JP7000503B2 - 決済装置、プログラム、および情報処理方法 - Google Patents

Description

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

近年、顧客に商品販売または役務提供（以下、「商品販売など」という）を対面で行う店舗においても、様々な本人確認の要素（知識、所有物、生体）が用いられて本人確認が行われている。

下記特許文献１には、顧客の生体要素（眼の画像情報）に基づいて本人か否かを確認する手段を備える顧客の端末（以下、「顧客端末」という）と、店舗内商品管理サーバと、を備えたショッピングシステムが記載されている。このユーザ端末において本人認証が成功した場合に購入対象の商品の決済指示を確定する。

特開２０１２－００８７４６号公報

近年、顧客と店舗との対面取引において顧客の端末（以下、「顧客端末」という）を利用したＱＲコード（登録商標）決済やモバイルＮＦＣ決済などの決済手段が多く用いられている。しかしながら、上記従来技術では、このような決済手段において顧客端末上でしか本人確認できないため顧客端末の脆弱性によっては不正に突破されてしまう。また既存のクレジットカード決済では顧客からのサインやパスワード入力などにより店舗側で本人確認できるが、セキュリティを考慮して店舗側での本人確認を必須とすると、上記のような顧客端末を用いた決済手段が利用困難となってしまう。

そこで、本発明は、上記課題に鑑み、顧客と店舗との間の対面取引において決済手段によらずに店舗側で顧客の本人確認ができる決済装置、プログラム、および情報処理方法を提供することを目的とする。

本発明の一態様に係る決済装置は、顧客の顧客端末、または顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続する決済装置であって、顧客と店舗との間の取引の支払いの際、顧客端末または店舗端末から、支払いの決済要求を受け付ける決済受付部と、顧客の属性を示す属性情報を記憶する記憶部を参照して、決済受付部が決済要求を受け付けた際に、店舗端末に、属性と取引への複数の対処方法を出力する出力部と、店舗端末から、複数の対処方法のうち店舗が採用する対処方法の選択を受け付ける選択受付部と、選択された対処方法が所定の条件を満たす場合、決済要求に基づいて、支払いの決済のための処理を行う決済処理部と、を備える。

本発明の一態様に係るプログラムは、顧客の顧客端末、または前記顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続するコンピュータに、前記顧客と前記店舗との間の取引の支払いの際、前記顧客端末または前記店舗端末から、前記支払いの決済要求を受け付ける決済受付機能と、前記顧客の属性を示す属性情報を記憶する記憶機能を参照して、前記決済受付機能が前記決済要求を受け付けた際に、前記店舗端末に、前記属性と前記取引への複数の対処方法を出力する出力機能と、前記店舗端末から、前記複数の対処方法のうち前記店舗が採用する対処方法の選択を受け付ける選択受付機能と、前記選択された対処方法が所定の条件を満たす場合、前記決済要求に基づいて、前記支払いの決済のための処理を行う決済処理機能と、を実現させる。

本発明の一態様に係る情報処理方法は、顧客の顧客端末、または前記顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続するコンピュータが、前記顧客と前記店舗との間の取引の支払いの際、前記顧客端末または前記店舗端末から、前記支払いの決済要求を受け付け、前記顧客の属性を示す属性情報を記憶する記憶部を参照して、前記決済要求を受け付けた際に、前記店舗端末に、前記属性と前記取引への複数の対処方法を出力し、前記店舗端末から、前記複数の対処方法のうち前記店舗が採用する対処方法の選択を受け付け、前記選択された対処方法が所定の条件を満たす場合、前記決済要求に基づいて、前記支払いの決済のための処理を行う。

本発明によれば、顧客と店舗との間の対面取引における顧客端末を利用した決済でも、店舗側で顧客の本人確認ができる決済装置、プログラム、および情報処理方法を提供することができる。

本実施形態に係る決済システムのシステム構成例を説明するための図である。 本実施形態に係る決済システムの概要を説明するための図である。 本実施形態に係る決済システムの概要を説明するための図である。 本実施形態に係る決済装置の機能構成の一例を示す図である。 本実施形態に係る決済装置の動作例を示す図である。 本実施形態に係る決済装置のハードウェア構成の一例を示す図である。

添付図面を参照して、本発明の好適な実施形態（以下、「本実施形態」という）について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

本実施形態において、「部」や「手段」、「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」、「システム」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「手段」、「装置」、「システム」の機能が１つの物理的手段や装置により実現されてもよい。

＜１．システム構成＞
図１を参照して、決済システム１のシステム構成例を説明する。

決済システム１は、店舗と店舗の顧客（以下、単に「顧客」という）に決済サービスを提供するためのシステムである。図１に示すように、決済システム１は、決済装置１００と、顧客が使用する顧客端末２００と、店舗が使用する店舗端末３００と、を含む。

決済装置１００と顧客端末２００と店舗端末３００とは、ネットワークＮを介して互いに接続されている。

ネットワークＮは、無線ネットワークや有線ネットワークにより構成される。ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ－ｐｈｏｎｅ Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４などに準拠したネットワークがある。

決済装置１００は、顧客端末２００、店舗端末３００との通信が可能な情報処理装置である。決済装置１００は、所定のプログラムを実行することにより、顧客端末２００および店舗端末３００と連携して、店舗からユーザへの商品販売または役務提供（以下、「商品販売など」ともいう）により生じた代金の支払いの決済（以下、単に「支払いの決済」または「決済」ともいう）をするための処理を制御するサーバ機能を実現する。

決済装置１００は、例えば、Ｗｅｂサーバとして、顧客や店舗に対して、決済サービスを提供するためのＷｅｂサイト（以下、「決済サイト」ともいう）を提供してよい。決済装置１００は、顧客端末２００または店舗端末３００から、決済サイトのＵＲＬを指定させてアクセス可能にする。

顧客端末２００は、顧客からの支払い要求の受け付けなどの入力または決済装置１００や店舗端末３００との通信が可能なスマートフォンやラップトップなどの端末装置である。顧客端末２００は、所定のプログラムを実行することにより、決済装置１００や店舗端末３００と連携して支払いの決済に関する情報を送受信したり、支払いの決済に関する画面を表示したり顧客の要求を受け付けたりする。

顧客端末２００は、例えば、顧客向けの決済システム１専用のアプリケーションプログラム（以下、「顧客用アプリ」という）をインストールしてもよい。

店舗端末３００は、事業者が有する店舗に設置された支払いの決済のための端末装置である。店舗端末３００は、例えば、バーコードリーダー機能を備える、ＰＯＳレジ端末、タブレット端末、またはハンディ端末などである。

店舗端末３００は、例えば、商品または役務（以下、「商品など」ともいう）の入力の受け付け、受け付けた商品などの代金の合計金額（支払い金額）の算出などのＰＯＳレジ機能を備えてもよい。また、店舗端末３００は、店舗向けの決済システム１専用のアプリケーションプログラム（以下、「店舗用アプリ」という）をインストールすることで、上記のＰＯＳレジ機能を実現させてもよい。上記のＰＯＳレジ機能は、例えば、後述の店舗端末３００のプロセッサ８０１が店舗用アプリを実行することにより実現されてもよい。また、店舗端末３００は、上記のＰＯＳレジ機能を実現にあたって、商品などの売上に関する情報を管理するＰＯＳシステム（不図示）に接続されてもよい。

＜２．概要＞
図２～３を参照して、決済システム１の概要を説明する。本例では、顧客と店舗との間の取引として、店舗は顧客に商品販売などを提供し、顧客は店舗にその代金を支払うものとするが、これに限る趣旨ではない。なお本例において「店舗」とは、店舗の店員も含むものとする。

本例では、説明を簡単にするため、顧客は、代金の支払い方法として利用者提示型（ＣＰＭ（Ｃｏｎｓｕｍｅｒ－Ｐｒｅｓｅｎｔｅｄ－Ｍｏｄｅ））のＱＲコードを用いるコード決済（以下、単に「コード決済」ともいう）を用いるものとするが、これに限定されない。決済システム１は、例えば、ＮＦＣを利用したモバイル決済、クレジットカード決済などのカード決済、または電子マネー決済など様々な決済手段に用いることができる。

（１）まず図２を参照して、顧客と店舗との取引の際の決済サービスの流れを説明する。図２に示すように、店舗は、商品販売などを顧客に提供する。（２）顧客は、商品などの代金の支払いをするため顧客端末２００を利用してコード決済をするためのアプリケーションプログラム（以下、「決済アプリ」ともいう）を起動させ、画面にＱＲコードを表示させる。この決済アプリは、例えば、顧客用アプリであってもよい。

（３）店舗端末３００は、顧客端末２００に表示されたＱＲコードを読み取って、ＱＲコードに含まれる情報に基づいて、上記（２）の支払いの決済のための決済要求を決済装置１００に送信する。ここで「ＱＲコードに含まれる情報」とは、例えば、それぞれの決済を識別する決済識別情報、店舗を識別する店舗識別情報、または顧客を識別する顧客識別情報もしくは間接的に顧客を特定する情報などを含んでもよい。（４）決済装置１００は、この支払いの決済要求を受け付けると、後述の記憶部１３０に記憶する属性情報を参照して、該当する顧客の属性を取得する。

「属性情報」とは、顧客の属性を示す情報である。ここで「顧客の属性」とは、顧客の性質や特徴を表す情報である。顧客の属性は、例えば、後述の顧客情報であってもよいし、顧客情報に基づく情報であってもよい。顧客の属性は、例えば、顧客個人の特定を困難にするための匿名加工がされた顧客情報であってもよい。

顧客の属性は、具体的には、（Ａ）年代（例えば、「３０代」など顧客の生年月日より算出）、（Ｂ）性別、（Ｃ）居住地（例えば、「大阪府在住」などの国・都道府県・市長村レベルのもの。顧客の住所より算出）を含んでもよい。

「顧客情報」とは、顧客に関する情報である。顧客情報は、例えば、顧客識別情報、または顧客の氏名、電話番号、住所、メールアドレス、ＳＮＳのアカウント情報、個人番号（マイナンバー）、性別もしくは生年月日などのいわゆる顧客の個人情報を含んでもよい。

顧客情報は、例えば、顧客の免許証番号、カード番号、顧客が保有する口座の口座情報（例えば、口座種別、口座番号、名義など）を含んでもよい。

顧客情報は、例えば、ユーザの生体的特徴に関する生体情報（例えば、ユーザの顔画像データ、指紋情報、眼球の虹彩情報又は声紋情報など）を含んでもよい。

（４）決済装置１００は、店舗評価と顧客評価を対比して、すなわちクロスチェックをして、このクロスチェックの結果に基づいて店舗評価を調整する。ここで「店舗評価」とは、顧客に対する店舗による評価である。またここで「顧客評価」とは、店舗に対する顧客による評価である。

（５）決済装置１００は、（ア）顧客の属性と、（イ）調整した顧客の店舗評価を、店舗端末３００に送信する。（６）店舗端末３００は、受信した顧客の属性および店舗評価と、取引への複数の対処方法を画面に出力する。

「取引への（複数の）対処方法」とは、顧客と店舗との間の取引にあたって、顧客の属性や店舗評価などを店舗が確認した際に顧客に対してとりうる対処方法をいう。取引への対処方法（以下、単に「対処方法」ともいう）は、店舗の形態や規模などに応じて適宜設定されればよい。対処方法は、例えば、（ア）取引を承認すること、（イ）取引を一定期間保留すること、（ウ）取引を拒否すること、または（エ）顧客に対して評価することの少なくともいずれかを含んでもよい。なお「一定期間」とは、例えば、顧客の本人確認ができるまでの期間としてもよい。

（７）店舗端末３００は、店舗から複数の対処方法のうち店舗が採用する対処方法の選択を受け付ける。

具体的には、店舗が、画面に出力された顧客の属性と実際の顧客とのギャップの有無をチェックする。店舗は、このチェックの結果に基づいて、画面に出力された複数の対処方法のうち採用する対処方法を選択する。例えば、ギャップが無いと店舗が判断した場合は、上記（ア）の対処方法を選択する、また多少のギャップは有るけれども即座に取引を拒否するまでではないと店舗が判断した場合は、上記（イ）の対処方法を選択する、またギャップが有って取引を続行できないと店舗が判断した場合は、上記（ウ）の対処方法を選択する。店舗端末３００は、これらの選択を、画面を介して店舗から受け付ける。

（８）店舗端末３００は、上記（７）の選択の結果を決済装置１００に送信する。決済装置１００は、この選択の結果を受け付ける。

（９）上記（７）において（イ）が選択された場合、決済装置１００は、顧客に対する本人確認を行うため、顧客端末２００または店舗端末３００に本人確認を要求する。なお決済装置１００は、例えば、店舗端末３００を介して顧客端末２００に本人確認を要求してもよい。決済装置１００は、これらの本人確認の要求に対する応答を受け付ける。

（１０）決済装置１００は、上記（７）の（ア）が選択された場合、または上記（７）の（イ）が選択されて顧客の本人確認ができた場合、支払い決済のための処理を行う。

（１）つぎに図３を参照して顧客と店舗との取引後の際の決済サービスの流れを説明する。図３に示すように、取引後に、店舗と顧客は相互にそれぞれの評価を顧客端末２００と店舗端末３００に入力する。顧客端末２００と店舗端末３００は、それぞれ入力された評価を受け付ける。（２）顧客端末２００と店舗端末３００は、決済装置１００に、それぞれの評価を送信する。決済装置１００は、送信されたそれぞれの評価を受け付ける。

（３）決済装置１００は、上記（２）で受け付けた評価について、店舗評価情報と顧客評価情報それぞれにおいて、新規レコード登録または既存レコードに対する更新を行う。

「店舗評価情報」とは、店舗による顧客に対する評価（以下、「店舗評価）」ともいう）を示す情報である。店舗評価は、例えば、店舗の各店員による評価であってもよい。店舗評価情報は、例えば、所定期間（例えば、過去３か月または過去１年間等の期間）における店舗評価の実績を含んでもよい。

「顧客評価情報」とは、顧客による店舗に対する評価（以下、「顧客評価」ともいう）を示す情報である。顧客評価情報、例えば、所定期間における顧客評価の実績を含んでもよい。

（４）決済装置１００は、受け付けた評価に基づいて、顧客と店舗それぞれにインセンティブを付与する。決済装置１００は、具体的には、顧客と店舗それぞれにインセンティブ情報を送信する。ここで「インセンティブ情報」とは、顧客と店舗それぞれに付与するインセンティブを示す情報である。インセンティブ情報の詳細は後述する。また決済装置１００は、受け付けた評価に基づいて、店舗にフィードバックを行う。決済装置１００は、具体的には、店舗端末３００にその店舗の顧客情報を送信して、店舗端末３００の画面に出力する。

上記構成によれば、決済装置１００は、顧客と店舗との間の対面取引において、決済手段によらずに、出力された顧客の属性と実際の顧客とを比較して顧客の本人確認ができる。このため上記構成によれば、決済装置１００は、店頭での対面取引におけるなりすましなどのリスクを低減することができる。また上記構成によれば、店舗は、この本人確認の結果をふまえて、出力された複数の対処方法のうち店舗が採用する対処方法を選択することができる。

＜３．機能構成＞
図４を参照して、本実施形態に係る決済装置１００の機能構成を説明する。図４に示すように、決済装置１００は、制御部１１０と、記憶部１３０と、通信部１４０と、を備える。

制御部１１０は、決済受付部１１１と、出力部１１２と、選択受付部１１３と、決済処理部１１４と、を備える。制御部１１０は、例えば、評価受付部１１５、算出部１１６、本確要求部１１７、本確受付部１１８、本確部１１９、調整部１２０、または付与部１２１を備えてもよい。

決済受付部１１１は、顧客と店舗との間の取引の支払いの際、顧客端末２００または店舗端末３００から、支払いの決済要求を受け付ける。

決済受付部１１１は、例えば、商品などの代金の支払い決済において店舗提示型（ＭＰＭ（Ｍｅｒｃｈａｎｔ－Ｐｒｅｓｅｎｔｅｄ－Ｍｏｄｅ））のＱＲコード決済を用いる場合は、ＱＲコードを生成してもよい。決済受付部１１１は、生成したＱＲコードを店舗端末３００に送信する。店舗端末３００は、受信したＱＲコードを画面に表示して、顧客端末２００に読み取らせる。顧客端末２００は、読み取ったＱＲコードに含まれる情報に基づいて、支払いの決済要求を決済装置１００に送信する。決済装置１００は、この支払いの決済要求を受け付ける。

出力部１１２は、属性情報を記憶する記憶部を参照して、決済受付部１１１が決済要求を受け付けた際に、店舗端末３００に、顧客の属性と取引への複数の対処方法を出力する。なおここでいう「記憶部」は、後述の記憶部１３０であってもよいし、外部装置の記憶部であってもよい（以下、同じとする）。また出力部１１２が店舗端末３００に各種情報を出力する態様は、どの様な態様でもよい。出力部１１２は、例えば、店舗端末３００に属性情報と対処方法情報とを送信して、店舗用アプリや決済サイトを介して店舗端末３００の画面に顧客の属性と取引への複数の対処方法を出力してもよい。ここで「対処方法情報」とは、複数の対処方法を示す情報である。

上記構成によれば、店舗は、顧客と店舗との間の対面取引において、決済手段によらずに、出力された顧客の属性と実際の顧客とを比較して顧客の本人確認ができる。このため上記構成によれば、店頭での対面取引におけるなりすましなどのリスクを低減することができる。また上記構成によれば、店舗は、この本人確認の結果をふまえて、出力された複数の対処方法のうち店舗が採用する対処方法を選択することができる。

複数の対処方法は、例えば、取引を拒否すること、または取引に対して評価をすることの少なくともいずれかを含んでもよい。

出力部１１２は、例えば、店舗評価情報を記憶する記憶部を参照して、決済受付部１１１が決済要求を受け付けた際に、店舗端末３００に、取引相手の顧客の店舗評価を出力してもよい。出力部１１２は、例えば、取引相手の顧客の店舗評価が所定の閾値より低い場合に、決済受付部１１１が決済要求を受け付けた際に、店舗端末３００に、注意を促すワーニングを出力してもよい。店舗評価情報は店舗による顧客に対する評価を示すため、このような構成によれば、店舗の店員に、取引相手の顧客に対する評価により、当該顧客に対する注意を促すことができる。

出力部１１２は、例えば、顧客評価情報を記憶する記憶部を参照して、店舗端末３００に、店舗自身の顧客評価を出力してもよい。顧客評価情報は顧客による店舗に対する評価を示すため、このような構成によれば、顧客からの評価を店舗にフィードバックをすることができる。

出力部１１２は、例えば、後述の算出部１１６が算出した各取引のリスクレベルを店舗端末３００に出力してもよい。

出力部１１２は、例えば、顧客端末２００や店舗端末３００それぞれに、後述の評価受付部１１５がそれぞれから評価を受け付けるための画面を出力させてもよい。

選択受付部１１３は、店舗端末３００から、複数の対処方法のうち店舗が採用する対処方法の選択を受け付ける。

決済処理部１１４は、店舗から選択された対処方法が所定の条件を満たす場合、決済受付部１１１が受け付けた決済要求に基づいて、支払いの決済のための処理を行う。

決済処理部１１４は、例えば、クレジットカード決済やデビットカード決済などのカード決済、カードレス払い決済、電子マネー決済、銀行振込決済などの決済方法うち顧客が選択した決済方法に応じて決済のための処理を行ってもよい。

「所定の条件」は、例えば、取引が拒否されていないことを含んでもよい。また、所定の条件は、取引が保留されていないことを含んでもよい。また所定の条件は、取引相手（顧客）の信頼度が所定の閾値を超えていることを含んでもよい。ここで「信頼度」とは、取引における顧客に対する信頼の度合いを示すものである。信頼度の詳細は後述する。

上記構成によれば、決済処理部１１４は、本人確認の結果をふまえて店舗が採用した対処方法が所定の条件を満たす場合に限り、支払いの決済のための処理を行うことができる。このため上記構成によれば、決済処理部１１４は、例えば、本人確認の結果をふまえて店舗が「取引を拒否する」とする対処方法を採用した場合、支払いの決済のための処理を行いないため、対面取引のリスクを低減することができる。

決済処理部１１４は、例えば、さらに後述の本確部１１９による本人確認の結果に基づいて、支払いの決済のための処理を行ってもよい。

上記構成によれば、顧客の信頼度に応じて追加の本人確認を行った結果をふまえて、決済処理部１１４は、支払いの決済のための処理を行うことができる。

評価受付部１１５は、店舗端末３００から、店舗評価を受け付ける。店舗評価は、例えば、１～５の５段階の数値評価（１から５にかけて昇順で評価が設定され、１が最も評価が低く（悪く）、５が最も評価が高い（良い）とする。以下、同じ。）としてもよい。

評価受付部１１５は、例えば、次の（１）～（４）のいずれか一つ、またはいずれか二つ以上の組み合わせにより店舗評価を受け付けてもよい。
（１）出力された顧客の属性との一致状況（本人、不明、怪しい、違いそうなど）
（２）顧客による購買や取引の不審状況（正常、不自然な大量購入、危険物購入など）
（３）顧客の挙動に関する状況（正常、不審行動あり、粗暴、トラブル発生など）
（４）顧客そのものの認知（常連客などの知人や顔見知り、見慣れない利用者など）

評価受付部１１５は、例えば、さらに、顧客端末２００から、顧客評価を受け付けてもよい。顧客評価は、例えば、１～５の５段階の数値評価としてもよい。

評価受付部１１５は、例えば、次の（１）～（３）のいずれか一つ、またはいずれか二つ以上の組み合わせにより店舗評価を受け付けてもよい。
（１）取引の総合評価（例えば、５段階の数値評価、簡易なコメントなど）
（２）店舗の業種情報を取得することで、業種に応じた評価（例えば、飲食店などでは味・サービス・清潔度、一般店舗は品ぞろえ・清潔度・接客など）
（３）店員などへの評価（例えば、５段階の数値評価、簡易なコメントなど）

算出部１１６は、店舗評価に基づいて、顧客ごとにその信頼度を算出する。算出部１１６は、例えば、所定期間蓄積された店舗評価の統計値（例えば、平均値、中央値、または最頻値など）により信頼度を算出してもよい。なお本実施形態では、説明を簡単にするために、信頼度をＡ～Ｅの５段階とする例を用いるがこれに限る趣旨ではない。この５段階では、ＡからＥにかけて降順で評価が設定され、Ａが最も評価が高く（良く）、Ｅが最も評価が低い（悪い）するとする。算出部１１６は、例えば、店舗評価１～５と信頼度Ｅ～Ａを対応付けて記憶する記憶部を参照して、顧客の所定期間における店舗評価の中央値が「４」の場合、それに対応する信頼度「Ｂ」をその顧客の信頼度として算出してもよい。

算出部１１６は、例えば、後述の調整部１２０に調整された店舗評価に基づいて、信頼度を算出してもよい。

上記構成によれば、算出部１１６は、店舗による一方的な顧客に対する店舗評価ではなく、店舗評価と顧客評価とのクロスチェックの結果により調整された店舗評価に基づいて顧客の信頼度を算出することができる。このため上記構成によれば、算出部１１６は、より精度よく顧客の信頼度を算出することができる。

算出部１１６は、例えば、顧客の信頼度や取引履歴に基づいて、各取引のリスクレベルを算出してもよい。算出部１１６は、例えば、顧客ごとの取引履歴情報を入力して構築する分類モデルにより、各取引をリスクレベル別に分類してもよい。ここで「取引履歴情報」とは、所定期間における各取引の取引履歴を示す情報である。またここで「取引履歴」とは、所定期間における顧客と店舗との間の各取引の内容（例えば、取引日時、取引対象の商品など、取引先の顧客の顧客識別情報、取引金額（決済金額）、決済方法など）を示すものである。

算出部１１６は、例えば、信頼度や取引履歴情報の特徴量を入力して分類モデルを構築してもよい。具体的には、まず算出部１１６は、信頼度や取引履歴を説明変数とし、リスクレベル１～Ｎ（Ｎを特定の数値とし、Ｎ以内かつ所定の数値以上は許容範囲外としてリスクとする）の分類クラスを目的変数としてそれぞれの特徴量を抽出する。

つぎに算出部１１６は、これらの抽出された特徴量を組み合わせて学習データとする。算出部１１６は、つぎに、当該学習データを用いて機械学習（例えば、ＳＶＭ、ベイジアンフィルタ、決定木構築のためのＩＤ３などの学習技法）により学習させて分類クラスを定義する分類モデルを構築する。

つぎに算出部１１６は、この構築された分類モデルを記憶部に記憶させる。

つぎに算出部１１６は、各取引を、信頼度や各取引の内容を示す取引情報の特徴量に基づき、記憶部に記憶された分類モデルを用いてリスクレベル１～Ｎの分類クラスに分類する。このようにして、算出部１１６は、各取引のリスクレベルを算出してもよい。

上記では教師あり学習の例を説明したが、算出部１１６は、他の例として、教師なし学習として、取引情報を入力して主成分分析およびクラスタリングを利用して構築した分類モデルにより、各取引をリスクレベル別に分類する方法を用いることも考えられる。

本確要求部１１７は、決済受付部１１１が決済要求を受け付けた際に、顧客の信頼度が所定の閾値（例えば、信頼度「Ｄ」など）より低い場合、顧客端末２００または店舗端末３００に、顧客に対する本人確認の要求を行う。すなわち本確要求部１１７は、顧客の属性と対面する顧客との比較による本人確認に加えて顧客の本人確認を行うことができる。

本確要求部１１７は、例えば、顧客や店舗がログインする決済サイトに本人確認を要求するメッセージを表示してもよいし、顧客用アプリまたは店舗用アプリにより本人確認を要求するメッセージをプッシュ通知してもよいし、顧客のメールアドレスやＳＮＳアカウントに本人確認を要求するメッセージを送信してもよい。

本確受付部１１８は、店舗端末３００、または店舗端末３００からさらに本人確認を要求された顧客端末２００から、確認情報を含む要求に対する応答を受け付ける。

「確認情報」とは、顧客が顧客本人であることを確認するための情報である。確認情報は、例えば、本人確認の要素（知識、所有物、生体）を示すものであってもよい。

確認情報は、例えば、本人の知識要素として、本人のみが知りうる情報（例えば、事前に登録した暗証番号（ＰＩＮコードを含む）もしくは秘密の合言葉、または電話番号の一部などであってもよい（知識認証）。

確認情報は、本人の所有物要素として、クレジットカードなどの各種決済用のカード、ＮＦＣタグ内蔵の顧客端末２００やカードなどであってもよい（所有物認証）。

確認情報は、例えば、本人の生体要素として、事前に登録した指紋や静脈パターンや容貌であってもよい（生体認証）。

確認情報は、例えば、多要素認証のため、上記複数の種類の本人確認の要素を組み合わせてもよい（例えば、クレジットカードとＰＩＮコードの組み合わせなど）。

確認情報は、例えば、個人情報が確認できる個人番号カード（マイナンバーカード）、運転免許証、パスポート、住民基本台帳カード（ユーザの顔写真付きのもの）などの画像データであってもよい。

本確部１１９は、確認情報に基づいて、顧客の本人確認を行う。

調整部１２０は、店舗評価と顧客評価を対比して、対比の結果に基づいて店舗評価を調整する。調整部１２０は、例えば、所定期間における顧客ごとの店舗評価の統計値とこの顧客の顧客評価とを対比してもよい。調整部１２０は、例えば、所定期間における店舗ごとの顧客評価の統計値とこの店舗の店舗評価とを対比してもよい。

調整部１２０は、例えば、顧客評価の統計値に基づいて店舗それぞれにおける店舗評価に対する重み付けを変えて調整してもよい。例えば、統計値「１」は重み「０．８」、統計値「２」は重み「０．８５」、統計値「３」は重み「０．９」、統計値「４」は重み「０．９５」、統計値「５」は重み「１」としてもよい。調整部１２０は、例えば、顧客評価の統計値が「１」の店舗の場合その店舗の店舗評価には重み「０．８」として、他方顧客評価の統計値が「５」の店舗の場合その店舗の店舗評価には重み「１」としてもよい。調整部１２０は、このように店舗ごとに重み付けをして所定期間における店舗評価の加重平均を算出してもよい。調整部１２０は、この算出した加重平均の値を、調整された店舗評価としてもよい。

調整部１２０は、例えば、上記対比の結果に基づいて、顧客評価を調整してもよい。調整部１２０は、例えば、上記店舗評価と同様に、店舗評価の統計値に基づいて顧客それぞれにおける顧客評価に対する重み付けを変えて調整してもよい。

調整部１２０は、例えば、店舗の所在地や顧客の居住地（住所）に基づいて、店舗評価や顧客評価に対する重み付けを変えて調整してもよい。調整部１２０は、例えば、店舗の業種に基づいて、店舗評価に対する重み付けを変えて調整してもよい。

上記構成によれば、調整部１２０は、地域性（例えば、都会と地方との差）や店舗の業種をふまえて、店舗評価や顧客評価を調整することができる。例えば、都会と比較して地方におけるお互いに顔の見える取引環境では、（相手を知っているがゆえに）相互に評価が適切に反映される可能性が高い。他方、地方と比較して都会における顔の見えない環境では（相手を知らないがゆえに）評価への雑音が混じる可能性が高い。上記構成によれば、調整部１２０は、このような地域差や業種差をふまえて調整することができる。

付与部１２１は、調整部１２０により調整された店舗評価に基づいて、顧客にインセンティブを付与する。ここで「インセンティブ」とは、例えば、決済サービスで利用可能なポイントや商品などを割引するクーポンであってもよい。付与部１２１は、具体的には、記憶部１３０が記憶する付与対象の顧客の顧客情報に、付与するポイントまたはクーポンを示すインセンティブ情報を関連付けて記憶してもよい。

上記構成によれば、付与部１２１は、一方的な店舗評価ではなく顧客評価とのクロスチェックをかけた店舗評価によりインセンティブを付与することができる。このため上記構成によれば、付与部１２１は、店舗の恣意的な、また悪意のある評価を是正した店舗評価により顧客にインセンティブを付与することができる。

インセンティブとは、例えば、顧客の口座への所定金額の振込であってもよい。付与部１２１は、付与対象の顧客の顧客情報に、振込金額を示すインセンティブ情報を関連付けて記憶してもよい。付与部１２１は、例えば、決済サービスの利用手数料（以下、単に「利用手数料」ともいう）を減額させる権利を顧客に付与してもよい。付与部１２１は、例えば、当該権利として、利用手数料の割引等の特典、または利用手数料の支払いに使用できるポイントを顧客に付与してもよい。付与部１２１は、他の例として、顧客に対して利用手数料を減免してもよい。

付与部１２１は、例えば、調整部１２０により調整された顧客評価に基づいて、店舗にインセンティブを付与してもよい。ここで「インセンティブ」とは、顧客へのインセンティブと同様に、決済サービスの利用手数料を減額させる権利であってもよいし、店舗が指定する口座への所定金額の振込であってもよい。

上記構成によれば、付与部１２１は、一方的な顧客評価ではなく店舗評価とのクロスチェックをかけた顧客評価によりインセンティブを付与することができる。このため上記構成によれば、付与部１２１は、顧客の恣意的な、また悪意のある評価を是正した顧客評価により店舗にインセンティブを付与することができる。

付与部１２１は、例えば、店舗評価と、その店舗評価の評価後（評価受付部１１５による受け付け後）に同一および／または他の店舗において選択された対処方法と、に基づいて、インセンティブを付与してもよい。

付与部１２１は、例えば、顧客Ａに対して店舗評価を「１」と評価し、その評価後に複数の店舗において顧客Ａとの取引において「取引を拒否すること」とする対処方法が店舗により選択された場合、適切な評価によって不正抑止につながったとしてインセンティブを付与してもよい（またはインセンティブのグレードを上げてもよい）。

上記構成によれば、店舗による恣意的な評価や取引を阻害する評価を抑止することができる。

記憶部１３０は、顧客情報、属性情報、店舗評価情報、顧客評価情報、対処方法情報、インセンティブ情報、取引情報もしくは取引履歴情報、または分類モデルなどを記憶してもよい。記憶部１３０は、例えば、これらの情報を相互に関連付けて記憶してもよい。記憶部１３０は、データベースマネジメントシステム（ＤＢＭＳ）を利用して各情報を記憶してもよいし、ファイルシステムを利用して各情報を記憶してもよい。ＤＢＭＳを利用する場合は、上記情報ごとにテーブルを設けて、このテーブル間を関連付けて各情報を管理してもよい。

通信部１４０は、ネットワークＮを介して、顧客端末２００および／または店舗端末３００に各種情報を送受信する。

＜４．動作例＞
図５を参照して、決済装置１００の動作例を説明する。なお、以下に示す処理の順番は一例であって、適宜、変更されてもよい。

図５に示すように、決済装置１００の決済受付部１１１は、顧客と店舗との間の取引の支払いの際、顧客端末２００または店舗端末３００から、支払いの決済要求を受け付ける（ステップＳ１０）。出力部１１２は、属性情報を記憶する記憶部１３０を参照して、決済受付部１１１が決済要求を受け付けた際に、店舗端末３００に、顧客の属性と取引への複数の対処方法を出力する（ステップＳ１１）。

選択受付部１１３は、店舗端末３００から、複数の対処方法のうち店舗が採用する対処方法の選択を受け付ける（ステップＳ１２）。

選択された対処方法が「顧客に対する評価をすること」の場合（ステップＳ１３の「顧客に対する評価」の場合）、評価受付部１１５は、店舗端末３００から、店舗評価を受け付ける（ステップＳ１４）。

選択された対処方法が「本人確認ができるまでの期間取引を保留にすること」の場合（ステップＳ１３の「本人確認」の場合）、本確要求部１１７は、顧客端末２００または店舗端末３００に、本人確認の要求を行う（ステップＳ１５）。本確受付部１１８は、店舗端末３００または顧客端末２００から、顧客が顧客本人であることを確認するための確認情報を含む上記本人確認の要求に対する応答を受け付ける（ステップＳ１６）。

本確部１１９において顧客の本人確認ができた場合（ステップ１７の「ＯＫ」の場合）、または評価受付部１１５が店舗評価を受け付けた場合、決済処理部１１４は、支払いの決済のための処理を行う。

選択された対処方法が「取引を拒否すること」の場合（ステップＳ１３の「取引を拒否する」の場合）、または、本確部１１９において顧客の本人確認ができなかった場合（ステップＳ１７の「ＮＧ」の場合）、決済処理部１１４は、支払い決済をキャンセルする（ステップＳ１９）。

出力部１１２は、決済処理の結果（例えば、支払いの決済完了など）や本人確認の結果（ＯＫまたはＮＧ）などを店舗端末３００に出力する。

＜５．ハードウェア構成＞
図６を参照して、上述してきた決済装置１００をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。

図６に示すように、コンピュータ８００は、プロセッサ８０１と、メモリ８０３と、記憶装置８０５と、入力Ｉ／Ｆ部８０７と、データＩ／Ｆ部８０９と、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。

プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、決済装置１００の制御部１１０が備える各機能部などは、メモリ８０３に一時記憶されたプログラムを、プロセッサ８０１が実行することにより実現可能である。

メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリなどの不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、顧客情報や確認情報などの各種情報を登録するテーブルと、当該テーブルを管理するＤＢを記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。

入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイスなどが挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などのインタフェースを介してコンピュータ８００に接続されても良い。

データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置などがある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢなどのインタフェースを介してコンピュータ８００へと接続される。

通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線または無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢなどのインタフェースを介してコンピュータ８００に接続される。

表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイなどが挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブルなどを介してコンピュータ８００に接続される。また、入力Ｉ／Ｆ部８０７としてタッチパネルが採用される場合には、表示装置８１３は、入力Ｉ／Ｆ部８０７と一体化して構成することが可能である。

なお、本実施形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均などなものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。

また、上記実施の形態で記載された決済装置が備える構成要素は、記憶装置８０５に格納されたプログラムがプロセッサ８０１によって実行されることで、定められた処理が他のハードウェアと協働して実現されるものとする。また、言い換えれば、これらの構成要素は、ソフトウェアまたはファームウェアとしても、それと対応するハードウェアとしても想定され、その双方の概念において、「機能」、「手段」、「部」、「処理回路」、「ユニット」、または「モジュール」などとも記載され、またそれぞれに読み替えることができる。

［変形例］
なお、本発明を上記実施の形態に基づいて説明してきたが、以下のような場合も本発明に含まれる。

（１）上記実施形態では、店舗における顧客との取引の例を説明したが、これに限定されない。決済システム１は、例えば、交通機関利用（バス乗車時の乗車賃の支払い）、またはその他の施設利用の際の支払いにおける決済に用いてもよい。

（２）上記実施形態に係る決済装置１００が備える各構成の少なくとも一部は、顧客端末２００または店舗端末３００が備えていてもよい。顧客端末２００または店舗端末３００は、例えば、それぞれがインストールする顧客用アプリまたは店舗用アプリを実行することでこれらの構成を実現させてもよい。

１…決済システム、１００…決済装置、１１０…制御部、１１１…決済受付部、１１２…出力部、１１３…選択受付部、１１４…決済処理部、１１５…評価受付部、１１６…算出部、１１７…本確要求部、１１８…本確受付部、１１９…本確部、１２０…調整部、１２１…付与部、１３０…記憶部、１４０…通信部、２００…顧客端末、３００…店舗端末、８００…コンピュータ、８０１…プロセッサ、８０３…メモリ、８０５…記憶装置、８０７…入力Ｉ／Ｆ部、８０９…データＩ／Ｆ部、８１１…通信Ｉ／Ｆ部、８１３…表示装置。

Claims (7)

1. 顧客の顧客端末、または前記顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続する決済装置であって、
   前記顧客と前記店舗との間の取引の支払いの際、前記顧客端末または前記店舗端末から、前記支払いの決済要求を受け付ける決済受付部と、
   前記店舗端末から、前記顧客に対する前記店舗による店舗評価であって前記顧客による取引の不審状況、前記顧客の挙動に関する状況、または顧客そのものの認知の少なくともいずれかによる店舗評価を受け付ける評価受付部と、
   前記店舗評価に基づいて、顧客ごとにその信頼度を算出する算出部と、
   前記決済受付部が前記決済要求を受け付けた際に、前記信頼度が所定の閾値より低い場合、前記店舗端末または前記顧客端末に、前記顧客に対する本人確認の要求を行う本確要求部と、
   前記店舗端末または前記顧客端末から、前記顧客が前記顧客本人であることを確認するための確認情報を含む前記要求に対する応答を受け付ける本確受付部と、
   前記確認情報に基づいて、前記顧客の本人確認を行う本確部と、
   前記決済要求と前記本人確認の結果に基づいて、前記支払いの決済のための処理を行う決済処理部と、を備える、
   決済装置。
2. 前記顧客の属性を示す属性情報を記憶する記憶部を参照して、前記決済受付部が前記決済要求を受け付けた際に、前記属性と、前記取引への複数の対処方法であって、前記取引を拒否すること、または前記顧客に対して評価をすることの少なくともいずれかを含む前記複数の対処方法と、を、前記店舗端末に出力する出力部と、
   前記店舗端末から、前記複数の対処方法のうち前記店舗が採用する対処方法の選択を受け付ける選択受付部と、
   前記決済処理部は、前記取引が拒否されていないこと、または前記評価に基づく前記信頼度が所定の閾値を超えていることの少なくともいずれかを含む所定の条件を前記選択された対処方法が満たす場合、前記支払いの決済のための処理を行う、
   請求項１に記載の決済装置。
3. 前記評価受付部は、さらに、前記顧客端末から、前記店舗に対する前記顧客による顧客評価を受け付け、
   前記決済装置は、前記店舗評価と前記顧客評価を対比して、対比の結果に基づいて前記店舗評価を調整する調整部をさらに備え、
   前記算出部は、前記調整された店舗評価に基づいて、前記信頼度を算出する、
   請求項１または２に記載の決済装置。
4. 前記調整された店舗評価に基づいて、前記顧客にインセンティブを付与する付与部をさらに備える、
   請求項３に記載の決済装置。
5. 前記調整部は、前記対比の結果に基づいて前記顧客評価を調整し、
   前記付与部は、前記調整された顧客評価に基づいて、前記店舗にインセンティブを付与する、
   請求項４に記載の決済装置。
6. 顧客の顧客端末、または前記顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続するコンピュータに、
   前記顧客と前記店舗との間の取引の支払いの際、前記顧客端末または前記店舗端末から、前記支払いの決済要求を受け付ける決済受付機能と、
   前記店舗端末から、前記顧客に対する前記店舗による店舗評価であって前記顧客による取引の不審状況、前記顧客の挙動に関する状況、または顧客そのものの認知の少なくともいずれかによる店舗評価を受け付ける評価受付機能と、
   前記店舗評価に基づいて、顧客ごとにその信頼度を算出する算出機能と、
   前記決済受付機能が前記決済要求を受け付けた際に、前記信頼度が所定の閾値より低い場合、前記店舗端末または前記顧客端末に、前記顧客に対する本人確認の要求を行う本確要求機能と、
   前記店舗端末または前記顧客端末から、前記顧客が前記顧客本人であることを確認するための確認情報を含む前記要求に対する応答を受け付ける本確受付機能と、
   前記確認情報に基づいて、前記顧客の本人確認を行う本確機能と、
   前記決済要求と前記本人確認の結果に基づいて、前記支払いの決済のための処理を行う決済処理機能と、を実現させる、
   プログラム。
7. 顧客の顧客端末、または前記顧客に商品販売もしくは役務提供を行う店舗の店舗端末とネットワークを介して接続するコンピュータが、
   前記顧客と前記店舗との間の取引の支払いの際、前記顧客端末または前記店舗端末から、前記支払いの決済要求を受け付け、
   前記店舗端末から、前記顧客に対する前記店舗による店舗評価であって前記顧客による取引の不審状況、前記顧客の挙動に関する状況、または顧客そのものの認知の少なくともいずれかによる店舗評価を受け付け、
   前記店舗評価に基づいて、顧客ごとにその信頼度を算出し、
   前記決済要求が受け付けられた際に、前記信頼度が所定の閾値より低い場合、前記店舗端末または前記顧客端末に、前記顧客に対する本人確認の要求を行い、
   前記店舗端末または前記顧客端末から、前記顧客が前記顧客本人であることを確認するための確認情報を含む前記要求に対する応答を受け付け、
   前記確認情報に基づいて、前記顧客の本人確認を行い、
   前記決済要求と前記本人確認の結果に基づいて、前記支払いの決済のための処理を行う、
   情報処理方法。
   

Images