JP2020102070A - カード取引システム - Google Patents

Abstract

【課題】クレジットカードのオーソリ処理によるシステムの負荷を軽減させることができるカード取引システムを提供する。【解決手段】カード取引システム１は、クレジットカードのオーソリ処理を構成する複数の処理のうちのどの処理を実行するかを定めた動作内容情報を格納するアクションＤＢ１１を有している。そして、加盟店サーバ２又は加盟店端末３からクレジットカードの利用要求を受け付けた場合、カード取引システム１は、アクションＤＢ１１に格納されている動作内容情報に基づいて、オーソリ処理において実行すべき処理を特定し、特定した処理を実行することによって取引の可否を判定する。【選択図】図１

Description

本発明は、システムの負荷を軽減することができるカード取引システムに関する。

取引に利用可能なクレジットカードのカード番号を不正に取得する手法の１つとして、クレジットマスターが知られている（非特許文献１を参照）。クレジットマスターは、自動で生成された複数のカード番号を用いてインターネット上のショッピングサイトでの取引を繰り返し試みることによって、取引に利用可能なカード番号を割り出す手法である。クレジットマスターが行われると、大量のオーソリ処理（与信照会処理）が発生することになるため、オーソリシステムの負荷が大きくなるという問題が生じる。

上記のようなクレジットマスターへの対策として、クレジットマスターが行われていることを検知した場合に、特定のカード番号帯のクレジットカードでの取引を一律不可にすることによって、システムの負荷を軽減する手法が従来知られている。

ウィキペディア フリー百科事典、" クレジットマスター"、［２０１８年１０月３０日検索］、インターネット（https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AC%E3%82%B8%E3%83%83%E3%83%88%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC）

しかしながら、上記のように特定のカード番号帯のクレジットカードでの取引を一律不可にした場合、そのカード番号帯に属するクレジットカードはすべて利用できなくなってしまうため、真正利用を阻害するという問題が生じる。

本発明は斯かる事情に鑑みてなされたものであり、その主たる目的は、取引を一律不可にすることなく、オーソリ処理によるシステムの負荷の増大を抑制することができるクレジットカード取引システムを提供することにある。

上述した課題を解決するために、本発明の一の態様のカード取引システムは、クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、前記オーソリ処理は、複数の処理で構成されており、クレジットカード及び／又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、特定した処理を実行することによって取引の可否を判定する判定手段とを備えることを特徴とする。

前記態様において、前記動作内容情報には、所定のカード番号帯毎に、前記複数の処理のうちのどの処理を実行するのかが定められていてもよい。

前記態様において、前記動作内容情報には、クレジットカードの加盟店毎に、前記複数の処理のうちのどの処理を実行するのかが定められていてもよい。

また、前記態様において、前記オーソリ処理は、クレジットカードの有効期限の確認を含む第１処理、クレジットカードの利用実績に基づいて不正の判定を行う第２処理、及び、カード会員の本人確認情報に基づいて不正の判定を行う第３処理を含んでおり、前記動作内容情報には、前記第１乃至第３処理のうちのどの処理を実行するのかが定められていてもよい。

また、前記態様において、前記取引の可否の判定結果に基づいて、前記動作内容情報の内容を更新する更新手段をさらに備えてもよい。

また、前記態様において、前記判定手段は、取引が不可であると判定した場合に、悪用の疑いがあるか否かをさらに判定し、前記更新手段は、前記悪用の疑いがあるか否かの判定結果に基づいて、前記動作内容情報の内容を更新するようにしてもよい。

また、前記態様において、前記更新手段は、所定の期間において前記判定手段によって取引が不可であると判定された件数に基づいて、前記動作内容情報の内容を更新するようにしてもよい。

また、前記態様において、前記更新手段は、前記オーソリ処理の所要時間に基づいて、前記動作内容情報の内容を更新するようにしてもよい。

また、前記態様において、前記更新手段は、所定の期間において前記判定手段によって取引の可否が判定された件数と、当該期間における前記所要時間とに基づいて、前記動作内容情報の内容を更新するようにしてもよい。

本発明によれば、安全性を担保した上で、オーソリ処理によるシステムの負荷の増大を抑制することが可能になる。

本発明の実施の形態に係るカード取引システム及びその通信先の構成を示すブロック図。 カード取引システムが有するアクションデータベースのレイアウトの一例を示す図。 カード取引システムが有する処理結果データベースのレイアウトの一例を示す図。 オーソリ処理の手順を示すフローチャート。 オーソリ処理の手順を示すフローチャート。 オーソリ処理の手順を示すフローチャート。 アクションＤＢ更新処理の手順を示すフローチャート。 アクションＤＢ更新処理の手順を示すフローチャート。 カード取引システムが有するアクションデータベースのレイアウトの他の例を示す図。 カード取引システムが有するアクションデータベースのレイアウトの他の例を示す図。 アクションＤＢ更新処理の手順を示すフローチャート。

以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。なお、以下に示す各実施の形態は、本発明の技術的思想を具体化するための方法及び装置を例示するものであって、本発明の技術的思想は下記のものに限定されるわけではない。本発明の技術的思想は、特許請求の範囲に記載された技術的範囲内において種々の変更を加えることができる。

［カード取引システムの構成］
図１は、実施の形態に係るカード取引システム及びその通信先の構成を示すブロック図である。図１に示すように、本実施の形態のカード取引システム１は、インターネットを含む通信ネットワーク１０１と通信可能に接続されている。この通信ネットワーク１０１には、複数の加盟店サーバ２，２，…及び複数の加盟店端末３，３，…が通信可能に接続されており、カード取引システム１は、通信ネットワーク１０１を介して、これらの加盟店サーバ２，２，…及び複数の加盟店端末３，３，…との間で各種のデータの送受信を行う。

カード取引システム１は、ＣＰＵ、主記憶装置、補助記憶装置、入出力インタフェース、及び通信インタフェース等を含むコンピュータシステムである。ＣＰＵは、補助記憶装置から主記憶装置にロードされた各種のコンピュータプログラムを実行する。これにより、後述する各情報処理が実現される。また、通信インタフェースは、通信ネットワーク１０１と接続するためのインタフェースである。

なお、カード取引システム１は、１台のコンピュータによって構成されていてもよく、複数のコンピュータによる分散システムによって構成されていてもよい。

図１に示すとおり、カード取引システム１の補助記憶装置には、アクションデータベース（ＤＢ）１１、処理結果データベース（ＤＢ）１２、通常ログデータベース（ＤＢ）１３、第１ログデータベース（ＤＢ）１４、第２ログデータベース（ＤＢ）１５、及び第３ログデータベース（ＤＢ）１６の各データベースが設けられている。これらのデータベースの詳細については後述する。

なお、本実施の形態では、上記の各データベースがカード取引システム１の内部に設けられているが、カード取引システム１がアクセス可能であれば、外部の他の装置に設けられていてもよい。

加盟店サーバ２は、クレジットカードの加盟店のオンラインショップを運営するサーバである。また、加盟店端末３は、加盟店に設置されたＣＡＴ（Credit Authorization Terminal）等の端末である。

図１に示すとおり、通信ネットワーク１０１には、複数の利用者端末４，４，…が通信可能に接続されている。利用者端末４が、通信ネットワーク１０１を介して各加盟店サーバ２にアクセスすることにより、オンラインショッピングが実現される。なお、利用者端末４は、例えば、パーソナルコンピュータ、スマートフォン等の携帯電話機又はタブレット端末等で構成される。

以下、上述した各データベースの詳細について説明する。
（１）アクションＤＢ１１
アクションＤＢ１１は、クレジットカードのオーソリ処理を実行する場合に、オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を格納するデータベースである。本実施の形態では、カード番号帯毎に動作内容が規定されている。

図２は、アクションＤＢ１１のレイアウトの一例を示す図である。図２に示すように、アクションＤＢ１１では、各カード番号帯の開始番号及び終了番号が定められるとともに、それらのカード番号帯に対してオーソリ処理の際に実行される動作内容が規定されている。

オーソリ処理の際の動作内容を規定する情報として、アクションＤＢ１１には、“通常”、“第１ログ”、“第１拡張”、“第２ログ”、“第２拡張”、及び“第３ログ”の各情報が格納されている。このうち、“通常”は、クレジットカードの有効期限及びセキュリティコードの確認など、オーソリ処理において通常行われる処理（以下「通常処理」という）を実行するか、それとも通常処理を行わずに取引を許可又は拒否するかを示す情報である。なお、通常処理のログのうち、処理日時などの基本的な内容については、通常ログＤＢ１３に書き込まれる。

また、“第１ログ”は、通常処理を実行する場合に、通常ログＤＢ１３へのログの書き込みに加えて、より詳細な内容のログを第１ログＤＢ１４へ書き込むか否かを示す情報である。

また、“第１拡張”は、クレジットカードの利用実績に基づいて不正の有無を判定する第１拡張処理を実行するか否かを示す情報である。第１拡張処理には、例えば、利用金額等が通常の利用時と大きく異なる場合に不正と判定したり、特定の地点でクレジットカードが利用された直後に当該地点から大きく距離が離れている地点で同一のクレジットカードが利用される場合に不正と判定したりする処理などが含まれる。

また、“第２ログ”は、第１拡張処理のログを第２ログＤＢ１５に書き込むか否かを示す情報である。

また、“第２拡張”は、クレジットカードのカード会員に本人確認情報の提示を追加で求め、カード会員から提示された情報に基づいて不正の有無を判定する第２拡張処理を実行するか否かを示す情報である。第２拡張処理には、カード会員の生体情報（指紋情報、静脈情報、顔情報、虹彩情報、及び声音情報など）、生年月日、干支、星座、自宅郵便番号、自宅住所、及び登録電話番号などの本人確認情報を追加で求める処理、並びに、その回答内容に基づいて不正の有無を判定する処理が含まれる。

なお、後述するように、アクションＤＢ更新処理において“第２拡張”を自動更新してもよく、例えば下記のようなカード会員については手動で設定してもよい。
（ａ）特定の加盟店で店員によるスキミングの発生が懸念されるような事象が確認された場合において、その加盟店での利用実績があるカード会員
（ｂ）特定の会員番号帯の取引で不正利用と思われるＮＧが増えているがすべてをＮＧにするほどではない場合において、その会員番号帯に含まれるカード会員

また、第２拡張処理は、店舗内の設備で取得可能な本人確認情報を確認した上で、その取得可能な本人確認情報の提示を求めるようにしてもよく、通常処理及び／又は第１拡張処理の結果に基づいて確認が必要な本人確認情報を特定した上で、その本人確認情報の提示を求めるようにしてもよい。

また、“第３ログ”は、第２拡張処理のログを第３ログＤＢ１６に書き込むか否かを示す情報である。

上述した通常処理、第１拡張処理、第２拡張処理、及び第１ログＤＢ１４乃至第３ログＤＢ１６への書き込み処理のそれぞれは、オーソリ処理を構成する処理に相当する。本実施の形態では、アクションＤＢ１１を参照することによって、取引毎に、オーソリ処理を構成するこれらの処理のうちのどの処理を実行するのかを特定し、その特定した処理を実行することによって、取引の可否の判定が行われる。

（２）処理結果ＤＢ１２
処理結果ＤＢ１２は、上記のアクションＤＢ１１に基づいてオーソリ処理が実行された場合の処理結果を示す処理結果情報を格納するデータベースである。

図３は、処理結果ＤＢ１２のレイアウトの一例を示す図である。図３に示すように、処理結果ＤＢ１２には、“処理日時”、“オーソリ結果”、“カード番号”、“加盟店番号”、“加盟店端末”、“処理所要時間”、及び“利用者端末”の各情報が格納されている。このうち、“処理日時”は、オーソリ処理の実行が開始された日時を示す情報である。

また、“オーソリ結果”は、取引の可否の判定結果を示す情報である。本実施の形態の場合、ＯＫ、ＮＧ１、及びＮＧ２の３種類のオーソリ結果が用いられる。ここで、ＯＫは取引が可であることを、ＮＧ１は取引が不可であって且つ悪用の疑いがないことを、ＮＧ２は取引が不可であって且つ悪用の疑いがあることを、それぞれ示している。悪用の疑いの有無については、例えば、限度額超過などによって取引が不可であると判定された場合は悪用の疑いはないと判断され、セキュリティコードの誤りなどによって取引が不可であると判定された場合は悪用の疑いがあると判断される。

また、“カード番号”は取引に利用されたクレジットカードの番号であり、“加盟店番号”は利用された加盟店を識別する加盟店番号である。

また、“加盟店端末”は、加盟店の店舗に設置された加盟店端末３を識別する加盟店端末番号である。利用者がクレジットカードを実店舗において利用する場合、その実店舗に設置されている加盟店端末３によってオーソリ処理の要求が行われる。このとき、その加盟店端末３の加盟店端末番号がカード取引システム１に送信され、その後処理結果ＤＢ１２に格納される。

また、“処理所要時間”は、オーソリ処理の実行に要した時間（レスポンスタイム）である。オーソリ処理を構成する各処理のうち、実行される処理の数が多いほど、処理所要時間が長くなる傾向にある。

また、“利用者端末”は、加盟店のオンラインショップにて利用者がクレジットカードを利用する場合に用いられた利用者端末４を識別するための情報である。例えば、携帯電話のＩＭＥＩ（International Mobile Equipment Identity）などが“利用者端末”として用いられる。

（３）ログＤＢ１３〜１６
上述したとおり、通常ログＤＢ１３及び第１ログＤＢ１４は通常処理のログを、第２ログＤＢ１５は第１拡張処理のログを、第３ログＤＢ１６は第２拡張処理のログをそれぞれ格納するデータベースである。取引の検証を行うためにはログが残されていることが好ましいが、ログの書き込みが多く行われるとシステムの負荷が増大することになる。したがって、ログを残す必要性が高い取引についてログの書き込みを行い、それ以外の取引についてはログの書き込みを行わないようにすることが望ましく、アクションＤＢ１１ではそのような設定がなされる。

［カード取引システムの動作］
次に、上述したように構成された本実施の形態のカード取引システムの動作について、フローチャート等を参照しながら説明する。以下では、（１）クレジットカードでの取引の可否を判定するオーソリ処理、及び（２）オーソリ処理の結果に基づいてアクションＤＢ１１の内容を更新するアクションＤＢ更新処理の各処理について説明する。

（１）オーソリ処理
利用者は、オンラインショップ又は実店舗にてクレジットカードを利用した取引を行う。オンラインショップで取引を行う場合、利用者は利用者端末４を用いて加盟店サーバ２にアクセスし、カード番号及び有効期限などのカード情報を加盟店サーバ２に対して入力する。また、実店舗で取引を行う場合では、利用者のクレジットカードのカード情報を加盟店端末３が読み取る。このようにしてカード情報を取得した加盟店サーバ２又は加盟店端末３は、そのカード情報を含むオーソリ要求をカード取引システム１に対して送信する。その後、カード取引システム１によって下記のオーソリ処理が実行される。

図４Ａ乃至図４Ｃは、カード取引システム１によって実行されるオーソリ処理の手順を示すフローチャートである。図４Ａに示すとおり、カード取引システム１はまず、上述したようにして加盟店サーバ２又は加盟店端末３から送信されたオーソリ要求を受信する（Ｓ１０１）。なお、このオーソリ要求には、カード情報の他、処理結果情報における“加盟店番号”、及び、“加盟店端末”又は“利用者端末”に相当する情報が含まれている。

次に、カード取引システム１は、アクションＤＢ１１を参照し（Ｓ１０２）、受信したオーソリ要求に含まれるカード番号が属するカード番号帯に係る動作内容情報を取得する。これにより、オーソリ処理を構成する各処理のうちどの処理を実行すべきかを判定することが可能になる。

カード取引システム１はまず、取得した動作内容情報における“通常”に基づいて、通常処理を実行するか、それとも通常処理を行わずに取引を許可又は拒否するかを判定する（Ｓ１０３）。ここで通常処理を実行しないと判定した場合（Ｓ１０３でＮＯ）、図４Ｂに進み、カード取引システム１は、取引を許可するか否かを判定する（Ｓ１０４）。

ステップＳ１０４において、取引を許可しないと判定した場合（Ｓ１０４でＮＯ）、カード取引システム１は、取引の拒否を示す拒否情報を加盟店サーバ２又は加盟店端末３に対して送信する（Ｓ１０５）。他方、取引を許可すると判定した場合（Ｓ１０４でＹＥＳ）、カード取引システム１は、取引の許可を示す許可情報を加盟店サーバ２又は加盟店端末３に対して送信する（Ｓ１０６）。

その後、カード取引システム１は、取引拒否又は許可を示す情報を含む処理結果情報を処理結果ＤＢ１２に登録する（Ｓ１０７）。なお、本実施の形態では、取引拒否の場合は処理結果情報における“オーソリ結果”をＮＧ２とし、取引許可の場合はＯＫとする。

ステップＳ１０３に戻り、通常処理を実行すると判定した場合（Ｓ１０３でＹＥＳ）、カード取引システム１は、所定の通常処理を実行し（Ｓ１０８）、そのログを通常ログＤＢ１３に書き込む（Ｓ１０９）。

次に、カード取引システム１は、動作内容情報における“第１ログ”に基づいて、第１ログＤＢ１４への書き込みを実行するか否かを判定する（Ｓ１１０）。第１ログＤＢ１４への書き込みを実行すると判定した場合（Ｓ１１０でＹＥＳ）、カード取引システム１は、通常処理の詳細なログを第１ログＤＢ１４に書き込む（Ｓ１１１）。他方、第１ログＤＢ１４への書き込みを実行しないと判定した場合（Ｓ１１０でＮＯ）は、ステップＳ１１１を経ずに次のステップＳ１１２へ進む。

次に、カード取引システム１は、動作内容情報における“第１拡張”に基づいて、第１拡張処理を実行するか否かを判定する（Ｓ１１２）。第１拡張処理を実行すると判定した場合（Ｓ１１２でＹＥＳ）、カード取引システム１は、所定の第１拡張処理を実行する（Ｓ１１３）。他方、第１拡張処理を実行しないと判定した場合（Ｓ１１２でＮＯ）は、ステップＳ１１３を経ずに次のステップＳ１１４へ進む。

次に、カード取引システム１は、動作内容情報における“第２ログ”に基づいて、第２ログＤＢ１５への書き込みを実行するか否かを判定する（Ｓ１１４）。第２ログＤＢ１５への書き込みを実行すると判定した場合（Ｓ１１４でＹＥＳ）、カード取引システム１は、第１拡張処理のログを第２ログＤＢ１５に書き込む（Ｓ１１５）。他方、第２ログＤＢ１５への書き込みを実行しないと判定した場合（Ｓ１１４でＮＯ）は、ステップＳ１１５を経ずに次のステップＳ１１６へ進む。

図４Ｃに進み、カード取引システム１は、動作内容情報における“第２拡張”に基づいて、第２拡張処理を実行するか否かを判定する（Ｓ１１６）。第２拡張処理を実行すると判定した場合（Ｓ１１６でＹＥＳ）、カード取引システム１は、所定の第２拡張処理を実行する（Ｓ１１７）。なお、この第２拡張処理において利用者の生体情報が必要になる場合、カード取引システム１は、加盟店サーバ２又は加盟店端末３などを介して生体情報を取得した上で、第２拡張処理を実行する。他方、第２拡張処理を実行しないと判定した場合（Ｓ１１６でＮＯ）は、ステップＳ１１７を経ずに次のステップＳ１１８へ進む。

次に、カード取引システム１は、動作内容情報における“第３ログ”に基づいて、第３ログＤＢ１６への書き込みを実行するか否かを判定する（Ｓ１１８）。第３ログＤＢ１６への書き込みを実行すると判定した場合（Ｓ１１８でＹＥＳ）、カード取引システム１は、第２拡張処理のログを第３ログＤＢ１６に書き込む（Ｓ１１９）。他方、第３ログＤＢ１６への書き込みを実行しないと判定した場合（Ｓ１１８でＮＯ）は、ステップＳ１１９を経ずに次のステップＳ１２０へ進む。

次に、カード取引システム１は、通常処理、第１拡張処理、及び第２拡張処理の結果に基づいて、当該クレジットカードでの取引の可否を判定する（Ｓ１２０）。なお、第１拡張処理及び第２拡張処理のうち実行されていない処理がある場合、その処理は判定の基礎とはならず、実行された処理の結果のみに基づいて取引の可否の判定が行われる。

ステップＳ１２０において取引は不可であると判定された場合（Ｓ１２０でＮＯ）、カード取引システム１は、取引が不可であることを示す取引不可情報を加盟店サーバ２又は加盟店端末３に対して送信する（Ｓ１２１）。他方、取引は可であると判定された場合（Ｓ１２０でＹＥＳ）、カード取引システム１は、取引が可であることを示す取引可情報を加盟店サーバ２又は加盟店端末３に対して送信する（Ｓ１２２）。

その後、カード取引システム１は、取引可又は不可を示す情報を含む処理結果情報を処理結果ＤＢ１２に登録する（Ｓ１２３）。ここで、取引可の場合は“オーソリ結果”をＯＫとし、取引不可の場合は“オーソリ結果”をＮＧ１又はＮＧ２とする。また、“処理所要時間”は、ステップＳ１０２からＳ１２０までに要した時間とする。

上述したとおり、本実施の形態では、カード番号帯によってオーソリ処理の動作内容が異なっている。例えば、不正取引の可能性が高いカード番号帯については第１拡張処理及び／又は第２拡張処理を行う一方、不正取引の可能性が低いカード番号については通常処理のみを行うなどの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。

（２）アクションＤＢ更新処理
アクションＤＢ更新処理では、上記のオーソリ処理の結果に基づき、アクションＤＢ１１の内容を更新する。例えば、オーソリ処理の結果を用いて不正取引の可能性が高いカード番号帯を特定し、そのカード番号帯についてはそれ以降より厳格なオーソリ処理を行うようにすることなどが想定される。なお、このアクションＤＢ更新処理は、所定の時間間隔で繰り返し実行される。以下、アクションＤＢ更新処理の具体例について説明する。

図５は、カード取引システム１が実行するアクションＤＢ更新処理の一例を示すフローチャートである。図５に示すとおり、カード取引システム１はまず、所定数（例えば直近１万件）の処理結果情報を処理結果ＤＢ１２から抽出し（Ｓ２０１）、カード番号帯毎に各種情報を集計する（Ｓ２０２）。

次に、カード取引システム１は、集計した結果を用いて、“オーソリ結果”がＮＧ２である件数の割合を算出し、その値と所定の第１閾値及び第２閾値とを比較する。ここで、第１閾値は、第２閾値よりも大きい値である。例えば、第１閾値及び第２閾値をそれぞれ８０％及び１０％などに設定することが想定される。

カード取引システム１はまず、ＮＧ１の件数の割合が第１閾値以上であるか否かを判定する（Ｓ２０３）。ここで、第１閾値以上であると判定された場合（Ｓ２０３でＹＥＳ）、悪用の疑いがある取引不可の件数が多いことになるため、カード取引システム１は、当該カード番号帯の取引について、通常処理を行うことなく一律拒否となるように、動作内容情報における“通常”を更新する（Ｓ２０４）。これにより、それ以降、当該カード番号帯については取引が一律拒否されることになる。

他方、ステップＳ２０３にて第１閾値以上ではないと判定された場合（Ｓ２０３でＮＯ）、カード取引システム１は、ＮＧ２の件数の割合が第２閾値以上であるか否かを判定する（Ｓ２０５）。ここで、第２閾値以上であると判定された場合（Ｓ２０５でＹＥＳ）、悪用の疑いがある取引不可の件数が一定数あることになるため、カード取引システム１は、当該カード番号帯の取引について第１拡張処理及び／又は第２拡張処理を実行するように、動作内容情報における“第１拡張”及び“第２拡張”を更新する（Ｓ２０６）。これにより、それ以降、当該カード番号帯についてはより厳しい基準で取引の可否の判定が行われることになる。なお、当該カード番号帯について既に各拡張処理を実施するように設定されている場合はそのままの設定が維持される。

また、ステップＳ２０５にて第２閾値以上ではないと判定された場合（Ｓ２０５でＮＯ）、悪用の疑いがある取引不可の件数が比較的少ないことになるため、カード取引システム１は、当該カード番号帯の取引について第１拡張処理及び／又は第２拡張処理を実行しないように、動作内容情報における“第１拡張”及び“第２拡張”を更新する（Ｓ２０７）。これにより、それ以降、当該カード番号帯についてはより緩やかな基準で取引の可否の判定が行われることになり、システムの負荷が軽減されることになる。なお、当該カード番号帯について既に各拡張処理を実施しないように設定されている場合はそのままの設定が維持される。

なお、上記では、ＮＧ２の件数の割合を基準にしているが、ＮＧ１又はＮＧ１とＮＧ２との合計の件数の割合を基準にしてもよい。また、件数の割合ではなく件数自体を基準にしてもよい。

図６は、カード取引システム１が実行するアクションＤＢ更新処理の他の例を示すフローチャートである。上述した場合と同様に、カード取引システム１はまず、所定数（例えば直近１万件）の処理結果情報を処理結果ＤＢ１２から抽出し（Ｓ３０１）、カード番号帯毎に各種情報を集計する（Ｓ３０２）。

次に、カード取引システム１は、集計した結果を用いて、取引が発生する頻度（以下「取引発生頻度」という）及び“処理所要時間”の平均を算出し、その取引発生頻度が所定の閾値以下であって、且つ平均処理所要時間が所定の閾値以上であるか否かを判定する（Ｓ３０３）。ここで、取引発生頻度は、毎秒何件の取引が発生しているのかを表す指標である。例えば８０秒間に１万件の取引が発生している場合であれば、取引発生頻度は１２５件／秒になる。取引発生頻度に対する閾値としては例えば２００秒／件などの値が、平均処理所要時間に対しては例えば１．５秒などの値が、それぞれ設定される。

ステップＳ３０３において、取引発生頻度が閾値以下及び平均処理所要時間が閾値以上の２つの条件を満足していると判定された場合（Ｓ３０３でＹＥＳ）、システムの負荷が比較的高いと判断することができるため、カード取引システム１は、当該カード番号帯の取引について第１拡張処理及び／又は第２拡張処理を実行しないように、動作内容情報における“第１拡張”及び“第２拡張”を更新する（Ｓ３０４）。これによって、システムの負荷の軽減を図ることができる。なお、当該カード番号帯について既に各拡張処理を実施しないように設定されている場合はそのままの設定が維持される。

他方、ステップＳ３０３において、上記２つの条件のうちの少なくとも１つが満足されないと判定された場合（Ｓ３０３でＮＯ）、システムの処理能力に余裕があると判断することができるため、カード取引システム１は、当該カード番号帯の取引について第１拡張処理及び／又は第２拡張処理を実行するように、動作内容情報における“第１拡張”及び“第２拡張”を更新する（Ｓ３０５）。これによって、当該カード番号帯に係る取引の安全性を強化することができる。なお、当該カード番号帯について既に各拡張処理を実施するように設定されている場合はそのままの設定が維持される。

なお、上記では、取引発生頻度及び平均処理所要時間の両方を基準にしているが、何れか一方のみを基準にするようにしてもよい。具体的には、平均処理所要時間が閾値以上である場合、オーソリ処理において実行する処理が少なくなるように、アクションＤＢ１１の内容を更新してもよい。また、取引発生頻度が閾値以下である場合、オーソリ処理において実行する処理が多くなるように、アクションＤＢ１１の内容を更新してもよい。

また、上述した２つのアクションＤＢ更新処理では、第１拡張処理及び第２拡張処理の実行の有無について設定変更を行っているが、それ以外の処理、すなわち第１ログ乃至第３ログ書き込み処理の実行の有無について同様に設定変更を行うようにしてもよい。

上記のアクションＤＢ更新処理を行うことによって、アクションＤＢ１１の内容を、取引の状況に応じた適切なものに自動的に設定することができる。すなわち、本実施の形態によれば、アクションＤＢ１１の自動メンテナンスを実現することができる。

（その他の実施の形態）
上記の実施の形態では、カード番号帯毎にオーソリ処理の動作内容が規定されているが、本発明はこれに限定されるわけではなく、個々のカード番号毎に規定されていてもよい。その他にも、例えば加盟店番号毎に、カード番号及び加盟店番号毎に、又はカード番号帯及び加盟店番号毎に、オーソリ処理の動作内容が規定されていても構わない。

図７は、加盟店番号毎にオーソリ処理の動作内容が規定されているアクションＤＢ１１のレイアウトの一例を示す図である。この場合、アクションＤＢ１１において、不正取引の可能性が高い加盟店の取引についてはより厳しい基準でオーソリ処理を行う（例えば、第１拡張処理及び／又は第２拡張処理を行うなど）一方、不正取引の可能性が低い加盟店の取引についてはより緩やかな基準でオーソリ処理を行う（例えば、通常処理のみを行うなど）などの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。

また、図８は、カード番号帯及び加盟店毎にオーソリ処理の動作内容が規定されているアクションＤＢ１１のレイアウトの一例を示す図である。この場合、アクションＤＢ１１において、不正取引の可能性が高いカード番号帯及び加盟店の組合せについてはより厳しい基準でオーソリ処理を行う一方、不正取引の可能性が低いカード番号帯及び加盟店の組合せについてはより緩やかな基準でオーソリ処理を行うなどの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。

なお、上記のように加盟店毎にオーソリ処理の動作内容を規定した場合、アクションＤＢ更新処理においても、各加盟店の事情を考慮した処理を行うことが可能になる。図９は、カード取引システム１が実行するアクションＤＢ更新処理の手順の変形例を示すフローチャートである。この例でも、カード取引システム１はまず、所定数（例えば直近１万件）の処理結果情報を処理結果ＤＢ１２から抽出し（Ｓ４０１）、カード番号帯毎に各種情報を集計する（Ｓ４０２）。

次に、カード取引システム１は、集計した結果を用いて、“オーソリ結果”がＮＧ１又はＮＧ２である件数の割合を算出し、その値が閾値以上（例えば８０％以上）であるか否かを判定する（Ｓ４０３）。ここで、閾値以上であると判定された場合（Ｓ４０３でＹＥＳ）、カード取引システム１は、ＮＧ１又はＮＧ２である取引の加盟店番号を特定することによって同一加盟店の件数の割合を算出し、その値が閾値以上（例えば５０％以上）であるか否かを判定する（Ｓ４０４）。

ステップＳ４０４において、同一加盟店の件数の割合が閾値以上であると判定された場合（Ｓ４０４でＹＥＳ）、当該加盟店について不正取引の可能性が高いことになるため、カード取引システム１は、当該加盟店の取引について、通常処理を行うことなく一律拒否となるように、動作内容情報における“通常”を更新する（Ｓ４０５）。その他にも、当該加盟店の取引について第１拡張処理及び／又は第２拡張処理を実行するように、動作内容情報における“第１拡張”及び“第２拡張”を更新することが想定される。

クレジットマスターの場合、特定の加盟店が狙われることがあるため、上記のように加盟店毎にオーソリ処理の動作内容を規定することは有効である。

１ カード取引システム
１１ アクションデータベース
１２ 処理結果データベース
１３ 通常ログデータベース
１４ 第１ログデータベース
１５ 第２ログデータベース
１６ 第３ログデータベース
２ 加盟店サーバ
３ 加盟店端末
４ 利用者端末
１０１ 通信ネットワーク

Claims (9)

1. クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、
   前記オーソリ処理は、複数の処理で構成されており、
   クレジットカード及び／又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、
   クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、
   特定した処理を実行することによって取引の可否を判定する判定手段と
   を備えることを特徴とする、カード取引システム。
2. 前記動作内容情報には、所定のカード番号帯毎に、前記複数の処理のうちのどの処理を実行するのかが定められている、
   請求項１に記載のカード取引システム。
3. 前記動作内容情報には、クレジットカードの加盟店毎に、前記複数の処理のうちのどの処理を実行するのかが定められている、
   請求項１又は２に記載のカード取引システム。
4. 前記オーソリ処理は、クレジットカードの有効期限の確認を含む第１処理、クレジットカードの利用実績に基づいて不正の判定を行う第２処理、及び、カード会員の本人確認情報に基づいて不正の判定を行う第３処理を含んでおり、
   前記動作内容情報には、前記第１乃至第３処理のうちのどの処理を実行するのかが定められている、
   請求項１乃至３の何れかに記載のカード取引システム。
5. 前記取引の可否の判定結果に基づいて、前記動作内容情報の内容を更新する更新手段
   をさらに備える、請求項１乃至４の何れかに記載のカード取引システム。
6. 前記判定手段は、取引が不可であると判定した場合に、悪用の疑いがあるか否かをさらに判定し、
   前記更新手段は、前記悪用の疑いがあるか否かの判定結果に基づいて、前記動作内容情報の内容を更新する、
   請求項５に記載のカード取引システム。
7. 前記更新手段は、所定の期間において前記判定手段によって取引が不可であると判定された件数に基づいて、前記動作内容情報の内容を更新する、
   請求項５又は６に記載のカード取引システム。
8. 前記オーソリ処理の所要時間に基づいて、前記動作内容情報の内容を更新する更新手段
   をさらに備える、請求項１乃至４の何れかに記載のカード取引システム。
9. 前記更新手段は、所定の期間において前記判定手段によって取引の可否が判定された件数と、当該期間における前記所要時間とに基づいて、前記動作内容情報の内容を更新する、
   請求項８に記載のカード取引システム。
   

Images