Method for future payment transactions

• US 7,818,229 B2
• Filed: 03/09/2006
• Issued: 10/19/2010
• Est. Priority Date: 10/19/2004
• Status: Expired due to Fees

• Current Assignee: Miritz Incorporated
• Original Assignee: Apollo Enterprise Solutions, Inc. (Apollo Enterprise Solutions, Ltd.)
• Inventors: House, William J. III, Hodgkins, David A., Imrey, G. Christopher
• Primary Examiner(s): Kyle; Charles R
• Assistant Examiner(s): Robinson; Kito R
• Application Number:
  US11/372,850
• Publication Number:
  US 20070156581A1
• Time in Patent Office: 1,685 Days
• Field of Search: 705/35, 705/40
• US Class Current: 705/35
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 20/102 Bill distribution or payments
• CPC Class Codes: G06Q 20/14 specially adapted for billing systems
• CPC Class Codes: G06Q 20/28 Pre-payment schemes, e.g. "pay before"
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 30/04 Billing or invoicing
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03

Abstract

A method for the online modification, submission and approval processing of a future payment request to afford a user the ability to renegotiate established loan agreement debt terms in which network communications are established between a user, such as a debtor, and a server is presented. The method comprises receiving information, at the server, regarding the loan agreement debt terms, presenting received information to a debtor, providing an interactive environment enabling a debtor to modify existing terms, submitting modified terms, processing data from the available information using a rules based engine, and processing a future payment request based on at least one decision made by the rules based engine. While online, the user/debtor may engage in revising a rejected future payment request in an attempt to reach a satisfactory renegotiation of debt terms.

Claims

1. A method for implementing a future payment transaction for payments owed, comprising:

presenting information to a user, the information comprising information related to payments owed, including a number of payments owed and scheduled due dates for the payments owed;

providing the user with an ability to submit a future payment request to a server, wherein the future payment request comprises a request to pay money to a third party in escrow for the benefit of a separate entity ahead of schedule for at least a portion of any scheduled payment selectable by the user representing money owed to the separate entity at a future date, wherein the user is provided with an ability to submit the future payment request for an out-of-sequence scheduled payment without submitting a corresponding a payment request in-sequence scheduled payment;

processing said future payment request at the server using a rules based engine configured to evaluate the future payment request by the user and, when acceptable based on rules established on behalf of the separate entity applicable to the acceptability of future payment requests, provide a decision comprising approval of the future payment request based on established rules, and when unacceptable based on rules established on behalf of the separate entity applicable to the acceptability of future payment requests, provide the decision comprising denial of the future payment request based on established rules;

presenting the decision to the user;

offering the user an ability to submit an alternate future payment request when the future payment request is unacceptable based on the rules established and processing that alternate future payment request at the server using the rules based engine;

wherein the rules established on behalf of the separate entity comprise the acceptability of receiving a future payment from any user.

2. The method of claim 1, wherein the user comprises a debtor and the payments owed comprise a debt owed by the debtor.

3. The method of claim 1, wherein the user comprises a debtor and the information comprises one or more loan agreement debt terms associated with the debtor.

4. The method of claim 1, wherein the rules in the rules based engine are established by a credit entity having rights to the debt.

5. The method of claim 1, wherein the rules based engine relies on at least one dictionary employed to translate received information into information used within a server.

6. The method of claim 1, wherein the future payment processing results are formed according to rules established by a credit entity having an interest in the future payment transaction.

7. The method of claim 1, further comprising enabling the user to form and submit an alternate future payment request if the future payment request is denied.

8. The method of claim 1, wherein the rules engine comprises rules that consider the user'"'"'s ability to satisfy the future payment request.

9. The method of claim 6, further comprising involving the credit entity for generating and presenting the user with one or more payment options representing an approved future payment transaction consisting of one or more debt terms.

10. A method for implementing a future payment transaction desired by a user relating to payments owed, comprising:

presenting information to the user, the information comprising a schedule of payments owed, including a number of payments owed and scheduled due dates for the payments owed;

enabling submission of a future payment request to a server, wherein the future payment request comprises a request to pay money ahead of schedule to a third party in escrow for the benefit of a party having an interest in payments owed for at least a portion of any scheduled payment selectable by the user representing money owed to the party having the interest in payments owed at a future date, wherein the user is provided with an ability to submit the future payment request for an out-of-sequence scheduled payment without submitting a corresponding payment request for an in-sequence scheduled payment;

processing said future payment request at the server using a rules based engine configured to evaluate the future payment request by the user and, when acceptable based on rules established on behalf of the party having the interest in payments owed and applicable to the acceptability of future payment requests, provide a decision comprising approval of the future payment request based on rules established on behalf of the party having the interest in payments owed, and when unacceptable based on rules established on behalf of the party having the interest in payments owed, provide the decision comprising denial of the future payment request based on the rules established;

presenting the decision from the server to the user;

offering the user an ability to submit an alternate future payment request when the future a payment request is unacceptable based on the rules established and processing that alternate future payment request at the server using the rules based engine.

wherein the rules established on behalf of the party having the interest in payments owed comprise the acceptability of receiving a future payment from any user.

11. The method of claim 10, wherein the user comprises a debtor and the payments owed comprise a debt owed by the debtor.

12. The method of claim 11, wherein the information comprises one or more loan agreement debt terms associated with the debtor.

13. The method of claim 10, further comprising enabling the user to modify and submit an alternate future payment request if the future payment request is denied.

14. A method for implementing a future payment transaction relating to payments owed, comprising:

presenting information to a user, the information comprising a schedule of payments owed, including a number of payments owed and scheduled due dates for the payments owed;

enabling the user to submit a future payment request to a server, wherein the future payment request comprises a request to make at least one immediate payment to a third party in escrow for the benefit of a party having an interest in payments owed for money owed to the party having the interest in payments owed at a future date representing at least a portion of a scheduled payment selectable by the user, wherein the user is provided with an ability to submit the future payment request for an out-of-sequence scheduled payment without submitting a corresponding payment request for an in-sequence scheduled payment;

processing said future payment request at the server based on submitted modifications to data from the information using a rules based engine configured to evaluate the future payment request by the user and, when acceptable based on rules established on behalf of the party having an interest in payments owed and applicable to the acceptability of future payment requests, provide a decision comprising approval of the future payment request based on the rules established, and when unacceptable based on rules established on behalf of the party having an interest in payments owed, provide the decision comprising denial of the future payment request based on the rules established;

transmitting the decision from the server to the user; and

offering the user an ability to submit an alternate future payment request when the future payment request is unacceptable based on the rules established, and processing that alternate future payment request at the server rules based engine;

wherein the rules established on behalf of the party to the transaction comprise the acceptability of receiving a future payment from any user.

15. The method of claim 14, wherein the user comprises a debtor and the payments owed comprise a debt owed by the debtor.

16. The method of claim 14, wherein the user comprises a debtor and the information comprises one or more loan agreement debt terms associated with the debtor.

17. The method of claim 14, wherein the rules in the rules based engine are established by a credit entity having rights to the debt.

18. The method of claim 14, wherein the rules based engine relies on at least one dictionary employed to translate received information into information used within a server.

19. The method of claim 14, further comprising enabling the user to form and submit an alternate future payment request if the future payment request is denied.

20. The method of claim 14, wherein the rules engine comprises rules that consider the user'"'"'s ability to satisfy the future payment request.