JP7156934B2 - 情報処理方法、プログラムおよび情報処理装置 - Google Patents

Description

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

近年、個人向けに金銭を貸し付けるサービスが知られている。例えば、特許文献１には、複数の消費者金融会社との間で契約取引を行う無人契約装置が開示されている。

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

金銭の貸付けサービスを利用する場合、ユーザは、自身の返済能力の範囲内で金銭の貸付けを受けることが可能である。ここで、金銭の貸付けを受ける際に、返済能力の範囲内で商品の購入も一緒に行うことができれば、単純に金銭の貸付けのみを受けることと比較して、より利便性が高まると考えられる。

本開示は、金銭の貸付けを受ける際に、ユーザの利便性をより高めることを可能にする情報処理方法を提供することを目的とする。

本開示の一実施形態に係る情報処理方法は、情報処理装置が行う情報処理方法であって、ユーザから、ユーザが貸し付けを希望する第１貸付額を含む金銭の貸付に関する要求を受け付けるステップと、第１貸付額とユーザのユーザ属性情報とに基づいて、ユーザに対して更に貸し付け可能な金額の上限を算出するステップと、算出された金額の上限の範囲で購入可能な商品の商品情報をユーザが利用する情報処理装置に送信するステップと、ユーザから商品を購入希望するとの指示を受けた場合に、ユーザに対して、第１貸付額と商品の価格との合計額を下限とする第２貸付額を貸し付けるステップと、を含む。

実施形態の一態様に係る通信システムの構成を示す図である。 本開示に係る情報処理装置のハードウェア構成の一例を示す図である。 第１実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す図である。 第１実施形態に係るユーザ管理ＤＢの一例を示す図である。 第１実施形態に係るユーザ行動ＤＢの一例を示す図である。 第１実施形態に係る貸付管理ＤＢの一例を示す図である。 第１実施形態に係る通信システムの処理のシーケンスの一例を示す図である。 審査に必要なユーザ属性情報の一例を示す図である。 貸付条件の表示および承諾を受け付ける画面の一例を示す図である。 貸付条件の選択をユーザから受け付ける画面の一例を示す図である。 利用規約を表示する画面の一例を示す図である。 ユーザのアカウントに対応づけられる複数の残高の具体例を説明する図である。 第２実施形態に係るサーバが行う処理手順の一例を示すフローチャートである。 第３実施形態に係る貸付管理ＤＢの一例を示す図である。 第３実施形態に係る通信システムが行う処理手順（第１貸付パターン）の一例を示すフローチャートである。 第３実施形態に係る通信システムが行う処理手順（第２貸付パターン）の一例を示すフローチャートである。 第４実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す図である。 ユーザに更に貸付け可能な金額を説明するための図である。

＜法令遵守＞
本明細書に記載の開示は、実施される場合、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、および修正をもって実施される。

本開示に係る通信システムを実施するための形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク１３０を介してサーバ１１０Ａ、サーバ１１０Ｂと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃと信用機関システム１４０と、銀行システム１５０とが接続される。

本開示において、サーバ１１０Ａと、サーバ１１０Ｂとをそれぞれ区別する必要がない場合は、サーバ１１０Ａとサーバ１１０Ｂとは、それぞれサーバ１１０と表現されてもよい。

本開示において、端末１２０Ａと、端末１２０Ｂと、端末１２０Ｃとをそれぞれ区別する必要がない場合は、端末１２０Ａと端末１２０Ｂと端末１２０Ｃとは、それぞれ端末１２０と表現されてもよい。

本開示において、サーバ１１０と、端末１２０とをそれぞれ区別する必要がない場合は、サーバ１１０と端末１２０とは、それぞれ情報処理装置２００と表現されてもよい。なお、ネットワーク１３０に接続される情報処理装置２００の数は限定されない。

サーバ１１０は、ネットワーク１３０を介してユーザが利用する端末１２０に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセンジャーを代表とするＳＮＳ（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。ユーザが端末１２０を介して所定のサービスを利用することで、サーバ１１０は１以上の端末１２０に所定のサービスを提供することができる。信用機関システム１４０は、個人のクレジットやローンの契約内容、返済、支払い状況等の取引事実に基づく個人の信用情報（借りた金銭を約束の期限までに支払うのか否かを客観的に示す情報）を管理する企業等が運営するシステムであり、金融サービスを提供する企業等からの問合せに応じて、ユーザの信用情報をサーバ１１０に通知する。

本開示において、決済サービスとは１以上のユーザが金銭または金銭相当物の授受ができるサービスを含む。限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）（以下で、一次元コードおよび二次元コードをまとめて「二次元コード等」と総称する。）、近距離無線通信（ＮＦＣ (Near Field Communication)、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Wi-Fi（登録商標）、超音波通信、赤外線通信など）を利用して決済を行うサービスを含む。また、代金の支払いを行うユーザ（支払者）の端末１２０が二次元コード等を読み取ることで決済を行うことを「ユーザ読取型コード決済」または「ＭＰＭ（Merchant Presented Mode）」と表現し、支払いを行うユーザの端末１２０が二次元コード等を表示し、表示された二次元コード等を、代金を請求する店舗側等のユーザ（販売者、請求者）の端末１２０が読み取ることで決済を行うことを「店舗読取型コード決済」または「ＣＰＭ（Consumer Presented Mode）」と表現する。なお、ＭＰＭおよびＣＰＭは、動的であってもよいし、静的であってもよい。

本開示において、金融サービスとは、１以上のユーザに金銭の貸付を行うサービスを含む。金銭は、限定でなく例として、サービスで利用可能なチャージ額、その他の金銭相当物を含む。また、金融サービスには、限定でなく例として、商品およびサービスの提供に対する対価である金銭の支払い時期を遅らせることが可能な、事実上ユーザに金銭を貸付けているに等しいサービスを含む。

必要に応じて、ユーザＸが利用する端末を端末１２０Ｘと表現し、ユーザＸまたは端末１２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー（電子マネー）の残高情報、ユーザに対応付けられたクレジットカード情報（クレジットカード番号など）を含み、これらのいずれか一つまたは、組み合わせであってもよい。

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

ネットワーク１３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１３０は、限定でなく例として、アドホック・ネットワーク（Ad Hoc Network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（Virtual Private Network：ＶＰＮ）、ローカル・エリア・ネットワーク（Local Area Network：ＬＡＮ）、ワイヤレスＬＡＮ（Wireless LAN：ＷＬＡＮ）、広域ネットワーク（Wide Area Network：ＷＡＮ）、ワイヤレスＷＡＮ（Wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（Metropolitan Area Network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮｓ（Integrated Service Digital Networks）、無線ＬＡＮｓ、ＬＴＥ（Long Term Evolution）、ＣＤＭＡ（Code Division Multiple Access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク１３０は、１つまたは複数のネットワーク１３０を含むことができる。

情報処理装置２００は、本開示に記載される機能および方法を実現できる情報処理装置であればどのような情報処理装置であってもよい。

情報処理装置２００は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、サーバ装置、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダなど）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（Personal Digital Assistant）、電子メールクライアントなど）、ウェアラブル端末（限定でなく例として、メガネ型デバイス、時計型デバイスなど）、他種のコンピュータ、またはコミュニケーションプラットホームを含む。

＜ハードウェア構成＞
図２を用いて、通信システム１に含まれる情報処理装置２００のハードウェア構成について説明する。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力インタフェース（入出力Ｉ／Ｆ）２０４と、通信インタフェース（通信Ｉ／Ｆ）２０５とを含む。情報処理装置２００のハードウェアの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により、本開示に記載される機能、および／または、方法を実現する。

プロセッサ２０１は、ストレージ２０３に記憶されるプログラムに含まれるコードまたは命令によって実現する機能および方法を実行する。プロセッサ２０１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ２０２は、ストレージ２０３からロードしたプログラムを一時的に記憶し、プロセッサ２０１に対して作業領域を提供する。メモリ２０２には、プロセッサ２０１がプログラムを実行している間に生成される各種データも一時的に含まれる。メモリ２０２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などを含む。

ストレージ２０３は、プログラムを記憶する。ストレージ２０３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどを含む。

通信Ｉ／Ｆ２０５は、ネットワーク１３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２０５は、ネットワーク１３０を介して、他の情報処理装置との通信を実行する機能を有する。通信Ｉ／Ｆ２０５は、各種データをプロセッサ２０１からの指示に従って、他の情報処理装置に送信する。また、通信Ｉ／Ｆ２０５は、他の情報処理装置から送信された各種データを受信し、プロセッサ２０１に伝達する。

入出力Ｉ／Ｆ２０４は、情報処理装置２００に対する各種操作を入力する入力装置、および、情報処理装置２００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ２０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

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

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

本開示の各実施形態のプログラムは、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、限定でなく例として、ソフトウェアプログラムやコンピュータプログラムを含む。

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

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、情報処理装置２００に提供されてもよい。

また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、本開示のプログラムは、限定でなく例として、JavaScript（登録商標）、Pythonなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Swift Kotlin、Java（登録商標）など
を用いて実装される。

情報処理装置２００における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。

情報処理装置２００における処理の少なくとも一部を、他の情報処理装置により行う構成としてもよい。この場合、プロセッサ２０１により実現される各機能部の処理のうち少なくとも一部の処理を、他の情報処理装置で行う構成としてもよい。

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

本開示では、明記されていない限り、または文脈によって示されない限り、「AおよびBの少なくとも一方」は、「Ａ、Ｂ、またはその両方」を意味する。さらに、明記されない限り、または文脈によって示されない限り、「ａ」、「ａｎ」、または「ｔｈｅ」は「１つまたは複数」を意味するものとする。したがって、本明細書では、別段に明記されない限り、または文脈によって示されない限り、「ａｎ Ａ」または「ｔｈｅ Ａ」は「１つまたは複数のＡ」を意味する。

本開示は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。また、添付の特許請求の範囲は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態または実施例の１以上の特徴と、本開示における他の実施形態または実施例の１以上の特徴との任意の組合せを包含する。

加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。

＜第１実施形態＞
第１実施形態は、ユーザから金銭の貸付に関する要求を受けた場合に、当該ユーザのユーザ属性情報および当該ユーザのユーザ行動情報の少なくとも１つに基づいて与信審査を行うことで、ユーザに金銭を貸し付ける際の条件（以下、「貸付条件」と言う。）を決定し、決定した貸付条件をユーザに提示する実施形態である。また、決定した貸付条件をユーザが受け入れた場合に、決定した貸付条件に従って金銭の貸付を行う実施形態である。

ユーザ属性情報には、限定でなく例として、ユーザの氏名、性別、年齢、職業、勤続年数、同居家族、家族の年収、他社借入額、信用機関システム１４０から取得可能な信用情報等を含む。なお、ユーザ属性情報は、ユーザ情報に含まれてもよい。

ユーザ行動情報には、限定でなく例として、電子商取引の利用履歴、決済サービスの利用履歴、ユーザの位置情報（端末１２０の位置情報）の履歴、Ｗｅｂサイトのアクセスログ等を含む。なお、ユーザ行動情報は、ユーザ情報に含まれてもよい。

貸付条件には、限定でなく例として、貸付可能な金銭の額（以下、「貸付可能額」と言う。）、金銭を貸し付ける際の利率（以下、「利率」と言う。）、および、返済期限のうち少なくともいずれかを含む。

第１実施形態によれば、金銭の貸付を希望するユーザに対して、ユーザ属性情報およびユーザ行動情報の少なくとも１つに基づいて、ユーザにとって適切な貸付可能額、利率や返済期限などの貸付条件を決定し、決定した貸付条件をユーザに通知することが可能になる。また、第１実施形態によれば、貸付条件を受け入れたユーザに対して金銭の貸付を行うことが可能になる。また、金銭の貸付を希望するユーザに対して、ユーザ属性情報およびユーザ行動情報の少なくとも１つを考慮してサーバが貸付条件を決定するので、より正確に貸付条件を決定することができ、かつ、貸付け条件の決定、貸付処理に係る処理をスムーズに行うことが可能になる。また、ユーザが金銭の貸付を希望してから実際に貸し付けがスムーズに行われるので、なめらかな金融サービスを提供することが可能になる。

＜第１実施形態の機能構成＞
図３を用いてサーバ１１０および端末１２０の機能構成を説明する。図３に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

（１）サーバの機能構成
サーバ１１０は、入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２と、制御部３１３と、記憶部３１４とを有する。入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３１３は、受付部３１５と、審査処理部３１６と、通知部３１７と、貸付処理部３１８と、返済処理部３１９とを含む。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

記憶部３１４は、プログラムと、各ユーザのアカウントを管理するユーザ管理ＤＢ（DataBase）と、ユーザ行動情報を格納するユーザ行動ＤＢと、ユーザに貸し付けた際の貸付条件を格納する貸付管理ＤＢとを記憶する。

図４Ａは、第１実施形態に係るユーザ管理ＤＢの一例を示す図である。「ユーザＩＤ」には、ユーザを一意に識別する識別子が含まれる。「ログイン情報」には、サーバ１１０にアクセスするユーザがユーザ本人であることを、サーバ１１０が確認するために必要なログインパスワード等に関する情報が含まれる。「銀行口座情報」には、サーバ１１０が提供する金融サービス、決済サービスおよび電子商取引サービスのうち少なくとも１つをユーザが利用する際に登録が必要な引落し口座に関する情報（口座番号、口座種別、支店名、口座名義等）が含まれる。

図４Ｂは、第１実施形態に係るユーザ行動ＤＢの一例を示す図である。「ユーザＩＤ」には、ユーザを一意に識別する識別子が含まれる。「電子商取引の利用履歴」には、限定でなく例として、ユーザが電子商取引を利用して取引した商品の種類、商品名、購入した商品の価格、商品を売却した際の売却額、取引が成立した日時、所定の期間における取引回数の合計、所定の期間における１回あたりの購入額の平均または全購入額の合計、所定の期間における１回あたりの売却額の平均または全売却額の合計、購入代金の支払い遅延の有無および遅延回数等を含む。「決済サービスの利用履歴」は、ユーザが、決済サービスを利用した日時、決済サービスを利用した際の決済額、所定の期間における１回あたりの決済額の平均または全決済額の合計、決済額を引き落とす際の遅延の有無および遅延回数等を含む。「位置情報の履歴」には、ユーザが利用する端末１２０から受信した位置情報がタイムスタンプと対応づけられて含まれる。

図４Ｃは、第１実施形態に係る貸付管理ＤＢの一例を示す図である。「ユーザＩＤ」には、ユーザを一意に識別する識別子が含まれる。「貸付額」には、ユーザに貸し付けた金額が含まれる。「貸付日」には、ユーザに貸し付けを実行した日が含まれる。「利率（年）」には、ユーザに貸し付けた金銭に適用される利率が含まれる。「返済期限」には、ユーザが金銭を返済すべき期日が含まれる。

受付部３１５は、ユーザから（端末１２０から）、金銭の貸付に関する要求を受け付ける機能を有する。

審査処理部３１６は、ユーザ属性情報およびユーザ行動情報の少なくとも１つに基づいて審査を行うことで、ユーザに金銭を貸し付ける際の貸付条件を決定する機能を有する。審査処理部３１６は、決定部と称してもよい。

通知部３１７は、審査処理部３１６で決定した貸付条件をユーザに（端末１２０に）通知する機能を有する。

貸付処理部３１８は、ユーザが貸付条件を受け入れたことを示す通知を端末１２０から受けた場合に、ユーザ（端末１２０）に対して貸付条件に従って金銭の貸付を行う機能を有する。また、ユーザに貸し付けを行った際の貸付条件を貸付管理ＤＢに記憶する。

返済処理部３１９は、ユーザに貸付けた金銭の返済を受け付ける機能を有する。

（２）端末の機能構成
端末１２０は、入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２と、制御部３２３と、記憶部３２４とを有する。入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３２３は、送信部３２５と、受信部３２６と、ＵＩ（UserInterface）部３２７と、位置情報測定部３２８とを含む。記憶部３２４は、プログラムを記憶する。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

送信部３２５は、ＵＩ部３２７を介してユーザから金銭の貸付を受けたい旨の指示を受けた場合に、金銭の貸付を管理するサーバ１１０に対して、金銭の借入に関する要求を送信する機能を有する。送信部３２５は、要求部と称されてもよい。また、送信部３２５は、ユーザから貸付条件を受け入れるとの指示をＵＩ部３２７を介して受けた場合、ユーザに対する貸付条件による金銭の貸付をサーバ１１０に実行させるために、ユーザが貸付条件を受け入れたことを示す通知をサーバ１１０に通知する機能を有する。当該機能は、通知部と称されてもよい。

受信部３２６は、サーバ１１０から、ユーザ属性情報およびユーザ行動情報の少なくとも１つに基づいて審査を行うことで決定された、ユーザに金銭を貸し付ける際の貸付条件の通知を受け付ける機能を有する。受信部３２６は、受付部と称されてもよい。

ＵＩ部３２７は、サーバ１１０が提供する金融サービス等に関する各種の画面を端末１２０のディスプレイに表示する機能を有する。また、当該金融サービス等に関する各種の入力をユーザから受け付ける機能を有する。また、ＵＩ部は、ユーザから金銭の貸付を受けたい旨の指示や貸付条件を受け入れるか否かの指示を受け付ける機能を有する。

位置情報測定部３２８は、端末１２０の現在位置の位置情報を測定し、サーバ１１０に通知する機能を備える。位置情報を受信したサーバ１１０は、受信した位置情報をユーザ管理ＤＢの「位置情報の履歴」に格納する。位置情報測定部３２８は、限定でなく例として、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を用いて、端末１２０の現在位置の位置情報として、該端末１２０の緯度および経度を測定する。なお、位置情報測定部３２８による端末１２０の位置情報の測定は、端末１２０の位置情報を測定できれば、どのような方法を用いてもよい。限定でなく例として、位置情報測定部３２８は、ＩＭＥＳ（Ｉｎｄｏｏｒ ＭＥｓｓａｇｉｎｇ Ｓｙｓｔｅｍ）、Ｗｉ－Ｆｉ、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｅｒ）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）、超音波などの近距離無線通信、ＬＴＥやＣＤＭＡなどの移動体通信システムなどを利用して、端末１２０の位置情報を測定してもよい。

＜第１実施形態の動作処理＞
図５を参照し、実施形態に係る通信システム１の処理について説明する。図５は、第１実施形態に係る通信システム１の処理のシーケンスの一例を示す。

ステップＳ１００で、端末１２０のＵＩ部３２７は、金銭の貸付を希望するユーザから、貸付希望額の入力を受け付ける。また、ＵＩ部３２７は、一次審査に必要なユーザ属性情報の入力を受け付ける。一次審査に必要なユーザ属性情報の一例を図６に示す。例えば、一次審査では、年収および他社借入額を入力するようにユーザに促すようにしてもよい。

ステップＳ１０１で、端末１２０の送信部３２５は、金銭の貸付に関する要求として、貸付希望額、入力されたユーザ属性情報、端末１２０を操作するユーザのユーザＩＤとをサーバ１１０に送信する。なお、ユーザＩＤは、限定でなく例として、金銭の貸付の受付を行う画面にログインする際に入力されたユーザＩＤであり、サーバ１１０が、端末１２０から受信した各種の要求がどのユーザからの要求であるのかを識別するために使用される。サーバ１１０の受付部３１５は、金銭の貸付に関する要求として、貸付希望額、ユーザ属性情報およびユーザＩＤを受け付ける。

ステップＳ１０２で、サーバ１１０の審査処理部３１６は、貸付希望額およびユーザ属性情報に基づき、一次審査を行う。一次審査では、例えば、法令で定められている総量規制（年収の１／３以上は借入をすることができないとする規制）以上に貸付を希望していないか等の審査を行う。

ステップＳ１０３で、サーバ１１０の通知部３１７は、一次審査の結果を端末１２０に通知する。端末１２０のＵＩ部３２７は、一次審査の結果を画面に表示し、一次審査を通過した場合、本審査に必要なユーザ属性情報の入力を受け付ける画面を表示する。一次審査を通過しなかった場合は、その旨を画面に表示し、処理を終了する。

ステップＳ１０４で、ＵＩ部３２７は、本審査に必要なユーザ属性情報の入力を受け付ける。本審査に必要なユーザ属性情報の一例を図６に示す。例えば、本審査では、年齢、性別、職業、勤続年数、同居家族（配偶者有無、子供の人数、扶養家族の人数等）、同居家族の年収等を入力するようにユーザに促すようにしてもよい。なお、図６に示す信用情報は、後述するステップＳ１０７の処理手順で取得する、信用機関システム１４０から取得する信用情報である。なお、ユーザ属性情報は、ステップＳ１００およびステップＳ１０４のタイミングでユーザから入力を受け付けるようにする必要は無い。例えば、既にユーザが利用している電子商取引サービスなどで既に登録済みのユーザ属性情報があれば、それを利用するようにしてもよい。つまり、ユーザ属性情報をサーバ１１０が取得できれば、ユーザ属性情報はステップＳ１０１で送信するユーザＩＤによって、サーバ１１０で特定することができる。

ステップＳ１０５で、端末１２０の送信部３２５は、入力されたユーザ属性情報と、ユーザＩＤとをサーバ１１０に送信する。サーバ１１０の受付部３１５は、入力されたユーザ属性情報およびユーザＩＤを受け付ける。

ステップＳ１０６およびステップＳ１０７で、サーバ１１０の審査処理部３１６は、一次審査の際に利用したユーザ属性情報、ステップＳ１０５で受け付けたユーザ属性情報および信用機関システム１４０から取得した信用情報を含む全てのユーザ属性情報と、ユーザ行動ＤＢから取得したユーザ行動情報とに基づき本審査を行う。

ステップＳ１０８で、審査処理部３１６は、更に、所定のアルゴリズムに従って貸付条件を決定する。サーバ１１０が決定する貸付条件には、貸付可能額、金銭を貸し付ける際の利率、および返済期限が含まれる。

ステップＳ１０９で、審査処理部３１６は、本審査の結果および貸付条件を端末１２０に通知する。

ステップＳ１１０で、端末１２０のＵＩ部３２７は、本審査を通過した場合、貸付条件を画面に表示する。本審査を通過しなかった場合は、その旨を画面に表示し、処理を終了する。また、ＵＩ部３２７は、表示された貸付条件での貸付を許容するか否かの選択をユーザから受け付ける。

図７のＡに、貸付条件を表示する画面の一例を示す。例えば図７のＡの画面には、貸付可能額が１０，０００円であり、返済期限が１か月後であり、返済期限時に加算される利子（手数料）が１６４円であることが表示されている。ボタンＢ１が押下されると、図７のＢに示す確認画面に進み、ボタンＢ２が押下されると、ステップＳ１１１の処理手順に進む。

ステップＳ１１１で、端末１２０の送信部３２５は、ユーザが貸付条件を受け入れたことを示す通知をサーバ１１０に送信する。

ステップＳ１１２で、サーバ１１０の貸付処理部３１８は、ユーザが貸付条件を受け入れたことを示す通知を受けて、ユーザに対して貸付条件に従って金銭の貸付を実行し、当該貸付条件等を貸付管理ＤＢに記憶する。具体的には、貸付処理部３１８は、ユーザ管理ＤＢに登録されているユーザの銀行口座に、貸付可能額に相当する金銭の振り込みを行うことや、ユーザが利用している決済サービスにおけるチャージ残高に、貸付可能額に相当する金額を加算する等の処理を行う。その他、所定の銀行ＡＴＭからの引き出しを可能としてもよい。なお、端末１２０の画面に、図７のＣに示す選択画面を表示することで、貸し付けた金銭を受け取る方法をユーザに選択させるようにしてもよい。

＜第１実施形態の貸付条件決定処理＞
続いて、審査処理部３１６は、図５のステップＳ１０８の処理手順で貸付条件を決定する際の決定方法について説明する。

審査処理部３１６は、図５のステップＳ１０８の処理手順で貸付条件を決定する際、ユーザ属性情報およびユーザ行動情報に基づいて、所定のアルゴリズムを用いてユーザの信用度を算出し、算出した信用度に基づいて貸付条件を決定するようにしてもよい。

例えば、審査処理部３１６は、信用機関システム１４０から得られた信用情報に含まれる各種のデータや、ユーザ行動情報に含まれる、電子商取引における取引頻度、取引額、購入代金の支払い遅延の有無または遅延回数などを所定のアルゴリズムに代入することでユーザの信用度（信用の度合いを数値の大きさで表現したもの）を算出する。また、審査処理部３１６は、ユーザの位置情報の履歴からユーザの行動エリアを把握し、把握した行動エリアに基づいてユーザの信用度を算出するようにしてもよい。例えばパチンコ店に頻繁に出入りしているなど、ギャンブル依存が疑われるようなユーザについては信用度を低く設定することが考えらえる。続いて、審査処理部３１６は、信用度が高いほど、貸付可能額が高くなるように貸付可能額を決定するようにしてもよい。また、審査処理部３１６は、信用度が高いほど、利率が低くなるように利率を決定するようにしてもよい。また、審査処理部３１６は、信用度が高いほど、返済期限が長くなるように返済期限を決定するようにしてもよい。ユーザ行動情報を用いて貸付条件を決定することで、ユーザ属性情報のみで貸付条件を決定するよりも、ユーザの信用度をより適切に算出することが可能になる。

また、審査処理部３１６は、図５のステップＳ１０８の処理手順で貸付条件を決定する際、貸付可能額、利率および返済期限のうち少なくとも１つが異なる複数の貸付条件を決定するようにしてもよい。この場合、ステップＳ１０９の処理手順において、通知部３１７は、決定された複数の貸付条件を端末１２０に通知する。また、ステップＳ１１０の処理手順で、端末１２０のＵＩ部３２７は、複数の貸付条件を画面に表示し、ユーザの選択を受け付ける。ステップＳ１１１の処理手順で、端末１２０の送信部３２５は、ユーザが選択した貸付条件をサーバ１１０に送信する。サーバ１１０の貸付処理部３１８は、ユーザから指定された、複数の貸付条件のうちいずれか１つの貸付条件に従って金銭の貸付を行う。

図８のＡは、貸付条件として貸付可能額が異なる場合に、貸付条件の選択をユーザから受け付ける画面の一例を示す。図８のＢは、貸付条件として返済期限が異なる場合に、貸付条件の選択をユーザから受け付ける画面の一例を示す。

審査処理部３１６は、図５のステップＳ１０８の処理手順で貸付条件を決定する際、貸付可能金額の上限を含む貸付条件を決定するようにしてもよい。この場合、ステップＳ１０９の処理手順において、通知部３１７は、貸付可能金額の上限を含む貸付条件を端末１２０に通知する。また、ステップＳ１１０の処理手順で、端末１２０のＵＩ部３２７は、貸付可能金額を上限とする貸付希望額の指定をユーザから受け付ける画面を表示し、貸付希望額の選択をユーザから受け付ける。ステップＳ１１１の処理手順で、端末１２０の送信部３２５は、ユーザから受け付けた貸付希望額をサーバ１１０に送信する。サーバ１１０の貸付処理部３１８は、ユーザから受け付けた貸付希望金額が、貸付可能金額の上限以下である場合に、貸付条件に従って貸付希望金額の金銭の貸付を行う。

＜＜第１実施例＞＞
貸付希望金額の指定をユーザから受け付ける場合で、かつ、本審査の結果、貸付可能金額がユーザの年収を１／３にした額から他社借入額を引いた範囲であった場合、端末１２０の画面に、ユーザ属性情報の少なくとも一部（例えばユーザの年収と他社からの借入額）と貸付可能額の上限とを共に表示し、ユーザが画面を操作することで、０円から貸付可能金額までの間で貸付希望額を任意に指定することができるようにしてもよい。図８のＣは、貸付希望金額の指定をユーザから受け付ける画面の一例を示す。図８のＣに示すように、ユーザの年収の１／３から他社借入額を引いた範囲でスライダー操作を受け付けるようにしてもよい。第１実施例によれば、総量規制の概念をユーザが理解しながら貸付を希望する金額を決定することが可能になる。例えば、ユーザが調整オブジェクト８１０を右側に指をスワイプする操作に応答して貸付金額に対応付けられた表示領域８２０の大きさを変化させてもよい。この場合、ユーザの操作に応じて貸付金額に対応付けられた表示領域８２０の面積が大きくなるにつれて、貸付金額も大きくなるようにしてもよい。また、ユーザの操作に応じて貸付金額に対応付けられた表示領域８２０の面積が小さくなるにつれて、貸付金額も小さくなるようにしてもよい。

＜＜第２実施例＞＞
図５のステップＳ１１０において、ユーザから貸付条件での貸付を許容するとの選択を受け付けた際、ＵＩ部３２７は、更に、利率が適用された利用規約を示す画面を表示すると共に、利用規約を確認したことを受け付けるようにしてもよい。この場合、送信部３２５は、ユーザが当該利用規約を確認したことを示す情報をサーバ１１０に送信し、サーバ１１０の貸付処理部３１８は、ユーザが利用規約を確認したことを示す情報を受けた場合に、貸付処理を実行するようにしてもよい。図９に利用規約を表示する画面の一例を示す。利率は、利用規約をスクロールすることで参照可能な位置に記述されるようにしてもよい。

第２実施例によれば、利用規約をスクロールしないと利率を確認することができないことから、ユーザに利用規約文面を確認させることが可能になる。また、利率と利用規約を同一の画面で表示できることから、利率を個別の画面で表示する場合と比較して画面数を削減することが可能になる。

＜＜第３実施例＞＞
サーバ１１０の通知部３１７は、ユーザ行動ＤＢの電子商取引の利用履歴、決済サービスの利用履歴および位置情報の履歴のうち少なくとも１つに基づいて、サーバ１１０が提供する貸付サービスを利用する可能性が高いユーザを抽出し、抽出したユーザの端末１２０に対して、貸付サービスの利用を勧める旨の通知を送信するようにしてもよい。当該通知を受信した端末１２０のＵＩ部３２７は、たとえば、貸付サービスの利用をお勧めする旨の通知を画面に表示させるようにしてもよい。第３実施例によれば、貸付サービスの利用を促進させることが可能になる。

＜第２実施形態＞
第２実施形態は、貸付管理ＤＢに記憶された貸付額、利率および返済期限を含む貸付条件を確認し、返済期限以降に、ユーザのアカウントに対応づけられる複数の残高のうち少なくともいずれか一つの残高から、貸付額および利率に基づき計算される返済額を減算することで返済を行う実施形態である。なお、第２実施形態では、ユーザのアカウントに対応づけられる複数の残高には、銀行から振り込んだ金銭や電子商取引において相手方から得られる金銭の残高、および、電子商取引において新たな商品の購入に充当することが可能なポイントの残高が含まれる前提である。

第２実施形態によれば、ユーザに貸し付けた金銭を適切に回収することが可能になる。また、サーバ１１０が自動的に回収を行うので、回収の処理をより正確に行うことが可能になる。また、より正確に回収の処理が行われることで、サービスを提供する企業が貸し倒れによる損失を受ける可能性が減り、新たなサービスの創造等を通じてなめらかな金融サービスを提供することが可能になる。

＜第２実施形態の機能構成＞
（１）サーバの機能構成
サーバ１１０の返済処理部３１９は、ユーザに貸し付けた貸付額について、返済期限以降に、ユーザのアカウントに対応づけられる複数の残高のうち少なくともいずれか一つの残高から、貸付額および利率に基づいて算出される返済額を減算することで返済処理を行う機能を有する。

また、返済処理部３１９は、ユーザのアカウントに対応づけられる複数の残高のうち、優先順位の高い残高から返済額を減算するようにしてもよい。また、返済処理部３１９は、ユーザのアカウントに対応づけられる複数の残高に含まれる、新たな商品の購入に利用可能なポイントの残高から、返済額を減算することで返済を行うようにしてもよい。また、返済処理部３１９は、ユーザのアカウントに対応づけられるポイントのうち、有効期限が短いポイントから優先して減算することで返済を行うようにしてもよい。

サーバ１１０の機能構成のうち、特に言及しない点は第１実施形態と同一でよい。

（２）端末の機能構成
端末１２０の機能構成は、第１実施形態と同一であるため説明は省略する。

＜第２実施形態の動作処理＞
まず、ユーザのアカウントに対応づけられる複数の残高の具体例について図１０を用いて説明する。第２実施形態では、サーバ１１０が提供する金融サービスおよび電子商取引サービスで共通のアカウントを利用してユーザを管理しているものとする。

図１０の左側は、ユーザのアカウントにユーザの銀行口座が登録される（ユーザのアカウントがユーザの銀行口座と関連づけられる）前の状態を示している。ユーザのアカウントにユーザの銀行口座が登録される前の状態を、第２実施形態では「銀行接続前」と称する。図１０の右側は、ユーザのアカウントにユーザの銀行口座が登録された後の状態を示している。ユーザのアカウントにユーザの銀行口座が登録された後の状態を、第２実施形態では「銀行接続後」と称する。なお、ユーザのアカウントにユーザの銀行口座を登録する際、犯罪による収益の移転防止に関する法律に基づく本人確認（例えば身分証明書の提出など）が行われ、本人確認が完了すると、ユーザが指定した銀行口座がユーザのアカウントに登録される。また、ユーザのアカウントにユーザの銀行口座が登録されることで、銀行口座とアカウントとの間での金銭の移動が容易になる。

銀行接続前の状態では、ユーザのアカウントには、商品を売却することで得られる売上金であって新たな商品の購入に充てることが不可能な「売上金」の残高（第１残高）と、売上金を変換することで得られるポイントであって新たな商品の購入に利用可能な「ポイント１」の残高（第２残高）と、利用促進施策などにより無償で付与されるポイントであって新たな商品の購入に利用可能な「ポイント２」の残高（第３残高）との３つの残高が存在する。

この状態でユーザのアカウントにユーザの銀行口座が登録されるとユーザのアカウントは銀行接続後の状態となり、「売上高」は、「残高」との呼び名に変更される。この「残高」を、第４残高と称してもよい。また、銀行接続後の「ポイント２」の残高を第５残高と称してもよい。銀行接続後、「残高」は、電子商取引サービスにおいて商品の購入代金に充てることが可能になる。ただし、「残高」を直接新たな商品の購入に充てることが可能になることにより、「残高」の全部または一部を「ポイント１」に交換することはできないようにする。つまり、銀行接続後は、ポイント１を商品購入代金に充てることでポイント１の残高が減ることはあるが、ポイント１の残高が増えることはない。ポイント１の残高がゼロになると、図１０の右側に示すように、ユーザのアカウントには、「残高」と「ポイント２」のみが存在する状態になる。

図１１は、第２実施形態に係るサーバ１１０が行う処理手順の一例を示すフローチャートである。図１１のフローチャートは、銀行接続前のアカウントおよび銀行接続後のアカウントの両方に適用される。

まず、サーバ１１０の返済処理部３１９は、ユーザに貸し付けた金銭（債務）が返済期限を過ぎると、最初に、「ポイント１」の残高から返済額を返済（除算）する（Ｓ２００）。全ての返済額が返済できた場合は処理を終了する（Ｓ２０１－ＹＥＳ）。全ての返済額が返済できない場合（Ｓ２０１－ＮＯ）、「ポイント２」の残高から残りの返済額を返済（除算）する（Ｓ２０２）。残りの返済額が返済できた場合は処理を終了する（Ｓ２０３－ＹＥＳ）。

残りの返済額が返済できない場合（Ｓ２０３－ＮＯ）、「売上金」の残高または「残高」から残りの返済額を返済（除算）する（Ｓ２０４）。残りの返済額が返済できた場合は処理を終了する（Ｓ２０５－ＹＥＳ）。残りの返済額が返済できない場合（Ｓ２０５－ＮＯ）、ユーザの銀行口座から残りの返済額を引落しすることで返済を完了させる（Ｓ２０６）。

すなわち、サーバ１１０は、最初に返済額を「ポイント１（第２残高）」から減算し、「ポイント１（第２残高）」が無くなった場合に「ポイント２（第３残高）」から減算し、「ポイント２（第３残高）」が無くなった場合に「売上高／残高（第１残高）」から減算することで返済を行う。また、銀行接続後で、「ポイント１」が存在しない場合、図１１のステップＳ２００およびステップＳ２０１は省略される。つまり、サーバ１１０は、最初に返済額を「ポイント２（第５残高）」から減算し、「ポイント２」が無くなった場合に「残高（第４残高）」から減算することで返済を行う。更に、サーバ１１０は、いずれの残高からも返済額を減算することが出来ない場合、不足分の返済額の少なくとも一部をユーザの銀行口座から直接引落すことで返済を行う。

なお、サーバ１１０は、銀行接続前の状態において、返済額を「売上高（第１残高）」又は「ポイント１（第２残高）」のいずれかの残高から減算し、当該残高が無くなった場合にもう一方の残高から減算することで返済を行うようにしてもよい。また、サーバ１１０は、銀行接続後の状態において、返済額を「残高（第４残高）」又は「ポイント２（第５残高）」のいずれかの残高から減算し、当該残高が無くなった場合にもう一方の残高から減算することで返済を行うようにしてもよい。銀行接続後の状態における「残高」及び「ポイント２」を、それぞれ第３残高及び第４残高と称してもよい。

ユーザが返済期限までに自主的に返済額を返済した場合には、図１０に示すフローチャートの処理は実行されない。この場合、返済処理部３１９は、返済期限までに全額を返済したユーザには、特典を付与するようにしてもよい。特典は、サーバ１１０が提供する金融サービスで利用可能な特典であってもよい。限定でなく例として、次回ユーザが金銭を借用する際の利子を無料または軽減にする等の特典であってもよい。

不足分の返済額を銀行口座から引き落とす場合において、ユーザのアカウントに複数の銀行口座が登録されている場合、サーバ１１０の返済処理部３１９は、当該複数の銀行口座のうち、電子商取引サービス、決済サービスまたは金融サービスにおいて取引が行われている回数が多い銀行口座から順に引落しを行うようにしてもよい。もしくは、サーバ１１０の返済処理部３１９は、当該複数の銀行口座のうち、電子商取引サービス、決済サービスまたは金融サービスにおいて最も直近で現金のやり取りが行われた銀行口座から順に引落しを行うようにしてもよい。なお、預金額が多い銀行口座から順に引落しを行うようにしてもよい。

第２実施形態において、ユーザの銀行口座からも引落しが出来なかった場合、サーバ１１０の返済処理部３１９は、ユーザに対して督促を行うために必要な処理（例えばブラックリストへの登録など）を行う。

＜第３実施形態＞
第３実施形態は、複数のユーザを含むグループの単位で金銭の貸付を行い、複数のユーザのうち少なくともいずれかのユーザから、貸し付けた金銭の返済を受ける実施形態である。グループの単位で金銭の貸付を行うパターンとして、２つのパターンが挙げられる。

第１貸付パターンは、複数のユーザのうち一人のユーザを、要求された貸付額を貸し付けるユーザとして審査し、他のユーザを、当該貸付額の返済を保証する保証人または連帯保証人として審査を行うパターンである。第１のパターンでは、基本的には貸付を受けたユーザが返済するが、貸付を受けたユーザが返済しない場合は他のユーザが貸付額を返済することになる。

第２貸付パターンは、複数のユーザの各々から貸付を希望する金額を受け付け、各々のユーザについて個別に審査を行い、審査を通過した場合に、各ユーザに対して各ユーザが希望した金額を貸し付けるパターンである。なお、第２のパターンでは、各々のユーザに貸付を行うが、返済時はいずれか一人のユーザが全員分の貸付額をまとめて返済してもよいし、各ユーザが自身の貸付額を返済するようにしてもよい。

第３実施形態によれば、金銭の貸付を希望するグループの単位で金銭の貸付を行うことが可能になる。また、第３実施形態によれば、金銭の貸付を希望するグループに対して、各々のユーザ属性情報およびユーザ行動情報の少なくとも１つを考慮してサーバが貸付条件を決定するので、より正確に貸付条件を決定することができ、かつ、貸付け条件を決定する際の処理をスムーズに行うことが可能になる。また、貸付け条件を決定する際の処理をスムーズに行うことができるため、なめらかな金融サービスを提供することが可能になる。

＜第３実施形態の機能構成＞
再度、図３を用いてサーバ１１０および端末１２０の機能構成を説明する。特に言及しない点は第１実施形態と同一でもよい。

（１）サーバの機能構成
制御部３１３は、受付部３１５と、審査処理部３１６と、通知部３１７と、貸付処理部３１８と、返済処理部３１９とを含む。

記憶部３１４は、プログラムと、各ユーザのアカウントを管理するユーザ管理ＤＢと、ユーザ行動情報を含むユーザ行動ＤＢと、ユーザに貸し付けた際の貸付条件を含む貸付管理ＤＢとを記憶する。ユーザ管理ＤＢおよびユーザ行動ＤＢは、第１実施形態と同一であるため説明は省略する。

図１２は、第３実施形態に係る貸付管理ＤＢの一例を示す図である。図１２のＡは、第１貸付パターンに対応する貸付管理ＤＢを示す。「ユーザＩＤ（貸付者）」には、金銭の貸付を受けたユーザのユーザＩＤが含まれる。「ユーザＩＤ（保障人）」には、保証人または連帯保証人であるユーザのユーザＩＤが含まれる。「保証人種別」には、ユーザＩＤ（保障人）が保証人なのか連帯保証人なのかを示すフラグが含まれる。「貸付額」には、ユーザＩＤ（貸付者）のユーザに貸し付けた金額が含まれる。「貸付日」、「利率（年）」および「返済期限」については、図４Ｃと同一であるため説明は省略する。

図１２のＢは、第２貸付パターンに対応する貸付管理ＤＢを示す。「グループＩＤ」には、貸付を受ける単位であるグループを一意に識別するＩＤが含まれる。「ユーザＩＤ」、「貸付額」、「貸付日」、「利率（年）」および「返済期限」については、図４Ｃと同一であるため説明は省略する。なお、図１２のＢの例では、貸付日と返済期限は同一であるが、必ずしもこれに限定されない。具体的には後述するが、第２貸付パターンの場合、与信審査や貸付はユーザごとに独立して行われることから、貸付日と返済期限をグループで統一してもよいし、ユーザごとに異なるようにしてもよい。

受付部３１５は、複数のユーザを含むグループから、金銭の貸付に関する要求を受け付ける機能を有する。第１貸付パターンの場合、金銭の貸付に関する要求には、グループとして貸付を希望する貸付額が含まれている。第２貸付パターンの場合、金銭の貸付に関する要求には、グループ内の複数のユーザの各々が貸し付けを希望する貸付額が含まれている。

審査処理部３１６は、グループ内の複数のユーザのうち一人のユーザに対してまたは当該複数のユーザの各々に対して、金銭を貸し付けることについての審査を行う機能を有する。また、審査処理部３１６は、第１貸付パターンの場合、グループ内の一人のユーザを、グループが希望する貸付額を貸し付けるユーザとして審査を行い、当該一人のユーザ以外の他のユーザを、貸付額の返済を保証する保証人または連帯保証人として審査を行う。また、審査処理部３１６は、第２貸付パターンの場合、グループ内の各ユーザに対して、各々のユーザが希望する貸付額を貸し付けることについて審査を行う。

通知部３１７は、審査処理部３１６で行われた審査の結果および貸付条件を各ユーザに通知する機能を有する。

貸付処理部３１８は、審査が完了した場合に、グループ内の一人のユーザまたは複数のユーザの各々に対して金銭の貸付を行う機能を有する。また、貸付処理部３１８は、第１貸付パターンの場合、金銭の貸付を行う一人のユーザおよび保証人または連帯保証人である他のユーザに対する審査が完了した場合に、当該一人のユーザに対して貸付額の貸付を行う。また、貸付処理部３１８は、第２貸付パターンの場合、複数のユーザの各々に対する審査が完了した場合に、当該複数のユーザの各々に対して、各々のユーザが希望する貸付額の貸付を行う。

返済処理部３１９は、グループ内の複数のユーザのうち少なくともいずれかのユーザから、貸し付けた金銭の返済を受け付ける機能を有する。

（２）端末の機能構成
送信部３２５は、ＵＩ部３２７を介してユーザからグループ単位で金銭の貸付を受けたい旨の指示を受けた場合に、金銭の貸付を管理するサーバ１１０に対して、金銭の借入に関する要求を送信する機能を有する。また、送信部３２５は、各ユーザから貸付条件を受け入れるとの指示をＵＩ部３２７を介して受けた場合、各ユーザに対する貸付条件による金銭の貸付をサーバ１１０に実行させるために、各ユーザが貸付条件を受け入れたことを示す通知をサーバ１１０に通知する機能を有する。

受信部３２６は、サーバ１１０から、各ユーザのユーザ属性情報および各ユーザのユーザ行動情報に基づいて審査を行うことで決定された、各ユーザに金銭を貸し付ける際の貸付条件の通知を受け付ける機能を有する。

ＵＩ部３２７は、サーバ１１０が提供する金融サービスに関する各種の画面を端末１２０のディスプレイに表示する機能を有する。また、当該金融サービスに関する各種の入力をユーザから受け付ける機能を有する。また、ＵＩ部は、ユーザから金銭の貸付を受けたい旨の指示や貸付条件を受け入れるか否かの指示を受け付ける機能を有する。

＜第３実施形態の動作処理＞
図１３は、第３実施形態に係る通信システムが行う処理手順（第１貸付パターン）の一例を示すフローチャートである。図１３では、ユーザＡ、ユーザＢおよびユーザＣを含むグループにおいて、ユーザＡが金銭の貸付を受けて、ユーザＢおよびユーザＣが連帯保証人または保証人になる前提とする。

ステップＳ３００で、端末１２０ＡのＵＩ部３２７は、グループでの貸付を受け付ける画面において、グループ単位での貸付を希望することと、グループを構成するユーザの選択と、選択されたグループ内の各ユーザのうち、金銭を貸し付けるユーザの選択と、連帯保証人または保証人になるユーザの選択と、保証人種別の選択（連帯保証人なのか保証人なのかの選択）とを受け付ける。ここでは、金銭の貸付を希望するユーザはユーザＡであり、連帯保証人になるユーザとしてユーザＢおよびユーザＣが選択されたと仮定する。

ここで、グループを構成するユーザの選択を受け付ける画面には、ユーザＡの現在位置（端末１２０Ａの現在位置）から所定の範囲内に存在する端末１２０を利用するユーザが一覧表示され、一覧表示されたユーザの中から選択を受け付けるようにしてもよい。若しくは、端末１２０Ａが送信するＢｌｕｅｔｏｏｔｈ（登録商標）の信号を受信した端末１２０を利用するユーザが一覧表示され、一覧表示されたユーザの中から選択を受け付けるようにしてもよい。若しくは、ユーザ間の繋がり関係を示すソーシャルグラフで表示されるユーザの中から選択を受け付けるようにしてもよい。

ステップＳ３０１で、続いて、端末１２０ＡのＵＩ部３２７は、ユーザＡから、貸付希望額の入力を受け付ける。

ステップＳ３０２およびステップＳ３０３で、選択されたユーザＢの端末１２０ＢおよびユーザＣの端末１２０Ｃに、ユーザＡが上記貸付希望額の貸付を受けることについての連帯保証人になることに同意するかの確認が行われるようにしてもよい。例えば、端末１２０Ａから端末１２０Ｂおよび端末１２０Ｃに、サーバ１１０を介して同意確認メッセージを送信することで、ユーザＢおよびユーザＣの同意を得ることとしてもよい。ここでは、同意が取れたものとして説明を続ける。

ステップＳ３０４で、端末１２０の送信部３２５は、グループでの貸付を要求するメッセージをサーバ１１０に送信する。当該メッセージには、貸付希望額と、ユーザＡに貸付を行うことと、ユーザＢおよびユーザＣがユーザＡの連帯保証人になることを示す情報が含まれる。

ステップＳ３０５で、グループでの貸付を要求するメッセージを受信すると、サーバ１１０は、端末１２０Ａに、ユーザ属性情報の入力を要求するメッセージを送信する。

ステップＳ３０６で、端末１２０ＡのＵＩ部３２７は、ユーザＡからユーザＡのユーザ属性情報の入力を受け付ける。

ステップＳ３０７で、端末１２０Ａの送信部３２５は、入力されたユーザＡのユーザ属性情報を送信する。

ステップＳ３０８で、サーバ１１０の審査処理部３１６は、受け付けたユーザＡのユーザ属性情報および信用機関システム１４０から取得したユーザＡの信用情報を含む全てのユーザ属性情報と、ユーザ行動ＤＢから取得したユーザＡの行動情報とに基づき、ユーザＡが希望する貸付希望額をユーザＡに貸し付けることが可能な否かの審査を行う。

同様に、ステップＳ３０９～ステップＳ３１２の処理手順において、ユーザＢがユーザＡの連帯保証人（または保証人）になることが可能か否かの審査が行われ、ステップＳ３１３～ステップＳ３１６において、ユーザＣがユーザＡの連帯保証人（または保証人）になることが可能か否かの審査が行われる。保証人に関する審査の内容は、連帯保証人に関する審査の内容よりも簡易であってもよい。

ステップＳ３１７で、サーバ１１０の通知部３１７は、ユーザＡが希望する貸付希望額をユーザＡに貸し付けることと、ユーザＢおよびユーザＣが連帯保証人になることについての審査結果と、貸付条件（審査を通過した場合のみ）とを端末１２０Ａに送信する。

ステップＳ３１８で、端末１２０ＡのＵＩ部３２７は、審査を通過した場合、貸付条件を画面に表示する。審査を通過しなかった場合は、その旨を画面に表示し、処理を終了する。ＵＩ部３２７は、表示された貸付条件での貸付を許容するか否かの選択をユーザＡから受け付ける。

ステップＳ３１９で、端末１２０Ａの送信部３２５は、ユーザＡが貸付条件を受け入れたことを示す通知をサーバ１１０に送信する。

ステップＳ３２０で、サーバ１１０の貸付処理部３１８は、ユーザＡが貸付条件を受け入れたことを示す通知を受けて、ユーザＡに対して貸付条件に従って金銭の貸付を実行し、貸付条件やユーザＢおよびユーザＣが連帯保証人であること等の情報を貸付管理ＤＢに記憶する。

以上説明した処理手順において、更に、連帯保証人または保証人であるユーザの端末１２０にも審査結果を通知し、当該ユーザから、連帯保証人または保証人になることおよび貸付条件についての同意を得るようにしてもよい。サーバ１１０の貸付処理部３１８は、審査に通過した貸付を行うユーザが貸付条件について同意をし、かつ、審査に通過した連帯保証人または保証人が、連帯保証人または保証人になることおよび貸付条件についての同意をした場合に、金銭の貸付を実行するようにしてもよい。

以上説明した処理手順において、ステップＳ３０５～ステップＳ３０８の処理手順、ステップＳ３０９～ステップＳ３１２の処理手順、および、ステップＳ３１３～ステップＳ３１６の処理手順の実行順序については図１３に示す順序に限定されない。これらの処理手順は処理に矛盾が無い限り、順序を入れ替えてもよいし、同時に実行するようにしてもよい。

サーバ１１０の審査処理部３１６は、金銭を貸し付けるユーザが審査を通過した場合において、更に、連帯保証人または保証人として選択されたユーザのうち少なくとも一のユーザが審査を通過した場合、ユーザに金銭の貸付を行うようにしてもよい。例えば、図１３の例では、ユーザＡが審査に通過した場合において、ユーザＢまたはユーザＣのうち少なくとも一方が審査に通過した場合はユーザＡに金銭の貸付を行うようにしてもよい。若しくは、サーバ１１０の審査処理部３１６は、金銭を貸し付けるユーザおよび連帯保証人または保証人として選択されたユーザの全てのユーザが審査を通過した場合にのみ、金銭の貸付を行うようにしてもよい。

第１貸付パターンでは、返済期限を過ぎると、サーバ１１０は、第２実施形態で説明した処理手順に従い、貸付を行ったユーザのアカウントの口座から減算処理を行うことで返済を行う。もし、貸付を行ったユーザのアカウントの口座から減算処理を行うことができない場合、連帯保証人または保証人であるユーザのアカウントの口座から減算処理を行うことで返済を行う。しかしながら、返済期限前であれば、グループ内のいずれか一人のユーザが返済を行ってもよい。

図１４は、第３実施形態に係る通信システムが行う処理手順（第２貸付パターン）の一例を示すフローチャートである。図１４の例では、ユーザＡ、ユーザＢおよびユーザＣを含むグループにおいて、各々のユーザが金銭の貸付を受けるものとする。第２貸付パターンについても、第１貸付パターンと同様、グループを構成するユーザの選択を受け付ける画面を用いて、グループに含まれるユーザの選択を受け付けることとしてもよい。当該画面には、ユーザの現在位置（端末１２０の現在位置）から所定の範囲内に存在する端末１２０を利用するユーザが一覧表示され、一覧表示されたユーザの中から選択を受け付けるようにしてもよい。若しくは、端末１２０が送信するＢｌｕｅｔｏｏｔｈ（登録商標）の信号を受信した端末１２０を利用するユーザが一覧表示され、一覧表示されたユーザの中から選択を受け付けるようにしてもよい。若しくは、ユーザ間の繋がり関係を示すソーシャルグラフに基づいて表示されるユーザの中から選択を受け付けるようにしてもよい。

図１４において、ステップＳ４００～ステップＳ４０３の処理手順は、ユーザＡ、ユーザＢおよびユーザＣを含むグループで行われるチャットであるグループトークのトークルーム中で行われるものとする。

ステップＳ４００で、端末１２０ＡのＵＩ部３２７は、ユーザＡからグループでの貸付を要求するメッセージの入力を受け付ける。送信部３２５は、受け付けたメッセージを、グループトークのトークルームに送信する。サーバ１１０の受付部３１５は、トークルームに送信された、グループでの貸付を要求するメッセージを認識する。このとき、サーバ１１０は、グループトークのトークルーム宛に、各ユーザに対して貸付希望額を入力するように指示するメッセージを送信するようにしてもよい。

ステップＳ４０１～ステップＳ４０１で、ユーザＡ、ユーザＢおよびユーザＣは、端末１２０Ａ、端末１２０Ｂおよび端末１２０Ｃの画面に表示されるトークルームにて自身の貸付希望額を入力して送信する。サーバ１１０の受付部３１５は、送信されたユーザＡ、ユーザＢおよびユーザＣの各々の貸付希望額を受け付ける。

以下で説明するステップＳ４１０～ステップＳ４１７の処理手順は、ユーザの個人的な情報の送信を含むことから、グループのトークルームではなくユーザＡとサーバ１１０との間で個別に行われるようにしてもよい。

ステップＳ４１０で、端末１２０ＡからユーザＡの貸付希望額を受信すると、サーバ１１０は、端末１２０Ａに、ユーザ属性情報の入力を要求するメッセージを送信する。

ステップＳ４１１で、端末１２０ＡのＵＩ部３２７は、ユーザＡからユーザＡのユーザ属性情報の入力を受け付ける。

ステップＳ４１２で、端末１２０Ａの送信部３２５は、入力されたユーザＡのユーザ属性情報を送信する。

ステップＳ４１３で、サーバ１１０の審査処理部３１６は、受け付けたユーザＡのユーザ属性情報および信用機関システム１４０から取得したユーザＡの信用情報を含む全てのユーザ属性情報と、ユーザ行動ＤＢから取得したユーザＡの行動情報とに基づき、ユーザＡが希望する貸付希望額をユーザＡに貸し付けることが可能な否かの審査を行う。

ステップＳ４１４で、サーバ１１０の通知部３１７は、ユーザＡが希望する貸付希望額をユーザＡに貸し付けることについての審査結果と、貸付条件（審査を通過した場合のみ）とを端末１２０Ａに送信する。

ステップＳ４１５で、端末１２０ＡのＵＩ部３２７は、審査を通過した場合、貸付条件を画面に表示する。審査を通過しなかった場合は、その旨を画面に表示し、処理を終了する。ＵＩ部３２７は、表示された貸付条件での貸付を許容するか否かの選択をユーザＡから受け付ける。

ステップＳ４１６で、端末１２０Ａの送信部３２５は、ユーザＡが貸付条件を受け入れたことを示す通知をサーバ１１０に送信する。

ステップＳ４１７で、サーバ１１０の貸付処理部３１８は、ユーザＡが貸付条件を受け入れたことを示す通知を受けて、ユーザＡに対して貸付条件に従って金銭の貸付を実行する。また、ユーザＡに金銭を貸し付けた際の貸付条件等の情報と、ユーザＡ、ユーザＢおよびユーザＣを含むグループのグループＩＤとを対応づけて貸付管理ＤＢに記憶する。

ステップＳ４２０では、端末１２０Ｂとサーバ１１０との間で、ステップＳ４１０～ステップＳ４１７と同様の処理手順が実行される。また、ステップＳ４３０では、端末１２０Ｃとサーバ１１０との間で、ステップＳ４１０～ステップＳ４１７と同様の処理手順が実行される。

第２貸付パターンでは、返済期限を過ぎると、サーバ１１０は、第２実施形態で説明した処理手順に従い、各ユーザのアカウントの口座から減算処理を行うことで返済を行う。しかしながら、返済期限前であれば、グループ内のいずれか一人のユーザがグループ内の各々のユーザが借りた額をまとめて返済可能としてもよい。

第２貸付パターンでは、審査処理部３１６は、複数のユーザの中で審査に落ちたユーザが存在する場合、複数のユーザのうち審査に落ちたユーザが貸し付けを希望する貸付額を、審査に落ちたユーザ以外のユーザに貸し付けることについて再度審査を行うようにしてもよい。審査に落ちたユーザ以外のユーザは、例えば、第１実施形態で説明した信用度が最も高いユーザを選択し、そのユーザに、当該ユーザの貸付希望額と、審査に落ちたユーザ以外のユーザの貸付希望額とを合算した額を貸し付けることについて審査を行うようにしてもよい。

＜第４実施形態＞
第４実施形態は、本審査によりユーザに貸付可能と判断した額よりも、ユーザが貸付を希望する額が少ない場合、当該ユーザに対して、ユーザに貸付可能と判断した額からユーザが貸付を希望する額を減算することで、ユーザに対して更に貸付け可能な金額の上限を算出し、算出した金額の上限の範囲で購入可能な商品をユーザに提示する（お勧めする）。また、ユーザが当該商品を購入希望する場合、ユーザが貸付を希望する額に当該商品の価格を合算した金額を貸付ける処理を行う。

第４実施形態によれば、ユーザに対して金銭の借入を促すことが可能になる。また、第４実施形態によれば、金銭の貸付を希望するユーザに対して、ユーザ属性情報等を考慮して貸付額の上限を決定し、更に、商品の購入をお勧めすることができる。また、貸付額の上限の決定および商品の提案までの一連処理をサーバが行うので、当該一連の処理をスムーズに行うことが可能になる。また、ユーザは、金銭の貸付けを受ける際に、返済能力の範囲内で商品の購入も一緒に行うことができるので、単純に金銭の貸付けのみを受けることと比較して、ユーザの消費行動を促進し、よりなめらかな社会の創造に寄与することが可能になる。

＜第４実施形態の機能構成＞
図１５を用いてサーバ１１０および端末１２０の機能構成を説明する。図１５において特に言及しない点は第１実施形態と同一でよい。

制御部３１３は、受付部３１５と、審査処理部３１６と、通知部３１７と、貸付処理部３１８と、返済処理部３１９と、レコメンド処理部３３０と、購入処理部３３１とを含む。

第４実施形態に係るユーザ管理ＤＢには、各ユーザがどのユーザと所定の関係を有するのかを示す情報が含まれる。

ここで、所定の関係とは、サーバ１１０が、２以上のユーザ間の所定の関係を記憶していることを意味する。限定でなく例として、所定の関係は、相互に関係構築を承認した関係、少なくとも一方が関係構築を申し入れた関係、ユーザ情報に基づき構築された関係、ユーザ行動に基づき構築された関係、所定の条件が満たされたことにより関係構築がなされた状態を含んでもよい。なお、ユーザ情報に基づき構築された関係とは、１以上の同一または類似するユーザ情報を有するユーザ同士を関係づけた関係を含んでもよいし、ユーザ行動に基づき構築された関係とは、１以上の同一または類似するユーザ行動を有するユーザ同士を関係づけた関係を含んでもよい。

また、ユーザと所定の関係にあるユーザは、限定ではなく例として、ユーザと所定の関係にある全てのユーザでもよいし、予め定められた所定の人数のユーザであってもよいし、親密度が所定の度合い以上のユーザであってもよい。

ここで、親密度とは、所定の期間内（１か月間や２か月間などの予め固定された期間でもよいし、所定の関係を構築してから現在までの期間でもよい）においてユーザとの間で送受信したメッセージの送受信量が多い順に親密度が高くなるように決定される度合いであってもよい。また、所定の期間内においてユーザ間で行われた取引（商品の売買や、資産の送受信・両替等などを含む）の回数が多い順に親密度が高くなるように決定される度合いでもよい。

また、親密度とは、所定の関係が構築されてから現在までの期間の長さが長いほど親密度が高くなるように決定される度合いであってもよい。所定の関係を構築してから現在までの期間の長さは、絶対値であってもよいし、ユーザと所定の関係にある１以上のユーザの中での相対値であってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、他のユーザがユーザの位置から所定の範囲内にいる時間の長さが長いほど、親密度が高くなるように決定される度合いであってもよい。また、親密度とは、ユーザと所定の関係にある複数のユーザについて、所定の関係が構築されてから現在までの期間と、各ユーザの位置情報とに基づいて推定される関係性（例えば家族関係にあると推定される等が高いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、ユーザと共通のユーザの数（共通の友達の人数）が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザとコミュニケーションをとっているユーザと所定の関係を構築しているユーザのうち、ユーザ自身と所定の関係にあるユーザの数が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザ自身の属性と、ユーザと所定の関係にある複数のユーザの各々の属性との間における類似度が高いほど親密度が高くなるように決定される度合いであってもよい。ユーザの属性とは、限定ではなく例として、興味または関心であってもよい。

受付部３１５は、ユーザから、ユーザが貸し付けを希望する貸付額（第１貸付額）を含む金銭の貸付に関する要求を受け付ける機能を有する。

審査処理部３１６は、ユーザが貸し付けを希望する貸付額と、ユーザ属性情報（年収、他社借入金等）とに基づいて、ユーザに対して更に貸し付け可能な金額の上限を算出する機能を有する。審査処理部３１６は、算出部と称されてもよい。なお、審査処理部３１６は、第１実施形態と同様、ユーザ属性情報およびユーザ行動情報の少なくとも１つ基づいて審査を行うこととしてもよい。

貸付処理部３１８は、ユーザから、レコメンド処理部３３０がユーザに提示した商品を購入希望するとの指示を受けた場合に、ユーザに対して、ユーザが貸し付けを希望する貸付額と、当該商品の価格との合計額を下限とする貸付額（第２貸付額）を貸し付ける処理を行う。

レコメンド処理部３３０は、審査処理部３１６で算出された、ユーザに対して更に貸し付け可能な金額の上限の範囲で購入可能な商品をユーザに提示する（ユーザが利用する端末１２０に送信する）機能を有する。レコメンド処理部３３０には送信部が含まれていてもよい。

購入処理部３３１は、レコメンド処理部３３０がユーザに提示した商品をユーザが購入することについての各種の処理を行う機能を有する。

＜第４実施形態の動作処理＞
図１６は、ユーザに更に貸付け可能な金額を説明するための図である。図１６の例は、審査の結果、ユーザに貸付可能と判断された額が、総量規制（年収の１／３以上は借入をすることができないとする規制）の上限である場合の例を示す。例えば、ユーザの年収の１／３がＸ円であり、ユーザの他社借入額がＹ円であり、ユーザが希望する貸付希望額がＺ円である場合、このユーザに対しては、更に、Ｘ－（Ｙ＋Ｚ）円を貸し付けることが可能である。この場合、サーバ１１０のレコメンド処理部３３０は、Ｘ－（Ｙ＋Ｚ）円以下で購入可能な商品の商品情報をユーザに提示することで、ユーザに対して当該商品の購入を促す。

レコメンド処理部３３０は、ユーザに提示する商品の価格が、ユーザの貸付希望額未満になるように、ユーザに提示する商品を決定するようにしてもよい。

また、レコメンド処理部３３０は、ユーザに提示する商品の価格が、ユーザが電子商取引において過去に落札した商品の落札金額の平均金額、最低金額、最高金額、または、過去に落札した商品の落札金額を金額順に並べた際の中央の金額よりも低い価格になるように、商品を決定するようにしてもよい。

また、レコメンド処理部３３０は、ユーザがソーシャルネットワークサービスにおいて所定のリアクション（例えば、「いいね」を押下したこと）を行った商品の中から、ユーザに提示する商品を決定するようにしてもよい。

また、レコメンド処理部３３０は、ユーザが電子商取引のＷｅｂサイトにおいて閲覧した商品や検索した商品の中から、ユーザに提示する商品を決定するようにしてもよい。このとき、ユーザが商品を閲覧した回数が所定の回数（例えば３回以上など）以上である商品の中からユーザに提示する商品を決定するようにしてもよい。若しくは、ユーザが過去に購入した商品の価格の平均値よりも所定の割合（例えば１０％など）だけ価格が高い商品であって、ユーザが所定の回数以上閲覧した商品の中から、ユーザに提示する商品を決定するようにしてもよい。

レコメンド処理部３３０がユーザに提示する商品には、サーバ１１０を管理する企業またはサードパーティーが提供するサービス、商品またはクーポンが含まれていてもよい。クーポンの一例として、サードパーティーが提供する商品やサービスの割引が受けられるものであってもよい。例えば、通常５万円のサービスがクーポンを使うことで３万円になるようなサービスがあった場合に、ユーザに提示する商品として当該クーポンを提示し、かつ、３万円を追加で借り入れることを促すメッセージを端末１２０の画面に表示させるようにしてもよい。レコメンド処理部３３０がユーザに提示するクーポンは、端末１２０の現在位置から所定の範囲内で利用可能なクーポンであってもよい。

また、貸付処理部３１８は、ユーザと所定の関係を構築しているユーザの中に、ユーザが貸し付けを希望する貸付額（第１貸付額）を超える貸付を受けているユーザが存在する場合、該ユーザに貸し付けている貸付額をユーザに提示する機能を有していてもよい。これにより、ユーザの消費行動を促進し、よりなめらかな社会の創造に寄与することが可能になる。

１ 通信システム
１０ サーバ
１００ 通信システム
１１０ サーバ
１１０Ａ サーバ
１１０Ｂ サーバ
１２０ 端末
１２０Ａ 端末
１２０Ｂ 端末
１２０Ｃ 端末
１２０Ｘ 端末
１３０ ネットワーク
１４０ 信用機関システム
１５０ 銀行システム
２００ 情報処理装置
２０１ プロセッサ
２０２ メモリ
２０３ ストレージ
２０４ 入出力インタフェース（入出力Ｉ／Ｆ）
２０５ 通信インタフェース（通信Ｉ／Ｆ）
３１３ 制御部
３１４ 記憶部
３１５ 受付部
３１６ 審査処理部
３１７ 通知部
３１８ 貸付処理部
３１９ 返済処理部
３２３ 制御部
３２４ 記憶部
３２５ 送信部
３２６ 受信部
３２７ ＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ）部
３２８ 位置情報測定部
３３０ レコメンド処理部
３３１ 購入処理部

Claims (8)

1. 情報処理装置が行う情報処理方法であって、
   ユーザから、前記ユーザが貸し付けを希望する第１貸付額を含む金銭の貸付に関する要求を受け付けるステップと、
   前記第１貸付額と前記ユーザのユーザ属性情報とに基づいて、前記ユーザに対して更に貸し付け可能な金額の上限を算出するステップと、
   算出された前記金額の上限の範囲で購入可能な商品の商品情報を前記ユーザが利用する情報処理装置に送信するステップと、
   前記ユーザから前記商品を購入希望するとの指示を受けた場合に、前記ユーザに対して、前記第１貸付額と前記商品の価格との合計額を下限とする第２貸付額を貸し付けるステップと、を含む情報処理方法。
2. 前記商品を前記ユーザが購入する処理を行うステップ、を更に有する、請求項１に記載の情報処理方法。
3. 前記送信するステップは、前記商品の価格が、前記第１貸付額未満になるように、前記商品を決定する、請求項１又は２に記載の情報処理方法。
4. 前記送信するステップは、前記商品の価格が、前記ユーザが電子商取引において過去に落札した商品の落札金額の平均金額、最低金額、最高金額、又は、過去に落札した商品の落札金額を金額順に並べた際の中央の金額のいずれかよりも低い価格になるように、前記商品を決定する、請求項１～３のいずれか一項に記載の情報処理方法。
5. 前記送信するステップは、前記ユーザがソーシャルネットワークサービスにおいて所定のリアクションを行った商品の中から、前記ユーザに送信する商品を決定する、請求項１～４のいずれか一項に記載の情報処理方法。
6. 前記ユーザと所定の関係を構築しているユーザの中に、前記第１貸付額を超える貸付を受けているユーザが存在する場合、該ユーザに貸し付けている貸付額を前記ユーザに提示するステップ、を有する、請求項１～５のいずれか一項に記載の情報処理方法。
7. 情報処理装置に、
   ユーザから、前記ユーザが貸し付けを希望する第１貸付額を含む金銭の貸付に関する要求を受け付けるステップと、
   前記第１貸付額と前記ユーザのユーザ属性情報とに基づいて、前記ユーザに対して更に貸し付け可能な金額の上限を算出するステップと、
   算出された前記金額の上限の範囲で購入可能な商品の商品情報を前記ユーザが利用する情報処理装置に送信するステップと、
   前記ユーザから前記商品を購入希望するとの指示を受けた場合に、前記ユーザに対して、前記第１貸付額と前記商品の価格との合計額を下限とする第２貸付額を貸し付けるステップと、を実行させるためのプログラム。
8. ユーザから、前記ユーザが貸し付けを希望する第１貸付額を含む金銭の貸付に関する要求を受け付ける受付部と、
   前記第１貸付額と前記ユーザのユーザ属性情報とに基づいて、前記ユーザに対して更に貸し付け可能な金額の上限を算出する算出部と、
   算出された前記金額の上限の範囲で購入可能な商品の商品情報を前記ユーザが利用する情報処理装置に送信する送信部と、
   前記ユーザから前記商品を購入希望するとの指示を受けた場合に、前記ユーザに対して、前記第１貸付額と前記商品の価格との合計額を下限とする第２貸付額を貸し付ける貸付処理部と、を有する情報処理装置。

Images