Context Tapping Engine

Abstract

The present invention provides systems, methods, manufactured products, and computer-readable media for context tapping engines for contactless cards. [Solution] An application running on a computing device authenticates the credentials associated with an account, detects a tap of a contactless card on the computing device, receives action data from the contactless card's communication interface used to determine the action associated with the tap of the contactless card on the computing device, determines the context of the application based on the application's current output, determines a first action associated with the tap of the contactless card on the computing device based on the action data, the determined context, and the data associated with the account, and initiates the execution of the first action based on the tap of the contactless card.

Description

Technical Field

[0001] Embodiments of the present specification generally relate to contactless cards, and more specifically, to a context 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 on March 20, 2019. The entire content of the aforementioned application is incorporated herein by reference.

Background Art

[0003] Often, when a contactless card is tapped on a computing device, the computing device may execute a pre-defined action. However, since the pre-defined action is static, it may not be relevant when considering the intended action that the user wishes to perform. Similarly, the pre-defined action may not be relevant when considering the context of the computing device.

Summary of the Invention

[0004] Embodiments disclosed herein provide systems, methods, articles, and computer-readable media for a context tapping engine. For example, an application running on a computing device may authenticate credentials associated with an account and detect a tap of a contactless card associated with the account onto the computing device. The application may receive action data from the contactless card's communication interface, which is at least partially used to determine an action associated with the tap of the contactless card onto the computing device. The application may determine the context of the application, at least partially based on the application's current output. Based on the action data, the determined context, and the data associated with the account, the application may determine a first action associated with the tap of the contactless card onto 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 the execution of the first action based on the tap of the contactless card onto the computing device. [Brief explanation of the drawing]

[0005] [Figure 1] This shows an embodiment of a system for providing a context tapping engine. [Figure 2A] This shows an embodiment of a context tapping engine. [Figure 2B] This shows an embodiment of a context tapping engine. [Figure 3A] This shows an embodiment of a context tapping engine. [Figure 3B] This shows an embodiment of a context tapping engine. [Figure 4] This shows an example of defining the rules for a context tapping engine. [Figure 5A]An example of a contactless card is shown. [Figure 5B] An example of a contactless card is shown. [Figure 6] This shows an embodiment of the first logical flow. [Figure 7] This shows a second embodiment of the logic flow. [Figure 8] This shows an embodiment of the third logical flow. [Figure 9] This shows an embodiment of the computing architecture. [Modes for carrying out the invention]

[0006] Embodiments disclosed herein provide a context tapping engine that interprets a tap of a contactless card to a computing device and dynamically determines an action to be performed on the computing device in response to the tap. The context tapping engine may consider any number and types of elements when determining the action to be performed. For example, the context tapping engine may consider one or more of default actions, user-defined actions, context-determined actions, and / or predictive actions to determine the action to be performed in response to a particular tap. A default action may be a default action specified in the memory of the contactless card. A user-defined action may be an action defined by a user and stored in the memory of the contactless card. Context-determined actions may consist of actions dynamically generated by the computing device based at least partially on the current context of the computing device. Predictive actions may consist of actions generated by the computing device based at least partially on historical data from multiple users. In doing so, a variety of relevant actions can be performed in response to a tap of a contactless card to the computing device.

[0007] For example, a user may receive a new contactless card and tap the contactless card against their smartphone. In response to the tap, the smartphone may open the card activation page of the account management application. This allows 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 contactless card's memory. Once the card is activated, the user may tap the card against the smartphone again. The smartphone may then decide to open the account balance page of the account management application based on the context of the account management application. In response to other taps on the contactless card, the smartphone may leverage machine learning to predict the action associated with the tap. For example, the smartphone may predict loading the user-defined actions page of the account management application. On the user-defined actions page, the user may define an action (e.g., a call to customer service), which may be stored in the contactless card's memory. A user-defined action may include one or more rules (or criteria) that, if met, cause the smartphone to perform the user-defined action (e.g., a call to customer service).

[0008] Referring generally to the notation and nomenclature used herein, one or more parts of the following detailed descriptions may be presented relating to program procedures performed on a computer or a network of computers. The descriptions and representations of these procedures are intended to convey to those skilled in the art in the most effective way to the substance of their work. Procedures are generally considered to be a set of self-consistent operations leading to a desired result. These operations are those that require the physical manipulation of physical quantities. Usually, but not always, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. For reasons of common use, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

[0009] Furthermore, these operations are often referred to in terms such as addition or comparison, and these are generally associated with intelligent calculations performed by human operators. However, in any of the calculations described herein that form part of one or more embodiments, such ability of a human operator is not required, or in most cases, undesirable. Rather, these calculations are machine calculations. Useful machines for performing the calculations of various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings herein, and / or devices or digital computers specifically constructed for the required purpose. Various embodiments also relate to devices or systems for performing these calculations. These devices may be specifically constructed for the required purpose. The structures required for these various machines will become apparent from the given description.

[0010] Here, we refer to the drawings. Here, similar reference numbers are used throughout to refer to similar elements. In the following description, many specific details are given for illustrative purposes to fully understand them. However, it will be apparent that novel embodiments can be implemented without these specific details. In other examples, well-known structures and devices are shown in block diagram form to facilitate their description. The intent is to cover all modifications, equivalents, and alternatives within the claims.

[0011] Figure 1 shows a schematic diagram of an exemplary system 100 corresponding to the disclosed embodiment. As shown, system 100 includes one or more contactless cards 101 and one or more mobile devices 110. Contactless card 101 represents any type of payment card, such as a credit card, debit card, ATM card, or gift card. Contactless card 101 may comprise one or more chips (not shown), such as a radio frequency identification (RFID) chip, configured to communicate with mobile device 110 via NFC, EMV standards, or other short-range protocols in wireless communication, or using NFC Data Interchange Format (NDEF) tags. While NFC is used as an example of a communication protocol in this specification, this disclosure is equally applicable to other types of wireless communication, such as EMV standards, Bluetooth®, and / or Wi-Fi. Mobile device 110 represents any type of network-enabled computing device, such as a smartphone, tablet computer, wearable device, laptop, or portable gaming device.

[0012] As shown, the contactless card memory 102 includes a data store for action data 103. 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, action data 103 may include URLs directed to websites, applications (e.g., the account application 113 and / or other applications 114), application pages (e.g., the account application 113 and / or other applications 114 on the mobile device 110), components of the OS 112, or other computing resources. Upon receipt by 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 the relevant action. For example, the tapping engine 115 may determine the 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 yet another example, the tapping engine 115 may generate a predictive action that predicts the user's intent based on historical data (e.g., previous actions performed by the user and / or other users). The tapping engine 115 may then initiate the execution of the contextual action and / or predictive action on the mobile device 110.

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

[0015] As shown, the memory 111 of the mobile device 110 contains 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 the user to perform various account-related operations, such as viewing account balances, purchasing items, and processing payments. First, the user may authenticate using authentication credentials to access certain functions of the account application 113. For example, 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 the action associated with tapping the contactless card 101 to the mobile device 110. As previously stated, the tapping engine 115 is configured to determine predefined actions associated with the tap, user-defined actions associated with the tap, generate contextual actions associated with the tap, and generate predictive actions associated with the tap. Generally, when the contactless card 101 is tapped to the mobile device 110 (e.g., brought into wireless range), the mobile device 110 may receive one or more records of action data 103 from the communication interface of the contactless card 101 (e.g., NFC, Bluetooth®, EMV, etc.).

[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, when determining an action to perform on the mobile device 110, the tapping engine 115 may further determine the context of the mobile device 110. The tapping engine 115 may determine the context based on any attribute of the mobile device 110, such as which applications are running on the mobile device 110, which applications are in the foreground of the mobile device 110's display, what functions are associated with the foreground applications, parsing the data displayed on the device's display, user profile 117 data, and / or account data 119 data (e.g., transaction data, purchase data, etc.).

[0018] Furthermore, in some embodiments, the tapping engine 115 may generate a predicted action that reflects the user's intent when determining an action to perform on the mobile device 110. For example, after the user taps the contactless card 101 on the mobile device 110, the user may repeatedly access the account statement page. In such an example, after detecting the tap of the contactless card 101 on the mobile device 110 by the user, the tapping engine 115 may load the account statement page. 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 taps of contactless cards on the device by a plurality of different users. 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 a predicted action for a given tap of the contactless card 101 on 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, where the score reflects the likelihood that the action was intended by the user. Next, the tapping engine 115 may select the predicted action with the highest score and initiate the execution of the selected predicted action.

[0019] As described above, in some embodiments, the action data 103 specifies a default action (for example, loading the card activation page of the account application 113 when a contactless card 101 that has not been activated for use is tapped on 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 the tap of an inactive card. In another example, the action data 103 may include a flag that reflects that the card has not been activated, and the tapping engine 115 loads the account activation page when it detects the flag indicating that the card has not been activated. In 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 yet 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 a flag from the server and load an account activation page accordingly. Once the card is activated, different actions may be stored as action data 103. These 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 the customer service department by phone number. The URL stored in action data 103 may specify that the OS 112's phone application (e.g., one of the other applications 114) should open and dial the customer service department's phone number. In such an example, the tapping engine 115 opens the phone application and dials the customer service department's phone number for the user who responds to the receipt of action data 103 based on a tap of the contactless card 101.

[0021] As another example, action data 103 is general and interpreted by the tapping engine 115 (e.g., using context and / or prediction) to determine the relevant action. For example, if a user taps a contactless card 101 on a mobile device 110 while viewing the homepage of the account application 113, the tapping engine 115 may determine that the context of the mobile device 110 is related to the relevant account (e.g., determining the concept of the text to be output to the homepage based on the homepage's URL). Accordingly, the tapping engine 115 can load the account balance page of the account application 113, which allows the user to view their account balance and other detailed account information. Thus, the tapping engine 115 may monitor the actions performed by the user and store instructions for the actions (along with the determined context) in the user profile 117 and / or account data 119. As another example, when a contactless card 101 is tapped on a mobile device 110, the tapping engine 115 may determine that account data 119 reflects that a purchase was made using the contactless card 101 (for example, using a web browser in another application 114) within a predefined time frame (e.g., 30 seconds, 1 minute, etc.). Thus, the tapping engine 115 may perform actions related to the purchase. For example, the tapping engine 115 may programmatically schedule payment for the purchase on a due date. As yet 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 relevant actions 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 a web browser currently contains 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 a web page in a web browser, or the Document Object Model (DOM) of a web page. In such an example, the tapping engine 115 may output a notification specifying that the contactless card 101 should be tapped on the device 110 to copy the account number of the card 101 into the account number field.

[0022] In some embodiments, when 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 has been performed. Additional notifications may specify to the user that any action can be linked to the card tap, including user-defined actions and / or one or more predefined actions that the user can select.

[0023] Rule 116 generally includes one or more rules that can be used by the tapping engine 115 to determine an action in response to a tap. For example, a rule in Rule 116 might specify payment for a movie ticket with reward points if the user spends more than $10 on movie tickets within a specified time. In such an example, the tapping engine 115 might detect a tap on the contactless card 101 and analyze the user's spending data in the account data 119 to determine that the user spent $20 on movie tickets within the specified time. In response, the tapping engine 115 might programmatically generate a contextual action that could include payment for a movie ticket with reward points, or loading a page in the account application 113 that allows the user to pay for a 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 different elements of action data 103. In such an example, a single package may be decrypted, parsed, and used for one or more purposes (e.g., accessing a URL, calling a phone number, and / or filling in a form field). For example, if the multiple elements of action data 103 are separated by comma delimiters, the tapping engine 115 may parse each element based on the comma delimiters and perform one or more operations associated with each element of the action data.

[0025] Figure 2A is a schematic diagram 200 showing an example of a tapping engine 115 that determines an action in response to a tap of a contactless card 101 on 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 on the mobile device 110, the contactless card 101 may send action data 103 to the mobile device 110. However, the action data 103 cannot specify the action to be performed (e.g., access to a URL such as an application or page). Therefore, the tapping engine 115 may determine the action to be performed 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 the 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 decide to perform an action related to customer service, such as initiating a call to customer service or loading a more detailed customer service page into the account application 113.

[0027] Additionally and / or alternatively, the tapping engine 115 may leverage the ML model 118 to determine the 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 displayed, that the context relates to customer service, application history, and / or the page was output for display on the mobile device 110, etc.). Furthermore, the ML model 118 may consider the history of tap actions performed by relevant user responses and / or the history of tap actions performed by multiple users. For example, the history of tap actions may show that the most frequent action performed in response to tapping the contactless card 101 when a customer service FAQ page is displayed is dialing customer service. The ML model 118 may further consider the rules 116, user profiles 117, and / or account data 119. Next, the ML model 118 may generate one or more candidate actions to perform and return the candidate action with the highest score as the action to be performed in response to the tapping of the contactless card 101 on the mobile device 110.

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

[0029] Figure 3A is a schematic diagram 300 showing an example of a tapping engine 115 that determines an action in response to a tap of a contactless card 101 on a mobile device 110, according to one embodiment. As previously mentioned, when the contactless card 101 is tapped on the mobile device 110, the contactless card 101 may send action data 103 to the mobile device 110. However, the action data 103 is generic and cannot specify the action to be performed. Therefore, the tapping engine 115 may determine an action to be performed in response to the tap.

[0030] As shown, the account application 113 on the mobile device 110 is outputting a homepage containing instructions for another user account. The tapping engine 115 may receive instructions from the account application 113 that the homepage is being output for display. The tapping engine 115 may decide on an action based on the context of the mobile device 110. As stated, the tapping engine 115 may determine the context by determining that the homepage of the account application 113 is being displayed. The tapping engine 115 may further determine the context by analyzing the output of the homepage (e.g., arbitrary text and / or images) to determine the concepts associated with the homepage. 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 decide to access the detailed account page of the account application 113.

[0031] Figure 3B is a schematic diagram 310 showing an embodiment in which the tapping engine 115 causes the account application 113 to load the account details page associated with the contactless card 101 (for example, based on the account number of the contactless card 101). As stated, the tapping engine 115 may decide to load the account details page in response to the 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 be loaded when the contactless card 101 is tapped while the homepage 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] Figure 4 is a schematic diagram 400 showing an exemplary user-defined action to be stored in action data 103 of a contactless card 101 according to one embodiment. As shown, the graphical user interface of the account application 113 allows the user to define the action. For example, in GUI element 401, the user specifies that the action should be applied to a tap of the contactless card 101 while the account application 113 is outputting the homepage (e.g., the homepage in Figure 3A). Furthermore, in GUI element 402, the user specifies that by tapping the contactless card 101 while the account application 113 is outputting the homepage, the detailed balance page associated with the account (e.g., the account details page in Figure 3B) should be loaded. The input provided in GUI element 401 can be manually entered by the user and / or selected by the user from multiple options (e.g., a dropdown list of options). Once submitted, the account application 113 generates action data 103-1, which is sent to the contactless card 101. Next, the contactless card 101 may store the action data 103-1 as a record of the action data 103 in the memory of the contactless card 101. In one embodiment, the action data 103-1 includes a URL that points to the account details page of the account application 113. However, in other embodiments, the action data 103-1 includes additional information (for example, a rule specifying that if the homepage of the account application 113 is currently open on the mobile device 110, the URL to the account details page should be followed).

[0033] Figure 5A shows a contactless card 101 that 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 502, which is displayed on the front or back of the card 101. In some examples, the contactless card 101 may include an identification card that is not related to a payment card, but is not limited to this. In some examples, the payment card may be a dual-interface contactless payment card. The contactless card 101 may include 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, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 may have physical properties that conform to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, the contactless card 101 relating to this disclosure may have different characteristics, and this disclosure should be understood as not requiring contactless card functionality for 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 a mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may also include processing circuits, an antenna, and other components not shown in Figure 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 that may be located on the back of the card (not shown in Figure 5A).

[0035] As shown in Figure 5B, the contact pads 520 of the contactless card 101 may include a processing circuit 525 for storing and processing information, which includes a microprocessor 530 and memory 102. It is understood that the processing circuit 525 may include additional components, including the processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware necessary to perform the functions described herein.

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

[0037] Memory 102 may be configured to store action data 103, one or more applets 540, one or more counters 504, and one or more customer identifiers 507. One or more applets 540 may comprise one or more software applications configured to run on one or more contactless cards, such as Java® card applets. However, it is understood that applet 540 is not limited to Java card applets and could instead be any software application capable of running on contactless cards or other devices with limited memory. One or more counters 504 may comprise numeric counters sufficient to store integers. Customer identifiers 507 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, the identifier being able to distinguish a user of a contactless card from other contactless card users. In some examples, customer identifiers 507 may identify both the customer and the account assigned to that customer, and further identify the contactless card associated with the customer's account.

[0038] While the processor and memory elements of the exemplary embodiments described above have been described with reference to the contact pads, the disclosure is not limited thereto. It is understood that these elements may be implemented as additional elements in addition to the processor 530 and memory 102 elements located outside or completely separated from the pads 520, or within the contact pads 520.

[0039] In some examples, the contactless card 101 may have one or more antennas 555. One or more antennas 555 may be located inside the contactless card 101 and around the processing circuit 525 of the contact pads 520. For example, one or more antennas 555 may be integrated with the processing circuit 525, or one or more antennas 555 may be used with an external booster coil. In other examples, one or more antennas 555 may be located outside 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 side of an air-core transformer. A 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 by using a gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 101 may return communication by switching the load of the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil by interference. More generally, using an antenna 555, processing circuit 525, and / or memory 102, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth®, and / or Wi-Fi communication.

[0041] As described above, the contactless card 101 may be built on a software platform capable of running on memory-limited smart cards or other devices such as Java cards, and one or more applications or applets may be securely executed. The applet may be added to the contactless card and provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to respond to one or more requests, such as a Near Field Data Exchange request from a reader (e.g., of a mobile device 110), and generate an NDEF message with a cryptographically secure OTP encoded as an NDEF text tag.

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

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

[0044] In some examples, one or more applet 540 may be configured to maintain its personalized state and allow personalization only after unlocking and authentication. Other states may have pre-personalization in a standard state. Upon entering the exit state, one or more applet 540 may be configured to delete the personalized data. In the exit state, one or more applet 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 can be used in authentication messages. In some examples, this can be interpreted as a major version in the most significant byte and a minor version in the least significant byte. The rules for each version are configured to interpret the authentication message. For example, with respect to the major version, this may include each major version having a specific authentication message layout and a specific algorithm. With respect to the minor version, this may include changes to the authentication message or encryption algorithm, or changes to static tag content, in addition to bug fixes, security enhancements, etc.

[0046] In some examples, one or more applet 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, the NFC reading of the tag may be processed, the data may be sent to a server, and the data may be verified by 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 have 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 (for example, by a mobile device 110), the counter 504 is sent to the server for verification to determine whether the counter value 504 is equal (as part of the verification).

[0048] One or more counters 504 may be configured to prevent replay attacks. For example, if a ciphertext is retrieved and replayed, and counter 504 is read, used, or otherwise passed, the ciphertext is immediately rejected. If counter 504 is not used, it can be replayed. In some examples, a counter incremented on the card is different from a counter incremented for a 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 have a first applet 540-1 and a second applet 540-2, which may be transaction applets. Each applet may have a counter 504.

[0049] In some cases, counter 504 may not be synchronized. In some cases, counter 504 may be incremented to account for accidental reads that initiate a transaction, such as reads at a certain angle, but the application does not process counter 504. In some cases, when the mobile device 110 is woken 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 reads.

[0050] To maintain the synchronization of counter 504, an application such as a background application may be run, configured to detect when the mobile device 110 wakes up and to synchronize with a server indicating that any reads resulting from the detection subsequently advance counter 504. In another example, a hashed one-time password could be used to accept a window of synchronization misses. For example, if it is within a threshold of 10, counter 504 may be configured to advance. However, if it is within a different threshold, e.g., 10 or 1000, a request to perform a resynchronization may be handled through one or more applications, requiring the user to tap, gesture, or otherwise indicate one or more times via the user's device. If counter 504 is increasing in the appropriate sequence, it is possible to know that the user is doing so.

[0051] The contactless card 101 is configured to protect data by performing key diversification techniques using a counter 504, a master key 505, and a diversified key 506 (for example, when sending action data 103 to a mobile device 110). Generally, the server (or any 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 called a master symmetric key). More specifically, each contactless card 101 is programmed with a separate master key 505, which 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 the counter 504 to enhance security using key diversification. The counter 504 has a value that is synchronized between the contactless card 101 and the server. The counter value 504 may have a number that changes each time data is exchanged between the contactless card 101 and the server (and / or between 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 close enough to the 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, the 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 a contactless card 101 to a 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) ciphertext. In some examples, this may occur when the contactless card 101 is read by an account application 113. In particular, this may occur during readings such as NFC reading of Near Field Radio Data Exchange (NDEF) tags, which may be created according to the NFC Data Exchange format. For example, an 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 selection file messages followed by a read file message may be sent. For example, the sequence may include "Select Function File," "Read Function File," and "Select NDEF File." At this point, the counter value 504 maintained by the contactless card 101 may be updated or incremented, followed by "Read NDEF File." At this point, a message containing a header and a shared secret may be generated. Next, a session key may be generated. A MAC ciphertext may be created from the message, which may contain a header and a shared secret. Next, the MAC ciphertext may be concatenated with one or more blocks of random data, and the MAC ciphertext and random numbers (RND) may be encrypted with the session key. Then, the ciphertext and header may be concatenated, encoded as ASCII hexadecimal, and returned in 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).Next, the contactless card 101 may transmit the MAC ciphertext to the mobile device 110, which may then forward the MAC ciphertext to a server for verification, as described below. However, in some embodiments, the mobile device 110 may verify the MAC ciphertext.

[0054] More generally, when preparing to transmit data (e.g., to a server and / or mobile device 110), the contactless card 101 may increment a counter value 504. The contactless card 101 may then provide a master key 505 and the counter value 504 as input to an encryption algorithm, which generates a diversified key 506 as output. The encryption algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, crypto-based message authentication code (CMAC) algorithms, 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. The contactless card 101 may then encrypt the data (e.g., customer identifier 507 and other arbitrary data) using the diversified key 506. The contactless card 101 may then transmit the encrypted data to the account application 113 on the mobile device 110 (e.g., via NFC connection, Bluetooth® connection, etc.). Next, the account application 113 of the mobile device 110 may transmit encrypted data to a server over a network (e.g., the Internet). In at least one embodiment, the contactless card 101 transmits a counter value 504 along with the encrypted data. In such an embodiment, the contactless card 101 may transmit either an encrypted counter value 504 or an unencrypted counter value 504.

[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 encryption. As previously mentioned, the counter value 504 may be data received from the mobile device 110 or a counter value 504 maintained by the server to perform key diversification of 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 decrypt the encrypted customer ID 507 received over the network using the diversified key 506, 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 of the account.

[0056] During the creation process of the contactless card 101, two encryption keys may be uniquely assigned to each card. The encryption keys may be symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm may be used with EMV and implemented in the hardware of the contactless card 101. By using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information of each entity that requires a key.

[0057] In some examples, to overcome vulnerabilities in the 3DES algorithm, session keys (such as unique keys per session) can be derived, but instead of using a master key, unique keys derived from the card and counters can be used as diversification data. For example, each time contactless card 101 is used in operation, a different key may be used to generate the message authentication code (MAC) and to perform encryption. This achieves three-layer encryption. Session keys can be generated by one or more applets and derived using application transaction counters with one or more algorithms (as defined in EMV4.3Book2A1.3.1 Common Session Key Derivation).

[0058] Furthermore, the increment of each card is unique and can be assigned by personalization or by an algorithm based on some identifying information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some examples, the increment may also vary with sequential reads, such as a single card incrementing sequentially as 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This can 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 content of a text NDEF record in hexadecimal ASCII format. In other examples, the NDEF record may be encoded in hexadecimal format.

[0060] Figure 6 shows an embodiment of the logical flow 600. The logical flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 600 may include some or all of the operations for determining an action to be performed based on a tap of the contactless card 101 on a computing device. Embodiments are not limited in this context.

[0061] As shown, the logical flow 600 begins in block 610, where an account application 113 running on the mobile device 110 authenticates the 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 the account's transactions). In block 620, the account application 113 and / or the tapping engine 115 may detect a tap of the contactless card 101 on the mobile device 110. For example, the contactless card 101 and the mobile device 110 may be within NFC communication range in block 620. In block 630, the account application 113 receives action data 103 of the contactless card 101 via the contactless card 101's communication interface. The account application 113 may then provide the action data 103 to the tapping engine 115. In one embodiment, the contactless card 101 encrypts the action data 103 using one or more key diversification techniques (for example, using a counter 504, a master key 505, and a diversified key 506). The account application 113 then verifies the encrypted action data 103 and / or forwards the encrypted action data 103 to the server for verification.

[0062] In 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. In 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 on training data, which includes historical tapping data of the current user and / or several other users. By doing so, the ML models 118 can accurately predict one or more intended actions associated with tapping the contactless card 101 on the mobile device 110 in block 620.

[0063] In block 660, the tapping engine 115 determines the action associated with the tap of the contactless card 101 on the mobile device 110 in block 620. Generally, the tapping engine 115 may determine the action based on one or more of the following: action data 103, account data 119 of the authenticated account, the determined context, rule 116, and / or user profile 117. For example, as mentioned, in some embodiments, the action data 103 specifies the action (e.g., load content at a specified URL using the account application 113 and / or other application 114). In another example, the tapping engine 115 may determine that the context of the mobile device 110 is related to 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. In 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] In block 670, the OS 112, the account application 113, and / or the tapping engine 115 begin executing the actions determined in block 660. For example, the phone application of the OS 112 may be opened and a phone number may be dialed for the user. Another example is opening a page in the account application 113. Yet another example is loading a web page by a web browser. In block 680, the account application 113 may optionally receive input specifying a user-defined action for a tap of the contactless card 101. In block 690, the user-defined action may be stored as action data 103 in the memory of the contactless card 101. In this way, the user-defined action can be executed in response to a subsequent tap of the contactless card 101 on the mobile device 110.

[0065] Figure 7 shows an embodiment of the logical flow 700. The logical flow 700 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 700 may include some or all of the operations for determining the context of a computing device. In this context, embodiments are not limited.

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

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

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

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

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

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

[0072] In 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 refer to a mapping between 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 a tap of the contactless card 101 on the mobile device 110. In block 850, the tapping engine 115 generates one or more predictive actions based on an ML model 118 trained on training data associated with the current user. In doing so, the current user's actions are taken into consideration when generating candidate actions.

[0073] In block 860, the tapping engine 115 generates one or more predictive actions based on an ML model 118 trained on training data associated with multiple users, which may include the current user. In this way, the actions of all users are considered when generating candidate actions. In block 870, the tapping engine 115 optionally starts executing one or more of the candidate actions determined in block 840, and / or the predictive actions generated in blocks 850 and / or 860.

[0074] In some examples, a contactless card 101 may be tapped on one or more devices, such as computer kiosks or terminals, to verify identity in order to receive transaction items in response to a purchase, such as coffee. Using a contactless card 101 can establish a secure method of verifying identity in a loyalty program. For example, secure verification of identity or receipt of rewards, coupons, offers, etc., is established in a way different from simply scanning a bar card. For example, an encrypted transaction may occur between the contactless card 101 and a device configured to handle 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 action or respond, for example, via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, and healthcare information may be written back to the contactless card.

[0075] In some examples, the contactless card 101 may be tapped onto a device such as a 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 identity verification.

[0076] In some embodiments, the example authentication communication protocol may mimic, with some modifications, an EMV-standard offline dynamic data authentication protocol commonly used between transaction cards and point-of-sale (POS) devices. For example, since the example authentication protocol is not used to complete payment transactions 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 is known in the art, a point-of-sale (POS) system submits a transaction containing transaction values ​​to the card issuer. Whether the issuer approves or rejects the transaction may depend on whether the card issuer is aware of the transaction values. On the other hand, in certain embodiments of this disclosure, transactions originating from a mobile device lack transaction values ​​associated with the POS system. Therefore, in some embodiments, a dummy transaction value (i.e., a value that the card issuer is aware of and that is sufficient to perform activation) may be passed as part of the example authentication communication protocol. POS-based transactions may reject a transaction based on the number of attempts (e.g., a transaction counter). If the number of attempts exceeds a buffer value, a soft rejection may occur. A soft rejection requires further verification before the transaction can be accepted. In some implementations, the transaction counter buffer value may be modified to avoid rejecting legitimate transactions.

[0077] In some cases, the contactless card 101 may selectively communicate information depending on the receiving device. When tapped, the contactless card 101 may recognize the device to which the tap is directed, and based on this recognition, the contactless card may provide the appropriate data to that device. This has the advantage that the contactless card can transmit only the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting the transmission of data and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. Information recognition and selective communication can be applied to a variety of scenarios, such as card activation, balance transfer, attempts to access an account, commercial transactions, and the prevention of staged fraud.

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

[0079] As another example, contactless card taps may be directed to POS devices including, but not limited to, kiosks, checkout registers, payment stations, or other terminals. When a tap is performed, the contactless card 101 may recognize the POS device and transmit only the information necessary for the action or transaction. For example, upon recognizing a POS 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 device-specific information, location-specific information, or transaction-specific information. For example, when a POS device receives data communication from a contactless card, it may recognize the contactless card and request additional information necessary to complete an action or transaction.

[0081] In some cases, a POS device may partner with an authorized vendor or other entity that is familiar with or accustomed to performing certain contactless card transactions. However, it is understood that such partnerships are not required for the implementation of the described method.

[0082] In some examples, such as shopping stores, grocery stores, and convenience stores, a contactless card 101 can be tapped on a mobile device without opening an application to indicate a desire or intention to use one or more reward points, loyalty points, coupons, offers, etc., to cover one or more purchases. In this way, the intention behind the purchase is provided.

[0083] In some examples, one or more applications may be configured to determine, in order to verify the user's identity, that the activation occurred via one or more tap gestures on the contactless card 101, such as that the activation occurred at 3:51 p.m., or that the transaction was processed or performed at 3:56 p.m.

[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, one or more actions may include collecting rewards, collecting points, deciding on the most important purchase, deciding on the cheapest purchase, and / or reconfiguring into other actions in real time.

[0085] In some examples, data related to tapping can be collected as biometric / gesture authentication. For example, a cryptographically secure and intercept-resistant unique identifier may be sent to one or more backend services. The unique identifier may be configured to retrieve secondary information about the individual. The secondary information may consist of personally identifiable information about the user. In some examples, the secondary information may be stored within a contactless card.

[0086] In some examples, the device may feature an application that splits bills among multiple individuals and checks payments. For example, each individual may, but not be required, possess a contactless card and be a customer of the same issuing financial institution. Each of these individuals may receive a push notification on the device via the application to split a purchase. Instead of 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 the individual tapping the card.

[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, such as waving or other movements of the card.

[0088] Figure 9 shows an exemplary embodiment of the computing architecture 900, comprising a computing system 902 suitable for carrying out the various embodiments described above. In various embodiments, the computing architecture 900 may be configured or carried out as part of an electronic device. In some embodiments, the computing architecture 900 may represent, for example, a system that carries out one or more components of system 100. In some embodiments, the computing system 902 may represent, for example, a mobile device 110 of system 100. Embodiments are not limited to this context. More generally, the computing architecture 900 is configured to carry out all the logic, applications, systems, methods, devices, and functions described herein.

[0089] The terms “system,” “component,” and “module” as used in this application are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or running software, examples of which are provided by the 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, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized to one computer and / or distributed across two or more computers. Furthermore, components may be coupled together in a communicative manner by various types of communication media and their operation may be coordinated. Coordination may include the one-way or two-way exchange of information. For example, components may communicate information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. Such data messages can be transmitted over various connections. Examples of connections include parallel interfaces, serial interfaces, and bus interfaces.

[0090] The computing system 902 includes various common computing elements such as one or more processors, multicore processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, and power supplies. However, the embodiments are not limited to those implemented by the computing system 902.

[0091] As shown in Figure 9, the computing system 902 includes a processor 904, system memory 906, and a system bus 908. The 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 multiprocessor architectures may also be used as the processor 904.

[0092] The system bus 908 provides an interface to system components, including but not limited to system memory 906 and processor 904. The system bus 908 can be one of several types of bus structures that can further interconnect to the memory bus (with or without a memory controller), peripheral buses, and local buses using any of various commercially available bus architectures. Interface adapters can connect to the system bus 908 via slot architectures. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extensible) (PCI(X)), PCI Express, and Personal Computer Memory Card International Association (PCMCIA).

[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 (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 drives (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in Figure 9, the system memory 906 may include non-volatile memory 910 and / or volatile memory 912. The non-volatile memory 910 may store the Basic Input / Output System (BIOS).

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

[0095] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in 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 an operating system 112, an account application 113, other applications 114, and a tapping engine 115.

[0096] The user may input commands and information to the computing system 902 via one or more wired / wireless input devices, such as a keyboard 938 and a pointing device such as a mouse 940. Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, gamepads, stylus pens, card readers, dongles, fingerprint readers, grabs, graphic tablets, joysticks, keyboards, retina readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processor 904 via an input device interface 942 coupled to the system bus 908, but may also be connected via other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, or an IR interface.

[0097] The monitor 944 or other types of display devices are also connected to the system bus 908 via an interface such as the video adapter 946. The monitor 944 may be located inside or outside the computing system 902. In addition to the monitor 944, the computer typically includes other peripheral output devices such as speakers and printers.

[0098] The computing system 902 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computers 948. The remote computers 948 could be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer devices, or other common network nodes, typically including many or all of the elements described in relation to the computing system 902, but for brevity, only the memory / storage device 950 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 952 and / or a larger network, such as a wide area network (WAN) 954. Such LAN and WAN network environments are common in offices and businesses and facilitate enterprise-scale computer networks such as intranets. All of these may connect to global communication networks, such as the Internet. In embodiments, the network 130 in Figure 1 is one or more of the LAN 952 and WAN 954.

[0099] When used in a LAN networking environment, the computing system 902 is connected to the LAN 952 via a wired and / or wireless 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 placed on it to communicate with the wireless capabilities of the adapter 956.

[0100] When used in a WAN networking environment, computing system 902 may include a modem 958, or be connected to a communication server on the WAN 954, or have other means for establishing communication on the WAN 954, such as via the Internet. The modem 958 may be internal or external, wired and / or wireless, and connect to the system bus 908 via an input device interface 942. In a network environment, the program modules, or parts thereof, shown with respect to computing system 902 may be stored in a remote memory / storage device 950. The shown network connections are illustrative, and it will be understood that other means may be used to establish communication links between computers.

[0101] Computing system 902 is capable of communicating with wired and wireless devices or entities using the IEEE 802 standard family, such as wireless devices configured to operate wirelessly (e.g., IEEE 802.16 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMAX, and Bluetooth® wireless technologies. Thus, communication can be a predefined structure, similar to conventional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies known as IEEE 802.11x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to connect 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 processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computed code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination of whether an embodiment is implemented using hardware and / or software elements may vary depending on any number of factors, such as required computing speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus rate, and other design or performance constraints.

[0103] One or more aspects of at least one embodiment can be implemented by representative instructions stored in a machine-readable medium representing various logics within a processor, which, when read by a machine, produce logic that performs the techniques described herein. Such representations, known as "IP cores," are stored in tangible machine-readable medium and provided to various customers or manufacturing facilities for loading into manufacturing machines that create logic or processors. Some embodiments can be implemented using, for example, a machine-readable medium or article that can store instructions or a set of instructions that, when executed by a machine, can cause a machine to perform methods and / or operations according to the embodiment. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. Machine-readable media or articles 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 rewritable (CD-RW), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile disks (DVDs), tapes, cassettes, etc. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, cryptographic 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 is provided for illustrative and explanatory purposes only. It is not intended to be exhaustive or to limit this disclosure to the exact form disclosed. Many modifications and changes are possible in light of this disclosure. The scope of this disclosure is intended to be limited by the appended claims rather than by this detailed description. Future applications claiming priority to this application may assert the disclosed subject matter in different ways and may generally include any set of one or more limitations, as variously disclosed or demonstrated herein.

Claims

1. Processor circuit and A device comprising a memory for storing instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: The application executed on the aforementioned processor circuit authenticates the credentials associated with the account, The application detects the tapping of the contactless card associated with the account to the device, The application receives action data from the communication interface of the contactless card, which is at least partially used to determine the action associated with the tap of the contactless card to the device. The application determines the context of the application, at least partially based on the application's current output. The application determines a first action as the action associated with the tap of the contactless card to the device, based on the action data, the determined context, and the data associated with the account, wherein the first action is associated with the application and at least one of the operating systems (OS) running on the processor circuit. The application initiates the execution of the first action based on the tap of the contactless card on the device, To execute Device.

2. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: The process involves receiving a machine learning (ML) model, the ML model being generated based on training data describing multiple actions performed in response to multiple taps of multiple contactless cards on multiple devices, and the contactless cards being associated with one of the accounts among the multiple contactless cards, where, The application generates predictive actions based on the action data, the determined context, and the ML model. Based on the tap of the contactless card on the device, the predicted action is determined as the first action, To execute The apparatus according to claim 1.

3. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: Receiving a machine learning (ML) model, the ML model being generated based on training data describing multiple actions performed in response to multiple taps of the contactless card associated with the account to the device, The application generates predictive actions based on the action data, the determined context, and the ML model. Based on the tap of the contactless card on the device, the predicted action is determined as the first action, To execute The apparatus according to claim 1.

4. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: Determining the context of the application based on at least one function and at least one contactless card associated with the current output of the application, wherein the current output of the application comprises a page displayed on the device's display, To execute The apparatus according to claim 1.

5. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: The application determines the user-defined action specified in the data associated with the account, The application determines the user-defined action as the first action, To execute The apparatus according to claim 1.

6. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: The device receives input specifying a user-defined action to associate the tap of the contactless card with the context of the application, The memory of the contactless card stores instructions for the tap of the contactless card to the device and the user-defined actions associated with the context of the application, To execute The apparatus according to claim 1.

7. The aforementioned memory stores instructions, When the aforementioned instruction is executed by the processor circuit, the processor circuit will: The application determines that the action data comprises a uniform resource locator (URL), and initiating the execution of the first action includes performing the operation associated with the URL. To execute The apparatus according to claim 1.

8. The first action comprises one or more of the following: (i) making a phone call, (ii) loading a page of the application, (iii) activating a component of the OS, (iv) accessing the functionality of a different application running on the OS, and (v) activating the contactless card. The apparatus according to claim 1.

9. A non-temporary computer-readable storage medium in which computer-readable program code is materialized, wherein the computer-readable program code, which is executable by a processor circuit, is provided to the processor circuit. The application executed on the aforementioned processor circuit authenticates the credentials associated with the account, The application detects the tapping of the contactless card associated with the account on the device, The application receives action data from the communication interface of the contactless card, which is at least partially used to determine the action associated with the tap of the contactless card to the device. The application determines the context of the application, at least partially based on the application's current output. The application determines a first action as the action associated with the tap of the contactless card to the device, based on the action data, the determined context, and a machine learning (ML) model, wherein the first action comprises an action performed by at least one of the application and the operating system (OS) running on the processor circuit. The application initiates the execution of the first action based on the tap of the contactless card on the device, A non-temporary computer-readable storage medium that enables execution of [a certain action].

10. The non-temporary computer-readable storage medium contains computer-readable program code executable by the processor circuit, and the processor circuit contains: The process involves generating an ML model based on training data describing multiple actions performed in response to multiple taps of multiple contactless cards on multiple devices, wherein each contactless card is associated with one of the multiple contactless cards and the account. A non-temporary computer-readable storage medium according to claim 9, further comprising computer-readable program code that causes the execution of the program.

11. The non-temporary computer-readable storage medium contains computer-readable program code executable by the processor circuit, and the processor circuit contains: Determining the context of the application based on at least one function and at least one contactless card associated with the current output of the application, wherein the current output of the application comprises a page displayed on the device's display, and the first action comprises one or more of the following: (i) making a phone call, (ii) loading a page of the application, (iii) activating a component of the OS, (iv) accessing a function of a different application running on the OS, and (v) activating the contactless card. A non-temporary computer-readable storage medium according to claim 9, further comprising computer-readable program code that causes the execution of the program.

12. The non-temporary computer-readable storage medium contains computer-readable program code executable by the processor circuit, and the processor circuit contains: The application determines a user-defined action specified by the data associated with the account, The application determines the user-defined action as the first action, A non-temporary computer-readable storage medium according to claim 9, further comprising computer-readable program code that causes the execution of the program.

13. The non-temporary computer-readable storage medium contains computer-readable program code executable by the processor circuit, and the processor circuit contains: Receiving input specifying a user-defined action to associate the tap of the contactless card on the device with the context of the application, The memory of the contactless card stores instructions for the user-defined action associated with the tapping of the contactless card to the device and the context of the application, A non-temporary computer-readable storage medium according to claim 9, further comprising computer-readable program code that causes the execution of the program.

14. The non-temporary computer-readable storage medium contains computer-readable program code executable by the processor circuit, and the processor circuit contains: The application determines that the action data comprises a uniform resource locator (URL), and initiating the execution of the first action includes performing the operation associated with the URL. A non-temporary computer-readable storage medium according to claim 9, further comprising computer-readable program code that causes the execution of the program.

15. The application running on the device's processor circuitry authenticates the credentials associated with the account, The application detects the tapping of the contactless card associated with the account on the device, The application receives action data from the communication interface of the contactless card, which is at least partially used to determine the action associated with the tap of the contactless card to the device. The application determines the context of the application, at least partially based on the application's current output. The application determines a first action as the action associated with the tap of the contactless card, based on the action data, the determined context, and a machine learning (ML) model, wherein the first action comprises an action performed by at least one of the application and the operating system (OS) running on the processor circuit. The application initiates the execution of the first action based on the tap of the contactless card on the device, Methods that include...

16. The aforementioned method, The method involves generating an ML model based on training data describing multiple actions performed in response to multiple taps of multiple contactless cards on multiple devices, wherein each contactless card is associated with one of the multiple contactless cards and the account. The method according to claim 15, further comprising:

17. The aforementioned method, Determining the context of the application based on at least one function and at least one contactless card associated with the current output of the application, wherein the current output of the application comprises a page displayed on the device's display, and the first action comprises one or more of the following: (i) making a phone call, (ii) loading a page of the application, (iii) activating a component of the OS, (iv) accessing a function of a different application running on the OS, and (v) activating the contactless card. The method according to claim 15, further comprising:

18. The aforementioned method, The application determines the user-defined action specified in the data associated with the account, The application determines the user-defined action as the first action, The method according to claim 15, further comprising:

19. The aforementioned method, Receiving input specifying a user-defined action to associate the tap of the contactless card on the device with the context of the application, The memory of the contactless card stores instructions for the user-defined action associated with the tapping of the contactless card to the device and the context of the application, The method according to claim 15, further comprising:

20. The aforementioned method, The application determines that the action data comprises a uniform resource locator (URL), and initiating the execution of the first action includes performing the operation associated with the URL. The method according to claim 15, further comprising:

Images