データをクラスタリングする方法、システム、装置およびその方法を適用するためのコンピュータ・プログラム
【課題】データ・クラスタおよび同義語の発見および修正のための方法およびシステムを提供する。
【解決手段】本発明の一つの側面は、データをクラスタリングする方法が、システム上で情報を受け取るステップを含み、その情報は前記システムによりアクセス可能なデータベースにストアされもしくはストアされるべき１個もしくは複数個のデータ属性を操作し、その情報および操作がデータ・クラスタに明示的に関連しない。データ・クラスタはその受け取った情報に基づいて自動的に調整され、そのデータ・クラスタは複数個のデータ属性を含み、その受け取った情報により操作される少なくとも１個のデータ属性を含む。そのデータ・クラスタは動的に調整され、受け取っている情報に応答する。
【解決手段】本発明の一つの側面は、データをクラスタリングする方法が、システム上で情報を受け取るステップを含み、その情報は前記システムによりアクセス可能なデータベースにストアされもしくはストアされるべき１個もしくは複数個のデータ属性を操作し、その情報および操作がデータ・クラスタに明示的に関連しない。データ・クラスタはその受け取った情報に基づいて自動的に調整され、そのデータ・クラスタは複数個のデータ属性を含み、その受け取った情報により操作される少なくとも１個のデータ属性を含む。そのデータ・クラスタは動的に調整され、受け取っている情報に応答する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータ・システムにおけるデータ・クラスタリングに関し、特に同義語のようなデータ・クラスタの発見および修正に関する。
【背景技術】
【０００２】
データ・マイニングはデータベースにおけるデータなど、データから潜在的に使用可能な情報を引き出すことを含む。データのクラスタリングがデータ・マイニングではしばしば使用される。それは、データまたは属性を異なるグループにクラス分けすることであり、すなわち各クラスタ中のデータが共通の形質(特性trait)を共有するようにクラスタ中にデータをグループ分けすることである。例えば、データのクラスタは検索がもっと効果的に実行されるのを許容する。何故ならばクラスタが各々の個別の属性の代わりに検索されることができ、かくして検索動作の回数を減少させるからである。
【０００３】
幾つかのコンピューティング・システムでは、あるデータ・クラスタを「同義語 (synonyms)」と呼ぶことができる。ここでいう同義語は検索目的または類似の機能からは全て同じと考えられる多数の異なるデータ・アイテムを含むことができる。この同義語は、任意の関連付けられるデータ・アイテムが見つかるときに仮想される同義語のデフォルト（省略時）値である「基本形（root form）」をもつことができる。同義語は入力事項に正確には一致はしていないかもしれないデータを検索して見つけ出すのに有用となり得る。例えば、人の特定の名前を検索すると、その名前と正確に一致したものが見つかるはずである。そして、その名前の同義語はその名前の変形を含むことができ、これもまたその同じ人に関係するデータを見つけ出すために検索されることができる。
【０００４】
コンピューティング・システムにおいて同義語を用いる一つの標準的な方法は、語（word）またはその語幹（root）に関連付けられかつ同じ意味を有するものとして全て取り扱われるデータ属性（同義語）のクラスタに各々の基本形の語がマップされたものをリストしているルックアップ・テーブルである同義語テーブルを提供することである。典型的には、同じ意味を持つ既知の同義語は、予め決定されまたは予め計算され、後で使用するために同義語テーブルにストアされる。入力語を受け取ると、その入力語をその同義語テーブル中で探し出すことによって、一致する同義語または属性が見出され、これが基本形の語または同義語識別子を提供する。
【０００５】
従来の同義語を使用する場合の一つの欠点は予め計算するのが難しいか自明でないかその両方であるデータのための同義語が存在することである。例えば、Ｒｏｂｅｒｔという名前（基本語 root word）の同義語はＢｏｂ、Ｂｏｂｂｉｅ、Ｂｏｂｂｙ、Ｄｏｂｂ、Ｒａｂ、Ｒａｂｂｉｅ、Ｒｏｂｂｉｅ、Ｒｏｂｂｙ、Ｒｏｂ、Ｒｏｂａｒｄ、Ｒａｉｂｅａｒｔ、Ｌｏｐａｋａ、およびＬｏｐｅｔｉであってよく、これらの変形例の全てが見つかっているわけでも予め決定されるわけでもない。更に、同義語または他のタイプのデータ・クラスタの形成および更新は全ての所望のデータが入力された後の別の時間に、またはクエリのときに典型的には行われる。これはその処理中に行われるクエリを非常に遅くすることがあり、また更新が行われる前に同義語が不正確またはドリフト（不完全）とされるのを潜在的に許容してしまう。
【０００６】
更に、同義語に対し語幹（root）をマッピングするルックアップ・テーブルは同義語の正確かつ完全なリストがそのタイプに対し見出されるように同義語のタイプの領域の知識を必要とする。例えば、言語領域の知識および技法が名前または語に対する同義語を正確に見出すのに使用されるが、他の領域の知識も数値など、他のタイプの同義語を決定するのに使用される必要がある。更に、ある語幹に対する全ての同義語のストレージは多量のストレージをとることができる。何故ならば各語幹の全ての既知の同義語は、これらの同義語がこれまで使用され、ストアされ、またはそのシステムにより検索されたかどうかに拘わらず、ストアされるからである。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、必要なものは、例えば同義語を迅速に更新することができ、データの正確さにおけるドリフトを防止することのできるような、そしてシステムによる使用時に同義語および属性のために必要なストレージを必要とするだけ、および／もしくはデータの特定の領域の知識を必要としないデータ・クラスタ（同義語など）を形成し修正するための改良された方法および装置である。本発明はそのようなニーズに取り組むものである。
【課題を解決するための手段】
【０００８】
本出願の発明は同義語などのデータ・クラスタの発見および修正に関する。本発明の一つの側面は、データをクラスタリングする方法が、システム上で情報を受け取るステップを含み、その情報は前記システムによりアクセス可能なデータベースにストアされもしくはストアされるべき１個もしくは複数個のデータ属性を操作し、その情報および操作がデータ・クラスタに明示的に関連しない。データ・クラスタはその受け取った情報に基づいて自動的に調整され、そのデータ・クラスタは複数個のデータ属性を含み、その受け取った情報により操作される少なくとも１個のデータ属性を含む。そのデータ・クラスタは動的に調整され、受け取っている情報に応答する。コンピュータ可読媒体およびシステムが似たような特徴を含む。
【０００９】
本発明の他の側面では、データをクラスタリングする方法がシステム上で情報を受け取るステップを含み、その情報は、そのシステムによりアクセス可能なデータベース中の少なくとも１個のデータ・エンティティにおいてストアされるべき複数個の受け取ったデータ属性を含む。１個もしくは複数個のデータ・クラスタがその受け取った情報に基づき修正され、その１個もしくは複数個のデータ・クラスタの各々が複数個のデータ属性を含むとともに、その受け取ったデータ属性を少なくとも１個含み、そしてその修正はその１個もしくは複数個のデータ・クラスタから特定のデータ属性を除去することを含む。
【００１０】
本発明の他の側面では、同義語を発見する方法がシステム上で情報を受け取るステップを含み、その情報はデータベースにデータ属性をストアさせる特定のデータ・エンティティに関連付けられる複数の受け取ったデータ属性を含む。その受け取ったデータ属性はそのデータベースにストアされる１個もしくは複数個のデータ・エンティティにストアされる筈であり、そのデータベースではその情報およびデータ属性が同義語を明示的に関連させない。同義語はその受け取ったデータ属性に基づいて、ならびに現在ストアされているデータに基づいて自動的に形成される。その形成には、少なくとも１個の閾値属性を含む複数個の候補のデータ・エンティティをデータベースにおいて調べることを含み、その同義語は動的にそして受け取った情報に応答して形成される。
【００１１】
本発明による実施例は動的なデータ・クラスタおよび同義語の発見を提供することができ、また修正も提供することができるが、その修正は非同義語関連の入力データを受け取るときに同義語が調整されるのを許容する。これはデータのドリフトを招来することなくリアルタイムで行われる更新および高速のクラスタリングを許容する。更特定の領域の知識を必要とすることなく同義語を発見することができ、異なるタイプのデータ特性を含むことができ、ストレージのコストを減じることができる。何故ならばシステムにより使用されるこれらの属性の入力のみが同義語に含まれる必要があるからである。
【００１２】
ここで本発明を、単なる例示であるが、以下の図面で説明するようにその好適な実施例に従って説明する。
【図面の簡単な説明】
【００１３】
【図１】本発明とともに使用されるのに適当な例示のシステムのブロック図である。
【図２】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図３】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図４】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図５】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図６】本発明の同義語の処理のための方法の実施例を示すフローチャートである。
【図７】着信情報にもとづき属性が除去される図６のステップを実装するための方法の実施例を示すフローチャートである。
【図８】同義語が発見され、その同義語テーブルおよび候補に加えられる図６のステップの実施例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
本発明はコンピュータ・システムにおけるデータ・クラスタリングに関し、特に同義語のようなデータ・クラスタの発見および修正に関する。以下の説明は本発明を当業者が製造し、使用することができるように提供され、一つの特許出願の内容およびその要求に合わせて提供される。好適な実施例に対する種々の変形、およびここで記述する汎用的な原理および特徴が当業者には容易に理解できよう。従って、本発明は図示された実施例に限定する意図はなく、ここで開示する原理および特徴に矛盾しない最大の範囲に与えられるべきである。
【００１５】
本発明が特定の実装例で提供される特定のシステムに従って主として記述されている。しかし当業者がこの方法およびシステムが他の実装例において効果的に動作するであろうことは容易に理解されよう。例えば、本発明とともに使用可能なシステムの実装例が多数の異なる形式をとることができる。本発明はまた幾つかのステップを有する特定の方法の脈絡で記述される。しかし本発明と矛盾しない異なるステップおよび／もしくは追加のステップを有する他の方法に対しても効果的に動作する。
【００１６】
本発明の実施例が完全にハードウエアの実施例、完全にソフトウエアの実施例、あるいはハードウエアおよびソフトウエアの両要素を含む実施例といった形態を含むことができる。ソフトウエアの実施例は、以下に限定されるものではないが、ファームウエア、常駐ソフトウエア、マイクロコードなどを含むことができる。更に、本発明の実施例はコンピュータまたは任意の命令実行システムによりあるいはそれと関連して使用されるためにコンピュータ可読媒体によりストアされたプログラム命令またはコードの形態をとることができる。その媒体は、電子的、磁気的、光学的、電磁的、赤外線の、もしくは半導体のシステム（または装置、デバイス）或いは伝送媒体であってよい。コンピュータ可読媒体の例は半導体もしくは固体素子のメモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、磁気ハード・ディスクおよび光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）を含む。
【００１７】
本発明の特徴を一層具体的に説明するために図１ないし図８を以下の説明とともに参照されたい。
【００１８】
本発明による方法およびシステムは、新しいデータ・クラスタを形成すること、現在あるデータ・クラスタを修正することを含む、データのセットのためのデータ・クラスタを調整することを指向する。そのデータ・クラスタはここで「同義語」と呼ばれる。ここで「同義語」という用語は、クラスタ、グループまたは２以上の属性の関連付け（association）をいう。但し、これらの属性はシステム１０によりストアされたデータ・レコード、集合または「エンティティ」において一緒に十分に共通の生成もしくは見かけに基づくその同義語において互いにグループ化されてきている。例えば、データ候補を検索するための個々の属性の代わりに同義語が有利に使用されることができ、かくして検索操作の回数を減らすことができる。
【００１９】
本発明による方法およびシステムはデータの取り入れ時にデータの汎用的なリアルタイムのクラスタリングを提供する。本発明による実施例は幾つかの方法で提供され得る。例えば、データの汎用的なリアルタイム・クラスタリングを提供するシステムが使用され得る。以下の２段階の検索を有するシステムも本発明に従うことができる。即ちその検索の一つの段階は偽の肯定を含む候補一致を得ること、そしてその検索の第２の段階は点数を付け（score）、さもなければ候補を解析してそれらを更に狭めおよび／もしくは所望の候補を確認するという２段階のシステムである。更に、もっと特定のアプリケーションでは、以下のエンティティの認識（recognition）および分解（resolution）のシステムが本発明に従ってあり得る。エンティティが見つかり異なるエンティティ同士が比較されて、どのエンティティが入力属性に関連付けられるかを決定する。候補のエンティティ同士は候補リストを用いて比較され、その候補は点数（スコア）を付けられて所望の一致を確認する。以下の実施例を或るエンティティ分解システムに関連して説明するが、他の実施例の他のタイプのアプリケーションにも適用され得る。
【００２０】
そのようなエンティティ解析システムとともに使用するのに適するシステムの一例は、人または他のエンティティのアイデンティティ（同定）を識別する「Ｒｅｌａｔｉｏｎｓｈｉｐ Ｒｅｓｏｌｕｔｉｏｎ（リレーションシップ・レゾリューション）」および「Ａｎｏｎｙｍｏｕｓ Ｒｅｓｏｌｕｔｉｏｎ（アノニマス・レゾリューション）」を含むＩＢＭコーポレーションからの「Ｅｎｔｉｔｙ Ａｎａｌｙｔｉｃ Ｓｏｌｕｔｉｏｎｓ（ＥＡＳ、エンティティ・アナリティック・ソリューションズ）」である。そのシステムは矛盾した不明瞭なアイデンティティおよび属性の情報を単一解のエンティティ（a single resolved entity）、例えば、ユーザーまたは組織に帰結させ、個人および／もしくはエンティティ間の非自明の関係を検出する、そしてデータセット内の不明瞭さ、スペルミス、または部分的記録を含むファジーな一致性に帰結させる。
【００２１】
図１は本発明とともに使用するのに適する例示のシステム１０のブロック図である。システム１０は１個もしくは複数個のコンピュータ・システム、電子システムもしくはデバイスを用いて実装される。この例のシステム１０は、１個もしくは複数個のマイクロプロセッサと、メモリ（ＲＡＭ、ＲＯＭ、フラッシュ・メモリなど）、ストレージ装置（ハード・ディスク、ＤＶＤ−ＲＯＭおよびＣＤ−ＲＯＭなどの光ディスク）、入力装置（キーボード、ポインティング・デバイス）、出力装置（モニタ、プリンタ）、通信装置およびネットワーク装置を含む種々の周辺装置とを含む周知のシステム・ハードウエア上に実装され得る。図１の例では、データ・ソース・システム１１がデータベース・サーバー１４と通信することができるアプリケーション・サーバー１２にデータを提供することができる。システム１０は、他の実施例で他のタイプのシステムを用いて実装されることもできる。
【００２２】
データ・ソース・システム１１が通信リンク１６を介してアプリケーション・サーバーに情報を提供する。データ・ソース・システム１１はそれ自身が異なるソースからの情報を、ユーザーがデータを入力する、あるいは異なるシステムがネットワークを介してデータを提供するといったようにして受け取ってもよい。ここで言及する例では、その情報が１個もしくは複数個の「エンティティ」または「データ・エンティティ」に関連付けられるデータ属性を含み、そのようなエンティティがデータをグループ化したレコード、集合またはグループであるデータ特性を含む。エンティティは人、組織、オブジェクト、主題、トピックなどをあらわすことができる。エンティティはそれに関連付けられる１個もしくは複数個のデータ属性を有し、幾つかの実施例ではその属性がそのエンティティを記述しまたは説明することができる。エンティティおよびその属性がシステム１０によりストアされ処理される。エンティティはまたそのエンティティに関連付けられるデータの異なるコレクションである１個もしくは複数個の異なる「アカウント（口座）」をもつことができる。
【００２３】
例えば、銀行などの組織は異なる人または顧客のとしてある種のエンティティを指定することができる。但し、各顧客は例えば財産を保持するためのアカウントまたは財産的な状態（小切手のアカウント、ローン・アカウントなど）を指定するためのアカウントなど異なるアカウントを所有することができる。顧客のエンティティに関連付けられる属性は、名前、住所、雇用者、電話番号などそのエンティティのための記述的な情報であり得る。
【００２４】
アプリケーション・サーバー１２がデータ・ソース・システム１１から入ってくる情報を受け取り、アプリケーション・プログラム・サービスおよびその情報のためのインターフェースを、リクエストしている顧客または他のリクエストしている人に提供することができる。アプリケーション・サーバーはそのサーバー上のアプリケーションが、他のサーバー、データベース管理システムなど、他の従属するアプリケーションと通信するのを許容することができる。本発明のここで説明する実施例に関しては、アプリケーション・サーバー１２は本発明に従って１個もしくは複数個の同義語処理アプリケーション２０を提供する。例えば、同義語処理アプリケーション２０はアプリケーション・サーバーに接続された、リクエストしているクライアントのためにランすることができる。複数の同義語処理アプリケーション２０がデータのもっと効果的な処理を提供するために並列にランすることができる。他の実施例では、同義語処理アプリケーション２０がクライアントまたはデータベースのサーバー上でランすることができる。
【００２５】
同義語処理アプリケーション２０が本発明の同義語の発見および他の処理を行うことができる。この処理は新しい同義語が受け取った着信（inbound）情報中に含まれるか調べること、存在する同義語に属性を加えたり削除したりすること、同義語を削除することを含むことができる。この処理はまた同義語および／または類似の属性を有する他の候補のエンティティを見出しそして処理するための候補の処理を含むことができる。これらの機能は図６に関連してあとで詳細に説明する。他の実施例では、同義語アプリケーション機能はそのシステム上の１個もしくは複数個の異なるアプリケーション上に実装されることができる。
【００２６】
データベース・サーバー１４は本発明で使用される情報のためのストレージを提供することができ、ハード・ディスク、磁気テープまたは他の時期ストレージ、ＣＤ、ＤＶＤまたは他の光ストレージといった多様な市販のストレージ装置の内の任意のものを用いて実装され得る。ここに記述された図１の実施例では、データベース・サーバー１４が同義語テーブル３０、１個もしくは複数個の属性テーブル３２、エンティティ同義語テーブル３４、およびエンティティ・アカウント・テーブル３６をストアするデータベース２４へのアクセスを提供する。同義語テーブル３０は、夫々の同義語に同義語識別子のラベルが付けられた多数の同義語をストアする。同義語テーブル３０はその同義語に関連付けられた属性への同義語識別子のマッピングをストアする。属性テーブル３２はシステム１０中のエンティティのデータ属性の全てをストアし、属性のタイプのための情報および関連付けられたアカウントをも含むことができる。エンティティ同義語テーブル３４はそのエンティティへの同義語のマッピングをストアし、そのエンティティでもって同義語が関連付けられる。アカウントを用いる実施例では、エンティティ・アカウント・テーブル３６はそのエンティティへのアカウントのマッピングをストアし、そのエンティティでもってそれらが関連付けられる。これらのテーブルの実例は図２ないし図５に沿って詳細に説明する。
【００２７】
本発明の代替実施例では、データベース２４にストアされたテーブルの幾つかまたは全てが他のストレージ・ロケーション、例えばその同義語処理アプリケーション２０のローカルのストレージなどのところにストアされ、アクセスされる。幾つかの代替実施例では、同義語処理アプリケーション２０がデータベース・サーバー上でランすることができ、またはその同義語が適用するデータセットがその同義語処理アプリケーション２０のローカルのストレージにストアされ得る。
【００２８】
図２ないし図５はデータベース・サーバー（または他のシステム・ストレージもしくはメモリ）にストアされることができ、かつ本発明の同義語処理で使用され得るテーブルの実例の概略図である。図２はエンティティ同義語テーブル３４の例を示す。一つの列では、同義語識別子（ＩＤ）が、異なる同義語を識別するためにストアされる。他の列では、異なるアイデンティティを識別するエンティティ識別子（ＩＤ）がストアされ、そこで識別されるエンティティはそのテーブルの同じ行にリストされた同義語を含む。このテーブルは同義語およびエンティティの追跡を可能にし、いろいろな同義語が更新されるときエンティティが更新されるのを許容する。
【００２９】
図３はエンティティ・アカウント・テーブル３６の例を示す。一つの列で、アカウント識別子はそのシステム上に提供される異なるアカウントを識別するためにストアされる。他の列では、エンティティ識別子はそのテーブルの同じ行のアカウントの関連付けられる特定のエンティティを識別するためにストアされる。エンティティごとに複数個のアカウントを許容する実施例ではそのアカウントをその適切なエンティティに関連付けるようにエンティティ・アカウント・テーブル３６が使用され得る。
【００３０】
図４は本発明により見出される同義語をストアするための同義語テーブル３０の例を示す。同義語テーブル３０では、そのテーブル中の各データ属性が特定の同義語に関連付けられる。同義語テーブル３０は特定の同義語を識別するための同義語識別列４０を含む。属性値列４２はそのテーブルの同じ行にリストされる同義語に関連付けられている属性のための属性値をストアする。属性タイプ列４４は属性を分類わけするように割り当てられるべき属性のタイプを許容する幾つかの実施例に含まれることもできる。その属性タイプはそのシステムのために有用な任意の指定されたタイプであることができ、その属性テーブル３２（以下で説明）で特定される。幾つかの場合には、その属性タイプが、図６に関連して詳細に説明するように、候補を検索するときの同義語処理の際に有用である。（同義語ＩＤにより識別される）同義語テーブル３０で提供される各同義語はそれに関連付けられた２個以上の属性を有し、かくして例示の同義語テーブル３０において少なくとも２行のストレージが必要である。他の実施例では他のテーブル組織が提供され得る。
【００３１】
図５は同義語テーブル３０におけるエンティティに関連付けられるデータ属性をストアするための属性テーブル３２の例を示す。一つの列４６では、属性識別子が各々の個別の属性を識別する。タイプ列４８が属性のタイプを示す。これはもし特定の実施例において属性のタイプが提供されている場合である。例えば、属性テーブル３２は名前、住所、電話番号および雇用者という４つの異なる属性タイプを示す。任意のタイプの属性を指定でき、このことが効率を上げるために検索パラメータを制限するかまたは異なる属性を分類する際の助けとなり得る。幾つかの実施例では、一つの属性もまた明瞭に識別できる異なる属性の一部（sub-portion）となり得る。例えば、郵便番号がそれ自身の属性となり得るし、そして別個の住所属性の一部ともなり得る。
【００３２】
値の列５０が属性の値を示す。ここで「値」もしくは「属性」という用語はいろいろな異なるタイプのデータに言及するのに使用される。例えば、値は数値（整数、実数など）または１個以上の英数字もしくは特定の文字を含むテキスト・ストリングであってよい。その属性をストアするためのその関連付けられたアカウント識別子をアカウント列５２が示す。これは使用される特定の実施例でアカウントが使用される場合である。アカウントを使用していない他の実施例では、属性テーブル３２がアカウント識別子の代わりにアカウント列５２にエンティティ識別子を含むことができる。これは特定の属性を有するエンティティを直接見つけるために使用され得る。
【００３３】
他の実施例では、属性テーブル３２が２以上の別個のテーブルとして実装され得る。例えば、各テーブルは一つのタイプのみのテーブルを含むことができ、その結果名前の属性のためのテーブル、ストリートの住所の属性のための異なるテーブル、Ｅメール・アドレスのための異なるテーブル等がある。
【００３４】
図６は本発明の同義語処理のための方法１００の実施例を示すフローチャートである。ここで開示する方法はハードウエア、ソフトウエアまたはハードウエアおよびソフトウエアの両方の組み合わせであってよい。方法１００は、メモリ、磁気テープ、磁気ディスク、光ディスクなどコンピュータ読み取り可能な媒体上で与えられるプログラム命令を用いて実施されてもよい。ここで説明する方法の処理ステップが唯一の実施例であること、これらのステップが異なる順序でまたは並行して実行され得ること、あるいは他の実施例における異なる方法で組み合わされることに留意されたい。
【００３５】
この方法は１０２で開始し、ステップ１０４で着信情報（ここで「着信（inbound）」と呼ぶ）を受け取る。その着信情報はそのシステムの１個以上のデータ属性を操作する。これはいろいろな異なる形式のいずれかをとることができる。例えば、その着信はデータベース・サーバー１４によりインターフェースされるデータベースの中に、または異なるデータセットまたは他のストレージ（全てここでは「データベース」と呼ぶ）の中にデータを挿入することができる。このように挿入されるデータはここで説明するように、着信中に含まれるデータ属性となり得る。エンティティの分解（resolution）または認識を行う幾つかの実施例では、その着信情報はそのシステムへのデータ属性入力の集合であるレコード、かつシステム１０により認識される１個以上のデータ・エンティティに関連付けられるレコードであり得る。一つの特定の実施例では、その着信というのは銀行のローン部門で顧客（エンティティ）のための新しいアカウントにおいて入力されるべきデータ属性を含むレコードであり得る。ここでそのレコードはその銀行のところでその顧客により申請されたローン・アプリケーションに関連付けられ、そしてまたそのデータ属性が名前、住所、雇用者の電話番号およびその顧客の従業員を含む。
【００３６】
その着信はまたそのシステムの現存するデータ属性を操作することができる。例えば、幾つかの実施例は着信がまた、あるいは代わりの命令が、データベースまたはシステムにストアされる特定のデータ属性が削除されるべきことを（着信情報中のコマンドまたは命令を介して）許容することができる。幾つかの実施例では、その着信が、現存するデータ属性またはクエリを用いるエンティティを見つけるように使用されることができる。その着信は任意の適当なフォーマットであってもよく、例えば一つの実装例ではその着信がＸＭＬフォーマットである。
【００３７】
どんな場合でも、着信が典型的には意図され、そしてデータベースにおいてデータを取り扱う（データ挿入、削除、比較など）ために明示的である。データ・エンティティもしくはレコードのためなど、その操作およびデータは同義語もしくはデータ・クラスタに特にあるいは明示的に関連付けられている必要はない。例えば、その着信情報はそのシステム上で同義語またはデータ・クラスタのことを知る必要さえない。かくして、本発明による実施例は自動的かつ動的な同義語／データ・クラスタの処理および調整をそのような同義語の調整を意図した特定のまたは明示的な入力必要とすることなく、行うことができる。
【００３８】
ステップ１０６では、データ属性がその着信から抽出される。幾つかの実施例では、これらの属性はその関連付けられた着信に関連付けられた一つのエンティティ（または代替例では１個もしくは複数個のそのようなエンティティ）を説明するかまたはそれに関係する。例えば、上述のローン顧客についてのデータを挿入するために着信レコードがその名前、完全な住所、電話番号およびその顧客の雇用者のための別個の属性を有することができる。その完全な住所は属性となり得るか、またはそれとは別に属性もまたその状態およびその住所の郵便番号など、幾つかの実施例で作業アドレスの部分から提供されることができるか、あるいはその両方かである。属性は、一旦抽出されると、システム１０のメモリ中にロードされることができる。
【００３９】
ステップ１０８では、同義語テーブル３０から選択された同義語がその抽出された属性のために見つかる。同義語テーブルがクエリされて、その抽出された属性のいずれかがそのテーブル中の属性値のいずれかと一致するか調べる。そしてもし一致が見つかれば、これらの属性を含むその対応する同義語が選択される。同義語テーブル３０中の各々の同義語は少なくとも２個の属性を有する。属性をタイプに分類する実施例では、着信が各々の抽出された属性に関連付けられたタイプを含むことができ、このタイプが同義語テーブル３０中の属性のタイプに比較されることができて検索量を少なくすることができる。同義語テーブル３０中の各同義語は任意の数の異なるタイプの属性を含むことができる。例えば、抽出された属性のタイプが図４の同義語テーブル３０の属性タイプ列４４にリストされたような属性のタイプに比較されることができる。その結果、その抽出された属性と同じタイプを有する属性値列４２中の対応する属性値のみがその抽出された属性に比較される。同義語の選択は着信中の各々の抽出された属性ごとに反復される。タイプを有しない異なる実施例では、抽出された属性が同義語テーブル３０中の各属性に比較されることができる。他の実施例が１個もしくは複数個の抽出された属性に一致する同義語を選択する他の方法を使用することができる。
【００４０】
ステップ１１０では候補グループもしくはエンティティが同義語テーブル３０からの選択された同義語およびその抽出された属性のセットを用いて発見され選択される。これらの候補エンティティはここでは「候補」というが、これは「着信エンティティ」即ちその着信に関連付けられたエンティティのための潜在的一致である（現在あるエンティティ、またはその着信により生成される新しく生成されるエンティティに加えられるべき着信の情報か始めは知られていないかもしれない、いずれの場合も着信エンティティと呼ばれる）。その選択された同義語は以下のように候補を見つけるのに使用される。ステップ１１０で選択された同義語ごとに、その選択された同義語を共有する全ての候補が選択される。これがここで説明する実施例において行われるのは、選択された同義語識別子に一致する同義語識別子を見つけるためにエンティティ同義語テーブル３４をチェックすることにより、そしてその一致した同義語を有する１個もしくは複数個の関連付けられたエンティティを選択することによってである。これは選択された同義語ごとに反復される。このタイプの検索は、例えば各々の同義語を用いて一致する候補を見つけるのをクエリが許容するのであって、各同義語または着信の中で各属性を用いてクエリを行わなければならないというのではないのではない。
【００４１】
抽出された属性のセットはまたステップ１１０において候補を見つけるのにも使用される。同義語テーブル３０において任意の同義語の一部ではない、その着信から抽出された属性があってもよく、これらの非同義語属性が追加の候補を見つけて選択するのに使用される。例えば、ここで説明する実施例では、各々の非同義語属性値が属性テーブル３２中の属性値に比較され、そして一致する属性値のためのアカウント列５２中のアカウント識別子が図３のエンティティ・アカウント・テーブル３６（または他の適当なテーブル）を用いてこれらの一致する属性を有する候補を見つけるのに使用される。アカウントを有しない他の実施例では、アカウント列５２中のエンティティ識別子がその一致する属性を有する候補エンティティを直接見つけるのに使用され得る。幾つかの実施例では、幾つかの所定のタイプの属性が候補を求めての検索から除外されることができる。
【００４２】
幾つかの実施例がステップ１１２を行ってもよい。そこでは全ての抽出された属性を用い、同義語に属性を含む、ステップ１１０で見つかった全ての候補に対して点数付けされる(score)。属性の点数付け即ちスコアリングは、必要であれば、属性タイプとともに変えてもよい。候補における同義語および属性に基き候補に点数付けするのに、よく知られた任意のスコアリング方法が使用され得る。例えば、既知の類似性スコアリング技法が、異なる値のタイプ（名前、住所、電話番号など）に対して適当であるとして使用され得る。例えば、数値類似性スコアリングは、桁の転置または他の共通のユーザー入力エラーを考慮することができる。幾つかの実施例が同義語を共有しない候補のスコアにペナルティを与えることができる。スコアリングが完了した後、その点数付けされた属性が着信の属性とどれほど近く一致するかが知られ、そのスコアがより正確な候補を提供するのに使用され得る。例えば、候補のリストを所望のもっと小さいリストに狭めることができるか、さもなければ一致と確認される。このスコアは、所望の閾値一致もしくは候補を提供する、候補をマージする（例えば、着信エンティティが或る候補とマージすべきかスコアが決定する）、エンティティをスプリットする（例えば、着信エンティティが１個もしくは複数個のエンティティにスプリットすべきことを着信が明らかにする。何故ならばそのエンティティを構成する（compose）アカウントがマージ可能な一致を最早考えられないからである）、候補相互の関係を生成するなど、システム１０の他の機能で使用されてもよい。幾つかの実施例では、エンティティの実際のマージングおよびスプリッティングは、以下で説明するように同義語の加除に影響を及ぼし得るので、直ぐに行われることができる。
【００４３】
ステップ１１４では、そのプロセスが着信情報および候補情報に基づく同義語からの属性の除去を決定し、実行する。ここで説明する実施例では、その除去は、一般的になっていて、データベースから除去されている属性に基づくか、または同義語形成閾値の下に落ちている候補／属性に基づくか、またはその両方に基づく除去を含む。一般的な属性の検出は、属性が一般的になってしまい、その結果候補を見つけるのに使用されるべきでなく、同義語の部分となるべきでないような多くの異なる候補において、着信から抽出された属性のいずれかが今や生じるかを決定することを含む。１個もしくは複数個の候補またはエンティティからの属性の検出が、例えばシステム１０における１個もしくは複数個の特定の候補またはエンティティを削除するために着信からのまたは他のソースからの直接の命令に基づいて生じるかもしれない。同義語形成閾値の下に属性が落ちるというのは、着信の属性が同義語属性を有する候補のパーセンテージの数値を減じるときに生じることがあり得る。その結果、１個もしくは複数個の属性が現在ある同義語から除去される必要があるかもしれない。同義語からの属性の除去については図７に関して以下で詳細に説明する。
【００４４】
ステップ１１６では、新しい同義語（もしあれば）が発見され、システム１０に加えられる。これは属性が同義語を形成する資格があるかチェックすること、新しい同義語を候補に加えること、および／もしくは現在ある同義語に属性を加えることを含み、そして図８に関して以下で詳細に説明する。
【００４５】
ステップ１１８では、前のステップ１１４および／もしくは１１６で加除された少なくとも１個の同義語をもった候補をそのプロセスが再評価しかつ調整する。加除された同義語を含む全ての候補がシーケンスの中立性を維持するために再評価されるべきである。即ちこれらの候補はそれらの候補を取り込む次の操作のために適切となるようにできるだけ迅速に更新されることができる。ここで説明する実施例では、再評価が、ステップ１０６ないし１１６がそのような候補ごとに行われる分解サイクルを通じてその候補をランすることを取り込む。これは各候補が最近更新された同義語およびその同義語に関連付けられる属性を含むことを許容する。そのプロセスは１２０で完了する。
【００４６】
ここで説明する実施例では、同義語処理アプリケーションが受け取った着信情報に応答してリアルタイムにかつ動的に同義語が前述のように処理される。これはデータの取り入れもしくは受け取り時に同義語および候補が更新されるのを許容し、その同義語および候補に基づく後のクエリを大きくスピードアップすることができる。後のデータ・クラスタリングを行う必要がないからである。
【００４７】
図７は、図６のステップ１１４を実装するための一つの実施例の方法を示すフローチャートであり、そのステップでは着信情報に基づき同義語からの属性の除去を行う。その同義語からの属性の除去というのは、前述のように着信によって引き起こされる複数の異なる結果のうちの任意のものに基づくことができ、一般的になる属性、候補もしくはエンティティから属性の削除、および１個もしくは複数個の同義語における属性の頻度の減少を含む。候補もしくはエンティティからの属性の削除の場合には、データセットからの属性の実際の削除は、本発明のために記述され、ここでは記述しないプロセスの前、最中、もしくはその後に行われることができる。
【００４８】
１５２でそのプロセスが開始し、ステップ１５４で着信中の属性の一つまたは既に削除されたあるいはこれから削除される属性の一つ（もし適用されるなら）が選択される。その選択された属性は少なくとも一つの実在する同義語に含まれる。その選択された属性を含む全ての同義語およびその選択された属性を含む全ての候補は前のステップから知られている。
【００４９】
ステップ１５８では、そのプロセスは属性が一般的になってしまったかチェックする。一般的な属性の削除は、それが一般的になってしまい、従って候補を見つけるのに使用されるべきでない、そして同義語の一部であるべきでないといったような多くの異なる候補においてその選択された属性が生じるか決定することを含む。記述された実施例において、一般的になったものの取り扱いは、その属性を含む（図６のステップ１１０で見つかる候補のセットにおける）候補の数が所定の一般閾値を超えるかチェックすることを含む。もし候補の数がその一般閾値を超えるなら、その選択された属性は一般的になったものと考えられる。一般的な属性を決定するための他の処理あるいは代わりの処理も行うことができる。もしその属性が一般的になったと見出されれば、そのプロセスは、以下で説明するように、その同義語からその属性を除去するためのステップ１６２に続く。
【００５０】
もし属性が一般的でないと決定されるなら、プロセスはステップ１６０に続く。ステップ１６０では、その選択された属性を含む同義語ごとに、そのプロセスは、同義語を有する候補の数がその選択された属性を有する全ての候補の同義語形成閾値パーセントよりも今や少なくなっている（但し、その着信エンティティが候補として含まれる）かチェックする。その閾値パーセントは同義語を形成するのに以前幾つかのポイントで使用されたが、図８の、例えばステップ２０４および２０８において後で詳細に説明する。一実施例では、もしその着信中のその選択された属性が現存する同義語の一部であるがその同義語の全ての属性にその着信の際付随するものでないなら、その同義語におけるそのフル・セットの属性を有する候補のパーセントは減らされているかもしれず、その結果、そのフル・セットの属性は同義語としての資格がなくなる。例えば、もしその着信がその同義語に含まれる３個のうちの始めの２個の属性のみを含むなら、３個の全ての属性を有する同義語を含む候補のパーセントは今や少なくなる。他の実施例では、もしその選択された属性が１個（もしくは複数個）の候補から削除されているなら、これはその同義語を作り上げている属性のセットの候補の数（従ってその発生の数）を減少させているかもしれず、その閾値が最早合致することはない。（着信中の命令により属性のそのような削除が生じる場合には、その属性が削除されたエンティティは着信エンティティと考えることができる。）
【００５１】
もしその同義語閾値を尚も超えているなら、そのプロセスは以下で説明するステップ１６８に続く。もしその発見閾値を超えていなければ、あるいはもしステップ１５８で一般的になってしまうという属性が見つからなかったならば、そのプロセスはステップ１６２に続く。ステップ１６２では、その選択された属性がその関連付けられた同義語から除去される。これは、例えばその選択された属性のエントリおよびタイプを同義語テーブル３０中のその関連付けられた同義語識別子から除去することによって行われる。代わりに、その属性は別の時に１個もしくは複数個の同義語から除去するためにマークされたり、指定されたりする。
【００５２】
ステップ１６４では、ステップ１６２で何らかの属性を除去された各々の同義語がその除去後に唯一の属性を含むかをそのプロセスがチェックする。もしノーであれば、そのプロセスは、以下で説明するステップ１６８に続く。もし或る同義語に唯一の属性が残っているなら、ステップ１６６では例えば同義語テーブル３０からその同義語エンティティおよびその属性を除去することによって、その同義語が完全に除去される。単一の属性のみを有する同義語がその属性を用いての検索に比較して検索の量を少なくはしないので、そのような同義語は必要でなく、除去される。
【００５３】
ステップ１６８では、そのプロセスが前述のステップでまだ調べられていなかった追加の適格な属性があるかそのプロセスはチェックする。もしイエスなら、そのプロセスはステップ１５４に戻り他の属性を選択する。もしそのような全ての属性が処理されてしまうなら、そのプロセスは１７０で完了する。
【００５４】
図８は、図６のステップ１１６を実装するための実施例の方法を説明するフローチャートであり、そのステップで同義語が発見され同義語テーブルおよび候補に加えられる。そのプロセスは２００で開始し、ステップ２０２では図６のステップ１０８において決定されたような１個もしくは複数個の同義語を着信が既に含むかそのプロセスがチェックする。もしそのデータが同義語を含まないなら、そのプロセスはステップ２０４に続き、そのステップでは、考慮中の２個以上の属性のいずれかを含む属性の全ての所定の同義語形成閾値パーセントを超える属性の数においてこれらの２個以上の属性に匹敵する同じ数の属性をその着信が有するかプロセスがチェックする。その比較において使用される候補は、候補として着信エンティティを含む。ここで説明する実施例では、属性相互間の正確な一致をそのプロセスが探し求める。従ってこのステップは、同じ属性のグループもしくはセットが、異なるエンティティにおいても同義語と考えられるほどにしばしば一緒に現れるかチェックする。即ちこれらの属性は多くのエンティティにおいて一緒に現れるという点で共通の関連付けを有する。同義語閾値パーセントはシステムのユーザーまたは管理者により、必要に応じて多めのもしくは少なめの同義語が発見されるのを許容するような好みのレベルに設定されることができる。
【００５５】
例えば、同義語パーセントが７０％であり、かつ図６のステップ１１０において見出される１５個の候補のうちから１０個の候補が、考慮中の２個の特定の属性のうちの１個以上を有する。もしその２個の属性がこれらの１０個の属性（これらの属性はその着信を含む）の内の少なくとも８個で現れることが見出されるなら、その同義語閾値は越えてしまい、そして２個の属性はそれらが新しい同義語としての資格を得るとき一緒に共通にグループ化されると考えられる。
【００５６】
幾つかの実施例では、異なる組み合わせの属性が其々新しい同義語のためにテストされ得る。例えば、もし着信が３個の属性を有するなら、それは全ての３個の属性がその閾値パーセントを越える数の候補に現れるか、そしてそれがその３個の内の２個の属性の組み合わせの各々がその閾値パーセントを越える数の候補に現れるか決定され得る。かくして複数個の同義語はその着信の内の一組の属性から発見されてもよいし、また同義語がそれらの属性の内の幾つかの中でオーバーラップしていてもよい。
【００５７】
もしステップ２０４でその同義語閾値を超えなければ、そのプロセスは２１６で終了する。もし着信がその同義語閾値を超える候補の数に現れる２個以上の属性を有するなら、ステップ２０６ではこれらの属性のグループから作られた１個または複数個の新しい同義語が生成される。ここで説明する実施例では、新しい同義語を加えるということは新しい使用されていない同義語識別子を新しい同義語中の属性ごとに同義語テーブル３０中のエントリに加えること、そしてそのエントリにその関連付けられた属性を割り当てることを含む。もし属性タイプが使用されていれば、同義語中の各属性のタイプも同義語テーブル３０に加えることもできる。
【００５８】
更に、ステップ２０６では、新しい同義語として生成されたそのセットの属性を有する候補である全ての適切な候補に新しい同義語が加えられる。これは着信により生成されもしくは加えられた着信エンティティに同義語を加えることを含む。好適な実施例では、その同義語が候補に加えられるのは、同義語識別子および関連付けられた候補エンティティ識別子をエンティティ同義語テーブル３４に加えることによってである。もし異なるグループの同義語が閾値条件に合致するなら、複数個の新しい同義語を加えることができる。そのプロセスは２１６で終了する。
【００５９】
幾つかのケースでは、一つの同義語からの属性のサブセットが１個もしくは複数個の追加の同義語を形成してもよい。例えば、着信中の４個の属性がその同義語閾値を超えさせるなら、これらの４個の属性は第１の同義語の中に含まれ、その第１の同義語が適切な候補に加えられる。異なる候補はこれらの４個の属性のうちの２個のみを有するかもしれない。その場合、これらの異なる候補の数は、これらの２個の属性のみから第２の同義語が形成されるのを許容するほどに十分大きく、そしてその第２の同義語がこれらの異なる候補ならびにその第１の同義語を含む候補に加えられる。
【００６０】
一実施例では、４個の候補が特定の名前もしくは住所の属性の一方または両方を有し、候補１ないし３は全てこれらの名前および住所の属性を有し、そして同義語生成のための閾値パーセントが７６％である。かくしてこれらの属性は同義語の中に形成されなかった。何故ならばそれらが全ての候補のうちの７５％およびその閾値を超えない中でグループとして存在するからである。これらの同じ属性の両方を新しいエンティティに挿入する着信方法を受け取る。これは着信エンティティを含む時の合計５個のうちから４個にこれらの一致する属性を備えた、８０％およびその閾値を超える候補の数をもたらし、その結果、２個の属性を備えた新しい同義語が発見されそして同義語テーブル３０に加えられる。更に、候補１ないし３の各々およびその着信により生成される着信エンティティが、これらのエンティティ識別子および同義語識別子をエンティティ同義語テーブル３４に加えることによって、新しい同義語を有する。
【００６１】
ステップ２０２に戻って、もし 着信が１個もしくは複数個の現在ある同義語を既に含むなら、そのプロセスはステップ２０８に続く。ステップ２０８では拡張された同義語を生成するために、属性が現在ある同義語に非同義語属性が加えられることができるか決定される。現在ある同義語の一部でない属性が着信中に何かあるか、そしてこれらの非同義語属性が、拡張された同義語のために考えられている１個もしくは複数個の属性を有するその候補の所定の同義語閾値パーセントを超える同義語候補の数に現れる非同義語属性に一致するかを決定される。その拡張された同義語は、現在ある同義語中に何らかの非同義語属性を有するかまたは非同義語属性を有するものである。ここで、「同義語属性」は着信中に存在する同じ同義語を既に有する候補であり、従ってこの方法は、元の同義語プラス非同義語属性を有する候補の数をその閾値パーセントに比較する。前述のように、候補の数は候補としての着信エンティティを含む。その発見閾値パーセントはステップ２０４で使用されるのと同じになり得る。ここで説明する実施例では、そのプロセスは属性相互間の正確な一致を探し求めている。
【００６２】
かくして、このプロセスは、１個もしくは複数個の新しい非同義語属性の着信の挿入が、非同義語属性のための一致する候補の数をしてその閾値を超えさせるかチェックする。ステップ２０４と同様、幾つかの実施例では、その現在ある同義語と非同義語属性との異なる組み合わせがその閾値を超えるためにテストされ得る。そして複数の組み合わせがその閾値条件に合致するかもしれない。
【００６３】
もしその閾値が合致しなければ、そのプロセスはステップ２１４に続く。もしその着信が２個以上の非同義語属性を有し、その発見閾値を超える同義語候補の数に現れるなら、ステップ２１０においてその非同義語属性は、その現在ある同義語プラス加えられた候補を含む新しい拡張された同義語を生成するための適切な現在ある同義語（すなわち着信中の特定の同義語であってその一致する候補にも存在する同義語）に加えられる。ここで説明する実施例では、これは、同義語テーブル３０において現在ある同義語識別子に新しい属性を加えることによって行われる。もし属性のタイプが使用されているなら、その同義語の各々のタイプもまたその同義語テーブルに加えられることができる。
【００６４】
ステップ２１２では、その加えられた属性（およびその現在ある同義語）を有する任意の候補に新しい同義語が加えられる、ここで説明する実施例では、エンティティ同義語テーブル３４に同義語識別子および着信候補エンティティを加えることによって、その新しい同義語がその着信エンティティ（着信候補）（もし適切なら）に加えられる。図２ないし図５のテーブルに似たテーブルを用いる、ここで説明する実施例では、典型的にはそのシステムに既にストアされた他の一致する候補がエンティティ同義語テーブル３４中の（今や拡張された）同義語に既に関連付けられる。前述のステップは属性が加えられ得る着信の中の、現在ある同義語ごとに反復されることができる。
【００６５】
ステップ２１４では、ステップ２０８の条件に合致しなかった、またはステップ２１０における現在ある同義語に加えられなかった、追加の非同義語の属性が着信中にあるか、そのプロセスがチェックする。そのような非同義語の属性は現在ある同義語に加えられるべき閾値条件に合致していなかったかもしれないが、新しい同義語を形成するための閾値条件にそれ自体をおそらくは合致させてくるかもしれない。かくして、もしそのような追加の非同義語の属性があるなら、そのプロセスはステップ２０４に続く。そしてそのステップ２０４でこれらの非同義語の属性がそのステップに対し前述したように何らかの新しい同義語を形成することができるかそれらがテストされる。そのプロセスは２１６で終了する。
【００６６】
他の実施例で、前述の方法の諸ステップが異なる順序で行われ得ること、適切であれば同時に行われ得ること、あるいはまた異なる態様で組み合わされ得ることを理解されたい。例えば、図６では、ステップ１１４における同義語からの属性の除去が、新しい同義語を発見し、加えるためのステップ１１６を行うのと同時に、またはそのプロセスの一部としておよび行われることもできる。図７において、ステップ１６４の唯一の属性を同義語が含むかチェックするのは、ステップ１６２の属性の除去と同時に行われることができる。更に、他の実施例では異なるタイプの同義語形成閾値といったような変形例を使用することができる。
【００６７】
本発明の実施例は入力データの各々個別の属性でもって検索することにより大きな数の個別の検索を行うのではなく、データベースにおける一致するデータもしくは候補のデータを検索するために同義語を有利に使用することができる。すなわち任意の属性が検索されるとき、その全体の同義語が代用され得る。ここで説明する同義語は、分析論、検索エンジン、スペル・チェッカなどを含む、広範なアプリケーションで使用され得る。
【００６８】
更に、本発明の実施例は、データがデータベースの中に取り入れられもしくは挿入されている際、そして挿入されているデータならびにそのシステムに既にストアされたデータに基づいて、リアルタイムに、かつオンザフライで動的に調整される（発見されもしくは修正されまたはその両方を施される）同義語またはデータ・クラスタを提供することができる。このことは、システムの現在のデータに関連して同義語が常に更新され、かつ再評価されるのを許容する。更に、そのエンティティ・データを更新し続けるため、かつエンティティのドリフトを防止するため、入力データが取り入れられている際、同義語に関連する全てのエンティティがリアルタイムに更新されることができる。このような特徴は動的な同義語のテーブルまたは辞書が維持されることを許容し、データ・クラスタリング、または同義語形成が性的なストアされたデータに基づいて行われていた従来の方法よりも時間を節約する。例えば、データ・マイニングにおけるデータ・クラスタリングは通常は非常に遅い。しかし、本発明の実施例において可能なように、もしクラスタが、取り入れ中にリアルタイムに決定されるなら、クエリが非常に高速に後で行われることができる。
【００６９】
更に、本発明の実施例は特定の領域の知識を必要とすることなく同義語を見つけることができる。かくして複数のタイプの属性で、任意のタイプのものが単一の同義語に集められることができ、そして或るタイプのデータのための類似性技法を知る必要なしに同義語が決定されることができる。ここで説明される自動的な同義語発見は名前のコンポーネントのためだけでなく、数字や住所のコンポーネント、色、綴りのミスなど、任意のタイプの属性に使用されることができる。更に、エンティティの分解（resolution）を行うときに、特定のデータについて解析者に提供され得る増量した情報および情報のタイプは、ここで説明する同義語を用いると、非常に有用であり得る。例えば、入力の住所を有していた人々の９０％が特定の電話番号をも共有していたことをそのシステムはユーザーに通知することができる。
【００７０】
更に本発明の実施例は同義語のテーブルまたは辞書のストレージ・コストを大きく減らすことができる。何故ならば（非同義語関連処理の場合）幾つかのポイントでそのシステムにより使用されそしてそのシステムによりストアされるデータ属性のみが同義語では使用されるからである。かくして、そのエンティティに関連する同義語のみ、およびそのシステムにより使用され処理されるデータがストアされる必要があり、決して必要とされない多量の同義語属性を予めストアしておく余分のストレージ・スペースは不要である。何故ならばそのような属性は着信するデータには決して見出されず、あるいはデータベースによりストアされないからである。
【００７１】
本発明の実施例を図示の実施例に従って説明したが、当業者これらの実施例に対する変形例もあり得ること、そしてこれらの変形例が本発明の趣旨および範囲内にあることも容易に理解されよう。従って、多くの変形例が特許請求の範囲から逸れずに当業者によってなされてもよい。
【技術分野】
【０００１】
本発明はコンピュータ・システムにおけるデータ・クラスタリングに関し、特に同義語のようなデータ・クラスタの発見および修正に関する。
【背景技術】
【０００２】
データ・マイニングはデータベースにおけるデータなど、データから潜在的に使用可能な情報を引き出すことを含む。データのクラスタリングがデータ・マイニングではしばしば使用される。それは、データまたは属性を異なるグループにクラス分けすることであり、すなわち各クラスタ中のデータが共通の形質(特性trait)を共有するようにクラスタ中にデータをグループ分けすることである。例えば、データのクラスタは検索がもっと効果的に実行されるのを許容する。何故ならばクラスタが各々の個別の属性の代わりに検索されることができ、かくして検索動作の回数を減少させるからである。
【０００３】
幾つかのコンピューティング・システムでは、あるデータ・クラスタを「同義語 (synonyms)」と呼ぶことができる。ここでいう同義語は検索目的または類似の機能からは全て同じと考えられる多数の異なるデータ・アイテムを含むことができる。この同義語は、任意の関連付けられるデータ・アイテムが見つかるときに仮想される同義語のデフォルト（省略時）値である「基本形（root form）」をもつことができる。同義語は入力事項に正確には一致はしていないかもしれないデータを検索して見つけ出すのに有用となり得る。例えば、人の特定の名前を検索すると、その名前と正確に一致したものが見つかるはずである。そして、その名前の同義語はその名前の変形を含むことができ、これもまたその同じ人に関係するデータを見つけ出すために検索されることができる。
【０００４】
コンピューティング・システムにおいて同義語を用いる一つの標準的な方法は、語（word）またはその語幹（root）に関連付けられかつ同じ意味を有するものとして全て取り扱われるデータ属性（同義語）のクラスタに各々の基本形の語がマップされたものをリストしているルックアップ・テーブルである同義語テーブルを提供することである。典型的には、同じ意味を持つ既知の同義語は、予め決定されまたは予め計算され、後で使用するために同義語テーブルにストアされる。入力語を受け取ると、その入力語をその同義語テーブル中で探し出すことによって、一致する同義語または属性が見出され、これが基本形の語または同義語識別子を提供する。
【０００５】
従来の同義語を使用する場合の一つの欠点は予め計算するのが難しいか自明でないかその両方であるデータのための同義語が存在することである。例えば、Ｒｏｂｅｒｔという名前（基本語 root word）の同義語はＢｏｂ、Ｂｏｂｂｉｅ、Ｂｏｂｂｙ、Ｄｏｂｂ、Ｒａｂ、Ｒａｂｂｉｅ、Ｒｏｂｂｉｅ、Ｒｏｂｂｙ、Ｒｏｂ、Ｒｏｂａｒｄ、Ｒａｉｂｅａｒｔ、Ｌｏｐａｋａ、およびＬｏｐｅｔｉであってよく、これらの変形例の全てが見つかっているわけでも予め決定されるわけでもない。更に、同義語または他のタイプのデータ・クラスタの形成および更新は全ての所望のデータが入力された後の別の時間に、またはクエリのときに典型的には行われる。これはその処理中に行われるクエリを非常に遅くすることがあり、また更新が行われる前に同義語が不正確またはドリフト（不完全）とされるのを潜在的に許容してしまう。
【０００６】
更に、同義語に対し語幹（root）をマッピングするルックアップ・テーブルは同義語の正確かつ完全なリストがそのタイプに対し見出されるように同義語のタイプの領域の知識を必要とする。例えば、言語領域の知識および技法が名前または語に対する同義語を正確に見出すのに使用されるが、他の領域の知識も数値など、他のタイプの同義語を決定するのに使用される必要がある。更に、ある語幹に対する全ての同義語のストレージは多量のストレージをとることができる。何故ならば各語幹の全ての既知の同義語は、これらの同義語がこれまで使用され、ストアされ、またはそのシステムにより検索されたかどうかに拘わらず、ストアされるからである。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、必要なものは、例えば同義語を迅速に更新することができ、データの正確さにおけるドリフトを防止することのできるような、そしてシステムによる使用時に同義語および属性のために必要なストレージを必要とするだけ、および／もしくはデータの特定の領域の知識を必要としないデータ・クラスタ（同義語など）を形成し修正するための改良された方法および装置である。本発明はそのようなニーズに取り組むものである。
【課題を解決するための手段】
【０００８】
本出願の発明は同義語などのデータ・クラスタの発見および修正に関する。本発明の一つの側面は、データをクラスタリングする方法が、システム上で情報を受け取るステップを含み、その情報は前記システムによりアクセス可能なデータベースにストアされもしくはストアされるべき１個もしくは複数個のデータ属性を操作し、その情報および操作がデータ・クラスタに明示的に関連しない。データ・クラスタはその受け取った情報に基づいて自動的に調整され、そのデータ・クラスタは複数個のデータ属性を含み、その受け取った情報により操作される少なくとも１個のデータ属性を含む。そのデータ・クラスタは動的に調整され、受け取っている情報に応答する。コンピュータ可読媒体およびシステムが似たような特徴を含む。
【０００９】
本発明の他の側面では、データをクラスタリングする方法がシステム上で情報を受け取るステップを含み、その情報は、そのシステムによりアクセス可能なデータベース中の少なくとも１個のデータ・エンティティにおいてストアされるべき複数個の受け取ったデータ属性を含む。１個もしくは複数個のデータ・クラスタがその受け取った情報に基づき修正され、その１個もしくは複数個のデータ・クラスタの各々が複数個のデータ属性を含むとともに、その受け取ったデータ属性を少なくとも１個含み、そしてその修正はその１個もしくは複数個のデータ・クラスタから特定のデータ属性を除去することを含む。
【００１０】
本発明の他の側面では、同義語を発見する方法がシステム上で情報を受け取るステップを含み、その情報はデータベースにデータ属性をストアさせる特定のデータ・エンティティに関連付けられる複数の受け取ったデータ属性を含む。その受け取ったデータ属性はそのデータベースにストアされる１個もしくは複数個のデータ・エンティティにストアされる筈であり、そのデータベースではその情報およびデータ属性が同義語を明示的に関連させない。同義語はその受け取ったデータ属性に基づいて、ならびに現在ストアされているデータに基づいて自動的に形成される。その形成には、少なくとも１個の閾値属性を含む複数個の候補のデータ・エンティティをデータベースにおいて調べることを含み、その同義語は動的にそして受け取った情報に応答して形成される。
【００１１】
本発明による実施例は動的なデータ・クラスタおよび同義語の発見を提供することができ、また修正も提供することができるが、その修正は非同義語関連の入力データを受け取るときに同義語が調整されるのを許容する。これはデータのドリフトを招来することなくリアルタイムで行われる更新および高速のクラスタリングを許容する。更特定の領域の知識を必要とすることなく同義語を発見することができ、異なるタイプのデータ特性を含むことができ、ストレージのコストを減じることができる。何故ならばシステムにより使用されるこれらの属性の入力のみが同義語に含まれる必要があるからである。
【００１２】
ここで本発明を、単なる例示であるが、以下の図面で説明するようにその好適な実施例に従って説明する。
【図面の簡単な説明】
【００１３】
【図１】本発明とともに使用されるのに適当な例示のシステムのブロック図である。
【図２】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図３】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図４】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図５】本発明の同義語の処理で使用され得るテーブルの例を示す概略図である。
【図６】本発明の同義語の処理のための方法の実施例を示すフローチャートである。
【図７】着信情報にもとづき属性が除去される図６のステップを実装するための方法の実施例を示すフローチャートである。
【図８】同義語が発見され、その同義語テーブルおよび候補に加えられる図６のステップの実施例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
本発明はコンピュータ・システムにおけるデータ・クラスタリングに関し、特に同義語のようなデータ・クラスタの発見および修正に関する。以下の説明は本発明を当業者が製造し、使用することができるように提供され、一つの特許出願の内容およびその要求に合わせて提供される。好適な実施例に対する種々の変形、およびここで記述する汎用的な原理および特徴が当業者には容易に理解できよう。従って、本発明は図示された実施例に限定する意図はなく、ここで開示する原理および特徴に矛盾しない最大の範囲に与えられるべきである。
【００１５】
本発明が特定の実装例で提供される特定のシステムに従って主として記述されている。しかし当業者がこの方法およびシステムが他の実装例において効果的に動作するであろうことは容易に理解されよう。例えば、本発明とともに使用可能なシステムの実装例が多数の異なる形式をとることができる。本発明はまた幾つかのステップを有する特定の方法の脈絡で記述される。しかし本発明と矛盾しない異なるステップおよび／もしくは追加のステップを有する他の方法に対しても効果的に動作する。
【００１６】
本発明の実施例が完全にハードウエアの実施例、完全にソフトウエアの実施例、あるいはハードウエアおよびソフトウエアの両要素を含む実施例といった形態を含むことができる。ソフトウエアの実施例は、以下に限定されるものではないが、ファームウエア、常駐ソフトウエア、マイクロコードなどを含むことができる。更に、本発明の実施例はコンピュータまたは任意の命令実行システムによりあるいはそれと関連して使用されるためにコンピュータ可読媒体によりストアされたプログラム命令またはコードの形態をとることができる。その媒体は、電子的、磁気的、光学的、電磁的、赤外線の、もしくは半導体のシステム（または装置、デバイス）或いは伝送媒体であってよい。コンピュータ可読媒体の例は半導体もしくは固体素子のメモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、磁気ハード・ディスクおよび光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）を含む。
【００１７】
本発明の特徴を一層具体的に説明するために図１ないし図８を以下の説明とともに参照されたい。
【００１８】
本発明による方法およびシステムは、新しいデータ・クラスタを形成すること、現在あるデータ・クラスタを修正することを含む、データのセットのためのデータ・クラスタを調整することを指向する。そのデータ・クラスタはここで「同義語」と呼ばれる。ここで「同義語」という用語は、クラスタ、グループまたは２以上の属性の関連付け（association）をいう。但し、これらの属性はシステム１０によりストアされたデータ・レコード、集合または「エンティティ」において一緒に十分に共通の生成もしくは見かけに基づくその同義語において互いにグループ化されてきている。例えば、データ候補を検索するための個々の属性の代わりに同義語が有利に使用されることができ、かくして検索操作の回数を減らすことができる。
【００１９】
本発明による方法およびシステムはデータの取り入れ時にデータの汎用的なリアルタイムのクラスタリングを提供する。本発明による実施例は幾つかの方法で提供され得る。例えば、データの汎用的なリアルタイム・クラスタリングを提供するシステムが使用され得る。以下の２段階の検索を有するシステムも本発明に従うことができる。即ちその検索の一つの段階は偽の肯定を含む候補一致を得ること、そしてその検索の第２の段階は点数を付け（score）、さもなければ候補を解析してそれらを更に狭めおよび／もしくは所望の候補を確認するという２段階のシステムである。更に、もっと特定のアプリケーションでは、以下のエンティティの認識（recognition）および分解（resolution）のシステムが本発明に従ってあり得る。エンティティが見つかり異なるエンティティ同士が比較されて、どのエンティティが入力属性に関連付けられるかを決定する。候補のエンティティ同士は候補リストを用いて比較され、その候補は点数（スコア）を付けられて所望の一致を確認する。以下の実施例を或るエンティティ分解システムに関連して説明するが、他の実施例の他のタイプのアプリケーションにも適用され得る。
【００２０】
そのようなエンティティ解析システムとともに使用するのに適するシステムの一例は、人または他のエンティティのアイデンティティ（同定）を識別する「Ｒｅｌａｔｉｏｎｓｈｉｐ Ｒｅｓｏｌｕｔｉｏｎ（リレーションシップ・レゾリューション）」および「Ａｎｏｎｙｍｏｕｓ Ｒｅｓｏｌｕｔｉｏｎ（アノニマス・レゾリューション）」を含むＩＢＭコーポレーションからの「Ｅｎｔｉｔｙ Ａｎａｌｙｔｉｃ Ｓｏｌｕｔｉｏｎｓ（ＥＡＳ、エンティティ・アナリティック・ソリューションズ）」である。そのシステムは矛盾した不明瞭なアイデンティティおよび属性の情報を単一解のエンティティ（a single resolved entity）、例えば、ユーザーまたは組織に帰結させ、個人および／もしくはエンティティ間の非自明の関係を検出する、そしてデータセット内の不明瞭さ、スペルミス、または部分的記録を含むファジーな一致性に帰結させる。
【００２１】
図１は本発明とともに使用するのに適する例示のシステム１０のブロック図である。システム１０は１個もしくは複数個のコンピュータ・システム、電子システムもしくはデバイスを用いて実装される。この例のシステム１０は、１個もしくは複数個のマイクロプロセッサと、メモリ（ＲＡＭ、ＲＯＭ、フラッシュ・メモリなど）、ストレージ装置（ハード・ディスク、ＤＶＤ−ＲＯＭおよびＣＤ−ＲＯＭなどの光ディスク）、入力装置（キーボード、ポインティング・デバイス）、出力装置（モニタ、プリンタ）、通信装置およびネットワーク装置を含む種々の周辺装置とを含む周知のシステム・ハードウエア上に実装され得る。図１の例では、データ・ソース・システム１１がデータベース・サーバー１４と通信することができるアプリケーション・サーバー１２にデータを提供することができる。システム１０は、他の実施例で他のタイプのシステムを用いて実装されることもできる。
【００２２】
データ・ソース・システム１１が通信リンク１６を介してアプリケーション・サーバーに情報を提供する。データ・ソース・システム１１はそれ自身が異なるソースからの情報を、ユーザーがデータを入力する、あるいは異なるシステムがネットワークを介してデータを提供するといったようにして受け取ってもよい。ここで言及する例では、その情報が１個もしくは複数個の「エンティティ」または「データ・エンティティ」に関連付けられるデータ属性を含み、そのようなエンティティがデータをグループ化したレコード、集合またはグループであるデータ特性を含む。エンティティは人、組織、オブジェクト、主題、トピックなどをあらわすことができる。エンティティはそれに関連付けられる１個もしくは複数個のデータ属性を有し、幾つかの実施例ではその属性がそのエンティティを記述しまたは説明することができる。エンティティおよびその属性がシステム１０によりストアされ処理される。エンティティはまたそのエンティティに関連付けられるデータの異なるコレクションである１個もしくは複数個の異なる「アカウント（口座）」をもつことができる。
【００２３】
例えば、銀行などの組織は異なる人または顧客のとしてある種のエンティティを指定することができる。但し、各顧客は例えば財産を保持するためのアカウントまたは財産的な状態（小切手のアカウント、ローン・アカウントなど）を指定するためのアカウントなど異なるアカウントを所有することができる。顧客のエンティティに関連付けられる属性は、名前、住所、雇用者、電話番号などそのエンティティのための記述的な情報であり得る。
【００２４】
アプリケーション・サーバー１２がデータ・ソース・システム１１から入ってくる情報を受け取り、アプリケーション・プログラム・サービスおよびその情報のためのインターフェースを、リクエストしている顧客または他のリクエストしている人に提供することができる。アプリケーション・サーバーはそのサーバー上のアプリケーションが、他のサーバー、データベース管理システムなど、他の従属するアプリケーションと通信するのを許容することができる。本発明のここで説明する実施例に関しては、アプリケーション・サーバー１２は本発明に従って１個もしくは複数個の同義語処理アプリケーション２０を提供する。例えば、同義語処理アプリケーション２０はアプリケーション・サーバーに接続された、リクエストしているクライアントのためにランすることができる。複数の同義語処理アプリケーション２０がデータのもっと効果的な処理を提供するために並列にランすることができる。他の実施例では、同義語処理アプリケーション２０がクライアントまたはデータベースのサーバー上でランすることができる。
【００２５】
同義語処理アプリケーション２０が本発明の同義語の発見および他の処理を行うことができる。この処理は新しい同義語が受け取った着信（inbound）情報中に含まれるか調べること、存在する同義語に属性を加えたり削除したりすること、同義語を削除することを含むことができる。この処理はまた同義語および／または類似の属性を有する他の候補のエンティティを見出しそして処理するための候補の処理を含むことができる。これらの機能は図６に関連してあとで詳細に説明する。他の実施例では、同義語アプリケーション機能はそのシステム上の１個もしくは複数個の異なるアプリケーション上に実装されることができる。
【００２６】
データベース・サーバー１４は本発明で使用される情報のためのストレージを提供することができ、ハード・ディスク、磁気テープまたは他の時期ストレージ、ＣＤ、ＤＶＤまたは他の光ストレージといった多様な市販のストレージ装置の内の任意のものを用いて実装され得る。ここに記述された図１の実施例では、データベース・サーバー１４が同義語テーブル３０、１個もしくは複数個の属性テーブル３２、エンティティ同義語テーブル３４、およびエンティティ・アカウント・テーブル３６をストアするデータベース２４へのアクセスを提供する。同義語テーブル３０は、夫々の同義語に同義語識別子のラベルが付けられた多数の同義語をストアする。同義語テーブル３０はその同義語に関連付けられた属性への同義語識別子のマッピングをストアする。属性テーブル３２はシステム１０中のエンティティのデータ属性の全てをストアし、属性のタイプのための情報および関連付けられたアカウントをも含むことができる。エンティティ同義語テーブル３４はそのエンティティへの同義語のマッピングをストアし、そのエンティティでもって同義語が関連付けられる。アカウントを用いる実施例では、エンティティ・アカウント・テーブル３６はそのエンティティへのアカウントのマッピングをストアし、そのエンティティでもってそれらが関連付けられる。これらのテーブルの実例は図２ないし図５に沿って詳細に説明する。
【００２７】
本発明の代替実施例では、データベース２４にストアされたテーブルの幾つかまたは全てが他のストレージ・ロケーション、例えばその同義語処理アプリケーション２０のローカルのストレージなどのところにストアされ、アクセスされる。幾つかの代替実施例では、同義語処理アプリケーション２０がデータベース・サーバー上でランすることができ、またはその同義語が適用するデータセットがその同義語処理アプリケーション２０のローカルのストレージにストアされ得る。
【００２８】
図２ないし図５はデータベース・サーバー（または他のシステム・ストレージもしくはメモリ）にストアされることができ、かつ本発明の同義語処理で使用され得るテーブルの実例の概略図である。図２はエンティティ同義語テーブル３４の例を示す。一つの列では、同義語識別子（ＩＤ）が、異なる同義語を識別するためにストアされる。他の列では、異なるアイデンティティを識別するエンティティ識別子（ＩＤ）がストアされ、そこで識別されるエンティティはそのテーブルの同じ行にリストされた同義語を含む。このテーブルは同義語およびエンティティの追跡を可能にし、いろいろな同義語が更新されるときエンティティが更新されるのを許容する。
【００２９】
図３はエンティティ・アカウント・テーブル３６の例を示す。一つの列で、アカウント識別子はそのシステム上に提供される異なるアカウントを識別するためにストアされる。他の列では、エンティティ識別子はそのテーブルの同じ行のアカウントの関連付けられる特定のエンティティを識別するためにストアされる。エンティティごとに複数個のアカウントを許容する実施例ではそのアカウントをその適切なエンティティに関連付けるようにエンティティ・アカウント・テーブル３６が使用され得る。
【００３０】
図４は本発明により見出される同義語をストアするための同義語テーブル３０の例を示す。同義語テーブル３０では、そのテーブル中の各データ属性が特定の同義語に関連付けられる。同義語テーブル３０は特定の同義語を識別するための同義語識別列４０を含む。属性値列４２はそのテーブルの同じ行にリストされる同義語に関連付けられている属性のための属性値をストアする。属性タイプ列４４は属性を分類わけするように割り当てられるべき属性のタイプを許容する幾つかの実施例に含まれることもできる。その属性タイプはそのシステムのために有用な任意の指定されたタイプであることができ、その属性テーブル３２（以下で説明）で特定される。幾つかの場合には、その属性タイプが、図６に関連して詳細に説明するように、候補を検索するときの同義語処理の際に有用である。（同義語ＩＤにより識別される）同義語テーブル３０で提供される各同義語はそれに関連付けられた２個以上の属性を有し、かくして例示の同義語テーブル３０において少なくとも２行のストレージが必要である。他の実施例では他のテーブル組織が提供され得る。
【００３１】
図５は同義語テーブル３０におけるエンティティに関連付けられるデータ属性をストアするための属性テーブル３２の例を示す。一つの列４６では、属性識別子が各々の個別の属性を識別する。タイプ列４８が属性のタイプを示す。これはもし特定の実施例において属性のタイプが提供されている場合である。例えば、属性テーブル３２は名前、住所、電話番号および雇用者という４つの異なる属性タイプを示す。任意のタイプの属性を指定でき、このことが効率を上げるために検索パラメータを制限するかまたは異なる属性を分類する際の助けとなり得る。幾つかの実施例では、一つの属性もまた明瞭に識別できる異なる属性の一部（sub-portion）となり得る。例えば、郵便番号がそれ自身の属性となり得るし、そして別個の住所属性の一部ともなり得る。
【００３２】
値の列５０が属性の値を示す。ここで「値」もしくは「属性」という用語はいろいろな異なるタイプのデータに言及するのに使用される。例えば、値は数値（整数、実数など）または１個以上の英数字もしくは特定の文字を含むテキスト・ストリングであってよい。その属性をストアするためのその関連付けられたアカウント識別子をアカウント列５２が示す。これは使用される特定の実施例でアカウントが使用される場合である。アカウントを使用していない他の実施例では、属性テーブル３２がアカウント識別子の代わりにアカウント列５２にエンティティ識別子を含むことができる。これは特定の属性を有するエンティティを直接見つけるために使用され得る。
【００３３】
他の実施例では、属性テーブル３２が２以上の別個のテーブルとして実装され得る。例えば、各テーブルは一つのタイプのみのテーブルを含むことができ、その結果名前の属性のためのテーブル、ストリートの住所の属性のための異なるテーブル、Ｅメール・アドレスのための異なるテーブル等がある。
【００３４】
図６は本発明の同義語処理のための方法１００の実施例を示すフローチャートである。ここで開示する方法はハードウエア、ソフトウエアまたはハードウエアおよびソフトウエアの両方の組み合わせであってよい。方法１００は、メモリ、磁気テープ、磁気ディスク、光ディスクなどコンピュータ読み取り可能な媒体上で与えられるプログラム命令を用いて実施されてもよい。ここで説明する方法の処理ステップが唯一の実施例であること、これらのステップが異なる順序でまたは並行して実行され得ること、あるいは他の実施例における異なる方法で組み合わされることに留意されたい。
【００３５】
この方法は１０２で開始し、ステップ１０４で着信情報（ここで「着信（inbound）」と呼ぶ）を受け取る。その着信情報はそのシステムの１個以上のデータ属性を操作する。これはいろいろな異なる形式のいずれかをとることができる。例えば、その着信はデータベース・サーバー１４によりインターフェースされるデータベースの中に、または異なるデータセットまたは他のストレージ（全てここでは「データベース」と呼ぶ）の中にデータを挿入することができる。このように挿入されるデータはここで説明するように、着信中に含まれるデータ属性となり得る。エンティティの分解（resolution）または認識を行う幾つかの実施例では、その着信情報はそのシステムへのデータ属性入力の集合であるレコード、かつシステム１０により認識される１個以上のデータ・エンティティに関連付けられるレコードであり得る。一つの特定の実施例では、その着信というのは銀行のローン部門で顧客（エンティティ）のための新しいアカウントにおいて入力されるべきデータ属性を含むレコードであり得る。ここでそのレコードはその銀行のところでその顧客により申請されたローン・アプリケーションに関連付けられ、そしてまたそのデータ属性が名前、住所、雇用者の電話番号およびその顧客の従業員を含む。
【００３６】
その着信はまたそのシステムの現存するデータ属性を操作することができる。例えば、幾つかの実施例は着信がまた、あるいは代わりの命令が、データベースまたはシステムにストアされる特定のデータ属性が削除されるべきことを（着信情報中のコマンドまたは命令を介して）許容することができる。幾つかの実施例では、その着信が、現存するデータ属性またはクエリを用いるエンティティを見つけるように使用されることができる。その着信は任意の適当なフォーマットであってもよく、例えば一つの実装例ではその着信がＸＭＬフォーマットである。
【００３７】
どんな場合でも、着信が典型的には意図され、そしてデータベースにおいてデータを取り扱う（データ挿入、削除、比較など）ために明示的である。データ・エンティティもしくはレコードのためなど、その操作およびデータは同義語もしくはデータ・クラスタに特にあるいは明示的に関連付けられている必要はない。例えば、その着信情報はそのシステム上で同義語またはデータ・クラスタのことを知る必要さえない。かくして、本発明による実施例は自動的かつ動的な同義語／データ・クラスタの処理および調整をそのような同義語の調整を意図した特定のまたは明示的な入力必要とすることなく、行うことができる。
【００３８】
ステップ１０６では、データ属性がその着信から抽出される。幾つかの実施例では、これらの属性はその関連付けられた着信に関連付けられた一つのエンティティ（または代替例では１個もしくは複数個のそのようなエンティティ）を説明するかまたはそれに関係する。例えば、上述のローン顧客についてのデータを挿入するために着信レコードがその名前、完全な住所、電話番号およびその顧客の雇用者のための別個の属性を有することができる。その完全な住所は属性となり得るか、またはそれとは別に属性もまたその状態およびその住所の郵便番号など、幾つかの実施例で作業アドレスの部分から提供されることができるか、あるいはその両方かである。属性は、一旦抽出されると、システム１０のメモリ中にロードされることができる。
【００３９】
ステップ１０８では、同義語テーブル３０から選択された同義語がその抽出された属性のために見つかる。同義語テーブルがクエリされて、その抽出された属性のいずれかがそのテーブル中の属性値のいずれかと一致するか調べる。そしてもし一致が見つかれば、これらの属性を含むその対応する同義語が選択される。同義語テーブル３０中の各々の同義語は少なくとも２個の属性を有する。属性をタイプに分類する実施例では、着信が各々の抽出された属性に関連付けられたタイプを含むことができ、このタイプが同義語テーブル３０中の属性のタイプに比較されることができて検索量を少なくすることができる。同義語テーブル３０中の各同義語は任意の数の異なるタイプの属性を含むことができる。例えば、抽出された属性のタイプが図４の同義語テーブル３０の属性タイプ列４４にリストされたような属性のタイプに比較されることができる。その結果、その抽出された属性と同じタイプを有する属性値列４２中の対応する属性値のみがその抽出された属性に比較される。同義語の選択は着信中の各々の抽出された属性ごとに反復される。タイプを有しない異なる実施例では、抽出された属性が同義語テーブル３０中の各属性に比較されることができる。他の実施例が１個もしくは複数個の抽出された属性に一致する同義語を選択する他の方法を使用することができる。
【００４０】
ステップ１１０では候補グループもしくはエンティティが同義語テーブル３０からの選択された同義語およびその抽出された属性のセットを用いて発見され選択される。これらの候補エンティティはここでは「候補」というが、これは「着信エンティティ」即ちその着信に関連付けられたエンティティのための潜在的一致である（現在あるエンティティ、またはその着信により生成される新しく生成されるエンティティに加えられるべき着信の情報か始めは知られていないかもしれない、いずれの場合も着信エンティティと呼ばれる）。その選択された同義語は以下のように候補を見つけるのに使用される。ステップ１１０で選択された同義語ごとに、その選択された同義語を共有する全ての候補が選択される。これがここで説明する実施例において行われるのは、選択された同義語識別子に一致する同義語識別子を見つけるためにエンティティ同義語テーブル３４をチェックすることにより、そしてその一致した同義語を有する１個もしくは複数個の関連付けられたエンティティを選択することによってである。これは選択された同義語ごとに反復される。このタイプの検索は、例えば各々の同義語を用いて一致する候補を見つけるのをクエリが許容するのであって、各同義語または着信の中で各属性を用いてクエリを行わなければならないというのではないのではない。
【００４１】
抽出された属性のセットはまたステップ１１０において候補を見つけるのにも使用される。同義語テーブル３０において任意の同義語の一部ではない、その着信から抽出された属性があってもよく、これらの非同義語属性が追加の候補を見つけて選択するのに使用される。例えば、ここで説明する実施例では、各々の非同義語属性値が属性テーブル３２中の属性値に比較され、そして一致する属性値のためのアカウント列５２中のアカウント識別子が図３のエンティティ・アカウント・テーブル３６（または他の適当なテーブル）を用いてこれらの一致する属性を有する候補を見つけるのに使用される。アカウントを有しない他の実施例では、アカウント列５２中のエンティティ識別子がその一致する属性を有する候補エンティティを直接見つけるのに使用され得る。幾つかの実施例では、幾つかの所定のタイプの属性が候補を求めての検索から除外されることができる。
【００４２】
幾つかの実施例がステップ１１２を行ってもよい。そこでは全ての抽出された属性を用い、同義語に属性を含む、ステップ１１０で見つかった全ての候補に対して点数付けされる(score)。属性の点数付け即ちスコアリングは、必要であれば、属性タイプとともに変えてもよい。候補における同義語および属性に基き候補に点数付けするのに、よく知られた任意のスコアリング方法が使用され得る。例えば、既知の類似性スコアリング技法が、異なる値のタイプ（名前、住所、電話番号など）に対して適当であるとして使用され得る。例えば、数値類似性スコアリングは、桁の転置または他の共通のユーザー入力エラーを考慮することができる。幾つかの実施例が同義語を共有しない候補のスコアにペナルティを与えることができる。スコアリングが完了した後、その点数付けされた属性が着信の属性とどれほど近く一致するかが知られ、そのスコアがより正確な候補を提供するのに使用され得る。例えば、候補のリストを所望のもっと小さいリストに狭めることができるか、さもなければ一致と確認される。このスコアは、所望の閾値一致もしくは候補を提供する、候補をマージする（例えば、着信エンティティが或る候補とマージすべきかスコアが決定する）、エンティティをスプリットする（例えば、着信エンティティが１個もしくは複数個のエンティティにスプリットすべきことを着信が明らかにする。何故ならばそのエンティティを構成する（compose）アカウントがマージ可能な一致を最早考えられないからである）、候補相互の関係を生成するなど、システム１０の他の機能で使用されてもよい。幾つかの実施例では、エンティティの実際のマージングおよびスプリッティングは、以下で説明するように同義語の加除に影響を及ぼし得るので、直ぐに行われることができる。
【００４３】
ステップ１１４では、そのプロセスが着信情報および候補情報に基づく同義語からの属性の除去を決定し、実行する。ここで説明する実施例では、その除去は、一般的になっていて、データベースから除去されている属性に基づくか、または同義語形成閾値の下に落ちている候補／属性に基づくか、またはその両方に基づく除去を含む。一般的な属性の検出は、属性が一般的になってしまい、その結果候補を見つけるのに使用されるべきでなく、同義語の部分となるべきでないような多くの異なる候補において、着信から抽出された属性のいずれかが今や生じるかを決定することを含む。１個もしくは複数個の候補またはエンティティからの属性の検出が、例えばシステム１０における１個もしくは複数個の特定の候補またはエンティティを削除するために着信からのまたは他のソースからの直接の命令に基づいて生じるかもしれない。同義語形成閾値の下に属性が落ちるというのは、着信の属性が同義語属性を有する候補のパーセンテージの数値を減じるときに生じることがあり得る。その結果、１個もしくは複数個の属性が現在ある同義語から除去される必要があるかもしれない。同義語からの属性の除去については図７に関して以下で詳細に説明する。
【００４４】
ステップ１１６では、新しい同義語（もしあれば）が発見され、システム１０に加えられる。これは属性が同義語を形成する資格があるかチェックすること、新しい同義語を候補に加えること、および／もしくは現在ある同義語に属性を加えることを含み、そして図８に関して以下で詳細に説明する。
【００４５】
ステップ１１８では、前のステップ１１４および／もしくは１１６で加除された少なくとも１個の同義語をもった候補をそのプロセスが再評価しかつ調整する。加除された同義語を含む全ての候補がシーケンスの中立性を維持するために再評価されるべきである。即ちこれらの候補はそれらの候補を取り込む次の操作のために適切となるようにできるだけ迅速に更新されることができる。ここで説明する実施例では、再評価が、ステップ１０６ないし１１６がそのような候補ごとに行われる分解サイクルを通じてその候補をランすることを取り込む。これは各候補が最近更新された同義語およびその同義語に関連付けられる属性を含むことを許容する。そのプロセスは１２０で完了する。
【００４６】
ここで説明する実施例では、同義語処理アプリケーションが受け取った着信情報に応答してリアルタイムにかつ動的に同義語が前述のように処理される。これはデータの取り入れもしくは受け取り時に同義語および候補が更新されるのを許容し、その同義語および候補に基づく後のクエリを大きくスピードアップすることができる。後のデータ・クラスタリングを行う必要がないからである。
【００４７】
図７は、図６のステップ１１４を実装するための一つの実施例の方法を示すフローチャートであり、そのステップでは着信情報に基づき同義語からの属性の除去を行う。その同義語からの属性の除去というのは、前述のように着信によって引き起こされる複数の異なる結果のうちの任意のものに基づくことができ、一般的になる属性、候補もしくはエンティティから属性の削除、および１個もしくは複数個の同義語における属性の頻度の減少を含む。候補もしくはエンティティからの属性の削除の場合には、データセットからの属性の実際の削除は、本発明のために記述され、ここでは記述しないプロセスの前、最中、もしくはその後に行われることができる。
【００４８】
１５２でそのプロセスが開始し、ステップ１５４で着信中の属性の一つまたは既に削除されたあるいはこれから削除される属性の一つ（もし適用されるなら）が選択される。その選択された属性は少なくとも一つの実在する同義語に含まれる。その選択された属性を含む全ての同義語およびその選択された属性を含む全ての候補は前のステップから知られている。
【００４９】
ステップ１５８では、そのプロセスは属性が一般的になってしまったかチェックする。一般的な属性の削除は、それが一般的になってしまい、従って候補を見つけるのに使用されるべきでない、そして同義語の一部であるべきでないといったような多くの異なる候補においてその選択された属性が生じるか決定することを含む。記述された実施例において、一般的になったものの取り扱いは、その属性を含む（図６のステップ１１０で見つかる候補のセットにおける）候補の数が所定の一般閾値を超えるかチェックすることを含む。もし候補の数がその一般閾値を超えるなら、その選択された属性は一般的になったものと考えられる。一般的な属性を決定するための他の処理あるいは代わりの処理も行うことができる。もしその属性が一般的になったと見出されれば、そのプロセスは、以下で説明するように、その同義語からその属性を除去するためのステップ１６２に続く。
【００５０】
もし属性が一般的でないと決定されるなら、プロセスはステップ１６０に続く。ステップ１６０では、その選択された属性を含む同義語ごとに、そのプロセスは、同義語を有する候補の数がその選択された属性を有する全ての候補の同義語形成閾値パーセントよりも今や少なくなっている（但し、その着信エンティティが候補として含まれる）かチェックする。その閾値パーセントは同義語を形成するのに以前幾つかのポイントで使用されたが、図８の、例えばステップ２０４および２０８において後で詳細に説明する。一実施例では、もしその着信中のその選択された属性が現存する同義語の一部であるがその同義語の全ての属性にその着信の際付随するものでないなら、その同義語におけるそのフル・セットの属性を有する候補のパーセントは減らされているかもしれず、その結果、そのフル・セットの属性は同義語としての資格がなくなる。例えば、もしその着信がその同義語に含まれる３個のうちの始めの２個の属性のみを含むなら、３個の全ての属性を有する同義語を含む候補のパーセントは今や少なくなる。他の実施例では、もしその選択された属性が１個（もしくは複数個）の候補から削除されているなら、これはその同義語を作り上げている属性のセットの候補の数（従ってその発生の数）を減少させているかもしれず、その閾値が最早合致することはない。（着信中の命令により属性のそのような削除が生じる場合には、その属性が削除されたエンティティは着信エンティティと考えることができる。）
【００５１】
もしその同義語閾値を尚も超えているなら、そのプロセスは以下で説明するステップ１６８に続く。もしその発見閾値を超えていなければ、あるいはもしステップ１５８で一般的になってしまうという属性が見つからなかったならば、そのプロセスはステップ１６２に続く。ステップ１６２では、その選択された属性がその関連付けられた同義語から除去される。これは、例えばその選択された属性のエントリおよびタイプを同義語テーブル３０中のその関連付けられた同義語識別子から除去することによって行われる。代わりに、その属性は別の時に１個もしくは複数個の同義語から除去するためにマークされたり、指定されたりする。
【００５２】
ステップ１６４では、ステップ１６２で何らかの属性を除去された各々の同義語がその除去後に唯一の属性を含むかをそのプロセスがチェックする。もしノーであれば、そのプロセスは、以下で説明するステップ１６８に続く。もし或る同義語に唯一の属性が残っているなら、ステップ１６６では例えば同義語テーブル３０からその同義語エンティティおよびその属性を除去することによって、その同義語が完全に除去される。単一の属性のみを有する同義語がその属性を用いての検索に比較して検索の量を少なくはしないので、そのような同義語は必要でなく、除去される。
【００５３】
ステップ１６８では、そのプロセスが前述のステップでまだ調べられていなかった追加の適格な属性があるかそのプロセスはチェックする。もしイエスなら、そのプロセスはステップ１５４に戻り他の属性を選択する。もしそのような全ての属性が処理されてしまうなら、そのプロセスは１７０で完了する。
【００５４】
図８は、図６のステップ１１６を実装するための実施例の方法を説明するフローチャートであり、そのステップで同義語が発見され同義語テーブルおよび候補に加えられる。そのプロセスは２００で開始し、ステップ２０２では図６のステップ１０８において決定されたような１個もしくは複数個の同義語を着信が既に含むかそのプロセスがチェックする。もしそのデータが同義語を含まないなら、そのプロセスはステップ２０４に続き、そのステップでは、考慮中の２個以上の属性のいずれかを含む属性の全ての所定の同義語形成閾値パーセントを超える属性の数においてこれらの２個以上の属性に匹敵する同じ数の属性をその着信が有するかプロセスがチェックする。その比較において使用される候補は、候補として着信エンティティを含む。ここで説明する実施例では、属性相互間の正確な一致をそのプロセスが探し求める。従ってこのステップは、同じ属性のグループもしくはセットが、異なるエンティティにおいても同義語と考えられるほどにしばしば一緒に現れるかチェックする。即ちこれらの属性は多くのエンティティにおいて一緒に現れるという点で共通の関連付けを有する。同義語閾値パーセントはシステムのユーザーまたは管理者により、必要に応じて多めのもしくは少なめの同義語が発見されるのを許容するような好みのレベルに設定されることができる。
【００５５】
例えば、同義語パーセントが７０％であり、かつ図６のステップ１１０において見出される１５個の候補のうちから１０個の候補が、考慮中の２個の特定の属性のうちの１個以上を有する。もしその２個の属性がこれらの１０個の属性（これらの属性はその着信を含む）の内の少なくとも８個で現れることが見出されるなら、その同義語閾値は越えてしまい、そして２個の属性はそれらが新しい同義語としての資格を得るとき一緒に共通にグループ化されると考えられる。
【００５６】
幾つかの実施例では、異なる組み合わせの属性が其々新しい同義語のためにテストされ得る。例えば、もし着信が３個の属性を有するなら、それは全ての３個の属性がその閾値パーセントを越える数の候補に現れるか、そしてそれがその３個の内の２個の属性の組み合わせの各々がその閾値パーセントを越える数の候補に現れるか決定され得る。かくして複数個の同義語はその着信の内の一組の属性から発見されてもよいし、また同義語がそれらの属性の内の幾つかの中でオーバーラップしていてもよい。
【００５７】
もしステップ２０４でその同義語閾値を超えなければ、そのプロセスは２１６で終了する。もし着信がその同義語閾値を超える候補の数に現れる２個以上の属性を有するなら、ステップ２０６ではこれらの属性のグループから作られた１個または複数個の新しい同義語が生成される。ここで説明する実施例では、新しい同義語を加えるということは新しい使用されていない同義語識別子を新しい同義語中の属性ごとに同義語テーブル３０中のエントリに加えること、そしてそのエントリにその関連付けられた属性を割り当てることを含む。もし属性タイプが使用されていれば、同義語中の各属性のタイプも同義語テーブル３０に加えることもできる。
【００５８】
更に、ステップ２０６では、新しい同義語として生成されたそのセットの属性を有する候補である全ての適切な候補に新しい同義語が加えられる。これは着信により生成されもしくは加えられた着信エンティティに同義語を加えることを含む。好適な実施例では、その同義語が候補に加えられるのは、同義語識別子および関連付けられた候補エンティティ識別子をエンティティ同義語テーブル３４に加えることによってである。もし異なるグループの同義語が閾値条件に合致するなら、複数個の新しい同義語を加えることができる。そのプロセスは２１６で終了する。
【００５９】
幾つかのケースでは、一つの同義語からの属性のサブセットが１個もしくは複数個の追加の同義語を形成してもよい。例えば、着信中の４個の属性がその同義語閾値を超えさせるなら、これらの４個の属性は第１の同義語の中に含まれ、その第１の同義語が適切な候補に加えられる。異なる候補はこれらの４個の属性のうちの２個のみを有するかもしれない。その場合、これらの異なる候補の数は、これらの２個の属性のみから第２の同義語が形成されるのを許容するほどに十分大きく、そしてその第２の同義語がこれらの異なる候補ならびにその第１の同義語を含む候補に加えられる。
【００６０】
一実施例では、４個の候補が特定の名前もしくは住所の属性の一方または両方を有し、候補１ないし３は全てこれらの名前および住所の属性を有し、そして同義語生成のための閾値パーセントが７６％である。かくしてこれらの属性は同義語の中に形成されなかった。何故ならばそれらが全ての候補のうちの７５％およびその閾値を超えない中でグループとして存在するからである。これらの同じ属性の両方を新しいエンティティに挿入する着信方法を受け取る。これは着信エンティティを含む時の合計５個のうちから４個にこれらの一致する属性を備えた、８０％およびその閾値を超える候補の数をもたらし、その結果、２個の属性を備えた新しい同義語が発見されそして同義語テーブル３０に加えられる。更に、候補１ないし３の各々およびその着信により生成される着信エンティティが、これらのエンティティ識別子および同義語識別子をエンティティ同義語テーブル３４に加えることによって、新しい同義語を有する。
【００６１】
ステップ２０２に戻って、もし 着信が１個もしくは複数個の現在ある同義語を既に含むなら、そのプロセスはステップ２０８に続く。ステップ２０８では拡張された同義語を生成するために、属性が現在ある同義語に非同義語属性が加えられることができるか決定される。現在ある同義語の一部でない属性が着信中に何かあるか、そしてこれらの非同義語属性が、拡張された同義語のために考えられている１個もしくは複数個の属性を有するその候補の所定の同義語閾値パーセントを超える同義語候補の数に現れる非同義語属性に一致するかを決定される。その拡張された同義語は、現在ある同義語中に何らかの非同義語属性を有するかまたは非同義語属性を有するものである。ここで、「同義語属性」は着信中に存在する同じ同義語を既に有する候補であり、従ってこの方法は、元の同義語プラス非同義語属性を有する候補の数をその閾値パーセントに比較する。前述のように、候補の数は候補としての着信エンティティを含む。その発見閾値パーセントはステップ２０４で使用されるのと同じになり得る。ここで説明する実施例では、そのプロセスは属性相互間の正確な一致を探し求めている。
【００６２】
かくして、このプロセスは、１個もしくは複数個の新しい非同義語属性の着信の挿入が、非同義語属性のための一致する候補の数をしてその閾値を超えさせるかチェックする。ステップ２０４と同様、幾つかの実施例では、その現在ある同義語と非同義語属性との異なる組み合わせがその閾値を超えるためにテストされ得る。そして複数の組み合わせがその閾値条件に合致するかもしれない。
【００６３】
もしその閾値が合致しなければ、そのプロセスはステップ２１４に続く。もしその着信が２個以上の非同義語属性を有し、その発見閾値を超える同義語候補の数に現れるなら、ステップ２１０においてその非同義語属性は、その現在ある同義語プラス加えられた候補を含む新しい拡張された同義語を生成するための適切な現在ある同義語（すなわち着信中の特定の同義語であってその一致する候補にも存在する同義語）に加えられる。ここで説明する実施例では、これは、同義語テーブル３０において現在ある同義語識別子に新しい属性を加えることによって行われる。もし属性のタイプが使用されているなら、その同義語の各々のタイプもまたその同義語テーブルに加えられることができる。
【００６４】
ステップ２１２では、その加えられた属性（およびその現在ある同義語）を有する任意の候補に新しい同義語が加えられる、ここで説明する実施例では、エンティティ同義語テーブル３４に同義語識別子および着信候補エンティティを加えることによって、その新しい同義語がその着信エンティティ（着信候補）（もし適切なら）に加えられる。図２ないし図５のテーブルに似たテーブルを用いる、ここで説明する実施例では、典型的にはそのシステムに既にストアされた他の一致する候補がエンティティ同義語テーブル３４中の（今や拡張された）同義語に既に関連付けられる。前述のステップは属性が加えられ得る着信の中の、現在ある同義語ごとに反復されることができる。
【００６５】
ステップ２１４では、ステップ２０８の条件に合致しなかった、またはステップ２１０における現在ある同義語に加えられなかった、追加の非同義語の属性が着信中にあるか、そのプロセスがチェックする。そのような非同義語の属性は現在ある同義語に加えられるべき閾値条件に合致していなかったかもしれないが、新しい同義語を形成するための閾値条件にそれ自体をおそらくは合致させてくるかもしれない。かくして、もしそのような追加の非同義語の属性があるなら、そのプロセスはステップ２０４に続く。そしてそのステップ２０４でこれらの非同義語の属性がそのステップに対し前述したように何らかの新しい同義語を形成することができるかそれらがテストされる。そのプロセスは２１６で終了する。
【００６６】
他の実施例で、前述の方法の諸ステップが異なる順序で行われ得ること、適切であれば同時に行われ得ること、あるいはまた異なる態様で組み合わされ得ることを理解されたい。例えば、図６では、ステップ１１４における同義語からの属性の除去が、新しい同義語を発見し、加えるためのステップ１１６を行うのと同時に、またはそのプロセスの一部としておよび行われることもできる。図７において、ステップ１６４の唯一の属性を同義語が含むかチェックするのは、ステップ１６２の属性の除去と同時に行われることができる。更に、他の実施例では異なるタイプの同義語形成閾値といったような変形例を使用することができる。
【００６７】
本発明の実施例は入力データの各々個別の属性でもって検索することにより大きな数の個別の検索を行うのではなく、データベースにおける一致するデータもしくは候補のデータを検索するために同義語を有利に使用することができる。すなわち任意の属性が検索されるとき、その全体の同義語が代用され得る。ここで説明する同義語は、分析論、検索エンジン、スペル・チェッカなどを含む、広範なアプリケーションで使用され得る。
【００６８】
更に、本発明の実施例は、データがデータベースの中に取り入れられもしくは挿入されている際、そして挿入されているデータならびにそのシステムに既にストアされたデータに基づいて、リアルタイムに、かつオンザフライで動的に調整される（発見されもしくは修正されまたはその両方を施される）同義語またはデータ・クラスタを提供することができる。このことは、システムの現在のデータに関連して同義語が常に更新され、かつ再評価されるのを許容する。更に、そのエンティティ・データを更新し続けるため、かつエンティティのドリフトを防止するため、入力データが取り入れられている際、同義語に関連する全てのエンティティがリアルタイムに更新されることができる。このような特徴は動的な同義語のテーブルまたは辞書が維持されることを許容し、データ・クラスタリング、または同義語形成が性的なストアされたデータに基づいて行われていた従来の方法よりも時間を節約する。例えば、データ・マイニングにおけるデータ・クラスタリングは通常は非常に遅い。しかし、本発明の実施例において可能なように、もしクラスタが、取り入れ中にリアルタイムに決定されるなら、クエリが非常に高速に後で行われることができる。
【００６９】
更に、本発明の実施例は特定の領域の知識を必要とすることなく同義語を見つけることができる。かくして複数のタイプの属性で、任意のタイプのものが単一の同義語に集められることができ、そして或るタイプのデータのための類似性技法を知る必要なしに同義語が決定されることができる。ここで説明される自動的な同義語発見は名前のコンポーネントのためだけでなく、数字や住所のコンポーネント、色、綴りのミスなど、任意のタイプの属性に使用されることができる。更に、エンティティの分解（resolution）を行うときに、特定のデータについて解析者に提供され得る増量した情報および情報のタイプは、ここで説明する同義語を用いると、非常に有用であり得る。例えば、入力の住所を有していた人々の９０％が特定の電話番号をも共有していたことをそのシステムはユーザーに通知することができる。
【００７０】
更に本発明の実施例は同義語のテーブルまたは辞書のストレージ・コストを大きく減らすことができる。何故ならば（非同義語関連処理の場合）幾つかのポイントでそのシステムにより使用されそしてそのシステムによりストアされるデータ属性のみが同義語では使用されるからである。かくして、そのエンティティに関連する同義語のみ、およびそのシステムにより使用され処理されるデータがストアされる必要があり、決して必要とされない多量の同義語属性を予めストアしておく余分のストレージ・スペースは不要である。何故ならばそのような属性は着信するデータには決して見出されず、あるいはデータベースによりストアされないからである。
【００７１】
本発明の実施例を図示の実施例に従って説明したが、当業者これらの実施例に対する変形例もあり得ること、そしてこれらの変形例が本発明の趣旨および範囲内にあることも容易に理解されよう。従って、多くの変形例が特許請求の範囲から逸れずに当業者によってなされてもよい。
【特許請求の範囲】
【請求項１】
データをクラスタリングする方法であって、
システムによりアクセス可能なデータベースにストアされたもしくはストアされるべき１個もしくは複数個のデータ属性の操作をする情報を前記システム上で受け取るステップであって、前記情報および前記操作がデータ・クラスタについて明示的に関連しない前記受け取るステップと、
前記受け取った情報に基づきデータ・クラスタを調整するステップであって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作をされる少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整するステップと
を含む方法。
【請求項２】
前記受け取った情報が、前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、前記ストアされたデータが前記システムによりアクセス可能であり、前記調整されたデータ・クラスタが新しいデータ・クラスタであり、前記調整が少なくとも１個の前記受け取ったデータ属性を含むために前記新しいデータ・クラスタを発見しかつ形成することを含む、請求項１に記載の方法。
【請求項３】
前記調整されたデータ・クラスタは前記システムによりアクセス可能な、現在ある、ストアされたデータ・クラスタであり、前記調整は前記現在あるデータ・クラスタを修正することである、請求項１に記載の方法。
【請求項４】
前記修正が前記受け取った情報に基づき、かつ前記データベース中の現在のデータに基づき前記現在あるデータ・クラスタから少なくとも１個のデータ属性を除去することを含む、請求項３に記載の方法。
【請求項５】
前記受け取った情報は前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、前記ストアされたデータが前記システムによりアクセス可能であり、前記現在あるデータ・クラスタからの前記少なくとも１個のデータ属性を除去することが、前記除去された少なくとも１個のデータ属性が一般的になったことを決定することを含む、請求項４に記載の方法。
【請求項６】
前記データ・クラスタは前記データベース中の少なくとも１個の前記操作をされたデータ属性の前記現在の発生数に基づき調整される、請求項１に記載の方法。
【請求項７】
複数個のストアされた現在あるデータ・クラスタが前記システムによりアクセス可能であり、前記現在あるデータ・クラスタのみが、前記システムにより受け取った過去の情報により操作されたデータ属性を含む、請求項１に記載の方法。
【請求項８】
複数個の現在あるデータ・クラスタがテーブルにストアされ、受け取っている情報に応答して修正される、請求項７に記載の方法。
【請求項９】
前記データ・クラスタが、前記データベースによりストアされた複数個のエンティティから少なくとも１個の候補のエンティティを見つける際に使用される同義語であり、各候補が複数個の協働するデータ属性を有する、請求項１に記載の方法。
【請求項１０】
前記データ・クラスタ中の前記複数個のデータ属性が複数の異なるタイプよりなる、請求項１に記載の方法。
【請求項１１】
前記受け取った情報が、前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、ストアされたデータが前記システムによりアクセス可能であり、前記データ・クラスタを調整するステップが、
少なくとも１個の前記受け取ったデータ属性を含む、複数個のストアされた現在あるデータ・クラスタを見つけるステップと、
各々が１個もしくは複数個の前記現在あるデータ・クラスタを含むような複数個の候補のデータ・エンティティ、ならびに各々が前記現在あるデータ・クラスタに含まれない複数個の受け取ったデータ属性のうちの任意のものを含むような複数個の候補のデータ・エンティティを見つけるステップと、
前記候補のデータ・エンティティおよび前記受け取った情報に基づき任意のデータ属性が前記現在あるデータ・クラスタから除去されるべきか決定するステップと
を含む、請求項１に記載の方法。
【請求項１２】
前記データ・クラスタを調整するステップが更に
複数個の前記受け取ったデータ属性が新しいデータ・クラスタを形成することを決定するステップと、
前記新しいデータ・クラスタ中の少なくとも１個の前記受け取ったデータ属性を含む、前記新しいデータ・クラスタ中の前記受け取ったデータ属性が前記候補の閾値パーセント数で現れることと、
更に前記新しいデータ・クラスタ中の前記データ属性を含む前記候補のデータ・エンティティの各々に前記新しいデータ・クラスタを加えるステップと
を含む、請求項１１に記載の方法。
【請求項１３】
前記データ・クラスタを調整するステップが更に
少なくとも１個の前記受け取ったデータ属性が前記受け取った情報中の現在あるデータ・クラスタに加えられるべきことを決定するステップを含み、
前記少なくとも１個の加えられたデータ属性および現在ある同義語が、
前記現在あるデータ・クラスタ中の少なくとも１個の前記受け取ったデータ属性を含むかまたは加算されるべき前記少なくとも１個の受け取ったデータ属性を含む、候補のデータ・エンティティの閾値パーセント数に現れる、請求項１１に記載の方法。
【請求項１４】
任意の属性が現在あるデータ・クラスタから除去されるべきか決定するステップが、前記受け取ったデータ属性に基づいて候補のデータ・エンティティの閾値パーセント数の下に前記候補のデータ・エンティティの数が落ちてしまったか決定するステップを含む、請求項１１に記載の方法。
【請求項１５】
新しいデータ・クラスタを加えるかまたは現在あるデータ・クラスタを少なくとも１個の調整された候補のデータ・エンティティから除去するステップ、および
少なくとも１個の調整されたデータ・クラスタがデータ・クラスタを更新したかチェックするために前記少なくとも１個の調整された候補の前記データ属性を評価するステップを更に含む、請求項１１に記載の方法。
【請求項１６】
前記システム上で情報を受け取るステップであって、前記情報はデータベースにストアされるデータ属性を有する特定のデータ・エンティティと関連付けられた複数個の受け取ったデータ属性を含み、前記データベースにストアされる１個もしくは複数個のデータ・エンティティに前記受け取ったデータ属性がストアされるべきであり、前記情報およびデータ属性が前記同義語に明示的に関連しないことを含む、前記情報を受け取るステップと、
前記受け取ったデータ属性に基づき、かつ前記現在のストアされたデータに基づき同義語を形成するステップであって、前記同義語が前記データ・エンティティに関連付けられた複数個の前記受け取ったデータ属性を含み、前記形成するステップが少なくとも１個の前記受け取った属性を含む前記データベースにおける複数個の候補のデータ・エンティティを調べるステップを含み、前記同義語を受け取っている前記情報に応答して形成されることを含む、前記同義語を形成するステップと
を更に含む、請求項１に記載の方法。
【請求項１７】
前記同義語を形成するステップが、前記１個もしくは複数個の受け取ったデータ属性が、異なるデータ・エンティティにおいて他の受け取ったデータ属性とともに十分頻度高く現れるか決定するステップを含み、前記現れるデータ属性から同義語を形成する、請求項１６に記載の方法。
【請求項１８】
請求項１ないし１７のいずれかに記載の全てのステップを実行するように適用されたプログラム・コードを含み、コンピュータ上でランされるコンピュータ・プログラム。
【請求項１９】
データをクラスタリングするためのシステムであって、
各々のデータ・エンティティが複数個のストアされたデータ属性を含む複数個のデータ・エンティティをストアするデータベースと、
システム上で情報を受け取る手段であって、前記情報が、前記受け取った情報にストアされた１個もしくは複数個の前記ストアされたデータ属性または１個もしくは複数個のデータ属性を操作し、前記情報および操作がデータ・クラスタに明示的に関連しない前記情報を受け取る手段と、
前記受け取った情報に基づきデータ・クラスタを調整する手段であって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作される少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整する手段と
を含むシステム。
【請求項２０】
データをクラスタリングする装置であって、
システムによりアクセス可能なデータベースにストアされたもしくはストアされるべき１個もしくは複数個のデータ属性の操作をする情報を前記システム上で受け取る手段であって、前記情報および前記操作がデータ・クラスタについて明示的に関連しない前記受け取る手段と、
前記受け取った情報に基づきデータ・クラスタを調整する手段であって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作をされる少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整する手段と
を含む装置。
【請求項１】
データをクラスタリングする方法であって、
システムによりアクセス可能なデータベースにストアされたもしくはストアされるべき１個もしくは複数個のデータ属性の操作をする情報を前記システム上で受け取るステップであって、前記情報および前記操作がデータ・クラスタについて明示的に関連しない前記受け取るステップと、
前記受け取った情報に基づきデータ・クラスタを調整するステップであって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作をされる少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整するステップと
を含む方法。
【請求項２】
前記受け取った情報が、前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、前記ストアされたデータが前記システムによりアクセス可能であり、前記調整されたデータ・クラスタが新しいデータ・クラスタであり、前記調整が少なくとも１個の前記受け取ったデータ属性を含むために前記新しいデータ・クラスタを発見しかつ形成することを含む、請求項１に記載の方法。
【請求項３】
前記調整されたデータ・クラスタは前記システムによりアクセス可能な、現在ある、ストアされたデータ・クラスタであり、前記調整は前記現在あるデータ・クラスタを修正することである、請求項１に記載の方法。
【請求項４】
前記修正が前記受け取った情報に基づき、かつ前記データベース中の現在のデータに基づき前記現在あるデータ・クラスタから少なくとも１個のデータ属性を除去することを含む、請求項３に記載の方法。
【請求項５】
前記受け取った情報は前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、前記ストアされたデータが前記システムによりアクセス可能であり、前記現在あるデータ・クラスタからの前記少なくとも１個のデータ属性を除去することが、前記除去された少なくとも１個のデータ属性が一般的になったことを決定することを含む、請求項４に記載の方法。
【請求項６】
前記データ・クラスタは前記データベース中の少なくとも１個の前記操作をされたデータ属性の前記現在の発生数に基づき調整される、請求項１に記載の方法。
【請求項７】
複数個のストアされた現在あるデータ・クラスタが前記システムによりアクセス可能であり、前記現在あるデータ・クラスタのみが、前記システムにより受け取った過去の情報により操作されたデータ属性を含む、請求項１に記載の方法。
【請求項８】
複数個の現在あるデータ・クラスタがテーブルにストアされ、受け取っている情報に応答して修正される、請求項７に記載の方法。
【請求項９】
前記データ・クラスタが、前記データベースによりストアされた複数個のエンティティから少なくとも１個の候補のエンティティを見つける際に使用される同義語であり、各候補が複数個の協働するデータ属性を有する、請求項１に記載の方法。
【請求項１０】
前記データ・クラスタ中の前記複数個のデータ属性が複数の異なるタイプよりなる、請求項１に記載の方法。
【請求項１１】
前記受け取った情報が、前記データベースにストアされるべき１個もしくは複数個の受け取ったデータ属性を含み、ストアされたデータが前記システムによりアクセス可能であり、前記データ・クラスタを調整するステップが、
少なくとも１個の前記受け取ったデータ属性を含む、複数個のストアされた現在あるデータ・クラスタを見つけるステップと、
各々が１個もしくは複数個の前記現在あるデータ・クラスタを含むような複数個の候補のデータ・エンティティ、ならびに各々が前記現在あるデータ・クラスタに含まれない複数個の受け取ったデータ属性のうちの任意のものを含むような複数個の候補のデータ・エンティティを見つけるステップと、
前記候補のデータ・エンティティおよび前記受け取った情報に基づき任意のデータ属性が前記現在あるデータ・クラスタから除去されるべきか決定するステップと
を含む、請求項１に記載の方法。
【請求項１２】
前記データ・クラスタを調整するステップが更に
複数個の前記受け取ったデータ属性が新しいデータ・クラスタを形成することを決定するステップと、
前記新しいデータ・クラスタ中の少なくとも１個の前記受け取ったデータ属性を含む、前記新しいデータ・クラスタ中の前記受け取ったデータ属性が前記候補の閾値パーセント数で現れることと、
更に前記新しいデータ・クラスタ中の前記データ属性を含む前記候補のデータ・エンティティの各々に前記新しいデータ・クラスタを加えるステップと
を含む、請求項１１に記載の方法。
【請求項１３】
前記データ・クラスタを調整するステップが更に
少なくとも１個の前記受け取ったデータ属性が前記受け取った情報中の現在あるデータ・クラスタに加えられるべきことを決定するステップを含み、
前記少なくとも１個の加えられたデータ属性および現在ある同義語が、
前記現在あるデータ・クラスタ中の少なくとも１個の前記受け取ったデータ属性を含むかまたは加算されるべき前記少なくとも１個の受け取ったデータ属性を含む、候補のデータ・エンティティの閾値パーセント数に現れる、請求項１１に記載の方法。
【請求項１４】
任意の属性が現在あるデータ・クラスタから除去されるべきか決定するステップが、前記受け取ったデータ属性に基づいて候補のデータ・エンティティの閾値パーセント数の下に前記候補のデータ・エンティティの数が落ちてしまったか決定するステップを含む、請求項１１に記載の方法。
【請求項１５】
新しいデータ・クラスタを加えるかまたは現在あるデータ・クラスタを少なくとも１個の調整された候補のデータ・エンティティから除去するステップ、および
少なくとも１個の調整されたデータ・クラスタがデータ・クラスタを更新したかチェックするために前記少なくとも１個の調整された候補の前記データ属性を評価するステップを更に含む、請求項１１に記載の方法。
【請求項１６】
前記システム上で情報を受け取るステップであって、前記情報はデータベースにストアされるデータ属性を有する特定のデータ・エンティティと関連付けられた複数個の受け取ったデータ属性を含み、前記データベースにストアされる１個もしくは複数個のデータ・エンティティに前記受け取ったデータ属性がストアされるべきであり、前記情報およびデータ属性が前記同義語に明示的に関連しないことを含む、前記情報を受け取るステップと、
前記受け取ったデータ属性に基づき、かつ前記現在のストアされたデータに基づき同義語を形成するステップであって、前記同義語が前記データ・エンティティに関連付けられた複数個の前記受け取ったデータ属性を含み、前記形成するステップが少なくとも１個の前記受け取った属性を含む前記データベースにおける複数個の候補のデータ・エンティティを調べるステップを含み、前記同義語を受け取っている前記情報に応答して形成されることを含む、前記同義語を形成するステップと
を更に含む、請求項１に記載の方法。
【請求項１７】
前記同義語を形成するステップが、前記１個もしくは複数個の受け取ったデータ属性が、異なるデータ・エンティティにおいて他の受け取ったデータ属性とともに十分頻度高く現れるか決定するステップを含み、前記現れるデータ属性から同義語を形成する、請求項１６に記載の方法。
【請求項１８】
請求項１ないし１７のいずれかに記載の全てのステップを実行するように適用されたプログラム・コードを含み、コンピュータ上でランされるコンピュータ・プログラム。
【請求項１９】
データをクラスタリングするためのシステムであって、
各々のデータ・エンティティが複数個のストアされたデータ属性を含む複数個のデータ・エンティティをストアするデータベースと、
システム上で情報を受け取る手段であって、前記情報が、前記受け取った情報にストアされた１個もしくは複数個の前記ストアされたデータ属性または１個もしくは複数個のデータ属性を操作し、前記情報および操作がデータ・クラスタに明示的に関連しない前記情報を受け取る手段と、
前記受け取った情報に基づきデータ・クラスタを調整する手段であって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作される少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整する手段と
を含むシステム。
【請求項２０】
データをクラスタリングする装置であって、
システムによりアクセス可能なデータベースにストアされたもしくはストアされるべき１個もしくは複数個のデータ属性の操作をする情報を前記システム上で受け取る手段であって、前記情報および前記操作がデータ・クラスタについて明示的に関連しない前記受け取る手段と、
前記受け取った情報に基づきデータ・クラスタを調整する手段であって、前記データ・クラスタが複数個のデータ属性を含むとともに、前記受け取った情報により操作をされる少なくとも一つのデータ属性を含み、前記情報を受け取るのに応答して前記データ・クラスタが調整されるようにした前記調整する手段と
を含む装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１１−５０９４７２（Ｐ２０１１−５０９４７２Ａ）
【公表日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２０１０−５４１７６６（Ｐ２０１０−５４１７６６）
【出願日】平成２１年１月５日（２００９．１．５）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０５００５７
【国際公開番号】ＷＯ２００９／０８７１３８
【国際公開日】平成２１年７月１６日（２００９．７．１６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年１月５日（２００９．１．５）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０５００５７
【国際公開番号】ＷＯ２００９／０８７１３８
【国際公開日】平成２１年７月１６日（２００９．７．１６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]