Context Tapping Engine

Abstract

To provide a method of dynamically determining an action to be executed in a computing device in response to a tap of a contactless card.SOLUTION: A method includes authenticating a credential associated with an account, detecting a tap of a contactless card associated with the account, receiving action data from the contactless card, determining a context of an application based on a current output of the application, determining a first action associated with the tap of the contactless card on the basis of the action data, the determined context, and a machine learning model, and starting executing the first action on the basis of the tap of the contactless card.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] FIELD Embodiments herein relate generally to contactless cards, and more particularly to a contextual tapping engine for contactless cards.

[0002] Related Applications This application claims priority to U.S. Patent Application No. 16 / 359,987, entitled "Context Tapping Engine," filed March 20, 2019. The contents of the aforementioned application are incorporated herein by reference in their entirety. [Background technology]

[0003] In many cases, tapping a contactless card against a computing device may cause the computing device to perform a predefined action. However, because the predefined action is static, it may not be relevant given the intended action that the user wants to perform. Similarly, the predefined action may not be relevant given the context of the computing device. Summary of the Invention

[0004]

[0006] Embodiments disclosed herein provide a system, method, article of manufacture, and computer-readable medium for a context tapping engine. According to one example, an application running on a computing device may authenticate credentials associated with an account and detect the tapping of a contactless card associated with the account to the computing device. The application may receive action data from a communication interface of the contactless card, the action data being used at least in part to determine an action associated with the tapping of the contactless card to the computing device. The application may determine a context for the application based at least in part on a current output of the application. Based on the action data, the determined context, and data associated with the account, the application may determine a first action associated with the tapping of the contactless card to the computing device, a first action associated with at least one of the applications, and an operating system (OS) running on the processor circuit. The application may initiate execution of the first action based on the tapping of the contactless card to the computing device. [Brief explanation of the drawings]

[0005] [Figure 1] 1 illustrates an embodiment of a system for providing a context tapping engine. [Figure 2A] 1 illustrates an embodiment of a context tapping engine. [Figure 2B] 1 illustrates an embodiment of a context tapping engine. [Figure 3A] 1 illustrates an embodiment of a context tapping engine. [Figure 3B] 1 illustrates an embodiment of a context tapping engine. [Figure 4] 1 shows an example of defining rules for a context tapping engine. [Figure 5A]1 shows an example of a contactless card. [Figure 5B] 1 shows an example of a contactless card. [Figure 6] 1 illustrates a first logic flow embodiment. [Figure 7] 10 illustrates a second logic flow embodiment. [Figure 8] 10 illustrates a third logic flow embodiment. [Figure 9] 1 illustrates an embodiment of a computing architecture. DETAILED DESCRIPTION OF THE INVENTION

[0006] Embodiments disclosed herein provide a contextual tapping engine that interprets a tap of a contactless card to a computing device and dynamically determines an action to perform on the computing device in response to the tap. The contextual tapping engine may consider any number and type of factors when determining the action to perform. For example, the contextual tapping engine may consider one or more of a default action, a user-defined action, a context-determined action, and / or a predicted action to determine the action to perform in response to a particular tap. The default action may be a default action specified in the memory of the contactless card. The user-defined action may be an action defined by a user and stored in the memory of the contactless card. The context-determined action may comprise an action dynamically generated by the computing device based at least in part on the current context of the computing device. The predicted action may comprise an action generated by the computing device based at least in part on historical data from multiple users. In this way, various associated actions may be performed in response to a tap of a contactless card on the computing device.

[0007] For example, a user may receive a new contactless card and tap the contactless card against a smartphone. In response to the tap, the smartphone may open a card activation page of an account management application, which may allow the user to activate the card. The smartphone may open the card activation page based on a uniform resource locator (URL) specified as action data in the memory of the contactless card. Once the card is activated, the user may tap the card against the smartphone again. The smartphone may then determine to open the account balance page of the account application based on the context of the account management application. In response to another tap of the contactless card, the smartphone may leverage machine learning to predict an action associated with the tap. For example, the smartphone may predict to load a user-defined action page of the account management application. In the user-defined action page, the user may specify an action (e.g., call customer service), which may be stored in the memory of the contactless card. The user-defined action may include one or more rules (or criteria) that, when met, cause the smartphone to perform the user-defined action (e.g., call customer service).

[0008] With general reference 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 herein, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are operations requiring 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 is sometimes convenient, 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.

[0009] Further, these operations are often referred to in terms, such as adding or comparing, which 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, for 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 and written in accordance with the teachings herein, and / or include apparatuses or digital computers specially constructed for the required purposes. Various embodiments also relate to apparatuses or systems for performing these operations. These apparatuses may be specially constructed for the required purposes. The required structure for these various machines will be apparent from the description given.

[0010] Reference is now made to the drawings, wherein 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 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 description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0011] FIG. 1 illustrates a schematic diagram of an exemplary system 100 consistent with the disclosed embodiments. As shown, the system 100 includes one or more contactless cards 101 and one or more mobile devices 110. The contactless cards 101 represent any type of payment card, such as a credit card, a debit card, an ATM card, or a gift card. The contactless cards 101 may include one or more chips (not shown), such as a radio frequency identification (RFID) chip, configured to communicate with the mobile devices 110 via NFC, the EMV standard, or other short-range protocols for wireless communication, or using NFC Data Exchange Format (NDEF) tags. While NFC is used herein as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and / or Wi-Fi. The mobile devices 110 represent any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, or the like.

[0012] As shown, the contactless card's memory 102 includes a data store of action data 103. The action data 103 represents any type of data that can be interpreted by the tapping engine 115 of the account application 113 to perform an action on the mobile device 110. For example, the action data 103 may include a URL directed to a website, an application (e.g., the account application 113 and / or other applications 114), an application page (e.g., the account application 113 and / or other applications 114 of the mobile device 110), a component of the OS 112, or other computing resource. Upon receiving the tapping engine 115, the tapping engine 115 may cause the mobile device 110 to load the resource specified by the URL.

[0013] As another example, the action data 103 may include rules, conditions, and / or other data that enable the tapping engine 115 to determine an associated action. For example, the tapping engine 115 may determine a context of the mobile device 110 and determine a contextual action based on the context of the mobile device 110 and the action data 103. As another example, the tapping engine 115 may generate a predictive action that predicts a user's intention based on historical data (e.g., previous actions performed by the user and / or other users). The tapping engine 115 may then initiate execution of the contextual action and / or the predictive action on the mobile device 110.

[0014] Additionally, action data 103 may store user-defined actions that can be interpreted by tapping engine 115 to perform the user-defined action on mobile device 110. A user-defined action in action data 103 may include a URL, as well as one or more rules or other conditions that must be satisfied before tapping engine 115 performs the user-defined action.

[0015] As shown, the memory 111 of the mobile device 110 includes an instance of an operating system (OS) 112. Examples of operating systems 112 include the Android® OS, iOS®, Linux®, and Windows® operating systems. As shown, the OS 112 includes an account application 113 and one or more other applications 114. The account application 113 allows a user to perform various account-related operations, such as viewing an account balance, purchasing items, and processing payments. A user may initially authenticate using authentication credentials to access certain functionality of the account application 113. For example, the authentication credentials may include a username and password, biometric credentials, etc.

[0016] As shown, the account application 113 includes a tapping engine 115 and a data store of rules 116, a user profile 117, a machine learning (ML) model 118, and account data 119. The tapping engine 115 is configured to determine an action associated with tapping the contactless card 101 against the mobile device 110. As described above, the tapping engine 115 is configured to determine a predefined action associated with the tap, a user-defined action associated with the tap, generate a contextual action associated with the tap, and generate a predicted action associated with the tap. Generally, when the contactless card 101 is tapped (e.g., brought into wireless communication range) against the mobile device 110, the mobile device 110 may receive one or more records of action data 103 from a communication interface (e.g., NFC, Bluetooth, EMV, etc.) of the contactless card 101.

[0017] The tapping engine 115 may determine an action to perform on the mobile device 110 based at least in part on the action data 103. For example, the action data 103 may specify a URL. In some embodiments, the tapping engine 115 may further determine the context of the mobile device 110 when determining an action to perform on the mobile device 110. The tapping engine 115 may determine the context based on any attributes of the mobile device 110, such as which application is running on the mobile device 110, which application is in the foreground of the mobile device 110's display, what functionality is associated with the foreground application, analyzing data displayed on the device's display, data in the user profile 117, and / or data in the account data 119 (e.g., transaction data, purchase data, etc.).

[0018] Further, in some embodiments, the tapping engine 115 may generate predicted actions that reflect the user's intent when determining an action to perform on the mobile device 110. For example, a user may repeatedly access an account statement page after tapping the contactless card 101 to the mobile device 110. In such an example, the tapping engine 115 may load the account statement page after detecting the user tapping the contactless card 101 to the mobile device 110. As another example, the tapping engine 115 may utilize an ML model 118 trained based on training data. The training data may describe historical actions performed in response to multiple different users tapping their contactless cards to the device. During training based on the training data, a machine learning (ML) algorithm may generate the ML model 118. The ML model 118 may be used to generate predicted actions for a given tap of the contactless card 101 to the mobile device 110. For example, the tapping engine 115 may provide one or more of the action data 103, the determined context, the rules 116, the user profile 117, and / or the account data 119 to the ML model 118, which may generate one or more predicted actions. The ML model 118 may further calculate a score for each predicted action, the score reflecting the likelihood that the action is the action intended by the user. The tapping engine 115 may then select the predicted action with the highest score and begin execution of the selected predicted action.

[0019] As mentioned, in some embodiments, the action data 103 specifies a default action (e.g., loading a card activation page of the account application 113 when a contactless card 101 that has not been activated for use is tapped to the mobile device 110). Thus, in such an example, the tapping engine 115 loads the account activation page of the account application 113 in response to tapping an inactive card. As another example, the action data 103 may include a flag reflecting that the card has not been activated, and the tapping engine 115 loads the account activation page upon detecting the flag indicating that the card has not been activated. As yet another example, the tapping engine 115 may determine that it has not previously communicated with the card 101 to load the account activation page. In another example, the flag may be stored on a server maintained by the issuer of the contactless card 101. The flag stored on the server may indicate that the card has been sent to the customer but has not yet been activated. The tapping engine 115 may receive the flag from the server and load the account activation page accordingly. When the card is activated, different actions may be stored as action data 103. The different actions may be generated by the contactless card 101 itself, the account application 113, and / or the user.

[0020] In other embodiments, action data 103 specifies a user-defined action, such as calling a customer service department by phone number. A URL stored in action data 103 may specify opening a phone application (e.g., one of other applications 114) of OS 112 and dialing the phone number of the customer service department. In such an example, tapping engine 115 opens the phone application and dials the phone number of the customer service department for the user who responds to receiving action data 103 based on tapping contactless card 101.

[0021] As another example, the action data 103 may be generic and interpreted by the tapping engine 115 (e.g., using context and / or predictions) to determine relevant actions. For example, if a user taps the contactless card 101 against the mobile device 110 while viewing the home page of the account application 113, the tapping engine 115 may determine that the context of the mobile device 110 is related to the associated account (e.g., determine the concept of text to be output on the home page based on the URL of the home page). In response, the tapping engine 115 may load the account balance page of the account application 113, allowing the user to view their account balance and other detailed account information. Thus, the tapping engine 115 may monitor actions performed by the user and store an indication of the action (along with the determined context) in the user profile 117 and / or account data 119. As another example, when the contactless card 101 is tapped against the mobile device 110, the tapping engine 115 may determine that the account data 119 reflects that a purchase was made using the contactless card 101 (e.g., using a web browser in another application 114) within a predefined time period (e.g., 30 seconds, 1 minute, etc.). Thus, the tapping engine 115 may perform an action related to the purchase. For example, the tapping engine 115 may programmatically schedule payment for the purchase on a due date. As another example, the tapping engine 115 may load a rewards page that allows the customer to pay for the purchase using reward points. As yet another example, the tapping engine 115 may determine an associated action based on the presence of one or more form fields within an application. For example, the tapping engine 115 may determine that a form field in the web browser currently includes an account number field.The tapping engine 115 may identify the account number field by any suitable means, such as reading the metadata of a form field, reading the source code of the web page in a web browser, the document object model (DOM) of the web page, etc. Thus, in such an example, the tapping engine 115 may output a notification specifying that the contactless card 101 be tapped against the device 110 to copy the account number of the card 101 into the account number field.

[0022] In some embodiments, once an action is performed in response to a tap, the tapping engine 115 and / or the account application 113 may output a notification to the user indicating that the action was performed. An additional notification may specify to the user that any action can be linked to the card tap, including a user-defined action and / or one or more predefined actions that the user can select.

[0023] Rules 116 generally include one or more rules that can be used by tapping engine 115 to determine an action in response to a tap. For example, a rule in rules 116 may specify paying for a movie ticket with reward points if the user spends more than $10 on movie tickets within a specified time period. In such an example, tapping engine 115 may detect a tap of contactless card 101 and analyze the user's spending data in account data 119 to determine that the user spent $20 on movie tickets within a specified time period. In response, tapping engine 115 may programmatically generate a contextual action that may include paying for the movie ticket with reward points or loading a page in account application 113 that allows the user to pay for the movie ticket with reward points.

[0024] In some embodiments, the contactless card 101 may transmit multiple elements of action data 103 to the device 110. For example, an encrypted package may include multiple elements of action data 103 and delimiters and / or metadata used by the tapping engine 115 to parse the different elements of the action data 103. In such an example, the single package may be decrypted, parsed, and used for one or more purposes (e.g., to access a URL, call a phone number, and / or fill in form fields). For example, if multiple elements of the action data 103 are separated by a comma delimiter, the tapping engine 115 may parse each element based on the comma delimiter and perform one or more operations associated with each element of the action data.

[0025] 2A is a schematic diagram 200 illustrating an example of a tapping engine 115 determining an action in response to tapping a contactless card 101 against a mobile device 110, according to one embodiment. As shown, an account application 113 on the mobile device 110 outputs a customer service page containing frequently asked questions (FAQs) about customer service issues. When the contactless card 101 is tapped against the mobile device 110, the contactless card 101 may send action data 103 to the mobile device 110. However, the action data 103 may not specify an action to perform (e.g., access a URL of an application, page, etc.). Thus, the tapping engine 115 may determine an action to perform in response to the tap.

[0026] In at least one embodiment, the tapping engine 115 determines the context of the mobile device 110 to determine an action to perform. For example, the tapping engine 115 may determine that a customer service page of the account application 113 is currently displayed on the mobile device 110. For example, the tapping engine 115 may parse the text of the customer service page and detect concepts related to customer service. Thus, the tapping engine 115 may determine that the context of the mobile device 110 is related to customer service. Thus, the tapping engine 115 may determine to perform an action related to customer service, such as initiating a call to customer service, loading a more detailed customer service page in the account application 113, etc.

[0027] Additionally and / or alternatively, the tapping engine 115 may leverage the ML model 118 to determine an action associated with tapping the contactless card 101 on the mobile device 110. For example, the tapping engine 115 may provide the ML model 118 with data describing the context of the mobile device 110 (e.g., that a customer service page is being displayed, the context relates to customer service, the history of the application, and / or the page output for display on the mobile device 110, etc.). Furthermore, the ML model 118 may consider a history of tap actions performed with associated user responses and / or a history of tap actions performed by multiple users. For example, the history of tap actions may indicate that the most frequent action performed in response to tapping the contactless card 101 when a customer service FAQ page is being displayed is dialing customer service. The ML model 118 may further consider rules 116, user profiles 117, and / or account data 119. The ML model 118 may then generate one or more candidate actions to perform and return the candidate action with the highest score as the action to perform in response to tapping the contactless card 101 against the mobile device 110.

[0028] 2B is a schematic diagram 210 illustrating an embodiment in which tapping engine 115 determines to open a phone application to dial customer support on behalf of a user. Thus, tapping engine 115 may initiate the opening of the phone application of OS 112 and cause the phone application to dial a phone number associated with customer support. For example, tapping engine 115 may determine to dial customer support based on the determined context of mobile device 110 of FIG. 2A. Additionally and / or alternatively, ML model 118 may determine that calling customer support is the most likely action to be performed by the user (based on the score calculated for each candidate action). Additionally and / or alternatively, tapping engine 115 may determine to call customer support based on a rule specified in rules 116 (and / or user profile 117), where the rule specifies to call customer service when a customer service-related page of account application 113 is displayed.

[0029] 3A is a schematic diagram 300 illustrating an example of a tapping engine 115 that determines an action in response to tapping a contactless card 101 against a mobile device 110, according to one embodiment. As described above, when the contactless card 101 is tapped against the mobile device 110, the contactless card 101 may send action data 103 to the mobile device 110. However, the action data 103 may be general and may not specify an action to perform. Thus, the tapping engine 115 may determine an action to perform in response to the tapping.

[0030] As shown, the account application 113 on the mobile device 110 is outputting a home page including an indication of another account of the user. The tapping engine 115 may receive an indication from the account application 113 that a home page is being output for display. The tapping engine 115 may determine an action based on the context of the mobile device 110. As mentioned, the tapping engine 115 may determine the context by determining that the home page of the account application 113 is being displayed. The tapping engine 115 may further determine the context by analyzing the output of the home page (e.g., any text and / or images) to determine concepts associated with the home page. Thus, the tapping engine 115 may determine that the context of the mobile device 110 is related to the user's account. Based on the determined context, the tapping engine 115 may determine to access a detailed account page of the account application 113.

[0031] 3B is a schematic diagram 310 illustrating an embodiment in which the tapping engine 115 causes the account application 113 to load an account details page associated with the contactless card 101 (e.g., based on the account number of the contactless card 101). As noted, the tapping engine 115 may determine to load the account details page in response to a tap based on the context of the mobile device. Additionally and / or alternatively, the user may specify a rule 116 indicating that the account details page should load when the contactless card 101 is tapped while the home page is displayed. Additionally and / or alternatively, the tapping engine 115 may predict, based on the ML model 118, that the user intends to load the account details page in response to the tap.

[0032] FIG. 4 is a schematic diagram 400 illustrating exemplary user-defined actions for storage in action data 103 of contactless card 101, according to one embodiment. As shown, the graphical user interface of account application 113 allows a user to define an action. For example, in GUI element 401, the user specified that the action applies to tapping contactless card 101 while account application 113 is outputting a home page (e.g., the home page of FIG. 3A ). Further, in GUI element 402, the user specified that tapping contactless card 101 while account application 113 is outputting a home page should load a detailed balance page associated with the account (e.g., the account details page of FIG. 3B ). The input provided in GUI element 401 may be manually entered by the user and / or selected by the user from multiple options (e.g., a drop-down list of options). Upon submission, account application 113 generates action data 103-1, which is sent to contactless card 101. Contactless card 101 may then store action data 103-1 in the memory of contactless card 101 as a record of action data 103. In one embodiment, action data 103-1 includes a URL that points to an account details page of account application 113. However, in other embodiments, action data 103-1 includes additional information (e.g., a rule specifying that if the home page of account application 113 is currently open on mobile device 110, the URL to the account details page should be followed).

[0033] FIG. 5A illustrates a contactless card 101, which may comprise 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 502, which displays the card's name on the front or back. In some examples, the contactless card 101 may comprise, but is not limited to, an identification card unrelated to a payment card. In some examples, the payment card may comprise a dual-interface contactless payment card. The contactless card 101 may comprise a substrate 510, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it should be understood that contactless cards 101 according to the present disclosure may have different characteristics and the present disclosure does not require that contactless cards be implemented as payment cards.

[0034] The contactless card 101 may also include identification information 515 displayed on the front and / or back of the card, and a contact pad 520. The contact pad 520 may be configured to establish contact with other communication devices, such as the mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may also include processing circuitry, an antenna, and other components not shown in FIG. 5A. These components may be located behind the contact pad 520 or elsewhere on the substrate 510. The contactless card 101 may also include a magnetic strip or tape (not shown in FIG. 5A) that may be located on the back of the card.

[0035] 5B, contact pad 520 of contactless card 101 may include processing circuitry 525 for storing and processing information, including microprocessor 530 and memory 102. It is understood that processing circuitry 525 may include additional components including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-resistant hardware necessary to perform the functions described herein.

[0036] The memory 102 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be read-only or one-time programmable at the factory. One-time programming allows it to be written once and read many times. Write-once / read-multiple memory may 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 many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Read / write memory may also be read many times after leaving the factory.

[0037] The memory 102 may be configured to store the action data 103, one or more applets 540, one or more counters 504, and one or more customer identifiers 507. The one or more applets 540 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 540 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 with limited memory. The one or more counters 504 may comprise a numeric counter sufficient to store an integer. The customer identifier 507 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 101, which identifier may distinguish the contactless card user from other contactless card users. In some examples, the customer identifier 507 may identify both the customer and the account assigned to the customer, and further identify the contactless card associated with the customer's account.

[0038] Although the processor and memory elements of the foregoing exemplary embodiments 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 completely separate from, the pads 520, or as additional elements in addition to the processor 530 and memory 102 elements located within the contact pads 520.

[0039] In some examples, the contactless card 101 may include one or more antennas 555. The one or more antennas 555 may be disposed within the contactless card 101 and around the processing circuit 525 of the contact pads 520. For example, the one or more antennas 555 may be integrated with the processing circuit 525, or the one or more antennas 555 may be used with an external booster coil. As another example, the one or more antennas 555 may be external to the contact pads 520 and the processing circuit 525.

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

[0041] As described above, contactless card 101 may be built on a software platform operable on a memory-limited smart card or other device, such as a Java Card, and one or more applications or applets may be securely executed. The applets 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 applets may be configured to 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., of mobile device 110), and generate an NDEF message comprising the cryptographically secure OTP encoded as an NDEF text tag.

[0042] An example of an NDEFOTP is the NDEF short record layout (SR=1). In such an example, one or more applets 540 may be configured to encode the OTP as a text tag of the well-known type NDEF Type 4. In some examples, an NDEF message may comprise one or more records. The applet 540 may be configured to add one or more static tag records in addition to the OTP record.

[0043] In some examples, contactless card 101 and server 120 may include specific data so that the card can be properly identified. Contactless card 101 may include one or more unique identifiers (not shown). Each time a read operation is performed, counter 104 may be configured to increment. In some examples, each time data from contactless card 101 is read (e.g., by mobile device 110), counter 104 is sent to the server for verification, which determines (as part of the verification) whether counter values ​​104 are equal.

[0044] In some examples, one or more applets 540 may be configured to maintain their personalized state and allow personalization only when unlocked and authenticated. Other states may comprise a standard state pre-personalization. Upon entering the exit state, one or more applets 540 may be configured to delete personalized data. In the exit state, one or more applets 540 may be configured to stop responding to all application protocol data unit (APDU) requests.

[0045] One or more applets 540 may be configured to maintain an applet version (2 bytes) that may be used in authentication messages. In some examples, this may be interpreted as a major version in the most significant byte and a minor version in the least significant byte. Rules for each version are configured to interpret authentication messages. For example, for major versions, this may include each major version having a specific authentication message layout and specific algorithms. For minor versions, this may include changes to authentication messages or encryption algorithms, changes to static tag content, as well as bug fixes, security enhancements, etc.

[0046] In some examples, one or more applets 540 may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, various encrypted data may be presented that may indicate the authenticity of the contactless card. Based on one or more applications, an NFC read of the tag may be processed, the data may be transmitted to a server, and the data may be verified at the server.

[0047] In some examples, the contactless card 101 and the server may contain specific data so that the card can be properly identified. The contactless card 101 may be equipped with one or more unique identifiers (not shown). Each time a read operation is performed, the counter 504 may be configured to increment. In some examples, each time data from the contactless card 101 is read (e.g., by the mobile device 110), the counter 504 is sent to the server for verification, which determines (as part of the verification) whether the counter values ​​504 are equal.

[0048] The counter(s) 504 may be configured to prevent replay attacks. For example, if a ciphertext is captured and replayed, the ciphertext will be immediately rejected if the counter 504 is read, used, or otherwise passed on. If the counter 504 is not used, it may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. The contactless card 101 cannot determine the application transaction counter 504 because there is no communication between the applets 540 on the contactless card 101. In some examples, the contactless card 101 may include a first applet 540-1, which may be a transaction applet, and a second applet 540-2. Each applet may include a counter 504.

[0049] In some examples, the counter 504 may be out of sync. In some examples, the counter 504 may increment to account for an accidental read that initiates a transaction, such as a read at an angle, but the application does not process the counter 504. In some examples, when the mobile device 110 wakes up, NFC may be enabled and the mobile device 110 may be configured to read available tags, but no action is taken in response to the read.

[0050] To keep the counter 504 synchronized, an application, such as a background application, may be executed that is configured to detect when the mobile device 110 wakes up and synchronize with a server indicating that a reading resulting from the detection subsequently advances the counter 504. In another example, a hashed one-time password may be utilized to accommodate a window of missed synchronization. For example, if within a threshold of 10, the counter 504 may be configured to advance. However, if within a different threshold, e.g., 10 or 1000, a request to perform a resynchronization may be processed via one or more applications, requiring the user to tap, gesture, or otherwise indicate one or more times via the user's device. If the counter 504 increments in the proper sequence, it may be known that the user is doing so.

[0051] The contactless card 101 is configured to perform a key diversification technique using the counter 504, the master key 505, and the diversified key 506 to protect data (e.g., when transmitting the action data 103 to the mobile device 110). Generally, the server (or other computing device owned and / or operated by the issuer of the contactless card 101) and the contactless card 101 may be provisioned with the same master key 505 (also referred to as a master symmetric key). More specifically, each contactless card 101 is programmed with a distinct master key 505 that has a corresponding pair in the server. For example, when the contactless card 101 is manufactured, a unique master key 505 may be programmed into the memory 102 of the contactless card 101. Similarly, the unique master key 505 may be stored in the customer record associated with the contactless card 101 in the server's account data 119 (or in another secure location). The master key may be kept secret from all parties other than the contactless card 101 and the server.

[0052] The master key 505 may be used in combination with a counter 504 to enhance security using key diversification. The counter 504 comprises a value that is synchronized between the contactless card 101 and the server. The counter value 504 may comprise a number that changes each time data is exchanged between the contactless card 101 and the server (and / or the contactless card 101 and the mobile device 110). To enable NFC data transfer between the contactless card 101 and the mobile device 110, the account application 113 may communicate with the contactless card 101 when the contactless card 101 is sufficiently close to a card reader 120 of the mobile device 110. The card reader 120 may be configured to read from and / or communicate with the contactless card 101 (e.g., via NFC, Bluetooth, RFID, etc.). Thus, an exemplary card reader 120 includes an NFC communication module, a Bluetooth communication module, and / or an RFID communication module.

[0053] For example, a user can tap the contactless card 101 to the mobile device 110, thereby bringing the contactless card 101 close enough to the card reader 120 of the mobile device 110 to enable NFC data transfer between the contactless card 101 and the card reader 120 of the mobile device 110. After communication is established between the mobile device 110 and the contactless card 101, the contactless card 101 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 101 is read by the account application 113. In particular, this may occur upon a read, such as an NFC read of a Near Field Exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, the account application 113 and / or a reader, such as the card reader 120, may send a message, such as an applet selection message, using the applet ID of the NDEF generation applet. Once the selection is confirmed, a sequence of a select file message followed by a read file message may be sent. For example, the sequence may include "select feature file," "read feature file," and "select NDEF file." At this point, a counter value 504 maintained by the contactless card 101 may be updated or incremented, followed by "read NDEF file." At this point, a message may be generated that includes a header and a shared secret. A session key may then be generated. A MAC ciphertext may be created from the message, which may include the header and the shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with the session key. The ciphertext and header may then be concatenated, encoded as ASCII hexadecimal, and returned in an NDEF message format (in response to the "read NDEF file" message). In some examples, the MAC ciphertext may be sent as an NDEF tag, and in other examples, the MAC ciphertext may be included with a uniform resource indicator (e.g., as a formatted string).The contactless card 101 may then transmit the MAC cryptogram to the mobile device 110, which may then forward the MAC cryptogram to a server for verification, as described below. However, in some embodiments, the mobile device 110 may verify the MAC cryptogram.

[0054] More generally, when preparing to send data (e.g., to a server and / or mobile device 110), contactless card 101 may increment counter value 504. Contactless card 101 may then provide master key 505 and counter value 504 as inputs to an encryption algorithm, which generates diversified key 506 as output. The encryption algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of encryption algorithms may include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Contactless card 101 may then encrypt data (e.g., customer identifier 507 and any other data) using diversified key 506. Contactless card 101 may then transmit the encrypted data to account application 113 of mobile device 110 (e.g., via an NFC connection, a Bluetooth connection, etc.). The account application 113 of the mobile device 110 may then transmit the encrypted data to a server over a network (e.g., the Internet). In at least one embodiment, the contactless card 101 transmits the counter value 504 along with the encrypted data. In such an embodiment, the contactless card 101 may transmit the counter value 504 encrypted or unencrypted.

[0055] Upon receiving the encrypted customer ID 507, the server may perform the same symmetric encryption using the counter value 504 as input to the encryption and the master key 505 as the key for the encryption. As previously described, the counter value 504 may be specified in the data received from the mobile device 110 or a counter value 504 maintained by the server to implement key diversification for the contactless card 101. The output of the encryption may be the same diversified key value 506 created by the contactless card 101. The server may then use the diversified key 506 to decrypt the encrypted customer ID 507 received over the network, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 507). By doing so, the server can verify the data transmitted by the contactless card 101 via the mobile device 110, for example, by comparing the decrypted customer ID 507 with the customer ID in the account data for the account.

[0056] During the contactless card 101 creation process, two encryption keys may be uniquely assigned to each card. The encryption keys may comprise symmetric keys that may be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used in EMV and is implemented in hardware on the contactless card 101. A key diversification process may be used to derive one or more keys from a master key based on uniquely identifiable information for each entity needing a key.

[0057] In some examples, to overcome the flaws of the 3DES algorithm, which is susceptible to vulnerabilities, a session key (such as a unique key per session) can be derived, but rather than using a master key, a unique key derived from the card and a counter can be used as diversification data. For example, each time the contactless card 101 is used during operation, a different key can be used to create a message authentication code (MAC) and to perform encryption. This provides three layers of encryption. The session key can be generated by one or more applets and derived using an application transaction counter with one or more algorithms (specified in EMV4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0058] Additionally, the increment for each card is unique and may be assigned during personalization or algorithmically based on some identifying information. For example, odd cards may increment by 2, and even cards may increment by 5. In some instances, the increments may even vary with sequential reads, such that one card increments 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from the unique identifier. This may make it difficult for a replay attacker to generalize from a small number of card instances.

[0059] The authentication message may be delivered as the contents of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0060] 6 illustrates an embodiment of a logic flow 600. The logic flow 600 may represent 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 for determining an action to perform based on tapping the contactless card 101 against the computing device. In this context, the embodiments are not limited.

[0061] As shown, the logic flow 600 begins at block 610, where the account application 113 executing on the mobile device 110 authenticates credentials associated with the account. For example, a user attempting to access the account application 113 may provide a fingerprint, a login / password combination, or other credentials to access their account within the account application 113. In some embodiments, the account application 113 may receive transaction data associated with the account (e.g., from a server that processes transactions for the account). At block 620, the account application 113 and / or the tapping engine 115 may detect a tap of the contactless card 101 against the mobile device 110. For example, the contactless card 101 and the mobile device 110 may come within NFC communication range at block 620. At block 630, the account application 113 receives the action data 103 of the contactless card 101 via the communication interface of the contactless card 101. The account application 113 may then provide the action data 103 to the tapping engine 115. In one embodiment, contactless card 101 encrypts action data 103 using one or more key diversification techniques (e.g., using counter 504, master key 505, and diversified key 506). Account application 113 may then verify the encrypted action data 103 and / or forward the encrypted action data 103 to a server for verification.

[0062] At block 640, the tapping engine 115 determines the context of the mobile device 110. The context may include the context of the OS 112, the account application 113, and / or other applications 114. For example, the context may include determining which applications (and / or components of the OS 112) are output for display on the mobile device 110 and which functions and / or actions are associated with the applications output for display. At block 650, the tapping engine 115 may optionally generate one or more predicted actions based on one or more ML models 118. As mentioned, the ML models 118 may be trained based on training data, which may include past tapping data of the current user and / or multiple other users. By doing so, the ML models 118 can accurately predict one or more intended actions associated with tapping the contactless card 101 against the mobile device 110 at block 620.

[0063] At block 660, the tapping engine 115 determines an action associated with tapping the contactless card 101 on the mobile device 110 at block 620. Generally, the tapping engine 115 may determine the action based on one or more of the action data 103, the account data 119 of the authenticated account, the determined context, the rules 116, and / or the user profile 117. For example, as mentioned, in some embodiments, the action data 103 specifies an action (e.g., load content at a specified URL using the account application 113 and / or other applications 114). As another example, the tapping engine 115 may determine that the context of the mobile device 110 is associated with activating an inactive contactless card 101 and load a page of the account application 113 that allows the user to activate the contactless card 101. As yet another example, the ML model 118 may generate one or more candidate actions and associated scores. The tapping engine 115 may select the candidate action with the highest score.

[0064] At block 670, the OS 112, the account application 113, and / or the tapping engine 115 begin executing the action determined at block 660. For example, a phone application of the OS 112 may be opened and a phone number may be dialed for the user. As another example, a page of the account application 113 may be opened. As yet another example, a web page may be loaded by a web browser. At block 680, the account application 113 may optionally receive input specifying a user-defined action for tapping the contactless card 101. At block 690, the user-defined action may be stored in the memory of the contactless card 101 as action data 103. Doing so allows the user-defined action to be executed in response to a subsequent tap of the contactless card 101 against the mobile device 110.

[0065] 7 illustrates an embodiment of a logic flow 700. The logic flow 700 may represent 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 for determining the context of a computing device. In this context, the embodiments are not limited.

[0066] As shown, logic flow 700 begins at block 710, where tapping engine 115 determines one or more applications that are in the foreground of OS 112. In other words, tapping engine 115 determines one or more applications that are displayed on the display of mobile device 110. At block 720, tapping engine 115 determines the current output of the one or more applications determined at block 710. For example, tapping engine 115 may determine which page is output to a web browser based on the page's URL. As another example, tapping engine 115 may analyze text output by an application. As another example, tapping engine 115 may determine which page of account application 113 is currently being output for display.

[0067] At block 730, the tapping engine 115 determines one or more functions associated with the one or more applications determined in block 710. For example, the tapping engine 115 may determine, based on the web browser URL, that a web page is associated with transferring funds from one account to another. As another example, the tapping engine 115 may determine a function associated with a page of the account application 113 being output. As yet another example, the tapping engine 115 may determine concepts within text output by the application and determine a function based on the concepts.

[0068] At block 740, the tapping engine 115 optionally determines associated account data 119. For example, the account data 119 may reflect a purchase, a transaction, a card activation, or other account-related operation. The tapping engine 115 may consider the account data 119 when determining the context (e.g., if the user recently completed a purchase with the contactless card 101, the context may include the purchase). At block 750, the tapping engine 115 determines the context of the mobile device 110 based on one or more of the determinations made at blocks 710-740. By doing so, the tapping engine 115 can determine an action to perform in response to tapping the contactless card 101 against the mobile device 110.

[0069] 8 illustrates an embodiment of a logic flow 800. The logic flow 800 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 800 may include some or all of the operations for performing an action in response to tapping the contactless card 101 against a computing device. In this context, the embodiments are not limited.

[0070] As shown, logic flow 800 begins at block 810, where tapping engine 115 determines that action data 103 received from contactless card 101 (e.g., at block 630 of FIG. 6 ) specifies a URL. In response, tapping engine 115 causes the URL to be accessed and begins performing the action specified by the URL. For example, if the URL is for a phone number, tapping engine 115 may cause OS 112 to open a phone application and dial the phone number. As another example, if the URL is for a website, tapping engine 115 may cause OS 112 to launch a web browser and load the URL.

[0071] At block 820, the tapping engine 115 may determine that a user-defined action has been specified (e.g., in the user profile 117). The tapping engine 115 may then begin executing the user-defined action. For example, the user-defined action in the user profile 117 may specify that the home page of the account application 113 is to be loaded as a default action. Thus, the tapping engine 115 may load the home page in response to tapping the contactless card 101 against the mobile device 110. At block 830, the tapping engine 115 begins executing the action specified by the rule 116. For example, the default rule 116 may specify that the account details page of the account application 113 is to be loaded if no action is specified by the action data 103 and / or if no user-defined action is specified.

[0072] At block 840, the tapping engine 115 may optionally determine one or more candidate actions based on the context of the mobile device 110. For example, the tapping engine 115 may reference a mapping between the candidate actions and applications, functions, and / or contexts. The tapping engine 115 may then select one or more of the candidate actions to perform in response to tapping the contactless card 101 on the mobile device 110. At block 850, the tapping engine 115 generates one or more predicted actions based on the ML model 118 trained based on training data associated with the current user. In doing so, the current user's actions are taken into account when generating the candidate actions.

[0073] At block 860, the tapping engine 115 generates one or more predicted actions based on the ML model 118 trained on training data associated with multiple users, which may include the current user, so that the actions of all users are considered when generating candidate actions. At block 870, the tapping engine 115 optionally begins executing one or more of the candidate actions determined at block 840 and / or the predicted actions generated at blocks 850 and / or 860.

[0074] In some examples, the contactless card 101 may be tapped against devices, such as one or more computer kiosks or terminals, to verify identity to receive a transaction item in response to a purchase, such as coffee. Using the contactless card 101 may establish a secure method of proving identity in a loyalty program. For example, secure proof of identity or receipt of a benefit to obtain a reward, coupon, offer, or the like is established in a manner other than simply scanning a bar card. For example, an encrypted transaction may occur between the contactless card 101 and a device configured to process one or more tap gestures. As described above, one or more applications may be configured to verify the user's identity and prompt the user to take an action or response, for example, via one or more tap gestures. In some examples, data, such as bonus points, loyalty points, reward points, or healthcare information, may be written back to the contactless card.

[0075] In some examples, the contactless card 101 may be tapped to a device such as the mobile device 110. As described above, the user's identity may be verified by one or more applications that grant the user desired benefits based on the verification of the identity.

[0076] In some embodiments, the example authentication communication protocol may mimic, with some modifications, the EMV-standard offline dynamic data authentication protocol commonly performed between transaction cards and point-of-sale devices. For example, because the example authentication protocol is not used to complete a payment transaction with the card issuer / payment processor itself, some data values ​​are unnecessary, and authentication may be performed without requiring a real-time online connection to the card issuer / payment processor. As known in the art, a point-of-sale (POS) system submits a transaction, including a transaction value, to a card issuer. The issuer's approval or denial of the transaction may be based on whether the card issuer recognizes the transaction value. On the other hand, in certain embodiments of the present disclosure, transactions originating from a mobile device lack a transaction value associated with the POS system. Thus, in some embodiments, a dummy transaction value (i.e., a value recognizable to the card issuer and sufficient for activation) may be passed as part of the example authentication communication protocol. POS-based transactions may reject transactions based on the number of transaction attempts (e.g., a transaction counter). A soft rejection may occur when a number of attempts exceeds a buffer value. A soft rejection requires further validation before the transaction is accepted. In some implementations, the transaction counter buffer value may be modified to avoid rejection of legitimate transactions.

[0077] In some examples, the contactless card 101 may selectively communicate information depending on the recipient device. When tapped, the contactless card 101 may recognize the device the tap is aimed at, and based on this recognition, the contactless card may provide the appropriate data to that device. This advantageously allows the contactless card to transmit only the information necessary to complete an immediate action or transaction, such as a payment or card authentication. Limiting data transmission and avoiding the transmission of unnecessary data may improve both efficiency and data security. Information recognition and selective communication may be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and staged fraud prevention.

[0078] When a tap of contactless card 101 is directed at a device running Apple's iOS® operating system, e.g., an iPhone®, iPod®, or iPad®, the contactless card may recognize the iOS® operating system and transmit appropriate data to communicate with the device. For example, contactless card 101 may provide encrypted identification information necessary to authenticate the card using, for example, an NDEF tag via NFC. Similarly, when a tap of contactless card 101 is directed at a device running the Android® operating system, e.g., an Android® smartphone or tablet, the contactless card may recognize the Android® operating system and transmit appropriate data to communicate with the device (such as encrypted identification information necessary for authentication according to the methods described herein).

[0079] As another example, a contactless card tap may be directed to a point-of-sale device, including, but not limited to, a kiosk, checkout register, payment station, or other terminal. When the tap is performed, the contactless card 101 may recognize the point-of-sale device and transmit only the information necessary for the action or transaction. For example, upon recognizing the point-of-sale device used to complete a commercial transaction, the contactless card 101 may communicate the payment information necessary to complete the transaction under the EMV standard.

[0080] In some examples, a POS device participating in a transaction may request or specify additional information provided by the contactless card, such as, for example, device-specific information, location-specific information, transaction-specific information, etc. For example, when a POS device receives a data communication from a contactless card, the POS device may request additional information necessary to recognize the contactless card and complete the action or transaction.

[0081] In some examples, the POS device may be affiliated with an authorized merchant or other entity familiar with particular contactless cards or accustomed to performing particular contactless card transactions, although it will be understood that such an affiliation is not required to practice the described methods.

[0082] In some instances, such as shopping stores, grocery stores, convenience stores, etc., the contactless card 101 may be tapped to a mobile device without opening an application to indicate a desire or intent to use one or more reward points, loyalty points, coupons, offers, etc. to cover one or more purchases, thus providing the intent behind the purchase.

[0083] In some examples, one or more applications may be configured to determine that they were launched via one or more tap gestures on the contactless card 101, such as that the launch occurred at 3:51 PM and that a transaction was processed or made at 3:56 PM, in order to verify the user's identity.

[0084] In some examples, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, the one or more actions may comprise collecting rewards, collecting points, determining the most important purchases, determining the least expensive purchases, and / or reconfiguring to other actions in real time.

[0085] In some examples, data regarding tapping actions may be collected as biometric / gesture authentication. For example, a cryptographically secure and resistant to interception unique identifier may be transmitted to one or more backend services. The unique identifier may be configured to retrieve secondary information regarding the individual. The secondary information may comprise personally identifiable information regarding the user. In some examples, the secondary information may be stored within a contactless card.

[0086] In some examples, the device may include an application for splitting bills or checking payments among multiple individuals. For example, each individual may possess a contactless card and be a customer of the same issuing financial institution, but this is not required. Each of these individuals may receive a push notification on the device via the application to split the purchase. Rather than tapping the card only once to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may possess contactless cards 101 that provide information to initiate one or more payment requests from individuals tapping their cards.

[0087] In some examples, this disclosure refers to tapping a contactless card, however, it should be understood that this disclosure is not limited to tapping and includes other gestures (e.g., waving or other movements of the card).

[0088] 9 illustrates an embodiment of an exemplary computing architecture 900 comprising a computing system 902 suitable for implementing the various embodiments described above. In various embodiments, the computing architecture 900 may be configured or implemented as part of an electronic device. In some embodiments, the computing architecture 900 may represent, for example, a system implementing one or more components of the system 100. In some embodiments, the computing system 902 may represent, for example, the mobile device 110 of the system 100. The embodiments are not limited in this context. More generally, the computing architecture 900 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein.

[0089] As used in this application, the terms “system,” “component,” and “module” are intended to refer to any computer-related entity: hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 900. 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 may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other and coordinate operations by various types of communication media. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections, examples of which include parallel interfaces, serial interfaces, and bus interfaces.

[0090] Computing system 902 includes 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 902.

[0091] 9, computing system 902 includes a processor 904, a system memory 906, and a system bus 908. Processor 904 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 used as processor 904.

[0092] The system bus 908 provides an interface from the system memory 906 to system components including, but not limited to, the processor 904. The system bus 908 may be any of several types of bus structures that may further interconnect to 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 connect to the system bus 908 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0093] The system memory 906 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), polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 9, the system memory 906 may include non-volatile memory 910 and / or volatile memory 912. The non-volatile memory 910 may store a basic input / output system (BIOS).

[0094] Computing system 902 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) 914, a magnetic floppy disk drive (FDD) 916 that reads from or writes to a removable magnetic disk 918, and an optical disk drive 920 that reads from or writes to a removable optical disk 922 (e.g., a CD-ROM or DVD). HDD 914, FDD 916, and optical disk drive 920 may be connected to system bus 908 by an HDD interface 924, an FDD interface 926, and an optical drive interface 928, respectively. HDD interface 924 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Computing system 902 is generally configured to implement all of the logic, systems, methods, devices, and functions described herein with reference to FIGS. 1-8.

[0095] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 910, 912, including an operating system 930, one or more application programs 932, other program modules 934, and program data 936. In one embodiment, the one or more application programs 932, other program modules 934, and program data 936 may include, for example, various applications and / or components of system 100, such as operating system 112, account application 113, other applications 114, tapping engine 115, etc.

[0096] A user may enter commands and information into the computing system 902 through one or more wired / wireless input devices, for example, a keyboard 938 and a pointing device such as a mouse 940. 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, grab, 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 the processor 904 through an input device interface 942 coupled to the system bus 908, but may 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.

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

[0098] The computing system 902 may operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 948. The remote computer 948 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node and typically includes many or all of the elements described relative to the computing system 902, although for simplicity, only a memory / storage device 950 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 952 and / or larger networks, e.g., a wide area network (WAN) 954. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks such as intranets. All of these may connect to a global communications network, e.g., the Internet. In an embodiment, the network 130 of FIG. 1 is one or more of the LAN 952 and the WAN 954.

[0099] When used in a LAN networking environment, the computing system 902 is connected to the LAN 952 through a wired and / or wireless communication network interface or adapter 956. The adapter 956 may facilitate wired and / or wireless communication to the LAN 952, which may include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 956.

[0100] When used in a WAN networking environment, the computing system 902 may include a modem 958 or have other means for establishing communications over the WAN 954, such as connected to a communications server on the WAN 954 or via the Internet. The modem 958 may be internal or external, a wired and / or wireless device, and connects to the system bus 908 via the input device interface 942. In a networked environment, program modules depicted relative to the computing system 902, or portions thereof, may be stored in the remote memory / storage device 950. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0101] The computing system 902 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., IEEE 802.16 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, or to wired networks (using IEEE 802.3-related media and functions).

[0102] 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, a 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 required 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.

[0103] 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, which, when read by a machine, causes the machine to manufacture logic that performs the techniques described herein. Such representations, known as “IP cores,” are stored on tangible machine-readable media and provided to various customers or manufacturing facilities for loading into manufacturing machines that create 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 the 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 disk, floppy disk, compact disk read-only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile disks (DVDs), tape, cassette, 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., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0104] 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 by the appended claims. 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 as variously disclosed or demonstrated herein.

Claims

1. A method comprising: receiving, by a processor of a device, action data from a contactless card, the action data including a uniform resource locator (URL); determining, by the processor of the device, an application associated with the URL based on the action data; and the processor of the device, based on determining that the application is associated with the URL, opening the application; the application provides functionality associated with the contactless card; method.

2. determining by the processor of the device that the action data is associated with activating the contactless card; based on determining that the action data is associated with activating the contactless card, the processor of the device opening a card activation page of the application; The method of claim 1 further comprising:

3. The method further includes the card activation page of the application initiating activation of the contactless card; the activation of the contactless card being the functionality associated with the contactless card; The method of claim 2.

4. The method of claim 3, further comprising the processor of the device outputting a notification specifying that the contactless card has been activated.

5. The method of claim 2, wherein the processor of the device determines that the action data is associated with activating the contactless card based on activation instructions specified in the action data.

6. The method of claim 1, wherein the processor of the device determines that a component of a mobile operating system (OS) is in the foreground of the OS before opening the application; The method of claim 1 , wherein the application is further opened based on the determination that a component of the OS is in the foreground of the OS.

7. The method of claim 1 , wherein the action data is formatted according to the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 14443 format.

8. The method of claim 1 , wherein the action data is received via near field communication (NFC), and the action data is in NFC Data Exchange Format (NDEF).

9. a ciphertext received via the NFC and being the NDEF; The method further includes the application determining that the ciphertext has been verified by the application or server. The method of claim 8.

10. A non-transitory computer-readable storage medium containing instructions, The instructions, when executed by a processor of a device, cause the processor of the device to: receiving action data from the contactless card, the action data including a uniform resource locator (URL); determining an application associated with the URL based on the action data; based on determining that the application is associated with the URL, opening the application; Execute the application provides functionality associated with the contactless card; A non-transitory computer-readable storage medium.

11. The instructions may further include: the processor of the device determining that the action data is associated with activating the contactless card; Upon determining that the action data is associated with activating the contactless card, the processor opens a card activation page of the application.

11. The non-transitory computer-readable storage medium of claim 10, wherein the processor of the device is configured to:

12. The instructions further configure the processor of the device so that the card activation page of the application initiates activation of the contactless card; the activation of the contactless card being the functionality associated with the contactless card; The non-transitory computer-readable storage medium of claim 11.

13. 13. The non-transitory computer-readable storage medium of claim 12, wherein the instructions further configure the processor of the device to output a notification specifying that the contactless card has been activated.

14. A non-transitory computer-readable storage medium as described in claim 11, wherein the processor of the device determines that the action data is associated with activating the contactless card based on activation instructions specified in the action data.

15. The instructions configure the processor of the device to determine that a component of a mobile operating system (OS) is in the foreground of the OS before opening the application; the application is further opened based on the determination that the OS component is in the foreground of the OS. The non-transitory computer-readable storage medium of claim 10.

16. 11. The non-transitory computer-readable storage medium of claim 10, wherein the action data is received via near field communication (NFC), and the action data is in NFC Data Exchange Format (NDEF).

17. a processor; a memory for storing instructions, The instructions, when executed by the processor, cause the processor to: receiving action data from the contactless card, the action data including a uniform resource locator (URL); determining an application associated with the URL based on the action data; based on determining that the application is associated with the URL, opening the application; Execute the application provides functionality associated with the contactless card; Computing equipment.

18. The instructions may further include: determining that the action data is associated with activating the contactless card; and opening a card activation page of the application based on a determination that the action data is associated with activating the contactless card.

20. The computing device of claim 17, wherein the processor of the computing device is configured to:

19. The instructions further configure the processor of the computing device so that the card activation page of the application initiates activation of the contactless card; the activation of the contactless card being the functionality associated with the contactless card; 20. The computing device of claim 18.

20. The processor of the computing device determines, based on activation instructions specified in the action data, that the action data is associated with activating the contactless card; the action data is received via near field communication (NFC), and the action data is in NFC Data Exchange Format (NDEF); 20. The computing device of claim 18.

Images