The present disclosure relates to improved computer processing systems for real-time services through the use of native, non-native, and hybrid tags.
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.
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
Referring now to
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,
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.
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.
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
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.
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.
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 |
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 |
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). |
Number | Date | Country | |
---|---|---|---|
63270718 | Oct 2021 | US |