JP2010541079A

JP2010541079A - 複数言語によるデータ記録を関連付ける方法およびシステム

Info

Publication number: JP2010541079A
Application number: JP2010527206A
Authority: JP
Inventors: ダグラススコットハーガー，; スコットシューマッハー，
Original assignee: イニシエイトシステムズ，インコーポレイテッド
Priority date: 2007-09-28
Filing date: 2008-09-26
Publication date: 2010-12-24
Anticipated expiration: 2028-09-26
Also published as: CN101884039A; AU2008304255B2; US8417702B2; EP2198374A1; EP2198374A4; BRPI0817530B1; CN101884039B; CA2701043A1; JP5306359B2; US20090089332A1; BRPI0817530A2; WO2009042931A1; AU2008304255A1; CA2701043C

Abstract

本明細書で開示される実施形態は、単一ハブ内で複数言語によるデータ記録を関連付けるためのシステムおよび方法を提供する。記録は、ハブに連結された情報源から入ってくると、コア層において特定の言語と関連付けられる。ハブは、各言語を１対１でメンバー型に論理的に対応づける。特定のメンバー型の各データ記録については、導出層において標準化およびバケッティングを行うために、一意の導出コードが利用される。異なる言語によるデータ記録が同じ統計的意味を有することができるように、言語の豊富さの平衡を保つために、ウエートが使用されてもよい。属性がデータ記録の言語に関して標準化されるため、データ記録とともに、適切な言語またはスクリプトを渡すことができる。次いで、ハブは、実体層における実体処理のために、データ記録を最適アルゴリズムに一致させることができる。

Description

（関連出願の相互参照）
本出願は、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＡＳＳＯＣＩＡＴＩＮＧＤＡＴＡＲＥＣＯＲＤＳＩＮＭＵＬＴＩＰＬＥＬＡＮＧＵＡＧＥＳ」と題された２００７年９月２８日出願の米国仮出願第６０／９９７，０２５号の優先権を主張し、その全体が本明細書に参考として援用される。本出願は、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＭＡＮＡＧＩＮＧＥＮＴＩＴＩＥＳ」と題された２００８年３月２７日出願の米国特許出願第１２／０５６，７２０号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＡＲＳＩＮＧＬＡＮＧＵＡＧＥＳ」と題された２００７年１２月３１日出願の米国特許出願第１１／９６７，５８８号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＩＮＤＥＸＩＮＧ，ＲＥＬＡＴＩＮＧＡＮＤＭＡＮＡＧＩＮＧＩＮＦＯＲＭＡＴＩＯＮＡＢＯＵＴＥＮＴＩＴＩＥＳ」と題された２００７年９月２８日出願の米国特許出願第１１／９０４，７５０号、「ＨＩＥＲＡＲＣＨＹＧＬＯＢＡＬＭＡＮＡＧＥＭＥＮＴＳＹＳＴＥＭＡＮＤＵＳＥＲＩＮＴＥＲＦＡＣＥ」と題された２００７年９月１４日出願の米国特許出願第１１／９０１，０４０号、「ＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤＦＯＲＡＵＴＯＭＡＴＩＣＷＥＩＧＨＴＧＥＮＥＲＡＴＩＯＮＦＯＲＰＲＯＢＡＢＩＬＩＳＴＩＣＭＡＴＣＨＩＮＧ」と題された２００７年６月１日出願の米国特許出願第１１／８０９，７９２号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＡＧＲＡＰＨＩＣＡＬＵＳＥＲＩＮＴＥＲＦＡＣＥＦＯＲＣＯＮＦＩＧＵＲＡＴＩＯＮＯＦＡＮＡＬＧＯＲＩＴＨＭＦＯＲＴＨＥＭＡＴＣＨＩＮＧＯＦＤＡＴＡＲＥＣＯＲＤＳ」と題された２００７年２月５日出願の米国特許出願第１１／７０２，４１０号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＩＮＤＥＸＩＮＧＩＮＦＯＲＭＡＴＩＯＮＡＢＯＵＴＥＮＴＩＴＩＥＳＷＩＴＨＲＥＳＰＥＣＴＴＯＨＩＥＲＡＲＣＨＩＥＳ」と題された２００７年１月２２日出願の米国特許出願第１１／６５６，１１１号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２２，２２３号、および「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＢＵＳＩＮＥＳＳＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２１，９２８号にも関連している。本段落で参照されるすべての出願はその全体が本明細書にあらゆる目的のために援用される。

（技術分野）
本開示は、概して、データ記録を関連付けることに関し、より具体的には、これらのデータ記録が関連付けられてもよいように、同じ実体に関する情報を含有してもよい、データ記録を識別することに関する。さらに具体的には、本明細書で開示される実施形態は、複数言語によるデータ記録の関連付けに関する。

（背景）
今日および現在の時代では、事業の圧倒的多数が、在庫、顧客、製品等の、運営の種々の局面に関する甚大な量のデータを保持している。人、製品、部品、または他のものに関するデータは、コンピュータデータベース等のデータ蓄積にデジタル形式で記憶されてもよい。これらのコンピュータデータベースは、実体に関するデータが迅速にアクセスされることを可能にし、データが同じ実体に関するデータの他の関連部分と相互参照されることを可能にする。データベースはまた、同じ実体に関する種々のデータ蓄積からのデータ記録が相互と関連付けられてもよいように、個人がデータベースに問い合せを行い、特定の実体に関するデータ記録を見出すことも可能にする。

しかしながら、データ蓄積は、データ蓄積内の実体に関する正しいデータを見出す能力を制限する場合がある、いくつかの制限を有する。データ蓄積内の実データは、データを入力した個人または元のデータソースと同じくらい正確であるにすぎない。したがって、例えば、個人の名字のつづりを誤った、または社会保障番号が不正確に入力された等のため、データ蓄積へのデータの入力における間違いは、データベース中の実体に関するデータの検索に、実体に関する関連データを見落とさせる場合がある。多くのこれらの種類の問題を想像することができ、いくつかのデータ記録が同じ実体に関する情報を含有してもよいように、データベース内にすでに記録を有する実体に対する２つの別個の記録が作成され得るが、例えば、２つのデータ記録に含有される名前または識別番号は、同じ実体を参照するデータ記録を相互に関連づけることが困難であり得るように、異なり得る。

多数のデータ記録を含有する１つ以上のデータ蓄積を運営する事業にとって、各データベース内および間で特定の実体に関する関連情報を見つける能力は、非常に重要であるが、容易には得られない。再度、任意の情報源におけるデータの入力のあらゆる間違い（無制限に、同じ実体に対する２つ以上のデータの作成を含む）は、特定の実体のデータがデータベース中で検索される時に、関連データを見落とさせる場合がある。加えて、複数の情報源を伴う場合には、情報源の各々が、データベース間でデータを見出す過程をさらに複雑にする場合がある、わずかに異なるデータ構文または形式を有する場合がある。データ記録中で参照される実体を適正に識別し、医療分野での実体に関する全データ記録を見つける必要性の一例としては、特定の医療機関と関連付けられた多数の異なる病院が、患者に関する情報を含有する１つ以上の情報源を有してもよく、医療機関が、病院の各々からマスターデータベースの中へ情報を収集するものである。同じ患者に関する情報源の全てからのデータ記録を結び付け、病院の記録の全てにおいて特定の患者の情報の検索を可能にすることが必要である。

そのようなデータベースの中で実体に関する関連データの全てを見出す能力を制限する、いくつかの問題がある。１つ以上の情報源から受信された別個のデータ記録の結果として、複数のデータ記録が特定の実体に存在してもよく、それはデータ断片化と呼ばれ得る問題につながる。データ断片化の場合、マスターデータベースのクエリが、特定の実体に関する関連情報の全てを回収しない場合がある。加えて、上記で説明されるように、データ入力中に生じた誤字により、クエリが実体に関する何らかの関連情報を見落とす場合があり、それはデータのアクセス不可能性の問題につながる。加えて、大型データベースは、Ｓｍｉｔｈという名字およびＪｉｍという名前の人々の複数の記録等の、同一と思われるデータ記録を含有する場合がある。データベースのクエリは、これらのデータ記録の全てを回収し、データベースにクエリを行った個人は、しばしば、間違ったデータ記録かもしれない、回収されるデータ記録のうちの１つをランダムに選択する場合がある。個人はしばしば、通常は、記録のうちのどれが適切であるかを決定しようとしない場合がある。このことは、正しいデータ記録が利用可能である時さえ、回収されている間違った実体のデータ記録につながり得る。これらの問題は、データベース内で特定の実体の情報を見つける能力を制限する。

見直さなければならないデータの量を低減し、ユーザが間違ったデータ記録を選ぶことを防止するために、同じ実体に関する情報を含み得る種々の情報源から、データ記録を識別し、関連付けることも望ましい。データベース内の重複データ記録を見つけ、これらの重複データ記録を削除する、従来のシステムがあるが、これらのシステムは、相互と実質的に同一であるデータ記録しか見つけない場合がある。したがって、これらの従来のシステムは、例えば、わずかに異なる名字を伴う２つのデータ記録が、それでもなお同じ実体に関する情報を含有するかどうかを決定することができない。加えて、これらの従来のシステムは、複数の異なる情報源からデータ記録を指標化し、同じ実体に関する情報を含有する１つ以上の情報源内でデータ記録を見つけ、これらのデータ記録をともに結び付けようとしない。その結果として、これらのデータ記録の属性間の不一致にもかかわらず、同じ実体に関する複数の情報源からのデータ記録を関連付けることができ、まとめてこれらの種々のデータ記録からの情報を集合させ、提示できることが望ましいであろう。しかしながら、実践では、複数の情報源から情報の正確で統一された見方を提供することが極めて難しくなり得る。データ記録が複数言語によるものである場合、課題はさらに手強くなり得る。

種々のソースからのデータ記録が、形式およびそれらが含有するデータの両方で異なる場合があるため、データ処理システムの構成は、非常に困難な作業を提示する場合がある。部分的には、構成過程が、データ記録の関連付けに利用されているシステムのアーキテクチャおよび能力の多大な専門知識、加えて、データ記録を関連付けるために使用されるアルゴリズムの結果として生じる構成が所望の結果をもたらすことを確実にするように、大規模な分析および細部への細心の注意を必要とする、手動集中作業となる場合があるため、これらの困難が引き起こされる。

これらの困難は、多くの場合、種々のデータソースの中のデータ記録が異なる言語による場合があるという事実によって、さらに悪化する場合がある。場合によっては、データ記録の属性は、ラテンアルファベットを全く使用しない言語による場合がある。いくつかの言語は、必ずしもラテンアルファベットで書かれた言語の規則、変化系列、または慣習に従うとは限らず、これらの言語による属性が構文解析しにくくなる。したがって、実施または利用される種々のアルゴリズムまたは比較は、異なる言語によるデータ記録を比較するために調整されなければならない場合がある。しかしながら、どのアルゴリズム、比較等が、どのデータ記録と併せて利用されるべきかを決定することは、困難な場合がある。したがって、データ記録が種々の異なる言語によるものであってもよい、種々の情報源の中で、これらのデータ記録を取得し、関連付けるためのシステムおよび方法の必要性がある。

（本開示の概要）
本明細書で開示される実施形態は、クエリに応じて、ハブが、複数言語によるデータ記録を検索し、これらのデータ記録が言語特有の方法でどのように関連付けられるべきかを決定し、それに応じて適時かつ正確に応答を準備することができるように、単一ハブ内で複数言語によるデータ記録を検索し、関連付けることを促進するように、基本的解決法を提供する。

より具体的には、各記録は、入ってくると、ハブのコア層において特定の言語と関連付けられる。しばしば、記録の言語は、既知であるか、または容易に決定することができる。そうでなければ、デフォルト言語が割り当てられてもよい。ハブにおいて、各言語は、メンバー型に１対１で論理的に対応づけられる。いくつかの実施形態では、複数言語によるデータ記録は、ハブにおける言語定義内で属性の型を共有することができる。

特定のメンバー型の各データ記録については、ハブの導出層において標準化およびバケッティング（候補選択）を行うために、一意の導出コードが利用される。一意の導出コードは、特定のメンバー型に論理的に対応づけられる特有の言語にとって一意であるという意味で、一意である。導出コードは、言語標準化、音訳標準化等の１つ以上の標準化技法を利用してもよい。標準化が言語特有となり得る一方で、バケッティングは言語非依存型となり得る。一例として、日本語特有の標準化を、図９−１３を参照して本明細書で説明する。次いで、標準化されたトークンを伴う、構文解析された日本語名が、図１４−１９を参照して本明細書で説明されるように、言語非依存型バケッティング過程に通される。

バケッティングまたは候補選択過程は、一式のデータ記録の１つ以上の属性がさらなる比較を必要とするほど同様であるかどうかを決定するように、それらの比較を備えてもよい。そうであれば、それらがどのように結び付けられる、または関連付けられるべきかについて、さらなる決定が行われる。図４−８を参照して以下で説明されるように、このより詳細な比較は、１つの記録（例えば、既存の記録）の一式の属性の各々を、他の記録（例えば、新規の記録）における対応する属性と比較することを必要として、その属性に対するウエートを生成してもよい。次いで、２つの記録が結び付けられるべきかどうか、およびどのように結び付けられるべきかを決定するように閾値と比較することができる、全体的ウエートを生成するように、一式の属性の各々に対するウエートが合計されてもよい。

他言語ハブとの関連で、異なる言語による２つのデータ記録が同じ統計的意味を有することができるように、自動的に言語の豊富さの平衡を保つために、ウエートを使用することができる。このように、異なる言語と関連付けられたデータ記録は、ハブの実体層において、単一の実体に、または同記録の言語実体に結び付けられてもよい。場合によっては、ハブのコア層における異なる言語と関連付けられたデータ記録が、実体層における複数の実体に結び付けられてもよいように、異なる言語からのデータ記録間の関係が識別される必要があってもよい。データ記録の全ての属性が、そのデータ記録の優勢な言語に関して適切に標準化されるため、ハブは、最適アルゴリズムを知的かつ自動的に一致させ、実体層において個々の言語による実体を処理する。言い換えれば、記録とともに、適切な言語またはスクリプトを渡すことができるため、ハブにおける実体処理のために、記録を適切なアルゴリズム経路へ「送る」ことができる。

したがって、本明細書で開示される実施形態は、単一ハブ内で種々の言語によるデータ記録を結び付けることができる。本開示の他の特徴、利点、および目的は、以下の説明および添付図面と併せて考慮すると、より良好に認識および理解されるであろう。

本明細書に付随し、その一部を形成する図面は、本開示のある局面を示すように含まれる。本開示のより明確な印象、ならびに本開示が提供されるシステムの構成要素および動作は、図面で示される、例示的であり、したがって非限定的な実施形態を参照することによって、より容易に明白となるであろう。可能な限り、同じまたは類似特徴（要素）を指すために、同じ参照番号が図面の全体を通して使用される。図面は、必ずしも一定の縮尺で描かれるとは限らない。
図１は、実体処理システムの一実施形態の基礎構造例を示す。図２Ａおよび２Ｂは、データ記録の２つの実施形態の表現を示す。図２Ａおよび２Ｂは、データ記録の２つの実施形態の表現を示す。図３は、データ記録を比較する、一実施形態のフロー図を示す。図４は、データ記録の属性を比較する方法の一実施形態のフロー図を示す。図５Ａおよび５Ｂは、２つの属性に対するウエートを決定する方法の一実施形態のフロー図を示す。図５Ａおよび５Ｂは、２つの属性に対するウエートを決定する方法の一実施形態のフロー図を示す。図６は、ウエートの計算で使用される値を決定する方法の一実施形態のフロー図を示す。図７は、本開示の一実施形態の用途の例を説明する際に使用するためのテーブルの例を示す。図８Ａおよび８Ｂは、本開示の一実施形態の用途の例を説明する際に使用するためのテーブルの例を示す。図８Ａおよび８Ｂは、本開示の一実施形態の用途の例を説明する際に使用するためのテーブルの例を示す。図９は、アジア言語を構文解析する、一実施形態のフロー図を示す。図１０は、いくつかの繁体字およびそれらの簡体の均等物の例を示す。図１１は、修飾語句または他の未グループ化文字をグループ化する例を示す。図１２は、本明細書で開示される構文解析の一実施形態がサンプルセットから各名前を作成することができる、トークンの数の統計値をグラフに描く、ヒストグラムを示す。図１３は、図１２の構文解析されたトークンの文字長の分布をグラフに描く、ヒストグラムを示す。図１４は、構文解析および翻訳後の文字の数の分布を示す。図１５は、図１４のサンプルからの、日本語の２０文字およびそれらの頻度を記載する。図１６は、図１４のサンプルからの元のトークンの分布、およびコード化されたトークンの分布を示す。図１７は、元の構文解析された名前、および対応するバケットアイテムの例を示す。図１８Ａおよび１８Ｂは、名前のバケッティングの言語非依存型方法の例を示す。図１８Ａおよび１８Ｂは、名前のバケッティングの言語非依存型方法の例を示す。図１９は、一緒に定性的にバケットするメンバーの数を示す、プロット図である。図２０は、他言語アイデンティティハブの実装例の一実施形態を示す。図２１は、図２０の実装例をより詳細に示す。

（詳細な説明）
好ましい実施形態、ならびにその種々の特徴および有利な詳細を、添付図面で示される例を参照して、より完全に説明する。本開示の詳細を不必要に分かりにくくしないよう、プログラミングおよびデータ処理技法を含む、周知のコンピュータハードウェアおよびソフトウェアの説明は省略する。しかしながら、当業者であれば、本開示の好ましい実施形態を開示する一方で、詳細な説明および具体例が、限定としてではなく例示のみとして挙げられることを理解するべきである。基礎的発明概念の範囲内の種々の置換、修正、追加、または再構成が、本開示を読んだ後に当業者にとって明白となるであろう。

本明細書で開示されるいくつかの実施形態は、本明細書に参考として援用される、１９９９年１１月２３日発行の米国特許第５，９９１，７５８号で説明されているように、異なる情報源からの実体に関する情報を指標化するシステムおよび方法の実施形態を活用することができる。本明細書で開示されるいくつかの実施形態は、本明細書に参考として援用される、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＩＮＤＥＸＩＮＧＩＮＦＯＲＭＩＯＮＡＢＯＵＴＥＮＴＩＴＩＥＳＷＩＴＨＲＥＳＰＥＣＴＴＯＨＩＥＲＡＲＣＨＩＥＳ」と題された２００７年１月２２日出願の上記で参照した米国特許出願第１１／６５６，１１１号で説明されているように、階層について、実体に関する情報を指標化する実体処理システムおよび方法の実施形態を活用することができる。

図１は、実体処理システム３０の一実施形態の基礎構造例を示す、ブロック図である。実体処理システム３０は、１つ以上の情報源３４、３６、３８からの１つ以上の実体についてのデータ記録に関するデータを処理、更新、または記憶し、複数のオペレータ４０、４２、４４からのコマンドまたはクエリに応答する、アイデンティティハブ３２を含んでもよく、その場合、オペレータは、人間のユーザおよび／または情報システムであってもよい。アイデンティティハブ３２は、単一の情報源からのデータ記録、または示されるように、複数の情報源からのデータ記録とともに動作してもよい。アイデンティティハブ３２の実施形態を使用して追跡される実体は、例えば、病院内の患者、医療制度の参加者、倉庫の中の部品、または、データ記録およびそれと関連付けられたデータ記録に含有される情報を有してもよい、任意の他の実体を含んでもよい。アイデンティティハブ３２は、アイデンティティハブ３２の機能を果たすように１つ以上のコンピュータ可読記憶媒体上に記憶されたコンピュータ可読命令（例えば、ソフトウェアアプリケーション）を実行する、少なくとも１つの中央処理装置（ＣＰＵ）４５を伴う１つ以上のコンピュータシステムであってもよい。アイデンティティハブ３２はまた、当業者によって理解されるように、ハードウェア回路、またはソフトウェアおよびハードウェアの組み合わせを使用して実装されてもよい。

図１の実施例では、アイデンティティハブ３２は、情報源３４、３６、３８からデータ記録を受信し、ならびに、情報源３４、３６、３８に訂正したデータを書き込み直してもよい。情報源３４、３６、３８に伝達される訂正したデータは、正しかった情報を含んでもよいが、データ記録の中の固定情報に関する情報、および／またはデータ記録間の結び付きに関する情報を変更している。

加えて、オペレータ４０、４２、４４のうちの１つは、アイデンティティハブ３２にクエリを伝送し、アイデンティティハブ３２からクエリへの返答を受信してもよい。情報源３４、３６、３８は、例えば、同じ実体に関するデータ記録を有してもよい、異なるデータベースであってもよい。例えば、医療分野では、各情報源３４、３６、３８は、医療機関の中の特定の病院と関連付けられてもよく、医療機関は、ロサンゼルスの患者のデータ記録が、その同じ患者が休暇中であり、かつニューヨークの病院に入院する時に見つけられてもよいように、複数の病院と関連付けられたデータ記録を関係付けるためにアイデンティティハブ３２を使用してもよい。アイデンティティハブ３２は、中心位置に位置してもよく、情報源３４、３６、３８およびユーザ４０、４２、４４は、アイデンティティハブ３２から遠隔に位置してもよく、例えば、インターネット、または広域ネットワーク、イントラネット、無線ネットワーク、専用ネットワーク等の任意の他の種類の通信ネットワーク等の、通信リンクによって、アイデンティティハブ３２に接続されてもよい。

いくつかの実施形態では、アイデンティティハブ３２は、アイデンティティハブ３２における完全データ記録を記憶する、独自のデータベースを有してもよい。いくつかの実施形態では、アイデンティティハブ３２が、必要な時に情報源３４、３６、３８から全データ記録を回収することができるように、アイデンティティハブ３２はまた、データ記録（例えば、特定のデータソース３４、３６、３８の中の住所）または完全データ記録を備えるデータフィールドの任意の部分を識別するのに十分なデータを含有するのみであってもよい。アイデンティティハブ３２は、実体識別子、または実データ記録とは別の連想データベースを利用して、同じ実体に関する情報を含有するデータ記録をともに結び付けてもよい。したがって、アイデンティティハブ３２は、１つ以上の情報源３４、３６、３８の中のデータ記録間の結び付きを維持してもよいが、必ずしも実体の単一の均一データ記録を維持するとは限らない。

いくつかの実施形態では、アイデンティティハブ３２は、データ記録（オペレータから、またはデータソース３４、３６、３８から受信される）を情報源３４、３６、３８の中の他のデータ記録と比較して、ともに結び付けられるべきデータ記録を識別することによって、情報源３４、３６、３８の中のデータ記録を結び付けてもよい。この識別過程は、データ記録の属性のうちの１つ以上と他のデータ記録の類似属性との比較を必要としてもよい。例えば、１つの記録と関連付けられた名前の属性が、他のデータ記録の名前と比較されてもよく、社会保障番号が別の記録の社会保障番号と比較されてもよい等である。このように、結び付けられるべきデータ記録が識別されてもよい。

情報源３４、３６、３８およびオペレータ４０、４２、４４は、同様の、または異なる機関および／または所有者と提携してもよく、相互から物理的に離れ、および／または遠隔にあってもよいことが、当業者にとって明白になるであろう。例えば、情報源３４が、１つの医療ネットワークによって運営されるロサンゼルスの病院と提携してもよい一方で、情報源３６は、おそらくフランスの企業が所有する別の医療ネットワークによって運営されるニューヨークの病院と提携してもよい。したがって、情報源３４、３６、３８からのデータ記録は、異なる形式、異なる言語等であってもよい。

このことは、データ記録例の２つの実施形態を示す、図２Ａおよび２Ｂを参照して、より明確に示されてもよい。これらのデータ記録２００、２０２の各々は、データ記録の各々の一式の属性に対応する、一式のフィールド２１０を有する。例えば、記録２００の各々の属性のうちの１つは、名前であってもよく、別の属性は、納税者番号等であってもよい。属性は、データ記録２００、２０２の複数のフィールド２１０を備えてもよいことが明白となるであろう。例えば、データ記録２０２の住所の属性は、それぞれ、通り、市、および州のフィールドである、２１０ｃ、２１０ｄ、および２１０ｅを備えてもよい。

しかしながら、データ記録２００、２０２の各々は、異なる形式を有してもよい。例えば、データ記録２０２が「保険業者」の属性に対するフィールド２１０を有してもよい一方で、データ記録２００にはそのようなフィールドがなくてもよい。また、同様の属性が異なる形式を有してもよい。例えば、記録２０２における名前のフィールド２１０ｂが、フルネームの入力を受け入れてもよい一方で、記録２００における名前のフィールド２１０ａは、制限された長さの名前の入力を可能にするように設計されてもよい。そのような不一致は、２つ以上のデータ記録（例えば、データ記録の属性）を比較して、結び付けられるべきデータ記録を識別する時に、問題となる場合がある。例えば、「ＢｏｂｓＦｌｏｗｅｒＳｈｏｐ」という名前は、「ＢｏｂｓＶｅｒｙＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐｐｅ」と同様であるが、厳密に同じではない。さらに、データ記録のデータを入力する際の誤字または間違いも、データ記録の比較、したがって、その結果に影響を及ぼす場合がある（例えば、「Ｇｌｏｗｅｒ」が「Ｆｌｏｗｅｒ」という言葉を入力する際の誤字に起因した、「ＢｏｂｓＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐ」という名前の「ＢｏｂｓＰｒｅｔｔｙＧｌｏｗｅｒＳｈｏｐ」との比較）。

データ記録における事業名は、それらの性質の結果として、多数のかなり特有の問題を提示する場合がある。いくつかの事業名が非常に短くなり得る（例えば、「Ｑｕｉｃｋ−Ｅ−Ｍａｒｔ」）一方で、他の事業名は非常に長くなり得る（例えば、「ＳａｎＦｒａｎｃｉｓｃｏ’ｓＢｅｓｔＣｏｆｆｅｅＳｈｏｐ」）。加えて、事業名は、同様の言葉（例えば、「Ｓｈｏｐ」、「Ｉｎｃ．」、「Ｃｏ．」）を頻繁に使用する場合があり、それは、同じ言語によるデータ記録を比較する時に、これらの名前を比較する発見的解決法で重視されるべきではない。さらに、頭字語が事業名で頻繁に使用され、例えば、「ＮｅｗＹｏｒｋＣｉｔｙＢａｇｅｌ」と名付けられた事業は、「ＮＹＣＢａｇｅｌ」としてデータ記録に頻繁に入力される場合がある。

さらに以下で詳細に説明されるように、本明細書で開示されるアイデンティティハブ３２の実施形態は、事業名を比較する時に、これらの特有の特性を考慮に入れることができる、アルゴリズムを採用する。具体的には、アイデンティティハブ３２によって採用される、いくつかのアルゴリズムは、頭字語をサポートし、事業名の中のある言葉の頻度を考慮に入れ、事業名内のトークンの順序付けを考慮する（例えば、「ＣｌｉｎｉｃｏｆＡｕｓｔｉｎ」という名前は、「ＡｕｓｔｉｎＣｌｉｎｉｃ」と事実上同一であると見なされている場合がある）。いくつかのアルゴリズムは、異なる記録における名前の比較（例えば、類似性）に基づいてウエートを生成するために、種々の音声比較方法、名前のトークンの頻度、イニシャルの一致、ニックネームの一致等に基づくウエートを含む、種々の名前比較技法を利用し、その場合、このウエートは、２つの記録が結び付けられるべきかどうかを決定する際に利用することができる。いくつかの実施形態では、各記録の名前の属性のトークンは、トークンを一致させる方法論を使用して、相互に対して比較される（例えば、トークンが正確に一致した場合、音声学的に一致した場合等）。次いで、決定された一致に基づいて、これらの一致にウエートを与えることができる（例えば、完全な一致には第１のウエートが与えられる一方で、ある種類のイニシャルの一致には第２のウエートが与えられる、等）。次いで、２つのデータ記録の名前の属性間の一致の程度に対する全体的ウエートを決定するように、これらのウエートを集約することができる。好適なウエート生成方法論の例示的実施形態は、本明細書に参考として援用される、「ＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤＦＯＲＡＵＴＯＭＡＴＩＣＷＥＩＧＨＴＧＥＮＥＲＡＴＩＯＮＦＯＲＰＲＯＢＡＢＩＬＩＳＴＩＣＭＡＴＣＨＩＮＧ」と題された２００７年６月１日出願の上記で参照した米国特許出願第１１／８０９，７９２号で説明されている。好適な名前比較技法の例示的実施形態は、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された２００６年９月１５日出願の上記で参照した米国特許出願第１１／５２２，２２３号、および「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＢＵＳＩＮＥＳＳＮＡＭＥＳ」と題された２００６年９月１５日出願の上記で参照した米国特許出願第１１／５２１，９２８号で説明されており、その両方は、本明細書に参考として援用される。

図３は、同じ実体に関する記録を識別する方法論の例を示す。ステップ３１０では、一式のデータ記録が、評価のためにアイデンティティハブ３２において転送されるか、または引き抜かれてもよい。これらのデータ記録は、例えば、一式の既存のデータ記録（例えば、情報源３４、３６、３８の中に既に存在してもよい、または、アイデンティティハブ３２に提供されてもよい）と比較するための、例えば、１つ以上の新規データ記録を含んでもよい。ステップ３２０では、比較のためのデータ記録が、すでに標準化されていなければ標準化されてもよい。この標準化は、データ記録がその元の形式から標準形式に変換されるように、データ記録の属性の標準化を備えてもよい。このように、異なるデータ記録の類似属性間の後続の比較が、属性およびデータ記録の両方の標準形式に従って行われてもよい。比較されるデータ記録の属性の各々は、異なる形式、異なる一式の語義、語彙等に従って、標準化またはトークン化されてもよく、その対応する標準形態への各属性の標準化は、別個の機能によって達成されてもよいことが、当業者にとって明白となるであろう。したがって、データ記録の各々は、データ記録の種々の属性の標準化を通して、標準形式に標準化されてもよく、各属性は、対応する機能によって標準化される（これらの属性標準化機能は、当然ながら、複数の種類の属性を標準化するように動作可能であってもよい）。

例えば、データ記録２００の名前の属性のフィールド２１０ａは、名前の属性に対する一式のトークン（例えば、「Ｂｏｂｓ」、「Ｐｒｅｔｔｙ」、「Ｆｌｏｗｅｒ」、および「Ｓｈｏｐ」）を生じるように評価されてもよく、これらのトークンは、標準化された属性が、名前の属性を備えるトークンを生成するように以降で構文解析されてもよいように、標準化された属性を生じるように、ある形態に従って連結させることができる（例えば、「ＢＯＢＳ：ＰＲＥＴＴＹ：ＦＬＯＷＥＲ：ＳＨＯＰ」）。別の例として、名前が標準化されると、連続した単一トークンをトークンに合体することができ（例えば、Ｉ．Ｂ．Ｍ．がＩＢＭになる）、置換を行うことができる（例えば、「Ｃｏ．」が「Ｃｏｍｐａｎｙ」に置換され、「Ｉｎｃ．」が「Ｉｎｃｏｒｐｏｒａｔｅｄ」に置換される等）。略称およびそれらの同等な置換を備える、等価テーブルが、アイデンティティハブ３２と関連付けられたデータベースに保存されてもよい。事業名を標準化する一実施形態に対する疑似コードは、以下のとおりである。

使用される技法を問わず、いったん比較されるデータ記録の属性およびデータ記録自体が、ステップ３２０において標準形態に標準化されると、ステップ３３０において新規または受信データ記録と比較するための既存のデータ記録から、一式の候補が選択されてもよい。この候補選択過程（本明細書ではバケッティングとも呼ばれる)は、既存の新規データ記録のうちのどれが、さらなる比較を必要とするほど新規データ記録と同様であるかを決定するように、新規または受信データ記録の１つ以上の属性と既存のデータ記録との比較を備えてもよい。各一式の候補（バケットグループ）は、属性に対応する候補選択機能（バケッティング機能）を使用する、データ記録間（例えば、受信データ記録と既存のデータ記録との間）の一式の属性の各々の比較に基づいてもよい。例えば、ある一式の候補は、名前を比較するように設計される候補選択機能、および住所を比較する別の候補選択機能を使用する、名前および住所の属性の比較に基づいて選択されてもよい。

ステップ３４０では、これらの一式の候補を備えるデータ記録は、新規または受信記録とのより詳細な比較を受けてもよく、その場合、一式の属性は、既存のデータ記録が新規データ記録と結び付けられるべきか、または関連付けられるべきかをどうかを決定するように、記録間で比較される。このより詳細な比較は、その属性に対するウエートを生成するように、記録（例えば、既存の記録）の一式の属性のうちの１つ以上を、他の記録（例えば、新規または受信記録）における対応する属性と比較することを必要としてもよい。次いで、一式の属性に対するウエートは、２つの記録が結び付けられるべきかどうかを決定するように閾値と比較することができる、全体的ウエートを生成するように合計されてもよい。例えば、全体的ウエートが第１の閾値（ソフトリンクまたはレビュー閾値と呼ばれる）未満であれば、記録は結び付けられてなくてもよく、全体的ウエートが第２の閾値（自動リンク閾値と呼ばれる）より大きければ、記録は結び付けられてもよく、一方で、全体的ウエートが２つの閾値の間にあれば、記録は、結び付けられ、ユーザレビューのためにフラグを付けられてもよい。

手短に図１を参照すると、アイデンティティハブ３２は、上記の方法論を実施する際に、国際的スクリプトおよび言語を記憶し、戻し、表示することができる、種々の構成要素を有する。しかしながら、種々の言語が異なる情報源システムから導出される時、データ記録の言語が不明である時、異なる言語からの記録が同じ実体内になければならない時、または異なる言語からの記録の間の関係が識別されなければならない時（階層的関係等）に、この直接的解決法は、より複雑となり得る。例えば、データ記録の結び付きは、情報源３４、３６、３８の中のデータ記録が異なる言語による場合があり、場合によっては、同じ情報源内の異なるデータ記録が異なる言語による場合があるという事実によって、さらに複雑にされる場合がある。オペレータ４０、４２、４４のうちの１つが、アイデンティティハブ３２に第１の言語によるクエリを伝送してもよく、情報源３４、３６、３８が、複数言語による同じ実体に関するデータ記録を維持すると仮定すると、アイデンティティハブ３２は、異なる言語によるこれらのデータ記録を検索し、それらが結び付けられるべきかどうか、およびどのように結び付けられるべきかを決定し、それに応じてクエリへの応答を準備し、適時かつ正確に、第１の言語でオペレータ４０、４２、または４４にクエリへの応答を返信する必要がある。

複数言語によるデータ記録を取り扱う１つの方法は、別個のハブを介してそれらを処理することであり、各ハブは、特定の言語で構成される。言語特有の検索が各ハブ内で行われてもよく、次いで、ユーザまたはユーザ群は、検索結果をまとめようとすることができる。このアプローチに関する問題は、言語間検索を行う方法がなく、手動で、またはコンピュータを使用して、別個のハブからの検索結果をまとめることは、面倒で、時間がかかり、極度の労力がかかり、費用がかかり、かつ間違いが発生しやすい過程となり得るということである。他のアプローチは、全ての言語で有効であるスーパーアルゴリズムを作成しようとすることであるが、そのようなスーパーアルゴリズムは、新規の言語に拡張可能ではない。

本明細書で開示される実施形態は、より基礎的なアプローチに基づく。本明細書で説明されるように、アイデンティティハブ３２の実施形態は、標準化、バケッティング、詳細比較、ウエート生成、結び付け、実体処理等を含む、種々の異なる機能を提供し、特定のデータ記録または一対のデータ記録の言語に基づいて、これらの機能を適用することができる。つまり、単一ハブ内で複数言語によるデータ記録を関連付けるために、アイデンティティハブ３２は、特有のアルゴリズムで構成されてもよく、標準化、比較等が行われているデータ記録の言語に基づいて、どのアルゴリズムが、どのデータ記録と併せて利用されるべきかを決定することができる。

多言語アイデンティティハブ３２の実装例３００の一実施形態を示す図２０、およびより詳細に実装例３００を示す図２１を参照する。上記で説明されるように、情報源３４、３６、３８からのデータ記録は、同じ、または異なる言語によるものであってもよい。したがって、コア層３０２において、データ記録が複数言語で記憶される。各データ記録の言語は、既知でなくてもよい。

各記録は、入ってくると、特定の言語とタグ付けされ、特徴付けられ、割り当てられ、あるいは関連付けられる。この過程は、自動かつ決定論的である。しばしば、記録の言語を容易に決定することができる。例えば、国コードがブラウザアプリケーションによって割り当てられてもよく、デフォルト言語が管理者によって設定されてもよく、記録と関連付けられた国コードと併せて、記録の内容に基づいて正しい言語を決定するために、アルゴリズムが利用されてもよい、等である。いくつかの実施形態では、「最悪」言語がさらなる処理のために選択される。ここで、言語は、処理するためにより多くの計算資源を要する場合があると、概して容認されるか、または決定することができた場合に、別の言語よりも悪いと見なされる。例えば、データ記録が英語および日本語によるデータを有する場合、その記録が英語も含有する場合があるかどうかにかかわらず、日本語による記録を構文解析するのにより手間がかかる場合があるため、日本語が、その特定のデータ記録に対する言語として選択される。いくつかの実施形態では、アイデンティティハブ３２は、英語、フランス語、ドイツ語、中国語、日本語、および韓国語によるデータ記録を記憶する。

図２１の実施例では、データ記録Ｒ_１、Ｒ_２、Ｒ_３、・・・、Ｒ_ｎが入ってくると、それらは、言語Ｌ_１、Ｌ_２、・・・、Ｌ_ｎによるものであると割り当てられるか、または決定され、Ｒ_１およびＲ_２は、同じ言語Ｌ_１によるものである。アイデンティティハブ３２では、各言語は、メンバー型に１対１で論理的に対応づけられる。したがって、Ｌ_１は、ＭｅｍＴｙｐｅ_１に論理的に対応づけられ、Ｌ_２は、ＭｅｍＴｙｐｅ_２に論理的に対応づけられる、等である。いくつかの実施形態では、複数言語によるデータ記録は、アイデンティティハブ３２における言語定義内で属性の型を共有することができる。

導出層３０４における、特定のメンバー型の各データ記録については、属性に標準化およびバケッティング（候補選択）を行うために、その特定のメンバー型に一意である（よって、その特定のメンバー型に論理的に対応づけられた言語に一意である）導出コードが利用される。導出コードは、１つ以上の標準化技法を利用してもよい。例えば、言語標準化、音訳標準化等である。音訳の場合、いくつかの実施形態は、元の属性ならびに音訳された属性を保持してもよく、いくつかの実施形態は、音訳された（標準化された）属性を保持してもよい。当業者であれば、他の標準化技法も可能であることを理解できるであろう。

この一意の導出コードは、データ記録に対してタグ付けされた言語以外の言語による文字を含有する属性を処理できることに留意されたい。例えば、データ記録Ｒ_１が英語および日本語の両方による名前の属性を含有すると仮定する。上記で説明されるように、たとえＲ_１が英語による名前の属性を含有しても、Ｒ_１は、日本語に一意の導出コードを利用してタグ付けされる。日本語特有の標準化では、日本語で意味が全くないか、またはほとんどない文字は、考慮から排除または除去されてもよい。日本語特有の標準化の実施形態例を、図９−１３を参照して以下で説明する。いくつかの実施形態では、候補選択仮定（バケッティング）は、言語非依存型となり得る。言語非依存型バケッティングの実施形態例を、図１４−１９を参照して以下で説明する。

本明細書で開示される実施形態は、たとえデータ記録が英語以外の種々の言語による属性を備えても、それらを結び付けることができる。言語特有の標準化は、複数言語によるデータ記録を構文解析する際に極めて有用となり得る。例えば、ドイツ語の「ｄｅｒ」は、「その」を意味する。したがって、ドイツ語に対してタグ付けされ、ドイツ語に対応するメンバー型に論理的に対応づけられるデータ記録については、そのデータ記録の名前の属性における「ｄｅｒ」は、ドイツ語特有の標準化に放り込まれる場合がある。しかしながら、英語での「ｄｅｒ」は、米国ミシガン州ディアボーンの駅コードとなる場合がある。したがって、英語に対してタグ付けされ、英語に対応するメンバー型に論理的に対応づけられるデータ記録については、「ｄｅｒ」を含有する名前の属性は、英語特有の標準化で標準化される場合がある。

場合によっては、データ記録の属性は、ラテンアルファベットを全く使用しない言語による場合がある。これらの言語は、必ずしもラテンアルファベットで書かれた言語の規則、変化系列、または慣習に従うとは限らないため、これらの言語による属性は、トークンに構文解析しにくい場合がある。これらの問題は、ラテン文字、表意文字等に加えて、多くの異なるコードのセットまたはアルファベットを利用する、日本語、韓国語、中国語等のアジア言語のことになると、特に密接な関係がある。これらの種類の言語の構文解析をさらに複雑にすることは、名前の複数部分を分離するために空白が使用されてはならないということであり、言語に対する幅広い知識基盤の適用がなければ、そのような名前のトークンへの構文解析が極めて困難となる。

図９−１３を参照して以下で説明されるように、本明細書で開示される実施形態は、アジア言語を含む種々の言語による、名前等の属性をトークンに構文解析することができる。いくつかの実施形態は、アジア言語による属性をトークンに分離してもよい。一例として、日本語の名前（例えば、日本語のアルファベットまたは文字セットの中の少なくとも１つの文字を備えるが、任意の他のアルファベットの文字も備えてもよい名前）は、１つ以上のトークンに構文解析される。場合によっては、空白に基づいて日本語の名前を１つ以上のトークンに構文解析することができるように、空白が日本語の名前の属性に導入される。

引き続き図２０および２１を参照すると、いったんデータ記録の属性が、それらのタグ付けされた言語に関して標準化され、導出層３０４においてトークンに構文解析されると、それらは、候補選択過程（バケッティング）で利用されてもよい。言語非依存型となり得る、この候補選択過程は、一式のデータ記録の１つ以上の属性がさらなる比較を必要とするほど同様であるかどうかを決定するように、それらの比較を備えてもよい。そうであれば、それらがどのように結び付けられる、または関連付けられるべきかについて、さらなる決定が行われる。図４−８を参照して以下で説明されるように、このより詳細な比較は、１つの記録（例えば、既存の記録）の一式の属性の各々を、他の記録（例えば、新規の記録）における対応する属性と比較することを必要として、その属性に対するウエートを生成してもよい。次いで、２つの記録がソフトリンクされるか、自動リンクされるか、またはユーザレビューのためにフラグと結び付けられるべきかどうかを決定するように閾値と比較することができる、全体的ウエートを生成するように、一式の属性の各々に対するウエートが合計されてもよい。

多言語アイデンティティハブ３２との関連で、異なる言語による２つのデータ記録が同じ統計的意味を有することができるように、自動的に言語の豊富さの平衡を保つために、ウエートを使用することができる。場合によっては、ウエートは、データ記録の関連付けの以前に決定されたレベルに優先する方法を提供することができる。ウエート生成を以下でさらに説明し、ウエート生成についてのさらなる教示は、本明細書に参考として援用される、「ＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤＦＯＲＡＵＴＯＭＡＴＩＣＷＥＩＧＨＴＧＥＮＥＲＡＴＩＯＮＦＯＲＰＲＯＢＡＢＩＬＩＳＴＩＣＭＡＴＣＨＩＮＧ」と題された２００７年６月１日出願の上記で参照した米国特許出願第１１／８０９，７９２号で見出すことができる。

したがって、異なる言語に対してタグ付けされたデータ記録は、多言語アイデンティティハブ３２の中の実体層３０６において、単一の実体に、または同実体の言語実体に結び付けられてもよい。利用される検索モデルに応じて、異なる言語による、実体、例えば、システム起動を検索すること（例えば、「システム起動の中国語およびドイツ語の名前は何か？」）、または記録がどの言語によるものであるかにかかわらず、同じ実体を検索することを希望してもよい。ロサンゼルスおよびニューヨークに所在地がある医療機関の上記の例に従って、医療機関がフランスのパリにも所在地があると仮定すると、患者がフランスのパリの病院にいる時に、その患者に関する記録を検索するクエリが、ロサンゼルスで英語のデータ記録、およびパリでフランス語のデータ記録を返すように、医療機関は、これらの所在地における複数の病院と関連付けられたデータ記録を関係付けるために、アイデンティティハブ３２を使用してもよい。

場合によっては、異なる言語からのデータ記録の間の関係が識別される必要があってもよい。つまり、コア層３０２において異なる言語に対してタグ付けされたデータ記録は、多言語アイデンティティハブ３２の中の実体層３０６において複数の実体に結び付けられてもよい。そのような実体の例は、個人、世帯、出荷用コンテナ、機関等を含んでもよいが、それらに限定されない。上記で説明される同じ患者が、１つは米国内、もう１つはフランス国内といった、２つの世帯の一員であると仮定すると、その同じ患者に関するデータ記録は、同じ個人を識別するが、２つの異なる住所の属性を有してもよい、２つの世帯実体に結び付けられてもよく、かつ２つの異なる言語によるものであってもよい。

各データ記録の全ての属性、よってデータ記録自体が、そのデータ記録の優勢な言語に関して適切に標準化されるため、多言語アイデンティティハブ３２は、最適アルゴリズムを知的かつ自動的に一致させ、実体層３０６において個々の言語によるこれらの実体を処理することができる。言い換えれば、記録とともに、適切な言語またはスクリプトを渡すことができるため、実体層３０６における実体処理のために、記録を適切なアルゴリズム経路へ「送る」ことができる。読者には、データ記録の一致のためのアルゴリズムの構成についての教示のため、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＡＧＲＡＰＨＩＣＡＬＵＳＥＲＩＮＴＥＲＦＡＣＥＦＯＲＣＯＮＦＩＧＵＲＡＴＩＯＮＯＦＡＮＡＬＧＯＲＩＴＨＭＦＯＲＴＨＥＭＡＴＣＨＩＮＧＯＦＤＡＴＡＲＥＣＯＲＤＳ」と題された２００７年２月５日出願の米国特許出願第１１／７０２，４１０号が指示される。本明細書で開示されるいくつかの実施形態は、本明細書に参考として援用される、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＩＮＤＥＸＩＮＧＩＮＦＯＲＭＡＴＩＯＮＡＢＯＵＴＥＮＴＩＴＩＥＳＷＩＴＨＲＥＳＰＥＣＴＴＯＨＩＥＲＡＲＣＨＩＥＳ」と題された２００７年１月２２日出願の上記で参照した米国特許出願第１１／６５６，１１１号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＩＮＤＥＸＩＮＧ，ＲＥＬＡＴＩＮＧＡＮＤＭＡＮＡＧＩＮＧＩＮＦＯＲＭＡＴＩＯＮＡＢＯＵＴＥＮＴＩＴＩＥＳ」と題された２００７年９月２８日出願の上記で参照した米国特許出願第１１／９０４，７５０号、「ＨＩＥＲＡＲＣＨＹＧＬＯＢＡＬＭＡＮＡＧＥＭＥＮＴＳＹＳＴＥＭＡＮＤＵＳＥＲＩＮＴＥＲＦＡＣＥ」と題された２００７年９月１４日出願の上記で参照した米国特許出願第１１／９０１，０４０号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＭＡＮＡＧＩＮＧＥＮＴＩＴＩＥＳ」と題された２００８年３月２７日出願の上記で参照した米国特許出願第１２／０５６，７２０号で開示されているように、実体に関する情報を指標化する、関係付ける、および管理する実体処理システムおよび方法の実施形態を活用することができる。

本明細書で開示されるいくつかの実施形態は、本明細書に参考として援用される、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＡＲＳＩＮＧＬＡＮＧＵＡＧＥＳ」と題された２００７年１２月３１日出願の米国特許出願第１１／９６７，５８８号、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２２，２２３号、および「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＢＵＳＩＮＥＳＳＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２１，９２８号で開示されているような、属性解析および比較技法の実施形態を活用することができる。

ここで、日本語特有の標準化およびバケッティング技法の実施形態を、図９−１９を参照して説明する。

ここで図９を参照すると、日本語による名前（例えば、少なくとも１つの日本語の文字を有する）等の文字列の構文解析のための方法の一実施形態のフロー図が描写されている。ステップ９１０では、日本語の名前が受信される。受信した名前の中の、ラテン文字を表すあらゆる半角片仮名の文字は、ステップ９２０でラテンの均等物に翻訳される。一実施形態では、名前の名前文字の各々は、例えば、ＵｎｉｃｏｄｅＣｏｎｓｏｒｔｉｕｍによって公表されたコード（例えば、ＵｎｉｃｏｄｅＴｒａｎｓｆｏｒｍａｔｉｏｎＦｏｒｍａｔ（ＵＴＦ）またはＵｎｉｖｅｒｓａｌＣｈａｒａｃｔｅｒＳｅｔ（ＵＣＳ））または均等物に従って、コードによって表されてもよく、例えば、各文字は、ＵＣＳ−４、ＵＴＦ−３２、ＵＴＦ−１６、ＵＣＳ−２、ＵＴＦ−ＥＢＤＩＣ、ＵＴＦ−８、ＵＴＦ−７等のコードポイントによって表されてもよい。したがって、各々の名前の文字に対する各々のコードポイントは、文字が半角片仮名の文字であるかどうかを確かめるように、ラテン文字と同等である半角片仮名の文字に対応する、一連のコードポイントと比較されてもよい。文字が、ラテン文字と同等である半角片仮名の文字であれば、同等のラテン文字と置換されてもよい（例えば、文字に対応するコードポイントが別のコードポイントと置換される）。半角片仮名のコード範囲内のラテンの均等物は、ラテン範囲に翻訳されるべきである。具体的には、一実施形態では、コード部分が６５２８１から６５３７０の範囲に入る文字は、３３から１２２のコードポイントの範囲内の各コードポイントに翻訳される（例えば、６５２８１のコードポイントが見出された場合はコードポイント３３に置換され、６５３００のコードポイントが見出された場合はコードポイント５２に置換される、等）。

次いで、名前の属性の比較をさらに促進するために、名前の中の全ての小文字のラテン文字が、ステップ９３０において、それらの大文字の均等物に翻訳されてもよい（例えば、「ａ」が「Ａ」に翻訳される）。再度、一実施形態では、このことは、名前の中の小文字のラテン文字を表す、あらゆるコードポイントと、同じラテン文字の大文字バージョンを表す各コードポイントとの置換を備えてもよい。

ステップ９４０では、名前の中のあらゆる区切り文字が、空白に翻訳されてもよい。どの文字が区切り文字かという定義は、利用される一式のコードポイントに対応する区切り文字の標準リスト、または区切り文字の専有リスト（例えば、区切り文字の標準リストに加えて、日本語特有の区切り文字または均等物等の、名前の言語に対する特有の区切り文字、または任意の他の所望の区切り文字を備えてもよい）のいずれかであってもよい。例えば、ステップ９３０で、名前の文字のコードポイントの各々が、区切り文字のリストと比較されてもよいように、区切り文字に対応するコードポイントのリストがデータベースに記憶されてもよく、名前の文字のコードポイントが、区切り文字のリストの中のコードポイントに対応する場合、名前の文字のコードポイントは、空白に対応するコードポイントと置換されてもよい。

次いで、ステップ９５０では、名前の中のあらゆる繁体字が、簡体の均等物に翻訳されてもよい。再度、一実施形態では、繁体字に対応するコードポイントを同等の簡体字に対応するコードポイントと置換することによって、繁体字をその簡体の均等物に翻訳するために、簡体の均等物に対応するコードポイントへの繁体字に対応するコードポイントの従来のマッピングが使用されてもよい。しかしながら、別の実施形態では、繁体字と簡体字との間のマッピングは、専有マッピングであってもよく、データベースは、繁体字のコードポイントのリストを記憶してもよく、その場合、これらのコードポイントの各々が、同等の簡体字に対するコードポイントと関連付けられる。次いで、このリストを使用して、名前の中のコードポイントをリストと比較することによって、名前の中の繁体字が識別されてもよく、コードポイントを同等の簡体字に対する関連コードと置換することによって、識別された繁体字が簡体字に翻訳されてもよい。

ステップ９５０で、繁体字がそれらの簡体の均等物に翻訳された後、ステップ９６０で、異なる種類の文字の間に空白が挿入されてもよい。例えば、日本語の名前は、とりわけ、ラテン、平仮名、片仮名、音標片仮名、半角片仮名といった、多くの異なる種類の文字を包含する場合がある。したがって、２つの文字が異なる種類（例えば、異なる文字セット）である場合、名前の中の２つの文字の間に空白が挿入されてもよい。一実施形態では、コードポイントの範囲が文字セットを指定してもよい（例えば、ラテン文字は、１から２５５のコードポイント範囲を備えてもよく、平仮名は、１２３５２から１２４４７のコードポイント範囲を備えてもよい、等）。したがって、特定された、あるいは定義されたコードポイント範囲を使用して、異なるコードポイント範囲内の隣接する文字が識別されてもよく、これらの２つの文字の間で、空白が名前に挿入されてもよい。

ステップ９６０における、異なる種類の文字の間の空白の挿入後、ステップ９７０で、表意文字が名前の中で識別されてもよく、これらの表意文字が空白によって区切られてもよい（例えば、空白が文字の前または後に挿入される）。一実施形態では、表意文字に対応する一式のコードポイントを備えるリストが保持されてもよい。表意文字である名前の中で文字が識別された場合（例えば、文字に対応するコードポイントを、表意文字のリストを備えるコードポイントと比較することによって）、表意文字の前または表意文字の後（例えば、表意文字が名前の最後の文字ではない場合）、空白が名前に挿入されてもよい。

次いで、名前は、ステップ９８０で一式のトークンに構文解析されてもよい。一実施形態では、この構文解析は、名前の中の空白に基づいて行われてもよい。したがって、空白は、名前の１つのトークンの終了、または名前の別のトークンの開始を指定してもよい。次いで、このように、一式のトークンが日本語の名前から得られてもよい。加えて、本開示の他の実施形態（例えば、異なるコードポイントまたはコードポイント範囲を利用してもよい）を適用することによって、韓国語または中国語等の他のアジア言語による名前が、同様に一式のトークンに分離されてもよい。日本語の名前または属性を比較する一実施形態は、テーブル駆動の翻訳技法を利用して、名前をトークンに構文解析することを含む。一実施形態では、テーブル駆動の翻訳技法は、異なる符号化および文字セット間のマッピング／フィルタリングのためのＵｎｉｃｏｄｅマッピングまたはｕｍａｐ−ｔｙｐｅ能力を介して、行うことができる。

したがって、一実施形態では、日本語の名前は、以下のようにトークンに構文解析することができる。
−半角片仮名をラテンに翻訳する。
−１０進（６５２８１、６５３７０）における半角片仮名コード範囲中のラテンの均等物を、１０進（３３、１２２）におけるラテン範囲に翻訳する。
−ラテン小文字を大文字に翻訳する。
−区切り文字を空白に翻訳する。
−該当する場合、日本語特有の区切り文字を標準リストに追加する。包括的なリストではないが、サンプルデータから引き出される例は以下を含む。

繁体中国語の文字を簡体字に翻訳する。一実施形態では、これらの翻訳の２２２のテーブルがある。図１０に例を示し、図中、繁体字が第２の列の中にあり、簡体の均等物が第１の列の中にある。

コードセットが変化する時に、第２の技法が適用されてもよい。その一例は、最初の３文字が片仮名であり、最後の４文字が漢字である、□□□□□□□である。ここでは、２つのトークンが形成される。このことは、ＮＴＴ□□□□□□□または□□□□□□等の組み込まれたラテン字がある時にも役立つ。１つ目と２つ目との違いは、１つ目が実際のラテンコードポイントを使用し、２つ目がそれらの半角の均等物を使用することである。

以下のコードポイント範囲は例示的であり、利用可能な１つまたは複数の全範囲を包括しない。

ここでは、第１の列が文字セット名であり、第２および第３の列が１０進範囲である。ＣＪＫ統合は、日本語のデータに適用した時のいわゆる漢字である。

以下の分布は、サンプルの一式の日本語事業名データの中の文字に関する統計からである。

この場合、漢字（ＣＪＫ統合）および片仮名が最も多い。

この実施例では、データ中のある文字が、これらのグループのうちのいずれにも該当しなかった。それらは大部分が修飾語句であり、これらの文字は、それに先行する文字を伴うグループ化した文字であった（反復文字□がこれらの中で最も一般的であった（すなわち、□□が□ □を意味する））。修飾語句または他の未グループ化文字をグループ化する、ほぼあらゆる方法が適用されてもよい。

前述の２つの技法が組み合わせられてもよい。例えば、□□□□□□□□□□が｛□，□□□□□□□｝に構文解析し、□□□□□□□□□□□が｛□□□□，□□，□□□□｝になる等のように、それらを一式のサンプル名に適用することができる。構文解析のサンプルを図１１に示す。図１２は、構文解析がサンプルの一式のデータからの各名前に対して作成した、トークンの数の統計値を示す、ヒストグラムである。図１２から分かるように、約１６，６０８の名前が、４４，６８１個のサンプルの名前から単一トークンとして残された。したがって、名前の約６３％が、少なくとも２つのトークンに構文解析された。大部分が２つのトークンの名前であり、平均が１つの名前に付き１．９４個の構文解析されたトークンである。図１３は、構文解析されたトークンの文字長の分布を示す、ヒストグラムであり、１つのトークンに付き平均５．１文字である。このことは、元のデータの中の平均１０．３文字の長さに匹敵する。要約すれば、この実施形態では、名前の構文解析のためのステップは、以下を含む。
１．半角文字をそれらのラテンの均等物に翻訳する（ラテンの均等物がある半角文字）。
２．小文字のラテンを大文字のラテンに翻訳する。
３．特殊文字を空白（区切り文字）に翻訳する。
４．文字が１つのコードセットから別のコードセットに変化する時はいつでも、空白を挿入する。修飾語句への変化でない限り、範囲もテーブル駆動となるべきである。
５．（必要であれば）あらゆる表意文字の前後に空白を挿入する。
６．空白についてトークンに構文解析する。

上記で説明される実施形態の複数部分または実施形態内のアイテムを指定する、任意の限定的言語は、特定の実施形態を考慮して、または特定の実施形態に関して該当するのみであると理解され、一般に本開示のシステムおよび方法に該当するとは理解されないことに留意されたい。

いくつかの実施形態では、英語の名前に対するバケッティングの方法は、３つの主要ステップを含む。
１）名前をトークンに構文解析するステップ
２）トークンおよびあらゆる同等のトークン（例えば、ニックネーム）に対する音声コードを作成するステップ
３）音声的にコード化されたトークンに頻度に基づくバケッティングを適用するステップ

以下は、この方法の一般的な言語非依存型バージョンを、どのようにして作成し、任意の言語による名前に適用することができるかを説明する。この言語非依存型バケッティング方法は、基本一致能力を提供することができ、一式の区切り文字およびスクリプトの変化に基づいて入力が構文解析される、上記で説明される構文解析の方法とともに使用することができる。現在、アイデンティティハブ３２は、言語非依存型の同等名処理および言語非依存型の頻度に基づくバケッティングを行うことができる。したがって、言語非依存型バケッティング方法を作成するために、唯一残されたするべきことは、任意の言語／スクリプトに適用することができる、一般的なコーディングルーチンである。

言語/スクリプト非依存型コーディングシステムを作成する際に、文字の統計値を考慮する必要がある。一例として、図１４は、構文解析および翻訳後の日本語の名前のサンプルからの単一文字分布を示す。より制限されたアルファベットでは、おそらく、対を成す文字または２部グラフを見る必要がある。構文解析および翻訳後に、図１４に示された分布を伴う２１６８文字があると仮定する。図１５は、図１４のサンプルからの最初の日本語の２０文字、およびそれらの頻度を記載する。

分布が急速に降下するため、このことは、ほぼ全ての構文解析されたトークンがいくつかの低頻度文字を含有することを示唆する。したがって、各トークンからｎ個の最高頻度文字を選択することに基づいて、コーディングスキームを構築することができる。この場合、アルゴリズムは、以下を含んでもよい。
１．トークンを備える文字を、それらの全体的頻度別に順序付ける。最低頻度文字が１番目である。
２．これらの中の最初のｎ個を選択する（元のトークンの長さまで）。

ｎを選ぶ時に、トークンの頻度は、誇張されすぎるものではない。つまり、コード化されたトークンの分布は、元のトークンの分布の桁数内となるべきである。これは、Ｓｏｕｎｄｅｘよりもｍｅｔａｐｈｏｎｅが好まれる理由のうちの１つである。ｎ＝２およびｎ＝３を見て、後者に決めたと仮定する。分布を図１６に示す。

ここで、曲線１６０は、元のトークンの分布であり、曲線１６２は、コード化されたトークンの分布である。頻度に基づくバケッティングで扱うことができる、最初の２つのコード化された値以外に、分布は合理的に見える。

次に、これらのコード化されたトークンは、バケッティングに使用される。一例として示すために、頻度が１／１０００未満であれば、１／１０００のカットオフおよび単一トークンに対するバケットを使用し、そうでなければ、ペア頻度が１／１０００未満である限り、ペアワイズ結合を使用する。

図１７は、元の構文解析された名前（左列）、および対応するバケットアイテム（右列）の例を示す。第５行では、３つの単一文字トークンが単独でバケットするほど低頻度である一方で、第６行では、２つの２方向バケットが生じたことに留意されたい。行また、これらのデータは英語の言葉も含有することに留意されたい。これらは異なって扱われない。

上記で説明されるスキームを適用すると、図１８Ａは、構文解析された名前１７０に対するバケッティングが、バケット１７５の中の一式の名前を作成することを示し、図１８Ｂは、構文解析された名前１８０に対するバケッティングが、バケット１８５の中の一式の名前を作成することを示す。これらの例の両方は、名前のバケッティングの言語非依存型方法を示す。

図１９は、一緒に定性的にバケットするメンバーの数を示す、プロット図である。この分布の平均は１７である（すなわち、平均して、メンバーは名前だけについて、１７人の他のメンバーとバケットする）。図１９から、１００回のクエリごとに、１７０より多いメンバーとバケットする。これは、実装の一例である。他の実装は、平均でおよそ１：１００よりもむしろ１：１０００（ｙ軸上の−３）の倍でヒットしてもよい。

現在のアーキテクチャでは、上記のバケッティング方法は、合理的な性能で容易に実装することができる。例えば、コーディングルーチンは、文字頻度テーブルを消費し、その頻度に従ってトークンの中の文字を分類し、一番上の３つの文字を選択してもよい。日本語以外のスクリプトにこのルーチンを使用するために、選択される文字の数は、構成可能なパラメータであってもよい。次いで、現在の頻度に基づくバケッティングを使用することができる。元のトークンおよびコード化されたトークンの分布が同様であるため、元のトークンまたはコード化されたトークンのいずれかで頻度を実行することができる。トークンは、本明細書に参考として援用される、「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２２，２２３号、および「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＢＵＳＩＮＥＳＳＮＡＭＥＳ」と題された２００６年９月１５日出願の米国特許出願第１１／５２１，９２８号で説明されている技法を使用して、順序付けることができる。

再び図２０および２１を参照すると、使用される技法を問わず、いったん比較されるデータ記録の属性が標準化され、一式の候補が比較のために選択されると、データ記録間のより詳細な比較が、属性レベルで行われてもよい。ウエートが各比較に対して生成されてもよい。

ここで図４を参照すると、属性の比較からスコアを生成する方法の一実施形態のフロー図が描写されている。任意の２つの属性（例えば、個人名、住所、会社名等）を比較するために、描写された方法論の実施形態が使用されてもよいが、それは事業名を比較する際に特に有用であってもよく、そのようなものとして説明される。

ステップ４１０では、２つの名前が、比較されてもよいように与えられるか、または提供される（例えば、ソフトウェアアプリケーションに入力される）。名前は各々、以上で論議されるように、一式のトークンを備える標準化された形態であってもよい。ステップ４２０では、名前の各々に対して、情報スコアが計算されてもよい。次いで、属性に対するこの情報スコアは、名前のトークンの各々の完全一致値の合計（トークンに対する情報スコアとも呼ばれる）であってもよい。次いで、２つの属性の情報スコアがステップ４３０で平均化されてもよい。

（例えば、２つの属性間の最小または最大情報スコアの代わりに）２つの属性の情報スコアに対する平均値を使用することにより、名前比較アルゴリズムの実施形態を可能にして、２つの属性間の生成されたウエートが２つの属性間の欠落したトークンを考慮に入れることを可能にしてもよく、いくつかの実施形態では、欠落したトークンに対して課せられるペナルティが、２つのトークン間の不一致に対して課せられるペナルティの半分になることを可能にしてもよい。順に、トークンの各々の情報スコアは、データサンプル中のトークンの発生頻度に基づいてもよい。トークンに対する情報スコアを決定するために、トークンの相対頻度を利用することによって、あるトークン（例えば、「Ｉｎｃ．」）の共通性が、これらのトークンをより低く採点することによって考慮に入れられてもよい。

次いで、２つの名前を比較することによって、２つの名前の間のスコアをステップ４４０で生成することができる。次いで、このスコアは、２つの名前に対する最終スコアを生成するために、ステップ４５０で正規化されてもよい。一実施形態では、この正規化過程は、生成されたスコアの平均情報スコアに対する比に倍率を適用して、正規化された指標値を生成してもよい。次いで、この正規化された指標値は、値のテーブルを指標化して最終尤度スコアを生成するために使用されてもよい。

ここでは、図４で描写された名前を比較するアルゴリズムの実施形態の種々のステップを、さらに詳細に掘り下げて考えることが有用となる場合がある。そのようなものとして、最初に対処されるのは、ステップ４３０で描写されるような平均情報スコアの計算であろう。上記で論議されるように、属性に対する情報スコアは、属性のトークンの各々に対する完全一致ウエートの合計であってもよい。これらの完全一致ウエートが計算される方法の実施形態を説明することが有用となる場合がある。一実施形態では、完全一致ウエートテーブルは、トークンの完全一致に使用するためのトークンまたはデフォルト値の完全一致に対するウエート値を有してもよい。言い換えれば、完全一致ウエートテーブルは、対応するウエート値を伴うトークンのリストを備えてもよい。このウエート値は、完全一致ウエートに対応してもよい。異なる言い方をすれば、比較されている両方のトークンが同じである場合、トークンは、完全一致ウエートテーブルで見つけられてもよく、対応するウエートは、これらの２つのトークンに対する一致ウエートとして使用される。２つのトークンが完全一致であると決定され、トークンが完全一致ウエートテーブルにない場合は、デフォルトウエート値が一致ウエートに利用されてもよい。

一実施形態では、完全一致ウエートテーブルの中のトークンと関連付けられたウエートは、情報源３４、３６、３８のうちの１つ以上と関連付けられた一式のデータ記録、または一式の提供されたデータ記録等の、サンプルの一式のデータ記録から計算されてもよい。サンプルの一式のデータ記録を使用して、完全一致ウエートは、頻度データおよび一致セットデータを使用して計算されてもよい。サンプルの一式のデータ記録の中の名前の文字列（例えば、名前の属性）Ｎａｍｅ_Ｔｏｔの数が計算されてもよく、これらの名前の文字列に対応する、各名前のトークンＴについては、カウントがＴ_{ｃｏｕｎｔ}で、頻度がＴ_ｆｒｅｑ＝Ｔ_{ｃｏｕｎｔ}／Ｎａｍｅ_Ｔｏｔである。

次いで、トークンは、頻度別に順序付けられ、最高頻度のトークンが１番目であり、該トークンおよびその前に来た全てのトークンの頻度の合計である、各トークンの累積頻度が、以下の表１で描写されるように計算される。

いくつかの実施形態では、累積頻度が０．８０を超える第１のトークンを含むまでの全てのトークンが決定され、これらのトークンの各々について、Ｅｘａｃｔ_Ｔｉ＝−Ｉｎ（Ｔ_{ｆｒｅｑ−ｉ}）という式を使用して、完全一致ウエートが計算されてもよい。Ｔ_Ｍが、累積頻度が０．８０を超える第１のトークンであり、Ｔ_Ｎが最後のトークンまたは最低頻度トークンである場合、−Ｉｎ（Ｔ_{ｆｒｅｑ−Ｍ＋１}），．．．．−Ｉｎ（Ｔ_{ｆｒｅｑ−Ｎ}）の平均を取ることによって、デフォルト完全一致ウエートを計算することができる。次いで、本明細書で説明される、名前を比較する比較アルゴリズムの実施形態が、データセット中の名前の一式のランダムペアに適用されてもよく、以下を生成する：Ｒａｎ_{ＮａｍｅＣｏｍｐ}＝比較される名前の文字列ペアの総数、およびＦｏｒＩ＝０ｔｏＭＡＸ＿ＳＩＭ、Ｒａｎ_{Ｓｉｍ−Ｉ}＝正規化された類似性がＩである名前の文字列ペアの総数。次いで、各Ｉについて、ＲａｎＦｒｅｑ_{Ｓｉｍ−Ｉ}＝Ｒａｎ_{Ｓｉｍ−Ｉ}／Ｒａｎ_{ＮａｍｅＣｏｍｐ}を計算することができる。いずれも本明細書に参考として完全に援用される、２００６年９月１５日出願のＮｏｒｍＡｄａｍｓらによる「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＢＵＳＩＮＥＳＳＮＡＭＥＳ」と題された米国特許出願第１１／５２１，９２８号、および２００６年９月１５日出願のＮｏｒｍＡｄａｍｓらによる「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された米国特許出願第１１／５２２，２２３号で説明されているようなウエート生成過程を使用して、一致Ｆｒｅｑ_{Ｓｉｍ−Ｉ}＝一致_{Ｓｉｍ−Ｉ}／一致_{ＮａｍｅＣｏｍｐ}も、トークンについて計算することができる。次いで、トークンに対する最終ウエートは、Ｗｅｉｇｈｔ−Ｎｏｒｍ−Ｓｉｍ_Ｉ＝ｌｏｇ１０（一致Ｆｒｅｑ_{Ｓｉｍ−Ｉ}／ＲａｎＦｒｅｑ_{Ｓｉｍ−Ｉ}）として計算されてもよい。

いったん一式のトークンに対する完全一致ウエートが計算されると、それらは、アイデンティティハブ３２と関連付けられたデータベースの中のテーブルに記憶されてもよい。例えば、以下の疑似コードは、イニシャルに対する完全一致ウエートを備える「ｉｎｉｔｉａｌＣｏｎｔｅｎｔ」テーブル、および他のトークンに対する完全一致ウエートを備える「ｅｘａｃｔＣｏｎｔｅｎｔ」といった、２つのテーブルを利用して、属性に対する情報スコアを計算する一実施形態を表す。

依然として図４を参照すると、いったんステップ４３０で情報スコアが計算され、これらのウエートが平均化されると、ステップ４４０で２つの名前に対してウエートが生成されてもよい。ここで図５Ａを参照すると、２つの属性間のウエートを生成する方法の一実施形態のフロー図が描写されている。より具体的には、ステップ５１５では、１つの属性の各トークンが、他の属性の各トークンと比較されてもよい。この比較は、各属性を備える一式のトークンの順序に従って行われてもよい。言い換えれば、１つの属性の第１のトークンが、他の属性のトークンの各々と比較されてもよく、その後、属性の第２のトークンが他の属性のトークンの各々と比較されてもよい、等である。

これらのトークンのペアの各々について、ステップ５２５では、２つのトークンの間に一致が存在するかどうか決定されてもよい。ステップ５２５で、２つのトークンの間に一致が存在しない場合、現在の一致ウエートは、ステップ５３７でゼロに設定されてもよい。しかしながら、２つのトークンの間に一致が存在する場合は、ステップ５３５で２つのトークンに対する現在の一致ウエートが計算されてもよい。

いったんステップ５２５で２つのトークンの間に一致が存在するかどうか決定され、そのような一致が存在する場合に、ステップ５３５で現在の一致ウエートに対して一致ウエートが計算されると、ステップ５４７で距離ペナルティが課せられるべきかどうか決定されてもよい。一実施形態では、距離ペナルティが課せられるべきかどうか決定されてもよく、属性の一対のトークンの間の最終一致が発生した場所に基づいて、距離ペナルティが計算されてもよい。この目的を達成するために、ステップ５４５では、属性の２つのトークンの間の最終一致が発生した場所を示す、最終一致位置が決定されてもよい。比較されている現在の２つのトークンの位置と、最終一致位置との（例えば、属性に対する）差異が、ある閾値よりも大きい場合、ステップ５５５で距離ペナルティが計算されてもよく、現在の一致ウエートから距離ペナルティを引くことによって、ステップ５５７で現在の一致ウエートが調整されてもよい。これらの差異ペナルティは、最終一致位置と現在のトークンの位置との差異に基づいて、異なってもよいことが明白となるであろう。

属性の以前のトークンに対する一致ウエートも、ステップ５６５、５６７、および５７５で決定されてもよい。より具体的には、ステップ５６５では、第１の以前の一致ウエートが、現在比較されている１つの属性のトークンと、もし存在すれば、現在比較されている第２の属性の以前のトークン（例えば、比較されている現在のトークンに順番が先行する）とに対して決定される。同様に、ステップ５６７では、第２の以前の一致ウエートが、現在比較されている第２の属性のトークンと、もし存在すれば、現在比較されている第１の属性の以前のトークンとに対して決定される。ステップ５７５では、いずれか一方のトークンが存在すれば、現在の属性の各々の以前のトークンを使用して、第３の以前の一致ウエートが決定される。次いで、現在の一致ウエートに第３の以前の一致ウエートを加えることによって、ステップ５７７で、現在比較されている一対のトークンに対する現在の一致ウエートが調整されてもよい。

次いで、ステップ５８５で、現在の一致ウエートが第１および第２の以前の一致ウエートと比較されてもよく、現在の一致ウエートが以前の一致ウエートのいずれか一方以上であれば、ステップ５８７で、ウエートが現在の一致ウエートに設定されてもよい。しかしながら、第１または第２の以前の一致ウエートが、現在の一致ウエートよりも大きければ、ステップ５９５で、ウエートは、第１または第２の以前の一致ウエートのうちの大きい方に設定される。このように、２つの属性のトークンの各々が比較された後に、ウエートが生成される。

本明細書で開示される、ある実施形態を実施する際に、多くの種類のデータ要素またはデータ構造が有用であってもよいことが明白となるであろう。例えば、図５Ｂは、テーブルを利用して２つの属性間のウエートを生成する方法の一実施形態のフロー図を示す。ステップ５１０では、２つの名前の比較に役立つように、テーブルが構築されてもよい。このテーブルは、名前のうちの１つにおけるトークンの各々に対する行に加えて、付加的な行と、他の名前におけるトークンの各々に対する列に加えて、付加的な列とを備えてもよい。したがって、テーブルの第１行および第１列が、初期状態に対応してもよい一方で、テーブルの他のセルの各々は、一意の一対のトークンに対応してもよく、名前の各々からの１つのトークンが比較される。テーブルの各セルは、位置（例えば、セル）インジケータおよびウエートを記憶する能力を有してもよい。テーブルが示された実施形態で利用されるが、テーブルは構造例にすぎず、任意のデータ構造、構造記憶が利用されてもよいことが明白となるであろう（例えば、任意の次元の配列、連結リスト、ツリー等）。

ステップ５１０でテーブルが構築された後、テーブル内のある初期セルが初期値を有するように、ステップ５２０で初期化されてもよい。より具体的には、一実施形態では、位置インジケータが空値またはゼロ値を受信してもよく、これらのセルの各々と関連付けられたウエートがゼロ値に初期化されてもよいように、第１行および第１列の各々が初期化されてもよい。

次いで、セルと関連付けられる位置および値を決定するように、（例えば、初期セルの他に）テーブルの他のセルの各々が反復されてもよい。各セルについては、ステップ５３０で、セルが頭字語一致を通してすでに一致させられているかどうかが決定され、もしそうであれば、セルを飛ばして進んでもよい。しかしながら、セルが以前に一致させられていなかった場合は、ステップ５４０で、セルに対応する２つのトークンの間に一致が存在するかどうか決定されてもよく、一致が存在しなければ、一実施形態では、１つのトークンの文字を、他方の名前の一式のトークンの最初の文字と比較することによって、ステップ５３２で、セルに対応するトークンのいずれか一方が、他方の名前における一式のトークンに対する頭字語であるかどうかが決定されてもよい。トークンのうちの１つが、他方の名前における一式のトークンに対する頭字語である場合、ステップ５３４では、対応するトークンが頭字語である一式のセル、および頭字語に対応する他方の名前の一式のトークンに対して、（以下でより詳細に説明されるような）最終位置インジケータおよびセルウエートが計算される。１つのトークンが他方の名前の一式のトークンに対する頭字語であるかどうかを決定する疑似コードは、以下のとおりであり、ＭＡＸ＿ＩＮＩＴ＿ＭＡＴＣＨは、この実施形態では３である、最大頭字語の長さである。

ステップ５３２で、いずれのトークンも頭字語ではないと決定された場合、現在のセルに対する一致ウエートがステップ５４２でゼロに設定されてもよい。ステップ５４０に戻って、現在のセルに対応する２つのトークンの間に一致が存在する場合、２つのトークンに対する一致ウエートがステップ５４２で計算されてもよい。２つの対応するトークンを比較し、ステップ５４０および５４２に従って関連一致ウエートを生成するために、事実上あらゆる種類の比較が利用されてもよいが、一実施形態では、完全一致、イニシャル一致、音声一致、ニックネーム一致、またはニックネーム音声一致が生じるかどうかが決定されてもよく、対応する一致ウエートは、本明細書に参考として完全に援用される、２００６年９月１５日出願のＮｏｒｍＡｄａｍｓらによる「ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＣＯＭＰＡＲＩＮＧＡＴＴＲＩＢＵＴＥＳＳＵＣＨＡＳＰＥＲＳＯＮＡＬＮＡＭＥＳ」と題された、前述の米国特許出願第１１／５２２，２２３号で説明されているように計算されてもよい。２つのトークンを比較し、関連一致ウエートを生成する疑似コードは、以下のとおりである。

依然として図５Ｂを参照して、いったんセルに対応する２つのトークンの間に一致が存在するかどうかがステップ５４０で決定され、そのような一致が存在する場合に一致ウエートがステップ５４２で計算された場合、距離ペナルティが課されるべきかどうかがステップ５５０で決定されてもよく、距離ペナルティは、ステップ５５２で計算されてもよい。一実施形態では、距離ペナルティが課されるべきかどうかが決定されてもよく、距離ペナルティは、最終位置一致に対応するセルの位置と、現在のセルとの違いに基づいて計算されてもよい。行の位置および列の位置の違いが計算されてもよく、違いが１より大きい場合（距離ペナルティが課されるべきであると示す）、課すべき距離ペナルティを決定するために、これらの違いの中で最も大きいものが使用されてもよい。例えば、現在のセルの行と最終一致を伴うセルの行との違いが、２であり、現在のセルの列と最終一致を伴うセルの列との違いが、３である場合、３という距離に関連付けられた距離ペナルティが利用されてもよい。最終一致セルと評価されている現在のセルとのより大きい距離に基づいて、より大きい違いのペナルティが関連付けられ、課せられてもよいことが明白となるであろう。実際に、ステップ５５０で、距離ペナルティが課せられるべきであると決定され、距離ペナルティが計算された場合には、一致ウエートから距離ペナルティを引くことによって、ステップ５６０で一致ウエートが調整されてもよい。

次いで、セルに一致ウエートを使用して、セルに対するセルウエートおよび最終一致位置がステップ５７０で計算されてもよい。セルに対する最終一致位置およびセルウエートを計算する方法の一実施形態のフロー図を図６に示す。概して、セルウエートおよび最終一致位置は、周辺セルの最終一致位置およびセルウエートに基づいて計算されてもよい。具体的には、現在のセルに隣接する１つのセル（例えば、現在のセルの行数から１を引いた、同じ列数）からのセルウエートが、ステップ６１０で決定されてもよく、現在のセルに隣接する別のセル（例えば、現在のセルの列数から１を引いた、同じ行数）からのセルウエートが、ステップ６２０で決定されてもよい。ステップ６３０では、現在のセルに対して計算された一致ウエート（ステップ５７０）に、対角上の隣接セル（例えば、現在のセルの行数から１を引き、現在のセルの列数から１を引いた）のセルウエートを加えることによって、一時的セルウエートが決定されてもよい。

２つの隣接セルからのセルウエート、および一時的セルウエートは、ステップ６４０で比較されてもよい。一時的セルウエートは、隣接セルのセルウエートのいずれか一方よりも大きい場合、ステップ６４２で、現在のセルの最終一致位置が現在のセルの位置に設定され、ステップ６４４で、現在のセルのセルウエートが一時的セルウエートに設定される。しかしながら、セルウエートのいずれか一方が一時的セルウエートを超える場合、２つのセルウエートのうちの大きい方が、現在のセルのセルウエートとして割り当てられ、ステップ６５２またはステップ６５４で、そのセル（例えば、より高いセルウエートを伴う隣接セル）の最終一致位置指標の値が、現在のセルの最終位置指標として割り当てられる。

ここで図５Ｂに戻って、テーブル中の全てのセルが上記で説明される方式で反復された後、ステップ５８０で、比較されている２つの名前に対するウエートは、テーブルの最終セル（例えば、最終行、最終列）のセルウエートであってもよい。次いで、次いで、ステップ５８０でウエートが決定され、このウエートは、一実施形態では、２つの名前に対するウエートの２つの名前の平均情報値に対する比を計算し、この比に最大指標値を掛けて正規化された指標値を求めることによって、図４のステップ４５０で表されるように正規化されてもよい。次いで、この正規化された指標値は、一実施形態では、指標値を使用して、アイデンティティハブ３２のデータベースに記憶されたウエートのテーブルを指標化することによって、最終ウエートを決定するために使用されてもよい。

上記で説明された方法の実施形態の用途の例を掘り下げる前に、種々の一致および分布ペナルティがどのように決定されるかを論議することが有用であり得る。一実施形態では、これらのペナルティを計算するために、図４に関して上記で説明されるもの等の比較アルゴリズムの実施形態が、サンプルの一式のデータ記録から得られた、一式の無作為なペアの名前に適用される。通常は、およそ１，０００万組の名前が使用されてもよい。比較アルゴリズムを適用している間に、以下が追跡されてもよい。
・Ｒａｎ_Ｃｏｍｐ＝比較される名前のトークンの総数。
・Ｒａｎ_{Ｅｘａｃｔ}＝正確に一致する名前のトークンの総数。
・Ｒａｎ_{Ｉｎｉｔｉａｌ}＝イニシャル一致を介して一致する名前のトークンの総数。イニシャル一致は、最初の文字が一致し、１つのトークンが長さ１を有し、他方の長さが１より大きいものである。
・Ｒａｎ_{Ｐｈｏｎｅｔｉｃ}＝完全ではなく、音声的に一致する名前のトークンの総数。
・Ｒａｎ_{Ｎｉｃｋｎａｍｅ}＝共通のニックネームを有し、完全には一致しない名前のトークンの総数。
・Ｒａｎ_{ＮｉｃｋＰｈｏｎｅ}＝音声的に一致するニックネームを有し、完全には一致しないか、またはニックネームだけを介しては一致しない、名前のトークンの総数。
・Ｒａｎ_Ｅｄｉｔ＝編集距離比較を介して一致し、完全には一致しない名前のトークンの総数。
・Ｒａｎ_{Ｄｉｓｔ−０}＝（ＣＸＮＭのみ）完全に一致し、各名前の文字列における以前のトークンも一致した、名前のトークンの総数。
・実施例１：ＢＯＢＳＦＬＯＷＥＲＳＨＯＰと比較されたＢＯＢＳＦＬＯＷＥＲＳＨＯＰでは、以前のトークンにおいて完全一致のＢＯＢＳがあったため、ＦＬＯＷＥＲに対する完全一致が数えられる。同様に、ＳＨＯＰも数えられる。
・実施例２：ＢＯＢＳＰＲＥＴＴＹＦＬＯＷＥＲＳＨＯＰと比較されたＢＯＢＳＦＬＯＷＥＲＳＨＯＰでは、以前のトークンがＢＯＢＳおよびＰＲＥＴＴＹであり、一致であるため、ＦＬＯＷＥＲは数えられない。ＳＨＯＰが数えられる。
・Ｒａｎ_{Ｄｉｓｔ−１}、Ｒａｎ_{Ｄｉｓｔ−２}、Ｒａｎ_{Ｄｉｓｔ−３}＝（ＣＸＮＭのみ）完全に一致し、現在の一致と以前の一致との間の正確なトークンの最大数が１、２、または３である、名前のトークンの総数。
・上記の実施例２では、ＦＬＯＷＥＲの一致に対して、以前の一致はＢＯＢＳである。第１の文字列には余分なトークンがなく、第２の文字列には１つのトークンがあるため、これがＲａｎ_{Ｄｉｓｔ−１}の例となる。
・文字列ＢＯＢＳＰＲＥＴＴＹＦＬＯＷＥＲＳおよびＢＯＢＳＧＯＯＤＦＬＯＷＥＲＳが比較された場合、各文字列に１つの余分なトークンがあるため、完全一致のＦＬＯＷＥＲＳに対する距離は、依然として１となる。
・文字列ＢＯＢＳＰＲＥＴＴＹＮＩＣＥＦＬＯＷＥＲＳおよびＢＯＢＳＧＯＯＤＦＬＯＷＥＲＳが比較された場合、第１の文字列に２つの余分なトークンがあるため、完全一致のＦＬＯＷＥＲＳに対する距離は２となる。
・余分なトークンの数が３以上であれば、Ｒａｎ_{Ｄｉｓｔ−３}で数えられる。

次いで、以下の頻度を計算することができる。

完全一致ウエートを生成することと併せて、上記で説明される過程を使用して、一式の一致した名前のペアを導出することができ、以下の頻度を導出することができる。

これらの頻度を使用して、以下の限界ウエートが計算されてもよい。

各ペナルティは以下のように計算されてもよい。

図７のテーブル例を参照して、「ＢｏｂｓＦｌｏｗｅｒＳｈｏｐ」および「ＢｏｂｓＶｅｒｙＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐｐｅ」といった２つの名前の間のウエートを得ることが所望され、以下のパラメータが比較に使用されると仮定すると、トークンの各々に対する完全一致ウエートは、以下のとおりである。
ＢＯＢＳ-２００
ＶＥＲＹ-１５０
ＰＲＥＴＴＹ-３００
ＦＬＯＷＥＲ-４００
ＳＨＯＰＰＥ-６００
ＳＨＯＰ-１５０
一方で、３という距離に対する距離ペナルティは１００であり、音声ペナルティは１００である。

一実施形態では、比較されている２つの名前に対して、平均情報スコアが計算されてもよい（ステップ４３０）。一実施形態では、このことは、各々の名前における各々のトークンに対する完全一致ウエートを使用して行われる。この方法によれば、ＢｏｂｓＦｌｏｗｅｒＳｈｏｐに対する情報スコアは７５０（例えば、２００＋４００＋１５０）であり、「ＢｏｂｓＶｅｒｙＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐｐｅ」という名前に対する情報スコアは、１６５０（２００＋１５０＋３００＋４００＋６００）であり、２つの情報スコアの平均を１２００にする。

いったん２つの名前に対する平均情報スコアが計算されると（ステップ４３０）、２つの名前に対するウエートが生成されてもよい（ステップ４４０）。一実施形態によれば、テーブル７００が構築される（ステップ５１０）。その場合、各セル７０２には、位置指標（例えば、行、列）およびセルウエートを保持する能力がある。次いで、テーブルのセル７０２ａが初期化されてもよい（ステップ５２０）。

いったんテーブルのセル７０２ａが初期化されると、テーブル７００の残りのセル７０２が反復されてもよい。セル７０２ｂ（例えば、行１、列１）から開始して、セル７０２ｂに対応する２つのトークンの間に一致が生じることが決定される（ステップ５４０）。次いで、これらの２つのトークンに対する一致ウエートが計算されてもよく（ステップ５４２）、この場合、それは２００である。次いで、隣接セルに対するセルウエート値が決定されてもよく（ステップ６１０、６２０）、このことから、２００を加えた対角セル７０２ａ１からのセルウエート（０）（例えば、セルに対する一時的セルウエート）が、隣接セル７０２ａ２、７０２ａ３のセルウエートよりも大きいことを決定することができる（ステップ６４０）。したがって、セル７０２ｂに対する最終一致位置指標は、現在のセル７０２ｂ（１，１）に設定され、現在のセルに対するセルウエートは、計算された一致ウエート（２００）に設定される（ステップ６４２、６４４）。

次いで、次のセル７０２ｃに対する最終一致位置指標およびセルウエートが計算されてもよい。セル７０２ｃに対応する２つのトークンの間に一致が生じないことが決定される（ステップ５４０）。頭字語一致が生じない（ステップ５３２）ため、このセルに対する一致ウエートは、ゼロに設定される（ステップ５４２）。次いで、一時的セルウエートが計算され（ステップ６３０）、隣接セル７０２ｂ、７０２ａ４のセルウエートと比較されてもよく（ステップ６４０、６５０）、このことから、隣接セル７０２ｂからのセルウエート（１００）が、セル７０２ａ４のセルウエート、または現在のセル（０）に対する一致ウエートを加えた対角セル７０２ａ３のセルウエート（例えば、一時的セルウエート）よりも大きいことを決定することができる。したがって、現在のセル７０２ｃの最終一致位置指標は、隣接セル７０２ｂ（１，１）の最終位置一致指標に設定され、現在のセル７０２ｃのセルウエートは、より大きいセルウエートを伴う隣接セル７０２ｂのセルウエートに設定される（ステップ６５２）。

同様に、セル７０２ｄ、７０２ｅ、７０２ｆ、７０２ｇ、７０２ｈ、７０２ｉ、７０２ｊ、および７０２ｋが、セル７０２ｃに関して上記で説明されるのと同様の結果とともに反復されてもよい。しかしながら、セル７０２ｌに到達すると、セル７０２ｌに対応する２つのトークンの間に一致が生じることが決定されてもよい（ステップ５４０）。次いで、セル７０２ｌに対応する２つのトークン（例えば、「Ｆｌｏｗｅｒ」および「Ｆｌｏｗｅｒ」）に対する一致ウエートが計算されてもよく（ステップ５４２）、この場合、それは４００である。次いで、対角セル７０２ｈの最終一致位置の位置を、現在のセル７０２ｌの位置と比較することによって、距離ペナルティが課せられるべきかどうかが決定されてもよい（ステップ５５０）。この比較は、相互から行指標を引き（例えば、４−１）、相互から列指標を引き（例えば、２−１）、これらの値の最大値を取り（例えば、３）、この距離値を閾値レベルと比較して、距離ペナルティが課せられるべきかどうかを決定することによって、達成されてもよい。この場合、距離ペナルティに対する閾値は、１という距離であってもよく、３が１よりも大きいため、距離ペナルティが課せられるべきであると決定されてもよい。次いで、距離値（例えば、３）に対応する距離ペナルティが、現在のセルに対する計算された一致ウエートから引かれてもよい（ステップ５５２、５６０）。この場合、距離ペナルティは１００であり、それは、セル７０２ｌの一致ウエートを３００に調整するように、４００の一致ウエートから引かれてもよい。次いで、隣接セルに対するセルウエート値が決定されてもよく、このことから、現在のセル７０２ｌに対する一致ウエート（例えば、３００）を加えた対角セル７０２ｈからのセルウエート（２００）が、いずれか一方の隣接セル７０２ｋ、７０２ｉのセルウエート（例えば、それぞれ、２００および２００）よりも大きいことを決定することができる（ステップ６４０）。したがって、セル７０２ｌの最終一致位置指標は、現在のセル７０２ｌ（４，２）に設定され、現在のセル７０２ｌのセルウエートは、対角セル７０２ｈからのセルウエートを加えた、計算された一致ウエート（例えば、３００＋２００＝５００）に設定される（ステップ６４２、６４４）。

セル７０２ｍ、７０２ｎ、および７０２ｏに対する最終位置一致指標およびセルウエートは、上記で説明される計算と同様に計算されてもよい。しかしながら、セル７０２ｐに到達すると、セル７０２ｐに対応する２つのトークンの間に一致が生じることが決定されてもよい（ステップ５４０）。次いで、セル７０２ｐに対応するトークン（例えば、「Ｓｈｏｐｐｅ」および「Ｓｈｏｐ」）に対する一致ウエートが計算されてもよく（ステップ５４２）、この場合、それは５０であってもよい（「Ｓｈｏｐｐｅ」と「Ｓｈｏｐ」との間の一致が音声一致であってもよいため、そのウエートは、音声ペナルティウエートを引いた、ＳｈｏｐｐｅおよびＳｈｏｐに対する完全一致ウエートの最小値であってもよい）。次いで、対角セル７０２ｌの最終一致位置の位置を、現在のセル７０２ｐの位置と比較することによって、距離ペナルティが課せられるべきかどうかが決定されてもよい（ステップ５５０）。この比較は、相互から行指標を引き（例えば、５−４）、相互から列指標を引き（３−２）、これらの値の最小値を取り（例えば、１）、この距離値を閾値レベルと比較して、距離ペナルティが課せられるべきかどうかを決定することによって、達成されてもよい。この場合、距離ペナルティに対する閾値は、１という距離であってもよく、そのようなものとして、距離ペナルティは課せられるべきではない。したがって、現在のセル７０２ｐの一致ウエートは、５０である。次いで、隣接セル７０２ｏ、７０２ｍに対するセルウエート値が決定されてもよく（ステップ６１０、６２０）、このことから、現在のセル７０２ｐに対する一致ウエート（例えば、５０）を加えた対角セル７０２ｌからのセルウエート（５００）が、いずれか一方の隣接セル７０２ｋ、７０２ｉのセルウエート（例えば、それぞれ、５００および５００）よりも大きいことを決定することができる（ステップ６４０）。したがって、セル７０２ｐの最終一致位置指標は、現在のセル７０２ｐ（５，３）に設定され、現在のセル７０２ｐのセルウエートは、対角セル７０２ｌを加えた、計算された一致ウエート（例えば、５００＋５０＝５５０）に設定される（ステップ６４２、６４４）。

テーブル７００の最終セル７０２ｐを読むと、比較されている２つの名前に対するウエートが５５０であると決定することができる。次いで、このウエートは、最大類似度指標、およびウエートの２つの名前に対する平均情報スコアに対する比に従って、正規化されてもよい（ステップ４５０）。例えば、最大類似度指標が１０である場合、ウエートは、方程式１０＊５５０／１２００の結果を四捨五入することによって、４という正規化された指標値に正規化されてもよい。この正規化された指標値は、２つのトークンに対する最終ウエートを生成するために、正規化されたウエートテーブルへの指標として使用されてもよい（ステップ４５０）。例えば、４という正規化されたウエートは、２つの名前に対する４４１という最終ウエートに指標化されてもよい。

図８は、頭字語が存在する実施例を示す。「ＢｏｂｓＶＰＦｌｏｗｅｒＳｈｏｐ」および「ＢｏｂｓＶｅｒｙＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐ」といった２つの名前の間のウエートを得ることが所望され、以下のパラメータが比較に使用されると仮定すると、トークンの各々に対する完全一致ウエートは、以下のとおりである。
ＢＯＢＳ-２００
ＶＥＲＹ-１５０
ＰＲＥＴＴＹ-３００
ＦＬＯＷＥＲ-４００
ＳＨＯＰ-１５０
一方で、３という距離に対する距離ペナルティは、１００である。

一実施形態では、比較されている２つの名前に対して、平均情報スコアが計算されてもよい（ステップ４３０）。一実施形態では、このことは、各々の名前における各々のトークンに対する完全一致ウエートを使用して行われる。この方法によれば、ＢｏｂｓＶＰＦｌｏｗｅｒＳｈｏｐに対する情報スコアは１０５０（例えば、２００＋３００＋４００＋１５０）であり、「ＢｏｂｓＶｅｒｙＰｒｅｔｔｙＦｌｏｗｅｒＳｈｏｐ」という名前に対する情報スコアは、１２００（２００＋１５０＋３００＋４００＋１５０）であり、２つの情報スコアの平均を１１２５にする。

いったん２つの名前に対する平均情報スコアが計算されると（ステップ４３０）、２つの名前に対するウエートが生成されてもよい（ステップ４４０）。一実施形態によれば、テーブル８００が構築される（ステップ５１０）。その場合、各セル８０２には、位置指標（例えば、行、列）およびセルウエートを保持する能力がある。次いで、テーブルのセル８０２ａが初期化されてもよい（ステップ５２０）。

いったんテーブルのセル８０２ａが初期化されると、テーブル８００の残りのセル８０２が反復されてもよい。セル８０２ｂ（例えば、行１、列１）から開始して、セル８０２ｂに対応する２つのトークンの間に一致が生じることが決定される（ステップ５４０）。次いで、これらの２つのトークンに対する一致ウエートが計算されてもよく（ステップ５４２）、この場合、それは２００である。次いで、隣接セルに対するセルウエート値が決定されてもよく（ステップ６１０、６２０）、このことから、２００を加えた対角セル８０２ａ１からのセルウエート（０）（例えば、セルに対する一時的セルウエート）が、隣接セル８０２ａ２、８０２ａ３のセルウエートよりも大きいことを決定することができる（ステップ６４０）。したがって、セル８０２ｂに対する最終一致位置指標は、現在のセル８０２ｂ（１，１）に設定され、現在のセル８０２ｂに対するセルウエートは、計算された一致ウエート（２００）に設定される（ステップ６４２、６４４）。

セル８０２ｃ−８０２ｆは、上記で論議されるように、同様に反復されてもよい。セル８０２ｇに到達すると、セル８０２ｇに対応する２つのトークンの間に一致が生じないことが決定されてもよい（ステップ５４０）が、ＶＰが頭字語であると決定されてもよい（ステップ５３２）。この決定は、セル８０２ｇに対応する最初のトークン「ＶＰ」の最初の文字（例えば、「Ｖ」）を、セル８０２ｇに対応する他方のトークン（例えば、ｖｅｒｙ）の最初の文字と比較することによって、達成されてもよい。文字「Ｖ」がトークン「Ｖｅｒｙ」の最初の文字に一致すると、トークン「ＶＰ」の次の文字（例えば、「Ｐ」）は、他方の名前における後続のトークン（例えば、「Ｐｒｅｔｔｙ」）と比較され、これらの文字が一致し、最初のトークン（例えば、「ＶＰ」）の文字がそれ以上ないと、トークン「ＶＰ」が頭字語であると決定することができ、上記で論議される計算と同様に、頭字語トークンに対応する一式のセル８０２ｇ、８０２ｋ（例えば、頭字語トークンの１文字および他方の名前のトークンに対応する各セル）に対して、値を計算することができ（図８Ａに関して表される実施例では、頭字語の文字（例えば、「Ｖ」および「Ｐ」）の間の位置および各一致するトークン（例えば、「Ｖｅｒｙ」および「Ｐｒｅｔｔｙ」）の両方が、５０というウエートとともにイニシャル一致を生成する）。セル８０２ｇおよび８０２ｋに対して値が計算された後、テーブルは、図８Ａに描写されたものと似ていてもよい。

次いで、テーブル８００の残りのセル８０２は、上記で説明されるように、これらのセルに対する最終位置一致およびセルウエートを計算するように、セル８０２ｄから開始して反復されてもよい。セル８０２ｇおよび８０２ｋは、頭字語を介して既に一致させられている（ステップ５３０）ため、反復過程中にこれらのセルを飛ばして進んでもよい。テーブル８００の残りのセル８０２を反復した後、テーブル８００は、図８Ｂに描写されたものと似ていてもよい。

テーブル８００の最終セル８０２ｕを読むと、比較されている２つの名前に対するウエートが８５０であると決定することができる。次いで、このウエートは、最大類似度指標、およびウエートの２つの名前に対する平均情報スコアに対する比に従って、正規化されてもよい（ステップ４５０）。例えば、最大類似度指標が１０である場合、ウエートは、方程式１０＊８５０／１１２５の結果を四捨五入することによって、８という正規化された指標値に正規化されてもよい。この正規化された指標値は、２つのトークンに対する最終ウエートを生成するために、正規化されたウエートテーブルへの指標として使用されてもよい（ステップ４５０）。例えば、８という正規化されたウエートは、２つの名前に対する５２０いう最終ウエートに指標化されてもよい。

名前を比較する方法の一実施形態を表す疑似コードは、以下のとおりである。

上記の疑似コードの実施形態によって返されてもよい、正規化された指標値は、上記で説明されるように、値のテーブルを指標化して最終ウエートを得るために使用されてもよい。そのようなテーブルは、以下に似ていてもよく、その場合、最大指標値は、１６であってもよい。

先述の明細書では、具体的実施形態を参照して本開示を説明した。しかしながら、説明は一例にすぎず、限定的な意味で解釈されるものではないことを理解されたい。したがって、本開示の実施形態の詳細の多数の変更および本開示の付加的な実施形態が、本説明を参照した当業者にとって明白となり、かつ当業者によって行われてもよいことを、さらに理解されたい。全てのそのような変更および付加的な実施形態は、以下の請求項で詳述されるような本開示の範囲内であることが意図される。

Claims

単一アイデンティティハブ内で複数言語によるデータ記録を処理する方法であって、
該単一アイデンティティハブにおいて受信される各データ記録について、該データ記録を言語と関連付けることと、
該データ記録の属性に、該言語に特有である一意の導出コードを適用することであって、該一意の導出コードは、言語特有の標準化および言語非依存型バケッティングを備え、該言語特有の標準化は、該言語に関する該データ記録の該属性を標準化する、ことと、
該データ記録とともに、該言語に関する情報および該データ記録の標準化された属性を、該単一アイデンティティハブの実体層に渡すことと、
該言語に関する該情報および該データ記録の該標準化された属性を利用して、該単一アイデンティティハブの該実体層において個々の言語による実体を処理するように、１つ以上のアルゴリズムを自動的かつ最適に選択し、適用することと
を含む、方法。
前記言語を前記単一アイデンティティハブにおける特定のメンバー型に論理的に対応づけることをさらに含む、請求項１に記載の方法。
前記複数言語の各々は、前記単一アイデンティティハブにおける特定のメンバー型に１対１で論理的に対応づけられる、請求項１に記載の方法。
前記一意の導出コードは、前記特定のメンバー型に基づいて選択的に適用される、請求項３に記載の方法。
前記複数言語による前記データ記録は、前記単一アイデンティティハブにおける言語定義内で属性の型を共有する、請求項３に記載の方法。
前記データ記録の前記属性は、２つ以上の言語によるものであり、前記言語は、該２つ以上の言語から選択される、請求項１に記載の方法。
前記データ記録は、前記単一アイデンティティハブによってアクセス可能である複数の情報源からのものであり、該複数の情報源は、１つ以上の言語によるものである、請求項１に記載の方法。
前記データ記録を前記言語と関連付けることは、
国コードを取得するように該データ記録を評価することと、
該国コードを利用して該言語を決定することと
をさらに含む、請求項１に記載の方法。
前記言語は、デフォルト言語である、請求項１に記載の方法。
第１の言語による第１のデータ記録の第１の属性に対する第１のウエートを生成することと、
第２の言語による第２のデータ記録の第１の属性に対する第２のウエートを生成することと、
該第１および第２のウエートを利用して、該第１の言語による該第１のデータ記録の該第１の属性および該第２の言語による該第２のデータ記録の第２の属性を比較することと
をさらに含む、請求項１に記載の方法。
プロセッサによって実行可能であるコンピュータ命令を記憶する、コンピュータ可読記憶媒体であって、該プロセッサによって実行されると、該コンピュータ命令は、コンピュータに、
単一アイデンティティハブにおいて受信される各データ記録について、該データ記録を言語と関連付けさせ、
該データ記録の属性に、該言語に特有である一意の導出コードを適用させ、該一意の導出コードは、言語特有の標準化および言語非依存型バケッティングを備え、該言語特有の標準化は、該言語に関する該データ記録の該属性を標準化し、
該言語に関する情報および該データ記録の該標準化された属性を利用して、個々の言語による実体を処理するように、１つ以上のアルゴリズムを最適に選択および適用させる、
コンピュータ可読記憶媒体。
前記プロセッサによって実行されると、前記コンピュータ命令はさらに、前記コンピュータに、前記言語を特定のメンバー型に論理的に対応づけさせる、請求項１１に記載のコンピュータ可読記憶媒体。
前記プロセッサによって実行されると、前記コンピュータ命令はさらに、前記コンピュータに、
国コードを取得するように前記データ記録を評価させ、
該国コードを利用して前記言語を決定させる、
請求項１１に記載のコンピュータ可読記憶媒体。
前記プロセッサによって実行されると、前記コンピュータ命令はさらに、前記コンピュータに、
第１の言語による第１のデータ記録の第１の属性に対する第１のウエートを生成させ、
第２の言語による第２のデータ記録の第１の属性に対する第２のウエートを生成させ、
該第１および第２のウエートを利用して、該第１の言語による該第１のデータ記録の該第１の属性および該第２の言語による該第２のデータ記録の第２の属性を比較させる、
請求項１１に記載のコンピュータ可読記憶媒体。
複数言語によるデータ記録を処理するシステムであって、
少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサによってアクセス可能であり、該少なくとも１つのプロセッサによって実行可能であるコンピュータ命令を記憶する、少なくとも１つのコンピュータ可読記憶媒体とを備え、該少なくとも１つのプロセッサによって実行されると、該コンピュータ命令は、該システムに、
単一アイデンティティハブにおいて受信される各データ記録について、該データ記録を言語と関連付けさせ、
該言語を特定のメンバー型に論理的に対応づけさせ、
該データ記録の属性に、該言語に特有である一意の導出コードを適用させ、該一意の導出コードは、言語特有の標準化および言語非依存型バケッティングを備え、該言語特有の標準化は、該言語に関する該データ記録の該属性を標準化し、
該言語に関する情報および該データ記録の該標準化された属性を利用して、個々の言語による実体を処理するように、１つ以上のアルゴリズムを自動的かつ最適に選択および適用させる、システム。