(57)【要約】      （修正有）【課題】簡単かつ安全に入金が行える情報システム、第一端末、第二端末、サーバ、入金処理方法、およびプログラムを提供する。【解決手段】情報システムは、第一端末１、第二端末２、及びサーバ３を具備する。第一端末は、認証コードを取得する取得部と、認証コードをサーバ及び第二端末に送信する第一送信部とを備える。第二端末は、第一端末から認証コードを受信する第二受信部と、第二受信部が受信した認証コードをサーバに送信する第二送信部とを備える。サーバは、第一端末から認証コードを受信する第一認証コード受信部と、第二端末から認証コードを受信する第二認証コード受信部と、第一認証コード受信部が受信した認証コードと第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、判断部が認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを備える。【選択図】図１
2019061524.tif 000002
【特許請求の範囲】
【請求項１】
第一端末、第二端末、およびサーバを具備し、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記サーバは、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備する情報システム。
【請求項２】
第二端末、およびサーバと共に情報システムを構成する第一端末であって、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記サーバは、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備し、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備する第一端末。
【請求項３】
第一端末、およびサーバと共に情報システムを構成する第二端末であって、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記サーバは、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備し、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備する第二端末。
【請求項４】
第一端末、および第二端末と共に情報システムを構成するサーバであって、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備するサーバ。
【請求項５】
第一端末、および第二端末と共に情報システムを構成するサーバが具備する第一認証コード受信部、第二認証コード受信部、判断部、および入金処理部によって実現される入金処理方法であって、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記第一認証コード受信部が、前記第一端末から認証コードを受信する第一認証コード受信ステップと、
前記第二認証コード受信部が、前記第二端末から認証コードを受信する第二認証コード受信ステップと、
前記判断部が、前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断ステップと、
前記入金処理部が、前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理ステップとを含む入金処理方法。
【請求項６】
第二端末、およびサーバと共に情報システムを構成する第一端末のプログラムであって、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記サーバは、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備し、
前記第一端末のコンピュータを、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部として機能させるためのプログラム。
【請求項７】
第一端末、およびサーバと共に情報システムを構成する第二端末のプログラムであって、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記サーバは、
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備し、
前記第二端末のコンピュータを、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備する第二端末。
【請求項８】
第一端末、および第二端末と共に情報システムを構成するサーバのプログラムであって、
前記第一端末は、
認証コードを取得する取得部と、
前記認証コードを前記サーバおよび前記第二端末に送信する第一送信部とを具備し、
前記第二端末は、
前記第一端末から認証コードを受信する第二受信部と、
前記第二受信部が受信した認証コードを前記サーバに送信する第二送信部とを具備し、
前記サーバのコンピュータを
前記第一端末から認証コードを受信する第一認証コード受信部と、
前記第二端末から認証コードを受信する第二認証コード受信部と、
前記第一認証コード受信部が受信した認証コードと前記第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、
前記判断部が前記認証条件を満たすと判断した場合に入金処理を実行する入金処理部として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、入金処理を行う情報システム等に関するものである。
【背景技術】
【０００２】
従来、複数の金融機関の口座を引落口座として、振込処理を実現可能なポータルインターネットバンキングシステムが存在した（例えば、特許文献１参照）。このシステムは、予め、各インターネットバンキングシステムにログインするためのパスワードなどの認証情報をユーザ毎に登録しておき、ユーザから振込要求が行なわれた場合に、当該認証情報を使用して、引落先の金融機関のインターネットバンキングシステムにアクセスを行ない、振込処理を行うというものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−２９５７５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記従来のシステムでは、振り込みを行いたいユーザは、その都度、ポータルサイトにログインし、振り込み先の口座情報や振り込み内容などを入力していた。
【０００５】
特に、例えば、グループで飲食やカラオケなどを行い、幹事が、全員分の代金を店側に支払った後、その代金を参加者数で割り算したワリカン額を、幹事以外の各参加者に請求するような場面において、各参加者から幹事への入金をインターネットバンキングで気軽に行えれば便利である。しかし、ワリカン額の入金のような、金額が比較的少額で、かつ同じグループのメンバ間での入金であっても、各参加者は、幹事への支払いの度に、ポータルサイトにログインし、幹事の口座情報や振り込む内容を入力するといった、複雑な操作を行う必要があった。
【０００６】
また、他の従来の情報システムにおいても、安全に入金するには、ユーザは、複雑な操作を要していた。
【課題を解決するための手段】
【０００７】
本第一の発明の情報システムは、第一端末、第二端末、およびサーバを具備し、第一端末は、認証コードを取得する取得部と、認証コードをサーバおよび第二端末に送信する第一送信部とを具備し、第二端末は、第一端末から認証コードを受信する第二受信部と、第二受信部が受信した認証コードをサーバに送信する第二送信部とを具備し、サーバは、第一端末から認証コードを受信する第一認証コード受信部と、第二端末から認証コードを受信する第二認証コード受信部と、第一認証コード受信部が受信した認証コードと第二認証コード受信部が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部と、判断部が認証条件を満たすと判断した場合に入金処理を実行する入金処理部とを具備する情報システムである。
【０００８】
かかる構成により、第一端末が認証コードを取得すると、その認証コードは、第二端末経由および非経由の２系統でサーバに伝達され、認証条件を満たすと判断され場合に入金処理が実行されるので、簡単かつ安全に入金が行える。
【０００９】
また、本第二の発明の情報システムは、第一の発明に対して、第一端末は、金額を示す金額情報を受け付ける第一受付部と、金額情報を有する入金依頼を作成する作成部とをさらに具備し、第一送信部は、認証コードと入金依頼とを、サーバおよび第二端末に送信し、第二受信部は、第一端末から認証コードと入金依頼とを受信し、第二端末は、第二受信部が受信した入金依頼に基づいて、入金指示を受け付ける指示画面を出力する第二出力部と、指示画面に対する入金指示を受け付ける第二受付部とをさらに具備し、第二送信部は、第二受付部が入金指示を受け付けたことに応じて、第二受信部が受信した認証コードをサーバに送信し、第一認証コード受信部は、第一端末から入金依頼と認証コードを受信し、入金処理部は、判断部が認証条件を満たすと判断した場合に、入金依頼に対応する入金処理を実行する情報システムである。
【００１０】
かかる構成により、第二端末を経由する系統において、第二端末からサーバへの認証コードの送信は、第二端末による入金指示の受け付けなしでは行われないので、安全かつ簡単に入金が行える。
【００１１】
また、本第三の発明の情報システムは、第二の発明に対して、指示画面は、金額に対応するコインの画像を有し、第二受付部は、指示画面が有するコインに対する操作に基づく入金指示を受け付ける情報システムである。
【００１２】
かかる構成により、直感的な操作で入金指示が行える。
【００１３】
また、本第四の発明の情報システムは、第二または第三の発明に対して、第一端末は、一のグループに属する２以上のユーザのうち第一ユーザの端末であり、第二端末は、２以上のユーザのうち第一ユーザを除く１以上の各第二ユーザの端末であり、サーバは、１以上の各第二ユーザが口座を有する金融機関のサーバである情報システムである。
【００１４】
かかる構成により、グループ内の第一ユーザと１以上の各第二ユーザとの間で、簡単かつ安全に入金が行える。
【００１５】
また、本第五の発明の情報システムは、第四の発明に対して、第一端末は、第一ユーザの口座に関する第一口座情報、および、１以上の各第二ユーザの口座に関する１以上の第二口座情報が格納される第一格納部をさらに具備し、第一送信部は、認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とを、サーバおよび第二端末に送信する情報システムである。
【００１６】
かかる構成により、第一端末が口座情報の管理を行うことで、第二端末やサーバの負担を抑制しつつ、簡単かつ安全に入金が行える情報システムを実現できる。
【００１７】
ただし、第一口座情報や第二口座情報等の口座情報については、サーバにのみ通知し、第二端末には通知しなくてもよい。例えば、第一送信部は、認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とをサーバに送信する一方、第二端末には、認証コードと、金額情報のみを有し、第一口座情報も第二口座情報も有さない入金依頼とを送信してもよい。これによって、第一ユーザは、第二ユーザに口座情報を知らせることなく、第二ユーザから入金を受けることができる。
【００１８】
なお、第五の発明の情報システムにおいて、作成部は、金額の入金を指示する入金指示を受け付ける指示画面を構成するための画面情報をも作成し、第一送信部は、認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とを、サーバに送信し、かつ、認証コードと、金額情報、および画面情報を有する入金依頼を、第二端末に送信することは好適である。
【００１９】
かかる構成により、第一端末が画面情報の作成をも行うことで、第二端末やサーバの負担をさらに抑制しつつ、簡単かつ安全に入金が行える情報システムを実現できる。
【００２０】
また、本第六の発明の情報システムは、第二から第五いずれか１つの発明に対して、サーバは、入金処理部が１以上のいずれかの第二ユーザの口座への入金処理を実行した場合に、入金完了を示す完了通知を第二ユーザのユーザ識別情報と対に第一端末に送信する完了通知送信部をさらに具簡単備し、第一端末は、サーバから第二ユーザのユーザ識別情報と対に完了通知を受信する第一受信部と、完了通知に基づいて、１以上の各第二ユーザの支払いの状況を図的に出力する第一出力部とをさらに具備する情報システムである。
【００２１】
かかる構成により、第一ユーザは、１以上の各第二ユーザからの入金状況を直感的に把握できる。
【００２２】
また、本第七の発明の情報システムは、第六の発明に対して、第一受付部は、一連の各支払いに対応する２以上の金額情報を、異なるタイミングで受け付け、完了通知送信部は、一連の各支払いに対応する完了通知を第二ユーザのユーザ識別情報と対に、一連の支払いであることを識別可能に、第一端末に送信し、第一出力部は、一連の支払いに対応する完了通知に基づいて、一連の支払いのうちのいずれの支払いが完了しているかを識別可能に、１以上の各第二ユーザの支払いの状況を図的に出力する情報システムである。
【００２３】
かかる構成により、第一ユーザは、１以上の各第二ユーザからの入金状況を、一連の支払いごとに、直感的に把握できる。
【００２４】
また、本第八の発明の情報システムは、第二から第七いずれか１つの発明に対して、判断部は、予め決められた期限条件を満たすほど支払いが遅延しているか否かをも判断し、サーバは、判断部が予め決められた期限条件を満たすほど支払いが遅延していると判断した場合に、入金依頼が有する金額情報を用いて、利息を算出する利息算出部をさらに具備、入金処理部は、金額情報と利息算出部が算出した利息とを用いて入金処理を実行する情報システムである。
【００２５】
かかる構成により、支払いが遅延した場合に、利息付きの入金が行える。
【００２６】
また、本第九の発明の情報システムは、第二から第八いずれか１つの発明に対して、サーバは、支払われる権利者の権利者識別子と支払い義務者の義務者識別子と支払う金額である金額情報とを有する２以上の債務情報が格納されるサーバ格納部と、権利者識別子と義務者識別子とが逆である２つの債務情報をサーバ格納部から取得し、取得した２つの債務情報の間で、金額情報が同額である場合は、２つの債務情報を消滅させ、同額でない場合は、２つの債務情報に代えて、低額である金額情報を有する方の債務情報の義務者識別子と、高額である金額情報を有する方の債務情報の権利者識別子と、２つの金額情報の差額とを有する新な債務情報を構成する相殺処理を行う相殺部をさらに具備する情報システムである。
【００２７】
かかる構成により、相殺を行うことで、入金処理を簡素化できる。
【００２８】
また、本第十の発明の情報システムは、第九の発明に対して、相殺部は、取得した２つの債務情報が有する、権利者識別子で識別されるユーザと義務者識別子とで識別されるユーザとが、同じグループに属する場合にのみ相殺処理を行う情報システムである。
【００２９】
かかる構成により、相殺をグループ内に限ることで、入金処理を簡素化しつつ、グループ外の権利者の保護も図ることができる。
【発明の効果】
【００３０】
本発明によれば、簡単かつ安全に入金が行える。
【図面の簡単な説明】
【００３１】
【図１】実施の形態における情報システムのブロック図
【図２】同サーバのブロック図
【図３】同第一端末の動作を説明するフローチャート
【図４】同第二端末の動作を説明するフローチャート
【図５】同サーバの動作を説明するフローチャート
【図６】同更新処理を説明するフローチャート
【図７】同支払い状況情報のデータ構造図
【図８】同債務情報のデータ構造図
【図９】同更新された債務情報を示す図
【図１０】同指示画面の出力例を示す図
【図１１】同その他の画面の出力例を示す図
【図１２】同支払い状況画面の出力例を示す図
【図１３】同コンピュータシステムの内部構成の一例を示す図
【発明を実施するための形態】
【００３２】
以下、情報システム等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動作を行うので、再度の説明を省略する場合がある。
【００３３】
図１は、本実施の形態における情報システムのブロック図である。この情報システムは、第一端末１、１または２以上の第二端末２、およびサーバ３を備える。第一端末１、および１以上の第二端末２の各々は、例えば、ＬＡＮやインターネット等のネットワーク、無線または有線の通信回線などを介して、サーバ３と通信可能に接続される。また、第一端末１と、１以上の各第二端末２との間でも、ネットワークや通信回線等を介した通信が可能である。なお、端末間の通信は、近距離無線通信でも構わない。
【００３４】
第一端末１は、一のグループに属する２または３以上のユーザのうち、第一ユーザの端末である。第二端末２は、かかる２以上のユーザのうち、第一ユーザを除く１または２以上の各第二ユーザの端末である。
【００３５】
グループとは、例えば、行動を共にする２または３人以上のメンバの集合であるといってもよい。行動とは、例えば、飲食、カラオケ等であるが、代金の支払いを要する行動であれば何でもよい。グループは、例えば、飲食店等で忘年会を行った２人以上の客（Ｘさん、Ｙさん、およびＺさんの３人等）の集団であってもよい。忘年会は、例えば、飲食店での一次会、およびカラオケ店での二次会などを含んでいてもよく、その場合の支払いは、２以上の各店での一連の支払いを含む。ただし、以上は例示であり、グループの行動やメンバ数などは問わない。
【００３６】
第一ユーザとは、２人以上のメンバで構成されたグループの代表者である。第一ユーザは、例えば、忘年会の幹事であってもよい。第二ユーザとは、当該グループの、代表者以外の各メンバである。第二ユーザは、例えば、忘年会の、幹事以外の参加者であってもよい。
【００３７】
例えば、忘年会の幹事（例えば、Ｘさん）は、２以上の各店（例えば、一次会の飲食店、および二次会のカラオケ店）において、代金の全額を店側に支払った後、第一端末１を介して、各メンバに対し、その代金の一部（通常、代金を全メンバ数で除算したワリカン額）を自分に支払うよう依頼する。依頼は、第一端末１から各第二端末２に伝えられ、幹事（依頼元）以外の各メンバ（依頼先）は、自分の第二端末２を介して、幹事へのワリカン額の支払いを行う。その際、各メンバは、例えば、各店からの出店の都度、その店でのワリカン額を支払ってもよいし、または、忘年会の散会時もしくは後日、各店でのワリカン額を一括または分割で支払っても構わない。
【００３８】
サーバ３は、１以上の各第二ユーザの口座から第一ユーザの口座への入金処理を行うことにより、上述したような１以上の各第二ユーザから第一ユーザへの支払いを実現する。なお、サーバ３は、第一ユーザおよび１以上の第二ユーザの各々が口座を有する一の銀行のサーバであることは、例えば、入金処理の手数料の軽減が容易な点で好適である。または、サーバ３は、１以上の各銀行のサーバと通信可能な専用サーバまたはクラウドサーバ等であってもよい。この場合、各ユーザは、１以上のどの銀行の口座も利用できる利点がある。ただし、サーバ３は、１以上の各銀行のサーバであってもよく、そのタイプや所在は問わない。
【００３９】
第一端末１のブロック図は、図１に含まれている。第一端末１は、第一格納部１１、第一受付部１２、第一処理部１３、第一送信部１４、第一受信部１５、および第一出力部１６を備える。第一処理部１３は、取得部１３１、および作成部１３２を備える。
【００４０】
第二端末２のブロック図も、図１に含まれている。第二端末２は、第二格納部２１、第二受信部２２、第二送信部２３、第二出力部２４、第二受付部２５、および第二処理部２６を備える。
【００４１】
図２は、サーバ３のブロック図である。サーバ３は、サーバ格納部３１、サーバ受信部３２、サーバ処理部３３、およびサーバ送信部３４を備える。サーバ受信部３２は、第一認証コード受信部３２１、および第二認証コード受信部３２２を備える。サーバ処理部３３は、判断部３３１、入金処理部３３２、利息算出部３３３、および相殺部３３４を備える。サーバ送信部３４は、完了通知送信部３４１を備える。
【００４２】
第一端末１を構成する第一格納部１１は、各種の情報を格納し得る。各種の情報とは、例えば、第一口座情報、第二口座情報などである。なお、その他の情報については、適時説明する。
【００４３】
第一口座情報とは、第一ユーザの口座に関する情報である。第一ユーザとは、前述したごとく、当該第一端末１のユーザである。第一ユーザは、２以上のメンバで構成されたグループの代表者であり、代表者以外のメンバである１以上の第二ユーザからの入金を受ける人である。
【００４４】
口座とは、通常、銀行の口座であるが、例えば、クレジット会社、保険会社、証券会社等、銀行以外の金融機関の口座でもよい。また、口座は、本情報システム専用の口座であることは好適あるが、汎用の口座でもよい。なお、かかる事項は、第二ユーザの口座にも共通する。
【００４５】
第一ユーザの口座は、第二ユーザの口座からの入金処理が可能な口座であれば何でもよい。第一口座情報は、例えば、口座番号、氏名等の情報を含む。第一口座情報には、例えば、残高、入出金の履歴などの情報も含まれていてよい。
【００４６】
第二口座情報とは、第二ユーザの口座に関する情報である。第二ユーザとは、当該第二端末２のユーザである。第二ユーザは、上記グループの代表者以外のメンバであり、代表者である第一ユーザへの入金を行う人である。
【００４７】
第二ユーザの口座は、第１ユーザの口座への入金処理が可能な口座であれば何でもよい。第二口座情報もまた、例えば、口座番号、氏名等の情報を含む。ただし、第二口座情報には、通常、残高等の情報までは含まれないが、含まれていてもよい。
【００４８】
第一格納部１１には、例えば、第一口座情報、および１以上の第二口座情報が予め格納されていることは好適である。ただし、第一口座情報、および１以上の第二口座情報は、例えば、後述するサーバ格納部３１に格納されていてもよい。
【００４９】
また、第一格納部１１には、例えば、第一端末識別子、１または２以上の第二端末識別子、グループ識別子、およびサーバ識別子なども格納されてよい。第一端末識別子とは、第一端末１を識別する情報である。第一端末識別子は、例えば、ＩＰアドレスやＭＡＣアドレス等のアドレスであるが、ＩＤでもよく、第一端末１を識別し得る情報であれば何でもよい。第二端末識別子とは、第二端末２を識別する情報である。第二端末識別子もまた、アドレスやＩＤ等であるが、第二端末２を識別し得る情報であれば何でもよい。グループ識別子とは、第一ユーザおよび１以上の第二ユーザが属するグループを識別する情報である。グループ識別子は、例えば、ＩＤであるが、ＩＤに対応付いたニックネーム等でもよく、グループを識別し得る情報であれば何でもよい。サーバ識別子とは、サーバ３を識別する情報である。サーバ識別子もまた、アドレスやＩＤ等であるが、サーバ３を識別し得る情報であれば何でもよい。
【００５０】
第一受付部１２は、金額情報を受け付ける。金額情報とは、金額を示す情報である。金額とは、例えば、幹事が店に支払った代金でもよいし、幹事に支払うべきワリカン額でもよい。金額情報は、グループのメンバ全員で支払うべき代金を示す情報でもよいし、メンバ一人一人が支払うべきワリカン額を示す情報でもよい。なお、ワリカン額は、必ずしもメンバ間で同額でなくてもよい。
【００５１】
第一受付部１２は、例えば、ワリカン額を示す金額情報を受け付けてもよい。または、第一受付部１２は、代金を示す金額情報を受け付け、その代金をメンバ数で除算することにより、ワリカン額を取得してもよい。なお、ワリカン額がメンバ間で同額でない場合、第一受付部１２は、１以上のメンバごとにワリカン額を受け付けてもよい。
【００５２】
第一受付部１２は、例えば、一連の各支払いに対応する２以上の金額情報を、異なるタイミングで受け付けることは好適である。一連の各支払いとは、例えば、前述した忘年会の一次会、二次会等であってもよい。異なるタイミングとは、例えば、一次会の後、二次会の後等であってもよい。
【００５３】
また、第一受付部１２は、一連の各支払いに対応する２以上の各金額情報を受け付ける際に、例えば、属性情報および順序情報をも受け付けることは好適である。属性情報とは、一連の支払いに共通の属性を示す情報である。属性情報は、例えば、“忘年会”等のイベント名でもよいし、“○月○日”等の日付でも構わない。順序情報とは、一連の支払いの順序を示す情報である。順序情報は、例えば、“１”や“２”等の番号でも、“一次会”や“二次会”等の文字列でもよく、順序を示し得る情報であれば、その表現形式は問わない。
【００５４】
第一処理部１３は、各種の処理を行う。各種の処理とは、例えば、後述する取得部１３１、後述する作成部１３２などの処理である。各種の処理には、フローチャートで説明する各種の判別なども含まれる。
【００５５】
取得部１３１は、認証コードを取得する。認証コードとは、依頼された入金処理の正当性をサーバ３が確認するための情報であるといってもよい。認証コードは、例えば、英数字や各種記号を２以上組み合わせた文字列であってもよい。
【００５６】
認証コードは、例えば、動的な認証コードであることは好適である。動的な認証コードとは、２以上の入金処理ごとに変化する認証コードであり、例えば、ワンタイムパスワードであってもよい。ワンタイムパスワードとは、一の入金処理に対して、一度限り有効なパスワードである。ワンタイムパスワード等の動的な認証コードは、例えば、当該入金処理を識別する入金処理識別子としても機能し得る。
【００５７】
ただし、認証コードは、静的な認証コードでもよい。静的な認証コードとは、２以上の入金処理に共通の認証コードであり、例えば、予め決められたパスワードでもよい。予め決められたパスワードとは、例えば、ユーザが決めたパスワードでもよいし、サーバ３等の外部装置で決定され、ユーザに通知されたパスワードでもよい。
【００５８】
取得とは、例えば、手入力を受け付けることでもよいし、外部装置（例えば、サーバ３や、図示しないパスワードカード等）から受信することでもよいし、自動的に生成することでもよい。
【００５９】
取得部１３１は、例えば、認証コードの手入力を、キーボードやタッチパネル等の入力デバイスを介して受け付けてもよい。手入力される認証コードは、例えば、予め決められたパスワード等の静的な認証コードでもよいし、パスワードカードによって生成および表示されたワンタイムパスワード等の動的なパスワードでも構わない。
【００６０】
または、取得部１３１は、例えば、ワンタイムパスワードの要求を外部装置に送信し、外部装置からワンタイムパスワードを受信してもよい。または、取得部１３１は、例えば、予め決められたアルゴリズムに従い、自らワンタイムパスワードを生成してもよい。
【００６１】
なお、取得部１３１は、例えば、第一受付部１２が金額情報を受け付けたことに応じて、または、後述する作成部１３２が入金依頼を作成したことに応じて、認証コードを取得する。ただし、後述する第一送信部１４による送信の前であれば、認証コードの取得のタイミングやトリガは問わない。
【００６２】
また、取得部１３１は、一の金額情報に対し、通常、１以上の第二ユーザごとに、認証コードを取得する。ただし、取得部１３１は、一の金額情報に対し、１つの認証コードを取得してもよい。後者の場合、一の金額情報に対して取得された認証コードは、１以上の第二ユーザに共通の認証コードとなる。
【００６３】
作成部１３２は、入金依頼を作成する。入金依頼とは、第二ユーザに対する入金の依頼であり、サーバ３に対する入金処理の実行の依頼でもある。入金依頼は、通常、取得部１３１が取得した金額情報を有する。また、入金依頼は、例えば、口座情報をも有することは好適である。口座情報は、銀行等の金融機関の口座に関する情報である。入金依頼が有する口座情報は、例えば、入金先口座情報、および入金元口座情報を含む。入金先口座情報とは、入金先である第一ユーザの口座に関する情報であり、入金元口座情報とは、入金元である第二ユーザの口座に関する情報である。口座に関する情報とは、例えば、口座番号、および氏名等であってもよい。ただし、口座情報は、サーバ３で管理されてもよい。
【００６４】
作成部１３２は、一の金額情報に対し、通常、１以上の第二ユーザごとに、入金依頼を作成する。ただし、取得部１３１は、一の金額情報に対し、１つの入金依頼を作成してもよい。後者の場合、一の金額情報に対して作成された入金依頼は、１以上の第二ユーザに対する共通の入金依頼となる。
【００６５】
作成部１３２は、例えば、指示画面を構成するための画面情報をも作成することは好適である。指示画面とは、第二端末２において出力される画面であり、第二ユーザによる入金指示を受け付けるための画面である。指示画面は、通常、金額情報が示す金額に対応する画像または文字列のうち１種類以上を有する。入金指示とは、第一ユーザの口座への入金の指示であり、金額情報が示す金額の入金の指示である。指示画面に対する入金指示は、例えば、一の支払いに対応する金額情報が示す金額の入金指示であってもよいし、一連の支払いに対応する２以上の金額情報のうち、一の金額情報が示す金額の入金指示であってもよい。
【００６６】
なお、画面情報は、１以上の各第二端末２において作成されてもよいが、特に、第二端末の数が多い場合は、第一端末１が作成して、１以上の各第二端末に送信した方が効率的であり、第二端末の負担を抑制できる。
【００６７】
指示画面は、例えば、金額情報が示す金額に対応するコインの画像を有していてもよい。コインとは、通常、硬貨であるが、例えば、紙幣、小切手、カード等も含んでよい。コインの画像は、通常、硬貨またはそれを模した図案の画像であるが、例えば、札束やカードの図案、銀行のシンボルマーク等の画像でもよく、支払い機能を視覚的に示し得る画像であれば何でもよい。なお、指示画面は、コインの画像に対応付けて、金額情報が示す金額に対応する文字列（例えば、“￥４０００”等）をも有していてよい。
【００６８】
詳しくは、指示画面は、例えば、一の支払いに対応する金額情報が示す金額に対応する１つのコインの画像を有していてもよい。または、指示画面は、例えば、一連の支払いに対応する２以上の金額情報が示す金額に対応する２以上のパーツで構成された１つのコインの画像を有していてもよい。
【００６９】
すなわち、例えば、一連の２回の支払いに対応するコインの画像は、１回目の支払いに対応付いた第一パーツ、および２回目の支払いに対応付いた第二パーツで構成される。この場合、第一パーツは、例えば、コインの中央部であり、第二パーツは、コインの当該中央部以外の部分であってもよい。中央部とは、例えば、コインの外周に対応する円（以下、外円と記す場合がある）よりも小さな同心円の内部（以下、円盤状のパーツと記す場合がある）であり、中央部以外の部分とは、当該同心円と外円との間のリング状の部分（以下、リング状のパーツと記す場合がある）であってもよい。
【００７０】
同様に、例えば、一連の３回の支払いに対応するコインの画像は、１回目の支払いに対応付いた第一パーツ、２回目の支払いに対応付いた第二パーツ、および３回目の支払いに対応付いた第三パーツで構成され、第一パーツは、例えば、外円よりも小さな第一同心円の内部であり、第二パーツは、当該第一同心円と、当該第一円より大かつ外円より小である第二同心円との間の第一リング部であり、第三パーツは、第二同心円と外円との間の第二リング部であってもよい。
【００７１】
一般に、一連のＮ回（ただし、Ｎは２以上の整数）の支払いに対応するコインの画像は、１回目の支払いに対応付いた第一パーツから、Ｎ回目の支払いに対応付いた第二パーツまでのＮ個のパーツで構成され、第一パーツは、例えば、（Ｎ−１）個の同心円のうち最も小さな第一同心円の内部であり、第２〜第Ｎパーツは、第１〜第（Ｎ−１）同心円の間の第１〜第（Ｎ−１）リング部であってもよい。
【００７２】
ただし、指示画面は、例えば、一連の支払いに対応する２以上の金額情報が示す金額に対応する２以上のコインの画像を有していてもよい。または、指示画面は、コインの画像に代えて、例えば、ボタンの画像を有していてもよく、一連の支払いに対応する２以上の金額情報のうち、一の金額情報が示す金額の入金指示を受け付け可能な画面であれば、その構成は問わない。また、指示画面は、例えば、支払いの依頼に関連するメッセージ（例えば、「幹事のＸ様からのお支払い依頼です」、「コインを投げるとＸ様への支払いが実行されます」等）も有していてよい。
【００７３】
指示画面を構成するための画面情報は、例えば、画像データ、文字データ、およびレイアウト情報などを有する。画像データは、コインの画像のデータである。文字データは、第二ユーザへのメッセージを示す文字列のデータである。レイアウト情報は、こうした画像や文字列の指示画面内における配置（例えば、位置、サイズ、表示態様等）を示す情報である。
【００７４】
第一送信部１４は、各種の情報を送信する。各種の情報とは、例えば、認証コード、金額情報、入金依頼、画面情報等である。
【００７５】
第一送信部１４は、例えば、取得部１３１が取得した認証コードを、サーバ３および１以上の第二端末２に送信する。第一送信部１４は、例えば、取得部１３１が取得した認証コードと、第一受付部１２が受け付けた金額情報とを、サーバ３および１以上の第二端末２に送信してもよい。
【００７６】
または、第一送信部１４は、例えば、取得部１３１が取得した認証コードと、作成部１３２が作成した入金依頼であり、金額情報を含む入金依頼とを、サーバ３および１以上の第二端末２に送信してもよい。なお、送信される入金依頼は、作成された入金依頼と同じでなくてもよい。また、サーバ３に送信される入金依頼と、第二端末２に送信される入金依頼とは同じでなくてもよい。例えば、サーバ３への入金依頼が金額情報および口座情報を含むのに対し、第二端末２への入金依頼は、口座情報を含まず、金額情報だけでもよいし、金額情報および画面情報を含んでもよい。口座情報がサーバ３で管理されている場合には、サーバ３への入金依頼も、口座情報を含まず、例えば、金額情報および１以上の第二ユーザ識別子を含んでもよい。
【００７７】
すなわち、第一送信部１４は、例えば、取得部１３１が取得した認証コードと、金額情報および口座情報を有する入金依頼とを、サーバ３および１以上の第二端末２に送信してもよい。その際、第一送信部１４は、第二端末２への入金依頼には、作成部１３２が作成した画面情報をさらに含めて送信してもよい。
【００７８】
または、第一送信部１４は、例えば、取得部１３１が取得した認証コードと、金額情報および口座情報を有する入金依頼とを、サーバ３に送信し、かつ、取得部１３１が取得した認証コードと、金額情報および画面情報を有する入金依頼を、第二端末２に送信してもよい。
【００７９】
第一送信部１４は、第一端末識別子または第一ユーザ識別子のうち１種類以上の情報と対に、認証コード等の情報を送信する。第一ユーザ識別子とは、第一ユーザを識別する情報である。第一ユーザ識別子は、例えば、メールアドレスやＩＤ等であるが、第一ユーザを識別し得る情報であれば何でもよい。第一ユーザ識別子は、第一端末識別子と兼用でも構わない。
【００８０】
第一送信部１４は、例えば、第一ユーザ識別子およびグループ識別子と対に、認証コード等の情報を送信してもよい。
【００８１】
なお、以上のような第一送信部１４の動作において、認証コード等の１以上の第二端末２への送信は、例えば、第二端末２ごとの送信指示に応じた個別送信でもよいし、一の送信指示に応じた一斉送信でも構わない。また、後者の場合、認証コード等のサーバ３への送信もまた、当該一の送信指示に応じて、１以上の第二端末２への一斉送信と共に実行されてもよい。
【００８２】
第一受信部１５は、各種の情報を受信する。各種の情報とは、例えば、完了通知である。
【００８３】
第一受信部１５は、サーバ３から完了通知を受信する。完了通知とは、入金の完了を通知するための情報である。完了通知は、サーバ３において、後述する入金処理部３３２が、１以上のいずれかの第二ユーザの口座から第一ユーザの口座への入金処理を実行した場合に、後述する完了通知送信部３４１が第一端末１に送信する情報である。完了通知は、例えば、残高情報を有していてもよい。残高情報とは、入金先口座である第一ユーザの口座の残高に関する情報をいう。残高情報は、例えば、入金処理の前の残高と、入金処理の後の残高とを含んでいてもよい。さらに、残高情報は、例えば、入金された金額を示す金額情報をも含んでいてよい。
【００８４】
第一受信部１５は、第一送信部１４が認証コード等をサーバ３および１以上の第二端末２に送信し、１以上の各第二端末２において、認証コード等が受信され、入金指示が受け付けられ、認証コードがサーバ３に送信され、サーバ３において、１以上の各第二ユーザの口座から第一ユーザの口座への入金処理が行われたことに応じて、サーバ３から、実行された入金処理に対応する第二ユーザ識別子または第二端末識別子のうち１種類以上の情報と対に、１以上の完了通知を受信する。
【００８５】
第一受信部１５は、サーバ３から、一連の支払いに対応する２以上の完了通知を受信してもよい。その際、第一受信部１５は、サーバ３から、例えば、実行された入金処理に対応する組情報と対に、２以上の完了通知を受信することは好適である。組情報とは、第二ユーザ識別子、属性情報、および順序情報などの組である。
【００８６】
組情報は、例えば、第二ユーザ識別子“Ｙ”、属性情報“忘年会”、および順序情報“一次会”の組、第二ユーザ識別子“Ｙ”属性情報“忘年会”、および順序情報“一次会”の組、第二ユーザ識別子“Ｚ”属性情報“忘年会”、および順序情報“一次会”の組、第二ユーザ識別子“Ｚ”属性情報“忘年会”、および順序情報“二次会”の組等であってもよい。なお、組情報は、例えば、グループ識別子をさらに有していてもよい。
【００８７】
第一出力部１６は、第一受信部１５が受信した完了通知に基づいて、１以上の各第二ユーザの支払いの状況を図的に出力する。図的に出力することは、例えば、支払い状況画面を構成し、ディスプレイ等の出力デバイスを介して出力することであってもよい。支払い状況画面とは、１以上の各第二ユーザの支払いの状況を示す画面である。支払い状況画面は、例えば、第二ユーザに対応するアイコンの画像、および金額に対応するコインの画像の組を、２組以上、有していてもよい。または、支払い状況画面は、例えば、１以上の第二ユーザ識別子が記載された第一レコードと、当該１以上の第二ユーザ識別子に対応付けて“完了”または“未完了”が記載される第二レコードとで構成された表を有していてもよく、その構成は問わない。
【００８８】
具体的には、第一出力部１６は、例えば、上記のようなアイコンの画像およびコインの画像の組を２組以上有する支払い状況画面を構成し、ディスプレイに表示してもよい。
【００８９】
第一出力部１６は、例えば、一の支払いに対する完了通知であり、第二ユーザ識別子と対に受信された完了通知に基づいて、どの第二ユーザからの支払いが完了しているかを識別可能に、１以上の各第二ユーザの支払いの状況を図的に出力してもよい。
【００９０】
支払いの完了または未完了を第二ユーザごとに識別可能に出力することは、例えば、支払いが完了している第二ユーザと完了していない第二ユーザとの間で、アイコンまたはコインのうち１種類以上の画像の表示態様（例えば、色、明るさ、コントラスト等）を異ならせることであってもよい。
【００９１】
または、支払いの完了または未完了を第二ユーザごとに識別可能に出力することは、例えば、支払いが完了した第二ユーザのアイコンまたはコインの画像に、“支払済み”等の文字列や、支払完了を示すマーカ等を対応付けることでも構わない。
【００９２】
具体的には、第一出力部１６は、例えば、上記支払い状況画面において、支払いが完了した１以上の各第二ユーザに関し、対応するコインの画像をグレーアウトしたり、対応するアイコンに支払完了を示すマーク等を対応付けたりしてもよい。
【００９３】
または、第一出力部１６は、例えば、一連の支払いに対応する完了通知であり、組情報と対に受信された完了通知に基づいて、一連の支払いのうちのいずれの支払いが完了しているかを識別可能に、１以上の各第二ユーザの支払いの状況を図的に出力することは好適である。
【００９４】
一連の支払いの完了または未完了を第二ユーザごとに識別可能に出力することは、例えば、１以上の各第二ユーザのアイコンに対応付いていている一のコインの画像を、一連の支払いに対応する２以上のパーツ（コインの中央の円、その円の周囲のリング等）で構成し、完了している支払いに対応するパーツと、完了していない支払いに対応するパーツとの間で、表示態様（例えば、色、明るさ、コントラスト等）を異ならせることであってもよい。
【００９５】
または、識別可能に出力することは、例えば、支払いが完了したパーツに、“支払済み”等の文字列や、支払完了を示すマーカ等を対応付けることでも構わない。
【００９６】
あるいは、識別可能に出力することは、例えば、１以上の各第二ユーザのアイコンに、一連の支払いに対応する２以上のコインを対応付け、完了している支払いに対応するコインと、完了していない支払いに対応するコインとの間で、表示態様を異ならせることでもよいし、支払いが完了したコインに“支払済み”等の文字列やマーカ等を対応付けることでも構わない。
【００９７】
具体的には、第一出力部１６は、例えば、上記支払い状況画面において、１以上の各第二ユーザのアイコンに対応付いていている一のコインの画像を、一連の支払いに対応する２以上のパーツで構成し、一連の支払いに対応する完了通知であり、組情報と対に受信された完了通知に基づいて、完了した支払いに対応するパーツの画像をグレーアウトしたり、対応するパーツに支払完了を示すマーク等を対応付けたりしてもよい。
【００９８】
第一出力部１６は、例えば、画面情報と、１以上の支払い状況情報とを保持しており、これら画面情報および１以上の支払い状況情報を用いて、上述したような支払い状況画面を構成してもよい。
【００９９】
支払い状況画面を構成するための画面情報もまた、例えば、画像データ、文字データ、およびレイアウト情報などを有する。ただし、画像データは、コインまたはそれを構成する２以上のパーツの画像のデータであり、文字データは、第一ユーザへのメッセージを示す文字列のデータである点が異なる。
【０１００】
支払い状況情報とは、支払いの状況に関する情報である。支払い状況情報は、例えば、第二ユーザ識別子、金額情報、および入金完了フラグなどを有する。入金完了フラグは、入金が完了したか否かを示す情報である。入金完了フラグは、例えば、“未完了”または“完了”のいずれかを示す。ただし、入金完了フラグは、“完了”のみを示してもよく、その場合、支払い状況情報が入金完了フラグを欠いていることで、“未完了”の状態が示される。また、支払い状況情報は、例えば、グループ識別子も有していてよい。さらに、一連の支払いに対応する支払い状況情報の場合、例えば、属性情報および順序情報をも有していることは好適である。
【０１０１】
第一出力部１６は、例えば、第一受付部１２が金額情報を受け付けるたびに、１以上の第二ユーザに対応する１以上の支払い状況情報を構成し、内部メモリ等に蓄積してもよい。ここで構成される１以上の各支払い状況情報は、第二ユーザ識別子、当該金額情報、および“未完了”を示す入金完了フラグを有する。こうして構成された１以上の支払い状況情報は、取得部１３１が取得した認証コードと対に蓄積されることは好適である。そして、第一出力部１６は、例えば、第一受信部１５が、第二ユーザ識別子と対に完了通知を受信するたびに、当該第二ユーザ識別子に対応する支払い状況情報が有する入金完了フラグを“未完了”から“完了”に更新してもよい。
【０１０２】
または、第一出力部１６は、例えば、第一受付部１２が、一連の支払いに対応する１以上の各金額情報を属性情報および順序情報と共に受け付けるたびに、１以上の第二ユーザに対応する１以上の支払い状況情報を構成し、内部メモリ等に蓄積してもよい。ここで構成される１以上の各支払い状況情報は、第二ユーザ識別子、当該金額情報、当該属性情報、当該順序情報、および“未完了”を示す入金完了フラグを有する。こうして構成された１以上の支払い状況情報もまた、取得部１３１が取得した認証コードと対に蓄積されることは好適である。そして、第一出力部１６は、第一受信部１５が、組情報と対に完了通知を受信するたびに、当該組情報に対応する支払い状況情報が有する入金完了フラグを“未完了”から“完了”に更新してもよい。
【０１０３】
第一出力部１６は、入金完了フラグが“未完了”を示す支払い状況情報に対応するコインまたはパーツを通常の態様で表示し、入金完了フラグが“完了”を示す支払い状況情報に対応するコインまたはパーツをグレーアウトされた態様で表示してもよい。
【０１０４】
第二端末２を構成する第二格納部２１は、各種の情報を格納し得る。各種の情報とは、例えば、第二端末識別子、グループ識別子、サーバ識別子などである。
【０１０５】
第二受信部２２は、各種の情報を受信する。各種の情報とは、例えば、認証コード、入金依頼などである。
【０１０６】
第二受信部２２は、第一端末１から認証コードを受信する。第二受信部２２は、第一端末１から、認証コードと、金額情報とを受信してもよい。
【０１０７】
または、第二受信部２２は、第一端末１から、認証コードと、金額情報を含む入金依頼とを受信してもよい。なお、前述したように、入金依頼には、口座情報または画面情報のうち１種類以上の情報が、さらに含まれていてもよい。
【０１０８】
すなわち、第二受信部２２は、第一端末１から、例えば、認証コードと、金額情報および口座情報を含む入金依頼とを受信してもよい。または、第二受信部２２は、第一端末１から、例えば、認証コードと、金額情報および画面情報を含む入金依頼とを受信してもよい。または、第二受信部２２は、第一端末１から、例えば、認証コードと、金額情報、口座情報、および画面情報を含む入金依頼とを受信してもよい。
【０１０９】
第二受信部２２は、第一端末１から、例えば、第一端末識別子または第一ユーザ識別子のうち１種類以上の情報と対に、認証コード等の情報を受信してもよい。第二受信部２２は、第一端末１から、例えば、第一ユーザ識別子およびグループ識別子と対に、認証コード等の情報を受信してもよい。
【０１１０】
第二送信部２３は、各種の情報を送信する。各種の情報とは、例えば、認証コードなどである。
【０１１１】
第二送信部２３は、第二受信部２２が受信した認証コードをサーバ３に送信する。
【０１１２】
第二送信部２３は、後述する第二受付部２５が入金指示を受け付けたことに応じて、第二受信部２２が受信した認証コードをサーバ３に送信してもよい。
【０１１３】
第二送信部２３は、通常、当該第二端末２を識別する第二端末識別子、または当該第二端末２のユーザを識別するユーザ識別子のうち１種類以上の情報と対に、認証コードをサーバ３に送信する。
【０１１４】
なお、第二送信部２３は、第二受信部２２が受信した口座情報もサーバ３に送信してよい。
【０１１５】
第二出力部２４は、各種の情報を出力する。各種の情報とは、例えば、指示画面などである。一般に、出力とは、例えば、ディスプレイへの表示、スピーカからの音出力、外部の装置への送信、プリンタでのプリントアウト、記録媒体への蓄積、他の処理装置や他のプログラムなどへの処理結果の引渡しなどを含む概念である。第二出力部２４は、通常、ディスプレイを介して、指示画面を出力する。
【０１１６】
第二出力部２４は、第二受信部２２が認証コードおよび入金依頼を受信したことに応じて、指示画面を出力する。
【０１１７】
第二出力部２４は、第二受信部２２が受信した入金依頼が有する金額情報および画面情報に基づいて、指示画面を構成し、ディスプレイに表示することは好適である。または、第二出力部２４は、画面情報を保持しており、第二受信部２２が受信した金額情報と、保持している画面情報とに基づいて、指示画面を構成し、ディスプレイに表示してもよい。なお、画面情報は、後述する第二処理部２６が作成してもよく、その場合、第二出力部２４は、第二受信部２２が受信した金額情報と、第二処理部２６が作成した画面情報とに基づいて、指示画面を構成してもよい。
【０１１８】
出力される指示画面は、例えば、受信された金額情報に対応するコインの画像を有する。例えば、受信された金額情報が一の支払いに対応する１つの金額情報を有する場合、第二出力部２４は、その金額情報に対応する１つのコインの画像を有する指示画面を構成し、出力する。また、受信された金額情報が一連の支払いに対応する２以上の金額情報を有する場合、第二出力部２４は、それら２以上の金額情報に対応する２以上のコインの画像を有する指示画面を構成し、出力する。
【０１１９】
また、出力される指示画面は、受信された画面情報が有する文字データに対応するメッセージをも有することは好適である。第二出力部２４は、例えば、１つのコインの画像を有する指示画面に、第一のメッセージ“グループａの忘年会  幹事のＸ様からのお支払い依頼です”、および第二のメッセージ“コインを投げるとＸ様への支払いが実行されます”を表示してもよい。また、第二出力部２４は、２以上のコインの画像を有する指示画面に、上記第一および第二のメッセージに加えて、第三のメッセージ“一・二次会の代金を別々に支払うこともできます（一次会代は外側のリングを、二次会代はコインの真ん中を、画面の外にスワイプしてください。）”をも出力することは好適である。
【０１２０】
また、第二出力部２４は、第二受信部２２がサーバ３から完了通知を受信したことに応じて、その完了通知を出力してもよい。なお、出力される完了通知は、受信された完了通知と同じでなくてもよい。
【０１２１】
第二受付部２５は、各種の情報を受け付ける。各種の情報とは、例えば、入金指示などである。入金指示とは、前述したように、第一ユーザの口座への入金の指示であり、金額情報が示す金額の入金の指示である。一般に、受け付けとは、タッチパネルやマウスやキーボード等の入力デバイスから入力された情報の受け付け、ネットワークや通信回線等を介して送信された情報の受信、ディスクや半導体メモリなどの記録媒体から読み出された情報の受け付けなどを含む概念である。ただし、第二受付部２５による入金指示の受け付けは、通常、タッチパネルやマウス等の入力デバイスを介した受け付けである。
【０１２２】
第二受付部２５は、例えば、出力された指示画面が有するコインに対する操作に基づく入金指示を受け付ける。コインに対する操作とは、通常、コインを投げる態様の操作である。コインを投げる態様の操作とは、例えば、指示画面が有するコインの画像に対するスワイプやフリック、ドラッグ等の操作であってもよい。ただし、コインに対する操作は、例えば、コインに触れる態様の操作でもよく、コインに対する操作であれば、その態様は問わない。
【０１２３】
具体的には、第二受付部２５は、例えば、ディスプレイに表示されている指示画面上のコインの画像に対するスワイプやドラッグ等の操作を、タッチパネルやマウス等の入力デバイスを介して受け付けてもよい。
【０１２４】
第二処理部２６は、各種の処理を行う。各種の処理とは、例えば、フローチャートで説明する各種の判別等の処理である。なお、第二処理部２６は、前述したような画面情報を作成する処理を行ってもよい。
【０１２５】
サーバ３を構成するサーバ格納部３１は、各種の情報を格納し得る。各種の情報とは、例えば、債務情報などである。債務情報とは、債務に関する情報である。債務情報は、例えば、権利者識別子と、義務者識別子と、金額情報とを有する。権利者識別子とは、支払われる権利者を識別する情報である。例えば、権利者識別子は、第一ユーザ識別子およびグループ識別子を有し、義務者識別子は、第二ユーザ識別子およびグループ識別子を有していてもよい。
【０１２６】
金額情報とは、義務者が権利者に支払う金額を示す情報である。金額情報は、前述した第一端末１の第一受付部１２が受け付ける金額情報と同じでよい。具体的には、例えば、グループａに属するユーザＸが、同じグループａのユーザＹに対して４０００円を支払う義務を有する場合、権利者識別子は“Ｙ＠ａ”、義務者識別子は“Ｘ＠ａ”のように表現されてもよい。ただし、権利者識別子および義務者識別子の構成や表現形式は問わない。
【０１２７】
なお、債務情報は、例えば、予め、サーバ格納部３１に格納されていてもよいし、または、後述する第一認証コード受信部３２１によって、第一端末１から認証コードと共に受信された入金依頼を用いて作成され、サーバ格納部３１に蓄積されてもよい。
【０１２８】
サーバ格納部３１には、例えば、２以上の債務情報が格納される。２以上の各債務情報は、例えば、認証コードまたは時刻情報のうち１種類以上の情報に対応付けて格納されることは好適である。例えば、第二受信部２２が第一端末１から認証コードと入金依頼とを受信した場合に、サーバ処理部３３が、内蔵時計やＮＴＰサーバ等から現在時刻を示す時刻情報を取得し、受信された入金依頼を用いて債務情報を構成し、構成した債務情報を当該認証コードおよび当該時刻情報に対応付けてサーバ格納部３１に蓄積してもよい。
【０１２９】
なお、サーバ格納部３１には、例えば、１または２以上の各グループ識別子に対応付けて、第一端末識別子、第一ユーザ識別子、１以上の第二端末識別子、および１以上の第二ユーザ識別子などが格納されてもよい。また、サーバ格納部３１には、第一または第二のユーザ識別子に対応付いた２以上の口座情報も格納されてよい。
【０１３０】
サーバ受信部３２は、各種の情報を受信する。各種の情報とは、例えば、認証コード、入金依頼等である。
【０１３１】
第一認証コード受信部３２１は、第一端末１から認証コードを受信する。第一認証コード受信部３２１は、第一端末１から、例えば、認証コードと入金依頼とを受信してもよい。第一認証コード受信部３２１は、第一端末１から、例えば、第一端末識別子または第一ユーザ識別子のうち１種類以上の情報と対に、入金依頼等を受信してもよい。
【０１３２】
第二認証コード受信部３２２は、第二端末２から認証コードを受信する。第二認証コード受信部３２２は、第二端末２から、通常、第二端末識別子または第二ユーザ識別子のうち１種類以上の情報と対に、認証コードを受信する。
【０１３３】
なお、第二認証コード受信部３２２は、第二端末２から口座情報も受信してよい。
【０１３４】
また、第二認証コード受信部３２２は、通常、第二端末２から直接、認証コード等を受信するが、例えば、第二端末２から、第二ユーザの口座を管理する銀行（第二銀行と記す場合もある）のサーバ（図示しない）を経由して、認証コード等を受信してもよい。このように、セキュリティの確保が可能であれば、第二端末２からサーバ３への認証コード等の伝達経路は問わない。
【０１３５】
サーバ処理部３３は、各種の処理を行う。各種の処理とは、例えば、後述する判断部３３１、後述する入金処理部３３２、後述する利息算出部３３３、後述する相殺部３３４などの処理である。各種の処理には、フローチャートで説明する各種の判別なども含まれてよい。
【０１３６】
判断部３３１は、第一認証コード受信部３２１が受信した認証コードと、第二認証コード受信部３２２が受信した認証コードとが、予め決められた認証条件を満たすか否かを判断する。認証条件は、例えば、第一認証コード受信部３２１が受信した認証コードと、第二認証コード受信部３２２が受信した認証コードとが一致することであってもよい。または、認証条件は、例えば、第一認証コード受信部３２１がユーザ識別子と対に受信した認証コードと、第二認証コード受信部３２２がユーザ識別子と対に受信した認証コードとが一致し、かつ、当該２つのユーザ識別子が同じグループ識別子に対応付いていることであってもよい。
【０１３７】
なお、認証条件は、口座情報に関する条件をも含んでいてよい。口座情報に関する条件は、具体的には、第一認証コード受信部３２１が第一端末１から認証コードと共に受信した入金依頼に含まれる口座情報と、第二認証コード受信部３２２が第二端末２から認証コードを共に受信した口座情報とが、一致することであってもよい。判断部３３１は、例えば、認証コードが一致しても、口座情報が一致しなければ、認証条件を満たさないと判断してもよい。
【０１３８】
また、判断部３３１は、予め決められた期限条件を満たすほど支払いが遅延しているか否かの判断も行い得る。期限条件は、例えば、予め決められた期日を過ぎても入金されないことであってもよい。期日は、例えば、月末でもよいし、〇月〇日等の特定の日付でも構わない。または、期限条件は、例えば、予め決められた期間が経過しても入金されないことであってもよい。期間は、例えば、１週間や１カ月等であってもよく、その長さは問わない。
【０１３９】
詳しくは、判断部３３１は、例えば、サーバ格納部３１に格納されている２以上の各債務情報に対し、当該債務情報に対応付いている時刻情報と、内蔵時計等から取得した現在時刻を用いて、予め決められた期限条件を満たすほど支払いが遅延しているか否かを判断してもよい。例えば、ある債務情報に対応付いた時刻情報が“２０１７／１１／１０”であり、期限条件が「月末を過ぎても入金されないこと」であり、現在時刻が“２０１７／１２／１”である場合、判断部３３１は、その債務情報に対応付いた時刻情報が属する月（１１月）と、現在時刻が属する月（１２月）とが異なることから、その債務情報に対応する支払が遅延していると判断する。
【０１４０】
入金処理部３３２は、入金処理を行う。入金処理とは、前述したように、１以上の各第二ユーザの口座から第一ユーザの口座への入金の処理である。入金の処理とは、自ら入金する処理に限らず、例えば、他の銀行等のサーバに対し、入金を指示する処理などでもよい。入金は、通常、第二ユーザの口座から第一ユーザの口座への振り込みであり、振り込みは、電信扱いが好適であるが、例えば、文書扱いでもよいし、振り込みの予約でも構わない。または、入金は、例えば、小切手や為替証書などを利用した金銭の移動でもよい。小切手等による入金の処理は、例えば、小切手等を発行する処理、小切手等の金額を第二ユーザの口座の残高から減算する処理、同額を第一ユーザの口座の残高に加算する処理などを含んでいてもよい。このように、入金処理は、第二ユーザから第一ユーザへの支払いを実現するための入金に関する処理であれば何でもよく、入金を行う主体や手順やタイミングも問わない。
【０１４１】
入金処理部３３２は、通常、判断部３３１が認証条件を満たすと判断した場合に入金処理を実行する。詳しくは、入金処理部３３２は、例えば、判断部３３１が、第一認証コード受信部３２１が受信した認証コードと第二認証コード受信部３２２が受信した認証コードとが認証条件を満たすと判断した場合に、第一認証コード受信部３２１が認証コードと共に受信した入金依頼に対応する入金処理を実行する。
【０１４２】
入金処理部３３２は、第一認証コード受信部３２１が認証コードと共に受信した入金依頼に含まれている金額情報を用いて、第二認証コード受信部３２２が認証コードと対に受信した第二ユーザ識別子に対応する口座から、第一認証コード受信部３２１が認証コード等と対に受信した第一ユーザ識別子に対応する口座への入金処理を実行してもよい。
【０１４３】
または、入金処理部３３２は、第一認証コード受信部３２１が認証コードと共に受信した入金依頼に含まれている金額情報と、後述する利息算出部３３３が算出した利息とを用いて、かかる入金処理を実行してもよい。
【０１４４】
利息算出部３３３は、判断部３３１が予め決められた期限条件を満たすほど支払いが遅延していると判断した場合に、入金依頼が有する金額情報を用いて、利息を算出する。なお、入金依頼が有する金額情報とは、当該入金依頼に対応する債務情報が有する金額情報でも構わない。
【０１４５】
利息算出部３３３は、例えば、利率情報を保持しており、サーバ格納部３１に債務情報と対に格納されている時刻情報が示す時刻からの経過時間、または期限条件を満たしてからの経過時間を計時し、利率情報および経過時間をも用いて、利息を算出することは好適である。利率情報とは、予め決められた利率に関する情報である。利率情報は、例えば、１ヶ月につき１％、年利１０％等の情報でもよい。
【０１４６】
詳しくは、利息算出部３３３は、例えば、判断部３３１が、サーバ格納部３１に格納されている２以上の債務情報のうち一の債務情報に対し、予め決められた期限条件を満たすほど支払いが遅延していると判断した場合に、サーバ格納部３１に当該一の債務情報と対に格納されている時刻情報が示す時刻から内蔵時計等が示す現在時刻までの経過時間を取得し、保持している利率情報と、取得した経過時間とを用いて、利息を算出してもよい。
【０１４７】
具体的には、例えば、支払いが遅延していると判断された上記一の債務情報の有する金額情報が“￥１００００”であり、当該一の債務情報と対に時刻情報“２０１７／１１／１０”がサーバ格納部３１に格納されており、利率情報が“１ヶ月につき１％”であり、内蔵時計の示す現在時刻が“２０１７／１２／１０”である場合、利息算出部３３３は、その時刻情報“２０１７／１１／１０”から現在時刻“２０１７／１２／１０”までの経過時間“１カ月”を取得し、保持している利率情報“１カ月につき１％”と、取得した経過時間“１カ月”とを用いて、金額情報“￥１００００”に対する１か月分の利息“￥１００”を算出してもよい。
【０１４８】
さらに、利息算出部３３３は、こうして利息を算出したことに応じて、サーバ格納部３１に格納されている当該一の債務情報を更新してもよい。具体的には、利息算出部３３３は、当該一の債務情報が有する金額情報に対し、算出した利息を加算してもよい。
【０１４９】
相殺部３３４は、相殺処理を行う。相殺処理とは、例えば、２つの債務情報を消滅させる処理でもよいし、または、当該２つ以上の債務情報に代えて、１つの新たな債務情報を構成する処理であってもよい。
【０１５０】
詳しくは、相殺部３３４は、例えば、権利者識別子と義務者識別子とが逆である２つの債務情報をサーバ格納部３１から取得し、取得した２つの債務情報の間で、金額情報が同額である場合は、当該２つの債務情報を消滅させてもよい。また、金額情報が同額でない場合は、当該２つの債務情報に代えて、低額である金額情報を有する方の債務情報の義務者識別子と、高額である金額情報を有する方の債務情報の権利者識別子と、２つの金額情報の差額とを有する新な債務情報を構成してもよい。
【０１５１】
相殺部３３４は、取得した２つの債務情報が有する、権利者識別子で識別されるユーザと義務者識別子とで識別されるユーザとが、同じグループに属する場合にのみ相殺処理を行うことは好適である。
【０１５２】
なお、相殺部３３４は、３つ以上の債務情報の間でも、当該３つ以上の債務情報を消滅させる相殺処理、または、当該３つ以上の債務情報に代えて、より少ない数の新たな債務情報を構成する相殺処理を行ってもよい。
【０１５３】
相殺部３３４は、以上のような相殺処理の結果に応じて、サーバ格納部３１に格納されている２以上の債務情報の更新を行ってもよい。
【０１５４】
なお、利息算出部３３３の処理と相殺部３３４の処理とは、別々のタイミングで行われてもよいが、例えば、サーバ格納部３１に格納されている２以上の債務情報を用いて、共通のタイミングで行われることは好適である。
【０１５５】
以下では、利息算出部３３３が、利息を算出し、債務情報を更新する処理、および相殺部３３４が、相殺を行い、２以上の債務情報の更新を行う処理等を、更新処理と総称する場合がある。更新処理は、例えば、タイミング情報が示すタイミングで実行されてもよい。タイミング情報とは、更新処理を行うタイミングに関する情報である。タイミング情報は、例えば、２以上の日時の集合でもよいし、毎朝９時等の周期を示す情報でもよい。ただし、更新処理は、ユーザ指示に応じて実行されてもよく、その実行のタイミングやトリガは問わない。なお、更新処理を行うか否かは、例えば、後にフローチャートで説明するように、サーバ処理部３３が判断してもよい。
【０１５６】
サーバ送信部３４は、各種の情報を送信する。各種の情報とは、例えば、完了通知である。
【０１５７】
完了通知送信部３４１は、入金処理部３３２が実行した入金処理に対する完了通知を第一端末１に送信する。
【０１５８】
すなわち、完了通知送信部３４１は、例えば、入金処理部３３２が１以上のいずれかの第二ユーザの口座への入金処理を実行した場合に、当該第二ユーザを識別する第二ユーザ識別情報と対に、完了通知を第一端末１に送信してもよい。
【０１５９】
完了通知は、前述したように、第一ユーザの口座の残高に関する残高情報を有することは好適である。すなわち、完了通知送信部３４１は、例えば、入金処理の前後での第一ユーザの口座の残高情報を取得し、完了通知に含めて送信してもよい。完了通知送信部３４１は、入金前後の残高情報に加えて、入金された金額を示す金額情報をも完了通知に含めて送信してもよい。
【０１６０】
または、完了通知送信部３４１は、一連の各支払いに対応する完了通知を、第二ユーザ識別情報と対に、一連の支払いであることを識別可能に、第一端末１に送信してもよい。一連の支払いであることを識別可能に送信することは、例えば、属性情報および順序情報を完了通知に対応付けて送信することであってもよい。
【０１６１】
なお、完了通知送信部３４１は、入金処理部３３２が実行した入金処理に対する完了通知を、当該入金処理の入金元である第二ユーザの第二端末２にも送信してもよい。この場合の完了通知は、当該第二ユーザの口座の残高に関する残高情報を有することは好適である。すなわち、完了通知送信部３４１は、例えば、入金処理の前後での第二ユーザの口座の残高情報を取得し、当該第二ユーザの第二端末２への完了通知に含めて送信してもよい。
【０１６２】
第一格納部１１、第二格納部２１、およびサーバ格納部３１は、例えば、ハードディスクやフラッシュメモリといった不揮発性の記録媒体が好適であるが、ＲＡＭなど揮発性の記録媒体でも実現可能である。
【０１６３】
第一格納部１１等に情報が記憶される過程は問わない。例えば、記録媒体を介して情報が第一格納部１１等で記憶されるようになってもよく、ネットワークや通信回線等を介して送信された情報が第一格納部１１等で記憶されるようになってもよく、あるいは、入力デバイスを介して入力された情報が第一格納部１１等で記憶されるようになってもよい。入力デバイスは、例えば、キーボード、マウス、タッチパネル等、何でもよい。
【０１６４】
第一受付部１２、および第二受付部２５は、入力デバイスを含むと考えても、含まないと考えてもよい。受付部１２等は、入力デバイスのドライバーソフトによって、または入力デバイスとそのドライバーソフトとで実現され得る。
【０１６５】
第一処理部１３、取得部１３１、作成部１３２、第二処理部２６、サーバ処理部３３、判断部３３１、入金処理部３３２、利息算出部３３３、および相殺部３３４は、通常、ＭＰＵやメモリ等から実現され得る。第一処理部１３等の処理手順は、通常、ソフトウェアで実現され、当該ソフトウェアはＲＯＭ等の記録媒体に記録されている。ただし、処理手順は、ハードウェア（専用回路）で実現してもよい。
【０１６６】
第一送信部１４、第二送信部２３、サーバ送信部３４、および完了通知送信部３４１は、通常、有線または無線の通信手段（例えば、ＮＩＣ(Network interface controller)やモデム等の通信モジュール）で実現されるが、放送手段（例えば、放送モジュール）で実現されてもよい。
【０１６７】
第一受信部１５、第二受信部２２、サーバ受信部３２、第一認証コード受信部３２１、および第二認証コード受信部３２２は、通常、有線または無線の通信手段で実現されるが、放送を受信する手段（例えば、放送受信モジュール）で実現されてもよい。
【０１６８】
第一出力部１６、および第二出力部２４は、ディスプレイやスピーカ等の出力デバイスを含むと考えても含まないと考えてもよい。第一出力部１６等は、出力デバイスのドライバーソフトによって、または出力デバイスとそのドライバーソフトとで実現され得る。
【０１６９】
次に、情報システムの動作について図３〜図６のフローチャートを用いて説明する。
【０１７０】
図３は、第一端末１の動作を説明するフローチャートである。
【０１７１】
（ステップＳ３０１）第一処理部１３は、第一受付部１２が金額情報を受け付けたか否かを判別する。第一受付部１２が金額情報を受け付けた場合はステップＳ３０２に進み、受け付けていない場合はステップＳ３０６に進む。
【０１７２】
（ステップＳ３０２）作成部１３２は、ステップＳ３０１で受け付けられた金額情報を有する入金依頼を作成する。なお、作成部１３２は、指示画面を構成するための画面情報をも作成することは好適である。
【０１７３】
（ステップＳ３０３）取得部１３１は、認証コードを取得する。詳しくは、取得部１３１は、例えば、認証コードの手入力をタッチパネル等の入力デバイスを介して受け付けてもよい。または、取得部１３１は、例えば、認証コードの要求を外部装置に送信し、外部装置から認証コードを受信しても構わない。
【０１７４】
（ステップＳ３０４）第一送信部１４は、ステップＳ３０３で取得部１３１が取得した認証コードと、ステップＳ３０２で作成部１３２が作成した入金依頼とを、サーバ３および１以上の第二端末２に送信する。その際、第一送信部１４は、例えば、サーバ３へは、金額情報および口座情報を含む入金依頼を送信し、第二端末２へは、金額情報および画面情報を含む入金依頼を送信することは好適である。
【０１７５】
（ステップＳ３０５）第一出力部１６は、ステップＳ３０１で第一受付部１２が受け付けた金額情報、および第一格納部１１に格納されている１以上の第二端末識別子等を用いて、１以上の第二ユーザに対応する１以上の支払い状況情報を構成し、内部メモリ等に蓄積する。その後、ステップＳ３０１に戻る。
【０１７６】
（ステップＳ３０６）第一処理部１３は、第一受信部１５がサーバ３から完了通知を受信したか否かを判別する。第一受信部１５は、サーバ３から、例えば、実行された入金処理に対応する第二ユーザ識別子または組情報と対に、完了通知を受信する。第一受信部１５がサーバ３から完了通知を受信した場合はステップＳ３０７７に進み、受信していない場合はステップＳ３０１に戻る。
【０１７７】
（ステップＳ３０７）第一出力部１６は、ステップＳ３０５で完了通知と対に受信された第二ユーザ識別子または組情報を用いて、内部メモリ等に保持している支払い状況情報の更新を行う。
【０１７８】
（ステップＳ３０８）第一出力部１６は、例えば、保持している画面情報と、１以上の支払い状況情報とを用いて、１以上の各第二ユーザの支払いの状況を図的に示す支払い状況画面を構成し、ディスプレイを介して出力する。その後、ステップＳ３０１に戻る。
【０１７９】
なお、図３のフローチャートにおいて、第一出力部１６は、完了通知が受信された場合に支払い状況画面を出力しているが、例えば、新たな支払い状況情報を構成した場合や、支払い状況画面の出力の指示を第一受付部１２が受け付けた場合などにも、これを出力してよく、支払い状況画面の出力のトリガは問わない。
【０１８０】
また、図３のフローチャートにおいて、第一端末１の電源オンやプログラムの起動に応じて処理が開始し、電源オフや処理終了の割り込みにより処理は終了する。ただし、処理の開始または終了のトリガは問わない。
【０１８１】
図４は、第二端末２の動作を説明するフローチャートである。
【０１８２】
（ステップＳ４０１）第二処理部２６は、第二受信部２２が第一端末１から認証コードを受信したか否かを判別する。第二受信部２２が第一端末１から認証コードを受信した場合はステップＳ４０２に進み、受信していない場合はステップＳ４０１に戻る。
【０１８３】
（ステップＳ４０２）第二出力部２４は、指示画面を出力する。詳しくは、第二出力部２４は、例えば、第二受信部２２が受信した入金依頼が有する金額情報および画面情報に基づいて、金額情報が示す金額に対応するコインの画像等を有する指示画面を構成し、ディスプレイに表示してもよい。
【０１８４】
（ステップＳ４０３）第二処理部２６は、第二受付部２５がステップＳ４０２で出力された指示画面が有するコインに対する操作に基づく入金指示を受け付けたか否かを判別する。第二受付部２５がかかる入金指示を受け付けた場合はステップＳ４０４に進み、受け付けていない場合はステップＳ４０３に戻る。
【０１８５】
（ステップＳ４０４）第二送信部２３は、第二受信部２２が受信した認証コードを、当該第二端末２を識別する第二端末識別子、または当該第二端末２のユーザを識別するユーザ識別子のうち１種類以上の情報（以下、単に第二端末識別子と記す場合もある）と対に、サーバ３に送信する。その後、ステップＳ４０１に戻る。
【０１８６】
なお、図４のフローチャートにおいて、第二端末２の電源オンやプログラムの起動に応じて処理が開始し、電源オフや処理終了の割り込みにより処理は終了する。ただし、処理の開始または終了のトリガは問わない。
【０１８７】
図５は、サーバ３の動作を説明するフローチャートである。
【０１８８】
（ステップＳ５０１）サーバ処理部３３は、第一認証コード受信部３２１が第一端末１から認証コードと入金依頼とを受信したか否かを判別する。第一認証コード受信部３２１が第一端末１から認証コードと入金依頼とを受信した場合はステップＳ５０２に進み、受信していない場合はステップＳ５０５に進む。
【０１８９】
（ステップＳ５０２）サーバ処理部３３は、内蔵時計やＮＴＰサーバ等から、現在時刻を示す時刻情報を取得する。
【０１９０】
（ステップＳ５０３）サーバ処理部３３は、ステップＳ５０１で受信された入金依頼を用いて、債務情報を構成する。
【０１９１】
（ステップＳ５０４）サーバ処理部３３は、ステップＳ５０３で構成した債務情報を、ステップＳ５０１で受信した認証コード、およびステップＳ５０２で取得した時刻情報に対応付けて、サーバ格納部３１に蓄積する。その後、ステップＳ３０１に戻る。
【０１９２】
（ステップＳ５０５）サーバ処理部３３は、第二認証コード受信部３２２が第二端末２から認証コードを受信したか否かを判別する。第二認証コード受信部３２２が第二端末２から認証コードを受信した場合はステップＳ５０６に進み、受信していない場合はステップＳ５０９に進む。
【０１９３】
（ステップＳ５０６）判断部３３１は、ステップＳ５０１で第一認証コード受信部３２１が受信した認証コードと、ステップＳ５０５で第二認証コード受信部３２２が受信した認証コードとが、予め決められた認証条件を満たすか否かを判断する。認証条件を満たす場合はステップＳ５０７に進み、満たさない場合はステップＳ５０１に戻る。
【０１９４】
（ステップＳ５０７）入金処理部３３２は、ステップＳ５０１で第一認証コード受信部３２１が受信した入金依頼に対応する入金処理を実行する。なお、受信された入金依頼に対応する入金処理とは、例えば、サーバ格納部３１に格納されている２以上の債務情報のうち、ステップＳ５０６で判断部３３１が認証条件を満たすと判断した認証コードに対応付いた債務情報に対応する入金処理であってもよい。
【０１９５】
（ステップＳ５０８）完了通知送信部３４１は、ステップＳ５０７で入金処理部３３２が実行した入金処理に対する完了通知を、当該入金処理の入金元である第二ユーザを識別する第二ユーザ識別子と対に、第一端末１に送信する。
【０１９６】
なお、実行された入金処理が、一連の支払いに対応する２以上の入金処理の一つである場合、完了通知送信部３４１は、当該入金処理に対する完了通知を、属性情報および順序情報に対応付けて、第二ユーザ識別情報と対に、第一端末１に送信することは好適である。その後、ステップＳ３０１に戻る。
【０１９７】
（ステップＳ５０９）サーバ処理部３３は、更新処理を行うか否かを判断する。サーバ処理部３３は、例えば、タイミング情報を保持しており、内蔵時計等が示す現在時刻と、このタイミング情報とを用いて、更新処理を行うか否かを判断してもよい。または、サーバ処理部３３は、例えば、第一端末１からのユーザ指示等に応じて、更新処理を行うと判断してもよい。更新処理を行う場合はステップＳ５１０に進み、行わない場合はステップＳ５０１に戻る。
【０１９８】
（ステップＳ５１０）サーバ処理部３３等は、更新処理を実行する。なお、更新処理については、図６のフローチャートを用いて説明する。その後、ステップＳ３０１に戻る。
【０１９９】
なお、図５のフローチャートにおいて、サーバ３の電源オンやプログラムの起動に応じて処理が開始し、電源オフや処理終了の割り込みにより処理は終了する。ただし、処理の開始または終了のトリガは問わない。
【０２００】
図６は、ステップＳ５１０の更新処理を説明するフローチャートである。
【０２０１】
（ステップＳ６０１）サーバ処理部３３は、変数ｉに初期値１をセットする。変数ｉとは、サーバ格納部３１に格納されている２以上の債務情報のうち、未選択の債務情報を順番に選択していくための変数である。
【０２０２】
（ステップＳ６０２）サーバ処理部３３は、ｉ番目の債務情報があるか否かを判別する。ｉ番目の債務情報がある場合はステップＳ６０２に進み、ない場合は上位処理にリターンする。
【０２０３】
（ステップＳ６０３）サーバ処理部３３は、ｉ番目の債務情報に対し、権利者識別子と義務者識別子とが逆である他の債務情報があるか否かを判別する。ｉ番目の債務情報に対し、権利者識別子と義務者識別子とが逆である他の債務情報がある場合は、ステップＳ６０３に進み、ない場合はステップＳ６０５に進む。
【０２０４】
（ステップＳ６０４）相殺部３３４は、相殺処理を行う。詳しくは、相殺部３３４は、ｉ番目の債務情報、およびステップＳ６０３で権利者識別子と義務者識別子とが逆であると判断された他の債務情報に対し、当該２つの債務情報を消滅させる処理、または、当該２つ以上の債務情報に代えて、１つの新たな債務情報を構成する処理を行う。さらに、相殺部３３４は、こうして行った相殺処理に応じて、サーバ格納部３１に格納されている債務情報であり、当該２つの債務情報に対応する２つの債務情報の更新を行う。２つの債務情報の更新とは、削除、または新たな１つの債務情報への置換である。その後、ステップＳ６０８に進む。
【０２０５】
（ステップＳ６０５）判断部３３１は、ｉ番目の債務情報について、当該債務情報が有する時刻情報等を用いて、予め決められた期限条件を満たすほど支払いが遅延しているか否かの判断を行う。支払いが遅延している場合はステップＳ６０６に進み、遅延していない場合はステップＳ６０８に進む。
【０２０６】
（ステップＳ６０６）利息算出部３３３は、ｉ番目の債務情報が有する金額情報等を用いて、利息を算出する。
【０２０７】
（ステップＳ６０７）利息算出部３３３は、ｉ番目の債務情報が有する金額情報に対し、ステップＳ６０６で算出した利息を加算する。さらに、利息算出部３３３は、サーバ格納部３１に格納されている債務情報であり、ｉ番目の債務情報に対応する債務情報が有する金額情報を、利息が加算された金額情報に更新する。
【０２０８】
（ステップＳ６０８）サーバ処理部３３は、変数ｉをインクリメントする。その後、ステップＳ６０２に戻る。
【０２０９】
以下、本実施の形態における情報システムの具体的な動作例について説明する。本例において、情報システムは、第一端末１、２以上の第二端末、およびサーバ３を備える。第一端末１は、ユーザＸの携帯端末であり、また、２以上の第二端末２のうち１つは、ユーザＹの端末携帯であり、さらに、２以上の第二端末２のうち他の１つは、ユーザＺの携帯端末である。ユーザＸ、ユーザＹ、およびユーザＺの３人は、同じグループａのメンバである。
【０２１０】
現在の日付は、２０１７年１２月１日であり、本日、グループａの忘年会が開かれる。忘年会は、飲食店での一次会、およびカラオケ店での二次会で構成される。幹事はユーザＸであり、ユーザＹおよびユーザＺも参加する。
【０２１１】
第一端末１の第一格納部１１には、例えば、第一端末識別子“Ｘ”、２以上の第二端末識別子“Ｙ”および“Ｚ”、ならびにグループ識別子“ａ”などが予め格納されている。
【０２１２】
第一出力部１６の内部メモリには、例えば、図７に示すような４以上の支払い状況情報が、認証コードと対に格納され得る。図７は、支払い状況情報のデータ構造図である。支払い状況情報は、第二ユーザ識別子、グループ識別子、属性情報、順序情報、金額情報、および入金完了フラグを有する。４以上の各支払い状況情報は、ＩＤ（例えば“１”〜“４”等）に対応付いている。
【０２１３】
例えば、認証コード“１２３６”と対になる支払い状況情報（以下、支払い状況情報１と記す場合がある）は、第二ユーザ識別子“Ｙ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“一次会”、金額情報“￥４０００”、および入金完了フラグ“未完了”を有する。同様に、認証コード“１２３７”と対になる状況情報２は、第二ユーザ識別子“Ｚ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“一次会”、金額情報“￥４０００”、および入金完了フラグ“完了”を有する。また、認証コード“１２３８”と対になる支払い状況情報３は、第二ユーザ識別子“Ｙ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“二次会”、金額情報“￥３０００”、および入金完了フラグ“未完了”を有する。さらに、認証コード“１２３９”と対になる支払い状況情報４は、第二ユーザ識別子“Ｚ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“二次会”、金額情報“￥３０００”、および入金完了フラグ“未完了”を有する。
【０２１４】
ユーザＹの第二端末２を構成する第二格納部２１には、例えば、第二端末識別子“Ｙ”、およびグループ識別子“ａ”などが予め格納されている。ユーザＺの第二端末２を構成する第二格納部２１には、例えば、第二端末識別子“Ｚ”、およびグループ識別子“ａ”などが予め格納されている。
【０２１５】
サーバ３のサーバ格納部３１には、例えば、図８に示すような４以上の債務情報が、認証コードおよび時刻情報と対に格納され得る。図８は、債務情報データの構造図である。債務情報は、権利者識別子、義務者識別子、および金額情報を有する。４以上の債務情報は、ＩＤ（例えば“１”〜“４”等）に対応付いている。
【０２１６】
例えば、認証コード“２１９５”および時刻情報“２０１７／１１／１０”と対になる債務情報（以下、債務情報１と記す場合がある）は、権利者識別子“Ｗ＠ｂ”、義務者識別子“Ｘ＠ａ”、および金額情報“￥１００００”を有する。同様に、認証コード“４３８９”および時刻情報“２０１７／１１／２３”と対になる債務情報２は、権利者識別子“Ｙ＠ａ”、義務者識別子“Ｘ＠ａ”、および金額情報“￥５０００”を有する。また、認証コード“１２３６”および時刻情報“２０１７／１２／１”と対になる債務情報３は、権利者識別子“Ｘ＠ａ”、義務者識別子“Ｙ＠ａ”、および金額情報“￥４０００”を有する。さらに、認証コード“１２３７”および時刻情報“２０１７／１２／１”と対になる債務情報４は、権利者識別子“Ｘ＠ａ”、義務者識別子“Ｚ＠ａ”、および金額情報“￥４０００”を有する。
【０２１７】
なお、現時点では、サーバ格納部３１には、図８に示した債務情報１〜４のうち、債務情報１および２のみが格納されているとする。
【０２１８】
いま、一次会が終了し、幹事であるユーザＸは、３人全員分の代金１万２千円の支払いを済ませた後、第一端末１の入力デバイスを操作して、一人当たりのワリカン額を示す金額情報“￥４０００”を、属性情報“忘年会”および順序情報“一次会”と共に入力したとする。
【０２１９】
第一端末１において、第一受付部１２が上記金額情報“￥４０００”等を受け付け、作成部１３２は、その金額情報“￥４０００”を有する２つの入金依頼を作成する。作成される２つの入金依頼の一方（以下、第一入金依頼と記す場合がある）は、入金先口座情報であるユーザＸの口座情報、および入金元口座情報であるユーザＹの口座情報をも有し、他方の入金依頼（第二入金依頼）は、入金先口座情報であるユーザＸの口座情報、および入金元口座情報であるユーザＺの口座情報をも有する。さらに、作成部１３２は、指示画面を構成するための画面情報をも作成する。
【０２２０】
次に、取得部１３１は、作成された第一入金依頼に対して認証コードを取得し、さらに、第二入金依頼に対しても、別の認証コードを取得する。取得は、ユーザＸによる手入力でも、自動生成でもよいし、外部装置からの受信でも構わない。ここでは、第一入金依頼に対して認証コード“１２３６”が取得され、第二入金依頼に対して認証コード“１２３７”が取得されたとする。
【０２２１】
次に、第一送信部１４は、作成された第一入金依頼と、それに対して取得された認証コード“１２３６”とを、サーバ３、およびユーザＹの第二端末２に送信する。また、第一送信部１４は、作成された第二入金依頼と、それに対して取得された認証コード“１２３７”とを、サーバ３、およびユーザＺの第二端末２に送信する。ユーザＹの第二端末２への第一入金依頼、およびユーザＺの第二端末２への第二入金依頼には、画面情報も含まれる。
【０２２２】
他方、第一出力部１６は、第一受付部１２が受け付けた金額情報“￥４０００”等と、第一格納部１１に格納されている第二端末識別子“Ｙ”を用いて、第二ユーザ識別子“Ｙ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“一次会”、金額情報“￥４０００”、および入金完了フラグ“未完了”を有する支払い状況情報を構成し、取得部１３１が取得した認証コード“１２３６”と対に、内部メモリに蓄積する。また、第一出力部１６は、第一受付部１２が受け付けた金額情報“￥４０００”等と、第一格納部１１に格納されている第二端末識別子“Ｚ”を用いて、第二ユーザ識別子“Ｚ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“一次会”、金額情報“￥４０００”、および入金完了フラグ“未完了”を有する支払い状況情報をも構成し、取得部１３１が取得した認証コード“１２３７”と対に、内部メモリに蓄積する。
【０２２３】
これにより、第一出力部１６の内部メモリには、図７に示した２つの支払い状況情報１および２が認証コードと対に格納される結果となる。ただし、この時点では、支払い状況情報２の入金完了フラグも、図示とは異なり“未完了”である。
【０２２４】
サーバ３において、第一認証コード受信部３２１が、第一端末１から第一入金依頼と認証コード“１２３６”とを受信すると、サーバ処理部３３は、内蔵時計等から現在時刻を示す時刻情報“２０１７／１２／１”を取得する。また、サーバ処理部３３は、受信された第一入金依頼を用いて債務情報（以下、第一債務情報と記す場合がある）を構成し、構成した第一債務情報を、認証コード“１２３６”および時刻情報“２０１７／１２／１”に対応付けて、サーバ格納部３１に蓄積する。引き続き、第一認証コード受信部３２１が、第一端末１から第二入金依頼と認証コード“１２３７”とを受信すると、サーバ処理部３３は、受信された第二入金依頼を用いて債務情報（第二債務情報）を構成し、構成した第二債務情報を、認証コード“１２３７”および時刻情報“２０１７／１２／１”に対応付けて、サーバ格納部３１に蓄積する。
【０２２５】
これにより、サーバ格納部３１には、図８に示したように、既存の２つの債務情報１および２に加えて、さらに２つの債務情報３および４が、認証コードおよび時刻情報と対に格納される結果となる。
【０２２６】
ユーザＹの第二端末２において、第二受信部２２が第一端末１から認証コード“１２３６”と第一入金依頼とを受信し、第二出力部２４は、受信された第一入金依頼に含まれる金額情報“￥４０００”および画面情報を用いて指示画面を構成し、ディスプレイを介して出力する。こうして、ユーザＹの第二端末２のディスプレイに、指示画面（図示せず）が表示される。この指示画面は、一次会の支払いに対応する１つのコインの画像と、当該コインの画像に対応付いた文字列“一次会￥４０００”と、ユーザＹまたはＺへのメッセージ「幹事のＸ様からのお支払い依頼です」および「コインを投げるとＸ様への支払いが実行されます」等を有する。
【０２２７】
ユーザＺの第二端末２においても、第二受信部２２が認証コード“１２３７”と第二入金依頼とを受信し、第二出力部２４は、第二入金依頼に含まれる金額情報“￥４０００”および画面情報を用いて指示画面を構成し、ディスプレイを介して出力する。こうして、ユーザＺの第二端末２のディスプレイにも、上記と同様の指示画面が表示される。
【０２２８】
ただし、この時点では、ユーザＹおよびユーザＺのいずれも、コインの画像に対する操作を行わなかったとする。その後、３人は、カラオケ店に移動し、二次会を行う。
【０２２９】
二次会の終了後、ユーザＸは、代金９千円の支払いを済ませた後、第一端末１の入力デバイスを操作して、ワリカン額を示す金額情報“￥３０００”を、属性情報“忘年会”および順序情報“二次会”と共に入力したとする。
【０２３０】
第一端末１において、第一受付部１２が上記金額情報“￥３０００”等を受け付け、作成部１３２は、その金額情報“￥３０００”を有する２つの入金依頼を作成し、さらに、画面情報をも作成する。作成される２つの入金依頼の一方（以下、第三入金依頼と記す場合がある）は、上記第一入金依頼と同様の口座情報をも有し、他方の入金依頼（第四入金依頼）は、上記第二入金依頼と同様の口座情報をも有する。
【０２３１】
次に、取得部１３１は、作成された第二入金依頼に対して認証コード“１２３８”を取得し、さらに、第三入金依頼に対しても、別の認証コード“１２３９”を取得する。次に、第一送信部１４は、作成された第三入金依頼と、それに対して取得された認証コード“１２３８”とを、サーバ３、およびユーザＹの第二端末２に送信する。また、第一送信部１４は、作成された第四入金依頼と、それに対して取得された認証コード“１２３９”とを、サーバ３、およびユーザＺの第二端末２に送信する。ユーザＹの第二端末２への第三入金依頼、およびユーザＺの第二端末２への第四入金依頼には、画面情報も含まれる。
【０２３２】
他方、第一出力部１６は、第一受付部１２が受け付けた金額情報“￥３０００”等と、第一格納部１１に格納されている第二端末識別子“Ｙ”を用いて、第二ユーザ識別子“Ｙ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“二次会”、金額情報“￥３０００”、および入金完了フラグ“未完了”を有する支払い状況情報を構成し、取得部１３１が取得した認証コード“１２３８”と対に、内部メモリに蓄積する。また、第一出力部１６は、受け付けられた金額情報“￥３０００”等と、格納されている第二端末識別子“Ｚ”を用いて、第二ユーザ識別子“Ｚ”、グループ識別子“ａ”、属性情報“忘年会”、順序情報“二次会”、金額情報“￥３０００”、および入金完了フラグ“未完了”を有する支払い状況情報をも構成し、取得部１３１が取得した認証コード“１２３９”と対に、内部メモリに蓄積する。
【０２３３】
これにより、第一出力部１６の内部メモリには、図７に示したように、既存の２つの支払い状況情報１および２に加えて、２つの支払い状況情報３および４が、認証コードと対に格納される結果となる。
【０２３４】
サーバ３において、第一認証コード受信部３２１が第三入金依頼と認証コード“１２３８”とを受信すると、サーバ処理部３３は、時刻情報“２０１７／１２／１”を取得し、第三入金依頼を用いて債務情報（第三債務情報）を構成し、構成した第三債務情報を、認証コード“１２３８”および時刻情報“２０１７／１２／１”に対応付けて、サーバ格納部３１に蓄積する。引き続き、第一認証コード受信部３２１が第四入金依頼と認証コード“１２３９”とを受信すると、サーバ処理部３３は、第四入金依頼を用いて債務情報（第四債務情報）を構成し、構成した第四債務情報を、認証コード“１２３９”および時刻情報“２０１７／１２／１”に対応付けて、サーバ格納部３１に蓄積する。
【０２３５】
これにより、サーバ格納部３１には、図８に示した既存の４つの債務情報１および２に加えて、上記第三債務情報および第四債務情報に対応する２つの債務情報（図示しない）が、認証コードおよび時刻情報と対に格納される結果となる。
【０２３６】
ユーザＹの第二端末２において、第二受信部２２が第一端末１から認証コード“１２３８”と第三入金依頼とを受信し、第二出力部２４は、第三入金依頼に含まれる金額情報“￥３０００”および画面情報を用いて指示画面を構成し、ディスプレイを介して出力する。こうして、ユーザＹの第二端末２のディスプレイに、例えば、図１０に示すような指示画面が表示される。
【０２３７】
図１０は、指示画面の出力例を示す図である。この指示画面は、一次会の支払いに対応するリング状のパーツ、および二次会の支払いに対応する円盤状のパーツで構成された１つのコインの画像と、前者のパーツに対応付いた文字列“一次会￥４０００”と、後者のパーツに対応付いた文字列“二次会￥３０００”と、ユーザＹまたはＺへのメッセージ「幹事のＸ様からのお支払い依頼です」、「コインを投げるとＸ様への支払いが実行されます」、および「一・二次会の代金を別々に支払うこともできます（一次会代は外側のリングを、二次会代はコインの真ん中を、画面の外にスワイプしてください。）」等を有する。
【０２３８】
ユーザＺの第二端末２においても、第二受信部２２が認証コード“１２３９”と第四入金依頼とを受信し、第二出力部２４は、第四入金依頼に含まれる金額情報“￥３０００”および画面情報を用いて指示画面を構成し、ディスプレイを介して出力する。こうして、ユーザＺの第二端末２のディスプレイにも、図１０と同様の指示画面が表示される。
【０２３９】
その後、ユーザＺが、指示画面上のコインを構成するリング状のパーツの画像に対するスワイプ操作を行ったとする。
【０２４０】
ユーザＺの第二端末２において、第二受付部２５が、上記リング状のパーツに対する操作に基づく入金指示を受け付け、第二送信部２３は、第二受信部２２が受信した認証コード“１２３７”を、第二ユーザ識別子“Ｚ”と対に、サーバ３に送信する。
【０２４１】
サーバ３において、第二認証コード受信部３２２が、第二端末２から認証コード“１２３７”を受信し、判断部３３１は、先に第一認証コード受信部３２１が受信した認証コードであり、サーバ格納部３１に格納されている債務情報４に対応付いた認証コード“１２３７”と、ここで第二認証コード受信部３２２が受信した認証コードとが一致するため、認証条件「第一認証コード受信部３２１が受信した認証コードと、第二認証コード受信部３２２が受信した認証コードとが一致すること」を満たすと判断する。
【０２４２】
かかる判断結果に応じて、入金処理部３３２は、債務情報４に対応する入金処理を実行する。これにより、ユーザＺの口座から４０００円がユーザＸの口座に入金される。さらに、入金処理部３３２は、こうして実行した入金処理に対応する債務情報４を、サーバ格納部３１から削除する。
【０２４３】
また、完了通知送信部３４１は、入金処理部３３２によって実行された入金処理に対する完了通知を、第二ユーザ識別子“Ｚ”、属性情報“忘年会”、および順序情報“一次会”を有する組尾情報と対に、第一端末１に送信する。
【０２４４】
第一端末１において、第一受信部１５が、サーバ３から完了通知を受信し、第一出力部１６は、完了通知と対に受信された組情報を用いて、内部メモリに保持している支払い状況情報２が有する入金完了フラグを“未完了”から“完了”に更新する。
【０２４５】
次に、第一出力部１６は、保持している画面情報、および４つの支払い状況情報１〜４を用いて、ユーザＹおよびユーザＺ各々の支払いの状況を図的に示す支払い状況画面を構成し、ディスプレイを介して出力する。こうして、ユーザＸの第一端末１のディスプレイに、例えば、図１１に示すような支払い状況画面が表示される。
【０２４６】
図１１は、支払い状況画面の出力例を示す図である。この支払い状況画面は、ユーザＹに対応するアイコンの画像、および当該アイコンに対応付いたコインの画像の組と、ユーザＺに対応するアイコンの画像、および当該アイコンに対応付いたコインの画像の組とを有している。かかる２つのコインのいずれも、前述した指示画面（図１０参照）が有するコインと同様、一次会の支払いに対応するリング状のパーツ、および二次会の支払いに対応する円盤状のパーツで構成されている。
【０２４７】
ただし、ユーザＹのアイコンに対応する方のコインでは、リング状のパーツの画像がグレーアウトされ、当該パーツに対応する文字列“一次会￥４０００”も消去されている。また、支払い状況画面は、ユーザＸへのメッセージ「Ｙ様・Ｚ様から幹事様へのお支払いの状況です」も有する。これにより、ユーザＸは、ユーザＹおよびユーザＺ各々からの支払い状況の変化を、容易かつ速やかに知ることができる。
【０２４８】
ここで、支払い状況とは、具体的には、未だ入金されていない状況である「未入金」、または、既に入金が済んだ情況である「入金済」であるが、さらに「保留」をも含んでいてよい。保留とは、入金する点について同意したが、未だ入金に至っていない状況をいう。
【０２４９】
例えば、図１１の支払い状況画面では、ユーザＹのコインに関し、リング状のパーツがグレーアウトされ、当該パーツに対応する文字列“一次会￥４０００”も消去されたことで、ユーザＹは一次会の代金を「入金済」であることが示される一方、円盤状のパーツはグレーアウトされず、当該パーツに対応付けて、金額を示す文字列「二次会￥３０００」が表示され、さらに保留を示す文字列「〇〇日まで待って」も表示されたことで、ユーザＹは二次会の代金三千円の支払いを「保留」していることも示される。
【０２５０】
また、ユーザＺのコインに関しては、リング状および円盤状のいずれのパーツもグレーアウトされず、前者のパーツに対応付けて文字列「一次会￥４０００」が表示され、後者のパーツに対応付けて文字列「二次会￥３０００」が表示されたことで、ユーザＺが一次会の代金四千円および二次会の代金三千円のいずれも未入金であることが示される。
【０２５１】
なお、上記の文字列「〇〇日まで待って」は、保留する期間の終わりを示す情報であるが、これに代えて、例えば、「一週間待って」のように、保留する期間の長さを示す情報が表示されてもよく、「保留」を示す情報の表現形式は問わない。または、「保留」を示す情報は、特に期間は定めず、例えば、「後で」や「保留中」等のように、後ほど入金する旨の情報でも構わない。
【０２５２】
具体的な処理としては、例えば、第一受信部１５が、第二ユーザ識別子、金額情報、および未完了を示す入金完了フラグに加えて、保留を示す情報をも有する支払状況情報を受信した場合に、第一出力部１６は、当該第二ユーザ識別子に対応付いたコインの画像であり、当該金額情報に対応する文字列「二次会￥３０００」等を有する画像に対応付けて、保留を示す情報に対応する文字列「〇〇日まで待って」等をさらに表示してもよい。
【０２５３】
グループａの忘年会は、以上で終了となる。本例では、忘年会の終了後、当日中に、二次会でのワリカン額について、ユーザＹおよびユーザＺからの支払いが完了したとする。これに伴い、前述した上記第三債務情報および第四債務情報に対応する２つの債務情報（図示しない）も、サーバ格納部３１から削除される。
【０２５４】
サーバ３において、サーバ処理部３３は、例えば、毎朝９時に更新処理を行うことを示すタイミング情報を保持しており、内蔵時計等が示す現在時刻が、忘年会の翌日である２０１７年１２月２日の午前９時になると、債務情報の更新を行うと判断する。なお、この時点で、サーバ格納部３１には、３つの債務情報１〜３が格納されている。
【０２５５】
サーバ処理部３３が更新処理を行うと判断した場合、判断部３３１は、サーバ格納部３１に格納されている３つの債務情報１〜３に対して順番に、権利者識別子と義務者識別子とが逆である他の債務情報があるか否かの判断を行う。本例では、債務情報２が権利者識別子“Ｙ＠ａ”と義務者識別子“Ｘ＠ａ”とを有し、債務情報３が権利者識別子“Ｘ＠ａ”と義務者識別子“Ｙ＠ａ”とを有するため、判断部３３１は、債務情報２に対し、権利者識別子と義務者識別子とが逆である債務情報３が存在すると判断する。
【０２５６】
かかる判断結果を受け、相殺部３３４は、相殺処理を行う。詳しくは、相殺部３３４は、債務情報２が有する金額情報“￥５０００”と、債務情報３が有する金額情報“￥４０００”との大小関係について、前者が後者よりも１０００円高いと判断し、債務情報２および債務情報３に代えて、新たな債務情報５を構成する処理を行う。ここで構成される債務情報５は、債務情報２および債務情報３のうち、より高額である債務情報２と同じ権利者識別子“Ｙ＠ａ”、義務者識別子“Ｘ＠ａ”、認証コード“４３８９”、および時刻情報“２０１７／１１／２３”を有し、かつ、その差額に対応する金額情報“￥１０００”をも有する。
【０２５７】
さらに、相殺部３３４は、こうして行った相殺処理に応じて、サーバ格納部３１から債務情報２および債務情報３を削除し、新たな債務情報５をサーバ格納部３１に蓄積する。なお、この時点で、サーバ格納部３１には、２つの債務情報１および５が格納されている。債務情報１と債務情報５とは、権利者識別子と義務者識別子とが逆ではないため、判断部３３１は、相殺処理の対象は、現時点では存在しないと判断する。
【０２５８】
引き続き、判断部３３１は、２つの債務情報１および５に対して順番に、当該債務情報が有する時刻情報、および内蔵時計が示す現在時刻を用いて、期限条件を満たすほど支払いが遅延しているか否かの判断を行う。本例では、判断部３３１は、期限情報“１週間以内”を保持しており、債務情報１が時刻情報“２０１７／１１／１０”を有し、現在時刻が“２０１７／１２／２”を示すため、いずれの債務情報に対しても、支払いが遅延していないと判断する。
【０２５９】
その後、本日の日付が２０１７年１２月１０日になったとする。なお、この時点でも、サーバ格納部３１には、２つの債務情報１および５が格納されている。判断部３３１は、相殺処理の対象は、現時点でも存在しないと判断する。
【０２６０】
引き続き、判断部３３１は、２つの債務情報１および５に対して、上記と同様に、支払いが遅延しているか否かの判断を行う。この時点では、現在時刻が“２０１７／１２／１０”を示し、債務情報１が有する時刻情報“２０１７／１１／１０”からの経過期間が１カ月に達したため、判断部３３１は、債務情報１に対し、支払いが遅延していると判断する。
【０２６１】
かかる判断結果を受け、利息算出部３３３は、債務情報１と対にサーバ格納部３１に格納されている時刻情報“２０１７／１１／１０”から、現在時刻“２０１７／１２／１０”までの経過時間“１カ月”を取得し、債務情報１が有する金額情報“￥１００００”と、保持している利率情報“１カ月につき１％”と、取得した経過時間“１カ月”とを用いて、利息“￥１００”を算出する。
【０２６２】
また、利息算出部３３３は、債務情報１が有する金額情報“￥１００００”に対し、こうして算出した利息“￥１００”を加算する。さらに、利息算出部３３３は、サーバ格納部３１に格納されている債務情報１が有する金額情報を、利息が加算された金額情報“￥１０１００”に更新する。
【０２６３】
なお、債務情報５と対になる時刻情報“２０１７／１１／２３”から現在時刻までの経過期間は、未だ１カ月に達しておらず、判断部３３１は、債務情報２に対し、支払いは遅延していないと判断する。よって、利息算出部３３３の処理は、債務情報２に対しては行われない。
【０２６４】
この時点で、サーバ格納部３１には、図９に示すような２つの債務情報１および５が格納されている。図９は、更新された債務情報を示す図である。債務情報１は、権利者識別子“Ｗ＠ｂ”、義務者識別子“Ｘ＠ａ”、および金額情報“￥１０１００”を有し、認証コード“２１９５”、および時刻情報“２０１７／１１／１０”に対応付いている。債務情報５は、権利者識別子“Ｙ＠ａ”、義務者識別子“Ｘ＠ａ”、および金額情報“￥１０００”を有し、認証コード“４９８３”、および時刻情報“２０１７／１１／２３”に対応付いている。
【０２６５】
なお、上例では、幹事の端末である第一端末１には支払い状況画面が表示され、幹事以外の１以上の各参加者の端末である第二端末２には指示画面が表示されたが、どの端末にも同じ画面が表示されてもよい。
【０２６６】
図１２は、かかる画面の出力例を示す図である。この画面は、５人からなるグループの各メンバＡ〜Ｅの端末に表示される画面であり、支払い状況画面と指示画面とを兼ねた画面である。この画面は、グループのニックネームを示す文字列“○○くん”と、“○○くん”に対応するキャラクタの画像と、５人のメンバに対応する５つの円の画像と、５つの円のうちの４つに対応付いた４枚のコインの画像と、コインを投げる方向を示す矢印の画像とを有する。コインが対応付いた４つの円は、幹事以外の参加者（ここでは、メンバＡ〜Ｄ）に対応し、コインが対応付いていない円は、幹事（ここでは、メンバＥ）に対応している。４枚のコインには、対応するメンバを識別する文字情報“Ａ”〜“Ｄ”が記されている。幹事以外の参加者であるメンバＡ〜Ｄは、自分のコインを矢印の方向に投げる態様の操作を行うことで、幹事であるメンバＥへの入金を行うことができる。
【０２６７】
なお、図１２の画面は、例えば、６人からなるグループの、幹事以外の各メンバＡ〜Ｅの端末に表示される指示画面であってもよい。この場合、コインが対応付いていない円は、例えば、欠席したメンバＥに対応していてもよい。また、幹事であるメンバＦの端末には、図示しない別の支払い状況画面が表示される。別の支払い状況画面とは、例えば、図１２の画面から矢印の画像を削除した画面であってもよく、これによって、メンバＦは、各メンバからの入金情報を知ることができる。
【０２６８】
以上、本実施の形態によれば、情報システムは、第一端末１、第二端末２、およびサーバ３を具備し、第一端末１は、認証コードを取得し、認証コードをサーバ３および第二端末２に送信し、第二端末２は、第一端末１から認証コードを受信し、受信した認証コードをサーバ３に送信し、サーバ３は、第一端末１から認証コードを受信し、第二端末２から認証コードを受信し、第一端末１から受信した認証コードと第二端末２から受信した認証コードとが予め決められた認証条件を満たすか否かを判断し、認証条件を満たすと判断した場合に入金処理を実行する。つまり、第一端末１が認証コードを取得すると、その認証コードは、第二端末２経由および非経由の２系統でサーバ３に伝達され、認証条件を満たすと判断され場合に、サーバ３で入金処理が実行されるので、簡単かつ安全に入金が行える。
【０２６９】
なお、第一端末１からの認証コードと第二端末２からの認証コードとに関してサーバ３が認証条件を満たすか否かの判断を行うとことは、例えば、請求する側と支払う側とが入金処理の実行について合意したことの確認を行うことである、とも考えられることから、支払う側の金融機関（つまり第二銀行）としては、認証条件を満たすと判断したことで、得体のしれない相手に振込んでいるのではないことの確証が得られるに等しい。これによって、不正な入金処理の実行を防止する効果が得られ、金融機関の顧客保護につながる。
【０２７０】
また、上記情報システムにおいて、第一端末１は、金額を示す金額情報を受け付け、金額情報を有する入金依頼を作成し、取得した認証コードと作成した入金依頼とを、サーバ３および第二端末２に送信し、第二端末２は、第一端末１から認証コードと入金依頼とを受信し、受信した入金依頼に基づいて、入金指示を受け付ける指示画面を出力し、指示画面に対する入金指示を受け付け、入金指示を受け付けたことに応じて、受信した認証コードをサーバ３に送信し、サーバ３は、第一端末１から入金依頼と認証コードを受信し、認証条件を満たすと判断した場合に、第一端末１から受信した入金依頼に対応する入金処理を実行することにより、第二端末２を経由する系統において、第二端末２からサーバ３への認証コードの送信は、第二端末２による入金指示の受け付けなしでは行われないので、安全かつ簡単に入金が行える。
【０２７１】
また、上記情報システムにおいて、指示画面は、金額に対応するコインの画像を有し、第二端末２は、指示画面が有するコインに対する操作に基づく入金指示を受け付けることにより、直感的な操作で入金指示が行える。
【０２７２】
なお、本実施の形態では、第二端末２の指示画面上に表示されたコインの画像に対する操作に基づく入金指示をトリガとして、サーバ３で入金処理が実行されたが、必ずしも指示画面上にコインの画像が表示されなくてもよく、例えば、指示画面上のボタンやソフトウェアキーボード等に対する操作に基づく入金指示をトリガとして、入金処理が実行されてもよい。また、第二端末２には、必ずしも指示画面が表示されなくてもよく、例えば、ハードウェアのボタンやキーの操作に基づく入金指示や、マイクロフォンを介して音声入力された入金指示などをトリガとして、入金処理が実行されても構わない。このように、入金処理のトリガとなる入金指示の種類は問わない。
【０２７３】
また、上記情報システムにおいて、第一端末１は、一のグループに属する２以上のユーザのうち第一ユーザの端末であり、第二端末２は、２以上のユーザのうち第一ユーザを除く１以上の各第二ユーザの端末であり、サーバ３は、１以上の各第二ユーザが口座を有する金融機関のサーバであることにより、グループ内の第一ユーザと１以上の各第二ユーザとの間で、簡単かつ安全に入金が行える。
【０２７４】
また、上記情報システムにおいて、第一端末１が具備する第一格納部１１には、第一ユーザの口座に関する第一口座情報、および、１以上の各第二ユーザの口座に関する１以上の第二口座情報が格納され、第一端末１は、取得した認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とを、サーバ３および第二端末２に送信してもよい。こうして、第一端末１が口座情報の管理を行うことで、第二端末２やサーバ３の負担を抑制しつつ、簡単かつ安全に入金が行える情報システムを実現できる。
【０２７５】
ただし、第一口座情報や第二口座情報等の口座情報については、サーバ３にのみ通知し、第二端末２には通知しなくてもよい。かかる変形例において、例えば、第一端末１を構成する第一送信部１４は、認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とをサーバ３に送信する一方、第二端末２へは、認証コードと、金額情報のみを有し、第一口座情報も第二口座情報も有さない入金依頼とを送信してもよい。これによって、第一ユーザは、第二ユーザに口座情報を知らせることなく、第二ユーザから入金を受けることができる。
【０２７６】
なお、上記変形例においても、サーバ３は、第一ユーザの口座、および１以上の各第二ユーザの口座を管理する一の銀行のサーバであることは好適である。
【０２７７】
ただし、サーバ３は、第一ユーザの口座を管理する銀行（以下、第一銀行と記す場合がある）のサーバであり、１以上の第二ユーザの各口座は、別の銀行（以下、第二銀行）で管理されてもよい。認証コードに関する判断は、第一銀行のサーバで行われ、認証条件を満たすと判断された場合に、第一銀行のサーバから第二銀行のサーバに、第一口座情報および金額情報が送信されることで、第二ユーザの口座から第一ユーザの口座への入金が実現される（第二変形例）。
【０２７８】
なお、上記第二変形例においても、第一端末１が取得した認証コードは、第二端末２経由および非経由の２系統でサーバ３に伝達されるが、前者（つまり、第二端末２を経由する方）の系統に関し、第二端末２を構成する第二送信部２３は、第二受信部２２が第一端末１から受信した認証コードを、第一銀行のサーバの識別子と共に、第二銀行のサーバに送信してもよい。なお、共に送信することは、認証コードが第一銀行のサーバの識別子を有する場合も含む。第二銀行のサーバは、第二端末２から、第一銀行のサーバの識別子と共に認証コードを受信することで、第一銀行のサーバに認証コードを送信することができる（第二変形例の第一の態様）。
【０２７９】
もしくは、第一端末１を構成する第一送信部１４が、第一銀行のサーバの識別子を第二端末２に送信し、第二端末２を構成する第二受信部２２がこれを受信することによって、第二送信部２３は、第二銀行のサーバを介すことなく、直接、第一銀行のサーバに認証コードを送信することも可能である（第二変形例の第二の態様）。
【０２８０】
または、サーバ３は、第二銀行のサーバであってもよい。詳しくは、第一端末１を構成する第一送信部１４は、取得部１３１が取得した認証コードと、第二銀行の識別子に関する問い合せとを第二端末２に送信する。これに応じて、第一受信部１５は、第二端末２から第二銀行のサーバの識別子を受信し、第一送信部１４は、第二銀行のサーバに、認証コードと、金額情報および第一口座情報を有する入金依頼とを送信する。第二銀行のサーバは、第一端末１から認証コードと入金依頼とを受信する一方、第二端末２から認証コードを受信して、認証コードに関する判断を行う。そして、第二銀行のサーバは、認証条件を満たすと判断した場合に、第一銀行のサーバとの間で、第二ユーザの口座から第一ユーザの口座への入金に関する処理を行えばよい（第三変形例）。
【０２８１】
なお、上記情報システムにおいて、第一端末１は、金額の入金を指示する入金指示を受け付ける指示画面を構成するための画面情報をも作成し、取得した認証コードと、金額情報、第一口座情報、および１以上の第二口座情報を有する入金依頼とを、サーバ３に送信し、かつ、取得した認証コードと、金額情報、および画面情報を有する入金依頼を、第二端末２に送信してもよい。こうして、第一端末１が口座情報の管理および画面情報の作成を行うことで、第二端末２やサーバ３の負担をさらに抑制しつつ、簡単かつ安全に入金が行える情報システムを実現できる。
【０２８２】
また、上記情報システムにおいて、サーバ３は、１以上のいずれかの第二ユーザの口座への入金処理を実行した場合に、入金完了を示す完了通知を第二ユーザのユーザ識別情報と対に第一端末１に送信し、第一端末１は、サーバ３から第二ユーザのユーザ識別情報と対に完了通知を受信し、完了通知に基づいて、１以上の各第二ユーザの支払いの状況を図的に出力することにより、第一ユーザは、１以上の各第二ユーザからの入金状況を直感的に把握できる。
【０２８３】
また、上記情報システムにおいて、第一端末１は、一連の各支払いに対応する２以上の金額情報を、異なるタイミングで受け付け、サーバ３は、一連の各支払いに対応する完了通知を第二ユーザのユーザ識別情報と対に、一連の支払いであることを識別可能に、第一端末１に送信し、第一端末は、一連の支払いに対応する完了通知に基づいて、一連の支払いのうちのいずれの支払いが完了しているかを識別可能に、１以上の各第二ユーザの支払いの状況を図的に出力することにより、第一ユーザは、１以上の各第二ユーザからの入金状況を、一連の支払いごとに、直感的に把握できる。
【０２８４】
また、上記情報システムにおいて、サーバ３は、予め決められた期限条件を満たすほど支払いが遅延しているか否かをも判断し、予め決められた期限条件を満たすほど支払いが遅延していると判断した場合に、入金依頼が有する金額情報を用いて、利息を算出し、金額情報と算出した利息とを用いて入金処理を実行することにより、支払いが遅延した場合に、利息付きの入金が行える。
【０２８５】
また、上記情報システムにおいて、サーバ３が具備するサーバ格納部３１には、支払われる権利者の権利者識別子と支払い義務者の義務者識別子と支払う金額である金額情報とを有する２以上の債務情報が格納され、サーバ３は、権利者識別子と義務者識別子とが逆である２つの債務情報をサーバ格納部３１から取得し、取得した２つの債務情報の間で、金額情報が同額である場合は、２つの債務情報を消滅させ、同額でない場合は、２つの債務情報に代えて、低額である金額情報を有する方の債務情報の義務者識別子と、高額である金額情報を有する方の債務情報の権利者識別子と、２つの金額情報の差額とを有する新な債務情報を構成する相殺処理を行うことにより、入金処理を簡素化できる。
【０２８６】
また、上記情報システムにおいては、サーバ３は、取得した２つの債務情報が有する、権利者識別子で識別されるユーザと義務者識別子とで識別されるユーザとが、同じグループに属する場合にのみ相殺処理を行うことより、入金処理を簡素化しつつ、グループ外の権利者の保護も図ることができる。
【０２８７】
なお、本実施の形態では、第一端末１は、１つであるが、２以上でもよい。また、第一端末１は、第二端末２の機能をも有していてよい。同様に、第二端末２もまた、第一端末１の機能をも有していてよい。
【０２８８】
すなわち、情報システムは、第一端末１および第二端末２の両方の機能を有する２以上の端末（図示しない）と、サーバ３とを備え、２以上の端末のうち一の端末が、第一端末１として動作し、他の１以上の各端末は、第二端末２として動作してもよい。かかる変形例において、各端末は、当該端末のユーザが、例えば、グループの代表者（例えば、グループａが催す忘年会の幹事等）となった場合には第一端末１として動作し、代表者以外のメンバ（例えば、幹事以外の参加者）となった場合には第二端末２として動作することは好適である。
【０２８９】
また、本実施の形態では、第一端末１は、グループの代表者（例えば、グループａが催す忘年会の幹事など）の端末であり、第二端末２は、グループの代表者以外（幹事以外の参加者など）の端末であったが、例えば、第一端末１は、グループ外のユーザ（例えば、忘年会に利用した飲食店やカラオケ店の店員など）の端末であり、第二端末２は、グループの各ユーザ（忘年会の各参加者）の端末であってもよい。または、店舗をグループの一員に加え、店舗からの請求を店舗の客が支払うような形態も可能である。この場合、第一端末１は店舗の端末であり、第二端末２は店舗の客の端末であってもよい。
【０２９０】
さらに、本実施の形態における処理は、ソフトウェアで実現してもよい。そして、このソフトウェアをソフトウェアダウンロード等により配布してもよい。また、このソフトウェアをＣＤ−ＲＯＭなどの記録媒体に記録して流布してもよい。
【０２９１】
本実施の形態における第一端末１を実現するソフトウェアは、例えば、以下のようなプログラムである。つまり、このプログラムは、第二端末２、およびサーバ３と共に情報システムを構成する第一端末１のプログラムであって、第二端末２は、第一端末１から認証コードを受信する第二受信部２２と、第二受信部２２が受信した認証コードをサーバ３に送信する第二送信部２３とを具備し、サーバ３は、第一端末１から認証コードを受信する第一認証コード受信部３２１と、第二端末２から認証コードを受信する第二認証コード受信部３２２と、第一認証コード受信部３２１が受信した認証コードと第二認証コード受信部３２２が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部３３１と、判断部３３１が認証条件を満たすと判断した場合に入金処理を実行する入金処理部３３２とを具備し、プログラムは、第一端末１のコンピュータを、認証コードを取得する取得部１３１と、認証コードをサーバ３および第二端末２に送信する第一送信部１４として機能させるためのプログラムである。
【０２９２】
また、本実施形態の第二端末２を実現するソフトウェアは、例えば、以下のようなプログラムである。つまり、このプログラムは、第一端末１、およびサーバ３と共に情報システムを構成する第二端末２のプログラムであって、第一端末１は、認証コードを取得する取得部１３１と、認証コードをサーバ３および第二端末２に送信する第一送信部１４とを具備し、サーバ３は、第一端末１から認証コードを受信する第一認証コード受信部３２１と、第二端末２から認証コードを受信する第二認証コード受信部３２２と、第一認証コード受信部３２１が受信した認証コードと第二認証コード受信部３２２が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部３３１と、判断部３３１が認証条件を満たすと判断した場合に入金処理を実行する入金処理部３３２とを具備し、プログラムは、第二端末２のコンピュータを、第一端末１から認証コードを受信する第二受信部２２と、第二受信部２２が受信した認証コードをサーバ３に送信する第二送信部２３として機能させるためのプログラムである。
【０２９３】
さらに、本実施形態のサーバ３を実現するソフトウェアは、例えば、以下のようなプログラムである。つまり、このプログラムは、第一端末１、および第二端末２と共に情報システムを構成するサーバ３のプログラムであって、第一端末１は、認証コードを取得する取得部１３１と、認証コードをサーバ３および第二端末２に送信する第一送信部１４とを具備し、第二端末２は、第一端末１から認証コードを受信する第二受信部２２と、第二受信部２２が受信した認証コードをサーバ３に送信する第二送信部２３とを具備し、プログラムは、サーバ３のコンピュータを、第一端末１から認証コードを受信する第一認証コード受信部３２１と、第二端末２から認証コードを受信する第二認証コード受信部３２２と、第一認証コード受信部３２１が受信した認証コードと第二認証コード受信部３２２が受信した認証コードとが予め決められた認証条件を満たすか否かを判断する判断部３３１と、判断部３３１が認証条件を満たすと判断した場合に入金処理を実行する入金処理部３３２として機能させるためのプログラムである。
【０２９４】
図１３は、実施の形態におけるプログラムを実行して、第一端末１や第二端末２などを実現するコンピュータシステム９００の内部構成の一例を示す図である。図１３において、コンピュータシステム９００は、プログラムを実行するコンピュータであるＭＰＵ９１１と、ブートアッププログラム等のプログラムを記憶するためのＲＯＭ９１２と、ＭＰＵ９１１に接続され、アプリケーションプログラムの命令を一時的に記憶すると共に、一時記憶空間を提供するＲＡＭ９１３と、アプリケーションプログラム、システムプログラム、およびデータを記憶するストレージ９１４と、ＭＰＵ９１１、ＲＯＭ９１２等を相互に接続するバス９１５と、外部ネットワークや内部ネットワーク等のネットワークへの接続を提供するネットワークカード９１６と、メモリカードスロット９１７と、ディスプレイ９１８と、ディスプレイ９１８の表示面に設けられたタッチパネル９１９とを備える。ストレージ９１４は、例えば、フラッシュメモリなどである。なお、コンピュータシステム９００全体をコンピュータと呼んでもよい。
【０２９５】
コンピュータシステム９００に、第一端末１等の機能を実行させるプログラムは、例えば、メモリカード９２０に記憶されて、メモリカードスロット９１７に挿入され、ストレージ９１４に転送されてもよい。これに代えて、そのプログラムは、ネットワークを介してコンピュータシステム９００に送信され、ストレージ９１４に記憶されてもよい。プログラムは、実行の際にＲＡＭ９１３にロードされる。なお、プログラムは、メモリカード９２０、またはネットワークから直接、ロードされてもよい。
【０２９６】
プログラムは、コンピュータシステム９００に、第一端末１等の機能を実行させるオペレーティングシステム（ＯＳ）、またはサードパーティプログラム等を必ずしも含んでいなくてもよい。プログラムは、制御された態様で適切な機能やモジュールを呼び出し、所望の結果が得られるようにする命令の部分のみを含んでいてもよい。コンピュータシステム９００がどのように動作するのかについては周知であり、詳細な説明は省略する。
【０２９７】
なお、上述したコンピュータシステム９００は、携帯端末であるが、サーバ３は、例えば、サーバまたは据え置き型のＰＣで実現されてもよい。この場合、例えば、タッチパネル９１８はキーボードおよびマウスに、メモリカードスロット９１７はディスクドライブに、ストレージ９１４はハードディスクやＳＳＤに、メモリカード９２０はＣＤやＤＶＤ等のディスクに、それぞれ置き換えられてもよい。ただし、以上は例示であり、第一端末１等を実現するコンピュータのハードウェア構成は問わない。
【０２９８】
なお、上記プログラムにおいて、情報を送信する送信ステップや、情報を受信する受信ステップなどでは、ハードウェアによって行われる処理、例えば、送信ステップにおけるモデムやインターフェースカードなどで行われる処理（ハードウェアでしか行われない処理）は含まれない。
【０２９９】
また、上記プログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、あるいは分散処理を行ってもよい。
【０３００】
また、上記各実施の形態において、一の装置に存在する２以上の通信手段（第一送信部１４、第一受信部１５など）は、物理的に一の媒体で実現されてもよいことは言うまでもない。
【０３０１】
また、上記各実施の形態において、各処理（各機能）は、単一の装置（システム）によって集中処理されることによって実現されてもよく、あるいは、複数の装置によって分散処理されることによって実現されてもよい。
【０３０２】
本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【産業上の利用可能性】
【０３０３】
以上のように、本発明にかかる情報システム等は、簡単かつ安全に入金が行えるという効果を有し、情報システム等として有用である。
【符号の説明】
【０３０４】
１  第一端末
２  第二端末
３  サーバ
１１  第一格納部
１２  受付部
１２  第一受付部
１３  第一処理部
１４  第一送信部
１５  第一受信部
１６  第一出力部
２１  第二格納部
２２  第二受信部
２３  第二送信部
２４  第二出力部
２５  第二受付部
２６  第二処理部
３１  サーバ格納部
３２  サーバ受信部
３３  サーバ処理部
３４  サーバ送信部
１３１  取得部
１３２  作成部
３２１  第一認証コード受信部
３２２  第二認証コード受信部
３３１  判断部
３３２  入金処理部
３３３  利息算出部
３３４  相殺部
３４１  完了通知送信部
【図１】
2019061524.tif 000003
【図２】
2019061524.tif 000004
【図３】
2019061524.tif 000005
【図４】
2019061524.tif 000006
【図５】
2019061524.tif 000007
【図６】
2019061524.tif 000008
【図７】
2019061524.tif 000009
【図８】
2019061524.tif 000010
【図９】
2019061524.tif 000011
【図１０】
2019061524.tif 000012
【図１１】
2019061524.tif 000013
【図１２】
2019061524.tif 000014
【図１３】
2019061524.tif 000015