JP2006085446A - カード不正使用防止システム - Google Patents

Abstract

【課題】 クレジットカードやキャッシュカードによる取引内容をそのカード名義人に対して通知して正当性を確認することで、第三者による当該カードの不正使用防止に有効なカード不正使用防止システムを提供する。
【解決手段】 小売の店舗１にて商品購入した代金決済がクレジットカードを利用して行われると、その取引内容は決済管理センター１０に送信され、決済情報から取引内容を認識するのに必要な情報をセキュリティ管理部２０から当該カードの名義人の登録済み連絡先である携帯電話など携帯端末４に電子メールなどで通知される。通知を受けたカード名義人はそのカード取引が自ら覚えがない場合は直ちに通知元であるセキュリティ管理部２０を経由して決済管理センター１０に急報される。決済管理センター１０は当該カード取引が無効である旨のエラー信号などを店舗１のカード決済端末装置２に送信するとともに、それ以降のカード使用を差し止める。
【選択図】 図１

Description

本発明は、クレジットカードやキャッシュカードの不正使用を防止するカード不正使用防止システムに関するものである。

近年、キャッシュカードやクレジットカードなど与信取引用のカードの盗難や偽造による不正使用が続発している。カード名義人である本人にとって、悪意の第三者による不正行為でカード取引が行われると暫くの期間、たとえば月次の請求書や月間利用明細書が本人宛に郵送されてくる最長期間１ヶ月間という期間はその不正取引を把握できず、被害額が増大してしまう危険性を負っている。月間利用明細書が送られてきて本人は初めて身に覚えの無い取引の存在を知ることになる。通常、カードを使用して物品購入の代金を決済したり、あるいは現金借入れ（キャッシング）などの与信取引が行われる場合、銀行や信販会社など金融機関ではカード発行先の顧客ごとにカード取引状況を逐一モニタしている。仮に同時刻に東京と大阪といった遠距離間で同一カードの使用が発生したような場合、それを不審取引として判断してカード名義人の本人に電話連絡して確認をとっている。しかし、それだけでは万全の処置といえず、カード名義人が認知するまでの最長１ヶ月間という不正取引が放置される期間を極力短縮して、仮に１週間ごとに利用明細書を郵送するというのでは、膨大な顧客ごとに金融機関側のコストが甚大なものとなり、顧客の立場からも煩わしく現実的ではない。る。

そうしたカード不正使用に係る諸問題を解決すべくこれまで多くの提案がなされてきた。たとえば特開２００１−２９１０３４号公報や特開２００２−１８３６４１号公報においても、カード不正使用防止システムや本人確認方法が開示されている。
特開２００１−２９１０３４号公報 特開２００２−１８３６４１号公報

しかしながら、従来のカード不正利用防止システム、そして上記２つの公報に記載のカード不正使用防止システムや本人確認方法のいずれにおいても、カード名義人本人が金融機関から通知を受けて第三者による不正取引を認知するまでにやはり相当な時間が掛かっており、不正使用を即時防げるという即効性に関して基本的な解決策とはなっていない。

以上の問題点に鑑み、本発明の目的は、クレジットカードやキャッシュカードによる取引内容をそのカード名義人に対して通知して正当性を確認することで、第三者による当該カードの不正使用防止に有効なカード不正使用防止システムを提供することにある。

以上の点を解決するために、本発明は次の構成を採用する。
＜構成＞
上記目的を達成するために、本発明による請求項１記載のカード使用不正使用システムは、クレジットカードおよびキャッシュカードを含む与信取引カードを利用した決済情報を予め登録した連絡先に対して、当該カードが利用されたことを認識させるのに必要な情報とともに通知するようにしたことを特徴とする。また、本発明による請求項２に記載のカード不正使用防止システムは、クレジットカードおよびキャッシュカードを含む与信取引カードを利用した決済情報を予め登録した連絡先に対して、当該カードが利用されたことを認識させるのに必要な情報とともに通知して承認させるようにしたことを特徴とする。

クレジットカードなど与信取引用カードを使用して物品購入などの代金決済が行われた際、その取引内容をカード名義人の連絡先に通知することで、カード名義人にそのカード取引の正当性を認識させたり、あるいは承認させることにより、悪意の第三者によるカード不正利用を防止することができる。

以下、本発明の実施形態について図を用いて詳細に説明する。

＜実施例１の構成＞
図１は、本例のカード不正使用防止システムの構成を示す機能ブロック図である。、以下、クレジットカードの処理について説明するが、クレジットカードに限らず与信取引用であれば他カードについても適用されるものとする。市中の小売店舗１では顧客３が物品購入の際に支払代金をクレジットカードで決済可能となっており、またＡＴＭ装置など利用してそのクレジットカードで現金借入れも可能となっているとする。店舗１に設置されたカード決済端末装置２は、顧客３から受け付けたカードの決済情報を銀行など金融機関の決済管理センター１０、あるいは信販企業などクレジットカードを発行して管理する事業体の決済管理センター１０のデータ送受信部１５へＷｅｂやWAN(Wide Area Network)などのネットワーク５を介して送信するようになっている。決済情報は、利用日、利用時刻、クレジットカード番号、カード有効期限、購入商品名、購入金額、分割払いの有無と分割回数、および利用店舗名などからなっている。

決済管理センター１０では顧客３ごとにすべての顧客情報を管理し、発行カードによる取引情報を統合して収集するようになっており、顧客情報を格納した顧客情報データベース１２を管理する顧客管理モジュール１１が備わっている。銀行発行カードであるならば、その顧客情報データベース１２には当該顧客３に関する店番号、普通か当座の科目、口座番号、暗証番号などの情報、またカードが正当なものかどうか、有効期限、現在使用可能か停止状態かといった各種情報が格納されている。さらに、決済管理センター１０には残高管理モジュール１３が備わり、ここでは顧客３ごとにカード取引設定額を管理するとともに、カード取引時に取引金額が設定額内かどうかを判断するための残高情報を格納した残高データベース１４を管理している。こうした決済管理センター１０は、次に述べるセキュリティ管理部２０に対して当該顧客３に関する必要な情報を提供して決済の確認処理を依頼するようになっている。

セキュリティ管理部２０は、決済管理センター１０からカード名義人である当該顧客３に関するクレジットカード取引において必要な情報を受け取り、顧客所有の携帯電話などのモバイル端末機、家庭や勤務先に設置されたパーソナルコンピュータといった電子メール受信可能なメール受信端末機４に送信して情報提供するメールサーバ２１を備えてなっている。このメールサーバ２１は、顧客３ごとに予め登録したメールアドレスとカード名義人を関連付けした情報テーブルでなっているメールアドレスデータベース２２を格納し、ここから取得した必要な情報を顧客３に対して通知するメール送受信部２３を備えている。

ここで、決済管理センター１０からセキュリティ管理部２０へ提供される上記「必要な情報」とは、上記の各種決済情報のうち、顧客３がカード名義人本人であるかどうかを認定できる最小限情報を意味し、「利用日」、「利用時刻」、「購入商品名」、そして「購入金額」からなっているものとする。

なお、本例では、決済管理センター１０内においてセキュリティ管理部２０を新規部門として設置したシステムが述べられるが、かかるセキュリティ管理部２０を専門企業などの事業体として分離させた場合であっても本発明の主旨を達成することができる。

＜実施例１の動作＞
次に、かかる実施例１の動作および作用について図２の動作フローを参照して説明する。
カード名義人である顧客本人が店舗１で物品購入代金の決済をクレジットカード使用で求めると、店舗１のカード決済端末装置２から決済管理センター１０へ、当該カード決済情報として利用日、利用時刻、クレジットカード番号、カード有効期限、購入商品名、購入金額、分割払いの有無と分割回数、そして利用店舗などの項目がネットワーク５を介して送信される(ステップ：Ｓ１)。決済管理センター１０では、かかる決済情報を受信すると当該顧客３の債務として記録する。

決済管理センター１０は、店舗１のカード決済端末装置２から受信したカード情報から、当クレジットカードを利用して決済した顧客がカード名義人本人であるかどうか認定するための必要な情報のみを抽出する(ステップ：Ｓ２)。すなわち、「本人認定に必要な情報」とは、この場合、利用日と、利用時刻と、購入商品名と、そして購入金額からなっている。抽出した認定用情報は決済管理センター１０のデータ送受信部１５からセキュリティ管理部２０へ、決済の確認処理を依頼する旨の要請情報とともに送信される。

セキュリティ管理部２０は、決済管理センター１０から要請された当該顧客３に関する認定用情報と確認処理要請情報を受け取ると、メールサーバ２１はメールアドレスデータベース２２を参照して格納されている当該カードに関する名義人とメールアドレスを読み出し、カード名義人に対してたとえば「カード取引が行われました」といったような文面の確認メールを作成し、メール送受信部２３からネットワーク６を介してカード名義人所有の携帯電話などメール受信端末機４へ送信して通知する(ステップ：Ｓ３)。次のステップＳ４において、店舗１の店頭でカード使用した顧客３がカード名義人本人であれば、つまり顧客３は自身がカード名義人であれば、通知を受けた確認メールを読解して了承する(YeＳ：取引有り)。仮に、店頭先でカード使用した顧客３がカード名義人本人でない場合、別場所で確認メールを受信したカード名義人は身に覚えのない取引であるので、直ちに確認メールの送信元であるセキュリティ管理部２０へたとえば「先ほどのカード取引は私ではありません」といったような文面でもってメール返信または電話連絡で急報する（Ｎｏ：取引無し）。

セキュリティ管理部２０は、カード名義人から覚えの無いカード取引である旨の連絡を受けて決済管理センター１０に転送し、決済管理センター１０はカード不正利用と判断して店舗１のカード決済端末装置２へ当該カード利用無効を示す文面またはエラー信号を送信する。店舗店頭先では当該カードを持ち込んだ顧客に対して決済を拒否する旨を通告する。そうした処理に併行して、決済管理センター１０は当該カードのそれ以後の利用を停止させる(ステップ：Ｓ５)。

なお、以上の実施例１においては、セキュリティ管理部２０からカード名義人の携帯電話などメール受信端末機４に送信される確認メールの内容について、前述のように、「本人認定に必要な情報」として利用日、利用時刻、購入商品名、購入金額などの項目を参照するものであった。個人情報保護という観点から、本人認定に必要な情報を「利用日」と「利用時刻」と「カード利用したという事実」という最小限の情報だけでも、カード名義人は自らカード取引したか否かが判断でき、その事実がなければ直ちに返信してカード使用を差し止めることが可能である。

＜実施例１の効果＞
以上のように、本例では、クレジットカードなどで与信取引が行われた際、その取引内容をカード名義人に電子メールで連絡することで、カード名義人がその取引事実を確認して、取引の事実に覚えがなければ直ちに第三者による不正使用と判断して当該カード使用を差し止めて被害を防ぎ、あるいは被害を最小限に抑えることができる。
また、システムを構築するのに店舗は多大な設備投資をする必要もなく、店頭先の既存の受信端末装置を用いることができるし、銀行など金融機関や信販企業でも決済管理センター１０にセキュリティ管理部２０といった若干の設備を増設するだけで、特別な人員の配置も不要で経費出費を抑え、しかもカード不正防止に有効なシステムということで顧客満足を高めることができる。また、カード名義人の希望でかかるサービスを有料で契約すれば実利が期待できる。

＜実施例２の構成＞
上記実施例１では、店舗１など店頭先でカード取引が行われた際にそのカード決済情報を電子メールにてカード名義人に通知することで、そのカード取引がカード名義人本人によるものか、悪意の第三者による不正使用かを監視するシステムとされた。その場合、カード名義人は所有する携帯電話などメール受信端末機でセキュリティ管理部２０からの確認メールを見落としたり確認が遅れたりすると、口座から予期せぬ金額が引き落としされてしまう場合も有り得る。メール受信端末機が自宅や勤務先のパソコンの場合は特に帰宅後とか勤務中の多忙などの理由で確認するまでに時間が掛かることがある。また、確認メールで通知を受けて決済管理センター１０に急報して取引停止を要請するといった手続き的な手間がある。さらには、カード使用を差し止める直前に店舗などにおいて既に不正使用者に商品が手渡されてしまっておれば、損害が発生する懸念がある。

そこで、本例ではそうした懸念を払拭するために、メール受信端末機として自宅や勤務先のパソコンを利用せず、カード名義人が常時携帯する携帯電話などに限定して確認を急ぎ、カード決済の承認をいち早く行う構成となっている。なお、実施例１に共通する各部・各装置には同一符号を付して説明を省く。

図３は、本例の決済管理センター１０の構成を示す機能ブロック図であり、この場合決済可否確認手段１６を新たに設けたことが実施例１と異なる点である。決済管理センター１０は、取引加盟店など小売の店舗１からの店頭先でのカード取引に関して認証の依頼を受けた際、「当該カードが有効であるか否か」、「購入金額がカード利用可能限度額以内であるか」などの確認を行う。その際、さらに決済可否確認手段１６によって決済の可否確認を行うようになっている。この決済可否確認手段１６は、決済管理センター１０に設けられた管理サーバで動作するプログラムであり、セキュリティ管理部２０に決済の可否確認を依頼するとともに、セキュリティ管理部２０から決済の可否確認結果を受信し、図示しない既存の決済認証手段に通知するようになっている。この決済認証手段は、決済が有効と認められたならば取引加盟店の店舗１に対して了解した旨の応答を行い、有効性が認められず決済否の場合はエラーコードを通知するようになっている。

図４は、本例のセキュリティ管理部２０の構成を示す機能ブロック図である。この場合のセキュリティ管理部２０は、カード名義人と、カード名義人の連絡先であるメールアドレスや携帯端末である携帯電話の電話番号やカード名義人の保有する携帯端末を識別するための携帯端末ＩＤを対応付けするための承認データベース４１が備わっている。携帯端末ＩＤとは、携帯端末ごとに割り振られているユニークな番号であり、個別の携帯電話の認証が可能となっている。また、本例のセキュリティ管理部２０は以下の各サーバが備わっている。すなわち、携帯端末に決済の承認を行わせるための承認サーバ４２、Ｗｅｂページを提供するためＷｅｂサーバ４３、Ｊａｖａアプリケーションを提供するためのＡＰサーバ４４、メールを送信するためのメールサーバ４５などである。さらに、本例のセキュリティ管理部２０には、ユーザの携帯端末に対してメールやデータを送信するための通信手段４６が備わっている。なお、上記承認データベース４１としては、決済管理センター１０の図１で示された顧客情報データベース１２に上記情報を追加して含んでおればよく、セキュリティ管理部２０から共通に利用することもできる。

そこで、図５は、本例で使用する携帯端末３０の具体例である携帯電話の構成を示す機能ブロック図である。かかる携帯端末３０としては、メール受信機能やＷｅｂアクセス機能、そしてＪａｖａアプリケーション実行機能などといった本例で適用可能なものであれば、その他機種としてPDAやノート型パソコンであってもよい。通信手段３１は、セキュリティ管理部２０との通信を行うための機能部であり、セキュリティ管理部２０からの問い合わせを受信して承認するためのデータ送受信、そして承認結果の送信などを行う。承認手段３２は、通信手段３１で受信した承認用データに基づいて顧客に対して承認のための機能を提供し、また承認操作を受け付け、通信手段３１を使用して承認結果をセキュリティ管理部２０に送信する機能部となっている。かかる承認手段３２は、携帯電話の制御部上で動作するメールソフトやブラウザ、またはブラウザ上に表示されているＨＴＭＬページやＪａｖａアプリケーションなどのプログラムである。また、表示手段３３を有し、承認手段３２からの承認情報を顧客に画面表示し、液晶パネルや有機ＬＥＤなどでなっている。さらに、入力手段３４は、顧客が承認のための入力操作を行うテンキーや入力レバーやカーソルパッドなどからなっている。

＜実施例２の動作＞
次に、以上の構成による実施例２の動作について図６の動作フローを参照して説明する。市中の店舗１などでクレジットカードが代金決済に使用された際、通常手続きによって図１に示す店舗の決済端末装置２から決済管理センター１０に当該カードの正当性認証についての依頼が送信される(ステップ：Ｓ１０)。決済管理センター１０では、店舗１からカード認証依頼を受信すると、当該カードの有効性、購入金額がカード利用可能限度額以内であるかどうかといった通常の確認処理を開始する。確認結果、カード正当性の確認がとれると決済可否確認手段１６が起動する。決済可否確認手段１６はクレジットカード番号など顧客を特定できる情報に加えて、利用日、利用時刻、購入商品名、利用金額など決済情報をセキュリティ管理部２０の承認サーバ４２に送信する(ステップ：Ｓ１１)。承認サーバ４２は、クレジットカード番号に基づいて通知すべき顧客のメールアドレス、携帯電話番号および携帯端末ＩＤを取得する。その後、顧客から承認を得るべく顧客の携帯端末３０との間で通信を開始する（ステップ：Ｓ１２）。顧客は、携帯端末３０にてセキュリティ管理部２０と通信を行い、通知されたカード利用情報を確認し、承認または非承認の操作を行う（ステップ：Ｓ１３）。顧客からの承認結果はセキュリティ管理部２０に送信され（ステップ：Ｓ１４）、さらに決済管理センター１０へ決済可否確認結果として送信される（ステップ：Ｓ１５）。決済管理センター１０は、決済可の場合は店舗１の決済端末装置２に対してその旨の情報を送信し、決済否の場合は拒否情報としてのエラーを通知する。

ここで、上記ステップＳ１２〜Ｓ１４の各処理において、携帯端末３０上で顧客に承認操作を行わせるための機能部である承認手段３２は、電子メールとＷｅｂブラウザとの組み合わせによっても実現可能であるが、好適にはＪａｖａアプリケーションなどのソフトウエアによって実現することが望ましい。以下は、それらＪａｖａアプリケーション、電子メールおよびＷｅｂブラウザを用いた各処理動作である。

＜Ｊａｖａアプリケーションを用いる場合＞
この場合、携帯端末３０上の承認手段３２としてＪａｖａアプリケーションを常駐して動作させる。このため、携帯電話の場合は待ち受けＡＰとして動作させることが望ましい。図７はそうした場合の動作フローを示している。すなわち、セキュリティ管理部２０はクレジットカード番号に基づいて特定したカード利用者の携帯端末に対して、Ｊａｖａアプリケーションの起動確認の通知を行う(ステップ：Ｓ２０)。携帯端末は、上記のような通知に応答してＪａｖａアプリケーションが起動状態であるかどうかをセキュリティ管理部２０に通知する(ステップ：Ｓ２１)。そうした応答は、携帯端末に備わる確認機能を使用できるし、Ｊａｖａアプリケーション自体がセキュリティ管理部２０に返答するようにしてもよい。起動確認ができなかった場合、決済否として扱うか、それとも後述する電子メールを用いる方法に切り替える。起動確認ができた場合は）、続いて決済確認用のデータを暗号化して送信する(ステップ：Ｓ２２)。送信するデータは、利用日時、利用店舗、購入金額、購入商品名などの顧客がカードの利用状況を特定するのに可能なだけの決済情報である。

Ｊａｖａアプリケーションはこれらのデータを受信すると、着信音やバイブレーションによって顧客に通知するとともに、図８に示すような決済情報を画面表示する(ステップ：Ｓ２３)。画面には利用情報と、「承認する」および「承認しない」の選択ボタンが表示される。本例では、誤操作による承認を防ぐために、初期状態として「承認しない」が選択された状態となっている。顧客は、利用情報を確認して、承認するか否かを判断し、対応するボタンを選択して携帯電話の決定ボタンなどによって決定操作する(ステップ：Ｓ２４)。Ｊａｖａアプリケーションは、顧客の選択したボタンに従ってセキュリティ管理部２０に承認／非承認のデータを送信する(ステップ：Ｓ２５)。なお、顧客の操作がなされずタイムアウトが発生した場合、非承認として扱う。タイムアウト時間は、たとえば１分間といったように、顧客が情報を確認するのに充分な時間であるとともに、タイムアウトが発生しても店舗の業務には差し支えない程度の時間が選択される。タイムアウトとなった場合、Ｊａｖａアプリケーションは前記データとともにカード利用の通知があった旨を画面に表示する。このようにすれば、Ｊａｖａアプリケーションを利用することにより、クレジットカードの利用情報の確認、承認の操作が可能となる。

＜電子メールとＷｅｂページを用いる場合＞
上記Ｊａｖａアプリケーションを用いた場合は、Ｊａｖａアプリケーションに対応していない場合とか、パケット通信ができない端末などでは対応できなかった。そのような端末では、電子メールとＷｅｂアクセスによって同様な処理を実現することができる。図９は、そうした場合の動作フローである。まず、セキュリティ管理部２０はＷｅｂサーバ４３に対してユーザが認証を行うためのＷｅｂページを生成する(ステップ：Ｓ３０)。このＷｅｂページは、今回の承認専用に生成されるものであり、承認操作が終了した後は削除される。また、ＷｅｂページへのアクセスはＳＳLなどによって暗号化される。セキュリティ管理部２０はＷｅｂサーバ４３のＵＲＬを埋め込んだメールを顧客の携帯端末のメールアドレスに送信する(ステップ：Ｓ３１)。顧客はメール着信があったことを着信音やバイブレーションによって知り、メールを表示する(ステップ：Ｓ３２)。顧客は、メールに埋め込まれているＵＲＬを選択してＷｅｂアクセスを行い(ステップ：Ｓ３３)、図７(b)に示すようなＷｅｂページを表示する(ステップ：Ｓ３４)。顧客は利用情報を確認し、Ｊａｖａアプリケーションを用いた場合と同様にして承認するか、しないかを決定する(ステップ：Ｓ３５)。なお、承認の際のパスワードを入力させるようにしてもよい。そのようにすれば、仮にキャッシュカードと携帯電話の両方が盗難された場合でも、不正使用を防ぐことができる。承認／非承認の選択がなされると、Ｗｅｂサーバ４３は、セキュリティ管理部２０に承認／非承認のいずれかのデータを送信する(ステップ：Ｓ３６)。また、顧客の操作がなされずにタイムアウトが発生した場合は非承認として取り扱う。タイムアウト時間は、たとえば１分間といったように、顧客が情報を確認するのに充分な時間であるとともに、タイムアウトが発生してもテンポの業務には差し支えない程度の時間が選択される。セキュリティ管理部２０はＷｅｂサーバ４３から承認か非承認のデータを受信すると、承認用Ｗｅｂサーバを削除する(ステップ：Ｓ３７)。また、メールには前記利用情報を含めてもよい。この場合、顧客はＷｅｂページにアクセスする前に利用内容を知ることができるので、不審な利用情報があれば無視することができるので、無駄な通信費用を支払わずに済む。また、承認用Ｗｅｂサーバが削除された後にも受信メールを確認することにより、利用情報を確認することができる。

図１０（a）,(b)は、メール画面およびＷｅｂ画面を示す表示例であり、画面上に他にも「口座の一次停止」のボタンを設けてもよい。その場合「口座の一時停止」が選択されるとセキュリティ管理部２０には、「口座の一時停止」のデータが送信される。セキュリティ管理部２０はその通知を受け取ると、決済管理センター１０に対して決済可否確認結果としてエラーを通知するとともに、決済管理センター１０に対して該口座の一時停止が指示された旨を通知する。決済管理センター１０は、店舗の決済端末に対してエラーを通知するとともに、それ以降当該口座の一時停止の状態に置く。これにより、以降、同じくクレジットカードが使用された場合は即エラーにできるようになるので、カードが明らかに盗難されたと判断されるような場合に、カードの停止を電話などで行う手間が省ける。このようにすれば、Ｊａｖａアプリケーションを利用できない携帯電話であっても、クレジットカードの利用情報の確認や承認の操作が可能となる。

＜Ｊａｖａアプリケーションと電子メールとＷｅｂページを併用する場合＞
上記のＪａｖａアプリケーションを用いた場合、電子メールとＷｅｂページを用いた場合を組み合わせて、Ｊａｖａアプリケーションを使用しつつ、Ｊａｖａアプリケーションに対応していない端末でも対応できる。図１１は、そうした場合の動作フロー図であり、まずセキュリティ管理部２０はＷｅｂサーバ４３対してユーザが認証を行うためのＷｅｂページを生成する(ステップ：Ｓ４０)。このＷｅｂページは、今回の承認専用に生成されるものであり、承認操作が終了した後は削除される。また、ＷｅｂページアクセスはＳＳLなどによって暗号化される。セキュリティ管理部２０は、Ｗｅｂサーバ４３のＵＲＬを埋め込んだメールを顧客の携帯端末のメールアドレスに送信する(ステップ：Ｓ４１)。セキュリティ管理部２０は、送信したメールの内容（送信先メールアドレス、埋め込んだＵＲＬなど）の情報を送信履歴として保存しておくものとする。また、携帯電話ではＪａｖａアプリケーションが動作しているものとする。Ｊａｖａアプリケーションを用いた場合と同様に、携帯電話の場合は待ち受けAPとして動作させることが望ましい。Ｊａｖａアプリケーションは、電子メールの着信があったときその情報を取得するように動作しており、着信を知ることができる(ステップ：Ｓ４２)。Ｊａｖａアプリケーションは電子メールの着信を検知すると、電子メールの内容のチェックを行う(ステップ：Ｓ４３)。チェックする内容とは、電子メールの送信元メールアドレス、送信元メールサーバのアドレス、タイトルなどである。着信した電子メールがセキュリティ管理部２０からのものであることを確認すると、ＪａｖａアプリケーションはメールからＵＲＬを取り出す(ステップ：Ｓ４４)。着信した電子メールがセキュリティ管理部２０からのものでなければ、Ｊａｖａアプリケーションは何も行わないので、顧客は通常のメールとして受け取ることができる。

Ｊａｖａアプリケーションは、ＵＲＬの真贋を確認するために、セキュリティ管理部２０に対してＵＲＬ、自メールアドレス、送信元メールアドレス、送信元メールサーバアドレスなどを暗号化して送信する(ステップ：Ｓ４５)。セキュリティサーバは受信したＵＲＬとメールアドレスをチェックし、送信履歴と一致しておればチェックをOKとして、不一致であればチェックNGとしてＪａｖａアプリケーションに結果を送信する(ステップ：Ｓ４６)。セキュリティ管理部２０のチェックがOKの場合、Ｊａｖａアプリケーションは着信音やバイブレーションによって顧客に通知するとともに、取得したＵＲＬをブラウザなどを用いて表示させる(ステップ：Ｓ４７)。以後、ステップＳ４８〜ステップＳ５１までの操作は上記電子メールとＷｅｂページを用いた場合と同様である。なお、前述の利用情報はメールに含めてもよい。この場合、顧客はＷｅｂページにアクセスする前に利用内容を知ることができるので、不審な利用情報であればそれを無視することができ、無駄な通信費用を支払わずに済む。また、承認用Ｗｅｂサーバが削除された後にも受信メールを確認することにより、利用情報を確認することができる。

このようにＪａｖａアプリケーションが起動していた場合は、セキュリティ管理部２０からのメール受信を自動的に検出して、ＵＲＬの確認を行うのでセキュリティの高い承認操作を行えるが、仮にＪａｖａアプリケーションが起動しておらず、Ｊａｖａアプリケーションが使用できない携帯電話であった場合でも、通常のメールとして取り扱われるので、Ｗｅｂアクセス機能を有してさえおれば上記電子メールとＷｅｂページを用いた場合と同様な処理が可能となる。また、セキュリティ管理部２０やＷｅｂサーバ４３の成りすましによってパスワードを盗まれることを防止するため、パスワード入力は携帯電話のパスワード機能を利用することとしてもよい。この場合、ＪａｖａアプリケーションやＷｅｂサーバ４３にはパスワード認証結果のみが通知されるので、パスワードを盗まれることはない。また、Ｊａｖａアプリケーションの管理者にメールの送信元アドレスなどの情報を通知することにしてもよい。特に、本例ではＪａｖａアプリケーションやセキュリティ管理部２０でもチェックによってエラーが発生した場合、Ｊａｖａアプリケーションはメールヘッダをセキュリティ管理部２０に送信して解析を助成するようにしてもよい。

＜実施例２の効果＞
以上説明したように、この実施例２によれば、顧客自身がカードを使用する場合は、自身の携帯端末に承認画面が現れるので、自身の携帯端末を準備しておけば、即座に承認を行うことができる。また、カードやクレジット番号が不正使用された場合でも、携帯電話に通知され、利用内容を確認して承認が行えるので、顧客にも、店舗にも、またクレジット会社にも損害が発生しない。また、前述のようにＪａｖａアプリケーション、電子メールおよびＷｅｂページを用いた場合の例では、セキュリティ管理部２０は顧客がＪａｖａアプリケーションを起動しているか、もしくはＪａｖａアプリケーションを利用できる環境であるかを意識せずとも通知できるので、処理を簡単にでき、コストを削減できる。また、ユーザはＪａｖａアプリケーションを常駐させていなくても承認機能を利用できるので、使い勝手の自由度が増大する。

本発明によるカード不正使用防止システムの実施例１の構成を示す機能ブロック図。 実施例１の動作フローチャート。 実施例２の決済管理センターの構成を示す機能ブロック図。 実施例２のセキュリティ管理部の構成を示す機能ブロック図。 実施例２の携帯端末の構成を示す機能ブロック図。 実施例２の全体動作フローチャート。 実施例２のＪａｖａアプリケーションを用いた場合の動作フローチャート。 実施例２の決済情報の画面表示例。 実施例２の電子メールとＷｅｂページを用いた場合の動作フローチャート。 同図（ａ），（ｂ）は実施例２のメール画面とＷｅｂ画面の表示例。 実施例２のＪａｖａアプリケーション、電子メールおよびＷｅｂページを用いた場合の動作フローチャート。

符号の説明

１ 小売店舗
２ カード決済端末装置
３ 顧客
４ メール受信端末機
５，６ ネットワーク
１０ 決済管理センター
１１ 顧客管理モジュール
１２ 顧客情報データベース
１３ 残高管理モジュール
１４ 残高データベース
１５ データ送受信部
１６ 決済可否確認手段
２０ セキュリティ管理部
２１ メールサーバ
２２ メールアドレスデータベース
２３ メール送受信部
３０ 携帯端末
３２ 承認手段
４２ 承認サーバ
４３ Ｗｅｂサーバ

Claims (9)

1. クレジットカードおよびキャッシュカードを含む与信取引カードを利用した決済情報を予め登録した連絡先に対して、当該カードが利用されたことを認識させるのに必要な情報とともに通知するようにしたことを特徴とするカード不正使用防止システム。
2. クレジットカードおよびキャッシュカードを含む与信取引カードを利用した決済情報を予め登録した連絡先に対して、当該カードが利用されたことを認識させるのに必要な情報とともに通知して承認させるようにしたことを特徴とするカード不正使用防止システム。
3. 前記連絡先からカード口座の一時停止を指示できるようにしたことを特徴とする請求項１または２に記載のカード不正使用防止システム。
4. 前記連絡先が当該カードの名義人所有の携帯端末である場合に、前記通知をその携帯端末で動作するプログラムに対して行うようにしたことを特徴とする請求項１または２に記載のカード不正使用防止システム。
5. 前記プログラムは、承認を依頼する情報の受取手段と、承認依頼情報に基づいて承認を要求する画面を表示する表示手段と、承認または非承認かの情報を選択して連絡する送信手段と、を有することを特徴とする請求項４に記載のカード不正使用防止システム。
6. 前記携帯端末への送信が電子メールである場合に、その電子メールは予め今回の取引専用に作成されたＷｅｂページへのリンクを含み、Ｗｅｂページには利用内容を承認するのに必要な情報とともに承認／非承認を前記カード名義人による操作で選択可能となっている請求項３，４または５のいずれかに記載のカード不正使用防止システム。
7. 前記携帯端末で動作するプログラムは、電子メールの受信を検出することによってその電子メールが当該カード利用に関する承認依頼のものか否かを確認して、リンクされているＷｅｂページを自動的に表示するようにしたことを特徴とする請求項６に記載のカード不正使用防止システム。
8. 前記Ｗｅｂページには口座の停止を前記カード名義人の操作で選択可能となっていることを特徴とする請求項７に記載のカード不正使用防止システム。
9. 電子メールにもまたカード利用内容を認識させるのに必要な情報が含まれていることを特徴とする請求項６，７または８のいずれかに記載のカード不正使用防止システム。
   

Images