WO2024243280A1

WO2024243280A1 - Apparatus and method for making financial transactions using an intelligent card

Info

Publication number: WO2024243280A1
Application number: PCT/US2024/030516
Authority: WO
Inventors: G. Christopher Imrey; William J. House Iii
Original assignee: Imrey G Christopher; House Iii William J
Priority date: 2023-05-22
Filing date: 2024-05-22
Publication date: 2024-11-28

Abstract

An apparatus for making financial transactions is provided, including an instrument and an electronic storage element provided with the instrument configured to receive information pertinent to a user. The instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee. The instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

Description

APPARATUS AND METHOD FOR MAKING FINANCIAL TRANSACTIONS USING AN INTELLIGENT CARD

The present application claims priority based on U.S. Provisional Patent Application Serial No. 63/468,229, entitled “Apparatus and Method for Making Financial Transactions Using an Intelligent Card,” inventors G. Christopher Imrey, et al., filed May 22, 2023, the entirety of which is incorporated herein by reference.

BACKGROUND

I. Field

[0001] The present invention relates generally to payment processing, and more specifically to processing payments using a card exclusively directed to specific receiving entities.

IL Background

[0002] Credit cards, debit cards, and charge cards are ubiquitous in society today. Such instruments have rendered cash transactions nearly obsolete. Different mechanisms have been set up around these instruments, such as payment processors (Apple Pay, Venmo, etc.) and the like. Such payment processors tend to financially link their services to the foregoing instruments and solidify the necessity of such instruments.

[0003] Certain persons may face financial obligations and may receive funds regularly or sporadically. However, such persons may have a variety of financial needs and requirements and may fall behind in required payments while addressing other matters.

Individuals may, for example, receive funds from an entity earmarked specifically to pay for housing. If the individual receives funds via a check, he or she may deposit those funds into an account and may use the funds and/or a credit, debit, or charge card to purchase goods or services unrelated to housing and may not have funds available to make the required housing payment. As a result, the individual may miss a payment, or possibly more than one payment, falling behind on the housing obligation, and could potentially lose his or her housing. Alternately, the entity may provide funds to a credit, debit, or charge card, but such instruments typically offer no restrictions on goods or services available to be purchased, and again, the individual may miss payments he or she uses funds for other purposes. [0004] Certain types of payment instruments can restrict purchasing. As an example, certain department store charge cards can only be used to purchase items at the issuing department store. However, these instruments do not allow any flexibility based on circumstances encountered, such as differing amounts of funds being available and/or the need or desire to pay alternate payees based on situations encountered.

[0005] It would be beneficial to provide a financial product or instrument that allows for flexibility for payment only to desired or permitted entities that can be changed dynamically based on circumstances. Such a design that overcomes issues with prior designs would be beneficial, and thus improve the efficiency and ease of use of such financial instruments.

SUMMARY

[0006] The following presents a simplified summary in order to provide a basic understanding of some aspects of the claimed subject matter. This summary is not an extensive overview, and is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0007] According to one embodiment, there is provided an apparatus for making financial transactions, comprising an instrument and an electronic storage element provided with the instrument configured to receive information pertinent to a user. The instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee. The instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0008] According to another embodiment, there is provided a system comprising an instrument, an electronic storage element provided with the instrument configured to receive information pertinent to a user, and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee. The instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee. The instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0009] According to a further embodiment, there is provided a system comprising, a financial instrument, an electronic storage element provided with the financial instrument configured to receive information pertinent to a user, and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee. The financial instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the financial instrument and electronic storage element. The financial instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0010] To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the claimed subject matter may be employed and the claimed subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 illustrates a conceptual representation of operation of a single payee closed loop card or instrument;

[0012] FIG. 2 is a conceptual representation of operation of a multi-payee closed loop card or instrument;

[0013] FIG. 3 shows a conceptual representation of operation of a multi-payee single government assistance closed loop card or instrument;

[0014] FIG. 4 illustrates a conceptual representation of operation of a multi-payee multi government assistance closed loop card or instrument;

[0015] FIG. 5 is a conceptual representation of operation of a multi-payee multi-NGO closed loop card or instrument;

[0016] FIG. 6 shows a conceptual representation of operation of a multi-payee multi- NGO closed loop card and open debit card combination on a card or instrument;

[0017] FIG. 7 is a conceptual representation of operation of a single payee 501(c)(3) closed loop decision card or instrument;

[0018] FIG. 8 illustrates is a conceptual representation of operation ofoperation with a business offering a closed loop card and debit card on a card or instrument;

[0019] FIG. 9 shows basic operation according to one embodiment of the design;

[0020] FIG. 10 graphically represents processing of the instrument and use of the instrument according to one embodiment of the design;

[0021] FIG. 11 shows system architecture according to one embodiment of the present design;

[0022] FIG. 12 illustrates decision engine operation for a multi-payee closed loop card or instrument; [0023] FIG. 13 is a representation of decision engine operation for a single payee, government funded card or instrument;

[0024] FIG. 14 shows decision engine operation for a multi-payee closed loop NGO card or instrument;

[0025] FIG. 15 illustrates decision engine operation for a multi-payee multigovernment funded closed loop card or instrument;

[0026] FIG. 16 represents decision engine operation for a single payee closed loop card or instrument;

[0027] FIG. 17 is a representation of decision engine operation for a multi-payee open loop card or instrument;

[0028] FIG. 18 illustrates a multi-payee open loop government card or instrument;

[0029] FIG. 19 illustrates decision engine workflow;

[0030] FIG. 20 shows scheduled payment or obligation workflow;

[0031] FIG. 21 is a general representation of operation;

[0032] FIG. 22 operation in a tenant/landlord scenario;

[0033] FIG. 23 illustrates an alternate single payee instrument embodiment;

[0034] FIG. 24 is a representation of the system wherein an angel or benefactor provides funds electronically to the instrument; and

[0035] FIG. 25 shows an arrangement with multiple parties wherein the present design may be effectively and efficiently employed. DETAILED DESCRIPTION

[0036] In this document, the words “embodiment,” “variant,” and similar expressions are used to refer to particular apparatus, process, or article of manufacture, and not necessarily to the same apparatus, process, or article of manufacture. Thus, “one embodiment” (or a similar expression) used in one place or context can refer to a particular apparatus, process, or article of manufacture; the same or a similar expression in a different place can refer to a different apparatus, process, or article of manufacture. The expression “alternative embodiment” and similar phrases are used to indicate one of a number of different possible embodiments. The number of possible embodiments is not necessarily limited to two or any other quantity.

[0037] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or variant described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or variants. All of the embodiments and variants described in this description are exemplary embodiments and variants provided to enable persons skilled in the art to make or use the invention, and not to limit the scope of legal protection afforded the invention, which is defined by the claims and their equivalents.

[0038] The present design includes an instrument that enables a paying entity to designate funds for a specific purpose, such as payment of a housing obligation, in a manner that enables the user to only pay specific purchases, debts, or obligations with specific monies. The instrument may take the form of a physical card, similar or identical to existing credit, debit, or charge cards including typical security features, wherein a payer may provide funds to the card or underlying account earmarked for specific purposes, such as payee, good, service, debt, or other set or established financial obligation. Such an instrument may be loaded by multiple entities for different purposes, monies may be distributed to all appropriate and approved recipients, and such a system can help persons stay current on his or her financial obligations.

[0039] In the present disclosure, a “closed loop” indicates funds provided to the card are designated with a specific payee or group of payees. For example, if $500 is allocated to or deposited on the card by a third party, or the user herself, the user can only use the $500 with payee X, or payees X through Z, or any number of designated payees or approved accounts. The payee may be designated by any appropriate party, including but not limited to the payer, the payee, and the user. In this disclosure, the term “open loop” refers to an arrangement wherein funds maintained on or available via the instrument include funds having no specific or specified payee or payees. For example, a debit arrangement may be provided with the instrument wherein the user or some third party may have deposited $600 on the card, and that $600 may be used anywhere for any purpose, much like any debit card. Such open loop funds may be employed with closed loop funds on the same instrument or card. In other words, an instrument may have $500 in closed loop funds with designated payees X through Z, in addition to $600 in open loop funds that may be used with any payee.

[0040] FIG. 1 is a conceptual overview of the present system with a single payee in a closed loop arrangement with the financial instrument. FIG. 1 contemplates a payer and a payee, where the payer may be, for example, a user or consumer. Instrument 101 is provided, and funds may be provided to instrument 101 via payer checking account 102, a payer existing debit card 103, a payer credit card 104, a payer online account such as PayPal 105, or payer cash 106, where the payer may pay cash to an entity such as a bank or a store representative, who then allocates the received cash funds to instrument 106. While five sources of payer funds are depicted in FIG. 1 , any form of payment may be employed, including but not limited to investment accounts, deposit accounts, and so forth. The funds are provided with a designated payee or payees. In this example, payee Bank Checking Account 107 is one payee, and Payee External Checking Account 108 is also pictured. Bank in this scenario is the provider of instrument 101, and payment from instrument 101 to Bank Checking Account 107 represents an internal transaction involving no third party or parties. In operation, as an example, payer credit card 102 may be directed by the payer to transfer or provide $300 to instrument 101. The payer’s credit card may be debited $300 and $300 provided to instrument 101 with the express purpose of paying Bank Checking Account 107 at a later time. Such designation is provided with instrument 101 and may be stored in any means appropriate, including but not limited to on a magnetic stripe provided with the instrument, on an EMV chip provided with the card, or a public or private blockchain.

[0041] FIG. 1 includes a border 109 around instrument 101 and payee Bank Checking Account 107, representing accounts or items within the control of the instrument issuer, such as a bank or other financial institution. In the representation of FIG. 1, instrument 101 and Bank Checking Account 107 are within the control of the instrument issuer, indicating the instrument issuer can retrieve funds from instrument 101 for transfer to Bank Checking Account 107 without transfer outside the institution. Similar borders provided in the other representations provided herein convey the same level of control or access by the instrument issuer.

[0042] FIG. 2 illustrates a multi -payee closed loop situation, with instrument 101 receiving funds from five possible payer accounts in this representation, namely payer options 102 through 106. In this representation, funds totaling $400 are provided to instrument 101, and may be paid to Payee 1 201, representing a first external checking account, Payee2 202 representing a second external checking account, or Payee3 203, representing a Bank Checking account. In this scenario, instrument 101 has a value of $400, wherein $100 may be transferred to Payee3 203, $200 to Payeel 201, and $100 to Payee2 202. Not only can the desired payee be provided to instrument 101, but a maximum or desired amount for transfer may be provided to instrument 101.

[0043] FIG. 3 adds government assistance 301 to the five possible payer accounts in this representation, namely payer options or accounts 102 through 106. In this representation, government assistance 301 is provided to instrument 101 in the amount of $350, and the user or payee, i.e., the entity directing payments to be made via instrument 101, can direct $50 to Payee3 203, $200 to Payeel 201, and $100 to Payee2 202. FIG. 4 illustrates three different government assistance 401-403, each providing funds dedicated to specific payees or debts. From FIG. 4, plan 1 401 is directed to Payeel 201, where $200 is provided and available, plan 2 is directed to Payee2 202, $100 provided and available, and plan 3 directed to Payee3 203 for $50. The user can employ his or her instrument 101 when desired to pay only those entities and obligations provided by the plans illustrated, with funds available for and directable to only those entities approved by the payer (accounts 102 through 106) and maintained with or on instrument 101.

[0044] FIG. 5 presents two third party NGOs (non-governmental organizations) 501 and 502, each providing $200, where third party NGO1 directs the $200 to Payeel 201 while third party NGO2 directs its $200 to Payee2 202 or Payee3 203. As may be appreciated and discussed further herein, a portion of the $200 may be dedicated to Payee2 and the remainder to Payee3, or the amount provided may be used in any amount, at the user’s discretion, to pay the obligation to Payee2 or Payee3. In other words, control over the amount provided may be at the discretion and control of the third party NGO or the user and may be available to multiple approved payees. Such discretion and control, established by payer or user, may be provided in any situation disclosed herein. Discretion and control may be changed to different entities in appropriate circumstances. For example, while Payer 1 may dedicate $550 for Payee X, at a later point Payee X may be removed from the list of available payees for any amount of the $550 left, or the payee may change from Payee X to Payee Y. Such changes are conveyed to instrument 101, such as via the financial institution associated with instrument 101. The user may be asked to reconnect her card at a given time, or codes or information provided to instrument 101 may be altered. For example, if the financial institution dedicates funds to be paid to Payee X via code ABCDEFG, code ABCDEFG may be altered by the financial institution to indicate Payees Y and Z. A user attempting to pay Payee X with funds after a change to Payees Y and Z may result in a message that such funds are unavailable, and potentially an indication to contact the financial institution.

[0045] FIG. 6 illustrates a dual NGO implementation similar to the representation of FIG. 5 and including a debit card or instrument having no restrictions on use. In this arrangement, each NGO (NGO1 501 and NGO2 502) provides $200 for the same payees, and $500 is provided to instrument 101 for use in any manner desired. Thus a total of $900 is available from instrument 101, $500 for any desired use and $400 for dedicated uses or payments for obligations. Similar debit amounts may be provided to the other scenarios depicted herein, including but not limited to the government plans shown in FIG. 4.

[0046] FIG. 7 shows an overall arrangement for one version of operation of the current system. From FIG. 7, the issuing entity provides instrument 101, wherein decision engine 701 provides a pool of agreements, wherein an agreement is an agreement to pay an amount of money to a payee and may include the term of the payments scheduled, monthly amounts due, and other relevant information regarding payment. Instrument 101 may be associated with one or more of the pool of agreements 702. The issuer may place the relevant agreement information on instrument 101 before providing the instrument to the user or may provide the information afterward. One example of a selected agreement 702 is payment from source A, which may be any entity including government, NGO, or other third party, to payee B, in the amount of $1000 total, with a monthly amount due of $47. The selected agreement 703 may allow for overpayment to be credited to the end of the obligation. In another scenario, the obligation may be $668 due interest free by December 31, with interest applied after December 31. Any financial agreement, determined by decision engine 701 or otherwise, may be provided as selected agreement 703.

[0047] FIG. 7 illustrates a second selected agreement 704 having an amount due and a date due as minimum information, wherein such information is also provided to instrument 101, and a 501(c)(3) card 705 that includes a 501(c)(3) entity payment provided to instrument 101. Payer A 706 may provide funding to instrument 101 and Payee B 707 may receive funds in accordance with and according to the terms of selected agreement 703, such as via an external checking account. In accordance with selected agreement 704, instrument 101 receives external payer C 710 funding. In operation the card agreement reader 708 processes transactions sending payment to, for example, Payee B 707 and may provide fees to the financial institution at point 711. A certain portion of the costs may be provided to a fund 709, which may be nonprofit or other charitable organization for example, which may provide funds to 501(c)(3) card 705.

[0048] Payer A may be any entity, including a lender set up to fund instrument 101. In one embodiment, Payer A may lend an amount to the user and may provide funds, such as $4000, to instrument 101 for payment to Payee B. As part of this arrangement or transaction, the user may agree to pay $425 over 10 payments to Payer A or another agreed to entity using instrument 101. Thus Payer A both funds instrument 101 and receives proceeds from instrument 101.

[0049] FIG. 8 shows user device 801 configured to operate using instrument 101. Instrument 101 is illustrated as representation 802 and selections 803 a-c indicate local businesses can load offers. For example, if you purchase an automobile today, you can pay $200 down and $500 per month for six years, or $1000 down and $450 for five years, etc. Such offers are provided to decision engine 701, which may be provided to user device 801 as offers 803a-c. Representations 804 indicate amount of funds available and open funds available, where amount of funds available may include the total amount available including restricted or dedicated funds and open funds can be used for any purchase. Such information may be provided to user 805, who can redeem offers at the business or via the business website using instrument 101. Offers may be for restricted or dedicated funds or may be usable with open funds, or a combination thereof.

[0050] FIG. 9 shows a first general overall flowchart of the system disclosed. Point 901 indicates the user receives a link via letter, email, text, or other communication method regarding payment plans for a debt or obligation. Point 902 calls for the user to log into the platform or system at a convenient time. Point 903 calls for the user to select a plan that works best for his or her situation, while point 904 processes payment in accordance with finances on instrument 101 for a desired period of time. The desired period of time may be one payment or may be multiple payments and may be until the account is depleted or the obligation is satisfied.

[0051] FIG. 10 is an alternate view representing hardware and operation of the system including instrument 101. From FIG. 10, card 1001 may include an EMV chip, magnetic stripe, or other readable data collection component. EMV 1002 is pictured in FIG. 10. The card 1001 may be provided to formatting device 1003 which may format the EMV or other readable data collection component for financial information and usage parameter data, such as fields for monetary amounts and other fields for usage parameters, such as codes representing acceptable payees. Other information and fields may be provided and/or formatted, such as dates, warnings, and so forth. Formatting device 103 provides instrument 101 capable of operating in accordance with the present design. Financial institution 1004 may in this embodiment house financial device 1005, but financial device 1005 may be located anywhere. Financial device 1005 receives instrument 101 and may provide information specific to the instrument 101, such as obligations, available funds, and association between specific funds, and other information needed to facilitate payment of funds at a point of sale or online. Information provided to instrument 101 may be similar to the financial information provided as shown in, for example, FIGs. 1-6. Instrument 101 may then be provided to user 1006.

[0052] User 1006 may have three options, providing instrument 101 to a merchant processing device 1007, where merchant processing device 1007 may be at a physical store location, or online, or any retail operation available. The user 1006 may provide instrument 101 to the merchant processing device which may receive funds according to the requirements or restrictions on instrument 101. Alternately, instructions for contacting a remote device may be provided on instrument 101, and when user 1006 contacts or provides instrument 101 to merchant processing device 1007, merchant processing device 1007 may obtain contact and/or authentication information and may contact a third party or third party device (not shown) to provide and obtain information to effectuate a transfer of funds according to restrictions imposed, if any, and accounting for funds for instrument 101. Such a third party device may be controlled or operated by or in association with financial institution 1004. Once the transaction has been completed, if for example user 1006 provides instrument 101 to a merchant point of sale device represented by merchant processing device 1007, the instrument may be returned to the user or may be provided to financial device 1005.

[0053] Alternately, once instrument 101 is returned to user 1006, user 1006 may provide instrument 101 to financial device 1005. Financial device 1005 in FIG. 10 represents a network of financial devices. A user may bring her card to a local bank branch that differs from the bank branch where she obtained instrument 101. Financial device 1005 may receive the instrument and may provide additional funds such as is shown in FIGs. 1 through 6 or in any manner acceptable.

[0054] User 1006 may alternately provide instrument 101 to third party processing device 1008, either physically or via the internet or other communication medium. User 1006 may wish to either use funds available on the card for payment or may seek to obtain funds from third party processing device 1008 in accordance with the requirements of FIGs. 1 through 6, for example. Third party processor may have arrangements with and be in a position to transfer funds to and receive funds from devices such as financial device 1005 and/or merchant processing device 1007. In one example, third party processing device 1008 may receive instrument information from user 1006 indicating that user 1006 wishes to pay $200 to Merchant X. Third party processing device 1008 may remove funds from instrument 101, transmit such information to, for example, central processing system 1009, and may transmit the required funds electronically to merchant processing device 1007 which includes the Merchant X account. In this situation, user 1006 may not physically provide instrument 101 to third party processing device, or an entity having contact or control over third party processing device 1008, but may provide authentication information and instrument information to third party processing device 1008. Such authentication may be used in conjunction with central processing system 1009 or other devices in the arrangement as appropriate.

[0055] Central processing system 1009 comprises a series of devices that facilitate the authentication and the functionality described herein, including with financial device 1005, merchant processing device 1007, and third party processing device 1008. Multiple such devices, e.g., multiple financial devices, merchant processing devices, and multiple third party processing devices may be included in the network and supported.

[0056] FIG. 11 illustrates the overall system architecture. Client web users 1101 can interface with the internet 1102 and can interface via the internet 1102 with authorization element 1103. Other users 1105 are shown also interfacing separately with internet 1106, wherein internet 1102 may send an email or SMS request or other communication to an email/SMS/other transmission service, such as sendGrid 1107, which may send information to internet 1106 and/or an email or SMS message as shown. A campaign manager 1108 may manage campaigns, where a campaign is a set of goals desired to be achieved by a vendor or merchant entity, such as resolving $1M in delinquent accounts or obtaining 500 full payments within the next year. WAF 1104 represents a web application firewall.

[0057] In the implementation of FIG. 11 , an Azure implementation is contemplated, or an Azure Kubernetes Service (AKS) implementation. Cluster 1109 represents the device functionality of cloud based applications and devices for the current design. Presented in cluster 1109 are management ingress element 1110, login ingress element 1111, customer ingress element 1112, egress element 1113, management API 1114, login service 1115, customer API 1116, and outbound service 1117. Interfaces between the various elements are shown, including egress 1113 interface with internet 1106 via sendGrid or a CRM system, such as HubSpot, transmissions. Message bus 1118 receives customer API 1116 and management API 1114 information and interfaces with database gateway 1119, event service 1120, decision engine 1121, plan manager 1122, pay service 1123, PDF service 1124, and egress service 1125. SQL database 1126 interfaces with the database gateway 1119 to provide database contents. Outbound service 1117 provides and receives remote procedure calls to and from egress service 1125. The system provides pull attachments between outbound service 1117 and storage element 1129. PDF service 1124 may provide a save generated PDF to storage element 1129. [0058] Application server 1127 is provided, in one embodiment an IBM WebSphere application server. VPN 1128 interfaces between institution 1130, such as a bank, and application server 1127. In this embodiment, instrument 101 may provide or receive appropriate information, such as financial information, payment obligations (amount and receiving entity) and so forth.

[0059] FIG. 12 illustrates an implementation of a multi -payee closed loop instrument and the process flow. From FIG. 12, the system may provide an invitation at point 1201 to employ an instrument such as instrument 101 in an arrangement with a pre-established institution or payee, or multiple such entities. The user may be invited to log on to a web site. Point 1202 provides the agreement to the user in the form of an “I agree” page, the user may continue from the “I agree” page at point 1203, and box 1204 determines whether the user has agreed to the terms provided. If so, operation proceeds to the authentication and registration process at point 1205. If not, the user returns to the “I agree” page at point 1202.

[0060] Point 1206 determines whether the user is authenticated. Authentication may be performed by any reasonable operation available. If the user is authenticated, processing moves to point 1207. If not, the user is returned to the authentication/registration process 1205. Point 1207 determines whether the user is in the plan, meaning has been approved by the financial institution and/or a payee and/or a payer.

[0061] If the user is in the plan, the system provides the user with a dashboard 1208 where she can select various available options. Options include Transactions 1209, meaning financial obligations she has and payments made, and transaction detail 1210, payment plans 1211 plan details 1213, and can manage her pay schedule at point 1212, and transaction history 1214 is also available. Plans may be offered by the payer and/or payee and may include repayment plans for monies expected to be received, for example. For example, debt 1 may be owed to payee K, and payment plan L may be offered by payee M, and such information may be made available to the user via dashboard 1208. Details of the plan, such as individual payments due, payments made, and so forth may be provided, and a list of transactions also provided. If the payee allows the user to change or manage a payment schedule, the user can do so at point 1212. Management of the schedule includes altering payment dates and amounts where available, and payees may restrict opportunities for management of payment schedules. For example, if the payment due date is the 17^th, the payee may establish the user can make the payment one week late without penalty, but no more than one week.

[0062] In certain embodiments, the system may provide the user with certain options for plans. For example, payment of $100 every month for 12 months, or payment of $55 every month for 24 months, or payment of $300 immediately and $70 per month for 12 months. The user may select or alter a proposed payment plan in some embodiments, subject to approval from the payer and/or payee. The questions noted at point 1221, when the user is not in the plan, may establish the user’s financial situation and ability to pay, as well as payment sources, including dedicated payment sources, such as where payer R is providing funds for the exclusive purpose of settling user’s financial obligation S.

[0063] Note that in some instances, funds can be provided to the user for settlement of a debt of another, such as an incapacitated relative. Thus the financial obligation and the payments made by payers may not be the property of the user, even though the user may have access to and control of instrument 101. As used herein, the term “user” is intended broadly and may indicate the person holding and/or controlling instrument 101, the person on behalf of whom instrument 101 is being employed, or any other person or entity having need for the functions described herein.

[0064] Dashboard 1208 may also provide debit card information at point 1215, wherein debit card information comprises funds usable for any purpose and not dedicated to or earmarked for a specific payee. The funding sources for those amounts provided to instrument 101 in the form of a debit card type payment can be obtained by the user via dashboard 1208 at point 1216. User profile, including relevant information about the user (name, contact information, passwords, and so forth) is available at point 1217.

[0065] The system determines whether plans are available at point 1218. If no plans are available, the user may browse dashboard 1208 as desired, but eventually the user may logout or the system may log her out at point 1219 and operation halts at point 1220. If there are plans available, the system evaluates whether the user needs to answer questions

[0066] The system provides the user with a set of questions via a questionnaire page at point 1222. Questions may vary, and the user may be provided with additional questions as time goes on. Questions may vary and may be provided by the financial institution or financial device 1005, a payer or payer device, and/or a payee and a payee device, or multiple such payers, payees, and/or devices. Questions may for example seek to assess the user’s ability to pay, the user’s current financial condition, existing and/or anticipated obligations, as well as questions such as age, where he or she does banking, current and/or anticipated sources of funds, and so forth. Based on answers to the questions, the user may be asked to log in at a later date such that the information collected at the questionnaire page can be processed and offers or plans provided at a later time. Alternately, the system may immediately provide the user with offers or plans, including offers or plans approved by payer, payee, and/or another interested party. Both these alternatives are shown as decision offers 1223. Specific instrument offers may be provided at point 1224. Point 1225 allows the user to compare offers, while point 1226 provides the user with offer details. Point 1227 evaluates whether the user has accepted an offer. If not, the system may direct him to the specific instrument offers at point 1224, and if he accepts the offer, he may be directed to confirm his acceptance at point 1228.

[0067] Point 1229 inquires as to whether the user has an instrument 101, and if not, he registers and obtains an instrument 101 at point 1230. Payees are bound to the instrument and any relevant funds at point 1231. If a debit card option exists, point 1232 funds the debit card of the instrument. Point 1233 may be employed where appropriate to transmit payment to bound payees. Point 1235 represents the plan manager, where the plan manager performs accounting functionality related to any plans selected as well as any transactions undertaken using the instrument 101, such as any payments made according to the plan or plans and any debit card transactions. Point 1234 calls for displaying any contract or plan.

[0068] FIGs. 13 through 18 illustrate different arrangements, including payment by government entities, use of open loop cards as opposed to closed loop cards, single payee and multi payee options, and so forth. As may be appreciated, much of the functionality of FIG. 12 and the components presented therein are offered with certain modifications based on the particular scenario.

[0069] FIG. 19 illustrates the workflow of the decision engine. Message broker 1901 receives and transmits messages, including a decision request to decision engine 1902. Decision engine 1902 retrieves the profile of the user at point 1903, and classifiers for the user at point 1904. Classifiers are classifications of users into groups, which may be established and may change. For example, “greater than 700 credit score,” “self employed,” “past bankruptcy,” and so forth. Different classifiers may be created and employed and removed as desired. Point 1905 calls for classifying the user and calculating the first level of the multi-decision process, essentially determining basic attributes for offers based on the particulars of the user. Point 1906 calls for retrieving offers. Data requests travel between message broker 1901 and points 1903, 1904, and 1906.

[0070] Point 1907 calls for qualifying offers based on the first level of the decision process and relevant profile attributes. Point 1908 calls for qualifying proposed modifications, where modifications may be any counterproposal by the user and/or matters such as terms of the existing agreement, characteristics of the subject matter of the existing agreement, and so forth. Point 1909 calls for qualifying grants, such as qualifying according to available grants and user financial characteristics. Point 1910 qualifies payment plans based on state of rele vant accounts and availability of grants or third party payments, for example. Point 1911 requalifies agreement modifications, ensuring such modifications are acceptable based on any existing financial arrangement or payment plan. Point 1912 saves decision results and point 1913 formats the decision results, which are provided to message broker 1901.

[0071] FIG. 20 illustrates the scheduled payments workflow. Plan manager 2001 manages all plans, i.e., contracts, agreements, financial obligations, and so forth. Point 2002 constructs a payment plan message, where all pending payments to specific payees are written to the database with transaction dates in the future. Point 2003 calls for transmitting the payment plan and message to the database gateway. Message broker 1901 sends the plan and associated information to database gateway 2004, which interfaces and provides and retrieves plan information to and from database 2005, which may be a SQL database.

[0072] Payment service 2006 polls database 2005 for due payments at point 2007 by transmitting database requests to database 2005 via message broker 1901. If no payments are due at point 2008, the system loops back to point 2007. If payments are due, the system loops through all due payments at point 2009 by transmitting a payment message at point 2010 and transmitting the result message at point 2011, where payment results are provided to message broker 1901 for saving to the database 2005. Payment message at point 2010 passes to application server 1127, and VPN 1128 interfaces between institution 1130, such as a bank, and application server 1127. Instrument 101 may provide or receive appropriate information, such as financial information, payment obligations (amount and receiving entity) and so forth. The user of instrument 101 may direct a payment to payee 2012.

[0073] FIG. 21 is a general overview of the present design. From FIG. 21, consumer or user 2101 may choose and accept a plan from one or more plans determined by the decision engine 2105. User 2101 may employ mobile device and mobile application 2102 to contact the API service 2103, which interfaces with financial institution 2107Financial institution 2107 may provide user 2101 with instrument 101. Database gateway 2104 provides the interface between API service 2103 and database 2106, and decision engine 2105 receives relevant information about the payer, payee, the plan or obligation in place, proposed amendments and provides options to the user based on rules selected or specified. Scheduled payments may be made via instrument 101 to a payee 2108.

[0074] FIG. 22 is a general diagram showing operation of an embodiment of the current design. From FIG. 22, in the upper left continuing to the lower right, point 2201 provides for landlord data entry and tenant account synchronization as needed where the landlord or property manager enters tenant data, monthly rent or obligation, delinquent account status, and so forth, or may synchronize current account data using known available information. Point 2202 represents the portfolio manager dashboard, managing, segmenting, and distributing tenant portfolios and optimizing tenant payment and contact campaigns in an arrangement organized as Master Portfolio with tenant pools provided therein. Point 2203 represents the contact manager notifying tenants by any reasonable means, including mail, email, or SMS, and providing them with links to login and view payment plans. Point 2204 reprpesents the tenant logging in from an appropriate computing device. Point 2205 stores and provides policies, plans, rules, and calls for the authentication of the user and retrieves applicable rules and available landlord discount percentages. Point 2206 illustrates separate devices, a decision engine and a parser, where the decision engine receives tenant account data and the parser extracts and calculates tenant and account data and performs decisioning functionality. Point 2207 represents a tenant offer dashboard, where the decision engine computes, calculates, and generates multiple payment plans and settlement offers for the tenant based on the tenant’s ability to pay and landlord offers. [0075] Point 2208 calls for the tenant to view discounts and payment plans and select a desired offer fitting the ability to pay. Alternately, the landlord may enable the tenant to propose an alternative resolution online that differs from the offers presented. Point 2209 calls for the tenant choosing method of payment and authorizing and scheduling the agreed upon payment amount. Point 2210 processes the payments using, in one embodiment, instrument 101 as described above. Point 2211 distributes payments to any party based on distribution rules established. Point 2222 posts transactions to accounts, such as the tenant account.

[0076] According to another embodiment, there is provided a solution wherein payees enter their Destination Accounts in the system, specifying which Payer funds will be deposited into which Payee Destination Account. When a Payer wants to make a payment or enters into a payment agreement with the Payee, the System will issue a prepaid debit card to the Payer, have the agreed upon payment amount loaded onto the card from one of the Payer’s source accounts (Checking Account, Debit Card, VISA/Mastercard, Paypal, Cash, etc.), lock the funds on the Payer’s new prepaid debit card for the Payee designated by the Payer and transfer the agreed upon amount to the Payee’ s Destination Account on the agreed upon date.

[0077] A payment processing platform is contemplated where the invention allows the Payee to sign up to the platform and receive an Intelligent Card loaded with information from the system that debits a Payee Source Account associated with the user and pushes payments to Payee Checking Accounts.

[0078] Plan amendments may be provided, wherein the payee creates a set of possible agreements using an Agreements Editor, the payee inputs qualification requirements for each Agreement, such as Amount of Delinquency, Start Date of Lease, Lease Termination Date, Monthly Rent, square footage, number of bedrooms, number of residents in the household, number of children in the household, why the tenant is delinquent, etc.

[0079] The payee may upload a set of User Profiles, i.e. User Accounts, statuses, lease agreement values, Payee Account per User Account or connect database of accounts to IRAP platform. The user may be contacted using Decision Engine rules for method of contact and contact message and sent an invitation code. The user may log in using invitation code and additional tenant-known information. The user profile is loaded into Decision Engine from uploaded or synchronized database. The user inputs optional information into system. The decision engine presents pool of possible Agreements based on User Profile and Lease data.

[0080] Rules to assemble the pool of agreements include rules to assemble additional agreements, amendments to existing lease, addendums to lease. Agreements include dates, amounts, Payer source accounts and Payee destination accounts. The user may select an agreement or plan. The user may input source payment account information into System.

[0081] The user agrees to Issuing of a Card or instrument such as instrument 101, loading of card with first payment amount from Source payment account, and Sending of First Payment Amount from user Card to payee Destination Checking Account. The system checks to see if Non-ident Prepaid Card issued and issues a card if not issued yet. The system assigns Bin numbers to the User Profile. An agreement loader loads the selected Agreement onto the Card, loads the card with Agreement ID, where the Agreement ID ties back to Agreement date/time/amount/routing.

[0082] A Card reader event service checks Card for Agreements and processes Agreement loaded on Card. The system may load the Intelligent Card with payment amount. The system routes payment to payee Destination Account from the Intelligent Card.

[0083] The system may include a credit/debit card that can be managed to set specific payment amounts per merchant or by expense category, per diem payments allowed, and restricts the cardholder’ s spending to the pre-defined amounts in the pre-defined categories in the pre-defined dates.

[0084] The system may include a credit/debit card that has Vault (dedicated funds) and Open Card (nondedicated funds) capabilities. Vault Capabilities: The card can be managed to lock specific BillPay payments to Specific Merchants by specifying that funds earmarked for BillPay remain in the Vault and cannot be used for Open Card purchases or withdrawals. Open Card capabilities include allowing users to set specific payment amounts per merchant or by expense category, per diem payments allowed, and restricts the cardholder’s spending to the pre-defined amounts in the pre-defined categories in the predefined dates. [0085] The decision engine can employ Al (artificial intelligence) to generate plans and offers based on any relevant learnings or data. Al can be used to determine the best contact methods and content for reaching out to relevant parties. Al can be used by the system to score or classify the payer, the payee or any relevant assets. Al can be employed as a natural language interface or chat for any or all parties. Al can also be employed to alter the information captured and alter display information. The decision engine can be used to provide machine learned information to the Al system, and the decision engine may act as a “prompt engineer” on behalf of the end user, where the “prompt engineer” strives to improve machine-generated outputs in ways that are reproducible. In other words, the system attempts to align Al behavior with human intent. The system and Al component may use Intelligent Card or instrument 101 usage history to generate offers, not just from participants, but from partners that may interest the end user.

[0086] FIG. 23 illustrates an alternate single payee instrument embodiment. From FIG. 23, Lender A inputs loan criteria for Payer loan into the decision engine. Payee B inputs payment plan criteria into the decision engine. The Payer logs in and optionally enters in Lender A and/or Payee B criteria. The decision engine calculates Payee B approved plans and Lender A terms. The Payer may select Payee B plan and Lender A terms. Lender A may fund the selected plan onto instrument 101. Instrument 101 may provide funds to Payee B according to the selected plan, and the Payer repays Lender A loan according to selected Lender A terms via instrument 101.

[0087] FIG. 24 illustrates operation of the system when an angel investor or angel benefactor is presented, called an “angel” herein. In this scenario, an angel is any entity providing funds to the user for either a dedicated purpose or for general unrestricted use. From FIG. 24, instrument 101 maintains funds for the benefit of and use by the user while angel instrument 2401 is provided to the angel and can hold funds as described herein. In the scenario of FIG. 24, the angel may be maintaining $200 on angel instrument 2401, and by operation of contract or by other circumstances the angel may cause funds to be transferred from angel instrument 2401 to instrument 101. Third party NGO 2402 may provide funds to instrument 101. According to an established agreement or contract or arrangement, the system may cause instrument 101 to transfer funds to Payeel 2403, Payee2 2404, and Payee3 2405. In the example presented, the angel provides $200 to instrument 101, with the agreement or indication that the funds are to be provided to Payee 1 2403 only. Funds transferred by Third party NGO 2402 are in this scenario provided to Payee2 2404 and Payee3 2405.

[0088] FIG. 25 is a general representation of a situation with multiple entities having multiple obligations or holdings that may be addressed by the present system. From FIG. 25, four properties are being managed or owned by different entities, including Property 1 2501, Property 2 2502, Property 3 2503, and Property 4 2504. Tenant 2521 has obligations to Property 1 2501 and 2502, such as renting the two properties. Property manager 1 2541 manages Property 1 2501, Property Manager 2 manages Property 2 2502, Property 3 2503, and Property 4 2504. Holding company 1 2561 holds Property 1 2501, while Holding company 2 holds Property 2 2502 and Property 3 2503. Landlord 2581 holds Property 4 2504.

[0089] In the scenario of FIG. 25, the tenant 2521 pays for Property 1 2501 and Property 2 2502 rents, and monies are provided and accounted for with Property Manager 1 2541 for Property 1 2501 and Property Manager 2 2542 for Property 2 2502. However, Property Manager 2 2542 must receive funds for three properties and accounting for each must be correct. Holding company 2 2562 ultimately receives rents for Property 2 2502 and Property 3 2503, receiving funds from tenant 2521 for her rental of Property 2 2502 and accounting for such payments with Property Manager 2 2542.

[0090] The present system provides an organized method for collecting and distributing funds such that each party receiving funds receives the correct funds at the appropriate time. Fees are calculated and distributed and the process of paying rents is easier and more efficient with little risk of payments being forgotten or misdirected.

[0091] Thus according to one embodiment, there is provided an apparatus for making financial transactions, comprising an instrument and an electronic storage element provided with the instrument configured to receive information pertinent to a user. The instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee. The instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0092] According to another embodiment, there is provided a system comprising an instrument, an electronic storage element provided with the instrument configured to receive information pertinent to a user, and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee. The instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee. The instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0093] According to a further embodiment, there is provided a system comprising, a financial instrument, an electronic storage element provided with the financial instrument configured to receive information pertinent to a user, and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee. The financial instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the financial instrument and electronic storage element. The financial instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

[0094] What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the described embodiments are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

Claims

1. An apparatus for making financial transactions, comprising: an instrument; and an electronic storage element provided with the instrument configured to receive information pertinent to a user; wherein the instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee; wherein the instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

2. The apparatus of claim 1, wherein the plan comprises a payment schedule for the one payee.

3. The apparatus of claim 1, wherein the user may provide information on the instrument and electronic storage element to a merchant and direct the funds unencumbered by any plan instructions to the merchant.

4. The apparatus of claim 1, wherein the user may propose plan changes and a remote device may receive the instrument and the electronic storage element and provide plan modifications to the instrument and the electronic storage element approved by the one payee.

5. The apparatus of claim 1, wherein the plan instructions comprise fees associated with payments made and anticipated distribution of the fees to entities provided in the plan instructions.

6. The apparatus of claim 1 , wherein any entity may provide funds to the instrument and provide instructions for distribution of funds in the plan instructions.

7. The apparatus of claim 1, wherein the instrument is configured to interface with an external decision engine configured to provide at least one offer to pay an amount owed, wherein the at least one offer is selectable to form one of the plan instructions.

8. A system comprising: an instrument; an electronic storage element provided with the instrument configured to receive information pertinent to a user; and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee; wherein the instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the instrument and electronic storage element and refrain from distributing funds to any payee other than the one payee; wherein the instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

9. The system of claim 8, wherein the payer comprises one of a non-govemment organization (NGO), a government organization, and a benefactor.

10. The system of claim 8, wherein the instrument and electronic storage element may receive information for multiple payers and multiple payees.

11. The system of claim 8, wherein the instrument and the electronic storage element connect the instrument to a financial institution.

12. The system of claim 8, wherein the plan instructions comprise fees associated with payments made and anticipated distribution of the fees to entities provided in the plan instructions.

13. The system of claim 8, wherein any entity may provide funds to the instrument and provide instructions for distribution of funds in the plan instructions.

14. The system of claim 8, wherein the decision engine is configured to provide at least one offer to pay an amount owed, wherein the at least one offer is selectable to form one of the plan instructions.

15. A system comprising: a financial instrument; an electronic storage element provided with the financial instrument configured to receive information pertinent to a user; and a decision engine configured to receive decision information comprising user relevant information, plan information, payer information, payee information, and proposed plan amendments and process the decision information to provide amended plan terms to the user that are amenable to the payee; wherein the financial instrument and the electronic storage element are configured to receive an electronic indication of funds from a payer and exclusively cause distribution of the funds from the payer to one payee according to plan instructions available on the financial instrument and electronic storage element; wherein the financial instrument and the electronic storage element are further configured to receive and cause distribution of funds unencumbered by any plan instructions.

16. The system of claim 15, wherein the payer comprises one of a nongovernment organization (NGO), a government organization, and a benefactor.

17. The system of claim 15, wherein the financial instrument and electronic storage element may receive information for multiple payers and multiple payees.

18. The system of claim 15, wherein the financial instrument and the electronic storage element connect the financial instrument to a financial institution.

19. The system of claim 15, wherein the plan instructions comprise fees associated with payments made and anticipated distribution of the fees to entities provided in the plan instructions.

20. The system of claim 15, wherein any entity may provide funds to the financial instrument and provide instructions for distribution of funds in the plan instructions.