Digital tag

Abstract

The invention discloses a method. The method includes receiving, by a transfer application on a device of a first user, a payload including a digital tag associated with a second user, a transaction identifier, and a transaction amount. The digital tag associated with the second user is transmitted by the transfer application to a digital tag computer. A primary account or token associated with the digital tag is received by the transfer application from the digital tag computer, and a push transfer message is transmitted by the transfer application to the acquirer computer.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2021 / 030145, international application date April 30, 2021, application number 202180020482.5 entering the Chinese national phase, and name “Digital Label”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is a PCT application claiming priority to and the benefit of U.S. Provisional Patent Application No. 63 / 018,769 filed on May 1, 2020, U.S. Provisional Patent Application No. 63 / 067,969 filed on August 20, 2020, and U.S. Provisional Patent Application No. 63 / 152,209 filed on February 22, 2021, all of which are incorporated herein by reference in their entirety. Background Art

[0004] Many transactions are completed by exchanging a primary account number between a first user and a second user. Often, it is difficult to remember or correctly enter a primary account number (e.g., a set of sixteen alphanumeric characters linked to an account) into a money transfer application that facilitates the transaction. Additionally, there may be privacy issues with the first user knowing the second user's primary account number.

[0005] Many money transfer apps allow users of the app to easily transact with other users of the same app. Such apps may use aliases (e.g., email addresses, phone numbers, etc.) to facilitate transactions through a primary account. The use of aliases allows users to easily direct transactions to users of the same app, but not all money transfer apps use the specific aliases used. In addition, email addresses and phone numbers are increasingly viewed as sensitive personal data, and users may be reluctant to share this information with parties they do not know well.

[0006] Embodiments of the present disclosure address this and other problems, individually and collectively. Summary of the invention

[0007] One embodiment of the present invention includes a method. The method includes: receiving a payload including a digital tag associated with a second user and a transaction amount by a transfer application on a first user device; transmitting the digital tag associated with the second user to a digital tag computer by the transfer application; receiving a primary account number or token associated with the digital tag from the digital tag computer by the transfer application; generating a push transfer message including the transaction amount and the primary account number or token associated with the second user by the transfer application; and transmitting the push transfer message to a transfer computer by the transfer application.

[0008] Another embodiment includes a user device, comprising: a processor and a computer-readable medium, the computer-readable medium including instructions for causing the user device to perform the following operations: receiving, by a transfer application on a first user device, a payload including a digital tag associated with a second user and a transaction amount; transmitting, by the transfer application, the digital tag associated with the second user to a digital tag computer; receiving, by the transfer application, a primary account number or token associated with the digital tag from the digital tag computer; generating, by the transfer application, a push transfer message including the transaction amount and the primary account number or token associated with the second user; and transmitting, by the transfer application, the push transfer message to a transfer computer.

[0009] Yet another embodiment includes a method. The method includes: receiving, by a digital tag computer, a payload including a digital tag associated with a second user and a transaction amount; retrieving, by the digital tag computer, a primary account number or token associated with the digital tag from a database associated with the digital tag computer; and transmitting, by the digital tag computer, the primary account number or token indicated by the digital tag associated with the second user to a money transfer application on a first user device.

[0010] The nature and advantages of the embodiments of the present invention may be better understood with reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1A An example flow of a user requesting issuance of a digital tag from an authorized entity is shown.

[0012] Figure 1B An example flow of a user requesting issuance of a digital tag from an aggregation entity is shown.

[0013] Figure 2 An example flow of a transaction between a first user and a second user associated with an aggregation entity via a money transfer application is shown.

[0014] Figure 3 An example process for transaction reversal is shown.

[0015] Figure 4 An example process for requesting issuance of a digital tag linked to a virtual credential from a money transfer application is shown.

[0016] Figure 5 An example flow of a transaction between a first user and a second user using a digital tag linked to a virtual credential is shown.

[0017] Figure 6 A block diagram of a user device 600 according to an embodiment is shown.

[0018] Figure 7A block diagram of a digital label computer 700 according to an embodiment is shown. DETAILED DESCRIPTION

[0019] Before discussing the embodiments of the present disclosure, some terms may be described in further detail.

[0020] "User" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0021] A "user device" may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). The user device may take any suitable form. Some examples of user devices include cards with a magnetic stripe or contactless element (e.g., including a contactless chip and antenna) (e.g., payment cards such as debit cards, credit cards, and prepaid cards), cellular phones, PDAs, personal computers (PCs), tablet computers, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable components.

[0022] An "authorizing entity" may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a government agency, a document repository, an access administrator, etc. An "issuer" may generally refer to a commercial entity (e.g., a bank) that maintains a user account. An issuer may also issue a payment credential to a customer that is stored on a user device such as a cell phone, smart card, tablet computer, or laptop computer.

[0023] A "mobile device" (sometimes referred to as a mobile communication device) may include any suitable electronic device that a user can transport or operate, which may also provide remote communication capabilities with a network. A mobile communication device may communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G or similar network), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, wearable devices (e.g., watches), vehicles such as cars and motorcycles, personal music players, handheld dedicated readers, etc. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device remotely accesses a network by tethering with another device (i.e., using the other device as a modem), two devices used together may be considered a single mobile device).

[0024] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such a single entity, an issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0025] An "aggregation entity" may generally be an entity that aggregates something. In some embodiments, an aggregation entity may aggregate merchants participating in a transaction and may sell goods or services, or provide access to goods or services. An aggregation entity may operate a server computer, which may generally be referred to as an "aggregation entity computer."

[0026] A "merchant" may generally be an entity that participates in a transaction and may sell goods or services or provide access to goods or services. In some embodiments, a merchant may be a seller that lists goods and / or services on a website hosted by an aggregation entity.

[0027] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as a confirmation. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information.

[0028] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account, or may be derived from information associated with the account. Examples of account information may include PAN (primary account number or "account number"), username, expiration date, and verification values ​​such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0029] A "digital wallet" may include an electronic device that allows a person to conduct e-commerce transactions. An electronic wallet may store user profile information, payment credentials, bank account information, one or more digital wallet identifiers, etc., and may be used in a variety of transactions, such as, but not limited to, e-commerce, social networking, transfers / personal payments, mobile commerce, proximity payments, gaming, etc., for retail purchases, digital goods purchases, utility payments, purchases of games or game points from gaming websites, transfers of funds between users, etc. A digital wallet may be designed to simplify the purchase and payment process. A digital wallet may allow a user to load one or more payment cards onto a digital wallet in order to make payments without having to enter an account number or present a physical card. A digital wallet may be a money transfer application.

[0030] A "token" may be a replacement value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0031] A “payment token” may include an identifier for a payment account that is a substitute for an account identifier such as a primary account number (PAN). For example, a payment token may include a series of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the token “4900 0000 0000 0001” can be used in place of the PAN “4147 0900 0000 1234”. In some embodiments, a payment token may be “format-retained” and may have a digital format that conforms to account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction, or to represent an original credential in other systems where an original credential would normally be provided. In some embodiments, a payment token may be generated so that recovery of the original PAN or other account identifier from the token value may not be derived computationally. Additionally, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0032] "Tokenization" is the process of replacing data with alternative data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with an alternative number (e.g., a token) that may be associated with the primary account identifier. Additionally, tokenization may be applied to any other information that may be replaced with an alternative value (i.e., a token). Tokenization increases the efficiency and security of transactions.

[0033] A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a Web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0034] There are many methods of payment between individuals and between individuals and merchants. A first user can choose to send a payment for goods and / or services to a second user. The first user can choose one of multiple transfer applications (e.g., a digital wallet) to make the payment. In addition, the second user can list the goods and / or services on multiple aggregation entities (e.g., a marketplace provided by a social network or other website). Multiple transfer applications and multiple aggregation entities need to be able to conduct transactions. Embodiments of the present invention simplify transactions by using digital tags. Digital tags can be shared by users and can be linked to payment credentials that can be used to conduct transactions. Digital tags reduce the number of parties that transfer applications and aggregation entities need to interact with in order to conduct transactions.

[0035] In an embodiment of the present invention, a user, such as a resource provider or an individual, may request a digital tag. The digital tag may be requested from an authorization entity associated with the user (e.g., an issuer maintaining the user's account) or an aggregation entity associated with the user (e.g., a social networking site where the user lists goods and / or services). The digital tag may be linked to a previously issued credential, such as a payment credential issued by an authorization entity.

[0036] Figure 1A A system is shown including a user device 100, an authorization entity computer 102, and a digital tag computer 104. These devices may be in operative communication with each other.

[0037] The components in the system of FIG. 1 and any of the following features can be in operative communication with each other via any suitable communication channel or communication network. Suitable communication networks can be any one and / or combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an operating mission as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., using protocols such as, but not limited to, wireless application protocol (WAP), I-mode, etc.), etc. Messages between computers, networks, and devices can be sent using secure communication protocols such as, but not limited to, file transfer protocol (FTP); hypertext transfer protocol (HTTP); and secure hypertext transfer protocol (HTTPS).

[0038] Figure 1A An example flow 100A is shown for a user to request issuance of a digital tag from an authorization entity 104. The user may be operating a user device 100. In some embodiments, the user device 100 may be a phone. The user may be a resource provider or an individual.

[0039] In step S100A, the user device 100 may generate and transmit a request for a digital tag. The request may include a set of alphanumeric characters to be used as a digital tag, as well as information related to the user operating the user device 100 (e.g., an email address associated with the user, a phone number associated with the user, etc.). The request for the digital tag may then be transmitted to an authorization entity computer 102 associated with the user. The authorization entity computer 102 may maintain an account associated with the user, which may be indicated by a primary account number.

[0040] In step S102A, after receiving a request for a digital tag from the user device 100, the authorized entity computer 102 may verify the uniqueness of the requested digital tag. The authorized entity computer 102 may communicate with a database maintained by the digital tag computer 104 that stores previously received requests (e.g., searching the digital tag database to ensure that the requested digital tag overlaps with a plurality of stored digital tags). Although one authorized entity computer 102 is shown communicating with the digital tag computer 104, there may be many authorized entity computers communicating with the digital tag computer 104.

[0041] In step S104A, the authorization entity computer 102 may receive a message verifying the uniqueness of the digital tag from the digital tag computer 104. The authorization entity computer 102 may then issue the digital tag by linking the digital tag to a primary account number of the user account. In some embodiments, the digital tag may be linked to an alternative account identifier, such as a payment token.

[0042] In step S105A, the issued digital tag and the primary account number or the alternative account identifier may be transmitted to the digital tag computer 104 for storage in a database. The issued digital tag may be in any suitable format. For example, the issued digital tag may be a payment token, a data string including a user name and an authorized entity identifier, a phone number, a tag (e.g., a QR code).

[0043] In step S106A, the authorization entity computer 102 may transmit the issued digital tag to the user device 100 .

[0044] Figure 1B A system is shown including a user device 100, an authorization entity computer 102, a digital tag computer 104, and an aggregation entity computer 106. These devices may be in operative communication with each other.

[0045] Figure 1B An example flow 100B is shown for a user requesting a digital tag to be issued from an aggregate entity. The aggregate entity may be a social networking computer system.

[0046] In step S100B, the user device 100 may generate a request for a digital tag. The request may include a set of alphanumeric characters to be used as a digital tag, and information related to the user operating the user device 100 (e.g., an email address associated with the user, a phone number associated with the user, etc.). The request for the digital tag may then be transmitted to the aggregation entity computer 106.

[0047] In step S102B, the aggregate entity computer 106 may verify the request. For example, verification may include checking that information about the user included in the request matches some information stored by the aggregate entity computer 106. This may require the aggregate entity computer 106 to request a key (e.g., a password or PIN) from the user of the user device 100 and then verify that it matches a key previously received and stored by the aggregate entity computer 106. After verifying the request, the aggregate entity computer 106 may transmit the digital tag request to the digital tag computer 104.

[0048] In step S104B, after receiving the digital label request, the digital label computer 104 may transmit the request to the authorization entity computer 102 .

[0049] In step S106B, the authorized entity computer 102 may verify whether the user has been authenticated in step S102B, and generate and issue a digital tag. The digital tag may be issued by linking the digital tag to the primary account of the user account. In some embodiments, the digital tag may be linked to an alternative account identifier, such as a payment token. The authorized entity computer 102 may transmit the issued digital tag to the digital tag computer 104. The digital tag may be in any suitable form. For example, the digital tag may be a payment token, a data string including a user name and an authorized entity identifier, a telephone number, a mark (e.g., a QR code).

[0050] In step S108B, after receiving the issued digital tag, the digital tag computer 104 may store the digital tag in a database. The digital tag computer 104 may then transmit the issued digital tag to the aggregation entity computer 106.

[0051] In step S110B, the aggregation entity computer 106 may transmit the issued digital tag to the user device 100 .

[0052] In an embodiment of the present invention, a user may first download and install or access in any suitable manner a money transfer application with the ability to send, receive, and request transactions on their user device. The money transfer application may be a standalone application, such as a digital wallet application, a banking application, etc. In some embodiments, the user may add one or more payment cards or instruments to the money transfer application.

[0053] Figure 2 An example flow 200 is shown of a transaction between a first user operating a first user device 202 and a second user operating a second user device 206. The second user operating the second user device 206 may be associated with an aggregate entity operating an aggregate entity computer 204. For example, the second user may be a merchant selling goods or services in a social network marketplace operated by the aggregate entity computer 204. The first user may purchase goods or services from the second user operating the second user device 206 via the aggregate entity computer 204 using the first user device 202.

[0054] The first user device 202 may include a money transfer application 208. The money transfer application 208 may be a digital wallet application, a peer-to-peer payment application, etc. The money transfer application 208 may be associated with an application server (not shown) that facilitates the functionality of the money transfer application 208.

[0055] In some embodiments, the aggregation entity operating the aggregation entity computer 204 may be directly linked to the money transfer application 208. For example, the aggregation entity computer 204 may host an application service of the money transfer application 208 and be able to transmit data directly to the money transfer application 208, or the money transfer application 208 may be able to access data hosted by the aggregation entity computer 204.

[0056] The money transfer application 208 on the first user device 202 may communicate with the digital tag computer 210. The money transfer application computer may also be in operative communication with a second authorization entity computer 216 associated with a second user of the second user device 206 via the transmission computer 212 and the processing network 214. The processing network 214 may also be in communication with the aggregation entity computer 204. The second authorization entity computer 216 may hold an account associated with the second user of the second user device 206.

[0057] Now you can refer to Figure 2 Describe the method.

[0058] In step S200, the first user device 202 may select a good or service provided by the second user and initiate a transaction with the aggregation entity computer 204. In some embodiments, initiating a transaction may include the first user operating the first user device 202 selecting a "pay" and / or "checkout" option at the aggregation entity (e.g., on a website hosted by the aggregation entity computer 204). The first user may choose to pay using the money transfer application 208.

[0059] In some embodiments, the first user device 202 may confirm the transaction amount and receive a payload in step S202A. The payload may include the transaction amount, product description, transaction identifier, and a digital tag associated with the second user. In other embodiments, the first user device 202 may be used to scan a tag (e.g., a QR code) including the payload. In other embodiments, the second user of the second user device 206 may verbally share the digital tag with the first user and / or the first user device 202 via NFC, Bluetooth, ultrasound, email, etc.

[0060] In other embodiments, the aggregation entity computer 204 may indicate that it is directly linked to the transfer application 208. The first user device 202 may confirm the transaction amount and initiate a request for a payload to the aggregation entity computer 204, which will be implemented in step S202B. In some embodiments, the first user device 202 may be configured to scan a token (e.g., a QR code) including a payload. The transfer application 208 may be configured to scan the token.

[0061] In step S202A, the first user device 202 may route the payload to a money transfer application 208 stored on the first user device 202. The money transfer application 208 may then store the payload. The money transfer application 208 may communicate with a first authorized entity operating a first authorized entity computer ( Figure 2 ) and maintain the first user's account.

[0062] In step S202B, in an alternative embodiment, after the first user device 202 confirms the transaction amount, the aggregation entity computer 204 may transmit the payload to the transfer application 208. The transfer application 208 may store the payload. The transfer application 208 may communicate with the first authorized entity ( Figure 2 In some embodiments, the transmission of the payload from the aggregation entity computer 204 to the money transfer application 208 can be performed directly, or in some embodiments, via the digital tag computer 210 or the processing network 214. For example, after the first user device 202 selects the "pay" and / or "checkout" option at the aggregation entity, the first user device 202 can be directed to a digital tag center operated by the digital tag computer 210 (e.g., via an API or link). The digital tag center can transmit the payload to the money transfer application 208.

[0063] In some embodiments, the transfer application 208 itself can maintain the first user's account. The account may have a preloaded fund balance. The transfer application 208 can determine whether the first user has enough funds in the preloaded balance to complete the transaction. If the transfer application 208 determines that the preloaded balance is insufficient, the transfer application 208 can initiate a pull transaction to add funds to the preloaded balance before continuing the transaction (e.g., via a debit card account associated with the first user). In some embodiments, only one of steps S202A and S202B may occur.

[0064] In step S204, after receiving the payload and determining that the first user has sufficient funds for the transaction, the transfer application 208 can transmit the digital tag associated with the second user to the digital tag computer 210. The digital tag computer 210 can parse the associated digital tag included in the payload into a credential. In some embodiments, the credential can be a payment credential, such as a primary account number associated with the second user. For example, the digital tag computer 210 can access a digital tag directory (e.g., a database storing mappings between digital tags and primary accounts) and transmit the retrieved primary account number to the transfer application 208. In some embodiments, the transfer application 208 can transmit the payload to the digital tag computer 210, and the digital tag computer 210 can store the payload in a database.

[0065] In step S206, after receiving the primary account number from the digital tag computer 210, the transfer application 208 can transmit a push transfer message to the transfer computer 212. In some embodiments, the push transfer message can be an original credit transaction message. The push transfer message can include a transaction amount, a transaction identifier, an account identifier or token associated with the first user, and a primary account number associated with the second user.

[0066] In some embodiments, the push transfer instruction message may be an OCT (Original Credit Transaction) message. An OCT (Original Credit Transaction) may be a clearing and settlement credit transaction designed for commercial applications such as commercial transfers or business-to-consumer repayments. An OCT may be a transaction for delivering funds to a recipient's account. In some cases, it is separate from an AFT transaction and may occur after an AFT transaction. This timing is to ensure the safety of payment of funds before they are sent to the recipient.

[0067] In step S208, after receiving the push transfer message from the money transfer application 208, the transmission computer 212 may route the push transfer message to the second authorization entity computer 216 via the processing network 214. The second authorization entity computer 216 may maintain the second user's account and add the transaction amount (i.e., credit) to the second user's account.

[0068] In step S210, after depositing the transaction amount into the account associated with the second user, the second authorization entity computer 216 may transmit a notification message to the second user device 206 to notify it that the transaction is completed.

[0069] In step S212, at any time after routing the push transfer message to the second authorization entity computer 216, the processing network 214 may transmit a notification message to the aggregation entity computer 204. The notification message may include a transaction identifier or payload and a timestamp. The timestamp may be the time when the transaction was completed. The aggregation entity computer 204 may maintain a database of completed transactions. For example, the database may store a payload associated with the transaction identifier.

[0070] Later, during the settlement process, actual funds may be transferred from the first authorized entity (or its computer) associated with the first user of the first user device 202 to a second authorized entity computer 216 of a second authorized entity via the processing network 214 .

[0071] The above-described embodiments allow digital tags to effectively route transactions for a second user. For example, the second user may choose to list goods and / or services on several websites hosted by multiple aggregation entities. The second user may only need to provide digital tags to multiple aggregation entities. In traditional methods, the first user may choose to use multiple transfer applications to trade with any one of the multiple aggregation entities. This requires a communication channel for each combination of the transfer application and the aggregation entity. In addition, some aggregation entities may require users to register one of their compatible transfer applications. In an embodiment of the present invention, a digital tag computer can facilitate these transactions, thereby requiring any single transfer application and aggregation entity to communicate between itself and the digital tag computer. The digital tag is used to route transactions by parsing the digital tag of the second user, and the digital tag of the second user displays its digital tag as a credential that can be used for transactions via the aggregation entity.

[0072] In some embodiments, the first user may generate a transaction reversal request. The transaction reversal request may be a request to return a transaction amount associated with the transaction identifier. For example, the first user may wish to return a product associated with the transaction identifier and receive the transaction amount paid for the product.

[0073] Figure 3An example flow 300 for transaction reversal is shown. In a first scenario (the first scenario will include step 308A), a first user operating a first user device 302 may have completed a transaction using funds withdrawn from an account maintained by a first authorization entity computer 318. In a second scenario (the second scenario will include step 308B), the first user may have used funds from a preloaded balance of an account maintained by a money transfer application 308. The first user may use the first user device 302 to generate a transaction reversal request including a transaction identifier.

[0074] In some embodiments, the first user device 302 may transmit a transaction reversal request to the aggregation entity computer 304. The aggregation entity computer 304 may notify the second user device 306 of the received transaction reversal request. In either scenario, the second user device 306 and / or the aggregation entity computer 304 may agree to complete the transaction reversal. For example, the aggregation entity computer 304 may notify the digital tag computer 310 of the completion of the transaction reversal and transmit a payload (which may be an example of a second payload) with a timestamp associated with the transaction identifier in the transaction reversal request to the digital tag computer 310.

[0075] In other embodiments, the first user device 302 may transmit a transaction reversal request to the money transfer application 308. In the first scenario, the money transfer application 308 may deny the transaction reversal request. In the second scenario, the money transfer application 308 may agree to complete the transaction reversal. The money transfer application 308 may notify the digital tag computer 310 that the transaction reversal is completed. The digital tag computer 310 may choose to retrieve the payload and timestamp from the database or from the aggregate entity computer 304 after receiving this notification.

[0076] In still other embodiments, the first user device 302 may transmit a transaction reversal request to the first authorization entity computer 318. The first authorization entity computer 318 may notify the first user device 302 of the request to reverse the transaction at the money transfer application 308.

[0077] In step S300, after receiving the payload (which may be an instance of the second payload) and notification of the completion of the transaction reversal (e.g., from the above entity), the digital tag computer 310 may verify the data included in the payload. For example, the digital tag computer 310 may verify that the payload received from the aggregation computer 304 is the same payload as that stored in the database by the digital tag computer 310. After verifying the payload, the digital tag computer 310 may then forward the transaction reversal request to the money transfer application 308.

[0078] In step S302, after receiving the transaction revocation request from the digital tag computer 310, the transfer application 308 can initiate a peer-to-peer pull transfer. For example, the transfer application 308 can generate a pull transfer message including a transaction amount, a transaction identifier, an account identifier or token associated with the first user, and a primary account number associated with the second user. In some embodiments, the pull transfer message can be an account funds transaction message. In step S304, the pull transfer message can be routed from the transmission computer 312 to the second authorization entity computer 316 via the processing network 314.

[0079] In some embodiments, the pull transfer message can be an account funds transaction (AFT) message. AFT (account funds transaction) is a transaction that can supply funds to another account, such as a credit, prepaid, debit, ATM or online account. AFT indicators can be used for authorization transactions and clearing and settlement transactions. Neither authorization nor clearing transactions carry any financial information about the transfer recipient. In some embodiments, AFT only carries the account number associated with the sender's payment card. AFT can also be accompanied by an indicator that allows the sender's card issuing bank to make appropriate authorization decisions. The indicator includes channel information, such as mail order / telephone order or Internet order, and merchant type. The following fields can be used in AFT and can be supported in messages and clearing and settlement transactions. Data fields can include: processing code; merchant type; CAVV result code; mail order / telephone order / e-commerce indicator; mail / telephone / e-commerce indicator; transaction ID (XID); and TransStain / CAVV data.

[0080] After receiving the pull transfer message from processing network 314, second authorization entity computer 316 may debit the transaction amount from the account indicated by the primary account number associated with the second user. The transaction amount may then be sent to transfer computer 312. Upon receiving the transaction amount, transfer computer 312 may notify transfer application 308.

[0081] In step S308A (eg, first scenario), after the transfer computer 312 notifies the money transfer application 308 of receipt of the transaction amount, the money transfer application 308 may credit an account associated with the first user maintained by the money transfer application 308 for the transaction amount.

[0082] Alternatively, in step S308B (eg, second scenario), after the transfer computer 312 notifies the money transfer application 308 of receipt of the transaction amount, the money transfer application 308 may credit an account associated with the first user maintained by the first authorization entity computer 318 .

[0083] In step S310, after crediting the account associated with the first user, the money transfer application 308 may notify the digital tag computer 310. The digital tag computer 310 may then notify the aggregation entity computer 304.

[0084] At a later time, actual funds may be transferred from a second authorization entity operating a second authorization entity computer 316 associated with a second user of the second user device 306 to a first authorization entity computer 318 of the first authorization entity via the processing network 314 during a settlement process.

[0085] Figure 4 An example process is shown for requesting the issuance of a digital tag linked to a virtual credential from a money transfer application 404. The digital tag may be similar to the digital tag of the above-described embodiment.

[0086] In step S400, user device 402 may request a digital tag from money transfer application 404. Money transfer application may be installed on user device 402. The request may include a set of alphanumeric characters to be used as the digital tag, and information related to the user operating user device 402 (e.g., an email address associated with the user, a phone number associated with the user, etc.).

[0087] In step S402, upon receiving the request for the digital tag, the money transfer application 404 may issue a virtual credential via an associated authorization entity computer 408. The authorization entity 408 may create the virtual credential and return it to the money transfer application 404. The virtual credential may be in the form of a real payment credential, but unlike a real payment credential, it cannot be used to independently conduct a payment transaction. The credential to be issued may be a virtual receive-only credential (i.e., a credential that only supports incoming payments), or the credential may be a fully functional payment credential (e.g., a PAN) that may also be used for purchases, AFT, etc.

[0088] In step S404, the money transfer application 404 may submit a request to create a digital tag associated with the user to the digital tag computer 406. The request may include the digital tag selected by the user in step S400, and the virtual credential issued by the authorization entity 408 in step S402.

[0089] In step S406, the digital tag computer 406 may receive a request to create a digital tag. The digital tag computer 406 may retrieve the digital tag and the virtual credential from the request. After verifying the uniqueness of the digital tag from a database storing previously received requests (e.g., searching the digital tag database to ensure that the requested digital tag overlaps with a plurality of stored digital tags), the digital tag computer 406 may tokenize the virtual credential. After tokenizing the virtual credential, the digital tag computer 406 may store the digital tag, the tokenized virtual credential, and the virtual credential, and approve the use of the digital tag.

[0090] In some embodiments, the virtual credential can be a receive-only credential. This can be used to add a layer of security when the token is used by a payment initiator to initiate an OCT message. If the token is compromised by a third party, the third party will not be able to withdraw funds from the underlying account.

[0091] In step S408 , the digital tag computer 406 may confirm the approval of the digital tag to the money transfer application 404 .

[0092] In step S410 , the money transfer application 404 may notify the user device 402 that the digital tag has been approved and is available for use. The virtual credential linked to the digital tag may point to an account managed by the money transfer application 404 .

[0093] Digital tags linked to virtual credentials can be used for peer-to-peer transactions. For example, a first user using a first money transfer application can send, receive, or request a transaction with a second user using a second money transfer application. The digital tag allows a transaction to be initiated using the second user's digital tag, which will then resolve to a virtual credential linked to an account managed by the second user's money transfer application.

[0094] Note that you can use dummy credentials instead of the ones above. Figure 2-3 Authentic credentials as described in the process.

[0095] Figure 5 An example flow of a transaction between a first user and a second user using a digital tag linked to a virtual credential is shown. In this embodiment, there is no aggregation computer 502 between the first user device and the second user device 506.

[0096] In step S500, the second user device 506 may share its digital tag with the first user device 502. In some embodiments, the second user device 506 may display a tag (e.g., a QR code) including the digital tag for scanning by the first user device 502. In other embodiments, the second user of the second user device 506 may verbally share the digital tag via NFC, Bluetooth, ultrasound, email, etc.

[0097] In step S502, the first user device 502 may route the digital tag to a first money transfer application 508 stored on the first user device 502. In some embodiments, in step S502, the first user device 502 may input the received digital tag and the amount of funds to be sent to the recipient into the first money transfer application 508. In other embodiments, in step 500, the digital tag may be directly received by the first money transfer application 508.

[0098] In step S504, the first transfer application 508 may send the digital tag to the digital tag computer 510 to parse the digital tag into a voucher. The digital tag computer 510 may then retrieve the voucher from a database (e.g., Figure 4 In step S406 , the virtual credential or tokenized virtual credential is stored by the digital tag computer 106 , and the credential is returned to the first transfer application 508 .

[0099] In step S506, the first transfer application 508 in conjunction with the transmission computer 512 may generate a push transfer message. In some embodiments, the push transfer message may be an original credit transaction message using the received virtual credential. The message may include the amount of the transaction, an account identifier (or token) associated with the first user device 502, and a credential linked to the second user device 506. The message may be sent to the second authorization entity computer 516 via the payment network 514.

[0100] In step S508, the second money transfer application 518 may receive the payment and deposit the funds into the account associated with the virtual credential. The second money transfer application 518 may notify the second user device 506 of the payment received in S510. The second money transfer application 518 may display a notification to the second user when the transaction is complete.

[0101] The above embodiment allows a first user using a first money transfer application to transact with a second user using any other (or the same) money transfer application. The first user may be able to send, receive, and request transactions from the second user more simply because the digital tag computer resolves the digital tag into a virtual credential. The money transfer application may have a communication channel with the digital tag computer to retrieve the virtual credential. The virtual credential can then be used to initiate a transaction. The first user and the second user are able to share their respective digital tags with any other user without having to share their real credentials because the digital tag (together with the digital tag computer) contains all the necessary routing information needed to complete the transaction (e.g., the user's credentials are linked to their digital tags, which are resolved by the digital tag computer for the transaction).

[0102] Figure 6 600 according to an embodiment. The user device 600 may be composed of, for example, Figure 2In some embodiments, the user device 600 can facilitate a user to communicate with another party (e.g., Figure 2 The user device 600 may include a processor 602. The processor 602 may be coupled to a memory 604, a network interface 606, and a computer-readable medium 608. The computer-readable medium 608 may include any suitable number and type of software modules.

[0103] Memory 604 may be used to store data and code. Memory 604 may be coupled to processor 602 internally or externally (e.g., via cloud-based data storage) and may include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. In some embodiments, memory 604 may store data items of a payload.

[0104] The network interface 606 may include an interface that allows the user device 600 to communicate with an external computer. The network interface 606 may enable the user device 600 to transfer data to or from another device, such as an aggregation entity computer, a digital tag computer, a transmission computer, an authorization entity computer, etc. Some examples of the network interface 606 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. The wireless protocols enabled by the network interface 606 may include Wi-Fi TM . Data transmitted via network interface 606 may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signals capable of being received by an external communication interface (collectively referred to as "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 606 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wire or cable, optical fiber, telephone line, cellular link, radio frequency (RF) link, WAN or LAN network, the Internet, or any other suitable medium.

[0105] The computer-readable medium 608 may include code that can be executed by the processor 602 for a method, the method comprising: receiving, by a transfer application on a first user device, a payload including a digital tag associated with a second user, a transaction identifier, and a transaction amount; transmitting, by the transfer application, the digital tag associated with the second user to a digital tag computer; receiving, by the transfer application, a primary account number or token associated with the digital tag from the digital tag computer; generating, by the transfer application, a push transfer message including the transaction amount, the transaction identifier, the account identifier or token associated with the first user, and the primary account number or token associated with the second user; and transmitting, by the transfer application, the push transfer message to the transmission computer.

[0106] The computer-readable medium 608 may include a plurality of software modules, including but not limited to a money transfer application 608A and a communication module 608B.

[0107] The transfer application 608A may include code that causes the processor 602 to receive a payload from the aggregate entity computer. For example, upon receiving the payload from the aggregate entity computer, the transfer application 608A may store the payload in the memory 604. The transfer application 608A may additionally generate push transfer messages and pull transfer messages. In some embodiments, for example Figure 2 In an example, after receiving a payload including a transaction amount and parsing the digital tag in the payload as an account identifier or token associated with the second user, the money transfer application 608A may generate a push transfer message. In some embodiments, for example Figure 3 In the example, after receiving the transaction cancellation request, the transfer application 608A can generate a pull transfer message.

[0108] The communication module 608B may include code that causes the processor 602 to generate messages, forward messages, receive messages, reformat messages, and / or otherwise communicate with other entities. In some embodiments, the communication module 608B may facilitate push transfer messages and / or pull transfer messages to a transfer computer.

[0109] Figure 7 A block diagram of a digital tag computer 700 according to an embodiment is shown. The digital tag computer 700 can facilitate the use of digital tags. For example, the digital tag computer 700 can resolve the digital tag into an account identifier linked during the registration of the digital tag. The digital tag computer 700 can store multiple digital tags. The digital tag computer 700 may include a processor 702. The processor 702 may be coupled to a memory 704, a network interface 706, a computer readable medium 708, and a database 710. The computer readable medium 708 may include any suitable number and type of software modules.

[0110] Memory 704 can be used to store data and code. In some embodiments, memory 704 can be linked to database 710. Memory 704 and / or database 710 can be coupled to processor 702 internally or externally (e.g., via cloud-based data storage), and can include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash or any other suitable memory device. Database 710 may include a directory for links between digital tags and account identifiers. In some embodiments, digital tag computer 700 can store data items (e.g., digital tags, account identifiers and / or tokens, etc.) received due to issuing digital tags in database 710.

[0111] The network interface 706 may include an interface that may allow the digital label computer 700 to communicate with an external computer. The network interface 706 may have the same or different features as the network interface 606 previously described.

[0112] The computer-readable medium 708 may include code that can be executed by the processor 602 for a method, the method comprising: receiving, by a digital tag computer, a payload including a digital tag associated with a second user, a transaction identifier, and a transaction amount; retrieving, by the digital tag computer, a primary account number or token associated with the digital tag from a database associated with the digital tag computer; and transmitting, by the digital tag computer, the primary account number indicated by the digital tag associated with the second user to a transfer application on a first user device.

[0113] The computer-readable medium 708 may include a plurality of software modules, including but not limited to a database management module 708A and a communication module 708B.

[0114] Database management module 708A may include code that causes processor 702 to manage data stored by memory 702 and / or database 710. For example, during the issuance of a digital tag (e.g., Figure 1A , Figure 1B and Figure 4 The database management module 708A may allow the processor 702 to verify the uniqueness of the received digital tag against multiple digital tags stored in the database 710. In some embodiments, after the digital tag computer 700 receives the payload, the database management module 708A may retrieve an account identifier or token linked to the issued digital tag included in the payload.

[0115] The communication module 708B may include code that enables the processor 702 to generate messages, forward messages, receive messages, reformat messages, and / or otherwise communicate with other entities. For example, the communication module 708B may allow the processor 702 to receive a request to check the uniqueness of a digital tag from an authorized entity computer or user device and generate a response.

[0116] Any software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media (such as a hard drive or floppy disk), or optical media (such as a compact disk (CD) or a digital versatile disk (DVD)), flash memory, etc. The computer-readable medium may be any combination of such storage devices or transmission devices.

[0117] Such program can also be encoded and sent using a carrier signal suitable for transmitting via a wired network, an optical network and / or a wireless network that meets multiple protocols including the Internet. Therefore, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such a program. The computer-readable medium encoded with program code can be encapsulated with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or inside a single computer product (e.g., a hard drive, a CD or an entire computer system), and can be present on or inside different computer products in a system or network. A computer system can include a monitor, a printer, or other suitable displays for providing any result mentioned herein to a user.

[0118] The above description is illustrative and non-restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims together with their full scope or equivalents.

[0119] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0120] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: receiving, by the digital tag computer from the authorization entity computer, a digital tag linked to the payment credential of the first user; storing the digital tag and the payment voucher in a database by the digital tag computer; transmitting, by the digital tag computer, the digital tag to a first money transfer application on a user device of the first user; receiving, by the digital tag computer, the digital tag linked to the payment credential of the first user from a second money transfer application on a user device of a second user; retrieving, by the digital tag computer, from the database the payment credential indicated by the digital tag associated with the first user; and The payment credential linked to the digital tag associated with the first user is transmitted by the digital tag computer to the second money transfer application, wherein the digital tag is replaced by the payment credential in a push transfer message transmitted to the transfer computer for authorizing a transaction, the push transfer message requesting approval of a transaction amount processed using the payment credential of the first user.

2. The method of claim 1, wherein the payment credential comprises a primary account number or token linked to the digital tag associated with the first user.

3. The method according to claim 2, wherein the master account or token is a virtual master account or a virtual token. The method of claim 1 , wherein the push transfer message is an original credit transaction message.

5. The method according to claim 1, further comprising: receiving, by the digital tag computer, a payload including a digital tag associated with the first user, a transaction identifier, the transaction amount, and a timestamp; verifying the payload by the digital tag computer; as well as A pull transfer message including the transaction amount, the transaction identifier, and the payment credential associated with the first user is transmitted by the digital tag computer to the first transfer application. The method according to claim 5 , wherein the pull transfer message is an account funds transaction message.

7. The method of claim 5, wherein the payload is part of a transaction reversal request.

8. The method of claim 1, wherein the digital tag received from the authorization entity computer comprises a user-selected digital tag, wherein the method further comprises: Verifying by the digital label computer that the digital label selected by the user is unique; as well as Upon verifying that the digital tag selected by the user is unique, the authorization entity computer is notified by the digital tag computer that the digital tag selected by the user is suitable for being assigned as the digital tag linked to the payment credential of the first user.

9. The method of claim 1, wherein the digital tag computer communicates with a plurality of authorized entity computers.

10. The method according to claim 1, further comprising: The digital label computer manages the digital label center; as well as An API is provided to the user device of the first user, wherein upon selecting an option to pay for the transaction, the user device is directed to the digital label center.

11. A digital label computer, comprising: processor, and A computer readable medium storing instructions that, when executed by the processor, cause the processor to: receiving, from an authorized entity computer, a digital tag linked to a payment credential of the first user; storing the digital tag and the payment credential in a database; transmitting the digital tag to a first money transfer application on a user device of the first user; receiving, from a second money transfer application on a user device of a second user, the digital tag linked to the payment credential of the first user; retrieving from the database the payment credential indicated by the digital tag associated with the first user; as well as transmitting the payment credential linked to the digital tag associated with the first user to the second money transfer application, wherein the digital tag is replaced by the payment credential in a push money transfer message transmitted to a transmitting computer for authorizing a transaction, the push money transfer message requesting approval of a transaction amount processed using the payment credential of the first user.

12. The digital tag computer of claim 11, wherein the payment credential comprises a primary account number or token linked to the digital tag associated with the first user.

13. The digital tag computer of claim 12, wherein the master account or token is a virtual master account or a virtual token.

14. The digital label computer of claim 11, wherein the push transfer message is an original credit transaction message.

15. The digital label computer of claim 11, wherein the instructions, when executed by the processor, further cause the processor to: receiving a payload including a digital tag associated with the first user, a transaction identifier, the transaction amount, and a timestamp; validating the payload; and A pull transfer message including the transaction amount, the transaction identifier, and the payment credentials associated with the first user is transmitted to the first money transfer application.

16. The digital tag computer of claim 15, wherein the pull transfer message is an account funds transaction message.

17. The digital tag computer of claim 15, wherein the payload is part of a transaction reversal request.

18. The digital tag computer of claim 11, wherein the digital tag received from the authorization entity computer comprises a user-selected digital tag, wherein the instructions, when executed by the processor, further cause the processor to: Verifying that the user-selected digital tag is unique; and Upon verifying that the user-selected digital tag is unique, the authorization entity computer is notified that the user-selected digital tag is suitable for being assigned as the digital tag linked to the payment credential of the first user.

19. The digital label computer of claim 11, wherein the digital label computer communicates with a plurality of authorized entity computers.

20. The digital label computer of claim 11, wherein the instructions, when executed by the processor, further cause the processor to: Manage the Digital Label Centre; and An API is provided to the user device of the first user, wherein upon selecting an option to pay for the transaction, the user device is directed to the digital label center.

Images