データウェアハウス内のデータの処理および検索のための方法とプログラム
【課題】データウエアハウスの精度、信頼性、および瞬時性を向上させる方法を提供する。
【解決手段】方法は、いかなるデータも失うことなく、受信されたデータ内のレコードと既存のデータ内のレコードとの間の関係に基づいてレコードを判別し対応付けする、ユーザ規定のアラートルールおよび相互関係に基づいてアラートを動作可能にする、レコードの対応付けに用いられた識別子が後になってエンティティ間で共通のものであって全体からみて一つのエンティティに対して特徴的なものでないことが分かった場合に、さらなる対応付けを停止し、以前に対応付けされたレコードを切り離す、データベースに格納されている処理済みデータの検索を依頼するデータ問い合わせを受信する、その問い合わせの処理に同一のアルゴリズムを用いる、処理済みデータを、同一のアルゴリズムを用いる他のデータベースに転送する、ことを含む。
【解決手段】方法は、いかなるデータも失うことなく、受信されたデータ内のレコードと既存のデータ内のレコードとの間の関係に基づいてレコードを判別し対応付けする、ユーザ規定のアラートルールおよび相互関係に基づいてアラートを動作可能にする、レコードの対応付けに用いられた識別子が後になってエンティティ間で共通のものであって全体からみて一つのエンティティに対して特徴的なものでないことが分かった場合に、さらなる対応付けを停止し、以前に対応付けされたレコードを切り離す、データベースに格納されている処理済みデータの検索を依頼するデータ問い合わせを受信する、その問い合わせの処理に同一のアルゴリズムを用いる、処理済みデータを、同一のアルゴリズムを用いる他のデータベースに転送する、ことを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にデータウェアハウス内のデータの処理および検索のための方法、プログラム、およびシステムに関するものであり、より詳細にはデータウェアハウスへのデータまたはデータウェアハウス内のデータの処理、データウェアハウス内のデータの問い合わせ、およびデータウェアハウス内のデータの解析のための方法、プログラム、およびシステムに関するものである。
【背景技術】
【０００２】
データウェアハウスとは、レコードを保存することに加えて、一般的に複数のソースからの問い合わせに対して応答するように構成されている、コンピュータを利用したデータベースのことである。レコードは、個人、組織、および所有物の如きエンティティと対応している。各レコードは、たとえば、個人の名称情報、アドレス情報、またはアカウント情報の如きそのエンティティの識別子を含んでいる。
【０００３】
残念なことには、特定のデータの品質、完全性、性能に関する問題を引き起こし、それらを永続化し、および／またはそれらを増加させるような特定の制限的事項のため、現在のデータウェアハウスシステムはその有効性が低下している。また、このような制限的事項のため、データウェアハウスシステムの実行、補正、および維持に必要とされるリスク、コスト、および時間が増加している。
【０００４】
上記の問題および制限的事項には、以下のような事項が含まれるが、これらの事項にのみ限定されるわけではない：（ａ）さまざまなデータソースからの異なるまたは相容れない形式に関連する問題、（ｂ）受信時点における情報の欠落に起因するデータの不完全性、（ｃ）不一致（軽微な場合が多い）または綴り違いに起因して同一のエンティティに対して複数のレコードが入力されること、（ｄ）複数のレコードが同一のエンティティを反映しているか否かおよび／または複数のレコード間になんらかの関係が存在するか否かの確認能力の不足、（ｅ）同一のエンティティを反映していると判定された二つのレコードが結合される場合またはその一方のレコードが廃棄される場合におけるデータの損失、（ｆ）結合されたレコードが後になってから二つの別々のエンティティを反映していたことが分かった場合にレコードを切り離す能力の不足、（ｇ）ユーザが規定したルールに基づいてリアルタイムでアラートを発生する能力の不足、（ｈ）受信データの処理に用いられるアルゴリズムまたは変換プロセスとは異なるアルゴリズムまたは変換プロセスを用いる問い合わせ（ｑｕｅｒｉｅｓ）からの不適切な結果、および（ｉ）特定の期間の如き所定の基準に従って持続的に問い合わせを維持する能力の欠如。
【０００５】
たとえば、個人の識別子が受信されデータベースに格納される場合には：（ａ）一方のソースからのレコードがコンマ区切り形式で入手可能であり、他方のソースからのレコードが他の形式で受信可能である場合、（ｂ）さまざまなレコードから、電話番号、アドレス、または他のなんらかの識別情報の如きデータが欠落している場合、または（ｃ）一方のレコードが現在の名前に対応しており他方のレコードが結婚前の名前に対応しているため、気付かないうちに、同一の個人を反映する二つのレコードが受信される場合がある。後者の場合、上記システムは、その二つのレコードを結合する必要があると判断するか、または一方のレコード（おそらく信頼性の低いソースからのレコード）を廃棄する必要があると判定しうる。しかしながら、現在のシステムは、通常、結合プロセスにおいてデータを廃棄するため、これらの二つのレコードが二つの別々のエンティティを反映していたことが後になってから分かった場合に、元の二つのレコードに分離した状態に戻すということができない。
【０００６】
さらに、識別子が受信されてデータベースに格納されるとき、コンピュータは、そのデータをデータベースにローディングするまえに、変換プロセスおよびエンハンスメントプロセスを実行しうる。しかしながら、現在のシステムの問い合わせツールは、データの受信および受信データの処理に用いられる変換プロセスおよびエンハンスメントプロセスをほとんど使用しないので、このような問い合わせによる結果は、整合性がなく、よって、不適切かつ不十分であり、正しくない可能性がある。
【０００７】
同様に、現在のデータウェアハウスシステムは、エンティティ間の関係を十分に特定するためにまたはリアルタイムでこれらのエンティティが同一のエンティティであるか否かを判定するために必要とされるツールを備えていない。たとえば、第一の個人が第二の個人と同一のアドレス有し、第二の個人が第三の個人と同一の電話番号を有している場合がある。このような状況では、第一の個人が第三の個人となんらかの関係を有している可能性を、とくにリアルタイムで判定することが効果的である場合がある。
【０００８】
さらに、現在のデータウェアハウスシステムは、エンティティ間の不適切なまたは矛盾する関係を見出し、ユーザが規定したアラートルールに基づいて、リアルタイムでアラートを発生する能力が限られている。この能力の限界は、たとえば、上記の関係を効率的に見出す能力を欠いていることを含むいくつかの要因によるものである。
【０００９】
さらに、現在のデータウェアハウスシステムは、まず、レコードを変換・エンハンスメントすることができず、さらに、所定の期間にわたり永続的な問い合わせを維持することができない。永続的な問い合わせは、たとえば、犯罪捜査においてある人の名前を特定するというようなケースを含むさまざまな状況において効果的である。上記の人に該当する人を特定する問い合わせは、最初はなんら結果を生じない場合もあるが、現在のシステムでは、実質的に、この問い合わせデータは廃棄される。しかしながら、受信データと同様に、この問い合わせデータをローディングすることは有効である。他の受信データまたは問い合わせデータとの照合に用いることにより、問い合わせデータは、さらに優れた根拠を結果に対して与えることが可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、現在のデータウェアハウスシステムの問題および限界のいずれかまたはすべては、そのデータウェアハウスの精度、信頼性、および瞬時性を低下させ、著しく性能を低下させている。実際、このような問題を抱えてながら利用すると、結果が不適切なものとなり、この結果に基づいて誤った結論を導き出してしまう恐れがある。
【００１１】
本発明は、このような問題および他の問題を解決すべくなされたものである。
【課題を解決するための手段】
【００１２】
本発明の目的は、データベースへのデータまたはデータベース内のデータを処理する方法、プログラム、およびシステムを提供することである。この方法は、（ａ）複数のエンティティのデータを受信するステップと、（ｂ）受信されたデータを処理するアルゴリズムを用いるステップと、（ｃ）処理されたデータをデータベースに格納するステップと、（ｄ）データベースに格納されたデータの検索に関するデータ問い合わせを受信するステップと、（ｅ）問い合わせの処理に同一のアルゴリズムを活用するステップとを有していることが好ましい。
【００１３】
上記データは、一または複数のエンティティを表す一または複数の識別子を有した一または複数のレコードからなっている。これらのエンティティは、個人、所有物、組織、タンパク質、または、識別データにより表されうる他のものであってもよい。
【００１４】
上記アルゴリズムは、標準メッセージ形式に変換されたデータを受信することを含み、ソースシステム、このソースシステムの識別子用の固有値、問い合わせシステム、および／またはユーザの如き識別子の属性情報を保持する。
【００１５】
上記アルゴリズムのプロセスは、データベースに格納まえのデータまたはデータベースの問い合わせられるまえのデータを解析することを含んでおり、この解析ステップは、（ａ）一もしくは複数の識別子を、ユーザ規定の基準とまたはデータベース、リスト、もしくは他の電子形式の内の一もしくは複数のデータセットと比較することと、（ｂ）ユーザ規定の基準に従って識別子を形式変換することと、（ｃ）受信されたデータを任意のさらなる識別子で補完するためのさらなる識別子の有無を、（最初のデータベースと同一のアルゴリズムを有し、カスケード式の探索を続けうる）他のデータベースまたはリストの内の一または複数のデータセットに対しての問い合わせを行うことにより、データを格納または問い合わせまえにエンハンスメントすることと、（ｄ）上記識別子に対してハッシュキーを作成することと、（ｄ）指定期間の如きユーザ規定の基準に基づいて処理された問い合わせを格納することとを含んでいる。
【００１６】
さらに、次のようなことが検討される。かかる方法、プログラム、およびシステムは、（ａ）データの処理およびレコードのマッチングにアルゴリズムを用いることと、（ｂ）マッチングされたレコードをデータベースに格納することとを含みうるし、上記アルゴリズムのプロセスは、（ｉ）受信データの識別子と同様な識別子を有する一群のレコードをデータベースから検索し、（ｉｉ）受信データにマッチングするレコードの有無を調べるために検索済の一群のレコードを解析し、（ｉｉｉ）同一のエンティティを反映していると判定される検索済のレコードと受信データをマッチングし、（ｉＶ）マッチング済のレコードのうちのいずれかになんらかの新規な識別子が追加されているか否かを解析し、（Ｖ）マッチング済のレコードのうちのいずれかにマッチングさせるべく、検索済の一群のレコードのうちのその他のレコードを再探索しうる。さらに、上記アルゴリズムは、（ａ）マッチングされたレコード内の識別子と同様な識別子を有するさらなる一群のレコードをデータベースから検索することと、（ｂ）レコードを検索するステップと、マッチングの有無を調べるために解析するステップと、同一のエンティティのレコードをマッチングさせるステップと、新規の識別子を探索するステップと、検索済みレコードを再サーチするステップとを、マッチングするレコードがそれ以上見つからなくなるまで、繰り返すことと、（ｃ）これらのレコードに対して永続キーを割り当てることとを有している。このプロセスはバッチ形式で実行されてもリアルタイムで実行されてもよい。
【００１７】
さらに、次のようなことが検討される。かかる方法、プログラム、およびシステムは、特定の識別子がエンティティ間で共通であるのかまたは全体からみて一つのエンティティに特徴的なものであるのかを判定することと、レコードのマッチングに用いられた特定の識別子が後になってエンティティ間で共通のものであって全体からみて一つのエンティティに特徴的なものでないことが分かった場合に、以前にマッチングされたレコードを切り離すこととを含んでいる。これらの判定ステップおよび切り離しステップは、リアルタイムで実行されてもバッチ形式で実行されてもよい。これらの判定ステップおよび切り離しステップは、エンティティ間で共通のものであって全体からみて特定のエンティティに特徴的なものでないことが分かった識別子に基づいてさらにマッチングすることを停止することと、切り離されたレコードを再び処理することとを含みうる。
【００１８】
さらに、次のようなことが検討される。受信データは、以前に格納された少なくとも一つのレコードと比較され、これらのエンティティ間に関係が存在するか否かが判定され、関係の存在する二つのエンティティ毎に一つの関係レコードが作成される。この関係レコードは、二つのエンティティ間の関係の可能性または二つのエンティティが同一である可能性を表す信頼性指数を含みうる。また、この関係レコードは、受信データに含まれるまたは割り当てられているエンティティの役割を掲示してもよい。この関係レコードは、ユーザ規定の基準の存在に基づいて、以前には分かっていなかった関連するレコードの存在を判定すべく解析される。この関係レコードは、一次の分解度を反映しており、この一次の分解度は、最大次数の分解度に従った試験すなわち最小関係レベルおよび／または類似信頼性指数の如き所定の基準を充足するレコードのみを含むように解析・展開されうる。ユーザ規定のアラートルールに基づいて一群の関連するレコードが特定されると、アラートが発生される。このアラートは、電子メールメッセージ、電話、携帯情報端末、またはビーパメッセージの如きさまざまな電子通信手段を利用して伝達されうる。
【００１９】
さらに、次のようなことが検討される。かかる方法は、（ａ）一または複数のデータベースに関係レコードを複製することと、（ｂ）作業量基準に基づいて、その追加のデータベースのうちの一または複数に受信データを分配し、解析することと、（ｃ）その追加のデータベースからのアラートを発行することとを含みうる。
【００２０】
さらに、次のようなことが検討される。かかる方法およびシステムは、格納されたデータを、最初のデータベースと同一のアルゴリズムを用いる他のデータベースに転送することを含みうる。上記の処理および転送はリアルタイムで実行されてもよいしバッチ形式で実行されてもよい。
【００２１】
本発明のこれらのまたは他の態様または属性を、以下の図面および付属の明細書を参照して説明する。
【発明を実施するための最良の形態】
【００２２】
本発明はさまざまな異なる形態で実施することが可能であるが、図面に記載されるとともに本明細書で詳細に説明される本発明の特定の実施例の開示は、本発明の原理を示す一例であって、ここで記載される特定の実施例により本発明を限定することを意図したものではない。
【００２３】
データベースへのデータおよびデータベース内のデータを処理し、処理された該データを検索するデータ処理システム10が図１〜図７に例示されている。このシステム10は、プロセッサ14とメモリ16とを有する少なくとも一つの従来型コンピュータ12を備えている。メモリ16は、データベース内およびランダムアクセスメモリ内のデータの格納のみならずシステム10を動作させるべく実行可能なソフトウェアの格納にも用いられる。しかしながら、このソフトウェアは、ＣＤ、ＤＶＤ、またはフロッピーディスクの如きその他のコンピュータ読み取り可能媒体に格納または搭載されてもよい。コンピュータ12は、複数のソース181〜18nから入力を受信しうる。
【００２４】
データは、一または複数のエンティティを表す一または複数の識別子を有している一または複数のレコードからなっている。これらのエンティティは、個人、組織、所有物、タンパク質、化学化合物もしくは有機化合物、バイオメトリック構造もしくは原子構造、または識別データによって表されうる他のものでありうる。個人タイプのエンティティの識別子には、個人の名称、住所、電話番号、クレジットカード番号、社会保障番号、職業情報、高頻度顧客優遇プログラムもしくは他の顧客プログラム、またはアカウント情報が含まれうる。全体からみて特徴的な識別子とは、個人エンティティの場合における社会保障番号の如きあるエンティティに特徴的な識別子のことである。
【００２５】
システム10は、複数のソース181〜18nからデータを受信し、アルゴリズム22を用いて受信データ20を処理する。このアルゴリズムは、メモリ16に格納され、プロセッサ14により処理または実行される。
【００２６】
たとえば受信データの属性情報（ソースシステム識別情報）を有する受信データ20は、複数のデータ形式で受信されると考えられる。アルゴリズム22により処理されるまえに、受信データ20は、国際メッセージ形式の如き標準メッセージ形式に24で変換される。
【００２７】
そのあと、図３に示されるように、アルゴリズム22は、標準化されたデータを26で受信し、データベースへの格納まえにまたは問い合わせまえに、その受信データ26を次のようにして28で解析する：（ａ）（ｉ）名称標準化30（たとえば、ルート名称リストとの比較）、（ｉｉ）アドレスハイジーン32（たとえば、郵便配達コードとの比較）（ｉｉｉ）フィールドの試験または変換34（たとえば、Ｍ／Ｆ確認のために性別フィールドの比較、またはＭａｌｅからＭへの変換など）、（ｉＶ）ユーザ規定の形式への変換36（たとえば、９９９−９９−９９９９形式へのすべての社会保障番号の変換）を含む複数の機能を実行すべく受信データ26をユーザ規定の基準またはルールと比較し、（ｂ）受信データ26を42で補完しうる（かつ受信データ20として伝送されうる）さらなる情報を探索すべく、システム10に、（最初のデータベースと同一のアルゴリズムを備え、カスケード式にこのシステムに追加のデータベースにアクセスさせうる）一または複数のデータベースに40でアクセスさせ、これによりデータを38でエンハンスメントさせ、（ｃ）解析されたデータからハッシュキーを44で構築する。元のデータの完全性を維持するために、新規に変更データまたはエンハンスメントデータは、いずれも、新規の作成されるフィールドに格納される。たとえば、名称「Ｂｏｂｂｙ Ｓｍｉｔｈ」が標準形式により26で受信された場合、この名称「Ｂｏｂｂｙ」は、ルート名称リストと30で比較され、名称「Ｒｏｂｅｒｔ」へ標準化され、この標準名称で新規に作成されるフィールドに保存される。さらに、Ｂｏｂｂｙ Ｓｍｉｔｈの名称および住所が26で受信される場合、システム10は、従来型のインターネットを利用した人物検索用データベース40にアクセスしてＢｏｂｂｙ Ｓｍｉｔｈの電話番号を取得することができ、次いで、この電話番号は、ユーザ規定の基準36に基づく標準的な方法で形式変換されうる。さらに、アドレスフィールドがアドレスリスト32と比較されて、標準アドレスの最後に、テキスト「Ｓｔｒｅｅｔ」が追加されうる。その後、ハッシュキーが、エンハンスメントされたデータに基づいて44で構築され、新規に作成されたフィールドに格納される。
【００２８】
また、システム10は、複数のソース181〜18nから問い合わせ46を受信し、同一のアルゴリズム22を用いて、受信された問い合わせ46を分析・処理する。たとえば、「Ｂｏｂｂｙ Ｓｍｉｔｈ」に対する問い合わせ46が受信される場合、受信された名称「Ｂｏｂｂｙ」を名称「Ｒｏｂｅｒｔ」に標準化する同一のアルゴリズム22が、また、問い合わされた名称「Ｂｏｂｂｙ」を名称「Ｒｏｂｅｒｔ」に標準化する。実際、システム10は、受信されたデータ20と同様に、受信された問い合わせ46をローディングし格納することにより、その問い合わせシステムおよびユーザのすべての属性を維持する。したがって、システム10が受信された問い合わせ46を処理するとき、アルゴリズム22は、欠けている情報を探すべく、公の記録データベースの如き他のデータベース40を探索しうる。問い合わせ結果94は、完全一致よりも幅の広いものであり、関連一致を含みうる。たとえば、問い合わせが「Ｂｏｂｂｙ Ｓｍｉｔｈ」に関するものである場合、この問い合わせ結果94は、Ｂｏｂｂｙ Ｓｍｉｔｈのクレジィットカードを使用したことのある人達のレコード、またはＢｏｂｙ Ｓｍｉｔｈのアドレスに住んだことのある人達のレコードを含みうる。
【００２９】
また、アルゴリズム22は、任意の受信データが26で受信されると、（ａ）この受信データに対応するエンティティと一致する既存のレコードがデータベース内に存在するか否かを判定し、（ｂ）それが存在する場合には、受信データと既存のレコードとをマッチングする機能を実行しうる。たとえば、上記のアルゴリズムは、有力な候補の有無を調べるため、データベースにおいて（受信データ内の識別子と同様の識別子を有する）一群のレコード48を検索し、全体から見て特徴的な識別子52に基づいて、既存の格納されたレコードのうちの受信されたデータに対応するレコードを特定するようなマッチング50の有無を調べるため、検索された一群のレコードを解析する。54でマッチングが特定される場合、上記のアルゴリズムは、マッチングされたレコードが、なんらかの新規なまたは以前に知られていない識別子56を有しているか否かを解析する。新規なまたは以前に知られていない識別子56が存在する場合、アルゴリズム22は、その新規なまたは以前に知られていない識別子56を解析し、そのマッチングされたレコード内の新規なまたは以前に知られていない識別子に基づいて、70で候補リスト／関係レコードを追加または更新し、なんらかのマッチング50がさらに存在するか否かを判定する。このプロセスは、マッチングがさらに見出されなくなるまで繰り返される。その後、このマッチングプロセスは、マッチングされたレコードのすべてに対して同一の永続キー60を割り当てる。さらに、マッチングがいずれのレコードに対しても見出されない場合、マッチングされなかったレコードにはそれ独自の永続キー62が割り当てられる。これらのレコードは、データの属性情報を完全に保持しており、マッチングプロセスでは、結合機能、排除機能、または削除機能によるいかなるデータの損失もない。
【００３０】
たとえば、レコード＃１が、個人の名称、電話番号、およびアドレスを有しており、レコード＃２が、同一の名称、およびクレジットカード番号を有している場合、これらの個人が同一の個人であるか否かを判断することはできないため、これらのレコードは別々に保管されなければならない。その後、レコード＃３のデータが受信され、そのデータが、（レコード＃１と同一の）名称と、（レコード＃１と同一の）アドレスと、（レコード＃１と同一の）電話番号と、クレジットカード番号と有している場合、レコード＃１とレコード＃３の名称、アドレス、および電話番号が一致するので、システム10は、レコード＃１およびレコード＃３が同一の個人を表していると判定しうるし、このことを受けて、上記のアルゴリズムは、レコード＃１のデータをレコード＃３のデータとマッチングさせる。次いで、システム10は、上記のアルゴリズムを再度実行し、マッチングさせられたレコード＃１を、候補リストのうちのその他のレコードと、またはこのマッチングさせられたレコードと同様の識別子を有するさらなるレコードと比較する。マッチングさせられたレコード＃１の名称およびクレジットカード番号がレコード＃２の名称およびクレジットカード番号とマッチングするので、これら二つのレコードもまたマッチングする。そして、このマッチングされたレコードは、マッチングが得られなくなるまで、54においてマッチングの有無を調べるべく、候補リストまたは検索されたさらなるレコードに対して再び試験される。
【００３１】
場合によって、システム10は、二つのレコードが誤ってマッチングされていると判定することがある。たとえば、社会保障番号は、個人に対し、全体から見て特徴的な識別子であると考えられているので、同一の社会保障番号に基づいてレコードをマッチングすることが多い。しかしながら、ある種の状況では、この番号がエンティティ間においてよくある番号であり、一つのエンティティに対して全体から見て特徴的な番号ではないということが後になってからわかる場合がある。たとえば、社会保障番号がレコードフィールドとして必要なフィールドであるデータを入力する作業において、データを入力する作業員が個人個人の社会保障番号を知らず、個人の社会保障番号として、単に「１２３−４５−６７８９」と入力する場合を考える。
【００３２】
この場合、社会保障番号は、このようなタイプの個人エンティティおいてその全体にわ
たり共通のものであり、もはや、これらの個人に対し、全体から見て特徴的な識別子ではない。したがって、（ａ）この時点で共通であると分かった識別子を共通識別子のリストに追加し、すべての将来のプロセスでは、70において、この時点で共通であることが分かった識別子に基づく候補リスト用のレコード検索または関係レコードの作成を行わず、64における今後のマッチングを停止し、（ｂ）上記の社会保障番号の誤用に基づいてマッチングされたレコードを、マッチングまえのデータを反映するように切り離す必要がある。この後者の目的を達成するために、システム10は、データを損失することなく、そのデータのすべての属性情報に従って、誤った想定以前のところまで、その誤った想定66に基づいて行ったマッチングを切り離して元に戻す。したがって、（「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」へと標準化されている）「Ｂｏｂｂｙ Ｓｍｉｔｈ」に関するレコード＃１が「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」に関するレコード＃２とマッチングされており、これらが別々の二人であり、これらの二人を最初のレコード＃１とレコード＃２とに切り離して元に戻す必要があるということが後になってから決定された場合には、上記のアルゴリズムは、レコード＃１における標準化された「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」が「Ｂｏｂｂｙ」として知られていたことを識別しうる。さらに、上記の決定ステップおよび切り離しステップは、リアルタイムで実行されてもよいしまたはバッチ形式で実行されてもよい。さらに、上記の切り離されたレコードは、新規に受信されたデータとして再び送信され、システムにおいて処理されてもよい。
【００３３】
また、関係が明白なものでなくともその関係を評価すること68が必要な場合がある。たとえば、個人＃１および個人＃２がそれぞれ組織＃３と関係を有して場合がある。したがって、個人＃１と個人＃２との間に関係が存在する有望な可能性がある。これらの関係は、いくつかの次数の分解度にまで広げられうる。したがって、システム10は、すべての受信データを、格納されているデータのすべてのレコードと比較し、それぞれのエンティティ間になんらかの関係が存在するすべてのレコード対に対して関係レコードを70で作成する。この関係レコード70は、関係タイプ（たとえば、父、共謀者）と、信頼性指数（二つのエンティティの関係の強度を表すスコア）72と、割り当てられた永続キー60、62とを有している。たとえば、信頼性指数72は、関係スコアと類似スコアとを有しうる。この関係スコアは、個人＃１と個人＃２との間に関係が存在する可能性を表す、たとえば１から１０までの間の指数である。また、類似指数は、個人＃１が個人＃２と同一の人物であることを表す、たとえば１から１０までの間の指数である。信頼性指数72は、上記のマッチングプロセス中に割り出されうる。
【００３４】
また、システム10は、二つのエンティティの間の不適切な関係の如き、または信頼性指数が所定の値を超えるおよび／もしくは分解度が所定の値を下回る関係レコードに基づく特定パターンのアクティビティの如き、ユーザ規定のアラートルール74の基準を充足する状態の存在を判定すべく、受信されたデータ20および問い合わせ46を解析する。たとえば、システム10は、不正なクレジットカードのリストを有しうる。このリストは、受信されたデータまたは問い合わせがこの不正クレジットカード番号のリスト上にあるクレジットカード番号を有しているか否かを判定するために用いられうる。さらに、ユーザ規定のアラートルール74により、受信データまたは問い合わせに関する調査報告される。たとえば、新規のベンダーのデータの入力の際に、この新規のベンダーが現在の従業員と同一のアドレスを有しており、そのベンダーと従業員との間に雇用者がおそらく調査を望むようななんらかの関係を示していると判定される場合に対するアラートルールが存在しうる。ユーザ規定のアラートルールの実行の引き金となりうる状況が検出されると、システム10は、アラート74を発行する。このアラートは、電子メールを介したメッセージの如きさまざまな媒体を通じて伝達されてもよいし、英数式ビーパ、情報携帯端末、または電話機の如きハンドヘルド通信デバイスへ伝達されてもよい。
【００３５】
たとえば、最大６次の分離度の範囲78において７を超える関係尤度信頼性指数（ｌｉｋｅｌｉｈｏｏｄ ｏｆ ｒｅｌａｔｉｏｎｓｈｉｐ ｃｏｎｆｉｄｅｎｃｅ ｉｎｄｉｃａｔｏｒ）76を有するレコードのすべてに対するユーザ規定のアラートルールをベースにする場合、システム10は、（ａ）個人＃１から開始し、（ｂ）76で７を超える信頼性指数を有する、個人＃１に関連する他のすべての個人を80において見出し、（ｃ）80における個人のうちの１次の分解度に該当するものをすべて分析し、84で７を超える信頼性指数を有する、１次の分解度に相当する個人80に関連するすべての個人を82において決定し、（ｄ）６次の分解度パラメータ78を充足するまでプロセスを繰り返す。上記システムは、（ユーザ規定の基準に基づいて得られたレコードのすべてを含みうる）アラート74を電子的に関連する個人または別のシステムに送信し、次のアクションを可能にし得る。
【００３６】
さらに、関係レコード70は、複数のデータベースにわたり複製されうる。受信データを20で受信すると、上記システムは、その他のデータベースの各々の作業量の状態を体系的に評価し、格納されている解析済みレコード68を最も効率的に解析しうるデータベースに対し、マッチング済／関係付け済み／解析済みレコードを分散しうる。次いで、アラート74は、それが、その他のデータベースから発生するいかなる原因によるいかなるアラートであっても、発生されうる。
【００３７】
最終的に、処理されたデータは、リアルタイムまたはバッチプロセス形式で、ウェアハウス発行リストに段階的に86従って、同一のアルゴリズム92を用いうるさらなるデータベースに88で転送されうる。このようにして、転送データ88は、このデータの関係を特定、マッチング、または処理するめに、さらなるデータベースおよびそれに続くデータベースの内の（異なるデータを含みうる）データとマッチングさせるべく用いられうる。たとえば、上記の信頼性指数に基づいてマッチングされたローカルデータベース内のレコードは、比較される地域データベースに88において転送され、同一のアルゴリズム92を用いてデータとマッチングされてもよい。その後、地域データベースから得られる処理済データは、ナショナルオフィスに88で転送されてもよい。各ステップにおいて処理されたデータを、とくにリアルタイムで結合することにより、組織またはシステムユーザは、不適切なまたは矛盾するデータを割り出し、さらなるアクションを促すことが可能になる。
【００３８】
上記の方法、プログラム、およびシステムの機能的な側面を実現するために、従来のソフトウェアコードを用いることができる。このコードは、単一のコンピュータ、またはインターネットの如き分散型コンピュータネットワークによる使用のためのいかなるコンピュータ読み取り可能媒体に搭載されてもよい。
【００３９】
以上により、本発明の精神および範疇から逸脱することなく複数の変形および改良が可能であることが明らかである。いうまでもなく、本明細書記載の特定の装置は、限定を意図したものでもなければ推測されるべきものでもない。また、いうまでもなく、添付のクレームの範疇に含まれるような上述の変形すべてを当該クレームにより網羅することを意図している。
【図面の簡単な説明】
【００４０】
【図１】本発明にかかるシステムのブロック線図である。
【図２】図１に示されるシステムブロックのデータ処理を示すフローチャートである。
【図３】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図４】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図５】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図６】図５に示される、格納されている解析済みレコードの評価のフローチャートである。
【図７】図５に示される、格納されている解析済みレコードの評価のフローチャートである。
【技術分野】
【０００１】
本発明は、一般的にデータウェアハウス内のデータの処理および検索のための方法、プログラム、およびシステムに関するものであり、より詳細にはデータウェアハウスへのデータまたはデータウェアハウス内のデータの処理、データウェアハウス内のデータの問い合わせ、およびデータウェアハウス内のデータの解析のための方法、プログラム、およびシステムに関するものである。
【背景技術】
【０００２】
データウェアハウスとは、レコードを保存することに加えて、一般的に複数のソースからの問い合わせに対して応答するように構成されている、コンピュータを利用したデータベースのことである。レコードは、個人、組織、および所有物の如きエンティティと対応している。各レコードは、たとえば、個人の名称情報、アドレス情報、またはアカウント情報の如きそのエンティティの識別子を含んでいる。
【０００３】
残念なことには、特定のデータの品質、完全性、性能に関する問題を引き起こし、それらを永続化し、および／またはそれらを増加させるような特定の制限的事項のため、現在のデータウェアハウスシステムはその有効性が低下している。また、このような制限的事項のため、データウェアハウスシステムの実行、補正、および維持に必要とされるリスク、コスト、および時間が増加している。
【０００４】
上記の問題および制限的事項には、以下のような事項が含まれるが、これらの事項にのみ限定されるわけではない：（ａ）さまざまなデータソースからの異なるまたは相容れない形式に関連する問題、（ｂ）受信時点における情報の欠落に起因するデータの不完全性、（ｃ）不一致（軽微な場合が多い）または綴り違いに起因して同一のエンティティに対して複数のレコードが入力されること、（ｄ）複数のレコードが同一のエンティティを反映しているか否かおよび／または複数のレコード間になんらかの関係が存在するか否かの確認能力の不足、（ｅ）同一のエンティティを反映していると判定された二つのレコードが結合される場合またはその一方のレコードが廃棄される場合におけるデータの損失、（ｆ）結合されたレコードが後になってから二つの別々のエンティティを反映していたことが分かった場合にレコードを切り離す能力の不足、（ｇ）ユーザが規定したルールに基づいてリアルタイムでアラートを発生する能力の不足、（ｈ）受信データの処理に用いられるアルゴリズムまたは変換プロセスとは異なるアルゴリズムまたは変換プロセスを用いる問い合わせ（ｑｕｅｒｉｅｓ）からの不適切な結果、および（ｉ）特定の期間の如き所定の基準に従って持続的に問い合わせを維持する能力の欠如。
【０００５】
たとえば、個人の識別子が受信されデータベースに格納される場合には：（ａ）一方のソースからのレコードがコンマ区切り形式で入手可能であり、他方のソースからのレコードが他の形式で受信可能である場合、（ｂ）さまざまなレコードから、電話番号、アドレス、または他のなんらかの識別情報の如きデータが欠落している場合、または（ｃ）一方のレコードが現在の名前に対応しており他方のレコードが結婚前の名前に対応しているため、気付かないうちに、同一の個人を反映する二つのレコードが受信される場合がある。後者の場合、上記システムは、その二つのレコードを結合する必要があると判断するか、または一方のレコード（おそらく信頼性の低いソースからのレコード）を廃棄する必要があると判定しうる。しかしながら、現在のシステムは、通常、結合プロセスにおいてデータを廃棄するため、これらの二つのレコードが二つの別々のエンティティを反映していたことが後になってから分かった場合に、元の二つのレコードに分離した状態に戻すということができない。
【０００６】
さらに、識別子が受信されてデータベースに格納されるとき、コンピュータは、そのデータをデータベースにローディングするまえに、変換プロセスおよびエンハンスメントプロセスを実行しうる。しかしながら、現在のシステムの問い合わせツールは、データの受信および受信データの処理に用いられる変換プロセスおよびエンハンスメントプロセスをほとんど使用しないので、このような問い合わせによる結果は、整合性がなく、よって、不適切かつ不十分であり、正しくない可能性がある。
【０００７】
同様に、現在のデータウェアハウスシステムは、エンティティ間の関係を十分に特定するためにまたはリアルタイムでこれらのエンティティが同一のエンティティであるか否かを判定するために必要とされるツールを備えていない。たとえば、第一の個人が第二の個人と同一のアドレス有し、第二の個人が第三の個人と同一の電話番号を有している場合がある。このような状況では、第一の個人が第三の個人となんらかの関係を有している可能性を、とくにリアルタイムで判定することが効果的である場合がある。
【０００８】
さらに、現在のデータウェアハウスシステムは、エンティティ間の不適切なまたは矛盾する関係を見出し、ユーザが規定したアラートルールに基づいて、リアルタイムでアラートを発生する能力が限られている。この能力の限界は、たとえば、上記の関係を効率的に見出す能力を欠いていることを含むいくつかの要因によるものである。
【０００９】
さらに、現在のデータウェアハウスシステムは、まず、レコードを変換・エンハンスメントすることができず、さらに、所定の期間にわたり永続的な問い合わせを維持することができない。永続的な問い合わせは、たとえば、犯罪捜査においてある人の名前を特定するというようなケースを含むさまざまな状況において効果的である。上記の人に該当する人を特定する問い合わせは、最初はなんら結果を生じない場合もあるが、現在のシステムでは、実質的に、この問い合わせデータは廃棄される。しかしながら、受信データと同様に、この問い合わせデータをローディングすることは有効である。他の受信データまたは問い合わせデータとの照合に用いることにより、問い合わせデータは、さらに優れた根拠を結果に対して与えることが可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、現在のデータウェアハウスシステムの問題および限界のいずれかまたはすべては、そのデータウェアハウスの精度、信頼性、および瞬時性を低下させ、著しく性能を低下させている。実際、このような問題を抱えてながら利用すると、結果が不適切なものとなり、この結果に基づいて誤った結論を導き出してしまう恐れがある。
【００１１】
本発明は、このような問題および他の問題を解決すべくなされたものである。
【課題を解決するための手段】
【００１２】
本発明の目的は、データベースへのデータまたはデータベース内のデータを処理する方法、プログラム、およびシステムを提供することである。この方法は、（ａ）複数のエンティティのデータを受信するステップと、（ｂ）受信されたデータを処理するアルゴリズムを用いるステップと、（ｃ）処理されたデータをデータベースに格納するステップと、（ｄ）データベースに格納されたデータの検索に関するデータ問い合わせを受信するステップと、（ｅ）問い合わせの処理に同一のアルゴリズムを活用するステップとを有していることが好ましい。
【００１３】
上記データは、一または複数のエンティティを表す一または複数の識別子を有した一または複数のレコードからなっている。これらのエンティティは、個人、所有物、組織、タンパク質、または、識別データにより表されうる他のものであってもよい。
【００１４】
上記アルゴリズムは、標準メッセージ形式に変換されたデータを受信することを含み、ソースシステム、このソースシステムの識別子用の固有値、問い合わせシステム、および／またはユーザの如き識別子の属性情報を保持する。
【００１５】
上記アルゴリズムのプロセスは、データベースに格納まえのデータまたはデータベースの問い合わせられるまえのデータを解析することを含んでおり、この解析ステップは、（ａ）一もしくは複数の識別子を、ユーザ規定の基準とまたはデータベース、リスト、もしくは他の電子形式の内の一もしくは複数のデータセットと比較することと、（ｂ）ユーザ規定の基準に従って識別子を形式変換することと、（ｃ）受信されたデータを任意のさらなる識別子で補完するためのさらなる識別子の有無を、（最初のデータベースと同一のアルゴリズムを有し、カスケード式の探索を続けうる）他のデータベースまたはリストの内の一または複数のデータセットに対しての問い合わせを行うことにより、データを格納または問い合わせまえにエンハンスメントすることと、（ｄ）上記識別子に対してハッシュキーを作成することと、（ｄ）指定期間の如きユーザ規定の基準に基づいて処理された問い合わせを格納することとを含んでいる。
【００１６】
さらに、次のようなことが検討される。かかる方法、プログラム、およびシステムは、（ａ）データの処理およびレコードのマッチングにアルゴリズムを用いることと、（ｂ）マッチングされたレコードをデータベースに格納することとを含みうるし、上記アルゴリズムのプロセスは、（ｉ）受信データの識別子と同様な識別子を有する一群のレコードをデータベースから検索し、（ｉｉ）受信データにマッチングするレコードの有無を調べるために検索済の一群のレコードを解析し、（ｉｉｉ）同一のエンティティを反映していると判定される検索済のレコードと受信データをマッチングし、（ｉＶ）マッチング済のレコードのうちのいずれかになんらかの新規な識別子が追加されているか否かを解析し、（Ｖ）マッチング済のレコードのうちのいずれかにマッチングさせるべく、検索済の一群のレコードのうちのその他のレコードを再探索しうる。さらに、上記アルゴリズムは、（ａ）マッチングされたレコード内の識別子と同様な識別子を有するさらなる一群のレコードをデータベースから検索することと、（ｂ）レコードを検索するステップと、マッチングの有無を調べるために解析するステップと、同一のエンティティのレコードをマッチングさせるステップと、新規の識別子を探索するステップと、検索済みレコードを再サーチするステップとを、マッチングするレコードがそれ以上見つからなくなるまで、繰り返すことと、（ｃ）これらのレコードに対して永続キーを割り当てることとを有している。このプロセスはバッチ形式で実行されてもリアルタイムで実行されてもよい。
【００１７】
さらに、次のようなことが検討される。かかる方法、プログラム、およびシステムは、特定の識別子がエンティティ間で共通であるのかまたは全体からみて一つのエンティティに特徴的なものであるのかを判定することと、レコードのマッチングに用いられた特定の識別子が後になってエンティティ間で共通のものであって全体からみて一つのエンティティに特徴的なものでないことが分かった場合に、以前にマッチングされたレコードを切り離すこととを含んでいる。これらの判定ステップおよび切り離しステップは、リアルタイムで実行されてもバッチ形式で実行されてもよい。これらの判定ステップおよび切り離しステップは、エンティティ間で共通のものであって全体からみて特定のエンティティに特徴的なものでないことが分かった識別子に基づいてさらにマッチングすることを停止することと、切り離されたレコードを再び処理することとを含みうる。
【００１８】
さらに、次のようなことが検討される。受信データは、以前に格納された少なくとも一つのレコードと比較され、これらのエンティティ間に関係が存在するか否かが判定され、関係の存在する二つのエンティティ毎に一つの関係レコードが作成される。この関係レコードは、二つのエンティティ間の関係の可能性または二つのエンティティが同一である可能性を表す信頼性指数を含みうる。また、この関係レコードは、受信データに含まれるまたは割り当てられているエンティティの役割を掲示してもよい。この関係レコードは、ユーザ規定の基準の存在に基づいて、以前には分かっていなかった関連するレコードの存在を判定すべく解析される。この関係レコードは、一次の分解度を反映しており、この一次の分解度は、最大次数の分解度に従った試験すなわち最小関係レベルおよび／または類似信頼性指数の如き所定の基準を充足するレコードのみを含むように解析・展開されうる。ユーザ規定のアラートルールに基づいて一群の関連するレコードが特定されると、アラートが発生される。このアラートは、電子メールメッセージ、電話、携帯情報端末、またはビーパメッセージの如きさまざまな電子通信手段を利用して伝達されうる。
【００１９】
さらに、次のようなことが検討される。かかる方法は、（ａ）一または複数のデータベースに関係レコードを複製することと、（ｂ）作業量基準に基づいて、その追加のデータベースのうちの一または複数に受信データを分配し、解析することと、（ｃ）その追加のデータベースからのアラートを発行することとを含みうる。
【００２０】
さらに、次のようなことが検討される。かかる方法およびシステムは、格納されたデータを、最初のデータベースと同一のアルゴリズムを用いる他のデータベースに転送することを含みうる。上記の処理および転送はリアルタイムで実行されてもよいしバッチ形式で実行されてもよい。
【００２１】
本発明のこれらのまたは他の態様または属性を、以下の図面および付属の明細書を参照して説明する。
【発明を実施するための最良の形態】
【００２２】
本発明はさまざまな異なる形態で実施することが可能であるが、図面に記載されるとともに本明細書で詳細に説明される本発明の特定の実施例の開示は、本発明の原理を示す一例であって、ここで記載される特定の実施例により本発明を限定することを意図したものではない。
【００２３】
データベースへのデータおよびデータベース内のデータを処理し、処理された該データを検索するデータ処理システム10が図１〜図７に例示されている。このシステム10は、プロセッサ14とメモリ16とを有する少なくとも一つの従来型コンピュータ12を備えている。メモリ16は、データベース内およびランダムアクセスメモリ内のデータの格納のみならずシステム10を動作させるべく実行可能なソフトウェアの格納にも用いられる。しかしながら、このソフトウェアは、ＣＤ、ＤＶＤ、またはフロッピーディスクの如きその他のコンピュータ読み取り可能媒体に格納または搭載されてもよい。コンピュータ12は、複数のソース181〜18nから入力を受信しうる。
【００２４】
データは、一または複数のエンティティを表す一または複数の識別子を有している一または複数のレコードからなっている。これらのエンティティは、個人、組織、所有物、タンパク質、化学化合物もしくは有機化合物、バイオメトリック構造もしくは原子構造、または識別データによって表されうる他のものでありうる。個人タイプのエンティティの識別子には、個人の名称、住所、電話番号、クレジットカード番号、社会保障番号、職業情報、高頻度顧客優遇プログラムもしくは他の顧客プログラム、またはアカウント情報が含まれうる。全体からみて特徴的な識別子とは、個人エンティティの場合における社会保障番号の如きあるエンティティに特徴的な識別子のことである。
【００２５】
システム10は、複数のソース181〜18nからデータを受信し、アルゴリズム22を用いて受信データ20を処理する。このアルゴリズムは、メモリ16に格納され、プロセッサ14により処理または実行される。
【００２６】
たとえば受信データの属性情報（ソースシステム識別情報）を有する受信データ20は、複数のデータ形式で受信されると考えられる。アルゴリズム22により処理されるまえに、受信データ20は、国際メッセージ形式の如き標準メッセージ形式に24で変換される。
【００２７】
そのあと、図３に示されるように、アルゴリズム22は、標準化されたデータを26で受信し、データベースへの格納まえにまたは問い合わせまえに、その受信データ26を次のようにして28で解析する：（ａ）（ｉ）名称標準化30（たとえば、ルート名称リストとの比較）、（ｉｉ）アドレスハイジーン32（たとえば、郵便配達コードとの比較）（ｉｉｉ）フィールドの試験または変換34（たとえば、Ｍ／Ｆ確認のために性別フィールドの比較、またはＭａｌｅからＭへの変換など）、（ｉＶ）ユーザ規定の形式への変換36（たとえば、９９９−９９−９９９９形式へのすべての社会保障番号の変換）を含む複数の機能を実行すべく受信データ26をユーザ規定の基準またはルールと比較し、（ｂ）受信データ26を42で補完しうる（かつ受信データ20として伝送されうる）さらなる情報を探索すべく、システム10に、（最初のデータベースと同一のアルゴリズムを備え、カスケード式にこのシステムに追加のデータベースにアクセスさせうる）一または複数のデータベースに40でアクセスさせ、これによりデータを38でエンハンスメントさせ、（ｃ）解析されたデータからハッシュキーを44で構築する。元のデータの完全性を維持するために、新規に変更データまたはエンハンスメントデータは、いずれも、新規の作成されるフィールドに格納される。たとえば、名称「Ｂｏｂｂｙ Ｓｍｉｔｈ」が標準形式により26で受信された場合、この名称「Ｂｏｂｂｙ」は、ルート名称リストと30で比較され、名称「Ｒｏｂｅｒｔ」へ標準化され、この標準名称で新規に作成されるフィールドに保存される。さらに、Ｂｏｂｂｙ Ｓｍｉｔｈの名称および住所が26で受信される場合、システム10は、従来型のインターネットを利用した人物検索用データベース40にアクセスしてＢｏｂｂｙ Ｓｍｉｔｈの電話番号を取得することができ、次いで、この電話番号は、ユーザ規定の基準36に基づく標準的な方法で形式変換されうる。さらに、アドレスフィールドがアドレスリスト32と比較されて、標準アドレスの最後に、テキスト「Ｓｔｒｅｅｔ」が追加されうる。その後、ハッシュキーが、エンハンスメントされたデータに基づいて44で構築され、新規に作成されたフィールドに格納される。
【００２８】
また、システム10は、複数のソース181〜18nから問い合わせ46を受信し、同一のアルゴリズム22を用いて、受信された問い合わせ46を分析・処理する。たとえば、「Ｂｏｂｂｙ Ｓｍｉｔｈ」に対する問い合わせ46が受信される場合、受信された名称「Ｂｏｂｂｙ」を名称「Ｒｏｂｅｒｔ」に標準化する同一のアルゴリズム22が、また、問い合わされた名称「Ｂｏｂｂｙ」を名称「Ｒｏｂｅｒｔ」に標準化する。実際、システム10は、受信されたデータ20と同様に、受信された問い合わせ46をローディングし格納することにより、その問い合わせシステムおよびユーザのすべての属性を維持する。したがって、システム10が受信された問い合わせ46を処理するとき、アルゴリズム22は、欠けている情報を探すべく、公の記録データベースの如き他のデータベース40を探索しうる。問い合わせ結果94は、完全一致よりも幅の広いものであり、関連一致を含みうる。たとえば、問い合わせが「Ｂｏｂｂｙ Ｓｍｉｔｈ」に関するものである場合、この問い合わせ結果94は、Ｂｏｂｂｙ Ｓｍｉｔｈのクレジィットカードを使用したことのある人達のレコード、またはＢｏｂｙ Ｓｍｉｔｈのアドレスに住んだことのある人達のレコードを含みうる。
【００２９】
また、アルゴリズム22は、任意の受信データが26で受信されると、（ａ）この受信データに対応するエンティティと一致する既存のレコードがデータベース内に存在するか否かを判定し、（ｂ）それが存在する場合には、受信データと既存のレコードとをマッチングする機能を実行しうる。たとえば、上記のアルゴリズムは、有力な候補の有無を調べるため、データベースにおいて（受信データ内の識別子と同様の識別子を有する）一群のレコード48を検索し、全体から見て特徴的な識別子52に基づいて、既存の格納されたレコードのうちの受信されたデータに対応するレコードを特定するようなマッチング50の有無を調べるため、検索された一群のレコードを解析する。54でマッチングが特定される場合、上記のアルゴリズムは、マッチングされたレコードが、なんらかの新規なまたは以前に知られていない識別子56を有しているか否かを解析する。新規なまたは以前に知られていない識別子56が存在する場合、アルゴリズム22は、その新規なまたは以前に知られていない識別子56を解析し、そのマッチングされたレコード内の新規なまたは以前に知られていない識別子に基づいて、70で候補リスト／関係レコードを追加または更新し、なんらかのマッチング50がさらに存在するか否かを判定する。このプロセスは、マッチングがさらに見出されなくなるまで繰り返される。その後、このマッチングプロセスは、マッチングされたレコードのすべてに対して同一の永続キー60を割り当てる。さらに、マッチングがいずれのレコードに対しても見出されない場合、マッチングされなかったレコードにはそれ独自の永続キー62が割り当てられる。これらのレコードは、データの属性情報を完全に保持しており、マッチングプロセスでは、結合機能、排除機能、または削除機能によるいかなるデータの損失もない。
【００３０】
たとえば、レコード＃１が、個人の名称、電話番号、およびアドレスを有しており、レコード＃２が、同一の名称、およびクレジットカード番号を有している場合、これらの個人が同一の個人であるか否かを判断することはできないため、これらのレコードは別々に保管されなければならない。その後、レコード＃３のデータが受信され、そのデータが、（レコード＃１と同一の）名称と、（レコード＃１と同一の）アドレスと、（レコード＃１と同一の）電話番号と、クレジットカード番号と有している場合、レコード＃１とレコード＃３の名称、アドレス、および電話番号が一致するので、システム10は、レコード＃１およびレコード＃３が同一の個人を表していると判定しうるし、このことを受けて、上記のアルゴリズムは、レコード＃１のデータをレコード＃３のデータとマッチングさせる。次いで、システム10は、上記のアルゴリズムを再度実行し、マッチングさせられたレコード＃１を、候補リストのうちのその他のレコードと、またはこのマッチングさせられたレコードと同様の識別子を有するさらなるレコードと比較する。マッチングさせられたレコード＃１の名称およびクレジットカード番号がレコード＃２の名称およびクレジットカード番号とマッチングするので、これら二つのレコードもまたマッチングする。そして、このマッチングされたレコードは、マッチングが得られなくなるまで、54においてマッチングの有無を調べるべく、候補リストまたは検索されたさらなるレコードに対して再び試験される。
【００３１】
場合によって、システム10は、二つのレコードが誤ってマッチングされていると判定することがある。たとえば、社会保障番号は、個人に対し、全体から見て特徴的な識別子であると考えられているので、同一の社会保障番号に基づいてレコードをマッチングすることが多い。しかしながら、ある種の状況では、この番号がエンティティ間においてよくある番号であり、一つのエンティティに対して全体から見て特徴的な番号ではないということが後になってからわかる場合がある。たとえば、社会保障番号がレコードフィールドとして必要なフィールドであるデータを入力する作業において、データを入力する作業員が個人個人の社会保障番号を知らず、個人の社会保障番号として、単に「１２３−４５−６７８９」と入力する場合を考える。
【００３２】
この場合、社会保障番号は、このようなタイプの個人エンティティおいてその全体にわ
たり共通のものであり、もはや、これらの個人に対し、全体から見て特徴的な識別子ではない。したがって、（ａ）この時点で共通であると分かった識別子を共通識別子のリストに追加し、すべての将来のプロセスでは、70において、この時点で共通であることが分かった識別子に基づく候補リスト用のレコード検索または関係レコードの作成を行わず、64における今後のマッチングを停止し、（ｂ）上記の社会保障番号の誤用に基づいてマッチングされたレコードを、マッチングまえのデータを反映するように切り離す必要がある。この後者の目的を達成するために、システム10は、データを損失することなく、そのデータのすべての属性情報に従って、誤った想定以前のところまで、その誤った想定66に基づいて行ったマッチングを切り離して元に戻す。したがって、（「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」へと標準化されている）「Ｂｏｂｂｙ Ｓｍｉｔｈ」に関するレコード＃１が「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」に関するレコード＃２とマッチングされており、これらが別々の二人であり、これらの二人を最初のレコード＃１とレコード＃２とに切り離して元に戻す必要があるということが後になってから決定された場合には、上記のアルゴリズムは、レコード＃１における標準化された「Ｒｏｂｅｒｔ Ｓｍｉｔｈ」が「Ｂｏｂｂｙ」として知られていたことを識別しうる。さらに、上記の決定ステップおよび切り離しステップは、リアルタイムで実行されてもよいしまたはバッチ形式で実行されてもよい。さらに、上記の切り離されたレコードは、新規に受信されたデータとして再び送信され、システムにおいて処理されてもよい。
【００３３】
また、関係が明白なものでなくともその関係を評価すること68が必要な場合がある。たとえば、個人＃１および個人＃２がそれぞれ組織＃３と関係を有して場合がある。したがって、個人＃１と個人＃２との間に関係が存在する有望な可能性がある。これらの関係は、いくつかの次数の分解度にまで広げられうる。したがって、システム10は、すべての受信データを、格納されているデータのすべてのレコードと比較し、それぞれのエンティティ間になんらかの関係が存在するすべてのレコード対に対して関係レコードを70で作成する。この関係レコード70は、関係タイプ（たとえば、父、共謀者）と、信頼性指数（二つのエンティティの関係の強度を表すスコア）72と、割り当てられた永続キー60、62とを有している。たとえば、信頼性指数72は、関係スコアと類似スコアとを有しうる。この関係スコアは、個人＃１と個人＃２との間に関係が存在する可能性を表す、たとえば１から１０までの間の指数である。また、類似指数は、個人＃１が個人＃２と同一の人物であることを表す、たとえば１から１０までの間の指数である。信頼性指数72は、上記のマッチングプロセス中に割り出されうる。
【００３４】
また、システム10は、二つのエンティティの間の不適切な関係の如き、または信頼性指数が所定の値を超えるおよび／もしくは分解度が所定の値を下回る関係レコードに基づく特定パターンのアクティビティの如き、ユーザ規定のアラートルール74の基準を充足する状態の存在を判定すべく、受信されたデータ20および問い合わせ46を解析する。たとえば、システム10は、不正なクレジットカードのリストを有しうる。このリストは、受信されたデータまたは問い合わせがこの不正クレジットカード番号のリスト上にあるクレジットカード番号を有しているか否かを判定するために用いられうる。さらに、ユーザ規定のアラートルール74により、受信データまたは問い合わせに関する調査報告される。たとえば、新規のベンダーのデータの入力の際に、この新規のベンダーが現在の従業員と同一のアドレスを有しており、そのベンダーと従業員との間に雇用者がおそらく調査を望むようななんらかの関係を示していると判定される場合に対するアラートルールが存在しうる。ユーザ規定のアラートルールの実行の引き金となりうる状況が検出されると、システム10は、アラート74を発行する。このアラートは、電子メールを介したメッセージの如きさまざまな媒体を通じて伝達されてもよいし、英数式ビーパ、情報携帯端末、または電話機の如きハンドヘルド通信デバイスへ伝達されてもよい。
【００３５】
たとえば、最大６次の分離度の範囲78において７を超える関係尤度信頼性指数（ｌｉｋｅｌｉｈｏｏｄ ｏｆ ｒｅｌａｔｉｏｎｓｈｉｐ ｃｏｎｆｉｄｅｎｃｅ ｉｎｄｉｃａｔｏｒ）76を有するレコードのすべてに対するユーザ規定のアラートルールをベースにする場合、システム10は、（ａ）個人＃１から開始し、（ｂ）76で７を超える信頼性指数を有する、個人＃１に関連する他のすべての個人を80において見出し、（ｃ）80における個人のうちの１次の分解度に該当するものをすべて分析し、84で７を超える信頼性指数を有する、１次の分解度に相当する個人80に関連するすべての個人を82において決定し、（ｄ）６次の分解度パラメータ78を充足するまでプロセスを繰り返す。上記システムは、（ユーザ規定の基準に基づいて得られたレコードのすべてを含みうる）アラート74を電子的に関連する個人または別のシステムに送信し、次のアクションを可能にし得る。
【００３６】
さらに、関係レコード70は、複数のデータベースにわたり複製されうる。受信データを20で受信すると、上記システムは、その他のデータベースの各々の作業量の状態を体系的に評価し、格納されている解析済みレコード68を最も効率的に解析しうるデータベースに対し、マッチング済／関係付け済み／解析済みレコードを分散しうる。次いで、アラート74は、それが、その他のデータベースから発生するいかなる原因によるいかなるアラートであっても、発生されうる。
【００３７】
最終的に、処理されたデータは、リアルタイムまたはバッチプロセス形式で、ウェアハウス発行リストに段階的に86従って、同一のアルゴリズム92を用いうるさらなるデータベースに88で転送されうる。このようにして、転送データ88は、このデータの関係を特定、マッチング、または処理するめに、さらなるデータベースおよびそれに続くデータベースの内の（異なるデータを含みうる）データとマッチングさせるべく用いられうる。たとえば、上記の信頼性指数に基づいてマッチングされたローカルデータベース内のレコードは、比較される地域データベースに88において転送され、同一のアルゴリズム92を用いてデータとマッチングされてもよい。その後、地域データベースから得られる処理済データは、ナショナルオフィスに88で転送されてもよい。各ステップにおいて処理されたデータを、とくにリアルタイムで結合することにより、組織またはシステムユーザは、不適切なまたは矛盾するデータを割り出し、さらなるアクションを促すことが可能になる。
【００３８】
上記の方法、プログラム、およびシステムの機能的な側面を実現するために、従来のソフトウェアコードを用いることができる。このコードは、単一のコンピュータ、またはインターネットの如き分散型コンピュータネットワークによる使用のためのいかなるコンピュータ読み取り可能媒体に搭載されてもよい。
【００３９】
以上により、本発明の精神および範疇から逸脱することなく複数の変形および改良が可能であることが明らかである。いうまでもなく、本明細書記載の特定の装置は、限定を意図したものでもなければ推測されるべきものでもない。また、いうまでもなく、添付のクレームの範疇に含まれるような上述の変形すべてを当該クレームにより網羅することを意図している。
【図面の簡単な説明】
【００４０】
【図１】本発明にかかるシステムのブロック線図である。
【図２】図１に示されるシステムブロックのデータ処理を示すフローチャートである。
【図３】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図４】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図５】図２に示されるプロセスアルゴリズムブロックのフローチャートである。
【図６】図５に示される、格納されている解析済みレコードの評価のフローチャートである。
【図７】図５に示される、格納されている解析済みレコードの評価のフローチャートである。
【特許請求の範囲】
【請求項１】
少なくとも一つの識別子を有するとともにそれぞれが複数のエンティティのうちの少なくとも一つを表す少なくとも一つのレコードからなるデータを受信するステップと、
前記受信されたデータの識別子と同様の識別子を有するさらなる一群のレコードをデータベースから検索し、
前記受信されたデータの少なくとも一部とのマッチングの有無を調べるべく、検索された前記一群のレコードの各識別子を解析し、
前記受信されたデータの少なくとも一部を、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードとマッチングさせ、
前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードに以前には格納されていなかった前記受信されたデータの少なくとも一部に、少なくとも一つの識別子が含まれているか否かを解析し、
前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの解析されたレコードとのマッチングの有無を調べるために、前記検索された一群のレコードの各識別子を再解析し、
マッチングされた前記レコードを前記データベースに格納する処理を行うステップと
を有しているデータ処理方法。
【請求項２】
前記格納する処理を行うステップが永続キーを割り当てることを含んでいる請求項１記載の方法。
【請求項３】
前記格納する処理を行うステップが、前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの解析されたレコードとの内の識別子と同様の識別子を有するさらなる一群のレコードを前記データベースから検索することをさらに含んでいる請求項１記載の方法。
【請求項４】
前記格納する処理を行うステップが、
データベースから一群のレコードを検索することと、
検索された前記一群のレコードの各識別子を解析することと、
前記受信されたデータの少なくとも一部をマッチングさせることと、
少なくとも一つの識別子が、以前に格納されていなかった前記受信されたデータの少なくとも一部に含まれているか否かを解析することと、
前記データベースから、さらなる一群のレコードを検索することと、
さらなるマッチングが見出されなくなるまで、マッチングの有無を調べるべく前記検索された一群のレコードの各識別子を再解析することと
を繰り返すことを含んでいる請求項１または請求項３記載の方法。
【請求項５】
前記格納する処理を行うステップが、
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子と、特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定することと、
前記特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子であって、特定のエンティティを表すレコードの全体からみて特徴的な識別子ではないと判定された場合、前記識別子に基づいて以前マッチングされたレコードを切り離すこと
を含んでいる請求項１記載の方法。
【請求項６】
前記格納する処理を行うステップが、、特定の識別子に基づくさらなるレコードのマッチングを、該特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子であって、特定のエンティティを表すレコードの全体からみて特徴的な識別子でないと判定された場合、禁止することを含んでいる請求項５記載の方法。
【請求項７】
前記格納する処理を行うステップが、受信されたデータとして前記切り離されたレコードを再処理することを含んでいる請求項５記載の方法。
【請求項８】
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子および特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定するステップと、以前にマッチングされたレコードを切り離すステップとが、リアルタイムで実行される請求項５記載の方法。
【請求項９】
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子および特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定するステップと、以前にマッチングされたレコードを切り離すステップとが、バッチ形式で実行される請求項５記載の方法。
【請求項１０】
データベースへのデータまたはデータベース内のデータを処理するシステムのための、コンピュータによって方法を実行すべく実行されるプログラムインストラクションを有するコンピュータ・プログラムであって、
該方法が、
少なくとも一つの識別子を有するとともにそれぞれが複数のエンティティのうちの少なくとも一つを表す少なくとも一つのレコードからなるデータを受信するステップと、
前記受信されたデータの前記識別子と同様の識別子を有するさらなる一群のレコードを前記データベースから検索し、
前記受信されたデータの少なくとも一部とのマッチングの有無を調べるべく、検索された前記一群のレコードの各識別子を解析し、
前記受信されたデータの少なくとも一部を、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードとマッチングさせ、
前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードに以前には格納されていなかった前記受信されたデータの少なくとも一部に、少なくとも一つの識別子が含まれているか否かを解析し、
前記受信されたデータの少なくとも一部および、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの解析されたレコードとのマッチングの有無を調べるために、前記検索された一群のレコードの各識別子を再解析し、
マッチングされた前記レコードを前記データベースに格納する処理を行うステップと
を有してなるコンピュータ・プログラム。
【請求項１１】
前記格納する処理を行うステップが、永続キーを割り当てることを含んでなる請求項１０記載のコンピュータ・プログラム。
【請求項１２】
前記格納する処理を行うステップが、ステップが、前記検索された一群のレコードの各識別子を再解析するまえに、マッチングの有無を調べるべく、前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの解析されたレコードとの内の識別子と同様な識別子を有するさらなる一群のレコードを前記データベースから検索することをさらに含んでなる請求項１０記載のコンピュータ・プログラム。
【請求項１】
少なくとも一つの識別子を有するとともにそれぞれが複数のエンティティのうちの少なくとも一つを表す少なくとも一つのレコードからなるデータを受信するステップと、
前記受信されたデータの識別子と同様の識別子を有するさらなる一群のレコードをデータベースから検索し、
前記受信されたデータの少なくとも一部とのマッチングの有無を調べるべく、検索された前記一群のレコードの各識別子を解析し、
前記受信されたデータの少なくとも一部を、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードとマッチングさせ、
前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードに以前には格納されていなかった前記受信されたデータの少なくとも一部に、少なくとも一つの識別子が含まれているか否かを解析し、
前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの解析されたレコードとのマッチングの有無を調べるために、前記検索された一群のレコードの各識別子を再解析し、
マッチングされた前記レコードを前記データベースに格納する処理を行うステップと
を有しているデータ処理方法。
【請求項２】
前記格納する処理を行うステップが永続キーを割り当てることを含んでいる請求項１記載の方法。
【請求項３】
前記格納する処理を行うステップが、前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映すると判定される前記検索された一群のレコードのうちの解析されたレコードとの内の識別子と同様の識別子を有するさらなる一群のレコードを前記データベースから検索することをさらに含んでいる請求項１記載の方法。
【請求項４】
前記格納する処理を行うステップが、
データベースから一群のレコードを検索することと、
検索された前記一群のレコードの各識別子を解析することと、
前記受信されたデータの少なくとも一部をマッチングさせることと、
少なくとも一つの識別子が、以前に格納されていなかった前記受信されたデータの少なくとも一部に含まれているか否かを解析することと、
前記データベースから、さらなる一群のレコードを検索することと、
さらなるマッチングが見出されなくなるまで、マッチングの有無を調べるべく前記検索された一群のレコードの各識別子を再解析することと
を繰り返すことを含んでいる請求項１または請求項３記載の方法。
【請求項５】
前記格納する処理を行うステップが、
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子と、特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定することと、
前記特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子であって、特定のエンティティを表すレコードの全体からみて特徴的な識別子ではないと判定された場合、前記識別子に基づいて以前マッチングされたレコードを切り離すこと
を含んでいる請求項１記載の方法。
【請求項６】
前記格納する処理を行うステップが、、特定の識別子に基づくさらなるレコードのマッチングを、該特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子であって、特定のエンティティを表すレコードの全体からみて特徴的な識別子でないと判定された場合、禁止することを含んでいる請求項５記載の方法。
【請求項７】
前記格納する処理を行うステップが、受信されたデータとして前記切り離されたレコードを再処理することを含んでいる請求項５記載の方法。
【請求項８】
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子および特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定するステップと、以前にマッチングされたレコードを切り離すステップとが、リアルタイムで実行される請求項５記載の方法。
【請求項９】
特定の識別子が、少なくとも二つの異なるエンティティを表すレコードに共通の識別子および特定のエンティティを表すレコードの全体からみて特徴的な識別子のうちの一つであるか否かを判定するステップと、以前にマッチングされたレコードを切り離すステップとが、バッチ形式で実行される請求項５記載の方法。
【請求項１０】
データベースへのデータまたはデータベース内のデータを処理するシステムのための、コンピュータによって方法を実行すべく実行されるプログラムインストラクションを有するコンピュータ・プログラムであって、
該方法が、
少なくとも一つの識別子を有するとともにそれぞれが複数のエンティティのうちの少なくとも一つを表す少なくとも一つのレコードからなるデータを受信するステップと、
前記受信されたデータの前記識別子と同様の識別子を有するさらなる一群のレコードを前記データベースから検索し、
前記受信されたデータの少なくとも一部とのマッチングの有無を調べるべく、検索された前記一群のレコードの各識別子を解析し、
前記受信されたデータの少なくとも一部を、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードとマッチングさせ、
前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの少なくとも一つの解析されたレコードに以前には格納されていなかった前記受信されたデータの少なくとも一部に、少なくとも一つの識別子が含まれているか否かを解析し、
前記受信されたデータの少なくとも一部および、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの解析されたレコードとのマッチングの有無を調べるために、前記検索された一群のレコードの各識別子を再解析し、
マッチングされた前記レコードを前記データベースに格納する処理を行うステップと
を有してなるコンピュータ・プログラム。
【請求項１１】
前記格納する処理を行うステップが、永続キーを割り当てることを含んでなる請求項１０記載のコンピュータ・プログラム。
【請求項１２】
前記格納する処理を行うステップが、ステップが、前記検索された一群のレコードの各識別子を再解析するまえに、マッチングの有無を調べるべく、前記受信されたデータの少なくとも一部と、前記複数のエンティティのうちの同一のエンティティを表す識別子を有するレコードを反映していると判定される前記検索された一群のレコードのうちの解析されたレコードとの内の識別子と同様な識別子を有するさらなる一群のレコードを前記データベースから検索することをさらに含んでなる請求項１０記載のコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００９−５９３７１（Ｐ２００９−５９３７１Ａ）
【公開日】平成２１年３月１９日（２００９．３．１９）
【国際特許分類】
【出願番号】特願２００８−２３７０４２（Ｐ２００８−２３７０４２）
【出願日】平成２０年９月１６日（２００８．９．１６）
【分割の表示】特願２００３−５５８６７３（Ｐ２００３−５５８６７３）の分割
【原出願日】平成１４年１２月２７日（２００２．１２．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２１年３月１９日（２００９．３．１９）
【国際特許分類】
【出願日】平成２０年９月１６日（２００８．９．１６）
【分割の表示】特願２００３−５５８６７３（Ｐ２００３−５５８６７３）の分割
【原出願日】平成１４年１２月２７日（２００２．１２．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]