JP7499919B1 - 情報処理システム、及び情報処理方法 - 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）に投稿したりすることで、送金先のユーザが利用する端末装置にリンク情報を提供する。そして、送金先のユーザがリンク情報を選択して受け取り操作を行った場合、決済サーバ１００は、サービス利用者ＵＡの口座から、送金先のユーザの口座へと、送金金額が示す額の電子マネーを移行させる。

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

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

クレジットカードサーバ２００は、クレジットカードサービス（「第１決済サービス」の一例）、及びクレジットカードサービスと連携する電子決済サービス（「第２決済サービス」の一例）を利用するユーザの中から、「あと払い」または「クレジットカード払い」を用いて実施されたコード決済の利用代金である後払い利用代金が未払いの状態である対象ユーザを特定する（ステップＳ０１）。たとえば、クレジットカードサーバ２００は、サービス事業者ＵＣの全ての顧客について管理されている後払い利用代金の返済状況のうち、電子決済サービスのサービス利用者にも該当する顧客の返済状況を参照し、後払い利用代金が未払いの状態である対象ユーザを特定する。

また、クレジットカードサーバ２００は、決済サーバ１００（「第２決済サービスを提供する第２事業者が運営する他の装置」の一例）に対して、特定した対象ユーザに対し、後払い利用代金の返済が完了していない旨の通知を行うことを要求する通知要求を送信する（ステップＳ０２）。たとえば、クレジットカードサーバ２００は、対象ユーザとして特定したサービス利用者ＵＡに対し、後払い利用代金の返済が完了していない旨の通知を行うことを要求する通知要求を決済サーバ１００に送信する。

なお、クレジットカードサーバ２００は、通知要求を送信する代わりに、サービス事業者ＵＢから提供されるＡＰＩ（Application Programming Interface）を用いて、決済サーバ１００が対象ユーザを管理する管理ファイルにアクセスし、管理ファイルに対象ユーザを特定するための識別情報を登録してもよい。たとえば、クレジットカードサーバ２００は、電子決済サービスにおいて各サービス利用者に対して個別に割り振られているユーザＩＤを、対象ユーザを識別するための識別情報として管理ファイルに書き込むことにより、登録してもよい。

決済サーバ１００は、クレジットカードサーバ２００から、後払い利用代金の返済が完了していない旨の通知を行うことを要求する通知要求を受け付けると（ステップＳ０３）、対象ユーザであるサービス利用者ＵＡに対し、決済用アプリを介して、所定のメッセージ情報（たとえば、図１に示すメッセージ情報Ｍ－１）を送信することにより（ステップＳ０４）、後払い利用代金の返済が完了していない旨の通知を実行する。

たとえば、決済サーバ１００は、決済アプリを介したプッシュ通知により、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報を対象ユーザであるサービス利用者ＵＡが使用する利用者端末１０（「端末装置」の一例）に送信してもよい。

利用者端末１０は、決済サーバ１００からメッセージ情報Ｍ－１を受信すると、受信したメッセージ情報Ｍ－１を、サービス利用者ＵＡにより決済アプリが起動されたタイミングで決済アプリのトップ画面Ｇ１に表示する。図１に示す表示例ＥＸ－１は、決済アプリのトップ画面Ｇ１に表示されるメッセージ情報Ｍ－１の一例を示す。図１に示すメッセージ情報Ｍ－１には、後払い利用代金の返済が完了していない旨のメッセージとともに、後払い利用代金である請求金額や、支払方法として返済先の銀行口座を示す情報が表示される。また、図１に示すメッセージ情報Ｍ－１には、メッセージ情報Ｍ－１から、後払い利用代金の支払手続に直接移行するための操作を受け付けるボタンＢＴ－１や、メッセージ情報Ｍ－１を非表示にする操作を受け付けるためのボタンＢＴ－２が設けられている。また、利用者端末１０は、決済アプリ上（たとえば、トップ画面Ｇ１）において、コード決済の利用代金の支払方法が、「残高払い」から、「あと払い」や「クレジットカード払い」などの後払い方式の支払方法への切り替えが行われた場合、後払い利用代金の返済が完了していない旨のメッセージなどを含むメッセージ情報Ｍ－１を表示してもよい。

また、たとえば、決済サーバ１００は、決済アプリを用いた支払が完了する都度、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報をサービス利用者ＵＡが使用する利用者端末１０に送信してもよい。また、たとえば、決済サーバ１００は、決済アプリを用いて、「あと払い」や「クレジットカード払い」などの後払い方式の支払方法により決済を完了した場合にのみ、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報をサービス利用者ＵＡが使用する利用者端末１０に送信してもよい。図２は、実施形態に係る支払完了画面におけるメッセージ情報の表示例を示す図である。図２に示す表示例ＥＸ－２は、利用者端末１０の支払完了画面Ｇ２に表示されるメッセージ情報Ｍ－２の一例を示す。

決済サーバ１００は、利用者端末１０から受信した取引情報に応じて決済処理を実行し、決済処理が正常に完了すると、支払完了画面の情報とともに、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報Ｍ－２を利用者端末１０に送信する。利用者端末１０は、決済サーバ１００から支払完了画面の情報とともに、メッセージ情報Ｍ－２を受信すると、たとえば、図２に示すように、受信したメッセージ情報Ｍ－２を、決済アプリの支払完了画面Ｇ２に表示する。図２に示すメッセージ情報Ｍ－２には、後払い利用代金の返済が完了していない旨のメッセージが表示される。また、図２に示すメッセージ情報Ｍ－２には、返済が完了していない後払い利用代金に関する利用明細を表示させる操作を受け付けるためのボタンＢＴ－３や、メッセージ情報Ｍ－１から、後払い利用代金の支払手続に直接移行するための操作を受け付けるボタンＢＴ－４が設けられている。なお、ボタンＢＴ－４には、図１に示すボタンＢＴ－１と同一の機能が割り当てられていてもよい。なお、図２は、メッセージ情報Ｍ－２の表示態様の一例であり、図２に示す例には特に限定される必要はない。

また、たとえば、決済サーバ１００は、通知に対応するメッセージ情報の開封状況に基づいて、反復して、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報の送信タイミングを変更してもよい。具体的には、決済サーバ１００は、メッセージ情報が開封されていない場合、メッセージ情報が開封された場合よりも短い周期で前記メッセージ情報を送信できる。図３は、実施形態に係るメッセージ情報の送信タイミングの一例を示す図である。図３に示す表示例ＥＸ－３は、利用者端末１０のホーム画面Ｇ３にプッシュ通知で表示されるメッセージ情報Ｍ－３の一例を示す。

決済サーバ１００は、後払い利用代金の返済が完了していない旨の通知を実行するためのメッセージ情報Ｍ－３をサービス利用者ＵＡに送信した後、メッセージ情報Ｍ－３の開封状況を収集する。そして、決済サーバ１００は、サービス利用者ＵＡによりメッセージ情報Ｍ－３が開封されている場合、たとえば、図３に示すように、前回、メッセージ情報Ｍ－３を送信した日の３日後に、決済アプリを介したプッシュ通知によりメッセージ情報Ｍ－３を改めて送信する。一方、決済サーバ１００は、サービス利用者ＵＡによりメッセージ情報Ｍ－３が開封されていない場合、たとえば、図３に示すように、前回、メッセージ情報Ｍ－３を送信した日の翌日に、改めてメッセージ情報Ｍ－３を送信する。なお、図３は、メッセージ情報Ｍ－３の送信タイミングの一例であり、図３に示す送信タイミングに特に限定される必要はなく、メッセージ情報Ｍ－３の送信を通じて、後払い利用代金の返済を促すという目的の達成を図ることが可能な任意の送信タイミングを採用できる。また、決済サーバ１００は、メッセージ情報Ｍ－３の送信タイミングを変更する場合に限られず、メッセージ情報Ｍ－３の送信頻度を変更してもよい。たとえば、メッセージ情報Ｍ－３が開封されていない場合、１日あたりに複数回、任意のタイミングでメッセージ情報Ｍ－３を送信してもよい。

上述してきたように、実施形態に係る情報処理システムＳＹＳによれば、決済サーバ１００は、後払い方式の支払方法である「あと払い」または「クレジットカード払い」を選択して行われたコード決済の利用代金である後払い利用代金が未払いの状態であること、すなわち後払い利用代金の返済が完了していないことを対象ユーザに認識させることができる。これにより、実施形態に係る情報処理システムＳＹＳは、後払い利用代金の返済を促して、債権を早期に回収し、後払いタイプのキャッシュレス決済の円滑な運用を図ることができる。

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

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

1. 所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置と、前記電子決済サービスのユーザが使用する端末装置とを含む情報処理システムであって、
   前記情報処理装置は、
   前記電子決済サービスと連携する他のサービスであって、前記電子決済サービスを通じて後払い方式の支払方法を前記ユーザに提供するサービスを運営する事業者が管理する他の装置から、後払い利用代金が未払いの状態である対象ユーザに対して、前記後払い利用代金の返済が完了していない旨の通知を行うことを要求する通知要求を受け付ける受付部と、
   前記受付部により前記通知要求が受け付けられた場合、前記コード決済を利用するために前記ユーザに提供される決済用アプリケーションを介して、前記通知を実行する通知部と
   を有し、
   前記端末装置は、
   前記ユーザに提供される決済用アプリケーションにおいて、前記ユーザにより、前記コード決済の利用代金の支払方法が、前記電子決済サービスにおいて前記ユーザが保有するマネー残高により支払いを行う残高払いから、前記後払い方式の支払方法への変更が行われることを契機として、前記情報処理装置から受信済みのメッセージ情報であって、前記後払い利用代金の返済が完了していない旨のメッセージを含む前記メッセージ情報を表示させる
   ことを特徴とする情報処理システム。
2. 前記通知部は、
   前記決済用アプリケーションを介したプッシュ通知により、メッセージ情報を前記対象ユーザが使用する端末装置に送信することによって、前記通知を実行する
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記通知部は、
   前記決済用アプリケーションを用いた支払が完了する都度、メッセージ情報を前記対象ユーザが使用する端末装置に送信することにより、前記通知を実行する
   ことを特徴とする請求項１に記載の情報処理システム。
4. 前記通知部は、
   前記通知に対応するメッセージ情報の開封状況に基づいて、前記通知を反復する際の前記メッセージ情報の送信タイミングを変更する
   ことを特徴とする請求項１に記載の情報処理システム。
5. 前記通知部は、
   前記メッセージ情報が開封されていない場合、前記メッセージ情報が開封されている場合よりも短い周期で前記メッセージ情報を送信する
   ことを特徴とする請求項４に記載の情報処理システム。
6. 前記受付部は、
   前記対象ユーザに対して前記通知を行うために、前記通知部により前記対象ユーザが使用する端末装置に送信されるメッセージ情報を通じて、前記後払い利用代金の支払手続に直接移行するための操作を前記対象ユーザから受け付ける
   ことを特徴とする請求項１に記載の情報処理システム。
7. 所定のコード情報を用いたコード決済を用いる場合、取引対象の代金の支払方法として後払い方式の支払方法を選択可能な電子決済サービスに関する処理を実行する情報処理装置と、前記電子決済サービスのユーザが使用する端末装置とを含む情報処理システムにより行われる情報処理方法であって、
   前記情報処理装置が、
   前記電子決済サービスと連携する他のサービスであって、前記電子決済サービスを通じて後払い方式の支払方法を前記ユーザに提供するサービスを運営する事業者が管理する他の装置から、後払い利用代金が未払いの状態である対象ユーザに対して、前記後払い利用代金の返済が完了していない旨の通知を行うことを要求する通知要求を受け付ける受付工程と、
   前記受付工程により前記通知要求が受け付けられた場合、前記コード決済を利用するために前記ユーザに提供される決済用アプリケーションを介して、前記通知を実行する通知工程と
   を含み、
   前記端末装置が、
   前記ユーザに提供される決済用アプリケーションにおいて、前記ユーザにより、前記コード決済の利用代金の支払方法が、前記電子決済サービスにおいて前記ユーザが保有するマネー残高により支払いを行う残高払いから、前記後払い方式の支払方法への変更が行われることを契機として、前記情報処理装置から受信済みのメッセージ情報であって、前記後払い利用代金の返済が完了していない旨のメッセージを含む前記メッセージ情報を表示させる
   ことを特徴とする情報処理方法。

Images