KR102775416B1 - Tapping engine in context - Google Patents

Abstract

Various embodiments of a contextual tapping engine are disclosed. For example, an application running on a computer device may authenticate credentials associated with an account and detect a tap of a contactless card to the computer device. The application may receive, from a communications interface of the contactless card, motion data used to determine an action associated with the tap of the contactless card to the computer device. The application may determine a context of the application based on current output of the application. The application may determine a first action associated with the tap of the contactless card to the device, a first action associated with at least one of the application and an operating system (OS), based on the motion data, the determined context, and the data associated with the account. The application may initiate performance of the first action based on the tap of the contactless card.

Description

Tapping engine in context

Embodiments of the present disclosure relate generally to contactless cards, and more particularly to a contextual tapping engine for contactless cards. This application claims the benefit of U.S. patent application Ser. No. 16/359,987, filed March 20, 2019, entitled "Contextual Tapping Engine," which is incorporated herein by reference in its entirety.

United States Patent Application Publication No. US 2019/0011989 (January 10, 2019) discloses execution of actions by an application program of a computer device based on a gesture detected via a gesture component. The input is detected using a three-dimensional object detection system of the gesture component of the computer device. However, the prior art does not disclose a technique for generating a predicted action using the motion data provided by the contactless card of the present invention. The present invention often causes the computer device to perform a predefined action when a contactless card is tapped to the computer device. However, the predefined action may be static and therefore may not be related to the intended action that the user is trying to perform. Similarly, the predefined action may not be relevant in the context of the computer device.

Embodiments disclosed herein provide systems, methods, articles of manufacture and computer-readable media for a tapping engine in the context of the present disclosure. In one embodiment, an application running on a computer device can authenticate credentials associated with an account and detect a tap of a contactless card associated with the account to the computer device.

The application may receive action data from the communication interface of the contactless card that is at least partially used to determine an action associated with a tap of the contactless card to a computer device.

An application can determine the context of the application based at least in part on the application's current output.

The application can determine a first action associated with a tap of the contactless card to the computer device based on the action data, the determined context, and data associated with the account, wherein the first action is associated with at least one of an operating system (OS) running on the processor circuit or an application.

The application can initiate performance of a first action based on a tap of a contactless card to a computer device.

Figure 1 illustrates an embodiment of a system providing a contextual tapping engine.
Figures 2a and 2b illustrate embodiments of a tapping engine in context.
Figures 3a and 3b illustrate embodiments of a contextual tapping engine.
Figure 4 illustrates an embodiment defining rules for a tapping engine in context.
Figures 5a and 5b illustrate embodiments of a contactless card.
Figure 6 illustrates an embodiment of the first logic flow.
Figure 7 illustrates an embodiment of the second logic flow.
Figure 8 illustrates an embodiment of the third logic flow.
Figure 9 illustrates an embodiment of the computer architecture.

Embodiments disclosed herein provide a contextual tapping engine that interprets a tap of a contactless card to a computer device and dynamically determines an action to be performed on the computer device in response to the tap. The contextual tapping engine may consider several types of factors when determining the action to perform.

For example, a contextual tapping engine may consider one or more of a default action, a user-defined action, a contextually determined action, and/or a predicted action to determine what action to perform in response to a given 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 the user and stored in the memory of the contactless card.

The contextually determined actions may include actions that are dynamically generated by the computer device based at least in part on the current context of the computer device. The predicted actions may include actions that are generated by the computer device based at least in part on historical data from multiple users. This allows for performing a variety of relevant actions in response to a contactless card tap on the computer device.

For example, a user may receive a new contactless card and tap the contactless card to the smartphone. In response to the tap, the smartphone may open a card activation page of an account management application that allows the user to activate the card. The smartphone may open the card activation page based on a unique resource locator (URL) specified in the motion data in the memory of the contactless card.

Once the card is activated, the user can tap the card again on the smartphone. The smartphone can then decide to open the account balance page of the account application based on the context of the account management application. The smartphone responding to other taps of the contactless card can use machine learning to predict the action associated with the tap.

For example, a smartphone may be expected to load a custom action page of an account management application. On the custom action page, a user may define an action (e.g., call customer service), which may be stored in the memory of the contactless card. The custom action may include one or more rules (or criteria) that, when met, cause the smartphone to perform the custom action (e.g., call customer service).

In general, referring to the notation and nomenclature used in this specification, one or more portions of the following detailed description may be presented in terms of program procedures executed on a computer or a computer network. Such procedural descriptions and representations are used by those skilled in the art to most effectively convey the essence of the task to those skilled in the art. A procedure is generally considered to be a coherent sequence of operations leading to a desired result. Such operations are operations that require physical manipulation of physical quantities.

Usually, but not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient, mainly for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, and so on. It should be noted, however, that all these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to the quantities in question.

These operations are also generally referred to in terms such as addition or comparison, which are mental operations performed by human operators. However, such capabilities of human operators are not necessary or in most cases desirable for any of the operations described herein that form part of one or more embodiments. Rather, these operations are machine operations.

Useful machines for performing the operations of the various embodiments include a digital computer selectively activated or configured by a computer program recorded in accordance with the teachings of the present disclosure and/or a device or digital computer specially constructed for the required purpose. Various embodiments also relate to devices or systems for performing these operations. Such devices may be specially constructed for the required purpose. The structures required for these various machines will be apparent from the given description.

Reference will now be made to the drawings, wherein like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. However, it will be apparent that the novel embodiments may be practiced without these specific details.

In other examples, well-known structures and devices are shown in block diagram form to facilitate explanation. It is intended to cover all modifications, equivalents, and alternatives within the scope of the claims.

FIG. 1 illustrates a schematic diagram of an exemplary system (100) consistent with the disclosed embodiments. As illustrated, the system (100) includes one or more contactless cards (101) and one or more mobile devices (110). The contactless card (101) represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, and the like. The contactless card (101) may include one or more chips (not shown), such as a radio frequency identification (RFID) chip configured to communicate with the mobile device (110) via NFC, the EMV standard, or other short-range protocol in wireless communication, or using an NFC Data Exchange Format (NDEF) tag.

Although NFC is used as an exemplary communication protocol herein, the present invention is equally applicable to other types of wireless communications, such as the EMV standard, Bluetooth, and/or Wi-Fi. The mobile device (110) represents any type of network-based computing device, such as a smart phone, a tablet computer, a wearable device, a laptop, a portable gaming device, and the like.

As illustrated, the memory (102) of the contactless card includes a data store of motion data (103). The motion data (103) represents any type of data that can be interpreted by the tapping engine (115) of the account application (113). For example, the motion data (103) may include a URL linking to a website, an application, such as the account application (113) and/or other applications (114), an application page, such as the account application (110) and/or other applications (114) of the mobile device (110), a component of the OS (112), or other computer resource. When received by the tapping engine (115), the tapping engine (115) may cause the mobile device (110) to load the resource specified by the URL.

In another embodiment, the motion data (103) may include rules, conditions, and/or other data that enable the tapping engine (115) to determine an associated motion. For example, the tapping engine (115) may determine a context of the mobile device (110) and determine a contextual motion based on the context of the mobile device (110) and the motion data (103). In another embodiment, the tapping engine (115) may generate predictive data predicting the user's intent based on historical data, such as previous motions performed by the user and/or other users. The tapping engine (115) may then initiate performance of the contextual motion and/or the predicted motion for the mobile device (110).

Additionally, the motion data (103) may store a user-defined action that may be interpreted by the tapping engine (115) to perform a user-defined action on the mobile device (110). The user-defined action of the motion data (103) may also include a URL as one or more rules or other conditions that must be satisfied before the tapping engine (115) performs the user-defined action.

As illustrated, the memory (111) of the mobile device (110) includes an instance of an operating system (OS) (112). Exemplary operating systems (112) include Android® OS, iOS®, Linux®, and Windows® operating systems. As illustrated, the OS (112) includes an account application (113) and one or more other applications (114). The account application (113) allows a user to perform various account-related actions, such as viewing account balances, purchasing items, and processing payments.

Initially, a user may authenticate using authentication credentials to access specific features of the account application (113). For example, the authentication credentials may include a user name and password, biometric credentials, etc.

As illustrated, 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 actions associated with a tap. As described above, the tapping engine (115) is configured to determine predefined actions associated with a tap, user-defined actions associated with a tap, generate contextual actions associated with a tap, and generate predicted actions associated with a tap.

Typically, when a contactless card (101) is tapped to a mobile device (110) (e.g., brought into wireless communication range), the mobile device (110) may receive one or more records of operation data (103) from a communication interface (e.g., NFC, Bluetooth, EMV, etc.) of the contactless card (101).

The tapping engine (115) can determine an action to perform on the mobile device (110) based at least in part on the motion data (103). For example, the motion data (103) can specify a URL. In some embodiments, the tapping engine (115) can additionally determine the context of the mobile device (110) when determining the action to perform on the mobile device (110). The tapping engine (115) can determine the context based on any of the following properties of the mobile device (110): an application running on the mobile device (110), an application in the foreground of the display of the mobile device (110), functionality associated with the foreground application, analysis of data displayed on the display of the device, data in the user profile (117) and/or data in the account data (119), such as transaction data, purchase data, etc.

Additionally, in some embodiments, the tapping engine (115) may generate predictive actions that reflect the user's intent when determining which action to perform on the mobile device (110). For example, a user may repeatedly access an account statement page after tapping a contactless card. In such an embodiment, the tapping engine (115) may detect a tap of the contactless card (101) to the mobile device (110) by the user and then load the account statement page.

In another embodiment, the tapping engine (115) may utilize a trained ML model (118) based on training data. The training data may describe past actions performed in response to taps of a contactless card to the device by a number 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) to the mobile device (110).

For example, the tapping engine (115) may provide one or more motion data (103), determined context, rules (116), user profile (117), and/or account data (119) that may generate one or more predicted motions to the ML model (118). The ML model (118) may further compute a score for each predicted motion, where the score reflects the likelihood that the motion is an intended motion by the user. The tapping engine (115) may select the predicted motion with the highest score and initiate execution of the selected predicted motion.

As noted, in some embodiments, the action data (103) specifies a basic action, for example, loading a card activation page of the account application (113) when a contactless card (101) that is not activated for use is tapped to the mobile device (110). Accordingly, in such embodiments, the tapping engine (115) loads the account activation page of the account application (113) in response to a tap of a deactivated card.

As another embodiment, the action data (103) may include a flag indicating that the card is not activated, and the tapping engine (115) may load an account activation page upon detecting the flag indicating that the card is not activated. As another embodiment, the tapping engine (115) may determine that the tapping engine (115) has not previously communicated with the card (101) to load an account activation page.

In another embodiment, the flag may be stored on a server maintained by the issuer of the contactless card (101). The flag stored on the server may indicate that the card has been sent to the customer but has not yet been activated. The tapping engine (115) may receive the flag from the server and, in response, load an account activation page. Once the card is activated, another action may be stored as action data (103). The other action may be generated by the contactless card (101) itself, the account application (113), and/or the user.

In another embodiment, the action data (103) specifies a user-defined action, such as calling a customer service department by phone number. The URL stored in the action data (103) may specify to open a phone application of the OS (112), for example one of the other applications (114), and dial the phone number for the customer service department. In this embodiment, the tapping engine (115) opens the phone application and dials the phone number for the customer service department for the user in response to receiving the action data (103) based on a tap of the contactless card (101).

In another embodiment, the motion data (103) is interpreted by the tapping engine (115) using, for example, context and/or prediction to determine common and associated motions. For example, if a user taps a contactless card (101) to the mobile device (110) while viewing the home page of an account application (113), the tapping engine (115) may determine whether the context of the mobile device (110) is related to the associated account, for example, by determining concepts within text displayed on the home page based on the URL of the home page.

In response, the tapping engine (115) may load an account balance page of the account application (113) that allows the user to view his or her account balance and other detailed account information. Accordingly, the tapping engine (115) may monitor actions performed by the user and store an indication of the action in the account data (119) along with the user profile (117) and/or determined context.

As another embodiment, when a contactless card (101) is tapped to a mobile device (110), the tapping engine (115) may determine that the account data (119) reflects that a purchase was made using the contactless card, for example, using a web browser of another application (114), within a predefined time period, for example, 30 seconds, 1 minute, etc. In this manner, 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 another embodiment, the tapping engine (115) may load a rewards page to allow the customer to pay for the purchase using rewards points.

As another embodiment, the tapping engine (115) may determine the associated action based on the presence of one or more form fields in the 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 metadata of the form field, reading the source code of the web page in the web browser, the document object model (DOM) of the web page, etc. Accordingly, in this embodiment, the tapping engine (115) may output a notification to the device (110) specifying that the contactless card (101) be tapped to copy the account number of the card (101) into the account number field.

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 may be associated with the card tap, including user-defined actions and/or one or more predefined actions that the user may select.

Rules (116) typically include one or more rules that can be used by the tapping engine (115) to determine an action to take in response to a tap. For example, a rule of rule (116) may specify that a movie ticket is to be paid for with reward points if the user spends more than $10 on movie tickets within a specified time period. In such an embodiment, the tapping engine (115) may detect a tap of 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 period.

In response, the tapping engine (115) may programmatically generate a contextual action that may include paying for movie tickets with reward points or loading a page of an account application (113) that enables the user to pay for movie tickets with reward points.

In some embodiments, the contactless card (101) may transmit multiple elements of motion data (103) to the device (110). For example, the encrypted package may include multiple elements of motion data (103) and delimiters and/or metadata used by the tapping engine (115) to parse other elements of the motion data (103).

In such embodiments, a single package may be decoded, parsed, and used for one or more purposes, such as navigating to a URL, calling a phone number, and/or filling out a form field. For example, if multiple elements of the 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.

FIG. 2A is a schematic diagram (200) illustrating an embodiment of a tapping engine (115) that determines an action in response to a tap of a contactless card (101) to a mobile device (110) according to one embodiment. As shown, an account application (113) on the mobile device (110) outputs a customer service page that includes frequently asked questions (FAQs) for customer service issues. When the contactless card (101) is tapped to the mobile device (110), the contactless card (101) may transmit action data (103) to the mobile device (110). However, the action data (103) may not specify an action to perform, such as accessing a URL for an application, a page, etc. Accordingly, the tapping engine (115) may determine the action to perform in response to the tap.

In at least one embodiment, the tapping engine (115) determines the context of the mobile device (110) to determine which action to perform. For example, the tapping engine (115) may determine that a customer service page of an account application (113) is currently displayed on the mobile device (110). For example, the tapping engine (115) may analyze text on the customer service page and detect concepts related to customer service.

Accordingly, the tapping engine (115) may determine that the context of the mobile device (110) is related to customer service. As such, the tapping engine (115) may determine to perform an action related to customer service, such as initiating a phone call to customer service, loading a more detailed customer service page in the account application (113), etc.

Additionally and/or optionally, the tapping engine (115) may utilize a machine learning (ML) model (118) to determine an action associated with a tap of the contactless card (101) to 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), such as whether a customer service page is being displayed, whether the context is related to customer service, a history of applications and/or pages output for display on the mobile device (110), and the like.

Additionally, the ML model (118) may consider the history of tap actions performed by the responding associated user and/or the history of tap actions performed by multiple users.

For example, a history of tap actions may indicate that the most frequent action performed in response to a tap of a contactless card (101) while a customer service FAQ page is displayed is dialing customer service. The ML model (118) may further consider rules (116), user profiles (117), and/or account data (119). The ML model (118) may then generate one or more candidate actions to perform and return to the mobile device (110) the candidate action with the highest score as the action to perform in response to a tap of the contactless card (101).

FIG. 2b is a schematic diagram (210) illustrating an embodiment in which the tapping engine (115) determines to open a phone application to dial customer support on behalf of the user. As such, the tapping engine (115) may initiate the opening of the phone application of the OS (112) and cause the phone application to dial a phone number associated with customer support. For example, the tapping engine (115) may determine to dial customer support based on the determined context of the mobile device (110) of FIG. 2a.

Additionally and/or optionally, the ML model (118) may determine that calling customer support is the most likely action to be performed by the user based on a computed score for each candidate action. Additionally and/or optionally, the tapping engine (115) may determine to call customer support based on a rule specified in the rule (116) (and/or the user profile (117)), wherein the rule specifies that a call to customer service is made when a customer service-related page of the account application (113) is displayed.

FIG. 3A is a schematic diagram (300) illustrating an embodiment of a tapping engine (115) that determines an action in response to a tap of a contactless card (101) to a mobile device (110) according to one embodiment. As mentioned, when the contactless card (101) is tapped to the mobile device (110), the contactless card (101) may transmit action data (103) to the mobile device (110). However, the action data (103) may be generic and may not specify an action to be performed. Accordingly, the tapping engine (115) may determine an action to be performed in response to a tap.

As illustrated, the account application (113) on the mobile device (110) outputs a home page that includes a display of one or more accounts of the user. The tapping engine (115) may receive an indication from the account application (113) that the home page is being output for display. The tapping engine (115) may determine an action based on the context of the mobile device (110). As described above, the tapping engine (115) may determine the context by determining that the home page of the account application (113) is being displayed.

The tapping engine (115) may further determine context by analyzing output from the home page, for example, arbitrary text and/or images, to determine concepts related to the home page. Thus, the tapping engine (115) may determine that the context of the mobile device (110) is related to the user's account. Based on the determined context, the tapping engine (115) may decide to access the detailed account page of the account application (113).

FIG. 3b is a schematic diagram (310) illustrating an embodiment in which the tapping engine (115) causes the account application (113) to load a detail page for an account associated with a contactless card (101), for example, based on the account number of the contactless card (101). As noted, the tapping engine (115) may determine to load a detail page for an account in response to a tap based on the context of the mobile device.

Additionally and/or optionally, a user may specify a rule (116) instructing the user to load an account detail page when a contactless card (101) is tapped while the home page is displayed. Additionally and/or optionally, the tapping engine (115) may predict, based on the ML model (118), that the user intends to load an account detail page in response to a tap.

FIG. 4 is a schematic diagram (400) illustrating an exemplary user-defined action to be stored in the action data (103) of a contactless card (101) according to one embodiment. As illustrated, the graphical user interface of the account application (113) allows a user to define an action. For example, in the GUI element (401), the user has specified that the action be applied to a tab of the contactless card (101) while the account application (113) outputs a home page, for example, the home page of FIG. 3a.

Additionally, in the GUI element (402), the user may specify that while the account application (113) is outputting the home page, the tab of the contactless card (101) should load a detailed balance page associated with the account, for example, the account details page of FIG. 3b. The input provided in the GUI element (401) may be manually entered by the user or may be selected by the user from a number of options, for example, a drop down list of options.

When submitted, the account application (113) generates motion data (103-1) that is transmitted to the contactless card (101). The contactless card (101) can store the motion data (103-1) as a record of the motion data (103) within the memory of the contactless card (101).

In one embodiment, the action data (103-1) includes a URL that links to an account detail page of the account application (113). However, in another embodiment, the action data (103-1) includes additional information, for example, a rule specifying that the URL should link to the account detail page if the home page of the account application (113) is currently open on the mobile device (110).

FIG. 5A illustrates a contactless card (101) that may include a payment card, such as a credit card, a debit card, and/or a gift card. As illustrated, the contactless card (101) may be issued by a service provider (502) that is indicated on the front or back of the card (101). In some embodiments, the contactless card (101) is not associated with a payment card and may include, without limitation, identification. In some embodiments, the payment card may include a dual interface contactless payment card.

The contactless card (101) may include a substrate (510) that may include a single layer or one or more laminated layers of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinylacetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodic titanium dioxide, palladium, gold, carbon, paper, and biodegradable materials.

In some embodiments, the contactless card (101) may have physical characteristics that comply with the ID-1 format of the ISO/IEC 7810 standard, or alternatively, the contactless card may comply with the ISO/IEC 14443 standard. However, it is understood that the contactless card (101) according to the present invention may have different characteristics and that the present invention does not require implementing a contactless card within a payment card.

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

As illustrated in FIG. 5b, the contact pads (520) of the contactless card (101) may include processing circuitry (525) for storing and processing information, including a microprocessor (530) and memory (102). It should be appreciated that the processing circuitry (525) may include additional components, including a processor, memory, error and parity/CRC checkers, a data encoder, an anti-collision algorithm, a controller, a command decoder, security primitives, and tamper-resistant hardware, necessary to perform the functions described herein.

The memory (102) may be a read-only memory, a write-once-read-many (WORM) memory, or a read/write memory, such as a RAM, a ROM, and an EEPROM, and the contactless card (101) may include one or more of these memories. The read-only memory may be read-only or one-time programmable at the factory. The one-time programming capability provides the opportunity to write once and read many times. The WORM memory may be programmed at a specific point in time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. The read/write memory may be programmed and reprogrammed many times after it leaves the factory. The read/write memory may also be read many times after it leaves the factory.

The memory (102) may be configured to store operation data (103), one or more applets (540), one or more counters (504), and one or more customer identifiers (507). The one or more applets (540) may include one or more software applications configured to run on one or more contactless cards, such as Java® Card applets. However, it should be understood that the applets (540) are not limited to Java Card applets and may be any software applications operable on a contactless card or other device having limited memory.

One or more of the counters (504) may include a numeric counter sufficient to store an integer. The customer identifier (507) may include a unique alphanumeric identifier assigned to a user of the contactless card (101), which identifier may distinguish a user of the contactless card from other users of contactless cards. In some embodiments, the customer identifier (507) may identify both the customer and an account assigned to the customer, and may additionally identify a contactless card associated with the customer's account.

In the above-described embodiments, the processor and memory elements have been described with reference to the contact pads, but the present invention is not limited thereto. It should be understood that these elements may be implemented external to the pads (520), implemented completely separately, or implemented as additional elements in addition to the processor (530) and memory (102) elements located within the contact pads (520).

In some embodiments, the contactless card (101) may include one or more antennas (555). The one or more antennas (555) may be positioned internally within the contactless card (101) and around the processing circuitry (525) of the contact pads (520). For example, the one or more antennas (555) may be integrated with the processing circuitry (525) and the one or more antennas (555) may be used with an external booster coil. In other embodiments, the one or more antennas (555) may be external to the contact pads (520) and the processing circuitry (525).

In one embodiment, the coil of the contactless card (101) can act as an alternative to an air-core transformer. The terminal can communicate with the contactless card (101) by blocking the power or amplitude modulation. The contactless card (101) can infer data transmitted from the terminal by utilizing a gap in the power connection of the contactless card, which can be maintained functionally through one or more capacitors. The contactless card (101) can switch the load on the coil of the contactless card or communicate again through load modulation. The load modulation can be detected at the terminal coil through interference.

More generally, the contactless card (101) uses an antenna (555), processing circuitry (525) and/or memory (102) to provide a communication interface that communicates via NFC, Bluetooth and/or Wi-Fi communications.

As described above, the contactless card (101) can be built on a software platform that can operate on other devices with limited memory, such as a smart card or a JavaCard, and can securely execute one or more applications or applets. An applet can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet can be configured to respond to one or more requests, such as a near-field data exchange request from a reader, such as a mobile NFC reader of a mobile device (110), and generate an NDEF message containing an encrypted secure OTP encoded in an NDEF text tag.

One embodiment of the NDEF OTP is the NDEF Short Record Layout (SR = 1). In such an embodiment, one or more applets (540) may be configured to encode the OTP as an NDEF Type 4 Well Known Type Text Tag. In some embodiments, the NDEF message may include one or more records. The applet (540) may be configured to add one or more static tag records in addition to the OTP record.

In some embodiments, the contactless card (101) and the server (120) may include certain data so that the card can be properly identified. The contactless card (101) may include one or more unique identifiers (not shown). The counter (104) may be configured to increment each time a read operation occurs. In some embodiments, each time data from the contactless card (101) is read, for example by a mobile device (110), the counter (104) is transmitted to the server for verification and a determination is made as part of the verification that the counter values (104) are equal.

In some embodiments, one or more of the applets (540) may be configured to maintain a personalized state to allow personalization only when unlocked and authenticated. Other states may include a pre-personalization standard state. Upon entering a terminated state, one or more of the applets (540) may be configured to remove personalized data. In a terminated state, one or more of the applets (540) may be configured to stop responding to all application program protocol data unit (APDU) requests.

One or more applets (540) may be configured to maintain an applet version (2 bytes) that may be used in authentication messages. In some embodiments, this may be interpreted as a most significant byte major version, and a least significant byte minor version.

Rules for each version are shaped to interpret the authentication message. For example, for major versions, this may include that each major version has a specific authentication message layout and a specific algorithm. For minor versions, this may include bug fixes, security enhancements, as well as changes to the authentication message or encryption algorithms and changes to static tag content.

In some embodiments, one or more applets (540) may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some embodiments, each time the tag is read, different encrypted data is 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 and the data may be transmitted to a server, where the data may be verified.

In some embodiments, the contactless card (101) and the server may include certain data so that the card can be properly identified. The contactless card (101) may include one or more unique identifiers (not shown). The counter (504) may be configured to increment each time a read operation occurs. In some embodiments, each time data from the contactless card (101) is read, for example by a mobile device (110), the counter (504) is transmitted to the server for verification and, as part of the verification, a determination is made as to whether the counter values (504) are equal.

One or more counters (504) may be configured to prevent replay attacks. For example, if a password is obtained and replayed, the password is immediately rejected if the counter (504) is read, used, or passed. If the counter (504) is not used, it may be replayed. In some embodiments, the counter that is incremented on the card is different from the counter that is 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 embodiments, the contactless card (101) may include a first applet (540-1) and a second applet (540-2), which may be transaction applets. Each applet may include a counter (504).

In some embodiments, the counter (504) may not be synchronized. In some embodiments, the counter (504) may be incremented to account for accidental reads that initiate a transaction, such as an oblique read, but the application does not process the counter (504). In some embodiments, when the mobile device (110) wakes up, NFC is enabled and the mobile device (110) may be configured to read an available tag, but does not take any action in response to the read.

An application, such as a background application, may be run to keep the counter (504) in sync. The mobile device (110) may be configured to detect when it wakes up and syncs with the server (120) and display a reading resulting from that detection to move the counter (504) forward. In other embodiments, a hashed one-time password may be utilized and a mis-synchronized window may be allowed.

For example, if within a threshold value of 10, the counter (504) may be configured to move forward. However, if within another threshold value, such as 10 or 1000, a request to perform a re-sync may be processed. This request may be via one or more applications that the user taps, gestures, or otherwise displays on the user's device one or more times. The user may be notified that they have done so when the counter (504) increments in the appropriate sequence.

The contactless card (101) is configured to perform key diversification techniques using a counter (504), a master key (505) and a diversification key (506) when transmitting, for example, operational data (103) to a mobile device (110) to secure data. Typically, a server or other computer device owned and/or operated by the issuer of the contactless card (101) and the contactless card (101) may also be provisioned with the same master key (505), also referred to as a master symmetric key.

More specifically, each contactless card (101) is programmed with a separate master key (505) having a corresponding pair within the server. For example, a unique master key (505) may be programmed into the memory (102) of the contactless card (101) when the contactless card (101) is manufactured. Similarly, the unique master key (505) may be stored in the customer's record associated with the contactless card (101) within the account data (119) of the server or in another secure location. The master key may be kept secret from all parties other than the contactless card (101) and the server.

The master key (505) may be used in conjunction with a counter (504) to enhance security using key diversification. The counter (504) comprises a value that is synchronized between the contactless card (101) and the server. The counter value (504) may comprise a number that changes each time data is exchanged between the contactless card (101) and the server and/or the contactless card (101) and the mobile device (110).

To enable NFC data transfer between a contactless card (101) and a mobile device (110), an account application (113) can communicate with the contactless card (101) when the contactless card (101) is brought sufficiently close to a card reader (120) of the mobile device (110). The card reader (120) is configured to read from and/or communicate with the contactless card (101) via, for example, NFC, Bluetooth, RFID, etc. Thus, an exemplary card reader (120) includes an NFC communication module, a Bluetooth communication module, and/or an RFID communication module.

For example, a user may tap a contactless card (101) to a mobile device (110) to bring the contactless card (101) sufficiently close to a card reader (120) of the mobile device (110) to enable NFC data transfer between the contactless card (101) and the card reader (120). After communication is established between the mobile device (110) and the contactless card (101), the contactless card (101) generates a message authentication code (MAC) cryptogram. In some embodiments, this may occur when the contactless card (101) is read by an account application (113).

In particular, this can occur during reading, such as NFC reading of a Near Field Data Exchange (NDEF) tag that can be generated according to the NFC data exchange format. For example, a reader, such as an account application (113) and/or a card reader (120), can transmit a message, such as an applet selection message, together with the applet ID of the NDEF generated applet. Once the selection is confirmed, a series of file selection messages and a read file message can be transmitted.

For example, the sequence may include "Select Capabilities File", "Read Capabilities File", and "Select NDEF File". At this point, a counter value (504) maintained by the contactless card (101) may be updated or incremented, followed by "Read NDEF file". At this point, a message may be generated, which may include a header and a shared secret. A session key may then be generated. A MAC secret may be generated from the message, which may include the header and the shared secret. The MAC secret may be concatenated with one or more random data blocks, and the MAC secret and a random number (RND) may be encrypted with the session key.

The ciphertext and header can then be concatenated, encoded in ASCII hex, and returned in response to a "Read NDEF File" message in NDEF message format. In some embodiments, the MAC secret can be transmitted as an NDEF tag, and in other embodiments, the MAC secret can be included as a formatted string, for example, along with a uniform resource identifier. The contactless card (101) can then transmit the MAC secret to the mobile device (110), which can then forward the MAC secret to a server for verification as described below. However, in some embodiments, the mobile device (110) can verify the MAC secret.

More generally, when preparing to transmit data to, for example, a server and/or mobile device (110), the contactless card (101) may increment a counter value (504). The contactless card (101) may then provide the master key (505) and the counter value (504) as inputs to an encryption algorithm that generates a diversification key (506) as output. The encryption algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cryptographic message authentication code (CMAC) algorithm, and the like.

Non-limiting examples of encryption algorithms may include a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm such as HMAC-SHA-256; and a symmetric CMAC algorithm such as AES-CMAC. The contactless card (101) may then use the diversification key (506) to encrypt data, for example, a customer identifier (507) and any other data. The contactless card (101) may then transmit the encrypted data to an account application (113) of the mobile device (110), for example, via an NFC connection, a Bluetooth connection, or the like.

An account application (113) of a mobile device (110) can transmit encrypted data to a server over a network, for example, the Internet. In at least one embodiment, the contactless card (101) transmits a counter value (504) together with the encrypted data. In such embodiments, the contactless card (101) can transmit an encrypted counter value (504) or an unencrypted counter value (504).

Upon receiving the encrypted customer ID (507), the server can perform the same symmetric encryption using the counter value (504) as input to the encryption and the master key (505) as a key for the encryption. As mentioned, the counter value (504) can be specified in the data received from the mobile device (110), or can be specified in the counter value (504) maintained by the server to implement key diversification for the contactless card (101). The output of the encryption can be the same diversified key value (506) generated by the contactless card (101).

The server can then use the diversification key (506) to decrypt the encrypted customer ID (507) received over the network, revealing the data transmitted by the contactless card (101), for example at least the customer identifier (507). This allows the server to verify the data transmitted by the contactless card (101) via the mobile device (110), for example by comparing the decrypted customer ID (507) with the customer ID in the account data for the account.

During the generation process of a contactless card (101), two encryption keys may be uniquely assigned to each card. The encryption keys may include symmetric keys that may be used for both encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and implemented by the hardware of the contactless card (101). Using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information for each entity requesting the key.

To overcome the flaws in the 3DES algorithm that may be vulnerable in some embodiments, instead of using a master key, a unique card-derived key, and a counter as diversifying data, a session key, for example a unique key per session, may be derived. For example, each time a contactless card (101) is used in operation, a different key may be used to generate a message authentication code (MAC) and perform encryption. This creates a cryptographic triple layer. The session keys may be generated by one or more applets and derived using an application transaction counter in conjunction with one or more algorithms as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation.

Additionally, each card increment can be unique and assigned by the personalization or algorithmically assigned by some identifying information. For example, odd-numbered cards may be incremented by 2 and even-numbered cards may be incremented by 5. In some embodiments, the increment may also be different for sequential reads, so that a card may be incremented sequentially by 1, 3, 5, 2, 2, ... repeating. A particular sequence or algorithmic sequence may be defined in one or more processes derived from the personalization time or unique identifier. This may make it more difficult for a replay attacker to generalize across a small number of card instances.

The authentication message may be conveyed as a text NDEF record in hexadecimal ASCII format. In other embodiments, the NDEF record may be encoded in hexadecimal format.

FIG. 6 illustrates an embodiment of a logic flow (600). The logic flow (600) may represent some or all of the operations performed by one or more of the embodiments described herein. For example, the logic flow (600) may include some or all of the operations for determining which operations to perform based on a tap of a contactless card (101) to a computer device. The embodiments are not limited in this context.

As illustrated, the logic flow (600) begins at block (610) where an account application (113) running on a mobile device (110) authenticates credentials associated with an 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 in the account application (113). In some embodiments, the account application (113) may receive transaction data associated with the account, for example, from a server that processes transactions for the account.

At block 620, the account application (113) and/or the tapping engine (115) may detect a tap of the contactless card (101) to the mobile device (110). For example, the contactless card (101) and the mobile device (110) may be within NFC communication range at block 620. At block 630, the account application (113) receives operation data (103) of the contactless card (101) via a communication interface of the contactless card (101).

The account application (113) may then provide the motion data (103) to the tapping engine (115). In one embodiment, the contactless card (101) may encrypt the motion data (103) using one or more key diversification techniques, such as a counter (504), a master key (505), and a diversification key (506). The account application (113) may then verify the encrypted motion data (103) and/or transmit the encrypted motion data (103) to a server for verification.

At block 640, the tapping engine (115) determines the context of the mobile device (110). The context may include the context of the OS (112), the account application (113), and/or other applications (114). For example, the context may include determining which applications and/or components of the OS1 (112) are to be output for display on the mobile device (110). It may also include determining which functions and/or actions are associated with the applications output for display.

At block 650, the tapping engine (115) may optionally generate one or more predicted actions based on one or more ML models (118). As mentioned, the ML models (118) may be trained based on training data, where the training data includes past tapping data for the current user and/or multiple other users. This allows the ML models (118) to accurately predict one or more intended actions associated with a tap of the contactless card (101) to the mobile device (110) at block (620).

At block 660, the tapping engine (115) determines an action associated with a tap of the contactless card (101) to the mobile device (110) at block 620. Typically, the tapping engine (115) may determine the action based on one or more of the action data (103), account data (119) of the authenticated account, the determined context, rules (116), and/or a user profile (117).

For example, as noted, in some embodiments the action data (103) specifies an action, such as loading content from a specified URL using the account application (113) and/or another application (114). In another embodiment, the tapping engine (115) may determine that the context of the mobile device (110) is related to activating an inactive contactless card (101) and may load a page of the account application (113) that enables the user to activate the contactless card (101). In yet another embodiment, 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.

At block 670, the OS (112), the account application (113), and/or the tapping engine (115) initiate the execution of the action determined at block 660. For example, the phone application of the OS (112) may be opened and a phone number may be dialed for the user. In another embodiment, a page of the account application (113) may be opened.

As another embodiment, the web page may be loaded by a web browser. At block 680, the account application (113) may optionally receive input specifying a custom action for a tap of the contactless card (101). At block 690, the custom action may be stored as action data (103) in the memory of the contactless card. This allows the custom action to be performed in response to a subsequent tap of the contactless card (101) to the mobile device (110).

FIG. 7 illustrates an embodiment of a logic flow (700). The logic flow (700) may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow (700) may include some or all of the operations for determining the context of a computer device. The embodiments are not limited in this context.

As illustrated, the logic flow (700) begins at 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 visible on the display. At block 720, the tapping engine (115) determines the current output of the one or more applications determined at block 710.

For example, the tapping engine (115) can determine which page is output from a web browser based on the URL of the page. In another embodiment, the tapping engine (115) can analyze text output from an application. In another embodiment, the tapping engine (115) can determine which page of the account application (113) is currently output for display.

At block 730, the tapping engine (115) determines one or more functions associated with one or more applications determined at block 710. For example, the tapping engine (115) may determine, based on a URL of a web browser, that a web page is associated with transferring funds from one account to another.

As another embodiment, the tapping engine (115) can determine a function associated with a page of an account application (113) being output. As another embodiment, the tapping engine (115) can determine a concept from text output by the application and determine a function based on the concept.

At block 740, the tapping engine (115) optionally determines any relevant account data (119). For example, the account data (119) may reflect a purchase, a transaction, a card activation, or other account-related action. The tapping engine (115) may consider the account data (119) when determining context. For example, if the user recently completed a purchase with a contactless card (101), the context may include the purchase.

At block 750, the tapping engine (115) determines the context of the mobile device (110) based on one or more of the determinations made in blocks 710-740. This allows the tapping engine (115) to determine an action to perform in response to a tap of the contactless card (101) to the mobile device (110).

FIG. 8 illustrates an embodiment of a logic flow (800). The logic flow (800) may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow (800) may include some or all of the operations for performing an operation in response to a tap of a contactless card (101) to a computer device. The embodiments are not limited in this context.

As illustrated, the logic flow (800) begins at block (810) where the tapping engine (115) determines that the action data (103) received from the contactless card (101) specifies a URL. In response, the tapping engine (115) causes the URL to be accessed to initiate performance of the action specified by the URL. For example, if the URL is 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 to a web site, the tapping engine (115) may cause the OS (112) to launch a web browser and load the URL.

At block 820, the tapping engine (115) may determine that a custom action is specified, for example, in the user profile (117). The tapping engine (115) may then initiate execution of the custom action. For example, the custom action in the user profile (117) may specify to load the home page of the account application (113) as the default action. Thus, the tapping engine (115) may load the home page on the mobile device (110) in response to a tap of the contactless card (101). At block 830, the tapping engine (115) initiates execution of the action specified by the rule (116). For example, the default rule (116) may specify to load the account detail page of the account application (113) if no action is specified by the action data (103) and/or if no custom action is specified.

At block 840, the tapping engine (115) may optionally determine one or more candidate actions based on the context of the mobile device (110). For example, the tapping engine (115) may reference mappings between candidate actions and applications, functions, and/or contexts. The tapping engine (115) may select one or more candidate actions to perform in response to a tap of the contactless card (101) to the mobile device (110). At block 850, the tapping engine (115) generates one or more predicted actions based on a trained ML model (118) based on training data associated with the current user. This allows the current user's actions to be taken into account when generating the candidate actions.

At block 860, the tapping engine (115) generates one or more predicted actions based on the trained ML model (118) based on training data associated with a plurality of users, which may include the current user. This ensures that the actions of all users are taken into account when generating candidate actions. At block 870, the tapping engine (115) optionally initiates execution of one or more of the candidate actions determined at block 840 and/or the predicted actions generated at blocks 850 and/or 860.

In some embodiments, the contactless card (101) may be tapped to one or more devices, such as computer kiosks or terminals, to verify identity in order to receive a transaction item in response to a purchase, such as a coffee. By using the contactless card (101), a secure method of proving identity in a loyalty program may be established. For example, proving identity securely or receiving a benefit to obtain a reward, coupon, offer, etc. is established in a manner different from simply scanning a bar card.

For example, an encrypted transaction may occur between a contactless card (101) and a device that may be configured to process one or more tap gestures. As described above, one or more applications may be configured to verify the identity of the user and then cause the user to act or respond thereto, for example, via one or more tap gestures. In some embodiments, data may be written back to the contactless card, such as bonus points, loyalty points, rewards points, health care information, and the like.

In some embodiments, the contactless card (101) may be tapped to 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 the identity verification.

In some embodiments, the exemplary authentication communication protocol may mimic, with some modifications, the offline dynamic data authentication protocol of the EMV standard that is typically performed between a transaction card and a POS device. For example, the exemplary authentication protocol may not require some data values since the card issuer/payment processor itself is not used to complete a payment transaction, and authentication may be performed without 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, including the transaction amount, to the card issuer. Whether the issuer approves or declines the transaction may depend on whether the card issuer recognizes the transaction amount.

Meanwhile, in certain embodiments of the present invention, a transaction occurring on a mobile device lacks a transaction value associated with the POS system. Therefore, in some embodiments, a dummy transaction value, i.e., a value sufficient to be recognized by the card issuer and to cause activation, may be transmitted as part of the exemplary authentication communication protocol. POS-based transactions may also decline transactions based on the number of transaction attempts, e.g., a transaction counter. Multiple attempts exceeding a buffer value may result in a graceful decline, a graceful decline requiring additional verification before accepting the transaction. In some embodiments, the buffer value for the transaction counter may be modified to avoid attrition of legitimate transactions.

In some embodiments, the contactless card (101) can selectively transmit information depending on the receiving device. When tapped, the contactless card (101) can recognize the device toward which the tap is directed and based on this recognition, the contactless card can provide appropriate data for that device. This advantageously allows the contactless card to transmit only the information necessary to complete an immediate action or transaction, such as a payment or card authentication. This can improve both efficiency and data security by limiting data transmission and preventing the transmission of unnecessary data. The recognition and selective communication of information can be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and step-by-step fraud reduction.

When the tap of the contactless card (101) is directed toward a device running Apple's iOS® operating system, such as an iPhone, iPod or iPad, the contactless card can recognize the iOS® operating system and transmit appropriate data to communicate with such a device. For example, the contactless card (101) can provide encrypted identification information necessary to authenticate the card, for example using an NDEF tag via NFC.

Similarly, if a contactless card tap is directed to a device running the Android® operating system, such as an Android® smartphone or tablet, the contactless card can recognize the Android® operating system and communicate with such device by transmitting appropriate data, such as encrypted identification information required for authentication by the methods described herein.

In another embodiment, the contactless card tap may be directed to a POS device, including but not limited to a kiosk, checkout register, payment station, or other terminal. When the tap is performed, the contactless card (101) may recognize the POS device and transmit only the information necessary for the operation or transaction. For example, when the POS device used to complete a transaction is recognized, the contactless card (101) may transmit the payment information necessary to complete the transaction in accordance with the EMV standard.

In some embodiments, a POS device participating in a transaction may request or specify additional information to be provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, when a POS device receives a data communication from a contactless card, the POS device may recognize the contactless card and request additional information necessary to complete the operation or transaction.

In some instances, the POS device may be associated with an authorized merchant or other entity that is familiar with a particular contactless card or is familiar with performing a particular contactless card transaction. However, it should be understood that such affiliation is not required to perform the described method.

In some embodiments, such as a shopping mall, grocery store, convenience store, etc., a contactless card (101) may be tapped to a mobile device without opening an application to indicate a desire or intent to utilize one or more of the reward points, loyalty points, coupons, or offers applied to one or more purchases, thus providing intent to purchase.

In some embodiments, one or more applications may be configured to determine that the initiation was initiated via one or more tap gestures of the contactless card (101). Thus, the initiation occurs at 3:51 PM and the transaction to verify the user's identity occurs at 3:56 PM.

In some embodiments, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, the one or more actions may include collecting rewards, collecting points, determining the most important purchase, determining the least expensive purchase, and/or reconfiguring to other actions in real time.

In some embodiments, data may be collected for the tap action as biometric/gesture authentication. For example, a cryptographically secure and non-eavesdropping unique identifier may be transmitted to one or more backend services. The unique identifier may be formatted to look up secondary information about the individual. The secondary information may include personally identifiable information about the user. In some embodiments, the secondary information may be stored within a contactless card.

In some embodiments, the device may include an application that splits a bill or verifies payments between multiple individuals. For example, each individual may own a contactless card and be a customer of the same issuing financial institution, but this is not required. Each individual may receive a push notification on their device via the application to split the purchase. Instead of accepting only one card tap to indicate payment, other contactless cards may be used. In some embodiments, individuals with other financial institutions may own contactless cards (101) to provide information to initiate one or more payment requests from individuals who tap their cards.

In some embodiments, the present invention refers to a tap of a contactless card. However, it should be understood that the present invention is not limited to a tap and the present invention encompasses other gestures, such as a wave or other movement of the card.

FIG. 9 illustrates an embodiment of an exemplary computer architecture (900) that includes a computer system (902) that may be suitable for implementing various embodiments as described above. In various embodiments, the computer architecture (900) may include or be implemented as part of an electronic device. In some embodiments, the computer architecture (900) may represent a system that implements one or more components of the system (100), for example.

In some embodiments, the computer system (902) may represent, for example, a mobile device (110) of the system (100). The embodiments are not limited in this context. More generally, the computer architecture (900) is configured to implement all of the logic, applications, systems, methods, devices, and functionality described herein.

The terms "system," "component," and "module," as used herein, refer to a computer-related entity, such as hardware, a combination of hardware and software, software, or software in execution. An example of this is provided by the exemplary computer architecture (900). For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and/or magnetic storage media), an object, an executable, a thread of execution, a program, and/or a computer.

For example, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Additionally, the components can be communicatively coupled to each other by various types of communication media to cooperate in their operations. Cooperation can involve one-way or two-way exchange of information.

For example, a component may convey information in the form of signals transmitted over a communications medium. The information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, additional embodiments may alternatively use data messages. Such data messages may be transmitted over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

The computer system (902) includes various common computer elements such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and the like. However, embodiments are not limited to implementation by the computer system (902).

As illustrated in FIG. 9, the computer system (902) includes a processor (904), system memory (906), and a system bus (908). The processor (904) may be any of commercially available computer processors, including without limitation, AMD® Athlon®, Duron®, and Opteron® processors; ARM® application, embedded, and security 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).

The system bus (908) provides an interface to system components, including but not limited to system memory (906), to the processor (904). The system bus (908) may be any of several types of bus architectures that may be additionally interconnected to a memory bus, a peripheral bus, and a local bus using any of a variety of commercially available bus architectures, with or without a memory controller. An interface adapter may be connected to the system bus (908) via a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

System memory (806) may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double-data-rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, drive arrays such as multiple array independent disk (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 embodiment illustrated in FIG. 9, the system memory (906) may include non-volatile memory (910) and/or volatile memory (912). A basic input/output system (BIOS) may be stored within the non-volatile memory (910).

The computer 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 Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computer system (902) is generally configured to implement all of the logic, systems, methods, devices and functions described herein with reference to FIGS. 1 through 8.

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

A user may enter commands and information into the computer 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 a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, gloves, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, pressure-sensitive, etc.), a trackball, a track pad, a sensor, a stylus, etc. These and other input devices are often connected to the processor (904) via an input device interface (942) that is coupled to the system bus (908), but may also be connected by a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

A monitor (944) or other type of display device is also connected to the system bus (908) via an interface, such as a video adapter (946). The monitor (944) may be internal or external to the computer system (902). In addition to the monitor (944), the computer typically includes other peripheral output devices, such as speakers, a printer, and the like.

The computer system (902) may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer (948), via wired and/or wireless communications. The remote computer (948) may include a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and may generally include many or all of the elements described relative to the computer system (902), although a memory/storage device (950) is illustrated for brevity.

The logical connections described 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 companies and facilitate enterprise-wide computer networks, such as intranets. Any of these networks may be connected to a global communications network, such as the Internet. In an embodiment, the network (130) of FIG. 1 is one or more of a LAN (952) and a WAN (954).

When used in a LAN network environment, the computer system (902) is connected to the LAN (952) via a wired and/or wireless communications network interface or adapter (956). The adapter (956) may facilitate wired and/or wireless communications to the LAN (952). It may also include a wireless access point disposed thereon to communicate with the wireless capabilities of the adapter (956).

When used in a WAN network environment, the computer system (902) may include a modem (958) or be connected to a communications server on the WAN (954) or have other means for establishing communications over the WAN (954), such as over the Internet. The modem (958), which may be internal or external and may be a wired and/or wireless device, is connected to the system bus (908) via an input device interface (942).

In a networked environment, program modules depicted in connection with a computer system (902) or portions thereof may be stored in a remote memory/storage device (950). It should be understood that the depicted network connections are exemplary and that other means of establishing a communications connection between the computers may be used.

The computer system (902) is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operable in IEEE 802.16 radio modulation technology, for example. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies. Accordingly, the communication may be a predefined structure as in a conventional network, or may be an ad hoc communication between at least two devices. A Wi-Fi network provides a secure, stable, and fast wireless connection using a wireless technology called IEEE 802.11x (a, b, g, n, etc.). A Wi-Fi network can be used to connect computers to each other, to the Internet, and to connect networks (using IEEE 802.3 related media and features) to wired networks.

Various embodiments can be implemented using hardware elements, software elements, or a combination thereof. Examples of hardware elements include processors, microprocessors, circuits, circuit elements (e.g., transistors, registers, 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, and the like.

Examples of software may include software components, programs, application programs, 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, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may depend on a number of factors such as desired computational speed, power levels, thermal tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within the processor, which when read by a machine cause the machine to produce logic for performing the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and supplied to various customers or manufacturing facilities for loading into a manufacturing machine that makes the logic or processor.

Some embodiments can be implemented using, for example, a machine-readable medium or article that can store instructions or sets of instructions that, when executed by a machine, can cause the machine to perform methods and/or operations according to the embodiments. Such a machine can include, for example, any suitable processing platform, computer platform, computer device, processing device, computer system, processing system, computer, processor, and the like, and can be implemented using any suitable combination of hardware and/or software.

Machine-readable media or articles 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, for example, memory, removable or non-removable media, erasable or non-erasable media, recordable or rewritable media, digital or analog media, hard disks, floppy disks, compact disk read only memories (CD-ROMs), recordable compact disks (CD-Rs), rewritable compact disks (CD-RWs), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, and the like.

The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and may be implemented using any suitable high-level, low-level object-oriented, visual, compiled, and/or interpreted programming language.

The foregoing description of exemplary embodiments has been presented for the purposes of illustration and description. The invention is not intended to be limited or exclusive to the precise form disclosed. Many modifications and variations are possible in light of the present invention. It is intended that the scope of the invention be limited not by this detailed description, but by the claims appended hereto.

Future applications claiming priority to this application may claim subject matter disclosed otherwise and may generally include one or more of any set of limitations as variously disclosed or otherwise described herein.

Claims (25)

processor; and
In a device including a memory storing instructions executed by a processor;
The above command causes the processor to
Receiving, by an application running on the processor, from a contactless card, operation data for one of a number of operations used to determine an operation associated with a tap of the contactless card to the device;
Generating a first predicted motion from among a plurality of predicted motions based on the motion data by a machine learning (ML) model running on the processor; and
The application initiates the execution of a first action predicted as an action;
A device characterized by inducing to do so. In the first paragraph, the memory stores instructions and, when executed by the processor,
The above command causes the processor to
Determine the context of the application based on at least one feature associated with the current output of the application,
The current output of the application includes the page displayed on the device's display, and the predicted first action is additionally generated based on the determined context.
A device characterized by induction. A device according to claim 2, wherein the context is further determined based on at least one contactless card associated with the current output of the application.
In the first aspect, the memory stores an instruction, and when executed by the processor, the processor performs the first operation predicted before the instruction is executed.
A rule is received by the application to initiate execution of the predicted first action; and
The application determines whether the account associated with the contactless card meets the rules;
A device characterized by inducing to do so. In the first paragraph, the memory stores instructions and, when executed by the processor,
The above command causes the processor to
Generate a number of predicted motions by an ML model based on motion data;
Compute a separate score for each action predicted by the ML model; and
Select the predicted first action based on each action score predicted by the ML model;
A device characterized by inducing to do so. A device according to claim 1, wherein the ML model is generated based on training data describing a plurality of actions performed in response to a plurality of taps of a plurality of contactless cards for a plurality of devices, wherein the predicted first actions comprise at least one selected from the group consisting of: (i) making a phone call, (ii) loading an application page, (iii) activating an operating system (OS) component running on the processor, (iv) accessing a function of another application running on the operating system, and (v) activating a contactless card. In the first aspect, the memory stores instructions, and when executed by the processor, the processor
Receives input specifying a custom action to associate a tap on a contactless card device with the context of the application; and
Transmitting an indication of a custom action to the contactless card for storage in the memory of the contactless card;
A device characterized by inducing to do so. In the first paragraph, the memory stores instructions and, when executed by the processor,
The above command causes the processor to
The motion data is determined by the application to include a unique resource locator (URL); and
Opens a page of the application associated with a URL by the application;
A device characterized by inducing to do so. A step of receiving, by an application running on a processor, from a contactless card, operation data for one of a plurality of operations for use in determining an operation associated with a tap of the contactless card to the device;
A step of generating a first predicted motion among a plurality of predicted motions based on the motion data by a machine learning (ML) model running on a processor; and
A computer-implemented method comprising: a step of initiating, by an application program, performance of a first action predicted as an action; In Article 9,
A step for determining the context of an application based on at least one feature associated with the current output of the application,
The current output of the application includes the page displayed on the display of the device, and the predicted first action is additionally generated based on the determined context;
A computer-implemented method further comprising: A computer-implemented method according to claim 10, wherein the context is further determined based on at least one contactless card associated with a current output of the application. In the 9th paragraph, before the step of starting the performance of the predicted first operation,
A step of receiving by the application a rule for starting the execution of the predicted first action; and
A step for the application to determine whether an account associated with a contactless card satisfies a rule;
A computer-implemented method further comprising: In Article 9,
A step of generating a plurality of predicted motions by an ML model based on motion data;
A step of calculating each score for each action predicted by the ML model; and
A step of selecting a predicted first action based on each action score predicted by the ML model;
A computer-implemented method further comprising: A computer-implemented method according to claim 9, wherein the predicted first action further comprises one or more of the following steps: (i) making a phone call, (ii) loading an application page, (iii) activating an operating system (OS) component running on the processor, (iv) accessing a function of another application running on the OS, and (v) activating a contactless card. In Article 9,
A step for receiving input specifying a custom action for associating a tap on a device of a contactless card with the context of an application; and
A step of storing a custom mark in the memory of a contactless card;
A computer-implemented method further comprising: A computer-implemented method according to claim 9, wherein the machine learning model is generated based on training data describing a plurality of actions performed in response to a plurality of taps of a plurality of contactless cards for a plurality of devices, wherein the device is one of the plurality of devices. In Article 9,
A step for determining by the application whether the motion data includes a unique resource locator (URL); and
A step of opening a page of an application associated with a URL by the application;
A computer-implemented method further comprising: A computer-readable storage medium containing instructions executed by a processor,
The above command causes the processor to
Receiving, by an application running on the processor, from a contactless card, operation data for one of a number of operations used to determine an operation associated with a tap of the contactless card to the device;
Generating a first predicted motion from among a plurality of predicted motions based on the motion data by a machine learning (ML) model running on the processor; and
The application initiates the execution of a first action predicted as an action;
A computer-readable storage medium that induces the user to do so. In paragraph 18, the instruction causes the processor to
Determine the context of the application based on at least one feature associated with the current output of the application,
The current output of the application includes the pages displayed on the device's display,
The predicted first action is further generated based on the determined context.
A computer-readable storage medium that induces the user to do so. A computer-readable storage medium according to claim 19, wherein the context is further determined based on at least one contactless card associated with a current output of the application.
In claim 18, the instruction, when executed by the processor, causes the processor to perform the first predicted operation before:
A rule for initiating a predicted first action is received by the application; and
The application determines whether the account associated with the contactless card meets the rules;
A computer-readable storage medium characterized by further inducing to do so. In paragraph 18, the instruction causes the processor to
Generate a number of predicted actions by the ML model based on the action data;
Compute a separate score for each action predicted by the ML model; and
Select the predicted first action based on the score of each action predicted by the ML model;
A computer-readable storage medium characterized by further inducing to do so. A computer-readable storage medium according to claim 18, wherein the predicted first action comprises one or more selected from (i) making a phone call, (ii) loading an application page, (iii) activating an operating system (OS) component running on the processor, (iv) accessing a function of another application running on the OS, and (v) activating a contactless card; wherein the ML model is generated based on training data describing a plurality of actions performed in response to a plurality of taps of a plurality of contactless cards for a plurality of devices, wherein the device is one of the plurality of devices. In paragraph 18, the instruction causes the processor to
Receives input specifying a custom action to associate a tap on a contactless card device with the context of the application; and
Store custom marks in the memory of a contactless card;
A computer-readable storage medium characterized by further inducing to do so. In paragraph 18, the instruction causes the processor to
The application determines whether the motion data contains a unique resource locator (URL); and
Opens a page of the application associated with a URL by the application;
A computer-readable storage medium characterized by further inducing to do so.