コミュニティ支援サーバ、コミュニティ支援方法、及びコミュニティ支援プログラム
【課題】登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせる。
【解決手段】複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのＳＮＳサイトを提供するＳＮＳサーバ１０が、ユーザの存在が確認された存在確認時刻とスポットとを含むユーザ行動履歴情報を記憶するＳＮＳＤＢ１１を備え、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻とスポットとに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションの相手として紹介するための紹介通知を送信する。
【解決手段】複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのＳＮＳサイトを提供するＳＮＳサーバ１０が、ユーザの存在が確認された存在確認時刻とスポットとを含むユーザ行動履歴情報を記憶するＳＮＳＤＢ１１を備え、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻とスポットとに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションの相手として紹介するための紹介通知を送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するための技術に関する。
【背景技術】
【０００２】
従来から、ＳＮＳ（Social Networking Service）を提供する様々なＳＮＳシステムが運用されている。ＳＮＳシステムでは、一般に、フレンドリストと呼ばれるコミュニケーションの相手として互いに承認し合ったユーザのリストを管理する機能を有している（例えば、特許文献１参照）。
【０００３】
ＳＮＳシステムでは、フレンドリストに掲載されたユーザ同士でコミュニケーションを図っていくことで、より趣向性に富んだサービスの提供が可能となっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−３７４７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来のＳＮＳシステムでは、フレンドリストに新しいユーザが継続的に登録されていかなければ、ＳＮＳにおけるコミュニケーション量が次第に減少していくことになってしまい、やがてユーザがＳＮＳの利用を止めてしまうおそれがあるという問題があった。
【０００６】
本発明は、上記の問題を解決すべく、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明のコミュニティ支援サーバは、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバであって、ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得手段と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出手段と、該抽出手段によって抽出された組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信手段とを含むことを特徴とする。
【０００８】
上記の構成としたことで、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようになる。
【０００９】
前記ユーザ行動履歴情報取得手段は、前記ユーザ端末によって送信された当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得し、前記ユーザ端末は、該ユーザ端末または当該ユーザ端末を利用するユーザが携帯するＩＣチップが搭載された携帯具との通信によってユーザの存在を確認するユーザ確認装置から該確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバから、当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得して送信する構成とされていてもよい。
【００１０】
前記紹介条件は、例えば、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことである。
【００１１】
前記抽出手段によって抽出された紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成する紹介通知生成手段を含み、前記紹介通知送信手段は、前記紹介通知生成手段によって生成された紹介通知を送信する構成とされていてもよい。
【００１２】
また、本発明のコミュニティ支援方法は、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバが実行するコミュニティ支援方法であって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを含むことを特徴とする。
【００１３】
さらに、本発明のコミュニティ支援プログラムは、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバに実行させるためのコミュニティ支援プログラムであって、前記コミュニティ支援サーバに、ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを実行させるためのものである。
【発明の効果】
【００１４】
本発明によれば、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようになる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態におけるＳＮＳシステム１００の構成の例を示すブロック図である。
【図２】改札ＤＢに格納される改札情報の例を示す説明図である。
【図３】ユーザＤＢに格納されるユーザ情報の例を示す説明図である。
【図４】紹介通知処理の例を示すフローチャートである。
【図５】ＳＮＳＤＢに格納される紹介条件情報の例を示す説明図である。
【図６】改札情報の例を示す説明図である。
【図７】通知内容情報の例を示す説明図である。
【図８】フレンド申請処理の例を示すフローチャートである。
【図９】紹介通知画面の例を示す説明図である。
【図１０】ユーザ行動履歴情報の例を示す説明図である。
【発明を実施するための形態】
【００１６】
以下、本発明の一実施の形態について図面を参照して説明する。
【００１７】
図１は、本発明の一実施の形態におけるＳＮＳシステム１００の構成の例を示すブロック図である。図１に示すように、ＳＮＳシステム１００は、ＳＮＳサーバ１０と、改札情報管理サーバ２０と、ユーザ端末３０〜３Ｎ（Ｎは任意の正の整数）と、自動改札機４０〜４Ｎとを含む。
【００１８】
ＳＮＳサーバ１０、及びユーザ端末３０〜３Ｎは、それぞれ、インターネットなどの通信ネットワーク５０によって接続されている。改札情報管理サーバ２０、及び自動改札機４０〜４Ｎは、それぞれ、自動改札機４０〜４Ｎによって取得された改札情報を伝送するための専用回線やインターネットなどの通信ネットワーク６０によって接続されている。
【００１９】
ＳＮＳサーバ１０は、例えばＳＮＳのサービス提供者や本システムのシステム管理者によって管理され、例えばＷＷＷサーバなどの情報処理装置によって構成される。ＳＮＳサーバ１０は、複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのコミュニケーションサイト（ＳＮＳサイト）を提供するコミュニティ支援サーバの一例であり、ＳＮＳにおけるコミュニケーションを図るようにするための各種の機能を有する。具体的には、各登録ユーザを管理する機能、各種のビデオゲームを提供する機能などが該当する。この二つのネットワーク５０及び６０間の接続は、詳細を後述する規定のアプリケーションによってのみ、限定的に実施される。
【００２０】
ＳＮＳサーバ１０は、ＳＮＳを提供するための各種の情報を示すＳＮＳ情報を格納するＳＮＳＤＢ１１と、ＳＮＳの登録ユーザに関するＳＮＳユーザ情報を格納するＳＮＳユーザＤＢ１２とを備えている。ＳＮＳＤＢ１１及びＳＮＳユーザＤＢ１２は、それぞれ、ＳＮＳサーバ１０の内部に備えられていてもよいし、外部に備えられていてもよい。
【００２１】
改札情報管理サーバ２０は、例えば改札情報を管理する管理者や本システムのシステム管理者によって管理され、例えばＷＷＷサーバなどの情報処理装置によって構成される。改札情報管理サーバ２０は、自動改札機４０〜４Ｎによって取得された改札情報を収集して蓄積する機能などの各種の機能を有する。
【００２２】
改札情報管理サーバ２０は、自動改札機４０〜４Ｎによって取得された改札情報を格納する改札ＤＢ２１と、自動改札機４０〜４Ｎを利用するユーザに関する改札ユーザ情報を格納する改札ユーザＤＢ２２とを備えている。改札ＤＢ２１及び改札ユーザＤＢ２２は、それぞれ、改札情報管理サーバ２０の内部に備えられていてもよいし、外部に備えられていてもよい。
【００２３】
ユーザ端末３０〜３Ｎは、それぞれ、ＳＮＳの登録ユーザによって管理され、例えば携帯電話端末やパーソナルコンピュータなどの情報処理装置によって構成される。本例では、ユーザ端末３０〜３Ｎとして特にＩＣチップを搭載した携帯電話端末（後述する改札用携帯具の一例）が用いられるものとし、この携帯電話端末を用いて自動改札機４０〜４Ｎを通過するものとする。
【００２４】
自動改札機４０〜４Ｎは、鉄道の駅の改札口（入口、出口、出入口）に設置される機械であって、人間に代わって改札業務を行うためのものである。本例の自動改札機４０〜４Ｎは、ユーザが改札を通過するために携帯するＩＣカードや携帯機器などの改札用携帯具との間で接触式あるいは非接触式により通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する機能を有している。改札用携帯具には、自動改札機４０〜４Ｎとの通信や各種の制御を行う機能を有するＩＣチップが搭載されており、改札に必要な各種の情報（改札用携帯具を使用するユーザを一意に特定するためのＩＣチップＩＤ、乗車定期券情報、電子マネー情報など）を記憶するＩＣメモリを備えているものとする。
【００２５】
図２は、改札ＤＢ２１に格納される改札情報の例を示す説明図である。改札情報は、例えば図２に示すように、スポット名と、存在確認時刻と、ユーザを一意に識別するためのユーザＩＤとなる当該ユーザが保持する改札用携帯具に搭載されたＩＣメモリに記憶されているＩＣチップＩＤと、存在確認区分とを含む情報である。
【００２６】
「スポット名」は、ユーザが存在した場所を特定するための情報であり、本例では、「Ａ駅改札」などの自動改札機４０〜４Ｎが設置されている場所を特定可能な名称とされる。なお、「Ａ駅南１」、「Ａ駅南２」、「Ａ駅北１」というように個々の改札機ごとにスポット名を細かく定義するようにしてもよい。「存在確認時刻」は、ユーザが存在した時刻を特定するための情報であり、本例ではユーザが自動改札機４０〜４Ｎを通過した時刻とされる。「存在確認区分」は、本例では自動改札機４０〜４Ｎを駅への入場のために通過したか、駅からの退場のために通過したかを区別するための情報とされる。
【００２７】
図３は、ＳＮＳユーザＤＢ１２に格納されるＳＮＳユーザ情報の例を示す説明図である。ＳＮＳユーザ情報は、本システム１００の登録ユーザに関する情報であって、例えば図３に示すように、登録ユーザの氏名を示すユーザ名と、ＳＮＳ用ユーザＩＤと、該当ユーザのフレンドリストと、改札通過時にユーザを特定するためのＩＣチップＩＤとを含む情報である。このＩＣチップＩＤは当該ユーザが改札通過時に用いる改札用携帯具に搭載されるＩＣチップを一意に特定するためのものである。その他、ＳＮＳユーザ情報には、ユーザ認証などの際に用いられるパスワード、ユーザの分身としてＳＮＳサイト上で使用されるアバターに関する情報を示すアバター情報、ユーザの住所などの情報が含まれていてもよい。
【００２８】
次に、本例のＳＮＳシステム１００の動作について説明する。
なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００２９】
本例では、自動改札機４０〜４Ｎは、改札用携帯具との間で通信を行って改札に必要な情報を含む改札必要情報（例えばＩＣチップＩＤ、定期券情報あるいは残高情報）を取得する毎に、改札の通過を許可するか否か判定し、改札の通過を許可したことに応じて改札情報を生成し、生成した改札情報を改札情報管理サーバ２０に送信する。ここで、自動改札機４０〜４Ｎによって生成される改札情報には、ＩＣチップＩＤ、改札の通過を許可した時刻である存在確認時刻、該当する自動改札機４０〜４Ｎの設置場所を特定可能な示すスポット名、駅への入場を許可したか駅からの退場を許可したかを示す存在確認区分、その他鉄道会社での管理に必要な情報が含まれるものとする。
【００３０】
なお、上記改札情報は、自動改札機４０〜４Ｎだけでなく、改札用携帯具に搭載されたＩＣメモリ内にも蓄積されており、改札通過の度に情報が上書きされるものとする。
【００３１】
改札情報管理サーバ２０に送信された上記改札情報をＳＮＳサービスで利用するためには、改札情報をＳＮＳサーバ１０に引き渡す必要があるが、改札情報は鉄道会社の保有する重要な個人情報であるため、ＳＮＳサービス提供者が安易にアクセスできるものではない。そこで、改札情報にアクセスするためには鉄道会社の信用に足りうるセキュリティが確保されている必要がある。本例では、以下に詳細を記載する通り、改札に利用する改札用携帯具（具体的には携帯電話端末（ユーザ端末３０〜３Ｎ））内に記憶された、特定のアプリケーションを利用する方法を用いる。
【００３２】
ユーザは、改札に利用する携帯電話端末内に、予め、鉄道会社のサイトや当該ＳＮＳサービスのサイト等に用意されている改札履歴取得用アプリケーション（改札履歴取得用プログラム）をダウンロード保存しておく。ユーザは、このアプリケーションを手動で起動させるか、自動起動設定をしておくことにより、任意のタイミングでアプリケーションを起動させる。
【００３３】
改札履歴取得用アプリケーションは、起動すると、携帯電話端末に、まず自端末に搭載されているＩＣチップＩＤを確認し、その後、改札情報管理サーバ２０と通信を行いサーバ２０が備える改札ＤＢ２１内に蓄積されている全ての改札情報の中から、当該ＩＣチップＩＤの改札履歴情報だけを抜粋して取得し、ＳＮＳサーバ１０にこの情報を送信する処理を実行させる。各ユーザからこのアプリケーションを利用して個別に送信された改札情報は、ＳＮＳサーバ１０が備えるＳＮＳＤＢ１１にＳＮＳ情報の一部として保存され、統合的に管理される。
【００３４】
なお、ここまでの説明で明らかなように、ＳＮＳサービスの利用者であっても、後述する紹介通知のサービスを利用したくないユーザは、この改札履歴取得用アプリケーションのダウンロード自体を行わないか、起動をしないようにすれば、自身の改札情報がＳＮＳサーバ１０に送信されることはない。よって、望んでいないにもかかわらず他のＳＮＳユーザに自身の改札情報を通知されることはない。
【００３５】
このようにすることで、ユーザは不特定多数のユーザの改札履歴情報の中から自分の改札履歴情報だけを選択的に取得することが可能になるため、鉄道会社は他のユーザの改札情報を漏えいさせるリスクを心配する必要がない。なお、ＩＣチップＩＤは改竄が非常に困難なデータであり、セキュリティ上の信用度は非常に高く、電子マネーサービス等の高度なセキュリティを必要とするサービスにおいても活用されるものである。
【００３６】
また、アプリの起動のタイミングについては、予め設定することにより自動起動させるようにしてもよい。自動起動のタイミングとしては、毎日一定の時刻に起動させるような方法や、規定の間隔で起動させるような方法の他に、ＩＣチップ内に蓄積される改札情報が上書きされたことを検知することで起動するようにしてもよい。このように設定することによって、ユーザは改札を通過する度に逐次最新の改札履歴情報をＳＮＳサーバ１０に送信することが可能となり、よりリアルタイム性の高いサービスを受けることが可能となる。
【００３７】
次に、ＳＮＳサーバ１０が実行する紹介通知処理について説明する。
図４は、紹介通知処理の例を示すフローチャートである。ここでは、ＳＮＳサーバ１０がＳＮＳの登録ユーザであるユーザＢ，Ｃによって使用されるユーザ端末３０，３１に対して紹介通知を送信する場合を例にして説明を行なう。なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００３８】
紹介通知処理において、ＳＮＳサーバ１０は、先ず、改札履歴取得用アプリケーションを利用して改札情報管理サーバ２０からユーザ端末３０〜３Ｎが取得した改札情報をそのユーザ端末３０〜３Ｎから受信したか否かを判定する（ステップＳ２０１）。改札情報を受信したと判定すると（ステップＳ２０１のＹ）、ＳＮＳサーバ１０は、受信した改札情報をＳＮＳ情報の一部としてＳＮＳＤＢ１１に保存する（ステップＳ２０２）。なお、本例では、ＳＮＳサーバ１０は、ＳＮＳＤＢ１１に格納されているＳＮＳユーザ情報を参照して、改札情報に含まれているＩＣチップＩＤに対応するＳＮＳ用ユーザＩＤを特定し、特定したＳＮＳ用ユーザＩＤを追加した改札情報をＳＮＳＤＢ１１に保存する。なお、ユーザ端末３０〜３ＮからＳＮＳ用ユーザＩＤが追加された改札情報を取得するようにしてもよい。
【００３９】
改札情報を保存すると、または改札情報を受信していないと判定すると（ステップＳ２０１のＮ）、ＳＮＳサーバ１０は、ユーザ端末３０〜３Ｎに対して紹介通知を送信するために改札情報を解析する解析タイミングであるか否かを確認する（ステップＳ２０３）。なお、解析タイミングとしては、例えば特定の時間間隔（例えば「１０分毎」や「１時間毎」など）や、新たな改札情報が保存されたときなど、種々の設定が考えられる。なお、ユーザ端末３０〜３Ｎから通知要求を受け付けたときを解析タイミングとして、通知要求を発したユーザ端末のために個別にステップＳ２０４以降の処理を行うようにしてもよい。
【００４０】
解析タイミングでなければ（ステップＳ２０３のＮ）、ＳＮＳサーバ１０は、ステップＳ２０１に遷移する。一方、解析タイミングであった場合には（ステップＳ２０３のＹ）、ＳＮＳサーバ１０は、ＳＮＳＤＢ１１にＳＮＳ情報の一部として保存されている改札情報を解析し、あらかじめ定められた紹介条件を満たすユーザの組を抽出するための処理を行う（ステップＳ２０４）。
【００４１】
本例においては、ＳＮＳ情報の一部としてＳＮＳＤＢ１１に紹介条件を特定可能な紹介条件情報が登録されており、ＳＮＳサーバ１０は、ステップＳ２０４にて、ＳＮＳＤＢ１１に保存された改札情報を参照し、登録された紹介条件のうち使用する条件として設定された紹介条件を満たすユーザの組を抽出する。
【００４２】
図５は、ＳＮＳＤＢ１１に格納される紹介条件情報の例を示す説明図である。紹介条件情報は、例えば図５に示すように、紹介条件を一意に特定するための紹介条件名称と、紹介条件とを含む情報である。本例においては、複数種類の紹介条件をそれぞれ示す紹介条件情報があらかじめ定められて登録されている。具体的には、例えば「ルールＡ」の紹介条件として、「同じ駅で前後３０分以内に通過したユーザ」が登録されている。ここでは、例えばシステム管理者によって、「ルールＡ」の紹介条件がステップＳ２０４にて使用する条件としてＳＮＳＤＢ１１に設定されているものとする。
【００４３】
なお、各紹介条件は、各ユーザが存在していた時刻（存在確認時刻）と場所（スポット）とに関連した条件があらかじめ定められるものとする。例えば、「同じ駅で前後３０分以内に入場したユーザ（ルールＢ）」、「同じ駅で前後３０分以内に退場したユーザ（ルールＣ）」、「近隣の駅で前後３０分以内に改札を通過したユーザ」、「ユーザ指定の駅の改札をユーザ指定の時間内に通過した他のユーザ（ルールＸ）」などが考えられる。なお、３０分は一例であり、どのような時間とされていてもよい。
【００４４】
なお、ルールＸが設定されている場合には、ユーザ端末３０〜３Ｎを使用する各ユーザそれぞれから駅と時間の指定をあらかじめ受け付けておき、ユーザ端末３０〜３Ｎ毎に異なる紹介条件が設定されるようにしてもよい。また、ユーザ端末３０〜３Ｎ毎に紹介条件が設定される場合には、ＳＮＳサーバ１０が、ステップＳ２０４にて、互いの紹介条件を満たしたユーザの組を抽出する構成としてもよい。
【００４５】
本例では、ＳＮＳサーバ１０は、ステップＳ２０４にて、ＳＮＳＤＢ１１に保存された改札情報を参照し、「同じ駅で前後３０分以内に通過したユーザ」を満たすユーザの組を抽出する。具体的には、ＳＮＳサーバ１０は、例えば、保存されている改札情報のうち未だ解析に用いられていない改札情報あるいは存在確認時刻が現在時刻から所定の解析対象時間前（例えば３時間前）以降である改札情報を参照し、同一の駅（同じスポット）を３０分差以内で通過したユーザの組を抽出する。具体的には、解析対象の改札情報が例えば図６に示す情報を含む場合には、ＳＮＳサーバ１０は、スポット名と存在確認時刻とを比較して、同じスポット（Ａ駅）を３０分差以内で通過したユーザの組として、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組と、ＳＮＳ用ユーザＩＤ「ＩＤ００７８」とＳＮＳ用ユーザＩＤ「ＩＤ００７９」の組とを含むユーザの組を抽出する。なお、ユーザの組は、２人のユーザに限らず、３人以上のユーザによって構成されていてもよい。また、３人以上のユーザによってユーザの組が構成されている場合に、通過時間が最も近い２人のユーザ、あるいはランダムに選ばれた２人のユーザといった２人のユーザに絞りこむようにしてもよい。
【００４６】
紹介条件を満たすユーザの組を抽出すると、ＳＮＳサーバ１０は、ＳＮＳユーザＤＢ１２に格納されたＳＮＳユーザ情報における該当ユーザのフレンドリストを参照して、抽出したユーザの組のうちフレンドリストに既にフレンド登録されているユーザ同士によって構成されている組を除外する（ステップＳ２０５）。なお、ステップＳ２０５にて、ユーザの組を構成する３人以上のユーザのうち一部のユーザ同士がフレンド登録済であった場合には、フレンド登録済のユーザ同士が同じ組にならないように組を分割するようにしてもよい。
【００４７】
本例では、ユーザＡとユーザＢとは既にフレンド登録しているため（図３参照）、ＳＮＳサーバ１０は、ステップＳ２０５にて、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組とＳＮＳ用ユーザＩＤ「ＩＤ００７８」とＳＮＳ用ユーザＩＤ「ＩＤ００７９」の組のうち、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組を除外する。
【００４８】
フレンドリストに登録済のユーザの組を除外すると、ＳＮＳサーバ１０は、除外していないユーザの組を構成する各ユーザに他方のユーザを紹介するための紹介通知を生成する処理を行う（ステップＳ２０６）。本例では、ＳＮＳＤＢ１１には、ＳＮＳ情報の一部として、紹介条件を示す各ルールに応じた通知内容を示す通知内容情報が登録されているものとする。ＳＮＳサーバ１０は、通知内容情報を参照し、該当するルールについての通知内容に従って、紹介通知を生成する。
【００４９】
図７は、ＳＮＳＤＢ１１に格納される通知内容情報の例を示す説明図である。通知内容情報は、例えば図７に示すように、紹介条件名称と通知内容とを含む情報である。ここでは、ＳＮＳサーバ１０に紹介条件として「ルールＡ」が設定されているため、ＳＮＳＮサーバ１０は、通知内容情報が示す通知内容のうち「ルールＡ」の通知内容に従って、ユーザＢ用の紹介通知として、「ユーザＢさん、ユーザＣさんとＡ駅でニアミス！フレンド申請してみては？」を明示した紹介通知を生成し、ユーザＣ用の紹介通知として、「ユーザＣさん、ユーザＢさんとＡ駅でニアミス！フレンド申請してみては？」を明示した紹介通知を生成する。なお、「フレンド申請」とは、ＳＮＳシステム１００において、ある登録ユーザが他の登録ユーザに対してフレンドリストに互いを登録することを要求するためのものである。
【００５０】
紹介通知を生成すると、ＳＮＳサーバ１０は、ユーザ端末３０，３１それぞれに対して紹介通知を例えば電子メールによって送信し（ステップＳ２０７）、ステップＳ２０１に遷移する。
【００５１】
次に、ユーザ端末３０〜３Ｎが実行するフレンド申請処理について説明する。ここでは、ユーザ端末３０がＳＮＳサーバ１０から紹介通知を受信した場合を例にして説明する。
【００５２】
図８は、ユーザ端末３０が実行するフレンド申請処理の例を示すフローチャートである。フレンド申請処理は、例えばユーザ端末３０の稼働中に実行される。なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００５３】
フレンド申請処理では、先ず、ユーザ端末３０は、紹介通知を受信したか否かを判定する（ステップＳ３０１）。この紹介通知は、上述した紹介通知処理のステップＳ２０７にて送信された通知である。
【００５４】
紹介通知を受信したと判定すると（ステップＳ３０１のＹ）、ユーザ端末３０は、表示画面に紹介通知を含む紹介通知画面を自己が備える表示装置（図示せず）に表示する（ステップＳ３０２）。
【００５５】
図９は、紹介通知画面の例を示す説明図である。図９に示すように、ユーザ端末３０の表示画面１０１には、通知内容情報に応じたテキストを含む紹介通知画面が表示される。紹介通知画面には、紹介相手ユーザ名表示領域１０２に該当ユーザ名が表示され、スポット名表示領域１０３に該当スポット名が表示された紹介内容を表示する表示領域と、紹介に応じてフレンド申請を行う場合に押下されるＹＥＳボタン１０４と、紹介に応じずにフレンド申請を行わない場合に押下されるＮＯボタン１０５とが設けられている。なお、本例においては、表示画面１０１はタッチパネルであるものとし、ユーザ端末３０は、例えばユーザＢの指による画面へのタッチに応じて各種の入力を受け付けるものとする。
【００５６】
紹介通知画面を表示したあと、ユーザ端末３０は、ユーザＢによるフレンド申請画面の表示要求を受け付けると（ステップＳ３０３のＹ）、ＳＮＳサーバ１０からフレンド申請画面を取得して、自己が備える表示装置の表示画面にフレンド申請画面を表示する（ステップＳ３０４）。本例においては、ユーザ端末３０は、紹介通知画面におけるＹＥＳボタン１０４が例えばユーザの指により押下された場合に、フレンド申請画面の表示要求を受け付けたと判定する。
【００５７】
フレンド申請画面は、図示はしないが、フレンド申請に必要な情報の入力を受け付けるための画面であり、例えば、フレンド申請者によるコメントなどの情報の入力を受け付ける入力領域などが設けられる。
【００５８】
ユーザ端末３０は、フレンド申請画面にてフレンド申請に必要な情報の入力を受け付けると（ステップＳ３０５のＹ）、フレンド申請画面にて受け付けた情報を含むフレンド申請情報をＳＮＳサーバ１０に向けて送信する（ステップＳ３０７）。ＳＮＳサーバ１０は、フレンド申請情報を受信すると、フレンド申請先の該当ユーザＣのユーザ端末３１に対して、例えば電子メールにてフレンドリストへの登録要求を受け入れるか否かを回答するためのフレンド要求回答画面を送信する。そして、フレンドリストへの登録要求を受け入れる旨の回答を受け付けた場合には、ＳＮＳサーバ１０は、該当ユーザＢ，Ｃ双方のフレンドリストにそれぞれ相手のユーザを登録する処理を行う。
【００５９】
一方、紹介通知画面を表示したあと、ユーザ端末３０は、ユーザＢによるフレンド申請画面の表示要求を受け付けることなく（ステップＳ３０３のＮ）、フレンド申請をしない旨を示す申請拒否の意思表示として紹介通知画面におけるＮＯボタン１０５が例えばユーザの指により押下されると（ステップＳ３０８のＹ）、紹介通知画面を消去して（ステップＳ３０９）、ここでのフレンド申請処理を終了する。
【００６０】
なお、上述した実施の形態では、鉄道の駅に設置される自動改札機４０〜４Ｎにて改札用携帯具との間で通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する構成としていたが、鉄道の駅に限らず、飛行場などの他の施設に設置される同様の器機によって改札用携帯具と同様の携帯具との間で通信を行い、改札情報と同様のユーザ行動履歴情報を生成する構成としてもよい。
【００６１】
また、上述した実施の形態では、鉄道の駅に設置される自動改札機４０〜４Ｎにて改札用携帯具との間で通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する構成としていたが、自動改札機４０〜４Ｎに限らず、コンビニエンスストアやレストランなどに設置される例えばカードリーダなどのユーザの存在を確認可能な他の装置（ユーザ確認装置）によって、改札用携帯具と同様の携帯具（例えば電子マネーを利用可能なＩＣカード）より取得された情報に基づいて、上述した改札情報と同様にして例えば図１０に示すようなユーザ行動履歴情報を生成して用いるようにしてもよい。
【００６２】
図１０は、ユーザ行動履歴情報の例を示す説明図である。ユーザ行動履歴情報は、例えば図１０に示すように、スポット名と、存在確認時刻と、ＩＣチップＩＤと、使用金額とを含む情報である。改札履歴取得用アプリケーションを用いた改札情報の取得方法と同様の仕組みで、コンビニエンスストアやレストランの経営者が提供する履歴取得用アプリケーションを用いることで、自身の端末のＩＣチップＩＤに合致するＩＣチップＩＤを含む履歴のみをコンビニエンスストアやレストランが管理する履歴情報サーバから改札用携帯具に取り込み、ＳＮＳサーバ１０に送信することが可能となる。このようにすれば、例えば同じ時間帯に同じエリア内のレストランに滞在していたユーザを紹介の対象としたり、同じ時間帯に同じエリア内のレストランで同様の金額を支払ったユーザを紹介の対象としたりすることができるようになる。さらに、例えば特定のレストランを利用したユーザに対して、その特定のレストランのコミュニティを紹介するようにしてもよい。なお、場所と時間以外の情報は、使用金額に限らず、購入した商品、購入した商品のカテゴリ、利用人数などの他の情報をユーザ行動履歴情報に含めることとし、そのような他の情報を紹介の条件に盛り込むようにしてもよい。上述した改札情報は、ユーザ行動履歴情報の一例である。
【００６３】
また、上述した実施の形態では、主として、ユーザ端末３０〜３ＮにＩＣチップなどの改札用携帯具の機能を搭載し、自動改札機４０〜４Ｎにてユーザ端末３０〜３Ｎとの間で通信を行う構成としていたが、ユーザ端末３０〜３Ｎとは別の改札用携帯具を用いる構成としてもよい。
【００６４】
以上に説明したように、上述した実施の形態では、複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのコミュニケーションサイト（例えばＳＮＳサイト）を提供するコミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、ユーザの存在が確認された存在確認時刻と存在確認場所（例えばスポット）とを含むユーザ行動履歴情報を取得し、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する構成としたので、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステム１００に持たせることができるようになる。
【００６５】
すなわち、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションの相手として紹介するための紹介通知を送信する構成としているので、共通の趣味や出身校といったコミュニティを介することなしに、時間的及び場所的に関連性を有するコミュニケーション相手に適した他のユーザを紹介することができるようになり、フレンドリストへの新たなフレンドの登録を適切に推奨することができるようになるため、ユーザの興味や関心を持続させることが可能となり、ＳＮＳの利用を促進することが可能となる。
【００６６】
また、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、ユーザ端末３０〜３Ｎによって送信された当該ユーザ端末３０〜３Ｎを利用するユーザに関するユーザ行動履歴情報を取得する構成とし、ユーザ端末３０〜３Ｎは、そのユーザ端末３０〜３Ｎまたはそのユーザ端末３０〜３Ｎを利用するユーザが携帯するＩＣチップが搭載された携帯具（例えば改札用携帯具）との通信によってユーザの存在を確認するユーザ確認装置（例えば自動改札機４０〜４Ｎ，ＩＣカードリーダ）から確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバ（例えば改札情報管理サーバ２０）から、そのユーザ端末３０〜３Ｎを利用するユーザに関するユーザ行動履歴情報を取得して送信する構成としているので、ユーザの意思を尊重した上で、存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を容易に取得しＳＮＳにて利用することができるようになる。すなわち、駅での改札時やコンビニエンスストアやレストランなどでの決済時に取得された情報に基づくユーザ行動履歴情報をユーザ端末３０〜３Ｎを介して取得することが可能となり、ＳＮＳサイトでのユーザ行動履歴情報の利用を希望するユーザのユーザ行動履歴情報を入手できるため、システム管理者側から積極的に個人情報を含むユーザ行動履歴情報を利用して特定した他のユーザを紹介することができるようになる。
【００６７】
また、上述した実施の形態では、紹介条件として、例えば、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことであるとしているので、時間的及び場所的に緊密な関連性を有するコミュニケーション相手に適した他のユーザを紹介することができるようになる。
【００６８】
また、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、抽出した紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成し、生成した紹介通知を送信する構成としているので、時間的及び場所的に緊密な関連性を有するユーザが紹介相手であることを明確した通知を行うことが可能となる。
【００６９】
なお、上述した実施の形態では、ユーザ行動履歴情報に基づいて、紹介するフレンド候補を特定し、フレンド候補として紹介する場合について説明したが、同様の処理によって、ユーザ行動履歴情報に基づいて、ＳＮＳ内で提供されるビデオゲームの対戦相手を紹介するようにしてもよい。このように構成すれば、登録ユーザのコミュニケーション相手としての対戦相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステム１００に持たせることができるようになる。
【００７０】
また、上述した実施の形態では、ユーザ行動履歴情報に基づいて、紹介するフレンド候補を特定し、フレンド候補として紹介する場合について説明したが、ユーザ行動履歴情報に基づいて、ＳＮＳ内で提供されるビデオゲームのパラメータを変更したり、新たなアイテムを登場させたりすることも考えられる。この場合、例えば、乗車駅から下車駅までの距離（区間）によって、ビデオゲームにおける敵キャラクタのゲーム上のレベルを変更したりすることが考えられる。また、路線や時間帯毎に異なるパラメータを設定することとし、特定の路線や時間帯の利用ユーザに対してビデオゲームを有利に進められるような特典を付与することとして、特定の路線や時間帯についてユーザの鉄道利用を促進させるようにしてもよい。
【００７１】
なお、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）は、自己が備える記憶装置に記憶されている制御プログラム（コミュニティ支援プログラム）に従って、上述した各種の処理を実行する。なお、ＳＮＳサーバ１０が、改札情報管理サーバ２０の機能を備える構成としてもよい。
【産業上の利用可能性】
【００７２】
本発明によれば、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせるのに有用である。
【符号の説明】
【００７３】
１０ ＳＮＳサーバ
１１ ＳＮＳＤＢ
１２ ＳＮＳユーザＤＢ
２０ 改札情報管理サーバ
２１ 改札ＤＢ
２２ 改札ユーザＤＢ
３０〜３Ｎ ユーザ端末
４０〜４Ｎ 自動改札機
５０，６０ 通信ネットワーク
【技術分野】
【０００１】
本発明は、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するための技術に関する。
【背景技術】
【０００２】
従来から、ＳＮＳ（Social Networking Service）を提供する様々なＳＮＳシステムが運用されている。ＳＮＳシステムでは、一般に、フレンドリストと呼ばれるコミュニケーションの相手として互いに承認し合ったユーザのリストを管理する機能を有している（例えば、特許文献１参照）。
【０００３】
ＳＮＳシステムでは、フレンドリストに掲載されたユーザ同士でコミュニケーションを図っていくことで、より趣向性に富んだサービスの提供が可能となっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−３７４７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来のＳＮＳシステムでは、フレンドリストに新しいユーザが継続的に登録されていかなければ、ＳＮＳにおけるコミュニケーション量が次第に減少していくことになってしまい、やがてユーザがＳＮＳの利用を止めてしまうおそれがあるという問題があった。
【０００６】
本発明は、上記の問題を解決すべく、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明のコミュニティ支援サーバは、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバであって、ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得手段と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出手段と、該抽出手段によって抽出された組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信手段とを含むことを特徴とする。
【０００８】
上記の構成としたことで、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようになる。
【０００９】
前記ユーザ行動履歴情報取得手段は、前記ユーザ端末によって送信された当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得し、前記ユーザ端末は、該ユーザ端末または当該ユーザ端末を利用するユーザが携帯するＩＣチップが搭載された携帯具との通信によってユーザの存在を確認するユーザ確認装置から該確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバから、当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得して送信する構成とされていてもよい。
【００１０】
前記紹介条件は、例えば、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことである。
【００１１】
前記抽出手段によって抽出された紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成する紹介通知生成手段を含み、前記紹介通知送信手段は、前記紹介通知生成手段によって生成された紹介通知を送信する構成とされていてもよい。
【００１２】
また、本発明のコミュニティ支援方法は、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバが実行するコミュニティ支援方法であって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを含むことを特徴とする。
【００１３】
さらに、本発明のコミュニティ支援プログラムは、複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバに実行させるためのコミュニティ支援プログラムであって、前記コミュニティ支援サーバに、ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを実行させるためのものである。
【発明の効果】
【００１４】
本発明によれば、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせることができるようになる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態におけるＳＮＳシステム１００の構成の例を示すブロック図である。
【図２】改札ＤＢに格納される改札情報の例を示す説明図である。
【図３】ユーザＤＢに格納されるユーザ情報の例を示す説明図である。
【図４】紹介通知処理の例を示すフローチャートである。
【図５】ＳＮＳＤＢに格納される紹介条件情報の例を示す説明図である。
【図６】改札情報の例を示す説明図である。
【図７】通知内容情報の例を示す説明図である。
【図８】フレンド申請処理の例を示すフローチャートである。
【図９】紹介通知画面の例を示す説明図である。
【図１０】ユーザ行動履歴情報の例を示す説明図である。
【発明を実施するための形態】
【００１６】
以下、本発明の一実施の形態について図面を参照して説明する。
【００１７】
図１は、本発明の一実施の形態におけるＳＮＳシステム１００の構成の例を示すブロック図である。図１に示すように、ＳＮＳシステム１００は、ＳＮＳサーバ１０と、改札情報管理サーバ２０と、ユーザ端末３０〜３Ｎ（Ｎは任意の正の整数）と、自動改札機４０〜４Ｎとを含む。
【００１８】
ＳＮＳサーバ１０、及びユーザ端末３０〜３Ｎは、それぞれ、インターネットなどの通信ネットワーク５０によって接続されている。改札情報管理サーバ２０、及び自動改札機４０〜４Ｎは、それぞれ、自動改札機４０〜４Ｎによって取得された改札情報を伝送するための専用回線やインターネットなどの通信ネットワーク６０によって接続されている。
【００１９】
ＳＮＳサーバ１０は、例えばＳＮＳのサービス提供者や本システムのシステム管理者によって管理され、例えばＷＷＷサーバなどの情報処理装置によって構成される。ＳＮＳサーバ１０は、複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのコミュニケーションサイト（ＳＮＳサイト）を提供するコミュニティ支援サーバの一例であり、ＳＮＳにおけるコミュニケーションを図るようにするための各種の機能を有する。具体的には、各登録ユーザを管理する機能、各種のビデオゲームを提供する機能などが該当する。この二つのネットワーク５０及び６０間の接続は、詳細を後述する規定のアプリケーションによってのみ、限定的に実施される。
【００２０】
ＳＮＳサーバ１０は、ＳＮＳを提供するための各種の情報を示すＳＮＳ情報を格納するＳＮＳＤＢ１１と、ＳＮＳの登録ユーザに関するＳＮＳユーザ情報を格納するＳＮＳユーザＤＢ１２とを備えている。ＳＮＳＤＢ１１及びＳＮＳユーザＤＢ１２は、それぞれ、ＳＮＳサーバ１０の内部に備えられていてもよいし、外部に備えられていてもよい。
【００２１】
改札情報管理サーバ２０は、例えば改札情報を管理する管理者や本システムのシステム管理者によって管理され、例えばＷＷＷサーバなどの情報処理装置によって構成される。改札情報管理サーバ２０は、自動改札機４０〜４Ｎによって取得された改札情報を収集して蓄積する機能などの各種の機能を有する。
【００２２】
改札情報管理サーバ２０は、自動改札機４０〜４Ｎによって取得された改札情報を格納する改札ＤＢ２１と、自動改札機４０〜４Ｎを利用するユーザに関する改札ユーザ情報を格納する改札ユーザＤＢ２２とを備えている。改札ＤＢ２１及び改札ユーザＤＢ２２は、それぞれ、改札情報管理サーバ２０の内部に備えられていてもよいし、外部に備えられていてもよい。
【００２３】
ユーザ端末３０〜３Ｎは、それぞれ、ＳＮＳの登録ユーザによって管理され、例えば携帯電話端末やパーソナルコンピュータなどの情報処理装置によって構成される。本例では、ユーザ端末３０〜３Ｎとして特にＩＣチップを搭載した携帯電話端末（後述する改札用携帯具の一例）が用いられるものとし、この携帯電話端末を用いて自動改札機４０〜４Ｎを通過するものとする。
【００２４】
自動改札機４０〜４Ｎは、鉄道の駅の改札口（入口、出口、出入口）に設置される機械であって、人間に代わって改札業務を行うためのものである。本例の自動改札機４０〜４Ｎは、ユーザが改札を通過するために携帯するＩＣカードや携帯機器などの改札用携帯具との間で接触式あるいは非接触式により通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する機能を有している。改札用携帯具には、自動改札機４０〜４Ｎとの通信や各種の制御を行う機能を有するＩＣチップが搭載されており、改札に必要な各種の情報（改札用携帯具を使用するユーザを一意に特定するためのＩＣチップＩＤ、乗車定期券情報、電子マネー情報など）を記憶するＩＣメモリを備えているものとする。
【００２５】
図２は、改札ＤＢ２１に格納される改札情報の例を示す説明図である。改札情報は、例えば図２に示すように、スポット名と、存在確認時刻と、ユーザを一意に識別するためのユーザＩＤとなる当該ユーザが保持する改札用携帯具に搭載されたＩＣメモリに記憶されているＩＣチップＩＤと、存在確認区分とを含む情報である。
【００２６】
「スポット名」は、ユーザが存在した場所を特定するための情報であり、本例では、「Ａ駅改札」などの自動改札機４０〜４Ｎが設置されている場所を特定可能な名称とされる。なお、「Ａ駅南１」、「Ａ駅南２」、「Ａ駅北１」というように個々の改札機ごとにスポット名を細かく定義するようにしてもよい。「存在確認時刻」は、ユーザが存在した時刻を特定するための情報であり、本例ではユーザが自動改札機４０〜４Ｎを通過した時刻とされる。「存在確認区分」は、本例では自動改札機４０〜４Ｎを駅への入場のために通過したか、駅からの退場のために通過したかを区別するための情報とされる。
【００２７】
図３は、ＳＮＳユーザＤＢ１２に格納されるＳＮＳユーザ情報の例を示す説明図である。ＳＮＳユーザ情報は、本システム１００の登録ユーザに関する情報であって、例えば図３に示すように、登録ユーザの氏名を示すユーザ名と、ＳＮＳ用ユーザＩＤと、該当ユーザのフレンドリストと、改札通過時にユーザを特定するためのＩＣチップＩＤとを含む情報である。このＩＣチップＩＤは当該ユーザが改札通過時に用いる改札用携帯具に搭載されるＩＣチップを一意に特定するためのものである。その他、ＳＮＳユーザ情報には、ユーザ認証などの際に用いられるパスワード、ユーザの分身としてＳＮＳサイト上で使用されるアバターに関する情報を示すアバター情報、ユーザの住所などの情報が含まれていてもよい。
【００２８】
次に、本例のＳＮＳシステム１００の動作について説明する。
なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００２９】
本例では、自動改札機４０〜４Ｎは、改札用携帯具との間で通信を行って改札に必要な情報を含む改札必要情報（例えばＩＣチップＩＤ、定期券情報あるいは残高情報）を取得する毎に、改札の通過を許可するか否か判定し、改札の通過を許可したことに応じて改札情報を生成し、生成した改札情報を改札情報管理サーバ２０に送信する。ここで、自動改札機４０〜４Ｎによって生成される改札情報には、ＩＣチップＩＤ、改札の通過を許可した時刻である存在確認時刻、該当する自動改札機４０〜４Ｎの設置場所を特定可能な示すスポット名、駅への入場を許可したか駅からの退場を許可したかを示す存在確認区分、その他鉄道会社での管理に必要な情報が含まれるものとする。
【００３０】
なお、上記改札情報は、自動改札機４０〜４Ｎだけでなく、改札用携帯具に搭載されたＩＣメモリ内にも蓄積されており、改札通過の度に情報が上書きされるものとする。
【００３１】
改札情報管理サーバ２０に送信された上記改札情報をＳＮＳサービスで利用するためには、改札情報をＳＮＳサーバ１０に引き渡す必要があるが、改札情報は鉄道会社の保有する重要な個人情報であるため、ＳＮＳサービス提供者が安易にアクセスできるものではない。そこで、改札情報にアクセスするためには鉄道会社の信用に足りうるセキュリティが確保されている必要がある。本例では、以下に詳細を記載する通り、改札に利用する改札用携帯具（具体的には携帯電話端末（ユーザ端末３０〜３Ｎ））内に記憶された、特定のアプリケーションを利用する方法を用いる。
【００３２】
ユーザは、改札に利用する携帯電話端末内に、予め、鉄道会社のサイトや当該ＳＮＳサービスのサイト等に用意されている改札履歴取得用アプリケーション（改札履歴取得用プログラム）をダウンロード保存しておく。ユーザは、このアプリケーションを手動で起動させるか、自動起動設定をしておくことにより、任意のタイミングでアプリケーションを起動させる。
【００３３】
改札履歴取得用アプリケーションは、起動すると、携帯電話端末に、まず自端末に搭載されているＩＣチップＩＤを確認し、その後、改札情報管理サーバ２０と通信を行いサーバ２０が備える改札ＤＢ２１内に蓄積されている全ての改札情報の中から、当該ＩＣチップＩＤの改札履歴情報だけを抜粋して取得し、ＳＮＳサーバ１０にこの情報を送信する処理を実行させる。各ユーザからこのアプリケーションを利用して個別に送信された改札情報は、ＳＮＳサーバ１０が備えるＳＮＳＤＢ１１にＳＮＳ情報の一部として保存され、統合的に管理される。
【００３４】
なお、ここまでの説明で明らかなように、ＳＮＳサービスの利用者であっても、後述する紹介通知のサービスを利用したくないユーザは、この改札履歴取得用アプリケーションのダウンロード自体を行わないか、起動をしないようにすれば、自身の改札情報がＳＮＳサーバ１０に送信されることはない。よって、望んでいないにもかかわらず他のＳＮＳユーザに自身の改札情報を通知されることはない。
【００３５】
このようにすることで、ユーザは不特定多数のユーザの改札履歴情報の中から自分の改札履歴情報だけを選択的に取得することが可能になるため、鉄道会社は他のユーザの改札情報を漏えいさせるリスクを心配する必要がない。なお、ＩＣチップＩＤは改竄が非常に困難なデータであり、セキュリティ上の信用度は非常に高く、電子マネーサービス等の高度なセキュリティを必要とするサービスにおいても活用されるものである。
【００３６】
また、アプリの起動のタイミングについては、予め設定することにより自動起動させるようにしてもよい。自動起動のタイミングとしては、毎日一定の時刻に起動させるような方法や、規定の間隔で起動させるような方法の他に、ＩＣチップ内に蓄積される改札情報が上書きされたことを検知することで起動するようにしてもよい。このように設定することによって、ユーザは改札を通過する度に逐次最新の改札履歴情報をＳＮＳサーバ１０に送信することが可能となり、よりリアルタイム性の高いサービスを受けることが可能となる。
【００３７】
次に、ＳＮＳサーバ１０が実行する紹介通知処理について説明する。
図４は、紹介通知処理の例を示すフローチャートである。ここでは、ＳＮＳサーバ１０がＳＮＳの登録ユーザであるユーザＢ，Ｃによって使用されるユーザ端末３０，３１に対して紹介通知を送信する場合を例にして説明を行なう。なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００３８】
紹介通知処理において、ＳＮＳサーバ１０は、先ず、改札履歴取得用アプリケーションを利用して改札情報管理サーバ２０からユーザ端末３０〜３Ｎが取得した改札情報をそのユーザ端末３０〜３Ｎから受信したか否かを判定する（ステップＳ２０１）。改札情報を受信したと判定すると（ステップＳ２０１のＹ）、ＳＮＳサーバ１０は、受信した改札情報をＳＮＳ情報の一部としてＳＮＳＤＢ１１に保存する（ステップＳ２０２）。なお、本例では、ＳＮＳサーバ１０は、ＳＮＳＤＢ１１に格納されているＳＮＳユーザ情報を参照して、改札情報に含まれているＩＣチップＩＤに対応するＳＮＳ用ユーザＩＤを特定し、特定したＳＮＳ用ユーザＩＤを追加した改札情報をＳＮＳＤＢ１１に保存する。なお、ユーザ端末３０〜３ＮからＳＮＳ用ユーザＩＤが追加された改札情報を取得するようにしてもよい。
【００３９】
改札情報を保存すると、または改札情報を受信していないと判定すると（ステップＳ２０１のＮ）、ＳＮＳサーバ１０は、ユーザ端末３０〜３Ｎに対して紹介通知を送信するために改札情報を解析する解析タイミングであるか否かを確認する（ステップＳ２０３）。なお、解析タイミングとしては、例えば特定の時間間隔（例えば「１０分毎」や「１時間毎」など）や、新たな改札情報が保存されたときなど、種々の設定が考えられる。なお、ユーザ端末３０〜３Ｎから通知要求を受け付けたときを解析タイミングとして、通知要求を発したユーザ端末のために個別にステップＳ２０４以降の処理を行うようにしてもよい。
【００４０】
解析タイミングでなければ（ステップＳ２０３のＮ）、ＳＮＳサーバ１０は、ステップＳ２０１に遷移する。一方、解析タイミングであった場合には（ステップＳ２０３のＹ）、ＳＮＳサーバ１０は、ＳＮＳＤＢ１１にＳＮＳ情報の一部として保存されている改札情報を解析し、あらかじめ定められた紹介条件を満たすユーザの組を抽出するための処理を行う（ステップＳ２０４）。
【００４１】
本例においては、ＳＮＳ情報の一部としてＳＮＳＤＢ１１に紹介条件を特定可能な紹介条件情報が登録されており、ＳＮＳサーバ１０は、ステップＳ２０４にて、ＳＮＳＤＢ１１に保存された改札情報を参照し、登録された紹介条件のうち使用する条件として設定された紹介条件を満たすユーザの組を抽出する。
【００４２】
図５は、ＳＮＳＤＢ１１に格納される紹介条件情報の例を示す説明図である。紹介条件情報は、例えば図５に示すように、紹介条件を一意に特定するための紹介条件名称と、紹介条件とを含む情報である。本例においては、複数種類の紹介条件をそれぞれ示す紹介条件情報があらかじめ定められて登録されている。具体的には、例えば「ルールＡ」の紹介条件として、「同じ駅で前後３０分以内に通過したユーザ」が登録されている。ここでは、例えばシステム管理者によって、「ルールＡ」の紹介条件がステップＳ２０４にて使用する条件としてＳＮＳＤＢ１１に設定されているものとする。
【００４３】
なお、各紹介条件は、各ユーザが存在していた時刻（存在確認時刻）と場所（スポット）とに関連した条件があらかじめ定められるものとする。例えば、「同じ駅で前後３０分以内に入場したユーザ（ルールＢ）」、「同じ駅で前後３０分以内に退場したユーザ（ルールＣ）」、「近隣の駅で前後３０分以内に改札を通過したユーザ」、「ユーザ指定の駅の改札をユーザ指定の時間内に通過した他のユーザ（ルールＸ）」などが考えられる。なお、３０分は一例であり、どのような時間とされていてもよい。
【００４４】
なお、ルールＸが設定されている場合には、ユーザ端末３０〜３Ｎを使用する各ユーザそれぞれから駅と時間の指定をあらかじめ受け付けておき、ユーザ端末３０〜３Ｎ毎に異なる紹介条件が設定されるようにしてもよい。また、ユーザ端末３０〜３Ｎ毎に紹介条件が設定される場合には、ＳＮＳサーバ１０が、ステップＳ２０４にて、互いの紹介条件を満たしたユーザの組を抽出する構成としてもよい。
【００４５】
本例では、ＳＮＳサーバ１０は、ステップＳ２０４にて、ＳＮＳＤＢ１１に保存された改札情報を参照し、「同じ駅で前後３０分以内に通過したユーザ」を満たすユーザの組を抽出する。具体的には、ＳＮＳサーバ１０は、例えば、保存されている改札情報のうち未だ解析に用いられていない改札情報あるいは存在確認時刻が現在時刻から所定の解析対象時間前（例えば３時間前）以降である改札情報を参照し、同一の駅（同じスポット）を３０分差以内で通過したユーザの組を抽出する。具体的には、解析対象の改札情報が例えば図６に示す情報を含む場合には、ＳＮＳサーバ１０は、スポット名と存在確認時刻とを比較して、同じスポット（Ａ駅）を３０分差以内で通過したユーザの組として、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組と、ＳＮＳ用ユーザＩＤ「ＩＤ００７８」とＳＮＳ用ユーザＩＤ「ＩＤ００７９」の組とを含むユーザの組を抽出する。なお、ユーザの組は、２人のユーザに限らず、３人以上のユーザによって構成されていてもよい。また、３人以上のユーザによってユーザの組が構成されている場合に、通過時間が最も近い２人のユーザ、あるいはランダムに選ばれた２人のユーザといった２人のユーザに絞りこむようにしてもよい。
【００４６】
紹介条件を満たすユーザの組を抽出すると、ＳＮＳサーバ１０は、ＳＮＳユーザＤＢ１２に格納されたＳＮＳユーザ情報における該当ユーザのフレンドリストを参照して、抽出したユーザの組のうちフレンドリストに既にフレンド登録されているユーザ同士によって構成されている組を除外する（ステップＳ２０５）。なお、ステップＳ２０５にて、ユーザの組を構成する３人以上のユーザのうち一部のユーザ同士がフレンド登録済であった場合には、フレンド登録済のユーザ同士が同じ組にならないように組を分割するようにしてもよい。
【００４７】
本例では、ユーザＡとユーザＢとは既にフレンド登録しているため（図３参照）、ＳＮＳサーバ１０は、ステップＳ２０５にて、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組とＳＮＳ用ユーザＩＤ「ＩＤ００７８」とＳＮＳ用ユーザＩＤ「ＩＤ００７９」の組のうち、ＳＮＳ用ユーザＩＤ「ＩＤ００７７」とＳＮＳ用ユーザＩＤ「ＩＤ００７８」の組を除外する。
【００４８】
フレンドリストに登録済のユーザの組を除外すると、ＳＮＳサーバ１０は、除外していないユーザの組を構成する各ユーザに他方のユーザを紹介するための紹介通知を生成する処理を行う（ステップＳ２０６）。本例では、ＳＮＳＤＢ１１には、ＳＮＳ情報の一部として、紹介条件を示す各ルールに応じた通知内容を示す通知内容情報が登録されているものとする。ＳＮＳサーバ１０は、通知内容情報を参照し、該当するルールについての通知内容に従って、紹介通知を生成する。
【００４９】
図７は、ＳＮＳＤＢ１１に格納される通知内容情報の例を示す説明図である。通知内容情報は、例えば図７に示すように、紹介条件名称と通知内容とを含む情報である。ここでは、ＳＮＳサーバ１０に紹介条件として「ルールＡ」が設定されているため、ＳＮＳＮサーバ１０は、通知内容情報が示す通知内容のうち「ルールＡ」の通知内容に従って、ユーザＢ用の紹介通知として、「ユーザＢさん、ユーザＣさんとＡ駅でニアミス！フレンド申請してみては？」を明示した紹介通知を生成し、ユーザＣ用の紹介通知として、「ユーザＣさん、ユーザＢさんとＡ駅でニアミス！フレンド申請してみては？」を明示した紹介通知を生成する。なお、「フレンド申請」とは、ＳＮＳシステム１００において、ある登録ユーザが他の登録ユーザに対してフレンドリストに互いを登録することを要求するためのものである。
【００５０】
紹介通知を生成すると、ＳＮＳサーバ１０は、ユーザ端末３０，３１それぞれに対して紹介通知を例えば電子メールによって送信し（ステップＳ２０７）、ステップＳ２０１に遷移する。
【００５１】
次に、ユーザ端末３０〜３Ｎが実行するフレンド申請処理について説明する。ここでは、ユーザ端末３０がＳＮＳサーバ１０から紹介通知を受信した場合を例にして説明する。
【００５２】
図８は、ユーザ端末３０が実行するフレンド申請処理の例を示すフローチャートである。フレンド申請処理は、例えばユーザ端末３０の稼働中に実行される。なお、本発明に関係しない処理については、その内容を省略している場合がある。
【００５３】
フレンド申請処理では、先ず、ユーザ端末３０は、紹介通知を受信したか否かを判定する（ステップＳ３０１）。この紹介通知は、上述した紹介通知処理のステップＳ２０７にて送信された通知である。
【００５４】
紹介通知を受信したと判定すると（ステップＳ３０１のＹ）、ユーザ端末３０は、表示画面に紹介通知を含む紹介通知画面を自己が備える表示装置（図示せず）に表示する（ステップＳ３０２）。
【００５５】
図９は、紹介通知画面の例を示す説明図である。図９に示すように、ユーザ端末３０の表示画面１０１には、通知内容情報に応じたテキストを含む紹介通知画面が表示される。紹介通知画面には、紹介相手ユーザ名表示領域１０２に該当ユーザ名が表示され、スポット名表示領域１０３に該当スポット名が表示された紹介内容を表示する表示領域と、紹介に応じてフレンド申請を行う場合に押下されるＹＥＳボタン１０４と、紹介に応じずにフレンド申請を行わない場合に押下されるＮＯボタン１０５とが設けられている。なお、本例においては、表示画面１０１はタッチパネルであるものとし、ユーザ端末３０は、例えばユーザＢの指による画面へのタッチに応じて各種の入力を受け付けるものとする。
【００５６】
紹介通知画面を表示したあと、ユーザ端末３０は、ユーザＢによるフレンド申請画面の表示要求を受け付けると（ステップＳ３０３のＹ）、ＳＮＳサーバ１０からフレンド申請画面を取得して、自己が備える表示装置の表示画面にフレンド申請画面を表示する（ステップＳ３０４）。本例においては、ユーザ端末３０は、紹介通知画面におけるＹＥＳボタン１０４が例えばユーザの指により押下された場合に、フレンド申請画面の表示要求を受け付けたと判定する。
【００５７】
フレンド申請画面は、図示はしないが、フレンド申請に必要な情報の入力を受け付けるための画面であり、例えば、フレンド申請者によるコメントなどの情報の入力を受け付ける入力領域などが設けられる。
【００５８】
ユーザ端末３０は、フレンド申請画面にてフレンド申請に必要な情報の入力を受け付けると（ステップＳ３０５のＹ）、フレンド申請画面にて受け付けた情報を含むフレンド申請情報をＳＮＳサーバ１０に向けて送信する（ステップＳ３０７）。ＳＮＳサーバ１０は、フレンド申請情報を受信すると、フレンド申請先の該当ユーザＣのユーザ端末３１に対して、例えば電子メールにてフレンドリストへの登録要求を受け入れるか否かを回答するためのフレンド要求回答画面を送信する。そして、フレンドリストへの登録要求を受け入れる旨の回答を受け付けた場合には、ＳＮＳサーバ１０は、該当ユーザＢ，Ｃ双方のフレンドリストにそれぞれ相手のユーザを登録する処理を行う。
【００５９】
一方、紹介通知画面を表示したあと、ユーザ端末３０は、ユーザＢによるフレンド申請画面の表示要求を受け付けることなく（ステップＳ３０３のＮ）、フレンド申請をしない旨を示す申請拒否の意思表示として紹介通知画面におけるＮＯボタン１０５が例えばユーザの指により押下されると（ステップＳ３０８のＹ）、紹介通知画面を消去して（ステップＳ３０９）、ここでのフレンド申請処理を終了する。
【００６０】
なお、上述した実施の形態では、鉄道の駅に設置される自動改札機４０〜４Ｎにて改札用携帯具との間で通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する構成としていたが、鉄道の駅に限らず、飛行場などの他の施設に設置される同様の器機によって改札用携帯具と同様の携帯具との間で通信を行い、改札情報と同様のユーザ行動履歴情報を生成する構成としてもよい。
【００６１】
また、上述した実施の形態では、鉄道の駅に設置される自動改札機４０〜４Ｎにて改札用携帯具との間で通信を行い、改札情報を生成して改札情報管理サーバ２０に送信する構成としていたが、自動改札機４０〜４Ｎに限らず、コンビニエンスストアやレストランなどに設置される例えばカードリーダなどのユーザの存在を確認可能な他の装置（ユーザ確認装置）によって、改札用携帯具と同様の携帯具（例えば電子マネーを利用可能なＩＣカード）より取得された情報に基づいて、上述した改札情報と同様にして例えば図１０に示すようなユーザ行動履歴情報を生成して用いるようにしてもよい。
【００６２】
図１０は、ユーザ行動履歴情報の例を示す説明図である。ユーザ行動履歴情報は、例えば図１０に示すように、スポット名と、存在確認時刻と、ＩＣチップＩＤと、使用金額とを含む情報である。改札履歴取得用アプリケーションを用いた改札情報の取得方法と同様の仕組みで、コンビニエンスストアやレストランの経営者が提供する履歴取得用アプリケーションを用いることで、自身の端末のＩＣチップＩＤに合致するＩＣチップＩＤを含む履歴のみをコンビニエンスストアやレストランが管理する履歴情報サーバから改札用携帯具に取り込み、ＳＮＳサーバ１０に送信することが可能となる。このようにすれば、例えば同じ時間帯に同じエリア内のレストランに滞在していたユーザを紹介の対象としたり、同じ時間帯に同じエリア内のレストランで同様の金額を支払ったユーザを紹介の対象としたりすることができるようになる。さらに、例えば特定のレストランを利用したユーザに対して、その特定のレストランのコミュニティを紹介するようにしてもよい。なお、場所と時間以外の情報は、使用金額に限らず、購入した商品、購入した商品のカテゴリ、利用人数などの他の情報をユーザ行動履歴情報に含めることとし、そのような他の情報を紹介の条件に盛り込むようにしてもよい。上述した改札情報は、ユーザ行動履歴情報の一例である。
【００６３】
また、上述した実施の形態では、主として、ユーザ端末３０〜３ＮにＩＣチップなどの改札用携帯具の機能を搭載し、自動改札機４０〜４Ｎにてユーザ端末３０〜３Ｎとの間で通信を行う構成としていたが、ユーザ端末３０〜３Ｎとは別の改札用携帯具を用いる構成としてもよい。
【００６４】
以上に説明したように、上述した実施の形態では、複数のユーザ同士がそれぞれ自己のユーザ端末３０〜３Ｎを利用して通信ネットワーク５０を介してコミュニケーションを図るためのコミュニケーションサイト（例えばＳＮＳサイト）を提供するコミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、ユーザの存在が確認された存在確認時刻と存在確認場所（例えばスポット）とを含むユーザ行動履歴情報を取得し、ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する構成としたので、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステム１００に持たせることができるようになる。
【００６５】
すなわち、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出し、抽出した組内の各ユーザそれぞれのユーザ端末３０，３１に対して、その組内の他のユーザをコミュニケーションの相手として紹介するための紹介通知を送信する構成としているので、共通の趣味や出身校といったコミュニティを介することなしに、時間的及び場所的に関連性を有するコミュニケーション相手に適した他のユーザを紹介することができるようになり、フレンドリストへの新たなフレンドの登録を適切に推奨することができるようになるため、ユーザの興味や関心を持続させることが可能となり、ＳＮＳの利用を促進することが可能となる。
【００６６】
また、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、ユーザ端末３０〜３Ｎによって送信された当該ユーザ端末３０〜３Ｎを利用するユーザに関するユーザ行動履歴情報を取得する構成とし、ユーザ端末３０〜３Ｎは、そのユーザ端末３０〜３Ｎまたはそのユーザ端末３０〜３Ｎを利用するユーザが携帯するＩＣチップが搭載された携帯具（例えば改札用携帯具）との通信によってユーザの存在を確認するユーザ確認装置（例えば自動改札機４０〜４Ｎ，ＩＣカードリーダ）から確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバ（例えば改札情報管理サーバ２０）から、そのユーザ端末３０〜３Ｎを利用するユーザに関するユーザ行動履歴情報を取得して送信する構成としているので、ユーザの意思を尊重した上で、存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を容易に取得しＳＮＳにて利用することができるようになる。すなわち、駅での改札時やコンビニエンスストアやレストランなどでの決済時に取得された情報に基づくユーザ行動履歴情報をユーザ端末３０〜３Ｎを介して取得することが可能となり、ＳＮＳサイトでのユーザ行動履歴情報の利用を希望するユーザのユーザ行動履歴情報を入手できるため、システム管理者側から積極的に個人情報を含むユーザ行動履歴情報を利用して特定した他のユーザを紹介することができるようになる。
【００６７】
また、上述した実施の形態では、紹介条件として、例えば、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことであるとしているので、時間的及び場所的に緊密な関連性を有するコミュニケーション相手に適した他のユーザを紹介することができるようになる。
【００６８】
また、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）が、抽出した紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成し、生成した紹介通知を送信する構成としているので、時間的及び場所的に緊密な関連性を有するユーザが紹介相手であることを明確した通知を行うことが可能となる。
【００６９】
なお、上述した実施の形態では、ユーザ行動履歴情報に基づいて、紹介するフレンド候補を特定し、フレンド候補として紹介する場合について説明したが、同様の処理によって、ユーザ行動履歴情報に基づいて、ＳＮＳ内で提供されるビデオゲームの対戦相手を紹介するようにしてもよい。このように構成すれば、登録ユーザのコミュニケーション相手としての対戦相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステム１００に持たせることができるようになる。
【００７０】
また、上述した実施の形態では、ユーザ行動履歴情報に基づいて、紹介するフレンド候補を特定し、フレンド候補として紹介する場合について説明したが、ユーザ行動履歴情報に基づいて、ＳＮＳ内で提供されるビデオゲームのパラメータを変更したり、新たなアイテムを登場させたりすることも考えられる。この場合、例えば、乗車駅から下車駅までの距離（区間）によって、ビデオゲームにおける敵キャラクタのゲーム上のレベルを変更したりすることが考えられる。また、路線や時間帯毎に異なるパラメータを設定することとし、特定の路線や時間帯の利用ユーザに対してビデオゲームを有利に進められるような特典を付与することとして、特定の路線や時間帯についてユーザの鉄道利用を促進させるようにしてもよい。
【００７１】
なお、上述した実施の形態では、コミュニティ支援サーバ（例えばＳＮＳサーバ１０）は、自己が備える記憶装置に記憶されている制御プログラム（コミュニティ支援プログラム）に従って、上述した各種の処理を実行する。なお、ＳＮＳサーバ１０が、改札情報管理サーバ２０の機能を備える構成としてもよい。
【産業上の利用可能性】
【００７２】
本発明によれば、登録ユーザのコミュニケーション相手に適した他の登録ユーザを適確に特定し、特定した他の登録ユーザを紹介する機能をシステムに持たせるのに有用である。
【符号の説明】
【００７３】
１０ ＳＮＳサーバ
１１ ＳＮＳＤＢ
１２ ＳＮＳユーザＤＢ
２０ 改札情報管理サーバ
２１ 改札ＤＢ
２２ 改札ユーザＤＢ
３０〜３Ｎ ユーザ端末
４０〜４Ｎ 自動改札機
５０，６０ 通信ネットワーク
【特許請求の範囲】
【請求項１】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバであって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得手段と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出手段と、
該抽出手段によって抽出された組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信手段とを含む
ことを特徴とするコミュニティ支援サーバ。
【請求項２】
前記ユーザ行動履歴情報取得手段は、前記ユーザ端末によって送信された当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得し、
前記ユーザ端末は、該ユーザ端末または当該ユーザ端末を利用するユーザが携帯するＩＣチップが搭載された携帯具との通信によってユーザの存在を確認するユーザ確認装置から該確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバから、当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得して送信する
請求項１記載のコミュニティ支援サーバ。
【請求項３】
前記紹介条件は、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことである
請求項１または請求項２記載のコミュニティ支援サーバ。
【請求項４】
前記抽出手段によって抽出された紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成する紹介通知生成手段を含み、
前記紹介通知送信手段は、前記紹介通知生成手段によって生成された紹介通知を送信する
請求項３記載のコミュニティ支援サーバ。
【請求項５】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバが実行するコミュニティ支援方法であって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、
該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを含む
ことを特徴とするコミュニティ支援方法。
【請求項６】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバに実行させるためのコミュニティ支援プログラムであって、
前記コミュニティ支援サーバに、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、
該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを
実行させるためのコミュニティ支援プログラム。
【請求項１】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバであって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得手段と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出手段と、
該抽出手段によって抽出された組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信手段とを含む
ことを特徴とするコミュニティ支援サーバ。
【請求項２】
前記ユーザ行動履歴情報取得手段は、前記ユーザ端末によって送信された当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得し、
前記ユーザ端末は、該ユーザ端末または当該ユーザ端末を利用するユーザが携帯するＩＣチップが搭載された携帯具との通信によってユーザの存在を確認するユーザ確認装置から該確認した際の存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得して蓄積しているユーザ行動履歴情報管理サーバから、当該ユーザ端末を利用するユーザに関するユーザ行動履歴情報を取得して送信する
請求項１記載のコミュニティ支援サーバ。
【請求項３】
前記紹介条件は、同一又は近隣の存在確認場所で、所定時間差内の存在確認時刻に存在が確認されたことである
請求項１または請求項２記載のコミュニティ支援サーバ。
【請求項４】
前記抽出手段によって抽出された紹介条件を満たすユーザの組内の各ユーザに対する紹介通知として、同一又は近隣の存在確認場所に同じ時間帯に存在していた他のユーザであることを明示した紹介通知を生成する紹介通知生成手段を含み、
前記紹介通知送信手段は、前記紹介通知生成手段によって生成された紹介通知を送信する
請求項３記載のコミュニティ支援サーバ。
【請求項５】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバが実行するコミュニティ支援方法であって、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、
該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを含む
ことを特徴とするコミュニティ支援方法。
【請求項６】
複数のユーザ同士がそれぞれ自己のユーザ端末を利用して通信ネットワークを介してコミュニケーションを図るためのコミュニケーションサイトを提供するコミュニティ支援サーバに実行させるためのコミュニティ支援プログラムであって、
前記コミュニティ支援サーバに、
ユーザの存在が確認された存在確認時刻と存在確認場所とを含むユーザ行動履歴情報を取得するユーザ行動履歴情報取得処理と、
ユーザ行動履歴情報を参照し、各ユーザの存在確認時刻と存在確認場所とに関連した条件としてあらかじめ定められた紹介条件を満たすユーザの組を抽出する抽出処理と、
該抽出処理にて抽出した組内の各ユーザそれぞれのユーザ端末に対して、当該組内の他のユーザを前記コミュニケーションサイトでのコミュニケーションの相手として紹介するための紹介通知を送信する紹介通知送信処理とを
実行させるためのコミュニティ支援プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−４８４２４（Ｐ２０１１−４８４２４Ａ）
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願番号】特願２００９−１９３８６８（Ｐ２００９−１９３８６８）
【出願日】平成２１年８月２５日（２００９．８．２５）
【出願人】（３０８０３３２８３）株式会社スクウェア・エニックス (173)
【Ｆターム（参考）】
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願日】平成２１年８月２５日（２００９．８．２５）
【出願人】（３０８０３３２８３）株式会社スクウェア・エニックス (173)
【Ｆターム（参考）】
[ Back to top ]