電話帳データを統合するための装置、方法及びコンピュータプログラム
【課題】複数の通信端末各々に保存されている電話帳を、何れかの通信端末の電話帳に統合する際に、同一ユーザのデータが重複して作成されないようにすること。
【解決手段】電話帳データ統合装置は、統合する複数の電話帳のデータを取得するデータ取得部と、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部とを有する。
【解決手段】電話帳データ統合装置は、統合する複数の電話帳のデータを取得するデータ取得部と、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電話帳データを統合するための装置、方法及びコンピュータプログラムに関連する。
【背景技術】
【０００２】
通信サービスの多様化、通信端末の普及及び高機能化等に伴って、複数の通信端末を所有するユーザが増えつつある。このようなユーザは、例えば、音声による電話通信を行うための標準機と、意見の投稿やアプリケーションの実行等のための情報端末（例えば、スマートフォン等）とを使い分けている。しかしながら、情報端末等がさらに高性能化するにつれて、複数の通信端末を所有する代わりに、所有する通信端末を1台の情報端末で済ませたいという要請もある。このような要請に応じるには、複数の通信端末各々に保存されている電話帳を、1台の情報端末に統合する必要がある。この場合において、一方の通信端末の電話帳を他方の通信端末の電話帳に単にコピーしたにすぎない場合、同一のユーザの情報が電話帳の中で重複して存在することになり、不便である。この点に関し、取り外し可能な外部データベースを通信端末の内部データベースにコピーすることで、同一ユーザについて重複したデータが生成される技術については、例えば特許文献1に記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2004−88542号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の課題は、複数の通信端末各々に保存されている電話帳を、何れかの通信端末の電話帳に統合する際に、同一ユーザのデータが重複して作成されないようにすることである。
【課題を解決するための手段】
【０００５】
一実施例による電話帳データ統合装置は、
統合する複数の電話帳のデータを取得するデータ取得部と、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、
統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部と
を有する電話帳データ統合装置である。
【発明の効果】
【０００６】
一実施例によれば、複数の通信端末各々に保存されている電話帳を、何れかの通信端末の電話帳に統合する際に、同一ユーザのデータが重複して作成されないようにすることができる。
【図面の簡単な説明】
【０００７】
【図１】通信システムの概要を示す図。
【図２】通信端末及びサービス提供サーバ間の動作例を示す図。
【図３】電話帳に保存されている個人情報の一例を示す図。
【図４】2つの電話帳各々から値が抽出された様子を示す図。
【図５】各々の電話帳の個人情報が併合される様子を示す図。
【図６】通信端末の機能ブロック図。
【図７】サービス提供サーバの機能ブロック図。
【図８】変形例における動作例を示す図。
【図９】変形例における通信端末の機能ブロック図。
【発明を実施するための形態】
【０００８】
一実施例による電話帳データ統合装置は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成し、特徴ベクトル同士の類似度に基づいて、ユーザの異同を判別する。ユーザの異同判別結果に基づいて、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を的確に判別でき、その情報を統合先の電話帳に追加することで、複数の電話帳のデータが過不足無く統合される。
【０００９】
以下の観点から実施例を説明する。
【００１０】
1．通信システム
2．動作例
3．通信端末
4．サービス提供サーバ
5．変形例
【実施例１】
【００１１】
＜1．通信システム＞
図1は、実施例で使用される通信システムの概要を示す。通信システムは、通信端末10、通信網20及びサービス提供サーバ30を少なくとも含む。通信端末10は、通信網20を介して情報を通信することが可能な適切な如何なる通信端末でもよい。
【００１２】
通信端末は、典型的には移動端末であるが、固定端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるがこれらに限定されない。
【００１３】
通信網20は、通信端末10とサービス提供サーバ30との間の通信を可能にする適切な如何なる通信網でもよい。通信網20は、典型的には移動通信網を含むが、無線又は有線による適切な如何なる通信網を含んでよい。通信網20は、インターネット網のようなセキュリティは低いが、広範囲にわたって通信をすることが可能なネットワークを含んでもよい。通信網20は、秘密情報を安全に通信することが可能なセキュリティネットワークを含んでもよい。
【００１４】
サービス提供サーバ30は、様々なユーザの通信端末と接続され、様々なユーザの情報を管理し、本実施例による電話帳統合サービスを提供する。電話帳統合サービスの具体的な内容については後述する。ユーザの情報には、電話帳の情報、通信端末の利用履歴情報等が含まれる。電話帳の情報は、ユーザが通信端末に登録している連絡先ユーザの個人情報が含まれている。個人情報は、連絡先ユーザの氏名、名称（会社名、組織名等）、ニックネーム、電話番号（自宅電話番号、会社電話番号等）、メールアドレス（キャリアメール、PCメール等のメールのアドレス）、ソーシャルネットワークサービス（SNS）のアカウント、住所、誕生日、説明文等であるが、これらに限定されない。利用履歴情報は、ユーザによる通信端末の操作履歴、発信履歴、着信履歴、アプリケーションの起動及び削除の履歴、情報の発信履歴（投稿等を含む。）、情報の受信履歴等であるが、これらに限定されない。
【００１５】
＜2．動作例＞
図2は、通信端末10及びサービス提供サーバ30間の動作例を示す。2台の通信端末を有するユーザが、2台各々に保存されている電話帳を、1つの通信端末の電話帳に統合しようとしているものとする。この場合、ユーザが手作業でユーザの異同を判断しながら、2つの電話帳を1つに統合することも技術的には可能である。しかしながら、電話帳に登録しているユーザ数が多い場合、そのような手作業は困難になる。以下に説明する動作例では、通信端末10とネットワークを介して接続されるサービス提供サーバ30が、複数の電話帳を統合する処理を支援する。移行元の通信端末10及び移行先の通信端末10は、典型的には、同一のユーザが所有しているが、異なるユーザが所有していているものであってもよい。
【００１６】
まず、2台の通信端末10を有するユーザが、サービス提供サーバ30に対して、2つの電話帳を統合することを希望する意思表示を行う（図示せず）。その後、移行元の通信端末10及び移行先の通信端末10各々の電話帳のデータが、サービス提供サーバ30に送信される（ステップS21、S22）。
【００１７】
図3は、ステップS21、S22において、各通信端末10からサービス提供サーバ30へ送信される電話帳のデータの内、ユーザA、Pとして登録されているデータを示す。移行元におけるユーザAと移行先におけるユーザPは、異なるユーザかもしれないし、同じユーザであるかもしれない。
【００１８】
移行元及び移行先の何れにおいても、電話帳のデータは、属性と値の組み合わせにより表現される。属性と値により表現される情報は、「情報要素」として言及される。図3に示す情報要素の種類及び数は、単なる一例にすぎず、適切な如何なる情報要素が幾つ設定されてもよい。
【００１９】
移行元の通信端末10の場合、ユーザAのプロフィール（個人情報）は、「姓名」、「性別」、「会社電話番号」、「携帯電話番号」、「メールアドレス1」、「メールアドレス2」及び「誕生日」という属性を有する。これらの属性各々について、値が設定されている。「姓名」には「ユーザA」を表す値が設定されている。「性別」には「男」を表す値が設定されている。「会社電話番号」には「111−111−1111」という電話番号を表す値が設定されている。「携帯電話番号」には「444−444−4444」という電話番号を表す値が設定されている。「メールアドレス1」には「AAA＠AAA．com」というアドレスが設定されている。「メールアドレス2」には「CCC＠CCC．com」というアドレスが設定されている。「誕生日」には「1983．11．23」という日付を表す値が設定されている。
【００２０】
移行先の通信端末10の場合、ユーザPのプロフィール（個人情報）は、「姓名」、「性別」、「会社電話番号」、「携帯電話番号」、「誕生日」、「SNSアカウント1」及び「SNSアカウント2」という属性を有する。これらの属性各々についても値が設定されている。「姓名」には「ユーザP」を表す値が設定されている。「性別」には「男」を表す値が設定されている。「会社電話番号」には「111−111−1111」という電話番号を表す値が設定されている。「携帯電話番号」には「444−444−4444」という電話番号を表す値が設定されている。「誕生日」には「1983．11．23」という日付を表す値が設定されている。「SNSアカウント1」には「helloworld」というソーシャルネットワークサービス（SNS）のためのアカウントを表す値が設定されている。「SNSアカウント2」には「mxworld」というSNSのためのアカウントを表す値が設定されている。
【００２１】
一般に、2つの電話帳各々に登録されているユーザに関し、携帯電話番号、メールアドレス及び姓名が一致していた場合、そのユーザは同一人物であると判断してよい。しかしながら、携帯電話番号、メールアドレス及び姓名の内の1つ以上が一致していなかったとしても、それらのユーザが別人であるとは限らない。説明の便宜上、携帯電話番号、メールアドレス及び姓名の属性を、「プライマリ属性」と言うことにする。
【００２２】
図2のステップS23において、統合すべき2つの電話帳の各ユーザのプライマリ属性の異同を判定することで、同一ユーザと判断されるユーザが選別される。プライマリ属性の内の1つ以上が一致していかなかったとしても、それらのユーザが別人であるとは限らない。そこで、以下に説明する方法により、プライマリ属性が完全に一致していないユーザ同士の異同を判定する。
【００２３】
ステップS23では、まず、統合する2つの電話帳各々から、全ての値が抽出される。例えば、上記の例の場合、移行元の電話帳のユーザAについて、「ユーザA」、「男」、「111−111−1111」、「444−444−4444」、「AAA＠AAA．com」、「CCC＠CCC．com」及び「1983．11．23」を表す値が抽出される。移行先の電話帳のユーザPについて、「ユーザP」、「男」、「111−111−1111」、「444−444−4444」、「1983．11．23」、「helloworld」及び「mxworld」を表す値が抽出される。ユーザA、Pだけでなく、電話帳に含まれている全ての値が抽出される。
【００２４】
図4は、2つの電話帳各々から値が抽出された様子を一覧表として示す。移行元の電話帳は、ユーザA、B、C、Dの個人情報を含み、移行先の電話帳はユーザP、Q、R、Sの個人情報を含むものとする。サービス提供サーバ30は、統合する2つの電話帳各々から値を抽出し、値を有するか否かの観点から、ユーザ毎に特徴ベクトルを生成する。特徴ベクトルの成分は、特定の値を有する成分の有無を表す。
【００２５】
例えば、移行元のユーザAの場合、「男」、「111−111−111」、「444−444−4444」、「AAA＠AAA．com」、「CCC＠CCC．com」、「1983．11．23」を表現する値を有するので、ユーザAの特徴ベクトルは、次のように表現できる：
（1，0，1，0，1，0，1，0，1，1，0，0，0，0）。
【００２６】
ユーザBの場合、「男」、「111−111−111」、「333−333−3333」を表現する値を有するので、ユーザBの特徴ベクトルは、次のように表現できる：
（1，0，1，1，0，0，0，0，0，0，0，0，0，0）。
【００２７】
ユーザCの場合、「女」、「111−111−111」、「BBB＠BBB．com」、「CCC＠CCC．com」、「1985．12．25」、「PATENT」を表現する値を有するので、ユーザCの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，0，0，1，1，0，1，0，0，1）。
【００２８】
ユーザDの場合、「男」、「111−111−111」を表現する値を有するので、ユーザDの特徴ベクトルは、次のように表現できる：
（1，0，1，0，0，0，0，0，0，0，0，0，0，0）。
【００２９】
ユーザPの場合、「男」、「111−111−111」、「444−444−4444」、「1983．11．23」、「helloworld」、「mxworld」を表現する値を有するので、ユーザPの特徴ベクトルは、次のように表現できる：
（1，0，1，0，1，0，0，0，0，1，0，1，1，0）。
【００３０】
ユーザQの場合、「女」、「111−111−111」、「777−777−7777」、「CCC＠CCC．com」、「helloword」を表現する値を有するので、ユーザQの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，1，0，0，1，0，0，1，0，0）。
【００３１】
ユーザRの場合、「男」、「111−111−111」、「PATENT」を表現する値を有するので、ユーザRの特徴ベクトルは、次のように表現できる：
（1，0，1，0，0，0，0，0，0，0，0，0，0，1）。
【００３２】
ユーザSの場合、「女」、「111−111−111」、「BBB＠BBB．com」、「CCC＠CCC．com」、「1985．12．25」、「mxworld」を表現する値を有するので、ユーザSの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，0，0，1，1，0，1，0，1，0）。
【００３３】
このようにして、各ユーザの特徴ベクトルが生成される。なお、説明の便宜上、特徴ベクトルが行ベクトルであるように説明されたが、このことは本実施例に必須ではなく、特徴ベクトルは列ベクトルとして定義されてもよい。
【００３４】
図2のステップS25において、サービス提供サーバ30は、特徴ベクトル同士の類似度を算出することで、ユーザ同士の異同を判別する。概して、特徴ベクトルの類似度は、特徴ベクトル同士の内積を算出することで決定されてもよい。内積に限らず、当該技術分野において既知の適切な如何なる方法が使用されてもよい。特徴ベクトル同士の内積を計算する前に、ウェイト又は重み係数が導入される。以下の計算例において、ウェイトは、同じ値の属性が出現した回数の逆数として定義されるが、別の定義が使用されてもよい。ウェイトは、図4の表において「ウェイト」の列に示されている。ユーザA−D、P−Sの8つのユーザの個人情報において、「性別」という属性が、「男」の値を有する個人情報の数は5であり、多数存在する。「電話番号」の属性として「111−111−1111」の値を有する個人情報の数は、8つであり、全ての個人情報に含まれている。このように電話帳の中で何回も出現する値は、特徴ベクトル同士の内積により類似度を算出する際、高い類似度に対応するとは限らない。例えば、同じ会社に属する5人の男性が同じ会社電話番号を有する場合、「男性」及び「会社電話番号」が一致したからといって、これらの5人の個人情報が同一人物を表すとは限らない。むしろ、出現回数が多い属性の値は、ユーザ同士の異同を判定する際には低く（小さく）考慮されるべきである。このような観点から、同じ値が複数回出現した場合には、出現回数の逆数のウェイトが導入される。
【００３５】
具体的には、次のようにして、ユーザx、yの類似度sim（x，y）が算出される。
【００３６】
sim（A，P）＝（1，0，1，0，1，0，1，0，1，1，0，0，0，0）・（W×（1，0，1，0，1，0，0，0，0，1，0，1，1，0）T）
＝1／5＋1／8＋1／2＋1／2＝1．325
ただし、上付き文字の「T」は転置を表す。Wは、以下のウェイトの値を対角成分とする正方行列である：
1／5、1／3、1／8、0、1／2、0、0、1／2、1／4、1／2、1／2、1／2、1／2、1／2。
なお、上記の計算式の場合、対角行列WをユーザPの特徴ベクトルにのみ乗算しているが、このことは本実施例に必須ではない。例えば、ユーザAの特徴ベクトルのみに対角行列が乗算されてもよい。さらには、W＝w×w＝w2を満たす正方行列wが定義され、ユーザA、Pの特徴ベクトル双方に、正方行列wがそれぞれ乗算された後に、内積が計算されてもよい。一例として、行列wは、ウェイトの平方根を対角成分とする行列により表現されてもよい。
【００３７】
sim（A，P）＝（w×（1，0，1，0，1，0，1，0，1，1，0，0，0，0））・（w×（1，0，1，0，1，0，0，0，0，1，0，1，1，0）T）
このような数学的な技法は本実施例に必須ではなく、当該技術分野における適切な如何なる方法が使用されてもよい。
【００３８】
同様な計算を行うことで、ユーザAとユーザQ、R、Sの類似度は、次のように算出される。
【００３９】
sim（A，Q）＝0．375
sim（A，R）＝0．325
sim（A，S）＝0．375
ユーザBとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４０】
sim（B，P）＝0．325
sim（B，Q）＝0．125
sim（B，R）＝0．325
sim（B，S）＝0．125
ユーザCとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４１】
sim（C，P）＝0．125
sim（C，Q）＝0．708
sim（C，R）＝0．125
sim（C，S）＝1．708
ユーザDとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４２】
sim（D，P）＝0．325
sim（D，Q）＝0．125
sim（D，R）＝0．325
sim（D，S）＝0．125
サービス提供サーバ30は、特徴ベクトル同士の内積が所定の閾値を超えるか否かに基づいて、ユーザ同士の異同を判定する。一例として、閾値が1．0であったとすると、sim（A，P）＝1．325＞1であり、ユーザAとユーザPは同一ユーザであると判断できる。同様に、sim（C，S）＝1．708＞1であるので、ユーザCとユーザSも同一ユーザであると判断できる。閾値は、目的に応じて任意に設定できる。例えば、閾値を1．5に設定してもよい。この場合、ユーザAとPは別ユーザとして判断され、ユーザCとSのみが同一であると判断される。
【００４３】
図2のステップS27において、サービス提供サーバ30は、ユーザ同士の異同の判定結果に基づいて、2つの電話帳を1つに統合する。まず、移動元の電話帳のユーザの内、移動先の何れのユーザとも同一と判定されなかったユーザの個人情報は、移動先の電話帳にそのままコピーされる。移動元の電話帳のユーザの内、移動先の何れかのユーザと同一であると判定されたユーザの場合、個人情報の差分の情報が、移動元から移動先の電話帳にコピーされる。これにより、2つの電話帳のデータが過不足無く併合された1つの電話帳のデータが生成される。この場合において、同一であると判断されたユーザが誰であるかは、ステップS25において判定されたユーザに加えて、プライマリ属性（携帯電話番号、メールアドレス及び姓名）が完全に一致したユーザである。図5は、同一であると判断されたユーザA、Pの個人情報が、1つに統合された様子を示す。図示されてはいないが、同一であると判断された他のユーザC、Sの個人情報も、1つに統合される。
【００４４】
図2のステップS29において、サービス提供サーバ30は、1つに統合された電話帳のデータを移行先の通信端末10に送信する。移行先の通信端末10は、電話帳を受信したデータにより更新又は置換することで、統合された電話帳のデータを得ることができる。
【００４５】
なお、ステップS25における異同判別の対象となるユーザは、プライマリ属性（携帯電話番号、メールアドレス及び姓名）が完全一致していないユーザであった。しかしながら、このことは本実施例に必須ではなく、プライマリ属性による判別行わずに、全てのユーザについてステップS25によるユーザの異同判別が行われてもよい。ただし、プライマリ属性により、明らかに同一であるユーザを選別し、残りのユーザについて本実施例による異同判別を行うことは、演算負担の軽減及び効率化等の観点から好ましい。
【００４６】
＜3．通信端末＞
図6は、本実施例において使用可能な通信端末10の機能ブロック図を示す。図6には、通信端末に備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図示の通信端末は、図1に示されている通信端末10として使用可能であり、図2に示す動作をすることが可能である。通信端末10は、通信網20を介して情報を通信することが可能な適切な如何なる通信端末でもよく、通信端末は、典型的には移動端末であるが、固定端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるがこれらに限定されない。図6には、通信部61及び記憶部63が示されている。
【００４７】
通信部61は、通信端末10が信号を送受信する機能を発揮するための処理部である。通信部61が送信する信号は、電話帳の情報、通信端末の利用履歴情報、電話帳の統合サービスを希望する意思表示の情報等を含む。通信部61が受信する信号は、統合された電話帳のデータ等を含む。
【００４８】
記憶部63は、電話帳の情報、通信端末の利用履歴情報等を記憶、保存及び管理する。電話帳の情報は、ユーザが通信端末に登録している連絡先ユーザの個人情報が含まれている。個人情報は、連絡先ユーザの氏名、名称（会社名、組織名等）、ニックネーム、電話番号（自宅電話番号、会社電話番号等）、メールアドレス（キャリアメール、PCメール等のメールのアドレス）、ソーシャルネットワークサービス（SNS）のアカウント、住所、誕生日、説明文等であるが、これらに限定されない。利用履歴情報は、ユーザによる通信端末の操作履歴、発信履歴、着信履歴、アプリケーションの起動及び削除の履歴、情報の発信履歴（投稿等を含む。）、情報の受信履歴等であるが、これらに限定されない。
【００４９】
＜4．サービス提供サーバ＞
図7は、サービス提供サーバの機能ブロック図を示す。図8には、サービス提供サーバに備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図示のサービス提供サーバは、図 1に示されているサービス提供サーバ30として使用可能であり、図2に示すように動作する。図7には、通信部71、記憶部73、電話帳データ統合装置75が示されている。電話帳データ統合装置75は、特徴ベクトル生成部751、異同判別部753及び電話帳統合部755を含む。
【００５０】
通信部71は、サービス提供サーバ30が信号を送受信する機能を発揮するための処理部である。通信部71が受信する信号は、電話帳の情報、通信端末の利用履歴情報、電話帳の統合サービスを希望する意思表示の情報等を含む。通信部71が送信する信号は、統合された電話帳のデータ等を含む。
【００５１】
記憶部73は、様々なユーザから取得した電話帳のデータを記憶、保存及び管理する。本実施例の場合、図2に示すような動作をサービス提供サーバ30に実行させるコンピュータプログラムが、記憶部73に保存されている。
【００５２】
電話帳データ統合装置75は、ユーザからの要請に応じて、複数の電話帳を1つに統合する処理を行う。
【００５３】
特徴ベクトル生成部751は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値（属性の値）を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する。
【００５４】
異同判別部753は、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する。
【００５５】
電話帳統合部755は、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を抽出して統合先の電話帳に追加する。具体的には、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報が、統合先の電話帳に追加されることに加えて、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分も、統合先の電話帳に追加される。
【００５６】
＜5．変形例＞
図2に示す実施例の動作の場合、電話帳を統合する処理は、サービス提供サーバ30が実行していた。しかしながら、本実施例はこのような形態に限定されない。電話帳を統合する処理を、移行先の電話帳を有する通信端末が行ってもよい。
【００５７】
図8は、変形例による動作例を示す。ステップS81において、移行先の電話帳を有する通信端末10は、移行元の通信端末10の電話帳のデータを取得する。移行元の通信端末10の電話帳のデータは、図示のように、移行元の通信端末10から移行先の通信端末10へ直接的に通知されてもよい。あるいは、サービス提供サーバ30のような他の通信ノードから、移行元の通信端末10の電話帳のデータが取得されてもよい。
【００５８】
ステップS83、S85、S87では、図2のステップS23、S25、S27と同様な処理が行われる。ステップS83では、通信端末10は、電話帳のデータから属性値を抽出し、異なる値の属性値全体の数に等しい次元の特徴ベクトルをユーザ毎に生成する。
【００５９】
ステップS85では、特徴ベクトルの類似度を算出することで、ユーザ同士の異同を判別する。
【００６０】
ステップS87では、移行元の電話帳の個人情報の内、移行先の電話帳の個人情報の中に含まれていない情報が、移行先の電話帳に追加される。
【００６１】
本変形例の場合、電話帳の統合作業は、移行先の電話帳を有する通信端末において行われる。このため、サービス提供サーバ30によらず、通信端末10同士の間で処理を行うことができる。
【００６２】
図9は、変形例における通信端末の機能ブロック図を示す。図9は、通信端末10に備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図9の通信端末は、少なくとも図6に示す通信端末10の動作を行う。図示の通信端末は、図8の移行先の通信端末10として使用可能である。図9には、通信部91、記憶部93、電話帳データ統合装置95が示されている。電話帳データ統合装置95は、特徴ベクトル生成部951、異同判別部953及び電話帳統合部955を含む。
【００６３】
通信部91は、通信端末10が信号を送受信する機能を発揮するための処理部である。図6の通信端末とは異なり、通信部91は、移行元の通信端末から、少なくとも電話帳の情報を受信する。
【００６４】
記憶部93は、他の通信端末から受信した電話帳のデータ及び自身の電話帳のデータを記憶、保存及び管理する。本変形例の場合、図8に示すような動作を通信端末10に実行させるコンピュータプログラムが、記憶部93に保存されている。
【００６５】
電話帳データ統合装置95は、ユーザからの要請に応じて、複数の電話帳を1つに統合する処理を行う。
【００６６】
特徴ベクトル生成部951は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値（属性の値）を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する。
【００６７】
異同判別部953は、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する。
【００６８】
電話帳統合部955は、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を抽出して統合先の電話帳に追加する。具体的には、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報が、統合先の電話帳に追加されることに加えて、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分も、統合先の電話帳に追加される。
【００６９】
以上本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、電話帳を統合する必要のある適切な如何なる移動通信システムに適用されてもよい。例えば本発明は、W−CDMA方式のシステム、HSDPA／HSUPA方式のW−CDMAシステム、LTE方式のシステム、LTE−Advanced方式のシステム、IMT−Advanced方式のシステム、WiMAX、Wi−Fi方式のシステム等に適用されてもよい。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。発明の理解を促すため具体的な数式を用いて説明がなされたが、特に断りのない限り、それらの数式は単なる一例に過ぎず適切な如何なる数式が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、読み取り専用メモリ（ROM）、EPROM、EEPROM、レジスタ、ハードディスク（HDD）、リムーバブルディスク、CD−ROM、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【００７０】
61 通信部
63 記憶部
71 通信部
73 記憶部
75 電話帳データ統合装置
751 特徴ベクトル生成部
753 異同判別部
755 電話帳統合部
【技術分野】
【０００１】
本発明は、電話帳データを統合するための装置、方法及びコンピュータプログラムに関連する。
【背景技術】
【０００２】
通信サービスの多様化、通信端末の普及及び高機能化等に伴って、複数の通信端末を所有するユーザが増えつつある。このようなユーザは、例えば、音声による電話通信を行うための標準機と、意見の投稿やアプリケーションの実行等のための情報端末（例えば、スマートフォン等）とを使い分けている。しかしながら、情報端末等がさらに高性能化するにつれて、複数の通信端末を所有する代わりに、所有する通信端末を1台の情報端末で済ませたいという要請もある。このような要請に応じるには、複数の通信端末各々に保存されている電話帳を、1台の情報端末に統合する必要がある。この場合において、一方の通信端末の電話帳を他方の通信端末の電話帳に単にコピーしたにすぎない場合、同一のユーザの情報が電話帳の中で重複して存在することになり、不便である。この点に関し、取り外し可能な外部データベースを通信端末の内部データベースにコピーすることで、同一ユーザについて重複したデータが生成される技術については、例えば特許文献1に記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2004−88542号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の課題は、複数の通信端末各々に保存されている電話帳を、何れかの通信端末の電話帳に統合する際に、同一ユーザのデータが重複して作成されないようにすることである。
【課題を解決するための手段】
【０００５】
一実施例による電話帳データ統合装置は、
統合する複数の電話帳のデータを取得するデータ取得部と、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、
統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部と
を有する電話帳データ統合装置である。
【発明の効果】
【０００６】
一実施例によれば、複数の通信端末各々に保存されている電話帳を、何れかの通信端末の電話帳に統合する際に、同一ユーザのデータが重複して作成されないようにすることができる。
【図面の簡単な説明】
【０００７】
【図１】通信システムの概要を示す図。
【図２】通信端末及びサービス提供サーバ間の動作例を示す図。
【図３】電話帳に保存されている個人情報の一例を示す図。
【図４】2つの電話帳各々から値が抽出された様子を示す図。
【図５】各々の電話帳の個人情報が併合される様子を示す図。
【図６】通信端末の機能ブロック図。
【図７】サービス提供サーバの機能ブロック図。
【図８】変形例における動作例を示す図。
【図９】変形例における通信端末の機能ブロック図。
【発明を実施するための形態】
【０００８】
一実施例による電話帳データ統合装置は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成し、特徴ベクトル同士の類似度に基づいて、ユーザの異同を判別する。ユーザの異同判別結果に基づいて、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を的確に判別でき、その情報を統合先の電話帳に追加することで、複数の電話帳のデータが過不足無く統合される。
【０００９】
以下の観点から実施例を説明する。
【００１０】
1．通信システム
2．動作例
3．通信端末
4．サービス提供サーバ
5．変形例
【実施例１】
【００１１】
＜1．通信システム＞
図1は、実施例で使用される通信システムの概要を示す。通信システムは、通信端末10、通信網20及びサービス提供サーバ30を少なくとも含む。通信端末10は、通信網20を介して情報を通信することが可能な適切な如何なる通信端末でもよい。
【００１２】
通信端末は、典型的には移動端末であるが、固定端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるがこれらに限定されない。
【００１３】
通信網20は、通信端末10とサービス提供サーバ30との間の通信を可能にする適切な如何なる通信網でもよい。通信網20は、典型的には移動通信網を含むが、無線又は有線による適切な如何なる通信網を含んでよい。通信網20は、インターネット網のようなセキュリティは低いが、広範囲にわたって通信をすることが可能なネットワークを含んでもよい。通信網20は、秘密情報を安全に通信することが可能なセキュリティネットワークを含んでもよい。
【００１４】
サービス提供サーバ30は、様々なユーザの通信端末と接続され、様々なユーザの情報を管理し、本実施例による電話帳統合サービスを提供する。電話帳統合サービスの具体的な内容については後述する。ユーザの情報には、電話帳の情報、通信端末の利用履歴情報等が含まれる。電話帳の情報は、ユーザが通信端末に登録している連絡先ユーザの個人情報が含まれている。個人情報は、連絡先ユーザの氏名、名称（会社名、組織名等）、ニックネーム、電話番号（自宅電話番号、会社電話番号等）、メールアドレス（キャリアメール、PCメール等のメールのアドレス）、ソーシャルネットワークサービス（SNS）のアカウント、住所、誕生日、説明文等であるが、これらに限定されない。利用履歴情報は、ユーザによる通信端末の操作履歴、発信履歴、着信履歴、アプリケーションの起動及び削除の履歴、情報の発信履歴（投稿等を含む。）、情報の受信履歴等であるが、これらに限定されない。
【００１５】
＜2．動作例＞
図2は、通信端末10及びサービス提供サーバ30間の動作例を示す。2台の通信端末を有するユーザが、2台各々に保存されている電話帳を、1つの通信端末の電話帳に統合しようとしているものとする。この場合、ユーザが手作業でユーザの異同を判断しながら、2つの電話帳を1つに統合することも技術的には可能である。しかしながら、電話帳に登録しているユーザ数が多い場合、そのような手作業は困難になる。以下に説明する動作例では、通信端末10とネットワークを介して接続されるサービス提供サーバ30が、複数の電話帳を統合する処理を支援する。移行元の通信端末10及び移行先の通信端末10は、典型的には、同一のユーザが所有しているが、異なるユーザが所有していているものであってもよい。
【００１６】
まず、2台の通信端末10を有するユーザが、サービス提供サーバ30に対して、2つの電話帳を統合することを希望する意思表示を行う（図示せず）。その後、移行元の通信端末10及び移行先の通信端末10各々の電話帳のデータが、サービス提供サーバ30に送信される（ステップS21、S22）。
【００１７】
図3は、ステップS21、S22において、各通信端末10からサービス提供サーバ30へ送信される電話帳のデータの内、ユーザA、Pとして登録されているデータを示す。移行元におけるユーザAと移行先におけるユーザPは、異なるユーザかもしれないし、同じユーザであるかもしれない。
【００１８】
移行元及び移行先の何れにおいても、電話帳のデータは、属性と値の組み合わせにより表現される。属性と値により表現される情報は、「情報要素」として言及される。図3に示す情報要素の種類及び数は、単なる一例にすぎず、適切な如何なる情報要素が幾つ設定されてもよい。
【００１９】
移行元の通信端末10の場合、ユーザAのプロフィール（個人情報）は、「姓名」、「性別」、「会社電話番号」、「携帯電話番号」、「メールアドレス1」、「メールアドレス2」及び「誕生日」という属性を有する。これらの属性各々について、値が設定されている。「姓名」には「ユーザA」を表す値が設定されている。「性別」には「男」を表す値が設定されている。「会社電話番号」には「111−111−1111」という電話番号を表す値が設定されている。「携帯電話番号」には「444−444−4444」という電話番号を表す値が設定されている。「メールアドレス1」には「AAA＠AAA．com」というアドレスが設定されている。「メールアドレス2」には「CCC＠CCC．com」というアドレスが設定されている。「誕生日」には「1983．11．23」という日付を表す値が設定されている。
【００２０】
移行先の通信端末10の場合、ユーザPのプロフィール（個人情報）は、「姓名」、「性別」、「会社電話番号」、「携帯電話番号」、「誕生日」、「SNSアカウント1」及び「SNSアカウント2」という属性を有する。これらの属性各々についても値が設定されている。「姓名」には「ユーザP」を表す値が設定されている。「性別」には「男」を表す値が設定されている。「会社電話番号」には「111−111−1111」という電話番号を表す値が設定されている。「携帯電話番号」には「444−444−4444」という電話番号を表す値が設定されている。「誕生日」には「1983．11．23」という日付を表す値が設定されている。「SNSアカウント1」には「helloworld」というソーシャルネットワークサービス（SNS）のためのアカウントを表す値が設定されている。「SNSアカウント2」には「mxworld」というSNSのためのアカウントを表す値が設定されている。
【００２１】
一般に、2つの電話帳各々に登録されているユーザに関し、携帯電話番号、メールアドレス及び姓名が一致していた場合、そのユーザは同一人物であると判断してよい。しかしながら、携帯電話番号、メールアドレス及び姓名の内の1つ以上が一致していなかったとしても、それらのユーザが別人であるとは限らない。説明の便宜上、携帯電話番号、メールアドレス及び姓名の属性を、「プライマリ属性」と言うことにする。
【００２２】
図2のステップS23において、統合すべき2つの電話帳の各ユーザのプライマリ属性の異同を判定することで、同一ユーザと判断されるユーザが選別される。プライマリ属性の内の1つ以上が一致していかなかったとしても、それらのユーザが別人であるとは限らない。そこで、以下に説明する方法により、プライマリ属性が完全に一致していないユーザ同士の異同を判定する。
【００２３】
ステップS23では、まず、統合する2つの電話帳各々から、全ての値が抽出される。例えば、上記の例の場合、移行元の電話帳のユーザAについて、「ユーザA」、「男」、「111−111−1111」、「444−444−4444」、「AAA＠AAA．com」、「CCC＠CCC．com」及び「1983．11．23」を表す値が抽出される。移行先の電話帳のユーザPについて、「ユーザP」、「男」、「111−111−1111」、「444−444−4444」、「1983．11．23」、「helloworld」及び「mxworld」を表す値が抽出される。ユーザA、Pだけでなく、電話帳に含まれている全ての値が抽出される。
【００２４】
図4は、2つの電話帳各々から値が抽出された様子を一覧表として示す。移行元の電話帳は、ユーザA、B、C、Dの個人情報を含み、移行先の電話帳はユーザP、Q、R、Sの個人情報を含むものとする。サービス提供サーバ30は、統合する2つの電話帳各々から値を抽出し、値を有するか否かの観点から、ユーザ毎に特徴ベクトルを生成する。特徴ベクトルの成分は、特定の値を有する成分の有無を表す。
【００２５】
例えば、移行元のユーザAの場合、「男」、「111−111−111」、「444−444−4444」、「AAA＠AAA．com」、「CCC＠CCC．com」、「1983．11．23」を表現する値を有するので、ユーザAの特徴ベクトルは、次のように表現できる：
（1，0，1，0，1，0，1，0，1，1，0，0，0，0）。
【００２６】
ユーザBの場合、「男」、「111−111−111」、「333−333−3333」を表現する値を有するので、ユーザBの特徴ベクトルは、次のように表現できる：
（1，0，1，1，0，0，0，0，0，0，0，0，0，0）。
【００２７】
ユーザCの場合、「女」、「111−111−111」、「BBB＠BBB．com」、「CCC＠CCC．com」、「1985．12．25」、「PATENT」を表現する値を有するので、ユーザCの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，0，0，1，1，0，1，0，0，1）。
【００２８】
ユーザDの場合、「男」、「111−111−111」を表現する値を有するので、ユーザDの特徴ベクトルは、次のように表現できる：
（1，0，1，0，0，0，0，0，0，0，0，0，0，0）。
【００２９】
ユーザPの場合、「男」、「111−111−111」、「444−444−4444」、「1983．11．23」、「helloworld」、「mxworld」を表現する値を有するので、ユーザPの特徴ベクトルは、次のように表現できる：
（1，0，1，0，1，0，0，0，0，1，0，1，1，0）。
【００３０】
ユーザQの場合、「女」、「111−111−111」、「777−777−7777」、「CCC＠CCC．com」、「helloword」を表現する値を有するので、ユーザQの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，1，0，0，1，0，0，1，0，0）。
【００３１】
ユーザRの場合、「男」、「111−111−111」、「PATENT」を表現する値を有するので、ユーザRの特徴ベクトルは、次のように表現できる：
（1，0，1，0，0，0，0，0，0，0，0，0，0，1）。
【００３２】
ユーザSの場合、「女」、「111−111−111」、「BBB＠BBB．com」、「CCC＠CCC．com」、「1985．12．25」、「mxworld」を表現する値を有するので、ユーザSの特徴ベクトルは、次のように表現できる：
（0，1，1，0，0，0，0，1，1，0，1，0，1，0）。
【００３３】
このようにして、各ユーザの特徴ベクトルが生成される。なお、説明の便宜上、特徴ベクトルが行ベクトルであるように説明されたが、このことは本実施例に必須ではなく、特徴ベクトルは列ベクトルとして定義されてもよい。
【００３４】
図2のステップS25において、サービス提供サーバ30は、特徴ベクトル同士の類似度を算出することで、ユーザ同士の異同を判別する。概して、特徴ベクトルの類似度は、特徴ベクトル同士の内積を算出することで決定されてもよい。内積に限らず、当該技術分野において既知の適切な如何なる方法が使用されてもよい。特徴ベクトル同士の内積を計算する前に、ウェイト又は重み係数が導入される。以下の計算例において、ウェイトは、同じ値の属性が出現した回数の逆数として定義されるが、別の定義が使用されてもよい。ウェイトは、図4の表において「ウェイト」の列に示されている。ユーザA−D、P−Sの8つのユーザの個人情報において、「性別」という属性が、「男」の値を有する個人情報の数は5であり、多数存在する。「電話番号」の属性として「111−111−1111」の値を有する個人情報の数は、8つであり、全ての個人情報に含まれている。このように電話帳の中で何回も出現する値は、特徴ベクトル同士の内積により類似度を算出する際、高い類似度に対応するとは限らない。例えば、同じ会社に属する5人の男性が同じ会社電話番号を有する場合、「男性」及び「会社電話番号」が一致したからといって、これらの5人の個人情報が同一人物を表すとは限らない。むしろ、出現回数が多い属性の値は、ユーザ同士の異同を判定する際には低く（小さく）考慮されるべきである。このような観点から、同じ値が複数回出現した場合には、出現回数の逆数のウェイトが導入される。
【００３５】
具体的には、次のようにして、ユーザx、yの類似度sim（x，y）が算出される。
【００３６】
sim（A，P）＝（1，0，1，0，1，0，1，0，1，1，0，0，0，0）・（W×（1，0，1，0，1，0，0，0，0，1，0，1，1，0）T）
＝1／5＋1／8＋1／2＋1／2＝1．325
ただし、上付き文字の「T」は転置を表す。Wは、以下のウェイトの値を対角成分とする正方行列である：
1／5、1／3、1／8、0、1／2、0、0、1／2、1／4、1／2、1／2、1／2、1／2、1／2。
なお、上記の計算式の場合、対角行列WをユーザPの特徴ベクトルにのみ乗算しているが、このことは本実施例に必須ではない。例えば、ユーザAの特徴ベクトルのみに対角行列が乗算されてもよい。さらには、W＝w×w＝w2を満たす正方行列wが定義され、ユーザA、Pの特徴ベクトル双方に、正方行列wがそれぞれ乗算された後に、内積が計算されてもよい。一例として、行列wは、ウェイトの平方根を対角成分とする行列により表現されてもよい。
【００３７】
sim（A，P）＝（w×（1，0，1，0，1，0，1，0，1，1，0，0，0，0））・（w×（1，0，1，0，1，0，0，0，0，1，0，1，1，0）T）
このような数学的な技法は本実施例に必須ではなく、当該技術分野における適切な如何なる方法が使用されてもよい。
【００３８】
同様な計算を行うことで、ユーザAとユーザQ、R、Sの類似度は、次のように算出される。
【００３９】
sim（A，Q）＝0．375
sim（A，R）＝0．325
sim（A，S）＝0．375
ユーザBとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４０】
sim（B，P）＝0．325
sim（B，Q）＝0．125
sim（B，R）＝0．325
sim（B，S）＝0．125
ユーザCとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４１】
sim（C，P）＝0．125
sim（C，Q）＝0．708
sim（C，R）＝0．125
sim（C，S）＝1．708
ユーザDとユーザP、Q、R、Sの類似度は、次のように算出される。
【００４２】
sim（D，P）＝0．325
sim（D，Q）＝0．125
sim（D，R）＝0．325
sim（D，S）＝0．125
サービス提供サーバ30は、特徴ベクトル同士の内積が所定の閾値を超えるか否かに基づいて、ユーザ同士の異同を判定する。一例として、閾値が1．0であったとすると、sim（A，P）＝1．325＞1であり、ユーザAとユーザPは同一ユーザであると判断できる。同様に、sim（C，S）＝1．708＞1であるので、ユーザCとユーザSも同一ユーザであると判断できる。閾値は、目的に応じて任意に設定できる。例えば、閾値を1．5に設定してもよい。この場合、ユーザAとPは別ユーザとして判断され、ユーザCとSのみが同一であると判断される。
【００４３】
図2のステップS27において、サービス提供サーバ30は、ユーザ同士の異同の判定結果に基づいて、2つの電話帳を1つに統合する。まず、移動元の電話帳のユーザの内、移動先の何れのユーザとも同一と判定されなかったユーザの個人情報は、移動先の電話帳にそのままコピーされる。移動元の電話帳のユーザの内、移動先の何れかのユーザと同一であると判定されたユーザの場合、個人情報の差分の情報が、移動元から移動先の電話帳にコピーされる。これにより、2つの電話帳のデータが過不足無く併合された1つの電話帳のデータが生成される。この場合において、同一であると判断されたユーザが誰であるかは、ステップS25において判定されたユーザに加えて、プライマリ属性（携帯電話番号、メールアドレス及び姓名）が完全に一致したユーザである。図5は、同一であると判断されたユーザA、Pの個人情報が、1つに統合された様子を示す。図示されてはいないが、同一であると判断された他のユーザC、Sの個人情報も、1つに統合される。
【００４４】
図2のステップS29において、サービス提供サーバ30は、1つに統合された電話帳のデータを移行先の通信端末10に送信する。移行先の通信端末10は、電話帳を受信したデータにより更新又は置換することで、統合された電話帳のデータを得ることができる。
【００４５】
なお、ステップS25における異同判別の対象となるユーザは、プライマリ属性（携帯電話番号、メールアドレス及び姓名）が完全一致していないユーザであった。しかしながら、このことは本実施例に必須ではなく、プライマリ属性による判別行わずに、全てのユーザについてステップS25によるユーザの異同判別が行われてもよい。ただし、プライマリ属性により、明らかに同一であるユーザを選別し、残りのユーザについて本実施例による異同判別を行うことは、演算負担の軽減及び効率化等の観点から好ましい。
【００４６】
＜3．通信端末＞
図6は、本実施例において使用可能な通信端末10の機能ブロック図を示す。図6には、通信端末に備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図示の通信端末は、図1に示されている通信端末10として使用可能であり、図2に示す動作をすることが可能である。通信端末10は、通信網20を介して情報を通信することが可能な適切な如何なる通信端末でもよく、通信端末は、典型的には移動端末であるが、固定端末でもよい。通信端末は、具体的には、携帯電話、情報端末、スマートフォン、ノート型パーソナルコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等であるがこれらに限定されない。図6には、通信部61及び記憶部63が示されている。
【００４７】
通信部61は、通信端末10が信号を送受信する機能を発揮するための処理部である。通信部61が送信する信号は、電話帳の情報、通信端末の利用履歴情報、電話帳の統合サービスを希望する意思表示の情報等を含む。通信部61が受信する信号は、統合された電話帳のデータ等を含む。
【００４８】
記憶部63は、電話帳の情報、通信端末の利用履歴情報等を記憶、保存及び管理する。電話帳の情報は、ユーザが通信端末に登録している連絡先ユーザの個人情報が含まれている。個人情報は、連絡先ユーザの氏名、名称（会社名、組織名等）、ニックネーム、電話番号（自宅電話番号、会社電話番号等）、メールアドレス（キャリアメール、PCメール等のメールのアドレス）、ソーシャルネットワークサービス（SNS）のアカウント、住所、誕生日、説明文等であるが、これらに限定されない。利用履歴情報は、ユーザによる通信端末の操作履歴、発信履歴、着信履歴、アプリケーションの起動及び削除の履歴、情報の発信履歴（投稿等を含む。）、情報の受信履歴等であるが、これらに限定されない。
【００４９】
＜4．サービス提供サーバ＞
図7は、サービス提供サーバの機能ブロック図を示す。図8には、サービス提供サーバに備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図示のサービス提供サーバは、図 1に示されているサービス提供サーバ30として使用可能であり、図2に示すように動作する。図7には、通信部71、記憶部73、電話帳データ統合装置75が示されている。電話帳データ統合装置75は、特徴ベクトル生成部751、異同判別部753及び電話帳統合部755を含む。
【００５０】
通信部71は、サービス提供サーバ30が信号を送受信する機能を発揮するための処理部である。通信部71が受信する信号は、電話帳の情報、通信端末の利用履歴情報、電話帳の統合サービスを希望する意思表示の情報等を含む。通信部71が送信する信号は、統合された電話帳のデータ等を含む。
【００５１】
記憶部73は、様々なユーザから取得した電話帳のデータを記憶、保存及び管理する。本実施例の場合、図2に示すような動作をサービス提供サーバ30に実行させるコンピュータプログラムが、記憶部73に保存されている。
【００５２】
電話帳データ統合装置75は、ユーザからの要請に応じて、複数の電話帳を1つに統合する処理を行う。
【００５３】
特徴ベクトル生成部751は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値（属性の値）を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する。
【００５４】
異同判別部753は、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する。
【００５５】
電話帳統合部755は、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を抽出して統合先の電話帳に追加する。具体的には、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報が、統合先の電話帳に追加されることに加えて、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分も、統合先の電話帳に追加される。
【００５６】
＜5．変形例＞
図2に示す実施例の動作の場合、電話帳を統合する処理は、サービス提供サーバ30が実行していた。しかしながら、本実施例はこのような形態に限定されない。電話帳を統合する処理を、移行先の電話帳を有する通信端末が行ってもよい。
【００５７】
図8は、変形例による動作例を示す。ステップS81において、移行先の電話帳を有する通信端末10は、移行元の通信端末10の電話帳のデータを取得する。移行元の通信端末10の電話帳のデータは、図示のように、移行元の通信端末10から移行先の通信端末10へ直接的に通知されてもよい。あるいは、サービス提供サーバ30のような他の通信ノードから、移行元の通信端末10の電話帳のデータが取得されてもよい。
【００５８】
ステップS83、S85、S87では、図2のステップS23、S25、S27と同様な処理が行われる。ステップS83では、通信端末10は、電話帳のデータから属性値を抽出し、異なる値の属性値全体の数に等しい次元の特徴ベクトルをユーザ毎に生成する。
【００５９】
ステップS85では、特徴ベクトルの類似度を算出することで、ユーザ同士の異同を判別する。
【００６０】
ステップS87では、移行元の電話帳の個人情報の内、移行先の電話帳の個人情報の中に含まれていない情報が、移行先の電話帳に追加される。
【００６１】
本変形例の場合、電話帳の統合作業は、移行先の電話帳を有する通信端末において行われる。このため、サービス提供サーバ30によらず、通信端末10同士の間で処理を行うことができる。
【００６２】
図9は、変形例における通信端末の機能ブロック図を示す。図9は、通信端末10に備わる様々な機能要素又は処理部の内、本実施例に特に関連するものが示されている。図9の通信端末は、少なくとも図6に示す通信端末10の動作を行う。図示の通信端末は、図8の移行先の通信端末10として使用可能である。図9には、通信部91、記憶部93、電話帳データ統合装置95が示されている。電話帳データ統合装置95は、特徴ベクトル生成部951、異同判別部953及び電話帳統合部955を含む。
【００６３】
通信部91は、通信端末10が信号を送受信する機能を発揮するための処理部である。図6の通信端末とは異なり、通信部91は、移行元の通信端末から、少なくとも電話帳の情報を受信する。
【００６４】
記憶部93は、他の通信端末から受信した電話帳のデータ及び自身の電話帳のデータを記憶、保存及び管理する。本変形例の場合、図8に示すような動作を通信端末10に実行させるコンピュータプログラムが、記憶部93に保存されている。
【００６５】
電話帳データ統合装置95は、ユーザからの要請に応じて、複数の電話帳を1つに統合する処理を行う。
【００６６】
特徴ベクトル生成部951は、複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値（属性の値）を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する。
【００６７】
異同判別部953は、特徴ベクトル同士の類似度に基づいて、複数の電話帳各々に含まれているユーザの異同を判別する。
【００６８】
電話帳統合部955は、統合元の電話帳の個人情報の内、統合先の電話帳に存在しない情報を抽出して統合先の電話帳に追加する。具体的には、統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報が、統合先の電話帳に追加されることに加えて、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分も、統合先の電話帳に追加される。
【００６９】
以上本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、電話帳を統合する必要のある適切な如何なる移動通信システムに適用されてもよい。例えば本発明は、W−CDMA方式のシステム、HSDPA／HSUPA方式のW−CDMAシステム、LTE方式のシステム、LTE−Advanced方式のシステム、IMT−Advanced方式のシステム、WiMAX、Wi−Fi方式のシステム等に適用されてもよい。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。発明の理解を促すため具体的な数式を用いて説明がなされたが、特に断りのない限り、それらの数式は単なる一例に過ぎず適切な如何なる数式が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、読み取り専用メモリ（ROM）、EPROM、EEPROM、レジスタ、ハードディスク（HDD）、リムーバブルディスク、CD−ROM、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【００７０】
61 通信部
63 記憶部
71 通信部
73 記憶部
75 電話帳データ統合装置
751 特徴ベクトル生成部
753 異同判別部
755 電話帳統合部
【特許請求の範囲】
【請求項１】
統合する複数の電話帳のデータを取得するデータ取得部と、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、
統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部と
を有する電話帳データ統合装置。
【請求項２】
ユーザ名、電話番号及びメールアドレスを表す個人情報の情報要素各々が、完全に一致しない複数のユーザについて、前記異同判別部がユーザの異同を判別する、請求項1記載の電話帳データ統合装置。
【請求項３】
統合元又は統合先の電話帳に属するユーザ各々の特徴ベクトルの複数の成分各々は、該ユーザの個人情報が該成分に対応する情報要素を有するか否かを表すとともに、特定の情報要素について同じ値が出現した頻度により重み付けされている、請求項1又は2に記載の電話帳データ統合装置。
【請求項４】
前記異同判別部は、前記特徴ベクトル同士の内積が所定値を超えるか否かに基づいて、前記特徴ベクトル同士の類似度を判定する、請求項1−3の何れか1項に記載の電話帳データ統合装置。
【請求項５】
当該電話帳データ統合装置が、複数の通信端末と通信するサービス提供サーバに設けられている、請求項1−4の何れか1項に記載の電話帳データ統合装置。
【請求項６】
前記サービス提供装置が、前記電話帳統合部により統合された電話帳のデータを、統合先の電話帳を有する通信端末に送信する送信部を有する、請求項5記載の電話帳データ統合装置。
【請求項７】
当該電話帳データ統合装置が、ユーザの通信端末に設けられている、請求項1−4の何れか1項に記載の電話帳データ統合装置。
【請求項８】
統合する複数の電話帳のデータを通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップ
を有する電話帳データ統合方法。
【請求項９】
統合する複数の電話帳のデータを複数の通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップを、
前記通信端末と通信するサービス提供サーバに実行させるコンピュータプログラム。
【請求項１０】
統合する複数の電話帳のデータを通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップを、
前記通信端末と通信可能な他の通信端末に実行させるコンピュータプログラム。
【請求項１】
統合する複数の電話帳のデータを取得するデータ取得部と、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルを、ユーザ毎に生成する特徴ベクトル生成部と、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別する異同判別部と、
統合元の電話帳の個人情報の内、統合先の電話帳のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合する電話帳統合部と
を有する電話帳データ統合装置。
【請求項２】
ユーザ名、電話番号及びメールアドレスを表す個人情報の情報要素各々が、完全に一致しない複数のユーザについて、前記異同判別部がユーザの異同を判別する、請求項1記載の電話帳データ統合装置。
【請求項３】
統合元又は統合先の電話帳に属するユーザ各々の特徴ベクトルの複数の成分各々は、該ユーザの個人情報が該成分に対応する情報要素を有するか否かを表すとともに、特定の情報要素について同じ値が出現した頻度により重み付けされている、請求項1又は2に記載の電話帳データ統合装置。
【請求項４】
前記異同判別部は、前記特徴ベクトル同士の内積が所定値を超えるか否かに基づいて、前記特徴ベクトル同士の類似度を判定する、請求項1−3の何れか1項に記載の電話帳データ統合装置。
【請求項５】
当該電話帳データ統合装置が、複数の通信端末と通信するサービス提供サーバに設けられている、請求項1−4の何れか1項に記載の電話帳データ統合装置。
【請求項６】
前記サービス提供装置が、前記電話帳統合部により統合された電話帳のデータを、統合先の電話帳を有する通信端末に送信する送信部を有する、請求項5記載の電話帳データ統合装置。
【請求項７】
当該電話帳データ統合装置が、ユーザの通信端末に設けられている、請求項1−4の何れか1項に記載の電話帳データ統合装置。
【請求項８】
統合する複数の電話帳のデータを通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップ
を有する電話帳データ統合方法。
【請求項９】
統合する複数の電話帳のデータを複数の通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップを、
前記通信端末と通信するサービス提供サーバに実行させるコンピュータプログラム。
【請求項１０】
統合する複数の電話帳のデータを通信端末から取得し、
前記複数の電話帳に含まれている複数のユーザの個人情報各々から、個人情報を構成する複数の情報要素の値を抽出し、互いに異なる値の情報要素全体の数に等しい次元の特徴ベクトルをユーザ毎に生成し、
前記特徴ベクトル同士の類似度に基づいて、前記複数の電話帳各々に含まれているユーザの異同を判別し、
統合元の電話帳内の個人情報の内、統合先の電話帳内のユーザと異なるユーザの個人情報と、統合元及び統合先の電話帳双方に含まれる同一ユーザの個人情報の差分とを、統合先の電話帳に追加することで、電話帳を統合するステップを、
前記通信端末と通信可能な他の通信端末に実行させるコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１２００４１（Ｐ２０１２−１２００４１Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６９６０６（Ｐ２０１０−２６９６０６）
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]