特開 2024-53104 車両提供方法、制御プログラム及び車両提供システム

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

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

(11)【公開番号】P2024053104

(43)【公開日】2024-04-12

(54)【発明の名称】車両提供方法、制御プログラム及び車両提供システム

(51)【国際特許分類】

   G06Q 50/43 20240101AFI20240405BHJP

【ＦＩ】

G06Q50/43

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

【公開請求】

(21)【出願番号】P 2024036808

(22)【出願日】2024-03-11

(71)【出願人】

【識別番号】524092800

【氏名又は名称】株式会社ＩＤＯＭ ＣａａＳ Ｔｅｃｈｎｏｌｏｇｙ

(74)【代理人】

【識別番号】100150072

【弁理士】

【氏名又は名称】藤原 賢司

(74)【代理人】

【識別番号】100179213

【弁理士】

【氏名又は名称】山下 未知子

(72)【発明者】

【氏名】山畑 直樹

(72)【発明者】

【氏名】中津川 賢人

(57)【要約】

【課題】支払い能力が比較的低いユーザにも車両の提供が可能な車両提供方法、制御プログラム及び車両提供システムを提供する。
【解決手段】本発明のある局面に従う車両提供方法は、コンピュータが、ユーザ情報を取得するステップと、車両の提供に関する、ユーザ情報に基づいた審査の結果を取得するステップと、上記結果に基づいて、第１スキームに従った車両の提供、又は、第２スキームに従った車両の提供を提示するステップとを実行することを含む。第１スキームにおいては、車両の車検証における使用者としての名義人がユーザである。第２スキームにおいては、上記使用者としての名義人がユーザ以外である。
【選択図】図１

【特許請求の範囲】

【請求項1】

コンピュータが、
ユーザ情報を取得するステップと、
車両の提供に関する、前記ユーザ情報に基づいた審査の結果を取得するステップと、
前記結果に基づいて、第１スキームに従った前記車両の提供、又は、第２スキームに従った前記車両の提供を提示するステップとを実行することを含み、
前記第１スキームにおいては、前記車両の車検証における使用者としての名義人が前記ユーザであり、
前記第２スキームにおいては、前記使用者としての名義人が前記ユーザ以外である、車両提供方法。

【請求項2】

前記コンピュータが、
前記第２スキームに従った前記車両の提供が行なわれた後に、車両提供のスキームを前記第２スキームから前記第１スキームへ変更するステップを実行することをさらに含む、請求項１に記載の車両提供方法。

【請求項3】

前記コンピュータが、
前記第２スキームに従った前記車両の提供が行なわれた後に、前記ユーザ情報を更新するステップと、
更新された前記ユーザ情報が所定条件を満たす場合に、前記車両提供のスキームを前記第２スキームから前記第１スキームへ変更可能である旨を提示するステップとを実行することをさらに含む、請求項２に記載の車両提供方法。

【請求項4】

前記審査が、前記第１スキームに従った前記車両の提供の可否に関する審査であり、
前記所定条件が、前記ユーザが提供を希望する車両の価格によって異なる、請求項３に記載の車両提供方法。

【請求項5】

前記審査が、前記第１スキームに従った前記車両の提供の可否に関する審査であり、
前記第２スキームに従った前記車両の提供が提示される場合に、前記ユーザが前記第１スキームに従って提供を希望する前記車両に基づいて、前記第２スキームに従って提供可能な車両が提示される、請求項１から請求項４のいずれか１項に記載の車両提供方法。

【請求項6】

前記車両提供のスキームが前記第２スキームから前記第１スキームへ変更された場合と、前記車両提供のスキームが最初から前記第１スキームである場合とで、前記第１スキームにおける前記車両の提供条件が異なる、請求項２から請求項４のいずれか１項に記載の車両提供方法。

【請求項7】

前記コンピュータが、
前記車両提供のスキームを前記第２スキームから前記第１スキームへ変更するのに要する期間を提示するステップと、
更新された前記ユーザ情報に基づいて前記期間を変更するステップとを実行することをさらに含む、請求項３又は請求項４に記載の車両提供方法。

【請求項8】

前記車両提供のスキームが最初から前記第１スキームである場合においては、前記車検証における所有者としての名義人が信販会社であり、
前記車両提供のスキームが前記第２スキームから前記第１スキームへ変更された場合においては、前記所有者としての名義人が前記信販会社又は自社である、請求項２から請求項４のいずれか１項に記載の車両提供方法。

【請求項9】

前記車両提供のスキームが前記第２スキームから前記第１スキームへ変更された場合に、前記第１スキームに従って提供される前記車両の納車が完了するまで、前記第２スキームに従った前記車両の提供が継続される、請求項２から請求項４のいずれか１項に記載の車両提供方法。

【請求項10】

ユーザ情報を取得するステップと、
車両の提供に関する、前記ユーザ情報に基づいた審査の結果を取得するステップと、
前記結果に基づいて、第１スキームに従った前記車両の提供、又は、第２スキームに従った前記車両の提供を提示するステップとをコンピュータに実行させ、
前記第１スキームにおいては、前記車両の車検証における使用者としての名義人が前記ユーザであり、
前記第２スキームにおいては、前記使用者としての名義人が前記ユーザ以外である、制御プログラム。

【請求項11】

ユーザ情報を取得する第１取得部と、
車両の提供に関する、前記ユーザ情報に基づいた審査の結果を取得する第２取得部と、
前記結果に基づいて、第１スキームに従った前記車両の提供、又は、第２スキームに従った前記車両の提供を提示する提示部とを備え、
前記第１スキームにおいては、前記車両の車検証における使用者としての名義人が前記ユーザであり、
前記第２スキームにおいては、前記使用者としての名義人が前記ユーザ以外である、車両提供システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両提供方法、制御プログラム及び車両提供システムに関する。

【背景技術】

【0002】

特開２０２３－１５８５２７号公報（特許文献１）は、情報処理装置を開示する。この情報処理装置は制御部を備える。制御部は、ユーザが過去に行なったリース契約に係る車両の用途又は走行距離に関する情報に基づいて、ユーザに適した車両のリースプランを提示する（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

【発明が解決しようとする課題】

【0004】

リース契約に基づいた車両の提供を受けることができるか否かの判断においては、例えば、車両の提供を希望するユーザの信用情報（例えば、支払い能力に関する情報）が考慮される。したがって、ユーザの信用情報次第では、リース契約を通じてユーザに車両が提供されない。上記特許文献１においては、このような問題の解決手段が開示されていない。

【0005】

本発明は、このような問題を解決するためになされたものであって、その目的は、支払い能力が比較的低いユーザにも車両の提供が可能な車両提供方法、制御プログラム及び車両提供システムを提供することである。

【課題を解決するための手段】

【0006】

本発明のある局面に従う車両提供方法は、コンピュータが、ユーザ情報を取得するステップと、車両の提供に関する、ユーザ情報に基づいた審査の結果を取得するステップと、上記結果に基づいて、第１スキームに従った車両の提供、又は、第２スキームに従った車両の提供を提示するステップとを実行することを含む。第１スキームにおいては、車両の車検証における使用者としての名義人がユーザである。第２スキームにおいては、上記使用者としての名義人がユーザ以外である。

【0007】

この車両提供方法においては、使用者としての名義人がユーザである第１スキームに従った車両の提供、又は、使用者としての名義人がユーザ以外である第２スキームに従った車両の提供が提示される。したがって、この車両提供方法によれば、第２スキームの提示が可能であるため、第１スキームに従った車両の提供が難しいユーザに対しても車両を提供することができる。

【0008】

上記車両提供方法は、コンピュータが、第２スキームに従った車両の提供が行なわれた後に、車両提供のスキームを第２スキームから第１スキームへ変更するステップを実行することをさらに含んでもよい。

【0009】

この車両提供方法によれば、車両提供のスキームが第２スキームから第１スキームへ変更され得るため、第２スキームに従った車両の提供が行なわれた後に、車両提供のスキームを柔軟に変更することができる。

【0010】

上記車両提供方法は、コンピュータが、第２スキームに従った車両の提供が行なわれた後に、ユーザ情報を更新するステップと、更新されたユーザ情報が所定条件を満たす場合に、車両提供のスキームを第２スキームから第１スキームへ変更可能である旨を提示するステップとを実行することをさらに含んでもよい。

【0011】

この車両提供方法によれば、更新されたユーザ情報が所定条件を満たす場合に車両提供のスキームを第２スキームから第１スキームへ変更可能である旨が提示されるため、ユーザ情報の更新状況に応じて車両提供のスキームをユーザの希望に沿うように変更することができる。

【0012】

上記車両提供方法においては、審査が、第１スキームに従った車両の提供の可否に関する審査であってもよく、所定条件が、ユーザが提供を希望する車両の価格によって異なってもよい。

【0013】

この車両提供方法によれば、ユーザが第１スキームにおいて提供を希望する車両の価格によって所定条件が異なるため、車両提供のスキームを第２スキームから第１スキームへ変更可能である旨の提示を適切なタイミングで行なうことができる。

【0014】

上記車両提供方法においては、審査が、第１スキームに従った車両の提供の可否に関する審査であってもよく、第２スキームに従った車両の提供が提示される場合に、ユーザが第１スキームに従って提供を希望する車両に基づいて、第２スキームに従って提供可能な車両が提示されてもよい。

【0015】

この車両提供方法によれば、ユーザが第１スキームに従って提供を希望する車両に基づいて第２スキームに従って提供可能な車両が提示されるため、ユーザの希望にある程度合った車両を第２スキームに従って提供可能な車両として提示することができる。

【0016】

上記車両提供方法においては、車両提供のスキームが第２スキームから第１スキームへ変更された場合と、車両提供のスキームが最初から第１スキームである場合とで、第１スキームにおける車両の提供条件が異なってもよい。

【0017】

この車両提供方法によれば、車両提供のスキームが第２スキームから第１スキームへ変更された場合と、車両提供のスキームが最初から第１スキームである場合とで、第１スキームにおける車両の提供条件が異なるため、より実情に合った提供条件に基づいて車両を提供することができる。

【0018】

上記車両提供方法は、コンピュータが、車両提供のスキームを第２スキームから第１スキームへ変更するのに要する期間を提示するステップと、更新されたユーザ情報に基づいて上記期間を変更するステップとを実行することをさらに含んでもよい。

【0019】

この車両提供方法によれば、更新されたユーザ情報に基づいて車両提供のスキームを第２スキームから第１スキームへ変更するのに要する期間が変更されるため、車両提供のスキームを第２スキームから第１スキームへ変更するのに要する期間としてより実情に合った期間を提示することができる。

【0020】

上記車両提供方法において、車両提供のスキームが最初から第１スキームである場合においては、車検証における所有者としての名義人が信販会社であってもよく、車両提供のスキームが第２スキームから第１スキームへ変更された場合においては、上記所有者としての名義人が信販会社又は自社であってもよい。

【0021】

上記車両提供方法において、車両提供のスキームが第２スキームから第１スキームへ変更された場合に、第１スキームに従って提供される車両の納車が完了するまで、第２スキームに従った車両の提供が継続されてもよい。

【0022】

この車両提供方法によれば、第１スキームに従って提供される車両の納車が完了するまで第２スキームに従った車両の提供が継続されるため、ユーザの手元に車両が存在しない期間の発生を抑制することができる。

【0023】

本発明に従う他の局面に従う制御プログラムは、ユーザ情報を取得するステップと、車両の提供に関する、ユーザ情報に基づいた審査の結果を取得するステップと、上記結果に基づいて、第１スキームに従った車両の提供、又は、第２スキームに従った車両の提供を提示するステップとをコンピュータに実行させる。第１スキームにおいては、車両の車検証における使用者としての名義人がユーザである。第２スキームにおいては、上記使用者としての名義人がユーザ以外である。

【0024】

この制御プログラムが実行されると、使用者としての名義人がユーザである第１スキームに従った車両の提供、又は、使用者としての名義人がユーザ以外である第２スキームに従った車両の提供が提示される。したがって、この制御プログラムによれば、第２スキームの提示が可能であるため、第１スキームに従った車両の提供が難しいユーザに対しても車両を提供することができる。

【0025】

本発明に従う他の局面に従う車両提供システムは、第１取得部と、第２取得部と、提示部とを備える。第１取得部は、ユーザ情報を取得する。第２取得部は、車両の提供に関する、ユーザ情報に基づいた審査の結果を取得する。提示部は、上記結果に基づいて、第１スキームに従った車両の提供、又は、第２スキームに従った車両の提供を提示する。第１スキームにおいては、車両の車検証における使用者としての名義人がユーザである。第２スキームにおいては、上記使用者としての名義人がユーザ以外である。

【0026】

この車両提供システムにおいては、使用者としての名義人がユーザである第１スキームに従った車両の提供、又は、使用者としての名義人がユーザ以外である第２スキームに従った車両の提供が提示される。したがって、この車両提供システムによれば、第２スキームの提示が可能であるため、第１スキームに従った車両の提供が難しいユーザに対しても車両を提供することができる。

【発明の効果】

【0027】

本発明によれば、支払い能力が比較的低いユーザにも車両の提供が可能な車両提供方法、制御プログラム及び車両提供システムを提供することができる。

【図面の簡単な説明】

【0028】

【図1】車両提供方法を実施するシステムを模式的に示す図である。

【図2】第１サーバのハードウェア構成を模式的に示すブロック図である。

【図3】第１ユーザ情報ＤＢを模式的に示す図である。

【図4】第２ユーザ情報ＤＢを模式的に示す図である。

【図5】第２サーバのハードウェア構成を模式的に示すブロック図である。

【図6】ユーザ端末のハードウェア構成を模式的に示すブロック図である。

【図7】貸出しスキームの決定手順の一例を示すフローチャートである。

【図8】図７のステップＳ１９０の処理を経てユーザ端末において表示される画面の一例を示す図である。

【図9】貸出しスキームの変更手順の一例を示すフローチャートである。

【図10】図９のステップＳ３４０の処理を経てユーザ端末において表示される画面の一例を示す図である。

【図11】図９のステップＳ３５０の処理を経てユーザ端末において表示される画面の一例を示す図である。

【図12】貸出しスキームの変更申込みに伴い実行される処理手順の一例を示すフローチャートである。

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

【0029】

以下、本発明の一側面に係る実施の形態（以下、「本実施の形態」とも称する。）について、図面を用いて詳細に説明する。なお、図中同一又は相当部分には同一符号を付してその説明は繰り返さない。また、各図面は、理解の容易のために、適宜対象を省略又は誇張して模式的に描かれている。

【0030】

［１．構成］
＜１－１．システムの構成＞
図１は、本実施の形態に従う車両提供方法を実施するシステムＳ１を模式的に示す図である。一般的に、カーリース契約を締結可能か否かの判断においては、例えば、車両の提供を希望するユーザの信用情報（例えば、支払い能力に関する情報）が考慮される。したがって、ユーザの信用情報次第では、カーリース契約を通じてユーザに車両が提供されない。システムＳ１は、支払い能力が比較的低いユーザにも車両の提供が可能な車両提供方法を実施する。

【0031】

図１に示されるように、システムＳ１は、第１サーバ１００と、第２サーバ２００と、ユーザ端末３００とを含んでいる。第１サーバ１００及び第２サーバ２００の各々は、例えば、汎用コンピュータによって実現される。ユーザ端末３００は、例えば、スマートフォン、タブレット又はＰＣ（Personal Computer）によって実現される。

【0032】

第１サーバ１００においては、例えば、自社（以下、「車両提供会社」とも称する。）のサービスを実現するための処理が実行される。車両提供会社は、車両をユーザに提供する会社であり、例えば、中古車販売事業、新車販売事業及びレンタカー事業を行なっている。第２サーバ２００においては、例えば、信販会社のサービスを実現するための処理が実行される。信販会社は、例えば、商品の代金立替事業及びリース事業を行なっている。ユーザ端末３００は、車両の提供を希望するユーザが所有する通信端末である。ユーザ端末３００には、車両提供会社にカーリース契約を申し込むためのアプリケーション（以下、「申込みアプリ」とも称する。）がインストールされている。

【0033】

ユーザが申込みアプリを立ち上げると、例えば、氏名、住所及び連絡先等の基本情報、希望する車種等の希望情報、並びに、年収及び借金額等の支払い能力情報といったユーザ情報の入力が要求される。ユーザ情報が入力されると、第１サーバ１００は、入力されたユーザ情報のうち信販会社における審査（与信審査）に必要な情報（以下、「審査用情報」とも称する。）を第２サーバ２００へ送信する。第２サーバ２００においては、受信された審査用情報に基づいた与信審査が行なわれる。与信審査が完了すると、第２サーバ２００から第１サーバ１００へ審査結果が送信される。第１サーバ１００においては、受信された審査結果に応じた車両提供スキーム（例えば、貸出しスキーム）をユーザへ提案するための処理が実行される。

【0034】

具体的には、審査を通じてカーリース契約の締結が可能と判断された場合には、カーリース契約（「第１スキーム」の一例）を通じた車両の提供がユーザに提案される。一方、審査を通じてカーリース契約の締結が不可能と判断された場合には、レンタカー契約（「第２スキーム」の一例）を通じた車両の提供がユーザに提案される。システムＳ１によれば、レンタカー契約（第２スキーム）の提示が可能であるため、カーリース契約（第１スキーム）に従った車両の提供が難しいユーザに対しても車両を提供することができる。

【0035】

カーリース契約とレンタカー契約との特徴的な違いについて次に説明する。カーリース契約においては車検証における使用者としての名義人がユーザになる一方、レンタカー契約においては車検証における使用者としての名義人がユーザ以外（例えば、車両提供会社）になる。与信が相対的に高いユーザに関しては使用者名義として本人が記載される一方、与信が相対的に低いユーザに関しては使用者名義として車両提供会社が記載されることで、ユーザの信用に合わせて使用者名義を変更することができる。

【0036】

カーリース契約においては支払い能力が相対的に高いと思われるユーザへ車両が提供されるため、車両の貸出期間が相対的に長期間である一方、レンタカー契約においては車両の貸出期間が相対的に短期間である。カーリース契約においては支払い能力が相対的に高いと思われるユーザへ車両が提供されるため、選択可能な車両の幅が相対的に広く（新車及び中古車の両方から選択可能）、レンタカー契約においては選択可能な車両の幅が相対的に狭い（新車からは選択できない場合が多い）。カーリース契約においてはカーリース事業を行なう会社（例えば、信販会社）へユーザが料金を支払う一方、レンタカー契約においてはレンタカー事業を行なう会社（例えば、車両提供会社）へユーザが料金を支払う。同一の車両がユーザに提供される場合において、与信が高いユーザと締結されるカーリース契約においては契約期間が長期化する傾向にあるためユーザが支払う１日当たりの料金が相対的に安い傾向にあり、一方で、レンタカー契約においてはユーザが支払う１日当たりの料金が相対的に高い傾向にある。カーリース契約を通じて提供される車両は使用者がユーザとなるため、車両のナンバーはいわゆる「わナンバー」以外であり、レンタカー契約を通じて提供される車両のナンバーは「わナンバー」である。以下、第１サーバ１００、第２サーバ２００及びユーザ端末３００の各々の構成について説明し、その後、システムＳ１における各種動作について説明する。

【0037】

＜１－２．第１サーバの構成＞
図２は、第１サーバ１００のハードウェア構成を模式的に示すブロック図である。図２に示されるように、第１サーバ１００は、制御部１１０と、通信Ｉ／Ｆ（interface）１３０と、記憶部１２０とを含んでいる。各構成は、バスを通じて電気的に接続されている。

【0038】

制御部１１０は、ＣＰＵ（Central Processing Unit）１１２、ＲＡＭ（Random Access Memory）１１４及びＲＯＭ（Read Only Memory）１１６等を含み、情報処理に応じて各構成要素の制御を行なうように構成されている。

【0039】

通信Ｉ／Ｆ１３０は、インターネット等のネットワークを通じて、第２サーバ２００及びユーザ端末３００（図１）と通信するように構成されている。通信Ｉ／Ｆ１３０は、例えば、有線ＬＡＮ（Local Area Network）モジュール又は無線ＬＡＮモジュールで構成される。

【0040】

記憶部１２０は、例えば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置で構成される。記憶部１２０は、例えば、制御プログラム１２２、第１ユーザ情報ＤＢ（database）１２４及び第２ユーザ情報ＤＢ１２６を記憶している。制御プログラム１２２がＣＰＵ１１２によって実行されることにより、第１サーバ１００における各種機能が実現される。

【0041】

図３は、第１ユーザ情報ＤＢ１２４を模式的に示す図である。図３を参照して、第１ユーザ情報ＤＢ１２４は、ユーザ端末３００から受信されたユーザ情報を管理する。第１ユーザ情報ＤＢ１２４においては、各ユーザの基本情報（氏名、住所及び電話番号等）、希望情報（希望車両等）、支払い能力情報（年収及び借金額等）及び与信スコアが対応付けて管理されている。与信スコアは、例えば、支払い能力情報等に基づいて制御部１１０によって算出される。詳細については後述するが、与信スコアは、レンタカー契約の締結後におけるユーザの支払い実績及び運転データの少なくとも一方に応じて更新される。

【0042】

図４は、第２ユーザ情報ＤＢ１２６を模式的に示す図である。図４を参照して、第２ユーザ情報ＤＢ１２６は、レンタカー契約を締結しているユーザの支払い実績情報及び運転データを管理する。第２ユーザ情報ＤＢ１２６においては、レンタカー契約を締結しているユーザ毎に、支払い実績情報（請求書番号、支払日、支払額及び支払総額等）及び各種運転データ（運転傾向、利用頻度、利用距離及び車両位置等）が対応付けて管理されている。ユーザに貸し出される車両にはＧＰＳ（Global Positioning System）等の情報を取得するＩｏＴ（Internet of Things）デバイスが搭載されており、各種運転データはＩｏＴデバイスを通じて収集される。支払い実績情報及び各種運転データは、ユーザの支払い能力を推定するために用いられ得る。

【0043】

＜１－３．第２サーバの構成＞
図５は、第２サーバ２００のハードウェア構成を模式的に示すブロック図である。図５に示されるように、第２サーバ２００は、制御部２１０と、通信Ｉ／Ｆ（interface）２３０と、記憶部２２０とを含んでいる。各構成は、バスを通じて電気的に接続されている。

【0044】

制御部２１０は、ＣＰＵ２１２、ＲＡＭ２１４及びＲＯＭ２１６等を含み、情報処理に応じて各構成要素の制御を行なうように構成されている。

【0045】

通信Ｉ／Ｆ２３０は、インターネット等のネットワークを通じて、第１サーバ１００（図１）と通信するように構成されている。通信Ｉ／Ｆ２３０は、例えば、有線ＬＡＮモジュール又は無線ＬＡＮモジュールで構成される。

【0046】

記憶部２２０は、例えば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置で構成される。記憶部２２０は、例えば、制御プログラム２２２及び信用情報ＤＢ２２４を記憶している。制御プログラム２２２がＣＰＵ２１２によって実行されることにより、第２サーバ２００における各種機能が実現される。信用情報ＤＢ２２４は、与信審査において利用される各ユーザの信用情報を管理する。信用情報の例としては、公共料金の支払い実績、並びに、クレジットカード及びローンの契約状況及び支払い状況等に関する情報が挙げられる。

【0047】

＜１－４．ユーザ端末の構成＞
図６は、ユーザ端末３００のハードウェア構成を模式的に示すブロック図である。図６に示されるように、ユーザ端末３００は、制御部３１０と、通信Ｉ／Ｆ３３０と、操作部３４０と、ディスプレイ３５０と、記憶部３２０とを含んでいる。ユーザ端末３００において、各構成はバスを通じて電気的に接続されている。

【0048】

制御部３１０は、ＣＰＵ、ＲＡＭ及びＲＯＭ等を含み、情報処理に応じて各構成要素の制御を行なうように構成されている。通信Ｉ／Ｆ３３０は、インターネット等のネットワークを通じて、第１サーバ１００（図１）と通信するように構成されている。通信Ｉ／Ｆ３３０は、例えば、有線ＬＡＮモジュール又は無線ＬＡＮモジュールで構成される。

【0049】

操作部３４０は、ユーザからの入力を受け付けるように構成されている。操作部３４０は、例えば、タッチパネル、キーボード、マウス及びマイクの一部又は全部で構成される。ユーザ情報の入力等の各種操作は、例えば、操作部３４０を通じて行なわれる。

【0050】

ディスプレイ３５０は、画像を表示するように構成されている。ディスプレイ３５０は、例えば、液晶モニタ又は有機ＥＬ（Electro Luminescence）モニタ等のモニタで構成される。ディスプレイ３５０は、例えば、第１サーバ１００によって提案される車両提供スキームに関する情報を表示する。

【0051】

記憶部３２０は、例えば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置である。記憶部３２０は、例えば、制御プログラム３２２を記憶している。制御プログラム３２２が制御部３１０のＣＰＵによって実行されることにより、ユーザ端末３００における各種機能が実現される。

【0052】

［２．動作］
＜２－１．貸出しスキームの決定動作＞
図７は、貸出しスキームの決定手順の一例を示すフローチャートである。図７の左側のフローチャートに示される処理は第１サーバ１００の制御部１１０によって実行され、図７の右側のフローチャートに示される処理は第２サーバ２００の制御部２１０によって実行される。

【0053】

図７の左側のフローチャートを参照して、第１サーバ１００の制御部１１０は、ユーザ端末３００からユーザ情報を受信したか否かを判定する（ステップＳ１００）。ユーザ端末３００からユーザ情報が受信されていないと判定されると（ステップＳ１００においてＮＯ）、制御部１１０は、再びステップＳ１００の処理を実行する。

【0054】

一方、ユーザ端末３００からユーザ情報が受信されたと判定されると（ステップＳ１００においてＹＥＳ）、制御部１１０は、受信されたユーザ情報から与信審査に必要な情報（審査用情報）を抽出し、審査用情報を第２サーバ２００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ１１０）。なお、受信されたユーザ情報は、制御部１１０によって第１ユーザ情報ＤＢ１２４に追加される。また、審査用情報は、例えば、基本情報、希望情報及び支払い能力情報に含まれる情報の全部又は一部である。

【0055】

その後、制御部１１０は、審査結果が第２サーバ２００から受信されたか否かを判定する（ステップＳ１２０）。審査結果としては、カーリース契約締結可能という結果と、カーリース契約締結不可能という結果とがある。審査結果が第２サーバ２００から受信されていないと判定されると（ステップＳ１２０においてＮＯ）、制御部１１０は、再びステップＳ１２０の処理を実行する。

【0056】

一方、審査結果が第２サーバ２００から受信されたと判定されると（ステップＳ１２０においてＹＥＳ）、制御部１１０は、受信された審査結果に基づいてカーリース契約の締結が可能か否かを判定する（ステップＳ１３０）。すなわち、制御部１１０は、審査結果がカーリース契約締結可能を示すか、審査結果がカーリース契約締結不可能を示すかを判定する。

【0057】

審査結果がカーリース契約締結可能を示す場合には（ステップＳ１３０においてＹＥＳ）、制御部１１０が、カーリース契約を締結可能である旨を示す画面データをユーザ端末３００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ１４０）。画面データは、ユーザ端末３００のディスプレイ３５０に画面を表示させるためのデータであり、例えば、ＨＴＭＬ（Hyper Text Markup Language）ファイルによって構成される。なお、審査結果がカーリース契約締結可能を示す場合にカーリース契約が締結されると、車検証における所有者としての名義人が信販会社になる。

【0058】

一方、審査結果がカーリース契約締結不可能を示す場合には（ステップＳ１３０においてＮＯ）、制御部１１０が、第１ユーザ情報ＤＢ１２４を参照することによって与信スコアを算出する（ステップＳ１５０）。算出された与信スコアは、第１ユーザ情報ＤＢ１２４に反映される。制御部１１０は、算出された与信スコアと、ユーザがカーリース契約での提供を希望していた車両をレンタカー契約で提供するための必要スコア（以下、「第１必要スコア」とも称する。）とを比較することによって、レンタカー契約を通じて車両を提供することができるか否かを判定する（ステップＳ１６０）。各車両の第１必要スコアは、予め決定されており、記憶部１２０に記憶されている。また、第１必要スコアは、車両の価格によって異なる。例えば、高額な車両の第１必要スコアは高く、低額な車両の第１必要スコアは低い。

【0059】

レンタカー契約を通じて車両を提供することができないと判定されると（ステップＳ１６０においてＮＯ）、制御部１１０は、カーリース契約及びレンタカー契約を締結することができない旨を示す画面データをユーザ端末３００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ１７０）。

【0060】

一方、レンタカー契約を通じて車両を提供することができると判定されると（ステップＳ１６０においてＹＥＳ）、制御部１１０は、「所要期間」を算出する（ステップＳ１８０）。システムＳ１においては、カーリース契約の締結が一旦拒否されたユーザであっても、レンタカー契約が一定期間継続された場合に、カーリース契約の締結が可能となる可能性がある。「所要期間」とは、レンタカー契約からカーリース契約への変更に要する期間のことをいう。詳細については後述するが、「所要期間」は、ユーザの状況（レンタカー契約における料金の支払い状況、運転傾向等）に応じて定期的に更新される。所要期間は、ユーザが希望する車両に関しレンタカー契約からカーリース契約へ切り替えるための必要スコア（以下、「第２必要スコア」とも称する。）、現在の与信スコア、及び、レンタカー契約を通じた与信スコア向上の予測等に基づいて算出される。

【0061】

その後、制御部１１０は、カーリース契約を締結することができない旨、及び、レンタカー契約であれば締結可能である旨等を示す画面データをユーザ端末３００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ１９０）。なお、ステップＳ１６０の前の段階で、レンタルしたい車両がユーザに問い合わされてもよい。例えば、ユーザによって選択された車両の第１必要スコアが低い場合には、ステップＳ１６０においてＹＥＳと判定されやすくなり、ユーザによって選択された車両の第１必要スコアが高い場合には、ステップＳ１６０においてＮＯと判定されやすくなる。

【0062】

図８は、図７のステップＳ１９０の処理を経てユーザ端末３００において表示される画面の一例を示す図である。図８に示されるように、ユーザ端末３００のディスプレイ３５０には、画面ＩＭ１が表示されている。画面ＩＭ１には、メッセージＭＳ１，ＭＳ２，ＭＳ３及びボタンＢＴ１，ＢＴ２が表示されている。メッセージＭＳ１は、カーリース契約を締結することができない旨を示している。

【0063】

メッセージＭＳ２は、レンタカー契約であれば締結可能である旨を示している。また、メッセージＭＳ２は、レンタカー契約可能な車両の種類を特定可能な情報（メーカー名及び車種名等）を含んでいる。この場合に、レンタカー契約の対象となる車両の種類は、ユーザがカーリース契約に従って提供を希望していた車両の種類に基づいて決定される。具体的には、レンタカー契約の対象となる車両としては、例えば、ユーザがカーリース契約に従って提供を希望していた車両と価格帯及び車両タイプ（スポーツカー、軽自動車、ミニバン、ＳＵＶ等）の少なくとも一方が近い車両が選択される。これにより、ユーザの希望にある程度合った車両をレンタカー契約に従って提供可能な車両として提示することができる。また、価格帯が近い車両に関するレンタカー契約が締結された場合には、レンタカー契約における支払い状況を確認することによって、そのような車両価格に関するユーザの支払い可否を確認することができる。なお、メッセージＭＳ２において複数の車両が提示され、ユーザが複数の車両からレンタルする車両を選択できるような構成であってもよい。この場合に、メッセージＭＳ２において提示される複数の車両の各々の第１必要スコアは、ユーザの現在の与信スコアよりも低い。ユーザが複数の車両からレンタルする車両を選択できる場合には、ユーザは、より自分の希望に合った車両をレンタルすることができる。

【0064】

メッセージＭＳ３は、レンタカー契約を一定期間継続するとカーリース契約の締結が可能となる可能性がある旨を示している。カーリース契約への変更に要する期間（所要期間）は、例えば、レンタカー契約の対象車両の価格及びユーザの与信スコアによって算出される。例えば、ユーザがレンタカー契約を通じて高額な車両を借りた場合には、ユーザがレンタカー契約を通じて低額な車両を借りた場合と比較して、支払い実績が早く積み上がるため、所要期間が短期間になる。詳細については後述するが、ユーザの与信スコアは、レンタカー契約を通じた支払い実績、レンタカー契約を通じて提供された車両の運転データ、及び、コミュニケーションデータ（車両提供会社とユーザとの間での通話履歴、メッセージアプリでのやりとりの履歴等）の少なくとも一部を参照することによって更新される。所要期間は、与信スコアが更新されると、更新後の与信スコアに基づいて再計算される。

【0065】

ユーザは、例えば、ボタンＢＴ１をタップすることによって、レンタカー契約の締結を申し込むことができる。また、ユーザは、例えば、ボタンＢＴ２をタップすることによってレンタカー契約の締結を拒否することができる。なお、これらの情報のうちの一部は表示されなくてもよく、例えば、所要期間に関する情報が表示されなくてもよい。

【0066】

図７の右側のフローチャートを参照して、第２サーバ２００の制御部２１０は、第１サーバ１００から審査用情報を受信したか否かを判定する（ステップＳ２００）。審査用情報が受信されていないと判定されると（ステップＳ２００においてＮＯ）、制御部２１０は、再びステップＳ２００の処理を実行する。

【0067】

一方、審査用情報が受信されたと判定されると（ステップＳ２００においてＹＥＳ）、制御部２１０は、与信審査のための処理を実行する（ステップＳ２１０）。制御部２１０は、例えば、信用情報ＤＢ２２４に格納されている信用情報にアクセスすることによってユーザに関する与信審査を行なう。与信審査が完了すると、制御部２１０は、審査結果を第１サーバ１００へ送信するように通信Ｉ／Ｆ２３０を制御する（ステップＳ２２０）。

【0068】

このように、システムＳ１においては、カーリース契約に従った車両の提供、又は、レンタカー契約に従った車両の提供がユーザに提示される。したがって、システムＳ１によれば、レンタカー契約の提示が可能であるため、カーリース契約に従った車両の提供が難しいユーザに対しても車両を提供することができる。

【0069】

＜２－２．レンタカー契約（第２スキーム）に従った車両提供中の動作＞
図９は、貸出しスキームの変更手順の一例を示すフローチャートである。このフローチャートに示される処理は、第１サーバ１００の制御部１１０によって所定周期で実行され、例えば、レンタカー代金の支払期限日毎に実行される。

【0070】

図９を参照して、第１サーバ１００の制御部１１０は、レンタカー代金の入金情報（支払い実績情報）及び各種運転データが取得されたか否かを判定する（ステップＳ３００）。制御部１１０は、例えば、自社内の経理システムにアクセスすることによってレンタカー代金の入金情報を取得し、レンタカー契約の対象となっている車両から各種運転データを受信することによって各種運転データを取得する。

【0071】

レンタカー代金の入金情報及び各種運転データが取得されていないと判定されると（ステップＳ３００においてＮＯ）、制御部１１０は、ステップＳ３００の処理を再び実行する。一方、レンタカー代金の入金情報及び各種運転データが取得されたと判定されると（ステップＳ３００においてＹＥＳ）、制御部１１０は、取得された情報が反映されるように、第１ユーザ情報ＤＢ１２４及び第２ユーザ情報ＤＢ１２６の更新処理を実行する（ステップＳ３１０）。例えば、制御部１１０は、レンタカー代金の入金情報及び各種運転データが反映されるように第２ユーザ情報ＤＢ１２６を更新すると共に、更新後の第２ユーザ情報ＤＢ１２６を踏まえた与信スコアを再計算し第１ユーザ情報ＤＢ１２４を更新する。

【0072】

制御部１１０は、更新後の与信スコアに基づいて所要期間（カーリース契約への変更に要する期間）を再計算する（ステップＳ３２０）。例えば、定期的に確実に入金が行なわれている場合には、定期的に確実に入金が行なわれていない場合と比較して、所要期間が短くなる。また、法令を遵守した運転が行なわれている場合には、法令を遵守した運転が行なわれていない場合と比較して、所要期間が短くなる。また、運転データに基づいて自宅住所、勤務先住所に関してユーザが虚偽の申告をしている可能性が低いと判定される場合には、運転データに基づいて自宅住所、勤務先住所に関してユーザが虚偽の申告をしている可能性が高いと判定される場合と比較して、所要期間が短くなる。これにより、車両提供のスキームをレンタカー契約からカーリース契約へ変更するのに要する期間としてより実情に合った期間を提示することができる。なお、運転データに基づいて自宅住所、勤務先住所に関して虚偽の申告をしている可能性が高いと判定された場合には、レンタカー契約自体が即解約され、貸し出している車両が即回収されてもよい。

【0073】

制御部１１０は、最新の与信スコアが希望車両の第２必要スコアよりも大きいか否かを判定する（ステップＳ３３０）。なお、各車両の第２必要スコアは、予め決定されており、記憶部１２０に記憶されている。また、第２必要スコアは、車両の価格によって異なる。例えば、高額な車両の第２必要スコアは高く、低額な車両の第２必要スコアは低い。

【0074】

最新の与信スコアが希望車両の第２必要スコアよりも大きいと判定されると（ステップＳ３３０においてＹＥＳ）、制御部１１０は、貸出しスキームの変更が可能である旨、及び、車両提供の条件を示す画面データをユーザ端末３００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ３４０）。

【0075】

図１０は、図９のステップＳ３４０の処理を経てユーザ端末３００において表示される画面の一例を示す図である。図１０に示されるように、ユーザ端末３００のディスプレイ３５０には、画面ＩＭ２が表示されている。画面ＩＭ２には、メッセージＭＳ４，ＭＳ５及びボタンＢＴ３，ＢＴ４が表示されている。メッセージＭＳ４は、レンタカー契約からカーリース契約への変更が可能である旨を示している。

【0076】

メッセージＭＳ５は、貸出しスキームがカーリース契約へ変更された場合における車両提供の条件を示している。ここで、貸出しスキームがレンタカー契約からカーリース契約へ変更された場合と、貸出しスキームが最初からカーリース契約である場合とでは、カーリース契約における車両の提供条件が異なる。例えば、貸出しスキームがレンタカー契約からカーリース契約へ変更された場合の方が、貸出しスキームが最初からカーリース契約である場合と比較して、月々の支払い額が高い。これにより、より実情に合った提供条件に基づいて車両をユーザに提供することができる。

【0077】

ユーザは、例えば、ボタンＢＴ３をタップすることによって、レンタカー契約からカーリース契約への変更を申し込むことができる。また、ユーザは、例えば、ボタンＢＴ４をタップすることによってレンタカー契約からカーリース契約への変更を拒否することができる。レンタカー契約からカーリース契約へ変更された場合に、車検証における所有者としての名義人は、車両提供会社であってもよいし、信販会社であってもよい。例えば、車検証における所有者としての名義人が車両提供会社になる場合と、車検証における所有者としての名義人が信販会社になる場合とで、希望車両の必要スコアが異なっていてもよい。例えば、車検証における所有者としての名義人が車両提供会社になる場合に、車検証における所有者としての名義人が信販会社になる場合と比較して、希望車両の必要スコアが低くてもよい。

【0078】

再び図９を参照して、ステップＳ３３０において、最新の与信スコアが希望車両の第２必要スコア以下であると判定されると（ステップＳ３３０においてＮＯ）、制御部１１０は、貸出しスキームの変更が不可能である旨、及び、最新の所要期間を示す画面データをユーザ端末３００へ送信するように通信Ｉ／Ｆ１３０を制御する（ステップＳ３５０）。

【0079】

図１１は、図９のステップＳ３５０の処理を経てユーザ端末３００において表示される画面の一例を示す図である。図１１に示されるように、ユーザ端末３００のディスプレイ３５０には、画面ＩＭ３が表示されている。画面ＩＭ３には、メッセージＭＳ６が表示されている。メッセージＭＳ６は、貸出しスキームの変更が不可能である旨、及び、最新の所要期間を示している。また、メッセージＭＳ６は、貸出しスキーム変更のための必要スコア、及び、現在の与信スコアの情報を含む。また、メッセージＭＳ６は、与信スコアを向上させるためのアクションを示す情報（例えば、「駐車場情報を入力することでスコアアップ」）を含む。なお、これらの情報のうちの一部は表示されなくてもよく、例えば、所要期間に関する情報が表示されなくてもよい。

【0080】

このように、システムＳ１によれば、車両提供のスキームがレンタカー契約からカーリース契約へ変更され得るため、レンタカー契約に従った車両の提供が行なわれた後に、車両提供のスキームを柔軟に変更することができる。

【0081】

また、システムＳ１によれば、更新されたユーザ情報（例えば、与信スコア）が所定条件（例えば、希望車両の必要スコア）を満たす場合（超えている場合）に車両提供のスキームをレンタカー契約からカーリース契約へ変更可能である旨が提示されるため、ユーザ情報の更新状況に応じて車両提供のスキームをユーザの希望に沿うように変更することができる。

【0082】

図１２は、貸出しスキームの変更申込みに伴い実行される処理手順の一例を示すフローチャートである。このフローチャートに示される処理は、第１サーバ１００の制御部１１０によって実行される。

【0083】

図１２を参照して、第１サーバ１００の制御部１１０は、貸出しスキームの変更申込みを受け付けたか否かを判定する（ステップＳ４００）。貸出しスキームの変更申込みを受け付けていないと判定されると（ステップＳ４００においてＮＯ）、制御部１１０は、ステップＳ４００の処理を再び実行する。

【0084】

一方、貸出しスキームの変更申込みを受け付けたと判定されると（ステップＳ４００においてＹＥＳ）、制御部１１０は、カーリース契約対象の車両を手配するための処理、及び、納車のための処理を実行する（ステップＳ４１０）。これらの処理には、例えば、カーリース契約の対象車両の選択を受け付ける処理、及び、車両に追加するオプションの選択を受け付ける処理等も含まれる。制御部１１０は、ユーザへの納車が完了したか否かを判定する（ステップＳ４２０）。制御部１１０は、例えば、車両の納車情報を管理する自社のシステムにアクセスすることによって、納車が完了したか否かを判定する。

【0085】

納車が完了していないと判定されると（ステップＳ４２０においてＮＯ）、制御部１１０は、再びステップＳ４２０の処理を実行する。一方、納車が完了したと判定されると（ステップＳ４２０においてＹＥＳ）、制御部１１０は、レンタカー契約（第２スキーム）の解約処理を実行する（ステップＳ４３０）。例えば、制御部１１０は、第１ユーザ情報ＤＢ１２４及び第２ユーザ情報ＤＢ１２６の更新を行なう。

【0086】

このように、システムＳ１によれば、カーリース契約に従って提供される車両の納車が完了するまでレンタカー契約に従った車両の提供が継続されるため、ユーザの手元に車両が存在しない期間の発生を抑制することができる。なお、納車が完了するまでレンタカー契約が継続するか否かは、ユーザが選択可能であってもよい。例えば、カーリース契約への変更申込み後は、レンタカー契約における料金が減額されてもよい。

【0087】

［３．特徴］
以上のように、本実施の形態に従うシステムＳ１においては、使用者としての名義人がユーザであるカーリース契約に従った車両の提供、又は、使用者としての名義人がユーザ以外であるレンタカー契約に従った車両の提供がユーザに提示される。したがって、システムＳ１によれば、レンタカー契約の提示が可能であるため、カーリース契約に従った車両の提供が難しいユーザに対しても車両を提供することができる。

【0088】

［４．他の実施の形態］
上記実施の形態の思想は、以上で説明された実施の形態に限定されない。以下、上記実施の形態の思想を適用できる他の実施の形態の例について説明する。

【0089】

＜４－１＞
上記実施の形態においては、第１スキームの一例としてカーリース契約が挙げられた。しかしながら、第１スキームは必ずしもカーリース契約でなくてもよい。第１スキームは、例えば、ローン契約であってもよい。ローン契約に従って車両がユーザに提供される場合には、車検証における使用者としての名義人がユーザとなり、車検証における所有者としての名義人はローン会社（信販会社）又はユーザとなる。

【0090】

＜４－２＞
また、上記実施の形態においては、申込みアプリを通じて車両提供スキームをユーザ端末３００のディスプレイ３５０に表示させることによって、車両提供スキームがユーザへ提示された。しかしながら、車両提供スキームの提示方法はこれに限定されない。例えば、申込みアプリ以外の一般的なメッセージアプリを通じて車両提供スキームがユーザへ提示されてもよいし、電話を通じて車両提供スキームがユーザへ提示されてもよい。また、ユーザ端末３００は、必ずしもユーザが所有する端末でなくてもよい。例えば、ユーザ端末３００は、車両提供会社が店舗に備えている端末であってもよい。店舗に備えられた端末を通じてユーザ又は店舗スタッフがユーザ情報を入力し、審査結果が当該端末のディスプレイに表示されてもよい。審査結果は、口頭で店舗スタッフからユーザへ伝えられてもよいし、後日電話又はメッセージアプリを通じて店舗スタッフからユーザへ伝えられてもよい。

【0091】

＜４－３＞
また、上記実施の形態において、レンタカー契約からカーリース契約への変更が行なわれた場合に、レンタカー契約期間中にユーザによって支払われた料金の一部がユーザへ返還されてもよい。

【0092】

＜４－４＞
また、上記実施の形態において、支払い実績を早く積むために、レンタカー契約において通常の料金よりも高い料金を支払うことが可能であってもよい。この場合には、例えば、レンタカー契約からカーリース契約への変更が行なわれた場合に、通常よりも多く支払った額の少なくとも一部がユーザへ返還される。

【0093】

＜４－５＞
また、上記実施の形態において、カーリース契約の解約手数料は、レンタカー契約の解約手数料よりも高額であってもよい。また、例えば、料金未払いが続くことで契約が強制的に解約される場合に、カーリース契約解約のための未払いの回数がレンタカー契約解約のための未払いの回数よりも少なくてもよい。カーリース契約の対象車両は、レンタカー契約の対象車両と比較して、一般的に高額なためである。また、レンタカー契約からカーリース契約へ変更となったユーザが、再びカーリース契約を申し込む場合には、以前の第２ユーザ情報ＤＢ１２６の情報を加味して与信審査が行なわれてもよい。

【0094】

＜４－６＞
また、上記実施の形態においては、審査用情報に基づいた与信審査が第２サーバ２００において行なわれた。すなわち、与信審査が信販会社によって行なわれた。しかしながら、与信審査は必ずしも信販会社によって行なわれなくてもよい。例えば、車両提供会社（自社）がリース事業を行ない、第１サーバ１００において審査用情報に基づいた与信審査が行なわれてもよい。この場合には、例えば、図７の左側に示されるフローチャートにおいて、ステップＳ１１０，Ｓ１２０の処理の代わりに、ステップＳ２１０の処理（審査用情報に基づいた与信審査処理）が実行される。与信審査処理においては、審査用情報に基づいた与信スコアの算出が行なわれる。ステップＳ１３０においては、算出された与信スコアが、ユーザが所望する車両のカーリース契約のために必要なスコア（以下、「第３必要スコア」とも称する。）よりも大きいか否かが判定される。算出された与信スコアが第３必要スコアよりも大きいと判定されるとステップＳ１４０に進み、算出された与信スコアが第３必要スコア以下であると判定されるとステップＳ１６０に進む。なお、この場合には、与信スコアが既に算出されているため、ステップＳ１５０の処理が実行されない。また、この場合にカーリース契約が行なわれるときは、カーリース契約を通じて提供される車両の車検証における所有者としての名義人が車両提供会社になる。

【0095】

以上、本発明の実施の形態について例示的に説明した。すなわち、例示的な説明のために、詳細な説明及び添付の図面が開示された。よって、詳細な説明及び添付の図面に記載された構成要素の中には、課題解決のために必須でない構成要素が含まれることがある。したがって、それらの必須でない構成要素が詳細な説明及び添付の図面に記載されているからといって、それらの必須でない構成要素が必須であると直ちに認定されるべきではない。

【0096】

また、上記実施の形態は、あらゆる点において本発明の例示にすぎない。上記実施の形態は、本発明の範囲内において、種々の改良や変更が可能である。例えば、いずれかの実施の形態の少なくとも一部の構成と、他のいずれかの実施の形態の少なくとも一部の構成とが組み合わされてもよい。すなわち、本発明の実施にあたっては、実施の形態に応じて具体的構成を適宜採用することができる。

【符号の説明】

【0097】

１００ 第１サーバ、１１０，２１０，３１０ 制御部、１１２，２１２ ＣＰＵ、１１４，２１４ ＲＡＭ、１１６，２１６ ＲＯＭ、１２０，２２０，３２０ 記憶部、１２２，２２２，３２２ 制御プログラム、１２４ 第１ユーザ情報ＤＢ、１２６ 第２ユーザ情報ＤＢ、１３０，２３０，３３０ 通信Ｉ／Ｆ、２００ 第２サーバ、２２４ 信用情報ＤＢ、３００ ユーザ端末、３４０ 操作部、３５０ ディスプレイ、ＢＴ１，ＢＴ２，ＢＴ３，ＢＴ４ ボタン、ＩＭ１，ＩＭ２，ＩＭ３ 画面、ＭＳ１，ＭＳ２，ＭＳ３，ＭＳ４，ＭＳ５，ＭＳ６ メッセージ、Ｓ１ システム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】