JP7414206B1 - 情報処理システム、及び情報処理方法 - 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）などの集積回路により実現され得る。

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

（受付部１３１について）
受付部１３１は、電子決済サービスを利用するサービス利用者（たとえば、図１に示すサービス利用者ＵＡなど）に提供されるクレジットカード払いの利用代金のうち、未確定の利用代金の前倒し支払いの要求を、通信部１１０を通じて、サービス利用者から受け付ける。

（提供部１３２について）
提供部１３２は、受付部１３１により前倒し支払いの要求が受け付けられた場合、前倒し支払いの要求元である対象ユーザに対して、前倒し支払いの手続を対象ユーザから受け付けるためのアプリ画面Ｇ－２（たとえば、図２参照）を対象ユーザに提供する。たとえば、提供部１３２は、対象ユーザが使用する利用者端末１０に対して、前倒し支払いの手続を対象ユーザから受け付けるアプリ画面Ｇ－２を表示させるための画面情報を、通信部１１０を通じて利用者端末１０に送信することにより、対象ユーザに提供する。

また、提供部１３２は、前倒し支払いの方法として、対象ユーザに紐付く電子マネーの残高であるマネー残高による残高払い、及び所定の銀行口座への銀行振込のうちの少なくともいずれか一方を選択可能なアプリ画面Ｇ－２を対象ユーザに提供してもよい。

また、提供部１３２は、クレジットカードサーバ２００から対象ユーザに紐付くクレジットカード払いの利用明細情報を取得し、取得した利用明細情報に基づいて、マネー残高により利用代金の前倒し支払いが可能であると判定されることを条件、前倒し支払いの方法として残高払いを含むアプリ画面Ｇ－２を提供してもよい。

また、提供部１３２は、アプリ画面Ｇ－２において銀行振込が選択された場合、銀行振込に関する手続の確認を行うための画面であって、利用代金の入金予定日の指定を対象ユーザから受け付けることが可能な確認画面Ｇ－４を提供してもよい。

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

また、提供部１３２は、対象ユーザ（たとえば、サービス利用者ＵＡ）が登録済みの銀行口座であって、対象ユーザが電子決済サービスにおいて保有するマネー残高へのチャージ（オートチャージを含む）を行う際のチャージ元として設定される銀行口座の残高と、マネー残高とを合わせた額が利用代金を上回っている場合、利用代金の前倒し支払いの支払方法として「マネー残高」および「銀行振込」を選択肢として合わせてアプリ画面Ｇに表示させることにより、対象ユーザに提供してもよい。

また、決済サーバ１００は、サービス利用者ＵＡから受け付けた入金予定日になった場合、決済アプリを介して、サービス利用者ＵＡに入金予定日である旨と合わせて、振込先情報を通知する通知部を有していてもよい。また、その際に、通知部は、サービス利用者ＵＡに、入金したか否かを回答させてもよい。この場合、通知部は、サービス利用者ＵＡから入金した旨の回答があった旨の情報をクレジットカードサーバ２００に通知してもよい。

（２－２．クレジットカードサーバ２００の構成）
以下、図５を参照しつつ、実施形態に係る情報処理システムＳＹＳが有するクレジットカードサーバ２００の機能構成の一例を説明する。図５は、実施形態に係るクレジットカードサーバ２００の構成例を示す図である。図５に示すように、クレジットカードサーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。

（通信部２１０について）
通信部２１０は、たとえば、ＮＩＣ（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 (6)

1. 所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法としてクレジットカード払いを選択可能な電子決済サービスに関する処理を実行する第１装置と、前記クレジットカード払いの決済処理において前記第１装置と連携する第２装置とを含む情報処理システムであって、
   前記第１装置は、
   前記電子決済サービスのユーザに提供される前記クレジットカード払いの利用代金のうち、未確定の前記利用代金の前倒し支払いの要求を前記ユーザから受け付ける受付部と、
   前記受付部により前記前倒し支払いの要求が受け付けられた場合、前記前倒し支払いの要求元である対象ユーザに対して、前記前倒し支払いの手続を前記対象ユーザから受け付けるための第１画面を前記対象ユーザに提供する提供部と
   を有することを特徴とする情報処理システム。
2. 前記提供部は、
   前記前倒し支払いの方法として、前記対象ユーザに紐付く電子マネーの残高であるマネー残高による残高払い、及び所定の銀行口座への銀行振込のうちの少なくともいずれか一方を選択可能な前記第１画面を前記対象ユーザに提供する
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記提供部は、
   前記第２装置から前記対象ユーザに紐付くクレジットカード払いの利用明細情報を取得し、取得した利用明細情報に基づいて、前記マネー残高により前記利用代金の前倒し支払いが可能であると判定されることを条件に、前記前倒し支払いの方法として前記残高払いを含む前記第１画面を提供する
   ことを特徴とする請求項２に記載の情報処理システム。
4. 前記提供部は、
   前記第１画面において銀行振込が選択された場合、前記銀行振込に関する手続の確認を行うための画面であって、前記利用代金の入金予定日の指定を前記対象ユーザから受け付けることが可能な第２画面を提供する
   ことを特徴とする請求項１に記載の情報処理システム。
5. 前記第２装置は、
   前記ユーザごとに前記クレジットカード払いの利用可能額を管理する管理部
   を有し、
   前記管理部は、
   前記前倒し支払いによる前記利用代金の支払いが確認された場合、前記利用代金に相当する額の分だけ、前記対象ユーザに紐付く前記利用可能額を増加させる
   ことを特徴とする請求項１に記載の情報処理システム。
6. 所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法としてクレジットカード払いを選択可能な電子決済サービスに関する処理を実行する第１装置と、前記クレジットカード払いの決済処理において前記第１装置と連携する第２装置を含む情報処理システムが実行する情報処理方法であって、
   前記第１装置が、
   前記電子決済サービスのユーザに提供される前記クレジットカード払いの利用代金のうち、未確定の前記利用代金の前倒し支払いの要求を前記ユーザから受け付ける受付工程と、
   前記受付工程により前記前倒し支払いの要求が受け付けられた場合、前記前倒し支払いの要求元である対象ユーザに対して、前記前倒し支払いの手続を前記対象ユーザから受け付けるための第１画面を前記対象ユーザに提供する提供工程と
   を含むことを特徴とする情報処理方法。

Images