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

Abstract

【課題】取引対象を提供する事業者による決済処理の手間の軽減を図ること。【解決手段】本願に係る情報処理装置は、情報処理装置は、記憶部と、決済処理部とを有する。記憶部は、事業者が提供するサービスを利用する利用者が事業者に対して定期的に利用代金を支払うための請求情報であって、事業者を特定するための事業者識別情報と、電子決済サービスにおけるユーザアカウントの情報と、代金の支払額を示す支払額情報と、代金の支払日を示す支払日情報と、定期的な支払周期を示す支払周期情報とを含む請求情報を記憶する。決済処理部は、支払周期と前記支払日情報に基づいて、前記ユーザアカウントから前記支払額に相当する電子マネーを引き出して前記事業者の売上情報として管理し、所定のタイミングで売上に相当する額の現金を前記事業者が保有する銀行口座に振り込む決済処理を実行する。【選択図】図３

Description

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

従来、クレジットカード決済やキャリア決済、ＱＲコード（登録商標）決済などの電子決済サービスの利用拡大に伴い、電子決済サービスに関する様々な技術が提案されている。たとえば、特許文献１には、複数の加盟店に対し、クレジットカード会社毎の取り扱いの違いに柔軟に対応した洗替を実施することを目的とした技術が提案されている。

また、商品やサービスといった取引対象に対する代金の支払いにも電子決済サービスが利用されており、取引対象を提供する事業者は、ユーザにより選択された決済方法を用いて、所定の決済日に定期的な決済処理を実施している。

特開２０１９－２２０２３５号公報

しかしながら、従来の技術は、取引対象を提供する事業者による決済処理の手間を軽減する上で改善の余地が残されている。たとえば、従来の技術では、事業者は、所定の決済日が到来する都度、ユーザにより選択された決済方法に対応する決済処理を実施する必要がある。

本願は、上記に鑑みてなされたものであって、取引対象を提供する事業者による決済処理の手間の軽減を図ることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、電子決済サービスのプラットフォームを利用する事業者からの要求に応じて、電子マネーの残高による代金の支払に関する決済処理を代行する。情報処理装置は、記憶部と、決済処理部とを有する。記憶部は、事業者が提供するサービスを利用する利用者が事業者に対して定期的に利用代金を支払うための請求情報であって、事業者を特定するための事業者識別情報と、電子決済サービスにおけるユーザアカウントの情報と、代金の支払額を示す支払額情報と、代金の支払日を示す支払日情報と、定期的な支払周期を示す支払周期情報とを含む請求情報を記憶する。決済処理部は、支払周期と支払日情報に基づいて、ユーザアカウントから支払額に相当する電子マネーを引き出して事業者の売上情報として管理し、所定のタイミングで売上に相当する額の現金を事業者が保有する銀行口座に振り込む決済処理を実行する。

実施形態の一態様によれば、取引対象を提供する事業者による決済処理の手間の軽減を図ることができるという効果を奏する。

図１は、実施形態に係る情報処理の概要を示す図である。 図２は、実施形態に係る決済処理の概要を示す図である。 図３は、実施形態に係る決済サーバの構成例を示す図である。 図４は、実施形態に係る事業者情報記憶部に記憶される事業者情報の一例を示す図である。 図５は、実施形態に係る請求情報記憶部に記憶される請求情報の一例を示す図である。 図６は、実施形態に係る残高情報記憶部に記憶される残高情報の一例を示す図である。 図７は、実施形態に係る利用者情報記憶部に記憶される利用者情報の一例を示す図である。 図８は、実施形態に係る請求情報登録処理の手順の一例を示すフローチャートである。 図９は、実施形態に係る決済処理の手順の一例を示すフローチャートである。 図１０は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．実施形態〕
（１－１．システム構成）
以下、実施形態に係る情報処理について説明する。図１に、実施形態に係る情報処理の概要を示す。なお、以下では、本願に係る情報処理装置の一例である決済サーバ１００によって、実施形態に係る情報処理が実現される例を説明する。まず、図１を用いて、実施形態に係る情報処理システムの構成について説明する。

図１に示すように、実施形態に係る情報処理システムＳＹＳは、事業者端末１０と、ユーザ端末２０と、決済サーバ１００とを含む。事業者端末１０、ユーザ端末２０、及び決済サーバ１００は、ネットワークＮ（たとえば、図３参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、たとえば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した情報処理システムＳＹＳには、複数の事業者端末１０や、複数のユーザ端末２０が含まれていてもよい。

図１に示す事業者端末１０は、商品やサービスといった取引対象をユーザ（たとえば、図１に示すユーザＵ２）に提供する事業を営む事業者Ｕ１により使用される情報処理端末である。

事業者Ｕ１は、ユーザに対する取引対象を提供する事業を営み、取引対象の提供の対価として、取引対象の代金を定期的に請求する。すなわち、事業者Ｕ１は、ユーザとの間で予め取り交わされた代金の支払方法により、予め決められている所定の期日に代金の請求を行う。たとえば、事業者Ｕ１が営む事業は、通信サービスをユーザに提供する通信事業や、商品やサービスを一定期間利用する権利をユーザに提供するサービス業や、ＥＣ（Electronic Commerce）サイトを通じて商品などを販売する小売業であってもよい。

また、事業者Ｕ１は、決済サーバ１００を通じて提供される電子決済サービスのプラットフォームを利用する。すなわち、事業者Ｕ１により運営される店舗は、決済サーバ１００を通じて提供される電子決済サービスの加盟店である。事業者Ｕ１は、ユーザが選択可能な代金の支払方法の１つとして、電子決済サービスを用いた決済方法を提示できる。決済サーバ１００を通じて提供される電子決済サービスによる決済方法は、たとえば、２次元コードなどの所定のコード情報を用いて、電子マネーの残高（以下、「マネー残高」と称する。）から、代金を支払う後述のコード決済（キャッシュレス決済、電子決済）を含む。

また、事業者端末１０は、たとえば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、事業者端末１０は、液晶ディスプレイや有機ＥＬ（Electro Luminescent）ディスプレイなどの表示デバイスを備え、決済サーバ１００から送信される各種情報を、ウェブブラウザやアプリケーションにより表示する。また、事業者端末１０が備える表示デバイスはタッチスクリーンディスプレイであってもよい。この場合、事業者端末１０は、事業者Ｕ１から指やスタイラスなどにより、タッチスクリーンディスプレイが有する画面内に表示された画像などのコンテンツに対する各種の操作を事業者Ｕ１から受付けて、各種の操作に応じた処理を実行する。

また、事業者端末１０は、ＬＴＥ（Long Term Evolution）、４Ｇ（第４世代移動通信システム）、５Ｇ（第５世代移動通信システム）などの無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local Area Network）などの近距離無線通信を介してネットワークＮに接続するための通信ユニットを有する。

なお、事業者端末１０は、所定の情報処理を実現する制御情報を決済サーバ１００から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語やＣＳＳ（Cascading Style Sheets）などのスタイルシート言語、Ｊａｖａ（登録商標）などのプログラミング言語、ＨＴＭＬ（HyperText Markup Language）などのマークアップ言語などにより記述される。なお、決済サーバ１００から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

また、事業者端末１０は、ウェブブラウザより電子決済サービスに関する所定のウェブサイトにアクセスし、電子決済サービスに関する各種処理を実現することもできる。たとえば、事業者Ｕ１は、事業者端末１０において起動させたウェブブラウザにより所定のウェブサイトにアクセスして、電子決済サービスに関する各種操作を実行できる。たとえば、事業者Ｕ１は、マネー残高による代金の支払に関する決済処理の代行を依頼するための定期決済リクエストを決済サーバ１００に送信できる。また、事業者Ｕ１は、ユーザにより選択された代金の支払方法を含む請求情報を決済サーバ１００に送信できる。

また、事業者端末１０には、電子決済サービスに関する処理を実行する決済サーバ１００と連携して電子決済サービスに関する各種処理を実現するための事業者用のアプリケーションプログラム（以下、適宜「事業者用アプリ」と称する。）が予めインストールされていてもよい。事業者用アプリは、電子決済サービスに関する各種処理を実行するための機能を含んでいてもよい。この場合、事業者Ｕ１は、事業者端末１０を用いて事業者用アプリを起動し、事業者用アプリを通じて、上述の定期決済リクエストや請求情報を決済サーバ１００に送信できる。

また、事業者端末１０は、サーバ装置や、メインフレームや、ワークステーションなどにより実現されてもよい。事業者端末１０がサーバ装置で実現される場合、単独のサーバにより実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。

図１に示すユーザ端末２０は、上述の電子決済サービスを用いて、商品やサービスなどの取引対象の決済を行うユーザＵ２により使用される情報処理端末である。

また、ユーザＵ２は、事業者Ｕ１から提供される各種サービスを利用する。また、ユーザＵ２は、事業者Ｕ１から提供される商品の定期購入や、事業者Ｕ１から提供される各種サービスの利用登録に際し、代金の支払方法として、決済サーバ１００により提供される電子決済サービスを登録する。代金の支払方法として電子決済サービスが登録された場合、電子決済サービスにおいてユーザＵ２が所有するユーザアカウントに紐づくマネー残高から代金の支払が実行される。ユーザＵ２は、ユーザ端末２０を操作してウェブブラウザを起動し、事業者Ｕ１がユーザ向けに提供する所定のウェブサイトにアクセスして、たとえば、事業者Ｕ１により利用可能な支払方法として提示された複数の支払方法の中から、電子決済サービスを選択できる。

また、ユーザ端末２０は、たとえば、スマートフォンや、タブレット型端末や、ノート型ＰＣや、デスクトップＰＣや、ＰＤＡなどにより実現される。また、ユーザ端末２０は、液晶ディスプレイや有機ＥＬディスプレイなどの表示デバイスを備え、事業者端末１０や決済サーバ１００から送信される各種情報を、ウェブブラウザやアプリケーションにより表示する。また、ユーザ端末２０が備える表示デバイスはタッチスクリーンディスプレイであってもよい。この場合、ユーザ端末２０は、ユーザＵ２から指やスタイラスなどにより、タッチスクリーンディスプレイが有する画面内に表示された画像などのコンテンツに対する各種の操作をユーザＵ２から受付けて、各種の操作に応じた処理を実行する。

また、ユーザ端末２０は、ＬＴＥ、４Ｇ（第４世代移動通信システム）、５Ｇ（第５世代移動通信システム）などの無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local Area Network）などの近距離無線通信を介してネットワークＮに接続するための通信ユニットを有する。

また、ユーザ端末２０には、電子決済サービスに関する処理を実行する決済サーバ１００と連携して電子決済サービスに関する各種処理を実現するためのサービス利用者用のアプリケーションプログラム（以下、適宜「ユーザアプリ」と称する。）が予めインストールされていてもよい。ユーザアプリは、たとえば、電子決済サービスに関する各種処理を実行するための機能を含んでいてもよい。なお、ユーザ端末２０は、ウェブブラウザより所定のウェブサイトにアクセスし、電子決済サービスに関する各種処理を実現することもできる。

図１に示す決済サーバ１００は、実施形態に係る情報処理を実行する情報処理装置であり、典型的にはサーバ装置であるが、メインフレームやワークステーションなどにより実現されてもよい。決済サーバ１００がサーバ装置で実現される場合、単独のサーバにより実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。

また、決済サーバ１００は、事業者Ｕ１が使用する事業者端末１０や、ユーザＵ２が使用するユーザ端末２０に対して制御情報を配信する配信装置として機能してもよい。ここで、制御情報は、たとえば、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語やＣＳＳ（Cascading Style Sheets）などのスタイルシート言語により記述される。なお、決済サーバ１００から配信されるアプリケーションそのものを制御情報とみなしてもよい。

また、決済サーバ１００は、たとえば、事業者端末１０やユーザ端末２０から送信されたＨＴＴＰ（HyperText Transfer Protocol）リクエストに応じて、かかるＨＴＴＰリクエストにおいて要求されたＨＴＭＬ（HyperText Markup Language）ファイルや、画像データや、画像データをウェブページや、ユーザアプリ上に表示させる制御を実行するための制御情報などを含むコンテンツを事業者端末１０やユーザ端末２０に送信する情報処理装置として機能してもよい。なお、この場合の制御情報を含むコンテンツは、たとえば、Ｆｌａｓｈ（登録商標）や、Ｓｉｌｖｅｒｌｉｇｈｔ（登録商標）などのＲＩＡ（Rich Internet Application）用のコンテンツにより実現可能であり、画像表示プログラムとして動作する。

また、決済サーバ１００を管理する管理者は、決済サーバ１００を通じて、上述の電子決済サービスを提供するプラットフォームサービスを運営する。決済サーバ１００は、たとえば、ユーザ端末２０で動作するユーザアプリなどと連携して、電子決済サービスに関する情報処理を実行する。

また、決済サーバ１００は、所定のウェブサイトを通じて、マネー残高による代金の支払に関する決済処理の代行を依頼するための定期決済リクエストを事業者Ｕ１から受け付ける。事業者Ｕ１は、自身が利用する事業者端末１０を用いて所定のウェブサイトにアクセスし、定期決済リクエストを決済サーバ１００に送信する。また、決済サーバ１００は、所定のウェブサイトを通じて、マネー残高による代金の支払に関する請求情報を事業者Ｕ１から受け付ける。事業者Ｕ１は、自身が利用する事業者端末１０を用いて所定のウェブサイトにアクセスし、請求情報を決済サーバ１００に送信する。

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

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

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

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

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

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

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

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

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

また、たとえば、ユーザ端末２０を用いた送金は、送金金額を受け取るためのリンク情報を送金先のユーザであるサービス利用者に提供することにより行われてもよい。具体的な例を挙げると、ユーザ端末２０は、ユーザＵ２から送金金額の入力を受け付けて送金金額を受け取るためのリンク情報を生成し、リンク情報を含む電子メールを送信したり、リンク情報を含む投稿情報をＳＮＳ（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 (7)

1. 電子決済サービスのプラットフォームを利用する事業者からの要求に応じて、電子マネーの残高による代金の支払に関する決済処理を実行する情報処理装置であって、
   前記事業者が提供するサービスを利用する利用者が前記事業者に対して定期的に利用代金を支払うための請求情報であって、前記事業者を特定するための事業者識別情報と、前記電子決済サービスにおけるユーザアカウントの情報と、前記代金の支払額を示す支払額情報と、前記代金の支払日を示す支払日情報と、定期的な支払周期を示す支払周期情報とを含む請求情報を記憶する記憶部と、
   前記支払周期と前記支払日情報に基づいて、前記ユーザアカウントから前記支払額に相当する電子マネーを引き出して前記事業者の売上情報として管理し、所定のタイミングで売上に相当する額の現金を前記事業者が保有する銀行口座に振り込む前記決済処理を実行する決済処理部と
   を有することを特徴とする情報処理装置。
2. 前記決済処理部は、
   前記支払周期と前記支払日情報に該当する支払日に基づいて、前記決済処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記決済処理部は、
   前記記憶部に記憶されている前記請求情報を繰り返し参照し、前記請求情報を参照したタイミングが前記請求情報に含まれている支払日と一致する支払タイミングに該当する請求があると判定した場合、前記決済処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記請求情報の更新要求に応じて、前記記憶部に記憶されている前記請求情報を更新する登録部
   をさらに有することを特徴とする請求項１～３のいずれか１つに記載の情報処理装置。
5. 前記登録部は、
   前記代金の支払先ごとに、前記代金の支払方法の変更要求を前記利用者から個別に受け付けて、前記記憶部に登録する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 電子決済サービスのプラットフォームを利用する事業者からの要求に応じて、電子マネーの残高による代金の支払に関する決済処理を実行する情報処理方法であって、
   前記事業者が提供するサービスを利用する利用者が前記事業者に対して定期的に利用代金を支払うための請求情報であって、前記事業者を特定するための事業者識別情報と、前記電子決済サービスにおけるユーザアカウントの情報と、前記代金の支払額を示す支払額情報と、前記代金の支払日を示す支払日情報と、定期的な支払周期を示す支払周期情報とを含む請求情報を記憶する記憶部に記憶されている前記支払周期と前記支払日情報に基づいて、前記ユーザアカウントから前記支払額に相当する電子マネーを引き出して前記事業者の売上情報として管理し、所定のタイミングで売上に相当する額の現金を前記事業者が保有する銀行口座に振り込む前記決済処理を実行する決済処理工程
   を含むことを特徴とする情報処理方法。
7. 電子決済サービスのプラットフォームを利用する事業者からの要求に応じて、電子マネーの残高による代金の支払に関する決済処理を実行するコンピュータに、
   前記事業者が提供するサービスを利用する利用者が前記事業者に対して定期的に利用代金を支払うための請求情報であって、前記事業者を特定するための事業者識別情報と、前記電子決済サービスにおけるユーザアカウントの情報と、前記代金の支払額を示す支払額情報と、前記代金の支払日を示す支払日情報と、定期的な支払周期を示す支払周期情報とを含む請求情報を記憶する記憶部に記憶されている前記支払周期と前記支払日情報に基づいて、前記ユーザアカウントから前記支払額に相当する電子マネーを引き出して前記事業者の売上情報として管理し、所定のタイミングで売上に相当する額の現金を前記事業者が保有する銀行口座に振り込む前記決済処理を実行する決済処理手順
   を実行させることを特徴とする情報処理プログラム。

Images