Enhanced user interface for contactless payment function in mobile telephone   

This application claims the benefit of provisional patent application No. 61/058,704, filed Jun. 4, 2008, which provisional application is hereby incorporated herein by reference.

Payment cards such as credit or debit cards are ubiquitous. For decades, such cards have included a magnetic stripe on which the relevant account number is stored. To consummate a purchase transaction with such a card, the card is swiped through a magnetic stripe reader that is part of a point of sale (POS) terminal. The reader reads the account number from the magnetic stripe. The account number is then used to route a transaction authorization request that is initiated by the POS terminal.

In pursuit of still greater convenience and more rapid transactions at POS terminals, payment cards have more recently been developed that allow the account number to be automatically read from the card by radio frequency communication between the card and a so-called “proximity reader” which may be incorporated with the POS terminal. In such cards, often referred to as “proximity payment cards” or “contactless payment cards”, a radio frequency identification (RFID) integrated circuit (IC, often referred to as a “chip”) is embedded in the card body. A suitable antenna is also embedded in the card body and is connected to the RFID chip to allow the chip to receive and transmit data by RF communication via the antenna. In typical arrangements, the RFID chip is powered from an interrogation signal that is transmitted by the proximity reader and received by the card antenna.

MasterCard International Incorporated, the assignee hereof, has established a widely-used standard, known as “PayPass”, for interoperability of contactless payment cards and proximity readers.

It has been proposed that the capabilities of a contactless payment card be incorporated into a mobile telephone, thereby turning the mobile telephone into a contactless payment device. Typically a mobile telephone/contactless payment device includes integrated circuitry with the same functionality as the RFID IC of a contactless payment card. In addition, the mobile telephone/contactless payment device includes a loop antenna that is coupled to the payment-related IC for use in sending and/or receiving messages in connection with a transaction that involves contactless payment.

The present disclosure addresses issues related to a user interface that may facilitate use of mobile telephones for contactless payment transactions and other types of transactions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a plan view of a mobile phone (in a flipped open condition) in which the present invention may be applied.

FIG. 2 is a block diagram representation of the mobile phone of FIG. 1.

FIG. 2A is a flow chart that illustrates a process that may be performed in the mobile phone of FIGS. 1 and 2 in accordance with aspects of the present invention.

FIGS. 3-8 show screen displays that may be displayed, in accordance with aspects of the present invention, on a display component of the mobile phone of FIGS. 1 and 2.

FIG. 9 is a flow chart that illustrates a process that a user may perform using the mobile phone of FIGS. 1 and 2 in accordance with aspects of the present invention.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodiments of the present invention, the user interface in a mobile telephone includes a wallet icon in a main menu. When the user selects the wallet icon, the user interface shifts to a display in which small images of identification cards (e.g., payment cards such as debit or credit cards) are presented. The small card images serve as a menu from which the user may select one of the identification cards. Once the user has selected one of the small card images, the selected image is displayed alone by the mobile phone, and in a larger scale. At that point, if the user positions the mobile phone for reading by a proximity reader, then the mobile phone uploads to the proximity reader an identification number which corresponds to the selected and displayed card image. In this way, for example, the user may select among a number of payment card accounts for use in a current purchase transaction.

FIG. 1 is a plan view of a mobile phone 100 (in a flipped open condition) in which the present invention may be applied. The mobile phone 100 includes a conventional hinged housing 102, including a display housing portion 104 and a control housing portion 106. The display housing portion 104 and the control housing portion 106 are hingedly joined together at a hinge 108. A conventional display component 110 is mounted in the display housing portion 104. Various control buttons and switches are mounted on the control housing portion 106. These buttons and switches include a conventional telephone numeric keypad 112. The buttons and switches also include a “select” button 114 nested within a four-way rocker/scroll switch 116. Further buttons and switches include soft keys 118 and 120, a start call key 122 and an end call key 124.

FIG. 2 is a block diagram representation of the mobile phone 100. Since the mobile phone 100 is also operable for contactless payment transactions, in addition to conventional mobile phone functions, it will sometimes be referred to herein as a mobile telephone/contactless payment device.

The mobile telephone/contactless payment device 100 may include a conventional housing (indicated by dashed line 202 in FIG. 1) that contains and/or supports the other components of the mobile telephone/contactless payment device 100. The mobile telephone/contactless payment device 100 further includes conventional control circuitry 204, for controlling over-all operation of the mobile telephone/contactless payment device 100. Other components of the mobile telephone/contactless payment device 100, which are in communication with and/or controlled by the control circuitry 204, include: (a) one or more memory devices 206 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 208; (c) the above-mentioned keypad 112 (which for present purposes will be understood to include the other buttons, switches and keys referred to above) for receiving user input; and (d) the above-mentioned display component 110 for displaying output information to the user.

The mobile telephone/contactless payment device 100 also includes conventional receive/transmit circuitry 216 that is also in communication with and/or controlled by the control circuitry 204. The receive/transmit circuitry 216 is coupled to an antenna 218 and provides the communication channel(s) by which the mobile telephone/contactless payment device 100 communicates via the mobile network (not shown). The mobile telephone/contactless payment device 100 further includes a conventional microphone 220, coupled to the receive/transmit circuitry 216. Of course, the microphone 220 is for receiving voice input from the user. In addition, a loudspeaker 222 is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 216.

In conventional fashion, the receive/transmit circuitry 216 operates to transmit, via the antenna 218, voice signals generated by the microphone 220, and operates to reproduce, via the loudspeaker 222, voice signals received via the antenna 218. The receive/transmit circuitry 216 may also handle transmission and reception of text messages and/or other data communications via the antenna 218.

The mobile telephone/contactless payment device 100 may also include an integrated circuit (IC) or chipset 224 of the kind embedded in contactless payment cards. The IC/chipset 224 may also be referred to as a “payment circuit”. The payment circuit 224 may store a payment card account number that identifies a payment card account that has been issued to the individual who owns the mobile telephone/contactless payment device 100. Further, the mobile telephone/contactless payment device 100 may include a loop antenna 226, coupled to the payment circuit 224. The payment circuit 224 may operate so as to interact with an RFID/NFC proximity reader of a POS terminal to provide the payment card account number (stored in the payment circuit 224) for a purchase transaction at the POS terminal. For example, the payment circuit 224 may be designed/programmed to operate in accordance with the above-mentioned “PayPass” standard.

In some embodiments, the payment circuit 224 may be at least partially integrated with the main control circuit 204. A payment application program may run in the payment circuit 224/control circuit 204 and be stored in the mobile phone 100. Functionality as described herein may be provided from program instructions stored in the payment circuit 224/memories 206. The stored program instructions may control a processing element which may be the control circuit 204 or which may constitute at least part of the payment circuit 224. In accordance with conventional teachings, the mobile phone 100 may include a “secure element” (not separately shown) which may constitute a portion of the payment circuit 224/control circuit 204 or of the SIM card 208. The secure element may store the payment application program and payment card account number and/or other sensitive information related to the payment capabilities of the mobile phone 100.

In its hardware aspects, the mobile phone 100 may be entirely conventional, but it may be programmed, in accordance with aspects of the invention, to provide a novel user interface and other novel functionality.

FIG. 2A is a flow chart that illustrates a process that may be performed in the mobile phone 100 in accordance with aspects of the present invention. FIGS. 3-8 show screen displays that may be displayed, in accordance with aspects of the present invention, on the display component 110 of the mobile phone 100. In particular, FIGS. 3-8 illustrate aspects of the novel user interface referred to above.

Referring now to FIG. 2A, the process may begin with a decision block 252, at which the mobile phone 100 determines whether the user has requested access to the main menu of the user interface. The user may do so, for example, from the “welcome screen” shown in FIG. 1 and displayed on the display component 110 of the mobile phone 100. For example, the user may request the main menu by actuating the left-hand soft key 118 to select the menu screen.

Until the user requests the main menu, the process of FIG. 2A may idle at decision block 252, as indicated by branch 254 from decision block 252. However, once the mobile phone determines that the user has requested the main menu, the process of FIG. 2A may advance from decision block 252 to block 256. At block 256, the mobile phone displays the main menu, which is shown in FIG. 3. That is, the main menu display of FIG. 3 replaces the welcome screen.

As seen from FIG. 3, the main menu may be displayed in a fairly conventional format, except that one of the menu icons presented is a “wallet” icon 302. The user may navigate among the menu icons in a conventional manner, e.g., by operating the rocker switch 116 (FIG. 1). A menu item is highlighted, as is conventional, when the user navigates to the menu item. In FIG. 3, the wallet icon 302 is shown as highlighted via the highlight indication 304. The highlight indication indicates that the icon in question may currently be selected by actuating the select button 114 (FIG. 1). Thus with the menu display in its condition shown in FIG. 3, actuation of the select button 114 results in selection of the wallet icon 302. (The highlight indication around a menu item may, for example, be referred to as a cursor.)

Referring again to FIG. 2A, a decision block 258 may follow block 256 in the process of FIG. 2A. At decision block 258, the mobile phone 100 determines whether the user has selected the wallet item. If not, block 260 follows decision block 258. At block 260, the process may idle, or may proceed to provide other functionality as represented by selection of a menu item/icon other than the wallet icon 302.

The user may select the wallet icon by moving the cursor to the wallet icon, and then actuating the select button. If at decision block 258 the mobile phone 100 determines that the user has selected the wallet icon 302, then the process of FIG. 2A may advance from decision block 258 to block 262.

Selection of the wallet icon may provide the path by which the user may access functions such as a contactless payment function. More generally, selection of the wallet icon may allow the user access to a “virtual wallet” application encompassing not only one or more contactless payment options, but also other identification functions commonly performed by cards that may be stored in one\'s wallet. Such other identification functions may include, for example, building access (e.g., via an RFID card), transit system access (via an RFID card), prepaid telephone calling card, etc.

At block 262, a display such as that shown in FIG. 4 may replace the display of FIG. 3 and may displayed on the display component 110 of the mobile phone 100. (For purposes of the present example, it is assumed that only contactless payment options are included in the virtual wallet incorporated in mobile phone 100, but as noted above, other functionality may also be included in the virtual wallet.)

FIG. 4 may be considered to be a virtual wallet menu display, and the virtual wallet menu is seen to comprise a plurality of images 402, 404, 406, 408, with each of the images 402, 404, 406, 408 representing the face or front side of a respective payment card issued to the user of the mobile phone. It will be noted that each of the card-face images 402, 404, 406, 408 shows, among other information, the payment card account number for the card in question. (Those who are skilled in the art will recognize that payment card account numbers are a type of identification number. From earlier discussion it will be understood that card-face images for other types of cards may be displayed in addition to or instead of the payment card face images, and that identification numbers other than payment card account numbers may be included in such card-face images for other types of cards.) It will also be observed that the card-face images 402, 404, 406, 408 do not overlap with each other. Rather, each of the card images is entirely surrounded by the background of the virtual wallet menu display.

In addition to including payment card account numbers, the card-face images may display other information customarily included on the face of a payment card. This information may include, for example, the name of the cardholder (e.g., an individual cardholder\'s name and/or the name of a company or other organization in the case of a “fleet” card). Other elements of the card-face image may include the name and/or logo of the payment card association which authorized the issuance of the card, and the name and/or logo of the issuer (that is, the issuing financial institution). The expiration date of the card may also be included in the card-face image.

The user may navigate among the card-face images/menu items by, e.g., operating the rocker switch 116. The virtual wallet menu display in its condition as shown in FIG. 4 includes a highlight indication 410 to indicate that the user has navigated to the card-face image 406. Consequently, if the user actuates the select button 114, doing so will effect selection of the card-face image 406, and thereby will also effect selection of the payment card account that corresponds to the payment card represented by the card-face image 406. As will be seen, selection of that payment card account may result in the corresponding payment card account number being wirelessly transmitted from the mobile phone 100 to a POS terminal (not shown) in connection with a purchase transaction.

To take a step or two backward from the virtual wallet menu display of FIG. 4, it should be understood that at least some of the data required to represent or build the card-face images may have been downloaded to the mobile phone 100 from an issuer or service provider computer system in conjunction with downloading of the corresponding payment card account numbers and related information. As is familiar to those who are skilled in the art, the process of loading account- or card-specific information into a mobile phone (or indeed any payment card or device) is commonly referred to as “personalization”. It is contemplated for present purposes that personalization may take place via any conventional mechanism or by any mechanism that is hereafter proposed. Examples of personalization mechanisms that may be used are over-the-air (OTA) personalization, or personalization via short range RF communication with a personalization card, as disclosed in commonly-assigned U.S. patent application Ser. No. 11/870,144. The \'144 application is hereby incorporated herein by reference.

To elaborate, in accordance with aspects of the present invention, conventional “personalization” transactions for mobile phones may be augmented with downloading of the image information to allow for display of a card-face image that corresponds to the payment card account number and other information downloaded to the mobile phone during personalization. The image information may be a bit map, or may include background color indicators, logo indicators, and/or other data from which the mobile phone is able to construct a bit map image for the card face in question. One technique for representing the card image data in an efficient manner is disclosed in commonly-assigned U.S. patent application Ser. No. 12/170,550. The \'550 application is hereby incorporated herein by reference.

The personalization process may, in some embodiments, result in the payment card account number, the image information, and other data all being stored in a payment application program that is stored in the mobile telephone 100. It may typically be the case that a separate personalization process was performed for each card image/account number included in the wallet menu display.

(As will be appreciated from subsequent discussion herein, the card image information loaded into the mobile phone during personalization may also include information required to display and/or construct an image of the rear face of the payment card in question.)

Returning again to FIG. 4, it will be noted that the virtual wallet menu display also includes an “Add New Card” menu item/icon 412. If the user were to navigate to and select the menu item 412, that interaction may result in launching a process in the mobile phone 100 whereby a new payment card account is added to the virtual wallet. (That is, this may be a personalization process.) As part of such a process, for example, the mobile phone 100 may access the website of an issuer that has already issued to the user a payment card for which information has yet to be downloaded to the mobile phone 100. The mobile phone\'s access to that website may automatically cause the issuer computer to download the corresponding payment card account number and other related information, including card-face image information, to the mobile phone 100. In this way, personalization of the mobile phone may occur with respect to the already-issued-but-not-yet-downloaded payment card account. This may also result in addition of the payment card account in question to the virtual wallet.

In an alternative process to be launched via selection of the menu item 412, the mobile phone may access the website of an issuer that has pre-approved, but not yet issued, an additional payment card account for the user of the mobile phone. As a result of the mobile phone accessing the latter website, the new payment card account may be issued by the issuer, the mobile phone may be personalized with the new account information (including downloading of the card-face image information), and the new payment card account may be added to the virtual wallet in the mobile phone.

Referring again to FIG. 2A, decision block 264 may follow block 262 in the process of FIG. 2A. At decision block 264, the mobile phone 100 may determine whether the user has selected one of the card options in the virtual wallet menu of FIG. 4. For example, and referring to FIG. 4, the user may select the card option illustrated at 406 by actuating the select button 114 with the virtual wallet menu display in the condition shown in FIG. 4. As noted above, actuation of the select button under those conditions would result in selection of the card-face image 406.

If at decision block 264 the mobile phone 100 determines that the user has not selected a card option, then the process may idle through blocks 262-264, as indicated by branch 266 in FIG. 2A. However, if at decision block 264 the mobile phone 100 determines that the user has selected one of the card options, then the process of FIG. 2A may advance from decision block 264 to block 268. Assuming that the selected card option were option 406, then block 268 would result in the screen display of FIG. 5 being displayed on the display component in place of the screen display of FIG. 4. It will be observed from FIG. 5 that the virtual wallet menu is no longer presented, having been replaced with an enlarged version 502 of the card-face image 406 of FIG. 4. The presence of the large card-face image 502 is a visual cue to the user that he/she has completed selection of the payment card account which corresponds to the payment card account number 504 included in the image 502. As noted above, selection of the payment card account in question may lead the corresponding payment card account number to be transmitted by the mobile phone to a POS terminal in connection with the next contactless payment purchase transaction that the mobile phone is used for.

Continuing to refer to FIG. 5, other elements included in the large card-face image may include the cardholder\'s name 506, valid from date 508, valid to date 510 and card brand (i.e., association brand) logo 512.

The process of FIG. 2A may advance from block 268 to decision block 270. At decision block 270, the mobile phone 100 may determine whether it has been utilized so as to initiate a transaction. If not, the process may idle through block 268 and 270, as indicated by branch 272 from decision block 270.

As is familiar to those who are skilled in the art, the user may initiate such a transaction by tapping the mobile phone on a proximity/contactless reader component (not shown) of a POS terminal (not shown). Bringing the mobile phone into proximity with the proximity reader in this manner may expose the mobile phone 100 to an interrogation signal transmitted from the proximity reader, which in turn may stimulate the mobile phone to exchange wireless RF communications with the proximity reader in accordance with conventional principles (including communication of the selected payment card account number from the mobile phone to the proximity reader). The selection of the user\'s desired payment card account for the transaction may occur before or after tapping the mobile phone on the reader, and may be accomplished by the above-described navigation through the virtual wallet menu display to the “account selected” screen display of FIG. 5. In some embodiments, if there is no default payment card account in the virtual wallet and the user has not just previously selected the payment card account, then tapping the mobile phone on the reader may cause the mobile phone to display the virtual wallet menu display of FIG. 4 with a prompt (not shown) such as, “Select Card”. (In this scenario, the “Add New Card” menu item may be omitted from the virtual wallet menu display.) Then, after the user selects the card and navigates to the account selected screen display, the user may be required to tap the mobile phone again on the reader to consummate the transaction. Consummating the transaction may include the mobile phone wirelessly transmitting the selected payment card account number to the proximity/contactless reader, and exchanging other data between the reader and the contactless payment application/circuitry of the mobile phone. In accordance with some conventional practices, the mobile phone may cryptographically generate a dynamic security code (CVC3) for the transaction and transmit the dynamic security code to the reader.

Referring again to FIG. 2A, if the mobile phone 100 determines at 270 that it has been utilized to initiate a transaction, then block 274 may follow decision block 270. At block 274, the mobile phone 100 uses, for the current transaction, the payment card account number which corresponds to the card option selected by the user from the virtual wallet menu.

In the particular example described up to this point, it has been assumed that the wallet function of the mobile phone is being used in connection with a purchase transaction at a POS terminal. However, in other cases the identification information to be supplied from the wallet function may be an identification number other than a payment card account number, and the mobile phone may be caused to interact with a proximity reader used for facilities access, transit system access, or some other purpose other than payment.

For the most part, up to this point, selection of menu options in the mobile phone 100 has been described in terms of locating a cursor at the item to be selected and then actuating a select button. However, according to an alternative method of selecting menu items, the display component 110 of the mobile phone 100 may be a touch screen, and selection of a menu item may be accomplished by the user touching the display with his/her finger or a stylus at the location of the menu item to be selected.

It will be observed that FIG. 4 and the other display screen figures are presented in the appended drawings quite a bit larger than life size. Thus the details, for example, of the enlarged card-face image 502 of FIG. 5 are quite a bit more visible in the drawings than they may be in a practical embodiment of the present invention. To compensate for the small size of the card-face image in such cases, the virtual wallet application may include a “zoom” function that, for example, would allow the user to selectively enlarge portions of the image 502. This may aid the user in reading information such as the payment card account number from the image 502. The zoom function may be accessible by single-, double- or triple-clicking on portions of the image 502. Alternatively, the zoom function may be accessible by an “options” menu (not shown) reached by actuating the left-hand soft key 118 (FIG. 1) when the screen display of FIG. 5 is displayed (note the “Options” label 514—FIG. 5—for the left-hand soft key).

Another function that may be accessible via the screen display of FIG. 5 is a “flip card” (a/k/a “flip”) function. This function may be accessible via the above-referenced “options menu”. Alternatively, this function may be accessible by single-, double- or triple-clicking the large card-face image 502 of FIG. 5. However accessed, the flip function may cause the screen display of FIG. 5 to be replaced with the screen display shown in FIG. 6.

Referring then to FIG. 6, the screen display shown therein includes a card-back image 602. The card-back image 602 may be substantially the same size as the card-face image 502 of FIG. 5. The card-back image 602 may represent the rear side of the same payment card of which the front side is represented by the card-face image 502.

The card-back image 602 may include a number of different elements including, for example, the user\'s signature 604 and a security code (CVC2) 606. Further elements may include issuer contact information such as one or more toll-free customer service telephone numbers and the address of the issuer\'s website (e.g., a cardholder customer service website).

In some embodiments, the card-back image may be a composite image assembled from a variety of image elements. For example, the signature element 604 may be derived from an image of the user\'s signature stored in the issuer\'s records, and may be combined with other elements, such as a stock frame image that is modified to reflect card specific information such as the CVC2.

The zoom and flip functions may also be accessible via the display of FIG. 6. For example, the user may use the flip function to navigate back from the display of FIG. 6 to the display of FIG. 5.

FIG. 7 is a screen display that may be presented on the display component 110 in connection with a function in which the mobile phone emulates a conventional reader/chip card combination for the well-known Chip Authentication Program (CAP). As those who are skilled in the art will understand, CAP is a two-factor authentication scheme for internet banking employed in Europe.

The mobile phone may thus be used to generate a code (displayed at 702 in FIG. 7) that the user can use to log onto internet banking. CAP currently requires users to generate a code using a reader device that verifies the user\'s card is present to reduce or eliminate the possibility of stolen card details being used without the card. The mobile phone may have all the chip card data stored in the virtual wallet application and thus may be able to generate the necessary code 702 provided that the user enters the correct PIN into the mobile phone. With this functionality, the user may be allowed to log onto internet banking without needing to have either the chip card or the reader, and only by using the mobile phone as the code generator. This may be especially useful in reducing the number of items the user needs to take with him or her while traveling.

The wallet application may allow the user to top up his/her payment card by directly contacting the issuer of the payment card from the mobile phone. The mobile phone may allow the user to view the balance in his/her payment card account (see FIG. 8, reference numeral 802). The mobile phone may also allow the user to select a top up amount from a menu 804. After the user enters his/her PIN and connects to the issuer, the balance may automatically update and be instantly available to the user. This may be accomplished, for example, via a transfer of funds from another account.

Embodiments of the invention, as described and depicted herein, may be particularly advantageous in presenting the wallet icon on the main menu, so that the user may readily and conveniently access the virtual wallet application. In some embodiments, various visual designs for the wallet icon may be available for selection or downloading by the user, so that the user can customize the appearance of the main menu at least to the extent of the wallet icon. At least some of the wallet icon visual designs may be produced by designers who are independent of the application provider and/or the issuers.

In some embodiments, the mobile phone may have voice recognition capabilities. Moreover, those capabilities may tie in to the virtual wallet application such that the user may be allowed to select a particular payment card or other identification or access card in the wallet application simply by speaking the name of the card into the microphone of the mobile phone. For example, if the user speaks the words “MasterCard debit” into the phone, this would automatically select the user\'s MasterCard debit card from the wallet application and activate it for use in the next or current contactless payment purchase transaction.

FIG. 9 is a flow chart that illustrates a process that a user may perform using the mobile phone 100 in accordance with aspects of the present invention.

The context of FIG. 9 may be a visit by the user to a retail store. The process of FIG. 9 is presented largely from the point of view of the user.

At 902 in FIG. 9, the user selects the items that he/she wishes to purchase and carries them to the checkout counter/POS terminal (not shown). At 904, the user enters a personal identification number (PIN) into the numeric keypad 112 of the mobile phone 100. In some embodiments, the mobile phone may operate such that a payment transaction (or at least a transaction in an amount above a certain limit) is not enabled unless the PIN had been recently entered into the phone.

For present purposes, it will be assumed that the user has previously selected a particular payment card account in the mobile phone 100 to use for the transaction (e.g., in the manner illustrated in FIG. 2A) or that programming in the mobile phone 100 has established a default payment card account number to be used for purchase transactions except when another payment card account number has been selected. It will also be assumed for present purposes that the total monetary amount of the intended purchase transaction is large enough such that the payment card issuer requires the user to submit a signature in connection with the transaction.

At 906, the user taps the mobile phone 100 on the proximity reader component of the POS terminal. As discussed above, this may lead immediately to an exchange of wireless communication between the mobile phone 100 and the proximity reader in which the relevant payment card account number is uploaded from the mobile phone 100 to the POS terminal.

At 908, the user waits while the resulting authorization request is generated or transmitted from the POS terminal. This may, but need not, include the POS terminal receiving a response to the authorization request from the card issuer.

At 910, the merchant requests that the user provide his/her signature, which the user may do, for example, by “signing” a tablet screen at the POS terminal with a stylus or by using a pen to inscribe his/her signature in ink on a transaction ticket.

At 912, in response to the merchant\'s request, the user displays a stored image of his/her signature on the display component of the mobile phone. For example, the user may do this be using the “flip” function referred to in connection with FIGS. 5 and 6 to cause the mobile phone 100 to display the rear card-face image shown in FIG. 6. The displaying of the user\'s signature as part of the rear card-face image is indicated at 914 in FIG. 9. The merchant may then compare the signature currently provided by the user per step 910 with the stored signature image displayed by the mobile phone at 912 to aid in authenticating the user\'s identity.

The process illustrated in FIG. 9 has elements that promote transaction security both for the cardholder and for the merchant. For the cardholder, the requirement that a he/she enter his/her PIN to enable the transaction adds a second (knowledge) factor to the first (possession) factor inherent in a payment-enabled phone. For the merchant, the display of the user\'s stored signature via the mobile phone display allows the merchant to authenticate the user\'s signature with substantially the same reliability as has conventionally applied with cardholder signatures carried on the back of payment cards.

In some embodiments, the mobile phone 100 may be programmed such that entry of the user\'s PIN into the mobile phone is effective only for a limited period of time (say, a few minutes or less). Once the period times-out, the user may be required to enter the PIN into the phone again to enable the next transaction that is over the no-signature-required limit.

In some embodiments, the enlarged card-face images or the card-back images may be rotated relative to the display component so that the length axis of the image is aligned with the longer dimension of the display component.

As the term “payment transaction” is used herein and in the appended claims, it should be understood to include the types of transactions commonly referred to as “purchase transactions” in connection with payment card systems.

As used herein and in the appended claims, the term “initiating a transaction” includes a proximity payment device such as a payment-enabled mobile telephone communicating a payment card account number to a POS terminal.

The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps.

Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.