HK1148100B

HK1148100B - Wirelessly executing financial transactions

Info

Publication number: HK1148100B
Application number: HK11102170.5A
Authority: HK
Inventors: D‧简恩
Original assignee: 设备保真度股份有限公司
Priority date: 2007-09-12
Filing date: 2008-09-12
Publication date: 2013-06-14

Description

Wirelessly executing financial transactions

Priority requirement

This application claims priority from U.S. patent application No. 60/971,813 filed on 12/9/2007 and U.S. patent application No. 12/209,087 filed on 11/9/2008, the entire contents of both applications being incorporated herein by reference.

Technical Field

The present invention relates to network communications, and more particularly to wirelessly performing financial transactions.

Background

Portable electronic devices and tokens have become an integral part of everyday user experience. Users have a wide variety of portable and handheld devices including communication, business, and entertainment devices such as cellular phones, music players, digital cameras, smart cards, memory tokens, and various possible combinations of the above devices and tokens. All these devices share the following commonalities: consumers are most of the time accustomed to carrying them around to most places. This is true across various demographics and age groups, regardless of the age of the consumer, their age group, their skill level, or context.

These common handheld devices provide options for expandable memory. Microampere digital (microSD) is a popular interface in high-end cellular phones, while SD and multi-media card (MMC) interfaces are also available in limited models. MicroSD is at least a common feature (in terms of size) supported by most of these devices and tokens. In addition, the adapter can be used to convert MicroSD to MiniSD, SD, MMC, and USB. While most popular MP3 players (ipods) provide a proprietary interface, competing designs do provide a standard interface. Digital cameras mostly offer SD and MMC, while digital at the tip (xD) is another option. Miniature and pocket-sized versions of these interfaces are also available in several models. Mini-USB is increasingly available for synchronization with laptop computers in cell phones, digital cameras, and MP3 players.

SUMMARY

The present invention is directed to a system and method for wirelessly performing financial transactions. The payment card includes an interface, a communication module, a secure memory, a user interface module, and a processing module. The interface connects to a slot of a mobile host device. The communication module wirelessly receives RF signals from and wirelessly transmits RF signals to the retail terminal. The secure memory stores user credentials and a payment application for performing financial transactions with the retail terminal. The user credentials and payment application are associated with a financial institution. The user interface module presents and receives information through a GUI of the mobile host device. The processing module executes a payment application using the user credentials in response to at least the transaction request received by the communication module and sends a transaction response to the retail terminal based at least in part on the executed application.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.

Description of the drawings

FIG. 1 is an example transaction system in accordance with some implementations of the invention;

FIG. 2 is an example transaction system that sends transaction information over a cellular core network;

FIG. 3 is the example transaction card of FIG. 1, according to some implementations of the invention;

FIG. 4 is an example smart card with an antenna selectively switched;

FIG. 5 is an example secure memory of a smart card for storing a plurality of user credentials;

FIG. 6 is a schematic diagram illustrating a personalization process of a smart card;

FIGS. 7A and 7b are flow diagrams illustrating an example method for initializing a smart card;

8A, 8B, and 8C are examples of call flows illustrating a call session with a smart card;

FIG. 9 is a flow diagram illustrating an example method for activating a transaction card; and

fig. 10A and 10B illustrate an example card for receiving a smart card.

Like reference symbols in the various drawings indicate like elements.

Detailed Description

FIG. 1 is a block diagram illustrating an example transaction system 100 for wirelessly executing transactions using a smart card that is independent of a host device. For example, the system 100 may include a microampere digital (microSD) card that performs transactions with a financial institution independent of a host device. In addition to microSD, system 100 may include other mass storage interfaces to connect the smart card to a host device, such as, for example, multi-media card (MMC), SD, Universal Serial Bus (USB), apple iDock, firewire, and/or others. A smart card is a device that is configured to be independent of a host device, inserted into or otherwise attached to the host device, and to access or otherwise perform a service (e.g., a transaction). In some implementations, the smart card may be fabricated as a microSD card including, for example, grooves, protrusions, and/or other features. The system 100 may include a smart card that includes dual interfaces. The dual interface may connect the smart card to a host device over a physical interface (e.g., SD, MMC, USB) and to an external device over a wireless connection (e.g., NFC, ISO 14443). In some implementations, the smart card may include an embedded security chip, a Central Processing Unit (CPU) with an operating system, local memory accessible by a user through a host device, and value added applications. The host device may include a cellular phone, a smart phone, a Personal Digital Assistant (PDA), an mpeg-1 audio layer 3(MP3) device, a digital camera, a camcorder, a client, a computer, and/or other devices that include mass storage and/or peripheral interfaces. In some implementations, the smart card may function as a host, while the host device is a slave (slave), such that the smart card controls operational aspects of the host device, such as a user interface. The smart card in system 100 may perform one or more of the following processes: selectively activating an antenna to conduct a wireless transaction in response to at least one event; verifying the host device with the financial institution using the host signature through, for example, a point of sale (POS); performing a transaction with a financial institution independent of a host device through, for example, a POS terminal; and/or other processes. By providing a smart card, the system 100 can wirelessly execute transactions with various financial institutions without requiring additional hardware, software, and/or firmware on the host device and/or without requiring changes to existing hardware, software, and/or firmware of the reader terminal to enable the user to wirelessly execute the transactions.

At a high level, the system 100 includes an offline store 102 and clients 104a and 104b coupled to a financial institution 106 via a network 108. Although not shown, the system 100 may include several intermediary parties between the financial institution 106 and the network, such as a transaction acquirer and/or a payment network host. The offline store 102 includes a mobile device 110a having a transaction card 112a and a point of sale (POS) device 114 that performs transactions with consumers. The POS device 114 includes a Graphical User Interface (GUI)109 for presenting information to and/or receiving information from a user. In some implementations, the POS114 may transmit a request to execute a transaction to the transaction card 112. The transaction card 112 may transmit authentication information to the POS 114. The client 104 includes a GUI115 for presenting information associated with the system 100. The client 104a includes a card reader 116 that interfaces the transaction card 112c with the client 104 a. The financial institution 106 may authorize the transaction based at least in part on the information transmitted by the transaction card 112. The mobile device 110 includes a GUI 111 for presenting information associated with financial transactions.

The offline store 102 is generally at least a portion of an enterprise having a physical presence (e.g., a building) for operations. For example, the offline store 102 may sell goods and/or services directly to consumers at a physical location (e.g., a brick and mortar store). In this example, the offline store 102 purchases or otherwise receives items from a wholesaler (not shown) (e.g., production) and may then sell the items to a consumer, such as a user of the mobile device 110. Generally, the offline store 102 may provide a face-to-face experience with the consumer when providing goods and/or services. For example, the offline store 102 may be a brick-and-mortar store such that a user selects goods or services using the Internet and purchases and receives the goods or services at the offline store 102. The offline store 102 may provide one or more of the following services associated with the goods: inventory, stock, distribution, and/or shipping. As a result, the offline store 102 may not directly distribute the goods received from the wholesaler. The offline store 102 may include a single retail store, one or more retail stores at a single geographic location, and/or multiple retail stores geographically distributed. In some cases, two or more entities may represent portions of the same entity or affiliated entities. For example, the offline store 102 and wholesaler may be departments within an enterprise. In summary, the offline store 102 may wirelessly perform financial transactions with the mobile device 110.

Each mobile device 110 includes an electronic device operable to interface with the transaction card 112 a. For example, mobile device 110 may receive and transmit wireless and/or contactless communications with system 100. As used in this disclosure, the mobile device 110 is intended to encompass a cellular telephone, a data telephone, a pager, a portable computer, a SIP phone, a smartphone, a Personal Data Assistant (PDA), a digital camera, an MP3 player, a camcorder, one or more processors within these or other devices, or any other suitable processing device capable of communicating information with the transaction card 112. In some implementations, the mobile device 110 may be based on cellular radio technology. For example, mobile device 110 may be a PDA operable to wirelessly connect with an external or unsecured network. In another example, the mobile device 110 may include a smartphone containing an input device such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with transactions with the offline store 102 (including digital data, visual information, or the GUI 111).

GUI 111 comprises a graphical user interface operable to allow a user of mobile device 110 to interface with at least a portion of system 100 for any suitable purpose, such as authorizing transactions and/or displaying transaction histories. Generally, the GUI 111 provides efficient and user-friendly presentation of data provided by the system 100 or communicated in the system 100 to a particular user, and/or is also an efficient and user-friendly tool for a user to self-manage settings and access services provided by the financial institution 106. The GUI 111 may include a plurality of customizable frames or views with interactive fields, drop down lists, and/or buttons operated by the user. The term "graphical user interface" may be used in the singular or in the plural to describe one or more graphical user interfaces and each display of a particular graphical user interface. GUI 111 may include any graphical user interface, such as a generic web browser or touch screen, that processes information in system 100 and presents results to a user.

The transaction card 112 may include any software, hardware, and/or firmware configured to wirelessly execute transactions with the POS device 114. For example, the transaction card 112 may perform contactless transactions with the POS device 114 independent of the mobile device 110 a. In other words, the transaction card 112 may wirelessly execute transactions without the mobile device 110 performing aspects of the transaction. The transaction card 112 may perform transactions with the POS device 114 using short range signals such as NFC (e.g., ISO 18092/ECMA 340), ISO 14443 type A/B, ISO 15693, Felica, MiFARE, Bluetooth, Ultra Wideband (UWB), Radio Frequency Identification (RFID), contactless signals, proximity signals, and/or other signals compatible with retail payment terminals (e.g., POS 114). In some implementations, the transaction card 112 may include one or more chipsets that execute an operating system and security processes to independently execute transactions. In doing so, mobile device 110 does not require additional hardware, software, and/or firmware to wirelessly perform transactions, such as NFC transactions, with POS 114. In some implementations, the transaction card 112 may perform one or more of the following processes: wirelessly receiving a request to perform a transaction and/or providing a response from the POS device 114; convert between a wireless protocol and a protocol compatible with the transaction card 112; converting between a transaction card protocol and a protocol compatible with the mobile device 110; presenting and receiving information to and from the user (e.g., PIN request, PIN) through the GUI 111; decrypt and encrypt information wirelessly transmitted between the transaction card 112 and the POS 114; executing applications locally stored in the transaction card 112; selectively turn on and off an antenna of the transaction card 112 based at least in part on one or more events; perform an authentication process based at least in part on information received, for example, through GUI 111; sending a host signature to the POS114 in response to at least the transaction challenge; storing, at least in part, details of a transaction performed between card 112 and POS device 514; generate and/or present alerts (e.g., audio-visual alerts) to the user through the GUI 111; generating and/or sending a wireless message alert to the financial institution 106 using the mobile device 110 if cellular capable; and/or others. In some implementations, the transaction card 112 may include a communication module with a protocol conversion module, an antenna tuning circuit, a power circuit, and a miniature antenna tuned to exchange wireless data with the retail terminal 114.

In some implementations, the transaction card 112 may initiate a transaction in response to at least a user selecting a graphical element in the GUI 111. The transaction card 112 may initiate a transaction with the POS114 in response to at least a wireless request transmitted by the POS 114. In some implementations, the transaction card 112 may selectively switch the antenna between the on and off states in response to one or more events. The one or more events may include a user request, completion of a transaction, insertion of the card 112 into a different mobile device, a change in location, a timer event, detection of an incorrect PIN entered by the user, a change in the wireless network to which the device is connected, a message received from the financial institution 106 using a wireless communication method such as SMS, and/or other events. For example, the transaction card 112 may receive one or more commands to turn off the antenna from a cellular network (not shown) through the mobile device 110. In some implementations, the transaction card 112 may request a user identification, such as a PIN, a user ID and password combination, a biometric signature, and/or the like.

With respect to translating between protocols, the transaction card 112 may be capable of processing information using a standard security protocol, such as ISO 7816, and/or other protocols. In this case, the transaction card 112 may convert between the NFC protocol (e.g., ISO 18092) and the transaction card protocol. In some implementations, the ISO 7816 commands may be encapsulated within interface commands for transmitting data between the host device 114 and the card 112. Additionally, the transaction card 112 may interface with the mobile device 110 through physical interfaces such as MicroSD, Mini-SD (Mini SD), SD, MMC, miniMMC, microMMC, USB, miniUSB, microUSB, firewire, apple iDock, and/or others. With regard to security processes, the transaction card 112 may implement one or more encryption algorithms to secure transaction information such as card number (e.g., credit card number, debit card number, bank account number), PIN, and/or other security-related information. The security-related information may include an expiration date, a card verification code, a user name, a home phone number, a user zip code, and/or other user information associated with verifying the identity of the cardholder. In some implementations, the transaction card 112 may execute private keys (symmetric algorithms) such as DES, TDES, and/or others, or public keys (asymmetric algorithms) such as RSA, elliptic curves, and/or others. Additionally, the transaction card 112 may include memory (e.g., flash memory, EEPROM) for storing user data, applications, offline web pages, and/or other information. With respect to applications, the transaction card 112 may execute locally stored applications and present and receive information to and from a user via the GUI 111. For example, the transaction card 112 may execute an application for synchronizing an account balance with the financial institution 106 using the GUI 111 and the mobile device 110. Alternatively or in addition to the application, the transaction card 112 may present offline web pages to the user using the GUI 111. In response to initiating a transaction, the transaction card 112 may automatically present an offline web page through the GUI 111. In some implementations, the offline web page may be associated with a financial institution 106. In some implementations, the transaction card 112 may be backward compatible and function as a mass storage device. For example, if the wireless interface of the transaction card 112 is unavailable or disabled, the transaction card 112 may function as a mass storage device that enables a user to access data stored in a memory component (e.g., flash memory). In some implementations, the transaction card 112 may execute a set of initialization commands in response to at least being inserted into the mobile device 110. These initialization commands may include determining device-related information for mobile device 100 (e.g., phone number, signature, connection network information, location information, and other available attributes), determining user-related information (e.g., PIN code, activation code), incrementing a counter, setting a flag, and activating/deactivating functions according to pre-existing rules and/or algorithms. In some implementations, the transaction card 112 substantially maintains attributes of the mobile device 110, such as size, accessibility to peripheral devices provided by the device, charging, battery life, signal strength, access to displays and all other input devices, connectivity to a wireless network (if any), interface capabilities to a PC (if any), and/or any other features provided by the device. The added functionality never compromises device performance, thereby retaining the credentials of its regulatory body such as the FCC and the device issuer such as the body (e.g., the warranty).

In some implementations, the transaction card 112 may automatically perform one or more fraud control processes. For example, the transaction card 112 may identify an operational change and automatically transmit a notification to a financial institution based at least in part on the identified change. The transaction card 112 may perform two fraud control processes: (1) determining that one or more rules are violated; and (2) automatically performing one or more actions in response to at least the violation. With respect to the rules, the transaction card 112 may locally store rules associated with updates to operational aspects of the transaction card 112. For example, the transaction card 112 may store rules indicating that a change of the mobile host device 110 is an operational violation. In some implementations, the transaction card 112 may store rules based at least in part on updates to one or more of: the phone number of host device 110; the MAC address of host device 110; a network wirelessly connected to host device 110; a location of the host device; and/or other aspects. In response to one or more events matching or otherwise violating a rule, the transaction card 112 may execute one or more processes to substantially block or otherwise notify the financial institution 106 of possible fraudulent activity. For example, the transaction card 112 may execute a command to block an associated user account and/or the transaction card 112. Alternatively or additionally, the transaction card 112 may transmit a command to the financial institution 106 to call the mobile host device 110. In some implementations, the transaction card 112 may execute commands based at least in part on the event type. In some examples, the transaction card 112 may initiate a call with the financial institution 506 in response to at least a change in the host device 110 number. In some examples, the transaction card 112 may re-execute the activation process in response to at least a specified event type. The activation process may include activating a transaction card and/or financial account, as discussed in more detail with reference to fig. 9. In some implementations, the transaction card 112 may execute a command to disconnect the GUI 111 from the transaction card 112. The transaction card 112 may present a disconnection notification through the GUI 111 prior to executing the command. In some implementations, the transaction card 112 may transmit a command to the financial institution 106 to deactivate an account associated with the card 112.

In some implementations, the POS114 may transmit a transaction request 117 to the transaction card 112 for information used to generate the authorization request 118. In response to at least the transaction request, the transaction card 112 may transmit one or more transaction responses 119 identifying information associated with the payment account. In some implementations, the POS device 114 may send a request 118 to authorize the transaction to the financial institution 106. The authorization information may include an account number, a transaction amount, user credentials, and/or other information. In response to at least the transaction request 118, the financial institution 106 may send an authorization response 120 to the POS device 114. In some implementations, the POS device 114 may transmit the response 120 to the transaction card 112. The transaction response 120 may include a receipt that may be presented to the user, for example, through the GUI 111 a. In some implementations, the financial institution 106 may send the authorization response 120 to the mobile device over a cellular core network (see fig. 2). In this implementation, the financial institution 106 may store the association between the mobile device 110 and the transaction card 112 during a user enrollment process, automatically upon activation of the card 112 by the user, upon, for example, initial insertion of the card 112 into the mobile device 110, and/or during other events. In the illustrated implementation, the POS114 includes a GUI 109.

The GUI 109 comprises a graphical user interface operable to allow a user of the POS114 to interface with at least a portion of the system 100 for any suitable purpose, such as the user entering transaction information (e.g., PIN, accepting transaction) and/or presenting transaction information (e.g., transaction amount). Generally, the GUI 109 provides an efficient and user-friendly presentation of data provided by the system 100 or communicated in the system 100 to a particular user, and/or is also an efficient and user-friendly tool for a user to wirelessly initiate a transaction with the transaction card 112. The GUI 109 may present the user with a series of screens or displays for accepting transactions and entering security information such as a PIN, for example.

In some implementations, the transaction card 112 may be implemented differently. The transaction card 112 may be implemented as a KeyFOB and remain active as a FOB outside of the mobile device 110. In this case, the transaction card 112 may be passive and powered from the induced magnetic field generated by the POS 114. The transaction card 112 may be implemented in the form of an industrial integrated circuit chip for mounting on a PCB or IC chip. In some implementations, the transaction card 112 may be implemented in the form of a self-contained desktop stand-alone unit powered by an external AC adapter or stand-alone box. In some implementations, the transaction card 112 can be implemented as an external accessory (e.g., a container) to the mobile device 110 and connected to the mobile device using a peripheral interface such as USB, serial port, iDock apple proprietary interface, and/or other interface.

In some implementations, the transaction card 112 may operate according to one or more of the following modes: simulating a movable card; a mobile reader; self-training; killing (killed); a memory; is not active; and/or other modes. The transaction card 112 may operate an activity card emulation mode to convert the mobile device 110 into a contactless payment device loaded with a financial instrument (FV), which may be, for example, a credit card, debit card, gift card, and/or other retail payment product. In this mode, the transaction card 112 may perform payment transactions at any payment terminal (e.g., POS114) that has the ability to accept contactless payment transactions. For example, these terminals may be contactless-enabled terminals under MasterCard paypass, Visa paywave programs, American stock ExpressPay, Discover Zip, and/or other payment programs currently used by merchants. After the antenna of the transaction card 112 is activated in this mode, the merchant terminal may detect the presence of the host device with the transaction card 112 and prompt the user to authorize the transaction, such as by entering a PIN, signing on a terminal interface, confirming the transaction amount, and/or other action. In this mode, these transactions may be processed as normal card-present transactions. In other words, the POS114 may perceive the transaction card 112 as a contactless plastic payment card and may communicate with the transaction card 112 as a contactless plastic payment card to perform a payment transaction. In these implementations, the POS114 may wirelessly communicate with the transaction card 112 using the same signals used to communicate with the contactless plastic payment card when the card 112 is operating in the active card emulation mode. In this active card emulation mode, the transaction card 112 emulates a contactless plastic payment card and may be backward compatible with the POS 114. In this implementation, neither the terminal nor the financial institution needs additional software to perform the transaction. In addition, the transaction card 112 in this mode may be used for other applications, such as physical access control (to open doors in a corporate or public transportation environment), logical access control (to request network access via a PC), application access control (to purchase access to amenities such as transportation, movies, or any other situation where payment needs to be made to gain access to a facility), and/or other applications.

In the active reader mode, the transaction card 112 may convert the mobile device 110 into a contactless reader device capable of receiving data when in range of a transmitting terminal (e.g., the POS 114). In some implementations, this mode requires dedicated NFC hardware while requiring reader mode capabilities as part of the transaction card 112. In the event that the mobile device 110 is proximate (e.g., 10cm or less) to a transmitting terminal, a reader mode of the transaction card 112 may be activated and the user prompted through the GUI 111 for authorization to receive data. This mode may only be applicable to mobile devices 110 having UI elements such as OK buttons and screens, LEDs to indicate that data reception is being requested, and/or other interfaces. Once the user authorizes transmission, the transaction card 112 in this mode may receive and locally store, process, and may execute the transaction and/or forward the received data to another entity. For example, the transaction card 112 in this mode may receive content by promoting a poster, confirming a purchase of a ticket, and/or the like. For example, the transaction card 112 in this mode may function as a mobile POS terminal that receives transaction information from a plastic contactless card/FOB and instructs the POS114 to prepare a transaction authorization request to the financial institution 106 over a cellular core network. Once the financial institution 106 authorizes the transaction, the mobile device 110 may display a confirmation of the transaction to the user via the GUI 111.

With respect to the self-training mode, the transaction card 112 may execute a version of the reader mode. In some implementations, the self-training mode may be activated by a dedicated action (e.g., pressing of the tip of a microswitch, entering an administrator password via GUI II 1). In response to at least activating this mode, the transaction card 112 may be configured to receive personalization data over, for example, a short-range wireless interface from another peer transaction card, such as a plastic contactless card compatible with this function and issued by the financial institution 106 or a management card specifically prepared for this purpose. The personalization data received in this mode may include encrypted FV information stored in a secure memory of the transaction card 112. In some implementations, the transaction card 112 in this mode may receive FV information through a contactless interface of a transmitter and/or otherwise. The transaction card 112 may then synthesize FV information corresponding to the user account and personalize an internal security module including, for example, a payment application and associated user credentials for performing transactions with the financial institution 106. The self-training mode may be used to re-personalize the transaction card 112 in the field. In some implementations, if the self-training mode is activated, all previous data may be deleted. The self-training mode may be a peer-to-peer personalization mode in which the card 112 may receive personalization information from another transaction card 112. The schema may represent additional personalization schemas as compared to factory, storefront, and/or over-the-air (OTA) personalization scenarios that may act as server-to-client personalization scenarios. In some implementations, the self-training mode may be a peer-to-peer personalization mode in which the transaction card 112 receives personalization information from another transaction card. Because two transaction cards 112 are used in this mode, this mode is different from server-to-client personalization scenarios like factory, storefront, and OTA personalization.

With respect to the inactive mode, the transaction card 112 may temporarily deactivate the contactless interface. In some implementations, the inactive mode can be activated using the mobile device 110 through a physical interface (e.g., microSD interface). At least in response to activation of the inactive mode, the transaction card 112 may temporarily act only as a mass storage card. In some implementations, the card 112 may also enter this state when the reset needle tip is pressed. In this mode, the transaction card 112 may retain locally stored information, including financial user data. In this mode, the transaction card 112 may perform an activation process and may return to the active mode if successful. The financial institution 106 may use the mode to temporarily prevent use in response to at least identifying at least possible fraudulent activity.

With regard to the kill mode, the transaction card 112 may permanently deactivate the contactless interface. In some implementations, the kill mode is activated using the mobile device 110 through a physical interface (e.g., microSD interface). In response to at least activation of the kill mode, the transaction card 112 may permanently act as a mass memory stick. In some implementations, the transaction card 112 may not be put into any other mode if the reset needle tip is pressed. Additionally, the transaction card 112 may delete financial content in memory in response to at least the mode being activated. In some implementations, the financial institution 106 may use this mode to delete data from a transaction card 112 that is physically lost but still connected to the wireless network via the host device 110.

With respect to the memory mode, the transaction card 112 may function as a mass memory stick such that the memory may be accessed by conventional methods. In some implementations, the transaction card 112 may automatically activate the mode in response to at least being removed from the host device, inserted into an unauthorized host device, and/or other events. The transaction card 112 may switch from the memory mode to the active mode, for example, by inserting the card 112 into an authorized device, or may switch from the mode to the self-training mode to re-personalize the device for a new host device or a new user account. In some implementations, the memory mode may operate substantially the same as the inactive mode.

In some implementations, the transaction card 112 may be re-personalized/updated, such as using a software device management process and/or a hardware reset. For example, the user may want to re-personalize the transaction card 112 for changing host devices, to own multiple host devices, and/or for other reasons. With respect to software device management, the user needs to mount (cradle) a new host device, insert the transaction card 112 to launch the software device management application. In some implementations, the software management application may be an application installed directly on the client 104, integrated as a plug-in to a normal synchronization application such as ActiveSync, available via a browser plug-in running on a plug-in provider website, and/or other source. The user may log into the application and verify his identity, and in response to the verification, the application may allow access to the device part of the device management application. The device management application may read the transaction card 112 and display the MAC address, signature, and/or other device specific information of the device into which he inserted his plug-in. The mobile device 110 may be marked as active and the host device may be shown as disabled or inactive. The application may allow the user to update the status of the new host device, and in response to at least this selection, the device management application may install a signature on the new host device and mark the update status as allowed in the secure memory of the transaction card 112. The user may also be able to update the status of the mobile device 110 to disabled. Otherwise, both devices may be active and the transaction card 112 may switch between the two devices. With respect to the hardware reset process, the user may activate the self-training mode using a reset needle tip button on the physical transaction card 112. In this mode, financial data may be deleted and must be reloaded. As described above, the provisioning process may begin when the transaction card 112 is inserted into a new host device.

The POS114 may include any software, hardware, and/or firmware that receives account information from the transaction card 112 for performing transactions with one or more financial institutions 106. For example, the POS114 may be an electronic cash register capable of wirelessly communicating transaction information with the transaction card 112 a. The POS114 may communicate transaction information associated with conventional contact payment methods, such as plastic cards and checks. If a wireless/contactless payment transaction is enabled, the POS114 may communicate information with the transaction card 112 in one or more of the following formats: 14443 type A/B, Felica, MiFare, ISO 18092, ISO 15693; and/or others. The transaction information may include verification information, check number, bank number, account number, transaction amount, time, driver's license number, merchant ID, merchant parameters, credit card number, debit card number, digital signature, and/or other information. In some implementations, the transaction information may be encrypted. In the illustrated implementation, the POS114 may wirelessly receive encrypted transaction information from the transaction card 112 and electronically transmit the information to one or more of the financial institutions 106 for authorization. For example, the POS114 may receive an indication that the transaction amount has been accepted or declined for the identified account and/or request additional information from the transaction card 112.

As used in this disclosure, the client 104 is intended to encompass a personal computer, touch screen terminal, workstation, network computer, desktop computer, kiosk, wireless data port, smart phone, PDA, one or more processors within these or other devices, or any other suitable processing or electronic device for viewing transaction information associated with the transaction card 112. For example, client 104 may be a PDA that is available to wirelessly connect with an external or unsecured network. In another example, client 104 may include a laptop computer containing an input device such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with transactions performed with financial institution 106, including digital data, visual information, or GUI 115. In some implementations, the client 104b may wirelessly communicate with the transaction card 112b using, for example, the NFC protocol. In some implementations, the client 104a includes a card reader 116 having a physical interface for communicating with the transaction card 112 c. In some implementations, the card reader 116 can include at least an adapter 116b that fits the interface supported by the client 104 (e.g., USB, firewire, Bluetooth, WiFi) to the physical interface supported by the card 112 (e.g., SD/NFC). In this case, the client 104a may not include a transceiver for wireless communication.

GUI115 comprises a graphical user interface operable to allow a user of client 104 to interface with at least a portion of system 100 for any suitable purpose, such as viewing transaction information. Generally, GUI115 provides an efficient and user-friendly presentation of data provided by system 100 or communicated within system 100 to a particular user. The GUI115 may include a plurality of customizable frames or views having interactive fields, drop down lists, and/or buttons operated by a user. The term "graphical user interface" may be used in the singular or in the plural to describe one or more graphical user interfaces and each display of a particular graphical user interface. GUI115 may include any graphical user interface, such as a generic web browser or touch screen, that processes information in system 100 and presents results to a user. Financial institution 106 may accept data from client 104 using, for example, a web browser (e.g., Microsoft Internet Explorer or Mozilla Firefox) and return an appropriate response (e.g., HTML or XML) to the browser using network 108. In some implementations, the GUI 111c of the transaction card 112c may be presented through the GUI115a of the client 104 a. In these implementations, the GUI115a may retrieve user credentials from the GUI 111c and populate financial forms presented in the GUI115 a. For example, GUI115a may present a form to the user for entering credit card information to purchase goods over the internet, and GUI115a may populate the form using GUI 111c at least in response to a request from the user.

Financial institutions 106a-c may include any enterprise that may authorize transactions received over network 108. For example, financial institution 106a may be a credit card provider that determines whether to authorize a transaction based at least in part on information received over network 106. Financial institution 106 may be a credit card provider, a bank, a federation (e.g., VISA), a retail merchant (e.g., Target), a prepaid/gift card vendor, internet banking, and/or others. Generally, the financial institution 106 may perform one or more of the following processes: receiving a request to authorize a transaction; identifying account numbers and other transaction information (e.g., PINs); identifying a fund and/or credit limit associated with the identified account; determining whether the transaction request exceeds a funding and/or credit limit and/or violates any other rules associated with the account; sending an indication of whether the transaction has been accepted or rejected; and/or other processes. With respect to banking, the financial institution 106 may identify an account number (e.g., bank account, debit card number) and associated verification information (e.g., PIN, zip code) and determine the funds available to the account holder. Based at least in part on the identified funds, the financial institution 106 may accept or decline the requested transaction or request additional information. As for encryption, the financial institution 106 may encrypt and decrypt data using a public key algorithm such as RSA or elliptic curve and/or a private key algorithm such as TDES.

The network 108 facilitates wireless or wired communication between the financial institution and any other local or remote computer, such as the client 104 and the POS device 114. Network 108 may be all or part of an enterprise or secured network. Although illustrated as a single network, the network 108 may be a continuous network logically divided into various sub-networks or virtual networks without departing from the scope of the present invention, so long as at least a portion of the network 108 may facilitate the transfer of transaction information between the financial institution 106, the client 104, and the offline store 102. In some implementations, the network 108 encompasses any internal or external network or networks, sub-network, or combination thereof, that can be used to facilitate communications between computing components in the system 100. Network 108 may communicate, for example, Internet Protocol (IP) packets, frame relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. Network 108 may include one or more Local Area Networks (LANs), Radio Access Networks (RANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), all or a portion of the global computer network known as the internet, and/or any other communication system or systems at one or more locations.

Fig. 2 is a block diagram illustrating an example transaction system 200 for wirelessly communicating transaction information using cellular radio technology. For example, the system 200 may wirelessly communicate a transaction receipt to the transaction card 112 using the mobile host device 110 and cellular radio technology. In some implementations, the cellular radio technology may include global system for mobile communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), and/or any other cellular technology. The financial institution 106 may assign one or more mobile host devices 110 to the transaction card 112 in response to one or more events. In some examples, the user may register the one or more mobile devices 110 with the financial institution 106 in connection with, for example, requesting an associated transaction card 112. In some examples, the transaction card 112 may register the mobile host device 110 with the financial institution 106 in response to at least an initial insertion of the device 110. Regardless of the association process, the system 100 may use the cellular capabilities of the host device 110 to transfer information between the financial institution 106 and the transaction card 112. When using the cellular radio technology of the host device 110, the system 100 may communicate with the transaction card 112 without the card 112 being proximate to a retail device, such as the POS device 114 of FIG. 1.

In the illustrated implementation, the cellular core network 202 generally includes various switching elements, gateways, and service control functions for providing cellular services. The cellular core network 202 typically provides these services via a plurality of cellular access networks (e.g., RANs) and also interfaces the cellular system with other communication systems (e.g., the network 108) via the MSC 206. According to cellular standards, the cellular core network 202 may include a circuit-switched (or voice-switched) portion for handling voice calls and a packet-switched (or data-switched) portion for supporting data transfers, such as e-mail messages and web browsing. The circuit-switched portion includes the MSC206 that switches or connects telephone calls between the Radio Access Network (RAN)204 and the network 108 or another network, between the cellular core network or other network. In the case where core network 202 is a GSM core network, core network 202 may include a packet-switched portion, also known as General Packet Radio Service (GPRS), including a Serving GPRS Support Node (SGSN) (not shown) for serving and tracking communication device 102 and a Gateway GPRS Support Node (GGSN) (not shown) for establishing connections between the packet-switched network and communication device 110, similar to MSC 206. The SGSN may also contain user data for establishing and handing over call connections. The cellular core network 202 may also include a Home Location Register (HLR) for maintaining "permanent" subscriber data and a Visitor Location Register (VLR) (and/or SGSN) for "temporary" maintenance of subscriber data retrieved from the HLR using wireless communication methods and up-to-date information on the location of these communication devices 110. In addition, the cellular core network 202 may include authentication, authorization, and accounting (AAA) that performs authentication, authorization, and accounting tasks for the devices 110 that may be used to access the GSM core network 202. Although the illustration of the core network 202 is described with reference to a GSM network, the core network 202 may include other cellular radio technologies (e.g., UTMS, CDMA, and others) without departing from the scope of the present invention.

The RAN204 provides a radio interface between mobile devices and the cellular core network 202 that can provide real-time voice, data, and multimedia services (e.g., calls) to the mobile devices over a macro call (macrocall) 208. In general, the RAN204 communicates over-the-air frames via a Radio Frequency (RF) link. In particular, the RAN204 converts air frames into physical link-based messages for transport through the cellular core network 202. The RAN204 may implement, for example, one of the following radio interface standards during transmission: advanced Mobile Phone Service (AMPS), GSM standard, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), IS-54(TDMA), General Packet Radio Service (GPRS), enhanced data rates for Global evolution (EDGE), or a dedicated radio interface. The user may subscribe to the RAN204, for example, to receive cellular telephone service, Global Positioning System (GPS) service, XM radio service, and so on.

The RAN204 may include Base Stations (BSs) 210 connected to Base Station Controllers (BSCs) 212. BS210 receives and transmits air frames (i.e., transmitted by cellular device 102 e) within the geographic area of RAN204 and communicates with other mobile devices 110 connected to GSM core network 202. Each BSC 212 is associated with one or more BSs 210 and controls the associated BSs 210. For example, BSC 212 may provide various functions such as handoff, cell configuration data, control of RF energy levels, or any other suitable functions for managing radio resources and routing signals to and from BS 210. The MSC206 handles access to the BSC 212 and the network 108. The MSC206 may be connected to the BSC 212 via a standard interface, such as an a-interface (a-interface). Although the elements of the RAN204 are described with reference to a GSM network, the RAN204 may include other cellular technologies such as UMTS, CDMA, and/or others. In the case of UMTS, the RAN204 may include node bs and Radio Network Controllers (RNCs).

The contactless smart card 214 is a pocket-sized card with an embedded integrated circuit that processes information. For example, the smart card 214 may receive transaction information wirelessly, process the information using an embedded application, and send a response wirelessly. The contactless smart card 214 may communicate wirelessly with the reader through RFID sensing technology at data rates of 106 to 848 kbps. The card 214 may communicate wirelessly between 10cm (e.g., ISO/IEC14443) to 50cm (e.g., ISO 15693) with a proximity reader. The contactless smart card 214 operates independently of an internal power source and captures energy from an incident radio frequency interrogation signal to power the embedded electronic circuitry. The smart card 214 may be a memory card or a microprocessor card. Generally, memory cards include only non-volatile memory storage components and may include some dedicated security logic. The microprocessor card includes volatile memory and a microprocessor component. In some implementations, the smart card 214 may have dimensions of a normal credit card size (e.g., 85.60 × 53.98 × 76mm, 5 × 15x.76mm). In some implementations, the smart card 214 may be a fob or other security token. The smart card 214 may include a security system having tamper-resistant properties (e.g., a secure cryptoprocessor, a secure file system, human-readable features) and/or may be configured to provide security services (e.g., confidentiality of stored information).

In some aspects of operation, the financial institution 106 may use the mobile host device 110 to communicate information to the transaction card 112. For example, the financial institution 106 may wirelessly communicate with the mobile host device 110 using the cellular core network 202. In some implementations, the financial institution 106 may send information to the mobile host device 110 in response to at least one event. The information may include, for example, transaction information (e.g., transaction receipts, transaction history), scripts, applications, web pages, and/or other information associated with the financial institution 106. The event may include completing a transaction, determining that the transaction card 112 is outside the operating range of the POS terminal, receiving a request from a user of the mobile host device, and/or others. For example, the financial institution 106 may identify a mobile host device 110 associated with the card 112 performing the transaction and send the transaction information to the mobile host device 110 using the cellular core network 202. When using the cellular core network 202, the financial institution 106 may transmit information to the transaction card 112 without requiring a POS terminal to be in proximity to the card 112. Additionally or alternatively, the financial institution 106 may request information from the mobile host device 110, the transaction card 112, and/or the user using the cellular core network 202. For example, the financial institution 106 may send a request for the transaction history to the card 112 through the cellular core network 202 and the mobile host device 110.

In some aspects of operation, a merchant or other entity may treat mobile host device 110c as a mobile POS terminal configured to wirelessly execute transactions with smart card 214. For example, the merchant may be mobile (e.g., a taxi cab driver) and may include a mobile host device 110c with a transaction card 112 c. In this example, the transaction card 112c may wirelessly receive account information from the smart card 214 and the POS114 may send an authorization request to the financial institution 106 using the mobile host device 110 and the cellular core network 202. In response to at least the request, the financial institution 106 may generate an authorization response to the transaction card 112c using the mobile host device 110 and the cellular core network 202.

In some implementations, the system 100 may perform one or more of the modes discussed with reference to fig. 1. For example, the transaction card 112 may be re-personalized/updated using the cellular radio technology of the mobile host device 110. The user may want to re-personalize the transaction card 112 for changing host devices, to own multiple host devices, and/or for other reasons. With respect to software device management, the user may use the cellular radio technology of the host device 110 to send a request to re-personalize the transaction card 112 to the financial institution 106.

FIG. 3 is a block diagram illustrating the example transaction card 112 of FIG. 1, according to some implementations of the invention. Generally, the transaction card 112 includes a personalization module that performs financial transactions independently of the mobile device 110. The illustrated transaction card 112 is for example purposes only, and the transaction card 112 may include some, all, or different modules without departing from the scope of the present invention.

In some implementations, the transaction card 112 may include an interface layer 302, an API/UI 304, a web server 306, a real-time framework 308, a payment application 310, a value-added application 312, user credentials 314, a real-time operating system 316, a contactless chipset 318, antenna control functionality 320, an antenna 322, bank-used memory 324, and free memory 326. In some implementations, the host controller includes an interface layer 302, an API/UI 304, a web server 306, a real-time framework 308, a contactless chipset 318, and an antenna control function 320. In some implementations, the security module includes a payment application 310 and user credentials 314. The bank used memory 324 and free memory 326 may be contained in flash memory. In some implementations, contactless chipset 318 may be integrated into a secure module or operate independently. The antenna 322 may be an electronic circuit.

The interface layer 302 includes both interfaces to the host device (i.e., physical connections) and the outside world (i.e., wireless/contactless connections). In a payment implementation, the wireless connection may be based on any suitable wireless standard, such as contactless (e.g., ISP 14443A/B), proximity (e.g., ISO 15693), NFC (e.g., ISO 18092), and/or others. In some implementations, the wireless connection may use another short-range wireless protocol, such as bluetooth, another proprietary interface used by retail payment terminals (Felica, MiFare, asia, etc., japan), and/or others. With respect to the physical interface, the interface layer 302 may physically interface with the mobile device 110 using an SD protocol such as MicroSD, Mini-SD, or SD (full size). In some implementations, the physical interface can include a converter/adapter for converting between two different protocols based at least in part on the mobile device 110. In some implementations, mobile device 110 can communicate using protocols such as USB, MMC, iPhone proprietary interface, or others.

The API/UI layer 304 may include any software, hardware, and/or firmware that functions as an API between the mobile device 110 and the transaction card 112 and as the GUI 111. Prior to performing a transaction, the transaction card 112 may automatically install a driver in the mobile device 110 in response to at least the insertion. For example, the transaction card 112 may automatically install a MicroSD device driver in the device 110 to enable the transaction card 112 to interface with the mobile device 110. In some implementations, the transaction card 112 may install an enhanced device driver, such as a mass storage with radio (MMR) API. In this implementation, the interface may drive a plug-in class containing mass storage and a radio interface. The MMR API may perform one or more of the following processes: connect/disconnect MMR controller (microcontroller in plug-in); data is transferred using MM protocols (e.g., SD, MMC, XD, USB, firewire); sending the encrypted data to the MMR controller; receiving an acknowledgement of success or error; receiving a status word indicating an error description; turn on/off the radio; transmit an instruction to the transaction card 112 to turn on the antenna and specify a mode of operation (e.g., transmit mode, listen mode); transmit data, such as sending instructions to the controller for transmitting data via radio; listening for data, such as sending instructions to the controller for listening for data; read data, such as sending an instruction to the controller to send data received by the listening radio; and/or others. In some implementations, the MMR may be TCP/IP compatible. In some implementations, the ISO 7816 commands of the encapsulated API may be processed by the security module, among other commands.

In some implementations, the API may operate according to two processes: (1) the transaction card 112 acts as a master and the mobile device 110 acts as a slave; and (2) card UI as a host. In a first process, the transaction card 112 may communicate one or more commands to the mobile device 110 in response to, for example, insertion of the transaction card 112 into a slot of the mobile device 110, a transaction between the transaction card 112 and the POS114, and/or other events. In some implementations, the transaction card 112 may request the mobile device 110 to perform one or more of the following functions: acquiring user input; acquiring a signature; displaying the data; sending data; receiving data; and/or others. The get user input command may present a data request from the user through the GUI 111. In some implementations, "obtain user input" may present a request for multiple data inputs. The data input may be in any suitable format, such as a numeric, alphanumeric, and/or other string of characters. The get signature command may request that the mobile device 110 return identification data, such as a phone number, a device ID like an IMEI code or MAC address, a network code, a subscription ID like a SIM card number, a connection status, location information, Wi-Fi beacons, GPS data, and/or other device specific information. The "display data" command may present a dialog box to the user via the GUI 111. In some implementations, the dialog box may disappear after a period of time, user selection, and/or other event. The "send data" command may request that the mobile device 110 send packet data using its own connection to the outside world (e.g., SMS, cellular, Wi-Fi). The "receive data" command may request that the mobile device 110 open a connection channel with certain parameters and identify data received over the connection. In some implementations, the command may request that the mobile device 110 forward any data (e.g., SMS) meeting certain criteria to be forwarded to the transaction card 112.

With respect to the UI as a host, the UI may execute one or more of the following commands: security module commands/responses; activation/deactivation; flash memory read/write; transmitting the data with or without encryption; receiving data with or without decryption; URL get data/URL post (post) data; and/or others. The "security module command" may relate to the security functionality provided by the card and be directed to a security module within the transaction card 112 (e.g., standard ISO 7816 commands, proprietary commands). In some implementations, these commands may include encryption, authentication, provisioning data, creating a security domain, updating user credentials after verifying a key, and/or others. In some implementations, these commands may include non-security related smart card commands, such as read transaction history commands. The read transaction history command may perform a read of the secure memory 324 of the transaction card 112. In some implementations, certain flags or regions of secure memory 324 may be written after security verification. The activate/deactivate command may activate or deactivate certain functions of the transaction card 112. The "flash read/write" command may perform a read/write operation to a designated area of the unsecure memory 326. The "transmit data with or without encryption" command may instruct the transaction card 112 to transmit data using its wireless connection with, for example, the POS 114. In addition, this data may be encrypted by the transaction card 112 prior to transmission using, for example, keys and encryption capabilities stored within the secure module. The "receive data with or without decryption" command may instruct the transaction card 112 to switch to a listening mode to receive data from its wireless connection with a terminal/card reader (e.g., the POS 114). In some implementations, data decryption may be requested by the security module using, for example, keys and decryption algorithms available on the security module (i.e., onboard decryption). The "URL get data/URL advertisement data" command may instruct the web server 306 to return the page according to the offline get or advertisement instruction using, for example, an offline URL.

The web server 306, which is part of the operating system of the transaction card 112, may assign or otherwise associate a URL pattern addressing to a particular file stored in the memory 326 (e.g., flash memory) of the transaction card 112. In some implementations, the web server 306 uses the URL to locate the file and returns the file to the browser using standard HTTP, HTTPs style transfers. In some implementations, the definitions of these files may be formatted using standard HTML, XHTML, WML, and/or XML style languages. The file may include links to additional offline storage locations in memory 326 or to internet websites accessible by mobile device 110. In some implementations, the web server 306 may support a secure protocol such as SSL. web server 306 may transfer the application in memory 326 to mobile device 111 for installation and execution. The web server 306 may request the capabilities of the browser on the device 110 using, for example, a browser user agent profile to customize the offline web page according to the capabilities supported by the device and browser (e.g., supported markup language, screen size, resolution, color, etc.).

As part of the real-time operating system, the real-time framework 308 may perform one or more functions based at least in part on one or more time periods. For example, the real-time framework 308 may enable an internal clock available on the CPU to provide timestamps in response to at least the requested event. The real-time framework 308 may allow certain tasks to be scheduled for execution in response to at least certain time and/or event based triggers. In some implementations, the real-time framework 308 may allow the CPU to insert delays in certain transactions. In some implementations, a portion of the WAP standard known as WTAI (wireless telephony application program interface) may be implemented to allow offline browser pages on the card 112 to take advantage of functionality provided by the mobile device 110 (e.g., send/receive wireless data, send/receive SMS, make voice calls, play ring tones, etc.).

Payment application 310 may include any software, hardware, and/or firmware that uses a predefined sequence and/or data format to exchange transaction information with a retail terminal in some instances. For example, the payment application 310 may generate a response to the transaction request in a format compatible with the retail terminal payment processing application by selecting, extracting, or otherwise including user credentials in the response. In some implementations, payment application 310 may perform one or more of the following processes: transmitting attributes of the transaction card 112 in response to at least the identification request received from the POS 114; receiving a request to execute a transaction from, for example, POS 114; identifying user credentials in memory 324 used by the bank at least in response to the request; generating a transaction response based at least in part on the user credentials; sending the transaction response to the POS114 using, for example, a contactless chipset; receive plaintext data (e.g., a random number) from the POS114 and provide a response containing the encrypted data by encrypting the plaintext data using the cryptographic capabilities of the secure element; sending the encrypted data using contactless chipset 318; incrementing a transaction counter upon receipt of each transaction request; transmitting the value of the transaction counter in response to a request from the POS 114; storing details of the transaction request received from the POS114 in a transaction history area of memory 324 used by the bank; send a transaction history to the CPU of the smart card 112 in response to such a request; receiving an ISO 7816 request from the CPU of the smart card 112; performing a corresponding transaction using the secure element operating system; providing a response to the CPU; and/or other processes. In generating the transaction response, the payment application 310 may generate the response in a format specified by a payment network (VISA, MasterCard, Amex, Discover) associated with the financial institution 106 or a format proprietary to that owned and defined by the financial institution 106 and processable by the POS 114. The transaction request may include one or more of the following: user credentials (e.g., account number); validity period data; a card verification number; transaction aggregation; and/or other card or user information. In some implementations, the payment application 310 may include a browser application for allowing transactions. Browser application 310 may be a browser that may be installed if device 110 lacks a browser or has a browser that is incompatible with web server 306 on card 112. After installation of such a browser 310, future communications between the mobile device 110 and the web server 306 utilize the newly installed browser.

The real-time operating system 316 may execute or otherwise include one or more of the following: a real-time framework 308; a host process that implements a physical interface between the transaction card CPU and the mobile device 110; an interface for implementing a physical interface between the transaction card CPU and the security module; a memory management process that implements an ISO 7816 physical interface between the transaction card CPU and memory 324 and/or 326; an application layer process that implements API and UI capabilities; a web server 306; an antenna control function 320; power management; and/or others. In some implementations, the real-time operating system 316 may manage the physical interface between the transaction card CPU and the secure memory 324, the secure memory 324 including memory segments and/or data buffers/pipes to allow limited access to particular memory areas. In some implementations, the security module may include a security module operating system provided by the security module vendor and may be compatible with the Visa and MasterCard specifications. The security module operating system may structure the data in the security module to be compliant with the Paypass and/or payWave specifications or any other available contactless retail payment industry specification. In addition, the security module may store the host device signature and the allowed mode of the antenna 322 in the secure element 324. In some implementations, the real-time operating system 316 may include a microcontroller operating system configured to personalize the secure element 324, such as, for example, by converting raw FV data (account number, expiration date, Card Verification Number (CVN), other application-specific details) into secure cryptographic information. In addition, the microcontroller operating system may present the card 112 to the host device as MicroSD mass storage. The microcontroller operating system may partition the memory into a user portion and a protected device application portion. In this example, the device application portion may be used to store a provider-specific application that is operated from the memory portion or installed on the host device from the memory portion.

The secure module chip may provide tamper-resistant hardware security functions for encrypting, authenticating, managing user credentials using multiple security domains, onboard processing capabilities for personalization, access and storage, and/or others. In some implementations, the secure module chip may include a contactless chipset 318.

Contactless chipset 318 may provide hardware protocol implementations and/or drivers for RF communications. For example, contactless chipset 318 may include onboard RF circuitry for interfacing with outside world connections using wireless/contactless connections. The wireless connection may be, for example, client to node (terminal/reader/base station), node to client (passive tag), or peer to peer (another transaction card 112).

The antenna control function 320 may control the availability of the RF antenna. For example, the antenna control function 320 may activate/deactivate the antenna 322 in response to, for example, successful authentication, completion of a routine established by the operating system 316, and/or other events. The antenna 322 may be a short range wireless antenna connected to the NFC inlay (inlay) via a software switch such as a nand gate or other element.

FIG. 4 is a block diagram illustrating an example smart card 400 in accordance with some implementations of the invention. For example, the transaction card of FIG. 1 may be implemented in accordance with the illustrated smart card 400. Generally, the smart card 400 may access services and/or transactions independently. The smart card 400 is for illustration purposes only and may include some, all, or different elements without departing from the scope of the present invention.

As shown, smart card 400 includes an antenna 402, a switch plus tuning circuit 404, a security module and contactless chipset 406, a CPU408, and a memory 410. The antenna 402 wirelessly transmits and receives signals such as NFC signals. In some implementations, the switch plus tuning circuit 404 may dynamically adjust the impedance of the antenna 402 to tune the transmit and/or receive frequency. In addition, the switch plus tuning circuit 404 may selectively turn the antenna 402 on and off in response to at least commands from the CPU 408. In some implementations, antenna 402 may be a short range wireless antenna connected to the NFC inlay via a software switch, such as a nand gate or other element, to allow code from CPU408 to turn antenna 402 on and off. In some implementations, card 400 may include an NFC mosaic (not shown) that may be a passive implementation of NFC short-range wireless technology that derives power from the reader terminal to send back data or a stronger implementation that uses an eNFC chipset to power the active reader mode and the self-training mode. Additionally, the card 400 may include an external needle reset (not shown) that causes the CPU408 to de-personalize the memory or security element.

The CPU408 may send switch commands in response to events such as user requests, transaction completion, and/or the like. When open, the secure chip and contactless chip set 406 is connected to the antenna 402 and performs one or more of the following processes: formatting signals according to one or more formats for wireless communication; decrypting the received message and encrypting the transmitted message; authenticating user credentials stored locally in memory 410; and/or other processes. The memory 410 may include secure and non-secure portions. In this implementation, the secure memory 410 may store one or more user credentials that are not accessible by the user. Additionally, the memory 410 may store offline web pages, applications, transaction histories, and/or other data. In some implementations, the memory 410 may include from 64MB to 32GB of flash memory. Additionally, memory 410 may be divided into user memory and device application memory. Chipset 406 may include a security module such as Visa and/or MasterCard certified for storing financial instrument data and/or according to a global standard. In addition to the user financial instruments, the secure element may store the signature and/or antenna pattern of the allowed host device.

In some implementations, the CPU408 may switch the antenna 402 between the active and inactive modes based at least in part on personalization parameters defined by, for example, a user, a distributor (e.g., financial institution, service provider), and the like. For example, CPU408 may activate antenna 402 when smart card 400 is physically connected to a host device and a handshake with the host device is successfully performed. In some implementations, CPU408 may automatically deactivate antenna 402 when smart card 400 is removed from the host device. In some implementations, antenna 402 is always active so that smart card 400 can be used as a stand-alone access device (e.g., a device on a key fob). With respect to the handshaking process, CPU408 may perform one or more authentication processes prior to activating smart card 400 and/or antenna 402, as shown in fig. 7. For example, the CPU408 may perform physical authentication, device authentication, and/or user authentication. For example, CPU408 may activate antenna 402 in response to at least detecting a connection to a physical interface (e.g., SD interface) with a host device and successfully installing a device driver (e.g., SD device driver) for mass memory access on the host device. In some implementations, the device authentication may include a physical authentication in addition to a signature comparison made between a device signature created during first use (provisioning) stored in a memory (e.g., a security module (SE)) and a runtime signature computed using, for example, unique parameters of the host device. In the absence of a host device signature in memory, CPU408 may bind the first compatible host device into which card 400 is inserted. A compatible host device may be a device that can successfully achieve physical authentication. If the host device signature is present in memory, CPU408 compares the stored signature to the current host device's real-time signature. If the signatures match, the CPU408 may proceed to complete the boot operation. If the signatures do not match, the host device is rejected, booting is aborted and the card 400 is returned to the mode prior to insertion into the device.

User authentication may include verifying a physical connection with a user using a PIN entered by the user, a x.509-type certificate that is unique to the user and stored on a host device, and/or other processes. Device and user authentication may verify a physical connection with a device through comparison of device signatures and user authentication through verification of a user PIN or certificate. In some implementations, the user may select a PIN or certificate at provisioning time. If this is the case, the CPU408 may instantiate a software plug-in on the host device. For example, the software plug-in may request the user's PIN in real time, read user credentials (e.g., x.509) installed on the device, and/or the like. The operation of the software plug-in may be customized by the provider. In any case, the returned user data may be compared to the user data stored in memory. In case of a successful match, the antenna 402 may be activated. In the event that the credentials do not successfully match, the card 400 is disabled. In the case of an unsuccessful PIN match, the user may be requested to repeat PIN attempts until a successful match or the number of attempts exceeds a threshold. The disc provider may customize the attempt threshold.

With respect to network authentication, the host device may be a cellular telephone so that card 400 may request network authentication prior to activation. For example, card 400 may be distributed by a Wireless Network Operator (WNO) that requires network authentication. In this example, a flag in memory may be set to ON, indicating that network authentication is required. If the flag is set to ON, a unique identity for the allowed network is stored locally in memory, such as a mobile network code for a GSM network, a NID for a CDMA network, an SSID for a broadband network, and/or an identifier. If the flag is ON, the CPU408 may request that a specialized software plug-in be downloaded to the host device and instantiated in response to at least the insertion. The software plug-in may query the host device to respond with network details. In some cases, the type of unique network identity used and the method used to infer it from the host device is variable and depends on the network provider and the capabilities of the host device. If the locally stored ID matches the request ID, CPU408 activates antenna 402 to allow access or otherwise denies service.

FIG. 5 illustrates an example transaction system 500 for wirelessly communicating transaction information using one of a plurality of interfaces. For example, the system 500 may interface with the transaction card 112 using a wired or wireless interface. With respect to the wired interface, the system 500 includes an adapter 504 and a reader 506. Adapter 504 may include any software, hardware, and/or firmware configured to convert between a format compatible with card 112 and a format compatible with client 104 c. For example, the adapter 504 may convert between the microSD protocol and the USB protocol. The reader 506 may include any software, hardware, and/or firmware configured to interface directly with the card 112 h. For example, the reader 506 may be a microSD reader to interface the client 104d with the card 112h using the microSD protocol. With respect to wireless interfaces, system 500 may include a cellular interface 502 and a short-range wireless interface 508. With respect to the cellular interface 502, the financial institution 106 may wirelessly communicate with the transaction card 112e using the cellular radio technology of the mobile device 110 e. For example, cellular interface 502 may be a CDMA interface, a GSM interface, a UMTS interface, and/or other cellular interface. With respect to the short-range wireless interface 508, the financial institution 106 may wirelessly communicate with the transaction card 112f using, for example, WiFi technology. The short-range wireless interface 508 may be an 802.11 interface, a bluetooth interface, and/or other wireless interface. In these implementations, the client 104e may include a transceiver for wirelessly communicating with the transaction card 112 f.

FIG. 6 is an illustration 600 of personalization of a smart card (e.g., transaction card 112, service card 210). In particular, the smart card may be personalized either before release to the user (i.e., pre-release) or after release to the user (i.e., post-release). With respect to pre-issuance, smart cards can be personalized in large quantities, for example at the factory. In this example, each smart card may be loaded with user credentials, a security framework, applications, offline web pages, and/or other data. In some implementations, the smart card may be individually personalized, for example, at a bank branch. In this case, the disc may be separately loaded with data associated with the user after, for example, purchasing the smart card. For post issuance, the smart card may be wirelessly personalized. For example, the transaction card 112 may be personalized through a cellular connection established using the mobile device 110. In some implementations, the smart card may be personalized by synchronizing with a computer, such as client 104. The transaction card 112 may receive the personalized receipt from a business associated with at least the financial institution 106 prior to activation, including: a user credential; a payment application; and at least one of an operation flag, a rule table, or a user interface. The personalized receipt present in the card may be updated after activation using at least one of the following methods: wireless or by other over-the-air messages containing application-specific and secure update instructions; an internet or client application running on a PC connected to the transaction card 112 via a host device or card reader; an internet application wirelessly connected to the transaction card 112 via a host mobile device or the user interface application of the transaction card 112 itself; and/or other methods.

In some implementations, provisioning of the smart card may be based at least in part on a distribution entity (e.g., financial institution, wireless carrier, user). For example, smart cards may be distributed by financial institutions such as banks. In this bank implementation, the smart card may be pre-provisioned with the user account. In this case, the smart card may be activated at least in response to an initial insertion into the host device. The antenna mode may be set by default to physical authentication only. In some examples, the user may select PIN authentication himself or prevent unauthorized use through a PC cradle (cradle) and plug-in management software without the host device having a screen and keyboard. In wireless carrier implementations, smart cards require device authentication prior to activation. In some examples, the user may provide financial data (e.g., credit or debit cards) using one of several methods. In addition, the user may add user authentication. In a user-provided implementation, the user may obtain the smart card from, for example, a retail store or other channel, such as an OEM host device manufacturer. In this case, the user may activate the card in a number of different devices using the offer selected by the provider.

With respect to activation for financial transactions, the smart card may be configured into a memory mode when the user retrieves the disc from, for example, a bank, a wireless carrier, a third party provider, and/or others. Activating the card may include the following two levels: 1) physically, specifying antenna availability in a specific set of circumstances required by the provider; and b) logically, indicating at the financial institution activation of the financial instrument carried on the activation card. In some implementations, the activation may be based at least in part on the device wholesaler, antenna availability selection, and/or type of host device, as shown in table 1 below.

Table 1:

plug-in vendor and distribution mode	Plugin initial state and antenna availability selection	The device does not have a screen/keyboard	The device has a screen and a keyboard
				FI: the financial institution (bank or retailer) will	The plug-in being in memory mode, for full use	Manual operation: the subscriber must call the number of the FI to activate him	If the device has wireless access capability, then insert

The plug-in is shipped directly to the customer or through the participation of resellers/distributors, etc.	User account information (FV) for personalization and antenna mode set to physical authentication	Account, the device may only operate a single account. The user can also use another PC to access the FI site on the Internet to activate his account	Thereafter, the plug-in generates a web page and takes the user to the FI's website. The user himself activates his account by entering his account number and matching the secret personal information (e.g. the last four digits of the SSN or home phone number). At the same time, the user may also optionally select a PIN (change antenna availability to user authentication). If an Internet connection is not available, the device may automatically place a voice call to the number of the FI to activate the account. If the wireless connection is not available (the device is a PDA only), the user must revert to manual activation (see left column)
				WNO: the wireless network operator carries the plug-in packaged with the host device and if the user wants to use the service, the user can select his preferred host device and package the plug-in with the device.	The plug-in is in memory mode, which is partially personalized (device signature of the host device is loaded to prevent the user from changing the host device) while FV information is not loaded. Antenna availability is set to device authentication (a plug-in can only be used with the host device that carries it)	Not applicable to	Suppose that: the device has a wireless connection available. The operator provides a packaged wallet management application. When the user clicks on the wallet management application, the user is invited to register a new account with the operator's partner FI. Once the registration is successful, the account data is downloaded over the air or over the internet to the plug-in and activated for use. In this scenario, a device may use multiple FIs and store multiple FVs. The user may choose to enter a PIN for a FV in the wallet management application to translate antenna availability to user and device authentication because the FV plug-in is bound to the device signature. Upon removal from the device, the antenna is turned off and the plug is converted into a simple mass memory stick. When the plug-in is inserted into another host device, the signatures do not match and the antenna is turned off.

WNO: the wireless network operator ships the plug-in as an accessory with a recommendation for a compatible device, and the user can select his preferred host device and attempt to operate the plug-in with itUsing the service	The plug-in is in memory mode, which is not personalized. Antenna availability is set to network authentication, which is set to ON. The plug-in will bind to the first device into which it was inserted and in which the network authentication was successful	Not applicable to	Suppose that: the device has a wireless connection available. The plug-in will make an internet connection to the operator portal and the wallet managing application will be downloaded after user confirmation. The user may decline to download and choose to manually provision FV data by going to a third party wallet provider or directly to the FI website. The plug-in is bound to the device and the network provider's network. If the same device is unlocked and used on another network, the plug-in will cease operation and will revert to memory mode. Upon removal from the device, the plug-in will revert to memory mode.
				OEM 1: cellular telephone manufacturer	Device authentication (binding device and cellular telephone)	Not applicable to	Option A: the device manufacturer provides the wallet management application and the rest of the process is the same as described above. And option B: the wireless carrier provides a wallet management application. The user goes over the air to the wireless carrier portal and downloads the application. The remainder of the process is the same as described above. And option C: the user navigates to a third party wallet management application (e.g., paypal or Google) to provide registration to participating FI over the internet and personalize FV on a plug-in. Option D: the user navigates to the FI's website and activates a new account personalized on the plug-in over the internet.
And (3) OEM 2: other manufacturers	Device authentication	The user must mount the device using an internet connectionTo the PC and registers on the PC by going directly to the FI's website. Downloading accounts over the Internet via the cradle and then	If the device has a wireless connection (which is a wireless PDA): as above. If the device does not have a wireless connection (it is an unconnected PDA): see left column

The device is activated. In this process, the plug-in is bound to the device signature. Upon removal from the host device, the antenna is turned off. When inserted into another device, the device signature fails and the device is used only as a mass storage device.

The chart shown is for exemplary purposes only. The user may activate the smart card using the same, partial, or different processes without departing from the scope of the present invention.

FIG. 7 is a flow diagram illustrating an example method 700 for automatically booting a smart card in response to at least insertion into a host device. Generally, a smart card may perform one or more authentication processes prior to activation. Many of the steps in this flowchart may occur simultaneously and/or in different orders than as shown. The system 100 or the system 200 may use methods with more steps, fewer steps, and/or different steps, as long as the methods are appropriate.

The method 700 begins at step 702, where an inserted host device is detected. For example, the transaction card 112 may detect insertion into the mobile device 110. If no aspect of the smart card requires authentication, at decision step 704, execution ends. If authentication is required in at least one aspect, execution proceeds to decision step 706. If the communication with the host device includes one or more errors, then at step 708, a failure is indicated to the user. In this example, the transaction card 112 may present an indication of the communication error to the user using the GUI 111. If no communication error is detected at decision step 706, execution continues to decision step 710. In some implementations, the smart card uploads the SD driver to the host device. If the smart card requires only physical authentication, execution proceeds to decision step 712. If the network authentication flag is not set to ON, then at step 714, the antenna is turned ON and the smart card is updated with the host device signature. For this example, the transaction card 112 may activate an antenna for wireless transactions and update local memory with a host signature. At decision step 712, if the network authentication flag is turned on, the smart card sends a request for a network ID to the host device at step 716. Next, at step 718, the smart card retrieves the network ID stored locally. If the stored network ID and the requested network ID match at decision step 720, the disc is activated at step 714. If the two network IDs do not match, the antenna is deactivated at step 722.

Returning to decision step 710, if the authentication is not just a physical authentication, execution continues to decision step 724. If the authentication process includes device authentication, the smart card sends a request for a network ID to the host device at step 726. At step 728, the smart card retrieves the device signature stored locally. If the smart card does not include at least one device signature, execution continues to decision step 734. If the smart card includes one or more device signatures, execution proceeds to decision step 732. If one of the device signatures matches the requesting network ID, execution proceeds to decision step 734. If the signatures do not match the requesting network ID, execution proceeds to step 722 to deactivate. If user authentication is not included in the authentication process, execution proceeds to decision step 712 for physical authentication. At decision step 734, if user authentication is included, execution proceeds to step 738.

Returning to decision step 724, if the authentication process does not include device authentication, execution continues to decision step 736. If the process does not include user authentication, the smart card is turned off at step 722. If user authentication is included, the smart card requests a PIN number from the user using the host device at step 738. Although user authentication is described with reference to entering a PIN through a mobile host device, other information, such as biometric information (fingerprints), may be used to authenticate the user. Returning again to this example, the transaction card 112 may present a request to enter a PIN to the user through the GUI 111. At step 740, the smart card retrieves the PIN stored locally. At decision step 742, if the request PIN matches the stored PIN, execution proceeds to decision step 712 for physical authentication. At decision step 742, if the request PIN does not match the stored PIN, execution proceeds to decision step 744. If the number of attempts does not exceed the specified threshold, execution returns to step 738. If the number of attempts exceeds the threshold, the antenna is deactivated at step 722. In this example, if it is the case that the transaction card 112 fails to authorize the device, network, and/or user, the transaction card 112 may wirelessly transmit an indication to an associated financial institution using the cellular radio technology of the mobile host device 110. In such a case, the illustrated method 700 may be implemented as a fraud control process to substantially prevent unauthorized use of the transaction card 112.

Fig. 8 is an example call flow 800 in accordance with some implementations of the invention. As shown, flow 800 includes a network 802, a host device 804, a smart card 806, and a terminal 808. The host device 804 is configured to communicate with the network 802 and includes a slot for insertion of a smart card 806. The smart card 806 is configured to send commands to and receive data from a user interface application 810 executed by the host device 810 and to execute transactions independently of the host device 810. The card 806 includes a CPU812 for performing transactions and a wireless chipset 814 for communicating with the terminal 808. CPU812 executes host controller/API interface 816, which host controller/API interface 816 is configured to send commands in a form compatible with host device 804 and to convert data from host device 804 into a form compatible with CPU 812.

As shown, the flow 800 may include multiple sessions 820 between the host device 804 and the card 806 and between the card 806 and the terminal 808. Session 820a shows a session that card 806 manages using the network capabilities of host device 810. In this example, the card 806 sends data for transmission over a cellular network connected to the host device 804, and upon receiving the cellular data, the host device 804 sends the data to the network 802. In response to receiving data from the network 802, the host device 804 can automatically send the received data to the card 806. In some implementations, the card 806 may send a request to the host device 804 for a device signature, as shown in the session 820 b. For example, the card 806 may request a device signature during the boot process. The session 820c illustrates that the user may submit commands to the card 806 through the interface of the host device 804. For example, the user may request that the disk display the user's transaction history through an interface of the host device 804.

In some implementations, the card 806 may receive a command to activate or deactivate an antenna through the host device 804, as shown in session 820 d. For example, the financial institution may identify the abnormal transaction and send a command to deactivate the card 806 over the network 802. The card 806 may authorize the user by requesting a PIN using the host device 804. As shown in session 820e, the user may submit a PIN to the card 806 using the interface of the host device 804, and in response to evaluating the submitted PIN, the card 806 may present an indication of the success or failure of the user authentication through the host device 804. In some implementations, the user and/or financial institution may request the transaction history of the card 806, as shown in the session 820 f. For example, the financial institution may send a request for the transaction history over the network 802 connected to the host device 804, and the card 806 may send the transaction history to the financial institution using the network 802 connected to the host device 804 at least in response to the request. In some implementations, the user may present an offline web page stored in the card 806, as shown in the session 820. For example, the card 806 may receive a request from a user to render an offline web page using the host device 804 and render the offline web page using a URL in the request. In some implementations, the data stored in the memory of the card 806 may be presented by, for example, the host device 804, as shown in the session 820 h. For example, a user may request specific information about particular data associated with a transaction, and the card 806 may retrieve the data and present the data to the user using the host device 804. In addition, the user may write data to the memory in the card 806, as shown in the session 820 i. For example, the user may update the transaction data with the annotation, and the card 806 may indicate, at least in response to the request, whether the update succeeded or failed.

With respect to the session between the card 806 and the terminal, the flow 800 illustrates a personalization session 820k and a transaction session 8201. With respect to personalization, the financial institution may personalize the card 806 with user credentials, user applications, web pages, and/or other information, as shown in session 820 k. For example, the terminal 808 may send a provisioning request including associated data to the card 806. Protocol conversion 818 may convert the personalization request into a form compatible with card 806. In response to at least the request, CPU812 sends an indication of the success or failure of the personalization using protocol conversion 818. Before the terminal performs the transaction, the terminal 808 may submit a transaction challenge to the card 806, as shown in session 8201. In this case, the card 806 may identify a device signature for the host device 804, present the associated data to the user through the host device 804, and send the signature to the terminal 808 using the protocol conversion 818.

Fig. 9 is a flow diagram illustrating an example method 900 for activating a wireless transaction system including a smart card. In general, a smart card may perform one or more activation processes in response to a selection, for example, from a user. Many of the steps in this flowchart may occur simultaneously and/or in different orders than as shown. The system 100 or the system 200 may use methods with more steps, fewer steps, and/or different steps, as long as the methods are appropriate.

The method 900 begins at step 902, where a request to activate a transaction card is received. For example, the user may select a graphical element displayed via GUI 111 of mobile host device 110 in fig. 1. At decision step 904, if account activation is included, at step 906, a request to activate the associated financial account is wirelessly transmitted to the financial institution using the cellular radio technology of the host device. For example, the transaction card 112d of fig. 2 may wirelessly transmit an activation request to the financial institution 106 using the cellular radio technology of the mobile host device 110 d. If account activation is not included, execution proceeds to decision step 908. If no card activation is included, execution ends. If card activation is included, execution proceeds to decision step 910. If the activation code is not included, then at step 912, the user is presented with one or more preprogrammed questions using the GUI of the host device. Returning to the initial example, the transaction card 112 may identify locally stored issues and present those issues to the user using the GUI 111 of the mobile host device 110. At step 914, answers to the pre-programmed questions stored locally are identified. Returning to decision step 910, if an activate code is included, execution continues to decision step 916. If the activation code is manually entered by the user, the user is presented with a request for the activation code through the GUI of the mobile host device at step 918. In an initial example, the transaction card 112 may present a request for an activation code, such as a string of characters, to a user through the GUI 111 of the mobile host device 110. If the activation code was not manually entered by the user, the transaction card wirelessly transmits a request for the activation code using the cellular radio technology of the host device at step 920. In this cellular example, the transaction card 112 may transmit a request to a financial institution using the cellular core network 202. In either example, at step 922, the locally stored activation code is identified. At decision step 924, if the locally stored information matches the provided information, then at step 926, the transaction card is activated. For example, the transaction card 112 may be activated at least in response to a user entering a matching activation code through the GUI 111. If the provided information does not match the locally stored information, execution ends.

10A and 10B illustrate example cards 1000 and 1020, respectively, for housing the transaction card 112 of FIG. 1. For example, the transaction card 112 may be inserted into the cards 1000 and 1020 during a personalization process and/or a distribution process. By performing personalization upon insertion, the transaction card 112 may be personalized using the same system used to personalize smart cards that is substantially unmodified. In other words, cards 1000 and 1020 are substantially similar in size to smart cards, such that the personalization system may similarly process cards 1000 and/or 1020. In FIG. 10A, the card 1000 includes a slot 1002 that is made to receive the transaction card 112. For example, the slot 1002 may use a friction fit, such as internal serrations, to hold the transaction card. When clamped in the slot 1002, the transaction card 112 is substantially flush with the front and back of the card 1000. In FIG. 10B, the card 1020 includes a pocket 1022 for holding the transaction card 112 adjacent at least one surface of the card 1020. In some implementations, cards 1000 and 1020 may include a magnetic stripe for performing contact transactions.

Various embodiments of the present invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. A micro-secure digital (microSD) payment card, comprising:

a microampere-all-digital interface connected to a microampere-all-digital slot of a mobile host device;

a communication module that wirelessly receives and transmits RF signals from and to a retail terminal;

a secure memory storing user credentials and a payment application for performing a financial transaction with the retail terminal, the user credentials and the payment application associated with a financial institution, the user credentials associated with one of a credit card account, a debit account, a gift account, or a prepaid account;

a user interface module that presents and receives information through a GUI of the mobile host device; and

a processing module to execute the payment application using the user credentials in response to at least a transaction request received by the communication module and to send at least one transaction response to the retail terminal based at least in part on the executed payment application, wherein the micro-security all-digital payment card is wirelessly personalized with the user credentials and the payment application associated with the financial institution after issuance.

2. The micro-secure all-digital payment card of claim 1, wherein the processing module comprises:

a security module to generate the transaction response based at least in part on the user credentials and the payment application; and

an operating system having a runtime environment that executes the payment application independent of the mobile host device.

3. The microampere all-digital payment card of claim 1, wherein the communication module comprises a protocol conversion module, an antenna tuning circuit, a power circuit, and a micro-antenna tuned to exchange wireless data with the retail terminal.

4. The micro-secure all-digital payment card of claim 1, wherein the user interface module presents information associated with the requested transaction through a GUI of the mobile host device.

5. The micro-secure all-digital payment card of claim 4, further comprising a locally-executing web server that generates the presented information based at least in part on at least one of real-time content during the transaction, offline content stored locally, or online content associated with the financial institution.

6. The micro-secure all-digital payment card of claim 4, wherein the user interface module further presents a request for a user identification through the GUI of the mobile host device, the user identification including at least one of a Personal Identification Number (PIN), a user ID and password, or a biometric signature, the processing module further verifying the submitted user identification with the user identification stored locally to the secure memory prior to performing the requested transaction.

7. The micro-secure all-digital payment card of claim 6, wherein the processing module further comprises disabling the communication module at least in response to a number of PIN entry events exceeding a threshold.

8. The micro-secure all-digital payment card of claim 1, wherein the communication module selectively switches the RF antenna between the activated state and the deactivated state in response to at least one event.

9. The micro-secure all-digital payment card of claim 8, wherein switching the RF antenna comprises selection through a GUI of the mobile host device.

10. The microampere all-digital payment card of claim 1, wherein the RF signal comprises at least one of a contactless signal, a proximity signal, a Near Field Communication (NFC) signal, a bluetooth signal, an ultra-wideband (UWB) signal, or a Radio Frequency Identification (RFID) signal.

11. The micro-secure all-digital payment card of claim 1, wherein the communication module further comprises a protocol conversion module that converts signals between wireless protocols compatible with the retail terminal and an internal transaction application.

12. The micro-secure all-digital payment card of claim 1, further comprising a cryptographic module that decrypts received signals prior to processing by the payment application and encrypts at least a portion of the transaction response prior to wireless transmission.

13. The micro-secure all-digital payment card of claim 1, further comprising an authentication module that authenticates at least one of a network of the mobile host device, or a user.

14. The micro-secure all-digital payment card of claim 13, wherein the authentication module further deactivates an antenna in response to at least one of a failure to authenticate the network of the mobile host device, or the user.

15. The micro-secure all-digital payment card of claim 1, wherein the micro-secure all-digital payment card is initialized at least in response to being inserted into a micro-secure all-digital slot of the mobile host device.

16. The micro-secure all-digital payment card of claim 1, further comprising a boot module that performs one or more authentication processes in response to at least being inserted into a micro-secure all-digital slot of the mobile host device.

17. The micro-secure all-digital payment card of claim 16, wherein the one or more authentication processes authenticate at least one of a network, a mobile host device, or a user.

18. The micro-secure all-digital payment card of claim 1, further comprising an activation module that activates the micro-secure all-digital payment card and sends a request to activate an associated user account to the financial institution in response to at least a user request or initial insertion into the mobile host device.

19. The micro-secure all-digital payment card of claim 18, wherein the micro-secure all-digital payment card is activated based at least in part on a user manually entering an activation code through a GUI of the mobile host device.

20. The micro-secure all-digital payment card of claim 1, further comprising an Application Program Interface (API) that wirelessly communicates with a financial institution using cellular radio technology of the mobile host device.

21. The micro-secure all-digital payment card of claim 1, wherein the micro-secure all-digital payment card performs the requested transaction independent of loading a driver to the mobile host device.

22. The micro-secure all-digital payment card of claim 1, wherein the micro-secure all-digital payment card emulates a contactless payment card when in communication with the retail terminal.

23. The micro-secure all-digital payment card of claim 1, further comprising a power module that receives power from RF signals received by the mobile host device and the communication module and automatically switches to a passive mode in response to at least a power loss from the mobile host device.

24. The micro-secure all-digital payment card of claim 1, wherein at least a business associated with the financial institution uploads personalization data prior to activation, wherein the personalization data comprises the user credentials; the payment application; and at least one of an operation flag, a rule table, or a user interface.

25. The micro-secure all-digital payment card of claim 24, wherein the communication module is further operable to update the personalization data after activation in response to at least one of a wireless signal comprising a secure update instruction or a wired signal through a client connected to the micro-secure all-digital payment card.

26. The micro-secure all-digital payment card of claim 1, wherein the processing module is further operable to send a notification to the financial institution using the mobile host device in response to an activity that violates one or more fraud control rules.

27. The micro-secure all-digital payment card of claim 1, wherein the processing module is further operable to populate a web page with user credentials to perform an internet transaction in response to at least a request from a client connected to the micro-secure all-digital payment card.

28. The micro-secure all-digital payment card of claim 1, wherein the micro-secure all-digital payment card maintains attributes of the mobile host device.

29. The micro-security all-digital payment card of claim 28, wherein the attributes comprise at least one of size, accessibility to peripheral devices, charging, battery life, signal strength, access to a GUI, connectivity to a wireless network, or interface capabilities with a client.

30. The micro-secure all-digital payment card of claim 28, wherein the attribute does not invalidate an authority's certificate or a warranty of the mobile host device.

31. A microampere digital card comprising:

a secure memory storing user credentials and a payment application for performing a financial transaction with the retail terminal, the user credentials and the payment application associated with a financial institution, the user credentials associated with one of a credit card account, a debit account, a gift account, or a prepaid account, wherein the card is wirelessly personalized after issuance by the user credentials and the payment application associated with the financial institution;

a security module that identifies the payment application and user credentials in response to at least a transaction request received by the communication module and encrypts a transaction response before sending to the retail terminal; and

an operating system having a runtime environment that executes the payment application to generate the transaction response independent of the mobile host device.

32. The microampere digital card of claim 31, further comprising a user interface module that presents and receives information through a GUI of the mobile host device.