A user, for example, may log into his/her online account to customize a new card. A user, for example, may log into his/her online account to delete, change and/or upgrade any options that may be associated with a user's current card. For example, a website may offer the same or similar user interface as may be offered by a kiosk. Accordingly, a user may utilize a remote location (e.g., an internet café) to access a website either to design a new card or to delete, change and/or upgrade any options that may be associated with a user's current card. Any virtual creations and/or changes made by the user via the website, may be saved for subsequent implementation at a manufacturing facility (e.g., a kiosk of the user's choosing).

Incentives to associate a new option (e.g., product) with a new or current card may be provided to a user. Such incentives may be displayed online (e.g., via a webpage) or by a GUI of a kiosk. For example, a user may associate an option with a virtual button of a virtual card on a GUI of a kiosk and may be provided with an incentive for the association. For example, a user may be provided with text indicating that if the user associates a particular product, then an amount of money may be added to a user's account. Once a physical card is produced from the kiosk, the card may provide control devices (e.g., buttons) to allow the user to utilize the incentives.

Architecture 150 may be utilized with any card. Architecture 150 may include processor 120. Processor 120 may have on-board memory for storing information (e.g., associated product information). 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. Memory 142 may be coupled to processor 120. Memory 142 may include data that is unique to a particular card. For example, memory 142 may include user-specific and card-specific data (e.g., name, account numbers, product information, and incentives for associated products).

Any number of reader communication devices may be included in architecture 150. For example, IC chip 152 may be included to communicate information to an IC chip reader. IC chip 152 may be, for example, an EMV chip. As per another example, RFID 151 may be included to communicate information to an RFID reader. A magnetic stripe communications device may also be included to communicate information to a magnetic stripe reader. Such a magnetic stripe communications device may provide electromagnetic signals to a magnetic stripe reader.

Different electromagnetic signals may be communicated to a magnetic stripe reader to provide different tracks of data. For example, electromagnetic field generators 170, 180, and 185 may be included to communicate separate tracks of information to a magnetic stripe reader. Such electromagnetic field generators 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 serially to a receiver of a magnetic stripe reader for a particular magnetic stripe track.

Read-head detectors 171 and 172 may be utilized to sense the presence of a magnetic stripe reader (e.g., a read-head housing of a magnetic stripe reader). The sensed information 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. Accordingly, 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 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.

Architecture 150 may include one or more sensors 160 (e.g., light sensors). Sensors 160 may receive information via, for example, light pulses communicated by a light source and sensed by sensors 160. Architecture may include one or more simulators 162 (e.g., touch simulators). Simulators 162 may simulate, for example, one or more human touches when pressed against a touch sensitive device (e.g., a touch sensitive display). Accordingly, architecture 150 may be used to transmit information to a touch sensitive display by simulating a series of touches that may be sensed by the touch sensitive display.

FIG. 2 shows kiosk 200. Kiosk 200 may include a user interface that may include, for example, display 210, keyboard 204, magnetic stripe reader 206, card slot 208, RFID interface 222, and programming/interrogation area 220. Compartment 202 may be included within kiosk 200. Accordingly, various card varieties 212-218 may be stocked within compartment 202 of kiosk 200. Card varieties 212-218 may include one or more variations (e.g., different hardware configurations) whose operation may be customized in accordance with a user's desires during a customization event. For example, card variety 212 may include a particular hardware configuration (e.g., two-buttons without a display). Card variety 214 may include, for example, an alternate hardware configuration (e.g., five-buttons with three displays). Persons skilled in the art will appreciate that many card varieties may be stocked within kiosk 200, where each card variety may include associated hardware configurations (e.g., processors, memory, input and/or output devices). Accordingly, each blank card and associated hardware configuration may be programmed and/or reprogrammed during one or more customization events to provide a card with customized operations that may be based upon design inputs received at kiosk 200 by a user of kiosk 200.

A customization event may include one or more design/alteration sessions held by a user at kiosk 200. For example, one or more GUIs may be presented by display 210 to allow a user to design a new card or to delete, change and/or upgrade any options that may be associated with a user's current card.

A user of kiosk 200 may, for example, utilize kiosk 200 to design a card having customized capabilities that may be associated with, for example, a particular hardware configuration of a particular card variety contained within compartment 202. A user of kiosk 200 may, for example, present his/her current card to an input device (e.g., card reader 206 or interrogation area 220) of kiosk 200. In doing so, kiosk 200 may interrogate the user's current card for any options that may be associated with the user's current card and display results of the interrogation onto display 210. For example, a user's current card may include one or more products that the user may wish to delete, change, and/or upgrade. By interrogating and displaying such products onto display 210, a user may make any alterations that he/she may desire by interacting with the various GUIs presented by display 210.

Kiosk 200 may include card slot 208. Card slot 208 may provide a means by which a user may discard his/her current card in exchange for a new card. Alternately, users may wish to delete, change, and/or upgrade their current cards without discarding them. Accordingly, interrogation devices (e.g., card reader 206, interrogation area 220, and RFID 222) may be utilized to glean a current configuration that may be associated with a user's current card. The current configuration may be displayed onto display 210 of kiosk 200 for subsequent monitoring and/or modification by a user.

Modification of a card's current configuration, for example, may be implemented by a programming region (e.g., programming area 220 of display 210). For example, a user's current card may be equipped with sensors (e.g., light sensors) that may be sensitive to light pulses generated within programming area 220 of display 210. The light sensors of the user's current card may receive a series of such light pulses, which may be construed as a configuration definition. For example, a user's current card may receive an optical data stream represented by a series of light pulses received from programming region 220. The optical data stream may define, for example, the operational mode of each component (e.g., button(s), display(s), data receivers, and data transmitters) that may exist within the user's current card.

A card may contain an RFID device having bidirectional data capability. Accordingly, RFID 222 may be used to interrogate a user's current card configuration for subsequent monitoring and/or modification via a series of one or more GUIs that may be displayed by display 210.

Display 210 may include interrogation area 220 that may be sensitive to touch (e.g., through use of a capacitive touch sensor). A card may include a corresponding electronic device that may simulate such a touch. In doing so, a user's current card may communicate with interrogation area 220 by simulating a series of touches that may be understood by kiosk 200 as a series of configuration data bits that may correspond to a configuration of a user's current card. Such configuration information may be subsequently monitored and/or modified via a series of one or more GUIs that may be displayed by display 210.

Card reader 206 may be used to interrogate a user's current card. For example, the user's current card may be inserted (e.g., swiped) into card reader 206. Configuration data may be transferred to kiosk 200 through operation of electromagnetic field generators present within the user's current card that are capable of communication with card reader 206. For example, electromagnetic field generators present within the user's current card may communicate configuration information to magnetic stripe track receivers in a read-head housing of a magnetic stripe reader (e.g., card reader 206). Such configuration information may be subsequently monitored and/or modified via a series of one or more GUIs that may be displayed by display 210. Other interrogation means (e.g., an IC chip reader or infrared transceiver) may also be employed to glean information associated with a user's current card.

FIG. 3 shows network topology 300. Kiosk 301 may include memory 318 and processor 310 for storing and executing code (e.g., GUI application code). The executed GUI application code may generate a series of interactive screens that may be displayed onto display 302 during a customization event (e.g., while a user designs and configures a new card and/or changes, deletes or upgrades options that may be associated with a user's current card).

Kiosk 301 may access a computer readable medium (e.g., CDs, DVDs, and internet 314) via input and/or output device 316. In doing so, executable code (e.g., GUI application code) may be accessed and downloaded into memory 318. Accordingly, processor 310 may execute one or more GUI applications such that a user conducting operations (e.g., card customizations) at kiosk 301 may do so interactively with kiosk 301. For example, a user may be prompted to execute one or more operations through instructions provided via display 302. Such operations may include discarding used cards into card tray 320 and/or presenting a card to kiosk 301 for interrogation of options (e.g., products) that may be associated with a card.

User input 306 may include a series of input operations (e.g., keyboard, mouse, and voice command) operations that may be prompted by a GUI displayed onto display 302. For example, a user may be prompted by a GUI during a customization event to define functional and aesthetic features that are to be associated either with a blank card or a user's current card. Such functional and/or aesthetic features may be rendered onto either a blank card or a user's current card.

In the event that functional and/or aesthetic features are to be associated with a new card, printer/programmer 312 may receive a blank card from card tray 320 and may install such functional and/or aesthetic features as directed by processor 310. In the event that functional and/or aesthetic features are to be associated with a user's current card, a user may first insert his/her current card into card tray 320 for subsequent delivery to printer/programmer 312 for installation of such functional and/or aesthetic features as directed by processor 310.

Configuration details and products that may be associated with a user's current card may be received from multimodal data processing device 328. For example, a user's current card may provide circuitry to simulate touch and area 328 of display 302 may be touch sensitive. Accordingly, by placing a user's current card against area 328 of display 302, a series of touches may be simulated by the user's current card that may be understood by processor 310 as a series of configuration data bits. Such configuration data bits may be indicative of configuration details and products that may be associated with the user's current card.

A user's current card may contain light sensors that may be sensitive to, for example, varying intensities and/or colors of light. Accordingly, programming area 328 may be used in conjunction with processor 310 to produce time-varying light color and/or intensity that may be received by the light sensors of a user's current card and understood by the user's current card as a series of configuration data bits. In doing so, a user's current card may be optically programmed by placing the user's current card against programming area 328 of display 302 while time-varying light color and/or intensity is used to convey configuration information to the user's current card.

Card development server 326 may be operable to execute similar, or the same, application code (e.g., GUI application code) as may be executed by processor 310 of kiosk 301. Accordingly, a user may access card development server 326 via a network (e.g., internet 314) to define aesthetic and/or functional features that he/she wishes to implement on either a blank card or a user's current card. Once completed, the functional and/or aesthetic features generated by the user may be downloaded from card development server 326 into memory 318 for subsequent access by the user. For example, a user may pre-define functional and/or aesthetic aspects of a customized card via the comfort of his/her own home, visit a kiosk of the user's choice, and download such functional and/or aesthetic features from card development server 326 into the kiosk of choice. Once downloaded, the user may either present his/her current card for modification or may choose to collect a newly customized card from the kiosk of choice. Such a modified current card or newly customized card may be based upon such pre-defined configuration details and may be produced for the user while the customer visits his/her kiosk of choice.

Kiosk 301 may connect to financial network 330. Accordingly, for example, kiosk 301 may provide access to all appropriate authorization servers, information databases, banking institutions, and payment networks that may be necessary to implement functions that may be performed by kiosk 301. For example, users may apply and request approval for one or more payment accounts that are to be associated with either a new card or a user's current card.

Accordingly, for example, kiosk 301 may seek approval and gain authorization for such accounts prior to their association to a card.

FIG. 4 shows GUI 400. GUI 400 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 400 that may include command section 402 that displays a command (e.g., “PLEASE MAKE A SELECTION”).

Such a command may prompt a user to utilize input devices (e.g., mouse, keypad, and touch/voice activated devices) that may be associated with a kiosk to respond to command 402. For example, GUI 400 may provide one or more responses 406-412 that may be selected by a user of the kiosk in response to command 402. The user may select an appropriate response, for example, by mousing-over and clicking on the desired response. GUI 400 may respond by providing feedback 404 (e.g., highlighted radio button) that is indicative of the user's selected response. Selected response 406 (e.g., “GET NEW CARD”) may signify that the user wishes to design a newly customized card at the kiosk. Other responses may include (e.g., “UPGRADE CURRENT CARD” 408, “BUY GIFT CARD” 410, and “TRADE-IN OLD CARD” 412).

GUIs executed by a processor may provide navigational aids (e.g., reverse-navigation 414 and forward-navigation 416). In doing so, a user may traverse all screens necessary to implement a particular customization event that may be required by a user.

FIG. 5 shows GUI 500. GUI 500 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 500 that may include command section 502 that displays a command (e.g., “PLEASE SELECT DESIRED CARD TYPE”).

GUI 500 may be displayed, for example, when a user wishes to create a newly customized card from a blank card. In some instances, the kiosk is stocked with a variety of blank cards having varied hardware configurations. The blank cards, therefore, may contain a number of hardware elements (e.g., buttons, displays, electromagnetic field generators, RFIDs, ICs, light sources, light sensors, infrared transceivers, and touch simulators), but may not contain any particular configuration definitions that define how the hardware elements operate.

For example, a blank card contained within a kiosk may be illustrated by virtual card 512 having virtual hardware elements (e.g., two buttons 518) and other hardware elements (not shown). A user wishing, for example, to design a card having two separate payment accounts associated with a single card may wish to select card type 504 as his or her virtual blank card selection.

Alternatively, a user may wish to select card type 506 as his or her virtual blank card selection. In this instance, for example, two virtual buttons 520 are illustrated as forming part of virtual card 514 along with virtual display 522 and other hardware elements (not shown) may also be provided. Users wishing to design a card having, for example, dynamic account number portion 522 may select virtual card 514 as their virtual blank card selection. Other virtual card selections may include virtual card 516 having, for example, a plurality of buttons, but with no account numbers displayed at all.

A kiosk may stock many varieties of cards, where each card variety may provide a particular hardware configuration. Should a user wish to design a virtual card that does not correspond to a card variety already contained within a kiosk, a user may select CUSTOM 510. In doing so, a user may design a customized hardware configuration that does not conform to any blank card variety contained within the kiosk. In such an instance, a non-conforming card design may nevertheless be transmitted from the kiosk (or card development website) to a manufacturing facility. In doing so, the user may not be able to retrieve a customized card at the kiosk itself, but may be able to upload a non-conforming design to a manufacturing facility for future delivery.

FIG. 6 shows GUI 600. GUI 600 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 600 that may include command section 602 that displays a command (e.g., “PLEASE SELECT ACCOUNT TRANSACTION”).

Once a user has selected a blank card variety, account transaction types, for example, may be associated with the blank card. For example, a user wishing to design a new card having two separate account numbers, may wish to select OPEN ACCOUNT 604 to begin the account selection process. OPEN MULTIPLE ACCOUNTS 612 may then be selected as an account transaction type to perform.

Payment products may include a selection of payment network brand associations. Accordingly, for example, desired network brand associations (e.g., BANK #1 614 and Bank #2 616) may be selected as payment products that may be associated with, for example, two of the many accounts that may ultimately be associated with the user's customized card.

FIG. 7 shows GUI 700. GUI 700 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 700 that may include command section 702 that displays a command (e.g., “PLEASE SELECT ACCOUNT DETAILS”).

Payment products may include products of various financial types (e.g., credit, debit, pre-paid, and installment) but those products may be offered by different associations (e.g., Discover, American Express, Visa, and MasterCard). Accordingly, a user may wish to associate at least one financial type with at least one payment network brand on a single card. A user may select, for example, Bank #1 as one payment network brand to be associated with a new card and may then select from one of many account types (e.g., installment, points, debit, and credit) to associate with the payment network brand.

GUI 700, for example, provides for such a selection by allowing the user to scroll through a list of financial types that may be associated with a particular brand by using scroll bar 704 and mouse operations to highlight a desired financial type (e.g., M/C credit). Should a user select more than one payment network brand to be associated with a new card, a user may similarly use scroll bar 706 to associate an additional network brand (e.g., Bank #3) to a particular financial type (e.g., Visa debit).

Depending upon which payment network brands and associated financial types a user has selected, GUI 700 may, for example, provide additional account details. For example, a credit financial type may require a user to supply further information to define terms (e.g., requested credit limit and requested interest rate) of such a credit account. Accordingly, for example, text input boxes 708 and 710 may be provided by GUI 700 to allow the user to define such terms. A debit financial type may require terms (e.g., account type and over-draft protection) to be specified. Accordingly, for example, text input boxes 712 and 714 may be provided by GUI 700 to allow the user to define such terms.

A kiosk may provide access to a financial network. Accordingly, for example, any payment network brands, associated financial account types, and associated terms that may be requested by a user via, for example, GUI 700, may be preauthorized by the kiosk. In doing so, products that a user may wish to associate with a new card may first be approved before being activated for use.

FIG. 8 shows GUI 800. GUI 800 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 800 that may include command section 802 that displays a command (e.g., “PERSONALIZE YOUR CARD”).

A user may select one or more aesthetic features of a card by interacting with GUI 800 to apply such aesthetic features. In addition, a user may gain instant feedback of the aesthetic features selected by viewing a virtual representation of such aesthetic features that may be placed onto a card during a customization event.

Virtual card 820, for example, may be updated by GUI 800 when a user selects which, if any, image link 806 is to be rendered onto the card. User selection may be effected, for example, by image link 806 that may allow a user to link to an image that may be network accessible (or otherwise accessible) by the kiosk. Accordingly, for example, a user may select an image to be rendered onto a new card using link 806, while obtaining instantaneous feedback from virtual card 820 as to what such an image might look like.

A user may select, for example, one or more color bands to be rendered onto a card by appropriate selection from scrolling list 804. Once selected, virtual card 820 may be updated with the color of choice. Persons skilled in the art will appreciate that various patterns may also be selected by a user so as to further enhance a background color that may have been selected by a user. A card may be further personalized with data that is specific to the user (e.g., the user's name). For example, a user may utilize text input 818 as a means to update virtual card 820 with user specific information. Font, style, color and other aesthetic attributes of text input 818 may also be further defined.

Any products that may have been associated with the card may also be identified in a manner that is pleasing and/or helpful to a user. For example, a button label that may be associated with a first payment account may be selected and rendered onto a card. Should such an account be a debit account, for example, a user may select button labels, such as “DEBIT” via scroll list 810, to identify that when a button so labeled is activated on an actual card, funds may be immediately authorized and debited from an associated debit account. Virtual representation of such a button label may be rendered onto virtual card 820 to provide feedback as to what such a button label may look like.

An additional product associated with a user's card may be labeled as, for example, “CREDIT” via scroll list 808, to identify that when a button so labeled is activated on an actual card, funds may be authorized from an associated credit account. However, such funds may not be immediately debited, but rather added to a credit balance that may be paid at a later date. Virtual representation of such a button label may be rendered onto virtual card 820 to provide feedback as to what such a button label may look like.

Virtual card 822 may be updated by GUI 800 when other aesthetic features (e.g., holographic link 812) are selected. Link 812, for example, may allow the user to link to various holographic images that may be network accessible (or otherwise accessible) to the kiosk. Once selected, virtual card 822 may immediately update the holographic image onto virtual card 822 for viewing. Other features (e.g., geometric features of a signature panel) may be designed. Text input boxes (e.g., boxes 814 and 816) may be utilized, for example, to design height and width features of a signature panel that may be displayed on a card. Once selected, virtual card 822 may immediately update the signature panel onto virtual card 822 for viewing.

FIG. 9 shows GUI 900. GUI 900 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 900 that may include command section 902 that displays a command (e.g., “PRINT CARD AND COLLECT REWARDS”).

GUI 900 may be displayed as a result of a user's request to associate one or more products (e.g., a debit card product and a credit card product) with a new card. Accordingly, status field 912 may indicate the results of a user's request, which may include the results indicative of an approval or disapproval of the request.

For example, a user's request to associate a product with a new card may include a request that the product include a particular financial type, associated terms, and payment network branding (e.g., a M/C credit account with an associated credit limit and interest rate). The request may include a particular financial institution. Accordingly, for example, status field 912 may provide the results of a request being sent by the kiosk to a financial institution for approval of such a requested product. Status field 912 (or an additional status field) may also provide status indicators for other products that may have been requested (e.g., a VISA debit account from checking with over-draft protection provided by an associated savings account).

A user's requested association of one or more products with a new card may include incentives for such association(s). For example, incentives (e.g., rewards points 908 and 910) may be associated with a new card when one or more products are requested and authorized.

Once all functional and/or aesthetic features of a user's new card have been defined, navigational button (e.g., PRINT CARD 914) may be activated. In doing so, a blank card may be retrieved from within a kiosk that conforms to a particular card variety (e.g., particular hardware configuration) as requested by the user. The hardware configuration of the blank card may be programmed in accordance with a user defined configuration as specified by the user at a user interface of the kiosk (or as specified by the user at a remote location that is network accessible to an appropriate card development server) during a customization event.

The blank card may be delivered to a printer located within the kiosk. Accordingly, any aesthetic features (e.g., images, holograms, labels, signature panels, colors, patterns, textures, card specific data, and user specific data) that may have been defined by the user may be rendered onto the user's new card. Once complete, the user may collect his or her newly programmed and/or personalized card directly from the kiosk. Alternately, the user may request that the card be delivered to the user at a different location (e.g., the home address of the user).

FIG. 10 shows GUI 1000. GUI 1000 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 1000 that may include command section 1002 that displays a command (e.g., “PLEASE SELECT ACCOUNT TRANSACTION”).

A user may wish to obtain a new card from a kiosk (or upgrade a current card), but may have one or more preexisting payment accounts. Accordingly, a user may select an account transaction (e.g., TRANSFER EXISTING ACCOUNTS 1004) to allow the user to transfer all or a portion of a preexisting account balance to a new product that may be associated with a new card (or a user's current card). Such a selection may be reflected by feedback (e.g., highlighted radio button 1004) that is provided to the user via GUI 1000 to confirm the user's selection.

A user may wish to close a preexisting account or leave a preexisting account open once a balance, or partial balance, transfer has been requested. Accordingly, for example, through appropriate selection via scroll list 1006 and associated mouse operations, a user may request that the preexisting account remain open or be closed irrespective of whether the full or partial balance is transferred from the preexisting account to the new product associated with the new or current card.

Once transfer of one or more accounts is requested, GUI 1000 may query the user for more information. For example, GUI 1000 may request that the user insert the user's preexisting card(s) into a card reader of the kiosk (e.g., via command 1008). In doing so, the kiosk may retrieve account information transferred during the card swipe that may be necessary to effect such account transfer(s). Alternately, a user may transfer account information into the kiosk via other means (e.g., manual, RFID, IC chip, infrared, or touch simulation).

Account transfer information may be programmed into a user's new card via programming facilities provided within the kiosk. Should a user wish to upgrade his or her current card with the account transfer information, for example, the user may present his or her current card to the kiosk to effect the transfer. For example, the user's current card may employ receivers (e.g., light sensors) that when placed against a programming area of a display of the kiosk, may be receptive to data transferred to the card via light pulses presented to the user's current card by the display's programming area. The user's current card may be programmed by other means (e.g., electromagnetic data transfer, RFID data transfer, infrared, or contact-based data transfer).

Appropriate status may be displayed by GUI 1000 as to the success or failure of the account transaction as requested by the kiosk. Such status may also reflect the success or failure of any authorizations that may be required by the one or more financial institutions involved with the transaction.

FIG. 11 shows GUI 1100. GUI 1100 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 1100 that may include command section 1102 that displays a command (e.g., “PLEASE SELECT ACCOUNT TRANSACTION”).

A variety of products (e.g., gift card products) may be associated with either of a new card or a user's current card. GUI 1100 may be utilized, for example, to allow a user to transfer dollar amounts associated with a preexisting gift card to one or more products that may be associated with a user's new or current card.

Scroll list 1106 and associated mouse operations, for example, may allow a user to select a gift card account that may be associated with one or more retail department stores. A dollar amount may be associated with such a gift card account. Should the user be in possession of a gift card, the user may present the gift card to the kiosk (e.g., the user may swipe the gift card through a magnetic stripe card reader of the kiosk) to ascertain account details (e.g., the dollar value that may be associated with the gift card) when commanded to do so (e.g., via command 1108). Alternately, the user may log into his or her online gift card account via, for example, a network browser that may be accessible from the kiosk.

Once a gift card account and related account information becomes known to the kiosk, the information may then be associated with the user's new or current card. For example, gift card account and related information may be programmed into a user's new card via, for example, programming facilities provided within the kiosk. Alternately, the user's current card may employ receivers (e.g., light sensors) that when placed against a programming area of a display of the kiosk, may be receptive to data transferred to the card via light pulses presented to the user's current card by the display's programming area. The user's current card may be programmed by other means (e.g., electromagnetic data transfer, RFID data transfer, infrared, or contact-based data transfer).

FIG. 12 shows GUI 1200. GUI 1200 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 1200 that may include command section 1202 that displays a command (e.g., “PLEASE SELECT ACCOUNT TRANSACTION”).

A variety of products (e.g., loyalty-based products) may be associated with either of a new card or a user's current card. GUI 1200 may be utilized, for example, to allow a user to transfer loyalty-based products (e.g., rewards points) that may be associated with one or more of a user's rewards programs to one or more products that may be associated with a user's new or current card.

Scroll list 1206 and associated mouse operations, for example, may allow a user to select a rewards program that may be associated with one or more service-oriented organizations (e.g., airlines or rental car agencies). A number of rewards points may be associated with such a service account. Should the user be in possession of a rewards card, the user may present the rewards card to the kiosk (e.g., the user may swipe the rewards card through a magnetic stripe card reader of the kiosk) to ascertain account details (e.g., the points value that may be associated with the rewards card) when commanded to do so (e.g., via command 1208). Alternately, the user may log into his or her online rewards account via, for example, a network browser that may be accessible from the kiosk.

Once a rewards account and related account information becomes known to the kiosk, the information may then be associated with the user's new or current card. For example, rewards account and related information may be programmed into a user's new card via, for example, programming facilities provided within the kiosk. Alternately, the user's current card may employ receivers (e.g., light sensors) that when placed against a programming area of a display of the kiosk, may be receptive to data transferred to the card via light pulses presented to the user's current card by the display's programming area. The user's current card may be programmed by other means (e.g., electromagnetic data transfer, RFID data transfer, infrared, or contact-based data transfer).

FIG. 13 shows GUI 1300. GUI 1300 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 1300 that may include command section 1302 that displays a command (e.g., “PLEASE SELECT ACCOUNT TRANSFER MODE”).

GUI 1300, for example, may be displayed when a user wishes to manually transfer information relating to a preexisting account into a kiosk. Feedback (e.g., highlighted radio button 1304) may confirm such a user's desire. A preexisting account may relate to any number of account types (e.g., credit, debit, gift, installment account) and may be associated with any number of payment network brands (e.g., VISA, M/C, American Express) as well with any number of financial institutions.

Account data transfer may begin with the user manually typing information (e.g., name, address, and account number) into scroll list 1306. Once complete, the user may submit the account information to the kiosk (e.g., via command 1308). Prior to being associated with products of a new card or a user's current card, the account information may be verified and authenticated via network facilities that may be available to the kiosk.

FIG. 14 shows GUI 1400, which may be used by a user wishing to transfer account information to a kiosk via, for example, electromagnetic data transfer as confirmed by feedback information (e.g., highlighted radio button 1402). Such an account data transfer mode may be preferred by a user should the user be in possession of any card having a magnetic stripe and/or a magnetic stripe emulator capable of conveying information electromagnetically. A user may be prompted by a kiosk through a series of commands (e.g., commands 1404-1408) to effect the account information transfer. Should an additional transfer be necessary, optional command (e.g., command 1410) may be presented by GUI 1400 to prompt the user to present the card once again to the kiosk.

FIG. 15 shows GUI 1500, which may be used by a user wishing to transfer account information to a kiosk via, for example, RFID as confirmed by feedback information (e.g., highlighted radio button 1502). Such an account data transfer mode may be preferred by a user should the user be in possession of any card having RFID capability. A user may be prompted by a kiosk through a series of commands (e.g., commands 1504-1508) to effect the account information transfer.

FIG. 16 shows GUI 1600, which may be used by a user wishing to transfer account information to a kiosk via, for example, the display of the kiosk as confirmed by feedback information (e.g., highlighted radio button 1602). Such an account data transfer mode may be preferred by a user should the user be in possession of any card having touch simulation technology. For example, a card may provide electronics that may simulate human touch (e.g., the card may generate a change in capacitance that may be sensed by a touch-sensitive display). Through a series of simulated touches, a card may transmit a series of data bits to a touch-sensitive display of a kiosk, where the data bits transmitted may be understood by the kiosk as account information. A user may be prompted by a kiosk through a series of commands (e.g., commands 1604-1608) to effect the account information transfer.

Persons skilled in the art will appreciate that other data transfer modes may be used. For example, cards employing IC technology (e.g., EMV technology) may transfer data to a kiosk that provides corresponding EMV chip contacts that may be utilized for data transfer from a card to the kiosk.

FIG. 17 shows GUI 1700. GUI 1700 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 1700 that may include command section 1702 that displays a command (e.g., “MAKE YOUR OWN GIFT CARD”) and sub-command section 1704 that displays a sub-command (e.g., “DRAG AND DROP UP TO FOUR DIFFERENT MERCHANTS”).

GUI 1700 may be utilized by users wishing to add products (e.g., gift card products) to a new card or a user's current card. Virtual card 1708, for example, may represent either a new card or a user's current card. Scroll list 1706 may be utilized by a user at a kiosk to scroll through a list of products that may be associated with virtual card 1708.

For example, a user wishing to associate one or more gift products (e.g., a BEST BUY gift product) with virtual card 1708 may utilize drag-and-drop operation 1710. For example, a user may mouse over to an icon within scroll list 1706 that is representative of a merchant of interest (e.g., BEST BUY). A user may then execute, for example, a series of mouse operations to drag-and-drop the icon onto virtual card 1708. Feedback indicating a successful drag-and-drop operation may include a rendering of a corresponding icon on virtual card 1708 after the drag-and-drop operation is complete. Other drag-and-drop operations (e.g., drag-and-drop operations 1712-1714) may be additionally executed until the user is satisfied with the products associated with virtual card 1708 as confirmed by the icons rendered onto virtual card 1708.

Virtual card 1708 may be representative of a user's current card. Accordingly, any icons displayed onto virtual card 1708 may be displayed as a result of an interrogation performed by a kiosk on a user's current card. For example, products (e.g., gift card products) may be associated with a user's current card. A kiosk may interrogate a user's current card in order to ascertain such preexisting gift card products and may then render icons representative of such preexisting gift card products onto virtual card 1708 for monitoring by a user. A user's current card may be equipped with any number of transmission capabilities (e.g., electromagnetic, RFID, touch simulation, infrared, and EMV chip) to transmit information related to such preexisting gift card products in response to such an interrogation.

FIG. 18 shows GUI 1800. A sub-command (e.g., sub-command 1802) may be displayed by GUI 1800 to allow a user to assign dollar values to gift card products that may be associated with a new virtual card. Alternately, GUI 1800 may be displayed in order to provide the user with a listing of preexisting gift card products and dollar amounts that may be associated with such preexisting gift card products on a user's current card. Accordingly, a user may either alter a preexisting gift card amount, or may enter a new gift card amount, into text input boxes (e.g., 1804-1808) as required.

FIG. 19 shows GUI 1900. A sub-command (e.g., sub-command 1902) may be displayed by GUI 1900, for example, to provide direction and capabilities to a user to personalize a new card (e.g., a new gift card). For example, text input boxes 1904 and 1906 may be utilized by GUI 1900 to allow a user to type one or more custom messages (e.g., HAPPY BIRTHDAY). Additional functionality provided by GUI 1900 may, for example, provide drag-and-drop operations (e.g., operations 1908 and 1910) to allow the user to drag custom text messages onto virtual card 1912 as directed by a sub-command (e.g., sub-command 1914).

Other aesthetic features (e.g., color, texture, background color/design, and various images) may be further rendered onto a virtual card. For example, such applications may be provided by GUI 2000 of FIG. 20. Scroll list 2002 may provide, for example, a palette of background designs that may be applied to virtual card 2008. By using a series of input commands (e.g., mouse events) scroll list 2002 may be navigated to locate and apply an acceptable background design. Feedback may be provided to the user (e.g., automatic updates to the background design rendered onto virtual card 2008 by GUI 2000) to allow the user to instantly view what such a background design might look like. Similarly, for example, scroll list 2004 may be navigated to locate and apply an acceptable background color that, for example, may be applied as a color used for the background design as selected via scroll list 2002.

Once all of the aesthetic and/or functional features of the new card have been attributed to virtual card 2008, a user may send a print/program job (e.g., by selecting command button 2006) to a printer/programmer that may be implemented within the kiosk. For example, a configuration description that defines the functional operation of virtual card 2008 may be transmitted to a programming facility within the kiosk to program (e.g., via IR programming) a blank card contained within the kiosk. Any aesthetic features that may have been applied to virtual card 2008 may be rendered onto the card by a printing facility that may be implemented within the kiosk. The fully functional and personalized card, for example, may then be delivered to the user from the kiosk for immediate use by the user.

FIG. 21 shows GUI 2100. GUI 2100 may be rendered onto a display of a kiosk by a processor implemented within the kiosk. A processor may be executing application code (e.g., GUI application code) that is effective to display GUI 2100 that may include command section 2102 that displays a command (e.g., “UPGRADE YOUR CURRENT CARD”).

GUI 2100 may be displayed as a result of a user's request to change (e.g., upgrade, delete, or replace) products that may be associated with a user's current card. A sub-command (e.g., sub-command 2104) may be provided by GUI 2100 to instruct the user to present his or her current card to the kiosk for interrogation. For example, a user's current card may be equipped with a magnetic stripe (or a device that may emulate a magnetic stripe). Accordingly, a user may insert the card into a card reader (e.g., a magnetic stripe reader) of the kiosk so that a description of the current configuration of the user's current card may be transmitted to the kiosk from the card via electromagnetic data.

Alternately, a user's current card may be equipped with touch simulation electronics that may simulate a human touch (e.g., electronics, that when activated, may indicate to a touch-sensitive display that the display has been touched by a human finger). In so doing, a user may present his or her current card to an interrogation region of a display of the kiosk and transmit information to the kiosk via the interrogation region as a series of simulated touches. As a result, information indicative of the current configuration of the user's current card may be communicated to the kiosk via a series of simulated touches that may be understood by the kiosk as a series of configuration data bits. Persons of ordinary skill will appreciate that other means of communicating configuration data bits (e.g., RFID communication or contact-based communication) may be used.

GUI 2100, for example, may allow a user to monitor a card's current configuration by displaying results of the interrogation. For example, a user may verify that a particular product (e.g., a VISA credit account) may be currently associated with the user's current card. Such a verification may be reported to the user via update region 2108 that may include a listing of all products currently associated with the user's current card.

A user may wish to make changes to the current configuration of the user's current card. Accordingly, for example, a user may choose to add products to the user's current card. GUI 2100 may be used, for example, to select one or more additional products to be associated with the user's current card.

For example, the user may navigate through a list of products (e.g., product providers) via scroll list 2110 that may offer products of interest to the user. Any selected providers may be updated to the user through feedback provided by selection confirmation area 2112 of GUI 2100. A further mouse operation (e.g. mouse click within region 2118) may be effective to move a selected object within selection confirmation area 2112 onto upgrade region 2114 of virtual card 2106. In so doing, a user may verify through feedback which, if any, product providers have been added to virtual card 2106.

GUI 2100, for example, may be used to select one or more products to be disassociated from the user's current card. For example, the user may use mouse operations (e.g., mouse clicks) to select currently associated products within region 2108. Any selected products may be updated to the user through feedback provided by selection confirmation area 2112 of GUI 2100. A further mouse operation (e.g. mouse click within region 2120) may be effective to remove a selected object from virtual card 2106. In so doing, a user may verify through feedback which, if any, products have been removed from virtual card 2106.

FIG. 22 shows GUI 2200, which may be used, for example, to further define one or more additional products to be associated with the user's current card. For example, the user may navigate through a list of products (e.g., financial types) via scroll list 2206. Any selected financial types may be updated to the user through feedback provided by selection confirmation area 2212 of GUI 2200. A further mouse operation (e.g. mouse click within region 2208) may be effective to further define account details of products (e.g., product providers) that may have been previously added to upgrade region 2214 of virtual card 2216. In so doing, a user may verify through feedback which, if any, product providers and associated financial types have been added to virtual card 2216.

FIG. 23 shows GUI 2300, which may be used, for example, to further define one or more additional products to be associated with the user's current card. For example, the user may wish to select details of a term (e.g., credit limit) that may be associated with a product (e.g., financial type) that may have been added to the user's current card. A mouse operation (e.g. mouse click within region 2306) may be effective to, for example, increase a credit limit of a financial type previously added to the user's current card. Accordingly, a user may verify through feedback (e.g., region 2308) details of any product providers, associated financial types (e.g., M/C credit), and credit limit (e.g., $10,000) that may have been added to the user's current card.

GUI 2300, for example, may redefine (e.g., delete, upgrade, or downgrade) details of products that may already be associated with a user's current card. For example, a mouse operation (e.g. mouse click within region