JP7149442B1

JP7149442B1 - サーバ、情報処理方法、プログラム、システム

Info

Publication number: JP7149442B1
Application number: JP2022100565A
Authority: JP
Inventors: 巧山岡
Original assignee: Line Corp
Current assignee: Line Corp
Priority date: 2021-12-07
Filing date: 2022-06-22
Publication date: 2022-10-06
Anticipated expiration: 2041-12-07
Also published as: JP2023084649A

Abstract

【課題】借り換えに関する利便性等を向上させる。【解決手段】ユーザの端末と通信するサーバは、ユーザが第１企業から借りた金銭の情報を含む第１情報を端末から受信する通信部と、第１情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得する制御部とを備え、制御部は、第１情報に基づき、第１企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得する制御を行う。【選択図】図１－１

Description

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

消費者金融等の金融機関で貸し出した借金の返済期限を通知する技術がある（例えば、特許文献１）。

特開２００８－３０５０３９号公報

本発明の第１の態様によると、ユーザの端末と通信するサーバは、ユーザが第１企業から借りた金銭の情報を含む第１情報を端末から受信する通信部と、第１情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得する制御部とを備え、制御部は、第１情報に基づき、第１企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得する制御を行う。
本発明の第２の態様によると、ユーザの端末と通信するサーバによって実行されるプログラムは、ユーザが第１企業から借りた金銭の情報を含む第１情報をサーバの通信部によって端末から受信することと、第１情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報をサーバの制御部によって取得することと、第１情報に基づき、第１企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得する制御を制御部によって行うこととがサーバによって実行される。
本発明の第３の態様によると、ユーザの端末と通信するサーバの情報処理方法は、ユーザが第１企業から借りた金銭の情報を含む第１情報をサーバの通信部によって端末から受信することと、第１情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報をサーバの制御部によって取得することと、第１情報に基づき、第１企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得する制御を制御部によって行うこととを含む。

実施形態に係る通信システムのシステム構成の一例を示す図。第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。第１実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。第１実施例に係るアカウント登録データの一例を示す図。第１実施例に係るアカウント管理データベースの一例を示す図。第１実施例に係る端末の制御部によって実現される機能の一例を示す図。第１実施例に係る端末の記憶部に記憶される情報等の一例を示す図。第１実施例に係る端末の表示部に表示される画面の一例を示す図。第１実施例に係る端末の表示部に表示される画面の一例を示す図。第１実施例に係る端末の表示部に表示される画面の一例を示す図。第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２実施例に係る端末の表示部に表示される画面の一例を示す図。第２実施例に係る端末の表示部に表示される画面の一例を示す図。第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３実施例に係るアカウント管理データベースの一例を示す図。第３実施例に係る端末の表示部に表示される画面の一例を示す図。第３実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第５実施例に係る端末の表示部に表示される画面の一例を示す図。第６実施例に係る端末の表示部に表示される画面の一例を示す図。第６実施例に係る端末の表示部に表示される画面の一例を示す図。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、トークルームには、一対一のユーザのトークルーム（以下、「一対一トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、公式アカウントのユーザとのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、２名のユーザや２つのアカウントで構成されるグループのトークルームとして管理してもよい。

公式アカウントは、一般のユーザではなく事業者のアカウント（事業者のユーザのアカウント）であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ（メッセージ）の送受信を行うことができるようにすることができる。

本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、１または複数のコンテンツであってもよい。

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

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

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

また、以下の実施例では、ユーザが金融機関からお金を借りるためのサービスの一例として、マネーローンサービス（Loan Service）を例示する。また、マネーローンサービスを実現するためのアプリケーションを「マネーローンアプリケーション」と称する。
マネーローンアプリケーションでは、限定ではなく例として、ユーザが他社で借入中の借金をマネーローンサービスの事業者が肩代わりし、マネーローンサービスの事業者に対する借金として一本化しまとめて借り換える「ローン借り換え」を行うことができる。

また、以下の実施例では、ユーザが支払いを行うためのサービス（以下、「支払いサービス」と称する。）を例示する。また、支払いサービスを実現するためのアプリケーションを「支払いアプリケーション」と称する。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い（決済）を行うようにことができるようにすることができる。

電子貨幣を用いた支払い方法としては、限定ではなく例として、「利用者提示型」のコード支払いと、「店舗提示型」のコード支払いとのうちのいずれかの方法を適用することができる。

「利用者提示型」のコード支払いは、限定ではなく例として、端末２０の表示部２４に表示されたコード情報をユーザが店舗の店員に提示し、店舗のコードリーダで読み取ってもらうことで支払いを行う方法とすることができる。
「店舗提示型」のコード支払いは、限定ではなく例として、店舗側が提示するコード情報をユーザが自己の端末２０のコードリーダに読み取らせて支払いを行う方法とすることができる。

本明細書において、「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末、または端末のユーザが所有する電子的な貨幣を意味するものとしてよいものとする。
なお、「電子貨幣」は、「デジタル通貨（デジタル貨幣）」と考えてもよいものとする。

１つの考え方として、電子貨幣は、「電子マネー」、「仮想通貨（暗号資産）」、「中央銀行発行デジタル通貨（ＣＢＤＢ）」などを含む概念と考えてもよいものとする。

また、電子貨幣は、「法定通貨」でもよいし、「企業通貨」でもよいものとする。電子貨幣の実装方法としては、「中央集権型金融（ＣｅＦｉ）」としてもよいし、「分散型金融（ＤｅＦｉ）」としてもよいものとする。

以下説明する実施例では、限定ではなく例として、電子貨幣の一例として、中央集権型金融における企業通貨としての電子マネーについて例示する。

なお、企業通貨には、クーポンなどの物的貨幣を含めてもよいものとする。

マネーローンサービス（マネーローンアプリケーション）を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ１）メッセージングアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ａ２）支払いアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
（Ｂ１）マネーローンサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ２）マネーローンサービスの機能と支払いサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｂ３）マネーローンサービスの機能と支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ１）マネーローンアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｃ２）マネーローンアプリケーションとは別のアプリケーションとして支払いアプリケーションを構成する形態
（Ｃ３）マネーローンアプリケーションとは別のアプリケーションとして支払いサービスとメッセージングサービスとの統合的なアプリケーションを構成する形態
（Ｄ）マネーローンアプリケーションを単体のアプリケーションとして構成する形態

（Ａ１）や（Ｂ１）、（Ｂ３）の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。

マネーローンサービス事業者を、支払いサービス事業者と同じ事業者とする場合についても同様である。

（Ｃ１）～（Ｃ３）の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、（Ｃ１）～（Ｃ３）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。
支払いアプリケーションについても同様である。

なお、上記とは異なり、マネーローンアプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。マネーローンアプリケーションの一機能として支払いサービスの機能を持たせるようにしてもよい。

＜実施例＞
以下、実施例について説明する。
以下説明する実施例では、マネーローンサービスにおいて、限定ではなくサーバが、金利（金利を含む金利情報）を２回取得（算出を含む。）することによって、端末のユーザに適切な金利を提示することを可能にする。

金利（金利を含む金利情報）を２回取得するのは、一つの観点からは、端末のユーザの申告に基づいて、大枠となる１回目の金利を取得し、その後、１回目の金利に対する端末のユーザの同意に基づいて、精査された２回目の金利を取得することで、端末のユーザが乗り換えローンの契約を迅速に締結できるようにすることがある。また、別の観点からは、詳細は第４実施例で説明するが、１回目の金利の取得後、乗り換えローンの一部の処理に失敗する可能性があり、この場合、法令上の問題を回避するための２回目の金利の取得が必要となる場合がある。

＜第１実施例＞
第１実施例は、限定ではなく例として、一の端末２０（以下、適宜「端末」と称する。）のユーザが、サーバ１０を運用するマネーローンサービス事業者以外の他の事業者からのローン（借金）をマネーローンサービス事業者の提供するローンに借り換える実施例である。
第１実施例では、限定ではなく例として、乗り換えを行う他社からのローン契約を一の契約とする。

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

以下では、ローン利用者（限定ではなく例として、端末２０のユーザ）から見て、借り換え先（乗り換え先）となるマネーローンサービス事業者（サーバ１０を運用するマネーローンサービス事業者）を「貸付先」と呼称する。また、ローン利用者から見て、借り換え元となる他社事業者を「借入先」と呼称する。貸付先は、サーバ１０の事業者と表現することもできる。

ここで、貸付先と借入先とは、限定ではなく例として、それぞれ企業とすることができる。企業は、貸金業法において規定される貸金業者とすることができる。企業は、団体であってもよいし、個人であってもよい。また、企業は、法人であってもよいし、そうでなくてもよい。

また、以下では、限定ではなく例として、
・借入先からのローン契約：「借入ローン契約」
・借入ローン契約において端末２０のユーザが借入を行った残高：「借入残高」
・借入を行った場合の金利（限定ではなく例として、実質年率）：「借入金利」
・借入に対する月々の約定返済額：「借入返済額」
とそれぞれ称する。借入ローン契約に関する情報を、以下では「借入先情報」と称する。

また、以下では、限定ではなく例として、
・借入ローン契約において借金の返済を行うための振込先となる金融機関口座に関する情報：「借入ローン振込先情報」
と称する。借入ローン振込先情報には、限定ではなく例として、金融機関名と、支店名と、振込先口座番号と、受取口座名義とを含めることができる。なお、借入ローン入金情報に、口座科目（限定ではなく例として、「普通預金口座」）や金融機関コード、振込依頼人名義等を含めるようにしてもよい。

また、以下では、限定ではなく例として、
・貸付先において結ぶローン契約：「貸付ローン契約」
・貸付ローン契約において端末２０のユーザが借入を行った残高：「貸付残高」
・端末２０のユーザが借入を行った場合の金利（限定ではなく例として、実質年率）：「貸付金利」
・借入に対して端末２０のユーザが月々返済する約定返済額：「貸付返済額」
とそれぞれ称する。

また、以下では、限定ではなく例として、
・貸付ローン契約において借金の返済を行うための振込先となる金融機関口座に関する情報：「貸付ローン振込先情報」
と呼称する。貸付ローン振込先情報は、限定ではなく例として、借入ローン振込先情報と同様の情報を含めるように構成することができる。

なお、マネーローンサービス事業者が支払いサービス事業者と提携している、またはマネーローンサービス事業者が支払いサービス事業者を兼ねる場合、限定ではなく例として、貸付ローン振込先情報は、ローン返済用に設定された電子マネー口座に関する情報を含めるように構成してもよい。借入ローン振込先情報についても同様である。

なお、貸付先または借入先の少なくとも一方に、行政機関を含めるようにしてもよいし、そうしなくてもよい。また、貸付先または借入先の少なくとも一方に、企業以外の任意団体を含めるようにしてもよいし、そうしなくてもよい。

また、以下では、マネーローンアプリケーションの名称を、適宜「ＭｏｎｅｙＬｏａｎＡｐｐ」と称して図示・説明する。

＜システム構成＞
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。

サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、マネーローンサービス、メッセージングサービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、マネーローンサーバ、メッセージングサーバ等のように表現することもできる。
本実施形態では、マネーローンサービス事業者（運営者）やメッセージングサービス事業者（運営者）をサーバ１０のユーザとする。

なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

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

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

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

また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。

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

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

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

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

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

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

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

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

アカウント登録データ１５３は、アプリケーション（本実施例では、マネーローンアプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。

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

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

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

なお、その他登録情報に、貸付に際しての与信を判断するための情報として、限定ではなく例として、端末２０のユーザが登録可能な、以下の項目を含めるようにしてもよい。
・勤務先
・年収
・勤続年数
・家族構成
・資産状況
・住居形態

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤとすることができる。

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

また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、１つのアプリケーションＩＤを識別（ログイン）対象として、複数の端末２０においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。

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

なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。

アカウント管理データベース１５５は、アカウント登録データ１５３に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース１５５Ａのデータ構成例を図１－５に示す。
アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、貸付管理データと、借入登録データとが記憶される。

アプリケーションＩＤは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ１５３に登録されたアプリケーションＩＤが記憶される。

貸付管理データは、限定ではなく例として、マネーローンサービス事業者がこのアプリケーションＩＤのアカウント所有者であるユーザに貸し付ける貸付ローン契約に関する情報を記憶させるためのデータであり、限定ではなく例として、貸付残高と、貸付金利と、貸付返済額と、その他貸付情報とが関連付けて記憶される。

貸付残高と、貸付金利と、貸付返済額とは、限定ではなく例として、ローンの貸付処理や貸し付けたローンの返済処理に伴い、サーバ１０の制御部１１により更新され記憶される情報とすることができる。

その他貸付情報には、限定ではなく例として、サーバ１０の制御部１１により設定される貸付ローン振込先情報が記憶されるようにすることができる。なお、その他貸付情報に、貸し付けたローンの返済状況や、このアプリケーションＩＤのアカウントのソーシャルスコアに関する情報等を含めるようにしてもよい。

借入登録データは、限定ではなく例として、このアプリケーションＩＤのアカウント所有者であるユーザがマネーローンサービス事業者にローンの借り換えを行う場合、借入ローン契約に関する情報を記憶させるためのデータであり、限定ではなく例として、借入残高と、借入金利と、借入返済額と、その他借入先情報とが関連付けて記憶される。

借入残高と、借入金利と、借入返済額とは、限定ではなく例として、端末２０のユーザによって入力されて登録される情報とすることができる。

その他借入先情報には、限定ではなく例として、借入先企業名や借入ローン振込先情報を含めることができる。
借入先企業名は、限定ではなく例として、借入先の企業の名称とすることができる。
借入先企業名と、借入ローン振込先情報とは、限定ではなく例として、端末２０のユーザによって入力されて登録される情報とすることができる。
なお、その他借入先情報に、借入ローン契約の契約日等の情報を含めるようにしてもよい。

限定ではなく例として、図１－５の例では、アプリケーションＩＤ「Ｕ０００１」のユーザＡ．Ａはマネーローンサービス事業者からまだ借入を行っていない（貸付を受けていない）ことに基づいて、貸付管理データの各項目には該当なし（ＮＵＬＬ）を示す「－」のデータが記憶されている。また、借入登録データの各項目には、ユーザＡ．Ａがローンの借り換えを希望している借入ローン契約として、借入先企業名「ＺＺ金融」から借入残高「３００，０００円」を借入金利「１８％」で借りており、借入返済額が「￥１０，０００」であることが記憶されている。

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

図１－７は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
なお、端末２０の記憶部２８に、アカウント管理データベース１５５Ａの友だち管理データを同期させて記憶させるようにしてもよい。

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

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

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

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

図１－８・図１－９・図１－１０は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。なお、以下では、端末２０が実行する処理を、限定ではなく例として、ユーザＡ．Ａの端末２０Ａが実行する処理として図示・説明する。

図１－８左側は、限定ではなく例として、マネーローンアプリケーションのホーム画面において借り換えプランの申し込みが選択された後に表示される、借入ローン契約の内容を受け付けるための借入先情報入力画面の一例である。
この画面では、画面最上部中央に、マネーローンアプリケーションの名称である「ＭｏｎｅｙＬｏａｎＡｐｐ」の文字が表示されるように構成されている。

また、その下には、マネーローンアプリケーション内での現在の位置やページ等を示す領域（以下、包括的に「アプリ内位置表示領域」と称する。）が構成されており、この例では、借入先情報入力画面であることに基づいて、「借りかえプラン申し込み」の文字が表示されている。

アプリ内位置表示領域の下には、借入ローン契約の契約内容入力を受け付けることを示す「お借入先情報」の文字が表示されるように構成されている。その下には、借入先情報として、限定ではなく例として、借入先企業名と、借入残高と、借入金利と、借入返済額（画面上では「毎月の返済額」と表記）と、借入ローン契約の契約日とを受け付けるフォームが表示されるように構成されている。
この画面では、借入ローン契約の内容として、借入先企業名が「ＺＺ金融」であり、借入残高が「３００，０００円」、借入金利が「年利１８％」、借入返済額が「１０，０００」円、契約日が「２０２０年ｚｚ月ｚｚ日」がそれぞれ入力されたことが表示されている。

借入先情報の入力フォームに情報を入力後、限定ではなく例として、ユーザによって借入先情報確認ボタンＢＴ１がタップされると、限定ではなく例として、図１－８中央の借り換えプラン申し込み確認画面に表示が遷移する。

この画面では、借り換えプラン申し込み確認画面であることを示す「申し込み確認画面」の文字がアプリ内位置表示領域に表示されている。
アプリ内位置表示領域の下には、入力された借入先情報をユーザに確認させるための借入先情報確認領域が表示されるように構成されている。借入先情報確認領域には、「お借入先情報」の文字の下に、借入先情報入力画面において入力された借入先情報が一覧で表示されている。

また、借入先情報確認領域の右上側には、入力された借入先情報の修正を行うための「修正」の文字で示される借入先情報修正ボタンＦＢＴ１が表示されるように構成されている。
限定ではなく例として、借入先情報修正ボタンＦＢＴ１がタップされると、借入先情報入力画面に表示が戻る。

借入先情報確認領域の下には、借り換えを行うユーザがローンサービス事業者に登録を行った各種ユーザ情報を確認するためのユーザ情報確認領域が表示されるように構成されている。
ユーザ情報確認領域では、登録済みの氏名や生年月日、電話番号といった各種ユーザ情報を確認することができる。

ユーザ情報の修正を行う場合、限定ではなく例として、マネーローンアプリケーションのホーム画面から登録情報修正を選択することで実行することができる。

画面最下部には、表示されている借入先情報とユーザ情報とに基づいて、借り換えプランの申し込みを行うための「借りかえプラン申し込み」の文字で示される借り換え申し込みボタンＢＴ２が表示されるように構成されている。

限定ではなく例として、ユーザによって借り換え申し込みボタンＢＴ２がタップされると、限定ではなく例として、図１－８右側の借り換えプラン申し込み完了画面に表示が遷移する。

この借り換えプラン申し込み完了画面では、借入先情報に基づく借り換え申し込みが行われたことを示す「お申し込み手続きが完了しました」の文字の下に、申し込み受付日である「２０２１年１１月１１日」の文字が表示されるように構成されている。
その下には、申し込みが完了したことを示すチェックマークが表示されるように構成されている。
また、チェックマークの下には、申し込み審査が完了するまでユーザに待機を要請するためのメッセージが表示されるように構成されている。
画面最下部には、借り換えプランの申し込みを終了させるための「完了」の文字で示される借り換え申し込み終了ボタンＢＴ３が表示されるように構成されている。

限定ではなく例として、ユーザによって借り換え申し込み終了ボタンＢＴ３がタップされると、限定ではなく例として、図１－９左側のマネーローンアプリケーションホーム画面に表示が遷移する。

このホーム画面では、アプリ内位置表示領域にはホーム画面であることを示す「お取引状況」の文字が表示されている。また、アプリ内位置表示領域の左側には、マネーローンアプリケーションにおける各種操作（限定ではなく例として、ローンの申し込みやユーザ情報の更新等）を行うための、横三本線で示されるメニュー表示ボタンが表示されるように構成されている。

ホーム画面において、限定ではなく例として、アプリ内位置表示領域の下には、貸付先からの各種通知を表示させるように構成することができる。限定ではなく例として、この画面では、申し込みを行った借り換えプランの審査が完了したことを示す審査完了通知ＮＴ１が表示されている。
この審査完了通知ＮＴ１では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、審査完了通知ＮＴ１には、審査結果の確認期限が「２０２１年１１月１８日」であることを示す文字が表示されるように構成されている。

審査完了通知ＮＴ１の下には、申し込みを行った貸付ローン契約に関する情報を表示させるための契約内容表示領域ＣＴＲ１が表示されるように構成されている。
契約内容表示領域ＣＴＲ１には、貸付ローン契約のプラン名である「借りかえプラン」の文字の下に、限定ではなく例として、貸付金利が表示されている。また、その下には、限定ではなく例として、貸付残高（ただし、本例の画面図では契約内容表示領域においてユーザ側に立ち「借入残高」と表記している。）と、次回返済日と、次回返済額とが表示されるように構成されている。なお、ユーザ側に立たず「貸付残高」と表示するようにしてもよい。
この画面では、契約内容表示領域ＣＴＲ１の貸付金利や貸付残高等として、申し込みは受け付けたがユーザとの契約は締結されていないことに基づいて、「審査中」や「処理中」の文字が表示されている。

また、契約内容表示領域ＣＴＲ１の下には、貸付先との取引履歴を示す取引履歴表示領域ＴＨＲ１が表示されるように構成されている。
この画面では、端末のユーザと貸付先との間ではまだローン取引が行われていない事に基づいて、取引履歴表示領域ＴＨＲ１には取引履歴がまだ表示されていない。

限定ではなく例として、ユーザによって審査完了通知ＮＴ１がタップされると、限定ではなく例として、図１－９中央の借り換えプラン契約締結画面に表示が遷移する。

この借り換えプラン契約締結画面では、アプリ内位置表示領域には契約締結の対象である「借り換えプラン」の文字が表示されている。
アプリ内位置表示領域の下には、後述するプレ成約条件に基づく貸付残高（画面内では「貸付金額」と表記）と、貸付金利と、貸付返済額（画面内では「毎月返済額」と表記）とを表示するためのプレ審査結果表示領域ＰＣＴ１が表示されるように構成されている。
この画面では、限定ではなく例として、プレ成約条件として、貸付残高が「３００，０００円」、貸付金利が「１４％」、貸付返済額が「９，０００円」の条件が表示されてユーザに提示されている。

また、プレ審査結果表示領域ＰＣＴ１の下には、プレ成約条件として提示された貸付金利や貸付返済額は、今後の処理結果により下がることがあり得ることを示すメッセージが表示されるように構成されている。
また、その下には、プレ審査結果表示領域ＰＣＴ１に表示されたプレ成約条件に基づく契約締結期限の情報（この例では、「２０２１年１１月１８日」までであることを示すメッセージ）が表示されるように構成されている。

その下には、本借り換えプランの契約内容における、限定ではなく例として、日本国の貸金業法第１６条の２に基づく規定事項が記載された規定事項表示領域ＡＣＴ１が表示されるように構成されている。
規定事項表示領域ＡＣＴ１の下には、チェックボックスと「上記事項を確認しました」のメッセージが表示されるように構成されている。限定ではなく例として、上記規定事項にユーザが同意する場合、チェックボックスをタップすると、チェックボックスがチェック済みとなる。

その下には、プレ審査結果表示領域ＰＣＴ１の条件に基づき借り換え契約を行うための「契約に同意」の文字で示される借り換え契約ボタンＢＴ５と、借り換え契約に同意せず破棄するための「借りかえをやめる」の文字で示される借り換えキャンセルボタンＢＴ４とが表示されるように構成されている。

なお、規定事項表示領域ＡＣＴ１下方のチェックボックスがチェック済みでない場合、限定ではなく例として、借り換え契約ボタンＢＴ５はグレーアウトの表示態様で表示され、限定ではなく例として操作が無効化されるように構成することができる。

限定ではなく例として、ユーザによって借り換え契約ボタンＢＴ５がタップされると、限定ではなく例として、図１－９右側の借入ローン振込先情報入力画面に表示が遷移する。

この借入ローン振込先情報入力画面では、アプリ内位置表示領域には「返済口座登録」の文字が表示されるように構成されている。アプリ内位置表示領域の下には、貸付先が借入ローン契約を代理返済するための借入ローン振込先情報の入力をユーザに促す「他社借入先の返済用口座情報を入力してください」のメッセージが表示されるように構成されている。

メッセージの下には、借入先情報として登録された借入先企業名である「ＺＺ金融」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、借入ローン振込先情報として、限定ではなく例として、金融機関名と、支店名と、口座科目と、振込先口座番号と、受取口座名義とを受け付けるフォームが表示されている。
この画面では、借入ローン振込先情報として、金融機関名が「〇×銀行」であること等がそれぞれ入力されたことが表示されている。

借入ローン振込先情報の入力フォームに情報を入力後、限定ではなく例として、ユーザによって「口座情報登録」の文字で示される借入ローン振込先情報登録ボタンＢＴ６がタップされると、限定ではなく例として、図１－１０左側のホーム画面に表示が遷移する。

このホーム画面において、アプリ内位置表示領域の下には、「ＺＺ金融」への返済を行うための振込処理中であることを示す振込処理通知ＮＴ２が表示されている。
この振込処理通知ＮＴ２では、通知の左側にユーザに確認を促すためのベルマークアイコンが表示されるように構成されている。また、振込処理通知ＮＴ２には、この例では振込予定日が「２０２１年１１月１２日」であることを示す文字が表示されるように構成されている。

なお、限定ではなく例として、ベルマークアイコンが表示される通知（限定ではなく例として、振込処理通知ＮＴ２）は、ユーザが確認後、限定ではなく例としてスワイプ操作を行うことによって通知をホーム画面から消去させることができるようにしてもよい。また、限定ではなく例として、エクスクラメーションアイコンが表示される通知（限定ではなく例として、審査完了通知ＮＴ１）は、限定ではなく例としてスワイプ操作を行った場合でもホーム画面から消去させることができないようにしてもよい。

振込処理通知ＮＴ２の下には、契約内容表示領域ＣＴＲ１が表示されるように構成されている。
この画面では、契約内容表示領域ＣＴＲ１の貸付金利は、プレ成約条件に基づく「１４％」であることが表示されている。また、貸付残高等は、借入先への振込処理が完了していないことに基づいて、「処理中」の文字が表示されている。

限定ではなく例として、時間経過後、「２０２１年１１月１２日」となり、「ＺＺ金融」への振込処理が完了した場合のホーム画面の一例を図１－１０右側に示す。

このホーム画面では、振込処理通知ＮＴ２の下に、「ＺＺ金融」への振込処理が完了し、後述する本成約条件が算出されたことに基づいて、貸付残高等が確定したことにより、借り換えプランの貸付金利等が更新されたことを示す契約書面再交付通知ＮＴ３が表示されている。

また、契約内容表示領域ＣＴＲ１において、貸付金利が本成約条件の「１２％」に更新されたことが表示されている。そして、貸付残高が「３００，０００円」に確定し、次回返済日が「２０２１年１１月２６日」、次回返済金額が本成約条件の貸付返済額に基づく「９，０００円」に確定したことが表示されている。

そして、取引履歴表示領域ＴＨＲ１には、ユーザが「２０２１年１１月２６日」に貸付先から「３００，０００円」を借り入れたことを示す取引履歴が表示されている。

なお、振込処理通知ＮＴ２と契約書面再交付通知ＮＴ３との間に、「ＺＺ金融」への振込処理が完了したことを示す振込処理完了通知を表示させるようにしてもよい。

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

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

最初に、端末２０Ａの制御部２１は、借入先情報受付処理を実行する（Ａ１１０）。
借入先情報受付処理では、限定ではなく例として、端末２０Ａの入出力部２３に対する入力（限定ではなく例として、ユーザ入力（ユーザによる操作入力や音入力等）。以下同様。）に基づいて、端末２０Ａの制御部２１は、借入先情報を取得する。ここで、借入先情報には、限定ではなく例として、借入先企業名と、借入残高と、借入金利と、借入返済額とを含めることができる。

すると、端末２０Ａの制御部２１は、借入先情報受付処理において取得した借入先情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。

通信Ｉ／Ｆ１４によって端末２０Ａから借入先情報を受信すると、サーバ１０の制御部１１は、借入登録データに借入先情報の借入残高等を記憶させる。
そして、サーバ１０の制御部１１は、借入ローン契約からの借り換えによる貸付を行うにあたって、仮の貸付ローン契約条件を算出するためのプレ成約条件算出処理を実行する（Ｓ１１０）。

プレ成約条件算出処理において、サーバ１０の制御部１１は、限定ではなく例として、貸付残高と、貸付金利と、貸付返済額とを、限定ではなく例として、マネーローンサービスの事業者が貸付を行う場合、事業者が損をしないと想定される条件算出方法であるキャップ金利の算出理論に基づいて算出する。以下では、算出された貸付残高（以下、「キャップ貸付残高」と称する。）と、貸付金利（以下、「キャップ貸付金利」と称する。）と、貸付返済額（以下、「キャップ貸付返済額」と称する。）とを、まとめて「キャップ条件」と称する。

なお、キャップ条件の算出において、サーバ１０の制御部１１は、不図示の指定信用情報機関のサーバ（以下、「指定信用情報機関サーバ」と称する。）にユーザＡ．Ａに関する信用情報照会情報を送信する。そして、サーバ１０の制御部１１は、指定信用情報機関サーバからユーザＡ．Ａに関する個人信用情報を受信すると、個人信用情報とキャップ金利の算出理論とに基づいて、キャップ条件を算出するようにしてもよいし、そうしなくてもよい。
指定信用情報機関は、限定ではなく例として、金融機関等から借入等を行っている各々のユーザの借入状況、支払い状況、契約状況などの信用情報を管理する機関として指定された機関とすることができる。

そして、サーバ１０の制御部１１は、限定ではなく例として、キャップ条件と、記憶部１５に記憶されるユーザＡ．Ａのソーシャルスコアとに基づいて、以下の条件を満たす貸付残高と、貸付金利と、貸付返済額とを算出する。
・制約条件１．貸付返済額は借入返済額を上回らない
・制約条件２．貸付金利は借入金利を上回らない
これらの条件は、限定ではなく例として、貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすための条件である。
・制約条件３．貸付金利と、貸付返済額とは、キャップ条件以上である（プレ成約条件での貸付金利≧キャップ貸付金利、かつ、プレ成約条件での貸付返済額≧キャップ貸付返済額）
この条件は、限定ではなく例として、本成約条件において貸付を行う条件を優遇するためのマージンを確保するための条件である。
この制約条件３．によって、プレ成約条件よりも端末２０のユーザにとって同等あるいは有利な本成約条件を算出することが可能となる。
以下では、算出された貸付残高と、貸付金利と、貸付返済額とを、「プレ成約条件」と称する。

限定ではなく例として、ユーザＡ．Ａのソーシャルスコアが高いほど、プレ成約条件での貸付金利とキャップ貸付金利とを近づけるようにしてもよい。また、限定ではなく例として、ユーザＡ．Ａのソーシャルスコアが高いほど、プレ成約条件での貸付返済額とキャップ貸付返済額とを近づけるようにしてもよい。
すなわち、ユーザＡ．Ａのソーシャルスコアが高いほど、プレ成約条件がキャップ条件に近づく（マージン：小）ようにしてもよい。逆に、ユーザＡ．Ａのソーシャルスコアが低いほど、プレ成約条件がキャップ条件から離れる（マージン：大）ようにしてもよい。

ユーザのソーシャルスコアが高いということは、そのユーザの信用性が高い可能性があることを意味する。このため、ユーザのソーシャルスコアが高いほど、本成約条件において貸付を行う条件が優遇されるようにすることができる。また、限定ではなく例として、マネーローンサービスを以前利用したことのあるユーザのソーシャルスコアが、以前よりも高くなっている場合は、そのユーザの信用性が以前よりも高くなっている可能性があるため、以前と比べて、本成約条件において貸付を行う条件が優遇されるようにするといったことも可能となる。
なお、ユーザのソーシャルスコアが低い場合は、これとは逆である。

なお、ソーシャルスコアはサーバ１０の記憶部１５に記憶されることに限定されない。プレ契約条件の算出において、サーバ１０の制御部１１は、不図示のソーシャルスコアサーバにユーザＡ．Ａのソーシャルスコア照会情報を送信する。そして、サーバ１０の制御部１１は、ソーシャルスコアサーバからユーザＡ．Ａのソーシャルスコア情報を受信し、プレ成約条件を算出するようにしてもよい。

すると、サーバ１０の制御部１１は、算出したプレ成約条件を含むプレ成約条件情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２０）。そして、サーバ１０の制御部１１は、プレ成約条件として算出された貸付金利を貸付管理データに記憶させる。
なお、プレ成約条件情報に、プレ成約条件の有効期限を含めるようにしてもよい。

なお、サーバ１０の制御部１１は、プレ成約条件算出処理において、ユーザＡ．Ａのソーシャルスコア等の問題によって上記制約条件１～３のいずれか一つを満たさない場合、ユーザＡ．Ａに対して乗り換えによる貸付を行うことが出来ないこと示す貸付成約不能情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。この場合、端末２０Ａの制御部２１は、受信した貸付成約不能情報を表示部２４に表示させる。また、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０からプレ成約条件情報を受信すると、端末２０Ａの制御部２１は、受信したプレ成約条件情報を表示部２４に表示させる（Ａ１３０）。限定ではなく例として、表示されたプレ成約条件情報に対するユーザ入力に基づいて、ユーザＡ．Ａが提示されたプレ成約条件で借り換えを行うことに同意したと判定する場合（Ａ１４０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、ユーザ入力に基づいて借入ローン振込先情報を取得する。そして、端末２０Ａの制御部２１は、取得した借入ローン振込先情報を含むプレ成約条件同意情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５０）。

ユーザＡ．Ａが提示されたプレ成約条件で借り換えを行うことに同意しないと判定する場合（Ａ１４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

なお、端末２０Ａの制御部１１は、借入先情報受付処理（Ａ１１０）において借入ローン振込先情報も取得し、借入ローン振込先情報を含む借入先情報をサーバ１０に送信するようにしてもよい。

また、端末２０Ａの制御部１１は、サーバ１０からプレ成約条件情報を受信する場合、自動的にプレ成約条件同意情報をサーバ１０に送信するようにしてもよい。

通信Ｉ／Ｆ１４によって端末２０Ａからプレ成約条件同意情報を受信したと判定する場合（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、代替返済振込処理を実行する（Ｓ１４０）。
代替返済振込処理において、サーバ１０の制御部１１は、マネーローンサービス事業者の金融金融口座から、借入ローン振込先情報で指定される金融機関口座（金融機関名・支店名・振込先口座番号・受取口座名義）に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信する。
金融機関において振込処理が完了すると、サーバ１０の制御部１１は、金融機関サーバから振込完了情報を受信する。すると、サーバ１０の制御部１１は、振込処理が成功した借入先について、借入登録データの各レコードを消去する。また、振込処理が成功した借入残高に基づいて、貸付管理データの貸付残高を加算する。

なお、本実施例では、振込処理は成功することとする。振込処理に失敗する場合については後の実施例で説明する。

代替返済振込処理が完了すると、サーバ１０の制御部１１は、本成約条件算出処理を実行する（Ｓ１５０）。
本成約条件算出処理において、サーバ１０の制御部１１は、代替返済振込処理において振込が完了した借入残高とその借入残高に紐づく借入金利とに基づいて、貸付残高と貸付金利と貸付返済額とを、限定ではなく例として、キャップ金利の算出理論に基づいて再度算出する。以下では、算出された貸付残高と貸付金利と貸付返済額とを、「本成約条件」と称する。
上記制約条件３．に基づいて、本成約条件では、プレ成約条件よりも貸付金利や貸付返済額が優遇される可能性がある。
また、本成約条件は制約条件１および制約条件２を自動的に満たすため、段階的借換における例外貸付の判定条件を満たす。

すると、サーバ１０の制御部１１は、本成約条件に基づいて、貸付管理データの各レコードを更新する。
また、サーバ１０の制御部１１は、算出した本成約条件を含む本成約条件情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１６０）。そして、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から本成約条件情報を受信すると、端末２０Ａの制御部２１は、受信した本成約条件情報を表示部２４に表示させる（Ａ１６０）。そして、端末２０Ａの制御部２１は、処理を終了させる。

なお、代替返済振込処理が完了すると、サーバ１０の制御部１１は、代替返済振込が終了したことを示す代替返済振込完了情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。この場合、端末２０Ａの制御部２１は、サーバ１０から代替返済振込完了情報を受信すると、受信した代替返済振込完了情報を表示部２４に表示させる。

限定ではなく例として、プレ成約条件の有効期限を過ぎ、端末２０Ａからプレ成約条件同意情報を受信しないと判定する場合（Ｓ１３０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

なお、サーバ１０の制御部１１は、Ｓ１６０のステップをスキップするようにしてもよい。また、端末２０Ａの制御部２１は、Ａ１６０のステップをスキップするようにしてもよい。
この場合、端末２０Ａの制御部２１は、Ａ１５０のステップを実行すると、限定ではなく例として、ユーザ入力に基づいて、任意のタイミングで条件照会情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。サーバ１０の制御部１１は、端末２０Ａから条件照会情報を受信したと判定する場合、本成約条件算出処理が終了しているならば本成約条件情報を、本成約条件算出処理が終了していない場合には振込処理中である旨の情報を端末２０Ａに送信するようにしてもよい。そして、端末２０Ａの制御部２１は、サーバ１０から受信した本成約条件情報または振込処理中である旨の情報を表示部２４に表示させる。

また、サーバ１０の制御部１１は、Ｓ１２０～Ｓ１３０のステップを省略するようにしてもよい。

また、プレ成約条件の算出においてソーシャルスコアを用いることは必須ではなく、これを用いなくてもよい。
限定ではなく例として、ソーシャルスコアに関係なく、「プレ成約条件の貸付金利＝借入金利」としてもよい。また、限定ではなく例として、ソーシャルスコアに関係なく、設定された割合（マネーローンサービス事業者が得る利益を考慮するなどして決めてもよい。）だけ借入金利から利率を下げた金利をプレ成約条件の貸付金利として算出するようにしてもよい。

＜第１実施例の効果＞
本実施例は、サーバ１０（限定ではなく、ユーザの端末と通信するサーバの一例）は、端末２０のユーザが第１企業から借りた金銭の情報を含む借入先情報（限定ではなく、第１情報の一例）を端末２０から受信する通信Ｉ／Ｆ１４を備える。また、サーバ１０は、受信した借入先情報に基づいて、端末２０のユーザが借りた金銭の借り換えに関する金利の情報を含むプレ制約条件情報（限定ではなく、第１金利情報の一例）を算出（限定ではなく、取得の一例）する制御部１１を備える。そして、制御部１１は、受信した借入先情報に基づき、第１企業に金銭を支払う代替返済振込処理（限定ではなく、支払い処理の一例）を行い、その支払い処理に基づいて、端末２０のユーザが借りた金銭の借り換えに関する金利の情報を含む本成約条件情報（限定ではなく、第２金利情報の一例）を算出（限定ではなく、取得の一例）する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、端末のユーザが第１企業から借りた金銭の情報を含む第１情報を端末から受信した上で、受信した第１情報に基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得することができる。また、その上で、サーバは、受信した第１情報に基づき、第１企業に金銭を支払った上で、その支払いに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得することができる。これにより、端末のユーザが第１企業から借りた金銭の借り換えを可能にするとともに、端末のユーザに適切な金利を提示することができる。また、限定ではなく例として、第２金利情報の金利が第１金利情報の金利と等しいか、それよりも低くなるように第１金利情報を算出するといったことも可能となる。

また、本実施例は、サーバ１０の制御部１１は、プレ成約条件情報（限定ではなく、第１金利情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、取得した第１金利情報を端末に送信することができる。これにより、限定ではなく例として、取得した第１金利情報に含まれる金利の情報を端末のユーザに知らせることができる。

また、本実施例は、算出（限定ではなく、取得の一例）されたプレ成約条件情報は、端末２０のユーザによる承諾に基づいて決定される構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザによる承諾があった場合に、取得された第１金利情報で決定することができる。

＜第１変形例（１）＞
上記の実施例では、プレ成約条件算出処理と、本成約条件算出処理とがサーバ１０の制御部１１において行われることとしたが、これに限定されない。限定ではなく例として、プレ成約条件算出処理または本成約条件算出処理、もしくはその両方の処理を、不図示のマネーローンサービス事業者基幹系サーバ（以下、「基幹サーバ」と称する。）において実行するようにしてもよい。

プレ成約条件算出処理を基幹サーバにおいて実行する場合、限定ではなく例として、サーバ１０の制御部１１は、借入先情報を端末２０から受信すると、受信した借入先情報を基幹サーバに送信する。そして、基幹サーバの制御部は、サーバ１０から受信した借入先情報に基づいて、プレ成約条件算出処理を実行し、算出されたプレ成約条件情報をサーバ１０に送信する。
サーバ１０の制御部１１は、基幹サーバからプレ成約条件情報を受信すると、受信したプレ成約条件情報を端末２０Ａに送信する。

本成約条件算出処理を基幹サーバにおいて実行する場合、限定ではなく例として、サーバ１０の制御部１１は、代替返済振込完了情報を基幹サーバに送信する。そして、基幹サーバの制御部は、サーバ１０から受信した代替返済振込完了情報に基づいて、本成約条件算出処理を実行し、算出された本成約条件情報をサーバ１０に送信する。
サーバ１０の制御部１１は、基幹サーバから本成約条件情報を受信すると、受信した本成約条件情報を端末２０に送信する。

なお、代替返済振込処理を基幹サーバにおいて実行するようにしてもよい。
この場合、限定ではなく例として、サーバ１０の制御部１１は、端末２０からプレ成約条件同意情報を受信すると、受信したプレ成約条件同意情報に基づいて、借入ローン振込先情報を基幹サーバに送信する。基幹サーバの制御部は、サーバ１０から借入ローン振込先情報を受信すると、代替返済振込処理を実行する。
代替返済振込処理が完了すると、基幹サーバの制御部は、代替返済振込完了情報をサーバ１０に送信する。

すなわち、本変形例は、限定ではなく例として、マネーローンアプリケーションのフロントエンド処理をサーバ１０において実行し、バックエンド処理を基幹サーバにおいて実行する例とすることができる。
また、本変形例は、限定ではなく例として、サーバ１０が、第１金利情報や第２金利情報を自装置で算出して取得するのではなく外部から取得する例とすることができる。

＜第１変形例（２）＞
上記の実施例では、代替返済振込処理において金融機関口座間での振込（振替）を実行したが、これに限定されない。限定ではなく例として、借入先が電子マネーでの返済に対応している場合、代替返済振込処理においてマネーローンサービス事業者の電子マネー口座から、借入ローン振込先情報で指定される返済用電子マネー口座に電子マネーの送金を行うようにしてもよい。
電子マネーの送金の処理も、振込（振替）の処理と同様に、サーバ１０が行う支払い処理の一例とすることができる。

＜第１変形例（３）＞
上記の実施例では、プレ成約条件算出処理において、制約条件１～３を満たすようにプレ成約条件を求めたが、これに限定されない。限定ではなく例として、制約条件１～２のみを満たすようにプレ成約条件を求めるようにしてもよい。

この場合、プレ成約条件での貸付金利よりも本成約条件での貸付金利が高くなる、または、プレ成約条件での貸付返済額よりも本成約条件での貸付返済額が高くなる、あるいはその両方を満たす可能性がある。しかし、本成約条件が制約条件１～２を満たす限りにおいて、例外貸付の判定条件は満たされている。

そのため、この場合、サーバ１０の制御部１１は、プレ成約条件算出処理の後、限定ではなく例として、プレ成約条件よりも貸付金利や貸付返済額が上がる可能性があることを含むプレ成約条件情報を端末２０Ａに送信するようにすることができる。

そして、サーバ１０の制御部１１は、端末２０Ａからプレ成約条件同意情報を受信したと判定し（Ｓ１３０：ＹＥＳ）、本成約条件算出処理の後、限定ではなく例として、制約条件１～２を満たし、かつプレ成約条件よりも本成約条件において端末２０のユーザが冷遇される（貸付金利が上がる、または貸付返済額が増額される、もしくはその両方）場合、更新された本成約条件を含む本成約条件情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。

＜第２実施例＞
第１実施例では、端末２０において入力された借入先情報を検証・判定することなく代替返済振込を実行する例を例示した。
第２実施例は、端末２０のユーザが申告した借入先情報を照会し、申告が正しいか否かを検証・判定する実施例である。

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

＜表示画面＞
図２－１～図２－２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
本画面図では、限定ではなく例として、借入企業名「ＺＺ金融」からの借入残高が実際には「２９０，０００円」であるにも関わらず、借入先情報としてユーザが借入残高を「３００，０００円」であると申告した例を示す。
なお、これはあくまでも一例であり、この例に限定されるものではない。

図２－１左側には、限定ではなく例として、図１－９右側の借入ローン振込先情報入力画面において借入ローン振込先情報登録ボタンＢＴ６がタップされると表示される、マネーローンアプリケーションホーム画面の一例を示している。

後述する借入先照会処理の処理結果に基づいて、ホーム画面には借入先確認要請通知ＮＴ４が表示されている。
借入先確認要請通知ＮＴ４では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側には入力された借入先情報に不備が発見されたことを示す「登録された情報に不備が見つかりました」のメッセージが表示されるように構成されている。また、借入先確認要請通知ＮＴ４には、借入先情報の確認期限が「２０２１年１１月１９日」であることを示す文字が表示されている。

限定ではなく例として、ユーザによって借入先確認要請通知ＮＴ４がタップされると、限定ではなく例として、図２－１中央の残高証明書提出画面に表示が遷移する。

この残高証明書提出画面では、アプリ内位置表示領域には借入先情報確認の対象である「借り換えプラン」の文字が表示されている。
アプリ内位置表示領域の下には、正確な借入先情報を取得するためにユーザに残高証明書の提出を促すための「残高証明書の提出が必要です」のメッセージが表示されている。その下には、残高証明書の提出が必要な借入先を示す借入先照合ボタンＬＣ１が表示されるように構成されている。

借入先照合ボタンＬＣ１の中央には、再照会対象となった借入先企業名である「ＺＺ金融」の文字が表示されるように構成されている。また、借入先照合ボタンＬＣ１の左下側には、残高証明書の情報が未登録であることを示す「未登録」の文字で示すアイコンが表示されるように構成されている。

また、残高証明書提出画面の下部には、残高証明書の提出期限を示すメッセージが表示されるように構成されている。この例では、提出期限は「２０２１年１１月１９日」までであることが表示されている。

その下には、残高証明書に関する情報を送信するための「提出する」の文字で示される証明書提出ボタンＢＴ７が表示されるように構成されている。この画面では、借入先照合ボタンＬＣ１で確認できるように未登録の借入先が存在することに基づいて、限定ではなく例として、証明書提出ボタンＢＴ７はグレーアウトの表示態様で表示され、無効化されている。

限定ではなく例として、ユーザによって借入先照合ボタンＬＣ１がタップされると、限定ではなく例として、図２－１右側の証明書取得画面に表示が遷移する。

この証明書取得画面では、アプリ内位置表示領域には証明書提出ボタンがタップされたことに基づいて、「証明書提出」の文字が表示されている。
証明書取得画面の中央部には、限定ではなく例として、ユーザによって証明書撮影ボタンＢＴ８がタップされ、撮像部２７によって残高証明書が撮像されたことにより、「撮影済み書類」の文字の下に撮像された書類の画像が表示されるように構成されている。
また、撮像が行われたことに基づいて、証明書撮影ボタンＢＴ８内部の文字が「撮影する」から「撮影しなおす」の文字へと変化している。

証明書撮影ボタンＢＴ８の下には、撮像した画像を証明書の画像として登録するための「登録」の文字で示される証明書登録ボタンＢＴ９が表示されるように構成されている。なお、書類の画像が撮像されていない場合、限定ではなく例として、証明書登録ボタンＢＴ９は、グレーアウトの表示態様で表示され、無効化されるようにすることができる。

限定ではなく例として、ユーザによって証明書登録ボタンＢＴ９がタップされると、限定ではなく例として、図２－２左側の残高証明書提出画面に表示が遷移する。

この残高証明書提出画面では、証明書の画像が取得されたことに基づいて、借入先照合ボタンＬＣ１内のアイコンが「未登録」アイコンから「登録済み」アイコンに変更されている。また、証明書提出ボタンＢＴ７はグレーアウトの表示態様が解除され、有効化されている。

なお、本画面図とは異なり、借入先照合ボタンＬＣ１がタップされると、借入先情報入力画面が表示され、入力フォームへの入力により再度借入先情報を取得しなおすように構成するようにしてもよい。

限定ではなく例として、ユーザによって証明書提出ボタンＢＴ７がタップされると、限定ではなく例として、図２－２中央のホーム画面に表示が遷移する。

このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、証明書の画像を送信したことにより再度借入先情報の照合が行われ、借入先情報の不整合が解消したことを示す借入先情報照合確認通知ＮＴ５が表示されている。
また、借入先情報照合確認通知ＮＴ５の下には、照合された借入先情報に基づいて、代替返済振込処理を実行していることを示す振込処理通知ＮＴ２が表示されている。

限定ではなく例として、時間経過後、「２０２１年１１月１２日」となり、「ＺＺ金融」への振込処理が完了した場合のホーム画面の一例を図２－２右側に示す。

このホーム画面では、アプリ内位置表示領域の下に、「ＺＺ金融」への振込処理が完了したことを示す振込処理完了通知ＮＴ６が表示されている。また、振込処理完了通知ＮＴ６の下には、本成約条件が算出されたことに基づいて、契約書面再交付通知ＮＴ３が表示されている。

また、契約内容表示領域ＣＴＲ１において、貸付金利が本成約条件の「１２％」に更新されたことが表示されている。そして、貸付残高が証明書の画像に基づく「２９０，０００円」に確定し、次回返済日が「２０２１年１１月２６日」、次回返済金額が本成約条件の貸付返済額に基づく「８，７００円」に確定したことが表示されている。

そして、取引履歴表示領域ＴＨＲ１には、ユーザが「２０２１年１１月２６日」に貸付先から「２９０，０００円」を借り入れたことを示す取引履歴が表示されている。

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

限定ではなく例として、端末２０Ａからプレ成約条件同意情報を受信したと判定する場合（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、借入先照会処理を実行する（Ｓ２１０）。

借入先照会処理において、サーバ１０の制御部１１は、限定ではなく例として、借り換えを行うユーザＡ．Ａの個人信用情報を照会するための信用情報照会情報を通信Ｉ／Ｆ１４によって、前述した不図示の指定信用情報機関サーバに送信する。そして、サーバ１０の制御部１１は、指定信用情報機関サーバからユーザＡ．Ａに関する個人信用情報を受信すると、個人信用情報に記録されたユーザＡ．Ａの借入資金残高等を借入先情報と照合する。

限定ではなく例として、個人信用情報の借入先及び借入資金残高と、借入先情報とが一致している場合、借入先照会処理の実行結果は正常と判断され（Ｓ２１０：正常）、サーバ１０の制御部１１は、Ｓ１４０以降のステップを実行する。

通信Ｉ／Ｆ２２によってサーバ１０から本成約条件情報を受信したと判定する場合（Ａ２１０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した本成約条件情報を表示部２４に表示させる（Ａ１６０）。本成約条件情報を受信しないと判定する場合（Ａ２１０：ＮＯ）、端末２０Ａの制御部２１は、Ａ１６０のステップをスキップさせる。

限定ではなく例として、個人信用情報の借入先及び借入資金残高と、借入先情報とが食い違っている場合、サーバ１０の制御部１１は、借入先照会処理の実行結果は異常と判断し（Ｓ２１０：異常）、処理を終了させる。

なお、借入先照会処理の実行結果が異常と判断される場合、サーバ１０の制御部１１は、借入先情報の再入力を求める借入先確認要請情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。そして、端末２０Ａの制御部２１は、借入先確認要請情報を受信すると、受信した借入先確認要請情報を表示部２４に表示させる。借入先確認要請情報に対するユーザ入力に基づいて、借入先情報が再入力されると、端末２０Ａの制御部２１は、再入力された借入先情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。

ここで、借入先情報の再入力方法として、端末２０Ａの制御部２１は、撮像部２７によって借入ローン契約の契約書や残高証明書を撮像し、取得した画像を借入先情報に含めて送信するようにしてもよい。

端末２０Ａから借入先情報を再受信すると、サーバ１０の制御部１１は、再度借入先照会処理を実行するようにしてもよい。借入先情報に契約書や残高証明書の画像が含まれる場合、サーバ１０の制御部１１は、ＯＣＲ処理を行い借入ローン契約の借入残高等を取得するようにしてもよい。なお、サーバ１０の制御部１１は、借入先情報の画像を表示部１３に表示させるようにしてもよい。そして、サーバ１０のユーザが表示された画像を目視することにより借入先照会処理の実行結果を入出力部１２によって入力するようにしてもよい。

なお、借入先照会処理の実行結果が異常と判断される場合、サーバ１０の制御部１１は、借入先確認要請情報を表示部１３に表示させるようにしてもよい。そして、サーバ１０のユーザは、表示された借入先確認要請情報に基づいて、電話等の手段で端末２０のユーザに連絡し、借入先情報の再照合を行うようにしてもよい。

＜第２実施例の効果＞
本実施例は、サーバ１０の制御部１１が、借入先情報（限定ではなく、第１情報の一例）に含まれる第１企業に金銭を支払うための情報に誤りがなかった場合、本成約条件情報（限定ではなく、第２金利情報の一例）を取得する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、第１情報に含まれる第１企業に金銭を支払うための情報に誤りがなかった場合、第２金利情報を取得することができる。限定ではなく例として、支払いに必要な情報（限定ではなく例として、支払い先の口座の情報等）に誤りがなかった場合や、端末のユーザによって提供された支払いを行うための情報に?偽りがなかったような場合に、第２金利情報を取得するといったことが可能となる。

また、本実施例は、サーバ１０の制御部１１が、限定ではなく例として、指定信用情報機関のサーバ等の装置に記憶されたデータに基づいて、借入先情報（第１情報）に含まれる第１企業に関する情報の正否を判別する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第１企業から借りた金銭の情報を含む第１情報に含まれる第１企業に関する情報の正否を、記憶されたデータに基づいて簡易かつ適切に判別することができる。

また、本実施例は、サーバ１０が端末２０から受信する借入先情報は、端末２０の撮像部２７によって撮像された画像の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末の撮像部によって撮像された画像の情報を含む、端末のユーザが第１企業から借りた金銭の情報を含む第１情報を受信することができる。また、金銭の借り入れに関する情報が端末で撮像されることによって第１情報がサーバに送信されるようにすることができ、金銭の借り入れに関する情報を端末のユーザが手入力せずに済むため、端末側（ユーザ側）の視点ではユーザにとって便利である。

＜第２変形例（１）＞
上記の実施例では、端末２０Ａからプレ成約条件同意情報を受信したと判定する場合（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、借入先照会処理を実行することとしたが、これに限定されない。限定ではなく例として、サーバ１０の制御部１１は、端末２０Ａから借入先情報を受信すると、プレ成約条件算出処理に先んじて借入先照会処理を実行するようにしてもよい。

この場合、サーバ１０の制御部１１は、借入先照会処理の実行結果は正常と判断すると、プレ成約条件算出処理以降の処理が実行するようにしてもよい。また、サーバ１０の制御部１１は、借入先照会処理の実行結果が異常と判断すると、プレ成約条件を算出せずに貸付成約不能情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。なお、サーバ１０の制御部１１は、借入先照会処理の実行結果が異常と判断すると、借入先確認要請情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。

＜第２変形例（２）＞
上記の実施例では、借入先照会処理において、借り換えを行うユーザの個人信用情報と借入先情報の借入残高等とを照合することとしたが、これに限定されない。限定ではなく例として、借入先情報の借入ローン振込先情報が適切か否かを照会するようにしてもよい。

この場合、限定ではなく例として、借入先企業名と、受取口座名義とが一致している場合、借入先照会処理が正常であると判定するように構成することができる。

なお、サーバ１０の制御部１１は、他のユーザの借り換えに伴う借入ローン振込先情報を蓄積して記憶部１５に記憶させ、借入ローン振込先データベースを構築するようにしてもよい。そして、サーバ１０の制御部１１は、借入先照会処理において、借入ローン振込先データベースを参照し、借入先企業名と、金融機関名・支店名が過去の履歴と合致する場合、借入先照会処理が正常であるように構成するようにしてもよい。

また、サーバ１０の制御部１１は、金融機関名と対応する銀行サーバに支店名・振込先口座番号とを含む名義照会情報を送信するようにしてもよい。銀行サーバは名義照会情報を受信すると、銀行サーバの記憶部に記憶される口座管理データベースを参照し、振込先口座番号の名義である口座名義情報をサーバ１０に送信する。そして、サーバ１０の制御部１１は、受信した口座名義情報と借入ローン振込先情報の受取口座名義とが合致する場合、借入先照会処理が正常であるように構成するようにしてもよい。

＜第３実施例＞
上記の実施例では、限定ではなく例として、借入ローン契約を一の契約として例示した。
第３実施例は、限定ではなく例として、端末２０のユーザが、複数の借入ローン契約をマネーローンサービス事業者の提供するローンに借り換える実施例である。なお、本実施例では、サーバ１０が行う振込処理は成功することとする。サーバ１０が行う振込処理が失敗する場合については、第４実施例で説明する。

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

図３－１は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｂのデータ構成例である。
アカウント管理データベース１５５Ｂには、アカウントごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、貸付管理データと、借入先登録データとが記憶される。
アプリケーションＩＤと、貸付管理データとは、限定ではなく例として、アカウント管理データベース１５５Ａと同様に構成することができる。

借入先登録データには、限定ではなく例として、借入先ＩＤと、借入残高と、借入金利と、借入返済額と、その他借入先情報とが関連付けて記憶される。

借入先ＩＤは、借入ローン契約を識別するための情報である。
この借入先ＩＤは、好ましくは借入ローン契約ごとに一意な値であり、限定ではなく例として、サーバ１０が借入先情報を受信すると、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶されるようにすることができる。

以下では、限定ではなく例として、借入登録データのｎ行目（「ｎ」は自然数）に登録される借入先を「第ｎ借入先」と称する。そして、「第ｎ借入先」からの借入ローン契約を「第ｎ借入ローン契約」、借入先情報を「第ｎ借入先情報」、借入ローン振込先情報を「第ｎ借入ローン振込先情報」とそれぞれ称する。

＜表示画面＞
図３－２～図３－３は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

本表示画面では、限定ではなく例として、借入ローン契約が２つの例について例示する。以下では、借入先企業名「ＸＸ信販」との借入ローン契約を「第１借入ローン契約」、借入先企業名「ＹＹローン」との借入ローン契約を「第２借入ローン契約」として区別することとする。なお、第１借入ローン契約と第２借入ローン契約との借入先は同じ企業としてもよい。

図３－２左側は、限定ではなく例として、図１－８左側の借入先情報入力画面の別例である。
この借入先情報入力画面では、アプリ内位置表示領域の下に、第１借入先情報を受け付けることを示す「お借入先情報１」の文字が表示されている。その下には、第１借入先情報を受け付けるフォームが表示されている。
この画面では、第１借入ローン契約の内容として、借入先企業名が「ＸＸ信販」であり、借入残高が「１００，０００円」、借入金利が「年利１０％」、借入返済額が「１０，０００」円、契約日が「２０２０年ｘｘ月ｘｘ日」がそれぞれ入力されたことが表示されている。

借入先情報の入力フォームの下には、他の借入ローン契約をまとめて借り換え希望するか否かを確認するための「その他に借りかえたいお借入先はございますか？」のメッセージが表示されるように構成されている。
メッセージの下には、第１借入ローン契約のみ借り換えを行うための「いいえ」の文字で示される借入先確認ボタンＢＴ１０と、他の借入ローン契約に関する借入先情報を入力するための「はい」の文字で示される他借入先情報入力ボタンＢＴ１１とが表示されるように構成されている。

限定ではなく例として、ユーザによって他借入先情報入力ボタンＢＴ１１がタップされると、再度借入先情報入力画面が表示されるように構成されている。
この画面では、第２借入先情報を受け付けることを示す「お借入先情報２」の文字が表示され、その下には、第２借入先情報を受け付けるフォームが表示される。
この例では、第２借入ローン契約の内容として、借入先企業名が「ＹＹローン」であり、借入残高が「６００，０００円」、借入金利が「年利１５％」、借入返済額が「２０，０００」円、契約日が「２０２０年ｙｙ月ｙｙ日」がそれぞれ入力されることとする。

その後、限定ではなく例として、ユーザによって借入先確認ボタンＢＴ１０がタップされると、限定ではなく例として、図３－２中央の借り換えプラン申し込み確認画面に表示が遷移する。この借り換えプラン申し込み確認画面は、限定ではなく例として、図１－８中央の借り換えプラン申し込み確認画面の別例である。

この画面では、借入先情報確認領域に、「お借入先情報１」の文字の下に、第１借入先情報が一覧で表示されるように構成されている。また、「お借入先情報２」の文字の下に、第２借入先情報が一覧で表示されるように構成されている。
また、第１借入先情報の修正を行うための第１借入先情報修正ボタンＦＢＴ２と、第２借入先情報の修正を行うための第２借入先情報修正ボタンＦＢＴ３とがそれぞれ表示されるように構成されている。
限定ではなく例として、第１借入先情報修正ボタンＦＢＴ２がタップされると、第１借入先情報の入力画面に表示が戻り、第２借入先情報修正ボタンＦＢＴ３がタップされると、第２借入先情報の入力画面に表示が戻る。

なお、ユーザによって３以上の借入先が指定された場合には、同様に、「お借入先情報ｎ（「ｎ」は自然数）」の文字の下に、第ｎ借入先情報が一覧で表示されるように構成するようにしてもよい。

限定ではなく例として、ユーザによって借り換え申し込みボタンＢＴ１２がタップされると、限定ではなく例として、図３－２右側の借り換えプラン申し込み完了画面に表示が遷移する。

そして、限定ではなく例として、ユーザによって借り換え申し込み終了ボタンＢＴ１３がタップされると、マネーローンアプリケーションホーム画面に表示が遷移する。

限定ではなく例として、ホーム画面において、ユーザによって審査完了通知がタップされると、限定ではなく例として、図３－３左側の借り換えプラン契約締結画面に表示が遷移する。

この画面では、プレ審査結果表示領域ＰＣＴ２には、限定ではなく例として、プレ成約条件として、貸付残高が「７００，０００円」、貸付金利が「１４％」、貸付返済額が「２３，０００円」の条件が表示されてユーザに提示されている。

限定ではなく例として、ユーザによって借り換え契約ボタンＢＴ１４がタップされると、限定ではなく例として、図３－３中央の借入ローン振込先情報入力画面に表示が遷移する。この借入ローン振込先情報入力画面は、限定ではなく例として、図１－９右側の借入ローン振込先情報入力画面の別例である。

この借入ローン振込先情報入力画面では、第１借入先情報として登録された借入先企業名である「ＸＸ信販」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、第１借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。

また、第１借入ローン振込先情報の入力フォームの下には、第２借入先情報として登録された借入先企業名である「ＹＹローン」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、第２借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。

なお、ユーザによって３以上の借入先が指定された場合には、同様に、第ｎ借入先情報として登録された借入先企業名の下に、第ｎ借入ローン振込先情報を受け付けるフォームが表示されるように構成するようにしてもよい。

各借入ローン振込先情報を受け付けるフォームに情報を入力後、限定ではなく例として、ユーザによって借入ローン振込先情報登録ボタンＢＴ１５がタップされると、限定ではなく例として、図３－３右側のホーム画面に表示が遷移する。

このホーム画面では、アプリ内位置表示領域の下に、「ＸＸ信販」への振込処理が完了したことを示す振込処理完了通知ＮＴ７と、「ＹＹローン」への振込処理が完了したことを示す振込処理完了通知ＮＴ８とが表示されている。
それらの通知の下には、本成約条件が算出されたことに基づいて、契約書面再交付通知ＮＴ９が表示されている。

また、契約内容表示領域ＣＴＲ２において、貸付金利が本成約条件の「１３％」に更新されたことが表示されている。そして、貸付残高が「７００，０００円」に確定し、次回返済日が「２０２１年１１月２６日」、次回返済金額が本成約条件の貸付返済額に基づく「２３，０００円」に確定したことが表示されている。

そして、取引履歴表示領域ＴＨＲ２には、ユーザが「２０２１年１１月１３日」に貸付先から「７００，０００円」を借り入れたことを示す取引履歴が表示されている。

＜処理＞
処理については、限定ではなく例として、図２－３のフローチャートに従って実行することができる。
なお、以下では、第ｎ借入先情報（「ｎ」は自然数）に含まれる借入残高を「第ｎ借入残高」、借入金利を「第ｎ借入金利」、借入返済額を「第ｎ借入返済額」とそれぞれ称する。

端末２０Ａの制御部２１は、第１借入先情報と第２借入先情報とを受け付けると（Ａ１１０）、第１借入先情報と第２借入先情報とを含む借入先情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。

プレ成約条件算出処理（Ｓ１１０）において、サーバ１０の制御部１１は、キャップ条件を算出すると、限定ではなく例として、キャップ条件と、記憶部１５に記憶されるユーザＡ．Ａのソーシャルスコアとに基づいて、以下の条件を満たすプレ成約条件の貸付残高と、貸付金利と、貸付返済額とを算出する。なお、前述したように、ソーシャルスコアを用いることは必須ではない。
・制約条件１′．貸付返済額は、第１借入返済額と第２借入返済額との合計額（以下、「合計借入返済額」と称する。）を上回らない。
すなわち、「合計借入返済額≧貸付返済額」
ここで、合計借入返済額は、限定ではなく例として、以下のように算出することができる。
「合計借入返済額＝第１借入返済額＋第２借入返済額」
・制約条件２′．貸付金利は、借り換えで返済される借入ローン契約の金利を貸付残高に基づいて平均した金利（以下、「加重平均借入金利」と称する。）を上回らない。
すなわち、「加重平均借入金利≧貸付金利」
ここで、加重平均借入金利は、限定ではなく例として、以下のように算出することができる。
「加重平均借入金利＝（第１借入残高×第１借入金利＋第２借入残高×第２借入金利）÷（第１借入残高＋第２借入残高）」

なお、合計借入返済額と加重平均借入金利とは、上記の式による算出方法に限定されない。限定ではなく例として、合計借入返済額を各借入残高とそれに紐付く借入金利とを用いて算出するようにしてもよいし、そうしなくてもよい。また、限定ではなく例として、加重平均借入金利を各借入金利の単純平均で算出するようにしてもよいし、そうしなくてもよい。

制約条件１′と制約条件２′との条件は、限定ではなく例として、貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすための条件である。

・制約条件３．貸付金利と、貸付返済額とは、キャップ条件以上である
すなわち、「貸付金利≧キャップ貸付金利」かつ「貸付返済額≧キャップ貸付返済額」
この条件は、限定ではなく例として、借り換えのうち一部が適切に実行できない場合を考慮するためのマージンを確保するための条件である。

借入先照会処理（Ｓ２１０）において、サーバ１０の制御部１１は、限定ではなく例として、個人信用情報の各々の借入先及び借入資金残高と、第１借入先情報と第２借入先情報との内容が一致している場合、借入先照会処理の実行結果は正常と判断し（Ｓ２１０：正常）、Ｓ１４０以降のステップを実行する。

代替返済振込処理（Ｓ１４０）において、サーバ１０の制御部１１は、マネーローンサービス事業者の金融金融口座から、第１借入ローン振込先情報で指定される金融機関口座に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信する。
同様に、サーバ１０の制御部１１は、マネーローンサービス事業者の金融金融口座から、第２借入ローン振込先情報で指定される金融機関口座に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信する。

各々の金融機関において振込処理が完了すると、サーバ１０の制御部１１は、金融機関サーバから振込完了情報を受信する。すると、サーバ１０の制御部１１は、振込処理が成功した借入先ＩＤの借入先について、借入登録データの各レコードを消去する。また、振込処理が成功した借入残高に基づいて、貸付管理データの貸付残高を加算する。
なお、本実施例では、前述したように、振込処理は成功することとする。

本成約条件算出処理（Ｓ１５０）において、サーバ１０の制御部１１は、代替返済振込処理において振込が完了した各借入残高とその借入残高に紐づく借入金利とに基づいて、本成約条件を再度算出する。
上記制約条件３．に基づいて、本成約条件では、プレ成約条件よりも貸付金利や貸付返済額が優遇される可能性がある。

また、上記とは異なる計算方法でプレ成約条件や本成約条件を算出することも可能であり、いずれの計算方法を用いてもよい。これは、制約条件３を用いない手法と考えてもよいものとする。なお、処理の流れ（フロー）は、上記の処理と同様とすることができる。

限定ではなく例として、図２－３のプレ成約条件算出処理（Ｓ１１０）において、サーバ１０の制御部１１は、記憶部１５に記憶されるユーザＡ．Ａのソーシャルスコアに基づいて、限定ではなく例として、以下のようにプレ成約条件の貸付金利を算出する。
「プレ成約条件の貸付金利」＝「加重平均借入金利」×「ユーザ係数」

ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値（限定ではなく例として、平均値）より大きい場合、「１」より小さい値をとり、ソーシャルスコアが所定値より小さい場合、「１」より大きい値をとる、正の係数であるようにしてもよい。なお、ユーザ係数は、限定ではなく例として、ソーシャルスコアが所定値である場合、「１」をとるようにしてもよい。

なお、ユーザ係数は、限定ではなく例として、ユーザＡ．Ａの信用情報に基づいて算出されるようにしてもよい。

また、前述したように、ソーシャルスコアを用いることは必須ではなく、これを用いないようにしてもよい。
限定ではなく例として、ソーシャルスコアに関係なく、「加重平均借入金利＝プレ成約条件の貸付金利」としてもよい。また、限定ではなく例として、ソーシャルスコアに関係なく、設定された割合（マネーローンサービス事業者が得る利益を考慮するなどして決めてもよい。）だけ加重平均借入金利から利率を下げた金利をプレ成約条件の貸付金利として算出するようにしてもよい。

また、プレ成約条件の貸付金利を、以下のように算出するようにしてもよい。
「プレ成約条件の貸付金利」＝「加重平均借入金利」－「ユーザ係数」
ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値（限定ではなく例として、平均値－分散値）より大きい場合、「０」より大きい値をとる、正の係数であるようにしてもよい。

そして、サーバ１０の制御部１１は、限定ではなく例として、算出されたプレ成約条件の貸付金利に基づいて、「合計借入返済額≧プレ成約条件の貸付返済額」となるようにプレ成約条件の貸付返済額と貸付残高とを算出する。

また、図２－３の本成約条件算出処理（Ｓ１５０）において、サーバ１０の制御部１１は、限定ではなく例として、上記のようにして算出したプレ成約条件の貸付金利と等しい本成約条件の貸付金利を算出する。

なお、「Ｎ＝１」とすることで、第１実施例や第２実施例で説明した借り入れが１つの契約の場合についても、上記の計算方法を同様に適用可能である。

また、第２実施例では、端末２０のユーザが申告した借入先情報を照会し、申告が正しいか否かを検証・判定する実施例について説明したが、第３実施例で説明した内容をこれと組み合わせて適用することも可能である。
具体的には、図２－３の処理を上記の実施例に適用し、Ｓ２１０の借入先紹介処理において、サーバ１０の制御部１１は、限定ではなく例として、借り換えを行うユーザＡ．Ａの個人信用情報を照会するための信用情報照会情報を通信Ｉ／Ｆ１４によって、前述した不図示の指定信用情報機関サーバに送信する。そして、サーバ１０の制御部１１は、指定信用情報機関サーバからユーザＡ．Ａに関する個人信用情報を受信すると、個人信用情報に記録されたユーザＡ．Ａの借入資金残高等を、端末２０Ａから受信した第１借入先情報と第２借入先情報と照合する。そして、第１借入先と第２借入先との各々について、個人信用情報の借入先及び借入資金残高と、借入先情報（第１借入先情報、第２借入先情報）とが一致している場合、借入先照会処理の実行結果は正常と判断され（Ｓ２１０：正常）、サーバ１０の制御部１１は、Ｓ１４０以降のステップを実行する。

＜第３実施例の効果＞
本実施例は、サーバ１０の通信Ｉ／Ｆ１４は、端末２０のユーザが第１企業から借りた金銭の情報を含む第１借入先情報（限定ではなく、第１情報の一例）と、端末２０のユーザが第２企業から借りた金銭の情報を含む第２借入先情報（限定ではなく、第２情報の一例）とを端末２０から受信する。そして、サーバ１０の制御部１１は、第１借入先情報と第２借入先情報とに基づいて、プレ成約条件情報（限定ではなく、第１金利情報の一例）を取得し、第１借入先情報と第２借入先情報とに基づき、第１企業と第２企業とに金銭を支払い支払い処理を行い、その支払い処理に基づいて、端末２０のユーザが借りた金銭の借り換えに関する本成約条件情報（限定ではなく、第２金利情報の一例）を取得する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、端末のユーザが第１企業から借りた金銭の情報を含む第１情報の他、端末のユーザが第２企業から借りた金銭の情報を含む第２情報を端末から受信した上で、その第１情報と第２情報とに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得することができる。また、その上で、サーバは、受信した第１情報と第２情報とに基づき、第１企業と第２企業とに金銭を支払った上で、その支払いに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第２金利情報を取得することができる。これにより、端末のユーザが第１企業から借りた金銭と、端末のユーザが第２企業から借りた金銭とをまとめた借り換えを可能とすることができるとともに、端末のユーザに適切な金利を提示することができる。また、限定ではなく例として、第２金利情報の金利が第１金利情報の金利と等しいか、それよりも低くなるように第１金利情報を算出するといったことも可能となる。

また、本実施例は、サーバ１０が行う支払い処理は、第１借入先情報（第１情報）に基づき第１企業の口座に振り込みを行い、第２借入先情報（第２情報）に基づき第２企業の口座に振り込みを行う処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第１企業から借りた金銭の情報を含む第１情報に基づき第１企業の口座に振り込みを行い、端末のユーザが第２企業から借りた金銭の情報を含む第２情報に基づき第２企業の口座に振り込みを行う処理を行って、各々の企業への支払いを行うことができる。また、振り込みという一般的な方法で、支払いを簡易かつ適切に行うことができる。

＜第３変形例（１）＞
上記の実施例では、借入ローン契約が２つの例について例示したが、これに限定されない。限定ではなく例として、借入ローン契約を３つ以上としてもよい。
以下では、「Ｎ」個（「Ｎ」は自然数）の借入ローン契約を乗り換える例について考える。

この場合、プレ成約条件算出処理において、制約条件１′における合計借入返済額は、限定ではなく例として、以下のように算出することができる。
合計借入返済額＝第１借入返済額＋・・・＋第ｎ借入返済額＋・・・＋第Ｎ借入返済額

また、制約条件２′における加重平均借入金利は以下のように算出することができる。
加重平均借入金利＝（第１借入残高×第１借入金利＋・・・＋第ｎ借入残高×第ｎ借入金利＋・・・＋第Ｎ借入残高×第Ｎ借入金利）÷（第１借入残高＋・・・＋第ｎ借入残高＋・・・＋第Ｎ借入残高）

そして、借入先照会処理や代替返済振込処理、本成約条件算出処理については借入ローン契約が２つの場合と同様に実行するようにすることができる。

＜第３変形例（２）＞
上記の実施例では、本成約条件が算出されると、サーバ１０の制御部１１は、本成約条件情報を端末２０Ａに送信することとしたが、これに限定されない。
限定ではなく例として、サーバ１０の制御部１１は、本成約条件算出処理を行った後、本成約条件に基づいて、貸付管理データの各レコードを更新する。

端末２０Ａの制御部２１は、限定ではなく例として、ユーザ入力に基づいて、本成約条件を取得することが選択されたか否かを判定する。そして、本成約条件を取得すると判定する場合、端末２０Ａの制御部２１は、本成約条件要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
通信Ｉ／Ｆ１４によって端末２０Ａから本成約条件要請情報を受信したと判定する場合、サーバ１０の制御部１１は、本成約条件情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。

本変形例は、サーバ１０の制御部１１は、端末２０のユーザによる入力に基づいて、本成約条件情報（限定ではなく、第２金利情報の一例）を端末２０に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザによる端末に対する入力に基づいて、第２金利情報を端末に送信することができる。
なお、逆に、限定ではなく例として、端末のユーザによる端末に対する入力がなされなければ、第２金利情報がサーバから端末に送信されないようにしてもよい。

＜第３変形例（３）＞
上記の実施例では、代替返済振込処理において金融機関口座間での振込（振替）を実行したが、これに限定されない。限定ではなく例として、借入先が電子マネーでの返済に対応している場合、代替返済振込処理においてマネーローンサービス事業者の電子マネー口座から、借入ローン振込先情報で指定される返済用電子マネー口座に電子マネーの送金を行うようにしてもよい。
電子マネーの送金の処理も、振込（振替）の処理と同様に、サーバ１０が行う支払い処理の一例とすることができる。

＜第４実施例＞
第３実施例では、代替返済振込処理において全ての借入先に対する振込（振替）が成功する場合について例示した。
第４実施例は、代替返済振込処理において借入先に対する振込（振替）が少なくとも１つ失敗する場合についての実施例である。

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

借入先に対する振込（振替）が失敗する場合、プレ成約条件算出処理における合計借入返済額や加重平均借入金利と、実際に振込処理が成功し、借り換えが確定した借入ローン契約を対象とする合計借入返済額や加重平均借入金利とが変化する可能性がある。このため、借り換え契約時の条件として、振込処理が全て成功する前提でのプレ成約条件を乗り換えローン契約としてそのまま用いる場合、振込処理の状況によっては、貸付金利や貸付返済額が段階的借換における例外貸付の判定条件を満たさなくなるという可能性がある。
そして、この場合、金利に関して法令違反となる場合がある。

分かり易いように具体例を挙げて説明する。
ここでは、限定ではなく例として、一の端末２０のユーザ（以下、単に「ユーザ」と称する。）が、限定ではなく例として、以下の３つの契約に基づく借り入れを行っている場合を考える。
・契約Ａ借入残高１０万円借入金利１０％借入返済額１０，０００円
・契約Ｂ借入残高６０万円借入金利１５％借入返済額２０，０００円
・契約Ｃ借入残高３０万円借入金利１８％借入返済額１０，０００円
この場合、合計借入返済額は「４０，０００円」、加重平均借入金利は「１５．４％」と算出される。

ここで、サーバ１０の制御部１１が、ユーザのプレ成約条件の金利を、限定ではなく例として、上記の加重平均借入金利「１５．４％」から「１％」だけ下げた「１４．４％」として算出したとする。なお、これはあくまで一例に過ぎない。

ユーザがプレ成約条件に同意したものの、サーバ１０が行う代替返済振込処理において、限定ではなく例として、契約Ｂ，Ｃに基づく振込に失敗したとする。この場合、ユーザは「１４．４％」のプレ成約条件の貸付金利で同意したものの、マネーローンサービス事業者から借り換えができるのは契約Ａのみとなる。そして、この場合、プレ成約条件の貸付金利「１４．４％」でユーザに貸付を行うと、実際に借り換え可能な借入ローン契約に基づいて算出される上限金利（すなわち、代替返済振込後に計算される加重平均借入金利（＝契約Ａの借入金利））「１０％」を上回ってしまうため、法令違反となる。
これは、借入の契約が２以上、かつ、振込が失敗する場合に起こり得る。

＜表示画面＞
図４－１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

本表示画面では、限定ではなく例として、第３実施例と同様に、借入先企業名「ＸＸ信販」との第１借入ローン契約と、第２借入先企業名「ＹＹローン」との借入ローン契約との２つの借入先からの乗り換え例について例示する。

限定ではなく例として、図３－３中央の借入ローン振込先情報入力画面においてユーザによって入力された第１借入ローン振込先情報に誤りがあり、代替返済振込処理において「ＸＸ信販」が指定するへの金融機関口座への振込処理が失敗したとする。
図４－１左側に、この場合表示されるホーム画面の一例を示す。

このホーム画面では、「ＹＹローン」への振込処理が完了したことを示す振込処理完了通知ＮＴ８の下に、「ＸＸ信販」への振込処理が失敗したことを示す振込処理失敗通知ＮＴ１０が表示されている。

振込処理失敗通知ＮＴ１０では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側には「ＸＸ信販」への振込処理が失敗したことを示す「ＸＸ信販への振込に失敗しました」というメッセージと、第１借入ローン振込先情報の再確認を促す「口座情報を確認してください」というメッセージとが表示されるように構成されている。また、振込処理失敗通知ＮＴ１０には、第１借入ローン振込先情報の確認期限が「２０２１年１１月１９日」であることを示す文字が表示されるように構成されている。

また、この画面では、契約内容表示領域ＣＴＲ２の貸付金利が、プレ成約条件に基づく「１４％」であることが表示されている。また、貸付残高等は、全ての借入先への振込処理が完了していないことに基づいて「処理中」の文字が表示されている。

限定ではなく例として、ユーザによって振込処理失敗通知ＮＴ１０がタップされると、限定ではなく例として、図４－１中央の借入ローン振込先情報入力画面に表示が遷移する。
この借入ローン振込先情報入力画面では、振込処理に失敗した第１借入先情報として登録された借入先企業名である「ＸＸ信販」の文字が「お借入先会社名」の文字とともに表示されるように構成されている。その下には、再確認が必要な第１借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。

フォームに情報を再入力後、限定ではなく例として、ユーザによって借入ローン振込先情報登録ボタンＢＴ１６がタップされると、ホーム画面に表示が遷移する。

図４－１右側のホーム画面は、限定ではなく例として、図４－１中央の借入ローン振込先情報入力画面において第１借入ローン振込先情報を入力後、再度「ＸＸ信販」への振込処理が失敗した場合の表示画面の一例である。また、この画面では、「ＸＸ信販」への振込処理失敗後、「２０２０年１１月２０日」となった場合を考える。

このホーム画面では、アプリ内位置表示領域の下に、「ＸＸ信販」への振込処理が失敗したことを示す振込処理失敗通知ＮＴ１１が表示されている。
また、振込処理失敗通知ＮＴ１１の下には、振込処理に成功した「ＹＹローン」の第２借入先情報に基づいて本成約条件が算出されたことにより、契約書面再交付通知ＮＴ１２が表示されている。

また、契約内容表示領域ＣＴＲ２において、貸付金利が本成約条件でも変動せず「１４％」であることが表示されている。そして、貸付残高が「ＹＹローン」の借入残高に基づく「６００，０００円」に確定し、次回返済日が「２０２１年１１月２６日」、次回返済金額が本成約条件の貸付返済額に基づく「２０，０００円」に確定したことが表示されている。

そして、取引履歴表示領域ＴＨＲ２には、ユーザが「２０２１年１１月２０日」に貸付先から「６００，０００円」を借り入れたことを示す取引履歴が表示されている。

すなわち、この例では、振込処理に失敗した「ＸＸ信販」からの第１借入ローン契約については乗り換えローンの対象とならず、「ＹＹローン」からの第２借入ローン契約のみが解消され、ローンサービス事業者のローンへ乗り換えが行われたこととなる。

＜処理＞
フローチャートを参照して、本実施例における処理を説明する。
以下説明するフローチャートの処理を適用して計算を行う方法として、限定ではなく例として、計算方法１と計算方法２との２つの計算方法を例示する。計算方法１と計算方法２とのいずれを用いてもよく、処理の流れは同様とすることができる。

＜計算方法１＞
計算方法１では、限定ではなく例として、サーバ１０が、代替返済振込処理が全て成功する前提でのキャップ条件よりも借り換えを行うユーザの条件が不利または等しいプレ成約条件を算出する。そして、プレ成約条件に基づく乗り換えローン契約をユーザと締結する。その後、代替返済振込処理の結果に基づいて、例外貸付の判定条件を満たす範囲内で本成約条件を算出する。そして、乗り換えローン契約をプレ成約条件よりも借り換えを行うユーザが有利または等しい本成約条件に契約を更新する。これは、前述した制約条件３を用いる手法と考えてもよいものとする。

図４－２～図４－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。このフローチャートは、限定ではなく例として、第１実施例のフローチャートを複数の借入先がある場合に拡張し、さらに、代替返済振込処理において振込処理の失敗が起こり得る場合のフローチャートとして構成したものである。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

なお、処理の簡略化のため、第２実施例において例示した借入先照会処理を本フローチャートでは省略する。第２実施例を参酌し、サーバ１０の制御部１１は、限定ではなく例として、プレ成約条件同意情報を受信したと判定する場合（Ｓ１３０：ＹＥＳ）、借入先照会処理（Ｓ２１０）を実行するようにしてもよい。

サーバ１０の制御部１１は、プレ成約条件算出処理において、限定ではなく例として、第１借入先情報と第２借入先情報とに基づくキャップ条件と、記憶部１５に記憶されるユーザＡ．Ａのソーシャルスコアとに基づいて、制約条件１′と、制約条件２′と、制約条件３とを満たすプレ成約条件を算出する。

サーバ１０の制御部１１は、限定ではなく例として、代替返済振込処理を実行すると（Ｓ１４０）、各借入先ＩＤ（この場合、「ｎ＝１，２」）において、第ｎ借入ローン振込先情報に基づく代替返済振込処理が成功したか否か判定する。全ての借入先ＩＤ（この場合、「ｎ＝１、２」）において第ｎ借入ローン振込先情報に基づく代替返済振込処理が成功した場合（Ｓ３１０：ＹＥＳ）、サーバ１０の制御部１１は、本成約条件算出処理を実行する（Ｓ１５０）。

一方、いずれかの借入先ＩＤにおいて第ｎ借入ローン振込先情報に基づく代替返済振込処理が失敗したとする。ここで、限定ではなく例として、２つの借入先のうち１つの借入先において代替返済振込処理に失敗した場合を考える。このとき、代替返済振込処理に失敗した借入先ＩＤを第ｍ借入先（「ｍ」は自然数）とする。この例では、「ｍ＝１または２」となる。
なお、２つの借入先の両方が失敗する場合（「ｍ」＝「１」と「２」）についても同様に考えることができる。

第ｍ借入ローン振込先情報に基づく代替返済振込処理が失敗した場合（Ｓ３１０：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、プレ成約条件同意情報を受信してからの経過日数が設定日数（限定ではなく例として、「７日」）以内であるか否かを判定する（Ｓ３２０）。なお、サーバ１０の制御部１１は、限定ではなく例として、プレ成約条件同意情報を受信してからの経過日数が設定日数未満であるか否かを判定するようにしてもよい。また、経過日数の起算日を、プレ成約条件情報を送信してからとしてもよい。

プレ成約条件同意情報を受信してからの経過日数が設定日数以内であると判定する場合（Ｓ３２０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、第ｍ借入ローン振込先情報の再確認を求めるための振込先情報確認依頼情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ３３０）。
なお、複数の借入先ＩＤにおいて代替返済振込処理に失敗した場合（限定ではなく例として、「ｍ」＝「１」と「２」）、サーバ１０の制御部１１は、失敗した全ての借入先ＩＤ（この場合、「ｍ」＝「１」と「２」）における第ｍ借入ローン振込先情報の再確認を求めるための振込先情報確認依頼情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。

限定ではなく例として、プレ成約条件同意情報をサーバ１０に送信すると（Ａ１５０）、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から振込先情報?確認依頼情報を受信したか否かを判定する（Ａ３１０）。

振込先情報確認依頼情報を受信したと判定する場合（Ａ３１０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した振込先情報確認依頼情報を表示部２４に表示させる（Ａ３２０）。限定ではなく例として、表示された振込先情報確認依頼情報に対するユーザ入力に基づいて、振込処理が失敗した借入先ＩＤにおける借入ローン振込先情報（第ｍ借入ローン振込先情報）を取得すると、端末２０Ａの制御部２１は、受け付けた借入ローン振込先情報を含む借入ローン振込先確認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３３０）。そして、端末２０Ａの制御部２１は、限定ではなく例として、Ａ３１０のステップに処理を戻す。

振込先情報確認依頼情報を受信しないと判定する場合（Ａ３１０：ＮＯ）、端末２０Ａの制御部２１は、本成約条件情報の受信待機を行い、Ａ１６０のステップを実行する。

通信Ｉ／Ｆ１４によって端末２０Ａから借入ローン振込先確認情報を受信すると、サーバ１０の制御部１１は、受信した借入ローン振込先確認情報に基づいて第ｍ借入ローン振込先情報を更新する。なお、複数の借入ローン振込先情報を受信した場合（限定ではなく例として、「ｍ」＝「１」と「２」）、サーバ１０の制御部１１は、複数の第ｍ借入ローン振込先情報を更新するようにしてもよい。

すると、サーバ１０の制御部１１は、更新した借入ローン振込先情報に基づいて、返済振込処理が完了していない借入先ＩＤにおいて、再度代替返済振込処理を実行する（Ｓ１４０）。

なお、サーバ１０の制御部１１は、限定ではなく例として、プレ成約条件同意情報を受信してから設定日数が経過後、借入ローン振込先確認情報を端末２０Ａから受信しないと判定する場合、限定ではなく例として、本成約条件算出処理を実行する（Ｓ１５０）ようにしてもよい。

プレ成約条件同意情報を受信してからの経過日数が設定日数を超過したと判定する場合（Ｓ３２０：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、本成約条件算出処理を実行する（Ｓ１５０）。

本成約条件算出処理において、サーバ１０の制御部１１は、代替返済振込処理が成功した借入先情報に関して、合計借入返済額と加重平均借入金利とを再計算する。

限定ではなく例として、第１借入先のみ代替返済振込処理が成功した場合、「合計借入返済額＝第１借入返済額」、「加重平均借入金利＝第１借入金利」となる。
また、限定ではなく例として、第２借入先のみ代替返済振込処理が成功した場合、「合計借入返済額＝第２借入返済額」、「加重平均借入金利＝第２借入金利」となる。
第１借入先と第２借入先とにおいて代替返済振込処理が成功した場合、前述したように「合計借入返済額＝第１借入返済額＋第２借入返済額」、「加重平均借入金利＝（第１借入残高×第１借入金利＋第２借入残高×第２借入金利）÷（第１借入残高＋第２借入残高）」となる。

すると、サーバ１０の制御部１１は、限定ではなく例として、代替返済振込処理において振込が完了した各借入先ＩＤの第ｎ借入残高と、第ｎ借入残高に紐づく第ｎ借入金利とに基づいて、キャップ金利の算出理論に基づいて、キャップ貸付金利を算出する。また、合計借入返済額に基づいて、貸付残高を算出する。

そして、サーバ１０の制御部１１は、限定ではなく例として、以下の制約条件Ａ～Ｄを満たし、評価関数「｜貸付金利－キャップ貸付金利｜」が最小となるように、本成約条件における貸付金利と貸付返済額とを、限定ではなく例として、最適化問題の一解法であるネルダー・ミード法を用いて算出する。
・制約条件Ａ：「加重平均借入金利≧貸付金利」
・制約条件Ｂ：「プレ成約条件の貸付金利≧貸付金利」
・制約条件Ｃ：「合計借入返済額≧貸付返済額」
・制約条件Ｄ：「プレ成約条件の貸付返済額≧貸付返済額」
なお、「キャップ貸付金利＞貸付金利」（マネーローンサービス事業者が損をする可能性がある貸付金利）としてもよい。

ただし、制約条件Ａの加重平均借入金利は、上記の代替返済振込処理を行った後に再計算される加重平均借入金利であって、プレ成約条件を算出する際に用いられる加重平均借入金利（代替返済振込処理を行う前の加重平均借入金利）ではない。

上記の計算方法によれば、限定ではなく例として、本成約条件における貸付金利と貸付返済額とを未知数とし、限定ではなく例として制約条件Ａ～Ｄのもと、評価関数「｜貸付金利－キャップ貸付金利｜」が最小となる解を、最適化問題のアルゴリズム（最適化演算）によって求めるようにすることができる。

ここで算出された本成約条件は、代替返済振込処理の振込処理結果に関わらず、段階的借換における例外貸付の判定条件を満たす。よって、前述した法令違反となることはない。

また、この計算方法では、借り換えを行うユーザにとっては、プレ成約条件よりも本成約条件が有利な借り換え条件となる可能性がある。少なくとも、プレ成約条件よりも本成約条件において不利となることはない。

本実施例の冒頭に示した具体例を用いて説明する。
前述した具体例に基づき、契約Ａのみが代替返済振込処理の振込処理に成功した場合、再計算された加重平均借入金利は「１０％」となる。
また、限定ではなく例として、契約Ａの借入残高と、借入金利とに基づいて、キャップ貸付金利が「８％」と算出されたとする。
このとき、貸付金利は、上記の最適化の手法により、限定ではなく例として「８％」～「１０％」の間の解で、「８％」になるべく近い、限定ではなく例として「８．５％」と算出される。

なお、本成約条件算出処理において、キャップ貸付金利がプレ成約条件の貸付金利を上回る場合、サーバ１０の制御部１１は、限定ではなく例として、本成約条件の貸付金利を算出せず、プレ成約条件の貸付金利をそのまま本成約条件の貸付金利として用いるようにしてもよい。

最後に、サーバ１０の制御部１１は、算出された本成約条件における貸付金利と貸付返済額と貸付残高とに基づいて、貸付管理データの各レコードを更新する。

なお、代替返済振込処理において全ての借入先において代替返済振込処理が失敗した場合、本成約条件算出処理において、サーバ１０の制御部１１は、借り換えローンの処理に失敗したことを示す本成約条件情報を送信するようにしてもよい。そして、サーバ１０の制御部１１は、借入先登録データのレコードを消去し、更新した貸付管理データを元に戻すようにしてもよい。

また、借入ローン契約を３つ以上とする場合も同様とすることができる。
「Ｎ」個（「Ｎ」は自然数）の借入ローン契約を乗り換える場合、プレ成約条件算出処理における合計借入返済額と加重平均借入金利とは、限定ではなく例として、以下のように算出することができる。
合計借入返済額＝第１借入返済額＋・・・＋第ｎ借入返済額＋・・・＋第Ｎ借入返済額
加重平均借入金利＝（第１借入残高×第１借入金利＋・・・＋第ｎ借入残高×第ｎ借入金利＋・・・＋第Ｎ借入残高×第Ｎ借入金利）÷（第１借入残高＋・・・＋第ｎ借入残高＋・・・＋第Ｎ借入残高）

また、本成約条件算出処理における合計借入返済額と加重平均借入金利とは、代替返済振込処理が完了しなかった借入先ＩＤを第ｍ借入先とすると、上記の式から「ｎ＝ｍ」となる項を省いたものとなる。

計算方法１では、制約条件３を用いた計算を行うことで、限定ではなく例として、マネーローンサービス事業者の利益とユーザのメリットとを考慮した、ちょうどよいバランスの金利を取得し得る。
なお、これは、制約条件３を用いて計算を行う手法を用いる場合において、他の実施例についても同様のことが言える。

＜計算方法２＞
次に、計算方法２について説明する。計算方法２は、制約条件３を用いない手法と考えてもよいものとする。なお、処理の流れ（フロー）は上記の処理と同様とすることができる。

限定ではなく例として、図４－２のプレ成約条件算出処理（Ｓ１１０）において、サーバ１０の制御部１１は、第３実施例で説明したのと同様に、限定ではなく例として、以下のようにプレ成約条件の貸付金利を算出する。
「プレ成約条件の貸付金利」＝「加重平均借入金利」×「ユーザ係数」

また、前述したように、ソーシャルスコアを用いることは必須ではない。また、ユーザ係数は、限定ではなく例として、ユーザＡ．Ａの信用情報に基づいて算出されるようにしてもよい。

図４－３の代替返済振込処理（Ｓ１４０）において失敗した振込が存在する場合、サーバ１０の制御部１１は、図４－３の本成約条件算出処理（Ｓ１５０）において、代替返済振込処理が成功した借入先情報に関して、合計借入返済額と加重平均借入金利とを再計算すると、限定ではなく例として、以下のように本成約条件を算出する。
「本成約条件の貸付金利」＝「ｍｉｎ（加重平均借入金利，プレ成約条件の貸付金利）」
「本成約条件の貸付返済額」＝「合計借入返済額」
「本成約条件の貸付残高」＝代替返済振込処理において振込に成功した借入残高の総和

すなわち、プレ成約条件および本成約条件の両方において、日本国の貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすため、法令違反となることはない。

分かり易いように、本実施例の冒頭に示した、以下の具体例を用いて詳細に説明する。
・契約Ａ借入残高１０万円借入金利１０％借入返済額１０，０００円
・契約Ｂ借入残高６０万円借入金利１５％借入返済額２０，０００円
・契約Ｃ借入残高３０万円借入金利１８％借入返済額１０，０００円
合計借入返済額「４０，０００円」、加重平均借入金利「１５．４％」

また、前述したように、サーバ１０の制御部１１が、ユーザのプレ成約条件の金利を、加重平均借入金利「１５．４％」から「１％」だけ下げた「１４．４％」として算出したものとする。なお、このプレ成約条件の金利の算出においては、前述したように、ユーザのソーシャルスコアを用いてもよいし、用いなくてもよい。

これらの条件（前提）のもと、振込に失敗するケースを含むいくつかのケースについて計算結果を例示する。なお、以下の計算結果における加重平均借入金利は、前述した代替返済振込処理を行った後に再計算される加重平均借入金利である。

（ケース１）契約Ａのみが振込成功の場合（冒頭で例示した振込失敗例）
再計算により、加重平均借入金利１０％、貸付返済額１０，０００円となる。
よって、このケースでは、
本成約条件の貸付金利＝ｍｉｎ（１０％，１４．４％）＝１０％
と算出する。
つまり、このケースは法令違反となってしまうため、再計算された加重平均借入金利を本成約条件の貸付金利とする。

（ケース２）契約Ｃのみが振込成功の場合
再計算により、加重平均借入金利１８％、貸付返済額１０，０００円となる。
よって、このケースでは、
本成約条件の貸付金利＝ｍｉｎ（１８％，１４．４％）＝１４．４％
と算出する。
つまり、このケースは法令違反とならないため、プレ成約条件の貸付金利を維持する。

（ケース３）契約Ａ、Ｂが振込成功の場合
再計算により、加重平均借入金利１４．２９％、貸付返済額３０，０００円となる。
よって、このケースでは、
本成約条件の貸付金利＝ｍｉｎ（１４．２９％，１４．４％）＝１４．２９％
と算出する。
つまり、このケースは法令違反となってしまうため、再計算された加重平均借入金利を本成約条件の貸付金利とする。

（ケース４）契約Ｂ、Ｃが振込成功の場合
再計算により、加重平均借入金利１６％、貸付返済額３０，０００円となる。
よって、このケースでは、
本成約条件の貸付金利＝ｍｉｎ（１６％，１４．４％）＝１４．４％
と算出する。
つまり、このケースは法令違反とならないため、プレ成約条件の貸付金利を維持する。

（ケース５）契約Ａ、Ｂ、Ｃの全てが振込成功の場合
このケースでは、
本成約条件の貸付金利＝ｍｉｎ（１４．４％，１４．４％）＝１４．４％（本成約条件の貸付金利＝プレ成約条件の貸付金利＝１４．４％）
と算出する。
なお、このケースは振込が全て成功するケースであるため、法令違反の問題は生じない。

他のケースにおいても同様に、限定ではなく例として、代替返済振込処理後の加重平均借入金利がプレ成約条件の貸付金利を上回る場合、プレ成約条件の貸付金利が本成約条件の貸付金利とされるようにする。また、代替返済振込処理後の加重平均借入金利がプレ成約条件の貸付金利以下である場合、代替返済振込処理後の加重平均借入金利が本成約条件の貸付金利とされるようにする。このようにすることで、法令違反とならないようにすることができる。

なお、限定ではなく例として、本成約条件の貸付残高が「０」であると算出される場合、限定ではなく例として、サーバ１０の制御部１１は、借り換えローンの貸付に失敗したことを示す本成約条件情報を端末２０に送信するようにしてもよい。

また、借入先が１つの場合であって、代替返済振込処理において振込が失敗する場合、限定ではなく例として、サーバ１０の制御部１１は、借り換えローンの貸付に失敗したことを示す本成約条件情報を端末２０に送信するようにしてもよい。

また、借入先が１つの場合、限定ではなく例として、代替返済振込処理において振込が成功する場合、サーバ１０の制御部１１は、限定ではなく例として、以下のように本成約条件を算出するようにしてもよい。
「本成約条件の貸付金利」＝「プレ成約条件の貸付金利」
「本成約条件の貸付返済額」＝「プレ成約条件の貸付返済額」
「本成約条件の貸付残高」＝「プレ成約条件の貸付残高」

なお、前述したように、「加重平均借入金利＝プレ成約条件の貸付金利」としてもよい。つまり、上記の具体例では、「プレ成約条件の貸付金利＝加重平均借入金利＝１５．４％」としてもよい。

また、上記の金利等の計算方法は、あくまで日本国の場合を例示したものに過ぎず、これに限定されない。上記と同様の思想によって、他の国において同様の問題が生ずる場合であっても、各々の国の法定金利やそれに関連する法令を遵守するように、上記の計算方法１や計算方法２と同様の考え方で、金利等を取得（算出）することができる。

＜第４実施例の効果＞
本実施例は、サーバ１０の制御部１１が、支払い処理において、第１借入先情報（限定ではなく、第１情報の一例）に基づく第１企業への支払いが失敗した場合、第２借入先情報（限定ではなく、第２情報の一例）に基づき決定されたプレ成約条件情報（限定ではなく、第２金利情報の一例）を取得する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、支払い処理において、端末のユーザが第１企業から借りた金銭の情報を含む第１情報に基づく第１企業への支払いが失敗した場合であっても、端末のユーザが第２企業から借りた金銭の情報を含む第２情報に基づき決定された第２金利情報を取得することによって、第２金利情報を適切に取得することができる。

また、この場合、サーバ１０の制御部１１は、再計算された加重平均借入金利（限定ではなく、第２情報に基づき算出される金利の上限の一例）が、プレ成約条件の貸付金利（限定ではなく、第１金利情報の金利の一例）より低い場合、本成約条件の貸付金利（限定ではなく、第２金利情報の金利の一例）を算出するようにしてもよい。
このような構成により得られる実施例の効果の一例として、サーバは、第２情報に基づき算出される金利の上限が、第１金利情報の金利より低い場合、第２金利情報の金利を算出することができる。この場合、前述したように、限定ではなく例として、金利に関連する法令等に違反しない第２金利情報の金利を算出することができる。

また、本実施例は、第１借入先情報は、第１企業の振込口座番号（限定ではなく、第１口座番号の一例）を含み、サーバ１０の制御部１１は、この振込口座番号に誤りがある場合、振込先情報確認依頼情報（限定ではなく、第１口座番号を入力するための情報の一例）を端末２０に通信Ｉ／Ｆ１４によって送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第１企業から借りた金銭の情報を含む第１情報に含まれる第１企業の第１口座番号の情報の第１口座番号に誤りがある場合、第１口座番号を入力するための情報を端末に送信して、端末のユーザに第１口座番号を入力させることができる。

また、本実施例は、サーバ１０の制御部１１は、端末２０のユーザによる、上記の振込先情報確認依頼情報への振込口座番号の入力が設定された期間内に行われなかった場合、第２振込先情報（限定ではなく、第２情報の一例）に基づく本成約条件情報（限定ではなく、第２金利情報の一例）を取得する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第１企業から借りた金銭の情報を含む第１情報に含まれる第１企業の第１口座番号の情報の第１口座番号に誤りがある場合であって、端末のユーザによる、第１口座番号を入力するための情報への入力が設定された期間内に行われなかった場合、端末のユーザが第２企業から借りた金銭の情報を含む第２情報に基づく第２金利情報を取得することができる。

＜第４変形例（１）＞
上記の実施例では、代替返済振込処理において、各借入ローン振込先情報を照合せずに金融機関口座への振込を実行したが、これに限定されない。限定ではなく例として、サーバ１０の制御部１１は、借入ローン振込先情報照合処理を実行し、振込依頼情報を通信Ｉ／Ｆ１４によって不図示の金融機関サーバに送信するようにしてもよい。

限定ではなく例として、サーバ１０の制御部１１は、他のユーザの借り換えに伴う借入ローン振込先情報を蓄積して記憶部１５に記憶させ、借入ローン振込先データベースを構築する。そして、サーバ１０の制御部１１は、借入ローン振込先情報照合処理において、借入ローン振込先データベースを参照し、借入先企業名と、金融機関名・支店名が過去の履歴と合致する場合、振込依頼情報を金融機関サーバに送信するようにしてもよい。

また、借入ローン振込先情報照合処理において、サーバ１０の制御部１１は、金融機関名と対応する銀行サーバに支店名・振込先口座番号とを含む名義照会情報を送信するようにしてもよい。銀行サーバは名義照会情報を受信すると、銀行サーバの記憶部に記憶される口座管理データベースを参照し、振込先口座番号の名義である口座名義情報をサーバ１０に送信する。そして、サーバ１０の制御部１１は、受信した口座名義情報と借入ローン振込先情報の受取口座名義とが合致する場合、振込依頼情報を金融機関サーバに送信するようにしてもよい。

なお、借入ローン振込先情報照合処理の結果、第ｎ借入ローン振込先情報が不当であると判定される場合、サーバ１０の制御部１１は、第ｎ借入先確認要請情報を表示部１３に表示させるようにしてもよい。そして、サーバ１０のユーザは、表示された第ｎ借入先確認要請情報に基づいて、電話等の手段で端末２０のユーザに連絡し、第ｎ借入先情報の照合を行うようにしてもよい。

本変形例は、サーバ１０は、借入ローン振込先データベースなどの記憶部１５に記憶されたデータ（限定ではなく、記憶されたデータの一例）と、第１借入先情報（限定ではなく、第１情報の一例）と、第２借入先情報（限定ではなく、第２情報の一例）とに基づいて、第１企業と第２企業とに対する支払い処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、記憶されたデータと、端末のユーザが第１企業から借りた金銭の情報を含む第１情報と、端末のユーザが第２企業から借りた金銭の情報を含む第２情報とに基づいて、第１企業と第２企業とに簡易かつ適切に金銭を支払うことができる。

＜第５実施例＞
上記の実施例では、借入先情報受付処理において、借入先情報の入力フォームに対するユーザ入力によって借入先情報を取得する例を例示した。第５実施例は、限定ではなく例として、撮像部２７によって借入先の契約書面を撮像することで借入先情報を取得する実施例である。

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

＜表示画面＞
図５－１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図５－１は、限定ではなく例として、図３－２左側の借入先情報入力画面の別例である。

この借入先情報入力画面では、アプリ内位置表示領域の下に、第１借入先情報の取得を行うための借入先受付ボタンＬＩＧ１が表示されるように構成されている。

借入先受付ボタンＬＩＧ１の中央には、第１借入先情報の取得を行うことを示す「借入先１」の文字が表示されるように構成されている。また、借入先受付ボタンＬＩＧ１の左下側には、第１借入先情報が未取得であることを示す「未登録」の文字で示すアイコンが表示されるように構成されている。

限定ではなく例として、ユーザ入力によって借入先受付ボタンＬＩＧ１がタップされると、限定ではなく例として、画面下部から借入先情報の取得方法を選択させるための借入先取得方法選択領域ＩＳＲ１がせり上がり表示されるように構成されている。

借入先取得方法選択領域ＩＳＲ１には、「お借入先情報の入力方法を選択してください」のメッセージの下に、限定ではなく例として、フォーム入力により取得するための「手動入力」の文字で示される借入先情報手動取得ボタンＢＴ１７と、契約書面を撮像することで取得するための借入先情報撮像取得ボタンＢＴ１８とが表示されるように構成されている。

限定ではなく例として、借入先情報手動取得ボタンＢＴ１７がタップされると、限定ではなく例として、図３－２左側と同様の借入先情報入力画面が表示される。

限定ではなく例として、借入先情報撮像取得ボタンＢＴ１８がタップされると、限定ではなく例として、図５－１右側の契約書面取得画面に表示が遷移する。

この契約書面取得画面では、アプリ内位置表示領域には借入先情報撮像取得ボタンがタップされたことに基づいて、「契約書類撮影」の文字が表示されている。
契約書面取得画面の中央部には、限定ではなく例として、ユーザによって契約書面撮影ボタンＢＴ１９がタップされ、撮像部２７によって契約書面が撮像されたことにより、「撮影済み書類」の文字の下に撮像された書類の画像が表示されるように構成されている。
また、撮像が行われたことに基づいて、契約書面撮影ボタンＢＴ１９内部の文字が「撮影する」から「撮影しなおす」の文字へと変化している。

契約書面撮影ボタンＢＴ１９の下には、撮像した画像を契約書面の画像として登録するための「登録」の文字で示される契約書面登録ボタンＢＴ２０が表示されるように構成されている。なお、書類の画像が撮像されていない場合、限定ではなく例として、契約書面登録ボタンＢＴ２０は、グレーアウトの表示態様で表示され、無効化されている。

限定ではなく例として、ユーザによって契約書面登録ボタンＢＴ２０がタップされると、限定ではなく例として、図５－１右側の借入先情報入力画面に表示が遷移する。

この借入先情報入力画面では、契約書面の画像が取得されたことに基づいて、借入先受付ボタンＬＩＧ１内のアイコンが「未登録」アイコンから「登録済み」アイコンに変更されている。また、借入先受付ボタンＬＩＧ１内には、第１借入先情報として取得された借入先企業名である「ＸＸ信販」の文字が表示されている。

また、借入先受付ボタンＬＩＧ１の下には、第２借入先情報の取得を行うための借入先受付ボタンＬＩＧ２が表示されるように構成されている。
同様に、第ｎ借入先情報の取得が実行されると、第ｎ＋１借入先情報の取得を行うための借入先受付ボタンが下に連なる形で表示されるように構成されている。

限定ではなく例として、ユーザによって借入先情報確認ボタンＢＴ１がタップされると、登録済みの借入先情報を確認させるための、限定ではなく例として、図３－２中央と同様な借り換えプラン申し込み確認画面に表示が遷移する。

＜処理＞
端末２０Ａの制御部２１は、限定ではなく例として、借入先情報受付処理（Ａ１１０）において、撮像部２７によって契約書面画像情報を取得する。すると、端末２０Ａの制御部２１は、取得した契約書面画像情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。

通信Ｉ／Ｆ１４によって端末２０Ａから契約書面画像情報を受信すると、サーバ１０の制御部１１は、限定ではなく例として、契約書面画像情報に対してＯＣＲ処理を実行し、借入先情報を取得する。

なお、ＯＣＲ処理は、サーバ１０において実行することに限定されない。限定ではなく例として、端末２０Ａの制御部２１は、契約書面画像情報に対してＯＣＲ処理を実行し、借入先情報を取得する。そして、端末２０Ａの制御部２１は、取得された借入先情報を通信Ｉ／Ｆ２２によってサーバ１０に送信するようにしてもよい。

＜第５実施例の効果＞
本実施例は、第１借入先情報（限定ではなく、第１情報の一例）と第２借入先情報（限定ではなく、第２情報の一例）とは、端末２０の撮像部２７によって撮像された画像の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末の撮像部によって撮像された画像の情報を含む、端末のユーザが第１企業から借りた金銭の情報を含む第１情報と、端末のユーザが第２企業から借りた金銭の情報を含む第２情報とを受信することができる。また、金銭の借り入れに関する情報が端末で撮像されることによって第１情報と第２情報とがサーバに送信されるようにすることができ、金銭の借り入れに関する情報を端末のユーザが手入力せずに済むため、端末側（ユーザ側）の視点では、ユーザにとって便利である。

＜第６実施例＞
上記の実施例では、サーバ１０の制御部１１は、本成約条件情報を端末２０に送信すると、処理を終了させる例を例示した。
第６実施例は、本成約条件情報に基づく借り換えローンの返済に関する実施例である。

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

＜表示画面＞
図６－１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図６－１左側には、限定ではなく例として、図３－３右側のホーム画面から時間が経過し、端末２０Ａのユーザが借り換えローンの返済を失念し、「２０２１年１２月２日」となった場合に表示されるホーム画面の一例を示す。

このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、「１１月分」の借り換えローン返済が完了していないことに基づいて、督促通知ＮＴ１３が表示されている。

督促通知ＮＴ１３では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側にはローンの返済が滞っていることを示す「お支払い期日が過ぎております」というメッセージが表示されるように構成されている。

また、このホーム画面では、契約内容表示領域ＣＴＲ２の下部に、返済が滞っている金額である「延滞金額」の文字が表示され、その右方に、延滞金額が「２５，０００円」であることが強調表示で表示されるように構成されている。延滞金額の下には、限定ではなく例として、延滞金額をサーバ１０の事業者と提携する電子マネーを用いて返済するための「返済する」の文字で示される延滞金返済ボタンＰＢＢ１が表示されるように構成されている。

また、契約内容表示領域ＣＴＲ２では、次回返済日が「２０２１年１２月２６日」であることが表示されている。

限定ではなく例として、ユーザによって延滞金返済ボタンＰＢＢ１がタップされると、支払いアプリケーションが起動する。図６－１中央は、限定ではなく例として、支払いアプリケーション起動後に自動的に遷移する送金画面の一例である。

この画面では、画面最上部中央に、支払いアプリケーションの名称である「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されるように構成されている。
また、アプリ内位置表示領域には、送金画面であることを示す「送金」の文字が表示されている。

アプリ内位置表示領域の下には、送金金額を指定することをユーザに促すための「金額を指定してください」の文字が表示されるように構成されている。その下には、送金金額を指定するための金額指定領域が表示されるように構成されている。この画面では、金額指定領域には、マネーローンアプリケーションから引き継がれた延滞金額である「２５，０００円」が入力された状態で表示されている。

金額指定領域の下には、送金先を示す送金先指定領域が表示されるように構成されている。この画面では、マネーローンアプリケーションから引き継がれた送金先として、マネーローンサービスの返済用電子マネー口座が送金先として表示されている。

送金画面の最下部には、送金先指定領域において指定される電子マネー口座に、金額指定領域において設定される送金金額の電子マネーを送金するための「送金」の文字で示される電子マネー送金ボタンＴＢＴ１が表示されるように構成されている。

限定ではなく例として、ユーザによって電子マネー送金ボタンＴＢＴ１がタップされ、電子マネーの送金に成功すると、限定ではなく例として、図６－１右側のマネーローンアプリケーションホーム画面に表示が遷移する。

このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、延滞金額が返済されたことに基づいて、延滞金返済確認通知ＮＴ１４が表示されている。
この延滞金返済確認通知ＮＴ１４では、ベルマークアイコンの右側に、「延滞金が返済されました」のメッセージが表示されるように構成されている。

また、契約内容表示領域ＣＴＲ２では、延滞金額の表示項目が消え、貸付残高が「６８０，０００円」に減った事が表示されている。

そして、取引履歴表示領域ＴＨＲ２には、ユーザが「２０２１年１１月１３日」に貸付先から「７００，０００円」を借り入れたことを示す取引履歴に加えて、「２０２１年１２月２日」に延滞金「２５，０００」円を返済したことを示す取引履歴が表示されている。

＜処理＞
サーバ１０の制御部１１は、限定ではなく例として、本成約条件情報を端末２０Ａに送信すると（Ｓ１６０）、ユーザに応じて貸付ローン振込先情報を設定し、通信Ｉ／Ｆ１４によって端末２０Ａに送信する。なお、貸付ローン振込先情報に、返済日や返済金額等の情報を含めるようにしてもよい。

なお、端末２０から貸付ローン振込先要求情報を受信したと判定する場合、サーバ１０の制御部１１は、設定された貸付ローン振込先情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から貸付ローン振込先情報を受信すると、端末２０の制御部２１は、受信した貸付ローン振込先情報を表示部２４に表示させる。

サーバ１０の制御部１１は、限定ではなく例として、各月の返済日が過ぎると、不図示の銀行サーバから月次取引情報を受信する。そして、サーバ１０の制御部１１は、月次取引情報を参照し、各ユーザのローン返済金額が入金されたか否かを判定する。

限定ではなく例として、端末２０ＡのユーザＡ．Ａと紐付けられた、貸付ローン振込先情報で指定される金融機関口座に入金が行われていないと判定する場合、サーバ１０の制御部１１は、乗り換えローンの返済が滞っていることを示す督促情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。

通信Ｉ／Ｆ２２によってサーバ１０から督促情報を受信すると、端末２０Ａの制御部２１は、受信した督促情報を表示部２４に表示させる。

＜第６実施例の効果＞
本実施例は、サーバ１０の制御部１１は、本成約条件情報（限定ではなく、第２金利情報の一例）に基づく返済金額を含む返済金額情報を通信Ｉ／Ｆ１４によって端末２０に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、第２金利情報に基づく返済金額を含む貸付ローン振込先情報（限定ではなく、返済金額情報の一例）を端末に送信して、第２金利情報に基づく返済金額を端末のユーザに知らせることができる。返済金額が分かるため、端末側（ユーザ側）の視点ではユーザにとって便利である。

また、本実施例は、サーバ１０の制御部１１は、端末２０のユーザが、貸付ローン振込先情報に基づく返済を期日内に行わない場合、返済を延滞していることを示す督促情報（限定ではなく、延滞情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが、第２金利情報に基づく返済金額を含む返済金額情報に基づく返済を期日内に行わない場合、返済を延滞していることを示す延滞情報を端末に送信して、返済を行うように端末のユーザに促すことができる。

＜第６変形例（１）＞
上記の実施例では、端末２０Ａにおいて、マネーローンアプリケーションのホーム画面にサーバ１０から受信した通知を表示させる例について例示したが、これに限定されない。限定ではなく例として、サーバ１０の事業者がメッセージングサービスを提供する事業者と提携している、またはサーバ１０の事業者とメッセージングサービス事業者が同じ場合等において、メッセージングサービスへ通知を含むコンテンツを送信するようにしてもよい。

図６－２は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図６－２左側は、限定ではなく例として、図３－３左側と同様の借り換えプラン契約締結画面の一例である。限定ではなく例として、ユーザによって借り換え契約ボタンＢＴ１４がタップされると、代替返済振込処理の実行が始まる。

図６－２中央には、借り換え契約ボタンＢＴ１４がタップした後、メッセージングアプリケーションにおいてマネーローンサービスの公式アカウントとのＯＡトークルームを確認した場合のトークルーム画面の一例を示す。

このトークルーム画面では、画面最上部中央に、メッセージングアプリケーションの名称である「ＭｅｓｓａｇｉｎｇＡｐｐ」の文字が表示されるように構成されている。
また、アプリ内位置表示領域には、マネーローンサービスの公式アカウントとのＯＡトークルームであることを示す「ＭｏｎｅｙＬｏａｎＳｅｒｖｉｃｅ」の文字が表示されている。

アプリ内位置表示領域の下には、トークルームにおいて送受信されるコンテンツを表示させるためのトークコンテンツ表示領域が表示されるように構成されている。
トークコンテンツ表示領域には、マネーローンサービスの公式アカウントから送信されたコンテンツが左側からの吹き出しで時系列順に上から下に表示されるように構成されている。この画面では、テキストコンテンツＣＴ１からテキストコンテンツＣＴ７までのコンテンツがマネーローンサービスの公式アカウントから送信されていることが表示されている。

また、トークコンテンツ表示領域の中央部分には、不図示のメッセージングサーバからのシステムコンテンツが表示されるように構成されている。この画面では、「２０２１年１１月１１日」から「２０２１年１１月１３日」までの日付が変わったことを示すシステムコンテンツが表示されている。

限定ではなく例として、テキストコンテンツＣＴ１では、限定ではなく例として、図３－２右側における借り換え申し込み終了ボタンＢＴ１３がタップされたことに基づいて、「借りかえプラン申し込み手続きが完了しました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ２では、プレ成約条件が算出されたことに基づいて、審査完了通知と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ３では、限定ではなく例として、図３－３左側の借り換えプラン契約締結画面における借り換え契約ボタンＢＴ１４がタップされたことに基づいて、「借りかえプランの契約に同意いただきました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ４では、「ＸＸ信販」への代替返済振込処理が完了したことに基づいて、振込処理完了通知ＮＴ７と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ５では、「ＹＹローン」への代替返済振込処理が完了したことに基づいて、振込処理完了通知ＮＴ８と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ６では、全ての借入先への代替返済振込処理が完了したことに基づいて、「他社借入先への返済が全て完了しました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツＣＴ６では、本成約条件が算出されたことに基づいて、契約書面再交付通知ＮＴ９と対応する文字が表示されている。また、テキストコンテンツＣＴ６では、本成約条件を確認するための、「確認」の文字で示される本成約条件確認ボタンＣＦＢ１が表示されるように構成されている。

限定ではなく例として、ユーザによって本成約条件確認ボタンＣＦＢ１がタップされると、限定ではなく例として、図６－２右側のマネーローンアプリケーションホーム画面に表示が遷移する。この画面は、図３－３右側のホーム画面と対応する画面であるが、契約内容表示領域ＣＴＲ２の上方に契約書面再交付通知ＮＴ９等は表示されていない。

なお、上記の画面図では、メッセージングアプリケーションのＯＡトークルームにおいてマネーローンアプリケーションの通知を行う例を例示したが、これに限定されない。
通知の方法としては、限定ではなく例として、以下の方法が挙げられる。
・マネーローンアプリケーションのシステム通知（プッシュ通知）。
・マネーローンアプリケーション内でのポップアップ通知（アプリケーションを開くと通知）。
・マネーローンアプリケーションのお知らせ領域（限定ではなく例として、ホーム画面上段）に通知。
・メッセージングアプリケーションのシステム通知（プッシュ通知）。
・メッセージングアプリケーションのスマートチャンネル領域（限定ではなく例として、トークリスト最上段）に表示。
・メッセージングアプリケーションのタイムラインに表示。
・メッセージングアプリケーションのＯＡトークルームに表示。
・支払いアプリケーションのシステム通知（プッシュ通知）。
・支払いアプリケーションのお知らせ領域（限定ではなく例として、お知らせ画面）に通知。
・上記通知方法の任意の組み合わせ。

＜その他＞
上記の実施例で説明した、マネーローンアプリケーションで実現した内容は、メッセージングアプリケーション等の他のアプリケーションでも同様に実現可能である。

１通信システム
１０サーバ
２０端末
３０ネットワーク

Claims

ユーザの端末と通信するサーバであって、
前記ユーザが複数企業の各々から借りた金銭の情報を含む第１情報を前記端末から受信する通信部と、
前記第１情報に基づいて、前記ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得する制御部とを備え、
前記制御部は、前記第１情報に基づき、前記複数企業の各々に金銭を支払う支払い処理を行い、少なくとも前記複数企業のうちの第１企業への支払いが実行できなかった場合に、少なくとも前記第１企業から借りた金銭の情報を前記第１情報から除いた第２情報に基づき算出される金利の上限が、前記第１金利情報の金利より低い場合、前記第２情報に基づく第２金利情報を取得する制御を行う。
請求項１に記載のサーバであって、
前記支払い処理は、前記第１情報に基づき前記複数企業の各々の口座に振り込みを行う処理を含む。
請求項１または請求項２に記載のサーバであって、
前記第１情報は、前記第１企業の第１口座番号の情報を含み、
前記制御部は、前記第１口座番号に誤りがある場合、前記第１口座番号を入力するための情報を前記端末に前記通信部によって送信する制御を行う。
請求項３に記載のサーバであって、
前記制御部は、前記ユーザによる、前記第１口座番号を入力するための情報への入力が設定された期間内に行われなかった場合、前記第２金利情報を取得する制御を行う。
請求項１から請求項４のいずれか一項に記載のサーバであって、
前記第１情報は、前記端末の撮像部によって撮像された画像の情報を含む。
請求項１から請求項５のいずれか一項に記載のサーバであって、
前記制御部は、記憶されたデータと、前記第１情報とに基づいて、前記複数企業の各々に金銭を支払う支払い処理を行う。
請求項１から請求項６のいずれか一項に記載のサーバであって、
前記制御部は、前記第１金利情報を前記通信部によって前記端末に送信する制御を行う。
請求項１から請求項７のいずれか一項に記載のサーバであって、
取得された前記第１金利情報は、前記端末のユーザによる承諾に基づいて決定される。
請求項１から請求項８のいずれか一項に記載のサーバであって、
前記制御部は、前記端末のユーザによる前記端末に対する入力に基づいて、前記第２金利情報を前記端末に送信する制御を行う。
請求項１から請求項９のいずれか一項に記載のサーバであって、
前記制御部は、記憶されたデータに基づいて、前記第１情報に含まれる前記第１企業に関する情報の正否を判別する制御を行う。
請求項１から請求項１０のいずれか一項に記載のサーバであって、
前記制御部は、前記第２金利情報に基づく返済金額を含む返済金額情報を前記通信部によって前記端末に送信する制御を行う。
請求項１１に記載のサーバであって、
前記制御部は、前記端末のユーザが、前記返済金額情報に基づく返済を期日内に行わない場合、返済を延滞していることを示す延滞情報を前記通信部によって前記端末に送信する制御を行う。
ユーザの端末と通信するサーバの情報処理方法であって、
前記ユーザが複数企業の各々から借りた金銭の情報を含む第１情報を前記端末から前記サーバの通信部によって受信することと、
前記第１情報に基づいて、前記ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を前記サーバの制御部によって取得することと、
前記第１情報に基づき、前記複数企業の各々に金銭を支払う支払い処理を行い、少なくとも前記複数企業のうちの第１企業への支払いが実行できなかった場合に、少なくとも前記第１企業から借りた金銭の情報を前記第１情報から除いた第２情報に基づき算出される金利の上限が、前記第１金利情報の金利より低い場合、前記第２情報に基づく第２金利情報を取得する制御を前記制御部によって行うこととを含む。
ユーザの端末と通信するサーバによって実行されるプログラムであって、
前記ユーザが複数企業の各々から借りた金銭の情報を含む第１情報を前記端末から前記サーバの通信部によって受信することと、
前記第１情報に基づいて、前記ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を前記サーバの制御部によって取得することと、
前記第１情報に基づき、前記複数企業の各々に金銭を支払う支払い処理を行い、少なくとも前記複数企業のうちの第１企業への支払いが実行できなかった場合に、少なくとも前記第１企業から借りた金銭の情報を前記第１情報から除いた第２情報に基づき算出される金利の上限が、前記第１金利情報の金利より低い場合、前記第２情報に基づく第２金利情報を取得する制御を前記制御部によって行うこととが前記サーバによって実行される。
ユーザの端末と、前記端末と通信するサーバとを含むシステムであって、
前記端末は、
前記ユーザが複数企業の各々から借りた金銭の情報を含む第１情報を前記サーバに送信し、
前記サーバは、
前記第１情報を前記端末から受信し、
前記第１情報に基づいて、前記ユーザが借りた金銭の借り換えに関する金利の情報を含む第１金利情報を取得し、
前記第１情報に基づき、前記複数企業の各々に金銭を支払う支払い処理を行い、少なくとも前記複数企業のうちの第１企業への支払いが実行できなかった場合に、少なくとも前記第１企業から借りた金銭の情報を前記第１情報から除いた第２情報に基づき算出される金利の上限が、前記第１金利情報の金利より低い場合、前記第２情報に基づく第２金利情報を取得する。