IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日本総合研究所の特許一覧

<>
  • 特許-カード取引システム 図1
  • 特許-カード取引システム 図2
  • 特許-カード取引システム 図3
  • 特許-カード取引システム 図4A
  • 特許-カード取引システム 図4B
  • 特許-カード取引システム 図4C
  • 特許-カード取引システム 図5
  • 特許-カード取引システム 図6
  • 特許-カード取引システム 図7
  • 特許-カード取引システム 図8
  • 特許-カード取引システム 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-12
(45)【発行日】2022-10-20
(54)【発明の名称】カード取引システム
(51)【国際特許分類】
   G06Q 20/40 20120101AFI20221013BHJP
   G06Q 20/24 20120101ALI20221013BHJP
   G07G 1/12 20060101ALI20221013BHJP
【FI】
G06Q20/40
G06Q20/24
G07G1/12 321P
【請求項の数】 8
(21)【出願番号】P 2018240592
(22)【出願日】2018-12-25
(65)【公開番号】P2020102070
(43)【公開日】2020-07-02
【審査請求日】2021-09-15
(73)【特許権者】
【識別番号】302064762
【氏名又は名称】株式会社日本総合研究所
(74)【代理人】
【識別番号】100125645
【弁理士】
【氏名又は名称】是枝 洋介
(74)【代理人】
【識別番号】100145609
【弁理士】
【氏名又は名称】楠屋 宏行
(72)【発明者】
【氏名】山本 真永
【審査官】萩島 豪
(56)【参考文献】
【文献】特開2003-196566(JP,A)
【文献】米国特許出願公開第2012/0278193(US,A1)
【文献】特開2000-194747(JP,A)
【文献】特表2017-500648(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G07G 1/12
(57)【特許請求の範囲】
【請求項1】
クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、
前記オーソリ処理は、複数の処理で構成されており、
クレジットカード及び/又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを所定のカード番号帯毎に定めた動作内容情報を取得する取得手段と、
クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、
特定した処理を実行することによって取引の可否を判定する判定手段と
を備えることを特徴とする、カード取引システム。
【請求項2】
前記動作内容情報には、クレジットカードの加盟店毎に、前記複数の処理のうちのどの処理を実行するのかが定められている、
請求項1に記載のカード取引システム。
【請求項3】
クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、
前記オーソリ処理は、複数の処理で構成されており、
クレジットカード及び/又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、
クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、
特定した処理を実行することによって取引の可否を判定する判定手段と
を備え
前記オーソリ処理は、クレジットカードの有効期限の確認を含む第1処理、クレジットカードの利用実績に基づいて不正の判定を行う第2処理、及び、カード会員の本人確認情報に基づいて不正の判定を行う第3処理を含んでおり、
前記動作内容情報には、前記第1乃至第3処理のうちのどの処理を実行するのかが定められている、
のカード取引システム。
【請求項4】
クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、
前記オーソリ処理は、複数の処理で構成されており、
クレジットカード及び/又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、
クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、
特定した処理を実行することによって取引の可否を判定する判定手段と
前記取引の可否の判定結果に基づいて、前記動作内容情報の内容を更新する更新手段と
を備えることを特徴とする、カード取引システム。
【請求項5】
前記判定手段は、取引が不可であると判定した場合に、悪用の疑いがあるか否かをさらに判定し、
前記更新手段は、前記悪用の疑いがあるか否かの判定結果に基づいて、前記動作内容情報の内容を更新する、
請求項4に記載のカード取引システム。
【請求項6】
前記更新手段は、所定の期間において前記判定手段によって取引が不可であると判定された件数に基づいて、前記動作内容情報の内容を更新する、
請求項4又は5に記載のカード取引システム。
【請求項7】
クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、
前記オーソリ処理は、複数の処理で構成されており、
クレジットカード及び/又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、
クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、
特定した処理を実行することによって取引の可否を判定する判定手段と
前記オーソリ処理の所要時間に基づいて、前記動作内容情報の内容を更新する更新手段と
を備えることを特徴とする、カード取引システム。
【請求項8】
前記更新手段は、所定の期間において前記判定手段によって取引の可否が判定された件数と、当該期間における前記所要時間とに基づいて、前記動作内容情報の内容を更新する、
請求項7に記載のカード取引システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、システムの負荷を軽減することができるカード取引システムに関する。
【背景技術】
【0002】
取引に利用可能なクレジットカードのカード番号を不正に取得する手法の1つとして、クレジットマスターが知られている(非特許文献1を参照)。クレジットマスターは、自動で生成された複数のカード番号を用いてインターネット上のショッピングサイトでの取引を繰り返し試みることによって、取引に利用可能なカード番号を割り出す手法である。クレジットマスターが行われると、大量のオーソリ処理(与信照会処理)が発生することになるため、オーソリシステムの負荷が大きくなるという問題が生じる。
【0003】
上記のようなクレジットマスターへの対策として、クレジットマスターが行われていることを検知した場合に、特定のカード番号帯のクレジットカードでの取引を一律不可にすることによって、システムの負荷を軽減する手法が従来知られている。
【先行技術文献】
【非特許文献】
【0004】
【文献】ウィキペディア フリー百科事典、” クレジットマスター”、[2018年10月30日検索]、インターネット(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)
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上記のように特定のカード番号帯のクレジットカードでの取引を一律不可にした場合、そのカード番号帯に属するクレジットカードはすべて利用できなくなってしまうため、真正利用を阻害するという問題が生じる。
【0006】
本発明は斯かる事情に鑑みてなされたものであり、その主たる目的は、取引を一律不可にすることなく、オーソリ処理によるシステムの負荷の増大を抑制することができるクレジットカード取引システムを提供することにある。
【課題を解決するための手段】
【0007】
上述した課題を解決するために、本発明の一の態様のカード取引システムは、クレジットカードのオーソリ処理を実行することによって当該クレジットカードを用いた取引の可否を判定するカード取引システムにおいて、前記オーソリ処理は、複数の処理で構成されており、クレジットカード及び/又はクレジットカードの加盟店毎に、前記オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を取得する取得手段と、クレジットカードの利用要求を受け付けた場合に、取得した動作内容情報に基づいて実行すべき処理を特定する特定手段と、特定した処理を実行することによって取引の可否を判定する判定手段とを備えることを特徴とする。
【0008】
前記態様において、前記動作内容情報には、所定のカード番号帯毎に、前記複数の処理のうちのどの処理を実行するのかが定められていてもよい。
【0009】
前記態様において、前記動作内容情報には、クレジットカードの加盟店毎に、前記複数の処理のうちのどの処理を実行するのかが定められていてもよい。
【0010】
また、前記態様において、前記オーソリ処理は、クレジットカードの有効期限の確認を含む第1処理、クレジットカードの利用実績に基づいて不正の判定を行う第2処理、及び、カード会員の本人確認情報に基づいて不正の判定を行う第3処理を含んでおり、前記動作内容情報には、前記第1乃至第3処理のうちのどの処理を実行するのかが定められていてもよい。
【0011】
また、前記態様において、前記取引の可否の判定結果に基づいて、前記動作内容情報の内容を更新する更新手段をさらに備えてもよい。
【0012】
また、前記態様において、前記判定手段は、取引が不可であると判定した場合に、悪用の疑いがあるか否かをさらに判定し、前記更新手段は、前記悪用の疑いがあるか否かの判定結果に基づいて、前記動作内容情報の内容を更新するようにしてもよい。
【0013】
また、前記態様において、前記更新手段は、所定の期間において前記判定手段によって取引が不可であると判定された件数に基づいて、前記動作内容情報の内容を更新するようにしてもよい。
【0014】
また、前記態様において、前記更新手段は、前記オーソリ処理の所要時間に基づいて、前記動作内容情報の内容を更新するようにしてもよい。
【0015】
また、前記態様において、前記更新手段は、所定の期間において前記判定手段によって取引の可否が判定された件数と、当該期間における前記所要時間とに基づいて、前記動作内容情報の内容を更新するようにしてもよい。
【発明の効果】
【0016】
本発明によれば、安全性を担保した上で、オーソリ処理によるシステムの負荷の増大を抑制することが可能になる。
【図面の簡単な説明】
【0017】
図1】本発明の実施の形態に係るカード取引システム及びその通信先の構成を示すブロック図。
図2】カード取引システムが有するアクションデータベースのレイアウトの一例を示す図。
図3】カード取引システムが有する処理結果データベースのレイアウトの一例を示す図。
図4A】オーソリ処理の手順を示すフローチャート。
図4B】オーソリ処理の手順を示すフローチャート。
図4C】オーソリ処理の手順を示すフローチャート。
図5】アクションDB更新処理の手順を示すフローチャート。
図6】アクションDB更新処理の手順を示すフローチャート。
図7】カード取引システムが有するアクションデータベースのレイアウトの他の例を示す図。
図8】カード取引システムが有するアクションデータベースのレイアウトの他の例を示す図。
図9】アクションDB更新処理の手順を示すフローチャート。
【発明を実施するための形態】
【0018】
以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。なお、以下に示す各実施の形態は、本発明の技術的思想を具体化するための方法及び装置を例示するものであって、本発明の技術的思想は下記のものに限定されるわけではない。本発明の技術的思想は、特許請求の範囲に記載された技術的範囲内において種々の変更を加えることができる。
【0019】
[カード取引システムの構成]
図1は、実施の形態に係るカード取引システム及びその通信先の構成を示すブロック図である。図1に示すように、本実施の形態のカード取引システム1は、インターネットを含む通信ネットワーク101と通信可能に接続されている。この通信ネットワーク101には、複数の加盟店サーバ2,2,…及び複数の加盟店端末3,3,…が通信可能に接続されており、カード取引システム1は、通信ネットワーク101を介して、これらの加盟店サーバ2,2,…及び複数の加盟店端末3,3,…との間で各種のデータの送受信を行う。
【0020】
カード取引システム1は、CPU、主記憶装置、補助記憶装置、入出力インタフェース、及び通信インタフェース等を含むコンピュータシステムである。CPUは、補助記憶装置から主記憶装置にロードされた各種のコンピュータプログラムを実行する。これにより、後述する各情報処理が実現される。また、通信インタフェースは、通信ネットワーク101と接続するためのインタフェースである。
【0021】
なお、カード取引システム1は、1台のコンピュータによって構成されていてもよく、複数のコンピュータによる分散システムによって構成されていてもよい。
【0022】
図1に示すとおり、カード取引システム1の補助記憶装置には、アクションデータベース(DB)11、処理結果データベース(DB)12、通常ログデータベース(DB)13、第1ログデータベース(DB)14、第2ログデータベース(DB)15、及び第3ログデータベース(DB)16の各データベースが設けられている。これらのデータベースの詳細については後述する。
【0023】
なお、本実施の形態では、上記の各データベースがカード取引システム1の内部に設けられているが、カード取引システム1がアクセス可能であれば、外部の他の装置に設けられていてもよい。
【0024】
加盟店サーバ2は、クレジットカードの加盟店のオンラインショップを運営するサーバである。また、加盟店端末3は、加盟店に設置されたCAT(Credit Authorization Terminal)等の端末である。
【0025】
図1に示すとおり、通信ネットワーク101には、複数の利用者端末4,4,…が通信可能に接続されている。利用者端末4が、通信ネットワーク101を介して各加盟店サーバ2にアクセスすることにより、オンラインショッピングが実現される。なお、利用者端末4は、例えば、パーソナルコンピュータ、スマートフォン等の携帯電話機又はタブレット端末等で構成される。
【0026】
以下、上述した各データベースの詳細について説明する。
(1)アクションDB11
アクションDB11は、クレジットカードのオーソリ処理を実行する場合に、オーソリ処理を構成する複数の処理のうちのどの処理を実行するのかを定めた動作内容情報を格納するデータベースである。本実施の形態では、カード番号帯毎に動作内容が規定されている。
【0027】
図2は、アクションDB11のレイアウトの一例を示す図である。図2に示すように、アクションDB11では、各カード番号帯の開始番号及び終了番号が定められるとともに、それらのカード番号帯に対してオーソリ処理の際に実行される動作内容が規定されている。
【0028】
オーソリ処理の際の動作内容を規定する情報として、アクションDB11には、“通常”、“第1ログ”、“第1拡張”、“第2ログ”、“第2拡張”、及び“第3ログ”の各情報が格納されている。このうち、“通常”は、クレジットカードの有効期限及びセキュリティコードの確認など、オーソリ処理において通常行われる処理(以下「通常処理」という)を実行するか、それとも通常処理を行わずに取引を許可又は拒否するかを示す情報である。なお、通常処理のログのうち、処理日時などの基本的な内容については、通常ログDB13に書き込まれる。
【0029】
また、“第1ログ”は、通常処理を実行する場合に、通常ログDB13へのログの書き込みに加えて、より詳細な内容のログを第1ログDB14へ書き込むか否かを示す情報である。
【0030】
また、“第1拡張”は、クレジットカードの利用実績に基づいて不正の有無を判定する第1拡張処理を実行するか否かを示す情報である。第1拡張処理には、例えば、利用金額等が通常の利用時と大きく異なる場合に不正と判定したり、特定の地点でクレジットカードが利用された直後に当該地点から大きく距離が離れている地点で同一のクレジットカードが利用される場合に不正と判定したりする処理などが含まれる。
【0031】
また、“第2ログ”は、第1拡張処理のログを第2ログDB15に書き込むか否かを示す情報である。
【0032】
また、“第2拡張”は、クレジットカードのカード会員に本人確認情報の提示を追加で求め、カード会員から提示された情報に基づいて不正の有無を判定する第2拡張処理を実行するか否かを示す情報である。第2拡張処理には、カード会員の生体情報(指紋情報、静脈情報、顔情報、虹彩情報、及び声音情報など)、生年月日、干支、星座、自宅郵便番号、自宅住所、及び登録電話番号などの本人確認情報を追加で求める処理、並びに、その回答内容に基づいて不正の有無を判定する処理が含まれる。
【0033】
なお、後述するように、アクションDB更新処理において“第2拡張”を自動更新してもよく、例えば下記のようなカード会員については手動で設定してもよい。
(a)特定の加盟店で店員によるスキミングの発生が懸念されるような事象が確認された場合において、その加盟店での利用実績があるカード会員
(b)特定の会員番号帯の取引で不正利用と思われるNGが増えているがすべてをNGにするほどではない場合において、その会員番号帯に含まれるカード会員
【0034】
また、第2拡張処理は、店舗内の設備で取得可能な本人確認情報を確認した上で、その取得可能な本人確認情報の提示を求めるようにしてもよく、通常処理及び/又は第1拡張処理の結果に基づいて確認が必要な本人確認情報を特定した上で、その本人確認情報の提示を求めるようにしてもよい。
【0035】
また、“第3ログ”は、第2拡張処理のログを第3ログDB16に書き込むか否かを示す情報である。
【0036】
上述した通常処理、第1拡張処理、第2拡張処理、及び第1ログDB14乃至第3ログDB16への書き込み処理のそれぞれは、オーソリ処理を構成する処理に相当する。本実施の形態では、アクションDB11を参照することによって、取引毎に、オーソリ処理を構成するこれらの処理のうちのどの処理を実行するのかを特定し、その特定した処理を実行することによって、取引の可否の判定が行われる。
【0037】
(2)処理結果DB12
処理結果DB12は、上記のアクションDB11に基づいてオーソリ処理が実行された場合の処理結果を示す処理結果情報を格納するデータベースである。
【0038】
図3は、処理結果DB12のレイアウトの一例を示す図である。図3に示すように、処理結果DB12には、“処理日時”、“オーソリ結果”、“カード番号”、“加盟店番号”、“加盟店端末”、“処理所要時間”、及び“利用者端末”の各情報が格納されている。このうち、“処理日時”は、オーソリ処理の実行が開始された日時を示す情報である。
【0039】
また、“オーソリ結果”は、取引の可否の判定結果を示す情報である。本実施の形態の場合、OK、NG1、及びNG2の3種類のオーソリ結果が用いられる。ここで、OKは取引が可であることを、NG1は取引が不可であって且つ悪用の疑いがないことを、NG2は取引が不可であって且つ悪用の疑いがあることを、それぞれ示している。悪用の疑いの有無については、例えば、限度額超過などによって取引が不可であると判定された場合は悪用の疑いはないと判断され、セキュリティコードの誤りなどによって取引が不可であると判定された場合は悪用の疑いがあると判断される。
【0040】
また、“カード番号”は取引に利用されたクレジットカードの番号であり、“加盟店番号”は利用された加盟店を識別する加盟店番号である。
【0041】
また、“加盟店端末”は、加盟店の店舗に設置された加盟店端末3を識別する加盟店端末番号である。利用者がクレジットカードを実店舗において利用する場合、その実店舗に設置されている加盟店端末3によってオーソリ処理の要求が行われる。このとき、その加盟店端末3の加盟店端末番号がカード取引システム1に送信され、その後処理結果DB12に格納される。
【0042】
また、“処理所要時間”は、オーソリ処理の実行に要した時間(レスポンスタイム)である。オーソリ処理を構成する各処理のうち、実行される処理の数が多いほど、処理所要時間が長くなる傾向にある。
【0043】
また、“利用者端末”は、加盟店のオンラインショップにて利用者がクレジットカードを利用する場合に用いられた利用者端末4を識別するための情報である。例えば、携帯電話のIMEI(International Mobile Equipment Identity)などが“利用者端末”として用いられる。
【0044】
(3)ログDB13~16
上述したとおり、通常ログDB13及び第1ログDB14は通常処理のログを、第2ログDB15は第1拡張処理のログを、第3ログDB16は第2拡張処理のログをそれぞれ格納するデータベースである。取引の検証を行うためにはログが残されていることが好ましいが、ログの書き込みが多く行われるとシステムの負荷が増大することになる。したがって、ログを残す必要性が高い取引についてログの書き込みを行い、それ以外の取引についてはログの書き込みを行わないようにすることが望ましく、アクションDB11ではそのような設定がなされる。
【0045】
[カード取引システムの動作]
次に、上述したように構成された本実施の形態のカード取引システムの動作について、フローチャート等を参照しながら説明する。以下では、(1)クレジットカードでの取引の可否を判定するオーソリ処理、及び(2)オーソリ処理の結果に基づいてアクションDB11の内容を更新するアクションDB更新処理の各処理について説明する。
【0046】
(1)オーソリ処理
利用者は、オンラインショップ又は実店舗にてクレジットカードを利用した取引を行う。オンラインショップで取引を行う場合、利用者は利用者端末4を用いて加盟店サーバ2にアクセスし、カード番号及び有効期限などのカード情報を加盟店サーバ2に対して入力する。また、実店舗で取引を行う場合では、利用者のクレジットカードのカード情報を加盟店端末3が読み取る。このようにしてカード情報を取得した加盟店サーバ2又は加盟店端末3は、そのカード情報を含むオーソリ要求をカード取引システム1に対して送信する。その後、カード取引システム1によって下記のオーソリ処理が実行される。
【0047】
図4A乃至図4Cは、カード取引システム1によって実行されるオーソリ処理の手順を示すフローチャートである。図4Aに示すとおり、カード取引システム1はまず、上述したようにして加盟店サーバ2又は加盟店端末3から送信されたオーソリ要求を受信する(S101)。なお、このオーソリ要求には、カード情報の他、処理結果情報における“加盟店番号”、及び、“加盟店端末”又は“利用者端末”に相当する情報が含まれている。
【0048】
次に、カード取引システム1は、アクションDB11を参照し(S102)、受信したオーソリ要求に含まれるカード番号が属するカード番号帯に係る動作内容情報を取得する。これにより、オーソリ処理を構成する各処理のうちどの処理を実行すべきかを判定することが可能になる。
【0049】
カード取引システム1はまず、取得した動作内容情報における“通常”に基づいて、通常処理を実行するか、それとも通常処理を行わずに取引を許可又は拒否するかを判定する(S103)。ここで通常処理を実行しないと判定した場合(S103でNO)、図4Bに進み、カード取引システム1は、取引を許可するか否かを判定する(S104)。
【0050】
ステップS104において、取引を許可しないと判定した場合(S104でNO)、カード取引システム1は、取引の拒否を示す拒否情報を加盟店サーバ2又は加盟店端末3に対して送信する(S105)。他方、取引を許可すると判定した場合(S104でYES)、カード取引システム1は、取引の許可を示す許可情報を加盟店サーバ2又は加盟店端末3に対して送信する(S106)。
【0051】
その後、カード取引システム1は、取引拒否又は許可を示す情報を含む処理結果情報を処理結果DB12に登録する(S107)。なお、本実施の形態では、取引拒否の場合は処理結果情報における“オーソリ結果”をNG2とし、取引許可の場合はOKとする。
【0052】
ステップS103に戻り、通常処理を実行すると判定した場合(S103でYES)、カード取引システム1は、所定の通常処理を実行し(S108)、そのログを通常ログDB13に書き込む(S109)。
【0053】
次に、カード取引システム1は、動作内容情報における“第1ログ”に基づいて、第1ログDB14への書き込みを実行するか否かを判定する(S110)。第1ログDB14への書き込みを実行すると判定した場合(S110でYES)、カード取引システム1は、通常処理の詳細なログを第1ログDB14に書き込む(S111)。他方、第1ログDB14への書き込みを実行しないと判定した場合(S110でNO)は、ステップS111を経ずに次のステップS112へ進む。
【0054】
次に、カード取引システム1は、動作内容情報における“第1拡張”に基づいて、第1拡張処理を実行するか否かを判定する(S112)。第1拡張処理を実行すると判定した場合(S112でYES)、カード取引システム1は、所定の第1拡張処理を実行する(S113)。他方、第1拡張処理を実行しないと判定した場合(S112でNO)は、ステップS113を経ずに次のステップS114へ進む。
【0055】
次に、カード取引システム1は、動作内容情報における“第2ログ”に基づいて、第2ログDB15への書き込みを実行するか否かを判定する(S114)。第2ログDB15への書き込みを実行すると判定した場合(S114でYES)、カード取引システム1は、第1拡張処理のログを第2ログDB15に書き込む(S115)。他方、第2ログDB15への書き込みを実行しないと判定した場合(S114でNO)は、ステップS115を経ずに次のステップS116へ進む。
【0056】
図4Cに進み、カード取引システム1は、動作内容情報における“第2拡張”に基づいて、第2拡張処理を実行するか否かを判定する(S116)。第2拡張処理を実行すると判定した場合(S116でYES)、カード取引システム1は、所定の第2拡張処理を実行する(S117)。なお、この第2拡張処理において利用者の生体情報が必要になる場合、カード取引システム1は、加盟店サーバ2又は加盟店端末3などを介して生体情報を取得した上で、第2拡張処理を実行する。他方、第2拡張処理を実行しないと判定した場合(S116でNO)は、ステップS117を経ずに次のステップS118へ進む。
【0057】
次に、カード取引システム1は、動作内容情報における“第3ログ”に基づいて、第3ログDB16への書き込みを実行するか否かを判定する(S118)。第3ログDB16への書き込みを実行すると判定した場合(S118でYES)、カード取引システム1は、第2拡張処理のログを第3ログDB16に書き込む(S119)。他方、第3ログDB16への書き込みを実行しないと判定した場合(S118でNO)は、ステップS119を経ずに次のステップS120へ進む。
【0058】
次に、カード取引システム1は、通常処理、第1拡張処理、及び第2拡張処理の結果に基づいて、当該クレジットカードでの取引の可否を判定する(S120)。なお、第1拡張処理及び第2拡張処理のうち実行されていない処理がある場合、その処理は判定の基礎とはならず、実行された処理の結果のみに基づいて取引の可否の判定が行われる。
【0059】
ステップS120において取引は不可であると判定された場合(S120でNO)、カード取引システム1は、取引が不可であることを示す取引不可情報を加盟店サーバ2又は加盟店端末3に対して送信する(S121)。他方、取引は可であると判定された場合(S120でYES)、カード取引システム1は、取引が可であることを示す取引可情報を加盟店サーバ2又は加盟店端末3に対して送信する(S122)。
【0060】
その後、カード取引システム1は、取引可又は不可を示す情報を含む処理結果情報を処理結果DB12に登録する(S123)。ここで、取引可の場合は“オーソリ結果”をOKとし、取引不可の場合は“オーソリ結果”をNG1又はNG2とする。また、“処理所要時間”は、ステップS102からS120までに要した時間とする。
【0061】
上述したとおり、本実施の形態では、カード番号帯によってオーソリ処理の動作内容が異なっている。例えば、不正取引の可能性が高いカード番号帯については第1拡張処理及び/又は第2拡張処理を行う一方、不正取引の可能性が低いカード番号については通常処理のみを行うなどの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。
【0062】
(2)アクションDB更新処理
アクションDB更新処理では、上記のオーソリ処理の結果に基づき、アクションDB11の内容を更新する。例えば、オーソリ処理の結果を用いて不正取引の可能性が高いカード番号帯を特定し、そのカード番号帯についてはそれ以降より厳格なオーソリ処理を行うようにすることなどが想定される。なお、このアクションDB更新処理は、所定の時間間隔で繰り返し実行される。以下、アクションDB更新処理の具体例について説明する。
【0063】
図5は、カード取引システム1が実行するアクションDB更新処理の一例を示すフローチャートである。図5に示すとおり、カード取引システム1はまず、所定数(例えば直近1万件)の処理結果情報を処理結果DB12から抽出し(S201)、カード番号帯毎に各種情報を集計する(S202)。
【0064】
次に、カード取引システム1は、集計した結果を用いて、“オーソリ結果”がNG2である件数の割合を算出し、その値と所定の第1閾値及び第2閾値とを比較する。ここで、第1閾値は、第2閾値よりも大きい値である。例えば、第1閾値及び第2閾値をそれぞれ80%及び10%などに設定することが想定される。
【0065】
カード取引システム1はまず、NG1の件数の割合が第1閾値以上であるか否かを判定する(S203)。ここで、第1閾値以上であると判定された場合(S203でYES)、悪用の疑いがある取引不可の件数が多いことになるため、カード取引システム1は、当該カード番号帯の取引について、通常処理を行うことなく一律拒否となるように、動作内容情報における“通常”を更新する(S204)。これにより、それ以降、当該カード番号帯については取引が一律拒否されることになる。
【0066】
他方、ステップS203にて第1閾値以上ではないと判定された場合(S203でNO)、カード取引システム1は、NG2の件数の割合が第2閾値以上であるか否かを判定する(S205)。ここで、第2閾値以上であると判定された場合(S205でYES)、悪用の疑いがある取引不可の件数が一定数あることになるため、カード取引システム1は、当該カード番号帯の取引について第1拡張処理及び/又は第2拡張処理を実行するように、動作内容情報における“第1拡張”及び“第2拡張”を更新する(S206)。これにより、それ以降、当該カード番号帯についてはより厳しい基準で取引の可否の判定が行われることになる。なお、当該カード番号帯について既に各拡張処理を実施するように設定されている場合はそのままの設定が維持される。
【0067】
また、ステップS205にて第2閾値以上ではないと判定された場合(S205でNO)、悪用の疑いがある取引不可の件数が比較的少ないことになるため、カード取引システム1は、当該カード番号帯の取引について第1拡張処理及び/又は第2拡張処理を実行しないように、動作内容情報における“第1拡張”及び“第2拡張”を更新する(S207)。これにより、それ以降、当該カード番号帯についてはより緩やかな基準で取引の可否の判定が行われることになり、システムの負荷が軽減されることになる。なお、当該カード番号帯について既に各拡張処理を実施しないように設定されている場合はそのままの設定が維持される。
【0068】
なお、上記では、NG2の件数の割合を基準にしているが、NG1又はNG1とNG2との合計の件数の割合を基準にしてもよい。また、件数の割合ではなく件数自体を基準にしてもよい。
【0069】
図6は、カード取引システム1が実行するアクションDB更新処理の他の例を示すフローチャートである。上述した場合と同様に、カード取引システム1はまず、所定数(例えば直近1万件)の処理結果情報を処理結果DB12から抽出し(S301)、カード番号帯毎に各種情報を集計する(S302)。
【0070】
次に、カード取引システム1は、集計した結果を用いて、取引が発生する頻度(以下「取引発生頻度」という)及び“処理所要時間”の平均を算出し、その取引発生頻度が所定の閾値以下であって、且つ平均処理所要時間が所定の閾値以上であるか否かを判定する(S303)。ここで、取引発生頻度は、毎秒何件の取引が発生しているのかを表す指標である。例えば80秒間に1万件の取引が発生している場合であれば、取引発生頻度は125件/秒になる。取引発生頻度に対する閾値としては例えば200秒/件などの値が、平均処理所要時間に対しては例えば1.5秒などの値が、それぞれ設定される。
【0071】
ステップS303において、取引発生頻度が閾値以下及び平均処理所要時間が閾値以上の2つの条件を満足していると判定された場合(S303でYES)、システムの負荷が比較的高いと判断することができるため、カード取引システム1は、当該カード番号帯の取引について第1拡張処理及び/又は第2拡張処理を実行しないように、動作内容情報における“第1拡張”及び“第2拡張”を更新する(S304)。これによって、システムの負荷の軽減を図ることができる。なお、当該カード番号帯について既に各拡張処理を実施しないように設定されている場合はそのままの設定が維持される。
【0072】
他方、ステップS303において、上記2つの条件のうちの少なくとも1つが満足されないと判定された場合(S303でNO)、システムの処理能力に余裕があると判断することができるため、カード取引システム1は、当該カード番号帯の取引について第1拡張処理及び/又は第2拡張処理を実行するように、動作内容情報における“第1拡張”及び“第2拡張”を更新する(S305)。これによって、当該カード番号帯に係る取引の安全性を強化することができる。なお、当該カード番号帯について既に各拡張処理を実施するように設定されている場合はそのままの設定が維持される。
【0073】
なお、上記では、取引発生頻度及び平均処理所要時間の両方を基準にしているが、何れか一方のみを基準にするようにしてもよい。具体的には、平均処理所要時間が閾値以上である場合、オーソリ処理において実行する処理が少なくなるように、アクションDB11の内容を更新してもよい。また、取引発生頻度が閾値以下である場合、オーソリ処理において実行する処理が多くなるように、アクションDB11の内容を更新してもよい。
【0074】
また、上述した2つのアクションDB更新処理では、第1拡張処理及び第2拡張処理の実行の有無について設定変更を行っているが、それ以外の処理、すなわち第1ログ乃至第3ログ書き込み処理の実行の有無について同様に設定変更を行うようにしてもよい。
【0075】
上記のアクションDB更新処理を行うことによって、アクションDB11の内容を、取引の状況に応じた適切なものに自動的に設定することができる。すなわち、本実施の形態によれば、アクションDB11の自動メンテナンスを実現することができる。
【0076】
(その他の実施の形態)
上記の実施の形態では、カード番号帯毎にオーソリ処理の動作内容が規定されているが、本発明はこれに限定されるわけではなく、個々のカード番号毎に規定されていてもよい。その他にも、例えば加盟店番号毎に、カード番号及び加盟店番号毎に、又はカード番号帯及び加盟店番号毎に、オーソリ処理の動作内容が規定されていても構わない。
【0077】
図7は、加盟店番号毎にオーソリ処理の動作内容が規定されているアクションDB11のレイアウトの一例を示す図である。この場合、アクションDB11において、不正取引の可能性が高い加盟店の取引についてはより厳しい基準でオーソリ処理を行う(例えば、第1拡張処理及び/又は第2拡張処理を行うなど)一方、不正取引の可能性が低い加盟店の取引についてはより緩やかな基準でオーソリ処理を行う(例えば、通常処理のみを行うなど)などの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。
【0078】
また、図8は、カード番号帯及び加盟店毎にオーソリ処理の動作内容が規定されているアクションDB11のレイアウトの一例を示す図である。この場合、アクションDB11において、不正取引の可能性が高いカード番号帯及び加盟店の組合せについてはより厳しい基準でオーソリ処理を行う一方、不正取引の可能性が低いカード番号帯及び加盟店の組合せについてはより緩やかな基準でオーソリ処理を行うなどの設定をすることにより、安全性を担保した上で、オーソリ処理によるシステム負荷の軽減を図ることが可能になる。
【0079】
なお、上記のように加盟店毎にオーソリ処理の動作内容を規定した場合、アクションDB更新処理においても、各加盟店の事情を考慮した処理を行うことが可能になる。図9は、カード取引システム1が実行するアクションDB更新処理の手順の変形例を示すフローチャートである。この例でも、カード取引システム1はまず、所定数(例えば直近1万件)の処理結果情報を処理結果DB12から抽出し(S401)、カード番号帯毎に各種情報を集計する(S402)。
【0080】
次に、カード取引システム1は、集計した結果を用いて、“オーソリ結果”がNG1又はNG2である件数の割合を算出し、その値が閾値以上(例えば80%以上)であるか否かを判定する(S403)。ここで、閾値以上であると判定された場合(S403でYES)、カード取引システム1は、NG1又はNG2である取引の加盟店番号を特定することによって同一加盟店の件数の割合を算出し、その値が閾値以上(例えば50%以上)であるか否かを判定する(S404)。
【0081】
ステップS404において、同一加盟店の件数の割合が閾値以上であると判定された場合(S404でYES)、当該加盟店について不正取引の可能性が高いことになるため、カード取引システム1は、当該加盟店の取引について、通常処理を行うことなく一律拒否となるように、動作内容情報における“通常”を更新する(S405)。その他にも、当該加盟店の取引について第1拡張処理及び/又は第2拡張処理を実行するように、動作内容情報における“第1拡張”及び“第2拡張”を更新することが想定される。
【0082】
クレジットマスターの場合、特定の加盟店が狙われることがあるため、上記のように加盟店毎にオーソリ処理の動作内容を規定することは有効である。
【符号の説明】
【0083】
1 カード取引システム
11 アクションデータベース
12 処理結果データベース
13 通常ログデータベース
14 第1ログデータベース
15 第2ログデータベース
16 第3ログデータベース
2 加盟店サーバ
3 加盟店端末
4 利用者端末
101 通信ネットワーク
図1
図2
図3
図4A
図4B
図4C
図5
図6
図7
図8
図9