ホーム > 特許ランキング > 楽天グループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-10-09
(45)【発行日】2024-10-18
(54)【発明の名称】入金システム、表示制御方法、及びプログラム
(51)【国際特許分類】
G06Q 20/18 20120101AFI20241010BHJP
【ＦＩ】
G06Q20/18
【請求項の数】
14
(21)【出願番号】P 2023163657
(22)【出願日】2023-09-26
【審査請求日】2023-09-26
(73)【特許権者】
【識別番号】399037405
【氏名又は名称】楽天グループ株式会社
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】坂▲崎▼ 和彦
(72)【発明者】
【氏名】三宅 里奈
(72)【発明者】
【氏名】西田 浩子
【審査官】山崎 雄司
(56)【参考文献】
【文献】特開２００５－２７０４５８（ＪＰ，Ａ）
【文献】特開２０１９－１９７３３２（ＪＰ，Ａ）
【文献】特開２０２１－０８２０２０（ＪＰ，Ａ）
【文献】特開２０２０－１０７２１７（ＪＰ，Ａ）
【文献】ローソン銀行ATM・セブン銀行ATM・コンビニ・auショップでのチャージ(入金)方法，2021年11月07日，［2024年6月19日検索］，インターネット，＜URL： https://web.archive.org/web/20211107125211/https://aupay.auone.jp/contents/sp/guide/shop_charge.html＞
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
入金が可能な決済手段であって、出金可能な第１残高と、出金可能ではない第２残高と、を有する前記決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信部と、前記ユーザ識別情報と、所定の期間における前記ユーザの入金上限額及び入金総額と、が関連付けられて格納されたユーザデータベースに基づいて、前記ユーザ識別情報受信部が受信した前記ユーザ識別情報に関連付けられた前記入金上限額及び前記入金総額に応じた入金可能額を計算する入金可能額計算部と、
前記入金端末に、前記入金可能額を表示させる表示制御部と、
前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信部と、
前記入金要求受信部により前記入金要求が受信され、かつ、前記ユーザの本人確認が完了している場合には、前記第１残高の前記入金を実行し、前記入金要求受信部により前記入金要求が受信され、かつ、前記ユーザの本人確認が完了していない場合には、前記第２残高の前記入金を実行する入金実行部と、
を含む入金システム。
【請求項2】
前記入金システムは、前記ユーザの本人確認が完了している場合には、前記入金端末に、前記第１残高の前記入金が完了したことを示す第１レシートを出力させ、前記ユーザの本人確認が完了していない場合には、前記入金端末に、前記第２残高の前記入金が完了したことを示す第２レシートを出力させる出力制御部を更に含む請求項１に記載の入金システム。
【請求項3】
前記表示制御部は、前記入金総額が前記入金上限額に達した場合には、前記入金端末に、前記入金総額が前記入金上限額に達したことと、前記入金が再び可能になる入金可能時期と、を表示させる、請求項１又は２に記載の入金システム。
【請求項4】
前記表示制御部は、前記入金総額が前記入金上限額未満であり、かつ、前記入金端末における最低入金額の前記入金が実行不可である場合には、前記入金端末に、前記入金総額が前記入金上限額に達することと、前記入金が再び可能になる入金可能時期と、を表示させる、請求項１又は２に記載の入金システム。
【請求項5】
前記入金システムは、前記入金可能額計算部により取得された前記入金可能額である第１入金可能額と、前記入金端末から可能な１回あたりの入金可能額である第２入金可能額と、を比較する入金可能額比較部を更に含み、前記表示制御部は、前記入金可能額比較部の比較結果に基づいて、前記入金端末に、前記第１入金可能額及び前記第２入金可能額のうちの低い方を表示させる、
請求項１又は２に記載の入金システム。
【請求項6】
前記入金端末には、認証コードが表示され、前記認証コードは、前記ユーザのユーザ端末により読み取られ、
前記ユーザ識別情報受信部は、前記ユーザ端末から、前記ユーザ識別情報と、前記認証コードから抽出されたコード情報と、を受信し、
前記入金システムは、前記コード情報に基づいて、認証を実行する認証実行部を更に含み、
前記表示制御部は、前記認証が成功した場合に、前記入金端末に、前記入金可能額を表示させる、
請求項１又は２に記載の入金システム。
【請求項7】
前記入金システムは、前記入金端末に対し、前記コード情報を送信するコード情報送信部を更に含み、前記入金端末には、前記コード情報送信部により送信された前記コード情報に基づいて、前記認証コードが表示され、
前記認証実行部は、前記コード情報送信部により送信された前記コード情報と、前記ユーザ端末から受信された前記コード情報と、に基づいて、前記認証を実行する、
請求項６に記載の入金システム。
【請求項8】
前記入金システムは、前記入金端末で前記認証コードが表示された後に、次の画面に遷移した場合に、前記認証コードを無効化する第１無効化部を更に含み、前記認証実行部は、前記第１無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
請求項６に記載の入金システム。
【請求項9】
前記入金システムは、前記認証が成功した場合に、前記認証コードを無効化する第２無効化部を更に含み、前記認証実行部は、前記第２無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
請求項６に記載の入金システム。
【請求項10】
前記入金システムは、前記入金要求受信部により前記入金要求が受信された場合に、最新の前記入金可能額に基づいて、前記入金の可否を判定する可否判定部を更に含み、前記入金実行部は、前記入金要求受信部により前記入金要求が受信され、かつ、前記可否判定部により前記入金が可能と判定された場合に、前記入金を実行する、
請求項１又は２に記載の入金システム。
【請求項11】
前記ユーザのユーザ端末には、前記決済手段を管理する決済事業者の事業者決済アプリと、前記決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、前記入金は、前記事業者決済アプリ及び前記ＯＥＭ決済アプリの各々から可能であり、
前記ユーザ識別情報受信部、前記入金可能額計算部、前記表示制御部、前記入金要求受信部、及び前記入金実行部の各々の処理は、前記ユーザが前記事業者決済アプリ又は前記ＯＥＭ決済アプリの何れを利用したとしても実行可能である、
請求項１又は２に記載の入金システム。
【請求項12】
前記入金実行部は、前記入金端末に投入された現金に基づいて、前記入金を実行し、前記入金システムは、前記入金端末の格納部のセンサの検出結果に基づいて、前記格納部に格納可能な現金の残高、又は、前記格納部に格納中の現金の合計を示す投入可能情報を取得する投入可能情報取得部を更に含み、
前記入金可能額計算部は、前記投入可能情報に更に基づいて、前記入金可能額を計算する、
請求項１又は２に記載の入金システム。
【請求項13】
コンピュータが、
入金が可能な決済手段であって、出金可能な第１残高と、出金可能ではない第２残高と、を有する前記決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信ステップと、
前記ユーザ識別情報と、所定の期間における前記ユーザの入金上限額及び入金総額と、が関連付けられて格納されたユーザデータベースに基づいて、前記ユーザ識別情報受信ステップで受信した前記ユーザ識別情報に関連付けられた前記入金上限額及び前記入金総額に応じた入金可能額を計算する入金可能額計算ステップと、
前記入金端末に、前記入金可能額を表示させる表示制御ステップと、
前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信ステップと、
前記入金要求受信ステップにより前記入金要求が受信され、かつ、前記ユーザの本人確認が完了している場合には、前記第１残高の前記入金を実行し、前記入金要求受信ステップにより前記入金要求が受信され、かつ、前記ユーザの本人確認が完了していない場合には、前記第２残高の前記入金を実行する入金実行ステップと、
を実行する表示制御方法。
【請求項14】
入金が可能な決済手段であって、出金可能な第１残高と、出金可能ではない第２残高と、を有する前記決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信部、前記ユーザ識別情報と、所定の期間における前記ユーザの入金上限額及び入金総額と、が関連付けられて格納されたユーザデータベースに基づいて、前記ユーザ識別情報受信部が受信した前記ユーザ識別情報に関連付けられた前記入金上限額及び前記入金総額に応じた入金可能額を計算する入金可能額計算部、
前記入金端末に、前記入金可能額を表示させる表示制御部、
前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信部、
前記入金要求受信部により前記入金要求が受信され、かつ、前記ユーザの本人確認が完了している場合には、前記第１残高の前記入金を実行し、前記入金要求受信部により前記入金要求が受信され、かつ、前記ユーザの本人確認が完了していない場合には、前記第２残高の前記入金を実行する入金実行部、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、入金システム、表示制御方法、及びプログラムに関する。
【背景技術】
【0002】
従来、入金が可能な決済手段を利用した電子決済（キャッシュレス決済）が普及している。ユーザは、所定の場所に配置された入金端末から、入金を指示することもできる。例えば、特許文献１には、入金端末の一例であるＡＴＭ（Automatic Teller Machine）にユーザが投入した現金と、ユーザがＡＴＭに入力した入金額と、に基づいて、入金を実行する情報処理システムが記載されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２０－０４６８２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
例えば、決済手段の中には、所定の期間における入金上限額が設定されている決済手段が存在する。このような決済手段では、入金端末を操作するユーザは、入金上限額を意識して入金を指示する必要がある。しかしながら、特許文献１の技術では、ＡＴＭを操作するユーザに入金上限額を意識させることはできないので、ユーザの利便性を十分に高めることはできなかった。この点は、特許文献１以外の他の従来技術も同様である。
【0005】
本開示の目的の１つは、入金端末を操作するユーザの利便性を高めることである。
【課題を解決するための手段】
【0006】
本開示に係る入金システムは、入金が可能な決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信部と、前記ユーザ識別情報に基づいて、所定の期間における前記ユーザの入金上限額及び入金総額に応じた入金可能額を計算する入金可能額計算部と、前記入金端末に、前記入金可能額を表示させる表示制御部と、前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信部と、前記入金要求受信部により前記入金要求が受信された場合に、前記入金を実行する入金実行部と、を含む。
【発明の効果】
【0007】
本開示は、例えば、入金端末を操作するユーザの利便性を高めることができる。
【図面の簡単な説明】
【0008】
【図1】第１実施形態の入金システムのハードウェア構成の一例を示す図である。
【図2】ユーザが、入金端末に対し、入金操作を行う様子の一例を示す図である。
【図3】入金端末に表示される画面の一例を示す図である。
【図4】ユーザ端末に表示される画面の一例を示す図である。
【図5】第１実施形態の入金システムで実現される機能の一例を示す図である。
【図6】ユーザデータベースの一例を示す図である。
【図7】入金総額が入金上限額に達した場合の入金額投入画面の一例を示す図である。
【図8】入金金額が入金上限額に達する間際の場合の入金額投入画面の一例を示す図である。
【図9】第１入金可能額及び第２入金可能額の互いの関係に応じた表示の一例を示す図である。
【図10】第１実施形態の入金システムで実行される処理の一例を示す図である。
【図11】第２実施形態のＯＥＭコード画面の一例を示す図である。
【図12】第２実施形態の入金システムで実行される処理の一例を示す図である。
【図13】第１実施形態に関する変形例で実現される機能の一例を示す図である。
【図14】第２実施形態に関する変形例で実現される機能の一例を示す図である。
【図15】特典情報が表示されたＯＥＭコード画面の一例を示す図である。
【発明を実施するための形態】
【0009】
［１．第１実施形態］
本開示に係る入金システム、表示制御方法、及びプログラムの実施形態の一例である第１実施形態を説明する。
本開示に係る入金システム、表示制御方法、及びプログラムの実施形態の一例である第１実施形態を説明する。
【0010】
［１－１．第１実施形態の入金システムのハードウェア構成］
図１は、第１実施形態の入金システムのハードウェア構成の一例を示す図である。例えば、入金システム１は、サーバ１０、入金端末２０、及びユーザ端末３０を含む。サーバ１０、入金端末２０、及びユーザ端末３０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。図１の例では、サーバ１０、入金端末２０、及びユーザ端末３０の各々が１つずつ示されているが、サーバ１０、入金端末２０、及びユーザ端末３０の少なくとも１つは、複数台存在してもよい。
図１は、第１実施形態の入金システムのハードウェア構成の一例を示す図である。例えば、入金システム１は、サーバ１０、入金端末２０、及びユーザ端末３０を含む。サーバ１０、入金端末２０、及びユーザ端末３０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。図１の例では、サーバ１０、入金端末２０、及びユーザ端末３０の各々が１つずつ示されているが、サーバ１０、入金端末２０、及びユーザ端末３０の少なくとも１つは、複数台存在してもよい。
【0011】
サーバ１０は、決済事業者が管理するサーバコンピュータである。決済事業者は、ユーザに対し、電子決済（キャッシュレス決済）に関する決済サービスを提供する事業者である。第１実施形態では、決済事業者は、入金が可能な決済手段を管理する。入金は、決済手段の残高を増やすことである。チャージ又は送金は、入金の一例である。第１実施形態では、チャージが入金に相当する場合を例に挙げる。このため、第１実施形態で入金と記載した箇所は、チャージと読み替えることができる。
【0012】
なお、入金の対象となる決済手段は、公知の決済サービスで利用されている任意のタイプであってよい。例えば、決済手段は、オンライン型の電子マネー、ＩＣカード型の電子マネー、オンライン型及びＩＣカード型以外の他の電子マネー、電子マネーとは呼ばれないプリペイドカード、オンライン型のプリペイドカード、銀行口座、証券口座、銀行及び証券会社以外の他の金融機関における口座、金融機関における口座以外の他の口座、又はその他の名前で呼ばれる手段であってもよい。
【0013】
例えば、サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、の少なくとも一方を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
【0014】
入金端末２０は、決済手段の入金時にユーザが操作するコンピュータである。入金端末２０は、ユーザ端末３０とは異なるコンピュータである。ユーザ以外の他の者が、入金端末２０を管理する。第１実施形態では、決済事業者のＯＥＭ（Original Equipment Manufacturing）先が、入金端末２０を管理する。ＯＥＭ先は、決済事業者と提携する者である。入金端末２０は、ＯＥＭ先の場所に配置される。決済事業者は、自身の決済サービスのシステムを流用して、ＯＥＭ先の決済サービスのシステムを開発する。例えば、ＯＥＭ先の決済サービスの名前は、ＯＥＭ先の名前を含む。
【0015】
第１実施形態では、スーパーマーケットの運営会社がＯＥＭ先である場合を例に挙げる。例えば、ユーザが、ＯＥＭ先における買い物でＯＥＭ先の決済サービスを利用すると、ＯＥＭ先における買い物で決済事業者の決済サービス又は他の決済サービスを利用する場合よりも、特典として付与されるポイントの付与率が高くなる。ＯＥＭ先の決済サービスは、ポイントの付与率以外の他の特典が発生してもよい。この場合、ユーザが、ＯＥＭ先における買い物でＯＥＭ先の決済サービスを利用すると、ＯＥＭ先に特有の特典が付与される。これにより、ＯＥＭ先は、独自の販促活動を行うことができる。
【0016】
なお、ＯＥＭ先は、任意の者であってよい。ＯＥＭ先は、スーパーマーケットに限られない。例えば、ＯＥＭ先は、コンビニエンスストア、ドラッグストア、飲食店、宿泊施設、交通機関、美容院、金融機関、地方公共団体、自治体、又はその他の者であってもよい。入金端末２０は、ＯＥＭ先に関係する場所（例えば、店舗又はショッピングモール）に配置されてもよいし、特にＯＥＭ先には関係のない場所に配置されてもよい。複数の場所の各々に、入金端末２０が配置されてもよい。
【0017】
例えば、入金端末２０は、チャージ機、ＰＯＳ端末、セルフレジ端末、ＡＴＭ、パーソナルコンピュータ、タブレット、又はスマートフォンである。入金端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、表示部２５、投入部２６、格納部２７、及び出力部２８を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。入金端末２０は、コード又はＩＣチップを読み取り可能な読取装置（例えば、カメラ、コードリーダ、又はリーダライタ）を含んでもよい。
【0018】
例えば、操作部２４は、タッチパネル又はマウス等の入力デバイスである。表示部２５は、液晶又は有機ＥＬ等のディスプレイである。投入部２６は、現金の投入を受け付ける装置である。格納部２７は、投入部から投入された現金を格納する装置である。投入部２６及び格納部２７の各々は、公知の構成であってよい。格納部２７は、光学センサ、超音波センサ、又は磁気センサ等のセンサによって、自身に格納された紙幣及び硬貨の少なくとも一方の枚数を検出しても良い。出力部２８は、レシートを出力するプリンタである。出力部２８は、自身に格納されたレシート用紙に文字を印刷して出力する。
【0019】
ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット、パーソナルコンピュータ、又はウェアラブル端末である。例えば、ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、表示部３５、及び撮影部３６を含む。制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部２４、及び表示部２５と同様であってよい。撮影部３６は、少なくとも１つのカメラを含む。ユーザ端末３０は、決済手段に関するデータが記録されたＩＣチップを含んでもよい。ユーザ端末３０のＩＣチップにデータが記録された決済手段が、第１実施形態における決済手段に相当してもよい。
【0020】
なお、記憶部１２，２２，３２に記憶されるプログラムは、ネットワークＮを介して、サーバ１０、入金端末２０、又はユーザ端末３０に供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、メモリカートスロット）と、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）と、の少なくとも一方が、サーバ１０、入金端末２０、又はユーザ端末３０に含まれてもよい。例えば、情報記憶媒体に記憶されたプログラムが、読取部及び入出力部の少なくとも一方を介して、サーバ１０、入金端末２０、又はユーザ端末３０に供給されてもよい。
【0021】
また、入金システム１は、少なくとも１つのコンピュータを含めばよい。入金システム１に含まれるコンピュータは、図１の例に限られない。例えば、入金システム１は、サーバ１０だけを含んでもよい。この場合、入金端末２０及びユーザ端末３０は、入金システム１の外部に存在する。入金システム１は、サーバ１０及び入金端末２０だけを含んでもよい。この場合、ユーザ端末３０は、入金システム１の外部に存在する。入金システム１は、サーバ１０及びユーザ端末３０だけを含んでもよい。この場合、入金端末２０は、入金システム１の外部に存在する。入金システム１は、図１に示さない他のコンピュータだけを含んでもよい。
【0022】
［１－２．第１実施形態の入金システムの概要］
第１実施形態では、決済手段を管理する決済事業者の事業者決済アプリと、決済事業者のＯＥＭ先のＯＥＭ決済アプリと、の各々が、ユーザ端末３０にインストールされている。事業者決済アプリは、ユーザが決済事業者の決済サービスを利用するためのアプリケーションである。ＯＥＭ決済アプリは、ユーザがＯＥＭ先の決済サービスを利用するためのアプリケーションである。決済事業者は、ＯＥＭ先からの依頼を受けて、ＯＥＭ決済アプリを開発する。
第１実施形態では、決済手段を管理する決済事業者の事業者決済アプリと、決済事業者のＯＥＭ先のＯＥＭ決済アプリと、の各々が、ユーザ端末３０にインストールされている。事業者決済アプリは、ユーザが決済事業者の決済サービスを利用するためのアプリケーションである。ＯＥＭ決済アプリは、ユーザがＯＥＭ先の決済サービスを利用するためのアプリケーションである。決済事業者は、ＯＥＭ先からの依頼を受けて、ＯＥＭ決済アプリを開発する。
【0023】
第１実施形態では、ユーザは、事業者決済アプリ及びＯＥＭ決済アプリの各々の利用登録を済ませているものとする。ユーザは、決済事業者の決済サービスに加盟する者（例えば、店舗又は宿泊施設）における決済で、事業者決済アプリを利用する。ユーザは、ＯＥＭ先における決済で、ＯＥＭ決済アプリを利用する。ＯＥＭ決済アプリは、ＯＥＭ先だけで利用可能であってもよいし、ＯＥＭ先以外の他の店舗等で利用可能であってもよい。以降、事業者決済アプリ及びＯＥＭ決済アプリを区別しない時は、単に決済アプリという。
【0024】
第１実施形態では、オンライン型の電子マネーが決済手段に相当する場合を例に挙げる。更に、ユーザが事業者決済アプリから利用する決済手段と、ユーザがＯＥＭ決済アプリから利用する決済手段と、が同じである場合を例に挙げる。即ち、ユーザの決済手段は、事業者決済アプリ用の残高と、ＯＥＭ決済アプリ用の残高と、の２つの残高が存在するわけではなく、共通の１つの残高が、事業者決済アプリ及びＯＥＭ決済アプリの各々から利用される。
【0025】
例えば、ユーザは、事業者決済アプリに対し、決済手段の入金で利用する入金手段を登録する。入金手段は、入金時の原資となる決済手段である。例えば、入金手段は、クレジットカード、銀行口座、暗号資産、オンラインフリーマーケットの売上金、又は他の決済手段であってもよい。ユーザは、事業者決済アプリを操作して、決済手段の入金を実行できる。事業者決済アプリからの入金の流れは、公知の流れであってよい。ユーザは、事業者決済アプリではなく、ブラウザから決済手段の入金を実行してもよい。
【0026】
第１実施形態では、ＯＥＭ決済アプリには、入金手段が登録されない場合を例に挙げる。更に、ユーザがＯＥＭ決済アプリから決済手段の入金を実行するためには、ユーザは、入金端末２０が配置された場所を訪れる必要があるものとする。例えば、ユーザが、入金端末２０が配置された場所を訪れて、ＯＥＭ決済アプリを利用して入金すると、ＯＥＭ先に特有の特典がユーザに付与される。ユーザは、入金端末２０に対し、入金のための入金操作を行う。
【0027】
図２は、ユーザが、入金端末２０に対し、入金操作を行う様子の一例を示す図である。例えば、入金端末２０は、ユーザが入金端末２０に近づいたことを人感センサ等の公知のセンサで検知すると、入金端末２０におけるトップページに相当する入金メニュー画面ＳＣ１を、表示部２５に表示させる。入金メニュー画面ＳＣ１には、ユーザが事業者決済アプリを選択するためのボタンＢ１０と、ユーザがＯＥＭ決済アプリを選択するためのボタンＢ１１と、が表示される。
【0028】
例えば、ユーザは、事業者決済アプリに入金手段を登録していなくても、ボタンＢ１０を選択して投入部２６に現金を投入することによって、事業者決済アプリに基づく入金を実行できる。ユーザがボタンＢ１０，Ｂ１１を選択した後の入金の流れは、互いに同様である。以降、ユーザがボタンＢ１１を選択した場合の入金の流れの一例を説明する。ユーザは、ボタンＢ１１を選択した後に、入金端末２０の案内に従って、入金端末２０及びＯＥＭ決済アプリの各々を操作して、入金の手続を行う。
【0029】
図３は、入金端末２０に表示される画面の一例を示す図である。例えば、ユーザが、図２の入金メニュー画面ＳＣ１のボタンＢ１１を選択すると、入金端末２０は、図３の上側のように、入金時の認証で利用される認証コードＣ２０を含むコード読取画面ＳＣ２を、表示部２５に表示させる。認証コードＣ２０は、所定の規格に基づいて生成された画像である。認証コードＣ２０は、任意のコードであってよい。例えば、認証コードＣ２０は、バーコード、二次元コード、又はこれらの組み合わせであってよい。
【0030】
例えば、認証コードＣ２０は、サーバ１０が生成した一時的な情報に基づいて生成される。以降、当該情報を、コード情報という。認証コードＣ２０は、サーバ１０等のコンピュータにアクセスするためのＵＲＬに基づいて生成されてもよい。認証コードＣ２０は、コード情報、ＵＲＬ、入金端末２０を識別可能な端末識別情報、及びその他の情報といった複数の情報に基づいて生成されてもよい。例えば、ユーザは、コード読取画面ＳＣ２の案内に従って、ユーザ端末３０を操作する。
【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】
また、入金システム１は、ユーザ端末には、決済手段を管理する決済事業者の事業者決済アプリと、決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、入金は、事業者決済アプリ及びＯＥＭ決済アプリの各々から可能であり、表示制御部１０６及び入金実行部１０８の各々の処理は、ユーザが事業者決済アプリ又はＯＥＭ決済アプリの何れを利用したとしても実行可能である。これにより、入金システム１は、入金時に、事業者決済アプリ及びＯＥＭ決済アプリのうちの好きな方をユーザに利用させることができるので、ユーザの利便性を、より高めることができる。
【0133】
［３．変形例］
本開示は、以上に説明した実施形態に限定されない。本開示は、本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
本開示は、以上に説明した実施形態に限定されない。本開示は、本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
【0134】
［３－１．第１実施形態に関する変形例］
まず、第１実施形態に関する変形例を説明する。
まず、第１実施形態に関する変形例を説明する。
【0135】
図１３は、第１実施形態に関する変形例で実現される機能の一例を示す図である。図１３のように、第１実施形態に関する変形例のサーバ１０は、出力制御部１０９、第１無効化部１１０、第２無効化部１１１、可否判定部１１２、及び投入可能情報取得部１１３を含む。出力制御部１０９、第１無効化部１１０、第２無効化部１１１、可否判定部１１２、及び投入可能情報取得部１１３の各々は、制御部１１により実現される。
【0136】
［変形例１－１］
例えば、決済手段は、出金可能な第１残高と、出金可能ではない第２残高と、を有してもよい。出金は、銀行口座等の口座への振込によって行われたり、ＡＴＭから現金が排出されることによって行われたりする。決済手段の出金方法は、公知の方法を利用可能である。入金手段によっては、第１残高への入金が禁止される。例えば、クレジットカードのショッピング枠を利用した入金は、第１残高ではなく、第２残高に対して行われる。この点も、公知の決済サービスで利用されている仕組みを利用可能である。
例えば、決済手段は、出金可能な第１残高と、出金可能ではない第２残高と、を有してもよい。出金は、銀行口座等の口座への振込によって行われたり、ＡＴＭから現金が排出されることによって行われたりする。決済手段の出金方法は、公知の方法を利用可能である。入金手段によっては、第１残高への入金が禁止される。例えば、クレジットカードのショッピング枠を利用した入金は、第１残高ではなく、第２残高に対して行われる。この点も、公知の決済サービスで利用されている仕組みを利用可能である。
【0137】
変形例１－１のユーザデータベースＤＢには、決済手段の第１残高、決済手段の第２残高、及び本人確認情報が格納される。本人確認情報は、本人確認の有無に関する情報である。例えば、本人確認は、本人確認書類（身分証明書）が利用される認証である。例えば、本人確認は、ｅＫＹＣ（Electronic Know Your Customer）により行われてもよい。本人確認は、本人確認書類ではなく、クレジットカード又は個人番号カード等の物理的なカードがユーザ端末３０で読み取られることによって行われてもよい。
【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】
なお、ＯＥＭ先は、１つに限られない。複数のＯＥＭ先が存在してもよい。例えば、第１ＯＥＭ先及び第２ＯＥＭ先といった２つのＯＥＭ先が存在したとする。ユーザが、第１ＯＥＭ先の場所に配置された入金端末２０と、第１ＯＥＭ先の決済アプリである第１ＯＥＭ決済アプリと、を利用して入金を実行した場合に、特典付与部１１４は、第１ＯＥＭ先の場所で利用可能な特典であって、ユーザが事業者決済アプリを利用して入金が実行された場合よりも良い特典を、ユーザに付与してもよい。同様に、ユーザが、第２ＯＥＭ先の場所に配置された入金端末２０と、第２ＯＥＭ先の決済アプリである第２ＯＥＭ決済アプリと、を利用して入金を実行した場合に、特典付与部１１４は、第２ＯＥＭ先の場所で利用可能な特典であって、ユーザが事業者決済アプリを利用して入金が実行された場合よりも良い特典を、ユーザに付与してもよい。３つ以上のＯＥＭ先が存在してもよい。
【0188】
変形例２－６の入金システム１は、ユーザが入金端末２０及びＯＥＭ決済アプリを利用して入金が実行された場合には、ＯＥＭ先の場所で利用可能な特典であって、ユーザが事業者決済アプリを利用して入金が実行された場合よりも良い特典を、ユーザに付与する。入金システム１は、ＯＥＭ決済アプリのＯＥＭコード画面ＳＣ６に、特典が付与されたことを表示させる。これにより、入金システム１は、ユーザに対し、ＯＥＭ決済アプリを利用すると良い特典を獲得できることを通知することができるので、ＯＥＭ先の決済サービスの利用を促進できる。
【0189】
［３－３．その他の変形例］
例えば、第１実施形態の変形例と、第２実施形態の変形例と、を組み合わせてもよい。
例えば、第１実施形態の変形例と、第２実施形態の変形例と、を組み合わせてもよい。
【0190】
例えば、ユーザが事業者決済アプリから利用する決済手段と、ユーザがＯＥＭ決済アプリから利用する決済手段と、が異なってもよい。即ち、ユーザが事業者決済アプリを利用する場合と、ユーザがＯＥＭ決済アプリを利用する場合と、で互いに異なる残高が利用されてもよい。例えば、ユーザが、コード読取画面ＳＣ２のボタンＢ２３、又は、入金額投入画面ＳＣ３のボタンＢ３１を選択した場合に、入金がキャンセルされてもよい。この場合、認証コードＣ２０が無効化されてもよい。認証コードＣ２０の無効化は、変形例１－２，１－３と同様にして実行されてもよい。ユーザが、コード読取画面ＳＣ２が表示されてから一定時間の間、入金端末２０に対する操作を行わなかった場合に、認証コードＣ２０が無効化されてもよい。
【0191】
例えば、サーバ１０で実行されるものとして説明した処理は、入金端末２０又はユーザ端末３０で実行されてもよい。入金端末２０で実行されるものとして説明した処理は、サーバ１０又はユーザ端末３０で実行されてもよい。ユーザ端末３０で実行されるものとして説明した処理は、サーバ１０又は入金端末２０で実行されてもよい。サーバ１０、入金端末２０、又はユーザ端末３０で実行されるものとして説明した処理は、複数のコンピュータで分担されてもよい。
【0192】
［４．付記］
例えば、入金システムは、下記のような構成も可能である。
例えば、入金システムは、下記のような構成も可能である。
【0193】
［４－１．第１実施形態の入金システムに関する付記］
（１－１）
入金が可能な決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信部と、
前記ユーザ識別情報に基づいて、所定の期間における前記ユーザの入金上限額及び入金総額に応じた入金可能額を計算する入金可能額計算部と、
前記入金端末に、前記入金可能額を表示させる表示制御部と、
前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信部と、
前記入金要求受信部により前記入金要求が受信された場合に、前記入金を実行する入金実行部と、
を含む入金システム。
（１－２）
前記表示制御部は、前記入金総額が前記入金上限額に達した場合には、前記入金端末に、前記入金総額が前記入金上限額に達したことと、前記入金が再び可能になる入金可能時期と、を表示させる、
（１－１）に記載の入金システム。
（１－３）
前記表示制御部は、前記入金総額が前記入金上限額未満であり、かつ、前記入金端末における最低入金額の前記入金が実行不可である場合には、前記入金端末に、前記入金総額が前記入金上限額に達することと、前記入金が再び可能になる入金可能時期と、を表示させる、
（１－１）又は（１－２）に記載の入金システム。
（１－４）
前記入金システムは、前記入金可能額計算部により取得された前記入金可能額である第１入金可能額と、前記入金端末から可能な１回あたりの入金可能額である第２入金可能額と、を比較する入金可能額比較部を更に含み、
前記表示制御部は、前記入金可能額比較部の比較結果に基づいて、前記入金端末に、前記第１入金可能額及び前記第２入金可能額のうちの低い方を表示させる、
（１－１）～（１－３）の何れかに記載の入金システム。
（１－５）
前記決済手段は、出金可能な第１残高と、出金可能ではない第２残高と、を有し、
前記入金実行部は、前記ユーザの本人確認が完了している場合には、前記第１残高の前記入金を実行し、前記ユーザの本人確認が完了していない場合には、前記第２残高の前記入金を実行し、
前記入金システムは、前記ユーザの本人確認が完了している場合には、前記入金端末に、前記第１残高の前記入金が完了したことを示す第１レシートを出力させ、前記ユーザの本人確認が完了していない場合には、前記入金端末に、前記第２残高の前記入金が完了したことを示す第２レシートを出力させる出力制御部を更に含む
（１－１）～（１－４）の何れかに記載の入金システム。
（１－６）
前記入金端末には、認証コードが表示され、
前記認証コードは、前記ユーザのユーザ端末により読み取られ、
前記ユーザ識別情報受信部は、前記ユーザ端末から、前記ユーザ識別情報と、前記認証コードから抽出されたコード情報と、を受信し、
前記入金システムは、前記コード情報に基づいて、認証を実行する認証実行部を更に含み、
前記表示制御部は、前記認証が成功した場合に、前記入金端末に、前記入金可能額を表示させる、
（１－１）～（１－５）の何れかに記載の入金システム。
（１－７）
前記入金システムは、前記入金端末に対し、前記コード情報を送信するコード情報送信部を更に含み、
前記入金端末には、前記コード情報送信部により送信された前記コード情報に基づいて、前記認証コードが表示され、
前記認証実行部は、前記コード情報送信部により送信された前記コード情報と、前記ユーザ端末から受信された前記コード情報と、に基づいて、前記認証を実行する、
（１－６）に記載の入金システム。
（１－８）
前記入金システムは、前記入金端末で前記認証コードが表示された後に、次の画面に遷移した場合に、前記認証コードを無効化する第１無効化部を更に含み、
前記認証実行部は、前記第１無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
（１－６）又は（１－７）に記載の入金システム。
（１－９）
前記入金システムは、前記認証が成功した場合に、前記認証コードを無効化する第２無効化部を更に含み、
前記認証実行部は、前記第２無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
（１－６）～（１－８）の何れかに記載の入金システム。
（１－１０）
前記入金システムは、前記入金要求受信部により前記入金要求が受信された場合に、最新の前記入金可能額に基づいて、前記入金の可否を判定する可否判定部を更に含み、
前記入金実行部は、前記入金要求受信部により前記入金要求が受信され、かつ、前記可否判定部により前記入金が可能と判定された場合に、前記入金を実行する、
（１－１）～（１－９）の何れかに記載の入金システム。
（１－１１）
前記ユーザのユーザ端末には、前記決済手段を管理する決済事業者の事業者決済アプリと、前記決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、
前記入金端末は、前記ＯＥＭ先の場所に配置され、
前記入金は、前記事業者決済アプリ及び前記ＯＥＭ決済アプリの各々から可能であり、
前記ユーザ識別情報受信部、前記入金可能額計算部、前記表示制御部、前記入金要求受信部、及び前記入金実行部の各々の処理は、前記ユーザが前記事業者決済アプリ又は前記ＯＥＭ決済アプリの何れを利用したとしても実行可能である、
（１－１）～（１－１０）の何れかに記載の入金システム。
（１－１２）
前記入金実行部は、前記入金端末に投入された現金に基づいて、前記入金を実行し、
前記入金システムは、前記入金端末に投入可能な現金に関する投入可能情報を取得する投入可能情報取得部を更に含み、
前記入金可能額計算部は、前記投入可能情報に更に基づいて、前記入金可能額を計算する、
（１－１）～（１－１１）の何れかに記載の入金システム。
（１－１）
入金が可能な決済手段に関する入金操作を受け付ける入金端末であって、ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を受信するユーザ識別情報受信部と、
前記ユーザ識別情報に基づいて、所定の期間における前記ユーザの入金上限額及び入金総額に応じた入金可能額を計算する入金可能額計算部と、
前記入金端末に、前記入金可能額を表示させる表示制御部と、
前記入金可能額が表示された後に、前記入金端末から、入金要求を受信する入金要求受信部と、
前記入金要求受信部により前記入金要求が受信された場合に、前記入金を実行する入金実行部と、
を含む入金システム。
（１－２）
前記表示制御部は、前記入金総額が前記入金上限額に達した場合には、前記入金端末に、前記入金総額が前記入金上限額に達したことと、前記入金が再び可能になる入金可能時期と、を表示させる、
（１－１）に記載の入金システム。
（１－３）
前記表示制御部は、前記入金総額が前記入金上限額未満であり、かつ、前記入金端末における最低入金額の前記入金が実行不可である場合には、前記入金端末に、前記入金総額が前記入金上限額に達することと、前記入金が再び可能になる入金可能時期と、を表示させる、
（１－１）又は（１－２）に記載の入金システム。
（１－４）
前記入金システムは、前記入金可能額計算部により取得された前記入金可能額である第１入金可能額と、前記入金端末から可能な１回あたりの入金可能額である第２入金可能額と、を比較する入金可能額比較部を更に含み、
前記表示制御部は、前記入金可能額比較部の比較結果に基づいて、前記入金端末に、前記第１入金可能額及び前記第２入金可能額のうちの低い方を表示させる、
（１－１）～（１－３）の何れかに記載の入金システム。
（１－５）
前記決済手段は、出金可能な第１残高と、出金可能ではない第２残高と、を有し、
前記入金実行部は、前記ユーザの本人確認が完了している場合には、前記第１残高の前記入金を実行し、前記ユーザの本人確認が完了していない場合には、前記第２残高の前記入金を実行し、
前記入金システムは、前記ユーザの本人確認が完了している場合には、前記入金端末に、前記第１残高の前記入金が完了したことを示す第１レシートを出力させ、前記ユーザの本人確認が完了していない場合には、前記入金端末に、前記第２残高の前記入金が完了したことを示す第２レシートを出力させる出力制御部を更に含む
（１－１）～（１－４）の何れかに記載の入金システム。
（１－６）
前記入金端末には、認証コードが表示され、
前記認証コードは、前記ユーザのユーザ端末により読み取られ、
前記ユーザ識別情報受信部は、前記ユーザ端末から、前記ユーザ識別情報と、前記認証コードから抽出されたコード情報と、を受信し、
前記入金システムは、前記コード情報に基づいて、認証を実行する認証実行部を更に含み、
前記表示制御部は、前記認証が成功した場合に、前記入金端末に、前記入金可能額を表示させる、
（１－１）～（１－５）の何れかに記載の入金システム。
（１－７）
前記入金システムは、前記入金端末に対し、前記コード情報を送信するコード情報送信部を更に含み、
前記入金端末には、前記コード情報送信部により送信された前記コード情報に基づいて、前記認証コードが表示され、
前記認証実行部は、前記コード情報送信部により送信された前記コード情報と、前記ユーザ端末から受信された前記コード情報と、に基づいて、前記認証を実行する、
（１－６）に記載の入金システム。
（１－８）
前記入金システムは、前記入金端末で前記認証コードが表示された後に、次の画面に遷移した場合に、前記認証コードを無効化する第１無効化部を更に含み、
前記認証実行部は、前記第１無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
（１－６）又は（１－７）に記載の入金システム。
（１－９）
前記入金システムは、前記認証が成功した場合に、前記認証コードを無効化する第２無効化部を更に含み、
前記認証実行部は、前記第２無効化部により無効化された前記認証コードが読み取られた場合には、前記認証を失敗させる、
（１－６）～（１－８）の何れかに記載の入金システム。
（１－１０）
前記入金システムは、前記入金要求受信部により前記入金要求が受信された場合に、最新の前記入金可能額に基づいて、前記入金の可否を判定する可否判定部を更に含み、
前記入金実行部は、前記入金要求受信部により前記入金要求が受信され、かつ、前記可否判定部により前記入金が可能と判定された場合に、前記入金を実行する、
（１－１）～（１－９）の何れかに記載の入金システム。
（１－１１）
前記ユーザのユーザ端末には、前記決済手段を管理する決済事業者の事業者決済アプリと、前記決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、
前記入金端末は、前記ＯＥＭ先の場所に配置され、
前記入金は、前記事業者決済アプリ及び前記ＯＥＭ決済アプリの各々から可能であり、
前記ユーザ識別情報受信部、前記入金可能額計算部、前記表示制御部、前記入金要求受信部、及び前記入金実行部の各々の処理は、前記ユーザが前記事業者決済アプリ又は前記ＯＥＭ決済アプリの何れを利用したとしても実行可能である、
（１－１）～（１－１０）の何れかに記載の入金システム。
（１－１２）
前記入金実行部は、前記入金端末に投入された現金に基づいて、前記入金を実行し、
前記入金システムは、前記入金端末に投入可能な現金に関する投入可能情報を取得する投入可能情報取得部を更に含み、
前記入金可能額計算部は、前記投入可能情報に更に基づいて、前記入金可能額を計算する、
（１－１）～（１－１１）の何れかに記載の入金システム。
【0194】
［４－２．第２実施形態の入金システムに関する付記］
（２－１）
ユーザのユーザ端末にインストールされた決済アプリに、入金が可能な決済手段に基づく決済のための決済コードを表示させる表示制御部と、
前記入金を実行する入金実行部と、
を含み、
前記表示制御部は、前記入金が実行された場合に、前記決済コードが表示される前記決済アプリのコード画面に、前記入金の実行に関する入金実行情報を表示させる、
入金システム。
（２－２）
前記入金システムは、
前記入金に関する入金操作を受け付ける入金端末であって、前記ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を、前記決済アプリから受信するユーザ識別情報受信部と、
前記入金端末から、入金要求を受信する入金要求受信部と、
を更に含み、
前記入金実行部は、前記入金要求受信部により前記入金要求が受信された場合に、前記ユーザ識別情報に関連付けられた前記決済手段の前記入金を実行する、
（２－１）に記載の入金システム。
（２－３）
前記入金端末には、認証コードが表示され、
前記認証コードは、前記ユーザ端末により読み取られ、
前記ユーザ識別情報受信部は、前記決済アプリから、前記ユーザ識別情報と、前記認証コードから抽出されたコード情報と、を受信し、
前記入金システムは、前記コード情報に基づいて、認証を実行する認証実行部を更に含み、
前記入金実行部は、前記認証が成功した場合に、前記入金を実行する、
（２－２）に記載の入金システム。
（２－４）
前記入金システムは、前記入金端末に対し、前記コード情報を送信するコード情報送信部を更に含み、
前記入金端末には、前記コード情報送信部により送信された前記コード情報に基づいて、前記認証コードが表示され、
前記認証実行部は、前記コード情報送信部により送信された前記コード情報と、前記決済アプリから受信された前記コード情報と、に基づいて、前記認証を実行する、
（２－３）に記載の入金システム。
（２－５）
前記認証コードは、前記コード情報と、前記入金端末を識別可能な端末識別情報と、に基づいて生成され、
前記表示制御部は、前記端末識別情報に基づいて、前記決済アプリに、前記入金端末に関する情報を表示させる、
（２－３）又は（２－４）に記載の入金システム。
（２－６）
前記認証コードは、前記コード情報と、前記決済アプリを識別可能なアプリ識別情報と、に基づいて生成され、
前記ユーザ端末は、前記決済アプリ以外の他の機能によって前記認証コードが読み取られた場合に、前記アプリ識別情報に基づいて、前記決済アプリを起動させる、
（２－３）～（２－５）の何れかに記載の入金システム。
（２－７）
前記表示制御部は、前記コード画面に、前記入金によって前記ユーザに付与される特典に関する特典情報を更に表示させる、
（２－１）～（２－６）の何れかに記載の入金システム。
（２－８）
前記表示制御部は、前記コード画面に、前記入金が所定の条件を満たした場合に付与される前記特典に関する前記特典情報を表示させる、
（２－７）に記載の入金システム。
（２－９）
前記ユーザ端末には、前記決済手段を管理する決済事業者の事業者決済アプリと、前記決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、
前記入金は、前記事業者決済アプリ及び前記ＯＥＭ決済アプリの各々から可能であり、
前記表示制御部及び前記入金実行部の各々の処理は、前記ユーザが前記事業者決済アプリ又は前記ＯＥＭ決済アプリの何れを利用したとしても実行可能である、
（２－１）～（２－８）の何れかに記載の入金システム。
（２－１０）
前記表示制御部は、前記ＯＥＭ決済アプリに基づく前記入金が実行された場合に、前記事業者決済アプリの前記コード画面には前記入金実行情報を表示させず、前記ＯＥＭ決済アプリの前記コード画面に、前記入金実行情報を表示させる、
（２－９）に記載の入金システム。
（２－１１）
前記ＯＥＭ決済アプリを利用した前記入金は、前記ＯＥＭ先の場所に配置された入金端末に基づいて実行され、
前記入金システムは、前記ユーザが前記入金端末及び前記ＯＥＭ決済アプリを利用して前記入金が実行された場合には、前記ＯＥＭ先の前記場所で利用可能な特典であって、前記ユーザが前記事業者決済アプリを利用して前記入金が実行された場合よりも良い前記特典を、前記ユーザに付与する特典付与部を更に含み、
前記表示制御部は、前記ＯＥＭ決済アプリの前記コード画面に、前記特典が付与されたことを表示させる、
（２－９）又は（２－１０）に記載の入金システム。
（２－１）
ユーザのユーザ端末にインストールされた決済アプリに、入金が可能な決済手段に基づく決済のための決済コードを表示させる表示制御部と、
前記入金を実行する入金実行部と、
を含み、
前記表示制御部は、前記入金が実行された場合に、前記決済コードが表示される前記決済アプリのコード画面に、前記入金の実行に関する入金実行情報を表示させる、
入金システム。
（２－２）
前記入金システムは、
前記入金に関する入金操作を受け付ける入金端末であって、前記ユーザが訪れた場所に配置された前記入金端末を操作する前記ユーザを識別可能なユーザ識別情報を、前記決済アプリから受信するユーザ識別情報受信部と、
前記入金端末から、入金要求を受信する入金要求受信部と、
を更に含み、
前記入金実行部は、前記入金要求受信部により前記入金要求が受信された場合に、前記ユーザ識別情報に関連付けられた前記決済手段の前記入金を実行する、
（２－１）に記載の入金システム。
（２－３）
前記入金端末には、認証コードが表示され、
前記認証コードは、前記ユーザ端末により読み取られ、
前記ユーザ識別情報受信部は、前記決済アプリから、前記ユーザ識別情報と、前記認証コードから抽出されたコード情報と、を受信し、
前記入金システムは、前記コード情報に基づいて、認証を実行する認証実行部を更に含み、
前記入金実行部は、前記認証が成功した場合に、前記入金を実行する、
（２－２）に記載の入金システム。
（２－４）
前記入金システムは、前記入金端末に対し、前記コード情報を送信するコード情報送信部を更に含み、
前記入金端末には、前記コード情報送信部により送信された前記コード情報に基づいて、前記認証コードが表示され、
前記認証実行部は、前記コード情報送信部により送信された前記コード情報と、前記決済アプリから受信された前記コード情報と、に基づいて、前記認証を実行する、
（２－３）に記載の入金システム。
（２－５）
前記認証コードは、前記コード情報と、前記入金端末を識別可能な端末識別情報と、に基づいて生成され、
前記表示制御部は、前記端末識別情報に基づいて、前記決済アプリに、前記入金端末に関する情報を表示させる、
（２－３）又は（２－４）に記載の入金システム。
（２－６）
前記認証コードは、前記コード情報と、前記決済アプリを識別可能なアプリ識別情報と、に基づいて生成され、
前記ユーザ端末は、前記決済アプリ以外の他の機能によって前記認証コードが読み取られた場合に、前記アプリ識別情報に基づいて、前記決済アプリを起動させる、
（２－３）～（２－５）の何れかに記載の入金システム。
（２－７）
前記表示制御部は、前記コード画面に、前記入金によって前記ユーザに付与される特典に関する特典情報を更に表示させる、
（２－１）～（２－６）の何れかに記載の入金システム。
（２－８）
前記表示制御部は、前記コード画面に、前記入金が所定の条件を満たした場合に付与される前記特典に関する前記特典情報を表示させる、
（２－７）に記載の入金システム。
（２－９）
前記ユーザ端末には、前記決済手段を管理する決済事業者の事業者決済アプリと、前記決済事業者のＯＥＭ（Original Equipment Manufacturing）先のＯＥＭ決済アプリと、の各々がインストールされ、
前記入金は、前記事業者決済アプリ及び前記ＯＥＭ決済アプリの各々から可能であり、
前記表示制御部及び前記入金実行部の各々の処理は、前記ユーザが前記事業者決済アプリ又は前記ＯＥＭ決済アプリの何れを利用したとしても実行可能である、
（２－１）～（２－８）の何れかに記載の入金システム。
（２－１０）
前記表示制御部は、前記ＯＥＭ決済アプリに基づく前記入金が実行された場合に、前記事業者決済アプリの前記コード画面には前記入金実行情報を表示させず、前記ＯＥＭ決済アプリの前記コード画面に、前記入金実行情報を表示させる、
（２－９）に記載の入金システム。
（２－１１）
前記ＯＥＭ決済アプリを利用した前記入金は、前記ＯＥＭ先の場所に配置された入金端末に基づいて実行され、
前記入金システムは、前記ユーザが前記入金端末及び前記ＯＥＭ決済アプリを利用して前記入金が実行された場合には、前記ＯＥＭ先の前記場所で利用可能な特典であって、前記ユーザが前記事業者決済アプリを利用して前記入金が実行された場合よりも良い前記特典を、前記ユーザに付与する特典付与部を更に含み、
前記表示制御部は、前記ＯＥＭ決済アプリの前記コード画面に、前記特典が付与されたことを表示させる、
（２－９）又は（２－１０）に記載の入金システム。
【符号の説明】
【0195】
１ 入金システム、１０ サーバ、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、２０ 入金端末、２４，３４ 操作部、２５，３５ 表示部、２６ 投入部、２７ 格納部、２８ 出力部、３０ ユーザ端末、３６ 撮影部、１００ データ記憶部、１０１ コード情報送信部、１０２ ユーザ識別情報受信部、１０３ 認証実行部、１０４ 入金可能額計算部、１０５ 入金可能額比較部、１０６ 表示制御部、１０７ 入金要求受信部、１０８ 入金実行部、１０９ 出力制御部、１１０ 第１無効化部、１１１ 第２無効化部、１１２ 可否判定部、１１３ 投入可能情報取得部、１１４ 特典付与部、２００ データ記憶部、２０１ 送信部、２０２ 受信部、２０３ 表示制御部、３００ データ記憶部、３０１ 操作受付部、３０２ 表示制御部、Ｂ１０，Ｂ１１，Ｂ２１，Ｂ２２，Ｂ２３，Ｂ３０，Ｂ３１，Ｂ４０，Ｂ４１，Ｂ６１ ボタン、Ｃ２０ 認証コード、Ｃ６０ 決済コード、ＤＢ ユーザデータベース、Ｉ５０，Ｉ５１ アイコン、Ｉ６３ 入金実行情報、Ｍ６２ モーダル、Ｎ ネットワーク、ＳＣ１ 入金メニュー画面、ＳＣ２ コード読取画面、ＳＣ３ 入金額投入画面、ＳＣ４ 入金完了画面、ＳＣ５ ユーザメニュー画面、ＳＣ６ ＯＥＭコード画面。
【要約】
【課題】入金端末を操作するユーザの利便性を高める。
【解決手段】入金システム（１）のユーザ識別情報受信部（１０２）は、入金が可能な決済手段に関する入金操作を受け付ける入金端末（２０）であって、ユーザが訪れた場所に配置された入金端末（２０）を操作するユーザを識別可能なユーザ識別情報を受信する。入金可能額計算部（１０４）は、ユーザ識別情報に基づいて、所定の期間におけるユーザの入金上限額及び入金総額に応じた入金可能額を計算する。表示制御部（１０６）は、入金端末（２０）に、入金可能額を表示させる。入金要求受信部（１０７）は、入金可能額が表示された後に、入金端末（２０）から、入金要求を受信する。入金実行部（１０８）は、入金要求受信部（１０７）により入金要求が受信された場合に、入金を実行する。
【選択図】図５
【解決手段】入金システム（１）のユーザ識別情報受信部（１０２）は、入金が可能な決済手段に関する入金操作を受け付ける入金端末（２０）であって、ユーザが訪れた場所に配置された入金端末（２０）を操作するユーザを識別可能なユーザ識別情報を受信する。入金可能額計算部（１０４）は、ユーザ識別情報に基づいて、所定の期間におけるユーザの入金上限額及び入金総額に応じた入金可能額を計算する。表示制御部（１０６）は、入金端末（２０）に、入金可能額を表示させる。入金要求受信部（１０７）は、入金可能額が表示された後に、入金端末（２０）から、入金要求を受信する。入金実行部（１０８）は、入金要求受信部（１０７）により入金要求が受信された場合に、入金を実行する。
【選択図】図５
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】