(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023084657
(43)【公開日】2023-06-19
(54)【発明の名称】サーバ、情報処理方法、プログラム、システム
(51)【国際特許分類】
G06Q 40/02 20230101AFI20230612BHJP
【FI】
G06Q40/02
【審査請求】未請求
【請求項の数】1
【出願形態】OL
(21)【出願番号】P 2022152250
(22)【出願日】2022-09-26
(62)【分割の表示】P 2022100565の分割
【原出願日】2021-12-07
(71)【出願人】
【識別番号】321003371
【氏名又は名称】LINE株式会社
(74)【代理人】
【識別番号】100093687
【弁理士】
【氏名又は名称】富崎 元成
(74)【代理人】
【識別番号】100168468
【弁理士】
【氏名又は名称】富崎 曜
(74)【代理人】
【識別番号】100166176
【弁理士】
【氏名又は名称】加美山 豊
(74)【代理人】
【識別番号】110001759
【氏名又は名称】弁理士法人よつ葉国際特許事務所
(72)【発明者】
【氏名】山岡 巧
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055BB01
(57)【要約】
【課題】借り換えに関する利便性等を向上させる。
【解決手段】ユーザの端末と通信するサーバは、ユーザが第1企業から借りた金銭の情報を含む第1情報を端末から受信する通信部と、第1情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報を取得する制御部とを備え、制御部は、第1情報に基づき、第1企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得する制御を行う。
【選択図】
図1-1
【特許請求の範囲】
【請求項1】
ユーザの端末と通信するサーバであって、
前記ユーザが複数企業の各々から借りた金銭の情報を含む第1情報を前記端末から受信する通信部と、
前記第1情報に基づいて、前記ユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報を取得する制御部とを備え、
前記制御部は、前記第1情報に基づき、前記複数企業の各々に金銭を支払う支払い処理を行い、少なくとも前記複数企業のうちの第1企業への支払いが実行できなかった場合に、少なくとも前記第1企業から借りた金銭の情報を前記第1情報から除いた第2情報に基づき算出される金利の上限が、前記第1金利情報の金利より低い場合、前記第2情報に基づく第2金利情報を取得する制御を行う。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、サーバ、プログラム、情報処理方法、端末等に関する。
【背景技術】
【0002】
消費者金融等の金融機関で貸し出した借金の返済期限を通知する技術がある(例えば、特許文献1)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【0004】
本発明の第1の態様によると、ユーザの端末と通信するサーバは、ユーザが第1企業から借りた金銭の情報を含む第1情報を端末から受信する通信部と、第1情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報を取得する制御部とを備え、制御部は、第1情報に基づき、第1企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得する制御を行う。
本発明の第2の態様によると、ユーザの端末と通信するサーバによって実行されるプログラムは、ユーザが第1企業から借りた金銭の情報を含む第1情報をサーバの通信部によって端末から受信することと、第1情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報をサーバの制御部によって取得することと、第1情報に基づき、第1企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得する制御を制御部によって行うこととがサーバによって実行される。
本発明の第3の態様によると、ユーザの端末と通信するサーバの情報処理方法は、ユーザが第1企業から借りた金銭の情報を含む第1情報をサーバの通信部によって端末から受信することと、第1情報に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報をサーバの制御部によって取得することと、第1情報に基づき、第1企業に金銭を支払う支払い処理を行い、支払い処理に基づいて、ユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得する制御を制御部によって行うこととを含む。
【図面の簡単な説明】
【0005】
【
図1-1】実施形態に係る通信システムのシステム構成の一例を示す図。
【
図1-2】第1実施例に係るサーバの制御部によって実現される機能の一例を示す図。
【
図1-3】第1実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。
【
図1-4】第1実施例に係るアカウント登録データの一例を示す図。
【
図1-5】第1実施例に係るアカウント管理データベースの一例を示す図。
【
図1-6】第1実施例に係る端末の制御部によって実現される機能の一例を示す図。
【
図1-7】第1実施例に係る端末の記憶部に記憶される情報等の一例を示す図。
【
図1-8】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-9】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-10】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-11】第1実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図2-1】第2実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図2-2】第2実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図2-3】第2実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図3-1】第3実施例に係るアカウント管理データベースの一例を示す図。
【
図3-2】第3実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図3-3】第3実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図4-1】第4実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図4-2】第4実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図4-3】第4実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図5-1】第5実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図6-1】第6実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図6-2】第6実施例に係る端末の表示部に表示される画面の一例を示す図。
【発明を実施するための形態】
【0006】
<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
【0007】
<実施形態>
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
【0008】
本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。
【0009】
システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
【0010】
また、クライアント(クライアント装置)とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
(1)端末&サーバ
(2)サーバ
(3)端末
【0011】
(1)は、限定ではなく例として、少なくとも1つの端末と、少なくとも1つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。
【0012】
サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。
【0013】
具体的には、サーバは、限定ではなく例として、少なくとも1つのプロセッサー(限定ではなく例として、CPU:Central Processing Unit、GPU:Graphics Processing Unit、APU:Accelerated Processing Unit、DSP:Digital Signal Processor(限定ではなく例として、ASIC:Application Specific Integrated Circuit、FPGA:Field Programmable Gate Array)等)、コンピュータ装置(プロセッサー+メモリ)、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか1つの装置の同種を複数備える構成(限定ではなく例として、CPU+CPU、ホモジニアスマルチコアプロセッサー等)や、いずれか1つの装置の異種を複数備える構成(限定ではなく例として、CPU+DSP、ヘテロジニアスマルチコアプロセッサー等)としてもよいし、複数の装置の組み合わせ(限定ではなく例として、プロセッサー+コンピュータ装置、プロセッサー+演算装置、複数の装置をヘテロジニアス化したもの等)であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。
【0014】
また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第1処理をプロセッサーが実行し、第2処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
【0015】
また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるPaaSやIaaS、SaaSの形態で提供されるようにしてもよい。
【0016】
また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、(1A)端末の制御部のみ、(1B)サーバの制御部のみ、(1C)端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
【0017】
また、システムの制御部が行う制御や処理(以下、包括的に「制御等」と称する。)は、(1A)端末の制御部のみによって行うようにしてもよいし、(1B)サーバの制御部のみによって行うようにしてもよいし、(1C)端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
【0018】
また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第1装置と第2装置とを備え、第1装置は第1通信部を有し、第2装置は第2通信部を有する場合、サーバの通信部は、第1通信部と第2通信部とを含む概念としてもよい。
【0019】
(2)は、限定ではなく例として、複数のサーバによって構成されるシステム(以下、「サーバシステム」と称する。)とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。
【0020】
サーバシステムが行う制御等は、複数のサーバのうち、(2A)一のサーバのみによって行うようにしてもよいし、(2B)他のサーバのみによって行うようにしてもよいし、(2C)一のサーバと他のサーバとが行うようにしてもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
【0021】
(3)は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース(登録商標)等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
【0022】
なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。
【0023】
以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム(限定ではなく例として、クライアントサーバシステム)を例示する。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
【0024】
また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記(3)のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
【0025】
なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
【0026】
また、本明細書では、適宜「通信I/Fによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部(プロセッサー等)の制御に基づいて、通信I/Fを介して(通信部を介して)、各種の情報やデータを送受信することを示してもよいものとする。
【0027】
また、本明細書において「関する」、「関連する」と記載された用語について、「Aに関するB」や「Aに関連するB」という場合、限定ではなく例として、「A」と何らかの関係性を有する「B」を意味してよいものとする。この具体例については後述する。
【0028】
また、本明細書において、「AとBとを送信する」、「AとBとを受信する」といったように、装置が2以上のものを対象として処理を行うことには、「A」と「B」とをタイミングを合わせて行うもの(以下、「同時」という。)と、「A」と「B」とをタイミングをずらして行うもの(以下、「非同時」という。)とを含めてよいものとする。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
【0029】
なお、「A」と「B」とをタイミングをずらして行うといっても、これはあくまでも「A」と「B」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
【0030】
以下の実施例では、ユーザがチャットを行うためのサービス(以下、「チャットサービス」と称する。)の一例として、メッセージングサービス(Messaging Service)を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにすることができる。
【0031】
なお、メッセージングサービス:MS(インスタントメッセージサービス:IMSを含む。)は、ソーシャルネットワーキングサービス:SNSの1つの形態(一形態)と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。
【0032】
また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置(限定ではなく例として、端末)間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス:IMS(Instant Messaging Service)を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにすることができる。
【0033】
チャットルーム(限定ではなく例として、トークルーム)とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるUI(User Interface)やGUI(Graphical User Interface)とすることができる。
【0034】
また、トークルームには、一対一のユーザのトークルーム(以下、「一対一トークルーム」と称する。)、複数のユーザを含むグループのトークルーム(以下、「グループトークルーム」と称する。)、公式アカウントのユーザとのトークルーム(以下、「OAトークルーム」と称する。)等を含めることができる。
【0035】
なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、2名のユーザや2つのアカウントで構成されるグループのトークルームとして管理してもよい。
【0036】
公式アカウントは、一般のユーザではなく事業者のアカウント(事業者のユーザのアカウント)であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ(メッセージ)の送受信を行うことができるようにすることができる。
【0037】
本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、1または複数のコンテンツであってもよい。
【0038】
コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像(静止画像、動画像の少なくともいずれか一方を含む。)形式の画像コンテンツ、音(音声を含む。)形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報(限定ではなく例として、URI(Uniform Resource Identifier)等を含む。)などのリンクコンテンツを含めてもよいものとする。
【0039】
テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか1つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
【0040】
画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか1つを含めることができる。
【0041】
また、以下の実施例では、ユーザが金融機関からお金を借りるためのサービスの一例として、マネーローンサービス(Loan Service)を例示する。また、マネーローンサービスを実現するためのアプリケーションを「マネーローンアプリケーション」と称する。
マネーローンアプリケーションでは、限定ではなく例として、ユーザが他社で借入中の借金をマネーローンサービスの事業者が肩代わりし、マネーローンサービスの事業者に対する借金として一本化しまとめて借り換える「ローン借り換え」を行うことができる。
【0042】
また、以下の実施例では、ユーザが支払いを行うためのサービス(以下、「支払いサービス」と称する。)を例示する。また、支払いサービスを実現するためのアプリケーションを「支払いアプリケーション」と称する。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い(決済)を行うようにことができるようにすることができる。
【0043】
電子貨幣を用いた支払い方法としては、限定ではなく例として、「利用者提示型」のコード支払いと、「店舗提示型」のコード支払いとのうちのいずれかの方法を適用することができる。
【0044】
「利用者提示型」のコード支払いは、限定ではなく例として、端末20の表示部24に表示されたコード情報をユーザが店舗の店員に提示し、店舗のコードリーダで読み取ってもらうことで支払いを行う方法とすることができる。
「店舗提示型」のコード支払いは、限定ではなく例として、店舗側が提示するコード情報をユーザが自己の端末20のコードリーダに読み取らせて支払いを行う方法とすることができる。
【0045】
本明細書において、「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末、または端末のユーザが所有する電子的な貨幣を意味するものとしてよいものとする。
なお、「電子貨幣」は、「デジタル通貨(デジタル貨幣)」と考えてもよいものとする。
【0046】
1つの考え方として、電子貨幣は、「電子マネー」、「仮想通貨(暗号資産)」、「中央銀行発行デジタル通貨(CBDB)」などを含む概念と考えてもよいものとする。
【0047】
また、電子貨幣は、「法定通貨」でもよいし、「企業通貨」でもよいものとする。電子貨幣の実装方法としては、「中央集権型金融(CeFi)」としてもよいし、「分散型金融(DeFi)」としてもよいものとする。
【0048】
以下説明する実施例では、限定ではなく例として、電子貨幣の一例として、中央集権型金融における企業通貨としての電子マネーについて例示する。
【0049】
なお、企業通貨には、クーポンなどの物的貨幣を含めてもよいものとする。
【0050】
マネーローンサービス(マネーローンアプリケーション)を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
(A1)メッセージングアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
(A2)支払いアプリケーションの一機能としてマネーローンサービスの機能を持たせる形態
(B1)マネーローンサービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(B2)マネーローンサービスの機能と支払いサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(B3)マネーローンサービスの機能と支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(C1)マネーローンアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
(C2)マネーローンアプリケーションとは別のアプリケーションとして支払いアプリケーションを構成する形態
(C3)マネーローンアプリケーションとは別のアプリケーションとして支払いサービスとメッセージングサービスとの統合的なアプリケーションを構成する形態
(D)マネーローンアプリケーションを単体のアプリケーションとして構成する形態
【0051】
(A1)や(B1)、(B3)の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、1つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる(連携される)ようにすることができる。
【0052】
マネーローンサービス事業者を、支払いサービス事業者と同じ事業者とする場合についても同様である。
【0053】
(C1)~(C3)の形態では、限定ではなく例として、マネーローンサービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、(C1)~(C3)の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、マネーローンアプリケーションにおけるユーザのアカウントとを関連付ける処理(連携する処理)を行うようにすることができる。
支払いアプリケーションについても同様である。
【0054】
なお、上記とは異なり、マネーローンアプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。マネーローンアプリケーションの一機能として支払いサービスの機能を持たせるようにしてもよい。
【0055】
<実施例>
以下、実施例について説明する。
以下説明する実施例では、マネーローンサービスにおいて、限定ではなくサーバが、金利(金利を含む金利情報)を2回取得(算出を含む。)することによって、端末のユーザに適切な金利を提示することを可能にする。
【0056】
金利(金利を含む金利情報)を2回取得するのは、一つの観点からは、端末のユーザの申告に基づいて、大枠となる1回目の金利を取得し、その後、1回目の金利に対する端末のユーザの同意に基づいて、精査された2回目の金利を取得することで、端末のユーザが乗り換えローンの契約を迅速に締結できるようにすることがある。また、別の観点からは、詳細は第4実施例で説明するが、1回目の金利の取得後、乗り換えローンの一部の処理に失敗する可能性があり、この場合、法令上の問題を回避するための2回目の金利の取得が必要となる場合がある。
【0057】
<第1実施例>
第1実施例は、限定ではなく例として、一の端末20(以下、適宜「端末」と称する。)のユーザが、サーバ10を運用するマネーローンサービス事業者以外の他の事業者からのローン(借金)をマネーローンサービス事業者の提供するローンに借り換える実施例である。
第1実施例では、限定ではなく例として、乗り換えを行う他社からのローン契約を一の契約とする。
【0058】
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0059】
以下では、ローン利用者(限定ではなく例として、端末20のユーザ)から見て、借り換え先(乗り換え先)となるマネーローンサービス事業者(サーバ10を運用するマネーローンサービス事業者)を「貸付先」と呼称する。また、ローン利用者から見て、借り換え元となる他社事業者を「借入先」と呼称する。貸付先は、サーバ10の事業者と表現することもできる。
【0060】
ここで、貸付先と借入先とは、限定ではなく例として、それぞれ企業とすることができる。企業は、貸金業法において規定される貸金業者とすることができる。企業は、団体であってもよいし、個人であってもよい。また、企業は、法人であってもよいし、そうでなくてもよい。
【0061】
また、以下では、限定ではなく例として、
・借入先からのローン契約:「借入ローン契約」
・借入ローン契約において端末20のユーザが借入を行った残高:「借入残高」
・借入を行った場合の金利(限定ではなく例として、実質年率):「借入金利」
・借入に対する月々の約定返済額:「借入返済額」
とそれぞれ称する。借入ローン契約に関する情報を、以下では「借入先情報」と称する。
【0062】
また、以下では、限定ではなく例として、
・借入ローン契約において借金の返済を行うための振込先となる金融機関口座に関する情報:「借入ローン振込先情報」
と称する。借入ローン振込先情報には、限定ではなく例として、金融機関名と、支店名と、振込先口座番号と、受取口座名義とを含めることができる。なお、借入ローン入金情報に、口座科目(限定ではなく例として、「普通預金口座」)や金融機関コード、振込依頼人名義等を含めるようにしてもよい。
【0063】
また、以下では、限定ではなく例として、
・貸付先において結ぶローン契約:「貸付ローン契約」
・貸付ローン契約において端末20のユーザが借入を行った残高:「貸付残高」
・端末20のユーザが借入を行った場合の金利(限定ではなく例として、実質年率):「貸付金利」
・借入に対して端末20のユーザが月々返済する約定返済額:「貸付返済額」
とそれぞれ称する。
【0064】
また、以下では、限定ではなく例として、
・貸付ローン契約において借金の返済を行うための振込先となる金融機関口座に関する情報:「貸付ローン振込先情報」
と呼称する。貸付ローン振込先情報は、限定ではなく例として、借入ローン振込先情報と同様の情報を含めるように構成することができる。
【0065】
なお、マネーローンサービス事業者が支払いサービス事業者と提携している、またはマネーローンサービス事業者が支払いサービス事業者を兼ねる場合、限定ではなく例として、貸付ローン振込先情報は、ローン返済用に設定された電子マネー口座に関する情報を含めるように構成してもよい。借入ローン振込先情報についても同様である。
【0066】
なお、貸付先または借入先の少なくとも一方に、行政機関を含めるようにしてもよいし、そうしなくてもよい。また、貸付先または借入先の少なくとも一方に、企業以外の任意団体を含めるようにしてもよいし、そうしなくてもよい。
【0067】
また、以下では、マネーローンアプリケーションの名称を、適宜「Money Loan App」と称して図示・説明する。
【0068】
<システム構成>
図1-1は、本開示の実施形態における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
【0069】
サーバ10は、ネットワーク30を介して、ユーザが所有する端末20に、所定のサービス(限定ではなく例として、マネーローンサービス、メッセージングサービス等)を提供する機能を有する。サーバ10は、限定ではなく例として、マネーローンサーバ、メッセージングサーバ等のように表現することもできる。
本実施形態では、マネーローンサービス事業者(運営者)やメッセージングサービス事業者(運営者)をサーバ10のユーザとする。
【0070】
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
【0071】
端末20(端末20A,端末20B,端末20C、・・・)は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、VR(Virtual Reality)端末、スマートスピーカ(音声認識用デバイス)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
【0072】
端末20A、端末20Bおよび端末20Cの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザXが利用する端末を端末20Xと表現し、ユーザXまたは端末20Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
【0073】
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
【0074】
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定ではなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
【0075】
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
【0076】
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
【0077】
(1)端末のHW構成
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0078】
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10等の各種装置との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10等の各種装置に送信する。また、通信I/F22は、サーバ10等の各種装置から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0079】
入出力部23は、端末20に対する各種操作を入力する装置や、端末20で処理された処理結果を出力する装置等を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0080】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含む。
【0081】
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ(音声出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
【0082】
あくまでも一例であるが、入出力部23は、限定ではなく例として、表示部24、音入力部25、音出力部26、撮像部27を備える。
【0083】
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
【0084】
音入力部25は、音データ(音声データを含む。以下同様。)の入力に利用される。音入力部25は、マイクなどを含む。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
【0085】
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
【0086】
時計部29Aは、端末20の内蔵時計であり、時刻情報(計時情報)を出力する。時計部29Aは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部29Aは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
【0087】
なお、時計部29Aは、NITZ(Network Identity and Time Zone)規格等を適用したクロックを有していてもよいし、有していなくてもよい。
【0088】
位置算出用情報検出部29Bは、制御部21が自己の端末20の位置を算出(測定)するために必要な情報(以下、「位置算出用情報」と称する。)を検出(計測)する機能部である。位置算出用情報検出部29Bは、限定ではなく例として、位置算出用センサ部と表現することもできる。
【0089】
位置算出用情報検出部29Bは、限定ではなく例として、GPS(Global Positioning System)等の衛星測位システムを利用して端末20の位置を算出するためのセンサやユニットである衛星測位センサ(衛星測位ユニット)や、慣性航法システムを利用して端末20の位置を算出するためのセンサやユニットである慣性計測センサ(慣性計測ユニット(IMU(Inertial Measurement Unit)))、UWB(超広帯域無線:Ultra Wide Band)を利用して端末20の位置を算出するためのセンサやユニットであるUWB測位センサ(UWB測位ユニット)等を含む。
【0090】
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むRF(Radio Frequency)信号をデジタル信号に変換するRF受信回路や、RF受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
【0091】
慣性計測ユニットは、慣性航法演算によって端末20の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、3軸の加速度センサや3軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
【0092】
UWB測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域RF(Radio Frequency)信号をデジタル信号に変換する超広帯域RF受信回路や、超広帯域RF受信回路から出力されるデジタル信号に基づいて端末20と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
【0093】
制御部21は、限定ではなく例として、位置算出用情報検出部29Bによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末20の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部21は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部28に記憶させるようにしてもよいし、そうしなくてもよい。
【0094】
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
【0095】
制御部21は、限定ではなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
【0096】
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定ではなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0097】
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
【0098】
(2)サーバのHW構成
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0099】
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
【0100】
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
【0101】
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0102】
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20等の各種装置に送信する。また、通信I/F14は、端末20等の各種装置から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0103】
入出力部12は、サーバ10に対する各種操作を入力する装置や、サーバ10で処理された処理結果を出力する装置等を含む。入出力部12は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0104】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。
【0105】
出力部は、制御部11で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ(音出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
【0106】
あくまでも一例であるが、入出力部12は、限定ではなく例として、表示部13を備える。
【0107】
表示部13は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
【0108】
時計部19は、サーバ10の内蔵時計であり、時刻情報(計時情報)を出力する。時計部19は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部19は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
(3)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
【0109】
本開示の各実施形態においては、端末20および/またはサーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
【0110】
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
【0111】
また、本開示の各実施形態のプログラムP(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
【0112】
また、システムのプログラム(システムによって実行されるプログラム)という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをP1とすると、システムのプログラムP1は、端末に保存されたプログラムP2と、サーバに保存されたプログラムP3とで構成され、P2とP3とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムP2は、第1の処理を実行し、第1の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムP3は、受信した第1の処理をした結果に対して第2の処理を行い、第2の処理を行った結果を端末に送信するプログラムであってもよい。
【0113】
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
【0114】
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
【0115】
また、本開示のプログラムPは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
【0116】
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
【0117】
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
【0118】
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
【0119】
<機能構成>
(1)サーバの機能構成
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたアプリケーション管理処理プログラム151に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部111を機能部として含む。
【0120】
図1-3は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とが記憶される。
【0121】
アカウント登録データ153は、アプリケーション(本実施例では、マネーローンアプリケーション)のアカウントに関する登録データであり、そのデータ構成の一例を
図1-4に示す。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
【0122】
ユーザ名は、このアプリケーションを利用する端末20のアカウントの名称であり、限定ではなく例として、端末20のユーザがアプリケーションを利用する際に登録する名称が記憶される。
【0123】
アプリケーションIDは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
【0124】
その他登録情報には、限定ではなく例として、端末20を識別するための識別情報、端末20の電話番号(端末電話番号)、メールアドレス(端末メールアドレス)、アプリケーションにおける各種の認証に利用されるパスワード(ログインパスワード、認証パスワード等)等の認証情報といった各種の情報を含めるようにすることができる。
【0125】
なお、その他登録情報に、貸付に際しての与信を判断するための情報として、限定ではなく例として、端末20のユーザが登録可能な、以下の項目を含めるようにしてもよい。
・勤務先
・年収
・勤続年数
・家族構成
・資産状況
・住居形態
【0126】
端末20を識別するための識別情報は、限定ではなく例として、端末ID(限定ではなく例として、IMEI(International Mobile Equipment Identity))とすることができる。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションIDとすることができる。
【0127】
なお、アプリケーションIDに代えて「ユーザID」としてもよいし、しなくてもよい。
また、1つの端末20につき1つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」とすることができる。
【0128】
また、限定ではなく例として、1つのアプリケーションIDに、複数の端末IDを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、1つのアプリケーションIDを識別(ログイン)対象として、複数の端末20においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。
【0129】
また、アプリケーションID等の各種のIDに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。なお、アプリケーションID等のIDの情報を端末電話番号等の情報に代えず、アプリケーションID等のIDの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
【0130】
なお、以下の各種の実施例では、説明の簡明化のため、1つの端末20につき1つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
【0131】
アカウント管理データベース155は、アカウント登録データ153に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース155Aのデータ構成例を
図1-5に示す。
アカウント管理データベース155Aには、アカウントごとの管理データとして、アカウント管理データが記憶される。
【0132】
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、貸付管理データと、借入登録データとが記憶される。
【0133】
アプリケーションIDは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ153に登録されたアプリケーションIDが記憶される。
【0134】
貸付管理データは、限定ではなく例として、マネーローンサービス事業者がこのアプリケーションIDのアカウント所有者であるユーザに貸し付ける貸付ローン契約に関する情報を記憶させるためのデータであり、限定ではなく例として、貸付残高と、貸付金利と、貸付返済額と、その他貸付情報とが関連付けて記憶される。
【0135】
貸付残高と、貸付金利と、貸付返済額とは、限定ではなく例として、ローンの貸付処理や貸し付けたローンの返済処理に伴い、サーバ10の制御部11により更新され記憶される情報とすることができる。
【0136】
その他貸付情報には、限定ではなく例として、サーバ10の制御部11により設定される貸付ローン振込先情報が記憶されるようにすることができる。なお、その他貸付情報に、貸し付けたローンの返済状況や、このアプリケーションIDのアカウントのソーシャルスコアに関する情報等を含めるようにしてもよい。
【0137】
借入登録データは、限定ではなく例として、このアプリケーションIDのアカウント所有者であるユーザがマネーローンサービス事業者にローンの借り換えを行う場合、借入ローン契約に関する情報を記憶させるためのデータであり、限定ではなく例として、借入残高と、借入金利と、借入返済額と、その他借入先情報とが関連付けて記憶される。
【0138】
借入残高と、借入金利と、借入返済額とは、限定ではなく例として、端末20のユーザによって入力されて登録される情報とすることができる。
【0139】
その他借入先情報には、限定ではなく例として、借入先企業名や借入ローン振込先情報を含めることができる。
借入先企業名は、限定ではなく例として、借入先の企業の名称とすることができる。
借入先企業名と、借入ローン振込先情報とは、限定ではなく例として、端末20のユーザによって入力されて登録される情報とすることができる。
なお、その他借入先情報に、借入ローン契約の契約日等の情報を含めるようにしてもよい。
【0140】
限定ではなく例として、
図1-5の例では、アプリケーションID「U0001」のユーザA.Aはマネーローンサービス事業者からまだ借入を行っていない(貸付を受けていない)ことに基づいて、貸付管理データの各項目には該当なし(NULL)を示す「-」のデータが記憶されている。また、借入登録データの各項目には、ユーザA.Aがローンの借り換えを希望している借入ローン契約として、借入先企業名「ZZ金融」から借入残高「300,000円」を借入金利「18%」で借りており、借入返済額が「¥10,000」であることが記憶されている。
【0141】
(2)端末の機能構成
図1-6は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されたアプリケーション処理プログラム281に従ってアプリケーション処理を実行するためのアプリケーション処理部211を機能部として含む。
【0142】
図1-7は、本実施例において端末20の記憶部28に記憶されるデータ等の一例を示す図である。
記憶部28には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム281と、この端末20、または端末20のユーザのアカウントに対応するアプリケーションID283とが記憶される。
なお、端末20の記憶部28に、アカウント管理データベース155Aの友だち管理データを同期させて記憶させるようにしてもよい。
【0143】
<表示画面>
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
【0144】
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
【0145】
以下では、ユーザによる操作として、限定ではなく例として、タップ(タップ操作)等を例示する。
タップ(タップ操作)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作とすることができる。
【0146】
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
【0147】
図1-8・
図1-9・
図1-10は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。なお、以下では、端末20が実行する処理を、限定ではなく例として、ユーザA.Aの端末20Aが実行する処理として図示・説明する。
【0148】
図1-8左側は、限定ではなく例として、マネーローンアプリケーションのホーム画面において借り換えプランの申し込みが選択された後に表示される、借入ローン契約の内容を受け付けるための借入先情報入力画面の一例である。
この画面では、画面最上部中央に、マネーローンアプリケーションの名称である「Money Loan App」の文字が表示されるように構成されている。
【0149】
また、その下には、マネーローンアプリケーション内での現在の位置やページ等を示す領域(以下、包括的に「アプリ内位置表示領域」と称する。)が構成されており、この例では、借入先情報入力画面であることに基づいて、「借りかえプラン申し込み」の文字が表示されている。
【0150】
アプリ内位置表示領域の下には、借入ローン契約の契約内容入力を受け付けることを示す「お借入先情報」の文字が表示されるように構成されている。その下には、借入先情報として、限定ではなく例として、借入先企業名と、借入残高と、借入金利と、借入返済額(画面上では「毎月の返済額」と表記)と、借入ローン契約の契約日とを受け付けるフォームが表示されるように構成されている。
この画面では、借入ローン契約の内容として、借入先企業名が「ZZ金融」であり、借入残高が「300,000円」、借入金利が「年利18%」、借入返済額が「10,000」円、契約日が「2020年zz月zz日」がそれぞれ入力されたことが表示されている。
【0151】
借入先情報の入力フォームに情報を入力後、限定ではなく例として、ユーザによって借入先情報確認ボタンBT1がタップされると、限定ではなく例として、
図1-8中央の借り換えプラン申し込み確認画面に表示が遷移する。
【0152】
この画面では、借り換えプラン申し込み確認画面であることを示す「申し込み確認画面」の文字がアプリ内位置表示領域に表示されている。
アプリ内位置表示領域の下には、入力された借入先情報をユーザに確認させるための借入先情報確認領域が表示されるように構成されている。借入先情報確認領域には、「お借入先情報」の文字の下に、借入先情報入力画面において入力された借入先情報が一覧で表示されている。
【0153】
また、借入先情報確認領域の右上側には、入力された借入先情報の修正を行うための「修正」の文字で示される借入先情報修正ボタンFBT1が表示されるように構成されている。
限定ではなく例として、借入先情報修正ボタンFBT1がタップされると、借入先情報入力画面に表示が戻る。
【0154】
借入先情報確認領域の下には、借り換えを行うユーザがローンサービス事業者に登録を行った各種ユーザ情報を確認するためのユーザ情報確認領域が表示されるように構成されている。
ユーザ情報確認領域では、登録済みの氏名や生年月日、電話番号といった各種ユーザ情報を確認することができる。
【0155】
ユーザ情報の修正を行う場合、限定ではなく例として、マネーローンアプリケーションのホーム画面から登録情報修正を選択することで実行することができる。
【0156】
画面最下部には、表示されている借入先情報とユーザ情報とに基づいて、借り換えプランの申し込みを行うための「借りかえプラン申し込み」の文字で示される借り換え申し込みボタンBT2が表示されるように構成されている。
【0157】
限定ではなく例として、ユーザによって借り換え申し込みボタンBT2がタップされると、限定ではなく例として、
図1-8右側の借り換えプラン申し込み完了画面に表示が遷移する。
【0158】
この借り換えプラン申し込み完了画面では、借入先情報に基づく借り換え申し込みが行われたことを示す「お申し込み手続きが完了しました」の文字の下に、申し込み受付日である「2021年11月11日」の文字が表示されるように構成されている。
その下には、申し込みが完了したことを示すチェックマークが表示されるように構成されている。
また、チェックマークの下には、申し込み審査が完了するまでユーザに待機を要請するためのメッセージが表示されるように構成されている。
画面最下部には、借り換えプランの申し込みを終了させるための「完了」の文字で示される借り換え申し込み終了ボタンBT3が表示されるように構成されている。
【0159】
限定ではなく例として、ユーザによって借り換え申し込み終了ボタンBT3がタップされると、限定ではなく例として、
図1-9左側のマネーローンアプリケーションホーム画面に表示が遷移する。
【0160】
このホーム画面では、アプリ内位置表示領域にはホーム画面であることを示す「お取引状況」の文字が表示されている。また、アプリ内位置表示領域の左側には、マネーローンアプリケーションにおける各種操作(限定ではなく例として、ローンの申し込みやユーザ情報の更新等)を行うための、横三本線で示されるメニュー表示ボタンが表示されるように構成されている。
【0161】
ホーム画面において、限定ではなく例として、アプリ内位置表示領域の下には、貸付先からの各種通知を表示させるように構成することができる。限定ではなく例として、この画面では、申し込みを行った借り換えプランの審査が完了したことを示す審査完了通知NT1が表示されている。
この審査完了通知NT1では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、審査完了通知NT1には、審査結果の確認期限が「2021年11月18日」であることを示す文字が表示されるように構成されている。
【0162】
審査完了通知NT1の下には、申し込みを行った貸付ローン契約に関する情報を表示させるための契約内容表示領域CTR1が表示されるように構成されている。
契約内容表示領域CTR1には、貸付ローン契約のプラン名である「借りかえプラン」の文字の下に、限定ではなく例として、貸付金利が表示されている。また、その下には、限定ではなく例として、貸付残高(ただし、本例の画面図では契約内容表示領域においてユーザ側に立ち「借入残高」と表記している。)と、次回返済日と、次回返済額とが表示されるように構成されている。なお、ユーザ側に立たず「貸付残高」と表示するようにしてもよい。
この画面では、契約内容表示領域CTR1の貸付金利や貸付残高等として、申し込みは受け付けたがユーザとの契約は締結されていないことに基づいて、「審査中」や「処理中」の文字が表示されている。
【0163】
また、契約内容表示領域CTR1の下には、貸付先との取引履歴を示す取引履歴表示領域THR1が表示されるように構成されている。
この画面では、端末のユーザと貸付先との間ではまだローン取引が行われていない事に基づいて、取引履歴表示領域THR1には取引履歴がまだ表示されていない。
【0164】
限定ではなく例として、ユーザによって審査完了通知NT1がタップされると、限定ではなく例として、
図1-9中央の借り換えプラン契約締結画面に表示が遷移する。
【0165】
この借り換えプラン契約締結画面では、アプリ内位置表示領域には契約締結の対象である「借り換えプラン」の文字が表示されている。
アプリ内位置表示領域の下には、後述するプレ成約条件に基づく貸付残高(画面内では「貸付金額」と表記)と、貸付金利と、貸付返済額(画面内では「毎月返済額」と表記)とを表示するためのプレ審査結果表示領域PCT1が表示されるように構成されている。
この画面では、限定ではなく例として、プレ成約条件として、貸付残高が「300,000円」、貸付金利が「14%」、貸付返済額が「9,000円」の条件が表示されてユーザに提示されている。
【0166】
また、プレ審査結果表示領域PCT1の下には、プレ成約条件として提示された貸付金利や貸付返済額は、今後の処理結果により下がることがあり得ることを示すメッセージが表示されるように構成されている。
また、その下には、プレ審査結果表示領域PCT1に表示されたプレ成約条件に基づく契約締結期限の情報(この例では、「2021年11月18日」までであることを示すメッセージ)が表示されるように構成されている。
【0167】
その下には、本借り換えプランの契約内容における、限定ではなく例として、日本国の貸金業法第16条の2に基づく規定事項が記載された規定事項表示領域ACT1が表示されるように構成されている。
規定事項表示領域ACT1の下には、チェックボックスと「上記事項を確認しました」のメッセージが表示されるように構成されている。限定ではなく例として、上記規定事項にユーザが同意する場合、チェックボックスをタップすると、チェックボックスがチェック済みとなる。
【0168】
その下には、プレ審査結果表示領域PCT1の条件に基づき借り換え契約を行うための「契約に同意」の文字で示される借り換え契約ボタンBT5と、借り換え契約に同意せず破棄するための「借りかえをやめる」の文字で示される借り換えキャンセルボタンBT4とが表示されるように構成されている。
【0169】
なお、規定事項表示領域ACT1下方のチェックボックスがチェック済みでない場合、限定ではなく例として、借り換え契約ボタンBT5はグレーアウトの表示態様で表示され、限定ではなく例として操作が無効化されるように構成することができる。
【0170】
限定ではなく例として、ユーザによって借り換え契約ボタンBT5がタップされると、限定ではなく例として、
図1-9右側の借入ローン振込先情報入力画面に表示が遷移する。
【0171】
この借入ローン振込先情報入力画面では、アプリ内位置表示領域には「返済口座登録」の文字が表示されるように構成されている。アプリ内位置表示領域の下には、貸付先が借入ローン契約を代理返済するための借入ローン振込先情報の入力をユーザに促す「他社借入先の返済用口座情報を入力してください」のメッセージが表示されるように構成されている。
【0172】
メッセージの下には、借入先情報として登録された借入先企業名である「ZZ金融」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、借入ローン振込先情報として、限定ではなく例として、金融機関名と、支店名と、口座科目と、振込先口座番号と、受取口座名義とを受け付けるフォームが表示されている。
この画面では、借入ローン振込先情報として、金融機関名が「〇×銀行」であること等がそれぞれ入力されたことが表示されている。
【0173】
借入ローン振込先情報の入力フォームに情報を入力後、限定ではなく例として、ユーザによって「口座情報登録」の文字で示される借入ローン振込先情報登録ボタンBT6がタップされると、限定ではなく例として、
図1-10左側のホーム画面に表示が遷移する。
【0174】
このホーム画面において、アプリ内位置表示領域の下には、「ZZ金融」への返済を行うための振込処理中であることを示す振込処理通知NT2が表示されている。
この振込処理通知NT2では、通知の左側にユーザに確認を促すためのベルマークアイコンが表示されるように構成されている。また、振込処理通知NT2には、この例では振込予定日が「2021年11月12日」であることを示す文字が表示されるように構成されている。
【0175】
なお、限定ではなく例として、ベルマークアイコンが表示される通知(限定ではなく例として、振込処理通知NT2)は、ユーザが確認後、限定ではなく例としてスワイプ操作を行うことによって通知をホーム画面から消去させることができるようにしてもよい。また、限定ではなく例として、エクスクラメーションアイコンが表示される通知(限定ではなく例として、審査完了通知NT1)は、限定ではなく例としてスワイプ操作を行った場合でもホーム画面から消去させることができないようにしてもよい。
【0176】
振込処理通知NT2の下には、契約内容表示領域CTR1が表示されるように構成されている。
この画面では、契約内容表示領域CTR1の貸付金利は、プレ成約条件に基づく「14%」であることが表示されている。また、貸付残高等は、借入先への振込処理が完了していないことに基づいて、「処理中」の文字が表示されている。
【0177】
限定ではなく例として、時間経過後、「2021年11月12日」となり、「ZZ金融」への振込処理が完了した場合のホーム画面の一例を
図1-10右側に示す。
【0178】
このホーム画面では、振込処理通知NT2の下に、「ZZ金融」への振込処理が完了し、後述する本成約条件が算出されたことに基づいて、貸付残高等が確定したことにより、借り換えプランの貸付金利等が更新されたことを示す契約書面再交付通知NT3が表示されている。
【0179】
また、契約内容表示領域CTR1において、貸付金利が本成約条件の「12%」に更新されたことが表示されている。そして、貸付残高が「300,000円」に確定し、次回返済日が「2021年11月26日」、次回返済金額が本成約条件の貸付返済額に基づく「9,000円」に確定したことが表示されている。
【0180】
そして、取引履歴表示領域THR1には、ユーザが「2021年11月26日」に貸付先から「300,000円」を借り入れたことを示す取引履歴が表示されている。
【0181】
なお、振込処理通知NT2と契約書面再交付通知NT3との間に、「ZZ金融」への振込処理が完了したことを示す振込処理完了通知を表示させるようにしてもよい。
【0182】
<処理>
図1-11は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0183】
なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略(削除)してもよい。
【0184】
最初に、端末20Aの制御部21は、借入先情報受付処理を実行する(A110)。
借入先情報受付処理では、限定ではなく例として、端末20Aの入出力部23に対する入力(限定ではなく例として、ユーザ入力(ユーザによる操作入力や音入力等)。以下同様。)に基づいて、端末20Aの制御部21は、借入先情報を取得する。ここで、借入先情報には、限定ではなく例として、借入先企業名と、借入残高と、借入金利と、借入返済額とを含めることができる。
【0185】
すると、端末20Aの制御部21は、借入先情報受付処理において取得した借入先情報を通信I/F22によってサーバ10に送信する(A120)。
【0186】
通信I/F14によって端末20Aから借入先情報を受信すると、サーバ10の制御部11は、借入登録データに借入先情報の借入残高等を記憶させる。
そして、サーバ10の制御部11は、借入ローン契約からの借り換えによる貸付を行うにあたって、仮の貸付ローン契約条件を算出するためのプレ成約条件算出処理を実行する(S110)。
【0187】
プレ成約条件算出処理において、サーバ10の制御部11は、限定ではなく例として、貸付残高と、貸付金利と、貸付返済額とを、限定ではなく例として、マネーローンサービスの事業者が貸付を行う場合、事業者が損をしないと想定される条件算出方法であるキャップ金利の算出理論に基づいて算出する。以下では、算出された貸付残高(以下、「キャップ貸付残高」と称する。)と、貸付金利(以下、「キャップ貸付金利」と称する。)と、貸付返済額(以下、「キャップ貸付返済額」と称する。)とを、まとめて「キャップ条件」と称する。
【0188】
なお、キャップ条件の算出において、サーバ10の制御部11は、不図示の指定信用情報機関のサーバ(以下、「指定信用情報機関サーバ」と称する。)にユーザA.Aに関する信用情報照会情報を送信する。そして、サーバ10の制御部11は、指定信用情報機関サーバからユーザA.Aに関する個人信用情報を受信すると、個人信用情報とキャップ金利の算出理論とに基づいて、キャップ条件を算出するようにしてもよいし、そうしなくてもよい。
指定信用情報機関は、限定ではなく例として、金融機関等から借入等を行っている各々のユーザの借入状況、支払い状況、契約状況などの信用情報を管理する機関として指定された機関とすることができる。
【0189】
そして、サーバ10の制御部11は、限定ではなく例として、キャップ条件と、記憶部15に記憶されるユーザA.Aのソーシャルスコアとに基づいて、以下の条件を満たす貸付残高と、貸付金利と、貸付返済額とを算出する。
・制約条件1.貸付返済額は借入返済額を上回らない
・制約条件2.貸付金利は借入金利を上回らない
これらの条件は、限定ではなく例として、貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすための条件である。
・制約条件3.貸付金利と、貸付返済額とは、キャップ条件以上である(プレ成約条件での貸付金利≧キャップ貸付金利、かつ、プレ成約条件での貸付返済額≧キャップ貸付返済額)
この条件は、限定ではなく例として、本成約条件において貸付を行う条件を優遇するためのマージンを確保するための条件である。
この制約条件3.によって、プレ成約条件よりも端末20のユーザにとって同等あるいは有利な本成約条件を算出することが可能となる。
以下では、算出された貸付残高と、貸付金利と、貸付返済額とを、「プレ成約条件」と称する。
【0190】
限定ではなく例として、ユーザA.Aのソーシャルスコアが高いほど、プレ成約条件での貸付金利とキャップ貸付金利とを近づけるようにしてもよい。また、限定ではなく例として、ユーザA.Aのソーシャルスコアが高いほど、プレ成約条件での貸付返済額とキャップ貸付返済額とを近づけるようにしてもよい。
すなわち、ユーザA.Aのソーシャルスコアが高いほど、プレ成約条件がキャップ条件に近づく(マージン:小)ようにしてもよい。逆に、ユーザA.Aのソーシャルスコアが低いほど、プレ成約条件がキャップ条件から離れる(マージン:大)ようにしてもよい。
【0191】
ユーザのソーシャルスコアが高いということは、そのユーザの信用性が高い可能性があることを意味する。このため、ユーザのソーシャルスコアが高いほど、本成約条件において貸付を行う条件が優遇されるようにすることができる。また、限定ではなく例として、マネーローンサービスを以前利用したことのあるユーザのソーシャルスコアが、以前よりも高くなっている場合は、そのユーザの信用性が以前よりも高くなっている可能性があるため、以前と比べて、本成約条件において貸付を行う条件が優遇されるようにするといったことも可能となる。
なお、ユーザのソーシャルスコアが低い場合は、これとは逆である。
【0192】
なお、ソーシャルスコアはサーバ10の記憶部15に記憶されることに限定されない。プレ契約条件の算出において、サーバ10の制御部11は、不図示のソーシャルスコアサーバにユーザA.Aのソーシャルスコア照会情報を送信する。そして、サーバ10の制御部11は、ソーシャルスコアサーバからユーザA.Aのソーシャルスコア情報を受信し、プレ成約条件を算出するようにしてもよい。
【0193】
すると、サーバ10の制御部11は、算出したプレ成約条件を含むプレ成約条件情報を通信I/F14によって端末20Aに送信する(S120)。そして、サーバ10の制御部11は、プレ成約条件として算出された貸付金利を貸付管理データに記憶させる。
なお、プレ成約条件情報に、プレ成約条件の有効期限を含めるようにしてもよい。
【0194】
なお、サーバ10の制御部11は、プレ成約条件算出処理において、ユーザA.Aのソーシャルスコア等の問題によって上記制約条件1~3のいずれか一つを満たさない場合、ユーザA.Aに対して乗り換えによる貸付を行うことが出来ないこと示す貸付成約不能情報を通信I/F14によって端末20Aに送信するようにしてもよい。この場合、端末20Aの制御部21は、受信した貸付成約不能情報を表示部24に表示させる。また、サーバ10の制御部11は、処理を終了させる。
【0195】
通信I/F22によってサーバ10からプレ成約条件情報を受信すると、端末20Aの制御部21は、受信したプレ成約条件情報を表示部24に表示させる(A130)。限定ではなく例として、表示されたプレ成約条件情報に対するユーザ入力に基づいて、ユーザA.Aが提示されたプレ成約条件で借り換えを行うことに同意したと判定する場合(A140:YES)、端末20Aの制御部21は、限定ではなく例として、ユーザ入力に基づいて借入ローン振込先情報を取得する。そして、端末20Aの制御部21は、取得した借入ローン振込先情報を含むプレ成約条件同意情報を通信I/F22によってサーバ10に送信する(A150)。
【0196】
ユーザA.Aが提示されたプレ成約条件で借り換えを行うことに同意しないと判定する場合(A140:NO)、端末20Aの制御部21は、処理を終了させる。
【0197】
なお、端末20Aの制御部11は、借入先情報受付処理(A110)において借入ローン振込先情報も取得し、借入ローン振込先情報を含む借入先情報をサーバ10に送信するようにしてもよい。
【0198】
また、端末20Aの制御部11は、サーバ10からプレ成約条件情報を受信する場合、自動的にプレ成約条件同意情報をサーバ10に送信するようにしてもよい。
【0199】
通信I/F14によって端末20Aからプレ成約条件同意情報を受信したと判定する場合(S130:YES)、サーバ10の制御部11は、代替返済振込処理を実行する(S140)。
代替返済振込処理において、サーバ10の制御部11は、マネーローンサービス事業者の金融金融口座から、借入ローン振込先情報で指定される金融機関口座(金融機関名・支店名・振込先口座番号・受取口座名義)に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信I/F14によって不図示の金融機関サーバに送信する。
金融機関において振込処理が完了すると、サーバ10の制御部11は、金融機関サーバから振込完了情報を受信する。すると、サーバ10の制御部11は、振込処理が成功した借入先について、借入登録データの各レコードを消去する。また、振込処理が成功した借入残高に基づいて、貸付管理データの貸付残高を加算する。
【0200】
なお、本実施例では、振込処理は成功することとする。振込処理に失敗する場合については後の実施例で説明する。
【0201】
代替返済振込処理が完了すると、サーバ10の制御部11は、本成約条件算出処理を実行する(S150)。
本成約条件算出処理において、サーバ10の制御部11は、代替返済振込処理において振込が完了した借入残高とその借入残高に紐づく借入金利とに基づいて、貸付残高と貸付金利と貸付返済額とを、限定ではなく例として、キャップ金利の算出理論に基づいて再度算出する。以下では、算出された貸付残高と貸付金利と貸付返済額とを、「本成約条件」と称する。
上記制約条件3.に基づいて、本成約条件では、プレ成約条件よりも貸付金利や貸付返済額が優遇される可能性がある。
また、本成約条件は制約条件1および制約条件2を自動的に満たすため、段階的借換における例外貸付の判定条件を満たす。
【0202】
すると、サーバ10の制御部11は、本成約条件に基づいて、貸付管理データの各レコードを更新する。
また、サーバ10の制御部11は、算出した本成約条件を含む本成約条件情報を通信I/F14によって端末20Aに送信する(S160)。そして、サーバ10の制御部11は、処理を終了させる。
【0203】
通信I/F22によってサーバ10から本成約条件情報を受信すると、端末20Aの制御部21は、受信した本成約条件情報を表示部24に表示させる(A160)。そして、端末20Aの制御部21は、処理を終了させる。
【0204】
なお、代替返済振込処理が完了すると、サーバ10の制御部11は、代替返済振込が終了したことを示す代替返済振込完了情報を通信I/F14によって端末20Aに送信するようにしてもよい。この場合、端末20Aの制御部21は、サーバ10から代替返済振込完了情報を受信すると、受信した代替返済振込完了情報を表示部24に表示させる。
【0205】
限定ではなく例として、プレ成約条件の有効期限を過ぎ、端末20Aからプレ成約条件同意情報を受信しないと判定する場合(S130:NO)、サーバ10の制御部11は、処理を終了させる。
【0206】
なお、サーバ10の制御部11は、S160のステップをスキップするようにしてもよい。また、端末20Aの制御部21は、A160のステップをスキップするようにしてもよい。
この場合、端末20Aの制御部21は、A150のステップを実行すると、限定ではなく例として、ユーザ入力に基づいて、任意のタイミングで条件照会情報を通信I/F22によってサーバ10に送信する。サーバ10の制御部11は、端末20Aから条件照会情報を受信したと判定する場合、本成約条件算出処理が終了しているならば本成約条件情報を、本成約条件算出処理が終了していない場合には振込処理中である旨の情報を端末20Aに送信するようにしてもよい。そして、端末20Aの制御部21は、サーバ10から受信した本成約条件情報または振込処理中である旨の情報を表示部24に表示させる。
【0207】
また、サーバ10の制御部11は、S120~S130のステップを省略するようにしてもよい。
【0208】
また、プレ成約条件の算出においてソーシャルスコアを用いることは必須ではなく、これを用いなくてもよい。
限定ではなく例として、ソーシャルスコアに関係なく、「プレ成約条件の貸付金利=借入金利」としてもよい。また、限定ではなく例として、ソーシャルスコアに関係なく、設定された割合(マネーローンサービス事業者が得る利益を考慮するなどして決めてもよい。)だけ借入金利から利率を下げた金利をプレ成約条件の貸付金利として算出するようにしてもよい。
【0209】
<第1実施例の効果>
本実施例は、サーバ10(限定ではなく、ユーザの端末と通信するサーバの一例)は、端末20のユーザが第1企業から借りた金銭の情報を含む借入先情報(限定ではなく、第1情報の一例)を端末20から受信する通信I/F14を備える。また、サーバ10は、受信した借入先情報に基づいて、端末20のユーザが借りた金銭の借り換えに関する金利の情報を含むプレ制約条件情報(限定ではなく、第1金利情報の一例)を算出(限定ではなく、取得の一例)する制御部11を備える。そして、制御部11は、受信した借入先情報に基づき、第1企業に金銭を支払う代替返済振込処理(限定ではなく、支払い処理の一例)を行い、その支払い処理に基づいて、端末20のユーザが借りた金銭の借り換えに関する金利の情報を含む本成約条件情報(限定ではなく、第2金利情報の一例)を算出(限定ではなく、取得の一例)する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、端末のユーザが第1企業から借りた金銭の情報を含む第1情報を端末から受信した上で、受信した第1情報に基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報を取得することができる。また、その上で、サーバは、受信した第1情報に基づき、第1企業に金銭を支払った上で、その支払いに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得することができる。これにより、端末のユーザが第1企業から借りた金銭の借り換えを可能にするとともに、端末のユーザに適切な金利を提示することができる。また、限定ではなく例として、第2金利情報の金利が第1金利情報の金利と等しいか、それよりも低くなるように第1金利情報を算出するといったことも可能となる。
【0210】
また、本実施例は、サーバ10の制御部11は、プレ成約条件情報(限定ではなく、第1金利情報の一例)を通信I/F14によって端末20に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、取得した第1金利情報を端末に送信することができる。これにより、限定ではなく例として、取得した第1金利情報に含まれる金利の情報を端末のユーザに知らせることができる。
【0211】
また、本実施例は、算出(限定ではなく、取得の一例)されたプレ成約条件情報は、端末20のユーザによる承諾に基づいて決定される構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザによる承諾があった場合に、取得された第1金利情報で決定することができる。
【0212】
<第1変形例(1)>
上記の実施例では、プレ成約条件算出処理と、本成約条件算出処理とがサーバ10の制御部11において行われることとしたが、これに限定されない。限定ではなく例として、プレ成約条件算出処理または本成約条件算出処理、もしくはその両方の処理を、不図示のマネーローンサービス事業者基幹系サーバ(以下、「基幹サーバ」と称する。)において実行するようにしてもよい。
【0213】
プレ成約条件算出処理を基幹サーバにおいて実行する場合、限定ではなく例として、サーバ10の制御部11は、借入先情報を端末20から受信すると、受信した借入先情報を基幹サーバに送信する。そして、基幹サーバの制御部は、サーバ10から受信した借入先情報に基づいて、プレ成約条件算出処理を実行し、算出されたプレ成約条件情報をサーバ10に送信する。
サーバ10の制御部11は、基幹サーバからプレ成約条件情報を受信すると、受信したプレ成約条件情報を端末20Aに送信する。
【0214】
本成約条件算出処理を基幹サーバにおいて実行する場合、限定ではなく例として、サーバ10の制御部11は、代替返済振込完了情報を基幹サーバに送信する。そして、基幹サーバの制御部は、サーバ10から受信した代替返済振込完了情報に基づいて、本成約条件算出処理を実行し、算出された本成約条件情報をサーバ10に送信する。
サーバ10の制御部11は、基幹サーバから本成約条件情報を受信すると、受信した本成約条件情報を端末20に送信する。
【0215】
なお、代替返済振込処理を基幹サーバにおいて実行するようにしてもよい。
この場合、限定ではなく例として、サーバ10の制御部11は、端末20からプレ成約条件同意情報を受信すると、受信したプレ成約条件同意情報に基づいて、借入ローン振込先情報を基幹サーバに送信する。基幹サーバの制御部は、サーバ10から借入ローン振込先情報を受信すると、代替返済振込処理を実行する。
代替返済振込処理が完了すると、基幹サーバの制御部は、代替返済振込完了情報をサーバ10に送信する。
【0216】
すなわち、本変形例は、限定ではなく例として、マネーローンアプリケーションのフロントエンド処理をサーバ10において実行し、バックエンド処理を基幹サーバにおいて実行する例とすることができる。
また、本変形例は、限定ではなく例として、サーバ10が、第1金利情報や第2金利情報を自装置で算出して取得するのではなく外部から取得する例とすることができる。
【0217】
<第1変形例(2)>
上記の実施例では、代替返済振込処理において金融機関口座間での振込(振替)を実行したが、これに限定されない。限定ではなく例として、借入先が電子マネーでの返済に対応している場合、代替返済振込処理においてマネーローンサービス事業者の電子マネー口座から、借入ローン振込先情報で指定される返済用電子マネー口座に電子マネーの送金を行うようにしてもよい。
電子マネーの送金の処理も、振込(振替)の処理と同様に、サーバ10が行う支払い処理の一例とすることができる。
【0218】
<第1変形例(3)>
上記の実施例では、プレ成約条件算出処理において、制約条件1~3を満たすようにプレ成約条件を求めたが、これに限定されない。限定ではなく例として、制約条件1~2のみを満たすようにプレ成約条件を求めるようにしてもよい。
【0219】
この場合、プレ成約条件での貸付金利よりも本成約条件での貸付金利が高くなる、または、プレ成約条件での貸付返済額よりも本成約条件での貸付返済額が高くなる、あるいはその両方を満たす可能性がある。しかし、本成約条件が制約条件1~2を満たす限りにおいて、例外貸付の判定条件は満たされている。
【0220】
そのため、この場合、サーバ10の制御部11は、プレ成約条件算出処理の後、限定ではなく例として、プレ成約条件よりも貸付金利や貸付返済額が上がる可能性があることを含むプレ成約条件情報を端末20Aに送信するようにすることができる。
【0221】
そして、サーバ10の制御部11は、端末20Aからプレ成約条件同意情報を受信したと判定し(S130:YES)、本成約条件算出処理の後、限定ではなく例として、制約条件1~2を満たし、かつプレ成約条件よりも本成約条件において端末20のユーザが冷遇される(貸付金利が上がる、または貸付返済額が増額される、もしくはその両方)場合、更新された本成約条件を含む本成約条件情報を通信I/F14によって端末20Aに送信するようにしてもよい。
【0222】
<第2実施例>
第1実施例では、端末20において入力された借入先情報を検証・判定することなく代替返済振込を実行する例を例示した。
第2実施例は、端末20のユーザが申告した借入先情報を照会し、申告が正しいか否かを検証・判定する実施例である。
【0223】
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0224】
<表示画面>
図2-1~
図2-2は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
本画面図では、限定ではなく例として、借入企業名「ZZ金融」からの借入残高が実際には「290,000円」であるにも関わらず、借入先情報としてユーザが借入残高を「300,000円」であると申告した例を示す。
なお、これはあくまでも一例であり、この例に限定されるものではない。
【0225】
図2-1左側には、限定ではなく例として、
図1-9右側の借入ローン振込先情報入力画面において借入ローン振込先情報登録ボタンBT6がタップされると表示される、マネーローンアプリケーションホーム画面の一例を示している。
【0226】
後述する借入先照会処理の処理結果に基づいて、ホーム画面には借入先確認要請通知NT4が表示されている。
借入先確認要請通知NT4では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側には入力された借入先情報に不備が発見されたことを示す「登録された情報に不備が見つかりました」のメッセージが表示されるように構成されている。また、借入先確認要請通知NT4には、借入先情報の確認期限が「2021年11月19日」であることを示す文字が表示されている。
【0227】
限定ではなく例として、ユーザによって借入先確認要請通知NT4がタップされると、限定ではなく例として、
図2-1中央の残高証明書提出画面に表示が遷移する。
【0228】
この残高証明書提出画面では、アプリ内位置表示領域には借入先情報確認の対象である「借り換えプラン」の文字が表示されている。
アプリ内位置表示領域の下には、正確な借入先情報を取得するためにユーザに残高証明書の提出を促すための「残高証明書の提出が必要です」のメッセージが表示されている。その下には、残高証明書の提出が必要な借入先を示す借入先照合ボタンLC1が表示されるように構成されている。
【0229】
借入先照合ボタンLC1の中央には、再照会対象となった借入先企業名である「ZZ金融」の文字が表示されるように構成されている。また、借入先照合ボタンLC1の左下側には、残高証明書の情報が未登録であることを示す「未登録」の文字で示すアイコンが表示されるように構成されている。
【0230】
また、残高証明書提出画面の下部には、残高証明書の提出期限を示すメッセージが表示されるように構成されている。この例では、提出期限は「2021年11月19日」までであることが表示されている。
【0231】
その下には、残高証明書に関する情報を送信するための「提出する」の文字で示される証明書提出ボタンBT7が表示されるように構成されている。この画面では、借入先照合ボタンLC1で確認できるように未登録の借入先が存在することに基づいて、限定ではなく例として、証明書提出ボタンBT7はグレーアウトの表示態様で表示され、無効化されている。
【0232】
限定ではなく例として、ユーザによって借入先照合ボタンLC1がタップされると、限定ではなく例として、
図2-1右側の証明書取得画面に表示が遷移する。
【0233】
この証明書取得画面では、アプリ内位置表示領域には証明書提出ボタンがタップされたことに基づいて、「証明書提出」の文字が表示されている。
証明書取得画面の中央部には、限定ではなく例として、ユーザによって証明書撮影ボタンBT8がタップされ、撮像部27によって残高証明書が撮像されたことにより、「撮影済み書類」の文字の下に撮像された書類の画像が表示されるように構成されている。
また、撮像が行われたことに基づいて、証明書撮影ボタンBT8内部の文字が「撮影する」から「撮影しなおす」の文字へと変化している。
【0234】
証明書撮影ボタンBT8の下には、撮像した画像を証明書の画像として登録するための「登録」の文字で示される証明書登録ボタンBT9が表示されるように構成されている。なお、書類の画像が撮像されていない場合、限定ではなく例として、証明書登録ボタンBT9は、グレーアウトの表示態様で表示され、無効化されるようにすることができる。
【0235】
限定ではなく例として、ユーザによって証明書登録ボタンBT9がタップされると、限定ではなく例として、
図2-2左側の残高証明書提出画面に表示が遷移する。
【0236】
この残高証明書提出画面では、証明書の画像が取得されたことに基づいて、借入先照合ボタンLC1内のアイコンが「未登録」アイコンから「登録済み」アイコンに変更されている。また、証明書提出ボタンBT7はグレーアウトの表示態様が解除され、有効化されている。
【0237】
なお、本画面図とは異なり、借入先照合ボタンLC1がタップされると、借入先情報入力画面が表示され、入力フォームへの入力により再度借入先情報を取得しなおすように構成するようにしてもよい。
【0238】
限定ではなく例として、ユーザによって証明書提出ボタンBT7がタップされると、限定ではなく例として、
図2-2中央のホーム画面に表示が遷移する。
【0239】
このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、証明書の画像を送信したことにより再度借入先情報の照合が行われ、借入先情報の不整合が解消したことを示す借入先情報照合確認通知NT5が表示されている。
また、借入先情報照合確認通知NT5の下には、照合された借入先情報に基づいて、代替返済振込処理を実行していることを示す振込処理通知NT2が表示されている。
【0240】
限定ではなく例として、時間経過後、「2021年11月12日」となり、「ZZ金融」への振込処理が完了した場合のホーム画面の一例を
図2-2右側に示す。
【0241】
このホーム画面では、アプリ内位置表示領域の下に、「ZZ金融」への振込処理が完了したことを示す振込処理完了通知NT6が表示されている。また、振込処理完了通知NT6の下には、本成約条件が算出されたことに基づいて、契約書面再交付通知NT3が表示されている。
【0242】
また、契約内容表示領域CTR1において、貸付金利が本成約条件の「12%」に更新されたことが表示されている。そして、貸付残高が証明書の画像に基づく「290,000円」に確定し、次回返済日が「2021年11月26日」、次回返済金額が本成約条件の貸付返済額に基づく「8,700円」に確定したことが表示されている。
【0243】
そして、取引履歴表示領域THR1には、ユーザが「2021年11月26日」に貸付先から「290,000円」を借り入れたことを示す取引履歴が表示されている。
【0244】
<処理>
図2-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0245】
限定ではなく例として、端末20Aからプレ成約条件同意情報を受信したと判定する場合(S130:YES)、サーバ10の制御部11は、借入先照会処理を実行する(S210)。
【0246】
借入先照会処理において、サーバ10の制御部11は、限定ではなく例として、借り換えを行うユーザA.Aの個人信用情報を照会するための信用情報照会情報を通信I/F14によって、前述した不図示の指定信用情報機関サーバに送信する。そして、サーバ10の制御部11は、指定信用情報機関サーバからユーザA.Aに関する個人信用情報を受信すると、個人信用情報に記録されたユーザA.Aの借入資金残高等を借入先情報と照合する。
【0247】
限定ではなく例として、個人信用情報の借入先及び借入資金残高と、借入先情報とが一致している場合、借入先照会処理の実行結果は正常と判断され(S210:正常)、サーバ10の制御部11は、S140以降のステップを実行する。
【0248】
通信I/F22によってサーバ10から本成約条件情報を受信したと判定する場合(A210:YES)、端末20Aの制御部21は、受信した本成約条件情報を表示部24に表示させる(A160)。本成約条件情報を受信しないと判定する場合(A210:NO)、端末20Aの制御部21は、A160のステップをスキップさせる。
【0249】
限定ではなく例として、個人信用情報の借入先及び借入資金残高と、借入先情報とが食い違っている場合、サーバ10の制御部11は、借入先照会処理の実行結果は異常と判断し(S210:異常)、処理を終了させる。
【0250】
なお、借入先照会処理の実行結果が異常と判断される場合、サーバ10の制御部11は、借入先情報の再入力を求める借入先確認要請情報を通信I/F14によって端末20Aに送信するようにしてもよい。そして、端末20Aの制御部21は、借入先確認要請情報を受信すると、受信した借入先確認要請情報を表示部24に表示させる。借入先確認要請情報に対するユーザ入力に基づいて、借入先情報が再入力されると、端末20Aの制御部21は、再入力された借入先情報を通信I/F22によってサーバ10に送信する。
【0251】
ここで、借入先情報の再入力方法として、端末20Aの制御部21は、撮像部27によって借入ローン契約の契約書や残高証明書を撮像し、取得した画像を借入先情報に含めて送信するようにしてもよい。
【0252】
端末20Aから借入先情報を再受信すると、サーバ10の制御部11は、再度借入先照会処理を実行するようにしてもよい。借入先情報に契約書や残高証明書の画像が含まれる場合、サーバ10の制御部11は、OCR処理を行い借入ローン契約の借入残高等を取得するようにしてもよい。なお、サーバ10の制御部11は、借入先情報の画像を表示部13に表示させるようにしてもよい。そして、サーバ10のユーザが表示された画像を目視することにより借入先照会処理の実行結果を入出力部12によって入力するようにしてもよい。
【0253】
なお、借入先照会処理の実行結果が異常と判断される場合、サーバ10の制御部11は、借入先確認要請情報を表示部13に表示させるようにしてもよい。そして、サーバ10のユーザは、表示された借入先確認要請情報に基づいて、電話等の手段で端末20のユーザに連絡し、借入先情報の再照合を行うようにしてもよい。
【0254】
<第2実施例の効果>
本実施例は、サーバ10の制御部11が、借入先情報(限定ではなく、第1情報の一例)に含まれる第1企業に金銭を支払うための情報に誤りがなかった場合、本成約条件情報(限定ではなく、第2金利情報の一例)を取得する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、第1情報に含まれる第1企業に金銭を支払うための情報に誤りがなかった場合、第2金利情報を取得することができる。限定ではなく例として、支払いに必要な情報(限定ではなく例として、支払い先の口座の情報等)に誤りがなかった場合や、端末のユーザによって提供された支払いを行うための情報に?偽りがなかったような場合に、第2金利情報を取得するといったことが可能となる。
【0255】
また、本実施例は、サーバ10の制御部11が、限定ではなく例として、指定信用情報機関のサーバ等の装置に記憶されたデータに基づいて、借入先情報(第1情報)に含まれる第1企業に関する情報の正否を判別する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第1企業から借りた金銭の情報を含む第1情報に含まれる第1企業に関する情報の正否を、記憶されたデータに基づいて簡易かつ適切に判別することができる。
【0256】
また、本実施例は、サーバ10が端末20から受信する借入先情報は、端末20の撮像部27によって撮像された画像の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末の撮像部によって撮像された画像の情報を含む、端末のユーザが第1企業から借りた金銭の情報を含む第1情報を受信することができる。また、金銭の借り入れに関する情報が端末で撮像されることによって第1情報がサーバに送信されるようにすることができ、金銭の借り入れに関する情報を端末のユーザが手入力せずに済むため、端末側(ユーザ側)の視点ではユーザにとって便利である。
【0257】
<第2変形例(1)>
上記の実施例では、端末20Aからプレ成約条件同意情報を受信したと判定する場合(S130:YES)、サーバ10の制御部11は、借入先照会処理を実行することとしたが、これに限定されない。限定ではなく例として、サーバ10の制御部11は、端末20Aから借入先情報を受信すると、プレ成約条件算出処理に先んじて借入先照会処理を実行するようにしてもよい。
【0258】
この場合、サーバ10の制御部11は、借入先照会処理の実行結果は正常と判断すると、プレ成約条件算出処理以降の処理が実行するようにしてもよい。また、サーバ10の制御部11は、借入先照会処理の実行結果が異常と判断すると、プレ成約条件を算出せずに貸付成約不能情報を通信I/F14によって端末20Aに送信するようにしてもよい。なお、サーバ10の制御部11は、借入先照会処理の実行結果が異常と判断すると、借入先確認要請情報を通信I/F14によって端末20Aに送信するようにしてもよい。
【0259】
<第2変形例(2)>
上記の実施例では、借入先照会処理において、借り換えを行うユーザの個人信用情報と借入先情報の借入残高等とを照合することとしたが、これに限定されない。限定ではなく例として、借入先情報の借入ローン振込先情報が適切か否かを照会するようにしてもよい。
【0260】
この場合、限定ではなく例として、借入先企業名と、受取口座名義とが一致している場合、借入先照会処理が正常であると判定するように構成することができる。
【0261】
なお、サーバ10の制御部11は、他のユーザの借り換えに伴う借入ローン振込先情報を蓄積して記憶部15に記憶させ、借入ローン振込先データベースを構築するようにしてもよい。そして、サーバ10の制御部11は、借入先照会処理において、借入ローン振込先データベースを参照し、借入先企業名と、金融機関名・支店名が過去の履歴と合致する場合、借入先照会処理が正常であるように構成するようにしてもよい。
【0262】
また、サーバ10の制御部11は、金融機関名と対応する銀行サーバに支店名・振込先口座番号とを含む名義照会情報を送信するようにしてもよい。銀行サーバは名義照会情報を受信すると、銀行サーバの記憶部に記憶される口座管理データベースを参照し、振込先口座番号の名義である口座名義情報をサーバ10に送信する。そして、サーバ10の制御部11は、受信した口座名義情報と借入ローン振込先情報の受取口座名義とが合致する場合、借入先照会処理が正常であるように構成するようにしてもよい。
【0263】
<第3実施例>
上記の実施例では、限定ではなく例として、借入ローン契約を一の契約として例示した。
第3実施例は、限定ではなく例として、端末20のユーザが、複数の借入ローン契約をマネーローンサービス事業者の提供するローンに借り換える実施例である。なお、本実施例では、サーバ10が行う振込処理は成功することとする。サーバ10が行う振込処理が失敗する場合については、第4実施例で説明する。
【0264】
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0265】
図3-1は、本実施例におけるアカウント管理データベース155の一例であるアカウント管理データベース155Bのデータ構成例である。
アカウント管理データベース155Bには、アカウントごとの管理データとして、アカウント管理データが記憶される。
【0266】
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、貸付管理データと、借入先登録データとが記憶される。
アプリケーションIDと、貸付管理データとは、限定ではなく例として、アカウント管理データベース155Aと同様に構成することができる。
【0267】
借入先登録データには、限定ではなく例として、借入先IDと、借入残高と、借入金利と、借入返済額と、その他借入先情報とが関連付けて記憶される。
【0268】
借入先IDは、借入ローン契約を識別するための情報である。
この借入先IDは、好ましくは借入ローン契約ごとに一意な値であり、限定ではなく例として、サーバ10が借入先情報を受信すると、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶されるようにすることができる。
【0269】
以下では、限定ではなく例として、借入登録データのn行目(「n」は自然数)に登録される借入先を「第n借入先」と称する。そして、「第n借入先」からの借入ローン契約を「第n借入ローン契約」、借入先情報を「第n借入先情報」、借入ローン振込先情報を「第n借入ローン振込先情報」とそれぞれ称する。
【0270】
<表示画面>
図3-2~
図3-3は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
【0271】
本表示画面では、限定ではなく例として、借入ローン契約が2つの例について例示する。以下では、借入先企業名「XX信販」との借入ローン契約を「第1借入ローン契約」、借入先企業名「YYローン」との借入ローン契約を「第2借入ローン契約」として区別することとする。なお、第1借入ローン契約と第2借入ローン契約との借入先は同じ企業としてもよい。
【0272】
図3-2左側は、限定ではなく例として、
図1-8左側の借入先情報入力画面の別例である。
この借入先情報入力画面では、アプリ内位置表示領域の下に、第1借入先情報を受け付けることを示す「お借入先情報1」の文字が表示されている。その下には、第1借入先情報を受け付けるフォームが表示されている。
この画面では、第1借入ローン契約の内容として、借入先企業名が「XX信販」であり、借入残高が「100,000円」、借入金利が「年利10%」、借入返済額が「10,000」円、契約日が「2020年xx月xx日」がそれぞれ入力されたことが表示されている。
【0273】
借入先情報の入力フォームの下には、他の借入ローン契約をまとめて借り換え希望するか否かを確認するための「その他に借りかえたいお借入先はございますか?」のメッセージが表示されるように構成されている。
メッセージの下には、第1借入ローン契約のみ借り換えを行うための「いいえ」の文字で示される借入先確認ボタンBT10と、他の借入ローン契約に関する借入先情報を入力するための「はい」の文字で示される他借入先情報入力ボタンBT11とが表示されるように構成されている。
【0274】
限定ではなく例として、ユーザによって他借入先情報入力ボタンBT11がタップされると、再度借入先情報入力画面が表示されるように構成されている。
この画面では、第2借入先情報を受け付けることを示す「お借入先情報2」の文字が表示され、その下には、第2借入先情報を受け付けるフォームが表示される。
この例では、第2借入ローン契約の内容として、借入先企業名が「YYローン」であり、借入残高が「600,000円」、借入金利が「年利15%」、借入返済額が「20,000」円、契約日が「2020年yy月yy日」がそれぞれ入力されることとする。
【0275】
その後、限定ではなく例として、ユーザによって借入先確認ボタンBT10がタップされると、限定ではなく例として、
図3-2中央の借り換えプラン申し込み確認画面に表示が遷移する。この借り換えプラン申し込み確認画面は、限定ではなく例として、
図1-8中央の借り換えプラン申し込み確認画面の別例である。
【0276】
この画面では、借入先情報確認領域に、「お借入先情報1」の文字の下に、第1借入先情報が一覧で表示されるように構成されている。また、「お借入先情報2」の文字の下に、第2借入先情報が一覧で表示されるように構成されている。
また、第1借入先情報の修正を行うための第1借入先情報修正ボタンFBT2と、第2借入先情報の修正を行うための第2借入先情報修正ボタンFBT3とがそれぞれ表示されるように構成されている。
限定ではなく例として、第1借入先情報修正ボタンFBT2がタップされると、第1借入先情報の入力画面に表示が戻り、第2借入先情報修正ボタンFBT3がタップされると、第2借入先情報の入力画面に表示が戻る。
【0277】
なお、ユーザによって3以上の借入先が指定された場合には、同様に、「お借入先情報n(「n」は自然数)」の文字の下に、第n借入先情報が一覧で表示されるように構成するようにしてもよい。
【0278】
限定ではなく例として、ユーザによって借り換え申し込みボタンBT12がタップされると、限定ではなく例として、
図3-2右側の借り換えプラン申し込み完了画面に表示が遷移する。
【0279】
そして、限定ではなく例として、ユーザによって借り換え申し込み終了ボタンBT13がタップされると、マネーローンアプリケーションホーム画面に表示が遷移する。
【0280】
限定ではなく例として、ホーム画面において、ユーザによって審査完了通知がタップされると、限定ではなく例として、
図3-3左側の借り換えプラン契約締結画面に表示が遷移する。
【0281】
この画面では、プレ審査結果表示領域PCT2には、限定ではなく例として、プレ成約条件として、貸付残高が「700,000円」、貸付金利が「14%」、貸付返済額が「23,000円」の条件が表示されてユーザに提示されている。
【0282】
限定ではなく例として、ユーザによって借り換え契約ボタンBT14がタップされると、限定ではなく例として、
図3-3中央の借入ローン振込先情報入力画面に表示が遷移する。この借入ローン振込先情報入力画面は、限定ではなく例として、
図1-9右側の借入ローン振込先情報入力画面の別例である。
【0283】
この借入ローン振込先情報入力画面では、第1借入先情報として登録された借入先企業名である「XX信販」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、第1借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。
【0284】
また、第1借入ローン振込先情報の入力フォームの下には、第2借入先情報として登録された借入先企業名である「YYローン」の文字が「お借入先会社名」の文字と共に表示されるように構成されている。その下には、第2借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。
【0285】
なお、ユーザによって3以上の借入先が指定された場合には、同様に、第n借入先情報として登録された借入先企業名の下に、第n借入ローン振込先情報を受け付けるフォームが表示されるように構成するようにしてもよい。
【0286】
各借入ローン振込先情報を受け付けるフォームに情報を入力後、限定ではなく例として、ユーザによって借入ローン振込先情報登録ボタンBT15がタップされると、限定ではなく例として、
図3-3右側のホーム画面に表示が遷移する。
【0287】
このホーム画面では、アプリ内位置表示領域の下に、「XX信販」への振込処理が完了したことを示す振込処理完了通知NT7と、「YYローン」への振込処理が完了したことを示す振込処理完了通知NT8とが表示されている。
それらの通知の下には、本成約条件が算出されたことに基づいて、契約書面再交付通知NT9が表示されている。
【0288】
また、契約内容表示領域CTR2において、貸付金利が本成約条件の「13%」に更新されたことが表示されている。そして、貸付残高が「700,000円」に確定し、次回返済日が「2021年11月26日」、次回返済金額が本成約条件の貸付返済額に基づく「23,000円」に確定したことが表示されている。
【0289】
そして、取引履歴表示領域THR2には、ユーザが「2021年11月13日」に貸付先から「700,000円」を借り入れたことを示す取引履歴が表示されている。
【0290】
<処理>
処理については、限定ではなく例として、
図2-3のフローチャートに従って実行することができる。
なお、以下では、第n借入先情報(「n」は自然数)に含まれる借入残高を「第n借入残高」、借入金利を「第n借入金利」、借入返済額を「第n借入返済額」とそれぞれ称する。
【0291】
端末20Aの制御部21は、第1借入先情報と第2借入先情報とを受け付けると(A110)、第1借入先情報と第2借入先情報とを含む借入先情報を通信I/F22によってサーバ10に送信する(A120)。
【0292】
プレ成約条件算出処理(S110)において、サーバ10の制御部11は、キャップ条件を算出すると、限定ではなく例として、キャップ条件と、記憶部15に記憶されるユーザA.Aのソーシャルスコアとに基づいて、以下の条件を満たすプレ成約条件の貸付残高と、貸付金利と、貸付返済額とを算出する。なお、前述したように、ソーシャルスコアを用いることは必須ではない。
・制約条件1′.貸付返済額は、第1借入返済額と第2借入返済額との合計額(以下、「合計借入返済額」と称する。)を上回らない。
すなわち、「合計借入返済額≧貸付返済額」
ここで、合計借入返済額は、限定ではなく例として、以下のように算出することができる。
「合計借入返済額=第1借入返済額+第2借入返済額」
・制約条件2′.貸付金利は、借り換えで返済される借入ローン契約の金利を貸付残高に基づいて平均した金利(以下、「加重平均借入金利」と称する。)を上回らない。
すなわち、「加重平均借入金利≧貸付金利」
ここで、加重平均借入金利は、限定ではなく例として、以下のように算出することができる。
「加重平均借入金利=(第1借入残高×第1借入金利+第2借入残高×第2借入金利)÷(第1借入残高+第2借入残高)」
【0293】
なお、合計借入返済額と加重平均借入金利とは、上記の式による算出方法に限定されない。限定ではなく例として、合計借入返済額を各借入残高とそれに紐付く借入金利とを用いて算出するようにしてもよいし、そうしなくてもよい。また、限定ではなく例として、加重平均借入金利を各借入金利の単純平均で算出するようにしてもよいし、そうしなくてもよい。
【0294】
制約条件1′と制約条件2′との条件は、限定ではなく例として、貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすための条件である。
【0295】
・制約条件3.貸付金利と、貸付返済額とは、キャップ条件以上である
すなわち、「貸付金利≧キャップ貸付金利」かつ「貸付返済額≧キャップ貸付返済額」
この条件は、限定ではなく例として、借り換えのうち一部が適切に実行できない場合を考慮するためのマージンを確保するための条件である。
【0296】
借入先照会処理(S210)において、サーバ10の制御部11は、限定ではなく例として、個人信用情報の各々の借入先及び借入資金残高と、第1借入先情報と第2借入先情報との内容が一致している場合、借入先照会処理の実行結果は正常と判断し(S210:正常)、S140以降のステップを実行する。
【0297】
代替返済振込処理(S140)において、サーバ10の制御部11は、マネーローンサービス事業者の金融金融口座から、第1借入ローン振込先情報で指定される金融機関口座に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信I/F14によって不図示の金融機関サーバに送信する。
同様に、サーバ10の制御部11は、マネーローンサービス事業者の金融金融口座から、第2借入ローン振込先情報で指定される金融機関口座に対して、プレ成約条件で求められた貸付金額の振込または振替を行うための振込依頼情報を通信I/F14によって不図示の金融機関サーバに送信する。
【0298】
各々の金融機関において振込処理が完了すると、サーバ10の制御部11は、金融機関サーバから振込完了情報を受信する。すると、サーバ10の制御部11は、振込処理が成功した借入先IDの借入先について、借入登録データの各レコードを消去する。また、振込処理が成功した借入残高に基づいて、貸付管理データの貸付残高を加算する。
なお、本実施例では、前述したように、振込処理は成功することとする。
【0299】
本成約条件算出処理(S150)において、サーバ10の制御部11は、代替返済振込処理において振込が完了した各借入残高とその借入残高に紐づく借入金利とに基づいて、本成約条件を再度算出する。
上記制約条件3.に基づいて、本成約条件では、プレ成約条件よりも貸付金利や貸付返済額が優遇される可能性がある。
【0300】
また、上記とは異なる計算方法でプレ成約条件や本成約条件を算出することも可能であり、いずれの計算方法を用いてもよい。これは、制約条件3を用いない手法と考えてもよいものとする。なお、処理の流れ(フロー)は、上記の処理と同様とすることができる。
【0301】
限定ではなく例として、
図2-3のプレ成約条件算出処理(S110)において、サーバ10の制御部11は、記憶部15に記憶されるユーザA.Aのソーシャルスコアに基づいて、限定ではなく例として、以下のようにプレ成約条件の貸付金利を算出する。
「プレ成約条件の貸付金利」=「加重平均借入金利」×「ユーザ係数」
【0302】
ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値(限定ではなく例として、平均値)より大きい場合、「1」より小さい値をとり、ソーシャルスコアが所定値より小さい場合、「1」より大きい値をとる、正の係数であるようにしてもよい。なお、ユーザ係数は、限定ではなく例として、ソーシャルスコアが所定値である場合、「1」をとるようにしてもよい。
【0303】
なお、ユーザ係数は、限定ではなく例として、ユーザA.Aの信用情報に基づいて算出されるようにしてもよい。
【0304】
また、前述したように、ソーシャルスコアを用いることは必須ではなく、これを用いないようにしてもよい。
限定ではなく例として、ソーシャルスコアに関係なく、「加重平均借入金利=プレ成約条件の貸付金利」としてもよい。また、限定ではなく例として、ソーシャルスコアに関係なく、設定された割合(マネーローンサービス事業者が得る利益を考慮するなどして決めてもよい。)だけ加重平均借入金利から利率を下げた金利をプレ成約条件の貸付金利として算出するようにしてもよい。
【0305】
また、プレ成約条件の貸付金利を、以下のように算出するようにしてもよい。
「プレ成約条件の貸付金利」=「加重平均借入金利」-「ユーザ係数」
ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値(限定ではなく例として、平均値-分散値)より大きい場合、「0」より大きい値をとる、正の係数であるようにしてもよい。
【0306】
そして、サーバ10の制御部11は、限定ではなく例として、算出されたプレ成約条件の貸付金利に基づいて、「合計借入返済額≧プレ成約条件の貸付返済額」となるようにプレ成約条件の貸付返済額と貸付残高とを算出する。
【0307】
また、
図2-3の本成約条件算出処理(S150)において、サーバ10の制御部11は、限定ではなく例として、上記のようにして算出したプレ成約条件の貸付金利と等しい本成約条件の貸付金利を算出する。
【0308】
なお、「N=1」とすることで、第1実施例や第2実施例で説明した借り入れが1つの契約の場合についても、上記の計算方法を同様に適用可能である。
【0309】
また、第2実施例では、端末20のユーザが申告した借入先情報を照会し、申告が正しいか否かを検証・判定する実施例について説明したが、第3実施例で説明した内容をこれと組み合わせて適用することも可能である。
具体的には、
図2-3の処理を上記の実施例に適用し、S210の借入先紹介処理において、サーバ10の制御部11は、限定ではなく例として、借り換えを行うユーザA.Aの個人信用情報を照会するための信用情報照会情報を通信I/F14によって、前述した不図示の指定信用情報機関サーバに送信する。そして、サーバ10の制御部11は、指定信用情報機関サーバからユーザA.Aに関する個人信用情報を受信すると、個人信用情報に記録されたユーザA.Aの借入資金残高等を、端末20Aから受信した第1借入先情報と第2借入先情報と照合する。そして、第1借入先と第2借入先との各々について、個人信用情報の借入先及び借入資金残高と、借入先情報(第1借入先情報、第2借入先情報)とが一致している場合、借入先照会処理の実行結果は正常と判断され(S210:正常)、サーバ10の制御部11は、S140以降のステップを実行する。
【0310】
<第3実施例の効果>
本実施例は、サーバ10の通信I/F14は、端末20のユーザが第1企業から借りた金銭の情報を含む第1借入先情報(限定ではなく、第1情報の一例)と、端末20のユーザが第2企業から借りた金銭の情報を含む第2借入先情報(限定ではなく、第2情報の一例)とを端末20から受信する。そして、サーバ10の制御部11は、第1借入先情報と第2借入先情報とに基づいて、プレ成約条件情報(限定ではなく、第1金利情報の一例)を取得し、第1借入先情報と第2借入先情報とに基づき、第1企業と第2企業とに金銭を支払い支払い処理を行い、その支払い処理に基づいて、端末20のユーザが借りた金銭の借り換えに関する本成約条件情報(限定ではなく、第2金利情報の一例)を取得する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、端末のユーザが第1企業から借りた金銭の情報を含む第1情報の他、端末のユーザが第2企業から借りた金銭の情報を含む第2情報を端末から受信した上で、その第1情報と第2情報とに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第1金利情報を取得することができる。また、その上で、サーバは、受信した第1情報と第2情報とに基づき、第1企業と第2企業とに金銭を支払った上で、その支払いに基づいて、端末のユーザが借りた金銭の借り換えに関する金利の情報を含む第2金利情報を取得することができる。これにより、端末のユーザが第1企業から借りた金銭と、端末のユーザが第2企業から借りた金銭とをまとめた借り換えを可能とすることができるとともに、端末のユーザに適切な金利を提示することができる。また、限定ではなく例として、第2金利情報の金利が第1金利情報の金利と等しいか、それよりも低くなるように第1金利情報を算出するといったことも可能となる。
【0311】
また、本実施例は、サーバ10が行う支払い処理は、第1借入先情報(第1情報)に基づき第1企業の口座に振り込みを行い、第2借入先情報(第2情報)に基づき第2企業の口座に振り込みを行う処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第1企業から借りた金銭の情報を含む第1情報に基づき第1企業の口座に振り込みを行い、端末のユーザが第2企業から借りた金銭の情報を含む第2情報に基づき第2企業の口座に振り込みを行う処理を行って、各々の企業への支払いを行うことができる。また、振り込みという一般的な方法で、支払いを簡易かつ適切に行うことができる。
【0312】
<第3変形例(1)>
上記の実施例では、借入ローン契約が2つの例について例示したが、これに限定されない。限定ではなく例として、借入ローン契約を3つ以上としてもよい。
以下では、「N」個(「N」は自然数)の借入ローン契約を乗り換える例について考える。
【0313】
この場合、プレ成約条件算出処理において、制約条件1′における合計借入返済額は、限定ではなく例として、以下のように算出することができる。
合計借入返済額=第1借入返済額+・・・+第n借入返済額+・・・+第N借入返済額
【0314】
また、制約条件2′における加重平均借入金利は以下のように算出することができる。
加重平均借入金利=(第1借入残高×第1借入金利+・・・+第n借入残高×第n借入金利+・・・+第N借入残高×第N借入金利)÷(第1借入残高+・・・+第n借入残高+・・・+第N借入残高)
【0315】
そして、借入先照会処理や代替返済振込処理、本成約条件算出処理については借入ローン契約が2つの場合と同様に実行するようにすることができる。
【0316】
<第3変形例(2)>
上記の実施例では、本成約条件が算出されると、サーバ10の制御部11は、本成約条件情報を端末20Aに送信することとしたが、これに限定されない。
限定ではなく例として、サーバ10の制御部11は、本成約条件算出処理を行った後、本成約条件に基づいて、貸付管理データの各レコードを更新する。
【0317】
端末20Aの制御部21は、限定ではなく例として、ユーザ入力に基づいて、本成約条件を取得することが選択されたか否かを判定する。そして、本成約条件を取得すると判定する場合、端末20Aの制御部21は、本成約条件要請情報を通信I/F22によってサーバ10に送信する。
通信I/F14によって端末20Aから本成約条件要請情報を受信したと判定する場合、サーバ10の制御部11は、本成約条件情報を通信I/F14によって端末20Aに送信するようにしてもよい。
【0318】
本変形例は、サーバ10の制御部11は、端末20のユーザによる入力に基づいて、本成約条件情報(限定ではなく、第2金利情報の一例)を端末20に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザによる端末に対する入力に基づいて、第2金利情報を端末に送信することができる。
なお、逆に、限定ではなく例として、端末のユーザによる端末に対する入力がなされなければ、第2金利情報がサーバから端末に送信されないようにしてもよい。
【0319】
<第3変形例(3)>
上記の実施例では、代替返済振込処理において金融機関口座間での振込(振替)を実行したが、これに限定されない。限定ではなく例として、借入先が電子マネーでの返済に対応している場合、代替返済振込処理においてマネーローンサービス事業者の電子マネー口座から、借入ローン振込先情報で指定される返済用電子マネー口座に電子マネーの送金を行うようにしてもよい。
電子マネーの送金の処理も、振込(振替)の処理と同様に、サーバ10が行う支払い処理の一例とすることができる。
【0320】
<第4実施例>
第3実施例では、代替返済振込処理において全ての借入先に対する振込(振替)が成功する場合について例示した。
第4実施例は、代替返済振込処理において借入先に対する振込(振替)が少なくとも1つ失敗する場合についての実施例である。
【0321】
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0322】
借入先に対する振込(振替)が失敗する場合、プレ成約条件算出処理における合計借入返済額や加重平均借入金利と、実際に振込処理が成功し、借り換えが確定した借入ローン契約を対象とする合計借入返済額や加重平均借入金利とが変化する可能性がある。このため、借り換え契約時の条件として、振込処理が全て成功する前提でのプレ成約条件を乗り換えローン契約としてそのまま用いる場合、振込処理の状況によっては、貸付金利や貸付返済額が段階的借換における例外貸付の判定条件を満たさなくなるという可能性がある。
そして、この場合、金利に関して法令違反となる場合がある。
【0323】
分かり易いように具体例を挙げて説明する。
ここでは、限定ではなく例として、一の端末20のユーザ(以下、単に「ユーザ」と称する。)が、限定ではなく例として、以下の3つの契約に基づく借り入れを行っている場合を考える。
・契約A 借入残高10万円 借入金利 10% 借入返済額 10,000円
・契約B 借入残高60万円 借入金利 15% 借入返済額 20,000円
・契約C 借入残高30万円 借入金利 18% 借入返済額 10,000円
この場合、合計借入返済額は「40,000円」、加重平均借入金利は「15.4%」と算出される。
【0324】
ここで、サーバ10の制御部11が、ユーザのプレ成約条件の金利を、限定ではなく例として、上記の加重平均借入金利「15.4%」から「1%」だけ下げた「14.4%」として算出したとする。なお、これはあくまで一例に過ぎない。
【0325】
ユーザがプレ成約条件に同意したものの、サーバ10が行う代替返済振込処理において、限定ではなく例として、契約B,Cに基づく振込に失敗したとする。この場合、ユーザは「14.4%」のプレ成約条件の貸付金利で同意したものの、マネーローンサービス事業者から借り換えができるのは契約Aのみとなる。そして、この場合、プレ成約条件の貸付金利「14.4%」でユーザに貸付を行うと、実際に借り換え可能な借入ローン契約に基づいて算出される上限金利(すなわち、代替返済振込後に計算される加重平均借入金利(=契約Aの借入金利))「10%」を上回ってしまうため、法令違反となる。
これは、借入の契約が2以上、かつ、振込が失敗する場合に起こり得る。
【0326】
<表示画面>
図4-1は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
【0327】
本表示画面では、限定ではなく例として、第3実施例と同様に、借入先企業名「XX信販」との第1借入ローン契約と、第2借入先企業名「YYローン」との借入ローン契約との2つの借入先からの乗り換え例について例示する。
【0328】
限定ではなく例として、
図3-3中央の借入ローン振込先情報入力画面においてユーザによって入力された第1借入ローン振込先情報に誤りがあり、代替返済振込処理において「XX信販」が指定するへの金融機関口座への振込処理が失敗したとする。
図4-1左側に、この場合表示されるホーム画面の一例を示す。
【0329】
このホーム画面では、「YYローン」への振込処理が完了したことを示す振込処理完了通知NT8の下に、「XX信販」への振込処理が失敗したことを示す振込処理失敗通知NT10が表示されている。
【0330】
振込処理失敗通知NT10では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側には「XX信販」への振込処理が失敗したことを示す「XX信販への振込に失敗しました」というメッセージと、第1借入ローン振込先情報の再確認を促す「口座情報を確認してください」というメッセージとが表示されるように構成されている。また、振込処理失敗通知NT10には、第1借入ローン振込先情報の確認期限が「2021年11月19日」であることを示す文字が表示されるように構成されている。
【0331】
また、この画面では、契約内容表示領域CTR2の貸付金利が、プレ成約条件に基づく「14%」であることが表示されている。また、貸付残高等は、全ての借入先への振込処理が完了していないことに基づいて「処理中」の文字が表示されている。
【0332】
限定ではなく例として、ユーザによって振込処理失敗通知NT10がタップされると、限定ではなく例として、
図4-1中央の借入ローン振込先情報入力画面に表示が遷移する。
この借入ローン振込先情報入力画面では、振込処理に失敗した第1借入先情報として登録された借入先企業名である「XX信販」の文字が「お借入先会社名」の文字とともに表示されるように構成されている。その下には、再確認が必要な第1借入ローン振込先情報を受け付けるフォームが表示されるように構成されている。
【0333】
フォームに情報を再入力後、限定ではなく例として、ユーザによって借入ローン振込先情報登録ボタンBT16がタップされると、ホーム画面に表示が遷移する。
【0334】
図4-1右側のホーム画面は、限定ではなく例として、
図4-1中央の借入ローン振込先情報入力画面において第1借入ローン振込先情報を入力後、再度「XX信販」への振込処理が失敗した場合の表示画面の一例である。また、この画面では、「XX信販」への振込処理失敗後、「2020年11月20日」となった場合を考える。
【0335】
このホーム画面では、アプリ内位置表示領域の下に、「XX信販」への振込処理が失敗したことを示す振込処理失敗通知NT11が表示されている。
また、振込処理失敗通知NT11の下には、振込処理に成功した「YYローン」の第2借入先情報に基づいて本成約条件が算出されたことにより、契約書面再交付通知NT12が表示されている。
【0336】
また、契約内容表示領域CTR2において、貸付金利が本成約条件でも変動せず「14%」であることが表示されている。そして、貸付残高が「YYローン」の借入残高に基づく「600,000円」に確定し、次回返済日が「2021年11月26日」、次回返済金額が本成約条件の貸付返済額に基づく「20,000円」に確定したことが表示されている。
【0337】
そして、取引履歴表示領域THR2には、ユーザが「2021年11月20日」に貸付先から「600,000円」を借り入れたことを示す取引履歴が表示されている。
【0338】
すなわち、この例では、振込処理に失敗した「XX信販」からの第1借入ローン契約については乗り換えローンの対象とならず、「YYローン」からの第2借入ローン契約のみが解消され、ローンサービス事業者のローンへ乗り換えが行われたこととなる。
【0339】
<処理>
フローチャートを参照して、本実施例における処理を説明する。
以下説明するフローチャートの処理を適用して計算を行う方法として、限定ではなく例として、計算方法1と計算方法2との2つの計算方法を例示する。計算方法1と計算方法2とのいずれを用いてもよく、処理の流れは同様とすることができる。
【0340】
<計算方法1>
計算方法1では、限定ではなく例として、サーバ10が、代替返済振込処理が全て成功する前提でのキャップ条件よりも借り換えを行うユーザの条件が不利または等しいプレ成約条件を算出する。そして、プレ成約条件に基づく乗り換えローン契約をユーザと締結する。その後、代替返済振込処理の結果に基づいて、例外貸付の判定条件を満たす範囲内で本成約条件を算出する。そして、乗り換えローン契約をプレ成約条件よりも借り換えを行うユーザが有利または等しい本成約条件に契約を更新する。これは、前述した制約条件3を用いる手法と考えてもよいものとする。
【0341】
図4-2~
図4-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。このフローチャートは、限定ではなく例として、第1実施例のフローチャートを複数の借入先がある場合に拡張し、さらに、代替返済振込処理において振込処理の失敗が起こり得る場合のフローチャートとして構成したものである。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0342】
なお、処理の簡略化のため、第2実施例において例示した借入先照会処理を本フローチャートでは省略する。第2実施例を参酌し、サーバ10の制御部11は、限定ではなく例として、プレ成約条件同意情報を受信したと判定する場合(S130:YES)、借入先照会処理(S210)を実行するようにしてもよい。
【0343】
サーバ10の制御部11は、プレ成約条件算出処理において、限定ではなく例として、第1借入先情報と第2借入先情報とに基づくキャップ条件と、記憶部15に記憶されるユーザA.Aのソーシャルスコアとに基づいて、制約条件1′と、制約条件2′と、制約条件3とを満たすプレ成約条件を算出する。
【0344】
サーバ10の制御部11は、限定ではなく例として、代替返済振込処理を実行すると(S140)、各借入先ID(この場合、「n=1,2」)において、第n借入ローン振込先情報に基づく代替返済振込処理が成功したか否か判定する。全ての借入先ID(この場合、「n=1、2」)において第n借入ローン振込先情報に基づく代替返済振込処理が成功した場合(S310:YES)、サーバ10の制御部11は、本成約条件算出処理を実行する(S150)。
【0345】
一方、いずれかの借入先IDにおいて第n借入ローン振込先情報に基づく代替返済振込処理が失敗したとする。ここで、限定ではなく例として、2つの借入先のうち1つの借入先において代替返済振込処理に失敗した場合を考える。このとき、代替返済振込処理に失敗した借入先IDを第m借入先(「m」は自然数)とする。この例では、「m=1または2」となる。
なお、2つの借入先の両方が失敗する場合(「m」=「1」と「2」)についても同様に考えることができる。
【0346】
第m借入ローン振込先情報に基づく代替返済振込処理が失敗した場合(S310:NO)、サーバ10の制御部11は、限定ではなく例として、プレ成約条件同意情報を受信してからの経過日数が設定日数(限定ではなく例として、「7日」)以内であるか否かを判定する(S320)。なお、サーバ10の制御部11は、限定ではなく例として、プレ成約条件同意情報を受信してからの経過日数が設定日数未満であるか否かを判定するようにしてもよい。また、経過日数の起算日を、プレ成約条件情報を送信してからとしてもよい。
【0347】
プレ成約条件同意情報を受信してからの経過日数が設定日数以内であると判定する場合(S320:YES)、サーバ10の制御部11は、限定ではなく例として、第m借入ローン振込先情報の再確認を求めるための振込先情報確認依頼情報を通信I/F14によって端末20Aに送信する(S330)。
なお、複数の借入先IDにおいて代替返済振込処理に失敗した場合(限定ではなく例として、「m」=「1」と「2」)、サーバ10の制御部11は、失敗した全ての借入先ID(この場合、「m」=「1」と「2」)における第m借入ローン振込先情報の再確認を求めるための振込先情報確認依頼情報を通信I/F14によって端末20Aに送信するようにしてもよい。
【0348】
限定ではなく例として、プレ成約条件同意情報をサーバ10に送信すると(A150)、端末20Aの制御部21は、通信I/F22によってサーバ10から振込先情報?確認依頼情報を受信したか否かを判定する(A310)。
【0349】
振込先情報確認依頼情報を受信したと判定する場合(A310:YES)、端末20Aの制御部21は、受信した振込先情報確認依頼情報を表示部24に表示させる(A320)。限定ではなく例として、表示された振込先情報確認依頼情報に対するユーザ入力に基づいて、振込処理が失敗した借入先IDにおける借入ローン振込先情報(第m借入ローン振込先情報)を取得すると、端末20Aの制御部21は、受け付けた借入ローン振込先情報を含む借入ローン振込先確認情報を通信I/F22によってサーバ10に送信する(A330)。そして、端末20Aの制御部21は、限定ではなく例として、A310のステップに処理を戻す。
【0350】
振込先情報確認依頼情報を受信しないと判定する場合(A310:NO)、端末20Aの制御部21は、本成約条件情報の受信待機を行い、A160のステップを実行する。
【0351】
通信I/F14によって端末20Aから借入ローン振込先確認情報を受信すると、サーバ10の制御部11は、受信した借入ローン振込先確認情報に基づいて第m借入ローン振込先情報を更新する。なお、複数の借入ローン振込先情報を受信した場合(限定ではなく例として、「m」=「1」と「2」)、サーバ10の制御部11は、複数の第m借入ローン振込先情報を更新するようにしてもよい。
【0352】
すると、サーバ10の制御部11は、更新した借入ローン振込先情報に基づいて、返済振込処理が完了していない借入先IDにおいて、再度代替返済振込処理を実行する(S140)。
【0353】
なお、サーバ10の制御部11は、限定ではなく例として、プレ成約条件同意情報を受信してから設定日数が経過後、借入ローン振込先確認情報を端末20Aから受信しないと判定する場合、限定ではなく例として、本成約条件算出処理を実行する(S150)ようにしてもよい。
【0354】
プレ成約条件同意情報を受信してからの経過日数が設定日数を超過したと判定する場合(S320:NO)、サーバ10の制御部11は、限定ではなく例として、本成約条件算出処理を実行する(S150)。
【0355】
本成約条件算出処理において、サーバ10の制御部11は、代替返済振込処理が成功した借入先情報に関して、合計借入返済額と加重平均借入金利とを再計算する。
【0356】
限定ではなく例として、第1借入先のみ代替返済振込処理が成功した場合、「合計借入返済額=第1借入返済額」、「加重平均借入金利=第1借入金利」となる。
また、限定ではなく例として、第2借入先のみ代替返済振込処理が成功した場合、「合計借入返済額=第2借入返済額」、「加重平均借入金利=第2借入金利」となる。
第1借入先と第2借入先とにおいて代替返済振込処理が成功した場合、前述したように「合計借入返済額=第1借入返済額+第2借入返済額」、「加重平均借入金利=(第1借入残高×第1借入金利+第2借入残高×第2借入金利)÷(第1借入残高+第2借入残高)」となる。
【0357】
すると、サーバ10の制御部11は、限定ではなく例として、代替返済振込処理において振込が完了した各借入先IDの第n借入残高と、第n借入残高に紐づく第n借入金利とに基づいて、キャップ金利の算出理論に基づいて、キャップ貸付金利を算出する。また、合計借入返済額に基づいて、貸付残高を算出する。
【0358】
そして、サーバ10の制御部11は、限定ではなく例として、以下の制約条件A~Dを満たし、評価関数「|貸付金利-キャップ貸付金利|」が最小となるように、本成約条件における貸付金利と貸付返済額とを、限定ではなく例として、最適化問題の一解法であるネルダー・ミード法を用いて算出する。
・制約条件A:「加重平均借入金利≧貸付金利」
・制約条件B:「プレ成約条件の貸付金利≧貸付金利」
・制約条件C:「合計借入返済額≧貸付返済額」
・制約条件D:「プレ成約条件の貸付返済額≧貸付返済額」
なお、「キャップ貸付金利>貸付金利」(マネーローンサービス事業者が損をする可能性がある貸付金利)としてもよい。
【0359】
ただし、制約条件Aの加重平均借入金利は、上記の代替返済振込処理を行った後に再計算される加重平均借入金利であって、プレ成約条件を算出する際に用いられる加重平均借入金利(代替返済振込処理を行う前の加重平均借入金利)ではない。
【0360】
上記の計算方法によれば、限定ではなく例として、本成約条件における貸付金利と貸付返済額とを未知数とし、限定ではなく例として制約条件A~Dのもと、評価関数「|貸付金利-キャップ貸付金利|」が最小となる解を、最適化問題のアルゴリズム(最適化演算)によって求めるようにすることができる。
【0361】
ここで算出された本成約条件は、代替返済振込処理の振込処理結果に関わらず、段階的借換における例外貸付の判定条件を満たす。よって、前述した法令違反となることはない。
【0362】
また、この計算方法では、借り換えを行うユーザにとっては、プレ成約条件よりも本成約条件が有利な借り換え条件となる可能性がある。少なくとも、プレ成約条件よりも本成約条件において不利となることはない。
【0363】
本実施例の冒頭に示した具体例を用いて説明する。
前述した具体例に基づき、契約Aのみが代替返済振込処理の振込処理に成功した場合、再計算された加重平均借入金利は「10%」となる。
また、限定ではなく例として、契約Aの借入残高と、借入金利とに基づいて、キャップ貸付金利が「8%」と算出されたとする。
このとき、貸付金利は、上記の最適化の手法により、限定ではなく例として「8%」~「10%」の間の解で、「8%」になるべく近い、限定ではなく例として「8.5%」と算出される。
【0364】
なお、本成約条件算出処理において、キャップ貸付金利がプレ成約条件の貸付金利を上回る場合、サーバ10の制御部11は、限定ではなく例として、本成約条件の貸付金利を算出せず、プレ成約条件の貸付金利をそのまま本成約条件の貸付金利として用いるようにしてもよい。
【0365】
最後に、サーバ10の制御部11は、算出された本成約条件における貸付金利と貸付返済額と貸付残高とに基づいて、貸付管理データの各レコードを更新する。
【0366】
なお、代替返済振込処理において全ての借入先において代替返済振込処理が失敗した場合、本成約条件算出処理において、サーバ10の制御部11は、借り換えローンの処理に失敗したことを示す本成約条件情報を送信するようにしてもよい。そして、サーバ10の制御部11は、借入先登録データのレコードを消去し、更新した貸付管理データを元に戻すようにしてもよい。
【0367】
また、借入ローン契約を3つ以上とする場合も同様とすることができる。
「N」個(「N」は自然数)の借入ローン契約を乗り換える場合、プレ成約条件算出処理における合計借入返済額と加重平均借入金利とは、限定ではなく例として、以下のように算出することができる。
合計借入返済額=第1借入返済額+・・・+第n借入返済額+・・・+第N借入返済額
加重平均借入金利=(第1借入残高×第1借入金利+・・・+第n借入残高×第n借入金利+・・・+第N借入残高×第N借入金利)÷(第1借入残高+・・・+第n借入残高+・・・+第N借入残高)
【0368】
また、本成約条件算出処理における合計借入返済額と加重平均借入金利とは、代替返済振込処理が完了しなかった借入先IDを第m借入先とすると、上記の式から「n=m」となる項を省いたものとなる。
【0369】
計算方法1では、制約条件3を用いた計算を行うことで、限定ではなく例として、マネーローンサービス事業者の利益とユーザのメリットとを考慮した、ちょうどよいバランスの金利を取得し得る。
なお、これは、制約条件3を用いて計算を行う手法を用いる場合において、他の実施例についても同様のことが言える。
【0370】
<計算方法2>
次に、計算方法2について説明する。計算方法2は、制約条件3を用いない手法と考えてもよいものとする。なお、処理の流れ(フロー)は上記の処理と同様とすることができる。
【0371】
限定ではなく例として、
図4-2のプレ成約条件算出処理(S110)において、サーバ10の制御部11は、第3実施例で説明したのと同様に、限定ではなく例として、以下のようにプレ成約条件の貸付金利を算出する。
「プレ成約条件の貸付金利」=「加重平均借入金利」×「ユーザ係数」
【0372】
ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値(限定ではなく例として、平均値)より大きい場合、「1」より小さい値をとり、ソーシャルスコアが所定値より小さい場合、「1」より大きい値をとる、正の係数であるようにしてもよい。なお、ユーザ係数は、限定ではなく例として、ソーシャルスコアが所定値である場合、「1」をとるようにしてもよい。
【0373】
また、前述したように、ソーシャルスコアを用いることは必須ではない。また、ユーザ係数は、限定ではなく例として、ユーザA.Aの信用情報に基づいて算出されるようにしてもよい。
【0374】
また、プレ成約条件の貸付金利を、以下のように算出するようにしてもよい。
「プレ成約条件の貸付金利」=「加重平均借入金利」-「ユーザ係数」
ここで、「ユーザ係数」は、限定ではなく例として、ソーシャルスコアが所定値(限定ではなく例として、平均値-分散値)より大きい場合、「0」より大きい値をとる、正の係数であるようにしてもよい。
【0375】
そして、サーバ10の制御部11は、限定ではなく例として、算出されたプレ成約条件の貸付金利に基づいて、「合計借入返済額≧プレ成約条件の貸付返済額」となるようにプレ成約条件の貸付返済額と貸付残高とを算出する。
【0376】
図4-3の代替返済振込処理(S140)において失敗した振込が存在する場合、サーバ10の制御部11は、
図4-3の本成約条件算出処理(S150)において、代替返済振込処理が成功した借入先情報に関して、合計借入返済額と加重平均借入金利とを再計算すると、限定ではなく例として、以下のように本成約条件を算出する。
「本成約条件の貸付金利」=「min(加重平均借入金利,プレ成約条件の貸付金利)」
「本成約条件の貸付返済額」=「合計借入返済額」
「本成約条件の貸付残高」=代替返済振込処理において振込に成功した借入残高の総和
【0377】
すなわち、プレ成約条件および本成約条件の両方において、日本国の貸金業法によって定められる、段階的借換における例外貸付の判定条件を満たすため、法令違反となることはない。
【0378】
分かり易いように、本実施例の冒頭に示した、以下の具体例を用いて詳細に説明する。
・契約A 借入残高10万円 借入金利 10% 借入返済額 10,000円
・契約B 借入残高60万円 借入金利 15% 借入返済額 20,000円
・契約C 借入残高30万円 借入金利 18% 借入返済額 10,000円
合計借入返済額「40,000円」、加重平均借入金利「15.4%」
【0379】
また、前述したように、サーバ10の制御部11が、ユーザのプレ成約条件の金利を、加重平均借入金利「15.4%」から「1%」だけ下げた「14.4%」として算出したものとする。なお、このプレ成約条件の金利の算出においては、前述したように、ユーザのソーシャルスコアを用いてもよいし、用いなくてもよい。
【0380】
これらの条件(前提)のもと、振込に失敗するケースを含むいくつかのケースについて計算結果を例示する。なお、以下の計算結果における加重平均借入金利は、前述した代替返済振込処理を行った後に再計算される加重平均借入金利である。
【0381】
(ケース1)契約Aのみが振込成功の場合(冒頭で例示した振込失敗例)
再計算により、加重平均借入金利10%、貸付返済額10,000円となる。
よって、このケースでは、
本成約条件の貸付金利=min(10%,14.4%)=10%
と算出する。
つまり、このケースは法令違反となってしまうため、再計算された加重平均借入金利を本成約条件の貸付金利とする。
【0382】
(ケース2)契約Cのみが振込成功の場合
再計算により、加重平均借入金利18%、貸付返済額10,000円となる。
よって、このケースでは、
本成約条件の貸付金利=min(18%,14.4%)=14.4%
と算出する。
つまり、このケースは法令違反とならないため、プレ成約条件の貸付金利を維持する。
【0383】
(ケース3)契約A、Bが振込成功の場合
再計算により、加重平均借入金利14.29%、貸付返済額30,000円となる。
よって、このケースでは、
本成約条件の貸付金利=min(14.29%,14.4%)=14.29%
と算出する。
つまり、このケースは法令違反となってしまうため、再計算された加重平均借入金利を本成約条件の貸付金利とする。
【0384】
(ケース4)契約B、Cが振込成功の場合
再計算により、加重平均借入金利16%、貸付返済額30,000円となる。
よって、このケースでは、
本成約条件の貸付金利=min(16%,14.4%)=14.4%
と算出する。
つまり、このケースは法令違反とならないため、プレ成約条件の貸付金利を維持する。
【0385】
(ケース5)契約A、B、Cの全てが振込成功の場合
このケースでは、
本成約条件の貸付金利=min(14.4%,14.4%)=14.4%(本成約条件の貸付金利=プレ成約条件の貸付金利=14.4%)
と算出する。
なお、このケースは振込が全て成功するケースであるため、法令違反の問題は生じない。
【0386】
他のケースにおいても同様に、限定ではなく例として、代替返済振込処理後の加重平均借入金利がプレ成約条件の貸付金利を上回る場合、プレ成約条件の貸付金利が本成約条件の貸付金利とされるようにする。また、代替返済振込処理後の加重平均借入金利がプレ成約条件の貸付金利以下である場合、代替返済振込処理後の加重平均借入金利が本成約条件の貸付金利とされるようにする。このようにすることで、法令違反とならないようにすることができる。
【0387】
なお、限定ではなく例として、本成約条件の貸付残高が「0」であると算出される場合、限定ではなく例として、サーバ10の制御部11は、借り換えローンの貸付に失敗したことを示す本成約条件情報を端末20に送信するようにしてもよい。
【0388】
また、借入先が1つの場合であって、代替返済振込処理において振込が失敗する場合、限定ではなく例として、サーバ10の制御部11は、借り換えローンの貸付に失敗したことを示す本成約条件情報を端末20に送信するようにしてもよい。
【0389】
また、借入先が1つの場合、限定ではなく例として、代替返済振込処理において振込が成功する場合、サーバ10の制御部11は、限定ではなく例として、以下のように本成約条件を算出するようにしてもよい。
「本成約条件の貸付金利」=「プレ成約条件の貸付金利」
「本成約条件の貸付返済額」=「プレ成約条件の貸付返済額」
「本成約条件の貸付残高」=「プレ成約条件の貸付残高」
【0390】
なお、前述したように、「加重平均借入金利=プレ成約条件の貸付金利」としてもよい。つまり、上記の具体例では、「プレ成約条件の貸付金利=加重平均借入金利=15.4%」としてもよい。
【0391】
また、上記の金利等の計算方法は、あくまで日本国の場合を例示したものに過ぎず、これに限定されない。上記と同様の思想によって、他の国において同様の問題が生ずる場合であっても、各々の国の法定金利やそれに関連する法令を遵守するように、上記の計算方法1や計算方法2と同様の考え方で、金利等を取得(算出)することができる。
【0392】
<第4実施例の効果>
本実施例は、サーバ10の制御部11が、支払い処理において、第1借入先情報(限定ではなく、第1情報の一例)に基づく第1企業への支払いが失敗した場合、第2借入先情報(限定ではなく、第2情報の一例)に基づき決定されたプレ成約条件情報(限定ではなく、第2金利情報の一例)を取得する構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、支払い処理において、端末のユーザが第1企業から借りた金銭の情報を含む第1情報に基づく第1企業への支払いが失敗した場合であっても、端末のユーザが第2企業から借りた金銭の情報を含む第2情報に基づき決定された第2金利情報を取得することによって、第2金利情報を適切に取得することができる。
【0393】
また、この場合、サーバ10の制御部11は、再計算された加重平均借入金利(限定ではなく、第2情報に基づき算出される金利の上限の一例)が、プレ成約条件の貸付金利(限定ではなく、第1金利情報の金利の一例)より低い場合、本成約条件の貸付金利(限定ではなく、第2金利情報の金利の一例)を算出するようにしてもよい。
このような構成により得られる実施例の効果の一例として、サーバは、第2情報に基づき算出される金利の上限が、第1金利情報の金利より低い場合、第2金利情報の金利を算出することができる。この場合、前述したように、限定ではなく例として、金利に関連する法令等に違反しない第2金利情報の金利を算出することができる。
【0394】
また、本実施例は、第1借入先情報は、第1企業の振込口座番号(限定ではなく、第1口座番号の一例)を含み、サーバ10の制御部11は、この振込口座番号に誤りがある場合、振込先情報確認依頼情報(限定ではなく、第1口座番号を入力するための情報の一例)を端末20に通信I/F14によって送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第1企業から借りた金銭の情報を含む第1情報に含まれる第1企業の第1口座番号の情報の第1口座番号に誤りがある場合、第1口座番号を入力するための情報を端末に送信して、端末のユーザに第1口座番号を入力させることができる。
【0395】
また、本実施例は、サーバ10の制御部11は、端末20のユーザによる、上記の振込先情報確認依頼情報への振込口座番号の入力が設定された期間内に行われなかった場合、第2振込先情報(限定ではなく、第2情報の一例)に基づく本成約条件情報(限定ではなく、第2金利情報の一例)を取得する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが第1企業から借りた金銭の情報を含む第1情報に含まれる第1企業の第1口座番号の情報の第1口座番号に誤りがある場合であって、端末のユーザによる、第1口座番号を入力するための情報への入力が設定された期間内に行われなかった場合、端末のユーザが第2企業から借りた金銭の情報を含む第2情報に基づく第2金利情報を取得することができる。
【0396】
<第4変形例(1)>
上記の実施例では、代替返済振込処理において、各借入ローン振込先情報を照合せずに金融機関口座への振込を実行したが、これに限定されない。限定ではなく例として、サーバ10の制御部11は、借入ローン振込先情報照合処理を実行し、振込依頼情報を通信I/F14によって不図示の金融機関サーバに送信するようにしてもよい。
【0397】
限定ではなく例として、サーバ10の制御部11は、他のユーザの借り換えに伴う借入ローン振込先情報を蓄積して記憶部15に記憶させ、借入ローン振込先データベースを構築する。そして、サーバ10の制御部11は、借入ローン振込先情報照合処理において、借入ローン振込先データベースを参照し、借入先企業名と、金融機関名・支店名が過去の履歴と合致する場合、振込依頼情報を金融機関サーバに送信するようにしてもよい。
【0398】
また、借入ローン振込先情報照合処理において、サーバ10の制御部11は、金融機関名と対応する銀行サーバに支店名・振込先口座番号とを含む名義照会情報を送信するようにしてもよい。銀行サーバは名義照会情報を受信すると、銀行サーバの記憶部に記憶される口座管理データベースを参照し、振込先口座番号の名義である口座名義情報をサーバ10に送信する。そして、サーバ10の制御部11は、受信した口座名義情報と借入ローン振込先情報の受取口座名義とが合致する場合、振込依頼情報を金融機関サーバに送信するようにしてもよい。
【0399】
なお、借入ローン振込先情報照合処理の結果、第n借入ローン振込先情報が不当であると判定される場合、サーバ10の制御部11は、第n借入先確認要請情報を表示部13に表示させるようにしてもよい。そして、サーバ10のユーザは、表示された第n借入先確認要請情報に基づいて、電話等の手段で端末20のユーザに連絡し、第n借入先情報の照合を行うようにしてもよい。
【0400】
本変形例は、サーバ10は、借入ローン振込先データベースなどの記憶部15に記憶されたデータ(限定ではなく、記憶されたデータの一例)と、第1借入先情報(限定ではなく、第1情報の一例)と、第2借入先情報(限定ではなく、第2情報の一例)とに基づいて、第1企業と第2企業とに対する支払い処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、記憶されたデータと、端末のユーザが第1企業から借りた金銭の情報を含む第1情報と、端末のユーザが第2企業から借りた金銭の情報を含む第2情報とに基づいて、第1企業と第2企業とに簡易かつ適切に金銭を支払うことができる。
【0401】
<第5実施例>
上記の実施例では、借入先情報受付処理において、借入先情報の入力フォームに対するユーザ入力によって借入先情報を取得する例を例示した。第5実施例は、限定ではなく例として、撮像部27によって借入先の契約書面を撮像することで借入先情報を取得する実施例である。
【0402】
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0403】
<表示画面>
図5-1は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
図5-1は、限定ではなく例として、
図3-2左側の借入先情報入力画面の別例である。
【0404】
この借入先情報入力画面では、アプリ内位置表示領域の下に、第1借入先情報の取得を行うための借入先受付ボタンLIG1が表示されるように構成されている。
【0405】
借入先受付ボタンLIG1の中央には、第1借入先情報の取得を行うことを示す「借入先1」の文字が表示されるように構成されている。また、借入先受付ボタンLIG1の左下側には、第1借入先情報が未取得であることを示す「未登録」の文字で示すアイコンが表示されるように構成されている。
【0406】
限定ではなく例として、ユーザ入力によって借入先受付ボタンLIG1がタップされると、限定ではなく例として、画面下部から借入先情報の取得方法を選択させるための借入先取得方法選択領域ISR1がせり上がり表示されるように構成されている。
【0407】
借入先取得方法選択領域ISR1には、「お借入先情報の入力方法を選択してください」のメッセージの下に、限定ではなく例として、フォーム入力により取得するための「手動入力」の文字で示される借入先情報手動取得ボタンBT17と、契約書面を撮像することで取得するための借入先情報撮像取得ボタンBT18とが表示されるように構成されている。
【0408】
限定ではなく例として、借入先情報手動取得ボタンBT17がタップされると、限定ではなく例として、
図3-2左側と同様の借入先情報入力画面が表示される。
【0409】
限定ではなく例として、借入先情報撮像取得ボタンBT18がタップされると、限定ではなく例として、
図5-1右側の契約書面取得画面に表示が遷移する。
【0410】
この契約書面取得画面では、アプリ内位置表示領域には借入先情報撮像取得ボタンがタップされたことに基づいて、「契約書類撮影」の文字が表示されている。
契約書面取得画面の中央部には、限定ではなく例として、ユーザによって契約書面撮影ボタンBT19がタップされ、撮像部27によって契約書面が撮像されたことにより、「撮影済み書類」の文字の下に撮像された書類の画像が表示されるように構成されている。
また、撮像が行われたことに基づいて、契約書面撮影ボタンBT19内部の文字が「撮影する」から「撮影しなおす」の文字へと変化している。
【0411】
契約書面撮影ボタンBT19の下には、撮像した画像を契約書面の画像として登録するための「登録」の文字で示される契約書面登録ボタンBT20が表示されるように構成されている。なお、書類の画像が撮像されていない場合、限定ではなく例として、契約書面登録ボタンBT20は、グレーアウトの表示態様で表示され、無効化されている。
【0412】
限定ではなく例として、ユーザによって契約書面登録ボタンBT20がタップされると、限定ではなく例として、
図5-1右側の借入先情報入力画面に表示が遷移する。
【0413】
この借入先情報入力画面では、契約書面の画像が取得されたことに基づいて、借入先受付ボタンLIG1内のアイコンが「未登録」アイコンから「登録済み」アイコンに変更されている。また、借入先受付ボタンLIG1内には、第1借入先情報として取得された借入先企業名である「XX信販」の文字が表示されている。
【0414】
また、借入先受付ボタンLIG1の下には、第2借入先情報の取得を行うための借入先受付ボタンLIG2が表示されるように構成されている。
同様に、第n借入先情報の取得が実行されると、第n+1借入先情報の取得を行うための借入先受付ボタンが下に連なる形で表示されるように構成されている。
【0415】
限定ではなく例として、ユーザによって借入先情報確認ボタンBT1がタップされると、登録済みの借入先情報を確認させるための、限定ではなく例として、
図3-2中央と同様な借り換えプラン申し込み確認画面に表示が遷移する。
【0416】
<処理>
端末20Aの制御部21は、限定ではなく例として、借入先情報受付処理(A110)において、撮像部27によって契約書面画像情報を取得する。すると、端末20Aの制御部21は、取得した契約書面画像情報を通信I/F22によってサーバ10に送信する。
【0417】
通信I/F14によって端末20Aから契約書面画像情報を受信すると、サーバ10の制御部11は、限定ではなく例として、契約書面画像情報に対してOCR処理を実行し、借入先情報を取得する。
【0418】
なお、OCR処理は、サーバ10において実行することに限定されない。限定ではなく例として、端末20Aの制御部21は、契約書面画像情報に対してOCR処理を実行し、借入先情報を取得する。そして、端末20Aの制御部21は、取得された借入先情報を通信I/F22によってサーバ10に送信するようにしてもよい。
【0419】
<第5実施例の効果>
本実施例は、第1借入先情報(限定ではなく、第1情報の一例)と第2借入先情報(限定ではなく、第2情報の一例)とは、端末20の撮像部27によって撮像された画像の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末の撮像部によって撮像された画像の情報を含む、端末のユーザが第1企業から借りた金銭の情報を含む第1情報と、端末のユーザが第2企業から借りた金銭の情報を含む第2情報とを受信することができる。また、金銭の借り入れに関する情報が端末で撮像されることによって第1情報と第2情報とがサーバに送信されるようにすることができ、金銭の借り入れに関する情報を端末のユーザが手入力せずに済むため、端末側(ユーザ側)の視点では、ユーザにとって便利である。
【0420】
<第6実施例>
上記の実施例では、サーバ10の制御部11は、本成約条件情報を端末20に送信すると、処理を終了させる例を例示した。
第6実施例は、本成約条件情報に基づく借り換えローンの返済に関する実施例である。
【0421】
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0422】
<表示画面>
図6-1は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
図6-1左側には、限定ではなく例として、
図3-3右側のホーム画面から時間が経過し、端末20Aのユーザが借り換えローンの返済を失念し、「2021年12月2日」となった場合に表示されるホーム画面の一例を示す。
【0423】
このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、「11月分」の借り換えローン返済が完了していないことに基づいて、督促通知NT13が表示されている。
【0424】
督促通知NT13では、通知の左側にユーザに確認漏れの注意喚起を促すためのエクスクラメーションマークアイコンが表示されるように構成されている。また、その右側にはローンの返済が滞っていることを示す「お支払い期日が過ぎております」というメッセージが表示されるように構成されている。
【0425】
また、このホーム画面では、契約内容表示領域CTR2の下部に、返済が滞っている金額である「延滞金額」の文字が表示され、その右方に、延滞金額が「25,000円」であることが強調表示で表示されるように構成されている。延滞金額の下には、限定ではなく例として、延滞金額をサーバ10の事業者と提携する電子マネーを用いて返済するための「返済する」の文字で示される延滞金返済ボタンPBB1が表示されるように構成されている。
【0426】
また、契約内容表示領域CTR2では、次回返済日が「2021年12月26日」であることが表示されている。
【0427】
限定ではなく例として、ユーザによって延滞金返済ボタンPBB1がタップされると、支払いアプリケーションが起動する。
図6-1中央は、限定ではなく例として、支払いアプリケーション起動後に自動的に遷移する送金画面の一例である。
【0428】
この画面では、画面最上部中央に、支払いアプリケーションの名称である「Payment App」の文字が表示されるように構成されている。
また、アプリ内位置表示領域には、送金画面であることを示す「送金」の文字が表示されている。
【0429】
アプリ内位置表示領域の下には、送金金額を指定することをユーザに促すための「金額を指定してください」の文字が表示されるように構成されている。その下には、送金金額を指定するための金額指定領域が表示されるように構成されている。この画面では、金額指定領域には、マネーローンアプリケーションから引き継がれた延滞金額である「25,000円」が入力された状態で表示されている。
【0430】
金額指定領域の下には、送金先を示す送金先指定領域が表示されるように構成されている。この画面では、マネーローンアプリケーションから引き継がれた送金先として、マネーローンサービスの返済用電子マネー口座が送金先として表示されている。
【0431】
送金画面の最下部には、送金先指定領域において指定される電子マネー口座に、金額指定領域において設定される送金金額の電子マネーを送金するための「送金」の文字で示される電子マネー送金ボタンTBT1が表示されるように構成されている。
【0432】
限定ではなく例として、ユーザによって電子マネー送金ボタンTBT1がタップされ、電子マネーの送金に成功すると、限定ではなく例として、
図6-1右側のマネーローンアプリケーションホーム画面に表示が遷移する。
【0433】
このホーム画面では、アプリ内位置表示領域の下に、限定ではなく例として、延滞金額が返済されたことに基づいて、延滞金返済確認通知NT14が表示されている。
この延滞金返済確認通知NT14では、ベルマークアイコンの右側に、「延滞金が返済されました」のメッセージが表示されるように構成されている。
【0434】
また、契約内容表示領域CTR2では、延滞金額の表示項目が消え、貸付残高が「680,000円」に減った事が表示されている。
【0435】
そして、取引履歴表示領域THR2には、ユーザが「2021年11月13日」に貸付先から「700,000円」を借り入れたことを示す取引履歴に加えて、「2021年12月2日」に延滞金「25,000」円を返済したことを示す取引履歴が表示されている。
【0436】
<処理>
サーバ10の制御部11は、限定ではなく例として、本成約条件情報を端末20Aに送信すると(S160)、ユーザに応じて貸付ローン振込先情報を設定し、通信I/F14によって端末20Aに送信する。なお、貸付ローン振込先情報に、返済日や返済金額等の情報を含めるようにしてもよい。
【0437】
なお、端末20から貸付ローン振込先要求情報を受信したと判定する場合、サーバ10の制御部11は、設定された貸付ローン振込先情報を通信I/F14によって端末20Aに送信するようにしてもよい。
【0438】
通信I/F22によってサーバ10から貸付ローン振込先情報を受信すると、端末20の制御部21は、受信した貸付ローン振込先情報を表示部24に表示させる。
【0439】
サーバ10の制御部11は、限定ではなく例として、各月の返済日が過ぎると、不図示の銀行サーバから月次取引情報を受信する。そして、サーバ10の制御部11は、月次取引情報を参照し、各ユーザのローン返済金額が入金されたか否かを判定する。
【0440】
限定ではなく例として、端末20AのユーザA.Aと紐付けられた、貸付ローン振込先情報で指定される金融機関口座に入金が行われていないと判定する場合、サーバ10の制御部11は、乗り換えローンの返済が滞っていることを示す督促情報を通信I/F14によって端末20Aに送信する。
【0441】
通信I/F22によってサーバ10から督促情報を受信すると、端末20Aの制御部21は、受信した督促情報を表示部24に表示させる。
【0442】
<第6実施例の効果>
本実施例は、サーバ10の制御部11は、本成約条件情報(限定ではなく、第2金利情報の一例)に基づく返済金額を含む返済金額情報を通信I/F14によって端末20に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、第2金利情報に基づく返済金額を含む貸付ローン振込先情報(限定ではなく、返済金額情報の一例)を端末に送信して、第2金利情報に基づく返済金額を端末のユーザに知らせることができる。返済金額が分かるため、端末側(ユーザ側)の視点ではユーザにとって便利である。
【0443】
また、本実施例は、サーバ10の制御部11は、端末20のユーザが、貸付ローン振込先情報に基づく返済を期日内に行わない場合、返済を延滞していることを示す督促情報(限定ではなく、延滞情報の一例)を通信I/F14によって端末20に送信する制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバは、端末のユーザが、第2金利情報に基づく返済金額を含む返済金額情報に基づく返済を期日内に行わない場合、返済を延滞していることを示す延滞情報を端末に送信して、返済を行うように端末のユーザに促すことができる。
【0444】
<第6変形例(1)>
上記の実施例では、端末20Aにおいて、マネーローンアプリケーションのホーム画面にサーバ10から受信した通知を表示させる例について例示したが、これに限定されない。限定ではなく例として、サーバ10の事業者がメッセージングサービスを提供する事業者と提携している、またはサーバ10の事業者とメッセージングサービス事業者が同じ場合等において、メッセージングサービスへ通知を含むコンテンツを送信するようにしてもよい。
【0445】
図6-2は、本変形例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
図6-2左側は、限定ではなく例として、
図3-3左側と同様の借り換えプラン契約締結画面の一例である。限定ではなく例として、ユーザによって借り換え契約ボタンBT14がタップされると、代替返済振込処理の実行が始まる。
【0446】
図6-2中央には、借り換え契約ボタンBT14がタップした後、メッセージングアプリケーションにおいてマネーローンサービスの公式アカウントとのOAトークルームを確認した場合のトークルーム画面の一例を示す。
【0447】
このトークルーム画面では、画面最上部中央に、メッセージングアプリケーションの名称である「Messaging App」の文字が表示されるように構成されている。
また、アプリ内位置表示領域には、マネーローンサービスの公式アカウントとのOAトークルームであることを示す「Money Loan Service」の文字が表示されている。
【0448】
アプリ内位置表示領域の下には、トークルームにおいて送受信されるコンテンツを表示させるためのトークコンテンツ表示領域が表示されるように構成されている。
トークコンテンツ表示領域には、マネーローンサービスの公式アカウントから送信されたコンテンツが左側からの吹き出しで時系列順に上から下に表示されるように構成されている。この画面では、テキストコンテンツCT1からテキストコンテンツCT7までのコンテンツがマネーローンサービスの公式アカウントから送信されていることが表示されている。
【0449】
また、トークコンテンツ表示領域の中央部分には、不図示のメッセージングサーバからのシステムコンテンツが表示されるように構成されている。この画面では、「2021年11月11日」から「2021年11月13日」までの日付が変わったことを示すシステムコンテンツが表示されている。
【0450】
限定ではなく例として、テキストコンテンツCT1では、限定ではなく例として、
図3-2右側における借り換え申し込み終了ボタンBT13がタップされたことに基づいて、「借りかえプラン申し込み手続きが完了しました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT2では、プレ成約条件が算出されたことに基づいて、審査完了通知と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT3では、限定ではなく例として、
図3-3左側の借り換えプラン契約締結画面における借り換え契約ボタンBT14がタップされたことに基づいて、「借りかえプランの契約に同意いただきました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT4では、「XX信販」への代替返済振込処理が完了したことに基づいて、振込処理完了通知NT7と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT5では、「YYローン」への代替返済振込処理が完了したことに基づいて、振込処理完了通知NT8と対応する文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT6では、全ての借入先への代替返済振込処理が完了したことに基づいて、「他社借入先への返済が全て完了しました」の文字が表示されている。
また、限定ではなく例として、テキストコンテンツCT6では、本成約条件が算出されたことに基づいて、契約書面再交付通知NT9と対応する文字が表示されている。また、テキストコンテンツCT6では、本成約条件を確認するための、「確認」の文字で示される本成約条件確認ボタンCFB1が表示されるように構成されている。
【0451】
限定ではなく例として、ユーザによって本成約条件確認ボタンCFB1がタップされると、限定ではなく例として、
図6-2右側のマネーローンアプリケーションホーム画面に表示が遷移する。この画面は、
図3-3右側のホーム画面と対応する画面であるが、契約内容表示領域CTR2の上方に契約書面再交付通知NT9等は表示されていない。
【0452】
なお、上記の画面図では、メッセージングアプリケーションのOAトークルームにおいてマネーローンアプリケーションの通知を行う例を例示したが、これに限定されない。
通知の方法としては、限定ではなく例として、以下の方法が挙げられる。
・マネーローンアプリケーションのシステム通知(プッシュ通知)。
・マネーローンアプリケーション内でのポップアップ通知(アプリケーションを開くと通知)。
・マネーローンアプリケーションのお知らせ領域(限定ではなく例として、ホーム画面上段)に通知。
・メッセージングアプリケーションのシステム通知(プッシュ通知)。
・メッセージングアプリケーションのスマートチャンネル領域(限定ではなく例として、トークリスト最上段)に表示。
・メッセージングアプリケーションのタイムラインに表示。
・メッセージングアプリケーションのOAトークルームに表示。
・支払いアプリケーションのシステム通知(プッシュ通知)。
・支払いアプリケーションのお知らせ領域(限定ではなく例として、お知らせ画面)に通知。
・上記通知方法の任意の組み合わせ。
【0453】
<その他>
上記の実施例で説明した、マネーローンアプリケーションで実現した内容は、メッセージングアプリケーション等の他のアプリケーションでも同様に実現可能である。
【符号の説明】
【0454】
1 通信システム
10 サーバ
20 端末
30 ネットワーク