(57)【要約】  データベースクエリの照合を強化するためのシステム。本システムはデータソース、シングルソース参照ファイルを含むデータリポジトリ、マルチソース参照ファイルを含むデータベース、および、データソースからの入来データを処理するインテリジェンスエンジンを含む。ただし、マルチソース参照ファイルはビジネスエンティティに対応する第１の一意ビジネス識別番号を有する。インテリジェンスエンジンは、入来データがマルチソース参照ファイルにマッチするか否かを判定し、データがマルチソース参照ファイルにマッチした場合には、前記データを前記マルチソース参照ファイルに付加し、データがマルチソース参照ファイルにマッチしない場合には、データがデータリポジトリに格納されているシングルソース参照ファイルにマッチするか否かを判定する。
2009521770.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを用いてデータベースクエリの照合を強化する方法であって、該方法は、データソースからデータを受け取り、当該データが第１の一意ビジネス識別番号を含むマルチソース参照フィルにマッチするか否かを調べ、前記データがマルチソース参照ファイルにマッチした場合には、前記データをマルチソース参照ファイルに付加し、前記データがマルチソース参照ファイルにマッチしない場合には、前記データがデータリポジトリ内に格納されているシングルソース参照ファイルにマッチするか否かを調べる、ただし、前記マルチソース参照ファイルはデータベース内に格納されていることを特徴とする、コンピュータを用いてデータベースクエリの照合を強化する方法。
【請求項２】
さらに、マルチソース化ルールを適用して、前記データが検証データソースとして適格であるか否かを判定し、前記データが検証データソースとして適格であれば、前記データを前記シングルソース参照ファイルに付加することにより第２のマルチソース参照ファイルを作成し、当該第２のマルチソース参照ファイルを前記データリポジトリから前記データベースに移し、前記データが検証データソースとして適格でなければ、前記データを用いて第２のシングルソース参照ファイルを作成し、当該第２のシングルソース参照ファイルを前記データリポジトリに格納する、請求項１記載の方法。
【請求項３】
さらに、前記第２のシングルソース参照ファイルを作成する前に、前記データの品質を予め決められた品質基準に基づいて検査し、前記第２のシングルソース参照ファイルを作成した後、前記データが前記予め決められた品質基準を満たしていれば、前記第２のシングルソース参照ファイルに第２の一意ビジネス識別番号を付与し、前記データが前記予め決められた品質基準を満たしていなければ、前記データをリジェクトファイルに送る、請求項２記載の方法。
【請求項４】
所定の長さの時間が経過しても前記第２のシングルソース参照ファイルがマルチソース参照ファイルとして分類し直されていない場合には、前記第２の一意ビジネス識別番号を第３のシングルソース参照ファイルに付与し直す、請求項３記載の方法。
【請求項５】
さらに、前記シングルソース参照ファイルと前記マルチソース参照ファイルからビジネスデータレポートを作成する、請求項３記載の方法。
【請求項６】
さらに、前記マルチソース参照ファイルと前記シングルソース参照ファイルから重複するデータを除去する、請求項３記載の方法。
【請求項７】
前記データソースにはユーザが作成したクエリが含まれている、請求項１記載の方法。
【請求項８】
前記データソースはウェブベースのデータソースである、請求項１記載の方法。
【請求項９】
データベースクエリの照合を強化するためのシステムであって、該システムは、データソース、シングルソース参照ファイルを含むデータリポジトリ、マルチソース参照ファイルを含むデータベース、および、当該データソースからの入来データを処理するインテリジェンスエンジンを含んでおり、ただし、前記マルチソース参照ファイルはビジネスエンティティに対応する第１の一意ビジネス識別番号を有しており、前記インテリジェンスエンジンは、前記入来データが前記マルチソース参照ファイルにマッチするか否かを判定し、前記データが前記マルチソース参照ファイルにマッチした場合には、前記データを前記マルチソース参照ファイルに付加し、前記データが前記マルチソース参照ファイルにマッチしない場合には、前記データが前記データリポジトリに格納されているシングルソース参照ファイルにマッチするか否かを判定することを特徴とする、データベースクエリの照合を強化するためのシステム。
【請求項１０】
前記システムはさらに前記インテリジェンスエンジン内に常駐するマルチソース化ロジックを含んでおり、該マルチソース化ロジックは前記データが検証データソースとして適格であるか否かを判定し、前記インテリジェンスエンジンは、前記マルチソース化ロジックが前記データは検証データソースとして適格であると判定した場合には、前記データを前記シングルソース参照ファイルに付加することにより第２のマルチソース参照ファイルを作成し、当該第２のマルチソース参照ファイルを前記データリポジトリから前記データベースに移し、前記データが検証データソースとして適格でなければ、前記データを用いて第２のシングルソース参照ファイルを作成する、請求項９記載のシステム。
【請求項１１】
前記システムはさらに、前記インテリジェンスエンジン内に常駐する品質チェッカと、前記インテリジェンスエンジン内に常駐するビジネス識別子付与ユニットと、リジェクトファイルを含んでおり、前記品質チェッカは前記インテリジェンスエンジンが第２のシングルソース参照ファイルを作成する前に前記データの品質をチェックするものであり、前記ビジネス識別子付与ユニットは、前記品質チェッカが前記データは予め決められた品質基準を満たしていると判定した場合に、第２の一意ビジネス識別番号を前記データに付与するものであり、前記リジェクトファイルは、前記品質チェッカが前記データは前記予め決められた品質基準を満たしていないと判定した場合に、前記データを受け取るものである、請求項１０記載のシステム。
【請求項１２】
前記ビジネス識別子付与ユニットは、所定の長さの時間が経過しても前記第２のシングルソース参照ファイルがマルチソース参照ファイルとして再分類されていない場合には、前記第２の一意ビジネス識別番号を第３のシングルソース参照ファイルに付与し直す、請求項１１記載のシステム。
【請求項１３】
前記システムはさらに前記シングルソース参照ファイルと前記マルチソース参照ファイルからビジネスデータレポートを作成する作成ユニットを含んでいる、請求項１１記載のシステム。
【請求項１４】
前記システムはさらに前記インテリジェンスエンジン内に常駐するデータクリーナを含んでおり、該データクリーナは前記マルチソース参照ファイルと前記シングルソース参照ファイルから重複するデータを除去する、請求項２記載のシステム。
【請求項１５】
前記データソースにはユーザが作成したクエリが含まれている、請求項９記載のシステム。
【請求項１６】
データベースクエリの照合を強化するためのコンピュータにより実行される命令を有するコンピュータ可読媒体であって、該コンピュータ可読媒体は、データソースからデータを受け取るための命令、当該データが第１の一意ビジネス識別番号を含むマルチソース参照フィルにマッチするか否かを調べるための命令、前記データがマルチソース参照ファイルにマッチした場合に、前記データをマルチソース参照ファイルに付加するための命令、前記データがマルチソース参照ファイルにマッチしない場合に、データリポジトリ内に格納されているシングルソース参照ファイルにマッチするか否かを調べるための命令を含んでおり、ただし、前記マルチソース参照ファイルはデータベース内に格納されていることを特徴とする、コンピュータ可読媒体。
【請求項１７】
前記コンピュータ可読媒体はさらに、マルチソース化ルールを適用して、前記データが検証データソースとして適格であるか否かを判定するための命令、前記データが検証データソースとして適格である場合に、前記データを前記シングルソース参照ファイルに付加することにより第２のマルチソース参照ファイルを作成するための命令、当該第２のマルチソース参照ファイルを前記データリポジトリから前記データベースに移すための命令、前記データが検証データソースとして適格でない場合に、前記データを用いて第２のシングルソース参照ファイルを作成するための命令、当該第２のシングルソース参照ファイルを前記データリポジトリに格納するための命令を含んでいる、請求項１６記載のコンピュータ可読媒体。
【請求項１８】
前記コンピュータ可読媒体はさらに、前記第２のシングルソース参照ファイルを作成する前に、前記データの品質を予め決められた品質基準に基づいて検査し、前記第２のシングルソース参照ファイルを作成した後、前記データが前記予め決められた品質基準を満たしていれば、前記第２のシングルソース参照ファイルに第２の一意ビジネス識別番号を付与し、前記データが前記予め決められた品質基準を満たしていなければ、前記データをリジェクトファイルに送る、請求項１６記載のコンピュータ可読媒体。
【請求項１９】
データフィードを受け取る入力側と少なくとも１つのデータベースとインテリジェンスエンジンとを含むシステムにおいて、前記データフィードは第１のビジネスエンティティを記述するデータフィールドを有しており、前記データベースには複数のビジネスエンティティを記述する複数のレコードを含まれており、前記インテリジェンスエンジンはマッチングロジックを含んでおり、該マッチングロジックは前記データフィールドを前記レコードと比較し、前記データフィールドに対して品質検査を行い、マッチが見付からず、かつ前記品質検査が満たされている場合には、前記データフィールドに一意ビジネス識別番号を付与し、前記データフィールドと前記一意ビジネス識別番号を前記データベース内の前記複数のレコードに付加する、ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
１．分野
本開示はデータの検索と照合に、より具体的には、ビジネスクエリに回答する目的でのデータの検索と照合に関する。
【０００２】
２．関連する技術の説明
かつては、ビジネスデータサービスの顧客がエンティティに関する情報を頻繁にリクエストすることがあった。しかし、たとえリクエストされた情報がビジネスデータサービスの内部データリポジトリにあっても、意味のある回答を要求者に提供することができなかった。これには主に２つの理由がある。第１には、レコード自体は内部リポジトリにあるものの、ビジネス識別子またはD-U-N-S Number(R)を有していないために、すぐには顧客に提供できないためである。第２には、レコードはビジネス識別子を有しているが、「個々」のデータビューと履歴データビューがビジネスデータサービスの照合参照ファイル内にないためである。
【０００３】
最近の調査によれば、回答者の６２％は、まだエンティティ識別子を取得する資格のない企業に関するレコードを検索することができれば、ユーザエクスペリエンスが改善されるだろうと指摘している。顧客行動もしくはプロセス、プロダクト発送およびシステム応答時間を大幅に変えることなく、顧客からの問合せに対して洞察に満ちた回答を提供するためには、すべての内部データを利用できることが必要である。
【０００４】
そのため、従来技術よりも格段に速く情報クエリに対して意味のある回答を提供するためのシステムと方法が求められている。
【０００５】
概要
本開示に記載された方法およびシステムは、特定のエンティティに関する情報レコードへの顧客クエリに対して、実質的につねに、意味のある回答を提供する。
【０００６】
本開示によれば、データベースクエリの照合を強化するための方法が提供される。この方法は、データソースからデータを受け取り、当該データが第１の一意ビジネス識別番号を含むマルチソース参照フィルにマッチするか否かを調べ、前記データがマルチソース参照ファイルにマッチした場合には、前記データをマルチソース参照ファイルに付加し、前記データがマルチソース参照ファイルにマッチしない場合には、データリポジトリ内に格納されているシングルソース参照ファイルにマッチするか否かを調べる。なお、上記マルチソース参照ファイルはデータベース内に格納されている。
【０００７】
さらに、本開示によれば、データベースクエリの照合を強化するためのシステムも提供される。このシステムは、データソースと、シングルソース参照ファイルが格納されたデータリポジトリと、マルチソース参照ファイルが格納されたデータベースと、データソースからの入来データを処理するインテリジェンスエンジンを含む。なお、上記マルチソース参照ファイルはビジネスエンティティに対応する第１の一意ビジネス識別番号を有している。インテリジェンスエンジンは、入来データがマルチソース参照ファイルにマッチするか否かを調べ、データがマルチソース参照ファイルにマッチした場合には、データをマルチソース参照ファイルに付加する。また、インテリジェンスエンジンは、入来データがマルチソース参照ファイルにマッチしない場合には、データリポジトリ内に格納されているシングルソース参照ファイルにマッチするか否かを調べる。
【０００８】
図面の簡単な説明
本開示の他の課題、利点および特徴については、明細書の以下の説明と添付図面の参照により明らかとなる。
図１は、本開示のシステムが値を付加することのできるエリアを示しており、
図２は、マッチが失敗した場合の本開示のシステムのデータフローを示しており、
図３は、本開示のシステムの顧客問合せフローチャートを示しており、
図４は、本開示のシステムのプロダクト決定ツリーダイアグラムであり、
図５は、クエリの拒絶を示す本発明のシステムのブロック図であり、
図６は、照合の成功と失敗の報告を示す本開示のシステムのブロック図であり、
図７は、本開示のシステムのブロック図である。
【０００９】
有利な実施形態の説明
本開示の１００％解決プロセスは、顧客が質問をするたびに実質的にその１００％に対して洞察に満ちた回答を提供し、その回答を返すことで収益を得る。１００％解決プロセスは以下の６つの基本指針に的を絞っている。
指針１：すべての内部データリポジトリを強化する
指針２：外部ビジネスデータソースを利用する
指針３：顧客データソースを利用する
指針４：照合を改善する
指針５：プロダクト可用性を改善する
指針６：顧客離れをなくす
【００１０】
かつては、内部データリポジトリにあるエンティティに関する情報を顧客が頻繁にリクエストすることがあったが、情報提供事業者は主に以下の２つの理由から回答を提供することができなかった。（１）レコードは内部リポジトリ内にあったが、ビジネス識別番号またはD-U-N-S(R)ナンバーを有していなかったために、すぐには顧客に提供できなかった。これは指針１の努力を通して解決される。（２）レコードはD-U-N-Sナンバーを有してたが、「個々」のデータビューと履歴データビューが情報提供事業者の照合参照ファイル内になかった。これは指針４の努力を通して解決される。
【００１１】
最近の調査によれば、回答者の６２％は、まだD-U-N-Sナンバーを取得する資格のない企業に関するレコードを検索することができれば、ユーザエクスペリエンスが改善されるだろうと指摘している。顧客行動、またはプロセス、プロダクト発送およびシステム応答時間を大幅に変えることなく、我々の顧客からの問合せに対して洞察に満ちた回答を提供するためにすべての内部データを利用できるということが、本開示の１００％解決プロセスの根幹である。
【００１２】
ビジネス上の洞察を効率的に顧客に提供するには、D-U-N-Sナンバーをもたない大量のデータを追跡および組織するための鍵をもたらすようなストラテジーを開発することが不可欠である。
【００１３】
本開示のシステムはD-U-N-Sナンバーを付与されていないデータがデータベースに流れ込む際にこのデータに予めD-U-N-Sナンバーを付与するので、顧客が非外部データソース専用の「リアルタイム」D-U-N-Sナンバー付与を利用して問合せをしたときにデータは利用可能となる。
【００１４】
このシステムは現在のD-U-N-Sナンバー付与プロセスの変更を伴う。長期的には、以前のポリシーでは、この指針に必要とされるだけの量のD-U-N-Sナンバーを使用可能にする能力が得られない。したがって、システムは初期的には短期的ストラテジーを用いて近い将来にD-U-N-Sナンバーの十分な供給を確保し、つぎに長期的ストラテジーを用いてD-U-N-Sナンバーを生成するアルゴリムを変更する。
【００１５】
以前には、D-U-N-Sナンバーの付与されたユニバースにマッチしないデータの大部分は、ＵＤＲ、すなわち、Unmatched Data Repositoryと呼ばれるリポジトリに格納された。本開示は、D-U-N-Sナンバーの付与されていない昨今のリポジトリには、顧客の問合せへの有効な回答に使用しうる質の高いビジネスデータが格納されていると判断した。洞察に満ちた回答で顧客の要求を満足させるには、以前にD-U-N-Sナンバーを付与されたことのいないデータを含むすべての内部データを完全利用しなければならない。
【００１６】
第１のステップにおいて、システムは最小限のデータ要件を満たすマッチしないすべての構内データエンティティにD-U-N-Sナンバーを予め付与し、これらを適切なインディケータをもつ在来型のデータリポジトリまたはD-U-N-Sナンバーの付与されたマルチソースユニバースDUNSRightTMデータリポジトリと同じリポジトリに格納する。このデータベースが照合参照ファイルを提供するので、顧客の問合せに回答するために利用できるデータの量が急速に増大する。
【００１７】
初期のD-U-N-Sナンバー事前付与プロセスに続いて、システムは顧客に対して次のような環境を創り出す。すなわち、この環境において、顧客は
・格納されているすべてのD-U-N-Sナンバー付きデータへの問合せを照合することができる。
・同類のデータエンティティをクラスタ化することができる。
・洞察に満ちた回答として提供されるD-U-N-Sナンバー付き統合レコードを作成することができる。
また、情報提供事業者はこの環境により、
・すべての内部データフィード／ソースを格納されているすべてのD-U-N-Sナンバー付きデータおよび入来データと連続的に照合することでコピーの作成を減らすことができる。
・同類のデータエンティティをクラスタ化し、顧客に提供しうるD-U-N-Sナンバー付きの新規マルチソースレコードを作成することができる。または
・問合せがあり次第、顧客に提供することのできる一意の新規シングルソースレコードを識別し、D-U-N-Sナンバー付与することができる。
【００１８】
顧客の問合せに内部データリポジトリを用いては回答できない場合、この環境は「リアルタイム」のD-U-N-Sナンバー付与、格納およびプロダクト生成をサポートしなければならない。
【００１９】
指針４：
また、入来データをD-U-N-Sナンバー付きExecutive at Home AddressファイルおよびD-U-N-S Decision Makerファイルと照合することで、マッチ率を少なくとも２％改善することができることも分かっている。これらのレコードを照合参照ファイルと経時的な企業情報に加えれば、洞察に満ちた回答を顧客に提供する能力がさらに強化される。
【００２０】
指針１および４が取り組む５つの主な機能分野は以下の通りである。
１．インテリジェンスエンジンはデータフローを自動化するためにビジネスごとに規定されたルールを取り入れる簡潔なデータ統合プロセスに基づいており、すべての入来データを統合することにより、データがデータベースに入ってくる時点と顧客の質問への回答に利用可能となる時点の間のタイムラグを短くする。これによりルールの微調整が可能となるため、マッチングと統合のプロセスが連続的に改善され、待ち時間は短くなり、経時的な検証が改善される。インテリジェンスエンジンはまたレコードの量、成功したマッチ、データの存在および例外の報告に関する統計を報告し、微調整プロセスのための入力とする。
【００２１】
２．D-U-N-Sナンバー付与エンジンは、最小限のデータ要件とビジネスごとに規定されたルールとに基づいて、顧客からの問合せと、従来型のデータソース（取引記録および公的記録）と、新しい電話会社データベース（ビジネスイエローページおよびホワイトページ）と、非従来型ソース（消費者、セキュリティクロスウォーク）とから受け取ったマッチしない新規データエンティティにD-U-N-Sナンバーを付与する。この付与エンジンは回答されるすべての顧客問合せを「リアルタイム」プロダクト生成を介してD-U-N-Sナンバー付与されたプロダクトによってサポートしなければならない。
【００２２】
３．データ管理プロセスは、より効率的なデータベースデザイン、より簡潔なデータフロー、ならびに、より高い処理能力と柔軟な監視能力とを備えたインフラストラクチャ戦略を有する新たに定義された遙かに大きなD-U-N-Sナンバー付与されたユニバースに基づいている。このことが複製レコードとエラー処理の増加の原因である。新しいクラスの情報をグローバルデータリポジトリに格納すれば、我々のデータにインテリジェンスを与えることができ、リンクしたエンティティが適切に処理される。この新たなレベルの情報は管理すべきレコードの拡大ユニバースをサポートするために我々のデータ保守プロセスを再構築する際に有用である。
【００２３】
４．顧客入力をより多くのおよび／またはより良いマッチポイントで強化することで、マッチングシステムが高品質のマッチを特定する確率を高める。ＥＨＡ（Executive at Home Address）およびＤＤＭ（D-U-N-S Decision Maker）ファイルの作成に使用されるデータを強化するための代替的データビューと、履歴データをマッチプロセスに取り入れる。また、マッチ処理量の増大に対処するために適切なシステム変更も取り入れる。
【００２４】
５．システムは顧客購買行動統計により再構築の努力をデータ保守戦略に向けさせる。ここで言うデータ保守戦略とは、顧客の質問に答えうる最新の住所を含む高品質のレコードファイルを我々が有していることを保証することによって、顧客の購買率を高めるものである。我々は品質改善とファイル拡充のために顧客購買行動の取得を強化する。さらに、この計画は、ポテンシャルの高いすべての問合せレコードが最小限の保守を受けるように適切なプロセスを設計することにより、現在の戦略におけるギャップを認識し、説明しなければならない。
【００２５】
システムはD-U-N-Sナンバーの付与、割り当ておよび最終的には決定の仕方に大きな変化をもたらし、それにより以前のアプローチを越えてD-U-N-Sナンバーの使用を拡大させる。顧客は我々の提供するすべての回答にD-U-N-Sナンバーを必要とする。
【００２６】
このシステムのおかげで、かつてはD-U-N-Sナンバーの付与されていないレコードであった大量のレコードを顧客が利用できるようになる。D-U-N-Sナンバーの付与されていないデータは、第２の独自データベースからの他のデータによって確認されていない新規データと、マルチソースではあるが、D-U-N-Sナンバーの割り当てられていない新規データとから構成されていた。このデータのほとんどはＵＤＲに格納されていた。
【００２７】
システムはシングルソースD-U-N-Sナンバーの初期データロードを提供する。シングルソースD-U-N-Sナンバーは、一意に識別可能であり、DUNSRightデータリポジトリと呼ばれるアクセス可能な環境に格納されている。システムは以下のステップを実行する。
ステップ１：すべてのＵＤＲレコードをマッチングプロセスを介してUS D-U-N-Sナンバーの付与された我々のデータベース（ＡＯＳ）と照合する
ステップ２：８＋の信頼コードをもつすべてのレコードはマルチソースレコードであると同定し、初期データロードには含めない。
ステップ３：残りのレコードのうち、２つの別個の独自データソースを有し、D-U-N-Sナンバー割当てのARDAルールに合格したレコードを特定し、ファイルをビルドする。
ステップ４：D-U-N-Sナンバー事前付与のための最小限のデータ要件を満たし、すべてのルールおよび妥当性検査に合格した残りのレコードが、D-U-N-Sナンバー付与されたシングルソースレコードの初期ロードファイルとしてシステムにより使用される。
ステップ５：本開示のシステムが使用されると、ＵＤＲの関連するプロセスフローとプロダクトは使用不能となる。
【００２８】
この機能は、インテリジェンスエンジンが、必要に応じ自動的にデータの深さを加え、ルールを用いて、相反する情報のうちのどれを取り入れるかを決定し、最も正確な情報を格納することによって、さらには、D-U-N-Sナンバー付与されたユニバースのデータ保守呼出しが減少するとともに、実行される呼出しが最大化されるような領域を特定することにより実現される。
【００２９】
インテリジェンスエンジンは、マッチングプロセスの上位マッチ機能の範囲を拡大することにより、同類のエンティティをクラスタ化し統合し、代表となる高品質の複合エンティティを形成することで、異種のビジネス情報を識別し、整理統合する。
【００３０】
インテリジェンスエンジンは
・人口／企業情報を付加する（例えば、電話会社データベースから電話番号を付加する）ことにより、データの深さを増大させる、
・一度、ＵＤＲから同類のデータエンティティを１つの複合エンティティに統合することにより、データの幅を広げる、
・最も正確、完全かつタイムリーな情報を得ることができるようにルールを設計することを通して、我々の情報の全体的な品質を高める、
・自動的に検証されるレコードの保守呼出しの回数を減らし、集中的なアウトバウンドコールと、さらに自動化された更新プロセスをもたらす。
【００３１】
このために、インテリジェンスエンジンは
・ポータブルである（すなわち、他のデータソースを受け入れ、取り込むように使用することができる）、
・複合レコードの個々のコンポーネントへのポインタを保持している、
・「リアルタイム」環境でもD-U-N-Sナンバー事前割当て環境でも動作する、
・今日のオンライン環境において毎日同じ応答時間と一日量を提供する、
・実施後１２ヶ月で２倍、２４ヶ月で３倍の増加を可能にする。
【００３２】
システムは包括的なポリシーを用いて相反する情報を扱う。これは、どのデータソースからのどの情報を維持すべかを詳述したタイブレーク判断ルールを用いることで為される。
【００３３】
図１を参照すると、インテリジェンスエンジンは相反する情報を整理統合して新規レコードを作成することにより値を付加し、正確性、完全性および適時性といった要素を改善することにより我々のデータの全体的な品質を高めている。シングルソースレコードはD-U-N-Sナンバーの付与または事前付与されたレコードであるが、この場合、基本識別情報は第２の独自データソースによって確認されていない。
【００３４】
インテリジェンスエンジンの他に、システムはD-U-N-Sナンバー付与エンジンと、１つまたは複数のデータベースリポジトリ（ＤＤＲ）と、「リアルタイム」プロダクト生成も含んでいる。なお、上記D-U-N-Sナンバー付与エンジンは定期的なデータフィードからデータベースへの新規データにD-U-N-Sナンバーを事前付与したり、単独の顧客からデータベースへの新規データにD-U-N-Sナンバー（シングルソースD-U-N-Sナンバー）を「リアルタイム」で付与するものであり、上記データベースリポジトリ（ＤＤＲ）は上で触れたシングルソースD-U-N-Sナンバーと相応するメタデータを格納するものである。
【００３５】
システムは
１．D-U-N-Sナンバー事前付与と「リアルタイム」プロダクト生成によりサポートされる「リアルタイム」D-U-N-Sナンバー付与のためのプロセスをオンラインシステムとバッチシステムとに使用する。
【００３６】
２．適切なデータ管理プロセスと、必要に応じてシングルソースD-U-N-Sナンバーレコードをマルチソースレコードに再分類し、その情報を相応しいすべてのロケーションに押し通すためのプロセスフローとを備えたリポジトリ（ＤＤＲ）を使用する。
【００３７】
３．今日D-U-N-Sナンバー付与の前に適用される検証レベルと少なくとも同じ検証レベルを用いて、リアルタイムに編集および検証を行う。これには、禁句のテーブル、住所の標準化と検証、スペルチェック、および、誤ったもしくは重複したデータがデータベースに入るのを緩和する重複報告保護（ＤＲＰＳ）／誤り処理が含まれる。システムはまたリンケージ（親会社／子会社、支社／本社関係）を調べるプロセスも使用する。すべてのレコードは、ＳＩＣ付与、レバレッジ、存在するすべての危険信号、ハイリスクアラートおよび不正防止モジュールについてリアルタイムで処理される。D-U-N-Sナンバー付与されたレコードが誤ったデータエントリーに基づいて不適切に割り当てられるのを防ぐため、システムは市名と国名の無効な組合せや市外局番の無効な取り替えなどのエントリーをマークし、できる限り訂正する。好ましくは、対話的な編集を利用して、市名と国名の無効な組合せや市外局番の無効な取り替えなどのエントリーデータを再入力するよう顧客に促すようにするとよい。
【００３８】
４．マルチソースレコードとして再分類されたすべてのシングルソースレコードを一意に識別する。というのも、これらのシングルソースレコードは、新たなビジネスステータスの浮上のため、さらには、不必要にレコードを非アクティブ状態にすることを防ぐために、それぞれ異なるデータ保守の仕方を必要とするからもしれないからである。システムはまたシングルソースレコードの正しくないマルチソース化を防ぐためにすべてのソースデータ情報（メタデータ）をレコードおよびデータエレメントのレベルに保持する。システムは、シングルソースレコードがマルチソース化されるまで、シングルソースレコードが他のシステム（オンラインおよびバッチでのマッチングのためのシステムを除く）に流れ込まないようにする機能も提供する。システムはまた、データの分析と索引が可能なユーザインタフェースと、ユーザ定義された変更可能な標準的データベース監査システムを含んでいる。
【００３９】
５．オンラインでの顧客トランザクションとバッチによる顧客トランザクションをすべて受理する。
【００４０】
６．シングルソースデータを含むすべての内部データにアクセスして、最も信頼性の高いコードをもつレコードを顧客に返すように、オンラインおよびバッチでのマッチングサービスを拡張する。返されたレコードがシングルソースレコードであった場合、D-U-N-Sナンバーはマルチソースレコードとして分類され、すべての顧客に利用可能となる。
【００４１】
７．内部データ内に見付からない顧客問合せを構造化された外部データソースと照合するようにオンラインおよびバッチでの照合サービスを拡張し、高品質のマッチが見付かった場合には、リアルタイムでD-U-N-Sナンバーの付与とプロダクト生成／発送ができるようにする。新規のD-U-N-Sナンバーはシングルソースレコードとして格納されるが、このレコードは第２の独自データソースによるデータ確認によってマルチソースレコードとして再分類されるまで他者には利用できない。
【００４２】
８．構造化データまたは非構造化データを含む外部データソースを用いる。
【００４３】
９．プロダクトの生成ができるオンラインアクセスシステムを用いる。
【００４４】
１０．シングルソースレコードとして付与および格納されたすべてのD-U-N-Sナンバーに必ず「付与日」を持たせる。この日付はD-U-N-Sナンバーの付与されたマルチソースレコードとして分類されるのにかかる時間をモニタするために使用される。システムはまた、シングルソースレコードのD-U-N-Sナンバーの寿命に関するルールと、シングルソースD-U-N-Sナンバーをリサイクルする前にレコードをどれだけの期間格納しておくかに関する保管ルールも使用する。例えば、レコードがビジネス登記からの事前付与されたD-U-N-Sナンバーであって、所定の時間が経過してもマルチソースレコードとして再分類されていないのであれば、このD-U-N-Sナンバーを新規レコードに対して再発行することができる。顧客入力に基づいてシングルソースD-U-N-Sナンバーが付与されている場合には、D-U-N-Sナンバーはリサイクルされない。
【００４５】
システムは、柔軟な処理・保管容量と、ビジネスに応じた監査・報告方法による監視能力を提供する。
【００４６】
システムは以下の動作を行う。
１．データエレメントにより加入者を追跡し、シングルソースレコードに対してデータベースアーカイビングおよび／またはD-U-N-Sナンバーリサイクルプロセスを用いる。
【００４７】
２．すべてのＵＳレコードに対してＮＣＯＡ（National Change of Address）処理を用い、自動処理フローにデータ変更を取り込むようにインテリジェンスエンジンを強化する。
【００４８】
３．ファイルビルド呼出にSETS、Look-Alikes、Professionalsおよび未解決ＳＩＣ付与といったプロセス改良点を組み込むことで、現行のファイルビルドプロセスでは除外されてしまうすべてのレコードを解決し、ＩＥを強化するために学習を利用する。
【００４９】
４．否定的解決を含むデータエレメント変更を最も正確な情報がデータベースに反映されるようにするための「トリガー」として使用するレコード更新プロセスを用いる。
【００５０】
５．マルチソースレコードとして再分類されたすべてのシングルソースレコードの一意識別子を利用し、新たなビジネスステータスの浮上のため、さらには、不必要にレコードを非アクティブ状態にすることを防ぐために、これらのシングルソースレコードにそれぞれ異なるデータ保守の仕方を適用する。
【００５１】
６．監視機能および関連する監査報告を用いる。なお、この監視機能および監査報告は下記を含むが、それらに限定されるものではない。
・残っているUS D-U-N-Sナンバーのユニバースを監視し、毎日、毎週および毎月監査報告を提供する。
・マルチソースD-U-N-Sナンバー"マルチソーシング"として分類し直されたシングルソースD-U-N-Sナンバーの数をソース、加入者番号などにより監視し、毎日、毎週および毎月監査報告を提供する。
・付与されたシングルソースD-U-N-Sナンバーの数をソース、加入者番号などにより監視し、毎日、毎週および毎月監査報告を提供する。
・リサイクルされたシングルソースD-U-N-Sナンバーの数をソース、加入者などにより監視し、毎日、毎週および毎月監査報告を提供する。
・閾値を超過したときには、適切なビジネスオーナーにアラートを通知する。
【００５２】
データベースの保全性を保護するため、システムは有効な顧客入力（例えば、顧客は有効な加入者番号を通じて識別可能でなければならない）を規定する適切なビジネスルールを特定ならびに利用し、フロントエンドおよびバックエンドでは適切なハイリスクアラートと不正検出サービスを採用する。
【００５３】
システムは、なりすまし、サービスの拒否および権限のない侵入に対する保護のため、データセキュリティ機構を内蔵する。
【００５４】
システムはグローバルD-U-N-Sナンバーの付与された我々のユニバースにマルチソースレコードを同時にフィードする基礎を提供するものであり、我々の従来のD-U-N-Sナンバー付与されたリポジトリとは異なるリポジトリからD-U-N-Sナンバー付与されたプロダクトの「リアルタイム」発送を可能にする。このシステムは、
インテリジェンスエンジンを介してレコードをクラスタ化、統合および重複除去することによりＵＤＲをクリーンアップする、
クリーンアップされたシングルソースＵＤＲレコードにD-U-N-S付与エンジンを用いてD-U-N-Sナンバーを事前付与する、
D-U-N-Sナンバー付与されたこれらのシングルソースレコードをデータリポジトリ環境にロードする、
オンラインとバッチの両方について、マッチングエンジンを用いてシングルソースレコードにアクセスする、
シングルソースレコードに基づいてプロダクトを生成することで回答を提供する、
オンラインサービスを介してマッチを提供する、
ＥＨＡ、ＤＤＭおよび履歴アドレスファイルを操作するマッチングロジックを採用する。
【００５５】
図２を参照すると、データベースクエリのマッチングを強化する方法２００が示されている。方法２００はデータをマルチソース参照ファイルのデータベース２４５およびシングルソース参照ファイルのデータリポジトリ２６０と照合する方法である。方法２００はデータソース２０５からデータを受け取るステップを含んでいる。つぎに、データソース２０５からのデータはインテリジェンスエンジンに供給され、インテリジェンスエンジンは第１のマッチングステップ２１０を実行する。第１のマッチングステップ２１０において、インテリジェンスエンジンは前記データが１つまたは複数のマルチソース参照ファイル内の複数のレコードのうち第１のレコードと相関またはマッチするか否かを調べる。第１のレコードはD-U-N-Sナンバーのような一意のビジネス識別番号を含んでおり、この一意のビジネス識別番号によって、第１のレコードが第１のレコードにより記述されたビジネスエンティティに対応していることが示される。第１のレコードはソース識別子も含んでおり、このソース識別子によって、第１のレコードが２つ以上の独立したデータソースからのデータを含んでいること、つまり、第１のレコードがマルチソースであることが示される。
【００５６】
第１のマッチングステップ２１０において、データが第１のレコードとマッチするとインテリジェンスエンジンが判定した場合、方法２００は、前記データフィールドが前記第１のレコード内にない場合には、結合ステップ２１５を実行して前記データと前記第１のレコードを結合し、結合レコードを生成する。結合ステップ２１５は、一意ビジネス識別番号を有する１つまたは複数の選択された内部参照ファイルに結合レコードを格納する。結合レコードはまたソース識別子も含んでおり、このソース識別子によって、結合レコードが２つ以上のデータソースからのデータを含んでいることが示される。１つの実施形態では、方法２００はデータと第１のレコードを結合して結合レコードを生成した後、第１のレコードを削除する。
【００５７】
データが第１のレコードとマッチしないとインテリジェンスエンジンが判定した場合には、方法２００は第２のマッチングステップ２２５を実行する。第２のマッチングステップ２２５において、インテリジェンスエンジンは前記データが１つまたは複数のマルチソース参照ファイル内の複数のレコードのうち第２のレコードと相関またはマッチするか否かを調べる。第２のレコードはD-U-N-Sナンバーのような一意のビジネス識別番号を含んでおり、この一意のビジネス識別番号によって、第２のレコードが第２のレコードにより記述されたビジネスエンティティに対応していることが示される。第２のレコードはソース識別子も含んでおり、このソース識別子によって、第２のレコードがただ１つのデータソースからのデータを含んでいること、つまり、第１のレコードがシングルソースであることが示される。
【００５８】
データが第２のレコードとマッチしないとインテリジェンスエンジンが判定した場合、方法２００は品質チェックステップ２５０を実行してデータの基本的な品質チェックを行い、データがシングルソースデータリポジトリ２６９に入るための所定の基準を満たしているか否かを検証する。データが品質チェックステップ２５０において基本的な品質基準を満たさなかった場合、方法２００はこのデータをリジェクトファイル２６５に送る。しかし、品質チェックステップ２５０においてデータが基本的な品質基準を満たした場合には、方法２００は付与ステップ２５５を実行する。付与ステップ２５５では、データにD-U-N-Sナンバーのような第２の一意ビジネス識別子が付与される。なお、この第２の一意ビジネス識別子は、以前には内部参照ファイル２２０，２３０内に存在していなかった第２のビジネスエンティティに対応するものである。つぎに、方法２００は格納ステップ２６０を実行する。格納ステップ２６０では、第２のビジネス識別子を付与されたデータがシングルソースデータリポジトリ２６０に加えられる。
【００５９】
データが第２のレコードとマッチしないとインテリジェンスエンジンが判定した場合、方法２００はマルチソース化判定ステップ２３５を実行する。マルチソース化ステップ２３５は、前記データがシングルソース参照ファイルをマルチソース参照ファイルとして再分類することを可能にする検証データソースとして適格であるか否かを判定する。マルチソース化ステップ２３５はこの判定をインテリジェンスエンジン内にある所定のルールに基づいて行う。この所定のルールに従い、前記データが検証データソースとして適格であるとインテリジェンスエンジンが判定した場合、方法２００は更新ステップ２４０を実行する。更新ステップ２４０では、第２のレコードがシングルソース参照からマルチソース参照へと再分類され、マルチソースデータベース２４５に加えられる。１つの実施形態では、第２のレコードはシングルソースデータリポジトリから除去される。
【００６０】
インテリジェンスエンジンは、シングルソースデータリポジトリとマルチソースデータベースへの定期データフィードのうち重複する情報を除去し、情報を統合するために使用される。入来データフィードはインテリジェンスエンジンを通して処理される。
【００６１】
定期データフィードと従来型のD-U-N-Sナンバーリポジトリ（ＡＯＳ）との間にマッチが見付かった場合、インテリジェンスエンジンはＡＯＳ内に既にあるマルチソースレコードの幅を増大させる。
【００６２】
ＡＯＳ内ではマッチが見付からないものの、シングルソースレコードとのマッチは見付かった場合、インテリジェンスエンジンはこのレコードを強化し、ＡＯＳの更新のためにマルチソース化ルールに通す（第２のレコードはマルチソース化に使用されるので）。このレコードはマルチソースとして更新されるようＤＤＲでタグ付けされる。レコードは、マルチソース化ルールを満たさなければ、将来のマルチソース化に備えてＤＤＲ内に残される。
【００６３】
データがマルチソースレコードにもシングルソースレコードにもマッチしない場合には、データが基本的なD-U-N-Sナンバー付与基準を満たすか否かを調べるチェックが実行される。基本的なD-U-N-Sナンバー付与基準を満たしていれば、データはD-U-N-Sナンバーを付与され、レコードとしてＤＤＲに付加される。なお、このレコードは適切なインディケータをもつシングルソースD-U-N-Sナンバーを有している。基本的なD-U-N-Sナンバー付与基準を満たしていなければ、データはリジェクトファイルに送られる。
【００６４】
図３を参照すると、データベースクエリのマッチングを強化し、データベース問合せに基づいてプロダクトを生成する方法３００が示されている。方法３００はデータ受け取りステップ３０５においてデータソースからデータを受け取る。１つの好ましい実施形態では、ウェブインタフェースを介してユーザからデータを受け取る。データを受け取った後、方法３００はグローバルマッチングステップ３１０を実行する。ここで、データは１つまたは複数のマルチソース参照ファイル２２０および１つまたは複数のシングルソース参照ファイル２３０と比較される。グローバルマッチングステップ３１０においてデータが参照ファイル２２０，２３０のいずれともマッチしないと判定された場合、方法３００はステップ３６５においてデータのマッチが見付からなかったことを示すメッセージをユーザに送る。
【００６５】
しかし、データが参照ファイル２２０，２３０の一方または両方とマッチすると判定された場合には、方法３００は第１の検査ステップ３２５を実行する。第１の検査ステップ３２５において、方法３００はマッチングデータが従来型の一意ビジネス識別子を含んでいるか否かを調べる。マッチングデータが従来型の一意ビジネス識別子を含んでいれば、第１のプロダクト生成ステップ３３０においてマッチングデータに基づいてプロダクトが生成される。
【００６６】
マッチングデータが従来型の一意ビジネス識別子を含んでいないと判定されると、方法３００はマルチソース化決定ステップ３３５を実行する。マルチソース化ステップ３３５は、前記データがシングルソース参照ファイルをマルチソース参照ファイルとして再分類することを可能にする検証データソースとして適格であるか否かを判定する。マルチソース化ステップ３３５はこの判定を所定のルールに基づいて行う。この所定のルールに従い、前記データが検証データソースとして適格であれば、方法３００は更新ステップ３４０を実行する。更新ステップ３４０では、第２のレコードがシングルソース参照からマルチソース参照へと再分類され、ステップ３５０においてマルチソースデータベースに加えられ、第２のプロダクト生成ステップ３４５においてマッチングデータに基づいてプロダクトが生成される。しかし、データが検証データソースとして適格でなくても、方法３００は第２のプロダク生成ステップ３４５においてプロダクトを生成するが、マッチングデータはステップ３５５においてシングルソースデータリポジトリに加えられない。
【００６７】
マッチングサービスは、顧客に洞察に満ちた回答を提供するために、シングルソースデータリポジトリからのシングルソースD-U-N-Sナンバーを含む。返されたレコードがシングルソースレコードであった場合、D-U-N-Sナンバーはマルチソースレコードとして分類され、すべての顧客に利用可能となる。詳細なプロセスフローは次の通りである。
【００６８】
１．入力された顧客問合せをマルチソースD-U-N-S（履歴ファイルとＥＨＡ／ＤＤＭに基づいた照合参照ファイルを含むＡＣＳ）およびシングルソースD-U-N-Sと照合し、最良マッチを顧客に返す。マッチが見付かった場合、
ａ．マルチソースリポジトリ（ＡＯＳ）からプロダクトを生成し、ＡＯＳからプロダクトを顧客に返す。
ｂ．シングルソースリポジトリ（ＤＤＲ）からプロダクトを生成し、ＤＤＲからプロダクトを顧客に返す。マッチがマルチソース化ルールに合格した場合には、ＤＤＲ内のレコードを更新し、ＡＯＳにアップロードする。不合格ならば、将来のマルチソース化に備えてＤＤＲにレコードを残しておく。
【００６９】
２．内部リポジトリにマッチが見付からない場合には、非外部ビジネスデータソースと照合する。
ａ．マッチが見付かったならば、レコードをD-U-N-Sナンバー付与ルールに通してD-U-N-Sナンバーを生成し、ＤＤＲに加える。レコードは将来のマルチソース化に備えたＤＤＲに保存される。そして、プロダクトを生成し、顧客に返す。
ｂ．マッチが見付からなければ、レコードをD-U-N-Sナンバー付与ルールに通してシングルソースD-U-N-Sナンバーを生成し、適切なインジケータとともにＤＤＲに加え、このエンティティが会社または消費者として存在する証拠は見付からなかった旨のメッセージとともにD-U-N-Sナンバーをプロダクトとしてユーザに返す。
【００７０】
図４には、顧客から受け取ったデータベースクエリのマッチングを強化するための代替的方法４００が示されている。
【００７１】
図５および６には、インテリジェンスエンジンに対する異なるデータフローパスが示されている。図５を参照すると、データフィード５２０を受け取るインテリジェンスエンジン５１０が示されている。インテリジェンスエンジン５１０はデータフィード５２０を第１のレコード５３５と比較するマッチングロジック５５５を含んでいる。第１のレコードには、（ｉ）第１のレコードと第１のレコードにより記述される第１のビジネスエンティティとが対応していることを示す第１の一意ビジネス識別子５４０、および、（ｉｉ）第１のレコードが単一のデータソースからのデータを含むことを示すソース識別子が含まれており、第２のレコード５４５には、（ｉ）第２のレコードと第２のレコードにより記述される第２のビジネスエンティティとが対応していることを示す第２の一意ビジネス識別子５５０、および、（ｉｉ）第２のレコードが２つ以上のデータソースからのデータを含むことを示すソース識別子が含まれている。
【００７２】
マッチングロジック５５５は、データフィード５２０が第１のビジネスエンティティに対応しているのか、あるいは第２のビジネスエンティティに対応しているのかを判定する。インテリジェンスエンジン５１０はまたマルチソース化ロジックを含んでおり、データフィード５２０が第２のビジネスエンティティに対応している場合にデータフィード５２０を第２のレコード５４５に結合する。インテリジェンスエンジン５１０はまた、データフィード５２０の品質を検査する品質チェッカ５６５と、前記第１の一意ビジネス識別子を割り当てるビジネス識別子割当てユニット５７０も含んでいる。
【００７３】
図６を参照すると、顧客クエリ６２０を実行するインテリジェンスエンジン６１０が示されている。インテリジェンスエンジン６１０は顧客クエリ６２０を第１のレコード６３５、第２のレコード６４５および第３のソース６９０と比較するマッチングロジック６５５を含んでいる。ここで、第１のレコード６３５には、（ｉ）第１のレコード６３５と第１のレコード６３５により記述される第１のビジネスエンティティとが対応していることを示す第１の一意ビジネス識別子６４０、および、（ｉｉ）第１のレコードが単一のデータソースからのデータを含むことを示すソース識別子が含まれており、第２のレコード６４５には、（ｉ）第２のレコード６４５と第２のレコード６４５により記述される第２のビジネスエンティティとが対応していることを示す第２の一意ビジネス識別子６５０、および、（ｉｉ）第２のレコード６４５が２つ以上のデータソースからのデータを含むことを示すソース識別子が含まれており、第３のソース６９０は選択された１つまたは複数の外部ビジネス参照ファイルからのデータを有している。
【００７４】
マッチングロジック６５５は、顧客クエリ６２０が第１のビジネスエンティティに対応しているのか、第２のビジネスエンティティに対応しているのか、あるいは第３のソース６９０に対応しているのかを、選択された１つまたは複数の外部ビジネスファイルから判定する。１つの有利な実施形態では、インテリジェンスエンジン６１０はマルチソース化ロジック６６０を含んでおり、顧客クエリ６２０が第２のビジネスエンティティに対応している場合に顧客クエリ６２０を第２のレコード６４５に結合する。
【００７５】
別の有利な実施形態では、インテリジェンスエンジン６１０は、顧客クエリ６２０と第３のソース６９０が対応しているとマッチングロジック３５５が判定した場合に、顧客クエリ６２０を第３のソース６９０に結合し、結合データファイル６６２を作成する。インテリジェンスエンジン６１０は結合データファイル６６２を検査する品質チェッカ６６５を含んでいる。
【００７６】
図７には、コンピュータ７００のＩ／Ｏユニットを介してデータフィードを受信する本発明のシステムが図示されている。コンピュータは、バスにより相互接続されたプロセッサ７１０、１つまたは複数のＩ／Ｏユニット７２０、およびメモリ７３０を含んでいる。メモリには、図２−６のロジックフローを具体化したプログラムが含まれている。コンピュータはデータベース２２０および２３０と相互接続されている。このコンピュータは、単一のコンピュータとして図示されてはいるが、図２−６のプロセスフローを協働して実行する複数のコンピュータとしてもよい。
【００７７】
以上、本発明を有利な実施形態を特に参照して説明してきたが、添付された請求項において規定された本発明の範囲を逸脱することなく、様々な変更および変形が為されうることは当業者にとっては明らかであろう。
【図面の簡単な説明】
【００７８】
【図１】本開示のシステムが値を付加することのできるエリアを示す。
【図２】マッチが失敗した場合の本開示のシステムのデータフローを示す。
【図３】本開示のシステムの顧客問合せフローチャートを示す。
【図４】本開示のシステムのプロダクト決定ツリーダイアグラムを示す。
【図５】クエリの拒絶を示す本発明のシステムのブロック図を示す。
【図６】照合の成功と失敗の報告を示す本開示のシステムのブロック図を示す。
【図７】本開示のシステムのブロック図を示す。
【図１】
2009521770.tif 000003
【図２】
2009521770.tif 000004
【図３】
2009521770.tif 000005
【図４】
2009521770.tif 000006
【図５】
2009521770.tif 000007
【図６】
2009521770.tif 000008
【図７】
2009521770.tif 000009
【国際調査報告】
2009521770.tif 000010