ユーザ評価装置
【課題】電話帳を用いてユーザの評価を行うユーザ評価装置を提供する。
【解決手段】電話帳管理部１５３は、電話番号を含む登録者情報が記録された電話帳１５２−１〜１５２−ｎを管理する。電話帳検索部１５４は、評価対象ユーザの電話帳に記録された登録者情報を取得する。評価部１５５は、評価対象ユーザを指定したユーザ評価要求を入力し、電話帳検索部１５４で取得された評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として評価対象ユーザの評価を行い、評価結果を出力する。
【解決手段】電話帳管理部１５３は、電話番号を含む登録者情報が記録された電話帳１５２−１〜１５２−ｎを管理する。電話帳検索部１５４は、評価対象ユーザの電話帳に記録された登録者情報を取得する。評価部１５５は、評価対象ユーザを指定したユーザ評価要求を入力し、電話帳検索部１５４で取得された評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として評価対象ユーザの評価を行い、評価結果を出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの電話帳に登録された情報に基づいてユーザの人脈に関する評価を行うユーザ評価装置に関する。
【背景技術】
【０００２】
一般に固定電話装置や携帯電話装置などの通信端末には、通信相手の電話番号を複数記憶し、電話をかける際には、相手の名前などから電話番号を検索して自動的に発信させる電話帳機能が備えられている。
【０００３】
また、電話帳を通信端末側で記憶するのではなく、電話サービス事業者側のデータベースに記憶し、個々の通信端末から通信ネットワークを介して電話帳を利用できるシステムが提案されている（例えば、特許文献１、特許文献２参照）。
【０００４】
さらに、ネットワーク側と個々の通信端末側との双方に電話帳を記憶するシステムも提案されている（例えば特許文献３参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１３６２６５号公報
【特許文献２】特開２００４−３０４３５７号公報
【特許文献３】特開平８−２２８３８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
通信端末のユーザが電話帳に登録した情報は、専ら通信相手の電話番号を検索するために利用されており、それ以外の目的で電話帳を利用する例は皆無である。
【０００７】
その理由としては、電話帳に登録された情報は個人情報の一種であるために、第三者が無断で使用すると個人情報の漏洩につながる恐れがあるためである。
【０００８】
しかし、電話帳はユーザの人脈を推測するための貴重な情報になり得るものである。電話番号の検索にしか利用しないのは得策でない。
【０００９】
通信端末の発着信履歴に記載される通信相手と異なり、電話帳に記録される登録者は、親しい友人や付き合いの多い相手など、ユーザと比較的密接なつながりのある人達であることが一般的である。このため、多くの友人や交際相手を持つユーザの電話帳には数多くの登録者が登録される傾向がある。逆に付き合う人の少ないユーザの電話帳の登録人数は少ない傾向を示す。つまり、電話帳の登録者数でその人の人脈の多さ、少なさを或る程度推測することができる。
【００１０】
本発明はこのような点に着目して提案されたものであり、その目的は、電話帳を用いてユーザの人脈に関する評価を行うユーザ評価装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明のユーザ評価装置は、電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段とを備える。
【発明の効果】
【００１２】
本発明によれば、電話帳を用いてユーザの評価を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施の形態に係る情報処理システムのブロック図である。
【図２】電話帳に登録される情報の一例を示す図である。
【図３】電話帳管理部の一例を示すブロック図である。
【図４】本発明の第１の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図５】本発明の第１の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図６】本発明の第２の実施の形態に係る情報処理システムのブロック図である。
【図７】Ｗｅｂ閲覧判定部の一例を示すブロック図である。
【図８】監視対象ＵＲＬ登録テーブルに記録される情報の一例を示す図である。
【図９】Ｗｅｂ閲覧履歴テーブルに記録される情報の一例を示す図である。
【図１０】本発明の第２の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図１１】本発明の第２の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図１２】本発明の第３の実施の形態に係る情報処理システムのブロック図である。
【図１３】ユーザ位置判定部の一例を示すブロック図である。
【図１４】位置情報管理テーブルに記録される情報の一例を示す図である。
【図１５】本発明の第３の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図１６】本発明の第３の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図１７】本発明の第４の実施の形態に係る情報処理システムのブロック図である。
【図１８】プレゼンス判定部の一例を示すブロック図である。
【図１９】本発明の第４の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図２０】本発明の第４の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【発明を実施するための形態】
【００１４】
［第１の実施の形態］
図１を参照すると、本発明の第１の実施の形態に係る情報処理システム１００は、通信事業者サーバ装置１１０と、複数のサービス装置１２０−１〜１２０−ｍと、複数のユーザ端末１３０−１〜１３０−ｎとが通信ネットワーク１４０を介して接続されている。
【００１５】
通信ネットワーク１４０は、通信事業者が運営するＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワークである。
【００１６】
ユーザ端末１３０−１〜１３０−ｎは、ユーザ１３１−１〜１３１−ｎが所有する携帯電話装置やＰＤＡなどの音声通話機能およびインターネット接続機能を有する通信端末である。ユーザ端末１３０−１〜１３０−ｎには、電話番号とユーザ識別子とが割り当てられている。ユーザ識別子は、ユーザ端末１３０−１〜１３０−ｎまたはユーザ１３１−１〜１３１−ｎを識別する値である。ユーザ識別子は、ユーザ１３１−１〜１３１−ｎが通信事業者の通信サービスの会員として加入する際に、通信事業者から割り当てられる。一般に加入時には、氏名や住所などの個人情報を登録する必要がある。ユーザ識別子は、例えば携帯電話ならＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ Ｃａｒｄ）カードによって付与され、電話番号やメールアドレスを特定するための固有のＩＤであるＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）などが利用できる。
【００１７】
通信事業者サーバ装置１１０は、固定電話や携帯電話等の電気通信サービスを提供する通信事業者のサーバコンピュータである。通信ネットワーク１４０経由によるユーザ端末１３０−１〜１３０−ｎ間およびユーザ端末１３０−１〜１３０−ｎとサービス装置１２０−１〜１２０−ｍ間の通信はすべて、この通信事業者サーバ装置１１０の制御の下で実施される。
【００１８】
本実施の形態においては、通信事業者サーバ装置１１０に、ユーザ評価装置１５０を配置している。ユーザ評価装置１５０は、記憶部１５１と、電話帳管理部１５３と、電話帳検索部１５４と、評価部１５５とを備えている。
【００１９】
記憶部１５１は、磁気ディスク等で構成され、通信事業者サーバ装置１１０を運用する通信事業者に加入しているユーザ１３１−１〜１３１−ｎの電話帳１５２−１〜１５２−ｎを記憶する。
【００２０】
電話帳に登録される情報の一例を図２に示す。図２を参照すると、電話帳には、ユーザ名と電話番号とユーザ識別子と最新通信時刻とから構成される登録者情報が複数記憶できるようになっている。個々の登録者情報に含まれるユーザ名は、この電話帳の持ち主が通信相手を識別するために付けた名前であり、一般的には通信相手の名前である。電話番号はその通信相手の電話番号である。電話帳の持ち主自身が登録するのは、このユーザ名と電話番号の情報だけであり、残りのユーザ識別子と最新通信時刻の情報は電話帳管理部１５３が自動的に付与する。最新通信時刻は、最後に通信が行われた日を示す。日だけでなく、時、分も含めても良い。また電話帳には、その電話帳がどのユーザのものであるかを識別するために、ユーザ識別子が付与されている。図２の電話帳には、ユーザ識別子ｕｓｅｒ００１が付与されており、この電話帳がユーザ識別子ｕｓｅｒ００１を持つユーザの電話帳であることが示されている。さらに本実施の形態では、本人の電話番号も電話帳に記憶している。図２の場合、０９０−１１１Ｘ−１１１Ｘがこの電話帳を保持するユーザの電話番号である。なお、電話帳の構成は図２の構成に限定されない。通信相手の住所やメールアドレス等の情報を登録した電話帳であっても良い。
【００２１】
電話帳管理部１５３は、ユーザ１３１−０〜１３１−ｎの電話帳１５２−１〜１５２−ｎを記憶部１５１に保持して管理する。電話帳管理部１５３は、通信ネットワーク１４０経由でアクセスしてきたユーザ端末１３０−１〜１３０−ｎからの要求に従って、記憶部１５１にユーザ１３１−１〜１３１−ｎの電話帳を新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索の機能を提供する。また電話帳管理部１５３は、通信事業者サーバ装置１１０の制御の下で行われた通信履歴を参照して、記憶部１５１に記憶された電話帳１５２−１〜１５２−ｎの各登録者情報中の最新通信時刻を更新する機能を有する。さらに電話帳管理部１５３は、電話帳検索部１５４から検索を要求された電話帳に登録された登録者情報を記憶部１５１から読み出して、電話帳検索部１５４へ出力する機能を有する。
【００２２】
図３を参照すると、電話帳管理部１５３の一例は、ユーザ要求処理部１５３１と、電話番号正当性判定部１５３２と、最新通信時刻更新部１５３３と、検索要求処理部１５３４とを備えている。
【００２３】
電話番号正当性判定部１５３２は、新たに電話帳に登録する電話番号が正当か否かを判定する部分である。本実施の形態では、電話番号が正当か否かの判定は、電話番号に対応するユーザ識別子が加入者データベース１５３５に記録されているか否かを調べることで行う。一般に、通信ネットワーク１４０を運用する通信事業者の加入者データベース１５３５には、加入ユーザの電話番号とユーザ識別子との対応が記録されているため、加入者データベース１５３５に対応するユーザ識別子が記録されている電話番号は、正当な電話番号であると判定できる。なお、加入者データベース１５３５は、通信事業者サーバ装置１１０内に備えられるか、あるいは通信事業者サーバ装置１１０からアクセス可能な他のサーバ内に備えられている。また、自社の加入者データベース１５３５に登録の無い電話番号は一律に不正な電話番号として扱っても良いし、自社以外の通信事業者に対して対応するユーザ識別子の有無を問い合わせて、その結果に従って判定するようにしても良い。
【００２４】
ユーザ要求処理部１５３１は、ユーザ端末１３０−１〜１３０−ｎからの要求に従って、記憶部１５１にユーザ１３１−１〜１３１−ｎの電話帳１５２−１〜１５２−ｎを新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索のサービスをユーザ端末１３０−１〜１３０−ｎに提供する部分である。ここで、ユーザ要求処理部１５３１は、ユーザ端末１３０−１〜１３０−ｎからの要求に従って新たな電話番号を電話帳に登録する際には、その電話番号の正当性を電話番号正当性判定部１５３２を用いて判定し、正当と判定された電話番号には、そのことを示すために、電話番号との対応がとれたユーザ識別子を電話帳に記録する。
【００２５】
最新通信時刻更新部１５３３は、記憶部１５１に記憶された電話帳１５２−１〜１５２−ｎの各登録者情報中の最新通信時刻を更新する部分である。具体的には、通信事業者サーバ装置１１０の制御によって、発信側通信端末および着信側通信端末との間に通信が行われた場合、双方の通信端末の電話番号あるいはユーザ識別子の組み合わせを持つ電話帳の登録者情報を記憶部１５１中から検索し、該当する登録者情報中の最新通信時刻を現在時刻で上書きする。例えば、ユーザ識別子ｕｓｅｒ００１のユーザ端末とユーザ識別子ｕｓｅｒ００２のユーザ端末との間で通信が行われた場合、最新通信時刻更新部１５３３は、ユーザ識別子ｕｓｅｒ００１を持つ電話帳の中にユーザ識別子ｕｓｅｒ００２を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。さらに最新通信時刻更新部１５３３は、ユーザ識別子ｕｓｅｒ００２を持つ電話帳の中にユーザ識別子ｕｓｅｒ００１を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。
【００２６】
検索要求処理部１５３４は、電話帳検索部１５４から検索の要求された電話帳に登録された登録者情報を記憶部１５１から読み出して、電話帳検索部１５４へ出力する部分である。
【００２７】
再び図１を参照すると、電話帳検索部１５４は、評価部１５５からの要求に従って、電話帳管理部１５３で管理されている電話帳のうち評価対象ユーザの電話帳に記録された登録者情報を取得し、評価部１５５へ通知する機能を有する。ここで、電話帳検索部１５４は、ユーザ識別子が付与されていない登録情報は電話番号が信用できないものと判断して取得の対象から除外する。また、電話帳検索部１５４は、現在から過去一定期間内の時刻が最新通信時刻に記録されていない登録情報は、交流が途絶えて久しい登録者と見做して、取得の対象から除外する。
【００２８】
評価部１５５は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部１５５は、評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを判定する登録数判定部１６１を備えている。
【００２９】
評価部１５５がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図４に示す。
【００３０】
図４を参照すると、ユーザ評価要求を受信した評価部１５５は、電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求する（ステップＳ１０１）。評価対象ユーザの指定は、例えばユーザ識別子で行う。
【００３１】
電話帳検索部１５４は、まず、電話帳管理部１５４を通じて評価対象ユーザの電話帳に記録された登録者情報を取得する（ステップＳ１０２）。次に、取得した登録者情報のうち、ユーザ識別子が付加されていない登録者情報、および最新通信時刻から過去所定期間内に一度も通信が行われていない登録者情報を除去する（ステップＳ１０３）。そして、残った登録者情報を評価部１５５に伝達する（ステップＳ１０４）。
【００３２】
評価部１５５は、登録数判定部１６１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【００３３】
次に評価部１５５は、登録数評価結果をユーザ評価結果とし（ステップＳ１０６）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００３４】
サービス装置１２０−１〜１２０−ｍは、サービス事業者が通信ネットワーク１４０を介してユーザ端末１３０−１〜１３０−ｎのユーザ１３１−１〜１３１−ｎに対してサービスを提供するためのサーバコンピュータである。サービス装置１２０−１〜１２０−ｍは、ユーザ端末１３０−１〜１３０−ｎからサービス要求を受信したとき、ユーザ端末１３０−１〜１３０−ｎのユーザ１３１−１〜１３１−ｎを評価対象ユーザに指定したユーザ評価要求を通信ネットワーク１４０経由でユーザ評価装置１５０へ送信し、ユーザ評価装置１５０から返される評価対象ユーザの評価結果に従って、サービス要求に対して提供するサービス内容を変更する機能を有する。
【００３５】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、各種考えられる。以下に幾つかの例を示す。
【００３６】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図５に示す。
【００３７】
図５に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部１５５に対してユーザ評価を要求する。ここでは、評価基準として、検索要求で指定された空席数の半分の４を指定したものとする。なお、検索要求で指定された空席数の半分を評価基準とするのは、あくまでも一例である。検索要求で指定された空席数と同じ数を評価基準としたり、検索要求で指定された空席数とは無関係にあらかじめ定められた定数値を指定するようにしてもよい。
【００３８】
評価部１５５は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳に登録された登録者情報を取得し、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部１５５に伝達する。例えば、ユーザ識別子ｕｓｅｒ００１で特定されるユーザの電話帳に図２に示した７名分の登録者情報が登録されている場合、ユーザ名Ｄ、Ｇの登録者情報にはユーザ識別子が記録されていないので、これらの登録者情報が除外される。また、現在日時を２００８年１１月２０日とし、過去１年以上にわたって通信が行われていない登録者情報を除外するとする場合、ユーザＨの登録者情報が除かれる。結局、電話帳検索部１５４は、ユーザＢ、Ｃ、Ｅ、Ｆの４名分の登録者情報を評価部１５５に伝達する。
【００３９】
評価部１５５は、登録数判定部１６１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。次に、評価部１５５は、登録数評価結果をユーザ評価結果として生成し、サービス装置１２０−１へ送信する。
【００４０】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００４１】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、４名以上の登録者情報が無ければ、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【００４２】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【００４３】
＜サービスの例２＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、特定の飲食店の予約をインターネット経由でリアルタイムに受け付ける予約受け付けサービスであっても良い。この場合、サービス装置１２０−１は、飲食店の空席情報を含む案内情報をリアルタイムに更新してデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの条件を指定して予約を要求すると、サービス装置は、予約を受け付けることができるか否かをデータベース中の案内情報を参照して決定し、予約可能ならば予約を受け付けた旨の通知を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、予約しようとするユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、予約者に特典を付与する。
【００４４】
具体的には、サービス装置１２０−１は、例１と同様に評価部１５５に対してユーザ評価要求を送信する。このとき、評価基準として、例えば登録者情報の数が３０以上を指定する。そして、サービス装置１２０−１は、評価部１５５のユーザ評価結果がＯＫであれば、つまりユーザの電話帳に３０人以上の登録者が登録されていれば、例えば、特典として１０％の割引を予約者に与え、ＮＧであれば、つまり３０人未満であれば、そのような特典は与えない。その理由は、３０人以上の登録者が電話帳に登録されているような人脈のあるユーザを顧客にできれば、その者の口コミによって顧客の増大を期待できるためである。
【００４５】
このように本実施の形態によれば、電話帳の登録者情報の数に基づいてユーザの人脈の多少に関する評価を行う。電話帳に記録される登録者は、親しい友人や付き合いの多い相手など、ユーザと比較的密接なつながりのある相手である場合が多いため、他の情報、例えば儀礼的に交換される名刺や年賀状の保有枚数に基づいて行う評価に比べて、より確かな評価を下すことができる。
【００４６】
また本実施の形態によれば、ユーザ識別子との対応がとれない電話番号を含む登録情報を除外して評価を行うために、不正な電話番号が登録されていたとしても、それらに影響されずに評価を行うことができる。
【００４７】
また本実施の形態によれば、過去所定期間に一度も通信されていない登録者を除外して評価を行うために、電話帳に電話番号を登録したものの一度も連絡していない相手や、過去には良く連絡を取り合っていたが最近は全く連絡し合っていない相手を除外した評価が可能になる。
【００４８】
また本実施の形態によれば、サービス事業者、通信事業者およびユーザのそれぞれに対して有効な効果が生じる。まずサービス事業者にとっては、ユーザ端末のユーザの評価結果に応じて、提供するサービス内容を変更することができ、従来にないサービス展開が可能になる。また通信事業者にとっては、個人情報の漏洩につなげずに、通信事業者側で管理するユーザの電話帳の情報をユーザの評価という新たな形で提供でき、収益につなげることができる。そして、ユーザにとっては、サービスを利用する際に、サービス事業者が通信事業者からのユーザ評価結果に基づいてサービス展開をするので、より良いサービスを受けることができる。
【００４９】
［第２の実施の形態］
図６を参照すると、本発明の第２の実施の形態に係る情報処理システム２００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部２１０を備えている点で相違する。
【００５０】
評価部２１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部２１１に加えて、Ｗｅｂ閲覧判定部２１２を備えている。
【００５１】
Ｗｅｂ閲覧判定部２１２は、電話帳検索部１５４で取得された登録者情報に含まれる登録者について、所定のＷｅｂサーバのコンテンツを閲覧しているか否かを前記Ｗｅｂサーバの閲覧履歴を参照して判定し、閲覧している登録者の数が評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する機能を有する。
【００５２】
図７を参照すると、Ｗｅｂ閲覧判定部２１２は、Ｗｅｂサーバ閲覧監視部２１２１と、閲覧者数検出部２１２２と、判定部２１２３と、監視対象ＵＲＬ登録テーブル２１２４と、Ｗｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍを記憶する記憶部２１２５とを備えている。
【００５３】
監視対象ＵＲＬ登録テーブル２１２４は、サービス装置１２０−１〜１２０−ｍを運用するサービス事業者を一意に識別するサービス事業者識別子に対応付けて、そのサービス事業者が事前に申請したＷｅｂページのＵＲＬを記録している。その内容例を図８に示す。図８に示されるように、サービス事業者識別子に対応付けて登録するＵＲＬは１つでも良いし、２つ以上であっても良い。ＵＲＬで特定されるＷｅｂページは、対応するサービス事業者識別子で特定されるサービス事業者のホームページなどであっても良いし、別のサービス事業者のホームページなどであっても良い。
【００５４】
Ｗｅｂサーバ閲覧監視部２１２１は、監視対象ＵＲＬ登録テーブル２１２４に記録されたＵＲＬに対してアクセスを行ったユーザ端末１３０−１〜１３０−ｎを検出し、検出結果を記憶部２１２５のＷｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍに記録する。Ｗｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍは、サービス事業者識別子に１対１に対応している。Ｗｅｂサーバ閲覧監視部２１２１は、監視対象ＵＲＬ登録テーブル２１２４の或るサービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出すると、そのサービス事業者識別子に対応するＷｅｂ閲覧履歴テーブルにユーザ端末１３０−１〜１３０−ｎのユーザ識別子を閲覧日の情報を添えて記録する。図９にサービス事業者識別子ｓｅｒｖｉｃｅ００１に対応するＷｅｂ閲覧履歴テーブルの記録情報の例を示す。
【００５５】
Ｗｅｂサーバ閲覧監視部２１２１が、ユーザ端末１３０−１〜１３０−ｎのＷｅｂ閲覧を監視する方法としては、プロキシを用いる方法、デバイスマネージメントを用いる方法が考えられる。プロキシを用いる方法では、ユーザ端末１３０−１〜１３０−ｎからｗｅｂページを直接アクセスするのではなく、Ｗｅｂ閲覧判定部２１２が代理としてアクセスを行い、その過程で、サービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出する方法である。デバイスマネージメントとは、ネットワークにアクセスするユーザ端末１３０−１〜１３０−ｎのデバイス情報やユーザ情報の収集、管理、書き込みを行うシステムのことである。デバイスマネージメントを用いてユーザ端末１３０−１〜１３０−ｎのＷｅｂ閲覧履歴を吸い上げて、サービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出する。
【００５６】
閲覧者数検出部２１２２は、電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者について、所定のＷｅｂサーバのコンテンツを閲覧しているか否かをＷｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍを参照して判定し、登録者のうち所定のＷｅｂサーバのコンテンツを閲覧している閲覧者数を検出する部分である。
【００５７】
判定部２１２３は、閲覧者数検出部２１２２で検出された閲覧者数が評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する部分である。
【００５８】
評価部２１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部２１０は、登録数判定部２１１の登録数評価結果と、Ｗｅｂ閲覧判定部２１２のＷｅｂ閲覧評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびＷｅｂ閲覧評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【００５９】
評価部２１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１０に示す。
【００６０】
図１０を参照すると、ユーザ評価要求を受信した評価部２１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【００６１】
次に評価部２１０は、登録数判定部２１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【００６２】
次に評価部２１０は、Ｗｅｂ閲覧判定部２１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、所定のＷｅｂページを過去一定期間（例えば１日）内に閲覧した者の数を計数し、評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する（ステップＳ２０１）。ここで、Ｗｅｂ閲覧評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置２１０に予め固定的に設定しておいても良い。また、Ｗｅｂ閲覧評価の評価基準は、登録数判定評価の評価基準と同じであっても良いし、相違していても良い。
【００６３】
次に評価部２１０は、登録数評価結果とＷｅｂ閲覧評価結果とからユーザ評価結果を生成し（ステップＳ２０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００６４】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【００６５】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。
【００６６】
また、飲食店の空席情報の検索サービスを利用して実際に飲食店で食事する人達のＷｅｂ閲覧履歴の傾向を分析した結果に基づいて、その人達が良く見るＷｅｂページのＵＲＬを自サービス事業者の識別子に対応付けて評価部２１０の監視対象ＵＲＬ登録テーブル２１２４に登録する手続きを行っておく。
【００６７】
何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図１１に示す。
【００６８】
図１１に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部２１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数判定用の評価基準として、検索要求で指定された空席数の半分の４を指定し、Ｗｅｂ閲覧判定用の評価基準として例えば１を指定したものとする。
【００６９】
評価部２１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部２１０に伝達する。
【００７０】
評価部２１０は、登録数判定部２１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【００７１】
また評価部２１０は、Ｗｅｂ閲覧判定部２１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、監視対象ＵＲＬ登録テーブル２１２４にサービス装置１２０−１の識別子に対応付けて記録されたＵＲＬのＷｅｂページを閲覧している者の数が評価基準の１以上であれば、「ＯＫ」のＷｅｂ閲覧評価結果を生成し、それ以外は「ＮＧ」のＷｅｂ閲覧評価結果を生成する。
【００７２】
次に評価部２１０は、登録数評価結果とＷｅｂ閲覧評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【００７３】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００７４】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち少なくとも１名の者が所定のＷｅｂページを２４時間以内に閲覧していれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【００７５】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、自サービス事業者の提供する飲食店の空席情報の検索サービスを利用して実際に飲食店で食事したユーザに対するアンケート調査など事前に得ている良く閲覧するＷｅｂページを、登録者の少なくとも一人が閲覧していれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【００７６】
このように本実施の形態によれば、電話帳の登録者の数に加えて、その登録者のうち所定のＷｅｂページを閲覧した者の数も考慮してユーザを評価するため、ユーザの人脈の中に所定のＷｅｂページを良く閲覧する者がどれだけいるかを考慮したユーザ評価が可能になる。
【００７７】
［第３の実施の形態］
図１２を参照すると、本発明の第３の実施の形態に係る情報処理システム３００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部３１０を備えている点で相違する。
【００７８】
評価部３１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部３１１に加えて、ユーザ位置判定部３１２を備えている。
【００７９】
ユーザ位置判定部３１２は、評価対象ユーザと電話帳検索部１５４で取得された登録者情報に含まれる登録者の位置情報を取得し、評価対象ユーザとの位置関係が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する機能を有する。
【００８０】
図１３を参照すると、ユーザ位置判定部３１２は、位置情報管理部３１２１と、位置合格数検出部３１２２と、判定部３１２３と、位置情報管理テーブル３１２５を記憶する記憶部３１２４とを備えている。
【００８１】
位置情報管理テーブル３１２５は、ユーザ端末１３０−１〜１３０−ｎのユーザ識別子に対応付けて、その地理的な位置情報を記録している。その内容例を図１４に示す。図１４に示される例では、田町、品川のように一定のエリアを特定する住所表記によりユーザ端末の地理的な位置を特定しているが、緯度と経度で位置情報を表現することも可能である。
【００８２】
位置情報管理部３１２１は、ユーザ端末１３０−１〜１３０−ｎの位置の変化を検出して、位置情報管理テーブル３１２５を更新する機能を有する。或いは、一定時間置きに更新してもよい。ユーザ端末１３０−１〜１３０−ｎの位置情報は公知の任意の方法で検知することができる。例えば、携帯電話の現在位置を検出して通知する位置情報通知サービスを利用して検知することができる。また、ユーザ端末１３０−１〜１３０−ｎにモバイルＳｕｉｃａ（登録商標）が搭載されている場合には改札通過履歴を利用することも可能である。さらに、携帯電話がどの基地局のエリアにいるかを通信事業者の基地局に知らせる位置登録情報を利用することも可能である。
【００８３】
位置合格数検出部３１２２は、評価対象ユーザの位置情報と電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者の位置情報とを位置情報管理テーブル３１２５から検索し、記評価対象ユーザとの位置関係が所定の条件を満たす登録者の数を計数する部分である。所定の条件とは、位置情報が地区名で表示される場合には同じ地区内にいるという条件や、緯度経度で表現される位置情報の場合には両者の距離が予め定められた距離以内であるという条件を用いることができる。
【００８４】
判定部３１２３は、位置合格数検出部３１２２で検出された登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する部分である。
【００８５】
評価部３１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部３１０は、登録数判定部３１１の登録数評価結果と、ユーザ位置判定部３１２のユーザ位置評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびユーザ位置評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【００８６】
評価部３１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１５に示す。
【００８７】
図１５を参照すると、ユーザ評価要求を受信した評価部３１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【００８８】
次に評価部３１０は、登録数判定部３１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置３１０に予め固定的に設定しておいても良い。
【００８９】
次に評価部３１０は、ユーザ位置判定部３１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、その位置が評価対象ユーザの位置と所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すユーザ位置評価結果を生成する（ステップＳ３０１）。ここで、ユーザ位置評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。また、ユーザ位置評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
【００９０】
次に評価部３１０は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し（ステップＳ３０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００９１】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【００９２】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図１６に示す。
【００９３】
図１６に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部３１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準およびユーザ位置評価用の評価基準として、検索要求で指定された空席数の半分の４を指定したものとする。
【００９４】
評価部３１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部３１０に伝達する。
【００９５】
評価部３１０は、登録数判定部３１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【００９６】
また評価部３１０は、ユーザ位置判定部３１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、評価対象ユーザ１３１−１の位置と所定の条件を満たす位置にいる者の数が評価基準の４以上であれば、「ＯＫ」のユーザ位置評価結果を生成し、それ以外は「ＮＧ」のユーザ位置評価結果を生成する。
【００９７】
次に評価部３１０は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【００９８】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００９９】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち４名以上が評価対象ユーザ１３１−１の近くにいれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【０１００】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの近くに、電話帳に登録された登録者のうちの何人かがいれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【０１０１】
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在位置と評価対象ユーザの現在位置との関係を考慮して、ユーザの評価を行うため、ユーザの人脈の中にユーザの近くにいる者がどれだけいるかを考慮したユーザ評価が可能になる。
【０１０２】
［第４の実施の形態］
図１７を参照すると、本発明の第４の実施の形態に係る情報処理システム４００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部４１０を備えている点で相違する。
【０１０３】
評価部４１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部４１１に加えて、プレゼンス判定部４１２を備えている。
【０１０４】
プレゼンス判定部４１２は、評価対象ユーザと電話帳検索部１５４で取得された登録者情報に含まれる登録者のプレゼンス情報を取得し、プレゼンス情報が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する機能を有する。
【０１０５】
図１８を参照すると、プレゼンス判定部４１２は、プレゼンス管理部４１２１と、プレゼンス検出部４１２２と、判定部４１２３と、プレゼンス情報管理テーブル４１２５を記憶する記憶部４１２４とを備えている。
【０１０６】
プレゼンス情報管理テーブル４１２５は、ユーザ端末１３０−１〜１３０−ｎのユーザ識別子に対応付けて、ユーザ１３１−１〜１３１−ｎのプレゼンス情報を記録している。プレゼンス情報とは、ユーザが今どのような状態にあるかを示す情報であり、通信可能な状態を示す「オンライン」、通信不可能な状態を示す「オフライン」、外出している状態を示す「外出中」、会議中を示す「会議中」などがある。
【０１０７】
プレゼンス管理部４１２１は、ユーザ端末１３０−１〜１３０−ｎのプレゼンス情報の変化を検出して、プレゼンス情報管理テーブル４１２５を更新する機能を有する。一般にプレゼンスシステムは、自分のプレゼンス情報を提供するプレゼンティティと、それを観察するウォッチャ、および、プレゼンティティからプレゼンス情報を受け取り、これをウォッチャに配信するプレゼンスサービス（プレゼンスサーバ）とからなる。プレゼンス管理部４１２１は、プレゼンスシステムにおけるウォッチャとして、プレゼンティティとしてのユーザ端末１３０−１〜１３０−ｎのプレゼンス情報を観察して、プレゼンス情報管理テーブル４１２５に記録する。また、通信事業者サーバ装置１１０がプレゼンスサーバである場合、プレゼンス検出部４１２２をプレゼンスサーバで実現することも可能である。
【０１０８】
プレゼンス検出部４１２２は、電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者のプレゼンス情報をプレゼンス情報管理テーブル４１２５から検索し、所定の条件を満たすプレゼンス情報の登録者の数を計数する部分である。所定の条件は、ユーザ評価要求中で指定しても良いし、評価部４１０に予め設定しておいても良い。
【０１０９】
判定部４１２３は、プレゼンス検出部４１２２で検出された登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する部分である。
【０１１０】
評価部４１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部４１０は、登録数判定部４１１の登録数評価結果と、プレゼンス検出部４１２２のプレゼンス評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびプレゼンス評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【０１１１】
評価部４１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１９に示す。
【０１１２】
図１９を参照すると、ユーザ評価要求を受信した評価部４１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【０１１３】
次に評価部４１０は、登録数判定部４１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【０１１４】
次に評価部４１０は、プレゼンス判定部４１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、そのプレゼンス情報が所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すプレゼンス評価結果を生成する（ステップＳ４０１）。ここで、プレゼンス評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。また、プレゼンス評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
【０１１５】
次に評価部４１０は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し（ステップＳ４０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【０１１６】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【０１１７】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図２０に示す。
【０１１８】
図２０に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部４１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準として、検索要求で指定された空席数の半分の４を指定し、プレゼンス評価用の評価基準として、「外出中」のプレゼンス情報の登録者の数が４名以上であるという基準を指定したものとする。
【０１１９】
評価部４１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部４１０に伝達する。
【０１２０】
評価部４１０は、登録数判定部４１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【０１２１】
また評価部４１０は、プレゼンス判定部４１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、そのプレゼンス情報が「外出中」である者の数が評価基準の４以上であれば、「ＯＫ」のユーザ位置評価結果を生成し、それ以外は「ＮＧ」のユーザ位置評価結果を生成する。
【０１２２】
次に評価部４１０は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【０１２３】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【０１２４】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち４名以上が「外出中」のプレゼンス情報であれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【０１２５】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの電話帳に登録された登録者のうち、４名以上が「外出中」であれば、それらの者が同伴者である可能性があり、冷やかしのユーザでない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【０１２６】
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在のプレゼンス情報を考慮して、ユーザの評価を行うため、ユーザの人脈の中に所定のプレゼンス情報となっている者がどれだけいるかを考慮したユーザ評価が可能になる。
【０１２７】
［その他の実施の形態］
以上本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されず、その他各種の付加変更が可能である。
【０１２８】
例えば、電話帳に記録された登録者情報の数以外の判断材料として、第２の実施の形態では所定のＷｅｂページを閲覧している登録者の数、第３の実施の形態では評価対象ユーザと所定の位置関係にある登録者の数、第４の実施の形態では所定のプレゼンス状態になっている登録者の数を用いたが、これらの判断材料を複数組み合わせる実施の形態や、これら以外の任意の判断材料を組み合わせる実施の形態も考えられる。
【０１２９】
また、前記の各実施の形態では、ユーザの電話帳を通信事業者のサーバ装置の記憶部に記憶して管理していたが、ユーザの電話帳をそのユーザのユーザ端末の記憶部に記憶して管理するようにしても良い。
【０１３０】
また、本発明のユーザ評価装置は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態におけるユーザ評価装置として機能させる。
【符号の説明】
【０１３１】
１００、２００、３００、４００…情報処理システム
１１０…通信事業者サーバ装置
１２０−１〜１２０−ｍ…サービス装置
１３０−１〜１３０−ｎ…ユーザ端末
１４０…通信ネットワーク
１５０…ユーザ評価装置
１５１…記憶部
１５２−１〜１５２−ｎ…電話帳
１５３…電話帳管理部
１５４…電話帳検索部
１５５、２１０、３１０、４１０…評価部
１６１、２１１、３１１、４１１…登録数判定部
【技術分野】
【０００１】
本発明は、ユーザの電話帳に登録された情報に基づいてユーザの人脈に関する評価を行うユーザ評価装置に関する。
【背景技術】
【０００２】
一般に固定電話装置や携帯電話装置などの通信端末には、通信相手の電話番号を複数記憶し、電話をかける際には、相手の名前などから電話番号を検索して自動的に発信させる電話帳機能が備えられている。
【０００３】
また、電話帳を通信端末側で記憶するのではなく、電話サービス事業者側のデータベースに記憶し、個々の通信端末から通信ネットワークを介して電話帳を利用できるシステムが提案されている（例えば、特許文献１、特許文献２参照）。
【０００４】
さらに、ネットワーク側と個々の通信端末側との双方に電話帳を記憶するシステムも提案されている（例えば特許文献３参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１３６２６５号公報
【特許文献２】特開２００４−３０４３５７号公報
【特許文献３】特開平８−２２８３８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
通信端末のユーザが電話帳に登録した情報は、専ら通信相手の電話番号を検索するために利用されており、それ以外の目的で電話帳を利用する例は皆無である。
【０００７】
その理由としては、電話帳に登録された情報は個人情報の一種であるために、第三者が無断で使用すると個人情報の漏洩につながる恐れがあるためである。
【０００８】
しかし、電話帳はユーザの人脈を推測するための貴重な情報になり得るものである。電話番号の検索にしか利用しないのは得策でない。
【０００９】
通信端末の発着信履歴に記載される通信相手と異なり、電話帳に記録される登録者は、親しい友人や付き合いの多い相手など、ユーザと比較的密接なつながりのある人達であることが一般的である。このため、多くの友人や交際相手を持つユーザの電話帳には数多くの登録者が登録される傾向がある。逆に付き合う人の少ないユーザの電話帳の登録人数は少ない傾向を示す。つまり、電話帳の登録者数でその人の人脈の多さ、少なさを或る程度推測することができる。
【００１０】
本発明はこのような点に着目して提案されたものであり、その目的は、電話帳を用いてユーザの人脈に関する評価を行うユーザ評価装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明のユーザ評価装置は、電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段とを備える。
【発明の効果】
【００１２】
本発明によれば、電話帳を用いてユーザの評価を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施の形態に係る情報処理システムのブロック図である。
【図２】電話帳に登録される情報の一例を示す図である。
【図３】電話帳管理部の一例を示すブロック図である。
【図４】本発明の第１の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図５】本発明の第１の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図６】本発明の第２の実施の形態に係る情報処理システムのブロック図である。
【図７】Ｗｅｂ閲覧判定部の一例を示すブロック図である。
【図８】監視対象ＵＲＬ登録テーブルに記録される情報の一例を示す図である。
【図９】Ｗｅｂ閲覧履歴テーブルに記録される情報の一例を示す図である。
【図１０】本発明の第２の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図１１】本発明の第２の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図１２】本発明の第３の実施の形態に係る情報処理システムのブロック図である。
【図１３】ユーザ位置判定部の一例を示すブロック図である。
【図１４】位置情報管理テーブルに記録される情報の一例を示す図である。
【図１５】本発明の第３の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図１６】本発明の第３の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【図１７】本発明の第４の実施の形態に係る情報処理システムのブロック図である。
【図１８】プレゼンス判定部の一例を示すブロック図である。
【図１９】本発明の第４の実施の形態におけるユーザ評価装置で実行される処理の流れを示すフローチャートである。
【図２０】本発明の第４の実施の形態に係る情報処理システムの処理例を示すシーケンス図である。
【発明を実施するための形態】
【００１４】
［第１の実施の形態］
図１を参照すると、本発明の第１の実施の形態に係る情報処理システム１００は、通信事業者サーバ装置１１０と、複数のサービス装置１２０−１〜１２０−ｍと、複数のユーザ端末１３０−１〜１３０−ｎとが通信ネットワーク１４０を介して接続されている。
【００１５】
通信ネットワーク１４０は、通信事業者が運営するＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワークである。
【００１６】
ユーザ端末１３０−１〜１３０−ｎは、ユーザ１３１−１〜１３１−ｎが所有する携帯電話装置やＰＤＡなどの音声通話機能およびインターネット接続機能を有する通信端末である。ユーザ端末１３０−１〜１３０−ｎには、電話番号とユーザ識別子とが割り当てられている。ユーザ識別子は、ユーザ端末１３０−１〜１３０−ｎまたはユーザ１３１−１〜１３１−ｎを識別する値である。ユーザ識別子は、ユーザ１３１−１〜１３１−ｎが通信事業者の通信サービスの会員として加入する際に、通信事業者から割り当てられる。一般に加入時には、氏名や住所などの個人情報を登録する必要がある。ユーザ識別子は、例えば携帯電話ならＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ Ｃａｒｄ）カードによって付与され、電話番号やメールアドレスを特定するための固有のＩＤであるＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）などが利用できる。
【００１７】
通信事業者サーバ装置１１０は、固定電話や携帯電話等の電気通信サービスを提供する通信事業者のサーバコンピュータである。通信ネットワーク１４０経由によるユーザ端末１３０−１〜１３０−ｎ間およびユーザ端末１３０−１〜１３０−ｎとサービス装置１２０−１〜１２０−ｍ間の通信はすべて、この通信事業者サーバ装置１１０の制御の下で実施される。
【００１８】
本実施の形態においては、通信事業者サーバ装置１１０に、ユーザ評価装置１５０を配置している。ユーザ評価装置１５０は、記憶部１５１と、電話帳管理部１５３と、電話帳検索部１５４と、評価部１５５とを備えている。
【００１９】
記憶部１５１は、磁気ディスク等で構成され、通信事業者サーバ装置１１０を運用する通信事業者に加入しているユーザ１３１−１〜１３１−ｎの電話帳１５２−１〜１５２−ｎを記憶する。
【００２０】
電話帳に登録される情報の一例を図２に示す。図２を参照すると、電話帳には、ユーザ名と電話番号とユーザ識別子と最新通信時刻とから構成される登録者情報が複数記憶できるようになっている。個々の登録者情報に含まれるユーザ名は、この電話帳の持ち主が通信相手を識別するために付けた名前であり、一般的には通信相手の名前である。電話番号はその通信相手の電話番号である。電話帳の持ち主自身が登録するのは、このユーザ名と電話番号の情報だけであり、残りのユーザ識別子と最新通信時刻の情報は電話帳管理部１５３が自動的に付与する。最新通信時刻は、最後に通信が行われた日を示す。日だけでなく、時、分も含めても良い。また電話帳には、その電話帳がどのユーザのものであるかを識別するために、ユーザ識別子が付与されている。図２の電話帳には、ユーザ識別子ｕｓｅｒ００１が付与されており、この電話帳がユーザ識別子ｕｓｅｒ００１を持つユーザの電話帳であることが示されている。さらに本実施の形態では、本人の電話番号も電話帳に記憶している。図２の場合、０９０−１１１Ｘ−１１１Ｘがこの電話帳を保持するユーザの電話番号である。なお、電話帳の構成は図２の構成に限定されない。通信相手の住所やメールアドレス等の情報を登録した電話帳であっても良い。
【００２１】
電話帳管理部１５３は、ユーザ１３１−０〜１３１−ｎの電話帳１５２−１〜１５２−ｎを記憶部１５１に保持して管理する。電話帳管理部１５３は、通信ネットワーク１４０経由でアクセスしてきたユーザ端末１３０−１〜１３０−ｎからの要求に従って、記憶部１５１にユーザ１３１−１〜１３１−ｎの電話帳を新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索の機能を提供する。また電話帳管理部１５３は、通信事業者サーバ装置１１０の制御の下で行われた通信履歴を参照して、記憶部１５１に記憶された電話帳１５２−１〜１５２−ｎの各登録者情報中の最新通信時刻を更新する機能を有する。さらに電話帳管理部１５３は、電話帳検索部１５４から検索を要求された電話帳に登録された登録者情報を記憶部１５１から読み出して、電話帳検索部１５４へ出力する機能を有する。
【００２２】
図３を参照すると、電話帳管理部１５３の一例は、ユーザ要求処理部１５３１と、電話番号正当性判定部１５３２と、最新通信時刻更新部１５３３と、検索要求処理部１５３４とを備えている。
【００２３】
電話番号正当性判定部１５３２は、新たに電話帳に登録する電話番号が正当か否かを判定する部分である。本実施の形態では、電話番号が正当か否かの判定は、電話番号に対応するユーザ識別子が加入者データベース１５３５に記録されているか否かを調べることで行う。一般に、通信ネットワーク１４０を運用する通信事業者の加入者データベース１５３５には、加入ユーザの電話番号とユーザ識別子との対応が記録されているため、加入者データベース１５３５に対応するユーザ識別子が記録されている電話番号は、正当な電話番号であると判定できる。なお、加入者データベース１５３５は、通信事業者サーバ装置１１０内に備えられるか、あるいは通信事業者サーバ装置１１０からアクセス可能な他のサーバ内に備えられている。また、自社の加入者データベース１５３５に登録の無い電話番号は一律に不正な電話番号として扱っても良いし、自社以外の通信事業者に対して対応するユーザ識別子の有無を問い合わせて、その結果に従って判定するようにしても良い。
【００２４】
ユーザ要求処理部１５３１は、ユーザ端末１３０−１〜１３０−ｎからの要求に従って、記憶部１５１にユーザ１３１−１〜１３１−ｎの電話帳１５２−１〜１５２−ｎを新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索のサービスをユーザ端末１３０−１〜１３０−ｎに提供する部分である。ここで、ユーザ要求処理部１５３１は、ユーザ端末１３０−１〜１３０−ｎからの要求に従って新たな電話番号を電話帳に登録する際には、その電話番号の正当性を電話番号正当性判定部１５３２を用いて判定し、正当と判定された電話番号には、そのことを示すために、電話番号との対応がとれたユーザ識別子を電話帳に記録する。
【００２５】
最新通信時刻更新部１５３３は、記憶部１５１に記憶された電話帳１５２−１〜１５２−ｎの各登録者情報中の最新通信時刻を更新する部分である。具体的には、通信事業者サーバ装置１１０の制御によって、発信側通信端末および着信側通信端末との間に通信が行われた場合、双方の通信端末の電話番号あるいはユーザ識別子の組み合わせを持つ電話帳の登録者情報を記憶部１５１中から検索し、該当する登録者情報中の最新通信時刻を現在時刻で上書きする。例えば、ユーザ識別子ｕｓｅｒ００１のユーザ端末とユーザ識別子ｕｓｅｒ００２のユーザ端末との間で通信が行われた場合、最新通信時刻更新部１５３３は、ユーザ識別子ｕｓｅｒ００１を持つ電話帳の中にユーザ識別子ｕｓｅｒ００２を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。さらに最新通信時刻更新部１５３３は、ユーザ識別子ｕｓｅｒ００２を持つ電話帳の中にユーザ識別子ｕｓｅｒ００１を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。
【００２６】
検索要求処理部１５３４は、電話帳検索部１５４から検索の要求された電話帳に登録された登録者情報を記憶部１５１から読み出して、電話帳検索部１５４へ出力する部分である。
【００２７】
再び図１を参照すると、電話帳検索部１５４は、評価部１５５からの要求に従って、電話帳管理部１５３で管理されている電話帳のうち評価対象ユーザの電話帳に記録された登録者情報を取得し、評価部１５５へ通知する機能を有する。ここで、電話帳検索部１５４は、ユーザ識別子が付与されていない登録情報は電話番号が信用できないものと判断して取得の対象から除外する。また、電話帳検索部１５４は、現在から過去一定期間内の時刻が最新通信時刻に記録されていない登録情報は、交流が途絶えて久しい登録者と見做して、取得の対象から除外する。
【００２８】
評価部１５５は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部１５５は、評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを判定する登録数判定部１６１を備えている。
【００２９】
評価部１５５がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図４に示す。
【００３０】
図４を参照すると、ユーザ評価要求を受信した評価部１５５は、電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求する（ステップＳ１０１）。評価対象ユーザの指定は、例えばユーザ識別子で行う。
【００３１】
電話帳検索部１５４は、まず、電話帳管理部１５４を通じて評価対象ユーザの電話帳に記録された登録者情報を取得する（ステップＳ１０２）。次に、取得した登録者情報のうち、ユーザ識別子が付加されていない登録者情報、および最新通信時刻から過去所定期間内に一度も通信が行われていない登録者情報を除去する（ステップＳ１０３）。そして、残った登録者情報を評価部１５５に伝達する（ステップＳ１０４）。
【００３２】
評価部１５５は、登録数判定部１６１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【００３３】
次に評価部１５５は、登録数評価結果をユーザ評価結果とし（ステップＳ１０６）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００３４】
サービス装置１２０−１〜１２０−ｍは、サービス事業者が通信ネットワーク１４０を介してユーザ端末１３０−１〜１３０−ｎのユーザ１３１−１〜１３１−ｎに対してサービスを提供するためのサーバコンピュータである。サービス装置１２０−１〜１２０−ｍは、ユーザ端末１３０−１〜１３０−ｎからサービス要求を受信したとき、ユーザ端末１３０−１〜１３０−ｎのユーザ１３１−１〜１３１−ｎを評価対象ユーザに指定したユーザ評価要求を通信ネットワーク１４０経由でユーザ評価装置１５０へ送信し、ユーザ評価装置１５０から返される評価対象ユーザの評価結果に従って、サービス要求に対して提供するサービス内容を変更する機能を有する。
【００３５】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、各種考えられる。以下に幾つかの例を示す。
【００３６】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図５に示す。
【００３７】
図５に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部１５５に対してユーザ評価を要求する。ここでは、評価基準として、検索要求で指定された空席数の半分の４を指定したものとする。なお、検索要求で指定された空席数の半分を評価基準とするのは、あくまでも一例である。検索要求で指定された空席数と同じ数を評価基準としたり、検索要求で指定された空席数とは無関係にあらかじめ定められた定数値を指定するようにしてもよい。
【００３８】
評価部１５５は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳に登録された登録者情報を取得し、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部１５５に伝達する。例えば、ユーザ識別子ｕｓｅｒ００１で特定されるユーザの電話帳に図２に示した７名分の登録者情報が登録されている場合、ユーザ名Ｄ、Ｇの登録者情報にはユーザ識別子が記録されていないので、これらの登録者情報が除外される。また、現在日時を２００８年１１月２０日とし、過去１年以上にわたって通信が行われていない登録者情報を除外するとする場合、ユーザＨの登録者情報が除かれる。結局、電話帳検索部１５４は、ユーザＢ、Ｃ、Ｅ、Ｆの４名分の登録者情報を評価部１５５に伝達する。
【００３９】
評価部１５５は、登録数判定部１６１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。次に、評価部１５５は、登録数評価結果をユーザ評価結果として生成し、サービス装置１２０−１へ送信する。
【００４０】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００４１】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、４名以上の登録者情報が無ければ、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【００４２】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【００４３】
＜サービスの例２＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、特定の飲食店の予約をインターネット経由でリアルタイムに受け付ける予約受け付けサービスであっても良い。この場合、サービス装置１２０−１は、飲食店の空席情報を含む案内情報をリアルタイムに更新してデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの条件を指定して予約を要求すると、サービス装置は、予約を受け付けることができるか否かをデータベース中の案内情報を参照して決定し、予約可能ならば予約を受け付けた旨の通知を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、予約しようとするユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、予約者に特典を付与する。
【００４４】
具体的には、サービス装置１２０−１は、例１と同様に評価部１５５に対してユーザ評価要求を送信する。このとき、評価基準として、例えば登録者情報の数が３０以上を指定する。そして、サービス装置１２０−１は、評価部１５５のユーザ評価結果がＯＫであれば、つまりユーザの電話帳に３０人以上の登録者が登録されていれば、例えば、特典として１０％の割引を予約者に与え、ＮＧであれば、つまり３０人未満であれば、そのような特典は与えない。その理由は、３０人以上の登録者が電話帳に登録されているような人脈のあるユーザを顧客にできれば、その者の口コミによって顧客の増大を期待できるためである。
【００４５】
このように本実施の形態によれば、電話帳の登録者情報の数に基づいてユーザの人脈の多少に関する評価を行う。電話帳に記録される登録者は、親しい友人や付き合いの多い相手など、ユーザと比較的密接なつながりのある相手である場合が多いため、他の情報、例えば儀礼的に交換される名刺や年賀状の保有枚数に基づいて行う評価に比べて、より確かな評価を下すことができる。
【００４６】
また本実施の形態によれば、ユーザ識別子との対応がとれない電話番号を含む登録情報を除外して評価を行うために、不正な電話番号が登録されていたとしても、それらに影響されずに評価を行うことができる。
【００４７】
また本実施の形態によれば、過去所定期間に一度も通信されていない登録者を除外して評価を行うために、電話帳に電話番号を登録したものの一度も連絡していない相手や、過去には良く連絡を取り合っていたが最近は全く連絡し合っていない相手を除外した評価が可能になる。
【００４８】
また本実施の形態によれば、サービス事業者、通信事業者およびユーザのそれぞれに対して有効な効果が生じる。まずサービス事業者にとっては、ユーザ端末のユーザの評価結果に応じて、提供するサービス内容を変更することができ、従来にないサービス展開が可能になる。また通信事業者にとっては、個人情報の漏洩につなげずに、通信事業者側で管理するユーザの電話帳の情報をユーザの評価という新たな形で提供でき、収益につなげることができる。そして、ユーザにとっては、サービスを利用する際に、サービス事業者が通信事業者からのユーザ評価結果に基づいてサービス展開をするので、より良いサービスを受けることができる。
【００４９】
［第２の実施の形態］
図６を参照すると、本発明の第２の実施の形態に係る情報処理システム２００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部２１０を備えている点で相違する。
【００５０】
評価部２１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部２１１に加えて、Ｗｅｂ閲覧判定部２１２を備えている。
【００５１】
Ｗｅｂ閲覧判定部２１２は、電話帳検索部１５４で取得された登録者情報に含まれる登録者について、所定のＷｅｂサーバのコンテンツを閲覧しているか否かを前記Ｗｅｂサーバの閲覧履歴を参照して判定し、閲覧している登録者の数が評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する機能を有する。
【００５２】
図７を参照すると、Ｗｅｂ閲覧判定部２１２は、Ｗｅｂサーバ閲覧監視部２１２１と、閲覧者数検出部２１２２と、判定部２１２３と、監視対象ＵＲＬ登録テーブル２１２４と、Ｗｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍを記憶する記憶部２１２５とを備えている。
【００５３】
監視対象ＵＲＬ登録テーブル２１２４は、サービス装置１２０−１〜１２０−ｍを運用するサービス事業者を一意に識別するサービス事業者識別子に対応付けて、そのサービス事業者が事前に申請したＷｅｂページのＵＲＬを記録している。その内容例を図８に示す。図８に示されるように、サービス事業者識別子に対応付けて登録するＵＲＬは１つでも良いし、２つ以上であっても良い。ＵＲＬで特定されるＷｅｂページは、対応するサービス事業者識別子で特定されるサービス事業者のホームページなどであっても良いし、別のサービス事業者のホームページなどであっても良い。
【００５４】
Ｗｅｂサーバ閲覧監視部２１２１は、監視対象ＵＲＬ登録テーブル２１２４に記録されたＵＲＬに対してアクセスを行ったユーザ端末１３０−１〜１３０−ｎを検出し、検出結果を記憶部２１２５のＷｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍに記録する。Ｗｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍは、サービス事業者識別子に１対１に対応している。Ｗｅｂサーバ閲覧監視部２１２１は、監視対象ＵＲＬ登録テーブル２１２４の或るサービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出すると、そのサービス事業者識別子に対応するＷｅｂ閲覧履歴テーブルにユーザ端末１３０−１〜１３０−ｎのユーザ識別子を閲覧日の情報を添えて記録する。図９にサービス事業者識別子ｓｅｒｖｉｃｅ００１に対応するＷｅｂ閲覧履歴テーブルの記録情報の例を示す。
【００５５】
Ｗｅｂサーバ閲覧監視部２１２１が、ユーザ端末１３０−１〜１３０−ｎのＷｅｂ閲覧を監視する方法としては、プロキシを用いる方法、デバイスマネージメントを用いる方法が考えられる。プロキシを用いる方法では、ユーザ端末１３０−１〜１３０−ｎからｗｅｂページを直接アクセスするのではなく、Ｗｅｂ閲覧判定部２１２が代理としてアクセスを行い、その過程で、サービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出する方法である。デバイスマネージメントとは、ネットワークにアクセスするユーザ端末１３０−１〜１３０−ｎのデバイス情報やユーザ情報の収集、管理、書き込みを行うシステムのことである。デバイスマネージメントを用いてユーザ端末１３０−１〜１３０−ｎのＷｅｂ閲覧履歴を吸い上げて、サービス事業者識別子に対応付けて記録されたＵＲＬにユーザ端末１３０−１〜１３０−ｎがアクセスしたことを検出する。
【００５６】
閲覧者数検出部２１２２は、電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者について、所定のＷｅｂサーバのコンテンツを閲覧しているか否かをＷｅｂ閲覧履歴テーブル２１２６−１〜２１２６−ｍを参照して判定し、登録者のうち所定のＷｅｂサーバのコンテンツを閲覧している閲覧者数を検出する部分である。
【００５７】
判定部２１２３は、閲覧者数検出部２１２２で検出された閲覧者数が評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する部分である。
【００５８】
評価部２１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部２１０は、登録数判定部２１１の登録数評価結果と、Ｗｅｂ閲覧判定部２１２のＷｅｂ閲覧評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびＷｅｂ閲覧評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【００５９】
評価部２１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１０に示す。
【００６０】
図１０を参照すると、ユーザ評価要求を受信した評価部２１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【００６１】
次に評価部２１０は、登録数判定部２１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【００６２】
次に評価部２１０は、Ｗｅｂ閲覧判定部２１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、所定のＷｅｂページを過去一定期間（例えば１日）内に閲覧した者の数を計数し、評価基準を満足するか否かを示すＷｅｂ閲覧評価結果を生成する（ステップＳ２０１）。ここで、Ｗｅｂ閲覧評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置２１０に予め固定的に設定しておいても良い。また、Ｗｅｂ閲覧評価の評価基準は、登録数判定評価の評価基準と同じであっても良いし、相違していても良い。
【００６３】
次に評価部２１０は、登録数評価結果とＷｅｂ閲覧評価結果とからユーザ評価結果を生成し（ステップＳ２０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００６４】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【００６５】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。
【００６６】
また、飲食店の空席情報の検索サービスを利用して実際に飲食店で食事する人達のＷｅｂ閲覧履歴の傾向を分析した結果に基づいて、その人達が良く見るＷｅｂページのＵＲＬを自サービス事業者の識別子に対応付けて評価部２１０の監視対象ＵＲＬ登録テーブル２１２４に登録する手続きを行っておく。
【００６７】
何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図１１に示す。
【００６８】
図１１に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部２１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数判定用の評価基準として、検索要求で指定された空席数の半分の４を指定し、Ｗｅｂ閲覧判定用の評価基準として例えば１を指定したものとする。
【００６９】
評価部２１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部２１０に伝達する。
【００７０】
評価部２１０は、登録数判定部２１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【００７１】
また評価部２１０は、Ｗｅｂ閲覧判定部２１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、監視対象ＵＲＬ登録テーブル２１２４にサービス装置１２０−１の識別子に対応付けて記録されたＵＲＬのＷｅｂページを閲覧している者の数が評価基準の１以上であれば、「ＯＫ」のＷｅｂ閲覧評価結果を生成し、それ以外は「ＮＧ」のＷｅｂ閲覧評価結果を生成する。
【００７２】
次に評価部２１０は、登録数評価結果とＷｅｂ閲覧評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【００７３】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００７４】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち少なくとも１名の者が所定のＷｅｂページを２４時間以内に閲覧していれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【００７５】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、自サービス事業者の提供する飲食店の空席情報の検索サービスを利用して実際に飲食店で食事したユーザに対するアンケート調査など事前に得ている良く閲覧するＷｅｂページを、登録者の少なくとも一人が閲覧していれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【００７６】
このように本実施の形態によれば、電話帳の登録者の数に加えて、その登録者のうち所定のＷｅｂページを閲覧した者の数も考慮してユーザを評価するため、ユーザの人脈の中に所定のＷｅｂページを良く閲覧する者がどれだけいるかを考慮したユーザ評価が可能になる。
【００７７】
［第３の実施の形態］
図１２を参照すると、本発明の第３の実施の形態に係る情報処理システム３００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部３１０を備えている点で相違する。
【００７８】
評価部３１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部３１１に加えて、ユーザ位置判定部３１２を備えている。
【００７９】
ユーザ位置判定部３１２は、評価対象ユーザと電話帳検索部１５４で取得された登録者情報に含まれる登録者の位置情報を取得し、評価対象ユーザとの位置関係が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する機能を有する。
【００８０】
図１３を参照すると、ユーザ位置判定部３１２は、位置情報管理部３１２１と、位置合格数検出部３１２２と、判定部３１２３と、位置情報管理テーブル３１２５を記憶する記憶部３１２４とを備えている。
【００８１】
位置情報管理テーブル３１２５は、ユーザ端末１３０−１〜１３０−ｎのユーザ識別子に対応付けて、その地理的な位置情報を記録している。その内容例を図１４に示す。図１４に示される例では、田町、品川のように一定のエリアを特定する住所表記によりユーザ端末の地理的な位置を特定しているが、緯度と経度で位置情報を表現することも可能である。
【００８２】
位置情報管理部３１２１は、ユーザ端末１３０−１〜１３０−ｎの位置の変化を検出して、位置情報管理テーブル３１２５を更新する機能を有する。或いは、一定時間置きに更新してもよい。ユーザ端末１３０−１〜１３０−ｎの位置情報は公知の任意の方法で検知することができる。例えば、携帯電話の現在位置を検出して通知する位置情報通知サービスを利用して検知することができる。また、ユーザ端末１３０−１〜１３０−ｎにモバイルＳｕｉｃａ（登録商標）が搭載されている場合には改札通過履歴を利用することも可能である。さらに、携帯電話がどの基地局のエリアにいるかを通信事業者の基地局に知らせる位置登録情報を利用することも可能である。
【００８３】
位置合格数検出部３１２２は、評価対象ユーザの位置情報と電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者の位置情報とを位置情報管理テーブル３１２５から検索し、記評価対象ユーザとの位置関係が所定の条件を満たす登録者の数を計数する部分である。所定の条件とは、位置情報が地区名で表示される場合には同じ地区内にいるという条件や、緯度経度で表現される位置情報の場合には両者の距離が予め定められた距離以内であるという条件を用いることができる。
【００８４】
判定部３１２３は、位置合格数検出部３１２２で検出された登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する部分である。
【００８５】
評価部３１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部３１０は、登録数判定部３１１の登録数評価結果と、ユーザ位置判定部３１２のユーザ位置評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびユーザ位置評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【００８６】
評価部３１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１５に示す。
【００８７】
図１５を参照すると、ユーザ評価要求を受信した評価部３１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【００８８】
次に評価部３１０は、登録数判定部３１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置３１０に予め固定的に設定しておいても良い。
【００８９】
次に評価部３１０は、ユーザ位置判定部３１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、その位置が評価対象ユーザの位置と所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すユーザ位置評価結果を生成する（ステップＳ３０１）。ここで、ユーザ位置評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。また、ユーザ位置評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
【００９０】
次に評価部３１０は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し（ステップＳ３０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【００９１】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【００９２】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図１６に示す。
【００９３】
図１６に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部３１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準およびユーザ位置評価用の評価基準として、検索要求で指定された空席数の半分の４を指定したものとする。
【００９４】
評価部３１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部３１０に伝達する。
【００９５】
評価部３１０は、登録数判定部３１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【００９６】
また評価部３１０は、ユーザ位置判定部３１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、評価対象ユーザ１３１−１の位置と所定の条件を満たす位置にいる者の数が評価基準の４以上であれば、「ＯＫ」のユーザ位置評価結果を生成し、それ以外は「ＮＧ」のユーザ位置評価結果を生成する。
【００９７】
次に評価部３１０は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【００９８】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【００９９】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち４名以上が評価対象ユーザ１３１−１の近くにいれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【０１００】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの近くに、電話帳に登録された登録者のうちの何人かがいれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【０１０１】
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在位置と評価対象ユーザの現在位置との関係を考慮して、ユーザの評価を行うため、ユーザの人脈の中にユーザの近くにいる者がどれだけいるかを考慮したユーザ評価が可能になる。
【０１０２】
［第４の実施の形態］
図１７を参照すると、本発明の第４の実施の形態に係る情報処理システム４００は、図１に示した情報処理システム１００と比較して、評価部１５５の代わりに評価部４１０を備えている点で相違する。
【０１０３】
評価部４１０は、図１に示した登録数判定部１６１と同等の機能を有する登録数判定部４１１に加えて、プレゼンス判定部４１２を備えている。
【０１０４】
プレゼンス判定部４１２は、評価対象ユーザと電話帳検索部１５４で取得された登録者情報に含まれる登録者のプレゼンス情報を取得し、プレゼンス情報が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する機能を有する。
【０１０５】
図１８を参照すると、プレゼンス判定部４１２は、プレゼンス管理部４１２１と、プレゼンス検出部４１２２と、判定部４１２３と、プレゼンス情報管理テーブル４１２５を記憶する記憶部４１２４とを備えている。
【０１０６】
プレゼンス情報管理テーブル４１２５は、ユーザ端末１３０−１〜１３０−ｎのユーザ識別子に対応付けて、ユーザ１３１−１〜１３１−ｎのプレゼンス情報を記録している。プレゼンス情報とは、ユーザが今どのような状態にあるかを示す情報であり、通信可能な状態を示す「オンライン」、通信不可能な状態を示す「オフライン」、外出している状態を示す「外出中」、会議中を示す「会議中」などがある。
【０１０７】
プレゼンス管理部４１２１は、ユーザ端末１３０−１〜１３０−ｎのプレゼンス情報の変化を検出して、プレゼンス情報管理テーブル４１２５を更新する機能を有する。一般にプレゼンスシステムは、自分のプレゼンス情報を提供するプレゼンティティと、それを観察するウォッチャ、および、プレゼンティティからプレゼンス情報を受け取り、これをウォッチャに配信するプレゼンスサービス（プレゼンスサーバ）とからなる。プレゼンス管理部４１２１は、プレゼンスシステムにおけるウォッチャとして、プレゼンティティとしてのユーザ端末１３０−１〜１３０−ｎのプレゼンス情報を観察して、プレゼンス情報管理テーブル４１２５に記録する。また、通信事業者サーバ装置１１０がプレゼンスサーバである場合、プレゼンス検出部４１２２をプレゼンスサーバで実現することも可能である。
【０１０８】
プレゼンス検出部４１２２は、電話帳検索部１５４で取得された登録者情報に含まれるそれぞれの登録者のプレゼンス情報をプレゼンス情報管理テーブル４１２５から検索し、所定の条件を満たすプレゼンス情報の登録者の数を計数する部分である。所定の条件は、ユーザ評価要求中で指定しても良いし、評価部４１０に予め設定しておいても良い。
【０１０９】
判定部４１２３は、プレゼンス検出部４１２２で検出された登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する部分である。
【０１１０】
評価部４１０は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク１４０経由でサービス装置１２０−１〜１２０−ｍから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク１４０経由で要求元のサービス装置１２０−１〜１２０−ｍに送信する機能を有する。本実施の形態の評価部４１０は、登録数判定部４１１の登録数評価結果と、プレゼンス検出部４１２２のプレゼンス評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびプレゼンス評価結果の双方が「ＯＫ」である場合に限り、「ＯＫ」のユーザ評価結果を生成する。
【０１１１】
評価部４１０がサービス装置１２０−１〜１２０−ｍからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置１２０−１〜１２０−ｍへ送信するまでにユーザ評価装置１５０で実行される処理の流れを図１９に示す。
【０１１２】
図１９を参照すると、ユーザ評価要求を受信した評価部４１０が電話帳検索部１５４に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部１５４から登録者情報を受け取るまでの処理は図４の処理と同じである（ステップＳ１０１〜Ｓ１０４）。
【０１１３】
次に評価部４１０は、登録数判定部４１１により、電話帳検索部１５４から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する（ステップＳ１０５）。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。
【０１１４】
次に評価部４１０は、プレゼンス判定部４１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、そのプレゼンス情報が所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すプレゼンス評価結果を生成する（ステップＳ４０１）。ここで、プレゼンス評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置１５０に予め固定的に設定しておいても良い。また、プレゼンス評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
【０１１５】
次に評価部４１０は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し（ステップＳ４０２）、ユーザ評価要求元に送信する（ステップＳ１０７）。
【０１１６】
サービス装置１２０−１〜１２０−ｍが提供するサービスの種類や内容は、第１の実施の形態と同様に各種考えられる。以下に一例を示す。
【０１１７】
＜サービスの例１＞
何れかのサービス装置、例えばサービス装置１２０−１の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置１２０−１は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末１３０−１のユーザ１３１−１が通信ネットワーク１４０を介してサービス装置１２０−１にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置１２０−１は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末１３０−１へ送信する。このとき、サービス装置１２０−１は、検索を要求してきたユーザ１３１−１を評価対象ユーザとしたユーザ評価要求をユーザ評価装置１５０に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図２０に示す。
【０１１８】
図２０に示されるように、ユーザ端末１３０−１のユーザ１３１−１が、例えば８人分の空席があるレストランの検索要求をサービス装置１２０−１に対して送信したとする。なお、この検索要求にはユーザ端末１３０−１のユーザ識別子が付加されており、その値はｕｓｅｒ００１であるものとする。サービス装置１２０−１は、検索を要求したユーザ端末１３０−１のユーザ識別子と評価基準とを指定して、評価部４１０に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準として、検索要求で指定された空席数の半分の４を指定し、プレゼンス評価用の評価基準として、「外出中」のプレゼンス情報の登録者の数が４名以上であるという基準を指定したものとする。
【０１１９】
評価部４１０は、ユーザ識別子ｕｓｅｒ００１を指定して電話帳検索部１５４に対して登録者情報の取得を要求する。電話帳検索部１５４は、電話帳管理部１５３を通じて、ユーザ識別子ｕｓｅｒ００１で特定されるユーザ１３１−１の電話帳１５２−１に登録された登録者情報を取得し、第１の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部４１０に伝達する。
【０１２０】
評価部４１０は、登録数判定部４１１により、電話帳検索部１５４から受け取った登録者情報の数が評価基準の４以上であれば、「ＯＫ」の登録数評価結果を生成し、それ以外は「ＮＧ」の登録数評価結果を生成する。
【０１２１】
また評価部４１０は、プレゼンス判定部４１２により、電話帳検索部１５４から受け取った登録者情報の登録者のうち、そのプレゼンス情報が「外出中」である者の数が評価基準の４以上であれば、「ＯＫ」のユーザ位置評価結果を生成し、それ以外は「ＮＧ」のユーザ位置評価結果を生成する。
【０１２２】
次に評価部４１０は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し、サービス装置１２０−１へ送信する。
【０１２３】
サービス装置１２０−１は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「ＯＫ」であれば、空席数が８以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末１３０−１へ送信する。他方、ユーザ評価結果が「ＮＧ」であれば、そのような検索結果の送信は行わない。
【０１２４】
このように本例では、８席以上の空席があるレストランの検索要求を出したユーザ１３１−１の電話帳１５２−１に４名以上の登録者情報があり、且つ、その登録者のうち４名以上が「外出中」のプレゼンス情報であれば、この検索要求に従って８席以上の空席があるレストランの検索結果をユーザ１３１−１に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
【０１２５】
まず、８人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の４名以上の登録者が記録されているのはごく普通のことであり、３名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの電話帳に登録された登録者のうち、４名以上が「外出中」であれば、それらの者が同伴者である可能性があり、冷やかしのユーザでない確率がさらに高まることがもう一つの理由である。さらに別の理由として、８以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
【０１２６】
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在のプレゼンス情報を考慮して、ユーザの評価を行うため、ユーザの人脈の中に所定のプレゼンス情報となっている者がどれだけいるかを考慮したユーザ評価が可能になる。
【０１２７】
［その他の実施の形態］
以上本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されず、その他各種の付加変更が可能である。
【０１２８】
例えば、電話帳に記録された登録者情報の数以外の判断材料として、第２の実施の形態では所定のＷｅｂページを閲覧している登録者の数、第３の実施の形態では評価対象ユーザと所定の位置関係にある登録者の数、第４の実施の形態では所定のプレゼンス状態になっている登録者の数を用いたが、これらの判断材料を複数組み合わせる実施の形態や、これら以外の任意の判断材料を組み合わせる実施の形態も考えられる。
【０１２９】
また、前記の各実施の形態では、ユーザの電話帳を通信事業者のサーバ装置の記憶部に記憶して管理していたが、ユーザの電話帳をそのユーザのユーザ端末の記憶部に記憶して管理するようにしても良い。
【０１３０】
また、本発明のユーザ評価装置は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態におけるユーザ評価装置として機能させる。
【符号の説明】
【０１３１】
１００、２００、３００、４００…情報処理システム
１１０…通信事業者サーバ装置
１２０−１〜１２０−ｍ…サービス装置
１３０−１〜１３０−ｎ…ユーザ端末
１４０…通信ネットワーク
１５０…ユーザ評価装置
１５１…記憶部
１５２−１〜１５２−ｎ…電話帳
１５３…電話帳管理部
１５４…電話帳検索部
１５５、２１０、３１０、４１０…評価部
１６１、２１１、３１１、４１１…登録数判定部
【特許請求の範囲】
【請求項１】
電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、
前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、
評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段とを備えることを特徴とするユーザ評価装置。
【請求項２】
前記電話帳管理手段は、登録者情報に含まれる電話番号の有効、無効を判定してその結果を当該登録者情報に記録し、
前記電話帳検索手段は、無効と判定された電話番号の登録者情報を取得の対象から除外することを特徴とする請求項１に記載のユーザ評価装置。
【請求項３】
前記電話帳管理手段は、登録者情報に含まれる電話番号に対応するユーザ識別子が、電話番号とユーザ識別子との対応を保持する加入者データベースに記録されているか否かを調べることにより、電話番号の有効、無効を判定することを特徴とする請求項２に記載のユーザ評価装置。
【請求項４】
前記電話帳管理手段は、ユーザの電話番号またはそれに対応するユーザ識別子で特定されるユーザ端末と当該ユーザの電話帳に記録されている登録者情報中の電話番号またはそれに対応するユーザ識別子で特定される通信端末との間で行われた通信を検出して、その通信時刻を当該登録者情報に記録し、
前記電話帳検索手段は、過去所定期間内に通信が一度も行われていない登録者情報を取得の対象から除外することを特徴とする請求項１に記載のユーザ評価装置。
【請求項５】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者のうち、所定の条件を満足する登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項６】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者について、所定のＷｅｂページを閲覧しているか否かを前記Ｗｅｂサーバの閲覧履歴を参照して判定し、閲覧している登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項７】
前記評価手段は、前記評価対象ユーザと前記電話帳検索手段で取得された登録者情報に含まれる登録者の位置情報を取得し、前記評価対象ユーザとの位置関係が所定の条件を満たす登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項８】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者のうち、そのプレゼンス情報が所定の条件を満たす登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項９】
請求項１乃至８の何れか１項に記載されたユーザ評価装置と、サービス装置と、ユーザ端末とが通信ネットワークを介して接続され、前記サービス装置は、前記ユーザ端末からサービス要求を受信したとき、前記ユーザ端末のユーザを評価対象ユーザに指定したユーザ評価要求を前記ユーザ評価装置へ送信し、前記ユーザ評価装置から受信した前記評価対象ユーザの評価結果に従って前記サービス要求に対して提供するサービス内容を変更することを特徴とする情報処理システム。
【請求項１０】
評価手段が、評価対象ユーザを指定したユーザ評価要求を入力し、
電話帳検索手段が、前記評価対象ユーザの電話帳に記録された登録者情報を取得し、
前記評価手段が、前記取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力することを特徴とするユーザ評価方法。
【請求項１１】
コンピュータを、
電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、
前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、
評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段として機能させるためのプログラム。
【請求項１】
電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、
前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、
評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段とを備えることを特徴とするユーザ評価装置。
【請求項２】
前記電話帳管理手段は、登録者情報に含まれる電話番号の有効、無効を判定してその結果を当該登録者情報に記録し、
前記電話帳検索手段は、無効と判定された電話番号の登録者情報を取得の対象から除外することを特徴とする請求項１に記載のユーザ評価装置。
【請求項３】
前記電話帳管理手段は、登録者情報に含まれる電話番号に対応するユーザ識別子が、電話番号とユーザ識別子との対応を保持する加入者データベースに記録されているか否かを調べることにより、電話番号の有効、無効を判定することを特徴とする請求項２に記載のユーザ評価装置。
【請求項４】
前記電話帳管理手段は、ユーザの電話番号またはそれに対応するユーザ識別子で特定されるユーザ端末と当該ユーザの電話帳に記録されている登録者情報中の電話番号またはそれに対応するユーザ識別子で特定される通信端末との間で行われた通信を検出して、その通信時刻を当該登録者情報に記録し、
前記電話帳検索手段は、過去所定期間内に通信が一度も行われていない登録者情報を取得の対象から除外することを特徴とする請求項１に記載のユーザ評価装置。
【請求項５】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者のうち、所定の条件を満足する登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項６】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者について、所定のＷｅｂページを閲覧しているか否かを前記Ｗｅｂサーバの閲覧履歴を参照して判定し、閲覧している登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項７】
前記評価手段は、前記評価対象ユーザと前記電話帳検索手段で取得された登録者情報に含まれる登録者の位置情報を取得し、前記評価対象ユーザとの位置関係が所定の条件を満たす登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項８】
前記評価手段は、前記電話帳検索手段で取得された登録者情報に含まれる登録者のうち、そのプレゼンス情報が所定の条件を満たす登録者の数が評価基準を満足するか否かを他の一つの判断材料として前記評価対象ユーザの人脈に関する評価を行うことを特徴とする請求項１乃至４の何れか１項に記載のユーザ評価装置。
【請求項９】
請求項１乃至８の何れか１項に記載されたユーザ評価装置と、サービス装置と、ユーザ端末とが通信ネットワークを介して接続され、前記サービス装置は、前記ユーザ端末からサービス要求を受信したとき、前記ユーザ端末のユーザを評価対象ユーザに指定したユーザ評価要求を前記ユーザ評価装置へ送信し、前記ユーザ評価装置から受信した前記評価対象ユーザの評価結果に従って前記サービス要求に対して提供するサービス内容を変更することを特徴とする情報処理システム。
【請求項１０】
評価手段が、評価対象ユーザを指定したユーザ評価要求を入力し、
電話帳検索手段が、前記評価対象ユーザの電話帳に記録された登録者情報を取得し、
前記評価手段が、前記取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力することを特徴とするユーザ評価方法。
【請求項１１】
コンピュータを、
電話番号を含む登録者情報が記録された電話帳を管理する電話帳管理手段と、
前記電話帳管理手段で管理されている電話帳のうち、評価対象ユーザの電話帳に記録された登録者情報を取得する電話帳検索手段と、
評価対象ユーザを指定したユーザ評価要求を入力し、前記電話帳検索手段で取得された前記評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを一つの判断材料として前記評価対象ユーザの人脈に関する評価を行い、評価結果を出力する評価手段として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１０−１８３２２６（Ｐ２０１０−１８３２２６Ａ）
【公開日】平成２２年８月１９日（２０１０．８．１９）
【国際特許分類】
【出願番号】特願２００９−２３４１６（Ｐ２００９−２３４１６）
【出願日】平成２１年２月４日（２００９．２．４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２２年８月１９日（２０１０．８．１９）
【国際特許分類】
【出願日】平成２１年２月４日（２００９．２．４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]