System and method for securely registering a recipient to a computer-implemented funds transfer payment network

Description

BACKGROUND

Embodiments of the present invention relate generally to the field of transferring funds. In particular, they relate to systems and methods for generating and maintaining a payment network.

Payments made between individuals are often made with cash or checks. Payments for items and services purchased from businesses are often also made with cash or checks, and are also often made using credit cards or debit cards. While these payment mechanisms have worked well, enhanced systems and methods of facilitating such payments would be desirable.

SUMMARY

According to an example embodiment, a computer-implemented payment processing method comprises receiving a fund transfer request identifying a recipient by a public identifier, determining a private identifier for the receiver based on the public identifier, and transmitting a transfer message via a computer network to cause funds to be transferred from a sender to the recipient. The fund transfer request is received via a computer network. The message is generated using the private identifier.

According to another example embodiment, a computer-implemented payment processing system comprises an account information directory and a rules engine. The account information directory comprises a database of registered users. At least one of the registered users is associated with a plurality of public tokens that are stored in the account information directory. The plurality of tokens are useable by the user to send funds to other users and to receive funds from the other users. The rules engine is accessible to the user by way of a computer network to configure attributes of the plurality of public tokens.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a fund transfer system in which a sender and a recipient use different banking institutions according to an example embodiment.

FIG. 2 is a schematic diagram of token management logic that may manage tokens for fund transfer requests according to an example embodiment.

FIG. 3A is a process in which a fund transfer request results in the funds being received by a registered or unregistered recipient according to an example embodiment.

FIG. 3B is a process in which a fund transfer request results in the funds being received by a registered or unregistered recipient according to an example embodiment.

FIG. 4 is a screen shot of a web page that may be presented to a user to configure user preferences and manage connections with other users.

FIG. 5 is a screen shot of a web page that may be presented to a user to configure notification settings.

FIG. 6 is a screen shot of a web page that may be presented to a user to send money to a recipient.

DETAILED DESCRIPTION

Referring to FIG. 1, a fund transfer system 100 that implements a payment network is shown. The fund transfer system 100 may be utilized by senders to send funds to recipients and by recipients to receive the funds. The fund transfer system 100 may facilitate the transfer of funds from senders to receivers without either party disclosing any financial account information to each other. The senders and recipients may be individuals or business entities. In the example embodiment, the sender uses a bank account as the source of funds. In other embodiments, the sender may use credit cards, debit cards, business credit cards or check cards as the source of funds. The fund transfer system 100 may be used for both intrabank transfers (i.e., transfers in which the sender and the recipient both have accounts at the same bank and the funds are transferred between the accounts within the same bank) and interbank transfers (i.e., transfers in which the sender and the recipient have accounts at different banks and the funds are transferred between the accounts at different banks).

The fund transfer system 100 may include, among other systems, a sender computer system 110, a bank computer system 120, a recipient computer system 130, a bank computer system 150, a payment service computer system 160, and an automated clearing house computer system 170. Each of the above described systems may communicate through a network 140, which may include one or more of the Internet, Cellular network, Wi-Fi, Wi-Max, a proprietary banking network, and so on. In FIG. 1 and throughout the remaining description, for sake of providing an example, it is assumed that the sender performs a funds transfer from an account maintained by the bank computer system 120 and the receiver receives the funds using an account maintained by the bank computer system 150. Hence, the computer system 120 is sometimes referred to herein as the sender bank computer system and the computer system 150 is sometimes referred to herein as the receiver bank computer system. It will be appreciated of course that any given bank computer system may operate in different capacities in the context of different fund transfer transactions. Additionally, while the examples provided herein are primarily in the context of a sender requesting a funds transfer to a recipient, it will also be appreciated that a recipient may request a funds transfer from a sender.

The sender computer system 110 may be used by an individual user (e.g., a business owner or employee, a consumer, and so on) to create transactions and interact with banking functions provided through an online banking area of a website provided by the sender bank computer system 120 or through a website provided by a payment service 160. The sender computer system 110 may, for example, comprise a user computer (e.g., desktop or laptop computer), a cellular telephone, smart phone, a mobile handheld wireless e-mail device, a personal digital assistant, a portable gaming device, or other suitable device. The sender computer system 110 may also comprise one or more servers each with one or more processors configured to execute instructions stored in memory. For example, such an arrangement may be utilized if the sender is a merchant or other business.

The sender computer system 110 may comprise network interface logic 112, a display device 114, an input device 116, and client application 118. Network interface logic 112 may include, for example, program logic that connects the sender computer system 110 to the network 140. As described in greater detail below, for example, the sender computer system 110 may receive and display screens on the display device 114 including account information, transaction instructions, and so on. In an example embodiment, such screens may be used to request a username and password information. Such screens may also be used to prompt the user to provide information regarding the amount of the funds and the identity of the merchant or individual that is to receive the funds. Such information may comprise, for example, a name, an address, a phone number, an e-mail address, a selection of a recipient from an electronic directory, and/or other information. Such screens may also include screens displaying information regarding past transactions. Such screens are-presented to the user via the display device 114. The input device 116 may be used to permit the user to initiate account access and to facilitate receiving fund transfer request information from the user.

The client application 118 may comprise program logic (i.e., stored executable instructions) configured to implement at least some of the functions described herein. As will be appreciated, the level of functionality that resides on the sender computer system 110 as compared to other components of the fund transfer system 100 may vary depending on the implementation. The client application 118 may simply be a web browser (e.g., Internet Explorer®, Mozilla Firefox®, Chrome®, Safari®, and so on) configured to receive and display web pages received from the banking computer system 120. The client application may also comprise a mobile web browser, text message (SMS) interface, a dedicated application, or other program suitable for sending and receiving information over the network 140.

The bank computer system 120 is operated by a bank institution that maintains accounts held by customers, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, and so on. The bank computer system 120 may, for example, comprise one or more servers each with one or more processors configured to execute instructions stored in memory, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with logic or processes shown in FIGS. 1-6.

The bank computer system 120 may include network interface logic 122, account processing logic 124, an account database 126, and an information directory 128. The network interface logic 122 may include, for example, program logic that connects the bank computer system 120 to the network 140. The network interface logic 122 may facilitate secure communications between the bank and the sender and/or the recipient. The network interface logic 122 may also facilitate communication with other entities, such as other banks, settlement systems, and so on. The network interface logic 122 may include user interface program logic configured to generate and present web pages to users accessing the bank computer system 120 over the network 140.

The account processing logic 124 performs account processing to process transactions in connection with the account(s) of the account holder, such as account credits and debits to checking and savings accounts, credits and debits to home mortgage and home equity accounts, credits and debits to student loan accounts, and so on. Thus, whenever funds are transferred into or out of an account of an account holder (e.g., a sender or recipient of funds), the account processing logic 124 reflects an appropriate debit or credit in the account database 126, which stores account information (e.g., transactions, information about the account holder, and so on) for accounts that are maintained by the bank on behalf of its customers. The account processing logic 124 may also process fund transfer requests to transfer funds from a sender using the sender computer system 110 to a recipient using the recipient computer system 130.

The information directory 128 may be used when an identifier other than a bank account/routing number is used (e.g. an e-mail address, phone number, Universal Payment Identification Code (UPIC), randomly generated number, and so on) to identify a recipient of a funds transfer. The information directory 128 may be a database that is maintained to allow the financial institution to convert/correlate the recipient's cell phone number (or e-mail address, or other identifier) to a bank account number/routing number of the recipient's bank account. This arrangement allows the sender to uniquely identify the recipient (e.g., with an e-mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient's bank account/routing number).

Users may register their information with the information directory 128 prior to any financial transaction. A user may be added to the information directory 128 upon registering for the fund transfer system 100 through the bank computer system 120. Upon registration, a new entry may be created for the newly registered user in a database that implements the information directory 128. The user may provide one or more identifiers (e.g., phone numbers, e-mail addresses, and so on) that the user may share with other individuals with whom the user interacts (for example, in the same way that people selectively or freely share phone numbers and e-mail addresses with other individuals for purposes of communicating with such other individuals). Herein, such identifiers are referred to as “public identifiers” or “public tokens.” (The terms “identifier” and “token” are used interchangeably herein to refer to a code (e.g., an e-mail address, a phone number, a user generated or system generated character string, etc.) that identifies a user.) The information directory 128 may also generate or otherwise associate an identifier that is securely maintained and that is used to identify the user in the information directory 128. Herein, such identifiers are referred to as “private identifiers.” The private identifier may, for example, be a unique ID of the database entry for the user in the information directory 128. While the private identifier is known by the information directory 128, it need not be known by the user with whom it is associated or by other users. However, it may be known by banks and other entities that are members of the payment network implemented by the funds transfer system 100. In addition to the public identifier(s) (e.g., phone numbers, e-mail addresses, and so on) and the private identifier (e.g., database UID), other information may also be stored in the database entry, such as account information (account numbers, routing numbers, etc.) for accounts held by the user at the bank and user preferences. At least some of this information may be populated automatically, e.g., if the user registers for the fund transfer system 100 during a secure on line banking session on the bank computer system 120.

Additionally, the database entry for each user may also store a registry of other users connected to that user. That is, for each user, a registry may be stored that includes a listing of each other user with whom the user has an established connection. Such connection may be established, for example, the first time that the user sends or receives funds from the other user. A connection may also be established by way of a user interface that permits a user to add connections with other users through a lookup service in the information directory 128 and/or another information directory. An example of such a user interface is discussed below in connection with FIG. 4. The users may include not only users that are registered in the payment network implemented by the fund transfer system 100, but also other affiliated payment networks, as discussed in greater detail below. For each user in the registry, additional information may be stored, such as their unique ID and/or other information. As another example, the information for the other users may be stored in separate database entries in the information directory 128.

In various embodiments, a plurality of information directories may exist, each directory maintained by a different institution or entity. For example, users that maintain accounts at the bank associated with bank computer system 120 may register through bank computer system 120, users that maintain accounts at the bank associated with bank computer system 150 may register through bank computer system 150, and so on for other users that maintain accounts at other entities. Such entities may also include non-bank entities (e.g., payment processing companies, credit agencies, credit card network providers, and so on), and users may also register through such non-bank entities.

In addition to the public and private identifiers that have already been described herein, additional identifiers may also be used. For example, such additional identifiers may be handled with varying levels of security. As another example, variations of existing public identifiers may be used to implement special purpose public tokens, public tokens with customized functionality, and so on, as discussed in greater detail below.

The token management logic 129 manages tokens. For example, the token management logic 129 may be configured to register tokens, authenticate tokens, generate tokens and so on. The token manage logic 129 may also facilitate identification of the recipient when a token is not recognized. The token management logic 129 may also be used to customize attributes of tokens, such that particular accounts are used, particular methods of notification are used, and so on. The token management logic 129 is discussed in greater detail below in connection with FIG. 2.

The recipient computer system 130 may be configured in generally the same manner as the other computer systems described herein. For example, if the fund recipient is an individual, the computer system 130 may be a mobile device, such as a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming device, a desktop computer or other suitable device. The computer system 130 may also comprise one or more servers each with one or more processors configured to execute instructions stored in memory. For example, such an arrangement may be utilized if the recipient is a merchant or other business.

In one embodiment (e.g., where the recipient is a bricks-and-mortar merchant), the recipient computer system 130 may include point of sale devices (e.g., cash register systems) that are equipped to electronically obtain public token information from customers. For example, the cash register systems may be equipped with a near field communication (NFC) reader device that is capable of reading a public token (e.g., cell phone number) from an NFC equipped cell phone. As another example, the cell phone may include an application that is configured to generate a bar code or other image on a display screen that contains the public token, and the cash register system may be equipped with a bar code reader configured to read the bar code. The recipient computer system 130 may then request payment from the sender via the funds transfer system 100 using the public token obtained at the point of sale.

The recipient bank computer system 150 may be configured in a similar manner as the sender bank computer system 120. Thus, the bank computer system 150 comprises network interface logic 152, account processing logic 154, account database 156, and information directory 158 corresponding to the network interface logic 122, account processing logic 124, account database 126 and information directory 128 of the bank computer system 120.

The payment service computer system 160 may be associated with a payment service that is configured to facilitate interbank fund transfers, e.g., a payment service provided by a non-bank entity as previously mentioned. The payment service may, for example, be an entity that is formed as a joint venture between banks and/or other entities that send and receive funds using the fund transfer system 100. As another example, the payment service may be a third party vendor. As another example, the payment service may be a web portal provided for an online community of individuals where such individuals obtain user names/login IDs or otherwise become registered members. The individuals may, for example, use the web portal to interact with each other and/or to interact with a service provided by the online community. Examples of online communities include MSN®, iPhone® users, Facebook®, LinkedIn®, and so on. The payment service may, for example, be an additional service that is offered by the web portal to the members of the online community. As another example, the payment service may be provided by one of the banks, i.e., such that the bank performs both the operations described herein as being performed by the bank computer system 120/150 and the operations described herein as being performed by the payment service computer system 160.

Herein, the banks associated with computer systems 120 and 150 are assumed to be “member banks” That is, the banks associated with computer systems 120 and 150 are assumed to follow established protocols for transferring funds using the fund transfer system 100. For example, in the context of a payment service that is created as a joint venture, the member banks may include at least the banks that are part owners of the joint venture, as well as potentially other banks. While two member banks are shown in FIG. 1, it will be appreciated that there may be additional member banks. Additionally, as previously indicated, non-bank entities may also be members. The payment service may also be used by senders and recipients that have bank accounts at non-member banks, for example, by permitting such users to register directly with the payment service computer system 160. Hence, users do not need to be customers of any particular bank in order to be able to use the fund transfer system 100.

The payment service computer system 160 may, for example, comprise one or more servers each with one or more processors configured to execute instructions stored in memory, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with logic or processes shown in FIGS. 1-6. The payment service computer system 160 includes network interface logic 162 and an information directory 168. Although not specifically shown, it will be appreciated that the payment service computer system 160 may include account processing logic and an account database in the same or similar manner to the account processing logic 124, 155 and the account databases 126, 156. The network interface logic 162 may include user interface program logic configured to generate and present web pages to users accessing the payment service computer system 160 over the network 140.

The information directory 168 may be used when an identifier other than a bank account/routing number is used (e.g. an e-mail address, phone number, Universal Payment Identification Code (UPIC), randomly generated number, and so on). As described above in connection with the information directory 128 and 158, the information directory 168 is a database that is maintained to allow the payment service to convert/correlate the recipient's cell phone number (or e-mail address, or other token) to a bank account number/routing number of the recipient's bank account for users that registered through the payment computer service system 160. This arrangement allows the sender to uniquely identify the recipient (e.g., with an e-mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient's bank account/routing number).

Users including senders and recipients may register their information with the information directory 168 in advance, e.g., where such users do not bank or have accounts with any of the other member entities. Additionally, the payment service computer system 160 may be configured such that users that only wish to send funds may do so without registering. For example, the payment service computer service system 160 may be configured to generate web pages that receive credit card information from a sender to complete a transaction each time a sender wishes to send funds, without requiring that the sender ever register with the payment service computer service system 160.

As will be appreciated, the information that is stored in the information directory 168 may vary depending on the implementation, including the extent to which information is also stored in the information directories 128 and 158. For example, in one embodiment, when a user registers at the bank computer system 120 (or at the bank computer system 150, or at the computer system of another member entity), information may be stored in both the information directory 128 and the information directory 158. The information directory 128 may store a complete identification of the user's bank accounts and other information collected during registration. Conversely, the information directory 168 may store a reduced amount of information, such as the registered public token(s), the financial institution with it is associated, and the private token (e.g., unique ID) associated with each token. More detailed bank account number/routing number, or other sensitive information need not be stored at the information directory 168. In another embodiment, instead of using a payment service computer system 160 to maintain the information directory 168, such information may be stored entirely in the information directories 128, 158 maintained by individual member banks As will also be appreciated, the extent to which transaction details are tracked and maintained in the account processing logic 124, 154 as compared to the extent to which transaction details are tracked and maintained by the payment service computer system 160 may vary depending on the implementation.

The Automatic Clearing House (ACH) system 170 is used to transmit funds to and from bank accounts of the senders and recipients. As is known, the ACH Network is a nationwide batch oriented electronic funds transfer system which provides for interbank clearing of electronic payments for participating depository financial institutions. An ACH entry may start with an account holder (known as the Receiver in ACH terminology) authorizing an Originator (e.g., a person or a company) to issue ACH debit or credit to an account. Depending on the ACH transaction, the Originator must receive authorization from the Receiver. In accordance with the rules and regulations of ACH, no financial institution may issue an ACH transaction (whether it is debit or credit) towards an account without prior authorization from the Receiver. Once authorization is received, the Originator then creates an ACH entry to be given to an Originating Depository Financial Institution (ODFI), which may be any financial institution that does ACH origination. This ACH entry is then sent to an ACH Operator (i.e., central clearing facilities through which financial institutions transmit or receive ACH entries, e.g., the Federal Reserve or the Electronic Payments Network) and is passed on to the Receiving Depository Financial Institution (RDFI), where the Receiver's account is issued either a credit or debit, depending on the ACH transaction. The RDFI may, however, reject the ACH transaction and return it to the ODFI with the appropriate reason, such as that there were insufficient funds in the account or that the account holder indicated that the transaction was unauthorized. An RDFI has a prescribed amount of time in which to perform returns (e.g., two to sixty days from the receipt of the ACH transaction). An ODFI receiving a return of an ACH entry may re-present the ACH entry two more times, or up to three total times, for settlement. Again, the RDFI may reject the transaction, after which the ODFI may no longer represent the transaction via ACH. The above description of ACH system is one in use currently, the embodiments of the current invention will continue to function similarly even if some methods and steps in the ACH system are modified.

Referring to FIG. 2, FIG. 2 shows the token management logic 169 in greater detail. As shown in FIG. 2, the token management logic 169 includes sponsor identification logic 182, registration logic 184, token authentication logic 186, rules engine 188, and token generation logic 190. Although the token management logic 169 is shown, it will be appreciated that the token management logic 129 and 159 may be configured in the same or similar manner.

The sponsor identification logic 182 may be configured to identify a sponsor of a token. For example, if the sender uses a token to identify a recipient that is unrecognized at the information directory 129 of the sender bank computer system 120 (i.e., because the recipient is not a customer of the sender bank), the sponsor identification logic 182 may be configured to receive the token from the sender bank computer system 120 and access the information directory 168 to provide an identification of the unique ID and financial institution associated with that token.

As will be appreciated, the extent to which the bank computer systems 120, 150 have sponsor identification logic that operates in the same manner as the sponsor identification logic 182 may depend, in part, on the extent to which the information is stored in the information directory 168 as compared to the extent to which information is also stored in the information directories 128 and 158. In various embodiments, greater or lesser degrees of reliance may be placed on the information directory 168 to perform user identification functions in a centralized fashion in connection with the transfer of funds between entities. Herein, for sake providing an example, it is assumed that the information directory 168 is used to perform user identification functions in a centralized fashion in connection with the transfer of funds between entities. In such embodiments, it may be possible to avoid replicating all the functions of the sponsor identification logic 182 and the bank computer systems 120, 150.

In one embodiment, the payment network implemented by the fund transfer system 100 is configured to interact with other affiliated payment networks (e.g., PayPal, CashEdge, and so on). In such an arrangement, if the token provided by the sender bank computer system 120 is not recognized in the information directory 168, the sponsor identification logic 182 is configured to transmit inquiries to the other affiliated payment networks (e.g., in a predetermined sequence) to determine if the token is recognized at any of the other affiliated payment networks. If the recipient is registered with another payment network, then the funds may be transferred to the recipient by routing the funds through the other payment network. In an embodiment where a user lookup service is provided by the information directory 168, the look up service may operate in the same manner to identify users registered at remote entities. Information may also be stored in the information directory 168 identifying the payment network determined to be associated with that token, thereby facilitating additional funds transfers to that token in the future. Hence, in such an arrangement, funds may be pushed to a recipient that is not registered with the payment system implemented by the funds transfer system 100 but rather that is registered with another payment system. Additionally, such funds may be pushed to the recipient without the sender having to know or be concerned about whether the recipient is registered with the payment system implemented by the funds transfer system 100.

The registration logic 184 is configured to facilitate the process of registering new users. For example, in the preceding discussion, if the token is not recognized at the information directory 168, and is not registered at any other affiliated payment network, then the registration logic may be configured to send the recipient an e-mail or other communication inviting the recipient to register with the payment network. Such an e-mail may include a link to the website provided by the payment service computer system 160. The registration logic 184 may be configured to generate web pages for presentation to the user at the website to facilitate the registration process. If, based on information provided by the user when registering at the website, it is determined that the user is a customer of one of the member entities, then the user may be forwarded to the website of the member entity to complete the registration process. As will be appreciated, the registration logic 184 may also present web pages to the user in other scenarios (e.g., where the user has arrived at the website as a result of a search engine query, where the user has arrived at the website via another website (e.g., such as an online community website or merchant website), and so on). The registration logic 184 may create new database entries in the information directory 168 responsive to inputs received from the user.

The token authentication logic 186 is configured to authenticate tokens. For example, when a user registers a new token, the token authentication logic 186 may be configured to confirm that the user is associated with that token (e.g., that the user who is attempting to register a cell phone number as a token is indeed the owner of that cell phone number). (Herein, the term “own” in the context of telephone numbers refers to the telephone number being assigned to one particular user as opposed to being assigned to other users, and is not being used to refer to ownership as between the user and the phone carrier that provides the telephone number to the user. The term is used analogously in the context of e-mail addresses.) As another example, when a user attempts to register a new e-mail address, the authentication logic 186 may perform an authentication operation such as sending the user an e-mail at the new e-mail address. The e-mail may, for example, contain a link that must be accessed by the user in order to successfully complete the registration process.

Additionally, the token authentication logic 186 may be configured to perform authentication operations on previously-registered tokens. For example, a user that registers a cell phone number may ultimately switch cell phone numbers and/or cell phone carriers. The token authentication logic 186 may be configured to process disconnect directories that are published by cell phone carriers and that list cell phone numbers that have been disconnected by that carrier. For example, if a registered cell phone number is listed as having been disconnected, the token authentication logic 186 may send an e-mail to the user at a registered e-mail address to determine whether the cell phone number is no longer a valid token for that user or whether the user has merely changed cell phone carriers but has retained the cell phone number.

The token authentication logic 186 may also be configured to send follow up communications to the user trying to use a token to send/receive money from another user if there is uncertainty regarding whether the other user is correct owner of the token. For example, the token authentication logic 186 may be configured to notify the sender that such uncertainty exists, request that the sender provide confirm information that was provided regarding the recipient, provide additional information regarding the recipient, and so on. For example, if a user attempts to send funds using the token jsmith@abc-company.com, an e-mail may be sent to the user if there is uncertainty whether ownership of the token jsmith@abc-company.com has changed (e.g., due to a change in employees at ABC Company). The authentication logic 186 may also be configured to access other networks or online communities (e.g., Facebook, LinkedIn, etc.) to obtain additional information that may be used to authenticate the token. The token authentication logic 186 may also be configured to track the changing public tokens by date and time of use and the date and time that a particular recipient ceases to use a particular public token.

Hence, the registration logic 182 and the authentication logic 184 cooperate to facilitate the registration of tokens and to ensure that the tokens are associated with their correct owners. In one embodiment, the entity that registers a token is responsible for warranting the validity of the registration. For example, if the recipient bank registers a token 415-555-1234, and subsequently accepts a payment to the user that registered the token 415-555-1234, then the recipient bank is responsible for refunding money to the sender if the user that registered the token 415-555-1234 is not actually the owner of that cell phone number at the time of the funds transfer (e.g., because the previous owner changed cell phone numbers, and the new owner is on a different payment network). Hence, the recipient bank undertakes responsibility for correctly authenticating the user at the time of registration and for routinely processing disconnect directories to ensure that the authentication remains valid.

In one embodiment, the warranty (and/or limited access to the information directory 168) may be provided as a service to third parties. For example, an on line retailer that is refunding money to a customer may wish to verify that a token previously provided by the customer (e.g., “415-555-1234”) remains accurate. If funds are refunded to the customer at the “415-555-1234” token, but the customer no longer owns that token, then the payment service would be responsible for refunding the funds to the correct customer. The fee charged for the service may, for example, be based on the dollar value of liability accepted by the payment service for providing incorrect information. As another example, a service may be provided in which a per token fee is charged for identifying a user based on a token and/or for identifying a token (e.g., e-mail address, cell phone number, etc.) based on an identification of a user.

The rules engine 188 is configured to permit users to configure different attributes for different tokens. The attributes may be specified in rules that are configured based on user specified preferences. In various embodiments, the rules engine 188 may provide a user with default settings that are used until the user decides to customize the rules. For example, the rules engine 188 may be used to configure the manner in which funds are directed to various accounts held by the user at the bank (e.g., to forward at least a portion of the funds or transfer funds into a particular type of account), and so on. As another example, the funds may be split between a plurality of accounts according to the rules specified by the user, e.g., the funds may also be transferred into at least one of a retirement account, savings account, PayPal® account, or a certificate of deposit. As another example, portion of the received funds may be forwarded to a different user that is registered with the payment network. As another example, the rules engine 188 may be used to configure the manner in which a notification is sent to a recipient informing the recipient that a fund transfer request has been made by a sender. For example, according to one embodiment, the rules may be configured to specify the channel(s) by which notifications are sent (e-mail, text message, voicemail, and so on), the e-mail account(s) and/or phone number(s) to which notifications are sent, and so on. As another example, if the fund transfer amount is greater than a threshold value, the user may receive an automated telephone call instead of an e-mail message or may receive an e-mail/telephone call instead of no message. As another example, if the fund transfer request originated from a particular sender, then the user may specify the mode of the notification (e.g., e-mail, voicemail, or text message). As another example, the rules engine 188 may be used to configure the payment channel used to send funds to a recipient (e.g., ACH transfer, credit card network, PayPal network, printed and mailed check, and so on). As another example, the rules engine 188 may be used to configure the speed with which funds are transferred to the recipient (e.g., instantaneous, same day, overnight, 2-day payment, and so on). As another example, the rules engine 188 may be used to configure transaction limits (e.g., to ensure that no more than $500 can be charged to a particular token during a predetermined time period such as one day, one week, one month, etc.).

The token generation logic 190 may be configured to generate additional public tokens for a user. The token generation logic 190 may cooperate with the rules engine 188 to create different tokens that are configured with different attributes. For example, a business may wish to use different individual tokens depending on whom within the business is responsible for processing a particular transaction. For example, a recipient that is a landlord that owns several apartment buildings may wish to create different tokens for each apartment building. For example, the additional tokens may be based on user provided alphanumeric character strings, may be system generated based on pseudo random character strings, or may be generated in another fashion. For example, if the landlord recipient already uses an e-mail address as a public token (e.g., landlord@mail.com), the additional public tokens may be variants of the public token already used by the recipient (e.g., landlord@mail.com/building1, landlord@mail.com/building2, landlord@mail.com/building3 and so on). Such tokens may then be configured with different attributes using rules engine 188. For example, if each of the different buildings has a different building manager, then an e-mail may be sent to an e-mail address of the respective building manager for a particular apartment building when a tenant of that apartment building pays rent.

As another example, the landlord recipient may provide each tenant with a different public token for use by the tenants to pay rent. Again, for example, the additional tokens may be variants of the public token already used by the recipient (e.g., landlord@mail.com/unit101, landlord@mail.com/unit102, landlord@mail.com/unit103 and so on). The bank computer system 150 may then receive funds from each tenant and all the funds may be transferred to one or more accounts belonging to the landlord. The account processing logic 154 may be configured to generate a report showing the funds received in connection with each token (thereby showing, for example, which tenants have paid in a given month and which tenants have not paid in a given month). Tokens may also be programmed with additional information, for example, the amount of the expected monthly payment. The account processing logic 154 may then be configured to compare the amount actually received with the expected monthly payment to ensure that the tenant has paid completely and to track overall account status of the tenant.

As another example, a recipient may also configure single use tokens. For example, a recipient may be organizing an event in which other users are expected to financially contribute to the event. The recipient may then configure a token (e.g., johnsmith@mail.com/moms-birthday-party) which may be provided to the other users. The account processing logic 154 may then generate a report showing the funds that have been received from various ones of the other users in connection with that token.

As another example, senders may also configure different tokens. For example, a sender may use a first token as their default token (e.g., johnsmith@mail.com), and create additional special purpose tokens where payment is to be made from other accounts (e.g., johnsmith@mail.com/collegesavings to make a tuition payment from a college savings fund).

As another example, as previously indicated, the information directories 128, 158, 168 may provide a lookup service that may be used by users to establish connections with other users. In such an embodiment, users may be able to configure aspects of their tokens that are displayed to other users. For example, if an individual is operating a business under another name (e.g., Joseph Smith DBA “Joe's Lawn Service”), it may be desirable to permit the user to configure the token such that the business name is displayed to other users, even though the name on the account is actually the individual's name. In this manner, it will be easier for customers of the business to establish a connection with the business.

Referring to FIGS. 3A and 3B, FIGS. 3A and 3B illustrate a process in which the funds may be received by a registered or unregistered recipient according to an example embodiment. In FIGS. 3A and 3B, a fund transfer message is received from a sender at the sender bank computer system 120 and propagates to the recipient bank computer system, where it causes funds to be deposited in to the account of a recipient. Specifically, at step 301 in FIG. 3A, the sender bank computer system 120 receives a fund transfer request from a sender which identifies the recipient using a token. At step 311, the bank computer system 120 searches the information directory 128 to determine whether the token is associated with a user that is registered with the sender bank (i.e., a transfer within the same bank). If the token is associated with a user registered with the sender bank then, at step 313, the recipient's account information is retrieved from the information directory 128. Subsequently, at step 315, the funds are transferred to the recipient's account. The funds may be transferred to the recipient's financial account based on preferences of the sender and the recipient, as discussed in greater detail below in connection with FIGS. 4 to 6.

If, at step 311, the recipient is not registered with the sender bank, then the process proceeds to step 321. At step 321, the bank computer system 120 transmits an inquiry to the payment service computer system 160, and it is determined if the token is associated with a user that is registered at another member entity of the payment network implemented by the funds transfer system 100. For example, if it is the first time that the sender has transferred funds to this particular recipient, then the bank computer system 120 may transfer the public token of the recipient as provided by the sender. In this scenario, the sponsor identification logic 182 may perform a search of the information directory 168 to determine if the token is associated with a user that is registered with another member entity. If the public token is located in the directory, then the payment service computer system 160 may return the unique ID associated with the public token along with an identification of the financial institution or other member entity with which it is associated to the sender bank computer system 120. The sender bank computer system 120 may then create another registry entry for the sender, and store the public token and the unique ID of the recipient as part of the registry entry. The sender bank computer system 120 may also prompt the sender to provide other information about the recipient (e.g., a nickname or other name by which the sender wishes to identify the recipient).

As another example, if the sender has transferred funds to this recipient previously, then the bank computer system 120 may transfer the unique ID of the recipient to the payment service computer system 160. In this scenario, the sponsor identification logic 182 may use the unique ID as an index to the database that implements the information directory 168 to locate the recipient in the information directory 168. Assuming the unique ID is still valid and is still located in the information directory 168, then the payment service computer system 160 may return the financial institution or other member entity with which it is associated to the sender bank computer system 120. As another example, if the sender has transferred funds to this recipient previously, then the bank computer system 120 identifies the member entity with which it is associated based on the unique ID itself (e.g., where the unique ID is embedded with information that identifies the financial institution). At step 323, the sender's registry is updated to include an entry for the recipient, including the unique identifier of the recipient. At step, 325 the funds are transferred to the member entity (e.g., the recipient bank in the example of FIG. 1) for deposit along with the unique ID of the recipient. Based on the unique ID, the information directory 158 may be accessed by the recipient bank computer system 150 to identify the account number of the recipient. The funds may then be deposited in the bank account of the recipient.

If, at step 321, the recipient is not a user that is registered at another member entity of the payment network implemented by the funds transfer system 100, then the process proceeds to step 331 illustrated in FIG. 3B. At step 331, the sponsor identification logic 182 of the payment service computer system 160 transmits inquiries to other payment networks (e.g., PayPal®, Star, Blink, Interlink, Plus, etc.), and it is determined if the token is associated with a user that is registered at another payment network. For example, the sponsor identification logic 182 may transmit an inquiry to a first payment network to inquire whether the recipient is registered at that payment network. If not, the sponsor identification logic 182 may continue to transmitting additional inquiries to other affiliated payment networks until the payment network at which the recipient has registered an account is identified. At step 333, if the recipient is registered with another payment network, information may also be stored in the information directory 168 identifying the payment network determined to be associated with that token, thereby facilitating additional funds transfers to that token in the future. Next, at step 335 the funds may be transferred to the recipient by routing the funds through the other payment network. Hence, in such an arrangement, funds may be pushed to a recipient that is not registered with the payment system implemented by the funds transfer system 100 without the sender having to know or be concerned about whether the recipient is registered with the payment system implemented by the funds transfer system 100.

If, after the search of other payment networks is completed, no other payment network is identified at which the recipient is registered, then the recipient is presumed to not be a registered user of any payment network. Accordingly, at step 341, an invitation is sent to the recipient to invite the recipient to join the payment network. For example, if the token used by the sender is an e-mail address, then an e-mail is sent to the recipient informing that another user is attempting to transfer funds to the recipient and inviting the recipient to join the payment network. A link in the e-mail may, for example, deliver the recipient to the website provided by the bank computer system 120. As another example, if the token used by the sender is a cell phone number, the recipient may be sent a text message containing a URL inviting the recipient to join the payment network. As will be appreciated, the recipient may be sent such an invitation in other situations, e.g., if the recipient is not a registered user of the payment network implemented by the funds transfer system 100, even if the user is a registered user of another payment network.

At step 343, the recipient may be prompted to provide account information. At step 351, based on the account information, it may be determined whether the user is a customer of one of the member entities. For example, a bank routing number for a demand deposit account may be used to determine whether the user is a customer of one of the member entities. If the recipient is a customer of a member entity, then at step 353 the recipient may be transferred to the member entity for registration (e.g., the recipient bank in the example of FIG. 1). A unique ID is associated with the recipient in the information directory 159 of the recipient bank computer system 150 and in the information directory 168 of the payment service computer system 160. At step 355, the sender's registry is updated to include the recipient, including the unique identifier of the recipient. At step 357, the funds are transferred to the recipient.

If the recipient is not a customer of a member entity, then at step 363 the recipient is registered by the payment service computer system 160. At step 365, the sender's registry is updated to include an entry for the recipient, including the unique identifier of the recipient. At step 367, the funds are transferred to the recipient. As will be appreciated, if the recipient has customized fund transfer preferences, the fund transfer will be processed by the rules engine 188 according to the recipient preferences. Examples of token customization to reflect such preferences were previously described above in connection with rules engine 188 and token generation logic 190.

FIG. 4 is a screen shot of a web page 400 that may be provided to a user when the user selects a preferences tab. The web page 400 may be used to configure preferences in connection with the token management logic 129, 159 or 169 (depending on where the user registered for the payment network). Web page 400 includes a plurality of fields including a default notification settings field 401, a manage connections field 411, and a manage recipients field 431. The default notification settings field 401 presents the user with information regarding the current default notification settings for a funds transfer event. As shown in the screen shot in FIG. 4, notification settings field 401 may include settings to specify a telephone number to which automated telephone call notifications or text message notifications should be sent (field 403) and an e-mail address to which e-mail notifications should be sent (field 405). The user may also be permitted to specify the name on the account (field 407) as it should appear to other users when the other users receive a funds transfer notification. The information specified in field 407 may also be used in other situations, for example, when others user are searching for connections through a lookup service in information directory 128, 156, 168. The user may configure the rules engine 188 to notify the user regarding transactions based on the user preferences received from the user prior to the occurrence of the transactions. If the user fails to configure customized notification settings, default notification settings may be used. In various embodiments, a user may choose different/custom notification settings for each token that the user has registered.

In the example shown in FIG. 4, the telephone number that may receive a call, text message or voice message, upon the occurrence of a predetermined event is 949-555-7878. Additionally, the e-mail address that may be used to notify the user that a fund transfer has occurred from or to the user's accounts is pat@mail.com. The user may choose to be notified by e-mail or telephone or both.

The token field 413 may display a particular token that the user has registered or is in the process of registering. The status field 415 may display whether the token has been verified/unverified or is active/inactive. The receiving money field 417 is derived in part on the information in the status field and indicating whether a particular token is currently available for sending/receiving money. For example, for the inactive phone number (i.e., 650-555-5555), the user may send/receive funds using this token for connections established prior to the token becoming inactive. However, the user cannot establish new connections with other users based on this token. For example, this may be a mobile number that was previously owned by the user. Because a unique ID serves as the basis for funds transfers after a connection has been established, previously established connections are still valid (because they are based on the unique ID and not the mobile number), however, new connections are not permitted to be established (because another user may now be using the token).

The account number field 419 may display the type of account and a partial account number of an account that is associated with the token in field 413. Hence, funds sent/received using the token specified in field 413 are withdrawn from/deposited to the account specified in field 419. If an account number is not associated with the e-mail address or the mobile number in field 413, then the account number field 419 may display a message such as “account is not specified.” The notification field 421 may indicate whether the default notification settings specified in field 701 are to be used for notifications or whether other/customized settings are to be used.

Actions field 423 may include various links that allow the user to take various actions. For example, links may include, edit, remove, and verify. If the status of a token is verified, then the edit field allows the user to edit attributes of the token as specified in the rules engine 188. For example, the accounts and notification preferences (fields 719 and 721) may be edited in greater detail. If the account number is verified, then the remove link may also be displayed. if the account is unverified or inactive, a verify link that sends an e-mail or a SMS and displays a verification code may be displayed. An edit and remove link may also be displayed for unverified or in active e-mail or telephone numbers. The user may also add new tokens using new connections link 425.

As will be apparent from fields 401 and 411, separate payment and notification channels may be used for funds transfers. For example, for the 415-555-4001 token, the payment channel occurs through the 415-555-4001 token, however, the notification channel occurs through the 949-555-7878 and pat@mail.com tokens. Additionally, if the user decides to set a custom notification channel for the 415-555-4001 token, the user can do so without disrupting connections that have already been established using the 415-555-4001 token. Disrupting one channel (e.g., by changing the token) does not impact the other channel.

The manage connections field 431 allows a user to perform various functions related to managing the user's connections with other users. Field 431 shows a registry of connections that have been established by a user. Within field 431 various information may be displayed regarding each other user, for example, name (field 433), nickname (field 435), e-mail/mobile (field 437), status (field 439), and actions (field 441) and a link that allows a user to add new recipients 443. Although not specifically shown, it will be appreciated that a unique ID may also be stored for each of the users in the registry shown in field 431. As previously indicated, the unique ID need not be known by the user and is maintained more secure.

The name field 433 may be the name of the recipient as it appears on the account associated with the other user (e.g., as specified by the other user). The nickname field 435 may be a nickname assigned to the other user (e.g., as specified by the user). The e-mail/mobile field 437 may display the public tokens that are being used by the recipient. The status field 437 may display whether a permanent connection has been established for a particular contact. Actions field 441 may be determined based on the status field. For example, if a link has been established, then the actions field 441 may display a link that allows a user to send money to the recipient. If a link has not been established, then the actions field may display a send money link, but the actions field 441 may also display a view details link. The view details link may display another screen to the user where the user may provide further details to establish a connection with a recipient. Other actions that may be displayed are edit and remove. Edit may allow the user to edit each field discussed above and remove may allow a user to remove a recipient and related information from the user's registry. A link 443 may be used to add additional users to the registry, e.g., via a search of information directories 128, 158 and/or 168.

In an example embodiment, the manage connections field 431 may present a message to the user that informs the user when another user is no longer the owner of a token. The message may include a link that allows the user to update the token information. In other embodiments, if the other user's information has changed, then the message presented by the manage connections field 431 may allow the user to update the outdated information.

FIG. 5 is a screen shot of a form that allows a user to update default or custom notification settings. In FIG. 5, the user is provided with a list of e-mail addresses associated with the user's account. The user may use a checkbox to indicate which e-mail address should receive a notification. For example, the user in the screen shot shown in FIG. 5 has chosen e-mail address “psmith@google.com” by placing a check mark 505 in the appropriate field. In other embodiments, a user may choose multiple e-mail addresses instead of choosing a single e-mail address. Also shown on the screen shot are telephone numbers associated with the user accounts. The user may use a check mark 509 to select a phone number that receives a notification. In other embodiments, the user may choose multiple telephone numbers and multiple e-mail addresses for notification. A link 511 may allow the user to add e-mail addresses or telephone numbers to the account information maintained by the bank. In one embodiment, the user may select the link and the user may be automatically taken to a web portal provided by a banking institution. The user may click on save button 513 to save the notification changes implemented by the user.

FIG. 6 shows a screen shot of a web page 600 that may be presented to a user when the user selects the send money tab. The web page 600 may include a send money field 601 that the user may fill out to send money to a chosen recipient. The web page 600 may include a display of various payment channels 619 that are available to the user. The web page 600 may also include a field 630 showing details regarding recent transactions that are pending, returned or completed.

The send money form 601 may prompt the user to choose a recipient from a pull down menu 603. The list of recipients presented using menu 603 may be populated using the list of recipients contained in field 431 discussed in FIG. 4. The list of recipients menu 603 may contain the names of users that the user has sent funds to or received funds from in the past or that have been added in another manner. In one embodiment, the recipients may be identified by the nicknames assigned to each recipient. Since the nicknames may be directly correlated with the unique ID within the token management logic 129, the account information may be derived from the nicknames via the unique ID. Hence, as previously indicated, the connection between the two users is not disrupted when a cell phone number or e-mail address becomes obsolete. After choosing the recipient, the user may choose an account from which funds will be sent to the recipient using a drop down menu 605. The drop down menu may be pre-populated with a list of all accounts that are held by the user. The user may enter a dollar amount that the user would like to transfer to the recipient in the amount field 607. The user's name may be presented with an optional field description 609 that will allow the user to ascertain that the payment was for a particular product or service provided by the recipient. Another field may be auto populated with the user's name as the sender of the funds. A nickname field 611 is also displayed if the recipient knows the user by a name that is different than the user's name as it appears on the user's account. The send money form 601 also displays links that allow the user to add recipients 615, manage recipients 617 and the current notification preference 613.

The payment channels form 619 presented to the user may allow the user to choose various payment channels such as, credit card, ACH or PayPal®. Also displayed with each payment channel may be the funds available to recipient field 623. For example, the credit card method may make the funds available to the recipient within 2-days of processing the send request. However, the user may be charged a fee as indicated by field 625, for example, $5.00. In other examples, a user may choose ACH in field 621, however the funds may be available to the recipient in 4 days with no fee. Other payment channels, such as PayPal®, Star, Blink, Interlink, and Plus may also be presented to the user.

Field 630 shows a few of the most recent transactions that the user has performed. Additional recent transactions may be displayed via selection of a link to view more transfers and/or by selecting the transfer activity tab. Field 630 may display various fields that include information regarding the transactions. For example, such fields may include a date sent field 633, from account field 635, recipient field 637, amount field 639, description field 641, status field 643 and actions field 645. The date sent field 633 lists the date when the user initiated the send request. The from account field 635 may display the type of account (i.e. checking, savings, or money market) and a partial account number. The recipient field 637 may display the full name of the recipient. The amount field 639 displays the dollar amount sent to the recipient. The description field 641 displays the description that was entered by the user while processing the request. The status field 643 may inform the user whether the fund transfer is pending, returned or not processed, or has been completed. The actions field 645 may display a link that allows a user to view more details regarding the current status of the fund transfer.

The embodiments of the present invention have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems and methods and programs of the present invention. However, describing the invention with drawings should not be construed as imposing on the invention any limitations that may be present in the drawings. The present invention contemplates methods, systems and program products on any machine-readable media for accomplishing its operations. The embodiments of the present invention may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.

As noted above, embodiments within the scope of the present invention include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium which can be used to store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Embodiments of the present invention have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

As previously indicated, embodiments of the present invention may be practiced in a networked environment using logical connections to one or more remote computers having processors. Those skilled in the art will appreciate that such network computing environments may encompass many types of computers, including personal computers, hand held devices, multi processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

An exemplary system for implementing the overall system or portions of the invention might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer. It should also be noted that the word “terminal” as used herein is intended to encompass computer input and output devices. Input devices, as described herein, include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. The output devices, as described herein, include a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present invention as defined in the appended claims. Such variations will depend on the software and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the invention. Likewise, software and web implementations of the present invention could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps. The foregoing description of embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiments were chosen and described in order to explain the principals of the invention and its practical application to enable one skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present invention as expressed in the appended claims.

Claims

1. A computer-implemented payment processing method comprising: receiving, by a computer system over a computer network, a first public identifier associated with a recipient, the computer network comprising the Internet, the recipient having a recipient account at a first financial institution, the first public identifier being able to assist with contacting the recipient regarding payment transactions, and the first public identifier comprising a first email address of the recipient;receiving from the first financial institution over the computer network, by the computer system, a private profile identifier generated by the first financial institution, the private profile identifier being a unique identifier associated with a database entry for the recipient in a first information directory at the first financial institution, the database entry for the recipient in the first information directory associating the private profile identifier with the first public identifier and an account number of the recipient account at the first financial institution, the private profile identifier not being shared with the recipient, the private profile identifier being stored by the first financial institution, the account number of the recipient account not being shared with the computer system, and the private profile identifier providing an additional level of security to facilitate secure communications over the computer network;performing a validation of the first public identifier by confirming that the first public identifier is useable to contact the recipient;storing, by the computer system, a record including the first public identifier and the private profile identifier in a second information directory, the private profile identifier stored in the record not including the account number of the recipient account, and the second information directory being implemented in a data storage system;receiving, by the computer system over the computer network, a first funds transfer request from a first sender, the first funds transfer request identifying the recipient by the first public identifier, the first funds transfer request not including the account number of the recipient account at the first financial institution or the private profile identifier, and the first funds transfer request to transfer first funds from an account of the first sender at a second financial institution to the recipient account at the first financial institution;determining, by the computer system, the private profile identifier for the recipient based on the first public identifier in the first funds transfer request and using the record stored in the second information directory; andproviding the private profile identifier, by the computer system over the computer network in response to receiving the first funds transfer request, to the second financial institution to facilitate a first transfer of the first funds from the account of the first sender at the second financial institution to the first financial institution using an automatic clearing house (ACH) network, the private profile identifier not being shared with the first sender, and the private profile identifier being provided to the second financial institution to enable the second financial institution to associate the first transfer of the first funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the first transfer of the first funds and deposit the first funds into the recipient account, wherein the account number of the recipient account is not shared with the first sender or the second financial institution,wherein: the computer system is operated by an entity that is different from the first financial institution and the second financial institution.
2. The method of claim 1, further comprising providing a graphical user interface to the first sender, the graphical user interface comprising at least one display screen, the at least one display screen displaying the first public identifier.
3. The method of claim 2, further comprising receiving a selection of the recipient from the first sender, wherein the first sender selects the recipient using the first public identifier.
4. The method of claim 1, wherein the private profile identifier is useable to uniquely identify the recipient in account information directories of a plurality of financial institutions comprising the first financial institution.
5. The method of claim 1, wherein the first transfer of the first funds is initiated at the first financial institution.
6. The method of claim 1, wherein the first transfer of the first funds is initiated at the second financial institution to cause the first funds to be transferred from the first sender to the recipient.
7. The method of claim 1, further comprising managing, by the computer system, accounts respectively associated with the recipient and a plurality of other users, the accounts comprising checking and credit card accounts held by the recipient at the first financial institution.
8. The method of claim 1, further comprising sending a request to the recipient over the computer network to accept the first funds from the first sender, the request to accept the first funds being directed to the recipient using the first public identifier.
9. The method of claim 1, further comprising: receiving from the first sender, by the second financial institution, a second funds transfer request, the second funds transfer request identifying the recipient by the first public identifier, the second funds transfer request being received after the private profile identifier was sent to the second financial institution in response to receiving the first funds transfer request, the second funds transfer request not including the account number of the recipient account at the first financial institution or the private profile identifier, and the second funds transfer request to transfer second funds to the recipient;determining, by the second financial institution, whether the second financial institution has previously stored the private profile identifier associated with the first public identifier; andif the second financial institution has previously stored the private profile identifier, using the private profile identifier stored by the second financial institution to facilitate a second transfer of the second funds from the account of the first sender at the second financial institution to the first financial institution using the ACH network, the private profile identifier enabling the second financial institution to associate the second transfer of the second funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the second transfer of the second funds and deposit the second funds into the recipient account, wherein the account number of the recipient account is not shared with the first sender or the second financial institution.
10. The method of claim 9, further comprising: determining, after the second funds transfer request is received, if the first public identifier is still able to assist with contacting the recipient regarding payment transactions; andif the first public identifier is no longer able to assist with contacting the recipient, providing the second funds transfer request to the second financial institution.
11. The method of claim 1, further comprising: receiving, by the computer system, a second funds transfer request from a second sender, the second sender having a second sender account at the second financial institution, the second funds transfer request being received after the private profile identifier was sent to the second financial institution in response to receiving the first funds transfer request, the second funds transfer request identifying the recipient by the first public identifier, and the second funds transfer request not including (a) the account number of the recipient account at the first financial institution or (b) the private profile identifier;determining, by the computer system, the private profile identifier for the recipient based on the first public identifier in the second funds transfer request and using the record stored in the second information directory; andproviding the private profile identifier, by the computer system in response to receiving the second funds transfer request, to the second financial institution to facilitate a second transfer of second funds from the second sender account at the second financial institution to the first financial institution using the ACH network, the private profile identifier not being shared with the second sender, and the private profile identifier being provided to the second financial institution to enable the second financial institution to associate the second transfer of the second funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the second transfer of the second funds and deposit the second funds into the recipient account, wherein the account number of the recipient account is not shared with the second sender or the second financial institution.
12. The method of claim 1, further comprising: receiving, by the computer system, a second funds transfer request from a second sender, the second sender having a second sender account at the second financial institution, the second funds transfer request being received after the private profile identifier was sent to the second financial institution in response to receiving the first funds transfer request, the second funds transfer request identifying the recipient by the first public identifier, and the second funds transfer request not including (a) the account number of the recipient account at the first financial institution or (b) the private profile identifier;determining, by the computer system, if the first public identifier is no longer able to assist with contacting the recipient;if the first public identifier is no longer able to assist with contacting the recipient, providing a message to the second sender rejecting the second funds transfer request; andif the first public identifier is still able to assist with contacting the recipient: determining, by the computer system, the private profile identifier for the recipient based on the first public identifier in the second funds transfer request and using the record stored in the second information directory; andproviding the private profile identifier, by the computer system in response to receiving the second funds transfer request, to the second financial institution to facilitate a second transfer of second funds from the second sender account at the second financial institution to the first financial institution using the ACH network, the private profile identifier not being shared with the second sender, and the private profile identifier being provided to the second financial institution to enable the second financial institution to associate the second transfer of the second funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the second transfer of the second funds and deposit the second funds into the recipient account, wherein the account number of the recipient account is not shared with the second sender or the second financial institution.
13. The method of claim 12, wherein determining, by the computer system, if the first public identifier is no longer able to assist with contacting the recipient comprises attempting to contact the recipient using the first public identifier.
14. The method of claim 2, wherein determining, by the computer system, the private profile identifier for the recipient comprises determining the private profile identifier based on the first public identifier received by the graphical user interface.
15. The method of claim 1, further comprising: receiving, by the computer system, a second public identifier associated with the recipient, the second public identifier being able to assist with contacting the recipient regarding payment transactions;storing the second public identifier, by the computer system, in the record stored in the second information directory;receiving, by the computer system, a second funds transfer request from a second sender, the second sender having a second sender account at a third financial institution, the second funds transfer request identifying the recipient by the first public identifier or the second public identifier, the second funds transfer request not including the account number of the recipient account at the first financial institution or the private profile identifier;determining, by the computer system, the private profile identifier for the recipient based on the first public identifier or the second public identifier in the second funds transfer request received from the second sender and using the record stored in the second information directory; andproviding the private profile identifier, by the computer system in response to receiving the second funds transfer request, to the third financial institution to facilitate a second transfer of second funds from the second sender account at the third financial institution to the first financial institution using the ACH network, the private profile identifier not being shared with the second sender, and the private profile identifier being provided to the third financial institution to enable the third financial institution to associate the second transfer of the second funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the second transfer of the second funds and deposit the second funds into the recipient account, wherein the account number of the recipient account is not shared with the second sender or the third financial insitution.
16. The method of claim 1, further comprising: creating the record based on the validation of the first public identifier,wherein: storing, by the computer system, the record occurs after the first public identifier is validated.
17. The method of claim 15, further comprising: performing a validation of the second public identifier; andstoring the second public identifier in the record based on the validation of the second public identifier,wherein: storing the second public identifier in the record occurs after the second public identifier is validated.
18. A nontransitory computer readable medium comprising instructions executable by a processor, the instructions being executable to perform a method, the method comprising: receiving over a computer network a first public identifier associated with a recipient, the computer network comprising the Internet, the recipient having a recipient account at a first financial institution, the first public identifier being able to assist with contacting the recipient regarding payment transactions, and the first public identifier comprising a first email address of the recipient;receiving over the computer network from the first financial institution a private profile identifier generated by the first financial institution, the private profile identifier being a unique identifier associated with a database entry for the recipient in a first information directory at the first financial institution, the database entry for the recipient in the first information directory associating the private profile identifier with the first public identifier and an account number of the recipient account at the first financial institution, the private profile identifier and the account number of the recipient account not being shared with the recipient, the private profile identifier being stored by the first financial institution, the account number of the recipient account not being shared with the processor, and the private profile identifier providing an additional level of security to facilitate secure communications over the computer network;performing a validation of the first public identifier by confirming that the first public identifier is useable to contact the recipient;storing a record including the first public identifier and the private profile identifier in a second information directory, the private profile identifier stored in the record not including the account number of the recipient account, and the second information directory being implemented in a data storage system;receiving over the computer network a first funds transfer request from a first sender, the first funds transfer request identifying the recipient by the first public identifier, the first funds transfer request not including the account number of the recipient account at the first financial institution or the private profile identifier, the first funds transfer request to transfer first funds from an account of the first sender at a second financial institution to the recipient account at the first financial institution;determining the private profile identifier for the recipient based on the first public identifier in the first funds transfer request and using the record stored in the second information directory; andproviding the private profile identifier over the computer network, in response to receiving the first funds transfer request, to the second financial institution to facilitate a first transfer of the first funds from the account of the first sender at the second financial institution to the first financial institution using an automatic clearing house (ACH) network, the private profile identifier not being shared with the first sender, and the private profile identifier being provided to the second financial institution to enable the second financial institution to associate the first transfer of the first funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the first transfer of the first funds and deposit the first funds into the recipient account, wherein the account number of the recipient account is not shared with the first sender or the second financial institution,wherein: the processor is operated by an entity that is different from the first financial institution and the second financial institution.
19. A system comprising: a processor;a second information directory being implemented in a data storage system; andnetwork interface logic configured to control the processor to: receive over a computer network a first public identifier associated with a recipient, the computer network comprising the Internet, the recipient having a recipient account at a first financial institution, the first public identifier being able to assist with contacting the recipient regarding payment transactions, and the first public identifier comprising a first email address of the recipient;receive over the computer network from the first financial institution a private profile identifier generated by the first financial institution, the private profile identifier being a unique identifier associated with a database entry for the recipient in a first information directory at the first financial institution, the database entry for the recipient in the first information directory associating the private profile identifier with the first public identifier and an account number of the recipient account at the first financial institution, the private profile identifier not being shared with the recipient, the private profile identifier being stored by the first financial institution, the account number of the recipient account not being shared with the system, and the private profile identifier providing an additional level of security to facilitate secure communications over the computer network;perform a validation of the first public identifier by confirming that the first public identifier is useable to contact the recipient;store a record including the first public identifier and the private profile identifier in the second information directory, the private profile identifier stored in the record not including the account number of the recipient account;receive over the computer network a first funds transfer request from a first sender, the first funds transfer request identifying the recipient by the first public identifier, the first funds transfer request not including the account number of the recipient account at the first financial institution or the private profile identifier, the first funds transfer request to transfer first funds from an account of the first sender at a second financial institution to the recipient account at the first financial institution;determine the private profile identifier for the recipient based on the first public identifier in the first funds transfer request and using the record stored in the second information directory; andprovide over the computer network the private profile identifier, in response to receiving the first funds transfer request, to the second financial institution to facilitate a first transfer of the first funds from the account of the first sender at the second financial institution to the first financial institution using an automatic clearing house (ACH) network, the private profile identifier not being shared with the first sender, and the private profile identifier being provided to the second financial institution to enable the second financial institution to associate the first transfer of the first funds with the private profile identifier such that the first financial institution uses the first information directory to identify the account number of the recipient account based on the private profile identifier to receive the first transfer of the first funds and deposit the first funds in the recipient account, wherein the account number of the recipient account is not shared with the first sender or the second financial institution,wherein: the system is operated by an entity that is different from the first financial institution and the second financial institution.
20. The method of claim 15, wherein the second public identifier comprises a second email address of the recipient that is different from the first email address of the recipient.

PRIORITY CLAIM

This application claims priority to U.S. Patent Application Ser. No. 61/607,882, entitled “SYSTEM AND METHOD FOR TRANSFERRING FUNDS,” filed Mar. 7, 2012.

US Referenced Citations (535)

Number	Name	Date	Kind
2011032	Blanchard	Aug 1935	A
5229764	Matchett et al.	Jul 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
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
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
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
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
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	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
7505937	Dilip et al.	Mar 2009	B2
7519560	Lam et al.	Apr 2009	B2
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
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	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
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
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
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
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
8893237	Ganesan	Nov 2014	B2
8938787	Turgeman	Jan 2015	B2
9626664	Bouey et al.	Apr 2017	B2
9691056	Bouey et al.	Jun 2017	B2
20020023054	Gillespie	Feb 2002	A1
20020029193	Ranjan	Mar 2002	A1
20020052852	Bozeman	May 2002	A1
20020091635	Dilip et al.	Jul 2002	A1
20020128932	Yung et al.	Sep 2002	A1
20020143634	Kumar	Oct 2002	A1
20020194503	Faith et al.	Dec 2002	A1
20030014316	Jaalinoja et al.	Jan 2003	A1
20030115151	Wheeler et al.	Jun 2003	A1
20030126094	Fisher et al.	Jul 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 et al.	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
20050069135	Brickell	Mar 2005	A1
20050080716	Belyi et al.	Apr 2005	A1
20050125347	Akialis et al.	Jun 2005	A1
20050137948	Kissner et al.	Jun 2005	A1
20050149455	Bruesewitz et al.	Jul 2005	A1
20050187873	Labrou	Aug 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
20060080727	Hammons et al.	Apr 2006	A1
20060106717	Randle et al.	May 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
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
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
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
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
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
20080097873	Cohen et al.	Apr 2008	A1
20080097899	Jackson et al.	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
20080177661	Mehra	Jul 2008	A1
20080208737	Dilip et al.	Aug 2008	A1
20080210751	Kim	Sep 2008	A1
20080210752	March	Sep 2008	A1
20080222048	Higgins et al.	Sep 2008	A1
20080238610	Rosenberg	Oct 2008	A1
20080244271	Yu	Oct 2008	A1
20080244277	Orsini et al.	Oct 2008	A1
20080255993	Blinbaum	Oct 2008	A1
20080294563	Boutahar et al.	Nov 2008	A1
20080306872	Felsher	Dec 2008	A1
20090006861	Bemmel	Jan 2009	A1
20090006920	Munson et al.	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
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
20090089193	Paintin	Apr 2009	A1
20090089209	Bixler et al.	Apr 2009	A1
20090099961	Ogilvy	Apr 2009	A1
20090106152	Dill	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
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
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
20100030687	Panthaki et al.	Feb 2010	A1
20100031022	Kramer	Feb 2010	A1
20100042537	Smith et al.	Feb 2010	A1
20100042539	Dheer et al.	Feb 2010	A1
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
20100115610	Tredoux et al.	May 2010	A1
20100131415	Sartipi	May 2010	A1
20100198729	Kavounas	Aug 2010	A1
20100269166	Awad et al.	Oct 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
20110112945	Cullen, III et al.	May 2011	A1
20110112954	Bruesewitz et al.	May 2011	A1
20110191160	Blackhurst et al.	Aug 2011	A1
20110202982	Alexander et al.	Aug 2011	A1
20110247058	Kisters	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
20110295746	Thomas et al.	Dec 2011	A1
20110313921	Dheer et al.	Dec 2011	A1
20110320347	Tumminaro et al.	Dec 2011	A1
20120016731	Smith et al.	Jan 2012	A1
20120041876	Nosek et al.	Feb 2012	A1
20120066121	Shahbazi et al.	Mar 2012	A1
20120116953	Klein et al.	May 2012	A1
20120173417	Lohman et al.	Jul 2012	A1
20120203695	Morgan et al.	Aug 2012	A1
20120209766	Kitchen et al.	Aug 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	Mendicino	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
20130117178	Mullen et al.	May 2013	A1
20130124405	Hamzeh	May 2013	A1
20130124406	Poplawski et al.	May 2013	A1
20130138557	Mullen	May 2013	A1
20130151384	Mullen et al.	Jun 2013	A1
20130212010	Mullen et al.	Aug 2013	A1
20130226627	Kubovcik et al.	Aug 2013	A1
20130232071	Dilip 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	Oct 2013	A1
20140006184	Godsey	Jan 2014	A1
20140046820	Sunderji et al.	Feb 2014	A1
20140058862	Celkonas	Feb 2014	A1
20140067677	Ali et al.	Mar 2014	A1
20140081783	Paranjape et al.	Mar 2014	A1
20140164246	Thomas et al.	Jun 2014	A1
20140188697	Bruesewitz et al.	Jul 2014	A1
20140188728	Dheer et al.	Jul 2014	A1
20140244515	Garfinkle et al.	Aug 2014	A1
20140310142	Mak	Oct 2014	A1
20140372308	Sheets	Dec 2014	A1
20160283918	Weinflash	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
20170024719	Finch et al.	Jan 2017	A1
20170024744	Finch et al.	Jan 2017	A1

Foreign Referenced Citations (93)

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
2 229 012	Mar 1997	CA
2 239 875	Jun 1997	CA
2 323 500	Sep 1999	CA
2 329 348	Nov 1999	CA
2 316 090	Feb 2001	CA
2 402 353	Sep 2001	CA
2423048	Mar 2002	CA
2 437 949	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
09-282367	Oct 1997	JP
2004532448	Oct 2004	JP
2008262601	Oct 2008	JP
1020120075590	Jul 2012	KR
1020140099676	Aug 2014	KR
2008012503	Dec 2008	MX
2008012504	May 2009	MX
1018913	Mar 2003	NL
1918913	Mar 2003	NL
9703800	Apr 1999	SE
200919343	May 2009	TW
9702539	Jan 1997	WO
9716798	May 1997	WO
9724891	May 1999	WO
1999024891	May 1999	WO
9934311	Aug 1999	WO
9946720	Sep 1999	WO
0055793	Sep 2000	WO
0058876	Oct 2000	WO
2001033522	May 2001	WO
0155984	Aug 2001	WO
0167364	Sep 2001	WO
0225605	Mar 2002	WO
2002025534	Mar 2002	WO
0235429	May 2002	WO
2002069561	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 (31)

Entry
Reframing the Infomated Household-Workplace; Gayle C. Avery, Ellen Baker; Information & Organization, 2002, vol. 12, Aug. 2001.
Electronic Cash and Monetary Policy; Mark Bernkopf; First Monday, vol. 1, No. 1-6, May 1996.
Electronic Payment Systems in European Countries; Country Synthesis Report; Final Version, Sep. 1999; Böhle, Rader, Riehm, Institut für Technikfolgenabschätzung und Systemanalyse for the European Science and Technology Observatory Network (ESTO).
Electronic Money in the 1990s: A Net Benefit or Merely a Trade-Off?; Mark E. Budnitz; HeinOnline--9 Ga. St. U. L. Rev. 747 1992-1993.
Digital Money—A Survey; Chida, Mambo, Shizuya; Graduate School of Information Sciences, Tohoku University; Received Jun. 15, 2001; Revised Aug. 21, 2001; Interdisciplinary Information Sciences. vol. 7, No. 2, pp. 135-165 (2001).
Defense Transportation's EDI Program: A Security Risk Assessment; PL205LN5; Logistics Management Institute; May 1993; Harold L. Frohman, William R. Ledder.
Managing Business with Electronic Commerce: Issues & Trends; Aryya Gangopadhyay; Idea Group Publishing (2002).
Factors Affecting the Successful Introduction of Mobile Payment Systems; Hans van der Heijden; Vrije Universiteit Amsterdam; 15th Bled Electronic Commerce Conference eReality; Constructing the eEconomy; Bled, Solvenia, Jun. 17-19, 2002.
Do Better Customers Utilize Electronic Distribution Channels? The Case of PC Banking; Dec. 2001; Lorin M. Hitt and Frances X. Frei.
The EBMG Reference Model on Electronic Markets: The Korean Case of JODAL; Eun Kim, Petra Schubert, Dorian Seltz and Bumtae Kim (2007).
PayPal in the Air!—A look at PayPal Mobile; Payment News; Glenbrook Partners; Glenbrook eCommerce Market Analysis Reports (2006).
A Stakeholder Perspective on Successful Electronic Payment Systems Diffusion; Sangjo Oh, Heejin Lee, Sherah Kurnia, Robert B. Johnston, Ben Lim; Department of Information Systems, the University of Melbourne Australia; Proceedings of the 39th Hawaii International Conference on Systems Sciences—2006.
Naval Postgraduate School, Monterey, California; Thesis, Financial Transaction Mechanisms for World Wide Web Applications; John R. Palumbo, Mar. 1996.
Naval Postgraduate School, Monterey, Calinfornia; Thesis, Security Management of Electronic Data Interchange; Hua-Fu Pao; Jun. 1993.
Electronic Payments of Small Amounts; Tobern P. Pedersen; Computer Science Department, Aarhus University (1998).
The Business Revolution through B2B Market Tone and its Impacts over the Financial System gong into 21st Century; Eveline Franco Veloso; The George Washington University; School of Business and Public Management; The Institute of Brazilian Business and Management Issues; XII Minerva Program-Fall 2000.
Households and Technology: The Case of Home Computers-Some Conceptual and Theoretical Issues; Alladi Venkatesh and Nicholas Vitalari, Project NOAH; Center for Research on Information Technology and Organizations (CRITO); originally appeared in M.L. Roberts and L. Wortzel (eds.) Marketing to the Changing Household, Ballinger Publishing, 1985, pp. 187-203.
SEMOPS: Design of a New Payment Service; A. Vilmos and S. Narnouskos; 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.
Building a World Class Infrastructure to Support E-Commerce in Malaysia; Raja Mohn Rosli bin Raja Zulkifli; 1997 Telekom Malaysia.
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 and Written Opinion for PCT/US10/36231, dated Nov. 8, 2010, 8 pages.
International Search Report and Written Opinion for PCT/US10/36233, dated Jul. 28, 2010, 7 pages.
International Search Report and Written Opinion for PCT/US10/36229, dated Jul. 28, 2010, 12 pages.
International Search Report and Written Opinion for PCT/US10/35465, dated Jul. 31, 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].
International Application No. PCT/US2016/042163, International Search Report and Written Opinion dated Sep. 26, 2016.

Related Publications (1)

	Number	Date	Country
	20130238489 A1	Sep 2013	US

Provisional Applications (1)

	Number	Date	Country
	61607882	Mar 2012	US

System and method for securely registering a recipient to a computer-implemented funds transfer payment network

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

US

CPC

International Classifications

Term Extension

Abstract