HK40101285A - Systems and methods for authenticated peer-to-peer data transfer using resource locators - Google Patents

Description

Systems and methods for certified peer-to-peer data transfer using resource locators

Cross-references to related applications

This application claims priority to U.S. Patent Application No. 17/162783, filed January 29, 2021, the disclosure of which is incorporated herein by reference in its entirety.

Technical Field

This disclosure relates to systems and methods for peer-to-peer data transfer, and more particularly to systems and methods for authenticated peer-to-peer data transfer using resource locators.

Background Technology

Point-to-point data transfer can be cumbersome when two peer devices are not already connected via an existing network. This is because, in order to complete a transfer, both peer devices must register and be configured for communication on the same network. Furthermore, configuring and scheduling data transfers can be detrimental to the user experience. Security risks also exist, potentially including risks associated with data integrity and vulnerabilities across platforms, as well as risks associated with misidentifying accounts using email addresses or other account identifiers. These risks and drawbacks may reduce user demand for cross-application communication and inhibit its functionality and efficiency.

These and other shortcomings exist. Therefore, there is a need for systems and methods for peer-to-peer data transmission that provide enhanced security and an improved user experience.

Summary of the Invention

Embodiments of this disclosure provide an authenticated data transmission system including a contactless card comprising a processor and a memory. Upon entering a communication field, the processor can be configured to dynamically generate a Uniform Resource Locator (URL). This URL may include a first set of information, which includes abstract identifier information. The URL may also include a second set of information containing user information. The processor can be configured to send the URL to initiate data transmission. After verifying a received response and confirming a third set of information associated with the data transmission, the data transmission can be completed.

Embodiments of this disclosure provide a method for authenticating data transmission. The method may include: dynamically generating a link including a Near Field Communication Data Exchange Format Uniform Resource Locator (URI), which includes identifier data and user data, after one or more processors of a transmitting device enter a communication field. The method may include sending the link to a first application including instructions for execution on a first device to initiate data transmission. The method may include authenticating a user associated with the first device by activating one or more actions based on the link. The method may include sending one or more requests for confirmation of quantity and recipient data associated with the data transmission. The method may include receiving one or more notifications based on the one or more requests for confirmation of quantity and recipient data associated with the data transmission. The method may include executing one or more login credentials in response to the one or more notifications to complete the data transmission.

Embodiments of this disclosure provide a computer-readable non-transient medium including computer-executable instructions, wherein, when executed by a processor, the instructions execution includes the following steps: dynamically generating a link after a contactless card enters a communication field, the link including a first set of information and a second set of information, the first set of information including identifier information and the second set of information including user information; sending the link to a first application including instructions for execution on a first device to initiate data transmission; identifying a user associated with the first device by activating one or more actions based on the link, the one or more actions being configured to request confirmation of a third set of information associated with the data transmission; and sending one or more responses based on authentication of the third set of information to complete the data transmission.

Attached Figure Description

Various embodiments of the present disclosure, as well as other objects and advantages, can be best understood by referring to the following description taken in conjunction with the accompanying drawings.

Figure 1 depicts an authenticated data transmission system according to an exemplary embodiment.

Figure 2A is an illustration of a contactless card according to an exemplary embodiment.

Figure 2B is an illustration of the contact pad of a contactless card according to an exemplary embodiment.

Figure 3 illustrates a method for authenticating data transmission according to an exemplary embodiment.

Figure 4 illustrates a method for initiating and authenticating data transmission according to an exemplary embodiment.

Figure 5 illustrates another method for initiating and authenticating data transmission according to an exemplary embodiment.

Detailed Implementation

The following description of the embodiments provides non-limiting representative examples that specifically describe features and teachings of different aspects of the invention with reference to numerals. The described embodiments should be considered as being practiceable separately from or in combination with other embodiments described in the embodiment description. Those skilled in the art who read the description of the embodiments should be able to learn and understand the different descriptive aspects of the invention. The description of the embodiments should contribute to an understanding of this disclosure to the extent that other implementations not specifically covered but within the knowledge of those skilled in the art upon reading the description of the embodiments will be understood to be consistent with the application of the invention.

As disclosed herein, users can use their cards for seamless identification and to initiate data transfers. Resource locators, such as Uniform Resource Locators (URLs), Internet Resource Locators (IRLs), Uniform Resource Identifiers (URIs), Uniform Resource Names (URNs), or other resource locators, can include abstract identification information, including but not limited to the cardholder's account or user identifier, which is loaded onto the chip during card personalization. Abstract identification information, such as dynamically generated URLs, can be generated for each transaction.

Non-limiting, identification information can be generated on the card by combining a unique identifier with one or more variables, such as a counter, one or more cryptographic algorithms, and/or any combination thereof. For example, one or more cryptographic algorithms may include encryption techniques such as public-key or private-key encryption, which will also be known to the authentication server. Non-limiting, exemplary symmetric-key algorithms may include symmetric-key encryption, such as DES (Data Encryption Standard), Triple DES, or AES (Advanced Encryption Standard). Non-limiting, exemplary asymmetric-key algorithms may include asymmetric public-key encryption, digital signature algorithms, or RSA (Rivest–Shamir–Adleman).

In some examples, peer-to-peer data transfers can be initiated and authenticated via a website. In other examples, peer-to-peer data transfers can be initiated and authenticated via an application. The systems and methods disclosed herein minimize the exposure of identity information or other personal information and provide greater security.

The exemplary embodiments of this disclosure provide improvements to limitations in the user experience for establishing and coordinating different types of data transfers and mitigating or eliminating security risks such as those associated with cross-platform compatibility, misidentification of accounts via email addresses, authentication of requested data transfers, and verification of device identification. Therefore, the systems and methods disclosed herein improve upon existing implementations by coordinating customized peer-to-peer data transfers that address these limitations and provide enhanced security benefits and an improved user experience.

Figure 1 illustrates an authenticated data transmission system 100. The authenticated data transmission system 100 may include a transmitting device 105, a first application 110, a second application 115, a network 120, a server 125, and a database 130. Although Figure 1 shows a single instance of the components of system 100, system 100 may include any number of components.

System 100 may include a transmitting device 105. The transmitting device 105 may include a contactless card, a contact-based card, a network-enabled computer, or other devices described herein. As further explained below in Figures 2A-2B, the transmitting device 105 may include one or more processors 102 and a memory 104. The memory 104 may include one or more applets 106 and one or more counters 108. The transmitting device 105 may communicate data with one or more devices 112, 117. For example, the transmitting device may transmit data to client devices 112, 117 via network 120. In some examples, the transmitting device 105 may be configured to transmit data to client device 117 via network 120 after entering one or more communication fields of client devices 112, 117. Without limitation, the transmitting device 105 may be configured to transmit data to client devices 112, 117 after entering one or more communication fields of client devices 112, 117 once or multiple times, such entry being associated with tapping, swiping, waving, and/or any combination thereof.

System 100 may include a first application 110. For example, the first application 110 may include instructions for execution on the first device 112. The first application 110 may communicate with any component of system 100. For example, the first device 112 may execute one or more applications such as the first application 110, which enable, for example, network and/or data communication with one or more components of system 100, and to send and/or receive data. The first device 112 may include one or more processors 113 coupled to memory 114. For example, the first device 112 may be a network-enabled computer. As referred to herein, a networked computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, network equipment, personal computers, workstations, telephones, handheld PCs, personal digital assistants, contactless cards, thin clients, fat clients, internet browsers, or other devices. The first device 112 may also be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad, or any other mobile device running Apple's operating system, any device running Microsoft's Mobile operating system, any device running Google's operating system, and/or any other smartphone, tablet, or similar wearable mobile device.

The first device 112 may include processing circuitry and may include additional components such as a processor, memory, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as required to perform the functions described herein. The first device 112 may also include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any available and supported device for inputting information into a user device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or portable video camera. These devices may be used for inputting information and interacting with other devices in the software described herein. In some examples, the first device 112 may include at least one selected from the group consisting of mobile devices, wearable devices, and automated service terminals.

System 100 may include a second application 115. The second application 115 may include instructions for execution on the second device 117. The second application 115 may communicate with any component of system 100. For example, the second device 117 may execute one or more applications such as the second application 115, enabling, for example, network and/or data communication with one or more components of system 100, and sending and/or receiving data. The second device 117 may include one or more processors 116 coupled to memory 118. For example, the second device 117 may be a networked computer. As referred to herein, a networked computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, network equipment, personal computers, workstations, telephones, handheld PCs, personal digital assistants, contactless cards, thin clients, fat clients, internet browsers, or other devices. The second device 117 may also be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad, or any other mobile device running Apple's operating system, any device running Microsoft's Mobile operating system, any device running Google's operating system, and/or any other smartphone, tablet, or similar wearable mobile device.

The second device 117 may include processing circuitry and may include additional components such as a processor, memory, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as required to perform the functions described herein. The second device 117 may also include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any available and supported device for inputting information into a user device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or portable video camera. These devices may be used for inputting information and interacting with other devices in the software described herein. In some examples, the second device 117 may include at least one selected from the group consisting of mobile devices, wearable devices, and automated service terminals.

System 100 may include network 120. In some examples, network 120 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect to any component of system 100. For example, client devices 112, 117 may be configured to connect to server 125 via network 120. In some examples, network 120 may include one or more of the following: fiber optic network, passive optical network, wired network, Internet network, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

Furthermore, network 120 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 120 may support the Internet, wireless communication networks, cellular networks, or any combination thereof. Network 120 may also include a single network, or any number of exemplary types of networks mentioned above, operating as independent networks or collaboratively with each other. Network 120 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 120 may be converted to one or more protocols of network devices, or converted from other protocols to one or more protocols of network devices. Although network 120 is depicted as a single network, it should be understood that, according to one or more examples, network 120 may include multiple interconnected networks, such as, for example, the Internet, service provider networks, cable television networks, corporate networks such as credit card association networks, and home networks.

Client devices 112 and 117 can communicate with one or more servers 125 via one or more networks 120 and can operate as a corresponding front-end to back-end pair with server 125. Client devices 112 and 117 can, for example, send one or more requests to server 125 from mobile device applications 110 and 115 running on them. These requests may be associated with retrieving data from server 125. Server 125 can receive one or more requests from client devices 112 and 117. Based on one or more requests from client applications 110 and 115, server 125 can be configured to retrieve the requested data. Server 125 can be configured to send the received data to client applications 110 and 115 in response to one or more requests.

System 100 may include one or more servers 125. In some examples, server 125 may include one or more processors 127 coupled to memory 129. Server 125 may be configured as a central system, server, or platform to control and invoke various data at different times to perform multiple workflow actions. Server 125 may be configured to connect to one or more client devices 112, 117. Server 125 may communicate with client applications 110, 115. For example, server 125 may communicate with client applications 110, 115 via one or more networks 120.

System 100 may include one or more databases 130. Database 130 may include relational databases, non-relational databases, or other database implementations, and any combination thereof comprising multiple relational and non-relational databases. In some examples, database 130 may include a desktop database, a mobile database, or an in-memory database. Furthermore, database 130 may be hosted internally on devices 112, 117, or it may be hosted externally on devices 112, 117, such as by server 125, by a cloud-based platform, or on any storage device that communicates with devices 112, 117. In some examples, database 130 may communicate with any number of components of system 100. For example, server 125 may be configured to retrieve requested data sent by applications 110, 115 from database 130. Server 125 may be configured to send received data from database 130 to client applications 110, 115 via network 120, the received data being in response to one or more requests. In other examples, client applications 110 and 115 may be configured to send one or more requests for requested data from database 130 via network 120.

In some examples, the exemplary processes described herein can be performed by a processing device and/or a computing device (e.g., a computer hardware device). Such a processing/computing device may be, for example, all or part of a computer/processor, or may include, but is not limited to, a computer/processor that may include, for example, one or more microprocessors, and uses instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard disk drive, or other storage device). For example, the computer-accessible medium may be part of the memory of client devices 112, 117, and/or server 125 or other computer hardware devices.

In some examples, a computer-accessible medium (e.g., a storage device or a collection thereof, such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., as described above) may be provided (e.g., for communication with a processing device). The computer-accessible medium may contain executable instructions thereon. Alternatively or separately, a storage device may be provided separately from the computer-accessible medium, which may provide instructions to the processing device to configure the processing device to perform certain exemplary procedures, processes, and methods, such as those described above.

In some examples, the sending device 105 may include a contact-based card. For example, the contact-based card may be configured to send a link to initiate data transmission after a connection is established with the device. This link may include, for example, a URL, IRL, URI, or URN. Without limitation, the contact-based card may be configured to establish physical contact with a card reader (e.g., a chip reader or magnetic stripe reader) of the client device 112. The card reader may be integrated internally or externally into the client device 112.

In other examples, the sending device 105 may include a contactless card. For example, the contactless card may be configured to send a link to the first application 110 to initiate data transmission after entering the communication field. This link may include, for example, a URL, IRL, URI, or URN. In some examples, the contactless card may enter the communication field of the client device 112 via one or more gestures selected from the group of tapping, swiping, waving, or any combination thereof.

In some examples, a user may be identified based on a Mobile Network Operator (MNO) lookup. In other examples, a user may be identified based on one or more cookies associated with a previous account login, such as login to an account associated with the sending device, a separate account associated with the user, and/or other accounts. The link may include a Near Field Communication Data Exchange Format Uniform Resource Locator (NDEF URL) and may be configured to invoke one or more actions or applications. In one example, the link may be configured to invoke a website, which may include causing a browser or other viewing application running on client device 112 or another device to access and display the website and/or causing the website to perform one or more actions (e.g., displaying or submitting information). In another example, the link may be configured to invoke an application running on client device 112 or a separate device.

The link may include a first set of information and a second set of information. For example, the first set of information may include identifier information. The first set of information may include an abstract username generated by the processor after the sending device 105 enters the communication field. For example, abstract identifier information may be generated for each transaction in the form of, for example, a dynamically generated URL. Without limitation, identification information can be generated on the card by combining a unique identifier with one or more variables (e.g., a counter, one or more cryptographic algorithms, and/or any combination thereof). For example, one or more cryptographic algorithms may include encryption techniques such as public-key or private-key encryption, which will also be known to a server such as server 125 for authentication. Without limitation, exemplary symmetric key algorithms may include symmetric key encryption such as DES, triple DES, or AES. Without limitation, exemplary asymmetric key algorithms may include asymmetric public-key encryption, digital signature algorithms, or RSA. For example, the second set of information may include user information such as cardholder information (e.g., account owner name, account number, expiration date, card verification value). The first application 110 may be configured to identify the user associated with the first device 112 by activating one or more actions based on the link. The one or more actions can be configured to request confirmation of a third set of information associated with the data transfer. The third set of information may include at least one selected from the groups of quantity, digital assets, and recipient information.

In some examples, at least one action may include launching a website configured to identify a user associated with the first device 112. Server 125 may be configured to identify a user associated with the first device 112 by selecting at least one from a set of device fingerprints of the first device 112 and cookies stored on the first device 112. Non-limitingly, device fingerprint identification may be based on at least one from a set of device configuration, device memory, device screen size, device operating system version, installed applications, telephone carrier provider, third-party cookies of the website, telephone number tracking obtained through a mobile network operator (MNO), browser type, browser language, IP address, and/or any combination thereof. The website may be configured to display a second set of information and a third set of information on the first device 112. After successfully identifying the user or owner of the first device 112, the website may be configured to load predetermined information including the second set of information. In some examples, this predetermined information may include user information such as cardholder information. In some examples, this information may be embedded in and transmitted via an NDEF URL when the transmitting device 105 enters the communication field. The website can also be configured to allow specifying quantities, including but not limited to monetary amounts. The website can also be configured to submit a transmission via a selection button. Furthermore, the website can be configured to adjust the recipient and/or transferor of the data transmission. For example, the directionality of the data transmission can be reversed. In some examples, by adjusting the directionality of the transmission, such as from transferor to recipient or from recipient to transferor, a corresponding message, such as a push notification or email, can be generated to indicate confirmation of the desired reversal of transmission. In some examples, this corresponding message can be displayed by the first application 110 and/or the second application 115.

The second application 115 can be configured to send one or more responses associated with authentication and confirmation of the third set of information to complete data transfer. In some examples, the second application 115 can be configured to receive a notification from the first application 110 that requires one or more responses associated with confirmation of the third set of information. The second application 115 can be configured to perform one or more authentication communications associated with confirmation of the third set of information. For example, data transfer can be completed after the received responses have been verified and the third set of information associated with data transfer has been confirmed. In some examples, one or more authentication communications may include at least one selected from the group of biometric communications and login communications.

In other examples, at least one action may include a first application 110 requesting one or more login credentials. The first application 110 may be configured to deeply link to a screen containing a second set of information and a third set of information upon submission of the requested login credentials and upon authentication of the login credentials. For example, the deep link described herein may refer to an NDEF URL being configured to link to a specific, generally searchable or indexed section of web content on a website, rather than the website's homepage. The third set of information may include at least one selected from the groups of quantity, digital assets, and recipient information. In some examples, a second application 115 may be configured to receive a notification requesting one or more responses associated with confirmation of the third set of information. The second application 115 may be configured to perform one or more authentication communications associated with confirmation of the third set of information. In some examples, one or more authentication communications may include authentication input. Exemplary authentication input may include, but is not limited to, input of login credentials, account information, security information, biometric information, and combinations thereof (e.g., entering a username, password, account number, security code, one-time password, answer to a security question, fingerprint, facial scan, retinal scan, voice recognition, and logging into an application or website associated with an account or issuing institution).

Devices associated with the user of sending device 105 (such as a second application 115 of a second device 117 associated with a cardholder) can be configured to receive notifications, including but not limited to push notifications or emails, which serve as a secondary confirmation of amount, digital assets, and the recipient of the transfer. To confirm the data transfer, the cardholder can select a button to take an action in response to a requested authentication communication, such as providing authentication input. After authenticating login via the received authentication input, the transfer can be confirmed. In this way, after confirmation, peer-to-peer transfers will be used for the authenticated user because the transfer is to a known recipient.

In some examples, peer-to-peer transfers may include the issuance of credit. This credit may be subject to one or more spending restrictions. For example, one or more spending restrictions may include time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, the issuance of credit may be associated with one or more rewards and/or points. For example, if credit is used at a specific merchant (e.g., a restaurant) at a specific time (e.g., a weekend), rewards and/or points may be issued and thus added to the user's rewards or loyalty points program. For example, rewards and/or points may be tailored to each of the transferor and transferee and may be adjusted based on the redemption of credit. For example, if credit is used at a specific merchant (e.g., a restaurant) and/or at a specific time (e.g., a weekend), rewards and/or points may be issued and thus added to the user's rewards or loyalty points program. The transferor may still accumulate rewards and/or points when the recipient or transferee uses the credit.

In other examples, peer-to-peer delivery may include the delivery of one or more digital assets. Without limitation, digital assets may include images or documents. Without limitation, the format type of the digital asset may include at least one selected from the group consisting of static image files (e.g., JPEG, PNG, SVG), static document files (e.g., PDF, PSD), animated files (e.g., GIF, SWF), and web code (e.g., HTML, CSS, JavaScript). One or more digital assets may be identified for delivery. For example, digital assets can be securely transmitted by launching a website and uploading the identified digital assets for delivery. In another example, digital assets can be securely transmitted by opening an application or launching an email client in which the identified digital assets may be included as attachments. In yet another example, digital assets may be identified as part of a Uniform Resource Locator (URL) sent for retrieving the identified digital assets.

In other examples, peer-to-peer transfers may include money transfers such as cash transfers. Similar to credit issuance, money transfers may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, money transfers may be subject to constraints based on time limits, amount limits, geographic restrictions, merchant type, merchant restrictions, and/or any combination thereof. In some examples, a money transfer may include multiple parts. For example, the first part of a money transfer may be transmitted before the second part. Any part of a money transfer may be transmitted at a predetermined time, including but not limited to a specific day, time, week, month, and/or any combination thereof. In this way, money transfers may be aggregated until the entire money transfer is satisfied.

In other examples, peer-to-peer delivery may include the issuance of virtual gift cards. Similar to the issuance of credit, virtual gift cards may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, virtual gift cards may be subject to time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, peer-to-peer delivery may include multiple portions associated with various amounts of the virtual gift card. For example, the first portion of a peer-to-peer delivery may be transmitted before the second portion. Any portion of the delivery may be transmitted at a predetermined time, including but not limited to a day, a time, a week, a month, and/or any combination thereof.

Figure 2A illustrates one or more transmitting devices 200. Transmitting device 200 may refer to the same or similar components of a transmitting device or contactless card 105, as explained above with respect to Figure 1. Although Figures 2A and 2B show a single instance of the components of transmitting device 200, any number of components may be used.

The sending device 200 can be configured to communicate with one or more components of the system 100. The sending device 200 can include contact-based or contactless cards, which can include payment cards such as credit cards, debit cards, or gift cards issued by a service provider 205 displayed on the front or back of the card 200. In some examples, the contactless card 200 is not a payment card and can include, but is not limited to, ID cards, membership cards, and transportation cards. In some examples, the payment card can include a dual-interface contactless payment card. The contactless card 200 can include a substrate 210, which can include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 200 can have physical characteristics conforming to the ID-1 format of the ISO/IEC 7810 standard, and the contactless card can additionally conform to the ISO/IEC 14443 standard. However, it should be understood that the contactless card 200 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of contactless cards in payment cards.

The contactless card 200 may also include identification information 215 displayed on the front and/or back of the card, and a contact pad 220. The contact pad 220 may be configured to establish contact with another communication device, including but not limited to user equipment, smartphones, laptops, desktop computers, or tablet computers. The contactless card 200 may also include processing circuitry, an antenna, and other components not shown in FIG. 2A. These components may be located behind the contact pad 220 or elsewhere on the substrate 210. The contactless card 200 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card (not shown in FIG. 2A).

As shown in Figure 2B, the contact pad 220 of Figure 2A may include processing circuitry 225 for storing and processing information. This processing circuitry 225 includes a microprocessor 230 and a memory 235. It should be understood that the processing circuitry 225 may include additional components, including a processor, memory, error and parity/CRC checksum, data encoder, anti-collision algorithm, controller, command decoder, security primitives, and tamper-proof hardware, as required to perform the functions described herein.

Memory 235 can be a read-only memory, a write-once-read-many memory, or a read/write memory, such as RAM, ROM, and EEPROM, and the contactless card 200 may include one or more of these memories. Read-only memory can be factory-programmable or one-time programmable. One-time programmability provides the opportunity to write once and then read many times. Write-once/read-many memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritten, but it may be read multiple times. Read/write memory may be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

Memory 235 can be configured to store one or more applets 240, one or more counters 245, and a customer identifier 250. The one or more applets 240 may include one or more software applications configured to execute on one or more contactless cards (such as Java Card applets). However, it should be understood that applet 240 is not limited to Java Card applets, but can be any software application that can operate on a contactless card or other device with limited memory. The one or more counters 245 may include numeric counters sufficient to store integers. The customer identifier 250 may include a unique alphanumeric identifier assigned to a user of the contactless card 200, and this identifier can distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 250 can identify a customer and the account assigned to that customer, and can also identify the contactless card associated with that customer's account.

The processor and memory elements of the foregoing exemplary embodiments are described with reference to the contact pad, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the pad 220, or completely separated from the pad 220, or implemented as other elements besides the processor 230 and memory 235 elements located within the contact pad 220.

In some examples, the contactless card 200 may include one or more antennas 255. These antennas 255 may be placed within the contactless card 200 and surrounding the processing circuitry 225 of the contact pad 220. For example, the antennas 255 may be integrated with the processing circuitry 225, and may be used in conjunction with an external boost coil. As another example, the antennas 255 may be external to the contact pad 220 and the processing circuitry 225.

In one embodiment, the coil of the contactless card 200 can be used as the secondary winding of an air-core transformer. The terminal can communicate with the contactless card 200 by cutting off power or by amplitude modulation. The contactless card 200 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained by one or more capacitors. The contactless card 200 can communicate by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal by interference.

Figure 3 illustrates a method 300 for authenticating data transmission. Figure 3 may refer to the same or similar components of system 100 and the transmitting device 200 of Figures 2A and 2B.

At block 310, method 300 may include sending a link to a first application after one or more processors of the transmitting device enter the communication field. This link includes instructions for execution on the first device, is configured to initiate data transmission, and includes a Near Field Communication Data Exchange Format Uniform Resource Locator (URI) comprising identifier data and cardholder data. In some examples, the transmission of the link may occur after the link is dynamically generated. In some examples, the transmitting device may enter the communication field of the client device via one or more gestures selected from a group of taps, swipes, waves, or any combination thereof. In some examples, the user may be identified based on a Mobile Network Operator (MNO) lookup. In other examples, the user may be identified based on one or more cookies associated with a previous account login, such as an account associated with the transmitting device, a separate account associated with the user, and/or other accounts.

The link may include a Near Field Communication Data Exchange Format Uniform Resource Locator (NDEF URL). The link may include a first set of information and a second set of information. The first set of information may include identifier information. For example, the first set of information may include an abstract username generated by the processor after the transmitting device enters the communication field. For example, abstract identification information such as a dynamically generated URL may be generated for each transaction. Without limitation, identification information can be generated on the card by combining a unique identifier with one or more variables (e.g., a counter, one or more cryptographic algorithms, and/or any combination thereof). For example, one or more cryptographic algorithms may include encryption techniques such as public-key or private-key encryption, which will also be known to the authentication server. Without limitation, exemplary symmetric key algorithms may include symmetric key encryption (such as DES, triple DES, or AES). Without limitation, exemplary asymmetric key algorithms may include asymmetric public-key encryption, digital signature algorithms, or RSA. For example, the second set of information may include user information, such as cardholder information. In some examples, the second set of information may include cardholder information (e.g., account owner name, account number, expiration date, card verification value).

At box 320, method 300 may include authenticating a user associated with the first device by activating one or more actions based on a link. The one or more actions may be configured to request confirmation of a third set of information associated with the data transfer. The third set of information may include at least one selected from the groups of quantity, digital assets, and recipient information. In some examples, at least one action may include launching a website configured to identify the user associated with the first device. In other examples, at least one action may include a first application requesting one or more login credentials.

At box 330, method 300 may include sending one or more requests for confirmation of the quantity, digital assets, and recipient data associated with the data transfer. For example, a first application may be configured to receive input indicating confirmation of the quantity (such as amount, digital assets) and recipient data (such as recipient) of the peer-to-peer transfer associated with the third set of information in box 320.

At box 340, method 300 may include receiving one or more notifications based on one or more requests for confirmation of the amount, digital assets, and recipient data associated with the data transfer. A device associated with the sending device user (such as a second application on a second device associated with a cardholder) may be configured to receive notifications, including but not limited to push notifications or emails, which serve as a secondary confirmation of the amount, digital assets, and recipient data.

At box 350, method 300 may include executing one or more login credentials in response to one or more notifications to complete a data transfer. For example, one or more authentication inputs may be received to complete the data transfer. This authentication input may be in response to one or more notifications. To confirm the data transfer, the cardholder can select a button to take an action in response to one or more requests and based on one or more notifications, such as a requested authentication communication including only the authentication input. Exemplary authentication inputs may include, but are not limited to, login credentials, account information, security information, biometric information, and combinations thereof (e.g., entering a username, password, account number, security code, one-time password, answer to a security question, fingerprint, facial scan, retinal scan, voice recognition, and logging into an application or website associated with an account or card issuer). After authenticating the login via the received authentication input, the transfer can be confirmed. Furthermore, the directionality of the data transfer can be reversed. In some examples, by adjusting the directionality of the transfer, such as from transferor to recipient or from recipient to transferor, a corresponding message, such as a push notification or email, can be generated to indicate confirmation of the desired reversal of the transfer. In some examples, this corresponding message may be displayed by a first application and/or a second application. In this way, after confirmation, peer-to-peer transmissions will be used for authenticated users, since the transmission is to a known recipient.

In some examples, peer-to-peer delivery may include issuing credit. This credit may be subject to one or more spending restrictions. For example, one or more spending restrictions may include time restrictions, amount restrictions, geographical restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof.

In some examples, peer-to-peer transfers may be associated with one or more rewards and/or points. For example, rewards and/or points may be tailored to each of the transferor and transferee, and may be based on credit redemption. For instance, rewards and/or points may be awarded and added to a user's rewards or loyalty points program if the credit is used at a specific merchant (e.g., a restaurant) and/or at a specific time (e.g., a weekend). The transferor can still accumulate rewards and/or points as the recipient or transferee uses the credit. In some examples, peer-to-peer transfers may include multiple parts. For example, the first part of a peer-to-peer transfer may be transmitted before the second part. For example, the first part may include one or more rewards, and the second part may include one or more points. Any part of the transfer may be transmitted at a predetermined time, including but not limited to a day, a time, a week, a month, and/or any combination thereof.

In other examples, peer-to-peer transmission may include the transmission of one or more digital assets. Without limitation, the digital asset may include an image or a document. Without limitation, the format type of the digital asset may include at least one selected from the group consisting of static image files (such as JPEG, PNG, SVG), static document files (such as PDF, PSD), animation files (such as GIF, SWF), and web code (such as HTML, CSS, JavaScript). The one or more digital assets may be identified for transmission. For example, a digital asset can be securely transmitted by launching a website and uploading the identified digital asset for transmission. In another example, a digital asset can be securely transmitted by opening an application or launching an email client in which the identified digital asset may be included as an attachment. In yet another example, the digital asset may be a digital asset that can be identified as part of a Uniform Resource Locator (URL), which is sent to retrieve the identified digital asset.

In other examples, peer-to-peer transfers may include money transfers such as cash transfers. Similar to credit issuance, money transfers may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, money transfers may be subject to restrictions based on time limits, amount limits, geographical restrictions, merchant type, merchant restrictions, and/or any combination thereof. In some examples, a money transfer may include multiple parts. For example, the first part of a money transfer may be transmitted before the second part. Any part of a money transfer may be transmitted at a predetermined time, including but not limited to a specific day, time period, week, month, and/or any combination thereof. In this way, money transfers may be aggregated until the entire money transfer is satisfied.

In other examples, peer-to-peer delivery may include the issuance of virtual gift cards. Similar to the issuance of credit, virtual gift cards may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, virtual gift cards may be subject to time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, peer-to-peer delivery may include multiple portions associated with various amounts of virtual gift cards. For example, the first portion of a peer-to-peer delivery may be transmitted before the second portion. Any portion of the delivery may be transmitted at a predetermined time, including but not limited to a day, a time, a week, a month, and/or any combination thereof.

Figure 4 illustrates a method for initiating and authenticating data transmission according to an exemplary embodiment. Figure 4 may be referenced to the same or similar components of system 100, the transmitting device 200 of Figures 2A and 2B, and the method 300 of Figure 3. As shown in Figure 4, peer-to-peer transmission can be initiated by a card entering the communication field of the user equipment and loading a website.

At box 405, method 400 may include the card entering the communication field of a user equipment, including but not limited to via one or more gestures selected from tapping, swiping, waving, or any combination thereof. This communication may include, but is not limited to, NFC. At box 410, method 400 may include loading a website via an NDEF URL to identify the user of the user equipment after the card enters the communication field of the user equipment. In some examples, the card may be configured to send a link to a client application of one or more user equipment devices to initiate data transfer after entering the communication field of box 405. In some examples, the sending of the link may occur after the link is dynamically generated. In some examples, the client application may be associated with a sending device or the issuing entity of the card. In other examples, the client application may not be associated with a sending device or the issuing entity of the card. For example, the client application may be associated with a third-party entity or an entity external to the issuing entity of the sending device or the card.

In some examples, the NDEF URL may include a domain name and an identifier. For example, the link may include abstract identification information, including but not limited to the cardholder's account or user identifier, which is loaded onto the chip during card personalization. For example, the URL may be encoded in the NDEF file during card imprinting. Abstract identification information, such as a dynamically generated URL, can be generated for each transaction. Without limitation, identification information can be generated on the card by combining a unique identifier with one or more variables (e.g., a counter, one or more cryptographic algorithms, and/or any combination thereof). For example, one or more cryptographic algorithms may include encryption techniques such as public-key or private-key encryption, which will also be used by the authentication server. Without limitation, exemplary symmetric key algorithms may include symmetric key encryption (such as DES, triple DES, or AES). Without limitation, exemplary asymmetric key algorithms may include asymmetric public-key encryption, digital signature algorithms, or RSA.

At box 415, method 400 may include identifying a user via device fingerprint, and may be based on, but not limited to, at least one of the following groups: device configuration, device memory, device screen size, device operating system version, installed applications, telephone carrier provider, third-party cookies of websites, phone number tracking via MNO lookup, browser type, browser language, IP address and/or device.

At box 420, the method may include prompting the user to log in to identify the user if the website cannot identify the user via cookies or device fingerprints. For example, if the website cannot successfully identify the user via at least one selected from the group of operating system, browser type, browser language, and IP address, the user may receive a notification generated by the server indicating an unsuccessful attempt, and/or the application may prompt the user to enter login information to successfully identify the user, and respond to the unsuccessful attempt notification.

At box 425, method 400 may include loading pre-registration information after user identification. In some examples, the pre-registration information may be any information associated with the cardholder that has been filled in or otherwise provided on the website via direct embedding in the NDEF URL. The website may also be configured to submit a transfer via a selection button. Furthermore, the website may be configured to adjust the recipient and/or transferor of the data transfer. For example, the directionality of the data transfer may be reversed. In some examples, by adjusting the directionality of the transfer, such as from transferor to recipient or from recipient to transferor, a corresponding message, such as a push notification or email, may be generated to indicate confirmation of the desired reversal of the transfer. In some examples, this corresponding message may be displayed by a first application and/or a second application.

At box 430, method 400 may include entering the amount and recipient data for the peer-to-peer transfer before the transfer is submitted. At box 435, method 400 may include receiving an email or push notification to confirm the peer-to-peer transfer. For example, a cardholder may be associated with a user device. An application on the user device may be configured to receive notifications. At box 440, in response to receiving a notification, the notification may be opened or displayed to prompt login or request biometric input to verify that the user initiated the transfer. In some examples, the prompt may include a request for one or more authentication inputs. For example, exemplary authentication inputs may include, but are not limited to, login credentials, account information, security information, biometric information, and combinations thereof (e.g., entering a username, password, account number, security code, one-time password, answer to a security question, fingerprint, facial scan, retinal scan, voice recognition, and logging into an application or website associated with the account or card issuer).

At box 445, after verifying one or more authentication inputs, a peer-to-peer transfer between the cardholder and the second user can be scheduled. In some examples, the peer-to-peer transfer can be scheduled at a predetermined time, such as a scheduled day, time, week, month, and/or year. In other examples, the peer-to-peer transfer can be scheduled instantly. In this way, the peer-to-peer transfer can be scheduled or placed in a transaction queue without having to identify individuals or download and register different applications. Furthermore, the direction of data transfer can be reversed. In some examples, by adjusting the directionality of the transfer, such as from sender to receiver or from receiver to sender, a corresponding message, such as a push notification or email, can be generated to indicate confirmation of the desired reversal of the transfer. In some examples, this corresponding message can be displayed by the first application and/or the second application. In this way, after confirmation, the peer-to-peer transfer will be used for the authenticated user because the transfer is to a known receiver.

In some examples, peer-to-peer transfers may include the issuance of credit. This credit may be subject to one or more spending restrictions. For example, one or more spending restrictions may include time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, the issuance of credit may be associated with one or more rewards and/or points. For example, if credit is used at a specific merchant (e.g., a restaurant) at a specific time (e.g., a weekend), rewards and/or points may be issued and thereby added to a user's rewards or loyalty points program. For example, rewards and/or points may be tailored to each of the transferor and transferee and may be adjusted based on the redemption of credit. For example, if credit is used at a specific merchant (e.g., a restaurant) and/or at a specific time (e.g., a weekend), rewards and/or points may be issued and thereby added to a user's rewards or loyalty points program. The transferor can still accumulate rewards and/or points when the recipient or transferee uses the credit.

In other examples, peer-to-peer delivery may include the delivery of one or more digital assets. Without limitation, digital assets may include images or documents. Without limitation, the format type of the digital asset may include at least one selected from the group consisting of static image files (such as JPEG, PNG, SVG), static document files (such as PDF, PSD), animated files (such as GIF, SWF), and web code (such as HTML, CSS, JavaScript). One or more digital assets may be identified for delivery. For example, digital assets can be securely transmitted by launching a website and uploading the identified digital assets for delivery. In another example, digital assets can be securely transmitted by opening an application or launching an email client in which the identified digital assets may be included as attachments. In yet another example, digital assets may be identified as part of a Uniform Resource Locator (URL) sent for retrieving the identified digital assets.

In other examples, peer-to-peer transfers may include money transfers such as cash transfers. Similar to credit issuance, money transfers may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, money transfers may be subject to restrictions based on time limits, amount limits, geographical restrictions, merchant type, merchant restrictions, and/or any combination thereof. In some examples, a money transfer may include multiple parts. For example, the first part of a money transfer may be transmitted before the second part. Any part of a money transfer may be transmitted at a predetermined time, including but not limited to a specific day, time, week, month, and/or any combination thereof. In this way, money transfers may be aggregated until the entire money transfer is satisfied.

In other examples, peer-to-peer delivery may include the issuance of virtual gift cards. Similar to the issuance of credit, virtual gift cards may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, virtual gift cards may be subject to time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, peer-to-peer delivery may include multiple portions associated with various amounts of virtual gift cards. For example, the first portion of a peer-to-peer delivery may be transmitted before the second portion. Any portion of the delivery may be transmitted at a predetermined time, including but not limited to a day, once, a week, a month, and/or any combination thereof.

Figure 5 illustrates another method for initiating and authenticating data transmission according to an exemplary embodiment. Figure 5 may refer to the same or similar components of system 100, the transmitting device 200 of Figures 2A and 2B, the method 300 of Figure 3, and the method 400 of Figure 4. As shown in Figure 5, point-to-point transmission can be initiated by the card entering the communication field of the user equipment and deeply linking it to the application.

At box 505, the method may include the card entering the communication field of the user device, including but not limited to via one or more gestures selected from tapping, swiping, waving, or any combination thereof. This communication may include, but is not limited to, Near Field Communication (NFC). At box 510, the method may include launching an application on the user device via a Near Field Communication Data Exchange Format (NDEF URL) after the card enters the communication field of the user device. In some examples, the transmission of the NDEF URL may occur after the NDEF URL is dynamically generated. In some examples, the application may be associated with the issuing entity of the issuing device. In other examples, the application may not be associated with the issuing entity of the issuing device. For example, the application may be associated with a third-party entity or an entity external to the issuing entity of the issuing device. At box 515, the method may include a deep link to the application on a peer-to-peer transmission screen that includes predefined information. In some examples, the predefined information may be any information associated with the cardholder that has been filled in or is directly embedded in the NDEF URL. In some examples, the application may be configured to prompt the user to log in before the deep link. In other examples, the application may be configured to prompt the user to log in after the deep link. In some examples, the login prior to the deep link may be the same as or different from the login required after the deep link. Furthermore, exemplary authentication input may include, but is not limited to, input of login credentials, account information, security information, biometric information, and combinations thereof (e.g., entering a username, password, account number, security code, one-time password, answers to security questions, fingerprint, facial scan, retinal scan, voice recognition, and logging into an application or website associated with an account or card issuer). At box 520, the method may include entering the amount and recipient data for the peer-to-peer transfer before submitting the transfer. At box 525, the method may include receiving an email or push notification to confirm the peer-to-peer transfer. For example, a cardholder may be associated with a user device. The user device or its application may be configured to receive notifications. At box 530, in response to receiving a notification, the notification may be opened or displayed to prompt authentication input to verify that the user initiated the transfer. At box 535, after verification, a peer-to-peer transfer between the cardholder and a second user may be scheduled. In some examples, the peer-to-peer transfer may be scheduled at a predetermined time, such as a predetermined day, time, week, month, and/or year. In other examples, peer-to-peer transfers can be scheduled on the fly. In this way, peer-to-peer transfers can be scheduled or placed in a transaction queue without requiring identification of individuals or downloading and registering different applications. Furthermore, the direction of data transfer can be reversed. In some examples, by adjusting the directionality of the transfer, such as from sender to receiver or from receiver to sender, a corresponding message, such as a push notification or email, can be generated to indicate confirmation of the desired reversal of the transfer. In some examples, this corresponding message can be displayed by a first application and/or a second application. In this way, after confirmation, the peer-to-peer transfer will be used for an authenticated user because the transfer is to a known receiver.

In some examples, peer-to-peer transfers may include the issuance of credit. This credit may be subject to one or more spending restrictions. For example, one or more spending restrictions may include time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, the issuance of credit may be associated with one or more rewards and/or points. For example, if credit is used at a specific merchant (e.g., a restaurant) at a specific time (e.g., a weekend), rewards and/or points may be issued and thereby added to a user's rewards or loyalty points program. For example, rewards and/or points may be tailored to each of the transferor and transferee and may be adjusted based on the redemption of credit. For example, if credit is used at a specific merchant (e.g., a restaurant) and/or at a specific time (e.g., a weekend), rewards and/or points may be issued and thereby added to a user's rewards or loyalty points program. The transferor can still accumulate rewards and/or points when the recipient or transferee uses the credit.

In other examples, peer-to-peer delivery may include the delivery of one or more digital assets. Without limitation, digital assets may include images or documents. Without limitation, the format type of the digital asset may include at least one selected from the group consisting of static image files (such as JPEG, PNG, SVG), static document files (such as PDF, PSD), animated files (such as GIF, SWF), and web code (such as HTML, CSS, JavaScript). One or more digital assets may be identified for delivery. For example, digital assets can be securely transmitted by launching a website and uploading the identified digital assets for delivery. In another example, digital assets can be securely transmitted by opening an application or launching an email client in which the identified digital assets may be included as attachments. In yet another example, digital assets may be identified as part of a Uniform Resource Locator (URL) sent for retrieving the identified digital assets.

In other examples, peer-to-peer transfers may include money transfers such as cash transfers. Similar to credit issuance, money transfers may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, money transfers may be subject to restrictions based on time limits, amount limits, geographical restrictions, merchant type, merchant restrictions, and/or any combination thereof. In some examples, a money transfer may include multiple parts. For example, the first part of a money transfer may be transmitted before the second part. Any part of a money transfer may be transmitted at a predetermined time, including but not limited to a specific day, time, week, month, and/or any combination thereof. In this way, money transfers may be aggregated until the entire money transfer is satisfied.

In other examples, peer-to-peer delivery may include the issuance of virtual gift cards. Similar to the issuance of credit, virtual gift cards may be subject to one or more spending restrictions and/or restrictions imposed by one or more merchants. For example, virtual gift cards may be subject to time restrictions, amount restrictions, geographic restrictions, merchant type restrictions, merchant restrictions, and/or any combination thereof. In some examples, peer-to-peer delivery may include multiple portions associated with various amounts of virtual gift cards. For example, the first portion of a peer-to-peer delivery may be transmitted before the second portion. Any portion of the delivery may be transmitted at a predetermined time, including but not limited to a day, a time, a week, a month, and/or any combination thereof.

In this specification, references are made to types of resource locators, such as URL, NDEF URL, IRL, URI, and URN. However, it should be understood that these references are exemplary, and this disclosure includes, but is not limited to, the types of resource locators mentioned.

It should also be noted that the systems and methods described herein can be tangibly embodied in one or more physical media, such as, but not limited to, optical discs (CDs), digital versatile optical discs (DVDs), floppy disks, hard disks, read-only memory (ROM), random access memory (RAM), and other physical media capable of storing data. For example, data storage devices may include random access memory (RAM) and read-only memory (ROM), which can be configured to access and store data and information, as well as computer program instructions. Data storage devices may also include storage media or other suitable types of memory (e.g., such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical discs, floppy disks, hard disks, removable magnetic tape cassettes, flash drives, any type of tangible and non-transient storage media), in which files including operating systems, applications including, for example, web browser applications, email applications and/or other applications, and data files can be stored. Data storage in network-enabled computer systems can include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases, such as databases created and maintained using software from, for example, a company, Excel files, Access files, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online storage or cloud storage), or any other storage mechanism. Furthermore, the accompanying drawings illustrate various components (e.g., servers, computers, processors, etc.). Functions described as performing at various components can be performed at other components, and the various components can be combined or separated. Other modifications are also possible.

Various embodiments have been described in the foregoing description with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented without departing from the broader scope of this disclosure as set forth in the following claims. Therefore, the description and drawings should be considered illustrative rather than restrictive.

Claims (20)

1. An authenticated data transmission system, comprising: Contactless cards, including processors and memory, Upon entering the communication field, the processor is configured as follows: Dynamically generate Uniform Resource Locators (URLs), wherein the URLs include: The first set of information includes abstract identifier information, and The second set of information includes user information; and Send the URL to initiate data transmission; and The data transmission is completed upon verification of the received response and confirmation of a third set of information associated with the data transmission. 2. The authenticated data transmission system of claim 1, wherein one or more actions are configured to identify a user based on the link. 3. The certified data transmission system of claim 2, wherein at least one of the one or more actions includes launching a website configured to identify a user associated with the first device. 4. The authenticated data transmission system of claim 3, wherein the user associated with the first device is identified by selecting at least one from the group of device fingerprint and cookie. 5. The authenticated data transmission system according to claim 4, wherein login information is requested when an unsuccessful identification is determined. 6. The certified data transmission system of claim 4, wherein the website is configured to display the second set of information and the third set of information. 7. The certified data transmission system of claim 6, wherein the notification includes one or more responses associated with confirmation of the third set of information. 8. The authenticated data transmission system of claim 7, wherein one or more authentication communications associated with the confirmation of the third set of information are performed, the one or more authentication communications including at least one selected from the group of biometric communications and login communications. 9. The authenticated data transmission system of claim 1, wherein the first set of information includes an abstract username generated by the processor after the contactless card enters the communication field. 10. The certified data transmission system of claim 1, wherein the link includes a near-field communication data exchange format uniform resource locator. 11. The certified data transmission system of claim 3, wherein the first device comprises at least one selected from the group consisting of mobile devices, wearable devices, and automated service terminals. 12. The authenticated data transmission system of claim 2, wherein at least one of the one or more actions includes requesting one or more login credentials. 13. The authenticated data transmission system of claim 12, wherein a deep link to a screen including a second set of information and a third set of information is performed when submitting the requested one or more login credentials and when authenticating the one or more login credentials. 14. The certified data transmission system of claim 1, wherein the third set of information includes at least one selected from the group consisting of quantity, digital assets, and recipient information. 15. The certified data transmission system of claim 14, wherein the notification includes the one or more responses associated with confirmation of the third set of information. 16. The authenticated data transmission system of claim 15, wherein one or more authentication communications associated with the confirmation of the third set of information are performed, the one or more authentication communications including at least one selected from the group of biometric communications and login communications. 17. The certified data transmission system of claim 1, wherein the data transmission is scheduled at a predetermined time. 18. A method for authenticating data transmission, comprising: After one or more processors of the transmitting device enter the communication field, a link is dynamically generated, the link including a near-field communication data exchange format uniform resource locator, the near-field communication data exchange format uniform resource locator including identifier data and user data; The link is sent to a first application, which includes instructions for execution on the first device, to initiate data transmission; Authenticate the user associated with the first device by activating one or more actions based on the link; Send one or more requests for confirmation of the quantity and recipient data associated with the data transmission; Receive one or more notifications, said one or more notifications based on said one or more requests for confirmation of the quantity and recipient data associated with said data transmission; and Execute one or more login credentials in response to the one or more notifications to complete the data transfer. 19. The method of claim 18, wherein at least one of the one or more actions includes launching a website configured to identify a user associated with the first device. 20. A computer-readable non-transient medium comprising computer-executable instructions, wherein, when executed by a processor, the instructions are executed comprising the following steps: After the contactless card enters the communication field, a link is dynamically generated. The link includes a first set of information and a second set of information. The first set of information includes identifier information, and the second set of information includes user information. The link is sent to a first application, which includes instructions for execution on the first device, to initiate data transmission; Identifying a user associated with the first device by activating one or more actions based on the link, wherein the one or more actions are configured to request confirmation of a third set of information associated with the data transmission; and One or more responses are sent based on the authentication of the third set of information in order to complete the data transmission.