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

Abstract

【課題】後払いサービスを利用するユーザにとって適切な利用上限金額を決定することができる情報処理装置、情報処理方法、および情報処理プログラムを提供する。【解決手段】実施形態に係る情報処理装置は、選択要求部と、上限枠決定部とを有する。選択要求部は、代金の支払い時に、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザに選択させる。上限枠決定部は、後払いを可能とする金額の上限枠を少なくともチャージ残高の利用状況に基づいて決定する。【選択図】図１

Description

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

電子マネーを用いて代金を支払う電子決済サービスが知られている。たとえば、電子決済サービスの一種として、利用者が携帯する端末装置を用いて２次元コード等を表示または読み取ることで決済を行う手法（たとえば、スマホ決済）が知られている。

また、電子決済サービスにおいてユーザが後払いサービスを希望する場合に、ユーザ毎の後払いサービスの最大利用金額を定めておき、その範囲内で複数の金額をユーザに提示して、後払いサービスの利用上限金額をユーザに決定させる情報処理装置が知られている。

特開２０２０－１２６４４５号公報

しかしながら、ユーザによって決定される後払いサービスの利用上限金額が、必ずしもユーザにとって適切な利用上限金額であるとは限らない。

本願は、上記に鑑みてなされたものであって、後払いサービスを利用するユーザにとって適切な利用上限金額を決定することができる情報処理装置、情報処理方法、および情報処理プログラムを提供することを目的とする。

実施形態の一態様に係る情報処理装置は、選択要求部と、上限枠決定部とを有する。選択要求部は、代金の支払い時に、電子マネーのチャージ残高から支払う即時払い後払いをユーザに選択させる。上限枠決定部は、前記後払いを可能とする金額の上限枠を少なくとも前記チャージ残高の利用状況に基づいて決定する。

実施形態の一態様によれば、後払いサービスを利用するユーザにとって適切な利用上限金額を決定することができる情報処理装置、情報処理方法、および情報処理プログラムを提供することができる。

図１は、実施形態に係る情報処理方法の概要を示す図である。 図２は、実施形態に係る情報処理装置の構成例を示す図である。 図３は、実施形態に係るユーザ情報の一例を示す図である。 図４は、実施形態に係るユーザ情報の一例を示す図である。 図５は、実施形態に係る提案部による表示画面例を示す図である。 図６は、実施形態に係る提案部による表示画面例を示す図である。 図７は、実施形態に係る情報処理装置が実行する決済処理の一例を示すフローチャートである。 図８は、実施形態に係る情報処理装置の制御部が実行する即時決済処理の一例を示すフローチャートである。 図９は、実施形態に係る情報処理装置の制御部が実行する後払い決済処理の一例を示すフローチャートである。 図１０は、実施形態に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と記載する。）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。

［１．情報処理方法の概要］
図１は、実施形態に係る情報処理方法の概要を示す図である。実施形態に係る情報処理装置は、例えば、ユーザが購入した商品または利用したサービスの代金を即時払いまたは後払いの支払い方法によって支払う電子決済サービスを提供する装置である。

即時払いは、ユーザによって予めチャージされた電子マネーのチャージ残高から代金をその場で支払う支払方法である。後払いは、電子決済サービスの事業者が代金を支払い、予め登録されたユーザの銀行口座から後日代金を引き落として代金を回収する支払方法である。

後払いは、支払金額に利子が加算されるが、現金の持ち合わせがない場合やチャージ残高が不足している場合であっても商品の購入やサービスの利用が可能であるため、ユーザにとっては便利な支払方法である。

一方、電子決済サービスを提供する事業者にとっては、利子による利益を得ることができる反面、支払金額の滞納により代金の回収ができなくなるリスクもある。このため、後払いには、利用金額の上限枠（与信）が設定されることが一般的である。

利用金額の上限枠は、ユーザの年齢、職業、勤続年数、および年収などによる事前審査によって決定されることが一般的である。しかし、ユーザの年齢、職業、勤続年数、および年収などが同じであっても、ユーザによって返済可能金額は異なる。

このため、利用金額の上限枠をユーザに決定させる決済サービスがあるが、ユーザによって決定される利用金額の上限枠が、必ずしもユーザにとって適切な利用上限金額であるとは限らない。また、一般的なクレジットカードの与信審査の場合、クレジットカードを利用するために与信審査を通さなければならないため、そもそも与信審査にクレジットカードの利用履歴を使用することができない。このため、クレジットカードの場合は、対象ユーザの年齢、職業、勤続年数、および年収などに基づいて、与信審査を行わなければならない。

これに対して、実施形態に係る電子決済サービスを提供する事業者は、既に電子決済サービスを利用しているユーザの利用実績を保有しているため、信頼性の高い利用履歴の情報を用いることで、適切な後払いの利用上限額を決定することが可能である。そこで、実施形態に係る情報処理装置は、図１に示す情報処理方法によってユーザにとって適切な後払いの利用上限額を決定する。

具体的には、ユーザ１１は、例えば、各種の商品やサービスといった決済対象の利用や購入を行った場合、自身の携帯端末装置（以下「ユーザ端末１２」と記載する）に予めインストールされた決済アプリ（アプリケーションプログラム）を起動する。

そして、ユーザ１１は、図１に示すように、決済アプリを使用して、店舗に設置された電子決済用の店舗コード（例えば、ＱＲコード（登録商標））１３をユーザ端末１２によって読み取り（ステップＳ１）、代金を入力する（ステップＳ２）。

店舗コード１３には、店舗を識別する識別情報が含まれる。なお、店舗コード１３は、ＱＲコードに限定されるものではなく、バーコードや所定のマーク、番号など（すなわち、所定のコード）であってもよい。その後、ユーザ端末１２は、店舗の識別情報および支払金額を示す情報を含む決済情報を情報処理装置１に送信する（ステップＳ３）。

情報処理装置１は、決済情報を受信すると、ユーザ１１によってチャージされた電子マネーのチャージ残高の利用状況に基づいて、後払いを可能とする金額の上限枠を決定する（ステップＳ４）。例えば、情報処理装置１は、１回のチャージ金額、チャージ残高の使用頻度、１回のチャージ残高の使用額、最低チャージ残高、および利用加盟店などに基づいて、ユーザの経済状態を推定し、推定結果に応じた金額の上限枠を決定する。

そして、情報処理装置１は、支払方法選択要求画面をユーザ１１のユーザ端末１２に表示させて、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザ１１に選択させる（ステップＳ５）。

このとき、情報処理装置１は、支払方法の選択肢として即時払いと後払いとを支払方法選択要求画面に表示させ、さらに即時払いに使用可能なチャージ残高と、後払いの上限枠とを支払方法選択要求画面に表示させる。

その後、ユーザ端末１２は、ユーザ１１によって支払方法が選択されると、支払方法決定情報を情報処理装置１に送信する（ステップＳ６）。情報処理装置１は、支払方法決定情報を受信すると、ユーザ１１によって選択された支払方法で決済処理を行う（ステップＳ７）。

情報処理装置１は、即時払いが選択された場合には、チャージ残高から代金分を店舗の口座へ即時に入金する。また、情報処理装置１は、後払いが選択された場合、ユーザ１１に代わって代金を店舗の口座に入金し、後日ユーザ１１の銀行口座から代金分を引き落として代金を回収する。情報処理装置１は、決済処理が完了した場合、ユーザ端末１２に決済完了通知を送信する（ステップＳ８）。

このように、情報処理装置１は、各ユーザ１１の経済状態によってそれぞれ異なるチャージ残高の利用状況に基づいて後払いの上限枠を決定することにより、後払いサービスを利用するユーザにとって適切な利用上限金額を決定することができる。

なお、情報処理装置１が行う決済処理は、上述した処理に限定されるものではない。例えば、情報処理装置１が行う決済処理は、店舗に設置された店舗端末を用いたものであってもよい。この場合、ユーザ１１のユーザ端末１２は、ユーザ１１を識別するためのユーザＩＤを画面上に表示する。店舗に設置された店舗者端末は、ユーザ端末１２に表示されたユーザＩＤを読み取り、ユーザＩＤと、決済金額と、店舗の識別情報とを示す決済情報を情報処理装置１へと送信する。情報処理装置１は、ユーザＩＤが示すユーザ１１のチャージ残高または銀行口座から、店舗の銀号口座へ代金を入金し、店舗端末或いはユーザ端末１２に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知する。

また、ユーザ１１のユーザ端末１２を用いた決済は、実店舗に対するものに限らず、たとえば、電子商取引サービスでの取引対象に対する決済（すなわち、オンライン決済）であってもよい。この場合、例えば、ユーザ端末１２は、ユーザ１１を識別するユーザＩＤと、店舗の識別情報と、取引対象の価格（決済金額）とを示す決済情報を情報処理装置１へと送信する。情報処理装置１は、ユーザＩＤが示すユーザ１１の銀行口座から、店舗の識別情報が示す店舗の銀行口座へと決済金額を入金し、ユーザ端末１２に対し決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知する。

［２．情報処理装置の構成］
次に、図２を参照して情報処理装置１の構成例について説明する。図２は、実施形態に係る情報処理装置の構成例を示す図である。実施形態に係る情報処理装置１は、通信ネットワークＮを介してユーザ端末１２、店舗端末１００、および銀行サーバ２００と有線または無線により相互に通信可能に接続される。

通信ネットワークＮは、たとえば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、ここでは図示を省略したが、情報処理装置１は、複数台のユーザ端末１２、複数台の店舗端末１００、および複数台の銀行サーバ２００と接続される。

ユーザ端末１２は、ユーザ１１によって利用される装置である。ユーザ端末１２は、たとえば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等により実現される。ユーザ端末１２は、情報処理装置１によって配信される情報を、ウェブブラウザやアプリにより表示する。

また、ユーザ端末１２は、所定の情報処理を実現する制御情報を情報処理装置１から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえば、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語やＣＳＳ（Cascading Style Sheets）等のスタイルシート言語、Ｊａｖａ（登録商標）等のプログラミング言語、ＨＴＭＬ（HyperText Markup Language）等のマークアップ言語等により記述される。なお、情報処理装置１から配信される所定のアプリそのものを制御情報とみなしてもよい。

店舗端末１００は、実施形態に係る電子決済サービスの加盟店に設置される端末装置である。店舗端末１００は、例えば、店舗において商品の購入またはサービスの利用を行ったユーザ１１が自身のユーザＩＤをユーザ端末１２に表示させて提示した場合に、ユーザＩＤを読み取る装置である。店舗端末１００は、読み取ったユーザＩＤと商品またはサービスの代金の金額とを含む決済情報を情報処理装置１に送信する。

銀行サーバ２００は、ユーザ１１の銀行口座を管理する銀行に属する装置である。銀行サーバ２００は、サーバ装置やクラウドシステム等により実現される。たとえば、銀行サーバ２００は、銀行口座の利用履歴として、各カード会社や、各種サービスの提供者による銀行口座からの引き落としに関する情報（引き落とした金額や、引き落とした日時等）や、現在の口座情報（口座残高等）などを、ユーザ１１に対応付けて管理する。

情報処理装置１は、サーバ装置やクラウドシステム等により実現される。例えば、情報処理装置１は、ユーザ１１のユーザ端末１２を用いて所定のコードを表示または読み取ることによって行われる電子決済に関する電子決済サービスを提供する。例えば、情報処理装置１は、ユーザ１１が所有する電子マネーのチャージ残高を管理しており、ユーザ１１からの決済情報に従って、チャージ残高から利用店舗の銀行口座に電子マネーの移動等を行うことで、即時払いの各種決済を実現する。また、情報処理装置１は、ユーザ１１からの決済情報に従って、代金を利用店舗の銀行口座に支払い、その後、所定の引き落とし日にユーザの銀行口座またはチャージ残高から代金を引き落として後払い決済を実現する。

なお、電子マネーとは、たとえば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。情報処理装置１は、通信部１０と、記憶部２０と、制御部３０とを有する。

（通信部）
通信部１０は、たとえば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部１０は、通信ネットワークＮを介してユーザ端末１２、店舗端末１００、および銀行サーバ２００等との間で有線または無線による情報の送受信を行う。

（記憶部）
記憶部２０は、たとえば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部２０は、ユーザ情報２１および学習モデル２２を記憶する。

（ユーザ情報）
図３および図４は、実施形態に係るユーザ情報の一例を示す図である。実施形態に係るユーザ２１情報は、各ユーザ１１による電子マネーのチャージ残高の利用状況を示す情報である。例えば、図３に示すように、ユーザ情報２１は、各ユーザＩＤに対して、後払いの登録状況、リボルビング（以下。「リボ」と記載する）払いの登録状況、電子決済サービスの利用日、利用店舗、入出金金額、支払方法、およびチャージ残高が対応付けられた情報を含む。リボ払いは、所定の利子が加算された後払い残高を毎月一定の金額ずつ返済する支払方法である。

ユーザＩＤは、各ユーザ１１の識別情報である。後払いの登録状況は、各ユーザ１１が支払方法として後払いを登録しているか否かを示す情報である。後払いの登録状況には、後払いの滞納があるか否かを示す情報も含まれる。

リボ払いの登録状況は、各ユーザ１１が支払方法としてリボ払いを登録しているか否かを示す情報である。リボ払いの登録状況は、リボ払いの滞納があるか否かを示す情報も含まれる。利用日は、各ユーザ１１が電子決済サービスを利用して、電子マネーのチャージまたは代金の支払いを行った年月日である。

利用店舗は、各ユーザ１１が商品の購入またはサービスの利用に電子決済サービスを使用した加盟店、または各ユーザが電子マネーのチャージや代金の支払いに使用した銀行である。支払方法は、各ユーザ１１が即時払いによる決済を行ったか、後払いによる決済を行ったかを示す情報である。

チャージ残高は、各ユーザ１１が電子決済サービスを利用した時点の電子マネーの残高である。また、チャージ残高には、ユーザ１１が電子マネーによる給与のチャージを設定している場合には、通常のチャージ残高とは別に管理される給与チャージ残高が含まれる。また、図４に示すように、ユーザ情報２１は、各ユーザＩＤに対応するユーザ１１の月毎の入出金額およびチャージ残高の推移を示す情報を含む。

（学習モデル）
学習モデル２２は、例えば、ＤＮＮ（Deep Neural Network）による機械学習手法によって構築されたもでるである。学習モデル２２は、延滞なくリボルビング払いを行っていたユーザ１１によるチャージ残高の利用状況を正解データとして機械学習し、任意のユーザ１１のチャージ残高の利用状況が入力された場合に、そのチャージ残高を保有するユーザの信頼度の高さに応じたスコアを出力する。

例えば、学習モデル２２は、後払いの延滞回数が少ないユーザ１１ほど高いスコアを出力し、後払いの延滞回数が多いユーザ１１ほど低いスコアを出力する。学習モデル２２は、リボ払いの延滞回数が少ないユーザ１１ほど高いスコアを出力し、リボ払いの延滞回数が多いユーザ１１ほど低いスコアを出力する。

学習モデル２２は、１回のチャージ金額の平均が高いユーザ１１ほど高いスコアを出力し、１回のチャージ金の平均が低いユーザ１１ほど低いスコアを出力する。学習モデル２２は、チャージ前のチャージ残高が高いユーザ１１ほど高いスコアを出力し、チャージ前のチャージ残高が低いユーザ１１ほど低いスコアを出力する。

学習モデル２２は、月毎の入出金額の移動平均が高いユーザ１１ほど高いスコアを出力し、月毎の入出金額の移動平均が低いユーザ１１ほど低いスコアを出力する。学習モデル２２は、月毎のチャージ残高の移動平均が高いユーザ１１ほど高いスコアを出力し、月毎のチャージ残高の移動平均が低いユーザ１１ほど低いスコアを出力する。

また、学習モデル２２は、電子決済サービスの使用頻度が高いユーザ１１ほど経済状態がよい可能性があるため高いスコアを出力し、使用頻度が低いユーザ１１ほど低いスコアを出力する。また、学習モデル２２は、チャージ残高の使用額が多いユーザ１１ほど経済状態がよい可能性があるため高いスコアを出力し、使用額が少ないユーザ１１ほど低いスコアを出力する。

また、給与チャージ残高は、不定期でチャージされる通常のチャージ残高とは違い、毎月確実にチャージされる。このため、学習モデル２２は、電子マネーによる給与のチャージを設定しているユーザ１１ほど高いスコアを出力し、電子マネーによる給与のチャージを設定していないユーザ１１ほど低いスコアを出力する。また、学習モデル２２は、毎月の給与のチャージ額が多いユーザ１１ほど高いスコアを出力し、毎月の給与のチャージ額が少ないユーザ１１ほど低いスコアを出力することもできる。

（制御部）
制御部３０は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報処理装置１内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。実施形態に係る制御部３０は、受付部３１と、上限枠決定部３２と、選択要求部３３と、提案部３４と、決済処理部３５ととを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（受付部）
受付部３１は、ユーザ端末１２または店舗端末１００から決済情報（図１参照）を受け付ける。決済情報には、ユーザＩＤ、電子決済サービスの利用日、利用店舗、および支払金額等の情報が含まれる。また、受付部３１は、ユーザ端末１２から支払方法確定情報（図１参照）を受け付ける。

（上限枠決定部）
上限枠決定部３２は、受付部３１によって決済情報が受け付けられると、決済情報を送信したユーザ１１による後払いを可能とする金額の上限枠を少なくともチャージ残高の利用状況に基づいて決定する。

例えば、上限枠決定部３２は、決済情報を送信したユーザ１１によるチャージ残高の利用状況を示すユーザ情報２１を学習モデル２２に入力し、学習モデル２２から出力されるスコアの高さに応じた上限枠を決定する。上限枠決定部３２は、スコアの高いユーザ１１ほど高い上限枠を決定し、スコアの低いユーザ１１ほど低い上限枠を決定する。

また、上限枠決定部３２は、チャージ残高の利用状況以外の情報に基づいて、後払いを可能とする金額の上限枠を決定することもできる。例えば、上限枠決定部３２は、決済情報を送信したユーザ１１が保有する銀行口座の残高を銀行サーバ２００から取得し、残高が多いユーザ１１ほど高い上限枠を決定し、残高が低いユーザ１１ほど低い上限枠を決定することもできる。

また、上限枠決定部３２は、例えば、高級ブランド品等の比較的高額の商品を取り扱う加盟店を主に利用するユーザほど高い上限枠を決定し、コンビニ等の比較的低額の商品を取り扱う加盟店を主に利用するユーザほど低い上限枠を決定することもできる。このように、上限枠決定部３２は、電子決済サービスによって取得し得るユーザ１１の決済に関する任意の情報に基づいて、後払いを可能とする金額の上限枠を決定することもできる。

また、上限枠決定部３２は、ユーザ１１によって電子決済サービスが利用される度に更新されるユーザ情報２１に基づき、チャージ残高の利用状況の変化に応じて、リアルタイムで後払いを可能とする金額の上限枠を変更する。これにより、上限枠決定部３２は、そのときのユーザ１１の経済状態に応じて、ユーザ１１にとって適切な上限枠を決定することができる。

（選択要求部）
選択要求部３３は、上限枠決定部３２によって後払いを可能とする金額の上限枠が決定されると、ユーザ端末１２に支払方法選択要求画面に表示させて、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザ１１に選択させる。

（提案部）
提案部３４は、学習モデル２２によって出力されるスコアが閾値以上であって、後払いを利用していないユーザ１１に後払いの利用を提案する。例えば、提案部３４は、決済情報を送信したユーザ１１の学習モデル２２によるスコアが閾値以上であって、ユーザ１１が後払いを利用していない場合、図５に示すように、支払方法選択要求画面に「後払いサービスに登録しませんか？」というメッセージを追加する。

これにより、情報処理装置１によって電子決済サービスを提供する事業者は、ユーザ１１によって後払いが選択されれば、利子による収益を上げることができる。また、ユーザ１１は、チャージ残高が不足している場合であっても、商品の購入やサービスの利用を行うことができる。

また、提案部３４は、スコアが前記閾値以上であって、リボルビング払いを利用していないユーザにリボルビング払いの利用を提案する。例えば、提案部３４は、決済情報を送信したユーザ１１の学習モデル２２によるスコアが閾値以上であって、ユーザ１１がリボ払いを利用していない場合、図６に示すように、支払方法選択要求画面に「リボ払いにしませんか？」というメッセージを追加する。

このとき、提案部３４は、リボ払い登録ようのアイコンを合わせて表示させる。これにより、情報処理装置１によって電子決済サービスを提供する事業者は、ユーザ１１によってリボ払いが選択されれば、例えば、１回払いの後払いよりも多い利子による収益を上げることができる。また、ユーザ１１は、月々の支払金額が一定になるため、収支管理が容易になる。

（決済処理部）
決済処理部３５は、受付部３１によって支払方法決定情報（図１参照）が受け付けられると、ユーザ１１によって選択された支払方法によって決済処理を行う。その後決済処理部３５は、決済処理が完了すると、決済完了通知（図１参照）をユーザ端末１２および店舗端末１００に送信する。

［３．決済処理］
次に、図７を参照して、実施形態に係る情報処理装置１の制御部３０が実行する決済処理の一例について説明する。図７は、実施形態に係る情報処理装置が実行する決済処理の一例を示すフローチャートである。

図７に示すように、制御部３０は、まず、ユーザ端末１２または店舗端末１００から決済情報を受信したか否かを判定する（ステップＳ１０１）。制御部３０は、決済情報を受信しないと判定した場合（ステップＳ１０１，Ｎｏ）、決済処理を受信するまでステップＳ１０１の判定処理を繰り返す。

そして、制御部３０は、決済処理を受信したと判定した場合（ステップＳ１０１，Ｙｅｓ）、ユーザ１１のチャージ残高の利用状況に基づいて後払い上限枠を決定する（ステップＳ１０２）。続いて、制御部３０は、支払方法選択要求画面をユーザ端末１２または店舗端末１００に表示させる（ステップＳ１０３）。

その後、制御部３０は、ユーザ端末１２または店舗端末１００から支払方法確定情報を受信したか否かを判定する（ステップＳ１０４）。制御部３０は、支払方法確定情報を受信しないと判定した場合（ステップＳ１０４，Ｎｏ）、支払方法確定情報を受信するまでステップＳ１０３の判定処理を繰り返す。

そして、制御部３０は、支払方法確定情報を受信したと判定した場合（ステップＳ１０４，Ｙｅｓ）、支払方法が即時払いか否かを判定する（ステップＳ１０５）。制御部３０は、即時払いであると判定した場合（ステップＳ１０５，Ｙｅｓ）、側決済処理を実行し（ステップＳ１０６）、処理をステップＳ１０８へ移す。即時決済処理の一例については、図８を参照して後述する。

また、制御部３０は、即時払いでないと判定した場合（ステップＳ１０５，Ｎｏ）、後払い決済処理を実行し、（ステップＳ１０７）、処理をステップＳ１０８へ移す。後払い決済処理の一例については、図９を参照して後述する。

制御部３０は、即時決済処理または後払い決済処理が完了すると、ユーザ端末１２および店舗端末１００に決済完了通知を送信し（ステップＳ１０８）、処理を終了する。その後、制御部３０は、ステップＳ１０１から処理を再度開始する。

［４．即時決済処理］
次に、図８を参照して、実施形態に係る情報処理装置の制御部が実行する即時決済処理の一例について説明する。図８は、実施形態に係る情報処理装置の制御部が実行する即時決済処理の一例を示すフローチャートである。

図８に示すように、制御部３０は、即時決済処理を開始すると、まず、決済情報に対応するユーザ１１のスコアが閾値以上で後払い未利用か否かを判定する（ステップＳ２０１）。制御部３０は、ユーザ１１のスコアが閾値未満の場合、またはユーザ１１が後払い未利用でない場合（ステップＳ２０１，Ｎｏ）、処理をステップＳ２０４へ移す。

また、制御部３０は、ユーザ１１のスコアが閾値以上で後払い未利用であると判定した場合（ステップＳ２０１，Ｙｅｓ）、ユーザ１１に対して後払いを提案し（ステップＳ２０２）、ユーザ１１が後払いを拒否したか否かを判定する（ステップＳ２０３）。

制御部３０は、ユーザ１１が後払いを拒否したと判定した場合（ステップＳ２０３，Ｙｅｓ）、チャージ残高から店舗の銀行口座に支払を行い（ステップＳ２０４）、処理を終了して図７に示すステップＳ１０８へ処理を移す。

また、制御部３０は、ユーザ１１が後払いを拒否せずに承諾したと判定した場合（ステップＳ２０３，Ｎｏ）、後払い決済処理を実行して（ステップＳ１０７）、図７に示すステップＳ１０８へ処理を移す。

［５．後払い決済処理］
次に、図９を参照して、実施形態に係る情報処理装置の制御部が実行する後払い決済処理の一例について説明する。図９は、実施形態に係る情報処理装置の制御部が実行する後払い決済処理の一例を示すフローチャートである。

図９に示すように、制御部３０は、後払い決済処理を開始すると、まず、店舗の銀行口座に代金を入金し（ステップＳ３０１）、ユーザ１１のスコアが閾値以上でリボ払い未利用か否かを判定する（ステップＳ３０２）。制御部３０は、ユーザ１１のスコアが閾値未満の場合、またはユーザ１１がリボ払い未利用でない場合（ステップＳ３０２，Ｎｏ）、処理をステップＳ３０５へ移す。

また、制御部３０は、ユーザ１１のスコアが閾値以上でリボ払い未利用であると判定した場合（ステップＳ３０２，Ｙｅｓ）、ユーザ１１に対してリボ払いを提案し（ステップＳ３０３）、ユーザ１１がリボ払いを拒否したか否かを判定する（ステップＳ３０４）。

制御部３０は、ユーザ１１がリボ払いを拒否したと判定した場合（ステップＳ３０４，Ｙｅｓ）、所定日にユーザ１１の銀行口座から代金の金額を引き落とし（ステップＳ３０５）、処理を終了して図７に示すステップＳ１０８へ処理を移す。

また、制御部３０は、ユーザ１１がリボ払いを拒否せずに承諾したと判定した場合（ステップＳ３０４，Ｎｏ）、所定日にユーザ１１の銀行口座から一定金額を引き落とし（ステップＳ３０６）、図７に示すステップＳ１０８へ処理を移す。

［６．変形例］
上述の実施形態は一例を示したものであり、種々の変更および応用が可能である。

上述した実施形態では、ユーザ端末１２による店舗コード１３の読み取りや、ユーザ端末１２に表示するユーザＩＤを店舗端末１００により読み取って決済処理を行う場合について説明したが、ユーザ端末１２を使用せずに決済処理を行ってもよい。

例えば、希望者には、実施形態に係る電子決済サービスの加盟店および加盟店以外でも利用可能なプラスチック製のクレジットカードを発行し、そのクレジットカードを使用して、上述した実施形態と同様の電子決済処理を行うこともできる。この場合、クレジットカードの券面には、番号を表せず、アプリ上で番号やセキュリティコードの確認をできるようにする。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。たとえば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

［７．効果］
上述してきたように、実施形態に係る情報処理装置１は、選択要求部３３と、上限枠決定部３２とを有する。選択要求部３３は、代金の支払い時に、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザに選択させる。上限枠決定部３２は、後払いを可能とする金額の上限枠を少なくともチャージ残高の利用状況に基づいて決定する。これにより、情報処理装置１は、ユーザ１１の主観にとらわれることなく、ユーザ１１にとって適切な後払いの上限枠を決定することができる。

また、情報処理装置１は、学習モデル２２を有する。学習モデル２２は、延滞なくリボルビング払いを行っていたユーザ１１によるチャージ残高の利用状況を正解データとして機械学習し、チャージ残高の利用状況が入力された場合に、当該チャージ残高を保有するユーザ１１の信頼度の高さに応じたスコアを出力する。上限枠決定部３２は、学習モデル２２によって出力されるユーザ１１のスコアに応じた上限枠を決定する。これにより、情報処理装置１は、他の多くのユーザによる後払い（リボ払い）の支払い状況に基づいて、各ユーザにとって適切な後払いの条件枠を決定することができる。

また、情報処理装置１は、提案部３４を有する。提案部３４は、学習モデル２２によって出力されるスコアが閾値以上であって、後払いを利用していないユーザに後払いの利用を提案する。これにより、情報処理装置１は、後払いを利用していないユーザ１１に対して後払いによる支払を促すことができる。

また、提案部３４は、スコアが閾値以上であって、リボルビング払いを利用していないユーザにリボルビング払いの利用を提案する。これにより、情報処理装置１は、リボ払いを利用していないユーザ１１に対してリボ払いによる支払を促すことができる。

また、上限枠決定部３２は、チャージ残高の利用状況の変化に応じて上限枠を変更する。これにより、情報処理装置１は、そのときのユーザ１１の経済状態に応じて、ユーザ１１にとって適切な上限枠を決定することができる。

［８．ハードウェア構成］
また、上述してきた実施形態に係る情報処理装置１は、たとえば、図１０に示すような構成のコンピュータ１０００によって実現される。以下、情報処理装置１を例に挙げて説明する。図１０は、実施形態に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、およびメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態の通信ネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、たとえばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

たとえば、コンピュータ１０００が情報処理装置１として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部３０の機能を実現する。また、ＨＤＤ１４００には、情報処理装置１の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。

［９．その他］
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した情報処理装置１は、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。たとえば、受付部は、受付手段や受付回路に読み替えることができる。

１ 情報処理装置
１０ 通信部
１１ ユーザ
１２ ユーザ端末
１３ 店舗コード
２０ 記憶部
２１ ユーザ情報
２２ 学習モデル
３０ 制御部
３１ 受付部
３２ 上限枠決定部
３３ 選択要求部
３４ 提案部
３５ 決済処理部
１００ 店舗端末
２００ 銀行サーバ

Claims (6)

1. 代金の支払い時に、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザに選択させる選択要求部と、
   前記後払いを可能とする金額の上限枠を少なくとも前記チャージ残高の利用状況に基づいて決定する上限枠決定部と、
   延滞なく後払いを行っていたユーザによる前記チャージ残高の利用状況を正解データとして機械学習し、チャージ残高の利用状況が入力された場合に、当該チャージ残高を保有するユーザの信頼度の高さに応じたスコアを出力する学習モデルと
   を有し、
   前記上限枠決定部は、
   前記学習モデルによって出力されるユーザのスコアに応じた前記上限枠を決定する
   ことを特徴とする情報処理装置。
2. 前記学習モデルによって出力されるスコアが閾値以上であって、前記後払いを利用していないユーザに前記後払いの利用を提案する提案部
   を有することを特徴とする請求項１に記載の情報処理装置。
3. 前記提案部は、
   前記スコアが前記閾値以上であって、リボルビング払いを利用していないユーザにリボルビング払いの利用を提案する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記上限枠決定部は、
   前記チャージ残高の利用状況の変化に応じて前記上限枠を変更する
   ことを特徴とする請求項１～３のいずれか一つに記載の情報処理装置。
5. コンピュータが実行する情報処理方法であって、
   代金の支払い時に、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザに選択させる選択要求工程と、
   前記後払いを可能とする金額の上限枠を少なくとも前記チャージ残高の利用状況に基づいて決定する上限枠決定工程と
   を含み、
   前記上限枠決定工程は、
   延滞なく後払いを行っていたユーザによる前記チャージ残高の利用状況を正解データとして機械学習し、チャージ残高の利用状況が入力された場合に、当該チャージ残高を保有するユーザの信頼度の高さに応じたスコアを出力する学習モデルによって出力されるユーザのスコアに応じた前記上限枠を決定する
   ことを特徴とする情報処理方法。
6. 代金の支払い時に、電子マネーのチャージ残高から支払う即時払い、または後払いをユーザに選択させる選択要求手順と、
   前記後払いを可能とする金額の上限枠を少なくとも前記チャージ残高の利用状況に基づいて決定する上限枠決定手順と
   をコンピュータに実行させ、
   前記上限枠決定手順は、
   延滞なく後払いを行っていたユーザによる前記チャージ残高の利用状況を正解データとして機械学習し、チャージ残高の利用状況が入力された場合に、当該チャージ残高を保有するユーザの信頼度の高さに応じたスコアを出力する学習モデルによって出力されるユーザのスコアに応じた前記上限枠を決定する
   ことを特徴とする情報処理プログラム。

Images