US008016192B2
`
`(12) United States Patent
`US 8,016,192 B2
`(0) Patent No.:
`Sep. 13, 2011
`(45) Date of Patent:
`Messergesetal.
`
`(54)
`
`(75)
`
`USER-CONFIGURABLE PRIORITY LIST FOR
`MOBILE DEVICE ELECTRONIC PAYMENT
`APPLICATIONS
`
`Inventors: Thomas S. Messerges, Schaumburg, IL
`(US); Ruben R. Formoso, Weston, FL
`(US)
`
`(73)
`
`Assignee: Motorola Mobility, Inc., Libertyville, IL
`(US)
`
`Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 894 days.
`
`(21)
`
`Appl. No.: 11/448,241
`
`(22)
`
`Filed:
`
`Jun. 6, 2006
`
`(65)
`
`(51)
`
`(52)
`
`(58)
`
`(56)
`
`Prior Publication Data
`
`US 2007/0278290 Al
`
`Dec. 6, 2007
`
`Int. Cl.
`
`(2006.01)
`GO6K 5/00
`US. Ch oe. 235/380; 235/379; 705/39; 705/41;
`705/44
`
`Field of Classification Search.................. 235/375,
`235/379, 380, 381; 705/1.26, 27, 28, 29,
`705/35, 39, 40, 44
`See application file for complete search history.
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`7/1997 Carlisle etal. oe 705/41
`
`3/1998 Klingman ........
`379/93.12
`1/2004 Phametal. wc 726/2
`
`5,649,118 A *
`5,729,594 A *
`6,678,828 Bl *
`
`.........0... 455/557
`8/2004 Zalewski et al.
`6,771,981 B1*
`6,959,202 B2* 10/2005 Heinonen etal. .......... 455/556.1
`
`6,976,011 B1* 12/2005 Capitant et al. oc... 705/67
`7,024,174 B2*
`4/2006 Nagy etal. .........
`.. 455/408
`_.. 235/380
`.
`7,494,055 B2*
`2/2009 Fernandesetal. .
`
`2/2010 Niimi .....0....
`.. 455/407
`7,660,574 B2*
`7/2002 Huddetal. oc 705/64
`2002/0087478 Al*
`
`w. 455/406
`2002/0142751 Al* 10/2002 Abe ou...
`2/2004 Pondetal. occ 705/16
`2004/0030601 Al*
`2005/0006461 Al
`1/2005 Shenker
`2007/0255797 AL* 11/2007 Dunnetal. on. 709/217
`
`* cited by examiner
`
`Primary Examiner — Thien M. Le
`Assistant Examiner — Christopher Stanford
`(74) Attorney, Agent, or Firm — Ingrassia Fisher & Lorenz,
`PC.
`
`(57)
`
`ABSTRACT
`
`A mobile device as disclosed herein can support a plurality of
`electronic payment applications such as credit and/or debit
`applications. During a payment
`transaction,
`the mobile
`device communicates a priority list of the electronic payment
`applicationsto a point of sale terminal, which then selects one
`ofthe applications for completion ofthe paymenttransaction,
`wherethe selection is governed bythepriority list. The data
`structure correspondingtothe priority list is configured such
`thatthe end user ofthe mobile device has managementaccess
`rights to at least some ofthe electronic payment applications.
`Such end user management access rights can be used to
`modify the relative priority of the electronic paymentappli-
`cations.
`
`15 Claims, 6 Drawing Sheets
`
`
`
`SELECT PAYMENT NEGOTIATION APPLICATION
`106
`(GET PRIORITY LIST)
`108
`(CARD PRIORITY LIST)
`
`
`
`110
`
`SAMSUNG 1008
`
`SAMSUNG 1008
`
`1
`
`

`

`U.S. Patent
`
`Sep. 13, 2011
`
`Sheet 1 of 6
`
`US 8,016,192 B2
`
`801
`
`(1SALIMOMdGud)
`
`(1SALIMOId139)
`
` OH
`
`[DI4
`
`NOILVONMddVNOILWILODSNLNSWAVd19373S
`
`90!
`
`
`
`
`
`
`
`2
`
`
`
`

`

`U.S. Patent
`
`Sep. 13, 2011
`
`Sheet 2 of 6
`
`US 8,016,192 B2
`
`al2
`
`202
`
`eo
`
`9
`
`208
`
`eee)
`soa)
`
`1. ACME CREDIT
`2. MARK 1 CREDIT
`3. MY BANK DEBIT
`4. GIFT CERTIFICATE
`9.|NEW CREDIT
`
`203
`
`206
`
`| 203
`
`200
`
`3
`
`

`

`U.S. Patent
`
`Sep. 13
`
`’
`
`2011
`
`Sheet 3 of 6
`
`US 8,016,192 B2
`
`oleOrg8067
`
`0&§8¢§
`
`
`
`JOVAYSLNIOlavy
`
`
`
`QSyiMyVvINT1A9
`
`JAN
`
`oldgvy
`
`908
`
`WAOS
`
`
`
`AV1dSI0NETS
`
`AOVAYSLNI
`
`2067
`
`6o§
`
`008
`
`ALISNDSS
`
`FINGOW
`
`ONISSSOONd
`
`SYNLOALIHONV
`
`AYOWSN
`
`oggalg
`
`HE
`
`vl
`
`LNAWAVd
`
`NOILVILOSAN
`
`NOILVONddV
`
`96&
`
`
`
`~TOULNOD
`
`AYNLONYLS
`
`JINCOW
`
`VLVd
`
`viva
`
`FYNLONYLS!
`
`|
`
`INAWAVd
`
`NOILOVSNVYL
`
`NOILVONddV
`
`4
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 13, 2011
`
`Sheet 4 of 6
`
`US 8,016,192 B2
`
`LALLYAZ
`
`. ELLELE
`
`aeNA
`Y
`
`504
`
`506
`
`orfy
`
`5
`
`

`

`U.S. Patent
`
`Sep. 13, 2011
`
`Sheet 5 of 6
`
`US 8,016,192 B2
`
`602
`
`604
`
`606
`
`608
`
`Y
`
`ACCESS
`
`PRIVATE
`
`600
`
`6
`
`

`

`U.S. Patent
`
`Sep. 13, 2011
`
`Sheet 6 of 6
`
`US 8,016,192 B2
`
`MANAGE ELECTRONIC
`PAYMENT APPLICATIONS
`
`700
`
`702
`
`MAINTAIN PRIORITY DATA
`STRUCTURE AT THE MOBILE
`
`DEVICE
`
`
`
` AUTHENTICATED?
`
`END USER
`ACCESS REQUEST?
`
`ISSUER
`ACCESS REQUEST?
`
`
`AUTHENTICATED?
`
`YES
`PROVIDE END USER
`MANAGEMENT ACCESS
`
`708
`
`YES
`PROVIDE ISSUER
`MANAGEMENT ACCESS
`
`724
`
`eeeem0 ee ee726
`| PROTECT A PORTION OF THE!
`I PROTECT A PORTION OF THE |
`PRIORITY DATA STRUCTURE|
`
`
`
`
`INDICATE THE CURRENT
`RECEIVE AND PROCESS
`PRIORITY AT THE MOBILE
`ISSUER INSTRUCTIONS TO
`
`
`
`DEVICE
`MODIFY THE CURRENT
`
`
`
`
`
`PRIORITY
` RECEIVE AND PROCESS END
`PRIORITY
`
` UPDATE/ ARRANGE PRIORITY
`DATA STRUCTURE
`
`USER INSTRUCTIONS TO
`MODIFY THE CURRENT
`
`7
`
`

`

`US 8,016,192 B2
`
`1
`USER-CONFIGURABLE PRIORITY LIST FOR
`MOBILE DEVICE ELECTRONIC PAYMENT
`APPLICATIONS
`
`TECHNICAL FIELD
`
`The present invention relates generally to mobile devices.
`Moreparticularly, the present invention relates to a technique
`for controlling the priority of payment applications on a
`mobile device.
`
`BACKGROUND
`
`Consumers usually pay for goods and services with cash,
`credit cards, or debit cards. Stored value cards (suchas gift
`cards or electronic gift certificates) and smart cards are
`becomingincreasingly popularas alternative payment meth-
`ods. When a bank or financial institution issues a physical
`paymenttransaction card, a logo or writing on the card indi-
`cates the brand of the payment application (e.g., MASTER-
`CARD,VISA,etc.) and the issuing entity (e.g., CITIBANK,
`WELLS FARGO,etc.). Such cards usually represent a single
`paymentapplication or, perhaps, a dual credit/debit applica-
`tion. The end user controls the use ofhis paymentapplications
`by physically selecting a card for use at the point of sale
`(“POS”). For dual credit/debit cards, the end user may also be
`able to select whether the credit card functionality or the debit
`card functionality is to be used at the POS. The end user
`knows which card to choose based on the logo or indicia
`printed on the card itself, while the selection of credit versus
`debit for a dual function card may be communicated to the
`POSclerk or entered at a POS terminal. These selection
`mechanisms are manual and somewhatlimited because con-
`
`ventional paymentcards do not include displays or any form
`of user interface.
`
`Systems and protocols currently under development are
`seeking to port existing smart card and paymentapplication
`technologies into handheld mobile devices such as cellular
`telephones. The goal of these systems and protocols is to
`enable an end userto store one or more paymentapplications
`on a mobile device such that, at the POS, the mobile device
`can be utilized as an electronic wallet. The mobile device
`
`wirelessly communicates the payment application data to the
`POSterminal, which then processes the paymenttransaction
`using a selected or designated paymentapplication. In prac-
`tice, most people carry more than onecredit, debit, or pay-
`ment card and, consequently, a mobile device with an elec-
`tronic wallet
`should accommodate multiple electronic
`paymentapplications.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`A more complete understanding of the present invention
`maybe derived by referring to the detailed description and
`claims when considered in conjunction with the following
`figures, wherein like reference numbersrefer to similar ele-
`ments throughoutthe figures.
`FIG. 1 is a diagram depicting an example electronic pay-
`ment procedure that utilizes a mobile device as a payment
`mechanism;
`FIG.2 is a face view of an example mobile telephonethat
`supports user-configurable electronic payment application
`priority;
`FIG.3 is a schematic representation of an example mobile
`device that supports user-configurable electronic payment
`application priority;
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`FIG.4 is an example data structure that includes priority
`information for electronic payment applications associated
`with a mobile device;
`FIG. 5 is another example data structure that includespri-
`ority information for electronic paymentapplications associ-
`ated with a mobile device;
`FIG.6 is yet another example data structure that includes
`priority information for electronic payment applications
`associated with a mobile device; and
`FIG.7 is a flow chart of an example process for managing
`electronic payment applications associated with a mobile
`device.
`
`DETAILED DESCRIPTION
`
`The following detailed description is merely illustrative in
`nature andis not intendedto limit the invention or the appli-
`cation and uses of the invention. Furthermore, there is no
`intention to be bound by any expressed or implied theory
`presented in the preceding technical field, background, brief
`summary or the following detailed description.
`The invention may be described herein in terms of func-
`tional and/or logical block components and various process-
`ing steps. It should be appreciated that such block compo-
`nents may berealized by any numberof hardware, software,
`and/or firmware components configuredto perform the speci-
`fied functions. For example, an embodimentof the invention
`may employ various integrated circuit components, e.g.,
`memory elements, digital signal processing elements, logic
`elements, look-up tables, or the like, which may carry out a
`variety of functions underthe control of one or more micro-
`processorsor other control devices. In addition, those skilled
`in the art will appreciate that the present invention may be
`practiced in conjunction with any numberof data transmis-
`sion protocols and that the system described herein is merely
`one exemplary application for the invention.
`For the sake of brevity, conventional techniques and tech-
`nologies related to mobile electronic devices, credit and debit
`card transaction processing, smart cards, electronic payment
`processing, wireless data communication, and other func-
`tional aspects of the systems (and the individual operating
`components of the systems) may not be described in detail
`herein. Furthermore, the connecting lines shownin the vari-
`ous figures contained herein are intended to represent
`example functional relationships and/or physical couplings
`between the various elements. It should be noted that many
`alternative or additional functional relationships or physical
`connections maybepresent in a practical embodiment.
`The following description refers to elements or features
`being “connected” or “coupled” together. As used herein,
`unless expressly stated otherwise, “connected” means that
`one element/feature is directly or indirectly connected to
`another element/feature, and not necessarily mechanically.
`Likewise, unless expressly stated otherwise, “coupled”
`means that one element/feature is directly or indirectly
`coupled to another element/feature, and not necessarily
`mechanically. Thus, although the schematic shownin FIG.3
`depicts one example arrangement of elements, additional
`intervening elements, devices, features, or components may
`be present in an actual embodiment (assuming that the func-
`tionality of the device is not adversely affected).
`Although the following description focuses on example
`embodiments that handle electronic payment applications
`that are utilized as payment mechanisms for purchases of
`goods, services, andthe like, the technologies and techniques
`described herein are not so limited and an electronic transac-
`
`tion application may be suitably configured to support the
`
`8
`
`

`

`US 8,016,192 B2
`
`3
`communication, transfer, and processing of other types of
`data. An electronic paymentapplication may correspondto: a
`credit account; a debit accountlinked to a savings account, a
`checking account, an investment account, or the like; a gift
`“card” or other stored value account; a pre-paid “card” or
`account; or the like. An electronic payment application may
`correspond to other applications that may be used during an
`electronic transaction, such as, without limitation: a loyalty or
`“points” account; a discount “card” or account; an identifica-
`tion “card” or mechanism; orthe like.
`It is desirable to have a system that combinesthe capabili-
`ties of very short range wireless communication and a secure
`platform to enable a financial service application, such as an
`electronic wallet, to be hosted on a handheld mobile device.
`Onesuitable short range wireless communication technology
`knownas near field communication (““NFC”) utilizes a carrier
`frequency in the 13 MHz range, along with relatively low bit
`rates. Other short range wireless communication technolo-
`gies leverage magnetic induction techniques to support data
`transfer between twodevices in close proximity to each other.
`Modern mobile devices (e.g., cellular telephones, personal
`digital assistants, digital media players, digital cameras, por-
`table video game units, etc.) are typically rich in features,
`have large displays, include multifunctional user interfaces,
`and have generous data storage capacities, and a single
`mobile device can host multiple electronic transaction and
`paymentapplications.
`A mobile device configured as described herein can man-
`age a plurality of electronic payment applications and select
`one or more of the applications for use with any given trans-
`action. In some cases, the end user should have complete
`control over the paymentapplication priority (which is akin to
`a person selecting a physical credit/debit card for a transac-
`tion), while in other cases the issuer of the mobile device or
`the issuer of the electronic payment platform should have
`control over the paymentapplication priority. For example, a
`cellular telephone issued and subsidized by Acme Bank may
`have a default setting that treats the Acme Bank credit card
`application as the first priority application. As another
`example, one might want a merchant’s POSterminal to have
`the ability to select and access a paymentcard, a loyalty card,
`and a discount card from a prioritized list. In some cases, it
`mayalso be useful to have an identification card exposed to
`the POS terminal (e.g., when one purchases alcohol). The
`user might want to control which of these cards, as well as
`their relative priority, are available to the merchant(e.g., for
`privacy reasons)and, for example,the card issuer may require
`that a certain card always be presented so that the issuer can
`share in the revenue(e.g., a cellular service provider card—in
`order to provide a kickback to this service provider for every
`purchase made).
`FIG. 1 is a diagram depicting an example electronic pay-
`ment procedure that utilizes a mobile device 102 as a payment
`mechanism at a POS terminal 104. In this example procedure,
`an end user 105 of mobile device 102 initiates near field
`communication between POS terminal 104 and mobile
`
`device 102 (alternate embodiments may employ different
`data communication techniques and protocols, such as a
`physical port connection, a smart card reader, or the like). The
`right side of FIG. 1 depicts end user 105 placing or waving
`mobile device 102 near POS terminal 104, which triggers the
`electronic payment procedure. After the near field communi-
`cation channel has been established, POS terminal 104 may
`select or initialize a payment negotiation application that is
`installed on mobile device 102. In conjunction with this selec-
`tion, POS terminal 104 solicits a prioritized list of electronic
`paymentapplications supported by or otherwise associated
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`with mobile device 102. The arrow 106 in FIG.1 represents
`the communication during which POS terminal 104 selects
`the payment negotiation application and during which POS
`terminal 104 requests the prioritized list from mobile device
`102.
`
`In responseto the request from POS terminal 104, mobile
`device 102 generates and transmits a suitable response 108
`back to POS terminal 104. In this example, response 108
`includes a copyofthe prioritized list (or any equivalent data
`structure that indicates priority for the electronic payment
`applications) in a format that can be received and processed
`by POSterminal 104. Once received, the priority list is pro-
`cessed by POSterminal 104 in an appropriate manner. For
`example, POS terminal 104 may analyze the electronic pay-
`ment applications in order from the highest priority to the
`lowest priority to determine whether POSterminal 104 sup-
`ports a particular electronic paymentapplication.In practice,
`POSterminal 104 mayselect the highest priority electronic
`paymentapplication that is accepted by the given merchant.
`After POS terminal 104 selects the electronic paymentappli-
`cation to be used for the current transaction, a suitable pay-
`ment protocol 110 is followed by POS terminal 104 to com-
`plete that transaction. Payment protocol 110 may complete
`the transaction using established electronic payment tech-
`niques that need not be described in detail herein. Multiple
`applications (e.g., credit card,
`loyalty card, etc.) may be
`selected and executed, in which case, paymentprotocol 110
`mayrepresent a bundle of transactions, one for each of these
`applications.
`In this example, payment protocol 110 represents a proto-
`col between mobile device 102 and POS terminal 104. This
`
`protocol typically would involve somesort of security mecha-
`nism (e.g., a challenge from POSterminal 104 and a response
`from mobile device 102) and would likely includethetransfer
`of account information for the selected payment mechanism
`(e.g., the account numberassociated with the paymentappli-
`cation could be sent from mobile device 102 to POS terminal
`104). After mobile device 102 and POSterminal 104 engage
`in payment protocol 110, POS terminal may engage in
`another protocol with the appropriate financial institution
`(not shown) to determine whether the transaction should be
`approved. Atthis time the financial institution will check the
`status of the designated account (e.g., whether the user
`exceededhis credit limit, whether the card has been reported
`as lost, whetherthe card been flagged as fraudulent,etc.) and
`do other verifications. In this regard, POS terminal 104 may
`obtain “approved”or “disapproved” message from the finan-
`cial institution.
`The electronic payment procedure depicted in FIG. 1 pro-
`vides a mechanism by which oneofa plurality of electronic
`payment applications hosted on a mobile device can be
`selected for use by a POSterminal. In one example imple-
`mentation, the priority list is “read-only” such that the end
`user is unable to modify the relative priority of any of the
`electronic paymentapplications. In such an implementation,
`the issuer of the mobile device (or the issuer of the payment
`transaction platform) mayretain access privileges to change
`the relative priority of the applications using a secure com-
`munication channel. In the example embodiment described
`below, however, the end user can access someorall of the
`priority list for purposes of modifying the relative priority of
`the applications. Thus, a practical implementation may be
`suitably configured to contemplate three potential models: (1)
`the issuer has full control of electronic payment application
`priorities; (2) the issuer delegates full control of electronic
`paymentapplication priorities to the end user; or (3) the issuer
`delegates partial control of electronic payment application
`
`9
`
`

`

`US 8,016,192 B2
`
`6
`5
`priority level. Another key or button, labeled “Make Private”
`priorities to the end user. As used herein,an “issuer” generally
`refers to a person, a software application, a company, or any
`or “Make Public” (depending on the current state), would
`entity that has the necessary security credentials and authen-
`removeor add the selected applicationto the priority list sent
`tication information (passwords, keys, identification num-
`to the POSterminal. Private applications could be rendered in
`bers, etc.) required to obtain access to the priority list in the
`gray text or be marked with a special icon (similar to how the
`mannerdescribed herein.
`“key icon” indicates locked applications in FIG.2).
`FIG.2 is a face view of an example mobile telephone 200
`FIG.3 is a schematic representation of an example mobile
`that supports user-configurable electronic payment applica-
`device 300 that supports user-configurable electronic pay-
`tion priority as described herein. Mobile telephone 200 is one
`ment application priority as described herein. Mobile device
`example implementation ofmobile device 102 shownin FIG.
`300 maybe realized as mobile device 102, mobile telephone
`1. Mobile telephone 200 may incorporate a numberof con-
`200, as a personal digital assistant, as a digital media player,
`ventional features and functionality that will not be described
`as a pocket personal computer,or the like. Mobile device 300
`in detail herein, including, without limitation: telecommuni-
`generally includes: a user interface 302; a display 304; a
`cation; still camera; video camera; digital media player; video
`communication module 306; a near field communication
`gameplayer; personal digital assistant; or the like. Mobile
`(“NFC”) radio 308; a cellular radio 310; a wired interface 312
`telephone 200 generally includes a housing 202 and a user
`(which may be optional in a practical implementation); a
`interface 203. User interface 203 may include, without limi-
`paymenttransaction application 313; a payment negotiation
`tation: a keypad 204; a navigation button 206; a display 208;
`application 314; a suitable amount ofmemory 316; a process-
`amicrophone 210; andaspeaker 212. User interface 203 may
`20
`ing architecture 318; and a security module 320. Someorall
`also include or be configured to function as, without limita-
`of these elements may be coupled together with a bus 322 or
`tion: a touch pad; a touch screen (on display 208); a stylus pad
`(on display 208); a cursor pointing device; or the like. User
`any suitable interconnection arrangement or architecture.
`interface 203 enables the user of mobile telephone 200 to
`Mobile device 300 mayalso include a suitably formatted data
`manipulate applications and features supported by mobile
`structure 324 that indicates priority for a plurality of elec-
`telephone 200 such as, for example, a payment negotiation
`tronic transaction applications associated with mobile device
`application as described in more detail below.In this regard,
`300, and a data structure control module 326 that is config-
`user interface 203 maybe suitably configured to produce end
`ured to manageaccessto the data structure 324. In accordance
`user instructions to modify a current priority of electronic
`with one example embodiment, paymenttransaction applica-
`paymentapplications associated with mobile telephone 200.
`tion 313, payment negotiation application 314, data structure
`FIG. 2 depicts an example screen shot on display 208,
`324, and data structure control module 326 mayreside within
`where the screen shot conveys the priority of the electronic
`the security module 320, while the user interface software for
`paymentapplications in a list format. The actual manner and
`payment transaction application 313, payment negotiation
`format in which this information is displayed may vary from
`application 314, data structure 324, and datastructure control
`one mobile deviceto another, and the particular screen shot in
`module 326 may reside in the main processor for mobile
`FIG.2 is not intendedto limit or otherwise restrict the scope
`device, e.g., processing architecture 318. An example
`or application ofthe example embodiments in any way.In this
`embodiment of mobile device 300 may include additional
`example, mobile telephone 200 supports five different elec-
`elements, components, features, and/or functionality associ-
`tronic paymentapplications, and the screen shotlists them in
`ated with conventional operating aspects, and such conven-
`orderofpriority (one being the highestpriority and five being
`tional aspects will not be described in detail herein.
`the lowest priority). Mobile telephone 200 may display an
`User interface 302 may be generally configured as
`appropriate icon, such as a key as shown in FIG. 2, that
`described above for user interface 203 (see FIG. 2). In this
`indicates that the priority of the corresponding electronic
`example, user interface 302 is coupled to data structure con-
`paymentapplication is locked and cannot be changed by the
`trol module 326 to facilitate updating of data structure 324
`end user(the icon mayalsoindicatethat other attributes ofthe
`using the technologies and techniques described herein. Dis-
`corresponding application are write protected, e.g., the ability
`play 304 maybe generally configured as described above for
`to modify existing access rights, application names, ability to
`display 208 (see FIG.2). In particular, mobile device 300 may
`
`delete applications, etc.). In this example, the first two elec- manipulate display 304 to renderalist or other indication of
`tronic paymentapplications are locked. As described in more
`the priority of electronic payment applications supported by
`mobile device 300.
`detail below, the priority of the remaining three electronic
`paymentapplications may be modified by the end user. The
`end user can manipulate user interface 202 to change the
`priority of the unlocked electronic paymentapplications(al-
`ternatively, the end user can implement such changesvia the
`internet, via a wired connection to a computing device, or the
`like). In one embodiment, the end user can select a desired
`electronic paymentapplicationin the list and manipulate user
`interface 203 in an appropriate mannerto changethepriority
`of the selected entry. In this regard, FIG. 2 depicts the fifth
`entry in a highlighted manner to indicate that it has been
`selected by the end user.
`As an example, each unlocked application could be
`manipulated using three soft keys or other user interface
`features. One key or button, labeled “Move Up”oridentified
`with an upward arrow, could be used to movethe selected
`application up one priority level. Another key or button,
`labeled “Move Down”oridentified with a downwardarrow,
`could be used to move the selected application down one
`
`In an example embodiment, processing architecture 318
`may be realized with any number of hardware, software,
`and/or firmware components, and processing architecture
`318 may include any numberof logical or functional mod-
`ules. Processing architecture 318 may be implemented or
`performed with a general purpose processor, a content
`addressable memory, a digital signal processor, an applica-
`tion specific integrated circuit, a field programmable gate
`array, any suitable programmable logic device, discrete gate
`or transistor logic, discrete hardware components, or any
`combination designed to perform the functions described
`here. A processor may be realized as a microprocessor, a
`controller, a microcontroller, or a state machine. Moreover, a
`processor may be implemented as a combination of comput-
`ing devices, e.g., a combination of a digital signal processor
`and a microprocessor, a plurality of microprocessors, one or
`more microprocessors in conjunction with a digital signal
`processorcore, or any other such configuration.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`10
`
`10
`
`

`

`US 8,016,192 B2
`
`7
`In practice, processing architecture 318 may be suitably
`configured to perform and/or support the various operations,
`features,
`techniques, functions, and operations described
`herein. In this example, processing architecture 318 includes
`or cooperates with data structure control module 326, which
`manages access to (and modification of) data structure 324.
`Moreover, although FIG. 3 depicts certain elements as dis-
`tinct blocks or modules, processing architecture 318 may
`include or incorporate additional functional components (or
`portions thereof) of mobile device 300, such as communica-
`tion module 306, wired interface 312, or security module 320.
`Memory 316 may be realized as RAM memory, flash
`memory, EPROM memory, EEPROM memory, registers, a
`hard disk, a removable disk, a CD-ROM,or any other form of
`storage medium knownintheart. In this regard, memory 316
`can be coupled to processing architecture 318 such that pro-
`cessing architecture 318 can read information from, and write
`information to, memory 316. In the alternative, memory 316
`may be integral
`to processing architecture 318. As an
`example, processing architecture 318 and memory 316 may
`reside in an ASIC. In this example, memory 316 may be
`utilized to store data structure 324 (depicted in dashedlines
`to indicate that storage in memory 316 may bean optional
`feature), authentication keys utilized by security module 320,
`data associated with the various electronic transaction appli-
`cations supported by mobile device 300, and other informa-
`tion that may relate to conventional operating features of
`mobile device 300.
`
`Communication module 306 may represent processing
`logic that is suitably configured to support the data commu-
`nication protocols, schemes, and techniques utilized by
`mobile device 300. In practice, communication module 306
`or a portion thereof may be consideredto be part of process-
`ing architecture 318. For simplicity, FIG. 3 depicts one com-
`munication module 306. An example embodiment, however,
`may include any number of communication modules. Com-
`munication module 306 may be configured to: process data
`received or transmitted by cellular radio 310; process data
`received or transmitted by NFC radio 308; process data
`received or transmitted by wired interface 312; and/or process
`data received or transmitted by other technologies and tech-
`niques supported by mobile device 300.
`For wireless communication of data, communication mod-
`ule 306 may support any number of suitable wireless data
`communication protocols,
`techniques, or methodologies,
`including, without limitation: RF; IrDA (infrared); Blue-
`tooth; ZigBee (and other variants of the IEEE 802.15 proto-
`col); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or
`any other variation); Direct Sequence Spread Spectrum; Fre-
`quency Hopping Spread Spectrum;cellular/wireless/cordless
`telecommunication protocols; wireless home network com-
`munication protocols; paging network protocols; magnetic
`induction; satellite data communication protocols; wireless
`hospital or health care facility network protocols such as
`those operating in the WMTSbands; GPRS; andproprietary
`wireless data communication protocols such as variants of
`Wireless USB.
`For communication of data over a cable, a wired connec-
`tion, or other physical link, communication module 306 may
`support any numberof suitable data communication proto-
`cols, techniques, or methodologies, including, without limi-
`tation: Ethernet; home network communication protocols;
`USB; IEEE 1394 (Firewire); hospital network communica-
`tion protocols; and proprietary data communication proto-
`cols.
`NFCradio 308 may cooperate with communication mod-
`ule 306 to support wireless near field communication. NFC
`
`8
`radio 308 may include hardware, software, and/or firmware
`configured to support NFC communication with a POSter-
`minal. NFC radio 308 may include any number of RF front
`end components, any numberoftransmitters, any number of
`receivers, and/or any numberoftransceivers, depending upon
`the particular implementation. NFC radio 308 may be
`coupled to a suitably configured antenna 328 which may(but
`need not) be internal to the housing of mobile device 300.
`NFC radio 308 utilizes RF carrier frequencies in the 13.54
`MHzrange and communicates data at a relatively low bit rate
`in the range of 106, 212, and 424 kilobits per second. Notably,
`NFCradio 308 need not rely on a cellular communication
`cellular network, an 802.11 network, or other non-NFC net-
`works to communicate with the POS terminal. NFC can be
`
`used to emulate a proximity card and thus support proximity
`paymentapplications, access control, e.g., a badge for door
`access, and others. In addition, NFC can also operate in reader
`or writer mode, giving an NFC-enabled device the ability to
`read or write to tags as well as proximity cards. An example
`embodimentofmobile device 300 mayutilize NFC radio 308
`to communicate data structure 324 to a POS terminal.
`
`Cellular radio 310 may cooperate with communication
`module 306 to support cellular communication using known
`techniques andtechnologies. Cellular radio 310 may include
`hardware, software, and/or firmware configured to support
`communication with a cellular network. Cellular radio 310
`
`may include any number of RF front end components, any
`numberof transmitters, any numberofreceivers, and/or any
`numberoftransceivers, depending uponthe particular imple-
`mentation. Cellular radio 310 may be coupled to a suitably
`configured antenna 330 which may (but need not) be internal
`to the housing of mobile device 300. In example embodi-
`ments, cellular radio 310 may be utilized to enable an issuer
`or an administrator to remotely access and manage payment
`negotiation application 314 and/or data structure 324.
`Wired interface 312 may cooperate with communication
`module 306 to support data communication with other
`devices using a tangible li