JP2013020390A - 情報提示システム、情報提示方法及び情報提示プログラム - Google Patents

Abstract

【課題】通信ネットワークを介して行われる高度かつ柔軟なネットワーク電話帳検索を可能にすること。
【解決手段】通信ネットワークに接続された携帯端末ごとに通信先の情報を記憶し、携帯端末からの要求に応じて、通信先の情報を当該携帯端末に提示する電話帳システムであって、収集部が、携帯端末ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する。そして、予測部が、収集部によって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する。
【選択図】 図２

Description

この発明は、情報提示システム、情報提示方法及び情報提示プログラムに関する。

従来、携帯電話などに備えられた電話帳機能などを通信ネットワーク上のサーバで機能させるネットワーク電話帳システムが知られている。例えば、ネットワーク電話帳システムでは、サーバが連絡先の電話番号やメールアドレスなどを記憶し、利用者の要求に応じて、携帯電話にそれらを提示させる。

近年、このようなネットワーク電話帳システムにおいては、記憶している連絡先の中から利用者の所望する連絡先を検索して、提示する機能も備えられてきている。このような機能としては、例えば、通信が行われた回数や時刻などの情報を連絡先ごとに自動的に入手、保存、更新して、長期間通信が行われていない連絡先を検索して利用者に提示したり、発信過多の連絡先や着信過多の連絡先を検索して利用者に提示したりする技術が知られている。

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

しかしながら、上述した従来技術では、高度かつ柔軟な検索を行うことが困難であるという問題があった。例えば、上述した従来技術では、自端末の通信回数及び通信時刻（通信開始時刻、通信終了時刻、累計発着信時間）のみが利用されているため、連絡先を検索する精度が低く、高度かつ柔軟な検索を行うことが困難であった。

そこで、本願は、上述した従来技術の問題に鑑みてなされたものであって、通信ネットワークを介して行われる高度かつ柔軟なネットワーク電話帳検索を可能にする情報提示システム、情報提示方法及び情報提示プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本願のシステムは、ネットワークに接続された携帯端末ごとに通信先の情報を記憶し、前記携帯端末からの要求に応じて、前記通信先の情報を当該携帯端末に提示する情報提示システムであって、前記携帯端末ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する収集部と、前記収集部によって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する予測部とを備えたことを特徴とする。

本願のシステムは、通信ネットワークを介して行われる高度かつ柔軟なネットワーク電話帳検索を可能にする。

図１は、実施例１に係るネットワーク電話帳システムの全体構成の一例を示す図である。 図２は、実施例１に係る電話帳システムの構成の一例を示す図である。 図３は、実施例１に係るユーザＤＢによって記憶される情報の第１の例を説明するための図である。 図４は、実施例１に係るユーザＤＢによって記憶される情報の第２の例を説明するための図である。 図５は、実施例１に係る事象データ生成部による処理の一例を説明するための図である。 図６は、実施例１に係る予測部による処理の一例を説明するための図である。 図７は、実施例１に係る電話履歴収集部による収集処理の手順を示すフローチャートである。 図８は、実施例１に係る電子メール履歴収集部による収集処理の手順を示すフローチャートである。 図９は、実施例１に係る予定情報収集部による収集処理の手順を示すフローチャートである。 図１０は、実施例１に係る事象データ生成部による処理の手順を示すフローチャートである。 図１１は、実施例１に係る予測部による処理の手順を示すフローチャートである。 図１２は、実施例２に係る電話帳システムの構成の一例を説明するための図である。 図１３は、バスケットＤＢによって記憶される情報の一例を説明するための図である。 図１４は、実施例２に係るアソシエーション分析部による第１の処理を説明するための図である。 図１５は、実施例２に係るアソシエーション分析部による第２の処理を説明するための図である。 図１６は、実施例２に係る電話帳システムによる処理の手順を示すフローチャートである。 図１７は、実施例２に係るアソシエーション分析部によるアソシエーションルール抽出処理の手順を示すフローチャートである。 図１８は、実施例２に係るアソシエーション分析部による頻出アイテム集合の抽出処理の手順を示すフローチャートである。 図１９は、実施例２に係る予測部による処理の手順を示すフローチャートである。 図２０は、実施例３に係る電話帳システムの構成の一例を説明するための図である。 図２１は、実施例３に係る確率変数ＤＢによって記憶される情報の第１の例を説明するための図である。 図２２は、実施例３に係る確率変数ＤＢによって記憶される情報の第２の例を説明するための図である。 図２３は、実施例３に係る適合性フィードバック部による処理の手順を示すフローチャートである。 図２４は、実施例４に係る情報提示プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、本願の情報提示システム、情報提示方法及び情報提示プログラムの実施例を詳細に説明する。以下では、本願の情報提示システムの一例として、ネットワーク電話帳システムに含まれる電話帳システムを例に挙げて説明する。なお、本願の情報提示システム、情報提示方法及び情報提示プログラムは、以下の実施例により限定されるものではない。

まず、実施例１に係るネットワーク電話帳システムの全体構成について説明する。図１は、実施例１に係るネットワーク電話帳システム１０の全体構成の一例を説明するための図である。図１に示すように、実施例１に係るネットワーク電話帳システム１０は、携帯端末１と、メールサーバ２と、構内交換システム３と、電話帳システム４と、予定管理システム５とを有し、通信ネットワーク６によるパケット通信で接続されている。例えば、ネットワーク電話帳システム１０は、企業などの組織におけるネットワークに適用されるシステムである。

通信ネットワーク６は、携帯端末１と、メールサーバ２と、構内交換システム３と、電話帳システム４と、予定管理システム５との間で送受信されるデータを中継する通信網である。例えば、通信ネットワーク６は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などである。

携帯端末１は、ユーザの操作に応じたコミュニケーションツールを起動し、通信ネットワーク６を介した他の携帯端末との通信（例えば、電話やメールの送受信）を行う。また、携帯端末１は、ユーザの操作に基づいて、後述する電話帳システム４にアクセスして電話帳のデータを受信し、受信した電話帳のデータを表示する。

メールサーバ２は、通信ネットワーク６内の携帯端末１に対する電子メールの送受信を行う。また、メールサーバ２は、ユーザごとにメールの送受信履歴を記憶する。例えば、メールサーバ２は、メールの送受信履歴として、メールが送受信された日時、相手先のメールアドレスなどを記憶する。

構内交換システム３は、通信ネットワーク６内の携帯端末１に対する電話の発着信を行う。また、構内交換システム３は、ユーザごとに電話の発着信履歴を記憶する。例えば、構内交換システム３は、電話の発着信履歴として、電話が発着信された日時、相手先の電話番号などを記憶する。

予定管理システム５は、携帯端末１のユーザごとのスケジュール情報を記憶する。例えば、予定管理システム５は、スケジュール情報として、ユーザの会議の登録情報（会議の予約・開始・終了を登録した登録者名など）を記憶する。

電話帳システム４は、携帯端末１によるアクセスに応じて、メールサーバ２、構内交換システム３及び予定管理システム５によってそれぞれ記憶されたメールの送受信履歴、電話の発着信履歴及びスケジュール情報を用い、携帯端末１のユーザの連絡先を現時点で連絡を取りうる可能性が高い順に並び替え、携帯端末１に提示する。なお、電話帳システム４による処理の詳細については、後述する。なお、以下では、メールの送受信履歴、電話の発着信履歴及びスケジュール情報をまとめて履歴データと記す場合がある。

以上、実施例１に係るネットワーク電話帳システム１０の全体構成について説明した。次に、電話帳システム４の構成について、図２を用いて説明する。図２は、実施例１に係る電話帳システム４の構成の一例を示す図である。図２に示すように、電話帳システム４は、ユーザＤＢ４１と、電話帳ＤＢ４２と、収集部４３と、予測部４４とを有する。

ユーザＤＢ４１は、後述する収集部４３及び予測部４４によって用いられる各種情報や、収集部４３及び予測部４４の処理結果などを記憶する。図３は、実施例１に係るユーザＤＢ４１によって記憶される情報の第１の例を説明するための図である。図３に示すように、ユーザＤＢ４１は、イベントＩＤとイベント一覧とが対応付けられたイベント識別情報を記憶する。ここで、図３に示す「イベントＩＤ」とは、通信ネットワーク６を介して実行される通信の内容（イベント）を一意に特定するための識別子を示す。また、図３に示す「イベント一覧」とは、通信ネットワーク６を介して実行される通信の内容（イベント）の一覧を示す。なお、「イベントＩＤ」は、ネットワーク電話帳システム１０の管理者によって任意に付与することが可能である。例えば、ユーザＤＢ４１は、図３に示すように、「イベントＩＤ：１」に「イベント一覧：ＴＥＬ発信」を対応付けたイベント識別情報を記憶する。同様に、ユーザＤＢ４１は、イベントＩＤにイベント一覧を対応付けたイベント識識別情報を記憶する。

図４は、実施例１に係るユーザＤＢ４１によって記憶される情報の第２の例を説明するための図である。図４に示すように、ユーザＤＢ４１は、イベントごとに、「リストＮｏ」と「相手先」とを対応付けた相手先リストを記憶する。ここで、図４に示す「リストＮｏ」とは、各イベントにおける相手先に付与された番号を示し、後述する収集部４３によって付与される。例えば、ユーザＤＢ４１は、「イベント：ＴＥＬ発信 ＩＤ＝１」の相手先リストとして、「リストＮｏ：１、相手先：０４２２１２３４５６７８」を記憶する。同様に、ユーザＤＢ４１は、図４に示すように、イベントごとに相手先リストを記憶する。なお、図４には、会議に係るイベントとして会議予約の相手先リストのみが示されているが、実際には、ユーザＤＢ４１は、会議開始及び会議終了の相手先リストも記憶する。

また、ユーザＤＢ４１は、後述する収集部４３によって生成された事象データを記憶するが、事象データの詳細については、後に詳述する。電話帳ＤＢ４２は、携帯端末１ごとの連絡先の情報を記憶する。例えば、電話帳ＤＢ４２は、携帯端末１のユーザの連絡先となる電話番号が登録された電話帳を記憶する。

図２に戻って、収集部４３は、電話履歴収集部４３ａと、電子メール履歴収集部４３ｂと、予定情報収集部４３ｃと、事象データ生成部４３ｄとを有し、携帯端末１ごとに、電話の発着信履歴と、メールの送受信履歴と、当該携帯端末１の利用者のスケジュール情報とを含む履歴情報を収集する。

電話履歴収集部４３ａは、一定間隔ごとに、構内交換システム３によって記憶されたユーザごとの電話の発着信履歴を収集して、相手先リストを生成し、生成した相手先リストをユーザＤＢ４１に格納する。具体的には、電話履歴収集部４３ａは、まず、任意の時間が経過すると、所定のユーザについて、通信ネットワーク６を介して構内交換システム３から電話の発着信履歴を１件収集する。そして、電話履歴収集部４３ａは、収集した電話の発着信履歴が発信履歴であるか、或いは、着信履歴であるかを判定した後、ユーザＤＢ４１によって記憶された相手先リストに一致する電話番号が記憶されているか否かを判定する。ここで、収集した電話番号がユーザＤＢ４１の相手先リストに記憶されていない場合に、電話履歴収集部４３ａは、収集した電話番号にリストＮｏを付与して、相手先リストに格納する。例えば、電話履歴収集部４３ａは、図４の相手先リスト「ＴＥＬ発信 ＩＤ＝１」に示すように、「相手先：０４２２１２３４５６７８」に「リストＮｏ：１」を付与してユーザＤＢ４１に格納する。そして、電話履歴収集部４３ａは、未収集の発着信履歴を１件ずつ収集して、上述した判定処理と格納処理を繰り返し実行する。さらに、電話履歴収集部４３ａは、収集した電話の発着信履歴を後述する事象データ生成部４３ｄに通知する。

電子メール履歴収集部４３ｂは、一定間隔ごとに、メールサーバ２によって記憶されたユーザごとのメールの送受信履歴を収集して、相手先リストを生成し、生成した相手先リストをユーザＤＢ４１に格納する。具体的には、電子メール履歴収集部４３ｂは、まず、任意の時間が経過すると、所定のユーザについて、通信ネットワーク６を介してメールサーバ２からメールの送受信履歴を１件収集する。そして、電子メール履歴収集部４３ｂは、収集したメールの送受信履歴が送信履歴であるか、或いは、受信履歴であるかを判定した後、ユーザＤＢ４１によって記憶された相手先リストに一致するメールアドレスが記憶されているか否かを判定する。ここで、収集したメールアドレスがユーザＤＢ４１の相手先リストに記憶されていない場合に、電子メール履歴収集部４３ｂは、収集したメールアドレスにリストＮｏを付与して、相手先リストに格納する。例えば、電子メール履歴収集部４３ｂは、図４の相手先リスト「メール送信 ＩＤ＝３」に示すように、「相手先：Ｔａｎａｋａ＠ａｃｂ．ｃｏｍ」に「リストＮｏ：１」を付与してユーザＤＢ４１に格納する。そして、電子メール履歴収集部４３ｂは、未収集の送受信履歴を１件ずつ収集して、上述した判定処理と格納処理を繰り返し実行する。さらに、電子メール履歴収集部４３ｂは、収集したメールの送受信履歴を後述する事象データ生成部４３ｄに通知する。

予定情報収集部４３ｃは、一定間隔ごとに、予定管理システム５によって記憶されたユーザごとのスケジュール情報を収集して、相手先リストを生成し、生成した相手先リストをユーザＤＢ４１に格納する。具体的には、予定情報収集部４３ｃは、まず、任意の時間が経過すると、所定のユーザについて、通信ネットワーク６を介して予定管理システム５からスケジュール情報を１件収集する。そして、予定情報収集部４３ｃは、収集したスケジュール情報が予約であるか、開始であるか、或いは、終了であるかを判定した後、ユーザＤＢ４１によって記憶された相手先リストに一致する登録者名が記憶されているか否かを判定する。ここで、収集した登録者名がユーザＤＢ４１の相手先リストに記憶されていない場合に、予定情報収集部４３ｃは、収集した登録者名にリストＮｏを付与して、相手先リストに格納する。例えば、予定情報収集部４３ｃは、図４の相手先リスト「会議予約 ＩＤ＝５」に示すように、「相手先：田中一郎」に「リストＮｏ：１」を付与してユーザＤＢ４１に格納する。そして、予定情報収集部４３ｃは、未収集のスケジュール情報を１件ずつ収集して、上述した判定処理と格納処理を繰り返し実行する。さらに、予定情報収集部４３ｃは、収集したスケジュール情報を後述する事象データ生成部４３ｄに通知する。

事象データ生成部４３ｄは、電話履歴収集部４３ａ、電子メール履歴収集部４３ｂ及び予定情報収集部４３ｃそれぞれから通知された履歴データを、時系列順に並べ、イベントＩＤとリストＮｏで表現した事象データを生成する。具体的には、事象データ生成部４３ｄは、通知された履歴データを時系列順に並べた後、ユーザＤＢ４１によって記憶されたイベント識別情報及び相手先リストを参照して、イベント種別をイベントＩＤに置換し、相手先をリストＮｏに置換することで、事象データを生成する。

図５は、実施例１に係る事象データ生成部４３ｄによる処理の一例を説明するための図である。図５においては、電話履歴収集部４３ａ、電子メール履歴収集部４３ｂ及び予定情報収集部４３ｃそれぞれから通知された履歴データを時系列順に並べた後の処理を示す。例えば、事象データ生成部４３ｄは、イベント識別情報及び相手先リストを参照して、図５に示すように、履歴データ「イベント種別：会議開始、相手先：田中一郎、時刻：２００９／３／３ １８：００」を「イベントＩＤ：６、リストＮｏ：１、時刻：２００９／３／３ １８：００」とした事象データを生成する。同様に、事象データ生成部４３ｄは、イベント識別情報及び相手先リストを参照して、図５に示す事象データを生成する。

図２に戻って、予測部４４は、収集部４３によって収集された情報の任意の時間区間における出現頻度に基づいて、携帯端末１のユーザが現時点で通信を行う可能性が高い通信先を予測し、予測した通信先の情報を携帯端末１に提示する。具体的には、予測部４４は、まず、任意のイベントを対象とし、事象データ生成部４３ｄによって生成された事象データのうち、任意の時間区間内に出現した対象のイベントＩＤとリストＮｏとの組をキーとして設定する。そして、予測部４４は、設定したキーの組に対して、同一の時間区間内で出現した他のすべてのイベントＩＤとリストＮｏとの組の出現回数を対応付ける。予測部４４は、上記した処理を事象データに設定したすべての時間区間で実行する。さらに、予測部４４は、対応付けた複数のキーの組と当該キーに対応する塊に対して、当該塊に含まれるイベントＩＤとリストＮｏとの組を新たなキーの組として、新たなキーの組の情報を含む各塊に対応する最初のキーの組と当該塊における新たなキーの組の出現回数とを一つの塊として整理する。換言すると、予測部４４は、最初のキーの組と対応するデータの関係とは逆となる、データからキーの組を求める逆引きの関係を設定する。

図６は、実施例１に係る予測部４４による処理の一例を説明するための図である。図６においては、図５に示す事象データに含まれるイベントのうち、「ＴＥＬ発信（イベントＩＤ＝１）に着目した場合の処理について示す。例えば、予測部４４は、図６の（Ａ）に示すように、設定された時間区間（ａ）及び（ｂ）からイベントＩＤとリストＮｏの組をそれぞれ抽出する。そして、予測部４４は、イベントＩＤ＝１に着目していることから、時間区間（ａ）から「イベントＩＤ：１、リストＮｏ：１」をキーの組として抽出する。同様に、予測部４４は、時間区間（ｂ）から「イベントＩＤ：１、リストＮｏ：２」をキーの組として抽出する。

そして、予測部４４は、時間区間（ａ）及び（ｂ）それぞれについて、キーの組を除く全イベント（イベントＩＤとリストＮｏとの組）の出現回数をカウントする。例えば、予測部４４は、図６の（Ｂ）に示すように、時間区間（ａ）において、「イベントＩＤ：２、リストＮｏ：２」が「３回」、「イベントＩＤ：２、リストＮｏ：１」が「２回」、「イベントＩＤ：３、リストＮｏ：１」が「１回」とカウントする。同様に、予測部４４は、図６の（Ｂ）に示すように、時間区間（ｂ）において、「イベントＩＤ：２、リストＮｏ：２」が「４回」、「イベントＩＤ：３、リストＮｏ：１」が「３回」とカウントする。

その後、予測部４４は、キーの組を除く全イベントのイベントＩＤとリストＮｏとの組について、イベントごとに、全時間区間におけるキーの組の出現回数の合計をカウントする。例えば、予測部４４は、図６の（Ｃ）に示すように、「イベントＩＤ：２、リストＮｏ：２」に対して、「イベントＩＤ：１、リストＮｏ：２」が「４回」、「イベントＩＤ：１、リストＮｏ：１」が「３回」とカウントする。同様に、予測部４４は、図６の（Ｃ）に示すように、「イベントＩＤ：２、リストＮｏ：１」に対して、「イベントＩＤ：１、リストＮｏ：１」が「２回」とカウントする。また、予測部４４は、図６の（Ｃ）に示すように、「イベントＩＤ：３、リストＮｏ：１」に対して、「イベントＩＤ：１、リストＮｏ：２」が「３回」、「イベントＩＤ：１、リストＮｏ：１」が「１回」とカウントする。

そして、予測部４４は、現時点でのユーザの履歴と照合する。具体的には、予測部４４は、現時点での時間区間に含まれるユーザの履歴と照合する。例えば、図６の（Ｄ）に示すように、現時点での時間区間に「イベントＩＤ：２、リストＮｏ：２」と「イベントＩＤ：３、リストＮｏ：１」とが含まれている場合、予測部４４は、図６の（Ｃ）に示す出現回数を参照して、「イベントＩＤ：１、リストＮｏ：１」が「３＋１」の「４回」、「イベントＩＤ：１、リストＮｏ：２」が「４＋３」の「７回」とカウントする。そして、出現回数が多い順に携帯端末１に相手先を提示する。例えば、予測部４４は、図６の（Ｄ）に示すように、「リストＮｏ：２（第１候補）＝０９０１２３４５６７８」、「リストＮｏ：１（第２候補）＝０４２２１２３４５６７８」を携帯端末１に提示する。

次に、実施例１に係る電話帳システム４による処理の手順について、図７〜１１を用いて説明する。図７は、実施例１に係る電話履歴収集部４３ａによる収集処理の手順を示すフローチャートである。図７に示すように、電話履歴収集部４３ａは、一定間隔ごとに構内交換システム３から履歴データを１件収集する（ステップＳ１０１）。そして、電話履歴収集部４３ａは、収集した履歴データから発着番号、発着信時刻、イベント種別を抽出する（ステップＳ１０２）。

続いて、電話履歴収集部４３ａは、抽出したイベント種別を基に、イベントＩＤ（＝１ｏｒ２）を設定して（ステップＳ１０３）、イベントＩＤごとの相手先リストを検索し（ステップＳ１０４）、リスト内に一致項目があるか否かを判定する（ステップＳ１０５）。

ここで、リスト内に一致項目がない場合には（ステップＳ１０５否定）、電話履歴収集部４３ａは、イベントＩＤにリストＮｏを付与して（ステップＳ１０６）、ユーザＤＢ４１の相手先リストに登録する（ステップＳ１０７）。そして、電話履歴収集部４３ａは、事象データ生成部４３ｄに抽出した発着番号、発着信時刻、イベント種別を通知する（ステップＳ１０８）。

一方、リスト内に一致項目がある場合には（ステップＳ１０５肯定）、電話履歴収集部４３ａは、事象データ生成部４３ｄに抽出した発着番号、発着信時刻、イベント種別を通知する（ステップＳ１０８）。そして、電話履歴収集部４３ａは、未読み込みデータがあるか否かを判定する（ステップＳ１０９）ここで、未読み込みデータがある場合には（ステップＳ１０９肯定）、電話履歴収集部４３ａは、ステップＳ１０１に戻って、履歴データを１件収集する。一方、未読み込みデータがない場合には（ステップＳ１０９否定）、電話履歴収集部４３ａは、処理を終了する。

図８は、実施例１に係る電子メール履歴収集部４３ｂによる収集処理の手順を示すフローチャートである。図８に示すように、電子メール履歴収集部４３ｂは、一定間隔ごとにメールサーバ２から履歴データを１件収集する（ステップＳ２０１）。そして、電子メール履歴収集部４３ｂは、収集した履歴データから送信アドレス、送受信時刻、イベント種別を抽出する（ステップＳ２０２）。

続いて、電子メール履歴収集部４３ｂは、抽出したイベント種別を基に、イベントＩＤ（＝３ｏｒ４）を設定して（ステップＳ２０３）、イベントＩＤごとの相手先リストを検索し（ステップＳ２０４）、リスト内に一致項目があるか否かを判定する（ステップＳ２０５）。

ここで、リスト内に一致項目がない場合には（ステップＳ２０５否定）、電子メール履歴収集部４３ｂは、イベントＩＤにリストＮｏを付与して（ステップＳ２０６）、ユーザＤＢ４１の相手先リストに登録する（ステップＳ２０７）。そして、電子メール履歴収集部４３ｂは、事象データ生成部４３ｄに抽出した送信アドレス、送受信時刻、イベント種別を通知する（ステップＳ２０８）。

一方、リスト内に一致項目がある場合には（ステップＳ２０５肯定）、電子メール履歴収集部４３ｂは、事象データ生成部４３ｄに抽出した送信アドレス、送受信時刻、イベント種別を通知する（ステップＳ２０８）。そして、電子メール履歴収集部４３ｂは、未読み込みデータがあるか否かを判定する（ステップＳ２０９）ここで、未読み込みデータがある場合には（ステップＳ２０９肯定）、電子メール履歴収集部４３ｂは、ステップＳ２０１に戻って、履歴データを１件収集する。一方、未読み込みデータがない場合には（ステップＳ２０９否定）、電子メール履歴収集部４３ｂは、処理を終了する。

図９は、実施例１に係る予定情報収集部４３ｃによる収集処理の手順を示すフローチャートである。図９に示すように、予定情報収集部４３ｃは、一定間隔ごとに予定管理システム５から履歴データを１件収集する（ステップＳ３０１）。そして、予定情報収集部４３ｃは、収集した履歴データからスケジュール登録者、会議予約・開始・終了時刻、イベント種別を抽出する（ステップＳ３０２）。

続いて、予定情報収集部４３ｃは、抽出したイベント種別を基に、イベントＩＤ（＝５ｏｒ６ｏｒ７）を設定して（ステップＳ３０３）、イベントＩＤごとの相手先リストを検索し（ステップＳ３０４）、リスト内に一致項目があるか否かを判定する（ステップＳ３０５）。

ここで、リスト内に一致項目がない場合には（ステップＳ３０５否定）、予定情報収集部４３ｃは、イベントＩＤにリストＮｏを付与して（ステップＳ３０６）、ユーザＤＢ４１の相手先リストに登録する（ステップＳ３０７）。そして、予定情報収集部４３ｃは、事象データ生成部４３ｄに抽出したスケジュール登録者、会議予約・開始・終了時刻、イベント種別を通知する（ステップＳ３０８）。

一方、リスト内に一致項目がある場合には（ステップＳ３０５肯定）、予定情報収集部４３ｃは、事象データ生成部４３ｄに抽出したスケジュール登録者、会議予約・開始・終了時刻、イベント種別を通知する（ステップＳ３０８）。そして、予定情報収集部４３ｃは、未読み込みデータがあるか否かを判定する（ステップＳ３０９）ここで、未読み込みデータがある場合には（ステップＳ３０９肯定）、予定情報収集部４３ｃは、ステップＳ３０１に戻って、履歴データを１件収集する。一方、未読み込みデータがない場合には（ステップＳ３０９否定）、予定情報収集部４３ｃは、処理を終了する。

図１０は、実施例１に係る事象データ生成部４３ｄによる処理の手順を示すフローチャートである。図１０に示すように、事象データ生成部４３ｄは、電話履歴収集部４３ａ、電子メール履歴収集部４３ｂ及び予定情報収集部４３ｃから通知された履歴データを時系列順に配列する（ステップＳ４０１）。そして、事象データ生成部４３ｄは、ユーザＤＢ４１に記憶された相手先リストを参照して（ステップＳ４０２）、イベント種別及び相手先をそれぞれイベントＩＤ及びリストＮｏに置換した事象データを生成してユーザＤＢ４１に登録して（ステップＳ４０３）、処理を終了する。

図１１は、実施例１に係る予測部４４による処理の手順を示すフローチャートである。図１１に示すように、実施例１に係る予測部４４は、まず、ユーザＤＢ４１に記憶された事象データを参照して、所定の時間幅ごとにデータを読み出す（ステップＳ５０１）。そして、予測部４４は、時間幅ごとにキーとなるイベントとリストＮｏの組を決定する（ステップＳ５０２）。

続いて、予測部４４は、キーとしたイベントＩＤとリストＮｏの組を除く全イベントの出現回数を時間幅ごとに対応付ける（ステップＳ５０３）。そして、予測部４４は、各キーに対応する塊に対して、各塊に含まれるイベントＩＤとリストＮｏとの組を新たなキーとして、新たなキーの情報を含む各塊に対応するキーと当該塊における新たなキーの出現回数の組を１つの塊として整理する（ステップＳ５０４）。

その後、予測部４４は、現時点での時間幅におけるユーザの履歴と照合して、回数の多い順に携帯端末に表示させて（ステップＳ５０５）、処理を終了する。

［実施例１の効果］
上述したように、実施例１によれば、通信ネットワーク６に接続された携帯端末１ごとに通信先の情報を記憶し、携帯端末１からの要求に応じて、通信先の情報を当該携帯端末１に提示する電話帳システム４であって、収集部４３が、携帯端末１ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する。そして、予測部４４が、収集部４３によって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する。従って、実施例１に係る電話帳システム４は、会議情報や発着信時間や発着信頻度などのコミュニケーション履歴情報を多角的に分析することにより、発信する可能性の高い連絡先を高精度に予測して並び替えて提示することができ、通信ネットワークを介して行われる高度かつ柔軟なネットワーク電話帳検索を可能にする。その結果、実施例１に係る電話帳システム４は、携帯端末から利用するネットワーク電話帳の利便性を向上させる。

また、実施例１によれば、予測部４４は、収集部４３によって収集された通信先の情報のうち、任意の時間区間内に出現した任意の通信先の情報に対して携帯端末１の利用者が現時点で通信を行うであろう通信先の情報を、同一の時間区間内で出現した他の通信先の情報の出現回数により予測する。従って、実施例１に係る電話帳システム４は、自端末以外のコミュニケーション履歴情報を利用することによって、連絡先の推薦精度を向上させることを可能にする。

また、実施例１によれば、ネットワーク電話帳システム１０内で一元管理されたネットワーク電話帳に各携帯端末から通信ネットワーク６を通じて接続することによって、電話帳の変更管理の稼働を削減することを可能にする。

また、実施例１によれば、ネットワーク電話帳システム１０内で一元管理されたネットワーク電話帳に各携帯端末から通信ネットワークを通じて接続することによって、携帯端末を紛失した際の秘匿情報漏洩のリスクを低減させることを可能にする。

上述した実施例１では、履歴データからキーの組を求める逆引きの関係を設定することで、提示する通信先を並び替える場合について説明した。実施例２では、履歴データをアソシエーション分析することで、提示する通信先を並び替える場合について説明する。なお、以下では、アソシエーション分析にアプリオリアルゴリズムを用いる例を説明するが、他のアルゴリズムも適用可能である。

まず、実施例２に係るネットワーク電話帳システムの構成について説明する。実施例２に係るネットワーク電話帳システムは、実施例１に係るネットワーク電話帳システムと同一の全体構成を有し、電話帳システムの処理内容が異なる。以下、これを中心に説明する。図１２は、実施例２に係る電話帳システム４ａの構成の一例を説明するための図である。図１２に示すように、実施例２に係る電話帳システム４ａは、ユーザＤＢ４１と、バスケットＤＢ４５と、ルールＤＢ４６と、収集部４７と、アソシエーション分析部４８と、予測部４４ａとを有する。

ユーザＤＢ４１は、実施例１と同様に、収集部４７によって収集された相手先リストと、収集部４７によって生成された事象データなどを記憶する。バスケットＤＢ４５は、後述する収集部４７の処理結果を記憶する。図１３は、バスケットＤＢ４５によって記憶される情報の一例を説明するための図である。図１３に示すように、バスケットＤＢ４５は、「バスケットＮｏ」と、「アイテムＩＤ」と、「イベント種別」と、「相手先」と、「時刻」とを対応付けた情報を記憶する。

ここで、図１３に示す「バスケットＮｏ」とは、後述する収集部４７によって付与される番号であり、時間幅を一意に特定するための識別子を示す。また、図１３に示す「アイテムＩＤ」とは、イベント種別と相手先の情報とを一意に特定するための識別子を示す。例えば、バスケットＤＢ４５は、図１３に示す、「バスケットＮｏ：１、アイテムＩＤ：５、イベント種別：会議予約、相手先：中村たろう、時刻：２０１１／４／１９ １５：３３」のように、「バスケットＮｏ」と、「アイテムＩＤ」と、「イベント種別」と、「相手先」と、「時刻」とを対応付けた情報を記憶する。

図１２に戻って、ルールＤＢ４６は、後述するアソシエーション分析部４８の処理結果であるアソシエーションルールを記憶する。なお、ルールＤＢ４６によって記憶されるアソシエーションルールについては、後に詳述する。

収集部４７は、図１２に示すように、電話履歴収集部４３ａと、電子メール履歴収集部４３ｂと、予定情報収集部４３ｃと、事象データ生成部４３ｅとを有する。図１２に示すように、実施例２に係る収集部４７は、実施例１に係る収集部４３と比較して、事象データ生成部の処理内容が異なる。以下、収集部４７については、これを中心に説明する。

事象データ生成部４３ｅは、電話履歴収集部４３ａ、電子メール履歴収集部４３ｂ及び予定情報収集部４３ｃから通知された履歴データを任意の時間幅であるバスケットごとに分類し、分類結果をバスケットＤＢ４５に登録する。具体的には、事象データ生成部４３ｅは、まず、電話履歴収集部４３ａ、電子メール履歴収集部４３ｂ及び予定情報収集部４３ｃから一定間隔で通知された全ての履歴データを時系列順に並べる。そして、事象データ生成部４３ｅは、一定間隔の全時間幅を予め設定されたバスケットの枠Ｔ（時間幅）で等分割し、等分割した各時間区間を識別するバスケットＮｏを付与する。

例えば、事象データ生成部４３ｅは、図１３に示すように、一定間隔で収集された９つの履歴データを時系列順に並べる。そして、事象データ生成部４３ｅは、図１３に示すように、時系列順に並べた履歴データをバスケット枠Ｔ＝１時間で分割し、分割した各時間区間に含まれる履歴データそれぞれに新しい順から昇順にバスケットＮｏ「１〜３」を付与する。

そして、事象データ生成部４３ｅは、各履歴データから発着信時刻に対応する電話番号と、送受信時刻に対応するメールアドレスと、会議登録・開始・終了時刻に対応するスケジュール登録者を抽出して、古い順から昇順にアイテムＩＤを付与して、バスケットＤＢ４５に登録する。例えば、事象データ生成部４３ｅは、図１３に示すように、各履歴データにアイテムＩＤを付与して、バスケットＤＢ４５に登録する。

アソシエーション分析部４８は、バスケットＤＢ４５によって記憶されたバスケットごと分類された情報に対してアソシエーション分析を実行してアソシエーションルールを抽出する。具体的には、まず、アソシエーション分析部４８は、バスケットごとに分類された情報から、支持度に基づいて、頻出アイテム集合Ｆを抽出する。そして、アソシエーション分析部４８は、抽出した頻出アイテム集合Ｆから、信頼度に基づいて、アソシエーションルールを抽出する。なお、支持度とは、条件（Ｘ）と結論（Ｙ）とを共に含むトランザクション件数／全トランザクション件数である。また、信頼度とは、条件（Ｘ）と結論（Ｙ）とを共に含むトランザクション件数／条件（Ｘ）を含むトランザクション件数である。

図１４は、実施例２に係るアソシエーション分析部４８による第１の処理を説明するための図である。図１４においては、図１３に示す情報に対して、頻出アイテム集合Ｆを抽出する処理を実行した例について示す。ここで、図１４に示す例では、最小支持度を０．６６（６６％）とし、それ以上の支持度のアイテムセットである頻出アイテム集合Ｆを抽出する場合について示す。ここで、まず、アソシエーション分析部４８は、支持度０．６６以上の頻出アイテム集合Ｆを抽出するために、図１４に示すように、バスケットＮｏ１〜３に含まれるアイテムＩＤ単体の出現頻度を算出し、出現頻度が６６％以上であるものを抽出する。

例えば、図１４に示すように、バスケットＮｏ１〜３のすべてにアイテムＩＤが含まれることから全トランザクション数は「３」となり、「アイテムＩＤ：１」はすべてのバスケット内に含まれることから、アソシエーション分析部４８は、「アイテムＩＤ：１」の支持度を「１．０」と算出して、出現頻度が６６％以上であるアイテムＩＤとして抽出する。同様に、アソシエーション分析部４８は、「アイテムＩＤ：２」の支持度を「０．６６」、「アイテムＩＤ：５」の支持度を「０．６６」と算出して、出現頻度が６６％以上であるアイテムＩＤとして抽出する。一方、「アイテムＩＤ：４」は「バスケットＮｏ：３」にのみ含まれることから、アソシエーション分析部４８は、「アイテムＩＤ：４」の支持度を「０．３」と算出し、出現頻度が６６％未満であることから「アイテムＩＤ：４」を抽出しない。

そして、アソシエーション分析部４８は、抽出したアイテムＩＤ１、２及び５について、すべての組合せ（全サイズ）の出現頻度を算出して、出現頻度が６６％以上であるアイテムＩＤの組を抽出する。すなわち、アソシエーション分析部４８は、アイテムＩＤ１、２及び５を含む集合Ｆから要素（組合せ）Ｚ∈Ｆを抽出して、要素ＺをアイテムＩＤ（Ｘ又はＹ）の和集合（Ｚ＝Ｘ∪Ｙ）とし、「Ｘ→Ｙ」の支持度が最小支持度０．６６（６６％）以上であるアイテムＩＤの組を抽出する。

例えば、アソシエーション分析部４８は、図１４に示すように、「アイテムＩＤ１、２」と、「アイテムＩＤ１、５」と、「アイテムＩＤ２、５」と、「アイテムＩＤ１、２、５」を支持度０．６６（６６％）以上のアイテムＩＤの組である頻出アイテム集合Ｆとして抽出する。

図１５は、実施例２に係るアソシエーション分析部４８による第２の処理を説明するための図である。図１５においては、図１４にて抽出された頻出アイテム集合Ｆから、信頼度に基づいて、アソシエーションルールを抽出する処理を実行した例について示す。ここで、図１５に示す例では、最小信頼度を０．６６（６６％）とし、それ以上の信頼度のアイテムＩＤの組をアソシエーションルールとして抽出する場合について示す。

例えば、アソシエーション分析部４８は、図１５に示すように、まず、図１４に示す処理により抽出した頻出アイテム集合Ｆを、頻出アイテム集合Ｆに含まれるアイテムＩＤに基づいてトランザクションに分割し、それぞれに対して処理を行う。アソシエーション分析部４８は、トランザクションごとにアイテムＩＤの組を抽出し、抽出したアイテムＩＤの組の信頼度を、上述した支持度と同様に算出し、信頼度０．６６（６６％）以上のアイテムＩＤの組をアソシエーションルールとして抽出する。

例えば、アソシエーション分析部４８は、図１５に示すように、「アイテムＩＤ１、２」と、「アイテムＩＤ１、５」と、「アイテムＩＤ２、５」とを信頼度０．６６（６６％）以上のアイテムＩＤの組であるアソシエーションルールとして抽出する。すなわち、アソシエーション分析部４８は、各アイテムＩＤに対応するイベント種別と相手先との組合せをアソシエーションルールとして抽出して、ルールＤＢ４６に登録する。一例を挙げると、アソシエーション分析部４８は、「０９０１２３４５６７８へのＴＥＬ発信」と「０８０２２２２３３３３」との組をアソシエーションルールとして抽出し、ルールＤＢ４６に登録する。

図１２に戻って、予測部４４ａは、ルールＤＢ４６に記憶されたアソシエーションルールを参照して、現時点での時間幅にあるアイテムＩＤを条件部としたアソシエーションルールを抽出し、抽出したアソシエーションルールの帰結部を携帯端末１に提示する。例えば、予測部４４ａは、現在時刻が図１３のバスケットＮｏ３の時間幅に含まれていた場合に、コミュニケーションツールが起動されると、バスケットＮｏ３に含まれるアイテムＩＤ５、１、２とアソシエーションルールを持つアイテムＩＤをバスケットＤＢ４５から読み出す。すなわち、予測部４４ａは、「０９０１２３４５６７８へのＴＥＬ発信」と、「０８０２２２２３３３３からのＴＥＬ着信」と、「中村たろうが参加する会議予約」とをアイテムＩＤの降順に並び替えた連絡先を携帯端末１に提示する。なお、ここでは、それぞれの信頼度が０．６６で同値であるため、アイテムＩＤの降順に並び替えた連絡先を携帯端末１に提示するが、信頼度が異なる場合は、信頼度の高い順に並び替えた連絡先を携帯端末１に提示する。

次に、実施例２に係る電話帳システム４ａによる処理の手順について、図１６〜１９を用いて説明する。図１６は、実施例２に係る電話帳システム４ａによる処理の手順を示すフローチャートである。図１６に示すように、収集部４７は、一定間隔ごとに構内交換システム３、メールサーバ２、予定管理システム５から履歴データを収集する（ステップＳ６０１）。そして、バスケットの枠Ｔ、最小支持度Ｓ、最小信頼度Ｃが設定されると（ステップＳ６０２）、事象データ生成部４３ｅは、対象となる全時間幅をＴで等分割し、分割した各時間区間を識別する番号として、新しい順から昇順にバスケットＮｏを付与する（ステップＳ６０３）。

続いて、事象データ生成部４３ｅは、各履歴データから発着信時刻に対応する電話番号と、送受信時刻に対応するメールアドレスと、会議登録・開始・終了時刻に対応するスケジュール登録者を抽出する（ステップＳ６０４）。そして、事象データ生成部４３ｅは、抽出したイベントに関する情報に、古い順から昇順にアイテムＩＤを付与してバスケットＤＢ４５に登録する（ステップＳ６０５）。

その後、アソシエーション分析部４８は、得られたバスケット群に対して、アソシエーション分析を実行し、アソシエーションルール群を抽出して、ルールＤＢ４６に登録し（ステップＳ６０６）、処理を終了する。

図１７は、実施例２に係るアソシエーション分析部４８によるアソシエーションルール抽出処理の手順を示すフローチャートである。なお、図１７に示す処理は、図１６のステップＳ６０６の処理に相当する。図１７に示すように、アソシエーション分析部４８は、バスケットＤＢ４５を参照して、全てのサイズの頻出アイテム集合Ｆを抽出する（ステップＳ７０１）。そして、アソシエーション分析部４８は、抽出した頻出アイテム集合Ｆから要素Ｚ∈Ｆを抽出し（ステップＳ７０２）、Ｚを共通部分のないＸとＹに分割する（Ｚ＝Ｘ∪Ｙ）（ステップＳ７０３）。

続いて、アソシエーション分析部４８は、分割したＸ→Ｙの信頼度ｓ（Ｘ→Ｙ）を算出して（ステップＳ７０４）、算出したｓ（Ｘ→Ｙ）が最小信頼度Ｃ以上であるか否かを判定する（ステップＳ７０５）。ここで、算出したｓ（Ｘ→Ｙ）が最小信頼度Ｃ以上である場合には（ステップＳ７０５肯定）、アソシエーション分析部４８は、アソシエーションルール「Ｘ→Ｙ」をルールＤＢ４６に登録して（ステップＳ７０６）、Ｚの全ての分割をチェックしたか否かを判定する（ステップＳ７０７）。

一方、算出したｓ（Ｘ→Ｙ）が最小信頼度Ｃ未満である場合には（ステップＳ７０５否定）、アソシエーション分析部４８は、Ｚの全ての分割をチェックしたか否かを判定する（ステップＳ７０７）。そして、Ｚの全ての分割をチェックしていない場合には（ステップＳ７０７否定）、アソシエーション分析部４８は、ステップＳ７０３に戻って、Ｚを共通部分のないＸとＹに分割する（Ｚ＝Ｘ∪Ｙ）。

一方、Ｚの全ての分割をチェックした場合には（ステップＳ７０７肯定）、アソシエーション分析部４８は、頻出アイテム集合Ｆの全ての要素をチェックしたか否かを判定する（ステップＳ７０８）。ここで、頻出アイテム集合Ｆの全ての要素をチェックしていない場合には（ステップＳ７０８否定）、アソシエーション分析部４８は、ステップＳ７０２に戻って、頻出アイテム集合Ｆから要素Ｚ∈Ｆを抽出する。一方、頻出アイテム集合Ｆの全ての要素をチェックした場合には（ステップＳ７０８肯定）、アソシエーション分析部４８は、処理を終了する。

図１８は、実施例２に係るアソシエーション分析部４８による頻出アイテム集合の抽出処理の手順を示すフローチャートである。なお、図１８に示す処理は、図１７のステップＳ７０１の処理に相当する。図１８に示すように、アソシエーション分析部４８は、バスケットＤＢ４５を参照して、アイテムＩＤ集合Ｆから要素Ｚ∈Ｆを抽出する（ステップＳ８０１）。そして、アソシエーション分析部４８は、Ｚを共通部分のないＸとＹに分割する（Ｚ＝Ｘ∪Ｙ）（ステップＳ８０２）。

続いて、アソシエーション分析部４８は、分割したＸ→Ｙの支持度Ｆ（Ｘ→Ｙ）を算出して（ステップＳ８０３）、算出したＦ（Ｘ→Ｙ）が最小支持度Ｓ以上であるか否かを判定する（ステップＳ８０４）。ここで、算出したＦ（Ｘ→Ｙ）が最小支持度Ｓ以上である場合には（ステップＳ８０４肯定）、アソシエーション分析部４８は、Ｚの全ての分割をチェックしたか否かを判定する（ステップＳ８０５）。

ここで、Ｚの全ての分割をチェックしていない場合には（ステップＳ８０５否定）、アソシエーション分析部４８は、ステップＳ８０３に戻って、Ｘ→Ｙの支持度Ｆ（Ｘ→Ｙ）を算出する。一方、Ｚの全ての分割をチェックした場合には（ステップＳ８０５肯定）、アソシエーション分析部４８は、Ｆの全ての要素をチェックしたか否かを判定する（ステップＳ８０６）。

また、ステップＳ８０４において、算出したＦ（Ｘ→Ｙ）が最小支持度Ｓ未満である場合には（ステップＳ８０４否定）、アソシエーション分析部４８は、Ｆの全ての要素をチェックしたか否かを判定する（ステップＳ８０６）。ここで、Ｆの全ての要素をチェックしていない場合には（ステップＳ８０６否定）、アソシエーション分析部４８は、ステップＳ８０２に戻って、Ｚを共通部分のないＸとＹに分割する（Ｚ＝Ｘ∪Ｙ）。一方、Ｆの全ての要素をチェックした場合には（ステップＳ８０６肯定）、アソシエーション分析部４８は、処理を終了する。

図１９は、実施例２に係る予測部４４ａによる処理の手順を示すフローチャートである。図１９に示すように、予測部４４ａは、バスケットＤＢ４５から最新のバスケットＮｏ内のアイテムＩＤを読み込む（ステップＳ９０１）。そして、予測部４４ａは、読み込んだアイテムＩＤに合致する条件部を持つアソシエーションルールをルールＤＢ４６から抽出する（ステップＳ９０２）。その後、予測部４４ａは、抽出したルールの帰結部に対応するイベント情報（電話番号、メールアドレス、スケジュール登録者）を携帯端末１に提示して（ステップＳ９０３）、処理を終了する。

［実施例２の効果］
上述したように、実施例２によれば、予測部４４ａは、収集部４７によって収集された通信先の情報間のアソシエーション分析の結果に基づいて、携帯端末１の利用者が現時点で通信を行うであろう通信先の情報を予測する。従って、実施例２に係る電話帳システム４ａは、組織内の全ての端末のコミュニケーション履歴を用いることで自端末のコミュニケーション履歴のみを用いて分析するより高精度に連絡先候補を並び替えることを可能にする。

上述した実施例２では、履歴データをアソシエーション分析することで、提示する通信先を並び替える場合について説明した。実施例３では、履歴データのパターンや頻度などの事柄を事前確率とし、発信確率を事後確率としたときの条件付確率から提示する通信先を並び替える場合について説明する。

まず、実施例３に係るネットワーク電話帳システムの構成について説明する。実施例３に係るネットワーク電話帳システムは、実施例１に係るネットワーク電話帳システムと同一の全体構成を有し、電話帳システムの処理内容が異なる。以下、これを中心に説明する。図２０は、実施例３に係る電話帳システム４ｂの構成の一例を説明するための図である。図２０に示すように、実施例３に係る電話帳システム４ｂは、ユーザＤＢ４１ａと、確率変数ＤＢ４９と、収集部４３と、適合性フィードバック部５０とを有する。

ユーザＤＢ４１ａは、後述する適合性フィードバック部５０による処理結果に基づいて、電話帳内のメンバーを並び替えた結果を記憶する。確率変数ＤＢ４９は、後述する適合性フィードバック部５０による処理結果を記憶する。具体的には、確率変数ＤＢ４９は、履歴データのパターン、スケジュール及び頻度などの事柄とユーザの発信確率の確率的な因果関係を有向グラフとして表した確率変数を記憶する。

図２１は、実施例３に係る確率変数ＤＢ４９によって記憶される情報の第１の例を説明するための図である。図２１においては、グラフ構造として、履歴データにパターンがあるか否かを表すパターン（pattern）と、予定までの時間を表すスケジュール（schedule）と、直近の発着信頻度を表す頻度（frequency）とを事前確率として、ａさんへの発信確率（a_recommend）を示す。図２１に示すように、確率変数ＤＢ４９は、頻度（frequency）、スケジュール（schedule）、パターン（pattern）の各事柄の組合せごとにａさんへの発信確率（a_recommend）が対応付けられた確率変数を記憶する。

図２２は、実施例３に係る確率変数ＤＢ４９によって記憶される情報の第２の例を説明するための図である。図２２においては、図２１に示す確率変数において、事前確率の頻度（frequency）が「１０」以上となった場合の確率変数を示す。換言すると、ａさんとの直近の発着信頻度が「１０」以上になった場合の確率変数を示す。図２１及び図２２には、ａさんへの発信確率を示す確率変数のみが示されているが、実際には、確率変数ＤＢ４９は、電話帳のメンバーそれぞれに対する確率変数を記憶する。

図２０に戻って、適合性フィードバック部５０は、収集部４３によって収集された履歴データからスケジュール、パターン、頻度などの事柄を抽出して、それらを事前確率とし、電話帳のメンバーそれぞれに対する確率変数を算出して、算出した確率変数を用いて、電話帳のメンバーそれぞれに対する発信確率を算出する。ここで、適合性フィードバック部５０は、ユーザから発信を実行するごとに、確率変数を更新して、発信確率を計算する。

一例を説明すると、適合性フィードバック部５０は、ユーザから電話帳に含まれるメンバー（ａさん）への電話発信があると、そのａさんへの過去の発信履歴の平均間隔と比較して、差分が閾値以内であるか否かを判定し、差分が閾値以内である場合にはパターン有とし、差分が閾値以上である場合にはパターン無とする。すなわち、適合性フィードバック部５０は、ユーザが行った電話発信が、定例的なパターン性のあるものであるか否かを判定する。そして、適合性フィードバック部５０は、ａさんが参加する予定までの時間を取得する。すなわち、適合性フィードバック部５０は、ａさんのスケジュールとの因果関係を考慮する。

続いて、適合性フィードバック部５０は、所定の時間（例えば、ｔ＝１時間）以内のａさんのメールと電話の発着信数を取得し、取得した発着信数を０〜１に正規化した値に変換する。具体的には、適合性フィードバック部５０は、相手先ごとに発着信数を取得し、最多の発着信数を「１」、最少の発着真数を「０」とした場合の値に変換する。

ここで、適合性フィードバック部５０は、予定開始までの時間をいくつかの間隔に分け、予定開始時刻に近いほど確率が高くなるように、事前確率を設定する。例えば、適合性フィードバック部５０は、図２１及び図２２のスケジュールに示すように、予定開始時刻まで時間を２４時間間隔で分け、予定開始時刻に近いほどａさんへの発信確率が高くなるようにスケジュールの発信確率を設定する。

また、適合性フィードバック部５０は、発信間隔が過去の発信間隔と同間隔であった場合に、発信確率が上昇するように処理を行う。例えば、適合性フィードバック部５０は、発着信履歴の間隔のパターンを発着信履歴の間隔の平均で表し、前回の発着信時刻から現在の発着信時刻までの間隔と平均の間隔との差の絶対値の逆数をパターンの発信確率として設定する。

さらに、適合性フィードバック部５０は、直近のメール・電話の発着信数が多い人の発信確率が上昇するように処理を行う。例えば、適合性フィードバック部５０は、現在から過去の任意の時間における発着信頻度と通話時間を頻度の発信確率として設定する。

適合性フィードバック部５０は、上記したような適合性フィードバック処理を実行した後、ベイズの定理を用いて事後確率を算出し、発信確率順に電話帳内のメンバーを並べ替えてユーザＤＢ４１ａに登録する。事後確率は、事前確率ｐ（Ｘｉ）の条件付確率を、Ｐ（Ｘｉ｜Ｘｊ）＝ｐ（Ｘｊ｜Ｘｉ）ｐ（Ｘｉ）／ｐ（Ｘｊ）として算出される。

そして、各確率が図２１に示す場合、ａさんへの発信確率は、Ｐ(pattern)×Ｐ(schedule)×Ｐ(frequency)×Ｐ("a_recommend"=yes | pattern, schedule, frequency)の全ての組み合わせの和 ／Ｐ(pattern)×Ｐ(schedule)×Ｐ(frequency)×Ｐ("a_recommend"=yes | pattern, schedule, frequency)の全ての組み合わせの和 + Ｐ(pattern)×Ｐ(schedule)×Ｐ(frequency)×Ｐ("a_recommend"=no | pattern, schedule, frequency)の全ての組み合わせの和であり、図２１に示すように、３７．７６となる。

また、各確率が図２２に示す場合、ａさんへの発信確率は、図２２に示すように、７７．８５となる。すなわち、頻度の条件が加わったことにより、ａさんへの発信確率が大幅に高くなる。適合性フィードバック部５０は、電話帳内のメンバーすべてに対して、発信確率を算出し、発信確率が高い順に携帯端末１に提示する。

次に、実施例３に係る適合性フィードバック部５０による処理の手順について、図２３を用いて説明する。図２３は、実施例３に係る電話帳システム４ｂによる処理の手順を示すフローチャートである。図２３に示すように、ユーザからの情報発信があると（ステップＳ１００１肯定）、適合性フィードバック部５０は、パターンの有無を解析して（ステップＳ１００２）、発信先のメンバーが参加する予定までの時間を取得する（ステップＳ１００３）。

そして、適合性フィードバック部５０は、Ｔ時間以内のメールと電話の発着信数を取得して（ステップＳ１００４）、それぞれの事柄を０〜１に正規化した値に変換する（ステップＳ１００５）。その後、適合性フィードバック部５０は、ベイズの条件付確率定義により条件付確率を算出して、発信確率を確率変数ＤＢ４９に登録する（ステップＳ１００６）。

続いて、適合性フィードバック部５０は、全ての電話帳内メンバーの発信確率を読み込み（ステップＳ１００７）、発信確率順に降順に並び替える（ステップＳ１００８）。そして、適合性フィードバック部５０は、並び替えた結果をユーザＤＢ４１ａに登録して（ステップＳ１００９）、処理を終了する。

［実施例３の効果］
上述したように、実施例３によれば、適合性フィードバック部５０は、収集部４３によって通信先の情報が収集されるごとに、収集済みの通信先の情報の条件付確率を算出し、算出した条件付確率に基づいて、携帯端末１の利用者が現時点で通信を行うであろう通信先の情報を予測する。従って、実施例３に係る電話帳システム４ｂは、発着信頻度や発着信時間の傾向、スケジュール情報などより多くのコミュニケーション履歴を用いることで、高精度で通信先候補を並び替えることを可能にする。

これまで実施例１、２及び３について説明したが、本願の技術は実施例１、２及び３に限定されるものではない。すなわち、実施例１、２及び３は、その他の様々な形態で実施されることが可能であり、種々の省略、置き換え、変更を行うことができる。

例えば、各装置の分散・統合の具体的形態（例えば、図２の形態）は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合することができる。一例を挙げると、電話履歴収集部４３ａと、電子メール履歴収集部４３ｂと、予定情報収集部４３ｃとを履歴データ収集部として統合してよい。

また、収集部４７を電話帳システム４の外部装置としてネットワーク経由で接続するようにしてもよく、或いは、予測部４４と収集部４３とを別々の装置が有し、ネットワークに接続されて協働することで、上述した電話帳システム４の機能を実現するようにしてもよい。

上記実施例１、２及び３で説明したネットワーク電話帳システム１０は、あらかじめ用意されたプログラムをコンピュータで実行することで実現することもできる。そこで、以下では、図２に示した電話帳システム４と同様の機能を実現する情報提示プログラムを実行するコンピュータの一例を説明する。

図２４は、実施例４に係る情報提示プログラムを実行するコンピュータ１０００を示す図である。図２４に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ（Central Processing Unit）１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。

ここで、図２４に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。実施例４に係る情報提示プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０９０に記憶される。具体的には、上記実施例で説明した収集部４３と同様の情報処理を実行する収集ステップと、予測部４４と同様の情報処理を実行する予測ステップとが記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。

また、上記実施例で説明したユーザＤＢ４１に記憶されるデータのように、情報提示プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュールやプログラムデータを必要に応じてＲＡＭ１０１２に読み出して、収集ステップと、予測ステップとを実行する。

なお、情報提示プログラムに係るプログラムモジュールやプログラムデータは、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、情報提示プログラムに係るプログラムモジュールやプログラムデータは、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

これらの実施例やその変形は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ 携帯端末
２ メールサーバ
３ 構内交換システム
４、４ａ、４ｂ 電話帳システム
５ 予定管理システム
１０ ネットワーク電話帳システム
４３ 収集部
４３ａ 電話履歴収集部
４３ｂ 電子メール履歴収集部
４３ｃ 予定情報収集部
４３ｄ、４３ｅ 事象データ生成部
４４、４４ａ 予測部
４８ アソシエーション分析部
５０ 適合性フィードバック部

Claims (6)

1. ネットワークに接続された携帯端末ごとに通信先の情報を記憶し、前記携帯端末からの要求に応じて、前記通信先の情報を当該携帯端末に提示する情報提示システムであって、
   前記携帯端末ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する収集部と、
   前記収集部によって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する予測部と、
   を備えたことを特徴とする情報提示システム。
2. 前記予測部は、前記収集部によって収集された通信先の情報のうち、前記任意の時間区間内に出現した任意の通信先の情報に対して前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を、同一の時間区間内で出現した他の通信先の情報の出現回数により予測することを特徴とする請求項１に記載の情報提示システム。
3. 前記予測部は、前記収集部によって収集された通信先の情報間の相関分析を行うことで、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測することを特徴とする請求項１又は２に記載の情報提示システム。
4. 前記予測部は、前記収集部によって通信先の情報が収集されるごとに、収集済みの通信先の情報の条件付確率を算出し、算出した条件付確率に基づいて、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測することを特徴とする請求項１〜３のいずれか一つに記載の情報提示システム。
5. ネットワークに接続された携帯端末ごとに通信先の情報を記憶し、前記携帯端末からの要求に応じて、前記通信先の情報を当該携帯端末に提示する情報提示システムによって実行される情報提示方法であって、
   前記携帯端末ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する収集工程と、
   前記収集工程によって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する予測工程と、
   を含んだことを特徴とする情報提示方法。
6. ネットワークに接続された携帯端末ごとに通信先の情報を記憶し、前記携帯端末からの要求に応じて、前記通信先の情報を当該携帯端末に提示する情報提示システムに含まれるコンピュータに実行させる情報提示プログラムであって、
   前記携帯端末ごとに、電話の発着信が行われた通信先の情報と、メールの送受信が行われた通信先の情報と、当該携帯端末の利用者のスケジュールに関与する通信先の情報とを収集する収集ステップと、
   前記収集ステップによって収集された通信先の情報の任意の時間区間における出現頻度に基づいて、前記携帯端末の利用者が現時点で通信を行うであろう通信先の情報を予測し、予測した通信先の情報を当該携帯端末に提示する予測ステップと、
   をコンピュータに実行させることを特徴とする情報提示プログラム。

Images