JP7379681B2 - 動的返済条件を生成するためのシステム及び方法 - Google Patents

Description

クレジット・ラインは、顧客が資金を必要とする場合に顧客がファシリティを利用することを可能にする、銀行又は他の金融機関によって政府、企業、又は個人の顧客に拡張されたクレジット・ファシリティである。クレジット・ラインは、当座貸越限度額、短期ローン、特別目的、輸出前貸信用状、期間ローン、割引、商業手形の購入等のようないくつかの形態をとる。これは事実上、借り手の裁量で容易に利用されうる資金源である。実際に引き出された金銭のみに利息が支払われる。クレジット・ラインは、担保によって保証されてもよいし、無保証であってもよい。

クレジット・カードは、金額に加えて他の合意された手数料を支払うことのカード発行者に対するカード所有者の約束に基づいて、カード所有者が商品及びサービスのために業者に支払うことを可能にするために、ユーザ（カード所有者）に発行される支払カードである。カード発行者（通常、銀行）は、リボルビング口座を作成し、カード所有者にクレジット・ラインを付与し、カード所有者はクレジット・ラインから、業者への支払いのために、又はキャッシュ・アドバンスとして、金銭を借りることができる。クレジット・カードは、利息が課されることを条件として、継続的な負債の残高を顧客が構築することを可能にする。

割賦ローンは、設定された回数のスケジュールされた支払いで経時的に返済されるローンであり、通常、ローンに対して少なくとも２回の支払いが行われる。ローンの期間は、数ヶ月もの短さであってもよいし、３０年もの長さであってもよい。例えば、モーゲージは、割賦ローンの一種である。

以下でより詳細に説明されるように、本開示は、添付の特許請求の範囲による動的返済条件を生成するためのシステム、方法、及びコンピュータ可読で非一時的な媒体を記載する。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、ＰＳＳにより、ユーザについて承認されたクレジット・ラインから引き出されるキャッシュ・アドバンスを求める要求を受信することを含む。クレジット・ラインは、ＰＳＳによって維持される口座に関連してもよく、デフォルト返済条件にさらに関連してもよい。コンピュータで実施される方法は、要求の受信に応答して、要求に関連する文脈特性をＰＳＳによって識別することをさらに含んでもよい。コンピュータで実施される方法は、ＰＰＳに記憶された識別された文脈特性及び履歴文脈情報に適用される機械学習モデルを使用して、ＰＳＳによって、要求されたキャッシュ・アドバンスがデフォルト返済条件とは異なる返済条件に適格であると判定することをさらに含んでもよい。コンピュータで実施される方法は、判定に基づいて、キャッシュ・アドバンスに関連するように修正された返済条件のセットを生成することをさらに含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、修正された返済条件のインジケーションを、承諾のためにユーザのデバイスへ送信することをさらに含んでもよい。コンピュータで実施される方法は、ユーザから承諾のインジケーションを受信すると、修正された返済条件とともに、要求されたキャッシュ・アドバンスを含むように、ＰＳＳによってクレジット・ラインを更新することをさらに含んでもよい。

いくつかの例では、１つ以上の識別された文脈特性は、要求に関連する日付、要求に関連する時刻、及び口座に関連する残高のうちの１つ以上を含む。特定の実施形態では、返済条件を生成することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はピア・ツー・ピア取引のうちの１以上に適用される機械学習モデルを使用することを含んでもよい。いくつかの例では、返済条件は、支払期日、返済スケジュール、及び取引についての金利のうちの１つ以上を含む。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、ＰＳＳにより、及びユーザのモバイル・デバイスから、金額について負債手段にアクセスすることの払戻要求を受信することを含む。負債手段は、ＰＳＳによって維持される口座に関連してもよい。コンピュータで実施される方法は、要求の受信に応答して、ＰＳＳによって、払戻要求の特性を識別することを含んでもよい。コンピュータで実施される方法は、識別された特性に適用される機械学習モデルを使用してＰＳＳによって、払戻要求に関連するように返済条件を生成することを含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、承諾のために返済条件をユーザのモバイル・デバイスへ送信することを含んでもよい。コンピュータで実施される方法は、ユーザから承諾のインジケーションを受信すると、ＰＳＳによって、返済条件とともに金額を含むように口座を更新することを含んでもよい。

いくつかの例では、口座は、各要求について動的返済条件を含むリボルビング口座であってもよい。いくつかの例では、口座は第１返済率を有し、返済条件を生成することは、返済条件に基づいて第１返済率を第２返済率に修正することを含んでもよい。いくつかの例では、負債手段は、口座と確立されたクレジット・ラインであってもよく、要求は、要求についてクレジット・ラインの少なくとも一部を移転することの要求であってもよい。いくつかの例では、返済条件は、支払期日、返済スケジュール、及び取引についての金利のうちの１つ以上を含む。いくつかの例では、返済条件を生成することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はピア・ツー・ピア取引のうちの１つ以上に適用される機械学習モデルを使用することを含んでもよい。

特定の実施形態では、コンピュータで実施される方法は、識別された特性に適用される機械学習モデルを用いてＰＳＳにより、払戻要求に関連するように返済条件を生成することを含んでもよい。返済条件のそれぞれは、異なる返済率を有してもよい。いくつかの例では、コンピュータで実施される方法は、ＰＰＳによって、ユーザのデバイスに関連するユーザ・インタフェース上に返済条件を提示するための命令を提供することと、ＰＰＳによって、及びユーザのデバイスから、返済条件のうちの１つの選択を受信すると、選択された返済条件とともに金額を含むようにユーザの口座を修正することとを含む。

特定の実施形態では、支払サービス・システムは、１以上のプロセッサと、プロセッサのうちの１つ以上に結合され、プロセッサのうちの１つ以上により実行された場合に、支払サービス・システム（ＰＳＳ）に、ユーザのモバイル・デバイスから、負債手段から金額を引き出すことの要求を受信させるように動作可能な命令を含む１つ以上のコンピュータ可読で非一時的な記憶媒体とを含む。
負債手段は、ＰＳＳによって維持される口座に関連してもよい。ＰＳＳは、要求の受信に応答して、要求の特性を識別してもよい。ＰＳＳは、識別された特性に適用される機械学習モデルを使用して、要求に関連するように返済条件を生成してもよい。ＰＳＳは、承諾のために、返済条件をユーザのモバイル・デバイスへ送信してもよい。ＰＳＳは、ユーザから承諾のインジケーションを受信すると、ＰＳＳによって維持されるデータ・ストアにおいて、返済条件とともに金額を含むように口座を更新してもよい。

いくつかの例では、口座は、各要求について動的返済条件を含むリボルビング口座である。いくつかの例では、口座は第１返済率を有し、返済条件を生成することは、返済条件に基づいて第１返済率を第２返済率に修正することを含む。いくつかの例では、負債手段は、ユーザ口座で確立されたクレジット・ラインであってもよい。要求は、要求についてクレジット・ラインの少なくとも一部を移転することの要求であってもよい。いくつかの例では、返済条件は、支払期日、返済スケジュール、及び取引についての金利のうちの１つ以上を含む。いくつかの例では、返済条件を生成することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はピア・ツー・ピア取引のうちの１つ以上への機械学習モデルの適用を含んでもよい。

いくつかの例では、ＰＳＳは、識別された特性に適用される機械学習モデルを使用して、払戻要求に関連するように返済条件を生成してもよい。返済条件のそれぞれは、異なる返済率を有する。いくつかの例では、ＰＳＳは、ユーザのデバイスに関連するユーザ・インタフェース上に返済条件を提示するための命令を提供してもよい。いくつかの例では、ＰＳＳは、返済条件のうちの１つの選択をユーザのデバイスから受信すると、選択された返済条件とともに金額を含むようにユーザの口座を修正してもよい。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、ＰＳＳにより、取引について支払カードに課金することの支払要求を受信することを含んでもよい。支払カードは、ＰＳＳによって維持されるユーザ口座に関連してもよい。ユーザ口座は、複数の取引のそれぞれに異なる金利を適用するように構成されてもよい。コンピュータで実施される方法は、支払要求の受信に応答して、ＰＳＳによって取引の購入特性を識別することを含んでもよい。コンピュータで実施される方法は、識別された購入特性と、ＰＳＳのデータ・ストアに記憶された履歴的な返済データとに基づいて、ＰＳＳによって、支払要求に関連するように金利を決定することを含んでもよい。コンピュータで実施される方法は、ユーザから支払確認を受信すると、ＰＳＳによって、決定された金利とともに取引を含むようにユーザ口座を更新することを含んでもよい。

いくつかの例では、１つ以上の識別された購入特性は、取引が商品についてか又はサービスについてか、商品又はサービスに関連するカテゴリ、取引に関連する日時、取引に関連する業者カテゴリ・コード（ＭＣＣ）、及び商品又はサービスが高級品として識別されるかどうかのうちの１つ以上を含む。いくつかの例では、コンピュータで実施される方法は、ユーザ口座及び支払カードを使用する支払要求の処理を容易にすることを含んでもよい。いくつかの例では、コンピュータで実施される方法は、１つ以上の以前の取引に関連する１つ以上のリスク要因を識別するために、機械学習モデルを用いて１つ以上の以前の取引を評価することを含んでもよい。コンピュータで実施される方法は、機械学習モデルを使用することによって、取引の明細と１つ以上の以前の取引との比較に基づいて取引に関連する１つ以上の現在のリスク要因を識別するために取引の明細を分析することをさらに含んでもよく、支払要求に関連する金利を決定することは、取引に関連する識別された現在のリスク要因にさらに基づいてもよい。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、ＰＳＳにより、及びユーザのモバイル・デバイスから、取引について負債手段にアクセスすることの支払要求を受信することを含んでもよい。負債手段は、ＰＳＳによって維持されるユーザ口座に関連してもよい。コンピュータで実施される方法は、支払要求の受信に応答して、ＰＳＳによって取引の特性を識別することを含んでもよい。コンピュータで実施される方法は、識別された特性に基づいて、ＰＳＳによって、支払要求に関連するように金利を決定することを含んでもよい。コンピュータで実施される方法は、支払確認を識別すると、ＰＳＳによって、決定された金利とともに取引を含むようにユーザ口座を更新することを含んでもよい。

いくつかの例では、ユーザ口座は、各取引について動的返済条件を含むリボルビング口座であってもよい。いくつかの例では、ユーザ口座は第１金利を有し、金利を決定することは、取引について第１金利を第２金利に修正することを含む。いくつかの例では、負債手段は支払カードであり、要求は、取引について支払カードに請求することの支払要求である。いくつかの例では、コンピュータで実施される方法は、ユーザ口座及び負債手段を使用する支払要求の処理を容易にすることを含んでもよい。いくつかの例では、ユーザは、ＰＳＳの支払サービスを使用する業者である。いくつかの例では、金利を決定することは、取引に関連するアイテム又はサービスの属性、業者の現在の業者在庫、又は業者の最近の取引活動のうちの１つ以上に適用される機械学習モデルを使用することをさらに含む。いくつかの例では、金利を決定することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はピア・ツー・ピア取引のうちの１つ以上に適用される機械学習モデルを使用することを含む。

特定の実施形態では、支払サービス・システムは、１以上のプロセッサと、プロセッサのうちの１つ以上に結合された１以上のコンピュータ可読で非一時的な記憶媒体とを含み、プロセッサのうちの１つ以上により実行された場合に、支払サービス・システムに、ユーザのモバイル・デバイスから、取引について負債手段にアクセスすることの支払要求を受信させるように動作可能な命令を含む。負債手段は、ＰＳＳによって維持されるユーザ口座に関連してもよい。ＰＳＳは、支払要求の受信に応答して、取引の特性を識別してもよい。ＰＳＳは、識別された特性に基づいて、支払要求に関連するように金利を決定してもよい。ＰＳＳは、ユーザから支払確認を受信すると、決定された金利とともに取引を含むようにユーザ口座を更新してもよい。

いくつかの例では、ユーザ口座は、各取引について動的返済条件を含むリボルビング口座であってもよい。いくつかの例では、ユーザ口座は第１金利を有し、金利を決定することは、取引について第１金利を第２金利に修正することを含む。いくつかの例では、負債手段は支払カードであってもよい。要求は、取引について支払カードに課金する支払要求であってもよい。いくつかの例では、ＰＳＳは、ユーザ口座及び負債手段を使用する支払要求の処理を容易にしてもよい。いくつかの例では、ユーザは、ＰＳＳの支払サービスを使用する業者であってもよい。いくつかの例では、金利を決定することは、取引に関連するアイテム又はサービスの属性、業者の現在の業者在庫、又は業者の最近の取引活動のうちの１つ以上への機械学習モデルの適用をさらに含む。いくつかの例では、金利を決定することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はピア・ツー・ピア取引のうちの１つ以上への機械学習モデルの適用を含む。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、第１ユーザに関連する第１デバイスからＰＳＳにより、第２ユーザから金額を借りることの要求を受信することを含んでもよい。第１ユーザは、ＰＳＳによって維持される第１ユーザ口座に関連してもよく、第２ユーザは、ＰＳＳによって維持される第２ユーザ口座に関連してもよい。コンピュータで実施される方法は、要求を受信することに応答して、ＰＳＳによって、第１ユーザ口座に関連する第１取引履歴と、ＰＳＳのデータ・ストア内の第２ユーザ口座に関連する第２取引履歴とを識別してもよい。コンピュータで実施される方法は、ＰＳＳによって、第１取引履歴及び第２取引履歴に基づいて、金額を借りることの要求に関連するように返済条件を決定することを含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、第２ユーザ口座に関連する第２取引履歴に基づいて、金額を第２ユーザに借りることの要求を送信する時刻を識別することを含んでもよい。コンピュータで実施される方法は、その時点で第２ユーザに関連する第２デバイスに金額を借りることの要求のインジケーションをＰＳＳによって送信することを含んでもよい。コンピュータで実施される方法は、第２ユーザから承諾のインジケーションを受信すると、ＰＳＳによって、返済条件とともに借りられる要求された金額を含むように第１ユーザ口座を更新することを含んでもよい。

いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、要求に関連する文脈特性を識別することを含んでもよい。返済条件を決定することは、識別された文脈特性に適用される機械学習モデルを使用することを含んでもよい。１つ以上の識別された文脈特性は、要求に関連する日付、要求に関連する時刻、及び口座に関連する残高のうちの１つ以上を含んでもよい。いくつかの例では、返済条件を決定することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又は第１ユーザ口座又は第２ユーザ口座に関連するピア・ツー・ピア取引のうちの１つ以上に適用される機械学習モデルを使用することを含んでもよい。いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、第２ユーザのそれぞれを含む第１ユーザの取引履歴に基づいて、第１ユーザが金額を借りることを要求できる第２ユーザのリストを識別することを含んでもよい。コンピュータで実施される方法は、第２ユーザのリストを第１ユーザに提示するための命令を、ＰＳＳによって第１デバイスへ送信することを含んでもよい。第２ユーザから金額を借りることの要求を受信することは、第１ユーザが、第２ユーザのリストから第２ユーザを選択することを含んでもよい。

特定の実施形態では、コンピュータで実施される方法は、支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、ＰＳＳにより、第１ユーザの第１デバイスから、第２ユーザから金額を借りることの要求を受信することを含んでもよい。第１ユーザはＰＳＳによって維持されている第１ユーザ口座に関連してもよく、第２ユーザはＰＳＳによって維持されている第２ユーザ口座に関連してもよい。コンピュータで実施される方法は、要求を受信することに応答して、ＰＳＳによって、第１ユーザ口座に関連する第１履歴文脈情報と、第２ユーザ口座に関連する第２履歴文脈情報とを識別してもよい。コンピュータで実施される方法は、ＰＳＳによって、第１履歴文脈情報及び第２履歴文脈情報に基づいて、金額を借りることの要求に関連するように返済条件を決定することを含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、第２ユーザに関連する第２デバイスへ、金額を借りることの要求のインジケーションを送信することを含んでもよい。コンピュータで実施される方法は、第２ユーザから承諾のインジケーションを受信すると、ＰＳＳによって、返済条件とともに、借りられる要求された金額を含むように、第１ユーザ口座を更新することを含んでもよい。

いくつかの例では、第１ユーザ口座は、各要求について動的返済条件を含むリボルビング口座であってもよい。ある例では、コンピュータで実施される方法は、ＰＳＳによって、要求に関連する文脈特性を識別することを含んでもよい。返済条件を決定することは、識別された文脈特性に適用される機械学習モデルを使用することを含んでもよい。１つ以上の識別された文脈特性は、要求に関連する日付、要求に関連する時刻、及び口座に関連する残高のうちの１つ以上を含んでもよい。いくつかの例では、返済条件を決定することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又は第１ユーザ口座又は第２ユーザ口座に関連するピア・ツー・ピア取引のうちの１つ以上に適用される機械学習モデルを使用することを含んでもよい。いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、第２ユーザのそれぞれを含む第１ユーザの取引履歴に基づいて、第１ユーザが金額を借りることを要求できる第２ユーザのリストを識別することを含んでもよい。コンピュータで実施される方法は、第２ユーザのリストを第１ユーザに提示するための命令を、ＰＳＳによって第１デバイスへ送信することを含んでもよい。第２ユーザから金額を借りることの要求を受信することは、第１ユーザが、第２ユーザのリストから第２ユーザを選択することを含んでもよい。

いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、返済条件からの決定された返済スケジュールに基づいて第１ユーザ口座から返済金額を自動的に引き落とすことによって、要求された金額の返済を容易にすることを含んでもよい。いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、第１ユーザ口座への受取クレジットの金額を検出することを含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、借りられた金額についての返済金額として使用される受取クレジットの金額のパーセンテージを決定することを含んでもよい。コンピュータで実施される方法は、ＰＳＳによって、第１ユーザ口座から第２ユーザ口座への返済金額の移転を開始することを含んでもよい。いくつかの例では、コンピュータで実施される方法は、ＰＳＳによって、第１ユーザが返済条件に基づいて要求された金額を返済するためのリマインダを生成することを含んでもよい。

特定の実施形態では、支払サービス・システムは、１以上のプロセッサと、プロセッサのうちの１つ以上に結合され、プロセッサの１つ以上により実行されると、支払サービス・システム（ＰＳＳ）に、第１ユーザの第１デバイスから、第２ユーザから金額を借りることの要求を受信させるように動作可能な命令を含む１以上のコンピュータ可読で一時でない記憶媒体とを含んでもよい。第１ユーザは、ＰＳＳによって維持される第１ユーザ口座に関連してもよく、第２ユーザは、ＰＳＳによって維持される第２ユーザ口座に関連してもよい。要求を受信することに応答して、ＰＳＳは、第１ユーザ口座に関連する第１履歴文脈情報と、第２ユーザ口座に関連する第２履歴文脈情報とを識別してもよい。ＰＳＳは、第１履歴文脈情報及び第２履歴文脈情報に基づいて、金額を借りることの要求に関連するように返済条件を決定してもよい。ＰＳＳは、第２ユーザに関連する第２デバイスに金額を借りることの要求のインジケーションを送信してもよい。ＰＳＳは、第２ユーザから承諾のインジケーションを受信すると、返済条件とともに借りられる要求された金額を含むように第１ユーザ口座を更新してもよい。

いくつかの例では、第１ユーザ口座は、各要求について動的返済条件を含むリボルビング口座であってもよい。いくつかの例では、ＰＳＳは、要求に関連する文脈特性を識別してもよい。返済条件を決定することは、識別された文脈特性に適用される機械学習モデルを使用することを含んでもよい。１つ以上の識別された文脈特性は、要求に関連する日付、要求に関連する時刻、及び口座に関連する残高のうちの１つ以上を含んでもよい。いくつかの例では、返済条件を決定することは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又は第１ユーザ口座又は第２ユーザ口座に関連するピア・ツー・ピア取引のうちの１つ以上に適用される機械学習モデルを使用することを含んでもよい。いくつかの例では、ＰＳＳは、第２ユーザのそれぞれを含む第１ユーザの取引履歴に基づいて、第１ユーザが金額を借りることを要求できる第２ユーザのリストを識別してもよい。ＰＳＳは第１デバイスに、第２ユーザのリストを第１ユーザに提示するための命令を送信してもよい。第２ユーザから金額を借りることの要求を受け取ることは、第１ユーザが、第２ユーザのリストから第２ユーザを選択すること含んでもよい。いくつかの例では、ＰＳＳは、返済条件から決定された返済スケジュールに基づいて第１ユーザ口座から返済金額を自動的に引き落とすことによって、要求された金額の返済を容易にしてもよい。いくつかの例では、ＰＳＳは、第１ユーザ口座への受取クレジットの金額を検出してもよい。ＰＳＳは、借りた金額についての返済金額として使用される受取クレジットの金額のパーセンテージを決定してもよい。ＰＳＳは、第１ユーザ口座から第２ユーザ口座への返済金額の移転を開始してもよい。いくつかの例では、ＰＳＳは、第１ユーザが返済条件に基づいて要求された金額を返済するためのリマインダを生成してもよい。

本開示の非限定的な実施形態は、概略的であり縮尺通りに描かれることを意図されていない添付の図面を参照して、例として説明される。従来技術を表すものとして示されない限り、図面は、本開示の態様を表す。

、 １つの実施形態による例示的な支払サービス・システム・ネットワークを説明する。

１つの実施形態による支払サービス・システムのための例示的なシステム・アーキテクチャを説明する。

、 例示的な実施形態による、取引のための返済条件を生成するためのプロセスを説明する。

、 例示的な実施形態による、支払カードを使用する取引のための返済条件を生成するためのプロセスを説明する。

、 例示的な実施形態による、クレジット・ラインにアクセスするための返済条件を生成するためのプロセスを説明する。

、 、 例示的な実施形態による、別のユーザから借りるための返済条件を生成するためのプロセスを説明する。

、 、 １つの実施形態による、負債手段にアクセスすることに関連する例示的なユース・インタフェースを説明する。

、 、 、 、 １つの実施形態による、負債手段にアクセスすることに関連する例示的なユーザ・インタフェースを説明する。

、 、 、 、 、 １つの実施形態による、負債手段にアクセスすることに関連する例示的なユーザ・インタフェースを説明する。

、 、 １つの実施形態による、負債手段にアクセスすることに関連する例示的なユーザ・インタフェースを説明する。

本書に記載される特定の実施形態は、支払サービス・システムを通じた、伝統的なライン、クレジット及びクレジット・カード口座、又は割賦ローンのような負債手段の管理及び履行を可能にする。本書で説明される特定の実施形態は、ユーザが取引に対する支払いを行うため、送金を要求するために、又は別の消費者から資金を借りることを要求するために、負債手段にアクセスすることを可能にする。本書に記載される特定の実施形態は、取引のための適切な返済条件を決定するために、取引の購入特性の分析を可能にする。特定の実施形態は、取引の特性に基づいてリアルタイムでのデフォルト返済条件の修正を含む動的返済条件を可能にする。特定の実施形態は、ユーザに適合する返済スケジュールの決定を通じてユーザの返済を改善するクレジット・ラインへのユーザのアクセスを改善する。

特定の実施形態は、異なるユーザ・プロファイル又は取引プロファイル文脈について負債のリスクのレベルを分類し、リスクのレベルを最小化する返済スケジュールを決定するように機械学習モデルを訓練することを可能にする。例として、限定されるものではないが、機械学習モデルは、ユーザの取引履歴の分析に基づいて、高リスクのユーザ・プロファイル又は取引プロファイル文脈を識別するように訓練されてもよい。すなわち、ユーザが典型的に、自分の残高の大部分を自分の口座に費やすならば、負債の返済が不可能になるかもしれない。したがって、機械学習モデルは、負債の返済に失敗する特定のユーザに関連するリスクのレベルを低減する返済スケジュールを決定してもよい。例えば、機械学習モデルは、ユーザが１回に少額の負債を返済することを可能にするために複数週間にわたって支払いを分散することが最適な返済スケジュールであると決定してもよい。別の例として、限定されるものではないが、取引プロファイル文脈は、取引の文脈を示してもよく、機械学習モデルは、高リスクの取引でありうる特定の取引（例えば、高級品、閾値金額のアイテム、特定のエリアで行われる購入）を識別してもよい。機械学習モデルは、ユーザが負債の返済に失敗するリスクを軽減する返済スケジュールを決定してもよい。機械学習モデルは、高リスクなユーザ・プロファイル及び／又は取引プロファイル文脈に関連する傾向を識別するように訓練されてもよい。機械学習モデルは、ユーザが負債の返済に失敗するリスクのレベルを最小化するように、対応する返済スケジュールを決定するように訓練されてもよい。

現在、負債手段（例えば、クレジット・カード、クレジット・ライン、又は割賦ローン）を使用するほとんどの購入には、固定条件（例えば、設定された返済スケジュール、金利、支払期日など）が付随する。しかし、一部の取引は、他の取引よりも高リスクの取引であると決定されるかもしれず、一部の取引は低リスク取引であるかもしれない。さらに、それは、負債手段についての条件を変更することができるのは、負債手段を発行する機関のみであるかもしれない。

特定の実施形態では、支払サービス・システムは、そのユーザが、各自の口座に関連してもよい１以上の負債手段にアクセスするためのプラットフォームを提供する。これらの負債手段は、支払サービス・システム又は支払サービス・システムに関連するエンティティによって発行されてもよいクレジット・カードを含んでもよい。これらの負債手段はまた、ユーザの口座に関連するクレジット・ラインを含んでもよい。特定の実施形態では、支払サービス・システムは、ユーザのための１以上の金融口座を管理してもよい。これらの金融口座は、ユーザが利用可能な１つ以上の負債手段を含んでもよい。各金融口座は、ユーザによって所有された実際の又は代表的な金額のフィアット通貨、又はユーザに所有又はユーザに割り当てられた他の資産（例えば、証券、暗号通貨トークン）を保持してもよい。支払サービス・システムはまた、１つ以上の第三者システム（例えば、銀行）によって管理される、ユーザに関連する１つ以上の金融口座へのアクセスを有してもよい。

特定の実施形態では、支払サービス・システムは、種々のユーザについて資産所有権を記録するように設計されたデータベースを維持してもよい。例として、限定されるものではないが、支払サービス・システムは、支払サービス・システムによって保持される資産及び負債を追跡するための１つ以上の台帳を記憶してもよく、支払サービス・システムによって保持されるこのような各資産又は各負債は、支払サービス・システム自体によって全体的に又は部分的に、及び／又は支払サービス・システムの１以上のユーザによって全体的に又は部分的に所有されてもよい。台帳は、支払サービス・システムによって保持される資産又は負債の金額を表す、支払サービス・システムに関連するサービス残高を記憶してもよい。サービス残高は例えば、１つ以上のフィアット通貨のそれぞれについてのフィアット通貨残高、１つ以上の証券資産のそれぞれについての証券残高、１つ以上の暗号通貨のそれぞれについての暗号通貨残高、１つ以上の負債手段のそれぞれについての負債残高、他の適切なデータ記録、又はこれらの任意の組合せを含んでもよい。支払サービス・システムはまた、複数のユーザのそれぞれについての追加の台帳を記憶してもよい。台帳は、各ユーザについてのプロファイルの一部として記憶されてもよい。１つ以上の台帳は、支払サービス・システムによって保持され１以上のユーザによって所有される資産の金額を表すユーザ残高を記憶してもよい。これらは、サービス残高と同様の内容を有してもよい。１つ以上の台帳は、ユーザの負債手段に関連する取引を追跡する負債台帳であってもよい。支払サービス・システムは、資産の所有権を表す情報を記憶するのに適した他のデータ構造を使用してもよい。

特定の実施形態では、ユーザは、負債手段にアクセスすることの要求を支払サービス・システムへ送信することによって、支払サービス・システムを通じて自分の口座に関連する負債手段にアクセスしてもよい。ユーザは、ポイント・オブ・セールス（ＰＯＳ）デバイスを介して店で購入すること、オンライン購入を行うこと、ピア・ツー・ピア（Ｐ２Ｐ）取引を介して送金すること、クレジット・ラインからキャッシュ・アドバンスを要求することのような取引を実施してもよい。特定の実施形態では、ユーザが取引についての支払いを行うために負債手段（例えば、クレジット・カード）を使用している際に、負債手段にアクセスすることの要求が自動的に送信されてもよい。例として、限定されるものではないが、ユーザは、ユーザの口座に関連する支払カードをスワイプしてもよく、要求は、自動的に生成され、支払サービス・システムへ送られてもよい。特定の実施形態では、ユーザは、負債手段へのアクセスを要求するためにユーザ・インタフェースにアクセスしてもよい。例として、限定されるものではないが、ユーザは、クレジット・ラインに関連するユーザ・インタフェースにアクセスしたり、コンピューティング・デバイスにインストールされたブラウザによって表示されるウェブページにアクセスしたりするために、支払サービス・システム又は他のエンティティに関連するモバイル・アプリケーションと対話してもよい。ユーザは、クレジット・ラインの一部をユーザの残高に移すことを要求することによって、クレジット・ラインから引き出す（例えば、キャッシュ・アドバンスする）ことを選択するために、ユーザ・インタフェース内の１つ以上の要素と対話してもよい。例として、限定されるものではないが、ユーザが金融口座に＄４００の残高を有し、＄３００の残高（例えば、おそらくは賃料のため）を維持することを望むならば、ユーザは、残高がこの金額を下回らないようにするために、＄１００を超える任意の購入についてクレジット・ラインにアクセスすることを望んでもよい。したがって、ユーザは、取引のためにクレジット・ラインの一部を移すために、金融口座に関連するクレジット・ライン（例えば、＄２００のクレジット・ライン）から引き出してもよい。ユーザは、ユーザ・インタフェースの１つ以上の要素を通じて、クレジット・ラインから引き出す値を入力し、クレジット・ラインの一部をユーザの残高に移すことの要求を支払サービス・システムへ送信してもよい。

特定の実施形態では、ユーザは、ユーザ残高が閾値金額を下回らないように、残高閾値を設定してもよい。例として、限定されるものではないが、ユーザは、金融口座の残高に対して＄３００の限度を設定してもよく、何らかの取引が残高を＄３００の限度未満に下げるならば、金融口座に関連するクレジット・ラインの一部のユーザの残高への移転を要求することの要求が生成されてもよい。特定の実施形態では、残高閾値は、特定の取引（例えば、賃料）に割り当てられてもよく、これは、残高を残高閾値未満に低下させうる。例として、限定されるものではないが、残高閾値は、賃料又は水道光熱費に関連しない購入について設定されてもよい。特定の実施形態では、支払サービス・システムは、クレジット・ラインから一部を引き出すことの要求を受信し、クレジット・ラインからの引き出しの承諾のために、金融口座に関連するコンピューティング・デバイス（例えば、ユーザが金融口座にサインインしたスマートフォン）へ要求を自動的に送信してもよい。要求は、取引の金額について自動的に生成されてもよい。例として、限定されるものではないが、ユーザが＄３００に設定された限度を有し、＄４００の残高を有し、＄１２５で食料雑貨を購入しようとするならば、ユーザの金融口座に関連するクレジット・ラインから＄２５を引き出すことの要求が生成されてもよい。支払サービス・システムは、設定された残高閾値を超える取引の通知を送信し、＄２５のクレジット・ラインからの引き出しを承認することの承諾を求める要求をユーザのスマートフォンへ送信してもよい。１つの実施形態によれば、ユーザに承諾を送信する前に、支払サービス・システムは、取引のリアルタイム・リスク評価を実行し、クレジット・ラインからの＄２５の引き出しについて修正された返済条件を生成してもよい。修正された返済条件は、ユーザ口座の負債手段（例えば、クレジット・ライン）に関連するデフォルト返済条件とは異なってもよく、取引の特性に基づく。例えば、支払サービス・システムは、要求／取引の特性を分析して、それが（地理的位置データに基づく）食料品店での購入、＄５０未満の確認された引き出し要求、及び（支払サービス上の過去の取引履歴に基づく）数日以内又は次の給与預金に関連すると判定してもよい。これらの要因は、より短い返済スケジュール及びより低い金利で（デフォルト条件からの）修正された返済条件を支払サービス・システムに提供させてもよい。ユーザが＄２５についてクレジット・ラインからの引き出しを、識別された条件で承認すると、取引は承諾されてもよく、支払サービス・システムは、デフォルト又は修正された返済条件とともにクレジット・ラインからの引き出しを含むようにユーザ口座を更新してもよい。

特定の実施形態では、支払サービス・システムは、取引の購入特性を識別してもよい。購入特性は、業者情報（例えば、業者識別子、業者在庫情報など）、取引が商品又はサービスであるかどうか、取引に関連するカテゴリ、取引に関連する日時、取引に関連する業者カテゴリ・コード（ＭＣＣ）、及び取引が高級品であるかどうかを含んでもよい。他の購入特性が含まれてもよい。支払サービス・システムは、取引明細から購入特性を抽出し、業者からの情報を要求し、取引の１つ以上の購入特性を識別するための他の手段を抽出してもよい。例として、限定されるものではないが、ユーザが金融口座に関連する支払カードを通じて新しいラップトップを購入しようと試みるならば、支払サービス・システムは、要求から、取引が新しいラップトップについてのものであること、特定の業者からのものであること、特定の日時におけるものであることなどを識別してもよい。支払サービス・システムは、取引に関連するカテゴリを決定するか、又は取引明細からそれを抽出してもよい。支払サービス・システムは、取引の個々のアイテムを識別し、及び／又は特定のカテゴリにアイテムを一緒にグループ化してもよい。例として、限定されるものではないが、取引が異なるカテゴリの複数のアイテムを含むならば、支払サービス・システムは、各個々のカテゴリを識別してもよい。特定の実施形態では、支払サービス・システムは、購入特性を表す１つ以上の特徴ベクトルを抽出し、特徴ベクトルのそれぞれを分類してもよい。各特徴ベクトルの分類及び他の購入特性は、本書に記載されるように、取引に関連する条件の集合を決定するために使用されてもよい。特定の実施形態では、支払サービス・システムはまた、履歴的な返済データを決定してもよい。履歴的な返済データは、ユーザ口座に関連してもよく、及び／又は取引に関連してもよい。例として、限定されるものではないが、履歴的な返済データは、ユーザがどのように負債を返済するか、又は特定の取引（例えば、自動車の特定のモデル）がどのように返済されるかに関するデータであってもよい。履歴的な返済データは、ユーザ口座の以前の取引及び／又は支払サービス・システムの他のユーザを含む同様の取引を分析することによって決定されてもよい。支払サービス・システムは、取引について履歴的な返済データを決定するために、１つ以上の以前の取引及び／又は１つ以上の同様の取引を評価するように機械学習モデルを使用してもよい。特定の実施形態では、支払サービス・システムは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、又はＰ２Ｐ取引にアクセスしてもよい。

特定の実施形態では、支払サービス・システムは、負債手段を使用する取引に関連する条件又は返済条件の集合を動的に決定してもよい。条件又は返済条件の集合は、取引をいつ清算すべきかの支払期日、返済スケジュール、及び取引の金利、又は取引に関連する手数料を含んでもよい。特定の実施形態では、支払サービス・システムは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、及び／又はＰ２Ｐ取引に適用される機械学習モデルを使用して、返済条件を生成してもよい。特定の実施形態では、ユーザが（例えば、支払カードを使用して、又はコンピューティング・デバイス上のモバイル・アプリケーションで直接に）取引について支払いを行うために負債手段にアクセスすることの要求を送信する場合に、支払サービス・システムは、取引に関連する購入特性及び履歴的な返済データに基づいて、条件の集合を決定してもよい。例として、限定されるものではないが、支払サービス・システムは、履歴的な返済データを通じて、ユーザが閾値回数の支払いを怠ったことを識別してもよい。支払サービス・システムは、怠った支払いの回数に基づいて、取引に関連する金利を上昇させてもよい。例として、限定されるものではないが、ユーザが２回の支払いを怠ったならば、支払サービス・システムは、取引の金利を少し上昇させてもよいが、ユーザが１０回の支払いを怠ったならば、支払サービス・システムは、金利を大量に上昇させるか、又は負債手段へのアクセスを自動的に拒否してもよい。別の例として、限定されるものではないが、支払サービス・システムは、取引の特定のカテゴリ（例えば、ハイエンド電子機器）をハイリスク取引と判定し、負債手段を使用する当該カテゴリの取引に関連する金利を上昇させてもよい。逆に、低リスク取引として識別される取引（例えば、閾値金額よりも低いコストを有する食料品）は、低減された金利を有してもよい。支払サービス・システムは、取引が異なるカテゴリの複数のアイテムを含むと判定し、取引における個々のアイテムの組合せに基づいて、条件の集約集合を生成してもよい。例として、限定されるものではないが、支払サービス・システムは、各アイテムに関連する返済条件を決定し、返済条件のそれぞれに重みを適用して、条件の全体的な集合を決定してもよい。例えば、金利は、各アイテムの様々なリスク評価に基づいて上下に調整されてもよい。重みは、取引の総コストと比較した個々のアイテムのコストの割合に基づいて適用されてもよい。特定の実施形態では、支払サービス・システムは、取引の項目化された受領証を提供してもよい。項目化された受領証は、取引について支払う（例えば、クレジット・カードで支払う、又はクレジット・ラインから引き出す）ためにローンを組むアイテムを選択するためにユーザに提供されてもよい。項目化された受領証を用いて、個々の返済条件は、個別の購入特性に基づいて、取引における個々のアイテムごとに示されてもよい。ユーザは、取引全体を組み合わせる、及び／又は取引の個々のアイテムを選択して、個別のアイテムについて支払うためにローンを組むオプションが提示されてもよい。別の例として、限定されるものではないが、返済条件を決定するために取引の日時が使用されてもよい。例えば、支払サービス・システムは、クリスマス前後の購入を高リスク取引でありうると判定し、当該期間中に負債手段を使用する取引の金利を上昇させてもよい。支払サービス・システムはまた、購入特性又は履歴的な返済データに基づいて、（ユーザが負債手段にアクセスすることを要求する前に負債を返済することを促すために）支払期日を繰り上げるか、又は（ユーザが負債を返済するためのより多くの時間を許容にするために）支払期日を繰り下げてもよい。支払サービス・システムは、負債手段を使用する取引に関連する金額に料金を適用してもよい。例として、限定されるものではないが、支払サービス・システムは、クレジット・ラインの引き出しに対して２．５％の料金を適用する。条件又は返済条件の他の集合と同様に、料金は、購入特性、履歴的な返済データ、又はユーザ口座に関連する他のデータのいずれかに基づいて変化してもよい。特定の実施形態では、支払サービス・システムは、識別された業者を使用して、返済条件を決定してもよい。例として、限定されるものではないが、業者は、支払サービス・システムを通じてプロモーションを実行し、業者における取引（又は特定のサービス又は商品に対する取引）について負債手段にアクセスするために、より低い金利又はより低い料金を宣伝してもよい。業者は、返済条件を変更するために支払サービス・システムに料金を提供してもよい。特定の実施形態では、料金は、クレジット・ラインの引き出しに関する利息の代わりに課されてもよい。例として、限定されるものではないが、クレジット・ラインに関連する金利が典型的には２０％ＡＰＲであるならば、クレジット・ラインは、クレジット・ラインの引き出しに関して利息を支払う代わりに、クレジット・ラインの任意の引き出しに対して課されうる２．５％の料金を有してもよい。したがって、ユーザがクレジット・ラインから＄２０を引き出すことを要求しているならば、ユーザはクレジット・ラインの引き出しに対して課される利息を有する代わりに、＄０．５０を支払うオプションを有する。特定の実施形態では、ユーザは、支払サービス・システムの支払サービスを使用する業者であってもよい。支払サービス・システムは、取引に関連するアイテム又はサービスの属性、業者の現在の業者在庫、又は業者の最近の取引活動に適用される機械学習モデルを使用して、条件又は返済条件の集合を生成してもよい。例として、限定されるものではないが、最近の取引活動が、業者が遅い月を有することを示すならば、支払サービス・システムは、非ビジネス関連の購入（例えば、業者のビジネスに関連する特定のカテゴリではない購入）に、より高い金利が適用されることを決定してもよい。金利の上昇は、業者が不正な購入を行うことを妨げるかもしれない。

特定の実施形態では、支払サービス・システムは、負債手段を用いた取引について返済スケジュールを決定してもよい。支払サービス・システムは、負債手段を使用する取引についての標準的又はデフォルトの返済スケジュールを有してもよい。支払サービス・システムは、受取給与、預金活動、株又は証券に関連するキャッシュ・フロー、及び／又はＰ２Ｐ取引に適用される機械学習モデルを使用して、修正された返済スケジュールを生成してもよい。支払サービス・システムは、生成された返済スケジュールに基づいて標準返済スケジュールを変更してもよい。この返済スケジュールは、負債手段の返済を最適化するようにカスタマイズされてもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザが隔月に支払われることを決定し、ユーザが支払われた後（例えば、支払日の翌日）に一致する返済スケジュールをセットアップ又は修正してもよい。特定の実施形態では、支払サービス・システムは、ユーザが支払われたというインジケーションを受信し、負債（クレジット・カード、割賦ローン等）を返済するために給料支払小切手の一部を引き落としてもよい。特定の実施形態では、支払サービス・システムは、取引が行われたときのような購入特性を使用して、返済スケジュールを決定してもよい。例として、限定されるものではないが、支払サービス・システムは、ショッピング休暇中に行われる取引について返済スケジュールを（例えば、８週間から１０週間へ）延ばしてもよい。特定の実施形態では、支払サービス・システムは、取引に関連する金額に基づいて返済スケジュールを決定してもよい。例として、限定されるものではないが、取引の金額が大きいならば、支払サービス・システムは、プラットフォーム上の同様の取引に関連する履歴的な返済活動に基づいて、返済スケジュールを延ばしてもよい。これは、利息を発生させる前に負債の返済を促進するのに役立ちうる。また、大規模な取引は、適時な負債の返済をさらに促進するために、より高い金利を有してもよい。支払サービス・システムは、ユーザの収入に基づいて返済スケジュールを決定してもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザが隔月に＄１０００の給料支払小切手を受け取ることを識別し、機械学習モデルを通じて負債手段を使用することからの負債について、ユーザが各給料支払小切手につき＄１００を支払うことができると決定してもよい。例えば、機械学習モデルは、ユーザが典型的に１ヶ月の間に費やす金額を決定し、ユーザの給料支払小切手のどの部分が負債を返済するために割り当てられうるかを決定してもよい。支払サービス・システムは、取引の金額及びユーザの取引履歴に基づいて、より短い返済スケジュールを生成してもよい。すなわち、例として、限定されるものではないが、ユーザが＄１００以下の取引についての支払いを行うために負債手段にアクセスすることを要求するならば、支払サービス・システムは、取引のコストの１回の支払いを含む返済スケジュールを生成してもよい。別の例として、限定されるものではないが、負債手段を使用する取引が＄１０００であるならば、支払サービス・システムは、１０週間の返済スケジュールを生成してもよい。

特定の実施形態では、支払サービス・システムは、クレジット・ライン及び／又は別の負債手段の使用をユーザに承認するかどうかを判定するために、ユーザの取引履歴、ユーザのネットワークのサイズ（例えば、ユーザが頻繁に取引を行う友人の数）、及び第三者情報（例えば、信用調査機関情報）を分析してもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザが取引について支払うのに十分な資金を既に有しているかどうかを判定し、取引について支払うためにクレジット・ラインの引き出しを必要としないと判定するために、受取キャッシュ・フローのような取引履歴を分析してもよい。支払サービス・システムは、ユーザが取引について自分の口座に十分な資金を有し、クレジット・ラインからの引き出しを必要としないという判定に応答して、ユーザに通知してもよい。別の例として、限定されるものではないが、ユーザが頻繁に取引（例えば、支払い及び金銭の要求）を行う大きなネットワークを有するならば、支払サービス・システムは、ユーザがローンを支払う確率が高く、及び／又はユーザのネットワークからの援助を要求できると判定してもよい。

特定の実施形態では、支払サービス・システムは、承諾のために、条件又は返済条件の集合をユーザへ送信してもよい。支払サービス・システムは、負債手段を使用する取引に関連する条件又は返済条件の集合を決定した後、支払サービス・システムは、返済条件の集合をユーザへ送信してもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザのスマートフォンのようなユーザ口座に関連するコンピューティング・デバイスへ承諾の要求を送信してもよい。ユーザがレビューするために条件又は返済条件の集合を表示するために、支払サービス・システムに関連するモバイル・アプリケーションのユーザ・インタフェースに、条件又は返済条件の集合が提示されてもよい。特定の実施形態では、支払サービスは、条件又は返済条件オプションの複数の集合を提供し、他の返済条件が動的に変化するように、条件又は返済条件の集合のうちの１つ以上をユーザが変更することを可能にしてもよい。例として、限定されるものではないが、ユーザは、隔週のかわりに毎週、ユーザの残高から金額を引き落とすように返済スケジュールを変更してもよく、又はユーザは、支払期日に全額を支払うことを決定してもよい。支払期日のような、ユーザによって変更不可能であってもよいいくつかの返済条件が存在してもよい。特定の実施形態では、ユーザは、１年以内に支払期日を延長するための回数を割り当てられてもよい。回数は、ユーザ口座に関連する履歴的な返済データに基づいてもよい。例として、限定されるものではないが、ユーザが支払いを怠らなかったならば、ユーザは、１年に２回の支払期日延長を割り当てられてもよい。特定の実施形態では、支払サービス・システムは、返済スケジュールの一部として、ユーザの残高からの自動引き落としを実行してもよい。ユーザが条件又は返済条件の集合を承諾した後、支払サービス・システムは、条件又は返済条件の集合とともに取引を含むようにユーザ口座を更新してもよい。例として、限定されるものではないが、ユーザが返済条件を承諾した後、支払サービス・システムは、自身の返済条件を有する取引を、ユーザ口座に関連する取引履歴内のユーザの口座に掲載してもよい。特定の実施形態では、各取引は、それ自身の個々の返済条件を有してもよい。支払サービス・システムは、１つ以上の負債手段に関連するユーザ口座内の各取引を集約し、ユーザ入力に基づいて取引を並べ替えてもよい。例として、限定されるものではないが、支払サービス・システムは、日付、支払期日、金利、金額などによって取引を並び替えてもよい。特定の実施形態では、支払サービス・システムは、負債手段を使用する取引についてユーザが利息を課される前の期間を決定し、支払アプリケーションに関連するモバイル・アプリケーション内のユーザ・インタフェースを介してユーザにそれを提示してもよい。ユーザが期間の前に取引に関連する負債を支払わないならば、支払サービス・システムは、取引の返済条件に基づいて、負債の残りに金利を適用してもよい。支払サービス・システムは、任意の変更でユーザ口座を更新してもよい。特定の実施形態では、ユーザ口座は、各取引について動的な返済条件を含むリボルビング口座であってもよい。

特定の実施形態では、ユーザは、別のユーザから金額を借りることを要求してもよい。例として、限定されるものではないが、ユーザは、友人から資金を借りることを要求してもよい。支払サービス・システムは、取引を容易にし、取引に関連する返済条件を決定してもよい。返済条件は、両方のユーザの取引履歴に基づいて決定されてもよい。支払サービス・システムは、取引に関連する返済条件を決定するために、両方のユーザの取引履歴に適用される機械学習モデルを使用してもよい。支払サービス・システムは、それぞれが取引に適格であるかどうかを判定するために、両方のユーザの取引履歴を分析してもよい。例として、支払サービス・システムは、ユーザが金額を借りた後に返済できるかどうかを判定してもよい。支払サービス・システムはまた、貸し手が、ユーザに金銭を融資するために利用可能な資金を有しうるかどうかを判定してもよい。ユーザの両方は、返済条件を修正してもよく、各ユーザは、最終的な返済条件を承諾するように要求されてもよい。ユーザは、ユーザから金銭を借りるために別のユーザにオファーを延長してもよい。
これは、貸し手がオファーを延長しているので、借り手の適格性の判定を無視してもよい。特定の実施形態では、支払サービス・システムは、ユーザが別のユーザから金額を借りることを要求するための最適な時間を決定してもよい。例として、限定されるものではないが、ユーザが別のユーザから金銭を要求しようとするならば、支払サービス・システムは、潜在的な貸し手が要求者のために十分な資金を有しているかどうかを判定してもよい。支払サービス・システムは、潜在的な貸し手がその時点で十分な資金を有していないと判定するかもしれないが、通常はその月のある日に支払われ、後日に要求するようにユーザに通知する。特定の実施形態では、ユーザ間の取引履歴に依存して、支払サービス・システムは、いつ要求すべきかの特定の詳細をユーザに通知してもよい。例として、限定されるものではないが、２人のユーザが互いに頻繁に金銭を支払い、要求する（例えば、強い関係を示す）ならば、支払サービス・システムは、潜在的な貸し手が典型的には月末まで支払われないことを要求者に通知してもよい。しかし、２人のユーザが２人の間で頻繁な取引を有していないならば、支払サービス・システムは、現在が潜在的な貸し手から金銭を借りる要求を要求する最良の時間ではないこと、及び／又は単にこの要求を拒否することをユーザに示してもよい。

特定の実施形態では、返済条件は、受取キャッシュから減算するための設定されたパーセンテージ又は金額を含んでもよい。一例として、限定されるものではないが、設定された条件について毎週（例えば、毎週金曜日に＄２０）の金額を支払う代わりに、ユーザは取引、ローンなどを返済するために、（オプションがユーザに対して有効にされているならば）受取金額のパーセンテージを引き落とすように選択してもよい。例えば、ユーザが＄１００を借りることを決定し、受取金銭のパーセンテージを通して支払うことを選択するならば、金銭がユーザに送られるときはいつでも、ローンが返済されるまで、借りた金銭を返済するために、パーセンテージ（例えば、金銭の１０％）が取り出される。特定の実施形態では、設定されたパーセンテージを選択するオプションは、取引履歴、返済履歴、及び他のパラメータに基づいてユーザに提供されてもよい。特定の実施形態では、ローンの返済は、毎週設定された金額（例えば、毎週＄２０）から、受取金銭の設定されたパーセンテージ（例えば、金銭がユーザの口座に入るごとに５％）に切り替わるように更新された返済条件を有してもよい。ユーザは、ユーザが適格であると支払サービス・システムが判定した後に、支払サービス・システムによってオファーされてもよい。例として、限定されるものではないが、ユーザは、ユーザが自分の仕事を失った場合に切り替えることを要求してもよく、支払サービス・システムは、ユーザが適格であると判定してもよい。返済を必要とする１つ以上の取引は、支払サービス・システムによる適格性の判定に基づいて返済条件を切り替えてもよい。特定の実施形態では、ユーザが別のユーザから借りているならば、潜在的な貸し手はオプションをオファーしてもよく、及び／又は借り手は、受取金銭のパーセンテージを通じて潜在的な貸し手に返済を要求してもよい。

特定の実施形態では、支払サービス・システムは、それぞれが独自の返済条件を有する複数の取引を統合してもよい。例として、限定されるものではないが、ユーザが異なる返済条件を有する２つの取引を有するならば、支払サービス・システムは、ユーザが１つの取引を返済するだけでよいように、２つの取引を組み合わせてもよい。支払サービス・システムは、統合された取引について新しい返済条件を算出してもよい。特定の実施形態では、ユーザは、それぞれが個別の返済条件を有する２つ以上の取引を統合することを要求してもよい。特定の実施形態では、２つ以上の取引が同じ返済条件を有する（例えば、デフォルト返済条件を有する）ならば、２つ以上の取引がデフォルトにより組み合わされてもよい。特定の実施形態では、イベントが複数の取引の統合をトリガしてもよい。支払サービス・システムがイベントを検出した場合に、イベントは、承諾のためにユーザに提示される新しい返済条件を有する２つ以上の取引の統合をトリガしてもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザが第三者（例えば、銀行）を通じて収入が増加し、所与の期間により多くの負債を支払うことができることを検出してもよい。ユーザが業者であるならば、イベントは、新しい従業員が業者の給与に追加されたこと、又は過去の傾向と比較した販売活動の増加であってもよい。イベントに応答して、支払サービス・システムは、新しい統合された取引オファーを生成してもよく、統合された取引オファーは、返済が必要な２つ以上の取引を新しい返済条件と組み合わせる。統合された取引オファーは、受け入れられるようにユーザに提示されてもよい。ユーザからの承諾があると（例えば、ユーザが統合された取引オファーを受け入れると）、支払サービス・システムは、新しい統合された取引オファーを示すために、ユーザ口座を更新してもよい。統合された取引オファーは、検出されたイベントに基づいて変化する返済条件を有してもよい。例として、限定されるものではないが、ユーザが今月増加したキャッシュ・フローを有すること（例えば、ユーザが多額の金銭を預金すること）を支払サービス・システムが検出したならば、支払サービス・システムは、複数の取引をより速く支払うことをユーザに促すために、より好ましい条件（例えば、短縮された返済スケジュールを有する低減された金利）で返済されるべき複数の取引を統合するために、統合された取引オファーを生成してもよい。

特定の実施形態では、支払サービス・システムは、スケジュールされた返済をユーザに思い出させるために、ユーザのコンピューティング・デバイスを通じてユーザへ通知を送信してもよい。ユーザは、ユーザの残高の自動的なスケジュールされた引き落としをオプト・イン又はオプト・アウトしてもよい。特定の実施形態では、ユーザの残高の自動的なスケジュールされた引き落としをオプト・イン又はオプト・アウトするユーザの能力は、ユーザのリスク・レベルに基づいてもよい。例として、限定されるものではないが、ユーザが高リスクのユーザとして分類されるならば、支払サービス・システム１０８は、ユーザの残高の自動的なスケジュールされた引き落としをユーザが選択することを抑制する。

特定の実施形態では、タスクを実行するように明示的にプログラムされることなく予測又は決定を行うために、「訓練データ」として知られるサンプル・データの数学的モデルを構築するために機械学習アルゴリズムが使用されてもよい。特定の実施形態では、コンピューティング・システム（例えば、支払サービス・システムに関連するコンピューティング・システム）は、取引データ分析の効率及び有効性を向上するために、機械学習モデルを利用してもよい。取引データ分析は、以前の取引、ユーザの取引履歴、特定のカテゴリの取引などのような、任意の適切な取引データの分析を含んでもよい。さらに、これらの機械学習モデルは、各取引に関連するリスクのレベルを決定するために、ユーザ・プロファイル、ユーザ返済履歴、取引プロファイル特性を分析してもよい。機械学習モデルは、それぞれがそれ自体の対応するユーザ・プロファイル、ユーザ返済履歴、及び取引プロファイル特性を有する複数の取引例について訓練されてもよい。例として、限定されるものではないが、機械学習モデルは、ユーザ・プロファイルのリスク・レベルを識別するように訓練されてもよい。例えば、負債を予定通り又は事前に支払い、負債を支払うための実質的な残高を有する人は、低リスクのユーザ・プロファイルとして分類されてもよい。したがって、この特定のユーザが行う任意の取引は一般に、低リスクとして分類されうる。機械学習モデルは、ユーザが負債を返済する際に従うための１つ以上の柔軟な返済スケジュールを決定してもよい。

特定の実施形態では、機械学習モデルは、教師ありでも、半教師ありでも、教師なしでもよい。機械学習モデルは、回帰学習、強化学習、決定木、ランダム・フォレスト、サポート・ベクトル・マシン、ニューラル・ネットワーク、又は任意の適切な学習アルゴリズムに基づいてもよい。特定の実施形態では、コンピューティング・システムは、取引データ分析のためにニューラル・ネットワーク・ベースの機械学習モデルを使用してもよい。例として、限定されるものではないが、ニューラル・ネットワーク・ベースのモデルは、畳み込みニューラル・ネットワーク、ロング・ショート・ターム・メモリ・ユニット、又は再帰ニューラル・ネットワーク、又はそれらの任意の組合せのうちの１つ以上を含んでもよい。

ニューラル・ネットワークは、互いにメッセージを交換する相互接続された人工「ニューロン」のシステムである。これらの接続は、訓練プロセス中に調整される数値の重みを有し、適切に訓練されたネットワークは、認識すべき画像又はパターンで提示された場合に正しく応答するようになる。ネットワークは、特徴検出「ニューロン」の複数の層からなる。各層は、前の層からの入力の異なる組み合わせに応答する多くのニューロンを有する。ネットワークの訓練は、意図された出力応答に関連する代表的な入力パターンの広範な種類の入力の「ラベル付けされた」データセットを使用して実行される。訓練は、中間特徴ニューロン及び最終特徴ニューロンの重みを反復的に決定するために、汎用方法を使用する。計算モデルに関して、各ニューロンは、入力と重みとの内積を計算し、バイアスを加算し、（例えば、シグモイド応答機能を使用して）非線形トリガ関数を適用する。
ディープ・ニューラル・ネットワーク（ＤＮＮ）は、いくつかの応用分野において著しい改善を示している。

特定の実装の形態では、支払サービス・システムは、ユーザが取引に関連する負債を返済するための最適な返済条件を決定することによって、取引についての返済条件を動的に生成する実装を通じて、ネットワーク速度を増加させ、ネットワーク全体の帯域幅を増加させてもよい。機械学習モデルを使用してユーザが負債を返済するための最適な返済条件を決定することによって、支払サービス・システムは、拒否された後にローンに再適用されるユーザの量を減少させる。さらに、支払サービス・システムは、負債の返済を最適化するために機械学習モデルを使用することによって、負債の返済に不履行を起こすユーザの量を減らす。これにより、不履行になっているユーザから支払いを収集するために必要なリソースの量を減らすことができる。支払サービス・システムは、取引に対応するユーザ及び業者の残高をインテリジェントに調整するためにデータ構造を使用することによって、分散システムを強化することを通じて消費されるネットワーク帯域幅を低減してもよい。例として、限定されるものではないが、ユーザは、負債手段を使用する取引の自動返済をスケジュールするようにオプト・インしてもよく、支払サービス・システムは、生成された返済条件に基づいてユーザの残高を調整してもよい。特定の実施形態では、返済されるべき複数の取引の統合が、複数の取引を１つの統合された取引に結合することにより、取引を管理するために使用されるリソースの量を減少させてもよい。支払サービス・システムは、取引を統合した結果として、複数の取引とは対照的に１つの取引を処理する必要があってもよい（例えば、複数の取引のための複数回で異なる時刻ではなく、ユーザ口座からの資金を単一の時刻に振り替える）。

本書に開示される実施形態は単なる例であり、この開示の範囲はこれらに限定されない。特定の実施形態は、上記に開示された実施形態の構成要素、要素、特徴、機能、動作、又はステップのすべてを含んでもよく、一部を含んでもよく、何も含まなくてもよい。方法、記憶媒体、システム、及びコンピュータ・プログラム商品を対象とする添付の特許請求の範囲に開示される実施形態であって、１つの請求項カテゴリ、例えば方法で言及される任意の特徴は、別の請求項カテゴリ、例えばシステムでも請求されてもよい。添付の特許請求の範囲における従属関係又は参照は、形式的な理由のみのために選択される。しかし、特許請求の範囲及びその特徴の任意の組合せが開示され、添付の特許請求の範囲で選択される従属にかかわらず請求されうるように、任意の先行の請求項（特にマルチ従属）への意図的な参照から生じる任意の主題も同様に請求されうる。請求されうる主題は、添付の特許請求の範囲に記載される特徴の組合せだけでなく、特許請求の範囲における特徴の任意の他の組合せも含み、特許請求の範囲において言及される各特徴は、特許請求の範囲における任意の他の特徴又は他の特徴の組合せと組合せられてもよい。さらに、本書に記載され又は図示された実施形態及び特徴のいずれも、別個の請求項において、及び／又は本書に記載又は図示された任意の実施形態又は特徴との任意の組合せにおいて、又は添付の請求項の特徴のいずれかとともに、請求されてもよい。

図１Ａは、例示的な支払サービス・システム・ネットワーク環境１００を示す。業者１０２は、業者１０２によって提供されたアイテム１０６について顧客１０４（又は「ユーザ１０４」）と取引を行ってもよい。図１Ａはまた、顧客１０４の支払手段を許可するために、ネットワーク１１０－１を介して業者ポイント・オブ・セールス（ＰＯＳ）デバイス１０５及び顧客デバイス１０３に結合された支払サービス・システム１０８（「支払サービス」とも呼ばれる）を説明する。

顧客１０４は、アイテム（例えば、業者１０２によって提供される商品又はサービス）１０６を購入するために業者１０２との取引に従事してもよい。顧客１０４は、１１２に示すように、現金又は他の任意の種類の支払手段を、業者１０２によって提供されるアイテムを求める要求とともに業者１０２に提供してもよい。

業者１０２は、顧客１０４からの支払いを受け入れるためにＰＯＳデバイス１０５を利用してもよい。ＰＯＳデバイス１０５は、デバイス上で実行される業者アプリケーションのインスタンスを含む任意の種類のモバイル・デバイス又は非モバイル・デバイスを備えてもよい。業者アプリケーションは、業者１０２（例えば、所有者、従業員など）が顧客１０４からの支払いを受け入れることを可能にするために、ＰＯＳ機能をＰＯＳデバイス１０５に提供してもよい。いくつかのタイプのビジネスでは、ＰＯＳデバイス１０５は、業者の店又は他のビジネスの場所に対応してもよく、したがって、通常、日々変化しない固定位置であってもよい。しかし、他のタイプのビジネスでは、ＰＯＳデバイス１０５の位置は、業者が食品トラックを運営する場合、路上販売者である場合、タクシー・ドライバーである場合など、又は別様にモバイル・ビジネスを有する場合、例えば、購入者の家庭、ビジネスの場所などでアイテムを販売する業者の場合など、時々変化してもよい。

本書で使用されるように、業者は、顧客による取得のための商品又はサービスの提供に従事する任意のビジネスを含んでもよい。業者に起因する動作は、業者の所有者、従業員、又は他のエージェントによって実行される動作を含んでもよく、よって、特に説明しない限り、本書では区別を行わない。さらに、本書で使用されるように、顧客は、購入、レンタル、リース、借用、ライセンス供与などによって、業者から商品又はサービスを取得する任意のエンティティを含んでもよい。以下、業者によって提供される商品及び／又はサービスは、アイテム、例えばアイテム１０６と称されてもよい。よって、業者及び顧客は、顧客が業者１０２からアイテム１０６を取得する取引を実行するために互いに対話してもよく、その見返りとして、顧客１０４は、支払い１１２を業者１０２に提供する。

本書で使用されるように、取引は、顧客１０４と業者１０２との間で行われるアイテムの取得のための金融取引を含んでもよい。例えば、取引について支払う場合に、顧客１０４は、現金又は他の支払手段１１２（例えば、デビット・カード、クレジット・カード、ストアド・バリュー又はギフト・カード、小切手、顧客が携帯するデバイス１０３上の電子支払アプリケーション１０７を介して、など）を使用して、業者に支払われるべき金額を提供してもよい。業者は、支払手段１１２に関連する識別子を（例えば、手動で、磁気カード・リーダ、ＮＦＣリーダ、又はＲＦＩＤリーダなどを介して）入力することなどによって、取引を処理するためにＰＯＳデバイス１０５と対話してもよい。例えば、顧客の支払手段は、カード・リーダに通された場合にカード及び顧客情報を提供するための１つ以上の磁気ストリップを有するカードを含んでもよい。他の例では、ユーロペイ、マスターカード、Ｖｉｓａ（ＥＭＶ）規格、すなわちＥＭＶカードに準拠するチップのような、カードがリーダに挿入された場合にデバイスによって読み取られる内蔵メモリ・チップを有するスマート・カードのような、他のタイプの支払手段が使用されてもよい。他の例では、他のタイプの支払手段は、高周波識別タグのような高周波を介して通信するカード又はコンピューティング・デバイス、及び近距離通信デバイスなどを含む。他の例では、他のタイプの支払手段は、クレジット・カード又はクレジット・ラインなどの負債手段を含んでもよい。

取引中に、ＰＯＳデバイス１０５は、支払手段の識別子、顧客から受け取った支払いの金額、顧客によって取得されたアイテム、取引の時刻、場所及び日付、支払手段に関連する支払ネットワーク１４０、支払手段の発行銀行、顧客の名前又はユーザ口座、顧客の連絡先情報、通貨の種類などのような、取引を記述する取引情報を決定してもよい。ＰＯＳデバイス１０５は、取引の実行と実質的に同時に（オンライン取引の場合）、又は後に（オフライン取引の場合のように）ＰＯＳデバイス１０５がオンライン・モードにある場合に、ネットワーク１１０－１を介して支払サービス・システム１０８へ取引情報を送信してもよい。特定の実施形態では、取引情報は、取引の購入特性を含んでもよい。

オフライン取引では、ＰＯＳデバイス１０５は、取引のコスト、取引が行われた時刻、取引が行われた曜日、取引が行われた場所、顧客が取得したアイテム、顧客のアイデンティティ及び／又は連絡先情報、並びに取引で使用される支払手段のような、取引に関連する１つ以上の特性（すなわち、取引情報）を記憶してもよい。顧客１０４とオフライン取引を行った後、ＰＯＳデバイス１０５は、記憶された情報（又はその何らかの部分集合）をネットワーク１１０－１を介して支払サービス・システム１０８に提供してもよい。ネットワーク１１０－１は、Ｗｉ－Ｆｉネットワーク、セルラ・ネットワークなどのような任意の１つ以上の有線又は無線ネットワークを表してもよい。オンライン取引では、ＰＯＳデバイス１０５は、顧客との取引と実質的に同時に、ネットワーク１１０－１を介してこの情報を支払サービス・システム１０８へ送信してもよい。

業者１０２が顧客１０４から支払情報を受信した後、業者１０２は、１１４に示されるように、個別の取引に関する情報とともに、個別の承諾要求を支払サービス・システム１０８へ送信してもよい。支払サービス・システム１０８は、支払処理サービス１２６、業者プロファイル１３０、及び顧客プロファイル１３２を含んでもよい。ここで、業者プロファイル１３０は、支払サービス・システム１０８を使用する１以上の業者に関する情報を含んでもよい。顧客プロファイル１３２は、支払サービス・システム１０８を使用する１以上の顧客に関する情報を含んでもよい。そうでなければ、各業者又は顧客は、支払サービス・システム１０８のユーザと呼ばれてもよい。特定のユーザは、業者、顧客、又はユースケースに応じたいずれかであってもよい。

支払処理サービス１２６は、業者１０２のＰＯＳデバイス１０５から取引に関する情報を受信し、取引を実行するために使用される支払手段を承諾しようと試みてもよい。その後、支払処理サービス１２６は、１１６に示されるように、支払手段が承諾されたか拒否されたかのインジケーションをＰＯＳデバイス１０５へ返信してもよい。

顧客及び業者が電子支払取引を開始する場合に、取引は、顧客に関連する金融口座から業者に関連する金融口座へ資金を電子的に移転することによって処理されてもよい。したがって、支払処理サービス１２６は、金融取引を電子的に行うために、支払カード・ネットワーク１４０（又は「カード支払ネットワーク」）、例えば、マスターカード（登録商標）、ＶＩＳＡ（登録商標）の１つ以上のコンピューティング・デバイスと、ネットワーク１１０－２を介して通信してもよい。支払処理サービス１２６は、ネットワーク１１０－２を介して、１つ以上の銀行の１つ以上のコンピューティング・デバイス、処理／取得サービスなどとも通信してもよい。例えば、支払処理サービス１２６は、取得銀行、及び／又は発行銀行、及び／又は電子支払のための顧客口座を維持する銀行と通信してもよい。支払処理サービス１２６はまた、支払サービス・システム１０８によって維持される顧客口座及び業者口座と通信するか、又はそれらにアクセスしてもよい。

取得銀行は、カード協会の登録会員（例えば、Ｖｉｓａ（登録商標）、マスターカード（登録商標））であってもよく、カード支払ネットワーク１４０の一部であってもよい。発行銀行は、買い手にクレジット・カードを発行してもよく、発行銀行が支払カードを発行したカード所有者によって行われた購入について、取得銀行に支払いを行ってもよい。したがって、いくつかの例では、取得銀行のコンピューティング・デバイスは、カード支払ネットワークに含まれてもよく、支払いを取得するためにカード発行銀行のコンピューティング・デバイスと通信してもよい。さらに、いくつかの例では、顧客は、クレジット・カードの代わりにデビット・カードを使用してもよく、その場合、デビット・カードに対応する銀行の銀行コンピューティング・デバイスは、顧客が参加している取引に関する通信を受信してもよい。さらに、いくつかのタイプの取引又は代替システム・アーキテクチャに関与する他の金融機関のコンピューティング・デバイスが存在してもよく、したがって、上記は、説明の目的のためのいくつかの例にすぎない。

暗号通貨を伴う取引では、支払サービス・システム１０８は、ネットワークを介して１つ以上の暗号通貨ネットワークと通信してもよい。このようなネットワークは例えば、ビットコイン・ネットワーク、イーサリアム・ネットワーク等を含んでもよい。暗号通貨ネットワークは、取引を暗号的に検証及び認証して、一般にブロック・チェーンと呼ばれる分散型台帳のコピー上に取引を記録する当事者のネットワークに関連する。取引が認証されると、暗号通貨ネットワークは、取引をブロック・チェーンに書き込むことによって取引を承認してもよい。このようなプロセスが完了するまでの時間は、多くの用途では実用的でないほど長くなりうる。

ネットワーク１１０－１、１１０－２は、Ｗｉ－Ｆｉネットワーク、セルラ・ネットワーク、ワイド・エリア・ネットワーク、ローカル・エリア・ネットワークなどのような、任意の１つ以上の有線又は無線ネットワークを表してもよい。説明のために、ネットワーク１１０－１、１１０－２は、別々のネットワークとして示されている。特定の実施形態では、ネットワーク１１０－１、１１０－２は同じネットワーク、同じネットワークのサブネット、１以上の別々のネットワーク、又は他の適切な構成であってもよい。

図１Ａは支払手段を承諾することの要求の一部として、取引データを支払サービス・システム１０８へ業者１０２が直接送信することを示すが、いくつかの例では、他のエンティティ（例えば、業者に関連する銀行又は顧客支払手段に関連する銀行）がバッチ式の定期的なプロセスの一部のような取引データを提供してもよい。

顧客プロファイル１３２はユーザ嗜好のインジケーションを記憶してもよいが、業者プロファイル１３０は業者１０２の個別のプロファイルに関連する情報を記憶してもよい。例えば、業者プロファイル１３０は、個別の業者によって提供されるアイテム（例えば、コーヒー・アイテム、収集品、アパレルなど）のクラス又はカテゴリ、業者のビジネスのタイプ（例えば、レストラン、コーヒー・ショップ、小売店など）、業者の地理的位置などを示してもよい。

いくつかの例では、業者に関連するコンピューティング・デバイス（例えば、ＰＯＳデバイス１０５、業者のサーバなど）は、顧客が物理的な施設又は業者のデジタル存在をいつ訪れたかを決定してもよい。例えば、顧客１０４のデバイス１０３は、近距離通信方法（例えば、Ｂｌｕｅｔｏｏｔｈなど）を介して業者１０２のＰＯＳデバイス１０５と通信するアプリケーション１０７（例えば、支払サービス・システム１０８によって提供されるアプリケーション）を含んでもよい。したがって、顧客が業者１０２の物理的な施設を訪れた場合に、例えば、ＰＯＳデバイス１０５は、顧客デバイス１０３の存在を検出してもよい。これに応じて、ＰＯＳデバイスは、顧客が存在すると判定してもよい。別の例では、ＰＯＳデバイス１０５及び顧客デバイス１０３の一方又は両方は、デバイスが互いに閾値近接範囲内にいつ位置したかを判定し、顧客デバイス１０３とＰＯＳデバイス１０５との間の取引を仲介するために、その位置（例えば、ＧＰＳ座標）を共通サービスに共有してもよい。

別の例では、顧客１０４は、業者の位置で「チェックイン」するために顧客デバイス１０３を利用してもよく、ＰＯＳデバイス１０５は、このチェックインのインジケーションを受信してもよい。顧客が業者１０２のデジタル存在（例えば、ウェブサイトなど）を訪れた場合に、顧客１０４は、ログインするか、又は他の方法で、顧客が業者にいると業者が判定する情報（例えば、デバイス１０３上のクッキー）を提供してもよい。もちろん、いくつかの例が列挙されているが、業者及び／又は支払サービス・システム１０８が、顧客が業者にいつ存在するかを、任意の他の複数の方法で決定してもよいことを理解されたい。各インスタンスにおいて、顧客１０４が業者１０２に位置するというインジケーションを支払サービス・システム１０８が受信した後、支払サービス・システム１０８は、顧客の１つ以上の以前に表現されたアイテム嗜好を業者へ送信するかどうかを判定してもよい。

さらに、顧客１０４は、支払サービス・システム１０８から、モバイル・ウォレット・アプリケーションのような支払アプリケーション１０７のインスタンスを受信することを望むかもしれない。図１Ａは、１１８において、顧客１０４が支払サービス・システム１０８へ支払アプリケーション要求を送ってもよいことを示す。これに応答して、１２０において、支払サービス・システム１０８は、アプリケーション１０７のインスタンスを顧客デバイス１０３へ返信してもよい。さらに、支払サービス・システム１０８は、アプリケーション１０７のインスタンスの識別情報を顧客プロファイルにマッピングしてもよい。

本主題の１つの実施形態によれば、顧客及び業者は、アイテム又は選択されたアイテムの集合を購入するために、支払サービス・システムを介して担保資産の支払いを送受信してもよい。別の実装形態では、顧客は、支払サービス・システムを介して担保資産の支払いを送信してもよく、支払サービス・システムは、担保資産を業者の選択の別の資産に変換する。別の実施態様では、顧客は、販売からの収入の一部又は全部を業者との請求書の清算にするという明示的な目的で、販売される特定の担保資産を指定してもよい。

図１Ｂは、例示的な環境１００の別の実施形態を示す。図１Ｂは、図１Ｂにおいて、取引が第１ユーザ１５０の操作デバイス１５２と第２ユーザ１５４の操作デバイス１５６との間であることを除いて、例示的な環境１００の実施形態と同じ構成要素の多くを含む。他のすべての構成要素について、少なくとも図１Ａに関する上記の説明が適用される。デバイス１５２及び１５６は、それぞれ、支払サービス・システム１０８によって提供されるアプリケーション１５３及び１５７が実行されるコンピューティング・デバイスであってもよい。いくつかの実施形態では、アプリケーション１５３及び１５７のうちの１つ以上は、ポイント・オブ・セールス・アプリケーションであってもよい。いくつかの実施形態では、アプリケーション１５３及び１５７のうちの１つ以上は、モバイル・ウォレット・アプリケーションであってもよい。いくつかの実施形態では、アプリケーション１５３及び１５７のうちの１つ以上は、少なくとも１つの支払口座にアクセスできる第三者によって提供されるアプリケーションであってもよい。

図１Ｂは、本技術が本書で説明される革新を使用して、任意の登場人物の任意の当事者（業者、ユーザ、銀行など）から任意の登場人物の任意の他の当事者へ通貨又は資産が送られてもよいことを企図する、より広い概念を示す。

具体的に、業者とユーザとの間の対話又は取引として説明した例のいずれも、２人のユーザ１５０と１５４との間で実行されてもよい。本主題の１つの実施形態によれば、ユーザ１５０及び１５４は、アイテム又は選択されたアイテムの集合を購入するために、支払サービス・システム１０８を介して担保資産内の支払いを送受信してもよい。別の実装形態では、ユーザ１５０は、支払サービス・システム１０８を介して担保資産の支払いを送信してもよく、支払サービス・システム１０８は、第１ユーザ１５０からの担保資産を第２ユーザ１５４の選択の別の資産に変換する。別の実施態様では、第１ユーザ１５０は、販売からの収入の一部又は全部を第２ユーザ１５４との請求書の精算にするという明示的な目的で、販売される特定の担保資産を指定してもよい。別の実施態様では、第１ユーザ１５０は、販売からの収入の一部又は全部を支払サービス・システムを介して第２ユーザ１５４へのローンの提供にするという明示的な目的で、販売される特定の担保資産を指定してもよい。この実施態様では、第１ユーザ１５０は、要求された返済形式（例えば、特定の通貨、同じ担保資産、１つ以上の他の指定された担保資産、任意の他の担保資産、又は異なる担保資産の混合、担保資産のタイプ、又は担保資産及び通貨での返済）を指定してもよい。第２ユーザ１５４は、支払サービスを通じて第１ユーザ１５０によって提供されたローンを返済してもよい。支払サービス・システム１０８は、第２ユーザ１５４によって提供される支払オプション（例えば、通貨又は担保資産の指定金額）を、指定された担保要求形式の返済に自動的に変換することによって、要求された形式の返済の履行を容易にしてもよい。支払サービス・システムは、様々な当事者のコンピューティング・システムが取引を承諾し処理するのに必要な通信及び処理時間を短縮することによって、支払オプション、より迅速かつ正確に完了される取引のより拡張的なアレイを可能にし、取引を準備し要求するためにユーザが関与しなければならない対話及びインタフェースを単純化する。総合すると、これらの改善は、以前の支払処理システム及び関連するデバイスに対する全体的な改善に相当する。したがって、支払サービス・システムは、以前のデバイスに勝る著しい技術的利点及び改良を含む。

図２は、支払サービス・システム１０８のための例示的なシステム・アーキテクチャを示す。特定の実施形態では、支払サービス・システム１０８は、複数の顧客のそれぞれについて顧客プロファイル１３２を記憶してもよい。顧客プロファイル１３２は、顧客識別情報（名前、連絡先情報、人口統計データなど）、顧客１０４による支払サービス・システム１０８を伴う過去の取引の記録を含む取引ログ２０２、リンクされた口座に関する情報（クレジット・カード情報、銀行口座情報など）、顧客プロファイル１３２によって利用されるサービスに関する情報（例えば、モバイル・ウォレット・アプリケーション）を含んでもよい顧客データ２０１を含んでもよい。顧客データ２０１は、ユーザの１つ以上の社会的連絡先又はピア・ツー・ピア連絡先（例えば、友人、家族、オンライン・ネットワーク接続）に関連する情報をさらに含んでもよい。情報は、このような連絡先のプロファイル情報の少なくとも一部を含んでもよい。

顧客プロファイル１３２はまた、顧客１０４に代わって支払サービス・システム１０８によって管理される任意の口座の台帳を含んでもよい。支払サービス・システム１０８によって管理される口座を顧客が有することは、処理速度の向上及びセキュリティの改善という技術的利点を可能にする技術の態様であることが理解されるだろう。例えば、顧客プロファイル１３２は、通貨台帳２０３を含んでもよい。通貨台帳２０３は、顧客が所有する１つ以上の通貨（例えば、米ドル、ユーロ、ビットコイン）のそれぞれの残高を記憶してもよい。通貨台帳は、それぞれが顧客によって所有される通貨を含む、ユーザの１つ以上の別々の口座に関する情報を含んでもよい。支払サービス・システム１３２はまた、ユーザに代わって１つ以上の通貨口座２０４を管理又は維持してもよい。通貨口座２０４は、顧客の使用のために割り当てられる、支払サービス・システム１０８によって保持される通貨の論理分割を含んでもよい。顧客プロファイル１３２はまた、負債台帳２０５を含んでもよい。負債台帳２０５は顧、客が所有する１つ以上の負債手段（例えば、クレジット・カード、クレジット・ライン、ローン）のそれぞれの残高を記憶してもよい。負債台帳は、それぞれがユーザによって所有される負債手段を含む、ユーザの１つ以上の別々の負債口座２０６に関する情報を含んでもよい。支払サービス・システム１０８、又は支払サービス・システム１０８に代わって動作する１つ以上の第三者は、ユーザのために負債口座２０６を管理し、維持してもよい。負債口座２０６は、顧客の使用のために割り当てられる、支払サービス・システム１０８によって保持される負債手段の論理分割を含んでもよい。通貨台帳２０３及び負債台帳２０５は、任意の適切なデータ構造を利用してもよい。例として、限定されるものではないが、顧客によって所有される各個々の資産又は負債についての情報を記録するために、別々の台帳が使用されてもよい。特定の顧客に関連する様々な台帳はすべて一緒に、グループで、又は別々に格納されてもよい。別の例として、限定されるものではないが、通貨台帳２０３及び負債台帳２０５は、論理台帳であってもよい。関連する台帳はすべて、単一のファイル、データ集合、又はデータベースに保存されてもよい。言い換えれば、複数のタイプの資産（例えば、フィアット通貨、暗号通貨、担保資産）に対する顧客の所有権はすべて複合台帳に記録されてもよいし、複数の台帳に別々に記録されてもよい。

各口座台帳（２０３、２０５）は、顧客１０４が口座（２０４、２０６）から資金を出す又は引き出す場合に、プラスの残高又はマイナスの残高を反映してもよい。口座は、外部口座から口座に関連する形式で通貨を移転することによって（例えば、ある金額の現金を支払サービス・システム１０８に移転し、その価値を通貨台帳２０３の残高として貸方に記入することによって）、又は異なる形式の通貨を使用して支払サービス・システム１０８から口座に関連する形式で通貨を購入することによって、又は口座が受取通貨を受け取る支払サービス・システム１０８の別のユーザ（顧客又は業者）との取引を行うことによって、資金を供給されてもよい。口座は、負債手段にアクセスすることの要求を受信することによって資金を供給されてもよい。顧客が支払サービス・システム１０８から負債手段にアクセスすることを要求した場合に、支払サービス・システム１０８は、通貨口座２０４又は通貨台帳２０３に記憶された残高を借方記入し、負債口座２０６又は負債台帳２０５に記憶された残高を貸方記入してもよい。

同様に、図１Ａ及び図１Ｂに関して紹介したように、支払サービス・システム１０８は、業者プロファイル１３４を記憶してもよい。業者プロファイル１３４は、業者データ２０７、取引ログ２０８、通貨台帳２０９、通貨口座２１０、負債台帳２１１、及び負債口座２１２を含んでもよい。業者データ２０７は、業者が支払いとして受け取ることを好む通貨又は資産のタイプのような、業者１０２に関連する１つ以上の嗜好設定を含んでもよい。業者プロファイル１３４に記憶された情報は、ＰＯＳデバイス１０５又は業者１０２に関連する他の適切なデバイスを通じて業者１０２によってアクセス可能にされ、管理されてもよい。顧客プロファイル１３２及びそれに含まれる情報（例えば、顧客データ２０１、取引ログ２０２、通貨台帳２０３、通貨口座２０４、負債台帳２０５、及び負債口座２０６）に関して説明される保守及び管理動作を含む動作は、業者プロファイル１３４及びそれに含まれる情報（例えば、業者データ２０７、取引ログ２０８、通貨台帳２０９、通貨口座２１０、負債台帳２１１、及び負債口座２１２）にも同様に適用可能である。

支払サービス・システム１０８は、支払サービス・システム１０８によって保持される現金又は他の通貨の金額を記録する通貨台帳２１３を維持してもよい。支払サービス・システムによって保持される現金又は他の通貨の金額は例えば、１つ以上の通貨口座２１４に保持されてもよい。支払サービス・システムは、支払サービス・システム１０８によって保持される負債手段の金額を記録する負債台帳２１５を維持してもよい。支払サービス・システム１０８によって保持される負債手段の金額は例えば、１つ以上の負債口座２１６に保持されてもよい。通貨台帳２１３及び負債台帳２１５はまた、支払サービス・システム１０８の１以上のユーザによって所有される支払サービス・システム１０８によって所有される資産の部分（例えば、通貨口座２１４及び負債口座２１６を通じて）及び支払サービス・システム１０８によって所有される資産の部分を指定してもよい。支払サービス・システム１０８がそれ自体の負債手段の債権を有する場合に、顧客は、支払サービス・システム１０８から直接負債手段へのアクセスを要求してもよい。

２人のユーザ（例えば、ユーザ１５０及び１５４）が資産の移転を伴う取引に従事する場合に、このような取引は、各顧客のプロファイル１３２に関連する台帳に反映されてもよい。例として、限定されるものではないが、第１ユーザ１５０は、ある金額の通貨資産を第２ユーザ１５４に移転してもよい。これに応じて、支払サービス・システム１０８は、第１ユーザ１５０の通貨台帳２０３（及び対応する通貨口座２０４）を借方記入し、第２ユーザ１５４の通貨台帳２０３（及び対応する通貨口座２０４）を貸方記入してもよい。

さらに、顧客１０４はまた、支払サービス・システム１０８に登録された１つ以上の外部支払カードを有してもよい。外部支払カードは、外部銀行口座２２２に関連付けられてもよい。外部支払カード口座は、支払サービス・システム１０８によって管理されなくてもよい。その代わりに、支払カードで行われる取引を、適切な外部支払ネットワーク２２４が処理してもよい。

さらに、顧客１０４は、支払サービス・システム１０８に登録された１つ以上の内部支払カードを有してもよい。内部支払カードは、顧客プロファイル１３２に関連するすべての口座にリンクされてもよい。いくつかの実施形態では、顧客デバイス１０３にインストールされた支払アプリケーション１０７を使用して、内部支払カードに関するオプションが調整及び管理されてもよい。例えば、顧客プロファイル１３２が複数の支払口座（例えば、暗号通貨、フィアット通貨、及び負債手段）を含む場合に、アプリケーション１０７は、内部支払カードを使用する際に、これらの口座のうちの１つを、借方又は貸方のデフォルト口座に設定してもよい。

顧客１０４は、顧客デバイス１０３にインストールされたアプリケーション１０７を通じて、支払サービス・システム１０８、通貨台帳２０３、通貨口座２０４、負債台帳２０５、及び負債口座２０６に登録された支払カードを含む顧客プロファイル１３２にアクセスし、監視してもよい。アプリケーション１０７は、支払サービス・システム１０８によって提供される、又は支払サービス・システム１０８によって提供される１つ以上のＡＰＩを使用することによって顧客プロファイル１３２にアクセスするように構成される、顧客対面アプリケーションであってもよい。いくつかの実施形態では、顧客デバイス１０３上のアプリケーション１０７は、支払方法を記憶すること、及びアプリケーション１０７の命令で顧客デバイス１０３による電子支払いを許可することを含むデジタル・ウォレット機能を提供してもよい。

支払サービス・システム１０８は、通貨口座に関するユーザ設定を受信してもよい。例えば、ユーザは、通貨口座の残高限度を設定してもよい。残高限度は、通貨口座に対する必要残高であってもよい。

図３Ａ～図３Ｂは、取引について返済条件を生成するためのプロセスにおける、支払サービス・システム３２０及びユーザ・デバイス３１０を含む様々なアクター間の対話を説明する。図３Ａを見ると、プロセスは一般に、プロセスのステップを表すブロックが図の上部から下方に進むにつれて進み、その結果、矢印がブロックを接続しない場合であっても、第２ブロック（例えば、ステップ３２３のブロック）の上の第１ブロック（例えば、ステップ３１２のブロック）が一般に、プロセスにおいて先に発生する。プロセスは、ステップ３２１で始まってもよく、このステップでは、支払サービス・システム３２０は、ユーザ口座に関連するデフォルト返済条件を生成してもよい。支払サービス・システム３２０は、ユーザの取引履歴を分析し、ユーザの資金が不足していると判定し、ユーザがクレジット・ラインを必要としうると判定してもよい。ステップ３２２において、支払サービス・システム３２０は、ユーザがアクセスするために利用可能な初期クレジット・ラインをユーザへ送信してもよい。ユーザ・デバイス３１０は、デフォルト返済条件を有するクレジット・ラインへのアクセスを受信してもよい。ユーザ・デバイス３１０は、アプリケーションにおいてユーザにクレジット・ラインを表示してもよい。ステップ３１２において、ユーザ・デバイス３１０は、取引について支払いを行うために、負債手段にアクセスすることの要求を受信してもよい。例えば、ユーザは、負債手段にアクセスすることの要求をアプリケーションに入力してもよい。別の例として、ユーザは、取引について支払いを行うために、支払カード（すなわち、負債手段）を使用してもよい。ユーザ・デバイス３１０は、ステップ３１３において、要求を支払サービス・システム３２０へ送信してもよい。支払サービス・システム３２０が要求を受信した後、ステップ３２３において、支払サービス・システム３２０は、取引の購入特性を識別してもよい。特定の実施形態では、支払サービス・システム３２０は、取引明細から購入特性を抽出し、又は業者に購入特性を要求してもよい。支払サービス・システム３２０が購入特性を抽出した後、支払サービス・システム３２０は、ステップ３２４において、購入特性に基づいて、修正された返済条件について取引が適格であるかどうかを判定してもよい。ステップ３２５において、取引が適格でないならば、プロセスはステップ３１４に進んでもよく、そこで、ユーザ・デバイス３１０は、ユーザ承諾のためにデフォルトの返済条件を提示する。ステップ３２５において、取引が適格であるならば、プロセスは図３Ｂのステップ３２６に進み、支払サービス・システム３２０は、要求に関連する返済条件を生成するために、識別された購入特性に適用される機械学習モデルを使用してもよい。例えば、支払サービス・システム３２０は、購入特性に基づいて取引に関連する金利を決定してもよい。ステップ３２７において、支払サービス・システム３２０は、返済条件の承諾のために、返済条件をユーザ・デバイス３１０へ送信してもよい。ユーザ・デバイス３１０が返済条件を受信した後、ステップ３１５において、ユーザ・デバイス３１０は、ユーザ承諾のために返済条件を提示する。ステップ３１６において、ユーザ・デバイス３１０が許諾を受信するか拒否を受信するかの判定が行われてもよい。ユーザが返済条件を拒否したならば、プロセスはステップ３２８に進み、ユーザ・デバイス３１０は、ユーザ拒否を介して支払サービス・システム３２０へ送信し、支払サービス・システム３２０は、取引について支払いを行うために、負債手段にアクセスすることの要求を拒否してもよい。ユーザが返済条件を承認することによって返済条件を許諾したならば、プロセスはステップ３２９に進み、ユーザ・デバイス３１０は、ユーザ承認を介して支払サービス・システム３２０へ送信し、支払サービス・システム３２０は、返済条件とともに取引を含むように、ユーザ・デバイス３１０に関連するユーザ口座を更新してもよい。これは、取引に関連する決定された手数料と、ユーザが負債の返済を滞納しているならば残余量に課される金利とを有する返済スケジュールを確立することを含んでもよい。プロセスはさらに、全体を通して説明したように、ユーザ・デバイス及び支払サービス・システムのために、顕著な新たな対話を可能にする。

図４Ａ～図４Ｂは、支払カードを使用する取引について返済条件を生成するプロセスにおける、支払サービス・システム４２０、ユーザ・デバイス４１０、及び業者デバイス４３０を含む様々なアクター間の対話を説明する。図４Ａを見ると、プロセスは一般に、プロセスのステップを表すブロックが図の上部から下方に進むにつれて進み、その結果、矢印がブロックを接続しない場合であっても、第２ブロック（例えば、ステップ４２２のブロック）の上の第１ブロック（例えば、ステップ４３１のブロック）が一般に、プロセスにおいて先に発生する。プロセスはステップ４３１で始まり、業者デバイス４３０は、支払カードを用いた取引について支払いを行うことの要求を受信してもよい。その後、ステップ４３２において、業者デバイス４３０は、取引について支払うための資金を移転することの要求と、取引に関連する取引明細とを送信してもよい。資金を移転することの要求は、取引で使用される支払カードに関連してもよい。ステップ４２１において、支払サービス・システム４２０は、支払カードに関連するユーザ口座を識別してもよい。支払サービス・システム４２０は、取引の購入特性を識別してもよい。特定の実施形態では、支払サービス・システム４２０は、取引明細から購入特性を抽出し、又は業者に購入特性を要求する。支払サービス・システム４２０が購入特性を抽出した後、支払サービス・システム４２０は、ステップ４２３において、購入特性に基づいて、修正された返済条件に取引が適格であるかどうかを判定してもよい。ステップ４２４において、取引が適格でないならば、プロセスはステップ４１１に進んでもよく、ユーザ・デバイス４１０は、ユーザ承諾のためにデフォルト返済条件を提示する。ステップ４２４において、取引が適格であるならば、プロセスは図４Ｂのステップ４２５に進み、支払サービス・システム４２０は、要求に関連する返済条件を生成するために、識別された購入特性に適用される機械学習モデルを使用してもよい。例えば、支払サービス・システム４２０は、購入特性に基づいて取引に関連する金利を決定してもよい。ステップ４２６において、支払サービス・システム４２０は、返済条件の承諾のために、返済条件をユーザ・デバイス４１０へ送信してもよい。ユーザ・デバイス４１０が返済条件を受信した後、ステップ４１２において、ユーザ・デバイス４１０は、ユーザ承諾のために返済条件を提示する。ステップ４１３において、ユーザ・デバイス４１０が承諾を受信するか、拒否を受信するかの判定が行われてもよい。ユーザが返済条件を拒否したならば、プロセスはステップ４２７に進み、ユーザ・デバイス４１０は、ユーザ拒否を介して支払サービス・システム４２０に送信し、支払サービス・システム４２０は、支払カードを使用する取引にについて支払いを行うためにアクセスすることの要求を拒否してもよい。支払サービス・システム４２０が要求を拒否した後、支払サービス・システム４２０は、拒否を業者デバイスへ送信してもよく、ステップ４３３において、業者デバイス４３０は、取引について支払うための資金を移転することの要求を拒否してもよい。ユーザが返済条件を承認することによって返済条件を承諾したならば、プロセスはステップ４２８に進み、ユーザ・デバイス４１０は、ユーザ承諾を介して支払サービス・システム４２０へ送信し、支払サービス・システム４２０は、返済条件とともに取引を含むように、ユーザ・デバイス４１０に関連するユーザ口座を更新してもよい。ユーザ口座が更新された後、ステップ４３４において、業者デバイス４３０は、取引について支払うために、業者への資金の移転を受け取ってもよい。これは、取引に関連する決定された手数料と、ユーザが負債の返済を滞納しているならば残余量に課される金利とを有する返済スケジュールを確立することを含んでもよい。プロセスはさらに、ユーザ・デバイス、支払サービス・システム、及び業者デバイスが全体を通して説明したように、顕著な新たな対話を可能にする。

図５Ａ～５Ｂは、クレジット・ラインにアクセスするための返済条件を生成するプロセスにおける、支払サービス・システム５２０及びユーザ・デバイス５１０を含む様々なアクター間の対話を説明する。図５Ａを見ると、プロセスは一般に、プロセスのステップを表すブロックが図の上部から下方に進むにつれて進み、その結果、矢印がブロックを接続しない場合であっても、第２ブロック（例えば、ステップ５２２のブロック）の上の第１ブロック（例えば、ステップ５１１のブロック）が一般に、プロセスにおいて先に発生する。プロセスはステップ５１１で始まってもよく、ユーザ・デバイス５１０は、ユーザ口座に関連するクレジット・ラインからのキャッシュ・アドバンスを求める要求を受信してもよい。その後、ステップ５１２において、ユーザ・デバイス５１０は、支払サービス・システム５２０へキャッシュ・アドバンスの要求を送信してもよい。ステップ５２１において、支払サービス・システム５２０は、ユーザ口座の取引履歴及び取引の取引特性を識別してもよい。支払サービス・システム５２０が取引履歴及び取引特性を識別した後、支払サービス・システム５２０は、ステップ５２２において、取引履歴及び取引特性に基づいて、修正された返済条件に取引が適格であるかどうかを判定してもよい。ステップ５２３において、取引が適格でないならば、プロセスはステップ５１３に進んでもよく、ユーザ・デバイス５１０は、ユーザ承諾のためのデフォルト返済条件を提示する。ステップ５１３において、取引が適格であるならば、プロセスはステップ５２４に進み、支払サービス・システム５２０は、要求に関連する返済条件を生成するために、識別された情報に適用される機械学習モデルを使用してもよい。例えば、支払サービス・システム５２０は、取引履歴及び取引特性に基づいて取引に関連する金利を決定してもよい。ステップ５２５において、支払サービス・システム５２０は、返済条件の承諾のために、返済条件をユーザ・デバイス５１０へ送信してもよい。ユーザ・デバイス５１０が返済条件を受信した後、ステップ５１４において、ユーザ・デバイス５１０は、ユーザ承諾のために返済条件を提示する。図５Ｂのステップ５１５において、ユーザ・デバイス５１０が承諾を受信するか拒否を受信するかの判定が行われてもよい。ユーザが返済条件を拒否したならば、プロセスはステップ５２６に進み、ユーザ・デバイス５１０は、ユーザ拒否を介して支払サービス・システム５２０へ送信し、支払サービス・システム５２０は、クレジット・ラインからのキャッシュ・アドバンスを求める要求を拒否してもよい。ユーザが返済条件を承認することによって返済条件を承諾したならば、プロセスはステップ５２７に進み、ユーザ・デバイス５１０は、ユーザ承諾を介して支払サービス・システム５２０へ送信し、支払サービス・システム５２０は、返済条件とともに取引を含むように、ユーザ・デバイス５１０に関連するユーザ口座を更新してもよい。これは、取引に関連する決定された手数料と、ユーザが負債の返済を滞納しているならば残余量に課される金利とを有する返済スケジュールを確立することを含んでもよい。このプロセスはさらに、全体を通して説明したように、ユーザ・デバイス及び支払サービス・システムのために、顕著な新たな対話を可能にする。

図６Ａ～図６Ｃは、別のユーザから借りるための返済条件を生成するためのプロセスにおける、支払サービス・システム６２０、第１ユーザ・デバイス６１０、及び第２ユーザ・デバイス６３０を含む、様々なアクター間の対話を説明する。図６Ａを見ると、プロセスは一般に、プロセスのステップを表すブロックが図の上部から下方に進むにつれて進み、その結果、矢印がブロックを接続しない場合であっても、第２ブロック（例えば、ステップ６２２のブロック）の上の第１ブロック（例えば、ステップ６１１のブロック）が一般に、プロセスにおいて先に発生する。プロセスはステップ５１１で始まってもよく、第１ユーザ・デバイス６１０は、第２ユーザから金額を借りることの要求を受信してもよい。その後、ステップ６１２において、第１ユーザ・デバイス６１０は、支払サービス・システム６２０に金額を借りることの要求を送信してもよい。ステップ６２１において、支払サービス・システム６２０は、第１ユーザに関連するユーザ口座の取引履歴を識別してもよい。支払サービス・システム６２０が取引履歴を識別した後、支払サービス・システム６２０は、ステップ６２２において、要求された金額を借りるのに第１ユーザが適格であるかどうかを判定するために、取引履歴に適用される機械学習モデルを使用してもよい。ステップ６２３において、第１ユーザが適格でないならば、プロセスはステップ６１３に進み、第１ユーザ・デバイス６１０は、金額を借りることの要求の拒否を受信する。ステップ６２３において、第１ユーザが適格であるならば、プロセスはステップ６２４に進んでもよく、支払サービス・システム６２０は、第２ユーザに関連するユーザ口座及び取引履歴を識別してもよい。図６Ｂのステップ６２５で、支払サービス・システムは、要求された金額を貸すのに第２ユースが適格であるかどうかを判定するために、第２ユーザの取引履歴に適用される機械学習モデルを使用してもよい。ステップ６２６において、第２ユーザが適格でないならば、プロセスはステップ６１４に進み、第１ユーザ・デバイス６１０は、金額を借りることの要求の拒否を受信する。ステップ６２６において、第２ユーザが適格であるならば、プロセスはステップ６２７に進み、支払サービス・システム６２０は、修正された返済条件を生成するために、第１ユーザ及び第２ユーザの両方の取引履歴に適用される機械学習モデルを使用する。図６Ｃのステップ６２８において、支払サービス・システム６２０は、承諾のために、修正された返済条件を第２ユーザへ送信してもよい。ステップ６３１において、第２ユーザ・デバイス６３０が承諾を受信するか、又は拒否を受信するかの判定が行われてもよい。第２ユーザが返済条件を拒否したならば、プロセスはステップ６２９に進み、第２ユーザ・デバイス６３０は、ユーザ拒否を介して支払サービス・システム６２０へ送信し、支払サービス・システム６２０は、第２ユーザから金額を借りることの要求を拒否してもよい。第２ユーザが返済条件を承認することによって返済条件を承諾したならば、プロセスはステップ６４１に進み、第２ユーザ・デバイス６３０は、ユーザ承諾を介して支払サービス・システム６２０へ送信し、支払サービス・システム６２０は、返済条件を有する取引を含むことができるように、第１ユーザ・デバイス６１０及び第２ユーザ・デバイス６３０に関連するユーザ口座を更新してもよい。これは、取引に関連する決定された手数料と、第１ユーザが負債の返済を滞納しているならば残余量に課される金利とを有する返済スケジュールを確立することを含んでもよい。このプロセスはさらに、第１ユーザ・デバイス、第２ユーザ・デバイス、及び支払サービス・システムは、全体を通して説明されるように、顕著な新たな対話を可能にする。

図７Ａ～７Ｃは、プロセス７００のための例示的なユーザ・インタフェース及び支払カードを使用することに関連する返済条件を生成するプロセス７００を説明する。例示的なモバイル・アプリケーションを使用してユーザが負債を支払うことを可能にするために、軽微な修正を伴う同様のインタフェースが使用されてもよい。図７Ａでは、ユーザは、取引のために業者のＰＯＳデバイス７０２で支払カード７０４を使用してもよい。ＰＯＳデバイス７０２は、事前に取引明細を有し、ユーザからの支払いを待ってもよい。モバイル・アプリケーション７０８は、ユーザが負債手段にアクセスし、管理するための機能を提供してもよい。負債手段は、クレジット・カード、クレジット・ライン、又はローンを含んでもよい。図７Ｂに示すように、このような機能は、ユーザ・デバイス７０６上で実行されるモバイル・アプリケーション７０８のユーザ・インタフェース７１０において提供されてもよい。ユーザ・インタフェース７１０は、ユーザが取引について支払うために支払カード７０４を使用することに応答して現れる画面を表してもよい。ユーザ・インタフェース７１０は、モバイル・アプリケーション７０８のホーム画面を表す別のユーザ・インタフェース上のオーバレイであってもよい。他の実施形態では、ユーザ・インタフェース７１０は、ホーム画面とは異なる別個の画面を開いてもよい。支払サービス・システムは、ユーザが取引の金利を課されることを抑制する返済計画を決定してもよい。特定の実施形態では、支払サービス・システムは、ユーザの取引履歴、収入及びキャッシュ・フローに基づいて、ユーザにとって最良に機能しうる複数の返済スケジュール７１２を決定してもよい。ユーザ・インタフェース７１０は、返済スケジュール７１２ｂのような他の返済スケジュール７１２の中でもとりわけ、提案された返済スケジュール７１２ａと、支払カードを使用する支払いを確認するインタフェースにユーザを導く「確認」ボタン７１４とを備えてもよい。図７Ｂに示すように、ユーザは、ユーザ入力７１６を通じて「確認」ボタン７１４を選択してもよい。特定の実施形態では、第１返済スケジュール７１２ａが選択され、他の返済スケジュール７１２と区別されてもよい。例として、限定されるものではないが、第１返済スケジュール７１２ａは現在選択されている返済スケジュール７１２ａを示すように強調表示されてもよい。特定の実施形態では、ユーザがスクロールして所望の返済スケジュール７１２を選択する複数の返済スケジュール７１２が存在してもよい。

図７Ｃに示すユーザ・インタフェース７１８は、ユーザがユーザ入力７１６を通じて「確認」ボタン７Ｂを選択した結果を示す。他の実施形態では、アプリケーション７０８はまた、ユーザが「確認」ボタン７１４を選択した後に、クレジット・ラインにアクセスすることの要求の詳細を含む確認ページを概要形式で表示してもよい。ユーザ・インタフェース７１８は、第１支払いの確認日７２０と、最近の取引を含む更新された取引履歴を示すホーム画面にユーザを戻すように指示する「完了」ボタン７２２とを含んでもよい。

図８Ａ～図８Ｅは、支払サービス・システムに関連する例示的なのモバイル・アプリケーション８０２を使用してクレジット・ラインにアクセスするプロセス８００のための例示的なユーザ・インタフェースを示しており、このモバイル・アプリケーションはユーザ・デバイス８０１上で実行される。例示的なモバイル・アプリケーション８０２を使用してユーザが負債を支払うことを可能にするために、軽微な修正を伴う同様のインタフェースが使用されてもよい（例えば、クレジット・ラインにアクセスすることに関するグラフィックを、クレジット・ラインに関連する負債を支払うことに関するグラフィックで置き換える）。モバイル・アプリケーション８０２は、ユーザが負債手段にアクセスし、管理するための機能を提供してもよい。負債手段は、クレジット・カード、クレジット・ライン、又はローンを含んでもよい。図８Ａに示されるように、このような機能は、ユーザ・インタフェース８０３に提供されてもよう。ユーザ・インタフェース８０３は、モバイル・アプリケーション８０２のホーム画面を表してもよい。ユーザ・インタフェース８０３は、現在利用可能な資金の金額を表示するユーザ口座に関連する残高８０４（例えば、＄３２５）と、残高８０４に追加資金を追加するためのインタフェースにユーザを導く「入金」ボタン８０５と、残高８０４から資金を引き出すためのインタフェースにユーザを導く「出金」ボタン８０６とを備えてもよい。ユーザ・インタフェース８０３は、１つ以上のフィアット通貨及び１つ以上の金融口座を管理するためのインタフェースにユーザを導く「現金」ボタン８０８と、ユーザ口座に関連するクレジット・ラインにアクセスするためのインタフェースにユーザを導く「クレジット・ライン」ボタン８１０とを備えてもよい。図８Ａに示されるように、ユーザは、ユーザ入力８１２を通じて「クレジット・ライン」ボタン８１０を選択してもよい。

図８Ｂに示されるユーザ・インタフェース８１４は、ユーザ入力８１２を通じてユーザが「クレジット・ライン」ボタン８１０を選択した結果を説明する。ユーザ・インタフェース８１４は、利用可能なクレジット・ライン額８１６、クレジット・ラインからどれだけ借りられるかのインジケーション８１８、現在アクセスするクレジット・ラインの一部を選択するためのインタフェースにユーザを導く「すぐに借りる」ボタン８２０、後日アクセスするクレジット・ラインの一部を選択するためのインタフェースにユーザを導く「後で」ボタン８２２、及びユーザ口座のクレジット・ラインに関連する詳細を提供する詳細セクション８２４を含んでもよい。図８Ｂに示されるように、ユーザは、ユーザ入力８２６を通じて「すぐに借りる」ボタン８２０を選択してもよい。

図８Ｃに示されるユーザ・インタフェース８２８は、ユーザ入力８２６を通じて「すぐに借りる」ボタン８２０をユーザが選択した結果を示す。ユーザ・インタフェース８２８は、ユーザ・インタフェース８１４の上のオーバレイであってもよい。他の実施形態では、ユーザ・インタフェース８２８は、ユーザ・インタフェース８１４とは異なる別個の画面を開いてもよい。ユーザ・インタフェース８２８は、ユーザが借りたいクレジット・ラインの分量を示す金額８３０と、クレジット・ラインのどれくらいの分量をユーザが借りたいかを示すボタン８３４を有するスライダ要素８３２と、取引の返済スケジュールを決定するためのインタフェースにユーザを導く「次へ」ボタン８３６とを含んでもよい。特定の実施形態では、支払サービス・システム１０８は、取引のインジケーションを受信し、ユーザが借りたいかもしれない金額８３０を自動的に決定してもよい。インジケーションは、取引について支払カードに請求することの要求に応答して、又は図８Ａ及び８Ｂを迂回する取引の結果として受信されてもよい。図８Ｃに示されるように、ユーザは、ユーザ入力８３８を通じて「次へ」ボタン８３６を選択してもよい。

図８Ｄに示されるユーザ・インタフェース８４０は、ユーザがユーザ入力８３８を通じて「次へ」ボタン８３６を選択した結果を示す。ユーザ・インタフェース８４０は、ユーザ・インタフェース８１４の上のオーバレイであってもよい。他の実施形態では、ユーザ・インタフェース８４０は、ユーザ・インタフェース８１４とは異なる別個の画面を開いてもよい。支払サービス・システム１０８は、ユーザが取引について金利を課されることを抑制する返済計画を決定してもよい。特定の実施形態では、支払サービス・システム１０８は、ユーザの取引履歴、収入及びキャッシュ・フローに基づいて、ユーザにとって最良に機能する複数の返済スケジュールを決定してもよい。ユーザ・インタフェース８４０は、返済スケジュール８４２ｂのような他の返済スケジュール８４２の中でもとりわけ、提案された返済スケジュール８４２ａと、クレジット・ラインからユーザの残高に資金を移転することの要求を確認するインタフェースにユーザを導く「確認」ボタン８４４とを備えてもよい。図８Ｄに示されるように、ユーザは、ユーザ入力８４６を通じて「確認」ボタン８４４を選択してもよい。特定の実施形態では、第１返済スケジュール８４２ａが選択され、他の返済スケジュール８４２と区別されてもよい。例として、限定されるものではないが、第１返済スケジュール８４２ａは現在選択されている返済スケジュール８４２ａを示すように強調表示されてもよい。特定の実施形態では、ユーザがスクロールして所望の返済スケジュール８４２を選択する複数の返済スケジュール８４２が存在してもよい。

図８Ｅに示されるユーザ・インタフェース８４８は、ユーザがユーザ入力８４６を通じて「確認」ボタン８４４を選択した結果を示す。他の実施形態では、アプリケーション８０２は、ユーザが「確認」ボタン８４４を選択した後に、クレジット・ラインにアクセスすることの要求の詳細を構成する確認ページを要約形式で表示してもよい。ユーザ・インタフェース８４８は、第１支払いの確認日８５０と、クレジット・ラインから残高８０４への移送を含む更新された残高８０４を示すユーザ・インタフェース８０３にユーザを戻す「完了」ボタン８５２とを含んでもよい。

図９Ａ～図９Ｆは、ユーザ・デバイス９０２上で実行される例示的なモバイル・アプリケーション９０４を使用して、別のユーザから資金を借りることを要求するプロセス９００の例示的なユーザ・インタフェースを説明し、モバイル・アプリケーション９０４は、支払サービス・システムに関連する。例示的なモバイル・アプリケーション９０４を使用してユーザが負債を支払うことを可能にするために、軽微な修正を伴う同様のインタフェースが使用されてもよい。モバイル・アプリケーション９０４は、ユーザが負債手段にアクセスし、管理するための機能を提供してもよい。負債手段は、クレジット・カード、クレジット・ライン、又はローンを含んでもよい。図９Ａに示されるように、このような機能は、ユーザ・インタフェース９０５に提供されてもよい。ユーザ・インタフェース９０５は、モバイル・アプリケーション９０４のホーム画面を表してもよい。特定の実施形態では、ユーザ・インタフェース９０５は、モバイル・アプリケーション９０４のホーム画面から、友人から借りるオプションを選択した後のユーザ・インタフェースを表してもよい。特定の実施形態では、支払サービス・システムは、ユーザが借りることを要求することを希望する提案されるユーザを識別してもよい。例として、限定されるものではないが、支払サービス・システムは、ユーザと他のユーザとの間の対話に基づいて、提案されるユーザを決定してもよい。例えば、ユーザが頻繁に特定のユーザへ金銭を送信し、当該ユーザから金銭を要求するならば、この特定のユーザは、提案されるユーザ・リストに追加されてもよい。ユーザ・インタフェース９０５は、ユーザが友人であるか、又は以前に取引したユーザのリストを含んでもよい。ユーザのリストは、支払サービス・システムの特定のユーザ口座に対応する１つ以上のボタン９０６ａ～９０６ｄを含む。ボタン９０６のそれぞれは、個別のユーザから金額を借りることを要求するためのインタフェースにユーザを導いてもよい。図９Ａに示されるように、ユーザは、ユーザ入力９０８を通じて「デニス・ミルズ」ボタン９０６ｂを選択してもよい。

図９Ｂに示されるユーザ・インタフェース９１０は、ユーザ入力９０８を通じてユーザが「デニス・ミルズ」ボタン９０６ｂを選択した結果を示す。ユーザ・インタフェース９１０は、ユーザ・インタフェース９０５の上にオーバレイであってもよい。他の実施形態では、ユーザ・インタフェース９１０は、ユーザ・インタフェース９０５とは異なる別個の画面を開いてもよい。ユーザ・インタフェース９１０は、ユーザが借りたい金額の分量を示す金額９１２と、どれくらいの金額をユーザが借りたいかを示すボタン９１６を有するスライダ要素９１４と、取引について返済スケジュールを決定するためのインタフェースにユーザを導く「次へ」ボタン９１８とを含んでもよい。特定の実施形態では、支払サービス・システムは、取引のインジケーションを受信し、ユーザが借りたい金額９１２を自動的に決定してもよい。インジケーションは、取引について支払カードに課されることの要求に応答して、又は図９Ａを迂回する取引の結果として受信されてもよい。特定の実施形態では、ユーザが借りたい金額は、図９Ａに示されるユーザ・インタフェース９０５に含まれてもよい。例として、限定としてではなく、ユーザは、借りるユーザを選択する前に、ユーザ・インタフェース９０５上で金額を入力できる。図９Ｂに示されるように、ユーザは、ユーザ入力９２０を通じて「次へ」ボタン９１８を選択してもよい。

図９Ｃに示されるユーザ・インタフェース９２２は、ユーザ入力９２０を通じてユーザが「次へ」ボタン９１８を選択した結果を示す。ユーザ・インタフェース９２２は、ユーザ・インタフェース９０５の上のオーバレイであってもよい。他の実施形態では、ユーザ・インタフェース９２２は、ユーザ・インタフェース９０５とは異なる別個の画面を開いてもよい。支払サービス・システムは、ユーザが取引について金利を課されることを抑制する返済計画を決定してもよい。特定の実施形態では、支払サービス・システムは、ユーザの取引履歴、収入、及びキャッシュ・フローに基づいて、ユーザにとって最良に機能する複数の返済スケジュールを決定してもよい。ユーザ・インタフェース９２２は、返済スケジュール９２４ｂのような他の返済スケジュール９２４の中でもとりわけ、提案された返済スケジュール９２４ａと、クレジット・ラインからユーザの残高に資金を移転することの要求を確認するインタフェースにユーザを導く「確認」ボタン９２６とを備えてもよい。図９Ｃに示されるように、ユーザは、ユーザ入力９２８を通じて「確認」ボタン９２６を選択してもよい。特定の実施形態では、第１返済スケジュール９２４ａが選択され、他の返済スケジュール９２４と区別されてもよい。例として、限定されるものではないが、第１返済スケジュール９２４ａは、現在選択されている返済スケジュール９２４ａを示すように強調表示されてもよい。特定の実施形態では、ユーザがスクロールして所望の返済スケジュール９２４を選択する複数の返済スケジュール９２４が存在してもよい。

図９Ｄに示されるユーザ・インタフェース９３０は、ユーザ入力９２８を通じてユーザが「確認」ボタン９２６を選択した結果を示す。他の実施形態では、アプリケーション９０４は、ユーザが「確認」ボタン９２６を選択した後に、クレジット・ラインにアクセスすることの要求の詳細を含む確認ページを概要形式で表示してもよい。ユーザ・インタフェース９３０は、第１支払いの確認日９３２と、借りた金額からユーザ残高への移転を含むユーザ口座の更新された残高を示すホーム画面に関連するユーザ・インタフェースにユーザを導く「完了」ボタン９３４とを備えてもよい。

図９Ｅに示されるユーザ・インタフェース９３６は、貸し手から借りた金銭を返済するために、ユーザが後日受け取ってもよい例示的なリマインダを示す。特定の実施形態では、ユーザは、貸し手から金銭を借りることを要求する間にリマインダをセットアップしてもよい。ユーザは、借りた金額を返済するために、将来リマインダを受け取る頻度及び／又は時期を選択してもよい。例として、限定されるものではないが、ユーザは、予定された返済日の３日前にリマインドされ、予定された返済日に支払うべき金額をユーザが支払うまで毎日リマインドされることを選択してもよい。したがって、ユーザが金曜日に予定された返済日を有するならば、ユーザは、その週に支払われるべき金額を支払うように火曜日にリマインドされてもよい。ユーザ・インタフェース９３６は、リマインダ９３８を含んでもよい。ユーザ・インタフェース９３６は、ユーザ・デバイス９０２のホーム画面であってもよい。他の実施形態では、リマインダ９３８は、ユーザ・デバイスの他のユーザ・インタフェースにおいて通知として表示されてもよい。例として、限定するものではなく、リマインダ９３８は、ユーザがユーザ・デバイス９０２と対話している間のポップアップ通知であってもよい。図９Ｅに示されるように、ユーザは、ユーザ入力９４０を通じてリマインダ９３８を選択してもよい。

図９Ｆに示されるユーザ・インタフェースは、ユーザ入力９４０を通じてユーザがリマインダ９３８を選択した結果を示す。特定の実施形態では、リマインダ９３８の選択は、モバイル・アプリケーション９０４をユーザ・インタフェース９４２に開いてもよい。ユーザ・インタフェース９４２は、最近の取引、完了した取引、係属中の取引、今後の取引などのような、モバイル・アプリケーション９０４内のユーザの最近の活動を表示してもよい。特定の実施形態では、ユーザ・インタフェース９４２は、今後の取引９４４を含み、それらをユーザのために列挙してもよい。支払サービス・システムのデータベースに記憶されたユーザに関連する１つ以上の口座記録に基づいて、支払サービス・システムは、今後の取引９４４に関して動作が完了される必要があるかどうかを判定してもよく、動作を完了するためにモバイル・アプリケーション９０４上に対話型ボタン９４６を生成するようにユーザ・デバイス９０２に命令を提供してもよい。例として、限定されるものではないが、今後の取引９４４は返済期限であってもよく、「返済」ボタン９４６は、取引を返済するためにユーザ・インタフェースにユーザがアクセスすることを可能にするために、今後の取引９４４にリンクされてもよい。「返済」ボタン９４６は、次の支払い（例えば、週に支払われる金額）を単に支払うための、及び／又は借りた金額よりも多くを支払うように修正するためのインタフェースにユーザを導いてもよい。ユーザ・インタフェース９４２は、取引を詳述するインタフェースにユーザを導く完了した取引９４８ａ、取引を詳述するインタフェースにユーザを導く完了した取引９４８ｂのような、完了した取引９４８に対する対話型ボタンを備えてもよい。

図１０Ａ～図１０Ｃは、ユーザ・デバイス１００２上で実行される例示的なモバイル・アプリケーション１００４を使用して、別のユーザから資金を借りることの要求を承認するプロセス１０００の例示的なユーザ・インタフェースを示し、モバイル・アプリケーション１００４は、支払サービス・システムに関連する。ユーザが例示的なモバイル・アプリケーション１００４を使用して負債を支払うことを可能にするために、軽微な修正を伴う同様のインタフェースが使用されてもよい。モバイル・アプリケーション１００４は、ユーザが負債手段にアクセスし、管理するための機能を提供してもよい。負債手段は、クレジット・カード、クレジット・ライン、又はローンを含んでもよい。図１０Ａに示されるように、このような機能は、ユーザ・インタフェース１００６に提供されてもよい。ユーザ・インタフェース１００６は、モバイル・アプリケーション１００４の活動画面を表してもよい。ユーザ・インタフェース１００６は、最近の取引、完了した取引、係属中の取引、今後の取引などのような、モバイル・アプリケーション１００４内のユーザの最近の活動を表示してもよい。ユーザ・インタフェース１００６は、係属中の取引１００８を含み、ユーザのためにそれらを列挙してもよい。支払サービス・システムは、係属中の取引１００８に関して動作を完了する必要があるかどうかを判定してもよく、動作を完了するためにモバイル・アプリケーション１００４上に対話型ボタン１０１０を生成するようにユーザ・デバイス１００２に命令を提供してもよい。支払サービス・システムは、動作を完了する必要があるかどうかの判定を行うために、支払サービス・システムのデータベースに記憶されたユーザに関連する１つ以上の口座記録を使用してもよい。例として、限定されるものではないが、係属中の取引１００８は、別のユーザから金銭を借りることの要求であってもよく、「貸す」ボタン１０１０は、ユーザが取引を承認するためにユーザ・インタフェースにアクセスすることを可能にするために係属中の取引１００８にリンクされてもよい。「貸す」ボタン１０１０は、金銭を借りることの要求を承認するため、及び／又は金銭を借りることの要求に対する１つ以上の返済条件を修正するためのインタフェースにユーザを導いてもよい。例として、限定されるものではないが、ユーザ・デバイス１００２に関連するユーザからユーザが金銭を借りたいならば、ユーザは、要求の詳細とともに、ユーザの係属中の取引１００８の下で要求を受信するだろう。ユーザ・インタフェース１００６は、取引を詳述するインタフェースにユーザを導く完了した取引１０１２ａと、取引を詳述するインタフェースにユーザを導く完了した取引１０１２ｂとのような、各完了した取引１０１２について対話型ボタンを備えてもよい。図１０Ａに示されるように、ユーザは、ユーザ入力１０１４を通じて「貸す」ボタン１０１０を選択してもよい。１つの実施形態によれば、貸し手ユーザは、資金を借りることの要求を承認すると（すなわち、「貸す」ボタン１０１０を選択することによって）、支払サービスは、要求ユーザの金融口座と貸し手ユーザの金融口座との間の取引の記録を記憶する。さらに、支払サービスは、借りることの要求の条件（例えば、期日、支払い金額）に関連するリマインダ通知を生成し、返済条件に基づいて２つの当事者の金融口座間の返済金額の取引処理を容易にしてもよい（例えば、ローン返済のための将来の受入支払いのパーセンテージを天引きすること、期日に処理される自動分割金額、図９Ｆの「返済」ボタンと対話するユーザなど）。

図１０Ｂに示されるユーザ・インタフェース１００６は、ユーザ入力１０１４を通じて「貸出」ボタン１０１０をユーザが選択した結果を示す。ユーザ・インタフェース１００６は、係属中の取引１００８を、完了した取引１０１２に変更するように、活動画面を更新してもよい。完了した取引１０１２は、最新の完了した取引１０１２が先に列挙されるように再順序付けされてもよい。図１０Ｂに示されるように、ユーザは、ユーザ入力１０１６を通じて、完了した取引１０１２ａを選択してもよい。

図１０Ｃに示されるユーザ・インタフェース１０１８は、ユーザ入力１０１６を通じて、完了した取引１０１２ａをユーザが選択した結果を示す。ユーザ・インタフェース１０１８は、完了した取引１０１２ａの詳細と、完了した取引１０１２ａの詳細を含むオーバレイ１０２０とを含んでもよい。オーバレイ１０２０はまた、ローン上の残高の残りを免除するためのインタフェースにユーザを導く「免除」ボタン１０２２と、モバイル・アプリケーション１００４のサポートに連絡するためのインタフェースにユーザを導く「サポート」ボタン１０２４とを備えてもよい。特定の実施形態では、「免除」ボタン１０２２は、借り手の今後の取引からローンを除去し、取引が完了し免除されたとしてマークする。

本書において、「又は」は特に指示がない限り、又は文脈によって他に指示がない限り、包括的であり、排他的ではない。したがって、本書では、「Ａ又はＢ」が別段の明示的な指示がない限り、又は文脈によって別段の指示がない限り、「Ａ、Ｂ、又はその両方」を意味する。さらに、「及び」は明確に別段の指示がない限り、又は文脈によって別段の指示がない限り、結合及び別々の両方である。したがって、本書では、「Ａ及びＢ」が別段の明示的な指示がない限り、又は文脈によって別段の指示がない限り、「Ａ及びＢ、一緒に又は別々に」を意味する。

本開示の範囲は、当業者が理解するのであろう、本書に記載又は図示された例示的な実施形態に対するすべての変更、置換、変形、変更、及び修正を包含する。本開示の範囲は、本書に記載又は図示された例示的な実施形態に限定されない。さらに、本開示は特定の構成要素、要素、特徴、機能、動作、又はステップを含むものとして本書でそれぞれの実施形態を説明及び例示するが、これらの実施形態のいずれも、当業者が理解するのであろう本書で説明又は例示される構成要素、要素、特徴、機能、動作、又はステップのいずれかの任意の組合せ又は置換を含んでもよい。さらに、添付の特許請求の範囲において、特定の機能を実行するように適合され、構成され、可能にされ、可能にされ、動作可能にされ、動作可能にされ、又は動作するように動作する装置又はシステム、あるいは装置又はシステムの構成要素への参照は、その装置、システム、構成要素、又はその特定の機能が起動され、オンにされ、又はロック解除されるかどうかにかかわらず、その装置、システム、構成要素を包含する。さらに、本開示は特定の利点を提供するものとして特定の実施形態を記載又は例示するが、特定の実施形態はこれらの利点のいずれも提供しないか、いくつか、又はすべてを提供しうる。

Claims (20)

1. 支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、
   前記ＰＳＳによって、ユーザについて承認されたクレジット・ラインから引き出されるキャッシュ・アドバンスを求める要求を受信することであって、前記クレジット・ラインは、前記ＰＳＳによって維持される口座に関連し、デフォルト返済条件に関連する、ことと、
   前記要求を受信したことに応答して、前記ＰＳＳによって、前記要求に関連する文脈特性を抽出することと、
   前記ＰＳＳによって、前記要求に関連するリスクのレベルを出力するために、前記抽出された文脈特性と、前記ＰＰＳに記憶された履歴文脈情報とが入力される機械学習モデルを使用して、前記要求されたキャッシュ・アドバンスについての返済条件を決定することであって、前記返済条件は、前記デフォルト返済条件とは異なり、リスクの前記レベルに基づく、ことと、
   前記決定に基づいて、前記キャッシュ・アドバンスに関連するように、修正された返済条件の集合を生成することと、
   前記ＰＳＳによって、前記修正された返済条件のインジケーションを、承諾のために前記ユーザのデバイスへ送信することと、
   前記ユーザから承諾のインジケーションを受信すると、前記ＰＳＳによって、前記要求されたキャッシュ・アドバンスを、前記修正された返済条件とともに含むように、前記クレジット・ラインを更新することと、を有する方法。
2. 請求項１に記載の方法であって、前記抽出された文脈特性は、前記要求に関連する日付と、前記要求に関連する時刻と、前記口座に関連する残高とのうちの１つ以上を含む、方法。
3. 請求項１に記載の方法であって、前記返済条件を生成することは、受取給与と、預金活動と、株又は証券に関連するキャッシュ・フローと、ピア・ツー・ピア取引とのうちの１つ以上に適用される前記機械学習モデルを使用することを含む、方法。
4. 請求項１に記載の方法であって、前記返済条件は、取引についての、支払期日と、返済スケジュールと、金利とのうちの１つ以上を含む、方法。
5. 支払サービス・システム（ＰＳＳ）に関連する１つ以上のコンピューティング・デバイスによって、
   前記ＰＳＳによって、ユーザのモバイル・デバイスから、金額について負債手段にアクセスすることの払戻要求を受信することであって、前記負債手段は、前記ＰＳＳによって維持される口座に関連する、ことと、
   前記払戻要求を受信したことに応答して、前記ＰＳＳによって、前記払戻要求の特性を抽出することと、
   前記ＰＳＳによって、前記払戻要求に関連するリスクのレベルを出力するために、前記抽出された特性が入力される機械学習モデルを使用して、前記払戻要求についての返済条件を決定することであって、前記返済条件は、リスクの前記レベルに基づく、ことと、
   前記ＰＳＳによって、承諾のために前記ユーザの前記モバイル・デバイスへ前記返済条件を送信することと、
   前記ユーザから承諾のインジケーションを受信すると、前記ＰＳＳによって、前記返済条件とともに前記金額を含むように、前記口座を更新することと、を有する方法。
6. 請求項５に記載の方法であって、前記口座は、各要求について動的返済条件を含むリボルビング口座である、方法。
7. 請求項５に記載の方法であって、
   前記口座は、第１返済率を有し、
   前記返済条件を生成することは、前記返済条件に基づいて前記第１返済率を第２返済率に修正することを含む、方法。
8. 請求項５に記載の方法であって、前記負債手段は、前記口座と確立されたクレジット・ラインであり、前記払戻要求は、前記払戻要求について前記クレジット・ラインの少なくとも一部を移転することの要求である、方法。
9. 請求項５に記載の方法であって、前記返済条件は、取引についての、支払期日と、返済スケジュールと、金利とのうちの１つ以上を含む、方法。
10. 請求項５に記載の方法であって、
    前記ＰＳＳによって、前記抽出された特性が入力される前記機械学習モデルを使用して、前記払戻要求に関連するように複数の返済条件を生成することであって、前記複数の返済条件のそれぞれは、異なる返済率を有する、ことをさらに有する、方法。
11. 請求項１０に記載の方法であって、
    前記ＰＰＳによって、前記ユーザのデバイスに関連するユーザ・インタフェース上に前記複数の返済条件を提示することの命令を提供することと、
    前記ＰＰＳによって、前記ユーザの前記デバイスから、前記複数の返済条件のうちの１つの選択を受信すると、前記選択された返済条件とともに前記金額を含むように、前記ユーザの口座を修正することと、をさらに有する方法。
12. 請求項５に記載の方法であって、前記返済条件を生成することは、受取給与と、預金活動と、株又は証券に関連するキャッシュ・フローと、ピア・ツー・ピア取引とのうちの１つ以上に適用される前記機械学習モデルを使用することを含む、方法。
13. 支払サービス・システムであって、
    １つ以上のプロセッサと、
    前記プロセッサのうちの１つ以上に結合され、前記プロセッサのうちの１つ以上によって実行された場合に、前記支払サービス・システム（ＰＳＳ）に、
    前記ＰＳＳによって、ユーザのモバイル・デバイスから、負債手段から金額を払い戻すことの要求を受信することであって、前記負債手段は、前記ＰＳＳによって維持される口座に関連する、ことと、
    前記要求を受信したことに応答して、前記ＰＳＳによって、前記要求の特性を抽出することと、
    前記ＰＳＳによって、前記要求に関連するリスクのレベルを出力するために、前記抽出された特性が入力される機械学習モデルを使用して、前記要求についての返済条件を決定することであって、前記返済条件は、リスクの前記レベルに基づく、ことと、
    前記ＰＳＳによって、承諾のために前記ユーザの前記モバイル・デバイスへ前記返済条件を送信することと、
    前記ユーザから承諾のインジケーションを受信すると、前記ＰＳＳによって維持されるデータストアにおいて、前記返済条件とともに前記金額を含むように、前記口座を更新することと、
    を行わせる命令を含む１つ以上のコンピュータ可読で非一時的な記憶媒体と、を備える支払サービス・システム。
14. 請求項１３に記載の支払サービス・システムであって、前記口座は、各要求について動的返済条件を含むリボルビング口座である、支払サービス・システム。
15. 請求項１３に記載の支払サービス・システムであって、
    前記口座は、第１返済率を有し、
    前記返済条件を生成することは、前記返済条件に基づいて前記第１返済率を第２返済率に修正することを含む、支払サービス・システム。
16. 請求項１３に記載の支払サービス・システムであって、前記負債手段は、前記口座と確立されたクレジット・ラインであり、前記要求は、前記要求について前記クレジット・ラインの少なくとも一部を移転することの要求である、支払サービス・システム。
17. 請求項１３に記載の支払サービス・システムであって、前記返済条件は、取引についての、支払期日と、返済スケジュールと、金利とのうちの１つ以上を含む、支払サービス・システム。
18. 請求項１３に記載の支払サービス・システムであって、前記１つ以上のプロセッサは、実行された場合に、前記ＰＳＳに、
    前記ＰＳＳによって、前記抽出された特性が入力される前記機械学習モデルを使用して、前記要求に関連するように複数の返済条件を生成することであって、前記複数の返済条件のそれぞれは、異なる返済率を有する、ことをさらに行わせるようにさらに動作可能である、支払サービス・システム。
19. 請求項１８に記載の支払サービス・システムであって、前記１つ以上のプロセッサは、実行された場合に、前記ＰＳＳに、
    前記ＰＰＳによって、前記ユーザのデバイスに関連するユーザ・インタフェース上に前記複数の返済条件を提示することの命令を提供することと、
    前記ＰＰＳによって、前記ユーザの前記デバイスから、前記複数の返済条件のうちの１つの選択を受信すると、前記選択された返済条件とともに前記金額を含むように、前記ユーザの口座を修正することと、をさらに行わせるようにさらに動作可能である、支払サービス・システム。
20. 請求項１３に記載の支払サービス・システムであって、前記返済条件を生成することは、受取給与と、預金活動と、株又は証券に関連するキャッシュ・フローと、ピア・ツー・ピア取引とのうちの１つ以上への前記機械学習モデルの適用を含む、支払サービス・システム。

Images