JP2015097009A - ソーシャルネットワーキングサービス提供システムおよびサーバ - Google Patents

Abstract

【課題】人と人との良好なつながりを構築できる可能を高める。
【解決手段】サーバは、ユーザが特定の日付の行動予定としてユーザ端末に入力した予定情報を、その日付に対応づけてユーザアカウントごとにデータベースに登録し、日付および行動場所が同一と解される予定情報が複数のユーザアカウントで前記データベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間でのメッセージの授受を仲介する。
【選択図】図４

Description

本発明は、ソーシャルネットワーキングサービスを提供するシステム、およびそれに用いられるサーバに関する。

近年、インターネットを利用したいわゆるソーシャルネットワーキングサービス（ＳＮＳ）を利用するユーザが増加している。ＳＮＳは、人と人とのつながりをサポートすることを目的とし、例えば共通の趣味や嗜好を持つ人々が知り合うきっかけを与える場としても利用される（例えば、特許文献１参照）。

一方、インターネットを利用したスケジュール管理システムが知られている（特許文献２参照）。スケジュール管理システムにおいて、管理サーバは、サイトに登録したユーザの端末にカレンダーを表示し、ユーザは、カレンダーの任意の日付に対応する箇所に予定を書き込む。管理サーバは、書き込まれた予定および日付（年月日）をそのユーザのユーザアカウントに対応づけて記憶する。ユーザは、記憶された情報をいつでも表示させて確認することができる。

特開２００８−１４０１７４号公報 特開２００５−３２２１７８号公報

上述したスケジュール管理を利用してＳＮＳを提供するシステムはない。

本発明におけるソーシャルネットワーキングサービス提供システムは、サーバと、サーバとネットワーク接続可能な複数のユーザ端末とを含み、サーバは、ユーザが特定の日付の行動予定としてユーザ端末に入力した予定情報を、その日付に対応づけてユーザアカウントごとにデータベースに登録するスケジュール管理部と、日付および行動場所が同一と解される予定情報が複数のユーザアカウントでデータベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間でのメッセージの授受を仲介する制御部とを具備する。

本発明によれば、スケジュール管理を利用してＳＮＳを提供することで、人と人との良好なつながりを構築できる可能性が高まる。

本発明の一実施形態におけるシステムの構成図。 データベース格納部の記憶例を示す図。 サーバによる処理手順の一例を示すフローチャート。 図３の同一予定検索処理の詳細を示すフローチャート。

図面を参照して本発明の一実施形態を説明する。
図１に示すように、本実施形態におけるシステムは、サービス提供者が保有するサーバ１０と、このサーバ１０にネットワーク回線（例えば、インターネット回線）２０を介して通信接続可能な複数のユーザ端末３０とを含む。サーバ１０が提供するサービスは、スケジュール管理サービス、およびこれを利用したソーシャルネットワーキングサービス（ＳＮＳ）である。なお、サーバ１０は１個のみ図示したが、複数のサーバから構成されていてもよい。

サーバ１０は、制御部１１、記憶部１２、通信部１３などを備える。制御部１１は、ＣＰＵ等から成る。記憶部１２は、データベースを格納するデータベース格納部１２Ａと、プログラムを格納するプログラム格納部１２Ｂとを含む。通信部１３は、ネットワーク回線２０を介してユーザ端末３０等と通信するための通信回路等から成る。

ユーザ端末３０は、通信機能および表示機能を有するものであれば、スマートフォン等の携帯端末でもよいし、据え置き型あるいはモバイル型のコンピュータでもよい。

本サービスを利用しようとする者は、本人を特定するための情報をユーザ端末３０からサーバ１０に送信し、ユーザアカウントを取得する（会員登録する）。送信する情報は、ユーザＩＤ、ログインパスワード、メールアドレス等を含み、これらは非公開情報として、ユーザアカウントごとにデータベース格納部１２Ａ内のデータベースに記憶される。

以下の説明において、「ユーザ」は、本サービスに会員登録したユーザを指す。

図２はデータベース格納部１２Ａに記憶されたデータベースの記憶例を示す図である。データベース格納部１２Ａには各ユーザＡ、Ｂ、Ｃ、・・・に対応してユーザ情報１２０１、１２０２、１２０３、・・・が記憶される。各ユーザ情報１２０１、１２０２、１２０３、・・・には、ユーザ名（ハンドルネーム）１２ａや、ユーザアカウント１２ｂ、また自己紹介等を含むユーザプロフィール１２ｃを記憶する。サービス提供者は、自己紹介の内容として、趣味、特技、職業、性別、年齢層等の記載をユーザに推奨し、これらをユーザプロフィール１２ｃとして記憶する。ユーザがユーザ端末３０にユーザプロフィールを記入して送信すると、サーバ１０は、受信したユーザプロフィール１２ｃをユーザアカウント１２ｂに対応づけてデータベースであるデータベース格納部１２Ａに記憶する。

更に、各ユーザ情報１２０１、１２０２、１２０３、・・・には、予定情報１２ｄが記憶される。ユーザは、ユーザ端末３０からユーザＩＤやパスワードをサーバ１０に送信してセッションを開始する。セッションは、ユーザアカウント１２ｂと一対一で対応する。セッションにおいて、ユーザは、スケジュール管理サービスを利用して、自身の予定情報１２ｄをサーバ１０に登録することができる。予定登録は、予定を登録したい「日」を含む「月」のカレンダーをユーザ端末３０に表示し、目的の「日」に対応する箇所に予定を書き込むことで行う。例えば、「○○○コンサート＠渋谷 開場１８：３０／開演１９：００」（○○○はアーティスト名）、「×××写真展 場所：＊＊＊ギャラリー」（×××は写真家名）などと書き込む。

サーバ１０は、書き込まれた予定およびその日付を当該ユーザアカウント１２ｂに対応づけてデータベース格納部１２Ａの予定情報１２ｄに記憶する。以降、ユーザは、自身が登録した予定情報１２ｄをいつでも確認できる。すなわち、ユーザが上述と同様の手順でセッションを開始し、予定を登録した「月」のカレンダーを表示させると、サーバ１０は、当該ユーザアカウント１２ｂに対応する予定情報１２ｄをデータベースから読み出し、該当する「日」に対応する箇所に表示する。

ところで、多くの人には、自分と同じ趣味を持っている人、あるいは自分と同じものに興味を持っている人と新たなつながりを持ちたいという願望がある。そこで本システムでは、この種の人と人とのつながりをサポートするため、サーバ１０は、同一の予定（日付および行動場所が同一と解される予定）を組んだ複数のユーザ間でのユーザプロフィール１２ｃの授受を仲介する。

すなわち、あるユーザのセッションにおいて、当該ユーザが予定を登録した後、サーバ１０は、その登録した予定情報１２ｄと同一の予定を登録した他のユーザをデータベースから検索する。検索タイミングとしては、ユーザが予定を登録した時点、ユーザが過去に登録した予定情報１２ｄを確認した時点、あるいはユーザが所定の確認操作を行った時点等が考えられる。

サーバ１０は、検索タイミングと判断すると、当該ユーザが登録した予定情報１２ｄからキーワードを抽出する。上述したコンサートや写真展等のイベントの場合、それらのイベント名、関連する人物名（アーティスト名、写真家名等）、会場名などがキーワードとして抽出される。次にサーバ１０は、抽出したキーワードや予定登録日付等に基づいてデータベース検索を行い、同一の予定と解される予定情報１２ｄを登録した他のユーザのうち、ユーザプロフィール１２ｃを登録しているユーザのユーザプロフィール１２ｃを抽出する。そして、抽出したユーザプロフィール１２ｃを当該ユーザ（正しくは、当該ユーザのユーザアカウント１２ｂに対応するユーザ端末３０）に送信する。当該ユーザのユーザ端末３０では、送信されてきたユーザプロフィール１２ｃがユーザごとに一覧表示される。

なお、各ユーザは、登録する予定ごとに自身のユーザプロフィール１２ｃの公開を許可するか否かを設定できるようにすることが望ましい。ユーザが「公開不可」を選択した場合、サーバ１０は、その予定情報１２ｄに関しては、当該ユーザのユーザプロフィール１２ｃを他のユーザに送信せず、また他のユーザのユーザプロフィール１２ｃを当該ユーザに送信することもない。

ここで、複数のユーザが同一の予定を組んだということは、それらのユーザが同じ日時に同じ場所で同じ行動をとる可能性が高いことを意味する。勿論、ユーザがたてる予定の中には、単に友人の誰それと会うといった、新たな人とのつながりを全く期待できないものも多々ある。しかし、予定の内容が、予め公に告知されたイベント（例えば、上述したコンサートや写真展など）の場合、それらのイベント会場は、同じ趣味を持つ複数の人が集う場といえるから、事前にそれらの人々の間でコミュニケーションをとれるようにすることで、新たな人とのつながりを築ける可能性が高まる。

そこでサーバ１０は、同一の予定を組んだ複数のユーザ間でのメッセージの授受を仲介することで、コミュニケーションの場を提供する。

一例として、ある女性のユーザＡがあるイベントの予定情報１２ｄを登録し、上述のようにして一覧表示された他のユーザのユーザプロフィール１２ｃを確認したところ、その中から気が合うと思われるユーザＢ（例えば、同じ女性で同じ趣味、かつ年齢層が自分と一致する）を見つけたとする。この場合、ユーザＡは、ユーザＢに対してメッセージを送ることができる。

ユーザが他の特定のユーザにメッセージを送るには、例えばユーザプロフィール１２ｃの一覧表示の中から目的のユーザのユーザプロフィール１２ｃを選択し、画面内のいずれかに表示されたメッセージボタンを操作すればよい。あるいは、各ユーザプロフィール１２ｃごとにメッセージボタンが表示されるようにし、目的のユーザに対応するメッセージボタンを操作する仕様でもよい。いずれの場合も、メッセージの送受信方法は、通常の電子メール送受信方法と同様である。すなわち、ユーザがメッセージボタンを操作すると、メッセージ書き込み欄が別窓で表示され、ユーザがメッセージを書き込んで送信ボタンを操作すると、そのメッセージがサーバ１０に送信される。

サーバ１０は、ユーザが発信したメッセージを保存するとともに、宛先に指定されたユーザに対し、別のユーザからメッセージが届いている旨を通知する。この通知を受信した宛先側ユーザが、サーバ１０にメッセージの送信を要求すると、サーバ１０は、発信側ユーザからのメッセージを宛先側ユーザに送信する。宛先側ユーザは、同様にして発信側ユーザに返信メッセージを送ることができる。

これにより、同一の予定を立てた二人のユーザ（例えば、上記ユーザＡとＢ）間で個人的なコミュニケーションが可能となる。かかるコミュニケーションを介して双方の気が合えば、イベントに先だって会って話しをしたり、イベントに連れだって出かけたり、イベント後に一緒に食事したりといった、新たな人と人とのつながりを構築できる可能性が高まる。

なお、いずれのユーザも、他のユーザとのやりとりを「ブロック」できるようにすることが望ましい。例えば上述のユーザＢが、ユーザＡからのメッセージを受け、そのメッセージの内容、あるいはユーザＡのユーザプロフィール１２ｃから、気が合いそうもないと判断した場合、または何らかの不審を抱いた場合は、ユーザＡに対して「ブロック」を設定できるようにする。この場合、サーバ１０は、ユーザＢが当該「ブロック」を解除しない限り、ユーザＡからユーザＢ宛の新たなメッセージが送信されても、その旨をユーザＢに通知せず、そのメッセージをユーザＢに送信することもない。

図３、図４は上述の機能を実現するための、サーバ１０における処理手順を示している。
このプログラムは、サーバ１０のプログラム格納部１２Ｂに格納されたもので、ユーザのログインに伴って制御部１１により実行される。

図３のステップＳ１において、制御部１１は、現在月のカレンダーを当該ユーザのユーザ端末（ログイン端末）３０に表示する（正しくは、制御部１１が現在月のカレンダーデータを当該ユーザのユーザ端末３０に送信し、そのデータを受信したユーザ端末３０が、そのデータに基づくカレンダーを自身の表示部に表示する）。

ステップＳ２において、制御部１１は、現在カレンダー表示されている「月」に関して、当該ユーザの予定情報１２ｄが登録されているか否かを判定する。ステップＳ２が否定されるとステップＳ６に進み、肯定されるとステップＳ３で、登録されている全ての予定情報１２ｄを、カレンダー中の該当する「日」部分に表示する。これによりユーザは、当該月における自身の予定を確認できる。

ステップＳ４において、制御部１１は、ユーザによる予定選択操作がなされたか否かを判定する。予定選択操作とは、ユーザがユーザ端末３０において、表示されている自身の予定情報１２ｄのいずれかを選択する操作である。ステップＳ４が肯定されるとステップＳ５に進み、選択された予定情報１２ｄに対して同一予定検索処理（図４）を行う。ステップＳ４が否定された場合はステップＳ６に進む。

ステップＳ６において、制御部１１は、ユーザによる予定入力操作が行われたか否かを判定する。予定入力操作とは、ユーザがユーザ端末３０において、表示されているカレンダーのいずれかの「日」に対応する箇所に予定を入力する操作である。ステップＳ６が否定されるとステップＳ９に進み、肯定されるとステップＳ７において、入力された予定とその日付とを対応づけてデータベース格納部１２Ａに予定情報１２ｄとして記憶する（入力された予定を登録する）。ステップＳ８では、ステップＳ７で登録した予定情報１２ｄに対して同一予定検索処理（図３）を行う。

ステップＳ９において、制御部１１は、ユーザによるカレンダー送り操作が行われたか否かを判定する。カレンダー送り操作とは、ユーザがユーザ端末３０において、現在表示されているカレンダーとは別の「月」のカレンダーの表示を指示する操作である。ステップＳ９が否定されるとステップＳ１１に進み、肯定されるとステップＳ１０において、指示された「月」のカレンダーを表示して（カレンダー送りを行って）ステップＳ２に戻る。

ステップＳ１１において、制御部１１は、ユーザによるログアウト操作がなされたか否かを判定し、否定されるとステップＳ２に戻り、肯定されると、ステップＳ１２で所定のログアウト処理を行って終了する。

図４はステップＳ５およびＳ８の同一予定検索処理の詳細を示している。
ステップＳ１０１において、制御部１１は、当該予定（ユーザによって選択された、または新たに登録された予定）と同一と解される予定情報１２ｄをデータベース格納部１２Ａに登録している他のユーザを検索する。これは上述したように、当該予定情報１２ｄの内容から抽出したキーワードと予定登録日付（月、日、時間）に基づいてデータベース検索を行い、同一の予定情報１２ｄと解される予定情報１２ｄを登録した他のユーザのうち、ユーザプロフィールを登録しているユーザのユーザプロフィール１２ｃを抽出する処理である。検索対象となる他のユーザは、ユーザプロフィール１２ｃを登録し、かつその公開を許可しているものに限る。

次いで制御部１１は、上記検索の結果、該当するデータが抽出されたか否かをステップＳ１０２で判定し、抽出されなかった場合はリターンする。その際、例えば「２０１３年１２月２０日の予定について、あなたと同一の予定を登録された方はいらっしゃいません」等のメッセージを表示することが望ましい。

一方、ステップＳ１０２が肯定された場合は、ステップＳ１０３に進む。上述したように、予め公に告知されたイベントに関する予定の場合、ステップＳ１０２が肯定される可能性は高い。ステップＳ１０３において、制御部１１は、抽出されたデータを表示するか否かをユーザに問う。例えば、「２０１３年１２月２５日の予定について、あなたと同一の予定を登録された方が１７名いらっしゃいます。表示しますか？」などと表示する。その後、制御部１１はユーザの反応を待つ（ステップＳ１０４、Ｓ１１０）。図２に示すデータベース格納部１２Ａの例では、ユーザＡが「×××写真展 場所：＊＊＊ギャラリー」を選択した、または新たに登録した場合に、ユーザＣの予定情報１２ｄが同一の予定として抽出される。

サーバの問いかけに対し、ユーザがＮＯの操作を行うとステップＳ１１０が肯定され、そのままリターンする。ユーザがＹＥＳの操作を行った場合は、ステップＳ１０４が肯定され、制御部１１はステップＳ１０５で検索結果を送信する。すなわち、同一の予定を組んだ他のユーザのユーザプロフィール１２ｃ（上記の例では、１７名分のユーザプロフィール１２ｃ）をユーザ端末３０に一覧表示する。

ステップＳ１０６において、制御部１１は、当該予定に関し、当該ユーザ宛に他のユーザからのメッセージがあるか否かを判定する。ステップＳ１０６が否定されるとステップＳ１０８に進み、肯定されるとステップＳ１０７で、メッセージがある旨をユーザに通知する。

上記ユーザプロフィール１２ｃの一覧表示画面において、ユーザはメッセージ関連操作を行うことができる。ステップＳ１０８でメッセージ関連操作が確認されると、制御部１１はステップＳ１０９において、その操作に応じたメッセージ関連処理を実行し、その後、ステップＳ１０８に戻る。

メッセージ関連操作とは、上述したように、ユーザプロフィール１２ｃが一覧表示されている他のユーザにメッセージを送信するための操作や、他のユーザからのメッセージがある場合（ステップＳ１０６が肯定された場合）にその送信を要求する操作、そのメッセージに対して返信を行うための操作である。メッセージ関連処理とは、それらの操作に応える処理である。

ステップＳ１０８が否定されると、制御部１１はステップＳ１１１でユーザによる一覧表示解除操作が行われたか否かを判定し、否定されるとステップＳ１０８に戻り、肯定されると、ユーザプロフィール１２ｃの一覧表示を解除してリターンする。

上記の実施形態によれば、スケジュール管理を利用してＳＮＳを提供することで、サーバに登録した予定を介して人と人との良好なつながりを新たに構築できる可能性が高まる。

（変形例）
（１）上記の実施形態では、サーバが、同一の予定を登録したユーザ間でメッセージの授受を仲介するのに先立ち、ユーザプロフィール１２ｃを公開する（ユーザ情報の授受を仲介する）例を示した。ユーザプロフィール１２ｃの公開は、ユーザがメッセージを送るべき相手を選別するのに大いに役立つが、特にこれは行わなくてもよい（ユーザプロフィール１２ｃの登録サービスそのものがなくてもよい）。この場合、サーバは、同一の予定をたてた他のユーザの数のみをユーザに通知し、通知を受けたユーザは、例えばその全員にメッセージを送れるようにすればよい。

（２）上記の実施形態では、ユーザが予定を選択若しくは新たに登録する時点で、予定が一致した他のユーザに対してメッセージを送り、他のユーザからの応答を待つように構成したが、他のユーザからの応答を待つことなく一旦メッセージを送り、図４に示す処理を終了し、他のユーザから応答があった場合に、その応答に対応する処理を別途行ってもよい。

（３）上記の実施形態では予定が完全に一致する他のユーザの予定を検索する例で説明したが、日時が完全に一致しなくても、当該予定の日時の近傍の範囲であって同一の予定が登録されている他のユーザを検索してコミュニケーションをとれるようにしてもよい。この場合は、その後のコミュニケーションによって各ユーザの予定が同じ日時になるように調整することもできる。

（４）上記の実施形態では日付および行動場所を含む予定が一致する他のユーザの予定を検索する例で説明したが、予定だけでなく、ユーザプロフィールの一つまたは複数が一致する他のユーザの予定を検索するように構成してもよい。例えば、予定だけでなく趣味も一致する他のユーザの予定を検索してもよい。

１０ サーバ
１１ 制御部
１２ 記憶部
２０ ネットワーク回線
３０ ユーザ端末

Claims (4)

1. サーバと、前記サーバとネットワーク接続可能な複数のユーザ端末とを含み、
   前記サーバは、
   ユーザが特定の日付の行動予定として前記ユーザ端末に入力した予定情報を、その日付に対応づけてユーザアカウントごとにデータベースに登録するスケジュール管理部と、
   日付および行動場所が同一と解される予定情報が複数のユーザアカウントで前記データベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間でのメッセージの授受を仲介する制御部とを具備することを特徴とするソーシャルネットワーキングサービス提供システム。
2. 前記サーバは、前記ユーザ端末から送信されたユーザ情報を、ユーザアカウントごとに前記データベースに登録するユーザ情報登録部を更に備え、
   前記制御部は、日付および行動場所が同一と解される予定情報が複数のユーザアカウントで前記データベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間で、前記メッセージの授受を仲介するのに先立ち、前記ユーザ情報の授受を仲介することを特徴とする請求項１に記載のソーシャルネットワーキングサービス提供システム。
3. 複数のユーザ端末にネットワーク接続可能なサーバであって、
   ユーザが特定の日付の行動予定として前記ユーザ端末に入力した予定情報を、その日付に対応づけてユーザアカウントごとにデータベースに登録するスケジュール管理部と、
   日付および行動場所が同一と解される予定情報が複数のユーザアカウントで前記データベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間でのメッセージの授受を仲介する制御部とを具備することを特徴とするサーバ。
4. 前記ユーザ端末から送信されたユーザ情報を、ユーザアカウントごとに前記データベースに登録するユーザ情報登録部を更に備え、
   前記制御部は、日付および行動場所が同一と解される予定情報が複数のユーザアカウントで前記データベースに登録されている場合、当該複数のユーザアカウントに対応するユーザ端末間で、前記メッセージの授受を仲介するのに先立ち、前記ユーザ情報の授受を仲介することを特徴とする請求項３に記載のサーバ。

Images