JP2022099175A

JP2022099175A - サーバ、プログラム、情報処理方法

Info

Publication number: JP2022099175A
Application number: JP2020212996A
Authority: JP
Inventors: 洋輔真崎; Yosuke Mazaki; 亮介濱窄; Ryosuke Hamasaku
Original assignee: Line Corp
Current assignee: Z Intermediate Global Corp
Priority date: 2020-12-22
Filing date: 2020-12-22
Publication date: 2022-07-04
Anticipated expiration: 2040-12-22
Also published as: JP7354089B2

Abstract

【課題】後払いの利便性を向上させる。【解決手段】端末と通信するサーバは、端末のユーザにより、後払いで購入された商品またはサービスの購入情報を受信し、購入情報のうち、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも第２情報を受信する通信部と、第２情報に基づいて、第２口座から第１口座に第２金額を送金することに関する処理を行う制御部とを備える。【選択図】図１－１

Description

本開示は、サーバ、プログラム、情報処理方法等に関する。

従来より、後払いで商品やサービスを購入することが頻繁に行われている。例えば特許文献１には、商品の購買金額の決済を行う技術が開示されている。

特開２００２－１７６６７１号公報

本発明の第１の態様によると、端末と通信するサーバは、端末のユーザにより、後払いで購入された商品またはサービスの購入情報を受信し、購入情報のうち、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも第２情報を受信する通信部と、第２情報に基づいて、第２口座から第１口座に第２金額を送金することに関する処理を行う制御部とを備える。
本発明の第２の態様によると、端末と通信するサーバによって実行されるプログラムは、端末のユーザにより、後払いで購入された商品またはサービスの購入情報をサーバの通信部によって受信することと、購入情報のうち、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも第２情報を通信部によって受信することと、第２情報に基づいて、第２口座から第１口座に第２金額を送金することに関する処理をサーバの制御部によって行うこととがサーバによって実行される。
本発明の第３の態様によると、端末と通信するサーバの情報処理方法は、端末のユーザにより、後払いで購入された商品またはサービスの購入情報をサーバの通信部によって受信することと、購入情報のうち、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも第２情報を通信部によって受信することと、第２情報に基づいて、第２口座から第１口座に第２金額を送金することに関する処理をサーバの制御部によって行うこととを含む。
本発明の第４の態様によると、端末と通信するサーバは、メモリに記憶されたプログラムを読み出し、プログラムに基づいて処理を実行するプロセッサーを備え、プロセッサーは、端末のユーザにより、後払いで購入された商品またはサービスの購入情報をサーバの通信部によって受信することと、購入情報のうち、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも第２情報を通信部によって受信することと、第２情報に基づいて、第２口座から第１口座に第２金額を送金することに関する処理を行うこととを実行する。

第１実施例に係る通信システムのシステム構成の一例を示す図。第１実施例に係るクレジットカード会社サーバの制御部によって実現される機能の一例を示す図。第１実施例係るクレジットカード会社サーバの記憶部に記憶される情報等の一例を示す図。第１実施例に係るユーザ登録データのデータ構成の一例を示す図。第１実施例に係る提携銀行データのデータ構成の一例を示す図。第１実施例に係るユーザ管理データベースのデータ構成の一例を示す図。第１実施例に係る端末の制御部によって実現される機能の一例を示す図。第１実施例に係る端末の記憶部に記憶される情報等の一例を示す図。第１実施例に係るクレジットカード決済サービスの原理の説明図。第１実施例に係る端末の表示画面の一例を示す図。第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係る通信システムのシステム構成の一例を示す図。第１変形例に係るユーザ管理データベースのデータ構成の一例を示す図。第１変形例に係るサーバの制御部によって実現される機能の一例を示す図。第１変形例に係るサーバの記憶部に記憶される情報の一例を示す図。第１変形例に係るアカウント登録データのデータ構成の一例を示す図。第１変形例に係るアカウント管理データベースのデータ構成の一例を示す図。第１変形例に係る端末の制御部によって実現される機能の一例を示す図。第１変形例に係る端末の記憶部に記憶される情報の一例を示す図。第１変形例に係るクレジットカード決済サービスの原理の説明図。第１変形例に係る端末の表示画面の一例を示す図。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係るアカウント管理データベースのデータ構成の一例を示す図。第１変形例に係る端末の表示画面の一例を示す図。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係るアカウント管理データベースのデータ構成の一例を示す図。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係る端末の表示画面の一例を示す図。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２変形例に係る端末の表示画面の一例を示す図。第３実施例に係るユーザ管理データベースのデータ構成の一例を示す図。第３実施例に係る端末の表示画面の一例を示す図。第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第４実施例に係る支払い口座設定用情報種別判定データのデータ構成の一例を示す図。第４実施例に係る取引別支払い口座設定用情報種別判定データのデータ構成の一例を示す図。第４実施例に係る端末の表示画面の一例を示す図。第４実施例に係る端末の表示画面の一例を示す図。第５実施例に係る支払い口座設定リマインド条件データのデータ構成の一例を示す図。第５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第６実施例に係る端末の表示画面の一例を示す図。第７実施例に係るユーザ管理データベースのデータ構成の一例を示す図。第７実施例に係る端末の表示画面の一例を示す図。第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第７変形例に係る端末の表示画面の一例を示す図。第８実施例に係る支払い口座決定用データのデータ構成の一例を示す図。第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第９実施例に係る端末の表示画面の一例を示す図。第９変形例に係る端末の表示画面の一例を示す図。第９変形例に係る端末の表示画面の一例を示す図。第９変形例に係る端末の表示画面の一例を示す図。第１０実施例に係るユーザ管理データベースのデータ構成の一例を示す図。第１０実施例に係るアカウント管理データベースのデータ構成の一例を示す図。第１０実施例に係る端末の表示画面の一例を示す図。第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係るアカウント管理データベースのデータ構成の一例を示す図。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係る端末の表示画面の一例を示す図。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。他の実施例に係る端末の表示画面の一例を示す図。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。

システムとは、限定ではなく例として、以下のいずれかの形態のシステムを含む概念とすることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、サーバクライアントシステムである。
この場合、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。

また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。

サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。

なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。

以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、サーバクライアントシステム）を例示する。
なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。

また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。

また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。

また、本明細書において「関する」、「関連する」と記載された用語について、限定ではなく例として、「Ａに関するＢ」や「Ａに関連するＢ」といった場合、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。

また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。

なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。

＜実施形態＞
クレジットカードを利用した決済（以下、「クレジットカード決済」と称する。）等による支払いが日常的に利用されている。
本実施形態は、このクレジットカード決済を含む後払いの決済に関する実施形態である。

「後払い」とは、ユーザが商品やサービスを購入する場合に、購入の手続きは行ったものの、そのタイミングでは代金の支払いを行わず、それよりも後のタイミング、限定ではなく例として、設定された日、または設定された期日までに代金の支払いを行うサービスである。先に商品等をユーザが受け取り（または、先に商品等がユーザに発送され）、その後に、その代金を支払うようなものをこれに含めることができる。

この後払いには、限定ではなく例として、少なくとも以下のいずれかの支払い方法を含めることができる。
（１）クレジットカード決済
（２）ツケ払い

（１）クレジットカード決済では、限定ではなく例として、月に１回などの設定された日にち（または設定された期日）に、設定された期間（限定ではなく例として、ひと月の期間）に行われた取引を対象として、クレジットカードに紐づけられた銀行口座からまとめて支払いを行う。

（２）ツケ払いでは、限定ではなく例として、商品等をユーザが受け取ると（または、商品等がユーザに発送されると）、後日、支払い（後払い）に必要な請求書がユーザ宛に送付される。または、請求情報がユーザの端末２０に送信される。そして、ユーザは、請求書等に記載された設定された日、または設定された期日までに、金融機関（口座振替を含む。）、コンビニエンスストア、電子マネーサービス等を利用して、請求書に記載された金額の支払いを行う。

本明細書では、（２）ツケ払いとして、限定ではなく例として、（２－１）一括ツケ払い、（２－２）都度ツケ払い、の２種類を例示する。
（２－１）一括ツケ払いは、限定ではなく例として、設定期間（限定ではなく例として、ひと月の期間）に行われた取引について、一括的に（まとめて）ツケ払いによる支払いを行う方法である。
（２－２）都度ツケ払いは、限定ではなく例として、取引が行われる都度、ツケ払いによる支払いを行う方法である。

また、本明細書では、端末のユーザにより、上記の後払いで購入された商品またはサービスの購入に関連する情報を「購入情報」と称する。「購入情報」は、商品またはサービスの購入と何らかの関係性を有する情報であればよく、限定ではなく例として、以下のようなものがこれに含まれる。
・後払いで商品またはサービスが購入されたことを示す情報
・後払いで購入された商品またはサービスの概要や細目を示す情報
・後払いの請求情報

なお、端末が受信する購入情報と、クレジットカード会社のサーバやメッセージングサービス・電子マネーサービス等のサービスを提供するサービス事業者のサーバで管理される購入情報とは、完全に同じ情報としてもよいし、一部が異なる情報としてもよい。

＜第１実施例＞
第１実施例は、本開示の手法を、限定ではなく例として、前述した（１）クレジットカード決済によって実現するための基本的な実施例である。

ユーザによっては、複数の金融機関の口座を持ち、利用用途に応じて、金融機関の口座を使い分けることがある。クレジットカード決済等の後払いを行う場合であっても、利用用途に応じて、金融機関の口座を使い分けることができると至便である。

第１実施例は、クレジットカード決済において、購入情報ごとに、クレジットカード決済の支払いを行う銀行口座（以下、「支払い口座」と称する。）をユーザが選択可能にする実施例である。本実施例では、クレジットカードに複数の銀行口座が紐づけられる。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

以下説明する実施例では、金融機関として「銀行」を例示する。
銀行には、店舗を有する銀行（郵政グループの銀行等も含む。）の他、限定ではなく例として、インターネット銀行（ネット銀行）も含めることができる。
なお、金融機関として、銀行ではなく、中央金庫、信用金庫等の金融機関を適用することも可能である。

また、以下説明する実施例では、支払い口座から支払い金額を引き落とすことを「口座振替」と称する。また、銀行サーバ５０が行う口座振替の処理を「口座振替処理」と称する。

なお、口座振替は、自動振替や口座自動振替等と称してもよい。
また、支払い口座は、引き落とし口座や振替口座等と称してもよい。

＜システム構成＞
図１－１は、本実施例における通信システム１Ａのシステム構成の一例を示す図である。
通信システム１Ａでは、限定ではなく例として、ネットワーク３０を介して、クレジットカード会社サーバ１０と、１以上の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、１以上の店舗端末４０（店舗端末４０Ａ，店舗端末４０Ｂ，店舗端末４０Ｃ，・・・）と、２以上の銀行サーバ５０（銀行サーバ５０Ａ，銀行サーバ５０Ｂ，銀行サーバ５０Ｃ）とが接続される。

クレジットカード会社サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０、店舗端末４０、銀行サーバ５０等に、限定ではなく例として、後述するクレジットカード決済サービスを提供する機能を有する。
クレジットカード会社サーバ１０は、クレジットカードサービスサーバ、クレジット支払い管理サーバ、クレジット決済サービスサーバ、クレジット決済管理サーバ、クレジット決済システムサーバ、クレジットサービスサーバ等のように表現することもできる。
本実施形態では、限定ではなく例として、クレジットカード会社サーバ１０のユーザを、クレジットカード会社（クレジット決済サービスの事業者）とする。

なお、クレジットカード決済のシステムには、限定ではなく例として、ブランドホルダー（国際ブランド）、カード発行会社（イシュア）、加盟店管理会社（アクワイアラ）、決済代行会社、カード加盟店、オーソリゼーションネットワーク等の構成要素が含まれる。
本実施形態では、簡明化のため、カード発行会社と加盟店管理会社とを包括して「クレジットカード会社」と称する。
なお、カード発行会社と加盟店管理会社とは同じ会社としてもよいし、異なる会社としてもよい。

なお、ネットワーク３０に接続されるクレジットカード会社サーバ１０の数や端末２０の数や店舗端末４０の数や銀行サーバ５０の数は、上記に限定されない。

本実施例では、「クレジット決済サービス」とは、クレジットカード会社（クレジットカード会社サーバ１０）が提供するサービスであって、クレジット決済を実現するためのサービスである。このクレジット決済サービスは、限定ではなく例として、ユーザ（ユーザの端末２０）、店舗（店舗端末４０）、銀行（銀行サーバ５０）に提供される。

以下では、クレジットカード会社が提携している銀行を「提携銀行」と称し、クレジットカード会社が提携している店舗を「提携店舗」と称する。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

ネットワーク３０は、通信システム１Ａを構成する各装置を接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

クレジットカード会社サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０等に対して、所定のサービス（本実施例では、クレジット決済サービス）を提供する機能を備える。クレジットカード会社サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。クレジットカード会社サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、クレジットカード会社サーバ１０は情報処理装置と表現されてもよい。クレジットカード会社サーバ１０と端末２０とを区別する必要がない場合は、クレジットカード会社サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

［各装置のハードウェア（ＨＷ）構成］
通信システム１Ａに含まれる各装置のＨＷ構成について説明する。

（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、クレジットカード会社サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、クレジットカード会社サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、クレジットカード会社サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。

音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。

位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。

位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。

衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。

慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。

ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。

制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。

（２）クレジットカード会社サーバのＨＷ構成
図１－１には、クレジットカード会社サーバ１０のＨＷ構成の一例を示している。
クレジットカード会社サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、表示部１３、時計部１９を備える。クレジットカード会社サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、クレジットカード会社サーバ１０のＨＷは、クレジットカード会社サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、クレジットカード会社サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、クレジットカード会社サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、クレジットカード会社サーバ１０に対する各種操作を入力する装置や、クレジットカード会社サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。

出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。

表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。

時計部１９は、クレジットカード会社サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

（３）店舗端末のＨＷ構成
店舗端末４０は、店舗の事業者（以下、「店舗事業者」と称する。）が使用・管理する装置である。店舗端末４０は、限定ではなく例として、サーバ、パソコン、端末（限定ではなく例として、携帯端末（スマートフォン、ＰＤＡ等））等によって実現される。

なお、店舗端末４０のＨＷ構成については、クレジットカード会社サーバ１０や端末２０と同様に構成することができるため、図示・説明を省略する。

本実施形態における店舗事業者には、クレジットカード会社と提携しており、ユーザが商品やサービスの購入をクレジットカードで行うことができるように、クレジットカード決済のシステムを導入している店舗の事業者であって、限定ではなく例として、コンビニエンスストア、スーパーマーケット、ファストフード店、飲食店、薬局、百貨店など、種々の業態の事業者を含めることができる。
店舗事業者は、本開示における事業者の一例である。

（４）銀行サーバのＨＷ構成
銀行サーバ５０のＨＷ構成や、各機能部を構成する部品や回路等は、限定ではなく例として、クレジットカード会社サーバ１０等と同様に構成することができるため、図示・説明を省略する。

（５）その他
クレジットカード会社サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、クレジットカード会社サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

本開示の各実施形態においては、端末２０および／またはクレジットカード会社サーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
他の装置についても同様である。

なお、端末２０の制御部２１、および／または、クレジットカード会社サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
他の装置についても同様である。

また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

クレジットカード会社サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
他の装置についても同様である。

また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、クレジットカード会社サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。クレジットカード会社サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。

また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
クレジットカード会社サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、クレジットカード会社サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、クレジットカード会社サーバ１０で行う構成としてもよいし、そうでなくてもよい。
クレジットカード会社サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、クレジットカード会社サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。

［各装置の機能構成］
（１）クレジットカード会社サーバの機能構成
図１－２は、本実施例においてクレジットカード会社サーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたクレジットカード決済管理処理プログラム１５１に従ってクレジットカード決済管理処理を実行するためのクレジットカード決済管理処理部１１１を機能部として含む。

図１－３は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
記憶部１５には、限定ではなく例として、クレジットカード決済管理処理として実行されるクレジットカード決済管理処理プログラム１５１と、ユーザ登録データ１５３と、提携銀行データ１５５と、提携店舗データ１５７と、ユーザ管理データベース１５９とが記憶される。

ユーザ登録データ１５３は、クレジットカード決済サービスを利用する端末２０または端末２０のユーザの登録データであり、そのデータ構成の一例を図１－４に示す。
ユーザ登録データ１５３には、限定ではなく例として、氏名と、契約者ＩＤと、認証パスワードと、クレジットカード情報と、その他登録情報とが関連付けて記憶される。

氏名は、クレジットカード決済サービスを利用する端末２０のユーザの氏名であり、限定ではなく例として、端末２０のユーザがクレジットカード決済を利用する際に登録する氏名が記憶される。

契約者ＩＤは、このユーザを識別するための識別情報として機能するＩＤである。
この契約者ＩＤは、好ましくはユーザごとに一意な値であり、限定ではなく例として、クレジットカード会社サーバ１０によってユーザごとに一意な値（固有の値）が設定されて記憶される。
契約者ＩＤは、端末のユーザに関連付けられた情報であり、端末のユーザに関する情報の一例である。

認証パスワードは、このユーザの端末２０において、クレジットカード決済サービスの機能として設けられた各種の機能を利用する際に実行する認証処理で、端末２０に入力を要求する認証用のパスワードであり、限定ではなく例として、ユーザによって設定されたパスワードが記憶される。

クレジットカード情報は、この契約者ＩＤのユーザのクレジットカードに関する情報であり、限定ではなく例として、クレジットカード番号、クレジットカードの有効期限、セキュリティコード等の情報がこれに含まれる。

その他登録情報は、このユーザのその他の登録情報であり、限定ではなく例として、以下の一部または全部の情報を含めることができる。
・住所（または居所）：このユーザの住所（または居所）。ユーザがクレジットカード決済サービスを利用する際に登録する住所（または居所）が記憶される。
・電話番号：このユーザの電話番号。限定ではなく例として、端末２０のユーザがクレジットカード決済サービスを利用する際に登録する電話番号（限定ではなく例として、端末２０の電話番号である端末電話番号）が記憶される。
・メールアドレス：このユーザのメールアドレス。限定ではなく例として、端末２０のユーザがクレジットカード決済サービスを利用する際に登録するメールアドレス（限定ではなく例として、端末２０のメールアドレスである端末メールアドレス）が記憶される。

なお、契約者ＩＤに代えて、クレジットカード情報や、電話番号・メールアドレス等の情報によってユーザを管理する手法を適用することも可能である。

また、上記の各種のユーザ情報は、クレジットカード会社サーバ１０が提供可能な他のサービスとクレジットカード決済サービスとで共通のユーザ情報としてクレジットカード会社サーバ１０で記憶・管理するようにしてもよいし、別のユーザ情報としてクレジットカード会社サーバ１０で記憶・管理するようにしてもよい。

提携銀行データ１５５は、提携銀行の管理データであり、そのデータ構成の一例を図１－５に示す。
提携銀行データ１５５には、限定ではなく例として、提携銀行ＩＤと、提携銀行名と、提携銀行サーバＵＲＩと、その他提携銀行情報とが関連付けて記憶される。

提携銀行ＩＤは、提携銀行または銀行サーバ５０を識別するための識別情報として機能するＩＤである。この提携銀行ＩＤには、限定ではなく例として、銀行コード、支店コード等の情報を含めることができる。

提携銀行名には、この提携銀行の名称（限定ではなく例として、提携銀行の商号、愛称または通称等）が記憶される。

提携銀行サーバＵＲＩには、提携銀行の銀行サーバ５０へのアクセス方法やアクセス先を含むＵＲＩ（Uniform Resource Identifier）（限定ではなく例として、ＵＲＬ（Uniform Resource Locator））が記憶される。

その他提携銀行情報は、この提携銀行ＩＤを有する提携銀行のその他の登録情報であり、限定ではなく例として、提携銀行の住所、クレジットカード決済サービスにおいて使用される、提携銀行を記号化したアイコンの画像データである提携銀行アイコン画像等の情報がこれに含まれる。

提携店舗データ１５７は、提携店舗の管理データであり、限定ではなく例として、提携店舗を識別するためのＩＤ（提携店舗ＩＤ）、提携店舗の名称、提携店舗の住所・連絡先等の情報が記憶される。

ユーザ管理データベース１５９は、ユーザ登録データ１５３に登録されているユーザに関する管理データを蓄積したデータベースであり、その一例であるユーザ管理データベース１５９Ａのデータ構成の一例を図１－６に示す。
ユーザ管理データベース１５９Ａには、ユーザ登録データ１５３に記憶されている契約者ＩＤごとの管理データとしてユーザ管理データが記憶される。

各々のユーザ管理データには、限定ではなく例として、契約者ＩＤと、取引データと、登録銀行口座データと、支払い口座設定データとが記憶される。

以下では、クレジットカード決済による商品やサービスの購入の取引のことを、単に「取引」や「クレジットカード取引」と称する。

取引データは、この契約者ＩＤのユーザが行った取引に関するデータであり、限定ではなく例として、取引ＩＤと、店舗ＩＤと、購入情報とが関連付けて記憶される。
なお、この他にも、与信照会結果の情報等を記憶させるようにすることも可能である。

取引ＩＤは、この契約者ＩＤのユーザによる商品またはサービスの購入の取引を識別するためのＩＤであり、好ましくは取引ごとに一意な値が設定されて記憶される。

店舗ＩＤには、提携店舗データ１５７に記憶された店舗ＩＤのうち、この取引ＩＤの取引が行われた店舗に対応する店舗ＩＤが記憶される。

購入情報は、その取引での商品またはサービスの購入に関する情報であり、限定ではなく例として、購入日時、購入店舗、購入金額等の情報が記憶される。

なお、クレジットカード会社サーバ１０がクレジットカード決済の取引について店舗から取得可能な情報は、限定ではなく例として、購入日時、購入店舗、購入金額の情報である可能性も考えられる。
しかし、これはあくまでも一例であり、この他に、購入された商品やサービスの名称、購入数等の情報も店舗から取得可能とし、これらの情報も併せて購入情報として記憶させるようにしてもよいし、しなくてもよい。

登録銀行口座データは、この契約者ＩＤのユーザのクレジットカードと紐づけられた銀行口座に関するデータであり、限定ではなく例として、口座ＩＤと、口座振替トークンとが記憶される。

口座ＩＤは、この契約者ＩＤのユーザの銀行口座を識別するための情報である。
口座ＩＤは、銀行口座を識別するための識別番号の他、限定ではなく例として、銀行コード、支店コード、口座番号等の情報を含めてもよい。口座ＩＤによって、この契約者ＩＤのユーザのクレジットカードと紐づけられた銀行口座が特定される。

銀行コード、支店コード、口座番号等の情報により、クレジットカード会社サーバ１０は、クレジットカードに紐づけられた銀行口座の情報を、後述するクレジットカード会社のｗｅｂページ（限定ではなく例として、支払い口座の設定ページ）に表示させることで、このｗｅｂページにアクセスしたユーザに、クレジットカードに紐づけられた銀行口座の情報を確認させることができる。

なお、口座番号の全ての桁数を記憶させる必要はなく、下３桁や下４桁など一部の桁数のみを記憶させるようにしてもよい。この場合は、記憶している一部の桁数のみを、ｗｅｂページに表示させるようにすることができる。

口座振替トークンは、この口座ＩＤの銀行口座について、この銀行口座を管理する提携銀行の銀行サーバ５０によって発行される認証用の情報である。
クレジットカード会社サーバ１０は、あらかじめ銀行サーバ５０によって発行されて銀行サーバ５０から通知された口座振替トークンと、口座振替を要求・依頼する金額（以下、「振替要求金額」と称する。）とに基づいて、この口座ＩＤの銀行口座による口座振替を銀行サーバ５０に要求・依頼する。
なお、口座振替トークンは、引き落としトークンやアクセストークン等のように表現してもよい。

支払い口座設定データは、設定された支払い口座の情報（支払い口座設定情報）に関するデータであり、限定ではなく例として、取引ＩＤと、支払い口座ＩＤとが関連付けて記憶される。

取引ＩＤには、上記の取引データの取引ＩＤが記憶される。

支払い口座ＩＤには、この取引ＩＤの取引について、登録銀行口座データに記憶された口座ＩＤのうち、端末２０のユーザによって支払い口座として選択された銀行口座に対応する口座ＩＤが記憶されて設定される。

なお、支払い口座の設定をユーザが忘れたり、そもそも行わない可能性もあり得る。
そこで、限定ではなく例として、登録銀行口座のうちユーザによってあらかじめ指定された銀行口座を、デフォルトの支払い口座として設定するようにしてもよい。
この場合、デフォルトの支払い口座とは異なる銀行口座が支払い口座として選択されると、その口座ＩＤで支払い口座ＩＤが更新されるようにすることができる。

また、支払い口座設定データは、限定ではなく例として、クレジットカード決済における月次の口座振替（引き落とし）が完了した後、当月分の支払い口座設定データとして保存するようにする、または消去やリセットするようにすることができる。

（２）端末の機能構成
図１－７は、本実施例における端末２０の制御部２１により実現される機能の一例を示す図である。
制御部２１は、主要な機能部として、限定ではなく例として、端末メイン処理部２１１を含む。

端末メイン処理部２１１は、記憶部２８に記憶されている端末メイン処理プログラム２８１に従って、各種の機能に基づく処理を行う機能を有している。

図１－８は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、端末メイン処理として実行される端末メイン処理プログラム２８１が記憶される。

＜原理・処理の概要＞
図１－９は、本実施例におけるクレジットカード決済サービスの原理を説明するための図であり、クレジットカード決済の流れを図示したものである。

本実施例では、クレジットカード決済サービスが適用される場合として、限定ではなく例として、以下のいずれかが含まれる。
（Ａ－１）端末２０のユーザ（客）が、店舗において店舗端末４０を用いてクレジットカードによる決済を行う場合
（Ａ－２）端末２０のユーザ（客）が、ＥＣサイト（限定ではなく例として、商品やサービスを販売するウェブサイト）において店舗端末４０を用いてクレジットカードによる決済を行う場合

図１－９では、これらのうち、限定ではなく例として、（Ａ－１）端末２０のユーザ（客）が、店舗において店舗端末４０を用いてクレジットカードによる決済の手続きを行った場合を例示する（図１－９に示す（１）～（９Ｂ））。

先ず、（１）端末２０のユーザが店舗で商品またはサービスを購入する際に、店舗のレジで、クレジットカード決済を行うための操作（ユーザの操作や店員の操作）を店舗端末４０に対して行う。

次いで、（２）店舗端末４０は、取引に関する情報（限定ではなく例として、決済日時、決済店舗、商品名、サービス名、購入金額（決済金額）等）と、その購入金額の与信照会（与信照会処理）を行うようにクレジットカード会社に要求する情報とを、クレジットカード会社サーバ１０に送信する。

ここで、与信照会とは、「オーソリゼーション（略して「オーソリ」とも称される。）」や「仮請求」等とも称され、クレジットカード会社に対してカード利用者（ユーザ）の信用確認（クレジットカードの有効性の確認やクレジットカードの利用限度枠の確認）をすることをいう。以下では、このクレジットカード会社サーバ１０が与信照会を行う処理のことを「与信照会処理」と称するものとする。
与信照会の結果がクレジットカード会社により「承認」された場合（以下では、「与信照会結果：承認」と称する。）、決済金額は一時的に（仮に）確保される。また、与信照会の結果がクレジットカード会社により「否認」された場合（以下では、「与信照会結果：否認」と称するものとする。）、決済金額は確保されない。

次いで、（３）与信照会処理を実行したクレジットカード会社サーバ１０は、与信照会の結果（「承認」または「否認」）の情報を店舗端末４０に送信する。

なお、図１－９では、与信照会処理を実行したクレジットカード会社サーバ１０は、与信照会の結果の情報を店舗端末４０に送信するようにしているが、これに限定されない。
与信照会の結果の情報を端末２０のみに送信してもよいし、与信照会の結果の情報を店舗端末４０と端末２０との両方に送信してもよい。

本例では、与信照会の結果が「承認」であった場合を図示・説明する。
次いで、（４）与信照会結果の情報（与信照会結果：承認）を受信した店舗端末４０のユーザ（店員）は、（１）で購入された商品またはサービスを端末２０のユーザ（客）に提供する。

次いで、（５）クレジットカード会社サーバ１０は、その店舗に購入金額・決済金額を支払う。
ここで、クレジットカード会社サーバ１０が店舗に決済金額を支払う手法として、クレジットカード会社が、店舗または店舗端末４０に紐づいている銀行の口座に振り込みを行う手法や、クレジットカード会社またはクレジットカード会社サーバ１０に紐づいている銀行の口座から店舗または店舗端末４０に紐づいている銀行の口座への振替を行う手法等が考えられる。

次いで、（６）クレジットカード会社サーバ１０は、クレジットカード会社サーバ１０が店舗端末４０に一時的に支払った決済金額の請求に係る情報（限定ではなく例として、商品購入情報、レシート情報等）と、この決済金額の支払いをいずれの銀行口座から行うかを設定するための情報（限定ではなく例として、クレジットカード会社のｗｅｂページへのリンク情報（ＵＲＩ（ＵＲＬ）等）とを含む請求情報を端末２０に送信する。

次いで、（７）決済金額の請求に係る情報を受信した端末２０のユーザが、この決済金額の支払いをいずれの銀行口座から行うかを選択する操作を行うことによって、端末２０は、支払い口座選択情報をクレジットカード会社サーバ１０に送信する。そして、クレジットカード会社サーバ１０によって、支払い口座が設定される。

（８Ａ），（８Ｂ）クレジットカード会社サーバ１０は、口座振替を提携銀行に要求（依頼）するタイミングで、支払い口座として設定された銀行口座を管理する提携銀行の銀行サーバ５０に対して、口座振替（引き落とし）を行うように要求する。

これを受けて、（９Ａ）Ａ銀行サーバ５０Ａは、振替要求金額の口座振替を行い、振替要求金額をクレジットカード会社に支払う。同様に、（９Ｂ）Ｂ銀行サーバ５０Ｂは、振替要求金額の口座振替を行い、振替要求金額をクレジットカード会社に支払う。

＜表示画面＞
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。

スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。

以下では、ユーザによる操作を、限定ではなく例として、タップ（タップ操作）として説明する。
タップ（タップ操作）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。

なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。

図１－１０は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図１－１０左は、限定ではなく例として、クレジットカード会社（クレジットカード決済サービスの事業者）（限定ではなく例として、「Ｘクレジットカード会社」、以下、この事業者名を適宜「Ｘカード」と称する。）から、請求情報として、商品購入情報と、クレジットカード会社のｗｅｂページ（限定ではなく例として、支払い口座の設定ページ）へのリンク情報とを含む電子メール（以下、適宜「Ｅメール」と称する。）を受信した場合に、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される受信Ｅメール画面である。

受信Ｅメール画面の上部左には、いずれのｗｅｂページが表示されているかをユーザに報知するための「Ｅメール」の文字が表示されている。

また、その下には、受信Ｅメールの件名（タイトル）を示す件名表示領域が構成されており、この例では、件名として「カードご利用のお知らせ」の文字が件名表示領域内に表示されている。
また、その下には、受信Ｅメールの差出人（送信元）を示す差出人表示領域が構成されており、この例では、「Ｆｒｏｍ：」の文字と、差出人（この例では「Ｘカード」）の文字とが差出人表示領域内に表示されている。

また、その下には、受信Ｅメールの本文を示す本文表示領域が構成されている。
本例では、本文表示領域には、限定ではなく例として、本文の見出しとして「ご利用情報」の文字が表示されている。
また、その下には、このクレジットカード決済の商品購入情報が表示されており、限定ではなく例として、購入日を示す「ご利用日」の欄と、購入店舗を示す「ご利用先」の欄と、購入金額を示す「ご利用金額」の欄とが設けられている。この例では、「ご利用日」の欄には「２０２０／１０／２８」が、「ご利用先」の欄には「店舗Ａ」が、「ご利用金額」の欄には「１０，０００円」がそれぞれ表示されている。

また、その下には、クレジットカード会社のｗｅｂページへのリンク情報が表示されており、クレジットカード会社のｗｅｂページの登録ＵＲＬに基づくリンクが張られた「支払い口座の設定はこちら＞」の文字を含むリンクボタンＢＴ１が表示されている。

図１－１０左に示される受信Ｅメール画面においてクレジットカード会社のｗｅｂページに移行するためのリンクボタンＢＴ１がタップされると、クレジットカード会社のｗｅｂページに移行する。

図１－１０中央には、クレジットカード会社のｗｅｂページのうち支払い口座の設定ページの表示画面（限定ではなく例として、支払い口座設定画面）の一例を示している。

この画面の上部左には、クレジットカード会社のｗｅｂページが表示されていることをユーザに報知するための「Ｘカード」の文字が表示されている。

また、その下には、このｗｅｂページが、支払い口座を設定するページであることを示す領域が構成されており、この例では、「支払い口座設定」の文字が表示されている。
具体的には、その下には、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）を表示するための銀行口座情報表示領域が構成されており、この例では、Ａ銀行に対応する銀行名として「Ａ銀行」の文字が、その口座番号として「ＸＸＸＸＸＸＸ」の数字が表示されている。また、「Ｂ銀行」に対応する銀行名として「Ｂ銀行」の文字が、その口座番号として「ＸＸＸＸＸＸＸ」の数字が表示されている。

また、その下には、商品購入情報（限定ではなく例として、購入日時、購入店舗、購入金額等）を表示するための領域が構成されており、この例では、このクレジットカード決済の商品購入情報として、「ご利用日」の欄（この例では「２０２０／１０／２８」）と、「ご利用金額」の欄（この例では「１００００円」）と、「詳細」の欄（この例では詳細を確認するためのリンク情報）とが表示されている。
この「詳細」の欄のリンク情報とは、商品購入情報の詳細な情報を含むクレジットカード会社のｗｅｂページへのリンクが張られたリンク情報である。商品購入情報の詳細な情報には、限定ではなく例として、購入日時、購入商品または購入サービスの名称、購入数、購入金額、購入店舗等の情報を含めることができる。

また、その右には、口座振替を行う銀行口座を選択するための第１アイコンを表示するための第１アイコン表示領域が構成されており、この例では、「支払い口座」の欄に、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンＩＣ１Ａと、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコンＩＣ１Ｂとが表示されている。

また、画面下部には、第１アイコンを選択した後に、その情報を保存・決定するための第２アイコンを表示するための第２アイコン表示領域が構成されており、この例では、「保存」の文字を含む第２アイコンＩＣ２が表示されている。
なお、第２アイコンＩＣ２は、第２ボタンとしてもよい。以下同様である。

図１－１０中央に示される支払い口座設定画面において、Ａ銀行に対応する第１アイコンＩＣ１Ａがタップされた後、第２アイコンＩＣ２がタップされると、限定ではなく例として、図１－１０右に示すような、クレジットカード会社のｗｅｂページのうち支払い口座の設定が完了したことを報知するページの画面（以下、「支払い口座設定完了画面」と称する。）が表示される。

また、その下には、支払い口座の設定が完了したことを示す領域が構成されており、この例では、「支払い口座の設定が完了しました。」の文字が表示されている。

また、その下には、商品購入情報を表示するための領域が構成されており、図１－１０中央の画面と同様の情報が表示されている。
また、その右には、設定した支払い口座を表示するための領域が構成されており、この例では、「支払い口座」の文字と、Ａ銀行に対応する「Ａ銀行」の文字とが表示されている。

＜処理＞
図１－１１，図１－１２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、店舗端末４０Ａ（店舗Ａの店舗端末４０）の制御部（不図示）が実行する処理、クレジットカード会社サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ５０Ａ（Ａ銀行の銀行サーバ５０）の制御部（不図示）が実行する処理、Ｂ銀行サーバ５０Ｂ（Ｂ銀行の銀行サーバ５０）の制御部（不図示）が実行する処理の一例を示している。
なお、店舗端末４０の制御部が実行する処理については図示を省略する。これは、以下同様である。

一例として、ユーザＡ．Ａが、店舗端末４０Ａによってクレジットカード決済のための手続きを行い、その口座振替を行う銀行口座を、ユーザＡ．Ａのクレジットカードに紐づけられているＡ銀行の銀行口座とＢ銀行の銀行口座との２つの銀行口座から選択する場合の処理を例示する。
なお、実際には、クレジットカードに紐づいている銀行口座は２つとは限らないが、３つ以上とする場合も同様であるため、ここでは図示・説明を省略する。

また、この処理は、本開示の手法を実現するための処理の一例に過ぎず、この処理に限定されるものではない。この処理に別のステップを追加してもよいし、この処理から一部のステップを省略（削除）してもよい。
これは、以下説明する各フローチャート（処理）について同様である。

まず、ユーザＡ．Ａが店舗端末４０Ａを用いてクレジットカード決済の手続きを行ったことに基づいて、店舗端末４０Ａの制御部は、限定ではなく例として、受け付けたクレジットカード情報と、その店舗でのその取引に関する情報（限定ではなく例として、購入日時、購入商品または購入サービスの名称、購入数、購入金額等の情報）と、その取引についての決済の与信照会処理を行うように要求する情報とを含む与信照会要求情報を、通信Ｉ／Ｆ（不図示）よってクレジットカード会社サーバ１０に送信する。

通信Ｉ／Ｆ１４によって店舗端末４０Ａから与信照会要求情報を受信すると、制御部１１は、ユーザ登録データ１５３を参照し、受信したクレジットカード情報に対応する契約者ＩＤを特定する。そして、ユーザ管理データベース１５９Ａに記憶されるユーザ管理データのうち、特定した契約者ＩＤに対応するユーザ管理データの取引データに、受信した取引に関する情報を記憶させる。そして、制御部１１は、受信された与信照会要求情報に基づいて、与信照会処理を実行する（Ｃ１１０）。そして、制御部１１は、与信照会結果の情報を含む与信照会結果情報を、通信Ｉ／Ｆ１４によって、限定ではなく例として店舗端末４０Ａに送信する（Ｃ１２０）。

通信Ｉ／Ｆによってクレジットカード会社サーバ１０から与信照会結果情報を受信すると、店舗端末４０Ａの制御部は、受信された与信照会結果情報に基づいて、与信照会結果を表示部（不図示）に表示させる（Ｂ１２０）。そして、店舗端末４０Ａの制御部は、最初に戻る。

なお、クレジットカード会社サーバ１０が、与信照会結果情報を端末２０Ａに対しても送信するようにしてもよいし、しなくてもよい。
この場合、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から与信照会結果情報を受信すると、制御部２１は、受信された与信照会結果情報に基づいて、与信照会結果を表示部２４に表示させるようにすることができる。

本実施例では、与信照会結果が「承認」である場合と、与信照会結果が「否認」である場合とのいずれの場合であっても、与信照会結果を通知（報知）するために、クレジットカード会社サーバ１０が、与信照会結果情報を送信している。

限定ではなく例として、請求情報をユーザＡ．Ａに報知するタイミング（限定ではなく例として、数日後、１週間後のタイミングなど、クレジットカード会社が設定したタイミング）で、制御部１１は、購入金額の請求に関する情報（限定ではなく例として、商品購入情報、レシート情報、取引データ（取引ＩＤ、店舗ＩＤ等））と、この購入金額の口座振替をいずれの銀行口座から行うかを設定するための情報（限定ではなく例として、クレジットカード会社のｗｅｂページへのリンク情報（ＵＲＩ（限定ではなく例としてＵＲＬ））等）とを含む請求情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ１３０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から請求情報を受信すると、制御部２１は、受信された請求情報（またはこれに基づく情報）を表示部２４に表示させる（Ａ１３０）。具体的には、限定ではなく例として、商品購入情報と、クレジットカード会社のｗｅｂページ（限定ではなく例として、支払い口座の設定ページ）へのリンク情報とを表示部２４に表示させる。

その後、制御部２１は、表示部２４に表示された請求情報に基づき、入力部を介して、支払い口座設定を行うための入力がなされたか否かを判定する（Ａ１４０）。具体的には、限定ではなく例として、クレジットカード会社のｗｅｂページ（支払い口座の設定ページ）へのリンク情報に対する入力部を介した操作を検知したか否かを判定する。
この場合における「支払い口座設定」とは、限定ではなく例として、取引が行われる都度、その取引について支払い口座を設定することを意味する。

支払い口座設定を行うための入力がなされなかったと判定した場合（Ａ１４０：ＮＯ）、制御部２１は、Ａ１９５に処理を進める。
一方、支払い口座設定を行うための入力がなされたと判定した場合（Ａ１４０：ＹＥＳ）、制御部２１は、限定ではなく例として、支払い口座の設定ページに移動するための支払い口座設定要求情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ１５０）。この場合、支払い口座設定要求情報には、限定ではなく例として、支払い口座設定ページに移動するための情報として、少なくとも請求情報のうちの取引ＩＤの情報を含めることができる。

ステップＣ１３０の後、制御部１１は、支払い口座設定要求情報を受信したか否かを判定する（Ｃ１４０）。
支払い口座設定要求情報を受信しなかったと判定した場合（Ｃ１４０：ＮＯ）、制御部１１は、ステップＣ１８０に処理を進める。

一方、支払い口座設定要求情報を受信したと判定した場合（Ｃ１４０：ＹＥＳ）、制御部１１は、受信された支払い口座設定要求情報に基づいて、決済金額の請求に関連する情報（限定ではなく例として、商品購入情報、レシート情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）とを含む支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ１５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定用情報を受信すると、制御部２１は、受信された支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定画面）を表示部２４に表示させる（Ａ１６０）。
限定ではなく例として、商品購入情報（購入日時、購入店舗、購入金額等）や、クレジットカードに紐づいている銀行口座情報（銀行名、口座番号等）、支払い口座を設定するために必要な他の情報（第１アイコン、第２アイコン等）等の情報を含む支払い口座設定画面を表示部２４に表示させるなどすることができる。

その後、制御部２１は、入力部を介したユーザによる支払い口座を選択する入力を受け付ける（Ａ１７０）。この場合、限定ではなく例として、端末２０Ａの表示部２４に表示した第１アイコン（本例では、Ａ銀行に対応する第１アイコンとＢ銀行に対応する第１アイコンのうちＡ銀行に対応する第１アイコン）がユーザＡ．Ａによって操作（限定ではなく例として、タップ）された後、第２アイコン（限定ではなく例として、「保存」アイコン）がユーザＡ．Ａによって操作（限定ではなく例として、タップ）されると、制御部２１は、選択された銀行口座（この例では、Ａ銀行の銀行口座）の情報を含む支払い口座選択情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ１８０）。

通信Ｉ／Ｆ１４によって端末２０Ａから支払い口座選択情報を受信すると、制御部１１は、支払い口座設定処理を行う（Ｃ１６０）。具体的には、限定ではなく例として、対象となる契約者（この例ではユーザＡ．Ａ）の契約者ＩＤが記憶されたユーザ管理データのうち、支払い口座設定データのうちの対応する取引ＩＤの取引について、受信した支払い口座選択情報から特定される支払い口座に対応する口座ＩＤを、支払い口座ＩＤに記憶させる。
つまり、本実施例では、クレジットカード会社サーバ１０が支払い口座を設定する。

その後、制御部１１は、支払い口座の設定が完了したことを報知するための支払い口座設定完了情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ１７０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定完了情報を受信すると、制御部２１は、受信された支払い口座設定完了情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定完了画面）を表示部２４に表示させる（Ａ１９０）。
限定ではなく例として、商品購入情報や、支払い口座情報（支払い口座としていずれかの銀行口座が設定されたことを報知する情報等）などの情報を含む支払い口座設定完了画面を表示部２４に表示させるなどすることができる。

その後、制御部２１は、処理を終了するか否かを判定し（Ａ１９５）、処理を継続すると判定したならば（Ａ１９５：ＮＯ）、最初に戻る。
一方、処理を終了すると判定したならば（Ａ１９５：ＹＥＳ）、制御部２１は、処理を終了する。

通信Ｉ／Ｆ１４によって端末２０Ａから支払い口座選択情報を受信し、支払い口座設定完了情報を送信すると、制御部１１は、口座振替要求条件が成立しているか否かを判定する（Ｃ１８０）。
口座振替要求条件とは、口座振替を銀行サーバ５０に要求（依頼）するための条件であり、限定ではなく例として、「クレジットカード決済における口座振替（引き落とし）日時（限定ではなく例として、毎月２５日の２４時）になったこと」とすることができる。

口座振替要求条件が成立したと判定した場合（Ｃ１８０：ＹＥＳ）、制御部１１は、ユーザ管理データに含まれる取引データと支払い口座設定データとに基づき、口座振替要求情報を、対応する銀行サーバ５０に通信Ｉ／Ｆ１４によって送信する（Ｃ１９０）。
具体的には、支払い口座設定データを参照し、支払い口座ＩＤごとに、その支払い口座ＩＤに関連付けて記憶されている取引ＩＤを特定する。そして、取引データを参照し、特定した取引ＩＤに関連付けて記憶されている購入金額を合算した金額を、その支払い口座の振替要求金額として算出する。そして、提携銀行データ１５５を参照し、支払い口座ＩＤごとに、対応する提携銀行サーバＵＲＩを取得し、算出した振替要求金額と、その支払い口座ＩＤに関連付けて記憶されている口座振替トークンとを含む口座振替要求情報を、通信Ｉ／Ｆ１４によって、対応する提携銀行サーバＵＲＩをアクセス先として、対応する銀行サーバ５０に送信する。
そして、制御部１１は、最新の支払い口座設定データを、当月分の支払い口座設定データとして保存する、または消去やリセットする。

なお、クレジットカード会社サーバ１０と銀行サーバ５０との間の処理は、アプリケーション・プログラミング・インタフェース（ＡＰＩ：Application Programming Interface）等によって実現することができる。これは、以下同様である。

その後、制御部１１、処理を終了するか否かを判定し（Ｃ１９５）、処理を継続すると判定したならば（Ｃ１９５：ＮＯ）、最初に戻る。
一方、処理を終了すると判定したならば（Ｃ１９５：ＹＥＳ）、制御部１１は、処理を終了する。

通信Ｉ／Ｆ（不図示）によってクレジットカード会社サーバ１０から口座振替要求情報を受信すると、Ａ銀行サーバ５０Ａの制御部（不図示）は、受信された口座振替要求情報に基づいて、口座振替処理を実行する（Ｄ１９０）。

その後、Ａ銀行サーバ５０Ａの制御部は、処理を終了するか否かを判定し（Ｄ１９５）、処理を継続すると判定したならば（Ｄ１９５：ＮＯ）、最初に戻る。一方、処理を終了すると判定したならば（Ｄ１９５：ＹＥＳ）、処理を終了する。

同様に、通信Ｉ／Ｆ（不図示）によってクレジットカード会社サーバ１０から口座振替要求情報を受信すると、Ｂ銀行サーバ５０Ｂの制御部（不図示）は、受信された口座振替要求情報に基づいて、口座振替処理を実行する（Ｅ１９０）。

その後、Ｂ銀行サーバ５０Ｂの制御部は、処理を終了するか否かを判定し（Ｅ１９５）、処理を継続すると判定したならば（Ｅ１９５：ＮＯ）、最初に戻る。一方、処理を終了すると判定したならば（Ｅ１９５：ＹＥＳ）、処理を終了する。

なお、上記の処理では、口座振替要求条件が成立した場合に（Ｃ１８０：ＹＥＳ）、クレジットカード会社サーバ１０が口座振替要求情報を銀行サーバ５０に送信し、銀行サーバ５０で口座振替処理が行われることとしたが、これに限定されない。
限定ではなく例として、Ｃ１８０のステップを省略し、クレジットカード会社サーバ１０の制御部１１が、Ｃ１７０の後、Ｃ１９０のステップを実行するようにする。つまり、支払い口座設定処理を行う都度、その取引に対応する購入金額を含む口座振替要求情報を銀行サーバ５０に送信するようにする。

この場合、銀行サーバ５０は、取引ごとにクレジットカード会社サーバ１０から送信される口座振替要求情報に基づき、購入金額を累積的に加算して更新する。そして、銀行サーバ５０は、口座振替条件（限定ではなく例として、クレジットカード決済における口座振替日時になったこと）が成立した場合に、記憶されている最新の累積金額をその支払い口座の口座振替金額として、口座振替処理を行うようにすることができる。

また、複数の口座（複数の口座情報）は、必ずしも端末２０のユーザを名義人とする口座（口座情報）である必要はなく、端末２０のユーザに関連する口座（口座情報）であればよい。いわゆる共有財布のようなものもこれに含めることができる。
同様に、クレジットカードも、必ずしも端末２０のユーザを名義人とするクレジットカードである必要はなく、端末２０のユーザに関連するクレジットカードであればよい。
詳細は後述するが、限定ではなく例として、（Ａ）法人クレジットカード、（Ｂ）家族クレジットカード、等のクレジットカードを適用する場合が、これらの一例である。

また、上記の処理では、購入情報（限定ではなく例として、請求情報）が端末２０の表示部２４に表示され、その後に、支払い口座設定ページにおいて端末２０のユーザに関連する複数の口座情報（登録銀行口座情報）が表示されることとしたが、これに限定されない。

限定ではなく例として、購入情報と複数の口座情報とが同じ画面（または同じページ）に表示されるようにしてもよい。
また、この場合、購入情報と複数の口座情報とが、同時に表示されるようにしてもよいし、非同時に表示されるようにしてもよい。
また、この場合、購入情報と複数の口座情報とが、両者を各々視認可能な位置関係や態様で表示されるようにしてもよいし、いずれか一方の情報のみを視認可能な位置関係や態様で表示されるようにしてもよい。
限定ではなく例として、一の画面に購入情報を表示した後、この購入情報に重畳（オーバーラップ）するように複数の口座情報を表示するなどしてもよい。

なお、この表示の手法は、購入情報と複数の口座情報とを表示する場合に限らず、２以上の各種の情報を表示する場合について同様に適用可能である。

＜第１実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザにより、クレジットカード決済やツケ払い等による支払い（限定ではなく、後払いの一例）で購入された商品またはサービスに関する請求情報（限定ではなく、購入情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信した請求情報と、自己の端末２０のユーザの登録銀行口座情報（限定ではなく、端末のユーザに関連する複数の口座情報の一例）とを表示部２４（限定ではなく、端末の表示部の一例）に表示する。そして、端末２０は、自己の端末２０のユーザにより、登録銀行口座情報に基づき一の口座（限定ではなく、第１口座情報に関連する第１口座の一例）が支払い口座として選択されたことに基づき、支払い口座設定完了情報（限定ではなく、購入情報の少なくとも一部の支払いを第１口座情報に関連する第１口座で支払うことに関する第１情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスを端末のユーザに確認させることができる。また、複数の口座情報のうちの第１口座情報が選択されたことに基づき、購入情報の少なくとも一部の支払いを第１口座情報に関連する第１口座で支払うことを端末のユーザに確認させるとともに、後払いで購入された商品またはサービスの支払いが第１口座から行われるようにすることができる。

ここで、購入情報は、端末が、クレジットカード会社サーバなどの後払いサービス事業者のサーバ等から受信する他、取引を行った店舗端末やＥＣサーバ等から受信するようにしてもよいし、しなくてもよい。
また、詳細は後述するが、他のサービスの事業者のサーバ等から受信するようにすることもできる。

また、本実施例は、端末２０が、端末２０のユーザにより、登録銀行口座情報のうちの第１口座情報と、請求情報のうちの第１請求情報とが選択された場合、第１口座を支払い口座とする設定が完了したことを示す第１支払い口座設定完了情報（限定ではなく、第１購入情報の支払いを第１口座で支払うことに関する第１情報の一例）を表示部２４に表示し、端末２０のユーザにより、登録銀行口座情報のうちの第２口座情報と、請求情報のうちの第２請求情報とが選択された場合、第２口座を支払い口座とする設定が完了したことを示す第２支払い口座設定完了情報（限定ではなく、第２購入情報の支払いを第２口座で支払うことに関する第２情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、後払いでの購入の各々について、その支払いを、複数の口座情報のうちの端末のユーザによって選択された口座情報に関連する口座から行うことを端末のユーザに確認させるとともに、その支払いが、対応する口座から行われるようにすることができる。

また、本実施例は、端末２０が、請求情報のうちの一の請求情報（限定ではなく、第１購入情報の一例）に対して、複数の登録銀行口座情報のうちから口座振替を行う銀行口座情報を選択するための第１アイコン等の情報（限定ではなく、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることに関する第３情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、購入情報のうちの第１購入情報に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることを、端末のユーザに報知することができる。

また、上記において、登録銀行口座情報は、端末２０のユーザに関連するクレジットカード情報（限定ではなく、端末のユーザに関連するクレジットカードの情報の一例）と関連付けられてクレジットカード会社サーバ１０に記憶されるようにすることができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報が、端末のユーザに関連するクレジットカードの情報と関連付けられるようにすることができる。

なお、登録銀行口座情報が、端末２０のユーザに関連するクレジットカード情報（限定ではなく、端末のユーザに関連するクレジットカードの情報の一例）と関連付けられて、端末２０の記憶部２８に記憶されるようにしてもよい。

また、この場合、後払いは、クレジットカードによって行われ、クレジットカードによって行われた、請求情報の少なくとも一部に対する支払いは、自己の端末２０のユーザによって選択された支払い口座（第１口座）から支払われるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの購入情報の少なくとも一部に対する支払いが、端末のユーザによって選択された第１口座情報に関連する第１口座から行われるようにすることができる。

また、この場合、後払いは、設定された日、または設定された期日までに支払うことを含むようにすることができる。
このような構成により得られる実施例の効果の一例として、設定された日、または設定された期日までに、端末のユーザによって選択された口座から後払いの支払いが行われるようにすることができる。

また、本実施例は、クレジットカード会社サーバ１０（限定ではなく、サーバの一例）が、端末２０のユーザによるクレジットカード決済による取引情報（限定ではなく、購入情報の一例）を店舗端末４０やＥＣサーバから受信し、対応する請求情報（購入情報）を通信Ｉ／Ｆ１４によって端末２０に送信する。そして、クレジットカード会社サーバ１０は、支払い口座選択情報（限定ではなく、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第１口座によって支払うことに関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０から受信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された購入情報を受信した上で、その購入情報を端末に送信して、端末のユーザに通知することができる。また、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第１口座によって支払うことに関する情報を端末から受信することで、支払いを行う口座を第１口座に設定するなどすることができる。

＜第１変形例（１）＞
上記の実施例において、クレジットカード会社サーバ１０の制御部１１が、支払い口座選択情報を端末２０から受信した場合に、選択された銀行口座を支払い口座として設定して問題ないかどうかをユーザに確認する情報（以下、「支払い口座設定確認情報」と称する。）を端末２０に送信する。そして、端末２０が、この支払い口座設定確認情報を表示部２４に表示するようにしてもよい。この場合、制御部１１は、端末２０から「確認ＯＫ」の情報を受信した場合に、支払い口座設定処理を行うようにすることができる。

また、一の銀行口座（第１口座）が支払い口座として選択されたことに基づいて、制御部１１が、第１口座が選択された旨の通知情報を端末２０に送信する。そして、端末２０が、この通知情報を表示部２４に表示するようにしてもよい。

また、一の銀行口座（第１口座）が支払い口座として選択されたことに基づいて、制御部１１が、選択された第１口座を、選択されなかった銀行口座とは異なる表示態様で表示させるようにしてもよい。この場合、限定ではなく例として、選択された第１口座をハイライト表示させるなどすることができる。

これらは、購入情報の少なくとも一部の支払いを第１口座情報に関連する第１口座で支払うことに関する第１情報、および、この第１情報の表示の一例である。

＜第１変形例（２）＞
上記の実施例の手法を、クレジットカード会社（クレジットカード会社サーバ１０）が提供するアプリケーション（以下、「クレジットカードアプリケーション」と称する。）によって実現することも可能である。
この場合、あらかじめ、端末２０がクレジットカードアプリケーションをクレジットカード会社サーバ１０から取得してインストールしておき、記憶部２８に記憶されたクレジットカードアプリケーションを実行するようにすることができる。

この場合、クレジットカードアプリケーションのアカウントのデータは、限定ではなく例として、クレジットカード会社サーバ１０の記憶部１５で記憶・管理するようにすることができる。

＜第１変形例（３）＞
上記の実施例において支払い口座が設定された後、端末２０のユーザによって支払い口座を変更する入力がなされたことに基づいて、支払い口座を別の銀行口座に変更するようにすることもできる。
以下では、これを「支払い口座の変更」と称する。

この場合は、端末２０のユーザが、クレジットカード会社サーバ１０の支払い口座設定ページに端末２０からアクセスし、支払い口座を変更する入力を行う。すると、クレジットカード会社サーバ１０は、そのユーザのユーザ管理データの支払い口座設定データのうち、対応する取引ＩＤに関連付けられた支払い口座ＩＤを、指定された支払い口座に対応する支払い口座ＩＤに更新することで、支払い口座を変更する。

＜第１変形例（４）＞
上記の実施例の手法は、前述した（２）ツケ払いについても同様に適用可能である。
この場合の処理については、クレジットカード会社サーバ１０が行う処理を、ツケ払い事業者のサーバ等の装置が行う処理に書き換えることによって、上記の実施例と同様に構成することが可能である。

（２）ツケ払いのうち、（２－１）一括ツケ払いを適用する場合は、上記の（１）クレジットカード決済とほぼ同様となる。
そこで、以下では、（２）ツケ払いのうち、（２－２）都度ツケ払いを適用する場合の処理を例示する。

図１－１３は、本変形例において各装置が実行する処理の流れの一例を示す図である。
この処理は、都度ツケ払いを適用する場合の処理例であり、クレジットカード決済と同様に、ツケ払い事業者のｗｅｂページ等からユーザ入力に基づいて支払い口座を設定し、設定した支払い口座から口座振替を行う処理例として記載したものである。

限定ではなく例として、ツケ払いの契約時等に、端末２０のユーザは、自身に関連する複数の銀行口座情報をツケ払い事業者に通知し、ツケ払い事業者のサーバ（以下、「ツケ払い事業者サーバ」と称する。）で登録されるようにすることができる。

この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、ツケ払い事業者サーバの制御部が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

なお、（２）ツケ払いでは、（１）クレジットカード決済における与信照会に相当する処理を、限定ではなく例として、購入金額、ツケ払いの利用頻度、過去の支払い実績等の情報に基づいて行うようにすることができる。
なお、この与信照会に相当する処理を行わないようにしてもよい。また、ツケ払いの契約時等のタイミングで与信の審査を行うようにしてもよい。

ツケ払い事業者サーバの制御部は、前述したＣ１７０に相当するステップを実行した後、支払い口座設定処理で設定した支払い口座に対応する銀行の銀行サーバ５０に、通信Ｉ／Ｆによって口座振替要求情報を送信する（Ｇ１９０）。
クレジットカード決済の場合とは異なり、都度ツケ払いでは、限定ではなく例として、端末２０のユーザによる取引の都度（商品やサービスの購入の都度）、口座振替が行われるようにすることができる。この場合、Ｇ１９０における口座振替要求情報の送信先の銀行サーバ５０は、その取引について支払い口座として択一的に設定した１つの銀行口座に対応する銀行サーバとなる。

その後、ツケ払い事業者サーバの制御部は、処理を終了するか否かを判定し（Ｇ１９５）、処理を継続すると判定したならば（Ｇ１９５：ＮＯ）、最初に戻る。
一方、処理を終了すると判定したならば（Ｇ１９５：ＹＥＳ）、ツケ払い事業者サーバの制御部は、処理を終了する。

＜第１変形例（５）＞
クレジットカード会社のｗｅｂページやクレジットカードアプリケーションを介して支払い口座が設定されるようにする手法に限らず、クレジットカード会社とは異なる事業者が提供する、クレジットアプリケーションとは異なるアプリケーションを介して支払い口座が設定されるようにしてもよい。

クレジットカードアプリケーションとは異なるアプリケーションとしては、限定ではなく例として、以下のアプリケーションが挙げられる。
（Ａ）チャットアプリケーション
（Ｂ）電子マネーアプリケーション（支払いアプリケーション、電子マネー決済アプリケーション）

チャットアプリケーションは、チャットサービスの事業者によって提供されるアプリケーションであって、ユーザがチャットを行うためのアプリケーションである。
限定ではなく例として、メッセージングサービスの事業者によって提供されるメッセージングアプリケーションがこれに含まれる。

電子マネーアプリケーションは、電子マネーサービスの事業者によって提供されるアプリケーションであって、ユーザが電子決済（限定ではなく例として、電子マネーによる決済）を行うためのアプリケーションである。

本変形例では、上記の（Ａ）チャットアプリケーションを適用する場合を例示する。
また、本変形例では、チャットアプリケーションの一例として、メッセージングアプリケーションを例示する。つまり、端末２０にインストールされたメッセージングアプリケーションによって、本開示に係る各種の処理が実行されることとして説明する。

また、本変形例では、メッセージングサービスを、サーバ６０を介して複数の装置間で簡単なメッセージの送受信を行うインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）とし、このメッセージングアプリケーションを、適宜「ＭｅｓｓａｇｉｎｇＡｐｐ」として図示・説明する。

なお、メッセージングサービス（ＩＭＳを含む。）は、ソーシャルネットワーキングサービス（ＳＮＳ）の１つの形態（一形態）と考えることもできる。このため、メッセージングサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスが含まれることとしてもよいし、そのようにしなくてもよい。

メッセージには、単純なテキストの他、限定ではなく例として、画像情報（静止画像情報、動画像情報の少なくともいずれか一方を含む。）、音情報（音声情報を含む。）、操作用情報（ボタン、アイコン等を含む。）、特定情報・通信情報・リンク情報（ＵＲＬ、ＵＲＩ等）など、装置間で送受信可能な各種の情報を含めることができる。

テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めることができる。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。

画像情報（画像）には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。

なお、本明細書では、メッセージングサービスで送受信される情報を「メッセージ」と称するが、これを、より広義の意味で「コンテンツ」と表現してもよい。
この場合は、コンテンツに、限定ではなく例として、テキスト、画像情報（静止画像情報、動画像情報の少なくともいずれか一方を含む。）、音情報（音声情報を含む。）、操作用情報（ボタン、アイコン等を含む。）、特定情報・通信情報・リンク情報（ＵＲＬ、ＵＲＩ等）など、装置間で送受信可能な各種の情報を含めることができる。
また、限定ではなく例として、メッセージをテキストとし、「コンテンツ」の中に、メッセージと、メッセージ以外の情報とが含まれるようにしてもよい。

本明細書におけるメッセージングサービスは、チャットサービスの一例である。
メッセージングサービスでは、ユーザが、チャットルームを利用してチャットを行うことができるように構成されている。
以下の説明では、適宜、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）を「トークルーム」と称する。
なお、トークルームをチャットルームと称してもよいし、しなくてもよい。

また、トークルームには、限定ではなく例として、１対１のユーザのトークルーム（以下、「１対１トークルーム」と称する。）の他、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）を含めることができる。この場合におけるトークルームは、複数のユーザを含むグループの各端末間で送受信されるコンテンツをグループに含まれるユーザが閲覧できるＵＩやＧＵＩのことを意味する。

また、本明細書では、メッセージングサービス（メッセージングアプリケーション）を利用する端末２０のユーザのことを「一般ユーザ」と称し、この一般ユーザのアカウントのことを「一般アカウント」と称する。
それに対し、メッセージングサービスを利用する不図示の事業者装置や事業者端末のユーザのことを「公式アカウント（ＯＡ：Official Account）事業者」と称し、この事業者のアカウントのことを「公式アカウント」と称する。
つまり、本明細書において、メッセージングサービスのアカウントには、一般アカウントと公式アカウントとが含まれる。

公式アカウントを有する事業者も、限定ではなく例として、事業者装置や事業者端末によって、一般アカウントを有する端末２０と同様に、サーバ６０を介して、他の装置との間でメッセージの送受信が可能である。限定ではなく例として、他の端末２０にメッセージが送信される場合と同様に、一般アカウントを有するユーザの端末２０から事業者装置や事業者端末宛に送信されたメッセージも、サーバ６０を介して事業者装置や事業者端末に届けられる。そして、そのメッセージの履歴が、事業者装置や事業者端末の表示部（不図示）にトークルーム等として表示される。

また、トークルームには、限定ではなく例として、１対１のユーザのトークルームである「１対１トークルーム」や、複数のユーザを含むグループの「グループトークルーム」の他、限定ではなく例として、ＯＡ事業者とのトークルーム（以下、「ＯＡトークルーム」と称する。）を含めることができる。

また、以下では、限定ではなく例として、トーク情報は、サーバ６０の記憶部６５で記憶・管理されるが、サーバ６０で追加されて更新されたトーク情報は端末２０に送信され、端末２０の記憶部２８においても、トーク情報がサーバ６０とは別に記憶されて保持されるものとする。

トーク情報とは、限定ではなく例として、アカウント間（１対１、グループを含む。）でやりとりされるコンテンツ（限定ではなく例として、メッセージ）を含む一連のトーク内容、コンテンツのやりとりの履歴（コンテンツの送受信の履歴）等の情報である。

この場合、サーバ６０の記憶容量等の問題により、サーバ６０で記憶・管理されるトーク情報は、限定ではなく例として、一定時間（限定ではなく、数週間の時間）が経過したタイミングで、サーバ６０の記憶部６５から消去するようにすることができる。
その一方で、端末２０の記憶部２８に記憶されるトーク情報のデータは、端末２０のユーザによって入力部を介して消去の入力がなされない限り、保持されるようにすることができる。

ただし、これはあくまでも一例に過ぎず、この形態に限定されるものではない。
限定ではなく例として、端末２０ではトーク情報は保持されないようにし、サーバ６０で記憶・管理されるトーク情報を、端末２０が取得して表示等するようにしてもよいし、そのようにしなくてもよい。

＜システム構成＞
図１－１４は、本変形例における通信システム１Ｂのシステム構成の一例を示す図である。
通信システム１Ｂは、図１－１の通信システム１Ａに、構成要素としてサーバ６０を追加したシステムである。

サーバ６０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービス（本変形例では、メッセージングサービス）を提供する機能を有する。
サーバ６０は、本変形例において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ６０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ６０は情報処理装置と表現されてもよい。サーバ６０と端末２０とを区別する必要がない場合は、サーバ６０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

サーバ６０は、限定ではなく例として、制御部６１（ＣＰＵ）、記憶部６５、通信Ｉ／Ｆ６４（インタフェース）、入出力部６２、時計部６９を備える。サーバ６０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ６０のＨＷは、サーバ６０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ６０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

なお、サーバ６０のＨＷは、限定ではなく例として、クレジットカード会社サーバ１０等の装置と同様とすることができるため、再度の説明を省略する。

本変形例では、サーバ６０のユーザを、メッセージングサービスの事業者（以下、「メッセージングサービス事業者」と称する。）とする。また、メッセージングサービス事業者は、クレジットカード会社とは異なる事業者とする。

この場合、端末２０のユーザによってクレジットカード決済が行われた場合、クレジットカード会社（クレジットカード会社サーバ１０）は、いずれのユーザによってクレジットカード決済が行われたかを把握可能であるが、メッセージングサービス事業者（サーバ６０）は、いずれのユーザによってクレジットカード決済が行われたかを把握する必要がある。

これを実現するための手法としては、限定ではなく例として、以下のいずれかの手法を適用することができる。
（Ｘ）端末２０のユーザがメッセージングアプリケーションのアカウント情報（限定ではなく例として、後述するメッセージングアプリケーションＩＤ等）をクレジットカード会社に通知する。限定ではなく例として、端末２０からクレジットカード会社サーバ１０にアカウント情報を送信する。そして、クレジットカード会社サーバ１０において、ユーザ情報に紐づけてアカウント情報が登録されるようにする手法
（Ｙ）端末２０のユーザがクレジットカード情報をメッセージングサービス事業者に通知する。限定ではなく例として、端末２０からサーバ６０にクレジットカード情報を送信する。そして、サーバ６０において、メッセージングサービスのアカウント情報に紐づけてクレジットカード情報が登録されるようにする手法

いずれの手法を適用することも可能であるが、本変形例では、限定ではなく例として、上記のうちの（Ｘ）の手法を適用する場合を例示する。

＜機能構成＞
（１）クレジットカード会社サーバ１０
図１－１５は、本変形例においてクレジットカード会社サーバ１０の記憶部１５に記憶されるユーザ管理データベース１５９の一例であるユーザ管理データベース１５９Ｂのデータ構成例を示す図である。
各々のユーザ管理データには、前述した契約者ＩＤ、取引データ、登録銀行口座データ、支払い口座設定データの他に、限定ではなく例として、この契約者ＩＤのユーザのメッセージングアプリケーションＩＤが記憶される。

このメッセージングアプリケーションＩＤは、限定ではなく例として、何らかのタイミング（限定ではなく例として、既にメッセージングサービスを利用している状態でクレジットカードサービスを利用する場合はクレジットカードサービスの契約時、既にクレジットカードサービスを利用している状態でメッセージングサービスを利用する場合はメッセージングサービスの契約時等のタイミング）で、端末２０からクレジットカード会社サーバ１０にメッセージングアプリケーションＩＤを送信するようにする。
または、サーバ６０からクレジットカード会社サーバ１０にメッセージングアプリケーションＩＤを送信するようにする。そして、クレジットカード会社サーバ１０は、受信したメッセージングアプリケーションＩＤを、契約者ＩＤと紐づけてユーザ管理データに記憶させて登録するようにすることができる。

（２）サーバ６０の機能構成
図１－１６は、本変形例においてサーバ６０の制御部６１によって実現される機能の一例を示す図である。
制御部６１は、記憶部６５に記憶されるメッセージングアプリケーション管理処理プログラム６５１に従って、メッセージングアプリケーション管理処理を実行するメッセージングアプリケーション管理処理部６１１を機能部として含む。

図１－１７は、本変形例においてサーバ６０の記憶部６５に記憶される情報の一例を示す図である。
記憶部６５には、限定ではなく例として、メッセージングアプリケーション管理処理として実行されるメッセージングアプリケーション管理処理プログラム６５１と、アカウント登録データ６５３と、アカウント管理データベース６５５とが記憶される。

アカウント登録データ６５３は、メッセージングアプリケーションのアカウントに関する登録データであり、そのデータ構成の一例を図１－１８に示す。
アカウント登録データ６５３には、限定ではなく例として、ユーザ名と、メッセージングアプリケーションＩＤと、その他登録情報とが関連付けて記憶される。

ユーザ名は、メッセージングアプリケーションを利用する端末２０のユーザの名称であり、限定ではなく例として、端末２０のユーザがメッセージングアプリケーションを利用する際に登録する名称が記憶される。

メッセージングアプリケーションＩＤは、メッセージングアプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このメッセージングアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ６０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
メッセージングアプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、メッセージングアプリケーションＩＤとすることができる。
なお、メッセージングアプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。

また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。

また、限定ではなく例として、１つのユーザＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。

また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ６５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ６５３に記憶させるようにすることができる。

アカウント管理データベース６５５は、アカウント登録データ６５３に記憶されたアカウントの管理用のデータベースであり、その一例であるアカウント管理データベース６５５Ａのデータ構成例を図１－１９に示す。
アカウント管理データベース６５５Ａには、アカウント登録データ６５３に記憶されたメッセージングアプリケーションＩＤごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、友だちデータと、トーク情報データと、取引データとが記憶される。

友だちデータは、このメッセージングアプリケーションＩＤのアカウントが友だち登録しているアカウントに関するデータである。友だち登録しているアカウントには、前述した一般アカウントの他、前述した公式アカウントも含めることができる。

本変形例では、端末２０のユーザがクレジットカード会社の公式アカウントを友だちに追加する操作を行い、サーバ６０において、クレジットカード会社の公式アカウントが友だちデータに登録されているものとして説明する。

トーク情報データは、このメッセージングアプリケーションＩＤのアカウントのトーク情報のデータである。
サーバ６０は、限定ではなく例として、メッセージ情報の送信元の端末２０から送信されたメッセージ情報を受信し、受信したメッセージ情報を、対応するアカウントのトークルームに追加する処理を行う。具体的には、アカウント管理データベース６５５Ａのうちの対応するアカウントのアカウント管理データにおいて、対応するトークルームのトーク情報に、受信したメッセージ情報を追加して更新する。そして、サーバ６０は、トークルームへの追加内容（トークルームに追加したメッセージ情報）を、送信先のユーザの端末２０に送信する。これにより、端末２０の表示部２４に表示されるトークルームにおけるメッセージ情報が更新される。

取引データは、クレジットカード会社サーバ１０から送信される請求情報（購入情報）に基づいて記憶される、端末２０のユーザによりクレジットカード決済で購入された購入情報のデータである。
なお、このアカウント管理データに記憶される取引データは、クレジットカード会社サーバ１０のユーザ管理データに記憶される取引データに記憶される情報のうちの少なくとも一部の情報を含むデータであればよい。

（３）端末２０の機能構成
図１－２０は、本変形例において端末２０の制御部２１によって実行される機能の一例を示す図である。
制御部２１は、前述した端末メイン処理部２１１の他に、限定ではなく例として、記憶部２８に記憶されるメッセージングアプリケーションプログラム２８３に従ってメッセージングアプリケーション処理を実行するメッセージングアプリケーション処理部２１３を機能部として含む。

図１－２１は、本変形例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、前述した端末メイン処理プログラム２８１の他に、限定ではなく例として、メッセージングアプリケーションプログラム２８３と、メッセージングアプリケーションのアカウントのデータであるメッセージングアプリケーションＩＤ２８５とが記憶される。

＜原理・処理の概要＞
図１－２２は、本変形例におけるクレジットカード決済サービスの原理を説明するための図であり、クレジットカード決済の流れを図示したものである。
なお、図１－９と同様の部分については説明を省略する。

（５）クレジットカード会社サーバ１０が店舗に購入金額を支払うと、（６－１）クレジットカード会社サーバ１０は、請求情報をサーバ６０に送信する。そして、（６－２）サーバ６０は、限定ではなく例として、メッセージングアプリケーションのメッセージ情報であって、この請求情報に対応するメッセージ情報である請求メッセージ情報を端末２０に送信する。

次いで、（７－１）請求メッセージ情報を受信した端末２０のユーザにより、端末２０の表示部２４に表示された請求メッセージ情報に基づき、支払い口座を選択する入力がなされたことに基づいて、支払い口座が設定される。

なお、支払い口座の設定（支払い口座設定処理）を行う主体は、限定ではなく例として、以下のいずれかとすることができる。
・クレジットカード会社サーバ１０
・サーバ６０

クレジットカード会社サーバ１０によって支払い口座が設定される場合は、（７－１）支払い口座選択情報が端末２０からクレジットカード会社サーバ１０に送信される。そして、クレジットカード会社サーバ１０によって支払い口座が設定される。
それに対し、サーバ６０によって支払い口座が設定される場合は、（７－１）支払い口座選択情報が端末２０からサーバ６０に送信される。そして、サーバ６０によって支払い口座が設定された後、（７－２）支払い口座設定情報がサーバ６０からクレジットカード会社サーバ１０に送信される。
この詳細については後述する。

＜表示画面＞
図１－２３は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１－２３左は、メッセージングアプリケーションのトークルーム画面の一例であり、画面最上部中央には、メッセージングアプリケーションの名称として「ＭｅｓｓａｇｉｎｇＡｐｐ」の文字が表示されている。また、画面最上部右には、この端末２０のユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＡ．Ａ）が表示されている。

また、その下には、限定ではなく例として、メッセージングアプリケーション内のいずれのページ（この例では、トークルーム）が現在表示されているかを示す領域の一種として、トークルームの名称（以下、「トークルーム名」と称する。）を含むトークルーム名表示領域ＣＬＲが設けられている。トークルーム名表示領域ＣＬＲは、現在ユーザが位置しているメッセージングアプリケーション内のページ（この例では、トークルーム）を示す領域とも言える。

本例では、トークルーム名表示領域ＣＬＲには、限定ではなく例として、ユーザＡ．Ａがクレジットカード会社である「Ｘカード」をトーク相手としてトークを行うためのＯＡトークルームであることを示す情報（この例では、「ＯＡ」のアイコンおよび「Ｘカード」の文字）が表示されている。

また、その下には、ユーザＡ．ＡとＸカードとが対話形式でトークを行うためのトーク領域が構成されており、画面向かって左側には相手であるＸカードを送信元とするメッセージ情報（メッセージ）が、画面向かって右側には自分であるユーザＡ．Ａのメッセージ情報が表示されるように構成されている。

この例では、ユーザＡ．Ａによる店舗Ａでの１回の取引に関する情報（画面では「ご利用情報」）を含む請求メッセージ情報がＸカードを送信元として送信され、サーバ６０を介して、端末２０Ａが請求メッセージ情報を受信したことに基づいて、このＯＡトークルームの画面向かって左側に、Ｘカードのアイコン画像と関連付けて、請求メッセージ情報が表示されている。

請求メッセージ情報の下部には、支払い口座の設定を行うために操作されるボタンであって、限定ではなく例として、前述したクレジットカード会社のｗｅｂページ（限定ではなく例として、振替を行う銀行口座の設定ページ）へのリンクが張られた「支払い口座の設定はこちら＞」の文字を含むリンクボタンＢＴ２が設けられている。

このリンクボタンＢＴ２がタップされると、メッセージングアプリケーションを経由してクレジットカード会社のｗｅｂページに遷移し、限定ではなく例として、図１－１０中央と同様のクレジットカード会社のｗｅｂページが表示される。
以降は、図１－１０と同様である。

＜処理＞
図１－２４，図１－２５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。本処理は、サーバ６０を、メッセージングサービス事業者のサーバとする場合の処理の一例である。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、サーバ６０の制御部６１が実行する処理、クレジットカード会社サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

Ｃ１２０の後、制御部１１は、限定ではなく例として、対象とする契約者ＩＤのユーザのメッセージングアプリケーションのアカウント情報（限定ではなく例として、メッセージングアプリケーションＩＤ）を含む請求情報を、通信Ｉ／Ｆ１４によってサーバ６０に送信する（Ｃ１３１）。

通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０から請求情報を受信すると、サーバ６０の制御部６１は、トークルーム用のメッセージ情報であって、受信した請求情報に対応するメッセージ情報（以下、「請求メッセージ情報」と称する。）を生成する。そして、制御部６１は、生成した請求メッセージ情報を、受信した請求情報に含まれるメッセージングアプリケーションＩＤのトークルームであって、トーク相手のアカウントをクレジットカード会社の公式アカウントとするＯＡトークルームに追加する。つまり、アカウント管理データベース６５５Ａのうち、上記のメッセージングアプリケーションＩＤに対応するアカウント管理データについて、そのトーク情報データを更新する。そして、制御部６１は、追加したメッセージ情報を、上記のメッセージングアプリケーションＩＤの端末２０（この例では端末２０Ａ）に通信Ｉ／Ｆ６４によって送信する（Ｂ１３１）。

その後、制御部６１は、処理を終了するか否かを判定し（Ｂ１９５）、処理を継続すると判定したならば（Ｂ１９５：ＮＯ）、最初に戻る。一方、処理を終了すると判定したならば（Ｂ１９５：ＹＥＳ）、制御部６１は、処理を終了する。

通信Ｉ／Ｆ２２によってサーバ６０から請求メッセージ情報を受信すると、制御部２１は、受信した請求メッセージ情報を含むＯＡトークルームを表示部２４に表示させる（Ａ１３１）。そして、制御部２１は、Ａ１４０に処理を進める。
つまり、この処理では、端末２０は、メッセージングアプリケーションからクレジットカード会社のｗｅｂページに遷移して支払い口座の設定のための入力を行い、クレジットカード会社サーバ１０によって支払い口座設定処理が行われる（Ｃ１６０）。

本例では、メッセージングアプリケーションのトークルームからクレジットカード会社のｗｅｂページに遷移させて支払い口座を選択させるようにしている。
なお、別の手法として、メッセージングアプリケーションのトークルームからメッセージングアプリケーションの支払い口座設定用のページに遷移させて支払い口座を選択させるようにしてもよい。

限定ではなく例として、メッセージングアプリケーションのトークルームに表示される支払い口座設定用のメッセージ情報において、ユーザが分かり易いように、支払い口座として選択された銀行口座の表示態様（第１表示態様）を、支払い口座として選択されなかった銀行口座とは異なる表示態様（第２表示態様）で表示させることが考えられる。
しかし、前述したように、端末２０に送信されたメッセージ情報が端末２０の記憶部２８に記憶されて保存される形態を適用することも可能であるため、この場合は、上記のように別のページに遷移させて支払い口座を選択させるようにするとよい。

ただし、サーバ６０側で表示態様等を変更したメッセージ情報を生成し、これを端末２０に送信することはメッセージ情報の改変に該当しないとも言えるため、このような手法を適用することも可能である。

また、上記の処理では、支払い口座が設定された場合に、支払い口座設定完了メッセージ情報がサーバ６０から端末２０に送信されることとした。
これに関連して、ユーザによる支払い口座を変更する入力に基づいて、支払い口座を別の銀行口座に変更した場合に、支払い口座が変更されたことを示す支払い口座変更メッセージ情報がサーバ６０から端末２０に送信されるようにしてもよい。

＜別の手法＞
図１－２６は、本変形例においてサーバ６０の記憶部６５に記憶されるアカウント管理データベース６５５の別例であるアカウント管理データベース６５５Ｂのデータ構成例を示す図である。
このアカウント管理データベース６５５Ｂでは、各々のアカウント管理データにおいて、友だちデータと、トーク情報データと、取引データとの他に、限定ではなく例として、登録銀行口座データと、支払い口座設定データとが記憶される。

登録銀行口座データおよび支払い口座設定データは、限定ではなく例として、クレジットカード会社サーバ１０のユーザ管理データベース１５９Ｂにおけるものと同様とすることができる。
限定ではなく例として、サーバ６０は、何らかのタイミングで登録銀行口座データをクレジットカード会社サーバ１０から取得して、アカウント管理データに記憶させるようにすることができる。

なお、メッセージングサービス事業者側でユーザの銀行口座に関する情報（本明細書では、クレジットカードに関する情報ともいえる。）が保持、管理されることをユーザが嫌がったり、セキュリティ面で好ましくないと捉える考え方もあり得る。
そこで、サーバ６０が、限定ではなく例として締め日（締め日時）にクレジットカード会社サーバ１０に必要な情報を送信した後、上記のアカウント管理データから、限定ではなく例として、登録銀行口座データを消去するようにしてもよい。同様に、支払い口座設定データを消去するようにしてもよい。

図１－２７は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１－２７左には、図１－２３と同様のＯＡトークルームを示しているが、表示される請求メッセージ情報の内容が一部異なっている。
具体的には、請求メッセージ情報の下部には、自分（この例ではユーザＡ．Ａ）が支払い口座として設定可能な銀行口座の一覧が表示されており、この例では、「Ａ銀行」のアイコンＩＣ３Ａと、「Ｂ銀行」のアイコンＩＣ３Ｂとが表示されている。

限定ではなく例として「Ａ銀行」のアイコンがタップされると、図１－２７中央のような表示がなされる。具体的には、図１－２７左のＯＡトークルームにおいて支払い口座として「Ａ銀行」の銀行口座がタップされて選択されたことに基づいて、自分（ユーザＡ．Ａ）を送信元とするメッセージ情報として「Ａ銀行を選択する」と示されたメッセージ情報が、画面向かって右側に吹き出しで表示されている。

また、画面中央部には、支払い口座として「Ａ銀行」の銀行口座を設定するか否かを確認するためのテキストを含む確認情報がポップアップ形式で表示されている。
この確認情報には、限定ではなく例として、「支払い口座をＡ銀行に設定しますか？」のテキストとともに、承認するための「はい」のボタンと、承認しないための「いいえ」のボタンとが表示されている。

限定ではなく例として「はい」のボタンがタップされると、図１－２７右のような表示がなされる。具体的には、図１－２７中央のＯＡトークルームにおいて「はい」のボタンがタップされて選択されたことに基づいて、自分（ユーザＡ．Ａ）を送信元とするメッセージ情報として「はい」と示されたメッセージ情報が、上記の「Ａ銀行を選択する」と示されたメッセージ情報の下に表示されている。

また、支払い口座の設定がサーバ６０によって行われたことに基づき、支払い口座の設定が完了したことを示す支払い口座設定完了メッセージ情報が、図１－２７左のＯＡトークルーム画面に表示されていた請求メッセージ情報の下に表示されている。

図１－２８は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。本処理は、サーバ６０を、メッセージングサービス事業者のサーバとする場合の処理の一例である。
通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０から請求情報を受信すると、制御部６１は、受信した請求情報に含まれるアカウント情報から特定されるアカウント管理データに記憶されている登録銀行口座データに基づき、登録銀行口座情報を含む請求メッセージ情報を生成する。そして、制御部６１は、生成した請求メッセージ情報を、トーク相手のアカウントをクレジットカード会社の公式アカウントとするＯＡトークルームに追加し、追加した請求メッセージ情報を通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ１３２）。

通信Ｉ／Ｆ２２によってサーバ６０から請求メッセージ情報を受信すると、制御部２１は、受信した請求メッセージ情報を含むＯＡトークルームを表示部２４に表示させる（Ａ１３２）。そして、制御部２１は、Ａ１４０に処理を進める。

通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、支払い口座設定処理を行う（Ｂ１６０）。
具体的には、アカウント管理データベース６５５Ｂの端末２０Ａのユーザのアカウント管理データのうち、支払い口座設定データの対応する取引ＩＤの取引について、受信した支払い口座選択情報から特定される銀行口座に対応する口座ＩＤを、支払い口座ＩＤに記憶させる。
つまり、本処理では、クレジットカード会社サーバ１０ではなく、メッセージングサービス事業者のサーバ６０が支払い口座設定処理を行う。

その後、制御部６１は、支払い口座設定完了メッセージ情報を生成し、生成した支払い口座設定完了メッセージ情報を上記のＯＡトークルームに追加する。そして、追加した支払い口座設定完了メッセージ情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ１７２）。

通信Ｉ／Ｆ２２によってサーバ６０から支払い口座設定完了メッセージ情報を受信すると、制御部２１は、受信した支払い口座設定完了メッセージ情報を上記のＯＡトークルームに表示させる（Ａ１９２）。そして、制御部２１は、Ａ１９５に処理を進める。

Ｂ１７２の後、制御部６１は、支払い口座設定情報送信条件が成立したか否かを判定する（Ｂ１８０）。
支払い口座設定情報送信条件は、支払い口座設定情報をクレジットカード会社サーバ１０に送信する条件であり、限定ではなく例として、「提携銀行に口座振替を依頼する日にち（期日）になったこと」とすることができる。
支払い口座設定情報は、支払い口座設定処理で設定した支払い口座に関する情報である。

支払い口座設定情報送信条件が成立したと判定した場合（Ｂ１８０：ＹＥＳ）、制御部６１は、対象とするアカウントのアカウント管理データに記憶されている最新の支払い口座設定データに対応する支払い口座設定情報を、通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０に送信する（Ｂ１９０）。そして、制御部６１は、Ｂ１９５に処理を進める。

Ｃ１３２の後、制御部１１は、通信Ｉ／Ｆ１４によってサーバ６０から支払い口座設定情報を受信したか否かを判定する（Ｃ１８０）。

受信したと判定したならば（Ｃ１８０：ＹＥＳ）、制御部１１は、取引データと、受信した支払い口座設定情報に基づき、支払い口座ごとに、振替要求金額を算出する。具体的には、支払い口座設定データを参照し、支払い口座ＩＤごとに、その支払い口座ＩＤに関連付けて記憶されている取引ＩＤを特定する。そして、取引データを参照し、特定した取引ＩＤに関連付けて記憶されている購入金額を合算した金額を、その支払い口座の振替要求金額として算出する。そして、制御部１１は、支払い口座ごとに、算出した振替要求金額と、その支払い口座ＩＤに関連付けて記憶されている口座振替トークンとを含む口座振替要求情報を、対応する銀行サーバ５０に通信Ｉ／Ｆ１４によって送信する（Ｃ１９１）。そして、制御部１１は、Ｃ１９５に処理を進める。

なお、サーバ６０と銀行サーバ５０との間の処理は、アプリケーション・プログラミング・インタフェース（ＡＰＩ）等によって実現することができる。これは、以下同様である。

また、本変形例において、メッセージングアプリケーションに代えて、電子マネーアプリケーションを適用することも可能である。
この場合は、通信システム１Ｂにおいて、サーバ６０を電子マネーサービス事業者のサーバとし、メッセージングアプリケーションのアカウント（限定ではなく例として、メッセージングアプリケーションＩＤ）を、電子マネーアプリケーションのアカウント（限定ではなく例として、電子マネーアプリケーションＩＤ）として、上記の実施例と同様の処理を行うようにすることができる。

電子マネーアプリケーションでは、電子マネーを補充（チャージ）し、チャージされた電子マネーを用いて、電子マネー決済等を行うことを可能とすることができる。
この場合、チャージする手法としては、限定ではなく例として、プリペイドカードを用いてチャージを行う手法や、ユーザが銀行口座の登録をサーバ６０に要求して自身のアカウント（電子マネーアプリケーションＩＤ）に銀行口座の情報が関連付けられるようにし、登録された銀行口座からチャージを行うようにする手法等を適用することができる。

また、電子マネーアプリケーションでは、ユーザの金銭を扱うという性質上、原則的には、電子マネーサービス事業者側でユーザの身分証明を行う必要がある。
この身分証明は、運転免許証等の公的な証明書の提示をユーザに要求して行う手法の他、クレジットカード情報の提示をユーザに要求して行うようにすることも可能である。

クレジットカード情報の提示をユーザに要求する場合、サーバ６０が、そのユーザのアカウントと関連付けてクレジットカード情報を保持しておくことで、サーバ６０は、そのクレジットカード情報に基づいて、そのユーザの登録銀行口座の情報や、そのユーザがクレジットカードを利用して行った取引に関する情報等の情報を、クレジットカード会社サーバ１０に照会することができる。

なお、以下では、電子マネーサービスとして提供されるアプリケーションである電子マネーアプリケーションを、適宜「ＰａｙｍｅｎｔＡｐｐ」として図示・説明する。

図１－２９は、本変形例においてサーバ６０の記憶部６５に記憶されるアカウント管理データベース６５５の別例であるアカウント管理データベース６５５Ｃのデータ構成例を示す図である。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションＩＤと、電子マネー口座残高と、取引データと、登録銀行口座データと、支払い口座設定データとが記憶される。

電子マネーアプリケーションＩＤは、電子マネーアプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
この電子マネーアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ６０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
電子マネーアプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

電子マネー口座残高は、この電子マネーアプリケーションＩＤ（このアカウント）の電子マネー口座の残高の金額である。

登録銀行口座データおよび支払い口座設定データは、限定ではなく例として、前述したクレジットカード会社サーバ１０のユーザ管理データベース１５９Ｂと同様に構成することができる。
限定ではなく例として、サーバ６０は、登録銀行口座データをクレジットカード会社サーバ１０に要求し、クレジットカード会社サーバ１０から登録銀行口座データを取得して、アカウント管理データに記憶させるようにすることができる。

図１－３０は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。本処理は、サーバ６０を、電子マネーサービス事業者のサーバとする場合の処理の一例である。
Ｂ１５０の後、制御部６１は、支払い口座設定処理を行う（Ｂ１６０）。
具体的には、アカウント管理データベース６５５Ｃの端末２０Ａのユーザのアカウント管理データのうち、支払い口座設定データの対応する取引ＩＤの取引について、端末２０Ａから受信した支払い口座選択情報から特定される銀行口座に対応する口座ＩＤを、支払い口座ＩＤに記憶させる。
つまり、本処理では、クレジットカード会社サーバ１０ではなく、電子マネーサービス事業者のサーバ６０が支払い口座設定処理を行う。
そして、制御部６１は、Ｂ１７０に処理を進める。

＜第１変形例（６）＞
前述した（Ａ）チャットアプリケーション（メッセージングアプリケーション）を適用する場合や（Ｂ）電子マネーアプリケーションを適用する場合の他に、限定ではなく例として、チャットと支払いとの両方を行うことができるアプリケーションを適用することも可能である。この形態としては、限定ではなく例として、以下のいずれかの形態が考えられる。
（ａ）チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
（ｂ）電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
（ｃ）チャットサービスの機能と電子マネーサービスの機能とを有する複合的（統合的）なアプリケーションを構成する形態
以下、これらの形態を適用する場合について説明する。

この場合のシステム構成は、限定ではなく例として、通信システム１Ｂ（図１－１４）と同様の構成を適用し、サーバ６０が、メッセージングサービスを提供する機能（メッセージングアプリケーションの情報を管理する機能）と、電子マネーサービスを提供する機能（電子マネーアプリケーションの情報を管理する機能）とを有するようにすることができる。

説明の簡明化のため、ここでは、サーバ６０を複合的な機能を有する１つのサーバとして説明する。
なお、これとは異なり、通信システム１Ｂにおいて、サーバ６０を、メッセージングサービス用のサーバ（第１サーバ）と、電子マネーサービス用のサーバ（第２サーバ）との２つに分けてもよい。

図１－３１は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１－３１左には、図１－２３左と同様のメッセージングアプリケーションのＯＡトークルーム画面を示している。
この画面において「支払い口座の設定はこちら＞」の文字を含むリンクボタンＢＴ２がタップされると、限定ではなく例として、端末２０において電子マネーアプリケーションが起動され、限定ではなく例として、図１－３１中央の画面が表示される。

この画面は、電子マネーアプリケーションにおける支払い口座設定画面であり、画面最上部には、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、支払い口座を設定するための情報が表示されている。

具体的には、「支払い口座設定」の文字とともに、登録されているユーザＡ．Ａの銀行口座に関する情報として、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）を表示するための銀行口座情報表示領域が構成されている。

また、その右には、振替を行う銀行口座を選択するための第１アイコンを表示するための第１アイコン表示領域が構成されており、この例では、「支払い口座」の欄に、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンＩＣ１Ａと、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコンＩＣ１Ｂとが表示されている。

また、画面下部には、第１アイコンを選択した後に、その情報を保存・決定するための第２ボタン（第２アイコン）を表示するための第２アイコン表示領域が構成されており、この例では、「保存」の文字を含む第２ボタンＢＴ３が表示されている。この第２ボタンＢＴ３の機能は、図１－１０に示した第２アイコンＩＣ２と同様である。

図１－３１中央に示される支払い口座設定画面において、限定ではなく例として、Ａ銀行に対応する第１アイコンＩＣ１Ａがタップされた後、第２ボタンＢＴ３がタップされると、限定ではなく例として、図１－３１右に示すような支払い口座設定完了画面が、電子マネーアプリケーションにおいて表示される。

図１－３２は、本変形例において各装置が実行する処理の流れの別例を示すフローチャートである。本処理は、サーバ６０を、メッセージングサービス事業者または電子マネーサービス事業者のサーバとする場合の処理の一例である。
Ａ１３１の後、制御部２１は、支払い口座設定を行うための入力がなされたか否かを判定する（Ａ１４１）。具体的には、限定ではなく例として、ＯＡトークルームに表示された請求メッセージ情報に含まれるリンクボタンがタップされるなどして、支払い口座設定を行うための入力がなされたか否かを判定する。

支払い口座設定を行うための入力がなされたと判定したならば（Ａ１４１：ＹＥＳ）、制御部２１は、通信Ｉ／Ｆ２２によって支払い口座設定ページをサーバ６０に要求する（Ａ１５１）。
これを受けて（Ｂ１５１：ＹＥＳ）、制御部６１は、電子マネーアプリケーションの支払い口座設定ページを、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ１５３）。

すると、制御部２１は、電子マネーアプリケーションを起動して、メッセージングアプリケーションから電子マネーアプリケーションに遷移し、受信した支払い口座設定用ページを表示部２４に表示させる（Ａ１５３）。そして、制御部２１は、Ａ１７０に処理を進める。

Ｂ１６０の後、制御部６１は、支払い口座設定完了情報を生成し、生成した支払い口座設定完了情報を上記の支払い口座設定ページに追加して通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ１７４）。これを受けて、制御部２１は、支払い口座設定完了情報を含む電子マネーアプリケーションの支払い口座設定ページを表示部２４に表示させる（Ａ１８４）。そして、制御部２１は、Ａ１９５に処理を進める。

上記の変形例では、サーバ６０（限定ではなく、サーバの一例）が、端末２０のユーザによるクレジットカード決済の請求情報（限定ではなく、購入情報の一例）をクレジットカード会社サーバ１０から受信し、受信された請求情報を通信Ｉ／Ｆ６４によって端末２０に送信する。そして、サーバ６０は、支払い口座選択情報（限定ではなく、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第１口座によって支払うことに関する情報の一例）を通信Ｉ／Ｆ６４によって端末２０から受信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された購入情報を受信した上で、その購入情報を端末に送信して、端末のユーザに通知することができる。また、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第１口座によって支払うことに関する情報を端末から受信することで、支払いを行う口座を第１口座に設定するなどすることができる。

＜第１変形例（７）＞
上記の変形例では、通信システム１Ｂにおいて、クレジットカード会社サーバ１０とサーバ６０とを異なるサーバとして構成する例を示したが、これに限定されない。
クレジットカード会社サーバ１０とサーバ６０とを、１つのサーバ（同じサーバ）として構成することも可能である。

＜第２実施例＞
第１実施例では、ユーザが商品やサービスをクレジットカード決済で購入するごと、つまり取引ごとに、支払い口座設定を行う実施例を示した。
第２実施例は、１または複数の取引に対して、まとめて支払い口座設定を行うことを可能にする実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、制御部１１が、前述した請求情報を送信する処理とは別に、前述した請求情報とは異なる請求情報の一例である「当月確定請求情報」を送信する処理（図２－２参照）を行う場合を例示する。

「当月確定請求情報」とは、限定ではなく例として、当月分のクレジットカード決済の請求に関する当月商品購入情報（限定ではなく例として、決済月情報、合計決済金額情報、取引別購入日時、取引別購入金額、取引別店舗等の情報を含む。）や、この合計決済金額のうちの各決済金額（取引別）の振替をいずれの銀行口座から行うかを設定するための情報（限定ではなく例として、クレジットカード会社のｗｅｂページへのリンク情報とを含む情報である。当月商品購入情報には、当月の購入履歴に関する情報が含まれる。
なお、「当月」は、「今月」、「現在の月」、「決済対象月」等のように表現してもよいし、しなくてもよい。

なお、購入履歴に関する情報とは、限定ではなく例として、購入履歴そのものの情報や、購入履歴を表示するために必要な情報など、購入履歴と何らかの関係性を有する情報である。

＜表示画面＞
図２－１は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図２－１は、ユーザが、今月度（本例では１０月度）の複数のクレジットカード取引に対してまとめて支払い口座設定を行う場合の表示画面の一例を示す図である。

図２－１左は、限定ではなく例として、クレジットカード会社（Ｘカード）から、当月確定請求情報として、当月決済情報と、クレジットカード会社のｗｅｂページへのリンク情報とを含むＥメールを受信した場合に、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される受信Ｅメール画面である。

受信Ｅメール画面の本文表示領域には、限定ではなく例として、本文の見出しとして「１０月度ご利用情報」の文字が表示されている。
また、その下には、今月度（１０月度）の当月決済情報が表示されており、限定ではなく例として、決済月を示す「ご利用月」の欄と、合計決済金額を示す「ご利用合計金額」の欄とが設けられている。この例では、「ご利用月」の欄には「２０２０／１０」が、「ご利用合計金額」の欄には「５０，０００円」がそれぞれ表示されている。

また、その下には、クレジットカード会社のｗｅｂページ（限定ではなく例として、今月度の支払い口座の設定ページ）へのリンク情報が表示されており、クレジットカード会社のｗｅｂページの登録ＵＲＬに基づくリンクが張られた「今月度の支払い口座の設定はこちら＞」の文字を含むリンクボタンＢＴ４が表示されている。
また、その他には、図１－１０左の画面と同様の情報が表示されている。

図２－１左に示される受信Ｅメール画面においてクレジットカード会社のｗｅｂページに移行するためのリンクボタンＢＴ４がタップされると、クレジットカード会社のｗｅｂページに移行する。

図２－１中央には、クレジットカード会社のｗｅｂページのうち今月度の支払い口座の設定ページの表示画面（以下、適宜「今月度支払い口座設定画面」と称する。）（限定ではなく例として、今月度支払い口座設定画面のうち「１０月度支払い口座設定画面」）の一例を示している。

今月度支払い口座設定画面のうち、このｗｅｂページが支払い口座を設定するページであることを示す領域には、「１０月度支払い口座設定」の文字が表示されている。

また、その下には、当月商品購入情報（限定ではなく例として、購入日時、購入金額等）を表示するための領域が構成されており、この例では、このクレジットカード決済の商品購入情報として、「ご利用日」の欄（この例では「２０２０／１０／０１」、「２０２０／１０／１５」、「２０２０／１０／２８」）と、「ご利用金額」の欄（この例では「２５，０００円」、「１５，０００円」、「１０，０００円」）と、「詳細」の欄（図１－１０参照）と、が購入日時順に表示されている。

また、その右の第１アイコン表示領域には、「支払い口座」の欄に、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンＩＣ１Ａと、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコンＩＣ１Ｂと、がクレジットカード取引毎に表示されている。
また、その他には、図２－１中央の画面と同様の情報が表示されている。

図２－１中央に示される１０月度支払い口座設定画面において、各クレジットカード取引における第１アイコン（本例では、上から順に「Ａ銀行に対応する第１アイコンＩＣ１Ａ」、「Ｂ銀行に対応する第１アイコンＩＣ１Ｂ」、「Ａ銀行に対応する第１アイコンＩＣ１Ａ」）がタップされた後、第２アイコンＩＣ２がタップされると、限定ではなく例として、図２－１右に示すような、クレジットカード会社のｗｅｂページのうち今月度の支払い口座の設定が完了したことを報知するページの画面（以下、適宜「今月度支払い口座設定完了画面」と称する。）が表示される。

この今月度支払い口座設定画面の、支払い口座の設定が完了したことを示す領域には、「１０月度支払い口座の設定が完了しました。」の文字が表示されている。

また、その下には、当月商品購入情報を表示するための領域が構成されており、図２－１中央の画面と同様の情報が表示されている。
また、その右には、設定した支払い口座を表示するための領域が構成されており、この例では、「支払い口座」の文字と、各クレジットカード取引別に上から順に、Ａ銀行に対応する「Ａ銀行」の文字と、Ｂ銀行に対応する「Ｂ銀行」の文字と、Ａ銀行に対応する「Ａ銀行」の文字とが表示されている。

＜処理＞
図２－２，図２－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図２－２は、第１実施例で説明したフローチャートのうちの図１－１２に対応する部分であり、Ｃ１２０までの処理については、図１－１１と共通であるため図示を省略している。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、クレジットカード会社サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

Ｃ１４０：ＮＯまたはＣ１７０の後、制御部１１は、当月確定請求情報送信条件が成立しているか否かを判定する（Ｃ２２５）。
当月確定請求情報送信条件とは、後述する当月確定請求情報を送信する条件であり、限定ではなく例として、「クレジットカード決済における締め日（締め日時）、限定ではなく例として月末日の翌営業日（翌営業日の特定の時刻）になったこと」とすることができる。

当月確定請求情報送信条件が成立していないと判定した場合（Ｃ２２５：ＮＯ）、制御部１１は、Ｃ１８０に処理を進める。

一方、当月確定請求情報送信条件が成立したと判定した場合（Ｃ２２５：ＹＥＳ）、制御部１１は、限定ではなく例として、当月の合計決済金額の請求に関する情報（限定ではなく例として、当月商品購入情報等）と、当月度の取引について口座振替を行う口座を選択・設定するための情報とを含む当月確定請求情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ２３０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から当月確定請求情報を受信すると、制御部２１は、受信された当月確定請求情報（またはこれに基づく情報）を表示部２４に表示させる（Ａ２３０）。具体的には、限定ではなく例として、当月商品購入情報（決済月、合計決済金額等）と、クレジットカード会社のｗｅｂページへのリンク情報とを表示部２４に表示させる。

その後、制御部２１は、表示部２４に表示された当月確定請求情報に基づき、入力部を介して、取引別支払い口座設定を行うための入力がなされたか否かを判定する（Ａ２４０）。具体的には、限定ではなく例として、クレジットカード会社のｗｅｂページ（当月の振替を行うクレジットカード取引別の支払い口座の設定ページ）へのリンク情報に対する入力部を介した操作を検知したか否かを判定する。
ここでの「取引別支払い口座設定」とは、取引の一覧（取引の履歴）から取引別に支払い口座を設定することを意味する。

取引別支払い口座設定を行うための入力がなされなかったと判定した場合（Ａ２４０：ＮＯ）、制御部２１は、Ａ１９５に処理を進める。
一方、取引別支払い口座設定を行うための入力がなされたと判定した場合（Ａ２４０：ＹＥＳ）、制御部２１は、限定ではなく例として、当月の取引別の支払い口座の設定ページ（ｗｅｂページ）に移動するための取引別支払い口座設定要求情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ２５０）。

ステップＣ２３０の後、制御部１１は、取引別支払い口座設定要求情報を受信したか否かを判定する（Ｃ２４０）。
取引別支払い口座設定要求情報を受信しなかったと判定した場合（Ｃ２４０：ＮＯ）、制御部１１は、Ｃ１８０に処理を進める。

一方、取引別支払い口座設定要求情報を受信したと判定した場合（Ｃ２４０：ＹＥＳ）、制御部１１は、受信された取引別支払い口座設定要求情報に基づいて、合計決済金額の請求に関連する情報（限定ではなく例として、当月商品購入情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）とを含む取引別支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ２５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から取引別支払い口座設定用情報を受信すると、制御部２１は、受信された取引別支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、今月度支払い口座設定画面）を表示部２４に表示させる（Ａ２６０）。
限定ではなく例として、当月商品購入情報（購入日時、購入金額等）や、クレジットカードに紐づいている銀行口座情報（銀行名、口座番号等）、支払い口座を設定するために必要な他の情報（第１アイコン、第２アイコン等）等の情報を含む今月度支払い口座設定画面を表示部２４に表示させるなどすることができる。

その後、制御部２１は、入力部を介したユーザによる取引別に支払い口座を選択する入力を受け付ける（Ａ２７０）。この場合、限定ではなく例として、端末２０Ａの表示部２４に表示された取引別に、第１アイコンがユーザＡ．Ａによって操作（限定ではなく例として、タップ）された後、第２アイコンがユーザＡ．Ａによって操作（限定ではなく例として、タップ）されると、制御部２１は、取引毎に支払い口座として選択された銀行口座の情報を含む取引別支払い口座選択情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ２８０）。

通信Ｉ／Ｆ１４によって端末２０Ａから取引別支払い口座選択情報を受信すると、制御部１１は、受信された取引別支払い口座選択情報に基づいて、取引別支払い口座設定処理を行う（Ｃ２６０）。具体的には、限定ではなく例として、対象となる契約者（この例ではユーザＡ．Ａ）の契約者ＩＤが記憶されたユーザ管理データのうち、支払い口座設定データに含まれる各々の取引ＩＤそれぞれについて、受信した取引別支払い口座選択情報から特定される支払い口座に対応する口座ＩＤを、支払い口座ＩＤに記憶させる。

その後、制御部１１は、取引別の支払い口座の設定が完了したことを報知するための取引別支払い口座設定完了情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信し（Ｃ２７０）、Ｃ１８０に処理を進める。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から取引別支払い口座設定完了情報を受信すると、制御部２１は、受信された取引別支払い口座設定完了情報（またはこれに基づく情報）（限定ではなく例として、今月度支払い口座設定完了画面）を表示部２４に表示させ（Ａ２９０）、Ａ１９５に処理を進める。
限定ではなく例として、当月商品購入情報や、支払い口座情報（支払い口座としていずれかの銀行口座が設定されたことを報知する情報等）などの情報を含む今月度支払い口座設定完了画面を表示部２４に表示させるなどすることができる。

＜第２実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザにより、後払いで購入された商品またはサービスの購入履歴に関する情報を含む商品購入情報を受信し、受信した商品購入情報と、自己の端末２０のユーザの登録銀行口座情報とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの購入履歴を端末のユーザに確認させることができるとともに、その支払いをいずれの口座から行うかをユーザに選択させることができる。

また、この場合、端末２０が、取引別支払い口座設定完了情報（限定ではなく、購入履歴のうちの少なくとも一部の支払いを第１口座に基づいて支払うことに関する情報の一例）を受信するようにすることができる。
このような構成により得られる実施例の効果の一例として、購入履歴のうちの少なくとも一部の支払いを第１口座情報に関連する第１口座で支払うことを端末のユーザに確認させるとともに、その支払いが第１口座から行われるようにすることができる。

また、本実施例は、端末２０が、自己の端末２０のユーザにより、後払いで購入された商品またはサービスの合計金額に関する情報を受信し、受信した合計金額に関する情報と、自己の端末２０のユーザの登録銀行口座情報とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの合計金額を端末のユーザに確認させることができるとともに、その支払いをいずれの口座から行うかをユーザに選択させることができる。

なお、購入履歴のうちの少なくとも一部の支払いを第１口座に基づいて支払うことに関する情報とは、限定ではなく例として、第１口座が支払い口座として選択されたことを示す情報や、第１口座が支払い口座として設定されたことを示す情報（上記の支払い口座設定完了情報）など、購入履歴のうちの少なくとも一部の支払いを第１口座に基づいて支払うことと何らかの関係性を有する情報である。

また、合計金額に関する情報とは、限定ではなく例として、合計金額そのものの情報や、合計金額を算出するための情報（各々の取引の購入金額等）など、合計金額と何らかの関係性を有する情報である。

＜第２変形例＞
第２実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座を設定するようにすることも可能である。

また、第１変形例で説明した、
（ａ）チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
（ｂ）電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
（ｃ）チャットサービスの機能と電子マネーサービスの機能とを有する複合的（統合的）なアプリケーションを構成する形態
を適用することも可能である。

＜表示画面＞
図２－４は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図２－４左は、メッセージングアプリケーションのトークルーム画面の一例である。
この画面のトーク領域には、ユーザＡ．Ａによる今月度のクレジットカード取引に関する情報（画面では「１０月度ご利用情報」）を含む後述する当月確定請求メッセージ情報がＸカードを送信元として送信され、サーバ６０を介して、端末２０Ａが当月確定請求メッセージ情報を受信したことに基づいて、このＯＡトークルームの画面向かって左側に、Ｘカードのアイコン画像と関連付けて、当月確定請求メッセージ情報が表示されている。

この「当月確定請求メッセージ情報」とは、クレジットカード会社サーバ１０から当月確定請求情報を受信したサーバ６０が、端末２０に送信するメッセージングアプリケーションのメッセージ情報であって、この当月確定請求情報に対応するメッセージ情報である。

当月確定請求メッセージ情報の下部には、支払い口座の設定を行うために操作されるボタンであって、限定ではなく例として、前述したクレジットカード会社のｗｅｂページ（限定ではなく例として、今月度の振替を行うクレジットカード取引別の支払い口座の設定ページ）へのリンクが張られた「今月度の支払い口座の設定はこちら」の文字を含むリンクボタンＢＴ２が設けられている。

この画面において「今月度の支払い口座の設定はこちら」の文字を含むリンクボタンＢＴ２がタップされると、限定ではなく例として、端末２０において電子マネーアプリケーションが起動され、限定ではなく例として、図２－４中央の画面が表示される。

この画面は、電子マネーアプリケーションにおける今月度支払い口座設定画面（本例では「１０月度支払い口座設定画面」）であり、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、図２－１中央の画面と同様の情報が表示されている。

図２－４中央に示される今月度支払い口座設定画面において、限定ではなく例として、クレジットカード取引毎に、上から順に、Ａ銀行に対応する第１アイコンＩＣ１Ａ、Ｂ銀行に対応する第１アイコンＩＣ１Ｂ、Ａ銀行に対応する第１アイコンＩＣ１Ａがタップされた後、第２ボタンＢＴ３がタップされると、限定ではなく例として、図２－４右に示すような今月度支払い口座設定完了画面が、電子マネーアプリケーションにおいて表示される。

この画面は、電子マネーアプリケーションにおける今月度支払い口座設定画面（本例では「１０月度支払い口座設定画面」）であり、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、図２－１右の画面と同様の情報が表示されている。

＜処理＞
本変形例における処理は、限定ではなく例として、図２－２～図２－３の処理を、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に基づいて書き換えることで同様に構成可能であるため、詳細な説明は省略する。

＜第３実施例＞
第３実施例は、支払い口座を設定する手法として、ユーザによる支払い口座の選択とは異なる方法によって支払い口座を設定することを可能にする実施例である。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、限定ではなく例として、支払い口座を設定する手法として、クレジットカード会社から請求された金額（商品毎の決済金額、当月分の合計決済金額等）のうち、一の銀行口座から口座振替を行う振替金額と、他の銀行口座から口座振替を行う振替金額とを、ユーザが任意に入力・指定することによって、支払い口座を設定する方式（以下、適宜「金額入力方式」と称する。）を適用する場合を例示する。なお、これを金額指定方式等と称してもよい。

＜データ構成＞
図３－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶されるユーザ管理データベース１５９の一例であるユーザ管理データベース１５９Ｃのデータ構成例を示す図である。

ユーザ管理データベース１５９Ａと同様に、各々のユーザ管理データには、限定ではなく例として、契約者ＩＤと、取引データと、登録銀行口座データと、支払い口座設定データとが記憶される。しかし、支払い口座設定データのデータ構成が異なっている。
具体的には、ユーザ管理データベース１５９Ｃでは、支払い口座設定データには、限定ではなく例として、振替金額と、支払い口座ＩＤとが関連付けて記憶される。

振替金額には、対応する支払い口座ＩＤについて、この契約者ＩＤのユーザによってこの支払い口座ＩＤの支払い口座から口座振替する金額として指定された金額が記憶される。

支払い口座ＩＤには、登録銀行口座データに記憶された口座ＩＤのうち、この振替金額の振替を行う口座として指定された銀行口座に対応する口座ＩＤが記憶されて設定される。

＜表示画面＞
図３－２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図３－２は、ユーザが金額入力方式を用いて支払い口座を設定する場合の表示画面の一例を示す図である。

図３－２左には、クレジットカード会社のｗｅｂページのうち今月度（本例では１０月度）の支払い口座の設定ページの表示画面（今月度支払い口座設定画面）として、限定ではなく例として、「１０月度支払い口座設定画面」の一例を示している。

今月度支払い口座設定画面のうち当月合計決済金額を表示するための領域には、「ご利用合計金額」の欄（この例では「５０，０００円」）が表示されている。

また、その右のクレジットカードに紐づけられている銀行口座（支払い口座）を表示するための領域には、「支払い口座」の文字と、Ａ銀行に対応する「Ａ銀行」の文字と、Ｂ銀行に対応する「Ｂ銀行」の文字とが表示されている。

また、その右には、支払い口座毎に振替金額を入力する振替金額入力領域が構成されており、この例では、振替金額として、「振替金額」の欄（この例では、ユーザがＡ銀行に対応する振替金額入力領域Ｒ１Ａに「３０，０００」と入力したことに基づいて「３０，０００円」、ユーザがＢ銀行に対応する振替金額入力領域Ｒ１Ｂに「２０，０００」と入力したことに基づいて「２０，０００円」）が表示されている。
つまり、この例では、ユーザが、Ａ銀行の銀行口座から「３０，０００円」の口座振替を行い、Ｂ銀行の銀行口座から「２０，０００円」の口座振替を行うことを選択したことを示している。
また、その他には、図２－１中央の画面と同様の情報が表示されている。

図３－２左に示される１０月度支払い口座設定画面において、各銀行の支払い口座に対応する振替金額入力領域に振替金額（本例では、Ａ銀行に対応する「３０，０００円」、Ｂ銀行に対応する「２０，０００円」）が入力された後、第２アイコンＩＣ２がタップされると、限定ではなく例として、図３－２右に示すような、クレジットカード会社のｗｅｂページのうち今月度の支払い口座の設定が完了したことを報知するページの画面（今月度支払い口座設定完了画面）が表示される。

また、その下には、支払い口座を表示するための領域が構成されており、この例では、「支払い口座」の文字と、Ａ銀行に対応する「Ａ銀行」の文字と、Ｂ銀行に対応する「Ｂ銀行」の文字とが表示されている。

また、その右には、設定した支払い口座毎の振替金額を表示するための領域が構成されており、この例では、「振替金額」の文字と、Ａ銀行に対応する振替金額として「３０，０００円」の文字と、Ｂ銀行に対応する振替金額として「２０，０００円」の文字とが表示されている。

なお、この例では、当月合計決済金額をもとに、ユーザが振替金額を自身で計算して入力する表示画面・ユーザインタフェース（ＵＩ）としているが、これに限定されない。
詳細は後述するが、（Ａ）振替金額固定方式、（Ｂ）割合設定方式、等の方式で、振替金額が設定されるような表示画面・ＵＩとすることも可能である。

＜処理＞
図３－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図３－３は、第２実施例のフローチャートのうちの図２－３に対応する部分を示したものである。

Ａ２３０の後、制御部２１は、表示部２４に表示された当月確定請求情報に基づき、入力部を介して、金額入力方式で支払い口座設定を行うための入力がなされたか否かを判定する（Ａ３４０）。

金額入力方式で支払い口座設定を行うための入力がなされなかったと判定した場合（Ａ３４０：ＮＯ）、制御部２１は、Ａ１９５に処理を進める。
一方、金額入力方式で支払い口座設定を行うための入力がなされたと判定した場合（Ａ３４０：ＹＥＳ）、制御部２１は、限定ではなく例として、金額入力方式による支払い口座の設定ページ（ｗｅｂページ）に移動するための金額入力方式支払い口座設定要求情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ３５０）。

ステップＣ２３０の後、制御部１１は、金額入力方式支払い口座設定要求情報を受信したか否かを判定する（Ｃ３４０）。受信しなかったと判定した場合（Ｃ３４０：ＮＯ）、制御部１１は、Ｃ１８０に処理を進める。

一方、金額入力方式支払い口座設定要求情報を受信したと判定した場合（Ｃ３４０：ＹＥＳ）、制御部１１は、金額入力方式支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ３５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から金額入力方式支払い口座設定用情報を受信すると、制御部２１は、受信された金額入力方式支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、今月度支払い口座設定画面）を表示部２４に表示させる（Ａ３６０）。

その後、制御部２１は、入力部を介したユーザによる登録銀行口座毎の振替金額の入力を受け付ける（Ａ３７０）。そして、制御部２１は、登録銀行口座毎に入力された振替金額を含む振替金額入力情報を、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０に送信する（Ａ３８０）。

通信Ｉ／Ｆ１４によって端末２０Ａから振替金額入力情報を受信すると、制御部１１は、受信された振替金額入力情報に基づいて、金額入力方式支払い口座設定処理を行う（Ｃ３６０）。具体的には、限定ではなく例として、対象となる契約者（この例ではユーザＡ．Ａ）の契約者ＩＤが記憶されたユーザ管理データの支払い口座設定データに、受信した振替金額入力情報から特定される振替金額を支払い口座ＩＤと関連付けて記憶させる。

その後、制御部１１は、金額入力方式での支払い口座の設定が完了したことを報知するための金額入力方式支払い口座設定完了情報を、通信Ｉ／Ｆ１４によって端末２０に送信し（Ｃ３７０）、Ｃ１８０に処理を進める。

この処理において、Ｃ１９０では、制御部１１は、ユーザ管理データに含まれる支払い口座設定データを参照し、支払い口座ＩＤごとに、関連付けて記憶されている振替金額を振替要求金額とし、その振替要求金額と、その支払い口座ＩＤに関連付けて記憶されている口座振替トークンとを含む口座振替要求情報を、通信Ｉ／Ｆ１４によって、対応する提携銀行サーバＵＲＩをアクセス先として、対応する銀行サーバ５０に通信Ｉ／Ｆ１４によって送信する。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から金額入力方式支払い口座設定完了情報を受信すると、制御部２１は、受信された金額入力方式支払い口座設定完了情報（またはこれに基づく情報）を表示部２４に表示させ（Ａ３９０）、Ａ１９５に処理を進める。

＜第３実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザによって後払いで購入された商品またはサービスの合計金額のうちのユーザによって入力（指定）された振替金額（限定ではなく、第１金額の一例）を、ユーザによって選択された第１銀行口座（第１口座）に基づいて支払うことに関する情報を受信して表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザにより、振替金額が入力されたことに基づき、第１銀行口座が支払い口座として設定されたことを示す支払い口座設定完了情報（限定ではなく、第１情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって後払いで購入された商品またはサービスの合計金額のうちの第１金額を、端末のユーザによって選択された第１口座情報に関連する第１口座で支払うことができる。

また、この場合、端末２０が、自己の端末２０のユーザにより、複数の登録銀行口座情報のうちの第２銀行口座（第２口座）が選択されたことに基づき、第２銀行口座が支払い口座として設定されたことを示す支払い口座設定完了情報（限定ではなく、合計金額のうちの第２金額を第２口座情報に関連する第２口座で支払うことに関する第２情報の一例）を表示部２４に表示するようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによって後払いで購入された商品またはサービスの合計金額のうちの第２金額を、端末のユーザによって選択された第２口座情報に関連する第２口座で支払うことができる。

＜第３変形例＞
第３実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、金額入力方式で支払い口座を設定するようにすることも可能である。

＜処理＞
本変形例における処理は、限定ではなく例として、図３－３の処理を、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に基づいて書き換えることで同様に構成可能であるため、詳細な説明は省略する。

＜第４実施例＞
クレジットカード決済では、口座振替の日にちが決まっている性質上、支払い口座を設定できる期間は有限である。しかしながら、クレジットカード決済を利用して商品やサービスを購入してから、実際に口座振替が行われるまで一定の期間が経過するクレジットカード決済において、ユーザがその期限を忘れてしまう可能性がある。
第４実施例は、支払い口座をユーザが選択可能な時期または日にちに関する情報（期間、期限、期日等の情報を含む。）をユーザに報知する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、限定ではなく例として、クレジットカード決済において支払い口座から振替が行われる日（以下、適宜「振替日」、「引き落とし日」と称する。）より前の日時に、支払い口座を設定できる期限（以下、適宜「支払い口座設定期限」と称する。）が設定される。そして、この支払い口座設定期限までの期間を、支払い口座を設定できる期間（以下、適宜「支払い口座設定可能期間」と称する。）とする。

支払い口座設定期限を「日」で表したものを、適宜「支払い口座設定期日」と称する。限定ではなく例として、毎月２５日が振替日であって、その３日前が支払い口座設定期限の日に設定される場合、毎月２２日が支払い口座設定期日となる。
なお、支払い口座設定期限を「日時」として設定するようにしてもよいし、しなくてもよい。

本実施例では、支払い口座設定期限をユーザに報知する情報を「期限報知情報」と称する。
「期限報知情報」は、支払い口座設定期限と何らかの関係性を有する情報であればよく、限定ではなく例として、以下の少なくともいずれか１つの情報がこれに含まれる。
・支払い口座設定期限を直接的に報知する情報（限定ではなく例として、後述する「支払い口座設定期限情報」）
・支払い口座設定期限を間接的に報知する情報（限定ではなく例として、後述する「支払い口座設定残り期間情報」）

「支払い口座設定期限情報」とは、支払い口座設定期限そのものを報知する情報であり、限定ではなく例として、「Ｘ月Ｙ日まで設定可能」の文字や「設定期限：Ｘ月Ｙ日」の文字等の情報が含まれる。

「支払い口座設定残り期間情報」とは、支払い口座設定期限までの残り期間を報知する情報であり、限定ではなく例として、支払い口座設定期限までの残り時間そのものの情報等がこれに含まれる。

なお、支払い口座設定残り期間情報には、限定ではなく例として、支払い口座設定期限までの残り期間（残り時間）を画像等によって示唆する情報（以下、「支払い口座設定残り期間示唆情報」と称する。）を含めることができる。

支払い口座設定残り期間示唆情報は、限定ではなく例として、支払い口座設定期限までの残り期間（残り時間）に基づいて、限定ではなく例として、以下のように表示態様を異ならせて端末２０の表示部２４に表示させるようにすることができる。
・支払い口座設定期限までの残り期間（残り時間）が所定期間（所定時間）以上ある場合（限定ではなく例として、一週間以上ある場合）：第１表示態様（限定ではなく例として、丸型のアイコンを表示、第１アイコンの周りに青色の枠を表示、等）
・支払い口座設定期限までの残り期間（残り時間）が所定期間（所定時間）以上ない場合（限定ではなく例として、一週間以内の場合）：第２表示態様（限定ではなく例として、三角形型のアイコンを表示、第１アイコンの周りに黄色の枠を表示、等）

本実施例では、期限報知情報が表示されるタイミングは、限定ではなく例として、以下の少なくともいずれか１つのタイミングがこれに含まれる。
・端末２０で請求情報や当月確定請求情報が表示されたタイミング（限定ではなく例として、請求情報や当月確定請求情報に関連する受信Ｅメール画面が表示されたタイミング）
・端末２０で支払い口座設定用情報や取引別支払い口座設定用情報が表示されたタイミング（限定ではなく例として、支払い口座設定画面や今月度支払い口座設定画面が表示されたタイミング）
以下では、期限報知情報が表示されるタイミングを、端末２０で今月度支払い口座設定画面が表示されたタイミングとする場合を例示する。

また、本実施例では、限定ではなく例として、支払い口座設定期限を超過したことを報知（示唆）する情報を「期限超過報知情報」と称する。この期限超過報知情報は、支払い口座設定期限と何らかの関係性を有する情報であって、支払い口座設定期限を超過したことを報知（示唆）する情報であり、限定ではなく例として、以下の少なくともいずれか１つの情報がこれに含まれる。
・支払い口座設定期限を超過したこと報知する情報（限定ではなく例として、後述する「支払い口座設定期限超過情報」）
・支払い口座設定期限までの残り期間がない（超過したこと）を報知する情報（限定ではなく例として、後述する「支払い口座設定残り期間超過情報」）

「支払い口座設定期限超過情報」とは、支払い口座設定期限を超過したことを直接的に報知する情報であり、具体的には、「Ｘ月Ｙ日で設定期間終了」の文字や「設定期限：Ｘ月Ｙ日を過ぎました。」の文字等が含まれる。

「支払い口座設定残り期間超過情報」は、期限超過（期限徒過）によって支払い口座設定期限までの残り期間がないことを報知する情報である。
支払い口座設定残り期間超過情報には、限定ではなく例として、支払い口座設定の残り期間がないことを画像等によって示唆する情報（以下、「支払い口座設定残り期間超過示唆情報」と称する。）を含めることができる。

支払い口座設定残り期間超過示唆情報は、限定ではなく例として、以下の表示態様で端末２０の表示部２４に表示させることができる。
・支払い口座設定期限までの残り期間がない場合：第３表示態様（限定ではなく例として、バツ型（×）のアイコンを表示、第１アイコンの周りに赤色の枠を表示、等）

本実施例では、支払い口座設定用情報には、限定ではなく例として、期限報知情報を含む支払い口座設定用情報と、期限超過報知情報を含む支払い口座設定用情報とが含まれる。
具体的には、期限報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「Ｘ月Ｙ日まで設定可能」の文字が含まれる支払い口座設定画面であり、期限超過報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「Ｘ月Ｙ日で設定期間終了」の文字が含まれる支払い口座設定画面である。

また、本実施例では、取引別支払い口座設定用情報には、限定ではなく例として、期限報知情報を含む取引別支払い口座設定用情報と、期限超過報知情報を含む取引別支払い口座設定用情報とが含まれる。
具体的には、期限報知情報を含む取引別支払い口座設定用情報とは、限定ではなく例として、「Ｘ月Ｙ日まで設定可能」の文字が含まれる今月度支払い口座設定画面であり、期限超過報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「Ｘ月Ｙ日で設定期間終了」の文字が含まれる今月度支払い口座設定画面である。

＜データ構成＞
図４－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶される支払い口座設定用情報種別判定データのデータ構成例を示す図である。
支払い口座設定用情報種別判定データには、限定ではなく例として、現在の計時情報（現在の日時）が支払い口座設定期限以内であるか否かの判定結果と、支払い口座設定用情報の種別とが関連付けて記憶される。

現在の計時情報が支払い口座設定期限以内であるか否かは、クレジットカード会社サーバ１０の制御部１１が、時計部１９から出力される計時情報に基づいて判定するようにすることができる。現在の計時情報が支払い口座設定期限以内である場合、判定結果は「ＹＥＳ」となり、現在の計時情報が支払い口座設定期限以内ではない場合、判定結果は「ＮＯ」となる。

支払い口座設定用情報の種別は、支払い口座設定用情報の種別であり、限定ではなく例として、期限報知情報を含む支払い口座設定用情報と、期限超過報知情報を含む支払い口座設定用情報とがこれに含まれる。このデータでは、判定結果が「ＹＥＳ」である場合、支払い口座設定用情報の種別は、期限報知情報を含む支払い口座設定用情報となり、判定結果が「ＮＯ」である場合、支払い口座設定用情報の種別は、期限超過報知情報を含む支払い口座設定用情報となることが定められている。

図４－２は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶される取引別支払い口座設定用情報種別判定データのデータ構成例を示す図である。
取引別支払い口座設定用情報種別判定データには、限定ではなく例として、現在の計時情報が支払い口座設定期限以内であるか否かの判定結果と、取引別支払い口座設定用情報の種別とが関連付けて記憶される。

取引別支払い口座設定用情報の種別は、取引別支払い口座設定用情報の種別であり、限定ではなく例として、期限報知情報を含む取引別支払い口座設定用情報と、期限超過報知情報を含む取引別支払い口座設定用情報とがこれに含まれる。このデータでは、判定結果が「ＹＥＳ」である場合、取引別支払い口座設定用情報の種別は、期限報知情報を含む取引別支払い口座設定用情報となり、判定結果が「ＮＯ」である場合、支払い口座設定用情報の種別は、期限超過報知情報を含む取引別支払い口座設定用情報となることが定められている。

＜表示画面＞
図４－３は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。図４－３は、支払い口座設定期限情報が表示される場合の表示画面の一例を示す図である。

図４－３には、クレジットカード会社のｗｅｂページのうち今月度の支払い口座の設定ページの表示画面（今月度支払い口座設定画面）（限定ではなく例として、今月度支払い口座設定画面のうち「１０月度支払い口座設定画面」）の一例を示している。

今月度支払い口座設定画面には、支払い口座設定期限情報を表示するための支払い口座設定期限情報領域Ｒ２が構成されており、この例では、支払い口座設定期限情報として、「１１月２２日まで設定可能」の文字が表示されている。
また、その他には、図２－１中央の画面と同様の情報が表示されている。

図４－４は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。図４－４は、支払い口座設定期限超過情報が表示される場合の表示画面の一例を示す図である。

図４－４には、クレジットカード会社のｗｅｂページのうち今月度の支払い口座の設定ページの表示画面（今月度支払い口座設定画面）（限定ではなく例として、今月度支払い口座設定画面のうち「１０月度支払い口座設定画面」）の一例を示している。

今月度支払い口座設定画面には、支払い口座設定期限超過情報を表示するための支払い口座設定期限超過情報表示領域Ｒ３が構成されており、この例では、支払い口座設定期限超過情報として、「１１月２２日で設定期間終了」の文字が表示されている。
また、その他には、図２－１中央の画面と同様の情報が表示されている。

＜処理＞
本実施例の処理は、限定ではなく例として、図１－１１、図２－２、図２－３に基づいて構成することができる。
なお、Ｃ１５０およびＡ１６０、並びにＣ２５０およびＡ２６０以外のステップについては、図１－１１、図２－２、図２－３と同様であるため、説明を省略する。

Ｃ１４０でＹＥＳと判定された場合、制御部１１は、支払い口座設定用情報種別判定データ（図４－１参照）に基づいて、端末２０Ａに送信する支払い口座設定用情報の種別を判定する。そして、制御部１１は、判定した種別の支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ１５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０からいずれかの種別の支払い口座設定用情報を受信すると、制御部２１は、受信された種別の支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、期限報知情報または期限超過報知情報を含む支払い口座設定画面）を表示部２４に表示させる（Ａ１６０）。

同様に、Ｃ２４０でＹＥＳと判定された場合、制御部１１は、取引別支払い口座設定用情報種別判定データ（図４－２参照）に基づいて、端末２０Ａに送信する取引別支払い口座設定用情報の種別を判定する。そして、制御部１１は、判定した種別の取引別支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０からいずれかの種別の取引別支払い口座設定用情報を受信すると、制御部２１は、受信された種別の取引別支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、期限報知情報または期限超過報知情報を含む今月度支払い口座設定画面）を表示部２４に表示させる（Ａ２６０）。

＜第４実施例の効果＞
本実施例は、端末２０が、請求情報のうちの一の請求情報（限定ではなく、第１購入情報の一例）に対して、複数の登録銀行口座情報のうちから支払い口座とする口座情報をユーザが選択可能な時期または日にちに関する情報（限定ではなく、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることに関する第３情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、購入情報のうちの第１購入情報に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることや、口座情報を選択することができる時期や日にちなどの情報を、端末のユーザに報知することができる。

また、この場合、上記の第３情報は、期限報知情報（限定ではなく、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な日にちに関する情報の一例）を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な日にちに関する情報を、端末のユーザに報知することができる。

また、この場合、支払い口座をユーザが選択可能な時期または日にちに関する情報（第３情報）は、支払い口座設定期限までの残り期間がない場合、支払い口座設定期限までの残り期間がある場合とは異なる表示態様で端末２０の表示部２４に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な時期または日にちではない場合、そのことを端末のユーザに確実に認識させることができる。

＜第４変形例＞
第４実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座設定期限等の情報をユーザに報知するようにすることも可能である。

＜処理＞
本変形例における処理は、限定ではなく例として、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に基づいて同様に構成可能であるため、詳細な説明は省略する。

＜第５実施例＞
上記の実施例では、クレジットカード決済に基づく、取引別の請求情報や、ひと月分の当月確定請求情報等が、クレジットカード会社サーバ１０から端末２０に送信される例を示した。
第５実施例は、請求情報や当月確定請求情報とは異なる支払い口座設定リマインド情報が、クレジットカード会社サーバ１０から端末２０に送信されることを可能にする実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、支払い口座の設定や変更をユーザに思い出させること、再確認させることを「支払い口座設定リマインド」と称し、この支払い口座設定リマインドに関連する情報を「支払い口座設定リマインド情報」と称する。この支払い口座設定リマインド情報には、支払い口座を設定するために用いられる各種の情報（限定ではなく例として、前述した支払い口座設定ページへのリンク情報等）を含めることができる。

なお、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）や、クレジットカード会社サーバ１０が店舗端末４０に一時的に支払った決済金額の請求に係る情報（限定ではなく例として、商品購入情報、レシート情報等）、当月分のクレジットカード決済の請求に関する当月商品購入情報（限定ではなく例として、決済月情報、合計決済金額情報、取引別購入日時、取引別購入金額、取引別店舗等の情報を含む。）等の情報を支払い口座設定リマインド情報に含めてもよいし、含めなくてもよい。

本実施例では、クレジットカード会社サーバ１０が、支払い口座設定リマインドを行うか否かを判定する処理（以下、「支払い口座設定リマインド判定処理」と称する。）を行う場合を例示する。
具体的には、本実施例では、クレジットカード会社サーバ１０の制御部１１が、記憶部１５に記憶済みの各種の情報を取得し、取得した情報に基づいて、後述する支払い口座設定リマインド条件の成否を判定する。そして、支払い口座設定リマインド条件が成立した場合、支払い口座設定リマインド情報を送信することに決定し、支払い口座設定リマインド条件が成立しなかった場合、支払い口座設定リマインド情報を送信しないことに決定する。

＜データ構成＞
図５－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶される支払い口座設定リマインド条件データのデータ構成例を示す図である。
支払い口座設定リマインド条件データには、限定ではなく例として、支払い口座設定リマインド条件の番号（Ｎｏ）と、この番号に対応する支払い口座設定リマインド条件とが関連付けて記憶されている。

なお、このデータはあくまでも一例に過ぎず、これに限定されるわけではない。
上記の全ての情報を関連付けて記憶させる必要はなく、一部の情報を記憶させないようにしてもよい。
また、支払い口座設定リマインド条件の成否の判定を上記のデータを参照することによって実現するのではなく、プログラムによって実現してもよい。
これは、他の実施例で説明するデータについても同様である。

以下、それぞれの支払い口座設定リマインド条件、および、その判定方法について詳細に説明する。

＜Ｎｏ「ＳＰ０１」＞
Ｎｏ「ＳＰ０１」には、支払い口座設定リマインド条件として「設定された時間間隔の時間が経過した、または設定された日時になった」が定められている。
「設定された時間間隔」は、限定でなく例として、端末２０側またはクレジットカード会社サーバ１０側であらかじめ任意の時間間隔を設定可能とすることができる。
限定ではなく例として、「毎週日曜日の朝１０時」等のタイミングでリマインドが行われるように条件を設定することができる。これは、週末である日曜日は比較的時間に余裕のある可能性があるためである。

なお、この他にも、限定ではなく例として、「毎月３日の朝１０時（クレジットカード決済における締め日の３日後の特定の時刻）」にリマインドが行われるように条件を設定するなどしてもよいし、しなくてもよい。

この支払い口座設定リマインド条件の判定では、限定でなく例として、クレジットカード会社サーバ１０が、時計部１９から出力される計時情報に基づいて、条件が成立したか否かを判定するようにすることができる。

＜Ｎｏ「ＳＰ０２」＞
Ｎｏ「ＳＰ０２」には、支払い口座設定リマインド条件として「支払い口座の設定，変更がされていない状態で設定時間が経過した」が定められている。
「設定時間」は、限定でなく例として、端末２０側またはクレジットカード会社サーバ１０側であらかじめ任意の設定時間を設定可能とすることができる。

「支払い口座の設定，変更がされていない状態」には、「支払い口座の設定がされていない状態」と、「支払い口座の変更がされていない状態」とが含まれる。

「支払い口座の設定がされていない状態」とは、クレジットカード決済以降に支払い口座の設定が一度もされていない状態である。
限定ではなく例として、支払い口座設定画面や今月度支払い口座設定画面の第１アイコンを選択した後に、その情報を保存・決定するための第２アイコンが操作されていない状態や、ユーザが端末２０に表示される請求情報や当月確定請求情報を閲覧していない状態等がこれに含まれる。

また、「支払い口座の変更がされていない状態」とは、支払い口座が設定された後、支払い口座の変更が一度もされていない状態である。
限定ではなく例として、クレジットカード決済における支払い口座が、一の銀行口座（限定ではなく例として、Ａ銀行の銀行口座）に初期設定される構成が採用される場合（この場合の初期設定される銀行口座を以下、適宜「初期支払い口座」と称する。）、いずれのクレジットカード決済も支払い口座が初期支払い口座のまま変更されていない状態や、クレジットカード決済における支払い口座が、いずれかの銀行口座に自動設定される構成が採用される場合（この方式を、以下、適宜「支払い口座自動設定方式」と称する。）、いずれのクレジットカード決済も支払い口座自動設定方式で設定された支払い口座のまま変更されていない状態等がこれに含まれる。

限定ではなく例として、「当月確定請求情報が送信されてから第２アイコンが操作されていない状態で設定時間（限定ではなく例として、支払い口座設定期日までの日数が残り１日となるまでの日数）が経過した」等の条件を設定することができる。これは、支払い口座設定期日が近くなっているにも関わらず、支払い口座の設定をユーザが失念している可能性があるため、支払い口座設定リマインドを行うことを意味する。

この支払い口座設定リマインド条件の判定では、限定でなく例として、クレジットカード会社サーバ１０が、ユーザからの第２アイコンへの入力を受け付けたことに基づいて制御部２１から送信される支払い口座設定選択情報や取引別支払い口座設定選択情報を受信したことに関する情報（限定ではなく例として、その受信履歴等の情報）と、時計部１９から出力される時計情報（計時情報）とを取得して、これらの情報に基づいて、条件の成否を判定するようにすることができる。

＜Ｎｏ「ＳＰ０３」＞
Ｎｏ「ＳＰ０３」には、支払い口座設定リマインド条件として「クレジットカード決済の取引数が設定数を超えた」が定められている。
「設定数」は、限定でなく例として、端末２０側またはクレジットカード会社サーバ１０側であらかじめ任意の数を設定可能とすることができる。
限定ではなく例として、取引数がある程度大きい数（限定ではなく例として、「２０件」や「３０件」）である場合、支払い口座の設定をしていないクレジットカード決済が溜まってしまい、後にユーザの負担となる可能性がある。そこで、支払い口座設定リマインドを行うようにすることができる。

この支払い口座設定リマインド条件の判定は、限定でなく例として、クレジットカード会社サーバ１０が、ユーザ管理データに含まれる取引データに基づいて取引数を算出し、算出した取引数が設定数を超えているか否かを判定することによって実現することができる。

＜Ｎｏ「ＳＰ０４」＞
Ｎｏ「ＳＰ０４」には、支払い口座設定リマインド条件として「決済金額が設定金額を超えた」が定められている。
「設定金額」は、限定でなく例として、端末２０側またはクレジットカード会社サーバ１０側であらかじめ任意の金額を設定可能とすることができる。

この条件における「決済金額」は、限定ではなく例として、当月度の合計決済金額とすることができる。
なお、これとは異なり、この条件における「決済金額」を、クレジットカード決済毎（取引毎）の決済金額としてもよいし、しなくてもよい。

限定ではなく例として、決済金額がある程度大きい金額（限定ではなく例として、「５万円」や「１０万円」等）である場合、引き落としを依頼する銀行口座をユーザが慎重に決めたいと考えるような場合が想定される。そこで、支払い口座設定リマインドを行うようにすることができる。

この支払い口座設定リマインド条件の判定は、限定でなく例として、クレジットカード会社サーバ１０が、ユーザ管理データに含まれる取引データに基づいて決済金額を算出し、算出した決済金額が設定金額を超えているか否かを判定することによって実現することができる。

＜処理＞
図５－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、図１－１１、図２－２、図２－３に示したＡ２９０およびＣ２７０までの処理と、Ａ１９５およびＣ１８０以降の処理とは同様であるため、図示・説明は省略する。

図２－３のＣ２７０の後、制御部１１は、支払い口座設定リマインド条件判定処理を実行する（Ｃ５１０）。
この支払い口座設定リマインド条件判定処理では、制御部１１は、前述した支払い口座設定リマインド条件データに基づいて支払い口座設定リマインド条件の成否を判定する。

支払い口座設定リマインド条件が成立していないと判定した場合（Ｃ５２０：ＮＯ）、制御部１１は、図２－３のＣ１８０に処理を進める。
一方、支払い口座設定リマインド条件が成立していると判定した場合（Ｃ５２０：ＹＥＳ）、制御部１１は、限定ではなく例として、支払い口座設定リマインドに関連する支払い口座設定リマインド情報を、通信Ｉ／Ｆ１４によって端末２０に送信し（Ｃ５３０）、図２－３のＣ１８０に処理を進める。

限定ではなく例として図２－３のＡ２９０の後、制御部２１は、通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定リマインド情報を受信したか否かを判定する（Ａ５３０）。

支払い口座設定リマインド情報を受信しなかったと判定した場合（Ａ５３０：ＮＯ）、制御部２１は、図２－３のＡ１９５に処理を進める。
一方、支払い口座設定リマインド情報を受信したと判定した場合（Ａ５３０：ＹＥＳ）、制御部２１は、受信された支払い口座設定リマインド情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定リマインド画面）を表示部２４に表示させ（Ａ５４０）、図２－３のＡ１９５に処理を進める。

＜第５実施例の効果＞
本実施例は、端末２０が、請求情報のうちの少なくとも一の請求情報（限定ではなく、購入情報の少なくとも一部の一例）に基づく支払い口座設定リマインド情報（限定ではなく、購入情報の少なくとも一部に基づく通知情報の一例）を通信Ｉ／Ｆ２２によって受信することに基づき、支払い口座設定用情報を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に基づく通知情報を通信部によって受信することに基づいて、複数の口座情報を表示部に表示して、端末のユーザに確認させることができる。

また、この場合、支払い口座設定リマインド情報は、設定された時間間隔で端末２０に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に基づく通知情報が設定された時間間隔で端末に送信されるため、複数の口座情報を定期的にユーザに確認させることが可能となる。

また、この場合、支払い口座設定リマインド情報は、請求情報のうちの少なくとも一の請求情報（限定ではなく、購入情報の少なくとも一部の一例）に対して、後払いの締め日（限定ではなく、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な期間または日にちの一例）に基づいて端末２０に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な期間または日にちに基づいて、適切なタイミングで通知情報が端末に送信されるようにすることができる。

また、この場合、支払い口座設定リマインド情報は、後払いの取引数（限定ではなく、購入情報に含まれる決済数の一例）に基づいて端末２０に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報に含まれる決済数に基づいて、適切なタイミングで通知情報が端末に送信されるようにすることができる。

また、この場合、支払い口座設定リマインド情報は、当月度の合計決済金額（限定ではなく、購入情報に基づく合計金額の一例）が設定金額（限定ではなく、設定された金額の一例）よりも大きい場合、端末２０に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報に基づく合計金額がある程度大きいような場合に、通知情報が端末に送信されるようにすることができる。

＜第５変形例＞
第５実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座設定リマインドを行うようにすることも可能である。

＜処理＞
本変形例における処理は、限定ではなく例として、図５－２の処理を、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。

＜第６実施例＞
第６実施例は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択可能にする実施例である。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

上記の実施例では、支払い口座設定画面や取引別支払い口座設定画面の第１アイコン表示領域に、画像情報の一例として、支払い口座を選択するための第１アイコン（限定ではなく例として、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンや、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコン）を表示した。
本実施例では、画像情報の別例として、第３アイコンを表示する。

「第３アイコン」とは、支払い口座設定画面や取引別支払い口座設定画面の第１アイコン表示領域に表示されるアイコンであって、クレジットカード決済におけるクレジットカード会社への支払い方法を選択・設定するためのアイコンである。「クレジットカード決済におけるクレジットカード会社への支払い方法」には、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
（Ａ）分割払い
（Ｂ）リボ払い
（Ｃ）ローン払い

（Ａ）「分割払い」は、クレジットカード会社から請求された金額を一括（１回）で支払わずに、支払い回数を複数回に分けて（指定して）支払う方法の一種である。
本実施例におけるクレジットカード決済の分割払いは、クレジットカード会社からの請求金額のうちユーザが指定した分割回数で割った分割金額を、月に１回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。

（Ｂ）「リボ払い」は、クレジットカード会社から請求された金額を一括（１回）で支払わずに、毎月の支払い金額を一定の金額に指定して、複数回に分けて支払う方法の一種である。
本実施例におけるクレジットカード決済のリボ払いは、クレジットカード会社からの請求金額のうちユーザが指定した毎月の支払い金額を、月に１回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。

（Ｃ）「ローン払い」は、クレジットカード会社から請求された金額を、その場ではユーザの銀行口座から支払わずに、ローン会社（限定ではなく例として、クレジットカード会社に関連するローン会社、クレジットカード会社に関連しないローン会社等）が支払いを行い、後からユーザがそのローン会社に支払いを行う方法の一種である。
本実施例におけるローン払いは、クレジットカード会社からの請求金額をローン会社が代わりに支払ったローン支払い金額を、ローン会社に月に１回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。

本実施例では、「第３アイコン」には、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
（Ａ）分割払いに対応する第３アイコン（限定ではなく例として、「分割払い」の文字を含む第３アイコン）
（Ｂ）リボ払いに対応する第３アイコン（限定ではなく例として、「リボ払い」の文字を含む第３アイコン）
（Ｃ）ローン払いに対応する第３アイコン（限定ではなく例として、「ローン」の文字を含む第３アイコン）

＜表示画面＞
図６－１は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図６－１は、支払い口座設定画面に第３アイコンが表示される場合の表示画面の一例を示す図である。

図６－１には、クレジットカード会社のｗｅｂページのうち支払い口座の設定ページの表示画面（支払い口座設定画面）の一例を示している。

支払い口座設定画面には、第１アイコンおよび第３アイコンを表示するためのアイコン表示領域が構成されており、この例では、「支払い口座，その他」の欄に、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンＩＣ１Ａと、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコンＩＣ１Ｂと、リボ払いに対応する「リボ払い」の文字を含む第３アイコンＩＣ３とが表示されている。
また、その他には、図１－１０中央の画面と同様の情報が表示されている。

図６－１左に示される支払い口座設定画面において、リボ払いに対応する第３アイコンＩＣ３がタップされた後、第２アイコンＩＣ２がタップされると、限定ではなく例として、図６－１中央に示すような、第３アイコンＩＣ３で選択した支払い方法に対応する支払い口座の設定ページの表示画面（以下、適宜「リボ払い支払い口座設定画面」と称する。）が表示される。

リボ払い支払い口座設定画面には、この支払い口座設定画面がいずれの支払い方法に対応しているかの情報を表示するための領域が構成されており、この例では、「リボ払い」の文字が表示されている。
また、その他には、図１－１０中央の画面と同様の情報が表示されている。

図６－１中央に示されるリボ払い支払い口座設定画面において、限定ではなく例として、Ａ銀行に対応する第１アイコンＩＣ１Ａがタップされた後、第２アイコンＩＣ２がタップされると、限定ではなく例として、図６－１右に示すような、クレジットカード会社のｗｅｂページのうちリボ払いの支払い口座の設定が完了したことを報知するページの画面（以下、「リボ払い支払い口座設定完了画面」と称する。）が表示される。

この画面には、リボ払いの支払い口座の設定が完了したことを示す領域が構成されており、この例では、「リボ払いの支払い口座の設定が完了しました。」の文字が表示されている。
また、その他には、図１－１０右の画面と同様の情報が表示されている。

＜処理＞
本実施例における処理は、図１－１１、図２－２、図２－３に示したフローチャートに倣って同様に構成することができる。
なお、図１－１１、図２－２、図２－３に示したフローチャートのうちのＣ１５０およびＡ１６０、並びにＣ２５０およびＡ２６０以外の処理とは同様であるため、説明を省略する。

図２－２のＣ１４０でＹＥＳと判定された場合、制御部１１は、受信された支払い口座設定要求情報に基づいて、決済金額の請求に関連する情報（限定ではなく例として、商品購入情報、レシート情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）と、支払い方法を設定するための情報（限定ではなく例として、各支払い方法に対応した第３アイコン等）と、を含む支払い口座設定用情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ１５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定用情報を受信すると、制御部２１は、受信された支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定画面）を表示部２４に表示させる（Ａ１６０）。
限定ではなく例として、商品購入情報（決済日時、決済店舗、決済金額等）や、クレジットカードに紐づいている銀行口座情報（銀行名、口座番号等）、支払い口座を設定するために必要な他の情報（第１アイコン、第２アイコン等）や、支払い方法を設定するための情報（第３アイコン等）等の情報を含む支払い口座設定画面を表示部２４に表示させるなどすることができる。

また、図２－３のＣ２４０でＹＥＳと判定された場合、制御部１１は、受信された取引別支払い口座設定要求情報に基づいて、合計決済金額の請求に関連する情報（限定ではなく例として、当月商品購入情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）と、支払い方法を設定するための情報（限定ではなく例として、各支払い方法に対応した第３アイコン等）と、を含む取引別支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｃ２５０）。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から取引別支払い口座設定用情報を受信すると、制御部２１は、受信された取引別支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、今月度支払い口座設定画面）を表示部２４に表示させる（Ａ２６０）。
限定ではなく例として、当月商品購入情報（購入日時、購入金額等）や、クレジットカードに紐づいている銀行口座情報（銀行名、口座番号等）、支払い口座を設定するために必要な他の情報（第１アイコン、第２アイコン等）や、支払い方法を設定するための情報（第３アイコン等）等の情報を含む今月度支払い口座設定画面を表示部２４に表示させるなどすることができる。

上記の（Ａ）分割払い、（Ｂ）リボ払い、（Ｃ）ローン払い、等に関する設定は、取引ごとに端末２０に送信される請求情報に基づいて行う（個別の購入情報の画面から行う）ようにしてもよいし、端末２０に送信される当月確定請求情報に基づいて行う（購入情報の履歴の画面から行う）ようにしてもよい。

＜第６実施例の効果＞
本実施例は、端末２０が、少なくとも１つの取引の支払いに対して、ローン支払いを選択・設定するための情報（限定ではなく、ローンで支払うことに関する第４情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、後払いによる購入情報の少なくとも一部の支払いに対して、ローンでの支払いが可能であることを端末のユーザに報知することができる。

また、この場合、ローン払いは、端末２０のユーザによって支払い口座として選択された銀行口座（限定ではなく、第１口座の一例）によって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第１口座によって、ローンによる支払いを可能とすることができる。

なお、ローンで支払うことに関する第４情報とは、限定ではなく例として、ローンで支払うことが可能であることをユーザに通知する情報や、ユーザがローンを申し込むための情報など、ローン支払いと何らかの関係性を有する情報である。

＜第６変形例＞
第６実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、クレジットカード会社への支払い方法を設定するようにすることも可能である。

＜第７実施例＞
上記の実施例では、支払い口座設定画面や取引別支払い口座設定画面に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号等の情報が表示される実施例を示した。
第７実施例は、支払い口座設定画面や取引別支払い口座設定画面に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号とは異なる情報（限定ではなく例として、銀行口座の残高に関連する残高情報）が表示される実施例である。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、銀行口座情報のうち銀行名や口座番号とは異なる情報として、ユーザ（預金者）の銀行口座の残高（以下、適宜「残高」、「銀行口座残高」等と称する。）に関連する情報（以下、適宜「残高情報」と称する。）が含まれる。

＜データ構成＞
図７－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶されるユーザ管理データベース１５９の一例であるユーザ管理データベース１５９Ｈのデータ構成例を示す図である。

ユーザ管理データベース１５９Ａと同様に、各々のユーザ管理データには、限定ではなく例として、契約者ＩＤと、取引データと、登録銀行口座データと、支払い口座設定データとが記憶される。しかし、登録銀行口座データのデータ構成が異なっている。
具体的には、ユーザ管理データベース１５９Ｈでは、支払い口座設定データには、限定ではなく例として、口座ＩＤと、口座振替トークンと、残高照会トークンとが関連付けて記憶される。

残高照会トークンは、この口座ＩＤの銀行口座を管理する提携銀行の銀行サーバ５０によって発行される認証用の情報である。
クレジットカード会社サーバ１０は、あらかじめ銀行サーバ５０によって発行されて銀行サーバ５０から通知された残高照会トークンと、前述した口座振替トークンとに基づいて、この契約者ＩＤのユーザの口座残高の情報を取得する処理を、その銀行サーバ５０との間で行う。
なお、残高照会トークンは、アクセストークン等のように表現してもよい。

なお、１つの口座ＩＤに対して２つ以上のトークン（この例では、１つの口座振替トークンと１つの残高照会トークン）が関連付けられる構成に限らず、１つの口座ＩＤに対して１つの口座トークン（包括的なトークン）が関連付けられる構成としてもよいし、そのようにしなくてもよい。

本実施例では、クレジットカード会社サーバ１０が銀行サーバ５０から残高情報を取得するが、取得された残高情報は、口座ＩＤと関連付けてユーザ管理データに記憶される。記憶された残高情報は、残高情報を取得する都度、最新の情報に更新される。
なお、記憶している残高情報は、その月の口座振替が行われたタイミング等で消去するようにしてもよいし、しなくてもよい。

＜表示画面＞
図７－２は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。図７－２は、支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。

図７－２には、クレジットカード会社のｗｅｂページのうち支払い口座の設定ページの表示画面（支払い口座設定画面）の一例を示している。

クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号、残高等）を表示するための銀行口座情報表示領域が構成されており、この例では、Ａ銀行に対応する銀行名として「Ａ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。また、「Ｂ銀行」に対応する銀行名として「Ｂ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。
また、その他には、図１－１０中央の画面と同様の情報が表示されている。

＜処理＞
図７－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、図１－１１、図１－１２に示したＡ１５０およびＣ１４０までの処理と、Ａ１７０、Ｃ１６０、Ｄ１９０、およびＥ１９０以降の処理とは同様であるため、図示・説明は省略する。

図１－１２のＣ１４０でＹＥＳと判定された後、クレジットカード会社サーバ１０と銀行サーバ５０との間で認証システム認可処理が行われる。
具体的には、制御部１１は、限定ではなく例として、ユーザ管理データベース１５９Ｈのうちの、支払い口座設定要求情報に含まれる取引ＩＤが記憶されているユーザ管理データにおける登録銀行口座データから、口座ＩＤに関連付けられた口座振替トークンと残高照会トークンとを取得する。
また、制御部１１は、提携銀行データ１５５から、このユーザ管理データに含まれる口座ＩＤ（提携銀行ＩＤ）に関連付けられた提携銀行サーバＵＲＩを取得する。そして、制御部１１は、その口座振替トークンと残高照会トークンとを含み、端末２０のユーザの口座に関する情報の照会・参照を要求するための残高照会要求情報（残高参照要求情報）を、通信Ｉ／Ｆ１４によって、その提携銀行サーバＵＲＩをアクセス先として、対応する銀行サーバ５０（Ａ銀行サーバ５０ＡやＢ銀行サーバ５０Ｂ）に送信する（Ｂ８２０）。

Ａ銀行サーバ５０Ａの制御部は、通信Ｉ／Ｆによってクレジットカード会社サーバ１０から残高照会要求情報を受信すると、記憶部に記憶された口座管理データベース（不図示）のうちの、残高照会要求情報に含まれる残高照会トークンと関連付けられた口座管理データ（不図示）から、限定ではなく例として、店番号、口座種別、口座番号、残高情報および取引履歴、ならびに姓および名等の情報を取得する。そして、これらの情報のうち少なくとも残高情報を含む銀行口座情報を、通信Ｉ／Ｆによって、クレジットカード会社サーバ１０に送信し（Ｄ８３０）、図１－１２のＤ１９０に処理を進める。これにより、クレジットカード会社サーバ１０とＡ銀行サーバ５０Ａとの間で行われる認証システム認可処理が完了する。

また、Ｂ銀行サーバ５０Ｂの制御部は、通信Ｉ／Ｆによってクレジットカード会社サーバ１０から残高照会要求情報を受信すると、Ａ銀行サーバ５０Ａの場合と同様に、銀行口座情報を、通信Ｉ／Ｆによって、クレジットカード会社サーバ１０に送信し（Ｅ８３０）、図１－１２のＥ１９０に処理を進める。これにより、クレジットカード会社サーバ１０とＢ銀行サーバ５０Ｂとの間で行われる認証システム認可処理が完了する。

通信Ｉ／Ｆ１４によって銀行サーバ５０（Ａ銀行サーバ５０Ａ、Ｂ銀行サーバ５０Ｂ）から残高情報を含む口座情報を受信すると、制御部１１は、受信された口座情報に基づいて、決済金額の請求に関連する情報（限定ではなく例として、商品購入情報、レシート情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号、残高情報等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）とを含む支払い口座設定用情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信し（Ｃ１５０）、図１－１２のＣ１６０に処理を進める。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定用情報を受信すると、制御部２１は、受信された支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定画面）を表示部２４に表示させ（Ａ１６０）、図１－１２のＡ１７０に処理を進める。
限定ではなく例として、商品購入情報（決済日時、決済店舗、決済金額等）や、クレジットカードに紐づいている銀行口座情報（銀行名、口座番号、残高情報等）、支払い口座を設定するために必要な他の情報（第１アイコン、第２アイコン等）等の情報を含む支払い口座設定画面を表示部２４に表示させるなどすることができる。

なお、端末２０が、残高情報に加えて、第６実施例で説明した、（Ａ）分割払い、（Ｂ）リボ払い、（Ｃ）ローン払い、などの支払い方法を選択・設定するための画像情報（前述した第３アイコン等）を、支払い口座設定画面や取引別支払い口座設定画面に表示させるようにしてもよいし、しなくてもよい。

＜第７実施例の効果＞
本実施例は、端末２０が、ユーザによって支払い口座として選択された銀行口座の残高情報を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第１口座情報に関連する第１口座の残高をユーザが確認可能となるため、第１口座からの支払いが可能であるかどうかの判断が容易になる。

＜第７変形例＞
第７実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、残高情報を表示するようにすることも可能である。

＜表示画面＞
図７－４は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。図７－４は、端末２０の電子マネーアプリケーションにおける支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。

図７－４には、電子マネーアプリケーションのうち支払い口座の設定ページの表示画面（支払い口座設定画面）の一例を示している。

クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号、残高等）を表示するための銀行口座情報表示領域が構成されており、この例では、Ａ銀行に対応する銀行名として「Ａ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。また、「Ｂ銀行」に対応する銀行名として「Ｂ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。
また、その他には、図１－３１中央の画面と同様の情報が表示されている。

＜処理＞
本変形例における処理は、限定ではなく例として、図７－３の処理を、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。

＜第８実施例＞
第８実施例は、装置（端末またはサーバ）側で支払い口座を決定する（自動で決定する）実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、端末２０またはクレジットカード会社サーバ１０が、支払い口座を決定する処理（以下、「支払い口座決定処理」と称する。）を行う。
ここで、「支払い口座の決定」には、限定ではなく例として、支払い口座設定処理で支払い口座に設定する銀行口座を決めることと、支払い口座に設定する銀行口座の候補を端末２０のユーザに提案（サジェスト）することと、のいずれかを含む概念とすることができる。
前者の場合は、決められた銀行口座が自動的に支払い口座に設定される。
一方、後者の場合は、決められた銀行口座が端末２０のユーザに提案され、その上で、端末２０のユーザが同意した場合には、その銀行口座が支払い口座に設定される。

＜データ構成＞
図８－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶される支払い口座決定用データのデータ構成例を示す図である。
このデータは、限定ではなく例として、前述した端末２０ＡのユーザＡ．Ａについて設定されるデータである。

支払い口座決定用データには、限定ではなく例として、条件の番号（Ｎｏ）と、この番号に対応する口座決定条件と、この条件によって決定される銀行口座（以下、「決定口座」と称する。）とが関連付けて記憶されている。決定口座には、括弧書きで、その決定口座に対応する口座ＩＤを記載している。

なお、このデータはあくまでも一例に過ぎず、これに限定されるわけではない。
上記の全ての情報を関連付けて記憶させる必要はなく、一部の情報を記憶させないようにしてもよい。
また、条件の成否の判定を上記のデータを参照することによって実現するのではなく、プログラムによって実現してもよい。
これは、他の実施例で説明するデータについても同様である。
以下、「口座決定条件」の一例について詳細に説明する。

＜Ｎｏ「ＳＰ１１」＞
Ｎｏ「ＳＰ１１」には、口座決定条件として「購入した商品またはサービスの種別」が定められており、これに関連付けて、複数の商品またはサービスの種別が定められている。この例では、商品の種別として、「食料品」、「衣料品」、「医薬品」などの複数の種別が記憶されている。

また、決定口座（口座ＩＤ）には、それぞれの商品またはサービスの種別に対応して決定されるユーザＡ．Ａの銀行口座（口座ＩＤ）が記憶されている。この例では、「食料品」には「Ａ銀行の銀行口座（ＢＡ００１）」が、「衣料品」には「Ｂ銀行の銀行口座（ＢＢ００１）」が、「医薬品」には「Ａ銀行の銀行口座（ＢＢ００２）」がそれぞれ記憶されている。

なお、処理は複雑になるが、商品またはサービスの種別ではなく、商品またはサービスごとの口座決定条件を設定するようにしてもよいし、しなくてもよい。

＜Ｎｏ「ＳＰ１２」＞
Ｎｏ「ＳＰ１２」には、口座決定条件として「商品またはサービスを購入した店舗の種別」が定められており、これに関連付けて、複数の店舗の種別が設定されている。この例では、店舗の種別として、「スーパーマーケット」、「百貨店」、「レストラン」などの複数の種別が記憶されている。

また、決定口座（口座ＩＤ）には、それぞれの店舗の種別に対応して決定されるユーザＡ．Ａの銀行口座（口座ＩＤ）が記憶されている。この例では、「スーパーマーケット」には「Ａ銀行の銀行口座（ＢＡ００１）」が、「百貨店」には「Ｃ銀行の銀行口座（ＢＣ００１）」が、「レストラン」には「Ｂ銀行の銀行口座（ＢＢ００１）」がそれぞれ記憶されている。

なお、処理は複雑になるが、店舗の種別ではなく、店舗ごとの口座決定条件を設定するようにしてもよいし、しなくてもよい。

＜Ｎｏ「ＳＰ１３」＞
Ｎｏ「ＳＰ１３」には、口座決定条件として「商品またはサービスを購入した購入金額」が定められており、これに関連付けて、複数の購入金額の範囲が設定されている。この例では、購入金額の範囲として、「１０万円未満」、「１０万円以上５０万円未満」、「５０万円以上１００万円未満」などの複数の範囲が記憶されている。

また、決定口座（口座ＩＤ）には、それぞれの購入金額に対応して決定されるユーザＡ．Ａの銀行口座（口座ＩＤ）が記憶されている。この例では、「１０万円未満」には「Ａ銀行の銀行口座（ＢＡ００１）」が、「１０万円以上５０万円未満」には「Ｃ銀行の銀行口座（ＢＣ００１）」が、「５０万円以上１００万円未満」には「Ｃ銀行の銀行口座（ＢＣ００２）」がそれぞれ記憶されている。

なお、この条件における「購入金額」は、１回の取引における購入金額としてもよいし、ひと月分の購入金額を合計した金額としてもよい。

これらの条件のうちの少なくとも１つの条件を適用して、端末２０またはクレジットカード会社サーバ１０が、支払い口座を決定する。

なお、上記の支払い口座決定用データは、端末２０のユーザの入力に基づいて、端末２０の制御部２１が生成して記憶部２８に記憶しておくようにすることができる。
または、端末２０のユーザの入力に基づいて、クレジットカード会社サーバ１０の制御部１１が生成して記憶部１５に記憶しておくようにすることができる。

限定ではなく例として、クレジットカード会社サーバ１０が支払い口座を決定する場合、限定ではなく例として、あらかじめ、端末２０のユーザ（この例ではユーザＡ．Ａ）が、クレジットカード会社のｗｅｂページ等にアクセスして必要事項を入力し、その入力結果に基づいて、クレジットカード会社サーバ１０の制御部１１が、支払い口座決定用データを生成するようにすることができる。

また、別の手法として、クレジットカード会社サーバ１０の制御部１１が、端末２０のユーザ（この例ではユーザＡ．Ａ）のクレジットカード決済の履歴（取引の履歴）、より具体的には、どの種別の商品またはサービスについてはどの銀行口座から引き落とす傾向があるか、どの種別の店舗についてはどの銀行口座から引き落とす傾向があるか、どの程度の金額についてはどの銀行口座から引き落とす傾向があるか、などを分析・推定する処理を行う。そして、制御部１１は、その推定結果に基づいて、支払い口座決定用データを生成するようにすることができる。

なお、端末２０にインストールされるクレジットカード会社のアプリケーションと、端末２０にインストールされる家計簿アプリケーションとを連携させ、家計簿アプリケーションにおけるユーザの家計簿のデータに基づいて、上記の支払い口座決定用データを生成するようにしてもよいし、しなくてもよい。

また、上記の他にも、限定ではなく例として、一の端末２０（そのユーザ）の現在位置の近傍に位置している端末２０（そのユーザ）に基づいて、支払い口座を決定するようにすることもできる。

具体的には、限定ではなく例として、「商品またはサービスを購入したタイミングで近くにいた人が設定された人であった」等の条件に基づいて、支払い口座を決定するようにしてもよい。限定ではなく例として、端末２０の近くに、その端末２０のユーザの家族や友人などの特定の人物が存在する場合、その端末２０のユーザは、それらの人物と一緒に会食やショッピングを行い、クレジットカード決済によって特定の銀行口座から引き落としを行うケースが考えられる。

そこで、端末２０またはクレジットカード会社サーバ１０が、その端末２０の近傍に、登録済みの特定の人物の端末２０が位置しているか否かを判定する。そして、位置していると判定した場合、端末２０のユーザの特定の銀行口座を支払い口座として決定するようにすることができる。

なお、端末２０の近傍に特定の人物の端末２０が位置しているか否かの判定は、限定ではなく例として、端末同士が無線通信を行うシステム、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等によって通信を行うことによって実現可能である。
端末２０が判定を行うのであれば、上記の通信によって、特定の人物の端末２０が近傍に位置しているか否かを判定可能である。
クレジットカード会社サーバ１０が判定を行うのであれば、端末２０が上記の通信結果の情報をクレジットカード会社サーバ１０に送信することで、クレジットカード会社サーバ１０側で判定可能となる。

また、この他にも、各々の端末２０が、自己の端末２０の最新の端末位置の情報をクレジットカード会社サーバ１０に送信する。そして、クレジットカード会社サーバ１０が、各々の端末２０から受信した端末位置の情報に基づいて、特定の人物の端末２０が近傍に位置しているかを判定することができる。

＜処理＞
図８－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
ここでは、クレジットカード会社サーバ１０の制御部１１が、支払い口座を決定する場合の処理を例示する。また、ここでは、支払い口座に設定する銀行口座の候補を端末２０のユーザに提案（サジェスト）する場合の処理を例示する。
なお、図１－１１、図１－１２に示したＡ１３０およびＣ１３０までの処理は同様であるため、図示・説明は省略する。

図１－１１のＣ１２０の後、制御部１１は、支払い口座決定処理を実行する（Ｃ９１０）。具体的には、限定ではなく例として、前述した支払い口座決定用データに基づいて、支払い口座を決定する。

次いで、制御部１１は、支払い口座が定まったか否かを判定し（Ｃ９２０）、定まったと判定した場合（Ｃ９２０：ＹＥＳ）、限定ではなく例として、決定した支払い口座の情報を含む請求情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ９３０）。そして、制御部１１は、図１－１２のＣ１４０に処理を進める。

一方、支払い口座が定まらなかったと判定した場合（Ｃ９２０：ＮＯ）、制御部１１は、図１－１２のＣ１３０に処理を進める。
なお、支払い口座が定まらない場合とは、上記の支払い口座決定用データの条件に当てはまるものがないような場合である。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から請求情報を受信すると、制御部２１は、図１－１２のＡ１３０に処理を進める。
この場合、Ａ１３０では、受信した請求情報が端末２０Ａの表示部２４に表示されるが、この際、決定された支払い口座の情報が併せて表示されることで、支払い口座とする銀行口座がユーザに提案される。
これにより、ユーザは、その銀行口座を支払い口座として設定して問題ないかを検討することができる。

＜第８変形例＞
第８実施例の手法は、第１変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座自動設定方式で支払い口座を設定するようにすることも可能である。

＜処理＞
本変形例における処理は、限定ではなく例として、図８－２の処理を、図１－２４～図１－２５、図１－２８、図１－３０、図１－３２等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。

＜第９実施例＞
第９実施例は、クレジットカードの銀行口座に関連付けられた特典情報をユーザに報知するとともに、その特典情報に対応する特典をユーザが受けられるようにする実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図９－１は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図であり、クレジットカード会社のｗｅｂページに対応する支払い口座設定画面の一例を示している。

この支払い口座設定画面には、クレジットカードに紐づけられたＡ銀行のキャッシュカードを模式化した画像の下に、このＡ銀行の銀行口座から口座振替を行った場合の特典情報として、「Ａ銀行ポイントＹ％還元」の文字を含むキャンペーン画像Ｇ１Ａが表示されている。
また、クレジットカードに紐づけられたＢ銀行のキャッシュカードを模式化した画像の下には、このＢ銀行の銀行口座から口座振替を行った場合の特典情報として、「Ｂ銀行クーポン配布中」の文字を含むキャンペーン画像Ｇ１Ｂが表示されている。
また、その他には、図１－１０中央の画面と同様の情報が表示されている。

＜処理＞
本実施例における処理は、図１－１１、図１－１２に示したフローチャートに倣って同様に構成することができる。
なお、図１－１１、図１－１２に示したフローチャートのうちのＣ１５０およびＡ１６０以外の処理とは同様であるため、説明を省略する。

図１－１２のＣ１４０でＹＥＳと判定された場合、制御部１１は、受信された支払い口座設定要求情報に基づいて、決済金額の請求に関連する情報（限定ではなく例として、商品購入情報、レシート情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）と、クレジットカードに紐づけられた銀行口座の各々に関連付けてユーザが取得可能な特典に関する情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信し（Ｃ１５０）、図１－１２のＣ１６０に処理を進める。

通信Ｉ／Ｆ２２によってクレジットカード会社サーバ１０から支払い口座設定用情報を受信すると、制御部２１は、受信された支払い口座設定用情報（またはこれに基づく情報）（限定ではなく例として、支払い口座設定画面）を表示部２４に表示させ（Ａ１６０）、図１－１２のＡ１７０に処理を進める。

また、口座振替が行われた後、クレジットカード会社サーバ１０は、その口座振替が行われた銀行口座、つまり、ユーザによって支払い口座として選択された銀行口座に対応する特典情報を、端末２０Ａに送信する。そして、端末２０Ａは、受信した特典情報を、表示部２４に表示させることができる。

限定ではなく、図９－１の例において、Ａ銀行の銀行口座を支払い口座とする支払いが行われた場合、Ａ銀行サーバ５０Ａによる口座振替処理が行われた後、クレジットカード会社サーバ１０は、その特典として、ポイント還元処理（限定ではなく例として、Ｙ％のポイントをユーザＡ．Ａに関連付けて記憶させる処理）を行うようにすることができる。
また、Ｂ銀行の銀行口座を支払い口座とする支払いが行われた場合、Ｂ銀行サーバ５０Ｂによる口座振替処理が行われた後、クレジットカード会社サーバ１０は、その特典として、クーポン提供処理（限定ではなく例として、クーポン情報を端末２０Ａに送信する処理）を行うようにすることができる。

＜第９実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザによって支払い口座として選択された銀行口座情報に関連付けられた割引、キャンペーン、クーポン等の情報（限定ではなく、第１口座情報に関連付けられた特典情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、選択された第１口座情報に関連する第１口座により支払いを行うことによって特典を取得可能であることや、取得可能な特典を、端末のユーザが認識できるようにすることができる。

また、この場合、端末２０が、自己の端末２０のユーザによって支払い口座として選択された銀行口座による支払いに基づいて、ユーザが取得した割引、キャンペーン、クーポン等の情報（限定ではなく、端末のユーザに関連付けられた特典情報の一例）を表示部２４に表示するようにすることができる。
このような構成により得られる実施例の効果の一例として、選択された第１口座情報に関連する第１口座による支払いに基づいて端末のユーザが取得した特典を確認させることができる。

＜第９変形例（１）＞
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、クレジットカードに紐づけられた銀行口座に関連付けられた特典情報を表示するようにすることも可能である。

図９－２は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図であり、電子マネーアプリケーションにおける支払い口座設定画面の一例を示している。

この支払い口座設定画面には、クレジットカードに紐づけられたＡ銀行のキャッシュカードを模式化した画像の下に、このＡ銀行の銀行口座から口座振替を行った場合の特典情報として、「Ａ銀行ポイントＹ％還元」の文字を含むキャンペーン画像Ｇ１Ａが表示されている。
また、クレジットカードに紐づけられたＢ銀行のキャッシュカードを模式化した画像の下には、このＢ銀行の銀行口座から口座振替を行った場合の特典情報として、「Ｂ銀行クーポン配布中」の文字を含むキャンペーン画像Ｇ１Ｂが表示されている。
また、その他には、図１－３１中央の画面と同様の情報が表示されている。

＜第９変形例（２）＞
上記の実施例において、新規銀行に関する情報（限定ではなく例として、新規銀行情報）や、その新規銀行に対応する画像情報（限定ではなく例として、新規銀行の口座開設を行う銀行口座を選択するための情報）を表示させるようにしてもよい。
また、新規銀行の口座開設に伴いユーザに付与される特典情報を表示させるようにしてもよい。

「新規銀行情報」とは、クレジットカードに紐づいていない銀行に関する情報、限定ではなく例として、ユーザが銀行口座を開設していない銀行に関する情報である。
限定ではなく例として、新規銀行の銀行名、その新規銀行のキャンペーン情報等を含めることができる。

＜表示画面＞
図９－３は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図であり、クレジットカード会社のｗｅｂページに対応する支払い口座設定画面の一例を示している。

この支払い口座設定画面には、クレジットカードに紐づけられたＡ銀行のキャッシュカードを模式化した画像およびＢ銀行のキャッシュカードを模式化した画像の下に、新規銀行情報（限定ではなく例として、新規銀行の銀行名、その新規銀行のキャンペーン情報等）を表示するための新規銀行情報表示領域が構成されている。この例では、「ＰＲあなたへのおすすめ＞」の文字とともに、新規銀行情報として、「Ｃ銀行ポイントＺ％還元」の文字を含むキャンペーン画像Ｇ２Ｃと、「Ｄ銀行クーポン配布中」の文字を含むキャンペーン画像Ｇ２Ｄとが表示されている。

また、支払い口座設定画面の下部には、新規銀行の口座開設を行う銀行口座を選択するための情報として、「ＰＲ口座開設希望のお客様はこちらをクリック！！」の文字と、Ｃ銀行に対応する「Ｃ銀行」の文字を含むアイコンＩＣ４Ｃと、Ｄ銀行に対応する「Ｄ銀行」の文字を含むアイコンＩＣ４Ｄとが表示されている。
また、その他には、図１－１０中央の画面と同様の情報が表示されている。

図１－１２のＣ１４０でＹＥＳと判定された場合、制御部１１は、受信された支払い口座設定要求情報に基づいて、決済金額の請求に関連する情報（限定ではなく例として、商品購入情報、レシート情報等）と、クレジットカードに紐づいている銀行口座情報（限定ではなく例として、銀行名、口座番号等）と、支払い口座を設定するために必要な他の情報（限定ではなく例として、銀行口座に対応した第１アイコン、第１アイコンを選択した後に保存・決定する第２アイコン等）と、クレジットカードに紐づいておらずユーザが銀行口座を開設していない銀行の情報と、ユーザが銀行口座を開設するための情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信し（Ｃ１５０）、図１－１２のＣ１６０に処理を進める。

＜第９変形例（３）＞
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、新規銀行情報等の情報を表示するようにすることも可能である。

＜表示画面＞
図９－４は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図であり、電子マネーアプリケーションにおける支払い口座設定画面の一例を示している。

この支払い口座設定画面には、クレジットカードに紐づけられたＡ銀行のキャッシュカードを模式化した画像およびＢ銀行のキャッシュカードを模式化した画像の下に、新規銀行情報（限定ではなく例として、新規銀行の銀行名、その新規銀行のキャンペーン情報等等）を表示するための新規銀行情報表示領域が構成されている。この例では、「ＰＲあなたへのおすすめ＞」の文字とともに、新規銀行情報として、「Ｃ銀行ポイントＺ％還元」の文字を含むキャンペーン画像Ｇ２Ｃと、「Ｄ銀行クーポン配布中」の文字を含むキャンペーン画像Ｇ２Ｄとが表示されている。

また、支払い口座設定画面の下部には、新規銀行の口座開設を行う銀行口座を選択するための情報として、「ＰＲ口座開設希望のお客様はこちらをクリック！！」の文字と、Ｃ銀行に対応する「Ｃ銀行」の文字を含むアイコンＩＣ４Ｃと、Ｄ銀行に対応する「Ｄ銀行」の文字を含むアイコンＩＣ４Ｄとが表示されている。
また、その他には、図１－３１中央の画面と同様の情報が表示されている。

＜第１実施例～第９実施例に関連する他の実施例＞
（１）上記の実施例では、合計決済金額のうちの各決済金額（取引別）の口座振替をいずれの銀行口座から行うかを取引ごとに設定する例を示したが、このような形態に限らず、合計決済金額のうちの各決済金額（取引別）の口座振替をいずれの銀行口座から行うかをまとめて設定できるようにしてもよい。

具体的には、限定ではなく例として、今月度支払い口座設定画面の第１アイコン表示領域に、「支払い口座」の文字が表示され、Ａ銀行に対応する「Ａ銀行」の文字を含む第１アイコンと、Ｂ銀行に対応する「Ｂ銀行」の文字を含む第１アイコンと、がクレジットカード取引毎ではなく、今月度の１または２以上のクレジットカード取引に対してまとめて１つずつ（Ａ銀行に対応する第１アイコンと、Ｂ銀行に対応する第１アイコンとが１つずつ）表示されるようにする。
そして、この第１アイコン（限定ではなく例として、Ａ銀行に対応する第１アイコン）がタップされた後、第２アイコンがタップされると、限定ではなく例として、今月度の支払い口座の設定がまとめて行われるようにする。

（２）上記の実施例では、クレジットカード決済におけるクレジットカード会社への支払い方法として、銀行口座から口座振替を行う方法を示したが、このような形態に限らず、銀行口座から口座振替を行う方法とは異なる方法で支払うことを可能としてもよい。
具体的には、限定ではなく例として、クレジットカード決済におけるクレジットカード会社への支払い方法として、電子マネーまたは電子マネーに変換可能なポイントを用いた方法で支払いを行う。この場合、支払い口座設定画面や取引別支払い口座設定画面の第１アイコン表示領域に、電子マネーまたは電子マネーに変換可能なポイントを用いた方法で支払いを行うための第５アイコン（限定ではなく例として、「ｐａｙ払い」の文字を含むアイコン、「ポイント払い」の文字を含むアイコン等）が表示されるようにすることができる。

（３）上記の実施例で説明した金額入力方式の他にも、限定ではなく例として、以下のいずれかの方式によって、支払い口座を設定するようにすることも可能である。
（Ａ）振替金額固定方式
（Ｂ）割合設定方式

（Ａ）「振替金額固定方式」は、限定ではなく例として、一の銀行口座から口座振替を行う振替金額がユーザによって任意に指定されると、残りの振替金額が他の銀行口座から口座振替されるように自動で設定される方式である。
具体的には、限定ではなく例として、合計決済金額が「１０万円」であり、一の銀行口座から口座振替を行う振替金額としてユーザによって「６万円」が指定されると、「６万円」が一の銀行口座から口座振替され、残りの振替金額である「４万円」が他の銀行口座から口座振替されるように設定される。

（Ｂ）「割合設定方式」は、限定ではなく例として、一の銀行口座から口座振替を行う振替金額と、他の銀行口座から口座振替を行う振替金額とが、ユーザによって任意に割合（比率、百分率等）で指定されることによって、支払い口座が自動で設定される方式である。
具体的には、限定ではなく例として、合計決済金額が「１０万円」であり、ユーザによって一の銀行口座から口座振替を行う振替金額と、他の銀行口座から口座振替を行う振替金額との割合が「８：２」に指定されると、合計決済金額の「１０万円」のうち「８万円」が一の銀行口座から口座振替され、残りの振替金額の「２万円」が他の銀行口座から口座振替されるように設定される。

（４）上記の実施例では、クレジットカードの契約者と、このクレジットカードのユーザとが同一である（一対一で紐づいている）例を示したが、このような形態に限らず、クレジットカードの契約者とこのクレジットカードのユーザとが同一でなくても（一対一で紐づいていなくても）よい。

具体的には、クレジットカードの契約者とこのクレジットカードのユーザとが同一でない場合のクレジットカードとして、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
（Ａ）法人クレジットカード
（Ｂ）家族クレジットカード

（Ａ）「法人クレジットカード」とは、限定ではなく例として、このクレジットカードの契約者が法人（限定ではなく例として、会社、個人事業主等）であり、このクレジットカードのユーザがその法人に属する人である場合に利用されるクレジットカードの一種である。
「法人クレジットカード」では、口座振替を行う銀行口座として法人の銀行口座やユーザ個人の銀行口座を設定することができる。
「法人クレジットカード」は、「会社クレジットカード」や、「コーポレートカード」、「ビジネスカード」等と称してもよい。

（Ｂ）「家族クレジットカード」とは、限定ではなく例として、このクレジットカードの契約者と、このクレジットカードのユーザがその契約者の家族（限定ではなく例として、契約者と生計を同一にする配偶者・親・子供（高校生をのぞく１８歳以上）等）である場合に利用されるクレジットカードの一種である。
「家族クレジットカード」では、口座振替を行う銀行口座として契約者の銀行口座を設定することができる。
「家族クレジットカード」は、「ファミリーカード」等と称してもよい。

（５）上記の実施例では、クレジットカード決済における取引に関する情報（請求情報、当月確定請求情報）が、このクレジットカードのユーザの端末２０に送信される例を示したが、このような形態に限らず、クレジットカード決済における取引に関する情報（請求情報、当月確定請求情報）が、このクレジットカードのユーザとは異なる人の端末２０に送信されるようにしてもよい。
具体的には、限定ではなく例として、前述した「法人クレジットカード」や「家族クレジットカード」を利用した場合、これらのクレジットカード決済における取引に関する情報（請求情報、当月確定請求情報）が、上記のようなクレジットカードのユーザとは異なる人の端末２０に送信されるようにすることができる。

限定ではなく例として、「法人クレジットカード」を利用した場合、このクレジットカード決済における取引に関する情報（情報請求情報、当月確定請求情報）が、このクレジットカードのユーザとは異なる人（限定ではなく例として、契約者である会社の事務担当や経理担当等）の端末２０に送信されるようにすることができる。
また、限定ではなく例として、「家族クレジットカード」を利用した場合、このクレジットカード決済における取引に関する情報（請求情報、当月確定請求情報）が、このクレジットカードのユーザとは異なる契約者である人（限定ではなく例として、契約者である親等）の端末２０に送信されるようにすることができる。

これらのクレジットカード決済における取引に関する情報が送信されるタイミングとしては、請求情報や当月確定請求情報が送信されるタイミングの他、限定ではなく例として、これとは異なるタイミングを適用することもできる。
具体的には、法人クレジットカードの場合、限定ではなく例として、「仕事上ではない私的な種別の商品・サービスの購入があったタイミング」等を適用することができる。また、家族クレジットカードの場合、限定ではなく例として、「高額な購入金額の商品・サービスの購入があったタイミング」等を適用することができる。

（６）上記の実施例では、クレジットカード決済におけるクレジットカード会社への支払い方法として「分割払い」の例を示した。ユーザによって「分割払い」の方法が選択（指定）された場合、分割払いの毎月の支払いにおける支払い口座の設定方法として、限定ではなく例として、少なくとも以下のいずれかの方式を適用することができる。
（Ａ）分割払い支払い口座固定方式
（Ｂ）分割払い支払い口座変動方式

（Ａ）「分割払い支払い口座固定方式」とは、ユーザによって最初の支払いにおいて支払い口座が選択される場合、ユーザによって選択された銀行口座が、分割払いの毎月の支払いにおける支払い口座として設定される方式である。
具体的には、ユーザによって３回払いの分割払いが選択され、最初の支払いにおいて銀行口座（限定ではなく例として、Ａ銀行に対応する銀行口座）が支払い口座として選択されると、この銀行口座が分割払いの毎月の支払いにおける支払い口座として設定される。

（Ｂ）「分割払い支払い口座変動方式」とは、ユーザによって毎月の支払いのたびに支払い口座が選択される場合、ユーザによって選択された銀行口座が、分割払いの毎月の支払いにおける支払い口座として設定される方式である。
具体的には、ユーザによって３回払いの分割払いが選択され、毎月の支払いにおいて一の銀行口座（限定ではなく例として、１回目の支払い：Ａ銀行に対応する銀行口座、２回目の支払い：Ｂ銀行に対応する銀行口座、３回目の支払い：Ａ銀行に対応する銀行口座）が支払い口座として選択されると、これらの銀行口座が分割払いの毎月の支払いにおける支払い口座として設定される。

（７）上記の実施例では、支払い口座設定画面や取引別支払い口座設定画面に、クレジットカードに紐づいている銀行口座情報として銀行名や口座番号とは異なる情報（限定ではなく例として、銀行口座の残高に関連する残高情報）が表示される例を示したが、このような形態に限らず、支払い口座設定画面や取引別支払い口座設定画面とは異なる画面に、クレジットカードに紐づいている銀行口座情報として銀行名や口座番号とは異なる情報（限定ではなく例として、銀行口座の残高に関連する残高情報）が表示されてもよい。
具体的には、限定ではなく例として、請求情報や当月確定請求情報に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号とともに、限定ではなく例として、銀行口座の残高に関連する残高情報が表示されるようにしてもよい。

（８）上記の実施例では、ユーザ（預金者）の銀行口座の残高そのものを表示したが、このような形態に限らず、残高と何らかの関係性を有する情報を表示させるようにしてもよい。
具体的には、ユーザ（預金者）の銀行口座の残高に関連する情報として、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
（Ａ）予想残高情報
（Ｂ）残高オブジェクト情報

（Ａ）「予想残高情報」とは、ユーザの銀行口座の残高に関連する情報であって、銀行口座の残高から決済金額を差し引いた場合に予想される残高に関連する情報である。
具体的には、限定ではなく例として、ユーザの銀行口座の残高が１０万円であり、決済金額が４万円である場合、予想残高情報として「６０，０００円」を表示させるようにすることができる。

（Ｂ）「残高オブジェクト情報」とは、ユーザの銀行口座の残高に関連する情報であって、オブジェクト形式等によって残高を表示する情報である。
具体的には、限定ではなく例として、ユーザの給与支給日の残高（限定ではなく例として、３０万円）を１００％とした円グラフや棒グラフ（ゲージ）をオブジェクトとし、最新の銀行口座の残高（限定ではなく例として、１０万円）が、この例では「３３％」の円グラフや棒グラフ（ゲージ）として表示されるようにすることができる。

（９）また、残高の表示に関連して、決済金額が銀行口座の残高を超える場合に、決済金額が銀行口座の残高を超えることをユーザに報知するようにしてもよい。
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えることをユーザに報知する方法として、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
（Ａ）予想残高情報の表示態様を変化させる
（Ｂ）アラート情報を表示させる

（Ａ）の方法では、決済金額が銀行口座の残高を超える場合、予想残高情報の表示態様を変化させることによって、決済金額が銀行口座の残高を超えることをユーザに報知する。
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えない場合は、予想残高情報がデフォルトの第１表示態様（限定ではなく例として、黒文字）で表示される。一方、決済金額が銀行口座の残高を超える場合は、予想残高情報が第１表示態様とは異なる第２表示態様（限定ではなく例として、赤文字）で表示されるようにすることができる。

（Ｂ）の方法では、決済金額が銀行口座の残高を超える場合、アラート情報を表示させることによって、決済金額が銀行口座の残高を超えることをユーザに報知する。
「アラート情報」とは、決済金額が銀行口座の残高を超えることをユーザに報知するための情報であり、限定ではなく例として、請求情報や当月確定請求情報に含めることができる。
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えない場合は、アラート情報は表示されないが、決済金額が銀行口座の残高を超える場合は、アラート情報（限定ではなく例として、「残高が不足しています。」の文字やマーク等）が表示されるようにすることができる。
なお、このアラート情報のみが、請求情報や当月確定請求情報とは異なる情報として端末２０に送信されて表示されるようにしてもよい。

また、上記の実施例において、サーバが、支払い口座として設定された銀行口座の残高情報に基づいて、支払い口座設定リマインドを行うようにしてもよい。
具体的には、サーバが、支払い口座として設定された銀行口座の残高が、その支払い口座からの支払い金額に満たないと判定した場合に、現時点では支払い口座の残高が不足していることを示す残高不足情報や、支払いができないことを示す支払い不可情報を含む支払い口座設定リマインド情報を、端末２０に送信するようにすることができる。

本変形例は、支払い口座設定リマインド情報（限定ではなく、通知情報の一例）は、少なくともユーザによって支払い口座として選択された銀行口座の残高情報（限定ではなく、第１口座の残高の情報の一例）に基づいて端末２０に送信される構成を示している。
このような構成により得られる変形例の効果の一例として、少なくとも第１口座の残高の情報に基づいて、購入情報の少なくとも一部に基づく通知情報が端末に送信されるようにすることができる。

（１０）上記の実施例では、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能にする例を示したが、このような形態に限らず、設定された条件が成立した場合にクレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能にしてもよい。
具体的には、限定ではなく例として、「支払い口座の残高が設定金額を下回った」、「決済金額が支払い口座の残高を超えた」等の条件を設定することができる。
この条件が成立しない場合は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを不可とする。一方、この条件が成立する場合は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能とする。

具体的には、限定ではなく例として、「支払い口座の残高が設定金額（限定ではなく例として、１万円）を下回った」の条件が成立しない場合は、第３アイコンが表示されないが、「支払い口座の残高が設定金額（限定ではなく例として、１万円）を下回った」の条件が成立する場合は、第３アイコンが表示されるようにすることができる。

なお、上記の設定された条件が成立する場合、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能とする手法として、第３アイコンを表示させることに限らず、条件が成立する場合、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能とする手法として、第３アイコンとは異なる情報を表示するようにしてもよい。

具体的には、「第３アイコンとは異なる情報」として、限定ではなく例として、ローン会社のｗｅｂページのリンク情報や広告情報等を表示させるようにしてもよい。このようにすることで、ユーザは、決済金額が支払い口座の残高を超える可能性がある場合に、ローン会社からローンによってお金を借りるなどすることが可能となる。

本変形例は、端末２０が、ユーザによって支払い口座として選択された銀行口座の残高情報に基づいて、ローンに関連する情報を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第１口座情報に関連する第１口座の残高が支払いを行うのに不足しているような場合に、ローンの情報を端末のユーザに報知することができる。

（１１）上記の実施例では、クレジットカードに紐づけられる銀行口座（支払い口座として設定可能な銀行口座）を２つとして説明したが、これを３以上の銀行口座としてもよい。この場合の処理は、上記の実施例と同様に構成することができるため、詳細な説明は省略する。

（１２）複数のクレジットカード取引のうち（複数の購入情報のうち）、その一部または全部のクレジットカード取引（購入情報）に対して、クレジットカードに紐づけられた複数の銀行口座の中から１つの銀行口座を支払い口座として設定するのに限らず、２以上の銀行口座を支払い口座として設定するようにすることも可能である。

限定ではなく例として、Ａ銀行の銀行口座と、Ｂ銀行の銀行口座と、Ｃ銀行の銀行口座との３つの銀行口座をクレジットカードに紐づける場合、あるクレジットカード取引（購入情報）に対して、限定ではなく例として、Ｂ銀行の銀行口座と、Ｃ銀行の銀行口座との２つの銀行口座を支払い口座として設定するなどしてもよい。

この場合は、限定ではなく例として、前述した金額入力方式、（Ａ）振替金額固定方式、（Ｂ）割合設定方式、等の方式に倣って、複数の支払い口座それぞれから口座振替を行う振替金額を、端末２０のユーザによる入力に基づいて設定するようにすることができる。

（１３）上記の実施例において、前述したように、デフォルトの支払い口座を設定するようにすることも可能である。
この場合、複数の銀行口座の中から支払い口座として設定する銀行口座をユーザに選択させるのではなく、デフォルトの支払い口座とは異なる銀行口座から支払いを希望する取引をユーザに選択させるようにしてもよい。
限定ではなく例として、Ａ銀行の銀行口座とＢ銀行の銀行口座とが登録されており、Ａ銀行の銀行口座がデフォルトの支払い口座として設定されている場合、Ｂ銀行の銀行口座から支払いを希望する取引をユーザに選択させるようにする。そして、選択された取引について、支払い口座をＢ銀行の銀行口座に更新するようにすることができる。

＜第１０実施例＞
第１０実施例は、前述した実施例とは異なる手法によって、後払いを実現する実施例である。後払いとしては、前述したように、（１）クレジットカード決済、（２）ツケ払い、のいずれを適用することも可能である。

以下説明する実施例では、前述した（１）クレジットカード決済を適用する場合を例示する。
前述した実施例では、端末２０のユーザに関連するクレジットカードに、複数の銀行口座が紐づけられていた。
それに対し、以下説明する実施例では、端末２０のユーザに関連するクレジットカードに、１つの銀行口座のみが紐づけられる。

以下では、便宜的に、ユーザに関連する銀行口座であって、ユーザに関連するクレジットカードに紐づけられた銀行口座を「メイン銀行口座」と称し、このユーザに関連するクレジットカードに紐づけられていない銀行口座を「サブ銀行口座」と称して説明する。

第１０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、ユーザがクレジットカード決済を行った後、その支払いをサブ銀行口座から行うことを予定している支払い予定金額（限定ではなく、第２金額の一例）等の情報を、所定のサーバが受信する。そして、所定のサーバが、受信した情報に基づいて、サブ銀行口座（限定ではなく、第２口座の一例）からメイン銀行口座（限定ではなく、第１口座の一例）に支払い予定金額（限定ではなく、第２金額の一例）を送金することに関する処理を行う。

第２口座から第１口座に第２金額を送金することに関する処理とは、限定ではなく例として、第２金額を実際に送金する処理や、送金を実現するために第２金額の情報を他の装置に送信する処理など、第２金額の送金と何らかの関係性を有する処理である。この具体例については後述する。

この処理を行う所定のサーバは、限定ではなく例として、金融機関サーバ（限定ではなく例として、銀行サーバ５０）や、資金移動業を営む資金移動業者のサーバ（以下、「資金移動業者サーバ」と称する。）とすることができる。

本実施例では、限定ではなく例として、資金移動業者を、前述した電子マネーサービス事業者（電子マネーアプリケーションの事業者）とする。そして、所定のサーバを、前述した電子マネーサービス事業者のサーバとし、これを前述したサーバ６０とする。

本実施例では、クレジットカード決済において、ユーザがサブ銀行口座から支払いを行いたい取引の情報（購入情報）を選択し、それをサーバ６０に通知する。これを受けて、サーバ６０は、銀行サーバ５０と通信して、そのユーザのサブ銀行口座から、そのユーザのメイン銀行口座（クレジットカードに紐づけられた銀行口座）に購入金額を送金する処理を行う。ここで、本実施例における「送金」とは、限定ではなく例として、サブ銀行口座からの電子マネーのチャージと、メイン銀行口座への出金とが含まれる。
これにより、ユーザにより選択された取引について、実際には、そのユーザのメイン銀行口座から購入金額が引き落とされてクレジットカード会社に支払われるが、ユーザにとっては、あたかもサブ銀行口座からクレジットカード会社への支払いが行われたように見えることになる。
このようにして送金を行うことを「口座間送金」と称する。

本実施例における口座間送金を実現する手法としては、大きく分けて、以下の手法が考えられる。
（１）取引ごとに送金（電子マネー振替・チャージ＆出金）を行う手法
（２）取引ごとに電子マネー振替・チャージを行い、複数の取引についてまとめて出金を行う手法
（３）複数の取引についてまとめて送金（電子マネー振替・チャージ＆出金）を行う手法

また、（３）の手法には、限定ではなく例として、以下の手法が考えられる。
（３－１）取引ごとに送金設定を行い、複数の取引についてまとめて送金を行う手法
（３－２）複数の取引についてまとめて送金設定を行い、複数の取引についてまとめて送金を行う手法

以下、各々の手法を適用する場合について説明する。

＜システム構成＞
本実施例では、システム構成として、限定ではなく例として、図１－１４に示した通信システム１Ｂを適用する。
また、本実施例では、図１－１４で説明したサーバ６０を、電子マネーサービス事業者のサーバとして説明する。

＜データ構成＞
図１０－１は、本実施例においてクレジットカード会社サーバ１０の記憶部１５に記憶されるユーザ管理データベース１５９の一例であるユーザ管理データベース１５９Ｅのデータ構成例を示す図である。
各々のユーザ管理データには、契約者ＩＤと、電子マネーアプリケーションＩＤと、取引データと、第１登録銀行口座データとが記憶される。

電子マネーアプリケーションＩＤには、この契約者ＩＤのユーザの電子マネーアプリケーションにおけるアカウントである。

第１登録銀行口座データには、この契約者ＩＤのユーザのクレジットカードに紐づけられた銀行口座の情報として、１つの銀行口座に関する情報が記憶される。具体的には、限定ではなく例として、１つの口座ＩＤと、この口座ＩＤに対応する口座振替トークンとが関連付けて記憶される。つまり、クレジットカードに紐づけられている銀行口座の数は１つである。

図１０－２は、本実施例においてサーバ６０の記憶部６５に記憶されるアカウント管理データベース６５５の一例であるアカウント管理データベース６５５Ｅのデータ構成例を示す図である。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションＩＤと、電子マネー口座残高と、取引データと、第２登録銀行口座データと、支払い口座設定データとが記憶される。

第２登録銀行口座データには、この電子マネーアプリケーションＩＤのユーザの銀行口座に関する情報として、限定ではなく例として、口座ＩＤと、口座振替トークンと、種別とが関連付けて記憶されている。

口座ＩＤには、このユーザの２以上（複数）の銀行口座の口座ＩＤが記憶される。
口座振替トークンは、この口座ＩＤに対応する口座振替トークンが記憶される。

種別には、この口座ＩＤの銀行口座のメイン／サブの種別であり、メイン銀行口座には「メイン」が、サブ銀行口座には「サブ」がそれぞれ関連付けて記憶される。
具体的には、前述した第１登録銀行口座データに記憶されている口座ＩＤ、つまり、ユーザのクレジットカードに紐づけられた銀行口座をメイン銀行口座とし、これに対応する口座ＩＤには「メイン」が関連付けて記憶される。一方、前述した第１登録銀行口座データに記憶されていない口座ＩＤ、つまり、ユーザのクレジットカードに紐づけられていない銀行口座をサブ銀行とし、これに対応する口座ＩＤには「サブ」が関連付けて記憶される。

支払い口座設定データには、限定ではなく例として、取引ＩＤと、支払い口座ＩＤとが関連付けて記憶される。

なお、クレジットカードに紐づけられた銀行口座はメイン銀行口座であるため、限定ではなく例として、メイン銀行口座を、デフォルトの支払い口座として設定するようにしてもよい。この場合、ユーザによってサブ銀行口座が支払い口座として選択されると、その口座ＩＤで支払い口座ＩＤが更新されるようにすることができる。

＜表示画面＞
図１０－３は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１０－３は、端末２０Ａの電子マネーアプリケーションにおいて支払い口座を設定する場合の表示画面の一例を示す図である。

図１０－３左には、電子マネーアプリケーションにおける支払い口座設定画面が表示されている。
この画面最上部には、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、支払い口座を設定するための情報が表示されている。

具体的には、「支払い口座設定」の文字とともに、登録されているユーザＡ．Ａの銀行口座に関する情報として、クレジットカードに紐づいているメイン銀行口座情報（限定ではなく例として、メイン銀行口座である銀行Ａに対応する銀行名、口座番号等）と、クレジットカードに紐づいていないサブ銀行口座情報（限定ではなく例として、サブ銀行口座である銀行Ｂに対応する銀行名、口座番号等）とを表示するための銀行口座情報表示領域が構成されている。

図１０－３左に示される支払い口座設定画面において、限定ではなく例として、Ｂ銀行に対応する第１アイコンＩＣ１Ｂがタップされた後、第２ボタンＢＴ３がタップされると、限定ではなく例として、図１０－３右に示すような支払い口座設定完了画面が、電子マネーアプリケーションにおいて表示される。

この画面の設定した支払い口座を表示するための領域には、「支払い口座」の文字と、Ｂ銀行に対応する「Ｂ銀行」の文字とが表示されている。
また、その他には、図１－３１右の画面と同様の情報が表示されている。

この例では、上記の画面図は、第１変形例で説明した図１－３１の中央、図１－３１の右の画面図と同様の表示態様・ユーザインタフェース（ＵＩ）となっている。
つまり、本実施例では、サブ銀行口座（上記の例では、Ｂ銀行の銀行口座）から支払い金額は引き落とされず、実際にはメイン銀行口座（上記の例では、Ａ銀行の銀行口座）から支払い金額が引き落とされるのであるが、上記のような表示を行うことにより、あたかもサブ銀行口座から支払い金額が引き落とされるかのようにユーザに見せることができる。つまり、ユーザは口座間送金が行われることを意識する必要はなく、支払い口座を選択すれば済む。

＜処理＞
図１０－４，図１０－５は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理は、前述した（１）の手法を適用する場合の処理の一例である。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、サーバ６０の制御部２１が実行する処理、クレジットカード会社サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理の一例を示している。

ここでは、分かり易いように、ユーザＡ．Ａのメイン銀行口座をＡ銀行の銀行口座（口座ＩＤ：ＢＡ００１）とし、ユーザＡ．Ａのサブ銀行口座をＢ銀行の銀行口座（口座ＩＤ：ＢＢ００１）として説明する。

制御部６１は、通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０から請求情報を受信すると、受信した請求情報（限定ではなく例として、請求情報を含む電子マネーアプリケーションの請求ページ）に基づき、アカウント管理データの取引データを更新する。そして、制御部６１は、送信元をクレジットカード会社のＯＡアカウントとする請求情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ６３０）。

通信Ｉ／Ｆ２２によってサーバ６０から請求情報を受信すると、制御部２１は、Ａ１３０のステップを実行する。

Ｂ６３０の後、制御部６１は、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座設定要求情報を受信したか否かを判定し（Ｂ６４０）、受信したと判定したならば（Ｂ６４０：ＹＥＳ）、支払い口座設定用情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ６５０）。

通信Ｉ／Ｆ２２によってサーバ６０から支払い口座設定用情報を受信すると、制御部２１は、受信した支払い口座設定用情報を表示部２４に表示させる（Ａ６６０）。

その後、制御部２１は、入力部を介して、ユーザによる支払い口座選択入力を受け付ける（Ａ６７０）。
具体的には、この請求情報について、ユーザがサブ銀行口座（Ｂ銀行の銀行口座（口座ＩＤ：ＢＢ００１））から支払うことを希望する場合、サブ銀行口座の選択の入力を受け付ける。そして、制御部２１は、サブ銀行口座が選択された旨を示す支払い口座選択情報を、通信Ｉ／Ｆ２２によってサーバ６０に送信する（Ａ６８０）。

なお、ユーザがメイン銀行口座（Ａ銀行の銀行口座（口座ＩＤ：ＢＡ００１））から支払うことを希望し、メイン銀行口座が選択された場合、制御部２１は、限定ではなく例として、Ａ６８０，Ａ６９０のステップをスキップするようにすることができる。
また、この場合、制御部６１は、Ｂ６６０ａ，Ｂ６７０のステップをスキップするようにすることができる。

通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、銀行サーバ５０（Ａ銀行サーバ５０Ａ、Ｂ銀行サーバ５０Ｂ）との間で、口座間送金処理を実行する（Ｂ６６０ａ）。

図１０－６は、口座間送金処理の流れの一例を示すフローチャートであり、この図では、左側から順に、サーバ６０の制御部６１が実行する処理、Ａ銀行サーバ５０Ａの制御部、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

制御部６１は、限定ではなく例として、端末２０Ａから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、この請求情報に対応する取引ＩＤに関連付けられた支払い口座ＩＤに、ユーザＡ．Ａのサブ銀行口座の口座ＩＤ（この例では、Ｂ銀行の口座ＩＤ：ＢＢ００１）を記憶させる。

そして、制御部６１は、取引データにおけるこの取引ＩＤに対応する購入金額を送金金額とし、送金金額と、対象とするユーザ（この例ではユーザＡ．Ａ）の電子マネーアプリケーションＩＤが記憶されたアカウント管理データの第２登録銀行口座データに含まれる送金元の銀行口座（この例では、Ｂ銀行の銀行口座）の口座ＩＤに関連付けられた口座振替トークンとを含む電子マネー振替依頼情報を、通信Ｉ／Ｆ６４によってＢ銀行サーバ５０Ｂに送信する（Ｂ６６１０）。

これを受けて、Ｂ銀行サーバ５０Ｂの制御部は、電子マネー振替処理を行う（Ｅ６６１０）。具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した電子マネー振替依頼情報に含まれる口座振替トークンと関連付けられた口座管理データに記憶された口座残高から、電子マネー振替依頼情報に含まれる送金金額を減算するとともに、その口座管理データに記憶された取引履歴に今回の取引内容を加えることで、その取引履歴を更新する。
そして、Ｂ銀行サーバ５０Ｂの制御部は、処理を終了する。

次いで、Ｂ銀行サーバ５０Ｂの制御部は、送金金額の電子マネー振替が完了したことを示す電子マネー振替完了情報を、通信Ｉ／Ｆによってサーバ６０に送信する（Ｅ６６２０）。これにより、サーバ６０とＢ銀行サーバ５０Ｂとの間で行われる認証システム認可処理が終了する。

通信Ｉ／Ｆ６４によってＢ銀行サーバ５０Ｂから電子マネー振替完了情報を受信すると、制御部６１は、受信した電子マネー振替完了情報を表示部６３に表示させる（Ｂ６６３０）。なお、このステップは省略してもよい。

その後、制御部６１は、チャージ処理を行う（Ｂ６６４０）。具体的には、受信した振替完了情報に基づき、電子マネーで上記のアカウント管理データの電子マネー口座残高に送金金額を加算する。

その後、制御部６１は、出金処理を行う（Ｂ６６５０）。具体的には、上記のアカウント管理データの電子マネー口座残高から送金金額を減算するとともに、この送金金額と、上記のアカウント管理データの第２登録銀行口座データに含まれる送金先の銀行口座（この例では、Ａ銀行の銀行口座）の口座ＩＤに関連付けられた口座振替トークンとを含む出金情報を、通信Ｉ／Ｆ６４によってＡ銀行サーバ５０Ａに送信する。

これを受けて、Ａ銀行サーバ５０Ａの制御部は、入金処理を行う（Ｄ６６５０）。具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した出金情報に含まれる口座振替トークンと関連付けられた口座管理データに記憶された口座残高に、出金情報に含まれる送金金額を加算し、その口座管理データに記憶された取引履歴に今回の取引内容を加えることで、その取引履歴を更新する。
そして、Ａ銀行サーバ５０Ａの制御部は、処理を終了する。

次いで、Ａ銀行サーバ５０Ａの制御部は、入金が完了したことを示す入金完了情報を、通信Ｉ／Ｆによってサーバ６０に送信する（Ｄ６６６０）。これにより、サーバ６０とＡ銀行サーバ５０Ａとの間で行われる認証システム認可処理が終了する。

通信Ｉ／Ｆ６４によってＡ銀行サーバ５０Ａから入金完了情報を受信すると、制御部６１は、受信した入金完了情報を表示部６３に表示させる（Ｂ６６６０）。なお、このステップは省略してもよい。
そして、制御部６１は、処理を終了する。

図１０－５に戻り、口座間送金処理を行った後、制御部６１は、口座間送金が完了したことを示す口座間送金完了情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ６７０）。そして、制御部６１は、Ｂ１９５に処理を進める。

これを受けて、制御部２１は、受信された口座間送金完了情報を表示部２４に表示させる（Ａ６９０）。そして、制御部２１は、Ａ１９５に処理を進める。

Ｃ１８０において口座振替要求条件が成立したと判定した場合（Ｃ１８０：ＹＥＳ）、制御部１１は、限定ではなく例として、対象とするユーザ（この例ではユーザＡ．Ａ）のユーザ管理データの第１登録銀行口座データにおいて口座ＩＤと関連付けられている口座振替トークンと、振替要求金額とを含む口座振替要求情報を、通信Ｉ／Ｆ１４によって、その口座ＩＤに対応する銀行の銀行サーバ５０（この例ではＡ銀行サーバ５０Ａ）に送信する（Ｃ６９０）。そして、制御部１１は、Ｃ１９５に処理を進める。

なお、上記の処理では、ユーザがメイン銀行口座から支払うことを希望し、メイン銀行口座が選択された場合、制御部２１は、Ａ６８０，Ａ６９０のステップをスキップすることとしたが、これをスキップしないようにしてもよい。
ただし、この場合であっても、制御部６１は、Ｂ６６０ａ，Ｂ６７０のステップはスキップするようにすることができる。

また、口座間送金を実現する際の手数料は、電子マネーサービス事業者と提携銀行との間で、任意に取り決めることを可能とすることができる。
一例として、電子マネー振替の手数料と、入金の手数料との両方を電子マネーサービス事業者が負担するようにし、対応する提携銀行（上記の例では、Ａ銀行およびＢ銀行）に手数料をそれぞれ支払うようにすることができる。
また、別例として、電子マネー振替の手数料は、電子マネーサービス事業者が負担するようにし、入金の手数料は、出金先の銀行（上記の例では、Ａ銀行）が受け持つようにすることができる。

＜第１０実施例の効果＞
本実施例は、サーバ６０（限定ではなく、端末と通信するサーバの一例）が、端末２０のユーザにより、クレジットカード決済やツケ払い（限定ではなく、後払いの一例）での購入に関する請求情報（限定ではなく、購入情報の一例）をクレジットカード会社サーバ１０から受信する。そして、サーバ６０は、端末２０のユーザがメイン銀行口座（限定ではなく、第１口座の一例）から支払う金額（限定ではなく、第１金額の一例）の情報を含む支払い口座選択情報（限定ではなく、第１情報の一例）と、端末２０のユーザがサブ銀行口座（限定ではなく、第２口座の一例）から支払う金額（限定ではなく、第２金額の一例）の情報を含む支払い口座選択情報（限定ではなく、第２情報の一例）とのうち、少なくともサブ銀行口座に関する支払い口座選択情報を端末２０から受信する。そして、サーバ６０は、受信した口座間送金依頼情報に基づいて、口座間送金処理（限定ではなく、第２口座から第１口座に第２金額を送金することに関する処理の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２口座から第１口座に第２金額を送金させた上で、第１口座から後払いによる支払いが行われるようにすることができる。

また、この場合、端末２０のユーザがメイン銀行口座から支払う金額の情報を含む支払い口座選択情報（第１情報）は、第１購入情報についてメイン銀行口座から支払うことを依頼する情報を含み、端末２０のユーザがサブ銀行口座から支払う金額の情報を含む支払い口座選択情報（第２情報）は、第２購入情報についてサブ銀行口座から支払うことを依頼する情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２購入情報について、あたかも第２口座から支払われるかの如く、実際には、第１口座から支払いが行われるようにすることができる。

また、この場合、口座間送金処理は、限定ではなく例として、締め日（限定ではなく、設定された期日の一例）よりも前に行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、設定された期日までに、第２口座から第１口座への第２金額の送金が行われるようにすることができる。

また、この場合、後払いは、端末のユーザに関連するクレジットカードによって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第２口座から第１口座に第２金額を送金させた上で、第１口座からクレジットカードによる支払いが行われるようにすることができる。

また、本実施例は、口座間送金処理（送金することに関する処理）は、口座間送金依頼情報（第２情報）に基づいて、サブ銀行口座（第２口座）から端末２０のユーザの電子マネー口座（限定ではなく、第３口座の一例）に送金金額を送金する処理を行い、電子マネー口座からメイン銀行口座（第１口座）に送金金額を送金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第３口座を介して、第２口座から第１口座に第２金額を適切に送金することができる。

また、この場合、電子マネー口座（第３口座）は、サーバ６０によって管理されるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金することに関する処理の処理主体であるサーバによって第３口座が管理されるため、第３口座を介した送金が確実に行われるようにすることができる。

また、この場合、サブ銀行口座（第２口座）から端末２０のユーザの電子マネー口座（限定ではなく、第３口座の一例）に送金金額を送金する処理は、サブ銀行口座の残高から電子マネー口座へのチャージ処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１口座の残高から第３口座にチャージする処理によって、第２口座から第３口座への第２金額の送金を実現することができる。

また、この場合、電子マネー口座は、電子マネー（電子貨幣）で送金金額がチャージされるようにすることができる。
このような構成により得られる実施例の効果の一例として、電子貨幣で第２金額が適切にチャージされるようにすることができる。

＜第１０変形例（１）＞
前述した（２）の手法を適用することも可能である。
この手法では、複数の取引についてまとめて出金を行うため、前述した手数料を削減することができるという利点がある。

図１０－７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１０－５に対応する部分を図示したものである。
Ｂ６５０の後、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、電子マネー振替＆チャージ処理を行う（Ｂ６６１）。
具体的には、電子マネー振替を依頼する銀行サーバ５０（この例では、Ｂ銀行サーバ５０Ｂ）との間で、限定ではなく例として、図１０－６のＢ６６１０～Ｂ６６４０、Ｅ６６１０～Ｅ６６２０と同様の処理を行う。

その後、制御部６１は、出金条件が成立したか否かを判定する（Ｂ６６３）。
出金条件は、限定ではなく例として、「出金日時になったこと」とすることができる。

前述したように、限定ではなく例として、クレジットカード決済における口座振替日よりも前の日（日時）に、支払い口座設定期限を設定することができる。限定ではなく例として、前述したように、毎月２５日が口座振替日であって、その３日前が支払い口座設定期限の日に設定される場合、毎月２２日が支払い口座設定期日となる。

これに基づき、出金日時は、限定ではなく例として、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。

出金条件が成立していないと判定したならば（Ｂ６６３：ＮＯ）、制御部６１は、Ｂ１９５に処理を進める。
一方、出金条件が成立したと判定したならば（Ｂ６６３：ＹＥＳ）、制御部６１は、出金処理を行う（Ｂ６６５）。
具体的には、出金を行う銀行サーバ５０（この例では、Ａ銀行サーバ５０Ａ）との間で、限定ではなく例として、図１０－６のＢ６６５０～Ｂ６６６０、Ｄ６６５０～Ｄ６６６０と同様の処理を行う。

その後、制御部６１は、出金が完了したことを示す出金完了情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ６６７）。そして、制御部６１は、Ｂ１９５に処理を進める。

なお、上記の（２）の手法を適用する場合、チャージによって電子マネー口座残高が増加するが、端末２０のユーザは、この電子マネー口座残高を消費して電子マネー決済等を行うことが可能である。電子マネー口座残高が消費されたことにより、まとめて出金を行うタイミングで、電子マネー口座残高が足りなくなることも考えられる。

そこで、ユーザが利用可能な電子マネー口座（通常の電子マネー口座：以下、「第１の電子マネー口座」と称する。）と、ユーザが利用不可の電子マネー口座（出金用の電子マネー口座：以下、「第２の電子マネー口座」と称する。）との２つの電子マネー口座を設けるようにしてもよいし、しなくてもよい。

この場合は、第１の電子マネー口座の残高と、第２の電子マネー口座の残高とを、アカウント管理データに記憶させるようにすることができる。
そして、サーバ６０の制御部６１は、電子マネー振替＆チャージ処理において第２の電子マネー口座にチャージし、出金処理において第２の電子マネー口座から出金するようにすることができる。

＜第１０変形例（２）＞
前述した（３）の手法を適用することも可能である。
この手法も、複数の取引についてまとめて送金（チャージ＆出金）を行うため、前述した手数料を削減することができるという利点がある。

図１０－８は、本実施例においてサーバ６０の記憶部６５に記憶されるアカウント管理データベース６５５の一例であるアカウント管理データベース６５５Ｆのデータ構成例を示す図である。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションＩＤと、電子マネー口座残高と、取引データと、第２登録銀行口座データと、支払い口座設定データとが記憶される。

支払い口座設定データには、取引ＩＤと、支払い口座ＩＤとに加えて、限定ではなく例として、送金フラグが設定される。

送金フラグは、デフォルトでは「ＯＦＦ」に設定されるが、この取引ＩＤについて口座間送金を行う場合は「ＯＮ」に設定されるフラグである。口座間送金が完了した場合は、このフラグは「ＯＦＦ」に戻される。

図１０－９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１０－５に対応する部分を図示したものである。この処理は、前述した（３－１）の手法を適用する場合の処理の一例である。

Ｂ６５０の後、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、口座間送金設定処理を行う（Ｂ６６２）。
具体的には、限定ではなく例として、端末２０Ａから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、この請求情報に対応する取引ＩＤに関連付けられた支払い口座ＩＤに、ユーザＡ．Ａのサブ銀行口座の口座ＩＤ（この例では、Ｂ銀行の口座ＩＤ：ＢＢ００１）を記憶させるとともに、送金フラグを「ＯＮ」に設定する。

その後、制御部６１は、口座間送金条件が成立したか否かを判定する（Ｂ６６４）。
口座間送金条件は、限定ではなく例として、「口座間送金日時になったこと」とすることができる。口座間送金日時は、限定ではなく例として、出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。

口座間送金条件が成立していないと判定したならば（Ｂ６６４：ＮＯ）、制御部６１は、Ｂ１９５に処理を進める。

一方、口座間送金条件が成立したと判定したならば（Ｂ６６４：ＹＥＳ）、制御部６１は、口座間送金処理を行う（Ｂ６６０ｂ）。
この口座間送金処理は、図１０－６と同様の手順で行うことができるが、制御部６１は、アカウント管理データの支払い口座設定データにおいて、送金フラグが「ＯＮ」に設定されている取引ＩＤの購入金額を合計した金額を送金金額として、図１０－６と同様の処理を行う。そして、制御部６１は、送金フラグを全て「ＯＦＦ」に戻す。

その後、制御部６１は、口座間送金が完了したことを示す口座間送金完了情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ６６６）。そして、制御部６１は、Ｂ１９５に処理を進める。

また、上記の他にも、前述した（３－２）の手法を適用することも可能である。

＜表示画面＞
図１０－１０は、前述した（３－２）の手法を適用した場合において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。図１０－１０は、端末２０の電子マネーアプリケーションにおいて支払い口座を設定する場合の表示画面の一例を示す図である。

図１０－１０左は、電子マネーアプリケーションにおける今月度支払い口座設定画面（本例では「１０月度支払い口座設定画面」）であり、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、図２－４中央の画面と同様の情報が表示されている。

図１０－１０左に示される今月度支払い口座設定画面において、限定ではなく例として、クレジットカード取引毎に、上から順に、Ａ銀行（メイン銀行口座）に対応する第１アイコンＩＣ１Ａ、Ｂ銀行（サブ銀行口座）に対応する第１アイコンＩＣ１Ｂ、Ａ銀行（メイン銀行口座）に対応する第１アイコンＩＣ１Ａがタップされた後、第２ボタンＢＴ３がタップされると、限定ではなく例として、図１０－１０右に示すような今月度支払い口座設定完了画面が、電子マネーアプリケーションにおいて表示される。

この画面は、電子マネーアプリケーションにおける今月度支払い口座設定画面（本例では「１０月度支払い口座設定画面」）であり、電子マネーアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。
また、その下には、図２－４右の画面と同様の情報が表示されている。

図１０－１１，図１０－１２は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
このうち、図１０－１１は、図１０－９に対応する部分を示している。

図１０－１１のＣ１３１の後、制御部１１は、当月確定請求情報送信条件が成立したか否かを判定し（Ｃ７２０）、成立したと判定したならば（Ｃ７２０：ＹＥＳ）、限定ではなく例として、対象とするユーザの電子マネーアプリケーションのアカウント情報（限定ではなく例として、電子マネーアプリケーションＩＤ）を含む当月確定請求情報を、通信Ｉ／Ｆ１４によってサーバ６０に送信する（Ｃ７３０）。そして、制御部１１は、Ｃ１８０に処理を進める。

図１０－１１のＢ６６６の後、制御部６１は、通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０から当月確定請求情報を受信したか否かを判定し（Ｂ７２５）、受信したと判定したならば（Ｂ７２５：ＹＥＳ）、当月確定請求情報（限定ではなく例として、当月確定請求情報を含む電子マネーアプリケーションにおける請求ページ）を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ７３０）。

図１０－１１のＡ６９４の後、通信Ｉ／Ｆ２２によってサーバ６０から当月確定請求情報を受信すると、制御部２１は、受信した当月確定請求情報を表示部２４に表示させる（Ａ２３０）。

その後、制御部２１は、入力部を介して支払い口座設定を行うための入力がなされたか否かを判定する（Ａ７４０）。入力がなされなかったと判定したならば（Ａ７４０：ＮＯ）、制御部２１は、Ａ１９５に処理を進める。
一方、入力がなされたと判定したならば（Ａ７４０：ＹＥＳ）、制御部２１は、支払い口座設定を要求するための支払い口座設定要求情報を、通信Ｉ／Ｆ２２によってサーバ６０に送信する（Ａ７５０）。

Ｂ７３０の後、制御部６１は、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座設定要求情報を受信したか否かを判定し（Ｂ７４０）、受信したと判定したならば（Ｂ７４０：ＹＥＳ）、支払い口座設定用情報を、通信Ｉ／Ｆ６４によって端末２０Ａに送信する（Ｂ７５０）。

通信Ｉ／Ｆ２２によってサーバ６０から支払い口座設定用情報を受信すると、制御部２１は、受信した支払い口座設定用情報を表示部２４に表示させる（Ａ７６０）。
その後、制御部２１は、入力部を介して、ユーザによる支払い口座の選択を受け付ける（Ａ７７０）。具体的には、当月度請求情報に含まれる各々の取引情報について、ユーザがメイン銀行口座から支払う取引情報（以下、「第１取引情報」と称する。）と、ユーザがサブ銀行口座から支払う取引情報（以下、「第２取引情報」と称する。）とのうち、少なくとも第２取引情報の選択を受け付ける。
第１取引情報は、１または複数の取引情報とすることができる。同様に、第２取引情報も、１または複数の取引情報とすることができる。

その後、制御部２１は、入力された情報を含む支払い口座選択情報を、通信Ｉ／Ｆ２２によってサーバ６０に送信する（Ａ７８０）。

通信Ｉ／Ｆ６４によって端末２０Ａから口座間送金要求情報を受信すると、制御部６１は、口座間送金設定処理を行う（Ｂ７７２）。
具体的には、限定ではなく例として、端末２０Ａから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、ユーザによって選択された各々の第２取引情報について、対応する取引ＩＤに関連付けられた支払い口座ＩＤに、ユーザＡ．Ａのサブ銀行口座の口座ＩＤ（この例では、Ｂ銀行の口座ＩＤ：ＢＢ００１）を記憶させるとともに、送金フラグを「ＯＮ」に設定する。
そして、制御部６１は、Ｂ６６４に処理を進める。

Ｂ６６０ｂの口座間送金処理では、制御部６１は、アカウント管理データの支払い口座設定データにおいて、送金フラグが「ＯＮ」に設定されている取引ＩＤの購入金額を合計した金額を送金金額として、図１０－６と同様の処理を行う。つまり、ユーザによって選択された第２取引情報に対応する購入金額を合計した金額が、サブ銀行口座からメイン銀行口座に送金される金額となる。

本変形例は、口座間送金処理は、限定ではなく例として、口座間送金日（限定ではなく、設定された日にちの一例）に行われる、または後払いの口座振替日（限定ではなく例として、設定された期日の一例）までに行われるようにすることができる。
このような構成により得られる変形例の効果の一例として、設定された日にちに、または設定された期日までに、第２口座から第１口座への第２金額の送金が行われるようにすることができる。

また、本変形例は、請求情報は、複数の請求情報を含む当月確定請求情報であり（限定ではなく、第１購入情報と第２購入情報と第３購入情報とを含む購入情報の一例）であり、第１金額は、第１請求情報に対応する購入金額（限定ではなく、第１購入情報の購入に基づく金額の一例）を含み、第２金額は、２以上の第２請求情報に対応する購入金額を合計した金額（限定ではなく、第２購入情報と第３購入情報との合計の金額の一例）を含む構成を示している。
このような構成により得られる変形例の効果の一例として、第２購入情報と第３購入情報との合計の金額を含む第２金額を、第２口座から第１口座に送金させることができる。

また、本変形例は、後払いは、端末２０のユーザに関連するクレジットカードによって行われ、口座間送金処理は、クレジットカード決済の口座振替日（限定ではなく、クレジットカードの支払い日の一例）に基づいて行われる構成を示している。
このような構成により得られる変形例の効果の一例として、クレジットカードの支払い日に基づいて、第２口座から第１口座への第２金額の送金が行われるようにすることができる。

＜第１０変形例（３）＞
サーバ６０が、ユーザによってメイン銀行口座から支払うことが選択された取引情報に対応する購入金額と、ユーザによってサブ銀行口座から支払うことが選択された取引情報に対応する購入金額とを含む金額の情報を、クレジットカード会社サーバ１０に送信して、クレジットカード会社に通知するようにしてもよいし、しなくてもよい。

クレジットカード会社サーバ１０は、ユーザの取引ごとの購入金額や、ユーザの当月分の合計の購入金額等の情報を記憶部１５に記憶しているため、クレジットカード会社は、口座振替によってユーザのメイン銀行口座から引き落とされる金額を把握している。
しかし、サーバ６０が、上記の金額の情報をクレジットカード会社サーバ１０に送信することで、クレジットカード会社は、ユーザが複数の銀行口座をどのように使い分けているかなどの分析を行うことができる。

本変形例は、サーバ６０は、端末２０のユーザがサブ銀行口座（限定ではなく、第２口座の一例）から支払う金額（限定ではなく、第２金額の一例）の情報を含む支払い口座選択情報ばかりでなく、端末２０のユーザがメイン銀行口座（限定ではなく、第１口座の一例）から支払う金額（限定ではなく、第１金額の一例）の情報を含む支払い口座選択情報も端末２０から受信する。そして、サーバ６０は、受信した支払い口座選択情報に基づいて、第１金額と第２金額とを含む金額をメイン銀行口座（限定ではなく、第１口座の一例）から支払うことに関する処理を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報ばかりでなく、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報も受信した上で、第１情報と第２情報とに基づいて、第１金額と第２金額とを含む金額を第１口座から支払うことに関する処理を行うことができる。

また、この場合、後払いは、端末２０のユーザに関連するクレジットカードによって行われる。そして、制御部６１によって行われる、第１金額と第２金額とを含む金額を端末２０のユーザのメイン銀行口座から支払うことに関する処理は、第１金額と第２金額とを含む金額の情報を、通信Ｉ／Ｆ６４によってクレジットカード会社サーバ１０（限定ではなく、クレジットカードの情報を管理する第１サーバの一例）に送信する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第１口座によって支払う第１金額と、端末のユーザに関連する第２口座によって支払う第２金額とを含む金額の情報を、クレジットカードの情報を管理する第１サーバのユーザ（クレジットカード会社等）に通知することができる。これにより、第１サーバのユーザは、受信した金額の情報に基づいて、ユーザが第１口座と第２口座とをどのように使い分けているかなどの分析を行うことができる。

なお、第１金額と第２金額とを含む金額を第１口座から支払うことに関する処理とは、限定ではなく例として、第１金額と第２金額とを含む金額を第１口座から支払う旨を他の装置に通知する処理や、第１金額と第２金額とを含む金額の情報を他の装置に送信する処理など、第１金額と第２金額とを含む金額を第１口座から支払うことと何らかの関係性を有する処理である。

＜第１０変形例（４）＞
クレジットカード決済によるユーザの支払い金額を、電子マネーサービス事業者が立て替える、つまり、一時的に負担するようにする。そして、電子マネーサービス事業者が、立て替えた金額（以下、「立替金額」と称する。）を、ユーザのメイン銀行口座（第１口座）から口座振替等によって引き落とすようにすることも可能である。

図１０－１３，図１０－１４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ｂ６６６の後、制御部６１は、立替支払い条件が成立したか否かを判定する（Ｂ７９２）。立替支払い条件は、ユーザに立て替えてクレジットカード決済の支払い金額を、電子マネーサービス事業者がクレジットカード会社に支払う条件である。
この立替支払い条件は、限定ではなく例として、「立替支払い日時になったこと」とすることができる。立替支払い日時は、限定ではなく例として、クレジットカード会社によって設定される日時とすることができる。

立替支払い条件が成立した場合（Ｂ７９２：ＹＥＳ）、制御部６１は、立替支払い処理を行う（Ｂ７９４）。
具体的には、限定ではなく例として、アカウント管理データの取引データに基づき、ユーザＡ．Ａの当月分の支払い金額を算出する。そして、算出した支払い金額を「立替金額」とし、振込処理等を行って、電子マネーサービス事業者の銀行口座からクレジットカード会社の銀行口座に立替金額を送金する。

その後、制御部６１は、口座振替要求条件が成立しているか否かを判定する（Ｂ７９６）。
口座振替要求条件は、サーバ６０が口座振替を銀行サーバ５０に要求（依頼）するための条件であり、限定ではなく例として、「電子マネーサービス事業者が設定した口座振替日時（限定ではなく例として、毎月２５日の２４時）になったこと」とすることができる。

口座振替要求条件が成立すると判定した場合（Ｂ７９６：ＹＥＳ）、制御部６１は、対象とするユーザ（この例では、ユーザＡ．Ａ）のアカウント管理データの第２登録銀行口座データにおいて種別「メイン」の口座ＩＤと関連付けられている口座振替トークンと、振替要求金額（＝立替金額）の情報とを含む口座振替要求情報を、通信Ｉ／Ｆ６４によって、その口座ＩＤに対応する銀行の銀行サーバ５０（この例では、Ａ銀行サーバ５０Ａ）に送信する（Ｂ７９８）。

なお、振替要求金額（＝立替金額）の情報には、端末２０のユーザがサブ銀行口座（第２口座）から支払う金額（第２金額）と、端末２０のユーザがメイン銀行口座（第１口座）から支払う金額（第１金額）とを含めることができる。

これを受けて、Ａ銀行サーバ５０Ａの制御部は、受信された口座振替要求情報に基づいて、口座振替処理を実行する（Ｄ１９０）。
この口座振替処理により、振替要求金額（＝立替金額）が電子マネーサービス事業者に支払われる。

なお、この場合、サーバ６０からユーザのメイン銀行口座の銀行サーバ５０に対して送信する情報（通信する情報）は、限定ではなく例として、以下のいずれかとすることができる。
・第１金額の情報と、第２金額の情報
・第１金額と第２金額とを合計した合計金額の情報（第１口座から支払う金額の情報）
・第１金額と第２金額とを合計した合計金額の情報（第１口座から支払う金額の情報）と、第２金額の情報（第２口座から支払う金額の情報）

本変形例は、サーバ６０は、端末２０のユーザがサブ銀行口座（限定ではなく、第２口座の一例）から支払う金額（限定ではなく、第２金額の一例）の情報を含む支払い口座選択情報ばかりでなく、端末２０のユーザがメイン銀行口座（限定ではなく、第１口座の一例）から支払う金額（限定ではなく、第１金額の一例）の情報を含む支払い口座選択情報も端末２０から受信する。
そして、サーバ６０は、第１金額と第２金額とを含む金額を端末２０のユーザのメイン銀行口座から支払うことに関する処理として、振替要求金額（＝立替金額）の情報を含む口座振替要求情報（限定ではなく、第１金額と第２金額とを含む金額の情報の一例）を、通信Ｉ／Ｆ６４によってユーザのメイン銀行口座を管理する銀行サーバ５０（限定ではなく、第１口座を管理する第２サーバの一例）に送信する処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第１口座によって支払う第１金額と、端末のユーザに関連する第２口座によって支払う第２金額とを含む金額の情報を、端末のユーザの第１口座を管理する第２サーバのユーザ（金融機関等）に通知することができる。これにより、第２サーバのユーザは、受信した情報に基づく金額を、サーバのユーザ（電子マネーサービス事業者等）に支払うなどすることができる。

＜第１０変形例（５）＞
上記の実施例では、サーバのユーザ（事業者）を、電子マネーサービス事業者（電子マネーアプリケーションの事業者）としたが、これに限定されない。
限定ではなく例として、銀行等の金融機関をサーバのユーザ（事業者）としてもよい。
この場合、ユーザのメイン銀行口座とサブ銀行口座とが同一銀行（または、同一銀行同一支店）の銀行口座である場合は、この銀行の銀行サーバ５０が、サブ銀行口座からメイン銀行口座への振替（振替処理）を行って送金を実現すればよい。
一方、ユーザのメイン銀行口座とサブ銀行口座とが異なる銀行の銀行口座である場合は、限定ではなく例として、サブ銀行口座の銀行の銀行サーバ５０が、サブ銀行口座から他行のメイン銀行口座への振込（振込処理）を行って送金を実現すればよい。

また、限定ではなく例として、資金移動業者をサーバのユーザ（事業者）としてもよい。
この場合、限定ではなく例として、前述した電子マネーサービス事業者等の資金移動業者をサーバのユーザとすることができるが、前述した以下の形態のいずれかの形態を適用し、上記の実施例において、チャットサービス（チャットアプリケーション）を介在させることもできる。
（ａ）チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
（ｂ）電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
（ｃ）チャットサービスの機能と電子マネーサービスの機能とを有する複合的（統合的）なアプリケーションを構成する形態

＜第１１実施例＞
第１１実施例は、ユーザがクレジットカード決済を行った後、その支払いをサブ銀行口座から行う金額（第２金額）等の情報をサーバ６０が銀行サーバ５０に送信する。そして、メイン銀行口座を管理する銀行サーバ５０と、サブ銀行口座を管理する銀行サーバ５０との間で口座間送金を実現する実施例である。
以下では、この手法を「銀行方式口座間送金」と称する。
第１１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

銀行方式口座間送金を実現するための手法としては、大きく分けて、以下の手法が考えられる。
（Ａ）取引ごとに送金（振込）を行う手法
（Ｂ）取引ごとに振替要求金額を設定する処理を行い、複数の取引についてまとめて送金を行う手法
（Ｃ）複数の取引についてまとめて送金（振込）を行う手法

また、（Ｃ）の手法には、限定ではなく例として、以下の手法が考えられる。
（Ｃ－１）取引ごとに送金設定を行い、複数の取引についてまとめて送金を行う手法
（Ｃ－２）複数の取引についてまとめて送金設定を行い、複数の取引についてまとめて送金を行う手法

以下、各々の手法を適用する場合について説明する。

＜処理＞
本実施例では、あらかじめ、サーバ６０によって、アカウント管理データにおける対象とするユーザ（ここでは「ユーザＡ．Ａ」として説明する。）の電子マネーアプリケーションＩＤと、この電子マネーアプリケーションＩＤが記憶されたアカウント管理データの第２登録銀行口座データに含まれる種別が「メイン」である銀行口座（ここでは「Ａ銀行の銀行口座」として説明する。）の口座ＩＤに関連付けられた口座振替トークンとを含む情報が、通信Ｉ／Ｆ６４によってＡ銀行サーバ５０Ａに送信される。
そして、Ａ銀行サーバ５０Ａによって、ユーザＡ．Ａの電子マネーアプリケーションＩＤと、ユーザＡ．ＡのＡ銀行の銀行口座に関連付けられた口座振替トークンとが関連付けて記憶される。

同様に、あらかじめ、サーバ６０によって、アカウント管理データにおける対象とするユーザ（ここでは「ユーザＡ．Ａ」として説明する。）の電子マネーアプリケーションＩＤと、この電子マネーアプリケーションＩＤが記憶されたアカウント管理データの第２登録銀行口座データに含まれる種別が「サブ」である銀行口座（ここでは「Ｂ銀行の銀行口座」として説明する。）の口座ＩＤに関連付けられた口座振替トークンとを含む情報が、通信Ｉ／Ｆ６４によってＢ銀行サーバ５０Ｂに送信される。
そして、Ｂ銀行サーバ５０Ｂによって、ユーザＡ．Ａの電子マネーアプリケーションＩＤと、ユーザＡ．ＡのＢ銀行の銀行口座に関連付けられた口座振替トークンとが関連付けて記憶される。

その後、サーバ６０、Ａ銀行サーバ５０Ａ、Ｂ銀行サーバ５０Ｂの間で、この電子マネーアプリケーションＩＤを介して銀行方式口座間送金が実現されるようにする。

なお、この手法はあくまでも一例であり、これに限定されない。
電子マネーアプリケーションＩＤとは異なる識別情報を介して銀行方式口座間送金を実現してもよい。
また、提携銀行の同意を得た上で、口座振替トークンを介して銀行方式口座間送金を実現してもよい。

図１１－１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理は、前述した（Ａ）の手法を適用する場合の処理の一例である。
なお、図１０－４、図１０－５に示したＢ６５０までの処理と、Ｂ６７０以降の処理とは同様であるため、図示・説明は省略する。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、サーバ６０の制御部２１が実行する処理、クレジットカード会社サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理の一例を示している。

Ｂ６５０の後、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、第１の銀行方式口座間送金処理を実行する（Ｂ６６０ｃ）。

図１１－２は、第１の銀行方式口座間送金処理の流れの一例を示すフローチャートであり、この図では、左側から順に、サーバ６０の制御部６１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

そして、制御部６１は、取引データにおけるこの取引ＩＤに対応する購入金額を送金金額とし、送金金額と、対象とするユーザ（この例ではユーザＡ．Ａ）の電子マネーアプリケーションＩＤとを含む銀行方式口座間送金情報を、通信Ｉ／Ｆ６４によってＡ銀行サーバ５０Ａに送信する（Ｂ６６１５）。
銀行方式口座間送金情報は、銀行方式口座間送金を依頼する情報であり、この例では、Ａ銀行サーバ５０Ａに対して、Ｂ銀行サーバ５０Ｂからお金を引き出すように依頼する情報である。

これを受けて、Ａ銀行サーバ５０Ａの制御部は、送金金額と、対象とするユーザ（この例ではユーザＡ．Ａ）の電子マネーアプリケーションＩＤとを含む振込要求情報を、Ａ銀行サーバ５０Ａの通信Ｉ／ＦによってＢ銀行サーバ５０Ｂに送信する（Ｄ６６１５）。

これを受けて、Ｂ銀行サーバ５０Ｂの制御部は、振込処理を行う（Ｅ６６１５）。
具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した振込要求情報に含まれる電子マネーアプリケーションＩＤと関連付けられた口座振替トークンに対応する口座管理データに記憶された口座残高から、振込要求情報に含まれる送金金額を減算するとともに、振込要求情報の送信元であり、振込先であるＡ銀行サーバ５０Ａに、その送金金額を送金する。

そして、Ｂ銀行サーバ５０Ｂの制御部は、振込処理が完了したことを通知するための情報を含む振込完了情報を、Ｂ銀行サーバ５０Ｂの通信Ｉ／ＦによってＡ銀行サーバ５０Ａに送信する（Ｅ６６１７）。

通信Ｉ／ＦによってＢ銀行サーバ５０Ｂから振込完了情報を受信すると、Ａ銀行サーバ５０Ａの制御部は、受信された振込完了情報に基づいて、送金金額の送金に関する処理が終了したことを通知する情報を含む送金完了情報を、Ａ銀行サーバ５０Ａの通信Ｉ/Ｆによってサーバ６０に送信する（Ｄ６６１７）。

図１１－１に戻り、第１の銀行方式口座間送金処理を行った後、制御部６１は、Ｂ６７０に処理を進める。

＜第１１実施例の効果＞
本実施例は、サーバ６０が、端末２０のユーザがサブ銀行口座から支払いを行うことを予定している支払い予定金額（限定ではなく、第２金額の一例）の情報を、メイン銀行口座（第１口座）を管理する銀行サーバ５０（限定ではなく、第２サーバの一例）に送信する処理を含む銀行方式口座間送金処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第２口座によって支払う第２金額を、端末のユーザに関連する第１口座を管理する第２サーバに通知することができる。

＜第１１変形例（１）＞
前述した（Ｂ）の手法を適用することも可能である。
この手法では、複数の取引についてまとめて送金を行うため、前述した手数料を削減することができるという利点がある。

図１１－３は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１１－１に対応する部分を図示したものである。
Ｂ６５０の後、通信Ｉ／Ｆ６４によって端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、第２の銀行方式口座間送金処理を行う（Ｂ６６０ｄ）。

図１１－４は、第２の銀行方式口座間送金処理の流れの一例を示すフローチャートであり、この図では、左側から順に、サーバ６０の制御部６１が実行する処理、Ａ銀行サーバ５０Ａの制御部が実行する処理、Ｂ銀行サーバ５０Ｂの制御部が実行する処理の一例を示している。

Ｄ６６１５によって、送金金額と、対象とするユーザ（この例ではユーザＡ．Ａ）の電子マネーアプリケーションＩＤとを含む振込要求情報がＡ銀行サーバ５０ＡからＢ銀行サーバ５０Ｂに送信されると、Ｂ銀行サーバ５０Ｂの制御部は、振込設定処理を行う（Ｅ６６１１）。
具体的には、限定ではなく例として、Ａ銀行サーバ５０Ａから受信した振込要求情報に含まれる電子マネーアプリケーションＩＤと関連付けて、受信した振込要求情報に含まれる送金金額を加算して更新し、送金フラグを「ＯＮ」に設定する。

次いで、Ｂ銀行サーバ５０Ｂの制御部は、振込条件が成立したか否かを判定する（Ｅ６６１３）。
振込条件は、限定ではなく例として、「振込日時になったこと」とすることができる。振込日時は、限定ではなく例として、前述した送金日時や出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。

振込条件が成立していないと判定したならば（Ｅ６６１３：ＮＯ）、Ｂ銀行サーバ５０Ｂの制御部は、処理を終了する。

一方、振込条件が成立したと判定したならば（Ｅ６６１３：ＹＥＳ）、Ｂ銀行サーバ５０Ｂの制御部は、Ｅ６６１５に処理を進める。
これを受けて、Ｂ銀行サーバ５０Ｂの制御部は、振込処理を行う（Ｅ６６１５）。
具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した振込要求情報に含まれる電子マネーアプリケーションＩＤと関連付けられた口座振替トークンに対応する口座管理データに記憶された口座残高から、この電子マネーアプリケーションＩＤと関連付けて記憶されている最新の送金金額（累積的な送金金額）を減算するとともに、振込要求情報の送信元であり、振込先であるＡ銀行サーバ５０Ａに、その送金金額を送金する。
そして、Ｂ銀行サーバ５０Ｂの制御部は、Ｅ６６１７に処理を進める。

図１１－３に戻り、第２の銀行方式口座間送金処理を行った後、制御部６１は、Ｂ６７０に処理を進める。

なお、上記の処理において、Ａ銀行サーバ５０Ａが、サーバ６０から受信した銀行方式口座間送金情報に含まれる送金金額を累積的に加算して更新する処理を行い、振込要求条件が成立した場合に、累積的な送金金額の情報を含む振込要求情報をＢ銀行サーバ５０Ｂに送信するようにしてもよい。
この場合、Ｂ銀行サーバ５０Ｂは、受信した振込要求情報に含まれる累積的な送金金額を、振込処理によってＡ銀行サーバ５０Ａに送金する。

＜第１１変形例（２）＞
前述した（Ｃ）の手法を適用することも可能である。
この手法では、複数の取引についてまとめて送金を行うため、前述した手数料を軽減することができるという利点がある。

図１１－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１１－３に対応する部分を示している。

Ｂ６５０の後、端末２０Ａから支払い口座選択情報を受信すると、制御部６１は、銀行方式口座間送金設定処理を行う（Ｂ６８０）。
具体的には、限定ではなく例として、端末２０Ａから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、この請求情報に対応する取引ＩＤに関連付けられた支払い口座ＩＤに、ユーザＡ．Ａのサブ銀行口座の口座ＩＤ（この例では、Ｂ銀行の口座ＩＤ：ＢＢ００１）を記憶させるとともに、送金フラグを「ＯＮ」に設定する。

その後、制御部６１は、銀行方式口座間送金条件が成立したか否かを判定する（Ｂ６８２）。
銀行方式口座間送金条件は、限定ではなく例として、「銀行方式口座間送金日時になったこと」とすることができる。銀行方式口座間送金日時は、限定ではなく例として、出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。

銀行方式口座間送金条件が成立していないと判定したならば（Ｂ６８２：ＮＯ）、制御部６１は、Ｂ１９５に処理を進める。

一方、銀行方式口座間送金条件が成立したと判定したならば（Ｂ６８２：ＹＥＳ）、制御部６１は、第３の銀行方式口座間送金処理を行う（Ｂ６６０ｅ）。
この第３の銀行方式口座間送金処理は、図１１－２の第１の銀行方式口座間送金処理と同様の手順で行うことができるが、制御部６１は、アカウント管理データの支払い口座設定データにおいて、送金フラグが「ＯＮ」に設定されている取引ＩＤの購入金額を合計した金額を送金金額として、Ｂ６６１５のステップを実行する。そして、制御部６１は、送金フラグを全て「ＯＦＦ」に戻す。

＜第１１変形例（３）＞
第１０変形例（３）と同様に、サーバ６０が、ユーザによってメイン銀行口座から支払うことが選択された取引情報に対応する購入金額と、ユーザによってサブ銀行口座から支払うことが選択された取引情報に対応する購入金額とを含む金額の情報を、クレジットカード会社サーバ１０に送信して、クレジットカード会社に通知するようにしてもよいし、しなくてもよい。

本変形例は、サーバ６０は、端末２０のユーザがサブ銀行口座（限定ではなく、第２口座の一例）から支払う金額（限定ではなく、第２金額の一例）の情報を含む支払い口座選択情報ばかりでなく、端末２０のユーザがメイン銀行口座（限定ではなく、第１口座の一例）から支払う金額（限定ではなく、第１金額の一例）の情報を含む支払い口座選択情報も端末２０から受信する。そして、サーバ６０は、受信した支払い口座選択情報に基づいて、第１金額と第２金額とを含む金額をメイン銀行口座から支払うことに関する処理を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報ばかりでなく、端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報も受信した上で、第１情報と第２情報とに基づいて、第１金額と第２金額とを含む金額を第１口座から支払うことに関する処理を行うことができる。

＜第１１変形例（４）＞
第１０変形例（４）と同様に、クレジットカード決済によるユーザの支払い金額を、電子マネーサービス事業者が立て替え、その立替金額を、ユーザのメイン銀行口座（第１口座）から口座振替等によって引き落とすようにすることも可能である。
この場合は、限定ではなく例として、図１０－１３，図１０－１４の処理を、第１１実施例で説明した銀行方式口座間送金に適用することで実現可能である。

＜第１１変形例（５）＞
上記の実施例では、サーバ６０からＡ銀行サーバ５０Ａに対して、Ｂ銀行サーバ５０Ｂからお金を引き出すように依頼する情報を送信することによって、Ａ銀行サーバ５０ＡからＢ銀行サーバ５０Ｂに対して振込要求情報が送信され、Ｂ銀行サーバ５０ＢからＡ銀行サーバ５０Ａに振込が行われることとしたが、これに限定されない。

反対に、サーバ６０からＢ銀行サーバ５０Ｂに対して、Ａ銀行サーバ５０Ａにお金を振り込むように依頼する情報を送信することによって、Ｂ銀行サーバ５０ＢからＡ銀行サーバ５０Ａに振込が行われるようにすることも可能である。

＜第１１変形例（６）＞
第１０変形例（５）と同様に、サーバのユーザを、銀行等の金融機関としてもよい。
この場合、ユーザのメイン銀行口座（第１口座）とサブ銀行口座（第２口座）とが同一銀行（または、同一銀行同一支店）の銀行口座である場合は、この銀行の銀行サーバ５０が、サブ銀行口座からメイン銀行口座への振替（振替処理）を行って、口座間送金を実現すればよい。
一方、ユーザのメイン銀行口座とサブ銀行口座とが異なる銀行の銀行口座である場合は、限定ではなく例として、サブ銀行口座の銀行の銀行サーバ５０が、サブ銀行口座から他行のメイン銀行口座への振込（振込処理）を行って送金を実現すればよい。

＜第１０実施例～第１１実施例に関連する他の実施例＞
（１）第１実施例～第９実施例やこれらの実施例に対応する変形例に記載した内容、第１実施例～第９実施例に関連する他の実施例に記載した内容は、第１０実施例，第１１実施例についても同様に適用可能である。以下、その一部を例示する。

限定ではなく例として、第７実施例の内容を第１０実施例に適用する場合、銀行口座情報として銀行名や口座番号とは異なる情報を端末２０の表示部２４に表示させるようにすることもできる。
具体的には、限定ではなく例として、銀行口座情報のうち銀行名や口座番号とは異なる情報として、ユーザの銀行口座の残高、またはこれに関連する情報を表示させるようにすることも可能である。

＜表示画面＞
図１２－１は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１２－１は、端末２０の電子マネーアプリケーションにおける支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。

図１２－１には、電子マネーアプリケーションのうち銀行口座の設定ページの表示画面（以下、適宜「支払い口座設定画面」と称する。）の一例を示しており、クレジットカードに紐づいているメイン銀行口座情報（限定ではなく例として、メイン銀行口座であるＡ銀行に対応する銀行名、口座番号、残高等）と、クレジットカードに紐づいていないサブ銀行口座情報（限定ではなく例として、サブ銀行口座であるＢ銀行に対応する銀行名、口座番号、残高等）とを表示するための銀行口座情報表示領域が構成されており、この例では、メイン銀行口座であるＡ銀行に対応する銀行名として「Ａ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。また、サブ銀行口座であるＢ銀行に対応する銀行名として「Ｂ銀行」の文字と、その口座番号として「ＸＸＸＸＸＸＸ」の数字と、その残高として「ＹＹＹＹＹＹ円」の数字とが表示されている。
また、その他には、図１－３１中央の画面と同様の情報が表示されている。

（２）第１０実施例，第１１実施例では、サブ銀行口座を１つとして説明したが、サブ銀行口座を２つ以上とすることも可能である。この場合の処理は、上記の実施例と同様に構成することができるため、詳細な説明は省略する。

（３）第１実施例～第９実施例の手法では、支払い口座として設定可能な各々の銀行口座がクレジットカードに紐づけられており、各々の銀行口座から口座振替が行われ得るため、口座振替が行われる前でなければ、支払い口座を変更することはできなかった。
しかし、第１０実施例，第１１実施例の口座間送金の手法では、口座振替が行われるのはメイン銀行口座のみであるため、メイン銀行口座から口座振替が行われた後であっても、支払い口座を変更できるようにすることも可能である。

限定ではなく例として、支払い口座としてメイン銀行口座が設定され、メイン銀行口座から口座振替が行われた後に、支払い口座がサブ銀行口座に変更された場合は、メイン銀行口座から引き落とされた金額を、事後的に口座間送金によってサブ銀行口座からメイン銀行口座に移すようにすることができる。

（４）第１１実施例で説明した銀行方式口座間送金において、サーバ６０が銀行サーバ５０に口座間送金を依頼するようにするのではなく、端末２０が銀行サーバ５０に口座間送金を依頼するようにしてもよい。
この場合は、通信システム１Ｂの構成要素からサーバ６０を除外し、図１－１の通信システム１Ａを適用することが可能である。

（５）前述したように、メイン銀行口座をデフォルトの支払い口座として設定するようにすることも可能である。
この場合、複数の銀行口座の中から支払い口座として設定する銀行口座をユーザに選択させるのではなく、サブ銀行口座から支払いを希望する取引をユーザに選択させるようにしてもよい。
限定ではなく例として、Ａ銀行の銀行口座がメイン銀行口座であり、Ｂ銀行の銀行口座がサブ銀行口座である場合、Ｂ銀行の銀行口座から支払いを希望する取引をユーザに選択させるようにする。そして、選択された取引について、支払い口座をＢ銀行の銀行口座に更新するようにすることができる。

１（１Ａ，１Ｂ）通信システム
１０クレジットカード会社サーバ
２０端末
３０ネットワーク
４０店舗端末
５０銀行サーバ
６０サーバ

Claims

端末と通信するサーバであって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を受信し、前記購入情報のうち、前記端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、前記端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも前記第２情報を受信する通信部と、
前記第２情報に基づいて、前記第２口座から前記第１口座に前記第２金額を送金することに関する処理を行う制御部とを備える。
請求項１に記載のサーバであって、
前記購入情報は、第１購入情報と第２購入情報とを含み、
前記第１情報は、前記第１購入情報の購入を前記第１口座によって支払うことに関する情報を含み、
前記第２情報は、前記第２購入情報の購入を前記第２口座によって支払うことに関する情報を含む。
請求項１または請求項２に記載のサーバであって、
前記送金することに関する処理は、設定された日にちに行われる、または設定された期日までに行われる。
請求項３に記載のサーバであって、
前記購入情報は、第１購入情報と第２購入情報と第３購入情報とを含み、
前記第１金額は、前記第１購入情報の金額を含み、
前記第２金額は、前記第２購入情報と前記第３購入情報との合計の金額を含む。
請求項３に記載のサーバであって、
前記後払いは、前記端末のユーザに関連するクレジットカードによって行われ、
前記送金することに関する処理は、前記クレジットカードの支払日に基づいて行われる。
請求項１から請求項５のいずれか一項に記載のサーバであって、
前記送金することに関する処理は、前記第２情報に基づいて、前記第２口座から前記端末のユーザの第３口座に前記第２金額を送金する処理を行い、前記第３口座から前記第１口座に前記第２金額を送金する処理を含む。
請求項６に記載のサーバであって、
前記第３口座は、前記サーバによって管理される。
請求項６または請求項７に記載のサーバであって、
前記第２口座から前記端末のユーザの第３口座に前記第２金額を送金する処理は、前記第１口座の残高から前記第３口座にチャージする処理を含む。
請求項８に記載のサーバであって、
前記第３口座は、電子貨幣で前記第２金額がチャージされる。
請求項６から請求項９のいずれか一項に記載のサーバであって、
前記通信部は、前記第１情報を受信し、
前記制御部は、前記第１情報と前記第２情報とに基づいて、前記第１金額と前記第２金額とを含む金額を前記第１口座から支払うことに関する処理を行う。
請求項１０に記載のサーバであって、
前記後払いは、前記端末のユーザに関連するクレジットカードによって行われ、
前記第１口座から支払うことに関する処理は、前記クレジットカードの情報を管理する第１サーバに前記第１金額と前記第２金額とを含む金額の情報を前記通信部によって送信する処理を含む。
請求項１０に記載のサーバであって、
前記第１口座から支払うことに関する処理は、前記第１口座を管理する第２サーバに前記第１金額と前記第２金額とを含む金額の情報を前記通信部によって送信する処理を含む。
請求項１から請求項５のいずれか一項に記載のサーバであって、
前記送金することに関する処理は、前記第２金額の情報を、前記第１口座を管理する第２サーバに前記通信部によって送信する処理を含む。
請求項１３に記載のサーバであって、
前記通信部は、前記第１情報を受信し、
前記制御部は、前記第１情報と前記第２情報とに基づいて、前記第１金額と前記第２金額とを含む金額を前記第１口座から支払うことに関する処理を行う。
請求項１４に記載のサーバであって、
前記後払いは、前記端末のユーザに関連するクレジットカードによって行われ、
前記第１口座から支払うことに関する処理は、前記クレジットカードの情報を管理する第１サーバに前記第１金額と前記第２金額とを含む金額の情報を前記通信部によって送信する処理を含む。
請求項１４に記載のサーバであって、
前記第１口座から支払うことに関する処理は、前記第２サーバに前記第１金額と前記第２金額とを含む金額の情報を前記通信部によって送信する処理を含む。
端末と通信するサーバによって実行されるプログラムであって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記サーバの通信部によって受信することと、
前記購入情報のうち、前記端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、前記端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも前記第２情報を前記通信部によって受信することと、
前記第２情報に基づいて、前記第２口座から前記第１口座に前記第２金額を送金することに関する処理を前記サーバの制御部によって行うこととが前記サーバによって実行される。
端末と通信するサーバの情報処理方法であって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記サーバの通信部によって受信することと、
前記購入情報のうち、前記端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、前記端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも前記第２情報を前記通信部によって受信することと、
前記第２情報に基づいて、前記第２口座から前記第１口座に前記第２金額を送金することに関する処理を前記サーバの制御部によって行うこととを含む。
端末と通信するサーバであって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づいて処理を実行するプロセッサーを備え、
前記プロセッサーは、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記サーバの通信部によって受信することと、
前記購入情報のうち、前記端末のユーザに関連する第１口座によって支払う第１金額の情報を含む第１情報と、前記端末のユーザに関連する第２口座によって支払う第２金額の情報を含む第２情報とのうち、少なくとも前記第２情報を前記通信部によって受信することと、
前記第２情報に基づいて、前記第２口座から前記第１口座に前記第２金額を送金することに関する処理を行うこととを実行する。