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

Abstract

【課題】より簡便な手続きで利用可能な電子決済サービスを提供すること。【解決手段】本願に係る情報処理装置は、ユーザから決済サービス経由でクレジットカードの申し込みを受け付ける受付部と、前記ユーザが決済サービスで本人確認済みか否かに関する本人確認情報を決済サービスから取得する取得部と、本人確認情報に基づき、本人確認済みのユーザに対しクレジットカードの精算口座として決済サービスのユーザウォレットまたは銀行口座の登録を提案し、本人確認済みでないユーザに対し精算口座として銀行口座の登録を提案する提案部とを備える。【選択図】図１

Description

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

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

たとえば、電子決済サービスでは、ユーザのウォレットにクレジットカードを紐づけておき、ユーザが電子マネー決済で利用した金額を後日まとめて支払う後払い決済に関する技術が提案されている（たとえば、特許文献１参照）。

特開２０２２－１５８８１０号公報

しかしながら、従来技術では、より簡便な手続きで利用可能な電子決済サービスを提供するうえで改善の余地があった。例えば、ユーザが後払い決済に登録するクレジットカードを申し込む場合、クレジットカードの引き落とし口座を登録する必要がある。

本発明は、上記に鑑みてなされたものであって、より簡便な手続きで利用可能な電子決済サービスを提供することができる情報処理装置、決済サーバ、情報処理方法、決済方法、情報処理プログラムおよび決済プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る情報処理装置は、ユーザから決済サービス経由でクレジットカードの申し込みを受け付ける受付部と、前記ユーザが前記決済サービスで本人確認済みか否かに関する本人確認情報を前記決済サービスから取得する取得部と、前記本人確認情報に基づき、本人確認済みの前記ユーザに対し前記クレジットカードの精算口座として前記決済サービスのユーザウォレットまたは銀行口座の登録を提案し、本人確認済みでない前記ユーザに対し前記精算口座として銀行口座の登録を提案する提案部とを備える。

本発明によれば、より簡便な手続きで利用可能な電子決済サービスを提供することができる。

図１は、実施形態に係る情報処理の一例を示す図である。 図２は、実施形態に係る支払いスキームの一例を示す図である。 図３は、実施形態に係る決済サーバの構成例を示すブロック図である。 図４は、実施形態に係るユーザ情報記憶部に格納される情報の一例を示す図である。 図５は、実施形態に係る情報処理装置の構成例を示すブロック図である。 図６は、実施形態に係る利用規約画面の一例を示す図である。 図７は、実施形態に係る提案処理の一例を示すフローチャートである。 図８は、実施形態に係る決済処理の一例を示すフローチャートである。 図９は、実施形態に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

［実施形態］
〔１．情報処理〕
まず、図１を用いて、実施形態に係る情報処理の一例について説明する。図１は、実施形態に係る情報処理の一例を示す図である。なお、以下では、連携サービスがクレジットカードの信用取引に関するサービスであり、決済サービスがユーザ端末１００を利用した電子マネー決済に関するサービスである場合について説明する。

図１に示すように、実施形態に係る情報処理装置１は、たとえば、クレジットカード会社が運営する情報処理装置であり、例えば、サーバ装置やクラウドシステムにより実現される。

たとえば、図１に示すクレジットカード会社は、電子決済事業者等と連携し、ユーザに対して各種サービスを提供する。本実施形態において、情報処理装置１は、ユーザからクレジットカードの申請を受け付ける。

電子決済事業者が保有する決済サーバ２００は、各ユーザに対して電子マネー決済を提供するサーバ装置である。例えば、決済サーバ２００は、ユーザ端末１００を用いる電子決済に関する電子決済サービスを提供し、各種の決済を行う情報処理装置である。例えば、決済サーバ２００は、取引対象の提供者（事業者）や取引対象が提供されるユーザの口座を管理しており、ユーザからの決済要求に従って、口座間における電子マネーの送金等を行うことで、各種決済を実現する。

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

ここで、情報処理装置１が実行する提供処理に先立ち、ユーザ端末１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗Ａに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ａを識別する店舗識別情報を示す２次元コードを用いて、ユーザがユーザ端末１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意のユーザが任意のユーザ端末１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコードのみならず、バーコードや所定のマーク、番号等であってもよい。

例えば、ユーザが店舗Ａにて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、ユーザは、ユーザ端末１００に予めインストールされた決済アプリを起動する。そして、ユーザは、決済アプリを介して、店舗Ａに設置された店舗識別情報を撮影する。このような場合、ユーザ端末１００は、決済対象の価格を入力するための画面を表示し、ユーザ或いは店舗Ａの店員から決済金額の入力を受け付ける。そして、ユーザ端末１００は、ユーザを識別するユーザ識別情報と、店舗識別情報（若しくは、店舗識別情報が示す情報、すなわち、店舗Ａ（若しくは店舗Ａの事業者）を示す情報（例えば、店舗ＩＤ）と、決済金額とを示す決済情報を決済サーバ２００へ送信する。

このような場合、決済サーバ２００は、ユーザ識別情報が示すユーザの口座から、店舗識別情報が示す店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させる。そして、決済サーバ２００は、決済が完了した旨の通知をユーザ端末１００へ送信する。このような場合、ユーザ端末１００は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

より詳細な例を説明する。例えば、店舗Ａに設置された店舗識別情報は、店舗ごとに設定されるＵＲＬであって、店舗Ａが属するグループを示すグループ識別情報と、そのグループにおいて店舗Ａを識別するグループ店舗識別情報とに紐づけ、決済サーバ２００が参照可能に管理されている。なお、店舗識別情報となるＵＲＬは、決済サーバ２００にアクセスするためのＵＲＬとなる。ユーザ端末１００は、店舗識別情報を撮影すると、撮影した店舗識別情報が示すＵＲＬにアクセスし、ユーザ識別情報を送信する。このような場合、決済サーバ２００は、アクセスされたＵＲＬと対応するグループ識別情報を特定し、特定したグループ識別情報と紐づけられた電子マネーの口座（「ウォレット」と表示する場合がある）を特定する。続いて、決済サーバ２００は、ユーザ端末１００に対して金額入力画面を表示させ、金額を入力させる。そして、決済サーバ２００は、ユーザ端末１００から受けつけたユーザ識別情報と紐づけられたウォレットから、グループ識別情報を特定し、特定したグループ識別情報と紐づけられたウォレットに対して、入力された金額の電子マネーを移動させる。なお、決済サーバ２００は、グループ識別情報およびグループ店舗識別情報とに紐づけられるウォレットに電子マネーを移動させてもよい。

なお、ユーザ端末１００を用いた決済は、上述した処理に限定されるものではない。例えば、ユーザ端末１００を用いた決済は、店舗Ａに設置された店舗端末を用いたものであってもよい。例えば、ユーザ端末１００は、ユーザを識別するためのユーザ識別情報を画面上に表示させる。このような場合、店舗Ａに設置された店舗端末は、ユーザ端末１００に表示されたユーザ識別情報を読み取り、ユーザ識別情報（若しくは、ユーザ識別情報が示す情報、すなわち、ユーザを示す情報（例えば、ユーザＩＤ）と、決済金額と、店舗Ａを識別する情報とを示す決済情報を決済サーバ２００へ送信する。このような場合、決済サーバ２００は、ユーザ識別情報が示すユーザの口座から、店舗Ａの口座へ、決済金額が示す額の電子マネーを移行させ、店舗Ａの店舗端末或いはユーザ端末１００に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

より詳細には、ユーザ端末１００は、ユーザ識別情報とともに決済サーバ２００に対して支払いリクエストを送信する。このような場合、決済サーバ２００は、ワンタイムコードを生成し、生成したワンタイムコードとユーザ識別情報とを紐づけるとともに、ワンタイムコードをユーザ端末１００に送信する。すると、ユーザ端末１００は、画面上にワンタイムコード（すなわち、ユーザを識別する情報）を表示する。このような場合、店舗端末は、ユーザ端末１００に表示されたワンタイムコードを読み取ると、読み取ったワンタイムコードと、グループ識別情報、グループ店舗識別情報および決済金額を決済サーバ２００に送信する。すると、決済サーバ２００は、ワンタイムコードに紐づけられたユーザ識別情報に紐づくウォレットから、グループ識別情報およびグループ店舗識別情報とに紐づけられるウォレットに決済金額分の電子マネーを移動させる。

また、ユーザ端末１００を用いた決済は、ユーザが予め電子マネーをチャージした口座から店舗Ａの口座へ電子マネーを移行させる処理のみならず、例えば、ユーザが予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、ユーザ端末１００は、店舗Ａの口座に対して決済金額の電子マネーを移行させるとともに、ユーザのクレジットカードの運用会社（カード会社）に対し、決済金額を請求してもよい。

ところで、近年では、上述したＱＲコードを用いた電子マネー決済が広く普及しつつある。電子マネー決済では、ユーザのウォレットにユーザのクレジットカードを紐づけておき、ユーザによって行われた電子マネー決済をクレジットカードの引き落としとして後日まとめて請求するサービスが提供されている。なお、以下では、かかるサービスについて、後払いサービスと記載する。

ユーザＵが後払いサービスに利用するクレジットカードの申し込みを行う場合、クレジットカードの引き落とし口座を登録する必要がある。現状、ユーザＵがクレジットカードの引き落とし口座の登録する段階において、クレジットカードの申し込みを中断するなど、申し込みを離脱するケースがある。

換言すると、ユーザＵがクレジットカードの引き落とし口座を登録する作業については簡略化することが望まれている。そこで、実施形態に係る情報処理装置１は、決済サービスのユーザウォレットをクレジットカードの引き落とし口座として選択可能なサービスを提供することとした。

具体的には、情報処理装置１は、既にユーザウォレットに銀行口座が登録されているユーザＵからクレジットカードの申し込みを受け付けた場合に、クレジットカードの引き落としをユーザウォレットから行う新規なサービスを提供する。

図１に示すように、まず、ユーザＵが、電子決済サービスのアプリを通じて決済サーバ２００へクレジットカードの申し込みを行う（ステップＳ１）。決済サーバ２００は、ユーザＵのユーザ端末１００に対し、情報提供同意画面を提供する（ステップＳ２）。ここで、情報提供同意画面は、決済サーバ２００で保有するユーザＵの個人情報について、クレジットカード会社への提供をユーザＵが同意するための画面である。

ユーザＵが情報提供同意画面において情報提供を同意すると（ステップＳ３）、決済サーバ２００から情報処理装置１へユーザＵによるクレジットカードの申し込みが通知される（ステップＳ４）。

情報処理装置１は、決済サーバ２００からの通知を受けて、ユーザＵのユーザ端末１００に対してクレジットカードの申し込み画面を提供し（ステップＳ５）、ユーザ端末１００から申し込み情報を取得する（ステップＳ６）。

つづいて、情報処理装置１は、決済サーバ２００からユーザＵの本人確認情報を取得し（ステップＳ６）、決済サーバ２００からユーザＵの本人確認情報を取得する。本人確認情報は、対応するユーザＵが決済サービスで本人確認済みか否かに関する情報である。

例えば、決済サービスにおいて、ユーザウォレットに銀行口座を登録し、ユーザウォレットのオートチャージ設定を行うユーザＵについては事前に本人確認が必須となる。そのため、決済サーバ２００から取得する本人確認情報は、オートチャージ設定を利用可能なユーザＵか否かを示す情報であるとも言える。

そして、情報処理装置１は、決済サーバ２００から取得した本人確認情報に基づいて、ユーザＵに対して提案する精算口座（クレジットカードの引き落とし口座）を選択する（ステップＳ８）。

具体的には、情報処理装置１は、ユーザＵが決済サーバ２００において本人確認済みである場合、ユーザウォレットまたは新規に登録される銀行口座を精算口座として選択し、ユーザＵが決済サーバ２００において本人確認済みでない場合、新規に登録される銀行口座を精算口座として選択する。

そして、情報処理装置１は、選択した精算口座をユーザＵに対して提案する（ステップＳ９）。つまり、決済サービス側でユーザウォレットに銀行口座を紐づけているユーザについてはクレジットカードの申し込みを行う際に、銀行口座を登録せずとも申し込みが可能となる。

これにより、実施形態に係る情報処理装置１によれば、より簡便な手続きで利用可能な電子決済サービスを提供することができる。

次に、図２を用いて、クレジットカードの精算口座をユーザウォレットとする場合の資金移動の流れについて説明する。図２は、実施形態に係る支払いスキームの一例を示す図である。

なお、図２に示すクレジットカード事業者を情報処理装置１、電子決済事業者を決済サーバ２００、銀行を銀行サーバ（不図示）と読み替えることにしてもよい。図２に示すように、ユーザＵがクレジットカードのサービスを利用すると（ステップＳ１１）、クレジットカード事業者からユーザＵへクレジットカードの請求明細書の送付が行われる（ステップＳ１２）。

請求明細書の送付は、例えば、電子データとして送付され、毎月の締め日以降にまとめて一ヶ月分の明細が送付される。つづいて、クレジットカード事業者から電子決済事業者に対しユーザＵによるクレジットの利用分の決済リクエストが行われる（ステップＳ１３）。

決済リクエストは、ユーザＩＤ、請求額等に関する情報を含む。電子決済事業者は、決済リクエストを受けて、ユーザＵのユーザウォレットの残高から引き落としを行う（ステップＳ１４）。

この際、電子決済事業者は、ユーザウォレットの残高が不足している場合には、ユーザウォレットのオートチャージ口座として設定されて銀行に対し、チャージリクエストを行う（ステップＳ１５）。

銀行では、かかるチャージリクエストを受けて、ユーザＵの銀行口座からユーザウォレットへ資金を移動させる残高チャージを行う（ステップＳ１６）。より具体的には、電子決済事業者は、ユーザウォレットに登録された銀行に対し、ユーザＵの銀行口座の口座番号とチャージ額を指定し、引き落としの請求項を行う。そして、銀行は、ユーザＵの銀行口座から電子決済事業者の口座へ送金し、電子決済事業者へ送金されたチャージ額を原資として、電子決済事業者はユーザウォレットに残高のチャージを行う。

その後、電子決済事業者は、ユーザウォレットから資金の引き落としを行い（ステップＳ１７）、その後、電子決済事業者は、所定の期日において、クレジットカード事業者に対して回収代金の送金を行う（ステップＳ１８）。

このようなスキームにより、ユーザウォレットの残高が不足する場合には、ユーザウォレットに紐づく銀行口座から不足分をチャージすることができるので、ユーザウォレットからクレジットカードの引き落としを適切に行うことができる。

〔２-１．決済サーバの構成例〕
次に、図３を用いて、決済サーバ２００の構成例について説明する。図３は、実施形態に係る決済サーバ２００の構成例を示すブロック図である。図３に示すように、決済サーバ２００は、通信部５と、記憶部６と、制御部７とを有する。

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

記憶部６は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

図３に示すように、記憶部６は、ユーザ情報記憶部６１を有する。ユーザ情報記憶部６１は、ユーザ情報を記憶する。ユーザ情報は、ユーザＵに関する各種情報を含む。図４は、実施形態に係るユーザ情報記憶部６１に格納される情報の一例を示す図である。

図４に示すように、実施形態に係るユーザ情報記憶部６１は、「ユーザＩＤ」、「登録情報」、「ウォレット情報」、「本人確認」、「オートチャージ」などといった項目の情報を互いに対応付けて記憶する。

「ユーザＩＤ」項目には、決済サーバ２００において各ユーザＵを識別するための識別子が格納される。「登録情報」項目には、対応するユーザＩＤによって識別されるユーザＵが決済サーバ２００に登録した情報が格納される。登録情報は、氏名、住所、年齢、家族構成、勤務地、年収などといった各種情報が含まれる。

「ウォレット情報」項目には、対応するユーザＩＤによって識別されるユーザＵの電子決済サービスで開設されたウォレット情報が格納される。ウォレット情報は、ウォレットを識別するための識別子（例えば、ウォレットＩＤ）や、残高に関する情報、ウォレットのチャージ口座（銀行口座）に関する情報を含む。

「本人確認」項目には、対応するユーザＩＤによって識別されるユーザＵが本人確認を実施済みか否かに関する情報（フラグ）が格納される。例えば、「本人確認」項目には、本人確認を実施済みのユーザＵには「１」、本人確認を実施済みでないユーザＵには「０」が格納される。

「オートチャージ」項目には、対応するユーザＩＤによって識別されるユーザＵがオートチャージ設定中か否かに関する情報（フラグ）が格納される。例えば、対応するユーザＩＤによって識別されるユーザＵオートチャージ設定中であれば「１」、オートチャージ設定でない場合「０」が格納される。

図３の説明に戻り、制御部７について説明する。制御部７は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報処理装置１内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部７は、取得部７１と、決済処理部７２と、設定部７３とを有する。取得部７１は、ユーザのクレジットカードの請求額に関する通知を取得する。例えば、取得部７１は、情報処理装置１からユーザのクレジットカードの請求額に関する通知を取得する。

なお、取得部７１は、クレジットカードの締め日以降にクレジットカードの請求額を一括で取得するようにしてもよく、所定の周期でクレジットカードの請求額を取得するようにしてもよい。

決済処理部７２は、ユーザ端末１００を用いた決済（電子決済）に関する各種決済処理を実行する。例えば、決済処理部７２は、クレジットカードの請求額をユーザウォレットから精算する決済処理を実行する。

決済処理部７２は、取得部７１からクレジットカードの請求額に関する通知を受け取ると、対応するユーザＵのユーザウォレットの残高でクレジットカードの請求額を精算可能か否かを判定する。

そして、決済処理部７２は、ユーザウォレットの残高でクレジットカードの請求額を精算可能（残高≧請求額）である場合、ユーザウォレットの残高からクレジットカードの請求額を減算する。

また、決済処理部７２は、ユーザウォレットの残高でクレジットカードの請求額を精算不可（残高＜請求額）である場合、ユーザウォレットのオートチャージ口座として登録された銀行に対してオートチャージを要求する。

その後、決済処理部７２は、残高チャージ後のユーザウォレットの残高からクレジットカードの請求額を減算する。なお、決済処理部７２は、ユーザウォレットに紐づく銀行口座が複数ある場合には、ユーザＵによって設定された優先順位、あるいは、ユーザＵが選択した銀行口座から残高をチャージするようにしてもよい。

また、決済処理部７２は、例えば、先払いサービスによってクレジットの請求額を精算するようにしてもよい。具体的には、決済処理部７２は、ユーザＵによって要求されたタイミングでユーザウォレットの残高からクレジットカードの請求額を減算するようにしてもよい。

また、決済処理部７２は、クレジットカードの請求額が所定の閾値を超えた場合には、ユーザに対して送付する振り込み用紙を手配する。ここで、振り込み用紙を手配するとは、電子決済事業者のオペレータあるいはクレジットカード会社のオペレータに対して、ユーザＵに対して振り込み用紙を送付するように指示することを指す。より具体的には、決済処理部７２は、ユーザＵの請求データに対し、精算を振り込み用紙とするフラグを紐づけて記憶する。オペレータは、かかるデータを参照し、ユーザＵに対し振り込み用紙を送付することになる。

また、所定の閾値は、１００万円であり、これは、電子決済事業者が決済可能な金額の上限が法律により定められているためである。すなわち、クレジットカードの請求額が１００万円を超える場合には、ユーザＵに振り込み用紙が送付され、振り込み用紙によって精算が行われる。

設定部７３は、クレジットカードの精算口座としてユーザウォレットを選択したユーザＵに対してユーザウォレットに紐づく銀行口座からのオートチャージをオンに設定する。例えば、設定部７３は、情報処理装置１による通知に基づき、クレジットカードの精算口座としてユーザウォレットを選択したユーザＵを識別し、当該ユーザＵのオートチャージをオンに設定する。

そして、設定部７３は、ユーザＵのオートチャージをオンに設定すると、ユーザＵによる後払いサービスが解除されるまで、あるいは、後払いサービスの引き落とし口座として新たに銀行口座が登録されるまで、ユーザＵによるオートチャージの設定変更を許可しない。

つまり、設定部７３は、後払いサービスの精算口座としてユーザウォレットを選択中のユーザＵについてはオートチャージ設定が常にオンになるように設定する。これにより、ユーザウォレットの残高不足によってクレジットカードの精算ができなくなる事態を回避することができる。

〔２-２．情報処理装置の構成例〕
次に、図５を用いて、実施形態に係る情報処理装置１の構成例について説明する。図５は、実施形態に係る情報処理装置１の構成例を示すブロック図である。図５に示すように、情報処理装置１は、通信部２と、記憶部３と、制御部４とを有する。

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

記憶部３は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

制御部４は、コントローラ（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）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る情報処理装置１として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部４０の機能を実現する。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置からネットワークＮを介してこれらのプログラムを取得してもよい。

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

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

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

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 情報処理装置
２ 通信部
３ 記憶部
４ 制御部
５ 通信部
６ 記憶部
７ 制御部
４０ 制御部
４１ 受付部
４２ 取得部
４３ 提案部
４４ 通知部
４５ 精算要求部
６１ ユーザ情報記憶部
７１ 取得部
７２ 決済処理部
７３ 設定部
１００ ユーザ端末
２００ 決済サーバ
Ｕ ユーザ

Claims (7)

1. 決済サービスが提供するアプリケーションの画面を通じてユーザからクレジットカードの申し込みを受け付ける受付部と、
   前記ユーザが前記決済サービスで本人確認を行った場合に登録される本人確認情報の有無を前記決済サービスのサーバ装置から取得する取得部と、
   前記本人確認情報の有無に基づき、前記決済サービスで本人確認済みの前記ユーザに対し前記クレジットカードの精算口座として前記決済サービスのユーザウォレットまたは銀行口座の登録を提案し、前記決済サービスで本人確認済みでない前記ユーザに対し前記精算口座として銀行口座の登録を提案する提案部と
   を備えることを特徴とする情報処理装置。
2. 前記提案部は、
   前記決済サービスで前記ユーザの前記ユーザウォレットに紐づく銀行口座から前記ユーザウォレットへ残高がチャージされるオートチャージの設定が可能であるユーザに対して前記精算口座として前記ユーザウォレットを提案すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記ユーザウォレットを前記精算口座に設定した前記ユーザについて、前記オートチャージの設定がオンとなるように前記決済サービスのサーバ装置に対し通知する通知部
   を備えることを特徴とする請求項２に記載の情報処理装置。
4. 前記通知部は、
   前記ユーザが前記ユーザウォレットを前記精算口座として設定している期間については、前記オートチャージの設定がオンからオフへ変更されないように前記サーバ装置に対し通知すること
   を特徴とする請求項３に記載の情報処理装置。
5. 前記精算口座が前記ユーザウォレットであるユーザの前記クレジットカードの請求額を前記ユーザウォレットから精算するように、前記決済サービスのサーバ装置へ要求する精算要求部
   を備えることを特徴とする請求項１に記載の情報処理装置。
6. コンピュータが実行する情報処理方法であって、
   決済サービスが提供するアプリケーションの画面を通じてユーザからクレジットカードの申し込みを受け付ける受付工程と、
   前記ユーザが前記決済サービスで本人確認を行った場合に登録される本人確認情報の有無を前記決済サービスのサーバ装置から取得する取得工程と、
   前記本人確認情報の有無に基づき、前記決済サービスで本人確認済みの前記ユーザに対し前記クレジットカードの精算口座として前記決済サービスのユーザウォレットまたは銀行口座の登録を提案し、前記決済サービスで本人確認済みでない前記ユーザに対し前記精算口座として銀行口座の登録を提案する提案工程と
   を含むことを特徴とする情報処理方法。
7. 決済サービスが提供するアプリケーションの画面を通じてユーザからクレジットカードの申し込みを受け付ける受付手順と、
   前記ユーザが前記決済サービスで本人確認を行った場合に登録される本人確認情報の有無を前記決済サービスのサーバ装置から取得する取得手順と、
   前記本人確認情報の有無に基づき、前記決済サービスで本人確認済みの前記ユーザに対し前記クレジットカードの精算口座として前記決済サービスのユーザウォレットまたは銀行口座の登録を提案し、前記決済サービスで本人確認済みでない前記ユーザに対し前記精算口座として銀行口座の登録を提案する提案手順と
   をコンピュータに実行させることを特徴とする情報処理プログラム。

Images