JP5853233B2 - 重複申込判定方法およびそのシステム - Google Patents

Description

本発明は、重複申込判定方法およびそのシステムに関し、より詳細には、特定の申込者を識別する住所または電話番号の申込情報と一致する申込情報をデータベースの中から検索し、重複申込の検索結果をネットワーク経由でクライアントへ返信する重複申込判定システムおよびその方法に関する。

従来の無人契約機システムは、お客様が画面から申込情報の入力をしている３０分程度の間、オペレータ側で他社の利用状況信用情報を専ら氏名および生年月日を検索文字列にして名寄する照会、お客様の自宅をディスプレイに表示した地図で確認、自宅や勤務先へ電話をして在籍確認、自宅情報やお客様の申告から家族で利用している人が存在するか否か苗字などの整合性に基づきコンピュータ端末を用いて名寄し、融資の契約が可能か否かを審査していた。

勿論、無人契約機システムでは、本人確認のため身分証明書を無人契約機のカメラを通してオペレータが確認する。例えば自動車運転免許証の撮像提示を求め、オペレータが免許証の顔写真、生年月日、免許の有効期限内であるか、印字がずれたりしていないかなどをディスプレイ上で確認するとともに、オペレータが免許証番号をコンピュータ端末へ入力し、初回に免許証を取得した都道府県、初回の免許証取得年、チェックデジットによる免許番号の真偽、再発行の回数をディスプレイに表示させ、お客様が申告している申込情報の整合性を確認していた。

また、従来の金融与信審査システムでは、本願発明者が提案した電話番号クリーニングシステム（特許文献１参照）を用いたコンピュータ与信審査が導入され、お客様の携帯または自宅の電話番号から実在電話番号期間をコンピュータが算出し顧客信用度を判定し偽造カード詐欺集団による申込を排除していた。

特開２００２−２３２５８３号公報

しかしながら、申込者がインターネットを介して消費者金融のサーバにアクセスし、偽造の身分証明書に記載の偽名および生年月日を用いて融資の申込をした場合、氏名と生年月日の名寄による重複申込の審査をパスし、融資の可否と融資枠を事前に獲得する。その後、申込者が無人契約機の設置場所へ赴き所定事項を手書きした申込書を無人契約機へ投入し偽造の身分証明書をカメラに提示するだけで詐欺行為であるにも拘らず無人契約機は数秒後に融資カードを発行してしまうという問題が発生した。

従前の無人契約機では、すでに事前審査により融資決済が完了しているので偽造の身分証明書とインターネット申込時に申告した個人情報をオペレータがディスプレイで確認するだけでカード発行処理を遂行するため、偽造の身分証明書による詐欺が見抜けないという課題が存在する。

また、従前の電話やファックスで事前に融資の可否と融資枠を獲得した場合も上記の課題も存在するばかりか、従前の漢字や片仮名を含む住所情報にるコンピュータ名寄審査では地名表記が統一されていないので、例えば、「新宿区市ヶ谷」と「新宿区市谷」はキャラクタコードが不一致、「さいたま市大宮区」と「サイタマ市大宮区」もキャラクタコードが不一致と判定されるため、名寄審査の精度が低下し重複申込判定が困難である。しかも、申込者は同一住所と同一名義で複数の消費者金融へ同時期に申し込んでから、偽造の身分証明書を廃棄し初回の申込から２日間程度で他の氏名の偽造身分証明書を作成して不正な融資申込を繰り返し、搾取した複数の偽名カードが所定の与信限度額に達した段階で同時多発的に現金自動支払機から現金を引き出している。

さらに、悪意の申込者は、住所表記に自宅住所地のビル名や号や部屋番等を省略しても融資カードの郵便配達が受けられる郵便制度を悪用し、同一の賃貸住所にビル名、号、および部屋番の有無並びに居住者名義を使い分けて複数種類の金融カード申込を短期間に行い、コンピュータ名寄審査を通過させ、郵便配達された多数の金融カードを搾取した後で同時多発的に現金自動支払機から現金を引き出し賃貸住所から撤退するという詐欺行為を繰り返している。

本発明は、この問題に対応してなされたものであり、所定期間に申し込まれた複数の申込情報の中から特定の申込者を識別する申込情報を探索して重複申込を判定する重複申込判定システムおよびその方法を提供することを目的とする。

上記目的を解決するために、本発明の重複申込判定方法は、複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をするサーバを用いた重複申込判定方法であって、前記サーバは、前記ネットワークを介して複数のクライアントから申込情報を受信しデータ集合体毎にデータベースに格納し、現在アクセス中のクライアントから受信された申込情報に含まれ、都道府県市区町村の上位住所区画を特定する郵便番号と、番地が存在するときは下位住所区画を特定する数字列を有する住所情報フィールドを、前記データベースに格納された前記データ集合体の中から検索し、この検索結果から一致する住所情報フィールド数またはデータ集合体数を計数し、該計数結果が所定閾値を超える場合であって、
かつ、
前記申込情報に含まれる電話番号の電話番号利用状況履歴情報を参照して前記電話番号の利用履歴の連続実在期間が所定の期間以下の場合、
前記申込情報が重複申込であると判定し、前記申込情報が重複申込であると判定された場合には、前記ネットワークを介して前記判定結果を申込情報を発信した前記アクセス中のクライアントへ返信する。
また、他の重複申込判定方法は、複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をするサーバを用いた重複申込判定方法であって、前記サーバは、前記ネットワークを介して前記複数のクライアントから申込情報を受信しデータ集合体毎にデータベースに格納し、現在アクセス中のクライアントから受信された申込情報に含まれる電話番号を前記データベースに格納された前記データ集合体の中から検索し、この検索結果から一致する電話番号のデータ集合体数を計数し、該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合、
かつ、
前記申込情報に含まれる電話番号の電話番号利用状況履歴情報を参照して前記電話番号の利用履歴の連続実在期間が所定の期間以下の場合、
前記申込情報が重複申込であると判定し、前記申込情報が重複申込であると判定された場合には、前記ネットワークを介して前記判定結果を申込情報を発信した前記アクセス中のクライアントへ返信する。

上記目的を解決するために、他の本発明の重複申込判定システムは、複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をする重複申込判定システムであって、 前記ネットワークを介して前記複数のクライアントから申込情報をそれぞれ受信しデータ集合体毎にデータベースに格納する収集手段と、 現在アクセス中のクライアントから受信された申込情報に含まれ、都道府県市区町村の上位住所区画を特定する郵便番号と、番地が存在するときは下位住所区画を特定する数字列を有する住所情報フィールドを、前記データベースに格納された前記データ集合体の中から検索する検索手段と、前記収集手段が申込情報を受信した段階で、前記検索手段の検索機能を実現させ検索結果と一致する住所情報フィールド数またはデータ集対数を計数し、該計数結果が所定閾値を超える場合であって、
かつ、
前記申込情報に含まれる電話番号の電話番号利用状況履歴情報を参照して前記電話番号の利用履歴の連続実在期間が所定の期間以下の場合、
受信した申込情報が重複申込であると判定する判定手段と、前記判定手段が重複申込であると判定した場合には、前記ネットワークを介して前記判定手段の判定結果を前記アクセス中のクライアントへ返信する判定結果送信手段と、を備えることを特徴とする。
また、重複申込判定システムは、前記判定結果送信手段が、前記ネットワークを介して前記判定結果を融資決済サーバに送信し、重複申込と判定された住所情報フィールドを有する複数の申込情報にそれぞれ対応するカード発行を保留させる。
さらに、重複申込判定システムは、複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をする重複申込判定システムであって、前記ネットワークを介して前記複数のクライアントから申込情報を受信しデータ集合体毎にデータベースに格納する収集手段と、現在アクセス中のクライアントから受信された申込情報に含まれる電話番号を前記データベースに格納された前記データ集合体の中から検索する検索手段と、前記収集手段が申込情報を受信した段階で、前記検索手段の検索機能を実現させ検索結果と一致する電話番号のデータ集合体数を計数し、該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合、
かつ、
前記申込情報に含まれる電話番号の電話番号利用状況履歴情報を参照して前記電話番号の利用履歴の連続実在期間が所定の期間以下の場合、
前記申込情報が重複申込であると判定する判定手段と、
前記判定手段が重複申込であると判定した場合には、前記ネットワークを介して前記判定手段の判定結果を前記アクセス中のクライアントへ返信する判定結果送信手段と、
を備える。

以上のように、所定期間にクライアント（パーソナルコンピュータ) から申し込まれた複数の申込情報の中から特定の申込者を識別する申込情報を探索して重複申込を判定する重複申込判定システムおよびその方法を提供することができる。また、重複申込判定システムは、同一の企業体が管理および運営するクライアント１２ａ〜１２ｃから申込情報を受信し重複申込を判定してもよく、複数の企業体が個別に管理および運営するクライアント１２ａ〜１２ｃから申込情報を受信し重複申込を判定してもよい。

本発明の実施の一形態を図１乃至図７に基づいて説明する。本実施形態の重複申込判定システム１０は、概略的には、重複申込判定サーバ１８がクライアント１２ａから受信する申込情報と部分的に一致する住所情報フィールドをデータベース１６から読み出し、住所情報フィールド数を計数し、この係数結果が所定閾値を超えることを条件として、重複申込であると判定し、この判定結果をクライアント１２ａへ返信する重複申込判定システム１０である。

ここで、図１は、重複申込判定システムの全体構成を概略的に示すブロック図で、図示する重複申込判定システム１０は、情報処理装置としてパーソナルコンピュータ等の端末装置による複数のクライアント１２ａ〜１２ｃと、例えば、バーチャル・プライベート・ネットワークＶＰＮ、ローカル・エリア・ネットワークＬＡＮ、インターネットのようなネットワーク１４を介して相互に暗号化通信可能に接続され、これらのクライアント１２ａ〜１２ｃから受信する個人情報を含む申込情報をデータベース１６に格納する重複申込判定サーバ１８を備える。

ここで、データベース１６は、記憶部として重複申込判定サーバ１８に内蔵されるハードディスクや、図示するように重複申込判定サーバ１８に接続および外付けされる記憶装置、例えばＣＤ−ＲＷ、磁気ディスク、光ディスク、光磁気ディスクのほかフラッシュメモリＩＣカード、ＥＥＰＲＯＭカートリッジ、磁気テープなどのコンピュータ読み取り可能な記録媒体を用いて格納することができる。

ネットワーク１４には、消費者金融会社が遠隔地に設置するカメラ付き端末としての無人契約機２２、消費者金融会社が管理する融資決済サーバ２０が相互に暗号化通信可能（セキュア・ソケット・レイヤＳＳＬ）に接続され、この融資決済サーバ２０は重複申込判定サーバ１８からネットワーク１４を介して重複申込の判定結果を受信することができる。

また、本実施形態において、データ集合体は、例えばクライアント１２ａからネットワーク１４を介して受診する個人情報を含む複数のフィールドを有し、この個人情報は、単体若しくは組合せによって特定の個人を識別することができる情報として、氏名、生年月日、申込者の連絡先である住所、居所、それら郵便番号、電話番号を主体的に含み、他の個人情報として、申込者の役職名、住民基本台帳番号、口座番号、クレジットカード番号、自動車免許証番号、パスポート番号、申込者のメールアドレスも副次的に含ませることができ、クライアント１２ａから受信する管理番号若しくは重複申込判定サーバ１８が生成する管理番号と対応させてデータベース１６へ格納することができる。

さらに、データ集合体には申込情報に自動記録される各クライアント１２ａ〜１２ｃに割り振られたグローバルＩＰアドレスとクライアントを管理する金融決済サーバ２０のグローバルＩＰアドレスを含ませても良い。これらグローバルＩＰアドレスを認証情報および重複申込判定結果を送信する際のネットワーク１４上の住所として利用することができる。勿論、グローバルＩＰアドレスに代えてクライアント１２ａ〜１２ｃの電子メールアドレスを予め記録してもよい。

図中のクライアント１２ａ〜１２ｃは、ＣＰＵによりブラウザ機能を実現するパーソナルコンピュータを用いることができ、ウエブ画面から申込情報をキーボード入力する。申込情報に含まれる郵便番号はハイフン区切りでキーボード入力し、上位３桁と下位４桁を結合した７桁の連続番号に自動変換して重複申込判定サーバ１８へ送信してもよく、ハイフン区切りの郵便番号を重複申込判定サーバ１８へ送信し重複申込判定サーバ１８側で７桁の連続番号に自動変換させてもよい。

図２は本実施形態の重複申込判定サーバの構成を示すブロック図で、重複申込判定サーバ１８（図１参照）は各種処理を実行するＣＰＵ３０を備え、データベース１６およびネットワーク１４並びにディスプレイ４２に接続されている。データベース１６には、クライアント１２ａ〜１２ｃとの認証をＩＤおよびパスワード並びにＩＰアドレスを照合して実行するログ情報、このログ情報に対応する個人情報フィールドを有するデータ集合体を格納若しくは保存する。このデータベース１６に保存されたログ情報や個人情報を含む各種情報はディスプレイ４２に表示させることができる。

クライアント１２ａ〜１２ｃは、認証情報をキーボードから入力してもよく内部のハードディスクに記憶しているＩＤおよびパスワードを重複申込判定サーバ１８へ自動送信しても良い。この場合、インタネットプロトコルによってクライアント１２ａ〜１２ｃのＩＰアドレスは重複申込判定サーバ１８へ自動送信されるので、重複申込判定サーバ１８は予め登録しているクライアント１２ａ〜１２ｃ毎にアクセス中のクライアントを区別することができる。

ＣＰＵ３０は、ネットワーク１４に接続する送受信制御部２８を備え、申込情報の収集手段３２、個人情報を検索する検索手段３４、重複申込を判定する判定手段３６、この判定手段３６の判定結果を送信する判定結果送信手段３８としての機能を実現する中央処理装置であって、これらの機能は、ＣＰＵ３０が重複申込判定サーバ用のプログラムを主記憶装置（例えばＲＡＭ）の中で実行することによって実現される。

本実施形態の重複申込判定システムでは、複数のクライアント１２ａ〜１２ｃとネットワーク１４を介して接続され、該複数のクライアント１２ａ〜１２ｃから申込情報を受信し重複申込判定をする重複申込判定サーバ１８を、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃから申込情報をそれぞれ受信しデータ集合体毎にデータベース１６に格納する収集手段３２、現在アクセス中のクライアント１２ａから受信された申込情報に含まれ、都道府県市区町村の上位住所区画を特定する郵便番号、番地が存在するときは下位住所区画を特定する数字列を有する住所情報フィールドをデータベース１６に格納されたデータ集合体の中から検索する検索手段３４、収集手段３２が申込情報を受信した段階で、検索手段３４の検索機能を実現させ検索結果と一致する住所情報フィールド数またはデータ集合体数を計数し、該計数結果が所定閾値を超える場合に受信した申込情報が重複申込であると判定する判定手段３６、判定手段３６が重複申込であると判定した場合には、ネットワーク１４を介して判定手段３６の判定結果をアクセス中のクライアント１２ａへ返信する判定結果送信手段３８、として機能させるためのプログラムをＣＰＵ３０で実行する。このプログラムは重複申込判定サーバ１８の内部に設けたコンピュータ読み取り可能な記憶媒体に記憶する。

次に、図３〜図７を参照しながら、本実施形態の重複申込判定システムの基本動作について説明する。

図３〜図５は本実施形態に用いるタイトル欄の情報とデータ集合体のデータ構造図、図６は重複申込判定システムの動作を説明するフローチャート、図７は融資決済サーバの動作を説明するフローチャートである。

本実施形態の検索手段３４では、住所情報フィールドに含まれる所番地情報と郵便番号を数値化し、同一住所で重複申込されたデータ集合体の計数処理を実行している。例えば、検索手段１１によって実行される計数ステップにおいて、データ集合体に含まれる文字もしくは文字列と住所情報の中に特徴的に出現する文字や文字列として予め検索プログラムに設定された特徴文字や特徴文字列とを照合し、特徴文字や特徴文字列がデータ集合体の住所フィールドの中から検出し郵便番号と所番地を結合させ申込情報と一致するデータ集合体を検索する。

また、本実施形態では、ＣＰＵ３０の演算処理能力が標準仕様に比して高い場合は、住所情報フィールドに記憶された住所文字列から所番地を抽出し郵便番号に後方結合処理をしてから申込情報と照合してもよく、ＣＰＵ３０の演算処理能力が標準仕様の場合は、予め郵便番号に所番地を結合する識別番号を住所情報フィールドの中に記憶させてから申込情報と照合してもよい。要は、ＣＰＵ３０の演算処理能力とデータベース１６の記憶容量の費用対効果に基づいて重複申込判定システム１０を構成することができる。

ここで、データ集合体に予め数値情報として記録させる郵便番号および所番地について具体的に説明する。クライアント１２ａ〜１２ｃから受信する申込情報では、郵便番号および住所が必須となる。図３に示すように、日本国内の所番地において特徴的に出現する文字を特徴文字として検索プログラムに予め設定登録する。例えば、所番地には「丁目」、「番」、「番地」、「号」、「−」、「の」が含まれている可能性が高い特徴文字を登録する。

図中のデータ集合体では、「氏名」、「電話番号」、「住所情報フィールド」、および「生年月日」のタイトル欄に合致したフォーマットで申込情報を各データ集合体として収集手段３２が記録すると共に、「住所情報フィールド」の中の所番地を解析し、上述した特徴文字が消去された数字を「郵便番号」の後方に結合する識別番号が収集手段３２により記録されている。

タイトル欄の下段には、図示した「・・・西新宿」が標記されている４個のデータ集合体がデータベース１６に記録され、これらの所番地、郵便マーク付き郵便番号から特徴文字を消去した識別番号「16083302AAA」がデータ集合体として収集手段３２が記録する。この識別番号「16083302AAA」が付与された複数のデータ集合体は同一住所と見做すことができる。

同様に、図示した「・・・青ヶ島」が標記されている３個のデータ集合体がデータベース１６に記録され、これらの所番地、郵便マーク付き郵便番号から特徴文字を消去した識別番号「1001701」がデータ集合体として収集手段３２が記録する。この場合、「青ヶ島」地区は無番地なので所番地のない識別番号が記録される。なお、収集手段３２は申込情報の住所から自動的に郵便番号辞書データから郵便番号を生成しても良い。例えば、申込人によっては、郵便番号の不知や下4桁番号を失念している場合もあるからである。

このように、予め識別番号を付与する図３に示したデータ集合体のフォーマットを用いるとＣＰＵ３０の負荷が低減され検索処理が軽減されるという点で有利である。

次に、図４に示すように、上述した識別番号を予めデータベース１６に格納しないデータ集合体を例示する。住所情報フィールドには申込情報に含まれる郵便番号を記録してもよく、収集手段３２が自動的に住所から郵便番号を生成して記憶しても良い。

図中のデータ集合体では、「氏名」、「電話番号」、「住所情報フィールド」、および「生年月日」のタイトル欄に合致したフォーマットで申込情報をそのまま各データ集合体として収集手段３２が記録する。

検索手段３４は、図示した「・・・西新宿」が標記されているデータ集合体をデータベース１６から順番に読み出し、これらの所番地、郵便マーク付き郵便番号から特徴文字を消去した識別番号「16083302AAA」を含むデータ集合体として検索し、同一の識別番号を有するデータ集合体の個数を計数する。そして、この識別番号「16083302AAA」が付与されたデータ集合体は同一住所と見做すことができる。

同様に、図示した「・・・青ヶ島」が標記されている３個のデータ集合体が記録されているが、上述したように、これらの所番地、郵便マーク付き郵便番号から特徴文字を消去した識別番号「1001701」を含むデータ集合体として検索手段３４が検索する。この場合も、「青ヶ島」地区は無番地なので所番地のない郵便番号と同一の識別番号「1001701」が検索される。

このように、図４に示したデータ集合体のフォーマットを用いるとデータのバイト数が低減できるのでデータベース１６の記憶容量を有効に活用できるという点で有利である。

本実施形態では、好ましくは図５に示すように、上述した特徴文字を消去した申込情報を格納するデータ集合体を用いてＣＰＵ３０およびデータベース１６のシステムリソースを有効に活用することができる。すなわち、住所情報フィールドには申込情報に含まれる郵便番号の連続番号と所番地から生成する識別番号の下桁を記録する。

そして、図中のデータ集合体では、収集手段３２は電話番号も郵便番号も住所所番地標記も特徴文字を消去しデータ圧縮処理を実行し各データ集合体をデータベース１６へ格納する。上述した特徴文字の消去処理については重複説明を省略するが、要はＣＰＵ３０の負荷を軽減し、収集手段３２および検索手段３４の処理速度を向上させると共に、データベース１６の記憶容量を有効活用することができる点で有利である。

上述した重複申込判定サーバ１８によって実行される重複申込判定の一連の手順を、図６に示すフローチャート（ステップＳ５０〜Ｓ５８）に従って説明する。

本実施形態の重複申込判定サーバ１８は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃからのアクセスに対して認証ステップ５０を実行する。認証されたクライアント（ＹＥＳフロー)から申込情報がネットワーク１４を介して受信され申込情報変換ステップＳ５２を実行する。なお、アクセスが拒否された場合はＩＤおよびパスワードの再入力を拒否されたクライアントへ要求する（ステップＳ５１)。

重複申込判定サーバ１８は、複数のクライアント１２ａ〜１２ｃから受信した申込情報をステップＳ５２〜Ｓ５７を経由してデータ集合体毎にデータベース１６に格納する。

次に、重複申込判定サーバ１８では、現在アクセス中の例えばクライアント１２ａから受信された申込情報に含まれ、都道府県市区町村の上位住所区画を特定する郵便番号、番地が存在するときは下位住所区画を特定する数字列を有する住所情報フィールドを申込情報変換ステップＳ５２において特徴文字を消去し識別番号を生成する。

そして、重複申込判定サーバ１８は、データベース１６に格納されたデータ集合体（図３参照）の中から識別番号をキー情報として検索し（ステップＳ５３）、この検索結果から一致する住所情報フィールド数またはデータ集合体数を計数し（ステップＳ５４）、該計数結果が所定閾値（例えば「１００個」）を超える場合に申込情報が重複申込であると判定し（ステップＳ５５のＹＥＳフロー）、申込情報が重複申込であると判定された場合には、重複申込結果出力ステップＳ５６においてネットワーク１４を介して判定結果を申込情報を発信したアクセス中のクライアント１２ａへ返信すると共に、申込情報格納ステップＳ５７を遂行し申込情報をデータベース１６へ格納する。

また、重複申込判定サーバ１８は、該計数結果が所定閾値（例えば「１００個」）を超えない場合（ステップＳ５５のＮＯフロー）、重複申込なし判定出力ステップＳ５８において申込情報が重複申込でない旨の報知をネットワーク１４を介してアクセス中のクライアント１２ａへ返信すると共に申込情報格納ステップＳ５７を遂行し申込情報をデータベース１６へ格納する。

但し、本発明は図６に示すフローチャートに沿った処理シーケンスに限定されず、例えば、クライアント１２ａ〜１２ｃ側で郵便番号などの事前処理を行うときは申込情報変換ステップＳ５２を省略することができ、申込情報検索ステップＳ５３と計数結果算出ステップＳ５４とを結合したＣＯＵＮＴＩＦ（住所情報フィールド、「識別番号」)のようなマクロ命令を実装する計数プログラムをＣＰＵ３０が実行してもよく、不図示の検索エンジンを用いてベータベース１６の中のデータ集合体に対して「郵便番号」と「所番地」を含むＡＮＤ条件の検索を実行してもよい。

また、上述の所定閾値を「１００個」にすることで経験則から詐欺集団を検知するように説明したが、例えば、お一人様２名限定のチケット販売業界では所定閾値を家族の申込を許可するため「４個」にしてもよく、求人業界では過去に同一人物が応募していないか確認するため所定閾値を「１個」にしてもよい。要は本発明の応用分野に対応する所定閾値を任意に設定することができる。

上述したＣＰＵ３０によって実行される重複申込判定の一連の手順を、図６に示すフローチャート（ステップＳ５０〜Ｓ５８）に従って詳細に説明する。

先ず、ＣＰＵ３０は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃからのアクセスに対して送受信制御部２８を用いて認証ステップ５０を実行する。認証されたクライアント（ＹＥＳフロー)から申込情報がネットワーク１４および送受信制御部２８を通じて受信され収集手段３２が申込情報変換ステップＳ５２を実行する。なお、送受信制御部２８によりアクセスが拒否された場合はＩＤおよびパスワードの再入力を拒否されたクライアントへ要求する（ステップＳ５１)。

ＣＰＵ３０は、複数のクライアント１２ａ〜１２ｃから受信した申込情報をステップＳ５２〜Ｓ５７を経由してデータ集合体毎にデータベース１６に格納する。

次に、収集手段３２では、現在アクセス中の例えばクライアント１２ａから受信された申込情報（例えば、偽造運転免許証記載の氏名、住所、生年月日、申告された電話番号の文字列および郵便番号）に含まれ、都道府県市区町村の上位住所区画を特定する郵便番号「160-8330」、番地が存在するときは下位住所区画を特定する数字列「二のＡＡのＢ」を有する住所情報フィールドを申込情報変換ステップＳ５２において特徴文字「の」を消去し識別番号「16083302AAB」を生成する。

そして、検索手段３４は、データベース１６に格納されたデータ集合体（図３参照）の中から識別番号「16083302AAB」を検索文字列として検索し（ステップＳ５３）、この検索結果から一致する住所情報フィールド数またはデータ集合体数を計数する（ステップＳ５４）。

判定手段３６は、該計数結果が所定閾値（例えば「１００個」）を超える場合に申込情報が重複申込であると判定する（ステップＳ５５のＹＥＳフロー）。そして、判定結果送信手段３８は申込情報が重複申込であると判定された場合には、重複申込結果出力ステップＳ５６においてネットワーク１４を介して判定結果（例えば、計数結果や該当するデータ集合体リスト）を申込情報を発信したアクセス中のクライアント１２ａへ返信すると共に、申込情報格納ステップＳ５７を遂行し申込情報をデータベース１６へ格納する。

表示制御部４０は、上記の判定結果（例えば、計数結果や該当するデータ集合体リスト）をディスプレイ４２へ出力しオペレータに注意を促すこともでき、重複申込判定システム１０の稼動状態を常時確認させることもできる。

また、判定手段３６は、該計数結果（例えば「４個」）が所定閾値を超えない場合（ステップＳ５５のＮＯフロー）、重複申込なし判定出力ステップＳ５８において申込情報が重複申込でない旨の報知をネットワーク１４を介してアクセス中のクライアント１２ａへ返信すると共に申込情報格納ステップＳ５７を遂行し申込情報をデータベース１６へ格納する。この場合、表示制御部４０は、上記の判定結果（例えば、「申込情報受信」の文字列と現在の計数結果）をディスプレイ４２へ出力し重複申込判定システムの運用状況をオペレータへ把握させることもできる。

但し、本発明は図６に示すフローチャートに沿った処理シーケンスに限定されないことは上述の通りである。例えば、クライアント１２ａ〜１２ｃは、融資決済サーバ２０にネットワーク１４を介して申込情報を送信し、融資決済サーバ２０が申込情報から抽出する郵便番号および所番地情報をネットワーク１４を介して重複申込判定システム１０へ転送することもできる。具体的には、重複申込判定サーバ１８は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃから申込情報を融資決済サーバ２０にリレーさせて受信しデータ集合体毎にデータベース１６に格納し（Ｓ５７）、現在アクセス中のクライアント１２ａから受信した申込情報を有する住所情報フィールドをデータベース１６に格納されたデータ集合体の中から検索し（Ｓ５３）、この検索結果から一致する住所情報フィールド数またはデータ集合体数を計数し（Ｓ５４）、該計数結果が所定閾値を超える場合に申込情報が重複申込であると判定し（Ｓ５５）、申込情報が重複申込であると判定された場合には、ネットワーク１４を介して判定結果を融資決済サーバ２０にリレーさせてアクセス中のクライアント１２ａへ返信（Ｓ５６）することができる。このように構成すると、例えば、重複申込判定システム１０は融資決済サーバ２０を設置する複数の企業体（同業者）から同時期に申込情報をへ集約して重複判定結果をそれぞれ複数の企業体へ個別に返信することができる。

重複申込判定システム１０は、重複申込判定結果をネットワーク１４を介してアクセス中のクライアントへ直接返信してもよく、融資決済サーバ２０を経由して間接的に返信してもよく、双方に並行して返信してもよい。すなわち、重複申込判定システム１０では公開情報の郵便番号および所番地情報を格納するだけなのでデータベース１６の記憶容量を有効に活用でき特定の個人を識別する個人情報に該当しないデータを伝送する点で有利である。

上述した融資決済サーバ２０によって実行される融資決済保留の一連の手順を、図７に示すフローチャート（ステップＳ６０〜Ｓ６３）に従って詳細に説明する。

融資決済サーバ２０は、ネットワーク１４を介して重複申込判定サーバ１８から重複申込結果（例えば、所定閾値を超えた旨の情報)を受信する。融資決済サーバ２０では予め登録している重複申込判定サーバ１８のＩＰアドレスと照合し認証された申込情報のみ受信を許可するのでハッカーによる業務妨害を未然に防止でき、ネットワーク１４はＶＰＮのような情報漏洩防止システムを提供しているので個人情報は部外者に漏洩しない。

融資決済サーバ２０は、事前融資決済が完了したお客様の中で重複申込に該当するデータ集合体を抽出し、各データ集合体が記憶するお客様にカード発行されたか否か自動判定する（ステップＳ６１)。カードが未発行の場合（ＮＯフロー)は融資決済保留ステップＳ６２へ分岐し該当するお客様の事前融資決済を保留に変更し処理を終了する。この融資決済サーバ２０による事前融資保留プロセスにより不正申込によるカード発行詐欺被害を未然に防止することができ、カード詐欺行為の抑止力となる。

また、融資決済サーバ２０は、ステップＳ６１においてカード発行済を確認した場合（ＹＥＳフロー)、カード使用停止ステップＳ６３へ処理を分岐させ、ネットワーク１４を介して現金自動支払機ＡＴＭからのカード融資実行（現金の払い出し)の最終確認情報に対して保留情報を返信し融資実行シーケンスを停止させ、詐欺によるカード被害を減少させることができる。勿論、ＡＴＭをカメラで監視するオペレータは現金の払い出しを要求する不審者から事情を聴取するため警察に電話通報するであろう。

例えば、偽造運転免許証を使って消費者金融から現金を引き出そうとした場合、偽造有印公文書行使と窃盗未遂容疑などで逮捕できるからである。

本発明の実施形態について住所情報フィールドを検索する重複申込判定システムを説明したが、上述した発明の効果を得ることができる本発明の他の実施形態について電話番号利用状況履歴を検索する下記の重複申込判定システムの機能構成を図１および図２、図８〜図１３を用いて説明する。

他の実施形態の重複申込判定システム１０では、複数のクライアント１２ａ〜１２ｃとネットワーク１４を介して接続され、該複数のクライアント１２ａ〜１２ｃから申込情報を受信し重複申込判定をする重複申込判定サーバ１８を、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃから申込情報をそれぞれ受信しデータ集合体毎に参照回数をカウントアップしてデータベース１６に格納する収集手段３２、現在アクセス中のクライアント１２ａから受信された申込情報に含まれる電話番号をデータベース１６に格納されたデータ集合体の中から検索する検索手段３４、収集手段３２が申込情報を受信した段階で、検索手段３４の検索機能を実現させ検索結果と一致する電話番号の参照回数を計数し、該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合に申込情報が重複申込であると判定する判定手段３６、判定手段３６が重複申込であると判定した場合には、ネットワーク１４を介して判定手段３６の判定結果をアクセス中のクライアント１２ａへ返信する判定結果送信手段３８、として機能させるためのプログラムをＣＰＵ３０で実行する。このプログラムは重複申込判定サーバ１８の内部に設けたコンピュータ読み取り可能な記憶媒体に記憶されている。

図８は他の実施形態に用いるタイトルヘッダとデータ集合体のデータ構造図、図９〜図１３はクライアント側のディスプレイに表示する重複申込判定結果のウエブ画面を示す図である。

他の実施形態の検索手段３４（図２参照）では、参照回数フィールドに含まれる数値情報の計数処理を実行している。例えば、検索手段１１によって実行される計数ステップにおいて、データ集合体に含まれる電話番号と申込情報と一致するデータ集合体を検索しこのデータ集合体に記憶されている参照回数フィールドの参照値を「１」カウントアップする。なお、上述した実施形態と同一または類似の部材は同一または類似の符号を用い、重複する説明を省略する。

他の実施形態において、重複申込判定サーバ１８は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃからのアクセスに対して認証ステップ５０を実行する。認証されたクライアント（ＹＥＳフロー)から申込情報がネットワーク１４を介して受信され申込情報変換ステップＳ５２を実行する。なお、アクセスが拒否された場合はＩＤおよびパスワードの再入力を拒否されたクライアントへ要求する（ステップＳ５１)。

重複申込判定サーバ１８は、複数のクライアント１２ａ〜１２ｃから受信した申込情報をステップＳ５２〜Ｓ５７に経由させデータ集合体毎にデータベース１６に格納しながら参照回数フールドの参照値を「１」カウントアップする。

次に、重複申込判定サーバ１８では、現在アクセス中の例えばクライアント１２ａから受信された申込情報に含まれ、市外局番、市内局番、加入者番号をハイフンまたはカッコのような特徴文字で区切る電話番号を有する電話番号フィールドを申込情報変換ステップＳ５２において特徴文字を消去し識別番号を生成する。なお、携帯電話番号は市外局番桁、市内局番桁、および加入者番号桁に対応する数字列を結合して識別番号を生成する。

そして、重複申込判定サーバ１８は、データベース１６に格納されたデータ集合体（図８参照）の中から識別番号を検索情報として検索し（ステップＳ５３）、この検索結果から一致する電話番号の現在および過去の参照値を計数し（ステップＳ５４）、該計数結果が所定閾値（例えば「１００個」）を超える場合に申込情報が重複申込であると判定し（ステップＳ５５のＹＥＳフロー）、申込情報が重複申込であると判定された場合には、重複申込結果出力ステップＳ５６においてネットワーク１４を介して判定結果を判定中の申込情報を発信したアクセス中のクライアント１２ａへ返信すると共に、申込情報格納ステップＳ５７を遂行しデータベース１６に格納されている申込情報と一致する現在の電話番号の参照値を「１」カウントアップする。

また、重複申込判定サーバ１８は、該計数結果が所定閾値（例えば「１００個」）を超えない場合（ステップＳ５５のＮＯフロー）、重複申込なし判定出力ステップＳ５８において申込情報が重複申込でない旨の報知をネットワーク１４を介してアクセス中のクライアント１２ａへ返信すると共に申込情報格納ステップＳ５７を遂行しデータベース１６に格納されている申込情報と一致する現在の電話番号の参照値を「１」カウントアップする。

但し、本発明は図６に示すフローチャートに沿った処理シーケンスに限定されず、例えば、クライアント１２ａ〜１２ｃ側で電話番号に含まれる特徴文字を消去する事前処理を行うときは申込情報変換ステップＳ５２を省略することができ、申込情報検索ステップＳ５３と計数結果算出ステップＳ５４とを結合したＣＯＵＮＴＩＦ（電話番号フィールド、「識別番号」)のようなマクロ命令を実装する計数プログラムをＣＰＵ３０が実行してもよく、不図示の検索エンジンを用いてベータベース１６の中のデータ集合体に対して「電話番号」を検索してもよい。

また、上述の実施形態と同様に所定閾値を「１００個」にすることで経験則から詐欺集団を検知するように説明したが、例えば、お一人様２名限定のチケット販売業界では所定閾値を家族の申込を許可するため「４個」にしてもよく、求人業界では過去に同一人物が応募していないか確認するため所定閾値を「１個」にしてもよい。要は本発明の応用分野に対応する所定閾値を任意に設定することができる。

上述したＣＰＵ３０によって実行される重複申込判定の一連の手順を、図６に示すフローチャート（ステップＳ５０〜Ｓ５８）に従って詳細に説明する。

ＣＰＵ３０は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃからのアクセスに対して送受信制御部２８を用いて認証ステップ５０を実行する。認証されたクライアント（ＹＥＳフロー)から申込情報がネットワーク１４および送受信制御部２８を通じて受信され収集手段３２が申込情報変換ステップＳ５２を実行する。なお、送受信制御部２８によりアクセスが拒否された場合はＩＤおよびパスワードの再入力を拒否されたクライアントへ要求する（ステップＳ５１)。

ＣＰＵ３０は、複数のクライアント１２ａ〜１２ｃから受信した申込情報をステップＳ５２〜Ｓ５７に経由させデータ集合体毎に参照回数を「１」カウントアップしデータベース１６に格納する。

次に、収集手段３２では、現在アクセス中の例えばクライアント１２ａから受信された申込情報（例えば、電話番号の文字列「03-3340-AAAA」）に含まれ、電話番号フィールド「03-3340-AAAA」を申込情報変換ステップＳ５２において特徴文字「−」、「（」、「）」などを消去し識別番号「033340AAAA」を生成する。

そして、検索手段３４は、データベース１６に格納されたデータ集合体（図８参照）の中から識別番号「033340AAAA」を検索文字として検索し（ステップＳ５３）、この検索結果から一致する電話番号の参照回数を計数する（ステップＳ５４）。

判定手段３６は、該計数結果が所定閾値（例えば「１００個」）を超える場合に申込情報が重複申込であると判定する（ステップＳ５５のＹＥＳフロー）。そして、判定結果送信手段３８が申込情報の重複申込であると判定した場合には、重複申込結果出力ステップＳ５６においてネットワーク１４を介して判定結果（例えば、計数結果や該当するデータ集合体リスト）を申込情報を発信したアクセス中のクライアント１２ａへ返信すると共に、申込情報格納ステップＳ５７を遂行し申込情報に該当する参照回数を「１」カウントアップしてデータベース１６へ格納する。

表示制御部４０は、上記の判定結果（例えば、計数結果や該当するデータ集合体リスト）をディスプレイ４２へ出力しオペレータに注意を促すこともでき、重複申込判定システム１０の稼動状態を確認させることもできる。

また、判定手段３６は、該計数結果が所定閾値を超えない場合（ステップＳ５５のＮＯフロー）、重複申込なし判定出力ステップＳ５８において申込情報が重複申込でない旨の報知をネットワーク１４を介してアクセス中のクライアント１２ａへ返信すると共に申込情報格納ステップＳ５７を遂行し申込情報に該当する参照回数を「１」カウントアップしデータベース１６へ格納する。この場合、表示制御部４０は、上記の判定結果（例えば、「申込情報受信中」の文字列と現在の計数結果）をディスプレイ４２へ出力し重複申込判定システムの運用状況をオペレータへ把握させることもできる。

但し、本発明は図６に示すフローチャートに沿った処理シーケンスに限定されないことは上述の通りである。例えば、クライアント１２ａ〜１２ｃは、融資決済サーバ２０へネットワーク１４を介して申込情報を送信し、融資決済サーバ２０が申込情報から抽出する電話番号をネットワーク１４を介して重複申込判定システム１０へ転送することもできる。

重複申込判定システム１０は、重複申込判定結果をネットワーク１４を介してアクセス中のクライアントへ直接的に返信してもよく、融資決済サーバ２０を経由して間接的に返信してもよく、双方に並行して返信してもよい。すなわち、重複申込判定システム１０では公開情報の電話番号および交換機から取得する理由表示に対応する電話番号利用情報を格納するだけなのでデータベース１６の記憶容量を有効に活用でき個人情報に該当しないデータを伝送する点で有利である。

なお、融資決済サーバ２０によって実行される融資決済保留の一連の手順は上述した実施形態と同様であり重複する説明を省略する。

図８に示すように、データベース１６に格納されているデータ集合体は、「電話番号」、「調査年月日」、「ステータス」、「移転番号」、および「参照回数」のタイトル欄に合致したフォーマットで記録され、例えばクライアント１２ａ〜１２ｃからアクセスされ申込情報に対応する現在の電話番号の参照回数を現在のデータ集合体として収集手段３２が「１」カウントアップする。

タイトル欄の下段には、図示したデータ集合体に含まれる「033340AAAA」の電話番号、調査年月日の「−−−」、ステータスの「−−−」、移転番号の「−−−」、参照回数の「50」のデータ集合体が記録されている。収集手段３２は、電話番号「033340AAAA」がクライアント１２ａ〜１２ｃの何れか１つからネットワーク１４を介して参照されると参照回数を「１」カウントアップし現在のデータ集合体として記録する。

但し、収集手段３２は、クライアント１２ａ〜１２ｃ以外のコンピュータ端末からアクセスされた場合、ＩＰアドレスやＩＤおよびパスワード情報から非カウントアップ端末として処理を遂行する。すなわち、認証を許可する場合であっても参照回数を変化させない電話番号情報の調査やメンテナンスに対応させるためである。

ここで、ステータスフィールドには、電話番号使用状況データが記録され、電話番号フィールドの電話番号毎にＩＳＤＮ交換機から取得するＪＴ−Ｑ９３１（レイヤー３）情報の「０１：欠番」、「１６：正常」、「２２：相手加入者番号変更」、「２８：無効番号」、および移転先電話番号等を電話番号発信コンピュータにより収集しコンピュータ読み取り可能な記憶媒体へ記録する。

例えば、電話番号発信コンピュータは、日本国内に存在する固定および携帯電話に割当てられた約３億５千万件の電話番号を２４時間連続運転状態で所定の順番でオートダイヤルした電話番号、調査月日に対応付けた電話番号使用状況データを実働２０日以内に収集し電話番号発信コンピュータ側のハードディスクに記憶する。

この電話番号使用状況データは月次で更新するので図中の最上段に位置する現在のデータ集合体には当月の申込情報による参照回数が記録されている。現在のデータ集合体の下段に位置する他のデータ集合体は先月以前に収集した過去の電話番号使用状況履歴である。

判定結果送信手段３８は、上述した処理シーケンス（ステップＳ５０〜Ｓ５８）により計数した参照回数および電話番号使用状況データに基づくウエブ画面データを生成し重複申込の判定結果をネットワーク１４に経由させアクセス中のクライアント１２ａ〜１２ｃの何れか１つへ返信する。

具体的には、図９に示すように、ウエブ画面には「申込情報の電話番号（１）の結果」、「電話番号 033340AAAA」、「過去に参照された回数 150」、「場所 東京」の書誌的事項の下に、タイトル欄と時系列に並べた各データ集合体の記録内容を表示する。また参照回数は所定閾値を超えるため、例えば「赤色」の判定結果文字「150」を表示させ他の表示文字色（例えば「黒色」)と異なる文字色または点滅表示により判定結果文字「150」を表示させることができる。

また、「場所 東京」の表示は、固定電話の市外局番および市内局番から特定する担当交換局の所在地情報に基づいて生成される。さらに、携帯電話番号の場合は、携帯電話の市外局番桁および市内局番桁から特定する通信事業者情報を生成し上記の「場所」に変えて表示させてもよい。要は、クライアント１２ａ〜１２ｃ側のオペレータが申込情報と照合できる地域またはキャリア情報を表示するとよい。

図中の電話番号使用状況履歴には、調査年月日に収集したステータス（理由表示）、移転番号、および参照回数が表示されている。検索手段３４は、調査年月日「2007-10-XX」〜「2007-06-XX」の各月参照回数「20」、この各参照回数と現在（当月)の参照回数とを合算し電話番号「033340AAAA」の過去に参照された回数「150」を計数する。すなわち、現在（当月)の参照回数は「50」である。

また、現在から半年以上の実在期間を有する電話番号がなぜ詐欺集団に利用されるのか公序良俗のため詳細について開示できないが、従前の融資決済では許可される電話番号に付いても他の実施形態においては参照回数の履歴およびリアルタイム情報に基づいて精度よく判定することができる。

さらに、検索手段３４は、他人が同一の電話番号「033340AAAA」を使用していた期間（調査年月日「2006-10-XX」、参照回数「3」を含む実在期間）に記憶された参照回数を計数しないので、過去に重複申込に該当する電話番号であるか否かに拘らず、「直近連続実在期間内」にクライアント１２ａ〜１２ｃから参照された回数を計数するため重複申込の判定精度を向上させ判定時間を短縮させることができる。

次に、図１０に示すウエブ画面には、「申込情報の電話番号（２）の結果」、「電話番号 049969BBBB」、「過去に参照された回数 80」、「場所 東京」の書誌的事項の下に、タイトル欄と時系列に並べた各データ集合体の記録内容を表示している。また参照回数は所定閾値以内であり、例えば他の表示文字色（例えば「黒色」)と同一の文字色で表示する。

ウエブ画面には、データベース１６の中に電話番号「049969BBBB」が調査年月日「2007-04-XX」から「2007-10-XX」まで実在する調査結果を記憶している状態を表示している。そして、前月の調査年月日「2007-10-XX」の月次だけ参照回数「10」が記憶され他の月次（調査年月日「2007-09-XX」から「2006-09-XX」）では参照回数「0」である。

したがって、重複申込判定システム１０は、現在（当月)の参照回数を含めて計数した計数結果「80」を検索手段３４により検索しクライアント１２ａ〜１２ｃの何れか１つに表示させている。

重複申込判定サーバ１８側のオペレータも、電話番号「049969BBBB」の参照回数が当月に入り急激に上昇している状態をディスプレイ４２に表示されている計数結果「80」および前月の参照回数「10」から認識することができる。

この場合、クライアント１２ａ乃至１２ｃ側のオペレータは、電話番号の履歴情報だけでは判別できない重複申込を実時間および過去の参照回数の計数結果から所定閾値を超えると予測することができ、直ちに融資決済を約10秒の簡易審査から次段の厳重審査へ移行させ詐欺申込による被害を未然に防止することができる。

他の実施形態の変形例を図１１に示す。ウエブ画面には「申込情報の電話番号（１）の結果」、「電話番号 033340AAAA」、「参照数の推移」の時系列表、「直近参照数の累計 150」、「場所 東京」の書誌的事項の下に、タイトル欄と時系列に並べた各データ集合体の記録内容を表示する。なお、直近参照数の累計（参照回数）は所定閾値を超えるため、上述の他の実施形態と同様に他の表示文字色と異なる有色文字または点滅表示により判定結果文字「150」を表示させることができる。

図中の電話番号使用状況履歴には、調査年月日に収集したステータス（理由表示）、および移転番号が表示されている。検索手段３４は、調査年月日「2007-10-XX」〜「2007-06-XX」の各月参照回数「20」、この各参照回数と現在（当月)の参照回数とを合算し電話番号「033340AAAA」の過去に参照された回数「150」を計数する。すなわち、現在（当月)の参照回数は「50」である。

判定結果送信手段３８は、参照推移の時系列表をウエブ画面に挿入するタグ文字情報を生成し次段の送受信制御部２８へ渡すことで、ネットワーク１４を介してウエブ画面をアクセス中のクライアント１２ａ乃至１２ｃの何れか１つへ表示させることができ、同様に、表示制御部４０を介してディスプレイ４２へ同様のウエブ画面を表示させることができる。

また、図１２に示すウエブ画面には、「申込情報の電話番号（２）の結果」、「電話番号 049969BBBB」、「参照数の推移」の時系列表、「直近参照数の累計 80」、「場所 東京」の書誌的事項の下に、タイトル欄と時系列に並べた各データ集合体の記録内容を表示している。なお、直近参照数の累計は所定閾値以内であり、例えば他の表示文字色（例えば「黒色」)と同一の文字色で表示する。

ウエブ画面の中には、電話番号「049969BBBB」が調査年月日「2007-04-XX」から「2007-10-XX」まで実在する調査結果を表示している。そして、参照数の推移では当月に「70」回、前月の月次（10月)だけ参照回数「10」が表示され他の月次では参照回数「0」が表示されている。また、直近参照数の累計に現在（当月)の参照回数を含めて計数した計数結果「80」が検索手段３４により検索されていることが分かる。

クライアント１２ａ乃至１２ｃ側または重複申込判定サーバ１８側のオペレータは、電話番号「049969BBBB」の参照回数が当月に入り急激に上昇している状態をディスプレイに表示されている参照数の推移から認識することができる。

この場合、クライアント１２ａ乃至１２ｃ側のオペレータは、電話番号の履歴情報だけでは判別できない重複申込を実時間および過去の参照回数の計数結果から所定閾値を超えると予測することができ、直ちに融資決済を約10秒の簡易審査から次段の厳重審査へ移行させ詐欺申込による被害を未然に防止することができる。

上述の他の実施形態で説明した重複申込判定システムの動作によれば、過去の電話番号の履歴および実時間の申込情報を結合して重複申込を判定したが、新設電話番号の申込者による重複申込判定結果を図１３に示す。

ウエブ画面の表示形式は図９および図１０と同一である。電話番号「033340CCCC」は、調査年月日「2006-09-XX」の月次に参照回数「5」、調査年月日「2006-10-XX」の月次に参照回数「100」、その後移転されている重複申込の電話番号である。そして、所定期間（2006-12から2007-03）に亘り欠番状態を経た後に新設電話番号として2007年4月から現在に至る実在の電話番号に変化している。

重複申込判定システム１０は、収集手段３２が申込情報の電話番号「033340CCCC」を受信した段階で、検索手段３４の検索機能を実現させ検索結果と一致する電話番号の参照回数を計数する。この計数結果が電話番号の直近連続実在期間内（当月および実在期間2007-05から2007-10）に所定閾値（例えば「100」）を超える場合に申込情報が重複申込であると判定する判定手段３６を備える。

重複申込判定システム１０は、図示した過去に参照された回数「0」を表示し欠番状態が連続した以前の参照回数を除外している。したがって、新設電話番号の申込者を重複申込者と誤認する誤判定を有効に防止することができ、オペレータの負担を軽減し業務効率を向上させることができる。

具体的には、検索手段３４は、データベース１６の中から電話番号「033340CCCC」と一致するデータ集合体を抽出し調査年月日を降順に探索しながら各参照回数フィールドに記憶された参照数値を計数する。並行してステータスフィールドを検査し「実在」から「欠番」へ変化した段階で計数を中止し計数結果を判定手段３６に渡せばよい。

図１４のフローチャートを参照して、他の実施形態のデータベース１６の生成工程を説明する。

先ず、複数の電話番号発信コンピュータは、全国に流通する固定および携帯電話番号に対してＩＳＤＮ（Integrated Services Digital Network）回線を通じてオートダイヤルして得た利用状況を示す理由表示データおよび移転先電話番号を、分担する各電話番号に対応させてオートダイヤルした調査年月日と共に履歴情報としてハードディスクに登録し月次の電話番号情報をそれぞれ収集する（ステップＳ７０)。

次に、コンピュータを用いて、データベース１６に記憶された当月のデータ集合体を読み出し、当月申込情報が存在するか否か参照回数に基づいて判定する（ステップＳ７１)。参照回数が記憶されているときは（ＹＥＳフロー）ステップＳ７２へ処理を分岐させ参照回数を収集した電話番号情報へ追加記録してからデータベース１６の履歴データ更新処理ステップＳ７３を遂行する。

一方、当月申込情報が存在しないときは（ＮＯフロー）ステップＳ７３へ処理を分岐させ電話番号情報へ「0」の参照回数を書き込み履歴データ更新処理を遂行する。履歴データ更新処理ステップＳ７３では、ファーストイン・ファーストアウトＦＩＦＯ方式により最初に記録した調査年月日、ステータス、移転番号、参照回数をデータ集合体の中から削除しデータベース１６の記憶容量を有効に利用する。

但し、本発明は、上述したデータベース１６の更新方法に限定されず、例えば、ステップＳ７０で収集した電話番号情報をそのままデータベース１６へ追加して更新し、参照回数データは重複申込判定サーバ１８の記憶部に別途記憶させても上述した他の実施形態と同様の効果を得ることができる。要は、調査月次に対応する電話番号の参照回数を重複申込判定サーバ１８側に記憶させ受信した申込情報と照合させるとよい。

本発明の他の実施形態について電話番号利用状況履歴を検索する重複申込判定システムを説明したが、上述した発明の効果を得ることができる本発明の追加の実施形態について申込情報のログ履歴を検索する重複申込判定システムの機能構成を図１および図２を用いて説明する。

追加の実施形態の重複申込判定システム１０では、複数のクライアント１２ａ〜１２ｃとネットワーク１４を介して接続され、該複数のクライアント１２ａ〜１２ｃから申込情報を受信し重複申込判定をする重複申込判定サーバ１８を、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃから申込情報をそれぞれ受信しデータ集合体毎にデータベース１６に格納する収集手段３２、現在アクセス中のクライアント１２ａから受信された申込情報に含まれる電話番号をデータベース１６に格納されたデータ集合体の中から検索する検索手段３４、収集手段３２が申込情報を受信した段階で、検索手段３４の検索機能を実現させ検索結果と一致する電話番号のデータ集合体数を計数し、該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合に申込情報が重複申込であると判定する判定手段３６、判定手段３６が重複申込であると判定した場合には、ネットワーク１４を介して判定手段３６の判定結果をアクセス中のクライアント１２ａへ返信する判定結果送信手段３８、として機能させるためのプログラムをＣＰＵ３０で実行する。このプログラムは重複申込判定サーバ１８の内部に設けたコンピュータ読み取り可能な記憶媒体に記憶されている。

ここで、ＣＰＵ３０は、データ集合体を申込情報の受信日時と管理番号と共にデータベース１６に記録する。すなわち、上記の他の実施形態では各調査月次に約３億５千万件の電話番号に対応させて参照回数データを記憶するので、多数の記憶容量を占めるであろう「０」回の参照回数データも当月および過去の履歴に記録されている。したがって、データベース１６の記憶容量をさらに有効利用するため複数のクライアント１２ａ〜１２ｃから受信した申込情報のログ情報をデータベース１６へ記録し、参照回数フィールドを用いない重複申込判定サーバ１８を提供する。

追加の実施形態において、重複申込判定サーバ１８は、ネットワーク１４を介して複数のクライアント１２ａ〜１２ｃからのアクセスに対して認証ステップ５０を実行する。認証されたクライアント（ＹＥＳフロー)から申込情報がネットワーク１４を介して受信され申込情報変換ステップＳ５２を実行する。以下、認証を許可されたシーケンスを説明する。

重複申込判定サーバ１８は、複数のクライアント１２ａ〜１２ｃから受信した申込情報をステップＳ５２〜Ｓ５７に経由させデータ集合体毎にデータベース１６に受信日時および管理番号と共にログ情報として格納する。

次に、重複申込判定サーバ１８では、現在アクセス中の例えばクライアント１２ａから受信された申込情報に含まれ、市外局番、市内局番、加入者番号をハイフンまたはカッコのような特徴文字で区切る電話番号を有する電話番号フィールドを申込情報変換ステップＳ５２において特徴文字を消去し識別番号を生成する。なお、携帯電話番号は市外局番桁、市内局番桁、および加入者番号桁に対応する数字列を結合して識別番号を生成する。

そして、重複申込判定サーバ１８は、データベース１６に格納された不図示のログ情報の中から識別番号を検索条件として検索し（ステップＳ５３）、この検索結果から一致する電話番号のログ件数を計数し（ステップＳ５４）、該計数結果が所定閾値（例えば「１００個」）を超える場合に申込情報が重複申込であると判定し（ステップＳ５５のＹＥＳフロー）、申込情報が重複申込であると判定された場合には、重複申込結果出力ステップＳ５６においてネットワーク１４を介して判定結果を判定中の申込情報を発信したアクセス中のクライアント１２ａへ返信すると共に、申込情報格納ステップＳ５７を遂行しデータベース１６に申込情報の受信日時および管理番号と共にログ情報として格納する。

ＣＰＵ３０は、ログ情報に記憶する申込情報の受信日時を降順に探索し該当する電話番号の調査年月日と比較しながら、電話番号の欠番を記録する調査年月日を検知することでログ件数を係数してもよく、上述したようにマクロ命令を用いて直近連続実在期間と電話番号のＡＮＤ検索条件により一括してログ件数を計数してもよい。

また、ＣＰＵ３０は、図９乃至図１３に示す「参照回数」や「過去に参照された回数」をログ情報の中に記憶している直近連続実在期間内の申込情報の受信年月日と電話番号のＡＮＤ条件を満たすログ件数を算出する。この場合、ＣＰＵ３０は申込情報を受信する毎にログ件数を計数するので負荷が増加するがデータベース１６の記憶容量は上述した如く有効に利用することができるという利点がある。

このように、ＣＰＵ３０はデータベース１６の中からログ情報を読み出して参照回数を累積演算するので、重複申込判定サーバ１８側にアクセスカウンタを設ける必要がなく、クライアントがアクセスしているウェブページにどれだけのアクセスがあったかという情報を重複申込判定サーバ１８側に記録およびクライアント側に表示させるＣＧＩのプログラムを実装しなくとも、参照回数をクライアント側へ表示（例えば、図９〜図１３参照）させることができる。

しかも、アクセスカウンタでは、認証を許可された後に表示される申込情報入力用ウェブページにアクセスした段階でＣＰＵ３０がアクセスカウンタ用プログラムを起動させ、このプログラムとは別に用意された申込情報入力用アクセス数記録ファイルから、記録されているアクセス数を読み取り、読み取ったアクセス数に「１」を加算した数値をアクセス数記録ファイルに書き戻してから申込情報入力用ウェブページに表示させるため、これから入力する申込情報と無関係な情報入力用ウェブページのアクセス数を表示するという課題も解消できる。

したがって、追加の実施形態では、現在流通している電話番号の件数、約３億５千万件分のアクセスカウンタ用プログラムを実装する参照回数表示ページ情報（ＨＴＭＬのタグ情報）を記録する必要もないので、重複申込判定サーバ１８側の記憶容量を有効に活用することができる。

なお、本発明の実施形態または他の実施形態若しくは追加の実施形態に記載された、作用及び効果は、本発明から生じる最も好適な作用及び効果を列挙したに過ぎず、本発明による作用及び効果は、本発明の実施形態に記載されたものに限定されるものではない。例えば、参照回数を「１」増加するインクリメント方式について説明したが、本発明はこれに限定されず所定閾値を出発数値として予め記憶し参照回数を「１」減少するデクリメント方式を採用してもよい。

本発明の実施形態として重複申込判定システムを概略的に示すブロック図。 本発明の実施形態として重複申込判定システムを示すブロック図。 実施形態に用いるデータ集合体の構造図。 実施形態に用いるデータ集合体の構造図。 実施形態に用いるデータ集合体の構造図。 本発明の実施形態として重複申込判定システムの動作を示すフローチャート。 本発明の実施形態として重複申込判定システムの動作を示すフローチャート。 他の実施形態に用いるデータ集合体の構造図。 他の実施形態のウエブ画面を示す図。 他の実施形態のウエブ画面を示す図。 他の実施形態のウエブ画面を示す図。 他の実施形態のウエブ画面を示す図。 他の実施形態のウエブ画面を示す図。 他の実施形態のデータベース作成動作を示すフローチャート。

符号の説明

１０ 重複申込判定システム
１２ａ〜１２ｃ クライアント
１４ ネットワーク
１６ データベース
１８ 重複申込判定サーバ
２０ 金融決済サーバ
２２ 無人契約機

Claims (2)

1. 複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をするサーバを用いた重複申込判定方法であって、
   前記サーバは、前記ネットワークを介して前記複数のクライアントから申込情報を受信しデータ集合体毎にデータベースに格納し、
   前記データ集合体は、電話番号、電話番号使用状況の調査年月日、電話番号使用状況データ及びクライアントからの申込情報に対応する電話番号の参照回数の所定期間毎のデータを有し、
   現在アクセス中のクライアントから受信された申込情報に含まれる電話番号を前記データベースに格納された前記データ集合体の中から検索し、
   この検索結果から一致する電話番号のデータ集合体から電話番号使用状況の調査年月日及び電話番号使用状況データに基づいて時系列での直近連続実在期間内の参照回数を計数し、
   該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合に前記申込情報が重複申込であると判定し、
   前記申込情報が重複申込であると判定された場合には、前記ネットワークを介して前記判定結果を申込情報を発信した前記アクセス中のクライアントへ返信する重複申込判定方法。
2. 複数のクライアントとネットワークを介して接続され、該複数のクライアントから申込情報を受信し重複申込判定をする重複申込判定システムであって、
   前記ネットワークを介して前記複数のクライアントから申込情報を受信し、電話番号、電話番号使用状況の調査年月日、電話番号使用状況データ及びクライアントからの申込情報に対応する電話番号の参照回数の所定期間毎のデータを有するデータ集合体をデータ集合体毎にデータベースに格納する収集手段と、
   現在アクセス中のクライアントから受信された申込情報に含まれる電話番号を前記データベースに格納された前記データ集合体の中から検索する検索手段と、
   前記収集手段が申込情報を受信した段階で、前記検索手段の検索機能を実現させ検索結果と一致する電話番号のデータ集合体から電話番号使用状況の調査年月日及び電話番号使用状況データに基づいて時系列での直近連続実在期間内の参照回数を計数し、該計数結果が電話番号の直近連続実在期間内に所定閾値を超える場合に前記申込情報が重複申込であると判定する判定手段と、
   前記判定手段が重複申込であると判定した場合には、前記ネットワークを介して前記判定手段の判定結果を前記アクセス中のクライアントへ返信する判定結果送信手段と、を備えることを特徴とする重複申込判定システム。