ホーム > 特許ランキング > ＬＩＮＥヤフー株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024159107
(43)【公開日】2024-11-08
(54)【発明の名称】プログラム、情報処理方法、サーバ
(51)【国際特許分類】
G06Q 20/14 20120101AFI20241031BHJP
【ＦＩ】
G06Q20/14
【審査請求】未請求
【請求項の数】21
【出願形態】ＯＬ
(21)【出願番号】P 2023074884
(22)【出願日】2023-04-28
(71)【出願人】
【識別番号】500257300
【氏名又は名称】ＬＩＮＥヤフー株式会社
(74)【代理人】
【識別番号】110001759
【氏名又は名称】弁理士法人よつ葉国際特許事務所
(74)【代理人】
【識別番号】100093687
【弁理士】
【氏名又は名称】富崎 元成
(74)【代理人】
【識別番号】100168468
【弁理士】
【氏名又は名称】富崎 曜
(74)【代理人】
【識別番号】100166176
【弁理士】
【氏名又は名称】加美山 豊
(72)【発明者】
【氏名】小原 由利絵
(72)【発明者】
【氏名】鈴村 天馬
(72)【発明者】
【氏名】赤塚 敏晃
(72)【発明者】
【氏名】伊東 宏祐
(72)【発明者】
【氏名】山内 智博
【テーマコード（参考）】
5L020
5L055
【Ｆターム（参考）】
5L020AA32
5L055AA32
(57)【要約】
【課題】貸し付けた金額の返済等に関する利便性を向上させる。
【解決手段】ユーザの端末と通信するサーバによって実行されるプログラムは、ユーザに貸し付けた金額の情報をサーバの記憶部に記憶する制御をサーバの制御部によって行うことと、貸し付けた金額の返済期限が過ぎている場合、貸し付けた金額の情報と、貸し付けた利率の情報とを端末にサーバの通信部によって送信することとがサーバによって実行される。
【選択図】図１－１
【解決手段】ユーザの端末と通信するサーバによって実行されるプログラムは、ユーザに貸し付けた金額の情報をサーバの記憶部に記憶する制御をサーバの制御部によって行うことと、貸し付けた金額の返済期限が過ぎている場合、貸し付けた金額の情報と、貸し付けた利率の情報とを端末にサーバの通信部によって送信することとがサーバによって実行される。
【選択図】図１－１
【特許請求の範囲】
【請求項1】
ユーザの端末と通信するサーバによって実行されるプログラムであって、
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を前記サーバの制御部によって行うことと、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に前記サーバの通信部によって送信することとが前記サーバによって実行される。
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を前記サーバの制御部によって行うことと、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に前記サーバの通信部によって送信することとが前記サーバによって実行される。
【請求項2】
請求項１に記載のプログラムであって、
前記貸し付けた金額の返済期限が過ぎている場合、遅延損害金率の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記貸し付けた金額の返済期限が過ぎている場合、遅延損害金率の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項3】
請求項１または請求項２に記載のプログラムであって、
前記貸し付けた金額の返済期限が過ぎている場合、最終借入日に関する契約日の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記貸し付けた金額の返済期限が過ぎている場合、最終借入日に関する契約日の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項4】
請求項１から請求項３のいずれか一項に記載のプログラムであって、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを含む、督促状を前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを含む、督促状を前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項5】
請求項１から請求項４のいずれか一項に記載のプログラムであって、
前記貸し付けた金額の情報と、貸し付けた利率の情報とを、前記ユーザを含むチャットルームに前記通信部によって送信することが前記サーバによって実行される。
前記貸し付けた金額の情報と、貸し付けた利率の情報とを、前記ユーザを含むチャットルームに前記通信部によって送信することが前記サーバによって実行される。
【請求項6】
請求項１から請求項５のいずれか一項に記載のプログラムであって、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを、前記ユーザの信用スコアの情報に基づいて、前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを、前記ユーザの信用スコアの情報に基づいて、前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項7】
請求項１から請求項６のいずれか一項に記載のプログラムであって、
前記貸し付けた金額に基づく、入金の約束に関する情報を前記端末から前記通信部によって受信することと、
前記入金の約束に関する情報を前記記憶部に記憶する制御を前記制御部によって行うこととが前記サーバによって実行される。
前記貸し付けた金額に基づく、入金の約束に関する情報を前記端末から前記通信部によって受信することと、
前記入金の約束に関する情報を前記記憶部に記憶する制御を前記制御部によって行うこととが前記サーバによって実行される。
【請求項8】
請求項７に記載のプログラムであって、
前記入金の約束に関する情報は、入金約束日に関する情報を含む。
前記入金の約束に関する情報は、入金約束日に関する情報を含む。
【請求項9】
請求項８に記載のプログラムであって、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを含む、第１督促状を前記端末に前記通信部によって送信することと、
前記第１督促状に対する前記ユーザによる入力に基づいて、前記入金の約束に関する情報を前記端末から前記通信部によって受信することとが前記サーバによって実行される。
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、前記貸し付けた利率の情報とを含む、第１督促状を前記端末に前記通信部によって送信することと、
前記第１督促状に対する前記ユーザによる入力に基づいて、前記入金の約束に関する情報を前記端末から前記通信部によって受信することとが前記サーバによって実行される。
【請求項10】
請求項９に記載のプログラムであって、
前記入金約束日に基づいて、前記第１督促状よりも後に送信される第２督促状が前記通信部によって前記端末に送信される。
前記入金約束日に基づいて、前記第１督促状よりも後に送信される第２督促状が前記通信部によって前記端末に送信される。
【請求項11】
請求項９または請求項１０に記載のプログラムであって、
前記第１督促状に対する前記ユーザによる入力に基づいて、前記貸し付けた金額に基づく返済予定金額の情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
前記第１督促状に対する前記ユーザによる入力に基づいて、前記貸し付けた金額に基づく返済予定金額の情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
【請求項12】
請求項７から請求項１１のいずれか一項に記載のプログラムであって、
前記貸し付けた金額の情報と、貸し付けた利率の情報とを、前記ユーザを含むチャットルームに前記通信部によって送信することと、
前記チャットルームへの前記ユーザによる入力に基づいて、前記入金の約束に関する情報を前記端末から前記通信部によって受信することとが前記サーバによって実行される。
前記貸し付けた金額の情報と、貸し付けた利率の情報とを、前記ユーザを含むチャットルームに前記通信部によって送信することと、
前記チャットルームへの前記ユーザによる入力に基づいて、前記入金の約束に関する情報を前記端末から前記通信部によって受信することとが前記サーバによって実行される。
【請求項13】
請求項５に記載のプログラムであって、
前記チャットルームへの前記ユーザによる入力に基づいて、前記貸し付けた金額に基づく、前記ユーザが返済する必要がある返済金額に関する情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
前記チャットルームへの前記ユーザによる入力に基づいて、前記貸し付けた金額に基づく、前記ユーザが返済する必要がある返済金額に関する情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
【請求項14】
請求項４に記載のプログラムであって、
前記督促状に対する前記ユーザの入力に基づいて、前記貸し付けた金額に対する返済を行うための口座の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記督促状に対する前記ユーザの入力に基づいて、前記貸し付けた金額に対する返済を行うための口座の情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項15】
請求項４に記載のプログラムであって、
前記ユーザの電子貨幣の残高が、前記貸し付けた金額に基づく返済金額よりも多い場合、第３督促状を前記端末に前記通信部によって送信し、前記ユーザの電子貨幣の残高が、前記貸し付けた金額に基づく返済金額よりも少ない場合、前記貸し付けた金額に対する返済を行うための口座の情報を含む第４督促状を前記端末に前記通信部によって送信することが前記サーバによって実行される。
前記ユーザの電子貨幣の残高が、前記貸し付けた金額に基づく返済金額よりも多い場合、第３督促状を前記端末に前記通信部によって送信し、前記ユーザの電子貨幣の残高が、前記貸し付けた金額に基づく返済金額よりも少ない場合、前記貸し付けた金額に対する返済を行うための口座の情報を含む第４督促状を前記端末に前記通信部によって送信することが前記サーバによって実行される。
【請求項16】
請求項４に記載のプログラムであって、
前記督促状は、前記ユーザが前記貸し付けた金額に基づく返済が滞っている理由に関する情報を含む。
前記督促状は、前記ユーザが前記貸し付けた金額に基づく返済が滞っている理由に関する情報を含む。
【請求項17】
請求項１から請求項１６のいずれか一項に記載のプログラムであって、
設定された時間帯に基づいて、前記貸し付けた金額の情報と、貸し付けた利率の情報とを送信する制御を前記制御部によって行うことが前記サーバによって実行される。
設定された時間帯に基づいて、前記貸し付けた金額の情報と、貸し付けた利率の情報とを送信する制御を前記制御部によって行うことが前記サーバによって実行される。
【請求項18】
請求項１から請求項１７のいずれか一項に記載のプログラムであって、
前記端末に送信された、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記ユーザが閲覧したことに関する情報を、前記ユーザの情報に関連付けて前記記憶部に記憶する制御を前記制御部によって行うことが前記サーバによって実行される。
前記端末に送信された、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記ユーザが閲覧したことに関する情報を、前記ユーザの情報に関連付けて前記記憶部に記憶する制御を前記制御部によって行うことが前記サーバによって実行される。
【請求項19】
請求項４に記載のプログラムであって、
前記督促状は、前記ユーザの属性情報を入力することに関する情報を含む。
前記督促状は、前記ユーザの属性情報を入力することに関する情報を含む。
【請求項20】
ユーザの端末と通信するサーバの情報処理方法であって、
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を前記サーバの制御部によって行うことと、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に前記サーバの通信部によって送信することとを含む。
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を前記サーバの制御部によって行うことと、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に前記サーバの通信部によって送信することとを含む。
【請求項21】
ユーザの端末と通信するサーバであって、
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を行う制御部と、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に送信する通信部とを備える。
前記ユーザに貸し付けた金額の情報を前記サーバの記憶部に記憶する制御を行う制御部と、
前記貸し付けた金額の返済期限が過ぎている場合、前記貸し付けた金額の情報と、貸し付けた利率の情報とを前記端末に送信する通信部とを備える。
【発明の詳細な説明】
【技術分野】
【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】第１変形例に係る端末の表示部に表示される画面の一例を示す図。
【図2-1】第２実施例に係るアカウント管理データベースの一例を示す図。
【図2-2】第２実施例に係る端末の表示部に表示される画面の一例を示す図。
【図2-3】第２実施例に係る端末の表示部に表示される画面の一例を示す図。
【図2-4】第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【図2-5】第２変形例に係る端末の表示部に表示される画面の一例を示す図。
【図2-6】第２変形例に係る端末の表示部に表示される画面の一例を示す図。
【図2-7】第２変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【図2-8】第２変形例に係る端末の表示部に表示される画面の一例を示す図。
【図2-9】第２変形例に係る端末の表示部に表示される画面の一例を示す図。
【図2-10】第２変形例に係る端末の表示部に表示される画面の一例を示す図。
【図3-1】第３実施例に係る端末の表示部に表示される画面の一例を示す図。
【図3-2】第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【図4-1】第４実施例に係る端末の表示部に表示される画面の一例を示す図。
【図5-1】第６実施例に係る端末の表示部に表示される画面の一例を示す図。
【図5-2】第６実施例に係る端末の表示部に表示される画面の一例を示す図。
【図6-1】第９実施例に係る端末の表示部に表示される画面の一例を示す図。
【発明を実施するための形態】
【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】
また、以下の実施例では、ユーザが金融機関からお金を借りるためのサービスの一例として、マネーローンサービス（Loan Service）を例示する。また、マネーローンサービスを実現するためのアプリケーションを「マネーローンアプリケーション」と称する。
マネーローンアプリケーションでは、限定ではなく例として、ユーザがマネーローンサービスの事業者から金銭を借りることや、借りた金銭のローン返済に関する情報を取得することができ。
マネーローンアプリケーションでは、限定ではなく例として、ユーザがマネーローンサービスの事業者から金銭を借りることや、借りた金銭のローン返済に関する情報を取得することができ。
【0046】
また、以下の実施例では、ユーザが支払いを行うためのサービス（以下、「支払いサービス」と称する。）を例示する。また、支払いサービスを実現するためのアプリケーションを「支払いアプリケーション」と称する。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い（決済）を行うようにことができるようにすることができる。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い（決済）を行うようにことができるようにすることができる。
【0047】
本明細書において、「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末、または端末のユーザが所有する電子的な貨幣を意味するものとしてよいものとする。
なお、「電子貨幣」は、「デジタル通貨（デジタル貨幣）」と考えてもよいものとする。
なお、「電子貨幣」は、「デジタル通貨（デジタル貨幣）」と考えてもよいものとする。
【0048】
１つの考え方として、電子貨幣は、「電子マネー」、「仮想通貨（暗号資産）」、「中央銀行発行デジタル通貨（ＣＢＤＢ）」などを含む概念と考えてもよいものとする。
【0049】
また、電子貨幣は、「法定通貨」でもよいし、「企業通貨」でもよいものとする。電子貨幣の実装方法としては、「中央集権型金融（ＣｅＦｉ）」としてもよいし、「分散型金融（ＤｅＦｉ）」としてもよいものとする。
【0050】
以下説明する実施例では、限定ではなく例として、電子貨幣の一例として、中央集権型金融における企業通貨としての電子マネーについて例示する。
【0051】
なお、企業通貨には、クーポンなどの物的貨幣を含めてもよいものとする。
【0052】
マネーローンサービス（マネーローンアプリケーション）を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ１）メッセージングアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ａ２）支払いアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ｂ１）マネーローンサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ２）マネーローンサービスの機能と支払いサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ３）マネーローンサービスの機能と支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ１）マネーローンアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｃ２）マネーローンアプリケーションとは別のアプリケーションとして支払いアプリケーションを構成する形態
（Ｃ３）マネーローンアプリケーションとは別のアプリケーションとして支払いサービスとメッセージングサービスとの統合的なアプリケーションを構成する形態
（Ｄ）マネーローンアプリケーションを単体のアプリケーションとして構成する形態
（Ａ１）メッセージングアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ａ２）支払いアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ｂ１）マネーローンサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ２）マネーローンサービスの機能と支払いサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ３）マネーローンサービスの機能と支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ１）マネーローンアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｃ２）マネーローンアプリケーションとは別のアプリケーションとして支払いアプリケーションを構成する形態
（Ｃ３）マネーローンアプリケーションとは別のアプリケーションとして支払いサービスとメッセージングサービスとの統合的なアプリケーションを構成する形態
（Ｄ）マネーローンアプリケーションを単体のアプリケーションとして構成する形態
【0053】
（Ａ１）や（Ｂ１）、（Ｂ３）の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。
【0054】
マネーローンサービス事業者を、支払いサービス事業者と同じ事業者とする場合についても同様である。
【0055】
（Ｃ１）～（Ｃ３）の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、（Ｃ１）～（Ｃ３）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。
支払いアプリケーションについても同様である。
また、（Ｃ１）～（Ｃ３）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。
支払いアプリケーションについても同様である。
【0056】
なお、上記とは異なり、マネーローンアプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。マネーローンアプリケーションの一機能として支払いサービスの機能を持たせるようにしてもよい。
【0057】
また、以下では、限定ではなく例として、マネーローンサービス事業者またはメッセージングサービス事業者によって、サーバ１０が運用・管理されることとして説明する。
【0058】
また、以下では、端末２０Ａのユーザを「ユーザＡ．Ａ」、端末２０Ｂのユーザを「ユーザＢ．Ｂ」、端末２０Ｃのユーザを「ユーザＣ．Ｃ」、・・・、として説明する。
【0059】
＜実施例＞
以下、本発明を適用した実施例の一例について説明する。
一例であるが、ユーザがマネーローンサービス事業者等の事業者からお金を借りた場合、ローン契約時に定められる約定返済日を迎えたにも関わらず返済が滞ってしまう場合が生じる。この場合、マネーローンサービス事業者等はユーザに対して返済が滞っていることを通知する書面を送付することが可能である。
以下の実施例では、事業者としてマネーローンサービス事業者を例示する。
以下、本発明を適用した実施例の一例について説明する。
一例であるが、ユーザがマネーローンサービス事業者等の事業者からお金を借りた場合、ローン契約時に定められる約定返済日を迎えたにも関わらず返済が滞ってしまう場合が生じる。この場合、マネーローンサービス事業者等はユーザに対して返済が滞っていることを通知する書面を送付することが可能である。
以下の実施例では、事業者としてマネーローンサービス事業者を例示する。
【0060】
この書面は、従来、手紙などの形式（以下、適宜「アナログ形式」と称する。）でユーザに対して送付されていた。
以下説明する実施例は、このような書面を、限定ではなく例として、マネーローンサービス事業者のＯＡを送信元とするメッセージングサービスのメッセージや、マネーローンサービスにおけるお知らせ等の形式（以下、適宜「デジタル形式」と称する。）で送付することに関する実施例である。
以下説明する実施例は、このような書面を、限定ではなく例として、マネーローンサービス事業者のＯＡを送信元とするメッセージングサービスのメッセージや、マネーローンサービスにおけるお知らせ等の形式（以下、適宜「デジタル形式」と称する。）で送付することに関する実施例である。
【0061】
返済が遅延した場合、マネーローンサービス事業者がユーザに対して返済が滞っていることを通知する書面の一例として、限定ではなく例として、以下のようなものを含めてよい。
・延滞通知書
・督促状
・催告書
・延滞通知書
・督促状
・催告書
【0062】
延滞通知書は、限定ではなく例として、マネーローンサービス事業者がユーザに対して返済が滞っていることを通知し、ユーザに対して返済するように促す書面であるようにしてよい。
【0063】
督促状は、限定ではなく例として、前述した延滞通知書と同様に、マネーローンサービス事業者がユーザに対して返済が滞っていることを通知し、ユーザに対して返済するように促す書面であるものの、限定ではなく例として、延滞通知書よりも厳しいことを明記することができる書面であるようにしてよい。
【0064】
具体的には、督促状には、限定ではなく例として、以下に示すような項目を含めるようにしてよい。
・賃金業を営む者の商号、名称または氏名および住所ならびに電話番号
・当該書面または電磁的記録を送付する者の氏名
・契約年月日
・貸付けの金額
・貸付けの利率
・支払いの催告に係る債権の弁済期
・支払いを催告する金額
・支払いの催告時における当該催告に係る残存債務の額
・支払いを催告する金額の内訳（元金、利息および債務不履行による賠償額の別をいう）
・賃金業を営む者の商号、名称または氏名および住所ならびに電話番号
・当該書面または電磁的記録を送付する者の氏名
・契約年月日
・貸付けの金額
・貸付けの利率
・支払いの催告に係る債権の弁済期
・支払いを催告する金額
・支払いの催告時における当該催告に係る残存債務の額
・支払いを催告する金額の内訳（元金、利息および債務不履行による賠償額の別をいう）
【0065】
催告書は、限定ではなく例として、前述した督促状と同様の書面であるものの、限定ではなく例として、督促状よりも厳しいことを明記することができる書面であるようにしてよい。
具体的には、催告書には、限定ではなく例として、前述した督促状に含まれる項目に加えて、以下のような項目を含めるようにしてよい。
・弁済期までに履行がなかった場合に法的措置をとること
・保証人や連帯保証人に請求すること
・支払いを催告する金額の一括弁済を求めること
具体的には、催告書には、限定ではなく例として、前述した督促状に含まれる項目に加えて、以下のような項目を含めるようにしてよい。
・弁済期までに履行がなかった場合に法的措置をとること
・保証人や連帯保証人に請求すること
・支払いを催告する金額の一括弁済を求めること
【0066】
この督促状や催告書には、限定ではなく例として、これらの書面をユーザに送付するなどすることによって、マネーローンサービス事業者がユーザに支払いを請求する意思があることを示すという法律的な意味合いが含まれるようにしてよい。これらの書面がユーザに送付されるなどすることによって、借金返済に関する時効の完成を延長することができる。
【0067】
また、督促状や催告書は、限定ではなく例として、内容証明で送付されるようにしてよいし、しなくてもよい。
【0068】
なお、マネーローンサービス事業者がユーザに対して返済するように促す書面としての、督促状と、催告書とが、限定ではなく例として、名称が異なり、内容も異なる書面であるようにしてよい例を示したが、このような例に限定されず、名称が異なるだけであり、同様の内容の書面であるようにしてもよい。
【0069】
以下説明する実施例では、限定ではなく例として、ユーザの返済が滞っているときに送付される書面が督促状である場合を一例として例示する。
ただし、これに限定されるものではない。
ただし、これに限定されるものではない。
【0070】
本明細書では、ローン契約について、限定ではなく例として、以下のようなプランを含めるようにしてよい。
・ポケットプラン
・マイペースプラン
・ポケットプラン
・マイペースプラン
【0071】
ポケットプランは、限定ではなく例として、貸付日から約定返済開始日までの期間と、約定返済開始日以降の約定返済日間の期間とが同等に設定される一般的なローン契約としてよい。
【0072】
マイペースプランは、限定ではなく例として、貸付日から約定返済開始日までの期間が、約定返済開始日以降の約定返済日間の期間よりも長く設定されるローン契約としてよい。
【0073】
本明細書におけるメインの実施例では、限定ではなく例として、ポケットプランを適用した場合を例示する。
マイペースプランを適用する場合については後述する。
マイペースプランを適用する場合については後述する。
【0074】
本明細書では、端末２０のユーザがマネーローンサービス事業者とローン契約を結んでいる場合に、約定返済日になされる返済方法は、限定ではなく例として、主にマネーローンサービスに連携されている電子マネーの残高（以下、「電子マネー残高」と称する。）から自動で返済されるようにしてよい。
ただし、これに限定されるものではなく、後述するが、銀行振込返済など他の返済方法で返済可能としてもよい。
ただし、これに限定されるものではなく、後述するが、銀行振込返済など他の返済方法で返済可能としてもよい。
【0075】
そして、ユーザが約定返済日に返済を行わないことに基づいて督促状が送付された場合、ユーザが督促状から返済を行うことができるようにしてよい。
後述する図１－８中央の画面における返済ボタンＨＢＴ等がユーザによってタップされる等した場合、限定ではなく例として、電子マネーで返済を行うための画面に遷移するようにしてよい。
この画面では、限定ではなく例として、電子マネーに残高をチャージするように（限定ではなく例として、電子マネー残高が返済金額よりも多い金額となるように）促す画面であるようにしてよい。
後述する図１－８中央の画面における返済ボタンＨＢＴ等がユーザによってタップされる等した場合、限定ではなく例として、電子マネーで返済を行うための画面に遷移するようにしてよい。
この画面では、限定ではなく例として、電子マネーに残高をチャージするように（限定ではなく例として、電子マネー残高が返済金額よりも多い金額となるように）促す画面であるようにしてよい。
【0076】
＜第１実施例＞
第１実施例は、限定ではなく例として、一の端末２０（以下、適宜「端末」と称する。）のユーザが、サーバ１０を運用するマネーローンサービス事業者とローン（貸金）契約を行い、その返済が滞ったことにより督促状が送付される場合の実施例である。
第１実施例は、限定ではなく例として、一の端末２０（以下、適宜「端末」と称する。）のユーザが、サーバ１０を運用するマネーローンサービス事業者とローン（貸金）契約を行い、その返済が滞ったことにより督促状が送付される場合の実施例である。
【0077】
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0078】
また、以下では、マネーローンアプリケーションの名称を、適宜「Ｍｏｎｅｙ Ｌｏａｎ Ａｐｐ」と称して図示・説明する。また、メッセージングアプリケーションの名称を、適宜「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」と称して図示・説明する。
【0079】
＜システム構成＞
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。
【0080】
サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、マネーローンサービス、メッセージングサービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、マネーローンサービスサーバ、メッセージングサービスサーバ等のように表現してもよい。
本実施形態では、マネーローンサービス事業者（運営者）やメッセージングサービス事業者（運営者）をサーバ１０のユーザとする。
本実施形態では、マネーローンサービス事業者（運営者）やメッセージングサービス事業者（運営者）をサーバ１０のユーザとする。
【0081】
なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。
【0082】
端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
【0083】
端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
【0084】
ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
【0085】
ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（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（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
【0086】
サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
【0087】
［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。
通信システム１に含まれる各装置のＨＷ構成について説明する。
【0088】
（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0089】
通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0090】
入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0091】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
【0092】
出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
【0093】
あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。
【0094】
表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
【0095】
音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。
【0096】
入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
【0097】
時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
【0098】
なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
【0099】
位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。
【0100】
位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。
【0101】
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
【0102】
慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
【0103】
ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
【0104】
制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。
【0105】
制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
【0106】
制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
【0107】
記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0108】
端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
【0109】
（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0110】
制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
【0111】
制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
【0112】
記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0113】
通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0114】
入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0115】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。
【0116】
出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
【0117】
あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。
【0118】
表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
【0119】
時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
【0120】
（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
【0121】
本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
【0122】
なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
【0123】
また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
【0124】
また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。
【0125】
記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
【0126】
サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
【0127】
また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
【0128】
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
【0129】
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
【0130】
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
【0131】
＜機能構成＞
（１）サーバの機能構成
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。
（１）サーバの機能構成
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。
【0132】
図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。
記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。
【0133】
アカウント登録データ１５３は、アプリケーション（本実施例では、マネーローンアプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。
【0134】
ユーザ名は、このアプリケーションを利用する端末２０のアカウントの名称であり、限定ではなく例として、端末２０のユーザがアプリケーションを利用する際に登録する名称が記憶される。
【0135】
アプリケーションＩＤは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
【0136】
その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。
【0137】
なお、その他登録情報に、貸付に際しての与信を判断するための情報として、限定ではなく例として、端末２０のユーザが登録可能な、以下の項目を含めるようにしてもよい。
・勤務先
・年収
・勤続年数
・家族構成
・資産状況
・住居形態
・勤務先
・年収
・勤続年数
・家族構成
・資産状況
・住居形態
【0138】
また、その他登録情報に、限定ではなく例として、端末２０のユーザ情報に基づいて算出される信用スコア（ソーシャルスコア）を含めるようにしてもよい。
【0139】
端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤとすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤとすることができる。
【0140】
なお、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。
【0141】
また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、１つのアプリケーションＩＤを識別（ログイン）対象として、複数の端末２０においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。
【0142】
また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。なお、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報に代えず、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。なお、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報に代えず、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
【0143】
なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
【0144】
アカウント管理データベース１５５は、アカウント登録データ１５３に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース１５５Ａのデータ構成例を図１－５に示す。
アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。
アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。
【0145】
各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、氏名と、貸付管理データとが記憶される。
【0146】
アプリケーションＩＤは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ１５３に登録されたアプリケーションＩＤが記憶される。
【0147】
氏名は、マネーローンサービスを利用する端末２０のユーザの氏名であり、限定ではなく例として、端末２０のユーザがマネーローンサービスを利用する際に登録する氏名が記憶される。ここでの氏名を、適宜「契約者氏名」と称する。
【0148】
貸付管理データは、限定ではなく例として、マネーローンサービス事業者がこのアプリケーションＩＤのアカウント所有者であるユーザに貸し付けるローン契約に関する情報を記憶させるためのデータである。
貸付管理データには、限定ではなく例として、貸付日と、貸付残高と、貸付金利と、約定返済額と、約定返済開始日と、遅延損害金利と、遅延損害金額と、その他貸付情報とが関連付けて記憶される。
約定返済開始日とは、初回の約定返済日とすることができる。「初回約定返済日」と称してもよい。
貸付管理データには、限定ではなく例として、貸付日と、貸付残高と、貸付金利と、約定返済額と、約定返済開始日と、遅延損害金利と、遅延損害金額と、その他貸付情報とが関連付けて記憶される。
約定返済開始日とは、初回の約定返済日とすることができる。「初回約定返済日」と称してもよい。
【0149】
貸付日（ローン契約日と言ってもよい。）と、貸付残高と、貸付金利と、約定返済額と、約定返済開始日と、遅延損害金利と、遅延損害金額とは、限定ではなく例として、ローンの貸付処理や貸し付けたローンの返済処理に伴い、サーバ１０の制御部１１により更新され記憶される情報としてよい。
【0150】
その他貸付情報には、限定ではなく例として、ローンの貸付処理に伴いサーバ１０の制御部１１により設定される、約定返済開始日以降の約定返済日（約定返済頻度）が記憶されるようにするようにしてもよい。なお、その他貸付情報に、貸し付けたローンの返済状況や、このアプリケーションＩＤのアカウントのソーシャルスコア（信用スコア）に関する情報等を含めるようにしてもよい。
【0151】
また、その他貸付情報に、限定ではなく例として、以下に示すものを含めるようにしてよい。
・マネーローンサービス事業者の商号、氏名、住所または電話番号
・送付者氏名
・弁済期日
・支払いを催告する金額
・残存貸付残高
・支払いを催告する金額の内訳
・マネーローンサービス事業者の商号、氏名、住所または電話番号
・送付者氏名
・弁済期日
・支払いを催告する金額
・残存貸付残高
・支払いを催告する金額の内訳
【0152】
（２）端末の機能構成
図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。
図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。
【0153】
図１－７は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
【0154】
＜表示画面＞
本実施例における表示画面例について説明する。
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
本実施例における表示画面例について説明する。
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
【0155】
また、以下説明する表示画面で用いる用語と、その後に説明する処理で用いる用語とで、用語が異なる場合がある（一部の用語が統一されていない場合がある）が、これは、ユーザの視点で表示画面について分かり易く説明するなどの目的であり便宜上のものに過ぎない。
これは、他の実施例や変形例についても同様である。
これは、他の実施例や変形例についても同様である。
【0156】
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。
【0157】
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
【0158】
以下では、ユーザによる操作として、限定ではなく例として、タップ（タップ操作）等を例示する。
タップ（タップ操作）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作とすることができる。
タップ（タップ操作）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作とすることができる。
【0159】
なお、表示画面例では、ローン契約における返済方法として、限定ではなく例として、元利定額方式に基づく算出例を例示するが、返済方法はこれに限定されない。限定ではなく例として、元金定額方式としてもよいし、残高スライド方式としてもよい。また、表示画面例内で図示される算出値はあくまで例示用の概算値であり、実際の値と異なる場合があり得る。
【0160】
図１－８は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。なお、以下では、端末２０が実行する処理を、限定ではなく例として、ユーザＡ．Ａの端末２０Ａが実行する処理として図示・説明する。
【0161】
本画面図では、限定ではなく例として、端末２０のユーザがマネーローンサービス事業者から「３０，０００円」を「年利１５％」で借り入れている場合に、ユーザが１回目の約定返済日に返済を行わないことに基づいて督促状が送付される例を示す。
なお、これはあくまでも一例であり、この例に限定されるものではない。
なお、これはあくまでも一例であり、この例に限定されるものではない。
【0162】
図１－８左側は、限定ではなく例として、マネーローンアプリケーションにおいて申し込みが完了された後に表示される、督促情報表示画面の一例である。
この画面では、画面最上部中央に、マネーローンアプリケーションの名称である「Ｍｏｎｅｙ Ｌｏａｎ Ａｐｐ」の文字が表示されるように構成されている。
また、その下には、督促情報を受信したことに基づいて、「［重要］お支払いのご案内」の文字が表示されている。
この画面では、画面最上部中央に、マネーローンアプリケーションの名称である「Ｍｏｎｅｙ Ｌｏａｎ Ａｐｐ」の文字が表示されるように構成されている。
また、その下には、督促情報を受信したことに基づいて、「［重要］お支払いのご案内」の文字が表示されている。
【0163】
その下には、督促情報の詳細な情報を表示するための督促情報表示領域ＲＲが構成されている。
督促情報表示領域ＲＲには、限定ではなく例として、契約者氏名に関する情報（＊＊＊＊様）と、返済が滞っていることを知らせる情報と、この督促の弁済期に関する情報（２０２３年２月１９日（７日後）まで）と、この督促において請求する金額に関する情報と（今回請求金額：Ｘ，ＸＸＸ円）、その請求する金額の内訳に関する情報（元金 Ａ，ＡＡＡ円，未収利息 ＢＢＢ円，遅延損害金 ＣＣＣ円）等が表示されている。
督促情報表示領域ＲＲには、限定ではなく例として、契約者氏名に関する情報（＊＊＊＊様）と、返済が滞っていることを知らせる情報と、この督促の弁済期に関する情報（２０２３年２月１９日（７日後）まで）と、この督促において請求する金額に関する情報と（今回請求金額：Ｘ，ＸＸＸ円）、その請求する金額の内訳に関する情報（元金 Ａ，ＡＡＡ円，未収利息 ＢＢＢ円，遅延損害金 ＣＣＣ円）等が表示されている。
【0164】
限定ではなく例として、ユーザによって画面の下方向を閲覧するようにスクロールされると、限定ではなく例として、図１－８中央の画面に表示が変わる。
この画面は、限定ではなく例として、督促情報の詳細な情報のうち図１－８左側の画面に表示されていた督促情報の詳細な情報の続きの情報が表示されている。
また、この画面では、限定ではなく例として、前述した図１－８左側の画面と同様である部分についての説明を省略する。
この画面は、限定ではなく例として、督促情報の詳細な情報のうち図１－８左側の画面に表示されていた督促情報の詳細な情報の続きの情報が表示されている。
また、この画面では、限定ではなく例として、前述した図１－８左側の画面と同様である部分についての説明を省略する。
【0165】
この例では、督促情報表示領域ＲＲには、限定ではなく例として、この督促の発信元であるマネーローンサービス事業者に関する情報（マネーローン株式会社、電話番号：ＴＴ－ＴＴＴＴ－ＴＴＴＴ等）と、この督促の支払いを行うための情報（「返済する」の文字を含む返済ボタンＨＢＴ等を含む情報）等が表示されている。
【0166】
限定ではなく例として、ユーザによって画面の下方向を閲覧するようにスクロールされると、限定ではなく例として、図１－８右側の画面に表示が変わる。
この画面は、限定ではなく例として、督促情報の詳細な情報のうち図１－８中央の画面に表示されていた督促情報の詳細な情報の続きの情報が表示されている。
また、この画面では、限定ではなく例として、前述した図１－８中央の画面と同様である部分についての説明を省略する。
この画面は、限定ではなく例として、督促情報の詳細な情報のうち図１－８中央の画面に表示されていた督促情報の詳細な情報の続きの情報が表示されている。
また、この画面では、限定ではなく例として、前述した図１－８中央の画面と同様である部分についての説明を省略する。
【0167】
この例では、督促情報表示領域ＲＲには、限定ではなく例として、貸付残高に関する情報（借入残高 ＺＺ，ＺＺＺ円）と、最終的な貸付日に関する情報（２０２３年１月１日）と、最終的な貸付残高に関する情報（最終借入後残高 ＺＺ，ＺＺＺ円）と、貸付日に関する情報（契約日 ２０２３年１月１日）と、貸付金利に関する情報（借入利率 １５％）と、遅延損害金利に関する情報（遅延損害金率 ２０％）と、この督促の発信元であるマネーローンサービス事業者に関する情報（発信元 マネーローン株式会社、住所 〒ＰＰＰ－ＰＰＰＰ 東京都港区・・・、担当者 ○○○○等）等が表示されている。
【0168】
そして、限定ではなく例として、図１－８中央の画面や図１－８右側の画面における返済ボタンＨＢＴがユーザによってタップされると、限定ではなく例として、返済を実際に行うための返済画面が表示されるようにしてよい（不図示）。
この返済画面では、限定ではなく例として、返済方法（電子マネー決済、銀行振込など）の設定や、設定した返済方法による実際の支払いなどが行われるようにしてよい。
この返済画面では、限定ではなく例として、返済方法（電子マネー決済、銀行振込など）の設定や、設定した返済方法による実際の支払いなどが行われるようにしてよい。
【0169】
＜処理＞
図１－９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、ユーザＡ．Ａの端末２０Ａの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
図１－９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、ユーザＡ．Ａの端末２０Ａの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
【0170】
なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。
【0171】
最初に、端末２０Ａの制御部２１は、限定ではなく例として、端末２０Ａの入出力部２３に対する入力（限定ではなく例として、ユーザ入力（ユーザによる操作入力や音入力等）。以下同様としてよい。）に基づいて、マネーローンサービス事業者からローンの借り入れを行うことを要求するための借入要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１１０）。
ここで、借入要求情報には、限定ではなく例として、借入希望額、返済希望期間、希望する振込先の金融機関口座、希望約定返済額等の情報のいずれか１つ以上の任意の組み合わせを含めるようにしてもよい。ユーザＡ．Ａ（または端末２０Ａ）を識別可能な情報（アプリケーションＩＤ等の情報）を含めてもよい。
ここで、借入要求情報には、限定ではなく例として、借入希望額、返済希望期間、希望する振込先の金融機関口座、希望約定返済額等の情報のいずれか１つ以上の任意の組み合わせを含めるようにしてもよい。ユーザＡ．Ａ（または端末２０Ａ）を識別可能な情報（アプリケーションＩＤ等の情報）を含めてもよい。
【0172】
通信Ｉ／Ｆ１４によって端末２０Ａから借入要求情報を受信すると、サーバ１０の制御部１１は、貸付条件算出処理を実行する（Ｓ１１０）。貸付条件算出処理において、サーバ１０の制御部１１は、限定ではなく例として、受信した借入要求情報と、ユーザ情報（限定ではなく例として、アカウント登録データ１５３のその他登録情報）とに基づいて、ユーザに貸付可能な貸し付け条件（限定ではなく例として、貸付金額と、貸付金利と、約定返済開始日と、約定返済額）とを算出する。
【0173】
なお、一般的に、貸し付け条件の算出方法は秘匿事項とされるため、具体的な算出式については記載していない。
ただし、貸し付け条件の算出方法が公開されてもよく、公開されるのであれば、その算出方法に基づいて貸し付け条件を算出するようにしてもよい。
ただし、貸し付け条件の算出方法が公開されてもよく、公開されるのであれば、その算出方法に基づいて貸し付け条件を算出するようにしてもよい。
【0174】
すると、サーバ１０の制御部１１は、算出された貸し付け条件を含む貸付条件情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２０）。
【0175】
通信Ｉ／Ｆ２２によってサーバ１０から貸付条件情報を受信すると、端末２０Ａの制御部２１は、受信した貸付条件情報を表示部２４に表示させる（Ａ１２０）。
限定ではなく例として、表示された貸付条件情報に対するユーザ入力に基づいて、端末２０Ａのユーザが貸付条件に同意すると判定した場合、端末２０Ａの制御部２１は、貸付条件承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１３０）。
限定ではなく例として、表示された貸付条件情報に対するユーザ入力に基づいて、端末２０Ａのユーザが貸付条件に同意すると判定した場合、端末２０Ａの制御部２１は、貸付条件承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１３０）。
【0176】
通信Ｉ／Ｆ１４によって端末２０Ａから貸付条件承認情報を受信したと判定する場合、サーバ１０の制御部１１は、貸付処理を実行する（Ｓ１３０）。
貸付処理において、サーバ１０の制御部１１は、限定ではなく例として、マネーローンサービス事業者の金融金融口座から、借入要求情報で指定される金融機関口座（金融機関名・支店名・振込先口座番号・受取口座名義）に対して、貸付条件算出処理で求められた貸付金額の振込または振替を行うための振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信する。
金融機関において振込処理が完了すると、サーバ１０の制御部１１は、金融機関サーバから振込完了情報を受信する。すると、サーバ１０の制御部１１は、貸付金額に基づいて、アカウント管理データベース１５５Ａの貸付管理データの貸付残高を加算する。また、サーバ１０の制御部１１は、限定ではなく例として、算出された貸付条件情報に基づいて、アカウント管理データベース１５５Ａの貸付管理データにおける各要素を更新する。
貸付処理において、サーバ１０の制御部１１は、限定ではなく例として、マネーローンサービス事業者の金融金融口座から、借入要求情報で指定される金融機関口座（金融機関名・支店名・振込先口座番号・受取口座名義）に対して、貸付条件算出処理で求められた貸付金額の振込または振替を行うための振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信する。
金融機関において振込処理が完了すると、サーバ１０の制御部１１は、金融機関サーバから振込完了情報を受信する。すると、サーバ１０の制御部１１は、貸付金額に基づいて、アカウント管理データベース１５５Ａの貸付管理データの貸付残高を加算する。また、サーバ１０の制御部１１は、限定ではなく例として、算出された貸付条件情報に基づいて、アカウント管理データベース１５５Ａの貸付管理データにおける各要素を更新する。
【0177】
なお、貸付処理において入金先とする金融機関口座は、限定ではなく例として、マネーローンサービス事業者と提携する電子マネーサービスの口座（アカウント）としてもよい。
【0178】
その後、サーバ１０の制御部１１は、貸付結果情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１４０）。ここで、貸付結果情報には、限定ではなく例として、以下の任意の情報の組み合わせを含むようにしてもよい。
・貸付処理における貸付金額（ユーザＡ．Ａから見ると借入金額）
・貸付処理後の貸付残高（ユーザＡ．Ａから見ると借入残高）
・約定返済開始日
・約定返済開始日以降の約定返済日（または返済頻度）
・約定返済日ごとの約定返済額
・貸付処理における貸付金額（ユーザＡ．Ａから見ると借入金額）
・貸付処理後の貸付残高（ユーザＡ．Ａから見ると借入残高）
・約定返済開始日
・約定返済開始日以降の約定返済日（または返済頻度）
・約定返済日ごとの約定返済額
【0179】
通信Ｉ／Ｆ２２によってサーバ１０から貸付結果情報を受信すると、端末２０Ａの制御部２１は、受信した貸付結果情報を表示部２４に表示させる（Ａ１４０）。
【0180】
以下では、限定ではなく例として、Ａ１１０～Ａ１４０およびＳ１１０～Ｓ１４０のステップをまとめて、借入処理（Ａ１００・Ｓ１００）と表記することがある。
【0181】
すると、サーバ１０の制御部１１は、限定ではなく例として、督促情報を端末２０に送信するための条件である督促情報送信条件が成立するか否かを判定する（Ｓ１５０）。
【0182】
督促情報送信条件には、限定ではなく例として、以下のような条件を含めるようにしてよい。
“Ｊ０１”：返済されていない状態で約定返済日から所定日数が経過したこと
“Ｊ０１”：返済されていない状態で約定返済日から所定日数が経過したこと
【0183】
ただし、この例では、約定返済日よりも前にユーザは返済（繰り上げ返済）ができるものとしてよいものとする。
また、「返済されていない状態」とは、「約定返済額の全額が返済されていないこと」としてよいものとする。
また、所定日数は、マネーローンサービス事業者による入力情報に基づいてサーバ１０で設定されるようにしてもよいし（マネーローンサービス事業者による設定と捉えてもよい。）し、サーバ１０側で自動設定するようにしてもよい。
また、「返済されていない状態」とは、「約定返済額の全額が返済されていないこと」としてよいものとする。
また、所定日数は、マネーローンサービス事業者による入力情報に基づいてサーバ１０で設定されるようにしてもよいし（マネーローンサービス事業者による設定と捉えてもよい。）し、サーバ１０側で自動設定するようにしてもよい。
【0184】
限定ではなく例として、督促情報送信条件として“Ｊ０１”が設定され、所定日数として「１０日」が設定されている場合、返済されていない状態で約定返済日から１１日目の０時００分に、初めて督促情報送信条件が成立することとなり、１回目の督促情報が端末２０に送信されるようにしてよい。
【0185】
なお、この例において、督促情報を再送する条件（以下、「督促情報再送条件」と称する。）が設定されるようにしてもよい。これは、限定ではなく例として、ユーザに督促をリマインドする意味を含め再督促を行う条件（再督促条件）と捉えてもよい。
具体的には、限定ではなく例として、上記の例において、返済されていない状態で約定返済日から１２日目の０時００分に、督促情報再送条件が成立し、２回目の督促情報が端末２０に送信されるようにしてよい。
以下、返済されない状態か続く場合には同様の制御が行われ、繰り返し督促情報が端末２０に送信されるようにしてよい。
つまり、この例では、限定ではなく例として、１日が経過するごとに、督促情報が繰り返し端末２０に送信されるようにしてもよい。
なお、これはあくまで一例に過ぎず、数時間ごとに督促情報が繰り返し送信されるようにしてもよい。また、変則的なタイミングで督促情報が送信されるようにしてもよい。
具体的には、限定ではなく例として、上記の例において、返済されていない状態で約定返済日から１２日目の０時００分に、督促情報再送条件が成立し、２回目の督促情報が端末２０に送信されるようにしてよい。
以下、返済されない状態か続く場合には同様の制御が行われ、繰り返し督促情報が端末２０に送信されるようにしてよい。
つまり、この例では、限定ではなく例として、１日が経過するごとに、督促情報が繰り返し端末２０に送信されるようにしてもよい。
なお、これはあくまで一例に過ぎず、数時間ごとに督促情報が繰り返し送信されるようにしてもよい。また、変則的なタイミングで督促情報が送信されるようにしてもよい。
【0186】
また、この場合、１回目（初回）と２回目以降とで、同じ督促情報が送信されるようにしてもよいし、異なる督促情報が送信されるようにしてもよい。
また、２回目には、１回目とは異なる督促情報が送信されるが、３回目以降は、２回目と同じ督促情報が送信されるようにしてもよい。
また、２回目には、１回目とは異なる督促情報が送信されるが、３回目以降は、２回目と同じ督促情報が送信されるようにしてもよい。
【0187】
督促情報送信条件が成立しないと判定する場合（Ｓ１５０：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、処理を終了させる。
【0188】
督促情報送信条件が成立すると判定する場合（Ｓ１５０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、督促情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１６０）。
この督促情報には、限定ではなく例として、以下の項目の情報を含めるようにしてよい。
・賃金業を営む者の商号、名称または氏名および住所ならびに電話番号
・当該書面または電磁的記録を送付する者の氏名
・契約年月日
・貸付けの金額
・貸付けの利率
・支払いの催告に係る債権の弁済期
・支払いを催告する金額
・支払いの催告時における当該催告に係る残存債務の額
・支払いを催告する金額の内訳（元金、利息および債務不履行による賠償額（遅延損害金率を含む。）の別をいう）
この督促情報には、限定ではなく例として、以下の項目の情報を含めるようにしてよい。
・賃金業を営む者の商号、名称または氏名および住所ならびに電話番号
・当該書面または電磁的記録を送付する者の氏名
・契約年月日
・貸付けの金額
・貸付けの利率
・支払いの催告に係る債権の弁済期
・支払いを催告する金額
・支払いの催告時における当該催告に係る残存債務の額
・支払いを催告する金額の内訳（元金、利息および債務不履行による賠償額（遅延損害金率を含む。）の別をいう）
【0189】
通信Ｉ／Ｆ２２によってサーバ１０から督促情報を受信すると、端末２０Ａの制御部２１は、受信した督促情報を表示部２４に表示させ（Ａ１５０）、処理を終了させる。
【0190】
なお、前述したように、サーバ１０は、督促情報（督促状）を端末２０に送信する他にも、限定ではなく例として、延滞通知書に相当する延滞通知情報や、催告書に相当する催告情報を端末２０に送信するようにしてもよい。また、この場合、最初に延滞通知情報を送信し、それから一定期間が経過した場合は督促情報を送信し、それからさらに一定期間が経過した場合は催告情報を送信するようにするなどしてもよい。
【0191】
本発明の１つの思想として、ユーザの返済が滞っている場合に、サーバ等の情報処理装置が、そのことをユーザに知らせる情報やユーザに返済を促す情報等の情報をユーザの端末２０に送信（デジタル形式で送付）することがあり、限定ではなく例としてサーバ１０は、貸し付けた金額の返済期限が過ぎている場合、限定ではなく例として、少なくとも、貸付金額の情報や貸付利率の情報を、端末２０に送信するするようにしてよい。そして、これらの情報の他、上記に示した各種の情報を、これらの情報に付加的に送信するようにしてもよい。
また、これらの情報は、限定ではなく例として、前述した延滞通知書、督促状、催告書等のいずれかの書面として（これらの情報を書面に含めて）送信するようにしてよい。
以下同様としてよい。
また、これらの情報は、限定ではなく例として、前述した延滞通知書、督促状、催告書等のいずれかの書面として（これらの情報を書面に含めて）送信するようにしてよい。
以下同様としてよい。
【0192】
また、各々の回の返済について、返済期限が過ぎている場合、限定ではなく例として、１回目に延滞通知書を送信し、２回目に督促状を送信するなどしてもよい。この場合、上記“Ｊ０１”の条件において、限定ではなく例として、延滞通知書を送信する条件としての所定日数として「３日」を設定し、督促状を送信する条件としての所定日数として「１０日」を設定するなどしてもよい。
なお、所定日数は、マネーローンサービス事業者側で任意に設定可能としてもよい。また、延滞通知書は送信しないようにしてもよい。
以下同様としてよい。
なお、所定日数は、マネーローンサービス事業者側で任意に設定可能としてもよい。また、延滞通知書は送信しないようにしてもよい。
以下同様としてよい。
【0193】
また、法律や法令等によって、債務者等に対し、支払いを行うように求める書面に含めなければならない情報が定められている場合は、その定めるところに基づき、送信する情報を決定すればよい。
そのような定めがない国等においては、送信する情報を自由に決定してもよい。また、そのような定めがあったとしても、法律や法令等が改正され、書面に含めなければならない情報が変更された場合は、その定めるところに基づき、送信する情報を決定すればよい。
以下同様としてよい。
そのような定めがない国等においては、送信する情報を自由に決定してもよい。また、そのような定めがあったとしても、法律や法令等が改正され、書面に含めなければならない情報が変更された場合は、その定めるところに基づき、送信する情報を決定すればよい。
以下同様としてよい。
【0194】
＜第１実施例の効果＞
本実施例は、サーバ１０（限定ではなく、ユーザの端末と通信するサーバの一例）が、貸付金額の情報（限定ではなく、ユーザに貸し付けた金額の情報の一例）を記憶部１５に記憶する制御を制御部１１によって行う。
サーバ１０は、返済期限が過ぎている場合、貸付金額の情報（限定ではなく、貸し付けた金額の情報の一例）と、貸付利率の情報（限定ではなく、貸し付けた利率の情報の一例）とを通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とが端末に送信されるようにすることによって、限定ではなく例として、これらをユーザに知らせることができる。
本実施例は、サーバ１０（限定ではなく、ユーザの端末と通信するサーバの一例）が、貸付金額の情報（限定ではなく、ユーザに貸し付けた金額の情報の一例）を記憶部１５に記憶する制御を制御部１１によって行う。
サーバ１０は、返済期限が過ぎている場合、貸付金額の情報（限定ではなく、貸し付けた金額の情報の一例）と、貸付利率の情報（限定ではなく、貸し付けた利率の情報の一例）とを通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とが端末に送信されるようにすることによって、限定ではなく例として、これらをユーザに知らせることができる。
【0195】
また、この場合、サーバ１０は、返済期限が過ぎている場合、遅延損害金率の情報を端末２０に通信Ｉ／Ｆ１４によって送信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、遅延損害金率の情報が端末に送信されるようにすることによって、限定ではなく例として、遅延損害金率をユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、遅延損害金率の情報が端末に送信されるようにすることによって、限定ではなく例として、遅延損害金率をユーザに知らせることができる。
【0196】
また、この場合、サーバ１０は、返済期限が過ぎている場合、最終借入日に関する契約日の情報を端末２０に通信Ｉ／Ｆ１４によって送信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、最終借入日に関する契約日の情報が端末に送信されるようにすることによって、限定ではなく例として、最終借入日に関する契約日をユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、最終借入日に関する契約日の情報が端末に送信されるようにすることによって、限定ではなく例として、最終借入日に関する契約日をユーザに知らせることができる。
【0197】
また、本実施例は、サーバ１０は、返済期限が過ぎている場合、上述した貸付金額の情報（限定ではなく、貸し付けた金額の情報の一例）と、上述した貸付利率の情報（限定ではなく、貸し付けた利率の情報の一例）とを含む、督促状を端末２０に通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とを含む督促状が端末に送信されるようにすることによって、限定ではなく例として、督促状の送信による、返済の督促を実現することができる。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、サーバによって、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とを含む督促状が端末に送信されるようにすることによって、限定ではなく例として、督促状の送信による、返済の督促を実現することができる。
【0198】
本実施例は、端末２０が、返済期限が過ぎている場合、貸付金額の情報（限定ではなく、貸し付けた金額の情報の一例）と、貸付利率の情報（限定ではなく、貸し付けた利率の情報の一例）とを通信Ｉ／Ｆ２２によってサーバ１０から受信する構成を示している。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、端末が、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とをサーバから受信するようにすることによって、限定ではなく例として、これらをユーザに知らせることができる。
なお、上記のように、端末２０が、遅延損額金率の情報、最終借入日に関する契約日の情報等の情報をサーバ１０から受信するようにしてもよい。また、上記のように、督促状をサーバ１０から受信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、貸し付けた金額の返済期限が過ぎている場合、端末が、ユーザに貸し付けた金額の情報と、貸し付けた利率の情報とをサーバから受信するようにすることによって、限定ではなく例として、これらをユーザに知らせることができる。
なお、上記のように、端末２０が、遅延損額金率の情報、最終借入日に関する契約日の情報等の情報をサーバ１０から受信するようにしてもよい。また、上記のように、督促状をサーバ１０から受信するようにしてもよい。
【0199】
また、端末２０が、上記の各種の情報を表示部２４に表示するようにしてもよい。
この場合、端末２０は、ユーザによる表示部２４に対するスクロール操作等に基づいて、スクロール制御を行って情報の表示を更新するようにしてもよい。
この場合、端末２０は、ユーザによる表示部２４に対するスクロール操作等に基づいて、スクロール制御を行って情報の表示を更新するようにしてもよい。
【0200】
＜第１変形例（１）＞
上記の実施例では、督促情報を受信した端末２０の表示部２４において督促情報が縦長に表示され、ユーザが縦方向にスクロールすることによって、表示部２４に一度に表示可能な最大のサイズ（本例では、督促情報表示領域ＲＲのサイズ）に表示できない部分の督促情報を閲覧することができる表示方式の例を示したが、これに限定されない。限定ではなく例として、督促情報の表示方式として前述した表示方式とは異なる表示方式で表示されるようにしてもよい。
上記の実施例では、督促情報を受信した端末２０の表示部２４において督促情報が縦長に表示され、ユーザが縦方向にスクロールすることによって、表示部２４に一度に表示可能な最大のサイズ（本例では、督促情報表示領域ＲＲのサイズ）に表示できない部分の督促情報を閲覧することができる表示方式の例を示したが、これに限定されない。限定ではなく例として、督促情報の表示方式として前述した表示方式とは異なる表示方式で表示されるようにしてもよい。
【0201】
本変形例では、督促情報の表示方式として、限定ではなく例として、督促情報を受信した端末２０の表示部２４において、督促情報のうち表示部２４に一度に表示可能な最大のサイズ（本例では、督促情報表示領域ＲＲのサイズ）で分割された督促情報（以下、適宜「分割督促情報」と称する。）が表示され、ユーザがその分割督促情報を横方向にスクロール（スライド）することによって、他の分割督促情報を閲覧することができる表示方式が採用されるようにしてよい。すなわち、分割督促情報が横方向に配置され、ユーザが横方向にスクロール（スライド）することによって、分割された督促情報のうち任意の督促情報が表示部２４に表示される。以下では、このような表示方式を適宜「カルーセル方式」等と称する。
【0202】
このカルーセル方式では、限定ではなく例として、第１の分割督促情報が表示部２４に表示されている場合に、第２の分割督促情報を表示するために第１の分割督促情報がユーザによって横方向にスライドされると、限定ではなく例として、第１の分割督促情報の一部が表示部２４に表示されながら、第２の分割督促情報の一部が表示部２４に表示される（フレームアウトしながらフレームインする）ようにしてよい。
【0203】
＜表示画面＞
図１－１０は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
本画面図では、限定ではなく例として、第１実施例と同様に、端末２０のユーザがマネーローンサービス事業者から「３０，０００円」を「年利１５％」で借り入れている場合に、ユーザが１回目の約定返済日に返済を行わないことに基づいて督促状が送付される例を示す。
なお、これはあくまでも一例であり、この例に限定されるものではない。
図１－１０は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
本画面図では、限定ではなく例として、第１実施例と同様に、端末２０のユーザがマネーローンサービス事業者から「３０，０００円」を「年利１５％」で借り入れている場合に、ユーザが１回目の約定返済日に返済を行わないことに基づいて督促状が送付される例を示す。
なお、これはあくまでも一例であり、この例に限定されるものではない。
【0204】
図１－１０左側の画面は、限定ではなく例として、前述した図１－８左側の画面と同様である部分についての説明を省略する。
この例では、画面最上部中央の下には、督促情報を受信したことと、カルーセル方式で表示されるために３つに分割された督促情報のうち１つ目の分割督促情報であることとに基づいて、「［重要］お支払いのご案内（１／３）」の文字が表示されている。
また、画面最下部中央には、この督促の支払いを行うための情報（「返済する」の文字を含むボタン）が表示されている。
この例では、画面最上部中央の下には、督促情報を受信したことと、カルーセル方式で表示されるために３つに分割された督促情報のうち１つ目の分割督促情報であることとに基づいて、「［重要］お支払いのご案内（１／３）」の文字が表示されている。
また、画面最下部中央には、この督促の支払いを行うための情報（「返済する」の文字を含むボタン）が表示されている。
【0205】
限定ではなく例として、表示部２４の右方向を閲覧するために督促情報表示領域ＲＲがユーザによって左方向にスクロールされると、限定ではなく例として、図１－１０中央の画面に表示が変わる。
この画面は、限定ではなく例として、３つに分割された督促情報のうち２つ目の分割督促情報が表示されている。
この画面は、限定ではなく例として、前述した図１－８中央の画面と同様である部分についての説明を省略する。
この画面は、限定ではなく例として、３つに分割された督促情報のうち２つ目の分割督促情報が表示されている。
この画面は、限定ではなく例として、前述した図１－８中央の画面と同様である部分についての説明を省略する。
【0206】
この例では、画面最上部中央の下には、督促情報を受信したことと、カルーセル方式で表示されるために３つに分割された督促情報のうち２つ目の分割督促情報であることとに基づいて、「［重要］お支払いのご案内（２／３）」の文字が表示されている。
また、画面最下部中央には、この督促の支払いを行うための情報（「返済する」の文字を含むボタン）が表示されている。
また、画面最下部中央には、この督促の支払いを行うための情報（「返済する」の文字を含むボタン）が表示されている。
【0207】
限定ではなく例として、表示部２４の右方向を閲覧するために督促情報表示領域ＲＲがユーザによって左方向にスクロールされると、限定ではなく例として、図１－１０右側の画面に表示が変わる。
この画面は、限定ではなく例として、３つに分割された督促情報のうち３つ目の分割督促情報が表示されている。
この画面は、限定ではなく例として、前述した図１－８右側の画面と同様である部分についての説明を省略する。
この画面は、限定ではなく例として、３つに分割された督促情報のうち３つ目の分割督促情報が表示されている。
この画面は、限定ではなく例として、前述した図１－８右側の画面と同様である部分についての説明を省略する。
【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】
１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
１０ サーバ
２０ 端末
３０ ネットワーク
【図1-1】
【図1-2】
【図1-3】
【図1-4】
【図1-5】
【図1-6】
【図1-7】
【図1-8】
【図1-9】
【図1-10】
【図1-11】
【図2-1】
【図2-2】
【図2-3】
【図2-4】
【図2-5】
【図2-6】
【図2-7】
【図2-8】
【図2-9】
【図2-10】
【図3-1】
【図3-2】
【図4-1】
【図5-1】
【図5-2】
【図6-1】