Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services

Information

  • Patent Grant
  • 11995621
  • Patent Number
    11,995,621
  • Date Filed
    Friday, October 21, 2022
    2 years ago
  • Date Issued
    Tuesday, May 28, 2024
    8 months ago
Abstract
A computer-implemented method includes receiving, by a provider computing system, a transfer tag associated with a recipient from a user device associated with a sender. The computer-implemented method further includes performing, by the provider computing system, a tag conversion process on the transfer tag to create a tag-based identifier corresponding to the transfer tag. The computer-implemented method further includes generating, by the provider computing system, a transfer request including the tag-based identifier. The computer-implemented method further includes sending, by the provider computing system, the transfer request to a transfer service computing system, the transfer request initiating a transfer of a resource to a recipient account of the recipient based on the tag-based identifier.
Description
TECHNICAL FIELD

The present disclosure relates to improved computer processing systems for real-time services through the use of native, non-native, and hybrid tags.


BACKGROUND

Many different digital transaction platforms exist. However, interoperability between the digital platforms is limited due to, for example, the incompatibility of the data used between the digital platforms. As a more specific example, users can register to engage in transactions (such as funds transfers or payments) through a payment service. Registration with the payment service may include identifying an account as a source of funds for funds transfers. Once registered, the user can partake in funds transfers with other registered users. These transactions may be completed by the user (sender) initiating the transaction with a recipient. However, wide applicability of the system is typically challenging given that registration of the sender and recipient with the system is required. This is especially true in certain instances where users may be reluctant to link their bank account to a non-bank entity digital transaction service. Moreover and even if the users do link their account with the digital transaction service, technical implementation hurdles remain to enable transactions between different entities.


SUMMARY

One embodiment relates to a computer-implemented method. The computer-implemented method includes receiving, by a provider computing system, a transfer tag associated with a recipient from a user device associated with a sender. The computer-implemented method further includes performing, by the provider computing system, a tag conversion process on the transfer tag to create a tag-based identifier corresponding to the transfer tag. The computer-implemented method further includes generating, by the provider computing system, a transfer request including the tag-based identifier. The computer-implemented method further includes sending, by the provider computing system, the transfer request to a transfer service computing system, the transfer request initiating a transfer of a resource to a recipient account of the recipient based on the tag-based identifier.


Another embodiment relates to a computer-implemented method. The computer-implemented method includes receiving, by a provider computing system, a desired transfer tag from a user device. The computer-implemented method further includes performing, by the provider computing system, a tag conversion process on the desired transfer tag to create a desired-tag-based identifier corresponding to the desired transfer tag. The computer-implemented method further comprises registering, by the provider computing system, an account of a user associated with the user device for a transfer service provided by a transfer service computing system using the desired-tag-based identifier.


Still another embodiment relates to a provider computing system. The provider computing system includes one or more processing circuits including one or more processors and one or more memories having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to receive a transfer tag associated with a recipient from a user device associated with a sender. The instructions, when executed by the one or more processors, further cause the one or more processors to perform a tag conversion process on the transfer tag to create a tag-based identifier corresponding to the transfer tag. The instructions, when executed by the one or more processors, further cause the one or more processors to generate a transfer request including the tag-based identifier. The instructions, when executed by the one or more processors, further cause the one or more processors to send the transfer request to a transfer service computing system, the transfer request initiating a transfer of a resource to a recipient account of the recipient based on the tag-based identifier.


These and other features, together with the organization and manner of operation thereof, will become apparent from the following detailed description and the accompanying drawings. Numerous specific details are provided to impart a thorough understanding of embodiments of the subject matter of the present disclosure. The described features of the subject matter of the present disclosure may be combined in any suitable manner in one or more embodiments and/or implementations. In this regard, one or more features of an aspect of the invention may be combined with one or more features of a different aspect of the invention. Moreover, additional features may be recognized in certain embodiments and/or implementations that may not be present in all embodiments or implementations.





BRIEF DESCRIPTION OF THE FIGURES


FIG. 1 is a block diagram of a computing system enabling a real-time service via generating and employing transfer tags, according to an example embodiment.



FIG. 2 is a block diagram of an identifier management logic that may manage registered identifiers associated with various users of the system of FIG. 1, according to an example embodiment.



FIG. 3 is a flow diagram of a method for a native registration process, according to an example embodiment.



FIG. 4 is a flow diagram of a method for a non-native registration process, according to an example embodiment.



FIG. 5 is a flow diagram of a method for a hybrid, non-native registration process, according to an example embodiment.



FIGS. 6 and 7 depict example graphical user interfaces depicting registration interfaces, according to an example embodiment.



FIG. 8 is a flow diagram of a method for a native transfer process, according to an example embodiment.



FIG. 9 is a flow diagram of a method for a non-native transfer process, according to an example embodiment.



FIG. 10 is a flow diagram of a method for a hybrid, non-native transfer process, according to an example embodiment.



FIGS. 11 and 12 depict graphical user interfaces depicting fund transfer interfaces, according to an example embodiment.





DETAILED DESCRIPTION

Various embodiments described herein relate to systems, methods, and devices for registering and using various identifiers to effectuate real-time or nearly real-time services involving multiple entities over a network. In one example embodiment, the real-time or nearly real-time service is a fund transfer and, particularly, a person-to-person (P2P) fund transfer. In other example embodiments, different services are contemplated.


As described herein, a real time or nearly real-time transfer service computing system environment includes a transfer service computing system configured to route transfer requests between sender and recipient devices based on one or more registered identifier(s) via a network. Each of the sender and recipient devices are associated with a corresponding sender/recipient computing system that is owned, controlled, managed, and/or operated by a corresponding provider institution (e.g., a financial institution). Each sender/recipient computing system is configured to store account information related to a plurality of customer accounts (e.g., accounts of senders and/or recipients). The sender/recipient computing systems are further configured to receive, store, utilize, and allow users to register or associate one or more of their accounts with certain identifier types (e.g., phone numbers, e-mail addresses, transfer tags) based on a level of implementation of a transfer service provided by the transfer service computing system in the corresponding sender/recipient computing system.


With this in mind and regarding the levels of implementation of the transfer service, the terms “native”, “non-native”, and “hybrid” are used herein to describe the sender/recipient computing systems as having various different implementation levels of the transfer service. In particular, these terms indicate the varying identifier types that may be used in each sender/recipient computing system application. Accordingly, “native” computing systems are systems that have fully implemented the use of transfer tags locally, and are configured to receive, store, utilize, and associate any of phone numbers, e-mail addresses, and/or transfer tags with users and their accounts. In contrast, “non-native” and “hybrid” computing systems are systems that have not fully implemented the use of transfer tags locally, and are configured only to store, utilize, and associate any of phone numbers and/or e-mail addresses with users and their accounts.


As used herein, the terms “transfer tag” or “tag” are used to describe a string of alphanumeric and/or symbolic characters for association with a given user account. In one embodiment, the user may select the tag during a registration process. Transfer tags are treated as a separate type of identifier (i.e., separate from phone numbers and e-mail addresses) within the transfer service computing environment that may be separately queried within a database of the transfer service computing system (as well as within databases of native systems) to appropriately route transfers, register the user with a given transfer tag, and/or identify a given user based on a transfer tag.


The varying levels of implementation capabilities across the various entities using the transfer service could, if unaddressed, prevent customers of non-native and hybrid computing systems from effectively transferring funds to customers of native computing systems based on the native computing system's customers' transfer tags. Further, it could also prevent customers of non-native and hybrid computing systems from registering their accounts with desired transfer tags. These issues could cause significant customer frustration and potentially result in customers abandoning usage of the transfer service altogether.


However, to account for varying levels of implementation across the various entities using the transfer service, the systems and methods described herein provide a technical solution of utilizing tag-based identifiers, which are shown as e-mail addresses in certain embodiments herein. The tag-based identifiers may correspond to the transfer tags and enable users of non-native and hybrid systems to functionally utilize transfer tags within the system, even though the non-native and hybrid systems have not fully implemented the use of transfer tags locally. Thus, the present disclosure provides for technical interoperability across different computing architectures and functionalities to enable ubiquitous operation across these distinct and different systems. In operation, a specific tag-related domain may be created (e.g., “@fundtag.com”), which may be appended to the transfer tags within the system to create corresponding tag-based identifiers (e.g., tag-based e-mail addresses). These tag-based identifiers may then be utilized by the non-native and hybrid systems without having to fully implement the use of transfer tags locally, because the non-native and hybrid systems are already configured to process e-mail addresses. The transfer service computing system is then further configured to recognize the tag-based identifiers based on the tag-related domain, and to register users and/or route fund transfers based on the tag-based identifiers and/or their corresponding transfer tags interchangeably. For example, if a user registers an account using a transfer tag or a tag-based identifier, the transfer service computing system is configured to automatically create and store an entry in a database indicating an association between (1) the user (e.g., the user's account, a provider institution managing the user's account) and (2) both the transfer tag and the corresponding tag-based identifier. Accordingly, when the transfer service computing system receives future fund transfer requests including either the transfer tag or the corresponding tag-based identifier associated with the user, the transfer service computing system is configured to query the database for the transfer tag or the corresponding tag-based identifier and to route the transfer requests to the user based on either one.


In some instances, users of non-native systems may need to know that, if the user is attempting to register their account with a transfer tag or to send a fund transfer request to a recipient's transfer tag, the user needs to manually append the tag-related domain to the transfer tag to create the tag-based identifier. In some instances, users of non-native systems may be prompted during a registration attempt or a fund transfer request process to manually append the tag-related domain to the transfer tag to create the tag-based identifier. In either case, the non-native system is then configured to receive and handle the tag-based identifier as a normal e-mail address. On the other hand, the hybrid systems may be configured to partially process transfer tags. That is, the hybrid systems are configured to generate modified user interfaces that are configured to receive transfer tags and then automatically convert the received transfer tags to the corresponding tag-based identifiers by appending the tag-related domain. Accordingly, users of the hybrid systems may not be aware that their respective systems have not fully implemented the use of transfer tags locally.


Beneficially, because the transfer service computing system is configured to register users and/or route fund transfers between users based on the tag-based identifiers and the corresponding transfer tags interchangeably, the use of the tag-based identifiers within the transfer service computing environment provides interoperability among the native, non-native, and hybrid systems. Additionally, because the transfer service computing system is configured to register (e.g., create and store an entry indicating an association between the user and a corresponding identifier(s) within a database) the user with both the tag-based identifier and the corresponding transfer tag, regardless of which one the user provides to the transfer service computing system, database management within the transfer service computing environment is improved because the tag-based identifier provides a ubiquitous identifier that is useable across native, non-native, and hybrid systems. The use of this ubiquitous identifier further improves (i.e., reduces) processing times associated with the transfer service computing system routing transfers from senders to recipients, thereby reducing latency and providing faster transfer times for real-time or nearly real-time transfers.


Further, because the transfer service computing system is configured to register the users based on the tag-based identifiers and the corresponding transfer tags interchangeably, users of non-native and hybrid systems are allowed to “claim” a desired transfer tag(s) within the transfer service computing system, such that the claimed transfer tag(s) is no longer available for use by other users, even though the user's systems has not implemented the use of transfer tags locally. The ability for the users of non-native and hybrid systems to claim desired transfer tag(s) prevents these users from having their desired transfer tag(s) claimed by other users before the non-native and hybrid systems fully implement the use of transfer tags locally. Additionally, the ability for the users of non-native and hybrid systems to claim desired transfer tag(s) allows for the users to associate a variety of different accounts with a variety of different transfer tags (e.g., a first customer account is registered with a first transfer tag, a second customer account is registered with a second transfer tag, a third customer account is registered with a third transfer tag). That is, the use of transfer tag(s) provides increased flexibility for users as compared to traditional phone number and e-mail address identifiers. For example, users may generally only have a limited number of phone numbers and/or email addresses available for registering with their various accounts. Conversely, by allowing for users of non-native and hybrid systems to register their accounts using transfer tags, the users are allowed to create and register new, unique transfer tags for as many different accounts as they would like.


Further, because the tag-based identifiers are in a format already used locally by the non-native and/or hybrid computing systems (e.g., an e-mail address), the non-native and hybrid computing systems are configured to use the tag-based identifiers without needing to immediately implement updated software associated using transfer tags locally, thereby allowing for the various computing systems within the transfer service computing environment to gradually implement the use of transfer tags locally and reducing a computational burden placed on the transfer service computing system. That is, in order to implement the updated software, the various sender/recipient computing systems within the transfer service computing environment may each have to pull (i.e., download) the software update from the transfer service computing system over the network. By allowing for a more gradual implementation across the transfer service computing environment, the computational burden placed on the transfer service computing system at any given time is reduced (e.g., by spreading the computation burden over a larger time period).


Referring now to FIG. 1, a real time or nearly real-time transfer service computing environment/system 100 is shown, according to an example embodiment. The system 100 allows for native, non-native, and hybrid registration and use of transfer tags for transfers (namely, payments described herein) according to various embodiments. The system 100 is configured to be utilized by senders to send funds to recipients, by recipients to receive the funds or request funds in a pull payment relationship, and by intermediaries who may apply restrictions or require approval before funds may be transferred. Beneficially, the system 100 facilitates the transfer of funds from senders to receivers without either party sharing information about their financial accounts with each other. This adds security to digital fund transfers. The senders and recipients may be individuals, groups of individuals, organizations, representatives of organizations, and so on. In certain embodiments, a sender may use a bank account as a 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 system 100 is configured to 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 system 100 is shown to include a sender computing system 110, a recipient computing system 120, a transfer service computing system 130 of a service provider, sender devices 150 associated with users registering their accounts and/or creating fund transfer requests, an Automated Clearing House (ACH) computing system 170, and recipient devices 180 associated with recipients of fund transfer requests. Each of the above described systems may communicate through a network 140, which may be a wireless and/or wired network, including, for example, one or more of the Internet, Cellular network, Wi-Fi, Wi-Max, a proprietary banking network, and so on. As will be described below, each system and device in system 100 includes, for communicating via network 140, may include a network interface device and network interface logic that may include, for example, program logic that connects the system or device to the network 140 or to other systems and devices. The network interface logic may facilitate secure communications between the bank, the sender, and/or the recipient. The network interface logic may also facilitate communication with other entities, such as other banks, settlement systems, and so on. The network interface logic may include user interface program logic configured to communicate with client applications running on other computing systems and devices, and generate and present web pages to users accessing a computing system over the network 140.


In FIG. 1 and other parts of the description, for sake of discussing example embodiments, it may be assumed that the sender performs a funds transfer from an account maintained by the sender computing system 110 and the receiver receives the funds using an account maintained by the recipient computing system 120. Hence, the sender computing system 110 may be associated with a sender financial institution computing system and the recipient computing system 120 may be associated with a receiver financial institution computing 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 examples provided herein may be 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. Further, while examples provided herein may be in the context of funds transfers, the same or similar processes may additionally or alternatively be utilized to enable transfers of a variety of other resources (e.g., documents, software applications, data or other information), as desired for a given application.


The sender devices 150 are configured to be used by users (e.g., a business owner or employee, a consumer, and so on) to initiate, accept, and/or request transactions and interact with banking functions provided through an online banking application or other client application, an online banking area of a website provided by the sender computing system 110 (or the recipient computing system 120), or through an a client application or website provided by the transfer service computing system 130. The sender devices 150, for example, may be or may comprise personal computers (e.g., desktops or laptop computers), smartphones, tablet computers, wearable devices (e.g., smartwatches), smart assistants/smart speakers, a personal digital assistant, a portable gaming device, or other suitable device. In some embodiments, the sender devices 150 may be part of, or may be replaced by, 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 initiating a funds transfer or payment is a merchant such as an online retailer or another organization.


The recipient devices 180 are similarly configured to be used by users (e.g., a business owner or employee, a consumer, and so on) to initiate, accept, and/or request transactions and interact with banking functions provided through an only banking functions provided through an online banking application or other client application, an online banking area of a website provided by the recipient computing system 120 (or the sender computing system 110), or through an a client application or website provided by the transfer service computing system 130. The recipient devices 180, for example, may be or may comprise personal computers (e.g., desktops or laptop computers), smartphones, tablet computers, wearable devices (e.g., smartwatches), smart assistants/smart speakers, a personal digital assistant, a portable gaming device, or other suitable device. In some embodiments, the recipient devices 180 may be part of, or may be replaced by, 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 accepting a funds transfer or payment is a merchant such as an online retailer or another organization.


A sender and/or recipient may own, operate, control, manage, and/or otherwise be associated with one or more sender and recipient devices 150 and 180, respectively. Sender devices 150 include one or more user interfaces 152 (devices or components that interface with the user), which may include one or more biometric sensors 154 (such as a fingerprint reader, a heart monitor that detects cardiovascular signals, face scanner, an iris scanner, etc.). User interfaces 152 also include input/output (“I/O”) devices 156 that provide perceptible outputs (such as display devices with display screens and/or light sources for visually-perceptible elements, an audio speaker for audible elements, and haptics or vibration devices for perceptible signaling via touch, etc.), that capture ambient sights and sounds (such as digital cameras, microphones, etc.), and/or allow the user to provide inputs (such as a touchscreen display, stylus, keyboard, force sensor for sensing pressure on a display screen, etc.).


Sender devices 150 further include one or more location sensors 158 configured to enable the sender device 150 to determine its location relative to, for example, other physical objects or relative to geographic locations. Example location sensors 158 include global positioning system (GPS) devices and other navigation, location, and geolocation devices, digital compasses, gyroscopes and other orientation sensors, as well as proximity sensors or other sensors that allow the sender device 150 to detect the presence and relative distance of nearby objects and devices. The sender devices 150 store in computer memory, and execute (“run”) using one or more processors, client applications 160, such as an Internet browser presenting websites, a banking application, an application of a payment platform, and applications provided or authorized by the entity implementing or administering any of the computing systems in system 100. Example client applications may present the user interfaces presented in the figures.


The sender devices 150 further includes network interface logic 162. The network interface logic 162 includes, for example, program logic that connects the sender devices 150 to the network 140. The network interface logic 162 facilitates secure communications between the user and the bank, the sender, and/or the recipient. The network interface logic 162 also facilitates communication with other entities, such as other banks, settlement systems, and so on.


Similarly, recipient devices 180 (which may be, or may comprise, one or more computing devices) include one or more user interfaces 182, which may include one or more biometric sensors 184. User interfaces 182 also include input/output components 186 that provide perceptible outputs that capture ambient sights and sounds and/or allow the user to provide inputs. Recipient devices 180 similarly include one or more location sensors 188 to enable the recipient device 180 to determine its location relative to, for example, other physical objects or relative to geographic locations. The recipient devices 180 also similarly store in computer memory, and execute (“run”) using one or more processors, various client applications 190. The recipient devices 180 similarly includes network interface logic 192, which may be substantially similar to the network interface logic 162 of the sender device 150.


The sender devices 150 and recipient devices 180 generate and/or receive and display screens on the I/O devices 156 (e.g., from the sender, recipient, and/or transfer computing systems), 186 including account information, transaction instructions, and so on. In an example embodiment, such screens may be used to request and/or receive 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. In some instances, such information comprises, for example, a transfer tag, 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.


The client applications 160 and/or 190 comprise program logic (i.e., stored executable instructions) configured to implement at least some of the functions described herein. The client applications 160 and/or 190 may be downloaded to the sender and recipient devices for execution. Alternatively, the client applications 160 and/or 190 may be hard-coded into the sender and recipient devices. As will be appreciated, the level of functionality that resides on the sender devices 150 and recipient devices 180 as compared to other components of the system 100 may vary depending on the implementation. In some instances, the client application 160 and/or 190 may be a web browser (e.g., “Internet Explorer,” “Mozilla Firefox,” “Chrome,” “Safari,” and so on) configured to receive and display web pages received from another component of system 100. 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. In some instances, the client applications 160 and/or 190 are managed, operated, updated, maintained, and/or provided to the sender devices 150 and recipient devices 180 by the sender computing system 110, the recipient computing system 120, and/or the transfer service computing system 130.


The sender computing system 110 may be operated by a provider, such as a bank or other financial institution that maintains accounts held by customers (e.g., demand deposit accounts, credit card accounts, home mortgage loans, student loans, and so on). The sender computing system 110, for example, comprises 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 the figures.


The sender computing system 110 includes network interface logic 112, account processing logic 114, identifier management logic 116, and an account and user database 118. The network interface logic 112 includes, for example, program logic that connects the sender computing system 110 to the network 140. The network interface logic 112 facilitates secure communications between the bank and the sender and/or the recipient. The network interface logic 112 also facilitates communication with other entities, such as other banks, settlement systems, and so on. The network interface logic 112 includes user interface program logic configured to generate and present web pages to users accessing the sender computing system 110 over the network 140.


The account processing logic 114 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 114 is configured to track the transaction and modify an entry/ledger in the user database 118 to reflect the debit or credit. The account processing logic 114 also processes fund transfer requests to transfer funds from a sender using the sender devices 150 to a recipient using the recipient device 180.


The account and user database 118 stores account information (e.g., transaction, information about the account holder, associated identifiers, and so on) for accounts that are maintained by the financial institution (or other non-bank entity) on behalf of its customers. The account and user database 118 is configured to be used by the identifier management logic 116 when an identifier other than a bank account/routing number is used (e.g., an e-mail address, phone number, transfer tag, Universal Payment Identification Code (UPIC), randomly generated number, and so on) to identify a recipient of a funds transfer. That is, the account and user database 118 is configured to allow the sender computing system 110 (particularly, the account processing logic 114 and the identifier management logic 116) to query, convert, or otherwise correlate the recipient's identifier (e.g., cell phone number, e-mail address, transfer tag, 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 based on the identifier, without utilization of private/personal information of the recipient (e.g., a recipient's bank account/routing number) for the real-time or nearly real-time transfer.


As an example, the identifier management logic 116 is configured to allow users to register and be added to the account and user database 118 prior to, during, and/or after a transaction. Upon registration, a new entry is created by the identifier management logic 116 for the newly registered user in the account and user database 118. For example, the user may provide one or more identifiers regarding the users that are configured to be shared with other users for using the real-time or nearly real-time transfer service. The “identifier” refers to a user-identifying value. The identifiers may include, for example, a transfer tag, a phone number regarding the user, an e-mail address(es) regarding the user, and so on. As will be described further herein, in some instances, the sender computing system 110 is configured to process differing types of identifiers based on a level of implementation by the sender computing system 110 of a transfer service provided, offered, and/or maintained by the transfer service computing system 130.


In some embodiments, the identifier management logic 116 is configured to accept and process identifiers (e.g., phone numbers, e-mail addresses, and transfer tags) directly. In these instances, as described above, the sender computing system 110 may be considered a native system (e.g., having fully implemented certain features of the transfer service).


In this regard, the phrase “accept and process” used in this context refers to the identifier management logic 116 being configured to receive and utilize an identifier (e.g., phone numbers, e-mail addresses) to perform various operations (e.g., performing queries within the account and user database 118, creating new associations between customer accounts and the identifiers within the account and user database 118). Further, “direct” processing refers to the identifier management logic 116 being configured to receive an identifier and to utilize the identifier to perform the various operations in the form that the identifier is originally received (i.e., if a phone number is received by the identifier management logic 116 from a customer, the identifier management logic 116 is configured to query the account and user database 118 for the phone number and create a new association between the customer's account and the phone number within the account and user database 118).


In some other instances, the identifier management logic 116 is configured to accept and process phone numbers and e-mail addresses directly, but is not configured to process transfer tags (directly or indirectly). In these instances, the sender computing system 110 may be considered a non-native system (e.g., not having fully implemented certain features of the transfer service). In yet some other instances, the identifier management logic 116 is configured to accept and process phone numbers and e-mail addresses directly, and is configured to accept and process transfer tags indirectly. In this context, “indirect” processing refers to the identifier management logic 116 being configured to receive an identifier and, particularly a transfer tag, and convert the identifier to a tag-based identifier to be utilized while performing various operations, as will be described below. In these instances, the sender computing system 110 may be considered a hybrid system (e.g., not having fully implemented certain features of the transfer service, while still allowing for transfer tags to be utilized). Accordingly, in various embodiments, the sender computing systems 110 of the system 100 are configured as native, non-native, and/or hybrid systems depending on the level of implementation of the transfer service, and are thus configured to accept and process differing types of identifiers. Identifier management logic is discussed in greater detail below in connection with FIG. 2.


In some instances, the sender computing system 110 also generates or otherwise associates an identifier that is securely maintained and that is used to identify the user in the account and user database 118. Herein, such identifiers are referred to as “private identifiers.” The private identifier may, for example, be a unique ID associated with the database entry for the user in the account and user database 118, and need not be known by the user with whom it is associated or by other users. In some embodiments, digital tokens comprising or corresponding to public identifiers (e.g., phone numbers, e-mail addresses, transfer tags) and/or private identifiers are generated.


Additionally, in some instances, the account and user database 118, for each user, also stores 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, or when a tag is established or generated. 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. For each user in the registry, additional information is stored within the account and user database 118, such as their unique ID and/or various other information.


The recipient computing system 120 is configured in a similar manner as the sender computing system 110, with network interface logic 122, account processing logic 124, identifier management logic 126, and account and user database 128. It should be appreciated that the various logic and database components of the recipient computing system 120 may function in a substantially similar manner as the corresponding components of the sender computing system 110 discussed above. As such, it should also be appreciated that any of the various methods and operations of the logic and database components of the sender computing system 110 described herein may be similarly applied to the corresponding components of the recipient computing system 120. For example, similar to the sender computing system 110, in various embodiments, the recipient computing systems 120 of the system 100 are configured as native, non-native, and/or hybrid systems depending on the level of implementation of the transfer service, and are thus configured to accept and process differing types of identifiers.


The transfer service computing system 130 is controlled by, managed by, owned by, and/or otherwise associated with a transfer service entity that is configured to enable real-time or nearly real-time transfers. The transfer service entity may be a financial institution (e.g., a card network) or other entity that supports transfers across multiple different entities (e.g., across different financial institutions). As described herein and in one embodiment, the “transfer” is a payment or fund transfer. However, the present disclosure is also applicable with other types of transfers, such as the secure transfer of information (e.g., documents). The payment or fund transfer may include electronic or digital fund transfers. In some instances, the transfer service entity 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 transfer service entity may be a third party vendor. As still another example, the transfer service entity may be provided by one of the banks, i.e., such that the bank (e.g., the sender computing system 110 and/or the recipient computing system 120) includes and performs both the components and operations described herein as being included in and performed by the sender computing system 110 or the recipient computing system 120, as well as the components and operations described herein as being included in and performed by the transfer service computing system 130.


The transfer service computing system 130 is configured, in various embodiments, to provide (e.g., through its own client application or through integration with a client application of another entity, such as a banking application) at least some of the functionality depicted in the figures and discussed below. Some of that functionality is configured to be provided via identifier processing logic 132. As an example, the transfer service entity provides or hosts a web portal provided for an online community of individuals where such individuals obtain user names/login IDs or otherwise become registered members to enable real-time or nearly real-time transfers between senders and recipients.


Herein, banks or financial institutions associated with computing systems 110 and 120 are “member banks” or “member institutions” that follow established protocols for transferring funds using system 100. For example, in the context of a transfer 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 (i.e., sender computing system 110 and recipient computing system 120), it will be appreciated that there may be additional member banks. Additionally, as previously indicated, non-bank entities may also be members. Additionally, in some instances, members and/or member banks may have varying levels of implementation of various features associated with the transfer service described herein (e.g., account/user identifier processing capabilities). Accordingly and as described herein, the members and/or member banks may be considered native, non-native, or hybrid members based on their respective levels of implementation, as will be described further below.


To allow for varying levels of implementation between the various members, the transfer service computing system 130 is configured to generate and maintain a tag-related domain configured to be specifically recognized and used within the system 100 to allow for users to both register their accounts with transfer tags (i.e., register with the transfer service computing system 130) and to send or receive funds to or from accounts associated with transfer tags, regardless of the level of implementation of their bank's or non-bank entity's computing system. In particular and as described in one embodiment herein, the tag-related domain is an email domain (e.g., “@fundtag.com”).


When the sender/recipient computing system 110, 120 is configured as a non-native or hybrid computing system and a user attempts to register an account or transfer funds using a transfer tag, the tag-related domain is appended, either by the user (in the non-native configuration) or automatically (in the hybrid configuration) by the sender/recipient computing system 110, 120, to the end of the transfer tag provided by the user to create a tag-based identifier. For example, if a user's transfer tag is “Happy123” and the e-mail domain is “@fundtag.com,” the corresponding converted tag-based identifier is “Happy123@fundtag.com.” Accordingly and in addition to registering and processing requests associated with phone numbers, e-mail addresses, and tags directly, the identifier processing logic 132 of the transfer service computing system 130 is further configured to recognize when either a tag or a tag-based identifier is used to register a new user or to transfer funds. Then, regardless of whether a tag or a tag-based identifier is used, the identifier processing logic 132 is configured to register both the tag and the corresponding tag-based identifier within the identifier database 134 and/or process the fund transfer request by identifying the sender or recipient (or the sender/recipient computing system 110, 120) using either of the tag or the corresponding tag-based identifier, as will be described further below.


In some instances, the transfer service provided by the transfer service computing system 130 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 transfer service computing system 130. Hence, users do not need to be customers of any particular bank in order to be able to transfer funds via system 100.


In some embodiments, transfer service computing system 130 may, for example, comprise one or more servers, each with one or more processing circuits including one or more processors configured to execute instructions stored in one or more memory devices, send and receive data stored in the one or more memory devices, and perform other operations to implement the operations described herein associated with certain logic and/or processes depicted in the figures. Although not specifically shown, it will be appreciated that the transfer service computing system 130 may include network interface logic, various databases, account processing logic, and other logic in the same or similar manner to the other components of system 100. The network interface logic may include user interface program logic configured to generate and present application pages, web pages, and/or various other data to users accessing the transfer service computing system 130 over the network 140.


The ACH computing system 170 is configured to be 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.



FIG. 2 shows an example identifier management logic 200 in greater detail. The identifier management logic 200 may be substantially similar to the identifier management logic 116 of the sender computing system 110 and/or the identifier management logic 126 of the recipient computing system 120. For example, each identifier management logic depicted in system 100 may include all, or a subset, of the elements shown in FIG. 2. As depicted, the identifier management logic 200 may include registration logic 210, identifier verification logic 220, and request processing logic 230.


The registration logic 210 is configured to register users for the transfer service provided by the transfer computing system and supported by the sender and recipient computing systems. In operation, the registration logic 210 is configured to generate pages or screens (e.g., user interfaces 600, 700 shown in FIGS. 6 and 7) for presentation to the user at the website or client application of a sender device 150 to facilitate the registration process. The registration logic 210 is additionally configured to create new database entries (e.g., within a corresponding account and user database 118, 128) responsive to the registration of various new identifiers by users.


In some instances, the user is required to sign into the client application 160 (or client application 190) provided to the sender device 150 (or the recipient device 180) prior to registration. Accordingly, the registration logic 210 is configured to utilize the user's sign-in information (e.g., username, password) to query the corresponding account and user database 118, 128 to identify the user and the user's account(s) at a provider institution associated with the sender/recipient computing system 110, 120. In some instances, the registration logic 210 is further configured to allow the user to select one account from a plurality of accounts associated with the user to be associated with an identifier(s) provided for registration. That is, if a user is associated with a plurality of accounts within the corresponding account and user database 118, 128, the registration logic 210 is configured to allow the user to select one account of the plurality of accounts to be associated with the provided identifier(s).


In some instances, the registration logic 210 is further configured to share information associated with registration events with the transfer service computing system 130. For example, the registration logic 210 is further configured to send an indication of association between new identifiers and users and/or accounts to the transfer service computing system 130 to be stored within the identifier database 134.


In some other instances, the registration logic 210 is configured to inform the transfer service computing system 130 that a new identifier (or multiple new identifiers) has been registered with a corresponding system (e.g., the sender or recipient computing system 110, 120) without providing any personal information related to the user. In these instances, the transfer service computing system 130 is configured to store an association between the new identifier (or multiple new identifiers) and the corresponding system within the identifier database 134. In some instances, the registration logic 210 is configured to provide certain information (e.g., name, address, other associated phone numbers, other associated e-mails) to the transfer service computing system 130, as desired for a given application.


In any case, as described herein, when a user registers with a tag-based identifier, the transfer service computing system 130 is configured to recognize the tag-based identifier received from the registration logic 210 based on a tag-related domain included within the tag-based identifier. Upon recognizing the tag-based identifier, the transfer service computing system 130 is configured to automatically store an association between the user, account, and/or the corresponding system and both the tag-based identifier and the transfer tag corresponding to the tag-based identifier within the identifier database 134.


The registration logic 210 is configured to accept and/or process various inputs (e.g., identifiers) received from the user during a registration process based on the level of implementation of the transfer service within the corresponding system (e.g., the sender or recipient computing system 110, 120). For example, if the sender or recipient computing system 110, 120 is a native system, the registration logic 210 is configured to receive a phone number, an e-mail address, and/or a desired transfer tag from the user. The registration logic 210 of the native system is then configured to register the user using any of the phone number, the e-mail address and/or the desired transfer tag. That is, the registration logic 210 is configured to associate the user's account(s) with any of the phone number, the e-mail address, and/or the desired transfer tag, and to store this association within the corresponding account and user database 118, 128.


Alternatively, if the sender or recipient computing system 110, 120 is a non-native system, the registration logic 210 is only configured to receive a phone number and/or an e-mail address from the user (i.e., not a transfer tag). The registration logic 210 is then configured to register the user using the phone number and/or the e-mail address from the user by directly associating the user's account(s) with the phone number and/or the e-mail address, and storing this association within the corresponding user database 118, 128. In this case, if the user desires to register their account with a transfer tag for fund transfers, the user may register their account by providing, at least in part, a tag-based e-mail address (i.e., a tag-based identifier) during the registration process.


By providing the tag-based identifier (e.g., the tag-based email address) during the registration process, when the registration logic 210 shares the registration information with the transfer service computing system 130, the transfer service computing system 130 is configured to recognize the tag-related domain and automatically associate the user, account, and/or the corresponding computing system with both the tag-based identifier and the corresponding tag. Accordingly, although the user's account may only be associated with the tag-based identifier (i.e., the tag-based e-mail) in the corresponding account and user database 118, 128, the user's desired transfer tag will still be indirectly registered to their account within the identifier database 134 of the transfer service computing system 130.


The use of the tag-based identifiers and the capability of the transfer service computing system 130 to recognize and identify tags and tag-based identifiers interchangeably allows for the registration of transfer tags by systems having varying levels of capabilities/implementation of the transfer service. Accordingly, users of non-native and hybrid computing systems (i.e., senders and/or recipients having accounts held by corresponding sender/recipient computing systems 110, 120 configured as non-native and hybrid computing systems) are allowed to “claim” transfer tags within the system 100, such that the transfer tags are made unavailable for use and/or registration by other users within the system 100, even though the users' providers' computing systems (e.g., the sender/recipient computing system 110, 120) are not configured to locally associate the user's account with the transfer tag.


That said, in some instances, the non-native systems (i.e., the sender/recipient computing systems 110, 120 configured as non-native systems) require the user to provide the tag-based identifiers to register their account with a transfer tag within the system 100. That is, the provider institutions may inform or otherwise instruct the users on how to create and use the tag-based identifier to register accounts with corresponding transfer tags within the system 100. In some other instances, the registration logic 210 of the non-native systems (i.e., the sender/recipient computing systems 110, 120 configured as non-native systems) is configured to provide a prompt (e.g., provided as a pop-up notification within the client application 160, 190, a push message that links to the client application 160, 190, etc.) to the sender/recipient device 150, 180 associated with the user instructing the user on how to create and use the tag-based identifier to register selected accounts with corresponding transfer tags within the system 100.


On the other hand, if the sender or recipient computing system 110, 120 is hybrid system, the registration logic 210 is configured receive any of a phone number, an e-mail address, and/or a transfer tag from the user during a registration process. If the user enters a phone number or an e-mail address, the registration logic 210 registers the user as discussed above, with respect to the non-native system. However, if the user enters a transfer tag, the registration logic 210 is configured to automatically perform a tag conversion process to create a corresponding tag-based identifier (e.g., a tag-based e-mail address) by automatically appending the tag-related domain to the received transfer tag.


In some instances, the registration logic 210 is configured to receive the tag-related domain from the transfer service computing system 130 prior to the registration process, and to store the tag-related domain within a memory of the registration logic 210, such that the tag-related domain is automatically retrieved from the memory of the registration logic 210 and appended to the transfer tag entered by the user during the registration process. In other instances, the registration logic 210 is configured to transmit a request for a current tag-related domain to the transfer service computing system 130 upon receipt of the transfer tag from the user during the registration process. The registration logic 210 may then receive the current tag-related domain from the transfer service computing system 130 and append the current tag-related domain to the received unique identifier. In this case, if the tag-related domain is changed within the system, the registration logic 210 is configured to ensure that the correct tag-related domain is appended to the received unique identifier. That is, in some instances, the stored tag-related domain is periodically updated by requesting and receiving the current tag-related domain from the transfer service computing system 130 to accommodate changing tag-related domains over time, which may be updated within the transfer service computing system 130 for a variety of reasons.


The registration logic 210 may then associate the tag-based identifier (e.g., the tag-based e-mail address) with the user and/or user's account as it would any other provided e-mail address. That is, although the registration logic 210 of the hybrid system is not configured to process transfer tags as a separate type of identifier to be associated with user accounts, the registration logic 210 is configured to treat the tag-based identifier created using the tag conversion process as an e-mail type identifier (e.g., because the appended tag-related domain is an e-mail domain) configured to be stored, queried, and associated with user accounts in the same way as any other provided e-mail address. However, when the registration logic 210 shares the registration information with the transfer service computing system 130, the transfer service computing system 130 is configured to recognize the tag-related domain and automatically associate the user, account, and/or the corresponding computing system with both the created tag-based identifier and the corresponding transfer tag.


As such, sender and/or recipient computing systems 110, 120 configured as hybrid systems are configured to allow for users (i.e., senders and/or recipients associated with sender devices 150 and/or recipient device 180) to be unaware that the use of transfer tags has not been fully implemented. For example, the registration logic 210 of the hybrid system (i.e., sender and/or recipient computing systems 110, 120 configured as hybrid systems) is configured to provide registration user interfaces to the user that are substantially similar to registration user interfaces provided by the registration logic 210 of native systems (i.e., sender and/or recipient computing systems 110, 120 configured as native systems). That is, the registration user interfaces (e.g., the registration interface 600 shown in FIG. 6) generated and provided by the native and hybrid systems (i.e., sender and/or recipient computing systems 110, 120 configured as native and/or hybrid systems) are each configured to receive transfer tags from users. Accordingly, even though the registration logic 210 of the hybrid systems (i.e., sender and/or recipient computing systems 110, 120 configured as hybrid systems) is not configured to directly associate the transfer tag with the user and/or user's account as a separate type of identifier, the users of the hybrid system may not need to know about and purposefully use tag-based domains (e.g., e-mail addresses) to register their accounts with transfer tags within the system 100.


Accordingly, the hybrid systems (i.e., sender and/or recipient computing systems 110, 120 configured as hybrid systems) provide a variety of benefits and technical advantages. For example, by eliminating the need for the user to manually append the tag-related domain, the hybrid system reduces the likelihood of entry errors, thereby improving the reliability of successful transfers. Further, by converting the transfer tag to a tag-based identifier that the hybrid systems (i.e., sender and/or recipient computing systems 110, 120 configured as hybrid systems) are already configured to process (e.g., a tag-based e-mail address), the converted tag-based identifier may be utilized without fully implementing the use of transfer tags, thereby reducing associated computational requirements imposed on the sender and/or recipient computing systems 110, 120 configured as hybrid systems (as compared to being configured as native systems), while still allowing the users to register their accounts with transfer tags and to transfer funds to recipients using transfer tags.


In some instances, prior to associating the new identifier(s) with the user and/or user's account, the identifier management logic 200 is configured to first verify the identifier(s) provided by the user. Verification refers to analyzing the identifier to confirm the availability of the identifier with the transfer service so that multiple of the same identifier are not used, which may create confusion and incorrect transfers. For example, the identifier verification logic 220 is configured to verify that the identifier(s) provided by the user are acceptable (i.e., meet one or more predefined format requirements) and have not already been registered by another user and/or for another account. As an example, when a user enters a transfer tag, the identifier verification logic 220 may determine that the transfer tag is acceptable (e.g., satisfies known conventions for number and types of alphanumeric and/or symbolic characters and does not include offensive language) and is unique (e.g., by cross-referencing a directory of transfer tags). For example, the identifier verification logic 220 is configured to cross-reference the corresponding account and user database 118, 128 and/or communicate with the transfer service computing system 130 to determine whether the provided identifier(s) have already been registered and associated with any other users, user accounts, and/or sender or recipient computing systems 110, 120 within the system 100.


In some instances, when a user attempts to register a new identifier, the identifier verification logic 220 is configured to perform an authentication operation such as sending the user a text, an e-mail at a newly-provided e-mail address, or, in the case of a transfer tag, an e-mail or text to a previously-registered identifier associated with the user's account. The text and/or e-mail may, for example, contain a link that must be accessed by the user in order to successfully complete the registration process. Accordingly, the registration logic 210 and the identifier verification logic 220 are configured to cooperate to facilitate the registration of certain identifiers.


The request processing logic 230 is configured to facilitate the creation, acceptance, and/or processing of real-time or nearly real-time transfer requests. For example, the request processing logic 230 is configured to generate pages or screens (e.g., user interfaces 1100, 1200 shown in FIGS. 11 and 12) for presentation to the user at the website or client application to facilitate the creation and/or acceptance of various fund transfer requests.


In some instances, the request processing logic 230 is configured to generate a fund transfer request based on one or more inputs provided by a user. For example, the request processing logic 230 is configured to receive a recipient identifier, a desired fund amount, and an indication of whether the user is requesting or sending money. The request processing logic 230 is then configured to generate and send the fund transfer request over the network, which may include the dynamically received information from the sender of, for example, the recipient identifier, the desired fund amount, and the indication of that the user is sending money (or, requesting money in another embodiment), to the transfer service computing system 130 to be routed to the recipient based on the recipient identifier. In some embodiments, the fund transfer request is configured as a payload data packet that includes information regarding the transfer. In other embodiment, the fund transfer request is configured as multiple payload packets thereby adding security to the process such that interception of one packet may be insufficient to effectuate a transfer without the other payload packets. Similar to the registration logic 210, the request processing logic 230 is configured to accept and/or process differing types of recipient identifiers received from the user based on the level of implementation of the transfer service within the corresponding system (e.g., the sender or recipient computing system 110, 120).


For example, if the sender computing system 110 is a native system, the request processing logic 230 is configured to receive a phone number, an e-mail address, and/or a transfer tag of the intended recipient from the user via a generated user interface provided to the sender device 150 by the client application 160 during a native fund transfer process. The request processing logic 230 of the native system is then configured to generate and transmit a fund transfer request to the transfer service computing system 130 to be routed to the appropriate recipient computing device and/or recipient user device based on the recipient identifier(s) provided by the user.


Alternatively, if the sender computing system 110 is configured as a non-native system, the request processing logic 230 is only configured to receive a phone number and/or an e-mail address of the intended recipient (i.e., not a transfer tag) via the generated user interface provided to the sender device 150 by the client application 160 during a non-native fund transfer process. Accordingly, if the recipient has a registered phone number and/or e-mail address, the user may provide the phone number and/or the e-mail address, as discussed above with respect to the native system. However, if the user desires to send a fund transfer request to a recipient having a registered transfer tag for fund transfers, the user may provide the tag-based identifier corresponding to the recipient's transfer tag into the generated user interface during the non-native fund transfer process.


When the user provides the corresponding tag-based identifier of the recipient and the request processing logic 230 sends the fund transfer request to the transfer service computing system 130, the transfer service computing system 130 is configured to recognize the tag-related domain and identify the recipient within the identifier database 134 based on either the tag-based identifier or the corresponding transfer tag. Accordingly, even though the non-native system has not fully implemented the use of transfer tags, the user is still allowed to send fund transfer requests to recipients based on their transfer tags by providing the corresponding tag-based identifier (e.g., the tag-based e-mail address). It will be appreciated that the use of the tag-based identifier and the capability of the transfer service computing system 130 to recognize and identify tags and tag-based identifiers interchangeably allows for funds transfers between systems having varying levels of implementation of the transfer service.


On the other hand, if the sender or recipient computing system 110, 120 is a hybrid system, the request processing logic 230 is configured to receive a phone number, an e-mail address, and/or a transfer tag of the intended recipient from the user via a generated user interface provided to the sender device 150 by the client application 160 during a hybrid fund transfer process. If the user enters a phone number or an e-mail address, the request processing logic 230 creates and sends the fund transfer request as discussed above, with respect to the native and non-native systems. However, similar to the registration logic 210, if the user enters a transfer tag, the request processing logic 230 is configured to automatically perform a tag conversion process to create a corresponding tag-based identifier (e.g., tag-based e-mail address) by automatically appending the tag-related domain to the received transfer tag prior to creating the fund transfer request. The request processing logic 230 then creates the fund transfer request using the created tag-based identifier (e.g., tag-based e-mail address) in a similar manner as if the identifier provided was a recipient e-mail address. Accordingly, the transfer service computing system 130 is similarly configured to recognize the tag-related domain and identify the recipient within the identifier database 134 based on either the tag-based identifier or the corresponding transfer tag. Accordingly, even though the request processing logic 230 is embodied in a hybrid computing system that is not configured to create and send fund transfer requests directly utilizing transfer tags of intended recipients, the users of the hybrid system do not need to know about and purposefully use the tag-based identifiers to create and send fund transfer requests to intended recipients based on the intended recipients' transfer tags within the system 100.


Referring now to FIGS. 3, 4, and 5, example methods for registering a transfer tag for fund transfers with system 100 via native systems (a native registration process 300), non-native systems (a non-native registration process 400), and hybrid, non-native systems (a hybrid, non-native registration process 500) are shown. It should be appreciated that the various method steps shown and described are provided as an example, and, in some instances, various additional steps may be performed and/or some of the described steps may be omitted, without departing from the scope of the present disclosure. Additionally, it should be appreciated that the following methods specifically refer to a tag-based identifier in the form of a tag-based e-mail address including a tag-related e-mail domain. However, it should be appreciated that various other types of tag-based identifiers may be implemented including various other types of tag-related domains.


Further, it should be appreciated that, in some instances, prior to the following registration processes, the client application 160, 190 generates a sign-in screen and receives a credential of the user (e.g., username, password, biometric, a combination thereof, etc.). The client application 160, 190 then authenticates the credential to allow access other features of the client application 160, 190. After the user is signed in, the client application 160, 190 presents the user with a graphical user interface including a main menu of the client application 160, 190. From the main menu, the user may select an option to begin the registration process via the graphical user interface. In some instances, the client application 160, 190 is configured to identify and provide a plurality of accounts stored within the account and user database 118, 128 of the sender/recipient computing system 110, 120 that are associated with the user based on the received credential of the user. The client application 160, 190 is then configured to allow the user to select one or more of the provided accounts associated with the user that they would like to register using the registration processes discussed below.


Referring first to FIG. 3, a native registration process 300 of a user registering their account with a transfer tag via a sender/recipient computing system 110, 120 configured as a native computing system is shown, according to an example embodiment. At process 305, the registration logic 210 receives a transfer service registration request including the transfer tag. For example, the user may enter a desired tag into a user interface (e.g., registration interface 600 shown in FIG. 6) generated by the sender/recipient device 150, 180, the sender/recipient computing system 110, 120, or the transfer service computing system 130 and provided to the sender/recipient device 150/180. The registration logic 210 then checks the availability of the transfer tag at process 310. That is, the identifier verification logic 220 is configured to cross-reference the corresponding account and user database 118, 128 and/or communicate with the transfer service computing system 130 to determine whether the desired tag has already been registered and associated with any other users, user accounts, and/or sender or recipient computing systems 110, 120 within the system 100.


If the desired tag is available, the registration logic 210 may provide an indication to the user via one or more graphical user interfaces (e.g., “Congrats—you have now obtained this tag!”). The registration logic 210 then registers the transfer tag with the user's account and stores an association between the transfer tag and the user's account within the corresponding account and user database 118, 128, at process 315. The registration logic 210 then communicates various registration information with the transfer service computing system 130, at process 320. For example, the registration logic 210 may provide an indication to the transfer service computing system 130 specifying the transfer tag and indicating various associated identifying information. In some instances, the identifying information includes the user's name, the user's contact information, the user's account information, and/or an identifier associated with the computing system of the corresponding member entity that the user is associated with. In some instances, the identifying information only includes the identifier associated with the computing system of the corresponding member entity that the user is associated with, such that no personal information pertaining to the user is shared with the transfer service computing system 130.


In any case, the transfer service computing system 130 is configured to store the registration information within the identifier database 134 to be used in further fund transfer request routing processes. Additionally, the transfer service computing system 130 is configured to recognize a transfer tag is included within the registration information and automatically associate both the transfer tag and the corresponding tag-related identifier (e.g., the tag-related e-mail address) with the provided identifying information within the identifier database 134. For example, in some instances, upon receiving registration information including an e-mail address identifier, the transfer service computing system 130 is configured to identify and compare an e-mail domain name (e.g., “@gmail.com,” “@yahoo.com,” “@fundtag.com”) to the tag-related e-mail domain (e.g., “@fundtag.com”) to determine whether the received e-mail address contains the tag-related e-mail domain. Accordingly, by comparing the e-mail domain name with the tag-related e-mail domain, the transfer service computing system 130 is configured to recognize (e.g., determine) that the received e-mail address contains the tag-related e-mail domain.


Referring now to FIG. 4, a non-native registration process 400 of a user registering their account with a transfer tag via a sender/recipient computing system 110, 120 configured as a non-native system is shown, according to an example embodiment. At process 405, using the sender/recipient computing system 110, 120 configured as a non-native system, when a user wants to register their account with a transfer tag, the user provides, and the registration logic 210 receives, a transfer service registration request including a corresponding tag-based identifier (e.g., a tag-based e-mail address) from the user. That is, the user provides the corresponding tag-based identifier associated with their desired tag (e.g., by appending the tag-related domain) by entering the tag-based identifier into a user interface (e.g., registration interface 700 shown in FIG. 7) provided to the sender device 150 (or the recipient device 180). For example, if the desired tag of the user is “John128” and the tag-related domain is “@fundtag.com,” the corresponding tag-based e-mail address would be “John128@fundtag.com”. The registration logic 210 may then check the availability of the tag-based identifier, at process 410. That is, the identifier verification logic 220 may cross-reference the corresponding account and user database 118, 128 and communicate with the transfer service computing system 130 to determine whether the tag-based identifier (and thus the desired tag) has already been registered and associated with any other users, user accounts, and/or sender or recipient computing systems 110, 120 within the system 100.


In some instances, if the desired tag (and/or corresponding tag-based identifier) is available, the client application 160, 190 is configured to generate and provide a confirmation screen to the user via the sender/recipient device 150, 180 including an indication that the desired transfer tag (and/or corresponding tag-based identifier) is available within the system 100. In some instances, the confirmation screen further includes a selectable accept option button and a selectable reject or cancel option button configured to allow the user to input a selection to accept or reject the desired tag and/or corresponding tag-based identifier.


In some instances, the confirmation screen is configured by the client application 160, 190 with a time-out period, within which the user must accept or reject the desired tag and/or tag-based identifier. That is, within the time-out period, the system 100 (e.g., the sender computing system 110, the recipient computing system 120, the transfer service computing system 130) is configured to temporarily treat or hold the desired tag and/or tag-based identifier in a “claimed” state, such that the desired tag and/or tag-based identifier is temporarily made unavailable to other users of the system 100 for registration with other accounts. For example, the sender/recipient computing systems 110, 120 and the transfer service computing system 130 may create temporary entries within each of the account and user databases 118, 128 and the identifier database 134 temporarily associating an account of the user with the desired tag and/or tag-based identifier. Upon expiration of the time-out period, the system 100 is configured to return the desired tag and/or tag-based identifier to an “available” state, such that the desired tag and/or tag-based identifier is again made available to other users of the system 100 for registration with other accounts. For example, upon expiration of the time-out period, the sender/recipient computing systems 110, 120 and the transfer service computing system 130 are configured to erase the temporary entries from within each of the account and user databases 118, 128 and the identifier database 134.


Upon acceptance by the user, the registration logic 210 is then configured to register the tag-based identifier with the user's account and store an association between the tag-based identifier and the user's account within the corresponding account and user database 118, 128, at process 415. The registration logic 210 may then similarly communicate various registration information with the transfer service computing system 130, at process 420. For example, the registration logic 210 may provide an indication to the transfer service computing system 130 specifying the tag-based identifier and indicating the various associated identifying information discussed above. However, the transfer service computing system 130 may recognize the tag-related domain within the tag-based identifier, and automatically associate both the tag-based identifier address and the transfer tag with the provided identifying information within the identifier database 134. Accordingly, even though the system of the member entity that the user's account is held at is not a native system, the user is still able to register their account with a desired tag within transfer service provided by the transfer service computing system 130.


Referring now to FIG. 5, a hybrid, non-native registration process 500 of a user registering their account with a transfer tag via a sender/recipient computing system 110, 120 configured as a hybrid system is shown, according to an example embodiment. As depicted, similar to the sender/recipient computing systems configured as native systems, the registration logic 210 of the sender/recipient computing systems 110, 120 configured as hybrid systems is configured to receive a transfer service registration request including a desired tag directly from the user, at process 505. That is, the user may directly provide their desired tag into a user interface (e.g., registration interface 600 shown in FIG. 6) provided to the sender device 150 (or the recipient device 180) by the client application 160, 190.


However, after receiving the desired tag, the registration logic 210 is then configured to automatically perform the tag conversion process discussed above at process 510. That is, the registration logic 210 is configured to automatically append the tag-related domain to the end of the desired tag entered by the user to create the corresponding tag-related identifier (e.g., tag-based e-mail address). For example, if the user enters the desired tag “John128” and the tag-related domain is “@fundtag.com,” the registration logic 210 is configured to append or otherwise add the tag-related domain to the end of the desired tag to create the corresponding tag-related identifier “John128@fundtag.com”.


In some instances, the registration logic 210 is configured to retrievably store the tag-related domain within the account and user database 118, 128 (or another database within the sender/recipient computing system 110, 120). Accordingly, when performing the tag conversion process discussed above, the registration logic 210 is configured to retrieve the tag-related domain from the account and user database 118, 128 and to append the tag-related domain to the received desired tag. In some other instances, the tag-related domain may be stored locally within a local memory of the sender/recipient device 150, 180. In these instances, the client application 160, 190 is configured to perform the tag conversion process on the sender/recipient device 150, 180 by querying the local memory for the stored tag-related domain and appending the tag-related domain to the desired tag. In these instances, the client application 160, 190 is configured to provide or otherwise transmit the created tag-based identifier from the sender/recipient device 150/180 to the registration logic 210 of the corresponding sender/recipient computing system 110, 120. In some instances, the stored tag-related domain within the local memory of the sender/recipient device 150, 180 may be periodically updated by the transfer service computing system 130 to accommodate changing tag-based domains over time, which may be updated within the transfer service computing system 130 for a variety of reasons.


In any case, once the created tag-based identifier has been created, the registration logic 210 then similarly checks the availability of the tag-based identifier, at process 515, by cross-referencing the corresponding account and user database 118, 128 and communicating with the transfer service computing system 130. In some instances, the registration logic 210 (or the client application 160, 190) performing the tag conversion process creates a uniform identifier type that is capable of being utilized across all systems (i.e., sender/recipient computing systems 110, 120 and transfer service computing system 130). Accordingly, in some instances, the sender/recipient computing systems 110, 120 and the transfer service computing system 130 are collectively configured to perform necessary queries (e.g., for identifier users, user accounts, available identifiers) utilizing a uniform type of identifier (e.g., an e-mail based identifier), thereby reducing processing times of the queries performed by the sender/recipient computing systems 110, 120 and/or the transfer service computing system 130.


If the desired tag is available, the registration logic 210 then similarly registers the tag-based identifier with the user's account and stores an association between the tag-based identifier and the user's account within the corresponding account and user database 118, 128, at process 520, and communicates the various registration information with the transfer service computing system 130, at process 525. Again, the transfer service computing system 130 similarly recognizes the tag-related domain within the tag-based e-mail address, and automatically associates both the tag-related identifier and the transfer tag with the provided identifying information within the identifier database 134.


Accordingly, the systems and methods described herein allow for users of native, non-native, and hybrid systems to each effectively register their accounts with desired tags, regardless of the level of implementation of the transfer service within the computing systems of their respective member entities.


Referring now to FIGS. 6 and 7, examples of potential graphical user interfaces which may be presented by a client application (e.g., a banking application, a standalone application of a payment platform such as “Zelle®,” or an internet web browser) during a registration process are shown. These are representative, non-limited example interfaces, and do not necessarily include all potential functionality of various embodiments. Similarly, not all the functionality depicted is necessarily required in all embodiments.



FIG. 6 shows a registration interface 600 that may be provided to a user of a sender/recipient computing system 110, 120 configured as a native or a hybrid computing system, according to an example embodiment. For example, in some instances, the registration interface 600 is generated by the corresponding sender/recipient computing system 110, 120 or the transfer service computing system 130 and provided to the sender/recipient device 150, 180 via the corresponding client application 160, 190. As illustrated, the registration interface 600 allows for the user to register their account by providing various identifiers. Specifically, the registration interface 600 includes a phone number field 605, an e-mail address field 610, and a desired tag field 615. Accordingly, the user may enter one or more of a phone number, an e-mail address, and/or a desired tag and select a submit button 620. The entered identifier is then transmitted to the corresponding sender/recipient computing system 110, 120 and/or the transfer service computing system 130 to be searched or queried, as discussed above, and an indication 625 is provided as to whether the entered identifier is or is not available for use. The user may select a next button 650 to proceed or a cancel button 655 to cancel registration of their account.


In some instances, if the sender is a user associated with a hybrid computing system and the entered identifier is a desired transfer tag, the client application 160, 190 is configured to perform the tag conversion process locally on the sender/recipient device 180, prior to transmitting the desired transfer tag to the corresponding sender/recipient computing system 110, 120 and/or the transfer service computing system 130. In some other instances, the client application 160, 190 is alternatively configured to send the desired transfer tag to the corresponding sender/recipient computing system 110, 120 without performing the tag conversion process. In these instances, the sender/recipient computing system 110, 120 is configured to perform the tag conversion process to create the corresponding tag-based identifier to be searched and queried, as discussed above.



FIG. 7 shows a registration interface 700 that may be provided to a user of sender/recipient computing system 110, 120 configured as a non-native computing system, according to an example embodiment. For example, in some instances, the registration interface 700 is similarly generated by the corresponding sender/recipient computing system 110, 120 or the transfer service computing system 130 and provided to the sender/recipient device 150, 180 via the corresponding client application 160, 190. As illustrated, the registration interface 700 similarly allows for the user to register their account by provided various identifiers. However, the registration interface 700 only includes a phone number field 605 and an e-mail address field 610. Accordingly, the user may enter one or more of a phone number or an e-mail address (e.g., a pre-existing e-mail address or a tag-based e-mail address corresponding to a desired tag), and select a submit button 720. The entered identifier may then be searched, as discussed above, and an indication 725 may be provided as to whether the entered identifier is or is not available for use. The user may then similarly select a next button 750 to proceed or a cancel button 755 to cancel registration of their account.


Referring now to FIGS. 8, 9, and 10, example methods for enabling real-time or nearly real-time transfers using transfer tags with the system 100 via native systems (native fund transfer process 800), non-native systems (non-native fund transfer process 900), and hybrid systems (hybrid fund transfer process 1000) are shown. It should be appreciated that the various method steps or processes shown and described are provided as an example, and, in some instances, various additional steps or processes may be performed and/or some of the described steps or processes may be omitted, without departing from the scope of the present disclosure.


It should be appreciated that, in some instances, prior to the following fund transfer request processes, the user is required to sign into the corresponding client application 160, 190 on the sender/recipient device 150, 180. Upon signing in, the user is presented with a graphical user interface providing a main menu of the client application 160, 190. From the main menu, the user may select an option to begin a fund transfer process via the graphical user interface.


For example, FIG. 8 shows a native fund transfer request process 800 of a user creating a fund transfer request based on a transfer tag of a request recipient (e.g., a requested sender or recipient of funds to be transferred) via a sender/recipient computing system 110, 120 configured as a native system, according to an example embodiment. As depicted, the request processing logic 230 receives the transfer tag from the sender device 150 (or the recipient device 180), at process 805. For example, the user may enter a transfer tag into a user interface (e.g., fund transfer interface 1100 shown in FIG. 11) provided to the sender device 150 (or the recipient device 180). The request processing logic 230 then generates a fund transfer request based on the transfer tag, at process 810. As discussed above, the fund transfer request may include the transfer tag, the desired fund amount, and the indication of whether the user is requesting or sending money.


The request processing logic 230 then sends the fund transfer request to the transfer service computing system 130, at process 815, which then routes the fund transfer request to the request recipient based on the transfer tag, at process 820. It should be appreciated that, even if the request recipient has an account maintained by a non-native or hybrid system (i.e., a sender/recipient computing system 110, 120 configured as a non-native or hybrid computing system), the transfer service computing system 130 is configured to recognize that the fund transfer request includes a transfer tag, and thus identify and route the fund transfer request to the request recipient based on the corresponding tag-based identifier (e.g., tag-based e-mail address) associated with the request recipient.



FIG. 9 shows a non-native fund transfer request process 900 of a user creating a fund transfer request based on a transfer tag of a request recipient via a sender/recipient computing system 110, 120 configured as a non-native system, according to an example embodiment. As depicted, the request processing logic 230 receives a recipient tag-based e-mail address, at process 905. For example, the user may append the tag-related domain to the desired recipient's transfer tag to create the tag-based identifier (e.g., tag-based e-mail address), and may enter the created tag-based identifier into a user interface (e.g., fund transfer interface 1200 shown in FIG. 12) provided to the sender device 150 (or the recipient device 180). The request processing logic 230 then generates a fund transfer request based on the tag-based identifier, at process 910. As discussed above, the fund transfer request may include the tag-based identifier, the desired fund amount, and the indication of whether the user is requesting or sending money.


The request processing logic 230 then sends the fund transfer request to the transfer service computing system 130, at process 915, which then routes the fund transfer request to the request recipient based on the tag-based identifier, at process 920. It should be appreciated that, even if the request recipient is a user of a native system, the transfer service computing system 130 (e.g., the identifier processing logic 132) is configured to recognize that the fund transfer request includes a tag-based identifier based on the tag-related domain, and thus identify and route the fund transfer request to the request recipient based on the corresponding transfer tag associated with the request recipient. For example, in some instances, upon receiving a funds transfer request including an e-mail address identifier, the transfer service computing system 130 (e.g., the identifier processing logic 132) is configured to identify and compare an e-mail domain name (e.g., “@gmail.com,” “@yahoo.com,” “@fundtag.com”) to the tag-related e-mail domain (e.g., “@fundtag.com”) to determine whether the received e-mail address contains the tag-related e-mail domain. Accordingly, by comparing the e-mail domain name with the tag-related e-mail domain, the transfer service computing system 130 (e.g., the identifier processing logic 132) is configured to recognize (e.g., determine) that the received e-mail address contains the tag-related e-mail domain. In some instances, the tag-related e-mail domain (e.g., “@fundtag.com”) is stored within the identifier database 134 and accessible by the identifier processing logic 132 to be retrieved and compared to the e-mail domain name of the e-mail address within the fund transfer request.



FIG. 10 shows a hybrid fund transfer request process 1000 of a user creating a fund transfer request based on a transfer tag of a request recipient via a sender/recipient computing system 110, 120 configured as a hybrid computing system, according to an example embodiment. As depicted, the request processing logic 230 receives a transfer tag of the request recipient, at process 1005. For example, the user may similarly enter the transfer tag into a user interface (e.g., fund transfer interface 1100 shown in FIG. 11) provided to the sender device 150 (or the recipient device 180). In some instances, the request processing logic 230 then automatically performs the tag conversion process, at process 1010, by appending the tag-related domain to the end of the transfer tag to create the corresponding tag-based identifier (e.g., tag-based e-mail address). In some other instances, the client application 160, 190 operating on the sender/recipient device 150, 180 performs the tag conversion process prior to sending the tag-based identifier to the sender/recipient computing system 110, 120. The request processing logic 230 then generates a fund transfer request based on the created tag-based identifier, at process 1015. As discussed above, the fund transfer request may similarly include the tag-based identifier, the desired fund amount, and the indication of whether the user is requesting or sending money.


The request processing logic 230 then sends the fund transfer request to the transfer service computing system 130, at process 1020, which then routes the fund transfer request to the requested recipient based on the tag-based e-mail address, at process 1025. It should again be appreciated that, even if the request recipient is a user of a native system, the transfer service computing system 130 is configured to recognize that the fund transfer request includes a tag-based identifier based on the tag-related domain, and thus identify and route the fund transfer request to the request recipient based on the corresponding transfer tag associated with the request recipient.


Referring now to FIGS. 11 and 12, examples of potential graphical user interfaces which may be presented by a client application (e.g., a banking application, a standalone application of a payment platform, which may be a P2P platform such as “Zelle®,” or an internet web browser) during a fund transfer request process are shown. These are representative, non-limited example interfaces, and do not necessarily include all potential functionality of various embodiments. Similarly, not all the functionality depicted is necessarily required in all embodiments.



FIG. 11 shows a fund transfer interface 1100 that may be provided to a user of a sender/recipient computing system 110, 120 configured as a native or a hybrid computing system, according to an example embodiment. For example, in some instances, the fund transfer interface 1100 is generated by the corresponding sender/recipient computing system 110, 120 or the transfer service computing system 130 and provided to the sender/recipient device 150, 180 via the corresponding client application 160, 190. As illustrated, the fund transfer interface 1100 allows for the user to create a fund transfer request based on various identifiers. Specifically, the fund transfer interface 1100 includes a phone number field 1105, an e-mail address field 1110, and a transfer tag field 1115. The fund transfer interface 1100 further includes a fund transfer amount field 1120. Accordingly, the user may enter one or more of a phone number, an e-mail address, and/or a transfer tag associated with the intended recipient, as well as the intended fund transfer amount, and may then select either a send button 1125 or a request button 1130 to create the fund transfer request. The user may alternatively select a cancel button 1155 to cancel the fund transfer request.



FIG. 12 shows a fund transfer interface 1200 that may be provided to a user of a sender/recipient computing system 110, 120 configured as a non-native computing system, according to an example embodiment. For example, in some instances, the fund transfer interface 1200 is similarly generated by the corresponding sender/recipient computing system 110, 120 or the transfer service computing system 130 and provided to the sender/recipient device 150, 180 via the corresponding client application 160, 190. As illustrated, the fund transfer interface 1200 similarly allows for the user to create a fund transfer request based on various identifiers. However, the fund transfer interface 1200 only includes a phone number field 1205 and an e-mail address field 1210 (i.e., no transfer tag field). The fund transfer interface 1200 further includes a fund transfer amount field 1215. Accordingly, the user may enter one or more of a phone number or an e-mail address (e.g., a pre-existing e-mail address or a tag-based e-mail address corresponding to a transfer tag), as well as the intended fund transfer amount, and may then select either a send button 1220 or a request button 1225 to create the fund transfer request. The user may alternatively select a cancel button 1255 to cancel the fund transfer request.


It should be appreciated that, in some instances, one or more sender computing systems 110 have a different level(s) of implementation of the transfer service as compared to one or more recipient computing systems 120. That is, in some instances, one or more sender computing systems 110 are configured as native systems and one or more recipient computing systems 120 are configured as non-native or hybrid systems, and/or vice versa. As described herein, the use of the tag-based identifiers within the sender and/or recipient computing systems 110, 120, in combination with the ability of the transfer service computing system 130 (e.g., the identifier processing logic 132) to recognize both tag-based identifiers and the corresponding transfer tags interchangeably, allows for senders and recipients of the sender and/or recipient computing systems 110, 120 to register their accounts with and send fund transfer requests based on transfer tags and/or the corresponding tag-based identifiers regardless of the differing levels of implementation of the transfer service across the various sender and recipient computing systems 110, 120 within the system 100.


The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that provide the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.


It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”


As used herein, the term “logic” may include hardware and machine-readable media storing instructions thereon for configuring the hardware to execute the functions described herein. The logic may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, logic may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of circuit. In this regard, the “logic” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, logic as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).


Thus and based on the forgoing, the “logic” may be embodied as one or more processing circuits comprising one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple “logics” (e.g., logic A and logic B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory).


Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be provided as one or more suitable processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given “logic” or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, “logic” as described herein may include components that are distributed across one or more locations.


An example system for providing the overall system or portions of the embodiments might include one or more 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. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, 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. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.


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 disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure may 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 has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the 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 disclosure as expressed in the appended claims.

Claims
  • 1. A computer-implemented method, comprising: receiving, by a provider computing system, a transfer tag associated with a recipient from a user device associated with a sender;performing, by the provider computing system, a tag conversion process on the transfer tag to create a tag-based identifier corresponding to the transfer tag;generating, by the provider computing system, a transfer request including the tag-based identifier; andsending, by the provider computing system, the transfer request to a transfer service computing system, the transfer request initiating a transfer of a resource to a recipient account of the recipient based on the tag-based identifier.
  • 2. The computer-implemented method of claim 1, wherein the tag-based identifier includes a tag-related domain that enables identification of the recipient account based on the transfer tag.
  • 3. The computer-implemented method of claim 2, wherein performing the tag conversion process comprises automatically appending the tag-related domain to the transfer tag to create the tag-based identifier.
  • 4. The computer-implemented method of claim 2, further comprising: transmitting, by the provider computing system, a request for a current tag-related domain from the transfer service computing system; andreceiving, by the provider computing system, the current tag-related domain from the transfer service computing system,wherein the tag-related domain included in the tag-based identifier is the current tag-related domain.
  • 5. The computer-implemented method of claim 2, wherein the tag-based identifier is an e-mail address and the tag-related domain is an e-mail domain.
  • 6. The computer-implemented method of claim 1, further comprising: receiving, by the provider computing system, a desired transfer tag from the user device;performing, by the provider computing system, the tag conversion process on the desired transfer tag to create a desired-tag-based identifier corresponding to the desired transfer tag; andregistering, by the provider computing system, a sender account of the sender for a transfer service provided by the transfer service computing system using the desired-tag-based identifier.
  • 7. The computer-implemented method of claim 6, wherein the desired-tag-based identifier enables identification of the sender account based on the desired transfer tag.
  • 8. The computer-implemented method of claim 7, wherein registering the sender account with the desired-tag-based identifier creates an association between the sender account and both of the desired transfer tag and the desired-tag-based identifier.
  • 9. A provider computing system comprising: one or more processing circuits including one or more processors and one or more memories having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to: receive a transfer tag associated with a recipient from a user device associated with a sender;perform a tag conversion process on the transfer tag to create a tag-based identifier corresponding to the transfer tag;generate a transfer request including the tag-based identifier; andsend the transfer request to a transfer service computing system, the transfer request initiating a transfer of a resource to a recipient account of the recipient based on the tag-based identifier.
  • 10. The provider computing system of claim 9, wherein the tag-based identifier includes a tag-related domain that enables identification of the recipient account based on the transfer tag.
  • 11. The provider computing system of claim 10, wherein performing the tag conversion process comprises automatically appending the tag-related domain to the transfer tag to create the tag-based identifier.
  • 12. The provider computing system of claim 10, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: transmit a request for a current tag-related domain from the transfer service computing system; andreceive the current tag-related domain from the transfer service computing system,wherein the tag-related domain included in the tag-based identifier is the current tag-related domain.
  • 13. The provider computing system of claim 10, wherein the tag-based identifier is an e-mail address and the tag-related domain is an e-mail domain.
  • 14. The provider computing system of claim 9, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: receive a desired transfer tag from the user device;perform the tag conversion process on the desired transfer tag to create a desired-tag-based identifier corresponding to the desired transfer tag; andregister a sender account of the sender for a transfer service provided by the transfer service computing system using the desired-tag-based identifier.
CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63/270,718, titled “SYSTEMS AND METHODS FOR NATIVE, NON-NATIVE, AND HYBRID REGISTRATION AND USE OF TAGS FOR REAL-TIME SERVICES,” filed Oct. 22, 2021, which is incorporated herein by reference in its entirety.

US Referenced Citations (565)
Number Name Date Kind
5412192 Hoss May 1995 A
5778067 Jones et al. Jul 1998 A
5953710 Fleming Sep 1999 A
6016484 Williams et al. Jan 2000 A
6353811 Weissman Mar 2002 B1
6615194 Deutsch et al. Sep 2003 B1
6865547 Brake et al. Mar 2005 B1
6873974 Schutzer Mar 2005 B1
6993510 Guy et al. Jan 2006 B2
7086586 Sullivan Aug 2006 B1
7287695 Wankmueller Oct 2007 B2
7395243 Zielke et al. Jul 2008 B1
7398919 Cooper Jul 2008 B2
7400883 Rivers et al. Jul 2008 B2
7631803 Peyret et al. Dec 2009 B2
7757944 Cline et al. Jul 2010 B2
7774274 Jones et al. Aug 2010 B2
7822206 Birk et al. Oct 2010 B2
7827057 Walker et al. Nov 2010 B1
7860790 Monk Dec 2010 B2
7909243 Merkow et al. Mar 2011 B2
7925285 Indirabhai Apr 2011 B2
7930225 Wahlberg et al. Apr 2011 B2
7945776 Atzmony et al. May 2011 B1
7958049 Jamison et al. Jun 2011 B2
7970669 Santos Jun 2011 B1
8019365 Fisher Sep 2011 B2
8078140 Baker et al. Dec 2011 B2
8126806 DiMartino et al. Feb 2012 B1
8160959 Rackley et al. Apr 2012 B2
8215560 Granucci et al. Jul 2012 B2
8280788 Perlman Oct 2012 B2
8401904 Simakov et al. Mar 2013 B1
8433657 Dinan Apr 2013 B2
8452257 Granucci et al. May 2013 B2
8467766 Rackley et al. Jun 2013 B2
8468587 Blinn et al. Jun 2013 B2
8489067 Rackley, III et al. Jul 2013 B2
8504699 Vaughan et al. Aug 2013 B2
8533123 Hart Sep 2013 B2
8538845 Liberty Sep 2013 B2
8548908 Friedman Oct 2013 B2
8555361 Nakhjiri et al. Oct 2013 B2
8566237 Forzley Oct 2013 B2
8566239 Arthur et al. Oct 2013 B2
8571953 Gopalakrishnan et al. Oct 2013 B2
8589290 Baskerville Nov 2013 B2
8615468 Varadarajan Dec 2013 B2
8626632 Dolan et al. Jan 2014 B1
8627424 O'Malley et al. Jan 2014 B1
8635131 Saunders Jan 2014 B1
8639621 Ellis et al. Jan 2014 B1
8645971 Carlson et al. Feb 2014 B2
8676704 Ledbetter et al. Mar 2014 B2
8682802 Kannanari Mar 2014 B1
8700729 Dua Apr 2014 B2
8706628 Phillips Apr 2014 B2
8725576 Fisher May 2014 B2
8725577 Fisher May 2014 B2
8732080 Karim May 2014 B2
8744966 Amacker et al. Jun 2014 B1
8750901 Gupta et al. Jun 2014 B1
8762265 Kessler et al. Jun 2014 B2
8762270 Evans et al. Jun 2014 B1
8768830 Jorgensen et al. Jul 2014 B1
8768834 Zacarias et al. Jul 2014 B2
8774781 Speiser et al. Jul 2014 B1
8781955 Schamer et al. Jul 2014 B2
8831677 Villa-Real Sep 2014 B2
8838501 Priebatsch Sep 2014 B1
8843125 Kwon et al. Sep 2014 B2
8843417 Hammad Sep 2014 B2
8880432 Collins, Jr. Nov 2014 B2
8924246 Chen et al. Dec 2014 B1
8925805 Grigg et al. Jan 2015 B2
8930271 Ellis et al. Jan 2015 B1
8972297 Kay et al. Mar 2015 B2
8977251 Grigg et al. Mar 2015 B2
8989712 Wentker et al. Mar 2015 B2
9020836 Fisher et al. Apr 2015 B2
9026460 Grigg et al. May 2015 B2
9027109 Wolberg-Stok et al. May 2015 B2
9031880 Bishop et al. May 2015 B2
9037509 Ellis et al. May 2015 B1
9043240 Langus et al. May 2015 B2
9043605 Machani May 2015 B1
9098190 Zhou et al. Aug 2015 B2
9111266 Kessler et al. Aug 2015 B2
9117242 Ellis et al. Aug 2015 B1
9177307 Ross et al. Nov 2015 B2
9208488 Liberty Dec 2015 B2
9208528 Chelst et al. Dec 2015 B2
9218624 Moghadam Dec 2015 B2
9256876 Vasant Akole et al. Feb 2016 B2
9286606 Diamond Mar 2016 B2
9324068 Soundararajan Apr 2016 B2
9361616 Zhou et al. Jun 2016 B2
9424572 Bondesen et al. Aug 2016 B2
9473491 Johansson et al. Oct 2016 B1
9652770 Kurani et al. May 2017 B1
9659312 Ellis et al. May 2017 B1
9691058 Epler et al. Jun 2017 B2
9704157 Ellis et al. Jul 2017 B1
9741051 Carpenter et al. Aug 2017 B2
9785934 Davis et al. Oct 2017 B2
9805363 Rudnick et al. Oct 2017 B1
9818109 Loh Nov 2017 B2
9928518 Vippagunta et al. Mar 2018 B1
9972047 Elliott et al. May 2018 B1
10019740 Simantov et al. Jul 2018 B2
10037561 Hecht et al. Jul 2018 B1
10115112 Fordyce, III Oct 2018 B2
10121129 Kalgi Nov 2018 B2
10223710 Purves et al. Mar 2019 B2
10235668 Ellis et al. Mar 2019 B1
10242368 Poole Mar 2019 B1
10380583 Ellis et al. Aug 2019 B1
10380596 Butler et al. Aug 2019 B1
10395247 Gilliam et al. Aug 2019 B2
10402897 Czyzewski et al. Sep 2019 B1
10445739 Sahni et al. Oct 2019 B1
10467615 Omojola et al. Nov 2019 B1
10515356 Cronic et al. Dec 2019 B2
10565558 Fredericks et al. Feb 2020 B2
10586236 Pourfallah et al. Mar 2020 B2
10600128 Graham et al. Mar 2020 B2
10817950 Iqbal et al. Oct 2020 B1
10853787 Mango Dec 2020 B1
10887301 Vera et al. Jan 2021 B1
10997592 Kurani May 2021 B1
11042882 Ledford et al. Jun 2021 B2
11068866 Hecht et al. Jul 2021 B1
11144902 Gaddam et al. Oct 2021 B2
11151546 Mossoba et al. Oct 2021 B2
11210715 Lindsey et al. Dec 2021 B2
11228660 Rapaka et al. Jan 2022 B2
11270293 Salama et al. Mar 2022 B2
11288660 Kurani Mar 2022 B1
11295294 Kurani et al. Apr 2022 B1
11334579 Quade et al. May 2022 B1
11416766 Chao et al. Aug 2022 B2
11422393 Stray et al. Aug 2022 B2
11436581 Walker et al. Sep 2022 B1
11551190 Clements et al. Jan 2023 B1
20020032602 Lanzillo et al. Mar 2002 A1
20020052852 Bozeman May 2002 A1
20020062249 Iannacci May 2002 A1
20020174016 Cuervo Nov 2002 A1
20020198829 Ludwig et al. Dec 2002 A1
20030028481 Flitcroft et al. Feb 2003 A1
20030040964 Lacek Feb 2003 A1
20030055785 Lahiri Mar 2003 A1
20030056096 Albert et al. Mar 2003 A1
20030172039 Guy et al. Sep 2003 A1
20040088349 Beck et al. May 2004 A1
20040230535 Binder et al. Nov 2004 A1
20040236632 Maritzen et al. Nov 2004 A1
20040254848 Golan et al. Dec 2004 A1
20040260646 Berardi et al. Dec 2004 A1
20050021401 Postrel Jan 2005 A1
20050021457 Johnson et al. Jan 2005 A1
20050043997 Sahota et al. Feb 2005 A1
20050077350 Courtion et al. Apr 2005 A1
20050086492 Nicodemus et al. Apr 2005 A1
20050125317 Winkelman et al. Jun 2005 A1
20050125668 Botz Jun 2005 A1
20050133590 Rettenmyer et al. Jun 2005 A1
20050138377 First et al. Jun 2005 A1
20050184145 Law et al. Aug 2005 A1
20050235363 Hibbard et al. Oct 2005 A1
20060129502 Pastusiak et al. Jun 2006 A1
20060229985 Lalwani et al. Oct 2006 A1
20060253335 Keena et al. Nov 2006 A1
20070125840 Law Jun 2007 A1
20070162369 Hardison Jul 2007 A1
20070168354 Ramer et al. Jul 2007 A1
20070170243 Desany et al. Jul 2007 A1
20070174166 Jones Jul 2007 A1
20070174873 Griggs Jul 2007 A1
20070198432 Pitroda Aug 2007 A1
20070244811 Tumminaro Oct 2007 A1
20070250923 M'Raihi Oct 2007 A1
20070262140 Long Nov 2007 A1
20080006685 Rackley, III et al. Jan 2008 A1
20080033878 Krikorian et al. Feb 2008 A1
20080127317 Nakhjiri May 2008 A1
20080203152 Hammad et al. Aug 2008 A1
20080208742 Arthur et al. Aug 2008 A1
20080242274 Swanburg et al. Oct 2008 A1
20080294556 Anderson Nov 2008 A1
20080319887 Pizzi et al. Dec 2008 A1
20090027191 Farah et al. Jan 2009 A1
20090043695 Hickey Feb 2009 A1
20090048971 Hathaway et al. Feb 2009 A1
20090063178 Pousti et al. Mar 2009 A1
20090076950 Chang et al. Mar 2009 A1
20090106558 Delgrosso et al. Apr 2009 A1
20090157531 Bui Jun 2009 A1
20090177563 Bernstein et al. Jul 2009 A1
20090192873 Marble Jul 2009 A1
20090271287 Halpern Oct 2009 A1
20090281941 Worth Nov 2009 A1
20090281951 Shakkarwar Nov 2009 A1
20090319409 Omidyar Dec 2009 A1
20090319427 Gardner et al. Dec 2009 A1
20090327010 Vadhri Dec 2009 A1
20090327151 Carlson et al. Dec 2009 A1
20100057553 Ameiss et al. Mar 2010 A1
20100063906 Nelsen et al. Mar 2010 A1
20100076833 Nelsen Mar 2010 A1
20100088188 Kumar et al. Apr 2010 A1
20100114724 Ghosh et al. May 2010 A1
20100114731 Kingston et al. May 2010 A1
20100114733 Collas et al. May 2010 A1
20100125495 Smith et al. May 2010 A1
20100125510 Smith et al. May 2010 A1
20100131415 Sartipi May 2010 A1
20100191602 Mikkelsen et al. Jul 2010 A1
20100205077 Hammad Aug 2010 A1
20100274655 Postrel Oct 2010 A1
20100280896 Postrel Nov 2010 A1
20100325048 Carlson et al. Dec 2010 A1
20100332386 Vancini et al. Dec 2010 A1
20110055080 Ahlers et al. Mar 2011 A1
20110071914 Beasley et al. Mar 2011 A1
20110106601 Perlman et al. May 2011 A1
20110106674 Perlman May 2011 A1
20110137797 Stals et al. Jun 2011 A1
20110153397 Wagenheim Jun 2011 A1
20110191160 Blackhurst et al. Aug 2011 A1
20110196782 Allen et al. Aug 2011 A1
20110251892 Laracey Oct 2011 A1
20110270665 Kim et al. Nov 2011 A1
20110270748 Graham et al. Nov 2011 A1
20110270749 Bennett et al. Nov 2011 A1
20110276489 Larkin Nov 2011 A1
20110289004 Prakash et al. Nov 2011 A1
20110295748 Woodriffe Dec 2011 A1
20110295749 Scalisi Dec 2011 A1
20110313918 Lawson et al. Dec 2011 A1
20120011063 Killian et al. Jan 2012 A1
20120018511 Hammad Jan 2012 A1
20120078735 Bauer et al. Mar 2012 A1
20120078751 MacPhail et al. Mar 2012 A1
20120084210 Farahmand Apr 2012 A1
20120110634 Jakobsson May 2012 A1
20120130731 Canetto May 2012 A1
20120130887 Meckling May 2012 A1
20120143705 Bhattacharya et al. Jun 2012 A1
20120150687 Hart Jun 2012 A1
20120158589 Katzin et al. Jun 2012 A1
20120185317 Wong Jul 2012 A1
20120185387 Doyle Jul 2012 A1
20120196586 Grigg et al. Aug 2012 A1
20120197793 Grigg et al. Aug 2012 A1
20120197794 Grigg et al. Aug 2012 A1
20120209749 Hammad et al. Aug 2012 A1
20120233005 White Sep 2012 A1
20120239417 Pourfallah et al. Sep 2012 A1
20120253852 Pourfallah et al. Oct 2012 A1
20120253913 Richard Oct 2012 A1
20120254021 Wohied et al. Oct 2012 A1
20120271712 Katzin et al. Oct 2012 A1
20120284130 Lewis et al. Nov 2012 A1
20120284195 McMillen et al. Nov 2012 A1
20120290376 Dryer et al. Nov 2012 A1
20120296720 Pirillo Nov 2012 A1
20120301774 Jiang et al. Nov 2012 A1
20120303425 Katzin et al. Nov 2012 A1
20120310774 Chassin Dec 2012 A1
20120323717 Kirsch Dec 2012 A1
20120323762 Kapur et al. Dec 2012 A1
20120330837 Persaud et al. Dec 2012 A1
20130006848 Kuttuva Jan 2013 A1
20130013509 Perlman et al. Jan 2013 A1
20130018777 Klein Jan 2013 A1
20130018786 Sher Jan 2013 A1
20130018791 Mendicino et al. Jan 2013 A1
20130018792 Casey et al. Jan 2013 A1
20130024364 Shrivastava et al. Jan 2013 A1
20130030941 Meredith et al. Jan 2013 A1
20130042261 Tavormina et al. Feb 2013 A1
20130054336 Graylin Feb 2013 A1
20130054454 Purves et al. Feb 2013 A1
20130054469 Agashe et al. Feb 2013 A1
20130060679 Oskolkov et al. Mar 2013 A1
20130060689 Oskolkov et al. Mar 2013 A1
20130060696 Martin et al. Mar 2013 A1
20130060708 Oskolkov et al. Mar 2013 A1
20130065555 Baker et al. Mar 2013 A1
20130073365 McCarthy Mar 2013 A1
20130073459 Zacarias et al. Mar 2013 A1
20130074168 Hao et al. Mar 2013 A1
20130080241 Fisher Mar 2013 A1
20130080323 Scipioni Mar 2013 A1
20130110628 Yeo et al. May 2013 A1
20130110658 Lyman et al. May 2013 A1
20130132275 Enzaldo et al. May 2013 A1
20130132854 Raleigh et al. May 2013 A1
20130143089 Teshima et al. Jun 2013 A1
20130144663 Qawami et al. Jun 2013 A1
20130144702 Tabor et al. Jun 2013 A1
20130151400 Makhotin et al. Jun 2013 A1
20130166332 Hammad Jun 2013 A1
20130168450 Von Mueller et al. Jul 2013 A1
20130173456 Grigg et al. Jul 2013 A1
20130173474 Ranganathan et al. Jul 2013 A1
20130179336 Lyons et al. Jul 2013 A1
20130179352 Dwyre et al. Jul 2013 A1
20130185167 Mestre et al. Jul 2013 A1
20130191227 Pasa et al. Jul 2013 A1
20130191277 O'Leary et al. Jul 2013 A1
20130191278 O'Leary et al. Jul 2013 A1
20130200999 Spodak et al. Aug 2013 A1
20130204785 Monk et al. Aug 2013 A1
20130226720 Ahluwalia et al. Aug 2013 A1
20130226751 Friedholm et al. Aug 2013 A1
20130226799 Raj Aug 2013 A1
20130232032 Chaturvedi et al. Sep 2013 A1
20130238455 Laracey Sep 2013 A1
20130246258 Dessert Sep 2013 A1
20130246260 Barten et al. Sep 2013 A1
20130246261 Purves et al. Sep 2013 A1
20130246265 Al-Sahli Sep 2013 A1
20130254028 Salci Sep 2013 A1
20130254102 Royyuru Sep 2013 A1
20130254114 Smith Sep 2013 A1
20130254115 Pasa et al. Sep 2013 A1
20130260734 Jain et al. Oct 2013 A1
20130262309 Gadotti Oct 2013 A1
20130262316 Hruska Oct 2013 A1
20130262317 Collinge et al. Oct 2013 A1
20130275250 Rodell et al. Oct 2013 A1
20130290121 Simakov et al. Oct 2013 A1
20130290169 Bathula et al. Oct 2013 A1
20130290176 Tirumalashetty Oct 2013 A1
20130297425 Wallaja Nov 2013 A1
20130297486 Colborn Nov 2013 A1
20130297513 Kirillin et al. Nov 2013 A1
20130304559 Stone et al. Nov 2013 A1
20130304642 Campos Nov 2013 A1
20130317928 Laracey Nov 2013 A1
20130332344 Weber Dec 2013 A1
20130346302 Purves et al. Dec 2013 A1
20140006129 Heath Jan 2014 A1
20140006194 Xie et al. Jan 2014 A1
20140006276 Grigg et al. Jan 2014 A1
20140006277 Rao Jan 2014 A1
20140012750 Kuhn et al. Jan 2014 A1
20140019352 Shrivastava Jan 2014 A1
20140019360 Yang Jan 2014 A1
20140038546 Neal et al. Feb 2014 A1
20140040139 Brudnicki et al. Feb 2014 A1
20140052617 Chawla et al. Feb 2014 A1
20140058855 Hussein et al. Feb 2014 A1
20140058936 Ren et al. Feb 2014 A1
20140058938 McClung, III Feb 2014 A1
20140067677 Ali et al. Mar 2014 A1
20140074581 Johnson et al. Mar 2014 A1
20140074655 Lim et al. Mar 2014 A1
20140074724 Gordon et al. Mar 2014 A1
20140081783 Paranjape et al. Mar 2014 A1
20140081854 Sanchez et al. Mar 2014 A1
20140089171 Gandhi Mar 2014 A1
20140089195 Ward et al. Mar 2014 A1
20140096215 Hessler Apr 2014 A1
20140100975 Van Apr 2014 A1
20140101034 Tanner et al. Apr 2014 A1
20140101048 Gardiner et al. Apr 2014 A1
20140108254 Lee Apr 2014 A1
20140109200 Tootill et al. Apr 2014 A1
20140114856 Jung et al. Apr 2014 A1
20140118704 Duelli et al. May 2014 A1
20140122310 Torrens et al. May 2014 A1
20140122563 Singh et al. May 2014 A1
20140129357 Goodwin May 2014 A1
20140129433 Rosenberger May 2014 A1
20140136352 Ramakrishna et al. May 2014 A1
20140143089 Campos et al. May 2014 A1
20140188586 Carpenter et al. Jul 2014 A1
20140188704 Grossman et al. Jul 2014 A1
20140188718 Grossman et al. Jul 2014 A1
20140188719 Poornachandran et al. Jul 2014 A1
20140201086 Gadotti et al. Jul 2014 A1
20140207680 Rephlo Jul 2014 A1
20140210321 Dixon Jul 2014 A1
20140214640 Mallikarjunan et al. Jul 2014 A1
20140222670 Concannon Aug 2014 A1
20140236792 Pant et al. Aug 2014 A1
20140244506 Gramling Aug 2014 A1
20140250003 Levchin et al. Sep 2014 A1
20140258135 Park et al. Sep 2014 A1
20140279097 Alshobaki et al. Sep 2014 A1
20140279459 Weiss et al. Sep 2014 A1
20140279469 Mendes Sep 2014 A1
20140279559 Smith et al. Sep 2014 A1
20140279566 Verma et al. Sep 2014 A1
20140282068 Levkovitz et al. Sep 2014 A1
20140297435 Wong Oct 2014 A1
20140297520 Levchin et al. Oct 2014 A1
20140297524 Ravindranath et al. Oct 2014 A1
20140304095 Fisher Oct 2014 A1
20140304187 Menn Oct 2014 A1
20140310173 Caldwell Oct 2014 A1
20140310182 Cummins Oct 2014 A1
20140337175 Katzin et al. Nov 2014 A1
20140337621 Nakhimov Nov 2014 A1
20140344153 Raj et al. Nov 2014 A1
20140351072 Wieler et al. Nov 2014 A1
20140351126 Priebatsch Nov 2014 A1
20140351130 Cheek et al. Nov 2014 A1
20140365322 Phillips Dec 2014 A1
20140365363 Knudsen et al. Dec 2014 A1
20140376576 Jespersen et al. Dec 2014 A1
20140379576 Marx et al. Dec 2014 A1
20150019944 Kalgi Jan 2015 A1
20150026049 Theurer et al. Jan 2015 A1
20150032626 Dill et al. Jan 2015 A1
20150032627 Dill et al. Jan 2015 A1
20150046339 Wong et al. Feb 2015 A1
20150066790 Desanti Mar 2015 A1
20150074774 Nema et al. Mar 2015 A1
20150088633 Salmon et al. Mar 2015 A1
20150089568 Sprague et al. Mar 2015 A1
20150095075 Breuer et al. Apr 2015 A1
20150100442 Van Heerden et al. Apr 2015 A1
20150100495 Salama et al. Apr 2015 A1
20150112781 Clark et al. Apr 2015 A1
20150120472 Aabye et al. Apr 2015 A1
20150121063 Maller et al. Apr 2015 A1
20150134514 Chan et al. May 2015 A1
20150134540 Law et al. May 2015 A1
20150137938 Slaby et al. May 2015 A1
20150140960 Powell et al. May 2015 A1
20150154588 Purves et al. Jun 2015 A1
20150178693 Solis Jun 2015 A1
20150186855 Bennett et al. Jul 2015 A1
20150186872 Sobol et al. Jul 2015 A1
20150186875 Zhang et al. Jul 2015 A1
20150186886 Schwalb et al. Jul 2015 A1
20150186952 Brown et al. Jul 2015 A1
20150187021 Moring et al. Jul 2015 A1
20150193131 Bayer et al. Jul 2015 A1
20150193745 Handwerger et al. Jul 2015 A1
20150193869 Del Vecchio et al. Jul 2015 A1
20150213435 Douglas et al. Jul 2015 A1
20150220914 Purves et al. Aug 2015 A1
20150229622 Grigg et al. Aug 2015 A1
20150237026 Kumar Aug 2015 A1
20150242987 Lee et al. Aug 2015 A1
20150254660 Allison et al. Sep 2015 A1
20150254698 Bondesen et al. Sep 2015 A1
20150254699 Bondesen et al. Sep 2015 A1
20150278799 Palanisamy Oct 2015 A1
20150278816 Fleishman et al. Oct 2015 A1
20150287015 Kaplinger et al. Oct 2015 A1
20150287037 Salmon et al. Oct 2015 A1
20150324768 Filter et al. Nov 2015 A1
20150332252 Shahrokhi et al. Nov 2015 A1
20150333964 Wang et al. Nov 2015 A1
20150339662 Huang et al. Nov 2015 A1
20150339663 Lopreiato et al. Nov 2015 A1
20150339671 Krietzman et al. Nov 2015 A1
20150348029 Van Os et al. Dec 2015 A1
20150363810 Kim et al. Dec 2015 A1
20150371212 Giordano et al. Dec 2015 A1
20150371234 Huang et al. Dec 2015 A1
20150371326 Montesano et al. Dec 2015 A1
20160004876 Bye et al. Jan 2016 A1
20160012465 Sharp Jan 2016 A1
20160026999 Kurian Jan 2016 A1
20160042341 Griffin et al. Feb 2016 A1
20160042344 Thimmana et al. Feb 2016 A1
20160048828 Lee Feb 2016 A1
20160048929 Parento et al. Feb 2016 A1
20160054336 Anderberg et al. Feb 2016 A1
20160063496 Royyuru et al. Mar 2016 A1
20160065370 Le Saint et al. Mar 2016 A1
20160071071 Lazay Mar 2016 A1
20160071074 Baird Mar 2016 A1
20160071096 Rosca Mar 2016 A1
20160071097 Lazay Mar 2016 A1
20160071099 Lazay Mar 2016 A1
20160071109 Lazay Mar 2016 A1
20160071110 Lazay Mar 2016 A1
20160086170 Hurt et al. Mar 2016 A1
20160086179 Barbier Mar 2016 A1
20160092696 Guglani et al. Mar 2016 A1
20160092866 Liberty et al. Mar 2016 A1
20160092868 Salama et al. Mar 2016 A1
20160092874 O'Regan et al. Mar 2016 A1
20160125396 Brickell et al. May 2016 A1
20160125409 Meredith et al. May 2016 A1
20160125417 Huang et al. May 2016 A1
20160132875 Blanco et al. May 2016 A1
20160132884 Fridman et al. May 2016 A1
20160140555 Scipioni May 2016 A1
20160140561 Cowan May 2016 A1
20160162882 McClung, III Jun 2016 A1
20160162889 Badenhorst Jun 2016 A1
20160180305 Dresser et al. Jun 2016 A1
20160269416 Camenisch et al. Sep 2016 A1
20160283925 Lavu et al. Sep 2016 A1
20160342962 Brown et al. Nov 2016 A1
20160342992 Lee Nov 2016 A1
20160343043 Hicks et al. Nov 2016 A1
20160379215 Clerkin Dec 2016 A1
20170017958 Scott et al. Jan 2017 A1
20170061402 Mobin et al. Mar 2017 A1
20170061406 Adams et al. Mar 2017 A1
20170061438 Patel Mar 2017 A1
20170164139 Deselaers et al. Jun 2017 A1
20170178110 Swanson et al. Jun 2017 A1
20170185989 Bozovich, Jr. Jun 2017 A1
20170193468 Chougule et al. Jul 2017 A1
20170228715 Gurunathan Aug 2017 A1
20170236118 Laracey Aug 2017 A1
20170337542 Kim et al. Nov 2017 A1
20170357969 Huang et al. Dec 2017 A1
20170357977 Pitz et al. Dec 2017 A1
20170364914 Howard Dec 2017 A1
20180007052 Quentin Jan 2018 A1
20180012203 Hall Jan 2018 A1
20180032981 Shanmugam et al. Feb 2018 A1
20180068308 Gupta et al. Mar 2018 A1
20180082283 Sharma Mar 2018 A1
20180096428 Gorenstein Apr 2018 A1
20180157336 Harris et al. Jun 2018 A1
20180219863 Tran Aug 2018 A1
20180285836 Enobakhare Oct 2018 A1
20180322488 Arana et al. Nov 2018 A1
20180324204 McClory et al. Nov 2018 A1
20180365675 Sivaraman Dec 2018 A1
20180374076 Wheeler Dec 2018 A1
20190108505 Perlman Apr 2019 A1
20190122222 Uechi Apr 2019 A1
20190165942 Subramaniam May 2019 A1
20190220908 Wilkes Jul 2019 A1
20190236577 Schmid et al. Aug 2019 A1
20190280863 Meyer et al. Sep 2019 A1
20190303803 Buc et al. Oct 2019 A1
20190304029 Murray et al. Oct 2019 A1
20190385250 Bhattacharjee et al. Dec 2019 A1
20200005277 Prabhu et al. Jan 2020 A1
20200028753 Powar et al. Jan 2020 A1
20200034813 Calinog et al. Jan 2020 A1
20200051117 Mitchell Feb 2020 A1
20200097957 Driggs et al. Mar 2020 A1
20200151706 Mossoba et al. May 2020 A1
20200175496 Finke et al. Jun 2020 A1
20200219060 Fredericks et al. Jul 2020 A1
20200279305 Mossoba et al. Sep 2020 A1
20200372536 Scislowski et al. Nov 2020 A1
20210027291 Ranganathan Jan 2021 A1
20210056552 Murray Feb 2021 A1
20210110392 Lacoss-Arnold et al. Apr 2021 A1
20210158333 Cohen et al. May 2021 A1
20210166260 Ho et al. Jun 2021 A1
20210358754 Masuoka et al. Nov 2021 A1
20210398179 Kolaja et al. Dec 2021 A1
20220027873 Pathuri et al. Jan 2022 A1
20220101609 Hu et al. Mar 2022 A1
20220147967 Clark May 2022 A1
20220210209 Vanbuskirk et al. Jun 2022 A1
20220215356 Dakshinyam Jul 2022 A1
Foreign Referenced Citations (22)
Number Date Country
2002-312554 Oct 2002 JP
20090014076 Feb 2009 KR
WO-2011100529 Aug 2011 WO
WO-2011113121 Sep 2011 WO
WO-2011159842 Dec 2011 WO
WO-2012139003 Oct 2012 WO
WO-2013044175 Mar 2013 WO
WO-2013079793 Jun 2013 WO
WO-2014111888 Jul 2014 WO
WO-2014134180 Sep 2014 WO
WO-2014207615 Dec 2014 WO
WO-2014210321 Dec 2014 WO
WO-2015023172 Feb 2015 WO
WO-2015054697 Apr 2015 WO
WO-2016009198 Jan 2016 WO
WO-2016053975 Apr 2016 WO
WO-2016097879 Jun 2016 WO
WO-2016153977 Sep 2016 WO
WO-2016172107 Oct 2016 WO
WO-2016196054 Dec 2016 WO
WO-2017106309 Jun 2017 WO
WO-2018005798 Jan 2018 WO
Non-Patent Literature Citations (37)
Entry
“Authors et al., Secure Authorization Token, Sep. 18, 2013, IP.com PAD, entire document” (Year: 2013).
Authors: Saygin Baksi et al; Title: Optimal primary-secondary user pairing and power allocation in cognitive cooperative multiple access channels; Date Added to IEEE Xplore: Apr. 10, 2014 (Year: 2014).
Authors et al: Tianliang Lei ; Title: Investigation of Cross-Social Network User Identification; Date of Conference: Apr. 21-22, 2022 . (Year: 2022).
P2P-Paid: A Peer-to-Peer Wireless Payment System by Gao et al (Year: 2005).
“Wang et al. Mobile payment security, threats, and challenges, Mar. 24, 2016, IEEE Xplore, Entire document” (Year: 2016).
Hany Herb, Hassan Farahat, and Mohamed Ezz, SecureSMSPay: Secure SMS Mobile Payment Model, 2008, 2008 2nd International Conference on Anti-counterfeiting, Security and Identification (pp. 11-17) (Year:2008).
J. Gao, V. Kulkarni, H. Ranavat, L. Chang and H. Mei, “A 2D Barcode-Based Mobile Payment System,” 2009 Third International Conference on Multimedia and Ubiquitous Engineering, 2009, pp. 320-329, doi: 10.1109/MU E.2009.62. (Year: 2009).
Latterell, Kayla, “How Do Gift Cards Work?,” https://www.cardsource.com/news/how-do-gift-cards-work, pp. 1-6.
“Cashcloud Mobile eWallet”, FinTech Forum Exchange, Jul. 1, 2016. 4 pages.
“Cashcloud mobile eWallet”, Popote Payments, www.popotepayments.com, 2016. 6 pages.
“Messages in the SCT interbank space—pacs.008 and pacs.002”, Nov. 1, 2017, Paiementor, pp. 1-3 (Year: 2017).
A Smart Card Alliance Payments Council White Paper; Publication date: Sep. 2011; Publication No. PC-11002; 191 Clarksville Rd. Princeton Junction, NJ 08550 www.smartcardalliance.org (Year: 2011).
Alipay, Alipay Documentation Red Packet QR Code Introduction, printed on Sep. 30, 2019 at Internet address https://intl.alipay.com/doc/redpacket/scrzsv, 2 pages.
Alipay, Trust Makes It Simple, printed on Sep. 30, 2019 from Internet address https://intl.alipay.com/, 3 pages.
Authors et al.: Disclosed anonymously, Notifying a User When a Bill is Due Using a Notification on the User's Mobile Device, Oct. 18, 2013 IP.com PAD, entire document (Year: 2013).
Bravo, Bravo Pay, CrunchBase, printed on Sep. 30, 2019 from Internet address https://www.crunchbase.com/organization/bravo#section-overview, 9 pages.
Bravo, Tip or Pay Your Tour Guide Without Sharing Personal Info, printed on Sep. 30, 2019 from Internet address https://trybravo.com, 4 pages.
Bravo, Trybravo's Competitors, Revenue, Number of Employees, Funding and Acquisitions, printed from Internet address https://www.owler.com/company/trybravo on Sep. 30, 2019, 2 pages.
DipJar, printed on Sep. 30, 2019 from Internet address https://www.dipjar.com/, 10 pages.
EMV, “Payment Tokenisation Specification Technical Framework”, 2014 EMVCO, LLC. 84 pages.
How to Control Children's Spending on Debit Cards | Money | by Jill Paperworth, May 10, 2009, https:www.theguardian.com/money/2009/mar/.../children-debit-cards-online-spend . . . (Year: 2009).
Lehdonvirta et al., UbiPay: Minimizing Transaction Costs with Smart Mobile Payments, Proceedings of the 6th International Conference on Mobile Technology, Application & Systems, ACM, Jan. 2009, retrieved from the Internet at http://www.researchgate.net/profile/Tatsuo_Nakajima/publication/220982951_UbiPay_minimizing_transaction_costs_with_smart_mobile_payments/links/548e9dad0cf225bf66a607bb.pdf on Oct. 30, 2015, 8 pages.
LevelUp, Restaurant Customers Expect Seamless Digital Experiences, printed on Sep. 30, 2019 from Internet address https://www.thelevelup.com/, 4 pages.
Message in the SCT interbank space—pacs.008 and pacs.002, Nov. 1, 2017, Paiementor, pp. 1-3 (Year: 2017).
N. C. Kiran and G. N. Kumar, “Reliable OSPM schema for secure transaction using mobile agent in micropayment system,” 2013 Fourth International Conference on Computing, Communications and Networking Technologies (ICCCNT), 2013, pp. 1-6, doi: 10.1109/ICCCNT.2013,6726503. (Year: 2013).
P. De, K. Dey, V. Mankar and S. Mukherjea, “Towards an interoperable mobile wallet service,” 2013 10th International Conference and Expo on Emerging Technologies for a Smarter World (CEWIT), 2013, pp. 1-6, doi: 1109/CEWIT.2013.6713767. (Year: 2013).
Smart Card Alliance, “The Mobile Payments and NFC Landscape: A U.S. Perspective,” Sep. 2011. 53 pages.
Square, Inc., Grow Your Business Your Way With Square Tools, printed on Sep. 30, 2019 from Internet address https://squareup.com/us/en, 8 pages.
TSIP, Introducing Helping Heart—A Contactless Payment Jacket to Help the Homeless, dated Jul. 4, 2017, printed on Sep. 30, 2019 from Internet address https://www.tsip.co.uk/blog/2019/2/19/introducing-helping-heart-a-contactless-payment-jacket-to-help-the-homeless, 4 pages.
Uber, How Uber Works, printed on Sep. 30, 2019 from Internet address https://www.uber.com/us/en/about/how-does-uber-work/, 6 pages.
W. Adi, A. Al-Qayedi, A. A. Zarooni and A. Mabrouk, “Secured multi-identity mobile infrastructure and offline mobile-assisted micro-payment application,” 2004 IEEE Wireless Communications and Networking Conference (IEEE Cat. No. 04TH8733), 2004, pp. 879-882 vol. 2, doi: 10.1109/WCNC.2004.1311302. (Year: 2004).
Wazeopedia, Main Page, printed on Sep. 30, 2019 from Internet address https://wazeopedia.waze.com/wiki/USA/Main_Page, 3 pages.
White, Ron, “How Computers Work”, Que Publishing, 7th Ed, Oct. 15, 2003, p. 4. 23 pages.
Yang, Ming-Hour. “Security enhanced EMV-based mobile payment protocol.” TheScientificWorldJournal vol. 2014 (2014): 864571. Doi: 10.115/2014/864571 (Year: 2014).
Kyrillidis; Mayes; Markantonakis, Card-present Transactions on the Internet Using the Smart CardWeb Server, 2013, IEEE, 12th, P616 (Year: 2013).
Urien, P., et al., “A breakthrough for prepaid payment: End to end token exchange and management using secure SSL channels created by EAP-TLS smart cards”, 2011 International Conference on Collaboration Technologies and Systems (CTS), 2011. (Year: 2011).
Polito et al., Inter-provider AAA and Billing of VoIP Users with Token-based Method, Dec. 26, 2007, IEEE Xplore, entire document (Year: 2007).
Provisional Applications (1)
Number Date Country
63270718 Oct 2021 US