特許 7564302 情報処理装置、情報処理方法、及び情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-09-30

(45)【発行日】2024-10-08

(54)【発明の名称】情報処理装置、情報処理方法、及び情報処理プログラム

(51)【国際特許分類】

   G06Q 20/08 20120101AFI20241001BHJP

【ＦＩ】

G06Q20/08

【請求項の数】 12

(21)【出願番号】P 2023124854

(22)【出願日】2023-07-31

【審査請求日】2023-07-31

【審判番号】

【審判請求日】2024-03-11

【早期審査対象出願】

(73)【特許権者】

【識別番号】519110124

【氏名又は名称】ＰａｙＰａｙ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】岩松 崇

(72)【発明者】

【氏名】荒尾 梨央

(72)【発明者】

【氏名】工藤 大輔

(72)【発明者】

【氏名】原口 智孝

【合議体】

【審判長】松田 直也

【審判官】佐藤 智康

【審判官】伏本 正典

(56)【参考文献】

【文献】特開２０２１－１１４１１３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

G06Q 10/00-99/00

(57)【特許請求の範囲】

【請求項1】

所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置であって、
前記コード決済により前記代金の支払いを行うための決済用アプリケーションの画面表示要求をユーザから受信した場合、前記電子決済サービスと連携する他のサービスであって、前記電子決済サービスを通じて前記後払い方式の支払方法を前記電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、前記画面表示要求の送信元である前記ユーザに対応する後払い利用代金の返済状況を示す情報を取得する取得部と、
前記取得部により、前記返済状況を示す情報として、前記ユーザが前記後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、前記返済状況を示す情報に含まれている前記後払い利用代金を返済済みの状態であるか否かを示す情報、及び前記後払い方式の支払方法に関する前記ユーザのステータスを示すステータス情報に基づいて、前記後払い利用代金の返済に関する前記ユーザの現在の状況を特定する特定部と、
前記ユーザにより、前記決済用アプリケーションにおいて前記支払方法として前記後払い方式の支払方法が選択された場合、前記特定部により特定された前記ユーザの現在の状況に応じて、前記決済用アプリケーションの画面の表示態様を決定し、決定した前記画面の表示態様に対応する画面情報を前記ユーザにより使用される利用者端末に送信する決定部と
を有することを特徴とする情報処理装置。

【請求項2】

前記決定部は、
前記ユーザより、前記決済用アプリケーションにおいて前記支払方法として、前記ユーザが保有する電子マネーの残高であるマネー残高から前記代金の支払いを行う支払い方法である残高払いから前記後払い方式の支払方法へ切り替える操作を検出した場合、前記決済用アプリケーションの画面の表示態様を決定する
ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記決定部は、
前記決済用アプリケーションの画面の表示態様として、前記画面の背景色の変更を決定する
ことを特徴とする請求項１または２に記載の情報処理装置。

【請求項4】

前記後払い利用代金の支払方法として電子マネーが選択されている場合、前記他の装置から、前記返済状況を示す情報を取得せずに情報処理装置内で保持している返済状況を取得して、取得した返済状況に基づいて、前記ユーザが前記未払いユーザに該当するか否かを判定する制御部
をさらに有することを特徴とする請求項１に記載の情報処理装置。

【請求項5】

前記特定部は、
前記後払い利用代金の返済に関する対象ユーザの現在の状況が当該現在の状況をいずれかに分類するための分類パターンのいずれに該当するかを特定し、
前記決定部は、
前記特定部により特定された分類パターンと、前記分類パターンに予め対応付けられている前記決済用アプリケーションの画面の表示態様とに基づいて、前記決済用アプリケーションの画面の表示態様を決定する
ことを特徴とする請求項１に記載の情報処理装置。

【請求項6】

前記決定部は、
前記ユーザの現在の状況が前記後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつ前記ユーザにより前記後払い利用代金の返済を約束する所定の手続が行われていないという状況に分類される場合、分類される状況に対応付けて予め設定される第１の表示態様に前記画面の表示態様を決定する
ことを特徴とする請求項５に記載の情報処理装置。

【請求項7】

前記決定部は、
前記ユーザの現在の状況が前記後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつ前記ユーザが前記後払い利用代金の返済を約束する所定の手続を受付済みの状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第２の表示態様に前記画面の表示態様を決定する
ことを特徴とする請求項５に記載の情報処理装置。

【請求項8】

前記決定部は、
前記ユーザの現在の状況が前記後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつ前記ユーザが前記後払い利用代金の返済を約束する所定の手続に基づく返済が履行されなかったという状況に分類される場合、分類される状況に対応付けて予め設定される第３の表示態様に前記画面の表示態様を決定する
ことを特徴とする請求項５に記載の情報処理装置。

【請求項9】

前記決定部は、
前記ユーザの現在の状況が前記後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつ前記ユーザが前記後払い利用代金の返済を約束する所定の手続に基づいて履行された返済額を確認中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第４の表示態様に前記画面の表示態様を決定する
ことを特徴とする請求項５に記載の情報処理装置。

【請求項10】

前記決定部は、
前記ユーザの現在の状況が前記後払い方式の支払方法の利用が停止されている利用停止中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第５の表示態様に前記画面の表示態様を決定する
ことを特徴とする請求項５に記載の情報処理装置。

【請求項11】

所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行するコンピュータにより行われる情報処理方法であって、
前記コード決済により前記代金の支払いを行うための決済用アプリケーションの画面表示要求をユーザから受信した場合、前記電子決済サービスと連携する他のサービスであって、前記電子決済サービスを通じて前記後払い方式の支払方法を前記電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、前記画面表示要求の送信元である前記ユーザに対応する後払い利用代金の返済状況を示す情報を取得する取得工程と、
前記取得工程により、前記返済状況を示す情報として、前記ユーザが前記後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、前記返済状況を示す情報に含まれている前記後払い利用代金を返済済みの状態であるか否かを示す情報、及び前記後払い方式の支払方法に関する前記ユーザのステータスを示すステータス情報に基づいて、前記後払い利用代金の返済に関する前記ユーザの現在の状況を特定する特定工程と、
前記ユーザにより、前記決済用アプリケーションにおいて前記支払方法として前記後払い方式の支払方法が選択された場合、前記特定工程により特定された前記ユーザの現在の状況に応じて、前記決済用アプリケーションの画面の表示態様を決定し、決定した前記画面の表示態様に対応する画面情報を前記ユーザにより使用される利用者端末に送信する決定工程と
を含むことを特徴とする情報処理方法。

【請求項12】

所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行するコンピュータに、
前記コード決済により前記代金の支払いを行うための決済用アプリケーションの画面表示要求をユーザから受信した場合、前記電子決済サービスと連携する他のサービスであって、前記電子決済サービスを通じて前記後払い方式の支払方法を前記電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、前記画面表示要求の送信元である前記ユーザに対応する後払い利用代金の返済状況を示す情報を取得する取得手順と、
前記取得手順により、前記返済状況を示す情報として、前記ユーザが前記後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、前記返済状況を示す情報に含まれている前記後払い利用代金を返済済みの状態であるか否かを示す情報、及び前記後払い方式の支払方法に関する前記ユーザのステータスを示すステータス情報に基づいて、前記後払い利用代金の返済に関する前記ユーザの現在の状況を特定する特定手順と、
前記ユーザにより、前記決済用アプリケーションにおいて前記支払方法として前記後払い方式の支払方法が選択された場合、前記特定手順により特定された前記ユーザの現在の状況に応じて、前記決済用アプリケーションの画面の表示態様を決定し、決定した前記画面の表示態様に対応する画面情報を前記ユーザにより使用される利用者端末に送信する決定手順と
を実行させることを特徴とする情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１１－１０８２２１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記の従来技術では、後払いタイプのキャッシュレス決済の円滑な運用を図る上で改善の余地がある。

【0006】

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

【課題を解決するための手段】

【0007】

本願に係る情報処理装置は、所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置であって、取得部と、特定部と、決定部とを有する。取得部は、コード決済により代金の支払いを行うための決済用アプリケーションの画面表示要求をユーザから受信した場合、電子決済サービスと連携する他のサービスであって、電子決済サービスを通じて後払い方式の支払方法を電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、画面表示要求の送信元であるユーザに対応する後払い利用代金の返済状況を示す情報を取得する。特定部は、取得部により、返済状況を示す情報として、ユーザが後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、後払い利用代金の返済に関するユーザの現在の状況を特定する。決定部は、特定部により特定されたユーザの現在の状況に応じて、決済用アプリケーションの画面の表示態様を決定する。

【発明の効果】

【0008】

実施形態の一態様によれば、後払いタイプのキャッシュレス決済の円滑な運用を図ることができるという効果を奏する。

【図面の簡単な説明】

【0009】

【図1】図１は、実施形態に係る情報処理の概要を説明するための図である。

【図2】図２は、実施形態に係る決済サーバの構成例を示す図である。

【図3】図３は、実施形態に係る利用者情報記憶部に記憶される利用者情報の一例を示す図である。

【図4】図４は、実施形態に係る表示態様情報記憶部に記憶される表示態様情報の一例を示す図である。

【図5】図５は、実施形態に係る決済サーバにより実行される情報処理の処理手順の一例を示すフローチャートである。

【図6】図６は、実施形態または変形例に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

【発明を実施するための形態】

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

決済サーバ１００は、利用者端末１０から画面表示要求を受信すると、サービス利用者ＵＡに対応する返済状況情報の取得要求をクレジットカードサーバ２００に送信する（ステップＳ０２）。画面表示要求の送信元である利用者端末１０を使用するサービス利用者ＵＡは、「ユーザ」の一例である。返済状況情報は、後払い方式の支払方法である「あと払い」または「クレジット払い」を選択して、サービス利用者ＵＡにより行われたコード決済の利用代金に該当する後払い利用代金の返済が完了しているか否かを示す情報である。返済状況情報には、画面表示要求に含まれているユーザＩＤ、すなわち、サービス利用者ＵＡを一意に特定するためのユーザＩＤ（たとえば、「Ｕ＃００１」）が同封される。

【0040】

クレジットカードサーバ２００は、決済サーバ１００から返済状況情報の取得要求を受信すると、対応する返済状況情報を決済サーバ１００に応答する（ステップＳ０３）。たとえば、クレジットカードサーバ２００は、各サービス利用者に対応する返済状況情報の中から、返済状況情報の取得要求に含まれているユーザＩＤ（たとえば、「Ｕ＃００１」）に紐付く返済状況情報を取得する。そして、クレジットカードサーバ２００は、取得した返済状況情報を決済サーバ１００に送信する。なお、返済状況情報には、たとえば、対象ユーザであるサービス利用者ＵＡの「あと払い」に対応する利用代金が返済済みの状態であるか否かを示す情報や、対象ユーザであるサービス利用者ＵＡの「クレジットカード払い」に対応する利用代金が返済済みの状態であるか否かを示す情報が含まれていてもよい。返済状況情報には、「クレジットカード払い」に関する対象ユーザの現在のステータスを示す情報が含まれていてもよい。ステータスを示す情報には、「カード暫定停止」や、「強制解約」などのステータス情報が含まれていてもよい。なお、クレジットカードサーバ２００は、対象ユーザのステータスが「カード暫定停止」であっても、「強制解約」の状態に至るまでの間、対象ユーザから利用代金の返済を受け付けることができる。

【0041】

決済サーバ１００は、返済状況情報として、対象ユーザが後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、後払い利用代金の返済に関する対象ユーザの現在の状況を特定する状況特定処理を実行する（ステップＳ０４）。たとえば、決済サーバ１００は、返済状況情報に基づいて、サービス利用者ＵＡが「あと払い」の利用可能期間内にあるかを特定したり、サービス利用者ＵＡにより後払い利用代金の返済を約束する所定の手続である入金約束が行われているか否かを特定したりしてもよい。

【0042】

決済サーバ１００は、特定したサービス利用者ＵＡの現在の状況に応じて、決済アプリの画面の表示態様を決定する表示態様決定処理を実行する（ステップＳ０５）。そして、決済サーバ１００は、表示態様決定処理の処理結果を反映した画面情報を利用者端末１０に送信する（ステップＳ０６）。

【0043】

利用者端末１０は、決済サーバ１００から受信した画面情報に基づいて、決済アプリの画面を表示する。たとえば、図１に、利用者端末１０における画面表示例を示す。図１に示す表示例ＥＸ１は、表示態様の変更が行われていない場合の決済アプリの通常（既定）のトップ画面Ｇ１の一例を示している。図１に示す表示例ＥＸ２は、表示態様の変更が行われている場合の決済アプリのトップ画面Ｇ１の一例を示している。図１に示すように、利用者端末１０に表示される決済アプリのトップ画面Ｇ１は、サービス利用者ＵＡの状況に応じて、決済サーバ１００により、決済アプリのトップ画面Ｇ１の表示態様が決定される。たとえば、表示例ＥＸ２に示すトップ画面Ｇ１の背景色が、表示例ＥＸ１に示す通常のトップ画面Ｇ１の背景色とは異なる色に変更される。また、表示例ＥＸ２に示すように、トップ画面Ｇ１の背景色を変更する例には特に限定される必要はなく、たとえば、トップ画面Ｇ１に設けられた「あと払い」に対応するアイコンの表示色やデザインなどを変更してもよい。

【0044】

決済サーバ１００は、後払い利用代金の返済に関する対象ユーザの現在の状況をいずれかに分類するための分類パターンと、分類パターンに対応する表示態様とをそれぞれ設定しておいてもよい。そして、決済サーバ１００は、分類パターンと、分類パターンに対応する表示態様とに基づいて、決済アプリの画面（たとえば、トップ画面Ｇ１）の表示態様を決定してもよい。

【0045】

たとえば、決済サーバ１００は、対象ユーザの現在の状況が「あと払い」または「クレジットカード払い」を利用可能な期間として予め定められる利用可能期間にあり、かつ対象ユーザにより後払い利用代金の返済を約束する所定の手続が行われていないという状況に分類される場合、分類される状況に対応付けて予め設定される第１の表示態様に決済アプリの画面の表示態様を決定してもよい。

【0046】

また、たとえば、決済サーバ１００は、対象ユーザの現在の状況が「あと払い」または「クレジットカード払い」を利用可能な期間として予め定められる利用可能期間にあり、かつ対象ユーザにより後払い利用代金の返済を約束する所定の手続を受付済みの状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第２の表示態様に決済サプリの画面の表示態様を決定してもよい。

【0047】

また、たとえば、決済サーバ１００は、対象ユーザの現在の状況が「あと払い」または「クレジットカード払い」の利用可能期間にあり、かつ後払い利用代金の返済を約束する所定の手続に基づく返済が履行されなかったという状況に分類される場合、分類される状況に対応付けて予め設定される第３の表示態様に決済サプリの画面の表示態様を決定してもよい。

【0048】

また、たとえば、決済サーバ１００は、対象ユーザの状況が「あと払い」または「クレジットカード払い」の利用可能期間にあり、かつ後払い利用代金の返済を約束する所定の手続に基づいて履行された返済額を確認中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第４の表示態様に決済サプリの画面の表示態様を決定してもよい。

【0049】

また、たとえば、決済サーバ１００は、対象ユーザの状況が「あと払い」または「クレジットカード払い」の利用が停止されている利用停止中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第５の表示態様に決済サプリの画面の表示態様を決定してもよい。

【0050】

また、決済サーバ１００は、決済アプリにおいて支払手段として「あと払い」または「クレジットカード払い」を選択する操作を対象ユーザから受け付けた場合、対象ユーザの現在の状況に応じて、決済アプリの画面の表示態様を決定してもよい。たとえば、図１に示すように、決済サーバ１００は、トップ画面Ｇに設けられているボタンＢＴに対して、「残高払い」を「あと払い」に切り替える操作を検出した場合、上述したように、対象ユーザの後払い利用代金の返済に関する現在の状況に応じて、決済アプリの画面（たとえば、トップ画面Ｇ１）の表示態様を決定してもよい。

【0051】

上述してきたように、実施形態に係る情報処理システムＳＹＳによれば、決済サーバ１００は、対象ユーザについて、後払い方式の支払方法である「あと払い」または「クレジットカード払い」を選択して行われたコード決済の利用代金である後払い利用代金の返済が行われていない場合、対象ユーザの決済アプリのトップ画面Ｇ１の表示態様を通常のトップ画面Ｇ１とは異なる表示態様に変更できる。これにより、実施形態に係る情報処理システムＳＹＳは、後払い利用代金の返済を促して、債権を早期に回収し、後払いタイプのキャッシュレス決済の円滑な運用を図ることができる。

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

図３に示すように、利用者情報記憶部１２１が記憶する利用者情報は、「ユーザＩＤ」の項目や、「即時払い利用履歴」の項目や、「あと払い利用履歴」の項目や、「銀行口座情報」の項目や、「入金予約状況」の項目などといった複数の項目を有している。利用者情報が有するこれらの項目は、相互に対応付けられている。

【0057】

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

【0058】

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

【0059】

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

【0060】

「銀行口座情報」の項目には、「あと払い」を選択して行われたコード決済の利用代金を支払うために引き落とし用口座として予め登録される銀行口座に関する情報が記憶される。「銀行口座情報」の項目に記憶される銀行口座に関する情報は、コード決済の利用代金の後払いの利用登録を行う各サービス利用者により登録される。銀行口座に関する情報には、銀行名や、支店名や、口座名義や、口座番号などの情報が含まれていてもよい。

【0061】

「入金予約状況」の項目には、後払い利用代金の返済を約束する所定の手続である入金約束が行われているか否かを示す情報が記憶される。

【0062】

（表示態様情報記憶部１２２について）
表示態様情報記憶部１２２は、後払い利用代金の返済に関する対象ユーザの現在の状況をいずれかに分類するための分類パターンの情報と、分類パターンに対応付けて予め規定される決済アプリの画面（たとえば、トップ画面Ｇ）の表示態様の内容を示す情報とを対応付けて記憶する。図４は、実施形態に係る表示態様情報記憶部１２２に記憶される表示態様情報の一例を示す図である。

【0063】

図４に示すように、表示態様情報記憶部１２２が記憶する表示態様情報は、「分類パターン」の項目や、「表示態様」の項目といった複数の項目を有している。表示態様情報が有するこれらの項目は、相互に対応付けられている。

【0064】

「分類パターン」の項目には、後払い利用代金の返済に関する対象ユーザの現在の状況をいずれかに分類するために予め規定された分類パターンを示す情報が記憶される。分類パターンは、たとえば、決済サーバ１００の管理者であるサービス事業者ＵＢ（たとえば、図１参照）により設定される。

【0065】

「表示態様」の項目には、決済アプリの画面（たとえば、トップ画面Ｇ）の表示態様を分類パターンに応じて決定するために予め規定された表示態様の内容を示す情報が記憶される。表示態様の内容は、たとえば、決済サーバ１００の管理者であるサービス事業者ＵＢ（たとえば、図１参照）により設定される。

【0066】

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

【0067】

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

【0068】

（取得部１３１について）
取得部１３１は、電子決済サービスを用いて代金の支払いを行うための決済用アプリの画面表示要求をユーザ（たとえば、図１に示すサービス利用者ＵＡ）から受信した場合、電子決済サービスと連携する他のサービスであって、決済用アプリにおいて支払手段として後払いを選択したユーザに代わり代金を支払うサービスを提供する事業者（たとえば、図１に示すサービス事業者ＵＣ）により運営される他の装置（たとえば、図１に示すクレジットカード００）から、画面表示要求の送信元であるユーザに対応する後払い利用代金の返済状況を示す返済状況情報を取得する。

【0069】

たとえば、取得部１３１は、通信部１１０を通じて、画面表示要求の送信元である対象ユーザに対応する返済状況情報の取得要求をクレジットカードサーバ２００に送信する。そして、取得部１３１は、通信部１１０を通じて、クレジットカードサーバ２００から受信した返済状況情報を取得する。返済状況情報には、あと払いを選択したコード決済の利用代金の請求に関する情報が含まれていてもよい。

【0070】

（特定部１３２について）
特定部１３２は、取得部１３１により、返済状況情報として、ユーザが後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、後払い利用代金の返済に関するユーザの現在の状況を特定する。たとえば、特定部１３２は、返済状況情報に基づいて、ユーザの現在の状況が「あと払い」の利用可能期間にあるかを特定したり、ユーザにより後払い利用代金の返済を約束する所定の手続が行われているか否かを特定したりしてもよい。

【0071】

（決定部１３３について）
決定部１３３は、ユーザが未払いユーザに該当する場合、ユーザにより使用される端末装置（たとえば、図１に示す利用者端末１０）に対して決済用アプリの画面を表示する際、特定部１３２により特定されたユーザの現在の状況に応じて、決済アプリの画面の表示態様を決定する。たとえば、決定部１３３は、返済状況情報に基づいて、後払い利用代金の返済に関する対象ユーザの現在の状況をいずれかに分類する。また、決定部１３３は、分類したユーザの現在の状況に対応する表示態様を、表示態様情報記憶部１２２に記憶されている表示態様情報を参照して決定する。

【0072】

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

【0073】

図５に示すように、取得部１３１は、利用者端末１０から決済アプリの画面表示要求を受信したか否かを判定する（ステップＳ１０１）。

【0074】

取得部１３１は、利用者端末１０から決済アプリの画面表示要求を受信したと判定した場合（ステップＳ１０１；Ｙｅｓ）、画面表示要求の送信元の対象ユーザに対応する後払い方式の利用代金の返済状況情報をクレジットカードサーバ２００から取得する（ステップＳ１０２）。

【0075】

特定部１３２は、取得部１３１により取得された返済状況情報に基づいて、対象ユーザが後払い方式の利用代金の返済が完了していない未払いユーザに該当するか否かを判定する（ステップＳ１０３）。たとえば、特定部１３２は、取得部１３１により、返済状況情報として、対象ユーザが利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、未払いユーザに該当すると判定する。

【0076】

また、特定部１３２は、対象ユーザが未払いユーザに該当すると判定した場合（ステップＳ１０３；Ｙｅｓ）、後払い方式の利用代金の返済に関する対象ユーザの現在の状況を特定する（ステップＳ１０４）。

【0077】

決定部１３３は、特定部１３２により特定されたユーザの現在の状況に応じて、決済アプリの画面の表示態様を決定する（ステップＳ１０５）。

【0078】

また、決定部１３３は、決定した決済アプリの画面の表示態様に対応する画面情報を利用者端末１０に送信して（ステップＳ１０６）、図５に示す処理手順を終了する。

【0079】

上述のステップＳ１０３において、特定部１３２は、対象ユーザが未払いユーザに該当しないと判定した場合（ステップＳ１０３；Ｎｏ）、決済アプリの通常の画面情報を利用者端末１０に送信して（ステップＳ１０７）、図５に示す処理手順を終了する。

【0080】

〔４．変形例〕
（４－１．連携サービスについて）
上述の実施形態では、サービス事業者ＵＢにより提供される電子決済サービスと連携する他のサービスが、サービス事業者ＵＣにより提供されるクレジットカードサービスである場合の情報処理の一例を説明したが、この例には特に限定される必要はない。たとえば、電子決済サービスと連携する他のサービスが、クレジットカードサービス以外のサービスであってもよい。たとえば、他のサービスが電子請求書の発行サービスである場合を例にあげると、電子請求書の発行サービスを運営する他のサービス事業者のサーバ装置が、電子決済サービスを運営するサービス事業者ＵＢの代わりに、サービス利用者ＵＡを含む各サービス利用者に対する電子請求書の発行、及び各サービス利用者に紐付く銀行口座から利用代金の引落しを代行すると仮定する。そして、サーバ装置は、各サービス利用者に発行した電子請求書に対応する請求金額の引落しが残高不足などにより失敗した場合、決済サーバ１００に対して、その旨を記述した返済状況情報を送信する。

【0081】

また、決済サーバ１００は、サービス利用者ＵＡにより「あと払い」の利用代金の支払方法として、「電子マネー」が選択されている場合、利用代金に相当する額の電子マネーをサービス事業者ＵＣが電子決済サービスにおいて保有する電子マネー口座（電子マネーの残高が管理される口座）へ移行させることにより、利用代金の精算を実行する。この場合、決済サーバ１００は、サービス利用者ＵＡの「あと払い」の返済状況を管理でき、必要に応じて取得して利用できる。たとえば、対象ユーザが「あと払い」の利用代金の支払方法として、「電子マネー」を選択している場合、決済サーバ１００は、後払い方式の利用代金の返済状況情報について、クレジットカードサーバ２００から取得せずに決済サーバ１００内で保持している返済状況を取得して、対象ユーザが後払い方式の利用代金の返済が完了していない未払いユーザに該当するか否かを判定してもよい。

【0082】

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

【0083】

上述のように、情報処理システムＳＹＳが、決済サーバ１００の制御部１３０が備える処理機能と、クレジットカードサーバ２００が備える処理機能とを統合した情報処理装置を含んで構成される場合、電子決済サービスを運営するサービス事業者ＵＢと、クレジットカードサービスを運営するサービス事業者ＵＣとが同一の事業者であってもよい。また、クレジットカードサービスを利用するためのクレジットカードに、利用代金を後払いするクレジットカード払いの他、サービス利用者の口座残高から即時引き落としが行われるデビットカード決済や、サービス利用者が各種サービス利用により獲得するポイントで支払いが行われるポイント決済などの複数の決済手段が付帯されている場合、電子決済サービスにより提供される決済手段と、クレジットカードサービスにより提供される決済手段とを柔軟に切り替えて表示可能な状態に決済アプリを構成してもよい。

【0084】

また、決済サーバ１００の処理機能とクレジットカードサーバ２００の処理機能とを統合した情報処理装置は、各種決済手段を用いて実行された利用代金の返済状況などの決済に関する情報を一元管理できる。すなわち、決済サーバ１００は、クレジットカードサーバ２００から、アプリ画面の表示要求の送信元であるサービス利用者の返済状況を示す取得する必要がない。また、この情報処理装置は、決済サーバ１００の制御部１３０が備える決定部１３２の処理機能により、電子決済サービスにより提供されるコード決済のうち「あと払い」を選択して行われたコード決済には特に限られず、クレジットカードサービスにより提供される決済手段についても、対応する決済手段の返済状況に応じて、対応する決済手段のアプリ画面を表示する際、アプリ画面の表示態様を決定してもよい。すなわち、決定部１３２は、クレジットカード払いに対応するアプリ画面の表示要求を受信した場合、表示要求の送信元である対象ユーザについて、クレジットカードサービスのクレジットカード払いを選択して行われた利用代金の返済状況を参照し、対象ユーザが未払いユーザに該当する場合、対象ユーザの現在の状況に応じて、クレジットカード払いに対応するアプリ画面を表示する際の表示態様を決定してもよい。

【0085】

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

【0086】

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

【0087】

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

【0088】

〔５．効果〕
上述してきたように、実施形態に係る情報処理システムＳＹＳが有する決済サーバ１００は、所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する。決済サーバ１００は、取得部１３１と、特定部１３２と、決定部１３３とを有する。取得部１３１は、コード決済により代金の支払いを行うための決済用アプリケーションの画面表示要求をユーザから受信した場合、電子決済サービスと連携する他のサービスであって、電子決済サービスを通じて後払い方式の支払方法を電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、画面表示要求の送信元であるユーザに対応する後払い利用代金の返済状況を示す情報を取得する。特定部１３２は、取得部１３１により、返済状況を示す情報として、ユーザが後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、後払い利用代金の返済に関するユーザの現在の状況を特定する。決定部１３３は、ユーザにより使用される端末装置に対して決済用アプリケーションの画面を表示する際、特定部１３２により特定されたユーザの現在の状況に応じて画面の表示態様を決定する。

【0089】

このようにして、実施形態に係る決済サーバ１００は、後払い方式の支払方法の利用代金の返済が完了していない対象ユーザの決済アプリのトップ画面の表示態様を通常のトップ画面とは異なる表示態様に変更できる。これにより、実施形態に係る情報処理システムＳＹＳは、後払い利用代金の返済を促して、債権を早期に回収し、後払いタイプのキャッシュレス決済の円滑な運用を図ることができる。

【0090】

また、決定部１３３は、ユーザの現在の状況が後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつユーザにより後払い利用代金の返済を約束する所定の手続が行われていないという状況に分類される場合、分類される状況に対応付けて予め設定される第１の表示態様に前記画面の表示態様を決定してもよい。

【0091】

また、決定部１３３は、ユーザの現在の状況が後払い方式の支払方法を利用可能な期間として予め定められる利用可能期間にあり、かつユーザにより後払い利用代金の返済を約束する所定の手続を受付済みの状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第２の表示態様に画面の表示態様を決定してもよい。

【0092】

また、決定部１３３は、ユーザの現在の状況が利用可能期間にあり、かつ所定の手続に基づく返済が履行されなかったという状況に分類される場合、分類される状況に対応付けて予め設定される第３の表示態様に画面の表示態様を決定してもよい。

【0093】

また、決定部１３３は、ユーザの現在の状況が利用可能期間にあり、かつ所定の手続に基づいて履行された返済額を確認中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第４の表示態様に画面の表示態様を決定してもよい。

【0094】

また、決定部１３３は、ユーザの現在の状況が後払いの利用が停止されている利用停止中の状態であるという状況に分類される場合、分類される状況に対応付けて予め設定される第５の表示態様に画面の表示態様を決定してもよい。

【0095】

このように、決済サーバ１００は、上述した各部により実行される処理、又は各部により実行される処理のうちのいずれかの組合せにより、後払い方式の支払方法の利用代金の返済が完了していない対象ユーザの現在の状況に応じて異なる表示態様で、たとえば、決済アプリのトップ画面を表示できる。

【0096】

また、決定部１３３は、決済用アプリケーションにおいて支払方法として後払い方式の支払方法を選択する操作を対象ユーザから受け付けた場合、ユーザの現在の状況に応じて、画面の表示態様を決定してもよい。これにより、決済サーバ１００は、たとえば、「あと払い」を利用しようとするタイミングで決済アプリの画面の表示態様を変更し、後払い利用代金の返済を促すことができる。

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【符号の説明】

【0108】

ＳＹＳ 情報処理システム
１０ 利用者端末
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 利用者情報記憶部
１２２ 表示態様情報記憶部
１３０ 制御部
１３１ 取得部
１３２ 特定部
１３３ 決定部
２００ クレジットカードサーバ

【要約】

【課題】後払いタイプのキャッシュレス決済の円滑な運用を図ること。
【解決手段】本願に係る情報処理装置は、取得部と、特定部と、決定部とを有する。取得部１３１は、決済用アプリケーションの画面表示要求をユーザから受信した場合、電子決済サービスと連携する他のサービスであって、電子決済サービスを通じて後払い方式の支払方法を電子決済サービスのユーザに提供する決済サービスを運営する事業者が管理する他の装置から、画面表示要求の送信元であるユーザに対応する後払い利用代金の返済状況を示す情報を取得する。特定部は、取得部により、返済状況を示す情報として、ユーザが後払い利用代金の返済が完了していない未払いユーザに該当する旨の情報が取得された場合、後払い利用代金の返済に関するユーザの現在の状況を特定する。決定部は、特定部により特定されたユーザの現在の状況に応じて、決済用アプリケーションの画面の表示態様を決定する。
【選択図】図２

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】