(57)【特許請求の範囲】
【請求項１】
顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断して名寄せする名寄せシステムであって、
上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手段と、
上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手段と、
上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手段と、
上記分類手段によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手段と、
その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一の第一グループ番号を設定してグループ化する第一グループ化手段と、
上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手段とを有し、
上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとする名寄せシステム。
【請求項２】
請求項１記載の名寄せシステムであって、
上記組み合わせキーと上記第一グループ化手段によって割り当てられた第一グループ番号とを対応させてキー番号管理データベースによって管理するキー番号管理手段と、
上記顧客情報レコードの提供する上記会員によって、上記第一グループ化手段によってグループ化された第一グループ番号毎に、同一顧客に関する顧客情報レコードである場合に、同一顧客に関する顧客情報レコードに同一の第二グループ番号が設定された顧客情報レコードを、外部から取り込むことによって取得する会員判断結果取得手段と、
上記会員判断結果取得手段によって取得した顧客情報レコードに基づいて、上記組み合わせキーと上記第一グループ番号との組み合わせに対応させて、上記キー番号管理データベースに上記第二グループ番号を追加する第二グループ番号追加手段と、
上記キー番号管理データベースに基づいて、同一の会員番号と店番号と顧客番号とによる組み合わせキーを有すると共に、上記第一グループ番号と上記第二グループ番号とによる同一の組み合わせグループ番号を有する顧客情報レコードを同一顧客に関する情報であると判断する同一顧客情報判断手段とを有する名寄せシステム。
【請求項３】
請求項１又は２記載の名寄せシステムであって、
上記顧客情報レコードを優先して抽出するための優先条件及び該顧客情報レコードの値を優先して決定するための優先条件の１つ以上に従って、上記キー番号管理データベースに基づいて、上記第一グループ番号と上記第二グループ番号とによる同一の組み合わせグループ番号を有する顧客情報レコードのグループ毎に優先すべき該顧客情報レコードを決定して該項目の値を決定し、同一グループ内の複数の顧客情報レコードを１つの顧客情報レコードにする単一化手段とを有し、
一顧客に対して一顧客情報レコードを対応させるようにした名寄せシステム。
【請求項４】
請求項１記載の名寄せシステムであって、
同一の決算年月及び第一グループ番号であって、かつ、同一の店番号及び顧客番号を示す顧客情報レコードの前期の決算年月を取得する前期決算年月取得手段と、
上記前期決算年月取得手段によって取得した前期の決算年月が全て同じであるか否かを判断する前期決算年月同一判断手段と、
上記前期決算年月同一判断手段によって上記前期決算年月取得手段によって取得した前期の決算年月が全て同じであると判断した場合であってかつ該前期の決算年月での上記第一グループ番号が異なる場合、上記決算年月における第一グループ番号を削除することによって、同一顧客ではない状態に設定する第一グループ番号削除手段とを有するようにした名寄せシステム。
【請求項５】
請求項４記載の名寄せシステムであって、
上記前期決算年月同一判断手段によって上記前期決算年月取得手段によって取得した前期の決算年月が全て同じではないと判断した場合、顧客が同一であることを判断する項目を更に追加して、上記前期決算年月取得手段における複数の顧客情報レコードにおける顧客が同一であることを判断する追加一致判断手段を有し、
上記追加一致判断手段によって一致しなかった場合、上記第一グループ番号削除手段を実行して、上記第一グループ番号を削除することによって、同一顧客ではない状態に設定するようにした名寄せシステム。
【請求項６】
請求項５又は４記載の名寄せシステムであって、
上記複数の顧客情報レコードを管理する管理者によって、上記グループ化によってグループ化された第一グループ番号毎に顧客情報レコードの一致を判断した判断結果に基づいて、一致する顧客情報レコードに同一の第三グループ番号が設定された顧客情報レコードを上記顧客情報データベースから取得する会員判断結果取得手段と、
上記第一グループ番号と上記第三グループ番号との組み合わせ番号が同一である顧客情報レコードを抽出する第二抽出手段とを有し、
上記第二抽出手段によって抽出された上記組み合わせ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとする名寄せシステム。
【請求項７】
顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断して名寄せする名寄せシステムであって、
上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手段と、
上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手段と、
上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手段と、
上記分類手段によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手段と、
その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一のグループ番号を設定してグループ化するグループ化手段と、
上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手段とを有し、
上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするようにした名寄せシステム。
【請求項８】
コンピュータに顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断させて名寄させる名寄せ方法であって、該コンピュータに、
上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手順と、
上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手順と、
上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手順と、
上記分類手順によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手順と、
その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一の第一グループ番号を設定してグループ化する第一グループ化手順と、
上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手順とを実行させ、
上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとする名寄せ方法。
【請求項９】
請求項８記載の名寄せ方法であって、上記コンピュータに、
同一の決算年月及び第一グループ番号であって、かつ、同一の店番号及び顧客番号を示す顧客情報レコードの前期の決算年月を取得する前期決算年月取得手順と、
上記前期決算年月取得手順によって取得した前期の決算年月が全て同じであるか否かを判断する前期決算年月同一判断手順と、
上記前期決算年月同一判断手順によって上記前期決算年月取得手順によって取得した前期の決算年月が全て同じではないと判断した場合、上記第一グループ番号を削除することによって、同一顧客ではない状態に設定する第一グループ番号削除手順とを有するようにした名寄せ方法。
【請求項１０】
顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの一致を判断して名寄せする名寄せシステムでの処理をコンピュータに行なわせるためのプログラムを格納した記憶媒体において、該コンピュータに、
上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手順と、
上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手順と、
上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手順と、
上記分類手順によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手順と、
その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一の第一グループ番号を設定してグループ化する第一グループ化手順と
上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手順とを実行させ、
上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするプログラムを格納した記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの一致を判断して名寄せする名寄せシステムムを提供するものである。
【０００２】
また、本発明は、そのような名寄せ方法及びそのシステムでの処理をコンピュータに行なわせるためのプログラムを格納した記憶媒体に関する。
【０００４】
【従来の技術】
従来より、顧客情報管理を行なっている企業において、例えば、金融機関等において、行内及び共同ＤＢのいずれにおいても顧客名、住所、電話番号等の顧客を特定化しうる情報をキー項目として、同一顧客に対して一意のキー項目を割り当てて顧客情報の管理を行なっている。
【０００５】
顧客情報の一致を判定する場合、そのキー項目が一致する顧客情報を同一であると判定していた。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来の顧客情報管理における顧客情報の一致判定は、以下に述べる問題点がある。
【０００７】
上記従来の顧客情報管理では、先ず、顧客名、住所、電話番号等の顧客を特定化しうるキー項目の完全一致をもって同一と判定していた。しかしながら、実際には、類似するキー項目が多く存在しているため、完全一致による判断では十分な結果が得られない場合があった。その場合、類似するキー項目の一致を判断するために人為的な確認作業が必要とされていた。つまり、通常、顧客情報の一致判断をして１つの顧客情報にする名寄せをより正確に行なうためには、より多くの顧客情報収集及びある程度の期間における顧客の情報解析が必要されるが、顧客の移転による住所変更、社名変更等があった場合、過去に遡って同一顧客の顧客情報であるか否かの判断をしなければならない。また、住所の記載方法の一致、前株或いは後株の記載の正確さ、カタカナ社名の記載方法及び表示方法の一致等を過去に遡って統一させなければならない。これら作業は、人為的に顧客情報の一つ一つを確認することによって行なう困難な作業であるため、このような顧客情報に基づいた名寄せの人為的確認作業には限界があり、必ずしも、正確ではなかった。
【０００８】
次に、この人為的な確認作業は、多くの場合、経験者によって成され、一致と見なされるデータを統合（単一化）するルールについて定義されていなかった。
【０００９】
また、一方で、所定のルールを定義付けて機械的に顧客情報の一致を判断しようとすると、管理される顧客情報の全組み合せ（総当り）によって一致判断する処理が実行されるため、顧客情報を管理するデータベースの規模によっては、システムに多大な負荷を発生させるため実現が困難であった。
【００１０】
そこで、本発明の第一の課題は、顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの一致を判断して名寄せシステムを提供することである。
【００１１】
また、本発明の第二の課題は、同様に、顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの一致を判断して名寄せ方法を提供することである。
【００１２】
更に、本発明の第三の課題は、上記のようなシステムでの処理をコンピュータに行なわせるためのプログラムを格納した記憶媒体を提供することである。
【００１４】
【課題を解決するための手段】
上記第一の課題を解決するため、本発明は、請求項１に記載されるように、顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断して名寄せする名寄せシステムであって、上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手段と、上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手段と、上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手段と、上記分類手段によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手段と、その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一の第一グループ番号を設定してグループ化する第一グループ化手段と、上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手段とを有し、上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするように構成される。
【００１５】
このような名寄せシステムでは、顧客を特定する顧客特定情報を含まない顧客情報レコードを分類することによって、同一の分類内において顧客情報レコードの顧客が同一であることの判断が行なわれるため、従来の顧客情報レコード全体の総当りによる顧客情報レードの一致判断に比べて、計算処理回数を大幅に削減することができる。
【００１６】
また、許容範囲が設定された複数の一致判断項目に基づいて、同一分類内にある複数の顧客情報レコードに対して顧客が同一であることを判断するため、顧客が同一であることを判断するための顧客情報レコードの取りこぼしを防ぐことができる。顧客が同一であると判断した複数の顧客情報レコードが同一の第一グループ番号で示されることによって、顧客を特定する顧客特定情報がなくても名寄せを実現することができる。
【００１７】
上記顧客特定情報は、顧客名又は企業名、住所、電話番号等の顧客を特定できる情報である。
【００１８】
上記顧客情報は、上記顧客特定情報を含まない顧客の状態、推移を客観的、定量的に示す情報である。
【００１９】
上記一致判断項目は、売上高、現金・預金、資産合計、資本金等の欠損率が低く、かつ、データとして精度が高い項目である。
【００２０】
上記許容範囲は、売上高、現金・預金、資産合計、資本金等で示される金額の一致とみなす範囲である。
【００２１】
顧客情報レコードの提供者によって同一顧客の顧客情報レコードであることを確認した結果を取得するという観点において、本発明は、請求項２に記載されるように、請求項１記載の名寄せシステムであって、上記組み合わせキーと上記第一グループ化手段によって割り当てられた第一グループ番号とを対応させてキー番号管理データベースによって管理するキー番号管理手段と、上記顧客情報レコードの提供する上記会員によって、上記第一グループ化手段によってグループ化された第一グループ番号毎に、同一顧客に関する顧客情報レコードである場合に、同一顧客に関する顧客情報レコードに同一の第二グループ番号が設定された顧客情報レコードを、外部から取り込むことによって取得する会員判断結果取得手段と、上記会員判断結果取得手段によって取得した顧客情報レコードに基づいて、上記組み合わせキーと上記第一グループ番号との組み合わせに対応させて、上記キー番号管理データベースに上記第二グループ番号を追加する第二グループ番号追加手段と、上記キー番号管理データベースに基づいて、同一の会員番号と店番号と顧客番号とによる組み合わせキーを有すると共に、上記第一グループ番号と上記第二グループ番号とによる同一の組み合わせグループ番号を有する顧客情報レコードを同一顧客に関する情報であると判断する同一顧客情報判断手段とを有するように構成することができる。
【００２２】
このような名寄せシステムでは、許容範囲内で広めにグループ化された顧客情報レコードを、顧客情報レコードの提供者によって、グループ毎に顧客情報レコードの一致を確認した結果を更にグループ化した顧客情報レコードを取得することができるため、より正確な名寄せを実現することができる。
【００２３】
グループ化された顧客情報レコードを１つのレコードに単一化するという観点において、本発明は、請求項３に記載されるように、請求項１又は２記載の名寄せシステムであって、上記顧客情報レコードを優先して抽出するための優先条件及び該顧客情報レコードの値を優先して決定するための優先条件の１つ以上に従って、上記キー番号管理データベースに基づいて、上記第一グループ番号と上記第二グループ番号とによる同一の組み合わせグループ番号を有する顧客情報レコードのグループ毎に優先すべき該顧客情報レコードを決定して該項目の値を決定し、同一グループ内の複数の顧客情報レコードを１つの顧客情報レコードにする単一化手段とを有し、一顧客に対して一顧客情報レコードを対応させるように構成することができる。
【００２４】
このような名寄せシステムでは、同一グループ内で、優先条件に基づいて、項目の値が決定することによって、顧客情報レコードを単一化することができる。
【００２５】
顧客情報レコードの一致を厳密に行なうという観点において、本発明は、請求項４に記載されるように、請求項１記載の名寄せシステムであって、同一の決算年月及び第一グループ番号であって、かつ、同一の店番号及び顧客番号を示す顧客情報レコードの前期の決算年月を取得する前期決算年月取得手段と、上記前期決算年月取得手段によって取得した前期の決算年月が全て同じであるか否かを判断する前期決算年月同一判断手段と、上記前期決算年月同一判断手段によって上記前期決算年月取得手段によって取得した前期の決算年月が全て同じであると判断した場合であってかつ該前期の決算年月での上記第一グループ番号が異なる場合、上記決算年月における第一グループ番号を削除することによって、同一顧客ではない状態に設定する第一グループ番号削除手段とを有するように構成することができる。
【００２６】
このような名寄せシステムでは、前期の決算年月における顧客が同一であると判断されたグループを参照して、決算年月おける同一グループ内の顧客情報レコードに対して顧客が同一であることを厳密に判断することによって、顧客情報レコードの一致の精度を向上させることができる。
【００２７】
上記決算年月は、顧客情報が顧客の財務状態を示す情報である場合、例えば、決算年月である。
【００２８】
顧客情報レコードの一致を厳密に行なうという観点において、本発明は、請求項５に記載されるように、請求項４記載の名寄せシステムであって、上記前期決算年月同一判断手段によって上記前期決算年月取得手段によって取得した前期の決算年月が全て同じではないと判断した場合、顧客が同一であることを判断する項目を更に追加して、上記前期決算年月取得手段における複数の顧客情報レコードにおける顧客が同一であることを判断する追加一致判断手段を有し、上記追加一致判断手段によって一致しなかった場合、上記第一グループ番号削除手段を実行して、上記第一グループ番号を削除することによって、同一顧客ではない状態に設定するように構成することができる。
【００２９】
このような名寄せシステムでは、同一グループ内の顧客情報レコードが、上記一致判断手段による判断結果によって前期の決算年月が一致しない場合において、一致判断項目を増やして、元の決算年月にて同一グループ内の顧客情報レコードの一致を判断するため、より精度の高い名寄せを実現することができる。
【００３０】
顧客情報レコードを管理する管理者による判断を反映させるという観点において、本発明は、請求項６に記載されるように、請求項５又は４記載の名寄せシステムであって、上記複数の顧客情報レコードを管理する管理者によって、上記グループ化によってグループ化された第一グループ番号毎に顧客情報レコードの一致を判断した判断結果に基づいて、一致する顧客情報レコードに同一の第三グループ番号が設定された顧客情報レコードを上記顧客情報データベースから取得する会員判断結果取得手段と、上記第一グループ番号と上記第三グループ番号との組み合わせ番号が同一である顧客情報レコードを抽出する第二抽出手段と、上記第一グループ番号と上記第三グループ番号との組み合わせ番号が同一である顧客情報レコードを抽出する第二抽出手段とを有し、上記第二抽出手段によって抽出された上記組み合わせ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするように構成することができる。
【００３１】
このような名寄せシステムでは、顧客情報レコードの一致結果に、顧客情報レコードの管理者による判断結果を反映させることによって、より精度の高い名寄せを実現することができる。
【００３２】
また、上記第一の課題を解決するため、本発明は、請求項７に記載されるように、顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断して名寄せする名寄せシステムであって、上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手段と、上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手段と、上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手段と、上記分類手段によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手段と、その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一のグループ番号を設定してグループ化するグループ化手段と、上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手段とを有し、上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするように構成することができる。
【００３３】
上記第二の課題を解決するため、本発明は、請求項８に記載されるように、コンピュータに顧客を特定する顧客特定情報を含まない複数の顧客情報レコードの顧客が同一であることを判断させて名寄させる名寄せ方法であって、該コンピュータに、上記名寄せシステムへの会員として登録された会員番号と、該会員の支店を特定する店番号と、該支店において取引のある顧客を特定する顧客番号とによる組み合わせキーによって、上記複数の顧客情報レコードの各顧客情報レコードを特定する顧客情報データベースで上記複数の顧客情報レコードを管理する顧客情報管理手順と、上記顧客情報レコードを構成する項目のうち顧客情報レコードが同一顧客に関する情報であると判断するために使用する項目を一致判断項目として、また、同一顧客に関する情報であると判断するための該一致判断項目に対する許容範囲とを一致判断項目データベースで管理する一致判断項目管理手順と、上記顧客情報レコードに含まれる決算年月及び上記会員の所在地域に関する所在地域情報を示す項目のうち、該所在地情報が同一であり、該決算年月が同一である顧客情報レコード同士を一つに分類する分類手順と、上記分類手順によって分類された同一分類内において１つ以上の顧客情報レコードの上記一致判断項目の値を互いに比較することによって、該一致判断項目データベースに管理される上記一致判断項目の許容範囲内にあるか否かを判断する一致判断手順と、その判断結果に基づいて、上記一致判断項目の許容範囲内にある顧客情報レコードに対して同一の第一グループ番号を設定してグループ化する第一グループ化手順と、上記決算年月には存在しないが該決算年月から１つ前の前期決算年月に存在する組み合わせキーに対応する第一グループ番号と同一の番号を有する該前期決算年月の他の組み合わせキーが該決算年月に存在する場合、該前期決算年月において該第一グループ番号と同じ番号を有する顧客情報レコードに対して、該決算年月に存在する該他の組み合わせキーで特定される顧客情報レコードに設定されている第一グループ番号に変更するグループ番号変更手順とを実行させ、上記第一グループ番号が同一である顧客情報レコードを、同一顧客で名寄せした顧客情報レコードとするように構成される。
【００３４】
上記第三の課題を解決するための手段として、本発明は、請求項１０に記載されるように、上記名寄せシステムによる処理をコンピュータに行なわせるためのプログラムを記憶した記憶媒体とすることもできる。
【００３８】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００３９】
本発明の実施の一形態に係るデータ処理装置に対応するマッチング処理システム１００は、例えば、図１に示すような機能構成を有する。マッチング処理システム１００は、コンピュータシステムによって実現される。
【００４０】
図１は、マッチング処理システムの機能構成を示す図である。図１において、マッチング処理システム１００は、通信制御処理部１０１と、入出力制御処理部１０３と、表示制御処理部１０５と、インストーラー１０７と、同一会員内マッチング処理部１１０と、全体マッチング処理部１２０と、マッチング条件設定処理部１３１と、データ管理部２００とを有する。上記各処理部は、マッチング処理システム１００のＣＰＵ（中央処理装置）によって制御される。マッチング処理システム１００は、インターネット等のネットワーク２５を介して、金融機関等の複数会員の会員端末４０と接続される。各会員は、会員端末４０から会員と取引のある複数の顧客５０に関する重複した顧客情報をマッチング処理システム１００へ送信し、マッチング処理システム１００によって顧客毎に名寄せされた顧客情報の提供を受ける。
【００４１】
通信制御処理部１０１は、ネットワーク２５を介して複数の会員端末４０とデータ通信を制御する。入出力制御処理部１０３は、キーボード又はマウス等による入力データの制御及びプリンター等への出力データの制御を行なう。表示制御処理部１０５は、表示ユニットへの表示データを制御する。インストーラー１０７は、マッチング処理システム１００を制御するためのプログラムが記憶されたＣＤ−ＲＯＭ２０から該プログラムをマッチング処理システム１００に備えられたハードディスク等の補助記憶装置へインストールする。尚、当該プログラムを格納する媒体としてＣＤ−ＲＯＭ２０に限定するものではなく、コンピュータが読み取り可能な媒体であればよい。
【００４２】
データ管理部２００は、マッチング処理システム１００での処理で必要となる情報を上記補助装置に格納し管理する管理部であって、キー番号管理ＤＢ（データベース）２０１と、マッチング条件ＤＢ２０２と、マッチング項目ＤＢ２０３と、マッチング前顧客情報ＤＢ２１１と、マッチング前財務情報ＤＢ２１２と、マッチング前企業ステータスＤＢ２１３と、マッチング前定量情報ＤＢ２１４と、会員別顧客情報ＤＢ２２１と、会員別企業ステータスＤＢ２２２と、会員別定量情報ＤＢ２２３と、会員別決算年月単位マッチングリスト２０５と、会員別マッチングリスト２０６と、会員採番マッチングリスト２０７と、全体顧客情報ＤＢ２３１と、全体企業ステータス情報ＤＢ２３２と、全体定量情報ＤＢ２３３と、全体決算年月単位マッチングリスト２０８と、全体マッチングリスト２０９と、マッチング後顧客情報ＤＢ２４１と、マッチング後財務情報ＤＢ２４２と、マッチング後企業ステータスＤＢ２４３と、マッチング後定量情報ＤＢ２４４と、マッチング用財務キー２５０とを有する。各データベースは、各会員を識別する会員番号、各会員の支店等を特定する店番号、及び、該支店と取引のある顧客を特定する顧客番号の３つの番号の組み合わせによって、レコードを識別することができる。
【００４３】
キー番号管理ＤＢ２０１は、処理中のデータベースのレコードを一意に識別するためのキーの組み合わせを管理するデータベースである。キー番号管理ＤＢ２０１は、会員を特定するための会員番号、会員の店番号、会員と取引のある顧客番号、マッチング処理システム１００で一致と判断した複数のデータを会員毎にグループ化した会員別機械計算グループ番号、会員が一致を確認してグループ化した会員別会員認定グループ番号、全会員のデータをマッチング処理システム１００で一致と判断しグループ化した全体機械計算グループ番号、全体認定グループ番号等とを有する。
【００４４】
マッチング条件ＤＢ２０２は、会員別及び全体をマッチングする際のマッチング条件を管理するデータベースである。マッチング項目ＤＢ２０３は、会員別及び全体をマッチングする際のマッチング項目を管理するデータベースである。日付管理ＤＢ２０４は、処理によってデータベースの情報が更新された日付を管理するデータベースである。
【００４５】
マッチング前顧客情報ＤＢ２１１と、マッチング前財務情報ＤＢ２１２と、マッチング前企業ステータスＤＢ２１３と、マッチング前定量情報ＤＢ２１４とは、各会員から送られてきたマッチング処理前の情報を管理するデータベースである。
【００４６】
会員別顧客情報ＤＢ２２１と、会員別企業ステータスＤＢ２２２と、会員別定量情報ＤＢ２２３とは、会員毎にマッチング処理を行なった情報を管理するデータベースである。
【００４７】
会員別決算年月単位マッチングリスト２０５と、会員別マッチングリスト２０６とマッチング処理によって生成されるリストである。会員別マッチングリスト２０６は、各会員へ提供され、各会員によってマッチングが行なわれる。
【００４８】
会員採番マッチングリスト２０７は、会員別マッチングリスト２０６に基づいて、各会員がマッチングを行なった結果を示すリストである。
【００４９】
全体顧客情報ＤＢ２３１と、全体企業ステータス情報ＤＢ２３２と、全体定量情報ＤＢ２３３とは、会員毎にマッチングされた会員別顧客情報ＤＢ２２１と、会員別企業ステータスＤＢ２２２と、会員別定量情報ＤＢ２２３との情報を全体でまとめたデータベースである。
【００５０】
全体決算年月単位マッチングリスト２０８と、全体マッチングリスト２０９とは、全体でマッチングを行なった結果を示すリストである。全体マッチングリスト２０９に基づいて、キー番号管理ＤＢ２０１が更新される。
【００５１】
マッチング後顧客情報ＤＢ２４１と、マッチング後財務情報ＤＢ２４２と、マッチング後企業ステータスＤＢ２４３と、マッチング後定量情報ＤＢ２４４とは、更新されたキー番号管理ＤＢ２０１に基づいて、データの重複が取り除かれたデータベースである。
【００５２】
同一会員内マッチング処理部１１０は、会員毎にデータの重複を取り除く（以下、単一化という）処理部であって、マッチング用信用作成処理部ＤＢ１１１と、会員別決算年月単位マッチング処理部１１２と、会員別マッチング処理部１１３と、会員別会員認定グループ確定処理部１１４と、会員別単一化処理部１１５とを有する。
【００５３】
マッチング用信用作成処理部ＤＢ１１１は、会員から提供されたマッチング前顧客情報ＤＢ２１１と、マッチング前財務情報ＤＢ２１２と、マッチング前企業ステータスＤＢ２１３と、マッチング前定量情報ＤＢ２１４とから、マッチング処理の対象となるデータ項目が設定されたマッチング用財務キー２５０に基づいて、データを抽出する。
【００５４】
会員別決算年月単位マッチング処理部１１２は、会員毎に同一決算年月にて、マッチング条件ＤＢ２０２とマッチング項目ＤＢ２０３とに基づいて、アローワンス範囲（許容範囲）をチェックして、同一顧客の判定を行ない、同一顧客毎にグループ化した会員別機械計算グループ番号を有する会員別決算年月単位マッチングリスト２０５を作成する。
【００５５】
会員別マッチング処理部１１３は、会員別決算年月単位マッチング処理部１１２によって作成された会員別決算年月単位マッチングリスト２０５に基づいて、会員別に複数の決算年月に渡るデータについて、存在する最近の決算年月（以下、直近の決算年月と言う）から過去に遡って同一顧客の判定を行ない、その判定結果に基づいて更新された会員別機械計算グループ番号を有する会員別マッチングリスト２０６を作成する。作成した会員別マッチングリスト２０６を、ネットワーク２５を介して会員へ提供する。
【００５６】
会員別会員認定グループ確定処理部１１４は、会員の会員端末４０から確定した結果を示す会員採番マッチングリスト２０７を受信すると、キー番号管理ＤＢ２０１の会員別会員認定グループ番号を更新する。
【００５７】
会員別単一化処理部１１５は、会員別会員認定グループ確定処理部１１４によって更新されたキー番号管理ＤＢ２０１に基づいて、会員別顧客情報ＤＢ２２１と、会員別企業ステータスＤＢ２２２と、会員別定量情報ＤＢ２２３と、マッチング前財務情報ＤＢ２１２とを、会員毎に一顧客に対して一情報レコードとなるように単一化する。単一化された会員別顧客情報ＤＢ２２１と、会員別企業ステータスＤＢ２２２と、会員別定量情報ＤＢ２２３とは、夫々、全体顧客情報ＤＢ２３１と、全体企業ステータスＤＢ２３２と、全体定量情報ＤＢ２３３とに格納される。
【００５８】
全体マッチング処理部１２０は、同一会員内マッチング処理部１１０によって会員毎に単一化された各種データを会員全体で単一化を行ない、会員間で重複する情報レコードを名寄せする処理部であって、全体決算年月単位マッチング処理部１２１と、全体マッチング処理部１２２と、全体認定グループ確定処理部１２３と、全体単一化処理部１２４とを有する。
【００５９】
全体決算年月単位マッチング処理部１２１は、同一顧客の判定を行ない、同一顧客毎にグループ化した全体機械計算グループ番号を有する全体決算年月単位マッチングリスト２０８を作成する。
【００６０】
全体マッチング処理部１２２は、全体決算年月単位マッチング処理部１２１によって作成された全体決算年月単位マッチングリスト２０８に基づいて、複数の決算年月に渡るデータについて直近から過去に遡って同一顧客の判定を行ない、その判定結果に基づいて更新された全体機械計算グループ番号を有する全体マッチングリスト２０９を作成する。
【００６１】
全体認定グループ確定処理部１２３は、全体マッチング処理部１２２によって作成された全体マッチングリスト２０９に基づいて、キー番号管理ＤＢ２０１の全体認定グループ番号を更新する。
【００６２】
全体単一化処理部１２４は、全体認定グループ確定処理部１２３によって更新されたキー番号管理ＤＢ２０１に基づいて、会員全体で一顧客に対して一情報レコードとなるように、全体顧客情報ＤＢ２３１と、全体企業ステータスＤＢ２３２と、全体定量情報ＤＢ２３３と、マッチング前財務情報ＤＢ２１２とを単一化する。単一化された全体顧客情報ＤＢ２３１と、全体企業ステータスＤＢ２３２と、全体定量情報ＤＢ２３３と、マッチング前財務情報ＤＢ２１２とは、夫々、マッチング後顧客情報ＤＢ２４１と、マッチング後企業ステータスＤＢ２４３と、マッチング後定量情報ＤＢ２４４と、マッチング後財務情報ＤＢ２４２とに格納される。
【００６３】
マッチング条件設定処理部１３１は、会員別及び全体のマッチングを行なう際のマッチング条件及びマッチング項目を取得する処理部である。マッチング処理システム１００の管理者は、マッチング条件設定処理部１３１によって表示ユニットに表示されるマッチング条件及びマッチング項目を設定する画面から、必要情報を設定することができる。管理者によって設定された情報は、マッチング条件ＤＢ２０２及びマッチング項目ＤＢ２０３で管理される。
【００６４】
次に、マッチング処理システム１００の管理者が、名寄せするためのマッチング条件と、マッチング項目とを設定する画面について説明する。
【００６５】
図２は、マッチング設定画面の例を示す図である。図２（Ａ）は、マッチング条件メンテナンス画面の例を示す図である。図２（Ａ）において、マッチング条件メンテナンス画面３１０は、図１のマッチング条件ＤＢ２０２で管理される項目の値を設定する画面であって、例えば、データ処理の種別を示す処理種別、マッチングの種別を示すマッチング種別、マッチング条件の登録日、マッチング条件を登録した登録者を特定する登録者コード、都道府県コード以外でマッチングに用いる財務項目数を示すマッチング項目数、マッチング項目数のうち一致を判断するための項目数を示すマッチングＯＫ基準項目数、レコードがマッチングの対象外となる財務項目の欠陥数を示すマッチング除外基準項目数等の項目を有する。
【００６６】
マッチング種別が「１」の場合は会員内マッチングを示し、「２」の場合は全体マッチングを示す。
【００６７】
図２（Ａ）に示されるマッチング条件メンテナンス画面２０１の場合、登録者コード「ａｄｍｉｎ」で特定される登録者が、登録日「００−１０−１３」（２０００年１０月１３日）に、マッチング種別「１」（会員内マッチング）の条件を更新したことを示している。該登録者によって、マッチング項目数に「４」、マッチングＯＫ基準項目数に「３」及びマッチング除外基準項目数に「８０」が設定されたことが示される。
【００６８】
図２（Ｂ）は、マッチング項目メンテナンス画面の例を示す図である。図２（Ｂ）において、マッチング項目メンテナンス画面３２０は、図１のマッチング項目ＤＢ２０３によって管理される項目の値を設定する画面であって、例えば、データ処理の種別を示す処理種別、マッチングの種別を示すマッチング種別、マッチング種別で特定される種別内の項目番号、マッチング項目の登録日、処理時に参照される項目名、アローワンス基準値、アローワンス範囲、アローワンス最小値、アローワンス対象条件等の項目を有する。
【００６９】
マッチング条件メンテナンス画面３１０のマッチング種別と同様に、マッチング種別が「１」の場合は会員内マッチングを示し、「２」の場合は全体マッチングを示す。
【００７０】
項目名で示される金額がアローワンス対象条件を満たす場合、アローワンス基準値の位で同一と見なす。アローワンス対象条件が設定されていない場合、該金額からアローワンス範囲を差し引いた金額から、該金額にアローワンス範囲を加えた金額までを一致と見なす。また、項目名で示される金額が、アローワンス基準値未満であれば、該金額からアローワンス最小値を差し引いた金額から、該金額にアローワンス最小値を加えた金額までを一致と見なす。
【００７１】
つまり、図２（Ｂ）に示されるマッチング項目メンテナンス画面３２０の場合、登録日「００−１０−１３」（２０００年１０月１３日）に、マッチング種別「１」（会員内マッチング）の条件を更新したことを示している。項目名「売上高」で示される金額が、アローワンス対象条件に基づいて、「１００，０００，０００」円より大きい場合、アローワンス範囲「１，０００，０００」の位で同一かを判断する。
【００７２】
マッチング項目メンテナンス画面３２０において、マッチング種別「１」で示される会員内マッチングでは、「売上高」、「現金・預金」、「資産合計」及び「資本金」の４つの項目がマッチング項目３２１となる。また、マッチング種別「２」で示される全体マッチングでは、「売上高」、「現金・預金」、「資産合計」及び「資本金」の４つの項目がマッチング項目３２２となる。
【００７３】
マッチング項目を選択する際に、例えば、「現金・預金」等のように、財務諸表作成元である企業（会員の顧客）が直接操作しにくい項目を利用する。一方、例えば、「棚卸資産」のような企業が恣意的に数値を操作する可能性が高い数値は利用しないようにする。また、「売上高」のように、欠損率が低い項目を利用する。
【００７４】
マッチング用信用ＤＢ作成処理部１１１での処理について図３で説明する。図３は、マッチング用信用ＤＢ作成処理を説明するフローチャート図である。図３において、マッチング前顧客情報ＤＢ２１１に存在する会員番号、店番、顧客番号との組み合わせキーがマッチング前財務情報ＤＢ２１２、マッチング前企業ステータスＤＢ２１３、マッチング前定量情報ＤＢ２１４の全てに存在する場合、その組み合わせキーで特定される情報を残し、４つのＤＢ全てに存在しない場合、その情報を削除する（ステップＳ１１）。
【００７５】
マッチング前顧客情報ＤＢ２１１から会員毎にデータをまとめて会員別顧客情報ＤＢ２２１へ出力する（ステップＳ１２）。
【００７６】
次に、マッチング用財務キー２５０に基づいて、マッチング前財務情報ＤＢ２１２から、所定の財務項目に応じてデータを出力すると共に、データ毎に値が設定されていない項目をカウントして欠損数として設定する（ステップＳ１３）。
【００７７】
また、マッチング前企業ステータスＤＢ２１３から、会員毎にデータをまとめて会員別企業ステータスＤＢ２２２へ出力する（ステップＳ１４）。
【００７８】
更に、マッチング前定量情報ＤＢ２１４から、会員毎にデータをまとめて会員別定量情報ＤＢ２２３へ出力する（ステップＳ１５）。
【００７９】
更に、キー番号管理に基づいて、マッチング前顧客情報ＤＢ２１１、マッチング前財務情報ＤＢ２１２、マッチング前企業ステータスＤＢ２１３、マッチング前定量情報ＤＢ２１４の全てに、同一の会員番号、店番、顧客番号との組み合わせキーが存在しない場合、キー番号管理から削除する（ステップＳ１６）。
【００８０】
会員別決算年月単位マッチング処理部１１２での処理について図４及び図５で説明する。図４は、会員別決算年月単位マッチング処理について説明するフローチャート図である。また、図５は、会員別決算年月単位マッチングリストの例を示す図である。図４中、マッチング前信用情報ＤＢとは、マッチング前顧客情報ＤＢ２１１と、マッチング前財務情報ＤＢ２１２と、マッチング前企業ステータスＤＢ２１３と、マッチング前定量情報ＤＢ２１４とを会員番号、店番号及び顧客番号との組み合わせキーによって関連付けし、マッチングに必要な情報を抽出したＤＢを示す。
【００８１】
図４において、マッチング用財務キー２５０の「欠損数」が、マッチング条件ＤＢ２０２を参照して、マッチング除外基準項目数以上のマッチング前信用情報ＤＢのデータを対象外データとし（ステップＳ２１）、マッチング用財務キー２５０の「欠損数」が、マッチング条件ＤＢ２０２を参照して、（マッチング項目数-マッチングＯＫ基準個数）以下のマッチング前信用情報ＤＢのデータを対象データとする（ステップＳ２２）。
【００８２】
例えば、図２（Ａ）に示すマッチング条件メンテナンス画面３１０において、マッチング除外基準項目数が「８０」以上のマッチング前信用情報ＤＢのデータを対象外データとし、更に、マッチング用財務キー２５０の「欠損数」が、マッチング項目数の値「４」からマッチングＯＫ基準個数の値「３」を引いた値「１」以下のマッチング前信用情報ＤＢのデータを対象データとして抽出される。
【００８３】
抽出した対象データを所定のデータ項目順に並べ替える（ステップＳ２３）。例えば、先ず、会員番号に基づいて対象データを昇順に並べ替え、続けて、決算年月に基づいて降順に、都道府県コードを昇順に、売上高を降順に、更に、マッチング財務項目欠損数を昇順に対象データを並べ替える。
【００８４】
次に、マッチング前信用情報ＤＢのマッチング項目の全項目で金額を比較する。又は、マッチング前信用情報ＤＢの上記データ項目順で示される項目に欠損があった場合、マッチングＯＫ基準項目数以上の欠損以外の項目で金額を比較する（ステップＳ２４）。つまり、図２（Ｂ）に示すマッチング項目メンテナンス画面３２０において設定されたマッチング項目３２１（「売上高」、「現金・預金」、「資産合計」及び「資本金」）の全項目で金額を比較する。又は、図２（Ａ）に示すマッチング条件メンテナンス画面３１０において設定されたマッチングＯＫ基準項目数「３」以上を満たすような欠損以外の項目で金額を比較する。但し、上記データ項目順で示される項目の後に続く他項目で欠損があり、欠損以外の項目数を累積した結果、マッチングＯＫ基準項目数に満たないデータは、マッチング対象外とする。
【００８５】
マッチング項目ＤＢ２０３のアローワンス対象条件に基づいて（なければ無条件に）、アローワンス基準値の位で同一か、或いは、アローワンス基準値±アローワンス範囲までを一致とする（ステップＳ２５）。例えば、図２（Ｂ）に示すマッチング項目メンテナンス画面３２０の場合、アローワンス対象条件が設定されているので、金額が１億円を超えるとき、十万円の位で四捨五入して百万円単位にして金額を比較する。比較した結果、差が±１００万円の範囲以内であれば「一致」とする。一方、アローワンス対象条件が設定されていない場合、百円の位で四捨五入して千円単位にして金額を比較する。比較した結果、差が±１０００円の範囲以内であれば「一致」とする。
【００８６】
一致したデータに対して、会員別機会計算グループ番号の割り当てを機械的に行なう（ステップＳ２６）。つまり、一致したデータを一つのグループとなるように、同一番号を割り当てる。
【００８７】
会員別決算年月単位マッチングリスト２０５を出力する（ステップＳ２７）。会員別機会計算グループ番号が割り当てられたデータを会員別決算年月単位マッチングリスト２０５として出力する。出力された会員別決算年月単位マッチングリスト２０５は、例えば、図５に示されるようなリストである。
【００８８】
上記図４に示す会員別決算年月単位マッチング処理において、ステップＳ２３にて所定のデータ項目に「都道府県」を含めることによって、実質的に、非財務項目である「都道府県」と、財務項目である「現金・預金」、「資本金」、「売上高」及び「総資産」とがマッチング条件となっている。
【００８９】
図５は、会員別決算年月単位マッチングリストの例を示す図である。図５において、点線で囲まれるデータが、図４に示す会員別決算年月単位マッチング処理によって一致していると判断されたことを示す。
【００９０】
図５に示す会員別決算年月単位マッチングリスト２０５は、会員＃「００１０」で示される会員の取引先に関する顧客情報、財務情報、企業ステータス及び定量情報に基づいて、作成されたリストである。会員別決算年月単位マッチング処理によって、同一「決算年月」内で「都道府県」が同一のレコードからマッチング項目「現金・預金」、「資本金」、「売上高」及び「総資産」のうちマッチングＯＫ基準項目数「３」以上のマッチング条件を満たすレコードは、例えば、決算年月「２００００３」において、都道府県「１０」では、レコード１からレコード３、レコード４からレコード５で纏められ、都道府県「２０」では、レコード６からレコード７、レコード８からレコード１０で纏められ、夫々順に、会員別会員機械計算グループ番号（図５中、「会員別会員機械計算Ｇ＃」）「１」、「２」、「３」、「４」で示される。
【００９１】
次に、会員別マッチング処理部１１３での処理を図６で説明する。
【００９２】
図６は、会員別マッチング処理について説明するフローチャート図である。図６において、会員別決算年月マッチングリスト２０５を所定のデータ項目順序に並べ替え、更に、店番及び顧客番号とを組み合わせキーとし、決算年月を対応付けたマトリクスを生成する（ステップＳ３１）。所定のデータ項目順序において、例えば、会員別決算年月マッチングリスト２０５は、会員番号に基づいて対象データを昇順に並べ替え、続けて、決算年月に基づいて降順に、会員別機械計算グループ番号を昇順に、店番及び顧客番号を昇順に並べ替える。更に、並べ替えた会員別決算年月マッチングリスト２０５に基づいて、店番及び顧客番号とを組み合わせキーとし、決算年月とを対応付けたマトリクスを生成する。
【００９３】
続けて、直近の決算年月を処理決算年月として設定し（ステップＳ３２）、店番及び顧客番号とを組み合わせキーとして、マトリクスを検索し、処理中決算年月のデータを有する店番及び顧客番号を抽出する。決算年月、店番、顧客番号、会員別機械計算グループ番号を保存する（ステップＳ３３）。つまり、最も近い（直近の）決算年月が２０００年３月（「200003」）であれば、決算年月「200003」を示す店番及び顧客番号を抽出し、該店番及び顧客番号との組み合わせキーによって特定される決算年月、店番、顧客番号、会員別機械計算グループ番号を保存する。
【００９４】
マトリクスの全てのデータを終了したか否かを判断する（ステップＳ３４）。全てのデータを終了した場合、会員別マッチングマッチングリストとして出力し（ステップＳ４０）、会員別マッチング処理を終了する。
【００９５】
一方、全てのデータを終了していない場合、処理中決算年月から存在する最近の決算年月（以下、前期の決算年月という）を、新たに、処理決算年月として設定して（ステップＳ３５）、店番及び顧客番号とを組み合わせキーとして、マトリクスを検索し、処理中決算年月のデータを有する店番及び顧客番号を抽出する（ステップＳ３６）。つまり、処理中決算年月に「200003」が設定されていたら、「200003」から前期の決算年月「199903」を処理中決算年月として設定する。そして、マトリクスから処理中決算年月「199903」に対応する店番及び顧客番号とを抽出する。
【００９６】
更に、処理済の決算年月で既に抽出済みの店番及び顧客番号の中には存在しないが、処理中決算年月に存在する店番号及び顧客番号に対応する会員別機械計算グループ番号と同じ会員別機械計算グループ番号を有する処理中決算年月の他の店番及び顧客番号が処理済の決算年月に存在するか否かを判断する（ステップＳ３７）。処理中決算年月が「199903」である場合、処理済の決算年月は「200003」であり、処理済の決算年月「200003」で抽出済みの店番及び顧客番号の中には存在しないが、処理中決算年月「199903」において、ステップＳ３６にて抽出した店番号及び顧客番号には存在するが処理済の決算年月「200003」には存在しないその店番号及び顧客番号に対応する会員別機械計算グループ番号と同じ会員別機械計算グループ番号を有する処理中決算年月「199903」の他の店番及び顧客番号が処理済の決算年月「200003」に存在するか否かを判断する。同じ会員別機械計算グループ番号のものがない場合、ステップＳ３９へ進む。
【００９７】
一方、同じ会員別機械計算グループ番号のものがある場合、抽出した店番及び顧客番号のうち、処理済の決算年月には存在しない店番及び顧客番号の会員別機械計算グループ番号と、上述した処理中決算年月の他の店番及び顧客番号の同一会員別機械計算グループ番号とを、処理済の決算年月での他の店番及び顧客番号の会員別機械計算グループ番号に変更する（ステップＳ３８）。処理中決算年月「199903」における会員別機械計算グループ番号を、処理済の決算年月「200003」で抽出済みの店番及び顧客番号の会員別機械計算グループ番号へと変更する。
【００９８】
処理中決算年月を決算年月として、また、ステップＳ３６で抽出された店番及び顧客番号と、その会員別機械計算グループ番号とを保存して（ステップＳ３９）、ステップＳ３４へ戻り、データが終了するまで、上記処理を繰り返す。
【００９９】
上記において、決算年月を降順に辿りながら、存在する最近の決算年月で検索される店番及び顧客番号との組み合わせキーによってデータが抽出されるため、直近の決算年月での会員別機械計算グループ番号が優先される処理となる。
【０１００】
上記会員別マッチング処理の詳細を図７で説明する。図７は、会員別マッチング処理の例を示す図である。図７中、説明の便宜上、会員番号、店番、顧客番号とをアルファベットに置き換えてある。同一アルファベットは、同一会員番号、店番及び顧客番号との同一組み合わせキーであることを示す。また、説明を簡単にするため、決算年月、顧客識別子及び会員別機械計算グループ番号（図中、会員別機械計算Ｇ＃で示す）の項目以外は省略される。図７（Ａ）は、顧客識別子が直近の決算年月には存在しないが、前期の決算年月に存在する場合の会員別マッチング処理の例を示す図である。図７（Ｂ）は、顧客識別子が直近の決算年月に存在し、前期の決算年月には存在しない場合の会員別マッチング処理の例を示す図である。
【０１０１】
図７（Ａ）において、図６のステップＳ３１の並べ替えによって、図５に示す会員別決算年月単位マッチングリスト２０５は、例えば、リスト４１１のようになったとする。更に、顧客識別子と決算年月とを対応付けたマトリクス４１２に基づいて、決算年月を過去へ辿る会員別マッチング処理によって、先ず、直近の決算年月「200003」で顧客識別子Ａ、Ｂ及びＣが抽出されると共に、顧客識別子Ａ、Ｂ及びＣに対して、全て会員別機械計算グループ番号「１」が決定する（ステップＳ３３）。
【０１０２】
次に、決算年月「199903」において、抽出された顧客識別子Ａ、Ｂ及びＣ以外の顧客識別子Ｄ及びＥが抽出される（ステップＳ３６）。この場合、顧客識別子Ｄ及びＥの会員別機械計算グループ番号は、同一の「２」で示される。ここで、この決算年月「199903」において、顧客識別子Ｄ及びＥと同一の会員別機械計算グループ番号「２」を示し、かつ、既に顧客識別子が抽出され会員別機械計算グループ番号が決定している顧客識別子を検索する。この場合、顧客識別子Ｃが検索される。決定済みの顧客識別子Ｃの会員別機械計算グループ番号「１」で顧客識別子Ｄ及びＥの会員別機械計算グループ番号を「２」から「１」へ変更する（ステップＳ３７及びＳ３８）。
【０１０３】
同様に、決算年月「199803」において、顧客識別子Ｆが抽出され、顧客識別子Ｆと同一の会員別機械計算グループ番号「２」を有する顧客識別子Ｅの決定済み会員別機械計算グループ番号「１」に従い、顧客識別子Ｆの会員別機械計算グループ番号を「１」に変更する。
【０１０４】
マトリクス４１２は、決定された会員別機械計算グループ番号によってマトリクス４１３のようになる。マトリクス４１３から、会員別機械計算グループ番号が決定（図７のリスト４１３の点線で囲まれる値）された決算年月及び顧客識別子と、その会員別機械計算グループ番号とを会員別マッチングリスト２０６として出力される。この場合、会員別マッチングリスト２０６は、リスト４１４のようなデータ構成となる（ステップＳ４０）。
【０１０５】
図７（Ｂ）において、図６のステップＳ３１の並べ替えによって、図５に示す会員別決算年月単位マッチングリスト２０５は、例えば、リスト４２１のようになったとする。更に、顧客識別子と決算年月とを対応付けたマトリクス４２２に基づいて、決算年月を過去へ辿る会員別マッチング処理によって、先ず、直近の決算年月「200003」で顧客識別子Ｇ、Ｈ、Ｉ、Ｊ、Ｋ及びＬが抽出されると共に、顧客識別子Ｇ、Ｈ、Ｉ、Ｊ、Ｋ及びＬに対して、全て会員別機械計算グループ番号「１」が決定する（ステップＳ３３）。そして、ステップＳ３４のデータ終了判断によって、終了と判断され、マトリクス４２２から、会員別機械計算グループ番号が決定（図７のリスト４２２の点線で囲まれる値）された決算年月及び顧客識別子と、その会員別機械計算グループ番号とを会員別マッチングリスト２０６として出力される。この場合、会員別マッチングリスト２０６は、リスト４２３のようなデータ構成となる（ステップＳ４０）。直近の決算年月での会員別機械計算グループ番号が優先して決定されるため、図７（Ｂ）の例の場合、決算年月「200003」のみで処理が終了する。
【０１０６】
上記処理によって得られた会員別マッチングリスト２０６は、ネットワーク２５を介して、マッチング処理システム１００から会員端末４０へ送信される。会員は、会員端末４０から受信した会員別マッチングリスト２０６の内容で、マッチングを認定する。
【０１０７】
図８は、会員別マッチングリストの例を示す図である。図８（Ａ）は、会員へ送付時の会員別マッチングリストを示す図である。図８（Ｂ）は、会員がマッチングシステム１００へ返送時の会員別マッチングリストを示す図である。会員は、図８に示すような会員別マッチングリスト２０６をマッチング処理システム１００から受信する。図８において、マッチング処理システム１００が設定した会員別機械計算グループ番号毎に、例えば、グループ番号１は員別機械計算グループ番号対応しており、会員別機械計算グループ番号が「１」となる６個の顧客データ、グループ番号２は、会員別機械計算グループ番号が「２」となる３個の顧客データが対応している。そして、各会員別機械計算グループ番号の最初の顧客データ４３０及び４４０のマッチング結果には「１」が入力されている。
【０１０８】
会員は、受信した図８（Ａ）に示す会員別マッチングリスト２０６に、グループ番号毎に、「１」が設定されている左端と同一であれば、「１」を入力する。同一でない場合には、「２」を入力する。また、「２」を入力した顧客データと同一の顧客データのマッチング結果にも「２」を入力する。このように１から順に、異なる顧客データのマッチング結果に自然数を入力すると、例えば、図８（Ｂ）のような会員別マッチングリスト２０６となる。
【０１０９】
図８（Ｂ）において、会員は、グループ番号１において、顧客データ４３０と顧客データ４３１及び４３３は同一であることを示し、顧客データ４３２と４３４は、それぞれ別の顧客データであることを示している。また、グループ番号２において、顧客データ４４０と顧客データ４４１及び４４２は同一であることを示している。このように会員によって設定された会員別マッチングリスト２０６は、マッチング処理システム１００へ返送され、会員採番マッチングリスト２０７として格納される。
【０１１０】
次に、会員から受信した会員採番マッチングリスト２０７に基づく、会員別会員認定グループ確定処理部１１４での処理について説明する。図９は、会員別会員認定グループ確定処理について説明するフローチャート図である。図９において、会員採番マッチングリスト２０７を読み込む（ステップＳ５１）。会員採番マッチングリスト２０７の会員番号、店番及び顧客番号とを組み合わせキーとして、キー番号管理２０１を検索する。検索されたキー番号管理２０１の会員番号、店番及び顧客番号の組み合わせキーに対応させて会員別会員認定グループ番号を設定する（ステップＳ５２）。
【０１１１】
上記処理によって、会員採番マッチングリスト２０７に基づいて、キー番号管理２０１に会員別会員認定グループ番号が、図１０のように、設定される。図１０は、会員別マッチング処理の例を示す図である。図１０中、説明の便宜上、会員番号、店番、顧客番号とをアルファベットに置き換えてある。同一アルファベットは、同一会員番号、店番及び顧客番号との同一組み合わせキーであることを示す。また、説明を簡単にするため、顧客識別子、会員別会員認定グループ番号（図中、会員別会員認定Ｇ＃で示す）、会員別機械計算グループ番号（図中、会員別機械計算Ｇ＃で示す）の項目以外は省略される。また、図１０中、△マークは空欄を意味する。
【０１１２】
図１０において、会員別マッチングリスト２０６は、会員に送信される際のリストを示し、会員別採番マッチングリスト２０７は、会員によって△マーク（空欄）に番号が設定され、マッチング処理システム１００で会員端末４０から受信後のリストを示す。会員別会員認定グループ確定処理部１１４は、受信した会員別採番マッチングリスト２０７から会員別会員認定グループ番号のデータ（図８に示すマッチング結果に対応）を抽出し、キー番号管理２０１の対応する顧客識別子の会員別会員認定グループ番号として設定する。
【０１１３】
会員別会員認定グループ確定処理部１１４での処理によって、例えば、顧客識別子Ｂの会員別機械計算グループ番号と会員別会員認定グループ番号とが同じ「１」であることを示している。一方、例えば、顧客識別子Ｃの会員別機械計算グループ番号［１］であるのに対し、会員別会員認定グループ番号「２」であることを示している。この場合、マッチング処理システム１００では、顧客識別子Ａ、Ｂ及びＣは、同一顧客である判断されたのに対し、会員は、顧客識別子Ａ及びＢは同一顧客であると確認しており、また、顧客識別子Ｃは顧客識別子Ａ及びＢとは異なる顧客であると確認していることを示す。
【０１１４】
図１０に示すキー番号管理ＤＢ２０１において、例えば、会員別機械計算グループ番号「１」及び会員別会員認定グループ番号「１」となる顧客識別子は、Ａ及びＢが存在する。このように、重複して存在するデータを１つのデータにする単一化処理について説明する。
【０１１５】
会員別単一化処理部１１５での処理について図１１及び図１２で説明する。図１１において、キー番号管理を読み込み、所定のデータ項目順で並び替える（ステップＳ６１）。所定のデータ項目順は、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号、店番、顧客番号の順に並び替える。
【０１１６】
会員別機械計算グループ番号がない場合、会員別信用情報から全体信用情報を出力する（ステップＳ６２）。会員別機械計算グループ番号がない場合、単一化対象外であるため、会員別信用情報（会員別顧客情報ＤＢ２２１、会員別企業ステータスＤＢ２２２、会員別定量情報ＤＢ２２３で管理される情報）を、全体信用情報（全体顧客情報ＤＢ２３１、全体企業ステータスＤＢ２３２、全体定量情報ＤＢ２３３で管理される情報）として出力する。
【０１１７】
キー番号管理に関連付けされる会員別顧客情報ＤＢ２２１から会員別顧客情報を抽出して（ステップＳ６３）、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号の組み合わせ単位で複数件存在する会員別顧客情報を抽出する（ステップＳ６４）。
【０１１８】
以下、キー番号管理２０１に関連付けられる会員別顧客情報を、会員別機械計算グループ番号及び会員別会員認定グループ番号の組み合わせキー単位で、単一化する。以下、ステップＳ６６からＳ６９までを処理▲１▼とする。
【０１１９】
会員番号、店番、顧客番号との組み合わせキーで直近の決算年月のマッチング財務キー２５０に基づいて、ステップＳ６４で抽出された会員別顧客情報の中から、更に、欠損数が最も少ない会員別顧客情報を抽出し（ステップＳ６５）、会員別顧客情報が複数存在するか否かを判断する（ステップＳ６６）。会員別顧客情報が複数存在しない場合、ステップＳ７０へ進む。
【０１２０】
一方、会員別顧客情報が複数存在する場合、最も新しい会員データ作成日を示す会員別顧客情報を抽出し（ステップＳ６７）、最も新しい会員データ作成日を示す会員別顧客情報が複数存在するか否かを判断する（ステップＳ６８）。会員別顧客情報が複数存在しない場合、ステップＳ７０へ進む。一方、会員別顧客情報が複数存在する場合、会員別顧客情報の店番及び顧客番号との組み合わせキーの若い方を抽出する（ステップＳ６９）。
【０１２１】
そして、ステップＳ６４で抽出された会員別顧客情報の同一グループ番号（会員別機械計算グループ番号及び会員別会員認定グループ番号の同一組み合わせ）のなかで最も古い融資取引開始年月を、処理▲１▼にて抽出した会員別顧客情報に設定する（ステップＳ７０）。
【０１２２】
ステップＳ６４にて抽出された会員別顧客情報に業種２として設定された情報のより詳細な情報を優先して抽出する。（ステップＳ７５）。抽出した業種をステップＳ６４で抽出したレコードに設定して、全体顧客情報へ出力する（ステップＳ７７）。
【０１２３】
キー番号管理２０１に関連付けされるマッチング前財務情報をマッチング前財務情報ＤＢ２１２から抽出し（ステップＳ７８）、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号及び決算年月との組み合わせキー単位で、複数件存在するマッチング前財務情報をマッチング前財務情報ＤＢ２１２から抽出する（ステップＳ７９）。
【０１２４】
以下、キー番号管理２０１に関連付けられるマッチング前財務情報を、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号及び決算年月との組み合わせキー単位で、単一化する。以下、ステップＳ８０からＳ８５までを処理▲２▼とする。
【０１２５】
会員番号、店番、顧客番号との組み合わせキーで直近の決算年月のマッチング財務キーに基づいて、欠損数が最も少ないマッチング前財務情報を抽出して（ステップＳ８０）、マッチング前財務情報が複数存在するか否かを判断する（ステップＳ８１）。マッチング前財務情報が複数存在しない場合、ステップＳ８５へ進む。
【０１２６】
一方、新しい会員データ作成日のマッチング前財務情報を抽出して（ステップＳ８２）、同一の新しい会員データ作成日のマッチング前財務情報が複数存在するか否かを判断する（ステップＳ８３）。マッチング前財務情報が複数存在しない場合、ステップＳ８５へ進む。一方、マッチング前財務情報が複数存在する場合、マッチング前財務情報の店番及び顧客番号との組み合わせキーの若い方を抽出する（ステップＳ８４）。
【０１２７】
そして、抽出したマッチング前財務情報の店番及び顧客番号に該当する全体顧客情報から店番及び顧客番号を塗り替えて、マッチング用財務キー２５０を更新する（ステップＳ８５）。
【０１２８】
キー番号管理２０１に関連付けされる会員別企業ステータス情報を会員別企業ステータス情報ＤＢ２２２から読み込み、会員別機械計算グループ番号、会員別会員認定グループ番号ごとに店番、顧客番号を該当する全体顧客情報から店番、顧客番号を塗り替えて、全体企業ステータス情報に出力する（ステップＳ８６）。
【０１２９】
そして、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号及び定量情報認定年月との組み合わせキー単位で、複数件存在する会員別定量情報を抽出する（ステップＳ８７）。
【０１３０】
以下、キー番号管理２０１に関連付けられる会員別定量情報を、会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号及び決算年月との組み合わせキー単位で、単一化する。以下、ステップＳ８８からＳ９２までを処理▲３▼とする。
【０１３１】
会員番号、会員別機械計算グループ番号、会員別会員認定グループ番号及び定量情報認定年月との組み合わせキー単位で、複数件存在する会員別定量情報を会員別定量情報ＤＢ２２３から抽出して（ステップＳ８８）、会員別定量情報が複数存在するか否かを判断する（ステップＳ８９）。会員別定量情報が複数存在しない場合、ステップＳ９３へ進む。
【０１３２】
一方、会員別定量情報が複数存在する場合、新しい会員データ作成日の会員別定量情報を抽出して（ステップＳ９０）、同一の新しい会員データ作成日の会員別定量情報が複数存在するか否かを判断する（ステップＳ９１）。会員別定量情報が複数存在しない場合、ステップＳ９３へ進む。一方、会員別定量情報が複数存在する場合、会員別定量情報の店番及び顧客番号との組み合わせキーの若い方を抽出する（ステップＳ９２）。
【０１３３】
そして、抽出した会員別定量情報の店番及び顧客番号を該当する全体顧客情報から店番及び顧客番号を塗り替えて、全体定量情報に出力し（ステップＳ９３）を終了する。
【０１３４】
上記処理によって、マッチング処理システム１００は、会員毎のマッチング（顧客毎の名寄せ）が完了し、次に、全会員でのマッチング処理を行なう。
【０１３５】
会員別決算年月単位マッチング処理部１１２での処理と同様に、全体決算年月単位マッチング処理部１２１は、マッチング用財務キー２５０によって情報項目を制限し、マッチング条件ＤＢ２０２及びマッチング項目ＤＢ２０３に基づいて、同一の決算年月内の都道府県毎にデータをマッチングさせる処理を行ない、全体決算年月単位マッチングリスト２０８を出力する。
【０１３６】
次に、会員別マッチング処理部１１３での処理と同様に、全体決算年月単位マッチングリスト２０８に基づいて、全体マッチングリスト２０９を出力する。全体マッチング処理部１２２での処理について図１３で説明する。図１３は、全体マッチング処理を説明するフローチャート図である。
【０１３７】
図１３において、会員別マッチング処理のステップＳ３１からＳ３９までを、全体決算年月マッチングリストに対して行ない、全体マッチングリスト２０９を出力する（ステップＳ１０１）。会員別機械計算グループ番号を全体機械計算グループ番号として同様の処理を行なえば良い。
【０１３８】
更に、同一の決算年月及び全体機械計算グループ番号の店番及び顧客番号を組み合わせキーとして、マッチング用財務キー２５０に基づいて、マッチング前財務情報ＤＢ２１２から必要な財務情報を参照して、前期の決算年月を取得する（ステップＳ１０２）。
【０１３９】
同一のグループ内で、ステップＳ１０２にて取得した前期の決算年月が全て同じであるか否かを判断する（ステップＳ１０３）。前期の決算年月が全て同じである場合、その前期の決算年月での全体機械計算グループ番号が全て同じであるか否かを判断し（ステップＳ１０４）、全て同じである場合、顧客が一致する（名寄せされている）と判断し、全体機械計算グループ番号をそのままとして変更しない。一方、全てが同じでない場合、異なる全体機械計算グループ番号を空欄に変更する。例えば、同一グループ内に３つのレコードが存在し、前期の決算年月が全て同じであるが、その前期の決算年月での全体機械計算グループ番号が異なるレコードが１つあった場合、そのレコードの全体機械計算グループ番号を空欄に設定して除外する。
【０１４０】
一方、ステップＳ１０３において、同一のグループ内で、ステップＳ１０２にて取得した前期の決算年月の全てが同じでない場合、マッチング項目を追加し、元の決算年月でマッチングを行なう（ステップＳ１０６）。例えば、「当期利益」等のデータが存在する確率の高い項目を追加して、元の決算年月において、同一のグループ内で「当期利益」に基づいてマッチング処理を行なう。
【０１４１】
マッチング処理の結果が一致したか否かを判断する（ステップＳ１０７）。一致した場合、ステップＳ１０９へ進む。一方、一致しなかった場合、同一グループ内の全体機械計算グループ番号を空欄に設定して除外する（不一致とする）。
【０１４２】
そして、直近の決算年月を採用しつつ、店番及び顧客番号による組み合わせキーで一意になるように対象データを抽出して（ステップＳ１０９）、全体マッチングリスト２０９を出力する。また、会員番号、店番、顧客番号による組み合わせキーでキー番号管理を検索し、全体機械計算グループ番号を更新して（ステップＳ１１０）、処理を終了する。
【０１４３】
上記より、全体マッチング処理において、会員別マッチング処理と同様の処理の他、前期の決算年月での一致を確認することによって、より精度の高い名寄せを実現することができる。
【０１４４】
更に、会員別会員認定グループ確定処理１１４での処理と同様に、全体認定グループ確定処理部１２３は、但し、会員採番マッチングリスト２０７ではなく表示ユニットに表示された全体マッチングリスト２０９に基づいて、マッチング処理システム１００の利用者が、最終確認を行なう。つまり、図８に示す会員別マッチングリスト２０６と同様に、マッチング処理の結果が全体マッチングリスト２０９に基づいて表示されるが、この場合、マッチング結果は全て「１」で表示される。利用者は、経験に基づき、グループ毎に左から順に同一であると判断した場合、マッチング結果「１」を変更せず、同一でないと判断した場合、「２」を入力しマッチング結果を変更する。以後、企業毎に３、４、．．．と番号を振っていく。利用者によって確認された全体マッチングリスト２０９の結果は、全体認証グループ番号として管理される。全体認定グループ確定処理部１２３は、全体マッチングリスト２０９の会員番号、店番及び顧客番号を組み合わせキーとしてキー番号管理を検索して、キー番号管理２０１の全体認定グループ番号を更新する。以後、全体マッチングリスト２０９が表示される際には、更新された全体認定グループ番号に基づいて、マッチング結果が示される。
【０１４５】
そして、会員別単一化処理部１１５での処理と同様に、全体単一化処理部１２４は、キー番号管理２０１に基づいて、全体顧客情報ＤＢ２３１、マッチング前財務情報ＤＢ２１２と、全体企業ステータスＤＢ２３２及び全体定量情報ＤＢ２３３とを単一化して、単一化された顧客情報に、夫々単一化されたマッチング前財務情報、企業ステータス、定量情報とを対応させ、マッチング後顧客情報ＤＢ２４１、マッチング後財務情報ＤＢ２４２、マッチング後企業ステータスＤＢ２４３、マッチング後定量情報ＤＢ２４４とを出力する。
【０１４６】
上記処理によって、守秘義務等によって顧客名、住所及び電話番号等の顧客を特定する情報がなく、かつ、重複したデータを単一化することが可能となる。
【０１４７】
また、上記処理は、現実的に、金融機関等で扱われる数十万件にも及ぶデータを処理する際においても、処理負荷を大幅に削減することを可能としている。その例について以下に図１４にて説明する。図１４は、マッチング処理の概念を示す図である。図４に示す会員別決算年月マッチング処理のステップＳ２３において、マッチング対象データを、項目Ｘ及び項目Ｙとを含む所定のデータ項目順に並べ、そのデータ項目の値に基づいてマッチング対象データを幾つかの区分に纏めるとマトリクス５００のように、データが項目Ｘの区分Ｘ１からＸｉ及び項目Ｙの区分Ｙ１からＹｊで区切られたブロックに分散される。ステップＳ２３において、都道府県コードと、決算年月とをデータ項目順に含めることによって、項目Ｘとして都道府県コード、及び、項目Ｙとして決算年月が対応する。都道府県コードによって４７区分に対象データが分散し、また、決算年月によって、四半期毎の過去１０年間が対象となる場合は４０区分に、或いは、年度毎の過去１０年間が対象となる場合は１０区分に対象データが分散することになる。つまり、２つの項目の区分によって１８８０ブロック、或いは、４７０ブロックに対象データが分散する。
【０１４８】
会員から重複を含む１０万件の顧客（取引先企業）に関するデータが提供され、都道府県コードの４７区分と年度毎の決算年月の１０区分でマッチングをした場合について説明する。１０万件のデータは、４７０ブロックのいずれかの対応するブロックに分散する。例えば、最も多くデータが集まる、都道府県が東京都で決算年月が２０００年３月の場合、１万件のデータがその１つのブロックに対応したとすると、東京都の２０００年３月期末の会員別決算年月マッチング処理は、マトリクス５１０のように、１万件データ（顧客Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、．．．）の総当りのマッチングとなる。このようにブロック毎でマッチング処理を行なうことで、大量なデータ１０万件を総当りでマッチングする必要がなくなる。
【０１４９】
また、本実施例において、より多くの名寄せされたデータを取得するため、隣接ブロックを考慮したマッチング処理を行なっている。つまり、１つの決算年月だけでは十分でない場合がある。例えば、図７に示す顧客識別子と決算年月とを対応付けたマトリクス４１２のように、過去に存在していたデータが含まれていない場合がある（決算年月「200003」の顧客識別子Ｄ、Ｅ及びＦ）。これらのデータを取り込むことで名寄せの精度を向上させることができる。それを実現するため、図６に示す会員別マッチング処理のステップＳ３５からＳ３８において、過去の決算年月に遡り、取りこぼしていたデータを含めたマッチング処理を行なっている。例えば、Ｙ１を最近の決算年月とするマトリクス５００において、決算年月「200003」での処理をブロック５０１に対応させると、会員別マッチング処理のステップＳ３５からＳ３８における決算年月「200003」での処理は、ブロック５０２に対応する。
【０１５０】
上記より、項目として都同府県と決算年月を適応した例を説明したが、これに限るものではない。適応した項目に応じて、項目Ｘ及び項目Ｙについて、近隣のブロック５０１及び５０２のデータを含めた名寄せを行なうことができる。例えば、項目として売上高を所定の範囲で複数の区分に分けても良い。その場合、所定桁数での切り上げ、切り下げ、又は、四捨五入等によって近隣のブロックのデータが参照される。
【０１５１】
また、取り込む近隣の範囲は、１つに限るものではない。項目の属性に応じて、複数ブロックを範囲としてもよい。図６に示す会員別マッチング処理は、データが終了するまで過去に遡る処理となっているため、対象となる決済年月を限定することによるデータの取りこぼしがない。
【０１５２】
また、項目を増やしてもよい。項目を増やすことによって、マトリクス５００の次元も増えるが、マッチング処理によるコンピュータへの負荷を大幅に削減することができる。
【０１５３】
例えば、全データの総当りによるマッチング処理では、１０万件のデータに対して、4,999,950,000回（（100,000×99,999）／2）の計算を要する。一方、都道府県及び決算年月の２項目を適用した場合、１０万件のデータが４７０ブロックに分散するため、１ブロック当たり保有するデータ件数は約２１３件（100,000／470）、１ブロック当たりのマッチング処理回数は２２、５７８回（（213×212）／2）、全ブロックのマッチング処理回数は10,611,660回（22,578×470）である。凡そ４７１分の１の処理回数となる。よって、本発明によれば、処理回数を大幅に軽減することができる。
【０１５４】
【発明の効果】
以上、説明してきたように、本願発明によれば、守秘義務の関係から顧客を特定しない顧客情報を管理又は金融機関等の合併等によって顧客情報の構成が統一されていないデータベースが構築された場合においても、区分毎のデータの一致判断となるため、計算処理回数を大幅に削減することができる。また、許容範囲を利用し、データ入力が各項で統一さていない場合においても、顧客情報の名寄せを効果的に実現することができる。
【０１５５】
【図面の簡単な説明】
【図１】マッチング処理システムの機能構成を示す図である。
【図２】マッチング設定画面の例を示す図である。
【図３】マッチング用信号ＤＢ作成処理を説明するフローチャート図である。
【図４】会員別決算年月単位マッチング処理について説明するフローチャート図である。
【図５】会員別決算年月単位マッチングリストの例を示す図である。
【図６】会員別マッチング処理について説明するフローチャート図である。
【図７】会員別マッチング処理の例を示す図である。
【図８】会員別マッチングリストの例を示す図である。
【図９】会員別会員認定グループ確定処理について説明するフローチャート図である。
【図１０】会員別マッチング処理の例を示す図である。
【図１１】会員別単一化処理を説明するフローチャート図である。
【図１２】会員別単一化処理を説明するフローチャート図である。
【図１３】全体マッチング処理を説明するフローチャート図である。
【図１４】マッチングの概念を示す図である。
【符号の説明】
２０          ＣＤ−ＲＯＭ
４０          会員端末
５０          顧客
１００        マッチング処理システム
１１１        マッチング用信用ＤＢ作成処理部
１１２        会員別決算年月単位マッチング処理部
１１３        会員別マッチング処理部
１１４        会員別会員認定グループ確定処理部
１１５        会員別単一化処理部
１２１        全体決算年月単位マッチング処理部
１２２        全体マッチング処理部
１２３        全体認定グループ確定処理部
１２４        全体単一化処理部
１３１        マッチング条件設定処理部
【図１】
0003721315.tif 000002
【図２】
0003721315.tif 000003
【図３】
0003721315.tif 000004
【図４】
0003721315.tif 000005
【図５】
0003721315.tif 000006
【図６】
0003721315.tif 000007
【図７】
0003721315.tif 000008
【図８】
0003721315.tif 000009
【図９】
0003721315.tif 000010
【図１０】
0003721315.tif 000011
【図１１】
0003721315.tif 000012
【図１２】
0003721315.tif 000013
【図１３】
0003721315.tif 000014
【図１４】
0003721315.tif 000015