JP7402375B1 - 情報処理装置、情報処理方法および情報処理プログラム - 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 (9)

1. ユーザからクレジットカードの申し込みを受け付ける受付部と、
   前記受付部がクレジットカードの申し込みを受け付けた前記ユーザが他のサービスで本人確認に利用した本人確認情報を取得する取得部と、
   前記取得部が取得した前記本人確認情報を入力した状態で前記クレジットカードの申し込み画面を前記ユーザへ提供する提供部と
   を備え、
   前記提供部は、
   前記他のサービスが提供する電子マネー口座で前記クレジットカードの精算を希望するユーザに対して、前記電子マネー口座に登録された銀行口座を前記申し込み画面に表示して提供する
   ことを特徴とする情報処理装置。
2. 前記提供部は、
   前記本人確認情報に基づいて入力した入力項目については前記ユーザによる編集を不可にした前記申し込み画面を提供すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記受付部は、
   前記クレジットカードとは異なる決済サービスを通じて、前記クレジットカードの申し込みを受け付け、
   前記取得部は、
   前記決済サービスで本人確認を行ったユーザの前記本人確認情報を取得すること
   を特徴とする請求項１に記載の情報処理装置。
4. 前記受付部は、
   前記決済サービスで利用する前記クレジットカードの申し込みを受け付けること
   を特徴とする請求項３に記載の情報処理装置。
5. 前記提供部は、
   前記本人確認情報を取得できなかったユーザ、または、前記電子マネー口座に銀行口座を登録していないユーザに対して、前記本人確認情報を入力していない状態で前記クレジットカードの申し込み画面を提供すること
   を特徴とする請求項１に記載の情報処理装置。
6. 前記提供部は、
   ユーザが前記電子マネー口座に複数の前記銀行口座を登録している場合に、前記申し込み画面において複数の銀行口座から前記電子マネー口座にチャージする前記銀行口座の指定を受け付けること
   を特徴とする請求項１に記載の情報処理装置。
7. 前記提供部は、
   前記申し込み画面の入力を終えたユーザに対して前記電子マネー口座で前記クレジットカードの精算ができなかった際に精算を行う銀行口座の登録を推奨する推奨画面を提供すること
   を特徴とする請求項１に記載の情報処理装置。
8. コンピュータが実行する情報処理方法であって、
   ユーザからクレジットカードの申し込みを受け付ける受付工程と、
   前記受付工程によってクレジットカードの申し込みを受け付けた前記ユーザが他のサービスで本人確認に利用した本人確認情報を取得する取得工程と、
   前記取得工程が取得した前記本人確認情報を入力した状態で前記クレジットカードの申し込み画面を前記ユーザへ提供する提供工程と
   を含み、
   前記提供工程は、
   前記他のサービスが提供する電子マネー口座で前記クレジットカードの精算を希望するユーザに対して、前記電子マネー口座に登録された銀行口座を前記申し込み画面に表示して提供する
   ことを特徴とする情報処理方法。
9. ユーザからクレジットカードの申し込みを受け付ける受付手順と、
   前記受付手順によってクレジットカードの申し込みを受け付けた前記ユーザが他のサービスで本人確認に利用した本人確認情報を取得する取得手順と、
   前記取得手順が取得した前記本人確認情報を入力した状態で前記クレジットカードの申し込み画面を前記ユーザへ提供する提供手順と
   をコンピュータに実行させ、
   前記提供手順は、
   前記他のサービスが提供する電子マネー口座で前記クレジットカードの精算を希望するユーザに対して、前記電子マネー口座に登録された銀行口座を前記申し込み画面に表示して提供する
   ことを特徴とする情報処理プログラム。

Images