WO2022074416A1

WO2022074416A1 - Cards, devices, systems, and methods for advanced payment functionality selection

Info

Publication number: WO2022074416A1
Application number: PCT/IB2020/000934
Authority: WO
Inventors: Jeffrey D. Mullen
Original assignee: Dynamics Inc
Current assignee: Dynamics Inc
Priority date: 2020-10-06
Filing date: 2020-10-06
Publication date: 2022-04-14
Anticipated expiration: 2023-04-06

Abstract

A wallet card or other device includes three buttons, a PCB antenna for connection to all cellular bands including low band, mid band and high band, dual pressure sensors operable to determine velocity and/or as an independent trigger, a cellular chip whose encryption/decryption key between a payment network and the cellular chip is dynamically changeable for security, and a dynamic magnetic communications device operable to communicate data using a magnetic data waveform with amplitude adjusted by the device.

Description

CARDS, DEVICES, SYSTEMS, AND METHODS

FOR ADVANCED PAYMENT FUNCTIONALITY SELECTION

Cross-Reference To Related Application

[0001] This application claims the benefit of U.S. Provisional Patent Application Nos. 62/911,357, titled "ADVANCED SECURE PAYMENT DEVICE," filed October 6, 2019 (Attorney Docket No. D/177PROV), 62/927,664, titled "SCALABLE LOYALTY PROCESSING APPARATUSES AND SYSTEMS AND METHODS OF HIGH VOLUME LOYALTY DATA PROCESSING," filed October 29, 2019 (Attorney Docket No. D/178PROV), 62/934,343, titled "SWITCH CARD OR DEVICE AND SYSTEM WITH MULTIPLE SECURE ELEMENTS," filed November 12, 2019 (Attorney Docket No. D/179PROV), 62/967,539, titled "SYSTEMS AND METHODS FOR TRANSACTION DETECTION AND TRANSACTION INDICATOR MECHANISMS FOR CARDS AND DEVICES," filed January 29, 2020 (Attorney Docket No. D/180PROV), and 62/987,276, titled "MULTI-FUNCTION APPLET POWERED CARDS AND OTHER DEVICES," filed March 9, 2020 (Attorney Docket No. D/181PROV), 62/987,279, titled "MULTI- FUNCTION APPLET POWERED CARDS AND OTHER DEVICES," filed March 9, 2020 (Attorney Docket No. D/181PROV), and 63/048,073, titled "PAYMENT DEVICE APPLETS WITH PRE- STORED MESSAGES AND TRIGGERABLE LOGIC," filed July 3, 2020 (Attorney Docket No. D/190PROV), each of which is hereby incorporated by reference herein in its entirety. This application also claims priority of United States Non-Provisional Patent Application Nos. Background of the Invention

[0002] This invention relates to magnetic cards, devices and payment systems.

Summary of the Invention

[0003] Systems and methods are provided for allowing a user to select an additional service to be performed in addition to the payment of goods with a payment card and/or other device (e.g., a mobile telephonic device, a tablet computer device, and/or other electronic device). A "card" may be used to denote powered cards, non-powered cards and other devices (e.g., powered or non-powered electronic devices, for example, computing devices).

[0004] A card may include one or more buttons. A user may associate an additional service to a button of a card at any time. At the time of purchase, information indicative of the button the user selected may be passed to a point-of-sale system with a user's payment information. Such data may be, for example, communicated through a merchant acquirer's network to a processing facility.

[0005] The processing facility may, for example, authorize a payment transaction and forward the information indicative of the button a user selected and the identity of a user to a remote facility. Such a remote facility may, for example, forward at least some of such information, as well as additional information, to a third party service provider such that the third party service provider enacts the additional feature desired by the user.

[0006] Such an additional feature may include, for example, earning and/or using a coupon provided by a coupon provider, the addition of value to a coupon by a retailer acting as an application provider, earning of a random reward from a manufacturer, and/or the like.

[0007] Selection of a feature may be provided, for example, by a Graphical User Interface (GUI) provided on a computing device (e.g., a mobile telephonic device) as a software and/or hardware application for that device, and/or via the internet or an intranet through a web browser. Such a selection may be provided with a non- powered card such that a single feature may be associated with a non-powered card for a period of time. Such a selection may be associated to an option (e.g., a button) on a powered card or other device (e.g., a mobile telephonic device) such that the user may associate different features with different options (e.g., different buttons).

[0008] Accordingly, for example, a user may receive a card (e.g., a powered card, non-powered card and/or other device) in the mail and use his/her web browser to associate different additional features to different buttons. The user may then utilize the card in a store and press a button in order to select that feature. A card may download information (e.g., via a wireless communication such as a light and/or electromagnetic communication) such that the card, and/or other device, displays information next to an option indicative of the feature (e.g., "Redeem LivingSocial Voucher," "Facebook Like"). Alternatively, no download may be provided and no additional information may be displayed such that a user's card, and/or other device, includes a generic descriptor (e.g., "credit" and "feature," or "feature 1" and "feature 2," or "debit" and "feature 1" and "feature [0009] A remote facility may also receive additional information than just a user identifier and information indicative of the option selected by a user (or that the user made a payment). Such additional information may be, for example, the type of merchant (e.g., a retail merchant or a gas merchant), the location of a merchant (e.g., the zip code of a merchant), the type of transaction (e.g., online or in-store purchase), the name of the merchant (e.g., "Amazon.com," or "Walmart"), the amount of the transaction (e.g., $10.25), and any other information. Such a remote facility may forward such information to a third party service provider in addition to information generated by the remote facility (e.g., a second user identifier such that different identifiers are used with the facility sending payment information and the third party service provider).

[0010] A feature/payment method ecosystem may be provided in which a development kit is available for third parties to develop applications for payment cards or other devices. A GUI may be provided where a user can select different third party applications to be associated with one or more user payment methods. The third party applications may be approved by an administrator and/or an approval signature flow before being accessible by a GUI. Different categories of third party applications may be provided on the GUI (e.g., a coupon category, a check-in category, a games category, a financial management tools category). The development kit may provide the ability for a third party service provider to, for example, receive user identification numbers and other information, (e.g., merchant name and location) and provide particular information (e.g., within a period of time) to a remote facility. [0011] Information received from a third party service provider may include, for example, information indicative that the user was properly identified and a service was performed (e.g., "check-in completed," "information added to financial management service."). Such information may be provided back to an issuing bank, processor, or other service provider such that the information may be displayed on a user's billing statement. Additional information may also be provided that may change the way a transaction is authorized or settled.

[0012] Additional information received from a third party may be utilized to change the way a transaction is authorized or settled. For example, a third party may provide a user with the ability to pre-purchase a voucher to a particular store (e.g., a particular barber in a particular zip code). A user may associate this third party service to a button on the user's card. For example, a user may purchase a service at a barber multiple times during a year on the user's credit account. The user may, at one such purchase, press the button associated with the desire to use the third party service and redeem a voucher the user already purchased or acquired. Information indicative of the user's desire to utilize such a service may be communicated to a point- of-sale terminal via a communications device located on the card (e.g., a dynamic magnetic stripe communications device, an RFID antenna, an exposed IC chip (e.g., an EMV chip, or any other communications device). The transaction may be authorized using the user's payment account if, for example, the user has enough funds associated with that account (e.g., a credit or debit account). [0013] The third party service provider may then determine the user had a pre-paid voucher for the transaction and may return to the card issuer, processor, and/or other party information indicative that the user's bill is to be adjusted by the amount of the voucher. Before, or after, settlement occurs a user's bill may show a statement credit in the amount of the voucher. A remote facility may perform such a data exchange as well as any associated value exchange. For example, the remote facility may, for a fee (e.g., a percentage of a transaction or a fixed fee), provide value from the third party service provider to the card issuer or processor (e.g., via an ACH or other type of monetary transaction). [0014] Alternatively, for example, the remote facility may provide the desired value to the card issuer, processor, and/or other party and demand the associated value be paid to the remote facility by the third party service provider within a period of time (e.g., three days). Information provided by a third party service provider to a remote facility may include an identifier indicative of the third party service provider, an identifier indicative of the user, an identifier indicative of the type of service provided by the third party service provider, an identifier indicative of the transaction with which further action by the third party service provider is desired, an amount of a post-statement credit that is to be applied for a particular transaction, and amount of a post-settlement credit that is to be applied for a particular transaction, an amount of a pre-settlement credit that is to be applied for a particular transaction, an amount of a credit that is to be applied during an authorization, an additional fee to be added to a statement for an additional service (e.g., a fee-based financial management tool service), and any other information desired by the third party service provider, processor, card issuer, remote facility, device provider, and/or any other entity (e.g., a card network).

[0015] Information indicative of a button press, and/or use of a card, that triggers a feature may be provided in a payment message utilized at authorization or at settlement. Furthermore, the service provider may return information in a period of time that permits actions to be performed pre-authorization and/or pre- settlement.

[0016] The payment actions may be determined, for example, via a user interaction with the card. Particularly, for example, a user may press a button on the card, from a group of buttons, the button being associated with the third party feature. The third party feature may be unique from the features provided to the user via the third party's non-payment card or device services. Accordingly, a user may obtain the benefit of the whimsical and festive nature of a unique feature every time the user makes a payment.

[0017] Information indicative of feature selection may be provided, for example, via an output device operable to be read by a card reader. For example, the feature selection may be communicated by a dynamic magnetic stripe communications device, an RFID antenna, an exposed IC chip, or any other type of output device. For online purchases, for example, a display may be provided on the card and a user selection may cause a particular number (e.g., a particular code) to be displayed on the card. Such a code may be entered into a text box on a website at checkout and may be representative of the user's desired feature. Accordingly, the feature may be communicated to a remote server such that the feature may be performed in the third party service on behalf of the user. The code may additionally provide the benefits of a security code and may be entered with a payment card number (e.g., a credit or debit card number) at online or in-store checkout. If a code is not representative of a feature, for example, a default feature may be provided.

[0018] Rewards may be awarded based on the amount of a purchase. Such rewards may be associated with a third party service or a card issuer, card provider, or other entity. For example, a coupon may be awarded by an application provider at every purchase instead of a card issuer providing an amount of points, miles, or cashback to a user. Alternatively, for example, a user may earn both rewards from a card issuer as well as rewards from a third party service provider. A user may select, via, for example, physical buttons on the card or virtual buttons on a capacitive-sensitive display of a mobile telephonic device, the type of feature the user desires. Multiple features may be provided from a particular third party service provider. For example, a coupon provider may provide a feature associated with a coupon and another feature associated with another coupon.

[0019] A card may include a dynamic magnetic communications device. Such a dynamic magnetic communications device may take the form of a magnetic encoder and/or a magnetic emulator. A magnetic encoder may change the information located on a magnetic medium such that a magnetic stripe reader may read changed magnetic information from the magnetic medium. A magnetic emulator may generate electromagnetic fields that directly communicate data to a magnetic stripe reader. Such a magnetic emulator may communicate data serially to a read-head of the magnetic stripe reader. [0020] All, or substantially all, of the front as well as the back of a card may be a display (e.g., bi-stable, non bi-stable, LCD, LED, or electrochromic display). Electrodes of a display may be coupled to one or more capacitive touch sensors such that a display may be provided as a touch-screen display. Any type of touch- screen display may be utilized. Such touch-screen displays may be operable of determining multiple points of touch. A barcode may be displayed across all, or substantially all, of a surface of a card. In doing so, computer vision equipment such as barcode readers may be less susceptible to errors in reading a displayed barcode.

[0021] A card may include a number of output devices to output dynamic information. For example, a card may include one or more RFIDs and/or IC chips to communicate to one or more RFID readers or IC chip readers, respectively. According to some example embodiments, a card may include three or more different types of output devices. A card may include devices to receive information. For example, an RFID and IC chip may both receive information and communicate information to an RFID and IC chip reader, respectively.

[0022] A device for receiving wireless information signals may be provided. A light sensing device and/or sound sensing device may be utilized to receive information wirelessly. A card may include a central processor that communicates data through one or more output devices simultaneously (e.g., an RFID, IC chip, and a dynamic magnetic stripe communications device). The central processor may receive information from one or more input devices simultaneously (e.g., an RFID, IC chip, dynamic magnetic stripe devices, light sensing device, and a sound sensing device). A processor may be coupled to surface contacts such that the processor may perform the processing capabilities of, for example, an EMV chip. The processor may be laminated over and not exposed such that such a processor is not exposed on the surface of the card.

[0023] A card may be provided with a button in which the activation of the button causes a code to be communicated through a dynamic magnetic stripe communications device (e.g., the subsequent time a read- head detector on the card detects a read-head). The code may be indicative of, for example, a feature (e.g., a payment feature). The code may be received by the card via manual input (e.g., onto buttons of the card) or via a wireless transmission (e.g., via light, electromagnetic communications, sound, or other wireless signals). A code may be communicated from a webpage (e.g., via light and/or sound) to a card. A card may include a display such that a received code may be visually displayed to a user. In doing so, the user may be provided with a way to select, and use, the code via both an in-store setting (e.g., via a magnetic stripe reader) or an online setting (e.g., by reading the code from a display and entering the code into a text box on a checkout page of an online purchase transaction).

[0024] A remote server, such as a payment authorization server, may receive the code and may process a payment differently based on the code received. For example, a code may be a security code to authorize a purchase transaction. A code may provide a payment feature such that a purchase may be made with points, debit, credit, installment payments, and/or deferred payments via a single payment account number (e.g., a credit card number) to identify a user and a payment feature code to select the type of payment a user desires to utilize.

[0025] A dynamic magnetic stripe communications device may include a magnetic emulator that comprises an inductor (e.g., a coil). Current may be provided through this coil to create an electromagnetic field operable to communicate with the read-head of a magnetic stripe reader. The drive circuit may vary the amount of current travelling through the coil such that a track of magnetic stripe data may be communicated to a read-head of a magnetic stripe reader. A switch (e.g., a transistor) may be provided to enable or disable the flow of current according to, for example, a frequency/double-frequency (F2F) encoding algorithm. In doing so, bits of data may be communicated.

[0026] Electronics may be embedded between two layers of a polymer (e.g., a PVC or non-PVC polymer). One or more liquid polymers may be provided between these two layers. The liquid polymer(s) may, for example, be hardened via a reaction between the polymers (or other material), temperature, and/or via light (e.g., an ultraviolet or blue spectrum light) such that the electronics become embedded between the two layers of the polymer and a card is formed.

[0027] A payment card or other device may receive information indicative of a feature desired to be added by a user. The payment card may communicate information indicative of the feature with payment card data associated with the card or a user selection. The payment data and feature information may be routed, for example, to an authorization server. The authorization server may authorize payment and, based on the authorized payment, communicate the feature information to a remote server. The remote server may utilize this remote information to impact a third party service. The feature information may, for example, be routed before the payment card data reaches an authorization server.

[0028] At merchant settlement, charge backs for a purchase associated with a reward (e.g., a coupon) may cause the feature to be reversed or a different feature to be implemented (e.g., a removal of rewards earned at authorization). According to some example embodiments, the feature may be implemented at settlement upon confirmation that, for example, no chargeback was associated with the payment transaction.

[0029] A graphical user interface (GUI) may be provided to allow users to display one or more application managers and one or more application provider interfaces. The GUI may be rendered onto a display of a card (e.g., a powered card, a mobile telephonic device, an electronic tablet, a laptop computer, or a desktop computer) and may allow a user to configure features that are desired to be added by the user.

[0030] A user may, for example, associate a card with one or more third party service features using the application manager. Such an application manager may be an interface to an ecosystem of applications and payment methods, where users within the ecosystem may manage which application(s) may be associated with a particular payment method (e.g., payment method card). A user may alter such associations at any time. Prior to associating one or more applications to a particular payment method, the payment method may be associated with one or more default applications that may be later modified by the user.

[0031] A GUI may be provided on an electronic device to administer one or more third party applications that facilitate the provision of coupons and/or the addition of value to coupons. The coupons and/or additional value may be earned by a user upon completion of a performance metric. A coupon may be selected by a user from every coupon made available by an application and/or feature provider, the coupon may be automatically determined and/or a coupon may selected by a user from a number of hidden coupons (e.g., via a virtual scratch-off). For example, an application provider may be a coupon provider that distributes coupons from a variety of retailers, a retailer and/or a collection of retailers. A user of a payment method, for example a powered card, may earn a coupon and/or add value to a coupon each time the user spends a target amount of money using the powered card. Additionally and/or alternatively, a user may receive a reward randomly from a collection of rewards including coupons, virtual items and tangible items, and/or select a blank reward from among multiple blank rewards to reveal a coupon.

[0032] A performance metric may include, for example, a purchase with a card (e.g., a physical and/or virtual payment method card), a sequence of purchases (e.g., ten purchases), a total amount spent, and/or other metrics related to various purchasing and/or non-purchasing transactional events.

[0033] A reward may scale based on an associated performance metric. The greater the burden placed on a user by a performance metric, the greater the reward may be. For example, a coupon may be earned from all coupons provided by a coupon provider each time a user makes purchases meeting or exceeding a specific dollar amount. For a dollar amount exceeding the specific dollar amount, a user may instead receive multiple coupons and/or add additional value to a coupon.

[0034] According to some example embodiments, a computing device may receive a first message including a coupon identifier of a multistage coupon, obtain a monetary value of a current stage of the multistage coupon based on the coupon identifier, and communicate a second message based on the first message, the second message indicating the monetary value of the current stage of the multistage coupon. The multistage coupon may not be associated with a user. Whether a condition to awarding the monetary value is met may be determined. The first message may include at least a portion of purchase transaction data, and the determination that the condition is met may be based on the at least a portion of the purchase transaction data. The current stage and a stage threshold may be obtained, and a determination made as to whether the current stage is equal to or exceeds the threshold. The second message may include an indication of card eligibility upon determining that the current stage is equal to or exceeds the threshold. According to some example embodiments, a point of sale

(POS) terminal may receive a barcode including a payment routing identity and communicate the barcode and data associated with a purchase transaction based on the routing identity. The POS terminal may receive a second barcode associated with at least one of an installment, a loyalty account, a discount and a request to pay for all or a portion of a purchase with points.

[0035] A wallet card device may include three buttons, a printed circuit board (PCB) antenna connectable to any cellular band, dual pressure sensors usable to determine speed of the wallet card device, a cellular chip, and a dynamic magnetic communications device usable to communicate waveforms at more than one amplitude, the wallet card device usable to dynamically change an encryption/decryption key between a payment network and the cellular chip is operable to be dynamically changed.

Systems and methods are provided for allowing a user to select an additional service to be performed in addition to the payment of goods with a payment card and/or other device (e.g., a mobile telephonic device, a tablet computer device, and/or other electronic device). A "card" may be used to denote powered cards, non-powered cards and other devices (e.g., powered or non-powered electronic devices, for example, computing devices). [0036] A card may include one or more buttons. A user may associate an additional service to a button of a card at any time. At the time of purchase, information indicative of the button the user selected may be passed to a point-of-sale system with a user's payment information. Such data may be, for example, communicated through a merchant acquirer's network to a processing facility.

[0037] The processing facility may, for example, authorize a payment transaction and forward the information indicative of the button a user selected and the identity of a user to a remote facility. Such a remote facility may, for example, forward at least some of such information, as well as additional information, to a third party service provider such that the third party service provider enacts the additional feature desired by the user.

[0038] Such an additional feature may include, for example, earning and/or using a coupon provided by a coupon provider, the addition of value to a coupon by a retailer acting as an application provider, earning of a random reward from a manufacturer, and/or the like.

[0039] Selection of a feature may be provided, for example, by a Graphical User Interface (GUI) provided on a computing device (e.g., a mobile telephonic device) as a software and/or hardware application for that device, and/or via the internet or an intranet through a web browser. Such a selection may be provided with a non- powered card such that a single feature may be associated with a non-powered card for a period of time. Such a selection may be associated to an option (e.g., a button) on a powered card or other device (e.g., a mobile telephonic device) such that the user may associate different features with different options (e.g., different buttons).

[0040] Accordingly, for example, a user may receive a card (e.g., a powered card, non-powered card and/or other device) in the mail and use his/her web browser to associate different additional features to different buttons. The user may then utilize the card in a store and press a button in order to select that feature. A card may download information (e.g., via a wireless communication such as a light and/or electromagnetic communication) such that the card, and/or other device, displays information next to an option indicative of the feature (e.g., "Redeem LivingSocial Voucher," "Facebook Like"). Alternatively, no download may be provided and no additional information may be displayed such that a user's card, and/or other device, includes a generic descriptor (e.g., "credit" and "feature," or "feature 1" and "feature 2," or "debit" and "feature 1" and "feature 2").

[0041] A remote facility may also receive additional information than just a user identifier and information indicative of the option selected by a user (or that the user made a payment). Such additional information may be, for example, the type of merchant (e.g., a retail merchant or a gas merchant), the location of a merchant (e.g., the zip code of a merchant), the type of transaction (e.g., online or in-store purchase), the name of the merchant (e.g., "Amazon.com," or "Walmart"), the amount of the transaction (e.g., $10.25), and any other information. Such a remote facility may forward such information to a third party service provider in addition to information generated by the remote facility (e.g., a second user identifier such that different identifiers are used with the facility sending payment information and the third party service provider).

[0042] A feature/payment method ecosystem may be provided in which a development kit is available for third parties to develop applications for payment cards or other devices. A GUI may be provided where a user can select different third party applications to be associated with one or more user payment methods. The third party applications may be approved by an administrator and/or an approval signature flow before being accessible by a GUI. Different categories of third party applications may be provided on the GUI (e.g., a coupon category, a check-in category, a games category, a financial management tools category). The development kit may provide the ability for a third party service provider to, for example, receive user identification numbers and other information, (e.g., merchant name and location) and provide particular information (e.g., within a period of time) to a remote facility.

[0043] Information received from a third party service provider may include, for example, information indicative that the user was properly identified and a service was performed (e.g., "check-in completed," "information added to financial management service."). Such information may be provided back to an issuing bank, processor, or other service provider such that the information may be displayed on a user's billing statement. Additional information may also be provided that may change the way a transaction is authorized or settled.

[0044] Additional information received from a third party may be utilized to change the way a transaction is authorized or settled. For example, a third party may provide a user with the ability to pre-purchase a voucher to a particular store (e.g., a particular barber in a particular zip code). A user may associate this third party service to a button on the user's card. For example, a user may purchase a service at a barber multiple times during a year on the user's credit account. The user may, at one such purchase, press the button associated with the desire to use the third party service and redeem a voucher the user already purchased or acquired. Information indicative of the user's desire to utilize such a service may be communicated to a point- of-sale terminal via a communications device located on the card (e.g., a dynamic magnetic stripe communications device, an RFID antenna, an exposed IC chip (e.g., an EMV chip, or any other communications device). The transaction may be authorized using the user's payment account if, for example, the user has enough funds associated with that account (e.g., a credit or debit account).

[0045] The third party service provider may then determine the user had a pre-paid voucher for the transaction and may return to the card issuer, processor, and/or other party information indicative that the user's bill is to be adjusted by the amount of the voucher. Before, or after, settlement occurs a user's bill may show a statement credit in the amount of the voucher. A remote facility may perform such a data exchange as well as any associated value exchange. For example, the remote facility may, for a fee (e.g., a percentage of a transaction or a fixed fee), provide value from the third party service provider to the card issuer or processor (e.g., via an ACH or other type of monetary transaction). [0046] Alternatively, for example, the remote facility may provide the desired value to the card issuer, processor, and/or other party and demand the associated value be paid to the remote facility by the third party service provider within a period of time (e.g., three days). Information provided by a third party service provider to a remote facility may include an identifier indicative of the third party service provider, an identifier indicative of the user, an identifier indicative of the type of service provided by the third party service provider, an identifier indicative of the transaction with which further action by the third party service provider is desired, an amount of a post-statement credit that is to be applied for a particular transaction, and amount of a post-settlement credit that is to be applied for a particular transaction, an amount of a pre-settlement credit that is to be applied for a particular transaction, an amount of a credit that is to be applied during an authorization, an additional fee to be added to a statement for an additional service (e.g., a fee-based financial management tool service), and any other information desired by the third party service provider, processor, card issuer, remote facility, device provider, and/or any other entity (e.g., a card network).

[0047] Information indicative of a button press, and/or use of a card, that triggers a feature may be provided in a payment message utilized at authorization or at settlement. Furthermore, the service provider may return information in a period of time that permits actions to be performed pre-authorization and/or pre- settlement.

[0048] The payment actions may be determined, for example, via a user interaction with the card. Particularly, for example, a user may press a button on the card, from a group of buttons, the button being associated with the third party feature. The third party feature may be unique from the features provided to the user via the third party's non-payment card or device services. Accordingly, a user may obtain the benefit of the whimsical and festive nature of a unique feature every time the user makes a payment.

[0049] Information indicative of feature selection may be provided, for example, via an output device operable to be read by a card reader. For example, the feature selection may be communicated by a dynamic magnetic stripe communications device, an RFID antenna, an exposed IC chip, or any other type of output device. For online purchases, for example, a display may be provided on the card and a user selection may cause a particular number (e.g., a particular code) to be displayed on the card. Such a code may be entered into a text box on a website at checkout and may be representative of the user's desired feature. Accordingly, the feature may be communicated to a remote server such that the feature may be performed in the third party service on behalf of the user. The code may additionally provide the benefits of a security code and may be entered with a payment card number (e.g., a credit or debit card number) at online or in-store checkout. If a code is not representative of a feature, for example, a default feature may be provided.

[0050] Rewards may be awarded based on the amount of a purchase. Such rewards may be associated with a third party service or a card issuer, card provider, or other entity. For example, a coupon may be awarded by an application provider at every purchase instead of a card issuer providing an amount of points, miles, or cashback to a user. Alternatively, for example, a user may earn both rewards from a card issuer as well as rewards from a third party service provider. A user may select, via, for example, physical buttons on the card or virtual buttons on a capacitive-sensitive display of a mobile telephonic device, the type of feature the user desires. Multiple features may be provided from a particular third party service provider. For example, a coupon provider may provide a feature associated with a coupon and another feature associated with another coupon.

[0051] A card may include a dynamic magnetic communications device. Such a dynamic magnetic communications device may take the form of a magnetic encoder and/or a magnetic emulator. A magnetic encoder may change the information located on a magnetic medium such that a magnetic stripe reader may read changed magnetic information from the magnetic medium. A magnetic emulator may generate electromagnetic fields that directly communicate data to a magnetic stripe reader. Such a magnetic emulator may communicate data serially to a read-head of the magnetic stripe reader. [0052] All, or substantially all, of the front as well as the back of a card may be a display (e.g., bi-stable, non bi-stable, LCD, LED, or electrochromic display). Electrodes of a display may be coupled to one or more capacitive touch sensors such that a display may be provided as a touch-screen display. Any type of touch- screen display may be utilized. Such touch-screen displays may be operable of determining multiple points of touch. A barcode may be displayed across all, or substantially all, of a surface of a card. In doing so, computer vision equipment such as barcode readers may be less susceptible to errors in reading a displayed barcode.

[0053] A card may include a number of output devices to output dynamic information. For example, a card may include one or more RFIDs and/or IC chips to communicate to one or more RFID readers or IC chip readers, respectively. According to some example embodiments, a card may include three or more different types of output devices. A card may include devices to receive information. For example, an RFID and IC chip may both receive information and communicate information to an RFID and IC chip reader, respectively. [0054] A device for receiving wireless information signals may be provided. A light sensing device and/or sound sensing device may be utilized to receive information wirelessly. A card may include a central processor that communicates data through one or more output devices simultaneously (e.g., an RFID, IC chip, and a dynamic magnetic stripe communications device). The central processor may receive information from one or more input devices simultaneously (e.g., an RFID, IC chip, dynamic magnetic stripe devices, light sensing device, and a sound sensing device). A processor may be coupled to surface contacts such that the processor may perform the processing capabilities of, for example, an EMV chip. The processor may be laminated over and not exposed such that such a processor is not exposed on the surface of the card.

[0055] A card may be provided with a button in which the activation of the button causes a code to be communicated through a dynamic magnetic stripe communications device (e.g., the subsequent time a read- head detector on the card detects a read-head). The code may be indicative of, for example, a feature (e.g., a payment feature). The code may be received by the card via manual input (e.g., onto buttons of the card) or via a wireless transmission (e.g., via light, electromagnetic communications, sound, or other wireless signals). A code may be communicated from a webpage (e.g., via light and/or sound) to a card. A card may include a display such that a received code may be visually displayed to a user. In doing so, the user may be provided with a way to select, and use, the code via both an in-store setting (e.g., via a magnetic stripe reader) or an online setting (e.g., by reading the code from a display and entering the code into a text box on a checkout page of an online purchase transaction).

[0056] A remote server, such as a payment authorization server, may receive the code and may process a payment differently based on the code received. For example, a code may be a security code to authorize a purchase transaction. A code may provide a payment feature such that a purchase may be made with points, debit, credit, installment payments, and/or deferred payments via a single payment account number (e.g., a credit card number) to identify a user and a payment feature code to select the type of payment a user desires to utilize.

[0057] A dynamic magnetic stripe communications device may include a magnetic emulator that comprises an inductor (e.g., a coil). Current may be provided through this coil to create an electromagnetic field operable to communicate with the read-head of a magnetic stripe reader. The drive circuit may vary the amount of current travelling through the coil such that a track of magnetic stripe data may be communicated to a read-head of a magnetic stripe reader. A switch (e.g., a transistor) may be provided to enable or disable the flow of current according to, for example, a frequency/double-frequency (F2F) encoding algorithm. In doing so, bits of data may be communicated.

[0058] Electronics may be embedded between two layers of a polymer (e.g., a PVC or non-PVC polymer). One or more liquid polymers may be provided between these two layers. The liquid polymer(s) may, for example, be hardened via a reaction between the polymers (or other material), temperature, and/or via light (e.g., an ultraviolet or blue spectrum light) such that the electronics become embedded between the two layers of the polymer and a card is formed.

[0059] A payment card or other device may receive information indicative of a feature desired to be added by a user. The payment card may communicate information indicative of the feature with payment card data associated with the card or a user selection. The payment data and feature information may be routed, for example, to an authorization server. The authorization server may authorize payment and, based on the authorized payment, communicate the feature information to a remote server. The remote server may utilize this remote information to impact a third party service. The feature information may, for example, be routed before the payment card data reaches an authorization server.

[0060] At merchant settlement, charge backs for a purchase associated with a reward (e.g., a coupon) may cause the feature to be reversed or a different feature to be implemented (e.g., a removal of rewards earned at authorization). According to some example embodiments, the feature may be implemented at settlement upon confirmation that, for example, no chargeback was associated with the payment transaction.

[0061] A graphical user interface (GUI) may be provided to allow users to display one or more application managers and one or more application provider interfaces. The GUI may be rendered onto a display of a card (e.g., a powered card, a mobile telephonic device, an electronic tablet, a laptop computer, or a desktop computer) and may allow a user to configure features that are desired to be added by the user.

[0062] A user may, for example, associate a card with one or more third party service features using the application manager. Such an application manager may be an interface to an ecosystem of applications and payment methods, where users within the ecosystem may manage which application(s) may be associated with a particular payment method (e.g., payment method card). A user may alter such associations at any time. Prior to associating one or more applications to a particular payment method, the payment method may be associated with one or more default applications that may be later modified by the user.

[0063] A GUI may be provided on an electronic device to administer one or more third party applications that facilitate the provision of coupons and/or the addition of value to coupons. The coupons and/or additional value may be earned by a user upon completion of a performance metric. A coupon may be selected by a user from every coupon made available by an application and/or feature provider, the coupon may be automatically determined and/or a coupon may selected by a user from a number of hidden coupons (e.g., via a virtual scratch-off). For example, an application provider may be a coupon provider that distributes coupons from a variety of retailers, a retailer and/or a collection of retailers. A user of a payment method, for example a powered card, may earn a coupon and/or add value to a coupon each time the user spends a target amount of money using the powered card. Additionally and/or alternatively, a user may receive a reward randomly from a collection of rewards including coupons, virtual items and tangible items, and/or select a blank reward from among multiple blank rewards to reveal a coupon.

[0064] A performance metric may include, for example, a purchase with a card (e.g., a physical and/or virtual payment method card), a sequence of purchases (e.g., ten purchases), a total amount spent, and/or other metrics related to various purchasing and/or non-purchasing transactional events.

[0065] A reward may scale based on an associated performance metric. The greater the burden placed on a user by a performance metric, the greater the reward may be. For example, a coupon may be earned from all coupons provided by a coupon provider each time a user makes purchases meeting or exceeding a specific dollar amount. For a dollar amount exceeding the specific dollar amount, a user may instead receive multiple coupons and/or add additional value to a coupon.

[0066] According to some example embodiments, a computing device may receive a first message including a coupon identifier of a multistage coupon, obtain a monetary value of a current stage of the multistage coupon based on the coupon identifier, and communicate a second message based on the first message, the second message indicating the monetary value of the current stage of the multistage coupon. The multistage coupon may not be associated with a user. Whether a condition to awarding the monetary value is met may be determined. The first message may include at least a portion of purchase transaction data, and the determination that the condition is met may be based on the at least a portion of the purchase transaction data. The current stage and a stage threshold may be obtained, and a determination made as to whether the current stage is equal to or exceeds the threshold. The second message may include an indication of card eligibility upon determining that the current stage is equal to or exceeds the threshold. [0067] A device may include memory for storing card information of a payment card, a display to display user identification information, a button to initialize the card, and by pressing the button information of the payment card may be displayed on the display. The memory may store information of more than one payment card and by pressing the button again, information of a different payment card may be displayed on the display. [0068] A card may include a dynamic magnetic communications device, which may take the form of a magnetic encoder or an electromagnetic generator. A magnetic encoder, for example, may be utilized to modify information that is located on a magnetic medium, such that a magnetic stripe reader may then be utilized to read the modified magnetic information from the magnetic medium. An electromagnetic generator, for example, may be provided to generate electromagnetic fields that directly communicate data to a read-head of a magnetic stripe reader. An electromagnetic generator, for example, may communicate data serially to a read-head of the magnetic stripe reader. An electromagnetic generator, for example, may communicate data in parallel to a read-head of a magnetic stripe reader. A card may include, for example, a static magnetic stripe that may be pre-programmed with magnetic information (e.g., financial account information associated with the card), which may be read by a magnetic stripe reader when the card is swiped across a read head of the magnetic stripe reader.

[0069] All, or substantially all, of the front surface, as well as the rear surface, of a card may be implemented as a display (e.g., bi-stable, non bi- stable, LCD, or electrochromic display). Electrodes of a display may be coupled to one or more touch sensors, such that a display may be sensitive to touch (e.g., using a finger or a pointing device) and may be further sensitive to a location of the touch. The display may be sensitive, for example, to objects that come within a proximity of the display without actually touching the display.

[0070] A card may include one or more light sources (e.g., light emitting diodes (LED)). One or more of such light sources may be configured according to a pattern within the card, whereby the pattern is unseen until the light sources are activated. Alternately, patterns visible on the card's surfaces (e.g., personalization indicia) may be visible, but may be highlighted when such light sources are activated. [0071] A dynamic magnetic stripe communications device may be implemented on a multiple layer board (e.g., a two-layer flexible printed circuit board). A coil for each track of information that is to be communicated by the dynamic magnetic stripe communications device may then be provided by including wire segments on each layer and interconnecting the wire segments through layer interconnections to create a coil. For example, a dynamic magnetic stripe communications device may include two coils such that two tracks of information may be communicated to two different read-heads included in a read-head housing of a magnetic stripe reader. A dynamic magnetic communications device may include, for example, three coils such that three tracks of information may be communicated to three different read-heads included in a read-head housing of a magnetic stripe reader. [0072] Input and/or output devices may be included on a card, for example, to facilitate data exchange with the card. For example, an integrated circuit (IC) may be included on a card and exposed from the surface of the card. Such a chip (e.g., an EMV chip) may communicate information to a chip reader (e.g., an EMV chip reader) and/or may receive information from the chip reader (e.g., a balance remaining on a gift card) which may then be stored in a memory of the card and used for a particular purpose (e.g., lights on the card may illuminate to indicate a balance remaining on the gift card). An RFID antenna or module may be included on a card, for example, to send and/or receive information between an RFID reader and the RFID included on the card.

[0073] One or more detectors may be provided, for example, to sense the presence of an external object, such as a person or device, which in turn, may trigger a communication sequence with the external object. Accordingly, for example, timing aspects of an information exchange between an external object and the various I/O devices implemented on a card may be determined by a processor of a card.

[0074] A sensed presence of an external object or device may include the type of object or device that is detected and, therefore, may then determine the type of communication that is to be used with the detected object or device. For example, a detected object may include a determination that the object is a read-head housing of a magnetic stripe reader. Such an identifying detection, for example, may activate a dynamic magnetic stripe communications device so that information may be communicated (e.g., electromagnetically communicated) to the read-head of the magnetic stripe reader. Alternately, a static magnetic stripe may be used to provide information to the magnetic stripe reader and a detection of the magnetic stripe reader may be used for other purposes (e.g., to illuminate portions of the card so that the card holder and others in proximity to the card holder may witness the card's reaction to the detected magnetic stripe reader).

[0075] One or more read-head detectors, for example, may be provided on a card. The one or more read-head detectors may be provided as, for example, conductive pads that may be arranged along a length of a card having a variety of shapes. A property (e.g., a capacitance magnitude) of one or more of the conductive pads may, for example, change in response to contact with and/or the proximity of an object.

[0076] A card may, for example, be swiped across a read-head of a magnetic stripe reader, such that a series of conductive pads arranged along a length of the card may be used by a processor to sequentially detect the presence of the read-head as the read-head moves in relation to the card. In doing so, for example, a series of detections (e.g., the capacitance magnitude of a series of conductive pads may increase and/or decrease) which may be indicative of a direction of a card swipe, a velocity of a card swipe and/or an acceleration of a card swipe.

[0077] A processor of the card may activate a transaction indicator (e.g., a visible or audible indicator) that is indicative of a completed transaction. For example, a processor of a card may activate one or more LEDs of one or more sets of LEDs to illuminate a feature on the card that indicates that the card has been used in a transaction. In so doing, a user may obtain the benefit of the whimsical and festive nature of a visible transaction indicator every time the user uses the card during a transaction. In addition, activation of the one or more LEDs may be indicative of an outcome of such a transaction (e.g., the number of LEDs activated may indicate a balance left on a gift card after the transaction completes). [0078] False alarm detection may be implemented to reduce occurrences of false alarms. For example, certain objects (e.g., a finger) may cause a processor of a card to detect, for example, a presence of a read- head housing of a magnetic stripe reader when, in fact, no read-head housing is present. In such instances, knowledge of, for example, a previously detected card swipe and associated direction may allow a second detection to be made, whereby a second read-head detection that is consistent with the originally detected card swipe direction may enable verification of a legitimate card swipe and, therefore, may enable a successful communication sequence with a magnetic stripe reader whose presence has been detected and verified, which may then be followed by a visible and/or an audible and/or a tactile indication that a transaction using the card has been completed.

[0079] One or more, for example, over 5 glow areas including a light material such as light guides that disperse light from light emitting diodes (LEDs). The LEDs may be face firing or side firing, to cause glow areas to emit light. Glow areas may be in the shape of logos, animals, or other thematic imagery. Glow areas may additionally or alternatively include a large number of LEDs, for example, over 100, over 150, over

200, or any number of LEDs.

[0080] According to example embodiments, a user may begin a transaction (e.g., insert a card into a reader), the card may perform a light show based on information received from a reader (e.g., CDOL - Card Risk Management Data Object List and/or PDOL - Processing Options Data Objects List, information utilized by artificial intelligence, hardware and/or software of a card or device) or issuer scripts received from a remote server (e.g., a financial institution). The light show may be tailored to a particular event, for example, 'Happy Birthday' displayed on or near the cardholder's date of birth or 'Happy New Year' and/or a fireworks display at or near the beginning of the New Year. As another example, when a transaction is performed in Germany after a transaction is performed in a different country, 'Welcome to Germany!' may be displayed.

[0081] A display may be a variety of configurations, for example, a dot matrix display of any number of LED rows and columns (e.g., 7 rows x 24 columns). One or more processors and/or controllers may be provided for the display. Fast imagery may be displayed by scanning columns, for example, faster than the eye can see and/or using fewer than all the LEDs of the display (e.g., 5, 10, 15 or 20).

[0082] Cards or other device may provide happiness and/or joy through festive displays triggered according to any events or for no reason (randomly). For example, at the beginning of a transaction a display may be turned on, and upon approval/authorization, a different image display (e.g., a waiting symbol to a thumbs-up symbol). Displays may differ based on, for example, the venue (a different display for a gas station than a purchase at the Special Olympics). Cards and other devices may provide displays taking into consideration, for example, medical information (e.g., reduced flashing for epileptic card holders). Prizes and transactions may be hidden and timely revealed - 'Double Point Monday' - half off installments on Tuesday, '5% Off Gas' on Wednesday. The card or other device may message a cardholder based on the cardholder's loyalty programs (issue related or otherwise. For example, the card or other device may inform the cardholder when points are earned for a purchase and when points are not earned. According to some example embodiments, different light shows may be provided for different accounts (e.g., debit and credit).

[0083] A glow card or other device may be a cheaper, light-brilliant alternative to other types of cards (e.g., metal) while also providing a cardholder information either through text, imagery, colors, movement speed or flashing of a displayed object, and or the like. The device may include a static or dynamic stripe, traditional stripe tracks, JIS 1 and/or JIS 2, and/or the like.

[0084] According to some example embodiments, a metal card or other device may be improved, for example, with precious metals and mirror finishes. For example, metal may be deposited using vapor deposition (e.g., CVD, PCVD, EPCVD, PVD) using, for example, a vacuum chamber at, for example, class 100,000, 1000, 100 or 1. The deposition may be conformal and/or result in a planar surface. For example, a card may have different thicknesses in different areas (e.g., battery area may be thicker) and the deposition may result in a planar or approximately planar surface. [0085] According to some example embodiments, a mask may be provided, for example, by using resist based processes and/or stickers. For example a sticker may be applied to a layer on which metal will be deposited and removed after the deposition.

[0086] A skin material may be thick (e.g., thicker than conventional skin layers) and made of, for example a flexible glass or other material that withstands elevated temperature processing (e.g., high temperature and/or pressure depositions) and protects internal components. The skin material may be the same on both sides of a card or different.

[0087] After metal deposition, a clear or colored plastic layer may be applied. For example, a clear protective layer may be applied for printing.

[0088] The card or other device may be weighted to provide the experience of, for example, a full metal card where metal is deposited on a non-metal skin and a non-metal finish is applied. Similarly, the corners or edges of a card may be coated such that when struck against an object emulates the sound of, for example, a full metal card.

[0089] A grinding and/or other polishing may be applied, for example, when applying different precious metals (e.g., gold over silver, or silver over gold) or when printing three dimensional images.

[0090] According to some example embodiments, a skin layer or other layer (e.g., a plastic layer) may be etched with a pattern prior to metal deposition to provide an inlay. According to some example embodiments, a skin layer or other layer (e.g., a plastic layer) may be etched with a pattern prior to metal deposition and a mask (e.g., sticker) applied to provide an inlay and protrusion on the card to provide a three dimensional image with metal above and below the skin layer surface. According to some example embodiments, mechanical engraving may be performed. [0091] A device according to example embodiments may include a first contact chip with a first primary account number (PAN) in storage, the first PAN associated with a first payment method, and a second contact chip with a second PAN in storage, the second PAN associated with a second payment method. The first payment method of the device may be credit, and the second payment method of the device may be equated monthly installments (EMI). [0092] Payment cards are provided that may be powered interactive payment cards or static payment cards. Interactive cards may have, for example, any number of buttons and/or displays to receive manual input from cardholders and/or display information to cardholders. Batteries may be included in interactive cards to power electronics such as displays and other electrical components in order to provide advanced functionality even when, for example, a card is not under power of an external device (e.g., a point-of- sale terminal). Non-powered and/or non-interactive cards may be provided with advanced capabilities through, for example, the inclusion of advanced payment applets that can trigger different functionalities in different situations. In doing so, the payment application can receive data from a transaction and initiate different capabilities in the same manner than a cardholder can initiate different capabilities. Advanced transaction processing capabilities at the terminal, merchant, merchant processor, payment network, bank, bank processor, or other device may receive data from and/or provide data to payment applets located on powered, non-powered, manually interfacing, and/or non-manually interfacing cards. [0093] A payments applet may be provided, for example, in a processing chip such as a secure processing chip that includes a secure element such as a secure memory element. A processing chip may communicate with a point-of-sale terminal through any number of interfaces such as a contact interface (e.g., contact EMV), a contactless interface (e.g., an RFID antenna, a magnetic communications device, or any type of interface (e.g., a dynamic and/or static QR code or other type of barcode provided through a display). Persons skilled in the art will appreciate that different interfaces may have their own processors and/or secure elements. In this manner, a processor may be coupled to other chips (e.g., processors) that provide different interfaces. For example, a contactless chip may provide a contactless interface and a contact chip may provide a contact interface. Accordingly, a payment applet may be provided in a contact chip and may include contact chip features and a payment applet may be provided in a contactless chip and may include contactless chip features. Additional software (e.g., firmware) may be provided to move data between different components and/or structures of a device. As per another example, a single chip may have an applet that includes multiple interface features such as contact chip features and contactless chip features. Persons skilled in the art will appreciate that different interfaces may have different performance and protocols that take advantage of the capabilities of the differentiating interfaces. For example, a applet may have a faster contactless protocol than a contact applet and, as such, may have the capability of completing a contactless transaction faster than the applet may complete a contact transaction (or vise versa) in certain scenarios.

[0094] Applets may include one or more applications and such applications may be prioritized such that a point-of-sale reader may initiate applications that are applicable to that point-of-sale reader in such a prioritization. A card or other device may change the priority of such applications based on input, for example, on the device (e.g., a manual input on a manual input interface such as a button on a battery powered card). The applet may change priorities alternatively, for example, based on pre-determined prioritizations based on data that is learned by the applet during one or more than one transaction. In general, payment applets are provided that may store in a secure element or other structure some or all data that is introduced to a payment applet after a payment applet is utilized to make a purchase transaction. The applet may utilize the received data to make determinations that may change the operation of the applet temporarily, permanently, and/or conditionally. For example, a payment applet may receive data associated with the country that the card was utilized in for a transaction. The payment applet may reset a transaction and utilize the information in the subsequent approved transaction or, for example, the applet may permit the transaction to complete and utilize the information in the subsequent transaction. For example, a card may have different payment card numbers associated with different countries and each payment card number may carry different economics (e.g., interchange and/or assessment fees) based on the country where the card number is utilized.

Accordingly, for example, a device may change the payment card number based on the country where the card is located in order to provide improved economics (e.g., interchange and/or assessment fees). The device may, for example, change a default parameter (e.g., payment account number) based on one transaction or receiving the same data (e.g., same country) for a number of transactions (e.g., for 2, 3, 4, 5, or more than 5 transactions). [0095] Persons skilled in the art will appreciate that different applications may be provided, for example, in an applet for different payment networks. Accordingly, for example, an applet may receive manual input (e.g., from a button on the device or information associated with a button press on an external device such as a mobile phone) that may cause the applet to initiate an application or prioritize an application associated with a particular account (e.g., a personal account) of a particular payment product (e.g., a credit card) of a particular network (e.g., Mastercard, Visa, Mastercard, JCB, UPI, etc.). Similarly, manual input may select a different account (e.g., personal account or business account) or a different option (e.g., pay with points, pay with installments such as a 3 month, 6 month, 12 month, 18 month, 24 month, 36 month or 48 month installment, etc.). [0096] Accordingly, for example, a cardholder may on the device that includes the applet (e.g., a powered card) or another device (e.g., a mobile phone associated with the cardholder) select a payment network, payment product, payment account, and/or payment option and provide information associated with this selection to the applet. This may be done via a direct electrical coupling on the device between the button and the applet. Alternatively, for example, this may be done remotely during a transaction by providing data to the applet associated with the selection (e.g., during contact EMV scripting and/or during contactless EMV scripting).

[0097] Accordingly, for example, a device (e.g., a telephonic payment device or card) may be utilized at a point of sale in a purchase transaction to purchase an item. The devices may be utilized, for example, to make a contact or contactless transaction. An applet on the device may be utilized to manage the transaction flow between the device and the point of sale terminal. During the transaction process, the device may manage the transaction for a first payment card account (e.g., a debit account) and that first payment card account may be associated with the country of payment account issuance (e.g., the United States). During the transaction process, the applet may learn that the transaction is occurring in the United States from data received from the point of sale device during the payment transaction. The applet may be structured to recognize the country and perform different activities based on the recognized country. For example, if the country recognized matches the country of issuance then the applet may ensure that a transaction only completes if the payment account for the transaction matches the payment account the applet recognizes is to be utilized for the recognized country. Thus, an applet may be set so that a particular account (e.g., debit) it utilized when the device is in the country of issuance and that a different account (e.g., a pre-paid account such as a foreign exchange pre-paid account) is utilized when the device is not in the country of issuance. If the recognized country matches the payment card account desired for that country then the apple may permit the transaction to complete. If the recognized country does not match the payment card account desired then the payment applet may attempt to change the account of the transaction or may terminate the transaction without the transaction successfully completing. This may be done, for example, by the card not proving a confirmation or acknowledgement of a transaction approval. Persons skilled in the art will appreciate that a device may include numerous steps of bi- directional communication to a point-of-sale device and the point-of-sale-device may include multiple steps of communication data bi-directionally to the merchant bank, payment network, issuer, issuing bank processor, and/or a variety of additional processing or other elements. By shutting down a transaction, the payment applet may then attempt to re-initiate a transaction with the payment account for the previously recognized country. The payment applet may change the account utilized in a payment transaction in order to, for example, increase the chance that the applet does not have to restart by assuming, for example, that at least a number of subsequent transactions will occur in the same country as the previously detected country. Persons skilled in the art will appreciate that a payment applet may not be able to restart a transaction and that the device holder may have to dis-engage the device from the point-of-sale reader and re-engage with the point-of-sale reader. As such, for example, a cardholder may have to remove a card from an EMV terminal the first time a cardholder enters a country and reinsert the card into the EMV terminal each time a cardholder enters a country. Alternatively, for example, a card may wait for a number of transactions (e.g., 2 transactions) that are associated with an account change before making the account change for future transactions. Accordingly, if for example, a cardholder is using a virtual card on a mobile phone and enters a country, that cardholder may, if the payment applet cannot re-initiate a transaction itself, find themselves dis-engaging from a reader on two consecutive occasions if the device is set to change the account used initially for a transaction only after two changes are detected. Persons skilled in the art will appreciate that a card may include program logic for predicting situations and pre-emptively changing accounts (or other features) based on those predictions. Person skilled in the art will appreciate that different accounts, options, or other features may be deployed by a payment applet on a device (e.g., a card or a mobile telephonic device) for different countries, groups of countries, country of issuance, countries outside the country of issuance, etc. Accordingly, for example, a payment device may change to a U.S. payment card when in the U.S, a French payment when in France, a German payment card when in Germany, and may default to an international foreign exchange card (e.g., a foreign exchange pre-paid card) if the device does not have a territory-specific account for a particular country or territory.

[0098] External information may be sent to a payment applet during a transaction in order to update the payment applet. For example, a mobile telephonic device may determine the location of the mobile telephonic device and may communicate information to a remote server. The remote server, in turn, may be reviewed by a processing system, for example, to see if any updates occurred during a payment transaction with a device and updates may be provided to the payment applet of the device undergoing the payment transaction during a payment transaction. Accordingly, for example, the country may be updated by an external device. Any type of information may be downloaded such as, for example, any setting or updated to program logic. For example, a setting as to whether the country should be changed for a current transaction or if the change (e.g., terminate and re-initiate a transaction) or if the change should wait until the next transaction (e.g., let the current transaction be approved and complete the transaction before changing the setting). Person skilled in the art will appreciate that the payment device may have its own wireless connection (e.g., cellular connection, Bluetooth connection, etc.) and may receive updates from this connection before, during, and/or after a payment transaction. Similarly, a payment device may communicate with an external non-point of sale device directly (e.g., a card may communicate with a mobile phone via a Bluetooth or other wireless connection). Non-wireless connections may also be utilized (e.g., a device may have an EMV slot and may electronically couple to a card via that EMV slot). Persons skilled in the art will appreciate that updates made to a payment applet may be also made to other communication systems such as, for example, dynamic barcode systems (e.g., dynamic QR systems) as well as dynamic magnetic stripe communications systems. Accordingly, the device may change the account on its magnetic stripe as well as displayed QR payment information in addition to its contact and contactless payment information.

[0099] Persons skilled in the art will also appreciate that an applet may be generally considered, for example, all software/firmware in a device that is utilized to complete a purchase transaction or may be considered individual applets running on individual environments. For example, a device may have an applet that runs on a first operating system to perform a first set of functions (e.g., Visa EMV contactless) and a second applet that runs on a second operating system to perform a second set of functions (e.g., QR code). Intermediary software/firmware as well as intermediary hardware (e.g., processor(s)) may be utilized to share information and/or controls between applets and/or other hardware and/or software/firmware portions of a device.

[0100] A payment applet on a device may receive time as part of a transaction process. Accordingly, the device may be utilize the time of a transaction in determining, for example, an account to utilize or a payment option or other metric to utilize. The device may, for example, utilize the time also to update a time tracking device such as a timer/counter. In doing so, for example, the card may be able to determine the time of a transaction before a transaction process starts. Accordingly, for example, a card may be able to predict when the day changes. A first account may be utilized, for example, for a first period of time and a second account may be utilized for a second period of time. For example, when a card is issued (e.g., a virtual and/or physical card) a first card account may be utilized for a period of time (e.g., the first 72 hours) and a second card account may be utilized for a second period of time (e.g., after the first 72 hours). In doing so, for example, additional security may be provided so if a card is compromised in the mail the relevancy of the card compromise may be reduced. Furthermore, for example, a debit or pre-paid card may be the card for the first period of time (e.g., first 5 days) and then the card may be switched over to a different product such as a credit account for a credit product. In doing so, for example, a card may be instantly issued to a consumer while a credit setup process is being performed that may, for example, determine the credit limit and/or other metrics associated with the credit card.

[0101] A payment applet may receive the date of a transaction in addition to the time. A device may utilize this date information in the current transaction and/or subsequent transactions. For example, in countries that have heightened levels of inflation, it may be beneficial for a cardholder (e.g., a physical card or a virtual card on a mobile device) to be issued a card that utilizes a different account over different portions of a month. For example, a first account may be utilized on the first half of the moth (e.g., beginning of the month to the end of the 15^th of the month) and a second account may be utilized on the second half of the money (e.g., starting on the 16t of the month to the end of the month). In doing so, a cardholder may have two different payment dates - one associated with the first account at a firs time and one associated with a second account at a second time. In doing so, the card may automatically recognize the date during a transaction and terminate the transaction if the account associated with that date is not being utilized so that another transaction may be started with that account utilized by the payment applet. Persons skilled in the art will appreciate that recognized time by the device may be utilized in conjunction with the recognized date and a timing circuit in order to predict when a new period starts so that the appropriate account can be utilized in a point-of-sale terminal when a transaction is made in that period. In a country where an annual interest rate is over two hundred percent, for example, a cardholder may be provide with material economic value for a card that provides a longer time for a payment to be due by having multiple payment periods. A card may switch between two, three, four, five or more accounts in order to provide a cardholder with two, three, four, five or more, respectively, credit payment periods. The different accounts may have a shared credit line and/or may have different credit lines.

[0102] The value of a transaction may be utilized, for example, as a switching mechanism in a payment applet to switch between accounts, options, and or other payment features. For example, a transaction associated with an amount larger than a particular amount (e.g., $100, $500, or $1000) may be switched from a first account (e.g., a debit account) to a second account (e.g., a credit account). A payment applet may alternatively, for example, switch a transaction from a first option (e.g., a credit option on a credit account) to a second option (e.g., an installment option on a credit account. Persons skilled in the art will appreciate that information associated with different options (e.g., pay with points, pay with various installment periods) may be embedded into payment data (e.g., a pan sequence number, magnetic stripe discretionary data, etc.). Accordingly, for example, a payment applet may determine to embed payment option data (e.g., installment data) in to payment information in a particular scenario or set of scenarios. This payment information may then be communicated through a payment network to an issuing bank's processor. An issuing bank's processor may authorize the transaction. After authorization, for example, the payment option data may be extracted (e.g., from a copy of the authorization message) and may be utilize do initiate an additional transaction such as a statement credit/offset (e.g., for a pay with points) or a statement credit/offset with monthly equated statement charges and/or additional monthly fees over a number of months (e.g., for an equated monthly installment over those number of months). A statement offset may be provided, for example, via a monetary file transfer between two different accounts. One account, for example, may be an escrow and another account may be the account associated with the payment device for the transaction. Accordingly, a $60 credit transaction may be offset by a $60 transfer. The description of the offset transaction may be, for example, associated with the feature. Accordingly, the description may state "Toys R Us 6/26 for $60 offset with 6 month EMI" and then each month a $10 installment may be applied with the description "Toys R Us 6/26 Installment X of 6" where X is the month installment of the 6 months of installments. A fee may be added (e.g., a percentage or fixed fee) to the aforementioned amount (e.g.. $2 to make the installment $12) or a second line statement may be provided in the statement for the fee (e.g., a second statement line of $2). Payment options may also be selected by a manual interface on a device or a manual interface on a remote device that is then communicated to the transacting device (e.g., via a wireless communication or through transaction data delivered to the transacting device from the point-of- sale terminal).

[0103] A payment applet may combine data from multiple transactions and utilize this combined data to make determinations on accounts, options, applications, or other attributes to utilize in a payment transaction. Cumulative data such as cumulative transaction amounts may be utilized to determine the amount spent on the payment device over, for example, a period of time, for example, on a particular type of payment (e.g., payment transactions with bi-directional data flow). Accordingly, for example, an account (e.g., a debit account) may be utilized until a particular amount of transaction volume occurs (e.g., $1,000) during a period of time (e.g., each month) and a second account (e.g., a credit aaccount) may be utilized after that until the end of the month. Alternatively, for example, credit may be utilized during each month until a transaction amount is reached and then an installment option may be utilized. In doing so, for example, a payment device (e.g., a static, non-interactive card) may be able to change accounts and/or payment options based on pre-determined conditions. Persons skilled in the art will appreciate that information may be sent to a device to, for example, update pre-determined conditions to other conditions (e.g., change the cumulative amount to cause a change in an account and/or option to a different cumulative amount as well as the account and/or option changed). Accordingly, updates to one or more payment applets or other software/firmware parts of a device may be updated during a transaction (e.g., through transaction information0 or at any time (e.g., through a wireless communication by a wireless communication communications device on the device).

[0104] A device may utilize (e.g., via a payment applet) an approval and/or a cumulative number of approvals and/or additional transaction data to initiate a feature. For example, a pre-stored message may be displayed on a display (e.g., an bi-stable display, non bi-stable display, and/or a display of individual light emitting diodes LEDs or other sources of light) for a particular transaction approval (e.g., first transaction) particular group of transaction approvals (e.g., first 10 transactions) and/or all transactions approvals of a particular type (e.g., first transaction approval after a new year). Accordingly, for example, a welcome message may be provided to a cardholder for the first one, two, or more than two transaction approvals. The number of transaction approvals may also be utilized, for example, to provide a game of chance and/or a sweepstakes. For example, a prize may be randomly hidden in each payment account (e.g., a prize of a free transaction or a discount on a transaction) and a message may be displayed to a cardholder indicative of whether or not a transaction approval was a winning transaction approval and the prize associated with that winning approval. Persons skilled in the art will appreciate that prizes may be distributed over a number of cards randomly such that, for example, multiple prizes may be provided on some cards and no prizes may be provide on other cards. Prizes may be randomly assigned transaction approvals (e.g., 72nd transaction approval) in a range of transaction approvals for a card (e.g., transaction approvals between 1 and 500). [0105] A mobile device may have a mobile wallet with a virtual card that corresponds to a physical card. A cardholder may select different accounts and/or options on the virtual card. This selection information may be stored on, for example, a remote server and delivered to a transacting device (e.g., a static, non- interactive card) during a transaction. A payment applet on the static-non-interactive card may determine whether or not to terminate a payment transaction based on the received information and change the account and/or option as desired by the cardholder and re- initiate the transaction.

[0106] Persons skilled in the art will appreciate that physical payment cards may be loaded as virtual cards into a virtual wallet of a mobile device (e.g., a mobile telephonic device). A user may, for example, browse different virtual cards in the virtual wallet and utilize those cards for online transactions (e.g., by reading a displayed card number) and/or an in-store transaction (e.g., by initiating a contactless transaction between the mobile telephonic device and a contactless point-of-sale terminal). Persons skilled in the art will appreciate that cards with interactive buttons and cards without interactive buttons may either or both be loaded into virtual wallets and receive virtual buttons to perform additional functionalities (e.g., the same functionalities on physical buttons of physical interactive cards). Accordingly, for example, a mobile wallet may be provided in which some virtual cards (e.g., those that correspond to physical interactive cards), some virtual cards (e.g., cards associated with a particular network, and/or virtual cards of a particular type (e.g., all credit cards) and/or all virtual cards may be provided with interactive features when they are digitized and uploaded into a virtual wallet. Persons skilled in the art will appreciate that a virtual wallet may be provided on a website and retrieved after a user logs into the website and identified themselves and is completing a purchase transaction. A virtual wallet may alternatively be provided on a device such as, for example, a watch, phone, or a card. Such devices may have wireless communication capabilities (e.g., cellular capabilities) to communicate data (e.g., virtual card data). [0107] Accordingly, for example, a non-interactive card with no buttons may be loaded into a wallet and the virtual card may have a virtual button associated with point redemption and one or more virtual buttons associated with one or more installment options (e.g., 6-month, 12-month, 18-month, and/or 24-mont installments). The virtual card may have a virtual button for one or more accounts (e.g., one or more debit, credit, and/or pre-paid accounts).

Additionally, for example, an interactive card with one or more payment account buttons (e.g., credit, debit, and/or pre-paid), installment buttons, and reward buttons may be loaded into one or more virtual wallets as a virtual card that has one, more than one, or all of the buttons of the physical card as virtual buttons on the virtual card. Thus, for example, an issuing bank may provide a virtual wallet where any card from that bank may be loaded into the virtual wallet and virtual buttons may be added to all of the cards for additional features not present on the physical cards (e.g., unless the physical cards are interactive cards). Additional features may be added as virtual buttons to all or some of an issuing bank's virtual cards after the card has been digitized/virtualized and put in the virtual wallet. Accordingly, for example, the functionality of a virtual card may be updated as new features are deployed.

[0108] Persons skilled in the art will appreciate that multiple processes may be utilized to load a physical card into a virtual wallet as a virtual card. For example, the personalization data associated wit a card may be utilized to fulfill a virtual card. As per another example, a physical card may be recognized at a remote server and a virtual card, such as a payment account token, may be generated and provided to a device. Host card emulation processes, for example, may be utilized. Brief Description of the Drawings

[0109] The principles and advantages of the present invention can be more clearly understood from the following detailed description considered in conjunction with the following drawings, in which the same reference numerals denote the same structural elements throughout, and in which:

[0110] FIG. 1 is an illustration of a card and architecture constructed in accordance with the principles of the present invention;

[0111] FIG. 2 is an illustration of a device constructed in accordance with the principles of the present invention;

[0112] FIG. 3 is an illustration of a network topology constructed in accordance with the principles of the present invention;

[0113] FIG. 4 is an illustration of a device constructed in accordance with the principles of the present invention;

[0114] FIG. 5 is an illustration of a device constructed in accordance with the principles of the present invention;

[0115] FIG. 6 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0116] FIG. 7 is an illustration of a device constructed in accordance with the principles of the present invention;

[0117] FIG. 8 is an illustration of a device constructed in accordance with the principles of the present invention; [0118] FIG. 9 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0119] FIG. 10 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0120] FIG. 11 is an illustration of a process flow charts constructed in accordance with the principles of the present invention;

[0121] FIG. 12 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0122] FIG. 13 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0123] FIG. 14 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0124] FIG. 15 is an illustration of a thin mechanical slider usable on a card and/or card chip in accordance with the principles of the present invention;

[0125] FIG. 16 is an illustration of features constructed in accordance with the principles of the present invention;

[0126] FIG. 17 is an illustration of features constructed in accordance with the principles of the present invention;

[0127] FIG. 18 is an illustration of features constructed in accordance with the principles of the present invention;

[0128] FIG. 19 is an illustration of features constructed in accordance with the principles of the present invention; [0129] FIG. 20 is an illustration of features constructed in accordance with the principles of the present invention;

[0130] FIG. 21 is an illustration of features constructed in accordance with the principles of the present invention;

[0131] FIG. 22 is an illustration of features constructed in accordance with the principles of the present invention;

[0132] FIG. 23 is an illustration of features constructed in accordance with the principles of the present invention;

[0133] FIG. 24 is an illustration of features constructed in accordance with the principles of the present invention;

[0134] FIG. 25 is an illustration of features constructed in accordance with the principles of the present invention;

[0135] FIG. 26 is an illustration of features constructed in accordance with the principles of the present invention;

[0136] FIG. 27 is an illustration of features constructed in accordance with the principles of the present invention;

[0137] FIG. 28 is an illustration of features constructed in accordance with the principles of the present invention;

[0138] FIG. 29 is an illustration of features constructed in accordance with the principles of the present invention;

[0139] FIG. 30 is an illustration of features constructed in accordance with the principles of the present invention; [0140] FIG. 31 is an illustration of features constructed in accordance with the principles of the present invention;

[0141] FIG. 32 is an illustration of features constructed in accordance with the principles of the present invention;

[0142] FIG. 33 is an illustration of a card and architecture constructed in accordance with the principles of the present invention;

[0143] FIG. 34 is an illustration of a device constructed in accordance with the principles of the present invention;

[0144] FIG. 35 is an illustration of a network topology constructed in accordance with the principles of the present invention;

[0145] FIG. 36 is an illustration of a device constructed in accordance with the principles of the present invention;

[0146] FIG. 37 is an illustration of a device constructed in accordance with the principles of the present invention;

[0147] FIG. 38 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0148] FIG. 39 is an illustration of a device constructed in accordance with the principles of the present invention;

[0149] FIG. 40 is an illustration of a device constructed in accordance with the principles of the present invention;

[0150] FIG. 41 is an illustration of a process flow chart constructed in accordance with the principles of the present invention; [0151] FIG. 42 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0152] FIG. 43 is an illustration of a process flow charts constructed in accordance with the principles of the present invention;

[0153] FIG. 44 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0154] FIG. 45 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0155] FIG. 46 is an illustration of a process flow chart constructed in accordance with the principles of the present invention;

[0156] FIG. 47 is an illustration of a thin mechanical slider usable on a card and/or card chip in accordance with the principles of the present invention;

[0157] FIG. 48 is an illustration of hardware in a loyalty hosting system;

[0158] FIG. 49 is an illustration of cards and architectures in accordance with the principles of the present invention;

[0159] FIG. 50 is an illustration of cards in accordance with the principles of the present invention;

[0160] FIG. 51 is an illustration of cards in accordance with the principles of the present invention;

[0161] FIG. 52 is an illustration of card displays in accordance with the principles of the present invention; [0162] FIG. 53 is an illustration of cards in accordance with the principles of the present invention;

[0163] FIG. 54 is an illustration of dynamics magnetic stripes in accordance with the principles of the present invention;

[0164] FIG. 55 is an illustration of dynamics magnetic stripes in accordance with the principles of the present invention;

[0165] FIG. 56 is an illustration of devices in accordance with the principles of the present invention;

[0166] FIG. 57 is an illustration of network topologies in accordance with the principles of the present invention;

[0167] FIG. 58 is an illustration of mobile devices in accordance with the principles of the present invention;

[0168] FIG. 59 is an illustration of cards in accordance with the principles of the present invention;

[0169] FIG. 60 is an illustration of cards in accordance with the principles of the present invention;

[0170] FIG. 61 is an illustration of cards in accordance with the principles of the present invention;

[0171] FIG. 62 is an illustration of cards in accordance with the principles of the present invention;

[0172] FIG. 63 is an illustration of cards in accordance with the principles of the present invention; [0173] FIG. 64 is an illustration of cards in accordance with the principles of the present invention;

[0174] FIG. 65 is an illustration of systems in accordance with the principles of the present invention;

[0175] FIG. 66 is an illustration of systems in accordance with the principles of the present invention;

[0176] FIG. 67 is a flow diagram illustrating communication sequences in accordance with the principles of the present invention;

[0177] FIG. 68 is an illustration of cards in accordance with the principles of the present invention;

[0178] FIG. 69 is an illustration of cards in accordance with the principles of the present invention;

[0179] FIG. 70 is an illustration of cards in accordance with the principles of the present invention;

[0180] FIG. 71 is an illustration of a card constructed in accordance with the principles of the present invention;

[0181] FIG. 72 is an illustration of a card constructed in accordance with the principles of the present invention;

[0182] FIG. 73 is an illustration of circuitry, and associated waveforms, constructed in accordance with the principles of the present invention;

[0183] FIG. 74 is an illustration of a card constructed in accordance with the principles of the present invention; [0184] FIG. 75 is an illustration of a card constructed in accordance with the principles of the present invention;

[0185] FIG. 76 is an illustration of a card constructed in accordance with the principles of the present invention;

[0186] FIG. 77 is an illustration of process flow charts constructed in accordance with the principles of the present invention;

[0187] FIG. 78 is an illustration of a card constructed in accordance with the principles of the present invention;

[0188] FIG. 79 is an illustration of a card constructed in accordance with the principles of the present invention; and

[0189] FIG. 80 is an illustration of a card constructed in accordance with the principles of the present invention.

[0190] FIG. 81 shows cards and architectures constructed in accordance with the principles of the present invention;

[0191] FIG. 82 shows devices constructed in accordance with the principles of the present invention;

[0192] FIG. 83 shows network topologies arranged in accordance with the principles of the present invention; [0193] FIG. 84 shows transaction verification methods according to principles of the present invention;

[0194] FIG. 85 shows cards according to principles of the present invention;

[0195] FIG. 86 shows a card according to principles of the present invention; [0196] FIG. 87 shows a token transaction method performed in accordance with the principles of the present invention;

[0197] FIG. 88 shows a card according to principles of the present invention;

[0198] FIG. 89 shows a card according to principles of the present invention;

[0199] FIG. 90 shows a card according to principles of the present invention;

[0200] FIG. 91 shows a card according to principles of the present invention;

[0201] FIG. 92 shows a mobile telephonic device according to principles of the present invention;

[0202] FIG. 93 shows a card with vertical print differentiation according to principles of the present invention;

[0203] FIG. 94 shows a card according to principles of the present invention;

[0204] FIG. 95 shows a card according to principles of the present invention;

[0205] FIG. 96 shows a card according to principles of the present invention;

[0206] FIG. 97 shows a GUI of a device according to principles of the present invention;

[0207] FIG. 98 is an illustration of a card and architecture constructed in accordance with the principles of the present invention;

[0208] FIG. 99 is an illustration of a device constructed in accordance with the principles of the present invention;

[0209] FIG. 100 is an illustration of a network topology constructed in accordance with the principles of the present invention; [0210] FIG. 101 is an illustration of a device constructed in accordance with the principles of the present invention;

[0211] FIG. 102 is an illustration of a device constructed in accordance with the principles of the present invention;

[0212] FIG. 103 is an illustration of a device constructed in accordance with the principles of the present invention;

[0213] FIG. 104 is an illustration of flow charts constructed in accordance with the principles of the present invention;

[0214] FIG. 105 is an illustration of a device constructed in accordance with the principles of the present invention;

[0215] FIG. 106 is an illustration of a device constructed in accordance with the principles of the present invention;

[0216] FIG. 107 is an illustration of a device constructed in accordance with the principles of the present invention; and

[0217] FIG. 108 is an illustration of a device constructed in accordance with the principles of the present invention.

Detailed Description of the Invention

[0218] FIG. 1 shows card 100 that may include, for example, dynamic magnetic stripe communications device 101, one or more displays (e.g., displays 112, 113 and 125), permanent information 120, light sensor 127, one or more buttons (e.g., buttons 130-134, 198 and 199), lights 135-138, 196 and 197, and dynamic number 114 which may include a permanent portion 111. Permanent portion 111 may be, for example, printed, embossed and/or laser etched on card 100.

[0219] Multiple displays may be provided on card 100 for various purposes. For example, display 112 may display a dynamic number entirely, and/or partially. Display 113 may be utilized to display a dynamic code (e.g., a dynamic security code). Display 125 may display logos, barcodes, and/or one or more lines of information (e.g., may display a coupon code). A display (e.g., at least one of displays 112, 113 and 125) may be a bi- stable display or non bi-stable display. A bi-stable display may be a display that maintains an image without power.

[0220] Card 100 may include permanent information 120 including, for example, information specific to a user (e.g., a user's name and/or username) and/or information specific to a card (e.g., a card issue date and/or a card expiration date).

[0221] Card 100 may include a dynamic magnetic communications device. Such a dynamic magnetic communications device may take the form of a magnetic encoder and/or a magnetic emulator. A magnetic encoder may change the information located on a magnetic medium such that a magnetic stripe reader may read changed magnetic information from the magnetic medium. A magnetic emulator may generate electromagnetic fields that directly communicate data to a magnetic stripe reader. Such a magnetic emulator may communicate data serially to a read-head of the magnetic stripe reader. [0222] Card 100 may include one or more buttons, for example, buttons 130-134, 198 and 199. Buttons 130-134, 198 and 199 may be, for example, mechanical buttons, capacitive buttons, light sensors and/or a combination thereof.

[0223] Button 199 may be used, for example, to communicate information through dynamic magnetic stripe communications device 101 indicative of a user's desire to communicate a single track of magnetic stripe information. Persons skilled in the art will appreciate that pressing a button (e.g., button 199) may cause information to be communicated through device 101 when an associated read-head detector detects the presence of a read-head of a magnetic stripe reader and/or at a specific frequency. Button 198 may be utilized to communicate (e.g., after button 198 is pressed and after a read-head detects a read-head of a reader) information indicative of a user selection (e.g., to communicate two tracks of magnetic stripe data). Multiple buttons may be provided on a card and each button may be associated with a different user selection.

[0224] Different third party features may be, for example, associated with different buttons and a particular feature may be selected by pressing an associated button. According to at least one example embodiment, button 198 and button 199 may each be associated with, for example, a different third party service provider feature (e.g., an application facilitating a coupon) and may be changed by a user at any time.

[0225] According to some example embodiments, a user may select a third party feature from a list displayed to the user. For example, the user may scroll through a list of features on a display (e.g., display 125). A user may scroll through a list using buttons on a card (e.g., buttons 130-134). The list of features may be displayed to the user individually, in groups and/or all features may be simultaneously displayed.

[0226] According to some example embodiments, a third party feature associated with a button may be changed by a user, for example, on a graphical user interface (GUI) provided by a device provider, ecosystem provider, application manager provider, remote facility provider, card issuer, processor, and/or any other entity (which may be the same or different entities). For example, an ecosystem provider may, on its website and/or via an application, allow a user to change the third party feature performed when the third party's feature button is selected by a user on the user's card or other device. [0227] A third party service provider may provide a reward (e.g., a coupon) from a collection of rewards based on, for example, one or more card transactions. The fact the user has received the reward may be presented on a profile page of the user. When a transaction is performed, a user's profile may be updated to state that the user has earned a reward and the user may receive the reward (e.g., via email). A user may be provided with a GUI, for example, a GUI on a mobile telephonic device of the user, when the user makes a purchase, to identify and/or use the reward earned by the user.

[0228] The selection of a feature may or may not have a cost associated with it. If a cost is associated with the feature, for example, the cost may be added to a customer's statement (e.g., added to a credit or debit purchase) for a particular transaction. A fixed-fee or variable-fee (e.g., a percentage of the transaction) may then be removed from the fee charged to the user and distributed among particular parties (e.g., distributed to the card issuer, application manager provider, ecosystem provider, device provider and/or other entity). The remainder of the fee, if any, may be provided, for example, to the third party service provider.

[0229] A cost may be associated to a feature selection, but may not be a cost to a user. For example, the cost may be a cost to a third party service provider (e.g., an incentive). The cost may be a cost to other entities, for example, the device provider, card issuer, card processor (which may be the same, for example, as the card issuer), and/or any other entity (e.g., card network).

[0230] According to some example embodiments, a user may select a type of payment on card 100 via manual input interfaces (e.g., buttons 130-134). The manual input interfaces may correspond to displayed options (e.g., displayed on display 125). Selected information may be communicated to a magnetic stripe reader via a dynamic magnetic stripe communications device. Selected information may also be communicated to a device (e.g., a mobile telephonic device) including a capacitive sensor and/or other type of touch sensitive sensor.

[0231] Lights 135-138, 196 and 197 (e.g., light emitting diodes), may be associated with buttons 131-134, 198 and 199. Each of lights 135-138, 196 and 197 may indicate, for example, when a button is pressed. In a case where a button may activate card 100 for communications, a light may begin blinking to indicate card 100 is still active (e.g., for a period of time) while reducing power expenditure. Although not shown, a light may be provided for button 130. [0232] Card 100 may include light sensor 127. Light sensor 127 may, for example, receive information from a light source (e.g., a display of a mobile telephonic device and/or a laptop computer). Card 100 may include, for example, any number of light sensors 127. Light sensor 127 may be utilized such that a display screen, or other light emitting device, may communicate information to light sensors 127 via light. Display 125 may allow a user to select (e.g., via buttons) options on display 125 that instruct the card to communicate (e.g., via a dynamic magnetic stripe communications device, RFID and/or exposed IC chip) to use a debit account, credit account, pre-paid account, and/or point account for a payment transaction.

[0233] Architecture 150 may be utilized with any card (e.g., any card 100). Architecture 150 may include, for example, processor 120, display 140, driving circuitry 141, memory 142, battery 143, radio frequency identification (RFID) 151, integrated circuit (IC) chip 152, electromagnetic field generators 170, 180, and 185, and read-head detectors 171 and 172.

[0234] Processor 120 may be any type of processing device, for example, a central processing unit (CPU) and/or a digital signal processor (DSP). Processor 120 may be, for example, an application specific integrated circuit (ASIC). Processor 120 may include on-board memory for storing information (e.g., triggering code). Any number of components may communicate to processor 120 and/or receive communications from processor 120. For example, one or more displays (e.g., display 140) may be coupled to processor 120. Persons skilled in the art will appreciate that components may be placed between particular components and processor 120. For example, a display driver circuit may be coupled between display 140 and processor 120.

[0235] Memory 142 may be coupled to processor 120. Memory 142 may store data, for example, data that is unique to a particular card. Memory 142 may store any type of data. For example, memory 142 may store discretionary data codes associated with buttons of a card (e.g., card 100 of FIG. 1). Discretionary data codes may be recognized by remote servers to effect particular actions. For example, a discretionary data code may be stored in memory 142 and may be used to cause a third party service feature to be performed by a remote server (e.g., a remote server coupled to a third party service such as a coupon provider). Memory 142 may store firmware that, for example, controls triggering and/or the like.

[0236] Architecture 150 may include any number of reader communication devices. For example, architecture 150 may include at least one of IC chip 152, RFID 151 and a magnetic stripe communications device. IC chip 152 may be used to communicate information to an IC chip reader (not illustrated). IC chip 152 may be, for example, an EMV chip. RFID 151 may be used to communicate information to an RFID reader. RFID 151 may be, for example, an RFID tag. A magnetic stripe communications device may be included to communicate information to a magnetic stripe reader. For example, a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

[0237] Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, architecture 150 may include electromagnetic field generators 170, 180, and 185 to communicate separate tracks of information to a magnetic stripe reader. Electromagnetic field generators 170, 180, and 185 may include a coil (e.g., each may include a coil) wrapped around one or more materials (e.g., a soft-magnetic material and a non- magnetic material). Each electromagnetic field generator may communicate information, for example, serially to a receiver of a magnetic stripe reader for a particular magnetic stripe track. According to at least one example embodiment, a single coil may communicate multiple tracks of data.

[0238] Architecture 150 may include read head detectors 171 and 172. Read-head detectors 171 and 172 may be configured to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). Information sensed by the read-head detectors 171 and 172 may be communicated to processor 120 to cause processor 120 to communicate information serially from electromagnetic generators 170, 180, and 185 to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader.

[0239] According to at least one example embodiment, a magnetic stripe communications device may change the information communicated to a magnetic stripe reader at any time. Processor 120 may, for example, communicate user-specific and card-specific information through RFID 151, IC chip 152, and/or electromagnetic generators 170, 180, and 185 to card readers coupled to remote information processing servers (e.g., purchase authorization servers). Driving circuitry 141 may be utilized by processor 120, for example, to control electromagnetic generators 170, 180 and 185. [0240] Architecture 150 may include, for example, a light sensor. Architecture 150 may receive information from a light sensor. Processor 120 may determine information received by a light sensor.

[0241] FIG. 2 shows device 200 that may be, for example, a mobile telephonic device and/or other device (e.g., portable computer such as a portable tablet computer). Device 200 may include, for example, housing 202, display 210, device card 220, virtual buttons 230, 231 and 240, virtual lights 242-247, dynamic card number and verification code 245, and identification information 250.

[0242] Display 210 may include, for example, light- sensitive and/or touch-sensitive elements. Device 200 may communicate information to a card reader, for example, via a contactless signal (e.g., an RFID signal) and/or a contact-based signal (e.g., a USB connection).

[0243] Device 200 may include a device card 220 and/or virtual buttons 230 and 231. Device card 220 may be a virtual representation of a card and/or any information identifying a payment method (e.g., credit account number). A person skilled in the art will appreciate that any physical card described herein may be provided as a device card on, for example, a computing system (e.g., a mobile telephonic device and/or a computer). Physical buttons of a physical card may, for example, correspond to virtual buttons of a device card.

[0244] Virtual button 230 may, for example, correspond to one feature (e.g., an opportunity to earn a coupon) from a third party service provider while virtual button 231 may, for example, correspond to another feature (e.g., the opportunity to add value to a coupon) from the same or a different third party service provider. According to at least one example embodiment, every feature may not be provided by a third party service provider. Persons skilled in the art will appreciate that, for example, the device provider may provide features.

[0245] All features for a card may be utilized with a particular payment account (e.g., a credit account) such that a payment transaction with that payment account is performed if any feature is selected. As another example, one or more features may be associated with a payment account (e.g., a credit account) while an additional one or more features may be associated with a different payment account (e.g., a debit account). Accordingly, a selected feature associated with a credit account may be utilized to make a purchase with credit and may perform an additional action associated with that feature. A different selected feature associated with a debit account may be utilized to make a purchase with debit and may perform an additional action associated with that different feature.

[0246] Device 200 may include virtual lights 242-247. Virtual lights 242-247 may, for example, indicate an active period during which device 200 may communicate with external devices. Virtual lights 242-247 may correspond to, for example, virtual buttons 230, 231 and 240. According to example embodiments, a fewer or greater number of virtual lights are contemplated (e.g., a center button of virtual buttons 240 may virtually light up).

[0247] FIG. 3 shows network topology 300 that may include, for example, mobile device 302, contactless device 304, cellular network access infrastructure 306, mobile network 310, wireless access point 308, IP network 312, payment network 314, issuer 320, payment server 316, merchant acquirer 317, ecosystem provider 342, merchant terminal 318, transaction card 333, user electronic device 345 and/or application providers 338, 339 and 340. [0248] Mobile device 302 (e.g., a mobile telephonic device, a PDA, an electronic tablet, a laptop, a GPS unit, and/or an MP3 player) may include, for example, a contactless interface that may initiate, sustain, and/or terminate communication channel 326 between contactless device 304 (e.g., a powered card, non-powered card and/or a device) and mobile device 302. Contactless device 304 and mobile device 302 may communicate via channel 326 using any number of contactless mediums, which may include for example, visible, audible, capacitive, electromagnetic, magnetic, and/or RF mediums.

[0249] Mobile device 302 may provide one or more transceivers, receivers and/or transmitters that may communicate with one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks (e.g., a mobile network 310). Mobile device 302 may, for example, communicate with a cellular station over a wireless radio interface (e.g., a GSM air interface) that may be used by mobile device 302 to communicate information (e.g., voice and data) to cellular network access infrastructure 306 (e.g., one or more GSM base transceiver stations, base station controllers and mobile switching centers). Persons skilled in the art will appreciate that cellular network access infrastructure 306 may utilize any multiple access architecture, such as for example, a code-division multiple access architecture and/or a time-division multiple access architecture.

[0250] Mobile device 302 may, for example, communicate with wireless access point 308 over a wireless interface (e.g., a Bluetooth interface or a Wi-Fi interface). Accordingly, for example, mobile device 302 may access one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network) without the need to first gain access to cellular network access infrastructure 306.

[0251] Payment information (e.g., a payment account number and a card expiration date) may be communicated from contactless device 304 to mobile device 302 in support of a transaction (e.g., a financial transaction) being conducted by mobile device 302. In so doing, for example, items for purchase on IP network 312 (e.g., the internet) may be accessed by a browser of mobile device 302 via an access point (e.g., wireless access point 308 and/or cellular network access infrastructure 306). Mobile device 302 may, for example, complete a purchase transaction by first obtaining required payment information from contactless device 304 and then communicating such payment information to network entities (e.g., merchant acquirer 317, payment server 316 and/or issuer 320). Mobile device 302 may, for example, already contain payment information necessary to complete a purchase transaction. Accordingly, mobile device may not need to obtain payment information from contactless device 304 before completing a purchase transaction.

[0252] Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with payment information received from mobile device 302 for authorization of a purchase. Once authorized, payment transaction information may be recorded onto a receipt that may be delivered to mobile device 302 via any one or more delivery options (e.g., via a short messaging service of mobile network 310 or an email delivery service of IP network 312).

[0253] A payment receipt may, for example, be provided to mobile device 302 as a proof-of-purchase object (e.g., a barcode) that may be provided to a display of mobile device 302 and read by other computing equipment (e.g., a barcode scanner) for proof-of-purchase confirmation.

[0254] Transaction card 333 (e.g., a powered card, non-powered card and/or device card) may, for example, communicate information to merchant terminal 318 (e.g., a magnetic stripe reader, an EMV reader, an RFID reader, an NFC reader and/or a swipe reader attached to an electronic device). Merchant terminal 318 may begin transactions (e.g., point-of-sale transactions) and/or complete transactions via merchant acquirer 317 and/or payment network 314. Accordingly, for example, transaction card 333 may communicate payment information to merchant terminal 318 to initiate a financial transaction.

[0255] Merchant terminal 318 may communicate transaction information, including at least a portion of the payment information, to merchant acquirer 317. Merchant acquirer 317 may authorize the financial transaction and/or communicate with payment server 316. Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with transaction information received from merchant acquirer

317 for authorization of a purchase. Once authorized, an authorization may be communicated to merchant terminal

318 and may be recorded onto a receipt by merchant terminal 318.

[0256] Application providers 338, 339 and 340 may be one or more entities (e.g., one or more servers) providing applications for association in an ecosystem provided by ecosystem provider 342. Each application may provide one or more features to users of a payment method (e.g., users of contactless device 304 and/or transaction card 333). For example, an application may provide a user an opportunity to earn a coupon and/or add value to a coupon in exchange for using the payment method. According to at least one example embodiment, application provider 338 may provide coupons as part of a loyalty or rewards program, which may be independent of any payment method. Ecosystem provider 342 may be, for example, a server that maintains associations between applications, users and payment methods.

[0257] Ecosystem provider 342, and application providers 338, 339 and 340, may communicate with different entities using one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network). Application providers 338, 339 and 340 may communicate directly and/or indirectly with different entities. For example, merchant terminal 318 and/or ecosystem provider 342 may communicate directly with application providers 338, 339 and 340 via IP network 312 and/or via a direct connection (e.g., to validate coupons with a coupon server). As another example, application providers 338, 339 and 340 may exchange information (e.g., transactional data) indirectly with issuer 320, merchant acquirer 317 and/or payment network 314 via, for example, ecosystem provider 342.

[0258] A user electronic device (e.g., mobile device 302 and/or a wired user electronic device 345) may display a GUI. The GUI may be an application manager used to interface with ecosystem provider 342, and application providers 338, 339 and 340, to define user preferences. Defining user preferences may include, for example, configuring associations (e.g., between users, applications and payment methods), features and/or permissions.

[0259] In order to configure associations, the GUI displayed on the user electronic device may, for example, display indicia representing applications that provide features. A user may associate one or more of the applications to one or more payment cards and/or payment card buttons (e.g., mobile device 302 and/or transaction card 333)).

[0260] In order to configure one or more features provided by an application, the GUI displayed on the user electronic device may be used to, for example, interface with one or more of application providers 338, 339 and 340. For example, using the GUI, a user may select a coupon from among multiple coupons provided by an application hosted by an application provider.

[0261] In order to configure associations, a user may use the GUI displayed on the user electronic device to define how payment network 314, ecosystem provider 342, one or more of application providers 338, 339 and 340, and third-party applications hosted by the one or more application providers (or any other application providing entity) interact for transactions conducted by the user. [0262] For example, a user may accept an end license user agreement that outlines how data may be shared between entities. As another example, a user may define what data may be shared between entities. For example, where data (e.g., transactional data) may be provided to ecosystem provider 342 by payment network 314, and/or provided to one or more of application providers 338, 339 and 340 by ecosystem provider 342, a user may select at least a portion of data provided to ecosystem provider 342 by payment network 314, and select at least a portion of data to be shared with the one or more of application providers 338, 339 and 340.

[0263] Prior to presenting transaction card 333 to merchant terminal 318 to initiate a transaction, a customer may select (e.g., via one or more button presses on a powered card and/or device card) an application to be associated to the transaction. Based on the selection, one or more additional actions may be taken besides the processing of the transaction by payment network 314. For example, a user may press a button on a powered card (e.g., transaction card 333). Upon presenting transaction card 333 to merchant terminal 318, a payment message (e.g., a magnetic stripe message) reflecting the button that was pressed may be communicated to merchant terminal 318. Merchant terminal 318 may communicate a data string including the payment message and transaction information to payment network 314 via merchant acquirer 317.

[0264] Payment network 314 may receive the data string. The data string may include a directive instructing payment network 314 to share data with ecosystem provider 342. According to at least one example embodiment, payment network 314 may share data with ecosystem provider 342 upon receiving the data string and recognizing, based on at least a portion of the data string (e.g., an account number), that data is to be shared. Payment network 314 may cause the same or a different data string to be communicated from payment network 314 (e.g., from a processor within payment network 314) to ecosystem provider 342. [0265] Although example embodiments describe a payment network communicating data to an ecosystem provider, alternatively and/or additionally, an issuer and/or a processor of an issuer may receive data and communicate at least a portion of the data and/or different data based on the received data to ecosystem provider 342. For example, a processor of issuer 320 may parse a data string received from merchant terminal 318 (e.g., via payment network 314) that includes a particular BIN number, may convert the data string into a different format and may forward the converted data string to ecosystem provider 342. Persons of ordinary skill in possession of example embodiments will appreciate that many different messaging schemes may be used.

[0266] Ecosystem provider 342 may receive the data string and compare user information (e.g., payment account number and/or payment account holder's name) that may be included within the data string to a user database to obtain a customer ID (e.g., a customer token) associated with the user information.

[0267] According to at least one example embodiment, sensitive information within the data string (e.g., payment account number and/or payment account holder's name) may be replaced with the customer ID to create a modified data string, and the sensitive information may be stored either locally within ecosystem provider 342 or remotely to ecosystem provider 342. The modified data string may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312.

[0268] According to at least one example embodiment, ecosystem provider 342 may receive the data string. The data string may be populated with information that may be indicative of which button was pressed on the powered card before being presented to merchant terminal 318. Using the button information and user preferences, ecosystem provider 342 may generate a third-party message with details that may be shared with a third-party application (e.g., one or more of application providers 338, 339 and 340). The generated data string may include the customer ID and may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312.

[0269] A user may elect to share certain transaction information with one or more of application providers 338, 339 and 340 each time a certain button is pressed on the user's powered card before presentment to merchant terminal 318 for payment. Such information may include, for example, merchant information (e.g., merchant's address), date/time information of a purchase, an amount of the purchase, a type of the purchase, and any other information (e.g., the customer ID associated with the customer's merchant account). The various pieces of the transaction information may or may not be selected for sharing by the user via the user preferences.

[0270] According to at least one example embodiment, a user may agree to share data during a registration process with an application provider (e.g., via an end user license agreement). Upon receiving a data string, the sharable data may be automatically populated within a third-party message and communicated to an application provider via IP network 312.

[0271] Upon receipt of the third-party message, the application provider (e.g., one or more of application providers 338, 339 and 340) may enact a feature provided to a user (e.g., provide a coupon). The application provider may initiate a second transaction (e.g., a piggyback transaction, a statement credit and/or the like). The second transaction may be communicated to ecosystem provider 342 via IP network 312 (e.g., the internet) and processed by ecosystem provider 342 accordingly. For example, ecosystem provider 342 may determine whether a second transaction is permitted and/or forward information associated with the second transaction to another entity (e.g., issuer 320).

[0272] According to some example embodiments, a GUI may, for example, be rendered onto a display of a user's card or other device (e.g., mobile device 302, user electronic device 345, transaction card 333 and/or contactless device 304). The GUI may display indicia of one or more third-party applications (e.g., provided by one or more application providers 338, 339 and 340) along with summary and/or detailed information. Based upon information gleaned from the information concerning the applications, the user may be better informed as to which third-party applications he or she may wish to associate with his or her powered or non-powered card. Accordingly, the whimsical and festive nature of a user's experience with a GUI rendered by an electronic device may be further enhanced.

[0273] According to example embodiments, an application provider may be any entity. For example, ecosystem provider 342 may be an application provider in addition to providing an ecosystem. According to at least one example embodiment, an application provider may be a third-party application provider and ecosystem provider 342 may host the third party application (e.g., provide coupons). Data sharing may be the same or different based on a particular configuration.

[0274] FIG. 4 shows device 400 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 401. Device 400 may include a processor that may render GUI 403 onto display 401. GUI 403 may be an application manager. Using GUI 403, a user may associate a payment method card (e.g., a powered physical card, non-powered physical card and/or device card) with third party service features within an ecosystem. GUI 403 may be displayed on display 401, for example, a computer monitor, mobile phone touch screen and/or the like. GUI 403 may be, for example, provided as an application for a device (e.g., a computer, a portable computing device and/or a mobile telephonic device) and/or retrieved information from a web browser.

[0275] An application manager may be provided, for example, on a remote facility and displayed via GUI 403 to allow a user to change the third party service features associated with a card. An application manager may manage an ecosystem of applications and payment method cards, and the user may utilize GUI 403 to, for example, associate a particular feature to a particular payment method card at any time. The user may associate the selected feature with a card and/or a card button.

[0276] Persons skilled in the art will appreciate that a default feature may be provided and/or that a number of features provided by a card issuer or other entity may be provided in addition to third party service features. For example, a card issuer may provide a card with a default of credit on one button and a default of decoupled debit on a second button. A user may press the first button to perform a credit transaction. A user may press the second button to perform a decoupled debit transaction.

[0277] GUI 403 may include tabs 405, information 411, virtual card 412, virtual indicia 413 and 414, slider 415, application identifiers 423 and 426, and selection options 428, 431, 432, 441-443 and 446.

[0278] Virtual card 412 may be provided as a representation of a user's physical and/or device card. A user may be provided with the ability to change between multiple different cards and configure the features associated with those multiple cards. Accordingly, virtual card 412 may be provided with indicia 413 in the configuration of, and indicative of, one button of a user's card, and virtual card 412 may be provided with indicia 414 in the configuration of, and indicative of, another button of a user's card. Indicia 413 and 414 may display the applications currently associated to each button (e.g., an application icon). A slider 415 may be provided to indicate which of applications associated with a button may be a default application (e.g., for online, telephonic and/or non-powered card transactions). Accordingly, a user may, for example, view virtual card 412 in order to refresh the user's memory with respect to the features associated with the buttons on a user's physical and/or device card.

[0279] A list of applications may be provided on GUI 403. Each application may provide one or more third party service provider features. In order to associate a particular feature with a particular card and/or one or more buttons on a card, a user may associate an application providing the feature to the card and/or card button(s). For example, selection 431 may associate application 423 to the button of a card associated with virtual button 413. Selection 432 may associate application 426 to the button of a card associated with virtual button 414. Accordingly, a user may change the features associated to a card by using GUI 403. In order to view the features provided by a particular application the user may, for example, select an "explore" button to view relevant information (e.g., selection 446).

[0280] The list of applications provided on GUI 403 may be, for example, all applications or a limited subset of all applications available to a user via an ecosystem provider. For example, in order to view all available applications, tab 402 may be selected by a user (e.g., with a keyboard, mouse, touch sensitive screen and/or electronic pointer) to display an application manager home view. In order to view a limited subset of applications a user may select a different tab. For example, tab 403 may be selected by a user to display a featured view including featured applications (e.g., applications-of-the-week). Other tabs may sort applications by category, use and/or the like.

[0281] Selections 428 may be selections used to activate an application with respect to the user. Activation may include registration with a third party application, acceptance of an end users license agreement associated with the application, and/or the like. Activation may also include selecting a particular feature from among multiple features provided by the application. According to at least one example embodiment, some applications may not require activation (e.g., single feature, non-interactive applications).

[0282] Once an application is activated and/or associated to a card and/or card button, a user may begin experiencing a selected feature by engaging in card transactions. For example, the user may press a card button associated with a desired feature during a card transaction. A physical and/or device card (not shown) may communicate information indicative of a button that was pressed on the physical and/or device card, along with or separate from other payment data (e.g., an account number, security code, and other data). For example, information indicative of the button that was pressed may be included in discretionary data of a payment message. A payment message may be, for example, one or more tracks of magnetic stripe data (e.g., communicated from a dynamic magnetic stripe communications device), an RFID message (e.g., a near field communication (NFC) message from a radio frequency antenna), and/or an exposed IC chip message (e.g., an EMV message) from an exposed IC chip.

[0283] The information indicative of which button was pressed may be passed to a card issuer and/or processor from a point-of-sale and any intermediary devices (e.g., a merchant acquirer processing server). The information may be passed to a remote facility (e.g., a facility providing an application manager) such that the remote facility may determine the button that was pressed by a user. This remote facility may, in turn, retrieve information associated with the third party feature (and/or a feature of a card issuer, processor, application manager provider, and/or any entity) and forward information to that feature provider such that the feature may be performed. Information may additionally and/or alternatively be provided from the feature provider to the entity that provided the information indicative of the button that the user pressed.

[0284] Persons skilled in the art will appreciate that if, for example, a non-powered card is utilized then information indicating that a button was pressed may not be available. With respect to a non-powered card, information indicative that a purchase was made may be provided to an application manager provider such that the application manager provider can initiate the desired feature for the non-powered card. For example, the feature may be a default feature, a selected feature (e.g., selected using an application manager) and/or a random feature.

[0285] For non-powered cards, for example, features may be associated with different types of purchases. For example, one feature may be provided for a particular merchant type (e.g., a grocer's coupon) and another feature may be provided for a different merchant type (e.g., a clothing store coupon). Features may be associated with other characteristics of a purchase such as, for example, a purchase above a particular amount (e.g., at or above $100) and/or a purchase below a particular amount (e.g., below $100). However, such additional feature selections are not limited to non- powered cards and may be provided to, for example, users of powered cards and devices.

[0286] According to example embodiments, any feature and/or capability not requiring a powered device (e.g., a computing device such as a powered card and/or mobile telephonic device) may be implemented with respect to a non-powered card and any feature and/or capability of a non-powered card may be implemented with respect to a powered card. According to at least one example embodiment, features and/or capabilities requiring a powered card may be implemented with respect to a non- powered card in various ways. For example, additional functionality may be provided at merchant terminals. [0287] GUI 403 may be provided, for example, on a card issuer's and/or application manager provider's website. GUI 403 may be provided, for example, on a bill statement web page. Accordingly, a user may utilize the application manager to manage application features when the user is logged into his/her account. Although example embodiments described with respect to FIG. 4 may describe a GUI 403 used to make various selections and/or associations, persons skilled in the art will appreciate that other methods are possible. For example, selections may be made by phone, email and/or the like.

[0288] A third party service provider may utilize GUI 403 as part of a user's administration and/or experience of that third party service. For example, a user's profile page for a third party service may include GUI 403. An application manager provider may provide web- code that retrieves GUI 403 from a remote facility managed by the application manager provider and/or other entity (e.g., issuer, merchant acquirer, payment network, merchant and/or the like). Selection 441 may be utilized by a user to check for updates (e.g., confirm that a feature was changed and/or if any updates are present). Selection 442 may be utilized to explain the functionality of a particular application feature. Selection 443 may be utilized for additional selection options, for example, changing which card is displayed on an application manager.

[0289] According to at least one example embodiment, a card may be provided with one button for a particular payment account (e.g., credit) and one button for a changeable feature. Accordingly, a user may, for example, only need to remember one feature associated with a card. A credit account may include rewards, for example, points, cashback, and/or miles, from the card issuer. Accordingly, pushing the payment account button may earn the user such rewards. Pushing the changeable feature button may, alternatively, for example, not earn the user such rewards and may instead initiate a changeable feature. In doing so, for example, the cost of providing a card may be reduced in that the cost of rewards for the card may be reduced. A feature may include, for example, a feature from a third party application provider. The feature from the third party application provider may be, for example, a random reward (e.g., a random coupon).

[0290] Information 411 may, for example, identify the user and card number associated with virtual card 412 and a corresponding physical card. One or more of tabs 405 may provide, for example, a history of purchases made by a user. An application manager may provide indicia reflecting a user rating (e.g., star rating 447).

[0291] According to example embodiments, an ecosystem provider may be the same or different from an application manager provider, a remote facility and/or other entities. One or more of the functions described herein as being performed by an application manager provider, and/or other entities, may be performed by the ecosystem provider. According to at least one example embodiment, an ecosystem provider may act as an application manager provider, application provider, issuer, merchant, third party service provider, payment network and/or the like to provide an end-to-end experience. In general, example embodiments contemplate the same, greater and/or fewer entities, and specific entities are described for purposes of explanation.

[0292] One of ordinary skill in the art will appreciate that GUI 403 is provided for purposes of illustration only and may take various forms. For example, features may be associated to a card without buttons and/or a card may include the same, fewer and/or a greater number of buttons than depicted in FIG. 4.

[0293] FIG. 5 shows device 500 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 501. Device 500 may include a processor that may render GUI 502 onto display 501. GUI 502 may be an application interface usable to manage a user's experience with an application. GUI 502 may be used to, for example, configure application settings, receive information from an application provider, and/or communicate information to an application provider.

[0294] GUI 502 may include, for example, application screens 503, 507, 524, 542 and 550, tabs 505, 520, 540 and 545, information displays 510, 513, 523, 525, 527, 530 and 543, and selections 535 and 547.

[0295] Information display 503 may include, for example, information related to an application provider. For example, information display 503 may display the name and a brief history of the application provider.

[0296] Tab 505 may be used to display application screen 507 and may include a descriptor associated with application screen 507 (e.g., "How It Works"). Although example embodiments may be described with respect to tabs, persons skilled in the art will appreciate that tabs are used for purposes of explanation only. For example, redirection links may be provided to redirect a user to a configuration screen of an application provider. According to at least one example embodiment, tab 505 may be an information display without tab functionality.

[0297] Application screen 507 may be a configuration and/or informational screen for an application, and may display information explaining a feature provided by the application. For example, application screen 507 may include information indicating that a coupon will be provided to a user once the user meets or exceeds a performance metric.

[0298] A coupon may be, for example, a voucher entitling a user to a discount and/or a rebate. The discount and/or rebate may be associated with a particular product, a purchase from a particular vendor and/or the like. A performance metric may define, for example, a transactional event. For example, a performance metric may include a purchase with a card (e.g., a physical and/or device card), a sequence of purchases (e.g., ten purchases) with a card, and/or spending a target amount with a card. Any purchasing and/or non-purchasing transactional event is contemplated by example embodiments. For example, a performance metric may involve a rate of transactions (e.g., checkout 5 books from a library in 10 minutes), a pattern of transactions (e.g., purchase 10 different items from 10 different stores), a target transaction (e.g., purchase a particular item) and/or the like.

[0299] Application screen 507 may include information displays 510 and 513. Information display 513 may include a representation of a type of reward, for example, an image representing a coupon. Information display 510 may display a representation of a performance metric, for example, a monetary value and a payment method. Accordingly, for example, application screen 507 may indicate that a user of a payment method (e.g., a powered card) may receive a coupon and/or increase the value of a coupon each time the user spends an amount indicated in information display 510 using the payment method indicated in display 510.

[0300] A coupon provided by an application provider may be selected in various ways. For example, a coupon may be randomly selected, may be selected by a user (e.g., from a list of coupons) and/or may be selected based on transactional information (e.g., data related to a purchase, a user purchase history and/or the like). The coupon may be selected prior to or after completion of the performance metric.

[0301] Each coupon may have a face value (e.g., a normal coupon value) and may be increased in value based on a value of the performance metric (e.g., a value to the application provider). For example, where a performance metric includes spending $100, $200 or $300, a value of the coupon may be 200% at the $100 level, 400% at the $200 level and 800% at the $300 level. A user may or may not select a level of the performance metric (not shown).

[0302] Tabs 520 may be used to display application screen 524. Application screen 524 may include, for example, information displays 525, 527 and 530, and selections 535. Information displays 525, 527 and 530 may, for example, display representations of redeemable coupons earned by a user. Selection 535 may be used to change one or more of the coupon representations displayed in application screen 524 (e.g., to cycle through available coupons). A user may, for example, select one of the representations to use the associated coupon for a specific purchase. Additionally and/or alternatively, the coupon may be applied at any time the coupon is usable according to a user selection and/or by default (e.g., a coupon applied to the purchase of a specific product and/or in a specific store as a default).

[0303] Each of information displays 525, 527 and 530 may display information associated with a coupon in addition to, or alternatively to, the representation of the coupon. For example, the information may include a description of the value provided by the coupon, a description of added value to a base value of the coupon, an expiration date of the coupon and/or any other coupon related information (e.g., within the representation and/or beneath the representation). According to at least one example embodiment, each representation of a coupon may be a progress meter. According to some example embodiments, a user may build a coupon by selecting various information (e.g., base value, added value, expiration date and/or the like).

[0304] Tabs 540 may include one or more tabs used to display one or more application screens 542. One of tabs 540 may be used to select an application screen including an information display listing earned coupons. For example, each of information displays 525, 527 and 530 may be selections representing categories of coupons. A user may select information display 525 to display, for example, a list of earned coupons related to food in information display 543. A user may select information display 527 to display, for example, a list of earned coupons related to small appliances in information display 543. A user may select information display 530 to display, for example, a list of earned coupons related to prepared beverages in information display 543.

[0305] According to some example embodiments, a list of earned coupons may also include, for example, unearned coupons. The unearned coupons may be visually distinguishable from the earned coupons (e.g., a different color and/or shading). Each displayed coupon may be, for example, a selection that may be used to begin earning the coupon, retrieve information associated with the coupon and/or the like. According to some example embodiments, more than one of information displays 525, 527 and 530 may be selected simultaneously. [0306] One of tabs 540 may be selected to display a redemption history in information display 543. A redemption history may, for example, display a purchase description and an amount saved. As another example, one of tabs 540 may be selected to display a transaction history. A transaction history may include, for example, information indicating a type of transaction (e.g., purchase), an amount spent, a date of the transaction and/or line items indicating that one or more coupons have been earned in relation to the transaction.

[0307] Tab 545 may selected to display application screen 550. Application screen 550 may include selection 547. Upon selecting selection 547, a user (having met a performance metric) may activate an earned coupon. As one example, a user may select a coupon from among multiple, available coupons and then press selection 547 to render the selected coupon usable. As another example, the application provider may randomly select a coupon earned by the user and the user may press selection 547 to render the randomly determined coupon usable. Selection 547 may include an information display (e.g., "$40 spent, press to redeem for coupon"). According to at least one example embodiment, selection 547 may not be included and a coupon may be automatically activated by the application provider (e.g., based on user settings).

[0308] A user may be notified by an application provider when a coupon is earned and/or additional value is added to the coupon. The application provider may utilize user submitted notification settings to notify the user. Once notified, a user may activate a coupon for a particular purchase and/or for any purchase (e.g., to be used when applicable). Once a coupon is activated, the user may initiate a purchase using a payment method (e.g., powered card) and an activated coupon may be associated to the purchase (e.g., manually and/or automatically associated to the purchase). For example, an application provider may receive transactional data indicating a type of product and/or a location of a purchase, search a list of coupons earned by a user and associate any applicable coupons to the purchase based on the transactional data. If any coupons are associated to the purchase, value may be provided to the user (e.g., via a statement credit), for example, immediately, at authorization, at settlement and/or in a number of days. Alternatively or additionally, the application provider may attach the coupon and/or a number associated with the coupon, for example, to an email. A user may print the coupon and/or use number associated with the coupon (e.g., for an internet purchase).

[0309] Persons of ordinary skill in possession of example embodiments will appreciate that many different notification and reward fulfillment methods may be used. For example, a user may be notified of a reward or receive a reward via email, telephonic data transfer (e.g., text messaging), telegram and/or the like. According to at least some example embodiments, no notification may be provided and/or a user may be required to retrieve a coupon (e.g., via a GUI). According to at least one example embodiment, a coupon may be transmitted to a user's powered card and the powered card may be operable to display a barcode usable at, for example, a retail establishment.

[0310] A selection may be included to activate functionality by which outright purchases of a coupon and/or contributions towards a coupon may be made (not shown). Purchases and/or contributions may be made using, for example, piggyback charges, third party charges, direct purchases and/or the like.

[0311] A piggyback charge may be a statement debit (charge) added to a user statement, for example, for each purchase using a card and/or a device card. A user may select an amount and/or frequency of the piggyback charge using, for example, GUI 502 (not shown). According to at least one example embodiment, a user may earn a coupon and/or increase the value of a coupon for each piggy back charge.

[0312] A third party charge may be a monetary value provided by an application provider, for example, upon a user meeting an incentive performance metric in addition or alternatively to using the payment method (e.g., making purchases at a specific store and/or buying a specific product). A direct purchase may be a partial or complete purchase of a feature by a user that is not attached to any other purchase. For example, a vendor may provide functionality by which a user may swipe a card and/or otherwise communicate data of a card to partially or wholly purchase a coupon without also purchasing any item from the vendor.

[0313] According to some example embodiments, a user may configure an application using GUI 502 to earn coupons and/or add value to coupons not included as a default selection on GUI 502. For example, GUI 502 may include a blank information display (not shown). A feature provider may provide 'drag-and-drop' coupon icons (e.g., on a feature provider website) representing the reward. A user may drag the icon onto GUI 502 and GUI 502 may be automatically modified to include the coupon. The icon transfer may include feature provider information, for example, information invisible to a user that may be used by an application. The coupon provider may provide special incentives for a limited time (e.g., Black Friday), as a customer acquisition tool, as a customer retention tool, and/or the like. The coupon may be a unique coupon not available outside of an ecosystem. [0314] As one non-limiting example, GUI 502 may display a configurable coupon application. A user may select from coupons provided by different retail outlets. The user may drag an icon from a webpage of a particular retail outlet onto the configurable application. The user may drag an icon from a webpage of a different retail outlet onto the configurable application. Both icons may appear on the configurable application. Accordingly, an application may not be limited to a specific retailer and/or coupon provider, and may enhance the whimsical and festive nature of a feature provided to a user.

[0315] An application accessed using GUI 502 may include configurable functionality to improve a user experience. For example, a representation of each coupon earned by the user may be publically and/or privately displayed when earned (and/or a progression display may be updated). For example, coupon information may be displayed on a user's social networking page, on a physical display at chosen location and/or the like. In order to provide configurable functionality, an application provider and/or an application of an application provider may be associated to the user during, for example, an activation process. A user requesting access to an application may be prompted for information. The information may include, for example, security credentials used to access a social networking site associated with the user.

[0316] Selections may, for example, activate an additional and/or alternative feature. For example, a selection (not shown) may be used to pay an amount corresponding to completion of the performance metric displayed in information display 510. As one example, if a user is required to spend $100 to earn a coupon, the value of the feature is $10, and the user has spent $50 using the payment method, the user may pay the coupon provider $5 (the difference in value). The amount may be, for example, immediately charged via GUI 502 and/or may be attached as a piggyback charge to a purchase (e.g., a next purchase using a card and/or a device card). Accordingly, a user may take advantage of limited time offers even where the user does not expect to complete a performance metric within the limited time. The whimsical and festive nature of a coupon application may therefore be enhanced.

[0317] FIG. 38 shows process flow chart 600. An application provider may receive user configuration selections (e.g., as in step 610) and transactional data from, for example, an application manager provider (e.g., as in step 620). The application provider may associate the transactional data with a user and determine if a performance metric has been completed (e.g., as in step 630). If a performance metric has not been completed, the application provider may update one or more information displays based on the received transactional data (e.g., as in step 640). If a performance metric has been completed, the application provider may display a completion message to a user and update one or more information displays (e.g., as in step 650). A value (e.g., coupon) may be transmitted to, for example, the payment method user (e.g., as in step 660).

[0318] According to one non-limiting example embodiment, a coupon provider may receive a user feature selection. The coupon provider may receive transactional information, for example, information indicative of a feature selected by a user (e.g., via a telephone device card, powered card and/or the like) and transactional information related to a payment card (e.g., a number of transactions performed by the user with the payment card, an amount spent and/or the like). Based on the information, the coupon provider may determine if a performance metric has been completed. For example, a performance metric may include ten user purchases using a powered credit card. If the user has not completed ten purchases using the powered credit card, a progression display (e.g., a progress meter) may be updated (e.g., if applicable). If the transactional metric has been met, an email may be sent notifying the user that the coupon has been earned. One or more progression displays may be updated and the coupon may be communicated to the user. According to at least one example embodiment, the notification and coupon may be communicated to the user in the same email message.

[0319] According to at least one example embodiment a coupon code may be communicated to the user. According to at least one other example embodiment, a user may be notified that a coupon code and/or a coupon is available electronically (e.g., accessed from an application manager).

[0320] FIG. 39 shows device 700 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer and/or an electronic tablet) that may include display 701. Device 700 may include a processor that may render GUI 702 onto display 701. GUI 702 may be an application interface usable to manage a user's experience with an application. For example, GUI 702 may be used to configure application settings, receive information from an application provider, communicate information to an application provider and/or the like. [0321] GUI 702 may include, for example, tabs 703, 718, 730 and 763, application screens 707, 723, 752 and 773, information displays 710, 713, 715, 727, 733, 737, 740, 743, 753, 755, 757 and 760, progress meter 725, entry fields 767 and 775, and selections 765, 770 and 777.

[0322] Tab 703 may be used to display application screen 707 and may include a descriptor associated with application screen 707 (e.g., "How It Works"). Upon selecting tab 703, application screen 707 may be displayed to a user. Application screen 707 may be a configuration screen for an application and may include information explaining features provided by the application. For example, application screen 705 may display different configurable, selectable features, along with explanatory information associated with each feature. According to at least one example embodiment, application screen may not be a configuration screen and may be an information screen. A feature may not be configurable and/or selectable (e.g., a set feature) and static feature information may be displayed.

[0323] A feature provided by an application may provide a user selected reward once a user meets or exceeds a performance metric. Alternatively and/or additionally, a feature provided by an application may provide a random reward from a collection of rewards once a user meets or exceeds a performance metric. The reward may be provided by the application provider upon a user meeting or exceeding the performance metric. An example of a performance metric may include a user completing one or more purchases meeting or exceeding a monetary value using a payment card.

[0324] A feature provided by an application provider may be represented by, for example, information displays 710, 713 and 715. For example, information display 713 may display an image representing a collection of different rewards. Information display 710 may display information associated with a performance metric. The performance metric may be, as one example, a transactional based performance metric represented by an image of a payment card and a monetary value. Information display 715 may include information associated with the performance metric and/or the collection of rewards. For example, information display 715 may notify a user that shopping at a particular store will earn additional rewards, and/or notify a user as to the odds of winning any one of the rewards from the collection of rewards. [0325] As one non-limiting example, application screen 707 may include information describing that a user may earn one random reward from a collection of rewards upon spending at least a monetary value (e.g., $6,000) using a payment method (e.g., a smartphone payment card). If the payment method is used to make purchases from a store (e.g., a particular store associated with the application) the amount spent in order to earn the reward may be reduced (e.g., earn a reward twice as fast).

[0326] Upon selecting tab 718, application screen 723 may be displayed to a user. Application screen 723 may include progress meter 725 and information display 727. Progress meter 725 may indicate user progress towards completing a performance metric. Progress meter 725 may be any type of progress meter. For example, a progress meter may be represented as a thermometer with a temperature scale replaced by a monetary scale (e.g., $0- $6,000). By viewing progress meter 725, a user may gauge progress towards a reward. Information display 727 may, for example, display an exact amount spent towards earning the reward.

[0327] A type of progress meter 725 is not limited. For example, an application provider may be an actress named 'Dynama Lemon.' The application provider may display a representation of a lemon. The representation may be, for example, a black and white outline. As progress is made towards completing the performance metric, the representation of the lemon may be progressively colored-in to demonstrate progress.

[0328] Upon selecting tab 730, application screen 752 may be displayed to a user. Application screen 752 may provide details with respect to the representation of the collection of rewards displayed in information display 713, and may include, for example, information displays 737, 740, 743, 753, 755, 757 and 760. Information displays 737, 740 and 743 may each display a representation of, for example, a coupon (e.g., different coupons) and information related to each coupon (e.g., an additional value associated with a coupon when the payment method is used to buy specific products). Information displays 753, 755, 757 and 760 may each display a representation of a tangible item and a description of the tangible item. The coupons and tangible items may be a collection of rewards from which a reward may be randomly awarded to the payment method user upon completion of the performance metric. Selection 765 may be a redemption button that may be used upon completion of the performance metric to receive the random reward. A user may change, for example, notification settings before using selection 765.

[0329] As a non-limiting example, a user may be awarded a random reward from among coupons and tangible items. Examples of coupons may include a coupon providing 5% off purchases of a product, $50 off purchases of $500 or more, 15% off purchases from a specific store and/or retailer, and/or the like. Examples of tangible items may include a makeup kit, a purse, nail polish remover, a ring and/or the like. Each item may be, for example, exclusively available to users of the payment method. Persons of ordinary skill in possession of example embodiments will appreciate the broad scope of different types of rewards that may be provided for use of a payment method and additional value that may be provided to a user upon using a payment method in a particular way (e.g., additional value when using the payment method to buy products sponsored by the application provider).

[0330] Tab 763 may be associated to notification settings. For example, tab 763 may be selected by a user to display entry fields 767 and 775, and selections 770 and 777. Entry fields 767 and 775 may be used by a user to enter information related to the type of notification (e.g., an email address and/or a text message number). Selections 770 and 777 may be used to submit the information entered into entry fields 767 and 775, respectively.

[0331] A user may be notified by the application provider when a reward is earned. The application provider may utilize user submitted notification settings to notify the user. For example, a user may submit an email address using entry field 767 and selection 770. As another example, a user may submit a number (e.g., a telephone number for text messaging) using entry fields 775 and selection 777. A notification email and/or text message may be sent to the email and/or number when a reward is earned. The email and/or text message may include a message indicating that a reward has been earned and that a redemption code usable to retrieve the reward is available. According to other example embodiments, the application provider may attach the redemption code and/or reward to the notification (e.g., embedded in the email). According to still other example embodiments, electronic rewards may be downloaded by clicking, for example, an information display associated with the earned reward (e.g., using an application manager).

[0332] Although example embodiments are described with respect to email and/or text messaging, persons of ordinary skill in possession of example embodiments will appreciate that many different notification methods may be used (e.g., telephonic, text messaging, telegram and/or the like). According to at least one example embodiment, no notification may be provided. According to other example embodiments, a user may provide a physical address at which to receive notifications and tangible rewards. According to yet other example embodiments, a user may submit multiple addresses (e.g., one or more email addresses, one or more telephone numbers, and/or one or more physical addresses) and select one of the addresses prior to redemption such that each reward redemption may result in a different notification or fulfillment (e.g., different rewards and/or notifications may be sent to different addresses at the whim of the user).

[0333] Although example embodiments described in relation to FIG. 7 may include performance metrics based on a monetary value, various other performance metrics are within the scope of example embodiments (e.g., number of transactions, type of transactions, a user acting as a merchant using a particular merchant service and/or the like).

[0334] FIG. 40 shows device 800 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 801. Device 800 may include a processor that may render GUI 802 onto display 801. GUI 802 may be an application interface usable to manage a user's experience with an application. For example, GUI 802 may be used to configure application settings, receive information from an application provider, communicate information to an application provider and/or the like. [0335] GUI 802 may include, for example, tab 805, application screen 807, information displays 810, 820, 830 and 840, and selection 850.

[0336] Tab 805 may be used to display application screen 807 and may include a descriptor associated with application screen 807 (e.g., "Scratch Off"). Upon selecting tab 805, application screen 807 may be displayed to a user. Application screen 807 may be an interactive selection screen for an application.

[0337] A feature provided by an application may provide a user an opportunity to select one reward from among multiple, hidden rewards. For example, a user may be presented with multiple representations of a logo (e.g., an application provider logo) in information displays 810-840. The user may be provided the opportunity to select one of information displays 810- 840 to unveil a reward. For example, a user may select information display 820 to reveal that the user has won a coupon (e.g., 15% off of a purchase).

[0338] According to example embodiments, a user may select two or more of information displays 810-840 and receive a reward associated with each selection. For example, multiple performance metrics may be available to the user. Depending on a value (e.g., cost to the user and/or value provided to the application provider) of the performance metric, a different number of selection may be made (e.g., one selection for $50 in spends, two selections for $100 in spends, etc.).

[0339] According to example embodiments, an application provider may receive a monetary value from, for example, an ecosystem provider, an issuer, a merchant and/or a payment network in exchange for providing a reward to a user. The monetary value may be, for example, a number of basis points (1/100 of a percentage point) related to a transaction. According to some example embodiments, an application provider may not receive a monetary value and/or may provide value. The application provider may receive value, for example, via customer acquisition, retention of customers, marketing (e.g., visibility within an ecosystem) and/or the like. According to some example embodiments, a value provided via a coupon may be greater than a monetary value provided to a coupon provider. A difference in value may be offset by other factors (e.g., high value coupons where 90% of the coupons are expected to expire prior to use).

[0340] A performance metric may be based on transactional processing. Transactional processing may include multiple stages. For example, a credit transaction may include authorization, batching, clearing and funding. An application and/or feature provider may provide a reward to a user at one of the various stages of transaction processing (e.g., authorization). In some cases, a transaction may be reversed (e.g., a void or credit) after a user receives a reward based on the transaction. For example, a user may purchase an item, receive an electronic reward and then return the purchased item. According to example embodiments, the application and/or feature provider may be notified by the application manager provider that a transaction has been reversed. A application and/or feature provider may take action based on the notification, for example, provider may reclaim a coupon, invalidate a coupon code, remove user authorization to use an application and/or feature, establish a debit pool that must be reduced by future uses of the payment method before additional rewards may be earned and/or the like. [0341] According to some example embodiments, a reward may be granted to a user at a stage of transaction processing (e.g., authorization) but may not be available for use by the user until a different stage of processing (e.g., settlement). If a transaction is reversed (e.g., via a return, a charge-off and/or a charge-back) after being made available to the user the application and/or feature provider may take steps to remove a value associated with the coupon. Accordingly, if a card is used fraudulently (e.g., a stolen card), rewards may be disassociated with a reward system when the purchases are charged-off as a result of the fraudulent spend.

[0342] FIG. 41 shows process flow chart 900. According to example embodiments, a rewards provider may utilize an application to configure rewards (e.g., for a rewards or loyalty program). For example, a computing device (e.g., a server) may display an interactive GUI that is usable to define a rewards program via selections and entries.

[0343] Referring to FIG. 41, reward description details may be defined (e.g., as in step 910). For example, a rewards provider may select a type of reward, enter a name for the reward, provide a brief description of the reward and upload an image to represent the reward. [0344] The reward type may be, for example, a coupon, an item, a virtual item, cashback, points, miles, entry into a lottery, and/or any other type of reward. Once a reward type is selected, the GUI may display further options tailored to the type of reward.

[0345] A rewards provider may define reward execution details (e.g., as in step 920). For example, a coupon provider may determine the type of coupon that will be provided to users by selecting various options. The options may determine, for example, whether or not the coupon will be based on a purchase amount or a purchased product, and the type of discount or rebate to be applied. If the coupon will be based on a purchase amount, the type of discount or rebate may include, for example, a percentage or value based discount. If the coupon will be based on a purchased product, the type of discount or rebate may include, for example, a percentage discount, a value based discount or a replace value.

[0346] A rewards provider may set distribution limits for the rewards program (e.g., as in step 930). The distribution limits may define the financial liability that may be incurred by the rewards provider. For example, using an overall limit and/or a per customer limit, a coupon provider may limit the number of coupons that are distributed and/or the maximum value of the coupons (e.g., the value either individually or in aggregate). As one example, a rewards provider may set an overall distribution limit of 1000 coupons and a per customer distribution limit of 5 coupons.

[0347] A rewards provider may define reward execution requirements (e.g., as in step 940). Reward execution requirements may, for example, describe the circumstances under which a coupon is redeemable. For example, coupons redemption may be limited to online purchases or store purchases, or permitted for both store purchases and online purchases.

[0348] If in-store redemption is permitted, the redemption may be limited to a particular store, a set of particular stores, and/or one or more geographical areas (e.g., by zip code, province/state and/or country). Information that may be entered into a GUI by a rewards provider may include, for example, one or more store ID's, store names, zip codes, province/state information and/or country codes.

[0349] Where redemption is permitted online, or online and in-store, reward redemption may be limited to one or more retailers (e.g., Dynamo Sporting Goods), to one or more types of retailers (e.g., sporting goods), by maximum and/or minimum purchase thresholds (e.g., purchase amount thresholds), by duration (e.g., a range of dates), by date (e.g., specific days), by time (e.g., specific hours), and/or by product and/or product group (e.g., to one or more SKU groups).

[0350] Accordingly, coupon redemption may be circumscribed by, for example, location, commercial relationships, cooperative interests, and/or logistical considerations. For example, a retailer may increase traffic through stores at historically underperforming times, days or months, reduce percentage reduction liability that may occur for higher value purchases, and restrict coupons to particular products, manufacturers or types of manufacturers. A retailer with knowledge of customer loading patterns within its stores may limit coupon redemption to particular stores at particular times on particular dates to level workload, control local traffic, synergize with staffing levels and/or increase loading at underperforming stores or regions.

[0351] A rewards provider may define reward usability and compatibility (e.g., as in step 950). For example, a retailer may define how coupons are used together (coupon usability), define the types of payment methods that are usable during a qualifying purchase (purchase types), and/or define the transferability of the coupons (user restrictions). [0352] For example, defining coupon usability may include selecting whether coupons are usable with all other coupons, with specific coupons or only by themselves. Defining purchase types may include selecting payment methods with which a coupon may be used, for example, all payment methods, specific branded payment methods (e.g., store loyalty credit card), cash, prepaid cash, payment methods supported by specific payment networks (e.g., Visa, MasterCard, Discover and/or American Express) and/or the like. Defining user restrictions may include restricting redemption to a designated user or designated users (e.g., the user to whom the coupon was sent) or permitting redemption by any user (e.g., a transferable coupon).

[0353] Although process flow chart 900 includes arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow chart 900 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0354] FIG. 42 shows process flow chart 1000. According to example embodiments, a rewards provider may utilize an application to configure a loyalty program. For example, a computing device (e.g., a server) may display an interactive GUI that is usable to define a loyalty program via selections and entries.

[0355] Referring to FIG. 10, a reward provider may define a description of a loyalty program (e.g., as in step 1010). For example, a rewards provider may select a program type, enter a name for the loyalty program, provide a brief description of the loyalty program and identify one or more rewards provided by the loyalty program.

[0356] The program type may be, for example, a predefined type of loyalty program. Once a reward type is selected, the GUI may display further options tailored to the type of loyalty program.

[0357] A rewards provider may define one or more reward distribution criteria (e.g., as in step 1020). For example, a loyalty program may provide a reward based on a monetary value spent (e.g., number of dollars), a number of visits (in-store and/or online), a number of particular items purchased and/or a number of purchases. [0358] A selection to base a loyalty program on monetary value may include entering an amount of the monetary value at which a reward may be provided. A selection to base a loyalty program on a number of visits may include entering the number of visits before a reward may be provided, and may include entering a number of consecutive days on which the visits must occur (e.g., a date range or a number). A selection to base a loyalty program on a number of purchased items may include entering one or more item types, one or more stock keeping units (SKU), and/or entering a number representing the number of items to be purchased before a reward may be provided. A selection to base a loyalty program on a number of purchases may include entering a number representing the number of purchases before a reward may be provided, and may include entering a minimum spend amount per purchase.

[0359] A rewards provider may set a rewards distribution criteria period for the loyalty program (e.g., as in step 1030). The distribution criteria period may specify a time period in which the loyalty program is deemed to be active and rewards may be earned. For example, a rewards provider may select an option to provide rewards from program inception or enter a date range. According to some example embodiments, a rewards provider may apply a retroactive time period such that historical data may be used to determine whether a reward was earned (e.g., prior to inception of the program).

[0360] A rewards provider may set program earning time constraints with respect to the loyalty program (e.g., as in step 1040). For example, reward earning may be limited such to only specific days, and/or specific days and times. For example, a loyalty program may be implemented to provide loyalty rewards for customers shopping on Black Friday (e.g., November 28, 2014) during non-peak hours.

[0361] A rewards provider may define program run limits (e.g., as in step 1050). For example, a rewards provider may select one or more options that may include running a loyalty program until start and end dates have been met (e.g., a date range), a particular amount of rewards have been generated, a particular amount of rewards have been redeemed, a particular amount of value has been generated and/or a particular amount of value has been redeemed.

[0362] A rewards provider may define program distribution criteria (e.g., as in step 1060). For example, a rewards provider may elect to distribute rewards only to a particular segment of a customer or consumer base. Rewards may be distributed based on psychographics, for example, any personality trait, value, attitude, interest, and/or lifestyle choice (e.g., "gamers," "savers," "sportsters," and/or "child conscience parents"). Award distribution may be based on, for example, gender, age, income and/or products (e.g., one or more SKUs). For example, coupons for geriatric feminine products may be distributed to female consumers by selecting gender and age as a basis for distribution, and entering product SKUs corresponding to the geriatric feminine products.

[0363] Although process flow chart 1000 includes arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow chart 1000 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0364] FIG. 43 shows process flow charts 1100 and 1150. According to example embodiments, a rewards provider may utilize an application to test a loyalty and/or rewards program by providing rewards to all, or one or more segments of, identified consumers (e.g., customers) and monitoring the effect of the reward.

[0365] The effect of the reward may be determined via test result data in multiple ways and may depend on the reward. For example, if a coupon is offered as a reward, transaction data and/or coupon-use data may be monitored to determine if the coupon resulted in a change in consumer behavior. The data may be collected at one stage of transaction processing (e.g., authorization, settlement, and/or the like), each stage or any combination of stages.

[0366] According to some example embodiments, test result data may include segment data from one or more segments receiving a coupon, from one or more segments not receiving a coupon and/or from one or more segments receiving a different coupon (multi-segment testing). Test results may include data from a portion of a segment receiving a coupon and a portion of a segment not receiving a coupon (in-segment testing). Test result data may include data from an entire consumer base (global testing). According to some example embodiments, segment data (e.g., in-segment and/or multi- segment data) collected during the duration of the testing may be compared. According to some example embodiments, before-and-after data may be compared (in- segment, multi-segment and/or global) using collected and historical data.

[0367] Referring to process flow chart 1100, a computing device (e.g., a server) may display an interactive GUI that is usable to describe and/or define test and distribution criteria used in program testing (e.g., as in step 1110). For example, a rewards provider may select a loyalty or rewards program for testing, enter a name of the test, enter a brief description, enter a number of rewards to generate, and/or select a percentage or number of consumers (e.g., customers and/or non-customers) to receive the generated rewards. The selected percentage or number may be applied to an entire consumer base (e.g., 100% where no segments are defined), to segments of a consumer base (e.g., x% where multiple segments are defined) and/or to a single segment of a consumer base (e.g., x% where a single segment is defined). Individual segments may be, for example, defined by distribution criteria.

[0368] A rewards provider may define one or more segments to be used in program testing be selecting or entering distribution criteria (e.g., as in step 1120). A segment may be based on, for example, psychographics. Psychographics may include any personality trait, value, attitude, interest, and/or lifestyle choice (e.g., "gamers," "savers," "sportsters," and/or "child conscience parents"). A segment may be based on characteristics or goods, for example, gender, age, income and/or products (e.g., one or more SKUs). Consumer psychographics and characteristics may be entered by a user and/or determined from transactional data.

[0369] Once all desired parameters for a test are configured, the test may be initiated (e.g., as in step 1130). The coupons may be distributed and data collection begun (e.g., via routing of transaction messages to a remote facility or other entity). At the completion of the test, for example at an expiration date of test coupons, data may be analyzed and results may be provided. Graphs may be displayed to summarize the test results. [0370] According to at least one example embodiment, a test may be repeated one or more times and graphical data may be continuously updated. Repetition may provide temporal or event based effect information (e.g., seasonal habits or the effects of weather). According to at least one example embodiment, tests may be triggered based on events to determine their impact on consumer habits (e.g., geographic testing triggered by a catastrophe).

[0371] Referring to process flow chart 1150, a computing device (e.g., a server) may display an interactive GUI that is usable to simulate a loyalty program or rewards program. For example, a rewards program may be built and simulated to ensure that the rewards program functions according to the reward provider's intended design.

[0372] A rewards provider may select a loyalty or rewards program (e.g., as in step 1160). For example, the reward program may be selected using the reward description (e.g., "incentive coupon"). The program may be, for example, selected from a list of programs. If the coupon includes a barcode, the type of barcode may be selected. A coupon simulation type may be selected. A coupon simulation type may be, for example, a valid coupon or a test coupon. An address (e.g., email address) of a user and a mail server identification may be entered. [0373] The program may be simulated (e.g., as in step 1170) by, for example, selecting to send one or more test emails (e.g., in a case where coupons are distributed by email), or by entering condition settings and selecting to simulate the program based on the condition settings. A condition may include, for example, maximum liability. The simulation may determine, based on the rewards program, the maximum liability where the maximum number of coupons are distributed and used. Alternatively, percentage of use assumptions and the like may be entered to determine a resulting liability based on the assumptions. In general, conditions may include any parameter used to determine the result of a defined rewards or loyalty program.

[0374] Although process flow charts 1100 and 1150 include arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow charts 1100 and 1150 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0375] FIG. 44 shows process flow charts 1200 and 1250. Process flow chart 1200 may provide an example of the implementation of a rewards program and process flow chart 1250 may provide an example of the implementation of a loyalty program.

[0376] Referring to process flow chart 1200, a computing device (e.g., a server) may display an interactive GUI usable to define a rewards program (e.g., as in step 1205). A remote facility may receive rewards program configurations (e.g., as in step 1210) from, for example, a third party provider (e.g., a retailer). Based on the defined program, the remote facility may distribute rewards according to the program definition. For example, the remote facility may distribute coupons to all customers within a demographic (e.g., globally, by segment, by partial segment and/or the like).

[0377] The rewards may be distributed physically (e.g., by mail, courier, in-store and/or the like) and/or non-physically (e.g., via electronic mail, telephonically, SMS messaging, television, social networking and/or the like). For example, a server of a remote facility may receive or pull data from a server of a third party provider, and based on the data distribute coupons to consumers via electronic mail. [0378] The remote facility may receive reward redemption information (e.g., as in step 1220). For example, the third party provider may communicate coupon redemption information to a remote facility (e.g., an ecosystem provider), and/or the remote facility may receive transactional data from one or more network entities in a transactional flow. The transactional data may include, as one example, an authorization message. [0379] The reward redemption information may include, for example, coupon identification information, user information, location information, product information, establishment information (e.g., store ID), purchase price information, and/or any other transactional data. The remote facility may determine if the coupon is valid based on the reward redemption information and a rewards program. The remote facility may, for example, determine if the coupon is recognized as active for a rewards program, and if the coupon redemption meets the requirements of a rewards program. [0380] For example, a rewards program may provide a discount that is only valid at a particular store, on a particular date and for a particular user. The remote facility may receive an authorization message that includes identification of a coupon and determine if the coupon is active for any rewards program. If the coupon is active, the remote facility may compare received transactional information against the requirements for the rewards program.

[0381] Based on the validity determination, the remote facility may provide validation information (e.g., as in step 1225) to a third party provider, a merchant terminal, an issuer, and/or other entity. For example, if the coupon is active and the transaction complies with the requirements of a rewards program, the remote facility may communicate information indicating that the discount or rebate may be applied to the transaction. If the coupon does not meet one or more criteria for redemption, the remote facility may indicate that the discount or rebate should not be applied to the transaction. Although example embodiments are described with respect to real-time processing, validation may occur after a purchase, for example, based on settlement. [0382] Referring to process flow chart 1250, a computing device (e.g., a server) may display an interactive GUI usable to define a loyalty program (e.g., as in step 1255). A remote facility may receive loyalty program configurations (e.g., as in step 1260) from, for example, a third party provider (e.g., a coupon provider).

[0383] The remote facility may receive transaction data. Based on the transaction data, historical data and a loyalty program definition, the remote facility may determine loyalty program applicability and performance metric status (e.g., as in step 1265).

[0384] For example, a server of a remote facility may receive or pull data from a server of a third party provider, or receive transactional messages from an entity within a purchase flow (e.g., as described with respect to FIG. 35). The transactional data may evaluated to determine if a loyalty program applies. For example, a loyalty program may award a coupon to users of a particular loyalty credit card that fall within a particular demographic. The remote facility may evaluate the transactional data to determine if a performance metric has been met. For example, the performance metric may include completing 10 purchases of a particular product using the loyalty credit card. The historical data may indicate that the user has previously purchased the particular product 9 times and the current purchase completes the performance metric.

[0385] A reward may be distributed as defined in the loyalty program (e.g., as in step 1270). If the performance metric has been met, a discount may be automatically applied to the transaction by communicating a message (e.g., to a point-of-sale device) and/or a coupon may be communicated to the user.

[0386] Where a coupon is communicated to a user, the remote facility may receive reward redemption information (e.g., as in step 1275) upon use of the coupon. For example, the third party provider may communicate coupon redemption information to the remote facility, and/or the remote facility may receive transactional data including reward redemption information from one or more network entities in a transactional flow. The transactional data may include, as one example, an authorization message. [0387] The reward redemption information may include, for example, coupon identification information, user information, location information, product information, establishment information (e.g., store ID), purchase price information, and/or any other transactional data. The remote facility may determine if the coupon is valid based on the reward redemption information and the loyalty program definition. The remote facility may, for example, determine if the coupon is recognized as active for a loyalty program, and if the coupon redemption meets the requirements of the loyalty program.

[0388] For example, the loyalty program may provide a discount or rebate that is only valid when used during specific hours in a particular country. The remote facility may receive a message (e.g., a settlement message) that includes identification of a coupon and determine if the coupon is active for any loyalty program. The remote facility may compare the received transactional information against the requirements for the rewards program. For example, the remote facility may determine if the coupon is being used during the specific hours and in the particular country, as required by the loyalty program. If the coupon is active and the requirements of the loyalty program are met, the coupon may be determined valid. Otherwise, the coupon may be determined invalid.

[0389] Based on the validity determination, the remote facility may provide validation information (e.g., as in step 1280) to a third party provider, a merchant terminal, an issuer, and/or other entity. For example, if the coupon is valid, the remote facility may communicate information indicating that the discount or rebate may be applied to the transaction. If the coupon is not valid, the remote facility may indicate that the discount or rebate should not be applied to the transaction. Although example embodiments are described with respect to settlement processing, validation may occur, for example, at authorization (or any other stage of processing).

[0390] Although process flow charts 1200 and 1250 include arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow charts 1200 and 1250 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described processes to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that if a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file). According to example embodiments, cards, ecosystems, third party applications, testing, simulation and transaction flows may be included in the implementation of a reward or loyalty program.

[0391] Example embodiments described with respect to process flow charts 1200 and 1250 are not limiting of example embodiments, but serve as examples. Various transactional flows and systems may be implemented in various ways (e.g., as described with respect to FIG. 3). Although specific entities may be used to describe example embodiments in relation to FIG. 12, various entities may perform one or more functions of other entities, and the particular entities used to describe

FIG. 12 are not limiting.

[0392] A value document (tangible or intangible) may be used to generate demographic information to understand consumer behavior by providing, for example, incentives to purchase, reductions in the price of particular items, free samples, and/or the like. For example, a value document may provide free shipping, buy-one get-one, trade-in for redemption, a coupon for a first-time customer, free trial offer, launch offer, special event offer and/or free giveaway. A value document may be, for example, a coupon providing $5.00 off a $10.00 purchase, and the coupon may be represented by a two or three dimensional barcode. A price conscious consumer may, for example, present a coupon to check out at a merchant, and the merchant may retain the coupon and offer the consumer a loyalty card during the check-out process. Consumer acceptance of the loyalty card may be low.

[0393] According to some example embodiments, a value system may issue an value identifier to influence consumer behavior for loyalty or advanced coupon features. For example, a value system may provide a multistage value account identifier which is individualized based on use of the multistage value account identifier. The multistage value account identifier may be, for example, a single code (e.g., represented by a barcode). The multistage value identifier may be associated to a multistage value account. According to example embodiments, the multistage value account may or may not be associated with a particular user.

[0394] A multistage value account may be associated with a defined or undefined set of stages. A stage may require, for example, a particular action (e.g., a purchase or a game move). For example, at a first visit to a retailer, a user may present a multistage value account identifier to receive $5.00 off a $10.00 purchase, and at a second visit receive $10.00 off a $20.00 purchase, and at a third visit receive $15.00 off a $20.00 purchase and at a fourth visit receive a free sandwich along with a message announcing that the user of the multistage value account identifier has achieved status and will be provided a card (e.g., gold status card) upon providing user information (e.g., a telephone number, email address, physical address and/or other information associated with the consumer). The card may, for example, represent a conventional loyalty program, specific privileges and/or expand the benefits provided by the multistage value system (e.g., with increasingly individualized customization based on information obtained from redemption associated with the stages of the multistage value account and/or based on user information).

[0395] User information may be requested via, for example, a retailer POS system, a method specified by the POS system, a receipt and/or an online purchase confirmation. According to some example embodiments, a user may receive an advertisement including a multistage value account identifier or method of obtaining a multistage account identifier, along with information indicating that upon achieving a particular stage the user is eligible for a status card upon submitting user information (e.g., to a website URL). According to at least one example embodiment, use of a multistage value account identifier may be conditioned on consent by the user for access to user information, for example, user information stored by a merchant, acquirer, issuer, processor, payment network, third party service provider, remote facility, device provider, mobile service provider and/or any other entity.

[0396] A multistage value system may be an implementation of an abbreviated (mini) loyalty program or an introductory loyalty program and a user may be seamlessly converted from the multistage value account to a value program. For example, a user may be converted to a loyalty card representing an extension of the multistage value system, or a different and/or traditional loyalty program. Consumer acceptance of the loyalty card may be increased and/or high as compared to conventional program offerings at checkout.

[0397] According to some example embodiments, one or more stages of a multistage value account may expire. According to other example embodiments, no stage of a multistage value account expires. According to still other example embodiments, one or more stages of a multistage value account may include a change date after which a different value is offered to the consumer.

[0398] According to some example embodiments, a consumer may be offered a choice of value from a pool at a first stage. According to other example embodiments, a choice may be presented to a user at one or more stages or every stage of a multistage account. According to still other example embodiments, no choice is offered to the user.

[0399] Machine learning may be applied to determine the value or pool of values offered at one or more stages of a multistage value account based on, for example, previous value selections by a user, use of the multistage value account identifier (e.g., redemption data), information submitted by a user, demographic data and/or any other information relevant to individualizing value to a user of a multistage value account.

[0400] Artificial intelligence may, for example, provide a multistage value system subscriber segmentation including groupings or patterns within a customer base of the subscriber. According to some example embodiments, the multistage value system subscriber may be offered choices of values to be offered to a user at one or more stages based on segmentation. A multistage value system subscriber may be, for example, a game company, issuer, processor, acquirer, payment network, merchant, property owner (e.g., mall owner or strip mall owner) and/or an affiliate of a collection of merchant brands subscribing to, or operating, a multistage value system. A multistage value system may according to at least some example embodiments be provided by a third party from a remote server.

[0401] A value offered to a user during one or more stages of a multistage value account may be the result of, for example, an online game or games (e.g., game scores). A value offered during one or more stages may be random, for example, the result of a virtual scrath- off.

[0402] The system may be a merchant, cross-merchant, product and/or issuer centric system. For example, a merchant multistage value system may offer a user a value at each of multiple stages, the value usable or in exchange for, among other things, making purchases from the merchant, making purchases from different stores of the merchant and/or purchasing different preferred products from the merchant. [0403] As another example, a cross-merchant multistage value system, which may be provided by, for example, an issuer, and may offer a user a sequence of values corresponding to a sequence of purchases from different merchants. For example, a user may be provided values usable or in exchange for making a purchase at a first merchant at a first stage, at a second merchant at a second stage, a third merchant at a third stage or any combinations of merchants with or without repeats. Stages may be related to, for example, non-competitive merchants, merchants familiar to one another, merchants selected according to machine learning and/or combinations thereof. According to at least one example embodiment, a multistage value account may include stages related to companies adverse to each other with the stage placement based on preferences of a multistage value system subscriber.

[0404] A user may be offered value for making a sequence of purchases of a particular product or a product from a family of products (e.g., for purchases of different flavors of a particular brand of ice cream). A user may be offered a single value for making a purchase at a sequence of vendors, either additional to values provided at one or more individual stages of the sequence or otherwise.

[0405] According to at least one example embodiment, a multistage value system may be used to induce user behavior. For example, a user may be offered value for travelling to specific geographic areas (e.g., malls, shopping districts, community revitalization projects) or different geographic locations (e.g., game vendor, amusement park locations, recreational facilities). [0406] The multistage value system may be, for example, provided via a server of a merchant, acquirer, issuer, processor, payment network, third party service provider, remote facility, device provider, and/or any other entity. A multistage value account identifier may be obtained in any manner value offers may be made. For example, a multistage value account identifier may be printed as a barcode on a receipt. Alternatively, for example, a user may obtain a generic identifier, submit the generic identifier and receive a multistage value account identifier. For example, a user may take a picture of a generic identifier in a newspaper or a screenshot of a web based advertisement, text or email the picture to a number provided in the newspaper or advertisement and receive a multistage account identifier in return from that number. Persons having ordinary skill in the art in possession of this specification will understand that many different ways of providing an identifier are achievable and contemplated

[0407] According to some example embodiments, a multistage value account may offer value based on a number of stages completed within a period of time (e.g., one month) and/or may change value based on the length of time between stage completion and/or may change the value based on the average length of time between completion of multiple stages and/or provide value based on a period of time in which all stages are completed. [0408] According to example embodiments, a multistage value account identifier may be the same for all stages, different for groupings of stages or different for each stage.

[0409] Figure 13 is an illustration of a process flow chart constructed in accordance with the principles of the present invention. Referring to FIG. 13, a server may receive a multistage value account identifier (e.g., a coupon identifier of a multistage coupon) and at least a portion of purchase transaction information (Step 1305). The server may use the multistage value account identifier to access multistage account data associated with the identifier, obtain a current stage associated with the multistage value account and a stage threshold, and determine that the current stage is equal to or greater than the stage threshold (Step 1310). The server may verify that the purchase qualifies a user of the multistage value account identifier to receive a value associated with the current stage based on the purchase transaction information (Step 1315). The server may communicate a message indicating the earned value and eligibility for a loyalty card associated with the multistage value account based on the threshold (Step 1320). User information may be received by the server in response to the message (Step 1325).

[0410] According to example embodiments, a multi- stage account may be associated a number of stages that may be completed in any order. For example, one stage may provide a free coffee upon purchasing a dinner from Dew-Rain-Dew Restaurant, or in real-time, for example, upon ordering, such that the coffee is enjoyed as part of the experience. A second stage of the multistage value may provide, for example, a free biscuit with breakfast, and a third stage may provide, for example, a free side with an entree at lunch. Upon completing all three stages, the user may receive an all-stage completion reward, for example, a $10 gift card.

[0411] According to some example embodiments, an employee of Dew-Rain-Dew Restaurant (e.g., a waitperson) may accept a multistage value account identifier at any portion of the dinner meal. For example, the employee may scan a QR Code displayed on a phone of the customer. The QR code may include the multistage value account identifier and may be uploaded to a remote server along with a merchant code indicating a purchase of a qualifying dinner. As another example, the customer may be provided with an SMS number (e.g., a dynamic number that changes based on time) linked to such a remote server and associated with Dew-Rain-Dew restaurant, such that the multistage value account identifier may be texted to the remote server and the purchase of the dinner confirmed simultaneously. As yet another example, the customer may not possess, and may be provided with, a multistage value account identifier for a new, unused account, for immediate or future use. According to at least one example embodiment, a merchant may permit back credit for previously purchased products (e.g., previous meals purchased from Dew-Rain-Dew Restaurant) and may provide a URL linked to a web GUI for managing a multistage value account.

[0412] The remote server may keep track of the stages and their completion regardless of the temporal order of completion. For example, the remote server may receive the multistage value account identifier and a merchant flag indicative of a stage, and update the multistage value account to reflect stage completion. The remote server may communicate with merchant systems to affect application of the value, and if all-stage completion is achieved, provide value and/or notice to the multistage value account user. For example, the remote server may communicate with Dew-Rain-Dew Restaurant's register or billing server such that the free coffee is properly accounted for in the bill and if all-stage completion is achieved, provide notice to the multistage value account user (directly or through Dew-rain-Dew's employee).

[0413] Figure 14 is an illustration of a process flow chart constructed in accordance with the principles of the present invention. Referring to FIG. 14, a user may scan a QR Code using a phone application (Step 1405). A server may receive a multistage value account identifier from the phone application and access the multistage account data associated with the identifier (Step 1410). The server may determine that the account is flagged for stage completion in any order and obtain stage completion data associated with the multistage value account (Step 1415). The server may communicate the flag and data to the phone application (1420). The phone application may display a list of stages showing which stages are complete, which stages are yet to be completed or a combination thereof, and may display stage requirements and values for uncompleted stages, and display a value associated with completion of all stages (1425). Accordingly, the user of the multistage value account may at any time check which stages are yet to be completed and verify the all stage completion reward, adding to the festive nature of the multistage value account.

[0414] According to at least some example embodiments, software and/or hardware may be included in, for example, a point-of-sale (POS) terminal that identifies a barcode. For example, a POS terminal may identify a QR code as being a QR code for a specific action, such as to authorize payment for a transaction.

[0415] The barcode, such as a QR code, may identify routing information for that barcode. The barcode as well as additional data, such as basket level purchase data and other data associated with a transaction (e.g., tax amount) may be communicated to the routing identity in the barcode. According to at least one example embodiment, the barcode may identify routing information and include the additional data.

[0416] The barcode and/or associated data may be routed to the routing identity for further processing. Persons skilled in the art will appreciate that multiple barcodes may have been utilized with a purchase. For example, one or more coupon barcodes may have been used for discounts, a loyalty barcode may have been utilized for loyalty account identification, an installment barcode may identify a user's desire to pay for a purchase in installments, a points barcode may indicate that a purchase is to be paid with points (e.g., loyalty points) and a payment barcode may have been provided to complete payment for the transaction.

[0417] According to at least one example embodiment, a barcode, such as a QR code, may be encoded in a manner to convey a greater amount of data than a conventional QR code, using for example a high capacity QR format (e.g., 177 x 177), multi-level data, data compression, or defined combination function flags. Mmultiple QR codes may be condensed into a single QR code. For example, a user may provide a POS terminal with a QR code that includes payment routing, loyalty, discount, installment, and/or points information, and/or other information. A QR code may, for example, indicate combinations of QR codes to be communicated to a routing identity (e.g., a payment QR code with an installment QR code for a third party installment plan provider to define an installment plan). [0418] According to some example embodiments, each barcode may initiate a different process and information may be routed to those different processes (either in parallel or in serial). The identification of the type of process (e.g., coupon, loyalty, payment, installment, points) may be determined at the point-of-sale terminal or at a routing identity. All such barcodes may have the same routing identity or a different routing identity. [0419] The system at the routing identity may receive, for example, all information, including all barcodes, and may determine the type of each barcode and initiate processes based off that determination.

[0420] For Payment, the type of the barcode may be identified as a payment type. The barcode may then include additional identifying information, such as the payment network for the payment account, the bank for the payment account, the user's account from that bank account, and additional discretionary data. In that discretionary data may be a dynamic security code that changes with every use. Accordingly, different barcodes may be provided by a device (e.g., a phone, watch, or battery powered card with a display) to make a payment at a store (e.g., via a point-of-sale system) and each of those barcodes may be associated to the same payment account from the same payment network and issuing bank with the difference being, at least in part, dynamic security data. For discount ... For loyalty ...

[0421] Persons skilled in the art will appreciate that magnetic stripe information could be, for example, represented as a barcode. A dynamic magnetic stripe security code, may be provided as part of the dynamic magnetic stripe data. Such data may be communicated to a point-of-sale terminal, identified and routed to that identified process, and the identified process may replace the barcode with magnetic stripe data, or generate magnetic stripe data, and may communicate this information to a payment network and perform an authorization process for that magnetic stripe data with a payment network. Persons skilled in the art will appreciate that a token may be utilized, such as a token issued by a token issuing entity, as the data for payment authorization.

[0422] Upon approval of the payment data, a message may be sent back to the point-of-sale terminal that causes the transaction to be completed. This can be done in many ways. For example, an amount of value may be stored in escrow and the point-of-sale terminal may be provided with indication that stored value is being utilized for the purchase amount and, after the transaction completes, the merchant's account may be deposited with the amount of the purchase. As such, the merchant may get access to funds quickly after a purchase transaction occurs.

[0423] As per another example, merchants may enter into contracts to accept the payment network's issuers barcodes for various types of payment (e.g., debit, credit, pre-paid) and transactions may be authorized and merchants paid within these terms.

[0424] Bank issuers may include their own wallets that run their own cards as dynamic barcodes, such as dynamic QR codes. Phone manufactures may find such features difficult to block as such features do not include the use of secure hardware on the devices.

[0425] The barcodes may be generated locally using local algorithms (e.g., stored in white box crypto approaches on the phone applications) or may be retried from a third party (e.g., retrieved and stored from a secure cloud). Such barcodes may be retrieved in batches (e.g., of 5 or more, 10 or more, 100 or more, etc). Such barcodes may be deleted after use so that the information is not retained on the device in any form.

[0426] A multi-issuer and multi-network wallet may be provided that permits a consumer to load in dynamic barcodes from various issuers. A user may be able to enter in his/her payment information either manually or via a phone (with an OCR component of an application reading information from the picture of the card). A token service may then be called to obtain an eligible payment token for the card. This token may be converted into a static or dynamic QR code.

[0427] Persons skilled in the art will appreciate that software may be included in point-of-sale terminals to recognize the barcode (e.g., as a Dynamic Payment Barcode) and the information to complete a transaction (e.g., payment total, basket level data of items purchased, tax information, etc) may be communicated to a dynamic payment process. The dynamic payment process may check to determine if other barcodes are utilized (e.g., a coupon barcode, loyalty barcode, etc.) and all barcode may be processed in order to properly complete a transaction. The barcode may identify the network and the appropriate information for that network may be communicated to obtain authorization of the payment information.

[0428] A decline may be received from the network and cause a decline communication to be sent to the point-of sale. [0429] An approval may be received from the network and cause an approval communication to be sent to the point of sale.

[0430] Additional information may be sent to the network, such as additional information to assist with other processes such as fraud detection and marketing insight evaluation.

[0431] Persons skilled in the art may appreciate that the identification steps may be included in the point- of-sale. Persons skilled in the art will appreciate that a point-of-sale may simply be the phone itself. A consumer may send a barcode from his/her phone to another phone and that phone itself may authorize the barcode and act as a barcode point-of-sale and/or identification and payment authorization process.

[0432] Super Smart Secure Payment Applets With Pre- Stored Messages and Logic and Ability To Change Subsequent Function Thereon

[0433] A payment card or other device such as a payment phone or watch, can interact with a point-of-sale terminal to complete a transaction. Multiple stages of communications from the payment device to the payment terminal and from the payment terminal to the payment device can be provided so that each device or process can identify itself to each other, securely confirm the other identity is authorized to conduct a transaction, and provided information for the authorization of a payment transaction. The point-of-sale terminal may route such communications to/from a merchant processor which may route parts of the communication to/from a payment network process, which may route part of the communications to/from an issuing processor that issued the payment device to the end consumer. [0434] The transaction may be communication between the payment device and point-of-sale terminal, for example, a contact chip connection, a contact or wireless magnetic stripe connection, a contactless connection, or through a visible connection such as a single-stage or multipl-stage barcode or QR code. A multiple-stage barcode may be a barcode that changes the information displayed throughout a payment transaction process so that multiple different types of information are displayed at different times over the same display area. [0435] During a transaction, a payment device may request information. This information may include, the amount authorized, additional monetary amounts, the country code of the terminal, the terminal verification results, the transaction currency code, the transaction data, the transaction type, the data authentication code, the iCC dynamic number, the CVM results, the transaction time, merchant custom data, transaction date, tvr, unpredictable number, whether the transaction was authorized or declined, or any type of data retrievable by the payment card.

[0436] A payment card may be battery-powered or non- battery powered and may include buttons to permit a consumer to select different payment accounts (e.g., debit, credit, pre-paid), payment options (e.g., pay with points, pay with equal monthly payments such as 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 36, 39, 42, 45, or 48 monthly payments, or other payment features (e.g., a password- entry system where a correct password is needed to use the card to complete a purchase).

[0437] The payment devices may include multiple processors - such as a general processor for managing the general operation of the device and a payments processor or secure memory element for managing all or part of the payment data and payment process of the device.

[0438] Data not associated with the direct authorization of a payment may be copied from information requested from the payment device and stored and utilized for non-payment or payment features.

[0439] For example, a card may have a display such as a pixelated display operable of displaying a cardholders payment network logo, cardholder name, payment account number, payment expiration date, payment security code for online transactions (e.g., CVV2, CVC2), card name, and other pieces of information.

[0440] Messages associated with a particular time and/or date may be pre-stored. For example, messages associated with an anniversary date of the issuance of the card, consumer birthday information, country holidays, religious events, or any notification or message associated with a particular time or date. For example, a message wishing the consumer a happy birthday and providing the consumer with a QR code coupon for a certain amount in value may be displayed based on a date received during a payment transaction (and, for example, a clock in the payment device that updates the stored date as time passes). Persons skilled in the art will appreciate that a birthday event may trigger a feature such as a game feature where a consumer gets to pick a gift box from a number of gift boxes where each or one ore of the gift boxes has a different amount or type of value stored in it. Accordingly, a marketing campaign may be provided where on your birthday you have the chance to win a statement credit for your payment card bill in different amounts based on, for example, an instant no- purchase necessary sweepstakes where on the cardholders birthday the cardholder is provided instant statement credit value based on different odds of receiving different amounts of value. Pre-stored messages based on time could be provided so that a different message is released at a particular time (e.g., 9am EST) every day. Date-based messages could include for example, new years, Christmas, Ramadan, each day of hannakah, memorial day, independence day, election day, etc.

[0441] Messages may be displayed on the payment device for example based on the first authorized transaction after a certain date/time. For example, a message may be pre-stored and displayed on the first authorized transaction after the first year of being issued the payment device or payment account on the payment device. [0442] Payment devices, such as payment cards, may include, for example, one or more displays, light emitting diodes, programmable magnetic stripes that can change the magnetic stripe data on the magnetic stripe, programmable EMV chips, programamble contactless chips, cellular chips and antennas for downloading data from a remote source, manual interfaces, sound interfaces, etc

[0443] Security features may be provided based on the received data. For example, a dynamic security code may be changed based on time and/or date information received from the payment device during an authorization transaction on a two-way authorization process (e.g., via an EMV or contactless transaction). The dynamic security code may provide a dynamic in-stripe security code (e.g., CVC1/CV1) and on-line security code (e.g., CVC2/CVV2). They may be the same or different security codes based on time and/or date or other information received and multiple types of information received (e.g., a different code may be provided based on time and country information received during a payment transaction).

[0444] Pre-stored messages may be provided based on any information received such as, for example, country code. A welcome message may be provided after a consumer makes a payment transaction in a new country that welcomes the user to the country and provides the consumer with payment information (e.g., exchange rates) based on that country. After each authorized transaction, for example, a card may display information on the transaction (e.g., amount of the transaction) in both the local and foreign currency by using information received and/or logic on the card.

[0445] Transaction applets may be provided that changes the account or payment option information based on what was received during the transaction. For example, if a US card account is utilized in Spain then the card may change the account to a Spanish account for future transactions (unless otherwise directed by the cardholder). In doing so, the payment device can receive information and change the way the payment devices operated based on the received information.

[0446] Any information could enable a new account (e.g., debit credit) or payment option (e.g., EMI, pay with points) for the current or a future transaction. A card can terminate a transaction based on information received and start a subsequent transaction (e.g., by having the cardholder remove and replace the card in a chip contact reader or reinstitute a new contactless transaction, etc. Persons skilled in the art will appreciate that payment terminals can be constructed to reinstitute transactions automatically if a transaction fails. [0447] Example types of information receivable to cause modification of an applet, or by an applet, may include, for example:

Amount, Authorized (Numeric)

Amount, Other (Numeric) Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Data Transaction Type Data Authenticiation Code ICC Dynamic Number CVM Results Transaction Time Merchant Custom Data Transaction Currency Code Transaction Date Transaction Type TVR Unpredictable Number

[0448] According to example embodiments, methods of personalization and personalization updates to credit cards in the field are disclosed.

[0449] Perso Data Encryption. According to some example embodiments, encrypted personalization data may be sent over a transmission link (e.g., cell network, Bluetooth, NFC, etc.). A perso data block may have a unique session identifier preprogrammed into a secure element (SE) which may be used as part of an decryption process.

[0450] Data may be encrypted at multiple levels. For example, a two level embodiment may include transmission link encryption. An entire block of perso data may be encrypted (e.g., 3DES, AES, etc.) during transmission. This block may be decrypted by, for example, a general purpose processor (GP). The GP may use a unique Session Identifier to request the transmission decryption key from the Secure Element.

[0451] Such a two level embodiment may further include encryption of sensitive perso data (personal data of a cardholder) - sensitive perso data such as UDKs may be encrypted such that they will never be in the clear. This information may be sent encrypted to the SE (such as a secure element chip) and may be decrypted inside the Secure Element. This decryption process may be performed by an applet installed on the SE.

[0452] Cards may be preloaded with sets of keys in the SE that are associated with: Transmission Link Key - This key may be utilized by the GP to decrypt the entire perso data block that was received. The GP may provide the unique session identifier provided with the perso data Block to the SE such that the appropriate key can be provided. Multiple unique transmission keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades can be performed over the life of the card. This process may be protected from attacks by, for example, only allowing three attempts to request the transmission link key and if the proper unique session identifier is not provided within three attempts, the process may be blocked going forward. Sensitive Perso Data Key - This key may be utilized by the SE to decrypt sensitive perso data. The unique session identifier may be provided to the SE to be able identify the proper preloaded keys to decrypt the sensitive perso data. Multiple unique sensitive perso data keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades may be performed over the life of a card. This process may be protected from attacks by only allowing three attempts to provide a unique session identifier and if the proper unique session identifier is not provided within three attempts, the process will be blocked going forward.

[0453] Preloaded Perso Data. Acording to some example embodiments, preloading either multiple entire sets of perso data or multiple partial sets of perso data (which may be unique to this card) which may be triggered to be used by sending a signal to the card over a transmission link (e.g., cell network, Bluetooth, NFC, etc.) to change account information.

[0454] Complete sets of Perso Data - Multiple sets of Perso Data which may include changes based on an update to PAN sequence number only or entirely different PANs can be preloaded on the SE. Each of the accounts may be associated with a Unique Account Identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the Unique Account Identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[0455] Partial Sets of Perso Data - In order to minimize the amount of data preloaded, only the unique data associated with an account upgrade (PAN, UDKs, certificates, etc.) may be preloaded. Multiple partial sets of Perso Data which may, for example, include changes based on an update to PAN sequence number only or entirely different PANs may be preloaded on the SE. Each of the Partial Sets of Perso Data may be associated with a unique account identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the unique account identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that Account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[0456] Referring to FIG. 15, a slider may be used to select different features instead of, for example, a button. A slider may have any states such as for example, two states, three states, four states, or more than four states. For example, a slider may have multiple stopping positions and each stopping position may be associated with a different account, payment option, or other feature.

[0457] A slider may not be associated with a supplemental visual indicator (e.g., a light emitting diode and/or display) as the slider itself may be the visual indicator. As a result, for example, a slider oriented card may be have a reduced cost. A slider oriented card may have, for example, no battery and may not be battery powered. Instead, for example, a slider may provide a control signal to a processor (e.g., a contact payments chip such as an EMV chip and/or a contactless chip). Accordingly, a card may be placed in a contact EMV payment card reader and the reader may deliver power to the EMV chip, and associated electronics. Firmware in a payments chip, and/or associated electronics/firmware (e.g., electronics/firmware coupled to a payments chip), may utilize the control signal(s) from the slider to determine the position of the slider. In doing so, the firmware may utilize a different option and/or payment account and/or feature for the card when it is used in a payment card reader. Accordingly, for example, a cardholder may slide a slider switch (or another stationary switch that can mechanically retain a state such as a lever switch or a push-button switch) to a desired option (e.g., credit account, debit account, pay in 6-month equated monthly installment (EMI, 12-month EMI, 18-month EMI, 24 month EMI, 30 month MEI, pay with rewards, etc.). Such a non battery powered card may include, for example, a static magnetic stripe. The static magnetic stripe may, for example, have a payment card account number of the highest interchange payment card account on the card (e.g., or the lowest interchange payment card account on the card). A single EMV chip may include contact (e.g., for contactless readers) and contactless (e.g., for contactless readers). A contactless RF field may, for example, power the chip such that firmware associated with a slider, or other stationary position switch, may be retrieved. A battery may be included, for example, to assist with certain types of payments (e.g., contactless payments) and that does not assist with other types of payments (e.g., contact payments). Accordingly, contact reader power may be utilized to power an electronics package to run slider-selected options when in the contact reader (e.g., EMV reader) and a battery may be utilized to power an electronics package to run slider-selected options when in a contactless reader (e.g., EMV contactless reader). Persons skilled in the art will appreciate that an electronics package may include a recharging circuit (e.g., a recharging chip) to recharge any battery on the card when the card is, for example, receiving power from a contact reader (e.g., an EMV contact payment reader) or a contactless reader (e.g., an EMV contactless payment reader).

[0458] FIG. 5 shows card segment 1500 that may include aperture 1501, slider base 1502, and slider handle 1502. Persons skilled in the art will appreciate that slider base 1502 may be larger than aperture 1501 and may be in a cavity so slider base 1502 may slide. Conductive contacts may couple with conductive wires on an electronic circuit board of an electronics package when slider base 1502 is moved into different positions by slider handle 1503. Persons skilled in the art will appreciate that an aperture may be an aperture in a plastic skin of a card and may be opened via an etching process such as a laser etching process. A circuit board may have a material (e.g., gold) that reflects a laser so that the circuit board is not damaged during etching. Structured may then be added, or may already be present on the circuit board, to receive a slider switch. Alternatively, for example, a slider switch may be coupled to a circuit board and the card may be laminated. Lamination may then be removed using a process such as, for example, a process that removes laminate over the switch. Slider handle 1503 may be an impression instead of, for example, an extrusion. In doing so, a slider switch handle may not extend above the surface of a card. Alternatively, for example, a slider switch handle may extend above the surface of a card.

[0459] Printed indicia (e.g., position markers and/or labels) may be printed on the card to indicate the states of slider switch base 1502. Any number of states may be selected from one or more slider switches.

[0460] Card 1510 may be provided and may include a slider switch to select between two states (e.g., a credit account for one state and a debit account for another state). Card 1510 may include, for example, a printed account number for any state of a slider switch. Accordingly, card 1510 may include a printed debit account number and a printed credit account number. Persons skilled in the art will appreciate that each credit account, or payment option/feature, may have a different printed card not present security code (e.g., online security code such as a CVC or CVV) and such online security codes may be, for example, 3 or 4 digits in length. Such online security codes may be printed on the same side of a card as the associated payment number/option or may be printed on a different side. A printed label may be located next to each online code to indicate the option/account/feature associated with the online security code.

[0461] Card 1530 may be included and may have a slider switch associated with a payment card and a payment card option (e.g., a credit account and an installment option associated with that credit account). Selecting an installment option may, for example, provide in a payment data message (e.g., an EMV, contactless, and/or magnetic stripe data) a flag associated with the selected option. Accordingly, an EMI option may be selected and the credit card account associated with the card may be communicated to a payment card reader. A flag associated with the selected payment option (e.g., EMI) may be communicated. This flag may be retrieved, for example, after authorization of the underlying payment account (e.g., credit card account). The flag may be recognized as being associated with a particular option and then a process associated with the option may be initiated (e.g., an installment option). A cardholder may change the option associated with a state of a button (e.g., a slider switch) using a different device (e.g., a mobile telephonic device or a portable or stationary computer on a website). Accordingly, a cardholder may change an option from a 6 month EMI to a 12 month EMI to a pay with points option. The flag, for example, communicated by the card may stay the same regardless of the option selected by a consumer, but after the flag is received, a processing system may retrieve (e.g., from a remote storage facility) the option associated with that flag that a cardholder selected (e.g., on the user's mobile phone).

[0462] Card 1550 may include, for example, card structure 1551 which may be for example, a plastic such as a laminated plastic. Card 1550 may include circuit board 1560 which may be a flexible circuit board and may be, for example, less than six thousandths of an inch in thickness (e.g., less than four thousandths of an inch in thickness. Circuit board 1560 may include contact payment reader contacts 1552 and may include, for example, 6 contacts, 8 contacts, or any amount of contacts. Persons skilled in the art will appreciate that circuit board 1560 may be laminated and embedded in structure 1551 and contacts 1552 may be lasered out and then filled up to the surface of the laminate with a material (e.g., a conductive material such as a silver). Processor 1553 as well as additional circuitry (e.g., ASICs, capacitors, resistors, battery charging circuitry, etc.) may be coupled to processor 1553 or other components of circuit board 1560. Slider switch 1553 may be provided on circuit board 1560 and coupled to processor 1553 or any component of card 1561. Persons skilled in the art will appreciate that a static (or electronically programmable magnetic stripe communications device) may be included in card 1550 as well as a RFID antenna and associated processing chip. Such an RFID antenna may be independent from circuit board 1560 and may have an independent chip and may be programmed with payments data independently from a chip associated with contacts 1552. Contacts 1552 and an RFID antenna (e.g., EMV contactless antenna) may share the same processor and/or secure storage element for secure payments data.

[0463] FIG. 16 shows a card with an orientation of detectors 1626 and dynamic magnetic stripe communication device 1630, whereby one or more detectors 1602-1616 and dynamic magnetic stripe communication device 1630 may be, for example, arranged along a length of card 1600.

[0464] Detectors 1602-1616 may be provided, for example, as conductive pads using, for example, an additive technique, whereby patterns of a conductive element (e.g., copper) may be applied to a PCB substrate according to a patterning mask definition layer. Detectors 1602-1616 may be provided, for example, as conductive pads using, for example, a subtractive technique whereby patterns of a conductive element (e.g., copper) may be removed from a pre-plated PCB substrate according to an etching mask definition layer. Other non-PCB fabrication techniques may be used to implement conductive pads 1602-1616 as may be required by a particular application.

[0465] Processor 1618, conductive pads 1602-1616, processor 1618, dynamic magnetic stripe communication device 1630, inductive sensor circuitry 1628 and multiple sensor algorithm 1632 may be combined to provide a multiple sensor detection system.

[0466] For example, each of conductive pads 1602-1616 may be utilized by processor 1618 as capacitive sensing pads. Processor 1618 may include the functionality to control and determine when an object is in the proximity of one or more conductive pads via a capacitive sensing technique. Dynamic magnetic stripe communications device 1630 and inductive sensor circuitry 1628 may be utilized by processor 1618 as an inductive sensing device. For example, a processor may include the functionality to independently utilize multiple portions of dynamic magnetic stripe communications device 1630 and determine when an object is in the proximity of one or more of the portions via an inductive sensing technique.

[0467] FIG. 49 shows capacitive detection circuitry 1700. A conductive pad may be utilized, for example, as a conductor of a capacitive device within a resistor/capacitor (RC) circuit to determine the capacitance of a conductive pad and determine whether the capacitance is below, equal to, or above one or more predetermined thresholds.

[0468] A conductive pad may, for example, form a portion of a capacitive element, such that plate 1716 of capacitive element 1714 may be implemented by a conductive pad and the second plate of capacitive element 1714 may be implemented by element 1710. Element 1710 may represent, for example, the device or object whose proximity or contact is sought to be detected.

[0469] The capacitance magnitude of capacitive element 1714 may exhibit, for example, an inversely proportional relationship to the distance separation between plate 316 and device 310. For example, the capacitance magnitude of capacitive element 1714 may be relatively low when the corresponding distance between plate 316 and device 1710 may be relatively large. The capacitance magnitude of capacitive element 1714 may be relatively large, for example, when the corresponding distance between plate 1716 and device 1710 is relatively small.

[0470] Capacitive detection may be accomplished, for example, via circuit 1700 of FIG. 49. Through a sequence of charging and discharging events, an average capacitance magnitude for capacitive element 1714 may be determined over time. In so doing, the spatial relationship (e.g., the separation distance) between plate 1716 and device 1710 may be determined.

[0471] Charge sequence 1750, for example, may be invoked, such that charge circuit 1704 may be activated at time Tl, while discharge circuit 1706 may remain deactivated. Accordingly, for example, current may flow through resistive component 1708. In doing so, for example, an electrostatic field may be generated that may be associated with capacitive component 1714. During the charge sequence, for example, the voltage at node 1712 may be monitored to determine the amount of time required (e.g., TCHARGE = Al-Tl) for the voltage at node 1712, V1712, to obtain a magnitude that is substantially equal to, below, or above a first threshold voltage (e.g., equal to VI).

[0472] Discharge sequence 1760, for example, may be invoked, such that discharge circuit 1706 may be activated at time T2, while charge circuit 1704 may remain deactivated. During the discharge sequence, for example, the electric field associated with capacitive element 1714 may be allowed to discharge through resistive component 1708 to a reference potential (e.g., ground potential). The voltage at node 1712 may be monitored to determine the amount of time required (e.g., TDISCHARGE = Δ2-T2) for the voltage at node 1712, V1712, to obtain a magnitude that is substantially equal to, below, or above a second threshold voltage (e.g., equal to V2).

[0473] Once the charge time, TCHARGE, and discharge time, TDISCHARGE, are determined, the charge and discharge times may be utilized to calculate a capacitance magnitude that may be exhibited by capacitive element 1714. For example, given that the magnitude of voltage, VI, may be equal to approximately 63% of the magnitude of voltage, VS, then a first relationship may be defined by equation (1) as:

[0474] TCHARGE = R₁₇₀₈*C1, (1) where R₁₇₀₈ the resistance magnitude of resistive element 1708 and Cl is proportional to a capacitance magnitude of a capacitive element (e.g., capacitive element 1714).

[0475] Similarly, for example, given that the magnitude of voltage, V2, is equal to approximately 37% of the magnitude of voltage, V_s, then a second relationship may be determined by equation (2) as: T_DISCHARGE = R₁₇₀₈*C2, (2) where C2 is proportional to a capacitance magnitude of capacitive element 1714. The capacitance magnitudes, C₁ and C₂, may then be calculated from equations (1) and (2) and averaged to determine an average capacitance magnitude that is exhibited by capacitive element 1714. [0476] Persons skilled in the art will appreciate that circuits 1704 and 1706 may be activated and deactivated by controller 1720. Accordingly, for example, controller 1720 may control when the charge and discharge events occur. Persons skilled in the art will further appreciate that controller 1720 may adjust a frequency at which circuits 1704 and 1706 may be activated and/or deactivated, thereby adjusting a sampling rate at which the capacitance magnitudes, C₁ and C₂, may be measured. In so doing, a sampling rate (e.g., a lower sampling rate) may be selected in order to select a power consumption rate of a card (e.g., a lower power consumption rate). Controller 1720 may, for example, store capacitance magnitude measurements within memory 1718. Accordingly, for example, multiple capacitance magnitudes may be stored for subsequent access by controller 1720.

[0477] A conductive pad may be utilized, for example, as a conductor of a capacitive device within a resistor/capacitor (RC) circuit to determine the capacitance of a conductive pad and determine whether the capacitance is below, equal to, or above one or more predetermined thresholds.

[0478] Referring to FIG. 16, a series of charge and discharge sequences for pads 1602-1616 may be executed by processor 1618 to determine, for example, a relative capacitance magnitude that is exhibited by each of pads 1602-1616. A series of charge and discharge sequences for each of pads 1602-1616 may be executed by processor 1618, for example, in order to obtain a capacitance characteristic for each of pads 1602-1616 over time.

[0479] By comparing the time-based capacitance characteristic of each pad 1602-1616 to a threshold capacitance value, a determination may be made, for example, as to when pads 1602-1616 are in a proximity, or touch, relationship with a device whose presence is to be detected. For example, a sequential change (e.g., increase) in the relative capacitance magnitudes of pads 1602-1608, respectively, and/or pads 1616-1610, respectively, may be detected and a determination may be made that a device is moving substantially in direction 1622 relative to card 1600. A sequential change (e.g., increase) in the relative capacitance magnitudes of detectors 1610-1616, respectively, and/or 1608-1602, respectively, may be detected, for example, and a determination may be made that a device is moving substantially in direction 1624 relative to card 1600. Based on the detection, processor 1618 may activate inductive sensor circuitry 1628 in order to determine if the object is inductively detectable.

[0480] Persons skilled in the art will appreciate that by electrically shorting pairs of detectors together (e.g., pair 1602/1610, pair 1604/1612, pair 1606/1614, etc.) directional vectors 1622 and 1624 become insubstantial. For example, regardless of whether a device is moving substantially in direction 1622 or substantially in direction 1624 relative to card 1600, a determination may nevertheless be made that a device is close to, or touching, card 1600.

[0481] FIG. 50 shows inductive detection circuitry 1800. Referring to FIG. 18, inductive detection circuitry 400 may include, for example, coil portions 1805-1815, amplification and detection determination devices 1820 and 1830, oscillator 1825 and processor 1835.

[0482] Coil portions 1805-1815 may be portions of a coil, for example, portions of a coil in a dynamic magnetic stripe communications device. Coil portion 1810 may be, for example, a central portion of a coil in a dynamic magnetic stripe communications device, and may be connected across oscillator 1825, or may be one or more separate coils. Oscillator 1825 may be, for example, an electronic circuit that produces a repetitive, oscillating electrical signal (e.g., an alternating current and/or voltage) and/or may be a signal from an output of a port on processor 1835. A control signal CTRL may be communicated to oscillator 1825 (e.g., by processor 1835) to initiate application of the electrical signal to coil portion 1810. A time- varying magnetic field may be generated by coil portion 1810 due to the signal. The time varying magnetic field may induce repetitive, oscillating electrical signals in each of coil potions 1805 and 1815.

[0483] Coil portions 1805 and 1815 may be, for example, side portions of a coil in a dynamic magnetic stripe communications device. Although FIG. 18 shows coil portions 1805 and 1815 adjacent to coil portion 1810, example embodiments are not so limited. Coil portions 1805-1815 may be, for example, separated by other coil portions (not shown).

[0484] Coil portion 1805 may be connected to oscillator 1825 (e.g., a high frequency oscillator), and connected across amplification and detection determination device 1820. Amplification and detection determination device 1820 may receive the oscillating signal induced in coil portion 1805 by coil portion 1810, and output a signal OUT1 to processor 1835. Coil portion 1815 may be connected to oscillator 1825, and connected across amplification and detection determination device 1830. Amplification and detection determination device 1830 may receive the oscillating signal induced in coil portion 1815 by coil portion 1810, and output a signal OUT2 to processor 1835. Signals OUT1 and OUT2 may indicate whether or not signals induced in coil portions 405 and/or 1815 are less than, equal to or greater than a threshold signal value.

[0485] The threshold signal value may be based on the magnitude of the signals induced in coil portions 1805 and 1815 when coil portions 1805 and 1815 are adjacent to an object (e.g., a read-head of a card reader), and when coil portions 1805 and 1815 are not adjacent to an object.

[0486] Persons of ordinary skill in the art may appreciate that in the presence of a high frequency magnetic field, currents may be induced in a conductive object within the field. The currents may consume power due to resistance and energy in the field may be lost. Signal amplitude may decrease in side portions of a coil in the presence of a conductive object according to example embodiments. Accordingly, a read-head of a card reader may change the coupling between coil portion 1810, and coil portions 1805 and 1815, such that a magnitude of the signal induced in coil portions 1805 and 1815 by coil portion 1810 may decrease.

[0487] Referring to FIG. 16, inductive detection may be implemented by determining coupling responses in coil end sections and setting response threshold values. For example, an oscillating signal may be applied to a center portion of a coil in dynamic magnetic stripe communications device 1630 by processor 1618 via inductive sensor circuitry 1628. A coupling response in the coil end sections may be determined both when an object is within proximity of card 1600 and when no object is within proximity of card 1600. The coupling response may be determined by, for example, measuring a current and/or voltage across the end coil sections. Based on a difference between the coupling responses, a threshold value may be determined. Multiple sensor algorithm 1632 may utilize the threshold value to determine whether or not an object is detected.

[0488] According to at least one example embodiment, multiple threshold values may be determined in order to discriminate between multiple different objects. For example, multiple different objects may be passed in proximity to dynamic magnetic stripe communications device 1630 to determine a coupling response of the end coil sections in the presence of each of the objects. The coupling response may be determined by, for example, measuring a current and/or voltage across the end coil sections in the presence of each object. One or more threshold signal values may be determined based on the coupling responses.

[0489] For example, a human finger, a skimmer, a first type of read-head and a second type of read-head may be passed within proximity of dynamic magnetic stripe communications device 1630. A change in coupling between the center and end sections of the coil in magnetic stripe communications device 1630 for each object may be determined. One or more thresholds may be set such that during normal operation processor 1618 will activate dynamic magnetic stripe communications device 1630 to communicate data in the presence of the first and second type of read-head, but not in the presence of the skimmer or human finger.

[0490] Accordingly, if the coupling response of card 1600 in the presence of the skimmer is between that of the coupling responses of the first and second types of read-heads, and a coupling response in the presence of the human finger is less than the coupling response in the presence of any other of the objects, three separate threshold values may be set. During normal operation, by comparing the coupling response of the end sections to the one or more threshold values, a determination may be made, for example, as to when the coil end sections are in a proximity, or touch, relationship with a device whose presence is to be detected.

[0491] Inductive sensor circuitry 1620 and dynamic magnetic stripe communications device 1630 may be used in conjunction with, for example, one or more pads 1602- 1616 to determine that a device (e.g., a read-head housing of a magnetic stripe reader) is in close proximity, or touching, one or more of pads 1602-1616. Processor 1618 may, for example, utilize multiple sensor algorithm 1632 to detect a device moving with respect to card 1600. For example, multiple sensor algorithm 1632 may analyze a capacitance change in one or more conductive pads to determine that a device is moving in relation to pads 1602-1616. Once a device is detected, processor 1618 may, for example, apply an oscillating signal to a center portion of dynamic magnetic stripe communication device 1630 and detect a coupling response of side portions of dynamic magnetic stripe communication device 1630. If a coupling response indicates that (e.g., inductive detection) an object is detected, processor 1618 may communicate with the detected device via dynamic magnetic stripe communications device 1628. [0492] FIG. 19 shows inductive detection circuitry 1900. Referring to FIG. 19, inductive detection circuitry 1900 may include, for example, coils 1905-1915, amplification and detection determination devices 1920 and 1930, oscillator 1925 and processor 1935.

[0493] Coil 1910 may be, for example, a coil of a dynamic magnetic stripe communications device and/or a coil separate from the dynamic magnetic stripe communications device. Coil 1910 may be connected across oscillator 1925. Oscillator 1925 may be, for example, an electronic circuit that produces a repetitive, oscillating electrical signal (e.g., an alternating current and/or voltage). Oscillator 1925 may be, for example, a processor (e.g., a signal may be output from a port of a processor). A control signal CTRL may be communicated to oscillator 1925 (e.g., by processor 1935) to initiate application of the electrical signal to coil 1910. A time-varying magnetic field may be generated by coil 1910 due to the signal. The time varying magnetic field may generate repetitive, oscillating electrical signals in each of coils 1905 and 1915.

[0494] Coils 1905 and 1915 may be, for example, detection coils on opposite ends of a card. For example, coils 1905 and 1915 may be adjacent to capacitive sensors at ends of a card. Coil 1905 may be connected across amplification and detection determination device 1920. Amplification and detection determination device 1920 may receive the oscillating signal induced in coil 1905 by coil 1910, and output a signal OUT1 to processor 1935. Coil 1915 may be connected across amplification and detection determination device 1930. Amplification and detection determination device 1930 may receive the oscillating signal induced in coil 1915 by coil 1910, and output a signal OUT2 to processor 1935. Signals OUT1 and OUT2 may indicate whether or not signals induced in coil portions 1905 and/or 1915 are less than, equal to or greater than a threshold signal value indicating whether or not an object is inductively detected.

[0495] The threshold signal value may be based on the magnitude of a signal induced in coil 1905 and/or coil 1915 when coil 1905 and/or coil 1915 is adjacent to an object (e.g., a read-head of a card reader), and the magnitude of a signal when coil 1905 and 1915 are not adjacent to an object.

[0496] FIG. 20 shows a card that is in proximity to an object 2002. Card 2015 may be in proximity to object 602 such that a distance between conductive pad 2006 and object 2002 is less than a distance between conductive pad 608 and object 2002. Accordingly, for example, a capacitance magnitude that may be associated with conductive pad 2006 may be, for example, greater than a capacitance magnitude that may be associated with conductive pad 2008. Persons of ordinary skill will appreciate that capacitance values may be relative to each pad and that a capacitance magnitude of a proximate pad may be equal to or less than a pad that is farther away from an object depending on, for example, manufacturing variation. Such pads may be in any case characterized such that the detected capacitances may be used to determine which pad is closer to an object.

[0497] A processor that may be monitoring the capacitance magnitudes of conductive pads 2006 and 2008 may determine, for example, that object 2002 is close to conductive pad 2006. Based on the determination, the processor may cause a time-varying signal to be applied to coil 2011, and may monitor coils 2010 and 2009 to determine a property (e.g., relative conductivity) of object 2002 (e.g., a read-head of a magnetic stripe reader).

[0498] Card 2025 may be in proximity to a device (e.g., read-head 2012) that may have moved from position 2020 such that a distance between conductive pad 2018 and device 2012 may be slightly greater than a distance between conductive pad 2016 and device 2012. Accordingly, for example, a capacitance magnitude that may be associated with conductive pad 2016 may be, for example, slightly greater than a capacitance magnitude that may be associated with conductive pad 2018. In so doing, for example, a processor that may be monitoring the capacitance magnitudes of conductive pads 2016 and 2018 may determine that a device may be travelling in direction 2014. Further, a processor may determine that a device is slightly closer to conductive pad 2016 than to conductive pad 2018. The processor may initiate inductive detection when device 2012 is at, for example, position 2020, by applying a time-varying signal to coil 2021, and may terminate the signal upon detecting device 2012 via coil 2019 and/or 2017.

[0499] Card 2035 may be in proximity to a device (e.g., read-head 2022) that may have moved from position 2032 to 2034. Accordingly, for example, a capacitance magnitude that may be associated with conductive pad 2028 may be slightly greater than a capacitance magnitude that may be associated with conductive pad 2026. In so doing, for example, a processor that may be monitoring the capacitance magnitudes of conductive pads 2026 and 2028 may determine that a device may be travelling in direction 2024. Further, a processor may determine that a device is slightly closer to conductive pad 2028 than to conductive pad 2026. The processor may initiate inductive detection when device 2022 is at, for example, position 2034 by applying a time-varying signal to coil 2033, and may terminate the signal upon detecting device 2022 via coil 2031 and/or 2032, and/or within a period of time.

[0500] Device 2022 may move from position 2034 to position 2036. Accordingly, for example, a capacitance magnitude that may be associated with conductive pad 2030, for example, may be slightly greater than a capacitance magnitude that may be associated with conductive pad 2028. In so doing, for example, a processor that may be monitoring the capacitance magnitudes of conductive pads 2030 and 2028 may determine that a device may be travelling in direction 2024.

[0501] A processor may determine, for example, that a device is first located closest to conductive pad 2026, the device is then located closest to conductive pad 2028, and the device is then located closest to conductive pad 2030 in succession by detecting, for example, that a capacitance magnitude of conductive pad 626 changes (e.g., increases), followed by a capacitance change (e.g., increase) of conductive pad 2028, and then followed by a capacitance change (e.g., increase) of conductive pad 2030, respectively. In response to a sequential capacitance change in pads 2026, 2028, and 2030, respectively, and a coupling response change in coil 2031, a processor may activate one or more electromagnetic field generators to initiate a communications sequence with, for example, read-head 2022. Each of the capacitance changes, the direction of movement and the inductive sensing may be used to determine that card 2035 is moving with respect to a read-head in an expected fashion, for example, a swipe through a card reader. A communication sequence may be initiated upon card 2035 determining that an expected sequence of events has occurred.

[0502] Sequences and relative timings of events may be known for various other types of readers (e.g., dip and/or motorized readers). Accordingly, data communication and data security may be improved. Persons of ordinary skill in the art will appreciate that read- head detection may occur in a similar fashion for movement in a direction opposite to direction 2024.

[0503] A sequential capacitance change in conductive pads 2026-2030, respectively, may not occur. For example, a speed at which a device (e.g., read-head 2022) travels in direction 2024 relative to card 2035 may cause a processor to detect a capacitance change, for example, in conductive pad 2026 followed by a capacitance change in conductive pad 2030, but a capacitance change in conductive pad 2028 may not be detected. Accordingly, for example, a processor may execute a detection algorithm with an awareness of capacitance changes in non-adjacent conductive pads (e.g., conductive pads separated by one or more other conductive pads). In so doing, for example, a processor may nevertheless determine that a device is moving in proximity to a card and may activate a communications device in response to such a detection. A processor may, for example, detect devices moving at increased speeds (e.g., twice an average swipe speed) without sacrificing detection accuracy. [0504] A processor may measure a magnitude of capacitance changes in conductive pads 2026-2030 that is not, for example, consistent with movement of a device in direction 2024. For example, a processor may first measure a capacitance magnitude associated with conductive pad 2026 that may be larger than a capacitance magnitude of either of conductive pads 2028 and 2030. A processor may next measure a capacitance magnitude associated with conductive pad 2030 that may be larger than a capacitance magnitude of either of conductive pads 2026 and 2028. A processor may next measure a capacitance magnitude associated with conductive pad 2028 that may be larger than a capacitance magnitude of either of conductive pads 2026 and 2030.

[0505] In so doing, for example, movement of a device in direction 2024 may be considered to be inconsistent with such a capacitance characteristic, since sequential capacitance magnitude increases may not be detected in conductive pads 2026, 2028, and 2030, respectively. A processor executing a multiple sensor algorithm may have an awareness that detected capacitance increases may be inconsistent with an actual direction of movement of a device. In so doing, for example, a processor may determine that a device is in proximity to card 2035, is not moving in direction 624, and may not, for example, activate a communications device in response to such a detection.

[0506] FIG. 21 shows a detection method flow diagram. Referring to sequence 2110, a sensor state change (e.g., an increased capacitance) may be detected in a first type of sensor (e.g., as in step 2111). A second type of sensor may be activated in response to the sensor state change (e.g., as in step 2112). A state of the second type of sensor (e.g., an inductive detection of a conductive object) may be determined (e.g., as in step 2113). Based on the first sensor state change and the state of the second type of sensor, a communication sequence may be activated (e.g., as in step 2114) and/or the second type of sensor may be deactivated.

[0507] A card may be fully operational (e.g., as in step 2121 of sequence 2120), whereby a communication sequence may be activated after a device is detected to be in proximity, or touching, the card. Once the communication sequence is completed, a state change of a first type of sensor (e.g., an increased capacitance) may be detected (e.g., as in step 2122). A low-power mode of a card may be activated based on the state change detection (e.g., as in step 2123).

[0508] FIG. 22 shows inductive detection circuitry 2200. Inductive detection circuitry 2200 may include, for example, one or more coils (e.g., dynamic magnetic stripe communications device 2204), a coil driver (e.g., ASIC 2202), processor 2206, excitation device (e.g., oscillator 2248) and one or more sensors (e.g., sensor 844 and/or sensor 2266). Dynamic magnetic stripe communications device 2204 may, for example, include a first coil (e.g., coil 2250) for communicating a first track of magnetic stripe information to a read head of a magnetic stripe reader, a second coil (not shown) for communicating a second track of magnetic stripe information to the read head of the magnetic stripe reader and a third coil (not shown) for communicating a third track of magnetic stripe information to the read head of the magnetic stripe reader.

[0509] Any one or more coils of dynamic magnetic stripe communications device 2204 may be used in a first mode of operation as a magnetic stripe communications device and in a second mode of operation, dynamic magnetic stripe communications device 2204 may be used as a component of inductive detection circuitry 2200. In the first mode of operation, processor 806 may activate ASIC 2202 (e.g., via assertion of signal ENABLE1 of ASIC 2202), which may in turn cause ASIC 2202 to assert a signal (e.g., ASIC 2202 may assert signal VPOS to an active high voltage level). In so doing, for example, switch devices (e.g., NFET 2208 and NFET 2210) may transition to a conductive state, thereby coupling ASIC 802 to one or more coils of dynamic magnetic stripe communications device 804 (e.g., node 2256 is electrically coupled to ASIC 2202 via NFET 2210 and node 2252 is electrically coupled to ASIC 2202 via NFET 2208). [0510] In the second mode of operation, processor 2206 may deactivate ASIC 2202 (e.g., via deassertion of signal ENABLE1 of ASIC 2202), which may in turn cause ASIC 2202 to deassert a signal (e.g., ASIC 2202 may deassert signal VPOS to an inactive low voltage level). In so doing, for example, switch devices (e.g., NFET 808 and NFET 2210) may transition to a non-conductive state, thereby decoupling ASIC 2202 from one or more coils of dynamic magnetic stripe communications device 2204 (e.g., node 2256 is electrically isolated from ASIC 2202 via NFET 2210 and node 2252 is electrically isolated from ASIC 2202 via NFET 2208). In addition, for example, processor 806 may assert signal, ENABLE2, thereby activating oscillator 2248, sensor circuit 2244 and/or sensor circuit 2246 during the second mode of operation.

[0511] Oscillator circuit 2248 may, for example, include an operational amplifier (OP AMP 2228), a feedback network (e.g., resistors 2230 and 2232) and a frequency selection network (e.g., resistors 2234, 2240 and capacitors 2236, 2238). VREF1 may, for example, be a reference voltage (e.g., ground potential) when OP AMP 2228 operates between positive and negative power supply rails (e.g., an output signal generated by OP AMP 2228 is a signal having a direct current (DC) component at or near ground potential). VREF1 may, for example, be a reference voltage (e.g., a positive potential greater than ground potential) when OP AMP 2228 operates between a positive power supply rail and ground potential (e.g., an output signal generated by OP AMP 2228 is a signal having a direct current (DC) component at a positive potential above ground potential).

[0512] Oscillator circuit 2248 may, for example, generate a signal (e.g., a square wave signal) having a frequency that may be selected by a frequency selection network (e.g., resistors 2234,2240 and capacitors 2236,2238), where resistors 2234,2240 may be selected to have equivalent resistance magnitudes approximately between 1500 ohms and 5000 ohms (e.g., approximately 3300 ohms) and capacitors 2236,2238 may be selected to have equivalent capacitance magnitudes approximately between 20 and 80 pF (e.g., approximately 47 pF). The signal frequency, fosc, generated by oscillator circuit 2248 may be approximated as, fosc= where C is the capacitance magnitude of capacitors 2236,2238 and R is the resistance magnitude of resistors 2234,2240. Accordingly, for example, the sinusoidal frequency, fosc, generated by oscillator circuit 2248 may be between approximately 400 kHz and 5 MHz (e.g., approximately 500 kHz).

[0513] Feedback network (e.g., resistors 2230 and 2232) of oscillator circuit 2248 may, for example, be used to select a voltage gain of OP AMP 2228, such that the overall gain of oscillator circuit 2248 is at, or near, unity when a signal at frequency, fosc, is being generated. Accordingly, for example, a ratio of the resistance magnitude of resistor 2230 to the resistance magnitude of resistor 2232 may be approximately between 2 and 10 (e.g., approximately equal to 5).

[0514] In the second mode of operation, for example, oscillator circuit 2248 may generate a signal to directly or indirectly excite a portion of dynamic magnetic stripe communications device 804 (e.g., center-tap node 2254 of coil 2250). In one embodiment, for example, the signal may transition transistor 2242 between conductive and non-conductive states, thereby applying a signal (e.g., a voltage signal approximately equal to ground potential) to node 2254 when transistor 2242 is conductive and applying a signal (e.g., a voltage signal approximately equal to VREF2) to node 2254 when transistor 2242 is non- conductive. In so doing, for example, at least a portion of dynamic magnetic stripe communications device 804 may be excited during the second mode of operation.

[0515] A signal (e.g., a voltage signal) that may be indicative of an excitation of at least one coil of dynamic magnetic stripe communications device 2204 during the second mode of operation may be sensed by sensor 2244 and/or 2246 at nodes 2252 and/or 2256, respectively. One or more differential amplifiers (e.g., amplifier 2212 and/or 2220) may, for example, be used to sense the difference between a signal present at a node (e.g., node 2252) as compared to a signal present at a different node (e.g., node 2256).

[0516] In the absence of a proximity, or touch, relationship with an object (e.g., a read head of a magnetic stripe reader) during the second mode of operation, for example, the sensed difference between a signal present at node 2252 as compared to a signal present at node 2256 may be substantially equal to zero. Accordingly, sensors 2244 and/or 2246 may provide a difference signal (e.g., a signal indicative of a zero difference) to indicate that no object may be in a touch, or proximity, relationship to dynamic magnetic stripe communications device 804 during the second mode of operation.

[0517] In the presence of a proximity, or touch, relationship with an object (e.g., a read head of a magnetic stripe reader) during the second mode of operation, for example, the sensed difference between a signal present at node 2252 as compared to a signal present at node 2256 may be substantially non-zero. Accordingly, sensors 2244 and/or 2246 may provide a difference signal (e.g., a signal indicative of a non- zero difference) to indicate that an object may be in a touch, or proximity, relationship to dynamic magnetic stripe communications device 804 during the second mode of operation.

[0518] Differential amplifier 2212 of sensor 2244 may, for example, provide a difference signal that is indicative of a magnitude of a signal present at node 2252 subtracted from a magnitude of a signal present at node 2256. Differential amplifier 2220 of sensor 2246 may, for example, provide a difference signal that is indicative of a magnitude of a signal present at node 2256 subtracted from a magnitude of a signal present at node 2252.

[0519] Peak detector 2214 may, for example, receive a difference signal generated by differential amplifier 2212 and/or peak detector 2222 may, for example, receive a difference signal generated by differential amplifier 2220. Excursions (e.g., maximum positive excursions) of the difference signal generated by differential amplifier 2212 and/or differential amplifier 2220 may, for example, forward bias a diode of peak detector 2214 and/or 2222, which may allow a capacitor of peak detector 2214 and/or 2222 to charge to a voltage indicative of such a maximum positive excursion, where the voltage may be maintained by the capacitor for a period of time (e.g., time enough for the difference signal generated by differential amplifier 2212 and/or differential amplifier 2220 to be sensed and processed by processor 2206). A resistance may, for example, be placed in parallel with the capacitor of peak detector 2214 and/or 2222 in order to allow the capacitor of peak detector 2214 and/or 2222 to discharge after a period of time (e.g., after the difference signal generated by differential amplifier 2212 and/or differential amplifier 2220 has been sensed and processed by processor 2206).

[0520] Comparators 2216 and 2224 of sensors 2244 and 2246, respectively, may compare the maximum positive signal excursions as may be generated by peak detectors 2214 and 2222, respectively, to a reference potential (e.g., VREF3 and VREF4, respectively). Comparator 2216 may, for example, compare a maximum of the difference signal, V2256-V2252, as may be generated by peak detector 2214, to VREF3, where V2256 is the voltage at node 2256 and V852 is the voltage at node 2252. If the difference signal is below VREF3, then an output of comparator 2216 (e.g., signal SENSEI) may be at a logic high level, whereas if the difference signal is above VREF3, then an output of comparator 2216 (e.g., signal SENSEI) may be at a logic low level. Resistor 2218 may be used to provide hysteresis, so that an output of comparator 2216 does not oscillate when a magnitude of the difference signal present at the inverting input to comparator 2216 is at, or near, the magnitude of VREF3.

[0521] Similarly, comparator 2224 may, for example, compare a maximum of the difference signal, V2252-V2256, as may be generated by peak detector 2222, to VREF4, where V2256 is the voltage at node 2256 and V2252 is the voltage at node 2252. If the difference signal is below VREF4, then an output of comparator 2224 (e.g., signal SENSE2) may be at a logic high level, whereas if the difference signal is above VREF4, then an output of comparator 2216 (e.g., signal SENSE2) may be at a logic low level. Resistor 2226 may be used to provide hysteresis, so that an output of comparator 2224 does not oscillate when a magnitude of the difference signal present at the inverting input to comparator 2224 is at, or near, the magnitude of VREF4.

[0522] Processor 2206 may, for example, monitor signals, SENSEI and/or SENSE2, as may be produced by sensors 2244 and/or 2246, respectively, to make a determination as to whether an object (e.g., a read head of a magnetic stripe reader) is in a proximity, or touch, relationship to dynamic magnetic stripe communications device 804 during the second mode of operation.

[0523] FIG. 23 shows force detection circuitry 2300. Referring to FIG. 23, force detection circuitry 2300 may include, for example, comb electrodes 2320 and 2330 on a substrate 2340. Comb electrodes may be conductive, for example, a metal (e.g., copper, silver and/or gold). Substrate 2340 may be a support layer and/or an insulating layer. [0524] According to at least one example embodiment, substrate 2340 may be a layer of a flexible circuit board (e.g., polyimide and/or FR4). Comb electrodes 2320 and 2330 may be, for example, circuit board traces connected to a processor. Contact resistance between electrodes 2320 and 2330 may vary as a response to the pressure applied to the pressure sensitive area.

[0525] According to at least one example embodiment, the length L of force detection circuitry 2300 may be 8mm to 12mm, for example, 9mm to 11mm (e.g., about 10.5mm), and a width W of force detection circuitry 2300 may be 3mm to 6mm, for example, about 4mm to 5mm (e.g., about 4.5mm).

[0526] Example embodiments are not limited to a resistive electrode force sensors. Force sensors according to example embodiments may include, for example, piezoresistive, capacitive, electromagnetic piezoelectric, optical, resonant, thermal and/or ionization based sensors. According to at least one example embodiment, a force sensor may be a micro- electro-mechanical (MEMs) diaphragm sensor.

[0527] FIG. 24 shows card 2400. Referring to FIG. 24, card 2400 may be, for example, a card compliant or noncompliant with ISO specifications for identification cards. According to some example embodiments, card 2400 may be a flexible mobile telephonic device with a thickness compatible with magnetic stripe readers, for example, a mobile phone with the dimensions of a standard credit card, (i.e., a thickness of about 30mils, a length of about 3.370 inches and a width of about 2.125 inches). According to at least one example embodiment, card 1000 may be a telephonic apparatus with a length and width and width of a conventional mobile phone. [0528] Card 2400 may include force sensor 2410 and EMV contacts 2420. Force sensor 2410 may, be located in a region 2450 of card 2400 in which a feed wheel of a motorized reader (e.g., motorized reader of an automated teller machine (ATM)) contacts card 2400. For example, lines 2430 and 2440 may illustrate borders of region 2450. A feed wheel of a motorized reader may contact and traverse card 2400 in region 2450. The width X of region 1050 may be about, for example, 8mm. Force sensor 1010 may be in proximity to or within region 2450 and embedded in card 2400 (e.g., a powered card). Although force sensor 2410 is shown in a particular location, such positioning is for illustrative purposes only. According to some example embodiments, force sensor 2410 may be anywhere in region 2450. According to other example embodiments, force sensor 2410 may be anywhere in card 1000 and still detect the presence of a feed wheel.

[0529] FIG. 25 a graph illustrating a force sensor response, for example, a signal associated with the detection of a motorized reader component (e.g., a feed wheel) crossing a high range force sensor of a powered card. The response signal may be a signature from which the type of a reader, and a speed of the card relative to the reader, may be determined.

[0530] According to some example embodiments, the velocity of the card relative to a reader (e.g., a side or end entry motorized reader) may be determined using the dimensions of the sensor, for example, a dimension of a sensor across which a reader component crosses, and the width of the waveform produced by the force sensor (i.e., time). For example, the speed a card is moved by the feed wheel of a motorized reader may be used to determine a communication data rate (e.g., in bits per second (bps)). The data rate may be determined so that, for example, data is transmitted to a read head of a motorized reader by a dynamic magnetic communications device of the card at the rate expected by the motorized reader. The motorized reader may expect data to be communicated at a rate corresponding to the speed a magnetic stripe card would be moved across one or more read-heads of the motorized reader.

[0531] A magnetic stripe card may have multiple tracks of data written to the stripe at different data densities. For example, for a payment card, tracks one and three may be recorded at 210 bits per inch and track two may be recorded at 75 bits per inch. The velocity at which the reader moves the card across a read-head may be multiplied with the recording density to determine the data rate in bits per second. The card may communicate data with a dynamic magnetic communications device at a data rate matching the expected data rate.

[0532] A type of the reader may be determined based on, for example, a depth of the waveform produced by the force sensor as the reader exerts pressure on the card. The depth of the waveform may be proportional to the force exerted on a card by the feed wheel of a motorized reader. Each type of reader (i.e., make and model) may exert a different pressure through a feed wheel and therefore a signature waveform may be produced by the force sensor in response to a type of reader. Signals produced or processed by a force sensor that do not match a known signature may be disregarded as a false detection. For example, pressure of a user's finger or of a wallet may be ignored.

[0533] According to some example embodiments, the expectations of a type of reader may be characterized using a card configured to collect data and default rates of data communication may be used for user cards based on the type of the reader without knowledge of a velocity of the card in the motorized reader.

[0534] FIG. 26 shows a detection method flow diagram. Referring to sequence 2600, a sensor state change (e.g., an increased capacitance) may be detected in a first type of sensor (e.g., as in step 2610). A second type of sensor may be activated in response to the sensor state change (e.g., as in step 2611). A state of the second type of sensor (e.g., an inductive detection of a conductive object) may be determined (e.g., as in step 2612). A state change of a third type of sensor (e.g., a force sensor) may be used to detect a type of a reader (e.g., a motorized reader or a make/model of a reader) (e.g., as in step 2613). Based on the first sensor state change, the state of the second type of sensor and the state change of the third type of sensor, a communication sequence may be activated (e.g., as in step 2614) and/or the second type of sensor may be deactivated.

[0535] Example embodiments are not limited and, for example, although the state change of the third type of sensor is shown after step 2612, the state change is independent and may occur at any time in the sequence.

[0536] FIG. 27 shows an example card according to example embodiments. Referring to FIG. 27, card 2705 illustrates an exemplary card prior to pushing a button on the card. Card 2755 illustrates the same exemplary card after pushing a button on the card once the display has completed updating. As described above, initially information regarding one stored card, in this case the Visa 1 card, is displayed. While not shown, additional information can be displayed to the user on the same or different displays. For example, the card number may be displayed in an embodiment. In an embodiment the Visa® logo may be displayed.

[0537] Prior to pressing the button, the EMV chip will communicate information associated with the Visa 1 card that is displayed on card 2705. In an embodiment, the Visa 1 card information may also be communicated via multiple means, for example a dynamic magnetic stripe emulator, a dynamic magnetic stripe encoder, or wirelessly. In an embodiment, the Visa 1 card information may also be communicated wirelessly via Bluetooth, RFID, WiFi, light (using LEDs and light sensors), as well as other wireless communication means known to those skilled in the art.

[0538] After pressing the button, the display will update, as described in more detail below, to display the information associated with a second cards, for example the VISA 2 card. In an exemplary embodiment, the display will appear to be swiped clear from a left to right direction. Once the display has been cleared, information regarding the second card will appear on the display, again in a left to right direction. Further exemplary embodiments are described below.

[0539] Once the display is updated, the EMV chip will communicate information associated with the Visa 2 card that is displayed on card 2755. In an embodiment, the Visa 2 card information may also be communicated via multiple means, for example a dynamic magnetic stripe emulator, a dynamic magnetic stripe encoder, or wirelessly. In an embodiment, the Visa 2 card information may also be communicated wirelessly via Bluetooth, RFID, WiFi, light (using LEDs and light sensors), as well as other wireless communication means known to those skilled in the art. In an embodiment, card 2705 maybe able to be recharged wirelessly, for example via a user's mobile phone.

[0540] FIG. 28 shows an example card according to example embodiments. Referring to FIG. 28, display 2810 illustrates an exemplary display card. In an exemplary embodiment, prior to pushing a button on the card, the display may be blank, for example when the card is in a sleep mode. In an exemplary embodiment, once a button is pressed, for example, button 2815, the card may exit the sleep mode. At that point, a processor, for example a 16 bit microprocessor, an ARM processor, or processor 120 illustrated in figure 1, may be configured to provide information to be displayed on display 2810 to a driving circuit that will in turn drive display 2810. In an exemplary embodiment, the driving circuit is configured to drive display 2810 to display the image from left to right. For example the image may gradually appear, row by row, on display 2810. In another embodiment the processor may control the driver to drive the display to first display the right most column of pixels in the left most column, and then display the right 2 most column of pixels in the left 2 most columns, and continue until the entire image is displayed, making is appear like the image moved across the screen. In an embodiment, the image may appear from top to bottom, bottom to top, or right to left. A person skilled in the art would understand that these are merely examples and that other configurations are possible, such as diagonally across the screen or from the center out.

[0541] In an exemplary embodiment, prior to pushing a button on the card, the display may be display a first card's information. In an exemplary embodiment, once a button is pressed, for example, button 2815 or button 2820, the card may be configured to provide information regarding a second card to be displayed on display 2810 to a driving circuit that will in turn drive display 2810. In an exemplary embodiment, the driving circuit is configured to drive display 2810 to display the image from left to right. For example an image associated with the first card may gradually disappear, row by row, on display 2810 and then an image associated with the second card may gradually appear. This may happen in various ways known to those skilled in the art, for example those described above. In another exemplary embodiment, an image associated with the first card may gradually disappear, row by row, on display 2810, while at the same time an image associated with the second card may gradually appear. This may happen in various ways known to those skilled in the art, for example those described above.

[0542] In an embodiment, the image data provided by the processor may be compressed image data. In an embodiment the image data stored on the card may be compressed image data. In another exemplary embodiment, the image data may be compressed by the processor, prior to sending the image data to the driving circuit. In an exemplary embodiment, image data associated with the payment cards stored on the card are loaded onto the card at the time the card is issued. In an exemplary embodiment, image data associated with user cards may be added or removed from the card as user cards are added or removed from the card. For example, an issuer or financial institution may communicate new card information wirelessly, such as using Bluetooth, WiFi, or NFC communications, or using wired connections, such as the EMV contacts, to the card. The new card information may include image data. In an embodiment this image data is stored directly to the memory on the card. In an embodiment, the processor processes this image data and stores a compressed version of the card image to memory.

[0543] Image data associated with a user card stored on the card may include new credit card numbers, new expiration dates, new network logos, coupon images, reward card images, point card images, hotel card images, barcodes, qcodes, CVV/CVC, dynamic CVV/CVC algorithms, dynamic CVV/CVC keys, etc.

[0544] FIG. 29 shows an example card according to example embodiments. Referring to FIG. 29, the display comprises a first portion 2910 and a second portion 2920. In an embodiment, the first portion 2910 may be updated first as described above, followed by the second portion 2920. In an exemplary embodiment, second portion 2920 may be updated first, followed by first portion 2910. In an embodiment first portion 2910 may be updated at the same time as second portion 2920, for example to create the effect that the display is being updated from the middle up and down, for from the left to the right on the time and from the right to the left on the bottom, or from the top and bottom towards the middle. A person skilled in the art would understand that these are merely examples and that other configurations are possible.

[0545] FIG. 30 shows an example card according to example embodiments. Referring to FIG. 30, the display comprises a first portion 3005, second portion 3010, third portion 3015, and fourth portion 3020. In an embodiment, each of the portions may be updated sequentially, for example first the first portion, followed by the second portion, then the third portion, and finally the fourth portion (though the portions may be updated in any order). In an embodiment two or more of the portions may be updated at the same time, for example all four portions may be updated simultaneously. This may allow for the display to provide different affects, such as updating the display from the center out or from the corners in. A person skilled in the art would understand that these are merely examples and that other configurations are possible.

[0546] FIG. 31 includes electronics package 3100 that may be included, for example, on a circuit board of an interactive payment card such as an interactive debit and/or credit card. Electronics package 3100 may include any number of pressure sensors such as, for example, pressure sensors 3110 and 3120. Person skilled in the art will appreciate that a payment card terminal may be motorized and may automatically receive payment cards. Wheels may be utilized on such a motorized payment card reader to move a card throughout a reader. Such wheels may be detected by one or more pressure sensors. Pressure sensors may be located at any location of a card such as, for example, the top of the card, middle of the card, and/or bottom of the card. Accordingly, one or more pressure sensors about the top of a card may detect one or more wheels about the top of a card. One or more pressure sensors about the middle of a card may detect one or more wheels about the middle of a card. One or more pressure sensors about the bottom of a card may detect one or more wheels about the bottom of a card. Any number of pressure sensors may be utilized to detect a wheel. For example, one, two, three, or more than three pressure sensors may be utilized to detect a wheel. Multiple pressure sensors may be spaced apart so that a wheel moves across the multiple pressure sensors and the movement is detected. Accordingly for example, the time difference between the detection of a wheel by multiple (e.g., two) pressure sensors may be utilized to determine the velocity of a card through a reader. Such a velocity may be utilized, for example, by a card so the card can provide data (e.g., magnetic stripe data such as one, two, or three tracks of magnetic stripe data) at a rate associated with the determined speed. Pressure sensors ma be used in conjunction with other sensors (e.g., capacitive sensors, indicative sensors, hall effect sensors) to assist in determine different types of readers and an interactive payment card may have different firmware for operating in different types of readers (e.g., a first type of motorized reader or a second type of motorized reader). Card may keep stored sensor values from one or more types of sensors and utilize data from these stored values to determine a type of reader and communicate data in a form associated with that reader. For example, magnetic data may be communicated at different speeds, with different leading/trailing zeros, for different tracks, with different delays, etc., for different types of detected readers.

[0547] Pressure sensor 3110 may include conductive traces 3111 and 3112. Pressure sensor 3120 may include conductive traces 3121 and 3122. Persons skilled in the art will appreciate that electronics package 3110 may be placed on a card rotated 90 degrees as shown in FIG. 31 so that a wheel moving from left-to-right or right-to- left on the surface of the card will move over both sensors 3110 and 3120. Sensors 3110 and 3120 may, for example, determine the direction a motorized reader is swiping. Persons skilled in the art will appreciate that motorized readers may move a card through one or more read-heads (e.g., a JIS1 read-head on one side of a card and a JIS-2 read-head on another side of a card) multiple times, for example, if a card is not read on the first try. Accordingly, for example, a processor may utilize information from pressure sensors to change the way data is communicated each time the card is attempted to be read by a motorized reader.

[0548] Flow chart 3150 may be included and may include step 3151 in which a timer is started after a first pressure sensor signal from a first pressure sensor is received. The timer may be stopped, for example, after a second pressure signal from a second pressure sensor is received in step 3152. The time between the two actuations of the pressure sensors may be determined in step 3163 and the distance the wheel traveled may be determined in step 3154 and the velocity the wheel was travelling may be determined in step 3156 and data, such as magnetic stripe data, may be communicated based on such a determined velocity. In step 3154, the distance may be a known distance between pressure sensor 3110 and 3120 (e.g., a known distance from the long axis of pressure sensor 3110 to the long axis of pressure sensor 3120). For example, a transmission rate from a dynamic magnetic stripe communications device may be determined based on a velocity so the transmission rate is approximate to the rate at which a read head may read data for a card traveling at the determined velocity. Multiple velocity bins may be determined and each bin may be associated with different velocity ranges. Once a velocity is determined, a bin may be selected based on the range of the bin and the velocity determined so the bin velocity range matches the determined velocity. A transmission rate associated with the bin may then be utilized. Persons skilled in the art will appreciate that a card may have more than one magnetic stripe data tracks for communication on more than one magnetic communications device. A magnetic communications device may communicate information to a magnetic stripe read- head located on the obverse side of a card (e.g., an EMV contact chip side) such as and one or more magnetic communications devices may communication information to a magnetic stripe read-head located on the reverse side of a card. Accordingly, for example, multiple communications devices may communicate simultaneously to both JIS-1 and JIS-2 read-heads. Different communication processes (e.g., communication rates) may be associated with a particular velocity (e.g., bin velocity range) for different read-heads.

[0549] Persons skilled in the art will appreciate that one or more pressure sensors may be utilized with multiple other types of sensing technologies on a card, or other device. For example, capacitive sensing may be utilized to determine that a read-head of a magnetic stripe reader electronically couples with the capacitive sensing. After capacitive sensing determines a read- head, one or more inductive sensors may be turned ON to confirm a read-head is interfacing with the inductive sensor. Persons skilled in the art will appreciate that inductive sensors may be utilized to determine, for example, the direction a card is being swiped or read by a reader. Inductive sensors may also provide an magnitude and a certain threshold may determine if a read-head is at a certain point with respect to one or more inductive sensors. One or more pressure sensors may be positioned to provide a signal before this inductive sensing threshold is met. Accordingly, velocity of the read-head may be determined and associated magnetic communications device communication attributes may be determined and then utilized when, for example, the inductive threshold is met. Persons skilled in the art will appreciate that one or more pressure sensors may be located close to a card edge (e.g., the left card edge from the obverse side of a card). For example, one or more pressure sensors may be located within an inch, within half an inch, or within a quarter of an inch of a edge of a card.

[0550] Persons skilled in the art will appreciate that capacitive sensing may be OFF while a card is OFF. Turning a card ON (e.g., selecting a payment option and/or account) may, for example, turn capacitive sensing ON. Hall sensors may be utilized to determine a read- head configuration (e.g., whether a read-head is located on one side of a card, both sides of a card, and whether the read heads are aligned with respect to one another or offset and, if offset, which read-head is the first to pass over a card and which read-head is the second to pass over a card). Hall sensors may, for example, activate inducting sensing. Pressure sensor(s) may be positioned to detect one or more wheels before a triggering threshold of an inductive sensing is met. After pressure sensors determine one or more wheels (e.g., as well as a velocity), Hall Sensor data may be utilized to determine a type of reader. For example, certain readers may be fabricated with a particular amount of metal, a reader with a large amount of metal may cause a certain communications attribute (e.g., a particular velocity may be determined and a particular communication data rate may be determined). If the hall effect sensors, for example, do not determine a particular type or types of readers that are associated with particular type or types of communication attributes, a determined velocity may be utilized for communication data rate. Particular types of readers (e.g., readers with a large amount of metal), for example, may utilize a single track of data (e.g., Track 2 data) and other types of readers, for example, may utilize multiple or several tracks of data. Persons skilled in the art will appreciate that any number of pressure sensors (e.g., three or more) may be utilized for a single wheel to determine velocity and change in velocity (e.g., acceleration).

[0551] Persons skilled in the art will appreciate that different firmware routines may be associated with different pressure sensors. For example, one or more pressure sensors may be utilized at the top edge of a card (with respect to an obverse side of a card that includes contact reader contacts). A card may be turned ON, capacitive sensing may turn ON, inductive sensing may be turned ON after capacitive sensing detects a read- head, the pressure sensor may determine a wheel before a threshold of inductive sensing is reached. Card velocity may be determined or, for example, card velocity may be associated with a determined reader associated with a top-edge sensor (e.g., all instances a top-edge pressure sensor detects one or more wheels).

[0552] FIG. 32 shows a view of a pressure sensing system 3201 and cross-section 3230 taken along line A-A' of pressure sensing system 3201. Referring to pressure sensing system 3201 and cross-section 3230, pressure sensing system 3201 may include base layer 3235, separation layer 3215 and pressure sensitive conductive layer 3240 (not shown in pressure sensing system 3201 for clarity of explanation).

[0553] Separation layer 3215 may include spaces 3205 and 3210. Base layer 3235 may include a material (e.g., flex material or thin FR-4), with active area sensors (not shown) on and/or in the material and exposed by spaces 3205. Contacts 3220 may correspond to the active area sensors. For example, one contact may connect to an active area sensor in space 3205, another contact may connect to an active area sensor in space 3210, and a third contact may be a ground (e.g., a contact between the active area sensor contacts).

[0554] Separation layer 3215 may include an adhesive, for example, a double sided pressure sensitive adhesive tape (e.g., bond ply). Separation layer 3215 may be separate pressure sensitive conductive layer 3240 from the active area sensors of base layer 3235 (or on base layer 3235). Pressure sensitive conductive layer 3240 may be a force sensing resistive layer with a resistance varying as a function of applied force. For example, the resistance of pressure sensitive conductive layer 3240 may decrease as force is applied.

[0555] According to some example embodiments, pressure sensing system 3201 may be used in, for example, a powered card. A powered card may be inserted into a motorized reader. A wheel (e.g., feed wheel) of the motorized reader may cross the active are sensors, for example, cross over one active area sensor and then a second active area sensor. Separation layer 3215 may separate pressure sensitive conductive layer 3240 from the active area sensors when no wheel applies pressure, and pressure sensitive conductive layer 3240 may contact the active area sensors through spaces 3205 and 3210 when pressure is applied, for example, by a feed wheel. The resistance of pressure sensitive conductive layer 3240 may decrease and short circuit conductive lines of the active area sensors when the wheel crosses over spaces 3205 and 3210.

[0556] A distance between the centerlines of the two active area sensors of pressure sensing system 3201 and/or the separation between the active area sensors by layer 3215 may be selected so that the active area sensors are close enough together for velocity to be calculated prior to the card being too far into the motorized reader, for timely and/or accurate communication with the reader (e.g., to avoid card read failures).

[0557] According to at least one example embodiment, pressure sensing system 3201 may be connected to a processor of a powered card. Pressure from the wheel of a motorized reader may force pressure sensitive conductive layer 3240 against the active area sensors exposed by spaces 3205 and 3210 and reduce the resistance of pressure sensitive conductive layer 3240 the tracks in the active area sensors together so that the card processor receives a signal indicative of a change in state across terminals (e.g., two terminals).

[0558] Distance 3250 may be 0.5 inches to 1.0 inches, for example, about 0.8 inches (e.g., 0.818 inches). Distance 3255 may be 0.01 inches to 0.03 inches, for example, about 0.02 inches (e.g., 0.021 inches). Distance 3260 may be 0.04 inches to 0.06 inches, for example, about 0.050 inches (e.g., 0.049 inches). Distance 3265 may be 0.01 inches to 0.03 inches, for example, about 0.02 inches (e.g., 0.021 inches). Distance 3270 may be 0.01 inches to 0.02 inches, for example, about 0.15 inches (e.g., 0.151 inches). Distance 3275 may be 0.020 inches to 0.040 inches, for example, about 0.030 inches.

[0559] Persons skilled in the art will appreciate that various elements of different example embodiments may be combined in various ways. Persons skilled in the art will also appreciate that the present invention is not limited to only the embodiments described. Instead, the present invention more generally involves dynamic information. Persons skilled in the art will also appreciate that the apparatus of the present invention may be implemented in other ways than those described herein. All such modifications are within the scope of the present invention, which is limited only by the claims that follow.

[0560] Persons skilled in the art will appreciate that the present invention is not limited to only the embodiments described, and that features described in one embodiment may be used in a different embodiment. The present invention more generally involves dynamic information and devices. Persons skilled in the art will also appreciate that the apparatus of the present invention may be implemented in other ways than those described herein. All such modifications are within the scope of the present invention, which is limited only by the claims that follow.

[0561] FIG. 33 shows card 100 that may include, for example, dynamic magnetic stripe communications device 101, one or more displays (e.g., displays 112, 113 and 125), permanent information 120, light sensor 127, one or more buttons (e.g., buttons 130-134, 198 and 199), lights 135-138, 196 and 197, and dynamic number 114 which may include a permanent portion 111. Permanent portion 111 may be, for example, printed, embossed and/or laser etched on card 100.

[0562] Multiple displays may be provided on card 100 for various purposes. For example, display 112 may display a dynamic number entirely, and/or partially. Display 113 may be utilized to display a dynamic code (e.g., a dynamic security code). Display 125 may display logos, barcodes, and/or one or more lines of information (e.g., may display a coupon code). A display (e.g., at least one of displays 112, 113 and 125) may be a bi- stable display or non bi-stable display. A bi-stable display may be a display that maintains an image without power.

[0563] Card 100 may include permanent information 120 including, for example, information specific to a user (e.g., a user's name and/or username) and/or information specific to a card (e.g., a card issue date and/or a card expiration date).

[0564] Card 100 may include a dynamic magnetic communications device. Such a dynamic magnetic communications device may take the form of a magnetic encoder and/or a magnetic emulator. A magnetic encoder may change the information located on a magnetic medium such that a magnetic stripe reader may read changed magnetic information from the magnetic medium. A magnetic emulator may generate electromagnetic fields that directly communicate data to a magnetic stripe reader. Such a magnetic emulator may communicate data serially to a read-head of the magnetic stripe reader.

[0565] Card 100 may include one or more buttons, for example, buttons 130-134, 198 and 199. Buttons 130-134, 198 and 199 may be, for example, mechanical buttons, capacitive buttons, light sensors and/or a combination thereof.

[0566] Button 199 may be used, for example, to communicate information through dynamic magnetic stripe communications device 101 indicative of a user's desire to communicate a single track of magnetic stripe information. Persons skilled in the art will appreciate that pressing a button (e.g., button 199) may cause information to be communicated through device 101 when an associated read-head detector detects the presence of a read-head of a magnetic stripe reader and/or at a specific frequency. Button 198 may be utilized to communicate (e.g., after button 198 is pressed and after a read-head detects a read-head of a reader) information indicative of a user selection (e.g., to communicate two tracks of magnetic stripe data). Multiple buttons may be provided on a card and each button may be associated with a different user selection.

[0567] Different third party features may be, for example, associated with different buttons and a particular feature may be selected by pressing an associated button. According to at least one example embodiment, button 198 and button 199 may each be associated with, for example, a different third party service provider feature (e.g., an application facilitating a coupon) and may be changed by a user at any time.

[0568] According to some example embodiments, a user may select a third party feature from a list displayed to the user. For example, the user may scroll through a list of features on a display (e.g., display 125). A user may scroll through a list using buttons on a card (e.g., buttons 130-134). The list of features may be displayed to the user individually, in groups and/or all features may be simultaneously displayed.

[0569] According to some example embodiments, a third party feature associated with a button may be changed by a user, for example, on a graphical user interface (GUI) provided by a device provider, ecosystem provider, application manager provider, remote facility provider, card issuer, processor, and/or any other entity (which may be the same or different entities). For example, an ecosystem provider may, on its website and/or via an application, allow a user to change the third party feature performed when the third party's feature button is selected by a user on the user's card or other device. [0570] A third party service provider may provide a reward (e.g., a coupon) from a collection of rewards based on, for example, one or more card transactions. The fact the user has received the reward may be presented on a profile page of the user. When a transaction is performed, a user's profile may be updated to state that the user has earned a reward and the user may receive the reward (e.g., via email). A user may be provided with a GUI, for example, a GUI on a mobile telephonic device of the user, when the user makes a purchase, to identify and/or use the reward earned by the user.

[0571] The selection of a feature may or may not have a cost associated with it. If a cost is associated with the feature, for example, the cost may be added to a customer's statement (e.g., added to a credit or debit purchase) for a particular transaction. A fixed-fee or variable-fee (e.g., a percentage of the transaction) may then be removed from the fee charged to the user and distributed among particular parties (e.g., distributed to the card issuer, application manager provider, ecosystem provider, device provider and/or other entity). The remainder of the fee, if any, may be provided, for example, to the third party service provider.

[0572] A cost may be associated to a feature selection, but may not be a cost to a user. For example, the cost may be a cost to a third party service provider (e.g., an incentive). The cost may be a cost to other entities, for example, the device provider, card issuer, card processor (which may be the same, for example, as the card issuer), and/or any other entity (e.g., card network).

[0573] According to some example embodiments, a user may select a type of payment on card 100 via manual input interfaces (e.g., buttons 130-134). The manual input interfaces may correspond to displayed options (e.g., displayed on display 125). Selected information may be communicated to a magnetic stripe reader via a dynamic magnetic stripe communications device. Selected information may also be communicated to a device (e.g., a mobile telephonic device) including a capacitive sensor and/or other type of touch sensitive sensor.

[0574] Lights 135-138, 196 and 197 (e.g., light emitting diodes), may be associated with buttons 131-134, 198 and 199. Each of lights 135-138, 196 and 197 may indicate, for example, when a button is pressed. In a case where a button may activate card 100 for communications, a light may begin blinking to indicate card 100 is still active (e.g., for a period of time) while reducing power expenditure. Although not shown, a light may be provided for button 130.

[0575] Card 100 may include light sensor 127. Light sensor 127 may, for example, receive information from a light source (e.g., a display of a mobile telephonic device and/or a laptop computer). Card 100 may include, for example, any number of light sensors 127. Light sensor 127 may be utilized such that a display screen, or other light emitting device, may communicate information to light sensors 127 via light. Display 125 may allow a user to select (e.g., via buttons) options on display 125 that instruct the card to communicate (e.g., via a dynamic magnetic stripe communications device, RFID and/or exposed IC chip) to use a debit account, credit account, pre-paid account, and/or point account for a payment transaction.

[0576] Architecture 150 may be utilized with any card (e.g., any card 100). Architecture 150 may include, for example, processor 120, display 140, driving circuitry 141, memory 142, battery 143, radio frequency identification (RFID) 151, integrated circuit (IC) chip 152, electromagnetic field generators 170, 180, and 185, and read-head detectors 171 and 172.

[0577] Processor 120 may be any type of processing device, for example, a central processing unit (CPU) and/or a digital signal processor (DSP). Processor 120 may be, for example, an application specific integrated circuit (ASIC). Processor 120 may include on-board memory for storing information (e.g., triggering code). Any number of components may communicate to processor 120 and/or receive communications from processor 120. For example, one or more displays (e.g., display 140) may be coupled to processor 120. Persons skilled in the art will appreciate that components may be placed between particular components and processor 120. For example, a display driver circuit may be coupled between display 140 and processor 120. [0578] Memory 142 may be coupled to processor 120. Memory 142 may store data, for example, data that is unique to a particular card. Memory 142 may store any type of data. For example, memory 142 may store discretionary data codes associated with buttons of a card (e.g., card 100 of FIG. 33). Discretionary data codes may be recognized by remote servers to effect particular actions. For example, a discretionary data code may be stored in memory 142 and may be used to cause a third party service feature to be performed by a remote server (e.g., a remote server coupled to a third party service such as a coupon provider). Memory 142 may store firmware that, for example, controls triggering and/or the like.

[0579] Architecture 150 may include any number of reader communication devices. For example, architecture 150 may include at least one of IC chip 152, RFID 151 and a magnetic stripe communications device. IC chip 152 may be used to communicate information to an IC chip reader (not illustrated). IC chip 152 may be, for example, an EMV chip. RFID 151 may be used to communicate information to an RFID reader. RFID 151 may be, for example, an RFID tag. A magnetic stripe communications device may be included to communicate information to a magnetic stripe reader. For example, a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

[0580] Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, architecture 150 may include electromagnetic field generators 170, 180, and 185 to communicate separate tracks of information to a magnetic stripe reader. Electromagnetic field generators 170, 180, and 185 may include a coil (e.g., each may include a coil) wrapped around one or more materials (e.g., a soft-magnetic material and a non- magnetic material). Each electromagnetic field generator may communicate information, for example, serially to a receiver of a magnetic stripe reader for a particular magnetic stripe track. According to at least one example embodiment, a single coil may communicate multiple tracks of data.

[0581] Architecture 150 may include read head detectors 171 and 172. Read-head detectors 171 and 172 may be configured to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). Information sensed by the read-head detectors 171 and 172 may be communicated to processor 120 to cause processor 120 to communicate information serially from electromagnetic generators 170, 180, and 185 to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader.

[0582] According to at least one example embodiment, a magnetic stripe communications device may change the information communicated to a magnetic stripe reader at any time. Processor 120 may, for example, communicate user-specific and card-specific information through RFID 151, IC chip 152, and/or electromagnetic generators 170, 180, and 185 to card readers coupled to remote information processing servers (e.g., purchase authorization servers). Driving circuitry 141 may be utilized by processor 120, for example, to control electromagnetic generators 170, 180 and 185.

[0583] Architecture 150 may include, for example, a light sensor. Architecture 150 may receive information from a light sensor. Processor 120 may determine information received by a light sensor.

[0584] FIG. 34 shows device 200 that may be, for example, a mobile telephonic device and/or other device (e.g., portable computer such as a portable tablet computer). Device 200 may include, for example, housing 202, display 210, device card 220, virtual buttons 230, 231 and 240, virtual lights 242-247, dynamic card number and verification code 245, and identification information 250.

[0585] Display 210 may include, for example, light- sensitive and/or touch-sensitive elements. Device 200 may communicate information to a card reader, for example, via a contactless signal (e.g., an RFID signal) and/or a contact-based signal (e.g., a USB connection).

[0586] Device 200 may include a device card 220 and/or virtual buttons 230 and 231. Device card 220 may be a virtual representation of a card and/or any information identifying a payment method (e.g., credit account number). A person skilled in the art will appreciate that any physical card described herein may be provided as a device card on, for example, a computing system (e.g., a mobile telephonic device and/or a computer). Physical buttons of a physical card may, for example, correspond to virtual buttons of a device card.

[0587] Virtual button 230 may, for example, correspond to one feature (e.g., an opportunity to earn a coupon) from a third party service provider while virtual button 231 may, for example, correspond to another feature (e.g., the opportunity to add value to a coupon) from the same or a different third party service provider. According to at least one example embodiment, every feature may not be provided by a third party service provider. Persons skilled in the art will appreciate that, for example, the device provider may provide features.

[0588] All features for a card may be utilized with a particular payment account (e.g., a credit account) such that a payment transaction with that payment account is performed if any feature is selected. As another example, one or more features may be associated with a payment account (e.g., a credit account) while an additional one or more features may be associated with a different payment account (e.g., a debit account). Accordingly, a selected feature associated with a credit account may be utilized to make a purchase with credit and may perform an additional action associated with that feature. A different selected feature associated with a debit account may be utilized to make a purchase with debit and may perform an additional action associated with that different feature.

[0589] Device 200 may include virtual lights 242-247. Virtual lights 242-247 may, for example, indicate an active period during which device 200 may communicate with external devices. Virtual lights 242-247 may correspond to, for example, virtual buttons 230, 231 and 240. According to example embodiments, a fewer or greater number of virtual lights are contemplated (e.g., a center button of virtual buttons 240 may virtually light up).

[0590] FIG. 35 shows network topology 300 that may include, for example, mobile device 302, contactless device 304, cellular network access infrastructure 306, mobile network 310, wireless access point 308, IP network 312, payment network 314, issuer 320, payment server 316, merchant acquirer 317, ecosystem provider 342, merchant terminal 318, transaction card 333, user electronic device 345 and/or application providers 338, 339 and 340. [0591] Mobile device 302 (e.g., a mobile telephonic device, a PDA, an electronic tablet, a laptop, a GPS unit, and/or an MP3 player) may include, for example, a contactless interface that may initiate, sustain, and/or terminate communication channel 326 between contactless device 304 (e.g., a powered card, non-powered card and/or a device) and mobile device 302. Contactless device 304 and mobile device 302 may communicate via channel 326 using any number of contactless mediums, which may include for example, visible, audible, capacitive, electromagnetic, magnetic, and/or RF mediums.

[0592] Mobile device 302 may provide one or more transceivers, receivers and/or transmitters that may communicate with one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks (e.g., a mobile network 310). Mobile device 302 may, for example, communicate with a cellular station over a wireless radio interface (e.g., a GSM air interface) that may be used by mobile device 302 to communicate information (e.g., voice and data) to cellular network access infrastructure 306 (e.g., one or more GSM base transceiver stations, base station controllers and mobile switching centers). Persons skilled in the art will appreciate that cellular network access infrastructure 306 may utilize any multiple access architecture, such as for example, a code-division multiple access architecture and/or a time-division multiple access architecture.

[0593] Mobile device 302 may, for example, communicate with wireless access point 308 over a wireless interface (e.g., a Bluetooth interface or a Wi-Fi interface). Accordingly, for example, mobile device 302 may access one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network) without the need to first gain access to cellular network access infrastructure 306.

[0594] Payment information (e.g., a payment account number and a card expiration date) may be communicated from contactless device 304 to mobile device 302 in support of a transaction (e.g., a financial transaction) being conducted by mobile device 302. In so doing, for example, items for purchase on IP network 312 (e.g., the internet) may be accessed by a browser of mobile device 302 via an access point (e.g., wireless access point 308 and/or cellular network access infrastructure 306). Mobile device 302 may, for example, complete a purchase transaction by first obtaining required payment information from contactless device 304 and then communicating such payment information to network entities (e.g., merchant acquirer 317, payment server 316 and/or issuer 320). Mobile device 302 may, for example, already contain payment information necessary to complete a purchase transaction. Accordingly, mobile device may not need to obtain payment information from contactless device 304 before completing a purchase transaction.

[0595] Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with payment information received from mobile device 302 for authorization of a purchase. Once authorized, payment transaction information may be recorded onto a receipt that may be delivered to mobile device 302 via any one or more delivery options (e.g., via a short messaging service of mobile network 310 or an email delivery service of IP network 312).

[0596] A payment receipt may, for example, be provided to mobile device 302 as a proof-of-purchase object (e.g., a barcode) that may be provided to a display of mobile device 302 and read by other computing equipment (e.g., a barcode scanner) for proof-of-purchase confirmation.

[0597] Transaction card 333 (e.g., a powered card, non-powered card and/or device card) may, for example, communicate information to merchant terminal 318 (e.g., a magnetic stripe reader, an EMV reader, an RFID reader, an NFC reader and/or a swipe reader attached to an electronic device). Merchant terminal 318 may begin transactions (e.g., point-of-sale transactions) and/or complete transactions via merchant acquirer 317 and/or payment network 314. Accordingly, for example, transaction card 333 may communicate payment information to merchant terminal 318 to initiate a financial transaction.

[0598] Merchant terminal 318 may communicate transaction information, including at least a portion of the payment information, to merchant acquirer 317. Merchant acquirer 317 may authorize the financial transaction and/or communicate with payment server 316. Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with transaction information received from merchant acquirer

318 and may be recorded onto a receipt by merchant terminal 318.

[0599] Application providers 338, 339 and 340 may be one or more entities (e.g., one or more servers) providing applications for association in an ecosystem provided by ecosystem provider 342. Each application may provide one or more features to users of a payment method (e.g., users of contactless device 304 and/or transaction card 333). For example, an application may provide a user an opportunity to earn a coupon and/or add value to a coupon in exchange for using the payment method. According to at least one example embodiment, application provider 338 may provide coupons as part of a loyalty or rewards program, which may be independent of any payment method. Ecosystem provider 342 may be, for example, a server that maintains associations between applications, users and payment methods.

[0600] Ecosystem provider 342, and application providers 338, 339 and 340, may communicate with different entities using one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network). Application providers 338, 339 and 340 may communicate directly and/or indirectly with different entities. For example, merchant terminal 318 and/or ecosystem provider 342 may communicate directly with application providers 338, 339 and 340 via IP network 312 and/or via a direct connection (e.g., to validate coupons with a coupon server). As another example, application providers 338, 339 and 340 may exchange information (e.g., transactional data) indirectly with issuer 320, merchant acquirer 317 and/or payment network 314 via, for example, ecosystem provider 342.

[0601] A user electronic device (e.g., mobile device 302 and/or a wired user electronic device 345) may display a GUI. The GUI may be an application manager used to interface with ecosystem provider 342, and application providers 338, 339 and 340, to define user preferences. Defining user preferences may include, for example, configuring associations (e.g., between users, applications and payment methods), features and/or permissions.

[0602] In order to configure associations, the GUI displayed on the user electronic device may, for example, display indicia representing applications that provide features. A user may associate one or more of the applications to one or more payment cards and/or payment card buttons (e.g., mobile device 302 and/or transaction card 333)).

[0603] In order to configure one or more features provided by an application, the GUI displayed on the user electronic device may be used to, for example, interface with one or more of application providers 338, 339 and 340. For example, using the GUI, a user may select a coupon from among multiple coupons provided by an application hosted by an application provider.

[0604] In order to configure associations, a user may use the GUI displayed on the user electronic device to define how payment network 314, ecosystem provider 342, one or more of application providers 338, 339 and 340, and third-party applications hosted by the one or more application providers (or any other application providing entity) interact for transactions conducted by the user. [0605] For example, a user may accept an end license user agreement that outlines how data may be shared between entities. As another example, a user may define what data may be shared between entities. For example, where data (e.g., transactional data) may be provided to ecosystem provider 342 by payment network 314, and/or provided to one or more of application providers 338, 339 and 340 by ecosystem provider 342, a user may select at least a portion of data provided to ecosystem provider 342 by payment network 314, and select at least a portion of data to be shared with the one or more of application providers 338, 339 and 340.

[0606] Prior to presenting transaction card 333 to merchant terminal 318 to initiate a transaction, a customer may select (e.g., via one or more button presses on a powered card and/or device card) an application to be associated to the transaction. Based on the selection, one or more additional actions may be taken besides the processing of the transaction by payment network 314. For example, a user may press a button on a powered card (e.g., transaction card 333). Upon presenting transaction card 333 to merchant terminal 318, a payment message (e.g., a magnetic stripe message) reflecting the button that was pressed may be communicated to merchant terminal 318. Merchant terminal 318 may communicate a data string including the payment message and transaction information to payment network 314 via merchant acquirer 317.

[0607] Payment network 314 may receive the data string. The data string may include a directive instructing payment network 314 to share data with ecosystem provider 342. According to at least one example embodiment, payment network 314 may share data with ecosystem provider 342 upon receiving the data string and recognizing, based on at least a portion of the data string (e.g., an account number), that data is to be shared. Payment network 314 may cause the same or a different data string to be communicated from payment network 314 (e.g., from a processor within payment network 314) to ecosystem provider 342. [0608] Although example embodiments describe a payment network communicating data to an ecosystem provider, alternatively and/or additionally, an issuer and/or a processor of an issuer may receive data and communicate at least a portion of the data and/or different data based on the received data to ecosystem provider 342. For example, a processor of issuer 320 may parse a data string received from merchant terminal 318 (e.g., via payment network 314) that includes a particular BIN number, may convert the data string into a different format and may forward the converted data string to ecosystem provider 342. Persons of ordinary skill in possession of example embodiments will appreciate that many different messaging schemes may be used.

[0609] Ecosystem provider 342 may receive the data string and compare user information (e.g., payment account number and/or payment account holder's name) that may be included within the data string to a user database to obtain a customer ID (e.g., a customer token) associated with the user information.

[0610] According to at least one example embodiment, sensitive information within the data string (e.g., payment account number and/or payment account holder's name) may be replaced with the customer ID to create a modified data string, and the sensitive information may be stored either locally within ecosystem provider 342 or remotely to ecosystem provider 342. The modified data string may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312.

[0611] According to at least one example embodiment, ecosystem provider 342 may receive the data string. The data string may be populated with information that may be indicative of which button was pressed on the powered card before being presented to merchant terminal 318. Using the button information and user preferences, ecosystem provider 342 may generate a third-party message with details that may be shared with a third-party application (e.g., one or more of application providers 338, 339 and 340). The generated data string may include the customer ID and may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312.

[0612] A user may elect to share certain transaction information with one or more of application providers 338, 339 and 340 each time a certain button is pressed on the user's powered card before presentment to merchant terminal 318 for payment. Such information may include, for example, merchant information (e.g., merchant's address), date/time information of a purchase, an amount of the purchase, a type of the purchase, and any other information (e.g., the customer ID associated with the customer's merchant account). The various pieces of the transaction information may or may not be selected for sharing by the user via the user preferences.

[0613] According to at least one example embodiment, a user may agree to share data during a registration process with an application provider (e.g., via an end user license agreement). Upon receiving a data string, the sharable data may be automatically populated within a third-party message and communicated to an application provider via IP network 312.

[0614] Upon receipt of the third-party message, the application provider (e.g., one or more of application providers 338, 339 and 340) may enact a feature provided to a user (e.g., provide a coupon). The application provider may initiate a second transaction (e.g., a piggyback transaction, a statement credit and/or the like). The second transaction may be communicated to ecosystem provider 342 via IP network 312 (e.g., the internet) and processed by ecosystem provider 342 accordingly. For example, ecosystem provider 342 may determine whether a second transaction is permitted and/or forward information associated with the second transaction to another entity (e.g., issuer 320).

[0615] According to some example embodiments, a GUI may, for example, be rendered onto a display of a user's card or other device (e.g., mobile device 302, user electronic device 345, transaction card 333 and/or contactless device 304). The GUI may display indicia of one or more third-party applications (e.g., provided by one or more application providers 338, 339 and 340) along with summary and/or detailed information. Based upon information gleaned from the information concerning the applications, the user may be better informed as to which third-party applications he or she may wish to associate with his or her powered or non-powered card. Accordingly, the whimsical and festive nature of a user's experience with a GUI rendered by an electronic device may be further enhanced.

[0616] According to example embodiments, an application provider may be any entity. For example, ecosystem provider 342 may be an application provider in addition to providing an ecosystem. According to at least one example embodiment, an application provider may be a third-party application provider and ecosystem provider 342 may host the third party application (e.g., provide coupons). Data sharing may be the same or different based on a particular configuration.

[0617] FIG. 36 shows device 400 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 401. Device 400 may include a processor that may render GUI 403 onto display 401. GUI 403 may be an application manager. Using GUI 403, a user may associate a payment method card (e.g., a powered physical card, non-powered physical card and/or device card) with third party service features within an ecosystem. GUI 403 may be displayed on display 401, for example, a computer monitor, mobile phone touch screen and/or the like. GUI 403 may be, for example, provided as an application for a device (e.g., a computer, a portable computing device and/or a mobile telephonic device) and/or retrieved information from a web browser.

[0618] An application manager may be provided, for example, on a remote facility and displayed via GUI 403 to allow a user to change the third party service features associated with a card. An application manager may manage an ecosystem of applications and payment method cards, and the user may utilize GUI 403 to, for example, associate a particular feature to a particular payment method card at any time. The user may associate the selected feature with a card and/or a card button.

[0619] Persons skilled in the art will appreciate that a default feature may be provided and/or that a number of features provided by a card issuer or other entity may be provided in addition to third party service features. For example, a card issuer may provide a card with a default of credit on one button and a default of decoupled debit on a second button. A user may press the first button to perform a credit transaction. A user may press the second button to perform a decoupled debit transaction.

[0620] GUI 403 may include tabs 405, information 411, virtual card 412, virtual indicia 413 and 414, slider 415, application identifiers 423 and 426, and selection options 428, 431, 432, 441-443 and 446.

[0621] Virtual card 412 may be provided as a representation of a user's physical and/or device card. A user may be provided with the ability to change between multiple different cards and configure the features associated with those multiple cards. Accordingly, virtual card 412 may be provided with indicia 413 in the configuration of, and indicative of, one button of a user's card, and virtual card 412 may be provided with indicia 414 in the configuration of, and indicative of, another button of a user's card. Indicia 413 and 414 may display the applications currently associated to each button (e.g., an application icon). A slider 415 may be provided to indicate which of applications associated with a button may be a default application (e.g., for online, telephonic and/or non-powered card transactions). Accordingly, a user may, for example, view virtual card 412 in order to refresh the user's memory with respect to the features associated with the buttons on a user's physical and/or device card.

[0622] A list of applications may be provided on GUI 403. Each application may provide one or more third party service provider features. In order to associate a particular feature with a particular card and/or one or more buttons on a card, a user may associate an application providing the feature to the card and/or card button(s). For example, selection 431 may associate application 423 to the button of a card associated with virtual button 413. Selection 432 may associate application 426 to the button of a card associated with virtual button 414. Accordingly, a user may change the features associated to a card by using GUI 403. In order to view the features provided by a particular application the user may, for example, select an "explore" button to view relevant information (e.g., selection 446).

[0623] The list of applications provided on GUI 403 may be, for example, all applications or a limited subset of all applications available to a user via an ecosystem provider. For example, in order to view all available applications, tab 402 may be selected by a user (e.g., with a keyboard, mouse, touch sensitive screen and/or electronic pointer) to display an application manager home view. In order to view a limited subset of applications a user may select a different tab. For example, tab 403 may be selected by a user to display a featured view including featured applications (e.g., applications-of-the-week). Other tabs may sort applications by category, use and/or the like.

[0624] Selections 428 may be selections used to activate an application with respect to the user. Activation may include registration with a third party application, acceptance of an end users license agreement associated with the application, and/or the like. Activation may also include selecting a particular feature from among multiple features provided by the application. According to at least one example embodiment, some applications may not require activation (e.g., single feature, non-interactive applications).

[0625] Once an application is activated and/or associated to a card and/or card button, a user may begin experiencing a selected feature by engaging in card transactions. For example, the user may press a card button associated with a desired feature during a card transaction. A physical and/or device card (not shown) may communicate information indicative of a button that was pressed on the physical and/or device card, along with or separate from other payment data (e.g., an account number, security code, and other data). For example, information indicative of the button that was pressed may be included in discretionary data of a payment message. A payment message may be, for example, one or more tracks of magnetic stripe data (e.g., communicated from a dynamic magnetic stripe communications device), an RFID message (e.g., a near field communication (NFC) message from a radio frequency antenna), and/or an exposed IC chip message (e.g., an EMV message) from an exposed IC chip.

[0626] The information indicative of which button was pressed may be passed to a card issuer and/or processor from a point-of-sale and any intermediary devices (e.g., a merchant acquirer processing server). The information may be passed to a remote facility (e.g., a facility providing an application manager) such that the remote facility may determine the button that was pressed by a user. This remote facility may, in turn, retrieve information associated with the third party feature (and/or a feature of a card issuer, processor, application manager provider, and/or any entity) and forward information to that feature provider such that the feature may be performed. Information may additionally and/or alternatively be provided from the feature provider to the entity that provided the information indicative of the button that the user pressed.

[0627] Persons skilled in the art will appreciate that if, for example, a non-powered card is utilized then information indicating that a button was pressed may not be available. With respect to a non-powered card, information indicative that a purchase was made may be provided to an application manager provider such that the application manager provider can initiate the desired feature for the non-powered card. For example, the feature may be a default feature, a selected feature (e.g., selected using an application manager) and/or a random feature.

[0628] For non-powered cards, for example, features may be associated with different types of purchases. For example, one feature may be provided for a particular merchant type (e.g., a grocer's coupon) and another feature may be provided for a different merchant type (e.g., a clothing store coupon). Features may be associated with other characteristics of a purchase such as, for example, a purchase above a particular amount (e.g., at or above $100) and/or a purchase below a particular amount (e.g., below $100). However, such additional feature selections are not limited to non- powered cards and may be provided to, for example, users of powered cards and devices.

[0629] According to example embodiments, any feature and/or capability not requiring a powered device (e.g., a computing device such as a powered card and/or mobile telephonic device) may be implemented with respect to a non-powered card and any feature and/or capability of a non-powered card may be implemented with respect to a powered card. According to at least one example embodiment, features and/or capabilities requiring a powered card may be implemented with respect to a non- powered card in various ways. For example, additional functionality may be provided at merchant terminals. [0630] GUI 403 may be provided, for example, on a card issuer's and/or application manager provider's website. GUI 403 may be provided, for example, on a bill statement web page. Accordingly, a user may utilize the application manager to manage application features when the user is logged into his/her account. Although example embodiments described with respect to FIG. 4 may describe a GUI 403 used to make various selections and/or associations, persons skilled in the art will appreciate that other methods are possible. For example, selections may be made by phone, email and/or the like.

[0631] A third party service provider may utilize GUI 403 as part of a user's administration and/or experience of that third party service. For example, a user's profile page for a third party service may include GUI 403. An application manager provider may provide web- code that retrieves GUI 403 from a remote facility managed by the application manager provider and/or other entity (e.g., issuer, merchant acquirer, payment network, merchant and/or the like). Selection 441 may be utilized by a user to check for updates (e.g., confirm that a feature was changed and/or if any updates are present). Selection 442 may be utilized to explain the functionality of a particular application feature. Selection 443 may be utilized for additional selection options, for example, changing which card is displayed on an application manager.

[0632] According to at least one example embodiment, a card may be provided with one button for a particular payment account (e.g., credit) and one button for a changeable feature. Accordingly, a user may, for example, only need to remember one feature associated with a card. A credit account may include rewards, for example, points, cashback, and/or miles, from the card issuer. Accordingly, pushing the payment account button may earn the user such rewards. Pushing the changeable feature button may, alternatively, for example, not earn the user such rewards and may instead initiate a changeable feature. In doing so, for example, the cost of providing a card may be reduced in that the cost of rewards for the card may be reduced. A feature may include, for example, a feature from a third party application provider. The feature from the third party application provider may be, for example, a random reward (e.g., a random coupon).

[0633] Information 411 may, for example, identify the user and card number associated with virtual card 412 and a corresponding physical card. One or more of tabs 405 may provide, for example, a history of purchases made by a user. An application manager may provide indicia reflecting a user rating (e.g., star rating 447).

[0634] According to example embodiments, an ecosystem provider may be the same or different from an application manager provider, a remote facility and/or other entities. One or more of the functions described herein as being performed by an application manager provider, and/or other entities, may be performed by the ecosystem provider. According to at least one example embodiment, an ecosystem provider may act as an application manager provider, application provider, issuer, merchant, third party service provider, payment network and/or the like to provide an end-to-end experience. In general, example embodiments contemplate the same, greater and/or fewer entities, and specific entities are described for purposes of explanation.

[0635] One of ordinary skill in the art will appreciate that GUI 403 is provided for purposes of illustration only and may take various forms. For example, features may be associated to a card without buttons and/or a card may include the same, fewer and/or a greater number of buttons than depicted in FIG. 4.

[0636] FIG. 37 shows device 500 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 501. Device 500 may include a processor that may render GUI 502 onto display 501. GUI 502 may be an application interface usable to manage a user's experience with an application. GUI 502 may be used to, for example, configure application settings, receive information from an application provider, and/or communicate information to an application provider.

[0637] GUI 502 may include, for example, application screens 503, 507, 524, 542 and 550, tabs 505, 520, 540 and 545, information displays 510, 513, 523, 525, 527, 530 and 543, and selections 535 and 547.

[0638] Information display 503 may include, for example, information related to an application provider. For example, information display 503 may display the name and a brief history of the application provider.

[0639] Tab 505 may be used to display application screen 507 and may include a descriptor associated with application screen 507 (e.g., "How It Works"). Although example embodiments may be described with respect to tabs, persons skilled in the art will appreciate that tabs are used for purposes of explanation only. For example, redirection links may be provided to redirect a user to a configuration screen of an application provider. According to at least one example embodiment, tab 505 may be an information display without tab functionality.

[0640] Application screen 507 may be a configuration and/or informational screen for an application, and may display information explaining a feature provided by the application. For example, application screen 507 may include information indicating that a coupon will be provided to a user once the user meets or exceeds a performance metric.

[0641] A coupon may be, for example, a voucher entitling a user to a discount and/or a rebate. The discount and/or rebate may be associated with a particular product, a purchase from a particular vendor and/or the like. A performance metric may define, for example, a transactional event. For example, a performance metric may include a purchase with a card (e.g., a physical and/or device card), a sequence of purchases (e.g., ten purchases) with a card, and/or spending a target amount with a card. Any purchasing and/or non-purchasing transactional event is contemplated by example embodiments. For example, a performance metric may involve a rate of transactions (e.g., checkout 5 books from a library in 10 minutes), a pattern of transactions (e.g., purchase 10 different items from 10 different stores), a target transaction (e.g., purchase a particular item) and/or the like.

[0642] Application screen 507 may include information displays 510 and 513. Information display 513 may include a representation of a type of reward, for example, an image representing a coupon. Information display 510 may display a representation of a performance metric, for example, a monetary value and a payment method. Accordingly, for example, application screen 507 may indicate that a user of a payment method (e.g., a powered card) may receive a coupon and/or increase the value of a coupon each time the user spends an amount indicated in information display 510 using the payment method indicated in display 510.

[0643] A coupon provided by an application provider may be selected in various ways. For example, a coupon may be randomly selected, may be selected by a user (e.g., from a list of coupons) and/or may be selected based on transactional information (e.g., data related to a purchase, a user purchase history and/or the like). The coupon may be selected prior to or after completion of the performance metric.

[0644] Each coupon may have a face value (e.g., a normal coupon value) and may be increased in value based on a value of the performance metric (e.g., a value to the application provider). For example, where a performance metric includes spending $100, $200 or $300, a value of the coupon may be 200% at the $100 level, 400% at the $200 level and 800% at the $300 level. A user may or may not select a level of the performance metric (not shown).

[0645] Tabs 520 may be used to display application screen 524. Application screen 524 may include, for example, information displays 525, 527 and 530, and selections 535. Information displays 525, 527 and 530 may, for example, display representations of redeemable coupons earned by a user. Selection 535 may be used to change one or more of the coupon representations displayed in application screen 524 (e.g., to cycle through available coupons). A user may, for example, select one of the representations to use the associated coupon for a specific purchase. Additionally and/or alternatively, the coupon may be applied at any time the coupon is usable according to a user selection and/or by default (e.g., a coupon applied to the purchase of a specific product and/or in a specific store as a default).

[0646] Each of information displays 525, 527 and 530 may display information associated with a coupon in addition to, or alternatively to, the representation of the coupon. For example, the information may include a description of the value provided by the coupon, a description of added value to a base value of the coupon, an expiration date of the coupon and/or any other coupon related information (e.g., within the representation and/or beneath the representation). According to at least one example embodiment, each representation of a coupon may be a progress meter. According to some example embodiments, a user may build a coupon by selecting various information (e.g., base value, added value, expiration date and/or the like).

[0647] Tabs 540 may include one or more tabs used to display one or more application screens 542. One of tabs 540 may be used to select an application screen including an information display listing earned coupons. For example, each of information displays 525, 527 and 530 may be selections representing categories of coupons. A user may select information display 525 to display, for example, a list of earned coupons related to food in information display 543. A user may select information display 527 to display, for example, a list of earned coupons related to small appliances in information display 543. A user may select information display 530 to display, for example, a list of earned coupons related to prepared beverages in information display 543.

[0648] According to some example embodiments, a list of earned coupons may also include, for example, unearned coupons. The unearned coupons may be visually distinguishable from the earned coupons (e.g., a different color and/or shading). Each displayed coupon may be, for example, a selection that may be used to begin earning the coupon, retrieve information associated with the coupon and/or the like. According to some example embodiments, more than one of information displays 525, 527 and 530 may be selected simultaneously. [0649] One of tabs 540 may be selected to display a redemption history in information display 543. A redemption history may, for example, display a purchase description and an amount saved. As another example, one of tabs 540 may be selected to display a transaction history. A transaction history may include, for example, information indicating a type of transaction (e.g., purchase), an amount spent, a date of the transaction and/or line items indicating that one or more coupons have been earned in relation to the transaction.

[0650] Tab 545 may selected to display application screen 550. Application screen 550 may include selection 547. Upon selecting selection 547, a user (having met a performance metric) may activate an earned coupon. As one example, a user may select a coupon from among multiple, available coupons and then press selection 547 to render the selected coupon usable. As another example, the application provider may randomly select a coupon earned by the user and the user may press selection 547 to render the randomly determined coupon usable. Selection 547 may include an information display (e.g., "$40 spent, press to redeem for coupon"). According to at least one example embodiment, selection 547 may not be included and a coupon may be automatically activated by the application provider (e.g., based on user settings).

[0651] A user may be notified by an application provider when a coupon is earned and/or additional value is added to the coupon. The application provider may utilize user submitted notification settings to notify the user. Once notified, a user may activate a coupon for a particular purchase and/or for any purchase (e.g., to be used when applicable). Once a coupon is activated, the user may initiate a purchase using a payment method (e.g., powered card) and an activated coupon may be associated to the purchase (e.g., manually and/or automatically associated to the purchase). For example, an application provider may receive transactional data indicating a type of product and/or a location of a purchase, search a list of coupons earned by a user and associate any applicable coupons to the purchase based on the transactional data. If any coupons are associated to the purchase, value may be provided to the user (e.g., via a statement credit), for example, immediately, at authorization, at settlement and/or in a number of days. Alternatively or additionally, the application provider may attach the coupon and/or a number associated with the coupon, for example, to an email. A user may print the coupon and/or use number associated with the coupon (e.g., for an internet purchase).

[0652] Persons of ordinary skill in possession of example embodiments will appreciate that many different notification and reward fulfillment methods may be used. For example, a user may be notified of a reward or receive a reward via email, telephonic data transfer (e.g., text messaging), telegram and/or the like. According to at least some example embodiments, no notification may be provided and/or a user may be required to retrieve a coupon (e.g., via a GUI). According to at least one example embodiment, a coupon may be transmitted to a user's powered card and the powered card may be operable to display a barcode usable at, for example, a retail establishment.

[0653] A selection may be included to activate functionality by which outright purchases of a coupon and/or contributions towards a coupon may be made (not shown). Purchases and/or contributions may be made using, for example, piggyback charges, third party charges, direct purchases and/or the like.

[0654] A piggyback charge may be a statement debit (charge) added to a user statement, for example, for each purchase using a card and/or a device card. A user may select an amount and/or frequency of the piggyback charge using, for example, GUI 502 (not shown). According to at least one example embodiment, a user may earn a coupon and/or increase the value of a coupon for each piggy back charge.

[0655] A third party charge may be a monetary value provided by an application provider, for example, upon a user meeting an incentive performance metric in addition or alternatively to using the payment method (e.g., making purchases at a specific store and/or buying a specific product). A direct purchase may be a partial or complete purchase of a feature by a user that is not attached to any other purchase. For example, a vendor may provide functionality by which a user may swipe a card and/or otherwise communicate data of a card to partially or wholly purchase a coupon without also purchasing any item from the vendor.

[0656] According to some example embodiments, a user may configure an application using GUI 502 to earn coupons and/or add value to coupons not included as a default selection on GUI 502. For example, GUI 502 may include a blank information display (not shown). A feature provider may provide 'drag-and-drop' coupon icons (e.g., on a feature provider website) representing the reward. A user may drag the icon onto GUI 502 and GUI 502 may be automatically modified to include the coupon. The icon transfer may include feature provider information, for example, information invisible to a user that may be used by an application. The coupon provider may provide special incentives for a limited time (e.g., Black Friday), as a customer acquisition tool, as a customer retention tool, and/or the like. The coupon may be a unique coupon not available outside of an ecosystem. [0657] As one non-limiting example, GUI 502 may display a configurable coupon application. A user may select from coupons provided by different retail outlets. The user may drag an icon from a webpage of a particular retail outlet onto the configurable application. The user may drag an icon from a webpage of a different retail outlet onto the configurable application. Both icons may appear on the configurable application. Accordingly, an application may not be limited to a specific retailer and/or coupon provider, and may enhance the whimsical and festive nature of a feature provided to a user.

[0658] An application accessed using GUI 502 may include configurable functionality to improve a user experience. For example, a representation of each coupon earned by the user may be publically and/or privately displayed when earned (and/or a progression display may be updated). For example, coupon information may be displayed on a user's social networking page, on a physical display at chosen location and/or the like. In order to provide configurable functionality, an application provider and/or an application of an application provider may be associated to the user during, for example, an activation process. A user requesting access to an application may be prompted for information. The information may include, for example, security credentials used to access a social networking site associated with the user.

[0659] Selections may, for example, activate an additional and/or alternative feature. For example, a selection (not shown) may be used to pay an amount corresponding to completion of the performance metric displayed in information display 510. As one example, if a user is required to spend $100 to earn a coupon, the value of the feature is $10, and the user has spent $50 using the payment method, the user may pay the coupon provider $5 (the difference in value). The amount may be, for example, immediately charged via GUI 502 and/or may be attached as a piggyback charge to a purchase (e.g., a next purchase using a card and/or a device card). Accordingly, a user may take advantage of limited time offers even where the user does not expect to complete a performance metric within the limited time. The whimsical and festive nature of a coupon application may therefore be enhanced.

[0660] FIG. 38 shows process flow chart 600. An application provider may receive user configuration selections (e.g., as in step 610) and transactional data from, for example, an application manager provider (e.g., as in step 620). The application provider may associate the transactional data with a user and determine if a performance metric has been completed (e.g., as in step 630). If a performance metric has not been completed, the application provider may update one or more information displays based on the received transactional data (e.g., as in step 640). If a performance metric has been completed, the application provider may display a completion message to a user and update one or more information displays (e.g., as in step 650). A value (e.g., coupon) may be transmitted to, for example, the payment method user (e.g., as in step 660).

[0661] According to one non-limiting example embodiment, a coupon provider may receive a user feature selection. The coupon provider may receive transactional information, for example, information indicative of a feature selected by a user (e.g., via a telephone device card, powered card and/or the like) and transactional information related to a payment card (e.g., a number of transactions performed by the user with the payment card, an amount spent and/or the like). Based on the information, the coupon provider may determine if a performance metric has been completed. For example, a performance metric may include ten user purchases using a powered credit card. If the user has not completed ten purchases using the powered credit card, a progression display (e.g., a progress meter) may be updated (e.g., if applicable). If the transactional metric has been met, an email may be sent notifying the user that the coupon has been earned. One or more progression displays may be updated and the coupon may be communicated to the user. According to at least one example embodiment, the notification and coupon may be communicated to the user in the same email message.

[0662] According to at least one example embodiment a coupon code may be communicated to the user. According to at least one other example embodiment, a user may be notified that a coupon code and/or a coupon is available electronically (e.g., accessed from an application manager).

[0663] FIG. 39 shows device 700 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer and/or an electronic tablet) that may include display 701. Device 700 may include a processor that may render GUI 702 onto display 701. GUI 702 may be an application interface usable to manage a user's experience with an application. For example, GUI 702 may be used to configure application settings, receive information from an application provider, communicate information to an application provider and/or the like. [0664] GUI 702 may include, for example, tabs 703, 718, 730 and 763, application screens 707, 723, 752 and 773, information displays 710, 713, 715, 727, 733, 737, 740, 743, 753, 755, 757 and 760, progress meter 725, entry fields 767 and 775, and selections 765, 770 and 777.

[0665] Tab 703 may be used to display application screen 707 and may include a descriptor associated with application screen 707 (e.g., "How It Works"). Upon selecting tab 703, application screen 707 may be displayed to a user. Application screen 707 may be a configuration screen for an application and may include information explaining features provided by the application. For example, application screen 705 may display different configurable, selectable features, along with explanatory information associated with each feature. According to at least one example embodiment, application screen may not be a configuration screen and may be an information screen. A feature may not be configurable and/or selectable (e.g., a set feature) and static feature information may be displayed.

[0666] A feature provided by an application may provide a user selected reward once a user meets or exceeds a performance metric. Alternatively and/or additionally, a feature provided by an application may provide a random reward from a collection of rewards once a user meets or exceeds a performance metric. The reward may be provided by the application provider upon a user meeting or exceeding the performance metric. An example of a performance metric may include a user completing one or more purchases meeting or exceeding a monetary value using a payment card.

[0667] A feature provided by an application provider may be represented by, for example, information displays 710, 713 and 715. For example, information display 713 may display an image representing a collection of different rewards. Information display 710 may display information associated with a performance metric. The performance metric may be, as one example, a transactional based performance metric represented by an image of a payment card and a monetary value. Information display 715 may include information associated with the performance metric and/or the collection of rewards. For example, information display 715 may notify a user that shopping at a particular store will earn additional rewards, and/or notify a user as to the odds of winning any one of the rewards from the collection of rewards. [0668] As one non-limiting example, application screen 707 may include information describing that a user may earn one random reward from a collection of rewards upon spending at least a monetary value (e.g., $6,000) using a payment method (e.g., a smartphone payment card). If the payment method is used to make purchases from a store (e.g., a particular store associated with the application) the amount spent in order to earn the reward may be reduced (e.g., earn a reward twice as fast).

[0669] Upon selecting tab 718, application screen 723 may be displayed to a user. Application screen 723 may include progress meter 725 and information display 727. Progress meter 725 may indicate user progress towards completing a performance metric. Progress meter 725 may be any type of progress meter. For example, a progress meter may be represented as a thermometer with a temperature scale replaced by a monetary scale (e.g., $0- $6,000). By viewing progress meter 725, a user may gauge progress towards a reward. Information display 727 may, for example, display an exact amount spent towards earning the reward.

[0670] A type of progress meter 725 is not limited. For example, an application provider may be an actress named 'Dynama Lemon.' The application provider may display a representation of a lemon. The representation may be, for example, a black and white outline. As progress is made towards completing the performance metric, the representation of the lemon may be progressively colored-in to demonstrate progress.

[0671] Upon selecting tab 730, application screen 752 may be displayed to a user. Application screen 752 may provide details with respect to the representation of the collection of rewards displayed in information display 713, and may include, for example, information displays 737, 740, 743, 753, 755, 757 and 760. Information displays 737, 740 and 743 may each display a representation of, for example, a coupon (e.g., different coupons) and information related to each coupon (e.g., an additional value associated with a coupon when the payment method is used to buy specific products). Information displays 753, 755, 757 and 760 may each display a representation of a tangible item and a description of the tangible item. The coupons and tangible items may be a collection of rewards from which a reward may be randomly awarded to the payment method user upon completion of the performance metric. Selection 765 may be a redemption button that may be used upon completion of the performance metric to receive the random reward. A user may change, for example, notification settings before using selection 765.

[0672] As a non-limiting example, a user may be awarded a random reward from among coupons and tangible items. Examples of coupons may include a coupon providing 5% off purchases of a product, $50 off purchases of $500 or more, 15% off purchases from a specific store and/or retailer, and/or the like. Examples of tangible items may include a makeup kit, a purse, nail polish remover, a ring and/or the like. Each item may be, for example, exclusively available to users of the payment method. Persons of ordinary skill in possession of example embodiments will appreciate the broad scope of different types of rewards that may be provided for use of a payment method and additional value that may be provided to a user upon using a payment method in a particular way (e.g., additional value when using the payment method to buy products sponsored by the application provider).

[0673] Tab 763 may be associated to notification settings. For example, tab 763 may be selected by a user to display entry fields 767 and 775, and selections 770 and 777. Entry fields 767 and 775 may be used by a user to enter information related to the type of notification (e.g., an email address and/or a text message number). Selections 770 and 777 may be used to submit the information entered into entry fields 767 and 775, respectively.

[0674] A user may be notified by the application provider when a reward is earned. The application provider may utilize user submitted notification settings to notify the user. For example, a user may submit an email address using entry field 767 and selection 770. As another example, a user may submit a number (e.g., a telephone number for text messaging) using entry fields 775 and selection 777. A notification email and/or text message may be sent to the email and/or number when a reward is earned. The email and/or text message may include a message indicating that a reward has been earned and that a redemption code usable to retrieve the reward is available. According to other example embodiments, the application provider may attach the redemption code and/or reward to the notification (e.g., embedded in the email). According to still other example embodiments, electronic rewards may be downloaded by clicking, for example, an information display associated with the earned reward (e.g., using an application manager).

[0675] Although example embodiments are described with respect to email and/or text messaging, persons of ordinary skill in possession of example embodiments will appreciate that many different notification methods may be used (e.g., telephonic, text messaging, telegram and/or the like). According to at least one example embodiment, no notification may be provided. According to other example embodiments, a user may provide a physical address at which to receive notifications and tangible rewards. According to yet other example embodiments, a user may submit multiple addresses (e.g., one or more email addresses, one or more telephone numbers, and/or one or more physical addresses) and select one of the addresses prior to redemption such that each reward redemption may result in a different notification or fulfillment (e.g., different rewards and/or notifications may be sent to different addresses at the whim of the user).

[0676] Although example embodiments described in relation to FIG. 7 may include performance metrics based on a monetary value, various other performance metrics are within the scope of example embodiments (e.g., number of transactions, type of transactions, a user acting as a merchant using a particular merchant service and/or the like).

[0677] FIG. 8 shows device 800 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 801. Device 800 may include a processor that may render GUI 802 onto display 801. GUI 802 may be an application interface usable to manage a user's experience with an application. For example, GUI 802 may be used to configure application settings, receive information from an application provider, communicate information to an application provider and/or the like. [0678] GUI 802 may include, for example, tab 805, application screen 807, information displays 810, 820, 830 and 840, and selection 850.

[0679] Tab 805 may be used to display application screen 807 and may include a descriptor associated with application screen 807 (e.g., "Scratch Off"). Upon selecting tab 805, application screen 807 may be displayed to a user. Application screen 807 may be an interactive selection screen for an application.

[0680] A feature provided by an application may provide a user an opportunity to select one reward from among multiple, hidden rewards. For example, a user may be presented with multiple representations of a logo (e.g., an application provider logo) in information displays 810-840. The user may be provided the opportunity to select one of information displays 810- 840 to unveil a reward. For example, a user may select information display 820 to reveal that the user has won a coupon (e.g., 15% off of a purchase).

[0681] According to example embodiments, a user may select two or more of information displays 810-840 and receive a reward associated with each selection. For example, multiple performance metrics may be available to the user. Depending on a value (e.g., cost to the user and/or value provided to the application provider) of the performance metric, a different number of selection may be made (e.g., one selection for $50 in spends, two selections for $100 in spends, etc.).

[0682] According to example embodiments, an application provider may receive a monetary value from, for example, an ecosystem provider, an issuer, a merchant and/or a payment network in exchange for providing a reward to a user. The monetary value may be, for example, a number of basis points (1/100 of a percentage point) related to a transaction. According to some example embodiments, an application provider may not receive a monetary value and/or may provide value. The application provider may receive value, for example, via customer acquisition, retention of customers, marketing (e.g., visibility within an ecosystem) and/or the like. According to some example embodiments, a value provided via a coupon may be greater than a monetary value provided to a coupon provider. A difference in value may be offset by other factors (e.g., high value coupons where 90% of the coupons are expected to expire prior to use).

[0683] A performance metric may be based on transactional processing. Transactional processing may include multiple stages. For example, a credit transaction may include authorization, batching, clearing and funding. An application and/or feature provider may provide a reward to a user at one of the various stages of transaction processing (e.g., authorization). In some cases, a transaction may be reversed (e.g., a void or credit) after a user receives a reward based on the transaction. For example, a user may purchase an item, receive an electronic reward and then return the purchased item. According to example embodiments, the application and/or feature provider may be notified by the application manager provider that a transaction has been reversed. A application and/or feature provider may take action based on the notification, for example, provider may reclaim a coupon, invalidate a coupon code, remove user authorization to use an application and/or feature, establish a debit pool that must be reduced by future uses of the payment method before additional rewards may be earned and/or the like. [0684] According to some example embodiments, a reward may be granted to a user at a stage of transaction processing (e.g., authorization) but may not be available for use by the user until a different stage of processing (e.g., settlement). If a transaction is reversed (e.g., via a return, a charge-off and/or a charge-back) after being made available to the user the application and/or feature provider may take steps to remove a value associated with the coupon. Accordingly, if a card is used fraudulently (e.g., a stolen card), rewards may be disassociated with a reward system when the purchases are charged-off as a result of the fraudulent spend.

[0685] FIG. 40 shows process flow chart 900. According to example embodiments, a rewards provider may utilize an application to configure rewards (e.g., for a rewards or loyalty program). For example, a computing device (e.g., a server) may display an interactive GUI that is usable to define a rewards program via selections and entries.

[0686] Referring to FIG. 9, reward description details may be defined (e.g., as in step 910). For example, a rewards provider may select a type of reward, enter a name for the reward, provide a brief description of the reward and upload an image to represent the reward.

[0687] The reward type may be, for example, a coupon, an item, a virtual item, cashback, points, miles, entry into a lottery, and/or any other type of reward. Once a reward type is selected, the GUI may display further options tailored to the type of reward.

[0688] A rewards provider may define reward execution details (e.g., as in step 920). For example, a coupon provider may determine the type of coupon that will be provided to users by selecting various options. The options may determine, for example, whether or not the coupon will be based on a purchase amount or a purchased product, and the type of discount or rebate to be applied. If the coupon will be based on a purchase amount, the type of discount or rebate may include, for example, a percentage or value based discount. If the coupon will be based on a purchased product, the type of discount or rebate may include, for example, a percentage discount, a value based discount or a replace value.

[0689] A rewards provider may set distribution limits for the rewards program (e.g., as in step 930). The distribution limits may define the financial liability that may be incurred by the rewards provider. For example, using an overall limit and/or a per customer limit, a coupon provider may limit the number of coupons that are distributed and/or the maximum value of the coupons (e.g., the value either individually or in aggregate). As one example, a rewards provider may set an overall distribution limit of 1000 coupons and a per customer distribution limit of 5 coupons.

[0690]A rewards provider may define reward execution requirements (e.g., as in step 940). Reward execution requirements may, for example, describe the circumstances under which a coupon is redeemable. For example, coupons redemption may be limited to online purchases or store purchases, or permitted for both store purchases and online purchases.

[0691] If in-store redemption is permitted, the redemption may be limited to a particular store, a set of particular stores, and/or one or more geographical areas (e.g., by zip code, province/state and/or country). Information that may be entered into a GUI by a rewards provider may include, for example, one or more store ID's, store names, zip codes, province/state information and/or country codes.

[0692] Where redemption is permitted online, or online and in-store, reward redemption may be limited to one or more retailers (e.g., Dynamo Sporting Goods), to one or more types of retailers (e.g., sporting goods), by maximum and/or minimum purchase thresholds (e.g., purchase amount thresholds), by duration (e.g., a range of dates), by date (e.g., specific days), by time (e.g., specific hours), and/or by product and/or product group (e.g., to one or more SKU groups).

[0693] Accordingly, coupon redemption may be circumscribed by, for example, location, commercial relationships, cooperative interests, and/or logistical considerations. For example, a retailer may increase traffic through stores at historically underperforming times, days or months, reduce percentage reduction liability that may occur for higher value purchases, and restrict coupons to particular products, manufacturers or types of manufacturers. A retailer with knowledge of customer loading patterns within its stores may limit coupon redemption to particular stores at particular times on particular dates to level workload, control local traffic, synergize with staffing levels and/or increase loading at underperforming stores or regions.

[0694] A rewards provider may define reward usability and compatibility (e.g., as in step 950). For example, a retailer may define how coupons are used together (coupon usability), define the types of payment methods that are usable during a qualifying purchase (purchase types), and/or define the transferability of the coupons (user restrictions). [0695] For example, defining coupon usability may include selecting whether coupons are usable with all other coupons, with specific coupons or only by themselves. Defining purchase types may include selecting payment methods with which a coupon may be used, for example, all payment methods, specific branded payment methods (e.g., store loyalty credit card), cash, prepaid cash, payment methods supported by specific payment networks (e.g., Visa, MasterCard, Discover and/or American Express) and/or the like. Defining user restrictions may include restricting redemption to a designated user or designated users (e.g., the user to whom the coupon was sent) or permitting redemption by any user (e.g., a transferable coupon).

[0696] Although process flow chart 900 includes arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow chart 900 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0697] FIG. 41 shows process flow chart 1000. According to example embodiments, a rewards provider may utilize an application to configure a loyalty program. For example, a computing device (e.g., a server) may display an interactive GUI that is usable to define a loyalty program via selections and entries.

[0698] Referring to FIG. 41, a reward provider may define a description of a loyalty program (e.g., as in step 1010). For example, a rewards provider may select a program type, enter a name for the loyalty program, provide a brief description of the loyalty program and identify one or more rewards provided by the loyalty program.

[0699] The program type may be, for example, a predefined type of loyalty program. Once a reward type is selected, the GUI may display further options tailored to the type of loyalty program.

[0700] A rewards provider may define one or more reward distribution criteria (e.g., as in step 1020). For example, a loyalty program may provide a reward based on a monetary value spent (e.g., number of dollars), a number of visits (in-store and/or online), a number of particular items purchased and/or a number of purchases. [0701] A selection to base a loyalty program on monetary value may include entering an amount of the monetary value at which a reward may be provided. A selection to base a loyalty program on a number of visits may include entering the number of visits before a reward may be provided, and may include entering a number of consecutive days on which the visits must occur (e.g., a date range or a number). A selection to base a loyalty program on a number of purchased items may include entering one or more item types, one or more stock keeping units (SKU), and/or entering a number representing the number of items to be purchased before a reward may be provided. A selection to base a loyalty program on a number of purchases may include entering a number representing the number of purchases before a reward may be provided, and may include entering a minimum spend amount per purchase.

[0702] A rewards provider may set a rewards distribution criteria period for the loyalty program (e.g., as in step 1030). The distribution criteria period may specify a time period in which the loyalty program is deemed to be active and rewards may be earned. For example, a rewards provider may select an option to provide rewards from program inception or enter a date range. According to some example embodiments, a rewards provider may apply a retroactive time period such that historical data may be used to determine whether a reward was earned (e.g., prior to inception of the program).

[0703] A rewards provider may set program earning time constraints with respect to the loyalty program (e.g., as in step 1040). For example, reward earning may be limited such to only specific days, and/or specific days and times. For example, a loyalty program may be implemented to provide loyalty rewards for customers shopping on Black Friday (e.g., November 28, 2014) during non-peak hours.

[0704] A rewards provider may define program run limits (e.g., as in step 1050). For example, a rewards provider may select one or more options that may include running a loyalty program until start and end dates have been met (e.g., a date range), a particular amount of rewards have been generated, a particular amount of rewards have been redeemed, a particular amount of value has been generated and/or a particular amount of value has been redeemed.

[0705] A rewards provider may define program distribution criteria (e.g., as in step 1060). For example, a rewards provider may elect to distribute rewards only to a particular segment of a customer or consumer base. Rewards may be distributed based on psychographics, for example, any personality trait, value, attitude, interest, and/or lifestyle choice (e.g., "gamers," "savers," "sportsters," and/or "child conscience parents"). Award distribution may be based on, for example, gender, age, income and/or products (e.g., one or more SKUs). For example, coupons for geriatric feminine products may be distributed to female consumers by selecting gender and age as a basis for distribution, and entering product SKUs corresponding to the geriatric feminine products.

[0706] Although process flow chart 1000 includes arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow chart 1000 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0707] FIG. 42 shows process flow charts 1100 and 1150. According to example embodiments, a rewards provider may utilize an application to test a loyalty and/or rewards program by providing rewards to all, or one or more segments of, identified consumers (e.g., customers) and monitoring the effect of the reward.

[0708] The effect of the reward may be determined via test result data in multiple ways and may depend on the reward. For example, if a coupon is offered as a reward, transaction data and/or coupon-use data may be monitored to determine if the coupon resulted in a change in consumer behavior. The data may be collected at one stage of transaction processing (e.g., authorization, settlement, and/or the like), each stage or any combination of stages.

[0709] According to some example embodiments, test result data may include segment data from one or more segments receiving a coupon, from one or more segments not receiving a coupon and/or from one or more segments receiving a different coupon (multi-segment testing). Test results may include data from a portion of a segment receiving a coupon and a portion of a segment not receiving a coupon (in-segment testing). Test result data may include data from an entire consumer base (global testing). According to some example embodiments, segment data (e.g., in-segment and/or multi- segment data) collected during the duration of the testing may be compared. According to some example embodiments, before-and-after data may be compared (in- segment, multi-segment and/or global) using collected and historical data.

[0710] Referring to process flow chart 1100, a computing device (e.g., a server) may display an interactive GUI that is usable to describe and/or define test and distribution criteria used in program testing (e.g., as in step 1110). For example, a rewards provider may select a loyalty or rewards program for testing, enter a name of the test, enter a brief description, enter a number of rewards to generate, and/or select a percentage or number of consumers (e.g., customers and/or non-customers) to receive the generated rewards. The selected percentage or number may be applied to an entire consumer base (e.g., 100% where no segments are defined), to segments of a consumer base (e.g., x% where multiple segments are defined) and/or to a single segment of a consumer base (e.g., x% where a single segment is defined). Individual segments may be, for example, defined by distribution criteria.

[0711] A rewards provider may define one or more segments to be used in program testing be selecting or entering distribution criteria (e.g., as in step 1120). A segment may be based on, for example, psychographics. Psychographics may include any personality trait, value, attitude, interest, and/or lifestyle choice (e.g., "gamers," "savers," "sportsters," and/or "child conscience parents"). A segment may be based on characteristics or goods, for example, gender, age, income and/or products (e.g., one or more SKUs). Consumer psychographics and characteristics may be entered by a user and/or determined from transactional data.

[0712] Once all desired parameters for a test are configured, the test may be initiated (e.g., as in step 1130). The coupons may be distributed and data collection begun (e.g., via routing of transaction messages to a remote facility or other entity). At the completion of the test, for example at an expiration date of test coupons, data may be analyzed and results may be provided. Graphs may be displayed to summarize the test results. [0713] According to at least one example embodiment, a test may be repeated one or more times and graphical data may be continuously updated. Repetition may provide temporal or event based effect information (e.g., seasonal habits or the effects of weather). According to at least one example embodiment, tests may be triggered based on events to determine their impact on consumer habits (e.g., geographic testing triggered by a catastrophe).

[0714] Referring to process flow chart 1150, a computing device (e.g., a server) may display an interactive GUI that is usable to simulate a loyalty program or rewards program. For example, a rewards program may be built and simulated to ensure that the rewards program functions according to the reward provider's intended design.

[0715] A rewards provider may select a loyalty or rewards program (e.g., as in step 1160). For example, the reward program may be selected using the reward description (e.g., "incentive coupon"). The program may be, for example, selected from a list of programs. If the coupon includes a barcode, the type of barcode may be selected. A coupon simulation type may be selected. A coupon simulation type may be, for example, a valid coupon or a test coupon. An address (e.g., email address) of a user and a mail server identification may be entered. [0716] The program may be simulated (e.g., as in step 1170) by, for example, selecting to send one or more test emails (e.g., in a case where coupons are distributed by email), or by entering condition settings and selecting to simulate the program based on the condition settings. A condition may include, for example, maximum liability. The simulation may determine, based on the rewards program, the maximum liability where the maximum number of coupons are distributed and used. Alternatively, percentage of use assumptions and the like may be entered to determine a resulting liability based on the assumptions. In general, conditions may include any parameter used to determine the result of a defined rewards or loyalty program.

[0717] Although process flow charts 1100 and 1150 include arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow charts 1100 and 1150 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described process to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that whether a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file).

[0718] FIG. 12 shows process flow charts 1200 and 1250. Process flow chart 1200 may provide an example of the implementation of a rewards program and process flow chart 1250 may provide an example of the implementation of a loyalty program.

[0719] Referring to process flow chart 1200, a computing device (e.g., a server) may display an interactive GUI usable to define a rewards program (e.g., as in step 1205). A remote facility may receive rewards program configurations (e.g., as in step 1210) from, for example, a third party provider (e.g., a retailer). Based on the defined program, the remote facility may distribute rewards according to the program definition. For example, the remote facility may distribute coupons to all customers within a demographic (e.g., globally, by segment, by partial segment and/or the like).

[0720] The rewards may be distributed physically (e.g., by mail, courier, in-store and/or the like) and/or non-physically (e.g., via electronic mail, telephonically, SMS messaging, television, social networking and/or the like). For example, a server of a remote facility may receive or pull data from a server of a third party provider, and based on the data distribute coupons to consumers via electronic mail.

[0721] The remote facility may receive reward redemption information (e.g., as in step 1220). For example, the third party provider may communicate coupon redemption information to a remote facility (e.g., an ecosystem provider), and/or the remote facility may receive transactional data from one or more network entities in a transactional flow. The transactional data may include, as one example, an authorization message. [0722] The reward redemption information may include, for example, coupon identification information, user information, location information, product information, establishment information (e.g., store ID), purchase price information, and/or any other transactional data. The remote facility may determine if the coupon is valid based on the reward redemption information and a rewards program. The remote facility may, for example, determine if the coupon is recognized as active for a rewards program, and if the coupon redemption meets the requirements of a rewards program. [0723] For example, a rewards program may provide a discount that is only valid at a particular store, on a particular date and for a particular user. The remote facility may receive an authorization message that includes identification of a coupon and determine if the coupon is active for any rewards program. If the coupon is active, the remote facility may compare received transactional information against the requirements for the rewards program.

[0724] Based on the validity determination, the remote facility may provide validation information (e.g., as in step 1225) to a third party provider, a merchant terminal, an issuer, and/or other entity. For example, if the coupon is active and the transaction complies with the requirements of a rewards program, the remote facility may communicate information indicating that the discount or rebate may be applied to the transaction. If the coupon does not meet one or more criteria for redemption, the remote facility may indicate that the discount or rebate should not be applied to the transaction. Although example embodiments are described with respect to real-time processing, validation may occur after a purchase, for example, based on settlement. [0725] Referring to process flow chart 1250, a computing device (e.g., a server) may display an interactive GUI usable to define a loyalty program (e.g., as in step 1255). A remote facility may receive loyalty program configurations (e.g., as in step 1260) from, for example, a third party provider (e.g., a coupon provider).

[0726] The remote facility may receive transaction data. Based on the transaction data, historical data and a loyalty program definition, the remote facility may determine loyalty program applicability and performance metric status (e.g., as in step 1265).

[0727] For example, a server of a remote facility may receive or pull data from a server of a third party provider, or receive transactional messages from an entity within a purchase flow (e.g., as described with respect to FIG. 3). The transactional data may evaluated to determine if a loyalty program applies. For example, a loyalty program may award a coupon to users of a particular loyalty credit card that fall within a particular demographic. The remote facility may evaluate the transactional data to determine if a performance metric has been met. For example, the performance metric may include completing 10 purchases of a particular product using the loyalty credit card. The historical data may indicate that the user has previously purchased the particular product 9 times and the current purchase completes the performance metric.

[0728] A reward may be distributed as defined in the loyalty program (e.g., as in step 1270). If the performance metric has been met, a discount may be automatically applied to the transaction by communicating a message (e.g., to a point-of-sale device) and/or a coupon may be communicated to the user.

[0729] Where a coupon is communicated to a user, the remote facility may receive reward redemption information (e.g., as in step 1275) upon use of the coupon. For example, the third party provider may communicate coupon redemption information to the remote facility, and/or the remote facility may receive transactional data including reward redemption information from one or more network entities in a transactional flow. The transactional data may include, as one example, an authorization message. [0730] The reward redemption information may include, for example, coupon identification information, user information, location information, product information, establishment information (e.g., store ID), purchase price information, and/or any other transactional data. The remote facility may determine if the coupon is valid based on the reward redemption information and the loyalty program definition. The remote facility may, for example, determine if the coupon is recognized as active for a loyalty program, and if the coupon redemption meets the requirements of the loyalty program.

[0731] For example, the loyalty program may provide a discount or rebate that is only valid when used during specific hours in a particular country. The remote facility may receive a message (e.g., a settlement message) that includes identification of a coupon and determine if the coupon is active for any loyalty program. The remote facility may compare the received transactional information against the requirements for the rewards program. For example, the remote facility may determine if the coupon is being used during the specific hours and in the particular country, as required by the loyalty program. If the coupon is active and the requirements of the loyalty program are met, the coupon may be determined valid. Otherwise, the coupon may be determined invalid.

[0732] Based on the validity determination, the remote facility may provide validation information (e.g., as in step 1280) to a third party provider, a merchant terminal, an issuer, and/or other entity. For example, if the coupon is valid, the remote facility may communicate information indicating that the discount or rebate may be applied to the transaction. If the coupon is not valid, the remote facility may indicate that the discount or rebate should not be applied to the transaction. Although example embodiments are described with respect to settlement processing, validation may occur, for example, at authorization (or any other stage of processing).

[0733] Although process flow charts 1200 and 1250 include arrows, the arrows are not limitations of order. Persons of ordinary skill in the art will appreciate that some or all of the described activities may be completed sequentially, in a different order or simultaneously. Although process flow charts 1200 and 1250 may be described above with respect to coupons, persons of ordinary skill in possession of example embodiments will understand the described processes to be broadly applicable to various types of rewards. Persons of ordinary skill will understand that if a process is described with respect to selection or entry, a selection may be implemented with an entry, an entry with a selection, and other possibilities exist (e.g., pulling SKUs from a database or other file). According to example embodiments, cards, ecosystems, third party applications, testing, simulation and transaction flows may be included in the implementation of a reward or loyalty program.

[0734] Example embodiments described with respect to process flow charts 1200 and 1250 are not limiting of example embodiments, but serve as examples. Various transactional flows and systems may be implemented in various ways (e.g., as described with respect to FIG. 3). Although specific entities may be used to describe example embodiments in relation to FIG. 12, various entities may perform one or more functions of other entities, and the particular entities used to describe

FIG. 12 are not limiting.

[0735] A value document (tangible or intangible) may be used to generate demographic information to understand consumer behavior by providing, for example, incentives to purchase, reductions in the price of particular items, free samples, and/or the like. For example, a value document may provide free shipping, buy-one get-one, trade-in for redemption, a coupon for a first-time customer, free trial offer, launch offer, special event offer and/or free giveaway. A value document may be, for example, a coupon providing $5.00 off a $10.00 purchase, and the coupon may be represented by a two or three dimensional barcode. A price conscious consumer may, for example, present a coupon to check out at a merchant, and the merchant may retain the coupon and offer the consumer a loyalty card during the check-out process. Consumer acceptance of the loyalty card may be low.

[0736] According to some example embodiments, a value system may issue an value identifier to influence consumer behavior for loyalty or advanced coupon features. For example, a value system may provide a multistage value account identifier which is individualized based on use of the multistage value account identifier. The multistage value account identifier may be, for example, a single code (e.g., represented by a barcode). The multistage value identifier may be associated to a multistage value account. According to example embodiments, the multistage value account may or may not be associated with a particular user.

[0737] A multistage value account may be associated with a defined or undefined set of stages. A stage may require, for example, a particular action (e.g., a purchase or a game move). For example, at a first visit to a retailer, a user may present a multistage value account identifier to receive $5.00 off a $10.00 purchase, and at a second visit receive $10.00 off a $20.00 purchase, and at a third visit receive $15.00 off a $20.00 purchase and at a fourth visit receive a free sandwich along with a message announcing that the user of the multistage value account identifier has achieved status and will be provided a card (e.g., gold status card) upon providing user information (e.g., a telephone number, email address, physical address and/or other information associated with the consumer). The card may, for example, represent a conventional loyalty program, specific privileges and/or expand the benefits provided by the multistage value system (e.g., with increasingly individualized customization based on information obtained from redemption associated with the stages of the multistage value account and/or based on user information).

[0738] User information may be requested via, for example, a retailer POS system, a method specified by the POS system, a receipt and/or an online purchase confirmation. According to some example embodiments, a user may receive an advertisement including a multistage value account identifier or method of obtaining a multistage account identifier, along with information indicating that upon achieving a particular stage the user is eligible for a status card upon submitting user information (e.g., to a website URL). According to at least one example embodiment, use of a multistage value account identifier may be conditioned on consent by the user for access to user information, for example, user information stored by a merchant, acquirer, issuer, processor, payment network, third party service provider, remote facility, device provider, mobile service provider and/or any other entity.

[0739] A multistage value system may be an implementation of an abbreviated (mini) loyalty program or an introductory loyalty program and a user may be seamlessly converted from the multistage value account to a value program. For example, a user may be converted to a loyalty card representing an extension of the multistage value system, or a different and/or traditional loyalty program. Consumer acceptance of the loyalty card may be increased and/or high as compared to conventional program offerings at checkout.

[0740] According to some example embodiments, one or more stages of a multistage value account may expire. According to other example embodiments, no stage of a multistage value account expires. According to still other example embodiments, one or more stages of a multistage value account may include a change date after which a different value is offered to the consumer.

[0741] According to some example embodiments, a consumer may be offered a choice of value from a pool at a first stage. According to other example embodiments, a choice may be presented to a user at one or more stages or every stage of a multistage account. According to still other example embodiments, no choice is offered to the user.

[0742] Machine learning may be applied to determine the value or pool of values offered at one or more stages of a multistage value account based on, for example, previous value selections by a user, use of the multistage value account identifier (e.g., redemption data), information submitted by a user, demographic data and/or any other information relevant to individualizing value to a user of a multistage value account.

[0743] Artificial intelligence may, for example, provide a multistage value system subscriber segmentation including groupings or patterns within a customer base of the subscriber. According to some example embodiments, the multistage value system subscriber may be offered choices of values to be offered to a user at one or more stages based on segmentation. A multistage value system subscriber may be, for example, a game company, issuer, processor, acquirer, payment network, merchant, property owner (e.g., mall owner or strip mall owner) and/or an affiliate of a collection of merchant brands subscribing to, or operating, a multistage value system. A multistage value system may according to at least some example embodiments be provided by a third party from a remote server.

[0744] A value offered to a user during one or more stages of a multistage value account may be the result of, for example, an online game or games (e.g., game scores). A value offered during one or more stages may be random, for example, the result of a virtual scrath- off.

[0745] The system may be a merchant, cross-merchant, product and/or issuer centric system. For example, a merchant multistage value system may offer a user a value at each of multiple stages, the value usable or in exchange for, among other things, making purchases from the merchant, making purchases from different stores of the merchant and/or purchasing different preferred products from the merchant. [0746] As another example, a cross-merchant multistage value system, which may be provided by, for example, an issuer, and may offer a user a sequence of values corresponding to a sequence of purchases from different merchants. For example, a user may be provided values usable or in exchange for making a purchase at a first merchant at a first stage, at a second merchant at a second stage, a third merchant at a third stage or any combinations of merchants with or without repeats. Stages may be related to, for example, non-competitive merchants, merchants familiar to one another, merchants selected according to machine learning and/or combinations thereof. According to at least one example embodiment, a multistage value account may include stages related to companies adverse to each other with the stage placement based on preferences of a multistage value system subscriber.

[0747] A user may be offered value for making a sequence of purchases of a particular product or a product from a family of products (e.g., for purchases of different flavors of a particular brand of ice cream). A user may be offered a single value for making a purchase at a sequence of vendors, either additional to values provided at one or more individual stages of the sequence or otherwise.

[0748] According to at least one example embodiment, a multistage value system may be used to induce user behavior. For example, a user may be offered value for travelling to specific geographic areas (e.g., malls, shopping districts, community revitalization projects) or different geographic locations (e.g., game vendor, amusement park locations, recreational facilities). [0749] The multistage value system may be, for example, provided via a server of a merchant, acquirer, issuer, processor, payment network, third party service provider, remote facility, device provider, and/or any other entity. A multistage value account identifier may be obtained in any manner value offers may be made. For example, a multistage value account identifier may be printed as a barcode on a receipt. Alternatively, for example, a user may obtain a generic identifier, submit the generic identifier and receive a multistage value account identifier. For example, a user may take a picture of a generic identifier in a newspaper or a screenshot of a web based advertisement, text or email the picture to a number provided in the newspaper or advertisement and receive a multistage account identifier in return from that number. Persons having ordinary skill in the art in possession of this specification will understand that many different ways of providing an identifier are achievable and contemplated

[0750] According to some example embodiments, a multistage value account may offer value based on a number of stages completed within a period of time (e.g., one month) and/or may change value based on the length of time between stage completion and/or may change the value based on the average length of time between completion of multiple stages and/or provide value based on a period of time in which all stages are completed. [0751] According to example embodiments, a multistage value account identifier may be the same for all stages, different for groupings of stages or different for each stage.

[0752] Figure 13 is an illustration of a process flow chart constructed in accordance with the principles of the present invention. Referring to FIG. 43, a server may receive a multistage value account identifier (e.g., a coupon identifier of a multistage coupon) and at least a portion of purchase transaction information (Step 1305). The server may use the multistage value account identifier to access multistage account data associated with the identifier, obtain a current stage associated with the multistage value account and a stage threshold, and determine that the current stage is equal to or greater than the stage threshold (Step 1310). The server may verify that the purchase qualifies a user of the multistage value account identifier to receive a value associated with the current stage based on the purchase transaction information (Step 1315). The server may communicate a message indicating the earned value and eligibility for a loyalty card associated with the multistage value account based on the threshold (Step 1320). User information may be received by the server in response to the message (Step 1325).

[0753] According to example embodiments, a multi- stage account may be associated a number of stages that may be completed in any order. For example, one stage may provide a free coffee upon purchasing a dinner from Dew-Rain-Dew Restaurant, or in real-time, for example, upon ordering, such that the coffee is enjoyed as part of the experience. A second stage of the multistage value may provide, for example, a free biscuit with breakfast, and a third stage may provide, for example, a free side with an entree at lunch. Upon completing all three stages, the user may receive an all-stage completion reward, for example, a $10 gift card.

[0754] According to some example embodiments, an employee of Dew-Rain-Dew Restaurant (e.g., a waitperson) may accept a multistage value account identifier at any portion of the dinner meal. For example, the employee may scan a QR Code displayed on a phone of the customer. The QR code may include the multistage value account identifier and may be uploaded to a remote server along with a merchant code indicating a purchase of a qualifying dinner. As another example, the customer may be provided with an SMS number (e.g., a dynamic number that changes based on time) linked to such a remote server and associated with Dew-Rain-Dew restaurant, such that the multistage value account identifier may be texted to the remote server and the purchase of the dinner confirmed simultaneously. As yet another example, the customer may not possess, and may be provided with, a multistage value account identifier for a new, unused account, for immediate or future use. According to at least one example embodiment, a merchant may permit back credit for previously purchased products (e.g., previous meals purchased from Dew-Rain-Dew Restaurant) and may provide a URL linked to a web GUI for managing a multistage value account.

[0755] The remote server may keep track of the stages and their completion regardless of the temporal order of completion. For example, the remote server may receive the multistage value account identifier and a merchant flag indicative of a stage, and update the multistage value account to reflect stage completion. The remote server may communicate with merchant systems to affect application of the value, and if all-stage completion is achieved, provide value and/or notice to the multistage value account user. For example, the remote server may communicate with Dew-Rain-Dew Restaurant's register or billing server such that the free coffee is properly accounted for in the bill and if all-stage completion is achieved, provide notice to the multistage value account user (directly or through Dew-rain-Dew's employee).

[0756] Figure 14 is an illustration of a process flow chart constructed in accordance with the principles of the present invention. Referring to FIG. 44, a user may scan a QR Code using a phone application (Step 1405). A server may receive a multistage value account identifier from the phone application and access the multistage account data associated with the identifier (Step 1410). The server may determine that the account is flagged for stage completion in any order and obtain stage completion data associated with the multistage value account (Step 1415). The server may communicate the flag and data to the phone application (1420). The phone application may display a list of stages showing which stages are complete, which stages are yet to be completed or a combination thereof, and may display stage requirements and values for uncompleted stages, and display a value associated with completion of all stages (1425). Accordingly, the user of the multistage value account may at any time check which stages are yet to be completed and verify the all stage completion reward, adding to the festive nature of the multistage value account.

[0757] According to at least some example embodiments, software and/or hardware may be included in, for example, a point-of-sale (POS) terminal that identifies a barcode. For example, a POS terminal may identify a QR code as being a QR code for a specific action, such as to authorize payment for a transaction.

[0758] The barcode, such as a QR code, may identify routing information for that barcode. The barcode as well as additional data, such as basket level purchase data and other data associated with a transaction (e.g., tax amount) may be communicated to the routing identity in the barcode. According to at least one example embodiment, the barcode may identify routing information and include the additional data.

[0759] The barcode and/or associated data may be routed to the routing identity for further processing. Persons skilled in the art will appreciate that multiple barcodes may have been utilized with a purchase. For example, one or more coupon barcodes may have been used for discounts, a loyalty barcode may have been utilized for loyalty account identification, an installment barcode may identify a user's desire to pay for a purchase in installments, a points barcode may indicate that a purchase is to be paid with points (e.g., loyalty points) and a payment barcode may have been provided to complete payment for the transaction.

[0760] According to at least one example embodiment, a barcode, such as a QR code, may be encoded in a manner to convey a greater amount of data than a conventional QR code, using for example a high capacity QR format (e.g., 177 x 177), multi-level data, data compression, or defined combination function flags. Mmultiple QR codes may be condensed into a single QR code. For example, a user may provide a POS terminal with a QR code that includes payment routing, loyalty, discount, installment, and/or points information, and/or other information. A QR code may, for example, indicate combinations of QR codes to be communicated to a routing identity (e.g., a payment QR code with an installment QR code for a third party installment plan provider to define an installment plan). [0761] According to some example embodiments, each barcode may initiate a different process and information may be routed to those different processes (either in parallel or in serial). The identification of the type of process (e.g., coupon, loyalty, payment, installment, points) may be determined at the point-of-sale terminal or at a routing identity. All such barcodes may have the same routing identity or a different routing identity. [0762] The system at the routing identity may receive, for example, all information, including all barcodes, and may determine the type of each barcode and initiate processes based off that determination.

[0763] For Payment, the type of the barcode may be identified as a payment type. The barcode may then include additional identifying information, such as the payment network for the payment account, the bank for the payment account, the user's account from that bank account, and additional discretionary data. In that discretionary data may be a dynamic security code that changes with every use. Accordingly, different barcodes may be provided by a device (e.g., a phone, watch, or battery powered card with a display) to make a payment at a store (e.g., via a point-of-sale system) and each of those barcodes may be associated to the same payment account from the same payment network and issuing bank with the difference being, at least in part, dynamic security data. For discount ... For loyalty ...

[0764] Persons skilled in the art will appreciate that magnetic stripe information could be, for example, represented as a barcode. A dynamic magnetic stripe security code, may be provided as part of the dynamic magnetic stripe data. Such data may be communicated to a point-of-sale terminal, identified and routed to that identified process, and the identified process may replace the barcode with magnetic stripe data, or generate magnetic stripe data, and may communicate this information to a payment network and perform an authorization process for that magnetic stripe data with a payment network. Persons skilled in the art will appreciate that a token may be utilized, such as a token issued by a token issuing entity, as the data for payment authorization.

[0765] Upon approval of the payment data, a message may be sent back to the point-of-sale terminal that causes the transaction to be completed. This can be done in many ways. For example, an amount of value may be stored in escrow and the point-of-sale terminal may be provided with indication that stored value is being utilized for the purchase amount and, after the transaction completes, the merchant's account may be deposited with the amount of the purchase. As such, the merchant may get access to funds quickly after a purchase transaction occurs.

[0766] As per another example, merchants may enter into contracts to accept the payment network's issuers barcodes for various types of payment (e.g., debit, credit, pre-paid) and transactions may be authorized and merchants paid within these terms.

[0767] Bank issuers may include their own wallets that run their own cards as dynamic barcodes, such as dynamic QR codes. Phone manufactures may find such features difficult to block as such features do not include the use of secure hardware on the devices.

[0768] The barcodes may be generated locally using local algorithms (e.g., stored in white box crypto approaches on the phone applications) or may be retried from a third party (e.g., retrieved and stored from a secure cloud). Such barcodes may be retrieved in batches (e.g., of 5 or more, 10 or more, 100 or more, etc). Such barcodes may be deleted after use so that the information is not retained on the device in any form.

[0769] A multi-issuer and multi-network wallet may be provided that permits a consumer to load in dynamic barcodes from various issuers. A user may be able to enter in his/her payment information either manually or via a phone (with an OCR component of an application reading information from the picture of the card). A token service may then be called to obtain an eligible payment token for the card. This token may be converted into a static or dynamic QR code.

[0770] Persons skilled in the art will appreciate that software may be included in point-of-sale terminals to recognize the barcode (e.g., as a Dynamic Payment Barcode) and the information to complete a transaction (e.g., payment total, basket level data of items purchased, tax information, etc) may be communicated to a dynamic payment process. The dynamic payment process may check to determine if other barcodes are utilized (e.g., a coupon barcode, loyalty barcode, etc.) and all barcode may be processed in order to properly complete a transaction. The barcode may identify the network and the appropriate information for that network may be communicated to obtain authorization of the payment information.

[0771] A decline may be received from the network and cause a decline communication to be sent to the point-of sale. [0772] An approval may be received from the network and cause an approval communication to be sent to the point of sale.

[0773] Additional information may be sent to the network, such as additional information to assist with other processes such as fraud detection and marketing insight evaluation.

[0774] Persons skilled in the art may appreciate that the identification steps may be included in the point- of-sale. Persons skilled in the art will appreciate that a point-of-sale may simply be the phone itself. A consumer may send a barcode from his/her phone to another phone and that phone itself may authorize the barcode and act as a barcode point-of-sale and/or identification and payment authorization process.

[0775] Super Smart Secure Payment Applets With Pre- Stored Messages and Logic and Ability To Change Subsequent Function Thereon

[0776] A payment card or other device such as a payment phone or watch, can interact with a point-of-sale terminal to complete a transaction. Multiple stages of communications from the payment device to the payment terminal and from the payment terminal to the payment device can be provided so that each device or process can identify itself to each other, securely confirm the other identity is authorized to conduct a transaction, and provided information for the authorization of a payment transaction. The point-of-sale terminal may route such communications to/from a merchant processor which may route parts of the communication to/from a payment network process, which may route part of the communications to/from an issuing processor that issued the payment device to the end consumer. [0777] The transaction may be communication between the payment device and point-of-sale terminal, for example, a contact chip connection, a contact or wireless magnetic stripe connection, a contactless connection, or through a visible connection such as a single-stage or multipl-stage barcode or QR code. A multiple-stage barcode may be a barcode that changes the information displayed throughout a payment transaction process so that multiple different types of information are displayed at different times over the same display area. [0778] During a transaction, a payment device may request information. This information may include, the amount authorized, additional monetary amounts, the country code of the terminal, the terminal verification results, the transaction currency code, the transaction data, the transaction type, the data authentication code, the iCC dynamic number, the CVM results, the transaction time, merchant custom data, transaction date, tvr, unpredictable number, whether the transaction was authorized or declined, or any type of data retrievable by the payment card.

[0779] A payment card may be battery-powered or non- battery powered and may include buttons to permit a consumer to select different payment accounts (e.g., debit, credit, pre-paid), payment options (e.g., pay with points, pay with equal monthly payments such as 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 36, 39, 42, 45, or 48 monthly payments, or other payment features (e.g., a password- entry system where a correct password is needed to use the card to complete a purchase).

[0780] The payment devices may include multiple processors - such as a general processor for managing the general operation of the device and a payments processor or secure memory element for managing all or part of the payment data and payment process of the device.

[0781] Data not associated with the direct authorization of a payment may be copied from information requested from the payment device and stored and utilized for non-payment or payment features.

[0782] For example, a card may have a display such as a pixelated display operable of displaying a cardholders payment network logo, cardholder name, payment account number, payment expiration date, payment security code for online transactions (e.g., CVV2, CVC2), card name, and other pieces of information.

[0783] Messages associated with a particular time and/or date may be pre-stored. For example, messages associated with an anniversary date of the issuance of the card, consumer birthday information, country holidays, religious events, or any notification or message associated with a particular time or date. For example, a message wishing the consumer a happy birthday and providing the consumer with a QR code coupon for a certain amount in value may be displayed based on a date received during a payment transaction (and, for example, a clock in the payment device that updates the stored date as time passes). Persons skilled in the art will appreciate that a birthday event may trigger a feature such as a game feature where a consumer gets to pick a gift box from a number of gift boxes where each or one ore of the gift boxes has a different amount or type of value stored in it. Accordingly, a marketing campaign may be provided where on your birthday you have the chance to win a statement credit for your payment card bill in different amounts based on, for example, an instant no- purchase necessary sweepstakes where on the cardholders birthday the cardholder is provided instant statement credit value based on different odds of receiving different amounts of value. Pre-stored messages based on time could be provided so that a different message is released at a particular time (e.g., 9am EST) every day. Date-based messages could include for example, new years, Christmas, Ramadan, each day of hannakah, memorial day, independence day, election day, etc.

[0784] Messages may be displayed on the payment device for example based on the first authorized transaction after a certain date/time. For example, a message may be pre-stored and displayed on the first authorized transaction after the first year of being issued the payment device or payment account on the payment device. [0785] Payment devices, such as payment cards, may include, for example, one or more displays, light emitting diodes, programmable magnetic stripes that can change the magnetic stripe data on the magnetic stripe, programmable EMV chips, programamble contactless chips, cellular chips and antennas for downloading data from a remote source, manual interfaces, sound interfaces, etc

[0786] Security features may be provided based on the received data. For example, a dynamic security code may be changed based on time and/or date information received from the payment device during an authorization transaction on a two-way authorization process (e.g., via an EMV or contactless transaction). The dynamic security code may provide a dynamic in-stripe security code (e.g., CVC1/CV1) and on-line security code (e.g., CVC2/CVV2). They may be the same or different security codes based on time and/or date or other information received and multiple types of information received (e.g., a different code may be provided based on time and country information received during a payment transaction).

[0787] Pre-stored messages may be provided based on any information received such as, for example, country code. A welcome message may be provided after a consumer makes a payment transaction in a new country that welcomes the user to the country and provides the consumer with payment information (e.g., exchange rates) based on that country. After each authorized transaction, for example, a card may display information on the transaction (e.g., amount of the transaction) in both the local and foreign currency by using information received and/or logic on the card.

[0788] Transaction applets may be provided that changes the account or payment option information based on what was received during the transaction. For example, if a US card account is utilized in Spain then the card may change the account to a Spanish account for future transactions (unless otherwise directed by the cardholder). In doing so, the payment device can receive information and change the way the payment devices operated based on the received information.

[0789] Any information could enable a new account (e.g., debit credit) or payment option (e.g., EMI, pay with points) for the current or a future transaction. A card can terminate a transaction based on information received and start a subsequent transaction (e.g., by having the cardholder remove and replace the card in a chip contact reader or reinstitute a new contactless transaction, etc. Persons skilled in the art will appreciate that payment terminals can be constructed to reinstitute transactions automatically if a transaction fails. [0790] Example types of information receivable to cause modification of an applet, or by an applet, may include, for example:

Amount, Authorized (Numeric)

[0791] According to example embodiments, methods of personalization and personalization updates to credit cards in the field are disclosed.

[0792] Perso Data Encryption. According to some example embodiments, encrypted personalization data may be sent over a transmission link (e.g., cell network, Bluetooth, NFC, etc.). A perso data block may have a unique session identifier preprogrammed into a secure element (SE) which may be used as part of an decryption process.

[0793] Data may be encrypted at multiple levels. For example, a two level embodiment may include transmission link encryption. An entire block of perso data may be encrypted (e.g., 3DES, AES, etc.) during transmission. This block may be decrypted by, for example, a general purpose processor (GP). The GP may use a unique Session Identifier to request the transmission decryption key from the Secure Element.

[0794] Such a two level embodiment may further include encryption of sensitive perso data (personal data of a cardholder) - sensitive perso data such as UDKs may be encrypted such that they will never be in the clear. This information may be sent encrypted to the SE (such as a secure element chip) and may be decrypted inside the Secure Element. This decryption process may be performed by an applet installed on the SE.

[0795] Cards may be preloaded with sets of keys in the SE that are associated with: Transmission Link Key - This key may be utilized by the GP to decrypt the entire perso data block that was received. The GP may provide the unique session identifier provided with the perso data Block to the SE such that the appropriate key can be provided. Multiple unique transmission keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades can be performed over the life of the card. This process may be protected from attacks by, for example, only allowing three attempts to request the transmission link key and if the proper unique session identifier is not provided within three attempts, the process may be blocked going forward. Sensitive Perso Data Key - This key may be utilized by the SE to decrypt sensitive perso data. The unique session identifier may be provided to the SE to be able identify the proper preloaded keys to decrypt the sensitive perso data. Multiple unique sensitive perso data keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades may be performed over the life of a card. This process may be protected from attacks by only allowing three attempts to provide a unique session identifier and if the proper unique session identifier is not provided within three attempts, the process will be blocked going forward.

[0796] Preloaded Perso Data. Acording to some example embodiments, preloading either multiple entire sets of perso data or multiple partial sets of perso data (which may be unique to this card) which may be triggered to be used by sending a signal to the card over a transmission link (e.g., cell network, Bluetooth, NFC, etc.) to change account information.

[0797] Complete sets of Perso Data - Multiple sets of Perso Data which may include changes based on an update to PAN sequence number only or entirely different PANs can be preloaded on the SE. Each of the accounts may be associated with a Unique Account Identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the Unique Account Identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[0798] Partial Sets of Perso Data - In order to minimize the amount of data preloaded, only the unique data associated with an account upgrade (PAN, UDKs, certificates, etc.) may be preloaded. Multiple partial sets of Perso Data which may, for example, include changes based on an update to PAN sequence number only or entirely different PANs may be preloaded on the SE. Each of the Partial Sets of Perso Data may be associated with a unique account identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the unique account identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that Account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[0799] Referring to FIG. 45, a slider may be used to select different features instead of, for example, a button.

[0800] FIG. 46 is a diagram illustrating example loyalty processing hardware configurations according to some example embodiments. According to example embodiments, a region may be any geographical, commercial and/or political division, such as a country, state, province, territory, consumer market, and/or the like.

[0801] [ProcessingAPI] discloses a non-limiting example according to example embodiments of loyalty processing. The particular elements and combinations of elements of [ProcessingAPI] provide an example only and is not to be construed in a mandatory nature generally. For example, while terms of a mandatory nature appear, the mandatory nature applies to the specific example provided in accordance with some example embodiments and may be permissive according to other example embodiments. For example, although the example provided by [ProcessingAPI] is shown with respect to one or more languages (e.g., XML), the disclosure is not limited to such language or languages. Persons of ordinary skill, once having read [ProcessingAPI], will at once envisage the multitude of different implementations of loyalty processing according to example embodiments.

[0802] [StackedOfferAPI] discloses a non-limiting example according to example embodiments of stacked offers processing. The particular elements and combinations of elements of [StackedOfferAPI] provide an example only and is not to be construed in a mandatory nature generally. For example, while terms of a mandatory nature appear, the mandatory nature applies to the specific example provided and is in accordance with some example embodiments and may be permissive according to other example embodiments. For example, although the example provided by [StackedOfferAPI] is shown with respect to data transmission of objects using a particular file format (e.g., JSON), the disclosure is not limited to such format. Persons of ordinary skill, once having read [StackedOfferAPI], will at once envisage the multitude of different ways that stacked offers may be processed (e.g., stacked offer issuance).

[0803] [DynamicsLoyaltyComponents] discloses a non- limiting example according to example embodiments of barcode formatting that may represent a variety of different types of offers in loyalty processing with backwards and forwards compatibility, providing at least the benefits of fast and direct access to offer details and payload validation before issued offer details are queried. The particular elements and combinations of elements of [DynamicsLoyaltyComponents] provide an example only and is not to be construed in a mandatory nature generally. For example, while terms of a mandatory nature appear, the mandatory nature applies to the specific example provided and is in accordance with some example embodiments and may be permissive according to other example embodiments. For example, although the example provided by [DynamicsLoyaltyComponents] is shown with respect to a particular type of validation (e.g., hash validation), the disclosure is not limited to such validation. Persons of ordinary skill, once having read [DynamicsLoyaltyComponents], will at once envisage the different ways that a barcode may, for example, be formatted to achieve the unexpected benefits disclosed therein.

[0804] [ComboLogic] discloses a non-limiting example according to example embodiments of loyalty processing combinational logic.

[0805] Referring to [uniqueness] and FIG. 46, elements usable alone or in combination with other elements according to example embodiments and/or conventional elements provide a robust, reliable, scalable loyalty processing apparatus/system/platform operable to process a high volume of transactions, for example ten thousand transactions per second and more than one billion transactions annually, with sub-second response time, and operable to process a range of offer types and data, and provide information and features. The use of the term user may represent a loyalty system provider customer (e.g., restaurant chain), a customer may be a user or consumer that is a current or potential customer.

[0806] QR Code Formatting: See

[DynamicsLoyaltyComponents]. [0807] PCS XML Formatting: See [ProcessingAPI].

[0808] Payload Hashing: See

[DynamicsLoyaltyComponents].

[0809] Barcode Parsing: See

[DynamicsLoyaltyComponents]. [0810] Issuance Data Logic: According to some example embodiments, upon parsing of a barcode, a loyalty processing apparatus/system/platform according to example embodiments may be operable to, using the individual components, verify that a coupon definition is valid (e.g., based on the coupons setup in the apparatus or system) and to ensure the individual coupon is still able to be utilized.

[0811] Offer Processing: see for example [StackedOfferAPI] .

[0812] Discount Processing: According to some example embodiments, after parsing a basket and reviewing the coupon definition, the apparatus or system may be operable to run discount processing rules triggered by conditions being met for a transaction. Offer attributes may be, for example, time based, location based, basket amount, SKU based and/or channel based.

[0813] Loyalty Tracking: According to some example embodiments, an apparatus/system/platform may track purchases made by unique card IDs/customers and award visits, points and/or special offers as customers reach their individual thresholds. The tracking may be performed by, for example, storing visit/points for individual QR Codes.

[0814] User Level Rewards: According to some example embodiments, all (or some) individual loyalty users may be tracked independently. Unique rewards may be awarded at the customer level such that a loyalty apparatus/system/platform is operable to provide individualized customer-specific offers and rewards to be configured.

[0815] Basket Verification Logic: According to some example embodiments, upon receipt of a POS XML including transaction basket SKUs, an apparatus/system/platform may compare the SKUs to rules to verify that that the transaction is a qualifying transaction.

[0200] Offer Stacking: See, for example, [StackedOffersAPI]. According to some example embodiments, an apparatus/system/platform may be operable to provide users the ability to stack multiple offers on a customer's account. The offer can be added in real time by calling the API and/or using a stacked offer upload feature in a dashboard. Product-specific discounts may be tiered on top of standard points/visit- based loyalty transactions.

[0816] Reward Gamification: According to some example embodiments, an apparatus/system/platform may provide functionality to rotate through predefined individual product rewards or to define odds to give unique discounts/offers based on either purchase history or customer profile.

[0817] Combo Logic: See [ComboLogic].

[0818] Balance Tracking: A suite of API endpoints may be provided to facilitate customer tracking of the customer's loyalty accounts. For example, one or more endpoints may provide customer loyalty account balance tracking.

[0819] User Registration: See, for example, API disclosure. A suite of API endpoints may be provided to facilitate customer tracking of the customer's loyalty accounts. For example, one or more endpoints may be provided to facilitate user registration of consumers (e.g., potential customers or customers) into a loyalty program.

[0820] Anonymous Loyalty: According to some example embodiments, an apparatus/system/platform may provide an option of customer registration to a barcode (QR code) or not. The apparatus/system/platform may track the loyalty visits/points/etc...by QR code (at the QR level) and users and/or customers may begin tracking loyalty before the customer is known.

[0821] Real-Time Issuance: See, for example, API disclosure. A suite of API endpoints may be provided to facilitate user or customer tracking of the customer's loyalty accounts. For example, one or more of these endpoints may be provided to facilitate issuance of consumer QR codes in real time.

[0822] Challenge Based Rewards: According to some example embodiments, an apparatus/system/platform may provide customer/consumer challenges that upon completion automatically rewards the customer/consumer with discounts and rewards based on the results.

[0823] Consumer Segmentation: According to some example embodiments, an apparatus/system/platform may provide users the ability to segment customers into individual consumer segments. Each segment may be associated to the award of a unique offer type (e.g., unique among segments). Users may move customers/consumers in and out of unique offers.

[0824] Coupons: According to some example embodiments, an apparatus/system/platform may determine any SKU to have any number of discounts applied. For example, Percentage Dollar Amount. [0825] Hosting Strategy: See, for example, FIG. 46. According to some example embodiments, an apparatus/system/platform may provide a cloud-based approach seggregating user traffic by region.

[0826] Auto-Scaling: According to some example embodiments, an apparatus/system/platform may provide container-based auto-scaling APIs with 0 transaction handling latency by providing demand based allocation (addition or removal) of, for example, hardware and virtual machines ("VMs") as required in real time. According to at least one example embodiments, for example, maximum and minimum thresholds on the number of concurrent transactions may be set by the user and/or provider to trigger demand based auto-scaling.

[0827] Currently, consumers carry multiple cards, for example, magnetic stripe cards, with them on a daily basis. It has gotten to the point that there is now a cottage industry dedicated to providing various carriers to hold these cards. To simplify consumer's lives and drive loyalty to a specific brand, what is needed is a single wallet card to replace one or more of these cards.

[0828] What is needed is a single wallet card or other device, provided by an issuer, which provides the functions of one or more cards. In an embodiment, the wallet cards may be preloaded with multiple cards, for example multiple issuer cards or multiple network cards. In an embodiment, the wallet card may be updated wirelessly to add, remove, or modify, cards that are stored on the wallet card.

[0829] FIG. 49 shows cards and architectures according to example embodiments. Referring to FIG. 1, card 100 may include, for example, dynamic magnetic stripe communications device 101, one or more displays (e.g., displays 112, 113 and 125), permanent information 120, one or more buttons (e.g., buttons 130-134 and 197-199) and/or dynamic number 114. Dynamic number 114 may include permanent portion 111. Permanent portion 111 may be, for example, printed, embossed and/or laser etched on card 100. Card 100 may conform to one or more ISO standards, for example ISO/IEC 7810 and ISO/IEC 7813. In some embodiments, the card may follow set physical dimension guidelines, for example the card may be 33 one thousands of an inch thick, plus or minus 2 one thousands of an inch.

[0830] Multiple displays may be provided on card 100 for various purposes. For example, display 112 may utilized to entirely, and/or partially, display a dynamic number. Display 113 may be utilized to display a dynamic code (e.g., a dynamic security code). Display 125 may display card information, logos, barcodes, holograms, and/or multiple lines of information. A display (e.g., at least one of displays 112, 113 and 125) may be a bi-stable display or non bi- stable display. A bi-stable display may be a display that maintains an image without power.

[0831] Permanent information 120 may include, for example, information specific to a user (e.g., a user's name and/or username) and/or information specific to a card (e.g., a card issue date and/or a card expiration date).

[0832] Buttons 131-134 and 197-199 may be mechanical buttons, capacitive buttons, or a combination of mechanical and capacitive buttons. Buttons 131-134 may be used, for example, to enter information (e.g., an access code) and/or to make a selection. For example, using buttons 131-134, a user may select options displayed on display 125 that instruct card 100 to communicate (e.g., via a dynamic magnetic stripe communications device, RFID and/or exposed IC chip) a user's instructions to use one of a debit account, a credit account, a pre-paid account, or a point account for a transaction (e.g., a payment transaction). According to at least one example embodiment, more than one account may be selected, for example, where a transaction may be divided between accounts. For example, card 100 may be utilized to indicate a user's desire to use a point account until the point account is exhausted and then a credit account.

[0833] Buttons 197 and 198 may be used, for example, to display a different card's information on more or more of the displays 112, 113, and 125. Persons skilled in the art will appreciate that pressing a button (e.g., button 199) may cause information to be communicated through device 101 when an associated read-head detector detects the presence of a read-head of a magnetic stripe reader. Button 199 may be utilized to communicate information indicative of a user selection.

[0834] A user may associate applications to buttons and/or features to applications, for example, on a graphical user interface (GUI). The graphical user interface may be, for example, an application manager provided by one or more entities. The associations may be changed, for example, at any time, periodically, and/or upon the occurrence of an event. According to some example embodiments, a user may associate applications to buttons and/or features to applications by telephone, by electronic mail and/or any other communication method.

[0835] Associations between buttons and service provider applications may be maintained by an ecosystem provider, for example, within an ecosystem of applications, transactional methods and types of transactions. When a transactional method (e.g., card 100) is used by a user, the ecosystem provider may receive transactional data and information indicative of a button selected by the user. The ecosystem provider may determine the identity of an application associated to the button, and may communicate some or all of the information and/or transactional data to the application and/or the service provider. The service provider and/or the application may provide a feature associated with the application based on the information and/or transactional data.

[0836] Architecture 150 may be utilized with any card (e.g., any card 100). Architecture 150 may include, for example, processor 120, display 140, driving circuitry 141, memory 142, battery 143, radio frequency identification (RFID) 151, integrated circuit (IC) chip 152, electromagnetic field generators 170, 180, and 185, and read-head detectors 171 and 172. [0837] Processor 120 may be any type of processing device, for example, a central processing unit (CPU) and/or a digital signal processor (DSP). Processor 120 may be, for example, an application specific integrated circuit (ASIC). Processor 120 may include on-board memory for storing information (e.g., drive code). Any number of components may communicate to processor 120 and/or receive communications from processor 120. For example, one or more displays (e.g., display 140) may be coupled to processor 120. Persons skilled in the art will appreciate that components may be placed between particular components and processor 120. For example, a display driver circuit may be coupled between display 140 and processor 120.

[0838] Memory 142 may be coupled to processor 120. Memory 142 may store data, for example, data that is unique to a particular card. Memory 142 may store any type of data. For example, memory 142 may store discretionary data codes associated with buttons of card 100. Discretionary data codes may be recognized by remote servers to effect particular actions. For example, a discretionary data code may be stored in memory 142 and may be used to cause a third party service feature to be performed by a remote server (e.g., a remote server coupled to a third party service such as an online voucher and/or coupon provider). [0839] Different third party features may be, for example, associated with different buttons and a particular feature may be selected by pressing an associated button. According to some example embodiments, a user may select a third party feature from a list displayed to the user. For example, the user may scroll through a list of features on a display (e.g., a display on the front of the card). A user may scroll through a list using buttons on card 100. The list of features may be displayed to the user individually (e.g., one or more buttons may be used to change which feature is displayed), in groups and/or all features may be simultaneously displayed.

[0840] According to at least one example embodiment, a user may select a type of payment on card 100 via manual input interfaces. The manual input interfaces may correspond to displayed options (e.g., displayed on display 125) and/or may be independent buttons. Selected information may be communicated to a magnetic stripe reader via a dynamic magnetic stripe communications device. Selected information may also be communicated to a device (e.g., a mobile telephonic device) including a capacitive sensor and/or other type of touch sensitive sensor.

[0841] Architecture 150 may include any number of reader communication devices. For example, architecture 150 may include at least one of IC chip 150, RFID 151 and a magnetic stripe communications device. IC chip 150 may be used to communicate information to an IC chip reader (not illustrated). IC chip 150 may be, for example, an EMV chip. RFID 150 may be used to communicate information to an RFID reader. RFID 150 may be, for example, a RFID tag. A magnetic stripe communications device may be included to communicate information to a magnetic stripe reader. For example, a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

[0842] Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, architecture 150 may include electromagnetic field generators 170, 180, and 185 to communicate separate tracks of information to a magnetic stripe reader. Electromagnetic field generators 170, 180, and 185 may include a coil (e.g., each may include a coil) wrapped around one or more materials (e.g., a soft-magnetic material and a non-magnetic material). Each electromagnetic field generator may communicate information, for example, serially and/or in parallel to a receiver of a magnetic stripe reader for particular magnetic stripe track.

[0843] Architecture 150 may include read head detectors 171 and 172. Read-head detectors 171 and 172 may be configured to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). Information sensed by the read-head detectors 171 and 172 may be communicated to processor 120 to cause processor 120 to communicate information serially from electromagnetic generators 170, 180, and 185 to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader.

[0844] According to at least one example embodiment, a magnetic stripe communications device may change the information communicated to a magnetic stripe reader at any time. Processor 120 may, for example, communicate user-specific and card-specific information through RFID 151, IC chip 150, and/or electromagnetic generators 170, 180, and 185 to card readers coupled to remote information processing servers (e.g., purchase authorization servers). Driving circuitry 141 may be utilized by processor 120, for example, to control electromagnetic generators 170, 180, and 185.

[0845] Architecture 150 may include, for example, a light sensor (not illustrated). Architecture 150 may receive information from a light sensor. Processor 120 may determine information received by a light sensor.

[0846] In an embodiment, a single wallet card operable to be loaded with information for one or more other cards, for example credit cards, debit cards, rewards cards, loyalty cards. An entity, for example an issuer, such as a bank, other financial institution, a network (like MasterCard® or Visa®), or a 3^rd party, would provide the wallet card. The wallet card can be provided with cards already loaded. In an embodiment, an EMV chip is provided on the card that is dynamic and can communicate information specific to a selected card.

[0847] In an embodiment, one or more of the displays, for example display 125 in Fig. 1, comprise e-paper. In an embodiment, displays comprising e-paper display information using a segmented display. In an embodiment, displays comprising e-paper display information using a pixilated display.

[0848] When active, the currently selected card information will be displayed, for example on display 125 of Fig. 1. The user may use buttons on the wallet card to cycle through stored cards. For example, there may be a single button that cycles sequentially through cards. In an embodiment, there may be two buttons that allow a user to cycle through cards in different orders, for example forward and backward though a sequence of cards. In other embodiments, there may be more than two buttons, for example a button for each card information stored on the wallet card. In an embodiment, logos associated with the financial institution or network associated with a specific account may also be displayed.

[0849] Once the user finds the information for the card they would like to use, he can use the wallet card as he would if he had that specific card. For example, the user may locate the information for an airline rewards credit card that he would like to use. Once that information is displayed, the user may swipe, tap, or otherwise conduct a payment transaction. [0850] A dynamic magnetic stripe communications device on the wallet card will transmit the information related to the selected stored card. This may be communicated via a magnetic stripe emulator, magnetic stripe encoder, or wirelessly. In an embodiment, the wallet card may communicate and receive information using Bluetooth. In an embodiment, the wallet card may communicate and receive information via RFID. In an embodiment, the wallet card may communicate and receive information via the EMV chip. In an embodiment, the wallet card may communicate and receive information via LEDs and light sensors.

[0851] In an embodiment, the wallet card is updated by the party that issued the wallet card, not by the user. For example, the wallet card may be issued by a banking institution, a credit institution, or any other 3^rd party. The issuing party may preload one or more specific cards onto the wallet card. For example, a bank may initially load debit card information, cash- back credit card information, and airline rewards credit card information onto the wallet card. The user could then use the wallet card to conduct debit transactions or credit transactions which result in different rewards (in this case cash back or airline rewards). As needed, the issuing party may also modify the card information on the wallet card. For example, the user may cancel the airline rewards credit card. In this case, the issuing party would communicate instructions to the card to delete this account. In another example, the issuing party may update the cash- back credit card information, for example if the card expired and the user authorized the third part to issue a replacement card. In this case, the issuing party would communicate instructions to the card to modify this account. In another example, the user may indicate that it wishes to open a new account with the issuing party, for example a low-interest credit card. In this case, the issuing party would communicate instructions to the card to add this account to the accounts stored on the wallet card. In an embodiment, deleted, modified, or added information may include EMV information. In an embodiment, an EMV chip may communicate card specific information related to the selected card.

[0852] In an embodiment, a wallet card may be limited to a specific network. The wallet card may be issued by a specific network, or a third party may only be authorized to provide card information for cards from a specific network on a given wallet card. For example, a credit card company, such as Visa®, may issue a wallet card, but only permit that credit cards company's (or a select few card issuing companies) cards to be accessed using the wallet card. Such a wallet card may include additional branding information identifying the wallet card, for example holograms or other logos. Some of this information may appear on the display itself.

[0853] In an embodiment, a wallet card may be limited to a specific financial institution. The wallet card may be issued by a specific financial institution, for example a specific bank, and may only maintain cards provided by that specific financial institution. For example, a bank, such as Bank of America®, may issue a wallet card, but only permit that bank's (or a select few card issuing companies) cards to be accessed using the wallet card. Such a wallet card may include additional branding information identifying the wallet card, for example holograms or other logos. Some of this information may appear on the display itself.

[0854] In an embodiment, if certain conditions are met, the card may go to sleep, turning off the display and all dynamic magnetic stripe communications devices. In an embodiment, within a set amount of time after the card is last interacted with, it will go to sleep. In an embodiment, the card may include a on/off button that, when pressed, will either put the card to sleep or wake it up from sleep.

[0855] In an embodiment, the wallet card may also maintain and display information related to the rewards tier achieved by a user with respect to the selected card. In an embodiment, the tier may be displayed on the card, for example with the selected card information or on a separate display. In an embodiment, the issuer's logo may be modified to display the tier of the selected card. For example, if a user has achieved Visa Signature status for a specific card, the Visa logo may be modified to indicate that user has achieved Visa signature status for that card. In an embodiment, multiple tiers are possible, for example, Visa® basic, Visa Signature®, and Visa Black® or American Express Gold®, American Express Platinum®, American Express Reserve®, and American Express Black®.

[0856] In an embodiment, the user may achieve different tiers, rather than specific cards. In an embodiment, the user's status may be displayed, either with the card information or on a separate display. For example, MasterCard® may issue a wallet card, where all the cards are linked and accrue points towards

MasterCard World Elite® status. Once a user has achieved this status, for example, by making enough purchases across all stored cards, the card may indicate that the user has achieved this status.

[0857] FIG.50 shows an example wallet card according to example embodiments. Referring to FIG. 50, card 205 illustrates an exemplary wallet card prior to pushing a button on the wallet card. Card 255 illustrates the same exemplary wallet card after pushing a button on the wallet card. As described above, initially information regarding one stored card, in this case the Visa 1 card, is displayed. While not shown, additional information can be displayed to the user on the same or different displays. For example, the card number may be displayed in an embodiment. In an embodiment the Visa® logo may be displayed.

[0858] Prior to pressing the button, the EMV chip will communicate information associated with the Visa 1 card that is displayed on card 205. In an embodiment, the Visa 1 card information may also be communicated via multiple means, for example a dynamic magnetic stripe emulator, a dynamic magnetic stripe encoder, or wirelessly. In an embodiment, the Visa 1 card information may also be communicated wirelessly via Bluetooth, RFID, WiFi, light (using LEDs and light sensors), as well as other wireless communication means known to those skilled in the art.

[0859] After pressing the button, the EMV chip will communicate information associated with the Visa 2 card that is displayed on card 255. In an embodiment, the Visa 2 card information may also be communicated via multiple means, for example a dynamic magnetic stripe emulator, a dynamic magnetic stripe encoder, or wirelessly. In an embodiment, the Visa 2 card information may also be communicated wirelessly via Bluetooth, RFID, WiFi, light (using LEDs and light sensors), as well as other wireless communication means known to those skilled in the art. In an embodiment, card 205 maybe able to be recharged wirelessly, for example via a user's mobile phone. In an embodiment, card 255 may determine that additional charge is needed. In an embodiment, card 255 can display a message to the user to either slow down the swipe or leave the card in the reader to allow the card to recharge. In an embodiment, while card 255 is in the reader, the card can be powered solely by the reader, solely by the battery (allowing card 255 to simultaneously charge the battery), or a combination thereof.

[0860] In an embodiment, the display is bi-stable, allowing message to remain on the display even after the card powers down. In an embodiment, the issuer or 3^rd party provided may provide messaged to the card. For example, a party may display a birthday message on the user's birthday or offer $5 of the first purchase on a user's birthday. In an embodiment, the card may display message in response to transaction events. For example, if a transaction is denied, the card may display a reason for the transaction denial (low funds or high balance) and suggest an action (user a different account or request a credit increase). By providing the user with information about transaction denials and options forward, the card may maintain its top of wallet status. In an embodiment issuers may provide new card data (for example if a user is issued a new card) and remove old data (for example if a user's card data is expired or compromised). In an embodiment, a bi-stable display is used to provide a message to the user while conserving power.

[0861] FIG. 51 shows an example wallet card according to example embodiments. Referring to FIG. 51, card 305 illustrates an exemplary wallet card prior to pushing a button on the wallet card. Card 355 illustrates the same exemplary wallet card after pushing a button on the wallet card. In this embodiment, the screen shows data for the entire card, for example, the card name, the card number, expiration data, a verification code (such as a CVV or CVC code), and a network logo (for example a VISA® logo). Some or all of this information may change for each card. For example, in one instance, the card number and expiration date may change, by the network logo may remain the same, for example where the two cards are of the same interchange tiers. In another example, the logo may change as well, for example if the two cards belong to different interchange tiers. As described above, initially information regarding one stored card, in this case the Visa 1 card, is displayed. While not shown, additional information can be displayed to the user on the same or different displays. For example, the card number may be displayed in an embodiment. In an embodiment the Visa® logo may be displayed.

[0862] In an embodiment, additional cards can be downloaded to the wallet card wirelessly, for example, using Bluetooth, RFID, WiFi, light, or other wireless communication means. In an embodiment, card 305 may also be updated wirelessly, for example, via a phone using Bluetooth. [0863] In an embodiment, wallet card 305 is issued by a single entity, for example a bank. That entity may provide additional cards or services through the card. For example, the entity may provide updates to a user's device, for example a mobile phone, which can wirelessly communicate information to the wallet card. In this way, additional card or services may be provided to the user, as discussed in more detail below.

[0864] In an embodiment, wallet card 305 may be limited to cards associated with a specific issuer, cards associated with a specific network, or cards associated with a specific network and specific issuer. [0865] FIG. 52 shows exemplary wallet card displays according to example embodiments.

[0866] Referring to FIG. 52, card display 405 illustrates an exemplary wallet card display communicating that the monthly payment is due. In an embodiment, other account status updates may be provided, for example, points accumulated, points redeemed, points expiring, recent transactions, etc. [0867] Card display 410 illustrates an exemplary wallet card display communicating that a user is approaching their spending limit. In an embodiment, other warnings may be provided, for example, finance charges, unusual activity notifications, etc.

[0868] Card display 415 illustrates an exemplary wallet card display communicating that the user has been offered a gift. This may be offered by the issuer, network, or a third party. Gifts may be offered in response to reaching certain milestones, for example accumulating a certain number of points, or randomly, as desired by the party offering the gift. [0869] Card display 420 illustrates an exemplary wallet card display communicating that the user can now apply for a new card provided by the issuer and/or the network. It may also be used to indicate that a new card, that was previously applied for, has been approved and downloaded to the card. This may allow issuers and networks to provide cards to their current customers instantly, without incurring the cost associated with manufacturing and mailing a new physical card.

[0870] Card display 425 illustrates an exemplary wallet card display communicating a special event. In an embodiment, this may be a generic event, for example New Year Celebrations, or may be specific to the user (for example, happy birthday) or the network or issuer (for example, corporate milestone events).

[0871] Card display 430 illustrates an exemplary wallet card display communicating a loyalty program offered by an issuer or a partner of the issuer. For example, an issuer may provide certain rewards based on usage of the card. Alternatively, a third party may partner with the issuer, for example a coffee shop, to provide loyalty rewards and incentives through the card.

[0872] Card display 435 illustrates an exemplary wallet card display communicating a coupon. In an embodiment, the coupon may be delivered as a UPC or bar code. In an embodiment, the merchant associated with a coupon may be disclosed, but the actual coupon may not be disclosed until it is redeemed.

[0873] Card display 440 illustrates an exemplary wallet card display communicating status upgrades for the user. For example, the card may be issued by an airline. Once a user has attained a specific flight status, information may be communicated to the user via the card.

[0874] Card display 445 illustrates an exemplary wallet card display may communicate points earned during transactions. In an embodiment, the display may also disclose the total points accumulated by the user. [0875] Card displays 450 and 455 illustrates an exemplary wallet card display may provide information regarding associated games. In an embodiment, users may earn gaming rewards by using their card or rewards may be provided to users by the issuer, and communicated to the user via the card.

[0876] Card display 460 illustrates an exemplary wallet card display communicate that a user has entered, or has won, a sweepstakes.

[0877] FIG. 53 shows an example wallet card according to example embodiments. Referring to FIG. 53, the top card illustrates an exemplary wallet card prior to pushing a button on the wallet card. The bottom card 355 illustrates the same exemplary wallet card after pushing a button on the wallet card.

Whereas in previous cards, for example the exemplary cards illustrated in Figure 3, the card holder's name is embossed on the card, in this embodiment, the card holder's name is provided on a display. In an embodiment the card holder name display can be a bi- stable display. Initially, the card can be manufactured without any information on the display. Once the card is ready to be personalized, the card holder's name can be programmed into the card. In an embodiment, at any point in the future, the card may be initialized, and the card holder's name can be displayed. In an embodiment, from that point forward, the card holder's name can always be displayed. In an embodiment, the card holder's name can be displayed each time the card is powered on, and removed each time the card is powered off.

[0878] FIG. 54 shows dynamic magnetic stripe 600 that may include a printed circuit board (PCB) and an adhesive layer (not shown) on top of the PCB. The dynamic magnetic stripe 600 may include a dynamic magnetic stripe communications device 602, a first magnet 604, and a second magnet 606. In some embodiments, the dynamic magnetic stripe 600 may also include a shield 608.

[0879] Dynamic magnetic stripe communications device 202 may be configured to communicate multiple tracks of electromagnetic data, for example, two tracks of electromagnetic data, by electromagnetic generator to read-heads of a magnetic stripe reader by appropriate control of current conducted by coils within dynamic magnetic stripe communications device 602. Dynamic magnetic stripe communications device 602 may be configured to be narrower than a traditional magnetic stripe. For example the entire width of dynamic magnetic stripe 600, including dynamic magnetic stripe communications device 602, first magnet 604, and second magnet 606 may be approximately equal to the width of a traditional magnetic stripe, for example about 10 mm wide. In an embodiment, dynamic magnetic stripe communications device 602 may be about 5 mm wide. In an embodiment, dynamic magnetic stripe communications device 602 is flexible.

[0880] First magnet 604 and second magnet 606 may be operable to bias electromagnetic data communicated by dynamic magnetic stripe communications device 602. For example, first magnet 604 and second magnet 606 may be operable to increase the amplitude of the electromagnetic data communicated by dynamic magnetic stripe communications device 602 to allow a magnetic read head to receive the electromagnetic data. In an embodiment, first magnet 604 and second magnet 606 may be operable to increase the amplitude of the electromagnetic data transmitted by different portions of dynamic magnetic stripe communications device 602 so that a magnetic read head located at a distance, for example, ¼ of an inch, an inch, or two inches away, can receive the data. In some embodiments, the magnetic read head may be located at least of an inch away, at least one inch away, or at least two inches away. In some embodiments, the magnetic read head may be located less than ¼ of an inch away, less than one inch away, or less than two inches away. In some embodiments, the magnetic read head may be located from about 1/10 of an inch away to about 3 inches away. In an embodiment, first magnet 604 and second magnet 606 may be configured to maintain a constant magnetic field amplitude across the length of dynamic magnetic stripe communications device 602. In an embodiment, first magnet 604 can be configured to bias one track of electromagnetic data and second magnet 606 can be configured to bias a second track of electromagnetic data. In an embodiment, first magnet 604 and second magnet 606 may be configured to reduce or eliminate cross talk between different tracks of the electromagnetic data, for example between a first and a second track of electromagnetic data. In an embodiment, first magnet 604 and second magnet 606 are flexible. In an embodiment, first magnet 604 and second magnet 606 are directly adjacent to dynamic magnetic stripe communications device 602. In an embodiment, first magnet 604 and second magnet 606 are close to but separated from dynamic magnetic stripe communications device 602.

[0881] In an embodiment, shield 608 may be operable to inhibit or block electromagnetic data communicated by dynamic magnetic stripe communications device 602. In an embodiment, shield 608 may be operable to inhibit or block electromagnetic effects. For example, this may increase the probability that a card is correctly read by a magnetic stripe reader with two read heads, positioned on opposite sides of the card and offset. In an embodiment, shield 608 comprises a material that is non-magnetic and conductive, for example copper. In an embodiment, shield 608 comprises a material that is magnetic and conductive. In an embodiment, shield 608 comprises a material that is a combination of magnetic and non-magnetic material. In an embodiment, shield 608 is as wide as dynamic magnetic stripe communications device 602. In an embodiment, shield 608 comprises a plurality of shield material, for example a strip of shield material associated with each track. In an embodiment, shield 608 is as wide as dynamic magnetic stripe 600. In an embodiment, shield 608 is wider than dynamic magnetic stripe 600. In an embodiment, shield 608 is flexible.

[0882] FIG. 55 shows a traditional magnetic stripe 730 and a dynamic magnetic stripe 705, each of which may include printed circuit board (PCB) and an adhesive layer (not shown) on top of the PCB. [0883] In an embodiment, traditional magnetic stripe 730 is similar to magnetic stripes found on traditional cards, for example static credit cards.

[0884] In an embodiment, dynamic magnetic stripe 705 is similar to dynamic magnetic stripe 600 illustrated in Fig. 6 and discussed above. Dynamic magnetic stripe 705 may include dynamic magnetic stripe communications device 715, first magnet 710, second magnet 720, a first sensor 735a, and a second sensor 735b, as illustrated in Fig. 55. In some embodiments, dynamic magnetic stripe 715 may also include shield 725.

[0885] Dynamic magnetic stripe communications device 715 may be configured to communicate multiple tracks of electromagnetic data, for example, two tracks of electromagnetic data, by electromagnetic generator to read-heads of a magnetic stripe reader by appropriate control of current conducted by coils within dynamic magnetic stripe communications device 715. Dynamic magnetic stripe communications device 715 may be configured to be narrower than a traditional magnetic stripe. For example the entire width of dynamic magnetic stripe 705, including dynamic magnetic stripe communications device 715, first magnet 710, and second magnet 720 may be approximately equal to the width of a traditional magnetic stripe, for example about 10 mm wide. In an embodiment, dynamic magnetic stripe communications device 715 may be about 5 mm wide. In an embodiment, dynamic magnetic stripe communications device 715 is flexible.

[0886] First magnet 710 and second magnet 720 may be operable to bias electromagnetic data communicated by dynamic magnetic stripe communications device 715. For example, first magnet 710 and second magnet 720 may be operable to increase the amplitude of the electromagnetic data communicated by dynamic magnetic stripe communications device 715 to allow a magnetic read head to receive the electromagnetic data. In an embodiment, first magnet 710 and second magnet 720 may be operable to increase the amplitude of the electromagnetic data transmitted by different portions of dynamic magnetic stripe communications device 715 so that a magnetic read head located at a distance, for example, ¼ of an inch, an inch, or two inches away, can receive the data. In some embodiments, the magnetic read head may be located at least of an inch away, at least one inch away, or at least two inches away. In some embodiments, the magnetic read head may be located less than of an inch away, less than one inch away, or less than two inches away. In some embodiments, the magnetic read head may be located from about 1/10 of an inch away to about 3 inches away. In an embodiment, first magnet 710 and second magnet 720 may be configured to maintain a constant magnetic field amplitude across the length of dynamic magnetic stripe communications device 715. In an embodiment, first magnet 710 can be configured to bias one track of electromagnetic data and second magnet 720 can be configured to bias a second track of electromagnetic data. In an embodiment, first magnet 710 and second magnet 720 may be configured to reduce or eliminate cross talk between different tracks of the electromagnetic data, for example between a first and a second track of electromagnetic data. In an embodiment, first magnet 710 and second magnet 720 are flexible. In an embodiment, first magnet 710 and second magnet 720 are directly adjacent to dynamic magnetic stripe communications device 715. In an embodiment, first magnet 710 and second magnet 720 are close to but separated from dynamic magnetic stripe communications device 715.

[0887] In an embodiment, shield 725 may be operable to inhibit or block electromagnetic data communicated by dynamic magnetic stripe communications device 715. In an embodiment, shield 725 may be operable to inhibit or block electromagnetic effects. For example, this may increase the probability that a card is correctly read by a magnetic stripe reader with two read heads, positioned on opposite sides of the card and offset. In an embodiment, shield 725 comprises a material that is non-magnetic and conductive, for example copper. In an embodiment, shield 725 comprises a material that is magnetic and conductive. In an embodiment, shield 725 comprises a material that is a combination of magnetic and non-magnetic material. In an embodiment, shield 725 is as wide as dynamic magnetic stripe communications device 715. In an embodiment, shield 725 comprises a plurality of shield material, for example a strip of shield material associated with each track. In an embodiment, shield 725 is as wide as dynamic magnetic stripe 705. In an embodiment, shield 725 is wider than dynamic magnetic stripe 705. In an embodiment, shield 725 is flexible.

[0888] In an embodiment, shield 725 may be operable to inhibit or block electromagnetic data communicated by dynamic magnetic stripe communication device 715 and/or traditional magnetic stripe 730. In an embodiment, shield 725 may be operable to inhibit or block any electromagnetic data. In an embodiment, shield 725 comprises a material that is non-magnetic and conductive, for example copper. In an embodiment, shield 725 comprises a material that is magnetic and conductive. In an embodiment, shield 725 comprises a material that is a combination of magnetic and non- magnetic material. In an embodiment, shield 725 is flexible.

[0889] In an embodiment, first sensor 735a and second sensor 735b may be operable to detect the presence of a read-head. In an embodiment, first sensor 735a and second sensor 735b may be operable to generate a voltage in relation to magnetic fields it experiences. For example, first sensor 735a and second sensor 325b may be Hall sensors, or other sensors that are affected by the "Hall effect." In an embodiment, when a magnetic read-head passes over the card, the voltage generated by the first sensor 735a and second sensor 735b will change. For example, first sensor 325a and second sensor 735b may be configured to increase the voltage output when a magnetic read-head passes over the card. In another embodiment, the first sensor 735a and second sensor 735b can be configured to generate a different change in voltage when a magnetic read-head passes under the card. For example, first sensor 735a and second sensor 735b may be configured to decrease the voltage output when a magnetic read-head passes under the card. Thus, by measuring the voltage output from the first sensor 735a and second sensor 735b, the device is able to determine if a magnetic read-head is passing over or under the card, and only activate dynamic magnetic stripe 705 when the read head is over the correct side of the card. Further, by measuring the voltage change across both the first sensor 735a and second sensor 735b, the device may determine which direction it is being traveling, for example if it is being swiped through a payment reader. This will allow it to output data on dynamic magnetic stripe communications device 715 in the appropriate order using the appropriate formatting.

[0890] FIG. 56 illustrates a device containing two dynamic magnetic stripes stacked within the device 800, each operable to communicate with read heads located proximate to opposite sides of the device. In an embodiment, the first dynamic magnetic stripe comprises a dynamic magnetic stripe communications device 805, a first magnet 810, and a second magnet 815 and the second dynamic magnetic stripe comprises a dynamic magnetic stripe communications device 830, a first magnet 825, a second magnet 835, a first sensor 840a, and a second sensor 840b.

[0891] Dynamic magnetic stripe communications devices 805 and 830 may be configured to communicate multiple tracks of electromagnetic data, for example, two tracks of electromagnetic data, by electromagnetic generator to read-heads of a magnetic stripe reader by appropriate control of current conducted by coils within dynamic magnetic stripe communications devices 805 and 830. Dynamic magnetic stripe communications devices 805 and 830 may be configured to be narrower than a traditional magnetic stripe. For example the entire width of each dynamic magnetic stripe, including dynamic magnetic stripe communications devices 805 and 830, first magnets 810 and 825, and second magnet 815 and 835 may be approximately equal to the width of a traditional magnetic stripe, for example about 10 mm wide. In an embodiment, dynamic magnetic stripe communications devices 805 and 830 may be about 5 mm wide. In an embodiment, dynamic magnetic stripe communications devices 805 and 830 is flexible.

[0892] First magnets 810 and 825 and second magnets

815 and 835 may be operable to bias electromagnetic data communicated by dynamic magnetic stripe communications devices 805 and 830. For example, first magnets 810 and 825 and second magnets 815 and 835 may be operable to increase the amplitude of the electromagnetic data communicated by dynamic magnetic stripe communications devices 805 and 830 to allow a magnetic read head to receive the electromagnetic data. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 may be operable to increase the amplitude of the electromagnetic data transmitted by different portions of dynamic magnetic stripe communications devices 805 and 830 so that a magnetic read head located at a distance, for example, ¼ of an inch, an inch, or two inches away, can receive the data. In some embodiments, the magnetic read head may be located at least of an inch away, at least one inch away, or at least two inches away. In some embodiments, the magnetic read head may be located less than ¼ of an inch away, less than one inch away, or less than two inches away. In some embodiments, the magnetic read head may be located from about 1/10 of an inch away to about 3 inches away. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 may be configured to maintain a constant magnetic field amplitude across the length of dynamic magnetic stripe communications devices 805 and 830. In an embodiment, first magnets 810 and 825 can be configured to bias one track of electromagnetic data and second magnets 815 and 835 can be configured to bias a second track of electromagnetic data. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 may be configured to reduce or eliminate cross talk between different tracks of the electromagnetic data, for example between a first and a second track of electromagnetic data. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 are flexible. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 are directly adjacent to dynamic magnetic stripe communications devices 805 and 830, respectively. In an embodiment, first magnets 810 and 825 and second magnets 815 and 835 are close to but separated from their respective dynamic magnetic stripe communications devices 805 and 830.

[0893] In an embodiment, shield 820 may be operable to inhibit or block electromagnetic data communicated by dynamic magnetic stripe communications device 805. In an embodiment, shield 820 may be operable to inhibit or block electromagnetic effects. For example, this may increase the probability that a card is correctly read by a magnetic stripe reader with two read heads, positioned on opposite sides of the card and offset. In an embodiment, shield 820 comprises a material that is non-magnetic and conductive, for example copper. In an embodiment, shield 820 comprises a material that is magnetic and conductive. In an embodiment, shield 820 comprises a material that is a combination of magnetic and non-magnetic material. In an embodiment, shield 820 is as wide as dynamic magnetic stripe communications devices 805 or 830. In an embodiment, shield 820 comprises a plurality of shield material, for example a strip of shield material associated with each track. In an embodiment, shield 820 is as wide as one or both dynamic magnetic stripes. In an embodiment, shield 820 is wider than one or both dynamic magnetic stripes. In an embodiment, shield 820 is flexible.

[0894] In an embodiment, first magnets 810 and 825 may be a single magnet, e.g., to make handling and manufacturing easier. For example, using a single magnet may eliminate issue of manufacturing a device with two magnets whose magnetic poles are oriented in the same direction in proximity of each other. In an embodiment, a single first magnet may be configured to maintain a constant magnetic field amplitude across the length of dynamic magnetic stripe communications devices 805 and 830. In an embodiment, a single first magnet can be configured to bias one track of electromagnetic data in each of dynamic magnetic stripe communications devices 805 and 830. In an embodiment, a single first magnet may be configured to reduce or eliminate cross talk between different tracks of the electromagnetic data within dynamic magnetic stripe communications devices 805 and 830.

[0895] In an embodiment, second magnets 815 and 835 may be a single magnet, e.g., to make handling and manufacturing easier. For example, using a single magnet may eliminate issue of manufacturing a device with two magnets whose magnetic poles are oriented in the same direction in proximity of each other. In an embodiment, a single second magnet may be configured to maintain a constant magnetic field amplitude across the length of dynamic magnetic stripe communications devices 815 and 835. In an embodiment, a single second magnet can be configured to bias one track of electromagnetic data in each of dynamic magnetic stripe communications devices 815 and 835. In an embodiment, a single second magnet may be configured to reduce or eliminate cross talk between different tracks of the electromagnetic data within dynamic magnetic stripe communications devices 815 and 835.

[0896] In some embodiments, shield 820 may be placed between dynamic magnetic stripe communications devices 805, first magnets 810, and/or second magnets 815 and dynamic magnetic stripe communications devices 830, first magnets 825, and/or second magnets 835. In an embodiment, each of these elements function in the same manner as described above in relation to their respective dynamic magnetic stripe.

[0897] In an embodiment, first sensor 840a and second sensor 840b may be operable to detect the presence of a read-head. In an embodiment, first sensor 840a and second sensor 840b may be operable to generate a voltage in relation to magnetic fields it experiences. For example, first sensor 840a and second sensor 840b may be Hall sensors, or other sensors that are affected by the "Hall effect." In an embodiment, when a magnetic read-head passes over the card, the voltage generated by the first sensor 840a and second sensor 840b will change. For example, first sensor 840a and second sensor 840b may be configured to increase the voltage output when a magnetic read-head passes over the card. In another embodiment, the first sensor 840a and second sensor 840b can be configured to generate a different change in voltage when a magnetic read-head passes under the card. For example, first sensor 840a and second sensor 840b may be configured to decrease the voltage output when a magnetic read-head passes under the card. Thus, by measuring the voltage output from the first sensor 840a and second sensor 840b, the device is able to determine if a magnetic read-head is passing over or under the card, and only activate dynamic magnetic stripe 805 or 830 when the read head is over the correct side of the card. In an embodiment, first sensor 840a and second sensor 840b may be configured to provide a specific voltage output when a magnetic read-head passes under the card at the same time as when a magnetic read-head passes over the card. Thus, by measuring the voltage output from the first sensor 840a and second sensor 840b, the device is able to determine if it should activate dynamic magnetic stripe 805, 830, or both. In an embodiment, the voltage increase or decrease may also be measured to identify the type of magnetic read-head, for example a shielded magnetic read-head. Further, by measuring the voltage change across both the first sensor 840a and second sensor 840b, the device may determine which direction it is being traveling, for example if it is being swiped through a payment reader. This will allow it to output data on dynamic magnetic stripe communications device 805, 830, or both in the appropriate order using the appropriate formatting. [0898] In an embodiment, a card, for example card 100, may be provided without any activated products.

For Example, all displays may be blank and the card may be configured not to transmit any data. In an embodiment, the card may display a serial number, either printed on the card or displayed on one or more of the displays. A user may use this serial number to receive a product activation code, for example by entering it into a web site, providing it to an authorized issuer in person, over the phone, or via text, or other manners known to a person of skill in the art. In this way, cards can be manufactured without personal information and handed out at a variety of avenues such as launch parties, sports events, college campuses, etc. without requiring users to fill out application forms. Later information can be gathered from the user, for example when the serial number is entered. Alternatively, information can be entered earlier, for example due to previous interactions with the issuer, and the user can link this card, through the serial number, to an existing account.

[0899] A product activation code may be utilized to activate a product on the card. The product may be stored on the card or other device (e.g., a mobile telephonic device) and may be inactive to authorize a purchase until activated. This product activation code may be entered online via a website or on the card.

The code may be entered on the card manually (e.g., via a user interface) or via a wire-based or wireless connection (e.g., a wireless connection to a computer). Accordingly, the product may be activated on the card (or other device) or on a remote authorization server. [0900] Product activation may occur in a variety of ways. Particularly, for example, an activation code received on a card may cause a processor to communicate product data via a communications device when a button associated with that product is pressed. For example, a payment card number associated with a product may be communicated through an RFID antenna, IC chip, and/or magnetic stripe communications device once the product is activated on card 100. Additionally, for example, data associated with the product (e.g., a portion or the entire payment card number) may be displayed on a display on card 100 after a product has been activated. Product data may, for example, be pre-stored on a card when the card is mailed to a user. An activation code may cause a particular product to be associated with a particular button (or manual interface input) and communicated through a communications device (e.g., a dynamic magnetic stripe communications device) when that button (or manual interface input) is provided by a user to a card. An activation code may be received online, in a store, or over a phone to enter into a card.

[0901] A pre-stored product may be pre-associated to a particular button or may be associated to a particular button at activation. For example, a primary product (e.g., a product the user desired to obtain and was mailed to a user) may have printed information on the face of a card for online and phone purchases. A non-activated product may also have printed information on the face of a card for online and phone purchases and may be associated with a button for in-store purchases, but may not communicate magnetic stripe information until the product is activated. Similarly, for example, the product may have a verification code that displays on a display after product activation. Alternatively, for example, the activation code may be printed. As per another example, a card may have a plurality of buttons (e.g., two), but may have more non-activated products stored than buttons. In doing so, an issuer may be provided with a number of cross-selling opportunities. When a user activates a particular product, that product may be associated with a button. As such, the corresponding magnetic stripe data communicated through a dynamic magnetic stripe communications device may be communicated when the associated button is pressed by a user. In doing so, more products may be stored in a card in an inactivated state than there are buttons, or other manual user interface inputs, on a card. In this manner, a user may be provided with a larger variety of products to activate. An activated product may be associated with the next available button from a list of available buttons. Displays next to these buttons may be utilized to, for example, indicate the payment product associated to the button. A card may have a particular button for activating a product that may be pressed before an activation code is entered. In doing so, the processor of a card may determine when a code is desired to be entered by a user.

[0902] A product may be activated on a remote authorization server. Accordingly, a card may, for example, communicate data (e.g., via a magnetic stripe communications device) before a payment product is activated. Yet, the authorization of a payment associated with that payment product may not be authorized until the product is activated.

Accordingly, activation of the authorization may occur by having a user enter a code online or provide a code over the phone. This code may be generated by a card via a display to identify the card and/or payment product. In this manner, for example, a card may be provided to a user in a particular configuration. For example, the card may include multiple printed account numbers for both activated and non-activated products. A button may be associated with each activated and non- activated product. To activate a product, a user may activate a product online or via a telephone call. The user may identify himself/herself in a variety of ways such as, for example, answering a number of security questions, providing information about recent purchases, and/or providing particular passwords. A card-generated and displayed activation code may also be utilized. The product may be activated such that the product may be utilized to authorize purchase transactions. Accordingly, the product may be used online or offline before activation but not cause a purchase transaction to complete until the product is activated and remote authorization servers updated with product activation information.

[0903] Both a card and the authorization servers may, for example, be activated. For example, a user may press button 138 to receive an authorization activation code. A user may provide this information to a remote server (e.g., either online or via an operator over the phone). The user may receive an on- card product activation code from this remote server (e.g., via a webpage or via the operator over the phone). The card may then receive this code to activate the product for the button and, for example, cause the next press of button 138 to display information associated with that product on display 125 (e.g., a payment card number) and communicate information associated with the product via one or more communication devices (e.g., RFID antennas, IC chips, or magnetic stripe communication devices). The code may be received via manual input (e.g., manual input using buttons 130-134), wire-based input (e.g., USB) or wireless input (e.g., via light pulses, sound pulses, or other wireless communication signals). [0904] A product that a user did not particularly request to be on a card may or may not require an activation code to initiate the product. The additional product may be utilized by a user by, for example, entering manual input into the card indicative of a desire to use that additional product (e.g., pushing a mechanical button). Accordingly, a user may receive a mailing that includes a card with a payment product that a user requested as well as one or more products that the user did not request. Such products may be pre-approved and may operate and authorize transactions without, for example, a particular activation code. A card may include additional products that a user did not request, for example, where some of these additional products require an activation code and other of these additional products do not require an activation code.

[0905] Activation of inactivated products can be performed online via a webpage or over the phone via an operator without the actual use of an activation code. For example, a user may identify himself/herself by logging into an online account. The user may select a primary account associated with a card. The user may then be displayed with information associated with the additional products that were provided on the card. Accordingly, a user may select an activation button on the website to activate the product. A card may generate (e.g., display) a code after a product is activated that may be provided back to a remote facility to confirm proper activation. Additionally, a card may generate a code via a communications device (e.g., a dynamic magnetic stripe device, RFID, or IC chip) such that an on-card activation verification code may be communicated with a user's first purchase.

[0906] Products that may be placed on a card may include, for example, debit products (e.g., decoupled or coupled debit products), credit products, gift products, pre-paid payment products, loyalty products, or any other type of product. Such products may each have a different number that is communicated via one or more reader communications devices (e.g., an RFID antenna, IC chip, or magnetic stripe communications device) as well as one or more displays.

[0907] Accordingly, for example, a grocery store chain (e.g., Giant Eagle) may provide users with a credit card that includes an inactivated loyalty number. The loyalty number may be used to receive discounts and instant coupons at the grocery store chain. Accordingly, a user may press a button, for example, associated with the credit card product to have a credit card number associated with that credit card product communicated via a communications device (e.g., a magnetic stripe communications device). A user may press a different button, for example, associated with the loyalty product, to have the loyalty number associated with the loyalty product, communicated via a communications device (e.g., that same magnetic stripe communications device). Alternatively, for example, the credit card product may be a default product that automatically communicates the credit card number associated with the default credit card product whenever the card is utilized without additional manual input. A user may log into his/her online account for the credit card product and may activate the loyalty card. Additionally, for example, the user may change/replace the number by changing the number online via the website and being provided with a code to enter into the card to change/replace the product (e.g., via manual input, light, sound, or a wireless or wire-based communications signal).

[0908] Incentives to activate a product may be provided to a user. Such incentives may be displayed online (e.g., via a webpage displaying the products to- be-activated) or on-card. For example, a user may press a button associated with an inactivated card and may be provided with an incentive on a display. For example, a user may be provided with text indicating that if the user activates the product within a period of time (e.g., within the next 10 days) then an amount of money may be added to a user's account.

Accordingly, a card may provide an activation code that includes embedded information indicative of the incentive. An incentive code (e.g., promotional code) may also be displayed to a user. Incentives may be displayed based on time. For example, one incentive may be displayed during the first 10 days a card is used by a user and a different incentive may be displayed during the next 10 days a card is used by a user. After all incentives are exhausted, for example, a card may erase the new product so that the product is removed from a card. An incentive and/or new product may be erased after a period of time or upon a card receiving manual input from a user indicative of a user's desire to erase the product and/or incentive. [0909] Similarly, for example, multiple new products may be stored on the card and rotated such that different new products may be displayed to a user. A display may be provided next to a button and the name of the new product may be displayed on such a display. A user may navigate through possible new products and may select, on card 100, the product or products the user desires. A user may erase products the user does not desire from a memory of card 100.

[0910] FIG. 57 shows network topology 900 that may include, for example, mobile device 902 (e.g., a mobile telephonic device, a PDA, an electronic tablet, a laptop, a GPS unit, or an MP3 player). Mobile device 902 may, for example, include a contactless interface that may initiate, sustain, and/or terminate communication channel 926 between card 904 and mobile device 902. Card 904 and mobile device 902 may communicate via channel 926 via a contactless communication medium (e.g., an RF medium).

[0911] Mobile device 902 may provide one or more transceivers that may communicate with one or more wired networks (e.g., IP network 912 and/or payment network 914) and/or one or more wireless networks (e.g., mobile network 910). Mobile device 902 may, for example, communicate with a cellular station over a wireless radio interface (e.g., a GSM air interface) that may be used by mobile device 902 to communicate information (e.g., voice and data) to cellular network access infrastructure 906 (e.g., one or more GSM base transceiver stations, base station controllers, and mobile switching centers). Persons skilled in the art will appreciate that cellular network access infrastructure 906 may utilize any multiple access architecture, such as for example, a code-division multiple access architecture and/or a time-division multiple access architecture. [0912] Mobile device 902 may, for example, communicate with wireless access point 908 over a wireless interface (e.g., a Bluetooth interface or a Wi-Fi interface). Accordingly, for example, mobile device 902 may access one or more wired networks (e.g., IP network 912 and/or payment network 914) and/or one or more wireless networks (e.g., mobile network 910) without the need to first gain access to cellular network access infrastructure 906.

[0913] Card 904 may, for example, be a powered card or a non-powered card (e.g., a powered payment card or a non-powered payment card). Accordingly, for example, payment information (e.g., a payment account number and a card expiration date) may be communicated from card 904 to mobile device 902 in support of a financial transaction being conducted by mobile device 902. In so doing, for example, items for purchase on IP network 912 (e.g., the internet) may be accessed by a browser of mobile device 902 via an access point (e.g., wireless access point 908 or cellular network access infrastructure 906). Mobile device 902 may, for example, complete a purchase transaction by first obtaining required payment information from card 904 and then communicating such payment information to network entities (e.g., payment server 916 and/or issuer 920).

[0914] Payment server 916 may, for example, contact issuer 920 via a network (e.g., payment network 914) with payment information received from mobile device 902 for authorization of a purchase. Once authorized, payment transaction information may be recorded onto a receipt that may be delivered to mobile device 902 via any one or more delivery options (e.g., via a short messaging service of mobile network 910 or an email delivery service of IP network 912). Mobile device 902 may allow a user to associate purchase categories (e.g., groceries, auto repair, or entertainment) to purchases transacted by the mobile device so that the user may receive a more detailed accounting of his or her expenditures on his or her receipt. Accordingly, for example, a user may enjoy a higher degree of integration such that a user may customize a level of detail provided on a receipt via mobile device 902. A payment receipt may, for example, be provided to mobile device 902 as a proof-of-purchase object (e.g., a barcode) that may be provided to a display of mobile device 902 and read by other computing equipment (e.g., a barcode scanner) for proof-of-purchase confirmation.

[0915] A device (e.g., mobile device 928 and/or card 922) may, for example, include a contactless communication device (e.g., an RFID device) that may initiate, sustain, and/or terminate a contactless communication channel (e.g., an RFID communications channel) with merchant terminal 918. Accordingly, for example, card 922 and/or mobile device 928 may communicate payment information to merchant terminal 918 to complete a financial transaction. In so doing, for example, mobile device 928 and/or card 922 may first receive a request from a user to communicate payment information to merchant terminal 918.

[0916] As per an example, a user of card 922 may press a button on card 922 that may cause payment information to be transferred to a memory of a processor (e.g., an RFID chip). An associated RFID antenna may, for example, sense the presence of merchant terminal 918 by detecting an RF carrier field that may be generated by an RFID device of merchant terminal 918. Once the presence of merchant terminal 918 is sensed, payment information may be transferred from an RFID chip of card 922 to an RFID antenna of card 922 to communicate the payment information via an RFID communication channel to merchant terminal 918 to complete a financial transaction.

[0917] As per another example, card 922 may be a non-powered card (e.g., a non-powered payment card). Accordingly, for example, card 922 may include an RFID chip and associated RFID antenna that may be brought within proximity to merchant terminal 918. An RFID antenna of card 922 may sense an RF carrier field generated by merchant terminal 918 and may derive operational power from the RF carrier field. The operational power may, for example, be collected by an RFID antenna of card 922 and provided to an associated RFID chip of card 922 in order to energize the RFID chip of card 922. Once energized, an RFID chip of card 922 may modulate an RF carrier field generated by merchant terminal 918 to, for example, communicate payment information from card 922 to merchant terminal 918 to complete a purchase transaction.

[0918] Any computing device (e.g., desktop computer 930) may, for example, provide contactless communication electronics (e.g., an RFID reader) that may communicate with a contactless communication device (e.g., card 932 and/or mobile device 934).

Accordingly, for example, any information that may be communicated by card 932 (e.g., payment information) may be received by computing device 930 (e.g., received via an RFID communication channel established between card 932 and computing device 930) and forwarded onto a network entity (e.g., issuer 920 and/or payment server 916) to complete a purchase transaction. Persons skilled in the art will appreciate that any RFID information may be exchanged between computing device 930 and an RFID enabled device (e.g., card 932 and/or mobile device 934).

[0919] FIG. 58 shows mobile device 1000. Mobile device 1000 may be any mobile device, such as a mobile telephonic device (e.g., cell phone), a PDA, an electronic tablet, an MP3 player, or a locating device (e.g., a GPS device). Accordingly, mobile device 1000 may be operated in a mobile environment while a user of mobile device 1000 goes about his or her daily activities (e.g., driving, shopping, walking, dining, and exercising). In addition, for example, mobile device 1000 may perform multiple functions simultaneously (e.g., a person may carry on a conversation while at the same time browsing and purchasing products on the internet).

[0920] Mobile device 1000 may include audio processing devices (e.g., microphone 1008 and speaker 1010). Accordingly, for example, mobile device 1000 may receive voice commands from a user via microphone 1008 and may process such commands to perform a function. For example, a user may place mobile device 1000 into a desired operational mode by speaking a command into microphone 1008 that is associated with the desired operational mode. In so doing, for example, mobile device 1000 may engage in hands-free operation by receiving voice commands via microphone 1008 and performing functions associated with the received voice commands. [0921] Mobile device 1000 may receive data input via microphone 1008. For example, a voice-band modem may generate signals in a voice-band frequency range that may be received by microphone 1008. A processor of mobile device 1000 may interpret the received audible information as data signals and may process the data signals as, for example, data values and/or control data input.

[0922] Mobile device 1000 may include camera 1002. Camera 1002 may capture one or more frames of video data and store the video data within a memory of mobile device 1000. Accordingly, for example, a processor of mobile device 1000 may receive one or more frames of video information via camera 1002 and may process the video information as data values and/or control data input. In so doing, for example, mobile device 1000 may receive optical information that is sensed by camera 1002 during a series of one or more video capture events that produce one or more frames of video information. The one or more frames of video information may contain one or more data elements (e.g., pixels) having properties (e.g., color, intensity, or contrast) that may be interpreted by a processor of mobile device 1000 as data values and/or control data.

[0923] Mobile device 1000 may include manual input interface 1012. Manual input interface 1012 may, for example, include keys and/or buttons that may be sensitive to manual input, such as a touch or an application of pressure. Accordingly, for example, a user of mobile device 1000 may enter information into mobile device 1000 via manual interface 1012 to cause a processor of mobile device 1000 to enter a particular mode of operation. Manual interface 1012 may, for example, be used for data entry (e.g., dialing a phone number or entering data as may be requested by mobile device 1000) during a particular mode of operation of mobile device 1000.

[0924] Mobile device 1000 may include display 1004. Display 1004 may provide visible information that may be utilized by a user during interaction with mobile device 1000. A portion or all of display 1004 may be touch sensitive such that objects making contact with display 1004 or objects coming within a proximity of display 1004 may be detected by a processor of mobile device 1000. Accordingly, for example, RFID operations graphical user interface 1006 may be provided by display 1004 so that graphical information may be displayed to solicit and/or receive data entry from a user. In so doing, for example, touch-sensitive graphical user interface devices such as radio buttons, textual input boxes, virtual buttons, pull-down menus, and navigational tools may be used for data entry to initiate, change, and/or support functions performed by mobile device 1000.

[0925] FIG. 10 shows architecture 1050. User interface 1052 may, for example, be included within architecture 1050 to allow user interaction with architecture 1050. For example, a dedicated key pad or keyboard may be included within user interface 1052 to allow alphanumeric data entry into architecture 1050. [0926] Architecture 1050 may include one or more displays 1054. Display 1054 may, for example, be touch-sensitive. Accordingly, for example, display 1054 may be utilized for alphanumeric data entry using virtual buttons that may be rendered onto touch- sensitive portions of display 1054. In so doing, for example, touching virtual buttons that may be associated with alphabetic and numeric characters of display 1054 may be detected by processor 1058 as alphanumeric data entry.

[0927] Alphanumeric entry boxes may, for example, be rendered onto display 1054. A user may, for example, activate a cursor within such an alphanumeric entry box by touching an area within the alphanumeric entry box. A user may utilize user interface 1052 and/or a virtual keypad rendered onto display 1054 to select alphanumeric characters to be placed within the alphanumeric entry box in accordance with a character position identified by an activated cursor within the alphanumeric entry box. In so doing, for example, processor 1058 may receive alphanumeric characters as typed into a alphanumeric entry box of display 1054 and may use such alphanumeric characters as data input.

[0928] Display 1054 may, for example, provide data output from architecture 1050. For example, display 1054 may communicate data using a series of light pulses. Accordingly, for example, processor 1058 may cause one or more portions of display 1054 to produce light pulses having varying characteristics (e.g., duration, intensity, and frequency) that may communicate information via such light pulses. In so doing, for example, a device that may be sensitive to light pulses may receive information communicated by display 1054 via light pulses having varying characteristics. Display 1054 may, for example, communicate data using visual information that may be substantially static (e.g., a barcode). [0929] Architecture 1050 may include one or more transceivers 1056. Transceiver 1056 may communicate information to and/or may receive information from one or more devices. Transceiver 1056 may, for example, communicate via a wireless interface with one or more cellular stations of a mobile network. Accordingly, for example, transceiver 1056 may allow a mobile device (e.g., mobile device 1000 of FIG. 10) to establish a communications channel with an associated cellular station. In so doing, for example, a mobile device (e.g., mobile device 1000 of FIG. 10) may exchange information (e.g., voice, text, data, or multimedia) with one or more terrestrial networks (e.g., the internet or a payment network) via an associated cellular station. As per another example, transceiver 1056 may exchange information with one or more other mobile devices via one or more associated cellular stations.

[0930] Transceiver 1056 may, for example, communicate via a wireless interface with one or more mobile devices directly. Accordingly, for example, transceiver 1056 may communicate with another mobile device without first accessing a mobile network via a cellular station of the mobile network. As per another example, transceiver 1056 may, for example, communicate via a wireless interface with one or more network devices (e.g., a wireless access point) directly. Accordingly, for example, a mobile device (e.g., mobile device 1000 of FIG. 10) may directly connect to a wired and/or a wireless network via any one or more wireless standards (e.g., Bluetooth or Wi-Fi) to exchange information with other devices that may be connected to the wired and/or wireless network. In so doing, for example, a wired and/or wireless network may be accessed by a mobile device without first accessing a mobile network via a cellular station of a mobile network.

[0931] Architecture 1050 may include RFID chip 1064, RFID antenna 1062, and optional RFID antenna 1066 which may combine to communicate with an RFID enabled device via an RFID communication channel. Accordingly, for example, architecture 1050 may be compatible with any RFID device, such as for example, an RFID enabled card, an RFID reader, and an RFID enabled computing device (e.g., an RFID enabled desktop computer). RFID antenna 1066 may, for example, be provided to enhance RFID data communication and/or reception.

[0932] RFID antenna 1062 and/or RFID antenna 1066 may, for example, establish an RF carrier field that may be modulated by an RFID device (e.g., an RFID tag of a non-powered payment card). In so doing, for example, an RFID tag of a non-powered payment card may derive operational power from an RF field provided by RFID antenna 1062 and/or RFID antenna 1066 and may communicate information (e.g., one, two, and/or three tracks of magnetic stripe data) to RFID antenna 1062 and/or RFID antenna 1066 by modulating the RF field produced by RFID antenna 1062 and/or RFID antenna 1066. [0933] A powered card may, for example, communicate with RFID antenna 1062 and/or RFID antenna 1066. A powered card may, for example, include a processor, a battery, a memory, a wireless communications device (e.g., a powered RFID device) and other electronics (e.g., buttons) that may allow a user to interact with the powered card to perform one or more functions. Accordingly, for example, a powered card may be used to communicate specific information to RFID antenna 1062 and/or RFID antenna 1066 by selective interaction with the buttons of the powered card. In so doing, for example, a powered card may be used to interactively communicate magnetic stripe information (e.g., one, two, and/or three tracks of magnetic stripe data) to RFID antenna 1062 and/or RFID antenna 1066 by sending a signal to a processor of a powered card (e.g., by pressing a button on the powered card) to initiate such communications.

[0934] RFID chip 1064 may, for example, receive RFID data from processor 1058 and may store such RFID data temporarily. Accordingly, for example, once an RFID communication channel is formed with an RFID enabled device, RFID data contained within RFID chip 1064 may be communicated to the RFID enabled device via RFID antenna 1062 and/or RFID antenna 1066. RFID antennas 1062 and 1066 may, for example, communicate the same RFID data to an RFID enabled device. RFID antennas 1062 and 1066 may, for example, communicate different RFID data sets to an RFID enabled device and the differences between the RFID data sets communicated may provide multiple other channels of data that may be communicated (e.g., an amplitude difference between RFID data sets may be an RFID data channel and a phase difference between RFID data sets may be an additional RFID data channel).

[0935] Architecture 1050 may include memory 1060 and/or processor 1058 may include internal memory. Accordingly, for example, application code may be stored within memory 1060 and/or processor 1058 and executed by processor 1058 in support of functions performed by architecture 1050. For example, an application (e.g., a graphical user interface) may be executed by processor 1058 and displayed onto display 1054, which may be used to interact with a user of a mobile device (e.g., mobile device 1000 of FIG. 10). Persons skilled in the art will appreciate that executable application code may be communicated to architecture 1050 via any one or more interfaces of architecture 1050 (e.g., user interface 1052, display 1054, transceiver 1056, and/or RFID antennas 1062 and/or 1066).

[0936] Application data (e.g., payment data) may be temporarily stored within RFID chip 1064 and communicated by RFID antenna 1062 and/or RFID antenna 1066 during operation. For example, payment data may be temporarily communicated to RFID chip 1064 by processor 1058 during a financial transaction being conducted via an RFID communication channel between a mobile device (e.g., mobile device 1000 of FIG. 10) and another RFID device (e.g., a merchant terminal). Once RFID data is communicated (or after a configurable delay period has expired), processor 1058 may cause the payment data stored within RFID chip 1064 to be erased so as to reduce an ability of an RFID skimmer to access data from RFID chip 1064.

[0937] FIG. 59 shows card 1100, which may be a powered card and may include, for example, board 1102, board 1104, dynamic magnetic communications device 1106, RFID chip 1118, board 1108, battery 1114, conductive leads 1120-1126 and RFID antenna 1116. Additional circuitry may be provided on board 1102, which may include, for example, processor 1130, an EMV chip, a display, a display driver, driver circuitry for dynamic magnetic stripe communications device 1106, light emitting diodes, light sensors, infrared sensors and transmitters, capacitive sensing contacts, and a user interface (e.g., one or more buttons).

[0938] All boards, circuitry, and other components of card 1100 may be laminated to form card assembly 1110. Such a lamination may, for example, be implemented using a series of lamination process steps, such that an electronics package containing boards 1102, 1104, and/or 1108 and associated electronics may be encapsulated by an injection molding process (e.g., a reaction injection molding process), whereby a silicon-based material or a polyurethane-based material may be injected and cured (e.g., using temperature and/or chemical reaction) to form the electronics package. The electronics package may then be sandwiched between layers of laminate (e.g., layers of polymer laminate). Accordingly, for example, both surfaces of card assembly 1110 may be formed by a layer of laminate such that no electrical contacts exist on either surface of card assembly 1110. Alternately, for example, a surface of card assembly 1110 may be formed by a layer of laminate such that electrical contacts may exist on a surface of card assembly 1110 to provide connectivity from a surface of card assembly 1110 to a processor (e.g., an EMV chip) of card 1100.

[0939] RFID antenna 1116 may, for example, be formed using an additive technique, whereby patterns of a conductive element (e.g., copper) may be applied to a PCB substrate (e.g., applied to either side of board 1108) according to a patterning mask definition layer. RFID antenna 1116 may, for example, be formed using a subtractive technique whereby patterns of a conductive element (e.g., copper) may be removed from a pre-plated PCB substrate (e.g., removed from either side of board 1108) according to an etching mask definition layer. Other non-PCB fabrication techniques may be used to implement RFID antenna 1116 as may be required by a particular application.

[0940] Conductive leads 1120 and 1122 may, for example, provide electrical conductivity between board 1108 and board 1102. Accordingly, for example, RFID data signals received by RFID antenna 1116 may be communicated to RFID chip 1118 via conductive leads 1120 and 1122. RFID data signals to be communicated by RFID antenna 1116 (e.g., RFID data signals provided to RFID chip 1118 via processor 1130) may, for example, be received from RFID chip 1118 via conductive leads 1120 and 1122. Conductive leads 1124 and 1126 may, for example, provide electrical conductivity between board 1108 and board 1102 so that operational power may be provided to the active electrical components that may exist on board 1102 from battery 1114. Conductive leads 1120-1126, for example, may use conductive adhesive, soldering paste, or any other type of conductive applications to provide electrical conductivity between boards 1108 and 1102.

[0941] FIG. 60 shows card 1200, which may be a powered card and may include, for example, board 1202, board 1204, dynamic magnetic communications device 1206, RFID chip 1218, board 1208, battery 1214, conductive leads 1220-1226 and RFID antenna 1216. Additional circuitry may be provided on board 1202, which may include, for example, processor 1230, an EMV chip, a display, a display driver, driver circuitry for dynamic magnetic stripe communications device 1206, light emitting diodes, light sensors, infrared sensors and transmitters, capacitive sensing contacts, and a user interface (e.g., one or more buttons). All boards, circuitry, and other components of card 1200 may, for example, be encapsulated by an injection molding process and sandwiched between two layers of laminate to form card assembly 1210 having no exposed contacts. Alternately, for example, a surface of card assembly 1210 may be formed by a layer of laminate such that electrical contacts may exist on a surface of card assembly 1210 to provide connectivity from a surface of card assembly 1210 to a processor (e.g., an EMV chip) of card 1200.

[0942] RFID antenna 1216 may, for example, be formed using additive and/or subtractive techniques to define patterns of a conductive element (e.g., copper) to form RFID antenna 1216 (e.g., on either side of board 1204). Conductive leads 1220 and 1222 may, for example, provide electrical conductivity between board 1204 and board 1202. Accordingly, for example, RFID data signals received by RFID antenna 1216 may be communicated to RFID chip 1218 via conductive leads 1220 and 1222. RFID data signals to be communicated by RFID antenna 1216 (e.g., as may be provided to RFID chip 1218 by processor 1230) may be received from RFID chip 1218 via conductive leads 1220 and 1222. Conductive leads 1224 and 1226 may, for example, provide electrical conductivity between board 1208 and board 1202 so that operational power may be provided to the active electrical components that may exist on board 1202 from battery 1214.

[0943] FIG. 61 shows card 600, which may be a powered card and may include, for example, board 602, board 604, dynamic magnetic communications device 606, RFID chip 618, board 608, battery 614, conductive leads 622-626 and RFID antenna 616. Additional circuitry may be provided on board 602, which may include, for example, processor 630, an EMV chip, a display, a display driver, driver circuitry for dynamic magnetic stripe communications device 606, light emitting diodes, light sensors, infrared sensors and transmitters, capacitive sensing contacts, and a user interface (e.g., one or more buttons). All boards, circuitry, and other components of card 600 may, for example, be encapsulated by an injection molding process and sandwiched between two layers of laminate to form card assembly 610 having no exposed contacts. Alternately, for example, a surface of card assembly 610 may be formed by a layer of laminate such that electrical contacts may exist on a surface of card assembly 610 to provide connectivity from a surface of card assembly 610 to a processor (e.g., an EMV chip) of card 600.

[0944] RFID antenna 616 may, for example, be formed using additive and/or subtractive techniques to define patterns of a conductive element (e.g., copper) to form RFID antenna 616 (e.g., on either side of board 604). One or more conductive leads 622 may, for example, provide electrical conductivity between RFID chip 618 of board 604 and processor 630 of board 602. Accordingly, for example, while data exchanged between RFID chip 618 and RFID antenna 616 may remain on board 604, one or more conduction paths 622 may be provided so that data that is to be communicated by RFID antenna 616 may first be communicated to RFID chip 618 by processor 630 that may exist, for example, on board 602. Conductive leads 624 and 626 may, for example, provide electrical conductivity between board 608 and board 602 so that operational power may be provided to the active electrical components that may exist on boards 602 and 604 from battery 614.

[0945] FIG. 62 shows card 700, which may be a powered card and may include, for example, board 702, board 704, dynamic magnetic communications device 706, RFID chip 718, board 708, battery 714, conductive leads 724-726 and RFID antenna 716. Additional circuitry may be provided on board 702, which may include, for example, processor 730, an EMV chip, a display, a display driver, driver circuitry for dynamic magnetic stripe communications device 706, light emitting diodes, light sensors, infrared sensors and transmitters, capacitive sensing contacts, and a user interface (e.g., one or more buttons). All boards, circuitry, and other components of card 700 may, for example, be encapsulated by an injection molding process and sandwiched between two layers of laminate to form card assembly 710 having no exposed contacts. Alternately, for example, a surface of card assembly 710 may be formed by a layer of laminate such that electrical contacts may exist on a surface of card assembly 710 to provide connectivity from a surface of card assembly 710 to a processor (e.g., an EMV chip) of card 700.

[0946] RFID antenna 716 may, for example, be formed using additive and/or subtractive techniques to define patterns of a conductive element (e.g., copper) to form RFID antenna 716 (e.g., on a top side of board 702). Accordingly, for example, RFID antenna 716 may be applied to board 702 at a location proximate to a location of board 704. In so doing, for example, RFID antenna 716 may be applied to board 702 below a location where board 704 attaches to board 702 and conduction paths may be extended to RFID chip 718 from RFID antenna 716 (e.g., via conductive traces on board 702). Conductive leads 724 and 726 may, for example, provide electrical conductivity between board 708 and board 702 so that operational power may be provided to the active electrical components that may exist on board 702 from battery 714. Persons skilled in the art will appreciate that RFID antenna 716 may be placed anywhere on any board (e.g., around a perimeter of board 702) so as to maximize an effectiveness of RFID antenna 716.

[0947] Persons skilled in the art will further appreciate that any combination of processors, EMV chips, display drivers, dynamic magnetic stripe communications device drivers, RFID chips, and associated circuitry may be combined into one or more application specific integrated circuits (ASIC). Accordingly, for example, a core processor may interoperate with an ASIC that combines the functionalities of an RFID chip, a dynamic magnetic stripe communications device driver, and a display driver. Alternately, for example, a core processor, RFID chip, a dynamic magnetic stripe communications device driver, a display driver and associated electronics may be consolidated into a single ASIC. As per another example, a core processor and an RFID chip may be provided as discrete components that may interoperate with an ASIC that may be dedicated to dynamic magnetic stripe communications device driver functions and another ASIC that may be dedicated to display driver functions. [0948] FIG. 63 shows card 1500, which may include multiple RFID antennas (e.g., RFID antennas 1502-1504) and associated RFID chips (e.g., RFID chips 1506-1508). Additional circuitry may be provided on card 1500, which may include, for example, a processor, an EMV chip, a display, a display driver, driver circuitry for a dynamic magnetic stripe communications device, light emitting diodes, light sensors, infrared sensors and transmitters, capacitive sensing contacts, and a user interface (e.g., one or more buttons). All boards, circuitry, and other components of card 1500 may, for example, be encapsulated by an injection molding process and sandwiched between two layers of laminate to form card assembly 1512 having no exposed contacts. Alternately, for example, a surface of card assembly 1512 may be formed by a layer of laminate such that electrical contacts may exist on a surface of card assembly 1512 to provide connectivity from a surface of card assembly 1512 to a processor (e.g., an EMV chip) of card 1500.

[0949] Processor 1510 may, for example, provide data to RFID chips 1506 and/or 1508 that may be communicated by RFID antenna 1502 and/or RFID antenna 1504, respectively. Processor 1510 may, for example, receive data from RFID chips 1506 and/or 1508 that may be received by RFID antenna 1502 and/or RFID antenna 1504, respectively.

[0950] Card 1500 may, for example, be placed within a communication distance of one or more RFID devices (e.g., one or more RFID enabled merchant terminals) in order to conduct a purchase transaction. Accordingly, for example, processor 1510 may communicate track 1 and track 2 magnetic stripe data to the RFID enabled merchant terminal via RFID chip 1506 and associated RFID antenna 1502. Alternately, for example, processor 1510 may communicate track 1 and track 2 magnetic stripe data to the RFID enabled merchant terminal via RFID chip 1508 and associated RFID antenna 1504.

[0951] As per another example, processor 1510 may utilize both RFID antennas 1502 and 1504 and associated RFID chips 1506 and 1508, respectively, to increase communication efficiency. Accordingly, for example, processor 1510 may communicate track 1 magnetic stripe data to RFID chip 1506 and track 2 magnetic stripe data to RFID chip 1508, so that track 1 magnetic stripe data may be communicated to an RFID enabled merchant terminal via RFID antenna 1502 and track 2 magnetic stripe data may be communicated to an RFID enabled merchant terminal via RFID antenna 1504. In so doing, for example, two tracks of magnetic stripe data may be communicated in half the time.

[0952] As per yet another example, RFID data communicated to RFID chips 1506 and 1508 by processor 1510 may be communicated in a fashion such that multiple channels of information may be communicated in addition to the first and second channels of information communicated by RFID chips 1506 and 1508. For example, phase, frequency, and/or amplitude differences between data communicated by RFID chip 1506/RFID antenna 1502 and data communicated by RFID chip 1508/RFID antenna 1504 may be used to communicate multiple channels of information. Accordingly, for example, a first set of information may be communicated by RFID chip 1506/RFID antenna 1502, a second set of information may be communicated by RFID chip 1508/RFID antenna 1504, and a third set of information may be communicated as an amplitude difference between each data element of the first and second information sets. A fourth set of information may be communicated, for example, as a phase difference between each data element of the first and second data sets. A fifth set of information may be communicated, for example, as a rate of change of the phase difference (e.g., frequency difference) between each data element of the first and second information sets. Persons skilled in the art will appreciate that any number of channels of information may be communicated by a pair of RFID communicators when differences between RFID data sets communicated by each RFID communicator are exploited as data channels.

[0953] A pair of RFID communicators may, for example, be used to increase accuracy of RFID data communicated. For example, the same RFID data may be communicated by RFID chip 1506/RFID antenna 1502 as is communicated by RFID chip 1508/RFID antenna 1504 so as to increase a probability that an RFID reader may receive RFID data that was intended to be communicated. Accordingly, for example, an RFID reader that may be spatially oriented such that data reception quality from a first RFID communicator is diminished in relation to a data reception quality from a second RFID communicator, may nevertheless receive a complete set of RFID data due to the redundant RFID communication configuration.

[0954] An RFID reader may, for example, employ collision avoidance algorithms, so that communications received from a first RFID communicator do not trump communications received from a second RFID communicator. Accordingly, for example, processor 1510 of card 1500 may communicate to such an RFID reader that dual RFID communicators may be present within card 1500. In so doing, for example, the RFID reader may activate its collision avoidance algorithm to accept RFID communications from both RFID communicators (e.g., RFID chip 1506/RFID antenna 1502 and RFID chip 1508/RFID antenna 1504) simultaneously.

[0955] RFID data may, for example, be received by RFID chip 1506/RFID antenna 1502 and RFID chip 1508/RFID antenna 1504. Accordingly, for example, card 1500 may be an RFID reader that may utilize a pair of RFID readers (e.g., a first RFID reader is provided by RFID chip 1506/RFID antenna 1502 and a second RFID reader is provided by RFID chip 1508/RFID antenna 1504). In so doing, for example, processor 1510 may impose an RFID communication protocol that accepts RFID data form each RFID reader simultaneously.

[0956] FIG. 64 shows card 1600 that may include, for example, configuration 1602. Configuration 1602 may include, for example, button 1604, button 1608, display 1606 and display 1610. Button 1604 may be associated with display 1606. Button 1604 may be pressed to utilize the option described by display 1606. Button 1608 may be associated with display 1610. Button 1608 may be pressed to utilize the option described by display 1610. A card may include additional buttons or displays or may not include the number of buttons or displays of card 1600. For example, a card may include only a single button (e.g., button 1604).

[0957] A user of card 1600 may, for example, select options 1606 or 1610 when card 1600 is to be used (e.g., when card 1600 is to be utilized at a point-of- sale terminal to complete a purchase transaction). Accordingly, for example, a user of card 1600 may press button 1604 to select option 1606 if the user wishes to exchange RFID data between card 1600 and an RFID device. Alternately, for example, a user of card 1600 may press button 1608 to select option 1610 if the user wishes to communication information to a magnetic stripe reader.

[0958] A user may, for example, press button 1608 to prepare card 1600 for communications with a magnetic stripe reader. Accordingly, for example, a processor of card 1600 may initiate a mode of operation upon activation of option 1610, whereby the processor searches for the presence of a read-head housing of a magnetic stripe reader. Once option 1610 is activated, a user may bring card 1600 within a communication distance of a magnetic stripe reader (e.g., the user may swipe card 1600 through a magnetic stripe reader). Upon the detection of the read-head housing of the magnetic stripe reader, the processor may communicate one, two, and/or three tracks of magnetic stripe data to a read-head of the detected magnetic stripe reader via dynamic magnetic stripe communications device 1614. [0959] Alternately, for example, a user may press button 1604 to prepare card 1600 for communication with an RFID device. Accordingly, for example, a processor of card 1600 may initiate a mode of operation upon activation of option 1606, whereby a processor of card 1600 provides magnetic stripe information (e.g., one, two, and/or three tracks of magnetic stripe data) to an RFID chip of card 1600. Once option 1606 is activated, a user may bring card 1600 within a communication distance of an RFID reader (e.g., the user may wave card 1600 within an RFID communication distance of an RFID reader) and an RFID communication sequence between card 1600 and an RFID reader may be completed where RFID data may be provided to RFID antenna 1612 from an RFID chip on card 1600 and communicated from RFID antenna 1612 to the RFID reader.

[0960] Upon activation of option 1606, a processor of card 1600 may activate passive RFID communications or active RFID communications using RFID antenna 1612 and an associated RFID chip. Passive RFID communications, for example, may require little or no energy to be expended by card 1600. Instead, RFID antenna 1612 may collect energy from an RFID reader when a user of card 1600 brings card 1600 within a communication distance of the RFID reader. The energy collected by RFID antenna 1612 may, for example, provide power to an RFID chip of card 1600. In so doing, for example, an RFID chip of card 1600 may communicate with a processor of card 1600, so that the processor may populate a memory of the RFID chip with information (e.g., payment information) that may be needed to complete a transaction (e.g., a purchase transaction). Once populated with information, the RFID chip of card 1600 may communicate the information to RFID antenna 1612, which may then communicate the information to the RFID reader.

[0961] Active RFID communications from card 1600 may, for example, utilize battery power from within card 1600. Accordingly, for example, once card 1600 is brought within a communication distance of an RFID reader, RFID antenna 1612 may detect the RFID reader and may wake an RFID chip from a low-power state. In so doing, for example, an RFID antenna 1612 may detect energy from an RFID reader and an RFID chip of card 1600 may utilize battery power of card 1600 to receive information from a processor of card 1600 and to provide the received information to RFID antenna 1612 for subsequent communication to an RFID reader.

[0962] Card 1600 may, for example, operate as an RFID reader, such that when brought within a communication distance of another RFID device, an RFID chip of card 1600 may interrogate the RFID device to determine whether the RFID device is to receive information from card 1600 (e.g., the RFID device is operating as an RFID reader) or whether the RFID device is to communicate information to card 1600 (e.g., the RFID device is operating as an RFID tag). Accordingly, for example, an RFID chip of card 1600 may interrogate the RFID device to determine that the RFID device is an RFID tag an that RFID data may be communicated from the RFID device to an RFID chip of card 1600. In so doing, for example, an RFID chip of card 1600 may receive information, such as executable machine code, payment information, or any other type of information that may be required by card 1600 to operate as intended and may forward such information to a processor of card 1600 to be stored within a memory of card 1600. As per one example, an RFID chip of card 1600 may receive personalization information (e.g., cardholder information and cardholder account information) to prepare card 1600 for use as a payment card.

[0963] FIG. 65 shows system 1700, which may include card 1702 and one or more RFID devices (e.g., mobile devices 1704 and 1706). Card 1702 may, for example, communicate with multiple RFID devices simultaneously. A user of card 1702 may, for example, enable RFID communications with card 1702 by pressing one of buttons 1712 or 1714. Accordingly, for example, payment information (e.g., payment account number and cardholder name) may be communicated from a core processor within card 1702 and stored within one or more RFID chips of card 1702. Data indicative of which button was pushed (e.g., discretionary data indicative of either credit button 1712 or debit button 1714) may also be communicated and stored within the one or more RFID chips of card 1702.

[0964] As per one example, card 1702 may provide two RFID communication devices that may detect an RF carrier field that may be generated by each of mobile devices 1704 and 1706. Users of mobile devices 1704 and 1706 may, for example, be husband and wife who may wish to store payment information associated with card 1702 on respective memory locations of mobile devices 1704 and 1704 so that such payment information may be used to complete purchase transactions using mobile devices 1704 and 1706.

[0965] A first RFID communication device of card 1702 may establish RFID communication channel 1710 with an RFID reader of mobile device 1704 and a second RFID communication device of card 1702 may establish communication channel 1708 with an RFID reader of mobile device 1706. Accordingly, for example, the first and second RFID communication devices of card 1702 may communicate payment information temporarily stored within an RFID chip of each respective RFID communication device of card 1702. In so doing, for example, mobile devices 1704 and 1706 may store payment information communicated via RFID communication channels 1710 and 1708, respectively, within respective memory locations of mobile devices 1704 and 1706. Mobile devices 1704 and 1706 may later recall such payment information from their respective memory locations, communicate the stored payment information via channels 1716 and 1718, respectively, of payment network 1720, and complete payment transactions with network entity 1722 using payment information received from card 1702.

[0966] FIG. 66 shows system 1800, which may include mobile device 1802, a stationary device (e.g., desktop computer 1804), payment network 1806, and network entity 1808. An application (e.g., RFID operations GUI 1812) may be executed by a processor of mobile device 1802 and may, for example, report a detection of an RFID device to a display of mobile device 1802. Such an RF device may, for example, include any device (e.g., desktop computer 1804) that may be RFID equipped. An RFID antenna and associated RFID chip may, for example, exist within desktop computer 1804 such that when mobile device 1802 is brought within an RFID communication distance of desktop computer 1804, an RFID antenna of mobile device 1802 may detect its presence, report the same to an RFID chip within mobile device 1802, which may then be reported to a processor of mobile device 1802 and reported to a user of mobile device 1802 via GUI 1812.

[0967] GUI 1812 may, for example, ask the user of mobile device 1802 whether he or she wishes to allow an RFID connection between mobile device 1802 and desktop computer 1804. The user may indicate his or her wish via radio buttons 1814 and may also indicate whether information (e.g., payment information) stored within a memory of mobile device 1802 is to be communicated to desktop computer 1804 via an RFID communication channel previously authorized by the user of mobile device 1802 (e.g., by selecting one of radio buttons 1816). If so, then such information may be communicated to desktop computer 1804 by mobile device 1802 and stored within a memory of desktop computer 1804. In so doing, for example, payment information communicated by mobile device 1802 to desktop computer 1804 may subsequently be communicated by desktop computer 1804 via communication channel 1810 of payment network 1806 to complete a purchase transaction (e.g., an online purchase of items contained within a shopping cart generated by an internet browser of desktop computer 1804) via network entity 1808.

[0968] A flow diagram of communication sequences is shown in FIG. 67. Step 1911 of sequence 1910 may, for example, include activating an RFID search within a card. Accordingly, for example, a user interface (e.g., one or more buttons) of a card may be associated with a communication feature on the card, whereby pressing one of the buttons may activate an RFID communication device on the card. In step 1912, an RFID device may be detected by the card and an RFID connection may be established between the card and the RFID device. RFID data may, for example, be transferred to an RFID chip on the card (e.g., as in step 1913) and the RFID data contained within an RFID chip on the card may, for example, be communicated via an RFID antenna on the card to the RFID device (e.g., as in step 1914). Once RFID data is communicated, RFID data contained within an RFID chip on the card may be erased so as to reduce a likelihood of skimming RFID data from the RFID chip on the card. [0969] Step 1921 of sequence 1920 may, for example, include activating an RFID search within a mobile device. Accordingly, for example, a user interface (e.g., a GUI executing on a processor of the mobile device) may be associated with a communication feature on the mobile device, whereby interfacing with the GUI may activate an RFID communication channel between a detected RFID device and the mobile device (e.g., as in step 1922). In step 1923, RFID data may, for example, be transferred to an RFID chip on the mobile device and the RFID data contained within an RFID chip on the mobile device may, for example, be communicated via an RFID antenna on the mobile device to the RFID device (e.g., as in step 1924). Once RFID data is communicated, RFID data contained within an RFID chip on the mobile device may be erased so as to reduce a likelihood of skimming RFID data from the RFID chip on the mobile device.

[0970] Step 1931 of sequence 1930 may, for example, include transferring RFID data from a core processor to an RFID chip on a card or a mobile device in preparation for communicating the RFID data via an RFID antenna on the card or the mobile device. If a timeout period that may be set in step 1932 expires before the RFID data is communicated by the card or mobile device (e.g., as in step 1933), then RFID data previously transferred to the RFID chip may be erased from the RFID chip by the core processor.

[0971] Step 1941 of sequence 1940 may, for example, include transferring RFID data from a core processor to an RFID chip on a card or a mobile device in preparation for communicating the RFID data via two RFID antennas on the card or the mobile device. In step 1942, the same data may be transferred to both RFID antennas. Alternately, for example, different data may be transferred each RFID antenna. In step 1943, both RFID antennas may communicate data to an RFID reader. As per one example, the same data may be communicated by both RFID antennas so as to increase a reliability of data communication. As per another example, different data may be communicated by each RFID antenna in order to increase an efficiency of data communication. As per yet another example, different data may be communicated by each RFID antenna, where differences (e.g., phase, frequency, and/or amplitude) may be used to communicate multiple other data channels.

[0972] FIG. 68 is an illustration of a card and associated circuit diagram. Referring to FIG. 68, a card or other device may include a battery according to some example embodiments. According to some example embodiments, no battery may be included.

[0973] For example, card 2000 may include housing structure 2021, two or more secure elements (e.g., secure processors, not shown), contacts 2005 (e.g., surface contacts), a slider 2010, and a magnetic stripe without an emulator or encoder (not shown), and may not include a battery. Each of the secure elements may be powered by terminal via contacts 2005 on the surface of card 2000. Each secure element may store different account information for different accounts (e.g., different payment accounts) and may store different Applets and associated account information.

[0974] According to some example embodiments, slider 2010 may be, or may be connected to, a switch that may connect and disconnect one or more of contacts 2005 (e.g., one or more of 5 active EMV contacts) to each of the two or more secure elements. At each position of the slider one of the secure elements may be connected to complete a transaction (e.g., an EMV contact transaction).

[0975] For example, in example embodiments including two secure elements and five active EMV Contacts, slider 2010 may be moved between two positions. One or more of a power contact, ground contact, clock contact, I/O contact, and reset contact may be connected or disconnected with respect to the two secure elements so that one of the secure elements may be used in a transaction. According to some example embodiments, a slider may connect an antenna (not shown) to one of the secure elements to complete a transaction (e.g., an EMV contactless transaction). According to some example embodiments, both contact and contactless transactions may be selected by account using one or more sliders (e.g., one or more switches).

[0976] Slider 2010 may have any number of selectable positions such as, for example, selectable position 2015 may be included and may be, for example, associated with a credit account (or other account/option). Selectable position 2020 may be, for example, associated with a debit account (or other account/option). The card may include a printed account number and/or option associated with each selectable position as well as a similar label next to each account number and/or payment option. FIG. 20 includes circuit 2050.

[0977] FIG. 69 is an illustration of a card and associated block diagram. Referring to FIG. 69, a card or other device may include a battery according to some example embodiments. According to some example embodiments, no battery may be included.

[0978] For example, card 2100 may include one or more secure elements (not shown) and at least one central or more general purpose processor(s) (e.g., processor 2102), external communication contacts 2105 (e.g., surface contacts to electronically couple with a payment card reader such as an EMV reader), one or more manual inputs 2101 (e.g., mechanical buttons, mechanical slider switches, or other manual interfaces such as non- mechanical manual input interfaces such as capacitive touch sensors/screens) , a magnetic stripe without an emulator or encoder (not shown), and card 2100 may not include a battery (e.g., may be powered from a payment card terminal).

[0979] According to some example embodiments including a single secure element and single general purpose processor or central processor, used for clarity of explanation, the secure element and processor may be powered by terminals. The processor may be connected to contacts 2105 (e.g., EMV contacts) and the secure element. The secure element may be powered by a terminal via contacts 2105 on the surface of card 2100. A slider may indicate which of two or more accounts account is selected by a user for a transaction.

[0980] As one example, card 2100 may be inserted into an EMV terminal. The processer and secure element may be powered by the terminal via contacts 2105. The processor may determine the position of a slider and if a slider is in a different position from that of a preceding transaction (e.g., immediately preceding transaction). If a slider is in the same position as in the last transaction, the transaction may complete. If a slider is in a different position from that of the preceding transaction, the processor may send a set of commands to the secure element after an answer to reset (ATR) is issued to inform the secure element that the active account has changed. The issuing of the commands may be completed prior to the general purpose processor releasing a SELECT command that the terminal issued. According to at least some example embodiments, the account change may be seamless to the terminal.

[0981] According to some example embodiments, slider 2100 may connect an antenna (not shown) to the secure element to complete the transaction (e.g., an EMV contactless transaction). According to some example embodiments, both contact and contactless transactions may be selected using a slider.

[0982] Secure element 2104 may be included and may provide, for example, EMV contact and EMV contactless payment applets. Secure element 2104 may be a secure chip with secure storage and security features so that firmware and data may not be removed from the secure element without breaking the secure element and/or defeating security protocals. A secure element 2104 may include a firmware (e.g., an operating system) from the chip manufacturer) and may include firmware from a third party (e.g., one or more payment network-specific payment applets so that contact and contactless transactions may be provided on that payment network). For example, secure element 2104 may include a Visa contact and contactless applet from the card manufacturer and/or a Mastercard contact and contactless applet. Different payment card accounts (e.g., debit and credit) may be provided by different payment networks and different manual input may cause a different payment networks applet to be run. For example, a card may include an international credit account from one payment network but may include a domestic debit account from a different payment network. General processor 2102 may be utilized, for example, to receive control signals from manual input interfaces and provide information associated with those control signals to a secure element. General processor 2102 may also manage information being received externally from and sent to, for example, payment card terminal interfaces 2015 (e.g., contact interfaces 2015). Accordingly, for example, general processor 2101 may create a secure data pipe between a secure element and a payment card reader (e.g., for contact and/or contactless payment transactions). Buffer chip 2103 may include, for example, electrical components to provide electronic signals between a processor (or other components of a card and a payment card reader. Buffer 2103 may also provide power from power provided by a payment card terminal to power components of card 2100 (e.g., power processor 2102 and/or charge a battery of card 2100) [0983] Card 2150 may be provided that may include housing structure 2151, contacts 2152, slider switch 2153 with switch position 2155 (e.g., credit) and switch position 2154 (e.g., equated monthly installmentsO. Card number 2158 may be associated to one or both features of slider switch 2153. For example, switch position 2155 may be associated with credit and switch position 2154 may be associated with equated monthly installments over via a credit authorization (e.g., card number 2158 is utilized to authorized the transaction and a flag noting switch location 2154 was utilized is communicated with the payment transaction data in, for example, an issure or network discretionary field, that field is utilized post-authorization to start a post-authorization equated monthly installment process). An online security code associated with the credit feature may be provided such as provided with indicia 2156 and an online security code for online purchases with the installment feature may be provided such as provided with indicia 2157. Accordingly, for example, card not present purchases may be provided a card number (e.g., card number 2158) and online security code. Multiple online security codes may authorize the card number (e.g., 2156 and 2157) and then the online security code may also be utilized to initiate a post-authorization process (e.g., a post-authorized equated monthly installment process). Options may include equated monthly installments of any longevity (e.g., 6 months, 12 months, 18 months) and may be fixed for a card, changed on a different device (e.g., over the phone or on an interface of another device), or changed on the card itself (e.g., via one or more manual interfaces, such as slider switches, that have additional location positions). For example, a slider switch may have six location switches, one for credit, one for pay with points, and four for four different equated monthly transaction durations (e.g., 6 month, 12 month, 18 month, and 24 month). Visual indicators (e.g., light sources or bi-stable displays) may be turned ON when, for example, a card is in a reader that provides power to the card to power the visual indicators. A battery may also be provided, for example, to provide power to one or more visual indicators. Visual indicators may be associated with a selected feature and may provide visual indication of the selected feature

[0984] FIG. 70 is an illustration of a card and associated circuit board. Referring to FIG. 70, card 2200 may include structure 2201, circuit board 2250, battery 2255 and a magnetic stripe 2260 without an emulator or encoder, and may be a multi-account contact and contactless card (e.g., EMV contact and contactless) including contacts 2205 and an antenna (not shown).

[0985] For example, card 2000 may include one or more secure elements (not shown), contacts 2205 (e.g., surface contacts), buttons 2210 and/or a central or general purpose processor (not shown). A secure element may be powered by a terminal via contacts 2205 (e.g., on the surface of card 2200).

[0986] A length and/or width of circuit board 2250 may be less than a length and/or width of card 2200, for example, a surface area of circuit board 2250 may be less than three fourths (3/4) of a surface area of card 2200, for example less than one half (1/2) a surface area of card 2200 (e.g., between one fourth (1/4) and one third (1/3) a surface area of card 2200). A length and/or width of battery 2255 may be less than a length and/or width of circuit board 2250, for example, a surface area of battery 2255 may be less than three fourths (3/4) of a surface area of circuit board 2250, for example less than one half (1/2) a surface area of circuit board 2250 (e.g., between one fourth (1/4) and one third (1/3) a surface area of circuit board 2250).

[0987] As used herein, a secure element may or may not be a processor, and use of the term "processor" in enumerations including the term "secure element" does not denote a secure element that is not a processor.

[0988] Card 2280 may be provided and may include structure 2281, contacts 2282, manual interface and visual indicator area 2284 and manual interface and printed indicia area 2283. Area 2284 may provide six options for a cardholder to select from and may include a credit button, pay with rewards button, and an equated monthly installment button that toggles between four equated monthly installment visual indicators (6 month, 12 month, 18 month, and 24 month). Accordingly, for example, one button press of the equated monthly installment may select a 6 month installment, two button presses of the equated monthly installment button may select a 12 month installment, three button presses of the equated monthly installment button may select a 18 month installment, four button presses of the equated monthly installment button may select a 24 month installment, and five button presses of the equated monthly installment may turn the card OFF (e.g., with or without a delay). Pressing the credit button or reward button a second time may turn the card OFF (with or without a delay). Visual indicators (e.g., LEDs) may also be associated with the rewards button and credit button. The rewards and credit button may actually be for other features (e.g., a debit account, pre-paid account, gift account, attach coupon, enter into a change of chance instead of earning rewards, etc.). Area 2284 may provide, for example, six functionalities (e.g., credit, pay with reward, and four equated monthly installment options). A card may have, for example, either area 2283, 2284, or a combination of area 2283 and 2284.

[0989] Multiple secure elements may be provided on a card and different manual selections (e.g., via a slider switch) may be associated with different secure elements. As a result, for example, a set of circuitry (e.g., chips and/or secure elements) may be associated with different manual inputs (e.g., slider switch positions) so that different circuitry is powered when a reader powers a card (e.g., via contact coupling to a payment card reader that includes a signal that may be utilized for power or a contactless coupling to a payment card reader that provides a signal that may be utilized for power). One or more general processors may be utilized for management. As per another example, no general processor may be utilized and, for example, switch locations may directly couple to different secure elements (e.g., and different payment applets associated with different payment accounts and/or options and/or features).

[0990] FIG. 71 shows card 100 that may include, for example, a dynamic number that may be entirely, or partially, displayed using a display (e.g., display 106). A dynamic number may include a permanent portion such as, for example, permanent portion 104 and a dynamic portion such as, for example, dynamic portion 106. Card 100 may include a dynamic number having permanent portion 104 and permanent portion 104 may be incorporated on card 100 so as to be visible to an observer of card 100. For example, labeling techniques, such as printing, embossing, laser etching, etc., may be utilized to visibly implement permanent portion 104.

[0991] Card 100 may include a second dynamic number that may be entirely, or partially, displayed via a second display (e.g., display 108). Display 108 may be utilized, for example, to display a dynamic code such as a dynamic security code. Card 100 may include third display 122 that may be used to display graphical information, such as logos and barcodes. Third display 122 may be utilized to display multiple rows and/or columns of textual and/or graphical information.

[0992] Persons skilled in the art will appreciate that any one or more of displays 106, 108, and/or 122 may be implemented as a bi-stable display. For example, information provided on displays 106, 108, and/or 122 may be stable in at least two different states (e.g., a powered-on state and a powered-off state). Any one or more of displays 106, 108, and/or 122 may be implemented as a non-bi-stable display. For example, the display is stable in response to operational power that is applied to the non-bi-stable display. Other display types, such as LCD or electro- chromic, may be provided as well.

[0993] Other permanent information, such as permanent information 120, may be included within card 100, which may include user specific information, such as the cardholder's name or username. Permanent information 120 may, for example, include information that is specific to card 100 (e.g., a card issue date, a card expiration date, a network logo and/or indicia associated with an issuer of card 100). Information 120 may represent, for example, information that includes information that is both specific to the cardholder, as well as information that is specific to card 100. Light sources (not shown) may be provided proximate to permanent information 120 and may be activated and deactivated to highlight at least a portion of permanent information 120.

[0994] Card 100 may accept user input data via any one or more data input devices, such as buttons 110- 118. Buttons 110-118 may be included to accept data entry through mechanical distortion, contact, or proximity. Buttons 110-118 may be responsive to, for example, induced changes and/or deviations in light intensity, pressure magnitude, or electric and/or magnetic field strength. Such information exchange may then be determined and processed by a processor of card 100 as data input.

[0995] Detectors 124 may be implemented to detect, for example, the proximity, or actual contact, of an object (e.g., a read-head housing of a magnetic stripe reader, an EMV reader or a bar code reader). Proximity detectors 124 may be utilized, for example, to detect a magnetic stripe reader during a transaction (e.g., a card-based financial transaction) when card 100 is swiped through a read-head housing of the magnetic stripe reader. During such a transaction, dynamic magnetic stripe communications device 102 may be activated in response to such a detection to provide one or more tracks of magnetic stripe data to the detected magnetic stripe reader. Alternately, a static magnetic stripe (not shown) and/or a dynamic magnetic stripe communications device may be used to provide one or more tracks of magnetic stripe data to the detected magnetic stripe reader. In other alternatives, an EMV chip, an RFID device and/or an electromagnetic device may be used to exchange transaction data with the detected EMV reader, RFID reader and/or magnetic stripe reader, respectively.

[0996] Once a point-of-sale terminal is detected, one or more visible indicators (e.g., LEDs) and/or an audible indicator (e.g., a speaker) and/or a tactile indicator (e.g., a vibrator) on a card may be activated in accordance with a transaction indicator algorithm to provide visible and/or audible and/or tactile feedback as to the occurrence of a transaction completed by card 100 and the associated point-of-sale terminal. Alternately, some other usage of card 100 (e.g., replenishment of credit onto a reloadable gift card) may also be indicated by activation of a transaction indicator algorithm.

[0997] Card 100 may be implemented using architecture 150, which may include one or more processors 154. One or more processors 154 may be configured to utilize external memory 152, internal memory of processor 154, or a combination of external memory 152 and internal memory for storing information, such as executable machine language, related dynamic machine data, transaction indicator algorithms and user input data values.

[0998] One or more of the components shown in architecture 150 may be configured to transmit information to processor 154 and/or may be configured to receive information as transmitted by processor 154. For example, one or more displays 156 may be coupled to receive data from processor 154. The data received from processor 154 may include, for example, at least a portion of dynamic numbers and/or dynamic codes. The data to be displayed on the display may be displayed on one or more displays 156.

[0999] One or more displays 156 may be, for example, touch sensitive and/or proximity sensitive. For example, objects such as fingers, pointing devices, etc., may be brought into contact with displays 156, or in proximity to displays 156. Detection of object proximity or object contact with displays 156 may be effective to perform any type of function (e.g., transmit data to processor 154). Displays 156 may have multiple locations that are able to be determined as being touched, or determined as being in proximity to an object.

[1000] Input and/or output devices may be implemented on architecture 150. For example, integrated circuit (IC) chip 160 (e.g., an EMV chip) may be included on architecture 150, that can exchange information with a chip reader (e.g., an EMV chip reader). Radio frequency identification (RFID) module 162 may be included within architecture 150 to enable the exchange of information with an RFID reader.

[1001] Other input and/or output devices 168 may be included on architecture 150, for example, to provide any number of input and/or output capabilities. For example, other input and/or output devices 168 may include an audio device capable of receiving and/or transmitting audible information.

[1002] Other input and/or output devices 168 may include a device that exchanges analog and/or digital data using a visible data carrier. Other input and/or output devices 168 may include a device, for example, that is sensitive to a non-visible data carrier, such as an infrared data carrier or electromagnetic data carrier. Other input and/or output devices 168 may include a device, for example, that is sensitive to laser light, such as light generated by a barcode scanner.

[1003] Persons skilled in the art will appreciate that a card (e.g., card 100 of FIG. 71) may, for example, be a self-contained device that derives its own operational power from one or more batteries 158. Furthermore, one or more batteries 158 may be included, for example, to provide operational power for a period of time (e.g., approximately 2-4 years). One or more batteries 158 may be included, for example, as rechargeable batteries.

[1004] Electromagnetic field generators 170-174 may be included on architecture 150 to communicate information to, for example, a read-head of a magnetic stripe reader via, for example, electromagnetic signals. For example, electromagnetic field generators 170-174 may be included to communicate one or more tracks of electromagnetic data to read-heads of a magnetic stripe reader. Electromagnetic field generators 170-174 may include, for example, a series of electromagnetic elements, where each electromagnetic element may be implemented as a coil wrapped around one or more materials (e.g., a magnetic material and/or a non-magnetic material). Additional materials may be placed outside the coil (e.g., a magnetic material and/or a non-magnetic material).

[1005] Electrical excitation by processor 154 of one or more coils of one or more electromagnetic elements via, for example, driving circuitry 164 may be effective to generate electromagnetic fields from one or more electromagnetic elements. One or more electromagnetic field generators 170-174 may be utilized to communicate electromagnetic information to, for example, one or more read-heads of a magnetic stripe reader. Alternately, a static magnetic stripe (not shown) may be used by itself, or in combination with electromagnetic field generators 170-174, to communicate information to a magnetic stripe reader.

[1006] Timing aspects of information exchange between the various I/O devices implemented on architecture 150 may be determined by processor 154. One or more proximity detectors 166 may be utilized, for example, to sense the proximity, mechanical distortion, or actual contact, of an external device, which in turn, may trigger the initiation of a communication sequence by processor 154. The sensed presence, mechanical distortion, or touch of the external device may be effective to, for example, determine the type of device or object detected.

[1007] For example, the detection may include the detection of, for example, a point-of-sale terminal (e.g., a magnetic stripe reader, an EMV reader, an RFID reader, and a barcode scanner). In response, processor 154 may activate one or more communication devices to initiate a communications sequence with, for example, one or more point-of-sale terminals.

[1008] A transaction indicator algorithm may be executed by processor 154, for example, to cause the activation of a transaction indicator (e.g., light sources 176) when a point-of-sale terminal is detected. For example, after a card (e.g., card 100 of FIG. 71) is detected as having been swiped through a magnetic stripe reader, light sources 176, or other indicia such as audible or tactile indicia, may be activated by processor 154 in such a manner as to alert the card holder and others around the card holder that the card has just been used in a transaction. Alternately, for example, other I/O 168 may detect light emitted from a barcode scanner, which would then cause processor 154 to activate light sources 176, or other indicia such as audible or tactile indicia, in such a manner as to alert the card holder and others around the card holder that the card has just been used in a transaction.

Still other transactions (e.g., transactions between IC chip 160 and an EMV reader or transactions between RFID 162 and an RFID reader) may cause processor 154 to activate light sources 176, or other indicia such as audible or tactile indicia, in such a manner as to alert the card holder and others around the card holder that the card has just been used in a transaction.

[1009] Turning to FIG. 72, a card is shown having an orientation of detectors 226, whereby one or more detectors 202-216 may be, for example, arranged along a length of card 200. Detectors 202-216 may be provided, for example, as conductive pads using, for example, an additive technique, whereby patterns of a conductive element (e.g., copper) may be applied to a PCB substrate according to a patterning mask definition layer. Detectors 202-216 may be provided, for example, as conductive pads using, for example, a subtractive technique whereby patterns of a conductive element (e.g., copper) may be removed from a pre-plated PCB substrate according to an etching mask definition layer. Other non-PCB fabrication techniques may be used to implement conductive pads 202-216 as may be required by a particular application.

[1010] Detection circuitry 220 of processor 218, conductive pads 202-216, processor 218, transaction indicator algorithm 230 and transaction indicator device 232 may be combined to provide a detection system. Persons skilled in the art will appreciate that any number of conductive pads may be utilized by a processor as capacitive sensing pads. Particularly, a processor may include the functionality to control a detection system to determine when an object is in the proximity of one or more conductive pads via a capacitive sensing technique. [1011] FIG. 73 shows detection circuitry 300. A conductive pad may be utilized, for example, as a conductor of a capacitive device within a resistor/capacitor (RC) circuit to determine the capacitance of a conductive pad and determine whether the capacitance is below, equal to, or above one or more predetermined thresholds.

[1012] A conductive pad may, for example, form a portion of a capacitive element, such that plate 316 of capacitive element 314 may be implemented by a conductive pad and the second plate of capacitive element 314 may be implemented by element 310. Element 310 may represent, for example, the device or object whose proximity or contact is sought to be detected.

[1013] The capacitance magnitude of capacitive element 314 may exhibit, for example, an inversely proportional relationship to the distance separation between plate 316 and device 310. For example, the capacitance magnitude of capacitive element 314 may be relatively low when the corresponding distance between plate 316 and device 310 may be relatively large. The capacitance magnitude of capacitive element 314 may be relatively large, for example, when the corresponding distance between plate 316 and device 310 is relatively small.

[1014] Detection may be accomplished, for example, via circuit 300 of FIG. 3. Through a sequence of charging and/or discharging events, a capacitance magnitude change for capacitive element 314 may be monitored over a given period of time. In so doing, for example, the spatial relationship (e.g., the separation distance) between plate 316 and device 310 may be approximated. [1015] Charge sequence 350 may, for example, be optionally invoked, such that charge circuit 304 may be activated at time Tl, while discharge circuit 306 may remain deactivated. Accordingly, for example, current may flow through resistive component 308. In doing so, for example, an electrostatic field may be generated that may be associated with capacitive component 314. During the charge sequence, for example, the voltage at node 312 may be monitored to determine the amount of time required (e.g., T_CHARGE = Δ1-T1) for the voltage at node 312, V₃₁₂, to obtain a magnitude that is substantially equal to, below, or above a first threshold voltage (e.g., equal to VI).

[1016] Discharge sequence 360 may, for example, be optionally invoked, such that discharge circuit 306 may be activated at time T2, while charge circuit 304 may remain deactivated. During the discharge sequence, for example, the electric field associated with capacitive element 314 may be allowed to discharge through resistive component 308 to a reference potential (e.g., ground potential). The voltage at node 312 may be monitored to determine the amount of time required (e.g., T_DISCHARGE = Δ2-T2) for the voltage at node 312, V₃₁₂, to obtain a magnitude that is substantially equal to, below, or above a second threshold voltage (e.g., equal to V2).

[1017] Once the charge time, T_CHARGE, and/or discharge time, T_DISCHARGE, are determined, the charge and/or discharge times may be utilized to calculate a capacitance magnitude that may be exhibited by capacitive element 314. For example, given that the magnitude of voltage, VI, may be equal to approximately 63% of the magnitude of voltage, V_s, then a first relationship may be defined by equation (1) as:

T_CHARGE = R₃₀₈*C1, (1) where R₃₀₈ is the resistance magnitude of resistive element 308 and Cl is proportional to a capacitance magnitude of a capacitive element (e.g., capacitive element 314). [1018] Similarly, for example, given that the magnitude of voltage, V2, is equal to approximately 37% of the magnitude of voltage, V_s, then a second relationship may be determined by equation (2) as: T_DISCHARGE = R₃₀₈*C2, (2) where C2 is proportional to a capacitance magnitude of capacitive element 314. The capacitance magnitudes, C₁ or C₂, may then be calculated from equations (1) or (2), respectively, and taken by themselves to determine a capacitance magnitude that may be exhibited by capacitive element 314. Alternatively, for example, capacitance magnitudes, C₁ and C₂, may be calculated from equations (1) and (2), respectively, and averaged to determine a capacitance magnitude that may be exhibited by capacitive element 314. [1019] Persons skilled in the art will appreciate that circuits 304 and/or 306 may be activated and deactivated by controller 320. Accordingly, for example, controller 320 may control when the charge and/or discharge events occur. Persons skilled in the art will further appreciate that controller 320 may adjust a frequency at which circuits 304 and 306 may be activated and/or deactivated, thereby adjusting a sampling rate at which the capacitance magnitudes, C₁ and/or C₂, may be measured. [1020] Turning back to FIG. 2, a series of charge and/or discharge cycles for pads 202-216 may be executed by processor 218 to determine, for example, a relative capacitance magnitude that may be exhibited by each of pads 202-216. A series of charge and/or discharge cycles for each of pads 202-216 may be executed by processor 218, for example, in order to obtain a capacitance characteristic for each of pads 202-216 over time, thereby determining whether an object (e.g., a read-head housing of a magnetic stripe reader) is within a proximity to card 200, whether that object is moving with respect to card 200 and if so, what direction that object is moving and/or whether that object is accelerating with respect to card 200.

[1021] By comparing the time-based capacitance characteristic of each pad 202-216 to a threshold capacitance value, a determination may be made, for example, as to when pads 202-216 are in a proximity, or touch, relationship with a device whose presence is to be detected. For example, a sequential change (e.g., increase) in the relative capacitance magnitudes of pads 202-208, respectively, and/or pads 216-210, respectively, may be detected and a determination may be made that a device is moving substantially in direction 222 relative to card 200. A sequential change (e.g., increase) in the relative capacitance magnitudes of detectors 210-216, respectively, and/or 208-202, respectively, may be detected, for example, and a determination may be made that a device is moving substantially in direction 224 relative to card 200.

[1022] Persons skilled in the art will appreciate that by electrically shorting pairs of detectors together (e.g., pair 202/210, pair 204/212, pair 206/214, etc.) directional vectors 222 and 224 become insubstantial. For example, regardless of whether a device is moving substantially in direction 222 or substantially in direction 224 relative to card 200, a determination may nevertheless be made that a device is close to, or touching, card 200.

[1023] Detection circuitry 220 of processor 218 may be used in conjunction with, for example, one or more pads 202-216 to determine that a device (e.g., a read- head housing of a magnetic stripe reader) is in close proximity, or touching, one or more of pads 202-216. Processor 218 may, for example, conclude that card 200 has been used in a transaction based on the detection and may execute transaction indicator algorithm 230 to determine the manner in which transaction indicator device 232 is to be activated based on the detected transaction (e.g., activation of one or more light sources, playing of a tune via an audible device, or vibration of card 200 via a tactile device).

[1024] FIG. 74 shows card 400 having front side 410 and back side 412. Card 400 may, for example, include a processor (not shown), a battery (not shown), a proximity detector (not shown) and memory to store a transaction indication algorithm to be executed by the processor. Front side 410 of card 400 may further include indicia 404 that may be indicative of a merchant who may honor card 400 at its point-of-sale terminal, indicia 406 that may be indicative of a payment network associated with card 400, indicia 408 that may be indicative of a payment account number (e.g., a gift card account number) that may be associated with a cash balance of card 400 with which to charge purchases against and design indicia 418 that may be printed or laser etched onto card 400.

[1025] Card 400 may, for example, be swiped through a magnetic stripe reader located at a point-of-sale terminal associated with merchant 404 and such a swipe may be detected by proximity detectors (not shown) of card 400. Based on the detection of the magnetic stripe reader and based on a transaction indication algorithm executed by the processor (not shown) of card 400, a visible indication of the transaction may be displayed by card 400. For example, one or more LEDs 402 may be illuminated based on the detection, such that LEDs may be illuminated to emit a constant intensity of light, varying intensities of light, a constant duration of light, a varying duration of light, a constant color of light, varying colors of light or any other form of light that may indicate that card 400 has been swiped through a magnetic stripe reader such that the user of card 400 and others around the user of card 400 may notice that card 400 is visibly illuminated.

[1026] Alternately, barcode 416 may be scanned during a transaction. Accordingly, for example, optical sensors 414 may detect light (e.g., laser light) from a barcode scanner that may be scanning barcode 416 and may report the detection to a processor (not shown) of card 400. Based on the detection of the barcode scanner and based on a transaction indication algorithm executed by the processor (not shown) of card 400, a visible indication (e.g., the illumination of LEDs 402) of the transaction may be displayed by card 400. [1027] Persons skilled in the art will appreciate that any type of indication of a transaction may be provided by card 400. For example, in addition to or instead of visible indicators, card 400 may emit sounds via a speaker (not shown) of card 400. As per another example, in addition to or instead of visible indicators, card 400 may emit vibrations via a vibrating device (not shown) of card 400.

[1028] FIG. 75 shows card 500. Card 500 may, for example, include a processor (not shown), a battery (not shown), a proximity detector (not shown), an input and/or output device that may exchange information with a point-of-sale terminal, and memory to store a transaction indication algorithm to be executed by the processor. Front side 510 of card 500 may further include design indicia 506 that may be printed or laser etched onto card 500. Devices (e.g., LEDs 502) may be positioned along design indicia 506 such that LEDs 502 may not be visible unless LEDs 502 are illuminated.

[1029] Card 500 may, for example, be presented to a point-of-sale terminal (e.g., a magnetic stripe reader, an EMV reader or an RFID reader) associated with a merchant and such presentment may be detected by proximity detectors (not shown) of card 500. Based on the detection of the point-of-sale terminal and based on a transaction indication algorithm executed by the processor of card 500, a visible indication of the transaction may be displayed by card 500. For example, one or more LEDs 502 may be illuminated based on the detection.

[1030] Further, card 500 may exchange information with the point-of-sale terminal via a contact-based transfer mechanism, such as an EMV contact mechanism. Alternately, card 500 may exchange information with the point-of-sale terminal via a contactless transfer mechanism, such as an RFID transfer mechanism or an electromagnetic transfer mechanism. Such information may, for example, be indicative of a balance that may be associated with card 500 after card 500 is used for a purchase transaction. Accordingly, for example, a processor (not shown) of card 500 may illuminate a number of LEDs that correspond to a balance of cash remaining on card 500 as may be reported to card 500 by the point-of-sale terminal. For example, four LEDs 502 may be illuminated on front side 510 of card 500 to indicate that approximately 80% of the cash value of card 500 remains after the transaction, such that each LED 502 that is illuminated may represent approximately 20% of the balance remaining on card 500. Alternately, for example, two LEDs 504 may be illuminated on front side 512 of card 500 to indicate that approximately 40% of the cash value of card 500 remains after the transaction.

[1031] FIG. 76 shows card 600. Card 600 may, for example, include a processor (not shown), a battery (not shown), a proximity detector (not shown), buttons (not shown) and memory to store an event indication algorithm to be executed by the processor. Card 600 may further include indicia 602 that may be indicative of an issuer of card 600 and indicia 604 that may be indicative of a payment network associated with card 600.

[1032] Pressing a button (not shown) of card 600 may, for example, be detected by a processor (not shown) of card 600. Based on the detection, the processor of card 600 may illuminate indicia (e.g., issuer indicia 602) in some manner. For example, only the first letter of issuer indicia 602 may be illuminated. As per another example, each letter of issuer indicia 602 may be separately illuminated in sequence upon detection of a button press. As per yet another example, each letter of issuer indicia 602 may be lit simultaneously, but the color and/or intensity of each letter may be different and/or may be varied. [1033] Card 600 may, for example, be swiped through a magnetic stripe reader located at a point-of-sale terminal and such a swipe may be detected by proximity detectors (not shown) of card 600. Based on the detection of the magnetic stripe reader and based on an event indication algorithm executed by the processor (not shown) of card 600, a visible indication of the transaction may be displayed by card 600. For example, one or more LEDs may be illuminated based on the detection, such that network logo 604 may appear to be glowing with a constant intensity of light, varying intensities of light, a constant duration of light, a varying duration of light, a constant color of light, varying colors of light or any other form of light that may indicate that card 600 has been swiped through a magnetic stripe reader such that the user of card 600 and others around the user of card 600 may notice that card 600 is visibly reacting to a transaction conducted with card 600.

[1034] A flow diagram of a detection activity is shown in FIG. 77. Step 711 of sequence 710 may initiate a detection operation, for example, where a property change (e.g., an increased capacitance) associated with a conductive pad is detected. A property change (e.g., a capacitance increase) may then be detected in a second conductive pad (e.g., as in step 712) to verify that a transaction may have occurred when a card (e.g., a payment card) is presented to a point-of-sale terminal (e.g., swiped through a magnetic stripe reader). In step 713, a processor of the card may execute a transaction indicator sequence, whereby the card reacts to the detected transaction by visibly, audibly and/or tactilely reacting to the transaction. For example, personalized features on the card may be caused to illuminate, or glow, based on a detected transaction. [1035] In step 721 of sequence 720, a property change (e.g., an increased capacitance) associated with a first pad of a set of pads may be detected. A property change (e.g., a capacitance increase) may then be detected in a second pad of the set of pads (e.g., as in step 722), such that a detection of a transaction completed with a card at a point-of-sale terminal may be verified. In step 723, a card may exchange transaction information with the point-of-sale terminal, such that the point-of-sale terminal may communicate transaction details to the card (e.g., the amount of the transaction and the balance left on the card after the transaction amount is deducted from the total amount previously available on the card). [1036] In step 724, a processor of the card may activate a transaction indicator sequence that not only may provide a visible, audible and/or a tactile reaction to the transaction, but that may also provide indicia that pertains to certain details of the transaction. For example, a number of LEDs on the card may be illuminated, where the number of LEDs illuminated may correspond to a balance left on a payment card after the payment card is used for a purchase transaction. As per another example, a number of letters associated with issuer indicia on the card may be caused to illuminate, or glow, where the number of letters illuminated may be indicative of a balance left on a payment card after the payment card is used for a purchase transaction. As per yet another example, an expiration date on the card may be caused to illuminate, or glow, if the expiration date is close (e.g., the card is within one month of expiration).

Another example may include providing visible indicia (e.g., causing a network logo on the card to glow) if the user of the card has just been awarded a gift (e.g., an instant cash award) by the merchant as may be reported to the card by the merchant's point-of-sale terminal.

[1037] Super Smart Secure Payment Applets With Pre- Stored Messages and Logic and Ability To Change Subsequent Function Thereon

[1038] A payment card or other device such as a powered card, payment phone and/or watch, can interact with a point-of-sale terminal to complete a transaction. Multiple stages of communications from the payment device to the payment terminal and from the payment terminal to the payment device can be provided so that each device or process can identify itself to each other, securely confirm the other identity is authorized to conduct a transaction, and provided information for the authorization of a payment transaction. The point-of-sale terminal may route such communications to/from a merchant processor which may route parts of the communication to/from a payment network process, which may route part of the communications to/from an issuing processor that issued the payment device to the end consumer. Issuer scripts may be used by the issuer and/or a remote server to update and change parameters and values on a secure element as part of a transaction communication.

[1039] The transaction may be a communication between the payment device and point-of-sale terminal, for example, a contact chip connection, a contact or wireless magnetic stripe connection, a contactless connection, or through a visible connection such as a single-stage or multiple-stage barcode or QR code. A multiple-stage barcode may be a barcode that changes the information displayed throughout a payment transaction process so that multiple different types of information are displayed at different times over the same display area.

[1040] During a transaction, a payment device may request information. This information may include, the amount authorized, additional monetary amounts, the country code of the terminal, the terminal verification results, the transaction currency code, the transaction data, the transaction type, the data authentication code, the iCC dynamic number, the CVM results, the transaction time, merchant custom data, transaction date, tvr, unpredictable number, whether the transaction was authorized or declined, or any type of data retrievable by the payment card.

[1041] A payment card may be battery-powered or non- battery powered and may include buttons to permit a consumer to select different payment accounts (e.g., debit, credit, pre-paid), payment options (e.g., pay with points, pay with equal monthly payments such as 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 36, 39, 42, 45, or 48 monthly payments, or other payment features (e.g., a password-entry system where a correct password is needed to use the card to complete a purchase).

[1042] The payment devices may include multiple processors - such as a general processor for managing the general operation of the device and a payments processor or secure memory element for managing all or part of the payment data and payment process of the device.

[1043] Data not associated with the direct authorization of a payment may be copied from information requested from the payment device and stored and utilized for non-payment or payment features.

[1044] For example, a card may include a display, for example, as a pixelated display operable of displaying a cardholders payment network logo, cardholder name, payment account number, payment expiration date, payment security code for online transactions (e.g., CVV2, CVC2), card name, and other pieces of information.

[1045] Messages associated with a particular time and/or date may be pre-stored. For example, messages associated with an anniversary date of the issuance of the card, consumer birthday information, country holidays, religious events, or any notification or message associated with a particular time or date. For example, a message wishing the consumer a happy birthday and providing the consumer with a QR code coupon for a certain amount in value may be displayed based on a date received during a payment transaction (and, for example, a clock in the payment device that updates the stored date as time passes). Persons skilled in the art will appreciate that a birthday event may trigger a feature such as a game feature where a consumer gets to pick a gift box from a number of gift boxes where each or one ore of the gift boxes has a different amount or type of value stored in it. Accordingly, a marketing campaign may be provided where on your birthday you have the chance to win a statement credit for your payment card bill in different amounts based on, for example, an instant no-purchase necessary sweepstakes where on the cardholders birthday the cardholder is provided instant statement credit value based on different odds of receiving different amounts of value. Pre-stored messages based on time could be provided so that a different message is released at a particular time (e.g., 9am EST) every day. Date-based messages could include for example, new years, Christmas, Ramadan, each day of hannakah, memorial day, independence day, election day, etc.

[1046] Messages may be displayed on the payment device for example based on the first authorized transaction after a certain date/time. For example, a message may be pre-stored and displayed on the first authorized transaction after the first year of being issued the payment device or payment account on the payment device.

[1047] Payment devices, such as payment cards, may include, for example, one or more displays, light emitting diodes, programmable magnetic stripes that can change the magnetic stripe data on the magnetic stripe, programmable EMV chips, programmable contactless chips, cellular chips and antennas for downloading data from a remote source, manual interfaces, sound interfaces, and/or the like. [1048] Security features may be provided based on the received data. For example, a dynamic security code may be changed based on time and/or date information received from the payment device during an authorization transaction on a two-way authorization process (e.g., via an EMV or contactless transaction). The dynamic security code may provide a dynamic in- stripe security code (e.g., CVC1/CV1) and on-line security code (e.g., CVC2/CVV2). They may be the same or different security codes based on time and/or date or other information received and multiple types of information received (e.g., a different code may be provided based on time and country information received during a payment transaction).

[1049] Pre-stored messages may be provided based on any information received such as, for example, country code and/or according to an issuer script. For example, a welcome message may be provided after a consumer makes a payment transaction in a new country that welcomes the user to the country and provides the consumer with payment information (e.g., exchange rates) based on that country. After each authorized transaction, for example, a card may display information on the transaction (e.g., amount of the transaction) in both the local and foreign currency by using information received and/or logic on the card.

[1050] Transaction applets may be provided that changes the account or payment option information based on what was received during the transaction. For example, if a US card account is utilized in Spain then the card may change the account to a Spanish account for future transactions (unless otherwise directed by the cardholder). In doing so, the payment device can receive information and change the way the payment devices operated based on the received information.

[1051] Cards or other devices may utilize an array of LEDs to be used to display and/or convey information to a user (e.g., cardholder). The LED arrays may be under the control of, for example, a general purpose microcontroller on the card. The cards or other devices may include dynamic magnetic communications devices and/or static magnetic stripes. The LED arrays may be in any configuration deemed necessary to convey information, for example, matrix configurations such as a dot matrix array, may be used to display alphanumeric messages (e.g., static or scrolling), and/or may be used to display images (e.g., static or moving) (FIG. 78).

[1052] The LED arrays may be in a random or ordered array configuration to display a sequence or imagery, for example, a fireworks display (FIG. 79). Random Images may be lit statically or in sequence (FIG. 80).

[1053] According to example embodiments, power on configurations may include card configurations with buttons to turn on the card and/or button-less card configurations that turn on when inserted into a RFID or EMV Reader. A button-less configuration may be applied whether or not the card or other device includes buttons.

[1054] Intelligence to decide messages may include PDOL/CDOL information utilized to determine a message. Items available from the terminal may be as follows:

[1055] Amount, Authorized (Numeric)

[1056] Amount, Other (Numeric)

[1057] Terminal Country Code

[1058] Terminal Verification Results [1059] Transaction Currency Code

[1060] Transaction Data

[1061] Transaction Type

[1062] Data Authentication Code

[1063] ICC Dynamic Number

[1064] CVM Results

[1065] Transaction Time

[1066] Merchant Custom Data

[1067] Transaction Currency Code

[1068] Transaction Date

[1069] Transaction Type

[1070] TVR

[1071] Unpredictable Number

[1072] PDOL/CDOL information may be used to display messages such as Happy Birthday based on, for example, a date (e.g., Transaction Date). Additional Rewards may be based on a transaction amount (e.g., Amount, Authorized). The information may be displayed in a variety of ways, for example, as a message on a dot matrix display and/or the "fireworks going off" (FIG. 79) indicating that the cardholder is a "winner" which may be known to the user as a criteria when the card or other device is received.

[1073] Issuer Scripts may be used by a financial institution (e.g., a bank) to send information to the card or other device during a transaction.

[1074] The issuer can inform the user of things, for example:

[1075] Additional rewards (e.g., based on total spend).

[1076] Reduced interest rate (e.g., based on level of usage).

[1077] Change in payment product Tier. [1078] This information may be displayed as a message on a dot matrix display and/or the "fireworks going off" indicating that they are a "winner" which would be known by the user as a criteria when the card was received.

[1079] Any information could enable a new account (e.g., debit credit) or payment option (e.g., EMI, pay with points) for the current or a future transaction. A card can terminate a transaction based on information received and start a subsequent transaction (e.g., by having the cardholder remove and replace the card in a chip contact reader or reinstitute a new contactless transaction, etc. Persons skilled in the art will appreciate that payment terminals can be constructed to reinstitute transactions automatically if a transaction fails.

[1080] Example types of information receivable to cause modification of an applet, or by an applet, may include, for example:

[1081] Amount, Authorized (Numeric)

[1082] Amount, Other (Numeric)

[1083] Terminal Country Code

[1084] Terminal Verification Results

[1085] Transaction Currency Code

[1086] Transaction Data

[1087] Transaction Type

[1088] Data Authenticiation Code

[1089] ICC Dynamic Number

[1090] CVM Results

[1091] Transaction Time

[1092] Merchant Custom Data

[1093] Transaction Currency Code

[1094] Transaction Date [1095] Transaction Type

[1096] TVR

[1097] Unpredictable Number

[1098] According to example embodiments, methods of personalization and personalization updates to credit cards in the field are disclosed.

[1099] One or more, for example, over 5 glow areas including a light material such as light guides that disperse light from light emitting diodes (LEDs). The LEDs may be face firing or side firing, to cause glow areas to emit light. Glow areas may be in the shape of logos, animals, or other thematic imagery. Glow areas may additionally or alternatively include a large number of LEDs, for example, over 100, over 200, or any number of LEDs.

[1100] Perso Data Encryption. According to some example embodiments, encrypted personalization data may be sent over a transmission link (e.g., cell network, Bluetooth, NFC, etc.). A personalization data block may have a unique session identifier preprogrammed into a secure element (SE) which may be used as part of an decryption process.

[1101] Data may be encrypted at multiple levels.

For example, a two level embodiment may include transmission link encryption. An entire block of personalization data may be encrypted (e.g., 3DES, AES, etc.) during transmission. This block may be decrypted by, for example, a general purpose processor (GP). The GP may use a unique Session Identifier to request the transmission decryption key from the Secure Element.

[1102] Such a two level embodiment may further include encryption of sensitive personalization data (personal data of a cardholder) - sensitive personalization data such as UDKs may be encrypted such that they will never be in the clear. This information may be sent encrypted to the SE (such as a secure element chip) and may be decrypted inside the Secure Element. This decryption process may be performed by an applet installed on the SE.

[1103] Cards may be preloaded with sets of keys in the SE that are associated with: Transmission Link Key - This key may be utilized by the GP to decrypt the entire personalization data block that was received. The GP may provide the unique session identifier provided with the personalization data Block to the SE such that the appropriate key can be provided.

Multiple unique transmission keys (each associated with a unique Session Identifier) may be preloaded such that multiple personalization upgrades can be performed over the life of the card. This process may be protected from attacks by, for example, only allowing three attempts to request the transmission link key and if the proper unique session identifier is not provided within three attempts, the process may be blocked going forward. Sensitive Perso Data Key - This key may be utilized by the SE to decrypt sensitive personalization data. The unique session identifier may be provided to the SE to be able identify the proper preloaded keys to decrypt the sensitive personalization data. Multiple unique sensitive personalization data keys (each associated with a unique Session Identifier) may be preloaded such that multiple personalization upgrades may be performed over the life of a card. This process may be protected from attacks by only allowing three attempts to provide a unique session identifier and if the proper unique session identifier is not provided within three attempts, the process will be blocked going forward.

[1104] Preloaded Perso Data. According to some example embodiments, preloading either multiple entire sets of personalization data or multiple partial sets of personalization data (which may be unique to this card) which may be triggered to be used by sending a signal to the card over a transmission link (e.g., cell network, Bluetooth, NFC, etc.) to change account information.

[1105] Complete sets of Perso Data - Multiple sets of Perso Data which may include changes based on an update to PAN sequence number only or entirely different PANs can be preloaded on the SE. Each of the accounts may be associated with a Unique Account Identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the Unique Account Identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[1106] Partial Sets of Perso Data - In order to minimize the amount of data preloaded, only the unique data associated with an account upgrade (PAN, UDKs, certificates, etc.) may be preloaded. Multiple partial sets of Perso Data which may, for example, include changes based on an update to PAN sequence number only or entirely different PANs may be preloaded on the SE. Each of the Partial Sets of Perso Data may be associated with a unique account identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the unique account identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that Account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[1107] Metal and Pseudo Metal Cards

[1108] According to example embodiments, a metal may be coated on a non-metal surface, for example, a plastic and/or glass (e.g., flexible glass) skin layer. For example, metal may be poured, sprayed, extruded and/or applied by mold processing. According to some example embodiments, metal may be deposited using vapor deposition (e.g., CVD, PCVD, EPCVD, PVD) using, for example, a vacuum chamber at, for example, class 100,000, 1000, 100 or 1. Metal may be deposited by, for example, evaporation, sputter coating, and/or thermal heat transfer.

[1109] The deposition may be conformal and/or result in a planar surface. For example, a card may have different thicknesses in different areas (e.g., battery area may be thicker) and the deposition may result in a planar or approximately planar surface.

[1110] Metal coating may be excluded in sensitive areas that include, for example, EMV contacts, LED lights, and electronic screens, using a mask. According to some example embodiments, a mask may be provided, for example, by using resist based processes and/or stickers. For example a sticker may be applied to a layer on which metal will be deposited and removed after the deposition. Metal patterning may be performed by, for example, shadow mask (contact and non-contact), tape off, laser removal and photoresist lift off.

[1111] A skin material may be thick (e.g., thicker than conventional skin layers) and made of, for example a flexible glass or other material that withstands elevated temperature processing (e.g., high temperature and/or pressure depositions) and protects internal components. The skin material may be the same on both sides of a card or different.

[1112] After metal coating, the metal may be covered with a protective and/or visual enhancement layer or layers. A protective film may be applied via, for example, printing, thermal transfer and/or spray coating.

[1113] Several surface materials may be used. For example, PolyCarb, PolyEster, Kapton tape and/or glass.

[1114] A protective film visual enhancement layer or layers may include, for example, printed textures and light bending patterns.

[1115] FIG. 81 shows cards and architectures according to example embodiments. Referring to FIG. 1, card 100 may be a dynamic powered card, and may include, for example, dynamic magnetic stripe communications device 101, one or more displays (e.g., displays 112, 113 and 125), permanent information 120, one or more buttons (e.g., buttons 130-134, 197 and 198) and/or dynamic number 114. Dynamic number 114 may include permanent portion 111. Permanent portion 111 may be, for example, printed, embossed and/or laser etched on card 100.

[1116] Multiple displays may be provided on card 100 for various purposes. For example, display 112 may utilized to entirely, and/or partially display a dynamic number. Display 113 may be utilized to display a dynamic code (e.g., a dynamic security code). Display 125 may display logos, barcodes and/or multiple lines of information. At least one of displays 112, 113 and 125 may be a bi-stable or non bi-stable display. A bi-stable display may be a display that maintains an image without power.

[1117] Permanent information 120 may include, for example, information specific to a user (e.g., a user's name and/or username) and/or information specific to a card (e.g., a card issue date and/or a card expiration date).

[1118] Buttons 131-134, 197 and 198 may be mechanical buttons, capacitive buttons, or a combination of mechanical and capacitive buttons. Buttons 131-134 may be used, for example, to enter information (e.g., an access code) and/or to make a selection. For example, using buttons 131-134, a user may select options displayed on display 125 that instruct card 100 to communicate (e.g., via a dynamic magnetic stripe communications device, RFID and/or exposed IC chip) a user's instructions to use a debit account, a credit account, a pre-paid account, and/or a point account for a transaction (e.g., a payment transaction). According to at least one example embodiment, more than one account may be selected. For example, a transaction may be divided between accounts and card 100 may be utilized to indicate a user's desire to use a point account until the point account is exhausted and then to use a credit account.

[1119] Button 197 may be used, for example, to communicate information through dynamic magnetic stripe communications device 101 indicative of a user's desire to communicate a single track of magnetic stripe information. Persons skilled in the art will appreciate that pressing a button (e.g., button 197) may cause information to be communicated through device 101 when an associated read-head detector detects the presence of a read-head of a magnetic stripe reader. Button 198 may be utilized to communicate (e.g., after button 198 is pressed and after a read-head detects a read-head of a reader) information indicative of a user selection (e.g., to communicate two or more tracks of magnetic stripe data, to communicate different track data, to modify tracks of data and/or the like).

[1120] Button 197 and button 198 may each be used to associate a feature to a transaction. For example, button 197 and button 198 may be associated to different service provider applications. Each service provider application may be associated to a different service provider feature (e.g., rewards). A user may, for example, press one or more of buttons 197 and 198 to choose one or more features for a particular transaction.

[1121] A user may associate applications to buttons and/or features to applications, for example, on a graphical user interface (GUI). The graphical user interface may be, for example, an application manager provided by one or more entities (e.g., an application manager provider). The associations may be changed, for example, at any time, periodically, and/or upon the occurrence of an event. According to some example embodiments, a user may associate applications to buttons and/or features to applications by telephone, by electronic mail and/or any other communication method. [1122] Associations between buttons and service provider applications may be maintained by an ecosystem provider, for example, within an ecosystem of applications, transactional methods and types of transactions. When a transactional method (e.g., card 100) is used by a user, the ecosystem provider may receive transactional data and information indicative of a button selected by the user. The ecosystem provider may determine the identity of an application associated to the button, and may communicate some or all of the information and/or transactional data to the application and/or the service provider. The service provider and/or the application may provide a feature associated with the application based on the information and/or transactional data.

[1123] Display 125 may be an enhanced display, an improved display, and/or a large footprint display. For example, display 125 may be a 1 inch by 1 inch display, a 1 inch by 1.5 inch display, a 1 inch by 2 inch display, and/or the like. Display 125 may be centered, left justified, right justified, top justified, bottom justified and/or vertically justified. Display 125 may be, for example, a multi-segment, a multiline display, a dot matrix display and/or the like. A multiline display 125 may include two lines of 5-20 characters per line, for example, 9 characters per line, 10 characters per line and/or 18 characters per line. Card 100 may include a toggle button, a power button and/or a toggle power button (e.g., one of buttons 197, 198, 131, 132, 133 and 134, or a touch sensitive element of a touch sensitive display 125 and/or read head detectors 171 and 172, and/or the like).

[1124] Different features may be provided based on the use of different transactional methods and/or transaction types. For example, suppose a service provider provides a reward feature based on the use of a particular payment method (e.g., a reward for using a particular credit card). A user may purchase an item using the particular payment method (e.g., may select a particular credit account using buttons 130-134 and display 125). When the purchase is performed, the reward may be communicated to the user. As another example, suppose a service provider provides a reward feature based on a type of transaction. For example, a reward may be provided for a sale of a commodity using a particular transaction processor (e.g., issuer, acquirer and/or payment network). A user may sell a commodity using the particular transaction processor (e.g., the ecosystem provider) and upon completion of the sale a reward may be communicated to the user.

[1125] Selection of a feature may or may not have a cost associated with it. If a cost is associated with the feature, for example, the cost may be added to a customer's statement (e.g., added to a credit or debit purchase) for a particular transaction. A fixed-fee and/or variable-fee (e.g., a percentage of the transaction) may then be removed from the fee charged to the user and distributed among particular parties, for example, distributed among a card issuer, application manager provider, ecosystem provider, device provider, service provider and/or one or more other entities. Persons skilled in the art in possession of example embodiments will appreciate that many different fee arrangements are possible, and that the various providers may be the same and/or different from each other.

[1126] A cost may be associated to a feature selection, but may not be a cost to a user. For example, the cost may be a cost to a service provider (e.g., a third party service provider). The cost may be provided to other entities, for example, the device provider, card issuer, card processor, and/or any other entity (e.g., a card network).

[1127] Display 112 may display a dynamic number, for example, all or a portion of an account number (e.g., a credit and/or debit account number). Display 113 may display, for example, a dynamic verification code (e.g., a card verification value (CVV) and/or card identification number (CID)). The dynamic numbers displayed on displays 112 and 113 may change according to various schemes as a security measure against fraudulent transactions. For example, the dynamic numbers may change based on time and/or upon the occurrence of an event such that a previously recorded number may become unusable. The dynamic numbers may change with each transaction (e.g, each swipe of card 100), when card 100 is turned on, and the like.

[1128] Card 100 and/or a user may communicate a dynamic number to a processing facility. The processing facility may validate the dynamic number (e.g., a dynamic credit card number and/or a dynamic security code). A user may purchase items using a dynamic card and a processing facility may authorize the purchases upon determining that the dynamic number is valid.

[1129] Although example embodiments may be described with respect to numbers, the scope of example embodiments includes any distinguishing representation of a security code and/or account, by any sensory method (e.g., sight, sound, touch and/or the like). Characters, images, sounds, textures, letters and/or any other distinguishable representations are contemplated by example embodiments.

[1130] Generation of a dynamic number and the functionality needed to verify the dynamic number at a processing facility may be accomplished in a variety of ways. For example, a private key (or equation, hash table function and/or the like) and a secure card number (e.g., a private number) may be known to both the dynamic card (e.g., stored in memory 142 of a card 100) and the processing/authorization facility. A signal may be received or generated by the dynamic card (e.g., a counter signal, a randomly generated signal, a timing signal, etc.) and the dynamic card may produce a dynamic number based on the signal, the private key and/or the private card number. The processing facility may utilize the private key, private card number, the dynamic number, and/or the signal (or a different signal synchronized with the signal) to verify that the dynamic number is correct.

[1131] As one non-limiting example, a processing facility may receive a time stamp with a dynamic number and any other information received from a dynamic card (e.g., account identification information and expiration date). The processing facility may use the time stamp, the received dynamic card information (and any other received information), the private key, and the private number to verify that the dynamic number is correct for that period of time (or a string of consecutive periods of time that include, and are located near, the time stamp). A time stamp may be utilized, for example, to authorize online purchases and/or telephonic purchases that are not immediately processed. A time stamp may be indicative of, for example, a particular time or period of time. According to at least one example embodiment, a timing may be independently determined by a dynamic card and a processing facility (e.g., using a same time source and/or synchronized timing sources) and a time stamp may not be communicated. According to other example embodiments, time may be synchronized between a card and a processing facility at the processing facility based on received timestamps.

[1132] Persons skilled in the art will appreciate that a dynamic card number may be produced without the need for a private number such as a private credit card number or security code, for example, a number stored in both a credit card and a remote facility. For example, a timing signal may be encoded based on the private key (or equation) and the resultant encoded number utilized as a dynamic credit card number. According to at least one example embodiment, a timing signal may be coded using a private credit card number.

[1133] A private key may be an equation or formula that uses one or more other variables (e.g., a random number) to generate a coded number (e.g., a dynamic number). Persons skilled in the art will appreciate that one or more private keys (e.g., an equation or formula) may be utilized to code different numbers for a dynamic card. For example, one private key may be utilized to code a dynamic card number while another private key may be utilized to code a dynamic security code (e.g., a verification code).

[1134] A number of private keys (and/or private numbers) may be stored in a credit card and such private keys (and/or private numbers) may be changed periodically (e.g., every day or week). A similar number of private keys (and/or private numbers) may be stored in a remote facility (e.g., a remote server), the selection of which may be determined by a particular time (e.g., a particular day or a particular week). A processing/authorization facility, or any device/facility, may receive the dynamic card number and decode the dynamic number based on a replica of the private key and/or private number of the card that is stored at, or accessible by, the facility (e.g., stored on a database and/or server).

[1135] Persons skilled in the art in possession of example embodiments will appreciate that synchronization between a card and a processing facility may not be required. For example, a counter on card 100 may increment each time card 100 is used. If information does not reach a processing facility a counter used by the processing facility may not also increment. The processing facility may authorize dynamic numbers that are valid within a range to avoid declining transactions that are otherwise valid (e.g., non-fraudulent). For example, if a dynamic number is recognized for another value of a counter within a range (e.g., within 10 increments of the counter from the value of the counter at the processing facility), the processing facility may authorize a transaction and set the counter at the processing facility to match the expected counter value at card 100. An algorithm and/or transaction history may be maintained to determine if non-synchronized validations exceed an expected error level. If the error level is exceeded, transactions may be declined. [1136] For example, a card may, at the push of a button on a dynamic card, generate a new number (e.g., from a list of stored numbers). A remote facility may determine if the button was pressed on the dynamic card by determining if a future dynamic number is valid and, if a future number is valid, the remote facility may invalidate all numbers located before the newly validated number. At the next transaction, the dynamic facility may, for example, attempt to validate the received number with the number located after the newly validated number. A table may store, for example, a dynamic number and a pointer to the next entry. A processor may read a dynamic number and utilize the pointer to determine the location of the next dynamic number. Persons of ordinary skill in the art will appreciate that similar strategies may be used for schemes employing a timing signal and/or the like.

[1137] A remote processing/authorization facility may, for example, perform the same process as the dynamic card and compare the facility's dynamic number with the received dynamic number for verification. For example, a remote facility may include any equations and variables needed by the dynamic card to generate a dynamic number and may perform an operation similar to the one performed by the dynamic card to generate its own dynamic number. The remote facility may then compare the received dynamic number to the generated dynamic number to determine if the two numbers are the same and/or within an expected degree of similarity.

[1138] A remote processing/authorization facility may decode a dynamic number using an equation and/or a private key (which may be an equation itself or a variable) to obtain a resultant number and compare this number against a private number for approval. If the decoded number matches the private number (which may, or may not, be the same private number stored in the credit card), then the dynamic number may be validated.

[1139] A dynamic card may be utilized using traditional infrastructure and may be utilized for online (or telephonic) purchases and purchases that require the card to be swiped (or entered manually into a credit card reader). A dynamic number may be decoded at any point in a validation/authorization process. For example, an online store may include the components (e.g., hardware and/or software) necessary to decode the dynamic number such that a decoded number (e.g., a credit/debit card number) may be transmitted to a card processing facility.

[1140] A processing facility, or any device decoding a number, may utilize an identification number to identify the account/card that produced the dynamic number. The identification number may then be utilized to look up, for example, the private key and/or private number of the account/card such that a dynamic number can be generated from the retrieved information (and compared to the received dynamic number) and/or the retrieved information can be utilized to decode the dynamic number such that the card may be validated and/or a transaction authorized. Multiple users may utilize the same dynamic number at any one time and the identity of the account/card can still be determined (e.g., by using the identification information).

[1141] Identification information may be utilized to identify a credit card. Multiple users may be utilizing the same dynamic number (e.g., a dynamic credit card number or a dynamic verification code) at any time. The identification information may be utilized to identify a credit card such that a dynamic number can be, for example, retrieved/generated for a particular period of time (and/or a particular transaction) for the identified credit card and compared to the received dynamic number.

[1142] The dynamic card number may be transformed into a particular credit card format so that a dynamic number may be verified as having the appropriate format before, for example, the number is transmitted to a credit card processing/authorization facility. For example, a coding equation may be utilized that always produces numbers that fit a particular format.

[1143] A dynamic card system may allow multiple users to have the same dynamic number at any particular time. Additional information may be transmitted to identify the user. For example, an account number and/or name may be utilized. According to at least one example embodiment, a traditional credit card number may be written on a traditional magnetic stripe. Such a credit card number may be used for identifying the user. A dynamic security code (e.g., a four digit security code such as a verification code) may then be provided that changes periodically. Such dynamic information (e.g., the dynamic security code) may be written to a portion of the magnetic stripe that does not have the traditional credit card number and/or the dynamic information (e.g., the dynamic security code) may be displayed to a user.

[1144] A signal may be utilized to produce a key that is used in an equation to manipulate a credit card number. The signal may be a timing signal, a counter signal, a random number generator signal (e.g., that operates similar to a random number generator in a processing facility) and/or the like. Such a counter number (or random number) may be provided to a processing facility so that the processing facility may decode (or perform the same function as the dynamic card and compare the results). A credit card number may be invalidated at the facility if, for example, any particular number is used more than a particular number of times (e.g., more than 10 times). Such a counter may be increased after every purchase (e.g., after a user presses a button to change the number). As per another example, if a counter is used and the counter is increased when a number is used (or the credit card believes that a number has been used), the number of transactions operable of being made may be limited by the storage capacity of the counter.

[1145] According to example embodiments, a method of authorizing transactions using a dynamic number may not be subject to synchronicity. For example, according to at least one example embodiment, an issuer may associate a function composed of multiple variables to each transaction account (e.g., to each credit card account), and may issue card 100 to a user with the associated function and a random number generator (e.g., a computational or physical device). A random number generated by the random number generator may define each variable of the function. For each transaction, card 100 may generate a random number and determine a solution to the associated function using the random number to generate a dynamic number. Card 100 may communicate the random number, the dynamic number and an identifier, to a verification facility and/or device (hereinafter, "verifying entity"). The verifying entity may retrieve the function associated to card 100 from secure storage based on the identifier and/or may determine the function using the identifier. A solution to the retrieved/determined function may be calculated using the random number communicated by card 100 to generate a verification number. The verifying entity may determine whether or not the verification number matches the communicated dynamic number. A transaction may be authorized if, for example, a match is determined.

[1146] According to example embodiments, a function associated with an account need not be stored by card 100 and/or a verifying entity. For example, each account may be associated to a function determination value and a (same) base set of variables. The function determination value may identify operators and/or exponents of a function including the base variables. Each associated function may be completely determined for each transaction using the operators, exponents and base variables. If the function determination value is, as one non-limiting example, a 5 digit number in a decimal numeral system defining 3 different operators, a total of about 2700 different functions may be determinable.

[1147] According to example embodiments, an identifier communicated by card 100 to a processing facility may be a function determination value and/or may be information used by a processing facility to determine/retrieve the function determination value.

[1148] Architecture 150 may be utilized with any card (e.g., any card 100). Architecture 150 may include, for example, processor 120, display 140, driving circuitry 141, memory 142, battery 143, radio frequency identification (RFID) 151, integrated circuit (IC) chip 152, electromagnetic field generators 170, 180, and 185, and read-head detectors 171 and 172.

[1149] Processor 120 may be any type of processing device, for example, a central processing unit (CPU) and/or a digital signal processor (DSP). Processor 120 may be, for example, an application specific integrated circuit (ASIC). Processor 120 may include on-board memory for storing information (e.g., drive code). Any number of components may communicate to processor 120 and/or receive communications from processor 120. For example, one or more displays (e.g., display 140) may be coupled to processor 120. Persons skilled in the art will appreciate that components may be placed between particular components and processor 120. For example, a display driver circuit may be coupled between display 140 and processor 120.

[1150] Memory 142 may be coupled to processor 120. Memory 142 may store data, for example, data that is unique to a particular card. Memory 142 may store any type of data. For example, memory 142 may store, for example, a function, base variables and/or a function determination value used to generate a dynamic number. As another example, memory 142 may store discretionary data codes associated with buttons of card 100. Discretionary data codes may be recognized by remote servers to effect particular actions. For example, a discretionary data code may be stored in memory 142 and may be used to cause a third party service feature to be performed by a remote server (e.g., a remote server coupled to a third party service such as an online voucher and/or coupon provider).

[1151] Different third party features may be, for example, associated with different buttons and a particular feature may be selected by pressing an associated button. According to some example embodiments, a user may select a third party feature from a list displayed to the user. For example, the user may scroll through a list of features on a display (e.g., a display on the front of the card). A user may scroll through a list using buttons on card 100. The list of features may be displayed to the user individually (e.g., one or more buttons may be used to change which feature is displayed), in groups and/or all features may be simultaneously displayed.

[1152] According to at least one example embodiment, a user may select a type of payment on card 100 via manual input interfaces. The manual input interfaces may correspond to displayed options (e.g., displayed on display 125) and/or may be independent buttons. Selected information may be communicated to a magnetic stripe reader via a dynamic magnetic stripe communications device. Selected information may also be communicated to a device (e.g., a mobile telephonic device) including a capacitive sensor and/or other type of touch sensitive sensor.

[1153] Architecture 150 may include any number of reader communication devices. For example, architecture 150 may include at least one of IC chip 152, RFID 151 and a magnetic stripe communications device. IC chip 152 may be used to communicate information to an IC chip reader (not illustrated). IC chip 152 may be, for example, an EMV chip. RFID 151 may be used to communicate information to an RFID reader. RFID 151 may be, for example, a RFID tag. A magnetic stripe communications device may be included to communicate information to a magnetic stripe reader. For example, a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

[1154] Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, architecture 150 may include electromagnetic field generators 170, 180 and 185 to communicate separate tracks of information to a magnetic stripe reader. Electromagnetic field generators 170, 180, and 185 may include a coil (e.g., each may include a coil) wrapped around one or more materials (e.g., a soft-magnetic material and a non-magnetic material). Each electromagnetic field generator may communicate information, for example, serially and/or in parallel to a receiver of a magnetic stripe reader for particular magnetic stripe track.

[1155] Architecture 150 may include read head detectors 171 and 172. Read-head detectors 171 and 172 may be configured to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). Information sensed by the read-head detectors 171 and 172 may be communicated to processor 120 to cause processor 120 to communicate information serially from electromagnetic generators 170, 180, and 185 to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader.

[1156] According to at least one example embodiment, a magnetic stripe communications device may change the information communicated to a magnetic stripe reader at any time. Processor 120 may, for example, communicate user-specific and card-specific information through RFID 151, IC chip 152, and/or electromagnetic generators 170, 180, and 185 to card readers coupled to remote information processing servers (e.g., purchase authorization servers). Driving circuitry 141 may be utilized by processor 120, for example, to control electromagnetic generators 170, 180 and 185.

[1157] Architecture 150 may include, for example, a light sensor (not illustrated). Architecture 150 may receive information from a light sensor. Processor 120 may determine information received by a light sensor.

[1158] FIG. 82 shows devices according to example embodiments. Referring to FIG. 82, device 200 may be, for example, a mobile telephonic device and/or other device (e.g., portable computer such as a portable tablet computer). Device 200 may include, for example, housing 202, display 210, device card 220, virtual buttons 230- 232, virtual keyboard 240, selections 250-290, and/or dynamic code 290.

[1159] Display 210 may include, for example, light- sensitive and/or touch-sensitive elements. Device 200 may communicate information to a card reader, for example, via a contactless signal (e.g., an RFID signal) and/or a contact-based signal (e.g., a USB connection). Any of multiple different communication technologies may be used to communicate information to, for example, a card reader.

[1160] Device 200 may include a device card 220 and/or virtual buttons 230 and 231. Device card 220 may be a virtual representation of a card and/or any information identifying a payment method (e.g., credit account number). Persons skilled in the art will appreciate that any physical card described herein may be provided as a device card on, for example, a computing system (e.g., a mobile telephonic device and/or a computer). Physical buttons of a physical card may, for example, correspond to virtual buttons of a device card.

[1161] Virtual button 230 may, for example, correspond to one component (e.g., an IC chip or virtualized IC chip) from one service provider. Virtual button 231 may, for example, correspond to another component (e.g., another IC chip or virtualized IC chip). [1162] All features associated to a card may be utilized, for example, with a particular payment account (e.g., a credit account) such that a payment transaction with that payment account is performed if any feature is selected. As another example, one or more features may be associated with a payment account (e.g., a credit account) while an additional one or more features may be associated with a different payment account (e.g., a debit account). Accordingly, a selected feature associated with a credit account may be utilized to make a purchase with credit and may perform an additional action associated with that feature. A different selected feature associated with a debit account may be utilized to make a purchase with debit and may perform an additional action associated with that different feature.

[1163] Selection 250 may be, for example, a link to an application for a new card provided by, for example, an ecosystem provider, application manager provider, card manufacturer and/or the like. Upon activation of selection 250 a user may be directed to an application form. Selection 260 may be, for example, a link to an application for an upgrade to a new card provided by, for example, an ecosystem provider, application manager provider, card manufacturer and/or the like. Upon activation of selection 260 a user may be directed to an application form. According to at least one example embodiment, selections 250 and 260 may only appear upon availability to a user and may not require an application process (e.g., may be based on preapproval).

[1164] Selection 270 may be, for example, a link used to report a lost and/or stolen device, device card and/or physical card. Upon activation of selection 270 information may be automatically communicated to one or more responsible parties, for example, an issuer (e.g., for deactivation of the payment method). Selection 280 may be, for example, a link used to display a GUI. Upon activation of selection 280 an application manager used to associate features to virtual buttons, and virtual buttons to payment methods, may be displayed.

[1165] Dynamic code 290 may be, for example, a credit card number, a CVV and/or a CID. Dynamic code 290 may change based on an event, for example, based on a change in time, a counter and/or the like. Dynamic code 290 may change based on a transaction using, for example, a function and/or formula. For example, dynamic code 290 may change every transaction, every number of transactions, for a type of transaction (e.g., greater than $100 and/or using a debit card) and/or the like.

[1166] FIG. 83 shows network topologies according to example embodiments. Referring to FIG. 83, network topology 300 may be a logical topology of a transactional network including multiple network elements (e.g., servers, routers, switches, user devices, communications infrastructure and/or the like). The network elements may include, for example, mobile device 305, card reader 310, card 315, network access infrastructure 325, mobile network 330, wireless access point 335, IP network 340, remote verification processor 345, payment network 355, issuers 360, device 370, contactless device 380 and/or online merchant 395.

[1167] Card 315 may be, for example, a powered and/or dynamic card. Mobile device 305 may be, for example, a mobile telephonic device, a personal digital assistant (PDA), an electronic tablet, a laptop, a global positioning system (GPS), an MP3 player, a smartphone and/or the like. Mobile device 305 may be used by any transactional entity, for example, a user, a merchant, a biller, an enterprise, a government, a non-profit organization and/or the like. Card reader 310 may be, for example, a data input device configured to receive data from a data device (e.g., card 315). For example, card reader 310 may receive data from a magnetic stripe, EMV chip, contactless (e.g., RFID) technology and/or the like. Card reader 310 may connect to mobile device 305 via, for example, interface 320. Interface 320 may be an input to, for example, any one of multiple ports of a mobile device 305, for example, an input to a universal serial bus (USB) port, MicroUSB port, 32-pin connector, a headphone jack, an Ethernet port and/or the like.

[1168] Remote verification processor 345 may be a network element of an entity performing data verification, for example, a remote service provider. Remote verification processor 345 may be a remote processing facility including one or more computing devices (e.g., servers) verifying dynamic data communicated during a transaction. Dynamic data may be, for example, data associated with, and/or communicated in lieu of, a static security code, such as a card verification code or card verification value code (e.g., CVV, CVV2, CVC, CVC2, CID and/or the like). The dynamic data may be conventionally placed within a transaction message, and/or may be placed in a discretionary field of a transaction message (and/or other fields).

[1169] A dynamic code verified by remote verification processor 345 may be dynamic data associated with and/or representative of any transactional data, such as an expiration date, payment data, third party data, a card number, portions of a card number, information printed on a transaction device, information displayed by a display of a transaction device, data associated with printing on a transaction device (e.g., a number of times a particular symbol is printed on a transaction device) and/or the like. Third party data may be, for example, merchant data associated with a purchase and/or associated with a merchant (e.g., a merchant ID) that may be used to verify that a valid merchant communicated transactional information.

[1170] Issuers 360 may be issuer processors and/or issuers of transactional methods compatible with dynamic security code transactions (e.g., issuing financial institutions). Payment network 355 may be, for example, one or more network elements routing transactional information between, for example, remote verification processor 345 and issuers 360.

[1171] Remote verification processor 345, issuers 360, and/or payment network 355 may be connected by, for example, IP network 340, mobile network 330, private networks, trusted networks, encryption networks, sub- networks and/or the like. Connections between network elements may be wired and/or wireless.

[1172] Mobile device 305 may include one or more transceivers, receivers and/or transmitters that may communicate with one or more wired networks (e.g., IP network 340 and/or payment network 355) and/or one or more wireless networks (e.g., mobile network 330). Mobile device 305 may, for example, communicate with a cellular station over a wireless radio interface (e.g., a global system for mobile communications (GSM) air interface and/or the like) that may be used by mobile device 305 to communicate information (e.g., voice and data) to cellular network access infrastructure 325 (e.g., one or more GSM base transceiver stations, base station controllers and mobile switching centers). Persons skilled in the art will appreciate that cellular network access infrastructure 325 may utilize any multiple access architecture, for example, a code- division multiple access architecture and/or a time- division multiple access architecture.

[1173] Mobile device 305 may communicate with wireless access point 335 over a wireless interface (e.g., a Bluetooth interface, Wi-Fi interface and/or the like). Mobile device 305 may, for example, access one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks (e.g., mobile network 310) without the need to first gain access to cellular network access infrastructure 325.

[1174] Mobile device 305 may initiate a financial transaction with one or more network entities and/or devices. Transactional information may be used to process the financial transaction and may include, for example, identification data, a dynamic number, and/or a time stamp. Transactional information may be used to verify that a dynamic number is correct. According to at least one example embodiment, the transactional information may include magnetic stripe data.

[1175] The transactional information may be communicated to mobile device 305 from card 315 via card reader 310. According to at least one example embodiment, a portion of the transactional information may be communicated to mobile device 305 from card 315, and a different portion may be provided by mobile device 305. For example, dynamic data, a timestamp and identification data may be provided by mobile device 305. [1176] The financial transaction may include, for example, a purchase of items for sale by a user. A purchaser's request to purchase the items may be initiated by a browser and/or application of mobile device 305 via an access point, for example, wireless access point 335 and/or cellular network access infrastructure 325. Mobile device 305 may obtain payment information including an identification code, dynamic data and/or a time stamp via card reader 310 (e.g., when card 315 is swiped through card reader 310), and may communicate the payment information to one or more network elements for transactional processing. The time stamp may be, for example, based on clock signal generated internally and/or externally to card 315.

[1177] According to some example embodiments, card 315 may include a receiver and/or transceiver, and may synchronize and/or resynchronize to remote verification processor 345, and/or remote verification processor 345 may synchronize to card 315, for example, using the timestamp. Using processor-side-synchronization, component differences between cards (e.g., part variability, wear and/or bending), different ambient conditions in which a card is used, bending of cards by users, differences induced during manufacture of cards, network delays, transaction delays and other variability may be accounted for by remote verification processor 345.

[1178] As another example, the financial transaction may include a purchase of items for sale by online merchant 395. The purchaser's request to purchase the items from online merchant 395 may be initiated by a browser of mobile device 305 via an access point, for example, wireless access point 335 and/or cellular network access infrastructure 325. Mobile device 305 may obtain payment information including an identification number, a dynamic data and/or a time stamp via card reader 310, for example, when card 315 is swiped through card reader 310. The payment information may be used to populate entry fields on a webpage of online merchant 395, including a dynamic data entry field and/or a time stamp field. In addition to, or alternatively, all or a portion of the payment information may be displayed on, for example, a display of card 315 and/or a display of mobile device 305, and manually entered using mobile device 305.

[1179] The same dynamic data as communicated by card 315 via a communication interface (a dynamic magnetic stripe, an IC chip, an RFID, a Bluetooth interface, and/or the like) may be displayed. Different dynamic data from the dynamic data communicated by card 315 may be displayed. For example, the dynamic data communicated via a communication interface may be based on a separate algorithm than the dynamic data displayed by card 315. The display may be toggled so that all dynamic data may be cycled through. According to some example embodiments, card 315 may include multiple displays, and at multiple interfaces. Each display and interface may provide a different dynamic code based on a different algorithm, and/or one of the displays may display the dynamic code communicated by an interface.

[1180] According to at least one example embodiment, a portion of the payment information may be displayed by card 315, a portion of the payment information may be printed on card 315, and the portions of the payment information may be entered using mobile device 305. Online merchant 395 may receive and then communicate the payment information. For example, the payment information may be communicated by online merchant 395 to one or more network elements for transactional processing.

[1181] Transactional processing may include multiple transactional events and associated transactional communication flows. Examples of transactional events may include authorizations, dynamic data verifications, settlements, statement debits (e.g., piggyback events), statement credits, returns, partial returns, voids, adjustments and/or chargebacks. Examples of transactional communication flows may include authorization, batching, clearing and funding.

[1182] According to example embodiments, dynamic data that is part of transactional information may be verified by remote verification processor 345. For example, dynamic data verification may be included as part of authorization, batching, clearing and/or funding. According to other example embodiments, dynamic data verification may be a separate transactional communication flow, for example, independent of authorization, batching, clearing and funding.

[1183] Mobile device 305 may communicate transactional information including dynamic data during a transaction, for example, a purchase transaction. For example, dynamic data, a timestamp and an identification number may be communicated to remote verification processor 345 by a transactional entity. The communicating transactional entity may be, for example, mobile device 305, payment network 355, online merchant 395, one or more of issuers 360, an issuer processor (not shown), a merchant acquirer and/or the like. Remote verification processor 345 may determine whether the dynamic data is valid and communicate the determination to a receiving transactional entity. The receiving transactional entity may be, for example, mobile device 305, payment network 355, online merchant 395, one or more of issuers 360, an issuer processor (not shown), a merchant acquirer and/or the like.

[1184] According to example embodiments, dynamic data verification may be performed prior to, during or after transaction processing, or a stage of processing. For example, prior to, during or after authorization processing. The receiving transactional entity may be the same or different from the communicating transactional entity. The communicating transactional entity and the receiving transactional entity may be based on the stage and/or communication flow of a transaction. According to some example embodiments, dynamic data verification may be independent of a communication flow. For example, a merchant may verify dynamic data via remote verification processor 345 prior to initiating a communication flow.

[1185] According to example embodiments, all of the transactional information or a portion of the transactional information may be communicated to remote verification processor 345. According to at least one example embodiment, more than one transactional entity may communicate transactional information to remote verification processor 345. According to at least one example embodiment, more than one transactional entity may be a receiving transactional entity and remote verification processor 345 may communicate the determination of whether the dynamic data is valid to multiple entities (e.g., mobile device 305 and an authorizing entity). [1186] Remote verification processor 345 may determine, for example, a private key used by card 315 to generate dynamic data, as well as inputs to the private key not received from network 355 (if any), by comparing the identification number against stored information. For example, the identification number may be compared to information stored in a database associating identification numbers to private keys. The identification number may be unique and the stored information may include a private key uniquely associated with card 315. The identification number may be either unique or non-unique, and the stored information may include a private key associated with multiple cards, including card 315.

[1187] Remote verification processor 345 may generate comparison data using, for example, the determined private key, the timestamp, and any other inputs to the determined private key. Remote verification processor 345 may generate comparison data using, for example, the determined private key, a time at which remote verification processor 345 receives the timestamp, and any other inputs to the private key. The comparison data may be compared to the dynamic data to determine whether the dynamic data is valid. For example, if the comparison data and the dynamic data are identical, or within a range of dynamic data based on the timestamp, the dynamic data may be determined to be valid.

[1188] According to some example embodiments, dynamic data verification may be based on prior verifications. For example, comparison data may be based on data stored at remote verification processor 345 with respect to previous verifications of card 315, a different card, or multiple different cards. [1189] If the dynamic data is determined to be valid, remote verification processor 345 may notify a receiving entity that the dynamic data is valid. For example, remote verification processor 345 may insert static data associated with the dynamic data into the transactional information (e.g., replace the dynamic data with the static data) such that the modified transactional information may be authorized by a conventional authorizing entity, and communicate the modified transactional data to the receiving entity (e.g., an authorization server). As another example, remote verification processor 345 may insert alert data indicative of valid dynamic data into the transactional information and communicate the modified transactional information to a network device of the receiving entity. As another example, remote verification processor 345 may forward or return transactional information to the network device of the receiving entity for authorization processing, including the dynamic data without the static data (e.g., where the dynamic data matches the static data). As yet another example, remote verification processor 345 may communicate a different message to the network device of the receiving entity indicating that valid dynamic data was received.

[1190] Persons of ordinary skill will appreciate that a different transactional data string may be used instead of a modified transactional data string. As one example, a different transactional data string may be used where remote verification processor 345 communicates transactional information received from a network entity in one data format to a network entity using a different data format. For example, transactional information received from a merchant may be in a different format than used by payment network 355. As another example, transactional information received from payment network 355 may be in a different format than used by one or more of issuers 360. According to example embodiments, multiple different entities may be receiving entities and remote verification processor 345 may communicate verification data differently to each receiving entity based on a format each entity typically receives or is capable of receiving.

[1191] If the dynamic data is determined to be invalid, remote verification processor 345 may notify a receiving entity that the dynamic data is invalid. For example, remote verification processor 345 may insert alert data indicative of invalid dynamic data (e.g., a static code that is not a solution to an equation or include in a LUT) into the transactional information and communicate the modified transactional information to a network device of the receiving entity. As another example, remote verification processor 345 may forward transactional information to a network device of a receiving entity for authorization processing, including the dynamic data without the static data (e.g., in a case where the dynamic data does not match the static data). As yet another example, remote verification processor 345 may communicate a different message to a receiving entity indicating that invalid dynamic data was received. The different message may be, for example, communicated to the entity from which the transactional data was received such that authorization is not performed.

[1192] According to some example embodiments, static data need not be used. For example, both an authorizing entity and remote verification processor 345 may expect dynamic data based on different equations. If the received dynamic data is valid, remote verification processor 345 may, for example, determine the dynamic data expected by the authorizing entity, and insert the expected data. If the received dynamic data is invalid, remote verification processor 345 may determine the dynamic data expected by the authorizing entity, and communicate data other than the data expected by the authorizing entity.

[1193] Remote verification processor 345 may store synchronization data used to adjust comparison data. Synchronization data may include, for example, an offset to a time determined at remote verification processor 345. The offset may compensate for timing signal differences between card 315 and remote verification processor 345.

[1194] The time determined at remote verification processor 345 may be modified by the offset and adjusted comparison data may be generated. The adjusted comparison data may be compared to the dynamic data. The offset may be used to adjust the time determined at remote verification processor 345, a received timestamp and/or a value based on the time determined at remote verification processor 345 and the received timestamp (e.g., modify a difference).

[1195] The offset may initially be, for example, a difference between a timing signal used by card 315 and a timing signal used by remote verification processor 345 at the time card 315 is manufactured. Card 315 may include a clock to generate a timing signal and/or may include an antenna and/or surface contacts to receive a timing signal from an external device. According to some example embodiments, the offset may initially be a difference between a timestamp received by remote verification processor 345 from card 315 and a time when the timestamp is received, either at the time of manufacture or otherwise. The timestamp and the time at remote verification processor 345 may each be based on any timing source, for example, a clock or a time service (e.g., NIST web clock).

[1196] The offset may be recalculated (modified or replaced), for example, at each transaction, after a period of time, at a time based on a drift rate of one or more clocks and/or at an arbitrary time. The offset may be recalculated based on a difference between a timestamp received from card 315 during a transaction and a time the transactional information is received by remote verification processor 345 (e.g., upon determining that the dynamic data is valid).

[1197] The offset, the time stamp, the time when the timestamp is received, and/or data based on the timestamp and the time when the timestamp is received, may be modified by network delays. A network delay may be an arbitrary value, a value reported by a network, and/or a measured value. The network delay may be a measured value received with the transactional information and/or a value determined by remote verification processor 345. For example, upon receiving the timestamp, remote verification processor 345 may measure network delay associated with transaction information by pinging mobile device 315 through the network element from which the timestamp was received. The delay may be determined based on the time between communicating the ping request and receiving a response from device 315. Absent network asymmetry, the delay may be divided in half and applied to the offset. However, if data traffic in one direction is slower than a different direction, routed along a different path, and/or any other asymmetry, the network delay may be determined based on the asymmetry. Any network characteristic may be used to determine network delay, for example, queue congestion, quality of service assignments, jitter differences, the time of day, the date, and/or the like.

[1198] According to some example embodiments, the offset may be replaced without recourse to prior data. According to other example embodiments, historical data may be used to determine a current offset. For example, an offset error algorithm using past data and new data may be used to determine a new offset. Past offsets may be used to calculate the new offset in order to reduce error due to potential variability in any factor causing a delay between a time at which card 315 generates a timestamp and a time the remote verification processor 345 determines a time, for example, an unmeasured delay or an erroneously measured delay.

[1199] According to some example embodiments, network delay may be applied to a difference between a current timestamp and the determined time, and the result used as an input to the offset error algorithm. According to other example embodiments, time difference data and network delay data may be stored, and one or both may be manipulated before being applied to the offset error algorithm as an input (e.g., in simple form, the offset error algorithm may receive averaged data as inputs).

[1200] According to some example embodiments, measurements of network characteristics and time differences may be stored by remote verification processor 345, and newly received times and measurements may by compared to the stored information to determine if differences between new data and historical data exceed respective minimum or maximum thresholds. If each individual difference does not exceed an associated minimum threshold or does exceed an associated maximum threshold, the data may be disregarded and the offset may remain the same, absent a data trend detected by remote verification processor 345. For example, a minimum threshold may indicate a negligible difference and a maximum threshold may indicate an outlier. According to some example embodiments, particular differences may be disregarded in determining the offset based on one or more thresholds such that only a portion of new data is used to recalculate the offset. Similarly, the differences may be combined and the combined differences may be compared to a single minimum and single maximum threshold to determine if offset recalculation will occur. Accordingly, computation resources may be conserved.

[1201] Merchant information may be used to at least temporarily (e.g., for a particular transaction) modify the offset or used as a separate offset. Merchant information may be communicated to remote verification processor 345, for example, with the information communicated by payment network 355. The merchant data may be used to determine merchant delay data associated with a particular merchant or a type of merchant using, for example, a database.

[1202] For example, if the determined difference between the timestamp and the time at remote verification processor 345 exceeds a threshold or results in an invalid comparison, remote verification processor 345 may determine the type of merchant from the merchant data. If the type of merchant is, for example, a merchant that delays transaction processing (e.g., batches transactions) or communication of the timestamp is otherwise delayed as a function of the type of merchant (e.g., manual entry related to online merchant 395), an additional offset may be applied or dynamic data verification may be waived.

[1203] Accordingly, for example, remote verification processor 345 may determine the time determined when the timestamp is received, modify the time with one or more offsets, and generate comparison data. The comparison data may be compared to the dynamic data to determine if the dynamic data is valid.

[1204] Persons of ordinary skill will appreciate that dynamic data verifications and/or time based evaluations by a remote verification processor permit dynamic data verification without requiring changes to existing infrastructure of financial institutions, including merchants, payment network 355, issuers 360, payment processors (not shown), merchant acquirers (not shown) and any other entity within the communication path of transaction data. Persons of ordinary skill will appreciate that synchronization by remote processor 345, without synchronization by card 315, includes multiple benefits. For example, power consumption at card 315 may be reduced. Further, network delays and merchant characteristics may be considered.

[1205] According to some example embodiments, remote verification processor 345 may perform timestamp verification. Timestamp verification may be performed by, for example, determining a difference between the timestamp received from card 315 and the time determined at remote verification processor 345, and comparing the difference to a threshold. If the time difference is invalid based on the threshold, the dynamic data may be determined invalid without generating the comparison data. Accordingly, a timestamp verification may be performed prior to verifying dynamic data and a message indicating that the dynamic data is invalid may be communicated to payment network 355 regardless of whether the dynamic data would otherwise be determined as valid. According to other example embodiments, both dynamic data verification and timestamp verification may be performed, and results of both verifications may be communicated to payment network 355.

[1206] As one non-limiting example, a network element within payment network 355 may receive transactional information from card 315 via mobile device 305 and any access infrastructure. The transactional information may include an identification number identifying card 315, a timestamp and dynamic data generated by a processor of card 315 using a private key and the timestamp. The dynamic data may be, for example, a dynamic CVC ("DCVC"). Payment network 315 may inspect the transactional information and determine that the transactional information includes the DCVC. The transactional information may be forwarded, or a portion of the transactional information may be communicated, to a remote facility, as a result of determining a DCVC is present.

[1207] The remote facility may be, for example, remote verification processor 345. Remote verification processor 345 may not be affiliated with conventional transaction processing entities and/or communication flows. For example, remote verification processor 345 may be a dynamic and/or powered card manufacturer producing feature cards, PIN cards, wallet cards and/or multi-brand cards. Remote verification processor 345 may perform other functions, may not be a card manufacturer and only verify dynamic codes, or may not be a card manufacturer and perform other functions besides dynamic code verification.

[1208] Remote verification processor 345 may determine a private key associated to card 315, as well as inputs to the private key not received from network 355 (if any), by comparing the identification number against stored information. For example, the identification number may be compared to information stored in a database associating identification numbers to private keys. The identification number may be unique and the stored information may include a private key uniquely associated with card 315. The identification number may be either unique or non-unique, and the stored information may include a private key associated with multiple cards, including card 315.

[1209] Remote verification processor 345 may generate comparison data using, for example, the determined private key, a time at which remote verification processor 345 receives the timestamp, and any other inputs to the a private key. The comparison data may be compared to the DCVC to determine whether the DCVC is valid. For example, if the comparison data and the DCVC are identical, or within an allowed range of DCVCs, the DCVC may be determined to be valid. The DCVC may be replaced with a CVC associated with the DCVC, and communicated to payment network 355 for authorization processing. If the DCVC is determined to be invalid, the transactional information (modified or unmodified to indicate invalidity) may be communicated to payment network 355 and/or a different type of message may be communicated. [1210] According to some example embodiments, only the static CVC may be communicated to payment network 355 and/or the static CVC may be included in a general message. The message may be in the same or different format from the message received by remote verification processor 345 from payment network 355. According to some example embodiments, as part of an ISO response, a formatted ISO message (e.g., a 110) may be communicated and the CVC placed in a field for security related information (field 53) or a field reserved for other uses (e.g., field 55 and/or field 56).

[1211] According to some example embodiments, remote verification processor 345 may receive a portion of transactional information and may communicate a message including the CVC to payment network 355. Payment network 355 may replace the DCVC in the original transactional information with the CVC received in the validation message, and communicate the transactional information to one or more of issuers 360 for full approval of the transaction. The issuer(s) may communicate a message approving or declining the transaction, or a portion of the transaction associated with the particular issuer, to payment network 355 for routing to mobile device 305.

[1212] If the DCVC is determined to be invalid, the transactional information (modified or unmodified to indicate invalidity) may be communicated to payment network 355 and/or a different type of message may be communicated.

[1213] According to some example embodiments, a full ISO authorization request, a JSON version, and/or an XML version may be communicated to remote verification processor 345 (0100 message types). Remote verification processor 345 may receive messages in ISO format, ASCII format, JSON format, XML format and/or another transaction format.

[1214] The transactional message may be communicated to remote verification processor 345 via, for example, web services (e.g., Rest based and/or SOAP based, with or without SAML) and/or direct socket point-to-point communication using an MPLS between data centers of remote verification processor 345 and data centers of payment network 355. A redundant MPLS line may be established to improve availability. Either a push or pull process may be used (e.g., transactional information may be pushed to remote verification processor 345).

[1215] According to some example embodiments, remote verification processor 345 may operate under the same guidelines as standard ISO message processing. Remote verification processor 345 may support all message types, including Network messages such as LogOn, Logoff and Heartbeats. The message may be encrypted using, for example, EBCDIC or ASCII encoding, and may utilize BitMap ISO functionality to determine which fields are being provided at a given time. Fields may be fixed or variable length, and may be BCD formatted as needed.

[1216] Remote verification processor 345 may respond to any message received with an ISO formatted message, including data from the original message. The ISO message may be formatted as a response message (e.g., a 110 in response to a 100). The fields included in the ISO message may be based on fields identified by payment network 355 to perform the appropriate processing. Remote verification processor 345 may perform a LogOn (message type 800) to initiate the flow of data to remote verification processor 345. Communication may flow in an asynchronous manner, even over a single connection. Information within the response may be utilized by payment network 355 to match the original authorization message to perform processing.

[1217] Upon authorization of a purchase, payment information may be recorded onto a receipt that may be delivered to mobile device 305 via any one or more delivery options (e.g., via a short messaging service of mobile network 330 and/or an email delivery service of IP network 340). A payment receipt may, for example, be provided to mobile device 305 as a proof-of-purchase object (e.g., a barcode) that may be provided to a display of mobile device 305 and read by other computing equipment (e.g., a barcode scanner) for proof-of-purchase confirmation.

[1218] Authorized transactions may be batched (e.g., aggregated) by mobile device 305 and/or by a merchant acquirer associated with mobile device 305. The batched transaction may be cleared by communicating (e.g., daily) the batched transactions to one or more of issuers 360 (routed by, for example, payment network 314), debiting the purchaser's account and communicating a monetary value from one or more of issuers 360 to mobile device 305 and/or to a merchant acquirer associated with mobile device 305. Funding may include mobile device 305 and/or a merchant acquirer associated with mobile device 305 notifying a user associated with mobile device 305 that funding has occurred and/or communicating the monetary value to mobile device 305 (and/or a financial institution associated with mobile device 305). Conventional communication flows may be used. Various fees may be deducted from the monetary value and paid to various entities during transactional processing. [1219] Device 370 may be, for example, a server, a laptop computer, a PDA, a desktop computer, a mobile device, a stand-alone piece of electronic equipment, and/or the like. Contactless device 380 may be, for example, a powered card and/or a non-powered card (e.g., a powered payment card and/or a non-powered payment card). Device card 375 may be a virtual representation of contactless device 380 or may be an independent device card. Device 370 may include a contactless interface that may initiate, sustain, and/or terminate communication channel 385 between contactless device 380 and device 370. Contactless device 380 and device 370 may communicate via channel 385 using any number of contactless mediums, which may include for example, visible, audible, capacitive, electromagnetic, magnetic, and/or RF mediums.

[1220] Contactless device 380 may communicate at least a portion of transactional information to device 370 to initiate a financial transaction (e.g., a purchase) using, for example, an IC chip, RFID tag a magnetic stripe, and/or a dynamic magnetic stripe communications device. Information may be communicated from contactless device 380 to device 370 in support of, for example, processing of the financial transaction. For example, device 370 may communicate transactional information, merchant data and/or transaction specific data to remote verification processor 345. Remote verification processor 345 may verify that a dynamic code (e.g., a CVV and/or CID) included in transactional information is valid. Remote verification processor 345 may verify the dynamic code, replace the dynamic code with a static code, and communicate the modified transactional data to one or more of issuers 360 for authorization of the transaction. One or more of issuers 360 may communicate the authorization to device 370. The user may be provided a receipt upon authorization of the financial transaction.

[1221] Device 370 may batch the authorized transaction with other transactions and communicate the batched transactions to one or more of issuers 360, and/or a merchant acquirer of device 370 may batch the transactions. Device 370 and/or a merchant acquirer of device 370 may request payment from one or more of issuers 360. The one or more issuers 360 may communicate a monetary value to device 370 and/or a merchant acquirer of device 370, and debit the user's account. The one or more issuers 360 may communicate the monetary value to device 370 and/or notify device 370 that funding has occurred. Conventional communication flows may be used. Various fees may be deducted from the monetary value and paid to various entities during transactional processing. [1222] FIG. 84 shows transaction verification methods according to principles of the present invention. Referring to FIG. 84, an account provider (e.g., a credit issuer) may generate one or more functions for dynamic code generation (e.g., as in 405). The account provider may associate the function(s) to one or more accounts (e.g., as in 410) and communicate account information including the function(s), or data associated with the function(s) to a card manufacturer (e.g., as in 415). The card manufacturer may be a separate entity from the account provider and/or the same entity. Persons skilled in the art will appreciate that no communication may occur in a case where the account provider and card manufacturer are a same entity. [1223] The card manufacturer may receive the account information and generate a card (e.g., as in 420 and 425). The card may be, for example, a powered card and/or a device card. The card and/or device may include a clock and the account information. For example, a card may include a timestamp generator, the function(s) and/or data associated with a function(s) (e.g., information stored in a LUT including data determined using function(s)), an identifier and/or other private and/or public information. The identifier may be a user identification, an account identification, a card identification and/or the like.

[1224] The card may be provided to the user of the account associated with the card (e.g., as in 430). The user may use the card to initiate a transaction. For example, the user may initiate a transaction with a card reader using the card. The card may generate a timestamp, and generate dynamic data and/or select data from storage. For example, the card may determine a solution using the function(s), the timestamp, and/or other data to generate or determine a dynamic code.

[1225] An entity processing the transaction (e.g., an acquirer and/or issuer) may receive transactional data including the identifier, the dynamic code, one or more functions, the timestamp and/or other data (e.g., as in 435). The entity processing the transaction may determine that the transactional information includes dynamic data, and communicate some or all of the information to a dynamic data verification server. The dynamic data verification server may retrieve a function(s) or select a verification code (e.g., from local secure storage) using the identifier and the timestamp. If any function is retrieved, a solution or a range of solutions to the function(s) may be determined to obtain a verification code. The verification code may be compared to the dynamic code to determine a result based on a degree of similarity (e.g., a match to a solution or a match within a range of codes) between the verification and dynamic codes (e.g., as in 440). The result may indicate whether a dynamic number is valid and may be communicated, for example, to a card reader (e.g., as in 445).

[1226] According to example embodiments, verifying dynamic data may reduce unauthorized use of an account (e.g., unauthorized by a user), for example, without a requirement of bi-directional communication between a device (e.g., a powered card and/or mobile telephonic device) and a processing entity. Facility-based synchronization between a card and a verification facility may reduce power consumption at the card and/or mobile device. Information not available or accessible by a card may be used in the synchronization process. The verification facility may be a remote facility, and may not be a conventional transactional entity, such that conventional transactional entities need not upgrade existing equipment and/or perform fewer or smaller upgrades as compared to without the verification facility. Multiple, different issuers may utilize a single verification processor, resulting in an increased reduction in infrastructure modification.

[1227] Persons skilled in the art will appreciate that various elements of different example embodiments may be combined in various ways. Persons skilled in the art will also appreciate that the present invention is not limited to only the embodiments described. Instead, the present invention more generally involves dynamic information. Persons skilled in the art will also appreciate that the apparatus of the present invention may be implemented in other ways than those described herein. All such modifications are within the scope of the present invention, which is limited only by the claims that follow.

[1228] FIG. 85 shows cards 500 and 550 according to principles of the present invention. Card 500 may be, for example, between 25 and 40 thousandths of an inch thick (e.g., approximately between 30 and 33 thousandths of an inch thick). Card 500 may include, for example, layer 510. Layer 510 may be a polymer, for example, polyethelene terephthalate and/or the like. Similarly, layer 515 may be included as a polymer, for example, polyethelene terephthalate and/or the like. An electronics package may be fixed (e.g., glued) to layer 515 or 510, and laminated via injection molding (e.g., reaction injection molding) to form laminate 511. Laminate 512 may be formed from one or more polyurethane- based or silicon-based substances.

[1229] To fabricate a card that is approximately 30 to 33 thousandths of an inch thick, for example, layer 515 and 510 may be approximately 5 to 7 thousandths of an inch thick (e.g., 5 thousandths of an inch thick). An electronics package may be less than approximately 10 to 20 thousandths of an inch thick (e.g., less than approximately 16 thousandths of an inch thick). Accordingly, for example, an area of laminate 511 between an electronics package and a layer may be a thickness such that an electronics package, layers 510 and 515 are approximately 33 thousandths of an inch thick. For example, laminate 511 may be approximately 3 to 10 thousandths of an inch thick (e.g., approximately 7 thousandths of an inch thick).

[1230] The volume of the electronics package of a powered card may be, for example, less than approximately two tenths of a cubic square inch (e.g., approximately less than one tenth of a cubic square inch). Such an electronics package may include multiple flexible boards, a battery, dynamic magnetic stripe communications device, magnetic stripe communications device drive circuitry, and multiple light emitting diodes.

[1231] Persons skilled in the art will appreciate that a protective layer may be placed over layer 510 and 515. Such a layer may be between approximately 0.5 and 2 thousandths of an inch thick (e.g., approximately 1.5 thousandths of an inch thick). Accordingly, for example, the combined thickness of two protective layers may be approximately 3 thousandths of an inch, the combined thickness of two exterior layers may be approximately 10 thousands of an inch, the thickness of an electronics package may be approximately 16 thousandths of an inch, and the thickness of a laminate between an electronics package and an exterior layer may be approximately 4 thousands of an inch. Persons skilled in the art will also appreciate that an injection molding process of a substance may allow that substance to fill into the groove and gaps of an electronics package such that the laminate may reside, for example, between components of an electronics package.

[1232] Card 500 may include an electronics package that includes, for example, board 512, processor 516, display 517, buttons 518, additional circuitry 519, board 513, and battery 514. Board 512 may be, for example, a dynamic magnetic communications device. A permanent magnet may be, for example, provided as part of an assembled board 512 or fixed (e.g., flexibly fixed) to the top of board 512. Board 513 may include, for example, capacitive and/or inductive read-head detectors placed about board 512. Battery 514 may be any type of battery, such as, for example, a flexible lithium polymer battery. Circuitry 519 may include, for example, one or more driver circuits (e.g., for a magnetic communications device and display 517), RFIDs, IC chips, wireless radio transceivers, light sensors and light receivers (e.g., for sending and communicating data via optical information signals), sound sensors and sound receivers, or any other component or circuitry for card 500. Read- head detectors for detecting the read-head of a magnetic stripe reader may be provided, for example, on board 512 and/or 514 as capacitive proximity sensors (e.g., capacitive-sensing contact plates) and/or inductive conductor sensors.

[1233] Circuitry 519 may include, for example, a chip including a display drive circuit. The drive circuit may drive display 517, for example, display units (e.g., segments) of display 517. Processor 516 may control the drive circuit.

[1234] Components on a board may be connected, for example, via surface mount assembly techniques, wire- bonding assembly techniques, and/or flip chip assembly techniques.

[1235] Display 517 may be on display board 520. Display board 520, processor 516 and the display driver of circuitry 519 may be on different portions of board 513. Processor 516 may be connected to the driver circuit via board 513. Display 517 may be connected to the display driver of circuitry 519 via display board 520 and board 513. The number of connections between the display and display board 520, between display board 520 and board 513, and between board 513 and the display driver may be related to, among other factors, the number of display units (e.g., segments) of display 517.

[1236] The display used for display 517 may be limited to a particular size or a particular number of display units (e.g., segments), and/or a card manufacturing process may be more complicated for enhanced and/or large footprint displays. Due to the number of connections required between display board 520 and board 513, and between board 513 and the drive circuitry, a manufacturing process to include a enhanced and/or large display in card 500 may require additional and/or more expensive equipment, consume more material, require greater processing times, have decreased line yield and/or increased failure rates.

[1237] Card 550 may be provided and may include, for example, exterior layers 551 and 554, laminate 552, board 553, battery 559, processor 555, display 556, buttons 557, circuitry 558, board 560 and display board 561. Circuitry 558 may include, for example, drive circuitry for a dynamic magnetic stripe communications device, programming sensors (e.g., infrared sensors), and light emitting diodes.

[1238] Display 556 may be an enhanced display, an improved display, and/or a large footprint display. Drive circuitry for display 556 may be on and/or in display board 561. Display 556 may be connected to the drive circuitry directly and/or by fabricating the connections directly on display board 561, for example, using a printed circuit board fabrication technique. Display 556 may be connected to drive circuitry without connecting via board 560 (without connecting via a primary board). Processor 555 may be connected to the drive circuitry of display board 561 via display board 561 and/or board 560.

[1239] A number of required connections between display board 561 and board 560 may be reduced as compared to a card with a display driver on board 560 by a factor of about 5. For example, if 10-20 connections are required for a display driver on (or in) display board 561, 50-100 connections may be required if display driver is on board 560.

[1240] According to example embodiments, a large, improved and/or enhanced display may be included in card 550 using an existing manufacturing process, or with process that is less complicated than for a card with a display driver on a primary board. Card 550 may be more durable, with fewer potential points of failure. The amount of space (real estate) available within card 550 for routing additional components may be increased and/or a card design may be less complicated. Display 125 may be a 1 inch by 1 inch display, a 1 inch by 1.5 inch display, a 1 inch by 2 inch display, and/or the like.

[1241] FIG. 86 shows device 600 according to principles of the current invention. Device 600 may be, for example, a multi-instrument device including display 610, on/off button 620 and/or toggle button 630.

Device 600 may act as a surrogate for multiple different instruments, for example, a credit card, a debit card, a stored value card, a driver's license, a passport, an access card, a transportation card, a loyalty card, a rewards card, an incentive card, a coupon, a gift card, a game action card and/or any other instrument.

[1242] Device 600 may include multiple different communication interfaces compatible with multiple different types of devices (e.g., readers). For example, device 600 may include a dynamic magnetic stripe to communicate with a magnetic stripe reader, an exposed chip interface to communicate with a contact smartcard reader, an unexposed chip interface to communicate with a contactless smartcard reader, an EMV reader compatible interface, an RFID interface to communicate with an RFID reader, a NFC interface to communicate with an NFC reader, a Bluetooth interface to communicate with a Bluetooth device, a IC radio module to receive from or communicate with a radio device, a light receiver and/or transceiver to receive from or communicate with a light based device (e.g., a display screen), a capacitive touch interface to communicate with a touch interface (e.g, a touch screen) and/or the like.

[1243] Device 600 may communicate and/or receive information during, before or after a transaction (e.g., at any time) using any communication interface included with device 600. For example, device 600 may be swiped through a magnetic stripe card reader during a purchase transaction and may communicate magnetic stripe data using a dynamic magnetic communications device.

[1244] As another example, device 600 may include an IC radio module and may receive various types of information from a radio broadcaster (e.g., a pager system). The types of information may include new card data, an update to an expired card, an instruction to delete one or more cards, an instruction to deactivate device 600 (e.g., where device 600 is compromised), an instruction to add a new reward or feature, an instruction to notify a user of a new sale or bonus item, an instruction to display advertising information (e.g., from a card reader and/or a public venue broadcasting system), an instruction to update firmware, an instruction to activate an inactive product, an instruction to increase or decrease card spending limits and/or an instruction to activate or deactivate features under subscription model.

[1245] Display 610 may be an enhanced display, an improved display and/or a large footprint display. Display 610 may be, for example, a multi-segment, a multiline display, a dot matrix display and/or the like. Display 610 may be sized according to an ISO standard device 600, and may be, for example, 1 inch by 1 inch, 1 inch by 1.5 inches and/or 1 inch by 2 inches. According to some example embodiments, device 600 may not be sized according to ISO standards and a size of display 610 may be compatible with the non-standard size. Display 610 may be variously located with respect to edges of device 600. For example, device 600 may be centered, left justified, right justified, top justified, bottom justified and/or vertically justified.

[1246] According to some example embodiments, display 610 may be a multiline display including two or more lines of 5-20 characters per line, for example, 9 characters per line, 10 characters per line and/or 18 characters per line.

[1247] Toggle button 630 may toggle display 610 between different display screens. For example, a user may press power button 620 and a first display screen may be displayed. Device 600 may automatically switch to a second display screen, and thereafter periodically switch between the first and second display screens. A length of time device 600 displays the first display screen and a length of time device 600 displays the second display screen may be different or the same. For example, device 600 may display the second display screen for a longer period of time in a case where the second display screen includes information that is more difficult for a user to retain in short term memory, and vice versa. According to some example embodiments, device 600 may display three or more display screens and automatically switch between two or more of the display screens.

[1248] A display screen may be information simultaneously displayed by display 610. For example, display 610 may be a two line display with two 10-digit lines. A first display screen may include the name of a card type identifier (e.g., BankName/Debit), an expiration date, and a CVC (e.g., a CVV, CVV2, CVC, CVC2, CID and/or DCVC). The second display screen may display, for example, a 15 or 16 digit card number. The card number may be displayed using both lines of the second display screen.

[1249] A user may press toggle button 630 and device 600 may display information associated with a different instrument. For example, a user may press toggle button 630 to display a first display screen associated with a different card. Display 610 may display the name (e.g., MerchantName/GiftCard) and other information related to the different card. Device 600 may automatically switch to a second display screen of the different card, for example, including a 15 or 16 digit card number.

[1250] Device 600 may periodically toggle between display screens, for example, while device 600 is on and/or for a period of time. Device 600 may turn off and/or cease to display information after an event. For example, device 600 may turn off, or turn display 610 off, after a transaction, after a communication is acknowledged and/or based on user input (or lack of input).

[1251] The user may press toggle button 630 a second time and device 600 may display a first display screen associated with a driver's license. The first display screen may display information related to the driver's license. For example, display 610 may display the name (e.g., State Name/Driver's License) driver's license number, license class, and expiration date when the first display screen is displayed. Device 600 may automatically toggle to a second display screen, for example, displaying physical characteristics of the user, such as height, weight, hair color and and eye color. Device 600 may automatically toggle to a third display screen, for example, displaying license requirements, for example, whether or not the user is required to wear corrective lenses. Device 600 may automatically toggle to a fourth display screen to display a validation code that may be used to authenticate the driver's license data (e.g., in lieu of a hologram).

[1252] A user may press toggle button 630 to switch between every instrument stored in device 600 and/or a subset of instruments stored in device 600. For example, a user may group instruments stored in device 600 via a graphical user interface on a mobile device (e.g., a mobile telephonic device) and may name the groups. For example, a user may group rewards cards group "Rewards," access cards in group "Access," and payment cards in group "Financial." The mobile device may provide grouping instructions to card 360, for example, through a communication interface. A user may switch between groups of toggled instruments by, for example, pressing toggle button 630 for a period of time (e.g., 2-4 seconds) and/or a number of times in quick succession (e.g., 2-4 times). Device 600 may display grouping information in the instrument name (e.g., "BankName/Credit/Financial"). Once a group is selected, a user may toggle through the selected group by pressing toggle button 630 for less than 2 seconds.

[1253] According to example embodiments, a card may display more than one screen of card data for a particular card such that a user may access instrument data exceeding a number of segments displayable by display 610. Display 610 may display 2 times the number of symbols displayable by the display by toggling between two display screens, 3 times the number of symbols by toggling between three display screens, 4 times the number of symbols by toggling between four display screens, and so on. For example, a user in possession of device 600 including a two line, 16 segment display (i.e., 8 segments per line) may have access to 32 segments with two display screens, 48 segments with three display screen and 64 segments with three display screens.

[1254] A user may press toggle button 630 one or more times to select a particular instrument from among multiple instruments, and device 600 may communicate data to a reader or other device based on the currently displayed instrument. For example, device 600 may begin communicating data upon detecting a reader and/or upon detecting that a user has not switched between cards for a period of time (e.g., a static period of time and/or a multiple of the average time a user takes to switch between cards). [1255] Device 600 may communicate data in a format expected by a type of reader. Device 600 may include reader detectors (not shown) to detect a type of reader and communicate transaction information associated with the selected card in the format expected by the type of reader. For example, device 600 may communicate data in a different format to each of a passport reader, a barcode scanner, a smart card reader, a magnetic stripe reader and/or the like.

[1256] Different formats or versions of data associated with the same underlying account may be stored on device 600, and/or device 600 may ble messages from stored data based on the detected or user selected reader. For example, ISO compliant data may be stored in device 600 as different transaction messages for a particular card (e.g., in a LUT). Device 600 may detect a particular type of reader and select a transaction message for communication based on the type of card reader and the card displayed by display 610. As another example, card 610 may include a processor and instruction sets for assembling messages based on the type of card reader. Device 600 may detect a particular type of card reader and assemble a transactional message for communication based on an instruction set associated with the type of card reader and underlying transactional information associated with a card displayed on display 610.

[1257] For example, device 600 may detect a smartcard reader and select a message associated with the selected card in a format compliant with ISO standards for smartcards. As another example, device 600 may detect a magnetic stripe reader, and use an algorithm to compose a message for the selected card in a format compliant with ISO standard for magnetic stripe cards. If the selected card is a dynamic card, device 600 may, for example, assemble the message using dynamic data in place of static data (e.g., use a DCVC in place of a CVC).

[1258] According to example embodiments, if device 600 detects a device requiring a token, the token may be generated or retrieved from memory, and communicated to the external device.

[1259] Device 600 may, for example, receive a selection of a type of reader from a user and communicate transactional information associated with the selected instrument in the format of the selected reader. For example, a user may toggle between sets of information for the same card. The name of the instrument may be displayed as, for example, 'Name/CardType/ReaderType.' A user may press toggle button 630 a number of times in rapid succession to switch between groups of instruments, press toggle button 630 for less than one second to toggle between cards, and press toggle button 630 for a number of seconds to toggle between card reader types associated with the card (e.g., 1-3 seconds), and press toggle button 630 and power button 620 simultaneously for a different function. If the user presses toggle button for a number of seconds, a different set of display screens for the same account but a different card reader type may be displayed. Alternatively, only the name of the instrument may change to reflect the currently selected type of reader.

[1260] According to some example embodiments, a user may toggle between card reader types when, for example, device 600 does not detect a particular card reader (e.g., a new kind of reader), the card reader is undetectable (e.g., receive-only wireless), and/or a card reader accepts multiple different formats of payment information and the user prefers a particular format. Similarly, a different entity, such as an issuer, may store a preference hierarchy for card reader types on device 600.

[1261] A default reader type may be set by a card manufacturer, an issuer and or a user, for example, based on a location in which the card will be used and/or a current location of the card. For example, an issuer may issue a card to a resident of the United states and set a default of communicating via a dynamic magnetic stripe communication device using the associated ISO compliant transaction message. As another example, device 600 may include a location device (e.g., a GPS or Wi-Fi receiver/transceiver) to determine a current location of card 360. For example, device 600 may include a GPS determining that device 600 is currently in Europe, and by default, device 600 may communicate data by contact and/or contactless smart card interfaces using the associated ISO compliant transaction message. As another example, device 600 may include a Wi-Fi transceiver, connect to a Wi-Fi hotspot and determine that device 600 is in Canada based on an IP address of the hotspot. Readers in Canada may accept magnetic stripe data or smart card data. A default hierarchy provided by an issuer may set device 600 to first attempt to communicate by a smartcard interface when a dual interface reader is detected.

[1262] According to example embodiments, a powered and/or dynamic card may store and display information for more than a single card, and may provide static and/or dynamic information for transactions. Displayed data may be used to complete transactions, for example, requiring manual entry of data and/or occurring at a location with limited access to financial transaction systems. Examples of such transactions may include, for example, a transaction with an internet merchant, a transaction with a merchant recording card information manually (e.g., by imprinter), a transaction with a retail merchant having a broken or disconnected reader, and/or the like.

[1263] Although device 600 is shown with two buttons, additional buttons may be provided. For example, a number of buttons may be provided to enter an unlocking code. Display 610 may switch to an unlocking display screen when, for example, a user begins to enter an unlocking code or when power button 620 is pressed. The unlocking code display screen may or may not display the symbols entered using the buttons, and may display messages associated with a successful or unsuccessful entry of an unlocking code. As another example, display 610 may perform various functions with respect to single accounts associated with different buttons or sets of toggled accounts associated with different buttons. According to some example embodiments, a button may be used to toggle display screens and cards. For example, a button may be pressed to switch through each display screen of a first card, and upon reaching the last display screen of the first card, the next button press may cause display 610 to display the first screen of the second card.

[1264] According to some example embodiments, device 600 may receive, store and communicate open network cards that may be communicated through more than one payment network. An open network card may be received by device 600 via any communication interface, for example, a Bluetooth interface. Device 600 may include printed network logos for each payment network, for example, four network logos. Device 600 may backlight a logo of the network associated with the currently selected card, and/or backlight each payment network associated with an open network card.

[1265] FIG. 87 shows a token transaction method performed in accordance with the principles of the present invention. Referring to FIG. 87, a user may initiate a tokenization process required to utilize a transaction card with a multi-card device (e.g., as in step 705). The process may be initiated by uploading card data associated with the transaction card to a user computing device (e.g., a mobile telephonic device, a PDA, a laptop and/or a desktop computer) and communicating the card data to a multi-card provider (e.g., a provider of a multi-card application and/or a provider of a multi-card device, such as a dynamic and/or powered card manufacturer and/or retailer).

[1266] For example, the transaction card may be a magnetic stripe card, such as credit or debit card. The user may upload the card data to the user's computing device by, for example, manually entering the card data into the computing device, obtaining the card data using a card reader connected to the computing device (e.g., a card reader provided by the multi-card provider), capturing one or more images of the card for OCR recognition (e.g., using a camera of the computing device) and/or verbally entering the card data using a voice recognition function of the computing device. Once the card data is uploaded, the user may communicate the card data to the multi-card provider by, for example, communicating the card data over an IP network to a processing server (e.g., as in step 710).

[1267] A verification process may be performed to determine if the user is associated with the card data and/or a financial institution is associated with the card data (e.g., as in step 715). For example, the user and/or the multi-card provider may connect with, for example, a payment network and/or a financial institution (e.g., a bank and/or issuer) associated with the card data. For example, the multi-card provider may connect via web services and/or a direct socket point-to-point connection, and the user may log-in using a log-in identity associated with the payment network, the financial institution and/or the multi-card provided by the multi-card provider. According to some example embodiments, the user may, additionally or alternatively, use the transaction card with a reader. For example, the user may swipe the transaction card at a point-of-sale device.

[1268] Upon completion of the verification process, the user may receive one or more tokens (e.g., as in step 720). For example, the payment network and/or the financial institution may communicate one or more tokens to the multi-card provider and/or the user mobile device. For example, the token may be directly usable by an application residing on the user's computing device, the multi-card provider may embed the token into an application and communicate the application to the user's computing device, the token and any required firmware/software may be communicated from the multi-card provider to the user's multi-card device, and/or the multi-card provider may provide a complete multi-card device (e.g., including the token) to the user (e.g., as in step 720). The user may conduct a transaction and the token may be communicated for authorization of the transaction (e.g., as in step 725).

[1269] According to some example embodiments, one or more tokens may be retrieved by a multi-card device or application during a transaction, or a simulated transaction. For example, one or more tokens may be downloaded to a multi-card device that is used at a card reader (e.g., a point-of-sale IC chip and/or magnetic stripe card reader). Accordingly, tokens may be changed at any time. For example, a payment network and/or financial institution may change a token periodically. Compromised tokens may be replaced. Card expirations may be transparent to a user.

[1270] According to example embodiments, a single token may be provided. According to other example embodiments multiple tokens may be provided. Different tokens may be provided for different types of transactions. Different tokens may be provided for different communication interface based transactions (e.g., EMV, magnetic stripe, etc.). For example, different tokens may be provided for secure connections and unsecured connections of a multi-card application (e.g., an application residing on a user's computing device). As another example, different tokens may be provided for wired and wireless connections of the user's mobile device and/or multi-card device. As yet another example, a different token may be provided for secure internet transactions, unsecure internet transactions, identity verified point-of-sale transactions (e.g., signature, photo ID, etc.) and/or identity unverified point-of-sale transactions. As still another example, different tokens may be provided for transactions via different card readers (e.g., a square reader v. a VeriFone reader) and/or transactions at different locations (e.g., domestic, international, country, state and/or city, for example, based on fraud data). As still yet another example, different tokens may be provided for one or more (e.g., some, groupings, or all) of dynamic magnetic stripe transactions, exposed chip transactions, unexposed chip transactions, EMV transactions, RFID transactions, NFC transactions, Bluetooth transactions, transactions using an IC radio module, light-based transactions (e.g., infrared), capacitive touch interface transactions, and/or any other communication interface based transaction.

[1271] According to example embodiments, the information downloaded to a multi-card device or multi- card application may include unique payment card data, for example, one or more unique card numbers, such that the unique data resides on the multi-card. Accordingly, if data is compromised during one type of transaction, the token may be determined invalid, and a user may continue to complete other types of transactions. For example, a unique card number may be used for each of contact IC transactions, contactless IC transactions, and dynamic magnetic stripe transactions. A token used for dynamic magnetic stripe transactions may be compromised (e.g., by skimming), a payment network and/or financial institution may invalidate the token. Future transactions using the invalidated token will be declined and future transactions using tokens assigned to contact or contactless IC transactions will continue to be accepted. Further, a payment network or financial institution may invalidate a token assigned to one type of transaction (e.g., magnetic stripe reader transactions) that unexpectedly appears in a different type of transaction (e.g., an online transaction), such that the magnet stipe reader transaction token may no longer be used.

[1272] FIG. 88 shows card 800 according to the principles of the present invention. Reference numeral 810 may show card 800 during a first period of time and reference numeral 820 may show card 800 at a second period of time. Referring to FIG. 88, a portion of a dynamic card number may be displayed on display 815 during the first time period and a dynamic security code may be displayed on display 815 during the second time period. For example, a user may activate card 800, and display 815 may automatically switch between display of the portion of the dynamic card number and the display of the dynamic security code, for example, periodically. As another example, a user may toggle between displaying the portion of the dynamic card number and displaying the dynamic security code using one of buttons 131-137.

[1273] According to some example embodiments, a payment card or other device such as a payment phone or watch, can interact with a point-of-sale terminal to complete a transaction. Multiple stages of communications from the payment device to the payment terminal and from the payment terminal to the payment device may be provided so that each device or process may identify itself to the other, securely confirm the other's identity is authorized to conduct a transaction, and provide information for the authorization of a payment transaction. The point-of-sale terminal may route such communications to/from a merchant processor which may route parts of the communication to/from a payment network process, which may route part of the communications to/from an issuing processor that issued the payment device to the end consumer.

[1274] The transaction may be communication between the payment device and point-of-sale terminal, for example, a contact chip connection, a contact or wireless magnetic stripe connection, a contactless connection, or through a visible connection such as a single-stage or multiple stage barcode or QR code. A multiple-stage barcode may be a barcode that changes the information displayed throughout a payment transaction process so that multiple different types of information are displayed at different times over the same display area.

[1275] During a transaction, a payment device may request information. This information may include, the amount authorized, additional monetary amounts, the country code of the terminal, the terminal verification results, the transaction currency code, the transaction data, the transaction type, the data authentication code, the iCC dynamic number, the CVM results, the transaction time, merchant custom data, transaction date, tvr, unpredictable number, whether the transaction was authorized or declined, or any type of data retrievable by the payment card.

[1276] A payment card may be battery-powered or non- battery powered and may include buttons to permit a consumer to select different payment accounts (e.g., debit, credit, pre-paid), payment options (e.g., pay with points, pay with unequal payments, or equal monthly payments, for example, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 36, 39, 42, 45, and/or 48 monthly payments, or other payment features (e.g., a password-entry system where a correct password may be needed to use the card to complete a purchase). [1277] The payment devices may include multiple processors, for example two or more payments processors and/or secure memory elements (e.g., exposed IC chip processors). As another example, a general processor for managing the general operation of the device and one or more payments processors or secure memory elements for managing all or part of the payment data and payment process of the device.

[1278] Data not associated with the direct authorization of a payment may be copied from information requested from the payment device and stored and utilized for non- payment or payment features.

[1279] For example, a device may have a display such as a pixelated display operable of displaying a cardholders payment network logo, cardholder name, payment account number, payment expiration date, payment security code for online transactions (e.g., CVV2, CVC2), card name, and other pieces of information.

[1280] Messages associated with a particular time and/or date may be pre-stored. For example, messages associated with an anniversary date of the issuance of the card, consumer birthday information, country holidays, religious events, or any notification or message associated with a particular time or date. For example, a message wishing the consumer a happy birthday and providing the consumer with a QR code coupon for a certain amount in value may be displayed based on a date received during a payment transaction (and, for example, a clock in the payment device that updates the stored date as time passes). Persons skilled in the art will appreciate that a birthday event may trigger a feature such as a game feature where a consumer gets to pick a gift box from a number of gift boxes where each or one ore of the gift boxes has a different amount or type of value stored in it. Accordingly, a marketing campaign may be provided where on your birthday you have the chance to win a statement credit for your payment card bill in different amounts based on, for example, an instant no-purchase necessary sweepstakes where on the cardholder's birthday the cardholder is provided instant statement credit value based on different odds of receiving different amounts of value. Pre-stored messages based on time could be provided so that a different message is released at a particular time (e.g., 9am EST) every day. Date-based messages could include for example, New Years, Christmas, Ramadan, each day of Hanukkah, Memorial Day, Independence Day, Election Day, etc.

[1281] Messages may be displayed on the payment device for example based on the first authorized transaction after a certain date/time. For example, a message may be pre-stored and displayed on the first authorized transaction after the first year of being issued the payment device or payment account on the payment device.

[1282] Payment devices, such as payment cards, may include, for example, one or more displays, light emitting diodes, programmable magnetic stripes that can change the magnetic stripe data on the magnetic stripe, programmable EMV chips, programmable contactless chips, cellular chips and antennas for downloading data from a remote source, manual interfaces, sound interfaces, etc.

[1283] Security features may be provided based on the received data. For example, a dynamic security code may be changed based on time and/or date information received from the payment device during an authorization transaction on a two-way authorization process (e.g., via an EMV or contactless transaction). The dynamic security code may provide a dynamic in-stripe security code (e.g., CVC1/CV1) and on-line security code (e.g., CVC2/CVV2). They may be the same or different security codes based on time and/or date or other information received and multiple types of information received (e.g., a different code may be provided based on time and country information received during a payment transaction).

[1284] Pre-stored messages may be provided based on any information received such as, for example, country code. A welcome message may be provided after a consumer makes a payment transaction in a new country that welcomes the user to the country and provides the consumer with payment information (e.g., exchange rates) based on that country. After each authorized transaction, for example, a card may display information on the transaction (e.g., amount of the transaction) in both the local and foreign currency by using information received and/or logic on the card.

[1285] Transaction applets may be provided that changes the account or payment option information based on what was received during the transaction. For example, if a US card account is utilized in Spain then the card may change the account to a Spanish account for future transactions (unless otherwise directed by the cardholder). In doing so, the payment device can receive information and change the way the payment devices operated based on the received information.

[1286] Any information could enable a new account (e.g., debit credit) or payment option (e.g., EMI, pay with points) for the current or a future transaction. A card can terminate a transaction based on information received and start a subsequent transaction (e.g., by having the cardholder remove and replace the card in a chip contact reader or reinstitute a new contactless transaction, etc. Persons skilled in the art will appreciate that payment terminals can be constructed to reinstitute transactions automatically if a transaction fails.

[1287] Example types of information receivable to cause modification of an applet, or by an applet, may include, for example:

Amount, Authorized (Numeric)

Amount, Other (Numeric)

Terminal Country Code

Terminal Verification Results

Transaction Currency Code

Transaction Data

Transaction Type

Data Authenticiation Code

ICC Dynamic Number

CVM Results

Transaction Time

Merchant Custom Data

Transaction Currency Code

Transaction Date

Transaction Type TVR

Unpredictable Number

[1288] According to example embodiments, methods of personalization and personalization updates to credit cards in the field are disclosed.

[1289] Perso Data Encryption. According to some example embodiments, encrypted personalization data may be sent over a transmission link (e.g., cell network, Bluetooth, NFC, etc.). A perso data block may have a unique session identifier preprogrammed into a secure element (SE) which may be used as part of an decryption process. [1290] Data may be encrypted at multiple levels. For example, a two level embodiment may include transmission link encryption. An entire block of perso data may be encrypted (e.g., 3DES, AES, etc.) during transmission. This block may be decrypted by, for example, a general purpose processor (GP). The GP may use a unique Session Identifier to request the transmission decryption key from the Secure Element.

[1291] Such a two level embodiment may further include encryption of sensitive perso data (personal data of a cardholder) - sensitive perso data such as UDKs may be encrypted such that they will never be in the clear. This information may be sent encrypted to the SE (such as a secure element chip) and may be decrypted inside the Secure Element. This decryption process may be performed by an applet installed on the SE.

[1292] Cards may be preloaded with sets of keys in the SE that are associated with: Transmission Link Key - This key may be utilized by the GP to decrypt the entire perso data block that was received. The GP may provide the unique session identifier provided with the perso data Block to the SE such that the appropriate key can be provided. Multiple unique transmission keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades can be performed over the life of the card. This process may be protected from attacks by, for example, only allowing three attempts to request the transmission link key and if the proper unique session identifier is not provided within three attempts, the process may be blocked going forward. Sensitive Perso Data Key - This key may be utilized by the SE to decrypt sensitive perso data. The unique session identifier may be provided to the SE to be able identify the proper preloaded keys to decrypt the sensitive perso data. Multiple unique sensitive perso data keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades may be performed over the life of a card. This process may be protected from attacks by only allowing three attempts to provide a unique session identifier and if the proper unique session identifier is not provided within three attempts, the process will be blocked going forward.

[1293] Preloaded Perso Data. Acording to some example embodiments, preloading either multiple entire sets of perso data or multiple partial sets of perso data (which may be unique to this card) which may be triggered to be used by sending a signal to the card over a transmission link (e.g., cell network, Bluetooth, NFC, etc.) to change account information.

[1294] Complete sets of Perso Data - Multiple sets of Perso Data which may include changes based on an update to PAN sequence number only or entirely different PANs can be preloaded on the SE. Each of the accounts may be associated with a Unique Account Identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the Unique Account Identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward. [0171] Partial Sets of Perso Data - In order to minimize the amount of data preloaded, only the unique data associated with an account upgrade (PAN, UDKs, certificates, etc.) may be preloaded. Multiple partial sets of Perso Data which may, for example, include changes based on an update to PAN sequence number only or entirely different PANs may be preloaded on the SE. Each of the Partial Sets of Perso Data may be associated with a unique account identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the unique account identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that Account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward.

[1295] FIGs. 9-11 show devices according to principles of the present invention. Referring to FIGS. 9-10, a card may have one or more contact chips (e.g., EMV chips 905 and 910), one or more magnetic stripes (e.g., stripes 1050 and 1060), and one or more RFID chips and/or antennas (e.g., antennas 1010 or 1060). For example, a card may have two contact chips. The contact chips may be on the same side of the card (e.g., FIGS. 9 and 10) or different sides of the card (e.g., FIG. 91). On the side of the card opposite a particular contact chip may be a magnetic stripe (e.g., FIG. 90). A card may have two contact chips and one or two magnetic stripes. Similarly, card may have two contact chips and one or two RFID chips and/or antennas (e.g., FIG. 11). Persons skilled in the art will appreciate that a contact chip may include the processing circuitry and firmware for an RFID functionality so that the contactless antenna is coupled directly to the EMV contact chip. Persons skilled in the art will also appreciate that a card may include one RFID antenna on less than half the card (e.g., the side of the chip associated with the RFID antenna) and another RFID antenna on less than the other half of the card (e.g., the side of the contact ship associated with the other RFID antenna). An RFID antenna may have its own RFID chip and the data on this chip may be for a different account or product than any other magnetic stripe, contact, or RFID chips and/or antennas.

[1296] A card may have two contact chips (e.g., 905 and 910) on the front of the card. For example, contact chip 905 may be on the left side of the card and contact chip 910 may be on the right side of the card, and each may be positioned on the card for insertion into a smart card reader (e.g., based on which end of the device is inserted). The card may have a single magnetic stripe and a single contactless antenna. The printing of the card may be different towards each contact chip. For example, the left side contact chip may be associated with a credit card account. The right side contact chip may be associated with an installment functionality on that same credit card account. One credit card number may be printed on the card. When the card is used in a contact reader, the same credit card account may be in each different contact chip but a installment flag may be provided in the data of the contact chip associated with installments. The credit card personal account numbers (PANs) may be the same in the two chips, but may have different PAN Sequence Numbers, or other identifying information, so that the two chips may have, among other things, different security counters that can be independently verified. The card may have two magnetic stripes - one associated with the credit functionality (e.g., a credit card number with no installment flag in the card data such as the card's discretionary data) and one associated with the installment functionality (e.g., a credit account with an installment flag in the card data such as the card's discretionary data). The card may alternatively have one magnetic stripe, for example, a magnetic stripe associated with the credit card number. In providing a single magnetic stripe, for example, a card may never be able to be miss-swiped in a magnetic stripe reader with the wrong magnetic stripe. The card may have one or two RFID antennas (e.g., connected each to a contact chip) and/or RFID chips with RFID antennas. One RFID antenna may be associated with a credit card number and another RFID antenna may be associated with a credit card number with an installment flag.

[1297] According to example embodiments, a processing system may receive batch 1 payment messages (e.g., authorization messages) and batch 2 payment messages (e.g., settlement messages), extract any value added flag such as an installment flag, and then perform the operation associated with the flag. Flags may be provided in payment message data associated with pay with full points, pay up to a set amount in points (e.g., $10), installments, a particular type of installments (e.g., 6 month equated monthly installment (EMI), 12 month EMI, 18 month EMI, 24 month EMI, 30 month EMI, 36 month EMI, 42 month EMI, 48 month EMI, 54 month EMI), forgo a reward for a chance at a lucky draw, or any other payment capability or function. A card number may be associated with, for example, a debit account, credit account, and/or pre-paid account. Different chips may be associated with payment account numbers associated with different types of payments (e.g., debit, credit, pre-paid) and they may have different flags in the data associated with different payment functionalities.

[1298] Persons skilled in the art will appreciate a 12 month installment flag in credit card data that includes a credit card number may be processed as a credit card. Thus, the bank may receive credit interchange on the product. The installment flag may then be processed to determine that an installment was desired by the consumer and then implemented on behalf of the consumer. In doing so, the bank may receive the value of the installment transaction as well as the value of the credit interchange.

[1299] Alternatively, two different credit card numbers may be printed on the card - one associated with the credit account and one associated with an installment account. The two sides of the card may be personalized with different colors associated with different credit cards. The card may be vertically personalized as shown in FIG. 93. A benefit of having two chips with two different credit card numbers is that each credit card number can be printed on the face of the card and used for online purchases. Thus, a card may have a contact, magnetic stripe, and RFID capability associated with one credit card number for credit and a card may have a contact, magnetic stripe, and RFID capability and another credit card number for credit that is associated with installments.

[1300] FIG. 92 shows a smart phone according to principles of the present invention. Referring to FIG. 92, persons skilled in the art will appreciate that a consumer may change the function of a flag on a phone, website, or another process (e.g., a call-in process). Accordingly, a consumer can go on their mobile or a website and change, for example, the type of installment from a 6 month installment to another installment length (e.g., a 12 month installment).

[1301] According to example embodiments, options may be changed by, for example, a user, issuer, merchant, and/or the like. Using a two chip embodiment as an example, options for the two chips may include any combination of, for example, debit 1, debit 2, credit 1, credit 2, prepaid 1, prepaid 2, installment 1 [e.g., # of months], installment 2 [e.g., # of months], APR 1 [e.g., interest rate], APR 2 [e.g., interest rate], points 1, points 2, Fx 1(credit, debit and/or prepaid foreign exchange), Fx 2, Cobrand 1, Cobrand 2, Special 1 (e.g., international points, currency, etc.), and/or Special 2. The lists may be different or the same (e.g., the same may include minus one cobrand if a cobrand is already selected for a different EMV chip or identical cobrands if use of the cobrand on both chips is applicable).

[1302] For example, options may be selectable during a trip so a card holder may select from the list of cobrands under cobrand 1 for EMV 1 (e.g., Airline X Miles) and from a list of available cobrands from cobrand 2 for EMV 2 (e.g., hotel points).

[1303] Al may be on multi-applet/function cards or different (or same) on different chips/functions.

[1304] Example. Chip A/Function A. For example, use of artificial intelligence (Al) may include switching to prepaid for debit or Fx (foreign exchange) outside or inside a country, switching to points after a threshold cumulative value, or for a transaction above and/or below a threshold value. As another example, single chip Al may include credit in a month up until a cumulative value and then switch to installment and organize on size of transaction (e.g., number of months). Cumulative value per year, per week, or any period of time. Cumulative volume.

[1305] Example Chip B/Function B. Installments on debit or credit or the like. Ai may include different durations based on different amounts, for example, under $500 then 6 months, over $500 then 12 months, over $1000 then 18 months, over $1,500 then 24 months. As another example, different cards based on different countries. The device may receive, for example, the Terminal Country Code from the reader and utilize, for example, prepaid domestically and/or in India, debit outside of India, and/or the lie.

[1306] Example Chip Function A & Chip Function B. According to some example embodiments, different chips may have different card numbers (PANs) providing the benefit of usability for online transactions and in-store transactions (see FIG. 94). Different chips may have same card number and different PAN sequence numbers with the same account and benefit that may be implemented on different stripes, EMV chips, contactless (See FIG. 15) and/or printed QR codes. According to some example embodiments, options may each be assigned a PAN and/or a PAN with different sequence numbers providing option depth (see FIG. 16). Persons having ordinary skill in the art and in possession of example embodiments should instantly envisage a variety or permutations, for example, 5 credit PANs and 4 options (e.g., 4 installment options). As another example, 4 options that may be used online and an option for Fx (foreign exchange) chip/stripe/contactless, and may be changed using a mobile telephonic or other device (e.g., PDA, PC, laptop, reader, PCS terminal, smart watch, smart glasses, etc.). [1307] Each contact and/or contactless capability may have an artificial intelligence capability that performs different actions based on different data received by the chip during a transaction. For example, the chip may be pre-programmed to insert a different installment flag based on a data field received by the chip such as a country (E.G., TERMINAL COUNTRY CODE), amount size (e.g., AMOUNT, AUTHORIZED), or time (e.g., TRANSACTION TIME). For example, an installment flag may be added if the card is used outside the county of original issuance or a larger installment length flag (e.g., 12 months) may be added if the amount of the transaction is larger than a particular amount (e.g., $1,000) where an even larger installment length flag (e.g., 24 months) may be added if the amount of the transaction is larger than a larger amount (e.g., $2,000), and/or an installment flag may be added based on the date being a set distance from a bill payment (e.g., 2 days).

[1308] FIG. 93 shows card 1300 that may have structure 1301 and chip 1310 and chip 1320. A payment cihp may be, for example, on a printed circuit board having contacts that can electrically couple to the contacts of a contact payment card terminal (e.g., EMV contact terminal). A payment chip may also be coupled to an RFID antenna (e.g., embedded in card structure 1301) for electrically coupling to a contactless payment terminal (e.g., an EMV contactless payment terminal). Accordingly, a payment chip may be utilized for both contact and contactless payments. A card, such as card 1300, may have two chips. A cardholder may insert the card into a reader in one direction to utilize a first chip and may insert the card into the reader in another direction to utilize a second chip. A contactless antenna may be located above chip 1310 for chip 1310 and a contactless antenna may be located below chip 1320 for chip 1320. Accordingly, a cardholder may tap the card in different positions to make a contactless transaction with a different chip. Alternatively, for example, contactless payment functionality may only be provided for one chip (e.g., chip 1310). Each chip may be associated with a different payment account (e.g., debit account, credit account, a first payment network account, a second, different payment network account, etc.), a different payment option and/or feature (e.g., pay with rewards, earn rewards, earn a game of chance entry, pay with installments, pay with equated monthly installments, pay with a first pay period, pay with a second pay period, pay with a first set of terms and conditions such as a first interest rate, pay with a second set of terms and conditions such as a second interest rate, etc.). Accordingly, for example, one chip may be associated with a payment card number and another chip may be associated with a payment option (e.g., an equated monthly installment option). Options may have sub-options (e.g., installment durations) that may be selected with buttons on the card or may be selected via a remote device (e.g., a mobile phone or computer). The remote device may communicate with the card directly (e.g., via BlueTooth or infrared or RFID or cellular modem) or may store the selection in a remote database (e.g., a remote cloud) and a payment processing process may retrieve the manual input that was received (e.g. a particular button was pressed and may retrieve the stored value from the remote device assigned to that button by the remote device). A credit card number may be associated with a card. A chip may authorize based off that credit card number (or an associated token). A second chip may also authorize based off that credit card number (or an associated token) but may include additional data representative of a payment option (e.g., a pay with installments option). The card number maybe utilized in both chips to authorize the transaction but, for example, a processing system may recognize a flag or other data element in the data received from the second chip to indicate an installment transaction is desired and a second, post-authorization, installment transaction may be initiated and carried out to completion.

[1309] FIG. 94 shows card 1400 with card structure 1401. Electronics package 1410 and 1420 may be included and may include contacts for electrically coupling for the bi-directional communication of data with a contact payment card terminal. Electronics packages 1410 and 1420 may each include one or more secure elements and/or processors. Electronic packages 1410 and 1420 may each be coupled to a different or the same payments antenna for contactless payments. Electronics package 1410 may include a contactless antenna while electronics package 1420 may not include a contactless antenna. Each electronics package may include different firmware (e.g. different applets) and/or different payments data (e.g., different accounts and/or options). More than two electronics packages may be provided. For example, an additional one or two electronics packages may be provided on the reverse side of card 1400. Card number 1411 may be associated with electronics package 1410. Card number 1421 may be associated with electronics package 1420. Person skilled in the art will appreciate that a payment option may be its own card account so that a different card number (e.g., and expiration date) may be used for card-not-present (e.g., online purchases). As per another example, both electronics packages may utilize the same account number and may have different online security codes (e.g., 3 or 4 digit security codes) that can be utilized to authorize the underlying account while also providing an indication to a processing system of a desired option. A card with two electronics packages for communicating to a payment terminal differently based on how the card is inserted may have, for example, a credit/credit combination, a credit/debit combination, a debit/debit combination, a credit/pre-paid combination, a debit/pre-paid combination, a international/domestic account combination, a credit/EMI combination, a debit/EMI combination, a credit/pay with points combination, a debit/pay with points combination, a credit/foreign exchange account combination, a debit/foreign exchange account combination. In a combination either one, more than one, or all accounts/options may have its own card number and/or contactless antenna. A card with multiple contact chips may also, for example, have two names written on the card (one for each orientation) as well as two expiration dates. Each chip may have its own payment network logo, payment network hologram, payment network security code, or any other component.

[1310] FIG. 95 shows card 1500 that may include contact chip packages 1510 and 1520. Package 1510 may be associated with a credit account and package 1520 may be associated with an equated monthly installment (EMI) option such as a 12-month EMI option that is utilizes the same underlying account number for initial authorization as electronics package 1510. Each package may have its own contactless antenna and indicia may be included that is aligned with the antenna to indicate where a consumer should tap the card to make different types of contactless transactions. For example, indicia 1511 may be associated with package 1510 and indicia 1521 may be associated with package 1520.

[1311] FIG. 96 shows card 1600 that may include card structure 1601. Payment terminal contact packages 1610 and 1620 may be included. Any number of printed/embossed account numbers may be associated with any contact package. For example, contact package 1610 may include a single printed/embossed account number, such as account number 1611, (e.g., a credit or debit account number). Contact package 1610 may be associated with one, two, three, four, or more than four account numbers (e.g., printed/embossed account numbers 1621-1624). Accordingly, electronics package 1620 may be utilized for a contact (e.g., and contactless) transaction and may provide an transaction with an account/option at a set or adjustable account/option (e.g., 12-month equated monthly installments) and, for online purchases, additional options may be provided in the form of additional account numbers. Online security codes may also be utilized and differentiated for different options (e.g., 4 different options). Accordingly, for example, a cardholder may make a purchase in a store using the desired electronics package and, when making an online or other type of card not present transaction, may utilize the printed/embossed account numbers for the same or different accounts/options as well as additional accounts/options. An electronics contact chip package may be associated with a slider switch (e.g., switch 1619) that may have one, two, or more than two switch positions (e.g., 6 switch positions). An electronics contact chip package may include buttons and visual indicators 1629. Manual interfaces may be utilized to change options/accounts in an electronic contact chips package or any type of electronics package.

[1312] One or more magnetic stripes may be provided (e.g., on the reverse side of card 1600. Each magnetic stripe may be associated with a different electronics contact chip package. Accordingly, for example, a magnetic stripe may be associated with electronics chip package 1610 and a different magnetic stripe may be associated with electronics chip package 1620.

[1313] FIG. 97 shows a GUI of a device according to principles of the present invention. A dynamic statement may be provided on a website or phone where a consumer can see all credit and installment transactions. A consumer can change installment to credit transaction and vise versa on the dynamic statement for no fee or for a fee. A consumer can change a duration of an installment to another duration of an installment for no fee or for a fee. The dynamic statement may include information such as date, time, merchant name, payment type (e.g., credit or installment), credit length, specific installment payment due for the month (e.g.., monthly installment payment 4 of 6), interest rate, fee amount, total transaction amount, amount due, or any other piece of information.

[1314] Device 1710 may include a graphical user interface (e.g., GUI 1711) associated with a website, application, or other software platform that provides details about a payment card (e.g., payment card 1600 of FIG. 6). The graphical user interface may display purchases made with each particular account/option of a payment card. For example, the graphical user interface may include a list of credit transactions that utilized a credit account on a card and a list of installment transactions that utilized an installment option on a card. The remaining balance and remaining installments (e.g., remaining equated monthly installments may be provided. The date of the original transaction or the date of the last or next installment may be provided. A total credit balance may be displayed (not shown) and a total amount of installment balance may be displayed (not shown). An installment balance may be shown as a balance due each month in the future where a balance is due (e.g., a projection of payments across future months).

[1315] Device 1720 may include a graphical user interface (e.g., GUI 1721) for data and services associated to a payment card. Device 1720 may be, for example, a laptop computer or a mobile phone. A graphical user interface on device 1720 may include, for example, a payment schedule for a purchase and the ability to convert an installment transaction to a credit transaction (e.g., for a fee) as well as convert an instalment payment schedule to a one-time payment. Different fees and/or discounts may be provided for converting from one type of payment to another or by paying early. Any graphical user interface may be a graphical user interface on a card itself and may communicate bi-directionally to remote servers via, for example, a cellular modem and SIM chip on the card itself. [1316] Device 1730 may include a graphical user interface (e.g., GUI 1731) for data and services associated to a payment card. Device 1730 may be, for example, a laptop computer or a mobile phone. A graphical user interface may permit a cardholder to select an installment transaction and change the terms of the installment transaction (e.g., number of installments). Accordingly, a cardholder can extend an installment schedule or accelerate an installment schedule. Partial payments may also be made available to reduce payments during an already existing payment schedule. At any time one, more than one, or multiple installment payments in a payment schedule may be moved to a different type of payment (e.g., a credit card account line). Or, for example, the entire schedule may be moved to another type of payment account (e.g., a credit card account line).

[1317] Device 1740 may include a graphical user interface (e.g., GUI 1741) for data and services associated to a payment card. Device 1740 may be, for example, a laptop computer or a mobile phone. A graphical user interface may, for example, include a list of credit transactions and any one, more than one, or all credit transactions (e.g., that are outstanding) may be converted into an installment schedule or another type of transaction. Accordingly, a cardholder may utilize a mobile phone application or website to, for example, determine the history of payment transactions and outstanding balances and plan and move different types of transactions to other types of transactions.

[0001] FIG. 1 shows card 100 that may include, for example, dynamic magnetic stripe communications device 101, one or more displays (e.g., displays 112, 113 and 125), permanent information 120, light sensor 127, one or more buttons (e.g., buttons 130-134, 198 and 199), lights 135-138, 196 and 197, and dynamic number 114 which may include a permanent portion 111. Permanent portion 111 may be, for example, printed, embossed and/or laser etched on card 100.

[0002] Multiple displays may be provided on card 100 for various purposes. For example, display 112 may display a dynamic number entirely, and/or partially. Display 113 may be utilized to display a dynamic code (e.g., a dynamic security code). Display 125 may display logos, barcodes, and/or one or more lines of information (e.g., may display a coupon code). A display (e.g., at least one of displays 112, 113 and 125) may be a bi-stable display or non bi-stable display. A bi-stable display may be a display that maintains an image without power.

[0003] Card 100 may include permanent information 120 including, for example, information specific to a user (e.g., a user's name and/or username) and/or information specific to a card (e.g., a card issue date and/or a card expiration date).

[0004] Card 100 may include a dynamic magnetic communications device. Such a dynamic magnetic communications device may take the form of a magnetic encoder and/or a magnetic emulator. A magnetic encoder may change the information located on a magnetic medium such that a magnetic stripe reader may read changed magnetic information from the magnetic medium. A magnetic emulator may generate electromagnetic fields that directly communicate data to a magnetic stripe reader. Such a magnetic emulator may communicate data serially to a read-head of the magnetic stripe reader. [0005] Card 100 may include one or more buttons, for example, buttons 130-134, 198 and 199. Buttons 130- 134, 198 and 199 may be, for example, mechanical buttons, capacitive buttons, light sensors and/or a combination thereof.

[0006] Button 199 may be used, for example, to communicate information through dynamic magnetic stripe communications device 101 indicative of a user's desire to communicate a single track of magnetic stripe information. Persons skilled in the art will appreciate that pressing a button (e.g., button 199) may cause information to be communicated through device 101 when an associated read-head detector detects the presence of a read-head of a magnetic stripe reader and/or at a specific frequency. Button 198 may be utilized to communicate (e.g., after button 198 is pressed and after a read-head detects a read-head of a reader) information indicative of a user selection (e.g., to communicate two tracks of magnetic stripe data). Multiple buttons may be provided on a card and each button may be associated with a different user selection.

[0007] Different third party features may be, for example, associated with different buttons and a particular feature may be selected by pressing an associated button. According to at least one example embodiment, button 198 and button 199 may each be associated with, for example, a different third party service provider feature (e.g., an application facilitating a coupon) and may be changed by a user at any time.

[0008] According to some example embodiments, a user may select a third party feature from a list displayed to the user. For example, the user may scroll through a list of features on a display (e.g., display 125). A user may scroll through a list using buttons on a card (e.g., buttons 130-134). The list of features may be displayed to the user individually, in groups and/or all features may be simultaneously displayed.

[0009] According to some example embodiments, a third party feature associated with a button may be changed by a user, for example, on a graphical user interface (GUI) provided by a device provider, ecosystem provider, application manager provider, remote facility provider, card issuer, processor, and/or any other entity (which may be the same or different entities). For example, an ecosystem provider may, on its website and/or via an application, allow a user to change the third party feature performed when the third party's feature button is selected by a user on the user's card or other device. [0010] A third party service provider may provide a reward (e.g., a coupon) from a collection of rewards based on, for example, one or more card transactions. The fact the user has received the reward may be presented on a profile page of the user. When a transaction is performed, a user's profile may be updated to state that the user has earned a reward and the user may receive the reward (e.g., via email). A user may be provided with a GUI, for example, a GUI on a mobile telephonic device of the user, when the user makes a purchase, to identify and/or use the reward earned by the user.

[0011] The selection of a feature may or may not have a cost associated with it. If a cost is associated with the feature, for example, the cost may be added to a customer's statement (e.g., added to a credit or debit purchase) for a particular transaction. A fixed-fee or variable-fee (e.g., a percentage of the transaction) may then be removed from the fee charged to the user and distributed among particular parties (e.g., distributed to the card issuer, application manager provider, ecosystem provider, device provider and/or other entity). The remainder of the fee, if any, may be provided, for example, to the third party service provider.

[0012] A cost may be associated to a feature selection, but may not be a cost to a user. For example, the cost may be a cost to a third party service provider (e.g., an incentive). The cost may be a cost to other entities, for example, the device provider, card issuer, card processor (which may be the same, for example, as the card issuer), and/or any other entity (e.g., card network).

[0013] According to some example embodiments, a user may select a type of payment on card 100 via manual input interfaces (e.g., buttons 130-134). The manual input interfaces may correspond to displayed options (e.g., displayed on display 125). Selected information may be communicated to a magnetic stripe reader via a dynamic magnetic stripe communications device.

Selected information may also be communicated to a device (e.g., a mobile telephonic device) including a capacitive sensor and/or other type of touch sensitive sensor.

[0014] Lights 135-138, 196 and 197 (e.g., light emitting diodes), may be associated with buttons 131- 134, 198 and 199. Each of lights 135-138, 196 and 197 may indicate, for example, when a button is pressed. In a case where a button may activate card 100 for communications, a light may begin blinking to indicate card 100 is still active (e.g., for a period of time) while reducing power expenditure. Although not shown, a light may be provided for button 130.

[0015] Card 100 may include light sensor 127. Light sensor 127 may, for example, receive information from a light source (e.g., a display of a mobile telephonic device and/or a laptop computer). Card 100 may include, for example, any number of light sensors 127. Light sensor 127 may be utilized such that a display screen, or other light emitting device, may communicate information to light sensors 127 via light. Display 125 may allow a user to select (e.g., via buttons) options on display 125 that instruct the card to communicate (e.g., via a dynamic magnetic stripe communications device, RFID and/or exposed IC chip) to use a debit account, credit account, pre-paid account, and/or point account for a payment transaction.

[0016] Card 100 may, for example, be loaded into device 188, which may be a portable device such as a portable telephonic device (e.g., a watch, mobile phone, automobile, etc.). Card 100 may be loaded into device 188 as digital card 187. Digital card 187 may have, for example, none of the features of card 100, a portion of the features of card 100, all of the features of card 100, and may include additional features not provided in card 100. Accordingly, for example, digital card 187 may include digital buttons that correspond to physical buttons on card 100 and/or digital displays that correspond to physical displays of card 100. Device 188 may include any number of communication devices to communicate, for example, to any device such as a remote server, a card, a payment device (e.g., watch, mobile phone, card), point-of-sale system, etc. Accordingly, device 188 may include Bluetooth, one or more cellular modems, magnetic stripe communication devices, contact communication devices, contactless communication devices, or any other type of communication technology (e.g., communication technology of card 100). One, two, three, four, or more than four cards may be loaded into device 188. All, or portion of the cards, that are digitized/virtualize may have virtual buttons added to the cards even if the physical cards do not have physical buttons. For example, one, two, three, four, or more than four virtual buttons may be added to one, more than one, or all cards that are digitized virtualized for a particular bank or for any bank. Digital card 187 may, for example, be loaded into a wallet that is branded to a bank issuer associated with digital card 187. Such a mobile wallet may be an executable program (e.g., an application) and may be able to load only cards from the same issuing bank or cards from multiple issuing banks. Digital cards may be loaded into a mobile wallet of a device without, for example, an underlying physical card. Such a digital card may be delivered from a remote server. Such a remote server may receive a request to create a digital card (e.g., from an issuing bank or from a consumer) and card personalization data may be delivered to the mobile wallet. A digital card may, for example, display one or more payment card numbers or may display no payment card numbers. A personal identification code may be requested in order for a digital (or physical) card to be utilized at a point-of-sale and/or to have one or more payment card account numbers displayed (e.g., for an online or over-the-phone transaction).

[0017] Architecture 150 may be utilized with any card (e.g., any card 100). Architecture 150 may include, for example, processor 120, display 140, driving circuitry 141, memory 142, battery 143, radio frequency identification (RFID) 151, integrated circuit (IC) chip 152, electromagnetic field generators 170, 180, and 185, and read-head detectors 171 and 172. [0018] Processor 120 may be any type of processing device, for example, a central processing unit (CPU) and/or a digital signal processor (DSP). Processor 120 may be, for example, an application specific integrated circuit (ASIC). Processor 120 may include on-board memory for storing information (e.g., triggering code). Any number of components may communicate to processor 120 and/or receive communications from processor 120. For example, one or more displays (e.g., display 140) may be coupled to processor 120. Persons skilled in the art will appreciate that components may be placed between particular components and processor 120. For example, a display driver circuit may be coupled between display 140 and processor 120.

[0019] Memory 142 may be coupled to processor 120. Memory 142 may store data, for example, data that is unique to a particular card. Memory 142 may store any type of data. For example, memory 142 may store discretionary data codes associated with buttons of a card (e.g., card 100 of FIG. 1). Discretionary data codes may be recognized by remote servers to effect particular actions. For example, a discretionary data code may be stored in memory 142 and may be used to cause a third party service feature to be performed by a remote server (e.g., a remote server coupled to a third party service such as a coupon provider). Memory 142 may store firmware that, for example, controls triggering and/or the like.

[0020] Architecture 150 may include any number of reader communication devices. For example, architecture 150 may include at least one of IC chip 152, RFID 151 and a magnetic stripe communications device. IC chip 152 may be used to communicate information to an IC chip reader (not illustrated). IC chip 152 may be, for example, an EMV chip. RFID 151 may be used to communicate information to an RFID reader. RFID 151 may be, for example, an RFID tag. A magnetic stripe communications device may be included to communicate information to a magnetic stripe reader. For example, a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

[0021] Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, architecture 150 may include electromagnetic field generators 170, 180, and 185 to communicate separate tracks of information to a magnetic stripe reader. Electromagnetic field generators 170, 180, and 185 may include a coil (e.g., each may include a coil) wrapped around one or more materials (e.g., a soft-magnetic material and a non-magnetic material). Each electromagnetic field generator may communicate information, for example, serially to a receiver of a magnetic stripe reader for a particular magnetic stripe track. According to at least one example embodiment, a single coil may communicate multiple tracks of data. [0022] Architecture 150 may include read head detectors 171 and 172. Read-head detectors 171 and 172 may be configured to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). Information sensed by the read-head detectors 171 and 172 may be communicated to processor 120 to cause processor 120 to communicate information serially from electromagnetic generators 170, 180, and 185 to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader.

[0023] According to at least one example embodiment, a magnetic stripe communications device may change the information communicated to a magnetic stripe reader at any time. Processor 120 may, for example, communicate user-specific and card-specific information through RFID 151, IC chip 152, and/or electromagnetic generators 170, 180, and 185 to card readers coupled to remote information processing servers (e.g., purchase authorization servers). Driving circuitry 141 may be utilized by processor 120, for example, to control electromagnetic generators 170, 180 and 185.

[0024] Architecture 150 may include, for example, a light sensor. Architecture 150 may receive information from a light sensor. Processor 120 may determine information received by a light sensor.

[0025] One or more payment applets may be, for example, run by any circuit and/or chip of card 150. Any applet on card 150 may be, for example, an applet on device 188 or associated with virtual card 187. Persons skilled in the art will appreciate that one or more payment applets may be pre-loaded into a card or other device or loaded into a card or other device after the card is issued to a cardholder. A payment applet may, for example, include software/firmware for any number of payment networks and may be updated at any time (e.g., at the direction of an issuing bank, payment network, administrator, cardholder etc.). Persons skilled in the art will appreciate that an applet may be provided with multiple applications such as, for example, applications for each payment network for a contact chip as well as a contact chip or other communication protocols. An applet may, for example, run off an operating system. Each chip may have a different operating system and each chip may have a different applet. Persons skilled in the art will appreciate that any physical button on a physical card or a virtual button on a virtual card may be included as a feature in a payment applet that is triggered based on pre-determined and/or adaptive determinations based on, at least in part, for example, transaction data (e.g., previous transaction data and/or current transaction data). A payment applet may utilize past and/or present data to provide predictive decisions and trigger features (e.g., switch payment accounts) based on such predictive decisions.

[0026] For example, an applet that provides transaction protocols for a device through both contact and contactless communication devices may recognize that the devices first transaction occurred (e.g., a contact transaction) and may display a pre-determined and pre-stored message on a display (e.g., "Welcome cardholder to bank" where bank may be personalized to the name of the bank and cardholder may be personalized to the first name or full name of the cardholder. The applet may then repeat that message for a number of transaction approvals (e.g., 1, 2, 3, 4, 5, or more than 5) regardless if the transaction is a contactless transaction or contactless transactions. The applet may, for example, also determine the country of a transaction utilizing country information (e.g., CDOL/PDOL country information) and may determine whether or not a payment card account number needs to be changed (e.g., based on pre-determined associations of card accounts to countries). The device may then cause a transaction to not be completed (e.g., not acknowledge an approval message sent to the device) and the device may change the payment account utilized for the next transaction). The applet may leave this payment account number until, for example, the country changes and then the applet may determine whether or not a payment account change is applicable to the recognized country and, if so, change the account for that transaction (e.g., shut down and restart a transaction with the new payment account number).

[0027] A single chip may have, for example, a single operating system and a single payment applet and multiple communication interfaces may be coupled to this chip such as, for example, a contactless antenna for contactless transaction and a contact interface for contact transactions. A processor, for example, may provide control signals to an applet or other structures of a card or a device to, for example, change payment accounts, features, and/or applets utilized on the components. Similarly, for example, payment transaction applets may communicate with other structures on a card or other device to, for example, initiate functionality such as, for example, pre-stored messages, light source operation (e.g., display images on LEDs and/or display animations using LED) or to utilize components of architecture 150.

[0028] FIG. 2 shows device 200 that may be, for example, a mobile telephonic device and/or other device (e.g., portable computer such as a portable tablet computer). Device 200 may include, for example, housing 202, display 210, device card 220, virtual buttons 230, 231 and 240, virtual lights 242-247, dynamic card number and verification code 245, and identification information 250.

[0029] Display 210 may include, for example, light- sensitive and/or touch-sensitive elements. Device 200 may communicate information to a card reader, for example, via a contactless signal (e.g., an RFID signal) and/or a contact-based signal (e.g., a USB connection).

[0030] Device 200 may include a device card 220 and/or virtual buttons 230 and 231. Device card 220 may be a virtual representation of a card and/or any information identifying a payment method (e.g., credit account number). A person skilled in the art will appreciate that any physical card described herein may be provided as a device card on, for example, a computing system (e.g., a mobile telephonic device and/or a computer). Physical buttons of a physical card may, for example, correspond to virtual buttons of a device card.

[0031] Virtual button 230 may, for example, correspond to one feature (e.g., an opportunity to earn a coupon) from a third party service provider while virtual button 231 may, for example, correspond to another feature (e.g., the opportunity to add value to a coupon) from the same or a different third party service provider. According to at least one example embodiment, every feature may not be provided by a third party service provider. Persons skilled in the art will appreciate that, for example, the device provider may provide features.

[0032] All features for a card may be utilized with a particular payment account (e.g., a credit account) such that a payment transaction with that payment account is performed if any feature is selected. As another example, one or more features may be associated with a payment account (e.g., a credit account) while an additional one or more features may be associated with a different payment account (e.g., a debit account). Accordingly, a selected feature associated with a credit account may be utilized to make a purchase with credit and may perform an additional action associated with that feature. A different selected feature associated with a debit account may be utilized to make a purchase with debit and may perform an additional action associated with that different feature.

[0033] Device 200 may include virtual lights 242- 247. Virtual lights 242-247 may, for example, indicate an active period during which device 200 may communicate with external devices. Virtual lights 242- 247 may correspond to, for example, virtual buttons 230, 231 and 240. According to example embodiments, a fewer or greater number of virtual lights are contemplated (e.g., a center button of virtual buttons 240 may virtually light up).

[0034] Card number 251 may be a static card number for virtual card 220 or, for example, may be dynamic and may change at every use. Additionally, for example, card number 251 may be changed to another card number based on information received during a payment transaction. Persons skilled in the art will appreciate that as a payment card number changes, for example, so may the payment cards security code (e.g., CVV and/or CVC) as well as other metrics (e.g., expiration date. Physical card 290 may be, for example, a physical representation of any structures and/or feature of virtual card 220 (e.g., a majority of the features of card 220). Persons skilled in the art will appreciate that a payment applet may be different from device to device such as, for example, provided to operate on a particular operating system of a particular device. A chip on a card may, for example, utilize a different operating system than a chip on a portable telephonic device.

[0035] FIG. 3 shows network topology 300 that may include, for example, mobile device 302, contactless device 304, cellular network access infrastructure 306, mobile network 310, wireless access point 308, IP network 312, payment network 314, issuer 320, payment server 316, merchant acquirer 317, ecosystem provider 342, merchant terminal 318, transaction card 333, user electronic device 345 and/or application providers 338, 339 and 340.

[0036] Mobile device 302 (e.g., a mobile telephonic device, a PDA, an electronic tablet, a laptop, a GPS unit, and/or an MP3 player) may include, for example, a contactless interface that may initiate, sustain, and/or terminate communication channel 326 between contactless device 304 (e.g., a powered card, non- powered card and/or a device) and mobile device 302. Contactless device 304 and mobile device 302 may communicate via channel 326 using any number of contactless mediums, which may include for example, visible, audible, capacitive, electromagnetic, magnetic, and/or RF mediums.

[0037] Mobile device 302 may provide one or more transceivers, receivers and/or transmitters that may communicate with one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks (e.g., a mobile network 310). Mobile device 302 may, for example, communicate with a cellular station over a wireless radio interface (e.g., a GSM air interface) that may be used by mobile device 302 to communicate information (e.g., voice and data) to cellular network access infrastructure 306 (e.g., one or more GSM base transceiver stations, base station controllers and mobile switching centers). Persons skilled in the art will appreciate that cellular network access infrastructure 306 may utilize any multiple access architecture, such as for example, a code-division multiple access architecture and/or a time-division multiple access architecture.

[0038] Mobile device 302 may, for example, communicate with wireless access point 308 over a wireless interface (e.g., a Bluetooth interface or a Wi-Fi interface). Accordingly, for example, mobile device 302 may access one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network) without the need to first gain access to cellular network access infrastructure 306.

[0039] Payment information (e.g., a payment account number and a card expiration date) may be communicated from contactless device 304 to mobile device 302 in support of a transaction (e.g., a financial transaction) being conducted by mobile device 302. In so doing, for example, items for purchase on IP network 312 (e.g., the internet) may be accessed by a browser of mobile device 302 via an access point (e.g., wireless access point 308 and/or cellular network access infrastructure 306). Mobile device 302 may, for example, complete a purchase transaction by first obtaining required payment information from contactless device 304 and then communicating such payment information to network entities (e.g., merchant acquirer 317, payment server 316 and/or issuer 320). Mobile device 302 may, for example, already contain payment information necessary to complete a purchase transaction. Accordingly, mobile device may not need to obtain payment information from contactless device 304 before completing a purchase transaction.

[0040] Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with payment information received from mobile device 302 for authorization of a purchase. Once authorized, payment transaction information may be recorded onto a receipt that may be delivered to mobile device 302 via any one or more delivery options (e.g., via a short messaging service of mobile network 310 or an email delivery service of IP network 312).

[0041] A payment receipt may, for example, be provided to mobile device 302 as a proof-of-purchase object (e.g., a barcode) that may be provided to a display of mobile device 302 and read by other computing equipment (e.g., a barcode scanner) for proof-of-purchase confirmation. [0042] Transaction card 333 (e.g., a powered card, non-powered card and/or device card) may, for example, communicate information to merchant terminal 318 (e.g., a magnetic stripe reader, an EMV reader, an RFID reader, an NFC reader and/or a swipe reader attached to an electronic device). Merchant terminal 318 may begin transactions (e.g., point-of-sale transactions) and/or complete transactions via merchant acquirer 317 and/or payment network 314. Accordingly, for example, transaction card 333 may communicate payment information to merchant terminal 318 to initiate a financial transaction.

[0043] Merchant terminal 318 may communicate transaction information, including at least a portion of the payment information, to merchant acquirer 317. Merchant acquirer 317 may authorize the financial transaction and/or communicate with payment server 316. Payment server 316 may, for example, contact issuer 320 via a network (e.g., payment network 314) with transaction information received from merchant acquirer 317 for authorization of a purchase. Once authorized, an authorization may be communicated to merchant terminal 318 and may be recorded onto a receipt by merchant terminal 318.

[0044] Application providers 338, 339 and 340 may be one or more entities (e.g., one or more servers) providing applications for association in an ecosystem provided by ecosystem provider 342. Each application may provide one or more features to users of a payment method (e.g., users of contactless device 304 and/or transaction card 333). For example, an application may provide a user an opportunity to earn a coupon and/or add value to a coupon in exchange for using the payment method. According to at least one example embodiment, application provider 338 may provide coupons as part of a loyalty or rewards program, which may be independent of any payment method. Ecosystem provider 342 may be, for example, a server that maintains associations between applications, users and payment methods.

[0045] Ecosystem provider 342, and application providers 338, 339 and 340, may communicate with different entities using one or more wired networks (e.g., IP network 312 and/or payment network 314) and/or one or more wireless networks 310 (e.g., a mobile network). Application providers 338, 339 and 340 may communicate directly and/or indirectly with different entities. For example, merchant terminal 318 and/or ecosystem provider 342 may communicate directly with application providers 338, 339 and 340 via IP network 312 and/or via a direct connection (e.g., to validate coupons with a coupon server). As another example, application providers 338, 339 and 340 may exchange information (e.g., transactional data) indirectly with issuer 320, merchant acquirer 317 and/or payment network 314 via, for example, ecosystem provider 342.

[0046] A user electronic device (e.g., mobile device 302 and/or a wired user electronic device 345) may display a GUI. The GUI may be an application manager used to interface with ecosystem provider 342, and application providers 338, 339 and 340, to define user preferences. Defining user preferences may include, for example, configuring associations (e.g., between users, applications and payment methods), features and/or permissions. [0047] In order to configure associations, for example, the GUI displayed on the user electronic device may, for example, display indicia representing applications that provide features. A user may associate one or more of the applications to one or more payment cards and/or payment card buttons (e.g., mobile device 302 and/or transaction card 333)).

[0048] In order to configure one or more features provided by an application, for example, the GUI displayed on the user electronic device may be used to, for example, interface with one or more of application providers 338, 339 and 340. For example, using the GUI, a user may select a coupon from among multiple coupons provided by an application hosted by an application provider.

[0049] In order to configure associations, for example, a user may use the GUI displayed on the user electronic device to define how payment network 314, ecosystem provider 342, one or more of application providers 338, 339 and 340, and third-party applications hosted by the one or more application providers (or any other application providing entity) interact for transactions conducted by the user.

[0050] For example, a user may accept an end license user agreement that outlines how data may be shared between entities. As another example, a user may define what data may be shared between entities. For example, where data (e.g., transactional data) may be provided to ecosystem provider 342 by payment network 314, and/or provided to one or more of application providers 338, 339 and 340 by ecosystem provider 342, a user may select at least a portion of data provided to ecosystem provider 342 by payment network 314, and select at least a portion of data to be shared with the one or more of application providers 338, 339 and 340. [0051] Prior to presenting transaction card 333 to merchant terminal 318 to initiate a transaction, a customer may select (e.g., via one or more button presses on a powered card and/or device card) an application to be associated to the transaction. Based on the selection, one or more additional actions may be taken besides the processing of the transaction by payment network 314. For example, a user may press a button on a powered card (e.g., transaction card 333). Upon presenting transaction card 333 to merchant terminal 318, a payment message (e.g., a magnetic stripe message) reflecting the button that was pressed may be communicated to merchant terminal 318.

Merchant terminal 318 may communicate a data string including the payment message and transaction information to payment network 314 via merchant acquirer 317.

[0052] Payment network 314 may receive the data string. The data string may include a directive instructing payment network 314 to share data with ecosystem provider 342. According to at least one example embodiment, payment network 314 may share data with ecosystem provider 342 upon receiving the data string and recognizing, based on at least a portion of the data string (e.g., an account number), that data is to be shared. Payment network 314 may cause the same or a different data string to be communicated from payment network 314 (e.g., from a processor within payment network 314) to ecosystem provider 342.

[0053] Although example embodiments describe a payment network communicating data to an ecosystem provider, alternatively and/or additionally, an issuer and/or a processor of an issuer may receive data and communicate at least a portion of the data and/or different data based on the received data to ecosystem provider 342. For example, a processor of issuer 320 may parse a data string received from merchant terminal 318 (e.g., via payment network 314) that includes a particular BIN number, may convert the data string into a different format and may forward the converted data string to ecosystem provider 342. Persons of ordinary skill in possession of example embodiments will appreciate that many different messaging schemes may be used.

[0054] Ecosystem provider 342 may receive the data string and compare user information (e.g., payment account number and/or payment account holder's name) that may be included within the data string to a user database to obtain a customer ID (e.g., a customer token) associated with the user information.

[0055] According to at least one example embodiment, sensitive information within the data string (e.g., payment account number and/or payment account holder's name) may be replaced with the customer ID to create a modified data string, and the sensitive information may be stored either locally within ecosystem provider 342 or remotely to ecosystem provider 342. The modified data string may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312. [0056] According to at least one example embodiment, ecosystem provider 342 may receive the data string. The data string may be populated with information that may be indicative of which button was pressed on the powered card before being presented to merchant terminal 318. Using the button information and user preferences, ecosystem provider 342 may generate a third-party message with details that may be shared with a third-party application (e.g., one or more of application providers 338, 339 and 340). The generated data string may include the customer ID and may be communicated to a third party application (e.g., one or more of application providers 338, 339 and 340) via, for example, IP Network 312.

[0057] A user may elect to share certain transaction information with one or more of application providers 338, 339 and 340 each time a certain button is pressed on the user's powered card before presentment to merchant terminal 318 for payment. Such information may include, for example, merchant information (e.g., merchant's address), date/time information of a purchase, an amount of the purchase, a type of the purchase, and any other information (e.g., the customer ID associated with the customer's merchant account). The various pieces of the transaction information may or may not be selected for sharing by the user via the user preferences.

[0058] According to at least one example embodiment, a user may agree to share data during a registration process with an application provider (e.g., via an end user license agreement). Upon receiving a data string, the sharable data may be automatically populated within a third-party message and communicated to an application provider via IP network 312.

[0059] Upon receipt of the third-party message, the application provider (e.g., one or more of application providers 338, 339 and 340) may enact a feature provided to a user (e.g., provide a coupon). The application provider may initiate a second transaction (e.g., a piggyback transaction, a statement credit and/or the like). The second transaction may be communicated to ecosystem provider 342 via IP network 312 (e.g., the internet) and processed by ecosystem provider 342 accordingly. For example, ecosystem provider 342 may determine whether a second transaction is permitted and/or forward information associated with the second transaction to another entity (e.g., issuer 320).

[0060] According to some example embodiments, a GUI may, for example, be rendered onto a display of a user's card or other device (e.g., mobile device 302, user electronic device 345, transaction card 333 and/or contactless device 304). The GUI may display indicia of one or more third-party applications (e.g., provided by one or more application providers 338, 339 and 340) along with summary and/or detailed information. Based upon information gleaned from the information concerning the applications, the user may be better informed as to which third-party applications he or she may wish to associate with his or her powered or non- powered card. Accordingly, the whimsical and festive nature of a user's experience with a GUI rendered by an electronic device may be further enhanced.

[0061] According to example embodiments, an application provider may be any entity. For example, ecosystem provider 342 may be an application provider in addition to providing an ecosystem. According to at least one example embodiment, an application provider may be a third-party application provider and ecosystem provider 342 may host the third party application (e.g., provide coupons). Data sharing may be the same or different based on a particular configuration.

[0062] Applet 391 may be provided on transaction card 333 or another device. Applet control information may be, for example, communicated to applet 391 during a payment transaction. For example, a cardholder may utilize the cardholder's portable telephonic device to change an account of a card (e.g., from a debit card to a credit card). This information may be communicated to a card during a transaction (e.g., utilizing EMV scripting). The card's applet then may, for example, fulfill the control request and change the account of the card for the transaction (e.g., from a particular debit card account to a particular credit card account). If, for example, the applet cannot change the account for the transaction, the applet can change the account for the subsequent transaction (e.g., which may involve terminating the transaction and not letting the transaction complete so the next successful transaction utilizes the new account or by not terminating the transaction and letting the transaction complete and the subsequent transaction would also complete).

[0063] FIG. 4 shows device 400 (e.g., a card, a mobile telephonic device, a laptop computer, a desktop computer or an electronic tablet) that may include display 401. Device 400 may include a processor that may render GUI 403 onto display 401. GUI 403 may be an application manager. Using GUI 403, a user may associate a payment method card (e.g., a powered physical card, non-powered physical card and/or device card) with third party service features within an ecosystem. GUI 403 may be displayed on display 401, for example, a computer monitor, mobile phone touch screen and/or the like. GUI 403 may be, for example, provided as an application for a device (e.g., a computer, a portable computing device and/or a mobile telephonic device) and/or retrieved information from a web browser.

[0064] An application manager may be provided, for example, on a remote facility and displayed via GUI 403 to allow a user to change the third party service features associated with a card. An application manager may manage an ecosystem of applications and payment method cards, and the user may utilize GUI 403 to, for example, associate a particular feature to a particular payment method card at any time. The user may associate the selected feature with a card and/or a card button.

[0065] Persons skilled in the art will appreciate that a default feature may be provided and/or that a number of features provided by a card issuer or other entity may be provided in addition to third party service features. For example, a card issuer may provide a card with a default of credit on one button and a default of decoupled debit on a second button. A user may press the first button to perform a credit transaction. A user may press the second button to perform a decoupled debit transaction.

[0066] GUI 403 may include tabs 405, information 411, virtual card 412, virtual indicia 413 and 414, slider 415, application identifiers 423 and 426, and selection options 428, 431, 432, 441-443 and 446.

[0067] Virtual card 412 may be provided as a representation of a user's physical and/or device card. A user may be provided with the ability to change between multiple different cards and configure the features associated with those multiple cards. Accordingly, virtual card 412 may be provided with indicia 413 in the configuration of, and indicative of, one button of a user's card, and virtual card 412 may be provided with indicia 414 in the configuration of, and indicative of, another button of a user's card. Indicia 413 and 414 may display the applications currently associated to each button (e.g., an application icon). A slider 415 may be provided to indicate which of applications associated with a button may be a default application (e.g., for online, telephonic and/or non-powered card transactions). Accordingly, a user may, for example, view virtual card 412 in order to refresh the user's memory with respect to the features associated with the buttons on a user's physical and/or device card.

[0068] A list of applications may be provided on GUI 403. Each application may provide one or more third party service provider features. In order to associate a particular feature with a particular card and/or one or more buttons on a card, a user may associate an application providing the feature to the card and/or card button(s). For example, selection 431 may associate application 423 to the button of a card associated with virtual button 413. Selection 432 may associate application 426 to the button of a card associated with virtual button 414. Accordingly, a user may change the features associated to a card by using GUI 403. In order to view the features provided by a particular application the user may, for example, select an "explore" button to view relevant information

(e.g., selection 446). [0069] The list of applications provided on GUI 403 may be, for example, all applications or a limited subset of all applications available to a user via an ecosystem provider. For example, in order to view all available applications, tab 402 may be selected by a user (e.g., with a keyboard, mouse, touch sensitive screen and/or electronic pointer) to display an application manager home view. In order to view a limited subset of applications a user may select a different tab. For example, tab 403 may be selected by a user to display a featured view including featured applications (e.g., applications-of-the-week). Other tabs may sort applications by category, use and/or the like.

[0100] Selections 428 may be selections used to activate an application with respect to the user. Activation may include registration with a third party application, acceptance of an end users license agreement associated with the application, and/or the like. Activation may also include selecting a particular feature from among multiple features provided by the application. According to at least one example embodiment, some applications may not require activation (e.g., single feature, non-interactive applications).

[0101] Once an application is activated and/or associated to a card and/or card button, a user may begin experiencing a selected feature by engaging in card transactions. For example, the user may press a card button associated with a desired feature during a card transaction. A physical and/or device card (not shown) may communicate information indicative of a button that was pressed on the physical and/or device card, along with or separate from other payment data (e.g., an account number, security code, and other data). For example, information indicative of the button that was pressed may be included in discretionary data of a payment message. A payment message may be, for example, one or more tracks of magnetic stripe data (e.g., communicated from a dynamic magnetic stripe communications device), an RFID message (e.g., a near field communication (NFC) message from a radio frequency antenna), and/or an exposed IC chip message (e.g., an EMV message) from an exposed IC chip. [0102] The information indicative of which button was pressed may be passed to a card issuer and/or processor from a point-of-sale and any intermediary devices (e.g., a merchant acquirer processing server). The information may be passed to a remote facility (e.g., a facility providing an application manager) such that the remote facility may determine the button that was pressed by a user. This remote facility may, in turn, retrieve information associated with the third party feature (and/or a feature of a card issuer, processor, application manager provider, and/or any entity) and forward information to that feature provider such that the feature may be performed. Information may additionally and/or alternatively be provided from the feature provider to the entity that provided the information indicative of the button that the user pressed.

[0103] Persons skilled in the art will appreciate that if, for example, a non-powered card is utilized then information indicating that a button was pressed may not be available. With respect to a non-powered card, information indicative that a purchase was made may be provided to an application manager provider such that the application manager provider can initiate the desired feature for the non-powered card. For example, the feature may be a default feature, a selected feature (e.g., selected using an application manager) and/or a random feature.

[0104] For non-powered cards, for example, features may be associated with different types of purchases. For example, one feature may be provided for a particular merchant type (e.g., a grocer's coupon) and another feature may be provided for a different merchant type (e.g., a clothing store coupon).

Features may be associated with other characteristics of a purchase such as, for example, a purchase above a particular amount (e.g., at or above $100) and/or a purchase below a particular amount (e.g., below $100). However, such additional feature selections are not limited to non-powered cards and may be provided to, for example, users of powered cards and devices.

[0105] According to example embodiments, any feature and/or capability not requiring a powered device (e.g., a computing device such as a powered card and/or mobile telephonic device) may be implemented with respect to a non-powered card and any feature and/or capability of a non-powered card may be implemented with respect to a powered card. According to at least one example embodiment, features and/or capabilities requiring a powered card may be implemented with respect to a non- powered card in various ways. For example, additional functionality may be provided at merchant terminals. [0106] GUI 403 may be provided, for example, on a card issuer's and/or application manager provider's website. GUI 403 may be provided, for example, on a bill statement web page. Accordingly, a user may utilize the application manager to manage application features when the user is logged into his/her account. Although example embodiments described with respect to FIG. 4 may describe a GUI 403 used to make various selections and/or associations, persons skilled in the art will appreciate that other methods are possible. For example, selections may be made by phone, email and/or the like.

[0107] A third party service provider may utilize GUI 403 as part of a user's administration and/or experience of that third party service. For example, a user's profile page for a third party service may include GUI 403. An application manager provider may provide web-code that retrieves GUI 403 from a remote facility managed by the application manager provider and/or other entity (e.g., issuer, merchant acquirer, payment network, merchant and/or the like). Selection 441 may be utilized by a user to check for updates (e.g., confirm that a feature was changed and/or if any updates are present). Selection 442 may be utilized to explain the functionality of a particular application feature. Selection 443 may be utilized for additional selection options, for example, changing which card is displayed on an application manager.

[0108] According to at least one example embodiment, a card may be provided with one button for a particular payment account (e.g., credit) and one button for a changeable feature. Accordingly, a user may, for example, only need to remember one feature associated with a card. A credit account may include rewards, for example, points, cashback, and/or miles, from the card issuer. Accordingly, pushing the payment account button may earn the user such rewards. Pushing the changeable feature button may, alternatively, for example, not earn the user such rewards and may instead initiate a changeable feature. In doing so, for example, the cost of providing a card may be reduced in that the cost of rewards for the card may be reduced. A feature may include, for example, a feature from a third party application provider. The feature from the third party application provider may be, for example, a random reward (e.g., a random coupon).

[0109] Information 411 may, for example, identify the user and card number associated with virtual card 412 and a corresponding physical card. One or more of tabs 405 may provide, for example, a history of purchases made by a user. An application manager may provide indicia reflecting a user rating (e.g., star rating 447).

[0110] According to example embodiments, an ecosystem provider may be the same or different from an application manager provider, a remote facility and/or other entities. One or more of the functions described herein as being performed by an application manager provider, and/or other entities, may be performed by the ecosystem provider. According to at least one example embodiment, an ecosystem provider may act as an application manager provider, application provider, issuer, merchant, third party service provider, payment network and/or the like to provide an end-to-end experience. In general, example embodiments contemplate the same, greater and/or fewer entities, and specific entities are described for purposes of explanation. [0111] One of ordinary skill in the art will appreciate that GUI 403 is provided for purposes of illustration only and may take various forms. For example, features may be associated to a card without buttons and/or a card may include the same, fewer and/or a greater number of buttons than depicted in FIG. 4.

[0112] Flip card option 491 may be utilized to flip a virtual card around to show a reverse of a card. Person skilled in the art will appreciate that a front of a virtual card and a back of a virtual card may correspond to a front of a physical card and a back of a physical card. For example, the back of a physical card may include a three or four digit security code and the back of a virtual card may also include a three or four digit security code (e.g., the same or a different security code). A personal identification code may be utilized to unlock a card so it can be utilized in a point-of-sale and/or permit one or more card numbers and/or security codes to be displayed. A personal unlocking code may unlock a card for a particular number of transactions (e.g., one, two, three, etc.) or for a period of time (e.g., an hour or an hour after a transaction).

[0113] Browsing arrows 492 and 493 may be utilized, for example, to change between different cards. A cardholder may, for example, load several card into a mobile payment wallet (e.g., on a mobile phone or a battery-powered card) and may scroll between different cards utilizing arrows 492 and 493. Arrow 492 may move to a card on the left of card 412 and arrow 493 may move to a card on the right of card 412. Person skilled in the art will appreciate that cards may be arranged in the order the cards were loaded, may be arranged in an order determined by a user (e.g., via an interface or via buttons/actions), and/or may be determined based on pre-determined settings. For example, the most used card may become the first card to be displayed or the last used card may become the first card displayed when a wallet is opened/displayed. [0114] FIG. 5 includes device 501 that may include contact chip 403, card account number 504, card account number 505, button array 506 that may include buttons 507-512, cardholder name 513, additional cardholder and/or card information 539, and any other communications device or structure (e.g., structures of card 100 of FIG. 1 and/or architecture 150 of FIG. 1). Applet 502 may be included in which a transaction field is detected, recognized as having an action associated with the detected transaction field (e.g., a particular value and/or range of values), and executing the action associated with the detected transaction field.

[0115] Persons skilled in the art will appreciate that one, two, tree, or more than three account numbers may be provided (e.g., printed and/or displayed) on one (e.g., obverse or reverse) side of a card or other device(s). Manual input interfaces may be associated to each card account so the card, or other device, communicates information associated with the selected manual interface. Manual interfaces may be, for example, mechanical interfaces (e.g., mechanical buttons), capacitive interfaces, or any other type of manual interfaces. Payment card account number, and associated information, may be downloaded to a card or other device and this downloaded payment card account number may be displayed on a display. Persons skilled in the art will appreciate that a payment card account number does not need to be displayed or printed on a card. Accordingly, a card may be utilized at a point- of-sale and the card may be secured from displayed the payment card number. Additionally, for example, a mobile telephonic device may provide a virtual card that displays a payment card account number, and associated data, for a payment card. That payment card account number may be associated with a payment account that is also associated with a payment card that does not have printed/displayed payment card account number. Persons skilled in the art will appreciate that multiple cards and/or devices may be associated with the same account and may have different payment card account numbers, and/or associated information. For example, a cardholder may have a card (virtual and/or physical) issued to a spouse and the devices/cards of the cardholder may be associated to the same account as the spouse so, for example, a single bill needs to be paid for both payment card account numbers. Similarly, for example, an employer may provide multiple workers with different payment card account numbers that are linked to the same account. Pan sequence numbers or other discretionary data may be utilized, for example, so that multiple cards/devices may have the same fifteen and/or sixteen digit account number but the differentiating information to distinguish the cards/devices is contained in the associated payment card data that is communicated at the point-of-sale (e.g., discretionary data). Accordingly, multiple devices may have the same printed/displayed card account number but different card data that is communicated through a transaction. Similarly, for example, tokens may be linked to overall cardholder accounts and these tokens may be utilized for individual cards/devices. Accordingly, new tokens may be issued to cards/devices (e.g., if a device is compromised) and be linked to the same account as the previous tokens so that a cardholder's experience is enhanced.

[0116] Card 500 may, for example, have a button associated with a credit payment functionality, a button associated with a pay with points/rewards functionality, and four buttons associated with an installment payment functionality (e.g. a 6-month, 12- month, 18-month, and 24-month installment functionality. Pressing different buttons may, for example, cause data to be changed in payment card data that is communicated to a point-of-sale reader (e.g., different discretionary data on the same payment account numbers, different payment account numbers, different pan sequence numbers, etc).

[0117] Device 550 may be the reverse side, for example, of device 500. Device 550 may include perimeter 651. Device 550 may include, for example, magnetic stripe 651, signature panel 652 for receiving pen marks (e.g., a signature), hologram 553, and printed or displayed indicia 654-659. Persons skilled in the art will appreciate that different payment options and/or cards may be utilized online by printing/displaying different security codes (e.g., CVV and/or CVC) on the card, For example, indicia 554 may be utilized as a card not present code for a credit transaction, indicia 655 may be utilized as an card not present code for a pay with points transaction, indicia 656 may be utilized as a card not present code for a first installment option (e.g., 6 month installments), indicia 657 may be utilized as a card not present code for a second installment option (e.g., 12 month installments), indicia 658 may be utilized as a card not present code for a third installment option (e.g., 18 month installment option)., indicia 659 may be utilized as a card not present code for a fourth installment option (e.g., 24 month installment option). Person skilled in the art will appreciate that a single display may be provided and a button (e.g., a button used to select a payment card account number or a different button) may be utilized to cause a security code (e.g., CVC code) to change to a CVC associated with that button (e.g., associated with that payment option). A security code may be displayed on a display with a payment card account number and a button associated with a different payment card account number and security code may cause the selected payment card account number and security code to change. Any number of security codes may be associated to, for example, a payment card account number. Additionally, for example, a security code may change based on use and/or time, for example, in order to provide additional security.

[0118] A card may include, for example, different payment account numbers, for example, to deploy a pay with point and/or pay with installment functionality and/or another type of payment functionality. For example, a payment card number (e.g., a credit card number) and a card not present security code (e.g., a CVC or CVV) associated with a credit payment may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side). On that same card/device, a different payment card number (e.g., a different credit card number) and a different card not present security code (e.g., a CVC or CVV) associated with a pay with rewards/points payment may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side). On that same card/device, a different payment card number (e.g., a different credit card number) and a different card not present security code (e.g., a CVC or CVV) associated with a first installment option may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side). On that same card/device, a different payment card number (e.g., a different credit card number) and a different card not present security code (e.g., a CVC or CVV) associated with a second installment option may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side). On that same card/device, a different payment card number (e.g., a different credit card number) and a different card not present security code (e.g., a CVC or CVV) associated with a third installment option may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side). On that same card/device, a different payment card number (e.g., a different credit card number) and a different card not present security code (e.g., a CVC or CVV) associated with a fourth installment option may be printed on a device (or displayed on a device) on the same side (e.g., the reverse or obverse side) or different sides (e.g., an obverse side a side other than the obverse side) [0119] Persons skilled in the art will appreciate that payment options may be utilized with any type of payment product (e.g., credit and/or debit) and may be embedded such as, for example, by utilizing discretionary data (e.g., one character, two characters, three characters, or more than three characters) of discretionary data in payment card transaction data (e.g., magnetic stripe data, EMV contact data, and/or EMV contactless data). In doing so, for example, the transaction may authorize for that payment type (e.g., credit) and credit interchange may be earned by an issuer. Post-authorization, for example, the discretionary data may be reviewed and if payment option data is recognized a second transaction may be initialized in order to, for example, implement the payment option (e.g., pay with point and/or installment). For pay with points, a point bank associated with an account may be adjusted based on the amount of the transaction so long as, for example, enough points are in the bank to cover the transaction amount. An amount of money equal to the points may then, for example, be deposited in the account and may, using an account-to-account (e.g., monetary file transfer) transfer approach be listed as a transaction on a statement with a transaction description describing that points were redeemed for a particular transaction. Partial pay with points may be utilized, for example, if a point bank does not have the appropriate number of points. Multiple pay with reward/point options may be provided such, as for example. Pay full in points, pay half in points, pay a percentage (e.g., 10%), pay a fixed amount (e.g., $5 or $10) in points. A pay with fixed amount or percentage may be pushed multiple times, for example, so a cardholder can select how many points the cardholder wants to spend on a card. Accordingly, for example, if a denomination was $1 then a cardholder could press the button 5 times to redeem $5 in points. Displays and/or other light sources (e.g., LEDs) may be utilized to indicate the amount of times the manual interface as been pressed and/or the amount selected). Similarly, interfaces may be utilized to select monthly installment amounts (e.g., a 1-month button may be pressed six times for a 6 month installment). A transaction may be authorized (e.g., on credit to earn credit interchange) and a secondary transaction may be initiated (e.g., by a remote server) after data has been recognized that an installment was desired in the payment data (e.g., magnetic stripe, emv contact, and/or emv contactless data).

[0120] Persons skilled in the art will appreciate that in addition to pay with rewards and/or pay with installments additional payment options may be deployed. For example, payment options may be associated with the selection of different types of rewards (e.g., cashback, miles, donations to charity, etc.), the utilization of an offer (e.g., a coupon), earning a chance to win a reward (e.g., a game of chance as in a sweepstakes), earning a game of skill to earn a reward, etc. Person skilled in the art will appreciate that a transaction such as a credit transaction may include a percentage earned towards rewards. Pressing a button such as a game of chance or game of skill may, for example, forfeit the earning such underlying rewards for a chance to earn a larger reward.

[0121] FIG. 6 shows payment device 600 that may include, for example, one or more speakers and/or microphones 602, cameras 603, housings 601, displays having displayed indicia 604 (e.g., percentage of battery remaining), displayed indicia 605 (e.g., time), indicia 606 (e.g., expandable menu), flip card virtual button 609, contact india 610, contactless indicia 625, light source indicia 611, light source indicia 612, light source indicia 613, light source indicia 614, interactive button 615, interactive button 616, interactive button 618, lightsource indicia 618, lightsource indicia 619, payment card number 621, information 622, network logo 623, card indicator 630, virtual card 607, virtual card 606, virtual card, 610, information area 631, indicia 632, indicia 533, indicia 634, information area 640, indicia 641, indicia 642, indicia 643, indicia 644, indicia 646, virtual button 647, virtual button 648, virtual button 649, virtual button 650, virtual button 655, manual interface 670, manual interface 671, and manual interface 672.

Persons skilled in the art will appreciate that device 600 may be any device such as a payment card or a mobile telephonic device.

[0122] Device 600 may include, for example, an executable native application and/or a web-based platform that provides the cardholder with a mobile wallet where multiple cards may be stored, browsed, selected, and utilized for both card present (e.g., point-of-sale terminals at a physical merchant location) and card-not-present (e.g., phone, mail, online) transactions. Cards may be loaded through various processes such as a host card emulation process (e.g., for issued virtual/physical cards) or a card personalization process (e.g., for cards not yet issued as virtual/physical cards). For example, a card that has been issued can be utilized in a host card emulation process to recognize the card and identify and authenticate the cardholder so that a virtual and/or physical card may be issued (e.g., on a new device such as a new card device or mobile telephonic device). A physical card (e.g., a battery powered card or a non-battery powered card) may be virtualized into a mobile device and may provide a similar experience or the experience may be enhanced. For example, a card with a credit button, an installment button with 4 installment toggles, and a pay with points button may be virtualized to have virtual buttons and provide the same functionality at, for example, a point-of-sale terminal (e.g., a contact, magnetic stripe, and/or contactless communication). For example, a consumer may select virtual button 617 to communicate information for a credit transaction, button 616 to communicate information for a pay with points transaction (e.g., on the credit rails), button 615 to communicate information for a pay with installment transaction (e.g., on the credit rails). Pressing button 615 may toggle through light source indicators 611-614 so the cardholder can select an installment option (e.g., 12-month equated monthly installment associated with light source indicator 612). Accordingly, light source indicators may transition from one state to another state based on a button associated with the light show indicator being utilized.

[0123] Persons skilled in the art will appreciate that information from a mobile device such as a mobile telephonic device may be communicated (e.g., wirelessly through a cellular modem) to a remote server. During a payment transaction, the information in this remote server may be communicated to a card or other device during a payment transaction such that information selected on a phone is delivered to a card. A payment applet in the card may utilize this data to provide different features. For example, a cardholder on a mobile telephonic device may change a virtual card from a credit card to a debit card and a static non-battery powered card may receive this data and change the data communicated in the transaction where the data is received or a subsequent transaction to change the card number (e.g., from debit to credit). Similarly, for example, a cardholder may select a particular option (e.g., installment option) and this may be communicated to a battery-powered card through data communicated through a payment transaction and the card may be switched to utilize that payment option. Data from a virtual card may be communicated to a physical card and may cause, for example, any action on a physical card such as light sources (e.g., LEDs) to activate on a physical card, images and/or messages to be displayed, cards to be loaded, etc. Persons skilled in the art will appreciate that a card and/or mobile device may communicate through a remote server to each other, directly to each other, through a remote server to each other during a payment transaction. Accordingly, information may be downloaded from one device to another device during a payment transaction (and vice versa) or, for example, information may be communicated outside of a payment transaction (e.g., directly or through a remote server or other system). More than two cards and/or devices may communicate with each other. For example, one card (e.g., a card of a business executive) may communicate to more than one other card (e.g., the card of multiple employees under the business executive). As per another example, a parent in a family may communicate information to cards and/or devices to a subset of the family (e.g., children) or all of the family (e.g., spouse and children). Communication rules and actions may be setup on a card, device, or other system (e.g., a website) and communicated to any device or system (e.g., the cards and/or other payment devices). Similarly, a website may provide controls. A cardholder may log into a website, authenticate themselves with a password, receive a mobile wallet, and may make selections on that mobile wallet that are then communicated to autonomous and adaptive program logic in a payment applet on one, more than one, or all devices with an association to the payment account(s) on the mobile wallet.

[0124] Persons skilled in the art will appreciate that a mobile payment wallet may be configured to a particular bank/entity, group of banks/entities, a particular payment networks, multiple payment networks, etc. Accordingly, for example, a mobile payment wallet may be provided as an executable application that may be downloaded from a mobile application service (e.g., an application store) and utilized for payment products for that particular issuer (or group of entities). Information may be stored on a remote server so that if a device (e.g., card or mobile telephonic device) is lost a new device may receive a login and/or password from a cardholder (or be identified in another way) and the previously stored information (cards, settings, information) may be restored. Similarly, if a device such as a card and/or mobile device is lost, a cardholder may go to a website (e.g., on any device) identify and authenticate themselves, retrieve the wallet, and deactivate cards so that the cards cannot be utilized on the lost cards. New cards may then be issued on non-lost devices so that when the other devices are loaded and/or logged into the new cards automatically update.

[0125] Card indicator 630 may be utilized, for example, to indicate to the user the location of the card (e.g., card 607) the cardholder is viewing as the primary card compared to the other cards. Card 607 may be in a mobile wallet with multiple cards such as card 608 and 624. Any number of payment card numbers may be associated with any single card on the mobile wallet, which may be provided on a display of a card, website, display of a mobile device, or any other device.

[0126] Information 631 may include information associated with a card associated with information 631 (e.g., a card currently selected by a cardholder). Information 631 may include information on the various payment card numbers, options, or any data associated with the card. For example, information 631 may include an available credit line (e.g., indicia 632), total credit line (e.g., indicia 633), and balance due (e.g., indicia 634). Information 635 may include, for example, title and associated information for attributes associated with a particular card (e.g., a select card of a mobile wallet). Person skilled in the art will appreciate that a physical card with multiple card numbers is a device that stores and utilizes multiple accounts (e.g., autonomously, as a result of manual input, etc.). Information 640 may be associated with, for example, a card of a mobile wallet such as, for example, a card being viewed in the mobile wallet. Such information may include a list of transactions the card has made, any associated options that were utilized, the amount, and any other information associated with the transaction (e.g., date and/or time). Indicia 641 may be associated with a merchant transaction on credit. Indicia 642 may be associated with a merchant transaction for an equated monthly installments (EMI). Terms associated with the payment option may be displayed such as, for example, the number of installments and a cost, if applicable, such as a fee and/or interest rate (e.g., a percentage rate and/or the resultant amount). Interactive buttons 647- 655 may be utilized to initiate additional features such as card features, statement features, home features, other features, and ask bank features. A card feature may, for example, provide a cardholder with an overview of cards and permit the addition, modification, and/or deletion of cards. A statement feature may include an overview of all statements, communication notifications for statements and other information such as transaction notifications (e.g., via text messaging and/or application notifications), home 649 may remove a cardholder from other features and bring the cardholder to a wallet usage and navigation screen (e.g., the graphical user interface of FIG. 6). Features 650 may be utilized to access additional features such as personal finance management tools, spending limits, etc. Ask a bank feature may be utilized, for example, to see a frequently asked questions, interact on a chat and/or phone with a representative, send a message (e.g., email message, and/or retrieve phone numbers for various departments, topics, and/or representatives. A device may include multiple manual user interfaces such as interfaces 670- 672 to operate the device, initiate applications such as one or more wallet applications, switch between open applications such as one or more wallet applications, and terminate applications such as one or more wallet applications.

[0127] Persons skilled in the art will appreciate that a card may be loaded in an active, ready for payment state so that a phone just has to be tapped against a terminal and contactless information may be communicated. A device may have a chip and/or expandable contact chip so that a mobile phone may have a portion that can be expanded out of the phone, or can be removed from the phone, for contact transactions. Magnetic stripe transactions may be performed wirelessly by wirelessly communicating magnetic stripe data to the magnetic stripe read-head of a magnetic stripe reader. A card may also show a QR code that may change with each payment card number and payment option and may also, for example, change with each transaction on that card number and payment option (e.g., for security via a dynamic QR code). Alternatively, for example, payment information may be ready to communicate as well as communicate after a button has been pushed (e.g., a credit button, points button, installment button, etc). A personal identification code may be utilized so that a request for a personal identification code is prompted at particular times (e.g., when a card is to be utilized for a card present and/or card not present transaction, a card is loaded into a wallet, modified, deleted, etc.).

[0128] FIG. 7 shows flow charts 710, 730, and 760. Flow chart 710 may include step 711 in which a contact, contactless, or another type of transaction may be initiated. Request for information from a payment applet may occur in step 712 and may include, requesting information from a point-of-sale terminal or other system (e.g., a remote server) for information about the transaction or if there is any information for a payment applet (e.g., control information). Persons skilled in the art will appreciate that a request for information may occur and a request for information step may not occur (just like any steps or processes). For example, information may be pushed to the payment applet (and/or vice versa). Received information may be stored in step 713, stored information may be reviewed in step 714. A determination may be based on the review and an applet may perform an action based on the reviewed information in step 715. An applet may shut down and the applet may wait for a new transaction to start or may start a new transaction and may do so in a different mode (e.g., with a different payment card number and/or different payment option). The transaction may complete in step 717 and the applet may stay in the same mode awaiting the next transaction. Person skilled in the art will appreciate that a payment applet may receive and sent information in any transaction (e.g., the transaction after a payment applet shut down).

[0129] Process 730 may be included and may include step 731 in which a static and/or dynamic card may be utilized in a transaction. Step 732 may be included and an operating mode for the card may be selected on an external device such as a mobile telephonic device. Accordingly, for example, a static card with no buttons may receive, in for example a payment applet, instructions during a transaction to change the card number, payment option, or other information or features and utilize the received information in executing a current or future payment transaction. A mobile telephonic device may, for example, communicate this information (e.g., to an issuing bank, to a payment network, to a third-party remote server, to the manufacturer of the card, to a manufacturer of the mobile telephonic phone, etc.) and this information may be pushed to the card or pulled from the car during a payment transaction or outside a payment transaction. [0130] Step 733 may be included in which mode selection, or other information, may be sent to a card other device or other system during a transaction.

Step 734 may be included in which an applet detects the received selection, stores the selection, reviews the selection, and includes any other steps. The payment applet may change to the desired and/or requested operating mode in step 735 and may restart the transaction. The transaction completes and the applet may stay in the desired mode in step 736 (e.g., for the next transaction, a certain number of transactions, and/or defaults to the mode for all transactions until, for example, changed). Cardholder may change the mode on an external device in step 737 and the new changed mode may be conveyed to any number of cards, devices, or other systems (e.g., a web-based system where all mode changes may be reviewed by cardholder and/or an admini7strator) during a transaction, outside of a transaction, directly to the device/card/system, or through one or more intermediary systems (e.g., remote servers).

[0131] Process 760 may be included and may include step 761 in which a cardholder may set a mode of a card (or other device) on an external device (e.g., a mobile telephonic device such as a mobile phone or a mobile watch). A digital card on the mobile device may be changed to the selection in step 762 and, at the next qualifying transaction, an associated physical card may also change to the selection in step 763.

[0132] Cardholder may set preferences when modes occur on a device in step 754. For example, a cardholder may set a preference of when modes change (e.g., current transaction or next transaction), attributes of modes (e.g., number of months in installments, amount of rewards being utilized, etc.) Information (e.g., mode information and/or preference information) may be conveyed to a card during a transaction in step 765. Card (or other device) may operate based on determined preferences in step 766 and preference recommendations may be provided to a cardholder (or administrator) based on usage data (e.g., transaction and/or device usage data) ins step 767. For example, a cardholder may be recommended improved strategies for installments and/or rewards usage to, for example, maximize rewards and/or minimize fees while achieving certain objectives (e.g., defer $X in a particular month or months).

[0133] FIG. 8 shows device 800. Device 800 may be, for example, a payment card or other payment device (e.g., mobile telephonic device).

[0134] FIG. 8 may include one or more dynamic magnetic communication devices and/or magnetic stripes 802, contact chips 803, contactless chips 804, manual interfaces 805, displays 806, wireless communication devices 807, memories 808, additional processors 809, light sources 810, batteries 811, input/output ports 812, peripherals 813, locating devices 814, image/video capture devices 815, sensors 816 (e.g., pressure, capacitive, inductive, magnetic), and/or other components 817.

[0135] A card may have a display such as a pixelated display operable of displaying a cardholders payment network logo, cardholder name, payment account number, payment expiration date, payment security code for online transactions (e.g., CVV2, CVC2), card name, and other pieces of information.

[0136] Messages associated with a particular time and/or date may be pre-stored. For example, messages associated with an anniversary date of the issuance of the card, consumer birthday information, country holidays, religious events, or any notification or message associated with a particular time or date. For example, a message wishing the consumer a happy birthday and providing the consumer with a QR code coupon for a certain amount in value may be displayed based on a date received during a payment transaction (and, for example, a clock in the payment device that updates the stored date as time passes). Persons skilled in the art will appreciate that a birthday event may trigger a feature such as a game feature where a consumer gets to pick a gift box from a number of gift boxes where each or one ore of the gift boxes has a different amount or type of value stored in it. Accordingly, a marketing campaign may be provided where on your birthday you have the chance to win a statement credit for your payment card bill in different amounts based on, for example, an instant no-purchase necessary sweepstakes where on the cardholders birthday the cardholder is provided instant statement credit value based on different odds of receiving different amounts of value. Pre-stored messages based on time could be provided so that a different message is released at a particular time (e.g., 9am EST) every day. Date-based messages could include for example, new years, Christmas, Ramadan, each day of hannakah, memorial day, independence day, election day, etc.

[0137] Messages may be displayed on the payment device for example based on the first authorized transaction after a certain date/time. For example, a message may be pre-stored and displayed on the first authorized transaction after the first year of being issued the payment device or payment account on the payment device.

[0138] Payment devices, such as payment cards, may include, for example, one or more displays, light emitting diodes, programmable magnetic stripes that can change the magnetic stripe data on the magnetic stripe, programmable EMV chips, programamble contactless chips, cellular chips and antennas for downloading data from a remote source, manual interfaces, sound interfaces, etc

[0139] Security features may be provided based on the received data. For example, a dynamic security code may be changed based on time and/or date information received from the payment device during an authorization transaction on a two-way authorization process (e.g., via an EMV or contactless transaction). The dynamic security code may provide a dynamic in- stripe security code (e.g., CVC1/CV1) and on-line security code (e.g., CVC2/CVV2). They may be the same or different security codes based on time and/or date or other information received and multiple types of information received (e.g., a different code may be provided based on time and country information received during a payment transaction).

[0140] Pre-stored messages may be provided based on any information received such as, for example, country code. A welcome message may be provided after a consumer makes a payment transaction in a new country that welcomes the user to the country and provides the consumer with payment information (e.g., exchange rates) based on that country. After each authorized transaction, for example, a card may display information on the transaction (e.g., amount of the transaction) in both the local and foreign currency by using information received and/or logic on the card. [0141] Transaction applets may be provided that changes the account or payment option information based on what was received during the transaction. For example, if a US card account is utilized in Spain then the card may change the account to a Spanish account for future transactions (unless otherwise directed by the cardholder). In doing so, the payment device can receive information and change the way the payment devices operated based on the received information. [0142] Any information could enable a new account (e.g., debit credit) or payment option (e.g., EMI, pay with points) for the current or a future transaction. A card can terminate a transaction based on information received and start a subsequent transaction (e.g., by having the cardholder remove and replace the card in a chip contact reader or reinstitute a new contactless transaction, etc. Persons skilled in the art will appreciate that payment terminals can be constructed to reinstitute transactions automatically if a transaction fails.

[0143] Example types of information receivable to cause modification of an applet, or by an applet, may include, for example, amount authorized (numeric), amount other (numeric), terminal country code, terminal verification results, transaction currency code, transaction data, data authentication code, ICC dynamic number, CVM results, transaction time, merchant custom code, transaction currency code, transaction date, transaction type, TVR, unpredictable number, or any other type of information from any source (e.g., a remote server of the issuer, processor, network, card manufacturer, device manufacturer, service provider, etc.)

[0144] Information may be pre-stored such as during personalization or during personalization updates. [0145] Personalization data may be, for example, encrypted. According to some example embodiments, encrypted personalization data may be sent over a transmission link (e.g., cell network, Bluetooth, NFC, etc.). A perso data block may have a unique session identifier preprogrammed into a secure element (SE) which may be used as part of an decryption process. [0146] Data may be encrypted at multiple levels. For example, a two level embodiment may include transmission link encryption. An entire block of perso data may be encrypted (e.g., 3DES, AES, etc.) during transmission. This block may be decrypted by, for example, a general purpose processor (GP). The GP may use a unique Session Identifier to request the transmission decryption key from the Secure Element. [0147] Such a two level embodiment may further include encryption of sensitive perso data (personal data of a cardholder) - sensitive perso data such as UDKs may be encrypted such that they will never be in the clear. This information may be sent encrypted to the SE (such as a secure element chip) and may be decrypted inside the Secure Element. This decryption process may be performed by an applet installed on the SE.

[0148] Cards may be preloaded with sets of keys in the SE that are associated with: Transmission Link Key - This key may be utilized by the GP to decrypt the entire perso data block that was received. The GP may provide the unique session identifier provided with the perso data Block to the SE such that the appropriate key can be provided. Multiple unique transmission keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades can be performed over the life of the card. This process may be protected from attacks by, for example, only allowing three attempts to request the transmission link key and if the proper unique session identifier is not provided within three attempts, the process may be blocked going forward. Sensitive Perso Data Key - This key may be utilized by the SE to decrypt sensitive perso data. The unique session identifier may be provided to the SE to be able identify the proper preloaded keys to decrypt the sensitive perso data. Multiple unique sensitive perso data keys (each associated with a unique Session Identifier) may be preloaded such that multiple perso upgrades may be performed over the life of a card. This process may be protected from attacks by only allowing three attempts to provide a unique session identifier and if the proper unique session identifier is not provided within three attempts, the process will be blocked going forward.

[0149] Personalization data may be pre-loaded. According to some example embodiments, preloading either multiple entire sets of perso data or multiple partial sets of perso data (which may be unique to this card) which may be triggered to be used by sending a signal to the card over a transmission link (e.g., cell network, Bluetooth, NFC, etc.) to change account information.

[0150] Complete sets of personal data and multiple sets of personalization data may, for example, be utilized which may include changes based on an update to PAN sequence number only or entirely different PANs can be preloaded on the SE. Each of the accounts may be associated with a Unique Account Identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the Unique Account Identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts, the process may be blocked going forward. [0151] Partial sets of personal data may, for example, be utilized in order to minimize the amount of data preloaded, only the unique data associated with an account upgrade (PAN, UDKs, certificates, etc.) may be preloaded. Multiple partial sets of Perso Data which may, for example, include changes based on an update to PAN sequence number only or entirely different PANs may be preloaded on the SE. Each of the Partial Sets of Perso Data may be associated with a unique account identifier programmed into the SE. When a change in account is deemed necessary a signal may be sent to the card including the unique account identifier associated with the next set of account data. This unique account identifier may be sent to the SE and if it matches the next account data the card may begin using that Account information. This process may be protected from attacks by only allowing three attempts to provide a unique account identifier and if the proper unique account identifier is not provided within three attempts then a protective action may occur (e.g., card may be disabled until cardholder properly identified, etc.).

[0152] FIG. 9 shows device 900 that may include a mobile payment wallet that can be pre-stored or can be modified to add any number of payment cards such as card 950. Card 950 amy include payment card account number 901, payment card account number 902, change virtual button 903, and change virtual button 904. Persons skilled in the art will appreciate that an account may be selected for use in a point-of-sale terminal by selecting a button that corresponds to an account. An account may be defaulted and may not need any button selection. Selection of a button (e.g., change to debit button 903) may change to debit account number 901 being utilized for transactions and button 904 may correspond to account number 902 being utilized. Persons skilled in the art will appreciate that the information on account selection may be communicated to a remote server and communicated down to a physical card that corresponds to virtual card 950 and a payment applet on this physical card may change at (e.g., starting at) the current and/or next transaction the selected account. Physical card associated with virtual card 950 may have similar features to card 950 such as, for example, two account numbers printed on the card (e.g., for card not present transactions) and associated information (e.g., security codes, expiration dates, etc.). Information 910 may correspond to information associated with card 950 and may include, or example, the available funds in the payment account numbers associated with card 950 9e.g., debit, credit, pre-paid, and/or any other type of payment product such as a secured credit payment product). Information 910 may include, for example, available credit, available debit, outstanding credit, etc. Information associated with transactions may be shown and may include transactions made on the accounts regardless of device. The type of device utilized may be shown on any device such as indicia 921 (e.g., a card transaction such as a physical card associated with virtual card 950) and indicia 922 (e.g., a phone transaction as a transaction with virtual card 950).

[0153] FIG. 10 may include device 1000 which may include virtual buttons 1001-1004, virtual buttons 1005-1006, and network logo 1009. Persons skilled in the art will appreciate that a card may have multiple logos such as multiple network logos such as multiple network logos for different network products (e.g., mastercard debit, mastercard world, mastercard world elite, etc). The logo may change, for example, based on the selected card. Features may be added utilizing one or more buttons 9e.g., buttons 1001 to 1004 such as different installment features. As a result, a consumer can add different installment options (e.g., 3-month, 6-month, 9-month, 12-month, 15-month, 18- month, 21-month, 24-month, 36-month, 48-month) installments and then select an option for a transaction. Buttons 1005-1008 may be utilized to also select cards and/or options. Persons skilled in the art will appreciate that after a feature is added, the feature may be shown and then may be selected and/or de-selected and/or changed. Features may be removed and new features may be added. New features may thus be issued after a physical card and virtual card has been issued and may be added by a cardholder and this may then be communicated to a physical card.

[0154] FIG. 11 may include device 1100 which may show another side of a card (e.g., the reverse side of card 1000 of FIG 10) and may include security codes 621-624. Persons skilled in the art will appreciate a different security code (e.g., CVC and/or CVV) may be associated with different options so that the virtual card can be utilized for online transactions with the same capability as in-store transactions. One or more installment security codes, point security codes, debit security codes, credit security codes, and other security codes associated with payment options and/or accounts may be utilized and these codes may be printed on devices (e.g., cards) as well as displayed on devices (e.g., battery-powered cards). Option 1110 may be utilized so that a cardholder may, for example, change the terms associated with a feature (e.g., the terms associated with an installment). Accordingly, for example, a cardholder may change the installment terms for one or more transactions (e.g., transactions going forward until changed). An installment transaction may on any device (e.g., card, phone, statements) be changed after a transaction is made.

For example, a cardholder can go to a statement and can change credit transactions to point and/or installment (e.g., part point, part installment) transactions (or another option) and can change installment terms at any time. For example, a cardholder that is on month 2 of a 6 month installment may change the installment to month 2 of a 12 month installment. A fee (e.g., fixed and/or percentage amount) may be charged for the change or as the functionality is deployed (e.g., as the installments occur in the future). Accordingly, a cardholder may have a dynamic statement where any transaction can be moved to another transaction type or option and may be, for example, get a new/additional cost and/or fee.

[0155] Information about an account may also be shown on the back of a card such as, for example, next to a security code associated with the information. Persons skilled in the art will appreciate that security codes for a payment card number, or another feature, may be provided on the same side as the payment card number. Indicia 1111 may be, for example, dynamic and may include the available point balance and may be associated with security code 1102. Option 1110 may be associated with security code 1101. Indicia

1112 may be associated with security code 1103 and may include the amount of available debit funds. Indicia

1113 may be associated with security code 1104 and may include the available credit line remaining. Person skilled in the art will appreciate that any information from any card or device may be communicated to another card or device and displayed. Accordingly, for example, indicia 1111-1113 may be communicated to a physical card that corresponds to the virtual card associated with indicia 1111-113 and displayed on the physical card.

[0156] Dynamics statements may be provided in which a cardholder can change past transactions from one type 9e.g., credit) to another (e.g., installment). Dynamic statements may have different sections associated with different transaction types (e.g., installment section and credit section) and a cardholder may take any credit transaction and move it to an installment (and vice versa). The statement may group transactions for installments based on original duration (e.g., group 12 month installments togetherO or remaining duration. Transactions may be ordered chronologically, magnitude of amount, magnitude of interest rate, remaining duration of installment, originally duration of installment, etc. Cardholders, for a fee or without a fee, may change installment duration even after, for example, the first installment payment has been paid for a transaction. Persons skilled in the art will appreciate that in providing dynamic statements a cardholder may change, month-to-month or day-to-day, their transaction decisions to decisions that better fit their month-to-month or day-to-day situations. For example, a cardholder may have a car accident and decide the cardholder wants to convert a number of credit transactions to installment transactions and may want to extend installment length for another number of transactions. Alternatively, for example, a cardholder may get a larger bonus than expected and may want to pay off installments faster (e.g., pay off entire installments or reduce the length of installments) as well as move installments to credit transactions or pay an outstanding credit transaction or monthly bill of transactions.

[0157] Persons skilled in the art will appreciate that an issuer predictive system may also be provided that utilizes the data from the cards and devices such as the installment, credit, point, etc. selection data to determine price insensitivities and sensitivities in particular cardholders and provides pricing based on those insensitivities and/or sensitivities. Furthermore, for example, such a platform may review traditional cards of a particular payment network for an issuer and provide recommendations to that issue on what cardholders should be issued battery-powered cards, cards with intelligent and information receiving and utilizing payment applets, and other features and which network and/or products should be initially put on the cards or other devices. Such a system may take into account various network incentives such that a platform may provide recommendations on what particular cardholders should be upgraded with new card technology as well as changed to a new network. Such a platform may, for example, provide estimates of value generation (e.g., expanded purchases) made across one or a set of individuals (e.g., the upgraded individuals) as well as the estimated value gain for the cardholder so the cardholder may be marketed the value gained by the upgrade and/or conversion.

[0158] Persons skilled in the art will appreciate that one or more applets may be associated with different buttons or modes for cards or other devices. Applets may also be associated with non-payment functionality (e.g., identification) or closed loop payment systems (e.g., transit systems or store payment systems) in addition to open loop systems (e.g., general purpose cards of a multi-national payment network that operates in more than 90% of countries). A card may be non-powered, for example, and may include a mechanical switch that may be mechanically moved and when the card is powered by an external reader (e.g., an EMV contact and/or EMV contactless reader) circuitry may detect the mechanical position of this switch and utilize the different positions to denote different consumer selections (e.g., selections of different accounts, options, applets, or other functionality). Such a mechanical switch may have two states, three states, or more than three states and may take the form, for example, of a sliding switch, height denominated switch, or any other type of interface that may be put into different states without power (e.g., and that can be read by circuitry such as circuitry such as a cards contact and/or contactless chip when power is applied to that circuitry and/or chip(s)). Accordingly, for example, data from a mobile device may be sent down to one applet, two applets, more than two applets, or a subset of applets during a transaction or outside of a transaction and cards, or other devices, may utilize the received information to change the operation of the applet (e.g., provide a different account and/or payment option) in the current transaction or the next transaction (e.g., starting the next transaction).

[0159] Persons skilled in the art will appreciate that the present invention is not limited to only the embodiments described, and that features described in one embodiment may be used in a different embodiment. The present invention more generally involves dynamic information and devices. Persons skilled in the art will also appreciate that the apparatus of the present invention may be implemented in other ways than those described herein. All such modifications are within the scope of the present invention, which is limited only by the claims that follow.

Claims

What is claimed is:

1. A payment card comprising: an applet stored on a processing chip; a contact structure coupled to said processing chip for electrically coupling said processing chip to a contact point-of-sale communication device to perform a contact payment transaction, wherein manual input data from an external device is operable to be communicated to said applet through said contact structure during said contact payment transaction, said applet receives said manual input data and determines whether to terminate said contact payment transaction and change payment data for a subsequent contact payment transaction based on said received manual input data;

2. The payment card of claim 1, wherein said RFID antenna coupled to said processing chip for electrically coupling said processing chip to a contactless point of sale communication device to perform a contactless transaction.

3. The payment card of claim 1, wherein said termination of said contact payment transaction occurs by said applet receiving an authorization for said contact payment transaction and not providing a confirmation of said authorization to said contact point-of-sale communication device.

4. The payment card of claim 1, wherein said manual input is representative of a debit card personal account number.

5. The payment card of claim 1, wherein said manual input is representative of a credit card personal account number.

6. The payment card of claim 1, wherein said external device is a wireless telephonic device.

7. The payment card of claim 1, further comprising a payment card personal account number, wherein said external device is a wireless telephonic device having a telephone number, wherein said telephone number and payment card personal account number are associated with the same entity.

8. The payment card of claim 1, further comprising a battery.

9. The payment card of claim 1, wherein said payment card does not include a battery.

10. The payment card of claim 1, further comprising a manual input interface.

11. The payment card of claim 1, wherein said payment card does not include a manual input device.

What is claimed is:

1. A device, comprising: three buttons; a printed circuit board (PCB) antenna operable to connect at least cellular low band, mid band and high band; a plurality of pressure sensors operable to determine velocity; a cellular chip; and a dynamic magnetic communications device operable to communicate data using a magnetic data waveform, wherein an encryption/decryption key between a payment network and the cellular chip is operable to be dynamically changed, and the wallet card device is operable to change an amplitude of the waveform.

What is claimed is:

1. A loyalty system, comprising: at least one apparatus operable to process five thousand to ten thousand transactions per second with a sub-second response time.

What is claimed is:

1.A payment device comprising: a first secure element; a second secure element a switch including a first mechanical position and a second mechanical position, wherein said first position enables said first secure element and said second position enables said second secure element.

2.A payment card comprising: a switch including a first mechanical position and a second mechanical position, wherein said first position enables a first payment option and said second position enables a second payment option, wherein said switch is powered with power received from a power contact of a contact payment card reader.

What is claimed is:

1. A method, comprising: receiving, by a payment device, data from a reader; analyzing the data to determine an event trigger associated with an event is present in the data; and providing a visual display associated with the event based on the event trigger.

2. A method, comprising: receiving, by a payment device, an issuer script from a reader, the issuer script including an event trigger associated with an event; and providing, on the payment device, a visual display associated with the event.

3. A method, comprising: receiving, by a payment device, an issuer script from a reader, the issuer script including instructions; and providing a visual display on the payment device based on the instructions.

4. The method of claim 1, wherein the data includes a processing options data objects list (PDOL).

5. The method of claim 1, wherein the data includes a card risk management data objects list (CDOL).

What is claimed is:

1. A device, comprising: a first contact chip with a first primary account number (PAN) in storage, said first PAN associated with a first payment method; and a second contact chip with a second PAN in storage, said second PAN associated with a second payment method. 2. The device of claim 1, wherein said first payment method is credit, and said second payment method is equated monthly installments (EMI).