JP7440699B1 - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ること。【解決手段】本願に係る情報処理装置は、取得部と、提供部とを有する。取得部は、電子決済サービスのユーザに提供される決済用アプリケーションの画面であって、後払い方式の支払方法に対応する第１の画面の表示要求をユーザから受け付けた場合、表示要求の送信元である対象ユーザに対応する後払い利用代金の請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す請求ステータス情報を取得する。提供部は、取得部により取得された請求ステータス情報に基づいて、対象ユーザに対応する請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを反映した第１の画面を表示するための画面情報を対象ユーザに提供する。【選択図】図６

Description

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

従来、主に企業と個人との間の商取引におけるキャッシュレス決済手段が広く消費者に認知されているが、特に、その利便性から、ユーザ個人が所有するスマートフォンなどのユーザ端末を用いてオンラインで行われる電子決済サービスが広く消費者の間に浸透している。

また、たとえば、クレジットカードなどのいわゆる後払いタイプのキャッシュレス決済について、ユーザが代金を支払いやすい仕組みを提供するとともに、顧客満足と回収率の向上の両方を実現することができる技術などが提案されている。

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

しかしながら、上記の従来技術では、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図る上で改善の余地がある。

本願は、上記に鑑みてなされたものであって、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ることができる情報処理装置、情報処理方法、及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置であって、取得部と、提供部とを有する。取得部は、電子決済サービスのユーザに提供される決済用アプリケーションの画面であって、後払い方式の支払方法に対応する第１の画面の表示要求をユーザから受け付けた場合、表示要求の送信元である対象ユーザに対応する後払い利用代金の請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す請求ステータス情報を取得する。提供部は、取得部により取得された請求ステータス情報に基づいて、対象ユーザに対応する請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを反映した第１の画面を表示するための画面情報を対象ユーザに提供する。

実施形態の一態様によれば、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ることができるという効果を奏する。

図１は、実施形態に係る情報処理（その１）の概要を説明するための図である。 図２は、実施形態に係る入金約束の手続を行うためのアプリ画面の一例を示す図である。 図３は、実施形態に係る情報処理（その２）の概要を説明するための図である。 図４は、実施形態に係る後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面の一例を示す図である。 図５は、実施形態に係る請求状況と支払方法との対応関係を示す参照情報の一例を概念的に示す図である。 図６は、実施形態に係る決済サーバの構成例を示す図である。 図７は、実施形態に係る利用者情報記憶部に記憶される利用者情報の一例を示す図である。 図８は、実施形態に係る決済サーバにより実行される情報処理（その１）の処理手順の一例を示すフローチャートである。 図９は、実施形態に係る決済サーバにより実行される情報処理（その２）の処理手順の一例を示すフローチャートである。 図１０は、実施形態または変形例に係る情報処理システムを構成する決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．実施形態〕
（１－１．システム構成）
以下、実施形態に係る情報処理について具体的に説明する。まず、実施形態に係る情報処理の説明に先駆けて、図１を参照しつつ、情報処理システムＳＹＳの構成の一例について説明する。

図１に示すように、実施形態に係る情報処理システムＳＹＳは、利用者端末１０、決済サーバ１００、及びクレジットカードサーバ２００を含んで構成される。利用者端末１０、決済サーバ１００、及びクレジットカードサーバ２００は、有線または無線により、ネットワークＮ（たとえば、図２参照）に接続される。利用者端末１０、決済サーバ１００、及びクレジットカードサーバ２００は、ネットワークＮを介して、他の装置との間で相互に通信できる。ネットワークＮは、たとえば、インターネットなどのＷＡＮ（Wide Area Network）である。

図１に示す利用者端末１０は、決済サーバ１００を運営および管理する事業者により提供される電子決済サービスの利用者であるサービス利用者ＵＡにより使用される情報処理端末である。利用者端末１０は、たとえば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、利用者端末１０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１では、利用者端末１０がスマートフォンである場合が例示されている。

また、利用者端末１０には、キャッシュレス決済手段の１つとしてサービス利用者ＵＡに提供されるコード決済（「スマートフォン決済」とも称される。）を利用するためのユーザ用のアプリケーションプログラム（以下、適宜「決済アプリ」と称する。）がインストールされる。利用者端末１０は決済アプリを通じた所定の情報処理を実現する制御情報を決済サーバ１００から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語や、ＣＳＳ（Cascading Style Sheets）などのスタイルシート言語、Ｊａｖａ（登録商標）などのプログラミング言語や、ＨＴＭＬ（HyperText Markup Language）などのマークアップ言語などにより記述される。なお、決済サーバ１００から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

図１に示す決済サーバ１００は、電子決済サービスを提供する電子決済サービス事業者ＵＢ（以下、「サービス事業者ＵＢ」と称する。）により運営および管理される情報処理装置である。決済サーバ１００は、メインフレームやワークステーションなどにより実現されてもよい。また、決済サーバ１００がサーバ装置で構成される場合、単独のサーバ装置により実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。

電子決済サービスは、上述の決済アプリを通じて、各サービス利用者に提供される。たとえば、決済アプリは、コード決済による決済に関する各種機能や、電子決済サービスに関連する付帯機能を有している。付帯機能には、取引履歴を確認する機能や、近くのお店を検索する機能や、ユーザアカウントの管理機能などが含まれている。電子決済サービスは、コード決済による電子マネーのやり取りを制御する所定の取引手段を提供するサービスともいえる。

また、決済サーバ１００は、利用者端末１０で動作する決済アプリと連動して、たとえば、専用のオンラインシステムを通じて提供する電子決済サービスに関する各種の処理を実行する。たとえば、決済サーバ１００は、電子決済サービスの利用希望者に対して決済アプリを配布し、決済アプリにおける所定の手続の完了を条件に、電子決済サービスを提供する。また、決済サーバ１００は、決済アプリ専用のインターフェイス（たとえば、決済サプリの機能により利用者端末１０に表示される各種操作画面）を介して、決済アプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。決済アプリは、決済先、決済元、及び決済額などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（すなわち、タイムスタンプ）などの情報が含まれていてもよい。

また、電子決済サービスには、コード決済を利用する場合の代金の支払方法として、「残高払い」や、「あと払い」や、「クレジットカード払い」など、各サービス利用者が選択可能な複数の支払方法が用意されている。「あと払い」および「クレジットカード払い」は、電子決済サービスのサービス利用者ＵＡが、コード決済を利用して取引対象の代金を支払う場合に選択可能な後払い方式の支払方法に該当する。なお、以下の説明において、「あと払い」および「後払い」は同義であり、説明の便宜上の言い替えに過ぎない。

たとえば、決済サーバ１００は、サービス利用者ＵＡにより「残高払い」が選択されている場合、サービス利用者ＵＡが保有する電子マネーの残高であるマネー残高から、取引対象の代金に相当する額の電子マネーを決済先の口座へ移行させることにより取引対象の代金を即時決済する。

また、サービス事業者ＵＢは、後述するクレジットカードサービス事業者ＵＣ（以下、「サービス事業者ＵＣ」と称する。）が、サービス利用者ＵＡが決済アプリにおいて利用登録済みのクレジットカードの運用会社である場合、サービス事業者ＵＣと互いに連携して、サービス利用者ＵＡにより「クレジットカード払い」が選択されている場合の決済処理を実現する。すなわち、サービス事業者ＵＣがサービス利用者ＵＡに提供するクレジットカードサービスは、サービス事業者ＵＢがサービス利用者ＵＡに提供する電子決済サービスと連携する他のサービスの一例である。サービス事業者ＵＢ、及びサービス事業者ＵＣは、業務連携に際して、ＩＤ連携などにより、互いの顧客に関する情報の紐付けを行う。互いの顧客に関する情報には、各サービスにおいて各サービス利用者に付与される識別情報や、各種代金の清算に用いる銀行口座の情報などが含まれている。たとえば、サービス事業者ＵＢ、及びサービス事業者ＵＣは、同一の顧客を特定するための情報として事業者間で共通の識別情報を管理してもよい。また、サービス事業者ＵＢ、又はサービス事業者ＵＣのいずれか一方において顧客に固有に割り振られている識別情報を他方の事業者が管理してもよい。たとえば、電子決済サービスにおいてサービス利用者ＵＡに対し、個別に割り振られているユーザＩＤを、サービス事業者ＵＣが同一の顧客に対応付けて管理してもよい。なお、決済サーバ１００、又はクレジットカードサーバ２００は、顧客の同一性を認証する際、eKYC（electronic Know Your Customer）などの手法を用いて、本人確認手続を実行してもよい。

たとえば、決済サーバ１００は、サービス利用者ＵＡにより「クレジットカード払い」が選択されている場合、取引対象の代金に相当する額の電子マネーを決済先の口座へ移行させる。また、サービス事業者ＵＢは、サービス事業者ＵＣに対して、取引対象の代金に相当する決済額を請求する。サービス事業者ＵＣは、サービス事業者ＵＢからの請求に応じて請求金額を支払う。また、クレジットカードサーバ２００は、サービス利用者ＵＡがクレジットカードの利用代金の引き落とし用口座として登録済みの銀行口座から、所定の期日にクレジットカードの利用代金の引落しを行うことにより回収する。

また、たとえば、決済サーバ１００は、サービス利用者ＵＡにより「あと払い」が選択されている場合、取引対象の代金を立替払いし、後日清算する。たとえば、決済サーバ１００は、サービス利用者ＵＡにより「あと払い」が選択されている場合、立替用口座から、取引対象の代金に相当する額の電子マネーを決済先の店舗が保有する電子マネー口座（電子マネーの残高が管理される口座）へ移行させたり、決済先となる店舗が保有する銀行口座に対して取引対象の代金に相当する額の現金を電子送金したりすることにより、取引対象の代金の立替を行う。また、決済サーバ１００は、サービス利用者ＵＡが「あと払い」の利用代金の引き落とし用口座として決済アプリに登録済みの銀行口座から、所定の期日に「あと払い」の利用代金の引落しを行うことにより回収する。

図２に示すクレジットカードサーバ２００は、サービス利用者ＵＡを含む顧客に対して、クレジットカードを用いた後払い方式のキャッシュレス決済サービスを提供するサービス事業者ＵＣにより運営および管理される情報処理装置である。サービス事業者ＵＣは、キャッシュレス決済サービスのユーザに対してクレジットカードを発行し、ユーザにより登録されたユーザ情報に対応付けてクレジットカードの情報を管理する。たとえば、クレジットカードサーバ２００は、サービス利用者ＵＡに対する後払い利用代金の請求状況を示す請求ステータス情報を管理する。クレジットカードサーバ２００は、メインフレームやワークステーションなどにより実現されてもよい。また、クレジットカードサーバ２００がサーバ装置で構成される場合、単独のサーバ装置により実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。

たとえば、クレジットカードサーバ２００は、決済サーバ１００から「クレジットカード払い」に関する請求情報を受信した場合、サービス事業者ＵＢに対して請求金額を支払う支払処理を実行する。また、クレジットカードサーバ２００は、電子決済サービスおける「クレジットカード払い」の利用登録時に、サービス事業者ＵＣが発行するクレジットカードを支払手段として利用登録するサービス利用者ＵＡを特定可能な状態で管理する。たとえば、クレジットカードサーバ２００は、サービス利用者ＵＡに対応するユーザＩＤを、サービス事業者ＵＣが運営するキャッシュレス決済サービスの顧客情報に対応付けて管理する。そして、クレジットカードサーバ２００は、電子決済サービスおいて「クレジットカード払い」を利用したサービス利用者ＵＡに対し、決済サーバ１００から受信する請求に基づいて、電子決済サービスおける「クレジットカード払い」の利用代金の請求を行う。また、クレジットカードサーバ２００は、サービス利用者ＵＡがクレジットカードの利用代金の引き落とし用口座として登録済みの銀行口座から、所定の期日にクレジットカードの利用代金の引落しを行うことにより回収する。

また、クレジットカードサーバ２００は、決済サーバ１００からの要求に応じて、電子決済サービスおける「あと払い」の利用代金を、「クレジットカード払い」の利用代金とともにまとめて引き落とす処理を実行してもよい。この場合、クレジットカードサーバ２００は、決済サーバ１００から「あと払い」の利用代金に関する請求情報を取得する。そして、クレジットカードサーバ２００は、取得した請求情報に含まれている「あと払い」の利用代金に基づいて、「クレジットカード払い」の利用代金とともに、「あと払い」の利用代金をまとめて引き落とす。

（１－２．利用者端末１０を用いた決済について）
ここで、利用者端末１０を用いたコード決済の一例について説明する。以下の説明では、たとえば、所定の店舗に配置された２次元コード（ＱＲコード（登録商標））であって、所定の店舗を識別する店舗識別情報を示す２次元コードを用いて、所定の店舗から取引対象の提供を受けるサービス利用者ＵＡが利用者端末１０を用いた決済を行う例について説明する。なお、以下に説明するコード決済の一例は、任意の利用者が任意の利用者端末１０を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報を示す２次元コードは、ＱＲコードのみならず、バーコードや所定のマーク、番号などであってもよい。また、２次元コードは、紙などの媒体に印字された印刷物により物理的に構成される例に限られず、任意の端末に表示される画像情報により構成されていてもよい。

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

決済サーバ１００は、利用者端末１０から取引情報を受け付けると、利用者識別情報が示すサービス利用者ＵＡの口座から、店舗識別情報が示す所定の店舗の口座へと、決済額に相当する分の電子マネーを移行させる。このとき、決済サーバ１００は、決済額に相当する分の電子マネーから所定の店舗に課金する所定の手数料を差し引いてから、所定の店舗の口座へ移行させてもよい。そして、決済サーバ１００は、取引が完了した旨の通知を利用者端末１０へと送信する。このような場合、利用者端末１０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨をサービス利用者ＵＡに通知する。あるいは、決済サーバ１００は、利用者識別情報が示すサービス利用者ＵＡの口座から決済額に相当する分の電子マネーを引き出して所定の店舗の売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を所定の店舗が保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、サービス利用者ＵＡの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨をサービス利用者ＵＡに通知してもよい。

なお、利用者端末１０を用いた決済は、上述した処理に限定されるものではない。たとえば、利用者端末１０を用いた決済は、所定の店舗に設置された端末装置（以下、「店舗端末」と称する。）を用いたものであってもよい。具体的には、まず、利用者端末１０は、サービス利用者ＵＡを識別するための利用者識別情報を示すコード情報を画面上に表示させる。このような場合、店舗端末は、利用者端末１０に表示されたコード情報から利用者識別情報を読み取り、読み取った利用者識別情報（もしくは、利用者識別情報が示す情報、すなわち、サービス利用者ＵＡを示す情報（たとえば、利用者ＩＤ））と、決済額と、所定の店舗を識別する情報とを含む取引情報を決済サーバ１００へと送信する。

決済サーバ１００は、店舗端末から取引情報を受け付けると、利用者識別情報が示すサービス利用者ＵＡの口座から、所定の店舗の口座へと、決済額に相当する分の電子マネーを移行させる。そして、決済サーバ１００は、店舗端末あるいは利用者端末１０に対し、取引が完了した旨の通知を送信する。店舗端末あるいは利用者端末１０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨をサービス利用者ＵＡに通知する。また、決済サーバ１００は、利用者識別情報が示すサービス利用者ＵＡの口座から決済額に相当する分の電子マネーを引き出して所定の店舗の売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を所定の店舗が保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、サービス利用者ＵＡの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を店員あるいはサービス利用者ＵＡに通知してもよい。

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

また、利用者端末１０を用いた決済は、サービス利用者ＵＡの口座から所定の店舗の口座へと電子マネーを移行させる処理のみならず、たとえば、サービス利用者ＵＡの口座から他のユーザの口座へと電子マネーを移行させる決済（すなわち、ユーザ間での送金）であってもよい。たとえば、送金元のサービス利用者ＵＡが利用する利用者端末１０は、送金先のユーザを識別する利用者識別情報（たとえば、送金先の利用者が利用する端末装置に表示される利用者識別情報）を読み取り、サービス利用者ＵＡから送金金額の入力を受け付け、読み取った識別情報と、送金金額と、サービス利用者ＵＡを識別する利用者識別情報とを示す情報を決済サーバ１００へと送信する。このような場合、決済サーバ１００は、サービス利用者ＵＡの口座から、送金先のユーザの口座へと、送金金額が示す額の電子マネーを移行させ、利用者端末１０または送金先のユーザが利用する端末装置に対し、送金が完了した旨の画面や所定の音声を出力させることで、送金が行われた旨を通知してもよい。

なお、利用者端末１０を用いた送金は、上述した処理に限定されるものではない。たとえば、利用者端末１０を用いた送金は、送金先のユーザの電話番号や、送金先のユーザを示す情報（たとえば、利用者ＩＤ）を利用者端末１０に入力することにより行われてもよい。具体的な例を挙げると、利用者端末１０は、送金先のユーザの電話番号または利用者ＩＤと、送金金額との入力をサービス利用者ＵＡから受け付け、入力された電話番号または利用者ＩＤと、送金金額と、サービス利用者ＵＡを識別する利用者識別情報とを決済サーバ１００へと送信する。そして、決済サーバ１００は、サービス利用者ＵＡの口座から、送信された電話番号または利用者ＩＤに紐づけられたユーザの口座へと、送金金額が示す額の電子マネーを移行させる。

ここで、送金先のユーザの電話番号や利用者ＩＤは、当該ユーザに関する情報と紐付けて決済アプリに予め登録されていてもよい。この場合、利用者端末１０は、決済アプリに登録されたユーザ（送金先）の指定と、当該ユーザへの送金金額の入力とをサービス利用者ＵＡから受け付け、指定されたユーザに紐付けられた電話番号または利用者ＩＤと、送金金額と、サービス利用者ＵＡを識別する利用者識別情報とを決済サーバ１００へと送信する。

また、たとえば、利用者端末１０を用いた送金は、送金金額を受け取るためのリンク情報を送金先のユーザに提供することにより行われてもよい。具体的な例を挙げると、利用者端末１０は、サービス利用者ＵＡから送金金額の入力を受け付けて送金金額を受け取るためのリンク情報を生成し、リンク情報を含む電子メールを送信したり、リンク情報を含む投稿情報をＳＮＳ（Social Networking Service）に投稿したりすることで、送金先のユーザが利用する端末装置にリンク情報を提供する。そして、送金先のユーザがリンク情報を選択して受け取り操作を行った場合、決済サーバ１００は、サービス利用者ＵＡの口座から、送金先のユーザの口座へと、送金金額が示す額の電子マネーを移行させる。

なお、上述した決済手段や決済サービスは、商品の購入や役務の提供に対する対価の提供（債務の精算）のためのものに限定されるものではない。例えば、上述したように、決済手段や決済サービスは、複数のユーザが有する口座間の送金に関する機能を有していてもよい。すなわち、上述した決済手段や決済サービスは、ユーザや店舗等、電子マネーの所有者と紐づく任意の所有者の口座間における電子マネーの送受信を制御するサービスであればよい。すなわち、実施形態に係る決済手段や決済サービスは、電子マネーのやり取りを実現するための各種制御（電子マネーを介した各種の口座間送金制御のみならず、電子マネー口座と銀行口座間のやり取りに関する制御や、分割、ボーナス払いに伴う処理といった各種債権処理、その他電子マネーを含む財産のやり取りに関する各種制御）を実行する取引手段や取引サービスであれば、任意の態様で提供されるものであってもよい。また、このような取引手段や取引サービスが実現する各種の制御には、決済に関する制御と送金に関する制御の両方が含まれていてもよく、いずれか一方のみが含まれていてもよい。すなわち、「取引」とは、電子マネーに関する「決済」のみならず、電子マネーの「送金」やその他各種の処理をも含む概念である。すなわち、決済サーバ１００は、任意の所有者間における電子マネーのやり取りを制御する取引手段を実現する情報処理装置であってもよい。

（１－３．実施形態に係る情報処理）
（１－３－１．実施形態に係る情報処理（その１）の概要）
以下、図１を用いて、実施形態に係る情報処理の概要について説明する。図１は、実施形態に係る情報処理（その１）の概要を説明するための図である。また、以下の説明では、クレジットカードサーバ２００が、サービス利用者ＵＡにより「あと払い」または「クレジットカード払い」を用いて実施されたコード決済の利用代金をまとめて回収する場合の情報処理の一例を示している。なお、以下の説明において、サービス利用者ＵＡと利用者端末１０とを同一視できる場合がある。すなわち、サービス利用者ＵＡを利用者端末１０と読み替えることができる。

図１に示すように、利用者端末１０は、サービス利用者ＵＡの操作に従って、決済アプリに搭載される「あと払い」の機能に対応するアプリ画面の表示要求を決済サーバ１００に送信する（ステップＳ０１）。表示要求には、電子決済サービスにおいてサービス利用者ＵＡを一意に特定するためのユーザＩＤ（たとえば、Ｕ＃００１）が含まれている。

決済サーバ１００は、利用者端末１０から「あと払い」の機能に対応するアプリ画面の表示要求を受信すると、対象ユーザに対応する後払い利用代金の請求状況を示す請求ステータス情報の取得要求をクレジットカードサーバ２００に送信する（ステップＳ０２）。たとえば、取得要求には、利用者端末１０から受信した表示要求に含まれているユーザＩＤ、すなわち、対象ユーザであるサービス利用者ＵＡを一意に特定するためのユーザＩＤ（たとえば、「Ｕ＃００１」）が同封される。

クレジットカードサーバ２００は、決済サーバ１００から請求ステータス情報の取得要求を受信すると、取得要求に含まれるユーザＩＤに対応付けられている請求ステータス情報を取得し、取得した請求ステータス情報を決済サーバ１００に応答する（ステップＳ０３）。

決済サーバ１００は、クレジットカードサーバ２００から請求ステータス情報を受信すると、受信した請求ステータス情報に基づいて、対象ユーザの請求状況を反映したアプリ画面を表示するための画面情報を利用者端末１０に送信する（ステップＳ０４）。

たとえば、決済サーバ１００は、サービス利用者ＵＡに対応する後払い利用代金の請求状況を示す画像情報を含む画面情報をサービス利用者ＵＡに提供してもよい。具体的には、決済サーバ１００は、請求状況として、「仮確定」、「確定」、「入金確認中」、「入金済」、又は「未払い」を示す画像情報を含む画面情報を提供できる。

利用者端末１０は、決済サーバ１００から画面情報を受信すると、受信した画面情報に基づいて、「あと払い」の機能に対応するアプリ画面Ｇ－１を表示する。図１に示す表示例ＥＸ－１～ＥＸ－５のそれぞれは、利用者端末１０に表示される「あと払い」の機能に対応するアプリ画面Ｇ－１の一例を示している。

たとえば、表示例ＥＸ－１に示されるアプリ画面Ｇ－１は、サービス利用者ＵＡに対する請求金額の仮確定の状態であることを示す画像情報ＯＢ－１を含んでいる。また、たとえば、表示例ＥＸ－２に示されるアプリ画面Ｇ－１は、サービス利用者ＵＡに対する請求金額が確定された状態であることを示す画像情報ＯＢ－２を含んでいる。また、たとえば、表示例ＥＸ－３に示されるアプリ画面Ｇ－１は、サービス利用者ＵＡからの後払い利用代金が入金されたか否かを確認する入金確認中の状態であることを示す画像情報ＯＢ－３を含んでいる。また、たとえば、表示例ＥＸ－４に示されるアプリ画面Ｇ－１は、サービス利用者ＵＡにより後払い利用代金の入金が確認された入金済みの状態であることを示す画像情報ＯＢ－４を含んでいる。また、たとえば、表示例ＥＸ－５に示されるアプリ画面Ｇ－１は、サービス利用者ＵＡにより後払い利用代金が未払いの状態であることを示す画像情報ＯＢ－５を含んでいる。

また、図１に示す表示例ＥＸ－１～ＥＸ－５に示すアプリ画面Ｇ－１のそれぞれは、請求状況に応じて対象ユーザが選択可能な後払い利用代金の支払方法を対象ユーザに提示し、後払い利用代金の支払方法の変更を受付可能なアプリ画面Ｇ－３（たとえば、図４参照）を、サービス利用者ＵＡからの操作に応じて利用者端末１０に表示させるためのリンク情報ＬＫを含んでいる。

また、図１に示す表示例ＥＸ－１～ＥＸ－５に示すアプリ画面Ｇ－１のうち、表示例ＥＸ－５に示されるアプリ画面Ｇ－１は、後払い利用代金の支払い期限からの経過日数を示す情報Ｍ－１や、後払い利用代金の返済を約束する所定の手続である「入金約束」をサービス利用者ＵＡから受け付けるためのボタンＢＴ－１を含んでいる。図２は、実施形態に係る入金約束の手続を行うためのアプリ画面の一例を示す図である。図２に示す表示例ＥＸ－６は、利用者端末１０に表示される「入金約束」の機能に対応するアプリ画面Ｇ－２の一例を示している。

図２に示すアプリ画面Ｇ－２は、請求金額を示す情報を含んでいる。また、図２に示すアプリ画面Ｇ－２は、後払い利用代金の返済を行う際にサービス利用者ＵＡが選択可能な支払方法の一覧を提示する領域や、サービス利用者ＵＡが後払い利用代金の返済予定日である支払予定日の設定を受け付けるための領域を含んでいる。サービス利用者ＵＡは、アプリ画面Ｇ－２を操作することにより、後払い利用代金の返済を行う際の支払方法を選択し、支払予定日を設定できる。また、利用者端末１０は、サービス利用者ＵＡの操作に従って、サービス利用者ＵＡにより設定された支払方法や支払予定日の情報を決済サーバ１００に送信できる。

図２に示すように、サービス利用者ＵＡが後払い利用代金の返済を行う際に選択可能な支払方法には、電子決済サービスにおいてサービス利用者ＵＡが保有する電子マネーの残高から支払を行う残高払いや、後払い利用代金の引き落とし口座として設定された銀行口座である支払口座からの再度の引落しにより支払う再振替や、電子帳票などを用いてコンビニエンスストアで支払うコンビニ支払いや、指定の銀行口座への振込により支払う銀行振込や、来月の利用代金とまとめて支払うまとめ払いなどが想定されている。たとえば、決済サーバ１００は、残高払いなどの即時決済が想定される支払方法や、まとめ払いなどの支払予定日が予め定められている支払方法がサービス利用者により選択された場合、支払予定日を設定する領域が自動的に表示されなくなるように制御してもよい。この場合、決済サーバ１００は、かかる制御を利用者端末１０に実行させるための制御情報を画面情報とともに利用者端末１０に送信してもよい。

また、図２に示す例において、決済サーバ１００は、サービス利用者ＵＡが後払い利用代金の返済を行う際に選択可能な支払方法として、アプリ画面Ｇ－２に表示される「残高払い」の項目に関連付けて、サービス利用者ＵＡが保有するマネー残高が利用可能額として表示される。決済サーバ１００は、画面情報に残高情報を含めて利用者端末１０に送信することにより、マネー残高の表示を実現する。また、決済サーバ１００は、マネー残高を表示する際、マネー残高が請求金額に対して残高不足であるか否かに応じて、たとえば、残高不足である場合、残高不足ではない場合よりも、マネー残高の情報が目立つように強調表示するなど表示態様を変更してもよい。この場合、決済サーバ１００は、かかる制御を利用者端末１０に実行させるための制御情報を画面情報とともに利用者端末１０に送信してもよい。

また、図２に示す例において、決済サーバ１００は、サービス利用者ＵＡが後払い利用代金の返済を行う際に選択可能な支払方法として、アプリ画面Ｇ－２に表示される「支払口座から再度引き落とし」の項目に関連付けて、サービス利用者ＵＡが引き落とし口座として設定した銀行口座の残高を表示してもよい。この場合、決済サーバ１００は、サービス利用者ＵＡにより保有される銀行口座が、サービス事業者ＵＢと連携する銀行からサービス利用者ＵＡにより貸与されている口座であり、この銀行からサービス利用者ＵＡの残高情報を取得可能な環境にあることを前提とする。また、この場合、決済サーバ１００は、かかる制御を利用者端末１０に実行させるための制御情報を画面情報とともに利用者端末１０に送信してもよい。

また、図２に示す例において、決済サーバ１００は、後払い利用代金の返済を行う際にサービス利用者ＵＡが選択可能な支払方法の一覧に含まれる各支払方法のうち、残高不足などにより使用できない支払方法が、使用可能な支払方法よりも下に表示されるように、標準を変更したり、使用できない支払方法を表示させないようにしたり、利用頻度の高い支払方法をより上部に表示したりするように制御してもよい。この場合、決済サーバ１００は、かかる制御を利用者端末１０に実行させるための制御情報を画面情報とともに利用者端末１０に送信してもよい。

また、図２に示す例において、決済サーバ１００は、支払方法として、残高払いや、支払口座からの再度の引き落としについて登録がない場合、対象ユーザを登録画面へ誘導するボタンなどをアプリ画面Ｇ－２に表示してもよい。たとえば、決済サーバ１００は、後払い利用代金の支払方法として残高払いを登録しているが、銀行口座からの引き落としの登録が行われていない場合、銀行口座からの引き落としを支払方法として設定するための操作に誘導してもよい。また、たとえば、決済サーバ１００は、後払い利用代金の支払方法として銀行口座からの引き落としを登録しているが、残高払いの登録が行われていない場合、残高払いを支払方法として設定するための操作に誘導してもよい。

また、図２に示す例において、決済サーバ１００は、アプリ画面Ｇ－２においてサービス利用者ＵＡにより設定される入金予定日の情報を受信した場合、入金予定日が経過する間、後払い利用代金の未払いの状態であるサービス利用者ＵＡに対して返済の催促を行うための所定のアクション（たとえば、支払の催促を行う架電など）の実行を一時的に停止してもよい。

また、図２に示す例において、決済サーバ１００は、アプリ画面Ｇ－２においてコンビニ支払いが支払方法として選択された場合、アプリ画面Ｇ－２において設定された入金予定日を、コンビニ支払いに用いる電子帳票に設けられているバーコードの有効期限として設定できる。

また、たとえば、決済サーバ１００は、上述の表示例ＥＸ－１および表示例ＥＸ－２に示すアプリ画面Ｇ－１の表示を行う場合、マネー残高や、電子マネーのオートチャージ設定をしている銀行口座の残高を合わせてアプリ画面Ｇ－１に表示させることにより、サービス利用者ＵＡに提供してもよい。たとえば、決済サーバ１００は、マネー残高のチャージ元としてサービス利用者ＵＡが設定している銀行口座を管理している銀行から提供を受ける当該銀行のシステムにアクセス可能なＡＰＩを用いて、サービス利用者ＵＡの銀行口座の残高の情報を取得し、取得した残高の情報をアプリ画面Ｇ－１に表示させる。また、決済サーバ１００は、マネー残高、又はマネー残高と銀行口座の残高とを合わせた額が、確定した請求金額よりも少ない場合、アプリ画面Ｇ－１において、マネー残高、又は銀行口座の残高を強調表示させてもよい。また、決済サーバ１００は、後払い利用代金の返済を行う際に選択可能な支払方法として、「マネー残高」を設定している場合にのみ、上述の表示を実行してもよい。

上述してきたように、実施形態に係る情報処理システムＳＹＳにおいて、決済サーバ１００は、後払い方式の支払方法である「あと払い」または「クレジットカード払い」を選択して行われたコード決済の利用代金である後払い利用代金の支払状況をサービス利用者ＵＡに認識させることができる。これにより、実施形態に係る情報処理システムＳＹＳにおいて、決済サーバ１００は、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ることができる。

（１－３－２．実施形態に係る情報処理（その２）の概要）
以下、図３を用いて、実施形態に係る情報処理（その２）の概要について説明する。図３は、実施形態に係る情報処理（その２）の概要を説明するための図である。

図３に示すように、利用者端末１０は、サービス利用者ＵＡの操作に従って、後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面の表示要求を決済サーバ１００に送信する（ステップＳ１１）。表示要求には、電子決済サービスにおいてサービス利用者ＵＡを一意に特定するためのユーザＩＤ（たとえば、Ｕ＃００１）が含まれている。

決済サーバ１００は、利用者端末１０から後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面の表示要求を受信すると、対象ユーザに対応する後払い利用代金の請求状況を示す請求ステータス情報の取得要求をクレジットカードサーバ２００に送信する（ステップＳ１２）。たとえば、取得要求には、利用者端末１０から受信した表示要求に含まれているユーザＩＤ、すなわち、対象ユーザであるサービス利用者ＵＡを一意に特定するためのユーザＩＤ（たとえば、「Ｕ＃００１」）が同封される。

クレジットカードサーバ２００は、決済サーバ１００から請求ステータス情報の取得要求を受信すると、取得要求に含まれるユーザＩＤに対応付けられている請求ステータス情報を取得し、取得した請求ステータス情報を決済サーバ１００に応答する（ステップＳ１３）。

決済サーバ１００は、クレジットカードサーバ２００から請求ステータス情報を受信すると、受信した請求ステータス情報に基づいて、対象ユーザに対する請求状況に応じた支払方法を選定する（ステップＳ１４）。また、決済サーバ１００は、対象ユーザに対する請求状況に応じた支払方法等を提示するアプリ画面を表示するための画面情報を利用者端末１０に送信する（ステップＳ１５）。

利用者端末１０は、決済サーバ１００から画面情報を受信すると、受信した画面情報に基づいて、後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面を表示する。図４は、実施形態に係る後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面の一例を示す図である。図４に示す表示例ＥＸ－７は、利用者端末１０に表示される後払い利用代金の支払方法等の変更受付機能に対応するアプリ画面Ｇ－３の一例を示している。

図４に示すアプリ画面Ｇ－３は、たとえば、図１に示すリンク情報ＬＫをサービス利用者ＵＡが操作することにより利用者端末１０に表示される。なお、アプリ画面Ｇ－４の表示契機は、図１に示すリンク情報ＬＫに対するサービス利用者ＵＡの操作検出には特に限定される必要はない。たとえば、アプリ画面Ｇ－３は、決済アプリのトップ画面に設けられているメニュー欄や、対象ユーザ宛ての電子メールに貼り付けられているリンクに対するサービス利用者ＵＡの操作検出を契機として、利用者端末１０に表示されてもよい。図４に示すように、アプリ画面Ｇ－３は、後払い利用代金の支払方法として、決済サーバ１００が対象ユーザであるサービス利用者ＵＡに対する後払い利用代金の請求状況に応じて選定した支払方法を示す情報の一覧を含んでいる。なお、支払方法を示す情報の一覧の中には、後払い利用代金の返済を約束する所定の手続である「入金約束」が含まれる場合があり、この場合、上述した図２に示すアプリ画面Ｇ－２に遷移させるためのボタンやリンクなどが設けられていてもよい。図５は、実施形態に係る請求状況と支払方法との対応関係を示す参照情報の一例を概念的に示す図である。

決済サーバ１００は、図５に示す参照情報Ｍ－２に基づいて、対象ユーザであるサービス利用者ＵＡに対する請求状況が「ＳＴ１－１」、「ＳＴ１－２」、「ＳＴ２－１」、「ＳＴ２－２」、「ＳＴ３－１」、又は「ＳＴ３－２」に該当する場合、サービス利用者ＵＡが選択可能な支払方法として、「支払方法Ｐ１」、「支払方法Ｐ２」、「支払方法Ｐ３」、「支払方法Ｐ４」、「支払方法Ｐ５」、「支払方法Ｐ６」、及び「支払方法Ｐ７」を選定することができる。

たとえば、サービス利用者ＵＡに対する請求状況が「ＳＴ１－１」である場合としては、請求金額が未確定の状態が想定される。また、たとえば、サービス利用者ＵＡに対する請求状況が「ＳＴ１－２」である場合としては、請求金額が仮確定した状態が想定される。また、たとえば、サービス利用者ＵＡに対する請求状況が「ＳＴ１－３」である場合としては、請求金額が確定した状態が想定される。

また、たとえば、サービス利用者ＵＡに対する請求状況が「ＳＴ２－１」、「ＳＴ２－２」、「ＳＴ２－３」、「ＳＴ３－１」、「ＳＴ３－２」、又は「ＳＴ３－３」である場合としては、請求金額に相当する額の入金が確認された入金済みの状態が想定される。

また、決済サーバ１００は、図５に示す参照情報Ｍ－２に基づいて、対象ユーザであるサービス利用者ＵＡの請求状況が「ＳＴ１－３」、「ＳＴ２－３」、又は「ＳＴ３－３」に該当する場合、サービス利用者ＵＡが選択可能な支払方法として、「支払方法１」、「支払方法２」、「支払方法３」、及び「支払方法４」を選定することができる。

また、決済サーバ１００は、図５に示す参照情報Ｍ－２に基づいて、対象ユーザであるサービス利用者ＵＡの請求状況が「ＳＴ４－１」、又は「ＳＴ４－２」に該当する場合、サービス利用者ＵＡが選択可能な支払方法として、「支払方法Ｐ８」、「支払方法Ｐ９」、及び「支払方法Ｐ１０」を選定することができる。また、図５に示すように、決済サーバ１００は、対象ユーザであるサービス利用者ＵＡの請求状況が「ＳＴ４－１」、又は「ＳＴ４－２」に該当する場合、「入金約束」を選定することができる。

サービス利用者ＵＡが選択可能な支払方法には、たとえば、リボルビング払いや、キャッシングや、分割払いや、繰り延べや、後払い利用代金を未払いである場合の残高払いや、コンビニエンスストアで利用可能なバーコード払いや、銀行口座の再振替払いや、繰り延べなどが含まれていてもよい。決済サーバ１００は、請求状況に応じて、サービス利用者ＵＡが選択可能な支払方法を選定する。

実施形態に係る情報処理システムＳＹＳにおいて、決済サーバ１００は、後払い方式の支払方法である「あと払い」または「クレジットカード払い」を選択して行われたコード決済の利用代金である後払い利用代金の支払状況をサービス利用者ＵＡに認識させることができる。これにより、実施形態に係る情報処理システムＳＹＳにおいて、決済サーバ１００は、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ることができる。

また、実施形態に係る情報処理（その２）において、決済サーバ１００は、「あと払い」の機能に対応するアプリ画面を表示する際、サービス利用者ＵＡに対応する後払い利用代金の請求状況が「入金済」である場合には、後払い利用代金の支払を行った際に用いた支払方法（たとえば、残高払いや口座振替など）を表示してもよい。

また、実施形態に係る情報処理（その２）において、決済サーバ１００は、「あと払い」の機能に対応するアプリ画面を表示する際、後払い利用代金の明細を合わせて表示してもよい。

〔２．装置構成〕
以下、図６を参照しつつ、実施形態に係る情報処理システムＳＹＳが有する決済サーバ１００の機能構成の一例を説明する。図６は、実施形態に係る決済サーバ１００の構成例を示す図である。図６に示すように、決済サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。

（通信部１１０について）
通信部１１０は、たとえば、ＮＩＣ（Network Interface Card）などによって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、利用者端末１０やクレジットカードサーバ２００などの他の装置との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、たとえば、ＲＡＭ（Random Access Memory）やフラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスクや光ディスクなどの記憶装置によって実現される。図６に示すように、記憶部１２０は、利用者情報記憶部１２１と、支払方法選定情報記憶部１２２とを有する。

（利用者情報記憶部１２１について）
利用者情報記憶部１２１は、電子決済サービスを利用するサービス利用者に関する利用者情報を記憶する。図７は、実施形態に係る利用者情報記憶部１２１に記憶される利用者情報の一例を示す図である。

図７に示すように、利用者情報記憶部１２１が記憶する利用者情報は、「ユーザＩＤ」の項目や、「残高払い取引履歴」の項目や、「あと払い取引履歴」の項目などといった複数の項目を有している。利用者情報が有するこれらの項目は、相互に対応付けられている。

「ユーザＩＤ」の項目には、電子決済サービスを利用するサービス利用者（たとえば、図１に示すサービス利用者ＵＡなど）を一意に特定するために各サービス利用者に対して個別に割り振られる固有の識別情報であるユーザＩＤが記憶される。

「残高払い取引履歴」の項目には、コード決済による取引のうち、「残高払い」を選択して行われた取引の履歴が記憶される。取引の履歴には、取引ごとに、決済日時や、決済先や、決済額などの情報が含まれていてもよい。

「あと払い取引履歴」の項目には、コード決済による取引のうち、「あと払い」を選択して行われた取引の履歴が記憶される。取引の履歴には、取引ごとに、決済日時や、決済先や、決済額などの情報が含まれていてもよい。

（支払方法選定情報記憶部１２２について）
支払方法選定情報記憶部１２２は、後払い利用代金の利用代金の支払方法等の変更を要求する対象ユーザに対して、対象ユーザに対応する後払い利用代金の請求状況に応じた支払方法を選定するための参照情報（たとえば、図５に示す参照情報Ｍ－２など）が記憶される。

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

図４に示すように、制御部１３０は、取得部１３１と、提供部１３２とを有し、これらの各部により、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０には、決済サーバ１００が実行する各種処理の拡張などに応じて、図６に示す各部とは異なる新たな機能部が導入されてもよい。

（取得部１３１について）
取得部１３１は、コード決済を利用するために電子決済サービスのユーザであるサービス利用者ＵＡに提供される決済用アプリの画面であって、アプリ画面Ｇ－１（「後払い方式の支払方法に対応する第１の画面」の一例）の表示要求をサービス利用者ＵＡから受け付けた場合、電子決済サービスと連携する他のサービスであって、電子決済サービスを通じてクレジットカード払い（「後払い方式の支払方法」の一例）をサービス利用者ＵＡに提供する決済サービスを運営するサービス事業者ＵＣが管理するクレジットカードサーバ２００（「他の装置」の一例）から、表示要求の送信元であるサービス利用者ＵＡ（「対象ユーザ」の一例）に対応する後払い利用代金の請求状況を示す請求ステータス情報を取得する。

（提供部１３２について）
提供部１３２は、取得部１３１により取得された請求ステータス情報に基づいて、対象ユーザ（たとえば、サービス利用者ＵＡ）に対応する請求状況を反映したアプリ画面Ｇ－１を表示するための画面情報を、通信部１１０を通じて利用者端末１０に送信することにより、対象ユーザに提供する。

また、提供部１３２は、請求状況を示す画像情報を含む画面情報を利用者端末１０に送信することにより、対象ユーザに提供してもよい。

また、提供部１３２は、請求状況として、後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いを示す画像情報を含む画面情報を利用者端末１０に送信することにより、対象ユーザに提供してもよい。

また、提供部１３２は、請求状況に応じて対象ユーザが選択可能な後払い利用代金の支払方法を対象ユーザに提示し、支払方法の変更を受付可能なアプリ画面Ｇ－３（「第２の画面」の一例）を表示するための画面情報を利用者端末１０に送信することにより、対象ユーザに提供してもよい。

また、提供部１３２は、請求状況が未払いである場合、後払い利用代金の支払方法および入金予定日を対象ユーザから受付可能なアプリ画面Ｇ－２（「第３の画面」の一例）を表示するための画面情報を利用者端末１０に送信することにより、対象ユーザに提供してもよい。

また、提供部１３２は、上述の表示例ＥＸ－１および表示例ＥＸ－２に示すアプリ画面Ｇの表示を行う場合、マネー残高や、電子マネーのオートチャージ設定をしている銀行口座の残高を合わせてアプリ画面Ｇに表示させることにより、サービス利用者ＵＡに提供してもよい。たとえば、提供部１３２は、マネー残高のチャージ元としてサービス利用者ＵＡが設定している銀行口座を管理している銀行から提供を受ける当該銀行のシステムにアクセス可能なＡＰＩを用いて、サービス利用者ＵＡの銀行口座の残高の情報を取得し、取得した残高の情報をアプリ画面Ｇに表示させる。また、提供部１３２は、マネー残高、又はマネー残高と銀行口座の残高とを合わせた額が、確定した請求金額よりも少ない場合、アプリ画面Ｇにおいて、マネー残高、又は銀行口座の残高を強調表示させてもよい。また、提供部１３２は、後払い利用代金の返済を行う際に選択可能な支払方法として、「マネー残高」を設定している場合にのみ、上述の表示を実行してもよい。

〔３．処理手順例〕
（３－１．決済サーバ１００による情報処理（その１））
以下、実施形態に係る決済サーバ１００により実行される情報処理の流れについて説明する。まず、図８を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順の一例を説明する。図８は、実施形態に係る決済サーバ１００により実行される情報処理（その１）の処理手順の一例を示すフローチャートである。なお、図８に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図８に示す処理手順を繰り返し実行する。

図８に示すように、取得部１３１は、通信部１１０を通じて、電子決サービスのユーザから、「あと払い」の機能に対応するアプリ画面の表示要求を受け付ける（ステップＳ１０１）。

取得部１３１は、アプリ画面の表示要求の送信元である対象ユーザの請求ステータス情報の取得要求を、通信部１１０を通じて、クレジットカードサーバ２００に送信する（ステップＳ１０２）。

取得部１３１は、通信部１１０を通じて、クレジットカードサーバ２００から送信された対象ユーザの請求ステータス情報を取得する（ステップＳ１０３）。

提供部１３２は、取得部１３１により取得された請求ステータス情報に基づいて、対象ユーザに対応する後払い利用代金の請求状況を反映したアプリ画面を対象ユーザに提供して（ステップＳ１０４）、図８に示す処理手順を終了する。

（３－２．決済サーバ１００による情報処理（その２））
以下、図９を用いて、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順の一例を説明する。図９は、実施形態に係る決済サーバ１００により実行される情報処理（その２）の処理手順の一例を示すフローチャートである。なお、図９に示す処理手順は、決済サーバ１００が有する制御部１３０により実行される。制御部１３０は、決済サーバ１００の稼働中、図９に示す処理手順を繰り返し実行する。

図９に示すように、取得部１３１は、通信部１１０を通じて、電子決サービスのユーザから、後払い利用代金の支払方法等の変更を受け付けるための変更受付機能に対応するアプリ画面の表示要求を受け付ける（ステップＳ２０１）。

取得部１３１は、アプリ画面の表示要求の送信元である対象ユーザの請求ステータス情報の取得要求を、通信部１１０を通じて、クレジットカードサーバ２００に送信する（ステップＳ２０２）。

取得部１３１は、通信部１１０を通じて、クレジットカードサーバ２００から送信された対象ユーザの請求ステータス情報を取得する（ステップＳ２０３）。

提供部１３２は、取得部１３１により取得された請求ステータス情報に基づいて、対象ユーザに対応する後払い利用代金の請求状況に応じて、対象ユーザが選択可能な支払方法を選定する（ステップＳ２０４）。

提供部１３２は、対象ユーザに対応する後払い利用代金の請求状況に応じた支払方法等を提示するアプリ画面を対象ユーザに提供して（ステップＳ２０５）、図９に示す処理手順を終了する。

〔４．変形例〕
上述の実施形態では、実施形態に係る情報処理システムＳＹＳは、決済サーバ１００とクレジットカードサーバ２００とを含んで構成される例を説明したが、このような例には特に限定される必要はない。たとえば、決済サーバ１００と、クレジットカードサーバ２００とが機能的または物理的に統合された単独のサーバであってもよい。また、決済サーバ１００の制御部１３０が有する処理機能の一部を、クレジットカードサーバ２００に分散してもよい。

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

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

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

〔５．効果〕
上述してきたように、実施形態に係る情報処理システムＳＹＳが有する決済サーバ１００は、所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置であって、取得部１３１と、提供部１３２とを有する。取得部１３１は、コード決済を利用するために電子決済サービスのユーザであるサービス利用者ＵＡに提供される決済用アプリの画面であって、アプリ画面Ｇ－１（「後払い方式の支払方法に対応する第１の画面」の一例）の表示要求をサービス利用者ＵＡから受け付けた場合、電子決済サービスと連携する他のサービスであって、電子決済サービスを通じてクレジットカード払い（「後払い方式の支払方法」の一例）をサービス利用者ＵＡに提供する決済サービスを運営するサービス事業者ＵＣが管理するクレジットカードサーバ２００（「他の装置」の一例）から、表示要求の送信元であるサービス利用者ＵＡ（「対象ユーザ」の一例）に対応する後払い利用代金の請求状況を示す請求ステータス情報を取得する。提供部１３２は、取得部１３１により取得された請求ステータス情報に基づいて、対象ユーザ（たとえば、サービス利用者ＵＡ）に対応する請求状況を反映したアプリ画面Ｇ－１を表示するための画面情報を、通信部１１０を通じて利用者端末１０に送信することにより、対象ユーザに提供する。

このようにして、実施形態に係る情報処理システムＳＹＳが有する決済サーバ１００は、後払い方式の支払方法である「あと払い」または「クレジットカード払い」を選択して行われたコード決済の利用代金である後払い利用代金の支払状況をサービス利用者ＵＡに認識させることができる。これにより、実施形態に係る情報処理システムＳＹＳにおいて、決済サーバ１００は、後払いタイプのキャッシュレス決済におけるユーザビリティの向上を図ることができる。

また、提供部１３２は、請求状況を示す画像情報を含む画面情報を提供してもよい。これにより、決済サーバ１００は、対象ユーザに、後払い利用代金の支払状況を容易に認識させることができる。

また、提供部１３２は、請求状況として、後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いを示す画像情報を含む画面情報を提供してもよい。これにより、決済サーバ１００は、対象ユーザに、後払い利用代金の支払状況を段階ごとに容易に認識させることができる。

また、提供部１３２は、請求状況に応じて対象ユーザが選択可能な後払い利用代金の支払方法を対象ユーザに提示し、支払方法の変更を受付可能なアプリ画面Ｇ－３（「第２の画面」の一例）を表示するための画面情報を対象ユーザに提供してもよい。これにより、決済サーバ１００は、対象ユーザに対して、後払い利用代金の請求状況に応じて選択可能な支払方法の確認および変更手続きを容易に実行させることができ、ユーザビリティを向上できる。

また、提供部１３２は、請求状況が未払いである場合、後払い利用代金の支払方法および入金予定日を対象ユーザから受付可能なアプリ画面Ｇ－２（「第３の画面」の一例）を表示するための画面情報を対象ユーザに提供してもよい。これにより、決済サーバ１００は、対象ユーザの後払い利用代金の返済手続きを円滑に実行でき、ユーザビリティを向上できる。

〔６．ハードウェア構成〕
また、上述してきた実施形態または変形例に係る決済サーバ１００は、たとえば、図１０に示すような構成のコンピュータ１０００によって実現される。図１０は、実施形態または変形例に係る情報処理システムを構成する決済サーバ１００の機能を実現するコンピュータの一例を示すハードウェア構成図である。

コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラムなどに基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭなど、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory)、ＨＤＤ、フラッシュメモリ等により実現される。

出力ＩＦ１０６０は、モニタやプリンタといった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェイスであり、たとえば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力ＩＦ１０７０は、マウス、キーボード、およびスキャナなどといった各種の入力装置１０２０から情報を受信するためのインターフェイスであり、たとえば、ＵＳＢなどにより実現される。

なお、入力装置１０２０は、たとえば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）などの光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリなどから情報を読み出す装置であってもよい。また、入力装置１０２０は、ＵＳＢメモリなどの外付け記憶媒体であってもよい。

ネットワークＩＦ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

演算装置１０３０は、出力ＩＦ１０６０や入力ＩＦ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。たとえば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

たとえば、コンピュータ１０００が実施形態または変形例に係る決済サーバ１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）を実行することにより、制御部１３０と同様の機能を実現する。すなわち、演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、実施形態または変形例に係る決済サーバ１００による処理を実現する。

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

また、上述した決済サーバ１００およびクレジットカードサーバ２００は、機能によっては外部のプラットフォームなどをＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

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

ＳＹＳ 情報処理システム
１０ 利用者端末
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 利用者情報記憶部
１２２ 支払方法選定情報記憶部
１３０ 制御部
１３１ 取得部
１３２ 提供部
２００ クレジットカードサーバ

Claims (11)

1. 取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置であって、
   前記電子決済サービスのユーザに提供される決済用アプリケーションの画面であって、前記後払い方式の支払方法に対応する第１の画面の表示要求を前記ユーザから受け付けた場合、前記表示要求の送信元である対象ユーザに対応する後払い利用代金の請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す請求ステータス情報を取得する取得部と、
   前記取得部により取得された前記請求ステータス情報に基づいて、前記対象ユーザに対応する前記請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを反映した前記第１の画面を表示するための画面情報を前記対象ユーザに提供する提供部と
   を有することを特徴とする情報処理装置。
2. 前記提供部は、
   前記請求状況を示す画像情報を含む前記画面情報を提供する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記提供部は、
   前記請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す前記画像情報を含む前記画面情報を提供する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記提供部は、
   前記請求状況が前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれに該当するかに応じて前記対象ユーザが選択可能な前記後払い利用代金の支払方法を前記対象ユーザに提示し、前記支払方法の変更を受付可能な第２の画面を表示するための画面情報を提供する
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記提供部は、
   前記請求状況と前記後払い利用代金の支払方法との対応関係を示す参照情報に基づいて、前記対象ユーザが選択可能な前記後払い利用代金の支払方法を前記第２の画面に表示するための画面情報を提供する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記提供部は、
   前記請求状況が入金済に該当する場合、前記後払い利用代金を支払った際に用いた支払方法を表示する前記第２の画面を表示するための画面情報を提供する
   ことを特徴とする請求項４に記載の情報処理装置。
7. 前記提供部は、
   前記対象ユーザが選択可能な前記後払い利用代金の支払方法に電子マネーが含まれる場合、前記対象ユーザに紐付くマネー残高の情報を前記第２の画面に表示するための画面情報を提供する
   ことを特徴とする請求項４に記載の情報処理装置。
8. 前記提供部は、
   前記電子マネーのオートチャージ設定をしている銀行口座の残高をあわせて表示するための画面情報を提供する
   ことを特徴とする請求項７に記載の情報処理装置。
9. 前記提供部は、
   前記請求状況が未払いである場合、前記後払い利用代金の支払方法および入金予定日を前記対象ユーザから受付可能な第３の画面を表示するための画面情報を提供する
   請求項４に記載の情報処理装置。
10. 取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行するコンピュータが実行する情報処理方法であって、
    前記電子決済サービスのユーザに提供される決済用アプリケーションの画面であって、前記後払い方式の支払方法に対応する第１の画面の表示要求を前記ユーザから受け付けた場合、前記表示要求の送信元である対象ユーザに対応する後払い利用代金の請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す請求ステータス情報を取得する取得工程と、
    前記取得工程により取得された前記請求ステータス情報に基づいて、前記対象ユーザに対応する前記請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを反映した前記第１の画面を表示するための画面情報を前記対象ユーザに提供する提供工程と
    を含むことを特徴とする情報処理方法。
11. 取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行するコンピュータに、
    前記電子決済サービスのユーザに提供される決済用アプリケーションの画面であって、前記後払い方式の支払方法に対応する第１の画面の表示要求を前記ユーザから受け付けた場合、前記表示要求の送信元である対象ユーザに対応する後払い利用代金の請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを示す請求ステータス情報を取得する取得手順と、
    前記取得手順により取得された前記請求ステータス情報に基づいて、前記対象ユーザに対応する前記請求状況として、前記後払い利用代金の仮確定、確定、入金確認中、入金済、又は未払いのいずれかを反映した前記第１の画面を表示するための画面情報を前記対象ユーザに提供する提供手順と
    を実行させることを特徴とする情報処理プログラム。

Images