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

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

▶ PayPay株式会社の特許一覧

特開2024-132780サーバ装置、情報提供方法、およびプログラム
<>
  • 特開-サーバ装置、情報提供方法、およびプログラム 図1
  • 特開-サーバ装置、情報提供方法、およびプログラム 図2
  • 特開-サーバ装置、情報提供方法、およびプログラム 図3
  • 特開-サーバ装置、情報提供方法、およびプログラム 図4
  • 特開-サーバ装置、情報提供方法、およびプログラム 図5
  • 特開-サーバ装置、情報提供方法、およびプログラム 図6
  • 特開-サーバ装置、情報提供方法、およびプログラム 図7
  • 特開-サーバ装置、情報提供方法、およびプログラム 図8
  • 特開-サーバ装置、情報提供方法、およびプログラム 図9
  • 特開-サーバ装置、情報提供方法、およびプログラム 図10
  • 特開-サーバ装置、情報提供方法、およびプログラム 図11
  • 特開-サーバ装置、情報提供方法、およびプログラム 図12
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024132780
(43)【公開日】2024-10-01
(54)【発明の名称】サーバ装置、情報提供方法、およびプログラム
(51)【国際特許分類】
   G06Q 20/40 20120101AFI20240920BHJP
【FI】
G06Q20/40 330
【審査請求】有
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2023110865
(22)【出願日】2023-07-05
(62)【分割の表示】P 2023039680の分割
【原出願日】2023-03-14
(11)【特許番号】
(45)【特許公報発行日】2023-10-10
(71)【出願人】
【識別番号】519110124
【氏名又は名称】PayPay株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100154852
【弁理士】
【氏名又は名称】酒井 太一
(74)【代理人】
【識別番号】100181124
【弁理士】
【氏名又は名称】沖田 壮男
(74)【代理人】
【識別番号】100194087
【弁理士】
【氏名又は名称】渡辺 伸一
(72)【発明者】
【氏名】笹山 裕矢
(72)【発明者】
【氏名】松本 道隆
【テーマコード(参考)】
5L020
5L055
【Fターム(参考)】
5L020AA75
5L055AA75
(57)【要約】
【課題】クレジットカードなどの、決済時に当該決済の正当性を確認する手続きを伴う電子決済において、正当な利用を不正利用と誤って判定してしまう状況を改善することができるサーバ装置、情報提供方法、およびプログラムを提供すること。
【解決手段】決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、前記支援情報提供部は、過去の前記手続きのうち実際に違反であった不正手続きを特定して前記不正手続きによって決済された金額の合計を前記不正手続きによる被害額として算出し、前記被害額を前記支援情報として提供する、サーバ装置。
【選択図】図1
【特許請求の範囲】
【請求項1】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、
前記支援情報提供部は、過去の前記手続きのうち実際に違反であった不正手続きを特定して前記不正手続きによって決済された金額の合計を前記不正手続きによる被害額として算出し、前記被害額を前記支援情報として提供する、
サーバ装置。
【請求項2】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、
前記支援情報提供部は、過去の前記手続きのうち、実際には不正利用が試みられた手続きではないにも関わらず前記複数のルールにより不正利用と判定された手続きである真正手続きを特定して前記真正手続きで決済されるはずであった金額の合計を前記真正手続きが阻害されたことによる損失額として算出し、前記損失額を前記支援情報として提供する、
サーバ装置。
【請求項3】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、
前記支援情報提供部は、前記複数のルールのうち特定のルールが削除された状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、
サーバ装置。
【請求項4】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、
前記支援情報提供部は、前記複数のルールのうち特定のルールであってパラメータ値の調整が可能なルールについて前記パラメータ値を変更した状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、
サーバ装置。
【請求項5】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置が、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する情報提供方法であって、
前記サーバ装置が、過去の前記手続きのうち実際に違反であった不正手続きを特定して前記不正手続きによって決済された金額の合計を前記不正手続きによる被害額として算出し、前記被害額を前記支援情報として提供する、
情報提供方法。
【請求項6】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置が、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する情報提供方法であって、
前記サーバ装置が、過去の前記手続きのうち、実際には不正利用が試みられた手続きではないにも関わらず前記複数のルールにより不正利用と判定された手続きである真正手続きを特定して前記真正手続きで決済されるはずであった金額の合計を前記真正手続きが阻害されたことによる損失額として算出し、前記損失額を前記支援情報として提供する、
情報提供方法。
【請求項7】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置が、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する情報提供方法であって、
前記サーバ装置が、前記複数のルールのうち特定のルールが削除された状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、
情報提供方法。
【請求項8】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置が、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する情報提供方法であって、
前記サーバ装置が、前記複数のルールのうち特定のルールであってパラメータ値の調整が可能なルールについて前記パラメータ値を変更した状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、
情報提供方法。
【請求項9】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置に、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供させるためのプログラムであって、
前記サーバ装置に、過去の前記手続きのうち実際に違反であった不正手続きを特定させて前記不正手続きによって決済された金額の合計を前記不正手続きによる被害額として算出させ、前記被害額を前記支援情報として提供させる、
ためのプログラム。
【請求項10】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置に、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供させるためのプログラムであって、
前記サーバ装置に、過去の前記手続きのうち、実際には不正利用が試みられた手続きではないにも関わらず前記複数のルールにより不正利用と判定された手続きである真正手続きを特定させて前記真正手続きで決済されるはずであった金額の合計を前記真正手続きが阻害されたことによる損失額として算出させ、前記損失額を前記支援情報として提供させる、
ためのプログラム。
【請求項11】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置に、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供させるためのプログラムであって、
前記サーバ装置に、前記複数のルールのうち特定のルールが削除された状況での不正手続きの検出状況をシミュレーションにより求めさせ、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供させる、
プログラム。
【請求項12】
決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置に、
前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供させるためのプログラムであって、
前記サーバ装置に、前記複数のルールのうち特定のルールであってパラメータ値の調整が可能なルールについて前記パラメータ値を変更した状況での不正手続きの検出状況をシミュレーションにより求めさせ、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供させる、
ためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ装置、情報提供方法、およびプログラムに関する。
【背景技術】
【0002】
一般に、利用者がクレジットカードを利用して支払いを行う際には、店舗側がクレジットカード会社に利用者の与信情報を照会し、決済可能かどうかを確認する手続きを行っている。この手続きは「オーソリ(Authorization)」と呼ばれ(信用照会や信用承認などと呼ばれる場合もある)、クレジットカードによる支払いは、オーソリによって決済可能であることが確認された場合に完了したとみなされるものである。従来、このオーソリのための電文データ(以下「オーソリデータ」という。)をもとに、与信判定のためのスコア値の信頼性を向上させる技術が提案されている。例えば、オーソリデータに加えて、直前の利用時にかかるオーソリデータとの利用時間の差、利用金額の差等の履歴情報を用いてスコア値を算出する方法が提案されている(例えば特許文献1参照)。また、例えば、オーソリデータの学習済みモデルにより不正利用の出現確率を算出し、算出した出現確率に当該学習済みモデルの信頼度を反映させてスコア値を算出する方法が提案されている(例えば特許文献2参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2004-348536号公報
【特許文献2】特開2004-334526号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記従来の技術では、正当な利用を不正利用と誤って判定してしまう状況を改善することができない可能性があった。より具体的には、上記従来の技術では、スコア値の精度向上は期待され得るものの、不正利用を判定するルールそのものの見直しを適切に行えない可能性があった。
【0005】
本発明は、このような事情を考慮してなされたものであり、クレジットカードなどの、決済時に当該決済の正当性を確認する手続きを伴う電子決済において、正当な利用を不正利用と誤って判定してしまう状況を改善することができるサーバ装置、情報提供方法、およびプログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【0006】
本発明の一態様は、決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、前記支援情報提供部は、過去の前記手続きのうち実際に違反であった不正手続きを特定して前記不正手続きによって決済された金額の合計を前記不正手続きによる被害額として算出し、前記被害額を前記支援情報として提供する、サーバ装置である。
本発明の一態様は、決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、前記支援情報提供部は、過去の前記手続きのうち、実際には不正利用が試みられた手続きではないにも関わらず前記複数のルールにより不正利用と判定された手続きである真正手続きを特定して前記真正手続きで決済されるはずであった金額の合計を前記真正手続きが阻害されたことによる損失額として算出し、前記損失額を前記支援情報として提供する、サーバ装置である。
【0007】
本発明の一態様は、決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、前記支援情報提供部は、前記複数のルールのうち特定のルールが削除された状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、サーバ装置である。
本発明の一態様は、決済時に当該決済の正当性を確認する手続きを伴う電子決済に関する情報提供を行うサーバ装置であって、前記正当性の確認のために予め定められた複数のルールについて、管理者による前記複数のルールの妥当性の判断を支援するための支援情報を、前記手続きの履歴情報をもとに生成して前記管理者の端末装置に提供する支援情報提供部を備え、前記支援情報提供部は、前記複数のルールのうち特定のルールであってパラメータ値の調整が可能なルールについて前記パラメータ値を変更した状況での不正手続きの検出状況をシミュレーションにより求め、当該シミュレーションの結果により認識される、前記不正手続きの検出状況の変化を前記支援情報として提供する、サーバ装置である。
【発明の効果】
【0008】
本発明の一態様によれば、クレジットカードなどの、決済時に当該決済の正当性を確認する手続きを伴う電子決済において、正当な利用を不正利用と誤って判定してしまう状況を改善することができるサーバ装置、情報提供方法、およびプログラムを提供することができる。
【図面の簡単な説明】
【0009】
図1】電子決済サービスが実現されるための構成の一例を示す図である。
図2】電子決済の大まかな流れを例示したシーケンス図(その1)である。
図3】電子決済の大まかな流れを例示したシーケンス図(その2)である。
図4】第1実施形態に係る決済サーバ100の構成図である。
図5】利用者情報172の内容の一例を示す図である。
図6】加盟店/店舗情報176の内容の一例を示す図である。
図7】端末決済とカード決済のそれぞれの処理を概念的に示す図である。
図8】カード決済設定情報272の内容の一例を示す図である。
図9】第1実施形態に係る提携クレジットカード会社サーバ200の構成図である。
図10】オーソリ情報276の内容の一例を示す図である。
図11】不正検知ルール278に含まれる個々のルールについて不正オーソリの割合をルールの精度として提示する支援情報の一例を説明する図(その1)である。
図12】不正検知ルール278に含まれる個々のルールについて不正オーソリの割合をルールの精度として提示する支援情報の一例を説明する図(その2)である。
【発明を実施するための形態】
【0010】
以下、図面を参照し、本発明のサーバ装置、情報提供方法、およびプログラムの実施形態について説明する。アプリケーションプログラムと決済サーバおよび提携クレジットカード会社サーバは、協働して電子決済サービスを提供する。以下の説明ではアプリケーションプログラムを決済アプリと称する。また、決済サーバと提携クレジットカード会社サーバを合わせたものを決済管理システムと称する場合がある。電子決済サービスは、店舗における商品やサービスの購買に係る決済をサポートするサービスである。店舗とは、例えば、現実空間に存在する物理的な店舗(実店舗)であるが、電子商取引の仮想店舗を含んでもよい。仮想店舗は、電子決済サービスの運営者とは異なる主体によって提供されるものを含んでもよい。その場合、仮想店舗における買い物の決済の際に、電子決済サービスのインターフェース画面に遷移するように制御される。電子決済サービスにおいて、店舗は、例えば加盟店(ブランド)に属するものとして扱われ、店舗において購買行動が行われた際の決済などの処理は、主として利用者と加盟店の間で行われる。これに代えて、決済などの処理が利用者と店舗との間で行われてもよい。
【0011】
[電子決済サービス]
図1は、電子決済サービスが実現されるための構成の一例を示す図である。電子決済サービスは、決済サーバ100および提携クレジットカード会社サーバ200を中心として実現される。決済サーバ100は、例えば、一以上の利用者端末装置10、一以上の第1店舗端末装置50、一以上のクレジット処理端末55、一以上の第2店舗端末装置70のそれぞれとネットワークNWを介して通信する。提携クレジットカード会社サーバ200は管理者端末装置80とネットワークNWを介して通信する。ネットワークNWは、例えば、インターネット、LAN(Local Area Network)、無線基地局、プロバイダ装置などを含む。
【0012】
利用者端末装置10は、例えば、スマートフォンやタブレット端末等の可搬型端末装置である。利用者端末装置10は、少なくとも、光学読取機能、通信機能、表示機能、入力受付機能、プログラム実行機能を有するコンピュータ装置である。以下の説明では、これらの機能を実現するための構成をそれぞれカメラ、通信装置、タッチパネル、CPU(Central Processing Unit)等と称する。利用者端末装置10では、CPU等のプロセッサにより決済アプリ20が実行されることで、決済サーバ100と連携して電子決済サービスを利用者に提供するように動作する。決済アプリ20は、例えば、アプリケーションストアから利用者端末装置10にインストールされ、カメラ、通信装置、タッチパネルなどを制御する。
【0013】
第1店舗端末装置50は、例えば、店舗に設置される。第1店舗端末装置50は、少なくとも、商品価格取得機能、光学読取機能、プログラム実行機能、通信機能を有するコンピュータ装置である。第1店舗端末装置50は、いわゆるPOS(Point of Sale)装置を含み、POS装置によって商品価格取得機能や光学読取機能を実現してもよい。店舗コード画像60は、店舗に置かれ、QRコード(登録商標)等のコード画像が紙やプラスチックの媒体に印刷されたものである。なお、店舗コード画像60は、店舗に置かれたディスプレイ(スマートフォンなどの端末装置のディスプレイでもよい)によって表示されてもよい。
【0014】
クレジット処理端末55は、第1店舗端末装置50と同様に、店舗に設置される。クレジット処理端末55は、例えば、クレジット決済端末(クレジットカードリーダー)と、POS装置を含む。レジット決済端末は、挿入され又は翳されたクレジットカード(提携カード57を含む)からPIN(Personal Identification Number)を読み取って利用者により入力されたPINと照合したり、クレジットカードから読み取ったBIN(Bank Identification Number)コード等を、POS装置を介して提携クレジットカード会社サーバ200に送信したりする。POS装置は、クレジット決済端末と協働して決済額等の情報を提携クレジットカード会社サーバ200に送信する。クレジット処理端末55と提携クレジットカード会社サーバ200の間に、立替払取次業者サーバ(acquirer)が介在してもよい。以下では説明を簡略化するために、立替払取次業者サーバについての記述を省略する。提携カード57は、例えば、一般的に普及しているクレジットカードと同様の態様のものであり、通信チップがカード基材に埋め込まれたものである。通信チップはPINを記憶した記憶媒体を内蔵し、コンタクタ(或いは無線アンテナ)を介して外部装置と通信する。これに代えて、提携カード57は磁気カードであってもよい。
【0015】
第2店舗端末装置70は、加盟店の運営者によって使用される。第2店舗端末装置70は、スマートフォンやタブレット端末、パーソナルコンピュータ等である。第2店舗端末装置70では、加盟店向けインターフェース72が動作する。加盟店向けインターフェース72は、加盟店向けアプリであってもよいし、ブラウザであってもよい。加盟店向けインターフェース72は、加盟店の運営者によるクーポンの設定等を受け付け、決済サーバ100に送信する。スマートフォンである第2店舗端末装置70は、加盟店向けアプリを実行することで、店舗コード画像に相当するコード画像を表示したり、利用者端末装置10が表示するコード画像を読み取ったりする機能を有する。
【0016】
決済サーバ100は、利用者端末装置10または第1店舗端末装置50から受信した決済情報に基づいて電子決済を実現する。第1店舗端末装置50は、POS装置と加盟店サーバを含む場合があり、その場合、POS装置から加盟店サーバを介して決済情報が決済サーバ100に送信される。以下の説明では、これを特に区別せず、第1店舗端末装置50から決済情報が送信されるものとする。
【0017】
提携クレジットカード会社サーバ200は、電子決済サービスの一部である提携クレジットカード決済を管理する。提携クレジットカード会社サーバ200は、例えば、決済サーバ100のグループ会社(提携クレジットカード会社)によって運営される。提携クレジットカード会社は、チャージ残高にチャージするファンドソース(資金源)としてのクレジットカードを提供する外部クレジットカード会社とは別事業者であってよい。
【0018】
なお、提携クレジットカード会社サーバ200は、提携クレジットカード決済の要求があった場合、当該提携クレジットカードについて決済可能かどうかを確認するためにオーソリを実行する。提携クレジットカード会社サーバ200は、オーソリによって決済可能であることを確認できた場合に決済処理を実行し、決済可能であることが確認できなかった場合には当該決済要求に対して非承認を回答する。より具体的には、オーソリでは、決済金額が利用限度額の範囲内であることや、不正利用に該当しないことなどの確認が行われる。提携クレジットカード会社サーバ200は、提携カード57の不正利用を検知するための1以上のルールを不正検知ルールとして予め記憶しており、オーソリデータを不正検知ルールに照らし合わせることにより、当該オーソリに係るカード利用が不正利用か否かを判定する。
【0019】
管理者端末装置80は、提携クレジットカード会社サーバ200の管理者が不正検知ルールの運用状況や妥当性の確認、判断などを行うために使用する端末装置である。管理者端末装置80は、不正検知ルールの管理用のアプリケーションプログラムである管理アプリ82を実行することにより、管理者端末装置80の利用者(管理者)に不正検知ルールを判定するためのユーザインターフェースを提供する。例えば、管理アプリ82は、不正検知ルールの運用状況に関する情報を提携クレジットカード会社サーバ200から取得して表示するとともに不正検知ルールの変更操作を受け付け、変更内容を提携クレジットカード会社サーバ200に通知する。提携クレジットカード会社サーバ200は通知された変更内容を不正検知ルールに反映させる。なお、管理アプリ82は、専用アプリケーションとして構成されてもよいし、ウェブブラウザなどの汎用アプリケーションを用いて構成されてもよい。
【0020】
図2および図3は、電子決済の大まかな流れを例示したシーケンス図である。電子決済には、パターン1とパターン2の二つが存在してよい。
【0021】
図2に示すパターン1(以下、ユーザスキャンと称する)の場合、決済アプリ20が起動した状態の利用者端末装置10が、光学読取機能によって店舗コード画像60をデコードする(S1)。店舗コード画像60には、店舗URL(Uniform Resource Locator)の情報が含まれている。この店舗URLは、電子決済サービスのドメインに対して店舗を識別可能な情報が付加されたものであり、決済サーバ100において加盟店IDや店舗ID等との対応付けがなされている(後述)。決済アプリ20は、店舗URLとアカウントIDを含む第1決済情報を決済サーバ100に送信する(S2)。決済サーバ100は、店舗URLに対応する加盟店ID、店舗IDから、店舗情報(後述)を検索して加盟店名と店舗名の情報を取得し(S3)、決済アプリ20に送信する(S4)。利用者は、加盟店名や店舗名が表示された画面において、決済金額を利用者端末装置10に入力する(S5)。そして、利用者端末装置10は、少なくとも決済金額を含む第2決済情報を生成し、決済サーバ100に送信する(S6)。決済サーバ100は、受信した第2決済情報に基づいて電子決済を行う(S7)。そして、決済サーバ100は、決済完了通知(決済完了画面を表示するための情報)を決済アプリ20に送信し(S8)、決済アプリ20は決済完了画面を表示する(S9)。なお、店舗コード画像60が店舗に置かれたディスプレイによって表示される場合、店舗コード画像60には、店舗URLだけでなく決済金額の情報が含まれる場合がある。この場合、利用者が決済金額を入力する手順が省略され、第1決済情報に決済金額の情報が含められて決済サーバ100に送信される。加盟店名や店舗名の情報は、決済完了画面に含めて表示されてよい。
【0022】
図3に示すパターン2(以下、ストアスキャンと称する)の場合、決済アプリ20の起動時、決済アプリ20において支払う操作が行われたとき、自動更新のタイミング(例えば1分おき)になったとき、およびその他のタイミングで、決済アプリ20はワンタイムコードの発行要求を決済サーバ100に送信する(S11)。決済サーバ100はワンタイムコードを生成し(S12)、決済アプリ20に送信する(S13)。決済アプリ20は、ワンタイムコードに基づいて生成した、QRコードやバーコード等のコード画像を表示する(S14)。利用者は利用者端末装置10の表示面を第1店舗端末装置50に翳し(提示し)、第1店舗端末装置50は、光学読取機能によってコード画像をデコードし、ワンタイムコード等を取得する(S15)。そして、第1店舗端末装置50は、ワンタイムコード、決済金額、加盟店ID、店舗ID等を含む決済情報を生成し、決済サーバ100に送信する(S16)。決済金額の情報は、予めバーコード読み取りや手入力等によって取得されている。決済サーバ100は、受信した情報に基づいて、ワンタイムコードに対応する利用者を特定し、電子決済を行う(S17)。そして、決済サーバ100は、決済完了通知を決済アプリ20に送信し(S18)、決済アプリ20は決済完了画面を表示する(S19)。
【0023】
なお、上記のいずれか一方のみのパターンで電子決済が行われてもよい。また、図2で説明した「アカウントID」は、利用者の識別情報として用いられ得る他の情報(例えば電話番号)であってもよい。また、ストアスキャンにおいてワンタイムコードの発行が省略され、決済アプリ20は、利用者のアカウントIDに基づいて生成したコード画像を表示してもよい。その場合、決済サーバ100は、ワンタイムコードに対応する利用者を特定するのに代えて、アカウントIDに対応する利用者を特定する。
【0024】
[決済サーバ]
図4は、第1実施形態に係る決済サーバ100の構成図である。決済サーバ100は、例えば、通信部110と、決済コンテンツ提供部120と、決済処理部130と、情報管理部140と、記憶部170とを備える。通信部110および記憶部170以外の構成要素は、例えば、CPUなどのハードウェアプロセッサがプログラム(ソフトウェア)を実行することにより実現される。これらの構成要素のうち一部または全部は、LSI(Large Scale Integration)やASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)、GPU(Graphics Processing Unit)などのハードウェア(回路部;circuitryを含む)によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めHDD(Hard Disk Drive)やフラッシュメモリなどの記憶装置(非一過性の記憶媒体を備える記憶装置)に格納されていてもよいし、DVDやCD-ROMなどの着脱可能な記憶媒体(非一過性の記憶媒体)に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。
【0025】
記憶部170は、HDDやフラッシュメモリ、RAM(Random Access Memory)などである。記憶部170は、決済サーバ100がネットワークを介してアクセス可能なNAS(Network Attached Storage)装置であってもよい。記憶部170には、利用者情報172、決済コンテンツ情報174、加盟店/店舗情報176などの情報が格納される。
【0026】
通信部110は、ネットワークNWに接続するための通信インターフェースである。通信部110は、例えばネットワークインターフェースカードである。
【0027】
決済コンテンツ提供部120は、例えば、Webサーバの機能を有し、電子決済サービスの各種画面を表示するための情報(コンテンツ)を利用者端末装置10に提供する。決済コンテンツ提供部120は、決済コンテンツ情報174から適宜、必要なコンテンツを読み出して利用者端末装置10に提供する。利用者端末装置10は、決済アプリ20によってコンテンツが再生された状態で利用者による各種入力を受け付け、前述した決済情報などを決済サーバ100に送信する。
【0028】
決済処理部130は、利用者端末装置10または第1店舗端末装置50により送信された決済情報に基づいて、決済処理を行う。決済処理部130は、利用者情報172を参照しながら決済処理を行う。
【0029】
図5は、利用者情報172の内容の一例を示す図である。利用者情報172は、利用者の登録情報の一例である。利用者情報172は、例えば、利用者URL、アカウントID、電話番号、パスワードの他、メールアドレス、利用者ID、氏名・住所・生年月日、登録日、チャージ残高、後払い設定、後払い枠、後払い利用額、後払い利用可能額、端末決済方法、カード決済方法、提携カード番号、銀行口座、クレジットカード番号、チャージ履歴情報、決済履歴情報などの情報が対応付けられたものである。利用者URLは、利用者間の送金処理に使用される。電子決済サービスへの新規登録時には、電話番号およびパスワードの登録が必須となる。アカウントIDは、決済サーバ100によって利用者に発行されるものであり、利用者IDは、利用者が任意に設定できる(設定しなくてもよい)IDである。メールアドレス、および氏名・住所・生年月日も同様に、利用者が任意に設定できる(設定しなくてもよい)情報である。登録日とは利用者が電子決済サービスに登録した日(アカウントを作成した日)である。以下、これらの情報が対応付けられた利用者のインスタンス(電子決済口座)のことをアカウントと称する。
【0030】
チャージ残高は、利用者が予めアカウントに送金することで設定された電子マネーの残高を示す情報である。送金の手段としては、指定業者(銀行)のATM(Automatic Teller Machine)からの送金、登録された銀行口座からの送金などがある。後払い設定は、後払いによる電子決済を可能とするための設定が済んでいるか否かを示す情報であり、「済」と「未」のいずれかに設定される。後払い設定は、後述する「端末決済」と「カード決済」に共通するフラグ情報である。端末決済の後払いを利用可能な利用者は、提携カード57が渡されている利用者である。なお、これに代えて、後払い設定は「端末決済」と「カード決済」で別々に設定される設定情報であってもよい。端末決済方法は、「端末決済」において利用者がチャージ残高による電子決済を行うのか、後払いによる決済を行うのかを示す設定情報である。カード決済方法は、「カード決済」において利用者がチャージ残高による電子決済を行うのか、後払いによる決済を行うのかを示す設定情報である。カード決済方法については提携クレジットカード会社サーバ200との間でリアルタイム同期がなされる。提携カード番号は、提携カード57の番号(例えばPAN(Primary Account Number))である。銀行口座とクレジットカード番号のそれぞれは、電子決済サービスに入金可能な銀行口座またはクレジットカード番号の情報(口座番号、カード番号)である。このクレジットカード番号は、提携カード57とは別のクレジットカードの番号である。チャージ履歴情報は、利用者が予め電子決済サービスに送金してチャージ残高を増加させた履歴である。決済履歴情報は、利用者が行った決済の内訳(日時、購買行動が行われた店舗の店舗ID、決済金額、決済方法など)を、決済ごとに示す情報である。
【0031】
図6は、加盟店/店舗情報176の内容の一例を示す図である。加盟店/店舗情報176は、例えば、店舗URLに対して加盟店IDと店舗IDが対応付けられた第1テーブル176Aと、加盟店IDに対して加盟店名と売上金(前述)が対応付けられた第2テーブル176Bと、店舗IDに対して店舗IDが対応付けられた第3テーブル176Cとを含む。加盟店/店舗情報176には、これらの情報の他、加盟店または店舗のカテゴリ、店舗の所在地、決済パターン等の情報が含まれてもよい。
【0032】
情報管理部140は、利用者端末装置10や第2店舗端末装置70から取得した情報に基づいて、利用者情報172および加盟店/店舗情報176を管理する。情報管理部140は、利用者情報172および加盟店/店舗情報176について新規レコードの追加、編集、削除などを行う。
【0033】
ここで、端末決済とカード決済について説明する。図7は、端末決済とカード決済のそれぞれの処理を概念的に示す図である。以下に説明するように、電子決済サービスは、(1)端末決済/チャージ残高による支払い、(2)端末決済/後払いによる支払い、(3)カード決済/チャージ残高による支払い、(4)カード決済/後払いによる支払いの4パターンの電子決済を行うことができる。
【0034】
[端末決済]
(1)決済サーバ100(決済処理部130)が、利用者端末装置10または第1店舗端末装置50から決済情報を取得すると、端末決済が開始される。決済サーバ100は、利用者情報172を参照して当該利用者の「端末決済方法」を取得する。決済サーバ100は、「端末決済方法」が「チャージ残高」に設定されている利用者に関して、自身の処理によって電子決済を行う。この場合、決済処理部130が、利用者IDに対応付けて管理しているチャージ残高を減少させ、加盟店の売上金の項目値を増加させることで、電子決済を行う。加盟店の売上金の項目値は、例えば、それ自体が電子マネーとして使用されるものでは無く、加盟店と電子決済サービスとの取り決めに応じたサイクルで、売上金の項目値に対応する金額が銀行口座に送金される。
【0035】
(2)端末決済において決済サーバ100は、「端末決済方法」が「後払い」に設定されている利用者に関して、利用者情報172を参照して得られる当該利用者の提携カード番号と共に、決済情報を提携クレジットカード会社サーバ200に転送する。提携クレジットカード会社サーバ200は、決済情報の示す決済額の累計が当月の上限を超えていないかどうかを確認し、上限を超えていない場合は取得した決済額を当該利用者の決済額の累計に加算するなどの処理を行う。決済額の累計金額は、例えば、一か月分まとめて翌月の支払日に銀行口座からの引き落とし等によって決済される。
【0036】
[カード決済]
(3)提携クレジットカード会社サーバ200がクレジット処理端末55から決済情報を取得すると、提携カード57を用いた電子決済(カード決済)が開始される。提携クレジットカード会社サーバ200は、記憶部270に記憶させているカード決済設定情報272を参照する。図8は、カード決済設定情報272の内容の一例を示す図である。カード決済設定情報272は、利用者に固有の情報(例えばPAN)と、カード決済方法と、当該利用者のアカウントIDとが互いに対応付けられた情報である。カード決済方法およびアカウントIDは、図5の利用者情報172に含まれるものと同じ情報であり、決済サーバ100との間で同期連携がなされている。提携クレジットカード会社サーバ200は、「カード決済方法」が「チャージ残高」に設定されている利用者に関して、カード決済設定情報272を参照して得られる当該利用者のアカウントIDと共に、決済情報を決済サーバ100に転送する。決済サーバ100は、取得した決済情報に基づいて、端末決済において「端末決済方法」が「チャージ残高」に設定されている場合と同様の処理を行う。
【0037】
(4)カード決済において、提携クレジットカード会社サーバ200は、「カード決済方法」が「後払い」に設定されている利用者に関して、自身の処理によって電子決済を行う。この場合、提携クレジットカード会社サーバ200は、端末決済において「端末決済方法」が「後払い」に設定されている場合と同様の処理を行う。
【0038】
「端末決済」と「カード決済」のそれぞれにおける「チャージ残高」と「後払い」の切り替えは、決済アプリ20に対する利用者の操作に応じて行われる。決済アプリ20は、「端末決済」において「チャージ残高」と「後払い」のいずれかの決済方法(または他の決済方法)を選択するためのインターフェース画面と、「カード決済」において「チャージ残高」と「後払い」のいずれかの決済方法(または他の決済方法)を選択するためのインターフェース画面と、を別々に利用者に提供する。
【0039】
なお、「端末決済」および「カード決済」において、クレジットカードを使用する決済(本実施形態の例ではクレジットカード決済または後払いである)の実行が要求された場合、提携クレジットカード会社サーバ200は、クレジット処理端末55から当該クレジットカードの使用に関するオーソリデータを取得し、取得したオーソリデータを不正検知ルールに照らし合わせることにより、当該クレジットカードの利用が不正利用であるか否かを判定し、判定結果をクレジット処理端末55に応答する。クレジット処理端末55は、判定結果に応じて決済を続行したり、中止したりする。提携クレジットカード会社サーバ200は、クレジットカードを使用する決済が発生する都度このようなオーソリ判定処理を実行し、判定結果を記録し、蓄積していくものである。
【0040】
[提携クレジットカード会社サーバ]
図9は、第1実施形態に係る提携クレジットカード会社サーバ200の構成図である。提携クレジットカード会社サーバ200は、例えば、通信部210と、クレジット決済処理部230と、情報管理部240と、記憶部270とを備える。通信部210および記憶部270以外の構成要素は、例えば、CPUなどのハードウェアプロセッサがプログラム(ソフトウェア)を実行することにより実現される。これらの構成要素のうち一部または全部は、LSI(Large Scale Integration)やASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)、GPU(Graphics Processing Unit)などのハードウェア(回路部;circuitryを含む)によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めHDD(Hard Disk Drive)やフラッシュメモリなどの記憶装置(非一過性の記憶媒体を備える記憶装置)に格納されていてもよいし、DVDやCD-ROMなどの着脱可能な記憶媒体(非一過性の記憶媒体)に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。提携クレジットカード会社サーバ200は「決済管理装置」の一例である。
【0041】
通信部210は、ネットワークNWに接続するための通信インターフェースである。通信部210は、例えばネットワークインターフェースカードである。
【0042】
クレジット決済処理部230は、クレジット処理端末55または決済サーバ100から送信または転送された決済情報に基づいて、提携カード57によるクレジットカード払い向けの決済処理を実行する。より具体的には、クレジット決済処理部230は、クレジット処理端末55または決済サーバ100から決済要求を受けたことに応じてオーソリを実行し、オーソリの結果、対象利用者についてクレジットカードでの決済可能の利用が承認された場合に決済処理を実行するものである。クレジット決済処理部230は、実行したオーソリの内容を後述のオーソリ情報276に保存する。
【0043】
クレジット決済処理部230は、利用者情報274を参照しながら決済処理を行う。利用者情報274は、クレジットカードによる電子決済サービスに関する利用者の各種情報を利用者の識別情報に対応づけて管理する情報である。利用者情報274には、例えば、クレジットカード番号や銀行口座、取引履歴等の情報が含まれる。
【0044】
なお、提携クレジットカード会社サーバ200が、例えば、決済サーバ100のグループ会社(提携クレジットカード会社)によって運営される場合、提携クレジットカード会社サーバ200の利用者情報274は決済サーバ100が保持する利用者情報172と同じ内容を管理するものであってもよい。この場合、提携クレジットカード会社サーバ200が保持する利用者情報274と、決済サーバ100が保持する利用者情報172とは所定のタイミングで互いに同期されてもよい。
【0045】
記憶部270は、HDDやフラッシュメモリ、RAM(Random Access Memory)などである。記憶部270は、提携クレジットカード会社サーバ200がネットワークを介してアクセス可能なNAS(Network Attached Storage)装置であってもよい。記憶部270には、カード決済設定情報272、利用者情報274、オーソリ情報276、不正検知ルール278などの情報が格納される。
【0046】
図10は、オーソリ情報276の内容の一例を示す図である。オーソリ情報276は、提携クレジットカード会社サーバ200が過去に実行したオーソリに関する情報である。オーソリ情報276は、例えば、オーソリの識別情報であるオーソリIDに、決済要求が発生した時刻や、決済金額、加盟店ID、利用者ID、不正検知ルール278による判定結果などが対応づけられた情報である。オーソリIDは、例えば、提携クレジットカード会社サーバ200が決済要求を受け付けたタイミングで一意に割り当てられる。例えば、不正検知ルール278による判定結果の一例として、決済可否、および決済不可と判定された場合の適用ルールが保持され得る。オーソリ情報は「履歴情報」の一例である。
【0047】
図9に戻る。不正検知ルール278は、提携カード57の利用に係るオーソリデータに照らし、当該オーソリが提携カード57の不正利用によるものであるか否かを判定するために設定された1以上のルールである。不正検知ルール278は、不正利用であることを判定するためのルールを定めたものであってもよいし、不正利用でないことを判定するためのルールを定めたものであってもよい。例えば、紛失されたカードの不正利用に該当するルールの一例として「深夜のコンビニエンスストアで所定回数以上連続して使用された」ことなどが挙げられる。また、例えば、特定の不正な手口に該当するルールの一例として「店舗Aで利用後すぐに店舗Bで所定金額の支払いに利用された」ことなどが挙げられる。
【0048】
情報管理部240は、管理者端末装置80から取得した情報に基づいて、不正検知ルール278を管理する。例えば、情報管理部240は、管理者端末装置80の管理アプリ82を介して不正検知ルール278の編集操作を受け付け、不正検知ルール278に対し新規ルールの追加や、既存ルールの編集、削除などを行う。ここで、情報管理部240は「支援情報提供部」の一例である。
【0049】
情報管理部240は、不正検知ルール278の管理を支援するための支援情報を管理者に提供する。支援情報は、管理者が不正検知ルール278をメンテナンスする上で役に立つ情報であればどのような情報であってもよい。例えば、支援情報には、削除または変更することが推奨されるルールの提示や、その推奨の根拠、提示されたルールを削除または変更した場合に得られる効果などの情報が含まれてよい。
【0050】
[不正検知ルールのメンテナンス]
図11および図12は、不正検知ルール278に含まれる個々のルールについて、不正利用として検知された(ルールに違反した)オーソリの総数に対する不正オーソリの割合をルールの精度として提示する支援情報の一例を示す図である。ここで、「不正オーソリ」とは実際に不正利用が試みられたオーソリである。これに対し、実際には不正利用が試みられたオーソリではないにも関わらずルールにより不正利用として検知されてしまったオーソリを、以下では「真正オーソリ」ということにする。すなわち、個々のルールは、不正オーソリの数が多いほど適切に不正を阻止したということができる一方で、真正オーソリの数が多いほど不正利用の誤検知が多く正当なカード利用を阻害したということができる。換言すれば、不正オーソリの数が多く、または/および真正オーソリの数が少ないほど不正検知ルール278の精度が高いということができる。ここで、不正検知ルール276によって検知されたオーソリは「違反手続き」の一例である。不正オーソリは「不正手続き」の一例であり、真正オーソリは「真正手続き」の一例である。
【0051】
図11の例は、複数のルールA、ルールB、およびルールCを含む不正検知ルール278による不正利用検知の状況の一例を示すものである。ここでは、不正利用として検知されたオーソリのうち、1つのルールによって検知されたオーソリに着目し、それらを特に「シングルヒット」と言って区別する。図11は、不正検知ルール278により不正利用として検知されたオーソリの総数が12個の場合の例である。この例において、ルールA、ルールB、およびルールCはそれぞれ、6個のオーソリを検知し(一部重複有り)、そのうち2個がシングルヒットである。ここで、ルールAのシングルヒットはいずれも不正オーソリであり、これとは逆にルールBのシングルヒットはいずれも真正オーソリである。一方、ルールBのシングルヒットは、一方が真正オーソリであり、他方が不正オーソリである。
【0052】
図12は、図11の例の検知状況における各ルールの精度を示すものである。図11の例の検知状況において、ルールA、ルールB、およびルールCはいずれも、検知総数が6で、不正オーソリ数が3であるので、シングルヒットを区別せずに全体として見た場合の検知精度は50%である。そのため、このような簡易的な精度の評価方法では、ルールA、ルールB、およびルールCの間には精度の差が無いということになり、各ルールの優劣について有効な知見を得ることができない。しかしながら、図11の例では、真正阻害に関して、ルールCは単独で利用を阻害している真正オーソリ(すなわちシングルヒットの真正オーソリ)の数が多く、ルールAやルールBに比べて劣っているということができる。
【0053】
本実施形態では、このようなルールの優劣を適切に可視化するためにシングルヒットに着目して精度の評価を行うものである。具体的には、図11の例におけるシングルヒットの真正オーソリの数は、ルールAで0個、ルールBで1個、ルールCで2個である。すなわち、図11の例においてシングルヒットの真正オーソリに着目した場合の検知精度は、図12に示されるように、ルールAで100%、ルールBで50%と、ルールCで0%となる。このような情報が支援情報として管理者に提供されることにより、管理者は不正検知ルール278を見直すべきか否かの判断を適切に行うことができる。また、この結果、不正検知ルール278により、正当なカード利用が不正利用と誤って判定されてしまう状況を改善することができる。
【0054】
なお、図11は、オーソリ数に対する不正オーソリ数の割合を支援情報として提供する場合の例を示したものであるが、提携クレジットカード会社サーバ200は、これに代えて/加えて、オーソリ数に対する真正オーソリ数の割合を支援情報として提供するように構成されてもよい。また、提携クレジットカード会社サーバ200は、オーソリの数に対する不正オーソリの割合が所定の閾値(第1閾値)未満であるルールについて見直し(削除または変更)を推奨するように構成されてもよい。また、提携クレジットカード会社サーバ200は、オーソリ数に対する真正オーソリの割合が所定の閾値(第2閾値)未満であるルールについて見直し(削除または変更)を推奨するように構成されてもよい。
【0055】
また、シングルヒットに着目した検知精度をもとにした不正検知ルール278の改善を繰り返し行っていくことにより、シングルヒットでなく、且つ、真正オーソリを検知したルールが優先的に排除されていき、また、シングルヒットであり、且つ真正オーソリを検知しなかったルールが優先的に維持されていくことになる。その結果、不正検知ルール278において、より多くの不正オーソリを検知しつつ、誤検知したとしても真正オーソリを1つだけ検知するようなルールが多くなっていく。このため、管理者は、個々のルールを少ないオーソリの実績で評価することができるようになり、不正検知ルール278のメンテナンスをより簡単かつ適切に行うことができるようになる。
【0056】
従来は、管理者が個々のルールごとに、表計算ソフトなどを用いて実績を手作業で詳細に分析していたにも関わらずルールの精度が分析コストに見合うほど向上しない場合があった。これに対して、本実施形態によれば、シングルヒットに着目した支援情報を管理者に提供することができるので、管理者はルールごとに詳細な分析を行う必要がなくなるのに加え、より効果の高いメンテナンスを優先的に行うことができるようになる。
【0057】
なお、上記の実施形態では、提携カード57を提供する電子決済サービスの運営者が、提携カード57の利用時(決済時)に行うオーソリを想定して説明したが、上述した不正検知ルール278のメンテナンス方法は、オーソリに相当するような前処理によって事前に与信照会を行うような任意のシステムに適用可能である。例えば、本実施形態のメンテナンス方法は、一般的なクレジットカード会社システムにおけるオーソリに適用されてもよいし、チャージ残高や後払いによる電子決済を可能にするシステム(例えば本実施形態では決済サーバ100など)に適用されてもよい。
【0058】
[他の支援情報の例示]
上述のとおり、支援情報は、管理者が不正検知ルール278の見直しを行うのに役立つ情報であればよい。例えば、提携クレジットカード会社サーバ200(または管理アプリ82)は、以下の(1)~(4)に示すような情報を支援情報として提供するように構成されてもよい。
【0059】
(1)不正利用による被害額
例えば、提携クレジットカード会社サーバ200は、不正利用によって生じた被害額を管理者に提供してもよい。この場合、例えば、情報管理部240は、オーソリ情報276をもとに不正オーソリによって決済された金額を合算することによって提携カード57の不正利用による被害額を算出することができる。不正オーソリの検出精度に加えて/代えて、このような被害額の情報が提供されることにより、管理者は、検出精度に加えて/代えて被害の大きさを考慮して不正検知ルール278をメンテナンスすることができる。
【0060】
(2)真正オーソリ発生(真正阻害)による損失額
また、例えば、提携クレジットカード会社サーバ200は、真正オーソリの検知により、正当なカード利用が阻害されたこと(真正阻害)で生じた機会損失の額を管理者に提供してもよい。この場合、例えば、情報管理部240は、オーソリ情報276をもとに真正オーソリで実施されるはずであった決済の金額を合算することによって真正阻害による損失額を算出することができる。不正オーソリの検出精度に加えて/代えて、このような損失額の情報が提供されることにより、管理者は、検出精度に加えて/代えて機会損失の大きさを考慮して不正検知ルール278をメンテナンスすることができる。
【0061】
(3)ルールを削除した場合の効果のシミュレーション結果
また、例えば、提携クレジットカード会社サーバ200は、特定のルールを削除した状況をシミュレーションした結果をもとに支援情報を提供してもよい。特定のルールは、管理者が指定したルールであってもよいし、精度や被害額、損失額等に基づいて削除が推奨されると認識されたルールであってもよい。例えば、情報管理部240は、オーソリ情報276に含まれる情報のうち削除対象のルールに該当しないオーソリの情報を用いて各種情報を計算することにより、ルールを削除した場合の状況をシミュレーションすることができる。情報管理部240は、シミュレーション結果を支援情報(オーソリ数、不正オーソリ数、精度、被害額、損失額など)としてもよいし、シミュレーション結果により認識される状況の変化を支援情報としてもよい。
【0062】
(4)ルールのパラメータを変更した場合の効果のシミュレーション結果
また、例えば、提携クレジットカード会社サーバ200は、閾値等のパラメータを含むルールについて、特定のパラメータ値を変更した状況をシミュレーションした結果をもとに支援情報を提供してもよい。特定のパラメータは、管理者が指定したパラメータであってもよいし、精度や被害額、損失額等に基づいて変更が推奨されると認識されたルールであってもよい。例えば、情報管理部240は、パラメータ変更後のルールに基づいてオーソリ情報276を評価することにより、特定のパラメータを変更した場合の状況をシミュレーションすることができる。情報管理部240は、シミュレーション結果を支援情報(オーソリ数、不正オーソリ数、精度、被害額、損失額など)としてもよいし、シミュレーション結果により認識される状況の変化を支援情報としてもよい。
【0063】
以上説明した実施形態によれば、クレジットカードなど、利用時に当該決済の正当性を確認する手続きを伴う電子決済において、正当な利用を不正利用と誤って判定してしまう状況を改善することができる。
【0064】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【0065】
10…利用者端末装置、20…決済アプリ、50…第1店舗端末装置、55…クレジット処理端末、57…提携カード、60…店舗コード画像、70…第2店舗端末装置、72…加盟店向けインターフェース、80…管理者端末装置、82…管理アプリ、100…決済サーバ、110…通信部、120…決済コンテンツ提供部、130…決済処理部、140…情報管理部、170…記憶部、172…利用者情報、174…決済コンテンツ情報、176…店舗情報、200…提携クレジットカード会社サーバ、210…通信部、230…クレジット決済処理部、240…情報管理部、270…記憶部、272…カード決済設定情報、274…利用者情報、276…オーソリ情報、278…不正検知ルール
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12