An accurate representation of the graphical user interface that allows data transfer

Abstract

A system, method, and computer-readable medium for providing an accurate image of a card. An application executing on a mobile device can receive account authentication information, determine a first contactless payment card associated with the account, and determine a card manufacturer identifier (CMID) for the card. The application can receive multiple metadata attributes of the first contactless payment card and one or more images of the first image from a digital asset management system based on the CMID. The application can determine a first orientation of the card that enables data transfer between the card and the mobile device based on the metadata attributes and attributes of the mobile device. The application can select a first image of the card. The application can generate a graphical user interface (GUI) that includes the first image and an indication of tapping the card against the mobile device according to the first orientation.

Description

[Technical Field]

[0001] This application claims priority to U.S. patent application Ser. No. 16 / 863,401, entitled "Precise Image of Graphical User Interface Enabling Data Transfer," filed April 30, 2020. The contents of the aforementioned patent application are incorporated herein by reference in their entirety. The present embodiments relate generally to computer software, and more particularly to providing accurate images in a graphical user interface to enable data transfer. [Background technology]

[0002] Cardholders (e.g., credit card holders, bank card holders, etc.) often use computer-based applications to perform various account-related activities. In many cases, users may be required to tap their card to a computing device to enable data transfer. However, differences in devices, cards, and other factors may require different orientations and / or placements of the card relative to the computing device to enable data transfer. Summary of the Invention

[0003]

[0003] Embodiments disclosed herein provide a system, method, article of manufacture, and computer-readable medium for providing an accurate image of a contactless card in a graphical user interface on a computing device. According to one example, an application executing on a processor may receive authentication information for an account. The application may determine a first contactless payment card associated with the account and a card manufacturer identifier (CMID) of the first contactless payment card. The application may receive, from a digital asset management system, multiple images of the first payment card and multiple metadata attributes of the first contactless payment card based on the CMID. The application may determine, based on the multiple metadata attributes of the first contactless payment card and multiple attributes of the mobile device, a first orientation of the first contactless payment card that enables near-field communication (NFC) data transfer between the first contactless payment card and the mobile device. The application may select a first image from multiple images representing the first contactless payment card according to the first orientation. The application may generate a graphical user interface (GUI) representing a first image of the plurality of images of the first contactless payment card and an indication of tapping the first contactless payment card against the mobile device according to the first direction, and display the GUI on the display. [Brief explanation of the drawings]

[0004] [Figure 1A] 1A and 1B show an example of a contactless card. [Figure 1B] 1A and 1B show an example of a contactless card.

[0005] [Figure 2A] 2A-2C illustrate an embodiment of a system that provides an accurate image of a contactless card in a graphical user interface to enable data transfer. [Figure 2B]2A-2C illustrate an embodiment of a system that provides an accurate image of a contactless card in a graphical user interface to enable data transfer. [Figure 2C] 2A-2C illustrate an embodiment of a system that provides an accurate image of a contactless card in a graphical user interface to enable data transfer.

[0006] [Figure 3A] 3A-3B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device. [Figure 3B] 3A-3B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device.

[0007] [Figure 4A] 4A-4B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device. [Figure 4B] 4A-4B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device.

[0008] [Figure 5A] 5A-5B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device. [Figure 5B] 5A-5B show an example of a graphical user interface that includes an accurate image of a contactless card to enable data transfer with a computing device.

[0009] [Figure 6] FIG. 6 illustrates one embodiment of the first logic flow.

[0010] [Figure 7] FIG. 7 illustrates one embodiment of the second logic flow.

[0011] [Figure 8] FIG. 8 illustrates one embodiment of a computing architecture. DETAILED DESCRIPTION OF THE INVENTION

[0012] Embodiments disclosed herein provide an accurate image of a payment card for use in a graphical user interface (GUI) on a computing device based at least in part on payment card metadata. The accurate image of the payment card in the GUI can assist a user in orienting the payment card relative to the computing device in a manner that enables data transfer between the payment card and the computing device. Generally, when a payment card is manufactured, it may be assigned a unique card manufacturer identifier (CMID) that uniquely identifies the card. Additionally, one or more images of the card (and / or one or more base images of a type of card) along with metadata attributes that describe the card may be stored in a digital asset management (DAM) system.

[0013] When a user logs into their account with an application, the application may determine the CMID of one or more cards associated with the account. The application may then use the CMID to query the DAM system and receive one or more images of the card and metadata attributes of the card. The application may further determine one or more attributes of the computing device on which the application is executed. Based on the card attributes and / or device attributes, the application may determine a card orientation (e.g., a front-on orientation) that will result in optimal data transfer between the card and the device (compared to other card orientations). The application may then select at least one image of the card received from the DAM system that represents the card in the determined orientation (e.g., a front-on orientation). The application may then generate a GUI using the image of the selected card. The GUI may further indicate that the image of the selected card is brought within communication range of the computing device (e.g., tapping the card while facing forward against the screen of the computing device). This may facilitate data transfer between the card and the computing device without requiring multiple attempts to initiate the data transfer.

[0014] Additionally, if a card base image is selected, additional data may be overlaid on the base image to approximate the actual physical card. For example, the account holder name, card number, expiration date, security code (CVV), etc. may be overlaid on the card base image. One or more logos may also be overlaid on the card based on logos depicted on the physical card. Furthermore, other auxiliary elements may be depicted in the GUI. For example, dashed guidelines may outline where the card should be placed relative to the computing device.

[0015] As another example, a camera on a computing device may be used to identify different characteristics of a physical card held by a user. For example, the camera may capture an image of the physical card, and an application may analyze the captured image to perform additional functions. In one embodiment, the color of the physical card depicted in the image may be used to determine whether the user is using the correct card for a requested operation in the application. For example, if a user attempts to transfer funds using a first card with metadata attributes indicating a red card, the image may depict a blue card. This color difference may enable the application to notify the user that an unauthorized card is being used. As another example, a graphical marker may be written on the card. In some embodiments, the graphical marker may be invisible to the human eye but may be detected by a camera. The graphical marker may be used to obtain different attributes of the card. For example, the graphical marker may be a matrix barcode directed to the card's uniform resource locator (URL) in the DAM system. In this way, the application can determine the card's attributes and, for example, whether the user is using the correct card.

[0016] Advantageously, the presently disclosed embodiments improve graphical user interfaces by providing an accurate image of a particular card in the GUI. Use of the accurate image of the card can provide an optimal orientation of the card relative to the computing device, thereby enabling faster and more reliable wireless data transfer between the card and the device compared to other orientations of the card / device. Similarly, use of the accurate image to provide an optimal orientation of the card relative to the computing device can enable data transfers that are not possible in other orientations (e.g., where data transfer is limited due to one or more other orientations). Doing so can improve the performance of the computing device by requiring less power and other resources when communicating with the card.

[0017] To generally refer to the notation and nomenclature used herein, one or more portions of the detailed descriptions which follow may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0018] Further, these operations are often referred to in terms, such as adding or comparing, that are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein forming part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein written in accordance with the teachings herein, and / or apparatuses specially constructed for the required purpose or digital computers. Various embodiments also relate to apparatuses or systems for performing these operations. These apparatuses may be specially constructed for the required purpose. The required structure for various of these machines will be apparent from the description given.

[0019] Referring now to the drawings, like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It will be apparent, however, that the novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. It is intended to cover all modifications, equivalents, and alternatives falling within the scope of the claims.

[0020] FIG. 1A illustrates a contactless card 101, which may include a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 may be issued by a service provider 109, with the card's signature displayed on the front or back of the card. In some examples, the contactless card 101 may be an identification card, independent of a payment card, including, but not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 101 may include a substrate 110, which may include a single layer or one or more laminates composed of plastic, metal, and other materials. Examples of substrates include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, biodegradable materials, and the like. In some examples, the contactless card 101 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard; the contactless card may otherwise conform to the ISO / IEC 14443 standard. However, it will be understood that contactless cards 101 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0021] Contactless card 101 may also include identification information 115 displayed on the front and / or back of the card, and a contact pad 120. Contact pad 120 may be configured to establish contact with another communication device, such as a user device, smartphone, laptop, desktop, or tablet computer. Contactless card 101 may also include processing circuitry, an antenna, and other components not shown in FIG. 1A. These components may be located behind contact pad 120 or elsewhere on substrate 110. Contactless card 101 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 1A).

[0022] 1B, contact pad 120 of contactless card 101 may include processing circuitry 125 for storing and processing information, including microprocessor 130 and memory 102. It will be understood that processing circuitry 125 may include additional components such as processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware necessary to perform the functions described herein.

[0023] The memory 102 may be read-only memory, write-once-read-many memory, or read / write memory, e.g., RAM, ROM, EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be factory programmable as read-only, or it may be one-time programmable. One-time programmable provides the opportunity to write once and read multiple times. Write-once / read-multiple memory can be programmed at any time after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but it can be read any number of times. Read / write memory may be programmed and reprogrammed any number of times after leaving the factory. Read / write memory can be read any number of times after leaving the factory.

[0024] Memory 102 may be configured to store one or more applets 103, a private key 104, encrypted data 105, one or more customer (or user) identifiers (IDs) 107, and a card manufacturing ID (CMID) 108. In some embodiments, CMID 108 is not stored in memory 102. One or more applets 103 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it will be understood that applet 103 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device having limited memory. Customer ID 107 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, which may distinguish a contactless card user from other contactless card users. In some examples, customer ID 107 may identify both the customer and the account assigned to that customer and may further identify the contactless card associated with the customer's account. In some embodiments, applet 103 may use customer ID 107 as input to a cryptographic algorithm using private key 104 to generate encrypted data 105 .

[0025] Although the processor and memory elements of the example embodiments described above are described with reference to contact pads, the present disclosure is not limited thereto, and it will be understood that these elements may be implemented external to, or entirely separate from, the pads 120, or as additional elements in addition to the processor 130 and memory 102 elements located within the contact pads 120.

[0026] In some examples, contactless card 101 may include one or more antennas 155. One or more antennas 155 may be disposed within contactless card 101 and around processing circuit 125 of contact pad 120. For example, one or more antennas 155 may be integral with processing circuit 125, or one or more antennas 155 may be used in conjunction with an external booster coil. As another example, one or more antennas 155 may be external to contact pad 120 and processing circuit 125.

[0027] In embodiments, the coil of contactless card 101 may function as the secondary of an air-core transformer. The terminal may communicate with contactless card 101 by cutting power or performing amplitude modulation. Contactless card 101 may infer data transmitted from the terminal using gaps in the contactless card's power connection, which may be maintained functionally via one or more capacitors. Contactless card 101 may also return communication by switching or modulating the load on the contactless card's coil. Load modulation may be detected by interference with the terminal's coil. More generally, using antenna 155, processing circuitry 125, and / or memory 102, contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0028] As described above, contactless card 101 may be built on a software platform capable of running on a smart card or other device with limited memory, such as JavaCard, on which one or more applications or applets may be securely executed. An applet may be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may respond to one or more requests, such as a near-field data exchange request, from a reader, such as a mobile NFC reader (e.g., card reader 218 of device 210 in FIGS. 2A-2C), and generate an NDEF message consisting of a cryptographically secure OTP encoded as an NDEF text tag.

[0029] In some embodiments, contactless card 101 may include one or more locations associated with optimal placement relative to a card reader to enable data transfer. In some embodiments, the one or more optimal locations may include processing circuitry 125, contact pad 120, antenna 155, coil, or some other location on the surface of contactless card 101. For example, returning to FIG. 1A , location 111 may be one optimal location for tapping contactless card 101 into a card reader. However, because different materials may be used to manufacture a given contactless card 101, location 111 may vary between different contactless cards 101. In some embodiments, location 111 may be stored as a metadata attribute of contactless card 101 (or type of contactless card), for example, in DAM 225 of FIG. 2A . As shown, contactless card 101 may further include graphical marker 112. In some embodiments, graphical marker 112 is invisible to the human eye but may be detected by a camera or other scanning device. The marker 112 may include any type of marker, such as a matrix barcode, a matrix code, a fiducial marker, etc. The marker 112 may be used to encode metadata attributes of the contactless card 101, such as the card type, one or more optimal positions 111, the material used to manufacture the contactless card 101, etc.

[0030] FIG. 2A illustrates a schematic diagram of an example system 200 consistent with disclosed embodiments. As illustrated, the system 200 includes one or more contactless cards 101, one or more mobile computing devices 210, and a server 220. As illustrated, the contactless cards 101 may include one or more communication interfaces, such as a radio frequency identification (RFID) chip, configured to communicate with the devices 210 via NFC, EMV standards, or other short-range protocols for wireless communication. While NFC is used as an example of a communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as EMV standards, Bluetooth, and / or Wi-Fi. The mobile devices 210 represent any type of network-enabled computing device, such as a smartphone, tablet computer, wearable device, laptop, portable gaming device, etc. The server 220 represents any type of computing device, such as a server, workstation, computing cluster, cloud computing platform, virtualized computing system, etc.

[0031] The computing device 210 and the server may be under the control of an operating system (OS) (not shown). Examples of operating systems include the Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the memory 211 of the computing device 210 includes an account application 213. The account application 213 allows a user to perform various account-related operations, such as viewing account balances, purchasing items, processing payments, account selection, transferring balances, activating contactless cards 101, and generating virtual account numbers associated with contactless cards 101. In some embodiments, a user may authenticate using authentication credentials to access certain features of the account application 213. For example, the authentication credentials may include a username and password, biometric credentials (e.g., fingerprint, Face ID, etc.), etc.

[0032] As shown, the memory 222 of the server 220 includes an authentication application 223, a data store 224 of account data, and a digital asset management (DAM) system 225. The authentication application 223 may interface with the account application 213. For example, as described in more detail below, the authentication application 223 may authenticate encrypted data 105 generated by a contactless card 101 based on a copy of a private key 104 and a customer ID 107 locally accessible to the server 220. The account data 224 generally stores account-related information for each of multiple users. For example, the account data 224 may indicate one or more contactless cards 101 associated with each account and the CMID of each card 101. The DAM system 225 stores information indicative of different assets, such as the contactless cards 101.

[0033] As previously mentioned, when a contactless card 101 is manufactured, it may be assigned a CMID 108 that uniquely identifies the card. The CMID 108 may be stored in the account data 224 and / or the associated cardholder's user profile in the DAM system 225. Additionally, one or more images 231 of the card 101 may be stored in the DAM system 225 along with metadata attributes 232 describing the card 101 (e.g., materials used in manufacturing the card, one or more locations relative to optimal wireless data transfer, the physical layout of the contactless card components depicted in FIGS. 1A-1B, one or more known limitations of the card (e.g., the inability to read the card 101 by tapping the back of the card 101 against the device 210), etc.). The image of a given card 101 may be generic to the type of card (e.g., one or more base images of a given type of card if multiple different types of cards exist) and / or an image of the actual physical card 101 itself.

[0034] As described above, a user of the account application 213 can generally attempt to perform any number of operations. In many cases, wireless data transfer between the contactless card 101 and the device 210 may be required to approve an operation, such as generating a one-time virtual account number for the contactless card 101. However, users often use improper orientations of the card 101 and the device 210, which can limit or otherwise slow data transfer between the card 101 and the device 210. For example, a user may attempt to tap the card 101 against the screen of the device 210. However, with some devices and / or some cards 101, NFC data transfer cannot occur when the card 101 is on the screen of the device 210. Instead, in some embodiments, the card 101 must be tapped against the back of the device 210 to enable NFC data transfer. However, the account application 213 may advantageously generate a GUI that accurately depicts the card 101 being tapped against the device 210 in the proper orientation and / or placement. The GUI of the account application 213 may further provide visual markers to assist the user in proper placement and orientation of the card 101 relative to the device 210. Doing so may improve data transfer capabilities and / or data transfer speeds between the card 101 and the device 210.

[0035] To generate a GUI that includes an accurate image of the card 101, the account application 213 may receive the CMID 108 of the card 101. For example, the account application 213 may receive the CMID 108 stored in the memory of the card 101 via wireless data transfer. In another example, the account application 213 may receive the CMID 108 from the account data 224 of the server 220 when the user provides authentication credentials approved by the server 220. In another example, the account application 213 may store a local instance (not shown) of the account data 224 for the user account and receive the CMID 108 of each card associated with the account from the local instance of the account data 224. The CMID 108 may generally identify the type or style of the card (e.g., a metallic card of the first card type). In some examples, the user may tap the card 101 against the device 210 before logging in to the account via the account application 213. In such an example, the CMID 108 may be received directly from the card and / or from the account data 224 of the server 220 .

[0036] Regardless of the technique used to receive the CMID 108, the account application 213 can use the CMID 108 to query the DAM system 225. FIG. 2B illustrates an embodiment in which the DAM system 225 returns one or more images 231 and card metadata 232 associated with the CMID 108 of the card 101. As depicted in FIG. 2C, the account application 213 may determine an optimal orientation 233 of the contactless card 101 to represent in a GUI to assist the user. The optimal orientation 233 may be based on the card metadata 232 and the device attributes 214 of the device 210. For example, the device attributes 214 of the device 210 may specify that the device 210 requires the contactless card 101 to be tapped against the screen of the device 210 to enable NFC data transfer. The device attributes 214 and / or the card metadata 232 may further specify that the card 101 must be face up when tapped against a given device 210. As such, the account application 213 may determine that the optimal orientation 233 for the card 101 is face-up (e.g., the front of the card depicted in FIG. 1A ). The account application 213 may then select an image 231 that depicts the card in a face-up orientation. The account application 213 may further select an image 231 that depicts the card in a rotated orientation such that one or more reference markers on the card 101 (e.g., contact pad 120, point 111, etc.) align with one or more markers in the device attributes 214. The image 231 may generally include multiple different images of a given card 101 from multiple different angles and / or directions. Additionally, the image 231 may include specific visual elements of the contactless card 101, such as a logo, a color template, etc.

[0037] More generally, card metadata 232 may generally include any type of metadata attributes for a given contactless card 101. Because different materials may be used to construct different types of cards, card metadata 232 may be different for different cards. Additionally, because of the way the card is constructed (and the components used in card construction), the card 101 may favor one side (e.g., left side, right side, front side, back side, etc.). Thus, card metadata 232 may specify one or more materials used in manufacturing contactless card 101 (e.g., substrate 110), components used in contactless card 101 (e.g., antenna 155, circuitry 125, and other elements depicted in FIGS. 1A-1B), component placement (e.g., the location of antenna 155 on contactless card 101, the location of processing circuitry 125 on contactless card 101, etc.), one or more colors on the surface of contactless card 101, one or more logos or other artwork on the surface of contactless card 101, and one or more locations 111 (or points) on the surface of contactless card 101 that are optimal locations for data transfer. As an additional example, card metadata 232 may specify a default orientation for data transfer. The orientation may be vertical and / or horizontal. Additionally and / or alternatively, the orientation may be face-up or face-down. In doing so, account application 213 can determine the optimal orientation and location for tapping contactless card 101 to device 210.

[0038] The device attributes 214 may include any type of metadata attribute for the type of device 210. Often, different devices 210 have different characteristics that require different placement locations to enable wireless data transfer with the contactless card 101. Thus, the device attributes 214 may specify the location of the NFC antenna of the card reader 218 of the device 210, the location on the surface of the device 210 where the contactless card 101 should be tapped to enable NFC data transfer (e.g., front, back, on the display, etc.). The device attributes 214 may also specify the default orientation of the contactless card 101 (e.g., face-up and / or face-down, vertical and / or horizontal, etc.). Doing so allows the account application 213 to determine the optimal orientation and location for tapping the contactless card 101 on a particular device 210.

[0039] In some embodiments, the image 231 may not be an image of the actual physical card 101 itself, but rather a base image of a particular type of card. To provide a more accurate image, the account application 213 may overlay data onto the selected image 231. For example, the account application 213 may overlay the user's name, the card's 101 account number, the card's 101 expiration date, and / or the card's 101 CVV. Additionally and / or alternatively, the account application 213 may overlay an image including a logo that appears on the card 101. The image including the logo may be received from the DAM 225 and may be associated with the CMID 108 of the contactless card 101. This may provide a more accurate image of the card 101, as the logo on a given type of card may change over time.

[0040] As shown in FIG. 2A , the device 210 includes a camera 219. The camera 219 may be a front-facing camera and / or a rear-facing camera. The camera 219 may capture an image when an instructional GUI is drawn to assist the user in tapping the contactless card 101 to the device 210. For example, the front-facing camera 219 may capture an image and determine that the card 101 is covering the camera 219 based on an analysis of the image performed by the account application 213 using image recognition and / or computer vision algorithms. The account application 213 may further determine that data transfer has not begun between the card 101 and the device 210. Therefore, the account application 213 may generate an audio and / or visual warning indicating changing the orientation of the contactless card 101. For example, the account application 213 may select different images 231 of the card 101 to represent the card 101 according to different orientations. The account application 213 may then output the selected image in a GUI to assist the user.

[0041] As another example, the account application 213 may analyze an image captured by the camera 219 and determine that a blue contactless card 101 is depicted in the image. However, the account application 213 may determine that the blue color of the contactless card 101 does not match the known red color of cards 101 used to perform operations (e.g., processing a funds transfer, generating a virtual account number, etc.). In one embodiment, the red color of the card 101 may be specified as card metadata 232 received from the DAM 225. Additionally and / or alternatively, the account application 213 may determine that the color of the card 101 should be red based on the card image 231 received from the DAM 225. If the color of the card in the image captured by the camera 219 does not match the known color of the card 101, the account application 213 may generate and output a notification specifying that the correct card is not being used. In some embodiments, detection of a different card 101 may indicate attempted fraud. For example, if a blue card is detected, the account application 213 may identify fraud and generate a fraud alert.

[0042] In another example, the account application 213 may detect the marker 112 in an image captured by the camera 219. Doing so may enable the account application 213 to determine whether the correct card is being presented. Doing so may enable the account application 213 to determine one or more attributes of the contactless card 101. For example, the account application 213 may decode the marker 112 to determine one or more elements of card metadata 232 (e.g., card color, card type, card material, etc.). As another example, the marker 112 may encode (or otherwise associate with) a URL that leads to a record for the contactless card 101 in the DAM system 225. Thus, the account application 213 may receive one or more images 231 and / or elements of card metadata 232 from the DAM system 225 (e.g., by accessing the decoded URL).

[0043] In some embodiments, the account application 213 can open in response to tapping the contactless card 101 against the device 210 (e.g., while the user is interacting with another application). When the card 101 is tapped against the device 210, the contactless card 101 is brought sufficiently close to the card reader 218 of the computing device 210. Doing so enables data transfer (e.g., NFC data transfer, Bluetooth data transfer, etc.) between the communication interface of the contactless card 101 (e.g., at least the antenna and coil of FIG. 1B ) and the card reader 218 of the computing device 210. The applet 103 of the contactless card 101 can then generate and send encrypted data 105 to the computing device 210. For example, the applet 103 of the contactless card 101 may use a cryptographic algorithm to generate an encrypted payload of the encrypted data 105 based at least in part on the private key 104 stored in the memory 102 of the contactless card 101. In such an embodiment, the private key 104 and some other pieces of data (e.g., a customer identifier, an account identifier, etc.) may be provided as input to a cryptographic algorithm that outputs encrypted data 105. In general, the applet 103 may use any type of cryptographic algorithm and / or system to generate the encrypted data 105, and the use of a particular cryptographic algorithm as an example should not limit this disclosure. In some embodiments, the applet 103 may perform encryption using key diversification techniques to generate the encrypted data 105. Examples of key diversification techniques are described in U.S. patent application Ser. No. 16 / 205,219, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0044] Once generated, the applet 103 may transmit the encrypted data 105 to the account application 213 on the computing device 210, for example, via NFC. The account application 213 may transmit the encrypted data 105 to the authentication application 223 on the server 220. Upon receipt, the authentication application 223 may authenticate the encrypted data 105. For example, the authentication application 223 may attempt to decrypt the encrypted data 105 using a cryptographic function and a copy of the private key 104 stored by the server 220. The private key 104 may be identical to the private key 104 stored in the memory 102 of the contactless card 101, with each contactless card 101 being manufactured to include a unique private key 104 (and the server 220 storing a corresponding copy of each unique private key 104). Thus, the authentication application 223 can successfully decrypt the encrypted data 105, thereby verifying the encrypted data 105. Although private key 104 is depicted as being stored in memory 222, private key 104 may be stored elsewhere, such as in a secure element and / or a hardware security module (HSM). In such embodiments, the secure element and / or HSM may use private key 104 and a cryptographic function to decrypt encrypted data 105.

[0045] For example, as described above, the customer ID 107 may be used to generate the encrypted data 105. In such an example, the authentication application 223 may decrypt the encrypted data 105 using the private key 104 of the server 220. If the decryption results in a customer identifier associated with the account in the account data 224, the authentication application 223 verifies the encrypted data 105. If the authentication application 223 cannot decrypt the encrypted data to obtain the expected result (e.g., the customer identifier of the primary account associated with the contactless card 101), the authentication application 223 does not verify the encrypted data 105. Upon verifying the encrypted data 105, the authentication application 223 may determine the CMID 108 of the contactless card 101 from the account data 224. The authentication application 223 may then instruct the DAM 225 to send the card image 231 and metadata 232 corresponding to the determined CMID 108 to the account application 213.

[0046] 3A illustrates an example GUI 300 generated by an account application 213 executing on a device 210. As mentioned, in some embodiments, a user may provide authentication credentials before the GUI 300 is generated by the account application 213. Additionally, a user may specify a type of operation to perform (e.g., transfer a balance, generate a virtual account number, etc.) before the GUI 300 is generated. As illustrated, the GUI 300 represents an exemplary mobile device 301. The GUI 300 also represents an optimal placement location 302 (enclosed in dashed lines) for placing the contactless card 101 to enable data transfer. The placement location 302 may generally be based on the device attributes 214 of the device 210 and / or the card metadata 232 of the contactless card 101.

[0047] FIG. 3B illustrates an example of a GUI 310 generated by the account application 213. The GUI 310 may be associated with the GUI 300 of FIG. 3A, e.g., the GUI 310 may be output subsequent to the GUI 300. As illustrated, the GUI 310 depicts an image 303 of a contactless card 101. The image 303 may be one of the card images 231 received from the DAM 225 based on the CMID of the contactless card 101 associated with the authenticated user's account. The account application 213 may select the image 303 based on the card metadata 232 of the contactless card 101 and / or the device attributes 214 of the device 210. As illustrated, the image 303 of the contactless card 101 depicts the contactless card 101 in a vertical, face-up orientation, which may be determined to be an optimal orientation by the account application 213. As illustrated, the GUI 310 may further include a touchpad 304, which may be part of the optimal orientation determined by the account application 213. In doing so, the user can then tap the contactless card 101 against the device 210 according to the orientation and / or position depicted in Figures 3A-3B.

[0048] 4A shows an example of a GUI 400 generated by an account application 213 executing on a device 210. As shown, the GUI 400 includes an outline 401 (dashed line) representing where a user should place the contactless card 101 on the device 210 to enable data transfer (and / or to enable faster data transfer compared to other orientations and / or placements). Additionally, the GUI 400 includes an outline 402 of the contact pads of the contactless card 101. The GUI 400 may generally be based on the device attributes 214 of the device 210 and / or the card metadata 232 of the contactless card 101.

[0049] 4B illustrates an example of a GUI 410 generated by the account application 213 executing on the device 210. The GUI 410 may be associated with the GUI 400 of FIG. 4A; for example, the GUI 410 may be output subsequent to the GUI 400. As shown, the GUI 410 includes an image 405 of the contactless card 101 in a vertical, face-up orientation. The GUI 410 further includes a graphical touchpad 496 to enable a user to determine the appropriate orientation of the card 101 relative to the device 210. As shown, the image 405 of the contactless card 101 further includes one or more logos 407, 408 superimposed on the image 405. Additionally, the image 405 includes superimposed user-specific attributes 409, such as the card number, expiration date, CVV, and cardholder name.

[0050] Returning to FIG. 4A , the front camera 403 of the device 210 is depicted. The camera 403 may correspond to the camera 219 and may capture images used by the account application 213. For example, if a user places a contactless card 101 on the camera 403, the image captured by the camera 403 may be obscured by the card 101. The account application 213 may then determine whether data transfer has been initiated between the contactless card 101 and the device 210. If data transfer has not been initiated and the image captured by the camera 403 indicates that the card is obscuring the camera 403, the account application 213 may output an alert to the user to adjust the orientation and / or position on the device 210 where the card is tapped.

[0051] 5A illustrates an example of a GUI 500 generated by an account application 213 executing on a device 210. The GUI 500 may generally be based on the device attributes 214 of the device 210 and / or the card metadata 232 of the contactless card 101. As shown, the GUI 500 includes an image 502 of the contactless card 101 and an image 501 of the device 210. The GUI 500 depicts the contactless card 101 being tapped against the back of the mobile device 210.

[0052] 5B illustrates an example of a GUI 510 generated by the account application 213. As shown, the GUI 510 represents images 503 of the contactless card 101 in different positions relative to the device 502. In some embodiments, the GUI 510 is generated in response to the account application 213 determining that a data transfer has not been initiated between the card 101 and the device 210 within a threshold time. As another example, the images 501, 503 may correspond to two default placement positions and / or orientations of the contactless card 101 relative to the device 210. Accordingly, the account application 213 may output the GUI 500 and / or GUI 510 to assist the user in initiating a data transfer when the contactless card 101 is tapped against the device 210.

[0053] Operation according to disclosed embodiments may be further described with reference to the following figures. Some of the figures may include logic flows. While such diagrams presented herein may include specific logic flows, it will be understood that the logic flows merely provide examples of how the general functionality as described herein may be implemented. Furthermore, a given logic flow does not necessarily have to be executed in the order presented, unless specifically indicated. Furthermore, a given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. The embodiments are not limited in this context.

[0054] 6 illustrates one embodiment of a logic flow 600. The logic flow 600 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations to provide an accurate image of the contactless card 101 in the graphical user interface of the account application 213 and to enable data transfer (e.g., between the contactless card 101 and the device 210). The embodiments are not limited in this context.

[0055] As shown, the logic flow 600 begins at block 610, where the account application 213 receives valid authentication credentials for an account. At block 620, the account application 213 may determine device attributes 214 of the device 210 executing the account application 213. The account application 213 may also determine a CMID of a first contactless card 101 among one or more contactless cards 101 associated with the account. In embodiments in which multiple cards 101 are associated with the account, the account application 213 may select the first card 101 based on the card being used as part of an operation in the account application 213 (e.g., a balance transfer, generation of a virtual account number, etc.). At block 630, the account application 213 may receive one or more images 231 and one or more elements of card metadata 232 of the first contactless card 101 from the DAM system 225 based on the CMID of the first contactless card 101.

[0056] In block 640, the account application 213 may determine an optimal orientation and / or placement of the contactless card 101 to enable data transfer with the device 210. The optimal orientation and / or placement of the contactless card 101 may be based on the card metadata 232 and / or the device attributes 214. For example, the optimal orientation may be a vertical orientation with the card 101 placed face up on the screen of the device 210. As another example, the optimal orientation may be a horizontal orientation with the card 101 placed face down on the back side (e.g., the side without the display) of the device 210.

[0057] At block 650, the account application 213 may generate a GUI representing the first image 231 of the contactless card 101 according to the determined optimal orientation and / or position. The GUI may further include an indication of tapping the contactless card 101 against the device 210 according to the optimal orientation and / or placement. At block 660, the account application 213 may optionally overlay cardholder data on the image 231 of the contactless card 101. For example, the account application 213 may overlay the cardholder name, the account number of the contactless card 101, the CVV of the contactless card 101, and the expiration date of the contactless card 101. At block 670, the account application 213 may display the GUI on the display of the device 210. At block 680, an NFC (or other wireless) data transfer may be performed between the contactless card 101 and the device 210.

[0058] 7 illustrates one embodiment of a logic flow 700. The logic flow 700 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 700 may include some or all of the operations of providing an accurate image of the contactless card 101 in the graphical user interface of the account application 213. The embodiments are not limited in this context.

[0059] As shown, logic flow 700 begins at block 710, where the camera 219 of the device 210 may capture an image representing a contactless card 101. At block 720, the account application 213 may determine whether the correct contactless card 101 has been presented by the user. For example, if the user is attempting to generate a virtual account number for the first contactless card 101, the user may be required to tap the first contactless card 101 against the device 210. However, the account application 213 may analyze the image captured at block 710 and determine that the user is holding a second contactless card 101 that is different from the first contactless card 101. The account application 213 may determine that the first contactless card 101 has not been presented based on any suitable technique, such as whether the color, logo, and / or account number of the card depicted in the image matches the corresponding color, logo, and / or account number of the first contactless card 101. If it is determined that the user has not presented the correct card, the account application 213 may output an indication in block 730 indicating that an incorrect contactless card 101 has been presented. The indication may be an audio indication (e.g., an error sound) and / or a visual indication (e.g., a GUI update informing the user that an incorrect card has been detected).

[0060] At block 740, the account application 213 may instruct the camera 219 to capture a second image. The account application 213 may analyze the second image and determine that the second image represents at least a portion of the contactless card 101 covering the camera 219. At block 750, the account application 213 may determine that data transfer between the device 210 and the contactless card 101 has not begun (e.g., within a predetermined time threshold). At block 760, the account application 213 may determine a different orientation and / or placement of the contactless card 101 relative to the device 210. At block 770, the account application 213 may output a GUI representing the different orientation and / or placement of the contactless card 101 relative to the device 210.

[0061] FIG. 8 illustrates one embodiment of an example computing architecture 800 including a computing system 802 that may be suitable for implementing various embodiments as described above. In various embodiments, computing architecture 800 may be configured or implemented as part of an electronic device. In some embodiments, computing architecture 800 may be representative of a system that implements, for example, one or more components of system 100. In some embodiments, computing system 802 may be representative of, for example, contactless card 101, mobile device 210, and server 220 of system 200. The embodiments are not limited in this context. More generally, computing architecture 800 may be configured to implement all of the logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-7.

[0062] As used herein, the terms “system,” “component,” and “module” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 800. For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution, and components can be localized on one computer and / or distributed among one or more computers. Furthermore, components can be communicatively coupled to each other by various types of communication media to coordinate operations. Coordination can include unidirectional or bidirectional information exchange. For example, components may communicate information in the form of signals communicated over a communication medium. Information can be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages may be transmitted across a variety of connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0063] Computing system 802 may include various typical computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by computing system 802.

[0064] 8, computing system 802 comprises a processor 804, a system memory 806, and a system bus 808. Processor 804 may be any of a variety of commercially available computer processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors; ARM® application, embedded, and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and SONY® Cell processors; Intel® Celeron®, Core®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as processor 804.

[0065] The system bus 808 provides an interface connecting system components, including but not limited to the system memory 806, to the processor 804. The system bus 808 may further be any of several types of bus structures that can interconnect a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may also connect to the system bus 808 through a slot architecture. Examples of slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, and Personal Computer Memory Card International Association (PCMCIA).

[0066] The system memory 806 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon oxide-silicon nitride-silicon oxide (SONOS) memory, magnetic or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state storage devices (e.g., USB memory, solid-state drives (SSDs)), and any other type of storage media suitable for storing information. In the embodiment shown in FIG. 8, the system memory 806 may include non-volatile memory 810 and / or volatile memory 812. The basic input / output system (BIOS) can be stored in non-volatile memory 810 .

[0067] Computing system 802 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 814, a magnetic floppy disk drive (FDD) 816 that reads from or writes to a removable magnetic disk 818, and an optical disk drive 820 that reads from or writes to a removable optical disk 822 (e.g., a CD-ROM or DVD). HDD 814, FDD 816, and optical disk drive 820 may be connected to system bus 808 by HDD interface 824, FDD interface 826, and optical drive interface 828, respectively. HDD interface 824 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Computing system 802 is generally configured to implement all of the logic, systems, methods, devices, and functions described herein with reference to FIGS. 1-7.

[0068] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, the drives and memory units 810, 812 may store a number of program modules including an operating system 830, one or more application programs 832, other program modules 834, and program data 836. In one embodiment, the one or more application programs 832, other program modules 834, and program data 836 may include, for example, various applications and / or components of systems 100 and / or 200, such as applets 103, private keys 104, encrypted data 105, customer ID 107, CMID 108, account application 213, authentication application 223, account data 224, and DAM system 225.

[0069] A user can enter commands and information into computing system 802 through one or more wired / wireless input devices, such as a keyboard 838 and a pointing device such as a mouse 840. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, gloves, graphics tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to processor 804 through an input device interface 842 coupled to system bus 808, but can be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0070] A monitor 844 or other type of display device is also connected to the system bus 808 via an interface, such as a video adapter 846. The monitor 844 may be internal or external to the computing system 802. In addition to the monitor 844, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0071] Computing system 802 can operate in a networked environment using wired and / or wireless communication logical connections to one or more remote computers, such as remote computer 848. The remote computer 848 can be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment appliance, a peer device, or other common network node, and typically includes many or all of the elements described in connection with computing system 802, although for simplicity, only memory / storage device 850 is illustrated. The depicted logical connections include wired / wireless connections to a local area network (LAN) 852 and / or larger networks, e.g., a wide area network (WAN) 854. Such LAN and WAN networking environments are commonplace in offices and businesses and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet. In an embodiment, network 230 of FIG. 2 is one or more of LAN 852 and WAN 854.

[0072] When used in a LAN networking environment, the computing system 802 is connected to the LAN 852 through a wired and / or wireless communication network interface or adapter 856. The adapter 856 can facilitate wired and / or wireless communication to the LAN 852 and may also include a wireless access point disposed thereon for communication with the wireless capabilities of the adapter 856.

[0073] When used in a WAN networking environment, the computing system 802 may include a modem 858 or be connected to a communications server on the WAN 854 or have other means of establishing communications over the WAN 854, such as via the Internet. The modem 858, which may be internal or external and may be a wired and / or wireless device, connects to the system bus 808 via the input device interface 842. In a networked environment, program modules depicted associated with the computing system 802, or portions thereof, may be stored in the remote memory / storage device 850. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0074] The computing system 802 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., modulation techniques according to IEEE 802.16 wireless communications). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies. Thus, communication may be in a predefined structure, such as a traditional network, or simply ad-hoc communication between at least two devices. Wi-Fi networks use wireless technologies known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0075] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include a processor, a microprocessor, a circuit, a circuit element (e.g., a transistor, a resistor, a capacitor, an inductor, etc.), an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a logic gate, a register, a semiconductor device, a chip, a microchip, a chipset, etc. Examples of software may include a software component, a program, an application, a computer program, an application program, a system program, a machine program, an operating system software, a middleware, firmware, a software module, a routine, a subroutine, a function, a method, a procedure, a software interface, an application program interface (API), an instruction set, a computational code, a computer code, a code segment, a computer code segment, a word, a value, a symbol, or any combination thereof. The decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0076] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor and, when read by a machine, cause the machine to produce logic that performs the techniques described herein. Such representations, known as “IP cores,” may be stored on tangible machine-readable media and supplied to various customers or manufacturing facilities to be loaded into manufacturing machines that produce the logic or processors. Some embodiments may be implemented using, for example, a machine-readable medium or article that may store instructions or sets of instructions that, when executed by a machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disks, floppy disks, compact disk-read only memory (CD-ROM), compact disk-recordable (CD-R), compact disk-rewriteable (CD-RW), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0077] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future applications claiming priority to this application may claim the disclosed subject matter differently and may generally include any set of one or more limitations variously disclosed or otherwise set forth herein.

Claims

1. an application executing on a processor of the device displaying a first image of a plurality of images of the contactless card in a graphical user interface (GUI), the first image representing the contactless card according to a first orientation; the application determining that a near field communication (NFC) data transfer has not been initiated between the device and the contactless card within a threshold time; determining, by the application, a second orientation different from the first orientation based on a plurality of metadata attributes of the contactless card and a plurality of attributes of the device; the application updating the GUI to display a second image of the plurality of images representing the contactless card according to the second orientation and to display instructions specifying tapping the contactless card against the device according to the second orientation; A method that encompasses

2. moreover, The application includes selecting a second image from the plurality of images based on the second orientation, the second image representing the contactless card according to the second orientation. The method of claim 1.

3. moreover, the application receiving a card manufacturer identifier (CMID) of the contactless card; the application receiving a plurality of images of the contactless card and a plurality of metadata attributes of the contactless card based on the CMID; 2. The method of claim 1, comprising:

4. moreover, the application capturing an image via a camera; The application determines, based on an analysis of the image, that the image represents the contactless card.

10. The method of claim 1 comprising:

5. moreover, the application detecting a graphical marker on a surface of the contactless card based on the image; the application determining at least one of a plurality of metadata attributes of the contactless card based on the graphical marker; 5. The method of claim 4, comprising:

6. moreover, the application overlaying a plurality of attributes of the contactless card onto the second image; the application displays the second image including the overlaid attributes of the contactless card on a GUI; 2. The method of claim 1, comprising:

7. the first orientation aligning a communication interface of the contactless card with a communication interface of the device; The second orientation is to align a communication interface of the contactless card with a communication interface of the device.

2. The method of claim 1, comprising:

8. A computer-readable storage medium containing instructions, The instructions, when executed by a processor of a device, cause the processor to displaying a first image of a plurality of images of a contactless card in a graphical user interface (GUI), the first image representing the contactless card according to a first orientation; determining that a near field communication (NFC) data transfer has not been initiated between the device and the contactless card within a threshold time; determining a second orientation different from the first orientation based on a plurality of metadata attributes of the contactless card and a plurality of attributes of the device; displaying a second image of the plurality of images representing the contactless card according to the second orientation and updating the GUI to display an instruction specifying tapping the contactless card against the device according to the second orientation. A computer-readable storage medium.

9. The instructions are selecting, based on the second orientation, the second image from among a plurality of images representing the contactless card in accordance with the second orientation. The computer-readable storage medium of claim 8.

10. The instructions are receiving a card manufacturer's identifier (CMID) for the contactless card; receiving, based on the CMID, a plurality of images of the contactless card and a plurality of metadata attributes of the contactless card. The computer-readable storage medium of claim 8.

11. The instructions are Capturing an image via a camera; determining, based on an analysis of the image, that the image represents the contactless card. The computer-readable storage medium of claim 8.

12. The instructions are detecting a graphical marker on a surface of the contactless card based on the image; determining at least one of a plurality of metadata attributes of the contactless card based on the graphical marker. The computer-readable storage medium of claim 11.

13. The instructions are superimposing a plurality of attributes of the contactless card onto the second image; and displaying the second image including the overlaid attributes of the contactless card on a GUI. The computer-readable storage medium of claim 8.

14. the first orientation aligns a communication interface of the contactless card with a communication interface of the device; The second orientation aligns the communication interface of the contactless card with the communication interface of the device. The computer-readable storage medium of claim 8.

15. A computing device including a processor and a memory, The memory contains instructions that, when executed by the processor, cause the processor to displaying a first image of a plurality of images of a contactless card in a graphical user interface (GUI), the first image representing the contactless card according to a first orientation; determining that a near field communication (NFC) data transfer has not been initiated between the computing device and the contactless card within a threshold time; determining a second orientation different from the first orientation based on a plurality of metadata attributes of the contactless card and a plurality of attributes of the computing device; updating the GUI to display a second image of the plurality of images representing the contactless card according to the second orientation and to display instructions specifying tapping the contactless card against the computing device according to the second orientation. Computer equipment.

16. The instructions are selecting, based on the second orientation, the second image from among a plurality of images representing the contactless card according to the second orientation.

16. The computer device of claim 15.

17. The instructions are receiving a card manufacturer's identifier (CMID) for the contactless card; receiving, based on the CMID, a plurality of images of the contactless card and a plurality of metadata attributes of the contactless card.

16. The computer device of claim 15.

18. The instructions are Capturing an image via a camera; determining, based on an analysis of the image, that the image represents the contactless card.

16. The computer device of claim 15.

19. The instructions are detecting a graphical marker on a surface of the contactless card based on the image; determining at least one of a plurality of metadata attributes of the contactless card based on the graphical marker.

20. The computer device of claim 18.

20. The instructions are superimposing a plurality of attributes of the contactless card onto a second image; and displaying the second image including the overlaid attributes of the contactless card on a GUI.

16. The computer device of claim 15.

Images