JP2009146315A - サービス提供システムの連携システム、サービス提供システムおよびその制御方法、ならびにコンピュータプログラム - Google Patents

Abstract

【課題】ユーザがＳＮＳのメンバを従来よりも簡単に検索できるようにする。
【解決手段】ＳＮＳ＿ＡのＳＮＳシステム２Ａに、検索条件受付部５１０、連携ＳＮＳインタフェース部２７、および検索結果画面送信部５１９を設ける。検索条件受付部５１０がユーザから検索条件を受け付けると、連携ＳＮＳインタフェース部２７は、ＳＮＳ＿Ｂの会員の中からその検索条件に合う会員を検索するようにＳＮＳシステム２Ｂに要求し、その結果を得る。検索結果画面送信部５１９は、その結果を示す結果表示用データＡＦをそのユーザの端末装置３に送信する。
【選択図】図７

Description

本発明は、ＳＮＳなどのサービスのシステムおよびその制御方法などに関する。

近年、ＳＮＳ（Social Networking Service）が普及している。また、１千万人以上の会員を擁する総合的なＳＮＳ、ビジネス向けのＳＮＳ、画像を共有するためのＳＮＳ、および特定のステータスを有する者の専用のＳＮＳなど、様々なＳＮＳが見られるようになった。

ＳＮＳに参加するためには、既にそのＳＮＳに参加している者から紹介を受けなければならない。そして、そのＳＮＳのＵＲＬをキーボードで入力することによってそのＳＮＳのＷｅｂサイトにアクセスし、自分の電子メールアドレス、ニックネーム、および趣味などをそのＳＮＳに登録しなければならない。

そこで、特許文献１に記載されるような方法が提案されている。この方法によると、招待先（被紹介者）は、メールのＵＲＬをクリックするだけで、ＳＮＳのＷｅｂページにアクセスすることができる。
特開２００７−６５７８３号公報

ところで、ユーザは、自分と同じＳＮＳに参加しているメンバを容易に検索することができる。しかし、自分が参加していないＳＮＳに参加しているメンバを検索することはできない。

よって、自分が参加していないＳＮＳに参加しているメンバを検索する必要があるのならば、そのＳＮＳに自ら参加しなければならない。しかし、新たにＳＮＳに参加するのは、上述の通り、様々な事項を入力しなければならず、面倒である。ＳＮＳ以外のサービスにおいても、同様である。

本発明は、このような問題点に鑑み、ユーザがＳＮＳのメンバを従来よりも簡単に検索できるようにすることを、目的とする。

本発明の一実施形態に係るサービス提供システムの連携システムは、ネットワークを介して第一の会員に対してサービスを提供する第一のサービス提供システムと、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムと、を有し、前記第一のサービス提供システムと前記第二のサービス提供システムとはネットワークを介して接続可能であり、前記第一のサービス提供システムには、検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、前記第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、が設けられ、前記第二のサービス提供システムには、前記第一のサービス提供システムから受信した前記検索条件に該当する前記第二の会員を検索する会員検索手段と、前記会員検索手段によって検索された前記第二の会員を示す第二の会員情報を前記第一のサービス提供システムに送信する会員情報送信手段と、が設けられ、前記第一のサービス提供システムには、さらに、前記第二のサービス提供システムから受信した前記第二の会員情報に基づいて、前記検索条件に該当する前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、が設けられている。

本発明の一実施形態に係るサービス提供システムは、ネットワークを介して第一の会員に対してサービスを提供するサービス提供システムであって、検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、前記会員問合せ手段によって送信された前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のサービス提供システムから受信する会員情報受信手段と、前記会員情報受信手段によって受信された前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、を有する。

好ましくは、前記検索条件に該当する前記第一の会員を検索する会員検索手段、を有し、前記検索結果回答手段は、前記第二の会員とともに、前記会員検索手段によって検索された前記第一の会員を、回答する。

または、前記第一の会員ごとに、当該サービス提供システムおよび前記第二のサービス提供システムにおいて共通に用いられる識別情報を記憶する、会員識別情報記憶手段、を有し、前記会員情報受信手段は、前記第二の会員情報として、前記第二の会員とともに当該第二の会員の前記識別情報を示す情報を受信し、前記検索結果回答手段は、前記第二の会員情報に示されるいずれかの前記第二の会員の前記識別情報と前記会員検索手段によって検索されたいずれかの前記第一の会員前記識別情報とが重複する場合は、当該第二の会員および当該第一の会員を、同一人であることを示して回答する。

または、前記第一の会員ごとに、複数の項目についての当該第一の会員の情報を記憶する、会員情報記憶手段、を有し、前記検索条件受付手段は、前記項目ごとの前記検索条件を受け付け、前記会員検索手段は、前記項目のうちの所定の項目の前記検索条件に該当する前記第一の会員を検索する。

本発明によると、ユーザがＳＮＳのメンバを従来よりも簡単に検索できるようにする。

図１はＳＮＳ連携システム１の全体的な構成の例を示す図、図２はＳＮＳシステム２の機能的構成の例を示す図である。

図１に示すように、ＳＮＳ連携システム１は、複数のＳＮＳシステム２および複数の端末装置３などによって構成される。各ＳＮＳシステム２および端末装置３は、インターネットなどのネットワークを介して互いに接続可能である。

ＳＮＳシステム２は、事業者がＳＮＳ（Social Networking Service）のサービスをユーザに提供するためのシステムである。以下、事業者Ａ、Ｂ、Ｃ、…のＳＮＳシステム２をそれぞれ「ＳＮＳシステム２Ａ」、「ＳＮＳシステム２Ｂ」、「ＳＮＳシステム２Ｃ」、…と区別して記載することがある。同様に、事業者Ａ、Ｂ、Ｃ、…がそれぞれ提供するＳＮＳを「ＳＮＳ＿Ａ」、「ＳＮＳ＿Ｂ」、「ＳＮＳ＿Ｃ」、…と区別して記載することがある。

従来、事業者は、自らのＳＮＳに加入しているユーザに対してのみ、サービスを提供する。しかし、本実施形態によると、事業者は、互いに信頼し連携する他の事業者のＳＮＳに加入しているユーザに対しても、サービスを提供する。この仕組みについては、後に詳細に説明する。

以下、事業者Ａ、Ｂ、Ｃが互いに自らのＳＮＳを連携させている場合を例に説明する。また、事業者から見て、その事業者のＳＮＳに加入しているユーザを「正会員」と記載し、連携している他のＳＮＳに加入しているユーザを「ゲスト会員」と記載する。ユーザから見て、そのユーザが正会員として利用することができるＳＮＳを「ホームＳＮＳ」と記載し、ゲスト会員として利用することができるＳＮＳを「ゲストＳＮＳ」と記載する。

端末装置３は、ユーザがＳＮＳを利用するための端末装置である。端末装置３には、インターネットに接続する機能およびＷｅｂブラウザが備わっている。端末装置３として、パーソナルコンピュータまたは携帯電話端末などが用いられる。

ＳＮＳシステム２は、図２に示すように、正会員サービス処理部２５、連携ＳＮＳインタフェース部２７、連携先ＳＮＳデータベース２Ｋ１、会員情報データベース２Ｋ２、プロフィールデータベース２Ｋ３、検索ポリシーデータベース２Ｋ４、検索条件変換データベース２Ｋ５、検索履歴データベース２Ｋ６、招待履歴データベース２Ｋ７、およびプロフィール履歴データベース２Ｋ８などによって構成される。

ＳＮＳシステム２として、ワークステーションまたはいわゆるサーバシステムが用いられる。図２の各部の機能を１式のサーバシステムによって実現してもよいし、各部を複数のサーバシステムまたは複数台のワークステーションに分散してもよい。

正会員サービス処理部２５は、連携先ゲスト登録受付部２５０、検索サービス処理部２５１、招待依頼受付部２５２、およびプロフィール閲覧処理部２５３などによって構成され、正会員であるユーザにサービスを提供するための処理を行う。一般にＳＮＳには様々な種類のサービスがあるが、本実施形態では、主に、会員の検索、コミュニティへの招待の依頼、プロフィールの閲覧のサービスを提供する場合を例に説明する。さらに、正会員サービス処理部２５は、正会員であるユーザを、連携している他のＳＮＳのゲスト会員として登録するための処理をも行う。

連携ＳＮＳインタフェース部２７は、ゲスト登録要求処理部２７０、検索要求処理部２７１、招待依頼送信部２７２、プロフィール要求処理部２７３、ゲスト登録処理部２８０、検索結果提供処理部２８１、招待依頼仕分処理部２８２、およびプロフィール提供処理部２８３などによって構成され、連携先である他のＳＮＳのＳＮＳシステム２に種々の要求を行ったり、当該他のＳＮＳのＳＮＳシステム２からの要求に基づいて種々の処理を行ったりする。つまり、他のＳＮＳシステム２とのインタフェースの役割を担う。

連携ＳＮＳインタフェース部２７の各部のうち、ゲスト登録要求処理部２７０ないしプロフィール要求処理部２７３は、正会員であるユーザが希望したサービスを提供するために、他のＳＮＳシステム２に対して種々の要求を行ったり必要な情報を取得したりする処理を行う。一方、ゲスト登録処理部２８０ないしプロフィール提供処理部２８３は、他のＳＮＳシステム２が他のＳＮＳの正会員であるユーザにサービスを提供するのをサポートするための処理を行う。

そのほか、ＳＮＳシステム２には、メッセージ、足跡、日記、コミュニティ、および友達などのサービスを正会員に提供するための手段が備わっている。これらの手段自体は公知なので、説明を省略する。

次に、図２の各部の機能を、各サービスのための共通の機能、正会員であるユーザを他のＳＮＳにゲスト会員として登録するための機能、ホームＳＮＳの会員およびゲストＳＮＳの会員の両方を検索するための機能、コミュニティへ招待するように依頼するための機能、およびプロフィールを閲覧するための機能に大別して説明する。また、ＳＮＳ＿Ａに加入しているユーザＵｘがＳＮＳ連携システム１を使用する場合を適宜例示しながら、説明する。

〔各サービスのための共通の機能〕
図３は連携先ＳＮＳデータベース２Ｋ１の例を示す図、図４は会員情報データベース２Ｋ２の例を示す図、図５はプロフィールデータベース２Ｋ３の例を示す図である。

連携先ＳＮＳデータベース２Ｋ１には、図３に示すように、連携先である他のＳＮＳごとの連携先ＳＮＳ情報ＤＴ１が記憶されている。

連携先ＳＮＳ情報ＤＴ１のうちの「ＳＮＳ−ＩＤ」は、そのＳＮＳを識別するための識別情報である。「ＳＮＳ名」は、そのＳＮＳの名称である。「ＩＰアドレス」は、そのＳＮＳのＳＮＳシステム２のＩＰアドレスを示す。例えば、ＳＮＳシステム２Ａの連携先ＳＮＳデータベース２Ｋ１には、ＳＮＳ＿ＢおよびＳＮＳ＿Ｃそれぞれの連携先ＳＮＳ情報ＤＴ１が記憶されている。

ＳＮＳシステム２の会員情報データベース２Ｋ２には、図４に示すように、正会員またはゲスト会員であるユーザごとの会員情報ＤＴ２が記憶されている。例えば、ＳＮＳ＿Ａの会員情報データベース２Ｋ２には、ＳＮＳ＿ＡをホームＳＮＳとするユーザごとの会員情報ＤＴ２と、ＳＮＳ＿ＡをゲストＳＮＳとするユーザごとの会員情報ＤＴ２とが、記憶されている。上述のユーザＵｘの会員情報ＤＴ２も、記憶されている。

会員情報ＤＴ２の中の「会員ＩＤ」は、そのユーザを識別するための識別情報である。会員ＩＤとして、例えばユーザ本人の電子メールアドレスが用いられる。

「ローカルニックネーム」は、そのユーザがそのＳＮＳの中で自らを指すために用いる架空の名前である。１人のユーザがＳＮＳごとに異なるローカルニックネームを付けることが可能である。例えば、ユーザＵｘは、ＳＮＳ＿Ａでは「ｔａｒａｋｏ」というローカルニックネームを使い、ＳＮＳ＿Ｂでは「ｍｅｎｔａｉｋｏ」というローカルニックネームを使うことができる。また、複数のユーザが同一のローカルニックネームを付けることが可能である。

一方、「グローバルニックネーム」は、そのユーザのホームＳＮＳおよびゲストＳＮＳのすべてで共通に用いられるニックネームである。グローバルニックネームは、ユーザが任意に決めてもよいし、そのユーザのホームＳＮＳのＳＮＳシステム２が自動的に決めてもよい。ただし、いずれにせよ、グローバルニックネームは、ユーザごとに異なる。つまり、ユニークである。

「会員区分」は、そのユーザが正会員であるかゲスト会員であるかを示す。ユーザＵｘの会員情報ＤＴ２の「会員区分」には、「正会員」が示される。

「ホームＳＮＳ−ＩＤ」は、そのユーザがホームＳＮＳとするＳＮＳの識別情報（ＳＮＳ−ＩＤ）を示す。「ホームＳＮＳ会員ＩＤ」は、そのユーザの、ホームＳＮＳにおける会員ＩＤを示す。ただし、そのユーザが正会員である場合は、両フィールドともに、空欄である。したがって、ＳＮＳシステム２Ａの会員情報データベース２Ｋ２に記憶されているユーザＵｘの会員情報ＤＴ２の両フィールドは、空欄である。

「利用ログ」は、そのユーザによるＳＮＳの利用の履歴を示す。具体的には、利用したサービスの種類、日時、および利用方法などが示される。

さらに、会員情報データベース２Ｋ２には、正会員であるユーザごとに、そのユーザがゲスト会員として登録されている他のＳＮＳのＳＮＳ−ＩＤおよび当該他のＳＮＳにおいて利用することができるサービス（つまり、利用権限）などを示すゲストＳＮＳ情報ＤＴＧが記憶されている。

プロフィールデータベース２Ｋ３には、図５に示すように、正会員であるユーザごとの氏名、性別、趣味、および年齢など様々な事項のプロフィールを示すプロフィール情報ＤＴ３が記憶されている。

〔正会員であるユーザを他のＳＮＳにゲスト会員として登録するための機能〕
図６はゲストＳＮＳへの会員登録の処理の流れの例を説明するフローチャートである。

正会員サービス処理部２５の連携先ゲスト登録受付部２５０は、連携先である他のＳＮＳのゲスト会員になりたい旨の要求を、正会員であるユーザから受け付ける処理を行う。

連携ＳＮＳインタフェース部２７のゲスト登録要求処理部２７０は、連携先ゲスト登録受付部２５０によって受け付けられたユーザからの要求に基づいて、他のＳＮＳのＳＮＳシステム２に対して、そのユーザをゲスト会員として当該他のＳＮＳに登録すべき旨の要求を行う。

一方、ゲスト登録処理部２８０は、他のＳＮＳのＳＮＳシステム２からの要求に従って、当該他のＳＮＳの正会員であるユーザを自らのＳＮＳにゲスト会員として登録する処理を行う。

ここで、ユーザＵｘがＳＮＳ＿Ｂのゲスト会員になることを希望した場合を例に、図６のフローチャートを参照しながら、ＳＮＳシステム２Ａの連携先ゲスト登録受付部２５０およびゲスト登録要求処理部２７０およびＳＮＳシステム２Ｂのゲスト登録処理部２８０の処理内容について詳細に説明する。

ユーザＵｘは、Ｗｅｂブラウザを操作して自分の端末装置３をＳＮＳシステム２Ａに接続させ、自分の会員ＩＤを用いてＳＮＳ＿Ａにログインする。そして、ＳＮＳ＿Ｂのゲスト会員になることを要求するコマンド入力する。

すると、このコマンドは、端末装置３からＳＮＳシステム２Ａに宛てて発信される。ＳＮＳシステム２Ａの連携先ゲスト登録受付部２５０は、このコマンドを受け付けると（図６の＃１０１）、ユーザＵｘのＳＮＳ＿Ａにおける会員ＩＤ、ユーザＵｘのグローバルニックネーム、およびゲスト会員として登録すべき旨の要求を示すゲスト登録要求データＲＱ１を生成する（＃１０２）。この会員ＩＤおよびグローバルニックネームは、ＳＮＳシステム２Ａ自身の会員情報データベース２Ｋ２（図４参照）に記憶されている、そのユーザの会員情報ＤＴ２に基づいている。以下、他の目的の処理においても同様に、会員情報ＤＴ２が参照される。

ゲスト登録要求処理部２７０は、このゲスト登録要求データＲＱ１をＳＮＳシステム２Ｂに宛てて送信する（＃１０３）。

ＳＮＳシステム２Ｂのゲスト登録処理部２８０は、このゲスト登録要求データＲＱ１を受信すると（＃１１１）、ＳＮＳシステム２Ｂ自身の会員情報データベース２Ｋ２に、新たな会員情報ＤＴ２を生成し登録する（＃１１２）。これにより、ユーザＵｘがＳＮＳ＿Ｂのゲスト会員として登録される。この会員情報ＤＴ２の各フィールドには、次のような情報が示される。

「会員ＩＤ」には、ＳＮＳ＿ＢにおいてユーザＵｘを他のユーザと識別するための会員ＩＤが示される。この会員ＩＤとして、ＳＮＳ＿Ｂが新たにユーザＵｘに対して発行した電子メールアドレスを用いてもよい。または、ユーザＵｘに会員ＩＤを指定させてもよい。「会員区分」には、「ゲスト会員」が示される。

「ホームＳＮＳ−ＩＤ」には、そのゲスト登録要求データＲＱ１の発信元であるＳＮＳつまりＳＮＳ＿ＡのＳＮＳ−ＩＤが示される。「グローバルニックネーム」および「ホームＳＮＳ＿会員ＩＤ」には、それぞれ、そのゲスト登録要求データＲＱ１に示されるグローバルニックネームおよび会員ＩＤ（つまり、ユーザＵｘのＳＮＳ＿Ａにおける会員ＩＤ）が示される。

ローカルニックネームは、ユーザＵｘが任意に指定することができる。今回の要求の際にユーザＵｘに指定させてもよいし、後にユーザＵｘがＳＮＳ＿Ｂにログインした際に指定させてもよい。

ゲスト登録処理部２８０は、ユーザＵｘの会員情報ＤＴ２を自らの会員情報データベース２Ｋ２に登録することができたら、登録に成功した旨およびＳＮＳ＿ＢにおけるユーザＵｘの会員ＩＤを示す完了通知データＡＣ１を、ＳＮＳシステム２Ａに宛てて送信する（＃１１３）。また、ユーザＵｘに対して利用を許可するサービス（つまり、利用権限。例えば、会員の検索またはコミュニティへの参加など。）を示す利用権限データＲＴ１もＳＮＳシステム２Ａに宛てて送信する。

ＳＮＳシステム２Ａにおいて、完了通知データＡＣ１および利用権限データＲＴ１が受信されると（＃１０４）、連携先ゲスト登録受付部２５０は、完了通知データＡＣ１をユーザＵｘの端末装置３に転送する（＃１０５）。さらに、利用権限データＲＴ１に示される利用権限が追加されるように、会員情報データベース２Ｋ２に記憶されている、ユーザＵｘのゲストＳＮＳ情報ＤＴＧを更新する（＃１０６）。

〔ホームＳＮＳの会員およびゲストＳＮＳの会員の両方を検索するための機能〕
図７は検索サービス処理部２５１の構成の例を示す図、図８は検索結果提供処理部２８１の構成の例を示す図、図９は検索処理の流れの例を説明するフローチャート、図１０は検索条件の指定用の画面の例を示す図、図１１は検索条件データＲＱ２の例を示す図、図１２は重み付けの方法を説明するための図、図１３は検索結果データＡＣ２の例を示す図、図１４は集約処理の流れの例を説明するフローチャート、図１５は検索結果データＡＣ２、ＡＤ２の集約の例を示す図、図１６は検索集約結果データＡＥの変形例を示す図である。

図２において、検索ポリシーデータベース２Ｋ４には、会員の検索のポリシーを示す検索ポリシーデータＤＴ４が記憶されている。

検索条件変換データベース２Ｋ５には、ユーザが指定した検索条件を、上述のポリシーに合わせて変換するための規則を示す検索条件変換データＤＴ５が記憶されている。

検索履歴データベース２Ｋ６には、ユーザごとに、検索のサービスを利用した日時などを示す検索履歴情報ＤＴ６が記憶されている。

正会員サービス処理部２５の検索サービス処理部２５１は、図７に示すように、検索条件受付部５１０、利用者権限確認部５１１、検索履歴確認部５１２、検索対象ＳＮＳ特定部５１３、検索結果受信部５１４、会員検索部５１５、重み調整処理部５１６、検索結果集約部５１７、検索結果画面生成部５１８、および検索結果画面送信部５１９などによって構成される。このような構成によって、正会員であるユーザから指定された検索条件に基づいて、そのユーザのホームＳＮＳおよびゲストＳＮＳのそれぞれの正会員を検索するための処理を行う。

連携ＳＮＳインタフェース部２７の検索要求処理部２７１は、検索を要求したユーザにとってのゲストＳＮＳのＳＮＳシステム２に対して、そのゲストＳＮＳの中の正会員の検索を行うように要求する。

一方、検索結果提供処理部２８１は、図８に示すように、要求受付部８１０、ポリシー適合判別部８１１、検索条件変換部８１２、会員検索部８１３、重み調整部８１４、および検索結果回答部８１５などによって構成される。このような構成によって、他のＳＮＳのＳＮＳシステム２からの要求に基づいて、正会員の検索を行いその結果を提供する処理を行う。

ここで、ユーザＵｘが特定の条件を満たす会員をＳＮＳ＿Ａ、ＳＮＳ＿Ｂ、およびＳＮＳ＿Ｃのうちのいずれかを利用する会員の中から探し出したい場合を例に、図９のフローチャートを参照しながら、ＳＮＳシステム２Ａの検索サービス処理部２５１および検索要求処理部２７１およびＳＮＳシステム２Ｂ、２Ｃそれぞれの検索結果提供処理部２８１の処理内容について詳細に説明する。

ユーザＵｘは、Ｗｅｂブラウザを操作し自分の会員ＩＤでＳＮＳ＿Ａにログインする。そして、図１０のような画面に検索条件を入力し、ゲストＳＮＳの中の検索を行うことを指定する。

ＳＮＳシステム２Ａの検索条件受付部５１０がこの検索条件を受け付けると（図９の＃１２１）、利用者権限確認部５１１は、会員情報データベース２Ｋ２に記憶されている、ユーザＵｘのゲストＳＮＳ情報ＤＴＧに基づいて、ユーザＵｘがどのＳＮＳから検索のサービスの利用権限を受けているのかを確認する（＃１２２）。ステップ＃１２２の処理と並行してまたは前後して、検索履歴確認部５１２は、ユーザＵｘの検索履歴情報ＤＴ６に基づいて、ユーザＵｘが過去の所定の期間に（例えば、今から１時間以内に）検索のサービスを所定の回数以上利用したが否かを確認する（＃１２３）。

検索対象ＳＮＳ特定部５１３は、利用者権限確認部５１１および検索履歴確認部５１２による確認の結果に基づいて、他のいずれのＳＮＳのＳＮＳシステム２に対して会員の検索を要求するかを特定する（＃１２４）。具体的には、次のように特定を行う。

ユーザＵｘが過去の所定の期間に検索のサービスを所定の回数以上利用したことが検索履歴確認部５１２によって確認された場合は、他のいずれのＳＮＳに対しても検索の要求は行わないと、決定する。また、ＳＮＳシステム２Ａ自身による検索も行わないと、決定する。つまり、ユーザからの検索の要求を拒否する。これは、検索のサービスの悪用を防止するためである。

所定の期間に検索のサービスを利用した回数が所定の回数未満である場合は、利用者権限確認部５１１によって確認された、ユーザＵｘが検索のサービスの利用権限を有するＳＮＳに、要求先を決定する。

連携ＳＮＳインタフェース部２７の検索要求処理部２７１は、検索条件受付部５１０によって受け付けられた検索条件に該当する会員を検索するように、検索対象ＳＮＳ特定部５１３によって特定されたＳＮＳのＳＮＳシステム２に対して要求する（＃１２５）。この際に、その検索条件を示す検索条件データＲＱ２を、特定されたＳＮＳのＳＮＳシステム２それぞれに対して送信する。本フローチャートの例では、ＳＮＳ＿Ｂのみが要求先として特定されたものとする。よって、ＳＮＳシステム２Ｃは、今回の検索に関する処理は実行しない。検索条件データＲＱ２には、検索条件のほか、ユーザＵｘのホームＳＮＳのＳＮＳ−ＩＤ、要求先のＳＮＳのＳＮＳ−ＩＤ、検索ごとに振られる連続番号、ユーザＵｘが過去に検索を要求（依頼）した回数、前回の依頼の日時、依頼の理由、およびユーザＵｘのステータスなどが示される。

ＳＮＳシステム２Ｂの要求受付部８１０がＳＮＳシステム２Ａから検索条件データＲＱ２を受信すると（＃１４１）、ポリシー適合判別部８１１は、ＳＮＳシステム２Ｂ自身の検索ポリシーデータベース２Ｋ４に記憶されている検索ポリシーデータＤＴ４に基づいて、今回要求された検索が、ＳＮＳ＿Ｂにおけるポリシーに合っているか否かをチェックする（＃１４２）。

例えば、氏名を検索キーとする検索を禁止するというポリシーが検索ポリシーデータＤＴ４に示されている場合は、検索条件データＲＱ２に示される検索条件に氏名が含まれているか否かをチェックする。そして、含まれていなければポリシーに合うと判別し、含まれていればポリシーに合わないと判別する。

ポリシーに合う場合は、検索条件変換部８１２は、検索条件データＲＱ２に示される検索条件を、検索条件変換データＤＴ５に基づいて、ＳＮＳ＿Ｂにおけるプロフィールの管理方法に合うものに変換する（＃１４３）。

例えば、ＳＮＳ＿Ｂにおいて、性別を非公開とし、学校の卒業時期を「６１期生」のような第何回目の卒業であるか（卒業回生）によって表し、理学部および工学部などを「理工学部」と総称して表す、という管理方法によってプロフィールを管理している場合は、検索条件データＲＱ２に示される検索条件を、次のように変換する。

検索条件に性別が示される場合は、それが「男」であるか「女」であるかを問わず、「ＡＬＬ」に変換する。検索条件に特定の大学の西暦の卒業年度が示されている場合は、「６１期生」のような卒業回生に変換する。または、検索条件に「工学部」と示される場合は、「理工学部」に変換する。

ポリシーに合わない場合は、検索結果提供処理部２８１は、検索できない旨の回答を要求元つまりＳＮＳシステム２Ａに対して送信する。または、検索条件変換部８１２は、ポリシーに合わない部分が削除されるように、検索条件データＲＱ２の検索条件を更新する。

会員検索部８１３は、検索条件変換部８１２によって必要に応じて変換されまたは返還された検索条件に合う会員のプロフィール情報ＤＴ３を、プロフィールデータベース２Ｋ３（図５参照）の中から検索する（＃１４４）。

検索条件に複数のフィールド（項目）が含まれる場合は、いずれか１つのフィールド（項目）でも内容が一致するプロフィール情報ＤＴ３をすべて検索する。

重み調整部８１４は、会員検索部８１３によって検索されたプロフィール情報ＤＴ３ごとに、フィールドごとに検索条件との一致具合などに応じた重み付け（重みの調整）を行うことによって、プロフィール情報ＤＴ３と検索条件との一致具合を示す一致度点数ＰＴを算出する（＃１４５）。ここで、一致度点数ＰＴの算出方法を、図１２を参照しながら説明する。

図１２（ａ）のような、検索条件変異定数を、ＳＮＳの管理者が予め定義しておく。検索条件変異定数は、プロフィールのフィールド（項目）ごとの重み定数からなる。検索における、そのフィールドの重要性が大きいほど、重み定数は大きくなる。

検索条件変異定数は、検索ポリシーデータベース２Ｋ４または検索条件変換データベース２Ｋ５などに記憶させておいてもよいし、検索条件変異定数用のデータベースを用意しておき、これに記憶させておいてもよい。

検索条件データＲＱ２に示される検索条件の各フィールドの検索キーと会員検索部８１３によって検索された各フィールドの内容（情報）とを照合する。そして、すべてのフィールドが一致の場合の点数（以下、「標準点数」と記載する。）を「１００」と定め、不一致だったフィールドに対応する重み定数を、標準点数から減算する。この差が、そのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。

例えば、検索条件が図１２（ｂ）のような内容であり、図１２（ｃ）に示す内容を含む、ＳＮＳ＿Ｂの正会員であるユーザＵａのプロフィール情報ＤＴ３が検索されたとする。両者を照合すると、図１２（ａ）の検索条件変異定数に示されるフィールドのすべてについて両者の内容が一致する。したがって、いずれのフィールドについても重み定数が発生しないので、標準点数である「１００」が、ユーザＵａのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。

または、図１２（ｄ）に示す内容を含む、ユーザＵｂのプロフィール情報ＤＴ３が検索されたとする。このプロフィール情報ＤＴ３の「現住所の都道府県」フィールドは空白であるので、このフィールドは「不明」という理由により、照合不能である。よって、このフィールドの重み定数は「１０」である。それ以外のフィールドについては、両者は一致する。したがって、「１００−１０＝９０」が、ユーザＵｂのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。

または、図１２（ｅ）に示す内容を含む、ユーザＵｃのプロフィール情報ＤＴ３が検索されたとする。このプロフィール情報ＤＴ３と検索条件とは、「学部」フィールドが類似し、残りのフィールドは一致する。したがって、「１００−４０＝６０」が、ユーザＵｃのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。なお、どの学部同士が類似するかは予め定義しておき、それを示すデータを所定のデータベースに記憶させておけばよい。

または、図１２（ｆ）に示す内容を含む、ユーザＵｄのプロフィール情報ＤＴ３が検索されたとする。このプロフィール情報ＤＴ３と検索条件とは、「卒業年度」フィールドが不一致であるが、残りのフィールドは一致する。したがって、「１００−５０＝５０」が、ユーザＵｄのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。

または、図１２（ｇ）に示す内容を含む、ユーザＵｅのプロフィール情報ＤＴ３が検索されたとする。このプロフィール情報ＤＴ３と検索条件とは、「卒業年度」フィールドが不一致であり、「学部」フィールドが類似し、残りのフィールドは一致する。したがって、「１００−２５−４０＝３５」が、ユーザＵｅのプロフィール情報ＤＴ３の一致度点数ＰＴとなる。

フローチャートに戻って、検索結果回答部８１５は、会員検索部８１３によって検索されたプロフィール情報ＤＴ３の一部および重み調整部８１４によって算出されたそれぞれの一致度点数ＰＴを示す検索結果データＡＣ２を、今回の検索の要求元つまりＳＮＳシステム２Ａに回答（送信）する（＃１４６）。

ただし、一致度点数ＰＴが所定の点数（例えば、「６０点」）未満であるプロフィール情報ＤＴ３およびその一致度点数ＰＴは、検索結果データＡＣ２に含めないようにしてもよい。つまり、足切りを行ってもよい。

また、検索結果データＡＣ２には、プロフィール情報ＤＴ３のうち、ユーザが個人を特定できる情報は含めないようにする。例えば、図１３のように、プロフィール情報ＤＴ３のうちのローカルニックネームおよびグローバルニックネームのみを含めるようにする。氏名、住所、および電話番号などは含めないようにする。

図７のＳＮＳシステム２Ａの検索結果受信部５１４は、ＳＮＳシステム２Ａ自身の検索要求処理部２７１を介して、検索の要求先つまりＳＮＳ＿ＢのＳＮＳシステム２Ｂから検索結果データＡＣ２を受信する（＃１２８）。

他のＳＮＳに対して検索を要求する処理と並行して、会員検索部５１５は、ＳＮＳ＿Ａ自身のプロフィールデータベース２Ｋ３の中から、ユーザＵｘが指定した検索条件に合う正会員のプロフィール情報ＤＴ３の検索を行う（＃１２６）。ただし、ここでも、会員検索部８１３の場合と同様に、いずれか１つのフィールド（項目）でも内容が一致するプロフィール情報ＤＴ３をすべて検索する。

重み調整処理部５１６は、会員検索部５１５によって検索されたプロフィール情報ＤＴ３ごとに重みの調整を行うことによって一致度点数ＰＴを算出する（＃１２７）。一致度点数ＰＴの算出方法は、図１２を用いて前に説明した通りである。そして、検索されたプロフィール情報ＤＴ３の一部および算出したそれぞれの一致度点数ＰＴを示す検索結果データＡＤ２を生成する。検索結果データＡＤ２には、図１３で説明した検索結果データＡＣ２と同様のフィールドが含まれる。したがって、検索結果データＡＤ２には、ユーザが個人を特定できる情報は含まれない。

検索結果集約部５１７は、他のＳＮＳのＳＮＳシステム２から得られた検索結果データＡＣ２および会員検索部５１５および重み調整処理部５１６によって得られた検索結果データＡＤ２を、図１４に示すような手順で集約する（＃１２９）。

検索結果データＡＣ２およびＡＤ２の中から１つの未注目のレコードに注目する（＃１５１）。

未注目の他のレコードの中に、その注目したレコードに示されるグローバルニックネームと同一のグローバルニックネームを示すものがなければ、つまり、その注目したレコードに示されるグローバルニックネームが検索結果データＡＣ２およびＡＤ２の中に１つしかなければ（＃１５２でＮｏ）、その注目したレコードに示されるローカルニックネームおよび一致度点数ＰＴとその注目したレコードの送信元（回答元）であるＳＮＳの名称（ＳＮＳ名）とを選出する（＃１５３）。

一方、未注目の他のレコードの中に、その注目したレコードに示されるグローバルニックネームと同一のグローバルニックネームを示すものがあれば（＃１５２でＹｅｓ）、それにも注目する（＃１５４）。これらのレコードの中から、一致度点数ＰＴが最も高いものを判別する（＃１５５）。そして、一致度点数ＰＴが最も高いレコードに示されるローカルニックネームおよび一致度点数ＰＴとそのレコードの送信元であるＳＮＳの名称とを選出する（＃１５６）。

すべてのレコードが注目されステップ＃１５３またはステップ＃１５４〜＃１５６の処理がなされたら（＃１５７でＹｅｓ）、ステップ＃１５３、＃１５６で選出した結果を、一致度点数ＰＴの高い順に並べ替える（＃１５８）。

このような方法によると、図１５の上方に示すような１つの検索結果データＡＤ２および２つの検索結果データＡＣ２は、図１５の下方に示すように集約される。以下、集約の結果を示すデータを「検索集約結果データＡＥ」と記載する。

または、ステップ＃１５５、＃１５６において、一致度点数ＰＴが最も高いレコードのローカルニックネームのみを選出するのではなく、同一のグローバルニックネームを示すすべてのレコードのローカルニックネームを選出してもよい。つまり、ローカルニックネームの名寄せを行ってもよい。この場合は、図１６に示すような検索集約結果データＡＥが得られる。

図９に戻って、検索結果画面生成部５１８は、検索集約結果データＡＥの内容をＷｅｂブラウザに表示させるための結果表示用データＡＦを生成する（＃１３０）。そして、検索結果画面送信部５１９は、生成された結果表示用データＡＦをユーザＵｘの端末装置３に送信する（＃１３１）。なお、今回の検索の実績を示すデータが検索履歴データベース２Ｋ６に追加される（＃１３２）。

〔コミュニティへ招待するように依頼するための機能〕
図１７はコミュニティへの招待の依頼に関する処理の流れの例を説明するフローチャート、図１８は招待要求データＲＱ３の例を示す図、図１９は依頼受領通知データＡＣ３の例を示す図である。

図２において、招待履歴データベース２Ｋ７には、正会員であるユーザが誰かをコミュニティに招待した実績を示すデータが保存されている。

正会員サービス処理部２５の招待依頼受付部２５２は、ゲストＳＮＳに開設されているコミュニティへの招待の要求を、正会員であるユーザから受け付ける処理を行う。なお、要求者であるユーザは、この要求を行う際に、所望するコミュニティだけでなく、誰に招待してもらうのか（つまり、招待者）をも指定しなければならない。ユーザは、コミュニティに既に参加している他のユーザを、前に述べた会員の検索のサービスを利用して見つけ、当該他のユーザを招待者として指定することができる。

連携ＳＮＳインタフェース部２７の招待依頼送信部２７２は、招待依頼受付部２５２によって受け付けられた要求に従って、ユーザが指定したコミュニティおよび招待者などを示す招待要求データＲＱ３を生成し、その招待者が正会員として所属するＳＮＳのＳＮＳシステム２に送信する。

一方、要求を受ける側のＳＮＳシステム２の招待依頼仕分処理部２８２は、招待要求データＲＱ３に示される招待者に対して、同じく招待要求データＲＱ３に示されるコミュニティに要求元のユーザを招待するよう依頼するメッセージを与える。

ここで、ＳＮＳ＿Ｂに開設されているコミュニティＭｘへの招待をユーザＵｘが所望し、ＳＮＳ＿Ｂの正会員であるユーザＵｙに招待を依頼する場合を例に、図１７のフローチャートを参照しながら、ＳＮＳシステム２Ａの招待依頼受付部２５２および招待依頼送信部２７２およびＳＮＳシステム２Ｂの招待依頼仕分処理部２８２の処理内容について詳細に説明する。

ユーザＵｘは、Ｗｅｂブラウザを操作して自分の端末装置３をＳＮＳシステム２Ａに接続させ、自分の会員ＩＤを用いてＳＮＳ＿Ａにログインする。そして、希望するコミュニティとしてコミュニティＭｘを指定し、招待者としてユーザＵｙを指定する。

ＳＮＳシステム２Ａの招待依頼受付部２５２は、これらの指定を受け付けると（図１７の＃１６１）、図１８のような、ユーザＵｘのホームＳＮＳつまりＳＮＳ＿ＡのＳＮＳ−ＩＤ、ユーザＵｙのホームＳＮＳつまりＳＮＳ＿ＢのＳＮＳ−ＩＤ、ユーザＵｘのＳＮＳ＿Ａにおける会員ＩＤ、ユーザＵｙの会員ＩＤ（または、グローバルニックネーム）、コミュニティＭｘへの招待を依頼するためのメッセージ（招待依頼メッセージ）、コミュニティＭｘにおけるユーザＵｘの希望の権限の区分（権限区分）、およびＳＮＳ＿ＡにおけるユーザＵｘのステータス（ホームＳＮＳ会員ステータス）を示す招待要求データＲＱ３を生成する（＃１６２）。招待依頼送信部２７２は、その招待要求データＲＱ３をＳＮＳシステム２Ｂに送信する（＃１６３）。

なお、招待依頼メッセージは、予め用意しておいたテンプレートに、ユーザが指定したコミュニティのコミュニティ名を当てはめることによって、生成することができる。

ＳＮＳシステム２Ｂの招待依頼仕分処理部２８２は、招待要求データＲＱ３を受信すると（＃１７１）、それに示される招待者つまりユーザＵｙの会員ＩＤのメッセージボックスに、それに示される招待依頼メッセージを保存する（＃１７２）。これにより、招待の依頼が完了する。

その後、ユーザＵｙがユーザＵｘをコミュニティＭｘに招待すると、その実績を示すデータが招待履歴データベース２Ｋ７に追加される。また、ユーザＵｙは、依頼に対する返信をユーザＵｘに送ることができる。この場合は、図１９のような依頼受領通知データＡＣ３がユーザＵｙの端末装置３からユーザＵｘの端末装置３に送信される。

〔プロフィールを閲覧するための機能〕
図２０はプロフィールの閲覧に関する処理の流れの例を説明するフローチャートである。

図２において、プロフィール履歴データベース２Ｋ８には、ユーザがプロフィールを閲覧した実績を示すデータが保存されている。

正会員サービス処理部２５のプロフィール閲覧処理部２５３は、他のＳＮＳの正会員であるユーザのプロフィールの閲覧の要求を、正会員であるユーザから受け付ける処理を行う。以下、プロフィールの閲覧の対象であるユーザを「閲覧対象ユーザ」と記載することがある。

連携ＳＮＳインタフェース部２７のプロフィール要求処理部２７３は、プロフィール閲覧処理部２５３によって受け付けられた要求に従って、ユーザが指定した閲覧対象ユーザのプロフィールの開示の要求を、その閲覧対象ユーザのホームＳＮＳのＳＮＳシステム２に対して行う。

一方、その閲覧対象ユーザのホームＳＮＳのＳＮＳシステム２のプロフィール提供処理部２８３は、要求されたプロフィールを開示するための処理を行う。

ここで、ＳＮＳ＿ＢをホームＳＮＳとするユーザＵｚのプロフィールを閲覧することを、ユーザＵｘが所望する場合を例に、図２０のフローチャートを参照しながら、ＳＮＳシステム２Ａのプロフィール閲覧処理部２５３およびプロフィール要求処理部２７３およびＳＮＳシステム２Ｂのプロフィール提供処理部２８３の処理内容について詳細に説明する。

ユーザＵｘは、Ｗｅｂブラウザを操作して自分の端末装置３をＳＮＳシステム２Ａに接続させ、自分の会員ＩＤを用いてＳＮＳ＿Ａにログインする。そして、ユーザＵｚのプロフィールの閲覧の要求を行う。

ＳＮＳシステム２Ａのプロフィール閲覧処理部２５３は、この要求を受け付けると（図２０の＃１８１）、ユーザＵｚのプロフィールの開示の要求、ユーザＵｚの会員ＩＤ（またはグローバルニックネーム）、およびユーザＵｘの会員ＩＤなどを示す閲覧要求データＲＱ４を生成する（＃１８２）。プロフィール要求処理部２７３は、生成された閲覧要求データＲＱ４をＳＮＳシステム２Ｂに送信する（＃１８３）。

ＳＮＳシステム２Ｂのプロフィール提供処理部２８３は、閲覧要求データＲＱ４を受信すると（＃１９１）、ユーザＵｘがユーザＵｚのプロフィールの開示を求めている旨の通知を、ＳＮＳ＿Ｂの管理者の端末装置に送信する（＃１９２）。

そして、ユーザＵｚのプロフィールをユーザＵｘに開示してもよい旨の通知を管理者の端末装置から受信すると（＃１９３）、ＳＮＳシステム２Ｂ自身のプロフィールデータベース２Ｋ３からユーザＵｚのプロフィール情報ＤＴ３を呼び出し（＃１９４）、これをＳＮＳシステム２Ａに送信する（＃１９５）。なお、今回のプロフィールの開示の実績を示すデータがプロフィール履歴データベース２Ｋ８に追加される（＃１９６）。

ＳＮＳシステム２Ａにおいて、ユーザＵｚのプロフィール情報ＤＴ３が受信されると（＃１８４）、プロフィール閲覧処理部２５３は、そのプロフィール情報ＤＴ３の内容をＷｅｂブラウザに表示させるためのプロフィール画面データＡＧを生成し（＃１８５）、ユーザＵｘの端末装置３に送信する（＃１８６）。

なお、１人のユーザにつき所定の期間中に所定の件数までに限って、管理者の許可なくプロフィール情報ＤＴ３を開示するようにしてもよい。この制限を行う際には、プロフィール履歴データベース２Ｋ８に記憶されている履歴を参照すればよい。

本実施形態によると、ユーザは、自分が正会員として登録されていないＳＮＳのメンバの検索を、そのＳＮＳに正会員として登録することなく行うことができる。

また、本実施形態によると、ユーザは、ホームＳＮＳ以外のＳＮＳに新たに参加する場合も、プロフィールを入力する必要がない。よって、ホームＳＮＳ以外のＳＮＳへの参加を従来よりも容易に行うことができる。しかも、このユーザのプロフィールは、ホームＳＮＳで管理され、必要な場合にのみ他のＳＮＳに提供される。よって、個人情報の漏洩の危険性を軽減することができる。

本実施形態では、会員の検索の処理を、ユーザのホームＳＮＳのＳＮＳシステム２およびゲストＳＮＳのＳＮＳシステム２が行ったが、いずれにも該当しないＳＮＳのＳＮＳシステム２でも行ってもよい。

本実施形態では、重み付けの処理をホームＳＮＳのＳＮＳシステム２およびゲストＳＮＳのＳＮＳシステム２がそれぞれに行ったが、ホームＳＮＳのＳＮＳシステム２が統括的に行ってもよい。

〔会員の検索のサービスの変形例−数珠つなぎ検索〕
図２１はＳＮＳ＿ＡおよびＳＮＳ＿Ｂそれぞれのメンバ構成の例を示す図、図２２は数珠つなぎ検索の例を説明するための図、図２３は検索結果の画面の例を示す図である。

従来のＳＮＳのサービスの１つの「友達」というサービスがある。このサービスによると、交友関係のある２人のユーザ同士を関連付けて管理することができる。また、従来、検索条件の１つとして、「ユーザ自身の友達であること」または「ユーザ自身の友達またはその友達であること」などという、友達に関する条件を入れることができる。

例えば、ＳＮＳ＿Ａの構成メンバおよび友達関係が図２１のような場合において、ユーザＵｘが「ユーザ自身の友達またはその友達であること」を検索条件として指定した場合は、従来の方法によると、ＳＮＳシステム２Ａは、自らのＳＮＳの会員だけを検索範囲とするので、ユーザＵｄおよびユーザＵｃが検索される。他のＳＮＳのユーザは検索されない。

しかし、図７の検索結果集約部５１７は、他のＳＮＳのユーザも含めて、友達関係を考慮した検索を行うことができる。以下、この検索の仕組みを、図２２を参照しながら説明する。

ユーザＵｘが指定した検索条件に基づいて、図２２（ａ）のように、ＳＮＳシステム２Ａの会員検索部５１５がＳＮＳ＿Ａの正会員であるユーザの中からユーザＳａ、Ｓｂ、Ｓｃ、およびＳｄを検索し、検索結果受信部５１４はＳＮＳ＿Ｂの正会員であるユーザであるユーザＴｄ、Ｔｅ、Ｔｆ、およびＴｇを示す検索結果をＳＮＳシステム２Ｂから得たとする。検索結果集約部５１７は、同一のグローバルニックネームを有するユーザ同士を同一人と判別し、両者を集約する。図２２（ａ）の例では、ユーザＳｄとユーザＴｄとが同一人である。このとき、ユーザＵｘの端末装置３には、図２３（ａ）のような検索結果の画面が表示される。

ここで、さらに、ユーザＵｘが「ユーザ自身の友達またはその友達であること」という検索条件を追加したとする。すると、検索結果集約部５１７は、図２２（ｂ）のように、同一人であるユーザＳｄ、Ｔｄを接続点として、ＳＮＳ＿Ａの中から検索された各ユーザおよびＳＮＳ＿Ｂの中から検索された各ユーザの友達関係を数珠つなぎのように連結する。そして、ユーザＵｘの友達およびその友達を、さらに選出する。つまり、ユーザＳｄ（Ｔｄ）およびその友達であるユーザＳｃおよびＴｅを選出する。このとき、ユーザＵｘの端末装置３には、図２３（ｂ）のような検索結果の画面が表示される。

このように、ＳＮＳシステム２は、複数のＳＮＳに跨った友達関係をも考慮して検索を行うことができる。

〔会員の検索およびプロフィールの閲覧の応用例、発展例−スカウト検索〕
図２４はスカウト検索の例を説明するための図である。

会員の検索およびプロフィールの閲覧のサービスを、大学が開設するＳＮＳにおいて、次のように応用させ発展させることができる。

図２４において、Ｅ大学のＳＮＳ＿ＥとＦ大学のＳＮＳ＿Ｆとは、互いに信頼し合い、連携している。企業のリクルータであるユーザＵｇは、ＳＮＳ＿Ｅに正会員として登録され、かつ、ＳＮＳ＿Ｆにゲスト会員として登録されている。ただし、ユーザＵｇは、ＳＮＳ＿ＥおよびＳＮＳ＿Ｆのいずれのユーザ（つまり、学生）のプロフィールも、各大学の管理者の許可を得なければ閲覧することができない。

ユーザＵｇがインターンへの参加者を募集するために、「インターン希望」という検索条件での検索をＳＮＳ＿ＥのＳＮＳシステム２（２Ｅ）に要求すると（＃４０１）、ＳＮＳシステム２Ｅは、インターンを希望する旨の情報が含まれるプロフィール情報ＤＴ３を自らのプロフィールデータベース２Ｋ３（図５参照）の中から検索する（＃４０２）。これにより、希望者が選出される。そして、ここでは、希望者の人数を回答する（＃４０３）。プロフィール情報ＤＴ３の内容は開示しない。

ステップ＃４０２、＃４０３と前後してまたは並行して、ＳＮＳシステム２Ｅは、ＳＮＳ＿ＦのＳＮＳシステム２（２Ｆ）に、ユーザＵｇが指定した検索条件を送信する（＃４０４）。

すると、ＳＮＳシステム２Ｆも、ＳＮＳシステム２Ｅと同様に、自らのプロフィールデータベース２Ｋ３（図５参照）の中から、インターンの希望者のプロフィール情報ＤＴ３を検索する（＃４０５）。そして、人数を、ＳＮＳシステム２Ｅを介してユーザＵｇに回答する（＃４０６、＃４０７）。

ユーザＵｇは、Ｅ大学の学生をインターンの候補とするために、Ｅ大学の学生のプロフィールの閲覧を所望する場合は、Ｅ大学の管理者に対して、閲覧の許可を求める（＃４０８）。Ｅ大学の管理者は、希望者のプロフィール情報ＤＴ３ごとに、開示を許可するか否かを決める（＃４０９）。ＳＮＳシステム２Ｅは、開示を許可されたプロフィール情報ＤＴ３だけをユーザＵｇに送信する（＃４１０）。

同様に、ユーザＵｇは、Ｆ大学の学生のプロフィールの閲覧を所望する場合は、Ｆ大学の管理者に対して、閲覧の許可を求める（＃４１１）。ＳＮＳシステム２Ｆは、Ｆ大学の管理者によって開示を許可されたプロフィール情報ＤＴ３だけをユーザＵｇに送信する（＃４１２、＃４１３、＃４１４）。

その他、ＳＮＳ連携システム１、ＳＮＳシステム２の全体または各部の構成、処理内容、処理順序、データベースの構成などは、本発明の趣旨に沿って適宜変更することができる。

上に述べた実施例には、以下に述べるような付記も開示されている。
（付記１）
ネットワークを介して第一の会員に対してサービスを提供する第一のサービス提供システムと、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムと、を有し、
前記第一のサービス提供システムと前記第二のサービス提供システムとはネットワークを介して接続可能であり、
前記第一のサービス提供システムには、
検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、
前記第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、
が設けられ、
前記第二のサービス提供システムには、
前記第一のサービス提供システムから受信した前記検索条件に該当する前記第二の会員を検索する会員検索手段と、
前記会員検索手段によって検索された前記第二の会員を示す第二の会員情報を前記第一のサービス提供システムに送信する会員情報送信手段と、
が設けられ、
前記第一のサービス提供システムには、さらに、
前記第二のサービス提供システムから受信した前記第二の会員情報に基づいて、前記検索条件に該当する前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、
が設けられている、
ことを特徴とするサービス提供システムの連携システム。
（付記２）
前記第一のサービス提供システムには、
前記ユーザによって指定された前記第二の会員のプロフィールの情報を前記第二のサービス提供システムに対して要求するプロフィール情報要求手段と、
前記第二のサービス提供システムから受信した前記プロフィールの情報を前記ユーザに対して回答するプロフィール回答手段と、が設けられ、
前記第二のサービス提供システムには、
前記第一のサービス提供システムから要求された前記第二の会員の前記プロフィールの情報を、当該第二のサービス提供システムのサービスの管理者が許可した場合に当該第一のサービス提供システムに送信する、プロフィール情報送信手段と、が設けられている、
付記１記載のサービス提供システムの連携システム。
（付記３）
前記プロフィール情報要求手段は、前記ユーザが前記第二の会員の指定を所定の期間内に所定の回数以上行った場合は、前記プロフィールの情報を要求しない、
付記２記載のサービス提供システムの連携システム。
（付記４）
ネットワークを介して第一の会員に対してサービスを提供するサービス提供システムであって、
検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、
ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、
前記会員問合せ手段によって送信された前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のサービス提供システムから受信する会員情報受信手段と、
前記会員情報受信手段によって受信された前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、
を有することを特徴とするサービス提供システム。
（付記５）
前記検索条件に該当する前記第一の会員を検索する会員検索手段、を有し、
前記検索結果回答手段は、前記第二の会員とともに、前記会員検索手段によって検索された前記第一の会員を、回答する、
付記４記載のサービス提供システム。
（付記６）
前記第一の会員ごとに、当該サービス提供システムおよび前記第二のサービス提供システムにおいて共通に用いられる識別情報を記憶する、会員識別情報記憶手段、を有し、
前記会員情報受信手段は、前記第二の会員情報として、前記第二の会員とともに当該第二の会員の前記識別情報を示す情報を受信し、
前記検索結果回答手段は、前記第二の会員情報に示されるいずれかの前記第二の会員の前記識別情報と前記会員検索手段によって検索されたいずれかの前記第一の会員前記識別情報とが重複する場合は、当該第二の会員および当該第一の会員を、同一人であることを示して回答する、
付記５記載のサービス提供システム。
（付記７）
前記第一の会員ごとに、複数の項目についての当該第一の会員の情報を記憶する、会員情報記憶手段、を有し、
前記検索条件受付手段は、前記項目ごとの前記検索条件を受け付け、
前記会員検索手段は、前記項目のうちの所定の項目の前記検索条件に該当する前記第一の会員を検索する、
付記５または付記６記載のサービス提供システム。
（付記８）
前記検索結果回答手段は、前記第二の会員のニックネームを回答する、
付記５ないし付記７のいずれかに記載のサービス提供システム。
（付記９）
前記第一の会員には友達である他の第一の会員が設定されており、前記第二の会員には友達である他の第二の会員が設定されており、
前記検索結果回答手段は、前記ユーザが特定の連鎖数を指定した場合は、同一の前記識別情報を持つ前記第一の会員と前記第二の会員とが同一人であるとみなした上で、当該ユーザから当該特定の連鎖数以内の友達関係にある前記第一の会員および前記第二の会員を回答する、
付記５記載のサービス提供システム。
（付記１０）
ネットワークを介して第一の会員に対してサービスを提供する第一のサービス提供システムと、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムと、の制御方法であって、
前記第一のサービス提供システムに、
検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
前記第二のサービス提供システムに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
を実行させ、
前記第二のサービス提供システムに、
前記第一のサービス提供システムから受信した前記検索条件に該当する前記第二の会員を検索する処理と、
検索した前記第二の会員を示す第二の会員情報を前記第一のサービス提供システムに送信する処理と、
を実行させ、
さらに、前記第一のサービス提供システムに、
前記第二のサービス提供システムから受信した前記第二の会員情報に基づいて、前記検索条件に該当する前記第二の会員を前記ユーザに対して回答する処理を実行させる、
ことを特徴とするサービス提供システムの制御方法。
（付記１１）
ネットワークを介して第一の会員に対してサービスを提供するサービス提供システムの制御方法であって、
当該サービス提供システムに、
検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
送信した前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のサービス提供システムから受信する処理と、
受信した前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する処理と、
を実行させる、
ことを特徴とするサービス提供システムの制御方法。
（付記１２）
ネットワークを介して第一の会員に対してサービスを提供するコンピュータに用いられるコンピュータプログラムであって、
当該コンピュータに、
検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
ネットワークを介して第二の会員に対してサービスを提供する第二のコンピュータに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
送信した前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のコンピュータから受信する処理と、
受信した前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する処理と、を実行させる、
ことを特徴とするコンピュータプログラム。

ＳＮＳ連携システムの全体的な構成の例を示す図である。 ＳＮＳシステムの機能的構成の例を示す図である。 連携先ＳＮＳデータベースの例を示す図である。 会員情報データベースの例を示す図である。 プロフィールデータベースの例を示す図である。 ゲストＳＮＳへの会員登録の処理の流れの例を説明するフローチャートである。 検索サービス処理部の構成の例を示す図である。 検索結果提供処理部の構成の例を示す図である。 検索処理の流れの例を説明するフローチャートである。 検索条件の指定用の画面の例を示す図である。 検索条件データの例を示す図である。 重み付けの方法を説明するための図である。 検索結果データの例を示す図である。 集約処理の流れの例を説明するフローチャートである。 検索結果データの集約の例を示す図である。 検索集約結果データの変形例を示す図である。 コミュニティへの招待の依頼に関する処理の流れの例を説明するフローチャートである。 招待要求データの例を示す図である。 依頼受領通知データの例を示す図である。 プロフィールの閲覧に関する処理の流れの例を説明するフローチャートである。 ＳＮＳ＿ＡおよびＳＮＳ＿Ｂそれぞれのメンバ構成の例を示す図である。 数珠つなぎ検索の例を説明するための図である。 検索結果の画面の例を示す図である。 スカウト検索の例を説明するための図である。

符号の説明

１ ＳＮＳ連携システム（サービス提供システムの連携システム）
２ ＳＮＳシステム（サービス提供システム）
２Ａ ＳＮＳシステム（第一のサービス提供システム）
２Ｂ ＳＮＳシステム（第二のサービス提供システム）
２７１ 検索要求処理部（会員問合せ手段）
２Ｋ３ プロフィールデータベース（会員識別情報記憶手段）
５１０ 検索条件受付部（検索条件受付手段）
５１４ 検索結果受信部（会員情報受信手段）
５１５ 会員検索部（会員検索手段）
５１９ 検索結果画面送信部（検索結果回答手段）
８１３ 会員検索部（会員検索手段）
８１５ 検索結果回答部（会員情報送信手段）
ＡＣ２ 検索結果データ
ＡＦ 結果表示用データ
ＲＱ２ 検索条件データ

Claims (10)

1. ネットワークを介して第一の会員に対してサービスを提供する第一のサービス提供システムと、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムと、を有し、
   前記第一のサービス提供システムと前記第二のサービス提供システムとはネットワークを介して接続可能であり、
   前記第一のサービス提供システムには、
   検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、
   前記第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、
   が設けられ、
   前記第二のサービス提供システムには、
   前記第一のサービス提供システムから受信した前記検索条件に該当する前記第二の会員を検索する会員検索手段と、
   前記会員検索手段によって検索された前記第二の会員を示す第二の会員情報を前記第一のサービス提供システムに送信する会員情報送信手段と、
   が設けられ、
   前記第一のサービス提供システムには、さらに、
   前記第二のサービス提供システムから受信した前記第二の会員情報に基づいて、前記検索条件に該当する前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、
   が設けられている、
   ことを特徴とするサービス提供システムの連携システム。
2. ネットワークを介して第一の会員に対してサービスを提供するサービス提供システムであって、
   検索条件を前記第一の会員の１人であるユーザから受け付ける検索条件受付手段と、
   ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムに対して、前記検索条件受付手段によって受け付けられた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる、会員問合せ手段と、
   前記会員問合せ手段によって送信された前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のサービス提供システムから受信する会員情報受信手段と、
   前記会員情報受信手段によって受信された前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する、検索結果回答手段と、
   を有することを特徴とするサービス提供システム。
3. 前記検索条件に該当する前記第一の会員を検索する会員検索手段、を有し、
   前記検索結果回答手段は、前記第二の会員とともに、前記会員検索手段によって検索された前記第一の会員を、回答する、
   請求項２記載のサービス提供システム。
4. 前記第一の会員ごとに、当該サービス提供システムおよび前記第二のサービス提供システムにおいて共通に用いられる識別情報を記憶する、会員識別情報記憶手段、を有し、
   前記会員情報受信手段は、前記第二の会員情報として、前記第二の会員とともに当該第二の会員の前記識別情報を示す情報を受信し、
   前記検索結果回答手段は、前記第二の会員情報に示されるいずれかの前記第二の会員の前記識別情報と前記会員検索手段によって検索されたいずれかの前記第一の会員前記識別情報とが重複する場合は、当該第二の会員および当該第一の会員を、同一人であることを示して回答する、
   請求項３記載のサービス提供システム。
5. 前記第一の会員ごとに、複数の項目についての当該第一の会員の情報を記憶する、会員情報記憶手段、を有し、
   前記検索条件受付手段は、前記項目ごとの前記検索条件を受け付け、
   前記会員検索手段は、前記項目のうちの所定の項目の前記検索条件に該当する前記第一の会員を検索する、
   請求項３または請求項４記載のサービス提供システム。
6. 前記検索結果回答手段は、前記第二の会員のニックネームを回答する、
   請求項３ないし請求項５のいずれかに記載のサービス提供システム。
7. 前記第一の会員には友達である他の第一の会員が設定されており、前記第二の会員には友達である他の第二の会員が設定されており、
   前記検索結果回答手段は、前記ユーザが特定の連鎖数を指定した場合は、同一の前記識別情報を持つ前記第一の会員と前記第二の会員とが同一人であるとみなした上で、当該ユーザから当該特定の連鎖数以内の友達関係にある前記第一の会員および前記第二の会員を回答する、
   請求項３記載のサービス提供システム。
8. ネットワークを介して第一の会員に対してサービスを提供する第一のサービス提供システムと、ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムと、の制御方法であって、
   前記第一のサービス提供システムに、
   検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
   前記第二のサービス提供システムに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
   を実行させ、
   前記第二のサービス提供システムに、
   前記第一のサービス提供システムから受信した前記検索条件に該当する前記第二の会員を検索する処理と、
   検索した前記第二の会員を示す第二の会員情報を前記第一のサービス提供システムに送信する処理と、
   を実行させ、
   さらに、前記第一のサービス提供システムに、
   前記第二のサービス提供システムから受信した前記第二の会員情報に基づいて、前記検索条件に該当する前記第二の会員を前記ユーザに対して回答する処理を実行させる、
   ことを特徴とするサービス提供システムの制御方法。
9. ネットワークを介して第一の会員に対してサービスを提供するサービス提供システムの制御方法であって、
   当該サービス提供システムに、
   検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
   ネットワークを介して第二の会員に対してサービスを提供する第二のサービス提供システムに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
   送信した前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のサービス提供システムから受信する処理と、
   受信した前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する処理と、
   を実行させる、
   ことを特徴とするサービス提供システムの制御方法。
10. ネットワークを介して第一の会員に対してサービスを提供するコンピュータに用いられるコンピュータプログラムであって、
    当該コンピュータに、
    検索条件を前記第一の会員の１人であるユーザから受け付ける処理と、
    ネットワークを介して第二の会員に対してサービスを提供する第二のコンピュータに対して、受け付けた前記検索条件を送信することによって、当該検索条件に該当する前記第二の会員を問い合せる処理と、
    送信した前記検索条件に該当する前記第二の会員を示す第二の会員情報を前記第二のコンピュータから受信する処理と、
    受信した前記第二の会員情報に示される前記第二の会員を前記ユーザに対して回答する処理と、を実行させる、
    ことを特徴とするコンピュータプログラム。

Images