(57)【要約】【課題】審査の人的負担を低減することができる判定装置、判定方法、及びプログラムを提供すること。【解決手段】判定装置は、第１時点において行われる決済に基づく決済情報を取得する取得部と、前記第１時点よりも所定期間前の第２時点以前に行われた決済の決済情報と、前記取得部によって取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する判定部と、を備える。【選択図】図１
2019164400.tif 000002
【特許請求の範囲】
【請求項１】
第１時点において行われる決済に基づく決済情報を取得する取得部と、
前記第１時点よりも所定期間前の第２時点以前に行われた決済の前記決済情報と、前記取得部によって取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する判定部と、
を備える判定装置。
【請求項２】
前記所定期間は、正常な決済であることが確認可能な期間である、
請求項１に記載の判定装置。
【請求項３】
前記判定部は、前記第２時点以前に行われた複数の決済に基づく複数の決済情報のうち正常な決済を示す決済情報と、前記取得部によって取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する、
請求項１又は請求項２に記載の判定装置。
【請求項４】
前記決済情報には、購入者を推定可能な購入者推定情報が含まれ、
前記判定部は、前記決済情報に含まれる購入者推定情報と、前記第２時点以前に行われた複数の決済に基づく複数の前記決済情報のうち正常な決済を示す前記決済情報に含まれる購入者推定情報とが合致する場合、前記第１時点において行われる決済が正常な決済であると判定する、
請求項３に記載の判定装置。
【請求項５】
前記購入者推定情報には、ＨＴＴＰクッキーを示す情報と、決済に伴う商品の配送先を示す情報と、前記購入者のメールアドレスを示す情報と、ウェブブラウザ情報とのうち、少なくともいずれか１つが含まれる、
請求項４に記載の判定装置。
【請求項６】
決済によって購入された商品、又はサービスの特徴に基づいて、前記購入者推定情報のうち、前記判定部の判定に用いられる情報を選択する選択部を更に備え、
前記判定部は、前記選択部によって選択された前記購入者推定情報に基づいて、前記第１時点において行われる決済が正常な決済であると判定する、
請求項４又は請求項５に記載の判定装置。
【請求項７】
決済手段の特徴に基づいて、前記購入者推定情報のうち、前記判定部の判定に用いられる情報を選択する選択部を更に備え、
前記判定部は、前記選択部によって選択された前記購入者推定情報に基づいて、前記第１時点において行われる決済が正常な決済であると判定する、
請求項４から請求項６のいずれか一項に記載の判定装置。
【請求項８】
決済によって購入された商品、又はサービスを販売する店舗の特徴に基づいて、前記判定部の判定対象の決済を選択する選択部を備え、
前記判定部は、前記選択部によって選択された前記判定対象の決済が正常な決済であると判定する、
請求項１から請求項７のいずれか一項に記載の判定装置。
【請求項９】
コンピュータが、
第１時点において行われる決済に基づく決済情報を取得し、
決済の履歴を示す情報のうち、前記第１時点よりも所定期間前の第２時点以前に行われた決済の決済情報と、取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する、
判定方法。
【請求項１０】
コンピュータに、
第１時点において行われる決済に基づく決済情報を取得させ、
決済の履歴を示す情報のうち、前記第１時点よりも所定期間前の第２時点以前に行われた決済の決済情報と、取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定させる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、判定装置、判定方法、及びプログラムに関する。
【背景技術】
【０００２】
クレジットカードが利用された際には、決済の審査が行われる。これに関連し、クレジットカードの情報を不正に入手した第三者による決済を早期に検出可能な手法するための技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−１３０９３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
クレジットカードの審査は、基本的に人手で行われていたため、人的負担が大きかった。
【０００５】
本発明は、このような事情を考慮してなされたものであり、審査の人的負担を低減することができる判定装置、判定方法、及びプログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【０００６】
本発明の一態様は、少なくとも第１時点において行われる決済に基づく決済情報を取得する取得部と、前記第１時点よりも所定期間前の第２時点以前の決済の履歴を示す情報と、前記取得部によって取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する判定部と、を備える判定装置である。
【発明の効果】
【０００７】
本発明の一態様によれば、審査の人的負担を低減することができる。
【図面の簡単な説明】
【０００８】
【図１】クレジット決済について概説するための図である。
【図２】実施形態に係る情報システムの一例を示す図である。
【図３】決済要求の内容の一例を示す図である。
【図４】履歴情報の内容の一例を示す図である。
【図５】ホワイトリストの対象となるレコードの取得時期を模式的に示す図である。
【図６】ホワイトリストの内容の一例を示す図である。
【図７】決済サーバの決済処理部による判定処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
＜実施形態＞
以下、図面を参照し、本発明の判定装置の実施形態について説明する。判定装置は、一以上のプロセッサにより実現される。判定装置は、商取引システムにおいて行われたクレジットカード決済の審査を補助するための判定を行う装置である。
【００１０】
判定装置は、商取引システムを提供する装置、商取引システムと連携している装置、その他の装置に内蔵される形で実現されてもよいし、単体で専ら判定処理を行う装置であってもよい。以下の説明では、判定装置が、商取引システムにおいて行われるクレジットカード決済に係る処理を行う決済システムを実現する決済サーバの一機能として実現されるものとする。
【００１１】
［決済審査の概要］
図１は、クレジット決済について概説するための図である。クレジット決済では、網羅的に又はサンプリングによって審査対象の決済を抽出し、抽出した決済を人手（図示する決済審査者）によって審査している場合があった。図１の上図は、比較対象として、決済審査者が審査を行う様子を示している。決済審査者は、例えば、審査対象の決済（以下、単に「審査対象決済」）を示す審査対象決済リストから審査対象決済の情報を取得し（図中Ａ）、参照データベースを参照して審査を行う（図中Ｂ）。そして、審査結果をクレジットカード会社等に通知する（図中Ｃ）。図１の下図は、判定装置が審査を行う様子を示している。判定装置は、例えば、審査対象決済リストから審査対象決済の情報を取得し（図中ａ）、以下に説明する処理によって審査を行う（図中ｂ）。そして、決済審査者による審査を経て審査結果をクレジットカード会社等に通知する（図中ｃ）。このように、判定装置を使用することで、人的負担を軽減することができる。
【００１２】
［情報処理システム１について］
図２は、実施形態に係る情報処理システム１の一例を示す図である。情報処理システム１は、例えば、決済サーバ１００と、一以上の端末装置２００と、一以上のショッピングサーバ３００とを備える。これらの装置は、ネットワークＮＷを介して接続される。決済サーバ１００と、端末装置２００と、ショッピングサーバ３００とは、ネットワークＮＷを介して種々の情報を送受信する。ネットワークＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、プロバイダ端末、無線通信網、無線基地局、専用回線などを含む。なお、図２に示す各装置の全ての組み合わせが相互に通信可能である必要はなく、ネットワークＮＷは、一部にローカルなネットワークを含んでもよい。
【００１３】
［端末装置２００について］
端末装置２００は、例えば、スマートフォンなどの携帯電話、タブレット端末、各種パーソナルコンピュータなどの、入力装置、表示装置、通信装置、記憶装置、および演算装置を備える端末装置である。通信装置は、ＮＩＣ（Network Interface Card）などのネットワークカード、無線通信モジュールなどを含む。端末装置２００では、ブラウザやアプリケーションプログラムなどのＵＡ（User Agent）２１０が起動する。ＵＡ２１０は、ショッピングサーバ３００から提供された販売画面を表示すると共に、端末装置２００の利用者によってなされた入力操作に応じたリクエストをショッピングサーバ３００に送信する。ショッピングサーバ３００は、ＵＡ２１０からのリクエストに応じて商品の販売を管理する。以下の説明では、ＵＡ２１０はブラウザであり、ショッピングサーバ３００はウェブサーバであるものとする。端末装置２００では、ＵＡ２１０が起動し、ユーザの入力する内容に応じたリクエストをショッピングサーバ３００に送信する。また、ＵＡ２１０が起動した端末装置２００は、ショッピングサーバ３００から取得した情報に基づいて、表示装置に各種画像を表示させる。端末装置２００は、購入者の「商品を購入する」操作に応じて、決済を要求するための決済要求２２０を、ショッピングサーバ３００に送信する。
【００１４】
［決済要求２２０について］
図３は、決済要求２２０の内容の一例を示す図である。決済要求２２０は、例えば、購入者のユーザＩＤに対して、取引日時、取引内容、決済手段、決済金額、クレジットカード番号、及び購入者推定情報等が対応付けられた情報である。取引内容には、例えば、「商品購入」、或いは「サービス購入」等の取引の内容が示される。決済手段には、例えば、「代金引換」、「銀行引き落とし」、「クレジット」、或いは「ポイント」等が示される。なお、決済手段は一例であってこれに限られない。決済要求２２０は、「決済情報」の一例であり、ユーザＩＤと、クレジットカード番号とは、「決済に係る識別情報」の一例である。
【００１５】
購入者推定情報は、購入者を推定（同定）することが可能な情報である。購入者推定情報は、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）クッキー、商品の配送先住所、購入者のメールアドレス、購入者がショッピングサイトを閲覧する際に用いたウェブブラウザの情報（以下、単にウェブブラウザ情報）のうち、少なくともいずれか１つが含まれる。ウェブブラウザ情報には、例えば、ブラウザバージョン、ウィンドウサイズ、言語設定、又はタイムゾーンのうち、少なくとも１つが含まれる。本実施形態では、ウェブブラウザ情報にブラウザバージョンのみが含まれる場合について説明する。ＨＴＴＰクッキー、又はウェブブラウザ情報は、購入者が用いるブラウザやアプリケーションプログラムから取得される。商品の配送先住所、又は購入者のメールアドレスは、購入者がログインしているショッピングサイトから取得される。なお、購入者推定情報に含まれる各種情報は一例であって、これに限られない。例えば、購入した商品がデジタルコンテンツ等の配送を伴わない商品である場合、購入者推定情報には、配送先住所が含まれない。また、購入者がアプリによってショッピングサイトのコンテンツを閲覧した場合、購入者推定情報には、ウェブブラウザ情報に代えて、アプリのバージョンが含まれる。
【００１６】
図２に戻り、ショッピングサーバ３００は、端末装置２００から受信した決済要求２２０に含まれる決済手段として「クレジット」が選択されている場合、当該決済要求２２０を、ネットワークＮＷを介して決済サーバ１００に送信する。
【００１７】
［決済サーバ１００について］
決済サーバ１００は、例えば、決済情報取得部１０２と、ホワイトリスト生成部１０３と、決済判定部１０４と、決済処理部１０６とを備える。これらの構成要素は、例えば、ＣＰＵ（Central Processing Unit）などのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置に格納されていてもよいし、ＤＶＤやＣＤ−ＲＯＭなどの着脱可能な記憶媒体に格納されており、記憶媒体がドライブ装置に装着されることでインストールされてもよい。
【００１８】
また、決済サーバ１００は、記憶装置１１０に、審査対象決済リスト１１２、履歴情報１１３、及びホワイトリスト１１４等のデータを格納する。記憶装置１１０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）等によって実現される。記憶装置１１０は、各サーバに付随するものであってもよいし、ネットワークＮＷを介してアクセス可能なＮＡＳ（Network Attached Storage）などの外部記憶装置であってもよい。
【００１９】
決済情報取得部１０２は、ショッピングサーバ３００から決済要求２２０を取得し、審査対象決済リスト１１２として蓄積する。決済判定部１０４は、決済情報取得部１０２によって取得された決済要求２２０と、当該決済要求２２０の決済結果とを対応付けて、履歴情報１１３として蓄積する。決済判定部１０４は、例えば、クレジットカード会社から提供されるブラックリストに掲載されるクレジットカードが決済に用いられた取引を正常な決済ではないと判定し、それ以外の決済を正常な決済であると判定する。
【００２０】
決済処理部１０６は、決済判定部１０４によって判定された結果に基づいて、決済処理を行う。具体的には、決済処理部１０６は、決済判定部１０４によって正常な決済であると判定された場合、決済処理を行う。また、決済処理部１０６は、決済判定部１０４によって正常な決済ではないと判定された場合、ショッピングサーバ３００（ショッピングサイト）、この取引の購入者の端末装置２００、或いはクレジットカード会社に正常な決済ではない決済が行われた旨を通知する。
【００２１】
［履歴情報１１３について］
図４は、履歴情報１１３の内容の一例を示す図である。履歴情報１１３は、ユーザＩＤに、決済要求２２０に含まれていた各種情報と、当該決済要求２２０に対する決済結果とが対応付けられた情報である。以下、履歴情報１１３に含まれる、一回の決済要求２２０に対応する情報を、「履歴情報１１３の１レコード」と称する。決済結果には、決済判定タイミングにおける審査の結果だけでなく、事後的に正常でない旨の申し出がなされたという結果も含まれる。仮に、ある購入者が、利用明細を受領して身に覚えの無い取引が行われていることを把握した場合、購入者は、クレジットカード会社の担当者に連絡する。担当者は、連絡を受けて、履歴情報１１３うち、当該取引のレコードの決済結果を「正常」から「返金」に修正する。
【００２２】
図２に戻り、ホワイトリスト生成部１０３は、履歴情報１１３に基づいて、ホワイトリスト１１４を生成する。ホワイトリスト１１４とは、審査対象決済が正常な決済であるか否かを判定する際に用いられる情報である。
【００２３】
［ホワイトリスト１１４について］
図５は、ホワイトリスト１１４の対象となるレコードの取得時期（決済要求２２０として取得された時期）を模式的に示す図である。ホワイトリスト１１４は、履歴情報１１３のレコードのうち、正常な決済であると判定された決済のレコードであり、例えば、決済判定部１０４による決済判定タイミング（時刻ｔ１；第１時点）から、所定期間ＴＭ前の判定基準タイミング（時刻ｔ２；第２時点）よりも前に、履歴情報１１３に蓄積されたレコードである。以降の説明において、時刻ｔ１を「決済判定タイミング」と記載し、時刻ｔ２を「判定基準タイミング」と記載する。決済判定タイミングは、「第１時点」の一例であり、判定基準タイミングは、「第２時点」の一例である。図６は、ホワイトリスト１１４の内容の一例を示す図である。なお、以下に説明するように、ホワイトリスト１１４は、履歴情報１１３のレコードのうち、収集時期を問わず、正常な決済であると審査された決済のレコードを集めたものであってもよい。
【００２４】
図２に戻り、ホワイトリスト生成部１０３は、例えば、一日に一回という頻度で、ホワイトリスト１１４を生成する。ホワイトリスト生成部１０３は、例えば、以下の（Ａ）、又は（Ｂ）の生成方法によって、ホワイトリスト１１４を生成する。生成方法（Ａ）は、ホワイトリスト生成部１０３が、履歴情報１１３に含まれるレコードのうち、判定基準タイミングよりも以前に蓄積されたレコードであり、決済結果が「正常」であるレコードを集めて、ホワイトリスト１１４を生成する生成方法である。生成方法（Ｂ）は、ホワイトリスト生成部１０３が、履歴情報１１３のレコードのうち、収集された時期に関わらず、決済結果が「正常」であるものを集めて、ホワイトリスト１１４を生成する生成方法である。
【００２５】
ここで、クレジットカード決済によって行われた取引の成否について、購入者が判断するまでには、所定期間ＴＭを要する場合がある。所定期間ＴＭとは、正常な決済であることが購入者、又はクレジットカード会社によって確認可能な期間であり、決済判定タイミングから好ましくは数日以上前の期間であり、更に好ましくは数週間以上前の期間であり、更に好ましくは３か月以上前の期間である。所定期間ＴＭは、例えば、決済判定タイミングから、購入者がクレジットカード会社によって発行される利用明細を確認し、決済の成否を判断するまでに要する期間である。したがって、ホワイトリスト１１４のレコードが示す決済は、購入者、又はクレジットカード会社によって正常な決済であることが確認された決済である。
【００２６】
［審査対象決済の判定について］
決済判定部１０４は、所定のタイミングにおいて審査対象決済リスト１１２のレコードとして記憶される審査対象決済が正常な決済であるか否かを判定する。具体的には、決済判定部１０４は、以下の（１）〜（５）の条件の少なくとも１つを満たす場合に、審査対象決済が正常な決済であると判定する。
（１）審査対象決済リスト１１２のレコードに含まれるＨＴＴＰクッキーを示す情報が、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のＨＴＴＰクッキーを示す情報のいずれかに一致する場合
この場合、購入者が通常使用する端末装置２００と同じ端末装置２００を用いて行った決済であることが推定されるため、決済判定部１０４は、当該レコードの審査対象決済が正常な決済であると判定する。
（２）審査対象決済リスト１１２のレコードに含まれる配送先住所が、当該レコードに含まれるホワイトリスト１１４のユーザＩＤが対応付けられた配送先住所のいずれかに一致する場合
この場合、購入者が購入した商品等を通常配送する配送先住所と同じ配送先住所の取引の決済であることが推定されるため、決済判定部１０４は、当該レコードの審査対象決済が正常な決済であると判定する。
（３）審査対象決済リスト１１２のレコードに含まれるメールアドレスを示す情報が、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のメールアドレスを示す情報のいずれかに一致する場合
この場合、購入者が取引に係る連絡に使用するメールアドレスに、通常使用するメールアドレスと同じメールアドレスを指定した取引であることが推定されるため、決済判定部１０４は、当該レコードの審査対象決済が正常な決済であると判定する。
（４）審査対象決済リスト１１２のレコードに含まれるウェブブラウザ情報を示す情報が、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のウェブブラウザ情報を示す情報のいずれかに一致する場合
この場合、購入者が通常使用するブラウザやアプリと同じブラウザによって行われる取引の決済であることが推定されるため、決済判定部１０４は、当該レコードの審査対象決済が正常な決済であると判定する。
（５）審査対象決済リスト１１２のレコードに含まれるクレジットカード番号を示す情報が、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のクレジットカード番号を示す情報のいずれかに一致する場合
これらの場合、購入者が通常使用するクレジットカードと同じクレジットカードによって行われた決済であることが推定されるため、決済判定部１０４は、当該レコードの審査対象決済が正常な決済であると判定する。
【００２７】
決済処理部１０６は、決済判定部１０４によって審査対象決済が判定された結果に基づいて、履歴情報１１３に記憶されるレコード、及びホワイトリスト１１４に記憶されるレコードを修正する。具体的には、決済処理部１０６は、決済判定部１０４によって審査対象決済が正常な決済ではないと判定された場合、改めて決済審査者に対して当該審査対象決済の審査（判定）を依頼する。
【００２８】
決済処理部１０６は、決済審査者によって改めて審査対象決済が正常な決済ではないと判定された場合、履歴情報１１３を更新する。具体的には、決済処理部１０６は、当該審査対象決済に対応する履歴情報１１３のレコードに含まれる決済結果を「異常」に変更する。なお、生成方法（Ｂ）によってホワイトリスト１１４が生成された場合、決済処理部１０６は、当該審査対象決済に対応するホワイトリスト１１４のレコードを削除する。
【００２９】
また、決済処理部１０６は、正常な決済ではないと判定された決済について、ショッピングサーバ３００、この取引の購入者の端末装置２００、或いはクレジットカード会社に正常な決済ではない決済が行われた旨を通知する。なお、決済処理部１０６は、決済審査者による判定結果を待たずに、履歴情報１１３のレコードを変更してもよく、各方面に異常な決済が行われた旨を通知してもよい。
【００３０】
［処理フロー］
図７は、決済サーバ１００の決済処理部１０６による判定処理の一例を示すフローチャートである。図７に示すフローチャートの処理は、決済判定タイミングにおいて実行される。決済判定タイミングは、例えば、数時間に１回、１日に１回、或いは数日に１回程度のタイミングである。決済処理部１０６は、審査対象決済リスト１１２から審査対象決済のレコードを読み出す（Ｓ１００）。
【００３１】
生成方法（Ａ）によってホワイトリスト１１４が生成される場合、決済判定部１０４は、審査対象決済リスト１１２から読み出したレコードに含まれる購入者推定情報と、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のレコードの購入者推定情報とが合致するか否かを判定する（Ｓ１０６）。
【００３２】
なお、生成方法（Ｂ）によってホワイトリスト１１４が生成される場合、Ｓ１０６の処理は、「審査対象決済リスト１１２から読み出したレコードに含まれる購入者推定情報と、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のレコードのうち判定基準タイミング以前のレコードに絞り込んだものに含まれる購入者推定情報とが合致するか否かを判定する」という内容に置換される。
【００３３】
決済判定部１０４は、審査対象決済リスト１１２から読み出したレコードに含まれる購入者推定情報と、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のレコードの購入者推定情報とが合致する（少なくとも一部が一致する）場合、正常な決済であると判定し（Ｓ１０８）、処理を終了する。決済判定部１０４は、審査対象決済リスト１１２から読み出したレコードに含まれる購入者推定情報と、当該レコードに含まれるユーザＩＤが対応付けられたホワイトリスト１１４のレコードの購入者推定情報とが合致しない場合、正常な決済ではない可能性があると判定する（Ｓ１１０）。この場合、決済処理部１０６は、改めて決済審査者（の端末装置）に対して当該審査対象決済の審査（判定）を依頼する（Ｓ１１２）。決済処理部１０６は、決済審査者からの通知を受けて、当該審査対象決済が正常な決済であるか否かを判定する（Ｓ１１４）。決済処理部１０６は、決済審査者が、当該審査対象決済が正常な決済であると判定した場合、処理を終了する。決済処理部１０６は、決済審査者が、当該審査対象決済が正常な決済ではないと判定した場合、履歴情報１１３を更新し（Ｓ１１６）、ショッピングサーバ３００、この取引の購入者の端末装置２００、或いはクレジットカード会社に正常な決済ではない決済が行われた旨を通知する。（Ｓ１１８）、処理を終了する。
【００３４】
［ポイント決済について］
また、上述では、決済判定部１０４がクレジットカード決済を判定（審査）対象とする場合について説明したが、これに限られない。決済判定部１０４は、ポイント決済を判定対象とし、同様の処理を行ってもよい。
【００３５】
［ホワイトリスト１１４に基づく判定について］
なお、上述では、決済判定部１０４が、審査対象決済に含まれる購入者推定情報と、当該決済要求２２０に含まれるユーザＩＤが対応付けられたホワイトリスト１１４の購入者推定情報の少なくとも１つとが一致する場合、当該審査対象決済が正常な決済であると判定する場合について説明したが、これに限られない。決済判定部１０４は、例えば、審査対象決済に含まれる購入者推定情報（つまり、ＨＴＴＰクッキー、配送先住所、購入者のメールアドレス、ウェブブラウザ情報）のうち、所定数（例えば、２つ）以上の情報がホワイトリスト１１４と一致する場合に、当該審査対象決済が正常な決済であると判定する構成であってもよい。
【００３６】
［購入者推定情報の組み合わせについて］
また、決済判定部１０４は、審査対象決済に含まれる購入者推定情報のうち、特定の情報の組み合わせに基づいて、審査対象決済が正常な決済であるか否かを判定してもよい。決済サーバ１００は、例えば、審査対象決済の取引によって購入された商品、又はサービスの特徴に基づいて、購入者推定情報のうち、決済処理部１０６の判定に用いられる情報を選択する選択部を備える。決済判定部１０４は、審査対象決済のレコードの購入者推定情報のうち、選択部によって選択された情報が、当該レコードに対応するホワイトリスト１１４のレコードの購入者推定情報と合致する場合、審査対象決済が正常な決済であると判定する。例えば、審査対象決済の取引によって購入された商品が「デジタルコンテンツ」である場合、選択部は、購入者推定情報のうち、「ＨＴＴＰクッキー」を決済処理部１０６の判定に用いる情報として選択し、決済処理部１０６は、審査対象決済のレコードに含まれる「ＨＴＴＰクッキー」と、ホワイトリスト１１４に含まれるレコードのうち、当該レコードに対応するレコードの「ＨＴＴＰクッキー」とが一致した場合、審査対象決済が正常な決済であると判定する。
【００３７】
また、選択部は、決済手段の特徴に基づいて、購入者推定情報のうち、決済処理部１０６の判定に用いられる情報を選択してもよい。例えば、審査対象決済の決済手段が「ポイント」である場合、選択部は、購入者推定情報のうち、「ＨＴＴＰクッキー」と、「配送先住所」とを決済処理部１０６の判定に用いる情報として選択し、決済処理部１０６は、審査対象決済のレコードに含まれる「ＨＴＴＰクッキー」、及び「配送先住所」と、ホワイトリスト１１４に含まれるレコードのうち、当該レコードに対応するレコードの「ＨＴＴＰクッキー」、及び「配送先住所」とが一致した場合、審査対象決済が正常な決済であると判定する。
【００３８】
なお、選択部は、購入者推定情報以外の購入者の情報を決済処理部１０６の判定に用いる情報として選択してもよい。例えば、審査対象決済の決済手段が「クレジットカード」である場合、選択部は、「ユーザＩＤ」と、「クレジットカード番号」とを決済処理部１０６の判定に用いる情報として選択し、決済処理部１０６は、審査対象決済のレコードに含まれる「ユーザＩＤ」、及び「クレジットカード番号」と、ホワイトリスト１１４に含まれるレコードのうち、当該レコードに対応するレコードの「ユーザＩＤ」、及び「クレジットカード番号」とが一致した場合、審査対象決済が正常な決済であると判定する。
【００３９】
また、決済サーバ１００は、購入された商品、又はサービスを販売する店舗の特徴に基づいて、審査対象決済を抽出する機能を有していてもよい。例えば、購入された商品、又はサービスを販売する店舗が、オークションサイトの店舗である場合、決済サーバ１００は、購入者が、購入した商品、又はサービスが落札する前の決済要求２２０を審査対象決済として抽出し、審査対象決済リスト１１２に記憶させてもよい。オークションサイトを利用する購入者によってオークションサイトのサーバに送信される決済要求２２０には、「決済金額」に代えて、「入札金額」が含まれる。
【００４０】
［審査対象決済を抽出する場合について］
また、上述では、決済情報取得部１０２によって取得された決済要求２２０が審査対象決済リスト１１２に記憶されることにより、いずれの決済も審査対象決済として決済処理部１０６によって判定される場合について説明したが、これに限られない。審査対象決済リスト１１２には、例えば、履歴情報１１３に記憶されるレコードのうち、網羅的に又はサンプリングによって審査対象決済のレコードが抽出され、審査対象決済リスト１１２として記憶される構成であってもよい。これにより、決済処理部１０６は、すべての決済のうち、抽出された審査対象決済について判定することができる。
【００４１】
［決済要求２２０の決済をリアルタイムに判定する場合について］
なお、上述では、審査対象決済リスト１１２に記憶される審査対象決済を、決済判定タイミングにおいて判定する場合について説明したが、これに限られない。決済判定部１０４は、例えば、決済情報取得部１０２によって取得された決済要求２２０が示す決済が正常な決済であるか否かをリアルタイムに判定してもよい。この場合、決済処理部１０６は、決済判定部１０４によって正常な決済であると判定された決済の決済処理を行い、決済判定部１０４によって正常な決済ではないと判定された決済は、決済を行うことができない旨、ショッピングサーバ３００、端末装置２００、或いは、クレジットカード会社に通知してもよい。
【００４２】
［ホワイトリスト１１４を生成しない場合について］
また、上述では、ホワイトリスト生成部１０３によってホワイトリスト１１４が生成される場合について説明したが、これに限られない。例えば、決済判定部１０４は、決済判定タイミングにおいて、履歴情報１１３のレコードのうち、判定基準タイミング以前のレコードであり、且つ決済結果に「正常」が対応付けられているレコードを参照し、審査対象決済が正常であるか否かを判定する構成であってもよい。この場合、決済サーバ１００は、ホワイトリスト生成部１０３を備えていなくてもよい。
【００４３】
［実施形態のまとめ］
以上説明したように、本実施形態の決済サーバ１００は、第１時点において行われる決済に基づく審査対象決済のレコードを取得する取得部（この一例では、決済情報取得部１０２）と、第１時点（この一例では、決済判定タイミング）よりも所定期間ＴＭ前の第２時点（この一例では、判定基準タイミング）以前のホワイトリスト１１４と、決済情報取得部１０２によって取得された審査対象決済のレコードとに基づいて、第１時点において行われる決済が正常な決済であるか否かを判定する判定部（この一例では、決済判定部１０４）と、を備え、決済審査者の人的負担を低減し、審査結果にばらつきが生じることを抑制することができる。
【００４４】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００４５】
１…情報処理システム
１００…決済サーバ
１０２…決済情報取得部
１０３…ホワイトリスト生成部
１０４…決済判定部
１０６…決済処理部
１１０…記憶装置
１１２…審査対象決済リスト
１１３…履歴情報
１１４…ホワイトリスト
２００…端末装置
２２０…決済要求
３００…ショッピングサーバ
ＴＭ…所定期間
【図１】
2019164400.tif 000003
【図２】
2019164400.tif 000004
【図３】
2019164400.tif 000005
【図４】
2019164400.tif 000006
【図５】
2019164400.tif 000007
【図６】
2019164400.tif 000008
【図７】
2019164400.tif 000009
【手続補正書】
【提出日】平成31年3月18日(2019.3.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１時点において行われる決済に基づく決済情報を取得する取得部と、
前記決済情報には、購入者を推定可能な情報であり、ＨＴＴＰクッキーを示す情報と、決済に伴う商品の配送先を示す情報と、前記購入者のメールアドレスを示す情報と、ウェブブラウザ情報とのうち、少なくともいずれか１つが含まれ、
決済によって購入された商品、又はサービスの特徴に基づいて、前記決済情報に含まれる情報のうち、判定に用いられる情報を選択する選択部と、
前記第１時点よりも所定期間前の第２時点以前に行われた決済の前記決済情報を含み、第２時点よりも後に行われた決済の前記決済情報を含まない情報群から、正常な決済と確認された決済情報を集めたホワイトリストと、前記取得部によって取得された前記決済情報とについて、前記選択部によって選択された前記情報の合致の程度に基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する判定部と、
を備える判定装置。
【請求項２】
前記所定期間は、正常な決済であることが確認可能な期間である、
請求項１に記載の判定装置。
【請求項３】
前記判定部は、前記第２時点以前に行われた複数の決済に基づく複数の決済情報のうち正常な決済を示す決済情報と、前記取得部によって取得された前記決済情報とに基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する、
請求項１又は請求項２に記載の判定装置。
【請求項４】
前記選択部は、決済手段の特徴に基づいて、前記判定部の判定に用いられる情報を選択する、
請求項１から請求項３のいずれか一項に記載の判定装置。
【請求項５】
前記選択部は、決済によって購入された商品、又はサービスを販売する店舗の特徴に基づいて、前記判定部の判定対象の決済を更に選択し、
前記判定部は、前記選択部によって選択された前記判定対象の決済が正常な決済であると判定する、
請求項１から請求項４のいずれか一項に記載の判定装置。
【請求項６】
コンピュータが、
第１時点において行われる決済に基づく決済情報を取得し、
前記決済情報には、購入者を推定可能な情報であり、ＨＴＴＰクッキーを示す情報と、決済に伴う商品の配送先を示す情報と、前記購入者のメールアドレスを示す情報と、ウェブブラウザ情報とのうち、少なくともいずれか１つが含まれ、
決済によって購入された商品、又はサービスの特徴に基づいて、前記決済情報に含まれる情報のうち、判定に用いられる情報を選択し、
前記第１時点よりも所定期間前の第２時点以前に行われた決済の前記決済情報を含み、第２時点よりも後に行われた決済の前記決済情報を含まない情報群から、正常な決済と確認された決済情報を集めたホワイトリストと、取得された前記決済情報とについて、選択された前記情報の合致の程度に基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定する、
判定方法。
【請求項７】
コンピュータに、
第１時点において行われる決済に基づく決済情報を取得させ、
前記決済情報には、購入者を推定可能な情報であり、ＨＴＴＰクッキーを示す情報と、決済に伴う商品の配送先を示す情報と、前記購入者のメールアドレスを示す情報と、ウェブブラウザ情報とのうち、少なくともいずれか１つが含まれ、
決済によって購入された商品、又はサービスの特徴に基づいて、前記決済情報に含まれる情報のうち、判定に用いられる情報を選択させ、
前記第１時点よりも所定期間前の第２時点以前に行われた決済の前記決済情報を含み、第２時点よりも後に行われた決済の前記決済情報を含まない情報群から、正常な決済と確認された決済情報を集めたホワイトリストと、取得された前記決済情報とについて、前記情報の合致の程度に基づいて、前記第１時点において行われる決済が正常な決済であるか否かを判定させる、
プログラム。