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

Abstract

【課題】電子決済サービスの利用拡大を図ること。【解決手段】本願に係る情報処理装置は、管理部と、名義変更部とを有する。管理部は、提携先の金融機関から借り受けた複数の仮想口座を特定するための口座番号と、電子決済サービスのサービス利用者を識別するための利用者識別情報とを対応付けて記憶部に保存することにより管理する。名義変更部は、仮想口座の所定名義をサービス利用者の利用者名義に変更するための名義変更処理を実行する。【選択図】図７

Description

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

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

また、上述の電子決済サービスの１つとして、予め発行されるユーザアカウントに対応付けて電子マネーをチャージして利用しておくことにより、電子決済を可能とするスキームを採用するサービスが存在する。このようなサービスに関連して、仮想口座の番号と、電子マネー端末ＩＤとを対応付けた対応情報を保持し、振込のあった仮想口座の番号に対応する電子マネー端末ＩＤを取得して、取得した電子マネー端末ＩＤと振込金額情報とを電子マネーサーバに送信する技術などが開示されている。

また、昨今、政府では、資金移動業を営む資金移動業者に対し、上述の電子マネーや仮想通貨といったデジタルマネーにより給与の支払いを認める、所謂「給与のデジタル払い」の導入が検討され始めている。「給与のデジタル払い」の導入が開始された場合、デジタルマネーを用いたサービスの利用拡大が期待される。

特開２００９－８０６０５号公報

しかしながら、上記の従来技術では、電子決済サービスの利用拡大を図る上で課題が残されている。

たとえば、「給与のデジタル払い」が導入された場合、電子決済サービスのサービス利用者の中には、デジタルマネーによる給与を受け取ることを希望するサービス利用者が現れることも想定される。しかし、サービス利用者が勤務する企業のポリシーやスキームによっては、電子決済サービスを利用した「給与のデジタル払い」が認められないといった不測の事態が起こり得る。

具体例をあげれば、電子決済サービスを運営する事業者Ｊが銀行から借り受けた仮想口座ＡＣＣをサービス利用者であるユーザＵに割り当てて、仮想口座ＡＣＣへの入金が確認された場合、入金額に応じてユーザＵに対応する電子マネーの残高を加算するスキームを実施しているとする。この場合、ユーザＵは、勤務する企業Ｋに対して仮想口座ＡＣＣを給与の振込先口座として指定することになるが、受取人名義（ユーザＵ）と口座名義（事業者Ｊ）とが異なる。このため、受取人名義と入金先の口座名義とが一致している場合、従業員が指定する振込先口座に対して給与の振込を行うポリシーやスキームを採用する企業の場合、給与の振込が行われない可能性がある。このように、「給与のデジタル払い」が導入されたとしても、事業者Ｊが実施する電子決済サービスのスキームの円滑な運用が期待できず、電子決済サービスの利用も促進されない。

本願は、上記に鑑みてなされたものであって、電子決済サービスの利用拡大を図ることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、管理部と、名義変更部とを有する。管理部は、提携先の金融機関から借り受けた複数の仮想口座を特定するための口座番号と、電子決済サービスのサービス利用者を識別するための利用者識別情報とを対応付けて記憶部に保存することにより管理する。名義変更部は、仮想口座の所定名義をサービス利用者の利用者名義に変更するための名義変更処理を実行する。
を有する

実施形態の一態様によれば、電子決済サービスの利用拡大を図ることができるという効果を奏する。

図１は、実施形態に係る情報処理の概要（その１）の一例を示す図である。 図２は、実施形態に係る情報処理の概要（その２）の一例を示す図である。 図３は、実施形態に係る情報処理の概要（その３）の一例を示す図である。 図４は、実施形態に係る振込入金サービスによる振込入金の通知例を示す図である。 図５は、実施形態に係る名義変更処理の概要を示す図である。 図６は、実施形態に係る振込額調整処理の概要を示す図である。 図７は、実施形態に係る決済サーバの構成例を示す図である。 図８は、実施形態に係る仮想口座情報記憶部に記憶される情報の一例を示す図である。 図９は、実施形態に係る利用者情報記憶部に記憶される情報の一例を示す図である。 図１０は、実施形態に係る口座情報記憶部に記憶される情報の一例を示す図である。 図１１は、実施形態に係る決済サーバにより実行される口座割当処理の処理手順例を示すフローチャートである。 図１２は、実施形態に係る決済サーバにより実行される振込入金の反映処理の処理手順例を示すフローチャートである。 図１３は、実施形態に係る決済サーバにより実行される振込額調整処理の処理手順例を示すフローチャートである。 図１４は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．実施形態〕
図１を用いて、実施形態に係る情報処理装置などにより実現される情報処理について説明する。図１は、実施形態に係る情報処理の概要（その１）の一例を示す図である。なお、図１では、実施形態に係る情報処理装置の一例である決済サーバ１００によって、実施形態に係る情報処理などが実現されるものとする。

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

図１に示す決済サーバ１００は、実施形態に係る情報処理を実行する情報処理装置であり、サーバ装置やクラウドシステムなどにより実現される。たとえば、決済サーバ１００は、利用者端末１０を用いた電子決済に関する電子決済サービス（コード決済による電子マネーのやり取りを制御する所定の取引手段を提供するサービス）をサービス利用者に提供する。決済サーバ１００は、電子決済サービスに関する情報処理を実行する。具体的には、決済サーバ１００は、コード決済を実現するための利用者端末用のアプリケーションプログラム（以下、適宜「ユーザアプリ」と称する。）を、サービス利用者である一般消費者に配布する。決済サーバ１００は、ユーザアプリ専用のインターフェイスを介して、ユーザアプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。ユーザアプリは、決済先、決済元、及び決済額などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（タイムスタンプ）などの情報が含まれていてもよい。

また、決済サーバ１００は、上述のサービスの１つとして、電子決済サービスのプラットフォームを利用した電子マネーによる振込入金サービスを提供する。たとえば、決済サーバ１００は、電子マネーによる給与の振込入金や、給与以外の各種振込入金を受け付けるサービスを提供する。具体的な情報処理の内容については後に詳述する。なお、給与の振込入金や、各種振込入金を受け付けるサービスは、コード決済を実現するためのユーザアプリ内で起動するミニアプリとして構成されてもよいし、このユーザアプリとは独立して用意された固有のアプリケーションプログラムであってもよい。

図１に示す利用者端末１０は、店舗から取引対象の提供を受ける一般消費者であり、決済サーバ１００により提供されるサービスを利用する利用者ＵＸによって利用される情報処理装置である。利用者端末１０は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、利用者端末１０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１では、利用者端末１０としてスマートフォンを例示している。

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

図１に示す銀行サーバ２０は、希望者により開設された銀行口座を管理する銀行（「金融機関」の一例）に属する情報処理装置であり、サーバ装置やクラウドシステムなどにより実現される。たとえば、銀行サーバ２０は、銀行口座の利用履歴として、各カード会社や、各種サービスの提供者による銀行口座からの引き落としに関する情報（引き落とした金額や、引き落とした日時等）や、現在の口座情報（口座残高等）などを、口座名義人に対応付けて管理する。

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

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

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

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

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

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

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

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

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

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

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

（１－３．実施形態の概要について）
（１－３－１．利用申込（その１））
以下、決済サーバ１００が実行する振込入金サービスに関する情報処理の概要を説明する。まず、図１を用いて、振込入金サービスの利用申込に応じた処理の概要（その１）について説明する。図１は、電子マネーによる給与以外の振込入金を希望するサービス利用者による利用申込の概要を示している。

なお、以下の説明では、利用者端末１０を利用者ＵＸと同一視する場合がある。すなわち、以下では、利用者ＵＸを利用者端末１０と読み替えることもできる。

図１に示すように、決済サーバ１００は、提携先の銀行（「金融機関」の一例）に属する銀行サーバ２０に対して、仮想口座の貸し出しを要求する（ステップＳ１１）。仮想口座とは、提携先の銀行において決済サーバ１００を運営する事業者が所有する同一の銀行口座に紐付けられる複数の仮想口座である。なお、この仮想口座は、銀行口座としての機能を有するものではなく、振込先を特定するための固有の番号情報であり、各種振込を受け付けるための専用口座として機能する。銀行サーバ２０は、決済サーバ１００からの要求に応じて、仮想口座の貸出を行う（ステップＳ１２）。なお、決済サーバ１００は、一度に所定のボリュームの仮想口座（たとえば、最大９，９９９，９９９口座などの任意の数）を銀行サーバ２０から借り受け可能である。

利用者ＵＸは、利用者端末１０に表示したユーザアプリのトップ画面（たとえば、画面Ｄ１－１）を通じて、振込入金用の専用口座作成依頼を決済サーバ１００に送信する（ステップＳ１３）。

決済サーバ１００は、利用者端末１０から振込入金用の専用口座作成依頼を受信すると、仮想口座の割当、及び、利用者情報の登録を実行する（ステップＳ１４）。たとえば、決済サーバ１００は、提携先の銀行から予め貸し出された複数の仮想口座のうち未使用である複数の仮想口座から任意に選択した仮想口座を、作成依頼元の利用者ＵＸに対応する専用口座（仮想口座）として任意に割り当てる。そして、決済サーバ１００は、割り当てた専用口座（仮想口座）を特定するための口座情報と、利用者ＵＸに固有の識別情報とを関連付けて登録し、利用者情報として管理する。利用者ＵＸに固有の識別情報として、たとえば、電子決済サービスの利用登録時に決済サーバ１００が利用者ごとに個別に割り振る利用者ＩＤを利用できる。

また、決済サーバ１００は、法令により義務付けられている資金移動業における滞留規制の遵守を目的として、振込入金用の専用口座を振込先（送金先）として入金された金額のうち、所定額を超える額の現金を専用口座に紐付く利用者ＵＸに返金するための返金用の銀行口座の情報を、利用申込の際、利用者ＵＸから取得する。決済サーバ１００は、利用者ＵＸから取得した返金用の銀行口座の情報を、上述の固有情報に関連付けて、利用者情報として登録する。

仮想口座の割当、及び、利用者情報の登録が完了すると、決済サーバ１００は、利用者端末１０に対し、振込入金用の専用口座の情報として利用者ＵＸに割り当てた仮想口座を特定するための口座情報を送信することにより（ステップＳ１５）、利用者ＵＸに口座情報を提供する。

以下、振込入金サービスの利用申込に応じて、利用者端末１０に表示される画面の遷移例を説明する。図１に示す画面Ｄ１－１は、利用者ＵＸの操作に従って、利用者端末１０に表示されるユーザアプリのトップ画面の一例である。図１に示す画面Ｄ１－１には、振込入金の利用申込を行うためのアイコンＯＢ１－１が設けられている。

また、図１に示す画面Ｄ１－２は、利用者ＵＸによるアイコンＯＢ１－１の操作に従って、利用者端末１０に表示される専用口座作成依頼画面の一例である。図１に示す画面Ｄ１－２には、振込入金用の専用口座作成依頼を決済サーバ１００に送信するためのボタンＯＢ１－２が設けられている。ボタンＯＢ１－２は、たとえば、返金用口座の情報の入力と、利用規約および個人情報の取り扱いに対する同意とを条件として、利用者ＵＸからの操作を受付可能な状態となるように構成されていてもよい。

また、図１に示す画面Ｄ１－３は、利用者ＵＸによるボタンＯＢ１－２の操作に従って、利用者端末１０から決済サーバ１００に送信された振込入金用の専用口座作成依頼に応じて、決済サーバ１００から利用者端末１０に送信される応答画面の一例である。図１に示す画面Ｄ１－３には、決済サーバ１００により作成された振込入金用の専用口座に関する情報が表示されている。利用者ＵＸは、この振込入金用の専用口座に関する情報を振込依頼先へ知らせる。振込依頼先は、利用者ＵＸから通知された振込入金用の専用口座を振込先（送金先）として振込入金を行う。決済サーバ１００は、振込入金用の専用口座に対する振込入金があったことを検知すると、振込入金用の専用口座に対応する利用者ＵＸの電子マネー口座に対して、専用口座に対する入金額に相当する電子マネーをチャージする。すなわち、決済サーバ１００は、振込入金用の専用口座に対応する利用者ＵＸのアカウントに紐づくマネー残高に対して入金額を反映させる。

（１－３－２．利用申込（その２））
以下、図２を用いて、振込入金サービスの利用申込に応じた処理の概要（その２）について説明する。図２は、実施形態に係る情報処理の概要（その２）の一例を示す図である。図２は、電子マネーによる給与の振込入金を希望するサービス利用者による利用申込の概要を示している。なお、図２に示すステップＳ２１～ステップＳ２２の処理手順は、図１に示すステップＳ１１～ステップＳ１２の処理手順に対応するので、説明は省略する。

図２に示すように、利用者ＵＸは、利用者端末１０に表示したユーザアプリのトップ画面（たとえば、画面Ｄ２－１）を通じて、給与受取用の専用口座作成依頼を決済サーバ１００に送信する（ステップＳ２３）。

決済サーバ１００は、利用者端末１０から給与受取用の専用口座作成依頼を受信すると、仮想口座の割当、及び、利用者情報の登録を実行する（ステップＳ２４）。たとえば、決済サーバ１００は、提携先の銀行から予め貸し出された複数の仮想口座のうち未使用である複数の仮想口座から任意に選択した仮想口座を、作成依頼元の利用者ＵＸに対応する専用口座（仮想口座）として任意に割り当てる。そして、決済サーバ１００は、割り当てた専用口座（仮想口座）を特定するための口座情報と、利用者ＵＸに固有の識別情報とを関連付けて登録し、利用者情報として管理する。利用者ＵＸに固有の識別情報として、たとえば、電子決済サービスの利用登録時に決済サーバ１００が利用者ごとに個別に割り振る利用者ＩＤを利用できる。

また、決済サーバ１００は、上述の滞留規制の順守および給与を名目とする送金ミスの検出を目的として、利用申込の際、所定の必要事項に関する情報を利用者ＵＸから取得する。所定の必要事項として、勤務先または雇用者や、社員番号や、社内での氏名や、受け取る金額や、返金用銀行口座などが想定される。勤務先や雇用者に関する情報は、給与受取用の振込入金サービスにおける振込元（送金元）の確認などに用いることが想定される。また、社員番号は、振込入金に誤りがあった場合、振込元に本人確認を行うキーとして用いることが想定される。また、社内での氏名は、振込先（送金先）として指定された口座名義人の確認などに用いることが想定される。また、受け取る金額は、事前に所定の金額を超えないように調整するために用いることが想定される。返金用銀行口座は、所定の金額を超える額を振込先（送金先）として用いることが想定される。決済サーバ１００は、利用者ＵＸから取得した所定の情報を、上述の固有情報に関連付けて、利用者情報として登録する。

仮想口座の割当、及び、利用者情報の登録が完了すると、決済サーバ１００は、利用者端末１０に対して、利用者ＵＸに割り当てた仮想口座に関する口座情報を送信することにより（ステップＳ２５）、利用者ＵＸに口座情報を提供する。

以下、電子マネーによる給与受取のための振込入金サービスの利用申込に応じて、利用者端末１０に表示される画面の遷移例を説明する。図２に示す画面Ｄ２－１は、利用者ＵＸの操作に従って、利用者端末１０に表示されるユーザアプリのトップ画面の一例である。図２に示す画面Ｄ２－１には、電子マネーによる給与受取の利用申込を行うためのアイコンＯＢ２－１が設けられている。

また、図２に示す画面Ｄ２－２は、利用者ＵＸによるボタンＯＢ２－２の操作に従って、利用者端末１０に表示される専用口座作成依頼画面の一例である。図２に示す画面Ｄ２－２には、給与受取用の専用口座作成依頼を決済サーバ１００に送信するためのボタンＯＢ２－２が設けられている。ボタンＯＢ２－２は、たとえば、所定の必要事項の入力と、利用規約および個人情報の取り扱いに対する同意とを条件として、利用者ＵＸからの操作を受付可能な状態となるように構成されていてもよい。

また、図２に示す画面Ｄ２－３は、利用者ＵＸによるボタンＯＢ２－２の操作に従って、利用者端末１０から決済サーバ１００に送信された給与受取用の専用口座作成依頼に応じて、決済サーバ１００から利用者端末１０に送信される応答画面の一例である。図２に示す画面Ｄ２－３には、決済サーバ１００により作成された給与受取用の専用口座に関する情報が表示されている。ここで、決済サーバ１００は、給与受取用の専用口座の支店名として、給与受取用であることを示す名称（たとえば、「キュウヨ支店」）を付与する。利用者ＵＸは、この給与受取用の専用口座の情報を振込依頼先へ知らせる。振込依頼先は、利用者ＵＸから通知された給与受取用の専用口座を振込先（送金先）として送金を行う。決済サーバ１００は、振込依頼先から給与受取用の専用口座に対する入金を検知すると、給与受取用の専用口座に対応する利用者ＵＸの電子マネー口座に対して、入金額に相当する電子マネーをチャージする。すなわち、決済サーバ１００は、給与受取用の専用口座に対応する利用者ＵＸのアカウントに紐づくマネー残高に対して入金額を反映させる。

上述したように、決済サーバ１００は、給与以外の振込入金や、給与の振込入金などの利用目的ごとに仮想口座を利用者に割り当てることができる。なお、図１や図２に示す例では、決済サーバ１００は、給与以外の振込入金サービスの利用申込と、給与の振込入金サービスの利用申込とをそれぞれ個別に受け付ける場合の処理の概要を説明したが、この例には特に限定される必要はない。たとえば、決済サーバ１００は、振込入金サービスの利用申込を受け付けた後、利用目的が給与以外の振込入金か、又は、給与の振込入金かをサービス利用者に選択させるようにしてもよい。

また、決済サーバ１００は、給与以外の振込入金サービスの利用申込に応じて、振込入金サービス用の専用口座としてサービス利用者に割り当てる仮想口座は、利用可能な期限が予め設定されている有効期限付きの仮想口座であってもよい。なお、決済サーバ１００は、給与以外の振込入金サービスの利用申込に応じて、サービス利用者に割り当てる仮想口座はワンタイム口座であってもよい。これにより、仮想口座の新陳代謝を促し、仮想口座の有効活用を図ることができる。

また、決済サーバ１００は、サービス利用者に対して利用目的ごとに仮想口座を割り当てる場合、利用目的ごとにマネー残高を管理してもよい。たとえば、決済サーバ１００は、図１に示す給与以外の振込入金サービスによる振込入金に対応するマネー残高と、図２に示す給与受取用の振込入金サービスによる振込入金に対応するマネー残高とをそれぞれ個別に管理できる。

（１－４．振込入金反映処理）
以下、図３を用いて、振込入金サービスによる振込入金の反映処理の概要について説明する。図３は、実施形態に係る情報処理の概要（その３）の一例を示す図である。図３は、サービス利用者である利用者ＵＸおよび利用者ＵＹが給与以外の振込入金サービスの利用申込を行い、利用者ＵＺが給与の振込入金サービスの利用申込を行った場合の情報処理システム１における処理の概要を示している。

図３に示すように、利用者ＵＸは、振込入金サービスを利用する場合、決済サーバ１００から通知された振込入金用の専用口座を示す情報を含む振込先情報を振込依頼先に通知する。たとえば、利用者ＵＸは、銀行名：「ＡＢＣ銀行」や、支店番号：「１２３」や、支店名：「ＤＥＦ」や、口座種別：「普通」や、仮想口座を示す口座番号：「１１１１１２」や、（口座名義人の）氏名：「トッキョケンイチ」を振込依頼先の企業Ａに通知する。

また、利用者ＵＹは、振込入金サービスを利用する場合、決済サーバ１００から通知された振込入金用の専用口座を示す情報を含む振込先情報を振込依頼先に通知する。たとえば、利用者ＵＹは、銀行名：「ＡＢＣ銀行」や、支店番号：「１２３」や、支店名：「ＤＥＦ」や、口座種別：「普通」や、仮想口座を示す口座番号：「１１１１１３」や、（口座名義人の）氏名：「イショウサクラコ」を振込依頼先の企業Ｂに通知する。

また、利用者ＵＺは、振込入金サービスを利用する場合、決済サーバ１００から通知された給与受取用の専用口座を示す情報を含む振込先情報を振込依頼先に通知する。たとえば、利用者ＵＺは、銀行名：「ＡＢＣ銀行」や、支店番号：「１２３」や、支店名：「キュウヨ支店」や、口座種別：「普通」や、仮想口座を示す口座番号：「１１１１１１」や、（口座名義人の）氏名：「ショウヒョウジン」を振込依頼先の雇用者Ｃに通知する。

企業Ａは、利用者ＵＸから振込入金の依頼を受け付けると、利用者ＵＸから通知された振込先情報に基づいて振込入金を行う。たとえば、企業Ａは、自らが銀行口座を所有する仕向銀行から、振込先情報に記された銀行（支店）の口座および口座名義人を送金先として、利用者ＵＸから指定された金額を送金する。図３では、企業Ａは、口座名義人が「トッキョケンイチ」である専用口座番号：「１１１１１２」に対して、現金：「￥３０，０００」の送金を行う例が示されている。

企業Ｂは、利用者ＵＹから振込入金の依頼を受け付けると、利用者ＵＹから通知された振込先情報に基づいて振込入金を行う。たとえば、企業Ｂは、自らが銀行口座を所有する仕向銀行から、振込先情報に記された銀行（支店）の口座および口座名義人を送金先として、利用者ＵＸから指定された金額を送金する。図３では、企業Ｂは、口座名義人が「イショウサクラコ」である専用口座番号：「１１１１１３」に対して、現金：「￥５０，０００」の送金を行う例が示されている。

雇用者Ｃは、利用者ＵＺから給与を受け取るための振込入金の依頼を受け付けると、利用者ＵＺから通知された振込先情報に基づいて振込入金を行う。たとえば、雇用者Ｃは、自らが銀行口座を所有する仕向銀行から、振込先情報に記された銀行（支店）の口座および口座名義人を送金先として、利用者ＵＺの給与を送金する。図３では、雇用者Ｃは、口座名義人が「ショウヒョウジン」である専用口座番号：「１１１１１１」に対して、給与：「￥２５０，０００」の送金を行う例が示されている。

決済サーバ１００は、同一の銀行口座に紐付けられた複数の仮想口座の中から利用者ごとに個別に割り当てられた専用口座（仮想口座）に対する振込入金を検知する検知処理を実行する（ステップＳ３１）。たとえば、決済サーバ１００は、所定のタイミングで複数の専用口座（仮想口座）が紐付けられている銀行口座の残高を確認する。そして、決済サーバ１００は、該当の銀行口座の残高が増えている場合、送金先として指定されている専用口座（仮想口座）を示す専用口座番号を個別に特定する。

また、決済サーバ１００は、振込入金の専用口座番号に対する入金が検知されると、振込内容を確認する処理を実行する（ステップＳ３２）。そして、決済サーバ１００は、振込内容の確認結果に応じた処理を実行する（ステップＳ３３～ステップＳ３５）。

たとえば、決済サーバ１００は、振込入金の送金先である対象利用者（たとえば、利用者ＵＸや利用者ＵＹ、利用者ＵＺなど）に紐付く専用口座（仮想口座）の残高を取得する。そして、決済サーバ１００は、専用口座（仮想口座）に対して振込入金の入金額を反映した後の残高が所定の金額を超えるかどうかを判定する。

決済サーバ１００は、専用口座（仮想口座）の残高が所定の金額を超えていない場合、対象利用者が所有する電子マネーのマネー残高に対して、振込入金の入金額を反映させるチャージ処理を実行する（ステップＳ３３）。一方、決済サーバ１００は、専用口座（仮想口座）の残高が所定の金額を超えている場合、対象利用者に予め紐付けられている銀行口座を送金先として、所定の金額を超える分に相当する額の現金を送金する返金処理を実行する（ステップＳ３４）。

また、決済サーバ１００は、検知した振込入金が給与受取用の入金である場合、対象利用者に対して、振込内容の確認するための確認依頼を送信してもよい（ステップＳ３５）。たとえば、決済サーバ１００は、振込入金の振込元が、対象利用者が予め設定した勤務先や雇用者とは異なっている場合、給与受取用の入金で間違いないか否かの確認通知を利用者端末１０に送信してもよい。この場合、決済サーバ１００は、対象利用者からの確認が取れた場合、マネー残高のチャージなどの処理を実行する。また、決済サーバ１００は、対象利用者の振込入金の履歴を辿り、給与受取用の入金が不規則なタイミングで行われている場合、給与受取用の振込入金で間違いがないかを対象利用者に確認するための確認通知を利用者端末１０に送信してもよい。なお、決済サーバ１００は、対象利用者の振込入金の履歴を辿り、利用目的が給与以外である振込入金が一定のタイミングで継続的に検知された場合、給与受取用の振込入金の間違いではないか否かを対象利用者に問い合わせるための確認通知を利用者端末１０に送信してもよい。これにより、利用目的を誤って、振込入金サービスが利用されることを防止できる。

また、決済サーバ１００は、所定のタイミングで、マネー残高のうち給与の内訳で管理されているマネー残高を示す情報をサービス利用者ごとに取得し、提携先の銀行に通知してもよい。資金移動業者が破綻した場合に、給与として支払われた電子マネーを、提携先の銀行が保証する場合がある。そのようなケースにおいて、提携先の銀行が、給与として利用者に支払われた電子マネーの残高を確認することは、保証が必要な金額を把握することが出来る点で有用である。

また、決済サーバ１００は、給与受取用の振込入金サービスの利用申込の際、振込入金の入金額のうち、電子マネーで受け取る金額の選択を利用者から受付可能としてもよい。この場合、決済サーバ１００は、入金額から電子マネーで受け取る分を差し引いた差額を現金で対象利用者の銀行口座に振り込むように処理できる。

また、決済サーバ１００を運営する事業者は、１回（１ｓｈｏｔ）の入金額が所定の金額を超える場合、振込入金の受付を拒否するように提携先の銀行との間で事前に申合せをしておいてもよい。たとえば、決済サーバ１００は、所定のタイミングで、仮想口座に対する入金の受付を拒否する所定の金額を示す情報を、銀行サーバ２０に送信する。なお、所定の金額は、利用目的（振込入金サービス）ごとに設定されてもよい。

また、決済サーバ１００は、銀行サーバ２０において仮想口座に対する入金の受付が拒否する処理が行われた振込入金に関する情報を銀行サーバ２０から取得してもよい。たとえば、決済サーバ１００は、給与受取用の振込入金サービスにおいて、１回（１ｓｈｏｔ）の入金額が所定の金額を超えている場合、次回も所定の金額を超える蓋然性が高いと判定する。この場合、決済サーバ１００は、振込入金の送金先である仮想口座に紐付く対象利用者に対して、次回も給与受取用の振込入金サービスの利用を継続するか否かの確認通知を送信する。これにより、提携先の銀行において、次回も入金の受付が拒否されてしまうことを回避できる。

（１－５．入金通知例）
以下、図４を用いて、振込入金サービスによる振込入金の通知例について説明する。図４は、実施形態に係る振込入金サービスによる振込入金の通知例を示す図である。図４では、振込入金サービスにより利用者ＵＸに対する入金が行われた場合の入金通知例を示している。

図４に示す画面Ｄ３－１は、利用者ＵＸの操作に従って、利用者端末１０に表示されるユーザアプリのトップ画面の一例である。図４に示す画面Ｄ３－１には、振込入金サービスによる入金があった旨を利用者ＵＸに通知するための通用用のポップアップＯＢ３－１が表示されている。

図４に示す画面Ｄ３－２は、利用者ＵＸによるポップアップＯＢ３－１の操作に従って、利用者端末１０に表示されるお知らせ詳細画面の一例である。図４では、画面Ｄ３－２に、「企業Ａから３０，０００円の入金がありました。」というように、ポップアップＯＢ３－１に対応する詳細情報が表示される例が示されている。これにより、両社ＵＸは、振込入金サービスが正常に機能したことを確認できる。

（１－６．名義変更処理）
以下、図５を用いて、振込入金サービスにおける名義変更処理について説明する。図５は、実施形態に係る名義変更処理の概要を示す図である。上述の振込入金サービスは、以下の点で改善の余地がある。

たとえば、上述の図３に示す例において、利用者ＵＺは、振込入金サービスを利用する場合、決済サーバ１００から通知された給与受取用の専用口座を示す情報を含む振込先情報を振込依頼先（たとえば、雇用者Ｃなど）に通知することになる。一方、上述の振込入金サービスにおいて、決済サーバ１００が銀行サーバ２０から貸し出しを受けた複数の仮想口座の口座名義は、決済サーバ１００を通じて振込入金サービスを提供している事業者ＰＰとなっている。このため、振込依頼先（たとえば、雇用者Ｃ）が、給与の振込を行う際、受取人名義（たとえば、「ショウヒョウジン」）と、振込先となる専用口座の名義（たとえば、事業者ＰＰ）との完全一致により給与の振込を実施するポリシーやスキームを採用する場合、給与の振込が行われない事態が起こる。このような事態は、給与の振込に限らず、その他の振込入金においても同様に起こり得る。このような事態の発生を鑑み、決済サーバ１００は、以下に説明する名義変更処理を実行する。

図５に示すように、たとえば、ユーザＵＸは、利用者端末１０に表示したユーザアプリのトップ画面（たとえば、図１に示す画面Ｄ１－１）を通じて、振込入金用の専用口座作成依頼を決済サーバ１００に送信する（ステップＳ４１）。

決済サーバ１００は、利用者端末１０から振込入金用の専用口座作成依頼を受信すると、作成依頼元の利用者ＵＸのステータス判定を実行する（ステップＳ４２）。具体的には、決済サーバ１００は、利用者ＵＸに固有の識別情報として専用口座作成依頼に含まれる利用者ＩＤに基づいて、利用者ＩＤに対応付けられているステータス情報を参照し、作成依頼元の利用者ＵＸによる本人確認の手続が完了済みであるか否かを判定する。

本人確認の手続は、たとえば、振込入金サービスの利用申込の際のコンプライアンスチェックとして予め実行されてもよいし、任意のタイミングでサービス利用者の要求により実行されてもよい。本人確認の手続は、たとえば、ＫＹＣ（Know Your Customer）や、ｅＫＹＣ（electronic Know Your Customer）などにより行われることが想定される。決済サーバ１００は、本人確認の手続の結果および本人確認の手続に用いられた本人確認情報を、利用者ＩＤに対応付けて管理する。決済サーバ１００は、サービス利用者から所定の書類が本人確認情報として郵送されてきた場合、受領した書類に関する情報を本人確認情報として記憶部に保存して管理する。また、決済サーバ１００は、サービス利用者から本人確認情報がオンラインでアップロードされてきた場合、受信した本人確認情報を記憶部に保存して管理する。本人確認情報には、本人を特定可能な任意の情報を利用でき、運転免許証やパスポート、マイナンバーカードなどの情報の他、サービス利用者が自ら撮影した本人の容貌を示す画像（セルフィー）などが例示される。

決済サーバ１００は、ステータス判定の結果に従って、作成依頼元の利用者ＵＸに対して、振込入金用の専用口座（仮想口座）の割当を実行する（ステップＳ４３）。具体的には、決済サーバ１００は、作成依頼元の利用者ＵＸのステータスが本人確認の手続が完了済みの状態であった場合、提携先の銀行から予め貸し出された複数の仮想口座のうち未使用である複数の仮想口座から任意に選択した仮想口座を、作成依頼元の利用者ＵＸに対応する専用口座（仮想口座）として任意に割り当てる。

また、決済サーバ１００は、利用者ＵＸに割り当てた専用口座（仮想口座）を特定するための口座番号を、利用者ＵＸに対応する利用者ＩＤに対応付けて、利用者情報として記憶部に保存する（ステップＳ４４）。

利用者ＵＸに対して口座を割り当てた後、決済サーバ１００は、利用者ＵＸに割り当てた専用口座（仮想口座）の名義を利用者名義に変更するための名義変更処理を実行する（ステップＳ４５）。具体的には、決済サーバ１００は、名義変更の対象となる仮想口座の口座番号（たとえば、「１１１１１２」）と、変更を希望する変更希望名義（たとえば、「トッキョケンイチ」）とを含む名義変更依頼を銀行サーバ２０に送信する（ステップＳ４５）。なお、名義変更処理は、上述したように、利用者ＵＸに対する専用口座（仮想口座）の割当後の一連の処理として実行されてもよいし、利用者ＵＸからの要求に応じたオンデマンドの処理として実行されてもよい。

また、決済サーバ１００による名義変更処理は、銀行側から提供されるＡＰＩなどの所定のインターフェイスを通じて、銀行が決済サーバ１００に貸し出した仮想口座を管理する管理ファイルにアクセスし、管理ファイルにおいて該当の仮想口座に対応付けられている口座名義の情報を書き換えることにより実行されてもよい。

名義変更処理が完了した後、決済サーバ１００は、口座番号（たとえば、「１１１１１２」）と口座名義（たとえば、「トッキョケンイチ」）とを含む口座情報を利用者端末１０に送信することにより、利用者ＵＸに通知する（ステップＳ４６）。

上述してきたように、決済サーバ１００は、振込入金用の専用口座作成依頼に応じて、作成依頼元のサービス利用者に割り当てた専用口座（仮想口座）の名義変更処理を実行する。このようなことから、電子決済サービスと同一のプラットフォームを通じて提供される振込入金サービスのスキームの円滑な運用を支援し、電子決済サービスの利用拡大を図ることができる。

また、決済サーバ１００は、ステータス判定により、作成依頼元の利用者ＵＸについて本人確認の手続が完了済みであると判定した場合、本人確認の手続に用いられた本人確認情報が有効期限内であることを条件として、作成依頼元の利用者ＵＸに対して、振込入金用の専用口座（仮想口座）の割当を実行してもよい。また、決済サーバ１００は、名義変更処理を実行する際、専用口座（仮想口座）の名義を、本人確認の手続で確認された利用者ＵＸの利用者名義に変更してもよい。

また、決済サーバ１００は、作成依頼元の利用者ＵＸに割り当てる仮想口座に有効期限を設定して、管理してもよい。たとえば、決済サーバ１００は、本人確認情報の有効期限に合わせて、サービス利用者に割り当てる仮想口座の有効期限を利用者ＩＤに対応付けて記憶部に保存して管理する。たとえば、図５に示す場合、決済サーバ１００は、利用者ＵＸに割り当てる専用口座（仮想口座）の有効期限として、本人確認情報の有効期限である「２０２４／１０／０１」を利用者ＩＤに対応付けて記憶部に保存して管理する。

また、決済サーバ１００は、振込入金サービスのサービス利用者から本人確認情報の変更依頼を受け付けてもよい。この場合、決済サーバ１００は、サービス利用者から受け付けた変更依頼に基づいて、利用者ＩＤに対応付けて、変更前の本人確認情報を変更後の本人確認情報に更新して記憶部に保存する。なお、サービス利用者が本人確認情報の変更依頼を行うための機能は、ユーザアプリに搭載されていてもよい。また、決済サーバ１００は、本人確認情報の変更を受け付けた際に、利用者の氏名が変更されている場合（たとえば結婚で姓が変わった場合など）に、合わせて口座名義も変更してもよい。

また、決済サーバ１００は、名義変更処理において、作成依頼元のサービス利用者に割り当てた専用口座（仮想口座）の利用者名義を変更する際、サービス利用者の利用者名を適用してもよいし、名義として利用を希望する任意の文字列を適用してもよい。また、決済サーバ１００は、変更後の利用者名義の文字数に制限を設けてもよい。この場合、決済サーバ１００は、変更依頼に対応する利用者名義が予め設定される上限文字数を超過する場合、利用者名義が文字数以下となるように調整した調整後の利用者名義を用いて名義変更処理を実行する。たとえば、決済サーバ１００は、利用者名義の前方から上限文字数以下となるように利用者名義の文字数を調整できる。また、決済サーバ１００は、本人確認情報の有効期限と仮想口座の有効期限が対応づいて設定されている場合に、本人確認情報の有効期限に近づいた際、例えば有効期限の１か月前になった際に、本人確認期限が迫っている旨と期限を過ぎた場合に仮想口座が使用できなくなる旨のどちらか、または双方を含めた本人確認の更新依頼の通知を利用者の端末に通知してもよい。

（１－７．振込額調整処理）
以下、図６を用いて、振込入金サービスにおける振込額調整処理について説明する。図６は、実施形態に係る振込額調整処理の概要を示す図である。上述の振込入金サービスは、以下の点で改善の余地がある。

上述の振込入金サービスでは、法令により義務付けられている資金移動業における滞留規制の遵守を目的とする処理が実行される。たとえば、決済サーバ１００を運営する事業者は、１回（１ｓｈｏｔ）の入金額が所定の金額を超える場合、振込入金の受付を拒否するように提携先の銀行との間で事前に申合せをしておく。これにより、銀行サーバ２０において、１回の入金額が所定の金額を超える場合、振込入金の受付を水際で拒否する。

あるいは、決済サーバ１００は、１回（１ｓｈｏｔ）の入金額が所定の金額を超えなくても、専用口座（仮想口座）に対する入金額を反映した後のマネー残高が所定の金額を超えるかどうかを判定する。決済サーバ１００は、処理対象となるサービス利用者（以下、「対象利用者」という。）に紐付くマネー残高が所定の金額を超えている場合、対象利用者に予め紐付けられている銀行口座を送金先として、所定の金額を超える分に相当する額の現金を送金する返金処理を実行する。

このように、銀行サーバ２０側と決済サーバ１００側の両方で、入金額を制限するための処理が実行されている。一方、決済サーバ１００が、たとえば、サービス利用者による本人確認の手続が完了済みであることを条件に返金処理を実行するというスキームを採用したと仮定する。このような仮定の元、たとえば、専用口座への入金が受け付けられ、マネー残高が所定の金額を超えている場合、返金先となる対象利用者が本人確認の手続を完了していなければ、返金が行われないという不都合が生じてしまう。そこで、実施形態に係る決済サーバ１００は、以下に説明する振込額調整処理を実行する。

図６に示すように、決済サーバ１００は、口座情報を参照し、処理対象となるサービス利用者のチャージ可能額を算出する（ステップＳ５１）。具体的には、決済サーバ１００は、処理対象となるサービス利用者のユーザアカウントに紐付く現時点でのマネー残高と、該当のサービス利用者に対応するマネー残高の上限との差分に基づいて、該当のサービス利用者のチャージ可能額を算出する。たとえば、図６に示す場合、決済サーバ１００は、処理対象となるサービス利用者の現時点でのマネー残高である１０万円と、該当のサービス利用者に対応するマネー残高の上限である１００万円との差分である９０万円をチャージ可能額として算出する。

なお、決済サーバ１００は、サービス利用者のユーザアカウントに紐付くマネー残高の増減に応じて、所定のタイミングでチャージ可能額を算出してもよい。たとえば、決済サーバ１００は、各サービス利用者のマネー残高を予め定められているタイミング（たとえば、日次）で確認し、マネー残高の増減が認められるサービス利用者を処理対象として特定し、特定した処理対象となるサービス利用者についてチャージ可能額の算出を実行してもよい。あるいは、決済サーバ１００は、処理対象となるサービス対象者を抽出した後、予め定められた所定の時刻に到達したタイミングでチャージ可能額の算出を実行してもよい。また、決済サーバ１００は、サービス利用者のチャージ可能額や、マネー残高のチャージの頻度や、マネー残高の利用の頻度に基づいて、各サービス利用者の次回のチャージ可能額の確認、及び銀行への振込上限額の通知のタイミングを制御してもよい。たとえば、決済サーバ１００は、チャージ可能額や、マネー残高のチャージの頻度や、マネー残高の利用の頻度に応じて、チャージ可能額を算出する周期を調整してもよい。具体的には、決済サーバ１００は、たとえば、チャージ可能額が一定額未満であるサービス利用者については、チャージ可能額が一定額以上であるであるサービス利用者よりも、チャージ可能額の算出タイミングの周期を短くすることにより、実効的な処理を実現できる。また、たとえば、決済サーバ１００は、他のサービス利用者と比較して、マネー残高のチャージの頻度やマネー残高の利用の頻度が相対的に少ないサービス利用者（たとえば、利用の頻度が所定の閾値未満であるサービス利用者）に対しては、マネー残高のチャージの頻度やマネー残高の利用の頻度が相対的に多いサービス利用者（利用の頻度が所定の閾値以上であるサービス利用者）よりも、チャージ可能額の算出タイミングの周期を長くすることにより、効率的な処理を実現できる。なお、周期はチャージ可能額を算出したタイミングで再度、チャージ可能額の大きさや、マネー残高のチャージの頻度や、マネー残高の利用の頻度に応じて、更新してもよい。

続いて、決済サーバ１００は、ステップＳ５１で算出したチャージ可能額を、処理対象となるサービス利用者に割り当てられている仮想口座の振込上限額として銀行サーバ２０に通知する（ステップＳ５２）。具体的には、決済サーバ１００は、利用者情報を参照し、処理対象となるサービス利用者の利用者ＩＤに基づいて、該当のサービス利用者に割り当てられている仮想口座の口座番号を特定する。そして、決済サーバ１００は、特定した仮想口座の口座番号の情報と、振込上限額の情報とを含む通知を銀行サーバ２０に送信する。たとえば、図６に示す場合、決済サーバ１００は、振込上限額である９０万円と、口座番号である「１１１１１２」とを含む通知を銀行サーバ２０に送信する。

また、決済サーバ１００は、振込上限額の通知を銀行サーバ２０に送信する代わりに、銀行から予め提供されるＡＰＩなどの所定のインターフェイスを通じて、銀行サーバ２０が仮想口座ごとに振込上限額を管理する管理ファイルにアクセスし、管理ファイルにおいて該当の仮想口座に対応付けられている振込上限額の情報を書き換えることにより変更してもよい。

また、決済サーバ１００は、処理対象となるサービス利用者が本人確認の手続を完了していない場合、チャージ可能額の算出を実行してもよい。これにより、サービス利用者による本人確認の手続が完了済みであることを条件に返金処理を実行するというスキームを採用する場合であっても、振込上限額を銀行サーバ２０側に受け渡すことで、本確認の手続を完了していないサービス利用者について、銀行サーバ２０の水際で入金規制を実行できる。

また、決済サーバ１００は、処理対象となるサービス利用者が本人確認の手続を完了している場合、該当のサービス利用者について返金処理を実行できる。この場合、決済サーバ１００は、サービス利用者が所有するユーザアカウントに紐付くマネー残高と、ユーザアカウントに紐付けて予め設定される残高上限額とを比較し、マネー残高が残高上限額を超えている場合、マネー残高のうち、残高上限額を超える超過分に相当する金額の払出を実行してもよい。なお、決済サーバ１００は、処理対象となるサービス利用者が本人確認の手続を完了している場合、上述の返金処理を実行できるので、振込調整処理を実行しなくてもよい。

また、決済サーバ１００は、返金処理を実行する際、払出先となるサービス利用者について払出先口座の登録がない場合、サービス利用者に提供される専用のアプリケーションであるユーザアプリを通じて、払出先口座の登録依頼をサービス利用者に通知してもよい。決済サーバ１００は、ユーザアプリを通じたプッシュ通知により払出先口座の登録依頼をサービス利用者に通知できる。また、決済サーバ１００は、ユーザアプリを通じた通知に限られず、電子メールやＳＭＳ（Short Message Service）、連携先のＳＮＳ（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 (10)

1. 提携先の金融機関から借り受けた複数の仮想口座を特定するための口座番号と、電子決済サービスのサービス利用者を識別するための利用者識別情報とを対応付けて記憶部に保存することにより管理する管理部と、
   前記仮想口座の所定名義を前記サービス利用者の利用者名義に変更するための名義変更処理を実行する名義変更部と
   を有することを特徴とする情報処理装置。
2. 前記管理部は、
   前記利用者識別情報に対応付けて、前記サービス利用者による本人確認の手続が完了済みであるか否かを示すステータス情報を前記記憶部に保存して管理し、
   前記サービス利用者から前記仮想口座の作成依頼を受け付けた場合、作成依頼元の前記サービス利用者に対応する前記利用者識別情報に対応付けられている前記ステータス情報に基づいて、前記作成依頼元の前記サービス利用者による前記本人確認の手続が完了済みであるか否かを判定するステータス判定処理を実行し、前記本人確認の手続が完了済みであると判定した場合、前記サービス利用者に対して前記仮想口座を割り当てる
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記管理部は、
   前記本人確認の手続が完了済みであると判定した場合、前記本人確認の手続に用いられた本人確認情報が有効期限内であることを条件として、前記サービス利用者に対して前記仮想口座を割り当てる
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記名義変更部は、
   前記仮想口座の所定名義を、前記本人確認の手続で確認された前記サービス利用者の利用者名義に変更する
   ことを特徴とする請求項２または３に記載の情報処理装置。
5. 前記管理部は、
   前記本人確認情報の有効期限を、前記サービス利用者に割り当てる前記仮想口座の有効期限として設定し、前記利用者識別情報に対応付けて前記記憶部に保存して管理する
   ことを特徴とする請求項３に記載の情報処理装置。
6. 前記管理部は、
   前記本人確認情報の変更依頼を前記サービス利用者から受け付けた場合、前記利用者識別情報に対応付けて、変更前の前記本人確認情報を変更後の前記本人確認情報に更新して前記記憶部に保存して管理する
   ことを特徴とする請求項２に記載の情報処理装置。
7. 前記名義変更部は、
   前記本人確認情報の変更依頼を受け付けた際、変更後の本人確認情報に紐付く前記サービス利用者の氏名が変更されている場合、変更後の氏名を用いて前記仮想口座の名義変更を実行する
   ことを特徴とする請求項６に記載の情報処理装置。
8. 前記名義変更部は、
   前記利用者名義が予め設定される上限文字数を超過する場合、前記利用者名義が前記上限文字数以下となるように調整した調整後の前記利用者名義を用いて前記名義変更処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
9. コンピュータが、
   提携先の金融機関から借り受けた複数の仮想口座を特定するための口座番号と、電子決済サービスのサービス利用者を識別するための利用者識別情報とを対応付けて記憶部に保存することにより管理する管理工程と、
   前記仮想口座の所定名義を前記サービス利用者の利用者名義に変更するための名義変更処理を実行する名義変更工程と
   を実行することを特徴とする情報処理方法。
10. コンピュータに、
    提携先の金融機関から借り受けた複数の仮想口座を特定するための口座番号と、電子決済サービスのサービス利用者を識別するための利用者識別情報とを対応付けて記憶部に保存することにより管理する管理手順と、
    前記仮想口座の所定名義を前記サービス利用者の利用者名義に変更するための名義変更処理を実行する名義変更手順と
    を実行させることを特徴とする情報処理プログラム。

Images