JP7841175B1 - 決済管理装置、決済管理方法、およびプログラム - Google Patents

Abstract

【課題】電子決済の不正利用が検知された利用者に対して一定の利用制限を設ける不正利用検知システムにおいて、当該利用制限の解除に係る手間を軽減すること。【解決手段】利用者の決済アプリから受信される決済要求に応じて決済処理を実行する決済処理部と、前記決済要求が不正利用を目的としたものであるか否かを判定する不正利用検知部と、前記不正利用検知部により不正利用によるものと判定された決済要求である被疑要求に応じて、前記利用者の決済アプリについて機能制限を行う機能制限部と、前記被疑要求に関して前記利用者の申告情報および本人確認の結果に基づいて前記機能制限を解除するか否かを判定する制限解除部と、前記制限解除部における判定結果に基づき、前記利用者の決済アプリの操作履歴を一定の監視期間において監視し、前記監視期間における操作内容に応じて機能制限の解除又は強化を制御するモニタリング制御部と、を備える決済管理装置。【選択図】図１

Description

本発明は、決済管理装置、決済管理方法、およびプログラムに関する。

従来、クレジットカードの利用時におけるオーソリデータ（オーソリゼーションデータ；クレジットカードの所有者や決済を要求する金額など店舗等から送信されたデータ）を用いて、クレジットカードの不正利用を検知する技術が知られている。例えば、特許文献１には、オーソリデータに付加された履歴情報を用いて、クレジットカードによる決済の要求が不正利用によるものか否かを判定する技術が開示されている。（特許文献１参照）。

特開２００４－３４８５３６号公報

一方、正当な利用者であっても、クレジット決済の状況がたまたま不正条件に合致してしまいクレジットカードの利用が制限されてしまう場合がある。この場合、正当な利用者は、クレジットカード会社に問い合わせて本人確認をしたり、当該クレジット決済が自身の利用によるものであることを説明したりすることで、利用制限を解除してもらうことができる。

しかしながら、このような流れでクレジットカードの利用制限が解除されるまでには長い時間（例えば数日間）がかかる場合があった。また、ＥＣサイトでは、クレジット決済が不正と判定された場合、その利用者は商品購入を完了せずにサイトを離脱する（いわゆるカゴ落ち）可能性が高いことが知られている。

このように、従来技術によるクレジット決済の不正判定では、利用制限の解除に手間がかかってしまう場合があることから、利用者および商品販売者の双方にとって機会損失を生じてしまう可能性があった。

本発明は、このような事情を考慮してなされたものであり、電子決済の不正利用が検知された利用者に対して一定の利用制限を設ける不正利用検知システムにおいて、当該利用制限の解除に係る手間を軽減することができる決済管理装置、決済管理方法、およびプログラムを提供することを目的の一つとする。

本発明の一態様は、利用者の端末装置で動作する決済アプリと協働して前記利用者に電子決済サービスを提供する決済管理装置であって、前記決済アプリから受信される決済要求に応じて当該決済要求に係る決済処理を実行する決済処理部と、前記決済要求が不正利用を目的としたものであるか否かを判定する不正利用検知部と、前記不正利用検知部により不正利用によるものと判定された決済要求である被疑要求に応じて、前記利用者の決済アプリについて機能制限を行う機能制限部と、前記被疑要求に関して前記利用者の申告情報および本人確認の結果に基づいて前記機能制限を解除するか否かを判定する制限解除部と、前記制限解除部における判定結果に基づき、前記利用者の決済アプリの操作履歴を一定の監視期間において監視し、前記監視期間における操作内容に応じて機能制限の解除又は強化を制御するモニタリング制御部と、を備える決済管理装置である。

本発明の一態様によれば、電子決済の不正利用が検知された利用者に対して一定の利用制限を設ける不正利用検知システムにおいて、当該利用制限の解除に係る手間を軽減することができる。

電子決済サービスが実現されるための構成の一例を示す図である。 電子決済の大まかな流れを例示したシーケンス図（その１）である。 電子決済の大まかな流れを例示したシーケンス図（その２）である。 第１実施形態に係る決済サーバ１００の構成図である。 利用者情報１７２の内容の一例を示す図である。 加盟店／店舗情報１７６の内容の一例を示す図である。 決済サーバ１００が、クレジット払いの際に、クレジットカード会社サーバ２００と協働して実施する処理の流れの一例を示すシーケンスチャート（その１）である。 決済サーバ１００が、クレジット払いの際に、クレジットカード会社サーバ２００と協働して実施する処理の流れの一例を示すシーケンスチャート（その２）である。 決済サーバ１００が、不正利用検知に伴う機能制限に関して実施する処理の流れの一例を示すフローチャートである。 決済アプリ２０を用いた機能制限解除の流れの一例を示す図である。

以下、図面を参照し、本発明の決済管理装置、決済管理方法、およびプログラムの実施形態について説明する。以下に登場する「サーバ」、「管理装置」「情報提供装置」などの、利用者にサービスを提供したり内部解析を行ったりするための各種装置は、分散化された装置群によって実現されてよく、それぞれの装置を運用する事業者は異なってもよい。また装置のハードウェアの保有者（クラウドサーバの提供者）と実質的な運用を行う事業者も異なってよい。アプリケーションプログラムと決済サーバは、協働して電子決済サービスを提供する。以下の説明ではアプリケーションプログラムを決済アプリと称する。電子決済サービスは、店舗における商品やサービスの購買に係る決済をサポートするサービスである。店舗とは、例えば、現実空間に存在する物理的な店舗（実店舗）であるが、電子商取引の仮想店舗を含んでもよい。仮想店舗は、電子決済サービスの運営者とは異なる主体によって提供されるものを含んでもよい。その場合、仮想店舗における買い物の決済の際に、電子決済サービスのインターフェース画面に遷移するように制御されてもよい。電子決済サービスにおいて、店舗は、例えば加盟店（ブランド）に属するものとして扱われ、店舗において購買行動が行われた際の決済などの処理は、主として利用者と加盟店の間で行われる。これに代えて、決済などの処理が利用者と店舗との間で行われてもよい。

［電子決済サービス］
図１は、電子決済サービスが実現されるための構成の一例を示す図である。電子決済サービスは、決済サーバ１００を中心として実現される。決済サーバ１００は、例えば、一以上の利用者端末装置１０、一以上の第１店舗端末装置５０、及び一以上の第２店舗端末装置７０のそれぞれとネットワークＮＷを介して通信する。また、決済サーバ１００は、クレジットカード会社サーバ２００とネットワークＮＷを介して通信可能である。ネットワークＮＷは、例えば、インターネット、ＬＡＮ（Local Area Network）、無線基地局、プロバイダ装置などを含む。

利用者端末装置１０は、例えば、スマートフォンやタブレット端末等の可搬型端末装置である。利用者端末装置１０は、少なくとも、光学読取機能、通信機能、表示機能、入力受付機能、プログラム実行機能を有するコンピュータ装置である。以下の説明では、これらの機能を実現するための構成をそれぞれカメラ、通信装置、タッチパネル、ＣＰＵ（Central Processing Unit）等と称する。利用者端末装置１０では、ＣＰＵ等のプロセッサにより決済アプリ２０が実行されることで、決済サーバ１００と連携して電子決済サービスを利用者に提供するように動作する。決済アプリ２０は、例えば、アプリケーションストアから利用者端末装置１０にインストールされ、カメラ、通信装置、タッチパネルなどを制御する。

第１店舗端末装置５０は、例えば、店舗に設置される。第１店舗端末装置５０は、少なくとも、商品価格取得機能、光学読取機能、プログラム実行機能、通信機能を有するコンピュータ装置である。第１店舗端末装置５０は、いわゆるＰＯＳ（Point of Sale）装置を含み、ＰＯＳ装置によって商品価格取得機能や光学読取機能を実現してもよい。店舗コード画像６０は、店舗に置かれ、ＱＲコード（登録商標）等のコード画像が紙やプラスチックの媒体に印刷されたものである。なお、店舗コード画像６０は、店舗に置かれたディスプレイ（スマートフォンなどの端末装置のディスプレイでもよい）によって表示されてもよい。

第２店舗端末装置７０は、加盟店の運営者によって使用される。第２店舗端末装置７０は、スマートフォンやタブレット端末、パーソナルコンピュータ等である。第２店舗端末装置７０では、加盟店向けインターフェース７２が動作する。加盟店向けインターフェース７２は、加盟店向けアプリであってもよいし、ブラウザであってもよい。加盟店向けインターフェース７２は、加盟店の運営者によるクーポンの設定等を受け付け、決済サーバ１００に送信する。スマートフォンである第２店舗端末装置７０は、加盟店向けアプリを実行することで、店舗コード画像に相当するコード画像を表示したり、利用者端末装置１０が表示するコード画像を読み取ったりする機能を有する。

決済サーバ１００は、利用者端末装置１０または第１店舗端末装置５０から受信した決済情報に基づいて電子決済を実現する。第１店舗端末装置５０は、ＰＯＳ装置と加盟店サーバを含む場合があり、その場合、ＰＯＳ装置から加盟店サーバを介して決済情報が決済サーバ１００に送信される。以下の説明では、これを特に区別せず、第１店舗端末装置５０から決済情報が送信されるものとする。

クレジットカード会社サーバ２００は、決済アプリ２０の利用者が所有するクレジットカードの発行会社（クレジットカード会社）が運営するサーバであり、当該クレジットカードを用いた電子決済（クレジット決済）を実現するための処理（クレジット決済処理）を行うサーバである。より具体的には、クレジットカード会社サーバ２００は、クレジットカードを用いた電子決済の際に受信されるオーソリ電文の内容に基づいてクレジット決済処理を行う。オーソリ電文は、クレジットカードの使用時において、カードの有効性確認（Authorization）のためにクレジットカード会社サーバ２００に送信される電文であり、支払い先の店舗や決済金額、利用者の識別情報等の決済に必要な情報（決済情報）が含まれる。クレジットカードの現物を用いた決済の場合、店舗等に設置された専用端末がカード情報を読み取ってオーソリ電文を生成し、生成したオーソリ電文をクレジットカード会社サーバ２００に送信する。一方、決済アプリ２０を介したクレジット決済の場合、決済アプリ２０から決済要求を受けた決済サーバ１００がオーソリ電文を生成してクレジットカード会社サーバ２００に送信する。

図２および図３は、電子決済の大まかな流れを例示したシーケンス図である。電子決済には、パターン１とパターン２の二つが存在してよい。

図２に示すパターン１（以下、ユーザスキャンと称する）の場合、決済アプリ２０が起動した状態の利用者端末装置１０が、光学読取機能によって店舗コード画像６０をデコードする（Ｓ１）。店舗コード画像６０には、店舗ＵＲＬ（Uniform Resource Locator）の情報が含まれている。この店舗ＵＲＬは、電子決済サービスのドメインに対して店舗を識別可能な情報が付加されたものであり、決済サーバ１００において加盟店ＩＤや店舗ＩＤ等との対応付けがなされている（後述）。決済アプリ２０は、店舗ＵＲＬとアカウントＩＤを含む第１決済情報を決済サーバ１００に送信する（Ｓ２）。決済サーバ１００は、店舗ＵＲＬに対応する加盟店ＩＤ、店舗ＩＤから、店舗情報（後述）を検索して加盟店名と店舗名の情報を取得し（Ｓ３）、決済アプリ２０に送信する（Ｓ４）。利用者は、加盟店名や店舗名が表示された画面において、決済金額を利用者端末装置１０に入力する（Ｓ５）。そして、利用者端末装置１０は、少なくとも決済金額を含む第２決済情報を生成し、決済サーバ１００に送信する（Ｓ６）。決済サーバ１００は、受信した第２決済情報に基づいて電子決済を行う（Ｓ７）。そして、決済サーバ１００は、決済完了通知（決済完了画面を表示するための情報）を決済アプリ２０に送信し（Ｓ８）、決済アプリ２０は決済完了画面を表示する（Ｓ９）。なお、店舗コード画像６０が店舗に置かれたディスプレイによって表示される場合、店舗コード画像６０には、店舗ＵＲＬだけでなく決済金額の情報が含まれる場合がある。この場合、利用者が決済金額を入力する手順が省略され、第１決済情報に決済金額の情報が含められて決済サーバ１００に送信される。加盟店名や店舗名の情報は、決済完了画面に含めて表示されてよい。

図３に示すパターン２（以下、ストアスキャンと称する）の場合、決済アプリ２０の起動時、決済アプリ２０において支払う操作が行われたとき、自動更新のタイミング（例えば１分おき）になったとき、およびその他のタイミングで、決済アプリ２０はワンタイムコードの発行要求を決済サーバ１００に送信する（Ｓ１１）。決済サーバ１００はワンタイムコードを生成し（Ｓ１２）、決済アプリ２０に送信する（Ｓ１３）。決済アプリ２０は、ワンタイムコードに基づいて生成した、ＱＲコードやバーコード等のコード画像を表示する（Ｓ１４）。利用者は利用者端末装置１０の表示面を第１店舗端末装置５０に翳し（提示し）、第１店舗端末装置５０は、光学読取機能によってコード画像をデコードし、ワンタイムコード等を取得する（Ｓ１５）。そして、第１店舗端末装置５０は、ワンタイムコード、決済金額、加盟店ＩＤ、店舗ＩＤ等を含む決済情報を生成し、決済サーバ１００に送信する（Ｓ１６）。決済金額の情報は、予めバーコード読み取りや手入力等によって取得されている。決済サーバ１００は、受信した情報に基づいて、ワンタイムコードに対応する利用者を特定し、電子決済を行う（Ｓ１７）。そして、決済サーバ１００は、決済完了通知を決済アプリ２０に送信し（Ｓ１８）、決済アプリ２０は決済完了画面を表示する（Ｓ１９）。

なお、上記のいずれか一方のみのパターンで電子決済が行われてもよい。また、図２で説明した「アカウントＩＤ」は、利用者の識別情報として用いられ得る他の情報（例えば電話番号）であってもよい。また、ストアスキャンにおいてワンタイムコードの発行が省略され、決済アプリ２０は、利用者のアカウントＩＤに基づいて生成したコード画像を表示してもよい。その場合、決済サーバ１００は、ワンタイムコードに対応する利用者を特定するのに代えて、アカウントＩＤに対応する利用者を特定する。

［決済サーバ］
図４は、第１実施形態に係る決済サーバ１００の構成図である。決済サーバ１００は、例えば、通信部１１０と、決済コンテンツ提供部１２０と、決済処理部１３０と、情報管理部１４０と、情報処理部１５０と、記憶部１７０とを備える。通信部１１０および記憶部１７０以外の構成要素は、例えば、ＣＰＵなどのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。

記憶部１７０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）などである。記憶部１７０は、決済サーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）装置であってもよい。記憶部１７０には、利用者情報１７２、決済コンテンツ情報１７４、加盟店／店舗情報１７６、不正検知ルール１７８などの情報が格納される。

通信部１１０は、ネットワークＮＷに接続するための通信インターフェースである。通信部１１０は、例えばネットワークインターフェースカードである。

決済コンテンツ提供部１２０は、例えば、Ｗｅｂサーバの機能を有し、電子決済サービスの各種画面を表示するための情報（コンテンツ）を利用者端末装置１０に提供する。決済コンテンツ提供部１２０は、決済コンテンツ情報１７４から適宜、必要なコンテンツを読み出して利用者端末装置１０に提供する。利用者端末装置１０は、決済アプリ２０によってコンテンツが再生された状態で利用者による各種入力を受け付け、前述した決済情報などを決済サーバ１００に送信する。

決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０により送信された決済情報に基づいて、決済処理を行う。決済処理部１３０は、利用者情報１７２を参照しながら決済処理を行う。

図５は、利用者情報１７２の内容の一例を示す図である。利用者情報１７２は、利用者の登録情報の一例である。利用者情報１７２は、例えば、利用者ＵＲＬ、アカウントＩＤ、電話番号、パスワードの他、メールアドレス、利用者ＩＤ、氏名・住所・生年月日、登録日、チャージ残高、クレジット払い設定、クレジット払い枠、クレジット払い利用額、クレジット払い利用可能額、決済方法設定、銀行口座、クレジットカード番号、チャージ履歴情報、決済履歴情報、利用制限情報などの情報が対応付けられたものである。利用者ＵＲＬは、利用者間の送金処理に使用される。電子決済サービスへの新規登録時には、電話番号およびパスワードの登録が必須となる。アカウントＩＤは、決済サーバ１００によって利用者に発行されるものであり、利用者ＩＤは、利用者が任意に設定できる（設定しなくてもよい）ＩＤである。メールアドレス、および氏名・住所・生年月日も同様に、利用者が任意に設定できる（設定しなくてもよい）情報である。登録日とは利用者が電子決済サービスに登録した日（アカウントを作成した日）である。以下、これらの情報が対応付けられた利用者のインスタンス（電子決済口座）のことをアカウントと称する。

チャージ残高は、利用者が予めアカウントに送金することで設定された電子マネーの残高を示す情報である。送金の手段としては、指定業者（銀行）のＡＴＭ（Automatic Teller Machine）からの送金、登録された銀行口座からの送金などがある。クレジット払い設定は、クレジット払いによる電子決済を可能とするための設定が済んでいるか否かを示す情報であり、「済」と「未」のいずれかに設定される。クレジット払い枠は月ごとに利用可能なクレジット払いの限度額であり、クレジット払い利用額は、当月に既に利用されたクレジット払いの金額であり、クレジット払い利用可能額は、クレジット払い枠からクレジット払い利用額を差し引いて求められる、当月に利用可能なクレジット払いの金額である。図ではクレジット払い枠を一つだけ示しているが、実際には更に日ごとの上限額などが存在し、それらの低い方がクレジット払い枠に設定されてよい。クレジット払いの更なる詳細については後述する。決済方法設定は、その時点において利用者がチャージ残高による電子決済を行うのか、クレジット払いによる決済を行うのかを示す設定情報である。銀行口座とクレジットカード番号のそれぞれは、電子決済サービスに入金可能な銀行口座またはクレジットカード番号の情報（口座番号、カード番号）である。チャージ履歴情報は、利用者が予め電子決済サービスに送金してチャージ残高を増加させた履歴である。決済履歴情報は、利用者が行った決済の内訳（日時、購買行動が行われた店舗の店舗ＩＤ、決済金額、決済方法など）を、決済ごとに示す情報である。

利用制限情報は、決済アプリ２０の不正利用が検知された利用者について、決済アプリ２０の使用を制限するための設定情報である。利用制限情報には、例えば、利用制限の有無（制限有無）、利用が制限される機能の範囲（制限範囲）、利用制限が実施される期間（制限期間）などの情報が含まれる。利用制限情報は、不正利用が検知されたタイミングや、利用制限の解除条件が満たされたタイミング等、必要なタイミングにおいて、適宜状況に応じた内容に更新されるものである。

図６は、加盟店／店舗情報１７６の内容の一例を示す図である。加盟店／店舗情報１７６は、例えば、店舗ＵＲＬに対して加盟店ＩＤと店舗ＩＤが対応付けられた第１テーブル１７６Ａと、加盟店ＩＤに対して加盟店名と売上金（前述）が対応付けられた第２テーブル１７６Ｂと、店舗ＩＤに対して店舗名が対応付けられた第３テーブル１７６Ｃとを含む。加盟店／店舗情報１７６には、これらの情報の他、加盟店または店舗のカテゴリ、店舗の所在地、決済パターン等の情報が含まれてもよい。

情報管理部１４０は、利用者端末装置１０や第２店舗端末装置７０から取得した情報に基づいて、利用者情報１７２および加盟店／店舗情報１７６を管理する。情報管理部１４０は、利用者情報１７２および加盟店／店舗情報１７６について新規レコードの追加、編集、削除などを行う。

［電子決済］
決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０から決済情報が取得されると、利用者情報１７２を参照して当該利用者の「決済方法設定」を取得する。決済処理部１３０は、「決済方法設定」が「チャージ残高」に設定されている利用者に関して、以下のように電子決済を行う。決済処理部１３０は、例えば、利用者ＩＤに対応付けて管理しているチャージ残高を減少させ、加盟店の売上金の項目値を増加させることで、電子決済を行う。加盟店の売上金の項目値は、例えば、それ自体が電子マネーとして使用されるものでは無く、加盟店と電子決済サービスとの取り決めに応じたサイクルで、売上金の項目値に対応する金額が銀行口座に送金される。

決済処理部１３０は、「設定情報」が「クレジット払い」に設定されている利用者に関して、以下のように電子決済を行う。クレジット払いとは、電子決済サービスの運営者とは別主体であるクレジットカード会社との連携による支払い方法であり、電子決済サービスの運営者が与信者となって、クレジット払い枠の範囲内でチャージ残高に依存しない電子決済を許容するものである。なおクレジット払いサービスを受けるために、電子決済サービスの運営者が提供するクレジットカードの取得が要求されてよい。クレジット払いで利用された金額は、一か月分まとめて翌月の支払日に、例えば銀行口座からの引き落としによって決済される。この場合、決済処理部１３０は、クレジット払い利用額に決済金額を加算し、クレジット払い利用可能額から同額を差し引くことで暫定決済を行い、締め日になると上記のように当月分の決済を翌月の支払い日に引き落とすための処理を行う、或いはクレジットカード会社の運営者に当該処理を依頼する。なお暫定決済の時点で決済金額がクレジット払い利用可能額を超える場合は、エラー通知が決済アプリ２０に返信される。

［決済アプリの不正利用検知］
上述のとおり、本実施形態の電子決済サービスでは、決済アプリ２０を使用した決済手段としてチャージ残高による残高払いやクレジットカードによるクレジット払いが使用可能である。このような電子決済サービスは、決済アプリ２０から手軽に利用できるので利用者にとって利便性が高い一方で、フィッシングやスキミング等の手口によって不正利用される可能性がある。そこで、実施形態の電子決済サービスは、決済アプリ２０の利用を監視して電子決済サービスの不正利用を検知する機能（不正利用検知機能）を有する。不正利用検知機能は、情報処理部１５０によって実現される。

情報処理部１５０は、決済アプリ２０の不正利用を検知するとともに、不正利用が検知された利用者に関する各種処理を実行する機能部である。より具体的には、情報処理部１５０は、例えば、不正検知部１５１と、機能制限部１５２と、制限解除部１５３とを備える。

不正検知部１５１は、決済アプリ２０による決済要求が発生した場合に、当該決済要求の発生状況を予め記憶部１７０に記憶されている不正検知ルール１７８と照らし合わせることで、当該決済要求が不正利用を目的としたものであるか否かを判定する。

機能制限部１５２は、不正検知部１５１によって不正利用が検知された決済アプリ２０の利用者について、決済アプリ２０の利用を制限する処理を行う。機能制限部１５２は、決済アプリ２０の不正利用が検知された状況に応じて、制限する機能の範囲や制限期間などを変更するように構成されてもよい。例えば、機能制限部１５２は、チャージ残高を使用した支払い（チャージ残高払い）の機能に加えて、チャージ残高を使用した送金等の機能を制限してもよい。また、例えば、機能制限部１５２は、クレジットカードを使用した支払い（クレジット払い）の機能に加えて、クレジットカードを使用したチャージや送金等の機能を制限してもよい。なお、本実施形態において、決済アプリ２０により提供される支払いやチャージ、送金等の機能は電子決済サービスにおいて利用者が使用可能な「決済機能」の一例である。

制限解除部１５３は、不正利用が検知されたことで決済アプリ２０の利用が制限された利用者について、不正利用と判定された決済要求が利用者本人によるものであることが確認された場合に、当該利用者に対する機能制限を解除する処理を行う。より具体的には、制限解除部１５３は、確認対象の決済要求について、利用者から不正利用でないことが申告され、且つ当該利用者の本人確認に成功した場合に、機能制限を解除する。

図７および図８は、本実施形態の決済サーバ１００が、クレジット払いの決済要求を受け付けた場合に、クレジットカード会社サーバ２００と協働して実施する処理の流れの一例を示すシーケンスチャートである。図７はユーザスキャンの場合の流れを示し、図８はストアスキャンの場合の流れを示す。いずれの場合も、クレジットカード会社サーバ２００と連携して電子決済を行う点は異なるものの、それ以外の部分については図２および図３の場合と同様である。

［不正検知無しの場合］
図７のユーザスキャンのフローでは、決済アプリ２０が第２決済情報を決済サーバ１００に送信すると（Ｓ６）、決済サーバ１００が第２決済情報をもとに電子決済を実行する（Ｓ７）。ここで、決済方法設定が「クレジット払い」に設定されている場合、決済サーバ１００は、クレジットカード会社サーバ２００と協働してクレジット決済処理を実行する（Ｓ７１～Ｓ７５）。

より具体的には、まず、決済サーバ１００において、不正検知部１５１が、クレジットカードを用いた決済の要求（以下「クレジット決済要求」という。）について不正利用検知を試行する（Ｓ７１）。ここでは、不正検知部１５１は、まず利用者情報１７２を参照して、発生した決済要求に適用される決済方法を認識する。ここで、適用すべき決済方法がクレジット払いであることが認識されると、続いて、不正検知部１５１は、不正検知ルール１７８に基づいて、対象のクレジット決済要求が被疑要求に該当するか否かを判定する。被疑要求とは、クレジットカードの不正利用を目的としたものであることが疑われるクレジット決済要求である。ここで、対象のクレジット決済要求が被疑要求でないと判定された場合、決済処理部１３０が、クレジット決済に関する決済情報を通知するための通常のオーソリ電文（以下「第１オーソリ電文」という。）をクレジットカード会社サーバ２００に送信する（Ｓ７２）。

クレジットカード会社サーバ２００は、ステップＳ７２で受信された第１オーソリ電文に基づいてオーソリ処理を実行する（Ｓ７３）。オーソリ処理は、クレジット決済の利用可能性を確認する処理であり、クレジットカードの有効性を確認する処理や、不正利用を検知する処理、利用可能額を確認する処理などが含まれる。なお、オーソリ処理における不正利用検知は、決済サーバ１００の不正検知部１５１と同様の方法でクレジットカードの不正利用を検知するものであってもよいし、クレジットカード会社独自の方法で不正利用を検知するものであってもよい。クレジットカード会社サーバ２００は、オーソリ処理によって対象のクレジット決済要求について、クレジット決済が利用可能であることが確認された場合、第１オーソリ電文に含まれる決済情報に基づいてクレジット決済処理を実行し（Ｓ７４）、処理結果を決済サーバ１００に応答する（Ｓ７５）。

［不正検知有りの場合］
図８のストアスキャンのフローでは、第１店舗端末装置５０が決済情報を決済サーバ１００に送信すると（Ｓ１６）、決済サーバ１００がステップＳ１６で受信した決済情報をもとに電子決済を実行する（Ｓ１７）。ここで、決済方法設定が「クレジット払い」に設定されている場合、決済サーバ１００は、クレジットカード会社サーバ２００と協働してクレジット決済処理を実行するが、不正利用検知により決済が中止される（Ｓ１７１～Ｓ１７６）。

より具体的には、まず、決済サーバ１００において、不正検知部１５１が、Ｓ７１同様に、発生したクレジット決済要求について不正利用検知を試行する（Ｓ１７１）。ここで、対象のクレジット決済要求が被疑要求であると判定された場合、決済処理部１３０が、決済アプリ２０に対して決済エラーを通知して（Ｓ１７２）、電子決済を中止する。この場合、決済アプリ２０は、決済エラーを表示する（Ｓ１７３）

この際、機能制限部１５２が、対象の利用者について電子決済サービスで利用可能な機能の一部または全部を制限する一方で（Ｓ１７４）、不正検知部１５１は、不正利用の判定結果を通知するための専用のオーソリ電文（第２オーソリ電文）を生成してクレジットカード会社サーバ２００に送信する（Ｓ１７５）。

一般に、オーソリ電文は、クレジットカード会社サーバ２００に対して所定金額の決済を指示する目的で使用されるものである。一方で、第２オーソリ電文は、通知専用のオーソリ電文である。このため、機能制限部１５２は、利用者に負担させない形で所定金額の決済を指示するオーソリ電文を第２オーソリ電文として送信する。例えば、所定金額は０円や１円などであってよい。

クレジットカード会社サーバ２００は、ステップＳ１７５で受信された第２オーソリ電文により、決済サーバ１００側の不正利用検知における判定結果を認識することができる（Ｓ１７６）。なお、クレジットカード会社サーバ２００は、ステップＳ１７６において、認識した判定結果に応じた処理を行うように構成されてもよい。例えば、クレジットカード会社サーバ２００は、判定結果をもとにクレジットカードの利用制限を行うように構成されてもよい。また、クレジットカード会社側で自前の不正利用検知を行っている場合には、決済サーバ１００側の判定結果をクレジットカード会社サーバ２００側の不正検知ルールに組み込んで、不正利用検知を行うように構成されてもよい。

ここでは説明の便宜上、図７の場合（ユーザスキャン）において不正利用が検知されなかった場合の流れを説明し、図８の場合（ストアスキャン）において不正利用が検知された場合の流れを説明したが、電子決済（クレジット決済）の処理自体はスキャン方式によらず共通である。すなわち、ユーザスキャン（図７）において不正利用が検知された場合、第１オーソリ電文の送信（Ｓ７２）に加えて／代えて、図８と同様の第２オーソリ電文によって不正利用の検知がクレジットカード会社サーバ２００に通知されてよい。また、ストアスキャン（図８）において不正利用が検知されなかった場合、第２オーソリ電文の送信（Ｓ１７５）に代えて、図７と同様の第１オーソリ電文によって決済情報がクレジットカード会社サーバ２００に通知されてよい。

また、ここでは説明の便宜上、決済方法設定が「クレジット払い」に設定されている場合の処理の流れについて説明したが、第２オーソリ電文によって不正利用の検知をクレジットカード会社サーバ２００に通知する処理は、決済方法設定の内容や決済用途によらず実施されてよいものである。例えば、不正利用検知や第２オーソリ電文の送信は、決済方法設定が「チャージ残高払い」の場合に実施されてもよいし、決済用途が支払い以外の場合（例えばチャージや送金）に実施されてもよい。

例えば、図２のユーザスキャンにおいてステップＳ６の第２決済情報に基づいて不正利用が検知された場合、決済サーバ１００は、Ｓ７の電子決済に代えて第２オーソリ電文をクレジットカード会社サーバ２００に送信してもよい。また例えば、図３のストアスキャンにおいてステップＳ１６の決済情報に基づいて不正利用が検知された場合、決済サーバ１００は、Ｓ１７の電子決済に代えて第２オーソリ電文をクレジットカード会社サーバ２００に送信してもよい。これにより、クレジットカード会社サーバ２００は、決済アプリ２０の利用が制限された利用者を認識することができるので、そのような利用者に関して所定の処理を実施することができる。例えば、クレジットカード会社サーバ２００は、決済アプリ２０の利用が制限された利用者について、クレジットカードの利用を制限してもよい。

一般に、クレジットカード会社は、自社が発行するクレジットカードについて不正利用を検知するために自前のシステムを有していることが多い。このような場合、決済サーバ１００側で検知された決済アプリ２０の不正利用の内容がクレジットカード会社サーバ２００に通知されることにより、クレジットカード会社では自前の不正利用検知の仕組みを決済サーバ１００側の仕組みに適合させることが可能となる。例えば、決済アプリ２０の利用が制限された利用者に対して、クレジットカード会社側でさらなる利用制限を実施した場合、制限解除のタイミングや条件が異なったりすることで、正当な利用者の利便性を必要以上に阻害してしまう可能性がある。このような考えに基づけば、例えば、クレジットカード会社は、決済サーバ１００から通知された利用者については自前システムによる制限を敢えて実施しないようにする、といった対応をとることも可能となる。このように、決済サーバ１００側での不正利用の検知結果が、決済方法の種類によらずにクレジットカード会社サーバ２００に通知されることにより、クレジットカード会社と決済事業者とが連携して不正利用防止の取り組みを推進することが可能となる。

［決済アプリを用いた機能制限の解除］
図９は、決済サーバ１００が、不正利用検知に伴う機能制限に関して実施する処理の流れの一例を示すフローチャートである。図９のフローは、決済サーバ１００において決済アプリ２０から新たな決済要求が受信されたことに応じて開始される。まず、不正検知部１５１が、不正検知ルール１７８に基づいて、新たに受信された決済要求が被疑要求に該当するか否かを判定する（Ｓ２０１）。ここで、当該決済要求が被疑要求であると判定された場合、決済処理部１３０が、要求された電子決済を実施する正常時処理（例えば、図７のＳ７１～Ｓ７５）を行う（Ｓ２０２）。

一方、Ｓ２０１において、新たに受信された決済要求が被疑要求であると判定された場合、不正検知部１５１は、要求元に対して決済エラーを通知するとともに（Ｓ２０３）、機能制限部１５２が、当該決済アプリ２０の利用者について決済アプリ２０の機能制限を行う（Ｓ２０４）。

続いて、制限解除部１５２が、Ｓ２０１で被疑要求と判定された決済要求について、不正利用の状況が、決済アプリ２０を用いた制限解除の対象（アプリ解除対象）に該当するか否かを判定する（Ｓ２０５）。アプリ解除対象か否かを判定する条件（アプリ解除条件）は、電子決済サービスの提供者によって任意に設定されてよい。例えば、アプリ解除条件は、全ての被疑要求をアプリ解除対象とするものであってもよいし、特定の状況で発生した被疑要求をアプリ解除対象とするものであってもよい。制限解除部１５２は、Ｓ２０１で検知された被疑要求がアプリ解除条件に該当しない場合は、被疑要求の審査を人員審査工程に送る（Ｓ２０６）。人員審査工程は、被疑要求について不正利用判定の結果の妥当性を人によって審査する工程である。

一方、Ｓ２０１で検知された被疑要求がアプリ解除条件に該当する場合、制限解除部１５３は、当該被疑要求が利用者自身の操作によるものであるかを利用者に問い合わせる（Ｓ２０７）。なお、上述のとおり、当該被疑要求はクレジット払いに係る決済要求であってもよいし、チャージ残高払いに係る決済要求であってもよい。例えば、制限解除部１５３は、上記問合せに対する回答の入力を受け付ける画面（申告画面）を表示させる。

図１０は、決済アプリ２０を用いた機能制限解除の流れの一例を示す図である。図１０の例では、まず制限解除部１５３が、不正検知部１５１により被疑要求が検知された場合に、被疑要求が検知され、機能制限が実施された旨の通知を対象の利用者の利用者端末装置１０に送信する。この通知により、利用者端末装置１０に通知画面Ｄ１が表示される。例えば、通知画面Ｄ１には、機能制限が実施された旨を通知するメッセージと、申告画面へのリンク情報ＩＦ１とが含まれる。リンク情報ＩＦ１は、例えば、ボタンインターフェースとして表示され得る。利用者がボタンインターフェースＩＦ１を操作することにより通知画面Ｄ１が申告画面Ｄ２に遷移する。

申告画面Ｄ２は、取り引き要求の種類に応じた情報が表示されてよい。図１０は、決済要求の場合の申告画面Ｄ２１と、送金要求の場合の申告画面Ｄ２２とが例示されている。申告画面Ｄ２１には、対象の決済要求に関する取引日時、利用店舗名、および利用金額が表示されている。また、申告画面Ｄ２２には、対象の送金要求に関する取引日時、および送金額が表示されている。利用者は、確認対象の取り引き要求が自身の操作によるものであれば「はい」ボタンを押下し、自身の操作によるものでなければ「いいえ」を押下することにより問合せに回答する。制限解除部１５３は、申告画面Ｄ２２により回答された内容を、決済用の第１オーソリ電文とは異なる通知専用のオーソリ電文（第３オーソリ電文）により、クレジットカード会社サーバ２００に通知する（Ｓ２０８）。第３オーソリ電文は第２オーソリ電文と同様に、利用者に負担させない形で所定金額の決済を指示するオーソリ電文であればよい。

図９に戻る。続いて、制限解除部１５３は、対象の利用者について本人確認を行う（Ｓ２０９）。例えば、本人確認の方法の一例として、通話発信による認証（通話発信認証）が挙げられる。通話発信認証は、認証要求元に認証用電話番号宛ての通話発信を指示し、認証用電話番号の着信側で要求元の電話番号からの着信を確認できた場合に要求元を認証する認証方法である。また、例えば、本人確認処理の別の一例として、ＳＭＳ（Short Message Service）認証が挙げられる。ＳＭＳ認証は、所定の情報をＳＭＳによって認証要求元に送信し、送信した情報を返信させることによって要求元を認証する方法である。これらのほか、制限解除部１５３は任意の方法で本人確認を行ってよい。

続いて、制限解除部１５３は、ステップＳ２０９において実施した利用者の本人確認が成功したか否かを判定する（Ｓ２１０）。ここで、利用者の本人確認が成功したと判定した場合、制限解除部１５３は、被疑要求に起因して実施された機能制限を解除する（Ｓ２１１）。ここで、制限解除部１５３は、対象の利用者について機能制限を解除することに加えて、不正検知ルール１７８のうち被疑要求を検知したルール（対象ルール）を一定時間無効化するように構成されてもよい。これにより、被疑要求が検知されたときと同様の操作により、利用者の決済要求が再度被疑要求として検知されてしまうことを抑制することができる。

例えば図１０に示されるように、申告画面Ｄ１による回答が「はい」であり、且つ通話発信認証による本人確認が成功した場合、決済サーバ１００は、対象利用者について機能制限を解除するとともに、対象ルールを一定時間無効化する。また、例えば、決済サーバ１００は、申告画面Ｄ１による回答が「いいえ」であり、且つ通話発信認証による本人確認が成功した場合には、対象利用者について機能制限を継続しつつ、被疑要求の審査を人員審査工程に送る（Ｓ２０６）。

なお、この場合（回答が「いいえ」且つ通話発信認証が成功した場合）、決済サーバ１００は、対象利用者を要監視の対象として、決済アプリ２０の使用状況を監視する（モニタリング）ように構成されてもよい。この場合、決済サーバ１００は、モニタリング中において、特定の操作が検知された場合、対象利用者について当該特定の操作に応じた処理を行うように構成されてもよい。例えば、決済サーバ１００は、モニタリング中に不適切な操作が検知された場合には、対象利用者についてさらなる機能制限を行うように構成されてもよい。また、決済サーバ１００は、一定時間モニタリングにおいて、不適切な操作が検知されなかった場合には、対象利用者について機能制限を解除するように構成されてもよい。

一方で、図１０の例において、通話発信認証による本人確認が失敗した場合には、決済サーバ１００は、対象利用者について決済アプリ１０を使用した全ての取り引きを制限するように構成されてもよい。

以上説明した実施形態によれば、電子決済の不正利用が検知された利用者に対して一定の利用制限を設ける不正利用検知システムにおいて、当該利用制限の解除に係る手間を軽減することができる。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１０ 利用者端末装置
２０ 決済アプリ
１００、１００Ａ 決済サーバ
１２０、１２０Ａ 決済コンテンツ提供部
１２２Ａ 表示制御部
１３０ 決済処理部
１４０ 情報管理部

Claims (9)

1. 利用者の端末装置で動作する決済アプリと協働して前記利用者に電子決済サービスを提供する決済管理装置であって、
   前記決済アプリから受信される決済要求に応じて当該決済要求に係る決済処理を実行する決済処理部と、
   前記決済要求が不正利用を目的としたものであるか否かを判定する不正利用検知部と、
   前記不正利用検知部により不正利用によるものと判定された決済要求である被疑要求に応じて、前記利用者の決済アプリについて機能制限を行う機能制限部と、
   前記被疑要求に関して前記利用者の申告情報および本人確認の結果に基づいて前記機能制限を解除するか否かを判定する制限解除部と、
   前記制限解除部における判定結果に基づき、前記利用者の決済アプリの操作履歴を一定の監視期間において監視し、前記監視期間における操作内容に応じて機能制限の解除又は強化を制御するモニタリング制御部と、
   を備える決済管理装置。
2. 前記モニタリング制御部は、前記監視期間中に不適切操作が検知されなかった場合には、前記機能制限を解除する、
   請求項１に記載の決済管理装置。
3. 前記モニタリング制御部は、前記監視期間中に不適切操作が検知された場合には、前記機能制限を強化する、
   請求項１に記載の決済管理装置。
4. 前記モニタリング制御部は、前記本人確認が成功し、かつ前記利用者の申告情報が不正利用でない旨を示す場合に、前記監視を開始する、
   請求項１から３のいずれか一項に記載の決済管理装置。
5. 前記決済処理部は、前記決済要求を受け付けると、クレジットカードを用いた決済処理を実行するクレジットカード会社サーバに対して、指定された金額のクレジット決済を指示するオーソリ電文を送信するものであり、
   前記制限解除部は、決済用の前記オーソリ電文とは異なる第２のオーソリ電文により前記申告情報を前記クレジットカード会社サーバに送信する、
   請求項１に記載の決済管理装置。
6. 前記第２のオーソリ電文は、所定の金額を前記利用者が負担しない形で決済することを前記クレジットカード会社サーバに指示するオーソリ電文である、
   請求項５に記載の決済管理装置。
7. 前記不正利用検知部は、
   所定の不正検知ルールに基づいて被疑要求を検知するものであり、
   前記制限解除部によって機能制限が解除された場合、前記不正検知ルールのうち、前記機能制限に係る被疑要求を検知したルールを一定時間無効化する、
   請求項１に記載の決済管理装置。
8. 利用者の端末装置で動作する決済アプリと協働して前記利用者に電子決済サービスを提供する決済管理装置が、
   前記決済アプリから受信される決済要求に応じて前記決済要求に係る決済処理を実行する決済処理ステップと、
   前記決済要求が不正利用を目的としたものであるか否かを判定する不正利用検知ステップと、
   前記不正利用検知ステップにより不正利用によるものと判定された決済要求である被疑要求に応じて、前記利用者の決済アプリについて機能制限を行う機能制限ステップと、
   前記被疑要求に関して前記利用者の申告情報および本人確認の結果に基づいて前記機能制限を解除するか否かを判定する制限解除ステップと、
   前記制限解除ステップにおける判定結果に基づき、前記利用者の決済アプリの操作履歴を一定の監視期間において監視し、前記監視期間における操作内容に応じて機能制限の解除又は強化を制御するモニタリングステップと、
   を有する決済管理方法。
9. 利用者の端末装置で動作する決済アプリと協働して前記利用者に電子決済サービスを提供する決済管理装置に、
   前記決済アプリから受信される決済要求に応じて、前記決済要求に係る決済処理を実行する決済処理ステップと、
   前記決済要求が不正利用を目的としたものであるか否かを判定する不正利用検知ステップと、
   前記不正利用検知ステップにより不正利用によるものと判定された決済要求である被疑要求に応じて、前記利用者の決済アプリについて機能制限を行う機能制限ステップと、
   前記被疑要求に関して前記利用者の申告情報および本人確認の結果に基づいて前記機能制限を解除するか否かを判定する制限解除ステップと、
   前記制限解除ステップにおける判定結果に基づき、前記利用者の決済アプリの操作履歴を一定の監視期間において監視し、前記監視期間における操作内容に応じて機能制限の解除又は強化を制御するモニタリングステップと、
   を実行させるためのプログラム。