ホーム > 特許ランキング > 楽天グループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-09-06
(45)【発行日】2024-09-17
(54)【発明の名称】入金システム、入金方法、及びプログラム
(51)【国際特許分類】
G06Q 40/02 20230101AFI20240909BHJP
G06Q 20/06 20120101ALI20240909BHJP
【ＦＩ】
G06Q40/02
G06Q20/06 300
【請求項の数】
20
(21)【出願番号】P 2023121539
(22)【出願日】2023-07-26
【審査請求日】2023-07-26
(73)【特許権者】
【識別番号】399037405
【氏名又は名称】楽天グループ株式会社
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】前田 朋希
(72)【発明者】
【氏名】岸本 祐有亮
(72)【発明者】
【氏名】平敷 兼貴
【審査官】永野 一郎
(56)【参考文献】
【文献】特許第７２８９４１２（ＪＰ，Ｂ１）
【文献】特許第７２１９３５９（ＪＰ，Ｂ１）
【文献】特開２０２１－１３５９０４（ＪＰ，Ａ）
【文献】特開２０２２－１５１８７３（ＪＰ，Ａ）
【文献】特開２０２２－０１５４３５（ＪＰ，Ａ）
【文献】特開２０２３－０２７９６８（ＪＰ，Ａ）
【文献】特開２０２３－０６７７３９（ＪＰ，Ａ）
【文献】特開２０１９－０７４９８３（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得部と、前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定部と、
前記要否判定部により前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行部と、
を含む入金システム。
【請求項2】
前記口座番号は、金融機関における前記ユーザの仮想口座の番号であり、前記振込情報取得部は、前記金融機関の金融機関システムから、前記仮想口座に関する前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金を実行する、
請求項１に記載の入金システム。
【請求項3】
前記口座番号は、ベンダーにより発行されたベンダー発行番号であり、前記振込情報取得部は、前記ベンダーのベンダーシステムから、前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記ベンダー発行番号に関連付けられた金融機関における口座であるベンダー関連口座の残高に基づいて、前記入金を実行する、
請求項１に記載の入金システム。
【請求項4】
前記振込情報取得部は、前記ベンダーシステムから、前記振込における予定日よりも前に、前記振込情報を取得し、前記入金システムは、
前記予定日よりも前に、前記振込情報に基づいて、前記振込に関するエラーが発生するか否かを判定するエラー判定部と、
前記エラー判定部により前記エラーが発生すると判定された場合に、前記振込におけるエラーの修正を依頼するための修正依頼処理を実行する修正依頼部と、
を更に含む請求項３に記載の入金システム。
【請求項5】
前記ベンダー関連口座には、前記振込情報が受け付けられる前に、前記振込における依頼人に関するデポジットが入金され、前記入金システムは、前記振込情報に基づいて、前記デポジットが足りるか否かを判定するデポジット判定部を更に含み、
前記入金実行部は、前記デポジット判定部により前記デポジットが足りると判定された場合に、前記入金を実行する、
請求項３又は４に記載の入金システム。
【請求項6】
前記ベンダー関連口座には、前記振込情報が受け付けられた後に、前記振込における依頼人によって前記振込に応じた金額が振り込まれ、前記入金システムは、前記ベンダー関連口座に前記金額が振り込まれたか否かを判定する振込判定部を更に含み、
前記入金実行部は、前記振込判定部により前記ベンダー関連口座に前記金額が振り込まれたと判定された場合に、前記入金を実行する、
請求項３又は４に記載の入金システム。
【請求項7】
前記要否判定部は、前記振込種別が給与振込又は賞与振込を示さない場合には、前記入金が不要であると判定し、前記振込種別が前記給与振込又は前記賞与振込を示す場合に、前記入金が必要であると判定する、請求項１～４の何れかに記載の入金システム。
【請求項8】
前記決済手段は、給与振込又は賞与振込用の第１残高と、当該第１残高とは異なる第２残高と、を有し、前記入金実行部は、前記入金が必要であると判定された場合に、前記第１残高に前記入金を実行する、
請求項７に記載の入金システム。
【請求項9】
前記入金システムは、前記要否判定部により前記入金が不要であると判定された場合に、前記ユーザにより指定された指定口座に対し、前記振込における振込金額の一部もしくは全部を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、請求項１～４の何れかに記載の入金システム。
【請求項10】
前記入金システムは、前記指定口座振込処理が実行される場合に、前記ユーザに対し、前記指定口座振込処理の実行に関する通知を行う第１通知部を更に含む、請求項９に記載の入金システム。
【請求項11】
前記入金システムは、前記指定口座振込処理が実行された場合に、前記決済手段の残高を管理するための残高管理画面に、前記指定口座振込処理が実行されたことを表示させる表示制御部を更に含む、請求項９に記載の入金システム。
【請求項12】
前記入金システムは、前記指定口座振込処理の実行結果に基づいて、前記振込における依頼人に対し、前記入金が不要と判定される種別の振込を行わないように促す通知を行う第２通知部を更に含む、請求項９に記載の入金システム。
【請求項13】
前記決済手段は、前記入金用の第１残高と、当該第１残高とは異なる第２残高と、を有し、前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記第１残高に対する前記入金を実行し、
前記入金システムは、
前記要否判定部により前記入金が不要であると判定された場合に前記ユーザが指定した指定口座に振り込むか、又は、当該場合に前記第２残高に入金するか、に関する設定を前記ユーザから受け付ける設定受付部と、
前記設定が前記指定口座を示す場合に、前記振込における振込金額を振り込むための指定口座振込処理を実行する指定口座振込部と、
を更に含み、
前記入金実行部は、前記設定が前記第２残高を示す場合に、前記第２残高に対する入金を実行する、
請求項１～４の何れかに記載の入金システム。
【請求項14】
前記決済手段には、前記入金用の残高に関する上限値が設定されており、前記入金システムは、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記上限値を超えるか否かを判定する上限値判定部を更に含み、
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えないと判定された場合に、前記振込における振込金額が前記決済手段に入金されるように、前記入金を実行する、
請求項１～４の何れかに記載の入金システム。
【請求項15】
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えると判定された場合に、前記決済手段の現在の前記残高と、前記上限値と、の差額に基づいて、前記入金を実行し、前記入金システムは、前記ユーザにより指定された指定口座に対し、前記振込金額のうち、前記上限値を超えた分を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、
請求項１４に記載の入金システム。
【請求項16】
前記決済手段には、前記上限値として、第１上限値と、当該第１上限値よりも高い第２上限値と、が設定されており、前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第２上限値を超えるか否かを判定し、
前記指定口座振込部は、前記上限値判定部により前記残高が前記第２上限値を超えると判定された場合に、前記指定口座振込処理を実行する、
請求項１５に記載の入金システム。
【請求項17】
前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第１上限値を超えるか否かを判定し、前記入金システムは、前記上限値判定部により前記残高が前記第１上限値を超えると判定された場合に、前記ユーザに対し、前記残高の利用を促す通知を行う第３通知部を更に含む、
請求項１６に記載の入金システム。
【請求項18】
前記入金システムは、過去における前記指定口座振込処理の実績に基づいて、前記ユーザに対し、前記振込として適切な額を提示する適切額提示部を更に含む、請求項１５に記載の入金システム。
【請求項19】
コンピュータが、
ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得ステップと、
前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定ステップと、
前記要否判定ステップにより前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行ステップと、
を実行する入金方法。
【請求項20】
ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得部、前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定部、
前記要否判定部により前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行部、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、入金システム、入金方法、及びプログラムに関する。
【背景技術】
【0002】
従来、電子的な決済手段（例えば、電子マネー又は仮想通貨）により、キャッシュレス化を推進するための技術が知られている。例えば、特許文献１には、電子マネーに対する入金によって、従業員に対する給与の支払を可能にする法改正が日本国で行われた場合に、従来型の電子マネーに対する入金が可能な基盤マネーを利用することによって、当該法改正に対応できるようにする金融基盤システムが記載されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２１－０４３８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のような技術では、ユーザの口座番号が振込先として指定された振込に基づいて、電子的な決済手段に対する入金が実行されることがある。特許文献１に記載の給与の支払を例に挙げると、雇用主である企業が、従業員の口座番号を振込先として指定した振込を行うと、当該従業員の電子マネーに対する入金が実行されることがある。このような振込の中には、従業員に対する給与の振込だけではなく、非給与（例えば、立替金等）の振込も存在するので、これらを区別して電子マネーを適切に管理することが求められている。この点は、特許文献１のような給与デジタル払い及び電子マネーに限られず、給与以外の振込と、電子的な決済手段全般と、についても言えることである。
【0005】
本開示の目的の１つは、ユーザの電子的な決済手段に対し、適切な入金を実行することである。
【課題を解決するための手段】
【0006】
本開示に係る入金システムは、ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得部と、前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定部と、前記要否判定部により前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行部と、を含む。
【発明の効果】
【0007】
本開示によれば、ユーザの電子的な決済手段に対し、適切な入金を実行することができる。
【図面の簡単な説明】
【0008】
【図1】第１実施形態における入金システムのハードウェア構成の一例を示す図である。
【図2】第１実施形態における入金システムの概要の一例を示す図である。
【図3】第１実施形態で給与デジタル払いを希望するユーザが行う手続きの一例を示す図である。
【図4】第１実施形態で給与デジタル払いを希望するユーザが行う手続きの一例を示す図である。
【図5】電子マネーの残高の一例を示す図である。
【図6】第１実施形態の入金システムで実現される機能の一例を示す図である。
【図7】電子マネーデータベースの一例を示す図である。
【図8】勤務先データベースの一例を示す図である。
【図9】振込データベースの一例を示す図である。
【図10】仮想口座データベースの一例を示す図である。
【図11】第１実施形態の入金システムで実行される処理の一例を示す図である。
【図12】第１実施形態の入金システムで実行される処理の一例を示す図である。
【図13】第２実施形態におけるシステム構成の一例を示す図である。
【図14】第２実施形態におけるにおける入金システムの概要の一例を示す図である。
【図15】第２実施形態の入金システムで実現される機能の一例を示す図である。
【図16】ベンダーデータベースの一例を示す図である。
【図17】第２実施形態の入金システムで実行される処理の一例を示す図である。
【図18】第２実施形態の入金システムで実行される処理の一例を示す図である。
【図19】変形例における機能の一例を示す図である。
【図20】指定口座振込処理の実行に関する通知の一例を示す図である。
【図21】残高管理画面の一例を示す図である。
【図22】振込における依頼人に対する通知の一例を示す図である。
【図23】残高の利用を促す通知の一例を示す図である。
【発明を実施するための形態】
【0009】
［１．第１実施形態］
本開示に係る入金システム、入金方法、及びプログラムの実施形態の一例である第１実施形態を説明する。
本開示に係る入金システム、入金方法、及びプログラムの実施形態の一例である第１実施形態を説明する。
【0010】
［１－１．第１実施形態における入金システムのハードウェア構成］
図１は、第１実施形態における入金システムのハードウェア構成の一例を示す図である。例えば、入金システム１は、インターネット又はＬＡＮ等のネットワークＮに接続される。第１実施形態では、勤務先システム２、金融機関システム３、及びユーザ端末４０も、ネットワークＮに接続される。ネットワークＮには、任意のコンピュータが接続可能である。ネットワークＮに接続されるコンピュータは、図１の例に限られない。
図１は、第１実施形態における入金システムのハードウェア構成の一例を示す図である。例えば、入金システム１は、インターネット又はＬＡＮ等のネットワークＮに接続される。第１実施形態では、勤務先システム２、金融機関システム３、及びユーザ端末４０も、ネットワークＮに接続される。ネットワークＮには、任意のコンピュータが接続可能である。ネットワークＮに接続されるコンピュータは、図１の例に限られない。
【0011】
例えば、入金システム１は、入金サーバ１０を含む。入金サーバ１０は、電子的な決済手段を取り扱う事業者のサーバコンピュータである。第１実施形態では、電子的な決済手段の一例として電子マネー（デジタルマネー）を説明するが、決済手段自体は、任意の種類であってよく、電子マネーに限られない。例えば、決済手段は、電子マネーとは呼ばれない前払い式支払手段、暗号資産、口座、ウォレット、クレジットカード、デビットカード、ポイント、又はその他の手段であってもよい。
【0012】
以降、電子マネーを取り扱う事業者を電子マネー事業者という。例えば、電子マネー事業者は、電子マネーの管理及び運営を行う企業である。以降の説明で電子マネーと記載した箇所は、入金が可能な任意の決済手段に読み替えることができる。例えば、決済手段は、残高の概念を有する。クレジットカード、デビットカード、及びポイントは、入金可能ではないので、電子マネーと記載した箇所は、前払い式支払手段、暗号資産、口座、ウォレット、又はその他の入金可能な決済手段に読み替えることができる。
【0013】
例えば、入金サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、の少なくとも一方を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
【0014】
なお、記憶部１２に記憶されるプログラムは、ネットワークＮを介して、入金サーバ１０に供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体に記憶されたプログラムが、情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して、入金サーバ１０に供給されてもよい。
【0015】
また、入金システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、入金システム１は、入金サーバ１０と、他のサーバコンピュータと、を含んでもよい。入金システム１は、パーソナルコンピュータ、タブレット、又はスマートフォンといったように、サーバコンピュータ以外の他のコンピュータを含んでもよい。入金システム１は、サーバコンピュータを含まずに、サーバコンピュータ以外の他のコンピュータだけを含んでもよい。
【0016】
勤務先システム２は、電子マネーを利用するユーザの勤務先のシステムである。第１実施形態では、勤務先の一例として会社を説明するが、勤務先は、ユーザに給与を支払う者であればよく、会社に限られない。例えば、勤務先は、個人商店、地方公共団体、非営利法人、又はその他の組織であってもよい。例えば、勤務先システム２は、勤務先サーバ２０及び勤務先端末２４を含む。なお、勤務先システム２は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。この点は、入金システム１と同様である。
【0017】
例えば、勤務先サーバ２０は、勤務先のサーバコンピュータである。勤務先サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。なお、記憶部２２に記憶されるプログラムは、ネットワークＮ又は情報記憶媒体を介して、勤務先サーバ２０に供給されてもよい。
【0018】
例えば、勤務先端末２４は、勤務先で給与振込を担当する担当者のコンピュータである。勤務先端末２４は、パーソナルコンピュータ、スマートフォン、又はタブレットである。勤務先端末２４は、制御部２５、記憶部２６、通信部２７、操作部２８、及び表示部２９を含む。制御部２５、記憶部２６、及び通信部２７のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部２８は、キーボード、マウス、又はタッチパネル等の入力デバイスである。表示部２９は、液晶又は有機ＥＬ等のディスプレイである。なお、記憶部２６に記憶されるプログラムは、ネットワークＮ又は情報記憶媒体を介して、勤務先端末２４に供給されてもよい。
【0019】
金融機関システム３は、金融機関のシステムである。第１実施形態では、金融機関の一例として銀行を説明するが、金融機関は、任意の種類であってよく、銀行に限られない。例えば、金融機関は、信用金庫、証券会社、協同組合、労働金庫、又はその他の機関であってもよい。例えば、金融機関システム３は、金融機関サーバ３０を含む。なお、金融機関システム３は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。この点は、入金システム１と同様である。
【0020】
例えば、金融機関サーバ３０は、金融機関のサーバコンピュータである。金融機関サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。なお、記憶部３２に記憶されるプログラムは、ネットワークＮ又は情報記憶媒体を介して、金融機関サーバ３０に提供されてもよい。
【0021】
ユーザ端末４０は、ユーザのコンピュータである。例えば、ユーザ端末４０は、パーソナルコンピュータ、スマートフォン、タブレット、又はウェアラブル端末である。図１では、１つのユーザ端末４０だけが示されているが、複数のユーザの各々のユーザ端末４０が存在してもよい。例えば、ユーザ端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５を含む。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部２８、及び表示部２９と同様であってよい。なお、記憶部４２に記憶されるプログラムは、ネットワークＮ又は情報記憶媒体を介して、ユーザ端末４０に提供されてもよい。
【0022】
［１－２．第１実施形態における入金システムの概要］
図２は、第１実施形態における入金システム１の概要の一例を示す図である。第１実施形態では、入金システム１は、勤務先システム２から給与振込の依頼を受け付ける金融機関システム３と連携することによって、ユーザに対する給与デジタル払いを実現する。例えば、給与デジタル払いを希望するユーザは、ユーザ端末４０にインストールされた決済アプリから所定の手続きを行う。決済アプリは、電子マネー事業者が提供するアプリケーション（例えば、いわゆるスマホアプリ）である。
図２は、第１実施形態における入金システム１の概要の一例を示す図である。第１実施形態では、入金システム１は、勤務先システム２から給与振込の依頼を受け付ける金融機関システム３と連携することによって、ユーザに対する給与デジタル払いを実現する。例えば、給与デジタル払いを希望するユーザは、ユーザ端末４０にインストールされた決済アプリから所定の手続きを行う。決済アプリは、電子マネー事業者が提供するアプリケーション（例えば、いわゆるスマホアプリ）である。
【0023】
図３及び図４は、第１実施形態で給与デジタル払いを希望するユーザが行う手続きの一例を示す図である。例えば、ユーザ端末４０で決済アプリが起動すると、ユーザ端末４０は、決済アプリ画面ＳＣ１を表示部４５に表示させる。ユーザが、電子マネーの加盟店に配置された決済端末にコードＣ１０を読み取らせると、予め支払元として設定された決済手段に基づいて、決済が実行される。図３の例では、ユーザは、電子マネーを支払元として設定している。ユーザは、クレジットカード等の他の決済手段に支払元を変更できる。
【0024】
第１実施形態では、オンライン型の電子マネーを例に挙げるが、電子マネーは、任意のタイプであってよく、オンライン型に限られない。例えば、電子マネーは、ユーザ端末４０のＩＣチップに残高等の情報が書き込まれるタイプ、ＩＣカードに残高等の情報が書き込まれるタイプ、磁気カードに残高等の情報が書き込まれるタイプ、顔認証等の生体認証だけで完結するタイプ、又はその他のタイプであってもよい。
【0025】
例えば、ユーザがボタンＢ１１を選択すると、図３の右上のように、ユーザ端末４０は、給与デジタル払いの手続きの詳細を、決済アプリ画面ＳＣ１に表示させる。なお、ユーザがボタンＢ１２を選択すると、ユーザ端末４０は、電子マネーの残高を管理するための残高管理画面（後述の変形例２）を、表示部４５に表示させる。第１実施形態では、ユーザは、決済アプリから、金融機関における仮想口座の開設手続きと、指定口座の登録手続きと、を行う場合を例に挙げるが、これらの手続きは、ユーザではなく、勤務先等の他の者が行ってもよい。
【0026】
仮想口座は、振込専用の口座である。別の言い方をすれば、仮想口座は、振込を受け付けるための口座である。仮想口座は、仮口座と呼ばれることもある。例えば、仮想口座は、残高の概念が存在しない、又は、残高が所定値（例えば、０円）で固定されている。仮想口座には、親口座が関連付けられている。親口座は、仮想口座に対する振込における現金が入金される口座である。親口座は、残高の概念が存在する、又は、残高が所定値（例えば、０円）で固定されていない。親口座は、仮想口座が関連付けられるという点以外については、通常の実口座と同様である。なお、仮想口座は出金機能を有してもよい。
【0027】
指定口座は、仮想口座とは異なる実口座である。例えば、指定口座の名義人は、ユーザである。指定口座は、第１実施形態における給与デジタル払いの仕組みではユーザが受け取れない資金を振り込むための口座である。指定口座は、仮想口座が開設された金融機関と同じ金融機関の口座であってもよいし、他の金融機関の口座であってもよい。ユーザは、任意の金融機関の口座を、指定口座として指定できる。
【0028】
例えば、ユーザがボタンＢ１３を選択すると、図３の左下のように、ユーザ端末４０は、ブラウザを起動して金融機関のウェブサイトを示す金融機関画面ＳＣ２を、表示部４５に表示させる。金融機関画面ＳＣ２には、ユーザの氏名、生年月日、及び住所といったように、仮想口座の開設に必要な情報が表示される。ユーザがボタンＢ２０を選択すると、仮想口座の開設が完了する。図３の右下のように、ユーザ端末４０は、仮想口座の開設が完了したことを示すメッセージを、金融機関画面ＳＣ２に表示させる。なお、ユーザは、ボタンＢ２１を選択して情報を修正することもできる。仮想口座の開設の手続自体は、公知の流れと同様であってもよい。
【0029】
例えば、決済アプリ画面ＳＣ１が右上の状態でユーザがボタンＢ１４を選択すると、図４の左側のように、ユーザ端末４０は、指定口座に関する情報の入力を受け付ける入力フォームＦ１５を、決済アプリ画面ＳＣ１に表示させる。ユーザは、入力フォームＦ１５に対し、金融機関名（金融機関コード）、支店名（支店コード）、口座種別、口座番号、及び名義人を入力することによって、指定口座を指定する。ユーザが入力フォームＦ１５に必要事項を入力してボタンＢ１６を選択すると、指定口座の登録が完了する。指定口座の登録が完了すると、図４の右側のように、ユーザ端末４０は、指定口座の登録が完了したことを示すメッセージを、決済アプリ画面ＳＣ１に表示させる。
【0030】
図２に戻り、ユーザは、勤務先における給与振込の担当者に対し、自身が発行した仮想口座を振込先として登録するように依頼する。担当者は、勤務先端末２４を操作して、ユーザの給与の振込先の情報を、勤務先サーバ２０に登録する。勤務先サーバ２０は、給与振込を実行すべきタイミングが訪れると、ＦＢ（Firm Banking）データを出力する。給与振込自体は、公知の処理によって実行されてよい。なお、ＦＢデータの代わりに、ＩＢ（Internet Banking）データでもよい。以下、ＦＢデータを例に説明する。
【0031】
例えば、ＦＢデータは、ヘッダレコード、データレコード、トレーラーレコード、及びエンドレコードを含む。ＦＢデータのフォーマットは、公知のフォーマットであってよい。ＦＢデータは、振込種別を含む。第１実施形態では、振込種別が「２１」であることは、総合振込を意味する。振込種別が「１１」であることは、給与振込を意味する。振込種別が「１２」であることは、賞与振込を意味する。振込種別が示す数値は、予め定められた意味であればよく、第１実施形態の例に限られない。ＦＢデータは、依頼人名、振込指定日、振込元の情報、振込先の情報、及び振込金額といった他の情報も含む。
【0032】
例えば、勤務先サーバ２０は、金融機関サーバ３０に対し、ＦＢデータを送信する。金融機関サーバ３０は、勤務先サーバ２０から、ＦＢデータを受信する。金融機関サーバ３０は、ＦＢデータに基づいて、振込を実行する。ＦＢデータに基づく振込は、公知の処理によって実行されてよい。第１実施形態では、ユーザが振込先として仮想口座を指定しているので、ユーザの給与は、電子マネー事業者が管理する親口座に入金される。
【0033】
例えば、入金サーバ１０は、ＡＰＩを利用して、金融機関サーバ３０から、給与デジタル払いの対象となる給与振込に関する振込情報を取得する。振込情報は、ＦＢデータの全部又は一部の情報を含む。例えば、振込情報は、依頼人名（振込名義人）、振込先、振込種別、及び振込金額を示す。依頼人名が振込名義人と異なる場合、振込人名と振込名義人の両方が振込情報に含まれるようにしてもよい。本開示では、依頼人名も振込名義人もユーザの勤務先である場合について説明する。振込情報は、即時に実行される振込の内容を示してもよいし、将来的に予定されている振込の内容を示してもよい。また、振込情報は、ＦＢデータのままでもよく、他のフォーマットに変換されたものでもよい。振込情報が他のフォーマットに変換された場合は、振込情報には、さらに他の情報が足されてもよい。例えば、振込情報には、現金が口座に着金しているか否かの情報が足されてもよい。なお、後述の第２実施形態の方式の場合には、現金が口座に着金しているか否かの情報が振込情報に足されないものとする。
【0034】
第１実施形態では、入金サーバ１０は、振込種別が給与振込又は賞与振込である場合には、電子マネーに対する入金を実行する。入金サーバ１０は、振込種別が給与振込又は賞与振込ではない場合（例えば、振込種別が総合振込である場合、又は、振込種別の指定がない場合）には、指定口座に対する振込を実行する。給与以外の立替金等の振込が実行される場合には、振込種別は、総合振込になる。振込種別が指定されないこともある。
【0035】
図５は、電子マネーの残高の一例を示す図である。第１実施形態では、電子マネーは、給与デジタル払い用の第１残高と、第１残高とは異なる第２残高と、を有する。第１残高には、上限値が設定されている。第１実施形態では、上限値が１０万円である場合を例に挙げるが、上限値は、任意の値であってよく、第１実施形態の例に限られない。例えば、上限値は、ユーザが指定できるようにしてもよい。第１残高は、出金が可能である。第２残高は、従来から存在する電子マネーの残高と同様であってよい。第２残高は、出金が可能であってもよいし、出金できないように制限されていてもよい。
【0036】
以降、第１残高を、給与残高という。第２残高を、非給与残高という。第１実施形態では、電子マネーの残高として、出金できない基本型残高と、出金可能なプレミアム型残高と、が存在するものとする。例えば、クレジットカードのショッピング枠に基づいて電子マネーのチャージが実行されると、基本型残高（図５の例では、１５０００円）が増える。クレジットカードのキャッシング枠、オンラインショッピングモールの売上金、又は暗号資産に基づいて電子マネーのチャージが実行されると、プレミアム型残高（図５の例では、１００００円）が増える。給与残高（図５の例では、５００００円）は、プレミアム型残高に分類される。
【0037】
例えば、入金サーバ１０は、振込種別が給与振込又は賞与振込であり、かつ、給与残高に給与額が入金されても上限値を超えない場合には、振込金額の全てを、給与残高に入金する。入金サーバ１０は、振込種別が給与振込又は賞与振込であり、かつ、給与残高に給与額が入金されると上限値を超える場合には、振込金額のうち、上限値を超えない範囲の金額を給与残高に入金し、かつ、上限値を超えた分を指定口座に振り込む。入金サーバ１０は、振込種別が給与振込又は賞与振込の何れでもない場合、振込金額の全てを、指定口座に振り込む。
【0038】
例えば、ある勤務先の従業員であるユーザＵ１～Ｕ３の各々が、給与デジタル払いの手続をしたとする。給与残高の上限値が、１０万円だったとする。ユーザＵ１の現在の給与残高が、２万円だったとする。ユーザＵ１に対する振込における振込種別が、給与振込だったとする。当該振込における振込金額が、３万円だったとする。この場合、ユーザＵ１の現在の給与残高の２万円に、振込金額の３万円を足しても上限値を超えない。このため、ユーザＵ１の給与残高に対し、振込金額の全てである３万円が入金される。
【0039】
例えば、ユーザＵ２の現在の給与残高が、８万円だったとする。ユーザＵ２に対する振込における振込種別が、賞与振込だったとする。当該振込における振込金額が、５万円だったとする。この場合、ユーザＵ２の現在の給与残高の８万円に、振込金額の５万円を足すと上限値を超える。このため、ユーザＵ２の給与残高に対し、当該給与残高が上限値になるように、振込金額の一部である２万円が入金される。振込金額のうち、上限値を超えた分の３万円は、ユーザＵ２の指定口座に入金される。
【0040】
例えば、ユーザＵ３の現在の給与残高が、５万円だったとする。ユーザＵ３に対する振込における振込種別が、総合振込だったとする。当該振込における振込金額が、６万円だったとする。この場合、振込種別が給与振込又は賞与振込ではないので、ユーザＵ３の給与残高に対する入金は、実行されない。ユーザＵ３の現在の給与残高に関係なく、振込金額の全てが、ユーザＵ３の指定口座に入金される。
【0041】
以上のように、第１実施形態の入金システム１は、振込種別に基づいて、電子マネーの給与残高に対する入金の要否を判定する。入金システム１は、給与残高に対する入金が必要であると判定した場合に、給与残高に対する入金を実行する。入金システム１は、給与残高に対する入金が不要であると判定した場合に、指定口座に対する振込を実行する。これにより、入金システム１は、ユーザの電子マネーに対し、適切な入金を実行できる。以降、入金システム１の詳細を説明する。
【0042】
［１－３．第１実施形態の入金システムで実現される機能］
図６は、第１実施形態の入金システム１で実現される機能の一例を示す図である。図４では、勤務先システム２、金融機関システム３、及びユーザ端末４０の各々で実現される機能の一例も示されている。
図６は、第１実施形態の入金システム１で実現される機能の一例を示す図である。図４では、勤務先システム２、金融機関システム３、及びユーザ端末４０の各々で実現される機能の一例も示されている。
【0043】
［１－３－１．入金システムで実現される機能］
例えば、入金サーバ１０は、データ記憶部１００、振込情報取得部１０１、要否判定部１０２、上限値判定部１０３、入金実行部１０４、及び指定口座振込部１０５を含む。データ記憶部１００は、記憶部１２により実現される。振込情報取得部１０１、要否判定部１０２、上限値判定部１０３、入金実行部１０４、及び指定口座振込部１０５は、制御部１１により実現される。
例えば、入金サーバ１０は、データ記憶部１００、振込情報取得部１０１、要否判定部１０２、上限値判定部１０３、入金実行部１０４、及び指定口座振込部１０５を含む。データ記憶部１００は、記憶部１２により実現される。振込情報取得部１０１、要否判定部１０２、上限値判定部１０３、入金実行部１０４、及び指定口座振込部１０５は、制御部１１により実現される。
【0044】
［データ記憶部］
データ記憶部１００は、電子マネーに対する入金に必要なデータを記憶する。例えば、データ記憶部１００は、電子マネーデータベースＤＢ１を記憶する。
データ記憶部１００は、電子マネーに対する入金に必要なデータを記憶する。例えば、データ記憶部１００は、電子マネーデータベースＤＢ１を記憶する。
【0045】
図７は、電子マネーデータベースＤＢ１の一例を示す図である。電子マネーデータベースＤＢ１は、電子マネーに関する各種情報が格納されたデータベースである。例えば、電子マネーデータベースＤＢ１には、ユーザＩＤ、残高情報、履歴情報、仮想口座情報、及び指定口座情報が格納される。電子マネーデータベースＤＢ１には、電子マネーに関する何らかの情報が格納されるようにすればよく、電子マネーデータベースＤＢ１に格納される情報は、図７の例に限られない。例えば、コードＣ１０に含まれる一時的なＩＤが電子マネーデータベースＤＢ１に格納されてもよい。
【0046】
ユーザＩＤは、ユーザを識別可能なユーザ識別情報の一例である。このため、ユーザＩＤと記載した箇所は、ユーザ識別情報と読み替えることができる。ユーザ識別情報は、ユーザＩＤ以外の他の情報であってもよく、ユーザＩＤに限られない。例えば、ユーザ識別情報は、メールアドレス、電話番号、又はコードＣ１０に含まれる一時的なＩＤであってもよい。ユーザ識別情報は、ユーザを何らかの形で識別可能な情報であればよい。ユーザ識別情報は、電子マネーを識別可能な電子マネー識別情報ということもできる。
【0047】
残高情報は、電子マネーの残高を示す情報である。第１実施形態では、残高情報は、給与残高、非給与残高のうちのプレミアム型残高、及び非給与残高のうちの基本型残高の各々を示す。以降、これら３つの残高を区別しない時は、単に残高という。残高情報は、電子マネーに対する入金が行われた場合に更新される。残高情報は、電子マネーが利用された場合にも更新される。
【0048】
履歴情報は、電子マネーの入金及び利用の各々の履歴を示す情報である。例えば、履歴情報は、電子マネーの入金日時、入金方法、入金種別、入金額、及び入金後の残高の少なくとも１つを示す。履歴情報は、電子マネーの利用日時、利用場所、利用額、利用後の残高、及び利用場所の少なくとも１つを示す。履歴情報は、電子マネーに対する入金が行われた場合に更新される。履歴情報は、電子マネーが利用された場合にも更新される。
【0049】
仮想口座情報は、ユーザの仮想口座を示す情報である。例えば、仮想口座情報は、仮想口座の金融機関コード、金融機関名、支店コード、支店名、口座種別、口座番号、及び名義人の全部又は一部を示す。仮想口座情報は、仮想口座に関連付けられた親口座を示してもよい。第１実施形態では、ユーザが図３の手続きを完了すると、入金サーバ１０は、金融機関サーバ３０又はユーザ端末４０から、仮想口座情報を取得する。入金サーバ１０は、ユーザのユーザＩＤに関連付けられるように、電子マネーデータベースＤＢ１に仮想口座情報を格納する。
【0050】
指定口座情報は、ユーザの指定口座を示す情報である。例えば、指定口座情報は、指定口座の金融機関コード、金融機関名、支店コード、支店名、口座種別、口座番号、及び名義人の全部又は一部を示す。第１実施形態では、ユーザが図４の手続きを完了すると、入金サーバ１０は、ユーザが入力フォームＦ１５に入力した情報に基づいて、指定口座情報を生成する。入金サーバ１０は、ユーザのユーザＩＤに関連付けられるように、電子マネーデータベースＤＢ１に指定口座情報を格納する。
【0051】
なお、データ記憶部１００は、任意のデータを記憶可能である。データ記憶部１００に記憶されるデータは、電子マネーデータベースＤＢ１に限られない。例えば、データ記憶部１００は、ユーザが図３及び図４の手続きを行うために必要なデータを記憶してもよい。データ記憶部１００は、入金サーバ１０が実行する処理に必要なデータ（例えば、給与残高の上限値）を記憶すればよい。
【0052】
［振込情報取得部］
振込情報取得部１０１は、ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する。第１実施形態では、振込情報取得部１０１は、金融機関の金融機関システム３から、振込情報を取得する。振込情報は、少なくとも振込種別を示す。振込情報は、振込種別だけを示してもよい。振込情報取得部１０１は、任意のタイミングで振込情報を取得可能である。例えば、振込情報取得部１０１は、金融機関システム３が特定の口座に対する振込を受け付けるたびに、金融機関システム３から振込情報を取得してもよい。振込情報取得部１０１は、所定の日時（例えば、ユーザの勤務先における給料日、又は、給料日よりも前の日）が訪れた場合に、金融機関システム３から振込情報を取得してもよい。
振込情報取得部１０１は、ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する。第１実施形態では、振込情報取得部１０１は、金融機関の金融機関システム３から、振込情報を取得する。振込情報は、少なくとも振込種別を示す。振込情報は、振込種別だけを示してもよい。振込情報取得部１０１は、任意のタイミングで振込情報を取得可能である。例えば、振込情報取得部１０１は、金融機関システム３が特定の口座に対する振込を受け付けるたびに、金融機関システム３から振込情報を取得してもよい。振込情報取得部１０１は、所定の日時（例えば、ユーザの勤務先における給料日、又は、給料日よりも前の日）が訪れた場合に、金融機関システム３から振込情報を取得してもよい。
【0053】
例えば、入金サーバ１０は、金融機関システム３に対し、ユーザの仮想口座に対する振込があったか否かを、定期的又は不定期的に問い合わせる。金融機関システム３は、入金サーバ１０からの問い合わせを受信すると、後述の振込データベースＤＢ３に基づいて、ユーザの仮想口座に対する振込があったか否かを判定する。金融機関システム３は、ユーザの仮想口座に対する振込があったと判定した場合、振込情報を生成する。金融機関システム３は、入金サーバ１０に対し、振込情報を送信する。振込情報取得部１０１は、金融機関システム３から、振込情報を取得する。なお、金融機関システム３は、ユーザの仮想口座に対する振込がなかったと判定した場合、入金サーバ１０に対し、その旨を回答する。
【0054】
例えば、複数のユーザの各々の口座番号が振込先として指定された振込が一度に実行される場合には、振込情報取得部１０１は、複数の振込の各々における振込種別を特定する。第１実施形態では、ユーザの口座番号は、金融機関におけるユーザの仮想口座の番号である。仮想口座の番号体系は、通常の実口座と同様である。図３の仮想口座の例では、「ＡＡＡキャッシュ支店」といったように、電子マネーを識別可能な支店名に仮想口座が開設されているが、通常の支店に仮想口座が開設されてもよい。
【0055】
第１実施形態では、ユーザの仮想口座の口座番号が振込先として指定された振込における現金は、仮想口座に関連付けられた親口座に振り込まれる。親口座に対する振込の処理は、金融機関サーバ３０によって実行される。当該処理自体は、公知の仮想口座で採用されている処理であってよい。
【0056】
なお、振込情報取得部１０１は、ＦＢデータにおける振込種別ではなく、振込の詳細（取引内容）を示す文字列に基づいて、振込種別を特定してもよい。例えば、振込情報取得部１０１は、当該文字列に「キユウヨ」又は「シヨウヨ」といった文字列が存在するか否かを判定することによって、振込種別を特定してもよい。振込情報取得部１０１は、給与振込又は賞与振込以外の他の振込種別を特定してもよい。他の振込種別としては、仕送り、小遣い、月謝等の支払、又はその他の特定の支払であってもよい。
【0057】
［要否判定部］
要否判定部１０２は、振込情報取得部１０１により特定された振込種別に基づいて、ユーザの電子マネーに対する入金の要否を判定する。入金の要否とは、入金を実行するか否かである。電子マネーに対する入金は、チャージと呼ばれることもある。例えば、要否判定部１０２は、振込種別が所定の種別ではない場合に、電子マネーに対する入金が不要であると判定する。要否判定部１０２は、振込種別が所定の種別である場合に、電子マネーに対する入金が必要であると判定する。所定の種別は、第１実施形態のような給与振込又は賞与振込に限られず、予め定められた種別であればよい。例えば、所定の種別は、仕送り、小遣い、月謝等の支払、又はその他の特定の支払であってもよい。
要否判定部１０２は、振込情報取得部１０１により特定された振込種別に基づいて、ユーザの電子マネーに対する入金の要否を判定する。入金の要否とは、入金を実行するか否かである。電子マネーに対する入金は、チャージと呼ばれることもある。例えば、要否判定部１０２は、振込種別が所定の種別ではない場合に、電子マネーに対する入金が不要であると判定する。要否判定部１０２は、振込種別が所定の種別である場合に、電子マネーに対する入金が必要であると判定する。所定の種別は、第１実施形態のような給与振込又は賞与振込に限られず、予め定められた種別であればよい。例えば、所定の種別は、仕送り、小遣い、月謝等の支払、又はその他の特定の支払であってもよい。
【0058】
第１実施形態では、要否判定部１０２は、振込種別が給与振込又は賞与振込を示さない場合には、電子マネーに対する入金が不要であると判定する。別の言い方をすれば、要否判定部１０２は、振込種別が給与振込又は賞与振込の何れでもない場合には、電子マネーに対する入金が不要であると判定する。例えば、要否判定部１０２は、振込種別が総合振込を示す場合、又は、振込種別が不明の場合（振込種別が指定されていない場合、又は、そもそも振込種別が存在しない場合）には、電子マネーに対する入金が不要であると判定する。
【0059】
第１実施形態では、要否判定部１０２は、振込種別が給与振込又は賞与振込を示す場合に、入金が必要であると判定する。別の言い方をすれば、要否判定部１０２は、振込種別が給与振込又は賞与振込の何れかである場合に、電子マネーに対する入金が必要であると判定する。なお、給与振込以外に入金システム１が利用される場合には、要否判定部１０２は、振込種別が所定の種別であるか否かを判定することによって、入金の要否を判定すればよい。
【0060】
［上限値判定部］
第１実施形態では、電子マネーには、入金用の残高に関する上限値が設定されている。例えば、入金用の残高は、給与残高である。入金用の残高は、給与残高に限られず、他の残高であってもよい。例えば、給与残高の概念が存在しない場合には、プレミアム型残高が入金用の残高に相当してもよい。他にも例えば、基本型の残高が入金用の残高に相当してもよい。基本型残高及びプレミアム型残高といった概念が存在しない場合には、電子マネーの何らかの残高が入金用の残高に相当すればよい。
第１実施形態では、電子マネーには、入金用の残高に関する上限値が設定されている。例えば、入金用の残高は、給与残高である。入金用の残高は、給与残高に限られず、他の残高であってもよい。例えば、給与残高の概念が存在しない場合には、プレミアム型残高が入金用の残高に相当してもよい。他にも例えば、基本型の残高が入金用の残高に相当してもよい。基本型残高及びプレミアム型残高といった概念が存在しない場合には、電子マネーの何らかの残高が入金用の残高に相当すればよい。
【0061】
上限値判定部１０３は、要否判定部１０２により入金が必要と判定された場合に、入金により給与残高が上限値を超えるか否かを判定する。上限値は、データ記憶部１００に記憶されているものとする。第１実施形態では、全てのユーザで上限値が共通である場合を例に挙げるが、ユーザによって上限値が異なってもよい。上限値判定部１０３は、ユーザの仮想口座に対する振込における振込金額と、ユーザの現在の給与残高と、の合計を計算する。上限値判定部１０３は、当該合計が上限値を超えるか否かを判定することによって、入金により給与残高が上限値を超えるか否かを判定する。
【0062】
［入金実行部］
入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。振込金額に応じた入金とは、電子マネーに対する入金額（チャージ額）が振込金額と同じ入金、又は、入金額が振込金額未満の入金である。入金実行部１０４は、要否判定部１０２により入金が不要と判定された場合には、入金を実行しない。入金の実行方法自体は、公知の処理を利用可能である。第１実施形態のような電子マネーであれば、公知の電子マネーのチャージで利用されている処理に基づいて、入金が実行されてよい。入金実行部１０４は、電子マネーデータベースＤＢ１に格納された残高情報を更新することによって、入金を実行する。例えば、入金実行部１０４は、入金が必要であると判定された場合に、給与残高に入金を実行する。
入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。振込金額に応じた入金とは、電子マネーに対する入金額（チャージ額）が振込金額と同じ入金、又は、入金額が振込金額未満の入金である。入金実行部１０４は、要否判定部１０２により入金が不要と判定された場合には、入金を実行しない。入金の実行方法自体は、公知の処理を利用可能である。第１実施形態のような電子マネーであれば、公知の電子マネーのチャージで利用されている処理に基づいて、入金が実行されてよい。入金実行部１０４は、電子マネーデータベースＤＢ１に格納された残高情報を更新することによって、入金を実行する。例えば、入金実行部１０４は、入金が必要であると判定された場合に、給与残高に入金を実行する。
【0063】
例えば、入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、親口座の残高に基づいて、電子マネーに対する入金を実行する。第１実施形態では、親口座の名義人は、電子マネーを取り扱う電子マネー事業者である。親口座は、複数のユーザの各々の仮想口座に共通である。入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、電子マネー事業者が名義人であり、かつ、複数のユーザに共通の親口座の残高に基づいて、電子マネーに対する入金を実行する。入金実行部１０４は、親口座の残高を原資にして、電子マネーに対する入金を実行する。金融機関の口座に基づいて電子マネーの入金を実行する処理は、公知の電子マネーのチャージで利用されている処理と同様であってよい。
【0064】
なお、親口座は、電子マネーを取り扱う電子マネー事業者ではなく、他の者（例えば、ユーザの勤務先、又は、電子マネー事業者と連携するベンダー）が名義人であってもよい。更に、入金実行部１０４は、親口座ではなく、仮想口座に関連付けられていない他の口座に基づいて、電子マネーに対する入金を実行してもよい。入金実行部１０４は、金融機関システム３の金融機関以外の他の金融機関の口座に基づいて、電子マネーに対する入金を実行してもよい。入金実行部１０４は、口座以外の他の決済手段に基づいて、電子マネーに対する入金を実行してもよい。
【0065】
例えば、入金実行部１０４は、上限値判定部１０３により残高が上限値を超えないと判定された場合に、振込における振込金額が電子マネーに入金されるように、電子マネーに対する入金を実行する。入金実行部１０４は、振込金額の全てを、電子マネーに入金する。なお、電子マネーの入金の際に手数料が発生する場合には、入金実行部１０４は、振込金額から手数料を引いた額が電子マネーに入金されるように、電子マネーに対する入金を実行してもよい。
【0066】
例えば、入金実行部１０４は、上限値判定部１０３により給与残高が上限値を超えると判定された場合に、電子マネーの現在の給与残高と、上限値と、の差額に基づいて、電子マネーに対する入金を実行する。入金実行部１０４は、電子マネーの給与残高が当該差額だけ増加するように、電子マネーに対する入金を実行する。別の言い方をすれば、入金実行部１０４は、入金後の給与残高が上限値と一致するように、電子マネーに対する入金を実行する。なお、入金実行部１０４は、入金後の給与残高が上限値よりも少ない額になるように、電子マネーに対する入金を実行してもよい。
【0067】
［指定口座振込部］
指定口座振込部１０５は、要否判定部１０２により入金が不要であると判定された場合に、ユーザにより指定された指定口座に対し、振込における振込金額の一部もしくは全部を振り込むための指定口座振込処理を実行する。指定口座振込処理は、指定口座に対する振込に関する何らかの処理であればよい。例えば、指定口座振込部１０５は、指定口座の金融機関のシステム（例えば、金融機関システム３又は他のシステム）、又は、全銀協のシステムに対し、指定口座への振込を依頼することによって、指定口座振込処理を実行する。第１実施形態では、ユーザの仮想口座に関連付けられた親口座が振込の原資になるので、指定口座振込部１０５は、金融機関システム３に対し、振込を依頼する。この振込でも、ＦＢデータが利用されてよい。
指定口座振込部１０５は、要否判定部１０２により入金が不要であると判定された場合に、ユーザにより指定された指定口座に対し、振込における振込金額の一部もしくは全部を振り込むための指定口座振込処理を実行する。指定口座振込処理は、指定口座に対する振込に関する何らかの処理であればよい。例えば、指定口座振込部１０５は、指定口座の金融機関のシステム（例えば、金融機関システム３又は他のシステム）、又は、全銀協のシステムに対し、指定口座への振込を依頼することによって、指定口座振込処理を実行する。第１実施形態では、ユーザの仮想口座に関連付けられた親口座が振込の原資になるので、指定口座振込部１０５は、金融機関システム３に対し、振込を依頼する。この振込でも、ＦＢデータが利用されてよい。
【0068】
なお、振込の依頼自体は、公知の処理を利用可能である。第１実施形態では、指定口座振込部１０５が、電子マネーデータベースＤＢ１を参照することによって、ユーザの指定口座を特定する場合を例に挙げるが、指定口座振込部１０５は、他のデータベースを参照することによって、ユーザの指定口座を特定してもよい。指定口座振込部１０５は、金融機関が入金システム１を管理する場合には、指定口座振込部１０５は、他のシステムに振込を依頼するのではなく、自らが振込を実行してもよい。
【0069】
例えば、指定口座振込部１０５は、ユーザにより指定された指定口座に対し、振込金額のうち、上限値を超えた分を振り込むための指定口座振込処理を実行する。指定口座振込部１０５は、ユーザの仮想口座に対する振込における振込金額から、電子マネーに対する入金の金額を引いた金額が指定口座に振り込まれるように、指定口座振込処理を実行する。振込手数料が発生する場合には、指定口座振込部１０５は、本来ユーザが受け取るべき金額から振込手数料を引いた額が指定口座に振り込まれるように、指定口座振込処理を実行してもよい。
【0070】
［１－３－２．勤務先システムで実現される機能］
例えば、勤務先サーバ２０は、データ記憶部２００及び振込依頼部２０１を含む。データ記憶部２００は、記憶部２２により実現される。振込依頼部２０１は、制御部２１により実現される。勤務先端末２４は、データ記憶部２４０、表示制御部２４１、及び操作受付部２４２を含む。データ記憶部２００は、記憶部２６により実現される。表示制御部２４１及び操作受付部２４２は、制御部２５により実現される。
例えば、勤務先サーバ２０は、データ記憶部２００及び振込依頼部２０１を含む。データ記憶部２００は、記憶部２２により実現される。振込依頼部２０１は、制御部２１により実現される。勤務先端末２４は、データ記憶部２４０、表示制御部２４１、及び操作受付部２４２を含む。データ記憶部２００は、記憶部２６により実現される。表示制御部２４１及び操作受付部２４２は、制御部２５により実現される。
【0071】
［データ記憶部］
データ記憶部２００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部２００は、勤務先データベースＤＢ２を記憶する。なお、データ記憶部２００は、勤務先データベースＤＢ２以外の他のデータを記憶してもよい。例えば、データ記憶部２００は、ユーザに対する振込の原資となる勤務先の口座に関する情報を記憶してもよい。勤務先の口座は、ユーザが仮想口座を開設した金融機関と同じ金融機関の口座であってもよいし、当該金融機関とは異なる金融機関の口座であってもよい。
データ記憶部２００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部２００は、勤務先データベースＤＢ２を記憶する。なお、データ記憶部２００は、勤務先データベースＤＢ２以外の他のデータを記憶してもよい。例えば、データ記憶部２００は、ユーザに対する振込の原資となる勤務先の口座に関する情報を記憶してもよい。勤務先の口座は、ユーザが仮想口座を開設した金融機関と同じ金融機関の口座であってもよいし、当該金融機関とは異なる金融機関の口座であってもよい。
【0072】
図８は、勤務先データベースＤＢ２の一例を示す図である。勤務先データベースＤＢ２は、従業員に対する振込に関する各種情報が格納されたデータベースである。例えば、勤務先データベースＤＢ２には、社員番号、氏名、振込先情報、振込金額、及び振込種別が格納される。勤務先データベースＤＢ２には、振込に関する何らかの情報が格納されるようにすればよく、勤務先データベースＤＢ２に格納される情報は、図７の例に限られない。例えば、過去に実行された振込のＦＢデータが勤務先データベースＤＢ２に格納されてもよい。ユーザが給与の全額ではなく一部だけを給与デジタル払いで受け取ることを希望する場合には、ユーザが希望した金額が勤務先データベースＤＢ２に格納されてもよい。ユーザの仮想口座に対する振込は、当該金額だけであってもよい。当該金額を超える分は、ユーザの実口座に対して振り込まれてもよい。
【0073】
振込先情報は、従業員の振込先に関する情報である。例えば、振込先情報は、金融機関コード、金融機関名、支店コード、支店名、口座種別、口座番号、及び名義人の全部又は一部を示す。従業員の中には、給与デジタル払いを希望しない者もいるので、振込先情報は、仮想口座を示すとは限らない。振込先情報は、仮想口座ではない実口座を示すこともある。第１実施形態では、給与デジタル払いを希望するユーザに対する振込を説明するので、振込先情報は、ユーザの仮想口座を示す。振込金額及び振込種別は、勤務先における給与振込の担当者が指定するものとする。
【0074】
［振込依頼部］
振込依頼部２０１は、金融機関システム３に対し、振込を依頼する。例えば、振込依頼部２０１は、勤務先データベースＤＢ２に格納された振込先情報、振込金額、及び振込種別に基づいて、ＦＢデータを生成する。振込依頼部２０１は、金融機関システム３又は他のシステム（例えば、全銀システム）に対し、当該ＦＢデータを送信することによって、振込を依頼する。振込の依頼方法自体は、公知の処理を利用可能である。例えば、振込依頼部２０１は、企業等の勤務先で給与振込が行われる場合の公知の処理と同様の処理を実行することによって、振込を依頼してもよい。
振込依頼部２０１は、金融機関システム３に対し、振込を依頼する。例えば、振込依頼部２０１は、勤務先データベースＤＢ２に格納された振込先情報、振込金額、及び振込種別に基づいて、ＦＢデータを生成する。振込依頼部２０１は、金融機関システム３又は他のシステム（例えば、全銀システム）に対し、当該ＦＢデータを送信することによって、振込を依頼する。振込の依頼方法自体は、公知の処理を利用可能である。例えば、振込依頼部２０１は、企業等の勤務先で給与振込が行われる場合の公知の処理と同様の処理を実行することによって、振込を依頼してもよい。
【0075】
［データ記憶部］
データ記憶部２４０は、勤務先における給与振込の担当者の業務に必要なデータを記憶する。例えば、データ記憶部２４０は、担当者がユーザの振込先情報を登録するためのツールを記憶する。
データ記憶部２４０は、勤務先における給与振込の担当者の業務に必要なデータを記憶する。例えば、データ記憶部２４０は、担当者がユーザの振込先情報を登録するためのツールを記憶する。
【0076】
［表示制御部］
表示制御部２４１は、勤務先における給与振込に関する画面を表示部２９に表示させる。担当者は、当該画面から、ユーザの仮想口座の情報を入力する。
表示制御部２４１は、勤務先における給与振込に関する画面を表示部２９に表示させる。担当者は、当該画面から、ユーザの仮想口座の情報を入力する。
【0077】
［操作受付部］
操作受付部２４２は、表示制御部２４１が表示させた画面に対する操作を受け付ける。当該操作の内容に基づいて、勤務先データベースＤＢ２に格納された振込先情報が更新される。
操作受付部２４２は、表示制御部２４１が表示させた画面に対する操作を受け付ける。当該操作の内容に基づいて、勤務先データベースＤＢ２に格納された振込先情報が更新される。
【0078】
［１－３－３．金融機関システムで実現される機能］
例えば、金融機関サーバ３０は、データ記憶部３００、仮想口座開設部３０１、振込受付部３０２、及び振込情報送信部３０３を含む。データ記憶部３００は、記憶部３２により実現される。仮想口座開設部３０１、振込受付部３０２、及び振込情報送信部３０３は、制御部３１により実現される。
例えば、金融機関サーバ３０は、データ記憶部３００、仮想口座開設部３０１、振込受付部３０２、及び振込情報送信部３０３を含む。データ記憶部３００は、記憶部３２により実現される。仮想口座開設部３０１、振込受付部３０２、及び振込情報送信部３０３は、制御部３１により実現される。
【0079】
［データ記憶部］
データ記憶部３００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部３００は、振込データベースＤＢ３及び仮想口座データベースＤＢ４を記憶する。なお、データ記憶部３００は、振込データベースＤＢ３及び仮想口座データベースＤＢ４以外の他のデータを記憶してもよい。例えば、データ記憶部３００は、入金システム１と連携するためのＡＰＩのデータを記憶してもよい。
データ記憶部３００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部３００は、振込データベースＤＢ３及び仮想口座データベースＤＢ４を記憶する。なお、データ記憶部３００は、振込データベースＤＢ３及び仮想口座データベースＤＢ４以外の他のデータを記憶してもよい。例えば、データ記憶部３００は、入金システム１と連携するためのＡＰＩのデータを記憶してもよい。
【0080】
図９は、振込データベースＤＢ３の一例を示す図である。振込データベースＤＢ３は、金融機関における口座に対する振込に関する各種情報が格納されたデータベースである。例えば、振込データベースＤＢ３には、ＦＢデータの送信元、ＦＢデータの受信日時、及びＦＢデータが格納される。振込データベースＤＢ３には、振込に関する何らかの情報が格納されるようにすればよく、振込データベースＤＢ３に格納される情報は、図９の例に限られない。例えば、勤務先以外から受け付けられた振込に関する情報が振込データベースＤＢ３に格納されてもよい。
【0081】
図１０は、仮想口座データベースＤＢ４の一例を示す図である。仮想口座データベースＤＢ４は、金融機関に開設された仮想口座に関する各種情報が格納されたデータベースである。例えば、仮想口座データベースＤＢ４には、仮想口座に関する仮想口座情報と、当該仮想口座に関連付けられた親口座に関する親口座情報と、が格納される。仮想口座データベースＤＢ４には、仮想口座に関する何らかの情報が格納されるようにすればよく、仮想口座データベースＤＢ４に格納される情報は、図１０の例に限られない。例えば、仮想口座を開設したユーザのユーザＩＤが仮想口座データベースＤＢ４に格納されてもよい。
【0082】
例えば、仮想口座情報は、仮想口座の金融機関コード、金融機関名、支店コード、支店名、口座種別、口座番号、及び名義人の全部又は一部を示す。親口座情報は、親口座の金融機関コード、金融機関名、支店コード、支店名、口座種別、口座番号、及び名義人の全部又は一部を示す。ユーザが仮想口座を開設すると、仮想口座開設部３０１は、当該仮想口座の仮想口座情報を生成して、親口座情報と関連付けて仮想口座データベースＤＢ４に格納する。１つの親口座は、少なくとも１つの仮想口座と関連付けられる。仮想口座データベースＤＢ４における仮想口座情報及び親口座情報によって、親口座及び仮想口座の関連付けが定義される。
【0083】
［仮想口座開設部］
仮想口座開設部３０１は、ユーザの仮想口座を開設する。例えば、仮想口座開設部３０１は、ユーザ端末４０から所定の要求（第１実施形態では、図３の流れにおける要求）を受け付けた場合に、仮想口座を開設する。仮想口座の開設方法自体は、公知の方法であってよい。仮想口座開設部３０１は、あるユーザの仮想口座の口座番号を、他の口座の口座番号と重複しないように発行する。仮想口座開設部３０１は、仮想口座を発行すると、仮想口座データベースＤＢ４を更新する。
仮想口座開設部３０１は、ユーザの仮想口座を開設する。例えば、仮想口座開設部３０１は、ユーザ端末４０から所定の要求（第１実施形態では、図３の流れにおける要求）を受け付けた場合に、仮想口座を開設する。仮想口座の開設方法自体は、公知の方法であってよい。仮想口座開設部３０１は、あるユーザの仮想口座の口座番号を、他の口座の口座番号と重複しないように発行する。仮想口座開設部３０１は、仮想口座を発行すると、仮想口座データベースＤＢ４を更新する。
【0084】
［振込受付部］
振込受付部３０２は、勤務先システム２から、振込の依頼を受け付ける。例えば、振込受付部３０２は、勤務先システム２から、ＦＢデータを受信することによって、振込の依頼を受け付ける。振込受付部３０２は、勤務先システム２以外の他のシステム又はＡＴＭ等から、振込の依頼を受け付けてもよい。
振込受付部３０２は、勤務先システム２から、振込の依頼を受け付ける。例えば、振込受付部３０２は、勤務先システム２から、ＦＢデータを受信することによって、振込の依頼を受け付ける。振込受付部３０２は、勤務先システム２以外の他のシステム又はＡＴＭ等から、振込の依頼を受け付けてもよい。
【0085】
［振込情報送信部］
振込情報送信部３０３は、入金システム１に対し、振込情報を送信する。例えば、振込情報送信部３０３は、入金システム１から振込情報の要求を受け付けると、振込データベースＤＢ３に基づいて、振込情報を生成する。振込情報送信部３０３は、振込データベースＤＢ３に格納されたＦＢデータの全部又は一部に基づいて、振込情報を生成する。振込情報送信部３０３は、入金システム１に対し、振込情報を送信する。
振込情報送信部３０３は、入金システム１に対し、振込情報を送信する。例えば、振込情報送信部３０３は、入金システム１から振込情報の要求を受け付けると、振込データベースＤＢ３に基づいて、振込情報を生成する。振込情報送信部３０３は、振込データベースＤＢ３に格納されたＦＢデータの全部又は一部に基づいて、振込情報を生成する。振込情報送信部３０３は、入金システム１に対し、振込情報を送信する。
【0086】
［１－３－４．ユーザ端末で実現される機能］
ユーザ端末４０は、データ記憶部４００、表示制御部４０１、及び操作受付部４０２を含む。データ記憶部４００は、記憶部４２により実現される。表示制御部４０１及び操作受付部４０２は、制御部４１により実現される。
ユーザ端末４０は、データ記憶部４００、表示制御部４０１、及び操作受付部４０２を含む。データ記憶部４００は、記憶部４２により実現される。表示制御部４０１及び操作受付部４０２は、制御部４１により実現される。
【0087】
[データ記憶部]
データ記憶部４００は、給与デジタル払いの手続きに必要なデータを記憶する。例えば、データ記憶部４００は、決済アプリ画面ＳＣ１等の各画面を表示するための決済アプリ又はブラウザを記憶する。
データ記憶部４００は、給与デジタル払いの手続きに必要なデータを記憶する。例えば、データ記憶部４００は、決済アプリ画面ＳＣ１等の各画面を表示するための決済アプリ又はブラウザを記憶する。
【0088】
［表示制御部］
表示制御部４０１は、データ記憶部４００に記憶された決済アプリ又はブラウザに基づいて、決済アプリ画面ＳＣ１等の各画面を表示部４５に表示させる。
表示制御部４０１は、データ記憶部４００に記憶された決済アプリ又はブラウザに基づいて、決済アプリ画面ＳＣ１等の各画面を表示部４５に表示させる。
【0089】
［操作受付部］
操作受付部４０２は、表示制御部４０１が表示させた各種画面に対する操作を受け付ける。
操作受付部４０２は、表示制御部４０１が表示させた各種画面に対する操作を受け付ける。
【0090】
［１－４．第１実施形態の入金システムで実行される処理］
図１１及び図１２は、第１実施形態の入金システム１で実行される処理の一例を示す図である。図１１及び図１２では、勤務先システム２、金融機関システム３、及びユーザ端末４０の各々で実行される処理の一例も示されている。図１１及び図１２の処理は、制御部１１，２１，３１，４１がそれぞれ記憶部１２，２２，３２，４２に記憶されたプログラムに従って動作することによって実行される。
図１１及び図１２は、第１実施形態の入金システム１で実行される処理の一例を示す図である。図１１及び図１２では、勤務先システム２、金融機関システム３、及びユーザ端末４０の各々で実行される処理の一例も示されている。図１１及び図１２の処理は、制御部１１，２１，３１，４１がそれぞれ記憶部１２，２２，３２，４２に記憶されたプログラムに従って動作することによって実行される。
【0091】
図１１のように、ユーザ端末４０は、決済アプリを起動して、金融機関サーバ３０との間で、ユーザの仮想口座を開設するための処理を実行する（Ｓ１００）。Ｓ１００における処理は、図３を参照して説明した通りである。なお、金融機関は、複数の仮想口座を事前に電子マネー事業者に付与してもよい。この場合、ユーザが決済アプリで仮想口座の開設を申請すると、入金サーバ１０が当該ユーザに仮想口座を割り当ててもよい。口座開設の処理は、入金サーバ１０を介して金融機関サーバ３０との間で実行されてもよい。
【0092】
Ｓ１００でユーザの仮想口座が開設されると、電子マネーデータベースＤＢ１及び仮想口座データベースＤＢ４に、当該仮想口座の情報が登録される。ユーザ端末４０は、入金サーバ１０との間で、指定口座を登録するための処理を実行する（Ｓ１０１）。Ｓ１０１における処理は、図４を参照して説明した通りである。ユーザの指定口座の情報は、電子マネーデータベースＤＢ１に登録される。ユーザが勤務先で振込先の申請を行うと、勤務先における振込の担当者は、勤務先端末２４を操作して、振込データベースＤＢ３に振込先情報を登録する。
【0093】
勤務先サーバ２０は、勤務先における給与又は賞与の振込日が近づくと、勤務先データベースＤＢ２に基づいて、ＦＢデータを生成する（Ｓ１０２）。勤務先の担当者は、予め給与又は賞与の内容を、事前に振込データベースＤＢ３に登録するものとする。担当者は、立替金等の総合振込に該当する内容も、事前に振込データベースＤＢ３に登録する。勤務先サーバ２０は、金融機関サーバ３０に対し、ＦＢデータを送信する（Ｓ１０３）。金融機関サーバ３０は、勤務先サーバ２０から、ＦＢデータを受信して振込を実行する（Ｓ１０４）。Ｓ１０４では、振込データベースＤＢ３が更新される。ユーザの仮想口座に対する振込における現金は、ひとまず親口座に入金される。
【0094】
入金サーバ１０は、金融機関サーバ３０に対し、ＡＰＩを利用して振込情報を要求する（Ｓ１０５）。金融機関サーバ３０は、種々の振込を取り扱うので、入金サーバ１０は、「ＡＡＡキャッシュ支店」の仮想口座に対する振込の振込情報を要求する。金融機関サーバ３０は、入金サーバ１０の要求を受け付けると（Ｓ１０６）、振込データベースＤＢ３に基づいて、振込情報を生成する（Ｓ１０７）。金融機関サーバ３０は、入金サーバ１０に対し、振込情報を送信する（Ｓ１０８）。入金サーバ１０は、金融機関サーバ３０から、振込情報を受信する（Ｓ１０９）。複数のユーザが給与デジタル払いを希望する場合には、入金サーバ１０は、Ｓ１０９で複数のユーザの各々の振込情報を受信する。
【0095】
入金サーバ１０は、振込情報が示す振込種別に基づいて、電子マネーに対する入金の要否を判定する（Ｓ１１０）。電子マネーに対する入金が必要である（振込種別が給与振込又は賞与振込である）と判定された場合（Ｓ１１０：必要）、入金サーバ１０は、電子マネーデータベースＤＢ１に基づいて、ユーザの給与残高が上限値を超えるか否かを判定する（Ｓ１１１）。ユーザの給与残高が上限値を超えると判定されない場合（Ｓ１１１：Ｎ）、入金サーバ１０は、電子マネーデータベースＤＢ１に基づいて、振込金額の全て給与残高に入金されるように、電子マネーに対する入金を実行し（Ｓ１１２）、後述のＳ１１６の処理に移行する。入金の原資は、金融機関における親口座の残高なので、Ｓ１１２の処理は、入金サーバ１０が金融機関サーバ３０と連携することによって、実行される。
【0096】
Ｓ１１１において、ユーザの給与残高が上限値を超えると判定された場合（Ｓ１１１：Ｙ）、図１２に移り、入金サーバ１０は、電子マネーデータベースＤＢ１に基づいて、振込金額の一部だけが入金されるように、電子マネーに対する入金を実行する（Ｓ１１３）。入金の原資は、金融機関における親口座の残高なので、Ｓ１１３の処理は、入金サーバ１０が金融機関サーバ３０と連携することによって、実行される。入金サーバ１０は、電子マネーデータベースＤＢ１を参照して指定口座を特定し、上限値を超えた分が指定口座に振り込まれるように、振込を実行する（Ｓ１１４）。振込の原資は、金融機関における親口座の残高なので、Ｓ１１４の処理は、入金サーバ１０が金融機関サーバ３０と連携することによって、実行される。なお、Ｓ１１１の時点でユーザの給与残高が上限値に達していた場合には、Ｓ１１３の処理は実行されず、振込金額の全額について、Ｓ１１４の処理における振込が実行される。
【0097】
Ｓ１１０において、電子マネーに対する入金が不要であると判定された場合（Ｓ１１０：Ｎ）、入金サーバ１０は、電子マネーデータベースＤＢ１を参照して指定口座を特定し、振込における振込金額の全てが指定口座に振り込まれるように、振込を実行する（Ｓ１１５）。振込の原資は、金融機関における親口座の残高なので、Ｓ１１５の処理は、入金サーバ１０が金融機関サーバ３０と連携することによって、実行される。入金サーバ１０は、まだ処理されていない振込が存在するか否かを判定する（Ｓ１１６）。まだ処理されていない振込が存在すると判定された場合（Ｓ１１６：Ｙ）、Ｓ１１０の処理に戻る。まだ処理されていない振込が存在しないと判定された場合（Ｓ１１６：Ｎ）、本処理は、終了する。
【0098】
［１－５．第１実施形態のまとめ］
第１実施形態の入金システム１は、振込情報が示す振込種別に基づいて、電子マネーに対する入金の要否を判定する。入金システム１は、入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。これにより、入金システム１は、電子マネーに対し、適切な入金を実行できる。例えば、入金システム１は、電子マネーに対する入金が不適切な振込種別の場合には、入金が不要と判定することによって、不適切な入金が実行されることを防止できる。入金システム１は、電子マネーに対する入金が適切な振込種別の場合には、入金が必要と判定することによって、適切な入金を実行できる。
第１実施形態の入金システム１は、振込情報が示す振込種別に基づいて、電子マネーに対する入金の要否を判定する。入金システム１は、入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。これにより、入金システム１は、電子マネーに対し、適切な入金を実行できる。例えば、入金システム１は、電子マネーに対する入金が不適切な振込種別の場合には、入金が不要と判定することによって、不適切な入金が実行されることを防止できる。入金システム１は、電子マネーに対する入金が適切な振込種別の場合には、入金が必要と判定することによって、適切な入金を実行できる。
【0099】
また、入金システム１は、金融機関システム３から、振込情報を取得する。入金システム１は、入金が必要と判定された場合に、入金を実行する。これにより、入金システム１は、仮想口座の仕組みを利用して、電子マネーに対する適切な入金を実行する仕組みを実現できる。例えば、電子マネー事業者は、電子マネーに対する入金前の資金を、親口座で安全に管理できる。
【0100】
また、入金システム１は、入金が必要と判定された場合に、電子マネーを取り扱う電子マネー事業者が名義人であり、かつ、複数のユーザに共通の親口座の残高に基づいて、入金を実行する。これにより、電子マネー事業者が、ユーザの勤務先からの振込を、自身が名義人の親口座で管理できる。例えば、電子マネー事業者は、給与デジタル払いの対象となる資金を管理しやすくなる。
【0101】
また、入金システム１は、振込種別が給与振込又は賞与振込を示さない場合には、入金が不要であると判定する。入金システム１は、振込種別が給与振込又は賞与振込を示す場合に、入金が必要であると判定する。これにより、入金システム１は、ユーザの電子マネーに対し、給与と非給与を区別することによって、給与デジタル払いにおける適切な入金を実行できる。例えば、入金システム１は、給与残高に対し、給与以外の入金が発生することを防止できる。入金システム１は、給与残高以外の他の残高（例えば、出金できない基本型残高）に対し、給与の入金が発生することを防止できる。
【0102】
また、入金システム１は、入金が必要であると判定した場合は、給与残高及び非給与残高のうち、給与残高に前記入金を実行する。これにより、ユーザは、給与残高と、非給与残高と、を区別して管理できるので、ユーザの利便性が高まる。例えば、ユーザ端末４０が給与残高及び非給与残高を区別して表示させる場合には、ユーザは、給与残高及び非給与残高を管理しやすくなる。
【0103】
また、入金システム１は、入金が不要であると判定された場合に、ユーザにより指定された指定口座に対し、振込における振込金額の一部もしくは全部を振り込むための指定口座振込処理を実行する。これにより、入金システム１は、ユーザが受け取るべき資金を、指定口座によってユーザに受け取らせることができる。例えば、入金システム１は、振込における非給与の部分を事前に排除できる。入金システム１は、振込種別が給与振込又は賞与振込であるものだけに対し、確実に電子マネーとして入金できる。例えば、ＡＴＭで給与の振込が行われる場合、勤務先の担当者は、振込種別を選択できない。このため、ＡＴＭから行われた給与の振込が、一律に「非給与（総合）」の扱いになることがある。この場合、非給与として電子マネーが付与されると、本来は給与であるべきものに対して適切な管理ができなくなる可能性がある。そこで、入金システム１は、非給与に基づく電子マネーを付与せずにユーザの指定口座に振り込む。入金システム１は、給与に基づく電子マネーを付与する仕組みを提供することによって、より適切な電子マネーの管理が可能になる。
【0104】
また、入金システム１は、入金が必要と判定された場合に、入金により残高が上限値を超えるか否かを判定する。入金システム１は、残高が上限値を超えないと判定された場合に、振込における振込金額が電子マネーに入金されるように、入金を実行する。これにより、入金システム１は、電子マネーの給与残高に制限を設けることができる。例えば、入金システム１は、政府又は行政等が定めたルール以上の給与残高にならないようにすることができる。電子マネー事業者が保証すべき保証額が給与残高の上限値によって決まる場合には、入金システム１は、適切な補償額となるような上限値にすることによって、保証額を適切な額にすることができる。
【0105】
また、入金システム１は、給与残高が上限値を超えると判定された場合に、電子マネーの現在の給与残高と、上限値と、の差額に基づいて、入金を実行する。入金システム１は、ユーザにより指定された指定口座に対し、振込金額のうち、上限値を超えた分を振り込むための指定口座振込処理を実行する。これにより、ユーザが上限値を超えた分を受け取れないといったことを防止できる。例えば、入金システム１は、給与の限度額を適切に管理できる。
【0106】
［２．第２実施形態］
第１実施形態では、入金システム１が、ユーザの仮想口座を利用して、給与デジタル払いを実現する場合を例に挙げた。給与デジタル払いの実現方法は、第１実施形態の例に限られない。入金システム１は、他の方法によって、給与デジタル払いを実現してもよい。第２実施形態では、入金システム１が、金融系のソフトウェアを開発するベンダーのベンダーシステムと協力して、給与デジタル払いを実現する場合を例に挙げる。ベンダーは、電子マネーを取り扱う電子マネー事業者と提携する企業である。なお、第２実施形態では、第１実施形態と同様の構成については、説明を省略する。
第１実施形態では、入金システム１が、ユーザの仮想口座を利用して、給与デジタル払いを実現する場合を例に挙げた。給与デジタル払いの実現方法は、第１実施形態の例に限られない。入金システム１は、他の方法によって、給与デジタル払いを実現してもよい。第２実施形態では、入金システム１が、金融系のソフトウェアを開発するベンダーのベンダーシステムと協力して、給与デジタル払いを実現する場合を例に挙げる。ベンダーは、電子マネーを取り扱う電子マネー事業者と提携する企業である。なお、第２実施形態では、第１実施形態と同様の構成については、説明を省略する。
【0107】
図１３は、第２実施形態におけるシステム構成の一例を示す図である。図１３のように、第２実施形態では、入金システム１は、ネットワークＮを介して、ベンダーシステム５と通信可能に接続される。例えば、ベンダーシステム５は、ベンダーサーバ５０を含む。なお、ベンダーシステム５は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。この点は、入金システム１と同様である。
【0108】
例えば、ベンダーサーバ５０は、ベンダーのサーバコンピュータである。ベンダーサーバ５０は、制御部５１、記憶部５２、及び通信部５３を含む。制御部５１、記憶部５２、及び通信部５３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。なお、記憶部５２に記憶されるプログラムは、ネットワークＮ又は情報記憶媒体を介して、ベンダーサーバ５０に提供されてもよい。
【0109】
［２－１．第２実施形態における入金システムの概要］
図１４は、第２実施形態におけるにおける入金システム１の概要の一例を示す図である。第２実施形態では、ユーザに対する振込における口座番号は、ベンダーにより発行されたベンダー発行番号である。ベンダー発行番号は、バーチャル口座番号といった他の名称で呼ばれることもある。ベンダー発行番号は、あくまで振込のための番号である。ベンダー発行番号が発行されたからといって、金融機関に口座が開設されるわけではない。
図１４は、第２実施形態におけるにおける入金システム１の概要の一例を示す図である。第２実施形態では、ユーザに対する振込における口座番号は、ベンダーにより発行されたベンダー発行番号である。ベンダー発行番号は、バーチャル口座番号といった他の名称で呼ばれることもある。ベンダー発行番号は、あくまで振込のための番号である。ベンダー発行番号が発行されたからといって、金融機関に口座が開設されるわけではない。
【0110】
例えば、ベンダー発行番号は、金融機関における口座と同様の番号体系である。ベンダー発行番号は、金融機関コードに相当するコード、支店コードに相当するコード、及び口座番号に相当する番号を含む。これらの桁数も、金融機関における口座と同様である。ベンダー発行番号の一部の桁によって、ベンダー発行番号であることを特定できるようになっている。なお、ベンダー発行番号は、金融機関における口座とは異なる番号体系であってもよい。ベンダー発行番号自体は、公知の番号であってよい。
【0111】
第２実施形態における全体的な流れは、第１実施形態における全体的な流れと概ね同様である。ただし、第２実施形態における全体的な流れは、仮想口座の口座番号の代わりにベンダー発行番号が利用される点で、第１実施形態における全体的な流れと異なる。例えば、ユーザは、ユーザ端末４０を操作して、金融機関サーバ３０ではなくベンダーサーバ５０にアクセスし、自身のベンダー発行番号を発行する。ベンダー発行番号の発行の流れは、図３と同様の流れであってよく、金融機関サーバ３０が仮想口座の口座番号を発行する処理を、ベンダーサーバ５０がベンダー発行番号を発行する処理に読み替えればよい。
【0112】
なお、ベンダーサーバ５０がベンダー発行番号を発行するための処理は、公知の処理を利用可能である。ベンダーサーバ５０は、あるユーザのユーザ端末４０から、ベンダー発行番号を発行するための要求を受け付けると、他のユーザのベンダー発行番号と重複しないように、ベンダー発行番号を発行する。ベンダーサーバ５０は、ユーザ端末４０に対し、当該発行されたベンダー発行番号を送信する。ベンダーサーバ５０は、勤務先システム２に対し、ユーザの社員番号等のユーザ識別情報とともに、当該発行されたベンダー発行番号を送信してもよい。
【0113】
例えば、ベンダー発行番号を利用した給与デジタル払いを実現するには、ユーザの電子マネーに対する入金の原資が必要である。第２実施形態では、電子マネー事業者が、金融機関に、当該原資をプールするための口座を開設しているものとする。以降、当該口座を、ベンダー関連口座という。給与デジタル払いを希望する複数のユーザが勤務先に存在する場合、ベンダー関連口座は、当該複数のユーザで共通である。例えば、ベンダー関連口座の名義人は、電子マネー事業者である。ベンダー関連口座は、複数の勤務先で共通であってもよいし、勤務先ごとにベンダー関連口座が開設されてもよい。
【0114】
例えば、ユーザは、自身のベンダー発行番号を発行すると、勤務先に振込先の申請を行う。勤務先における給与振込の担当者は、勤務先端末２４を操作して、ユーザのベンダー発行番号を、勤務先サーバ２０に登録する。勤務先サーバ２０は、給与日又は賞与日等の振込のタイミングが近づくと、第１実施形態と同様にしてＦＢデータを生成する。第２実施形態のＦＢデータには、仮想口座の口座番号の代わりにベンダー発行番号が含まれる。
【0115】
例えば、金融機関サーバ３０は、勤務先の全従業員のＦＢデータのうち、金融機関分のＦＢデータを取得する。入金サーバ１０及び金融機関サーバ３０の間の連携は、第１実施形態と同様であってよいので、図１４では省略している。ベンダーサーバ５０は、勤務先の全従業員のＦＢデータのうち、ベンダー発行番号が指定された分のＦＢデータを取得する。入金サーバ１０は、ＡＰＩを利用して、ベンダーサーバ５０に対し、振込情報を要求する。ベンダーサーバ５０は、入金サーバ１０からの要求を受け付けると、ＦＢデータに基づいて、振込情報を生成する。ベンダーサーバ５０は、入金サーバ１０に対し、振込情報を送信する。
【0116】
以降の処理は、第１実施形態と同様であってもよいが、第２実施形態では、入金サーバ１０は、エラーが発生するか否かを事前にチェックするものとする。例えば、入金サーバ１０は、給与残高の上限値を超えるか否か、又は、総合振込であるか否かといった判定を事前に実行する。入金サーバ１０は、ベンダーサーバ５０に対し、エラーの判定結果を送信する。ベンダーサーバ５０は、入金サーバ１０からエラーの判定結果を受信すると、勤務先システム２にエラーの判定結果を転送する。
【0117】
例えば、勤務先における給与振込の担当者は、必要に応じてＦＢデータを修正する。ＦＢデータが修正された後の流れは、最初にＦＢデータが生成された時の流れと同様である。古いＦＢデータは、破棄される。担当者は、ＦＢデータの修正が不要と考えた場合には、ＦＢデータを修正しない。担当者は、ＦＢデータの修正を忘れることもある。このような場合には、金融機関システム３は、ＦＢデータを受信しないようにしてもよいし、同じＦＢデータを再び受信するようにしてもよい。
【0118】
第２実施形態では、電子マネーを取り扱う電子マネー事業者は、金融機関に自身の口座を開設している。ユーザの勤務先は、電子マネー事業者の口座に対し、デポジットを振り込む。ユーザの勤務先は、デポジットではなく、給与振込が発生するたびに、電子マネー事業者の口座に対し、合計金額を振り込んでもよい。ユーザの電子マネー又は指定口座に対する入金は、電子マネー事業者の口座の残高から行われる。第２実施形態では、以上の流れによって、給与デジタル払いが実現される。
【0119】
［２－２．第２実施形態の入金システムで実現される機能］
図１５は、第２実施形態の入金システム１で実現される機能の一例を示す図である。図１５では、勤務先システム２、ベンダーシステム５、及びユーザ端末４０の各々で実現される機能の一例も示されている。第２実施形態では、第１実施形態と同様の機能については、説明を省略する。
図１５は、第２実施形態の入金システム１で実現される機能の一例を示す図である。図１５では、勤務先システム２、ベンダーシステム５、及びユーザ端末４０の各々で実現される機能の一例も示されている。第２実施形態では、第１実施形態と同様の機能については、説明を省略する。
【0120】
図１５では、金融機関システム３の機能が省略されているが、金融機関システム３は、第１実施形態で説明した機能を有してもよい。即ち、第１実施形態及び第２実施形態が組み合わされてもよい。この場合、ユーザは、仮想口座を開設するか、又は、ベンダー発行番号を発行するかを選択できるようにしてもよい。他にも例えば、ある勤務先は仮想口座の方式（第１実施形態の方式）を利用し、他の勤務先はベンダーの方式（第２実施形態の方式）を利用するといったように、両方の方式が混在してもよい。入金システム１は、両方の方式に対応可能であってよい。
【0121】
［２－２－１．入金システムで実現される機能］
例えば、第２実施形態の入金システム１は、エラー判定部１０６、修正依頼部１０７、デポジット判定部１０８、及び振込判定部１０９を含む。エラー判定部１０６、修正依頼部１０７、デポジット判定部１０８、及び振込判定部１０９の各々は、制御部１１により実現される。
例えば、第２実施形態の入金システム１は、エラー判定部１０６、修正依頼部１０７、デポジット判定部１０８、及び振込判定部１０９を含む。エラー判定部１０６、修正依頼部１０７、デポジット判定部１０８、及び振込判定部１０９の各々は、制御部１１により実現される。
【0122】
［データ記憶部］
第２実施形態では、図７の仮想口座情報に代えて、ベンダー発行番号が電子マネーデータベースＤＢ１に格納される。例えば、ユーザに対してベンダー発行番号が発行されると、入金サーバ１０は、当該ユーザのユーザＩＤに関連付けて、当該ベンダー発行番号を電子マネーデータベースＤＢ１に格納する。電子マネーデータベースＤＢ１の他の構成は、第１実施形態と同様である。第２実施形態のデータ記憶部１００は、個々の勤務先が、後述のデポジットの対象であるか、又は、後述の都度振込の対象であるかを識別可能なデータを記憶してもよい。
第２実施形態では、図７の仮想口座情報に代えて、ベンダー発行番号が電子マネーデータベースＤＢ１に格納される。例えば、ユーザに対してベンダー発行番号が発行されると、入金サーバ１０は、当該ユーザのユーザＩＤに関連付けて、当該ベンダー発行番号を電子マネーデータベースＤＢ１に格納する。電子マネーデータベースＤＢ１の他の構成は、第１実施形態と同様である。第２実施形態のデータ記憶部１００は、個々の勤務先が、後述のデポジットの対象であるか、又は、後述の都度振込の対象であるかを識別可能なデータを記憶してもよい。
【0123】
［振込情報取得部］
第２実施形態の振込情報取得部１０１は、ベンダーのベンダーシステム５から、振込情報を取得する。例えば、ベンダーシステム５は、自発的に、入金システム１に対し、振込情報を送信する。振込情報取得部１０１は、ベンダーシステム５から、当該振込情報を取得する。即ち、振込情報取得部１０１は、ベンダーシステム５に対して自ら振込情報を取得しにいくのではなく、ベンダーシステム５から送信された振込情報を取得してもよい。なお、入金サーバ１０は、ベンダーシステム５に対し、ユーザのベンダー発行番号に対する振込があったか否かを、定期的又は不定期的に問い合わせてもよい。ベンダーシステム５は、入金サーバ１０からの問い合わせを受信すると、後述のベンダーデータベースＤＢ６に基づいて、ユーザのベンダー発行番号に関する振込情報を入金サーバ１０に送信する。
第２実施形態の振込情報取得部１０１は、ベンダーのベンダーシステム５から、振込情報を取得する。例えば、ベンダーシステム５は、自発的に、入金システム１に対し、振込情報を送信する。振込情報取得部１０１は、ベンダーシステム５から、当該振込情報を取得する。即ち、振込情報取得部１０１は、ベンダーシステム５に対して自ら振込情報を取得しにいくのではなく、ベンダーシステム５から送信された振込情報を取得してもよい。なお、入金サーバ１０は、ベンダーシステム５に対し、ユーザのベンダー発行番号に対する振込があったか否かを、定期的又は不定期的に問い合わせてもよい。ベンダーシステム５は、入金サーバ１０からの問い合わせを受信すると、後述のベンダーデータベースＤＢ６に基づいて、ユーザのベンダー発行番号に関する振込情報を入金サーバ１０に送信する。
【0124】
例えば、ベンダーシステム５は、勤務先サーバ２０から振込情報を受け付けて、入金サーバ１０に対し、振込情報を送信する。振込情報取得部１０１は、ベンダーシステム５から、振込情報を取得する。なお、ベンダーシステム５は、勤務先サーバ２０から振込情報を受信していなかった場合、入金サーバ１０に対し、その旨を回答する。
【0125】
例えば、振込情報取得部１０１は、ベンダーシステム５から、振込における予定日よりも前に、振込情報を取得してもよい。予定日は、振込における予約日ということもできる。例えば、給与振込であれば、毎月の２５日である。ＦＢデータには、振込における予定日が指定されているものとする。振込情報取得部１０１は、ベンダーシステム５から、予定日の前日又はそれよりも前の日に、ベンダーシステム５から、振込情報を取得する。振込情報が取得される日時は、予め定められていてもよい。なお、振込情報取得部１０１は、予定日当日に振込情報を取得してもよい。
【0126】
［エラー判定部］
エラー判定部１０６は、予定日よりも前に、振込情報に基づいて、振込に関するエラーが発生するか否かを判定する。エラーに該当するエラー条件は、予め定められていればよい。エラー条件は、振込情報に基づいて判定可能な条件であればよい。例えば、エラー条件は、依頼人名、振込先、振込種別、及び振込金額に基づいて判定可能な条件である。エラー判定部１０６は、振込情報に基づいて、エラー条件が満たされるか否かを判定する。エラー判定部１０６は、エラー条件が満たされると判定されない場合には、エラーが発生しないと判定する。エラー判定部１０６は、エラー条件が満たされると判定された場合には、エラーが発生すると判定する。
エラー判定部１０６は、予定日よりも前に、振込情報に基づいて、振込に関するエラーが発生するか否かを判定する。エラーに該当するエラー条件は、予め定められていればよい。エラー条件は、振込情報に基づいて判定可能な条件であればよい。例えば、エラー条件は、依頼人名、振込先、振込種別、及び振込金額に基づいて判定可能な条件である。エラー判定部１０６は、振込情報に基づいて、エラー条件が満たされるか否かを判定する。エラー判定部１０６は、エラー条件が満たされると判定されない場合には、エラーが発生しないと判定する。エラー判定部１０６は、エラー条件が満たされると判定された場合には、エラーが発生すると判定する。
【0127】
第２実施形態では、エラー条件の一例として、給与残高が上限値を超えることと、振込種別が給与振込又は賞与振込ではないことと、を説明する。即ち、電子マネーに対する入金を実行できない、又は、振込金額の一部しか電子マネーに入金できないことが、エラーに相当する場合を例に挙げる。例えば、エラー判定部１０６は、ユーザの給与残高と、振込における振込金額と、に基づいて、ユーザの給与残高が上限値をすでに超えているか否か、もしくは振込における振込金額を振り込んだら上限値を超えるか否かを判定する。エラー判定部１０６は、ユーザの給与残高が上限値を超えないと判定された場合には、エラーが発生しないと判定する。エラー判定部１０６は、ユーザの給与残高が上限値を超えると判定された場合に、エラーが発生すると判定する。
【0128】
例えば、エラー判定部１０６は、ユーザのベンダー発行番号に対する振込における振込種別が給与振込又は賞与振込であるか否かを判定する。エラー判定部１０６は、当該振込種別が給与振込又は賞与振込であると判定された場合には、エラーが発生しないと判定する。エラー判定部１０６は、当該振込種別が給与振込又は賞与振込ではないと判定された場合には、エラーが発生すると判定する。
【0129】
なお、エラー判定部１０６は、上記判定を組み合わせてもよい。例えば、エラー判定部１０６は、給与残高が上限値を超えず、かつ、振込種別が給与振込又は賞与振込である場合に、エラーが発生しないと判定してもよい。エラー判定部１０６は、給与残高が上限値を超える、又は、振込種別が給与振込若しくは賞与振込ではない場合に、エラーが発生すると判定してもよい。
【0130】
また、エラー条件は、任意の条件であってよく、上記の例に限られない。例えば、エラー条件は、ベンダー発行番号が無効であること、振込金額が閾値以上であること、振込の依頼人名が所定の名前ではないこと、又はその他の条件であってもよい。他にも例えば、エラー条件は、後述のデポジット判定部１０８により判定されるデポジットが足りるか否か、又は、後述の振込判定部１０９により判定される金額が足りるか否かであってもよい。この場合、エラー判定部１０６は、デポジット判定部１０８又は振込判定部１０９と同様の機能を有する。
【0131】
［修正依頼部］
修正依頼部１０７は、エラー判定部１０６によりエラーが発生すると判定された場合に、振込におけるエラーの修正を依頼するための修正依頼処理を実行する。修正依頼処理は、依頼人に対し直接的にもしくは間接的に、振込の詳細を何らかの形で依頼するための処理であればよい。第２実施形態では、入金サーバ１０が所定の通知をベンダーサーバ５０に送信する処理が、修正依頼処理に相当する場合を例に挙げるが、入金サーバ１０が所定の通知を勤務先サーバ２０又は他のコンピュータに送信する処理が、修正依頼処理に相当してもよい。例えば、修正依頼部１０７は、エラー判定部１０６によりエラーが発生すると判定された場合に、ベンダーサーバ５０に対し、エラーの内容を示す通知を送信する。当該通知には、エラーが発生すると判定された振込を識別可能な情報が含まれているものとする。
修正依頼部１０７は、エラー判定部１０６によりエラーが発生すると判定された場合に、振込におけるエラーの修正を依頼するための修正依頼処理を実行する。修正依頼処理は、依頼人に対し直接的にもしくは間接的に、振込の詳細を何らかの形で依頼するための処理であればよい。第２実施形態では、入金サーバ１０が所定の通知をベンダーサーバ５０に送信する処理が、修正依頼処理に相当する場合を例に挙げるが、入金サーバ１０が所定の通知を勤務先サーバ２０又は他のコンピュータに送信する処理が、修正依頼処理に相当してもよい。例えば、修正依頼部１０７は、エラー判定部１０６によりエラーが発生すると判定された場合に、ベンダーサーバ５０に対し、エラーの内容を示す通知を送信する。当該通知には、エラーが発生すると判定された振込を識別可能な情報が含まれているものとする。
【0132】
［デポジット判定部］
例えば、ベンダー関連口座に、振込情報が受け付けられる前に、振込における依頼人によってデポジットが入金される場合、デポジット判定部１０８は、振込情報に基づいて、デポジットが足りるか否かを判定する。デポジットが足りるとは、デポジットの総額が振込における振込金額の合計額以上であることを意味する。デポジット判定部１０８は、金融機関サーバ３０に対し、ベンダー関連口座の残高（デポジットの総額）の照会を要求する。金融機関サーバ３０は、当該照会の要求を受け付けると、入金サーバ１０に対し、ベンダー関連口座の残高を示す情報を送信する。入金サーバ１０は、金融機関サーバ３０から、当該情報を受信する。デポジット判定部１０８は、当該情報が示すデポジットの総額と、今回の振込における振込金額の総額と、を比較することによって、デポジットが足りるか否かを判定する。
例えば、ベンダー関連口座に、振込情報が受け付けられる前に、振込における依頼人によってデポジットが入金される場合、デポジット判定部１０８は、振込情報に基づいて、デポジットが足りるか否かを判定する。デポジットが足りるとは、デポジットの総額が振込における振込金額の合計額以上であることを意味する。デポジット判定部１０８は、金融機関サーバ３０に対し、ベンダー関連口座の残高（デポジットの総額）の照会を要求する。金融機関サーバ３０は、当該照会の要求を受け付けると、入金サーバ１０に対し、ベンダー関連口座の残高を示す情報を送信する。入金サーバ１０は、金融機関サーバ３０から、当該情報を受信する。デポジット判定部１０８は、当該情報が示すデポジットの総額と、今回の振込における振込金額の総額と、を比較することによって、デポジットが足りるか否かを判定する。
【0133】
［振込判定部］
例えば、ベンダー関連口座に、振込情報が受け付けられた後に、振込における依頼人によって振込に応じた金額が振り込まれる場合、振込判定部１０９は、ベンダー関連口座に当該金額が振り込まれたか否かを判定する。振込判定部１０９は、金融機関サーバ３０に対し、ベンダー関連口座に対する明細の照会を要求する。金融機関サーバ３０は、当該照会の要求を受け付けると、入金サーバ１０に対し、ベンダー関連口座の明細を示す情報を送信する。入金サーバ１０は、金融機関サーバ３０から、当該情報を受信する。振込判定部１０９は、当該情報が示す振込の履歴と、今回の振込における振込金額の総額及び依頼人名と、を比較することによって、振込が行われたか否かを判定する。振込判定部１０９は、これらが一致しない場合には、振込が行われたと判定せず、これらが一致する場合に、振込が行われたと判定する。
例えば、ベンダー関連口座に、振込情報が受け付けられた後に、振込における依頼人によって振込に応じた金額が振り込まれる場合、振込判定部１０９は、ベンダー関連口座に当該金額が振り込まれたか否かを判定する。振込判定部１０９は、金融機関サーバ３０に対し、ベンダー関連口座に対する明細の照会を要求する。金融機関サーバ３０は、当該照会の要求を受け付けると、入金サーバ１０に対し、ベンダー関連口座の明細を示す情報を送信する。入金サーバ１０は、金融機関サーバ３０から、当該情報を受信する。振込判定部１０９は、当該情報が示す振込の履歴と、今回の振込における振込金額の総額及び依頼人名と、を比較することによって、振込が行われたか否かを判定する。振込判定部１０９は、これらが一致しない場合には、振込が行われたと判定せず、これらが一致する場合に、振込が行われたと判定する。
【0134】
［入金実行部］
第２実施形態の入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、電子マネーに対する入金を実行する。入金の原資となるのが親口座ではなくベンダー関連口座である点で第１実施形態とは異なるが、他の点は、第１実施形態と同様である。入金実行部１０４は、ベンダー関連口座の残高を原資にして、ユーザの電子マネーに対する入金を実行する。
第２実施形態の入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、電子マネーに対する入金を実行する。入金の原資となるのが親口座ではなくベンダー関連口座である点で第１実施形態とは異なるが、他の点は、第１実施形態と同様である。入金実行部１０４は、ベンダー関連口座の残高を原資にして、ユーザの電子マネーに対する入金を実行する。
【0135】
例えば、入金実行部１０４は、デポジット判定部１０８によりデポジットが足りると判定された場合に、電子マネーに対する入金を実行する。入金実行部１０４は、デポジット判定部１０８によりデポジットが足りると判定されない場合には、当該デポジットに基づく入金を実行しない。
【0136】
例えば、入金実行部１０４は、振込判定部１０９によりベンダー関連口座に金額が振り込まれたと判定された場合に、ベンダー関連口座の残高に基づいて、電子マネーに対する入金を実行する。入金実行部１０４は、振込判定部１０９によりベンダー関連口座に金額が振り込まれたと判定されない場合には、ベンダー関連口座の残高に基づく入金を実行しない。
【0137】
［２－２－２．ベンダーシステムで実現される機能］
例えば、ベンダーサーバ５０は、データ記憶部５００、番号発行部５０１、振込受付部５０２、及び振込情報送信部５０３を含む。データ記憶部５００は、記憶部５２により実現される。番号発行部５０１、振込受付部５０２、及び振込情報送信部５０３は、制御部５１により実現される。
例えば、ベンダーサーバ５０は、データ記憶部５００、番号発行部５０１、振込受付部５０２、及び振込情報送信部５０３を含む。データ記憶部５００は、記憶部５２により実現される。番号発行部５０１、振込受付部５０２、及び振込情報送信部５０３は、制御部５１により実現される。
【0138】
［データ記憶部］
データ記憶部５００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部５００は、振込データベースＤＢ５と、ベンダーデータベースＤＢ６と、を記憶する。振込データベースＤＢ５は、振込データベースＤＢ３と概ね同様の内容のため、図示を省略する。ただし、振込データベースＤＢ５に格納されるＦＢデータの振込先は、第１実施形態のような仮想口座ではなく、ベンダー発行番号である。他の点については、振込データベースＤＢ５は、振込データベースＤＢ３と同様である。
データ記憶部５００は、ユーザに対する振込に必要なデータを記憶する。例えば、データ記憶部５００は、振込データベースＤＢ５と、ベンダーデータベースＤＢ６と、を記憶する。振込データベースＤＢ５は、振込データベースＤＢ３と概ね同様の内容のため、図示を省略する。ただし、振込データベースＤＢ５に格納されるＦＢデータの振込先は、第１実施形態のような仮想口座ではなく、ベンダー発行番号である。他の点については、振込データベースＤＢ５は、振込データベースＤＢ３と同様である。
【0139】
図１６は、ベンダーデータベースＤＢ６の一例を示す図である。ベンダーデータベースＤＢ６は、ベンダーを経由した振込を実現するための各種情報が格納されたデータベースである。例えば、ベンダーデータベースＤＢ６には、ベンダー発行番号、ユーザの氏名、生年月日、及び住所が格納される。ベンダーデータベースＤＢ６には、ベンダー発行番号に関する何らかの情報が格納されるようにすればよく、ベンダーデータベースＤＢ６に格納される情報は、図１６の例に限られない。例えば、勤務先の情報がベンダーデータベースＤＢ６に格納されてもよい。
【0140】
［番号発行部］
番号発行部５０１は、ユーザのベンダー発行番号を発行する。例えば、番号発行部５０１は、ユーザ端末４０から所定の要求を受け付けた場合に、ベンダー発行番号を発行する。ベンダー発行番号の発行方法自体は、公知の方法であってよい。番号発行部５０１は、あるユーザのベンダー発行番号を、他のベンダー発行番号と重複しないように発行する。番号発行部５０１は、ベンダー発行番号を発行すると、当該ベンダー発行番号、ユーザの氏名、生年月日、及び住所をベンダーデータベースＤＢ６に格納する。
番号発行部５０１は、ユーザのベンダー発行番号を発行する。例えば、番号発行部５０１は、ユーザ端末４０から所定の要求を受け付けた場合に、ベンダー発行番号を発行する。ベンダー発行番号の発行方法自体は、公知の方法であってよい。番号発行部５０１は、あるユーザのベンダー発行番号を、他のベンダー発行番号と重複しないように発行する。番号発行部５０１は、ベンダー発行番号を発行すると、当該ベンダー発行番号、ユーザの氏名、生年月日、及び住所をベンダーデータベースＤＢ６に格納する。
【0141】
［振込受付部］
振込受付部５０２は、勤務先システム２から、振込情報を受け付ける。例えば、振込受付部５０２は、勤務先システム２から、ＦＢデータを受信することによって、振込情報を受け付ける。振込受付部５０２は、勤務先システム２以外の他のシステム又はＡＴＭ等から、振込情報を受け付けてもよい。
振込受付部５０２は、勤務先システム２から、振込情報を受け付ける。例えば、振込受付部５０２は、勤務先システム２から、ＦＢデータを受信することによって、振込情報を受け付ける。振込受付部５０２は、勤務先システム２以外の他のシステム又はＡＴＭ等から、振込情報を受け付けてもよい。
【0142】
［振込情報送信部］
振込情報送信部５０３は、入金システム１に対し、振込情報を送信する。例えば、振込情報送信部５０３は、入金システム１から振込情報の要求を受け付けると、ベンダーデータベースＤＢ６に基づいて、振込情報を送信する。振込情報送信部５０３は、振込データベースＤＢ５に格納されたＦＢデータの全部又は一部に基づいて、振込情報を送信する。振込情報送信部５０３は、入金システム１に対し、振込情報を送信する。振込情報送信部５０３は、勤務先システム２から受け付けた振込情報をそのまま送信してもよく、他のフォーマットに変換して送信してもよい。
振込情報送信部５０３は、入金システム１に対し、振込情報を送信する。例えば、振込情報送信部５０３は、入金システム１から振込情報の要求を受け付けると、ベンダーデータベースＤＢ６に基づいて、振込情報を送信する。振込情報送信部５０３は、振込データベースＤＢ５に格納されたＦＢデータの全部又は一部に基づいて、振込情報を送信する。振込情報送信部５０３は、入金システム１に対し、振込情報を送信する。振込情報送信部５０３は、勤務先システム２から受け付けた振込情報をそのまま送信してもよく、他のフォーマットに変換して送信してもよい。
【0143】
［２－３．第２実施形態の入金システムで実行される処理］
図１７及び図１８は、第２実施形態の入金システム１で実行される処理の一例を示す図である。図１７及び図１８では、勤務先システム２、金融機関システム３、ベンダーシステム５、及びユーザ端末４０の各々で実行される処理の一例も示されている。図１７及び図１８の処理は、制御部１１，２１，３１，４１，５１がそれぞれ記憶部１２，２２，３２，４２，５２に記憶されたプログラムに従って動作することによって実行される。
図１７及び図１８は、第２実施形態の入金システム１で実行される処理の一例を示す図である。図１７及び図１８では、勤務先システム２、金融機関システム３、ベンダーシステム５、及びユーザ端末４０の各々で実行される処理の一例も示されている。図１７及び図１８の処理は、制御部１１，２１，３１，４１，５１がそれぞれ記憶部１２，２２，３２，４２，５２に記憶されたプログラムに従って動作することによって実行される。
【0144】
図１７のように、ユーザ端末４０は、決済アプリを起動して、ベンダーサーバ５０との間で、ユーザのベンダー発行番号を発行するための処理を実行する（Ｓ２００）。Ｓ２００でユーザのベンダー発行番号が発行されると、電子マネーデータベースＤＢ１及びベンダーデータベースＤＢ６に、当該ベンダー発行番号の情報が登録される。Ｓ２０１の処理は、Ｓ１０１の処理と同様である。ユーザが勤務先で振込先の申請を行うと、勤務先における振込の担当者は、勤務先端末２４を操作して、勤務先サーバ２０に振込先情報を登録する。
【0145】
勤務先サーバ２０は、ベンダーサーバ５０に対し、ＦＢデータを送信する（Ｓ２０３）。ベンダーサーバ５０は、勤務先サーバ２０から、ＦＢデータを受信してＦＢデータを振込データベースＤＢ５に格納する（Ｓ２０４）。Ｓ２０４では、振込データベースＤＢ５が更新される。入金サーバ１０は、ベンダーサーバ５０に対し、ＡＰＩを利用して振込情報を要求する（Ｓ２０５）。ベンダーサーバ５０は、入金サーバ１０の要求を受け付けると（Ｓ２０６）、振込データベースＤＢ５に基づいて、振込情報を生成する（Ｓ２０７）。ベンダーサーバ５０は、入金サーバ１０に対し、振込情報を送信する（Ｓ２０８）。入金サーバ１０は、ベンダーサーバ５０から、振込情報を受信する（Ｓ２０９）。複数のユーザが給与デジタル払いを希望する場合には、入金サーバ１０は、Ｓ２０９で複数のユーザの各々の振込情報を受信する。
【0146】
入金サーバ１０は、振込情報に基づいて、エラーが発生するか否かを判定する（Ｓ２１０）。エラーが発生すると判定されない場合（Ｓ２１０：Ｎ）、後述のＳ２２３の処理に移行する。Ｓ２１０において、エラーが発生すると判定された場合（Ｓ２１０：Ｙ）、入金サーバ１０は、ベンダーサーバ５０に対し、ＦＢデータの修正を要求する（Ｓ２１１）。ベンダーサーバ５０は、要求を受け付けると（Ｓ２１２）、勤務先サーバ２０に対し、ＦＢデータの修正を要求する（Ｓ２１３）。勤務先サーバ２０は、要求を受け付ける（Ｓ２１４）。
【0147】
図１８に移り、勤務先サーバ２０は、勤務先における担当者がＦＢデータの修正を受け付ける（Ｓ２１５）。勤務先サーバ２０は、ベンダーサーバ５０に対し、修正後のＦＢデータを送信する（Ｓ２１６）。ベンダーサーバ５０は、勤務先サーバ２０から、修正後のＦＢデータを受信する（Ｓ２１７）。続くＳ２１８～Ｓ２２２は、それぞれＳ２０５～Ｓ２０９と同様である。その後のＳ２２３～Ｓ２２９は、それぞれＳ１１０～Ｓ１１６と同様である。なお、振込データベースＤＢ５に基づいて、振込情報が生成されるタイミングは、上記の例に限られない。当該タイミングは、他の適宜なタイミングでもよい。例えば、エラー判定やエラー修正等が終わった後に、振込情報が生成されるようにしてもよい。
【0148】
［２－４．第２実施形態のまとめ］
第２実施形態の入金システム１は、ベンダーシステム５から、振込情報を取得する。入金システム１は、電子マネーに対する入金が必要と判定された場合に、ベンダー発行番号に関連付けられたベンダー関連口座の残高に基づいて、入金を実行する。これにより、入金システム１は、ベンダー発行番号の仕組みを利用して、電子マネーに対する適切な入金を実行する仕組みを実現できる。例えば、金融機関に仮想口座を開設するのに抵抗があるユーザは、ベンダー発行番号の方式を利用して、電子マネーによって給与又は賞与を受け取ることができる。
第２実施形態の入金システム１は、ベンダーシステム５から、振込情報を取得する。入金システム１は、電子マネーに対する入金が必要と判定された場合に、ベンダー発行番号に関連付けられたベンダー関連口座の残高に基づいて、入金を実行する。これにより、入金システム１は、ベンダー発行番号の仕組みを利用して、電子マネーに対する適切な入金を実行する仕組みを実現できる。例えば、金融機関に仮想口座を開設するのに抵抗があるユーザは、ベンダー発行番号の方式を利用して、電子マネーによって給与又は賞与を受け取ることができる。
【0149】
また、入金システム１は、ベンダーシステム５から、振込における予定日よりも前に、振込情報を取得する。入金システム１は、予定日よりも前に、振込情報に基づいて、振込に関するエラーが発生するか否かを判定する。入金システム１は、エラーが発生すると判定された場合に、振込におけるエラーの修正を依頼するための修正依頼処理を実行する。修正依頼処理によって、エラーが発生しにくくなる。
【0150】
また、入金システム１は、振込情報に基づいて、デポジットが足りるか否かを判定する。入金システム１は、デポジットが足りると判定された場合に、入金を実行する。入金システム１は、電子マネーに対する入金の原資が不足することを防止できる。
【0151】
また、入金システム１は、ベンダー関連口座に金額が振り込まれたか否かを判定する。入金システム１は、ベンダー関連口座に金額が振り込まれたと判定された場合に、入金を実行する。入金システム１は、電子マネーに対する入金の原資が不足することを防止できる。
【0152】
［３．変形例］
なお、本開示は、以上に説明した実施形態に限定されない。本開示は、本開示の趣旨を逸脱しない範囲で、適宜変更可能である。以降の変形例では、第１実施形態の方式によって変形例における給与デジタル払いが実現される場合を例に挙げるが、第２実施形態の方式によって変形例における給与デジタル払いが実現されてもよい。
なお、本開示は、以上に説明した実施形態に限定されない。本開示は、本開示の趣旨を逸脱しない範囲で、適宜変更可能である。以降の変形例では、第１実施形態の方式によって変形例における給与デジタル払いが実現される場合を例に挙げるが、第２実施形態の方式によって変形例における給与デジタル払いが実現されてもよい。
【0153】
図１９は、変形例における機能の一例を示す図である。図１９のように、入金サーバ１０は、第１通知部１１０、表示制御部１１１、第２通知部１１２、設定受付部１１３、第３通知部１１４、及び適切額提示部１１５を含む。第１通知部１１０、表示制御部１１１、第２通知部１１２、設定受付部１１３、第３通知部１１４、及び適切額提示部１１５の各々は、制御部１１により実現される。
【0154】
［３－１．変形例１］
例えば、ユーザの指定口座に対する振込が実行される場合、ユーザは、電子マネーに入金されていないので、自身の給与等を受け取っていないと勘違いする可能性がある。このため、ユーザに対し、ユーザの指定口座に対する振込が実行された旨が通知されてもよい。変形例１の入金システム１は、第１通知部１１０を含む。第１通知部１１０は、指定口座振込処理が実行される場合に、ユーザに対し、指定口座振込処理の実行に関する通知を行う。
例えば、ユーザの指定口座に対する振込が実行される場合、ユーザは、電子マネーに入金されていないので、自身の給与等を受け取っていないと勘違いする可能性がある。このため、ユーザに対し、ユーザの指定口座に対する振込が実行された旨が通知されてもよい。変形例１の入金システム１は、第１通知部１１０を含む。第１通知部１１０は、指定口座振込処理が実行される場合に、ユーザに対し、指定口座振込処理の実行に関する通知を行う。
【0155】
図２０は、指定口座振込処理の実行に関する通知の一例を示す図である。例えば、第１通知部１１０は、指定口座振込処理が実行されたことを示すメッセージＭ１７を決済アプリの決済アプリ画面ＳＣ１に表示させることによって、通知を行う。第１通知部１１０は、任意の通知手段に基づいて、ユーザに対する通知を行ってよい。例えば、第１通知部１１０は、決済アプリ内の通知機能、電子メール、ＳＭＳ、プッシュ通知、バナー通知、又はその他の通知手段に基づいて、ユーザに対する通知を行ってもよい。
【0156】
例えば、第１通知部１１０は、指定口座振込処理が実行されたか否かを判定する。第１通知部１１０は、指定口座振込処理が実行されたと判定された場合に、ユーザに対する通知を行う。通知に必要なデータは、データ記憶部１００に記憶されているものとする。通知は、任意の情報を含むことができる。例えば、通知は、指定口座振込処理が実行されたことを示す情報以外にも、振込における依頼人名、振込日時、振込金額、又はこれらの組み合わせを含んでもよい。通知は、公知の金融系のアプリ又はウェブサイトでユーザが閲覧可能な情報と同様の情報を含んでもよい。
【0157】
変形例１の入金システム１は、指定口座振込処理が実行される場合に、ユーザに対し、指定口座振込処理の実行に関する通知を行う。これにより、ユーザは、指定口座振込処理が実行されたことに気付くことができる。例えば、給与デジタル払いで自身の給与が支払われたにもかかわらず、電子マネーの給与残高が増えておらず、給与の支払が行われなかったとユーザが勘違いすることを防止できる。ユーザは、指定口座に対する振込によって、自身の給与が支払われたことに気付くことができる。
【0158】
［３－２．変形例２］
例えば、指定口座振込処理が実行された場合に、変形例１のような通知ではなく、電子マネーの残高を管理するための残高管理画面に、指定口座振込処理が実行されたことが表示されてもよい。変形例２の入金システム１は、表示制御部１１１を含む。表示制御部１１１は、指定口座振込処理が実行された場合に、決済手段の残高を管理するための残高管理画面に、指定口座振込処理が実行されたことを表示させる。
例えば、指定口座振込処理が実行された場合に、変形例１のような通知ではなく、電子マネーの残高を管理するための残高管理画面に、指定口座振込処理が実行されたことが表示されてもよい。変形例２の入金システム１は、表示制御部１１１を含む。表示制御部１１１は、指定口座振込処理が実行された場合に、決済手段の残高を管理するための残高管理画面に、指定口座振込処理が実行されたことを表示させる。
【0159】
図２１は、残高管理画面の一例を示す図である。変形例２では、ユーザが決済アプリ画面ＳＣ１のボタンＢ１２を選択すると、残高管理画面ＳＣ３が表示される場合を例に挙げるが、残高管理画面ＳＣ３は、他の操作が行われた場合に表示されてもよい。残高管理画面ＳＣ３は、ユーザが残高管理画面ＳＣ３を表示させるための操作を行った場合に表示されるようにすればよい。残高管理画面ＳＣ３の表示に必要なデータは、データ記憶部１００に記憶されているものとする。例えば、ユーザの指定口座に対する入金の履歴を示すデータが、電子マネーデータベースＤＢ１又は他のデータベースに格納されている。入金サーバ１０は、ユーザの指定口座に対する振込が実行された場合に、金融機関サーバ３０から当該振込の実行の履歴を示すデータを取得して、当該データをデータ記憶部１００に記録する。
【0160】
例えば、ユーザ端末４０は、ユーザがボタンＢ１２を選択すると、入金サーバ１０に対し、残高管理画面ＳＣ３の表示要求を送信する。入金サーバ１０は、ユーザ端末４０から、残高管理画面ＳＣ３の表示要求を受信する。表示制御部１１１は、電子マネーデータベースＤＢ１を参照し、ユーザの電子マネーの残高情報及び利用履歴を取得する。変形例２では、電子マネーの利用履歴の一部として、指定口座振込処理の実行結果が示されるものとする。
【0161】
例えば、表示制御部１１１は、電子マネーの残高情報及び利用履歴に基づいて、残高管理画面ＳＣ３の表示データを生成する。表示データは、ユーザ端末４０に何らかの画面を表示させるために必要なデータであればよく、任意のデータ形式であってよい。例えば、表示データは、ＨＴＭＬデータ又は画像データであってもよい。図２１の例では、表示制御部１１１は、利用履歴として、指定口座振込処理が実行されたことを示す残高管理画面ＳＣ３の表示データを生成する。表示制御部１１１は、ユーザ端末４０に対し、当該生成された表示データを送信する。ユーザ端末４０は、表示データを受信すると、当該表示データに基づいて、残高管理画面ＳＣ３を表示部４５に表示させる。
【0162】
変形例２の入金システム１は、指定口座振込処理が実行された場合に、残高管理画面ＳＣ３に、指定口座振込処理が実行されたことを表示させる。これにより、ユーザは、指定口座振込処理が実行されたことに気付くことができる。例えば、給与デジタル払いで自身の給与が支払われたにもかかわらず、電子マネーの給与残高が増えておらず、給与の支払が行われなかったとユーザが勘違いすることを防止できる。ユーザは、指定口座に対する振込によって、自身の給与が支払われたことに気付くことができる。例えば、電子マネーとして入金されないが、残高管理画面ＳＣ３において、ひとまず入金されてから出金されたように表示されてもよく、この場合には、ユーザの利便性が更に向上する。
【0163】
［３－３．変形例３］
例えば、電子マネーの給与残高が上限値に達したまま、ユーザが給与残高を利用しない場合には、その後のユーザの給与は、指定口座に振り込まれる。ユーザの給与が何度も指定口座に振り込まれた場合には、給与デジタル払いの意味合いが薄れてしまうので、ユーザの給与の振込先を見直すように促されてもよい。変形例３の入金システム１は、第２通知部１１２を含む。第２通知部１１２は、指定口座振込処理の実行結果に基づいて、振込における依頼人に対し、入金が不要と判定される種別の振込を行わないように促す通知を行う。
例えば、電子マネーの給与残高が上限値に達したまま、ユーザが給与残高を利用しない場合には、その後のユーザの給与は、指定口座に振り込まれる。ユーザの給与が何度も指定口座に振り込まれた場合には、給与デジタル払いの意味合いが薄れてしまうので、ユーザの給与の振込先を見直すように促されてもよい。変形例３の入金システム１は、第２通知部１１２を含む。第２通知部１１２は、指定口座振込処理の実行結果に基づいて、振込における依頼人に対し、入金が不要と判定される種別の振込を行わないように促す通知を行う。
【0164】
図２２は、振込における依頼人に対する通知の一例を示す図である。変形例３では、依頼人は、ユーザの勤務先である。給与デジタル払い以外の場面に入金システム１が適用される場合には、依頼人は、勤務先以外の他の者であってよい。例えば、依頼人は、ユーザの家族、友人、生徒、又はその他の知り合いであってもよい。例えば、第２通知部１１２は、ユーザの勤務先のメールアドレスに対し、ユーザの給与の振込方法を変更することを促す電子メールを送信する。勤務先のメールアドレスは、データ記憶部１００に予め記憶されているものとする。第２通知部１１２は、任意の通知手段に基づいて、勤務先に対する通知を行ってよい。例えば、第２通知部１１２は、何らかの管理ツール内の通知機能、ＳＭＳ、プッシュ通知、バナー通知、又はその他の通知手段に基づいて、勤務先に対する通知を行ってもよい。
【0165】
変形例３の入金システム１は、指定口座振込処理の実行結果に基づいて、振込における依頼人に対し、入金が不要と判定される種別の振込を行わないように促す通知を行う。これにより、入金システム１は、給与デジタル払いの意味合いが薄れるといったことを防止できる。ユーザが振込先を変更すれば、入金サーバ１０が無用な処理を実行しなくて済むので、入金サーバ１０の処理負荷を軽減できる。例えば、入金システム１は、毎月決まった額の非給与の振込があった際に、ユーザに対して非給与の振込をしないように会社に連絡する旨の通知を出すこともできる。
【0166】
［３－４．変形例４］
例えば、第１実施形態及び第２実施形態で説明したように、電子マネーは、入金実行部１０４による入金用の給与残高と、当該給与残高とは異なる基本型残高及びプレミアム型残高と、を有してもよい。給与残高は、第１残高の一例である。基本型残高及びプレミアム型残高は、第２残高の一例である。第１残高及び第２残高は、互いに別々に管理される残高であればよく、他の名称で呼ばれてもよい。入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、給与残高に対する入金を実行する。この点は、第１実施形態及び第２実施形態で説明した通りである。
例えば、第１実施形態及び第２実施形態で説明したように、電子マネーは、入金実行部１０４による入金用の給与残高と、当該給与残高とは異なる基本型残高及びプレミアム型残高と、を有してもよい。給与残高は、第１残高の一例である。基本型残高及びプレミアム型残高は、第２残高の一例である。第１残高及び第２残高は、互いに別々に管理される残高であればよく、他の名称で呼ばれてもよい。入金実行部１０４は、要否判定部１０２により入金が必要と判定された場合に、給与残高に対する入金を実行する。この点は、第１実施形態及び第２実施形態で説明した通りである。
【0167】
変形例４の入金システム１は、設定受付部１１３を含む。設定受付部１１３は、要否判定部１０２により入金が不要であると判定された場合にユーザが指定した指定口座に振り込むか、又は、当該場合に基本型残高及びプレミアム型残高に入金するか、に関する設定をユーザから受け付ける。ユーザの設定は、電子マネーデータベースＤＢ１に格納されるものとする。例えば、ユーザは、決済アプリ画面ＳＣ１又は他の画面から、当該設定を指定する。入金サーバ１０は、ユーザにより指定された設定を、データ記憶部１００に記録する。
【0168】
変形例４では、入金サーバ１０は、振込種別が給与振込又は賞与振込を示さないと判定された場合に、ユーザの設定を参照する。入金実行部１０４は、ユーザから受け付けた設定が第２残高を示す場合に、第２残高に対する入金を実行する。第２残高に対する入金の実行方法自体は、公知の処理を利用可能である。電子マネーであれば、公知の電子マネーのチャージで利用されている処理に基づいて、第２残高に対する入金が実行されてよい。入金実行部１０４は、電子マネーデータベースＤＢ１に格納された残高情報を更新することによって、第２残高に対する入金を実行する。
【0169】
例えば、指定口座振込部１０５は、ユーザから受け付けた設定が指定口座を示す場合に、指定口座振込処理を実行する。ユーザから受け付けた設定が指定口座を示すことが、設定口座振込処理の実行のための条件になるが、指定口座振込処理の詳細は、第１実施形態で説明した通りである。
【0170】
なお、ユーザは、入金金額又は残額を指定することによって、変形例４における設定指定してもよい。例えば、ユーザは、振込金額が１万円未満なら電子マネーに入金し、振込金額が１万円を超えている分は、指定口座に振り込むといった設定をしてもよい。他にも例えば、入金システム１は、過去の入出金履歴に基づいて、設定の候補をユーザに提案してもよい。
【0171】
変形例４の入金システム１は、ユーザから受け付けた設定が第２残高を示す場合に、第２残高に対する入金を実行。入金システム１は、ユーザから受け付けた設定が指定口座を示す場合に、指定口座振込処理を実行する。これにより、入金システム１は、ユーザの好みに応じた入金を実現できるので、ユーザの利便性が高まる。
【0172】
［３－５．変形例５］
例えば、第１実施形態及び第２実施形態では、電子マネーに１０万円の上限値が定められている場合を例に挙げた。電子マネーには、上限値として、第１上限値と、当該第１上限値よりも高い第２上限値と、が設定されていてもよい。変形例５では、第１上限値が８万円であるものとする。第２上限値が１０万円であるものとする。第１上限値及び第２上限値の各々は、任意の値であってよく、変形例５に限られない。第１上限値及び第２上限値の各々は、電子マネーを取り扱う電子マネー事業者により指定されてもよいし、ユーザにより指定されてもよい。
例えば、第１実施形態及び第２実施形態では、電子マネーに１０万円の上限値が定められている場合を例に挙げた。電子マネーには、上限値として、第１上限値と、当該第１上限値よりも高い第２上限値と、が設定されていてもよい。変形例５では、第１上限値が８万円であるものとする。第２上限値が１０万円であるものとする。第１上限値及び第２上限値の各々は、任意の値であってよく、変形例５に限られない。第１上限値及び第２上限値の各々は、電子マネーを取り扱う電子マネー事業者により指定されてもよいし、ユーザにより指定されてもよい。
【0173】
変形例５の上限値判定部１０３は、要否判定部１０２により入金が必要と判定された場合に、入金により残高が第２上限値を超えるか否かを判定する。第１上限値及び第２上限値が存在するという点で第１実施形態及び第２実施形態とは異なるが、上限値判定部１０３の判定方法自体は、第１実施形態及び第２実施形態と同様である。
【0174】
変形例５の指定口座振込部１０５は、上限値判定部１０３により残高が第２上限値を超えると判定された場合に、指定口座振込処理を実行する。第１上限値及び第２上限値が存在するという点で第１実施形態及び第２実施形態とは異なるが、指定口座振込部１０５の処理自体は、第１実施形態及び第２実施形態と同様である。
【0175】
なお、第１上限値は、後述の変形例６で説明する通知以外の他の用途で利用されてもよい。例えば、ユーザの給与残高が第２上限値を超えると、給与残高に対する入金が受け付けられなくなるが、給与残高が第１上限値を超えた場合には、給与残高に対する入金が実行される前に、入金の要否がユーザに問い合わせられるようにしてもよい。入金実行部１０４は、ユーザによる回答に基づいて、第１上限値を超える入金を実行してもよい。例えば、第１上限値は、ユーザではなく、勤務先に対する通知のために利用されてもよい。
【0176】
変形例５の入金システム１は、入金が必要と判定された場合に、入金により給与残高が第２上限値を超えるか否かを判定する。入金システム１は、給与残高が第２上限値を超えると判定された場合に、指定口座振込処理を実行する。これにより、入金システム１は、電子マネーの給与残高に、第２上限値という制限を設けることができる。
【0177】
［３－６．変形例６］
例えば、変形例５において、上限値判定部１０３は、要否判定部１０２により入金が必要と判定された場合に、入金により給与残高が第１上限値を超えるか否かを判定してもよい。変形例６の入金システム１は、第３通知部１１４を含む。第３通知部１１４は、上限値判定部１０３により残高が第１上限値を超えると判定された場合に、ユーザに対し、残高の利用を促す通知を行う。
例えば、変形例５において、上限値判定部１０３は、要否判定部１０２により入金が必要と判定された場合に、入金により給与残高が第１上限値を超えるか否かを判定してもよい。変形例６の入金システム１は、第３通知部１１４を含む。第３通知部１１４は、上限値判定部１０３により残高が第１上限値を超えると判定された場合に、ユーザに対し、残高の利用を促す通知を行う。
【0178】
図２３は、残高の利用を促す通知の一例を示す図である。例えば、第３通知部１１４は、残高の利用を促すことを示すメッセージＭ１８を、決済アプリの決済アプリ画面ＳＣ１に表示させることによって、通知を行う。通知のためのデータは、データ記憶部１００に記録されているものとする。第３通知部１１４は、任意の通知手段に基づいて、ユーザに対する通知を行ってよい。例えば、第３通知部１１４は、決済アプリ内の通知機能、電子メール、ＳＭＳ、プッシュ通知、バナー通知、又はその他の通知手段に基づいて、ユーザに対する通知を行ってもよい。
【0179】
変形例６の入金システム１は、入金が必要と判定された場合に、入金により残高が第１上限値を超えるか否かを判定する。入金システム１は、給与残高が第１上限値を超えると判定された場合に、ユーザに対し、給与残高の利用を促す通知を行う。これにより、入金システム１は、ユーザが給与残高を積極的に利用する動機付けをユーザに与えることができるので、給与振込自に給与残高が第２上限値を超えにくくなる。
【0180】
［３－７．変形例７］
例えば、ユーザに対する給与デジタル払いが繰り返し実行されると、毎月どの程度の金額であれば、給与残高の上限値を超えないかを推定できることがある。この場合に、ユーザに対し、給与デジタル払いで受け取ることができる適切な金額を提示してもよい。変形例７の入金システム１は、適切額提示部１１５を含む。適切額提示部１１５は、過去における指定口座振込処理の実績に基づいて、ユーザに対し、振込として適切な額を提示する。
例えば、ユーザに対する給与デジタル払いが繰り返し実行されると、毎月どの程度の金額であれば、給与残高の上限値を超えないかを推定できることがある。この場合に、ユーザに対し、給与デジタル払いで受け取ることができる適切な金額を提示してもよい。変形例７の入金システム１は、適切額提示部１１５を含む。適切額提示部１１５は、過去における指定口座振込処理の実績に基づいて、ユーザに対し、振込として適切な額を提示する。
【0181】
例えば、適切額提示部１１５は、過去の全部又は一部の期間において、ユーザが電子マネーで給与を受け取った平均金額を計算する。適切額提示部１１５は、ユーザに対し、当該計算された平均金額を、振込として適切な額として提示する。適切額提示部１１５は、決済アプリ画面ＳＣ１、決済アプリ内の通知機能、電子メール、ＳＭＳ、プッシュ通知、バナー通知、又はその他の通知手段に基づいて、ユーザに対する提示を行ってよい。
【0182】
変形例７の入金システム１は、過去における指定口座振込処理の実績に基づいて、ユーザに対し、振込として適切な額を提示する。これにより、入金システム１は、振込として適切な額をユーザに気付かせることができる。例えば、入金システム１は、毎月２万円の給与振込のうち、１万円が指定口座に振り込まれている場合に、ユーザに対し、「給与デジタル払いの振込金額を１万円にして下さい」といった通知を行うことができる。
【0183】
［３－８．その他の変形例］
例えば、上記変形例を組み合わせてもよい。
例えば、上記変形例を組み合わせてもよい。
【0184】
例えば、入金システム１は、ユーザによる電子マネーの出金履歴に基づいて、上限値を超える分の振込金額を指定口座に振り込むのではなく、保留額として一定期間において電子マネー残高に入金してもよい。入金システム１は、給与を電子マネー残高に入金するか、給与を指定口座に振り込むかについて、ユーザが設定できるようにしてもよい。入金システム１は、上記の設定は、ユーザが金額を指定することによって設定されてもよい。例えば、入金システム１は、振込金額が１万円未満なら電子マネーに入金し、１万円を超えている分は指定口座に振り込めるようにしてもよい。入金システム１は、ユーザによる電子マネーの出金履歴に基づいて、ユーザに対し、当該設定の案を提案してもよい。入金システム１は、振込種別が給与振込か非給与振込かによって、電子マネーの利用時のポイント倍率を異ならせるようにしてもよい。入金システム１は、給与残高が利用された場合に、他の残高が利用された場合よりも高いポイント倍率でポイントを付与してもよい。
【0185】
例えば、入金サーバ１０で実現されるものとして説明した機能は、入金システム１の複数のコンピュータで機能が分担されてもよい。この場合、複数のコンピュータの各々が、他のコンピュータに対し、自身の処理結果を送信することによって、機能の分担が実現されるようにすればよい。入金システム１は、勤務先システム２、金融機関システム３、ベンダーシステム５、及びユーザ端末４０の少なくとも１つを含んでもよい。
【0186】
［４．付記］
例えば、本開示に係る入金システムは、下記のような構成も可能である。
（１）
ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得部と、
前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定部と、
前記要否判定部により前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行部と、
を含む入金システム。
（２）
前記口座番号は、金融機関における前記ユーザの仮想口座の番号であり、
前記振込情報取得部は、前記金融機関の金融機関システムから、前記仮想口座に関する前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金を実行する、
（１）に記載の入金システム。
（３）
前記口座番号は、ベンダーにより発行されたベンダー発行番号であり、
前記振込情報取得部は、前記ベンダーのベンダーシステムから、前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記ベンダー発行番号に関連付けられた金融機関における口座であるベンダー関連口座の残高に基づいて、前記入金を実行する、
（１）に記載の入金システム。
（４）
前記振込情報取得部は、前記ベンダーシステムから、前記振込における予定日よりも前に、前記振込情報を取得し、
前記入金システムは、
前記予定日よりも前に、前記振込情報に基づいて、前記振込に関するエラーが発生するか否かを判定するエラー判定部と、
前記エラー判定部により前記エラーが発生すると判定された場合に、前記振込におけるエラーの修正を依頼するための修正依頼処理を実行する修正依頼部と、
を更に含む（３）に記載の入金システム。
（５）
前記ベンダー関連口座には、前記振込情報が受け付けられる前に、前記振込における依頼人に関するデポジットが入金され、
前記入金システムは、前記振込情報に基づいて、前記デポジットが足りるか否かを判定するデポジット判定部を更に含み、
前記入金実行部は、前記デポジット判定部により前記デポジットが足りると判定された場合に、前記入金を実行する、
（３）又は（４）に記載の入金システム。
（６）
前記ベンダー関連口座には、前記振込情報が受け付けられた後に、前記振込における依頼人によって前記振込に応じた金額が振り込まれ、
前記入金システムは、前記ベンダー関連口座に前記金額が振り込まれたか否かを判定する振込判定部を更に含み、
前記入金実行部は、前記振込判定部により前記ベンダー関連口座に前記金額が振り込まれたと判定された場合に、前記入金を実行する、
（３）～（５）の何れかに記載の入金システム。
（７）
前記要否判定部は、前記振込種別が給与振込又は賞与振込を示さない場合には、前記入金が不要であると判定し、前記振込種別が前記給与振込又は前記賞与振込を示す場合に、前記入金が必要であると判定する、
（１）～（６）の何れかに記載の入金システム。
（８）
前記決済手段は、給与振込又は賞与振込用の第１残高と、当該第１残高とは異なる第２残高と、を有し、
前記入金実行部は、前記入金が必要であると判定された場合に、前記第１残高に前記入金を実行する、
（７）に記載の入金システム。
（９）
前記入金システムは、前記要否判定部により前記入金が不要であると判定された場合に、前記ユーザにより指定された指定口座に対し、前記振込における振込金額を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、
（１）～（８）の何れかに記載の入金システム。
（１０）
前記入金システムは、前記指定口座振込処理が実行される場合に、前記ユーザに対し、前記指定口座振込処理の実行に関する通知を行う第１通知部を更に含む、
（９）に記載の入金システム。
（１１）
前記入金システムは、前記指定口座振込処理が実行された場合に、前記決済手段の残高を管理するための残高管理画面に、前記指定口座振込処理が実行されたことを表示させる表示制御部を更に含む、
（９）又は（１０）に記載の入金システム。
（１２）
前記入金システムは、前記指定口座振込処理の実行結果に基づいて、前記振込における依頼人に対し、前記入金が不要と判定される種別の振込を行わないように促す通知を行う第２通知部を更に含む、
（９）～（１１）の何れかに記載の入金システム。
（１３）
前記決済手段は、前記入金用の第１残高と、当該第１残高とは異なる第２残高と、を有し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記第１残高に対する前記入金を実行し、
前記入金システムは、
前記要否判定部により前記入金が不要であると判定された場合に前記ユーザが指定した指定口座に振り込むか、又は、当該場合に前記第２残高に入金するか、に関する設定を前記ユーザから受け付ける設定受付部と、
前記設定が前記指定口座を示す場合に、前記振込における振込金額を振り込むための指定口座振込処理を実行する指定口座振込部と、
を更に含み、
前記入金実行部は、前記設定が前記第２残高を示す場合に、前記第２残高に対する入金を実行する、
（１）～（１２）の何れかに記載の入金システム。
（１４）
前記決済手段には、前記入金用の残高に関する上限値が設定されており、
前記入金システムは、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記上限値を超えるか否かを判定する上限値判定部を更に含み、
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えないと判定された場合に、前記振込における振込金額が前記決済手段に入金されるように、前記入金を実行する、
（１）～（１３）の何れかに記載の入金システム。
（１５）
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えると判定された場合に、前記決済手段の現在の前記残高と、前記上限値と、の差額に基づいて、前記入金を実行し、
前記入金システムは、前記ユーザにより指定された指定口座に対し、前記振込金額のうち、前記上限値を超えた分を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、
（１４）に記載の入金システム。
（１６）
前記決済手段には、前記上限値として、第１上限値と、当該第１上限値よりも高い第２上限値と、が設定されており、
前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第２上限値を超えるか否かを判定し、
前記指定口座振込部は、前記上限値判定部により前記残高が前記第２上限値を超えると判定された場合に、前記指定口座振込処理を実行する、
（１５）に記載の入金システム。
（１７）
前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第１上限値を超えるか否かを判定し、
前記入金システムは、前記上限値判定部により前記残高が前記第１上限値を超えると判定された場合に、前記ユーザに対し、前記残高の利用を促す通知を行う第３通知部を更に含む、
（１６）に記載の入金システム。
（１８）
前記入金システムは、過去における前記指定口座振込処理の実績に基づいて、前記ユーザに対し、前記振込として適切な額を提示する適切額提示部を更に含む、
（１５）～（１７）の何れかに記載の入金システム。
例えば、本開示に係る入金システムは、下記のような構成も可能である。
（１）
ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する振込情報取得部と、
前記振込情報が示す前記振込種別に基づいて、前記ユーザの電子的な決済手段に対する入金の要否を判定する要否判定部と、
前記要否判定部により前記入金が必要と判定された場合に、前記振込における振込金額に応じた前記入金を実行する入金実行部と、
を含む入金システム。
（２）
前記口座番号は、金融機関における前記ユーザの仮想口座の番号であり、
前記振込情報取得部は、前記金融機関の金融機関システムから、前記仮想口座に関する前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金を実行する、
（１）に記載の入金システム。
（３）
前記口座番号は、ベンダーにより発行されたベンダー発行番号であり、
前記振込情報取得部は、前記ベンダーのベンダーシステムから、前記振込情報を取得し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記ベンダー発行番号に関連付けられた金融機関における口座であるベンダー関連口座の残高に基づいて、前記入金を実行する、
（１）に記載の入金システム。
（４）
前記振込情報取得部は、前記ベンダーシステムから、前記振込における予定日よりも前に、前記振込情報を取得し、
前記入金システムは、
前記予定日よりも前に、前記振込情報に基づいて、前記振込に関するエラーが発生するか否かを判定するエラー判定部と、
前記エラー判定部により前記エラーが発生すると判定された場合に、前記振込におけるエラーの修正を依頼するための修正依頼処理を実行する修正依頼部と、
を更に含む（３）に記載の入金システム。
（５）
前記ベンダー関連口座には、前記振込情報が受け付けられる前に、前記振込における依頼人に関するデポジットが入金され、
前記入金システムは、前記振込情報に基づいて、前記デポジットが足りるか否かを判定するデポジット判定部を更に含み、
前記入金実行部は、前記デポジット判定部により前記デポジットが足りると判定された場合に、前記入金を実行する、
（３）又は（４）に記載の入金システム。
（６）
前記ベンダー関連口座には、前記振込情報が受け付けられた後に、前記振込における依頼人によって前記振込に応じた金額が振り込まれ、
前記入金システムは、前記ベンダー関連口座に前記金額が振り込まれたか否かを判定する振込判定部を更に含み、
前記入金実行部は、前記振込判定部により前記ベンダー関連口座に前記金額が振り込まれたと判定された場合に、前記入金を実行する、
（３）～（５）の何れかに記載の入金システム。
（７）
前記要否判定部は、前記振込種別が給与振込又は賞与振込を示さない場合には、前記入金が不要であると判定し、前記振込種別が前記給与振込又は前記賞与振込を示す場合に、前記入金が必要であると判定する、
（１）～（６）の何れかに記載の入金システム。
（８）
前記決済手段は、給与振込又は賞与振込用の第１残高と、当該第１残高とは異なる第２残高と、を有し、
前記入金実行部は、前記入金が必要であると判定された場合に、前記第１残高に前記入金を実行する、
（７）に記載の入金システム。
（９）
前記入金システムは、前記要否判定部により前記入金が不要であると判定された場合に、前記ユーザにより指定された指定口座に対し、前記振込における振込金額を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、
（１）～（８）の何れかに記載の入金システム。
（１０）
前記入金システムは、前記指定口座振込処理が実行される場合に、前記ユーザに対し、前記指定口座振込処理の実行に関する通知を行う第１通知部を更に含む、
（９）に記載の入金システム。
（１１）
前記入金システムは、前記指定口座振込処理が実行された場合に、前記決済手段の残高を管理するための残高管理画面に、前記指定口座振込処理が実行されたことを表示させる表示制御部を更に含む、
（９）又は（１０）に記載の入金システム。
（１２）
前記入金システムは、前記指定口座振込処理の実行結果に基づいて、前記振込における依頼人に対し、前記入金が不要と判定される種別の振込を行わないように促す通知を行う第２通知部を更に含む、
（９）～（１１）の何れかに記載の入金システム。
（１３）
前記決済手段は、前記入金用の第１残高と、当該第１残高とは異なる第２残高と、を有し、
前記入金実行部は、前記要否判定部により前記入金が必要と判定された場合に、前記第１残高に対する前記入金を実行し、
前記入金システムは、
前記要否判定部により前記入金が不要であると判定された場合に前記ユーザが指定した指定口座に振り込むか、又は、当該場合に前記第２残高に入金するか、に関する設定を前記ユーザから受け付ける設定受付部と、
前記設定が前記指定口座を示す場合に、前記振込における振込金額を振り込むための指定口座振込処理を実行する指定口座振込部と、
を更に含み、
前記入金実行部は、前記設定が前記第２残高を示す場合に、前記第２残高に対する入金を実行する、
（１）～（１２）の何れかに記載の入金システム。
（１４）
前記決済手段には、前記入金用の残高に関する上限値が設定されており、
前記入金システムは、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記上限値を超えるか否かを判定する上限値判定部を更に含み、
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えないと判定された場合に、前記振込における振込金額が前記決済手段に入金されるように、前記入金を実行する、
（１）～（１３）の何れかに記載の入金システム。
（１５）
前記入金実行部は、前記上限値判定部により前記残高が前記上限値を超えると判定された場合に、前記決済手段の現在の前記残高と、前記上限値と、の差額に基づいて、前記入金を実行し、
前記入金システムは、前記ユーザにより指定された指定口座に対し、前記振込金額のうち、前記上限値を超えた分を振り込むための指定口座振込処理を実行する指定口座振込部を更に含む、
（１４）に記載の入金システム。
（１６）
前記決済手段には、前記上限値として、第１上限値と、当該第１上限値よりも高い第２上限値と、が設定されており、
前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第２上限値を超えるか否かを判定し、
前記指定口座振込部は、前記上限値判定部により前記残高が前記第２上限値を超えると判定された場合に、前記指定口座振込処理を実行する、
（１５）に記載の入金システム。
（１７）
前記上限値判定部は、前記要否判定部により前記入金が必要と判定された場合に、前記入金により前記残高が前記第１上限値を超えるか否かを判定し、
前記入金システムは、前記上限値判定部により前記残高が前記第１上限値を超えると判定された場合に、前記ユーザに対し、前記残高の利用を促す通知を行う第３通知部を更に含む、
（１６）に記載の入金システム。
（１８）
前記入金システムは、過去における前記指定口座振込処理の実績に基づいて、前記ユーザに対し、前記振込として適切な額を提示する適切額提示部を更に含む、
（１５）～（１７）の何れかに記載の入金システム。
【符号の説明】
【0187】
１ 入金システム、２ 勤務先システム、３ 金融機関システム、５ ベンダーシステム、Ｎ ネットワーク、１０ 入金サーバ、１１，２１，２５，３１，４１，５１ 制御部、１２，２２，２６，３２，４２，５２ 記憶部、１３，２３，２７，３３，４３，５３ 通信部、２０ 勤務先サーバ、２４ 勤務先端末、２８，４４ 操作部、２９，４５ 表示部、３０ 金融機関サーバ、４０ ユーザ端末、５０ ベンダーサーバ、１００ データ記憶部、１０１ 振込情報取得部、１０２ 要否判定部、１０３ 上限値判定部、１０４ 入金実行部、１０５ 指定口座振込部、１０６ エラー判定部、１０７ 修正依頼部、１０８ デポジット判定部、１０９ 振込判定部、１１０ 第１通知部、１１１ 表示制御部、１１２ 第２通知部、１１３ 設定受付部、１１４ 第３通知部、１１５ 適切額提示部、２００ データ記憶部、２０１ 振込依頼部、２４０ データ記憶部、２４１ 表示制御部、２４２ 操作受付部、３００ データ記憶部、３０１ 仮想口座開設部、３０２ 振込受付部、３０３ 振込情報送信部、４００ データ記憶部、４０１ 表示制御部、４０２ 操作受付部、５００ データ記憶部、５０１ 番号発行部、５０２ 振込受付部、５０３ 振込情報送信部、Ｂ１１，Ｂ１２，Ｂ１３，Ｂ１４，Ｂ１６，Ｂ２０，Ｂ２１ ボタン、Ｃ１０ コード、ＤＢ１ 電子マネーデータベース、ＤＢ２ 勤務先データベース、ＤＢ３ 振込データベース、ＤＢ４ 仮想口座データベース、ＤＢ５ 振込データベース、ＤＢ６ ベンダーデータベース、Ｆ１５ 入力フォーム、Ｍ１７ メッセージ、ＳＣ１ 決済アプリ画面、ＳＣ２ 金融機関画面、ＳＣ３ 残高管理画面。
【要約】
【課題】ユーザの電子的な決済手段に対し、適切な入金を実行する。
【解決手段】入金システム（１）の振込種別取得部（１０１）は、ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する。要否判定部（１０２）は、振込情報が示す振込種別に基づいて、ユーザの電子的な決済手段に対する入金の要否を判定する。入金実行部（１０４）は、要否判定部により入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。
【選択図】図６
【解決手段】入金システム（１）の振込種別取得部（１０１）は、ユーザの口座番号が振込先として指定された振込における振込種別を示す振込情報を取得する。要否判定部（１０２）は、振込情報が示す振込種別に基づいて、ユーザの電子的な決済手段に対する入金の要否を判定する。入金実行部（１０４）は、要否判定部により入金が必要と判定された場合に、振込における振込金額に応じた入金を実行する。
【選択図】図６
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】