特開 2024-103384 プログラム、情報処理方法、情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024103384

(43)【公開日】2024-08-01

(54)【発明の名称】プログラム、情報処理方法、情報処理装置

(51)【国際特許分類】

   G06Q 20/22 20120101AFI20240725BHJP

【ＦＩ】

G06Q20/22

【審査請求】未請求

【請求項の数】23

【出願形態】ＯＬ

(21)【出願番号】P 2023007674

(22)【出願日】2023-01-20

(71)【出願人】

【識別番号】500257300

【氏名又は名称】ＬＩＮＥヤフー株式会社

(74)【代理人】

【識別番号】110001759

【氏名又は名称】弁理士法人よつ葉国際特許事務所

(74)【代理人】

【識別番号】100093687

【弁理士】

【氏名又は名称】富崎 元成

(74)【代理人】

【識別番号】100168468

【弁理士】

【氏名又は名称】富崎 曜

(74)【代理人】

【識別番号】100166176

【弁理士】

【氏名又は名称】加美山 豊

(72)【発明者】

【氏名】真崎 洋輔

【テーマコード（参考）】

5L020

5L055

【Ｆターム（参考）】

5L020AA51

5L055AA51

(57)【要約】

【課題】後払いの支払い情報に基づく第２金額を確保等するための手法を提案する。
【解決手段】情報処理装置によって実行されるプログラムは、ユーザによって、後払いにより支払われる支払い情報と、ユーザに関するユーザ情報とを情報処理装置の制御部によって取得することと、ユーザ情報に基づいて、ユーザの口座に含まれる第１金額のうち、支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を情報処理装置の通信部によって送信することとが情報処理装置によって実行される。
【選択図】図１－１

【特許請求の範囲】

【請求項1】

情報処理装置によって実行されるプログラムであって、
ユーザによって、後払いにより支払われる支払い情報と、前記ユーザに関するユーザ情報とを前記情報処理装置の制御部によって取得することと、
前記ユーザ情報に基づいて、前記ユーザの口座に含まれる第１金額のうち、前記支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を前記情報処理装置の通信部によって送信することとが前記情報処理装置によって実行される。

【請求項2】

請求項１に記載のプログラムであって、
前記ユーザ情報は、前記ユーザを識別可能な情報を含む。

【請求項3】

請求項１または請求項２に記載のプログラムであって、
前記ユーザ情報は、前記口座を管理する金融機関に関する情報を含む。

【請求項4】

請求項３に記載のプログラムであって、
前記ユーザ情報は、前記口座に関する情報を含む。

【請求項5】

請求項１から請求項４のいずれか一項に記載のプログラムであって、
前記後払いは、前記ユーザに関連付けられたクレジットカードによる支払いを含む。

【請求項6】

請求項１から請求項５のいずれか一項に記載のプログラムであって、
前記第１設定は、前記ユーザによる、前記第２金額の使用に関する設定を含む。

【請求項7】

請求項１から請求項６のいずれか一項に記載のプログラムであって、
前記第１設定は、前記第２金額の使用をロックすることに関する設定を含む。

【請求項8】

請求項１から請求項７のいずれか一項に記載のプログラムであって、
前記第１制御情報は、設定された日にち、または日時に前記通信部によって送信される。

【請求項9】

請求項８に記載のプログラムであって、
前記支払い情報は、第１支払い情報であり、
前記ユーザによって、前記後払いによる第２支払い情報を前記制御部によって取得することと、
前記ユーザ情報に基づいて、前記ユーザの端末のユーザの口座に含まれる第１金額のうち、前記第１支払い情報と、前記第２支払い情報とに基づく第３金額に対して前記第１設定を行うための前記第１制御情報を前記情報処理装置の通信部によって送信することとが前記情報処理装置によって実行される。

【請求項10】

請求項１から請求項７のいずれか一項に記載のプログラムであって、
前記第１制御情報は、前記ユーザの第１入力に基づいて、前記通信部によって送信される。

【請求項11】

請求項１から請求項１０のいずれか一項に記載のプログラムであって、
設定された日にち、または日時以降に前記第１制御情報を送信可能に前記制御部によって制御することが前記情報処理装置によって実行される。

【請求項12】

請求項１から請求項１１のいずれか一項に記載のプログラムであって、
前記ユーザによって設定された第１条件を満たす前記支払い情報を前記制御部によって取得することが前記情報処理装置によって実行される。

【請求項13】

請求項１２に記載のプログラムであって、
前記ユーザによって設定された前記第１条件は、支払いの属性に関する設定を含む。

【請求項14】

請求項１３に記載のプログラムであって、
前記支払いの属性は、固定費および変動費を含む。

【請求項15】

請求項１から請求項１４のいずれか一項に記載のプログラムであって、
前記ユーザによる第２入力に基づいて、前記第２金額に対して前記第１設定とは異なる第２設定を行うための第２制御情報を前記通信部によって送信することが前記情報処理装置によって実行される。

【請求項16】

請求項１５に記載のプログラムであって、
前記第２設定は、前記第２金額を使用可能にする設定を含む。

【請求項17】

請求項１５または請求項１６のいずれか一項に記載のプログラムであって、
設定された第２条件を満たさない場合で、前記ユーザによって前記第２入力が行われた場合、前記第２制御情報を送信しない制御を前記制御部によって行うことが前記情報処理装置によって実行される。

【請求項18】

請求項１５から請求項１７のいずれか一項に記載のプログラムであって、
前記第２入力に基づいて、前記第２設定が行われた前記第２金額に関する情報を前記ユーザの端末に前記通信部によって送信することが前記情報処理装置によって実行される。

【請求項19】

請求項１から請求項１８のいずれか一項に記載のプログラムであって、
前記第１金額が前記第２金額よりも小さい金額の場合、前記口座の残高が足りないことを示す情報を前記ユーザの端末に送信する制御を前記制御部によって行うことが前記情報処理装置によって実行される。

【請求項20】

請求項１から請求項１９のいずれか一項に記載のプログラムであって、
前記口座に含まれる前記第１金額は、前記口座に含まれる金額が複数分割されたうちの一つの金額であり、
前記第１制御情報は、前記複数分割された前記第１金額のうちの前記第２金額を前記第１設定にするための情報を含む。

【請求項21】

請求項２０に記載のプログラムであって、
前記口座に含まれる前記第１金額は、前記口座に含まれる金額が、前記ユーザによってカテゴリごとに分割されたうちの一つの金額である。

【請求項22】

情報処理装置の情報処理方法であって、
ユーザによって、後払いにより支払われる支払い情報と、前記ユーザに関するユーザ情報とを前記情報処理装置の制御部によって取得することと、
前記ユーザ情報に基づいて、前記ユーザの口座に含まれる第１金額のうち、前記支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を前記情報処理装置の通信部によって送信することとを含む。

【請求項23】

情報処理装置であって、
ユーザによって、後払いにより支払われる支払い情報と、前記ユーザに関するユーザ情報とを取得する制御部と、
前記ユーザ情報に基づいて、前記ユーザの口座に含まれる第１金額のうち、前記支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信する通信部とを備える。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００２－１７６６７１号公報

【発明の概要】

【0004】

本発明の第１の態様によると、情報処理装置によって実行されるプログラムは、ユーザによって、後払いにより支払われる支払い情報と、ユーザに関するユーザ情報とを情報処理装置の制御部によって取得することと、ユーザ情報に基づいて、ユーザの口座に含まれる第１金額のうち、支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を情報処理装置の通信部によって送信することとが情報処理装置によって実行される。
本発明の第２の態様によると、情報処理装置の情報処理方法は、ユーザによって、後払いにより支払われる支払い情報と、ユーザに関するユーザ情報とを情報処理装置の制御部によって取得することと、ユーザ情報に基づいて、ユーザの口座に含まれる第１金額のうち、支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を情報処理装置の通信部によって送信することとを含む。
本発明の第３の態様によると、情報処理装置は、ユーザによって、後払いにより支払われる支払い情報と、ユーザに関するユーザ情報とを取得する制御部と、ユーザ情報に基づいて、ユーザの口座に含まれる第１金額のうち、支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信する通信部とを備える。

【図面の簡単な説明】

【0005】

【図1-1】実施例に係る通信システムの構成の一例を示す図。

【図1-2】実施例に係る家計管理サーバの制御部によって実現される機能の一例を示す図。

【図1-3】実施例に係る家計管理サーバの記憶部に記憶される情報等の一例を示す図。

【図1-4】実施例に係る家計管理ユーザ登録データのデータ構成の一例を示す図。

【図1-5】実施例に係る家計管理ユーザ管理データベースのデータ構成の一例を示す図。

【図1-6】実施例に係るクレジットカード会社サーバの制御部によって実現される機能の一例を示す図。

【図1-7】実施例に係るクレジットカード会社サーバの記憶部に記憶される情報等の一例を示す図。

【図1-8】実施例に係るクレジットカード決済ユーザ登録データのデータ構成の一例を示す図。

【図1-9】実施例に係る提携銀行データのデータ構成の一例を示す図。

【図1-10】実施例に係るクレジットカード決済ユーザ管理データベースのデータ構成の一例を示す図。

【図1-11】実施例に係る銀行サーバの制御部によって実現される機能の一例を示す図。

【図1-12】実施例に係る銀行サーバの記憶部に記憶される情報等の一例を示す図。

【図1-13】実施例に係る銀行口座ユーザ登録データのデータ構成の一例を示す図。

【図1-14】実施例に係る提携クレジットカード会社データのデータ構成の一例を示す図。

【図1-15】実施例に係る銀行口座ユーザ管理データベースのデータ構成の一例を示す図。

【図1-16】実施例に係る端末の制御部により実現される機能の一例を示す図。

【図1-17】実施例に係る端末の記憶部に記憶される情報の一例を示す図。

【図1-18】第１実施例に係る端末の表示画面の一例を示す図。

【図1-19】第１実施例に係る端末の表示画面の一例を示す図。

【図1-20】第１実施例に係る端末の表示画面の一例を示す図。

【図1-21】第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図1-22】第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図1-23】第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図1-24】第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図2-1】第２実施例に係る家計管理サーバの記憶部に記憶される情報等の一例を示す図。

【図2-2】第２実施例に係るロック要求情報送信条件データのデータ構成の一例を示す図。

【図2-3】第２実施例に係る端末の表示画面の一例を示す図。

【図2-4】第２実施例に係る端末の表示画面の一例を示す図。

【図2-5】第２実施例に係る端末の表示画面の一例を示す図。

【図2-6】第２実施例に係る端末の表示画面の一例を示す図。

【図2-7】第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図3-1】第３実施例に係るロック要求情報送信条件データのデータ構成の一例を示す図。

【図3-2】第３実施例に係る端末の表示画面の一例を示す図。

【図4-1】第４実施例に係る端末の表示画面の一例を示す図。

【図4-2】第４実施例に係る端末の表示画面の一例を示す図。

【図4-3】第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図4-4】第４変形例に係る家計管理サーバの記憶部に記憶される情報等の一例を示す図。

【図4-5】第４変形例に係るロック解除要求情報送信条件データのデータ構成の一例を示す図。

【図4-6】第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図5-1】第５実施例に係る端末の表示画面の一例を示す図。

【図5-2】第５変形例に係る端末の表示画面の一例を示す図。

【図6-1】第６実施例に係る銀行口座ユーザ管理データベースのデータ構成の一例を示す図。

【図6-2】第６実施例に係る端末の表示画面の一例を示す図。

【図6-3】第６実施例に係る端末の表示画面の一例を示す図。

【図6-4】第６実施例に係る端末の表示画面の一例を示す図。

【図7-1】第７実施例に係る口座開設パターンの一例を示す図。

【図7-2】第７実施例に係る銀行口座ユーザ管理データベースのデータ構成の一例を示す図。

【図7-3】第７実施例に係る端末の表示画面の一例を示す図。

【図7-4】第７実施例に係る端末の表示画面の一例を示す図。

【図7-5】第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図7-6】第７実施例に係る口座開設パターンの別例を示す図。

【図7-7】第７実施例に係る銀行口座ユーザ管理データベースのデータ構成の別例を示す図。

【図7-8】第７実施例に係る端末の表示画面の一例を示す図。

【図7-9】第７実施例に係る端末の表示画面の一例を示す図。

【図7-10】第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図7-11】第７実施例に係るクレジットカード決済ユーザ管理データベースのデータ構成の一例を示す図。

【図7-12】第７実施例に係る銀行口座ユーザ管理データベースのデータ構成の別例を示す図。

【図7-13】第７実施例に係る端末の表示画面の一例を示す図。

【図7-14】第７実施例に係る端末の表示画面の一例を示す図。

【図7-15】第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図8-1】第８実施例に係る口座開設パターンの一例を示す図。

【図8-2】第８実施例に係る口座開設パターンの一例を示す図。

【図8-3】第８実施例に係る端末の表示画面の一例を示す図。

【図8-4】第８実施例に係る端末の表示画面の一例を示す図。

【図8-5】第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図8-6】第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図8-7】第８実施例に係る端末の表示画面の一例を示す図。

【図8-8】第８実施例に係る端末の表示画面の一例を示す図。

【図8-9】第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図8-10】第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図9-1】第９実施例に係るクレジットカード決済ユーザ管理データのデータ構成の一例を示す図。

【図9-2】第９実施例に係る端末の表示画面の一例を示す図。

【図9-3】第９実施例に係る端末の表示画面の一例を示す図。

【図9-4】第９実施例に係る端末の表示画面の一例を示す図。

【図9-5】第９実施例に係る端末の表示画面の一例を示す図。

【図9-6】第９実施例に係る端末の表示画面の一例を示す図。

【図10-1】第１０実施例に係る銀行サーバの記憶部に記憶される情報等の一例を示す図。

【図10-2】第１０実施例に係る一括振替処理要求情報送信条件データのデータ構成の一例を示す図。

【図10-3】第１０実施例に係る端末の表示画面の一例を示す図。

【図10-4】第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【発明を実施するための形態】

【0006】

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

【0007】

＜実施形態＞
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。

【0008】

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

【0009】

本願請求項に係る発明の端末（本願発明の端末）の生産は、限定ではなく例として、ユーザが所有（所持）している端末で、本明細書に記載したプログラム（限定ではなく例として、アプリケーションプログラム）等が受信されることによって（または受信されて端末に記憶されることによって）、本端末において、本願請求項に係る発明の機能が実現可能となる状態が作り出される（本願請求項に係る発明が実行可能になる状態が作り出される）という概念を含んでもよい。

【0010】

また、本願請求項に係る発明のシステム（本願発明のシステム）の生産は、限定ではなく例として、本願システムに含まれるサーバから送信された本明細書に記載されたプログラム（限定ではなく例として、アプリケーションプログラム）等を、本願システムに含まれる端末で受信することによって（または受信されたプログラムが端末に記憶されることによって）、本願請求項に係るシステムの発明の機能が実現可能となる状態が作り出される（本願請求項に係る発明が実行可能になる状態が作り出される）という概念を含んでもよい。

【0011】

また、本明細書において、システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。

【0012】

また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

【0013】

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。

【0014】

サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。

【0015】

具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。

【0016】

また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。

【0017】

また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。

【0018】

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

【0019】

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

【0020】

また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。

【0021】

（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

以下の実施例では、ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例として、メッセージングサービス（Messaging Service）を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。

【0033】

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

【0034】

また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置（限定ではなく例として、端末）間で簡単なメッセージの送受信を行うインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。

【0035】

チャットルーム（限定ではなく例として、トークルーム）とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）とすることができる。

【0036】

また、トークルームには、１対１のユーザのトークルーム（以下、「１対１トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、ＯＡ事業者（限定ではなく例として、メッセージングサービスの事業者と提携する事業者）とのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

【0037】

また、メッセージングアプリケーションのアカウントであって、一般のユーザではない事業者のアカウントを「（ＯＡ（Official Account））」と称してもよく、この公式アカウントのユーザを「公式ユーザ」と称してもよい。なお、これを「公式アカウントユーザ」や「公式アカウント事業者」等のように称してもよい。
それに対し、メッセージングアプリケーションのアカウントであって、ＯＡ事業者ではないユーザのアカウントを「一般アカウント」と称し、一般アカウントのユーザを「一般ユーザ」と称する。なお、これを「一般アカウントユーザ」等のように称してもよい。
つまり、メッセージングアプリケーションのアカウントには、一般アカウントと公式アカウントとを含めてよいものとする。

【0038】

また、ＯＡ事業者も、限定ではなく例として、一般アカウントのユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でメッセージの送受信を行うことができるようにしてもよい。

【0039】

また、メッセージ（メッセージ情報）とは、限定ではなく例として、メッセージングサービスで用いられる送信元と送信先とが定められる情報であって、メッセージを識別するための識別情報（メッセージＩＤ）とメッセージコンテンツとで構成される情報としてもよい。
また、メッセージコンテンツとは、限定ではなく例として、メッセージＩＤを除くメッセージの中身を意味するものとしてもよい。メッセージコンテンツは、１または２以上のコンテンツとしてもよい。

【0040】

また、メッセージを識別するための識別情報として設定される情報を「メッセージＩＤ」と称する。
同じメッセージＩＤのメッセージに含まれるメッセージコンテンツは、このメッセージＩＤによって識別されると考えることもできる。よって、メッセージを識別するための識別情報は、メッセージコンテンツを識別するための識別情報と実質的に同義と考えることもできる。
なお、これとは異なり、メッセージコンテンツごとに個別の識別情報（メッセージコンテンツＩＤ）を設定するようにしてもよいし、そのようにしなくてもよい。

【0041】

コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、ＵＲＩ（ＵＲＬ等を含む。）などのリンクコンテンツを含めてもよいものとする。

【0042】

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

【0043】

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

【0044】

なお、上記の定義とは異なり、メッセージの上位概念がコンテンツである、またはコンテンツとメッセージとは同義である、と定義してもよいし、そのように定義しなくてもよい。

【0045】

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

【0046】

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

【0047】

この後払いには、限定ではなく例として、少なくとも以下のいずれかの支払い方法を含めてよい。
（１）クレジットカード決済
（２）ツケ払い
（３）電子マネーアプリケーションを用いた後払い

【0048】

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

【0049】

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

【0050】

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

【0051】

（３）電子マネーアプリケーションを用いた後払いは、限定ではなく例として、電子マネーによる支払いを行うことが可能な支払いアプリケーションを用いて、限定ではなく例として、事前の電子マネー口座への電子マネーのチャージを不要として支払いを行うことができ、利用金額が翌月等にまとめてユーザの口座から引き落とされるサービスとすることができる。

【0052】

また、本明細書では、端末のユーザにより、上記の後払いで購入された商品またはサービスの購入に関連する情報を「購入情報」と称する。「購入情報」は、商品またはサービスの購入となんらかの関係性を有する情報であればよく、少なくとも、ユーザによって後払いによって支払われる金額の情報（購入金額・利用金額の情報）が含まれるようにすることができる。

【0053】

なお、この他にも、購入情報には、以下の情報が含まれてもよい。
・後払いで商品またはサービスが購入されたことを示す情報
・後払いで購入された商品またはサービスの概要・細目（購入された商品やサービスの種類・種別を示す情報を含めてよい。）を示す情報
・後払いで商品またはサービスを購入したユーザに関する情報

【0054】

なお、端末が受信する購入情報と、クレジットカード会社のサーバや、後述する家計管理サービスのサーバ、メッセージングサービス・支払いサービス（決済サービス）のサーバ等のサーバで管理される購入情報とは、同じ情報としてもよいし、一部が異なる情報としてもよい。

【0055】

近年、家計を管理するためのサービス（以下、「家計管理サービス」と称する。）を用いた家計管理がユーザによって日常的に利用されている。
以下では、この家計管理サービスを実現するためのアプリケーションを「家計管理アプリケーション」と称する。

【0056】

「家計管理アプリケーション」では、限定ではなく例として、少なくとも以下のいずれかのサービスと連携して利用することができる。
（１）クレジットカード決済のサービス
（２）銀行口座のサービス

【0057】

（１）家計管理アプリケーションにおけるクレジットカード決済のサービスでは、限定ではなく例として、前述したクレジットカード決済の利用に関する情報を家計管理アプリケーションに連携して利用することができる。
これにより、家計管理アプリケーションにおいて、連携しているクレジットカードに対応したクレジットカード決済に関する情報（決済日時、決済金額、決済店舗など）を、ユーザが確認することができる。

【0058】

（２）家計管理アプリケーションにおける銀行口座のサービスでは、限定ではなく例として、銀行口座の入出金に関する情報や残高に関する情報を家計管理アプリケーションに連携して利用することができる。
これにより、家計管理アプリケーションにおいて、連携している銀行口座の入出金や残高に関する情報を、ユーザが確認することができる。

【0059】

このように、家計管理アプリケーションを用いることによって、クレジットカード決済に関するお金の動きや銀行口座に関するお金の動きを、一元化して管理することができる。

【0060】

以下の実施例の一部では、この家計管理サービスを用いた実施例を主として説明する。
なお、家計管理サービスを用いることは必須ではなく、これを用いないようにしてもよい。詳細は後述する。

【0061】

また、以下の実施例では、後払いとして、限定ではなく例として（１）クレジットカード決済を適用する場合を主として説明する。ただし、（２）ツケ払いや（３）電子マネーアプリを用いた後払い等についても同様の手法を適用可能である。

【0062】

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

【0063】

また、以下の実施例では、支払い口座から支払い金額を引き落とすことを「口座引き落とし」と称する場合がある。「口座振替」と称してもよい。

【0064】

また、以下の実施例では、クレジットカード決済の支払いを行う銀行口座を「支払い口座」と称する場合がある。
なお、支払い口座は、引き落とし口座や振替口座等と称してもよい。

【0065】

また、以下の実施例では、クレジットカード決済で取引された商品またはサービスを、「購入品」や「購入商品」等と称する場合がある。

【0066】

＜実施例＞
クレジットカード決済等の後払いによって商品やサービスを購入するユーザによっては、詳細は後述するが、そのクレジットカードに紐付けられた金融機関の口座からクレジットカード決済での利用金額が引き落とされるときに、金融機関の口座の残高が不足してしまい、クレジットカード決済での利用金額を引き落とせなくなる場合があり得る。
このようなことが発生しないよう、限定ではなく例として、クレジットカード決済での利用金額を金融機関の口座から引き落とす前に、クレジットカード決済での利用金額分に対応する金融機関の口座の残高をユーザが使用することが困難となるようにすることが考えられる。

【0067】

以下の実施例では、大きく分けて以下の２つの手法を例示する。
（Ａ）ユーザの口座に含まれる第１金額のうち、支払い情報（購入情報等）に基づく第２金額に対してロック設定等の設定を行うことによって、後払いの支払い金額をユーザが使用することを困難とする手法
（Ｂ）ユーザの第１口座に含まれる金額のうち、支払い情報に基づく第２金額を第１口座とは異なる第２口座に移動することによって、後払いの支払い金額をユーザが使用することを困難とする手法

【0068】

＜第１実施例＞
第１実施例は、上記（Ａ）の手法を適用した基本的な実施例である。
第１実施例では、クレジットカード決済において、支払い口座の残高のうち、クレジットカード決済の利用金額に対応する金額（商品やサービスの購入による購入金額に対応する金額等が含まれ得る。）をロックし、ユーザが残高のうちのその金額を使用することを困難とする。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0069】

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

【0070】

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

【0071】

なお、家計管理サービスのシステムには、限定ではなく例として、家計管理サービスの事業者がユーザの代わりに銀行口座（インターネットバンキング等）やクレジットカード会社のホームページにログインして明細を取得、表示等する構成要素が含まれてもよい。

【0072】

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

【0073】

本実施例では、「家計管理サービス」とは、家計管理サービスを提供する会社（家計管理サーバ１０）が提供するサービスであって、限定ではなく例として、ユーザ（ユーザの端末２０）、クレジットカード会社（クレジットカード会社サーバ５０）、銀行（銀行サーバ６０）に提供される。

【0074】

以下では、家計管理サービスが提携している銀行を「提携銀行」と称し、その提携銀行のうち端末２０のユーザによって家計管理サービスに連携された銀行を「連携銀行」と称する。また、家計管理サービスが提携しているクレジットカード会社を「提携クレジットカード会社」と称し、その提携クレジットカード会社のうち端末２０のユーザによって家計管理サービスに連携された銀行を「連携クレジットカード会社」と称する。

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（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（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

なお、店舗端末４０のＨＷ構成については、端末２０等と同様に構成してよいため、図示・説明を省略する。

【0120】

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

【0121】

（５）銀行サーバのＨＷ構成
銀行サーバ６０のＨＷ構成や、各機能部を構成する部品や回路等は、限定ではなく例として、家計管理サーバ１０等と同様に構成してよいため、図示・説明を省略する。

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

図１－３は、本実施例において家計管理サーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
記憶部１５には、限定ではなく例として、制御部１１によって読み出され、家計管理処理として実行される家計管理処理プログラム１５１と、家計管理ユーザ登録データ１５３と、家計管理ユーザ管理データベース１５５とが記憶される。

【0133】

家計管理ユーザ登録データ１５３は、家計管理サービスを利用する端末２０または端末２０のユーザの登録データであり、そのデータ構成の一例を図１－４に示す。
家計管理ユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、青瓜ケーションＩＤと、その他登録情報とが関連付けて記憶される。

【0134】

ユーザ名は、家計管理サービスを利用する端末２０のユーザの名称であり、限定ではなく例として、端末２０のユーザが家計管理サービスを利用する際に登録する名称が記憶される。

【0135】

アプリケーションＩＤは、家計管理サービスにおいてこのユーザを識別するための識別情報として機能するＩＤである。
この契約者ＩＤは、好ましくはユーザごとに一意な値であり、限定ではなく例として、家計管理サーバ１０によってユーザごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末のユーザに関連付けられた情報であり、端末のユーザに関する情報の一例である。

【0136】

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

【0137】

なお、アプリケーションＩＤに代えて、電話番号・メールアドレス等の情報によってユーザを管理する手法を適用することも可能である。

【0138】

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

【0139】

家計管理ユーザ管理データベース１５５は、家計管理ユーザ登録データ１５３に登録されているユーザに関する管理データを蓄積したデータベースであり、その一例である家計管理ユーザ管理データベース１５５のデータ構成の一例を図１－５に示す。
家計管理ユーザ管理データベース１５５には、家計管理ユーザ登録データ１５３に記憶されているアプリケーションＩＤごとの管理データとして家計管理ユーザ管理データが記憶される。

【0140】

各々の家計管理ユーザ管理データには、限定ではなく例として、アプリケーションＩＤと、ユーザ名と、その他情報と、連携クレジットカード管理データと、連携銀行口座管理データと、取引管理データと、入出金管理データとが記憶される。

【0141】

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

【0142】

連携クレジットカード管理データは、このアプリケーションＩＤのユーザによって連携されたクレジットカードに関するデータであり、限定ではなく例として、クレジットカードＩＤと、クレジットカード会社名と、クレジットカード番号とが関連付けて記憶される。

【0143】

クレジットカードＩＤは、このアプリケーションＩＤのユーザによって連携されたクレジットカードを識別するためのＩＤであり、好ましくはクレジットカードごとに一意な値が設定されて記憶される。

【0144】

クレジットカード会社名は、このクレジットカードＩＤに対応するクレジットカードの事業者名である。
なお、クレジット会社名には、限定ではなく例として、クレジットカード会社を識別するためのＩＤ（以下、適宜「ＣＣＩＤ」と称する。）が割り当てられており、このＣＣＩＤは、好ましくはクレジットカード会社ごとに一意な値が設定されて記憶される。

【0145】

クレジットカード番号は、このアプリケーションＩＤのユーザによって連携されたクレジットカードを識別するための番号であり、好ましくはクレジットカードごとに一意な番号が設定されて記憶される。

【0146】

なお、ここでは、連携クレジットカード管理データに、クレジットカードＩＤと、クレジットカード番号とが記憶される例を示したが、これに限定されない。
連携クレジットカード管理データに、限定ではなく例として、クレジットカードＩＤと、クレジットカード番号との少なくともいずれか一方が記憶されるようにしてもよい。

【0147】

連携銀行口座管理データは、このアプリケーションＩＤのユーザによって連携された銀行口座に関するデータであり、限定ではなく例として、銀行口座ＩＤと、銀行名と、銀行口座番号とが関連付けて記憶される。

【0148】

銀行口座ＩＤは、このアプリケーションＩＤのユーザによって連携された銀行口座を識別するためのＩＤであり、好ましくは銀行口座ごとに一意な値が設定されて記憶される。

【0149】

銀行名は、この銀行口座ＩＤに対応する銀行の名称である。
なお、銀行名には、限定ではなく例として、銀行を識別するためのＩＤ（以下、適宜「銀行ＩＤ」と称する。）が割り当てられており、この銀行ＩＤは、好ましくは銀行ごとに一意な値が設定されて記憶される。

【0150】

銀行口座番号は、このアプリケーションＩＤのユーザによって連携された銀行口座を識別するための番号であり、銀行口座ごとに一意な番号が設定されて記憶される。

【0151】

銀行名（銀行ＩＤ）や銀行口座番号は、限定ではなく例として、端末２０のユーザによる入力に基づいて端末２０からその情報が送信され、これを受信して取得することによって記憶されるようにしてもよい。
また、クレジットカード会社サーバ５０からこの情報が送信され、これを受信して取得するようにしてもよい。

【0152】

なお、ここでは、連携銀行口座管理データに、銀行口座ＩＤと、銀行口座番号とが記憶される例を示したが、これに限定されない。
連携銀行口座管理データに、限定ではなく例として、銀行口座ＩＤと、銀行口座番号との少なくともいずれか一方が記憶されるようにしてもよい。

【0153】

取引管理データは、このアプリケーションＩＤのユーザが連携したクレジットカードを用いた取引に関するデータであり、限定ではなく例として、取引ＩＤと、店舗ＩＤと、購入情報とが関連付けて記憶される。

【0154】

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

【0155】

店舗ＩＤには、提携店舗データ（不図示）に記憶された店舗ＩＤのうち、この取引ＩＤの取引が行われた店舗に対応する店舗ＩＤが記憶される。

【0156】

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

【0157】

なお、家計管理サーバ１０がクレジットカード決済の取引についてクレジットカード会社サーバ５０から取得可能な情報には、限定ではなく例として、購入日時、購入店舗、購入金額の情報が含まれ得るが、購入された商品やサービスに関する情報は含まれない場合がある。
しかし、購入された商品やサービスに関する情報、限定ではなく例として、購入された商品やサービスの名称、購入数等の情報を店舗端末４０から取得可能とし、これらの情報も併せて購入情報として取得して記憶させるようにしてもよい。また、クレジットカード会社サーバ５０からこれらの情報も併せて購入情報として取得して記憶させるようにしてもよい。

【0158】

入出金管理データは、このアプリケーションＩＤのユーザが連携した銀行口座においてなされた入出金に関するデータであり、限定ではなく例として、入出金ＩＤと、入出金情報とが関連付けて記憶される。

【0159】

取引ＩＤは、このアプリケーションＩＤのユーザが連携した銀行口座の入出金を識別するためのＩＤであり、好ましくは入出金ごとに一意な値が設定されて記憶される。

【0160】

入出金情報は、その銀行口座での入金・出金に関する情報であり、限定ではなく例として、入出金日時、入出金の内容、入出金金額等の情報が記憶される。

【0161】

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

【0162】

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

【0163】

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

【0164】

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

【0165】

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

【0166】

なお、限定ではなく例として、一のクレジットカード会社において、契約者１人につき１枚のみクレジットカードを利用可能であるものとしてもよい。
この場合、契約者を識別するためのＩＤである契約者ＩＤをそのまま、契約者のクレジットカードを識別するための識別情報として機能するクレジットカードＩＤとして利用してもよい。

【0167】

また、限定ではなく例として、一のクレジットカード会社において、契約者１人につき複数枚のクレジットカードを利用可能であるものとしてもよい。
この場合、一の契約者ＩＤに対して複数のクレジットカードＩＤが登録されるようにしてもよい。

【0168】

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

【0169】

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

【0170】

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

【0171】

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

【0172】

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

【0173】

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

【0174】

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

【0175】

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

【0176】

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

【0177】

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

【0178】

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

【0179】

クレジットカード決済ユーザ管理データベース５５９は、クレジットカード決済ユーザ登録データ５５３に登録されているユーザに関する管理データを蓄積したデータベースであり、その一例であるクレジットカード決済ユーザ管理データベース５５９のデータ構成の一例を図１－１０に示す。
クレジットカード決済ユーザ管理データベース５５９には、限定ではなく例として、クレジットカード決済ユーザ登録データ５５３に記憶されている契約者ＩＤごとの管理データとしてクレジットカード決済ユーザ管理データが記憶される。

【0180】

各々のクレジットカード決済ユーザ管理データには、限定ではなく例として、契約者ＩＤと、取引管理データと、登録銀行口座管理データとが記憶される。

【0181】

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

【0182】

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

【0183】

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

【0184】

購入情報は、その取引での商品またはサービスの購入に関する情報であり、限定ではなく例として、購入日時、購入店舗、購入金額等の情報が記憶される。
なお、前述したように、クレジットカード会社サーバ５０がクレジットカード決済の取引について店舗から取得可能な情報に、購入日時、購入店舗、購入金額等の情報の他、限定ではなく例として、購入された商品やサービスに関する情報を含めてもよい。この情報は、限定ではなく例として、店舗端末４０から取得可能としてよい。

【0185】

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

【0186】

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

【0187】

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

【0188】

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

【0189】

口座引き落としトークンは、限定ではなく例として、対応する銀行口座ＩＤの銀行口座について、この銀行口座を管理する提携銀行の銀行サーバ６０によって発行される認証用の情報（データ）とすることができる。
本実施例において、家計管理サーバ１０は、銀行サーバ６０から与えられた口座引き落としトークンによって、そのアプリケーションＩＤのユーザの口座残高の情報等の情報を取得したり、口座引き落としを依頼する処理等の処理を、銀行サーバ６０との間で行うようにすることができる。

【0190】

なお、口座引き落としトークンは、引き落としトークンやアクセストークン等のように表現してもよい。

【0191】

クレジットカード会社サーバ５０は、限定ではなく例として、あらかじめ銀行サーバ６０によって発行されて銀行サーバ６０から通知された口座引き落としトークンと、口座引き落としを要求・依頼する金額（以下、「振替要求金額」と称する。）とに基づいて、この銀行口座ＩＤによって識別される銀行口座による口座引き落としを銀行サーバ６０に要求・依頼するようにすることができる。

【0192】

（３）銀行サーバの機能構成
図１－１１は、本実施例において銀行サーバ６０の制御部６１（図１－１では図示を省略）によって実現される機能の一例を示す図である。
制御部６１は、限定ではなく例として、記憶部６５に記憶された銀行口座入出金管理処理プログラム６５１に従って銀行口座入出金管理処理を実行するための銀行口座入出金管理処理部６１１を機能部として含む。

【0193】

図１－１２は、本実施例において銀行サーバ６０の記憶部６５（図１－１では図示を省略）に記憶される情報等の一例を示す図である。
記憶部６５には、限定ではなく例として、制御部６１によって読み出され、銀行口座入出金管理処理として実行される銀行口座入出金管理処理プログラム６５１と、銀行口座ユーザ登録データ６５３と、提携クレジットカード会社データ６５５と、銀行口座ユーザ管理データベース６５９とが記憶される。

【0194】

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

【0195】

契約者氏名は、銀行口座サービスを利用する端末２０のユーザの氏名であり、限定ではなく例として、端末２０のユーザが銀行口座を利用する際に登録する氏名が記憶される。

【0196】

契約者ＩＤは、銀行口座サービスを利用するユーザを識別するための識別情報として機能するＩＤである。
この契約者ＩＤは、好ましくはユーザごとに一意な値であり、限定ではなく例として、銀行サーバ６０によってユーザごとに一意な値（固有の値）が設定されて記憶される。
契約者ＩＤは、端末のユーザに関連付けられた情報であり、端末のユーザに関する情報の一例である。

【0197】

限定ではなく例として、一の銀行において、契約者１人につき１つのみの銀行口座を利用可能であるものとしてもよい。
この場合、契約者を識別するためのＩＤである契約者ＩＤをそのまま、契約者の銀行口座を識別するための識別情報として機能する銀行口座ＩＤとして利用してもよい。

【0198】

また、限定ではなく例として、一の銀行において、契約者１人につき複数個の銀行口座を利用可能であるものとしてもよい。
この場合、一の契約者ＩＤに対して複数個の銀行口座ＩＤが登録されるようにしてもよい。

【0199】

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

【0200】

銀行口座情報は、この契約者ＩＤのユーザの銀行口座に関する情報であり、限定ではなく例として、銀行口座番号、支店名、支店番号等の情報がこれに含まれる。

【0201】

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

【0202】

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

【0203】

また、上記の各種のユーザ情報は、銀行サーバ６０が提供可能な他のサービスと銀行口座サービスとで共通のユーザ情報として銀行サーバ６０で記憶・管理するようにしてもよいし、別のユーザ情報として銀行サーバ６０で記憶・管理するようにしてもよい。

【0204】

提携クレジットカード会社データ６５５は、提携クレジットカード会社の管理データであり、そのデータ構成の一例を図１－１４に示す。
提携クレジットカード会社データ６５５には、限定ではなく例として、提携クレジットカード会社名と、提携クレジットカード会社ＩＤと、提携クレジットカード会社サーバＵＲＩと、その他登録情報とが関連付けて記憶される。

【0205】

提携クレジットカード会社名には、この提携クレジットカード会社の名称（限定ではなく例として、提携クレジットカード会社の商号、愛称または通称等）が記憶される。

【0206】

提携クレジットカード会社ＩＤ（ＣＣＩＤ）は、提携クレジットカード会社またはクレジットカード会社サーバ５０を識別するための識別情報として機能するＩＤである。

【0207】

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

【0208】

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

【0209】

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

【0210】

各々の銀行口座ユーザ管理データには、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとが記憶される。

【0211】

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

【0212】

前述したように、クレジットカードＩＤは、この契約者ＩＤのユーザのクレジットカードを識別するための情報である。
このクレジットカードＩＤによって、この契約者ＩＤのユーザの銀行口座と紐づけられたクレジットカードが特定される。

【0213】

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

【0214】

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

【0215】

銀行口座入出金管理データは、この契約者ＩＤのユーザの銀行口座の入出金に関するデータであり、限定ではなく例として、残高と、ロック合計金額と、利用可能残高と、日時と、取引内容と、入出金金額等が記憶される。

【0216】

残高は、この契約者ＩＤのユーザの銀行口座の残高に関する情報であり、限定ではなく例として、銀行口座の残高金額が記憶される。

【0217】

ロック合計金額は、限定ではなく例として、この契約者ＩＤのユーザの銀行口座の残高のうちロックされている金額を合計した金額である。

【0218】

利用可能残高は、この契約者ＩＤのユーザの銀行口座の残高のうち利用可能な金額に関する情報であり、限定ではなく例として、残高からロック金額を引いた金額が記憶される。

【0219】

本実施例では、１つの手法として、銀行口座の残高のうちロックされた金額は、銀行口座の契約者が使用することができないようにすることができる。

【0220】

しかし、ロックされた金額を契約者が使用することができるようにしてもよく、この場合、限定ではなく例として、残高のうちロックされていない金額を使用するときよりも困難な条件を設定することによって、銀行口座の残高のうちロックされた金額を使用することはできるものの、ロックされた金額を使用することに関して制限を課すようにしてもよい。

【0221】

（Ａ）ロックされていない残高を使用するときの条件
（Ｂ）ロックされている残高を使用するときの条件
との組合せとして、限定ではなく例として、以下のいずれかの組合せを適用してよい。
「（Ａ）一段階認証、（Ｂ）多段階認証」
「（Ａ）日時制限なし、（Ｂ）日時制限あり」
「（Ａ）手数料なし、（Ｂ）手数料あり」

【0222】

「（Ａ）一段階認証、（Ｂ）多段階認証」とは、限定ではなく例として、（Ａ）ロックされていない残高を利用するときは、銀行サーバ６０から要求される認証は１回である一方で、限定ではなく例として、（Ｂ）ロックされている残高を利用するときは、銀行サーバ６０から要求される認証は２回以上であるという条件の組合せとしてもよい。多要素認証としてもよい。

【0223】

「（Ａ）日時制限なし、（Ｂ）日時制限あり」とは、限定ではなく例として、（Ａ）ロックされていない残高を利用するときは、３６５日２４時間受け付け可能である一方で、限定ではなく例として、（Ｂ）ロックされている残高を利用するときは、平日の９～１７時の期間のみ受け付け可能であるという条件の組合せとしてもよい。

【0224】

「（Ａ）手数料なし、（Ｂ）手数料あり」とは、限定ではなく例として、（Ａ）ロックされていない残高を利用するときは、銀行から請求される手数料が無料である一方で、限定ではなく例として、（Ｂ）ロックされている残高を利用するときは、銀行から請求される手数料が有料（限定ではなく例として、３００円）であるという条件の組合せとしてもよい。

【0225】

日時は、この契約者ＩＤのユーザの銀行口座の入出金の日時に関する情報であり、限定ではなく例として、「年／月／日」等が記憶される。

【0226】

取引内容は、この契約者ＩＤのユーザの銀行口座の入出金の取引内容に関する情報であり、限定ではなく例として、入出金の詳細な内容に関する情報等が記憶される。

【0227】

入出金金額は、この契約者ＩＤのユーザの銀行口座の入出金の金額に関する情報であり、限定ではなく例として、入出金の金額に関する情報等が記憶される。

【0228】

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

【0229】

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

【0230】

図１－１７は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、端末メイン処理として実行される端末メイン処理プログラム２８１が記憶される。
なお、図示は省略するが、記憶部２８には、限定ではなく例として、制御部２１によって読み出され、各種のアプリケーションについて、そのアプリケーション処理を実行するためのアプリケーション処理プログラムや、そのアプリケーションに関するデータが記憶されるようにすることができる。

【0231】

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

【0232】

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

【0233】

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

【0234】

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

【0235】

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

【0236】

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

【0237】

なお、与信照会処理を実行したクレジットカード会社サーバ５０は、与信照会の結果の情報を店舗端末４０に送信するようにしているが、これに限定されない。
与信照会の結果の情報を、端末２０、店舗端末４０、家計管理サーバ１０のうち少なくともいずれか一つに送信してもよい。

【0238】

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

【0239】

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

【0240】

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

【0241】

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

【0242】

これを受けて、（８）銀行サーバ６０は、振替要求金額の口座引き落としを行い、振替要求金額をクレジットカード会社に支払う。

【0243】

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

【0244】

なお、以下説明する表示画面に示される日付や金額、履歴等は、データ構成の項目で説明するデータ中に示されるものとは必ずしも整合しておらず、あくまで表示画面の一例（表示画面例）に過ぎない。
これは、他の実施例や変形例についても同様である。

【0245】

また、以下説明する表示画面で用いる用語と、その後に説明する処理で用いる用語とで、用語が異なる場合がある（一部の用語が統一されていない場合がある）が、これは、ユーザの視点で表示画面について分かり易く説明するなどの目的であり便宜上のものに過ぎない。
これは、他の実施例や変形例についても同様である。

【0246】

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

【0247】

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

【0248】

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

【0249】

なお、１つの図面内、または複数の図面を跨いで、異なる端末２０で表示される所定の画面を示して、画面の遷移の流れを説明する場合がある。この場合、限定ではなく例として、異なる端末２０では、以下のうちの少なくともいずれかに基づいて（少なくともいずれかを契機として）、所定の画面が表示されることとしてもよいものとする。
・自動的に表示される
・端末２０に対してなんらかの通知（プッシュ通知等を含む。以下同様。）が行われ、ユーザが通知に対する操作を行うと表示される
・端末２０に対して通知は行われないが、ユーザがアプリケーションに対して所定の操作を行うと表示される
・端末２０に対してなんらかの通知が行われ、ユーザが通知を行ったアプリケーションに対して所定の操作を行うと表示される

【0250】

図１－１８は、本実施例において端末２０Ａ（ユーザＡ．Ａの端末２０）の表示部２４に表示される画面の一例を示す図である。
図１－１８左側には、端末２０Ａで不図示の家計管理アプリケーション処理プログラムが実行されることで表示される家計管理アプリケーションにおけるメイン画面の一例を示している。
画面最上部には、家計管理アプリケーションの名称（この例では「家計管理Ａｐｐ」）と、その右側に、ユーザのアイコン画像（この例ではユーザＡ．Ａのアイコン画像）およびユーザ名（この例ではユーザＡ．Ａ）を含むアプリ情報表示領域が構成されている。

【0251】

その下には、ユーザが各種の項目を選択するための、複数の項目を含むタブ領域が構成されている。
タブ領域には、限定ではなく例として、「カード」（クレジットカード等を含む。）、「銀行」、「おしらせ」、「設定」等の複数の項目を含めてよい。

【0252】

この例では、ユーザＡ．Ａによって項目「カード」がタッチ（タップとしてもよい。以下同様。）されて選択されたことに基づき、タブ領域のうち、「カード」の項目に対応する領域が、選択された態様（以下、「選択態様」と称する。）で表示されている。

【0253】

また、ユーザＡ．Ａによって項目「カード」がタッチされて選択されたことに基づき、タブ領域の下に、ユーザＡ．Ａが登録済みのカードに関する情報であるカード情報が表示されている。
ここでは、ユーザＡ．Ａが、クレジットカード会社名「Ｘカード」のクレジットカード「Ｘカード」を登録済みであることに基づき、「Ｘカード」のカード情報が表示されている。また、この例では、カード情報には、限定ではなく例として、クレジットカード会社名（括弧書きで、家計管理アプリケーションにおけるカードＩＤ（ＣＣＩＤ））と、このカードの当月利用額の情報とが含まれている。

【0254】

限定ではなく例として、この「Ｘカード」のカード情報がユーザによってタッチされて選択されると、限定ではなく例として、図１－１８右側の画面に表示が変わる。
この画面は、選択されたカードに関するより詳細な情報が表示されるカード画面であり、画面最上部のアプリケーションの名称等を含む領域の下には、１つ前の画面（この例では図１－１８左側の画面）に戻るための「＜」のボタンと、「カード」のテキストとを含む領域が構成されている。

【0255】

その下には、カード情報表示領域が構成されており、この例では、「Ｘカード」を模したクレジットカード画像が表示されている。
クレジットカード画像には、限定ではなく例として、このクレジットカードの名称「Ｘカード」や、クレジットカード番号等の情報が印字されている。

【0256】

なお、クレジットカード番号は、限定ではなく例として下三桁や下四桁など、設定された桁の番号のみを示し、他の桁の番号は「＊」等によって秘匿するようにしてもよい。
また、クレジットカード番号そのものを印字しないようにしてもよい。
また、クレジットカード画像そのものを表示しないようにしてもよい。

【0257】

また、この例では、カード画像の右に、このカードに関する各種の設定を行うための設定アイコンＩＣ３が表示されている。
この設定アイコンＩＣ３については後述する。

【0258】

また、この例では、カード画像の下に、このカードのショッピングやキャッシングの利用可能残額の情報が表示されている。

【0259】

また、この例では、利用可能残額の情報の下に、このカードの利用履歴（利用履歴情報）が表示されている。
この例では、「利用履歴」のテキストとともに、ユーザＡ．Ａが「Ｘカード」を用いてクレジットカード決済をした、利用履歴（利用履歴情報）ＵＨ１を含む複数の利用履歴（利用履歴情報）が表示されている。

【0260】

また、この例では、各々の利用履歴には、その利用履歴の利用金額のロックの状態（ロック済／ロック）を示すロックアイコンＩＣ１が表示されるように構成されている。
ロックアイコンＩＣ１は、限定ではなく例として、南京錠を模した画像のアイコン（南京錠のアイコン）とされている。ロックアイコンＩＣ１は、限定ではなく例として、ロック済である場合は南京錠が施錠された態様で表示され、未ロックである場合は南京錠が開錠された状態で表示されるように構成されている。なお、これはあくまで一例に過ぎず、これに限定されるものではない。
この例では、利用履歴ＵＨ１に関連付けられたロックアイコンＩＣ１は、ロック済みであることにより施錠された態様で表示されている。

【0261】

図１－１９左側には、図１－１８左側の画面において、タブ領域のうちの「銀行」がユーザＡ．Ａによってタッチされて選択されたことに基づいて表示される画面の一例を示している。
タブ領域のうち、「銀行」の項目に対応する領域が選択態様で表示されており、タブ領域の下には、ユーザＡ．Ａが登録済みの銀行口座に関する口座情報が表示されている。

【0262】

ここでは、ユーザＡ．Ａが、銀行名「Ａ銀行」等の銀行の銀行口座を登録済みであることに基づき、この銀行口座の情報である口座情報が表示されている。また、この例では、口座情報には、限定ではなく例として、銀行名（括弧書きで、家計管理アプリケーションにおける銀行ＩＤ）と、この銀行口座の口座番号と、この銀行口座の口座残高（残高）の情報とが含まれている。

【0263】

限定ではなく例として、「Ａ銀行」の口座情報がユーザによってタッチされて選択されると、限定ではなく例として、図１－１９中央の画面に表示が変わる。
この画面は、この口座に関するより詳細な情報が表示される口座画面であり、画面最上部のアプリ情報表示領域の下には、１つ前の画面（この例では図１－１９左側の画面）に戻るための「＜」のボタンと、「銀行」のテキストとを含む領域が構成されている。

【0264】

その下には、口座情報表示領域が構成されており、この例では、この銀行口座のキャッシュカードを模したキャッシュカード画像が表示されている。
キャッシュカード画像には、限定ではなく例として、銀行名（この例では「Ａ銀行」）行」）、口座番号等の情報が印字されている。

【0265】

なお、口座番号は、下三桁や下四桁など、設定された桁の番号のみを示し、他の桁の番号は「＊」等で示して秘匿するようにしてもよい。
また、口座番号そのものを印字しないようにしてもよい。
また、キャッシュカード画像そのものを表示しないようにしてもよい。

【0266】

また、この例では、キャッシュカード画像の下に、口座残高に占めるロック金額の割合を示すための横長の帯グラフが表示されている。
この帯グラフは、限定ではなく例として、横幅全長が口座残高を示しており、左端を起点としてハッチングが施された部分的な領域（部分領域）が、ロック金額に対応する領域（以下、便宜的に「ロック領域」と称する。）ＬＲとして示されている。ロック領域ＬＲの横幅は、口座残高に占めるロック金額の割合に基づいて算出される。以下、帯グラフのうちロック領域ＬＲ以外の領域を、便宜的に「非ロック領域」と称し、この例では、ロック領域ＬＲの右に非ロック領域ＮＬＲが表示されている。
また、この例では、帯グラフの右下の位置に、口座残高が表示されている。

【0267】

なお、ロック領域ＬＲに、ロック金額の情報（金額の数値の情報）が表示されるようにしてもよい。また、非ロック領域ＮＬＲに、非ロック金額の情報（金額の数値の情報）が表示されるようにしてもよい。
また、ロック領域ＬＲがユーザによってタッチされると、このロック領域ＬＲと関連付けて、吹き出しやバブル等によってロック金額の数値が表示されるようにしてもよい。また、非ロック領域ＮＬＲがユーザによってタッチされると、この非ロック領域ＮＬＲと関連付けて、吹き出しやバブル等によって非ロック金額の数値が表示されるようにしてもよい。長押し操作等によって、これらの情報を表示させることができるようにしてもよい。

【0268】

その下には、この銀行口座の取引履歴（取引履歴情報）が表示されている。具体的には、限定ではなく例として、「取引履歴」のテキストとともに、ユーザＡ．Ａがこの口座で取引を行った複数の取引履歴が表示されている。
この例では、取引履歴は、限定ではなく例として、この口座から取引が行われた日付と、その取引の内容（取引内容）と、入出金金額とが関連付けられたリスト形式で表示されている。なお、日付は日時としてもよい。

【0269】

また、取引履歴のうち、この口座に紐づけられたクレジットカード決済による取引に基づき利用金額がロックされた取引については、取引内容の欄に「ロック」と表示され、その横に、前述したロックアイコンＩＣ１が表示されるように構成されている。
また、取引履歴の入出金金額の欄では、入金は「＋」付きの金額で表示され、出金は「－」付きの金額で表示され、ロックはそのままの金額が表示されている。

【0270】

この例では、取引履歴のうち「２０２２年１月６日」の「２０，０００円」の金額がロックされたことが示されている。

【0271】

限定ではなく例として、帯グラフのロック領域ＬＲがタッチされると、限定ではなく例として、図１－１９右側のような表示に変わる。
この例では、取引履歴のうち、取引内容が「ロック」とされているレコード（行）が、タッチされたロック領域ＬＲと同じハッチングが施されて表示されている。
このようにすることで、ユーザは、帯グラフのロック領域ＬＲと、取引履歴の取引との対応関係を一見して把握可能となる。

【0272】

同じカードで複数回の決済が行われて、各々の金額がロックされることが想定される。
この場合、帯グラフのロック領域ＬＲは、限定ではなく例として、口座残高に対する、各々のロック金額を合算した金額が占める割合に基づく、１つのハッチングが施された領域としてもよい。
また、この場合、ロック領域ＬＲがタッチされると、限定ではなく例として、取引履歴のうち、各々の取引に対応する欄が、そのハッチングが施された態様で表示されるようにしてもよい。

【0273】

なお、ここではハッチングで示しているが、これを色で示すようにしてもよい。
また、上記のように同じカードで複数回の決済が行われた場合において、帯グラフと取引履歴とにおいて、それぞれ異なるハッチングやそれぞれ異なる色で、対応する帯グラフの領域や、対応する取引履歴のレコードを表示させるようにしてもよい。

【0274】

図１－２０は、図１－１９に対応する画面であって、ユーザＡ．Ａが複数のクレジットカードを登録している場合の画面の一例を示す図である。
ここでは、限定ではなく例として、ユーザＡ．Ａが、「Ｘカード」と「Ｙカード」の２枚のクレジットカードを登録しており、どちらのクレジットカードも、上記の「Ａ銀行」の同じ口座に紐づけられている場合を例示する。

【0275】

図１－２０左側には、図１－１９と同様の構成の画面が示されているが、帯グラフにおいて、ロック領域ＬＲとして、「Ｘカード」に対応する第１ロック領域ＬＲ１と、「Ｙカード」に対応する第２ロック領域ＬＲ２との、２つのロック領域が構成されている。また、第１ロック領域ＬＲ１と、第２ロック領域ＬＲ２とは、それぞれ異なるハッチングが施されて表示されている。
また、取引履歴には、「Ｘカード」の取引情報の他、「Ｙカード」の取引情報が含まれている。

【0276】

限定ではなく例として、図１－２０中央の画面のように、第２ロック領域ＬＲ２がユーザによってタッチされると、限定ではなく例として、図１－２０右側のような表示に変わる。
この例では、取引履歴のうち、取引内容が「ロック」とされているレコードのうち、「Ｙカード」で決済が行われた取引のレコードが、第２ロック領域ＬＲ２と同じハッチングが施されて表示されている。
このようにすることで、同じ口座に紐づけて複数のカードを登録している場合であっても、ユーザは、各々のカードについて、帯グラフのロック領域ＬＲと、取引履歴の取引との対応関係を一見して把握可能となる。

【0277】

なお、同じカードで複数回の決済が行われて、各々の金額がロックされることが想定されるが、この場合、前述した手法と同様の手法を適用してよい。
また、異なる複数のハッチングではなく、異なる複数の色を用いるようにしてもよい。

【0278】

＜（１）第１パターン＞
（１）第１パターンとして、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、店舗端末４０（限定ではなく例として、店舗サーバ）によって家計管理サーバ１０に送信され、そのクレジットカード決済に対応する金額をロックするように要求する情報が、家計管理サーバ１０によって銀行サーバ６０に送信されることによって、クレジットカード決済に対応する金額がロックされる場合の処理を例示する。
この場合、限定ではなく例として、家計管理サービスの事業者およびクレジット会社と提携している店舗において、ユーザによってクレジットカード決済が行われた場合、その店舗の店舗端末４０は、クレジットカード会社サーバ５０と家計管理サーバ１０とに対して、購入情報を送信するようにすることができる。この場合、限定ではなく例として、クレジットカード決済に関する処理において、クレジットカード会社サーバ５０は、与信照会結果の情報を含む与信照会結果情報として、限定ではなく例として、与信照会の結果に関する情報の他に、その決済に対応するクレジットカードのクレジットカードＩＤ等の情報を含む与信紹介結果情報を店舗端末４０に送信するなどすることができる。

【0279】

＜処理＞
図１－２１→図１－２２は、本実施例の（１）第１パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
図１－２１では、左側から順に、店舗端末４０の制御部（不図示）が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、銀行サーバ６０の制御部６１が実行する処理をそれぞれ示している。
また、図１－２２では、左側から順に、店舗端末４０の制御部が実行する処理、ユーザＡ．Ａの端末２０の制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、銀行サーバ６０の制御部６１が実行する処理をそれぞれ示している。

【0280】

なお、図１－２１では、主に店舗端末４０とクレジットカード会社サーバ５０とで行われるクレジットカード決済に関する処理を示しており、端末２０の制御部２１が実行する処理に関しては図示を省略する。

【0281】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、店舗端末４０によって家計管理サーバ１０に送信され、そのクレジットカード決済に対応する金額をロックするように要求する情報が、家計管理サーバ１０によって銀行サーバ６０に送信されることによって、クレジットカード決済に対応する金額がロックされる場合を例示する。

【0282】

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

【0283】

最初に、店舗端末４０の制御部は、限定ではなく例として、ユーザＡ．Ａによってクレジットカード決済の手続きが行われたか否かを判定する（Ｔ１０１０）。
ユーザＡ．Ａによってクレジットカード決済の手続きが行われていないと判定する場合（Ｔ１０１０：ＮＯ）、店舗端末４０の制御部は、限定ではなく例として、Ｔ１０２０のステップをスキップする。

【0284】

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

【0285】

クレジットカード会社サーバ５０の制御部５１は、通信Ｉ／Ｆ（不図示）によって店舗端末４０から与信照会要求情報を受信したか否かを判定する（Ｃ１０１０）。
通信Ｉ／Ｆによって店舗端末４０から与信照会要求情報を受信しなかったと判定する場合（Ｃ１０１０：ＮＯ）、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、Ｃ１０２０～Ｃ１０３０のステップをスキップする。

【0286】

通信Ｉ／Ｆによって店舗端末４０から与信照会要求情報を受信したと判定する場合（Ｃ１０１０：ＹＥＳ）、クレジットカード会社サーバ５０の制御部５１は、与信照会処理を実行する（Ｃ１０２０）。
与信照会処理において、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、クレジットカード決済ユーザ登録データ５５３を参照し、受信したクレジットカード情報に対応する契約者ＩＤを特定し、クレジットカード決済ユーザ管理データベース５５９に記憶されるクレジットカード決済ユーザ管理データのうち、特定した契約者ＩＤに対応するクレジットカード決済ユーザ管理データに基づいて、与信照会処理プログラムに従って、与信照会を行う。このとき、クレジットカード決済ユーザ管理データベース５５９に記憶されるクレジットカード決済ユーザ管理データのうち、特定した契約者ＩＤに対応するクレジットカード決済ユーザ管理データの取引管理データに、受信した取引に関する情報を記憶させる。

【0287】

そして、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、与信照会結果の情報を含む与信照会結果情報を、通信Ｉ／Ｆによって店舗端末４０に送信する（Ｃ１０３０）。この与信照会結果情報には、限定ではなく例として、与信照会の結果に関する情報の他に、その決済に対応するクレジットカードのクレジットカードＩＤに関する情報も含めてよい。

【0288】

店舗端末４０の制御部は、通信Ｉ／Ｆによってクレジットカード会社サーバ５０から与信照会結果情報を受信したか否かを判定する（Ｔ１０３０）。
通信Ｉ／Ｆによってクレジットカード会社サーバ５０から与信照会結果情報を受信しなかったと判定する場合（Ｔ１０３０：ＮＯ）、店舗端末４０の制御部は、限定ではなく例として、Ｔ１０４０のステップをスキップする。

【0289】

通信Ｉ／Ｆによってクレジットカード会社サーバ５０から与信照会結果情報を受信したと判定する場合（Ｔ１０３０：ＹＥＳ）、店舗端末４０の制御部は、限定ではなく例として、受信した与信照会結果情報に基づいて、与信照会結果を表示部（不図示）に表示させる（Ｔ１０４０）。

【0290】

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

【0291】

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

【0292】

店舗端末４０の制御部は、通信Ｉ／Ｆによってクレジットカード会社サーバ５０から受信した与信照会結果情報に基づいて、与信照会結果が承認であったか否かを判定する（Ｔ１０５０）。
与信照会結果が承認ではない（非承認である）と判定する場合（Ｔ１０５０：ＮＯ）、店舗端末４０の制御部は、限定ではなく例として、Ｔ１０６０のステップをスキップし、処理を終了する。

【0293】

与信照会結果が承認であると判定する場合（Ｔ１０５０：ＹＥＳ）、店舗端末４０の制御部は、限定ではなく例として、与信照会結果情報に含まれるクレジットカードＩＤに関する情報と、購入金額の請求に関する情報（限定ではなく例として、購入者情報（クレジットカードＩＤ等）、商品購入情報、レシート情報、取引データ（取引ＩＤ、店舗ＩＤ等））等を含む購入情報を、通信Ｉ／Ｆによって家計管理サーバ１０（およびクレジットカード会社サーバ５０）に送信する（Ｔ１０６０）。

【0294】

家計管理サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって購入情報を受信したか否かを判定する（Ｓ１０１０）。
購入情報を受信しなかったと判定する場合（Ｓ１０１０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ１０２０のステップをスキップする。

【0295】

購入情報を受信したと判定する場合（Ｓ１０１０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ユーザＡ．ＡのアプリケーションＩＤが記憶された家計管理ユーザ管理データに含まれる連携クレジットカード管理データや連携銀行口座管理データ、それらが紐づけられたデータ等の各種のデータに基づいて、限定ではなく例として、クレジットカードＩＤに紐づけられた銀行の銀行名（銀行口座ＩＤ）と銀行口座番号とを特定する。そして、特定した銀行名（銀行ＩＤ）に基づき、ユーザＡ．Ａの銀行口座の口座残高に対応する金額（限定ではなく、第１金額の一例）のうち、購入情報に基づくクレジットカード決済の利用金額に対応する金額（限定ではなく、第２金額の一例）をロック要求金額とし、限定ではなく例として、特定した銀行口座番号の情報と、ロック要求金額の情報とを含み、その銀行口座番号の銀行口座の口座残高のうち、ロック要求金額をロックするように要求するロック要求情報を、通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する（Ｓ１０２０）。

【0296】

銀行サーバ６０の制御部（不図示）は、通信Ｉ／Ｆ（不図示）によって家計管理サーバ１０からロック要求情報を受信したか否かを判定する（Ｂ１０１０）。
通信Ｉ／Ｆによって家計管理サーバ１０からロック要求情報を受信しなかったと判定する場合（Ｂ１０１０：ＮＯ）、銀行サーバ６０の制御部は、限定ではなく例として、Ｂ１０２０～Ｂ１０３０のステップをスキップする。

【0297】

通信Ｉ／Ｆによって家計管理サーバ１０からロック要求情報を受信したと判定する場合（Ｂ１０１０：ＹＥＳ）、銀行サーバ６０の制御部は、ロック処理（ロック設定）を実行する（Ｂ１０２０）。
ロック処理において、銀行サーバ６０の制御部は、限定ではなく例として、受信したロック要求情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データのロック金額のデータに、受信したロック要求金額を記憶させる。

【0298】

なお、限定ではなく例として、１人につき１つの口座しか所有することのできない銀行（金融機関）であれば、銀行口座番号を送信せずとも、ユーザの契約者氏名や連絡先情報等の情報を送信することによって、銀行サーバ６０はユーザの口座を特定可能となる。
このため、ロック要求情報には、必ずしも銀行口座番号を含めなくてもよい。

【0299】

次いで、銀行サーバ６０の制御部は、限定ではなく例として、ロック処理の結果に関する情報を含むロック結果情報を、通信Ｉ／Ｆによって家計管理サーバ１０に送信する（Ｂ１０３０）。

【0300】

家計管理サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって銀行サーバ６０からロック結果情報を受信したか否かを判定する（Ｓ１０３０）。
通信Ｉ／Ｆ１４によって銀行サーバ６０からロック結果情報を受信しなかったと判定する場合（Ｓ１０３０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ１０４０のステップをスキップする。

【0301】

通信Ｉ／Ｆ１４によって銀行サーバ６０からロック結果情報を受信したと判定する場合（Ｓ１０３０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、銀行サーバ６０から受信したロック結果情報と同様のロック結果情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｓ１０４０）。

【0302】

端末２０の制御部２１は、通信Ｉ／Ｆ２２によって家計管理サーバ１０からロック結果情報を受信したか否かを判定する（Ａ１０１０）。
通信Ｉ／Ｆ２２によって家計管理サーバ１０からロック結果情報を受信しなかったと判定する場合（Ａ１０１０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ１０２０のステップをスキップする。

【0303】

通信Ｉ／Ｆ２２によって家計管理サーバ１０からロック結果情報を受信したと判定する場合（Ａ１０１０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、受信したロック結果情報に基づいて、ロック結果を表示部２４に表示させる（Ａ１０２０）。

【0304】

＜（２）第２パターン＞
（２）第２パターンとして、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０によって家計管理サーバ１０に送信され、そのクレジットカード決済に対応する金額をロックするように要求する情報が、家計管理サーバ１０によって銀行サーバ６０に送信されることによって、クレジットカード決済に対応する金額がロックされる場合の処理を例示する。

【0305】

＜処理＞
図１－２３は、本実施例の（２）第２パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートであり、図１－２１に続く部分を示したものである（図１－２１→図１－２３）。
この図では、左側から順に、ユーザＡ．Ａの端末２０の制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、銀行サーバ６０の制御部６１が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図１－２２と同様である部分についての説明を省略する。

【0306】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０によって家計管理サーバ１０に送信され、そのクレジットカード決済に対応する金額をロックするように要求する情報が、家計管理サーバ１０によって銀行サーバ６０に送信されることによって、クレジットカード決済に対応する金額がロックされる場合を例示する。

【0307】

Ｃ１０１０：ＮＯ、または、Ｃ１０３０のステップの後、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、与信照会結果情報に基づいて、与信照会結果が承認であったか否かを判定する（Ｃ１０４０）。
与信照会結果が承認でないと判定する場合（Ｃ１０４０：ＮＯ）、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、Ｃ１０５０のステップをスキップし、処理を終了する。

【0308】

与信照会結果が承認であると判定する場合（Ｃ１０４０：ＹＥＳ）、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、与信照会結果情報に含まれるクレジットカードＩＤに関する情報と、購入金額の請求に関する情報（限定ではなく例として、購入者情報（クレジットカードＩＤ）、商品購入情報、レシート情報、取引データ（取引ＩＤ、店舗ＩＤ等））等を含む購入情報を、通信Ｉ／Ｆによって家計管理サーバ１０に送信する（Ｃ１０５０）。

【0309】

＜第１金額、第２金額について＞
上記の処理では、ユーザの銀行口座の残高に対応する金額、つまり、ユーザの銀行口座の残高全部を第１金額とし、そのうち、後払いによる利用金額に対応する金額（限定ではなく、第２金額の一例）に対してロック設定を行うこととした。

【0310】

しかし、これに限定されるものではなく、第１金額を、ユーザの銀行口座の残高のうちの一部の金額に対応する金額としてもよい。この場合、限定ではなく例として、ユーザの銀行口座の残高に対応する金額を複数分割し、複数分割された金額のうちの一つの金額を第１金額として、上記と同様の処理を行うようにしてもよい。つまり、第１金額は、ユーザの口座に含まれる金額であればよい。

【0311】

この場合、限定ではなく例として、ユーザの端末２０に対する入力に基づいて、限定ではなく例として、家計管理サーバ１０または銀行サーバ６０が金額を複数分割し、そのうちの一つの金額を対象として、上記と同様の処理を行うようにしてもよい。ただし、ユーザの銀行口座が複数に分割されるわけではなく、あくまでその銀行口座の管理データにおいて、複数分割された金額に関するデータが記憶されて管理されるようにしてよい。

【0312】

また、同様に、第２金額を、利用金額のうちの一部の金額に対応する金額としてもよい。つまり、第２金額は、支払い情報に基づく金額であればよい。
この場合、限定ではなく例として、ユーザの端末２０に対する入力に基づいて、限定ではなく例として、家計管理サーバ１０によって第２金額とする金額が設定され、その金額の情報を含むロック要求情報が、家計管理サーバ１０から銀行サーバ６０に送信されるようにすることができる。

【0313】

＜第１実施例の効果＞
本実施例は、家計管理サーバ１０（限定ではなく、情報処理装置の一例）が、ユーザによるクレジットカード決済等の後払いにより支払われる少なくとも金額の情報を含む支払い情報（限定ではなく、ユーザによって、後払いにより支払われる支払い情報の一例）と、そのユーザが所有する口座を管理する金融機関の情報や口座番号等の情報（限定ではなく、ユーザに関するユーザ情報の一例）とを制御部１１によって取得する。そして、家計管理サーバ１０は、取得したユーザ情報に基づいて、そのユーザの銀行等の金融機関の口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対して、限定ではなく例としてロック設定（限定ではなく、第１設定の一例）を行うためのロック要求情報等の情報（限定ではなく、第１制御情報の一例）を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによって、後払いにより支払われる支払い情報と、そのユーザに関するユーザ情報とを取得した上で、取得したユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報が送信されることによって、支払い情報に基づく第２金額に対して第１設定を行わせることができる。

【0314】

また、本実施例は、ユーザ情報は、ユーザを識別可能な情報を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザを識別可能な情報を含むユーザ情報を取得した上で、ユーザを識別可能な情報に基づいて、第１制御情報を送信することができる。

【0315】

また、本実施例は、ユーザ情報は、口座を管理する金融機関に関する情報を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、口座を管理する金融機関に関する情報を含むユーザ情報を取得した上で、口座を管理する金融機関に関する情報に基づいて、第１制御情報を送信することができる。

【0316】

また、この場合、ユーザ情報は、その金融機関のそのユーザの口座番号等の情報（限定ではなく、口座に関する情報の一例）を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、金融機関におけるユーザの口座に関する情報を含むユーザ情報を取得した上で、金融機関におけるユーザの口座に関する情報に基づいて、第１制御情報を送信することができる。

【0317】

また、本実施例は、後払いは、ユーザに関連付けられたクレジットカードによる支払いを含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザに関連付けられたクレジットカードにより支払われる支払い情報と、上記のユーザ情報とを取得した上で、ユーザ情報に基づいて、第１制御情報を送信することができる。つまり、クレジットカードによる支払いを対象として、ユーザの口座に含まれる第１金額のうち、支払い情報に基づく第２金額に対して第１設定を行わせることができる。

【0318】

また、本実施例は、第１設定は、ユーザによる、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）をロックすることによって、ユーザが使用できなくなるようにする設定（限定ではなく、第２金額の使用に関する設定の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによる、第２金額の使用に関する設定を行わせることができ、ユーザによる第２金額の使用を制限するなどすることができる。

【0319】

また、本実施例は、第１設定は、第２金額の使用をロックすることに関するロック設定を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２金額の使用をロックすることに関する設定を行わせることができ、ユーザが第２金額を使用できないようにするなどすることができる。

【0320】

なお、ロック金額の一部をユーザが使用することができないようにするのであれば、ロック設定は、上記のユーザによる第２金額の使用に関する設定のうち、ユーザによる第２金額の使用の制限に関する設定と捉えてもよい。ロック金額の全部をユーザが使用することができないようにするのであれば、ロック設定は、上記のユーザによる第２金額の使用に関する設定のうち、ユーザによる第２金額の使用の禁止に関する設定と捉えてもよい
また、前述したようにロック金額をユーザが使用できるように構成してもよく、この場合、ロック設定は、上記のユーザによる第２金額の使用に関する設定のうち、ユーザによる第２金額の使用の許可に関する設定と捉えてもよい。

【0321】

また、本実施例は、ユーザの口座に含まれる金額（限定ではなく、第１金額の一例）は、口座に含まれる金額が複数分割されたうちの一つの金額であり、ロック要求情報等の情報（限定ではなく、第１制御情報の一例）は、複数分割された口座に含まれる金額（限定ではなく、第１金額の一例）のうちの支払い情報に基づく金額（限定ではなく、第２金額の一例）をロック設定にするための情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザの口座に含まれる金額が複数分割されたうちの一つの金額を第１金額とし、この第１金額のうちの第２金額を第１設定にさせることができる。

【0322】

また、本実施例は、銀行サーバ６０（限定ではなく、情報処理装置の一例）が、前述した支払い情報と、前述したユーザ情報とを制御部６１によって取得する。
そして、銀行サーバ６０は、取得したユーザ情報に基づいて、ユーザの銀行等の金融機関の口座（限定ではなく、ユーザの口座、ユーザの第１口座の一例）に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対して、限定ではなく例としてロック設定（限定ではなく、第１設定の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、取得されたユーザ情報に基づいて、ユーザの口座（第１口座）に含まれる第１金額のうち、取得された支払い情報に基づく第２金額に対して第１設定を行うことができる。

【0323】

＜第１変形例（１）＞
上記の実施例では、家計管理サーバ１０が銀行サーバ６０に対してロック設定を要求することとしたが、これに限定されない。
限定ではなく例として、クレジットカード会社サーバ５０が銀行サーバ６０に対してロック設定を要求するようにしてもよい。

【0324】

図１－２４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１－２１に続く部分を示したものである（図１－２１→図１－２４）。ただし、図１－２１の家計管理サーバ１０の処理は不要としてよい。

【0325】

Ｃ１０４０：ＹＥＳと判定したならば、クレジットカード会社サーバ５０の制御部５１は、ユーザ情報に基づいて、ロック要求情報を通信Ｉ／Ｆによって銀行サーバ６０に送信する（Ｃ１０６０）。

【0326】

Ｂ１０３０において銀行サーバ６０の制御部６１は、ロック結果情報を通信Ｉ／Ｆ１４によってクレジットカード会社サーバ５０に送信する。

【0327】

通信Ｉ／Ｆによって銀行サーバ６０からロック結果情報を受信すると（Ｃ１０７０：ＹＥＳ）、クレジットカード会社サーバ５０の制御部５１は、そのロック結果情報を通信Ｉ／Ｆによって端末２０Ａに送信する（Ｃ１０８０）。

【0328】

なお、ロック結果情報が、銀行サーバ６０から端末２０Ａに対して送信されるようにしてもよい。

【0329】

また、この他にも、限定ではなく例として、端末２０Ａから銀行サーバ６０に対してロック設定要求情報を送信するようにしてもよい。

【0330】

＜第１変形例（２）＞
上記の実施例や変形例では、銀行サーバ６０等の金融機関のサーバに、ユーザの口座残高に対して取得した支払い情報に基づく金額をロックする設定を行うように要求される場合を示したが、これに限定されない。
限定ではなく例として、ユーザの端末２０にダウンロードされて使用されるアプリケーションであって、電子マネーによる決済を行う支払いアプリケーション（決済アプリケーション）を用いて、取得した支払い情報に基づく金額に対応する電子マネーをプール（蓄える、ためる）処理を行うなどしてもよい。
支払いアプリケーションでは、支払いサービスのサーバによって、ユーザが保有する電子マネーが、電子マネー口座のデータに記憶されて管理されるようにすることができる。

【0331】

この場合、限定ではなく例として、家計管理サーバ１０の制御部１１が、取得した支払い情報に基づく金額をプールするように要求する情報を、通信Ｉ／Ｆ１４によって支払いサービスのサーバに送信する。そして、支払いサービスのサーバの制御部は、ユーザの電子マネー口座から、受信した情報に含まれる金額分の電子マネーを、そのユーザの電子マネー口座から減算し、その電子マネー口座に関連付けられた、そのユーザのプール用の電子マネー口座（以下、「プール用電子マネー口座」と称する。）に加算するようにしてもよい。
この場合、支払いサービスのサーバは、限定ではなく例として、プール用電子マネー口座に記憶された電子マネー残高は、支払いアプリケーションを用いた支払い（決済）で用いないようにすることができる。

【0332】

なお、一般的には電子マネーを法定通貨に変換することができない場合が多い可能性があるが、ユーザは、必要に応じて、支払いアプリケーションを用いて自身の電子マネー口座から電子マネー決済をすることで、クレジットカード決済での支払い分の法定通貨を使用しないように自身で調整することができる。

【0333】

＜第１変形例（３）＞
上記の実施例では、家計管理サーバ１０が、ユーザ情報と、購入情報とに基づいて、ロック設定を行う場合の処理を示した。また、ユーザ情報には、前述したように、下記に例示する情報を含めてよいこととした。
・ユーザの契約者氏名の情報、連絡先情報
・ユーザが口座を所有する金融機関の情報（銀行ＩＤ等）
・ユーザが所有する金融機関の口座の情報（銀行口座ＩＤ等）（金融機関の情報も実質的に含まれる。）

【0334】

しかし、これに限定されるものではなく、家計管理サーバ１０が、限定ではなく例として、家計管理アプリケーションでユーザ認証を行った後に取得される口座引き落としトークン（前述）等の情報と、購入情報とに基づいて、ロック設定を行うようにしてもよい。

【0335】

この場合、限定ではなく例として、家計管理サーバ１０の記憶部１５に記憶される家計管理ユーザ管理データベース１５５の家計管理ユーザ管理データ（限定ではなく例として図１－５）に記憶される連携銀行口座管理データに、クレジットカード決済ユーザ管理データベース５５９のクレジットカード決済管理データ（図１－１０）に記憶される登録銀行口座管理データと同様に、銀行口座ＩＤと、口座引き落としトークンとを関連付けて記憶させるようにしてもよい。

【0336】

家計管理サーバ１０は、限定ではなく例として、家計管理アプリケーションにおけるユーザ認証の認証結果が「ＯＫ」となり、家計管理アプリケーションでの銀行口座やクレジットカードの登録が完了した後、銀行サーバ６０から口座引き落としトークンを取得し、銀行口座ＩＤと関連付けて記憶させるようにすることができる。
なお、家計管理サーバ１０が口座引き落としトークンをクレジットカード会社サーバ５０から取得するようにしてもよい。

【0337】

この場合、家計管理サーバ１０の制御部１１は、限定ではなく例として図１－２２や図１－２３の処理のＳ１０２０のステップにおいて、口座引き落としトークンを含むロック要求情報を、通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する。そして、銀行サーバ６０の制御部６１は、受信した口座引き落としトークンに基づいて、ロック処理（ロック設定）を行うようにすることができる。

【0338】

また、家計管理サーバ１０が、限定ではなく例として、取得したユーザの認証に関する情報と、取得した支払い情報とに基づいて、ロック設定を行わせるようにしてもよい。

【0339】

限定ではなく例として、同じ事業者によって、家計管理サービスと、銀行サービスとが提供される場合があり得る。限定ではなく例として、ある事業者が、家計管理サービスと、インターネット銀行等の銀行サービスとを提供するような場合があり得る。

【0340】

この場合、事業者のサーバとして、１または複数のサーバを構成し、上記と同様の処理を行うようにすることができる。
また、家計管理サービスと銀行サービスとを連携させ、これらのサービス（アプリケーション）で用いられるユーザ情報として共通の情報を用いるようにしてもよい。そして、この場合、ユーザ情報として、共通の情報を用いるようにしてもよい。

【0341】

この場合におけるユーザ情報として、限定ではなく例として、アカウント情報等のユーザの認証情報（個人認証情報）を用いるようにしてもよい。
そして、家計管理サーバ１０は、個人認証情報をロック要求情報に含めて、その事業者の銀行サーバ６０に送信するようにしてもよい。

【0342】

なお、このようなユーザの認証に関する情報は、ユーザを識別可能な情報の一種としてもよい。
また、前述した口座引き落としトークン等の情報も、ユーザを識別可能な情報の一種としてもよい。

【0343】

＜第１変形例（４）
本発明における後払いにより支払われる支払い情報には、支払い金額として、限定ではなく例として、ユーザがクレジットカードを用いる場合における、クレジットカード会社が提供するショッピング枠に含まれる割賦枠（分割払いやリボ払い等）の金額やキャッシング枠の金額が含まれてもよい。

【0344】

＜第２実施例＞
第２実施例は、クレジットカード決済の利用金額に対応する金額をロックするときの条件のうち日時に関する条件が設定される実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0345】

本実施例では、ロック対象金額をロックする条件（以下、適宜「ロック条件」と称する。）として、限定ではなく例として、以下のような日時に関する条件が設定されるようにすることができる。
“ＣＴ”：日時に関するロック条件

【0346】

このロック条件には、限定ではなく例として、さらに詳細なロック条件が設定されるようにしてよく、その詳細なロック条件を以下に例示する。

【0347】

「“ＣＴ”：日時に関するロック条件」とは、限定ではなく例として、クレジットカード決済による取引が行われた日時（取引日時）に関する条件としてよく、限定ではなく例として、以下のいずれかの条件を含めてよい。
「“ＣＴ０１”：取引日時が直近の給料振込日から次の給料振込日３日前になるまでの期間（以下、適宜「Ｔ１」と称する。）であった場合」
「“ＣＴ０２”：取引日時がＴ１以外の期間（以下、適宜「Ｔ２」と称する。）であり、現在日時が特定日時（特定日でもよい。以下同様。）となった場合」

【0348】

＜データ構成＞
図２－１は、本実施例において家計管理サーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
このデータ構成では、前述した図１－７と同様の部分についての説明を省略する。
本実施例において、記憶部１５には、限定ではなく例として、家計管理処理プログラム１５１と、家計管理ユーザ登録データ１５３と、家計管理ユーザ管理データベース１５５とに加えて、限定ではなく例として、ロック要求情報送信条件データ１５７が記憶される。

【0349】

ロック要求情報送信条件データ１５７は、ロック要求情報送信条件が設定されたデータであり、その一例であるロック要求情報送信条件データ１５７Ａのデータ構成例を図２－２に示す。
ロック要求情報送信条件は、限定ではなく例として、家計管理サーバ１０が銀行サーバ６０に対してロック要求情報を送信するための条件であり、前述したロック条件を具体化したものと捉えてもよい。

【0350】

ロック要求情報送信条件データ１５７Ａには、限定ではなく例として、条件Ｎｏと、ロック要求送信条件とが関連付けて記憶される。

【0351】

ここでは、限定ではなく例として、ユーザの給料振込日が毎月「２５日」であり、クレジットカードが「月末締め」（月末が締め日）であり、クレジットカードの口座引き落とし日が「翌月の１０日」である場合を例示する。
ただし、これはあくまでも一例に過ぎず、これに限定されるものではない。

【0352】

条件Ｎｏには、ロック要求情報送信条件に対応した番号（条件の識別情報）が設定される。
条件Ｎｏは、好ましくはロック要求情報送信条件ごとに一意な値であり、限定ではなく例として、家計管理サーバ１０によってロック要求情報送信条件ごとに一意な値（固有の値）が設定されて記憶される。

【0353】

本例では、条件Ｎｏ「ＣＴ０１」：「取引日時がＴ１であった場合」の条件が設定されている。
「Ｔ１」は、限定ではなく例として、ユーザの直近の給料振込日（前月２５日０時００分）から次の給料振込日３日前（今月２２日０時００分）になるまでの期間とすることができる。
なお、「３日前」はあくまで一例に過ぎず、「１日前」や「２日前」等としてもよい。また、日を設定するのではなく、時間（Ｘ時間前）を設定するようにしてもよい。

【0354】

「取引日時がＴ１であった場合」とは、クレジットカード決済の取引がＴ１の期間に行われた場合とすることができる。この場合、家計管理サーバ１０は、限定ではなく例として、クレジットカード決済の取引がＴ１の期間に行われた場合、クレジットカード会社サーバ５０からその取引の購入情報を受信したタイミングで、即時にロック要求情報を銀行サーバ６０に送信するようにすることができる。
より具体的には、家計管理サーバ１０の制御部１１は、クレジットカード会社サーバ５０から受信した購入情報に含まれる購入日時（取引日時）に基づき、購入日時が、Ｔ１の期間に含まれると判定すると、ロック要求情報を銀行サーバ６０に送信するようにすることができる。

【0355】

条件Ｎｏ「ＣＴ０２」：「取引日時がＴ２であり、現在日時が特定日時となった場合」の条件が定められている。
「Ｔ２」は、限定ではなく例として、上記Ｔ１以外の期間（限定ではなく例として、ユーザの次の給料振込日３日前（今月２２日０時００分）から次の給料振込日（今月２５日０時００分）になるまでの期間）とすることができる。

【0356】

「取引日時がＴ２であり、現在日時が特定日時となった場合」とは、クレジットカード決済の取引がＴ２の期間に行われた場合であって、このデータを参照する処理（後述する図２－７のＳ２０３０のステップ）を行っているタイミングが特定日時（限定ではなく例として、給料振込日の翌日０時００分、クレジットカードの口座引き落とし日の前日０時００分等）となった場合とすることができる。この場合、家計管理サーバ１０は、限定ではなく例として、クレジットカード決済の取引がＴ２の期間に行われた場合、クレジットカード会社サーバ５０からその取引の購入情報を受信したタイミングとは異なるタイミングで（時間差を設けて）、ロック要求情報を銀行サーバ６０に送信するようにすることができる。

【0357】

なお、「０時００分」は「日にち」（特定日）を表すものとし、特定日の「０時００分」以外の時刻を「特定日時」と言ってもよい。限定ではなく例として、特定日の「３：００」、「６：００」、「９：００」、「１２：００」、「１５：００」、「１８：００」、「２１：００」といった時刻を特定日時としてもよい。

【0358】

より具体的には、家計管理サーバ１０の制御部１１は、クレジットカード会社サーバ５０から受信した購入情報に含まれる購入日時（取引日時）に基づき、購入日時が、Ｔ２の期間に含まれると判定すると、すぐにロック要求情報を銀行サーバ６０に送信するのではなく、その後、現在日時が特定日時となったタイミングで、ロック要求情報を銀行サーバ６０に送信するようにすることができる。

【0359】

これらの条件は、限定ではなく例として、ユーザの行為に基づいて設定される（ユーザの端末２０で設定される、ユーザの端末２０から設定情報が送信されて家計管理サーバ１０で設定される）ようにしてよい。便宜的に、この設定を「手動設定」と称する場合がある。
具体的には、ユーザが端末２０で家計管理アプリケーションを起動して条件の設定入力を行い、その設定情報が家計管理サーバ１０に送信されて、ロック要求情報送信条件データ１５７Ａに記憶されるようにしてもよい。

【0360】

なお、ユーザによる設定入力を不要とし、これらの条件が家計管理サーバ１０（または家計管理サーバ１０のユーザ）によって設定されるようにしてもよい。便宜的に、この設定を「自動設定」と称する場合がある。

【0361】

また、手動設定で条件が設定される場合、ロック要求情報送信条件データは、ユーザと関連付けて記憶される、限定ではなく例として、家計管理ユーザ管理データベース１５５のうち、そのユーザのアプリケーションＩＤが記憶された家計管理ユーザ管理データに記憶されるようにしてもよい。

【0362】

＜表示画面＞
図２－３～図２－６は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図２－３左側には、図１－１８中央と同様の画面が表示されており、この例では、設定アイコンＩＣ３がユーザによってタッチされた状態が示されている。すると、限定ではなく例として、図２－３中央のような画面に表示が変わる。
この画面は、カードに関する設定を行うためのカード設定画面の一例であり、この例では、設定の項目として、「ロックに関する設定」と、「その他の設定」とをそれぞれ選択可能に表示されている。

【0363】

限定ではなく例として、「ロックに関する設定」の表示領域がユーザによってタッチされると、限定ではなく例として、図２－３右側のような表示に変わる。
この例では、「ロックに関する設定」のうちのより詳細の設定の項目として、限定ではなく例として、「ロック日に関する設定」と、「ロック項目に関する設定」とをそれぞれ選択可能に構成されている。

【0364】

限定ではなく例として、「ロック日に関する設定」の表示領域がユーザによってタッチされると、限定ではなく例として、図２－４左側のような表示に変わる。
この例では、ロック日を変える日付を指定するようユーザに促すテキスト（この例では「ロック日を変える日付を指定してください」）が画面上部に表示されている。その下には、限定ではなく例として、日付をカレンダー上で指定するためのカレンダー（この例では「２０２２年１月のカレンダー」）が表示されている。

【0365】

また、カレンダーの日付のうち、限定ではなく例として、本日（この例では「２０２２年１月２０日」）と、このクレジットカード（この例では「Ｘカード」）の締め日（この例では月末である「２０２２年１月３１日」）と、ユーザＡ．Ａの給料日（この例では「２０２２年１月２５日」）とに、それぞれ印が付されて表示されている。給料日は、ユーザの給料が振り込まれる日にちである。給料日は、限定ではなく例として、ユーザが家計管理アプリケーションにあらかじめ登録しておくなどすることができる。
また、限定ではなく例として、カレンダーの右下の位置には、これらの印のインデックスが表示されている。

【0366】

限定ではなく例として、カレンダー上で、ユーザＡ．Ａによって「２０２２年１月２２日」と、「２０２２年１月２３日」と、「２０２２年１月２４日」との３つの日付がタッチされると、限定ではなく例として、図２－４中央のように、指定された３つの日付が第１指定態様（この例では上向き角丸の矩形の印が付された態様）で表示される。

【0367】

この状態で、画面下部に表示された「決定」ボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図２－４右側のような表示に変わる。
具体的には、ロックする日を指定するようユーザに促すテキスト（この例では「ロック日を指定してください」）が表示されている。他の表示は、図２－４中央と同様である。

【0368】

限定ではなく例として、カレンダー上で、ユーザＡ．Ａによって「２０２２年１月２６日」の日付がタッチされると、限定ではなく例として、図２－５左側のように、指定された日付が第２指定態様（この例では下向き角丸の矩形の印が付された態様）で表示される。

【0369】

この状態で、画面下部に表示された「決定」ボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図２－５中央のような表示に変わる。
この例では、この内容で設定することをユーザに確認するテキスト（この例では「これで設定してよろしいですか？」）のテキストが表示されている。他の表示は、図２－５左側と同様である。

【0370】

この状態で、画面下部に表示された「ＯＫ」ボタンＢＴ３がユーザによってタッチされると、限定ではなく例として、図２－５右側のような設定完了画面に表示が変わる。

【0371】

なお、この例において、図２－４左側の画面においてユーザによってロック日を変える日付が指定されると、限定ではなく例として、指定された日付から当月の給料日１日前までの日付までの日付が一括で指定されるようにしてもよい。具体的には、限定ではなく例として、図２－４左側において、ユーザによって「２０２２年１月２２日」が指定されると、「２０２２年１月２２日」～「２０２２年１月２４日」までの３つの日付が一括で指定されるようにしてもよい。

【0372】

図２－６には、図１－１８中央と同様のカード画面を示している。
この例では、上記の設定を行った後、ユーザＡ．Ａが、限定ではなく例として「２０２２年１月２３日」に「Ｘカード」でクレジットカード決済を行い、その結果が反映された後に表示された画面の一例を示している。また、ここでは、このクレジットカード決済後、「２０２２年１月２３日」～「２０２２年１月２５日」の期間に画面が表示された場合を示している。
利用履歴には、「２０２２年１月２３日」にユーザが「ＰＰスーパー」でクレジットカード決済を行った利用履歴ＵＨＲ３が新たに追加されて表示されている。そして、この例では、この利用履歴の利用金額が未ロックであることに基づき、対応するロックアイコンＩＣ１（南京錠のアイコン）が開錠された態様で表示されている。これは、上記の例においてユーザがロック日として指定した「２０２２年１月２６日」になっていないためである。

【0373】

なお、限定ではなく例として、ユーザの給料日（給料日の０時００分）の翌日（０時００分）や翌日の特定時刻をロック要求情報が送信されるタイミングとして設定可能としてもよいし、ユーザの給料日であって給料が振り込まれる時刻以降の時刻をロック要求情報が送信されるタイミングとして設定可能としてもよい。

【0374】

また、ユーザが、指定した日付における支払いのロックを来月分に繰り越したいと考えるような場合もあり得る。
この場合は、限定ではなく例として、図２－４右側の画面において、ユーザは、ロックする日として、当月のクレジットカード決済の締め日よりも後の日付（この例では「２０２２年２月１日」以降の日付（限定ではなく例として「２０２２年２月１日」）や時刻を指定するようにすることができる。

【0375】

＜処理＞
図２－７は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、限定ではなく例として図１－２３に対応する処理を示したものである。

【0376】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０によって家計管理サーバ１０に送信される。そして、ロック要求情報条件が成立した場合に、ロック要求情報が家計管理サーバ１０によって銀行サーバ６０に送信される場合を例示する。

【0377】

Ｓ１０１０：ＹＥＳの場合、家計管理サーバ１０の制御部１１は、限定ではなく例として、購入情報を受信したことを示すフラグの一種である購入情報受信フラグをセットする（Ｓ２０１０）。この購入情報受信フラグは、限定ではなく例として、所定の期間（限定ではなく例として、セットされてから１ヶ月間、次の口座引き落とし日までの期間等）が経過するまで継続してセットされてもよいものとする。

【0378】

Ｓ１０１０：ＮＯ、または、Ｓ２０１０の処理の後、家計管理サーバ１０の制御部１１は、限定ではなく例として、購入情報受信フラグがセットされているか否かを判定する（Ｓ２０２０）。
購入情報受信フラグがセットされていないと判定する場合（Ｓ２０２０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ２０３０～Ｓ２０４０の処理をスキップする。

【0379】

購入情報受信フラグがセットされていると判定する場合（Ｓ２０２０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ロック要求情報送信条件データ１５７Ａを参照し、ロック要求情報送信条件が成立しているか否かを判定する（Ｓ２０３０）。
ロック要求情報送信条件が成立していないと判定する場合（Ｓ２０３０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ２０４０の処理をスキップする。

【0380】

ロック要求情報送信条件が成立していると判定する場合（Ｓ２０３０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ１０２０に処理を進める。

【0381】

このように、家計管理サーバ１０が購入情報を受信した場合に、購入情報受信フラグをセットし、その後も継続してセットすることによって、購入情報を受信したタイミングとは異なるタイミングでロック要求情報送信条件が成立し得る状況においても、家計管理サーバ１０が購入情報を受信済みであることを把握することができる。そして、ロック要求情報送信条件が成立しているか否かの判定などを適確に行うことができる。

【0382】

＜第２実施例の効果＞
本実施例は、ロック要求情報等の情報（限定ではなく、第１制御情報の一例）は、限定ではなく例として、特定日（限定ではなく、設定された日にちの一例）、または特定日時（限定ではなく、設定された日時の一例）に家計管理サーバ１０の通信Ｉ／Ｆ１４によって送信される構成を示している。
このような構成により得られる実施例の効果の一例として、設定された日にち、または日時に、ユーザの口座に含まれる第１金額のうち、取得した支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報が送信されるようにし、これによって、支払い情報に基づく第２金額に対して第１設定を行わせることができる。

【0383】

また、本実施例は、家計管理サーバ１０は、限定ではなく例として、ユーザの給料が振り込まれる日（給料日）（限定ではなく、設定された日にちの一例）、またはユーザの給料が振り込まれる日時（限定ではなく、設定された日時以降の一例）に、ロック要求情報を送信可能に制御部１１によって制御する構成を示している。
このような構成により得られる実施例の効果の一例として、設定された日にち、または日時以降に、第１制御情報を送信可能に制御することができる。

【0384】

＜第２変形例（１）＞
上記の実施例では、家計管理サーバ１０がクレジットカード会社サーバ５０から１つの購入情報を受信する場合の処理を例示したが、複数の購入情報を受信する場合についても同様とすることができる。

【0385】

この場合、限定ではなく例として図２－７の処理をループさせ、家計管理サーバ１０が、購入情報を受信するごとに、Ｓ２０１０～Ｓ１０４０の処理を行うようにしてもよい。これは、購入（取引）ごとに、逐次的に、利用金額に対応する金額をロックさせる処理と考えてもよい。
つまり、家計管理サーバ１０は、第１購入情報（限定ではなく、第１支払い情報の一例）を取得し、ユーザのユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した第１購入情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信して、第２金額に対してロック設定等の第１設定を行わせるようにしてもよい。
また、家計管理サーバ１０は、第２購入情報（限定ではなく、第２支払い情報の一例）を取得し、ユーザのユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した第２購入情報に基づく第３金額に対して第１設定を行うための第１制御情報を送信して、第３金額に対してロック設定等の第１設定を行わせるようにしてもよい。

【0386】

また、複数の購入情報に基づく金額をまとめてロックする設定を行わせるようにすることも可能である。
この場合、限定ではなく例として図２－７のＳ２０３０のステップにおいて、家計管理サーバ１０の制御部１１は、限定ではなく例として、クレジットカード会社サーバ５０から受信済みの複数の購入情報のうち、ロック要求情報送信条件が成立した購入情報を判定する。そして、ロック要求情報送信条件が成立した購入情報を対象として、各々の購入情報に含まれる購入金額を合算した金額（限定ではなく、第３金額の一例）を算出して合算ロック要求金額とする。そして、家計管理サーバ１０の制御部１１は、合算ロック要求金額を含むロック要求情報を銀行サーバ６０に送信するようにしてもよい。
つまり、家計管理サーバ１０は、第１購入情報（限定ではなく、第１支払い情報の一例）と、第２購入情報（限定ではなく、第２支払い情報の一例）とを取得する。
そして、家計管理サーバ１０は、ユーザのユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した第１購入情報と、取得した第２購入情報とに基づく第３金額（限定ではなく例として、第１購入情報の第１購入金額と第２購入情報の第２購入金額とを加算した金額）に対して第１設定を行うための第１制御情報を送信して、第３金額に対してロック設定等の第１設定を行わせるようにしてもよい。

【0387】

なお、これらの場合、限定ではなく例として図２－７の処理において、クレジットカード会社サーバ５０の制御部が、Ｃ１０５０のステップにおいて、１つの購入情報を送信するようにしてもよいし、複数の購入情報をまとめて送信するようにしてもよい。
そして、家計管理サーバ１０の制御部１１が、Ｓ１０１０のステップにおいて、１つの購入情報を受信したか否かを判定するようにしてもよいし、複数の購入情報をまとめて受信したか否かを判定するようにしてもよい。

【0388】

本変形例は、家計管理サーバ１０は、後払いにより支払われる第１支払い情報の他、後払いにより支払われる第２支払い情報を制御部１１によって取得する。そして、家計管理サーバ１０の制御部１１は、ユーザ情報に基づいて、そのユーザの銀行口座に含まれる口座残高のうち、第１支払い情報と、第２支払い情報とに基づく金額に対してロック設定を行うためのロック要求情報を、通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる変形例の効果の一例として、第１支払い情報の他、ユーザによる、後払いによる第２支払い情報を取得した上で、ユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した第１支払い情報と、取得した第２支払い情報とに基づく第３金額に対して第１設定を行うための第１制御情報が送信されることによって、第１支払い情報と第２支払い情報とに基づく第３金額に対して第１設定を行わせることができる。これにより、限定ではなく例として、ユーザによる、第３金額の使用をまとめて制限に関する設定や、第３金額の使用をまとめてロックすることに関する設定等を行わせることができる。

【0389】

＜第２変形例（２）＞
上記の実施例で説明したロック要求情報送信条件は、あくまでも一例に過ぎず、これに限定されない。
得限定ではなく例として、ユーザが、自己の端末２０に対して、ロック要求情報を送信するように家計管理サーバ１０に依頼するためのロック依頼入力（限定ではなく、第１入力の一例）を行うことを可能とする。このロック依頼入力を受け付けた端末２０は、ロックを依頼する情報（以下、「ロック依頼情報」と称する。）を通信Ｉ／Ｆ２２によって家計管理サーバ１０に送信する。そして、家計管理サーバ１０は、端末２０からロック依頼情報を受信したことを条件として、ロック要求情報を銀行サーバ６０に送信するようにしてもよい。

【0390】

本変形例は、第１制御情報は、ユーザのロック依頼入力（限定ではなく、第１入力の一例）に基づいて、家計管理サーバ１０の通信Ｉ／Ｆ１４によって送信される構成を示している。
このような構成により得られる変形例の効果の一例として、ユーザの第１入力に基づいて、第１制御情報が送信されるようにし、これによって、支払い情報に基づく金額に対して第１設定を行わせることができる。

【0391】

＜第３実施例＞
第３実施例は、限定ではなく例として、クレジットカード決済による購入品の品目の種別等に関するロック条件が設定される実施例である。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0392】

本実施例では、クレジットカード決済の利用金額に対応する金額をロックするときのロック条件として、限定ではなく例として、以下のような購入品の品目の種別に関する条件を設定しておくことができる。
“ＣＩ”：購入品の種別に関するロック条件

【0393】

このロック条件には、限定ではなく例として、さらに詳細なロック条件が設定されてもよく、その詳細なロック条件を以下に例示する。

【0394】

「ＣＩ：購入品の種別に関するロック条件」とは、限定ではなく例として、クレジットカード決済による取引が行われた購入品の品目の種別に関する条件とすることができ、限定ではなく例として、「ＣＩ０１：購入品が第１種別の品目」を含めることができる。
「ＣＩ０１：購入品が第１種別の品目」とは、限定ではなく例として、クレジットカード決済による取引が行われた購入品の品目の種別が第１種別である場合のこととすることができる。ここで第１種別とは、限定ではなく例として、食品や外食費などの種別としてよい。

【0395】

また、この他にも、「ＣＩ：購入品の種別に関するロック条件」には、限定ではなく例として、「ＣＩ０２：購入品が第２種別の品目」を含めてもよい。
「ＣＩ０２：購入品が第２種別の品目」とは、限定ではなく例として、クレジットカード決済による取引が行われた購入品の品目の種別が第２種別である場合のこととすることができる。ここで第２種別とは、限定ではなく例として、日用品などの種別としてよい。

【0396】

＜データ構成＞
図３－１は、本実施例におけるロック要求情報送信条件データ１５７の一例であるロック要求情報送信条件データ１５７Ｂを示す図である。
本例では、条件Ｎｏ「ＣＩ０１」：「購入品が第１種別の品目」の条件が設定されている。
また、条件Ｎｏ「ＣＴ０２」：「購入品が第２種別の品目」の条件が設定されている。

【0397】

これらの条件は、限定ではなく例として、前述したように、手動設定されるようにしてもよいし、自動設定されるようにしてもよい。
また、手動設定で条件が設定される場合、ロック要求情報送信条件データは、ユーザと関連付けて記憶される、限定ではなく例として、家計管理ユーザ管理データベース１５５のうち、そのユーザのアプリケーションＩＤが記憶された家計管理ユーザ管理データに記憶されるようにしてもよい。

【0398】

＜表示画面＞
図３－２には、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示している。
図３－２左側には、図２－３右側と同様のカード設定画面の一例を示しており、ここでは、ユーザによって「ロック項目に関する設定」の表示領域がタッチされて選択された状態が示されている。すると、限定ではなく例として、図３－２中央のような表示に変わる。
この例では、選択された「ロック項目に関する設定」として、限定ではなく例として、支出項目によるロック設定を行うための「支出項目指定」と、金額指定によるロック設定（第３変形例で後述）を行うための「金額指定」と、購入品の品目の種別ごとの個別指定によるロック設定を行うための「個別指定」との３種類の設定を選択可能に構成されている。

【0399】

限定ではなく例として、「支出項目指定」がユーザによってタッチされて選択されると、限定ではなく例として、図３－２右側のような画面が表示される。
この画面は、ロックする支出項目を設定するための画面であり、「支出項目を指定してください」のテキストとともに、この例では、「変動費」と「固定費」との２つの支出項目が表示されている。

【0400】

ここでは、便宜的に、食費、日用品費等を含む包括的な支出項目を「変動費」と称し、家賃、光熱費等を含む包括的な支出項目を「固定費」としている。

【0401】

この例では、各々の支出項目にはラジオボタンが関連付けて表示されており、ラジオボタンをオンとすることで、対応する支出項目をロック設定として選択することができるように構成されている。

【0402】

この例では、「変動費」の項目に対応するラジオボタンがユーザによってオンとされた状態が示されている。この状態で、画面下部の「決定」ボタンＢＴ１がユーザによってタッチされると、「変動費」の支出項目がロック対象として設定される。

【0403】

なお、限定ではなく例として、上記の「個別指定」の項目が選択された場合、限定ではなく例として、変動費のうちの「食費」や「日用品費」といった、変動費の下位の支出項目について同様の表示がされ、同様に設定を行うことができるようにしてもよい。固定費についても同様としてもよい。
さらに、限定ではなく例として、「食費」について食材購入、外食といったより具体的な指定をすることができるようにしてもよく、「日用品費」についても同様としてもよい。固定費についても同様としてもよい。

【0404】

＜処理＞
本実施例における各装置が実行する処理の流れは、前述した各種のフローチャートの処理の流れを同様に適用可能であるため、図示を省略する。
この場合、限定ではなく例として図２－７の処理において、購入情報受信フラグがセットされており、ロック要求情報送信条件が成立した場合に、家計管理サーバ１０がロック要求情報を送信するようにすることができる。

【0405】

また、この場合、Ｃ１０５０のステップで、クレジットカード会社サーバ５０の制御部５１は、限定ではなく例として、クレジットカード決済による利用金額の情報の他、少なくとも支出項目を特定可能な情報を購入情報に含めて、家計管理サーバ１０に送信するようにすることができる。

【0406】

そして、Ｓ１０２０のステップにおいて、ロック要求情報送信条件データ１５７Ｂのロック要求情報送信条件（図３－１の“ＣＩ０１”、“ＣＩ０２”等）に設定されている種別の購入品に関する利用金額に対応するロック要求情報が、家計管理サーバ１０から銀行サーバ６０に送信されるようにすることができる。
逆に言えば、ロック要求情報送信条件データ１５７Ｂのロック要求情報送信条件（図３－１の“ＣＩ０１”、“ＣＩ０２”等）に設定されていない種別の購入品に関する利用金額に対応するロック要求情報は、家計管理サーバ１０から銀行サーバ６０に送信されないようにすることができる。

【0407】

このように、限定ではなく例として、ユーザの利用度合いに応じてその月ごとに利用金額が変動し得る変動費である第１種別（食品）、第２種別（日用品）等の購入品に関する利用金額は、残高をロックすることによって、クレジットカード決済の銀行口座からの振替を確実に行うようにすることができる。
一方で、限定ではなく例として、ユーザの利用度合いに関わらずその月ごとに利用金額が固定されている種別の固定費（家賃、光熱費等）や、ユーザがイレギュラーに購入した高額になり得る種別の購入品（趣味の購入品等）に関する利用金額は、残高をロックしないことによって、ユーザが自由に利用できる銀行口座の残高をむやみに減らしてしまわないようにすることができる。

【0408】

＜第３実施例の効果＞
本実施例は、家計管理サーバ１０は、限定ではなく例として図３－１等のデータを参照し、ユーザによって設定されたロック条件（限定ではなく、第１条件の一例）を満たす購入情報を取得する構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信する対象の支払い情報として選定することができる。

【0409】

また、この場合、上記のユーザによって設定されたロック条件は、限定ではなく例として、ユーザの利用度合いに応じてその月ごとに利用金額が変動し得る種別の変動費の属性や、ユーザの利用度合いに関わらずその月ごとに利用金額が固定されている種別の固定費の属性、ユーザがイレギュラーに購入した高額になり得る高額出費の属性といった、支払いの属性（支払いの種別、支払いの種類）に関する設定を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、支払いの属性に関する設定を含む、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信する対象の支払い情報として選定することができる。

【0410】

また、この場合、上記の支払いの属性は、固定費および変動費を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、固定費および変動費を含む支払いの属性に関する設定を含む、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報を送信する対象の支払い情報として選定することができる。

【0411】

＜第３変形例（１）＞
上記の実施例では、購入品の品目の種別等に関してロック条件が設定される例を示したが、このような例に限定されず、他の項目に関してロック条件が設定されてもよい。

【0412】

限定ではなく例として、クレジットカード決済の取引における購入品の購入金額に関してロック条件を設定してもよい。この場合、ロック条件には、限定ではなく例として、以下のような購入金額に関する条件を含めることができる。
“ＣＭ”：購入金額に関するロック条件

【0413】

このロック条件には、限定ではなく例として、以下の条件を含めてよい。
「ＣＭ０１：購入金額が設定金額未満（または購入金額が設定金額以下）」
これは、比較的安価な取引がなされた場合に、その金額をロックする条件と捉えてもよい。

【0414】

なお、これとは逆に、限定ではなく例として、以下の条件を含めてもよい。
「ＣＭ０２：購入金額が設定金額以上（または購入金額が設定金額超）」
これは、比較的高価な取引がなされた場合に、その金額をロックする条件と捉えてもよい。

【0415】

設定金額は、前述した条件と同様に、手動設定されるようにしてもよいし、自動設定されるようにしてもよい。

【0416】

また、条件「ＣＭ０１」と条件「ＣＭ０２」とで、設定金額として同じ金額を設定してもよいし、異なる金額を設定してもよい。
異なる金額を設定する場合、限定ではなく例として、条件「ＣＭ０１」については、「１０，０００円」や「２０，０００円」といった第１設定金額を設定し、条件「ＣＭ０２」については、第１設定金額よりも高い「１００，０００円」や「２００，０００円」といった第２設定金額を設定するようにしてもよい。

【0417】

また、限定ではなく例として、「変動費」や「固定費」といった包括的な支出項目について、どのくらいの金額以上（または超）のものはロック対象とするか、または、どのくらいの金額未満（または以下）のものはロック対象とするかを設定可能としてもよい。
また、限定ではなく例として、「変動費」のうちの「食費」や「日用品費」といった個別具体的な支出項目について同様の設定を行うことができるようにしてもよい。「固定費」についても同様としてもよい。

【0418】

＜第４実施例＞
第４実施例は、銀行口座の残高がロックされているときに、ロックを解除することに関する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0419】

ここでは、銀行口座の残高のうちいずれかの金額がロックされているときに、ロックを解除することを要求する情報が、ユーザＡ．Ａの端末２０によって家計管理サーバ１０に送信され、そのロックを解除することを要求する情報が家計管理サーバ１０によって銀行サーバ６０に送信されることで、銀行サーバ６０によってロックが解除される場合を例示する。

【0420】

＜表示画面＞
図４－１～図４－２は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図４－１左側には、図１－１９中央と同様の画面を示しており、この例では、取引履歴のうち、「２０２２年１月６日」の取引内容に「ロック」が記憶された欄のロックアイコンＩＣ１がユーザによってタッチされた状態が示されている。

【0421】

すると、限定ではなく例として、図４－１中央のような表示に変わる。
この例では、この取引に対応するクレジットカード決済の利用金額のロックを解除するか否かをユーザに確認するためのテキスト（この例では「ロックを解除しますか？」）と、ロック解除を許諾するための「はい」ボタンと、ロック解除をキャンセルするための「キャンセル」ボタンとを含むロック解除確認情報ＵＬＩが、画面中央部にポップアップ表示されている。

【0422】

「はい」ボタンがユーザによってタッチされると、限定ではなく例として、図４－１右側のような表示に変わる。
具体的には、取引履歴において、図４－１左側の画面でタッチされた、施錠された南京錠の画像のロックアイコンＩＣ１が、開錠された南京錠の画像のアイコンに変化して表示されている。
また、ロックが解除されたことに基づき、口座残高の帯グラフのロック領域が、ロックが解除された金額の割合分だけ横幅が縮められて表示されている。

【0423】

図４－２には、前述した家計管理アプリケーションのカード画面の一例を示しており、この例では、利用履歴のうち、「２０２２年１月２３日」の取引内容のロックアイコンＩＣ１がユーザによってタッチされた状態が示されている。

【0424】

すると、限定ではなく例として、図４－２中央のような表示に変わる。
この例では、図４－１中央の画面と同様に、この利用履歴に対応するクレジットカード決済の利用金額のロックを解除するか否かをユーザに確認するためのロック解除確認情報ＵＬＩが、画面中央部にポップアップ表示されている。

【0425】

「はい」ボタンがユーザによってタッチされると、限定ではなく例として、図４－２右側のような表示に変わる。
具体的には、利用履歴において、図４－２左側の画面でタッチされた、施錠された南京錠の画像のロックアイコンＩＣ１が、開錠された南京錠の画像のアイコンに変化して表示されている。

【0426】

つまり、この例では、限定ではなく例として、ユーザが「銀行」の取引履歴からロックを解除することができ、また、ユーザが「カード」の利用履歴からもロックを解除することができる場合を示している。
ただし、これはあくまで一例に過ぎず、これに限定されるものではない。

【0427】

＜処理＞
図４－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順にユーザＡ．Ａの端末２０の制御部２１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、銀行サーバ６０の制御部６１が実行する処理をそれぞれ示している。

【0428】

本例では、クレジットカード決済が行われ、ユーザＡ．Ａの銀行口座の残高の少なくとも一部の金額がロックされているときに、ロックを解除することを要求する情報が、ユーザＡ．Ａの端末２０によって家計管理サーバ１０に送信される。そして、その後、その情報に関する情報が家計管理サーバ１０によって銀行サーバ６０に送信されることで、銀行サーバ６０によってロックが解除される場合を例示する。

【0429】

家計管理サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからロック解除要求情報を受信したか否かを判定する（Ｓ４０１０）。
受信しなかったと判定したならば（Ｓ４０１０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ４０２０のステップをスキップする。

【0430】

通信Ｉ／Ｆ１４によって端末２０からロック解除要求情報を受信したと判定する場合（Ｓ４０１０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ロック解除要求情報を、通信Ｉ／Ｆによって銀行サーバ６０に送信する（Ｓ４０２０）。
ここでのロック解除要求情報は、限定ではなく例として、端末２０から家計管理サーバ１０に送信されるロック解除要求情報と同様の情報であってもよいし、異なる情報であってもよい。

【0431】

また、Ｓ４０２０のステップの処理の後、家計管理サーバ１０の制御部１１は、限定ではなく例として、通信Ｉ／Ｆ１４によって銀行サーバ６０からロック解除認証要求情報を受信したか否かを判定する（Ｓ４０３０）。
受信しなかったと判定する場合（Ｓ４０３０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ４０４０のステップをスキップする。

【0432】

通信Ｉ／Ｆ１４によって銀行サーバ６０からロック解除認証要求情報を受信したと判定する場合（Ｓ４０３０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ロック解除認証要求情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｂ４０４０）。
ここでのロック解除認証要求情報は、限定ではなく例として、銀行サーバ６０から家計管理サーバ１０に送信されるロック解除認証要求情報と同様の情報であってもよいし、異なる情報であってもよい。

【0433】

Ｓ４０６０のステップの処理の後、家計管理サーバ１０の制御部１１は、限定ではなく例として、通信Ｉ／Ｆ１４によって端末２０からロック解除認証情報を受信したか否かを判定する（Ｓ４０５０）。
受信しなかったと判定する場合（Ｓ４０５０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ４０６０のステップをスキップする。

【0434】

通信Ｉ／Ｆ１４によって端末２０からロック解除認証情報を受信したと判定する場合（Ｓ４０５０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ロック解除認証情報を、通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する（Ｓ４０６０）。
ここでのロック解除認証情報は、限定ではなく例として、端末２０から家計管理サーバ１０に送信されるロック解除認証情報と同様の情報であってもよいし、異なる情報であってもよい。

【0435】

Ｓ４０６０のステップの処理の後、家計管理サーバ１０の制御部１１は、限定ではなく例として、通信Ｉ／Ｆ１４によって銀行サーバ６０からロック解除結果情報を受信したか否かを判定する（Ｓ４０７０）。
受信しなかったと判定する場合（Ｓ４０７０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、処理を終了する。

【0436】

通信Ｉ／Ｆ１４によって銀行サーバ６０からロック解除結果情報を受信したと判定する場合（Ｓ４０７０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、ロック解除結果情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｓ４０８０）。
ここでのロック解除結果情報は、限定ではなく例として、銀行サーバ６０から家計管理サーバ１０に送信されるロック解除結果情報と同様の情報であってもよいし、異なる情報であってもよい。
そして、家計管理サーバ１０の制御部１１は、処理を終了する。

【0437】

なお、本処理では、ロック解除を行うに際してユーザ認証を行っているが、これを行わないようにしてもよい。
具体的には、限定ではなく例として、Ａ４０３０～Ａ４０６０、Ｓ４０３０～Ｓ４０６０、Ｂ４０２０～Ｂ４０４０のステップを省略してもよい。

【0438】

また、本処理では、ロック設定によって設定されたロックを解除するロック解除設定を行う場合を例示したが、これに限定されない。
限定ではなく例として、一時的なロックの解除の設定（以下、「一時ロック解除設定」と称する。）等を行うようにしてもよい。限定ではなく例として、ロック設定によってロックされた金額が、一時ロック解除設定を行ってから設定時間（限定ではなく例として、１時間～３時間の時間範囲の時間）だけユーザによって使用可能となり、設定時間が経過した後は、再びロック設定（再ロック設定）されるような設定を行うようにしてもよい。

【0439】

＜第４実施例の効果＞
本実施例は、家計管理サーバ１０が、ユーザによるロック解除入力等の入力（限定ではなく、第２入力の一例）に基づいて、ロック設定（限定ではなく、第１設定の一例）とは異なる設定であるロック解除設定や一時ロック解除設定等の設定（限定ではなく、第２設定の一例）を行うためのロック解除要求情報等の情報（限定ではなく、第２制御情報の一例）を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによる第２入力に基づいて、第２金額に対して第１設定とは異なる第２設定を行うための第２制御情報が送信されることによって、第１設定とは異なる第２設定を行わせることができる。

【0440】

また、この場合、上記の第２設定は、第２金額を使用可能にする設定を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２制御情報が送信されることによって、第２金額を使用可能にする設定を行わせることができる。

【0441】

また、本実施例は、家計管理サーバ１０は、上記の第２入力に基づいて、ロック解除結果情報（ロック解除結果情報に含まれる金額の情報）（限定ではなく、第２設定が行われた第２金額に関する情報）をユーザの端末２０に通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによる第２入力に基づいて、第２設定が行われた第２金額に関する情報がユーザの端末に送信されることによって、第２設定が行われた第２金額に関する情報を端末のユーザに知らせることができる。

【0442】

＜第４変形例（１）＞
上記の実施例において、銀行口座の残高のうちいずれかの金額がロックされているときにユーザがロックを解除しようとする場合に、ロックを解除するための条件（ロック解除条件）が設定されるようにしてもよい。

【0443】

図４－４は、本変形例において家計管理サーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
本実施例において、記憶部１５には、限定ではなく例として、家計管理処理プログラム１５１と、家計管理ユーザ登録データ１５３と、家計管理ユーザ管理データベース１５５とに加えて、限定ではなく例として、ロック解除要求情報送信条件データ１５８が記憶される。

【0444】

ロック解除要求情報送信条件データ１５８は、限定ではなく例として、ロック解除条件の一種であり、ロック解除要求情報を送信するための条件であるロック解除要求情報送信条件が設定されたデータであり、そのデータ構成例を図４－５に示す。
ロック解除要求情報送信条件データ１５８Ａには、限定ではなく例として、条件Ｎｏと、ロック解除要求情報送信条件とが関連付けて記憶される。

【0445】

条件Ｎｏは、ロック解除要求情報送信条件に対応した番号（条件の識別情報）が設定される。
条件Ｎｏは、好ましくはロック解除要求情報送信条件ごとに一意な値であり、限定ではなく例として、家計管理サーバ１０によってロック解除要求情報送信条件ごとに一意な値（固有の値）が設定されて記憶される。

【0446】

本例では、条件Ｎｏ「ＣＬ０１」：「現在日時が口座引き落とし日の前日ではない」の条件が設定されている。
「現在日時が口座引き落とし日の前日ではない」とは、限定ではなく例として、このデータを参照するタイミングが、クレジットカード決済の口座引き落とし日の前日（限定ではなく例として、口座引き落とし日の前日０時００分から口座引き落とし日の０時００分となるまでの期間）以外の日時である場合とすることができる。

【0447】

本変形例では、限定ではなく例として図４－３の処理において、Ｓ４０１０のステップで端末２０Ａからロック解除要求情報を受信したと判定した場合に（Ｓ４０１０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、ロック解除要求情報送信条件データ１５８を参照し、ロック解除要求情報送信条件が成立しているか否かを判定するようにすることができる。
そして、ロック解除要求情報送信条件が成立していないと判定した場合、家計管理サーバ１０の制御部１１は、Ｓ４０２０のステップをスキップし、ロック解除要求情報送信条件が成立していると判定した場合、家計管理サーバ１０の制御部１１は、Ｓ４０２０のステップを行うようにすることができる。

【0448】

本変形例は、家計管理サーバ１０が、ロック解除要求情報送信条件（限定ではなく、設定された第２条件の一例）を満たさない場合で、ユーザによってロック解除入力等の入力（限定ではなく、第２入力の一例）が行われた場合、ロック解除要求情報等の情報（限定ではなく、第２制御情報の一例）を送信しない制御を制御部１１によって行う構成を示している。
このような構成により得られる変形例の効果の一例として、設定された第２条件を満たさない場合で、ユーザによって第２入力が行われた場合、第２制御情報を送信しない制御が行われることによって、第１設定とは異なる第２設定が行われないようにすることができる。

【0449】

＜第４変形例（２）＞
上記の実施例や第４変形例（１）で説明した処理を、限定ではなく例として、端末２０と銀行サーバ６０との間で行うようにしてもよい。

【0450】

図４－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側に、ユーザＡ．Ａの端末２０の制御部２１が実行する処理を示し、右側に、銀行サーバ６０の制御部６１が実行する処理を示しており、図４－３に対応する処理を示している。

【0451】

本例では、クレジットカード決済が行われ、ユーザＡ．Ａの銀行口座の残高の少なくとも一部の金額がロックされているときに、ロックを解除することを要求する情報が、ユーザＡ．Ａの端末２０によって銀行サーバ６０に送信されることで、銀行サーバ６０によってロックが解除される場合を例示する。

【0452】

最初に、端末２０の制御部２１は、限定ではなく例として、ユーザＡ．Ａによってロック解除入力（限定ではなく例として、ロック解除操作）が行われたか否かを判定する（Ａ４０１０）。限定ではなく例として、端末２０における銀行サービスに関するアプリケーション等でロックを解除するためのボタンなどがユーザによって操作なされたか否かを判定するようにしてもよい。

【0453】

なお、このロック解除入力には、限定ではなく例として、ロックされている金額のうちのいくらの金額のロックを解除するのかを設定する入力も含まれていてもよい。

【0454】

ユーザＡ．Ａによってロック解除の操作が行われていないと判定する場合（Ａ４０１０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ４０２０のステップをスキップする。

【0455】

ユーザＡ．Ａによってロック解除の操作が行われたと判定する場合（Ａ４０１０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、銀行口座ＩＤに関する情報と、その銀行口座ＩＤに対応する銀行口座のロックされている残高のロックを解除するように要求する情報とを含むロック解除要求情報を、通信Ｉ／Ｆ２２によって銀行サーバ６０に送信する（Ａ４０２０）。

【0456】

なお、限定ではなく例として、前述したロックされている残高のうちのいくらの金額のロックを解除するのかを設定する操作がなされた場合には、この金額に関する情報がロック解除要求情報に含まれるようにしてもよい。

【0457】

銀行サーバ６０の制御部は、限定ではなく例として、通信Ｉ／Ｆによって端末２０からロック解除要求情報を受信したか否かを判定する（Ｂ４０１０）。
通信Ｉ／Ｆによって端末２０からロック解除要求情報を受信しなかったと判定する場合（Ｂ４０１０：ＮＯ）、銀行サーバ６０の制御部は、限定ではなく例として、Ｂ４０２０のステップをスキップする。

【0458】

通信Ｉ／Ｆによって端末２０からロック解除要求情報を受信したと判定する場合（Ｂ４０１０：ＹＥＳ）、銀行サーバ６０の制御部は、限定ではなく例として、銀行口座ＩＤに関する情報と、ロックを解除する前に端末２０のユーザが銀行口座ＩＤの契約者（ユーザＡ．Ａ）本人であるか否かを認証するための情報を含むロック解除認証要求情報を、通信Ｉ／Ｆによって端末２０に送信する（Ｂ４０２０）。

【0459】

端末２０の制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除認証要求情報を受信したか否かを判定する（Ａ４０３０）。
通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除認証要求情報を受信しなかったと判定する場合（Ａ４０３０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ４０４０～Ａ４０６０のステップをスキップする。

【0460】

通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除認証要求情報を受信したと判定する場合（Ａ４０３０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、受信したロック解除認証要求情報に基づいて、ロック解除認証要求情報を表示部２４に表示させる（Ａ４０４０）。

【0461】

端末２０の制御部２１は、限定ではなく例として、ユーザＡ．Ａによって認証操作が行われたか否かを判定する（Ａ４０５０）。
ここで、限定ではなく例として、端末２０における銀行サービスに関するアプリケーション等の認証画面で認証パスワードなどがユーザによって入力なされたか否かを判定するようにしてもよい。

【0462】

ユーザＡ．Ａによって認証操作が行われていないと判定する場合（Ａ４０５０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ４０６０のステップをスキップする。

【0463】

ユーザＡ．Ａによって認証操作が行われたと判定する場合（Ａ４０５０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、銀行口座ＩＤに関する情報と、ユーザＡ．Ａによる認証操作に関する情報とを含むロック解除認証情報を、通信Ｉ／Ｆ２２によって銀行サーバ６０に送信する（Ａ４０６０）。
このロック解除要求情報には、限定ではなく例として、ユーザＡ．Ａによって入力された認証パスワードに関する情報が含まれてもよい。

【0464】

銀行サーバ６０の制御部は、限定ではなく例として、通信Ｉ／Ｆによって端末２０からロック解除認証情報を受信したか否かを判定する（Ｂ４０３０）。
通信Ｉ／Ｆによって端末２０からロック解除認証情報を受信しなかったと判定する場合（Ｂ４０３０：ＮＯ）、銀行サーバ６０の制御部は、限定ではなく例として、Ｂ４０４０～Ｂ４０６０のステップをスキップする。

【0465】

通信Ｉ／Ｆによって端末２０からロック解除認証情報を受信したと判定する場合（Ｂ４０３０：ＹＥＳ）、銀行サーバ６０の制御部は、限定ではなく例として、ロック解除認証されているか否かを判定する（Ｂ４０４０）。
ここで、銀行口座ユーザ管理データには、限定ではなく例として、事前にユーザによってロック解除用の認証パスワードが登録されているものとし、ロック解除認証情報を受信した銀行サーバ６０の制御部は、限定ではなく例として、銀行口座ＩＤに対応する銀行口座ユーザ管理データに含まれる認証パスワードを参照し、ロック解除認証情報に含まれるユーザＡ．Ａによって入力された認証パスワードと整合しているか否かを判定するなどしてもよい。

【0466】

ロック解除認証されていないと判定する場合（Ｂ４０４０：ＮＯ）、銀行サーバ６０の制御部は、限定ではなく例として、Ｂ４０５０のステップをスキップする。

【0467】

ロック解除認証されたと判定する場合（Ｂ４０４０：ＹＥＳ）、銀行サーバ６０の制御部は、限定ではなく例として、ロック解除処理（ロック解除設定）を実行する（Ｂ４０５０）。
ロック解除処理において、銀行サーバ６０の制御部は、限定ではなく例として、受信したロック解除認証情報に含まれる銀行口座ＩＤに基づいて、銀行口座ユーザ管理データベース６５９のうち、その銀行口座ＩＤに対応する銀行口座ユーザ管理データを特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データのロック金額のデータに、受信したロック解除要求情報に含まれるロック解除する金額に関する情報を記憶させる（ロック解除後のロック金額に更新させる）。

【0468】

そして、Ｂ４０４０：ＮＯ、または、Ｂ４０５０のステップの処理の後、銀行サーバ６０の制御部は、限定ではなく例として、ロック解除処理の結果に関する情報を含むロック解除結果情報を、通信Ｉ／Ｆによって端末２０に送信する（Ｂ４０６０）。
このように、銀行サーバ６０の制御部は、限定ではなく例として、ロック解除認証情報を受信した場合（Ｂ４０３０：ＹＥＳ）、ロック解除認証のＹＥＳまたはＮＯに関わらず、ロック解除結果情報を端末２０に送信している。

【0469】

この場合、ロック解除の認証がなされてロック解除処理が行われた場合、ロック解除結果情報には、限定ではなく例として、ロック解除の認証がなされたことに関する情報や、ロック解除処理が行われことに関する情報等の情報が含まれるようにしてもよい。ロック解除された金額の情報が含まれるようにしてもよい。
また、ロック解除の認証がなされずロック解除処理が行われなかった場合、ロック解除結果情報には、限定ではなく例として、ロック解除の認証がなされなかったことに関する情報や、ロック解除処理が行われなかったことに関する情報等の情報が含まれるようにしてもよい。ロック解除されなかった金額の情報が含まれるようにしてもよい。
そして、銀行サーバ６０の制御部６１は、処理を終了する。

【0470】

端末２０の制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除結果情報を受信したか否かを判定する（Ａ４０７０）。
通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除結果情報を受信しなかったと判定する場合（Ａ４０７０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ４０８０のステップをスキップする。

【0471】

通信Ｉ／Ｆ２２によって銀行サーバ６０からロック解除結果情報を受信したと判定する場合（Ａ４０７０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、受信したロック解除結果情報に基づいて、ロック解除結果情報を表示部２４に表示させる（Ａ４０８０）。
そして、端末２０Ａの制御部２１は、処理を終了する。

【0472】

なお、第４変形例（１）に本処理を適用する場合、限定ではなく例として、図４－５のロック解除要求情報送信条件データ１５８と同様のデータとして、ロック解除認証要求情報送信条件データを、銀行サーバ６０の記憶部６５に記憶させておく。
そして、限定ではなく例として図４－６の処理において、銀行サーバ６０の制御部６１が、Ｂ４０１０のステップで端末２０Ａからロック解除要求情報を受信したと判定した場合（Ｂ４０１０：ＹＥＳ）、ロック解除認証要求情報送信条件データを参照し、ロック解除認証要求情報送信条件が成立しているか否かを判定するようにすることができる。
そして、銀行サーバ６０の制御部６１は、ロック解除認証要求情報送信条件が成立していないと判定した場合、Ｂ４０２０のステップをスキップし、ロック解除認証要求情報送信条件が成立していると判定した場合、Ｂ４０２０のステップを行うようにすることができる。

【0473】

＜第５実施例＞
第５実施例は、銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額がロックされるときに、銀行口座の残高が不足する場合に関する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0474】

以下、本実施例における銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額がロックされるときに銀行口座の残高が不足している場合における処理の一例を説明する。

【0475】

ここでは、（Ｅ１）第１パターンとして、銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額をロックするための銀行口座の残高が不足しているときに、ロックするための銀行口座の残高が不足していることをユーザに通知する場合を例示する。

【0476】

＜表示画面＞
図５－１は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図５－１左側には、端末２０ＡのＯＳの待ち受け画面（ロック画面）を示している。
この例では、待ち受け画面の上部に、家計管理サービス（家計管理サーバ１０）を送信元とするプッシュ形式で通知される通知情報（プッシュ通知情報）であって、ロックする銀行口座の残高が不足していることをユーザに通知する通知情報の一例として、プッシュ通知情報ＰＮ１が表示されている。

【0477】

このプッシュ通知情報ＰＮ１がユーザによってタッチされると、限定ではなく例として、端末２０Ａで家計管理アプリケーションが起動し、図５－１右側のような家計管理アプリケーションのおしらせ画面が表示される。
このおしらせ画面では、「ロック未確認のおしらせ」として、限定ではなく例として、日付（この例では「２０２２年１月６日」）とともに、その日付におけるクレジットカード決済の決済金額（利用金額）が銀行口座の残高不足によりロックされなかった（ロックすることができなかった）ことを示すテキストが表示されている。また、この例では、限定ではなく例として、銀行口座の残高を確認するようユーザに促すテキストが併せて表示されている。

【0478】

なお、後述するが、この他にも、限定ではなく例として、ロックする予定であった金額（以下、「ロック予定金額」と称する。）や、銀行口座の残高、ロックを行うために不足している金額（不足金額）等の情報も併せて表示させるようにしてもよい。

【0479】

＜処理＞
本実施例の（Ｅ１）第１パターンにおける処理の流れは、前述した各種のフローチャートの処理の流れを同様に適用可能であるため、図示を省略する。

【0480】

限定ではなく例として、図１－２３等の処理のＢ１０２０のロック処理において、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、Ｂ１０３０のロック結果情報に、限定ではなく例として、ロックするための銀行口座の残高が不足していたことをユーザに通知する通知情報を含めることができる。

【0481】

そして、銀行サーバ６０や家計管理サーバ１０によって送信された、このロックするための銀行口座の残高が不足していたことをユーザに通知する通知情報を含むロック結果情報を受信した端末２０Ａの制御部２１によってロック結果情報が表示部２４に表示されることによって、端末２０のユーザＡ．Ａはロックするための銀行口座の残高が不足していたことを認識できる。

【0482】

本実施例では、限定ではなく例として、銀行口座の残高が不足していたことによってクレジットカード決済の利用金額をロックできなかった場合、ロック処理において、ロック予定金額について、限定ではなく例として、以下のような制御を行うようにしてもよい。
なお、以下では、限定ではなく例として、ロック予定金額のうち、ロックされた一部の金額を「ロック済金額」と称し、ロックされていない残りの金額を「ロック未済金額」と称する。

【0483】

“Ｅ１”：ロック予定金額のうちいずれの金額もロックせずに、残高がロック予定金額を超えたときにロック予定金額をロックする
“Ｅ２”：ロック予定金額のうち残高分の金額だけロックし、残高がロック未済金額を超えたときにそのロック未済金額をロックする
“Ｅ３”：ロック予定金額のうち残高分の金額だけロックし、残高が０円より多くなったときに残高分だけの金額をその都度ロックする

【0484】

“Ｅ１”は、限定ではなく例として、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、銀行口座の残高がロック予定金額を超えるまではロックせずに、銀行口座の残高がロック予定金額を超えたときにロック予定金額をロックする制御方法とすることができる。

【0485】

“Ｅ２”は、限定ではなく例として、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、ロック予定金額のうち残高分の金額だけロックし、銀行口座の残高がロック未済金額を超えたときに残りのロック未済金額をロックする制御方法とすることができる。

【0486】

“Ｅ３”は、限定ではなく例として、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、ロック予定金額のうち残高分の金額だけロックし、銀行口座の残高が０円よりも多くなったときにロック未済金額のうち残高分の金額をその都度ロックする制御方法とすることができる。

【0487】

＜第５実施例の効果＞
本実施例は、家計管理サーバ１０（限定ではなく、情報処理装置の一例）が、ユーザの銀行等の口座に含まれる金額（限定ではなく、第１金額の一例）が、支払い情報に基づく金額（限定ではなく、第２金額の一例）より小さい金額の場合、ロックするための口座残高が不足していることをユーザに通知する情報（限定ではなく、口座の残高が足りないことを示す情報の一例）をユーザの端末２０に送信する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額が第２金額よりも小さい金額の場合、口座の残高が足りないことを示す情報がユーザの端末に送信されることによって、口座の残高が足りないことを端末のユーザに知らせることができる。

【0488】

＜第５変形例（１）＞
上記の実施例において、（Ｅ２）第２パターンとして、銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額をロックするための銀行口座の残高が不足しているときに、ロックするための銀行口座の残高が不足していることと、不足している金額とをユーザに通知するようにしてもよい。

【0489】

また、この（Ｅ２）第２パターンにおいて、限定ではなく例として、銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額をロックするための銀行口座の残高が不足しているときに、ユーザが不足している残高を補うためのお金を借りることができるようにしてもよい。

【0490】

図５－２は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図５－２左側には、図５－１と同様の画面を示している。
図５－２右側には、図５－１右側と同様の家計管理アプリケーションのおしらせ画面を示しているが、図５－１右側に示した画面とは一部が異なっている。

【0491】

具体的には、図５－２右側の画面では、前述した情報の他、前述したロック予定金額や、銀行口座の残高、不足金額等の情報が併せて表示されている。

【0492】

また、この例では、ユーザがキャッシングサービスを利用してキャッシングを行うことを可能とする情報として、限定ではなく例として、「キャッシングサービスを利用する」のテキストを含むボタンＢＴ４が表示されている。

【0493】

キャッシングサービスは、限定ではなく例として、クレジットカード会社が提供するサービスとすることができ、ボタンＢＴ４には、限定ではなく例として、クレジットカード会社のウェブサイト（外部サイト）のＵＲＬ（限定ではなく例として、キャッシングページのＵＲＬ）や、クレジットカード会社が提供するアプリケーション（クレジットカードアプリケーション）のページ情報（限定ではなく例として、クレジットカードアプリケーションのキャッシングページのページ情報）等のリンクが設定されるようにすることができる。そして、ボタンＢＴ４がユーザによってタッチされると、端末２０Ａの表示部２４には、上記のページが表示されるようにすることができる（不図示）。
なお、ボタンＢＴ４ではなく、リンク付きのテキスト等としてもよい。

【0494】

この場合、限定ではなく例として、図１－２３等の処理のＢ１０２０のロック処理において、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、Ｂ１０３０のロック結果情報に、限定ではなく例として、ロックするための銀行口座の残高が不足していることをユーザに通知する通知情報と、その不足している金額に関する情報と、ユーザがお金を借りるための情報とを含めることができる。

【0495】

そして、このロックするための銀行口座の残高が不足していることをユーザに通知する通知情報と、その不足している金額に関する情報と、ユーザがお金を借りるための情報とを含むロック結果情報を受信した端末２０Ａの制御部２１によって、ロック結果情報が表示部２４に表示されることによって、端末２０のユーザＡ．Ａはロックするための銀行口座の残高が不足していることと、不足している金額とを認識できるとともに、不足している金額を補うためのお金を借りるための導線を確保することができ、ユーザのニーズにあったサービスを提供できる。

【0496】

＜第４変形例（２）＞
上記の実施例において、（Ｅ３）第３パターンとして、銀行口座の残高のうちクレジットカード決済における利用金額に対応する金額をロックするための銀行口座の残高が不足しているときに、ロックするための銀行口座の残高が不足していることが通知される際の条件が設定されるようにしてもよい。

【0497】

本変形例では、限定ではなく例として、ロック処理が行われたタイミングが特定日時であった場合、ロックするための銀行口座の残高が不足していることが即時にユーザに通知されず、限定ではなく例として、ロック処理が行われたタイミングが特定日時以外の日時であった場合、ロックするための銀行口座の残高が不足していることが即時にユーザに通知されるようにしてもよい。

【0498】

ここでの特定日時とは、限定ではなく例として、以下のような日（または日時）を含めるようにしてもよい。
・給料振込日の前日
・口座引き落とし日の翌日
・臨時収入日前の一週間

【0499】

給料振込日の前日は、限定ではなく例として、その翌日にユーザの銀行口座に給料が振り込まれることが予想されるため、給料振込日の前日にロックするための銀行口座の残高が不足していた場合であっても、そのことを即時にユーザに通知する必要性が低く、即時に通知することから除外するようにしてもよい。
この給料振込日は、限定ではなく例として、ユーザが銀行サーバ６０の銀行口座ユーザ管理データなどに登録してもよいし、銀行サーバ６０がユーザの毎月の取引内容を参照することによって算出し、銀行口座ユーザ管理データなどに登録するようにしてもよい。

【0500】

口座引き落とし日の翌日は、限定ではなく例として、その前日にユーザの銀行口座の残高からクレジットカード決済の振り替えが行われ、残高が減少していることが予想されるため、口座引き落とし日の翌日にロックするための銀行口座の残高が不足していた場合であっても、そのことを即時にユーザに通知する必要性が低く、即時に通知することから除外するようにしてもよい。
この口座引き落とし日は、限定ではなく例として、ユーザが銀行サーバ６０の銀行口座ユーザ管理データなどに登録してもよいし、銀行サーバ６０がユーザの毎月の取引内容を参照することによって算出し、銀行口座ユーザ管理データなどに登録するようにしてもよい。

【0501】

臨時収入日前の一週間は、限定ではなく例として、その数日後にユーザの銀行口座に臨時収入が振り込まれることが予想されるため、臨時収入日前の一週間にロックするための銀行口座の残高が不足していた場合であっても、そのことを即時にユーザに通知する必要性が低く、即時に通知することから除外するようにしてもよい。
この臨時収入日は、限定ではなく例として、ユーザが銀行サーバ６０の銀行口座ユーザ管理データなどに登録してもよいし、銀行サーバ６０がユーザの毎月の取引内容を参照することによって算出し、銀行口座ユーザ管理データなどに登録するようにしてもよい。
具体的には、毎月の取引内容のうち、限定ではなく例として、給料振込日以外で銀行口座の残高に「１００，０００円」以上の入金があった場合、この日を臨時収入日とするようにしてもよい。

【0502】

なお、ロック処理が行われたタイミングが特定日時であったとき、ロックするための銀行口座の残高が不足していることが即時にユーザに通知されなかった場合であって、その後の所定のタイミングでロック予定金額がロックされていない場合には、ロックするための銀行口座の残高が不足していることがユーザに通知されるようにしてもよい。
ここでの所定のタイミングとは、限定ではなく例として、以下のようなタイミングを含めるようにしてもよい。
・給料振込日以降のタイミング
・口座引き落とし日の一週間後以降のタイミング
・臨時収入日以降のタイミング

【0503】

給料振込日以降のタイミングは、限定ではなく例として、ユーザの銀行口座に給料が振り込まれた後であるため、このタイミングでロックするための銀行口座の残高が不足している場合は、クレジットカード決済の口座引き落としに関して問題が発生する可能性が高いので、ロックするための銀行口座の残高が不足していることを通知するようにしてもよい。

【0504】

口座引き落とし日の一週間後以降のタイミングは、限定ではなく例として、ユーザの銀行口座からクレジットカード決済の口座引き落としが終了し、一週間が経過した後であるため、このタイミングでロックするための銀行口座の残高が不足している場合は、クレジットカード決済の翌月の口座引き落としに関して問題が発生する可能性が高いので、ロックするための銀行口座の残高が不足していることを通知するようにしてもよい。

【0505】

臨時収入日以降のタイミングは、限定ではなく例として、ユーザの銀行口座に臨時収入が振り込まれた後であるため、このタイミングでロックするための銀行口座の残高が不足している場合は、クレジットカード決済の口座引き落としに関して問題が発生する可能性が高い。このため、ロックするための銀行口座の残高が不足していることを通知するようにしてもよい。

【0506】

この場合、限定ではなく例として、図１－２３等の処理のＢ１０２０のロック処理において、銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額をロックできなかった場合、Ｂ１０３０のロック結果情報に、限定ではなく例として、ロックするための銀行口座の残高が不足していることをユーザに通知する通知情報を含めることができる。

【0507】

ここで、限定ではなく例として、ロック処理が行われたタイミングが特定日時である場合、ロックするための銀行口座の残高が不足していることをユーザに通知する通知情報を含めないようにし、限定ではなく例として、ロック処理が行われたタイミングが特定日時でない場合、ロックするための銀行口座の残高が不足していることをユーザに通知する通知情報を含めるようにしてもよい。

【0508】

そして、ロック処理が行われたタイミングが特定日時でない場合、このロックするための銀行口座の残高が不足していることをユーザに通知する通知情報を含むロック結果情報を受信したユーザＡ．Ａの端末２０の制御部２１によって、限定ではなく例として、ロック結果情報が表示部２４に表示されることによって、ユーザＡ．Ａはロックするための銀行口座の残高が不足していることを認識することができる。
一方で、ロック処理が行われたタイミングが特定日時である場合、このロックするための銀行口座の残高が不足していることをユーザに通知する通知情報を含まないロック結果情報を受信したユーザＡ．Ａの端末２０の制御部２１によって、限定ではなく例として、ロック結果情報が表示部２４に表示されることによって、ユーザＡ．Ａはロックするための銀行口座の残高が不足していることを認識しないようにすることができる。

【0509】

＜第６実施例＞
第６実施例は、銀行口座の残高のうちクレジットカード決済における購入品の品目の種別に応じて、ロック可能な金額が設定される場合に関する実施例である。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0510】

本実施例では、クレジットカード決済における購入品の品目の種別に応じて、銀行口座の残高のうちロック可能な金額（以下、適宜「ロック上限金額」や「ロック可能金額」等と称する。）を設定することができるようにしてもよい。

【0511】

このロック上限金額は、限定ではなく例として、クレジットカード決済における購入品の品目の種別に応じて設定された金額であるものとしてもよい。
本例では、前述した第１種別（食品、外食費）の品目の購入品に対応するロック上限金額には、限定ではなく例として、第１設定金額が設定されるようにしてもよく、前述した第２種別（日用品）の品目の購入品に対応するロック上限金額には、限定ではなく例として、第２設定金額が設定されるようにしてもよい。
限定ではなく例として、第１設定金額として「５０，０００円」、第２設定金額として「３０，０００円」が設定されるようにしてもよい。これらのロック上限金額は、限定ではなく例として、ユーザが任意に決定できるようにしてもよいし、限定ではなく例として、ユーザが決定することはできず、家計管理サーバ１０、クレジットカード会社サーバ５０、または、銀行サーバ６０のいずれかが任意に決定できるようにしてもよい。

【0512】

また、同じ種別の品目の購入品の購入金額の合計の金額を、限定ではなく例として、適宜「種別合計金額」と称し、この種別合計金額がロック上限金額を超える場合に、限定ではなく例として、ユーザによるクレジットカード決済の利用を制限するようにしてもよい。この制限方法として、限定ではなく例として、以下のようなものが含まれるようにしてもよい。
以下では、種別合計金額がロック上限金額を超える状態を、限定ではなく例として、適宜「超過状態」や「ロック上限超過状態」と称する。

【0513】

“Ｆ０１”：超過状態であることをユーザに通知
“Ｆ０１”は、限定ではなく例として、超過状態であることを示す情報をユーザに通知することによって、その超過状態に対応した種別の品目の購入品をユーザがこれ以上購入しないように促すようにする制限方法とすることができる。

【0514】

また、この場合、超過状態であることをユーザに通知するタイミングとして、限定ではなく例として、以下のようなタイミングを含めることができる。
“ＴＦ１”：超過状態となる前のタイミング
“ＴＦ２”：超過状態となるタイミング
“ＴＦ３”：超過状態となった後のタイミング

【0515】

“ＴＦ１”は、限定ではなく例として、一の種別の品目の商品をクレジットカード決済で購入すると、その種別のロック金額が超過状態となってしまう場合、その取引の最終的な決定がなされる前のタイミングとすることができる。
具体的には、その取引の最終的な決定がなされる前のタイミングとして、限定ではなく例として、ＥＣサイト等において、その種別の商品に関する情報が表示されている商品画面を閲覧しているときや、その種別の商品を購入するための購入画面を閲覧しているとき等としてもよい。

【0516】

“ＴＦ２”は、限定ではなく例として、一の種別の品目の商品をクレジットカード決済で購入し、その種別のロック金額が超過状態となる場合、その取引の最終的な決定がなされるタイミングとすることができる。
具体的には、その取引の最終的な決定がなされるタイミングとして、限定ではなく例として、ＥＣサイト等において、その種別の商品を購入し、クレジットカード決済が完了したことを通知するための決済完了画面を閲覧しているとき等としてもよい。

【0517】

“ＴＦ３”は、限定ではなく例として、一の種別の品目の商品をクレジットカード決済で購入し、その種別のロック金額が超過状態となった場合、その取引の最終的な決定がなされた後のタイミングとすることができる。
具体的には、その取引の最終的な決定がなされた後のタイミングとして、限定ではなく例として、ＥＣサイト等においてその種別の商品を購入した翌日や、購入日から数日経過した後のクレジットカード決済の口座引き落とし日の前日等としてもよい。

【0518】

＜データ構成＞
本実施例における銀行口座ユーザ管理データベース６５９の一例である銀行口座ユーザ管理データベース６５９１のデータ構成の一例を図６－１に示す。
このデータ構成では、前述した図１－１５と同様の部分についての説明を省略する。

【0519】

本実施例における銀行口座ユーザ管理データベース６５９１には、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとが記憶される。
本実施例における銀行口座入出金管理データには、限定ではなく例として、ロック合計金額と、そのロック合計金額に関する、購入品の品目の種別と、種別ロック金額と、ロック上限金額とが記憶される。

【0520】

ロック合計金額は、前述した図１－１５において説明したロック合計金額と同様とすることができる。

【0521】

種別は、この契約者ＩＤのユーザのロック合計合計金額のうち購入品の品目の種別に関する情報である。

【0522】

種別ロック金額は、この契約者ＩＤのユーザのロック合計金額のうち購入品の品目の種別に対応するロックされている合計の金額である。

【0523】

ロック上限金額は、この購入品の品目の種別に対応するロック可能な金額であり、任意の値が記憶される。

【0524】

このデータによれば、ユーザの銀行口座の口座残高に対応する金額（限定ではなく、第１金額の一例）が、購入品の品目の種別等のカテゴリに応じたロック上限金額によって概念的に複数分割され、このようにして複数分割された金額のうちの購入情報に基づく金額（限定ではなく、第２金額の一例）をロック設定させるようにすることができる。

【0525】

＜表示画面＞
図６－２は、本実施例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図６－２左側には、図１－１９中央と同様の画面を示しており、「Ａ銀行」の表示領域がユーザによってタッチされた状態が示されている。すると、限定ではなく例として、図６－２中央のような画面が表示される。

【0526】

この画面では、前述した帯グラフが表示され、この帯グラフでは、食費と日用品費との２つについて前述したロック領域が表示されている。
便宜的に、食費に対応するロック領域を「第１種ロック領域」と称し、日用品費に対応するロック領域を「第２種ロック領域」と称する。

【0527】

第１種ロック領域の横幅は、食費について口座残高に占めるロック上限金額の割合を示しており、第１種ロック領域は、異なるハッチングの２つの領域ＬＲ１１、ＮＬＲ１１に分けられている。
そして、第１種ロック領域のうち、左側の領域ＬＲ１１の横幅は、食費について、口座残高に占めるロック金額の割合であって、ロック上限金額に占めるロック金額の割合を示している。

【0528】

同様に、第２種ロック領域の横幅は、日用品費について口座残高に占めるロック上限金額の割合を示しており、第１種ロック領域と同様に、第２種ロック領域も、異なるハッチングの２つの領域ＬＲ２１、ＮＬＲ２１に分けられている。
そして、第２種ロック領域のうち、左側の領域ＬＲ２１の横幅は、日用品費について、口座残高に占めるロック金額の割合であって、ロック上限金額に占めるロック金額の割合を示している。

【0529】

限定ではなく例として、第１種ロック領域のうちの領域ＬＲ１１がユーザによってタッチされると、限定ではなく例として、図６－２右側のような表示に変わる。
この例では、取引履歴のうち、取引内容が「ロック」とされているレコードであって、支出項目が「食費」であるレコードが、タッチされた領域と同じハッチングが施されて表示されている。

【0530】

図６－３には、本実施例において端末２０Ａの表示部２４に表示される画面であって、限定ではなく例として、図３－２中央の画面等において、購入品の品目の種別ごとの個別指定によるロック設定を行うための「個別指定」が選択された場合に表示される画面の一例を示す図である。

【0531】

この画面では、支出項目として包括的な支出項目ではなく、個別具体的な支出項目についてロック上限金額を設定可能となっており、この例では、「食費」、「日用品費」といった個別具体的な支出項目が表示され、各々に関連付けて、ラジオボタンと、「上限指定」ボタンＢＴ５とが表示されている。

【0532】

図６－３左側、中央の画面に示すように、「食費」に関連付けられたラジオボタンがオンとされ、「上限指定」ボタンＢＴ５がユーザによってタッチされると、限定ではなく例として、図６－３右側のような画面が表示される。

【0533】

この画面は、「食費」に関するロック上限金額を設定するための画面であり、この例では、「支出項目“食費”の上限金額を指定してください」のテキストが表示され、その下に、ユーザが入力した金額が表示される金額表示領域Ｒ５が構成されている。ユーザは、限定ではなく例として、ＯＳのキーボードやアプリケーションのキーボードを立ち上げて金額を入力することができる。

【0534】

この例では、ユーザによって「５０，０００」の数字が入力されたことに基づき、金額表示領域には「５０，０００円」と表示されている。これは、食費のロック上限金額として「５０，０００円」が設定されたことを示している。この状態で、画面下部の「決定」ボタンＢＴ１がユーザによってタッチされると設定が完了する。

【0535】

図６－４には、本実施例において端末２０Ａの表示部２４に表示される画面であって、超過状態（ロック上限超過状態）であることをユーザに通知するための通知画面の一例を示している。
図６－４左側には、図５－２左側と同様のＯＳの待ち受け画面（ロック画面）を示している。
この例では、待ち受け画面の上部に、家計管理サービス（家計管理サーバ１０）を送信元とするプッシュ形式で通知される通知情報（プッシュ通知情報）であって、クレジットカード決済の利用金額のロックにより、銀行口座のロック上限金額を超過したことをユーザに通知する通知情報として、プッシュ通知情報ＰＮ５が表示されている。

【0536】

プッシュ通知情報ＰＮ５がユーザによってタッチされると、限定ではなく例として、端末２０Ａで家計管理アプリケーションが起動し、図６－４右側のような家計管理アプリケーションのおしらせ画面が表示される。
このおしらせ画面では、「ロック上限超過のおしらせ」として、クレジットカードの決済金額のロックにより、銀行口座のロック上限金額を超過した旨のテキストや、銀行口座の口座残高を確認するようユーザに促すテキストを含む通知情報が表示されている。

【0537】

＜処理＞
本実施例における処理の流れは、前述した各種のフローチャートの処理の流れを同様に適用可能であるため、図示を省略する。

【0538】

この場合、限定ではなく例として、図１－２３等の処理のＢ１０２０のロック処理において、銀行サーバ６０の制御部は、限定ではなく例として、受信したロック要求情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの種別、ロック金額、および、ロック合計金額のデータに、受信したロック金額に関する情報を記憶させる。

【0539】

そして、一の種別のロック金額がロック上限金額を超える場合（超過状態となる場合）、Ｂ１０３０のステップのロック結果情報に、限定ではなく例として、ロック金額が超過状態となることをユーザに通知する通知情報を含めることができる。

【0540】

このように、クレジットカード決済での取引により一の種別のロック金額が超過状態となる場合に、家計管理サーバ１０や銀行サーバ６０によって送信されたロック金額が超過状態となることをユーザに通知する通知情報を含むロック結果情報を受信したユーザＡ．Ａの端末２０の制御部２１によって、限定ではなく例として、ロック結果情報が表示部２４に表示されることによって、端末２０のユーザＡ．Ａにその種別のロック金額が超過状態となることを認識させることができ、その種別の品目の購入品をこれ以上購入することを抑制できる。

【0541】

＜第６実施例の効果＞
本実施例は、ユーザの口座に含まれる残高（限定ではなく、第１金額の一例）は、複数分割されたうちの一つの金額であり、ロック要求情報等の情報（限定ではなく、第１制御情報の一例）は、複数分割された口座に含まれる金額（限定ではなく、第１金額の一例）のうちの支払い情報に基づく金額（限定ではなく、第２金額の一例）をロック設定にするための情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザの口座に含まれる金額が複数分割されたうちの一つの金額を第１金額とし、この第１金額のうちの第２金額を第１設定にさせることができる。

【0542】

また、この場合、ユーザの口座に含まれる第１金額は、口座に含まれる金額が、ユーザによって購入品の種別等のカテゴリごとに分割されたうちの一つの金額であるようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザの口座に含まれる金額が、ユーザによってカテゴリごとに分割されたうちの一つの金額を第１金額とし、この第１金額のうちの第２金額を第１設定にさせることができる。

【0543】

＜第７実施例＞
以下、前述した（Ｂ）の手法を適用する場合の実施例について説明する。
なお、以下では、便宜的に、一般的に用いられる用語である「振替」と「振込」とを包括して「振替」と称する場合がある。つまり、便宜的に、「振込」を「振替」の一種として用いる場合がある。

【0544】

第７実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする実施例である。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0545】

以下、本実施例における、クレジットカード決済の利用金額に対応する金額を、第１の銀行口座から第２の銀行口座に振替し、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とするいくつかのパターンについて、表示画面や処理を例示する。

【0546】

＜（Ｇ１）第１パターン＞
（Ｇ１）第１パターンとして、ユーザ（契約者）が２つの異なる銀行でそれぞれ銀行口座を開設している場合に、クレジットカード決済での利用金額を、ユーザ（契約者）の銀行口座であって、クレジットカード決済の振替を行う銀行口座である第１の銀行口座から、ユーザの銀行口座であって、クレジットカード決済の振替を行わない銀行口座である第２の銀行口座に振替を行う場合を例示する。

【0547】

本実施例では、限定ではなく例として、第１の銀行口座を、適宜「主口座」や「メイン口座」と称し、第２の銀行口座を、適宜「副口座」や「サブ口座」と称する。
主口座は、限定ではなく例として、給料が振り込まれたり、クレジットカード決済の振替口座として設定されていたり、契約者個人の資産を管理するためであったり、日常生活の主となる入出金の際に使用される銀行口座であってもよい。
一方で、副口座は、限定ではなく例として、副業での給料が振り込まれたり、家計や趣味に関する入出金など、契約者が任意に設定した目的のために使用される銀行口座であってもよい。
このような銀行口座の種別を、適宜「口座種別」と称する。

【0548】

＜口座開設パターン＞
図７－１は、本実施例の（Ｇ１）第１パターンにおけるユーザ（契約者）の銀行口座の開設パターン（以下、適宜「口座開設パターン」と称する。）７１の一例を示す図である。
口座開設パターン７１は、銀行口座サービスを利用する端末２０または端末２０のユーザの口座開設パターンであり、限定ではなく例として、契約者氏名と、契約者ＩＤ（銀行口座ＩＤ）と、銀行名と、口座種別とが関連付けられている。

【0549】

契約者氏名は、銀行口座サービスを利用する端末２０のユーザの氏名であり、限定ではなく例として、端末２０のユーザが銀行口座を利用する際に登録する氏名である。

【0550】

契約者ＩＤ（銀行口座ＩＤ）は、銀行口座サービスを利用するユーザを識別するための識別情報として機能するＩＤである。

【0551】

銀行名は、この契約者ＩＤに対応した銀行の名称（限定ではなく例として、銀行の商号、愛称または通称等）である。

【0552】

口座種別は、この銀行口座ＩＤに対応する銀行口座の種別を示した情報である。

【0553】

本例では、口座開設パターン７１には、限定ではなく例として、契約者氏名として「＊＊＊＊」と、その契約者氏名「＊＊＊＊」が開設している契約者ＩＤ（銀行口座ＩＤ）として「ＵＢ０００１」，「ＵＢ２０３３」と、契約者ＩＤ（銀行口座ＩＤ）「ＵＢ０００１」に対応する、銀行名として「Ａ銀行」，口座種別として「主口座」と、契約者ＩＤ（銀行口座ＩＤ）「ＵＢ２０３３」に対応する、銀行名として「Ｂ銀行」，口座種別として「副口座」とが示されている。

【0554】

＜データ構成＞
本実施例の（Ｇ１）第１パターンにおける銀行口座ユーザ管理データベース６５９の一例である銀行口座ユーザ管理データベース６５９２のデータ構成の一例を図７－２に示す。
このデータ構成では、前述した図１－１５と同様の部分についての説明を省略する。

【0555】

本実施例の（Ｇ１）第１パターンにおける銀行口座ユーザ管理データベース６５９２には、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとに加えて、限定ではなく例として、他行口座管理データが記憶される。

【0556】

本実施例の（Ｇ１）第１パターンにおける銀行口座入出金管理データには、限定ではなく例として、前述した図１－１５と異なり、ロック金額と、利用可能残高とが記憶されていない。

【0557】

他行口座管理データは、この契約者ＩＤのユーザの銀行口座と紐づけられた他の銀行の銀行口座に関するデータであり、限定ではなく例として、銀行口座ＩＤと、銀行名とが記憶される。
なお、銀行口座ＩＤと、銀行名については前述したものと同様であるので説明を省略する。

【0558】

前述したように、銀行口座ＩＤは、この契約者ＩＤのユーザの銀行口座を識別するための情報である。
この他行口座管理データの銀行口座ＩＤによって、この契約者ＩＤのユーザの銀行口座と紐づけられた他の銀行の銀行口座が特定される。

【0559】

＜表示画面＞
図７－３～図７－４は、本実施例の（Ｇ１）第１パターンにおいて端末２０Ｍ（ユーザＭ．Ｍの端末２０）の表示部２４に表示される画面の一例を示す図である。
ここでは、ユーザＭ．Ｍが、Ａ銀行とＢ銀行とにそれぞれ銀行口座を開設しており、クレジットカード決済に基づき、その利用金額が、Ａ銀行の銀行口座からＢ銀行の銀行口座に振り込まれる場合を例示する。この例では、Ａ銀行の銀行口座が「主口座」となり、Ｂ銀行の銀行口座が「副口座」となる。

【0560】

ここでは、端末２０にダウンロードされて使用される銀行アプリケーションの画面の一例を示す。

【0561】

図７－３には、Ａ銀行が提供する銀行アプリケーションの一例であるＡ銀行アプリケーションの画面の一例を示している。
画面最上部には、アプリケーションの名称である「Ａ銀行Ａｐｐ」と、ユーザＭ．Ｍのアイコン画像およびユーザ名とを含む領域が表示されている。
また、その下には、表示させる情報をユーザが選択するためのタブ領域が設けられており、この例では、「ホーム」と、「おしらせ」と、「設定」とを含むタブ領域が表示されている。そして、この例では、「ホーム」タブが選択された状態が示されている。

【0562】

その下には、ユーザＭ．ＭのＡ銀行の銀行口座に関する情報を表示する口座情報表示領域が構成されている。この例では、口座情報表示領域には、契約者氏名と、支店名と、銀行口座種別と、銀行口座番号とが表示されている。
また、この口座情報表示領域の下には、この銀行口座の口座残高（この例では「６５４，３２１円」）の情報を表示する口座残高表示領域が構成されている。

【0563】

その下には、ユーザが明細を確認するための「明細」ボタンＢＴ９と、ユーザが各種の手続きをするための「各種手続き」ボタンと、ユーザが定期預金を行うための「定期預金」ボタンとが表示されている。

【0564】

限定ではなく例として、ユーザが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済を行ったとする。

【0565】

図７－３中央には、図７－３左側と同様の画面を示しているが、上記のクレジットカード決済に基づき、口座残高が「６５４，３２１円」から「２０，０００円」減少して「６３４，３２１円」となった状態が示されている。これは、以下説明する取引履歴に示されるように、本口座（Ａ銀行の銀行口座）からＢ銀行の銀行口座に「２０，０００円」が振り込まれたことに基づく。

【0566】

「明細」ボタンＢＴ９がユーザによってタッチされると、限定ではなく例として、図７－３右側の画面が表示される。
この画面は、ユーザが本口座の明細を確認するための明細画面であり、この例では、画面上部に口座残高が表示され、その下に、この銀行口座の取引履歴がリスト形式で表示されている。

【0567】

取引履歴には、限定ではなく例として、日付と、取引内容と、入出金金額とが関連付けられている。
上記のように、ユーザＭ．Ｍが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済を行ったことに基づき、取引履歴の日付「２０２２／１２／０１」には、取引内容として「振込 Ｂ銀行」が、入出金金額として「－２０，０００円」がそれぞれ表示されている。
これは、本口座からＢ銀行の銀行口座に「２０，０００円」が送金された（振り込まれた）ことを示している。

【0568】

図７－４には、Ｂ銀行が提供する銀行アプリケーションの一例であるＢ銀行アプリケーションの画面の一例を示している。
画面最上部には、アプリケーションの名称である「Ｂ銀行Ａｐｐ」と、ユーザＭ．Ｍのアイコン画像およびユーザ名とを含む領域が表示されている。
また、その下には、表示させる情報をユーザが選択するためのタブ領域が設けられており、この例では、「ホーム」と「設定」とを含むタブ領域が表示されている。そして、この例では、「ホーム」タブが選択された状態が示されている。

【0569】

その下には、ユーザＭ．ＭのＢ銀行の銀行口座に関する情報が表示される口座情報表示領域が構成されている。この例では、口座情報表示領域には、契約者名と、支店名と、銀行口座種別と、銀行口座番号と、「明細」ボタンＢＴ９とが表示されている。
また、この口座情報表示領域の下には、この銀行口座の口座残高（この例では「１２３，４５６円」）の情報を表示する口座残高表示領域が構成されている。

【0570】

図７－４中央には、図７－４左側と同様の画面であって、前述したように「２０２２年１２月１日」に、Ａ銀行の銀行口座から本口座（Ｂ銀行の銀行口座）に「２０，０００円」が振り込まれた場合に表示される画面を示している。
口座残高が「１２３，４５６円」から「２０，０００円」増加して「１４３，４５６円」となった状態が示されている。

【0571】

「明細」ボタンＢＴ９がユーザによってタッチされると、限定ではなく例として、図７－４右側のような画面が表示される。
この画面は、本口座の取引履歴等をユーザが確認するための明細画面であり、上部には、この銀行口座の残高が表示されており、図７－４中央の画面と同じ値の残高が表示されている。

【0572】

その下には、この銀行口座の取引履歴が表示されている。この例では、取引履歴は、日付と、取引内容と、入出金金額とが関連付けられてリスト形式で表示されている。
取引履歴の日付「２０２２／１２／０１」には、取引内容として「振込 Ａ銀行」が、入出金金額として「＋２０，０００円」が表示されている。
これは、Ａ銀行から送金された「２０，０００円」が本口座で受金（着金）されたことを示している。

【0573】

＜処理＞
図７－５は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理、Ｂ銀行サーバ６０Ｂの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図１－２３と同様である部分についての説明を省略する。

【0574】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／Ｆによってクレジットカード会社サーバ５０から購入情報を受信したか否かを判定する（ＢＡ７０１０）。この購入情報には、少なくともクレジットカード決済の利用金額の情報を含めることができる。

【0575】

購入情報を受信しなかったと判定する場合（ＢＡ７０１０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ７０２０～ＢＡ７０３０のステップをスキップする。

【0576】

購入情報を受信したと判定する場合（ＢＡ７０１０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、振替処理を実行する（ＢＡ７０２０）。
振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している主口座としての銀行口座（銀行口座ＩＤ）を特定し、その主口座としての銀行口座に紐付けられている副口座としての銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を減算して記憶させる。

【0577】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に基づいて、振替先であるユーザのＢ銀行の銀行口座ＩＤに関する情報と、ユーザのＡ銀行の銀行口座からＢ銀行の銀行口座にクレジットカード決済での購入金額を振替することに関する情報とを含む振替情報を、Ｂ銀行サーバ６０Ｂに送信する（ＢＡ７０３０）。

【0578】

Ｂ銀行サーバ６０Ｂの制御部は、通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替情報を受信したか否かを判定する（ＢＢ７０１０）。
振替情報を受信しなかったと判定する場合（ＢＢ７０１０：ＮＯ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、ＢＢ７０２０～ＢＢ７０３０のステップをスキップする。

【0579】

振替情報を受信したと判定する場合（ＢＢ７０１０：ＹＥＳ）、Ｂ銀行サーバ６０Ｂの制御部は、振替処理を実行する（ＢＢ７０２０）。
振替処理において、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、受信した振替情報に含まれる、振替先であるＢ銀行の銀行口座ＩＤに関する情報と、購入金額に関する情報とに基づいて、銀行口座ユーザ管理データベース６５９に記憶される銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を加算して記憶させる。

【0580】

そして、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、Ｂ銀行サーバ６０での振替処理の結果に関する情報を含む振替結果情報を、通信Ｉ／ＦによってＡ銀行サーバ６０Ａに送信する（ＢＢ７０３０）。

【0581】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替結果情報を受信したか否かを判定する（ＢＡ７０４０）。
通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替結果情報を受信しなかったと判定する場合（ＢＡ７０４０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ７０５０のステップをスキップする。

【0582】

通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替結果情報を受信したと判定する場合（Ｂ７０４０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、Ｂ銀行サーバ６０Ｂから受信した振替結果情報と同様の振替結果情報を、通信Ｉ／Ｆによって端末２０に送信する。

【0583】

端末２０の制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信したか否かを判定する（Ａ７０１０）。
通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信しなかったと判定する場合（Ａ７０１０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ７０２０のステップをスキップする。

【0584】

通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信したと判定する場合（Ａ７０１０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、受信した振替結果情報に基づいて、振替結果情報を表示部２４に表示させる（Ａ７０２０）。

【0585】

なお、これらのステップの処理の後、図７－５では図示を省略しているが、以下のような処理が実行されるようにしてもよい。
Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、クレジットカード決済がなされたときに、ユーザの主口座であるＡ銀行の銀行口座からユーザの副口座であるＢ銀行の銀行口座に振替された金額を、ユーザの主口座であるＡ銀行の銀行口座に再度振替を行う再振替処理を実行するための条件が成立しているか否かを判定する。
この条件には、限定ではなく例として、「現在日時がクレジットカードの口座引き落とし日の前日である」等を含めるようにしてもよい。

【0586】

この条件が成立していないと判定する場合には、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、前述した副口座から主口座への再振替処理をスキップする。

【0587】

この条件が成立したと判定する場合には、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、前述した副口座から主口座への再振替処理を実行する。
この再振替処理は、限定ではなく例として、前述した振替処理と同様であるので、説明を省略する。

【0588】

そして、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、再振替処理の実行結果に基づいて、振替先であるユーザのＡ銀行の銀行口座ＩＤに関する情報と、ユーザのＢ銀行の銀行口座からＡ銀行の銀行口座にクレジットカード決済での購入金額を再度振替することに関する情報とを含む再振替情報を、Ａ銀行サーバ６０Ａに送信する。

【0589】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから再振替情報を受信したか否かを判定する。
通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから再振替情報を受信しなかったと判定する場合、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、以降のＡ銀行サーバ６０Ａによって実行される再振替処理に関する処理のステップをスキップする。

【0590】

通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから再振替情報を受信したと判定する場合、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、再振替処理を実行する。
この再振替処理は、限定ではなく例として、前述した振替処理と同様であるので、説明を省略する。

【0591】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、Ａ銀行サーバ６０Ａでの再振替処理の結果に関する情報を含む再振替結果情報を、通信Ｉ／Ｆによって端末２０に送信する。

【0592】

端末２０の制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから再振替結果情報を受信したか否かを判定する。
通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから再振替結果情報を受信しなかったと判定する場合、端末２０の制御部２１は、限定ではなく例として、再振替結果情報の表示に関する処理のステップをスキップする。

【0593】

通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから再振替結果情報を受信したと判定する場合、端末２０の制御部２１は、限定ではなく例として、Ａ銀行サーバ６０Ａから受信した再振替結果情報に基づいて、再振替結果情報を表示部２４に表示させる。

【0594】

このように、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座であるユーザの主口座からクレジットカードの支払い口座でないユーザの副口座に振替を行うことによって、クレジットカードの引き落としを行うときの残高を確保することができ、クレジットカードの引き落としを確実に行うことができる。

【0595】

＜（Ｇ２）第２パターン＞
（Ｇ２）第２パターンとして、ユーザ（契約者）が１つの銀行で２つの銀行口座を開設している場合に、クレジットカード決済での利用金額を、ユーザ（契約者）の銀行口座であって、クレジットカード決済の振替を行う銀行口座である第１の銀行口座から、ユーザの銀行口座であって、クレジットカード決済の振替を行わない銀行口座である第２の銀行口座に振替を行う場合を例示する。

【0596】

ここで、１つの銀行において２つの銀行口座を開設する手法として、以下のようなものを含めることができる。
（Ｘ）１つの銀行口座ＩＤに対応する２つの銀行口座
（Ｙ）２つの銀行口座ＩＤの各々に対応する２つの銀行口座

【0597】

（Ｘ）１つの銀行口座ＩＤに対応する２つの銀行口座とは、限定ではなく例として、契約者１人に対して１つの銀行口座ＩＤが割り当てられ、その契約者１人に対して２つの銀行口座が開設できるようにしてもよい。この２つの銀行口座のうち１つの銀行口座は、限定ではなく例として、一般的に銀行が契約者に提供する現実の銀行口座とは異なる仮想の銀行口座であってもよい。
以下では、限定ではなく例として、現実の銀行口座を、適宜「現実口座」や「現実銀行口座」等と称し、限定ではなく例として、仮想の銀行口座を、適宜「仮想口座」や「仮想銀行口座」等と称する。

【0598】

この仮想口座は、限定ではなく例として、現実口座の銀行口座ＩＤに紐付いており、仮想口座用の銀行口座ＩＤ（以下、適宜「仮想口座ＩＤ」と称する。）が割り当てられてもよいものとする。
なお、一の現実口座の銀行口座ＩＤに対して、２よりも多い複数の仮想口座が紐付けられてもよいものとする。

【0599】

この仮想口座は、限定ではなく例として、契約者が任意に開設することができ、限定ではなく例として、契約者の使途に応じて銀行口座を使い分けるようにしてもよい。

【0600】

（Ｙ）２つの銀行口座ＩＤの各々に対応する２つの銀行口座とは、限定ではなく例として、契約者１人に対して２つの銀行口座ＩＤが割り当てられ、契約者１人に対してそれらの２つの銀行口座ＩＤに対応する２つの銀行口座が開設できるようにしてもよい。この２つの銀行口座は、限定ではなく例として、一般的に銀行が契約者に提供する現実の銀行口座であってもよい。

【0601】

＜口座開設パターン＞
図７－６は、本実施例の（Ｇ２）第２パターンにおけるユーザ（契約者）の口座開設パターンの一例を示す図である。
口座開設パターン７２は、銀行口座サービスを利用する端末２０または端末２０のユーザの口座開設パターンであり、このデータ構成では、前述した図７－１と同様の部分についての説明を省略する。

【0602】

口座開設パターン７２には、限定ではなく例として、契約者氏名と、契約者ＩＤ（銀行口座ＩＤ）と、銀行名と、口座種別とに加えて、仮想口座ＩＤが関連付けられている。

【0603】

仮想口座ＩＤは、銀行口座サービスの仮想口座を利用するユーザを識別するための識別情報として機能するＩＤである。

【0604】

本例では、口座開設パターン７２には、限定ではなく例として、契約者氏名として「＊＊＊＊」と、その契約者氏名「＊＊＊＊」が開設している契約者ＩＤ（銀行口座ＩＤ）として「ＵＢ０００１」と、契約者ＩＤ（銀行口座ＩＤ）「ＵＢ０００１」に紐付けられている仮想口座ＩＤとして「ＶＢ０００１」、銀行名として「Ａ銀行」，口座種別として「主口座」，「副口座」とが示されている。
ここでは、銀行口座ＩＤ「ＵＢ０００１」のうち仮想口座が紐付けられていない銀行口座は、限定ではなく例として、ユーザの主口座としての現実口座であり、銀行口座ＩＤ「ＵＢ０００１」のうち仮想口座が紐付けられている銀行口座は、限定ではなく例として、ユーザの副口座としての仮想口座である。

【0605】

＜データ構成＞
本実施例の（Ｇ２）第２パターンにおける銀行口座ユーザ管理データベース６５９の一例である銀行口座ユーザ管理データベース６５９３のデータ構成の一例を図７－７に示す。
このデータ構成では、前述した図７－２と同様の部分についての説明を省略する。

【0606】

本実施例の（Ｇ２）第２パターンにおける銀行口座ユーザ管理データベース６５９３には、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとに加えて、限定ではなく例として、仮想口座管理データベースが記憶される。

【0607】

仮想口座管理データベースは、銀行口座ユーザ登録データ６５３に登録されているユーザの仮想口座に関する管理データを蓄積したデータベースである。

【0608】

仮想口座管理データベースには、銀行口座ユーザ登録データ６５３に記憶されている契約者ＩＤごとの仮想口座の管理データとして仮想口座管理データが記憶される。

【0609】

各々の仮想口座管理データには、限定ではなく例として、仮想口座ＩＤと、仮想口座入出金データとが記憶される。

【0610】

仮想口座ＩＤは、この契約者ＩＤのユーザの銀行口座と紐づけられた仮想口座を識別するための識別情報として機能するＩＤである。

【0611】

仮想口座入出金管理データは、この仮想口座ＩＤの銀行口座の入出金に関するデータであり、限定ではなく例として、残高と、日時と、取引内容と、入出金金額等が記憶される。

【0612】

残高は、この仮想口座ＩＤの銀行口座の残高に関する情報であり、限定ではなく例として、仮想口座の残高金額が記憶される。

【0613】

日時は、この仮想口座ＩＤの銀行口座の入出金の日時に関する情報であり、限定ではなく例として、「年／月／日」等が記憶される。

【0614】

取引内容は、この仮想口座ＩＤの銀行口座の入出金の取引内容に関する情報であり、限定ではなく例として、入出金の詳細な内容に関する情報等が記憶される。

【0615】

入出金金額は、この仮想口座ＩＤの銀行口座の入出金の金額に関する情報であり、限定ではなく例として、入出金の金額に関する情報等が記憶される。

【0616】

＜表示画面＞
図７－８～図７－９は、本実施例の（Ｇ２）第２パターンにおいて端末２０Ｍ（ユーザＭ．Ｍの端末２０）の表示部２４に表示される画面の一例を示す図である。
ここでは、前述したＡ銀行の銀行アプリケーションの画面の一例を示す。

【0617】

図７－８には、Ａ銀行の銀行アプリケーションの画面の一例を示しており、図７－８左側に示すように、この例では、画面上部に「現実口座」のテキストを含む領域が構成され、その下に、この現実口座に関する情報が表示される現実口座情報表示領域Ｒ１１が構成されている。
また、その下には、「仮想口座」のテキストを含む領域が構成され、その下に、この仮想口座に関する情報が表示される仮想口座情報表示領域Ｒ１３が構成されている。

【0618】

現実口座情報表示領域Ｒ１１には、限定ではなく例として、契約者名と、この現実口座の口座番号（この例では「＊＊＊＊５２８」）と、この現実口座の口座残高（この例では「６５４，３２１円」）とが表示されている。
現実口座の口座番号は、ユーザＭ．ＭがＡ銀行に口座を開設した場合にＡ銀行の銀行サーバ６０によって設定された現実の口座番号とされている。

【0619】

仮想口座情報表示領域Ｒ１３には、限定ではなく例として、契約者名と、この仮想口座の口座番号（この例では「ｖ＊＊＊０１」）と、この仮想口座の口座残高（この例では「１２３，４５６円」）とが表示されている。
仮想口座は現実口座に紐付けられ、仮想口座の口座番号は、Ａ銀行の銀行サーバ６０によって設定された仮想的な口座番号とされている。

【0620】

図７－８中央には、前述した図７－３～図７－４の例と同様に、「２０２２年１２月１日」にユーザＭ．Ｍが「２０，０００円」のクレジットカード決済を行った場合に表示される画面を示している。
この例では、現実口座から仮想口座に「２０，０００円」を振り替える処理が行われ、その結果、現実口座情報表示領域Ｒ１１の口座残高が「６３４，３２１円」に減少し、仮想口座情報表示領域Ｒ１３の口座残高が「１４３，４５６円」に増加した状態が示されている。

【0621】

限定ではなく例として、仮想口座情報表示領域Ｒ１３がユーザによってタッチされると、限定ではなく例として、図７－８右側のような画面が表示される。
この画面は、Ａ銀行アプリケーションの「ホーム」の画面であり、その構成は、限定ではなく例として図７－３左側に示した画面と同様の画面となっている。
この例では、口座情報表示領域には、ユーザＭ．Ｍの現実口座の口座情報が表示されており、契約者名、支店名、銀行口座種別、銀行口座番号が表示されている。銀行口座番号は、現実口座の口座番号と同じ番号が表示されている。

【0622】

また、その下の残高情報表示領域には、図７－８中央の画面において仮想口座情報表示領域Ｅ１３がタッチされたことに基づき、仮想口座の口座残高（この例では「１４３，４５６円」）が表示されている。

【0623】

この状態で「明細」ボタンＢＴ９がユーザによってタッチされると、限定ではなく例として、図７－９左側の画面が表示される。
この画面は、仮想口座の明細画面であり、画面上部には、「仮想口座」のテキストとともに、この仮想口座の口座番号が表示される領域が構成されている。
また、その下には、この仮想口座の口座残高が表示される領域が構成されている。

【0624】

その下には、仮想口座の取引履歴が表示されており、日付と、取引内容と、入出金金額とが関連付けられたリスト形式で表示されている。
この例では、日付「２０２２／１２／０１」に、取引内容として「振替 Ａ銀行 現実口座」が表示され、入出金金額として「＋２０，０００円」と表示されている。
これは、現実口座から本口座（仮想口座）に「２０，０００円」が振り替えられたことを示している。

【0625】

＜処理＞
図７－１０は、本実施例の（Ｇ２）第２パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図１－２３と同様である部分についての説明を省略する。

【0626】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０からＡ銀行サーバ６０Ａに送信されたことに基づいて、そのクレジットカード決済に対応する金額が、ユーザの主口座であるＡ銀行の現実口座からユーザの副口座であるＡ銀行の仮想口座に振替される場合を例示する。

【0627】

この場合、ＢＡ７０２０の振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している主口座としての銀行口座（銀行口座ＩＤ）を特定し、その主口座としての銀行口座に紐付けられている副口座としての仮想口座（仮想口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を減算して記憶させるとともに、特定した仮想口座に対応する仮想口座入出金管理データの残高のデータに、受信した購入金額に関する情報を加算して記憶させる。

【0628】

図７－１０に図示したステップの処理の後、図７－５において説明したような再振替処理が実行されるようにしてもよい（不図示）。
この場合、ユーザの副口座であるＡ銀行の仮想口座からユーザの主口座であるＡ銀行の現実口座に再振替処理が実行されるようにすることができる。

【0629】

＜（Ｇ３）第３パターン＞
（Ｇ３）第３パターンとして、ユーザ（契約者）が２つの異なる銀行でそれぞれ銀行口座を開設している場合に、クレジットカード決済での利用金額を、ユーザの銀行口座であって、クレジットカード決済の振替を行わない銀行口座である第２の銀行口座から、ユーザ（契約者）の銀行口座であって、クレジットカード決済の振替を行う銀行口座である第１の銀行口座に振替を行う場合を例示する。

【0630】

＜データ構成＞
本実施例の（Ｇ３）第３パターンにおけるクレジットカード決済ユーザ管理データベース５５９の一例であるクレジットカード決済ユーザ管理データ５５９１のデータ構成の一例を図７－１１に示す。
このデータ構成では、前述した図１－１０と同様の部分についての説明を省略する。

【0631】

本実施例の（Ｇ３）第３パターンにおけるクレジットカード決済ユーザ管理データ５５９１には、限定ではなく例として、契約者ＩＤと、取引管理データと、登録銀行口座管理データとが記憶される。

【0632】

本実施例の（Ｇ３）第３パターンにおける登録銀行口座管理データには、限定ではなく例として、このクレジットカードの支払い口座である銀行口座（支払い口座）に関する情報と、このクレジットカードの支払い口座でない銀行口座（以下、適宜「関連口座」と称する。）に関する情報とが記憶される。

【0633】

このクレジットカードの支払い口座である銀行口座に関する情報として、限定ではなく例として、銀行口座ＩＤと、口座引き落としトークンとが記憶される。
また、このクレジットカードの支払い口座でない銀行口座に関する情報として、限定ではなく例として、銀行口座ＩＤが記憶される。

【0634】

この登録銀行口座管理データの銀行口座ＩＤによって、この契約者ＩＤ（クレジットカードＩＤ）と紐づけられたユーザの主口座および副口座の銀行口座が特定される。

【0635】

本実施例の（Ｇ３）第３パターンにおける銀行口座ユーザ管理データベース６５９の一例である銀行口座ユーザ管理データベース６５９４のデータ構成の一例を図７－１２に示す。
このデータ構成では、前述した図７－２と同様の部分についての説明を省略する。

【0636】

本実施例の（Ｇ３）第３パターンにおける銀行口座ユーザ管理データベース６５９４には、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとに加えて、限定ではなく例として、他行口座管理データが記憶される。

【0637】

本実施例の（Ｇ３）第３パターンにおける他行口座管理データは、限定ではなく例として、銀行口座ＩＤと、銀行名とに加えて、限定ではなく例として、登録クレジットカードＩＤが記憶される。

【0638】

登録クレジットカードＩＤは、限定ではなく例として、対応する銀行口座ＩＤを支払い口座として登録しているクレジットカードのクレジットカードＩＤである。

【0639】

前述したように、銀行口座ＩＤおよびクレジットカードＩＤは、この契約者ＩＤのユーザの銀行口座を識別するための情報である。
この他行口座管理データの（登録）クレジットカードＩＤによって、この契約者ＩＤ（銀行口座ＩＤ）のユーザのクレジットカードと紐づけられた他の銀行の銀行口座（主口座）が特定される。

【0640】

＜表示画面＞
図７－１３～図７－１４は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。
図７－１３には、端末２０Ｍの表示部２４に表示されるＢ銀行の銀行アプリケーションの画面の一例を示しており、図７－１３左側に示すように、ユーザＭ．ＭのＢ銀行の銀行口座（関連口座）の口座残高として「１２３，４５６円」が表示されている。

【0641】

限定ではなく例として、ユーザＭ．Ｍが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済を行ったことに基づき、図７－１３中央の画面では、ユーザＭ．Ｍの口座残高が「１０３，４５６円」に減少している。

【0642】

この状態で「明細」ボタンＢＴ９がユーザによってタッチされると、限定ではなく例として、図７－１３右側の画面が表示される。
この画面は、Ｂ銀行の銀行口座の明細画面であり、取引履歴のうち、日付「２０２２／１２／０１」について、取引内容として「振込 Ａ銀行」が、入出金金額として「－２０，０００円」が表示されている。
これは、本口座（ユーザＭ．Ｍの関連口座）からＡ銀行の銀行口座（ユーザＭ．Ｍの支払い口座）に対して「２０，０００円」が送金された（振り込まれた）ことを示している。

【0643】

図７－１４には、端末２０Ｍの表示部２４に表示されるＡ銀行の銀行アプリケーションの画面の一例を示しており、図７－１４左側に示すように、ユーザＭ．ＭのＡ銀行の銀行口座（支払い口座）の口座残高として「６５４，３２１円」が表示されている。

【0644】

限定ではなく例として、ユーザＭ．Ｍが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済を行ったことに基づき、図７－１４中央の画面では、このユーザＭ．ＭのＡ銀行の銀行口座の口座残高が「６７４，３２１円」に増加している。

【0645】

この状態で「明細」ボタンＢＴ９がユーザによってタッチされると、限定ではなく例として、図７－１４右側の画面が表示される。
この画面は、Ａ銀行の銀行口座の明細画面であり、取引履歴のうち、日付「２０２２／１２／０１」について、取引内容として「振込 Ｂ銀行」が、入出金金額として「＋２０，０００円」が表示されている。
これは、Ｂ銀行の銀行口座（ユーザＭ．Ｍの関連口座）から送金された「２０，０００円」が本口座（ユーザＭ．Ｍの支払い口座）で受金されたことを示している。

【0646】

＜処理＞
図７－１５は、本実施例の（Ｇ３）第３パターンおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、Ｂ銀行サーバ６０Ｂの制御部が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図７－５と同様である部分についての説明を省略する。

【0647】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０によってユーザの副口座であるＢ銀行の銀行口座が開設されるＢ銀行サーバ６０Ｂに送信されたことに基づいて、そのクレジットカード決済に対応する金額が、ユーザの副口座であるＢ銀行の銀行口座からユーザの主口座であるＡ銀行の銀行口座に振替される場合を例示する。

【0648】

Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、通信Ｉ／Ｆによってクレジットカード会社サーバ５０から購入情報を受信したか否かを判定する（ＢＢ７４１０）。
購入情報を受信しなかったと判定する場合（ＢＢ７４１０：ＮＯ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、ＢＢ７４２０～ＢＢ７４３０のステップをスキップする。

【0649】

購入情報を受信したと判定する場合（ＢＢ７４１０：ＹＥＳ）、Ｂ銀行サーバ６０Ｂの制御部は、振替処理を実行する（ＢＢ７４２０）。

【0650】

振替処理において、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される他行口座管理データのうち、そのクレジットカードＩＤに対応する、クレジットカードを振替口座として登録している主口座としての銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を減算して記憶させる。

【0651】

そして、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、受信した購入情報に基づいて、振替先であるユーザのＡ銀行の銀行口座ＩＤに関する情報と、ユーザのＢ銀行の銀行口座からＡ銀行の銀行口座にクレジットカード決済での購入金額を振替することに関する情報とを含む振替情報を、通信Ｉ／ＦによってＡ銀行サーバ６０Ａに送信する（ＢＢ７４３０）。

【0652】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替情報を受信したか否かを判定する（ＢＡ７４１０）。
通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替情報を受信しなかったと判定する場合（ＢＡ７４１０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ７４２０～ＢＢ７４３０のステップをスキップする。

【0653】

通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから振替情報を受信したと判定する場合（ＢＡ７４１０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、振替処理を実行する（ＢＡ７４２０）。
振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した振替情報に含まれる、振替先であるＡ銀行の銀行口座ＩＤに関する情報と、購入金額に関する情報とに基づいて、銀行口座ユーザ管理データベース６５９に記憶される銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を加算して記憶させる。

【0654】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、Ａ銀行サーバ６０Ａでの振替処理の結果に関する情報を含む振替結果情報を、通信Ｉ／ＦによってＢ銀行サーバ６０Ｂに送信する（ＢＡ７４３０）。

【0655】

Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替結果情報を受信したか否かを判定する（ＢＢ７４４０）。
通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替結果情報を受信しなかったと判定する場合（ＢＢ７４４０：ＮＯ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、ＢＢ７４５０のステップをスキップする。

【0656】

通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替結果情報を受信したと判定する場合（ＢＢ７４４０：ＹＥＳ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、Ａ銀行サーバ６０Ａから受信した振替結果情報と同様の振替結果情報を、通信Ｉ／Ｆによって端末２０に送信する（ＢＢ７４５０）。

【0657】

なお、これらのステップの処理の後、（Ｇ１）第１パターンや（Ｇ２）第２パターンにおいて示したような、クレジットカードの利用に伴って、一の銀行口座から他の銀行口座に振替を行っていた利用金額を、元の銀行口座に再度振替を行う処理が実行されない。
（Ｇ３）第３パターンでは、限定ではなく例として、クレジットカードに利用に伴って、クレジットカードの支払い口座でない副口座からクレジットカードの支払い口座である主口座に、その利用金額の振替がなされるため、クレジットカードの引き落とし前に、その振替が行われた金額を元の銀行口座に再度振替を行う必要がない。

【0658】

このように、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座であるユーザの副口座からクレジットカードの支払い口座でないユーザの副口座に振替を行うことによって、クレジットカードの引き落としを行うときの残高を確保することができ、クレジットカードの引き落としを確実に行うことができる。
また、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座であるユーザの副口座からクレジットカードの支払い口座でないユーザの副口座に振替を行うことによって、再度振替を行う必要がなく、振替に係る手数料や振替に係る処理の負担を軽減化できる。

【0659】

なお、上記の処理では、ユーザの一の口座（第１口座）の残高に対応する金額、つまり、ユーザの第１口座の残高全部を第１金額とし、利用金額に対応する金額（限定ではなく、第２金額の一例）に対して振替等を行うための設定を行うこととした。
しかし、これに限定されるものではなく、第１実施例でも説明したように、第１金額を、ユーザの第１口座の残高のうちの一部の金額に対応する金額としてもよい。
同様に、第２金額を、利用金額のうちの一部の金額に対応する金額としてもよい。つまり、第２金額は、支払い情報に基づく金額であればよい。

【0660】

また、限定ではなく例として、銀行サーバ６０が、クレジットカード会社サーバ５０ではなく、店舗端末４０や端末２０から支払い情報を取得するようにしてもよい。

【0661】

＜第７実施例の効果＞
本実施例は、銀行サーバ６０（限定ではなく、情報処理装置の一例）が、後払いによる少なくとも利用金額の情報（限定ではなく、ユーザによって、後払いにより支払われる支払い情報の一例）と、ユーザに関するユーザ情報とを制御部６１によって取得する。
そして、銀行サーバ６０は、取得したユーザ情報に基づいて、ユーザの第１口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対して、限定ではなく例として振替等を行うための設定（限定ではなく、第１設定の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、取得されたユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額に対して第１設定を行うことができる。

【0662】

また、本実施例は、上記の第１設定は、ユーザの第１口座に含まれる金額のうち、取得した支払い情報に基づく金額を第１口座とは異なる第２口座に移動する設定を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザの第１口座に含まれる第１金額のうち、支払い情報に基づく第２金額を、第１口座とは異なる第２口座に移動する設定が行われることによって、限定ではなく例として、後払いによる支払いを行う分の金額を第２口座にプールさせるといったことが可能となる。

【0663】

また、この場合、第１口座と第２口座とは、銀行サーバ６０（限定ではなく、情報処理装置の一例）で管理されている口座であるようにしてもよい。
このような構成により得られる実施例の効果の一例として、情報処理装置で管理されている第１口座と第２口座とを用いて、上記の第１設定を行うことができるため、処理や管理を容易にすることができる。

【0664】

また、本実施例は、第２口座は、第１の銀行サーバ６０とは異なる第２の銀行サーバ（第２銀行サーバが提供する銀行サービス）（限定ではなく、情報処理装置とは異なるサービスの一例）によって管理されている口座である構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置とは異なるサービスによって管理されている第２口座を用いて、上記の第１設定を行うことができる。

【0665】

また、本実施例は、銀行サーバ６０は、設定された日にち、または日時に基づいて、副口座等の口座（限定ではなく、第２口座の一例）に振り替えられた第２金額を、主口座等の口座に再振替することに関する制御（限定ではなく、第２口座に移動された第２金額を、第１口座に移動することに関する制御の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、設定された日にち、または日時に基づいて、第２口座に移動された第２金額を、第１口座に移動することができる。これにより、限定ではなく例として、ユーザは、一旦振替等によって第２口座に移動させた金額を、口座引き落とし日の前日や数時間前等の日時に、第１口座に再び移動させるといったことが可能となる。

【0666】

＜第７変形例（１）＞
上記の実施例では、銀行サーバ６０が、クレジットカード会社サーバ５０から支払い情報を取得する場合を例示したが、これに限定されない。
限定ではなく例として、銀行サーバ６０が、家計管理サーバ１０から支払い情報を取得するようにしてもよい。

【0667】

この場合、限定ではなく例として、上記の処理において、家計管理サーバ１０は、クレジットカード会社サーバ５０等から購入情報を受信して取得する。
そして、家計管理サーバ１０の制御部１１は、限定ではなく例として、家計管理アプリケーションで登録されるなどして取得したユーザ情報に基づいて、振替要求情報（限定ではなく、支払い情報に基づく第２金額をユーザの第１口座から第２口座に移動することに関する制御情報の一例）を銀行サーバ６０に送信するようにすることができる。

【0668】

なお、ユーザ情報には、限定ではなく例として第１変形例（３）で示したような種々の情報を含めてよい。

【0669】

本変形例は、家計管理サーバ１０（限定ではなく、情報処理装置の一例）が、ユーザによるクレジットカード決済等の後払いにより支払われる少なくとも金額の情報を含む支払い情報と、そのユーザに関するユーザ情報とを制御部１１によって取得する。
そして、家計管理サーバ１０は、取得したユーザ情報に基づいて、そのユーザの銀行等の金融機関の口座（限定ではなく、ユーザの口座、ユーザの第１口座の一例）に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対して、限定ではなく例として振替設定（限定ではなく、第１設定の一例）を行うための振替要求情報等の情報（限定ではなく、第１制御情報の一例）を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる変形例の効果の一例として、ユーザによって、後払いにより支払われる支払い情報と、そのユーザに関するユーザ情報とを取得した上で、取得したユーザ情報に基づいて、そのユーザの口座に含まれる第１金額のうち、取得した支払い情報に基づく第２金額に対して第１設定を行うための第１制御情報が送信されることによって、支払い情報に基づく第２金額に対して第１設定を行わせることができる。

【0670】

本変形例は、家計管理サーバ１０（限定ではなく、情報処理装置の一例）が、ユーザによるクレジットカード決済等の後払いにより支払われる少なくとも金額の情報を含む支払い情報と、そのユーザに関するユーザ情報とを制御部１１によって取得する。
そして、家計管理サーバ１０は、取得したユーザ情報に基づいて、そのユーザの銀行等の金融機関の第１口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）を第１口座から第２口座に移動することに関する振替要求情報等の情報（限定ではなく、制御情報の一例）を通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する構成を示している。
このような構成により得られる変形例の効果の一例として、取得されたユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額を第１口座から第２口座に移動することに関する制御情報を送信することによって、第２金額を第１口座から第２口座に移動させることができる。

【0671】

＜第７変形例（２）＞
ユーザが複数のクレジットカードを所有しており、それぞれのクレジットカードに異なる銀行口座が紐づけられている場合があり得る。
この場合、限定ではなく例として、第１のクレジットカードのクレジットカード会社のサーバが、前述した図７－５～図７－１５のいずれの処理と同様の処理によって、対応する銀行サーバ６０に振替を要求し、第２のクレジットカードのクレジットカード会社のサーバが、前述した図７－５～図７－１５のいずれの処理と同様の処理によって、対応する銀行サーバ６０に振替を要求するようにしてもよい。

【0672】

また、この場合、各々のクレジットカード会社のサーバから銀行サーバ６０に対して振替の要求を行うことは煩雑である場合があり得る。
そこで、第７変形例（１）のように、家計管理サーバ１０を介在させ、各々のクレジットカード会社について、そのクレジットカード会社のクレジットカード決済による購入情報を取得する。そして、家計管理サーバ１０の制御部１１は、家計管理アプリケーションで登録されるなどして取得したユーザ情報に基づいて、対応する銀行の銀行サーバ６０に対して、振替要求情報（限定ではなく、支払い情報に基づく第２金額をユーザの第１口座から第２口座に移動することに関する制御情報の一例）を送信するようにしてもよい。

【0673】

なお、ユーザ情報には、限定ではなく例として第１変形例（３）で示したような種々の情報を含めてよい。

【0674】

また、本変形例では、ユーザ情報には、（ａ）クレジットカード決済の支払い口座に関する情報や、（ｂ）そのクレジットカード決済の支払い口座を管理するサービスに関する情報などが含まれるようにしてもよい。
以下では、このユーザ情報に含まれる情報の（ａ）や（ｂ）を、限定ではなく例として、前述した（Ｇ１）～（Ｇ３）のパターンごとに例示する。

【0675】

（Ｇ１）第１パターン
（ａ）：クレジットカードの支払い口座（主口座）に対応する銀行口座ＩＤ、銀行口座番号などの情報
（ｂ）：支払い口座（主口座）を管理する銀行に対応する銀行名、銀行ＩＤなどの情報

【0676】

（Ｇ２）第２パターン
（ａ）：クレジットカードの支払い口座（現実口座）に対応する銀行口座ＩＤ、銀行口座番号などの情報
（ｂ）：支払い口座（現実口座）を管理する銀行に対応する銀行名、銀行ＩＤなどの情報

【0677】

（Ｇ３）第３パターン
（ａ）：クレジットカードの支払い口座（主口座）に対応する銀行口座ＩＤ、銀行口座番号などの情報
（ｂ）：支払い口座（主口座）を管理する銀行に対応する銀行名、銀行ＩＤなどの情報

【0678】

本変形例は、ユーザ情報は、後払いにより支払いが行われるユーザの第１口座に関する情報、または後払いにより支払いが行われるユーザの第１口座を管理するサービス（限定ではなく例として、第１口座を管理する銀行のサービス）に関する情報を含む。
そして、家計管理サーバ１０（限定ではなく、情報処理装置の一例）が、取得した、後払いにより支払いが行われるユーザの第１口座に関する情報、または後払いにより支払いが行われるユーザの第１口座を管理するサービスに関する情報を含むユーザ情報に基づいて、ユーザの第１口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）を第１口座から第２口座に移動することに関する振替要求情報（限定ではなく、制御情報の一例）を通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する構成を示している。
このような構成により得られる変形例の効果の一例として、取得された、後払いにより支払いが行われるユーザの第１口座に関する情報、または後払いにより支払いが行われるユーザの第１口座を管理するサービスに関する情報を含むユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額を第１口座から第２口座に移動することに関する制御情報を送信することによって、第２金額を第１口座から第２口座に移動させることができる。

【0679】

＜第８実施例＞
第８実施例は、異なるクレジットカードＩＤを有する複数のクレジットカードがあるときに、これらのクレジットカードの支払い口座が共通の銀行口座である場合、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行う実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0680】

本実施例では、限定ではなく例として、クレジットカードに紐付けられた支払い口座としての銀行口座を、適宜「副口座」と称する。また、限定ではなく例として、クレジットカードに紐付けられた銀行口座であって、支払い口座とは異なる銀行口座を、適宜「主口座」と称する。
本実施例における主口座は、限定ではなく例として、給料が振り込まれたり、契約者個人の資産を管理するためであったり、日常生活の主となる入出金の際に使用される銀行口座であってもよい。
一方で、本実施例における副口座は、限定ではなく例として、クレジットカードの支払い、家計や趣味に関する入出金など、契約者が任意に設定した目的のために使用される銀行口座であってもよい。

【0681】

本実施例では、第１のユーザ（契約者）が２つの異なる銀行でそれぞれ銀行口座を開設しており、一方の銀行口座（第１Ａの銀行口座）を主口座とし、他方の銀行口座（第１Ｂの銀行口座）を副口座とする場合を例示する。
また、第２のユーザ（契約者）が１つの銀行で銀行口座を開設しており、その銀行口座を主口座（第２Ａの銀行口座）とする場合を例示する。

【0682】

以下では、前述した第１のユーザ（契約者）の主口座である銀行口座（第１Ａの銀行口座）と、第２のユーザ（契約者）の主口座である銀行口座（第２Ａの銀行口座）とを、適宜「関連口座」等と称する。
また、前述した第１のユーザ（契約者）の副口座である銀行口座（第１Ｂの銀行口座）を、適宜「共通支払い口座」や「共通口座」等と称する。

【0683】

具体的には、第１のユーザ（契約者）が利用する第１のクレジットカードの関連口座は、限定ではなく例として、第１のユーザの主口座（第１Ａの銀行口座）であり、第２のユーザ（契約者）が利用する第２のクレジットカードの関連口座は、限定ではなく例として、第２のユーザの主口座（第２Ａの銀行口座）である。

【0684】

また、第１のユーザ（契約者）が利用する第１のクレジットカードの支払い口座と、第２のユーザ（契約者）が利用する第２のクレジットカードの支払い口座とは、限定ではなく例として、第１のユーザの副口座（第１Ｂの銀行口座）である。

【0685】

以下、本実施例における異なるクレジットカードＩＤを有する複数のクレジットカードがあるときに、これらのクレジットカードの支払い口座が共通の銀行口座である場合、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行ういくつかのパターンについて、表示画面や処理を例示する。

【0686】

＜（Ｈ１）第１パターン＞
（Ｈ１）第１パターンとして、異なるクレジットカードＩＤを有する複数のクレジットカードがあるときに、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、共通の支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行うように、クレジットカード会社サーバ５０によって要求される場合を例示する。

【0687】

＜口座開設パターン＞
図８－１，図８－２は、本実施例の（Ｈ１）第１パターンにおける第１のユーザ（契約者）と第２のユーザとの口座開設パターンの一例を示す図である。

【0688】

口座開設パターン７３Ａは、銀行口座サービスを利用する端末２０Ｍまたは端末２０Ｍのユーザの口座開設パターンであり、その口座開設パターンの一例を図８－１に示す。このデータ構成では、前述した図７－１と同様の部分についての説明を省略する。

【0689】

本例では、口座開設パターン７３Ａには、限定ではなく例として、契約者氏名として「＊＊ＭＭ」と、契約者氏名「＊＊ＭＭ」が開設している銀行口座の契約者ＩＤ（銀行口座ＩＤ）として「ＵＢ０００１」と、この契約者ＩＤ（銀行口座ＩＤ）「ＵＢ０００１」に対応する、銀行名として「Ａ銀行」と、口座種別として「主口座」とが示されており、契約者氏名「＊＊ＡＡ」が開設している銀行口座の契約者ＩＤ（銀行口座ＩＤ）として「ＵＢ３０３３」と、この契約者ＩＤ（銀行口座ＩＤ）「ＵＢ３０３３」に対応する、銀行名として「Ｃ銀行」と、口座種別として「副口座」とが示されている。

【0690】

口座開設パターン７３Ｂは、銀行口座サービスを利用する端末２０Ｎまたは端末２０Ｎのユーザの口座開設パターンであり、その口座開設パターンの一例を図８－２に示す。このデータ構成では、前述した図７－１と同様の部分についての説明を省略する。

【0691】

本例では、口座開設パターン７３Ｂには、限定ではなく例として、契約者氏名として「＊＊ＮＮ」と、契約者氏名「＊＊ＮＮ」が開設している銀行口座の契約者ＩＤ（銀行口座ＩＤ）として「ＵＢ２０２０」と、この契約者ＩＤ（銀行口座ＩＤ）「ＵＢ２０２０」に対応する、銀行名として「Ｂ銀行」と、口座種別として「主口座」とが示されている。

【0692】

本実施例の（Ｈ１）第１パターンにおけるデータ構成（システム構成）は、限定ではなく例として、前述した第７実施例の（Ｇ３）第３パターンで説明した構成を採用してもよい。

【0693】

＜表示画面＞
図８－３～図８－４には、この場合に端末２０の表示部２４に表示される画面の一例を示している。
ここでは、ユーザＭ．Ｍが、Ａ銀行とＣ銀行とにそれぞれ銀行口座を開設しており、ユーザＮ．Ｎが、Ｂ銀行に銀行口座を開設している場合を例示する。そして、ユーザＭ．Ｍによって行われたクレジットカード決済に基づき、その利用金額がＡ銀行の銀行口座からＣ銀行の銀行口座に振り込まれ、ユーザＮ．Ｎによって行われたクレジットカード決済に基づき、その利用金額がＢ銀行の銀行口座からＣ銀行の銀行口座に振り込まれる場合を例示する。
この例では、Ａ銀行の銀行口座がユーザＭ．Ｍの「主口座」となり、Ｂ銀行の銀行口座がユーザＮ．Ｎの「主口座」となり、Ｃ銀行の銀行口座が名義をユーザＭ．Ｍとする２名の「副口座」となる。
また、ここでは、端末２０の表示部２４に表示される銀行アプリケーションの画面を例示する。

【0694】

図８－３には、端末２０Ｍ（ユーザＭ．Ｍの端末２０）の表示部２４に表示されるＡ銀行の銀行アプリケーションの画面の一例を示している。
画面の構成は、限定ではなく例として図７－３と同様とすることができ、この例では、ユーザＭ．Ｍが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済を行ったことに基づき、図８－３右側の明細画面における取引履歴のうち、日付「２０２２／１２／０１」について、取引内容として「振込 Ｃ銀行」が、入出金金額として「－２０，０００円」が表示されている。

【0695】

図８－４には、端末２０Ｎ（ユーザＮ．Ｎの端末２０）の表示部２４に表示されるＢ銀行の銀行アプリケーションの画面の一例を示している。
画面の構成は、限定ではなく例として図７－４と同様とすることができるが、図７－４とは異なり、ユーザがユーザＮ．Ｎであるため、ユーザＮ．Ｎに関する情報が表示されている。図８－４左側では、口座残高表示領域には、ユーザＮ．Ｎの本口座の口座残高として「３３２，２１１円」が表示されている。
この例では、ユーザＮ．Ｎが「２０２２年１２月２日」に「１０，０００円」のクレジットカード決済を行ったことに基づき、図８－４中央の画面では口座残高が「３２２，２１１円」に減少しており、図８－４右側の明細画面における取引履歴のうちの日付「２０２２／１２／０２」について、取引内容として「振込 Ｃ銀行」が、入出金金額として「－１０，０００円」が表示されている。

【0696】

＜処理＞
図８－５は、本実施例の（Ｈ１）第１パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｍの制御部２１が実行する処理、Ｘクレジットカード会社サーバ５０Ｘの制御部が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理、Ｃ銀行サーバ６０Ｃの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図７－５と同様である部分についての説明を省略する。

【0697】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、Ｘクレジットカード会社サーバ５０ＸからユーザＭ．Ｍの主口座であるＡ銀行の銀行口座が開設されるＡ銀行サーバ６０Ａに送信されたことに基づいて、そのクレジットカード決済に対応する金額をユーザＭ．Ｍの主口座であるＡ銀行の銀行口座からユーザＭ．Ｍの副口座（共通口座）であるＣ銀行の銀行口座に振替する場合を例示する。

【0698】

また、図１－２１に示したように、店舗端末４０と、クレジットカード会社サーバ５０（限定ではなく例として、Ｘクレジットカード会社サーバ５０Ｘ）とで、クレジットカード決済に関する処理が行われたものとする（不図示）。

【0699】

ＣＸ１０４０：ＹＥＳの場合、Ｘクレジットカード会社サーバ５０Ｘの制御部は、通信Ｉ／Ｆによって購入情報をＡ銀行サーバ６０Ａに送信する（ＣＸ１０５０）。

【0700】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＸクレジットカード会社サーバ５０Ｘから購入情報を受信したか否かを判定する（ＢＡ８０１０）。
購入情報を受信しなかったと判定する場合（ＢＡ８０１０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ８０２０～ＢＡ８０３０のステップをスキップする。

【0701】

購入情報を受信したと判定する場合（ＢＡ８０１０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、振替処理を実行する（ＢＡ８０２０）。

【0702】

振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される他行口座管理データのうち、そのクレジットカードＩＤに対応する、クレジットカードを振替口座として登録している共通口座（銀行口座ＩＤ）を特定する。そして、銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を減算して記憶させる。

【0703】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に基づいて、振替先であるユーザのＣ銀行の銀行口座ＩＤに関する情報と、ユーザのＡ銀行の銀行口座からＣ銀行の銀行口座にクレジットカード決済での購入金額を振替することに関する情報とを含む振替情報を、通信Ｉ／ＦによってＣ銀行サーバ６０Ｃに送信する（ＢＡ８０３０）。

【0704】

Ｃ銀行サーバ６０Ｃの制御部は、限定ではなく例として、通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替情報を受信したか否かを判定する（ＢＣ８０１０）。
通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替情報を受信しなかったと判定する場合（ＢＣ８０１０：ＮＯ）、Ｃ銀行サーバ６０Ｃの制御部は、限定ではなく例として、ＢＣ８０２０～ＢＣ８０３０のステップをスキップする。

【0705】

通信Ｉ／ＦによってＡ銀行サーバ６０Ａから振替情報を受信したと判定する場合（ＢＣ８０１０：ＹＥＳ）、Ｃ銀行サーバ６０Ｃの制御部は、限定ではなく例として、振替処理を実行する（ＢＣ８０２０）。
振替処理において、Ｃ銀行サーバ６０Ｃの制御部は、限定ではなく例として、受信した振替情報に含まれる、振替先であるＣ銀行の銀行口座ＩＤに関する情報と、購入金額に関する情報とに基づいて、銀行口座ユーザ管理データベース６５９に記憶される銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信した購入金額に関する情報を加算して記憶させる。

【0706】

そして、Ｃ銀行サーバ６０Ｃの制御部は、限定ではなく例として、Ｃ銀行サーバ６０Ｃでの振替処理の結果に関する情報を含む振替結果情報を、通信Ｉ／ＦによってＡ銀行サーバ６０Ａに送信する（ＢＣ８０３０）。

【0707】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＣ銀行サーバ６０Ｃから振替結果情報を受信したか否かを判定する（ＢＡ８０４０）。
通信Ｉ／ＦによってＣ銀行サーバ６０Ｃから振替結果情報を受信しなかったと判定する場合（ＢＡ８０４０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ８０５０のステップをスキップする。

【0708】

通信Ｉ／ＦによってＣ銀行サーバ６０Ｃから振替結果情報を受信したと判定する場合（ＢＡ８０４０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、Ｃ銀行サーバ６０Ｃから受信した振替結果情報と同様の振替結果情報を、通信Ｉ／Ｆによって端末２０に送信する（ＢＡ８０５０）。

【0709】

端末２０Ｍの制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信したか否かを判定する（Ａ８０１０）。
通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信しなかったと判定する場合（Ａ８０１０：ＮＯ）、端末２０Ｍの制御部２１は、限定ではなく例として、Ａ８０２０のステップをスキップする。

【0710】

通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから振替結果情報を受信したと判定する場合（Ａ８０１０：ＹＥＳ）、端末２０Ｍの制御部２１は、限定ではなく例として、受信した振替結果情報に基づいて、振替結果情報を表示部２４に表示させる（Ａ８０２０）。

【0711】

なお、これらのステップの処理の後、前述した（Ｇ１）第１パターンや（Ｇ２）第２パターンで示したような、クレジットカードの利用に伴って、一の銀行口座から他の銀行口座に振替を行っていた利用金額を、元の銀行口座に再度振替を行う処理は実行されないようにすることができる。
これは、支払い口座でない関連口座からクレジットカードの支払い口座である共通口座にその利用金額の振替がなされるので、クレジットカードの引き落とし前に、その振替が行われた金額を元の銀行口座に再度振替をする必要がないためである。

【0712】

図８－６は、本実施例の（Ｈ１）第１パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｎの制御部２１が実行する処理、Ｙクレジットカード会社サーバ５０Ｙの制御部が実行する処理、Ｂ銀行サーバ６０Ｂの制御部が実行する処理、Ｃ銀行サーバ６０Ｃの制御部が実行する処理をそれぞれ示している。

【0713】

このフローチャートについては、以下のような対応関係で、前述した図８－５と同様であるので説明を省略する。なお、以下では、「図８－５に示す装置＝図８－６に示す装置」の関係であるものとする。
・Ｘクレジットカード会社サーバ５０Ｘ＝Ｙクレジットカード会社サーバ５０Ｙ
・Ａ銀行サーバ６０Ａ＝Ｂ銀行サーバ６０Ｂ
・ユーザＭ．Ｍの端末２０Ｍ＝ユーザＮ．Ｎの端末２０Ｎ

【0714】

このように、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座でない銀行口座からクレジットカードの支払い口座に振替を行うことによって、クレジットカードの引き落としを行うときの残高を確保することができ、クレジットカードの引き落としを確実に行うことができる。
また、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座からクレジットカードの支払い口座でない銀行口座に振替を行うことによって、再度振替を行う必要がなく、振替に係る手数料や振替に係る処理の負担を軽減化できる。

【0715】

＜（Ｈ２）第２パターン＞
（Ｈ２）第２パターンとして、異なるクレジットカードＩＤを有する複数のクレジットカードがあるときに、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、共通の支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行うように、家計管理サーバ１０によって要求される場合を例示する。

【0716】

＜口座開設パターン＞
本実施例の（Ｈ２）第２パターンにおける第１のユーザ（契約者）と第２のユーザとの口座開設パターンは、前述した図８－１，図８－２と同様であるものとしてもよいので、説明を省略する。

【0717】

本実施例の（Ｈ２）第２パターンにおけるデータ構成（システム構成）は、限定ではなく例として、前述した第７実施例の（Ｇ３）第３パターンで説明した構成を採用してもよい。

【0718】

＜表示画面＞
図８－７～図８－８には、この場合に端末２０の表示部２４に表示される画面の一例を示している。
ここでは、ユーザＭ．Ｍが、Ａ銀行とＣ銀行とにそれぞれ銀行口座を開設しており、ユーザＮ．Ｎが、Ｂ銀行に銀行口座を開設している場合を例示する。
そして、ユーザＭ．Ｍによって行われたクレジットカード決済に基づき、その利用金額がＡ銀行の銀行口座からＣ銀行の銀行口座に振り込まれ、ユーザＮ．Ｎによって行われたクレジットカード決済に基づき、その利用金額がＢ銀行の銀行口座からＣ銀行の銀行口座に振り込まれる場合を例示する。
また、ここでは、図８－３～図８－４とは異なり、端末２０の表示部２４に表示される家計管理アプリケーションの画面を例示する。

【0719】

図８－７には、端末２０Ｍの表示部２４に表示される家計管理アプリケーションの画面の一例を示しており、タブ領域の「銀行」タブが選択された状態が示されている。
この例では、タブ領域の「銀行」タブが選択された状態が示されており、タブ領域の下には、ユーザＭ．Ｍが家計管理アプリケーションに登録済みの銀行口座に関する情報として、Ａ銀行に関する情報を表示する第１口座情報表示領域と、Ｃ銀行に関する情報を表示する第２口座情報表示領域とが構成されている。

【0720】

図８－７左側では、Ａ銀行の口座残高が「６５４，３２１円」であるのに対し、前述した例と同様に、ユーザＭ．Ｍが「２０２２年１２月１日」に「２０，０００円」のクレジットカード決済をしたことに基づき、図８－７中央では、Ａ銀行の口座残高が「６３４，３２１円」に減少している。

【0721】

この状態でＡ銀行の口座情報表示領域がユーザによってタッチされると、限定ではなく例として、図８－７右側のような画面が表示される。
この画面では、Ａ銀行の銀行口座に関するより詳細な情報が表示されており、取引履歴のうち、日付「２０２２／１２／０１」には、取引内容として「振込 Ｃ銀行」が、入出金金額として「－２０，０００円」が表示されている。
これは、Ａ銀行の銀行口座からＣ銀行の銀行口座に「２０，０００円」が送金された（振り込まれた）ことを示している。

【0722】

図８－８には、端末２０Ｎの表示部２４に表示される家計管理アプリケーションの画面の一例を示しており、タブ領域の「銀行」タブが選択された状態が示されている。
この例では、タブ領域の「銀行」タブが選択された状態が示されており、タブ領域の下には、ユーザＮ．Ｎが家計管理アプリケーションに登録済みの銀行口座に関する情報として、Ｂ銀行に関する情報を表示する口座情報表示領域が構成されている。

【0723】

図８－８左側では、Ｂ銀行の口座残高が「３３２，２１１円」であるのに対し、前述した例と同様に、ユーザＮ．Ｎが「２０２２年１２月２日」に「１０，０００円」のクレジットカード決済をしたことに基づき、図８－８中央では、Ｂ銀行の口座残高が「３２２，２１１円」に減少している。
この状態でＢ銀行の口座情報表示領域がユーザによってタッチされると、限定ではなく例として、図８－８右側のような画面が表示される。
この画面では、Ｂ銀行の銀行口座に関するより詳細な情報が表示されており、取引履歴のうち、日付「２０２２／１２／０２」には、取引内容として「振込 Ｃ銀行」が、入出金金額として「－１０，０００円」が表示されている。
これは、Ｂ銀行の銀行口座からＣ銀行の銀行口座に「１０，０００円」が送金された（振り込まれた）ことを示している。

【0724】

＜処理＞
図８－９は、本実施例の（Ｈ２）第２パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｍの制御部２１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理、Ｃ銀行サーバ６０Ｃの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図８－５と同様である部分についての説明を省略する。

【0725】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報がクレジットカード会社サーバ５０等から家計管理サーバ１０に送信され、その情報を受信した家計管理サーバ１０によって、クレジットカード決済に対応する金額をユーザＭ．Ｍの主口座であるＡ銀行の銀行口座から、ユーザＭ．Ｍの副口座（共通口座）であるＣ銀行の銀行口座に振替するように要求する情報が送信される場合を例示する。

【0726】

また、図１－２１に示したように、店舗端末４０と、クレジットカード会社サーバ５０（限定ではなく例として、Ｘクレジットカード会社サーバ５０Ｘ）との間で、クレジットカード決済に関する処理が行われたものとする（不図示）。
また、前述したように、クレジットカード決済に関する処理において、Ｘクレジットカード会社サーバ５０Ｘの制御部は、限定ではなく例として、与信照会結果の情報を含む与信照会結果情報を、通信Ｉ／Ｆによって店舗端末４０に送信する。

【0727】

家計管理サーバ１０の制御部１１は、限定ではなく例として、通信Ｉ／Ｆ１４によって購入情報を受信したか否かを判定する（Ｓ８２１０）。
購入情報を受信しなかったと判定する場合（Ｓ８２１０：ＮＯ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、Ｓ８２２０のステップをスキップする。

【0728】

購入情報を受信したと判定する場合（Ｓ８２１０：ＹＥＳ）、家計管理サーバ１０の制御部１１は、限定ではなく例として、購入情報に含まれるクレジットカードＩＤに紐付けられているＡ銀行の銀行口座（主口座＝関連口座）の残高に対して利用金額に対応する金額を、Ｃ銀行の銀行口座（副口座＝支払い口座）に振替するように要求する振替要求情報を、通信Ｉ／Ｆ１４によってＡ銀行サーバ６０Ａに送信する（Ｓ８２２０）。

【0729】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／Ｆによって家計管理サーバ１０から振替要求情報を受信したか否かを判定する（ＢＡ８２１０）。
通信Ｉ／Ｆによって家計管理サーバ１０から振替要求情報を受信しなかったと判定する場合（ＢＡ８２１０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ８０２０～ＢＡ８０３０のステップをスキップする。

【0730】

通信Ｉ／Ｆによって家計管理サーバ１０から振替要求情報を受信したと判定する場合（ＢＡ８２１０：ＹＥＳ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、ＢＡ８０２０～ＢＡ８０３０のステップに処理を進める。

【0731】

図８－１０は、本実施例の（Ｈ２）第２パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｎの制御部２１が実行する処理、家計管理サーバ１０の制御部１１が実行する処理、Ｂ銀行サーバ６０Ｂの制御部が実行する処理、Ｃ銀行サーバ６０Ｃの制御部が実行する処理をそれぞれ示している。

【0732】

このフローチャートについては、以下のような対応関係で、前述した図８－９と同様であるので説明を省略する。なお、以下では、「図８－９に示す装置＝図８－１０に示す装置」の関係であるものとする。
・Ａ銀行サーバ６０Ａ＝Ｂ銀行サーバ６０Ｂ
・ユーザＭ．Ｍの端末２０Ｍ＝ユーザＮ．Ｎの端末２０Ｎ

【0733】

このように、クレジットカードＩＤの異なる２つのクレジットカードのそれぞれの決済において、それらのクレジットカードの利用金額を、クレジットカードの支払い口座でない銀行口座からクレジットカードの支払い口座に振替を行うように、共通の家計管理サービスが要求することによって、クレジットカードの引き落としを行うときの残高を確保することができ、クレジットカードの引き落としを確実に行うことができる。
また、クレジットカードＩＤの異なる２つのクレジットカードのそれぞれの決済において、それらのクレジットカードの利用金額を、クレジットカードの支払い口座でない銀行口座からクレジットカードの支払い口座に振替を行うように、共通の家計管理サービスが要求することによって、振替に係る手数料や振替に係る処理の負担を軽減化できる。

【0734】

＜第９実施例＞
第９実施例は、共通のクレジットカードＩＤを有する複数のクレジットカードがあるときに、これらのクレジットカードの支払い口座が共通の銀行口座である場合、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行う実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0735】

本実施例では、このような共通のクレジットカードＩＤを有する複数のクレジットカードを、適宜「共通クレジットカード」、「共通カード」と称する。
一のクレジットカードＩＤに対応する共通クレジットカードは、限定ではなく例として、支払い口座として共通の銀行口座が設定される。
また、その共通クレジットカードは、限定ではなく例として、共通クレジットカードごとに、その共通クレジットカードを利用する契約者または契約者に属する人の銀行口座が紐付けられてもよい。ここでの共通クレジットカードに紐付けられる銀行口座は、限定ではなく例として、支払い口座として設定される銀行口座とは異なり、限定ではなく例として、共通クレジットカードを利用する契約者または契約者に属する人が支払い口座に振替を行うときなどに用いる銀行口座であるものとする。

【0736】

本実施例では、限定ではなく例として、共通クレジットカードに紐付けられた支払い口座としての銀行口座を「副口座」と称し、限定ではなく例として、共通クレジットカードに紐付けられた支払い口座とは異なる銀行口座を「主口座」と称する。

【0737】

共通クレジットカードとは、限定ではなく例として、以下のようなものを含めることができる。
（Ａ）法人クレジットカード
（Ｂ）家族クレジットカード

【0738】

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

【0739】

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

【0740】

以下、本実施例における共通クレジットカードの支払い口座が、共通の銀行口座である場合、それぞれのクレジットカードに紐付けられた支払い口座の銀行口座とは異なる銀行口座から、支払い口座である銀行口座に、クレジットカードにおける利用金額の振替を行ういくつかのパターンについて、表示画面や処理を例示する。

【0741】

＜（Ｉ１）第１パターン＞
（Ｉ１）第１パターンとして、共通クレジットカードのクレジットカード決済において、それぞれの共通クレジットカードに紐付けられた主口座から、共通の支払い口座である副口座に、クレジットカードにおける利用金額の振替を行うように、クレジットカード会社サーバ５０によって要求される場合を例示する。

【0742】

＜口座開設パターン＞
本実施例の（Ｉ１）第１パターンにおける第１のユーザ（契約者）と第２のユーザとの口座開設パターンは、前述した図８－１，図８－２と同様としてよいため、説明を省略する。

【0743】

＜データ構成＞
本実施例の（Ｉ１）第１パターンにおけるクレジットカード決済ユーザ管理データベース５５９の一例であるクレジットカード決済ユーザ管理データ５５９２のデータ構成の一例を図９－１に示す。
このデータ構成では、前述した図７－１１と同様の部分についての説明を省略する。

【0744】

本実施例の（Ｉ１）第１パターンにおけるクレジットカード決済ユーザ管理データ５５９２には、限定ではなく例として、契約者ＩＤと、取引管理データと、登録銀行口座管理データとに加えて、限定ではなく例として、共通クレジットカード管理データが記憶される。

【0745】

共通クレジットカード管理データには、限定ではなく例として、共通クレジットカードＮｏ．と、銀行口座ＩＤとが記憶される。

【0746】

共通クレジットカードＮｏ．は、限定ではなく例として、このクレジットカードに対応する共通クレジットカードを識別するため識別情報として機能する番号である。
この共通クレジットカードＮｏ．は、好ましくは発行された共通クレジットカードごとに一意な値であり、限定ではなく例として、クレジットカード会社サーバ５０によって共通クレジットカードごとに一意な値（固有の値）が設定されて記憶される。

【0747】

銀行口座ＩＤは、共通クレジットカードＮｏ．に紐付けられた関連口座の銀行口座ＩＤである。
この共通クレジットカード管理データの銀行口座ＩＤによって、この契約者ＩＤ（クレジットカードＩＤ）の各共通クレジットカードと紐づけられたユーザの関連口座が特定される。

【0748】

＜処理＞
本実施例の（Ｉ１）第１パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートは、限定ではなく例として、前述した図８－５，図８－６と同様とすることができるため、説明を省略する。

【0749】

但し、本実施例では、共通のクレジットカードＩＤを有する共通クレジットカードに関する処理であるので、クレジットカード会社サーバ５０の制御部が行う処理は、限定ではなく例として、図８－５，図８－６いずれの場合も、Ｘクレジットカード会社サーバ５０Ｘの制御部が行う処理であるものとしてよい。

【0750】

本例では、クレジットカードの契約者がユーザＭ．Ｍであり、そのクレジットカードに対応する共通クレジットカードをユーザＭ．ＭとユーザＮ．Ｎとが利用している。
そして、これらの共通クレジットカードの支払い口座として、限定ではなく例として、ユーザＭ．Ｍが契約者であるＣ銀行の銀行口座が設定されている。
また、共通クレジットカードＮｏ．「００１」の共通クレジットカードの関連口座として、限定ではなく例として、ユーザＭ．Ｍが契約者であるＡ銀行の銀行口座が設定されており、共通クレジットカードＮｏ．「００２」の共通クレジットカードの関連口座として、限定ではなく例として、ユーザＮ．Ｎが契約者であるＢ銀行の銀行口座が設定されている。

【0751】

＜（Ｉ２）第２パターン＞
（Ｉ２）第２パターンとして、共通クレジットカードのクレジットカード決済において、それぞれの共通クレジットカードに紐付けられた主口座から、共通の支払い口座である副口座に、クレジットカードにおける利用金額の振替を行うように、家計管理サーバ１０によって要求される場合を例示する。

【0752】

＜口座開設パターン＞
本実施例の（Ｉ２）第２パターンにおける第１のユーザ（契約者）と第２のユーザとの口座開設パターンは、前述した図８－１，図８－２と同様としてよいため、説明を省略する。

【0753】

本実施例の（Ｉ２）第２パターンにおけるデータ構成（システム構成）は、前述した（Ｉ１）第１パターンと同様としてよいため、説明を省略する。

【0754】

＜処理＞
本実施例の（Ｉ２）第２パターンにおいて各装置が実行する処理の流れの一例を示すフローチャートは、限定ではなく例として、前述した図８－９，図８－１０と同様とすることができるため、説明を省略する。

【0755】

但し、本実施例では、共通のクレジットカードＩＤを有する共通クレジットカードに関する処理であるので、クレジットカード会社サーバ５０の制御部が行う処理は、限定ではなく例として、図８－９，図８－１０いずれの場合も、Ｘクレジットカード会社サーバ５０Ｘの制御部が行う処理であるものとしてよい。

【0756】

本例では、クレジットカードの契約者がユーザＭ．Ｍであり、そのクレジットカードに対応する共通クレジットカードをユーザＭ．ＭとユーザＮ．Ｎとが利用している。
そして、これらの共通クレジットカードの支払い口座として、限定ではなく例として、ユーザＭ．Ｍが契約者であるＣ銀行の銀行口座が設定されている。
また、共通クレジットカードＮｏ．「００１」の共通クレジットカードの関連口座として、限定ではなく例として、ユーザＭ．Ｍが契約者であるＡ銀行の銀行口座が設定されており、共通クレジットカードＮｏ．「００２」の共通クレジットカードの関連口座として、限定ではなく例として、ユーザＮ．Ｎが契約者であるＢ銀行の銀行口座が設定されている。

【0757】

＜第９実施例の効果＞
本実施例は、銀行サーバ６０（限定ではなく、情報処理装置の一例）が、共通の識別情報を有するクレジットカードの支払い口座が共通の口座である場合、それぞれのクレジットカードに紐付けられた支払い口座とは異なる口座から、支払い口座である口座に、クレジットカードにおける利用金額の振替を行う構成を示している。
このような構成により得られる実施例の効果の一例として、共通カードなどの複数のユーザが使用可能なカードである場合であっても、第２金額を適切に第２口座に移動させることができる。

【0758】

＜第９変形例（１）＞
上記の実施例において、（Ｉ３）第３パターンとして、共通クレジットカードのクレジットカード決済において、いずれの銀行口座から支払い口座に対してクレジットカードにおける利用金額の振替を行うかの設定を行うことができるようにしてもよい。

【0759】

本変形例では、共通クレジットカードのクレジットカード決済において、いずれの銀行口座から支払い口座に対してクレジットカードにおける利用金額の振替を行うかを設定するための手法として、限定ではなく例として、以下のようなものを含めてよい。
（ＳＡ）基本設定
（ＳＢ）決済前ユーザ設定
（ＳＣ）決済時ユーザ設定
（ＳＤ）決済後ユーザ設定

【0760】

（ＳＡ）基本設定は、クレジットカード会社が提供する共通クレジットカードサービスの基本的な設定であり、限定ではなく例として、各共通クレジットカードを利用したユーザの関連口座から支払い口座に振替を行うように設定される手法とすることができる。

【0761】

（ＳＢ）決済前ユーザ設定は、共通クレジットカードを用いたクレジットカード決済を行う前に、いずれの関連口座から支払い口座に振替を行うのかを事前に決定しておく手法でとすることができる。
具体的には、決済前ユーザ設定手法として、限定ではなく例として、以下のようなものを含めることができる。
（ＳＢ１）購入品の種別ごとに分類
（ＳＢ２）購入金額ごとに分類

【0762】

（ＳＢ１）購入品の種別ごとに分類は、ユーザが共通クレジットカードを用いて購入する商品やサービスの種別に応じて、いずれの銀行口座から支払い口座に振替を行うのかを事前に決定しておく手法とすることができる。
限定ではなく例として、第１種別（限定ではなく例として、食品，外食費，家賃等）の購入品を購入した場合は、第１の銀行口座（限定ではなく例として、夫の関連口座）から支払い口座に振替を行い、第２種別（限定ではなく例として、日用品，電気・光熱費等）の購入品を購入した場合は、第２の銀行口座（限定ではなく例として、妻の関連口座）から支払い口座に振替を行うものとしてもよい。

【0763】

（ＳＢ２）購入金額ごとに分類は、ユーザが共通クレジットカードを用いて購入する商品やサービスの購入金額に応じて、いずれの銀行口座から支払い口座に振替を行うのかを事前に決定しておく手法とすることができる。
限定ではなく例として、第１金額以上（限定ではなく例として、１０，０００円以上）を購入した場合は、第１の銀行口座（夫の関連口座）から支払い口座に振替を行い、第１金額未満（限定ではなく例として、１０，０００円未満）を購入した場合は、第２の銀行口座（妻の関連口座）から支払い口座に振替を行うものとしてもよい。

【0764】

（ＳＣ）決済時ユーザ設定は、共通クレジットカードを用いたクレジットカード決済を行うときに、いずれの関連口座から支払い口座に振替を行うのかを決定する手法とすることができる。
具体的には、決済時ユーザ設定手法として、限定ではなく例として、クレジットカード決済を最終的に決定するためのボタンが表示されている画面において、この取引での購入金額をいずれの関連口座から支払い口座に振替を行うのかを選択／決定するような情報が表示されるなどしてもよい。

【0765】

（ＳＤ）決済後ユーザ設定は、共通クレジットカードを用いたクレジットカード決済を行った後に、いずれの関連口座から支払い口座に振替を行うのかを決定する手法とすることができる。
具体的には、決済後ユーザ設定手法として、限定ではなく例として、クレジットカード決済の取引が完了した後に、その共通クレジットカードを所有しているすべてのユーザに、その取引に関していずれの関連口座から支払い口座に振替を行うのかを選択／決定させるための情報を含む情報が通知されることによって、その情報に基づいて、ユーザはいずれの関連口座から支払い口座に振替を行うのかを選択／決定することができるなどしてもよい。この情報は、限定ではなく例として、メッセージングサービス（メッセージングアプリケーション）等のチャットサービス（チャットアプリケーション）において通知されるものであってもよいし、家計管理サービスにおいて通知されるものであってもよい。

【0766】

また、この場合、上記の通知を受けたユーザ同士（限定ではなく例として、夫と妻、家族間）で、いずれの関連口座から支払い口座に振替を行うのかを、メッセージングアプリケーション等を用いたメッセージのやり取り（チャット）を行うことによって決定するようにしてもい。

【0767】

＜表示画面＞
以下、共通クレジットカードを用いて決済を行う場合の、前述したパターンのうちのいくつかのパターンを適用する場合の表示画面例を説明する。
以下では、支払い口座に対して振込を行う銀行口座を「振込元口座」として図示・説明する。

【0768】

図９－２～図９－３は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図であり、上記の（ＳＢ）決済前ユーザ設定を適用する場合の画面の一例を示す図である。
これらの図では、端末２０Ｍ（ユーザＭ．Ｍの端末２０）の表示部２４に表示される「Ｘカード」のクレジットカード会社が提供するクレジットカードアプリケーションの画面の一例を示している。

【0769】

図９－２左側には、「Ｘカード」のクレジットカードアプリケーションの振込元口座設定画面の一例を示しており、この例では、「支出項目指定」と、「金額指定」と、「個別指定」との３つの表示領域が構成されている。

【0770】

限定ではなく例として、「支出項目指定」の表示領域がユーザによってタッチされると、限定ではなく例として、図９－２中央のような画面が表示される。
この例では、「支出項目を指定してください」のテキストとともに、この例では、「食費」の支出項目、「日用品費」の支出項目等の複数の支出項目が表示され、各々に関連付けて、その支出項目を選択するためのラジオボタンが設けられている。
また、各々の支出項目には、振込元の銀行口座の指定を行うための「振込元指定」ボタンＢＴ１０（「振込元設定」ボタン等としてもよい。以下同様。）が関連付けて設けられている。

【0771】

限定ではなく例として、「食費」の支出項目のラジオボタンがオンとされ、それに関連付けられた「振込元指定」ボタンＢＴ１０がユーザによってタッチされると、限定ではなく例として、図９－２右側のような画面が表示される。
この画面は、支出項目「食費」について、振込元の銀行口座を指定するための振込元口座指定画面であり、「支出項目“食費”の振込を行う銀行口座を指定してくださ」のテキストとともに、この例では、「Ａ銀行」、「Ｂ銀行」、「Ｃ銀行」の３つの銀行に対応するボタンＢＴ１１～ＢＴ１３が表示されている。

【0772】

限定ではなく例として、「Ａ銀行」のボタンＢＴ１１がユーザによってタッチされると、限定ではなく例として、図９－３左側のような画面が表示される。
この画面は、図９－２左側の画面に続く振込元口座指定画面であり、「支出項目“食費”の振込を行う銀行口座を指定してください」のテキストの下に、選択された「Ａ銀行」のテキストと、ユーザによって入力された支店名が表示される支店名表示領域Ｒ１５が構成されている。
支店名表示領域の右下の位置には、支店名を検索するための「検索」ボタンＢＴ１５が設けられており、この「検索」ボタンＢＴ１５を操作することによって、選択された「Ａ銀行」の支店名が一覧表示され、その中からユーザが支店名を選択することができるように構成されている。なお、ユーザは、ＯＳのキーボードやクレジットカードアプリケーションのキーボード等を用いて支店名を入力するようにしてもよい。

【0773】

このようにして支店名が入力され、その後、不図示の画面において銀行口座種別、銀行口座番号等の情報が入力され、画面下部の「決定」ボタンＢＴ１がユーザによってタッチされると、図９－３右側のような振込元口座設定完了画面が表示される。

【0774】

図９－４は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図であり、上記の（ＳＣ）決済時ユーザ設定を適用する場合の画面の一例を示す図である。
この図では、端末２０Ｍの表示部２４に表示されるショッピングアプリケーション（買い物アプリケーション）の画面の一例を示している。

【0775】

図９－４左側では、ユーザＭ．Ｍが、ある商品を、共通クレジットカードを用いて購入しようとしている場面が示されており、「こちらの内容で購入しますか」のテキストとともに、商品名、値段（価格）、商品画像等の情報を含む領域が表示されている。
また、その下には、振込元口座を設定するための、限定ではなく例として、「振込元口座の設定はこちら」のテキストと、「振込元指定」ボタンＢＴ１０とを含む振込元口座設定領域が表示されている。

【0776】

「振込元指定」ボタンＢＴ１０がユーザによってタッチされると、限定ではなく例として、図９－４中央の画面が表示される。
この画面は、ショッピングアプリケーションにおける振込元口座設定画面であり、「こちらのお買い物で振替を行う銀行口座を指定してください」のテキストとともに、前述した例と同様に、「Ａ銀行」、「Ｂ銀行」、「Ｃ銀行」の３つの銀行に対応するボタンＢＴ１１～ＢＴ１３が表示されている。

【0777】

限定ではなく例として、「Ａ銀行」のボタンＢＴ１１がユーザによってタッチされ、「決定」ボタンＢＴ１がユーザによってタッチされると、限定ではなく例として、図９－４右側のような振込元口座設定完了画面が表示される。

【0778】

図９－５～図９－６は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図であり、上記の（ＳＤ）決済後ユーザ設定を適用する場合の画面の一例を示している。

【0779】

図９－５には、端末２０Ｍの表示部２４に表示される画面の一例を示している。
図９－５左側には、端末２０Ｍの表示部２４に表示されるＯＳの待ち受け画面（ロック画面）を示しており、画面最上部には、メッセージングアプリケーションのプッシュ通知情報として「振込元口座の設定のおしらせ」のプッシュ通知情報ＰＮ７が表示されている。

【0780】

限定ではなく例として、プッシュ通知情報ＰＮ７がユーザによってタッチされると、端末２０Ｍでメッセージングアプリケーションが起動し、限定ではなく例として、図９－５中央の画面が表示される。

【0781】

この画面は、ユーザＭ．Ｍがメッセージングアプリケーションで友だちとして登録している「Ｘカード」の公式アカウントのトークルーム画面であり、向かって左側に、「Ｘカード」（Ｘカードのクレジットカード会社）を発信元とする、「振込元口座の設定のおしらせ」に関するメッセージが表示されている。
このメッセージには、ユーザＭ．Ｍが「２０２２年１２月１日」に共通クレジットカードを用いて行ったクレジットカード決済の振込元口座を設定するように促すテキストと、そのクレジットカード決済の決済日時と、その利用金額と、振込元口座を設定するための「振込元指定」ボタンＢＴ１０とが含まれている。

【0782】

「振込元指定」ボタンＢＴ１０がユーザによってタッチされると、限定ではなく例として、端末２０Ｍで「Ｘカード」のクレジットカードアプリケーションが起動し、限定ではなく例として、図９－５左側のような画面が表示される。
この画面は、「Ｘカード」のクレジットカードアプリケーションにおける振込元口座設定画面であり、この例では、「振込を行う銀行口座を指定してください」のテキストとともに、前述した例と同様に、「Ａ銀行」、「Ｂ銀行」、「Ｃ銀行」の３つの銀行に対応するボタンＢＴ１１～ＢＴ１３が表示されている。

【0783】

限定ではなく例として、「Ａ銀行」のボタンがユーザによってタッチされ、画面下部の「決定」ボタンＢＴ１がユーザによってタッチされると、振込元口座の設定が完了する。

【0784】

図９－６には、端末２０Ｎ（ユーザＮ．Ｎの端末２０）の表示部２４に表示される画面の一例を示している。ユーザＮ．Ｎは、限定ではなく例として、ユーザＭ．Ｍと夫婦の関係や家族の関係にあるユーザ等とすることができる。
この画面では、図９－５と同様の画面が表示されている。つまり、この例では、ユーザＭ．Ｍが共通クレジットカードを用いて行ったクレジットカード決済に関する購入通知が、ユーザＭ．ＭとユーザＮ．Ｎとの両方に送信されている。

【0785】

＜処理＞
本実施例では、銀行サーバ６０に対して振替要求等を行う情報処理装置（限定ではなく例として、家計管理サーバ１０やクレジットカード会社サーバ５０等の装置）は、ユーザの端末２０に対する入力に基づきユーザの端末２０から送信された振込元口座の情報（振込元口座を特定可能な情報）を含むユーザ情報に基づいて、振込元口座（限定ではなく、第１口座の一例）を設定・記憶するようにすることができる。そして、情報処理装置は、このようにして設定（記憶）した振込元口座の情報を含むユーザ情報に基づいて、銀行サーバ６０に対して振替要求等を行うようにすることができる。

【0786】

また、本実施例では、銀行サーバ６０に対して振替要求等を行う情報処理装置（限定ではなく例として、家計管理サーバ１０やクレジットカード会社サーバ５０等の装置）は、第１ユーザの端末２０に対する入力に基づき第１ユーザの端末２０から送信された振込元口座の情報（振込元口座を特定可能な情報）を含むユーザ情報、または、第２ユーザの端末２０に対する入力に基づき第２のユーザの端末２０から送信された振込元口座の情報（振込元口座を特定可能な情報）を含むユーザ情報に基づいて、振込元口座（限定ではなく、第１口座の一例）を設定・記憶するようにすることができる。そして、情報処理装置は、このようにして設定（記憶）した振込元口座の情報を含むユーザ情報に基づいて、銀行サーバ６０に対して振替要求等を行うようにすることができる。
なお、この場合、第１ユーザと第２ユーザとは、上記のように、限定ではなく例として、共通クレジットカードを所有するユーザ等としてもよい。

【0787】

＜第９実施例の効果＞
本実施例は、ユーザ情報は、ユーザによって設定された振込元口座（限定ではなく、第１口座の一例）の情報を含む。
そして、銀行サーバ６０（限定ではなく、情報処理装置の一例）は、取得したユーザ情報に基づいて、ユーザの振込元口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対して振替等を行うための設定（限定ではなく、第１設定の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、取得された、ユーザによって設定された第１口座の情報を含むユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額に対して第１設定を行うことができる。

【0788】

本実施例は、ユーザ情報は、ユーザによって設定された振込元口座（限定ではなく、第１口座の一例）の情報を含む。
そして、家計管理サーバ１０（限定ではなく、情報処理装置の一例）は、取得したユーザ情報に基づいて、ユーザの振込元口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）を振込元口座から支払い口座（限定ではなく、第２口座の一例）に移動することに関する振替要求情報を通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、取得された、ユーザによって設定された第１口座の情報を含むユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額を第１口座から第２口座に移動することに関する制御情報を送信することによって、第２金額を第１口座から第２口座に移動させることができる。

【0789】

また、本実施例は、ユーザ情報は、第１ユーザの端末２０、または第１ユーザとは異なる第２ユーザの端末２０から送信された振込元口座（限定ではなく、第１口座の一例）の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザの端末、またはこのユーザとは異なるユーザの端末から送信された第１口座に関する情報に基づいて、上記のように、取得された支払い情報に基づく第２金額に対して第１設定を行ったり、取得された支払い情報に基づく第２金額を第１口座から第２口座に移動させるなどすることが可能となる。

【0790】

また、本実施例は、ユーザ情報は、クレジットカード決済の後（限定ではなく、後払いの後の一例）に、ユーザの端末２０から送信された情報に基づき選択された振込元口座（限定ではなく、第１口座の一例）の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、後払いの後に、ユーザの端末から送信された情報に基づき選択された第１口座の情報に基づいて、上記のように、取得された支払い情報に基づく第２金額に対して第１設定を行ったり、取得された支払い情報に基づく第２金額を第１口座から第２口座に移動させるなどすることが可能となる。

【0791】

＜第１０実施例＞
第１０実施例は、クレジットカード決済を利用した場合に、クレジットカードに紐付けられた第１の銀行口座の残高に対してそのクレジットカードの利用金額をロックし、クレジットカードに紐付けられた第１の銀行口座から第２の銀行口座に対してそのロックした金額の振替を行う実施例である。
第１０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0792】

以下、本実施例におけるクレジットカード決済を利用した場合に、クレジットカードに紐付けられた第１の銀行口座の残高に対してそのクレジットカードの利用金額をロックし、クレジットカードに紐付けられた第１の銀行口座から第２の銀行口座に対してそのロックした金額の振替を行ういくつかのパターンについて、表示画面や処理を例示する。

【0793】

本実施例では、限定ではなく例として、クレジットカード決済を利用した場合に、クレジットカードに紐付けられた第１の銀行口座の残高に対してそのクレジットカードの利用金額をロックするようにクレジットカード会社サーバ５０によって要求され、クレジットカードに紐付けられた第１の銀行口座から第２の銀行口座に対してそのロックした金額の振替を行う場合を例示する。

【0794】

＜データ構成＞
図１０－１は、本実施例において銀行サーバ６０の記憶部６５に記憶される情報等の一例を示す図である。このデータ構成では、前述した図１－１２と同様の部分についての説明を省略する。

【0795】

本実施例における記憶部６５には、限定ではなく例として、銀行口座入出金管理処理プログラム６５１と、銀行口座ユーザ登録データ６５３と、提携クレジットカード会社データ６５５と、銀行口座ユーザ管理データベース６５９とに加えて、限定ではなく例として、一括振替処理要求情報送信条件データ６５７が記憶される。

【0796】

一括振替処理要求情報送信条件データ６５７は、限定ではなく例として、銀行サーバ６０が他の銀行サーバ６０に一括振替処理要求情報を送信するときにおいて参照されるデータであり、そのデータ構成の一例として一括振替処理要求情報送信条件データ６５７１を図１０－２に示す。

【0797】

一括振替処理要求情報送信条件データ６５７１には、限定ではなく例として、条件Ｎｏ．と、一括振替処理要求情報送信条件とが関連付けて記憶される。

【0798】

条件Ｎｏは、一括振替処理要求情報送信条件に対応した番号（条件の識別情報）が設定される。
条件Ｎｏは、好ましくは一括振替処理要求情報送信条件ごとに一意な値であり、限定ではなく例として、銀行サーバ６０によって一括振替処理要求情報送信条件ごとに一意な値（固有の値）が設定されて記憶される。

【0799】

本例では、条件Ｎｏ「ＣＩＴ０１」：「現在日時がクレジットカードの口座引き落とし日の前日」の条件などが設定されている。
「現在日時がクレジットカードの口座引き落とし日の前日」とは、限定ではなく例として、このデータを参照する処理（後述する図１０－４のＢＢ９０４０のステップの処理）を行っているタイミングがクレジットカードの口座引き落とし日の前日（限定ではなく例として、口座引き落とし日の前日０時００分から口座引き落とし日の０時００分となるまでの期間）となる場合である。

【0800】

＜表示画面＞
図１０－３は、本実施例において端末２０Ｍの表示部２４に表示される画面の一例を示す図である。
図１０－３左側には、端末２０Ｍの表示部２４に表示されるＡ銀行の銀行アプリケーションのうちの明細画面が表示された状態が示されている。
この明細画面は、限定ではなく例として、画面上部に口座残高が表示される領域が構成され、その下に、図１－１９等と同様の、ロック領域ＬＲと非ロック領域ＮＬＲとで構成される帯グラフが表示されている。
図１０－３左側の画面は、限定ではなく例として、「２０２２年１月６日」にクレジットカード決済が行われた場合の画面であり、取引履歴の日付「２０２２年１月６日」には、取引内容としてロックアイコンＩＣ１および「ロック」の文字が、入出金金額として「２０，０００円」が表示されている。

【0801】

図１０－３中央の画面は、その後、限定ではなく例として、「２０２２年１月１０日」にクレジットカード決済が行われた場合の画面であり、取引履歴の日付「２０２２年１月１０日」には、取引内容としてロックアイコンＩＣ１および「ロック」の文字が、入出金金額として「３０，０００円」が表示されている。

【0802】

図１０－３右側の画面は、その後、限定ではなく例として、口座引き落とし日「２０２２年２月１０日」の前日である「２０２２年２月９日」に一括振込が行われた場合の画面であり、取引履歴の日付「２０２２年２月９日」には、取引内容として「振込 Ｂ銀行」が、入出金金額として「－８０，０００円」がそれぞれ表示されている。

【0803】

＜処理＞
図１０－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０の制御部２１が実行する処理、クレジットカード会社サーバ５０の制御部５１が実行する処理、Ａ銀行サーバ６０Ａの制御部が実行する処理、Ｂ銀行サーバ６０Ｂの制御部が実行する処理をそれぞれ示している。
このフローチャートについては、前述した図７－５と同様である部分についての説明を省略する。

【0804】

本例では、クレジットカード決済が行われた後に、そのクレジットカード決済に関する情報が、クレジットカード会社サーバ５０からユーザの主口座であるＡ銀行のＡ銀行サーバ６０Ａに送信されたことに基づいて、ユーザの主口座であるＡ銀行の銀行口座の残高からそのクレジットカード決済に対応する金額をロックし、所定のタイミングでそのロックされた金額を、ユーザの主口座であるＡ銀行の銀行口座からユーザの副口座であるＢ銀行の銀行口座に振替する場合を例示する。

【0805】

ＢＡ７０１０で購入情報を受信しなかったと判定する場合（ＢＡ７０１０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ９０１０～ＢＡ９０２０のステップをスキップする。

【0806】

購入情報を受信したと判定する場合（ＢＡ７０１０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ロック処理を実行する（ＢＡ９０１０）。
このロック処理は、前述したＢ１０２０のステップにおいて説明した処理と同様とすることができるため、説明を省略する。

【0807】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報と、ロック処理の結果とに基づいて、ロック処理が実行されたことを示すフラグの一種であるロック済フラグをセットする（ＢＡ９０２０）。

【0808】

このロック済フラグは、限定ではなく例として、所定の期間（限定ではなく例として、次のクレジットカードの口座引き落とし日までの期間、後述する一括振替要求情報が送信されるまでの期間等）が経過するまで継続してセットされてもよいものとする。

【0809】

また、このロック済フラグは、限定ではなく例として、ロック処理が実行される度にセットされるフラグであり、実行されたロック処理に対応するように一意なロック済フラグがセットされもよいものとする。
具体的には、第１のロック処理が実行された後にセットされるロック済フラグを、限定ではなく例として、第１ロック済フラグとし、第１のロック処理とは異なる第２のロック処理が実行された後にセットされるロック済フラグを、限定ではなく例として、第２ロック済フラグとするようにしてもよい。

【0810】

また、これらのロック処理に対応するロック済フラグには、限定ではなく例として、ロック処理の結果に関する情報が含まれるようにしてもよい。
具体的には、第１ロック済フラグには、限定ではなく例として、第１のロック処理の結果として、第１のロック処理に対応するロック金額などが含まれるようにしてもよく、第２ロック済フラグには、限定ではなく例として、第２のロック処理の結果として、第２のロック処理に対応するロック金額などが含まれるようにしてもよい。

【0811】

ＢＡ９０２０のステップの処理、または、ＢＡ７０１０：ＮＯのステップの処理の後、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、少なくともいずれか一つのロック済フラグがセットされているか否かを判定する（ＢＡ９０３０）。
ロック済フラグがセットされていないと判定する場合には（ＢＡ９０３０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ９０４０～ＢＡ９０５０の処理をスキップし、そのまま処理を終了する。

【0812】

ロック済フラグがセットされたと判定する場合には（ＢＡ９０３０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、一括振替処理要求情報送信条件データ６５７を参照し、一括振替処理要求情報送信条件が成立しているか否かを判定する（ＢＡ９０４０）。
一括振替処理要求情報送信条件が成立していないと判定する場合には（ＢＡ９０４０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ９０５０の処理をスキップする。

【0813】

一括振替処理要求情報送信条件が成立したと判定する場合には（ＢＡ９０４０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、一括振替処理を実行する。
この一括振替処理振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している主口座としての銀行口座（銀行口座ＩＤ）を特定し、その主口座としての銀行口座に紐付けられている副口座としての銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、セットされているロック済フラグに含まれるロック金額の合計を一括して減算して記憶させる。

【0814】

そして、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に基づいて、振替先であるユーザのＢ銀行の銀行口座ＩＤに関する情報と、ユーザのＡ銀行の銀行口座からＢ銀行の銀行口座にロック金額の合計を一括して振替することに関する情報とを含む一括振替情報を、Ｂ銀行サーバ６０Ｂに送信する（ＢＡ９０６０）。

【0815】

Ｂ銀行サーバ６０Ｂの制御部（不図示）は、限定ではなく例として、通信Ｉ／Ｆ（不図示）によってＡ銀行サーバ６０Ａから一括振替情報を受信したか否かを判定する（ＢＢ９０１０）。
通信Ｉ／ＦによってＡ銀行サーバ６０Ａから一括振替情報を受信しなかったと判定する場合（ＢＢ９０１０：ＮＯ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、ＢＢ９０２０～ＢＢ９０３０のステップをスキップする。

【0816】

通信Ｉ／ＦによってＡ銀行サーバ６０Ａから一括振替情報を受信したと判定する場合（ＢＢ９０１０：ＹＥＳ）、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、一括振替処理を実行する（ＢＢ９０２０）。
一括振替処理において、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、受信した一括振替情報に含まれる、振替先であるＢ銀行の銀行口座ＩＤに関する情報と、ロック金額の合計に関する情報とに基づいて、銀行口座ユーザ管理データベース６５９に記憶される銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの残高のデータに、受信したロック金額の合計に関する情報を一括して加算して記憶させる。

【0817】

そして、Ｂ銀行サーバ６０Ｂの制御部は、限定ではなく例として、Ｂ銀行サーバ６０での一括振替処理の結果に関する情報を含む一括振替結果情報を、通信Ｉ／ＦによってＡ銀行サーバ６０Ａに送信する（ＢＢ９０３０）。

【0818】

Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから一括振替結果情報を受信したか否かを判定する（ＢＡ９０７０）。
通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから一括振替結果情報を受信しなかったと判定する場合（ＢＡ９０７０：ＮＯ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ９０８０のステップをスキップする。

【0819】

通信Ｉ／ＦによってＢ銀行サーバ６０Ｂから一括振替結果情報を受信したと判定する場合（ＢＡ９０７０：ＹＥＳ）、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、Ｂ銀行サーバ６０Ｂから受信した一括振替結果情報と同様の一括振替結果情報を、通信Ｉ／Ｆによって端末２０に送信する（ＢＡ９０８０）。

【0820】

端末２０の制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから一括振替結果情報を受信したか否かを判定する（Ａ９０１０）。
通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから一括振替結果情報を受信しなかったと判定する場合（Ａ９０１０：ＮＯ）、端末２０の制御部２１は、限定ではなく例として、Ａ９０２０のステップをスキップする。

【0821】

通信Ｉ／Ｆ２２によってＡ銀行サーバ６０Ａから一括振替結果情報を受信したと判定する場合（Ａ９０１０：ＹＥＳ）、端末２０の制御部２１は、限定ではなく例として、受信した一括振替結果情報に基づいて、一括振替結果情報を表示部２４に表示させる（Ａ９０２０）。

【0822】

このように、クレジットカードを用いた決済において、クレジットカードの利用金額を、クレジットカードの支払い口座でない銀行口座の残高の方で一旦ロックしておき、クレジットカードの口座引き落とし日が近くなるなどしたタイミングで、ロック金額の合計をクレジットカードの支払い口座でない銀行口座からクレジットカードの支払い口座に一括して振替を行うことによって、クレジットカードの引き落としを行うときの残高を確保することができ、クレジットカードの引き落としを確実に行うことができるとともに、振替に係る手数料や振替に係る処理の負担を軽減化できる。

【0823】

＜第１０実施例の効果＞
本実施例は、銀行サーバ６０（限定ではなく、情報処理装置の一例）が、後払いによる利用金額の情報（限定ではなく、ユーザによって、後払いにより支払われる支払い情報の一例）と、ユーザに関するユーザ情報とを制御部６１によって取得する。
そして、銀行サーバ６０は、取得したユーザ情報に基づいて、ユーザの第１口座に含まれる金額（限定ではなく、第１金額の一例）のうち、取得した支払い情報に基づく金額（限定ではなく、第２金額の一例）に対してロック設定等の設定（限定ではなく、第１設定の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、取得されたユーザ情報に基づいて、ユーザの第１口座に含まれる第１金額のうち、取得された支払い情報に基づく第２金額に対してロック設定を行うことができる。

【0824】

また、この場合、銀行サーバ６０は、上記のような第２金額に対してロック設定等の第１設定が行われた後、設定された日にち、または日時に基づいて、後払いの支払い情報に基づく金額（限定ではなく、第２金額の一例）を第１口座から第２口座に振り替える処理（限定ではなく、第２金額を第１口座から第２口座に移動する処理の一例）を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２金額に対して第１設定が行われた後、設定された日にち、または日時に基づいて、第２金額を第１口座から第２口座に移動することができる。

【0825】

また、この場合、上記の第１設定は、ユーザによる、取得した支払い情報（限定ではなく、支払い情報の一例）に基づく金額（限定ではなく、第２金額の一例）をロックするなどすることによって、ユーザが使用できなくなるようにする設定（限定ではなく、第２金額の使用に関する設定の一例）を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザによる、第２金額の使用に関する設定を行うことができ、第１口座から第２口座に移動する第２金額のユーザにより使用を制限するなどすることができる。

【0826】

また、この場合、上記の第１設定は、第２金額の使用をロックすることに関するロック設定を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２金額の使用をロックすることに関する設定を行わせることができ、第１口座から第２口座に移動する第２金額の使用をロックすることができる。

【0827】

＜第１１実施例＞
第１１実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする実施例に、クレジットカード決済の利用金額に対応する金額をロックするときの条件のうち日または日時に関する条件が設定される実施例を適用した実施例である。つまり、第１１実施例は、前述した第７実施例に第２実施例を適用した実施例と捉えることができる。
第１１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0828】

＜データ構成＞
本実施例では、銀行サーバ６０の記憶部１５には、限定ではなく例として、銀行口座入出金管理処理プログラム６５１と、銀行口座ユーザ登録データ６５３と、提携クレジットカード会社データ６５５と、銀行口座ユーザ管理データベース６５９に加えて、限定ではなく例として、振替処理実行条件データ（不図示）が記憶される。

【0829】

振替処理実行条件データは、振替処理実行条件が設定されたデータとすることができる。振替処理実行条件は、限定ではなく例として、銀行サーバ６０が振替処理を実行するための条件とすることができる。

【0830】

振替処理実行条件データには、限定ではなく例として、条件Ｎｏと、振替処理実行条件とが関連付けて記憶される。

【0831】

条件Ｎｏには、振替処理実行条件に対応した番号（条件の識別情報）が設定される。
条件Ｎｏは、好ましくは振替処理実行条件ごとに一意な値であり、限定ではなく例として、銀行サーバ６０によって振替処理実行条件ごとに一意な値（固有の値）が設定されて記憶される。

【0832】

この場合、振替処理実行条件データの一例として、限定ではなく例として、前述した図２－２のロック要求情報送信条件データと同様の情報が含まれるようにしてもよい。

【0833】

＜処理＞
本実施例における各装置が実行する処理の流れは、前述した各種のフローチャートの処理の流れを組み合わせることによって実現可能であるため、図示を省略する。

【0834】

この場合、限定ではなく例として、前述した図７－５の処理において、ＢＡ７０１０：ＹＥＳのステップの後に、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、前述した図２－７のＳ２０１０のステップと同様の処理を実行するようにすることができる（ＢＡ７０１２）。

【0835】

ＢＡ７０１０：ＮＯのステップ、または、ＢＡ７０１２のステップの後に、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、前述した図２－７のＳ２０２０～Ｓ２０３０のステップと同様の処理を実行するようにすることができる（ＢＡ７０１４、ＢＡ７０１６）
ここで、ＢＡ７０１６のステップの処理では、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、振替処理実行条件データを参照し、振替処理実行条件が成立しているか否かを判定するようにしてもよい。

【0836】

次いで、ＢＡ７０１６：ＹＥＳの場合、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ７０２０のステップの処理を実行するようにしてもよい。

【0837】

また、ＢＡ７０１６：ＮＯの場合、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、ＢＡ７０２０以降のステップの処理をスキップするようにしてもよい。

【0838】

このように、銀行サーバ６０が購入情報を受信した場合に、購入情報受信フラグをセットし、その後も継続してセットすることによって、購入情報を受信したタイミングとは異なるタイミングで振替処理実行条件が成立し得る状況においても、銀行サーバ６０が購入情報を受信済みであることを把握することができる。そして、振替処理実行条件が成立しているか否かの判定などを適確に行うことができる。

【0839】

＜第１１実施例の効果＞
本実施例は、前述した第１設定は、ユーザの給料が振り込まれる日（給料日）（限定ではなく、設定された日にちの一例）が経過した後、またはユーザの給料が振り込まれる日時（限定ではなく、設定された日時以降の一例）が経過した後に行われる構成を示している。
このような構成により得られる実施例の効果の一例として、設定された日にち、または日時が経過した後に、第１設定が行われるようにすることができる。

【0840】

また、この場合、設定された日にち、または日時は、ユーザの給料が振り込まれる日にち、または日時に関連するようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザの給料が振り込まれる日にちに関連する日にちが経過した後、またはユーザの給料が振り込まれる日時に関連する日時が経過した後に、第１設定が行われるようにすることができる。

【0841】

＜第１２実施例＞
第１２実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする実施例に、クレジットカード決済による購入品の品目の種別等に関するロック条件が設定される実施例を適用した実施例である。つまり、第１２実施例は、前述した第７実施例に第３実施例を適用した実施例と捉えることができる。
第１２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0842】

＜データ構成＞
本実施例では、銀行サーバ６０の記憶部１５には、限定ではなく例として、銀行口座入出金管理処理プログラム６５１と、銀行口座ユーザ登録データ６５３と、提携クレジットカード会社データ６５５と、銀行口座ユーザ管理データベース６５９に加えて、限定ではなく例として、振替処理実行条件データ（不図示）が記憶される。

【0843】

本実施例における振替処理実行条件データの一例として、限定ではなく例として、前述した図３－１のロック要求情報送信条件データと同様の情報が含まれるようにしてもよい。

【0844】

＜処理＞
本実施例における各装置が実行する処理の流れは、前述した第１１実施例のフローチャートの処理の流れを同様に適用可能であるため、図示および説明を省略する。

【0845】

このように、限定ではなく例として、ユーザの利用度合いに応じてその月ごとに利用金額が変動し得る変動費である第１種別（食品）、第２種別（日用品）等の購入品に関する利用金額を、クレジットカードの支払い口座に振込することによって、クレジットカード決済の銀行口座からの振替を確実に行うようにすることができる。
一方で、限定ではなく例として、ユーザの利用度合いに関わらずその月ごとに利用金額が固定されている種別の固定費（家賃、光熱費等）や、ユーザがイレギュラーに購入した高額になり得る種別の購入品（趣味の購入品等）に関する利用金額を、クレジットカードの支払い口座に振込しないことによって、ユーザが自由に利用できる銀行口座の残高をむやみに減らしてしまわないようにすることができる。

【0846】

＜第１２実施例の効果＞
本実施例は、銀行サーバ６０は、ユーザによって設定された振替処理実行条件（限定ではなく、第１条件の一例）を満たす購入情報を制御部６１によって取得する構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行う対象の支払い情報として選定することができる。

【0847】

また、この場合、ユーザによって設定された振替処理実行条件は、限定ではなく例として、ユーザの利用度合いに応じてその月ごとに利用金額が変動し得る種別の変動費の属性や、ユーザの利用度合いに関わらずその月ごとに利用金額が固定されている種別の固定費の属性、ユーザがイレギュラーに購入した高額になり得る高額出費の属性といった、支払いの属性（支払いの種別、支払いの種類）に関する設定を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、支払いの属性に関する設定を含む、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行う対象の支払い情報として選定することができる。

【0848】

また、この場合、上記の支払いの属性は、固定費および変動費を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、固定費および変動費を含む支払いの属性に関する設定を含む、ユーザによって設定された第１条件を満たす支払い情報を、その支払い情報に基づく第２金額に対して第１設定を行う対象の支払い情報として選定することができる。

【0849】

＜第１３実施例＞
第１３実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする場合に、その振替金額を元に戻すことに関する実施例を適用した実施例である。つまり、第１３実施例は、前述した第７実施例に第４実施例と類似した構成を適用した実施例と捉えることができる。
第１３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0850】

＜処理＞
本実施例における各装置が実行する処理の流れは、前述した図４－３のフローチャートの処理と同様の処理を適用可能であるため、図示を省略する。

【0851】

この場合、図４－３の各ステップの処理における“ロック”を、限定ではなく例として“振替”に変更するものとしてもよい。
これに対応して各ステップの処理の内容も、“ロック”に関するものから“振替”に関するものに変更されるものとしてもよい。

【0852】

限定ではなく例として、クレジットカード決済が行われたことに基づいて、ユーザＡ．Ａの一の銀行口座から、そのクレジットカード決済の利用金額が他の銀行口座に振替されたときに、振替を解除（キャンセル）することを要求する情報が、ユーザＡ．Ａの端末２０によって家計管理サーバ１０に送信される。そして、その後、その情報に関する情報が家計管理サーバ１０によって銀行サーバ６０に送信されることで、銀行サーバ６０（限定ではなく例として、Ａ銀行サーバ６０Ａ）によって振替が解除（キャンセル）される場合などが考えられる。

【0853】

本実施例におけるＳ４０８０のステップに対応する処理において、家計管理サーバ１０の制御部１１は、限定ではなく例として、振替解除処理の結果に関する情報を含む振替解除結果情報を、通信Ｉ／Ｆ１４によって端末２０に送信する。
ここでの振替解除結果情報は、限定ではなく例として、銀行サーバ６０から家計管理サーバ１０に送信される振替解除結果情報と同様の情報であってもよいし、異なる情報であってもよい。

【0854】

＜第１３実施例の効果＞
本実施例は、銀行サーバ６０が、ユーザの銀行等の金融機関の口座に含まれる金額（限定ではなく、第１金額の一例）が、購入情報（限定ではなく、支払い情報の一例）に基づく金額（限定ではなく、第２金額の一例）より小さい金額の場合、振替を行うための口座残高が不足していることをユーザに通知する情報（限定ではなく、口座の残高が足りないことを示す情報の一例）をユーザの端末２０に送信する制御を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額が第２金額よりも小さい金額の場合、口座の残高が足りないことを示す情報がユーザの端末に送信されることによって、口座の残高が足りないことを端末のユーザに知らせることができる。

【0855】

＜第１４実施例＞
第１４実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする場合に、振替を行う第１の銀行口座の残高が不足する場合の実施例である。つまり、第１４実施例は、前述した第７実施例に第５実施例と類似した構成を適用した実施例と捉えることができる。
第１４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0856】

＜処理＞
本実施例における処理の流れは、前述した各種のフローチャートの処理の流れを同様に適用可能であるため、図示を省略する。

【0857】

限定ではなく例として、図７－５等の処理のＢＡ７０２０の振替処理において、Ａ銀行の銀行口座の残高が不足していたことによって、クレジットカード決済の利用金額を振替できなかった場合、限定ではなく例として、Ａ銀行サーバ６０Ａの制御部は、ＢＡ７０３０～ＢＡ７０４０の処理をスキップして、ＢＡ７０５０の処理を実行するようにして、限定ではなく例として、ＢＡ７０５０の振替結果情報に、振替するための銀行口座の残高が不足していたことをユーザに通知する通知情報を含めることができる。

【0858】

そして、Ａ銀行サーバ６０Ａによって送信された、この振替するための銀行口座の残高が不足していたことをユーザに通知する通知情報を含む振替結果情報を受信した端末２０Ａの制御部２１によって振替結果情報が表示部２４に表示されることによって、端末２０のユーザＡ．Ａは振替するための銀行口座の残高が不足していたことを認識できる。

【0859】

＜第１４実施例の効果＞
本実施例は、銀行サーバ６０（限定ではなく、情報処理装置の一例）が、ユーザの口座に含まれる金額（限定ではなく、第１金額の一例）が、支払い情報に基づく金額（限定ではなく、第２金額の一例）より小さい金額の場合、振替するための口座残高が不足していることをユーザに通知する情報（限定ではなく、口座の残高が足りないことを示す情報の一例）をユーザの端末２０に送信する制御を制御部６１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額が第２金額よりも小さい金額の場合、口座の残高が足りないことを示す情報がユーザの端末に送信されることによって、口座の残高が足りないことを端末のユーザに知らせることができる。

【0860】

＜第１５実施例＞
第１５実施例は、クレジットカード決済の利用金額に対応する金額を、クレジットカード決済の支払いを行う第１の銀行口座から、クレジットカード決済の支払いを行わない第２の銀行口座に振替し、クレジットカードの口座引き落としが完了するまで、ユーザが第１の銀行口座の残高のうちその金額を使用することを困難とする場合に、クレジットカード決済における購入品の品目の種別に応じて、一の銀行口座から他の銀行口座に振替可能な金額が設定される場合に関する実施例である。つまり、第１５実施例は、前述した第７実施例に第６実施例と類似した構成を適用した実施例と捉えることができる。
第１５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0861】

本実施例では、クレジットカード決済における購入品の品目の種別に応じて、振替可能な金額（以下、適宜「振替上限金額」や「振替可能金額」等と称する。）を設定することができるようにしてもよい。

【0862】

この振替上限金額は、限定ではなく例として、クレジットカード決済における購入品の品目の種別に応じて設定された金額であるものとしてもよく、限定ではなく例として、第６実施例に示したロック上限金額と同様に、振替上限金額が設定されもよい。

【0863】

＜データ構成＞
本実施例における銀行口座ユーザ管理データベース６５９の一例である銀行口座ユーザ管理データには、限定ではなく例として、契約者ＩＤと、登録クレジットカード管理データと、銀行口座入出金管理データとが記憶される。
本実施例における銀行口座入出金管理データには、限定ではなく例として、振替合計金額と、その振替合計金額に関する、購入品の品目の種別と、種別振替金額と、振替上限金額とが記憶される。

【0864】

振替合計金額は、限定ではなく例として、この契約者ＩＤのユーザの銀行口座から他の銀行口座に振替されている金額を合計した金額である。

【0865】

種別は、この契約者ＩＤのユーザの振替合計金額のうち購入品の品目の種別に関する情報である。

【0866】

種別振替金額は、この契約者ＩＤのユーザの振替合計金額のうち購入品の品目の種別に対応する振替されている合計の金額である。

【0867】

振替上限金額は、この購入品の品目の種別に対応する振替可能な金額であり、任意の値が記憶される。

【0868】

このデータによれば、ユーザの銀行口座の口座残高に対応する金額が、購入品の品目の種別等のカテゴリに応じた振替上限金額によって概念的に複数分割され、このようにして複数分割された金額のうちの購入情報に基づく金額を振替設定させるようにすることができる。

【0869】

＜処理＞
本実施例における処理の流れは、前述した各種のフローチャートの処理の流れを同様に適用可能であるため、図示を省略する。

【0870】

この場合、限定ではなく例として、図７－５等の処理のＢＡ７０２０の振替処理において、Ａ銀行サーバ６０Ａの制御部は、限定ではなく例として、受信した購入情報に含まれるクレジットカードＩＤに基づいて、銀行口座ユーザ管理データベース６５９に記憶される登録クレジットカード管理データのうち、そのクレジットカードＩＤに対応するクレジットカードを振替口座として登録している銀行口座（銀行口座ＩＤ）を特定する。そして、銀行口座ユーザ管理データベース６５９に記憶される銀行口座ユーザ管理データのうち、特定した銀行口座に対応する銀行口座入出金管理データの振替合計金額、種別、種別振替金額のデータに、受信した購入金額（振替金額）に関する情報を記憶させる。

【0871】

そして、一の種別の振替金額が振替上限金額を超える場合（超過状態となる場合）、ＢＡ７０５０のステップの振替結果情報に、限定ではなく例として、振替金額が超過状態となることをユーザに通知する通知情報を含めることができる。

【0872】

このように、クレジットカード決済での取引により一の種別の振替金額が超過状態となる場合に、銀行サーバ６０によって送信された振替金額が超過状態となることをユーザに通知する通知情報を含む振替結果情報を受信したユーザＡ．Ａの端末２０の制御部２１によって、限定ではなく例として、振替結果情報が表示部２４に表示されることによって、端末２０のユーザＡ．Ａにその種別の振替金額が超過状態となることを認識させることができ、その種別の品目の購入品をこれ以上購入することを抑制できる。

【0873】

＜第１５実施例の効果＞
本実施例は、ユーザの口座に含まれる残高（限定ではなく、第１金額の一例）は、複数分割されたうちの一つの金額である構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザの口座に含まれる金額が複数分割されたうちの一つの金額を第１金額とし、この第１金額のうちの第２金額に対して第１設定を行うことができる。

【0874】

また、この場合、ユーザの口座に含まれる第１金額は、口座に含まれる金額が、ユーザによって購入品の種別等のカテゴリごとに分割されたうちの一つの金額であるようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザの口座に含まれる金額が、ユーザによってカテゴリごとに分割されたうちの一つの金額を第１金額とし、この第１金額のうちの第２金額に対して第１設定を行うことができる。

【0875】

＜その他＞
上記の実施例で説明した情報処理装置は、サーバに限定されず、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（personal digital assistant）などの情報処理端末であってもよい。

【0876】

また、上記の実施例で説明した手法を、複数のシステムとして構成して実現してもよい。限定ではなく例として、家計管理サーバとクレジットカード会社サーバとで構成される第１システム（家計管理システム・クレジットカード会社システム）を構成し、限定ではなく例として、第１システムの家計管理サーバから送信される情報に基づいて、銀行サーバがロックや振替の設定・処理を行うようにするなどしてもよい。
また、家計管理サーバと銀行サーバとで構成される第２システム（家計管理システム・銀行システム）を構成し、限定ではなく例として、クレジットカード会社サーバから送信される購入情報に基づいて家計管理サーバが情報を銀行サーバに送信し、銀行サーバがロックや振替の設定・処理を行うようにするなどしてもよい。

【0877】

また、上記の実施例でサーバの制御部が行うこととして説明した処理のうちの少なくとも一部の処理を、端末の制御部が行うようにしてもよい。

【0878】

また、上記の実施例において、各種のアプリケーション（家計管理アプリケーション、クレジットカードアプリケーション、銀行アプリケーション、メッセージングアプリケーション、支払いアプリケーション等のアプリケーション）を配信する用のサーバ（端末がアプリケーションをダウンロードするサーバ）を、対応するサービス（アプリケーション）を提供するサーバ等とは異なるサーバとして構成してもよい。つまり、アプリケーションを配信する用のサーバと、上記の実施例等で説明したアプリケーション管理処理等を行うサーバ等とを物理的に分離されたサーバとして構成してもよいし、１つのサーバとして構成してもよい。

【0879】

また、アプリケーションには、各種のアプリケーションのプログラムに限らず、限定ではなく例として、おおもととなるアプリケーションの一機能として他のサービスの機能を持たせるためのプログラム（限定ではなく例として、メッセージングアプリケーションの一機能として支払いサービスの機能を持たせるためのプログラム、またはその逆）や、おおもととなるアプリケーションのアップデート用のプログラム等を含めてもよい。また、アプリケーションプログラムで活用されるデータ（アプリケーションのアップデート用のデータ等も含めてもよい。）を含めてもよい。

【0880】

また、上記の実施例では、限定ではなく例として、本発明をクライアントサーバシステムによって実現する手法を説明したが、これに限定されない。前述したように、分散システムなど、サーバやサーバシステムの機能を端末に持たせるシステムによって実現してもよい。限定ではなく例として、上記の実施例で説明したフローチャートで、サーバやサーバシステムが行うこととして説明した処理を、端末が行うようにしてもよい。

【符号の説明】

【0881】

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

【図1-1】

【図1-2】

【図1-3】

【図1-4】

【図1-5】

【図1-6】

【図1-7】

【図1-8】

【図1-9】

【図1-10】

【図1-11】

【図1-12】

【図1-13】

【図1-14】

【図1-15】

【図1-16】

【図1-17】

【図1-18】

【図1-19】

【図1-20】

【図1-21】

【図1-22】

【図1-23】

【図1-24】

【図2-1】

【図2-2】

【図2-3】

【図2-4】

【図2-5】

【図2-6】

【図2-7】

【図3-1】

【図3-2】

【図4-1】

【図4-2】

【図4-3】

【図4-4】

【図4-5】

【図4-6】

【図5-1】

【図5-2】

【図6-1】

【図6-2】

【図6-3】

【図6-4】

【図7-1】

【図7-2】

【図7-3】

【図7-4】

【図7-5】

【図7-6】

【図7-7】

【図7-8】

【図7-9】

【図7-10】

【図7-11】

【図7-12】

【図7-13】

【図7-14】

【図7-15】

【図8-1】

【図8-2】

【図8-3】

【図8-4】

【図8-5】

【図8-6】

【図8-7】

【図8-8】

【図8-9】

【図8-10】

【図9-1】

【図9-2】

【図9-3】

【図9-4】

【図9-5】

【図9-6】

【図10-1】

【図10-2】

【図10-3】

【図10-4】