Real-time determination of funds availability for checks and ACH items

Description

TECHNICAL FIELD

This disclosure relates generally to financial transaction processing, and relates more particularly to real-time determination of funds availability for check and ACH (Automated Clearing House) items.

BACKGROUND

When a first financial institution receives a payment item from a payee, such as a check or an ACH item, to be paid from a payor's account maintained by a second financial institution, the first financial institution generally does not interact with the second financial institution to determine whether to accept the transaction and/or make the funds for the payment item immediately available to the payee. Instead, the first financial institution generally makes that determination based on information about the payee, such as the payee's credit history and/or information about the payee's account(s) (e.g., account balances) maintained by the first financial institution. In some instances, the first financial institution may seek information about the payor's account maintained by the second financial institution through a third-party fraud-prevention service, which generally provides information about whether the account is open and in good status, has had recent activity for not-sufficient funds (NSF) or other return activity, or had a stop payment order. The fraud-prevention service generally derives this information based on overnight batch data received from financial institutions, which in some cases can include the second financial institution.

BRIEF DESCRIPTION OF THE DRAWINGS

To facilitate further description of the embodiments, the following drawings are provided in which:

FIG. 1 illustrates a block diagram of a system that can be employed for real-time determination of funds availability for check and ACH items, according to an embodiment;

FIG. 2 illustrates an exemplary workflow for real-time determination of funds availability sent from a first financial institution through a system with a second financial institution determining a payment likelihood and without the system making a routing decision, according to various embodiments;

FIG. 3 illustrates an exemplary workflow for real-time determination of funds availability sent from the first financial institution of FIG. 2 through the system of FIG. 2 with the system of FIG. 2 making a routing decision of whether to have the second financial institution of FIG. 2 determine a payment likelihood, according to various embodiments;

FIG. 4 illustrates an exemplary workflow for real-time determination of funds availability sent from the first financial institution of FIG. 2 to the system of FIG. 2 for determining a payment likelihood, according to various embodiments;

FIG. 5 illustrates an exemplary flow chart for a method to facilitate determining an availability of funds for a payment item, according to an embodiment;

FIG. 6 illustrates an exemplary flow chart for a method to facilitate determining an availability of funds for a payment item, according to an embodiment;

FIG. 7 illustrates an exemplary flow chart for a method to facilitate determining an availability of funds for a payment item, according to an embodiment;

FIG. 8 illustrates a computer that is suitable for implementing an embodiment of the system of FIG. 1 and/or the system of FIG. 2; and

FIG. 9 illustrates a representative block diagram of an example of elements included in circuit boards inside a chassis of the computer of FIG. 8.

For simplicity and clarity of illustration, the drawing figures illustrate the general manner of construction, and descriptions and details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the present disclosure. Additionally, elements in the drawing figures are not necessarily drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of embodiments of the present disclosure. The same reference numerals in different figures denote the same elements.

The terms “first,” “second,” “third,” “fourth,” and the like in the description and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms “include,” and “have,” and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, device, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, system, article, device, or apparatus.

The terms “left,” “right,” “front,” “back,” “top,” “bottom,” “over,” “under,” and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the apparatus, methods, and/or articles of manufacture described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.

The terms “couple,” “coupled,” “couples,” “coupling,” and the like should be broadly understood and refer to connecting two or more elements mechanically and/or otherwise. Two or more electrical elements may be electrically coupled together, but not be mechanically or otherwise coupled together. Coupling may be for any length of time, e.g., permanent or semi-permanent or only for an instant. “Electrical coupling” and the like should be broadly understood and include electrical coupling of all types. The absence of the word “removably,” “removable,” and the like near the word “coupled,” and the like does not mean that the coupling, etc. in question is or is not removable.

As defined herein, two or more elements are “integral” if they are comprised of the same piece of material. As defined herein, two or more elements are “non-integral” if each is comprised of a different piece of material.

As defined herein, “approximately” can, in some embodiments, mean within plus or minus ten percent of the stated value. In other embodiments, “approximately” can mean within plus or minus five percent of the stated value. In further embodiments, “approximately” can mean within plus or minus three percent of the stated value. In yet other embodiments, “approximately” can mean within plus or minus one percent of the stated value.

As defined herein, “real-time” can, in some embodiments, be defined with respect to operations carried out as soon as practically possible upon occurrence of a triggering event. A triggering event can include receipt of data necessary to execute a task or to otherwise process information. Because of delays inherent in transmission and/or in computing speeds, the term “real time” encompasses operations that occur in “near” real time or somewhat delayed from a triggering event. In a number of embodiments, “real time” can mean real time less a time delay for processing (e.g., determining) and/or transmitting data. The particular time delay can vary depending on the type and/or amount of the data, the processing speeds of the hardware, the transmission capability of the communication hardware, the transmission distance, etc. However, in many embodiments, the time delay can be less than approximately one second, five seconds, ten seconds, thirty seconds, one minute, five minutes, or ten minutes.

DESCRIPTION OF EXAMPLES OF EMBODIMENTS

Various embodiments include a method to facilitate determining an availability of funds for a payment item. The method can include providing a processing mechanism in data communication through a network with a first entity and a plurality of depository financial institutions. The plurality of depository financial institutions can include a second entity. The method also can include receiving a first inquiry at the processing mechanism through the network from the first entity. The first inquiry can be received from the first entity in real time after the first entity receives the payment item. The method further can include storing the first inquiry received from the first entity. The method additionally can include sending a second inquiry from the processing mechanism through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be based at least in part on the first inquiry. The method further can include receiving a first response at the processing mechanism through the network from the second entity. The first response can be sent by the second entity in real time in response to receiving the second inquiry. The method additionally can include storing the first response received from the second entity. The method further can include sending a second response from the processing mechanism through the network to the first entity in real time after receiving the first response. The second response can be based at least in part on the first response. The second entity can be specified by the payment item as being responsible for paying the payment item. The first entity can be different from the second entity. The first and second responses each can include a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item. The payment likelihood indicator can be based at least in part on a current status and a current available balance of an account maintained by the second entity that is specified by the payment item for payment of the payment item.

A number of embodiments include a system to facilitate determining an availability of funds for a payment item. The system can include one or more processing modules in data communication through a network with a first entity and a plurality of depository financial institutions. The plurality of depository financial institutions can include a second entity. The system also can include one or more non-transitory memory storage modules storing computing instructions configured to run on the one or more processing modules and perform one or more acts. The one or more acts can include receiving a first inquiry at the processing mechanism through the network from the first entity. The first inquiry can be received from the first entity in real time after the first entity receives the payment item. The one or more acts also can include storing the first inquiry received from the first entity. The one or more acts additionally can include sending a second inquiry from the processing mechanism through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be based at least in part on the first inquiry. The one or more acts further can include receiving a first response at the processing mechanism through the network from the second entity. The first response can be sent by the second entity in real time in response to receiving the second inquiry. The one or more acts additionally can include storing the first response received from the second entity. The one or more acts further can include sending a second response from the processing mechanism through the network to the first entity in real time after receiving the first response. The second response can be based at least in part on the first response. The second entity can be specified by the payment item as being responsible for paying the payment item. The first entity can be different from the second entity. The first and second responses each can include a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item. The payment likelihood indicator can be based at least in part on a current status and a current available balance of an account maintained by the second entity that is specified by the payment item for payment of the payment item.

Some embodiments can include a method to facilitate determining an availability of funds for a payment item. The method can be implemented via execution of computer instructions configured to run at one or more processing modules and configured to be stored at one or more non-transitory memory storage modules. The method can include receiving a first inquiry through a network from a first entity. The first inquiry can be received from the first entity in real time after the first entity receives the payment item. the method also can include determining a routing decision of whether or not to route the first inquiry to a second entity. The second entity can be a depository financial institution that is specified by the payment item as responsible for paying the payment item. The routing decision can be based at least in part on a risk of non-payment of the payment item by the second entity. The method further can include, if the routing decision is to not route the first inquiry to the second entity, sending a first response through the network to the first entity in real time after receiving the first inquiry. The method additionally can include, if the routing decision is to route the first inquiry to the second entity, sending a second inquiry through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be based at least in part on the first inquiry. The method further can include, if the routing decision is to route the first inquiry to the second entity, receiving a second response through the network from the second entity. The second response can be sent by the second entity in real time in response to receiving the second inquiry. The method additionally can include, if the routing decision is to route the first inquiry to the second entity, storing the second response received from the second entity. The method further can include, if the routing decision is to route the first inquiry to the second entity, sending a third response through the network to the first entity in real time after receiving the second response. The third response can be based at least in part on the second response. The first entity can be different from the second entity.

Many embodiments can include a system to facilitate determining an availability of funds for a payment item. The system can include one or more processing modules in data communication through a network with a first entity and a second entity. The system also can include one or more non-transitory memory storage modules storing computing instructions configured to run on the one or more processing modules and perform one or more acts. The one or more acts can include receiving a first inquiry through a network from a first entity. The first inquiry can be received from the first entity in real time after the first entity receives the payment item. the one or more acts also can include determining a routing decision of whether or not to route the first inquiry to a second entity. The second entity can be a depository financial institution that is specified by the payment item as responsible for paying the payment item. The routing decision can be based at least in part on a risk of non-payment of the payment item by the second entity. The one or more acts further can include, if the routing decision is to not route the first inquiry to the second entity, sending a first response through the network to the first entity in real time after receiving the first inquiry. The one or more acts additionally can include, if the routing decision is to route the first inquiry to the second entity, sending a second inquiry through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be based at least in part on the first inquiry. The one or more acts further can include, if the routing decision is to route the first inquiry to the second entity, receiving a second response through the network from the second entity. The second response can be sent by the second entity in real time in response to receiving the second inquiry. The one or more acts additionally can include, if the routing decision is to route the first inquiry to the second entity, storing the second response received from the second entity. The one or more acts further can include, if the routing decision is to route the first inquiry to the second entity, sending a third response through the network to the first entity in real time after receiving the second response. The third response can be based at least in part on the second response. The first entity can be different from the second entity.

Further embodiments can include a method to facilitate determining an availability of funds for a payment item. The method can be implemented via execution of computer instructions configured to run at one or more processing modules and configured to be stored at one or more non-transitory memory storage modules. The method can include receiving at least hourly updated account data comprising current statuses and current available balances of accounts maintained by one or more depository financial institutions. The method also can include receiving an inquiry through a network from a first entity. The inquiry can be received from the first entity in real time after the first entity receives the payment item. The payment item can specify a second entity as responsible for paying the payment item. The payment item can specify an account maintained by the second entity for payment of the payment item. The one or more depository financial institutions can include the second entity. The method additionally can include determining a payment likelihood indicator based at least in part on a status and an available balance of the account as updated by the updated account data. The payment likelihood indicator can indicate a likelihood of the second entity to pay the payment item. The method further can include storing the payment likelihood indicator. The method additionally can include sending a response through the network to the first entity in real time after receiving the inquiry. The response can include the payment likelihood indicator. The first entity can be different from the second entity.

In certain embodiments of the method, the payment item can include a check. The first entity can be a depository financial institution receiving the check for deposit. The second entity can be a depository financial institution against which the check has been drawn.

In certain embodiments of the method, the payment item can include an ACH item. The first entity can be an originating depository financial institution. The second entity can be a receiving depository financial institution. In some embodiments, the first entity can be a processor or a third party acting on behalf of the originating depository financial institution. In a number of embodiments, the second entity can be a processor or a third party acting on behalf of the receiving depository financial institution.

In certain embodiments of the method, the inquiry can include a routing number of the second entity that is specified by the payment item; an account number of the second entity that is specified by the payment item; a payment amount that is specified by the payment item; an identifier of the first entity; a transaction channel identifier that indicates the channel through which a transacting entity presented the payment item to the first entity; a payment distribution method identifier that indicates how the transacting entity requested to be paid for the payment item by the first entity; an account number of the first entity associated with the transacting entity; and if the payment item is a check, a serial number of the check.

In certain embodiments of the method, the payment likelihood indicator in the response can include an indication of whether or not the second entity guarantees payment of the payment item.

In certain embodiments of the method, the payment likelihood indicator in the response can include a score.

In certain embodiments of the method, the response further can include one or more reason indicators to explain the payment likelihood indicator.

In certain embodiments of the method, the response can be sent within 30 seconds of receiving the inquiry. The payment item can include one of a check or an ACH item.

Still further embodiments can include a system to facilitate determining an availability of funds for a payment item. The system can include one or more processing modules in data communication through a network with a first entity and one or more depository financial institutions. The one or more depository financial institutions can include a second entity. The system also can include one or more non-transitory memory storage modules storing computing instructions configured to run on the one or more processing modules and perform one or more acts. The one or more acts can include receiving at least hourly updated account data comprising current statuses and current available balances of accounts maintained by one or more depository financial institutions. The one or more acts also can include receiving an inquiry through a network from a first entity. The inquiry can be received from the first entity in real time after the first entity receives the payment item. The payment item can specify a second entity as responsible for paying the payment item. The payment item can specify an account maintained by the second entity for payment of the payment item. The one or more depository financial institutions can include the second entity. The one or more acts additionally can include determining a payment likelihood indicator based at least in part on a status and an available balance of the account as updated by the updated account data. The payment likelihood indicator can indicate a likelihood of the second entity to pay the payment item. The one or more acts further can include storing the payment likelihood indicator. The one or more acts additionally can include sending a response through the network to the first entity in real time after receiving the inquiry. The response can include the payment likelihood indicator. The first entity can be different from the second entity.

In certain embodiments of the system, the payment item can include a check. The first entity can be a depository financial institution receiving the check for deposit. The second entity can be a depository financial institution against which the check has been drawn.

In certain embodiments of the system, the payment item can include an ACH item. The first entity can be an originating depository financial institution. The second entity can be a receiving depository financial institution.

In certain embodiments of the system, the inquiry can include a routing number of the second entity that is specified by the payment item; an account number of the second entity that is specified by the payment item; a payment amount that is specified by the payment item; an identifier of the first entity; a transaction channel identifier that indicates the channel through which a transacting entity presented the payment item to the first entity; a payment distribution method identifier that indicates how the transacting entity requested to be paid for the payment item by the first entity; an account number of the first entity associated with the transacting entity; and if the payment item is a check, a serial number of the check.

In certain embodiments of the system, the payment likelihood indicator in the response can include an indication of whether or not the second entity guarantees payment of the payment item.

In certain embodiments of the system, the payment likelihood indicator in the response can include a score.

In certain embodiments of the system, the response further can include one or more reason indicators to explain the payment likelihood indicator.

In certain embodiments of the system, the response can be sent within 30 seconds of receiving the inquiry. The payment item can include one of a check or an ACH item.

Turning to the drawings, FIG. 1 illustrates a block diagram of a system 100 that can be employed for real-time determination of funds availability for check and ACH items, according to an embodiment. System 100 is merely exemplary and embodiments of the system are not limited to the embodiments presented herein. The system can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements or modules of system 100 can perform various procedures, processes, and/or activities. In other embodiments, the procedures, processes, and/or activities can be performed by other suitable elements or modules of system 100. In some embodiments, system 100 can include a system 110. System 110 can be a computer system, such as computer system 800, as shown in FIG. 8 and described below, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In several embodiments, system 110 can include a database 111. In a number of embodiments, system 110 can include one or more modules, such as a communications module 112, a data module 113, a risk engine 114, and/or a likelihood calculation engine 115, which are described below in further detail.

In many embodiments, system 110 can be in data communication through a network 120 with financial institutions, such as financial institutions 131, 132, 133, and/or 134. Network 120 can be the Internet or another suitable computer data network. In certain embodiments, each of financial institutions 131-134 can include a computer system, such as computer system 800, as shown in FIG. 8 and described below, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In many embodiments, the financial institutions (e.g., 131-134) can be depository financial institutions, such as savings banks, credit unions, savings and loan associations, etc. In other embodiments, other forms of financial institutions and/or other entities can be connected to system 110 through network 120.

In a number of embodiments, system 110 can regularly receive information from financial institutions, such as financial institutions 131-134, about accounts maintained by the financial institutions (e.g., 131-134). In various embodiments, the information received from the financial institutions can be stored in database 111. For example, in many embodiments, each of financial institutions (e.g., 131-134) can provide overnight batch data to system 110, which can include information about whether accounts are open and in good status, what balances are available in the open accounts, whether accounts have had recent NSF or other activity, and/or whether accounts have had a stop payment order. In a number of embodiments, system 110 can use the data provided by the financial institutions to provide fraud-prevention services to financial institutions (e.g., 131-134). For example, if a payee attempts to cash a check at financial institution 131 for a check drawn on a payor's account maintained at financial institution 132, financial institution 131 can inquire with system 110 about information regarding the payor's account at financial institution 132.

In the same or other embodiments, system 110 can provide for interaction between the financial institutions (e.g., 131-134). For example, in many embodiments, system 110 can provide protocols for a financial institution (e.g., 131) to communicate with another one of the financial institutions (e.g., 132) through system 110 to obtain additional information about whether the other financial institution (e.g., 132) that is specified as responsible for paying a payment item is likely to pay the payment item. In some embodiments, the payment item can be a check. In other embodiments, the payment item can be an ACH item. For example, a check can be drawn on an account at the other financial institution (e.g., 132), or an ACH item can specific an account at the other financial institution (e.g., 132) for payment, and financial institution 132 can be deemed responsible for paying the payment item using the specified account. In a number of embodiments, the interactions between the financial institutions (e.g., 131-134) through system 110 can be limited to inquiries regarding checks or ACH items, and not include inquiries regarding payment card transactions (e.g., debit card, credit card, etc.). In other embodiments, the interactions between the financial institutions (e.g., 131-134) through system 110 can include payment card transactions.

In some embodiments, system 110 can determine whether to route an inquiry from a financial institution (e.g., 131) receiving a payment item to another financial institution (e.g., 132) specified by the payment item as responsible for paying the payment item. The determination can be based on one or more factors, as described below in further detail. In several embodiments, the financial institution (e.g., 132) that is specified by the payment item as responsible for paying the payment item can respond with information regarding a likelihood of that financial institution (e.g., 132) paying the payment item. In other embodiments, information regarding a likelihood of that financial institution (e.g., 132) to pay the payment item, such as information provided regularly (e.g., twice daily, hourly, half-hourly, on each transaction, etc.), can be provided to system 110 by that financial institution (e.g., 132). In many embodiments, the financial institution (e.g., 131) that received the payment item can receive the information regarding the likelihood of payment by the financial institution (e.g., 132) that is specified by the payment item as responsible for paying the payment item, and can use that information and/or other information provided by system 110 to determine whether to approve or deny the transaction. In many embodiments, system 110 can facilitate real-time determination of funds availability on a scale of many financial institutions (e.g., greater than 5, 10, 20, 50, 100, 500, 1000, 10,000, or more financial institutions) and can facilitate many such transactions (e.g., greater than 100, 1,000, 10,000, 100,000, 1,000,000, 10,000,000, or more per day) through system 110.

In certain embodiments, system 110 can provide interaction between the financial institutions (e.g., 131-134) for providing credit push notifications. For example, in many embodiments, system 110 can provide protocols for a financial institution (e.g., 131) to communicate with another one of the financial institutions (e.g., 132) through system 110 to notify the other financial institution (e.g., 132) of a credit push payment. In some embodiments, for example, a customer can initiate notification of an ACH credit transaction at financial institution 131 (which can be an originating depository financial institution (ODFI)) to credit an account of a recipient at financial institution 132 (which can be a receiving depository financial institution (RDFI)), which can result in a memo post to the account of the recipient at financial institution 132 in real time. In many embodiments, the credit push transaction can be cleared through conventional batch processing (e.g., nightly or interim day batch processing), and the notification can be sent from financial institution 131 through system 110 to financial institution 132 in real time, which can beneficially provide financial institution 132 with information about future credits to be posted to the account of the recipient at financial institution 132. In many embodiments, system 110 can store the transaction, such as in database 111.

Turning ahead in the drawings, FIG. 2 illustrates an exemplary workflow 200 for real-time determination of funds availability sent from a first financial institution 202 through a system 203 with a second financial institution 204 determining a payment likelihood and without system 203 making a routing decision, according to various embodiments. Workflow 200 is merely exemplary and is not limited to the embodiments presented herein. Workflow 200 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of workflow 200 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of workflow 200 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of workflow 200 can be combined or skipped. System 203 can be similar or identical to system 110 (FIG. 1).

In some embodiments, workflow 200 can begin with an activity 211 of an entity, such as consumer 201, presenting a payment item to a first financial institution 202 for a transaction. For example, consumer 201 can present a check for $500 to be cashed at a financial institution, such as first financial institution 202. The check can be drawn by a payor against an account of the payor at another financial institution, such as second financial institution 204. In many embodiments, consumer 201 can be the payee, endorsee, or bearer of the check. As another example, consumer 201 can make an online purchase at an online retailer by using checking or savings account information for an account maintained at a financial institution, such as second financial institution 204, and the online retailer can be the originator that presents an ACH payment item based on the checking or savings account information to an originating depository financial institution (ODFI). In various embodiments, consumer 201, the originator, and/or the payor can use the payment item to attempt to effect a transfer of funds (e.g., make a payment, receive a payment, make a deposit, and/or cash the payment item) and/or to determine an availability of funds to be transferred using the payment item. For example, the originator can request that the ACH payment item be screened through the ODFI.

In many embodiments, workflow 200 can continue with an activity 212 of the payment item being received by first financial institution 202. For example, first financial institution 202 can receive a physical check or information regarding the payment item. For example, the payment item can be received through an automated teller machine (ATM), a teller, mail, an online transaction, an online request, remote deposit capture (RDC), lock box, in-store, check processor, or another channel. In other embodiments, first financial institution 202 can be replaced by the originator (such as a merchant) or a payment processor, which can interact directly with system 203. In some embodiments, first financial institution 202 can be a processor or a third party acting on behalf of the ODFI. In a number of embodiments, the second entity can be a processor or a third party acting on behalf of the RDFI.

In some embodiments, workflow 200 can continue with an activity 213 of first financial institution 202 determining whether to make an inquiry to system 203 and/or storing the determination. In some embodiments, first financial institution 202 can automatically send an inquiry to system 203 after receiving a payment item. In other embodiments, first financial institution 202 can make an internal risk decision based on one or more factors, such as the relationship between first financial institution 202 and the requestor (e.g., consumer 201 or the originator who provided the payment item to first financial institution 202). For example, the requestor can have one or more accounts at first financial institution 202. The internal risk decision can be based on the account balances of the requestor at first financial institution 202, return activity of the requestor at first financial institution 202, a date of the payment item, a payment amount of the payment item, and/or a relationship history of deposits of the requestor at first financial institution 202. In addition, or alternatively, the internal risk decision can be based on a relationship history of the payor with first financial institution 202. First financial institution 202 can store the internal risk decision.

In many embodiments, workflow 200 can continue with an activity 214 of first financial institution 202 sending an inquiry to system 203, and/or system 203 receiving the inquiry from financial institution 202. In a number of embodiments, the inquiry can be sent from first financial institution 202 to system 203 in real time after activity 212 of first financial institution 202 receiving the payment item. In several embodiments, the inquiry can include information from the payment item identifying the account of the payor, the financial institution (e.g., second financial institution 204) maintaining the account of the payor, information regarding the requestor, the channel through which the request was made, the type of transaction, and/or other information. For example, in some embodiments, the inquiry can include: (1) the routing number (e.g. American Bankers Association (ABA) routing transit number (RTN)) specified by the payment item; (2) the account number specified by the payment item; (3) if the payment item is a check, a serial number of the check; (4) an account transaction (“trans”) code specified by the payment item; (5) a dollar amount specified by the payment item; (6) an identifier for the originator, requestor, and/or first financial institution 202; (7) one or more channel indicators (e.g., ATM, a teller, mail, an online transaction, the identity of the online device, the location of the online device, RDC, lock box, in-store, check processor, and/or another channel); (8) an identifier of what the requestor has requested with the transaction (e.g., cash, deposit, or payment); (9) an identifier of the type (e.g., check, ACH item, Standard for Financial Services Messaging (ISO (International Organization for Standardization) 20022), certified check, payment cards (debit card, credit card), etc.); (10) transaction identifier (ID) or sequence number for the transaction (which can be generated by system 203); (11) an account number of the requestor, payee, and/or depositor; and/or other suitable information. For example, in some embodiments, the inquiry can include a debit card number for a debit card associated with the account of the payor. In some embodiments, the debit card number can be included in the inquiry in lieu of the routing number and/or the account number. In a number of embodiments, the inquiry can include a transaction business date. In certain embodiments, the inquiry can include a primary client ID or other ID, a transaction ID, and/or an item ID for the payment item.

In certain embodiments, the inquiry can include an identifier linked to the account of the payor. In some embodiments, an identifier can be included in the inquiry in lieu of the routing number and/or the account number. For example, the identifier can include a tokenized or masked token, which can be an identifier which can be linked to the account of the payor. In some embodiments, the token can be a temporary (e.g., one-time use, or limited-time use) identifier. In a number of embodiments, the token include an encrypted identifier. In some embodiments, the identifier in the inquiry can include an email address of the payor, a phone number of the payor, a device ID of the payor, the name of the payor, a debit card number of the payor, a transaction business date, a transaction ID, an item ID, and/or a client ID. In a number of embodiments, such as when the account number and/or routing number is tokenized, the inquiry can include a tokenized service manager ID.

In many embodiments, workflow 200 can continue with an activity 215 of system 203 storing the inquiry sent from first financial institution 202. The inquiry can be stored in database 111 (FIG. 1), and can include a timestamp of when the inquiry was received at system 203. In some embodiments when the inquiry includes an identifier, system 203 can determine the account number and/or routing number from the identifier.

In many embodiments, workflow 200 can continue with an activity 216 of system 203 sending an inquiry to second financial institution 204, and/or second financial institution 204 receiving the inquiry from system 203. In a number of embodiments, the inquiry can be sent from system 203 to second financial institution 204 in real time after activity 214 of system 203 receiving the inquiry. In many embodiments, the inquiry sent to second financial institution 204 in activity 216 can be similar or identical to the inquiry received by system 203 in activity 214. In some embodiments, such as when the inquiry of activity 214 includes an identifier, the inquiry of activity 216 can include the account number and/or routing number from the identifier. In other embodiments, activity 216 can include the identifier in lieu of the account number and/or routing number, and second financial institution 204 can determine the account number and/or routing number from the identifier.

In several embodiments, workflow 200 can continue with an activity 217 of second financial institution 204 determining and/or saving a payment likelihood. In various embodiments, determining the payment likelihood can be based at least in part on current information of the payor's account maintained by second financial institution 204 and/or information provided to second financial institution 204 in the inquiry. In many embodiments, the financial institutions (e.g., second financial institution 204) that participate in services offered through system 203 and provide payment likelihood for real-time determination of funds availability can have agreed to common consortium rules to be used when determining a payment likelihood. The common consortium rules can advantageously provide consistency across determinations made and information provided by different financial institutions. In some embodiments, the providers of system 203 can dictate the consortium rules to the financial institutions (e.g., second financial institution 204) that provide payment likelihood information.

In several embodiments, the consortium rules can address information that an inquirer (e.g., first financial institution 202) might want to know in determining whether to approve or deny a transaction, such as current account status and sufficiency of funds to cover the payment item, risk of fraud, money laundering, and/or other factors. Second financial institution 204, which is specified as responsible for paying the payment item, can beneficially have current detailed information regarding the payor and/or the payor's account maintained by second financial institution 204. For example, in some embodiments, activity 217 of second financial institution 204 determining the payment likelihood can be based on one or more rules, such as: (1) determining whether the payor's account is currently open (e.g., based on intra-day status, if the account is opened or closed during the day of the inquiry); (2) determining whether the current balance and/or available balance (e.g., the current balance adjusted by pending transactions that have not yet cleared) of the payor's account is greater than the amount specified by the payment item (e.g., is greater than or equal to the payment amount, is greater than the payment amount by a predetermined amount (e.g., is the balance at least $200 greater than the payment amount), or is greater than the payment amount by a factor of the payment amount (e.g. is the balance at least 150% of the payment amount)); (3) determining whether the payment amount is in a range of historical spending amounts by the payor (e.g., determining whether the payment amount is consistent with the payor's spending habits); (4) determining whether there is a likelihood of a deposit to be made into the account (e.g., on the day of the inquiry) that would make the payor's account able to cover the payment item, or expected withdrawals that would make the payor's account unable to cover the payment item; (5) determining whether the payment item is consistent with a pattern, if any, between the payee and the payor; (6) determining whether other payment items have been drawn on and/or presented for clearing against the payor's account (e.g., other pending charges) that would affect whether the payor's account could cover the payment item; (7) determining whether there is a risk of fraud based on activity that matches a fraudulent pattern or is inconsistent with the payor's spending habits; (8) determining whether there is a risk of fraud based on how recently the payor's account was opened; (9) determining whether there is a risk of fraud based on the channel used to present the payment; (10) determining whether there is a likelihood of money laundering based on transaction payment amounts, and/or the identities of the payor and/or payee; (11) if the payment item is a check, determining if the account is uses the Positive Pay verification service, and if so, verifying that the check is on the list provided by the payor and if the check has already been paid; (12) if the payment item is a check, determining whether the serial number of the check is in pattern (e.g., whether the serial number of the check is not within the range of serial numbers in one or more checkbooks that have been used recently for the payor's account); (13) if the payment item is a check, determining whether the check is a duplicate of an already-paid check; (14) if the payment item is a check, determining whether the check is likely a counterfeit, such as based on a statistical analysis; and/or other suitable rules.

In a number of embodiments, the rules can be used to determine a likelihood of whether or not the payment item will clear the payor's account at second financial institution 204. For example, in some embodiments, second financial institution 204 can determine a payment likelihood indicator, which can be whether or not second financial institution 204 guarantees payment of the payment item (e.g., either guarantees payment or does not guarantee payment) or whether or not second financial 204 is likely to pay the payment item (e.g., either is likely to pay or is not likely to pay). In the same or other embodiments, second financial institution 204 can determine a payment likelihood score, and the payment likelihood indicator can include the payment likelihood score. In some embodiments, the payment likelihood score can be a numeric score (e.g., 0-100), an alphabetic score (e.g., A-Z), a color score (e.g., red, yellow, or green), or another suitable type of score. In some embodiments, the payment likelihood indicator can include an expiration date/time. For example, the guarantee can have an expiration date/time after which the guarantee or payment likelihood indicator will expire.

In a number of embodiments, the payment likelihood indicator can include reason indicators (e.g., reason codes, explanations, attributes, etc.) that explain the reasons for the payment likelihood indicator. For example, the reasons can include: (1) that the payment item is not found on Positive Pay; (2) that the item is a possible duplicate; (3) that the account is closed; (4) that there has been fraud or the payment item is likely to be fraud on the account; (5) that the payment item is likely to be a counterfeit; (6) that the payment amount specified by the payment item is greater than the current and/or available balance of the payor's account; (6) that the payor's account is overdrawn or has an NSF status; (7) that the account has a sufficient balance; (8) that payment item is or is not in pattern (e.g., payment amount is consistent with transaction history, that the serial number is in the range of serial numbers in one or more checkbooks that have been used recently for the payor's account, etc.); (9) that the expected balance is or is not sufficient, based on expected deposits and/or payments; (10) that the payment is or is not in pattern for transactions between the payor and the payee; (11) that the item is on Positive Pay and is verified; and/or other suitable reasons.

In many embodiments, workflow 200 can continue with an activity 218 of second financial institution 204 sending a response to system 203, and/or system 203 receiving the response from second financial institution 204. In a number of embodiments, the response can be sent from second financial institution 204 to system 203 in real time after activity 216 of second financial institution 204 receiving the inquiry. In several embodiments, the response can include the payment likelihood indicator that was determined in activity 217. In some embodiments, the response can include information from the inquiry and/or information determined by second financial institution 204. For example, in a number of embodiments, the response can include: (1) the routing number (e.g. ABA RTN) specified by the payment item; (2) the account number specified by the payment item; (3) if the payment item is a check, a serial number of the check; (4) an account transaction (“trans”) code specified by the payment item; (5) a dollar amount specified by the payment item; (6) an identifier for the originator, requestor, and/or first financial institution 202; (7) one or more channel indicators (e.g., ATM, a teller, mail, an online transaction, the identity of the online device, the location of the online device, RDC, lock box, in-store, check processor, and/or another channel); (8) an identifier of what the requestor has requested with the transaction (e.g., cash, deposit, or payment); (9) an identifier of the type (e.g., check, ACH item, Standard for Financial Services Messaging (ISO (International Organization for Standardization) 20022), certified check, payment cards (debit card, credit card), etc.); (10) transaction identifier (ID) or sequence number for the transaction (which can be generated by system 203); (11) the account number of the requestor, payee, and/or depositor; (12) the date and/or time(s) of the inquiry/inquiries (e.g., based on the timestamp stored in activity 215 and/or the time the determination of the payment likelihood in activity 217); (13) the payment likelihood indicator (e.g., whether or not guaranteed to pay (which can include a guarantee expiration date/time), whether or not likely to pay; and/or the payment likelihood score); (14) the reason indicators for the payment likelihood indicator; and/or other suitable information.

In many embodiments, workflow 200 can continue with an activity 219 of system 203 storing the response sent from second financial institution 204 in activity 218. The inquiry can be stored in database 111 (FIG. 1), and can include a timestamp of when the response was received at system 203.

In some embodiments, workflow 200 can continue with an activity 220 of system 203 sending a response to first financial institution 202, and/or first financial institution 202 receiving the response from system 203. In a number of embodiments, the response can be sent from system 203 to first financial institution 202 in real time after activity 218 of system 203 receiving the response. In many embodiments, the response sent to first financial institution 202 in activity 220 can be similar or identical to the response received by system 203 in activity 218.

In several embodiments, workflow 200 can continue with an activity 221 of first financial institution 202 determining whether to approve or deny the transaction, actually approving or denying the transaction, storing the approval or denial, and/or notifying consumer 201 of such approval or denial. In various embodiments, first financial institution 202 can determine whether to approve or deny the transaction based at least in part on the response received by first financial institution 202 in activity 220. By incorporating insight from second financial institution 204, first financial institution 202 can advantageously make a more informed decision in determining the availability of funds for the payment item and in determining whether to approve or deny the transaction. For example, if the response includes a guarantee of payment or an indication or likelihood of payment by second financial institution 204, first financial institution 202 can approve the transaction. If the response includes the payment likelihood score, first financial institution 202 can determine whether the score indicates a low enough risk that first financial institution 202 can be comfortable with the risk of approving the transaction.

Turning ahead in the drawings, FIG. 3 illustrates an exemplary workflow 300 for real-time determination of funds availability sent from first financial institution 202 through system 203 with system 203 making a routing decision of whether to have second financial institution 204 determine a payment likelihood, according to various embodiments. Workflow 300 is merely exemplary and is not limited to the embodiments presented herein. Workflow 300 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of workflow 300 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of workflow 300 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of workflow 300 can be combined or skipped. Workflow 300 can be similar to workflow 200 (FIG. 2), and various activities of workflow 300 can be similar or identical to various activity of workflow 200 (FIG. 2).

In some embodiments, workflow 300 can begin with an activity 311 of an entity, such as consumer 201, presenting a payment item for a transaction. Activity 311 can be similar or identical to activity 211 (FIG. 2).

In many embodiments, workflow 300 can continue with an activity 312 of the payment item being received by first financial institution 202. Activity 312 can be similar or identical to activity 212 (FIG. 2).

In some embodiments, workflow 300 can continue with an activity 313 of first financial institution 202 determining whether to make an inquiry to system 203 and/or storing the determination. Activity 313 can be similar or identical to activity 213 (FIG. 2).

In many embodiments, workflow 300 can continue with an activity 314 of first financial institution 202 sending an inquiry to system 203, and/or system 203 receiving the inquiry from first financial institution 202. Activity 314 can be similar or identical to activity 214 (FIG. 2).

In a number of embodiments, workflow 300 can continue with an activity 315 of determining whether to route the inquiry to second financial institution 204 and/or storing the determination. In many embodiments, the routing decision can be based at least in part on a risk of non-payment of the payment item by the second entity. In many embodiments, the routing decision can be based on information received from financial institutions (e.g., 131-134 (FIG. 1), which can include first financial institution 202 and/or second financial institution 204), such as overnight batch data regarding whether accounts are open and in good status, what balances are available in the open accounts, whether accounts have had recent NSF or other activity, whether accounts had a stop payment order, and/or other suitable information. In some embodiments, system 203 can store the inquiry from first financial institution 202 received in activity 314 with or without a timestamp of when the inquiry was received by system 203, and system 203 can use database 111 (FIG. 1) to store the inquiry. In a number of embodiments, the routing decision can be based at least in part on other inquiries received earlier in the same day that are similar to the inquiry received in activity 314. In some embodiments, the financial institutions (e.g., 131-134 (FIG. 1), first financial institution 202, and/or second financial institution 204) can provide additional information to system 203 on a periodic or regular basis (e.g., daily, twice daily, hourly, half-hourly, on every transaction, etc.), which can be received by system 203 before receiving the inquiry in activity 314, which can be more up-to-date than overnight batch data, and which can be used by system 203 in some embodiments to determine the routing decision.

In several embodiments, the routing decision can be based on whether second financial institution 204 is setup to participate in online back-office validation to determine payment likelihood, and/or can be based on rules that determine a risk of non-payment, based on information made available to system 203 from the financial institutions (e.g., 131-134 (FIG. 1), first financial institution 202, and/or second financial institution 204) before receiving the inquiry in activity 314, based on earlier inquiries through system 203 (similar to the inquiry received in activity 314), and/or based on the inquiry received in activity 314. In some embodiments, when system 203 applies the rules to determines the risk of non-payment and the routing decision, system 203 can generate decision information, which can be returned to first financial institution 202 and/or sent to second financial institution 204.

In various embodiments, system 203 can determine whether the payment item is drawn on an invalid account. If the account specified by the payment item is not found, system 203 can generate decision information indicating that the account was not found and can determine not to route the inquiry to second financial institution 204.

In many embodiments, system 203 can determine whether the account specified by the payment item is open. If the account is closed, and has been closed for more than a predetermined amount of time (e.g., 7 days), system 203 can generate decision information that the account is closed and determine not to route the inquiry to second financial institution 204. In some embodiments, if the account has been closed for less than a predetermined amount of time (e.g., 7 days), system 203 can generate decision information that the account has been recently closed and can determine to route the inquiry to second financial institution 204.

In several embodiments, system 203 can determine, if the payment item is an ACH item, whether the account specified by the payment item has a “Post no Debits” status. If the account has a “Post no Debits” status, system 203 can generate decision information indicating that the account has a “Post no Debits” status and can determine not to route the inquiry to second financial institution 204.

In various embodiments, system 203 can determine, if the payment item is a check, whether the account specified by the payment item has a stop payment on the item. For example, the stop payment can be based on a three-field match of routing number, account number, and serial number, or a four-field match of routing number account number, serial number, and payment amount. If the account has a stop payment status, system 203 can generate decision information indicating that the account has a stop payment status and can determine not to route the inquiry to second financial institution 204.

In some embodiments, system 203 can determine, if the payment item is a check, whether the account specified by the payment item uses Positive Pay verification. In some embodiments, if the account uses Positive Pay verification, system 203 can generate decision information indicating that the account has uses Positive Pay verification. In some embodiments, system 203 can determine not to route the inquiry to second financial institution 204. In other embodiments, system 203 can determine to route the inquiry to second financial institution 204 for Positive Pay verification.

In many embodiments, system 203 can determine, if the payment item is a check, whether the check is likely a duplicate. If the check is likely a duplicate, system 203 can generate decision information indicating that the check is likely a duplicate and can determine not to route the inquiry to second financial institution 204.

In many embodiments, system 203 can determine, if the payment item is a check, whether the check is likely a counterfeit. If the check is likely a counterfeit, system 203 can generate decision information indicating that the check is likely a counterfeit and can determine not to route the inquiry to second financial institution 204.

In many embodiments, system 203 can determine whether the payment item is likely part of a money-laundering scheme. For example, system 203 can determine whether the payment item is likely part of a money-laundering scheme based on the payment amount of the payment item and/or other transactions, and/or the payee and/or payor for the payment item. If the payment item is likely part of a money-laundering scheme, system 203 can generate decision information indicating that the payment item is likely part of a money-laundering scheme and can determine not to route the inquiry to second financial institution 204.

In many embodiments, system 203 can determine whether the payment item is likely fraudulent. For example, system 203 can determine whether the payment item is likely fraudulent based on the channel used, whether the channel used is a new device, the authentication used in the channel, the location of the channel, whether the payor's account was recently opened, and/or whether the payment is consistent with transaction patterns for the payor and/or payee. If the payment item is likely fraudulent, system 203 can generate decision information indicating that the payment item is likely fraudulent and can determine not to route the inquiry to second financial institution 204.

In some embodiments, if system 203 has been provided with account balances (e.g., nightly, or more frequently), system 203 can determine whether the payment amount specified by the payment item is greater than the latest balance information received by system 203. In some embodiments, system 203 can generate decision information indicating that the payment item is likely unable to be covered by the payor's account and can determine not to route the inquiry to second financial institution 204.

In various embodiments, system 203 can determine whether the payment amount for the payment item is greater than or less than a predetermined amount. For certain financial institutions, and/or for certain accounts at certain financial institutions, the financial institution (e.g., either first financial institution 202 or second financial institution 204) might not want to have the inquiry routed to second financial institution 204 if the payment amount if below a predetermined amount (e.g., a payment amount below $10, $50, or $100). In such cases, system 203 can generate decision information indicating that the payment item is below a certain amount and determine not to route the inquiry to second financial institution 204.

In a number of embodiments, system 203 can determine whether second financial institution is setup to participate in online validation to determine payment likelihood. If second financial institution is not setup to participate in online validation, system 203 can generate decision information indicating that second financial institution 204 is not setup to participate in online validation, and can determine not to route the inquiry to second financial institution 204.

In many embodiments, if system 203 has determined to not route the inquiry to second financial institution 204, system 203 can instead respond to first financial institution 202. In such cases, workflow 300 can continue with an activity 316 of system 203 sending a response to first financial institution 202, and/or first financial institution 202 receiving the response from system 203. In a number of embodiments, the response can be sent from system 203 to first financial institution 204 in real time after activity 314 of system 203 receiving the inquiry. In many embodiments, the response sent to first financial institution 202 in activity 316 can include information from the inquiry and/or the decision information generated by system 203 in activity 315.

If system 203 has determined to route the inquiry to second financial institution 204, workflow 300 can continue with an activity 317 of system 203 sending an inquiry to second financial institution 204, and/or second financial institution 204 receiving the inquiry from system 203. Activity 317 can be similar or identical to activity 216 (FIG. 2). In some embodiments, the inquiry sent to second financial institution 204 in activity 317 can include the decision information, such as the determination of the risk of non-payment, generated by system 203 in activity 315, and/or the information received by system 203 from first financial institution 202 in activity 314. In other embodiments, the decision information generated by system 203 in activity 315 can be sent to second financial institution 204 in a separate informational message sent before or after the inquiry sent by system 203 to second financial institution 204 in activity 317. In yet other embodiments, after receiving the inquiry in activity 317, second financial institution 204 can send a request for additional information to system 203, and system 203 in response can send an informational message to second financial institution 204 than includes the decision information generated by system 203 in activity 315. In yet other embodiments, second financial institution 204 can proceed to determine the payment likelihood (described below) without the information generated by system 203 in activity 315.

In several embodiments, workflow 300 can continue with an activity 318 of second financial institution 204 determining a payment likelihood and/or storing the determination. Activity 318 can be similar or identical to activity 217 (FIG. 2). In various embodiments, determining the payment likelihood can be based at least in part on current information of the payor's account maintained by second financial institution 204, information provided to second financial institution 204 in the inquiry, and/or the decision information generated by system 203 in activity 315. In many embodiments, the information available to second financial institution 204 can be different than the information available to system 203. For example, the information available to second financial institution 204 can be current information, as opposed to information from the previous night, and/or one or more previous intra-day updates, which can beneficially allow second financial institution 204 to make decisions based on more current information. In some embodiments, system 203 can have information about the payor and/or payee at other financial institutions (e.g., 131-134 (FIG. 1)), which can beneficially allow system 203 to determine risks using aggregated information that is not otherwise available to second financial institution 204. As such, the information provided by system 203 to second financial institution 204 in certain embodiments, such as the decision information generated by system 203 in activity 315, can advantageously enhance the ability of second financial institution 204 to more accurately determine the payment likelihood, such as whether not to guarantee payment, whether or not to determine that payment is likely, and/or to accurately determine a payment likelihood score.

In many embodiments, workflow 300 can continue with an activity 319 of second financial institution 204 sending a response to system 203, and/or system 203 receiving the response from second financial institution 204. Activity 319 can be similar or identical to activity 218 (FIG. 2).

In various embodiments, workflow 300 can continue with an activity 320 of system 203 storing the response sent from second financial institution 204 in activity 319. Activity 320 can be similar or identical to activity 219 (FIG. 2).

In some embodiments, activity 320 can include system 203 further determining a payment likelihood based on the payment likelihood determined by and received from second financial institution 204 and also based on additional information available to system 203. In these embodiments, system 203 might have information that second financial institution 204 does not have, and therefore, system 203 can refine or further determine the payment likelihood that was originally made by second financial institution 204, and system 203 can store the refined determination. For example, as explained above with respect to activity 315, system 203 may have additional financial information about the payor's other bank accounts at other financial institutions that second financial institution 204 does not have. Similarly, system 203 may have financial information about second financial institution 204 that is not part of the response in activity 319 but that system 203 can use to refine or further determine the payment likelihood.

In some embodiments, workflow 300 can continue with an activity 321 of system 203 system 203 sending a response to first financial institution 202, and/or first financial institution 202 receiving the response from system 203. Activity 321 can be similar or identical to activity 220 (FIG. 2). In some embodiments, the decision information generated by system 203 in activity 315 can be added to the response to first financial institution 202, and/or other risk factors, such as whether the account was recently opened.

In several embodiments, workflow 300 can continue after activity 316 or activity 321 with an activity 322 of first financial institution 202 determining whether to approve or deny the transaction, actually approving or denying the transaction, storing the approval or denial, and/or notifying consumer 201 of such approval or denial. Activity 322 can be similar or identical to activity 221 (FIG. 2). By incorporating insight from second financial institution 204 (e.g., the payment likelihood decision determined in activity 318) and/or system 203 (e.g., the decision information generated in activity 315), first financial institution 202 can advantageously make a more informed decision in determining the availability of funds for the payment item and in determining whether to approve or deny the transaction.

In some embodiments, workflow 300 can optionally continue after activity 322 with an activity 323 of first financial institution 202 sending a payment decision message to system 203, and/or system 203 receiving a payment decision message from first financial institution 202. In a number of embodiments, the payment decision message can include information regarding whether first financial institution 202 accepted or denied the transaction. In some embodiments, the payment decision message can be sent from first financial institution 202 in real time after activity 316 or activity 321 of system 203 receiving the response.

In many embodiments, workflow 300 can continue with an activity 324 of system 203 storing the payment decision message sent from first financial institution 202 in activity 323. The payment decision message can be stored in database 111 (FIG. 1), and can include a timestamp of when the payment decision message was received at system 203.

In some embodiments, workflow 300 can further optionally continue with an activity 325 of system 203 sending a payment decision message to second financial institution 204, and/or second financial institution 204 receiving the payment decision message from system 203. In a number of embodiments, the payment decision message can be sent from system 203 to second financial institution 204 in real time after activity 323 of system 203 receiving the payment decision message in activity 323. In many embodiments, the payment decision message sent to second financial institution 204 in activity 325 can be similar or identical to the payment decision message received by system 203 in activity 323.

In some embodiments, workflow 300 can further optionally continue with an activity 326 of second financial institution 204 storing the payment decision message sent from system 203 in activity 325. Second financial institution 204 also can store a timestamp of when the payment decision message was received at second financial institution 204.

In various embodiments, the information in the payment decision message sent to system 203 and/or second financial institution 204 from first financial institution 202 can beneficially be used by system 203 and/or second financial institution 204 to determine risks in future transactions. In many embodiments, second financial institution 204 can use the information in the payment decision message to update a pending account status of the payor's account. In some embodiments, workflow 200 (FIG. 2) can similarly include sending a payment decision message to system 203 and/or second financial institution 204 such that activities 323, 324, 325, and 326 also can be part of workflow 200 (FIG. 2) by occurring after activity 221 (FIG. 2).

Turning ahead in the drawings, FIG. 4 illustrates an exemplary workflow 400 for real-time determination of funds availability sent from first financial institution 202 to system 203 for determining a payment likelihood, according to various embodiments. Workflow 400 is merely exemplary and is not limited to the embodiments presented herein. Workflow 400 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of workflow 400 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of workflow 400 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of workflow 400 can be combined or skipped. Workflow 400 can be similar to workflow 200 (FIG. 2) and/or workflow 300 (FIG. 3), and various activities of workflow 400 can be similar or identical to various activity of workflow 200 (FIG. 2) and/or workflow 300 (FIG. 3).

In some embodiments, workflow 400 can begin with an activity 411 of an entity, such as consumer 201, presenting a payment item for a transaction. Activity 411 can be similar or identical to activity 211 (FIG. 2) and/or activity 311 (FIG. 3).

In many embodiments, workflow 400 can continue with an activity 412 of the payment item being received by first financial institution 202. Activity 412 can be similar or identical to activity 212 (FIG. 2) and/or activity 312 (FIG. 3).

In some embodiments, workflow 400 can continue with an activity 413 of determining whether to make an inquiry to system 203 and/or storing the determination. Activity 413 can be similar or identical to activity 213 (FIG. 2) and/or activity 313 (FIG. 3).

In many embodiments, workflow 400 can continue with an activity 414 of first financial institution 202 sending an inquiry to system 203, and/or system 203 receiving the inquiry from first financial institution 202. Activity 414 can be similar or identical to activity 214 (FIG. 2) and/or activity 314 (FIG. 3).

In a number of embodiments, workflow 400 can continue with an activity 415 of system 203 determining a payment likelihood. Activity 415 can be similar to activity 217 (FIG. 2), activity 315 (FIG. 3), and/or activity 318 (FIG. 3). In some embodiments, system 203 can store the inquiry from first financial institution 202 received in activity 414 with or without a timestamp of when the inquiry was received by system 203, and system 203 can store the inquiry and/or timestamp in database 111 (FIG. 1). In a number of embodiments, system 203 can apply one or more of the rules applied in making the routing decision in activity 315 (FIG. 3) to determine a risk of non-payment, and/or system 203 can generate decision information, such as the decision information generated in activity 315 (FIG. 3), by applying the rules. System 203 can determine a payment likelihood based on the decision information and/or through applying rules, such as the common consortium rules used to determine a payment likelihood in activity 217 (FIG. 2) and/or activity 318 (FIG. 3). In some embodiments, a financial institution that is specified in a payment item as responsible for paying the payment item can provide information regularly (e.g., twice daily, hourly, half-hourly, on each transaction, etc.) to system 203 so as to allow system 203 to determine the payment likelihood, rather than the financial institution determining the payment likelihood (as done by second financial institution 204 in activity 217 (FIG. 2) and activity 318 (FIG. 3)). In some embodiments, the financial institution can provide less, as much, or more information to system 203 as is used by second financial institution 204 to determine the payment likelihood in activity 217 (FIG. 2) and/or activity 318 (FIG. 3).

In a number of embodiments, workflow 400 can continue with an activity 416 of system 203 providing the payment likelihood information and/or decision information generated in activity 415 to be stored in system 203.

In several embodiments, workflow 400 can continue with an activity 417 of system 203 storing the payment likelihood information and/or decision information generated in activity 415 with or without a timestamp when the determination was made, in system 203, and system 203 can store the information and/or timestamp in database 111 (FIG. 1).

In many embodiments, workflow 400 can continue with an activity 418 of system 203 sending a response to system first financial institution 202, and/or first financial institution 202 receiving the response from system 203. Activity 417 can be similar to activity 218 (FIG. 2), activity 220 (FIG. 2), activity 319 (FIG. 3), and/or activity 321 (FIG. 3). The response can include the decision information and/or the payment response likelihood information, as determined in activity 415, and/or other risk factors, such as whether the account was recently opened.

In several embodiments, workflow 400 can continue with an activity 419 of first financial institution 202 determining whether to approve or deny the transaction, actually approving or denying the transaction, storing the approval or denial, and/or notifying consumer 201 of such approval or denial. Activity 422 can be similar or identical to activity 221 (FIG. 2) and/or activity 322 (FIG. 3). In some embodiments, workflow 400 can optionally send the payment decision information to system 203, as described in activities 323 and 324 in FIG. 3.

Turning ahead in the drawings, FIG. 5 illustrates a flow chart for a method 500 to facilitate determining an availability of funds for a payment item, according to an embodiment. Method 500 is merely exemplary and is not limited to the embodiments presented herein. Method 500 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of method 500 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of method 500 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of method 500 can be combined or skipped. Method 500 can be similar or identical to the acts performed by system 203 (FIGS. 2-4) in workflow 200 (FIG. 2). In many embodiments, the payment item can include one of a check or an ACH item.

Referring to FIG. 5, method 500 can include a block 501 of providing a processing mechanism in data communication through a network with a first entity and a plurality of depository financial institutions. The first entity can be similar or identical to first financial institution 202 (FIGS. 2-4). The processing mechanism can be similar or identical to system 110 (FIG. 1) and/or system 203 (FIGS. 2-4). The network can be similar or identical to network 120 (FIG. 1). The depository financial institutions can be similar or identical to financial institutions 131-134 (FIG. 1), first financial institution 202 (FIGS. 2-4), and/or second financial institution 204 (FIGS. 2-3). In some embodiments, the plurality of depository financial institutions can include a second entity. The second entity can be similar or identical to second financial institution 204 (FIGS. 2-3). In some embodiments, the second entity can be specified by the payment item as being responsible for paying the payment item. In many embodiments, the first entity can be different from the second entity. In some embodiments, the payment item can be a check, the first entity can be a depository financial institution receiving the check for deposit, and the second entity can be a depository financial institution against which the check has been drawn. In other embodiments, the payment item can be an ACH item, the first entity can be an originating depository financial institution (ODFI) for the ACH item, and the second entity can be a receiving depository financial institution (RDFI) for the ACH item. In a number of embodiments, the first entity can be a payment processor, and the second entity can be a financial institution.

In many embodiments, method 500 additionally can include a block 502 of receiving a first inquiry at the processing mechanism through the network from the first entity. The first inquiry can be similar or identical to the inquiry sent from first financial institution 202 (FIGS. 2-4) to system 203 (FIGS. 2-4) in activity 214 (FIG. 2). In various embodiments, the first inquiry can be received from the first entity in real time after the first entity receives the payment item. For example, the first entity can receive the payment item similarly or identically to first financial institution 202 (FIGS. 2-4) receiving the payment item in activity 212 (FIG. 2).

In some embodiments, method 500 further can include a block 503 of storing the first inquiry received from the first entity along with a first timestamp that indicates when the first inquiry was received from the first entity. Block 503 of storing the first inquiry can be similar or identical to activity 215 (FIG. 2) of system 203 (FIGS. 2-4) storing the inquiry sent from first financial institution 202 (FIGS. 2-4).

In many embodiments, method 500 additionally can include a block 504 of sending a second inquiry from the processing mechanism through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be similar or identical to the inquiry sent from system 203 (FIGS. 2-4) to second financial institution 204 (FIGS. 2-3) in activity 216 (FIG. 2), and block 504 can be similar or identical to activity 216 (FIG. 2). In various embodiments, the second inquiry can be based at least in part on the first inquiry. In some embodiments, the first and/or second inquiries can include a routing number of the second entity that is specified by the payment item; an account number of the account maintained by the second entity that is specified by the payment item; a payment amount that is specified by the payment item; an identifier of the first entity; a transaction channel identifier that indicates the channel through which a transacting entity presented the payment item to the first entity; a payment distribution method identifier that indicates how the transacting entity requested to be paid for the payment item by the first entity; an account number of the first entity associated with the transacting entity; and/or, if the payment item is a check, a serial number of the check. In a number of embodiments, the first inquiry can include an identifier linked to the account maintained by the second entity that is specified by the payment item.

In some embodiments, method 500 further can include a block 505 of receiving a first response at the processing mechanism through the network from the second entity. The first response can be similar or identical to the response sent from second financial institution 204 (FIGS. 2-3) to system 203 (FIGS. 2-4) in activity 218 (FIG. 2), and block 505 can be similar or identical to activity 281 (FIG. 2). In various embodiments, the first response can be sent by the second entity in real time in response to receiving the second inquiry.

In many embodiments, method 500 additionally can include a block 506 of storing the first response received from the second entity along with a second timestamp that indicates when the first response was received from the second entity. Block 506 of storing the first response can be similar or identical to activity 219 (FIG. 2) of system 203 (FIGS. 2-4) storing the response sent from second financial institution 204 (FIGS. 2-3).

In some embodiments, method 500 further can include a block 507 of sending a second response from the processing mechanism through the network to the first entity in real time after receiving the first response. The second response can be similar or identical to the response sent from system 203 (FIGS. 2-4) to first financial institution 202 (FIGS. 2-4) in activity 220 (FIG. 2), and block 507 can be similar to activity 220 (FIG. 2). In various embodiments, the second response can be sent within 30 seconds of receiving the first inquiry. In some embodiments, the second response can be based at least in part on the first response. In some embodiments, the first and/or second responses each can include a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item. The payment likelihood indicator can be similar or identical to the payment likelihood indicator determined by second financial institution 204 (FIGS. 2-3) in activity 217 (FIG. 2). In various embodiments, the payment likelihood indicator can be based at least in part on a current status and a current available balance of an account maintained by the second entity that is specified by the payment item for payment of the payment item. In a number of embodiments, the payment likelihood indicator in the first and/or second responses can include an indication of whether or not the second entity guarantees payment of the payment item. In many embodiments, the payment likelihood indicator in the first and/or second responses can include a score. The score can be similar or identical to the payment likelihood score determined by second financial institution 204 (FIGS. 2-3) in activity 217 (FIG. 2). In various embodiments, the first and/or second responses each can further include one or more reason indicators to explain the payment likelihood indicator provided by the second entity. The reason indicators can be similar or identical to the reason indicators determined by second financial institution 204 (FIGS. 2-3) in activity 217 (FIG. 2).

Turning ahead in the drawings, FIG. 6 illustrates a flow chart for a method 600 to facilitate determining an availability of funds for a payment item, according to an embodiment. Method 600 is merely exemplary and is not limited to the embodiments presented herein. Method 600 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of method 600 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of method 600 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of method 600 can be combined or skipped. Method 600 can be similar or identical to the acts performed by system 203 (FIGS. 2-4) in workflow 300 (FIG. 3). In many embodiments, the payment item can include one of a check or an ACH item.

Referring to FIG. 6, method 600 can include a block 601 of receiving a first inquiry through a network from a first entity. The first entity can be similar or identical to first financial institution 202 (FIGS. 2-4). The network can be similar or identical to network 120 (FIG. 1). The first inquiry can be similar or identical to the inquiry sent from first financial institution 202 (FIGS. 2-4) to system 203 (FIGS. 2-4) in activity 314 (FIG. 3), and block 610 can be similar or identical to activity 315 (FIG. 3). In a number of embodiments, the first inquiry can be received from the first entity in real time after the first entity receives the payment item. For example, the first entity can receive the payment item similarly or identical to first financial institution 202 (FIGS. 2-4) receiving the payment item in activity 312 (FIG. 3).

In many embodiments, method 600 additionally can include a block 602 of determining a routing decision of whether or not to route the first inquiry to a second entity. Block 602 of determining the routing decision can be similar or identical to activity 315 (FIG. 3) of system 203 (FIGS. 2-4) determining whether to route the inquiry to second financial institution 204 (FIGS. 2-3). The second entity can be similar or identical to second financial institution 204 (FIGS. 2-3). In many embodiments, the first entity can be different from the second entity. In various embodiments, the second entity can be a depository financial institution that is specified by the payment item as responsible for paying the payment item. In a number of embodiments, the routing decision can be based at least in part on a risk of non-payment of the payment item by the second entity. In some embodiments, the payment item can be a check, the first entity can be a depository financial institution receiving the check for deposit, and the second entity can be a depository financial institution against which the check has been drawn. In other embodiments, the payment item can be an ACH item, the first entity can be an originating depository financial institution (ODFI) for the ACH item, and the second entity can be a receiving depository financial institution (RDFI) for the ACH item.

In several embodiments, determining the routing decision can include determining the routing decision based at least on part on account data received from a plurality of financial institutions for accounts maintained by the financial institutions. The financial institutions can be similar or identical to financial institutions 131-134 (FIG. 1), first financial institution 202 (FIGS. 2-4), and/or second financial institution 204 (FIGS. 2-3). In various embodiments, the account data can be received before receiving the first inquiry. In many embodiments, the plurality of financial institutions can include the second entity. In some embodiments, the payment item can specify for payment a first account of the accounts. In a number of embodiments, the first account can be maintained by the second entity. In some embodiments, the account data can include first account data for the first account.

In various embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when it is determined, based on the first account data, that the first account is not valid. In many embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when it is determined, based on the first account data, that the first account has been closed for a predetermined amount of time. In a number of embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when the payment item comprises an ACH item and it is determined, based on the first account data, that the first account has a post no debits status. In some embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when the payment item comprises a check and it is determined, based on the first account data, that the first account has a stop payment on the check. In several embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when the payment item comprises a check and it is determined, based on the first account data, the first account uses positive pay verification. In various embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when it is determined, based on the first account data, the payment item is likely a duplicate. In many embodiments, determining the routing decision further can include determining the routing decision such that the routing decision is to not route the first inquiry to the second entity when, based on the first account data, a payment amount of payment item is determined to be below a predetermined threshold amount.

In some embodiments, method 600 further can include, if the routing decision is to not route the first inquiry to the second entity, a block 603 of sending a first response through the network to the first entity in real time after receiving the first inquiry. Block 603 can be similar or identical to activity 316 (FIG. 3), and the first response can be similar or identical to the response sent from system 203 (FIGS. 2-4) to first financial institution 202 (FIGS. 2-4) in activity 316 (FIG. 3). In some embodiments, sending the first response to the first entity can include sending the first response such that the first response includes information derived in determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3).

In certain embodiments, method 600 can optionally include, if the routing decision is to route the first inquiry to the second entity, a block 604 of sending an informational message through the network to the second entity in real time after receiving the first inquiry. In some embodiments, the informational message can include information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3), and block 604 can be similar or identical to activity 317 (FIG. 3).

In many embodiments, method 600 additionally can include, if the routing decision is to route the first inquiry to the second entity, after block 602 or block 604, a block 605 of sending a second inquiry through the network to the second entity in real time after receiving the first inquiry. The second inquiry can be similar or identical to the inquiry sent from system 203 (FIGS. 2-4) to second financial institution 204 (FIGS. 2-3) in activity 317 (FIG. 3), and block 605 can be similar to activity 317 (FIG. 3). In various embodiments, the second inquiry can be based at least in part on the first inquiry. In some embodiments, the first and/or second inquiries can include a routing number of the second entity that is specified by the payment item; an account number of the second entity that is specified by the payment item; a payment amount that is specified by the payment item; an identifier of the first entity; a transaction channel identifier that indicates the channel through which a transacting entity presented the payment item to the first entity; a payment distribution method identifier that indicates how the transacting entity requested to be paid for the payment item by the first entity; an account number of the first entity associated with the transacting entity; and/or, if the payment item is a check, a serial number of the check. In some embodiments, sending the second inquiry to the second entity can include sending the second inquiry such that the second inquiry further includes information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3).

In certain embodiments, method 600 can optionally include, such as in some embodiments when block 604 was skipped, a block 606 of receiving a request for additional information through the network from the second entity.

In certain embodiments, method 600 can further optionally include, after block 606, a block 607 of sending an informational message through the network to the second entity in real time after receiving the request for additional information. The informational message can include information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3). Blocks 606 and 607 can be similar to activity 317 (FIG. 3).

In many embodiments, method 600 additionally can include, after block 605 or block 607, a block 608 of receiving a second response through the network from the second entity. The first response can be similar or identical to the response sent from second financial institution 204 (FIGS. 2-3) to system 203 (FIGS. 2-4) in activity 319 (FIG. 3), and block 608 can be similar or identical to activity 319 (FIG. 3). In various embodiments, the first response can be sent by the second entity in real time in response to receiving the second inquiry.

In some embodiments, method 600 further can include a block 609 of storing the second response received from the second entity along with a timestamp that indicates when the second response was received from the second entity. Block 609 of storing the second response can be similar or identical to activity 320 (FIG. 3) of system 203 (FIGS. 2-4) storing the response sent from second financial institution 204 (FIGS. 2-3).

In many embodiments, method 600 additionally can include a block 610 of sending a third response through the network to the first entity in real time after receiving the second response. The third response can be similar or identical to the response sent from system 203 (FIGS. 2-4) to first financial institution 202 (FIGS. 2-4) in activity 321 (FIG. 3), and block 610 can be similar or identical to activity 321 (FIG. 3). In various embodiments, the third response can be based at least in part on the second response. In some embodiments, the second and/or third responses can include a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item. The payment likelihood indicator can be similar or identical to the payment likelihood indicator determined by second financial institution 204 (FIGS. 2-3) in activity 318 (FIG. 3). In various embodiments, the payment likelihood indicator can be based at least in part on a current status and a current available balance of an account maintained by the second entity that is specified by the payment item for payment of the payment item. In some embodiments, the one or more processing modules (e.g., system 203 (FIGS. 2-4) can be in data communication through the network with a plurality of financial institutions that have each agreed to apply common standards for determining the payment likelihood indicator. The financial institutions can be similar or identical to financial institutions 131-134 (FIG. 1), first financial institution 202 (FIGS. 2-4), and/or second financial institution 204 (FIGS. 2-3). The common standards can be similar or identical to the common consortium rules described above in connection with activity 318 (FIG. 3). In several embodiments, the second entity can be any one of the plurality of financial institutions, as specified by the payment item. In some embodiments, sending the third response to the first entity can include sending the third response such that the third response further includes information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3).

In a number of embodiments, the payment likelihood indicator in the second and/or third responses can include an indication of whether or not the second entity guarantees payment of the payment item. In many embodiments, the payment likelihood indicator in the second and/or third responses can include a score. The score can be similar or identical to the payment likelihood score determined by second financial institution 204 (FIGS. 2-3) in activity 217 (FIG. 2). In various embodiments, the second and/or third responses each can further include one or more reason indicators to explain the payment likelihood indicator provided by the second entity. The reason indicators can be similar or identical to the reason indicators determined by second financial institution 204 (FIGS. 2-3) in activity 217 (FIG. 2). In various embodiments, one of the first response or the third response can be sent within 30 seconds of receiving the first inquiry.

In certain embodiments, method 600 optionally can include, after block 603 or block 610, a block 611 of sending an informational message through the network to the second entity including information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3).

In certain embodiments, method 600 optionally can include, after block 603 or block 610, a block 612 of receiving a first payment decision message through the network from the first entity that indicates whether the first entity paid the payment item. For example, the first payment decision message can be similar to the payment decision message received by system 203 (FIGS. 2-4) in activity 323 (FIG. 3), and block 612 can be similar or identical to activity 323 (FIG. 3).

In certain embodiments, method 600 can include, after block 612, a block 613 of sending a second payment decision message through the network to the second entity, the second payment decision message being based at least in part on the first payment decision message. For example, the second payment decision message can be similar to the payment decision message sent by system 203 (FIGS. 2-4) in activity 325 (FIG. 3), and block 613 can be similar or identical to activity 325 (FIG. 3). In many embodiments, sending the second payment decision message to the second entity can include sending the second payment message such that the second payment message further includes information derived from determining the routing decision. For example, the information can be similar or identical to the decision information generated by system 203 (FIGS. 2-4) in activity 315 (FIG. 3).

Turning ahead in the drawings, FIG. 7 illustrates a flow chart for a method 700 to facilitate determining an availability of funds for a payment item, according to an embodiment. Method 700 is merely exemplary and is not limited to the embodiments presented herein. Method 700 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of method 700 can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of method 700 can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of method 700 can be combined or skipped. Method 700 can be similar or identical to the acts performed by system 203 (FIGS. 2-4) in workflow 400 (FIG. 5). In many embodiments, the payment item can include one of a check or an ACH item.

Referring to FIG. 7, method 700 can include a block 701 of receiving at least hourly updated account data comprising current statuses and current available balances of accounts maintained by one or more depository financial institutions. The financial institutions can be similar or identical to financial institutions 131-134 (FIG. 1), first financial institution 202 (FIGS. 2-4), and/or second financial institution 204 (FIGS. 2-3).

In many embodiments, method 700 additionally can include a block 702 of receiving an inquiry through a network from a first entity. The first entity can be similar or identical to first financial institution 202 (FIGS. 2-4). The network can be similar or identical to network 120 (FIG. 1). The inquiry can be similar or identical to the inquiry sent from first financial institution 202 (FIGS. 2-4) to system 203 (FIGS. 2-4) in activity 414 (FIG. 4), and block 702 can be similar or identical to activity 414 (FIG. 4). In a number of embodiments, the inquiry can be received from the first entity in real time after the first entity receives the payment item. For example, the first entity can receive the payment item similarly or identical to first financial institution 202 (FIGS. 2-4) receiving the payment item in activity 412 (FIG. 3). In various embodiments, the payment item can specify a second entity as responsible for paying the payment item. The second entity can be similar or identical to second financial institution 204 (FIGS. 2-3). In many embodiments, the first entity can be different from the second entity. In some embodiments, the payment item can specify an account maintained by the second entity for payment of the payment item. In a number of embodiments, one of the one or more depository financial institutions can include the second entity.

In a number of embodiments, the payment item can be a check, the first entity can be a depository financial institution receiving the check for deposit, and the second entity can be a depository financial institution against which the check has been drawn. In other embodiments, the payment item can be an ACH item, the first entity can be an originating depository financial institution (ODFI) for the ACH item, and the second entity can be a receiving depository financial institution (RDFI) for the ACH item. In several embodiments, the inquiry can include a routing number of the second entity that is specified by the payment item; an account number maintained by the second entity that is specified by the payment item; a payment amount that is specified by the payment item; an identifier of the first entity; a transaction channel identifier that indicates the channel through which a transacting entity presented the payment item to the first entity; a payment distribution method identifier that indicates how the transacting entity requested to be paid for the payment item by the first entity; an account number of the first entity associated with the transacting entity; and/or, if the payment item is a check, a serial number of the check.

In some embodiments, method 700 further can include a block 703 of determining a payment likelihood indicator based at least in part on a status and an available balance of the account as updated by the updated account data. The payment likelihood indicator can be similar or identical to the payment likelihood indicator determined by second financial institution 204 (FIGS. 2-3) in activity 415 (FIG. 4), and block 703 can be similar to activity 415 (FIG. 4).

In many embodiments, method 700 additionally can include a block 704 of storing the payment likelihood indicator. For example, block 704 of storing the payment likelihood indicator can be similar or identical to activity 417 (FIG. 4) of system 203 (FIGS. 2-4) storing the payment likelihood indicator.

In some embodiments, method 700 further can include a block 705 of sending a response through the network to the first entity in real time after receiving the inquiry. The response can be similar or identical to the response sent from system 203 (FIGS. 2-4) to first financial institution 202 (FIGS. 2-4) in activity 418 (FIG. 4), and block 705 can be similar or identical to activity 418 (FIG. 4). In a number of embodiments, the response can include the payment likelihood indicator.

In various embodiments, the payment likelihood indicator can indicate a likelihood of the second entity to pay the payment item. In a number of embodiments, the payment likelihood indicator in the response can include an indication of whether or not the second entity guarantees payment of the payment item. In many embodiments, the payment likelihood indicator in the response can include a score. The score can be similar or identical to the payment likelihood score determined by system 203 (FIGS. 2-4) in activity 415 (FIG. 4). In various embodiments, the response can further include one or more reason indicators to explain the payment likelihood indicator. The reason indicators can be similar or identical to the reason indicators determined by system 203 (FIGS. 2-3) in activity 415 (FIG. 4). In various embodiments, the response can be sent within 30 seconds of receiving the inquiry.

Returning to FIG. 1, as described above, system 110 can include one or more modules, such as communications module 112, data module 113, risk engine 114, and/or likelihood calculation engine 115. System 110 and the modules therein are merely exemplary and are not limited to the embodiments presented herein. System 110 can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements or modules of system 110 can perform various procedures, processes, and/or acts. In other embodiments, the procedures, processes, and/or acts can be performed by other suitable elements or modules.

In many embodiments, communications module 112 can at least partially perform block 502 (FIG. 5) of receiving a first inquiry at the processing mechanism through the network from the first entity, block 504 (FIG. 5) of sending a second inquiry from the processing mechanism through the network to the second entity in real time after receiving the first inquiry, block 505 (FIG. 5) of receiving a first response at the processing mechanism through the network from the second entity, block 507 (FIG. 5) of sending a second response from the processing mechanism through the network to the first entity in real time after receiving the first response, block 601 (FIG. 6) of receiving a first inquiry through a network from a first entity, block 603 (FIG. 6) of sending a first response through the network to the first entity in real time after receiving the first inquiry, block 604 (FIG. 6) of sending an informational message through the network to the second entity in real time after receiving the first inquiry, block 605 (FIG. 6) of sending a second inquiry through the network to the second entity in real time after receiving the first inquiry, block 606 (FIG. 6) of receiving a request for additional information through the network from the second entity, block 607 (FIG. 6) of sending an informational message through the network to the second entity in real time after receiving the request for additional information, block 608 (FIG. 6) of receiving a second response through the network from the second entity, block 610 (FIG. 6) of sending a third response through the network to the first entity in real time after receiving the second response, block 611 (FIG. 6) of sending an informational message through the network to the second entity including information derived from determining the routing decision, block 612 (FIG. 6) of receiving a first payment decision message through the network from the first entity that indicates whether the first entity paid the payment item, block 613 (FIG. 6) of sending a second payment decision message through the network to the second entity, block 701 (FIG. 7) of receiving at least hourly updated account data comprising current statuses and current available balances of accounts maintained by one or more depository financial institutions, block 702 (FIG. 7) of receiving an inquiry through a network from a first entity, and/or block 705 (FIG. 7) of sending a response through the network to the first entity in real time after receiving the inquiry.

In several embodiments, data module 113 can at least partially perform block 503 (FIG. 5) of storing the first inquiry received from the first entity along with a first timestamp that indicates when the first inquiry was received from the first entity, block 506 (FIG. 5) of storing the first response received from the second entity along with a second timestamp that indicates when the first response was received from the second entity, block 609 (FIG. 6) of storing the second response received from the second entity along with a timestamp that indicates when the second response was received from the second entity, and/or block 704 (FIG. 7) of storing the payment likelihood indicator. In some embodiments, module 113 also can perform portions of block 602 (FIG. 6) and block 703 (FIG. 7).

In many embodiments, risk engine 114 can at least partially perform block 602 (FIG. 6) of determining a routing decision of whether or not to route the first inquiry to a second entity. Furthermore, as explained above for activity 320 (FIG. 3), some embodiments of risk engine 114 also can at least partially perform block 609 (FIG. 6) when block 320 (FIG. 3) refines or further determines the payment likelihood after receiving the originally determined payment likelihood from the second financial institution.

In several embodiments, likelihood calculation engine 115 can at least partially perform block 703 (FIG. 7) of determining a payment likelihood indicator based at least in part on a status and an available balance of the account as updated by the updated account data

In various embodiments, the techniques described herein can beneficially connect in real time a depository bank, an originator, or a payment acceptor with information from the paying bank about a payment item in order to deliver more intelligence as to the likelihood that the payment item will pay. These techniques can advantageously provide the paying bank with insight as to check and/or ACH items that will clear in the near term. In many embodiments, the techniques described herein can allow financial institutions to connect to a single entity (e.g., server 110 (FIG. 1) or server 203 (FIGS. 2-4) to connect to multiple financial institutions for query and responses, and/or to access fraud-prevention services.

Turning ahead in the drawings, FIG. 8 illustrates a computer 800, all of which or a portion of which can be suitable for implementing an embodiment of at least a portion of system 110 (FIG. 1) and/or system 203 (FIGS. 2-4), and/or the techniques described in workflow 200 (FIG. 2), workflow 300 (FIG. 3), workflow 400 (FIG. 4), method 500 (FIG. 5), method 600 (FIG. 6), and/or method 700 (FIG. 7). Computer 800 includes a chassis 802 containing one or more circuit boards (not shown), a USB (universal serial bus) port 812, a Compact Disc Read-Only Memory (CD-ROM) and/or Digital Video Disc (DVD) drive 816, and a hard drive 814. A representative block diagram of the elements included on the circuit boards inside chassis 802 is shown in FIG. 9. A central processing unit (CPU) 910 in FIG. 9 is coupled to a system bus 914 in FIG. 9. In various embodiments, the architecture of CPU 910 can be compliant with any of a variety of commercially distributed architecture families.

Continuing with FIG. 9, system bus 914 also is coupled to memory 908 that includes both read only memory (ROM) and random access memory (RAM). Non-volatile portions of memory storage unit 908 or the ROM can be encoded with a boot code sequence suitable for restoring computer 800 (FIG. 8) to a functional state after a system reset. In addition, memory 908 can include microcode such as a Basic Input-Output System (BIOS). In some examples, the one or more memory storage units of the various embodiments disclosed herein can comprise memory storage unit 908, a USB-equipped electronic device, such as, an external memory storage unit (not shown) coupled to universal serial bus (USB) port 812 (FIGS. 8-9), hard drive 814 (FIGS. 8-9), and/or CD-ROM or DVD drive 816 (FIGS. 8-9). In the same or different examples, the one or more memory storage units of the various embodiments disclosed herein can comprise an operating system, which can be a software program that manages the hardware and software resources of a computer and/or a computer network. The operating system can perform basic tasks such as, for example, controlling and allocating memory, prioritizing the processing of instructions, controlling input and output devices, facilitating networking, and managing files. Some examples of common operating systems can comprise Microsoft® Windows® operating system (OS), Mac® OS, UNIX® OS, and Linux® OS.

As used herein, “processor” and/or “processing module” means any type of computational circuit, such as but not limited to a microprocessor, a microcontroller, a controller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a graphics processor, a digital signal processor, or any other type of processor or processing circuit capable of performing the desired functions. In some examples, the one or more processors of the various embodiments disclosed herein can comprise CPU 910.

In the depicted embodiment of FIG. 9, various I/O devices such as a disk controller 904, a graphics adapter 924, a video controller 902, a keyboard adapter 926, a mouse adapter 906, a network adapter 920, and other I/O devices 922 can be coupled to system bus 914. Keyboard adapter 926 and mouse adapter 906 are coupled to a keyboard 804 (FIGS. 8 and 9) and a mouse 810 (FIGS. 8 and 9), respectively, of computer 800 (FIG. 8). While graphics adapter 924 and video controller 902 are indicated as distinct units in FIG. 9, video controller 902 can be integrated into graphics adapter 924, or vice versa in other embodiments. Video controller 902 is suitable for refreshing a monitor 806 (FIGS. 8 and 9) to display images on a screen 808 (FIG. 8) of computer 800 (FIG. 8). Disk controller 904 can control hard drive 814 (FIGS. 8 and 9), USB port 812 (FIGS. 8 and 9), and CD-ROM or DVD drive 816 (FIGS. 8 and 9). In other embodiments, distinct units can be used to control each of these devices separately.

In some embodiments, network adapter 920 can comprise and/or be implemented as a WNIC (wireless network interface controller) card (not shown) plugged or coupled to an expansion port (not shown) in computer system 800 (FIG. 8). In other embodiments, the WNIC card can be a wireless network card built into computer system 800 (FIG. 8). A wireless network adapter can be built into computer system 800 (FIG. 8) by having wireless communication capabilities integrated into the motherboard chipset (not shown), or implemented via one or more dedicated wireless communication chips (not shown), connected through a PCI (peripheral component interconnector) or a PCI express bus of computer system 800 (FIG. 8) or USB port 812 (FIG. 8). In other embodiments, network adapter 920 can comprise and/or be implemented as a wired network interface controller card (not shown).

Although many other components of computer 800 (FIG. 8) are not shown, such components and their interconnection are well known to those of ordinary skill in the art. Accordingly, further details concerning the construction and composition of computer 800 and the circuit boards inside chassis 802 (FIG. 8) need not be discussed herein.

When computer 800 in FIG. 8 is running, program instructions stored on a USB drive in USB port 812, on a CD-ROM or DVD in CD-ROM and/or DVD drive 816, on hard drive 814, or in memory 908 (FIG. 9) are executed by CPU 910 (FIG. 9). A portion of the program instructions, stored on these devices, can be suitable for carrying out all or at least part of the techniques described herein.

Although computer system 800 is illustrated as a desktop computer in FIG. 8, there can be examples where computer system 800 may take a different form factor while still having functional elements similar to those described for computer system 800. In some embodiments, computer system 800 may comprise a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. Typically, a cluster or collection of servers can be used when the demand on computer system 800 exceeds the reasonable capability of a single server or computer. In certain embodiments, computer system 800 may comprise a portable computer, such as a laptop computer. In certain other embodiments, computer system 800 may comprise a mobile device, such as a smartphone. In certain additional embodiments, computer system 800 may comprise an embedded system.

Although real-time determination of funds availability for check and ACH items has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes may be made without departing from the spirit or scope of the disclosure. Accordingly, the disclosure of embodiments is intended to be illustrative of the scope of the disclosure and is not intended to be limiting. It is intended that the scope of the disclosure shall be limited only to the extent required by the appended claims. For example, to one of ordinary skill in the art, it will be readily apparent that any element of FIGS. 1-9 may be modified, and that the foregoing discussion of certain of these embodiments does not necessarily represent a complete description of all possible embodiments. For example, one or more of the procedures, processes, or activities of FIGS. 2-7 may include different procedures, processes, and/or activities and be performed by many different modules, in many different orders.

Replacement of one or more claimed elements constitutes reconstruction and not repair. Additionally, benefits, other advantages, and solutions to problems have been described with regard to specific embodiments. The benefits, advantages, solutions to problems, and any element or elements that may cause any benefit, advantage, or solution to occur or become more pronounced, however, are not to be construed as critical, required, or essential features or elements of any or all of the claims, unless such benefits, advantages, solutions, or elements are stated in such claim.

Moreover, embodiments and limitations disclosed herein are not dedicated to the public under the doctrine of dedication if the embodiments and/or limitations: (1) are not expressly claimed in the claims; and (2) are or are potentially equivalents of express elements and/or limitations in the claims under the doctrine of equivalents.

Claims

1. A method to facilitate determining an availability of funds for a payment item, the method comprising: providing a processing system in data communication through a network with a first entity and a plurality of depository financial institutions, the processing system comprising a database, a communications system, and a data system, the plurality of depository financial institutions comprising a second entity, the second entity maintaining a payor account that is specified by the payment item as being responsible for paying the payment item to a payee that is specified by the payment item, the first entity being different from the second entity, and the payment item being one of a check or an ACH item;receiving, using the communications system, a first inquiry at the processing system through the network from the first entity, the first inquiry being received from the first entity in real-time after the payee presents the payment item to the first entity for a payment to the payee based on the payment item though one or more payment methods comprising (a) a cash payment to the payee or (b) a deposit into a payee account of the payee at the first entity, and the first inquiry being received from the first entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods;storing in the database, using the data system, the first inquiry received from the first entity;sending, using the communications system, a second inquiry from the processing system through the network to the second entity in real-time after receiving the first inquiry, the second inquiry being based at least in part on the first inquiry, and the second inquiry being sent to the second entity before the first entity pays the payee through any of the one or more payment methods;receiving, using the communications system, a first response at the processing system through the network from the second entity, the first response being sent by the second entity in real-time in response to receiving the second inquiry, the first response comprising a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item, the payment likelihood indicator being based at least in part on a current status and a current available balance of the payor account maintained at the second entity, and the first response being received from the second entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods;storing in the database, using the data system, the first response received from the second entity; andsending, using the communications system, a second response from the processing system through the network to the first entity in real-time after receiving the first response, the second response being based at least in part on the first response, the second response comprising the payment likelihood indicator provided by the second entity, and the second response, including the payment likelihood indicator, being sent to the first entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods, such that the first entity determines whether to approve the payment to the payee based at least in part on the payment likelihood indicator provided by the second entity, and such that the first entity notifies the payee whether the payment is approved by the first entity,wherein the second inquiry comprises: a transaction channel identifier that indicates a channel through which the payee presented the payment item to the first entity, the channel comprising at least one of an automated teller machine, a teller, mail, online, remote deposit capture, lock-box, in-store, or check processor; anda payment distribution method identifier that indicates how the payee requested to be paid for the payment item by the first entity, the payment distribution method identifier comprising at least one of cash or deposit.
2. The method of claim 1, wherein: the payment item comprises the check; andthe first entity is a depository financial institution receiving the check for deposit; andthe second entity is a depository financial institution against which the check has been drawn.
3. The method of claim 1, wherein: the payment item comprises the ACH item;the first entity is an originating depository financial institution for the ACH item; andthe second entity is a receiving depository financial institution for the ACH item.
4. The method of claim 1, wherein: the first entity is at least one of a payment processor or a third party acting on behalf of an originating depository financial institution; andthe second entity is a financial institution.
5. The method of claim 1, wherein: the first inquiry comprises an identifier linked to the payor account maintained by the second entity that is specified by the payment item.
6. The method of claim 1, wherein the second inquiry further comprises: a routing number of the second entity that is specified by the payment item;an account number of the payor account maintained by the second entity that is specified by the payment item;a payment amount that is specified by the payment item;an identifier of the first entity;an account number of the payee account at the first entity; andif the payment item is the check, a serial number of the check.
7. The method of claim 1, wherein the payment likelihood indicator in the first and second responses comprises an indication of whether or not the second entity guarantees paying the payment item.
8. The method of claim 1, wherein the payment likelihood indicator in the first and second responses comprises a score.
9. The method of claim 1, wherein the first and second responses each further comprise one or more reason indicators to explain the payment likelihood indicator provided by the second entity.
10. The method of claim 1, wherein: the second response is sent within 30 seconds of receiving the first inquiry;storing the first inquiry comprises storing the first inquiry along with a first timestamp that indicates when the first inquiry was received from the first entity; andstoring the first response comprises storing the first response along with a second timestamp that indicates when the first response was received from the second entity.
11. A system to facilitate determining an availability of funds for a payment item, the system comprising: a database;a communications system;a data system;one or more processors in data communication through a network with a first entity and a plurality of depository financial institutions, the plurality of depository financial institutions comprising a second entity, the second entity maintaining a payor account that is specified by the payment item as being responsible for paying the payment item to a payee that is specified by the payment item, the first entity being different from the second entity, and the payment item being one of a check or an ACH item; andone or more non-transitory computer-readable media storing computing instructions configured to run on the one or more processors and perform: receiving, using the communications system, a first inquiry through the network from the first entity, the first inquiry being received from the first entity in real-time after the payee presents the payment item to the first entity for a payment to the payee based on the payment item though one or more payment methods comprising (a) a cash payment to the payee or (b) a deposit into a payee account of the payee at the first entity, and the first inquiry being received from the first entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods;storing in the database, using the data system, the first inquiry received from the first entity;sending, using the communications system, a second inquiry through the network to the second entity in real-time after receiving the first inquiry, the second inquiry being based at least in part on the first inquiry, and the second inquiry being sent to the second entity before the first entity pays the payee through any of the one or more payment methods;receiving, using the communications system, a first response through the network from the second entity, the first response being sent by the second entity in real-time in response to receiving the second inquiry, the first response comprising a payment likelihood indicator provided by the second entity that indicates a likelihood of the second entity to pay the payment item, the payment likelihood indicator being based at least in part on a current status and a current available balance of the payor account maintained at the second entity, and the first response being received from the second entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods;storing in the database, using the data system, the first response received from the second entity; andsending, using the communications system, a second response through the network to the first entity in real-time after receiving the first response, the second response being based at least in part on the first response, the second response comprising the payment likelihood indicator provided by the second entity, and the second response, including the payment likelihood indicator, being sent to the first entity before the payment is approved by the first entity and before the first entity pays the payee through any of the one or more payment methods, such that the first entity determines whether to approve the payment transaction to the payee based at least in part on the payment likelihood indicator provided by the second entity, and such that the first entity notifies the payee whether the payment is approved by the first entity,wherein the second inquiry comprises: a transaction channel identifier that indicates a channel through which the payee presented the payment item to the first entity, the channel comprising at least one of an automated teller machine, a teller, mail, online, remote deposit capture, lock-box, in-store, or check processor; anda payment distribution method identifier that indicates how the payee requested to be paid for the payment item by the first entity, the payment distribution method identifier comprising at least one of cash or deposit.
12. The system of claim 11, wherein: the payment item comprises the check; andthe first entity is a depository financial institution receiving the check for deposit; andthe second entity is a depository financial institution against which the check has been drawn.
13. The system of claim 11, wherein: the payment item comprises the ACH item;the first entity is an originating depository financial institution for the ACH item; andthe second entity is a receiving depository financial institution for the ACH item.
14. The system of claim 11, wherein: the first entity is at least one of a payment processor or a third party acting on behalf of an originating depository financial institution; andthe second entity is a financial institution.
15. The system of claim 11, wherein: the first inquiry comprises an identifier for the payor account maintained by the second entity that is specified by the payment item.
16. The system of claim 11, wherein the second inquiry further comprises: a routing number of the second entity that is specified by the payment item;an account number of the payor account maintained by the second entity that is specified by the payment item;a payment amount that is specified by the payment item;an identifier of the first entity;an account number of the payee account at the first entity; andif the payment item is the check, a serial number of the check.
17. The system of claim 11, wherein the payment likelihood indicator in the first and second responses comprises an indication of whether or not the second entity guarantees paying the payment item.
18. The system of claim 11, wherein the payment likelihood indicator in the first and second responses comprises a score.
19. The system of claim 11, wherein the first and second responses each further comprise one or more reason indicators to explain the payment likelihood indicator provided by the second entity.
20. The system of claim 11, wherein: the second response is sent within 30 seconds of receiving the first inquiry;storing the first inquiry comprises storing the first inquiry along with a first timestamp that indicates when the first inquiry was received from the first entity; andstoring the first response comprises storing the first response along with a second timestamp that indicates when the first response was received from the second entity.

US Referenced Citations (653)

Number	Name	Date	Kind
2011032	Blanchard	Aug 1935	A
5229764	Matchett et al.	Jul 1993	A
5265007	Barnhard, Jr. et al.	Nov 1993	A
5282249	Cohen et al.	Jan 1994	A
5283829	Anderson	Feb 1994	A
5329589	Fraser et al.	Jul 1994	A
5383113	Kight et al.	Jan 1995	A
5453601	Rosen	Sep 1995	A
5455407	Rosen	Oct 1995	A
5465206	Hilt et al.	Nov 1995	A
5481609	Cohen et al.	Jan 1996	A
5619657	Sudama et al.	Apr 1997	A
5642419	Rosen	Jun 1997	A
5649117	Landry	Jul 1997	A
5652786	Rogers	Jul 1997	A
5671280	Rosen	Sep 1997	A
5677955	Doggett et al.	Oct 1997	A
5699528	Hogan	Dec 1997	A
5703344	Bezy et al.	Dec 1997	A
5729594	Klingman	Mar 1998	A
5745886	Rosen	Apr 1998	A
5781723	Yee et al.	Jul 1998	A
5790677	Fox et al.	Aug 1998	A
5826241	Stein et al.	Oct 1998	A
5832460	Bednar et al.	Nov 1998	A
5848161	Luneau et al.	Dec 1998	A
5848400	Chang	Dec 1998	A
5870473	Boesch et al.	Feb 1999	A
5873072	Kight et al.	Feb 1999	A
5878141	Daly et al.	Mar 1999	A
5884288	Chang et al.	Mar 1999	A
5889863	Weber	Mar 1999	A
5903721	Sixtus	May 1999	A
5913203	Wong et al.	Jun 1999	A
5915023	Bernstein	Jun 1999	A
5920847	Kolling et al.	Jul 1999	A
5920848	Schutzer et al.	Jul 1999	A
5946669	Polk	Aug 1999	A
5956700	Landry	Sep 1999	A
5970475	Barnes et al.	Oct 1999	A
5978840	Nguyen et al.	Nov 1999	A
5983208	Haller et al.	Nov 1999	A
5987132	Rowney	Nov 1999	A
5987140	Rowney et al.	Nov 1999	A
5996076	Rowney et al.	Nov 1999	A
5999625	Bellare et al.	Dec 1999	A
6002767	Kramer	Dec 1999	A
6016484	Williams et al.	Jan 2000	A
6029150	Kravitz	Feb 2000	A
6032133	Hilt et al.	Feb 2000	A
6035285	Schlect et al.	Mar 2000	A
6039250	Ito et al.	Mar 2000	A
6044362	Neely	Mar 2000	A
6049786	Smorodinsky	Apr 2000	A
6058380	Anderson et al.	May 2000	A
6061665	Bahreman	May 2000	A
6070150	Remington et al.	May 2000	A
6072870	Nguyen et al.	Jun 2000	A
6078907	Lamm	Jun 2000	A
6081790	Rosen	Jun 2000	A
6085168	Mori et al.	Jul 2000	A
6112181	Shear et al.	Aug 2000	A
6119101	Peckover	Sep 2000	A
6119106	Mersky et al.	Sep 2000	A
6119107	Polk	Sep 2000	A
6125352	Franklin et al.	Sep 2000	A
6128603	Dent et al.	Oct 2000	A
6138107	Elgamal	Oct 2000	A
6145738	Stinson et al.	Nov 2000	A
6167378	Webber, Jr.	Dec 2000	A
6173272	Thomas et al.	Jan 2001	B1
6236981	Hill	May 2001	B1
6246996	Stein et al.	Jun 2001	B1
6260024	Shkedy	Jul 2001	B1
6285991	Powar	Sep 2001	B1
6289322	Kitchen et al.	Sep 2001	B1
6292211	Pena	Sep 2001	B1
6292789	Schutzer	Sep 2001	B1
6304857	Heindel et al.	Oct 2001	B1
6304860	Martin, Jr. et al.	Oct 2001	B1
6311170	Embrey	Oct 2001	B1
6317745	Thomas et al.	Nov 2001	B1
6334116	Ganesan et al.	Dec 2001	B1
6381582	Walker et al.	Apr 2002	B1
6385595	Kolling	May 2002	B1
6411942	Fujimoto	Jun 2002	B1
6438527	Powar	Aug 2002	B1
6446051	Gupta	Sep 2002	B1
6488203	Stoutenburg et al.	Dec 2002	B1
6502747	Stoutenburg et al.	Jan 2003	B1
6578015	Haseltine et al.	Jun 2003	B1
6587550	Council et al.	Jul 2003	B2
6594647	Randle et al.	Jul 2003	B1
6609114	Gressel et al.	Aug 2003	B1
6647376	Farrar et al.	Nov 2003	B1
6678664	Ganesan	Jan 2004	B1
6839687	Dent et al.	Jan 2005	B1
6847708	Abbasi et al.	Jan 2005	B1
6868391	Hultgren	Mar 2005	B1
6882986	Heinemann et al.	Apr 2005	B1
6891953	DeMello et al.	May 2005	B1
6968319	Remington et al.	Nov 2005	B1
6996542	Landry	Feb 2006	B1
7003480	Fox et al.	Feb 2006	B2
7004382	Sandru	Feb 2006	B2
7010512	Gillin et al.	Mar 2006	B1
7031939	Gallagher et al.	Apr 2006	B1
7035821	Smith, II et al.	Apr 2006	B1
7039951	Chaudhari et al.	May 2006	B1
7051001	Slater	May 2006	B1
7089208	Levchin et al.	Aug 2006	B1
7098783	Crichlow	Aug 2006	B2
7103261	Grecia	Sep 2006	B2
7120606	Ranzini et al.	Oct 2006	B1
7120608	Gallagher et al.	Oct 2006	B1
7133835	Fusz et al.	Nov 2006	B1
7184980	Allen-Rouman et al.	Feb 2007	B2
7191151	Nosek	Mar 2007	B1
7200551	Senez	Apr 2007	B1
7206938	Bender et al.	Apr 2007	B2
7227950	Faith et al.	Jun 2007	B2
7240031	Kight et al.	Jul 2007	B1
7249098	Milberger et al.	Jul 2007	B2
7254235	Boudreault et al.	Aug 2007	B2
7287009	Liebermann	Oct 2007	B1
7296004	Garrison et al.	Nov 2007	B1
7302411	Ganesan et al.	Nov 2007	B2
7319855	Brune et al.	Jan 2008	B1
7321874	Dilip et al.	Jan 2008	B2
7321875	Dilip et al.	Jan 2008	B2
7333953	Banaugh et al.	Feb 2008	B1
7343014	Sovio et al.	Mar 2008	B2
7349871	Labrou et al.	Mar 2008	B2
7353203	Kriplani et al.	Apr 2008	B1
7366695	Allen-Rouman et al.	Apr 2008	B1
7370014	Vasavada et al.	May 2008	B1
7376587	Neofytides et al.	May 2008	B1
7383223	Dilip et al.	Jun 2008	B1
7383226	Kight et al.	Jun 2008	B2
7389917	Abraham et al.	Jun 2008	B2
7392223	Ganesan et al.	Jun 2008	B1
7395241	Cook et al.	Jul 2008	B1
7398252	Neofytides et al.	Jul 2008	B2
7426492	Bishop et al.	Sep 2008	B1
7450010	Gravelle et al.	Nov 2008	B1
7451114	Matsuda et al.	Nov 2008	B1
7475039	Remington et al.	Jan 2009	B2
7475808	Bishop et al.	Jan 2009	B1
7478066	Remington et al.	Jan 2009	B2
7499887	Boyle et al.	Mar 2009	B2
7505937	Dilip et al.	Mar 2009	B2
7519560	Lam et al.	Apr 2009	B2
7526650	Wimmer	Apr 2009	B1
7532122	Aull et al.	May 2009	B2
7536722	Saltz et al.	May 2009	B1
7596701	Varghese et al.	Sep 2009	B2
7603311	Yadav-Ranjan	Oct 2009	B1
7606734	Baig et al.	Oct 2009	B2
7606787	Keown et al.	Oct 2009	B2
7610245	Dent et al.	Oct 2009	B2
7613653	Milberger et al.	Nov 2009	B2
7620602	Jakstadt et al.	Nov 2009	B2
7644037	Ostrovsky	Jan 2010	B1
7653591	Dabney	Jan 2010	B1
7657497	Nandy	Feb 2010	B2
7677438	DeJean et al.	Mar 2010	B2
7685067	Britto et al.	Mar 2010	B1
7689482	Lam et al.	Mar 2010	B2
7693791	Hahn-Carlson et al.	Apr 2010	B2
7702579	Neely et al.	Apr 2010	B2
7707082	Lapstun et al.	Apr 2010	B1
7707107	Gebb et al.	Apr 2010	B2
7711690	Garrison et al.	May 2010	B1
7716127	Gebb et al.	May 2010	B2
7716132	Spies et al.	May 2010	B1
7720754	Gutierrez-Sheris	May 2010	B1
7720756	Kavounas	May 2010	B2
7734543	Braco	Jun 2010	B2
7752130	Byrd et al.	Jul 2010	B2
7756785	Gebb et al.	Jul 2010	B2
7756786	Trende et al.	Jul 2010	B2
7765156	Staniar et al.	Jul 2010	B2
7769687	Gebb et al.	Aug 2010	B2
7769998	Lynch et al.	Aug 2010	B2
7774271	Edwards et al.	Aug 2010	B1
7778901	Ganesan et al.	Aug 2010	B2
7783567	Kleiman et al.	Aug 2010	B1
7792749	Ganesan	Sep 2010	B2
7809650	Bruesewitz et al.	Oct 2010	B2
7840520	Nandy	Nov 2010	B2
7848972	Sharma	Dec 2010	B1
7856384	Kulasooriya et al.	Dec 2010	B1
7870070	Meier et al.	Jan 2011	B2
7873573	Realini	Jan 2011	B2
7877325	Bishop et al.	Jan 2011	B2
7885869	Uehara et al.	Feb 2011	B2
7899744	Bishop et al.	Mar 2011	B2
7904385	Bishop et al.	Mar 2011	B2
7908214	Bishop et al.	Mar 2011	B2
7925585	Bishop et al.	Apr 2011	B2
7937312	Woolston	May 2011	B1
7941367	Bishop et al.	May 2011	B2
7941372	Bishop et al.	May 2011	B2
7942321	Linton et al.	May 2011	B2
7945491	Sharma	May 2011	B2
7953660	Ganesan et al.	May 2011	B2
7958030	Kemper et al.	Jun 2011	B2
7958049	Jamison et al.	Jun 2011	B2
7962406	Bishop et al.	Jun 2011	B2
7962407	Bishop et al.	Jun 2011	B2
7962408	Bishop et al.	Jun 2011	B2
7970706	Keene	Jun 2011	B2
7979348	Thomas et al.	Jul 2011	B2
7979349	Bishop et al.	Jul 2011	B2
7996307	Bishop et al.	Aug 2011	B2
7996310	Edwards et al.	Aug 2011	B1
8001612	Wieder	Aug 2011	B1
8020005	Mani et al.	Sep 2011	B2
8041606	Mascavage, III et al.	Oct 2011	B2
8050997	Nosek et al.	Nov 2011	B1
8060389	Johnson	Nov 2011	B2
8069115	Schoenberg et al.	Nov 2011	B2
8073772	Bishop et al.	Dec 2011	B2
8073773	Kozee et al.	Dec 2011	B2
8086497	Oakes, III	Dec 2011	B1
8103584	Bishop et al.	Jan 2012	B2
8103585	Bishop et al.	Jan 2012	B2
8112354	Lalwani	Feb 2012	B2
8121894	Mason	Feb 2012	B2
8121945	Rackley et al.	Feb 2012	B2
8123124	Salazar et al.	Feb 2012	B2
8126793	Jones	Feb 2012	B2
8165934	Manista et al.	Apr 2012	B2
8165958	McLaughlin et al.	Apr 2012	B1
8180706	Bishop et al.	May 2012	B2
8190514	Bishop et al.	May 2012	B2
8195565	Bishop et al.	Jun 2012	B2
8229850	Dilip et al.	Jul 2012	B2
8234212	Bishop et al.	Jul 2012	B2
8244609	Prakash et al.	Aug 2012	B2
8249965	Tumminaro	Aug 2012	B2
8249983	Dilip et al.	Aug 2012	B2
8255278	Young et al.	Aug 2012	B1
8255327	Kemper et al.	Aug 2012	B2
8255336	Dilip et al.	Aug 2012	B2
8266028	Bulman et al.	Sep 2012	B2
8266065	Dilip et al.	Sep 2012	B2
8275704	Bishop et al.	Sep 2012	B2
8290835	Homer et al.	Oct 2012	B2
8290862	Sheehan et al.	Oct 2012	B2
8290863	Sheehan et al.	Oct 2012	B2
8311913	Marchetti et al.	Nov 2012	B2
8311914	Marchetti et al.	Nov 2012	B2
8311937	Marchetti et al.	Nov 2012	B2
8311942	Mason	Nov 2012	B1
8321341	Nandy	Nov 2012	B2
8310346	Burbridge et al.	Dec 2012	B2
8341046	Marchetti et al.	Dec 2012	B2
8342407	Williams et al.	Jan 2013	B2
8352365	Goldberg et al.	Jan 2013	B1
8370639	Azar et al.	Feb 2013	B2
8374932	Marchetti et al.	Feb 2013	B2
8380177	Laracey	Feb 2013	B2
8380591	Kazenas et al.	Feb 2013	B1
8380622	Bushman et al.	Feb 2013	B2
8401939	Lam et al.	Mar 2013	B2
8402555	Grecia	Mar 2013	B2
8407124	Uehara et al.	Mar 2013	B2
8407141	Mullen et al.	Mar 2013	B2
8417628	Poplawski et al.	Apr 2013	B2
8423460	Kay et al.	Apr 2013	B2
8433629	Murtaugh et al.	Apr 2013	B2
8458086	Bishop et al.	Jun 2013	B2
8458774	Ganesan	Jun 2013	B2
8467766	Rackley et al.	Jun 2013	B2
8484104	Hurlbutt et al.	Jul 2013	B1
8498914	Hazelhurst	Jul 2013	B2
8521657	Kuebert et al.	Aug 2013	B2
8527413	Heller	Sep 2013	B2
8532021	Tumminaro	Sep 2013	B2
8533079	Sharma	Sep 2013	B2
8533860	Grecia	Sep 2013	B1
8549601	Ganesan	Oct 2013	B2
8560417	Mullen et al.	Oct 2013	B2
8596527	Bishop et al.	Dec 2013	B2
8606640	Brody et al.	Dec 2013	B2
8615457	Mullen et al.	Dec 2013	B2
8634559	Brown et al.	Jan 2014	B2
8646685	Bishop et al.	Feb 2014	B2
8666865	Mullen et al.	Mar 2014	B2
8706641	Bruesewitz et al.	Apr 2014	B2
8713325	Ganesan	Apr 2014	B2
8719905	Ganesan	May 2014	B2
8738526	Nosek et al.	May 2014	B2
8745699	Ganesan	Jun 2014	B2
8751347	Mullen et al.	Jun 2014	B2
8768838	Hoffman	Jul 2014	B1
8769784	Ganesan et al.	Jul 2014	B2
8775306	Nosek et al.	Jul 2014	B2
8789153	Ganesan	Jul 2014	B2
8794509	Bishop et al.	Aug 2014	B2
8806592	Ganesan	Aug 2014	B2
8814039	Bishop et al.	Aug 2014	B2
8820633	Bishop et al.	Sep 2014	B2
8887247	Ganesan	Nov 2014	B2
8887308	Grecia	Nov 2014	B2
8893237	Ganesan	Nov 2014	B2
8938787	Turgeman	Jan 2015	B2
9392008	Michel et al.	Jul 2016	B1
D769296	Grecia	Oct 2016	S
9626664	Bouey et al.	Apr 2017	B2
9691056	Bouey et al.	Jun 2017	B2
D826955	Grecia	Aug 2018	S
10049349	Grassadonia et al.	Aug 2018	B1
D857054	Grecia	Aug 2019	S
D857712	Grecia	Aug 2019	S
20020023054	Gillespie	Feb 2002	A1
20020029193	Ranjan et al.	Mar 2002	A1
20020052852	Bozeman	May 2002	A1
20020091635	Dilip et al.	Jul 2002	A1
20020128932	Yung et al.	Sep 2002	A1
20020143634	Kumar et al.	Oct 2002	A1
20020194119	Wright et al.	Dec 2002	A1
20020194503	Faith et al.	Dec 2002	A1
20030014316	Jaalinoja et al.	Jan 2003	A1
20030097331	Cohen	May 2003	A1
20030115151	Wheeler et al.	Jun 2003	A1
20030126094	Fisher et al.	Jul 2003	A1
20030130919	Templeton	Jul 2003	A1
20030165328	Grecia	Sep 2003	A1
20030220875	Lam et al.	Nov 2003	A1
20030220876	Burger et al.	Nov 2003	A1
20030236728	Sunderji et al.	Dec 2003	A1
20040034594	Thomas et al.	Feb 2004	A1
20040089711	Sandru	May 2004	A1
20040158522	Brown et al.	Aug 2004	A1
20040193522	Binet	Sep 2004	A1
20040230489	Goldthwaite et al.	Nov 2004	A1
20040259626	Akram et al.	Dec 2004	A1
20050008148	Jacobson	Jan 2005	A1
20050010523	Myklebust et al.	Jan 2005	A1
20050010786	Michener et al.	Jan 2005	A1
20050065891	Lee et al.	Mar 2005	A1
20050069135	Brickell	Mar 2005	A1
20050071283	Randle	Mar 2005	A1
20050080716	Belyi	Apr 2005	A1
20050125347	Akialis et al.	Jun 2005	A1
20050137948	Kissner et al.	Jun 2005	A1
20050144452	Lynch et al.	Jun 2005	A1
20050149455	Bruesewitz et al.	Jul 2005	A1
20050187873	Labrou	Aug 2005	A1
20050203959	Muller et al.	Sep 2005	A1
20050246292	Sarcanin	Nov 2005	A1
20050273842	Wright et al.	Dec 2005	A1
20050274793	Cantini et al.	Dec 2005	A1
20050289061	Kulakowski	Dec 2005	A1
20060000892	Bonalle	Jan 2006	A1
20060014532	Seligmann	Jan 2006	A1
20060022048	Johnson	Feb 2006	A1
20060080727	Hammons et al.	Apr 2006	A1
20060085357	Pizarro	Apr 2006	A1
20060106717	Randle	May 2006	A1
20060116949	Wehunt et al.	Jun 2006	A1
20060149632	Bhatti et al.	Jul 2006	A1
20060149635	Bhatti et al.	Jul 2006	A1
20060161772	Talstra et al.	Jul 2006	A1
20060165060	Dua	Jul 2006	A1
20060212401	Ameerally et al.	Sep 2006	A1
20060224470	Ruano et al.	Oct 2006	A1
20060258397	Kaplan et al.	Nov 2006	A1
20060280339	Cho	Dec 2006	A1
20060287004	Fuqua	Dec 2006	A1
20060287963	Steeves et al.	Dec 2006	A1
20070046456	Edwards et al.	Mar 2007	A1
20070061590	Boye et al.	Mar 2007	A1
20070106892	Engberg	May 2007	A1
20070108269	Benco et al.	May 2007	A1
20070136167	Dilip et al.	Jun 2007	A1
20070136168	Dilip et al.	Jun 2007	A1
20070136169	Dilip et al.	Jun 2007	A1
20070156726	Levy	Jul 2007	A1
20070168281	Bishop et al.	Jul 2007	A1
20070174189	Bishop et al.	Jul 2007	A1
20070179885	Bird et al.	Aug 2007	A1
20070198264	Chang	Aug 2007	A1
20070198405	Bishop et al.	Aug 2007	A1
20070198406	Bishop et al.	Aug 2007	A1
20070230371	Tumminaro	Oct 2007	A1
20070233615	Tumminaro	Oct 2007	A1
20070236330	Cho et al.	Oct 2007	A1
20070244811	Tumminaro	Oct 2007	A1
20070255620	Tumminaro et al.	Nov 2007	A1
20070255652	Tumminaro et al.	Nov 2007	A1
20070255653	Tumminaro et al.	Nov 2007	A1
20070255662	Tumminaro	Nov 2007	A1
20080010685	Holtzman et al.	Jan 2008	A1
20080015982	Sokolic et al.	Jan 2008	A1
20080015985	Abhari et al.	Jan 2008	A1
20080015994	Bonalle et al.	Jan 2008	A1
20080032741	Tumminaro	Feb 2008	A1
20080033880	Fiebiger et al.	Feb 2008	A1
20080040171	Albers	Feb 2008	A1
20080046362	Easterly	Feb 2008	A1
20080082454	Dilip et al.	Apr 2008	A1
20080082828	Jennings et al.	Apr 2008	A1
20080086403	Dilip et al.	Apr 2008	A1
20080086426	Dilip et al.	Apr 2008	A1
20080091596	Labaton	Apr 2008	A1
20080091606	Grecia	Apr 2008	A1
20080097873	Cohen et al.	Apr 2008	A1
20080097899	Jackson	Apr 2008	A1
20080109392	Nandy	May 2008	A1
20080127319	Galloway et al.	May 2008	A1
20080140564	Tal et al.	Jun 2008	A1
20080141033	Ginter et al.	Jun 2008	A1
20080147536	Breen	Jun 2008	A1
20080167962	Lawe	Jul 2008	A1
20080177661	Mehra	Jul 2008	A1
20080189209	Loomis et al.	Aug 2008	A1
20080208737	Dilip et al.	Aug 2008	A1
20080208742	Arthur et al.	Aug 2008	A1
20080208743	Arthur et al.	Aug 2008	A1
20080210751	Kim	Sep 2008	A1
20080210752	March	Sep 2008	A1
20080222048	Higgins et al.	Sep 2008	A1
20080222199	Tiu et al.	Sep 2008	A1
20080227471	Dankar et al.	Sep 2008	A1
20080238610	Rosenberg	Oct 2008	A1
20080242274	Swanburg et al.	Oct 2008	A1
20080244271	Yu	Oct 2008	A1
20080244277	Orsini et al.	Oct 2008	A1
20080249936	Miller et al.	Oct 2008	A1
20080255993	Blinbaum	Oct 2008	A1
20080294563	Boutahar et al.	Nov 2008	A1
20080306872	Felsher	Dec 2008	A1
20080313264	Pestoni	Dec 2008	A1
20080313714	Fetterman et al.	Dec 2008	A1
20080319887	Pizzi et al.	Dec 2008	A1
20090006861	Bemmel	Jan 2009	A1
20090006920	Munson et al.	Jan 2009	A1
20090018909	Grecia	Jan 2009	A1
20090030843	Hoffman et al.	Jan 2009	A1
20090043705	Bishop et al.	Feb 2009	A1
20090048885	Bishop et al.	Feb 2009	A1
20090048886	Bishop et al.	Feb 2009	A1
20090048887	Bishop et al.	Feb 2009	A1
20090048951	Bishop et al.	Feb 2009	A1
20090048952	Bishop et al.	Feb 2009	A1
20090048963	Bishop et al.	Feb 2009	A1
20090048966	Bishop et al.	Feb 2009	A1
20090048968	Bishop et al.	Feb 2009	A1
20090048969	Bishop et al.	Feb 2009	A1
20090048971	Hathaway et al.	Feb 2009	A1
20090068982	Chen et al.	Mar 2009	A1
20090070272	Jain	Mar 2009	A1
20090076956	Bishop et al.	Mar 2009	A1
20090076957	Bishop et al.	Mar 2009	A1
20090076958	Bishop et al.	Mar 2009	A1
20090083181	Bishop et al.	Mar 2009	A1
20090083541	Levine	Mar 2009	A1
20090089193	Paintin	Apr 2009	A1
20090089205	Bayne	Apr 2009	A1
20090089209	Bixler et al.	Apr 2009	A1
20090099961	Ogilvy	Apr 2009	A1
20090112658	Mullen et al.	Apr 2009	A1
20090112659	Mullen et al.	Apr 2009	A1
20090112660	Mullen et al.	Apr 2009	A1
20090112661	Mullen et al.	Apr 2009	A1
20090112662	Mullen et al.	Apr 2009	A1
20090112747	Mullen et al.	Apr 2009	A1
20090119190	Realini	May 2009	A1
20090119207	Grecia	May 2009	A1
20090119212	Liu et al.	May 2009	A1
20090125323	Lakshmanan et al.	May 2009	A1
20090125426	Bishop et al.	May 2009	A1
20090132392	Davis et al.	May 2009	A1
20090132423	Liu	May 2009	A1
20090138388	Bishop et al.	May 2009	A1
20090150269	Bishop et al.	Jun 2009	A1
20090150270	Bishop et al.	Jun 2009	A1
20090150271	Bishop et al.	Jun 2009	A1
20090150288	Bishop et al.	Jun 2009	A1
20090157518	Bishop et al.	Jun 2009	A1
20090157519	Bishop et al.	Jun 2009	A1
20090164324	Bishop et al.	Jun 2009	A1
20090164325	Bishop et al.	Jun 2009	A1
20090164326	Bishop et al.	Jun 2009	A1
20090164327	Bishop et al.	Jun 2009	A1
20090164328	Bishop et al.	Jun 2009	A1
20090164329	Bishop et al.	Jun 2009	A1
20090164330	Bishop et al.	Jun 2009	A1
20090164331	Bishop et al.	Jun 2009	A1
20090204457	Buhrmann et al.	Aug 2009	A1
20090204815	Dennis et al.	Aug 2009	A1
20090228365	Tomchek et al.	Sep 2009	A1
20090265241	Bishop et al.	Oct 2009	A1
20090265249	Bishop et al.	Oct 2009	A1
20090265250	Bishop et al.	Oct 2009	A1
20090265252	Fletcher	Oct 2009	A1
20090271277	Bishop et al.	Oct 2009	A1
20090271278	Bishop et al.	Oct 2009	A1
20090271303	Wang et al.	Oct 2009	A1
20090282259	Skorik et al.	Nov 2009	A1
20090287564	Bishop et al.	Nov 2009	A1
20090287565	Bishop et al.	Nov 2009	A1
20090287601	Tumminaro et al.	Nov 2009	A1
20090289106	Bishop et al.	Nov 2009	A1
20090299841	Bishop et al.	Dec 2009	A1
20090307072	Morales-Lema	Dec 2009	A1
20090319425	Tumminaro et al.	Dec 2009	A1
20090327133	Aharoni et al.	Dec 2009	A1
20100010906	Grecia	Jan 2010	A1
20100030687	Panthaki	Feb 2010	A1
20100031022	Kramer	Feb 2010	A1
20100042539	Dheer et al.	Feb 2010	A1
20101142537	Smith et al.	Feb 2010
20100057622	Faith et al.	Mar 2010	A1
20100063935	Thomas et al.	Mar 2010	A1
20100094765	Nandy	Apr 2010	A1
20100100480	Altman et al.	Apr 2010	A1
20100100899	Bradbury et al.	Apr 2010	A1
20100115610	Tredoux et al.	May 2010	A1
20100127822	Devadas	May 2010	A1
20100131415	Sartipi	May 2010	A1
20100161736	Picknelly	Jun 2010	A1
20100185868	Grecia	Jul 2010	A1
20100198729	Kavounas	Aug 2010	A1
20100269166	Awad et al.	Oct 2010	A1
20100293090	Domenikos et al.	Nov 2010	A1
20100306107	Nahari	Dec 2010	A1
20100320266	White	Dec 2010	A1
20110055078	Nandy	Mar 2011	A1
20110055083	Grinhute	Mar 2011	A1
20110066523	Harrison	Mar 2011	A1
20110066551	Bruesewitz et al.	Mar 2011	A1
20110078078	Meier et al.	Mar 2011	A1
20110099382	Grecia	Apr 2011	A1
20110110508	LaFreniere et al.	May 2011	A1
20110112945	Cullen, III et al.	May 2011	A1
20110112954	Bruesewitz et al.	May 2011	A1
20110131130	Griffin et al.	Jun 2011	A1
20110145149	Valdes et al.	Jun 2011	A1
20110173116	Yan et al.	Jul 2011	A1
20110191160	Blackhurst et al.	Aug 2011	A1
20110196782	Allen et al.	Aug 2011	A1
20110202407	Buhrmann et al.	Aug 2011	A1
20110202982	Alexander et al.	Aug 2011	A1
20110247058	Kisters	Oct 2011	A1
20110251869	Shekhter	Oct 2011	A1
20110251952	Kelly et al.	Oct 2011	A1
20110258111	Raj et al.	Oct 2011	A1
20110264543	Taveau et al.	Oct 2011	A1
20110264583	Cooper et al.	Oct 2011	A1
20110270749	Bennett et al.	Nov 2011	A1
20110276479	Thomas	Nov 2011	A1
20110282778	Wright et al.	Nov 2011	A1
20110288946	Baiya et al.	Nov 2011	A1
20110295746	Thomas et al.	Dec 2011	A1
20110313921	Dheer et al.	Dec 2011	A1
20110320347	Tumminaro et al.	Dec 2011	A1
20120005749	Zoldi et al.	Jan 2012	A1
20120016731	Smith et al.	Jan 2012	A1
20120018511	Hammad	Jan 2012	A1
20120041876	Nosek et al.	Feb 2012	A1
20120066121	Shahbazi et al.	Mar 2012	A1
20120109802	Griffin et al.	May 2012	A1
20120116953	Klein et al.	May 2012	A1
20120130898	Snyder et al.	May 2012	A1
20120151220	Grecia	Jun 2012	A1
20120173409	Hu	Jul 2012	A1
20120173417	Lohman et al.	Jul 2012	A1
20120203695	Morgan et al.	Aug 2012	A1
20120209766	Kitchen et al.	Aug 2012	A1
20120231814	Calman et al.	Sep 2012	A1
20120265687	Dilip et al.	Oct 2012	A1
20120278239	Nosek et al.	Nov 2012	A1
20120284154	Creighton et al.	Nov 2012	A1
20120284175	Wilson et al.	Nov 2012	A1
20120290453	Manista et al.	Nov 2012	A1
20130018791	Mendocino et al.	Jan 2013	A1
20130036000	Giordano et al.	Feb 2013	A1
20130054452	Au et al.	Feb 2013	A1
20130060708	Oskolkov et al.	Mar 2013	A1
20130073455	McLaughlin et al.	Mar 2013	A1
20130080368	Nandy	Mar 2013	A1
20130085936	Law et al.	Apr 2013	A1
20130103576	Ackley	Apr 2013	A1
20130110658	Lyman et al.	May 2013	A1
20130117178	Mullen et al.	May 2013	A1
20130124405	Hamzeh	May 2013	A1
20130124406	Poplawski et al.	May 2013	A1
20130138557	Mullen et al.	May 2013	A1
20130151384	Mullen et al.	Jun 2013	A1
20130197998	Buhrmann et al.	Aug 2013	A1
20130212010	Mullen et al.	Aug 2013	A1
20130226627	Kubovcik et al.	Aug 2013	A1
20130232071	Dilip et al.	Sep 2013	A1
20130238488	Bouey et al.	Sep 2013	A1
20130238489	Bouey et al.	Sep 2013	A1
20130238490	Bouey et al.	Sep 2013	A1
20130238491	Bouey et al.	Sep 2013	A1
20130238492	Muthu et al.	Sep 2013	A1
20130246280	Kirsch	Sep 2013	A1
20130262296	Thomas et al.	Oct 2013	A1
20130262311	Buhrmann et al.	Oct 2013	A1
20130282588	Hruska	Oct 2013	A1
20140006184	Godsey	Jan 2014	A1
20140040069	Tomasofsky et al.	Feb 2014	A1
20140046820	Sunderji et al.	Feb 2014	A1
20140058862	Celkonas	Feb 2014	A1
20140059693	Stecher	Feb 2014	A1
20140067677	Ali et al.	Mar 2014	A1
20140081783	Paranjape et al.	Mar 2014	A1
20140164246	Thomas et al.	Jun 2014	A1
20140187205	Dankar et al.	Jul 2014	A1
20140188697	Bruesewitz et al.	Jul 2014	A1
20140188728	Dheer et al.	Jul 2014	A1
20140244515	Garfinkle et al.	Aug 2014	A1
20140304778	Grecia	Oct 2014	A1
20140310142	Mak	Oct 2014	A1
20140337230	Bacastow	Nov 2014	A1
20140351137	Chisholm	Nov 2014	A1
20140365350	Shvarts	Dec 2014	A1
20140372308	Sheets	Dec 2014	A1
20150026061	Siegel et al.	Jan 2015	A1
20150046181	Adjaoute	Feb 2015	A1
20150046216	Adjaoute	Feb 2015	A1
20150046224	Adjaoute	Feb 2015	A1
20150066738	Tian et al.	Mar 2015	A1
20150073975	Bomhofen et al.	Mar 2015	A1
20150073977	Ghosh et al.	Mar 2015	A1
20150081324	Adjaoute	Mar 2015	A1
20150089568	Sprague et al.	Mar 2015	A1
20150112866	Muthu et al.	Apr 2015	A1
20150186994	He	Jul 2015	A1
20150193776	Douglas et al.	Jul 2015	A1
20160034932	Sion et al.	Feb 2016	A1
20160078443	Tomasofsky et al.	Mar 2016	A1
20160078444	Tomasofsky et al.	Mar 2016	A1
20160092872	Prakash et al.	Mar 2016	A1
20160104133	Davis et al.	Apr 2016	A1
20160188317	Hilliar et al.	Jun 2016	A1
20160203490	Gupta et al.	Jul 2016	A1
20160267280	Mansour et al.	Sep 2016	A1
20160300206	Novac et al.	Oct 2016	A1
20160300207	Novac et al.	Oct 2016	A1
20160300225	Novac et al.	Oct 2016	A1
20160300226	Novac et al.	Oct 2016	A1
20160321625	Gilliam, III et al.	Nov 2016	A1
20170024719	Finch et al.	Jan 2017	A1
20170024744	Finch et al.	Jan 2017	A1
20170024828	Michel et al.	Jan 2017	A1
20170103399	Napsky et al.	Apr 2017	A1

Foreign Referenced Citations (103)

Number	Date	Country
4034997	Mar 1998	AU
1757201	May 2001	AU
8870801	Apr 2002	AU
2002252137	Sep 2002	AU
PI0710021	Aug 2011	BR
PI0710089	Aug 2011	BR
2229012	Mar 1997	CA
2239875	Jun 1997	CA
2323500	Sep 1999	CA
2329348	Nov 1999	CA
2316090	Feb 2001	CA
2402353	Sep 2001	CA
2423048	Mar 2002	CA
2437949	Aug 2002	CA
2436319	Feb 2004	CA
2647602	Mar 2008	CA
2647636	Mar 2008	CA
101454794	Jun 2009	CN
101454795	Jun 2009	CN
865010	Sep 1998	EP
820620	Mar 1999	EP
998731	May 2000	EP
1107198	Jun 2001	EP
1184823	Mar 2002	EP
1208513	May 2002	EP
1400053	Mar 2004	EP
1416455	May 2004	EP
1504393	Feb 2005	EP
2008237	Dec 2008	EP
2013842	Jan 2009	EP
2266083	Dec 2010	EP
2304678	Apr 2011	EP
2344994	Jul 2011	EP
2387772	Nov 2011	EP
2407918	Jan 2012	EP
2407919	Jan 2012	EP
2438562	Apr 2012	EP
2297856	Aug 1996	GB
2384084	Jul 2003	GB
2454614	May 2009	GB
09282367	Oct 1997	JP
H11265413	Sep 1999	JP
2000311209	Nov 2000	JP
2002049872	Feb 2002	JP
2002298041	Oct 2002	JP
2003308437	Oct 2003	JP
2004192437	Jul 2004	JP
2004532448	Oct 2004	JP
2005512173	Apr 2005	JP
2006285329	Oct 2006	JP
2007128192	May 2007	JP
2008102914	May 2008	JP
2008262601	Oct 2008	JP
2014132474	Jul 2014	JP
1020120075590	Jul 2012	KR
1020140099676	Aug 2014	KR
2008012503	Dec 2008	MX
2008012504	May 2009	MX
1018913	Mar 2003	NL
9703800	Apr 1999	SE
200919343	May 2009	TW
1997002539	Jan 1997	WO
1997016798	May 1997	WO
1999024891	May 1999	WO
1999034311	Jul 1999	WO
1999046720	Sep 1999	WO
2000055793	Sep 2000	WO
2000058876	Oct 2000	WO
200133522	May 2001	WO
2001055984	Aug 2001	WO
2001067364	Sep 2001	WO
200225534	Mar 2002	WO
2002025605	Mar 2002	WO
2002035429	May 2002	WO
2002069561	Sep 2002	WO
2002073483	Sep 2002	WO
2003091849	Nov 2003	WO
2005004026	Jan 2005	WO
2005057455	Jun 2005	WO
2007116368	Oct 2007	WO
2008011102	Jan 2008	WO
2008027620	Mar 2008	WO
2008027621	Mar 2008	WO
2008110791	Sep 2008	WO
2009058526	May 2009	WO
2009097215	Aug 2009	WO
2009114876	Sep 2009	WO
2009152184	Dec 2009	WO
2009158420	Dec 2009	WO
2010082960	Jul 2010	WO
2010083113	Jul 2010	WO
2010138358	Dec 2010	WO
2010138359	Dec 2010	WO
2010138611	Dec 2010	WO
2010138613	Dec 2010	WO
2010138615	Dec 2010	WO
2010141662	Dec 2010	WO
2011008625	Jan 2011	WO
2011137082	Nov 2011	WO
2011163525	Dec 2011	WO
2012075187	Jun 2012	WO
2017011596	Jan 2017	WO
2017014815	Jan 2017	WO

Non-Patent Literature Citations (42)

Entry
International Trade Administration (export.gov; Chapter 1: Methods of Payment in International Trade; https://2016.export.gov/tradefinanceguide/eg_main_043221.asp; Nov. 13, 2012) (Year: 2012).
International Search Report for PCT/US2016/042163, dated Sep. 26, 2016.
International Search Report and Written Opinion for PCT/US2016/026000, dated Jul. 13, 2016.
International Search Report and Written Opinion for PCT/US11/33828, dated Jul. 12, 2011, 11 pages.
International Search Report for PCT/US10/36231, dated Nov. 8, 2010, 8 pages.
International Search Report for PCT/US10/36233, dated Jul. 28, 2010, 7 pages.
International Search Report for PCT/US10/36229, dated Jul. 28, 2010, 12 pages.
International Search Report for PCT/US10/35465, dated Jul. 13, 2010, 7 pages.
International Search Report for PCT/US09/48490, dated Jul. 31, 2009, 1 page.
“Greg's diary”, Aug. 2009, available at http://www.lemis.com/grog/diary-aug2009.php?dirdate=20090807&imagesizes=11111111111111111113#Photo-19.
Trusted Computing Platform Alliance (TCPA), Main Specification Version 1. 1b, Published by the Trusted Computing Group, 2003, 332 pages.
Benson, Carol Coye, “Faster, Better, Cheaper—Like it or Not,” http://paymentsviews.com/2013/03/13/faster-better-cheaper-like-it-or-not/, Mar. 13, 2013.
Fiserv, Inc., “Popmoney(R): Instant Payments—Now You Can Deliver Funds in Real Time,” Feb. 6, 2014 [retrieved online from https://www.fiserv.com/resources/Popmoney_Instant_Payments_2_06_2014.pdf on Aug. 7, 2015].
Gayle C. Avery, Ellen Baker; Reframing the Infomated Household-Workplace; Information & Organization, 2002, vol. 12, Aug. 2001.
Mark Bernkopf; Electronic Cash and Monetary Policy; First Monday, vol. 1, No. 1-6, May 1996.
Electronic Payment Systems in European Countries; Country Synthesis Report; Bohle, Rader, Riehm, Institut far Technikfolgenabschatzung and Systemanalyse for the European Science and Technology Observatory Network (ESTO); Final Version, Sep. 1999.
Mark E. Budnitz; Electronic Money in the 1990s: A Net Benefit or Merely a Trade-Off?; 9 Ga. St. U. L. Rev. 747, 1992-1993.
Chida, Mambo, Shizuya; Digital Money—A Survey; Revised Aug. 21, 2001; Interdisciplinary Information Sciences. vol. 7, No. 2, pp. 135-165 (2001).
Harold L. Frohman, William R. Ledder; Defense Transportation's EDI Program: A Security Risk Assessment; PL205LN5; Logistics Management Institute; May 1993.
Aryya Gangopadhyay; Managing Business with Electronic Commerce: Issues & Trends; Idea Group Publishing (2002).
Hans van der Heijden; Factors Affecting the Successful Introduction of Mobile Payment Systems; Vrije Universiteit Amsterdam; 15th Bled Electronic Commerce Conference eReality; Constructing the eEconomy; Bled, Solvenia, Jun. 17-19, 2002.
Lorin M. Hitt and Frances X. Frei; Do Better Customers Utilize Electronic Distribution Channels? The Case of PC Banking; Dec. 2001.
Eun Kim, Petra Schubert, Dorian Seltz and Bumtae Kim; The EBMG Reference Model on Electronic Markets: The Korean Case of JODAL (2007).
Glenbrook Partners; PayPal in the Air!—A look at PayPal Mobile; Payment News; Glenbrook eCommerce Market Analysis Reports (2006).
Sangjo Oh, Heejin Lee, Sherah Kurnia, Robert B. Johnston, Ben Lim; A Stakeholder Perspective on Successful Electronic Payment Systems Diffusion; Proceedings of the 39th Hawaii International Conference on Systems Sciences, 2006.
John R. Palumbo; Naval Postgraduate School, Monterey, California; Thesis, Financial Transaction Mechanisms for World Wide Web Applications, Mar. 1996.
Hua-Fu Pao; Naval Postgraduate School, Monterey, California; Thesis, Security Management of Electronic Data Interchange; Jun. 1993.
Tobern P. Pedersen; Electronic Payments of Small Amounts; Aarhus University (1998).
Eveline Franco Veloso; The Business Revolution through B2B Market Tone and its Impacts over the Financial System gong into 21st Century; The Institute of Brazilian Business and Management Issues; XII Minerva Program-Fall 2000, 2000.
Alladi Venkatesh and Nicholas Vitalari; Households and Technology: The Case of Home Computers-Some Conceptual and Theoretical Issues; originally appeared in M.L. Roberts and L. Wortzel (eds.) Marketing to the Changing Household, Ballinger Publishing, 1985, pp. 187-203.
A. Vilmos and S. Namouskos; SEMOPS: Design of a New Payment Service; International Workshop on Mobile Commerce Technologies & Applications (MCTA 2003), In proceedings of the 14th International Conference DEXA 2003, Sep. 1-5, 2003, Prague, Czech Republic.
Raja Mohn Rosli bin Raja Zulkifli; Building a World Class Infrastructure to Support E-Commerce in Malaysia; 1997 Telekom Malaysia, 1997.
Chang, et al., “Smart Phone for Mobile Commerce,” Computer Standards & Interfaces 31.4, pp. 740-747, 2009.
NACHA (Business-to-Business EIPP: Presentment Models and Payment Options, http://euro.ecom.cmu.edu/resources/elibrary/epay/B2BPaymentOptions.pdf, 2001), (Year: 2001).
Federal Financial Institutions Examination Council (Wholesale Payment System, https://ithandbook.ffiec.gov/media/274899/ffiec_itbooklet_wholesalepaymentsystems.pdf, Section 4, Jul. 2004.
Oldfield et al., “The Place of Risk Management in Financial Institutions,” The Wharton School, Financial Institutional Center, University of Pennsylvania, 1995.
NoPass, “No Password Login \| Touch ID Fingerprint iPhone App,” available at https://web.archive.org/web/20150328095715/http://www.nopassapp.com/, Mar. 28, 2015.
Constant Contact Tech Blog, “iOS Security: How Apple Protects Data on iOS Devices—Part 1,” available at https://web.archive.org/web/20150403175348/https://techblog.constantcontact.com/software-development/ios-security/, Dec. 8, 2014.
NoPass, “Register”, available at https://web.archive.org/web/20141222172212/http://www.nopassapp.com/register/, Dec. 22, 2014.
NoPass, “Login,” available at https://web.archive.org/web/20141222170523/http://www.nopassapp.com/login/, Dec. 22, 2014.
Apple, “iOS Security,” available https://web.archive.org/web/20140226213513/http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf, Feb. 2014.
eBay Developers Program, “eBay Web Services XML API Guide,” 2005.

Related Publications (1)

	Number	Date	Country
	20160283918 A1	Sep 2016	US

Real-time determination of funds availability for checks and ACH items

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

CPC

International Classifications