Patent Application
20130212023
Financial institution customers are constantly looking for new and useful ways to manage their finances. This is particularly so given that most customers have multiple financial accounts and the effects of neglecting any one of them, even once, can result in payments, added interest, public embarrassment, and/or other outcomes. Accordingly, there is a need to provide methods and apparatuses that help these customers better manage their finances.
In general terms, embodiments of the present invention relate to methods and apparatuses for prepaying, covering, avoiding, negating, and/or otherwise offsetting future exceeded account threshold payments. As an example, in some embodiments, an account holder can prepay one or more future exceeded account threshold payments, so that if the account holder later engages in a transaction that results in an exceeded account threshold payment, that exceeded account threshold payment will be paid, covered, avoided, and/or otherwise offset. In other words, the account holder can offset an exceeded account threshold payment before a transaction that results in that exceeded account threshold payment is ever initiated.
In some cases, the account holder may have a financial incentive to prepay and/or otherwise offset future exceeded account threshold payments. For example, in some embodiments, a regular exceeded account threshold payment is $35 if paid after and/or at the time the exceeded account threshold payment is incurred, but the exceeded account threshold payment may be only $10 if paid in advance (i.e., paid before the holder engages in the transaction that results in the exceeded account threshold payment). There may also be other incentives for prepaying, covering, and/or otherwise offsetting future exceeded account threshold payments. For example, in some embodiments, when an account holder prepays one or more future exceeded account threshold payments, the account holder also consents to later incurring and/or offsetting those one or more future exceeded account threshold payments. As a result, the holder may not be required to provide this consent later (e.g., at the time of the exceeded account threshold transaction, and the like), which may spare the holder of any public embarrassment, annoyance, and/or hassle associated with providing the consent and/or being notified of the exceeded account threshold and/or exceeded account threshold payment.
As described in more detail herein, some embodiments of the present invention provide a method that includes: (a) receiving one or more payments for offsetting one or more future exceeded account threshold payments, where the one or more payments are associated with an account; (b) receiving transaction information associated with a transaction, where the transaction involves the account, and where the transaction is initiated after the receiving the one or more payments; (c) determining, based at least partially on the transaction information, that the account will incur an exceeded account threshold as a result of the transaction; (d) determining that the one or more payments are sufficient to offset an exceeded account threshold payment associated with the exceeded account threshold; and (e) authorizing the transaction based at least partially on the determining that the one or more payments are sufficient.
In some embodiments, the method further includes increasing an exceeded account threshold allocation associated with the account based at least partially on the receiving the one or more payments. In some of these embodiments, the determining that the one or more payments are sufficient includes determining that the exceeded account threshold allocation is sufficient to offset the exceeded account threshold payment. In addition, in some embodiments, the authorizing the transaction includes authorizing the transaction based at least partially on the determining that the exceeded account threshold allocation is sufficient. In some embodiments, the determining that the exceeded account threshold allocation is sufficient to offset the exceeded account threshold payment includes determining that the amount of the exceeded account threshold payment is less than the amount of the exceeded account threshold allocation.
In some embodiments, the method further includes decreasing the exceeded account threshold allocation based at least partially on the authorizing the transaction. Also, in some embodiments, the exceeded account threshold allocation has a balance, and the increasing the exceeded account threshold allocation includes increasing the balance by at least the amount of the one or more payments. In some of these embodiments, the decreasing the exceeded account threshold allocation includes decreasing the balance by the amount of the exceeded account threshold payment. However, in other embodiments, the exceeded account threshold allocation includes a number of exceeded account threshold payment credits, and the increasing the exceeded account threshold allocation includes increasing the number of exceeded account threshold payment credits. In some of these embodiments, the decreasing the exceeded account threshold allocation includes decreasing the number of exceeded account threshold payment credits. Further, in some embodiments, the determining that the exceeded account threshold allocation is sufficient to offset the exceeded account threshold payment includes determining that the exceeded account threshold allocation has at least one exceeded account threshold payment credit.
In some embodiments, the method further includes: (a) determining that the exceeded account threshold allocation has fallen below a predetermined threshold; and (b) prompting a holder of the account to increase the exceeded account threshold allocation based at least partially on the determining that the exceeded account threshold allocation has fallen below the predetermined threshold. Additionally or alternatively, in some embodiments, the method further includes: (a) receiving a transaction history associated with the account; (b) determining a trend based at least partially on the transaction history; and (c) prompting a holder of the account to submit one or more payments for offsetting one or more future exceeded account threshold payments, where the prompting is based at least partially on the trend. In some embodiments, the receiving the one or more payments includes receiving, from a holder of the account, consent to the account being assessed the one or more future exceeded account threshold payments, and where the authorizing the transaction includes authorizing the transaction based at least partially on the receiving the consent.
In some embodiments, the receiving the one or more payments for offsetting one or more future exceeded account threshold payments includes receiving one or more premium payments for purchasing coverage to offset one or more future exceeded account threshold payments. In some of these embodiments, the method further includes: recording coverage information in a computer-readable medium based at least partially on the receiving the one or more premium payments, where the coverage information indicates that the account has coverage to offset one or more future exceeded account threshold payments. In some embodiments, the determining that the one or more payments are sufficient includes determining, based at least partially on the coverage information, that the account has coverage sufficient to offset the exceeded account threshold payment. Additionally or alternatively, in some embodiments, the authorizing the transaction includes authorizing the transaction based at least partially on the determining that the account has coverage sufficient to offset the exceeded account threshold payment.
In some embodiments, the coverage includes a predetermined coverage amount for offsetting one or more future exceeded account threshold payments, and the determining that the account has coverage sufficient to offset the exceeded account threshold payment includes determining that the amount of the exceeded account threshold payment is less than the predetermined coverage amount. Additionally or alternatively, in some embodiments, the coverage includes a predetermined coverage period for offsetting one or more future exceeded account threshold payments, and the determining that the account has coverage sufficient to offset the exceeded account threshold payment includes determining that the transaction occurs during the predetermined coverage period. In some embodiments, the coverage is sufficient to offset a predetermined number of future exceeded account threshold payments, and the determining that the account has coverage sufficient to offset the exceeded account threshold payment includes determining that the exceeded account threshold payment is within the predetermined number
In some embodiments of the method, the receiving one or more payments for offsetting one or more future exceeded account threshold payments includes receiving one or more payments for avoiding one or more future exceeded account threshold payments. In some of these embodiments, the determining that the one or more payments are sufficient to offset the exceeded account threshold payment includes determining that the one or more payments are sufficient to avoid the exceeded account threshold payment. In addition, in some of these embodiments, the authorizing the transaction includes authorizing the transaction based at least partially on the determining that the one or more payments are sufficient to avoid the exceeded account threshold payment.
However, in other embodiments of the method, the receiving one or more payments for offsetting one or more future exceeded account threshold payments includes receiving one or more payments for prepaying one or more future exceeded account threshold payments. In some of these embodiments, the determining that the one or more payments are sufficient to offset the exceeded account threshold payment includes determining that the one or more payments are sufficient to pay the exceeded account threshold payment. In addition, in some embodiments, the authorizing the transaction includes authorizing the transaction based at least partially on the determining that the one or more payments are sufficient to pay the exceeded account threshold payment.
Also, in some embodiments of the method, the receiving the one or more payments includes receiving the one or more payments from a first transaction machine. In some of these embodiments, the transaction involves a second transaction machine, and the second transaction machine is different than the first transaction machine and located remotely from the first transaction machine. In some embodiments of the method, the transaction is initiated at least one hour after the receiving the one or more payments. Additionally or alternatively, in some embodiments of the method, the transaction involves a holder of the account. In some of these embodiments, the method further includes prompting the holder to consent to using the one or more payments to offset the exceeded account threshold payment, where the prompting occurs after the determining that the account will incur the exceeded account threshold and before the authorizing the transaction.
As also described in more detail herein, other embodiments of the present invention provide an apparatus that includes a communication interface configured to: (a) receive one or more payments for offsetting one or more future exceeded account threshold payments, where the one or more payments are associated with an account; and (b) receive transaction information associated with a transaction, where the transaction involves the account, and where the transaction is initiated after the communication interface receives the one or more payments. In some of these embodiments, the apparatus also includes a processor operatively connected to the communication interface and configured to: (a) determine, based at least partially on the transaction information, that the account will incur an exceeded account threshold as a result of the transaction; (b) determine that the one or more payments are sufficient to offset an exceeded account threshold payment associated with the exceeded account threshold; and (c) authorize the transaction based at least partially on the processor determining that the one or more payments are sufficient.
Still other embodiments of the present invention provide a computer program product having a non-transitory computer-readable medium. In some of these embodiments, the non-transitory computer-readable medium includes one or more computer-executable program code portions that, when executed by a computer, cause the computer to: (a) receive one or more payments for offsetting one or more future exceeded account threshold payments, where the one or more payments are associated with an account; (b) receive transaction information associated with a transaction, where the transaction involves the account, and where the transaction is initiated after the computer receives the one or more payments; (c) determine, based at least partially on the transaction information, that the account will incur an exceeded account threshold as a result of the transaction; (d) determine that the one or more payments are sufficient to offset an exceeded account threshold payment associated with the exceeded account threshold; and (e) authorize the transaction based at least partially on the computer determining that the one or more payments are sufficient.
Other embodiments of the present invention provide a method that includes: (a) receiving a payment for prepaying a future exceeded account threshold payment, where the payment is associated with an account; (b) increasing an exceeded account threshold allocation associated with the account based at least partially on the receiving the payment; (c) determining, using a processor, that the account has incurred an exceeded account threshold payment as a result of a transaction, where the transaction was initiated after the receiving the payment; and (d) decreasing the exceeded account threshold allocation based at least partially on the determining that the account has incurred the exceeded account threshold payment.
In some embodiments of this method, the increasing the exceeded account threshold allocation includes increasing the exceeded account threshold allocation by the amount of the payment. Additionally or alternatively, in some embodiments, the decreasing the exceeded account threshold allocation includes decreasing the exceeded account threshold allocation by the amount of the exceeded account threshold payment. Also, in some embodiments of the method, the decreasing the exceeded account threshold allocation includes paying the exceeded account threshold payment. In some embodiments, the method further includes: (a) receiving a transaction history associated with the account; (b) determining a trend based at least partially on the transaction history, where the trend is based at least partially on the number of exceeded account threshold payments identified in the transaction history; and (c) prompting a holder of the account to increase the exceeded account threshold allocation based at least partially on the trend.
In some embodiments of the method, the transaction is completed before the determining that the account has incurred an exceeded account threshold payment as a result of the transaction. Additionally or alternatively, in some embodiments of the method, the transaction involves a holder of the account. In some of these embodiments, the method further includes prompting the holder to consent to using the exceeded account threshold allocation to offset the exceeded account threshold payment, where the prompting the holder occurs during the transaction.
Having thus described some embodiments of the present invention in general terms, reference will now be made to the accompanying drawings, wherein:
In general terms, embodiments of the present invention relate to methods and apparatuses for prepaying, covering, avoiding, negating, and/or otherwise offsetting (sometimes collectively referred to herein as “offsetting” for simplicity) future exceeded account threshold payments. As an example, in some embodiments, an account holder can prepay one or more future exceeded account threshold payments, so that if the account holder later engages in a transaction that results in an exceeded account threshold payment, that exceeded account threshold payment will be paid, covered, avoided, and/or otherwise offset. In other words, the account holder can offset an exceeded account threshold payment before a transaction that results in that exceeded account threshold payment is ever initiated.
In some cases, the account holder may have a financial incentive to prepay and/or otherwise offset future exceeded account threshold payments. For example, in some embodiments, a regular exceeded account threshold payment is $35 if paid after and/or at the time the exceeded account threshold payment is incurred, but the exceeded account threshold payment may be only $10 if paid in advance (i.e., paid before the holder engages in the transaction that results in the exceeded account threshold payment). There may also be other incentives for prepaying, covering, and/or otherwise offsetting future exceeded account threshold payments. For example, in some embodiments, when an account holder prepays one or more future exceeded account threshold payments, the account holder also consents to later incurring and/or offsetting those one or more future exceeded account threshold payments. As a result, the holder may not be required to provide this consent later (e.g., at the time of the exceeded account threshold transaction, and the like), which may spare the holder of any public embarrassment, annoyance, and/or hassle associated with providing the consent and/or being notified of the exceeded account threshold and/or exceeded account threshold payment.
As used herein, the phrase “exceeded account threshold payment” generally refers to the one or more payments typically associated with incurring an exceeded account threshold (e.g., surpassed balance, exceeded credit threshold amount, and the like). Thus, the phrase “future exceeded account threshold payment” generally refers to one or more exceeded account threshold payments associated with incurring a “future exceeded account threshold,” which itself results from a “future exceeded account threshold transaction.” As used herein, the phrase “future exceeded account threshold transaction” generally refers to a transaction that: (a) is initiated, performed, engaged in, completed, and/or otherwise occurs in the future; and (b) if completed, will result in an exceeded account threshold (i.e., the “future exceeded account threshold”). It will be understood that a future exceeded account threshold transaction refers to a potential transaction that has not yet occurred and may never occur; however, if the future exceeded account threshold transaction does occur, it will result in an exceeded account threshold.
Referring now to
For simplicity, the portion of the process flow 100 represented by block 130 is sometimes referred to herein as the “exceeded account threshold determination,” and that the portion represented by block 140 is sometimes referred to herein as the “sufficiency determination.” In addition, in some embodiments, the term “determine” is meant to have its one or more ordinary meanings (i.e., its one or more ordinary dictionary definitions), but in other embodiments, that term is additionally or alternatively meant to have the one or more ordinary meanings of one or more of the following terms: decide, conclude, verify, ascertain, find, discover, learn, calculate, observe, read, and/or the like. For example, in some embodiments, the apparatus having the process flow 100 is configured to make the exceeded account threshold determination by calculating, based at least partially on the transaction information and an available balance associated with the account, that the account will incur the exceeded account threshold as a result of the transaction.
Further, in some embodiments, the term “offset” is meant to have its one or more ordinary meanings, but in other embodiments, the term “offset” is additionally or alternatively meant to have the one or more ordinary meanings of one or more of the following terms: cover, counterbalance, pay, negate, avoid, and/or the like. For example, in some embodiments, the apparatus having the process flow 100 determines that the one or more payments are sufficient to offset the exceeded account threshold payment by determining that the one or more payments are sufficient to avoid the exceeded account threshold payment. As another example, in some embodiments, the apparatus determines that the one or more payments are sufficient to offset the exceeded account threshold payment by determining that the one or more payments were used to prepay the exceeded account threshold payment.
The apparatus having the process flow 100 illustrated in
Regarding block 110, the account referred to in the process flow 100 can include any number and/or type of account(s). For example, in some embodiments, the account includes a checking account, savings account, money market account, investment account, brokerage account, certificate of deposit account, and/or any other type of deposit account. In some embodiments, the deposit account is one or more accounts that can incur a surpassed balance and/or be discrepant. Of course, it will be understood that embodiments of the present invention may also apply to one or more credit accounts, such as a credit card account, line of credit (LOC) account, store credit account, and/or the like. Additionally or alternatively, in some embodiments, the credit account is one or more accounts that can incur an amount “exceeded credit threshold.” For example, if a credit account has a $5,000 maximum credit threshold and a $5,300 account balance, then it will be understood that the credit account has incurred an exceeded credit threshold amount of $300.
Also, it will be understood that the one or more payments referred to in block 110 are associated with the account referred to in block 110. In some embodiments, the one or more payments are associated with the account because the payments are paid into an exceeded account threshold allocation that is associated with the account. In other embodiments, the one or more payments are associated with the account because the payments are used to purchase one or more exceeded account threshold payment credits for the account. In still other embodiments, the one or more payments are associated with the account because the payments are used to purchase exceeded account threshold coverage for the account.
In some embodiments, the payments are associated with the account because the payments are sent by a holder of the account. Additionally or alternatively, in some embodiments, the payments are associated with the account because they are designated for the account (e.g., designated for prepaying exceeded account threshold payments incurred by the account, designated for an exceeded account threshold allocation associated with the account, marked with information that identifies the account, and the like). In some alternative embodiments, the apparatus having the process flow 100 is configured to designate the one or more payments for offsetting one or more future exceeded account threshold payments, where the apparatus is configured to designate the payments upon or after receiving them.
It will be understood that the one or more payments referred to in block 110 may not be limited for use with the account referred to in block 110. For example, in some embodiments, the one or more payments originate from a holder of the account who holds several other accounts, and the one or more payments may be used to offset one or more future exceeded account threshold payments associated with exceeded account threshold amounts incurred by any of the accounts held by the holder. However, in some embodiments, the one or more payments are associated with the account referred to in block 110 because they only can be used to offset future exceeded account threshold payments that result from future exceeded account threshold transactions involving the account.
Further regarding block 110, the apparatus having the process flow 100 can be configured to receive the one or more payments in any way. In some embodiments, the apparatus receives the one or more payments from a holder of the account (and/or some other person) via a transaction machine (e.g., the prepayment machine 620, a personal computer, a mobile phone, and the like). As used herein, the phrase “transaction machine” generally refers to an interactive computer terminal that is configured to initiate, perform, complete, and/or facilitate one or more transactions. Examples of transaction machines include, but are not limited to, automated teller machines (ATMs), point-of-sale (POS) devices (e.g., merchant terminals, and the like), self-service machines, public and/or business kiosks (e.g., an Internet kiosk, mass transit kiosk, ticketing kiosk, DVD vending kiosk, airline/train check-in kiosk, bill pay kiosk, and the like), parking meters, vending machines, self-checkout machines (e.g., at a grocery store, retail store, and the like), mobile phones (e.g., feature phones, smart phones, and the like), gaming devices, computers (e.g., personal computers, tablet computers, laptop computers, and the like), personal digital assistants (PDAs), and/or the like.
In some embodiments, the transaction machine used to submit the one or more payments referred to in block 110 (and/or the transaction machine involved in the transaction referred to in block 120) is located in a public place and is available for public use (e.g., on a street corner, on the exterior wall of a banking center, at a public rest stop, and the like). In other embodiments, the transaction machine is additionally or alternatively located in a place of business and available for public and/or business customer use (e.g., in a retail store, post office, banking center, grocery store, and the like). In accordance with some embodiments, the transaction machine is not owned by the user of the transaction machine and/or the holder of the account referred to in block 110. However, in other embodiments, the transaction machine is located in a private place, is available for private use, and/or is owned by the user of the transaction machine and/or the holder.
It will be understood that, in some embodiments, the transaction machine used to submit the one or more payments referred to in block 110 is the same type of transaction machine (and/or the very same transaction machine) involved in the transaction referred to in block 120. Also, it will be understood that, in some embodiments, the one or more payments referred to in block 110 are submitted using a prepayment application (e.g., the prepayment application 627, and the like) that executes on the transaction machine. For example, in some embodiments, the holder submits the one or more payments by using one or more input features displayed and/or otherwise provided in association with a mobile banking application that executes on a mobile phone.
Regarding block 120, the transaction can include any transaction involving a deposit account and/or credit account. Exemplary transactions include, but are not limited to: purchasing, renting, selling, and/or leasing one or more goods and/or services (e.g., merchandise, groceries, tickets, and the like); withdrawing cash; making deposits (e.g., checks, cash, and the like); making payments to creditors (e.g., paying bills, paying taxes, and the like); sending remittances; transferring funds; loading money onto stored value cards; and/or the like. The transaction information referred to in block 110 can be any information that identifies, defines, describes, and/or is otherwise associated with the transaction. Exemplary transaction information includes, but is not limited to, the party(ies) involved in the transaction, the date and/or time of the transaction, the posting date of the transaction, the account(s) involved in the transaction, the transaction amount(s) associated with the transaction, the good(s) and/or service(s) involved in the transaction (e.g., product names, stock keeping unit (SKU) information, universal product code (UPC) information, and the like), a description of the transaction (which, itself, can include any transaction information, e.g., the description may describe the transaction status, the goods and/or services involved in the transaction, and the like), and/or the like.
The transaction information can also include any information that defines and/or identifies the type of the transaction. As understood herein, the transaction type of a transaction may be defined, at least in part, by the one or more goods and/or services involved in the transaction, the one or more types of accounts involved in the transaction (e.g., credit card transaction, savings account transaction, and the like), the one or more parties involved in the transaction (e.g., account holder, bank, teller, merchant, counterparty, and the like), when the transaction was initiated (e.g., time of day, day of week, and the like), and/or the like. In some embodiments, the transaction type is defined, at least in part, by the one or more channels through which the transaction is conducted, such as, for example, a point-of-sale (POS) device (e.g., merchant terminal, and the like), ATM, teller terminal, electronic banking account (e.g., online banking account, mobile banking account, SMS banking account, and the like), personal computer, kiosk, call center, and/or the like. Additionally or alternatively, in some embodiments, the transaction type is defined, at least in part, by the one or more instruments and/or methods used to conduct the transaction, such as, for example, paper checks, electronic checks, debit cards, credit cards, ATM cards, checkcards, wire transfers, online bill pay, automated clearing house (ACH), contactless payments, near field communication (NFC) interface payments, cash payments, and/or the like. In some embodiments, the transaction information additionally or alternatively identifies and/or describes one or more merchant category codes (MCCs) associated with the transaction.
Also regarding block 120, the apparatus having the process flow 100 can be configured to receive the transaction information in any way. For example, in some embodiments, the apparatus is configured to receive an authorization request associated with the transaction, where the authorization request includes the transaction information. In some embodiments, the apparatus is embodied as an authorization apparatus (e.g., the authorization apparatus 630, and the like) maintained by a financial institution, where the apparatus is configured to approve and/or decline authorization requests for debit transactions, credit transactions, ATM transactions, POS device transactions, and/or one or more other types of transactions that involve one or more accounts maintained by the financial institution. Additionally or alternatively, the apparatus can be configured to receive the transaction information directly or indirectly from the source of the transaction. For example, in some embodiments, the apparatus is located remotely from the transaction machine involved in the transaction but is operatively connected to the transaction machine via a network. As another example, the apparatus may include, be included in, and/or be embodied as a transaction machine. For example, in some embodiments, the apparatus having the process flow 100 is the transaction machine involved in the transaction referred to in block 120.
Further regarding block 120, it will be understood that the apparatus having the process flow 100 receives the one or more payments referred to in block 110 before the transaction referred to in block 120 is initiated. Said differently, in some embodiments, the apparatus is configured to perform the portions represented by blocks 120-150 at some point after the apparatus performs the portion represented by block 110. In some cases, the apparatus is configured to perform these portions hours, days, and/or months after the apparatus receives the one or more payments. In some embodiments, the process flow 100 actually represents two separate transactions, where the first transaction is represented by block 110 and the second transaction is represented by blocks 120-150.
Regarding block 130, the term “exceeded account threshold” and/or “exceeded account threshold amount,” as used herein, generally refers to the difference between: (a) the total amount of one or more purchases, draws, payments, assessments, balance transfers, financial obligations, and/or other liabilities incurred, or that will be incurred, by an account as a result of a transaction, and (b) the total amount of funds and/or credit available to the account immediately prior to the transaction, where the total amount of the responsibilities exceeds the total amount of available credit and/or funds. In some embodiments, the exceeded account threshold is referred to as a “surpassed balance” if the account that incurs the exceeded account threshold, or will incur the exceeded account threshold, is a deposit account (e.g., checking account, savings account, brokerage account, and the like). For example, if a checking account has an available balance of $25 immediately before the checking account is used to pay a $50 electric bill, then the checking account will incur a $25 surpassed balance as a result of paying the bill. In some embodiments, the term “surpassed balance” refers to the amount by which the balance of an account is negative. For example, if a deposit account has an available balance of −$65, then the deposit account has one or more surpassed balances totaling $65. Additionally or alternatively, in some embodiments, the term “surpassed balance” refers to a situation where a deposit account is found to have unavailable funds to cover a transaction.
In some embodiments, the exceeded account threshold is referred to as “exceeding the credit threshold” and/or “incurring an exceeded credit threshold amount” if the account that incurs the exceeded account threshold or will incur the exceeded account threshold is a credit account (e.g., credit card account, line of credit (LOC) account, store credit account, and the like). For example, if a credit card account has $500 in available credit immediately prior to the credit card account being used to make a $600 purchase, then it will be understood that the credit card account will go over its maximum credit threshold by $100 as a result of the purchase. Additionally or alternatively, in some embodiments, the phrase “exceeded credit threshold amount” generally refers to the difference between an account balance for the credit account and a maximum credit threshold (sometimes referred to as “credit line”) associated with the credit account, where the account balance exceeds the maximum credit threshold. For example, if a credit account has a $5,000 maximum credit threshold and a $5,300 account balance, then it will be understood that the credit account has incurred one or more exceeded credit threshold amounts totaling $300.
In some embodiments, the transaction referred to in block 130 is a present, initiated, and/or pending transaction. For example, in some embodiments, the apparatus is configured to make the exceeded account threshold determination after the transaction has been initiated (e.g., at a POS device) but before the transaction has been completed. In addition, the apparatus can be configured to make the exceeded account threshold determination in any way. For example, in some embodiments, the apparatus is configured to make the exceeded account threshold determination by determining that the deposit account does not have sufficient available funds and/or credit to cover the transaction.
Additionally or alternatively, in some embodiments, the apparatus is an authorization apparatus (e.g., the authorization apparatus 630 referred to in
Regarding block 140, the apparatus can be configured to make the sufficiency determination in any way. In some embodiments, the apparatus is configured to determine that the one or more payments are sufficient by determining that an exceeded account threshold allocation associated with the account is sufficient to offset the exceeded account threshold payment. For example, in some embodiments, the exceeded account threshold allocation has a balance, and the apparatus is configured to make the sufficiency determination by determining that the amount of the exceeded account threshold payment is less than the amount of the exceeded account threshold allocation. As another example, in some embodiments, the exceeded account threshold allocation has a number of exceeded account threshold payment credits (i.e., a credit that can be used to pay, cover, avoid, and/or otherwise offset an exceeded account threshold payment), and the apparatus is configured to make the sufficiency determination by determining that the exceeded account threshold allocation has at least one exceeded account threshold payment credit. It will be understood that, in some embodiments, one or more portions of the exceeded account threshold allocation may expire. For example, in some embodiments, an exceeded account threshold payment credit expires after one year if the credit is not used. In other embodiments, as described in more detail in connection with
It will be understood that, in some embodiments, the exceeded account threshold allocation (and/or the one or more payments) associated with the account is separate from, and therefore does not comprise any portion of, the balance of the account. In other words, in some embodiments, the account balance cannot serve as the exceeded account threshold allocation or vice versa. Accordingly, in such embodiments, the exceeded account threshold allocation is essentially treated as an “account” that is separate from the account referred to in block 110. Also, it will be understood that, in some embodiments, the future exceeded account threshold payment referred to in block 110 is the exceeded account threshold payment referred to in block 140.
Regarding block 150, the apparatus can be configured to authorize the transaction in any way. For example, in some embodiments, the apparatus is configured to send, to the transaction machine referred to in the process flow 100, one or more instructions to complete the transaction. In some embodiments, the apparatus is configured to authorize the transaction by approving an authorization request associated with the transaction. In some embodiments, the authorization request approved by the apparatus having the process flow 100 was included in the transaction information referred to in block 110.
The apparatus having the process flow 100 can be configured to perform any portion of the process flow 100 represented by blocks 110-150 upon or after one or more triggering events (which, in some embodiments, is one or more of the other portions of the process flow 100). As used herein, a “triggering event” refers to an event that automatically (i.e., without human intervention) triggers the execution, performance, and/or implementation of a triggered action, either immediately, nearly immediately, or sometime after (e.g., within minutes, hours, and the like) the occurrence of the triggering event. For example, in some embodiments, the apparatus having the process flow 100 is configured such that the apparatus making the sufficiency determination (the triggering event) automatically and immediately or nearly immediately triggers the apparatus to authorize the transaction (the triggered action).
In accordance with some embodiments, the apparatus can be configured to automatically perform one or more of the portions represented by blocks 110-150, whereas in other embodiments, one or more of the portions of the process flow 100 require and/or involve human intervention (e.g., a user operating the apparatus configured to perform the process flow 100, and the like). In addition, it will be understood that, in some embodiments, the apparatus (and/or a user thereof) is configured to perform one or more portions of the process flow 100, from start to finish, within moments, seconds, and/or minutes (e.g., within approximately 1-15 minutes from start to finish, and the like). As an example, in some embodiments, the apparatus is configured to authorize the transaction within moments, seconds, and/or minutes (e.g., within approximately 1-15 minutes, and the like) of: (a) receiving the transaction information associated with the transaction; (b) making the exceeded account threshold determination; and/or (c) making the sufficiency determination. As another example, in some embodiments, the apparatus having the process flow 100 is configured to authorize the transaction while the holder of the account is still at and/or near the transaction machine involved in the transaction referred to in block 120.
In some embodiments, the apparatus having the process flow 100 is configured to implement an exceeded account threshold service. As used herein, the phrase “exceeded account threshold service” generally refers to a service that provides an account holder with the funds and/or credit necessary to complete an exceeded account threshold transaction. As used herein, the phrases “exceeded account threshold service” and “service for exceeding account thresholds” may be used interchangeably. For example, in some embodiments, where a transaction, if completed, would surpass the balance of a checking account by $10, the exceeded account threshold service can provide the checking account with the $10 needed to complete the transaction. As another example, in some embodiments, the exceeded account threshold service enables an account holder to consent to and/or prepay one or more future exceeded account threshold payments prior to engaging in one or more future exceeded account threshold transactions.
The exceeded account threshold service includes one or more terms, which define the one or more rights, responsibilities, privileges, payments, features, and/or obligations of the exceeded account threshold service. For example, in some embodiments, the one or more terms of the exceeded account threshold service describe how the exceeded account threshold service works; identify the exceeded account threshold service provider; define what constitutes an exceeded account threshold; identify the one or more exceeded account threshold payments assessed for enrolling in the exceeded account threshold service, for participating in the exceeded account threshold service, and/or for engaging in an exceeded account threshold transaction; and/or the like. In some embodiments, the exceeded account threshold service is provided by a financial institution, such as a bank, and not by an account held by and/or otherwise associated with the holder. For example, in some embodiments, the exceeded account threshold service is provided by the same financial institution that maintains the apparatus having the process flow 100 and/or the account that incurs, or will incur, the exceeded account threshold.
It will be understood that, in some embodiments, the exceeded account threshold service (and/or the exceeded account threshold service provider) is regulated in the United States by the Electronic Funds Transfer Act, also known as Federal Reserve Board Regulation E (hereinafter “Regulation E”). In other embodiments, the exceeded account threshold service (and/or exceeded account threshold service provider) is regulated in the United States by the Credit Card Accountability Responsibility and Disclosure Act of 2009, which is codified in the United States as Public Law No. 111-24 (sometimes referred to herein, for simplicity, as the “Credit CARD Act of 2009” or the “CARD Act”). In some embodiments, the exceeded account threshold service does not contractually obligate the exceeded account threshold service provider to cover account discrepancies. In other words, in such embodiments, the exceeded account threshold service provider may choose to cover surpassed balance and/or exceeded credit threshold transactions at its discretion. However, in other embodiments, the exceeded account threshold service provider is contractually obligated to cover exceeded account thresholds incurred by an account.
In some embodiments, one or more portions of the process flow 100 may be configured to comply with one or more portions of a law, rule, and/or regulation that is directed to and/or otherwise relates to an exceeded account threshold (collectively referred to herein as “exceeded account threshold regulation” for simplicity). For example, in the United States, Regulation E regulates surpassed balance services provided by financial institutions. Accordingly, it will be understood that some embodiments of the present invention enable a financial institution to comply with Regulation E, the CARD Act, and/or one or more other exceeded account threshold regulations. For example, in some embodiments, the receiving the one or more payments for offsetting one or more future exceeded account threshold payments may comply with one or more notification, consent, opt-in, and/or revocation requirements of an exceeded account threshold regulation. In some embodiments, as required by one or more exceeded account threshold regulations, the holder must opt into and/or otherwise enroll in the exceeded account threshold service before the holder can participate in and/or otherwise use the exceeded account threshold service. As such, in some embodiments, the apparatus having the process flow 100 can be configured to prompt the account holder to consent to, accept, and/or agree to one or more terms of an exceeded account threshold service. Also, it will be understood that the exceeded account threshold service is sometimes referred to herein as a surpassed balance service if the account participating in the service is a deposit account. Also, the exceeded account threshold service is sometimes referred to herein as an exceeded credit threshold service if the account participating in the service is a credit account.
It will also be understood that the apparatus having the process flow 100 can be configured to perform any one or more portions of any embodiment described and/or contemplated herein, including, for example, any one or more portions of the process flows 200, 300, 400, and/or 500 described later herein. Also, the number, order, and/or content of the portions of the process flow 100 are exemplary and may vary. In addition, the process flow 100 can include one or more additional and/or alternative portions. For example, in some alternative embodiments of the process flow 100, the apparatus having the process flow 100 is configured to: (a) determine that the account has incurred an exceeded account threshold payment as a result of the transaction (i.e., make an “exceeded account threshold payment determination”); and (b) decrease an exceeded account threshold allocation associated with the account based at least partially on making the exceeded account threshold payment determination. In some of these embodiments, the apparatus is configured to perform one or both of these functions after the transaction has occurred and/or been completed.
As another example, in some alternative embodiments, the apparatus having the process flow 100 is configured to pay, cover, and/or otherwise offset the exceeded account threshold payment. In some of these embodiments, the apparatus is configured to perform this function simultaneous with, after, and/or based at least partially on the apparatus making the exceeded account threshold determination, making the sufficiency determination, and/or authorizing the transaction. In some embodiments, the apparatus is configured to offset the exceeded account threshold payment using an exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage associated with the account. In some of these embodiments, the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage is used to offset the exceeded account threshold payment but not the exceeded account threshold itself. For example, if an account incurs an $100 surpassed balance and an associated $35 surpassed balance payment, the apparatus having the process flow 100 may be configured to pay the $35 surpassed balance payment with funds from an surpassed balance allocation associated with the account, but the apparatus will not use funds from the surpassed balance allocation to pay the $100 surpassed balance. It will be understood that this limitation may be imposed by one or more exceeded account threshold regulations.
As another example, in some alternative embodiments, the apparatus having the process flow 100 is configured to prompt the user of the transaction machine (e.g., the holder of the account referred to in block 110) to consent to using the one or more payments (and/or the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage) to offset the exceeded account threshold payment referred to in block 140. In some embodiments, the apparatus is configured to prompt the user sometime after the apparatus receives the transaction information, as represented by block 120, and/or sometime before the apparatus authorizes the transaction, as represented by block 150. For example, in some embodiments, the apparatus is configured to prompt the user to consent during the transaction referred to in block 120. As another example, in some embodiments, the apparatus is configured to prompt the user to consent to using the one or more payments (and/or the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage) to offset the exceeded account threshold payment after the apparatus determines that the account will incur the exceeded account threshold.
Also, it will be understood that the apparatus can be configured to prompt the user in any way and/or the user may give his consent (and/or decline to give his consent) in any way. For example, in some embodiments, while the user is at the transaction machine involved in the transaction referred to in block 120, the apparatus having the process flow 100 sends a communication (e.g., text message, email, phone call, and the like) to the user's mobile device (e.g., mobile phone, portable gaming device, and the like) that notifies the user of the exceeded account threshold and/or the exceeded account threshold payment. That same communication may additionally or alternatively prompt the user to consent to using the one or more payments (and/or the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage) to offset the exceeded account threshold payment. In such embodiments, the user may provide his consent by sending a return communication to the apparatus that indicates his consent. Of course, the user may also be able indicate, via the return communication, that the user does not consent to using the one or more payments (and/or the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage) to offset the exceeded account threshold payment. In some embodiments, the apparatus automatically determines that the user does not consent if the user does not respond to the first communication within a predetermined period of time (e.g., 30 seconds, 5 minutes, and the like).
In other embodiments, the apparatus is configured to prompt the user to consent (and/or to receive the user's consent) via a transaction machine associated with the transaction referred to in block 120 (e.g., via a user interface associated with the transaction machine). It will be understood that the user may be prompted to consent to using the one or more payments via a first channel (e.g., a mobile phone, and the like) and then provide his consent to using the one or more payments via a second channel (e.g., the transaction machine, and the like). It will also be understood that the apparatus may be configured to authorize the transaction based at least partially on the apparatus receiving the user's consent to using the one or more payments (and/or the exceeded account threshold allocation, exceeded account threshold payment credit, and/or coverage) to offset the exceeded account threshold payment.
Of course, the apparatus having the process flow 100 can be configured to prompt the holder via any communication device and/or medium, such as, for example, a personal computer, mobile phone, ATM, POS device, online banking account, email account, social media network, and/or the like. In some embodiments, the prompting the holder may include sending and/or presenting, to the user and/or holder, one or more questions, instructions, requests, messages, graphics, sounds, telephone calls, text messages, SMS messages (e.g., traditional SMS messages, 2-way SMS messages, and the like), actionable alerts, instant messages, voice messages, voice recordings, interactive voice response (IVR) communications, pages, emails, communications specific to one or more social media networks and/or applications, user interfaces (e.g., dashboard screens, web pages, and the like) and/or the like. For example, in some embodiments, the apparatus having the process flow 100 sends a text message to the holder's mobile phone that notifies the holder of the exceeded account threshold, notifies the holder of the exceeded account threshold payment, and/or prompts the holder to consent to the exceeded account threshold and/or exceeded account threshold payment by return text message, all during the transaction and/or while the holder is still standing at the transaction machine.
Referring now to
As represented by block 205, the bank customer submits a payment for offsetting a future exceeded account threshold payment. For example, in some embodiments, the customer uses an online banking account to transfer money from an account held by the customer to an exceeded account threshold allocation. As a result of submitting the payment, the bank increases the exceeded account threshold allocation associated with the customer's account, as represented by block 210. It will be understood that, in some embodiments, the portions of the process flow 200 represented by blocks 205 and 210 occur before one or more (or all) of the other portions of the process flow 200. For example, in some embodiments, the customer submits the payment for offsetting a future exceeded account threshold payment, as represented by block 205, seconds, minutes, hours, and/or days before the customer approaches the transaction machine referred to in block 215.
Sometime after submitting the payment, the customer approaches the transaction machine for the purpose of engaging in a transaction using the transaction machine, as represented by block 215. In some embodiments, this transaction begins when the customer approaches the transaction machine for engaging in the transaction, as represented by block 215, and ends when the customer leaves the transaction machine, as represented by block 255. After arriving at the transaction machine, the customer presents account information at the transaction machine, as represented by block 220. For example, in some embodiments where the transaction machine is a POS device, the customer may swipe a debit and/or credit card associated with the account through the POS device in order to communicate account information associated with the account to the POS device and/or the apparatus having the process flow 200. As another example, in some embodiments where the transaction machine is a personal computer, the customer may input account information into a web page associated with the transaction that is displayed at the personal computer. After the account information is presented, the transaction machine (and/or the apparatus having the process flow 200) identifies and/or authenticates the customer, as represented by block 225. In some embodiments, the transaction machine authenticates the customer based at least partially on one or more credentials (e.g., username/password, PIN, checkcard, and the like) the customer presents to the transaction machine.
After being authenticated, the customer selects the transaction and/or agrees to the transaction amount, as represented by block 230. Then, as represented by block 235, the transaction machine sends an authorization request to the apparatus having the process flow 200, where the authorization request identifies and/or describes the transaction, the customer, the account, and/or the like. After receiving the authorization request, the apparatus having the process flow 200 must determine whether the account has sufficient available funds and/or credit to cover the transaction, as represented by block 240. In other words, the apparatus having the process flow 200 is configured to determine whether the account will incur an exceeded account threshold as a result of the transaction. If the account will not incur an exceeded account threshold, then the apparatus, as represented by blocks 245 and 250, approves the authorization request and/or instructs the transaction machine to complete the transaction. After the transaction is completed at the transaction machine, the customer leaves the transaction machine, as represented by block 255.
However, if the apparatus having the process flow 200 determines that the account will incur an exceeded account threshold as a result of the transaction (i.e., the account does not have sufficient available funds and/or credit to cover the transaction), then the apparatus is configured to determine whether the customer's exceeded account threshold allocation is sufficient to offset the exceeded account threshold payment associated with the exceeded account threshold, as represented by block 260. For example, in some embodiments, the apparatus is configured to make the sufficiency determination by determining whether the amount of the exceeded account threshold payment is less than the amount of the exceeded account threshold allocation. As another example, in some embodiments, the exceeded account threshold allocation has a number of exceeded account threshold payment credits, and the apparatus is configured to make the sufficiency determination by determining whether the exceeded account threshold allocation has at least one exceeded account threshold payment credit.
If the exceeded account threshold allocation is not sufficient, then the apparatus and/or the bank may be required, by one or more exceeded account threshold regulations, to obtain the customer's consent to incur the exceeded account threshold and/or the exceeded account threshold payment before the apparatus and/or the bank approves the authorization request. As such, the apparatus having the process flow 200 (and/or the transaction machine) is configured prompt the customer to consent to the exceeded account threshold payment and/or the exceeded account threshold, as represented by block 265. Thereafter, the apparatus is configured to determine whether the customer consents to incurring the exceeded account threshold and/or the exceeded account threshold payment, as represented by block 270. If the customer does not consent to the exceeded account threshold payment and/or the exceeded account threshold, then the apparatus is configured to decline the transaction, as represented by block 275. However, if the customer does consent to the exceeded account threshold payment and/or the exceeded account threshold, then the apparatus approves the authorization request and the transaction is completed, as represented by blocks 245-255. In some embodiments, the apparatus is additionally configured to store the customer's consent in a datastore (e.g., computer-readable memory, and the like), which, in some embodiments, complies with one or more requirements of an exceeded account threshold regulation.
Referring again to block 265, it will be understood that the customer may be prompted to consent in any way and/or the customer may give his consent in any way. For example, in some embodiments, while the customer is at the transaction machine, the apparatus having the process flow 200 sends a text message to the customer's mobile phone that notifies the customer of the exceeded account threshold payment and prompts the customer to consent to incurring the exceeded account threshold payment by return text message. In other embodiments, the customer consents to the exceeded account threshold payment by using one or more input features displayed and/or otherwise provided in association with a mobile banking application that executes on the customer's mobile phone. In still other embodiments, the customer is prompted to consent and/or consents to the exceeded account threshold payment via the transaction machine referred to in block 215 (e.g., via a user interface associated with the transaction machine, and the like). It will be understood that the customer may be prompted to consent to the exceeded account threshold payment via a first channel (e.g., a mobile phone, and the like) and then provide his consent to the exceeded account threshold payment via a second channel (e.g., the transaction machine, and the like).
As another example, in some embodiments, the customer consents to the exceeded account threshold payment by presenting (or re-presenting) account information to the transaction machine after being prompted to consent to the exceeded account threshold payment. Specifically, in some embodiments where the transaction machine is a POS device, the apparatus having the process flow 100 is configured to prompt the customer to consent to the exceeded account threshold payment by re-swiping a debit or credit card through the POS device. If the customer then re-swipes the debit or credit card through the POS device, then the apparatus determines that the customer has consented to the exceeded account threshold payment.
Referring again to block 260, if the apparatus having the process flow 200 determines that the exceeded account threshold allocation is sufficient to offset the exceeded account threshold payment, then the apparatus is configured to prompt the customer to consent to using the exceeded account threshold allocation (e.g., the balance of the exceeded account threshold allocation, an exceeded account threshold payment credit in the exceeded account threshold allocation, and the like) to offset the exceeded account threshold payment associated with the exceeded account threshold, as represented by block 280. In other words, the apparatus is configured to prompt the customer to consent to using the exceeded account threshold allocation for this particular transaction. As with the prompting referred to in block 265, the apparatus having the process flow 200 can be configured to prompt the customer to consent to using the exceeded account threshold allocation in any way and the customer can consent to using the exceeded account threshold allocation in any way. For example, in some embodiments, while the customer is at the transaction machine, the apparatus having the process flow 200 sends a communication to the customer's mobile phone (and/or to the transaction machine) that notifies the customer of the exceeded account threshold payment, notifies the customer of the balance of the exceeded account threshold allocation, and/or prompts the customer to consent to using the balance of the exceeded account threshold allocation to offset the exceeded account threshold payment. As another example, in some embodiments, while the customer is at the transaction machine, the apparatus having the process flow 200 (and/or the transaction machine) presents a user interface at the transaction machine that notifies the customer of the exceeded account threshold payment, notifies the customer of the balance of the exceeded account threshold allocation, and/or prompts the customer to consent to using the balance of the exceeded account threshold allocation to offset the exceeded account threshold payment.
After prompting the customer, the apparatus is configured to determine whether the customer consents to using the exceeded account threshold allocation to offset the exceeded account threshold payment, as represented by block 285. If the customer indicates (e.g., via return communication) that the customer does not consent, then the apparatus is configured to decline the transaction, as represented by block 275. For example, in some cases, the customer may indicate to the apparatus that the customer does not consent to using the exceeded account threshold allocation for this transaction because the customer may wish to use the exceeded account threshold allocation to offset another (and/or future) exceeded account threshold payment (i.e., not the exceeded account threshold payment referred to in block 260). However, if the customer indicates that the customer does consent to using the exceeded account threshold allocation for this transaction to offset the exceeded account threshold payment, then the apparatus decreases the exceeded account threshold allocation, as represented by block 290, and approves the authorization request, as represented by block 245. Again, it will be understood that the customer may indicate his consent to using the exceeded account threshold allocation in any way. Also, it will be understood that, in this example embodiment, the apparatus is configured to assume that the customer would not consent to incurring the exceeded account threshold and/or exceeded account threshold payment if the customer does not consent to using the exceeded account threshold allocation to offset the exceeded account threshold payment; however, in other embodiments, the apparatus may be configured to prompt the customer to consent to incurring the exceeded account threshold payment and/or the exceeded account threshold, even if the customer does not consent to using the exceeded account threshold allocation to offset the exceeded account threshold payment.
In accordance with some embodiments, one or more portions of the process flow 200 may comply with one or more requirements of an exceeded account threshold regulation (e.g., Regulation E and/or the CARD Act in the United States, and the like). For example, in some embodiments, receiving the customer's consent to the exceeded account threshold and/or exceeded account threshold payment, as represented by the “Yes” arrow between blocks 270 and 245 may comply with one or more requirements of an exceeded account threshold regulation. In addition, in some embodiments, the receiving the customer's consent may comply with one or more exceeded account threshold regulation requirements because, for example, the customer was first authenticated by the transaction machine and/or by the apparatus having the process flow 200. As another example, in some embodiments, the customer submitting the payment for offsetting a future exceeded account threshold payment may satisfy one or more consent and/or notification requirements of an exceeded account threshold regulation because, for example, the customer may be deemed to have consented to incurring a future exceeded account threshold and/or future exceeded account threshold payment by submitting the payment.
Of course, it will also be understood that the embodiment illustrated in
It will be understood that the apparatus having the process flow 200 can be configured to perform one or more portions of the process flow 200 in real time, in substantially real time, and/or at one or more predetermined times. The apparatus having the process flow 200 may additionally or alternatively be configured to perform any of the portions of the process flow 200 represented by blocks 205-290 upon or after one or more triggering events (which, in some embodiments, is the performance of one or more of the other portions of the process flow 200). In addition, in some embodiments, the apparatus having the process flow 200 (and/or a user thereof) is configured to perform one or more portions of the process flow 200, from start to finish, within moments, seconds, and/or minutes (e.g., within approximately 1-15 minutes, and the like).
Referring now to
As represented by block 330, the apparatus having the process flow 300 is also configured to receive transaction information associated with a transaction, where the transaction involves the account, and where the transaction is initiated after the receiving the one or more premium payments. Like the process flow 100, the apparatus is also configured to determine, based at least partially on the transaction information, that the account will incur an exceeded account threshold as a result of the transaction, as represented by block 130 of the process flow 300. In addition, as represented by block 340, the apparatus is configured to determine, based at least partially on the coverage information, that the account has coverage sufficient to offset an exceeded account threshold payment associated with the exceeded account threshold. As represented by block 350, the apparatus is configured to authorize the transaction based at least partially on the apparatus determining that the account has coverage sufficient to offset the exceeded account threshold payment.
In some embodiments, the coverage referred to in block 320 is similar to insurance coverage. For example, in some embodiments, the coverage includes a predetermined coverage amount for offsetting one or more future exceeded account threshold payments. In such embodiments, the apparatus may be configured to determine that the account has coverage sufficient to offset the exceeded account threshold payment by determining that the amount of the exceeded account threshold payment is less than the predetermined coverage amount. As another example, in some embodiments, the coverage includes a predetermined coverage period for offsetting one or more future exceeded account threshold payments. In such embodiments, the apparatus may be configured to determine that the account has coverage sufficient to offset the exceeded account threshold payment by determining that the transaction occurs during the predetermined coverage period. As yet another example, in some embodiments, the coverage is sufficient to offset a predetermined number of future exceeded account threshold payments. In such embodiments, the apparatus having the process flow 300 may be configured to determine that the account has coverage sufficient to offset the exceeded account threshold payment by determining that the exceeded account threshold payment is within the predetermined number. Also, it will be understood that, in some embodiments, the account has coverage to offset one or more future exceeded account threshold payments because a holder of the account has coverage to offset one or more future exceeded account threshold payments. In other words, in some embodiments, the account holder may have coverage that extends to one or more other accounts held by the account holder. However, in other embodiments, the coverage referred to in block 310 is uniquely associated with the account referred to in block 310.
Referring now to
Regarding block 410, the phrase “transaction history,” as used herein, typically refers to any of the information associated with any one or more individual transactions in which an account has been involved, such as, for example, the description of the goods/services involved in the transaction, the transaction date, the posting date, the type of transaction (e.g., purchase, deposit, credit, debit, draw, and the like), the transaction amount, the names of the merchants and/or counterparties involved in the transaction, the locations of the merchants and/or counterparties involved in the transaction, and/or any other transaction information. It will be understood that the transaction history contemplated herein includes the information typically provided to the account holder in a periodic (e.g., monthly) account statement and/or via an electronic banking account (e.g., online banking account, mobile banking account, and the like). Transaction history information may also include any information associated with one or more exceeded account threshold transactions and/or exceeded account threshold payments.
Regarding block 420, the term “trend,” as used herein, typically refers to one or more earning, spending, credit, debit, and/or other behaviors, tendencies, and/or patterns evidenced by the transaction history. For example, in some embodiments, the apparatus having the process flow 400 is configured to determine that the account has incurred two or more exceeded account threshold payments each month for the previous three months. Based at least partially on this information, the apparatus may determine that this is a trend associated with the account. In such embodiments, the apparatus may be further configured to prompt the account holder to submit as many payments as necessary to offset at least two exceeded account threshold payments each month.
In some embodiments, the apparatus having the process flow 400 is configured to determine a trend based at least partially on information associated with two or more transactions described in the transaction history. However, in other embodiments, the apparatus is configured to determine a trend based only on one transaction from the transaction history. For example, in some embodiments, the apparatus having the process flow 400 is configured to prompt the holder based solely on the amount and timing of a single exceeded account threshold payment incurred during a previous month. In some embodiments, the apparatus having the process flow 400 is configured to determine the trend as a result of implementing an algorithm to analyze the transaction history. Additionally or alternatively, in some embodiments, the apparatus is configured to determine the trend by projecting one or more funding shortfalls based at least partially on the transaction history.
Regarding block 430, the apparatus having the process flow 400 can be configured to prompt the holder via any communication device and/or medium, such as, for example, a personal computer, mobile phone, ATM, online banking account, email account, social media network, and/or the like. In some embodiments, the prompting the holder includes sending and/or presenting one or more questions, instructions, requests, messages, graphics, sounds, telephone calls, emails, text messages, SMS messages (e.g., traditional SMS messages, 2-way SMS messages, and the like), actionable alerts, instant messages, voice messages, voice recordings, interactive voice response (IVR) communications, pages, emails, communications specific to one or more social media networks and/or applications, and/or the like. For example, in some embodiments, the apparatus having the process flow 400 sends a text message to the account holder's mobile phone that notifies the holder of the trend and/or prompts the holder to submit one or more payments (e.g., using the mobile phone and/or a mobile banking application, and the like) in response. As another example, in some embodiments, the apparatus sends a web page to a personal computer that can be rendered at the personal computer to display an input feature (e.g., digital selectable button, link, drop down menu, and the like) that invites the holder to use the input feature to submit the one or more payments.
In some embodiments, the holder requests the prompting, but in other embodiments, the holder receives an unsolicited prompt. In other words, the prompting may include one or more “push” and/or “pull” communications delivered to the holder via a transaction machine (e.g., the prepayment machine 620, and the like). Also, in some embodiments, the apparatus having the process flow 400 is configured to communicate with the holder, via the transaction machine, by using pre-recorded and/or dynamically generated video and/or audio (e.g., which may include one or more menu options, and the like) in order to further communicate with the holder and/or direct the holder how to proceed. In addition to prompting, in some embodiments, the apparatus is also configured to present to the holder information that identifies the amount of an exceeded account threshold payment, the payment amount required to offset a future exceeded account threshold payment, the available balance and/or available credit for the account, and/or the like. It will be understood that the information associated with the exceeded account threshold payment may be presented to the holder at the same time as the apparatus prompts the holder to submit the one or more payments.
Referring now to
Referring now to
As shown in
The prepayment machine 620 can include any apparatus described and/or contemplated herein. In addition, the prepayment machine 620 can initiate, execute, complete, and/or otherwise facilitate any one or more portions of any embodiment described and/or contemplated herein. In some embodiments, the prepayment machine 620 includes one or more personal computers, ATMs, POS devices, gaming devices, mobile phones, modules, front end systems, network devices, and/or the like. Thus, it will be understood that, in some embodiments, the prepayment machine 620 is the same type of machine as the personal computer 601, the POS device 603, and/or the ATM 604. (In some alternative embodiments, the prepayment machine 620 is the personal computer 601, the POS device 603, and/or the ATM 604.) As illustrated in
Each communication interface described herein, including the communication interface 622, generally includes hardware, and, in some instances, software, that enables a portion of the system 600, such as the prepayment machine 620, to send, receive, and/or otherwise communicate information to and/or from the communication interface of one or more other portions of the system 600. For example, the communication interface 622 of the prepayment machine 620 may include a modem, network interface controller (NIC), near field communication (NFC) interface, network adapter, network interface card, and/or some other electronic communication device that operatively connects the prepayment machine 620 to another portion of the system 600, such as, for example, the authorization apparatus 630.
Each processor described herein, including the processor 624, generally includes circuitry for implementing the audio, visual, and/or logic functions of that portion of the system 600. For example, the processor may include a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. Control and signal processing functions of the system in which the processor resides may be allocated between these devices according to their respective capabilities. The processor may also include functionality to operate one or more software programs based at least partially on computer-executable program code portions thereof, which may be stored, for example, in a memory device, such as in the prepayment application 627 of the memory 626 of the prepayment machine 620.
Each memory device described herein, including the memory 626 for storing the prepayment application 627 and other information, may include any computer-readable medium. For example, the memory may include volatile memory, such as volatile random access memory (RAM) having a cache area for the temporary storage of data. Memory may also include non-volatile memory, which may be embedded and/or may be removable. The non-volatile memory may additionally or alternatively include an EEPROM, flash memory, and/or the like. The memory may store any one or more of portions of information used by the apparatus in which it resides to implement the functions of that apparatus. The memory may be transitory and/or non-transitory.
As shown in
For example, in some embodiments, the prepayment application 627 is executable to receive one or more payments for offsetting one or more future exceeded account threshold payments. As another example, in some embodiments, the prepayment application 627 is executable to receive transaction information associated with a transaction. As another example, in some embodiments, the prepayment application 627 is executable to increase and/or decrease an exceeded account threshold allocation (e.g., the exceeded account threshold allocation 642) associated with an account. As still another example, in some embodiments, the prepayment application 627 is executable to prompt a user (e.g., the holder 608) to consent to an exceeded account threshold payment and/or an exceeded account threshold. As another example, in some embodiments, the prepayment application 627 is executable to prompt the account holder 608 to consent to an exceeded account threshold, to an exceeded account threshold payment, and/or to using the exceeded account threshold allocation 642 and/or the coverage 644 to offset an exceeded account threshold payment associated with an exceeded account threshold transaction. As another example, in some embodiments, the prepayment application 627 is executable to receive one or more premium payments for purchasing coverage (e.g., the coverage 644) to offset one or more future exceeded account threshold payments. As another example, in some embodiments, the prepayment application 627 is executable to record coverage information in a computer-readable medium, where the coverage information indicates that the account has coverage to offset one or more future exceeded account threshold payments.
As another example, in some embodiments, the prepayment application 627 is executable to determine a trend based at least partially on a transaction history associated with an account (e.g., the account 640). As another example, in some embodiments, the prepayment application 627 is executable to prompt a holder of an account to submit one or more payments for offsetting one or more future exceeded account threshold payments. As a further example, in some embodiments, the prepayment application 627 is executable to determine that an exceeded account threshold allocation has fallen below a predetermined threshold. As another example, in some embodiments, the prepayment application 627 is executable to prompt a holder to increase an exceeded account threshold allocation.
In some embodiments, where the prepayment machine 620 includes and/or is embodied as an ATM, the prepayment application 627 is configured to execute on the ATM in order to initiate, perform, complete, and/or facilitate, for example, one or more cash withdrawals, deposits, and/or the like. In other embodiments, where the prepayment machine 620 includes and/or is embodied as a POS device, the prepayment application 627 is configured to execute on the POS device in order to initiate, perform, complete, and/or facilitate, for example, one or more debit card and/or credit card transactions. In still other embodiments, where the prepayment machine 620 includes and/or is embodied as a personal computer, the prepayment application 627 is configured to execute on the personal computer, and, in some embodiments, the prepayment application 627 is embodied as a web browser (i.e., for navigating the Internet, and the like) that is operable to initiate, perform, complete, and/or otherwise facilitate one or more transactions (e.g., submitting payments for offsetting future exceeded account threshold payments).
In some embodiments, the prepayment application 627 is executable to enable the holder 608 and/or prepayment machine 620 to communicate with one or more other portions of the system 600, and/or vice versa. In some embodiments, the prepayment application 627 is additionally or alternatively executable to initiate, perform, complete, and/or otherwise facilitate one or more financial and/or non-financial transactions. In some embodiments, the prepayment application 627 includes one or more computer-executable program code portions for causing and/or instructing the processor 624 to perform one or more of the functions of the prepayment application 627 and/or prepayment machine 620 described and/or contemplated herein. In some embodiments, the prepayment application 627 includes and/or uses one or more network and/or system communication protocols.
In some embodiments, the prepayment machine 620 and/or prepayment application 627 (and/or one or more other portions of the system 600) requires its users to authenticate themselves to the prepayment machine 620 and/or prepayment application 627 before the prepayment machine 620 and/or prepayment application 627 will perform one or more functions. For example, in some embodiments, the prepayment machine 620 (and/or the prepayment application 627) is configured to authenticate a user based at least partially on an ATM/debit/credit card, loyalty/rewards/club card, smart card, token (e.g., USB token, and the like), username/password, personal identification number (PIN), biometric information, and/or one or more other credentials that the user presents to the prepayment application 627. Additionally or alternatively, in some embodiments, the prepayment application 627 is configured to authenticate a user by using one-, two-, or multi-factor authentication. For example, in some embodiments, the prepayment application 627 requires two-factor authentication, such that the holder 608 must provide a valid debit card and enter the correct PIN associated with the debit card in order to authenticate the holder 608 to the prepayment application 627.
As shown in
The authorization application 637 may instruct and/or cause the processor 634 (and/or the authorization apparatus 630) to execute any one or more of the functions described herein as being performed by “an apparatus,” by the authorization apparatus 630, and/or by the authorization application 637. The authorization application 637 can be executable to initiate, execute, complete, and/or facilitate any one or more portions of any embodiment described and/or contemplated herein, such as, for example, any one or more portions of the process flows 100, 200, 300, 400, and/or 500 described herein.
For example, in some embodiments, the authorization application 637 is executable to receive one or more payments for offsetting one or more future exceeded account threshold payments. As another example, in some embodiments, the authorization application 637 is executable to receive transaction information associated with a transaction. As another example, in some embodiments, the authorization application 637 is executable to determine that an account will incur an exceeded account threshold as a result of a transaction (i.e., make an exceeded account threshold determination). As still another example, in some embodiments, the authorization application 637 is executable to determine that an exceeded account threshold allocation, exceeded account threshold payment credit, coverage, and/or one or more payments are sufficient to offset an exceeded account threshold payment associated with an exceeded account threshold transaction (i.e., make a sufficiency determination). As another example, in some embodiments, the authorization application 637 is executable to prompt the account holder 608 to consent to an exceeded account threshold, to an exceeded account threshold payment, and/or to using the exceeded account threshold allocation 642 and/or the coverage 644 to offset an exceeded account threshold payment associated with an exceeded account threshold transaction. As another example, in some embodiments, the authorization application 637 is executable to authorize a transaction.
In some embodiments, the authorization application 637 is executable to receive, approve, and/or decline an authorization request. As another example, in some embodiments, the authorization application 637 is executable to determine whether an account and/or an account holder are enrolled in an exceeded account threshold service. As still another example, in some embodiments, the authorization application 637 is executable to prompt a customer to consent (e.g., via the user interface 629, and the like) to an exceeded account threshold payment. In some embodiments, the authorization application 637 is executable to increase and/or decrease an exceeded account threshold allocation associated with an account. As another example, in some embodiments, the authorization application 637 is executable to complete a transaction.
In some embodiments, the authorization application 637 is executable to receive one or more premium payments for purchasing coverage to offset one or more future exceeded account threshold payments. Also, in some embodiments, the authorization application 637 is executable to record coverage information in a computer-readable medium (e.g., the authorization datastore 638, and the like), where the coverage information indicates that the account has coverage to offset one or more future exceeded account threshold payments. As another example, in some embodiments, the authorization application 637 is executable to determine that an account has coverage sufficient to offset an exceeded account threshold payment.
In some embodiments, the authorization application 637 is executable to receive transaction history associated with an account and/or determine a trend based at least partially on that transaction history. As another example, in some embodiments, the authorization application 637 is executable to prompt a holder to submit one or more payments for offsetting one or more future exceeded account threshold payments. As still another example, in some embodiments, the authorization application 637 is executable to determine that an exceeded account threshold allocation has fallen below a predetermined threshold. In some embodiments, the authorization application 637 is executable to prompt a holder of an account to increase an exceeded account threshold allocation. Also, in some embodiments, the authorization application 637 is executable to determine that an exceeded account threshold payment is associated with an account.
In some embodiments, the authorization application 637 is executable to generate and/or send disclosure information to the holder 608, where the disclosure information defines one or more terms of an exceeded account threshold service. In some embodiments, the authorization application 637 generates and/or sends this disclosure information to the holder 608 prior to the holder 608 submitting a payment at the prepayment machine 620 and/or prior to the holder 608 initiating and/or engaging in a transaction at one or more of the channels 601-606. Also, in some embodiments, the authorization application 637 is further executable to prompt (e.g., via the user interface 629, a user interface of one of the channels 601-606, and the like) the holder 608 to agree to the one or more terms of the exceeded account threshold service defined in the disclosure information. In some embodiments, the authorization application 637 is operable to perform one or more of these (and/or other) functions, such that a financial institution may comply with one or more exceeded account threshold regulation requirements (e.g., Regulation E in the United States, and the like).
In some embodiments, the authorization application 637 is executable to enable the authorization apparatus 630 to communicate with one or more other portions of the system 600, such as, for example, the authorization datastore 638 and/or the prepayment machine 620, and/or vice versa. In addition, in some embodiments, the authorization application 637 is executable to initiate, perform, complete, and/or otherwise facilitate one or more financial and/or non-financial transactions. In some embodiments, the authorization application 637 includes one or more computer-executable program code portions for causing and/or instructing the processor 634 to perform one or more of the functions of the authorization application 637 and/or the authorization apparatus 630 that are described and/or contemplated herein. In some embodiments, the authorization application 637 includes and/or uses one or more network and/or system communication protocols.
In addition to the authorization application 637, the memory 636 also includes the authorization datastore 638. It will be understood that the authorization datastore 638 can be configured to store any type and/or amount of information. For example, in some embodiments, the authorization datastore 638 includes information associated with one or more accounts, account holders, transactions, exceeded account thresholds, exceeded account threshold payments, exceeded account threshold allocations, coverages, electronic banking accounts, exceeded account threshold services, authorization requests, exceeded account threshold regulations, and/or the like. In some embodiments, the authorization datastore 638 may also store any information related to offsetting future exceeded account threshold payments via a prepayment machine (e.g., the prepayment machine 620). In some embodiments, the authorization datastore 638 additionally or alternatively stores information associated with electronic banking and/or electronic banking accounts.
In accordance with some embodiments, the authorization datastore 638 may include any one or more storage devices, including, but not limited to, datastores, databases, and/or any of the other storage devices typically associated with a computer system. It will also be understood that the authorization datastore 638 may store information in any known way, such as, for example, by using one or more computer codes and/or languages, alphanumeric character strings, data sets, figures, tables, charts, links, documents, and/or the like. Further, in some embodiments, the authorization datastore 638 includes information associated with one or more applications, such as, for example, the authorization application 637 and/or the prepayment application 627. In some embodiments, the authorization datastore 638 provides a real-time or near real-time representation of the information stored therein, so that, for example, when the processor 634 accesses the authorization datastore 638, the information stored therein is current or nearly current.
The embodiment represented by
The system 600 and/or one or more portions of the system 600 may include and/or implement any embodiment of the present invention described and/or contemplated herein. For example, in some embodiments, the system 600 (and/or one or more portions of the system 600) is configured to implement any one or more embodiments of the process flow 100 described and/or contemplated herein in connection with
As a specific example, in accordance with an embodiment of the present invention, the authorization apparatus 630 is configured to: (a) receive one or more payments for offsetting one or more future exceeded account threshold payments, where the one or more payments are associated with the account 640 (e.g., and/or received via the prepayment machine 620, and the like), as represented by block 110 shown in
Referring now to
In accordance with some embodiments, the personal computer 701 and the POS device 705 are operatively and selectively connected to the authorization server 703 via one or more networks (not shown). Also, the personal computer 701 and the POS device 705 are accessible to a customer of a bank (not shown). Also, in this example embodiment, the POS device 705 is maintained by a merchant, the personal computer 701 is maintained by the customer of the bank, and the authorization server 703 is maintained by the bank. Further, in accordance with some embodiments, the bank maintains the checking account (e.g., the account 640, and the like) held by the customer and associated with the debit card mentioned below. Also, it will be understood that, in this example embodiment, the checking account (and/or the customer) includes a surpassed balance allocation (e.g., exceeded account threshold allocation 642, and the like).
As represented by block 702, the customer logs in to an online banking account associated with the checking account. Although not shown, in some embodiments, the customer may be identified and/or authenticated as part of the login process. Next, as represented by block 704, the customer submits a $50 payment for prepaying a future surpassed balance payment. For example, in some embodiments, the customer uses one or more user input features (e.g., field, button, drop down menu, and the like) of the online banking account to send a payment of $50 to the authorization server 703 (and/or one or more other bank apparatuses) for the purpose of prepaying one or more future surpassed balance payments that may incurred by the checking account and/or the customer. As a result of submitting the $50 payment, the authorization server 703 increases the customer's surpassed balance allocation by $100, as represented by block 706. Thus, in this example embodiment, the authorization server 703 credits the customer's surpassed balance allocation with an amount greater than the amount of the payment received. In other words, in this example embodiment, the customer is incentivized to submit a payment for prepaying one or more future surpassed balance payments because the customer receives double credit for each payment (and/or a discount by prepaying). Also, in this example embodiment, it will be understood that the $50 payment referred to in block 704 increases the customer's surpassed balance allocation from $0 to $100.
After the bank customer submits the $50 payment (and/or the customer's surpassed balance allocation is increased from $0 to $100 as a result of the payment), the customer swipes a debit card at the POS device 705 to engage in (and/or initiate) a debit card transaction (e.g., purchase transaction, and the like) involving the customer and the merchant, as represented by block 708. It will be understood that the customer swipes the debit card at the POS device 705 after the customer submits the $50 payment. For example, in some embodiments, the customer swipes the debit card at the POS device 705 minutes after the customer submits the $50 payment. Specifically, the customer may submit the $50 payment via the customer's mobile phone while the customer is waiting in line to approach to POS device 705 in the merchant store. As another example, in some embodiments, the customer swipes the debit card two months after the customer submits the $50 payment. Although not shown, the POS device 705 may also authenticate the customer based at least partially on one or more credentials the customer provides to the POS device 705.
Next, as represented by block 710, the POS device 705 generates and sends an authorization request associated with the debit card transaction to the authorization server 703. In accordance with some embodiments, the authorization request includes information that, for example, identifies the customer, the checking account associated with the debit card, the amount of the transaction, the one or more goods and/or services involved in the transaction, and/or the like. As represented by block 712, the authorization server 703 then determines that the checking account associated with the debit card will incur a surpassed balance as a result of the transaction. After making the surpassed balance determination, the authorization server 703, in this example embodiment, determines that a $35 surpassed balance payment is associated with the transaction (e.g., because the transaction is a surpassed balance transaction, and the like), as represented by block 714.
In addition, in this example embodiment, as represented by block 716, the authorization server 705 determines that the customer is enrolled in (e.g., has already opted in to, and the like) a surpassed balance service provided by the bank that maintains the checking account and the authorization server 703. Although not shown, in accordance with some embodiments, a customer is assigned a surpassed balance allocation after the customer enrolls in the surpassed balance service. Next, as represented by block 718, the authorization server 703 determines that the customer's surpassed balance allocation is sufficient to pay the surpassed balance payment. For example, in some embodiments, the authorization server 703 determines that the $35 surpassed balance payment is less than the $100 amount in the customer's surpassed balance allocation. Based at least partially on this sufficiency determination, the authorization server 703 approves the authorization request, as represented by block 720. After the authorization request has been approved and/or based at least partially on the authorization server 703 approving the authorization request, the transaction is completed at the POS device 705, as represented by block 722. Additionally, after the authorization request has been approved and/or based at least partially on the authorization server 703 approving the authorization request, the authorization server 703 decreases the customer's surpassed balance allocation by $35 to pay the $35 surpassed balance payment, as represented by block 724. In this example embodiment, this results in the surpassed balance allocation being adjusted from $100 before the decrease to $65 after the decrease. Also, it will be understood that, in accordance with some embodiments, the authorization server 703 decreasing the surpassed balance allocation by $35 serves to pay the $35 surpassed balance payment.
Of course, the embodiment illustrated in
As still another example, in some alternative embodiments, the authorization server 703 is configured to perform one or more of the portions represented by blocks 712-718 after the authorization server approves the authorization request, as represented by block 720. For example, in some embodiments, after the authorization server 703 receives the $50 payment, increases the customer's surpassed balance allocation by $100, and/or approves the authorization request, the authorization server 703 is configured to: (a) determine that the checking account has incurred the surpassed balance payment as a result of the transaction; and/or (b) decrease the surpassed balance allocation based at least partially on the authorization server 703 determining that the account has incurred the surpassed balance payment. Thus, in such alternative embodiments, the authorization server 703 is configured to make the surpassed balance determination and/or decrease the customer's surpassed balance allocation after the authorization server 703 approves the authorization request and/or after the transaction occurs.
Also, in some embodiments, one or more of the portions of the process flow represented by blocks 702-724 are triggered by one or more triggering events, which, in some embodiments, include the performance of one or more of the other portions of the process flow represented by blocks 702-724. Also, in some embodiments, the system 700 is configured to perform the one or more portions of the process flow represented by blocks 702-724, from start to finish, within moments, seconds, and/or minutes. For example, in some embodiments, the authorization server 703 approves the authorization request within approximately moments, seconds, and/or minutes of the authorization server 703 receiving the authorization request from the POS device 705. Further, it will be understood that one or more portions of the process flow represented by blocks 702-724 may be configured to comply with one or more requirements of an exceeded account threshold regulation (e.g., Regulation E and/or the CARD Act in the United States).
Although many embodiments of the present invention have just been described above, the present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Also, it will be understood that, where possible, any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments of the present invention described and/or contemplated herein may be included in any of the other embodiments of the present invention described and/or contemplated herein, and/or vice versa. In addition, where possible, any terms expressed in the singular form herein are meant to also include the plural form and/or vice versa, unless explicitly stated otherwise. Accordingly, the terms “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein. Like numbers refer to like elements throughout.
As will be appreciated by one of ordinary skill in the art in view of this disclosure, the present invention may include and/or be embodied as an apparatus (including, for example, a system, machine, device, computer program product, and/or the like), as a method (including, for example, a business method, computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, and the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a computer-readable storage medium having one or more computer-executable program code portions stored therein. As used herein, a processor, which may include one or more processors, may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more general-purpose circuits perform the function by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or by having one or more application-specific circuits perform the function.
It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, electromagnetic, infrared, and/or semiconductor system, device, and/or other apparatus. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as, for example, a propagation signal including computer-executable program code portions embodied therein.
One or more computer-executable program code portions for carrying out operations of the present invention may include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.
Some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of apparatuses and/or methods. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and/or combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a general purpose computer, special purpose computer, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).
The one or more computer-executable program code portions may be stored in a transitory and/or non-transitory computer-readable medium (e.g., a memory, and the like) that can direct, instruct, and/or cause a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s)
The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with, and/or replaced with, operator- and/or human-implemented steps in order to carry out an embodiment of the present invention.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations, modifications, and combinations of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.
The present application is a continuation-in-part application of, and claims priority to, U.S. patent application Ser. No. 13/006,641, which was filed on Jan. 14, 2011, and is titled “Offsetting Future Overage Fees,” and is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13006641 | Jan 2011 | US |
| Child | 13841589 | US |
