[第1の実施の形態]
図1を参照すると、本発明の第1の実施の形態に係る情報処理システム100は、通信事業者サーバ装置110と、複数のサービス装置120−1〜120−mと、複数のユーザ端末130−1〜130−nとが通信ネットワーク140を介して接続されている。
通信ネットワーク140は、通信事業者が運営するNGN(Next Generation Network)等のネットワークである。
ユーザ端末130−1〜130−nは、ユーザ131−1〜131−nが所有する携帯電話装置やPDAなどの音声通話機能およびインターネット接続機能を有する通信端末である。ユーザ端末130−1〜130−nには、電話番号とユーザ識別子とが割り当てられている。ユーザ識別子は、ユーザ端末130−1〜130−nまたはユーザ131−1〜131−nを識別する値である。ユーザ識別子は、ユーザ131−1〜131−nが通信事業者の通信サービスの会員として加入する際に、通信事業者から割り当てられる。一般に加入時には、氏名や住所などの個人情報を登録する必要がある。ユーザ識別子は、例えば携帯電話ならSIM(Subscriber Identity Module Card)カードによって付与され、電話番号やメールアドレスを特定するための固有のIDであるIMSI(International Mobile Subscriber Identity)などが利用できる。
通信事業者サーバ装置110は、固定電話や携帯電話等の電気通信サービスを提供する通信事業者のサーバコンピュータである。通信ネットワーク140経由によるユーザ端末130−1〜130−n間およびユーザ端末130−1〜130−nとサービス装置120−1〜120−m間の通信はすべて、この通信事業者サーバ装置110の制御の下で実施される。
本実施の形態においては、通信事業者サーバ装置110に、ユーザ評価装置150を配置している。ユーザ評価装置150は、記憶部151と、電話帳管理部153と、電話帳検索部154と、評価部155とを備えている。
記憶部151は、磁気ディスク等で構成され、通信事業者サーバ装置110を運用する通信事業者に加入しているユーザ131−1〜131−nの電話帳152−1〜152−nを記憶する。
電話帳に登録される情報の一例を図2に示す。図2を参照すると、電話帳には、ユーザ名と電話番号とユーザ識別子と最新通信時刻とから構成される登録者情報が複数記憶できるようになっている。個々の登録者情報に含まれるユーザ名は、この電話帳の持ち主が通信相手を識別するために付けた名前であり、一般的には通信相手の名前である。電話番号はその通信相手の電話番号である。電話帳の持ち主自身が登録するのは、このユーザ名と電話番号の情報だけであり、残りのユーザ識別子と最新通信時刻の情報は電話帳管理部153が自動的に付与する。最新通信時刻は、最後に通信が行われた日を示す。日だけでなく、時、分も含めても良い。また電話帳には、その電話帳がどのユーザのものであるかを識別するために、ユーザ識別子が付与されている。図2の電話帳には、ユーザ識別子user001が付与されており、この電話帳がユーザ識別子user001を持つユーザの電話帳であることが示されている。さらに本実施の形態では、本人の電話番号も電話帳に記憶している。図2の場合、090−111X−111Xがこの電話帳を保持するユーザの電話番号である。なお、電話帳の構成は図2の構成に限定されない。通信相手の住所やメールアドレス等の情報を登録した電話帳であっても良い。
電話帳管理部153は、ユーザ131−0〜131−nの電話帳152−1〜152−nを記憶部151に保持して管理する。電話帳管理部153は、通信ネットワーク140経由でアクセスしてきたユーザ端末130−1〜130−nからの要求に従って、記憶部151にユーザ131−1〜131−nの電話帳を新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索の機能を提供する。また電話帳管理部153は、通信事業者サーバ装置110の制御の下で行われた通信履歴を参照して、記憶部151に記憶された電話帳152−1〜152−nの各登録者情報中の最新通信時刻を更新する機能を有する。さらに電話帳管理部153は、電話帳検索部154から検索を要求された電話帳に登録された登録者情報を記憶部151から読み出して、電話帳検索部154へ出力する機能を有する。
図3を参照すると、電話帳管理部153の一例は、ユーザ要求処理部1531と、電話番号正当性判定部1532と、最新通信時刻更新部1533と、検索要求処理部1534とを備えている。
電話番号正当性判定部1532は、新たに電話帳に登録する電話番号が正当か否かを判定する部分である。本実施の形態では、電話番号が正当か否かの判定は、電話番号に対応するユーザ識別子が加入者データベース1535に記録されているか否かを調べることで行う。一般に、通信ネットワーク140を運用する通信事業者の加入者データベース1535には、加入ユーザの電話番号とユーザ識別子との対応が記録されているため、加入者データベース1535に対応するユーザ識別子が記録されている電話番号は、正当な電話番号であると判定できる。なお、加入者データベース1535は、通信事業者サーバ装置110内に備えられるか、あるいは通信事業者サーバ装置110からアクセス可能な他のサーバ内に備えられている。また、自社の加入者データベース1535に登録の無い電話番号は一律に不正な電話番号として扱っても良いし、自社以外の通信事業者に対して対応するユーザ識別子の有無を問い合わせて、その結果に従って判定するようにしても良い。
ユーザ要求処理部1531は、ユーザ端末130−1〜130−nからの要求に従って、記憶部151にユーザ131−1〜131−nの電話帳152−1〜152−nを新規に作成し、この作成した電話帳に対する登録者情報の追加、更新、削除および検索のサービスをユーザ端末130−1〜130−nに提供する部分である。ここで、ユーザ要求処理部1531は、ユーザ端末130−1〜130−nからの要求に従って新たな電話番号を電話帳に登録する際には、その電話番号の正当性を電話番号正当性判定部1532を用いて判定し、正当と判定された電話番号には、そのことを示すために、電話番号との対応がとれたユーザ識別子を電話帳に記録する。
最新通信時刻更新部1533は、記憶部151に記憶された電話帳152−1〜152−nの各登録者情報中の最新通信時刻を更新する部分である。具体的には、通信事業者サーバ装置110の制御によって、発信側通信端末および着信側通信端末との間に通信が行われた場合、双方の通信端末の電話番号あるいはユーザ識別子の組み合わせを持つ電話帳の登録者情報を記憶部151中から検索し、該当する登録者情報中の最新通信時刻を現在時刻で上書きする。例えば、ユーザ識別子user001のユーザ端末とユーザ識別子user002のユーザ端末との間で通信が行われた場合、最新通信時刻更新部1533は、ユーザ識別子user001を持つ電話帳の中にユーザ識別子user002を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。さらに最新通信時刻更新部1533は、ユーザ識別子user002を持つ電話帳の中にユーザ識別子user001を含む登録者情報が存在するかどうかを調べ、存在すればその登録情報中の最新通信時刻を現在時刻で上書きする。
検索要求処理部1534は、電話帳検索部154から検索の要求された電話帳に登録された登録者情報を記憶部151から読み出して、電話帳検索部154へ出力する部分である。
再び図1を参照すると、電話帳検索部154は、評価部155からの要求に従って、電話帳管理部153で管理されている電話帳のうち評価対象ユーザの電話帳に記録された登録者情報を取得し、評価部155へ通知する機能を有する。ここで、電話帳検索部154は、ユーザ識別子が付与されていない登録情報は電話番号が信用できないものと判断して取得の対象から除外する。また、電話帳検索部154は、現在から過去一定期間内の時刻が最新通信時刻に記録されていない登録情報は、交流が途絶えて久しい登録者と見做して、取得の対象から除外する。
評価部155は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク140経由でサービス装置120−1〜120−mから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク140経由で要求元のサービス装置120−1〜120−mに送信する機能を有する。本実施の形態の評価部155は、評価対象ユーザの電話帳に記録された登録者情報の数が評価基準を満足するか否かを判定する登録数判定部161を備えている。
評価部155がサービス装置120−1〜120−mからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置120−1〜120−mへ送信するまでにユーザ評価装置150で実行される処理の流れを図4に示す。
図4を参照すると、ユーザ評価要求を受信した評価部155は、電話帳検索部154に対して評価対象ユーザの電話帳に記録された登録者情報を要求する(ステップS101)。評価対象ユーザの指定は、例えばユーザ識別子で行う。
電話帳検索部154は、まず、電話帳管理部154を通じて評価対象ユーザの電話帳に記録された登録者情報を取得する(ステップS102)。次に、取得した登録者情報のうち、ユーザ識別子が付加されていない登録者情報、および最新通信時刻から過去所定期間内に一度も通信が行われていない登録者情報を除去する(ステップS103)。そして、残った登録者情報を評価部155に伝達する(ステップS104)。
評価部155は、登録数判定部161により、電話帳検索部154から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する(ステップS105)。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置150に予め固定的に設定しておいても良い。
次に評価部155は、登録数評価結果をユーザ評価結果とし(ステップS106)、ユーザ評価要求元に送信する(ステップS107)。
サービス装置120−1〜120−mは、サービス事業者が通信ネットワーク140を介してユーザ端末130−1〜130−nのユーザ131−1〜131−nに対してサービスを提供するためのサーバコンピュータである。サービス装置120−1〜120−mは、ユーザ端末130−1〜130−nからサービス要求を受信したとき、ユーザ端末130−1〜130−nのユーザ131−1〜131−nを評価対象ユーザに指定したユーザ評価要求を通信ネットワーク140経由でユーザ評価装置150へ送信し、ユーザ評価装置150から返される評価対象ユーザの評価結果に従って、サービス要求に対して提供するサービス内容を変更する機能を有する。
サービス装置120−1〜120−mが提供するサービスの種類や内容は、各種考えられる。以下に幾つかの例を示す。
<サービスの例1>
何れかのサービス装置、例えばサービス装置120−1の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置120−1は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末130−1のユーザ131−1が通信ネットワーク140を介してサービス装置120−1にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置120−1は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末130−1へ送信する。このとき、サービス装置120−1は、検索を要求してきたユーザ131−1を評価対象ユーザとしたユーザ評価要求をユーザ評価装置150に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図5に示す。
図5に示されるように、ユーザ端末130−1のユーザ131−1が、例えば8人分の空席があるレストランの検索要求をサービス装置120−1に対して送信したとする。なお、この検索要求にはユーザ端末130−1のユーザ識別子が付加されており、その値はuser001であるものとする。サービス装置120−1は、検索を要求したユーザ端末130−1のユーザ識別子と評価基準とを指定して、評価部155に対してユーザ評価を要求する。ここでは、評価基準として、検索要求で指定された空席数の半分の4を指定したものとする。なお、検索要求で指定された空席数の半分を評価基準とするのは、あくまでも一例である。検索要求で指定された空席数と同じ数を評価基準としたり、検索要求で指定された空席数とは無関係にあらかじめ定められた定数値を指定するようにしてもよい。
評価部155は、ユーザ識別子user001を指定して電話帳検索部154に対して登録者情報の取得を要求する。電話帳検索部154は、電話帳管理部153を通じて、ユーザ識別子user001で特定されるユーザ131−1の電話帳に登録された登録者情報を取得し、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部155に伝達する。例えば、ユーザ識別子user001で特定されるユーザの電話帳に図2に示した7名分の登録者情報が登録されている場合、ユーザ名D、Gの登録者情報にはユーザ識別子が記録されていないので、これらの登録者情報が除外される。また、現在日時を2008年11月20日とし、過去1年以上にわたって通信が行われていない登録者情報を除外するとする場合、ユーザHの登録者情報が除かれる。結局、電話帳検索部154は、ユーザB、C、E、Fの4名分の登録者情報を評価部155に伝達する。
評価部155は、登録数判定部161により、電話帳検索部154から受け取った登録者情報の数が評価基準の4以上であれば、「OK」の登録数評価結果を生成し、それ以外は「NG」の登録数評価結果を生成する。次に、評価部155は、登録数評価結果をユーザ評価結果として生成し、サービス装置120−1へ送信する。
サービス装置120−1は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「OK」であれば、空席数が8以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末130−1へ送信する。他方、ユーザ評価結果が「NG」であれば、そのような検索結果の送信は行わない。
このように本例では、8席以上の空席があるレストランの検索要求を出したユーザ131−1の電話帳152−1に4名以上の登録者情報があれば、この検索要求に従って8席以上の空席があるレストランの検索結果をユーザ131−1に提供し、4名以上の登録者情報が無ければ、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
まず、8人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の4名以上の登録者が記録されているのはごく普通のことであり、3名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。別の理由として、8以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
<サービスの例2>
何れかのサービス装置、例えばサービス装置120−1の提供するサービスは、特定の飲食店の予約をインターネット経由でリアルタイムに受け付ける予約受け付けサービスであっても良い。この場合、サービス装置120−1は、飲食店の空席情報を含む案内情報をリアルタイムに更新してデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末130−1のユーザ131−1が通信ネットワーク140を介してサービス装置120−1にアクセスし、必要な席数などの条件を指定して予約を要求すると、サービス装置は、予約を受け付けることができるか否かをデータベース中の案内情報を参照して決定し、予約可能ならば予約を受け付けた旨の通知を要求元のユーザ端末130−1へ送信する。このとき、サービス装置120−1は、予約しようとするユーザ131−1を評価対象ユーザとしたユーザ評価要求をユーザ評価装置150に対して行い、得られた評価結果に応じて、予約者に特典を付与する。
具体的には、サービス装置120−1は、例1と同様に評価部155に対してユーザ評価要求を送信する。このとき、評価基準として、例えば登録者情報の数が30以上を指定する。そして、サービス装置120−1は、評価部155のユーザ評価結果がOKであれば、つまりユーザの電話帳に30人以上の登録者が登録されていれば、例えば、特典として10%の割引を予約者に与え、NGであれば、つまり30人未満であれば、そのような特典は与えない。その理由は、30人以上の登録者が電話帳に登録されているような人脈のあるユーザを顧客にできれば、その者の口コミによって顧客の増大を期待できるためである。
このように本実施の形態によれば、電話帳の登録者情報の数に基づいてユーザの人脈の多少に関する評価を行う。電話帳に記録される登録者は、親しい友人や付き合いの多い相手など、ユーザと比較的密接なつながりのある相手である場合が多いため、他の情報、例えば儀礼的に交換される名刺や年賀状の保有枚数に基づいて行う評価に比べて、より確かな評価を下すことができる。
また本実施の形態によれば、ユーザ識別子との対応がとれない電話番号を含む登録情報を除外して評価を行うために、不正な電話番号が登録されていたとしても、それらに影響されずに評価を行うことができる。
また本実施の形態によれば、過去所定期間に一度も通信されていない登録者を除外して評価を行うために、電話帳に電話番号を登録したものの一度も連絡していない相手や、過去には良く連絡を取り合っていたが最近は全く連絡し合っていない相手を除外した評価が可能になる。
また本実施の形態によれば、サービス事業者、通信事業者およびユーザのそれぞれに対して有効な効果が生じる。まずサービス事業者にとっては、ユーザ端末のユーザの評価結果に応じて、提供するサービス内容を変更することができ、従来にないサービス展開が可能になる。また通信事業者にとっては、個人情報の漏洩につなげずに、通信事業者側で管理するユーザの電話帳の情報をユーザの評価という新たな形で提供でき、収益につなげることができる。そして、ユーザにとっては、サービスを利用する際に、サービス事業者が通信事業者からのユーザ評価結果に基づいてサービス展開をするので、より良いサービスを受けることができる。
[第2の実施の形態]
図6を参照すると、本発明の第2の実施の形態に係る情報処理システム200は、図1に示した情報処理システム100と比較して、評価部155の代わりに評価部210を備えている点で相違する。
評価部210は、図1に示した登録数判定部161と同等の機能を有する登録数判定部211に加えて、Web閲覧判定部212を備えている。
Web閲覧判定部212は、電話帳検索部154で取得された登録者情報に含まれる登録者について、所定のWebサーバのコンテンツを閲覧しているか否かを前記Webサーバの閲覧履歴を参照して判定し、閲覧している登録者の数が評価基準を満足するか否かを示すWeb閲覧評価結果を生成する機能を有する。
図7を参照すると、Web閲覧判定部212は、Webサーバ閲覧監視部2121と、閲覧者数検出部2122と、判定部2123と、監視対象URL登録テーブル2124と、Web閲覧履歴テーブル2126−1〜2126−mを記憶する記憶部2125とを備えている。
監視対象URL登録テーブル2124は、サービス装置120−1〜120−mを運用するサービス事業者を一意に識別するサービス事業者識別子に対応付けて、そのサービス事業者が事前に申請したWebページのURLを記録している。その内容例を図8に示す。図8に示されるように、サービス事業者識別子に対応付けて登録するURLは1つでも良いし、2つ以上であっても良い。URLで特定されるWebページは、対応するサービス事業者識別子で特定されるサービス事業者のホームページなどであっても良いし、別のサービス事業者のホームページなどであっても良い。
Webサーバ閲覧監視部2121は、監視対象URL登録テーブル2124に記録されたURLに対してアクセスを行ったユーザ端末130−1〜130−nを検出し、検出結果を記憶部2125のWeb閲覧履歴テーブル2126−1〜2126−mに記録する。Web閲覧履歴テーブル2126−1〜2126−mは、サービス事業者識別子に1対1に対応している。Webサーバ閲覧監視部2121は、監視対象URL登録テーブル2124の或るサービス事業者識別子に対応付けて記録されたURLにユーザ端末130−1〜130−nがアクセスしたことを検出すると、そのサービス事業者識別子に対応するWeb閲覧履歴テーブルにユーザ端末130−1〜130−nのユーザ識別子を閲覧日の情報を添えて記録する。図9にサービス事業者識別子service001に対応するWeb閲覧履歴テーブルの記録情報の例を示す。
Webサーバ閲覧監視部2121が、ユーザ端末130−1〜130−nのWeb閲覧を監視する方法としては、プロキシを用いる方法、デバイスマネージメントを用いる方法が考えられる。プロキシを用いる方法では、ユーザ端末130−1〜130−nからwebページを直接アクセスするのではなく、Web閲覧判定部212が代理としてアクセスを行い、その過程で、サービス事業者識別子に対応付けて記録されたURLにユーザ端末130−1〜130−nがアクセスしたことを検出する方法である。デバイスマネージメントとは、ネットワークにアクセスするユーザ端末130−1〜130−nのデバイス情報やユーザ情報の収集、管理、書き込みを行うシステムのことである。デバイスマネージメントを用いてユーザ端末130−1〜130−nのWeb閲覧履歴を吸い上げて、サービス事業者識別子に対応付けて記録されたURLにユーザ端末130−1〜130−nがアクセスしたことを検出する。
閲覧者数検出部2122は、電話帳検索部154で取得された登録者情報に含まれるそれぞれの登録者について、所定のWebサーバのコンテンツを閲覧しているか否かをWeb閲覧履歴テーブル2126−1〜2126−mを参照して判定し、登録者のうち所定のWebサーバのコンテンツを閲覧している閲覧者数を検出する部分である。
判定部2123は、閲覧者数検出部2122で検出された閲覧者数が評価基準を満足するか否かを示すWeb閲覧評価結果を生成する部分である。
評価部210は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク140経由でサービス装置120−1〜120−mから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク140経由で要求元のサービス装置120−1〜120−mに送信する機能を有する。本実施の形態の評価部210は、登録数判定部211の登録数評価結果と、Web閲覧判定部212のWeb閲覧評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびWeb閲覧評価結果の双方が「OK」である場合に限り、「OK」のユーザ評価結果を生成する。
評価部210がサービス装置120−1〜120−mからユーザ評価要求を受信してから、ユーザ判定結果を要求元のサービス装置120−1〜120−mへ送信するまでにユーザ評価装置150で実行される処理の流れを図10に示す。
図10を参照すると、ユーザ評価要求を受信した評価部210が電話帳検索部154に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部154から登録者情報を受け取るまでの処理は図4の処理と同じである(ステップS101〜S104)。
次に評価部210は、登録数判定部211により、電話帳検索部154から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する(ステップS105)。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置150に予め固定的に設定しておいても良い。
次に評価部210は、Web閲覧判定部212により、電話帳検索部154から受け取った登録者情報の登録者のうち、所定のWebページを過去一定期間(例えば1日)内に閲覧した者の数を計数し、評価基準を満足するか否かを示すWeb閲覧評価結果を生成する(ステップS201)。ここで、Web閲覧評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置210に予め固定的に設定しておいても良い。また、Web閲覧評価の評価基準は、登録数判定評価の評価基準と同じであっても良いし、相違していても良い。
次に評価部210は、登録数評価結果とWeb閲覧評価結果とからユーザ評価結果を生成し(ステップS202)、ユーザ評価要求元に送信する(ステップS107)。
サービス装置120−1〜120−mが提供するサービスの種類や内容は、第1の実施の形態と同様に各種考えられる。以下に一例を示す。
<サービスの例1>
何れかのサービス装置、例えばサービス装置120−1の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置120−1は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。
また、飲食店の空席情報の検索サービスを利用して実際に飲食店で食事する人達のWeb閲覧履歴の傾向を分析した結果に基づいて、その人達が良く見るWebページのURLを自サービス事業者の識別子に対応付けて評価部210の監視対象URL登録テーブル2124に登録する手続きを行っておく。
何れかのユーザ端末、例えばユーザ端末130−1のユーザ131−1が通信ネットワーク140を介してサービス装置120−1にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置120−1は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末130−1へ送信する。このとき、サービス装置120−1は、検索を要求してきたユーザ131−1を評価対象ユーザとしたユーザ評価要求をユーザ評価装置150に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図11に示す。
図11に示されるように、ユーザ端末130−1のユーザ131−1が、例えば8人分の空席があるレストランの検索要求をサービス装置120−1に対して送信したとする。なお、この検索要求にはユーザ端末130−1のユーザ識別子が付加されており、その値はuser001であるものとする。サービス装置120−1は、検索を要求したユーザ端末130−1のユーザ識別子と評価基準とを指定して、評価部210に対してユーザ評価を要求する。ここでは、評価基準としては、登録数判定用の評価基準として、検索要求で指定された空席数の半分の4を指定し、Web閲覧判定用の評価基準として例えば1を指定したものとする。
評価部210は、ユーザ識別子user001を指定して電話帳検索部154に対して登録者情報の取得を要求する。電話帳検索部154は、電話帳管理部153を通じて、ユーザ識別子user001で特定されるユーザ131−1の電話帳152−1に登録された登録者情報を取得し、第1の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部210に伝達する。
評価部210は、登録数判定部211により、電話帳検索部154から受け取った登録者情報の数が評価基準の4以上であれば、「OK」の登録数評価結果を生成し、それ以外は「NG」の登録数評価結果を生成する。
また評価部210は、Web閲覧判定部212により、電話帳検索部154から受け取った登録者情報の登録者のうち、監視対象URL登録テーブル2124にサービス装置120−1の識別子に対応付けて記録されたURLのWebページを閲覧している者の数が評価基準の1以上であれば、「OK」のWeb閲覧評価結果を生成し、それ以外は「NG」のWeb閲覧評価結果を生成する。
次に評価部210は、登録数評価結果とWeb閲覧評価結果とからユーザ評価結果を生成し、サービス装置120−1へ送信する。
サービス装置120−1は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「OK」であれば、空席数が8以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末130−1へ送信する。他方、ユーザ評価結果が「NG」であれば、そのような検索結果の送信は行わない。
このように本例では、8席以上の空席があるレストランの検索要求を出したユーザ131−1の電話帳152−1に4名以上の登録者情報があり、且つ、その登録者のうち少なくとも1名の者が所定のWebページを24時間以内に閲覧していれば、この検索要求に従って8席以上の空席があるレストランの検索結果をユーザ131−1に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
まず、8人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の4名以上の登録者が記録されているのはごく普通のことであり、3名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、自サービス事業者の提供する飲食店の空席情報の検索サービスを利用して実際に飲食店で食事したユーザに対するアンケート調査など事前に得ている良く閲覧するWebページを、登録者の少なくとも一人が閲覧していれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、8以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
このように本実施の形態によれば、電話帳の登録者の数に加えて、その登録者のうち所定のWebページを閲覧した者の数も考慮してユーザを評価するため、ユーザの人脈の中に所定のWebページを良く閲覧する者がどれだけいるかを考慮したユーザ評価が可能になる。
[第3の実施の形態]
図12を参照すると、本発明の第3の実施の形態に係る情報処理システム300は、図1に示した情報処理システム100と比較して、評価部155の代わりに評価部310を備えている点で相違する。
評価部310は、図1に示した登録数判定部161と同等の機能を有する登録数判定部311に加えて、ユーザ位置判定部312を備えている。
ユーザ位置判定部312は、評価対象ユーザと電話帳検索部154で取得された登録者情報に含まれる登録者の位置情報を取得し、評価対象ユーザとの位置関係が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する機能を有する。
図13を参照すると、ユーザ位置判定部312は、位置情報管理部3121と、位置合格数検出部3122と、判定部3123と、位置情報管理テーブル3125を記憶する記憶部3124とを備えている。
位置情報管理テーブル3125は、ユーザ端末130−1〜130−nのユーザ識別子に対応付けて、その地理的な位置情報を記録している。その内容例を図14に示す。図14に示される例では、田町、品川のように一定のエリアを特定する住所表記によりユーザ端末の地理的な位置を特定しているが、緯度と経度で位置情報を表現することも可能である。
位置情報管理部3121は、ユーザ端末130−1〜130−nの位置の変化を検出して、位置情報管理テーブル3125を更新する機能を有する。或いは、一定時間置きに更新してもよい。ユーザ端末130−1〜130−nの位置情報は公知の任意の方法で検知することができる。例えば、携帯電話の現在位置を検出して通知する位置情報通知サービスを利用して検知することができる。また、ユーザ端末130−1〜130−nにモバイルSuica(登録商標)が搭載されている場合には改札通過履歴を利用することも可能である。さらに、携帯電話がどの基地局のエリアにいるかを通信事業者の基地局に知らせる位置登録情報を利用することも可能である。
位置合格数検出部3122は、評価対象ユーザの位置情報と電話帳検索部154で取得された登録者情報に含まれるそれぞれの登録者の位置情報とを位置情報管理テーブル3125から検索し、記評価対象ユーザとの位置関係が所定の条件を満たす登録者の数を計数する部分である。所定の条件とは、位置情報が地区名で表示される場合には同じ地区内にいるという条件や、緯度経度で表現される位置情報の場合には両者の距離が予め定められた距離以内であるという条件を用いることができる。
判定部3123は、位置合格数検出部3122で検出された登録者の数が評価基準を満足するか否かを示すユーザ位置評価結果を生成する部分である。
評価部310は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク140経由でサービス装置120−1〜120−mから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク140経由で要求元のサービス装置120−1〜120−mに送信する機能を有する。本実施の形態の評価部310は、登録数判定部311の登録数評価結果と、ユーザ位置判定部312のユーザ位置評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびユーザ位置評価結果の双方が「OK」である場合に限り、「OK」のユーザ評価結果を生成する。
評価部310がサービス装置120−1〜120−mからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置120−1〜120−mへ送信するまでにユーザ評価装置150で実行される処理の流れを図15に示す。
図15を参照すると、ユーザ評価要求を受信した評価部310が電話帳検索部154に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部154から登録者情報を受け取るまでの処理は図4の処理と同じである(ステップS101〜S104)。
次に評価部310は、登録数判定部311により、電話帳検索部154から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する(ステップS105)。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置310に予め固定的に設定しておいても良い。
次に評価部310は、ユーザ位置判定部312により、電話帳検索部154から受け取った登録者情報の登録者のうち、その位置が評価対象ユーザの位置と所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すユーザ位置評価結果を生成する(ステップS301)。ここで、ユーザ位置評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置150に予め固定的に設定しておいても良い。また、ユーザ位置評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
次に評価部310は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し(ステップS302)、ユーザ評価要求元に送信する(ステップS107)。
サービス装置120−1〜120−mが提供するサービスの種類や内容は、第1の実施の形態と同様に各種考えられる。以下に一例を示す。
<サービスの例1>
何れかのサービス装置、例えばサービス装置120−1の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置120−1は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末130−1のユーザ131−1が通信ネットワーク140を介してサービス装置120−1にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置120−1は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末130−1へ送信する。このとき、サービス装置120−1は、検索を要求してきたユーザ131−1を評価対象ユーザとしたユーザ評価要求をユーザ評価装置150に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図16に示す。
図16に示されるように、ユーザ端末130−1のユーザ131−1が、例えば8人分の空席があるレストランの検索要求をサービス装置120−1に対して送信したとする。なお、この検索要求にはユーザ端末130−1のユーザ識別子が付加されており、その値はuser001であるものとする。サービス装置120−1は、検索を要求したユーザ端末130−1のユーザ識別子と評価基準とを指定して、評価部310に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準およびユーザ位置評価用の評価基準として、検索要求で指定された空席数の半分の4を指定したものとする。
評価部310は、ユーザ識別子user001を指定して電話帳検索部154に対して登録者情報の取得を要求する。電話帳検索部154は、電話帳管理部153を通じて、ユーザ識別子user001で特定されるユーザ131−1の電話帳152−1に登録された登録者情報を取得し、第1の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部310に伝達する。
評価部310は、登録数判定部311により、電話帳検索部154から受け取った登録者情報の数が評価基準の4以上であれば、「OK」の登録数評価結果を生成し、それ以外は「NG」の登録数評価結果を生成する。
また評価部310は、ユーザ位置判定部312により、電話帳検索部154から受け取った登録者情報の登録者のうち、評価対象ユーザ131−1の位置と所定の条件を満たす位置にいる者の数が評価基準の4以上であれば、「OK」のユーザ位置評価結果を生成し、それ以外は「NG」のユーザ位置評価結果を生成する。
次に評価部310は、登録数評価結果とユーザ位置評価結果とからユーザ評価結果を生成し、サービス装置120−1へ送信する。
サービス装置120−1は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「OK」であれば、空席数が8以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末130−1へ送信する。他方、ユーザ評価結果が「NG」であれば、そのような検索結果の送信は行わない。
このように本例では、8席以上の空席があるレストランの検索要求を出したユーザ131−1の電話帳152−1に4名以上の登録者情報があり、且つ、その登録者のうち4名以上が評価対象ユーザ131−1の近くにいれば、この検索要求に従って8席以上の空席があるレストランの検索結果をユーザ131−1に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
まず、8人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の4名以上の登録者が記録されているのはごく普通のことであり、3名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの近くに、電話帳に登録された登録者のうちの何人かがいれば、冷やかしのユーザではない確率がさらに高まることがもう一つの理由である。さらに別の理由として、8以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在位置と評価対象ユーザの現在位置との関係を考慮して、ユーザの評価を行うため、ユーザの人脈の中にユーザの近くにいる者がどれだけいるかを考慮したユーザ評価が可能になる。
[第4の実施の形態]
図17を参照すると、本発明の第4の実施の形態に係る情報処理システム400は、図1に示した情報処理システム100と比較して、評価部155の代わりに評価部410を備えている点で相違する。
評価部410は、図1に示した登録数判定部161と同等の機能を有する登録数判定部411に加えて、プレゼンス判定部412を備えている。
プレゼンス判定部412は、評価対象ユーザと電話帳検索部154で取得された登録者情報に含まれる登録者のプレゼンス情報を取得し、プレゼンス情報が所定の条件を満たす登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する機能を有する。
図18を参照すると、プレゼンス判定部412は、プレゼンス管理部4121と、プレゼンス検出部4122と、判定部4123と、プレゼンス情報管理テーブル4125を記憶する記憶部4124とを備えている。
プレゼンス情報管理テーブル4125は、ユーザ端末130−1〜130−nのユーザ識別子に対応付けて、ユーザ131−1〜131−nのプレゼンス情報を記録している。プレゼンス情報とは、ユーザが今どのような状態にあるかを示す情報であり、通信可能な状態を示す「オンライン」、通信不可能な状態を示す「オフライン」、外出している状態を示す「外出中」、会議中を示す「会議中」などがある。
プレゼンス管理部4121は、ユーザ端末130−1〜130−nのプレゼンス情報の変化を検出して、プレゼンス情報管理テーブル4125を更新する機能を有する。一般にプレゼンスシステムは、自分のプレゼンス情報を提供するプレゼンティティと、それを観察するウォッチャ、および、プレゼンティティからプレゼンス情報を受け取り、これをウォッチャに配信するプレゼンスサービス(プレゼンスサーバ)とからなる。プレゼンス管理部4121は、プレゼンスシステムにおけるウォッチャとして、プレゼンティティとしてのユーザ端末130−1〜130−nのプレゼンス情報を観察して、プレゼンス情報管理テーブル4125に記録する。また、通信事業者サーバ装置110がプレゼンスサーバである場合、プレゼンス検出部4122をプレゼンスサーバで実現することも可能である。
プレゼンス検出部4122は、電話帳検索部154で取得された登録者情報に含まれるそれぞれの登録者のプレゼンス情報をプレゼンス情報管理テーブル4125から検索し、所定の条件を満たすプレゼンス情報の登録者の数を計数する部分である。所定の条件は、ユーザ評価要求中で指定しても良いし、評価部410に予め設定しておいても良い。
判定部4123は、プレゼンス検出部4122で検出された登録者の数が評価基準を満足するか否かを示すプレゼンス評価結果を生成する部分である。
評価部410は、評価対象ユーザに対するユーザ評価要求を通信ネットワーク140経由でサービス装置120−1〜120−mから受け付け、当該評価対象ユーザの評価をそのユーザの電話帳を用いて行い、その評価結果を通信ネットワーク140経由で要求元のサービス装置120−1〜120−mに送信する機能を有する。本実施の形態の評価部410は、登録数判定部411の登録数評価結果と、プレゼンス検出部4122のプレゼンス評価結果とからユーザ評価結果を生成する。具体的には、登録数評価結果およびプレゼンス評価結果の双方が「OK」である場合に限り、「OK」のユーザ評価結果を生成する。
評価部410がサービス装置120−1〜120−mからユーザ評価要求を受信してから、ユーザ評価結果を要求元のサービス装置120−1〜120−mへ送信するまでにユーザ評価装置150で実行される処理の流れを図19に示す。
図19を参照すると、ユーザ評価要求を受信した評価部410が電話帳検索部154に対して評価対象ユーザの電話帳に記録された登録者情報を要求して、電話帳検索部154から登録者情報を受け取るまでの処理は図4の処理と同じである(ステップS101〜S104)。
次に評価部410は、登録数判定部411により、電話帳検索部154から受け取った登録者情報の数を計数し、評価基準を満足するか否かを示す登録数評価結果を生成する(ステップS105)。ここで、評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置150に予め固定的に設定しておいても良い。
次に評価部410は、プレゼンス判定部412により、電話帳検索部154から受け取った登録者情報の登録者のうち、そのプレゼンス情報が所定の条件を満たす者の数を計数し、評価基準を満足するか否かを示すプレゼンス評価結果を生成する(ステップS401)。ここで、プレゼンス評価の評価基準は、サービス装置がユーザ評価要求中で指定しても良いし、ユーザ評価装置150に予め固定的に設定しておいても良い。また、プレゼンス評価の評価基準は、登録数評価の評価基準と同じであっても良いし、相違していても良い。
次に評価部410は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し(ステップS402)、ユーザ評価要求元に送信する(ステップS107)。
サービス装置120−1〜120−mが提供するサービスの種類や内容は、第1の実施の形態と同様に各種考えられる。以下に一例を示す。
<サービスの例1>
何れかのサービス装置、例えばサービス装置120−1の提供するサービスは、飲食店の空席情報をインターネット経由でリアルタイムに提供する検索サービスであっても良い。この場合、サービス装置120−1は、飲食店から空席情報を含む案内情報をリアルタイムに受け付けてデータベースに蓄積する。何れかのユーザ端末、例えばユーザ端末130−1のユーザ131−1が通信ネットワーク140を介してサービス装置120−1にアクセスし、必要な席数などの検索条件を指定して検索を要求すると、サービス装置120−1は、検索条件を満たす飲食店の案内情報をデータベースから検索し、検索結果を要求元のユーザ端末130−1へ送信する。このとき、サービス装置120−1は、検索を要求してきたユーザ131−1を評価対象ユーザとしたユーザ評価要求をユーザ評価装置150に対して行い、得られた評価結果に応じて、サービス提供の可否を判断する。この際の処理シーケンスの一例を図20に示す。
図20に示されるように、ユーザ端末130−1のユーザ131−1が、例えば8人分の空席があるレストランの検索要求をサービス装置120−1に対して送信したとする。なお、この検索要求にはユーザ端末130−1のユーザ識別子が付加されており、その値はuser001であるものとする。サービス装置120−1は、検索を要求したユーザ端末130−1のユーザ識別子と評価基準とを指定して、評価部410に対してユーザ評価を要求する。ここでは、評価基準としては、登録数評価用の評価基準として、検索要求で指定された空席数の半分の4を指定し、プレゼンス評価用の評価基準として、「外出中」のプレゼンス情報の登録者の数が4名以上であるという基準を指定したものとする。
評価部410は、ユーザ識別子user001を指定して電話帳検索部154に対して登録者情報の取得を要求する。電話帳検索部154は、電話帳管理部153を通じて、ユーザ識別子user001で特定されるユーザ131−1の電話帳152−1に登録された登録者情報を取得し、第1の実施の形態と同様に、その中から不正な電話番号を含む登録者情報および最近通信が行われていない登録者情報を除外し、残りの登録者情報を評価部410に伝達する。
評価部410は、登録数判定部411により、電話帳検索部154から受け取った登録者情報の数が評価基準の4以上であれば、「OK」の登録数評価結果を生成し、それ以外は「NG」の登録数評価結果を生成する。
また評価部410は、プレゼンス判定部412により、電話帳検索部154から受け取った登録者情報の登録者のうち、そのプレゼンス情報が「外出中」である者の数が評価基準の4以上であれば、「OK」のユーザ位置評価結果を生成し、それ以外は「NG」のユーザ位置評価結果を生成する。
次に評価部410は、登録数評価結果とプレゼンス評価結果とからユーザ評価結果を生成し、サービス装置120−1へ送信する。
サービス装置120−1は、ユーザ評価結果に応じてサービス提供の可否を決定する。もし、ユーザ評価結果が「OK」であれば、空席数が8以上のレストランの案内情報を図示しないデータベースから検索して、ユーザ端末130−1へ送信する。他方、ユーザ評価結果が「NG」であれば、そのような検索結果の送信は行わない。
このように本例では、8席以上の空席があるレストランの検索要求を出したユーザ131−1の電話帳152−1に4名以上の登録者情報があり、且つ、その登録者のうち4名以上が「外出中」のプレゼンス情報であれば、この検索要求に従って8席以上の空席があるレストランの検索結果をユーザ131−1に提供し、それ以外の場合は、そのような検索結果の提供は行わない。このような制御を行う理由は以下の通りである。
まず、8人で会食しようと思っているユーザならば、その電話帳に少なくともその半分の4名以上の登録者が記録されているのはごく普通のことであり、3名以下の登録者しか記録されていないユーザは暇に任せて検索で遊んでいる冷やかしのユーザと考えられることが理由の一つである。また、飲食店の空席情報の検索サービスを利用して何人かで食事しようとする考えているユーザの電話帳に登録された登録者のうち、4名以上が「外出中」であれば、それらの者が同伴者である可能性があり、冷やかしのユーザでない確率がさらに高まることがもう一つの理由である。さらに別の理由として、8以上の空席があるような閑古鳥が鳴いている状態を公にすることは、料理があまり美味しくないなどのサービス品質が低いことを感じさせる恐れがあるために、収益の増大につながる確率が高い場合以外は、できるだけ公にしたくないというレストラン側の事情によるものである。
このように本実施の形態によれば、電話帳の登録者の数に加えて、電話帳の登録者の現在のプレゼンス情報を考慮して、ユーザの評価を行うため、ユーザの人脈の中に所定のプレゼンス情報となっている者がどれだけいるかを考慮したユーザ評価が可能になる。
[その他の実施の形態]
以上本発明の実施の形態について説明したが、本発明は以上の実施の形態にのみ限定されず、その他各種の付加変更が可能である。
例えば、電話帳に記録された登録者情報の数以外の判断材料として、第2の実施の形態では所定のWebページを閲覧している登録者の数、第3の実施の形態では評価対象ユーザと所定の位置関係にある登録者の数、第4の実施の形態では所定のプレゼンス状態になっている登録者の数を用いたが、これらの判断材料を複数組み合わせる実施の形態や、これら以外の任意の判断材料を組み合わせる実施の形態も考えられる。
また、前記の各実施の形態では、ユーザの電話帳を通信事業者のサーバ装置の記憶部に記憶して管理していたが、ユーザの電話帳をそのユーザのユーザ端末の記憶部に記憶して管理するようにしても良い。
また、本発明のユーザ評価装置は、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態におけるユーザ評価装置として機能させる。