JP2011081670A - 個人情報管理システム - Google Patents

Abstract

【課題】適切な相手との間でのみ、フレンド関係の申請・構築等が可能な個人情報管理システムを提供する。
【解決手段】顧客管理サーバは、（１）両ユーザＡ、Ｂが既登録ユーザで、かつ、お互いの電話帳にお互いの個人情報が登録されている場合、（２）両ユーザＡ、Ｂが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢの電話帳にはユーザＡの個人情報が登録されていない場合、（３）ユーザＡのみが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢは未登録ユーザの場合に、両ユーザＡ、Ｂの間でフレンド関係の構築を可能とする。
【選択図】図１

Description

本発明は、個人情報管理システムなどに関し、特に、ソーシャルネットワークを利用する登録ユーザの個人情報を適切に管理する個人情報管理システムなどに関する。

近年、社会的ネットワークをインターネットなどの通信ネットワーク上で構築するソーシャルネットワークサービス（Social Network Service）が広く普及している。ソーシャルネットワークサービスは、参加者が互いに友人を紹介しあって新たな友人関係を広げることを目的としており、その多くは既存の参加者からの招待がないと、ソーシャルネットワークに参加できない方式を採用している。

このようなソーシャルネットワークサービスとしては、例えば、「ｏｒｋｕｔ」（例えば、非特許文献１参照）や「ｇｒｅｅ」（例えば、非特許文献２参照）と呼ばれるサーバ集中型のサービスが知られている。

ここで、ソーシャルネットワークが構築されていく手順について説明する。先ず、ある人が、あるソーシャルネットワークの既存の参加者（ユーザ）である親しい人から紹介される形で、そのソーシャルネットワークに招待される。次に、ソーシャルネットワークに招待された人が、自分の個人情報を登録することでそのソーシャルネットワークに参加する。さらに、ソーシャルネットワークに招待されて新たに参加した人が、別の親しい友人を紹介する形でそのソーシャルネットワークに招待する。このような各段階が繰り返されることで、自身と直接関係のない他人との繋がりを通じて新たな人間関係が構築される。なお、ソーシャルネットワークに登録したユーザは、あらかじめ用意されたフォーマットに自己のプロフィールを入力することによって自己紹介を行う一方、いったんソーシャルネットワークに登録されると、既に登録された全てのユーザについて、ニックネームなどによる検索（ニックネーム検索）などが可能となる。

ところで、多くのソーシャルネットワークサービスは、フレンド関係構築機能が備えられている。「フレンド関係構築機能」とは、ソーシャルネットワークへの一連の招待作業が終わった後に、そのソーシャルネットワークの中から友達関係（フレンド関係）を構築したい相手を、ニックネーム検索などで探し、その相手にフレンド関係の申請を行い、承認などを得ることでフレンド関係を構築する機能である。この機能により、ソーシャルネットワークサービスを利用するユーザは自身と直接関係のない他人との間に、新たにフレンド関係を構築してゆくことが可能となる。

"ｏｒｋｕｔ ｗｅｂ ｓｉｔｅ"、［ｏｎｌｉｎｅ］、［平成２１年９月２７日検索］、インターネット＜ＵＲＬ：http://www.orkut.com＞ "ｇｒｅｅ ｗｅｂ ｓｉｔｅ"、［ｏｎｌｉｎｅ］、［平成２１年９月２７日検索］、インターネット＜ＵＲＬ：http://www.gree.jp＞

しかしながら、従来のフレンド関係構築機能は、いったんソーシャルネットワークサービスに登録すると、自身と直接関係のない他人から、突然、フレンド関係の申請を受けることがある。

申請を受けたユーザは、相手のプロフィールなどを確認して申請を拒否することも可能であるが、人間の心理として無碍に許否することは後味が悪いものである。そうであるとはいえ、自身に直接関係のない他人とフレンド関係を結んでしまうと、自身の詳細なプロフィールなど、本来他人には見せたくない情報までフレンド間で共有することになってしまう、等の問題があった。

本発明は、以上説明した事情を鑑みてなされたものであり、適切な相手との間でのみ、フレンド関係の申請・構築等が可能な個人情報管理システムを提供することを目的とする。

本発明に係る個人情報管理システムは、電話帳を備えた複数の通信端末と、各通信端末の電話帳に登録されているユーザの個人情報を管理する個人情報管理サーバとを備えた個人情報管理システムであって、前記通信端末は、当該通信端末の所有者に関わるオーナー情報を含む複数人の個人情報を登録した電話帳を記憶するメモリと、電話帳に登録されているユーザにフレンド申請を行うための入力を行う入力手段と、前記ユーザの個人情報を含めて前記入力されたフレンド申請を前記個人情報管理サーバに送信する送信手段と、を備え、前記個人情報管理サーバは、前記各通信端末の所有者に関わるオーナー情報を記憶する第１記憶手段と、前記オーナー情報の開示を相互に許可するフレンド関係にある前記両所有者を特定するフレンド関係情報を記憶する第２記憶手段と、前記フレンド申請に含まれる前記ユーザの個人情報と一致する前記オーナー情報が、前記第１記憶手段に記憶されているか否かを判断する第１判断手段と、前記第１判断手段によって前記オーナー情報が記憶されていると判断された場合には、前記フレンド申請先となる他のユーザの通信端末にアクセスする第１アクセス手段と、前記フレンド申請元のユーザのオーナー情報を検索キーとして前記他のユーザの通信端末の電話帳を検索することにより、前記フレンド申請元のユーザの個人情報が前記他のユーザの電話帳に登録されているか否かを判断する第２判断手段と、前記第２判断手段によって前記他のユーザの電話帳に登録されていると判断された場合には、前記フレンド関係情報として、前記フレンド申請元であるユーザと前記フレンド申請先である他のユーザとを特定する情報を、前記第２記憶手段に記憶する、第１登録手段とを備えることを特徴とする。

かかる構成によれば、フレンド申請元のユーザとフレンド申請先のユーザが既登録ユーザで、かつ、お互いの電話帳にお互いの個人情報が登録されている場合に、フレンド関係の構築が可能となるため、従来の如く、自身が直接関係ない他人から、突然フレンド関係の申請がなされてしまう等の問題を未然に防ぐことが可能となる。

以上説明したように、本発明によれば、適切な相手との間でのみ、フレンド関係の申請・構築等が可能となる。

本実施形態に係るソーシャルネットワークサービスにおいて利用される顧客管理システムのアーキテクチャを示す図である。 同実施形態に係るユーザ登録処理のシーケンスを示す図である。 同実施形態に係る通信端末に表示される入力画面を例示した図である。 同実施形態に係る顧客データベースの登録内容を例示した図である。 同実施形態に係る第１のパターンのフレンド関係構築処理のシーケンスを示す図である。 同実施形態に係る第１のパターンの変形例１のフレンド関係構築処理のシーケンスを示す図である。 同実施形態に係る第１のパターンの変形例２のフレンド関係構築処理のシーケンスを示す図である。 同実施形態に係る第２のパターンのフレンド関係構築処理のシーケンスを示す図である。 同実施形態の変形例に係る第２のパターンのフレンド関係構築処理のシーケンスを示す図である。 同実施形態に係る第３のパターンのフレンド関係構築処理のシーケンスを示す図である。

以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。

Ａ．本実施形態
（１）実施形態の構成
図１は、本実施形態に係るソーシャルネットワークサービスにおいて利用される顧客管理システム１００のアーキテクチャを示す図である。顧客管理システム１００は、Ｗｅｂ上に設けられた顧客管理サーバ２００と、通信ネットワーク（インターネットなど）４００を介して顧客管理サーバ２００との間でデータを授受することが可能な複数の通信端末３００−ｋ（ｋ≧２）とを備えて構成される。なお、以下の説明では、各通信端末を特に区別する必要がない場合には、単に通信端末３００と呼ぶ。

通信端末３００は、メール機能や、インターネット接続機能等を備えた携帯電話、ＰＨＳ（Personal Handyphone System）、ＰＤＡ（Personal Digital Assistance）等であり、ＣＰＵ、メモリ、通信装置（送信手段）、操作ボタンやタッチパネルなどの入力装置（入力手段）、ＬＣＤなどの表示装置といったハードウェア資源を備えている。通信端末３００は、インターネット４００に接続された顧客管理サーバ２００にアクセスしてユーザ自身の個人情報を登録することが可能となっている。また、通信端末３００のメモリ３１０には電話帳が保存され、この電話帳には、当該端末を所持するユーザ（すなわちオーナー）自身の個人情報のほか、家族や友人、会社の同僚や付き合いのある顧客など、他人の個人情報も登録されている。なお、本実施形態では、通信端末として携帯電話などを想定するが、インターネット等の通信ネットワークを介して顧客管理サーバ２００にアクセス可能なパーソナルコンピュータなどにも適用可能である。

顧客管理サーバ２００は、サーバコンピュータなどによって構成され、ソーシャルネットワークサービスを利用するユーザ（すなわち、登録ユーザ）について、顧客データベースＤＢ１に格納される登録ユーザ自身の個人情報を管理するほか、登録ユーザ同士のフレンド関係をあらわすフレンド関係情報（例えば登録ユーザＡと登録ユーザＢはフレンド関係にあるなど；詳細は後述）などを管理する役割などを担っている。

顧客管理サーバ２００は、当該サーバを構成する各ハードウェア資源がメモリに格納されたソフトウェアと協働して動作することにより、以下に示す顧客管理手段２１０、フレンド関係管理手段２２０の機能を実現する。

顧客情報管理手段２１０は、ユーザが本システムを利用する際に必要となるＩＤ、パスワードなどアカウント情報や、本システムを利用する登録ユーザ自身の個人情報（例えば住所、電話番号、メールアドレス、ニックネームなど）を、顧客データベースＤＢ１に登録・管理する手段である。

フレンド関係管理手段２２０は、登録ユーザ間でのフレンド関係の構築をサポートするとともに、フレンド関係をあらわす情報（フレンド関係にある登録ユーザ同士の対応関係をあらわす情報；以下、フレンド関係情報）を顧客データベースＤＢ１に登録・管理する手段である。なお、フレンド関係とは、自身の個人情報の開示を相互に許可する登録ユーザ間の関係をいう。

（２）実施形態の動作
以下、新規ユーザが顧客管理サーバ２００に登録する処理（以下、ユーザ登録処理）について説明した後、本発明の特徴部分である登録ユーザ間でフレンド関係を構築する処理（フレンド関係構築処理）について、図面を参照しながら説明する。

＜ユーザ登録処理＞
図２は、ユーザ登録処理のシーケンスを示す図である。
顧客管理システム１００の利用を所望するユーザＡは、自身の通信端末３００−１に顧客管理サーバ２００のアドレスなどを入力することで顧客管理サーバ２００にアクセスし、ユーザ登録の要求を行う（ステップＳ１０）。顧客管理サーバ２００は、かかる要求を受けとると、ユーザ登録に必要な情報を入力すべき指示を通信端末３００−１に送る（ステップＳ２０）。

図３は、通信端末３００−１に表示される入力画面を例示した図である。
ユーザは、図３に示す入力画面に指示に従ってＩＤやパスワードなど、登録ユーザの認証に必要なアカウント情報を設定するとともに、名前、住所、電話番号、メールアドレス、ニックネームなど、ユーザ自身の個人情報（以下、オーナー情報）を設定する（ステップＳ３０）。なお、オーナー情報は、ユーザ自身の個人情報をあらわすものであれば、どのような情報であっても良く、その種類や数も特に限定されない。

通信端末３００−１は、ユーザによって設定されたアカウント情報及オーナー情報をメモリ３１０に格納するとともに、顧客管理サーバ２００へ送信する（ステップＳ４０）。顧客管理サーバ２００の顧客管理手段２１０は、通信端末３００−１からアカウント情報及びオーナー情報を受け取ると、受け取ったアカウント情報及びオーナー情報をユーザごとに、顧客データベースＤＢ１に格納する（ステップＳ５０）。

図４は、顧客データベースＤＢ１の登録内容を例示した図である。
図４に示すように、顧客データベースＤＢ１には、登録ユーザごとに、アカウント情報とオーナー情報とフレンド関係情報とが対応づけられて登録されている。なお、新規登録ユーザの場合など、未だ何れの登録ユーザともフレンド関係が構築されていない場合には、フレンド関係情報は顧客データベースＤＢ１に登録されない。また、フレンド関係情報については、登録ユーザごとではなく、全登録ユーザのフレンド関係をあらわすテーブルを別途顧客データベースＤＢ１に登録しても良い。

顧客管理サーバ２００は、顧客データベース（第1記憶手段）ＤＢ１へのアカウント情報及びオーナー情報の登録が終了すると、通信端末３００−１に新規ユーザ登録が終了した旨を通知し（ステップＳ６０）、ユーザ登録処理を終了する。このように、顧客データベースＤＢ１には、登録ユーザごとに、アカウント情報と登録ユーザの個人情報（すなわちオーナー情報）とフレンド情報が登録されのみであり、登録ユーザの電話帳に記録されている他人の個人情報については顧客データベースＤＢ１に登録されない。別言すれば、自分以外の他のユーザ（未登録、既登録を問わず）の個人情報については、顧客データベースＤＢ１に登録されないため、顧客管理サーバ２００への不正アクセスにより、他のユーザの個人情報が流出してしまうといった問題を未然に防止することが可能となる。

＜フレンド関係構築処理＞
以下、ユーザＡとユーザＢがフレンド関係を構築する場合について、複数のパターンを例示ながら説明する。なお、フレンド関係は１対１に限らず、１対多数（例えばユーザＡ対ユーザＢ、ユーザＣ、ユーザＤ・・・など）の場合にも適用可能である。また、以下の説明で「アクセスする」とは、メールなどによる通知も含む概念をあらわすものとする。

ア サーバ主導型
ア−１ 両ユーザＡ、Ｂが既登録ユーザで、かつ、お互いの電話帳にお互いの個人情報が登録されている場合（第１のパターン）

図５Ａは、第１のパターン（パターン１）のフレンド関係構築処理のシーケンスを示す図である。
ユーザＡは、自身の通信端末３００−１を操作し、アカウント情報を入力するなどして顧客管理サーバ２００にアクセスすることで、通信端末３００−１と顧客管理サーバ２００との間の通信を確立する（ステップＳ１１０→ステップＳ１２０）。顧客管理サーバ２００は、通信端末３００−１との通信が確立すると、各通信端末３００−１のメモリ３１０にアクセスし、ユーザＡの電話帳に登録されている他人（家族や友人、同僚など）の個人情報を吸い上げる（ステップＳ１３０）。

そして、顧客管理サーバ２００のフレンド関係管理手段（第１判断手段）２２０は、吸い上げた個人情報と、顧客データベース（第１記憶手段）ＤＢ１に登録されている全オーナー情報とのつきあわせ（照合）を行うことで、顧客データベースＤＢ１にフレンド申請先のユーザ（ここではユーザＢ）のオーナー情報が登録されているか否かを判断する（ステップＳ１４０）。顧客データベースＤＢ１にフレンド申請先のユーザＢのオーナー情報が登録されていない場合には（ステップＳ１４０；ＮＯ）、後述するパターン３のステップＳ５６０に移行する（図８参照）。

ただし、ここでは、ユーザＡの通信端末３００−１から吸い上げた個人情報は、ユーザＢ、ユーザＣの個人情報であるのに対し、顧客データベースＤＢ１にオーナー情報として登録されていたのは、ユーザＢ、ユーザＣであり（すなわち、両ユーザＢ、Ｃとも既登録ユーザ）、顧客データベースＤＢ１にフレンド情報として登録されていたのは、ユーザＣのみであったとする（すなわち、現時点でユーザＡとフレンド関係にあるのはユーザＣのみ）。

よって、フレンド関係管理手段（第1アクセス手段）２２０は、顧客データベースＤＢ１にフレンド申請先のユーザＢのオーナー情報が登録されていると判断すると（ステップＳ１４０；ＹＥＳ）、ユーザＡとユーザＢはフレンド関係の構築の可能性があると判断し、まず、ユーザＢの通信端末３００−２にアクセスする（ステップＳ１５０）。フレンド関係管理手段２２０は、通信端末３００−２との通信が確立すると（ステップＳ１６０）、通信端末３００−２のメモリ３２０にアクセスし、ユーザＢの電話帳に登録されている個人情報を吸い上げる（ステップＳ１７０）。

そして、フレンド関係管理手段（第2判断手段）２２０は、ユーザＢの電話帳から吸い上げた個人情報にユーザＡの個人情報があるか否かを判断する（ステップＳ１８０）。フレンド関係管理手段２２０は、ユーザＢの電話帳にユーザＡの個人情報が登録されていないと判断した場合には（ステップＳ１８０；ＮＯ）、後述するパターン２のステップＳ４００に移行する（図６参照）。

一方、フレンド関係管理手段２２０は、ユーザＢの電話帳にユーザＡの個人情報が登録されていると判断すると（ステップＳ１８０；ＹＥＳ）、既登録ユーザＡ、Ｂについては、相互の電話帳に相互の個人情報が登録されていることを認識する（ステップＳ１９０）。このように、相互の電話帳に相互の個人情報が登録されている場合には、フレンド関係管理手段２２０は、ユーザＡとユーザＢはフレンド関係を構築できると判断し、ユーザＡの通信端末３００−１、ユーザＢの通信端末３００−２に対して、ユーザＡ、Ｂ間でフレンド関係の構築を促すメッセージを通知する（ステップＳ２００）。

一例を挙げて説明すると、フレンド関係管理手段２２０は、ユーザＡの通信端末３００−１に対しては「ユーザＢとの間でフレンド関係が構築できます。ユーザＢとのフレンド関係を承認しますか？」といった文字メッセージを通知する一方、ユーザＢの通信端末３００−２に対しても、同種の文字メッセージ、例えば「ユーザＡとの間でフレンド関係が構築できます。ユーザＡとのフレンド関係を承認しますか？」といった文字メッセージを通知する。

ユーザＡ、Ｂは、それぞれ文字メッセージを確認した後、通信端末３００−１、３００−２を適宜操作してフレンド関係を承認する旨を入力する（ステップＳ２１０、ステップＳ２２０）。かかる操作がなされると、その旨がフレンド関係管理手段２２０に通知される。フレンド関係管理手段（第1登録手段）２２０は、この通知を受け、顧客データベース（第2記憶手段）ＤＢ１のユーザＡのフレンド情報としてユーザＢを追加するとともに、ユーザＢのフレンド情報としてユーザＡを追加する（ステップＳ２２０）。

フレンド関係管理手段２２０は、このようにしてユーザＡとユーザＢとの間で新たなフレンド関係を構築すると、通信端末３００−１、３００−２に対して新たなフレンド関係が構築された旨のメッセージ（例えば「ユーザＡさんとユーザＢさんとの間で、フレンド関係が新たに構築されました。」）を送り（ステップＳ２４０）、処理を終了する。

以上説明したように、本パターンの場合には、両ユーザＡ、Ｂが既登録ユーザで、かつ、お互いの電話帳にお互いの個人情報が登録されている場合にフレンド関係の構築が可能となる。よって、といった自身が直接関係ない他人から、突然フレンド関係の申請がなされてしまう等の問題を未然に防ぐことが可能となる。

＜変形例１＞
また、既登録ユーザＡが自身の電話帳に、ユーザＢを追加する場合にも適用可能である。なお、以下の説明では、ユーザＢは既登録ユーザである場合を想定するが、未登録ユーザである場合も同様に適用可能である。

図５Ｂは、変形例１に係る第１パターンのフレンド関係構築処理のシーケンスを示す図であり、図５Ａと対応するステップには同一符号を付し、詳細な説明を割愛する。
ユーザＡは、通信端末３００−１を操作し、ユーザＢの個人情報（例えば、名前や電話番号など）を自分の電話帳に新たに登録すると（ステップＳ１１０ａ）、通信端末３００−１は顧客サーバ２００にアクセスし、顧客管理サーバ２００との間の通信を確立する（ステップＳ１１０ａ→ステップＳ１２０）。顧客管理サーバ２００のフレンド関係管理手段２２０は、通信端末３００−１との通信が確立すると、新たに登録されたユーザＢの個人情報を検索キーとして顧客データベースを検索することにより、ユーザＢのオーナー情報が登録されているか否かを判断する（ステップＳ１４０）。なお、この後の動作については、パターン１の場合と同様に説明することができるため、割愛する。このように、既登録ユーザが自身の電話帳に、新たなユーザの個人情報を追加したタイミングで、フレンド関係の構築を行うようにしても良い。

＜変形例２＞
図５Ｃは、変形例２に係る第１パターンのフレンド関係構築処理のシーケンスを示す図であり、図５Ｂと対応するステップには同一符号を付し、詳細な説明を割愛する。
顧客管理サーバ２００のフレンド関係管理手段２２０は、通信端末３００−１との通信が確立すると、新たに登録されたユーザＢの個人情報を検索キーとして顧客データベースＤＢ１を検索することにより、ユーザＢのオーナー情報が登録されているか否かを判断する（ステップＳ１４０）。フレンド関係管理手段２２０は、ユーザＢのオーナー情報が顧客データベースＤＢ１に登録されていると判断すると、ユーザＢに対して既登録ユーザであることをユーザＡに通知して良いか否かを問い合わせるメッセージ（通知許可判断メッセージ）を通信端末３００−２に送る（ステップＳ１４０ａ）。ユーザＢは、通信端末３００−２の表示装置などに表示される通知許可メッセージの内容を確認し、自身（すなわちユーザＢ）が既登録ユーザであることをユーザＡに通知しても良い旨の入力操作（許可同意操作）を行う（ステップＳ１４０ｂ）。フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２から許可同意操作をあらわすメッセージを受け取ると、ユーザＡの通信端末３００−１にユーザＢが既登録ユーザである旨のメッセージ（例えば「フレンド申請先のユーザＢさんは、既登録ユーザです。」）を送った後（ステップＳ１４０ｃ）、ステップＳ１５０に進む。なお、この後の動作については、パターン１の場合と同様に説明することができるため、割愛する。

＜変形例３＞
上記第１のパターンでは、両ユーザＡ、Ｂが既登録ユーザである場合を例に説明したが、いずれか一方のユーザ（例えばユーザＡ）が新規登録ユーザの場合にも同様に適用可能である。かかる場合には、新規登録のタイミングでフレンド関係を構築しても良い。

例えば、ユーザＡが新規登録する場合には、顧客情報管理手段２１０がユーザＡの個人情報（オーナー情報）などを顧客データベースＤＢ１に登録するとともに、フレンド関係管理手段２２０が通信端末３００−１のメモリ３１０にアクセスし、ユーザＡの電話帳に登録されている他人（家族や友人、同僚など）の個人情報を吸い上げる。

そして、フレンド関係管理手段２２０は、吸い上げた個人情報と、顧客データベースＤＢ１に登録されている全オーナー情報とのつきあわせ（照合）を行うことで、顧客データベースＤＢ１にフレンド申請先のユーザ（ここではユーザＢ）のオーナー情報が登録されているか否かを判断する。なお、この後の動作については、上記第１のパターンと同様に説明することができるため、これ以上の説明は割愛する。

イ ユーザ主導型
イ−１ 両ユーザＡ、Ｂが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢの電話帳にはユーザＡの個人情報が登録されていない場合（第２のパターン）

図６は、第２のパターン（パターン２）のフレンド関係構築処理のシーケンスを示す図である。
ユーザＢとのフレンド関係を所望するユーザＡは、まず、自身の通信端末３００−１を操作して顧客管理サーバ２００にアクセスすることで、通信端末３００−１と顧客管理サーバ２００との間の通信を確立する（ステップＳ３１０→ステップＳ３２０）。ユーザＢは、自身の通信端末３００−１を操作することで、ユーザＢとのフレンド関係の構築を希望する旨（以下、フレンド申請情報）の入力を行う（ステップＳ３３０）。なお、フレンド申請情報には、フレンド対象となるユーザＢを特定するための情報（例えば、名前や電話番号など；以下、フレンド対象情報）が含まれる。

かかる操作がなされると、ユーザＡのフレンド申請情報が通信端末３００−１から顧客管理サーバ２００へ送信される。顧客管理サーバ２００のフレンド関係管理手段２２０は、通信端末３００−１からのユーザＡのフレンド申請情報を検索キーとして、顧客データベースＤＢ１を検索する（ステップＳ３４０）。具体的には、フレンド関係管理手段２２０は、ユーザＡのフレンド申請情報に含まれるフレンド対象情報（ここでは、例えばユーザＢの名前や電話番号、メールアドレスなど）を検索キーとして、顧客データベースＤＢ１を検索することにより、顧客データベースＤＢ１にユーザＢのオーナー情報が登録されているか否かを判断する（ステップＳ３５０）。ここで、顧客データベースＤＢ１にフレンド申請先のユーザＢのオーナー情報が登録されていないと判断すると（ステップＳ３５０；ＮＯ）、フレンド関係管理手段２２０は、後述するパターン３のステップＳ５６０に移行する。

ただし、ここでは上述したパターン１と同じように、ユーザＡの通信端末３００−１から吸い上げた個人情報がユーザＢ、ユーザＣの個人情報であるのに対し、顧客データベースＤＢ１にオーナー情報として登録されていたのは、ユーザＢ、ユーザＣであり（すなわち、両ユーザＢ、Ｃとも既登録ユーザ）、顧客データベースＤＢ１にフレンド情報として登録されていたのは、ユーザＣのみであったとする（すなわち、現時点でユーザＡとフレンド関係にあるのはユーザＣのみ）。

この場合、フレンド関係管理手段２２０は、フレンド申請先のユーザＢのオーナー情報はすでに顧客データベースＤＢ１に登録されていることから、ユーザＡとユーザＢはフレンド関係の構築の可能性があると判断し、まず、ユーザＢの通信端末３００−２にアクセスする（ステップＳ３６０）。フレンド関係管理手段２２０は、通信端末３００−２との通信が確立すると（ステップＳ３７０）、通信端末３００−２のメモリ３２０にアクセスし、ユーザＢの電話帳に登録されている個人情報を吸い上げる（ステップＳ３８０）。そして、フレンド関係管理手段２２０は、ユーザＢの電話帳から吸い上げた個人情報にユーザＡの個人情報があるか否かを判断する（ステップＳ３９０）。吸い上げた個人情報にユーザＡの個人情報がある場合には（ステップＳ３９０；ＹＥＳ）、上述したパターン１のステップＳ１９０に移行する（図５参照）。

ただし、本実施例ではユーザＢの電話帳にはユーザＡの個人情報は登録されていない。この場合、フレンド関係管理手段（第1通知手段）２２０は、ユーザＡからフレンド申請があった旨（例えば、「ユーザＢさん、ユーザＡさんからフレンド申請の要求がありました。承諾しますか？」）およびフレンド申請を受け付けるか否かの入力を促すメッセージ（例えば、「承諾する場合には「ＹＥＳ」、許否する場合には「ＮＯ」を入力してください。」）を、通信端末３００−２へ送信する（ステップＳ４００）。

一方、ユーザＢは、通信端末３００−２の表示装置に表示される内容を把握し、ユーザＡからのフレンド申請の要求を承諾する旨の入力操作を行う（ステップＳ４１０）。かかる操作がなされると、通信端末３００−２は、顧客管理サーバ２００にフレンド申請の要求を承諾する旨の応答を返す。

顧客管理サーバ２００のフレンド関係管理手段２２０は、通信端末３００−２からの応答を受け取ると、通信端末３００−１に対してフレンド申請が受け付けられた旨のメッセージ（例えば「ユーザＡさん、ユーザＢさんによってフレンド申請は承諾されました。」）を送る（ステップＳ４２０）。

さらに、フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２の電話帳にユーザＡの個人情報を登録するべく、ユーザＢの通信端末３００−２にアクセスし、ユーザＢの電話帳にユーザＡの個人情報を書き込む（ステップＳ４３０）。かかる処理が終了すると、フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２に対してユーザＡとのフレンド関係の構築が完了した旨のメッセージ（例えば、「ユーザＡとのフレンド関係が構築されました。」）、及びユーザＡの個人情報が電話帳に新たに登録された旨のメッセージ（例えば、「ユーザＡの個人情報を新たに追加いたしました。」）を送る（ステップＳ４４０）。

最後に、フレンド関係管理手段（第2登録手段）２２０は、顧客データベース（第2記憶手段）ＤＢ１にアクセスし、登録ユーザＡのフレンド情報として「登録ユーザＢ」、登録ユーザＢのフレンド情報として「登録ユーザＡ」をそれぞれ登録する（ステップＳ４５０）。

以上説明したように、本パターンの場合には、両ユーザＡ、Ｂが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢの電話帳にはユーザＡの個人情報が登録されていない場合にフレンド関係の構築が可能となる。このような場合であっても、ユーザＡの電話帳にユーザＢの個人情報が登録されていることが前提（すなわち、ユーザＡはユーザＢの個人情報を知っていることが前提）となっているため、本パターンにおいても、自身が直接関係ない他人から、突然フレンド関係の申請がなされてしまう等の問題を未然に防ぐことが可能となる。

＜変形例１＞
ユーザＢが登録ユーザであることを、ユーザＡに教えて良いか否かを確認しても良い。
図７は、変形例１に係る第２パターンのフレンド関係構築処理のシーケンスを示す図である。なお、図６と対応するステップには同一符号を付し、詳細な説明を割愛する。

フレンド関係管理手段２２０は、顧客データベースＤＢ１に登録されている全オーナー情報とのつきあわせ（照合）を行った結果、ユーザＢが登録ユーザであると判断すると（ステップＳ３５０；ＹＥＳ）、まず、ユーザＢの通信端末３００−２にアクセスし、通信端末３００−２と顧客管理サーバ２００との間で通信を確立する（ステップＳ３６０→ステップＳ３７０）。

そして、フレンド関係管理手段２２０は、ユーザＡに対してユーザＢが既登録ユーザである旨を教えて良いかを確認する文字メッセージ（例えば「あなた（ユーザＢ）が既登録ユーザであることをユーザＡさんに教えても良いですか？」）を、通信端末３００−２に送る（ステップＳ３６０ａ）。その後、ユーザＢが通信端末３００−２を利用して既登録ユーザであることを教えて良い旨の入力操作を行うと（ステップＳ３６０ｂ）、その旨がフレンド関係管理手段２２０に通知される。

フレンド関係管理手段２２０は、この通知を受け取ると、ユーザＡの通信端末３００−１にアクセスし、フレンド申請中のユーザＢは既登録ユーザである旨の文字メッセージ（例えば「現在、フレンド申請中のユーザＢさんは既登録ユーザです。」）を送り（ステップＳ３６０ｃ）、ステップＳ３８０に進む。ユーザＡは、通信端末３００−１の表示装置に表示されるこの文字メッセージを確認することで、フレンド申請中のユーザＢがユーザＡと同じく、既登録ユーザであることを知る。なお、ステップＳ３８０に進んだ後の動作は、本実施形態のパターン２と同様であるため、説明を割愛する。

また、ユーザＢが既登録ユーザであることを教えたくない旨の入力操作（例えば、ユーザＡとのフレンド関係の構築を望まない場合など）を行った場合には、フレンド関係管理手段２２０は、ユーザＡに対してユーザＢが既登録ユーザであることを知らせることはない。

このように、フレンド申請されたユーザＢが既登録ユーザであるか、未登録ユーザであるかの情報は、ユーザＢの承認なしにユーザＡに開示しないように構成しても良い。

イ ユーザ主導型
イ−２ ユーザＡのみが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢは未登録ユーザの場合（第３のパターン）

図８は、第３のパターン（パターン３）のフレンド関係構築処理のシーケンスを示す図である。
ユーザＢとのフレンド関係を所望するユーザＡは、まず、自身の通信端末３００−１を操作して顧客管理サーバ２００にアクセスすることで、通信端末３００−１と顧客管理サーバ２００との間の通信を確立する（ステップＳ５１０→ステップＳ５２０）。ユーザＡは、自身の通信端末３００−１を操作することで、ユーザＢとのフレンド関係の構築を希望する旨（以下、フレンド申請情報）の入力を行う（ステップＳ５３０）。なお、フレンド申請情報には、フレンド対象となるユーザＢを特定するための情報（例えば、名前や電話番号など；以下、フレンド対象情報）が含まれる。

かかる操作がなされると、ユーザＡのフレンド申請情報が通信端末３００−１から顧客管理サーバ２００へ送信される。顧客管理サーバ２００のフレンド関係管理手段２２０は、通信端末３００−１からのユーザＡのフレンド申請情報を検索キーとして、顧客データベースＤＢ１を検索する（ステップＳ５４０）。具体的には、フレンド関係管理手段２２０は、ユーザＡのフレンド申請情報に含まれるフレンド対象情報（ここでは、例えばユーザＢの名前や電話番号、メールアドレスなど）を検索キーとして、顧客データベースＤＢ１を検索することにより、顧客データベースＤＢ１にユーザＢのオーナー情報が登録されているか否かを判断する（ステップＳ５５０）。顧客データベースＤＢ１にユーザのオーナー情報が登録されている場合には、上述したパターン２のステップＳ３５０か（図６参照）、パターン１のステップ１５０に進む（図５Ａ参照）。

ただし、ここでは、ユーザＡの通信端末３００−１から吸い上げた個人情報は、ユーザＢ、ユーザＣの個人情報であるのに対し、顧客データベースＤＢ１にオーナー情報として登録されていたのはユーザＣのみであり（すなわち、ユーザＣのみ既登録ユーザ）、顧客データベースＤＢ１にフレンド情報として登録されていたのもユーザＣのみであったとする（すなわち、現時点でユーザＡとフレンド関係にあるのはユーザＣのみ）。

よって、フレンド関係管理手段２２０は、顧客データベースＤＢ１にユーザＢのオーナー情報は登録されていないために（ステップＳ５５０；ＮＯ）、ユーザＡがユーザＢとフレンド関係を構築するためには、まず、未登録ユーザＢを当該システムに招待し、ユーザＢにユーザ登録してもらう必要があると判断する（ステップＳ５６０）。フレンド関係管理手段（第2通知手段）２２０は、かかる判断に基づいて、ユーザＢの通信端末３００−２にアクセスすることで、通信端末３００−２と顧客管理サーバ２００との間の通信を確立する（ステップＳ５６０→ステップＳ５７０）。そして、フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２に対し、Ｂさんに当該システムの招待及びＡさんからフレンド申請がある旨のメッセージ（例えば「Ａさんからシステム利用に関して招待がありました。Ａさんとのフレンド関係を承認する場合は、必要事項を入力してユーザ登録を行うととともに、フレンド申請に対して“ＹＥＳ”を選択してください。」）を送る（ステップＳ５８０）。

ユーザＢは、通信端末３００−２の表示装置に表示される内容から、ユーザＡからシステム利用に関して招待を受けたこと、及びフレンド申請があったことを把握する。ユーザＢは、通信端末３００−２を利用して、ユーザＡからの招待及びフレンド申請の要求を承諾する旨の入力操作を行う（ステップＳ５９０）。具体的には、ユーザＢは、通信端末３００−２の操作ボタンやタッチパネルなどを操作して、ユーザ登録に必要なユーザ自身の個人情報（すなわち電話番号や名前など）を入力するとともに、フレンド申請に対して“ＹＥＳ”を選択する旨の入力を行う。

かかる操作がなされると、顧客管理サーバ２００のアクセス制御管理手段（第3登録手段）２１０は、顧客データベース（第１記憶手段）ＤＢ１にユーザＢの個人情報をオーナー情報として新規に登録する（ステップＳ６００）。その後、フレンド関係管理手段２２０は、ユーザＡの通信端末３００−１に対してフレンド申請が受け付けられた旨のメッセージ（例えば「ユーザＡさん、ユーザＢさんによってフレンド申請は承諾されました。」）を送る（ステップＳ６１０）。さらに、フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２の電話帳にユーザＡの個人情報を登録するべく、ユーザＢの通信端末３００−２にアクセスし、ユーザＢの電話帳にユーザＡの個人情報を書き込む（ステップＳ６２０）。かかる処理が終了すると、フレンド関係管理手段２２０は、ユーザＢの通信端末３００−２に対してユーザ登録が完了した旨、ユーザＡとのフレンド関係の構築が完了した旨のメッセージ（例えば、「登録作業は完了し、ユーザＡとのフレンド関係が構築されました。」）、及びユーザＡの個人情報が電話帳に新たに登録された旨のメッセージ（例えば、「ユーザＡの個人情報を新たに追加いたしました。」）を送る（ステップＳ６３０）。

最後に、フレンド関係管理手段（第3登録手段）２２０は、顧客データベースＤＢ１にアクセスし、登録ユーザＡのフレンド情報として「登録ユーザＢ」、登録ユーザＢのフレンド情報として「登録ユーザＡ」をそれぞれ登録する（ステップＳ６４０）。

以上説明したように、本パターンの場合には、ユーザＡのみが既登録ユーザで、ユーザＡの電話帳にのみユーザＢの個人情報が登録され、ユーザＢは未登録ユーザの場合にフレンド関係の構築が可能となる。このような場合であっても、ユーザＡの電話帳にユーザＢの個人情報が登録されていることが前提（すなわち、ユーザＡはユーザＢの個人情報を知っていることが前提）となっているため、本パターンにおいても、自身が直接関係ない他人から、突然フレンド関係の申請がなされてしまう等の問題を未然に防ぐことが可能となる。

Ｂ．その他
＜応用例１＞
電話帳に登録されているユーザとの親密度に応じて、構築するフレンド関係の種類を選択するようにしても良い。例えば、親密度に応じて、ビジネス・フレンド関係、またはプライベート・フレンド関係のいずれかを構築可能とする。
ここで、フレンド関係の種類は、電話帳に登録されているフレンド申請先のユーザの個人情報の種類や数（少なくともいずれか一方のパラメータ）に応じて決定される。例えば、登録される個人情報が「電話番号」のみの場合には、ビジネス・フレンド関係の構築が可能となり、登録されている個人情報が「電話番号」と「誕生日」と「ニックネーム」の場合には、プライベート・フレンド関係の構築が可能となる。そして、ビジネス・フレンド関係が構築された場合には、フレンド関係が構築されたユーザ間で「電話番号」や「オフィス住所」など、制限された個人情報（ビジネス関連情報）のみが共有可能となる。

一方、プライベート・フレンド関係が構築された場合には、フレンド関係が構築されたユーザ間で「電話番号」や「ニックネーム」、「自己紹介写真」、など、制限のない（あるいは一部のみ制限された）個人情報（プライベート関連情報）の共有が可能となる。

通信端末（決定手段、申請手段）３００は、フレンド申請先のユーザの個人情報の種類または数の少なくともいずれかのパラメータに基づいてフレンド関係の種類を決定すると、この種類のフレンド関係にてフレンド申請を行う。なお、顧客管理サーバ２００のフレンド関係管理手段２２０がフレンド申請を受け取った後の動作については、本実施形態等と同様に説明することができるため、割愛する。

かかる構成によれば、ビジネス上付き合いがある友人と、公私ともに付き合いがある友人との間で、共有できる情報を変えることが可能となる。
なお、フレンド関係の種類を決定する条件や、フレンドフレンド関係の種類に応じて共有可能となる個人情報の種類や数については、通信端末３００のメモリに格納しておけば良い。この条件は、固定的なものであっても良く、書き換え可能なものであっても良い。書き換え可能とする場合には、通信端末３００の入力操作によって書き換え可能としても良く、また、顧客管理サーバ２００が書き換える構成としても良い。

また、通信端末（判断手段）３００は、フレンド関係の種類を決定する代わりに、フレンド申請そのものを受け付けるか否かを判断しても良い。例えば、フレンド申請を試みるユーザに関して、電話帳に登録されている個人情報が「電話番号」のみの場合には、フレンド申請そのものを拒否する。一方、フレンド申請を試みるユーザに関して、電話帳に登録されている個人情報が「電話番号」と「誕生日」と「ニックネーム」の場合には、フレンド申請を許可する。フレンド申請を許可した場合、通信端末（申請手段）３００は、顧客管理サーバ２００にフレンド申請を行う。なお、フレンド申請そのものを受け付けるか否かの判断条件は、電話帳に登録されている個人情報の種類または数の少なくともいずれか一方を使用すれば良い。

さらにまた、どのような条件でビジネス・フレンド関係やプライベート・フレンド関係の構築を可能とするかは、任意に設定可能である。また、本応用例では、フレンド関係の種類が２種類（ビジネス・フレンド関係、プライベート・フレンド関係）の場合を例示したが、３種類以上であっても良いのは勿論である。

また、フレンド関係が構築されユーザ間で共有することが可能となる情報の種類や数は、任意に設定可能である。以上説明した設定可能な条件については、各ユーザが自身の通信端末３００を利用して任意に設定しても良く、また、顧客管理サーバ２００の方で任意に設定しても良い。

＜応用例２＞
各ユーザ間でフレンド関係が構築された後は、オーナー情報に登録されている様々な情報を共有するようにしても良い。例えば、ユーザＡとユーザＢについてフレンド関係が構築された場合、ユーザＡのオーナー情報として名前、住所、電話番号、メールアドレス、誕生日、ニックネーム、自己紹介写真が顧客データベースＤＢ１に登録されているのに対し、ユーザＢの電話帳に登録されているユーザＡの個人情報は、名前、電話番号、メールアドレスだったとする。

このような場合、顧客管理サーバ２００のフレンド関係管理手段（反映手段）２２０は、顧客データベースＤＢ１の登録されているユーザＡのオーナー情報と、ユーザＢの電話帳に登録されているユーザＡの個人情報とを比較することで、これらの差分（ここでは、住所、誕生日、ニックネーム、自己紹介写真；以下、差分情報）を求め、求めた差分情報をユーザＢの電話帳に登録されているユーザＡの個人情報に追加（反映）しても良い。かかる構成によれば、フレンド関係を構築したユーザ間で、より新密度の高い情報共有が可能となる。

また、上記本実施形態および各変形例において示した各処理のステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。さらに本明細書等において、手段とは、単に物理的手段を意味するものではなく、その手段が有する機能をソフトウェアによって実現する場合も含む。さらにまた、１つの手段が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段の機能が１つの物理的手段により実現されてもよい。また、本発明に係るソフトウェアの開発支援プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。

１００…顧客管理システム、２００…顧客管理サーバ、２１０…顧客管理手段、２２０…フレンド関係管理手段、ＤＢ１…顧客データベース、３００…通信端末、３１０…メモリ。

Claims (7)

1. 電話帳を備えた複数の通信端末と、各通信端末の電話帳に登録されているユーザの個人情報を管理する個人情報管理サーバとを備えた個人情報管理システムであって、
   前記通信端末は、
   当該通信端末の所有者に関わるオーナー情報を含む複数人の個人情報を登録した電話帳を記憶するメモリと、
   電話帳に登録されているユーザにフレンド申請を行うための入力を行う入力手段と、
   前記ユーザの個人情報を含めて前記入力されたフレンド申請を前記個人情報管理サーバに送信する送信手段と、を備え、
   前記個人情報管理サーバは、
   前記各通信端末の所有者に関わるオーナー情報を記憶する第１記憶手段と、
   前記オーナー情報の開示を相互に許可するフレンド関係にある前記両所有者を特定するフレンド関係情報を記憶する第２記憶手段と、
   前記フレンド申請に含まれる前記ユーザの個人情報と一致する前記オーナー情報が、前記第１記憶手段に記憶されているか否かを判断する第１判断手段と、
   前記第１判断手段によって前記オーナー情報が記憶されていると判断された場合には、前記フレンド申請先となる他のユーザの通信端末にアクセスする第１アクセス手段と、
   前記フレンド申請元のユーザのオーナー情報を検索キーとして前記他のユーザの通信端末の電話帳を検索することにより、前記フレンド申請元のユーザの個人情報が前記他のユーザの電話帳に登録されているか否かを判断する第２判断手段と、
   前記第２判断手段によって前記他のユーザの電話帳に登録されていると判断された場合には、前記フレンド関係情報として、前記フレンド申請元であるユーザと前記フレンド申請先である他のユーザとを特定する情報を、前記第２記憶手段に記憶する、第１登録手段と
   を備える、個人情報管理システム。
2. 前記第２判断手段によって前記他のユーザの電話帳に登録されていないと判断された場合には、前記フレンド申請先となる他のユーザの通信端末に、前記申請元であるユーザからフレンド申請があった旨を通知する第１通知手段と、
   前記他のユーザの通信端末から前記申請を承諾する旨の入力があった場合に、前記フレンド関係情報として、前記フレンド申請元であるユーザと前記フレンド申請先である他のユーザとを特定する情報を、前記第２記憶手段に記憶する、第２登録手段と
   をさらに備える、請求項１に記載の個人情報管理システム。
3. 前記第１判断手段によって前記オーナー情報が記憶されていないと判断された場合には、前記フレンド申請先となる他のユーザの通信端末に、当該システムへのユーザ登録を促す旨、及び前記申請元であるユーザからフレンド申請があった旨を通知する第２通知手段と、
   前記他のユーザの通信端末から、前記ユーザ登録に対応する該他のユーザの個人情報の入力、及び前記申請を承諾する旨の入力があった場合に、該他のユーザの個人情報をオーナー情報として前記第１記憶手段に記憶するとともに、前記フレンド関係情報として、前記フレンド申請元であるユーザと前記フレンド申請先である他のユーザとを特定する情報を前記第２記憶手段に記憶する、第３登録手段と
   をさらに備える、請求項１に記載の個人情報管理システム。
4. 前記第１記憶手段に記憶されている申請元のユーザのオーナー情報と、前記他のユーザの電話帳に登録されている前記申請元のユーザの個人情報とを比較することにより、該オーナー情報と該個人情報との差分をあらわす差分情報を求め、求めた差分情報を、前記他のユーザの電話帳に登録されている前記申請もとのユーザの個人情報に反映させる反映手段をさらに備える、請求項１〜３のいずれか１の請求項に記載の個人情報管理システム。
5. 電話帳を備えた複数の通信端末と、前記各通信端末を所持する各ユーザの間で、オーナー情報の開示を相互に許可するフレンド関係の構築が可能な個人情報管理サーバとを備えた個人情報管理システムであって、
   前記通信端末は、
   当該通信端末の所有者に関わるオーナー情報を含む複数人の個人情報を登録した電話帳を記憶するメモリと、
   電話帳に登録されているユーザにフレンド申請を行うための入力を行う入力手段と、
   前記電話帳に登録されている前記フレンド申請先のユーザの個人情報の種類、または数の少なくともいずれかに基づいて、フレンドの種類を決定する決定手段と、
   前記個人情報管理サーバに対して、決定したフレンドの種類にてフレンド申請を行う申請手段とを備え、
   前記フレンドの種類に応じて、前記フレンド関係が構築されたユーザの間で開示が許可される前記オーナー情報の種類が異なる、個人情報管理システム。
6. 前記フレンドの種類と、前記開示が許可される前記オーナー情報の種類との対応を示す対応情報を記憶する記憶手段を備える、請求項５に記載の個人情報管理システム。
7. 電話帳を備えた複数の通信端末と、前記各通信端末を所持する各ユーザの間で、オーナー情報の開示を相互に許可するフレンド関係の構築が可能な個人情報管理サーバとを備えた個人情報管理システムであって、
   前記通信端末は、
   当該通信端末の所有者に関わるオーナー情報を含む複数人の個人情報を登録した電話帳を記憶するメモリと、
   電話帳に登録されているユーザにフレンド申請を行うための入力を行う入力手段と、
   前記電話帳に登録されている前記フレンド申請先のユーザの個人情報の種類、または数の少なくともいずれかに基づいて、フレンド申請を許可するか否かを判断する判断手段と、
   前記フレンド申請を許可すると判断した場合に、前記個人情報管理サーバに対して、フレンド申請を行う申請手段とを備える、個人情報管理システム。

Images