CN101657984A - Contactless transaction - Google Patents

Abstract

A method associated with a contactless phone. The method includes sending a balance inquiry response message to a mobile phone. The mobile phone incl udes a contactless element that is configured to communicate with a contactl ess reader in a point of sale terminal. The account balance inquiry response message provides an account balance for an account associated with the mobi le phone. The mobilephone is operated by a consumer. The method also includ es sending a transaction alert message to the mobile phone, where the transa ction alert message informs the consumer that a transaction has occurred usi ng the account. The method also includes sending an offer message to the mob ile phone, where the offer message provides a benefit to the consumer if the consumer uses the mobile phone to conduct a predetermined transaction.

Description

contactless transaction

Cross References to Related Applications

This patent application is a non-provisional application of, and claims priority from, U.S. Provisional Patent Application No. 60/884,212, filed January 9, 2007, and U.S. Provisional Patent Application No. 60/884,290, filed January 10, 2007 , the above-mentioned application is hereby generally incorporated by reference in its entirety.

This application is also related to U.S. Patent Application No.__________ (Attorney Docket No. 16222U-038330US), entitled "Mobile Phone Payment With Disabling Feature," filed on the same date as this application, and also Relates to U.S. Patent Application No._________ (Attorney Docket No. 16222U-038340US), entitled "Mobile Phone Payment Process including Threshold Indicator," filed on the same date as this application, and also relates to U.S. Patent Application No._____________ (Attorney Docket No. 16222U-038320US) entitled "Mobile Payment Management" filed on the same date as this application. These applications are hereby incorporated by reference in their entirety.

background

People of all ages around the world use mobile phones as an essential part of their daily lives. In some parts of the world, they are primary communication devices, but mobile phones are much more than communication devices. They are truly multifunctional, offering consumers the ability not only to make and receive calls, but also to take pictures, send text messages, listen to music, surf the Web, and even watch movies.

Consumer demand for universal multifunctional mobile phones is increasing. Technologies are emerging to support the mobile payment infrastructure (i.e. contactless payment acceptance infrastructure, NFC-enabled mobile phones, and robust mobile networks). Mobile phones have the potential to enhance the security and convenience of using payment products and introduce payment products to parts of the world that currently do not have the supporting infrastructure for traditional payment products.

Consumers are interested in mobile payments and want better ways to conduct transactions using their mobile phones and better ways to manage the payment process.

Also, in some cases, a consumer may hold two or more payment cards (eg, credit cards) and may want to use his or her phone to use the account numbers associated with those payment cards. Different issuers of those credit cards may provide different payment services for those cards. It is desirable to allow users to use the different payment services offered by these issuers on a single phone.

Embodiments of the invention address these and other problems individually or collectively.

brief overview

Embodiments of the present invention relate to an improved consumer mobile phone payment system and method.

One embodiment of the invention relates to a method. The method includes receiving an account balance inquiry response message using a mobile phone, wherein the mobile phone includes a contactless element configured to communicate with a contactless reader of a point-of-sale terminal, and wherein the account balance inquiry response message is provided with the mobile phone the account balance of an account associated with the phone, the mobile phone being operated by the consumer; receiving transaction alert messages using the mobile phone, wherein the transaction alert notifies the consumer that a transaction has occurred using the account; and receiving promotional messages, wherein if the consumer uses If the mobile phone is used to make a predetermined transaction, the preferential message provides benefits for the consumer.

Another embodiment of the invention is directed to a method comprising the steps of: sending a balance inquiry response message to a mobile phone, wherein the mobile phone includes a contactless element configured to communicate with a contactless reader of a point-of-sale terminal, and wherein the account balance inquiry response message provides an account balance for an account associated with a mobile phone operated by the consumer; and a transaction alert message is sent to the mobile phone, wherein the transaction alert message notifies the consumer that a transaction has occurred using the account ; and sending an offer message to the mobile phone, wherein the offer message provides a benefit to the consumer if the consumer uses the mobile phone to make the predetermined transaction.

Other embodiments of the invention may involve computer-readable media, phones, and systems associated with the methods described above and other methods.

These and other embodiments of the invention are described in more detail below.

Brief description of the drawings

Fig. 1 shows a block diagram of a system according to an embodiment of the present invention.

Figure 2 shows a screenshot showing the configuration process on the phone display.

Figure 3 shows a screen shot on the phone showing the payment process.

Figures 4-6 show multiple screen shots with transaction messages on the phone display.

7-8 show multiple screen shots on the phone display for balance inquiries.

Figures 9(a)-9(b) show multiple screenshots on the phone display for payment reminders.

Figures 10, 11(a) and 11(b) show screenshots associated with balance alerts.

Figure 12 shows a screenshot indicating that an account has been blocked due to suspicious activity.

Figure 13 shows a screenshot illustrating discounting.

Figures 14(a) and 14(b) show screenshots illustrating the different issuer-specific mobile payment applications a consumer can choose from, and a subsequent screenshot illustrating that a particular mobile payment application has become the default application.

15 shows a screenshot associated with selecting an issuer-specific mobile payment application as the default application.

Fig. 16 shows a block diagram of a computer device.

Figure 17 shows a block diagram of a mobile phone with contactless elements.

A detailed description

I. Mobile Trading System

Embodiments of the present invention combine payment functionality with a range of value-added applications and functions such as coupons, personalization, and account management. Embodiments of the present invention make it easy for publishers and mobile operators to provide convenient new services to consumers through mobile phones.

Some features of embodiments of the invention include the following:

Phone Payment Services (Pre-Paid or Post-Paid): Embodiments of the present invention allow consumers to pay for phone services using a payment application on the customer's phone.

Contactless Payments at Point of Sale: Using embodiments of the present invention, consumers can easily and quickly use their phones to pay at merchants instead of cards.

Remote Payment: Using embodiments of the present invention, a consumer can use his or her mobile phone to pay for goods and services for any card not present transaction. To use remote payments, a consumer registers his or her payment account with a mobile carrier, and the mobile carrier associates the consumer's payment account with a mobile phone number. Whenever a consumer conducts a card-away transaction (such as a mail order, telephone order or Internet order), the consumer can provide his or her registered mobile phone number (instead of his or her payment account details) to proceed It's time to buy. Mobile transfers can also be performed remotely, but these transactions are unique in that they involve the movement of funds rather than purchases.

The service provider can provide the system's payment and value-added functionality to the consumer's mobile phone via SMS messages (or other messaging protocols) over the mobile network. Examples of payment functions include proximity payment, remote payment, and mobile money transfer. Examples of value-added features include offers, authentication, and top-up minutes on mobile phones.

Figure 1 shows a system according to an embodiment of the invention. Referring to FIG. 1 , participants in embodiments of the present invention may include traditional payment service participants such as issuer 14 , merchant 16 , and consumer 10 . Other parties may also include mobile operators 26 and mobile service providers such as messaging service provider 20 , directory service provider 22 , and OTA (over-the-air) service provider 24 .

A system may also include a number of specific components. Examples of these components include offers engine 18, messaging gateway 20(a), directory service engine 22(a), and service activation system 24(a).

The system may also include a mobile phone 10(a), which may include: a mobile phone component such as an NFC communication element 10(a)-1 (near field communication element, which is an example of a contactless element); including a payment application 10 The secure element of (a)-2; and the resident application 10(a)- comprising one or more mobile applications 10(a)-3' and one or more download managers 10(a)-3" 3.

Messages can be passed between the components shown in Figure 1. Reference numeral 2 shows arrows for offer management messages, reference numeral 4 shows arrows for service activation messages, reference numeral 6 shows arrows for catalog service messages, and reference numeral 8 shows arrows for Arrows for account management messages.

The various components below are described in further detail below.

II. Types of payment services and value-added services

Embodiments of the invention may facilitate at least three types of payment protocols. The first type may include proximity payments (ie, contactless payments) for face-to-face payments at merchant locations. The second type may include remote payments for payments made in e-commerce environments or other card absences. A third type may include mobile money transfers for transferring funds from one person to another for personal rather than business use (ie, person-to-person payments).

Proximity Pay provides the same functionality as conventional contactless card transaction processing, but instead of using a contactless card, the consumer presents a mobile phone containing a payment application to a point-of-sale (POS) device at the merchant's location. NFC-enabled phones mimic contactless cards and use the same communication standard. The POS device is the same as that used for contactless cards, and the payment application interacts with the POS device in the same way as a contactless card. Payment is initiated via a mobile phone rather than a card, but is otherwise the same as contactless transaction processing.

A payment application used in a phone 10(a) according to an embodiment of the invention may support at least two different proximity payment configurations. The first configuration is "always on". When the payment configuration is in always-on mode, the default payment application 10(a)-2 is always active so that the customer can initiate a transaction by waving the phone 10(a) in front of the POS device without selecting a payment function. The second configuration is "Manual". When the payment configuration is in manual mode, the consumer 10 can access the payment application 10(a)-2 and select the payment function to make a proximity payment. During this process, the consumer 10 may also select an account to use for payment. Issuer 14 can specify which of these configurations, or the issuer-specific payment service associated with the account, is the default, and can also specify whether the consumer has the option to select the default payment configuration. Proximity Pay is compatible with Visa Contactless Payment Specification (VCPS) 2.0.2. Embodiments of the present invention also allow more than one payment application to reside in the secure element, and allow one of these payment applications to be selected as default.

Remote payments make it possible for consumers to use their mobile phones to initiate and authenticate card-not-present transactions between consumers and merchants. Remote payments are made over a mobile network and do not involve interacting with a POS device. Remote payment transactions are based on mobile phone numbers rather than account numbers, so no financial information is sent over the mobile network. Card not present transactions include Internet, call center and automated services such as Interactive Voice Response (IVR) transactions, as well as face-to-face interactions. Remote payment may use the customer's registered mobile phone 10(a) as an authentication channel. To use the remote payment functionality, consumers can register their mobile phone number with the directory service provider 22 or other entity, and can associate that mobile phone number with an account so they can use that registered phone number for payments.

A mobile money transfer refers to a transaction between two individuals. Mobile transfers allow a cardholder or customer to transfer funds from his or her card or account to another card or account using a mobile phone 10(a). This enables consumers to easily send money to individuals via mobile phones over mobile networks for international remittances and domestic person-to-person transfers. Consumers can use mobile transfers to pay a friend or another individual (not a merchant) for a service.

Mobile transfers can rely on aliases rather than account information to transfer funds, so no financial information is sent over the mobile network. Consumers who want to send money can register their account and link it to their mobile phone number. They can also designate payees and assign them aliases. Recipients can register with the service, but they don't need to be registered to receive funds wired to them.

Embodiments of the present invention may also provide a number of value-added features, including discounts, authentication for security purposes, account management, and top-up of mobile phone minutes.

An offer may refer to a coupon, discount or promotion sent to a mobile application on a consumer's mobile phone by an issuer, merchant, or payment processing organization such as Visa. Consumers can redeem the offer using the mobile application.

An offer feature may include at least three elements. These three elements include the offer engine 18 that the merchant 16 or issuer 14 uses to define the offer, the offer message format that ensures delivery to the mobile application (the offer message format can be Visa Mobile Data Format (VMDF)), and the offer to which the offer is sent. The mobile application 10(a), . The consumer uses the mobile application 10(a) to manage the offer and redeem the offer at the merchant's POS device.

Consumers register (opt-in) with their issuers to receive offers. To send an offer, a merchant or issuer may define the offer and submit it to a payment processing organization such as Visa for review and approval. After the offer is approved, it enters the offer engine 18 and is scheduled for delivery to the consumers 10 who choose to receive it. The offer engine 18 formats the offer into a suitable message format and delivers it via SMS or some other mobile channel to the mobile application 10(a)-3 on the customer's mobile phone 10(a).

The customer's offers can be delivered to the mobile application 10(a)-3 separately from other messages and present them in a defined and labeled format. Mobile application 10(a)-3 integrates offer delivery and management with point-of-sale payment. It enables consumers to view, manage and redeem offers they have received. Application 10(a)-3 supports some automatic offer management, such as expired deletion. Offers can include barcodes or promotional codes that are scanned or entered by the merchant at the time of purchase. When redeeming an offer at a merchant establishment, the consumer may use the mobile phone's proximity payment functionality.

Authentication provides a mechanism for the issuer to request information from the mobile phone, which makes it possible for the issuer to confirm that the phone and customer are indeed who they claim to be. It enables parties in an e-commerce transaction to send confidential and correct payment data and provides authentication that the purchaser is an authorized user of a particular account. Both the mobile remote payment and mobile money transfer functions use payment authentication capabilities.

The top-up function enables mobile phones to automatically purchase minutes on prepaid phones. This service is the concrete realization of the remote payment function. It uses the same mechanism as remote payment services, as consumers buy minutes from mobile operators.

III. Account Management

Account management services include mobile management of payment account profiles and transactions, ranging from regular mobile banking to new mobile account management tools. The account management service can be linked to the issuer-specific payment service, and can be provided as an extension to the issuer's existing account management service. Mobile payment account management functionality can be integrated with existing issuer banking systems as well as any future account management service provider, whether it is a bank or another third party.

Each issuer 14 can decide what account management functions are available to consumers. The consumer 10 may use the mobile application 10(a)-3' to request current account balances, receive payment validation notifications and transaction credentials, and configure and receive balance alerts, transaction alerts, and payment reminders. When account management services are available to the consumer 10, the consumer 10 can configure these functions to deliver account information based on the consumer's criteria. For example, a consumer may request to receive an alert when his or her account balance reaches a specified threshold.

Mobile payment systems use messaging services to support account management services. The messaging system formats the message and sends it over the mobile operator network 26 . The consumer 10 sends a message requesting account management services, and the issuer 14 or merchant 16 sends the message in response.

The following table lists the transmissions from the mobile application 10(a)-3' on the consumer's mobile phone 10(a) to the issuer 14 or merchant 16 and from the issuer 14 or merchant 16 to the mobile phone 10(a) Account management messages for mobile application 10(a)-3' on ).

information Sent from send to Balance Alert Configuration Request Balance Inquiry Request Payment Alert Configuration Request Transaction Alert Configuration Request Consumers via mobile app issuer Balance Alert Configuration Response Balance Alert Balance Inquiry Response Payment Effective Payment Reminder Configuration Response Payment Reminder Transaction Alert Configuration Response Transaction Alert issuer Consumers via mobile app Transaction failure certificate Transaction success certificate Merchant Consumers via mobile app

Issuer 14 is generally responsible for acquiring, registering, and supporting consumer payment accounts. In the mobile transaction system, issuer 14 has the option to support account management and offer management functions in addition to processing payment accounts. These account management and benefit management functions may be functions of an "issuer-specific payment service". Furthermore, because payment account activation can occur after the consumer 10 has acquired the mobile phone 10(a), the issuer's traditional card issuance process can be transferred to an OTA service activation environment.

The merchant 16 accepts payments using payment accounts in both brick-and-mortar and e-commerce settings. The merchant 16 can also use the mobile payment system to issue offers to the mobile customer database ranging from a targeted subset of account owners to the entire collection.

The messaging service provider 20 provides a messaging interface between the consumer's mobile phone 10(a) and other providers. The provider operates the messaging gateway 20(a) and related systems.

The OTA service provider 24 manages the secure element 10(a)-2 on the mobile device 10(a), including providing a secure element application.

Directory service provider 22 provides support for routing remote payment and mobile money transfer transactions using aliases associated with registered consumers 10 to relevant account information.

Consumer 10 uses mobile phone 10(a) to access mobile payments and value-added services. The consumer 10 requests that any application be downloaded and personalized on the mobile phone 10(a).

The mobile operator 26 provides and supplies the mobile network, including the data services required to support the services described above. The mobile operator 26 also typically selects the mobile phones that its network supports and the applications that run on those mobile phones. It also sends messages to and receives messages from the mobile phone 10(a).

Messaging services allow interaction between different platform participants. Messaging supports account management, basic offers, and service activation for remote payments and mobile money transfers, and directory services.

Certain embodiments of the invention relate to managing a consumer's payment account using a combination of messages. One embodiment of the invention includes using a mobile phone to receive an account balance inquiry response message. The mobile phone includes a contactless element configured to communicate with a contactless reader of a point-of-sale terminal. The Account Balance Inquiry Response message provides the account balance of the account associated with the mobile phone operated by the customer. The method also includes receiving a transaction alert message using the mobile phone, wherein the transaction alert notifies the consumer that a transaction using the account has occurred; and receiving an offer message, wherein the offer message may be Consumers benefit. Such messages may be received by the mobile phone 10(a), and may be displayed by the mobile phone 10(a).

The mobile operator 26 or any other suitable entity may communicate the balance inquiry response message, transaction alert message, and offer message to the mobile phone accordingly. Mobile operator 26 is operable a communication server including a processor and a computer-readable medium operatively coupled to the processor. The computer readable medium may include code for delivering various messages to the mobile phone 10(a).

Messaging service provider 20 formats messages sent by publisher 14, merchant 16, and other service providers and delivers them to mobile application 10(a)-3' on mobile phone 10 over the mobile network. It also formats and delivers account management messages that consumers 10 send to issuers 14 and merchants 16 through mobile applications on mobile phones 10 .

The underlying protocol to which messages are sent to and from the mobile application 10(a)-3' may be the Visa Mobile Data Format (VMDF). All messages may be in VMDF format upon arrival at the messaging gateway 20(a) to ensure they are delivered to the mobile application 10(a)-3'. VMDF is not SMS specific. It includes the use of any text or binary data that is provided for use in applications on the network and for local storage purposes.

The messaging service provider 20 operates a messaging gateway 20(a) that provides a unified messaging interface between other providers and participants and consumers' mobile phones 10(a). Messaging gateway 20(a) supports at least three functional components. The first feature is the Alert API, which facilitates the transfer of messages to and from the mobile application 10(a)-3' on the consumer's mobile phone 10(a). The second feature is a reporting web interface that allows issuers 14, merchants 16, and payment processing organizations such as Visa to monitor related traffic to and from consumers' mobile phone applications. A third feature is a test center as an interface that allows participants to send messages to and receive messages from virtual mobile applications to test the readiness of their systems. The Test Center supports account management and offer messaging.

Offer Engine 18 is the system responsible for managing offers. Its capabilities range from a simple user interface (UI) through which merchants 16 define offers, to a sophisticated database transaction system that targets offers to consumers based on a wide range of demographic and behavioral data. In addition, the messaging gateway 20(a) supports an offers web interface that acts as an offers engine. It is a basic web-based UI through which merchants 16 can define simple offers to deliver to all consumers 10 .

The process of enabling a mobile phone is called "service activation" because it constitutes activation on the mobile phone. The payment application 10(a)-2', the mobile application 10(a)-3', the service activation application, account information, and data (such as data related to the issuer-specific payment application) can be linked using service activation. provided on the mobile phone. Without service activation, these apps can only be issued if the secure element—in many cases the mobile phone itself—is personalized before the consumer acquires it. While service activation is a general term for such activation that could theoretically be done through a number of channels or methods, embodiments of the present invention are preferably directed to providing a payment application over-the-air (OTA) over a mobile network to a mobile phone 10 on the security element 10(a)-2. OTA service activation allows the issuer 14 to securely and remotely enable the secure payment and account data of the phone 10(a) without requiring the consumer to access their banking or retail channels.

The OTA service provider 24 operates and manages the OTA service activation system 24(a). The OTA service activation system 24(a) provides personalization and distribution functions as well as day-to-day management of the consumer's secure element application. The function of the OTA service activation system 24(a) is to provide and personalize the secure element application using the mobile operator network. In addition, the OTA service provider 24 uses this system 24(a) to manage secure elements deployed in the field after personalization. This is the functionality required to manage payment accounts. Compromised accounts can be locked and unlocked, and the platform can be removed wirelessly. The OTA service activation system 24(a) wirelessly provides information to the mobile phone for loading, installing and personalizing software on the phone, locking and unlocking applications on the phone, and removing applications from the phone. It communicates with the download manager 10(a)-3" on the phone to perform OTA activity actions.

OTA service activation also provides remote control of mobile phones for corporate branding, configuration of offers and messaging, and planning of new services without user intervention. It uses OTA technology to communicate with the SIM or NFC chip without physical access to the phone 10(a). New services can be downloaded securely without requiring the operator to re-issue the mobile phone 10(a).

Directory services are used to support mobile money transfers and remote payments as well as value-added services such as pre-offering (in a future version of the platform), authentication, and top-up. A directory service is required for transactions that use aliases associated with registered consumers to route to other information. It determines who the consumer is and routes the relevant consumer information to the issuer.

For mobile transfers, an alias can be used to identify and/or contact the recipient of the transfer. Usually, the directory allows the sender to use an alias that is more convenient and friendly (similar to a mobile number) than an account number. In money transfer transactions, aliases/directories also allow for better privacy between sender and receiver. The parties' banks can securely retain personal information belonging to each of the sender and receiver without the sender and receiver or the cardholder and merchant 16 sharing any personal information with each other to conduct the transaction.

The mobile phone 10(a) is the gateway between the service provider and the customer 10. The mobile telephone 10(a) includes a variety of different functional components. The first feature is an NFC (Near Field Communication) radio frequency capability that provides a card emulation mode to allow proximity payments. It includes the antenna used to communicate with the merchant's contactless POS device. The second functional component is the secure element form factor used to securely hold the payment application. A third type of feature is an existing mobile application space with a mobile application 10(a)-3' and a download manager 10(a)-3".

The mobile phone 10(a) can: initiate payment transactions, receive data related to issuer-specific payment services, present issuer-specific payment services to consumers for selection, receive offers from issuer and merchants and display them; receiving account management information from issuer 14 and displaying it in the mobile application; and communicating with OTA service activation system 24(a) for OTA campaigns.

To allow mobile payments, the secure element 10(a)-2 provides the following capabilities. It provides secure storage to protect sensitive data related to mobile payments. This includes private keys associated with the phone and consumer, public keys, and certificates associated with the issuer and backend systems. It can also provide the ability to securely store consumer-specific personal information associated with mobile payments, such as a credit/debit card PAN (Personal Account Number). It also provides encryption to support secure payment protocols, data integrity, and confidentiality. This includes support for encryption/decryption, signature verification, and authentication of secure SMS messages from issuers, service activation systems, and other backend systems. It can also provide a secure deployment and execution environment for the mobile payment application 10(a)-3".

It should be understood that while the specific examples described herein include the secure element and payment application within the secure element, as well as the use of a mobile application outside the secure element, embodiments of the invention are not limited thereto. For example, the functionality of the payment application and the mobile application may be combined into one application in any suitable logical portion of the hardware in the phone.

The secure element 10(a)-2 may be in one of the following forms: Embedded hardware: This is a tamper-resistant hardware smart card with contactless capabilities that is tightly integrated with the mobile phone. Removable Universal Subscriber Identity Module (USIM): The secure element can be integrated with a USIM card that provides smart card functionality. In this case, the contactless functionality is separated. Removable Secure Digital (SD) Card: A smart card that provides a secure programmable environment. Application and mobile payment specific security information is provided on the smart card. Communication with the secure element on the smart card uses APDU commands.

The Secure Element also offers integrated NFC capability supporting the ISO 14443 standard. NFC capabilities provide support for peer-to-peer, reader/writer, and card emulation modes.

The payment application 10(a)-2' is securely stored on the mobile phone's secure element 10(a)-2 and is used to conduct payment transactions. It may include one of two Java Card applications - the Visa Smart Debit/Credit (VSDC) Card Specification Java Application integrated with the Proximity Payment System Environment (PPSE). The VSDC application is a payment application and the PPSE application is a directory application that stores details of the payment application. This is the same app that is used for the available Visa payWave contactless payment cards. VPA currently uses the contactless specification VCPS2.0.2. The current version of the GlobalPlatform Java application is version 2.7.

Payment application 10(a)-2 contains payment functionality and issuer/cardholder personalization data. The data sent by the issuer wirelessly via the service activation system 24(a) is provided to the payment application 10(a)-2 and personalizes the payment application 10(a)-2 on the secure element 10(a)-2. The service activation system 24(a) directs OTA provisioning, initialization, and personalization commands (based on issuer specifications) from the service activation system to the payment application 10(a)-2. The personalized instance of payment application 10(a)-2' may be locked, unlocked, and removed from secure element 10(a) using OTA commands initiated by issuer 14 through service activation system 24(a).

To enable mobile proximity payment, a specific payment application 10(a)-2' (indicated by a unique application identifier (AID)) is associated with a specific mobile application 10(a)-3', and the specific mobile The application 10(a)-3' correlates the consumer experience with the mobile proximity mechanism. Additionally, the secure element 10(a)-2 may have a specific payment application 10(a)-2' configured as a default program for proximity payments.

The payment application 10(a)-2' interfaces with the contactless proximity modem in manual or automatic mode. When the mobile phone 10(a) comes into proximity of a contactless POS device, the payment application 10(a)-2' is automatically notified if it is configured in automatic payment mode. In manual mode, communication with the POS is initiated by the consumer 10 through the mobile application 10(a)-3'.

Mobile application 10(a)-3 includes a user interface. It includes user interfaces for payments, account management, offer management and reimbursement, and setting preferences. The mobile application 10(a)-3 is a J2ME/MIDP 2.0 application (MIDlet). The Mobile Information Device Profile (MIDP) is a specification published for the use of Java on embedded devices such as mobile phones. Each mobile application 10(a)-3 can be customized and configured for a particular issuer, and is associated with a particular payment application instance.

The customization and configuration process can include receipt of data associated with an issuer-specific payment application instance that can be linked to an issuer-specific payment service. In an embodiment of the invention, there may be many different issuer-specific payment application instances linked to different issuer-specific payment services. Different issuer-specific payment services may have different sets of functions. For example, a publisher may provide promotional messages, but not deal alert messages. Another issuer may provide transaction alert messages, but not promotional messages. In an embodiment of the invention, the consumer 10 can select an issuer-specific payment service as the default service used by his phone 10(a), and can then use the phone 10(a) with the selected issuer-specific payment service. services to conduct transactions such as payment transactions. Issuer-specific payment services may include dedicated management services and payment functions.

Mobile applications 10(a)-3' can be provisioned, activated and configured wirelessly on mobile phone 10(a) according to issuer specifications during service activation and initialization. Once configured, the application instance appears as an entry in the phone's main menu folder for mobile payments and other financial applications. There may be more than one instance of the application on the menu based on the number of instances of the mobile application that have been activated, provisioned, and configured on the phone 10(a).

The user interface may include a flash page welcoming the consumer to the application, a main menu page for all features supported by the issuer, payment related pages, and detail pages for features supported by the issuer. Publisher 14 may customize certain visual elements of the user interface, such as providing icons and product names and customizing splash screens.

Mobile applications 10(a)-3' may interface with corresponding payment applications 10(a)-2' using APDU commands to enable proximity payments and provide secure storage of credentials associated with mobile payments and consumers 10.

The download manager 10(a)-3" may be a MIDlet that resides on the mobile phone 10(a) (but not on the secure element 10(a)-2). It is the service activation system 24(a) associated with the secure element Interface between 10(a)-2. It is responsible for initial provisioning, service activation of mobile application 10(a)-3', secure element 10(a)-2, and payment application 10(a)-2' , initialization, management (including locking and unlocking of the mobile application 10(a)-3′) and configuration. The download manager 10(a)-3″ works with the service activation system 24(a) (as part of the backend system) Connects with the local device management and provisioning agent on the mobile phone 10(a) for these functions.

IV. Mobile payment process

A number of exemplary payment processes can be described with reference to FIGS. 2-3.

Referring to FIG. 2, the consumer can select whether the proximity payment function is automatic (always on), manual without PIN or manual with PIN. If the customer selects automatic, the customer needs to designate a default payment account. When in automatic mode, the proximity payment feature is always active, and the payment app will perform the proximity payment transaction when the consumer waves the phone over the contactless reader. If either of the manual options is selected, the consumer will need to enable the mobile app and will need to select the payment feature to activate the proximity payment feature.

Referring to Figure 2, the consumer launches the mobile application (302) and selects the proximity payment setup option (304). Consumers have the option to have the account automatically (always on). If the consumer chooses at 306, 308 to keep the account always on, the mobile application sets the configured AID (Unique Application Identifier) as default. If the customer chooses not to have the account automated, the customer has the option (314, 310, 312) to have that account be the default payment account when making manual payments.

Referring to Figure 3, to manually activate the Proximity Pay function, the consumer selects the Pay or Prepare to Pay function within the mobile payment application. This enables the secure element to mimic a contactless card and interact with the contactless reader associated with the POS terminal. This mode remains active until a specified period of time has elapsed (timeout). If the timeout period expires and the consumer has not yet conducted a Proximity Payment transaction, the mobile application deactivates the Proximity Payment feature, requiring reactivation by the consumer to continue the transaction.

The consumer selects the mobile application to enable it and selects the payment function 320,322. The phone displays the "Ready to Pay" page for 30 seconds, or until the customer navigates away from the page or the payment transaction is complete 324. To continue the transaction, the consumer places the phone near 326 the contactless reader. The reader obtains the account information from the secure element on the phone and completes the transaction. The phone displays the "Payment Sent" page for 15 seconds, or until the customer exits the page. The phone can then revert to its previous state.

V. Dedicated Account Management Process

Referring to Figure 4, when the message is a transaction voucher, transaction alert or payment validation message, it is stored in the transaction message library in the phone. Other messages such as balance inquiries, balance alerts, and payment reminder messages are stored in the transaction message store.

Each item in the message library may correspond to a particular account management event. These events can be provided wirelessly as is the case with most alerts and transaction credentials.

Consumers need to be in the mobile application to access the transaction message library. The main menu of the mobile application provides an option that the customer can select to open the library, as shown in screen shot 330 . The library displays a list of transaction credentials, transaction alerts, and payment validation message summaries, as shown in screen shot 332 .

Referring to Figure 5, as shown in screenshots 334 and 336, the customer can view transaction credentials, transaction alerts, and details of payments that have been made to the account. Specifically, the consumer can view three different types of transaction messages: transaction vouchers, transaction alerts, and payment validation messages. The content of each type of message can be different. The consumer can select a message and then select the view message option to display the message details screen.

Referring to screenshots 338 and 340 in FIG. 6, thresholds for transaction alerts can be configured within the mobile application. Optionally, alert thresholds can be configured on the publisher's Web site. If the threshold is exceeded, a message such as that shown in screen 340 is shown.

Referring to screenshots 342, 344 and 346 in FIG. 7, a customer may request an existing balance of credit products stored in the mobile phone's secure element. This is similar to the usual remote banking functionality, except this is for a mobile phone channel rather than a web channel.

After the issuer processes the balance inquiry, the issuer delivers a response message to the balance inquiry to the consumer's mobile phone. Balance inquiries are displayed and updated for future reference in the account summary function of the mobile application. The balance information requested includes (1) issuer name, (2) current balance, (3) remaining credit available, and (4) a disclaimer regarding the accuracy of the credit account's balance information.

Referring to screenshots 348, 350 and 352 in FIG. 8, a customer may request an existing balance of a debit product stored in the mobile phone's secure element. This is similar to the usual remote banking functionality. Balance inquiries are displayed and updated for future reference in the account summary function of the mobile application. Balance information may include (1) issuer name, (2) current balance in debit account, (3) funds available, (4) available balance, and (5) disclaimer regarding inaccuracies of balance information.

Referring to screenshots 354, 356, 358, and 360 in Figures 9(a) and 9(b), the consumer can register or unregister for payment reminders using the mobile application. Consumers can configure the current status (on/off) of the payment reminder feature.

The consumer does not have to be alerted as to whether the configure payment reminder operation with the issuer was successful. Only consumer choices need to be confirmed within the mobile application when making those choices.

Referring to screenshots 362, 364 and 366 in FIG. 10, the customer can configure the balance level at which the balance alert occurs. This use case describes this option for the case where the payment device is a credit product. The consumer configures the following: (1) the credit balance at which balance alerts will be generated; and (2) the current state (on/off) of the balance alert feature.

The consumer does not have to be alerted as to whether the configure balance alert operation with the issuer was successful. Only consumer choices need to be confirmed from within the mobile application when making those choices.

Referring to screenshot 372 in Figure 11(a), the consumer receives a credit product balance alert when a predetermined threshold has been exceeded. The publisher generates this alert, and the alert is sent to the consumer's handheld device.

Referring to screenshot 374 in Figure 11(b), the customer receives a balance alert for debited products when a predetermined threshold has been exceeded. The publisher generates this alert, and the alert is sent to the consumer's handheld device.

Referring to screenshot 376 in FIG. 12, the consumer receives an issuer-generated risk alert when the consumer's payment account is blocked for reasons specific to the issuer. The issuer generates this alert, and the alert is sent to the customer's phone.

Whether or not a platform password is configured, the mobile application is enabled and the message is displayed to the consumer. Once the message is displayed, the consumer will only have the option to acknowledge receipt of the message, which will exit the application. In some embodiments, this message is never stored.

Embodiments of the invention may also include offers as shown in screenshots 378 , 380 and 382 in FIG. 13 . First, the offer library on the phone can be selected as shown in screen shot 378, thereby opening the offer library and checking to see if the offer has expired. As shown in screenshot 380, different merchants offering different offers may be displayed. The consumer can select one of them, so that merchant's specific offers can be displayed. The consumer can then redeem the offer in a number of ways, including using the above-mentioned NFC element or contactless element to communicate with the POS terminal.

VI. Multi-issuer dedicated payment service capability

As noted above, the customization and configuration process may include receipt of data associated with an issuer-specific payment application instance that may be linked to an issuer-specific payment service. This data may include computer code for a publisher-specific application, code for a publisher-specific instance, or code for a link to a publisher-specific application or instance. For example, in some embodiments of the invention, there may be many different issuer-specific payment application instances linked to different issuer-specific payment services. Different issuer-specific payment services may have different sets of functions. For example, an issuer may provide promotional messages, but not deal warning messages. Another issuer may provide transaction warning messages, but not promotional messages. In an embodiment of the invention, the consumer 10 can select an issuer-specific payment service as the default service used by his phone 10(a), and can use the phone 10(a) with the selected issuer-specific payment service to carry out transactions such as payment transactions. Issuer-specific payment services may include dedicated management services or value-added services and payment functionality.

In some embodiments, once the device is loaded, the instance may be the default instance if no more than one instance exists on the device. In other embodiments, there may be multiple payment applications on the mobile phone that are specifically associated with different issuers. The customer can choose from different issuer-specific payment applications, as shown in Figure 14(a) (Bank A, Bank B, and Bank C applications in window 390). Once a payment application is selected (eg, Bank B in window 392), it can be set as the default payment application, as shown in Figure 14(b).

Referring to the screenshots 402, 404, 406, 408, 410 in Figure 15, from a usability perspective, this process strives to achieve the desired result while requiring minimal interaction from the customer. The issuer decides to allow consumer configuration and to what extent. Consumer interactions are preferably consistent.

Also from a usability point of view, the issuer may not allow consumers to have any configuration options. For example, the issuer can configure the platform to be automatically enabled (always on) and freely accessible (ie, no password required). It is also possible for issuers to only allow consumers to change certain configuration options. For example, issuers can configure the platform to manually enable with mandatory password-protected access, in which case consumers can only be prompted for a password. In both cases above, the consumer is always given the option to set the platform as the default for Proximity Payments.

VII. COMPUTER DEVICES AND MOBILE TELEPHONES

The various parties and elements in Figure 1 may operate one or more computer devices to facilitate the functions described herein. Any of the elements in FIG. 1 including offers engine 18, messaging gateway 20(a), issuer 14, directory service engine 22(a), service activation system 24(a), and mobile operator 26 may use any An appropriate number of subsystems to facilitate the functions described herein. Examples of these subsystems or components are shown in FIG. 16 . The subsystems shown in FIG. 16 are interconnected via a system bus 775 . Additional subsystems are shown such as printer 774 , keyboard 778 , fixed disk 779 (or other storage including computer readable media), monitor 776 coupled to display adapter 782 . Peripherals and input/output (I/O) devices coupled to I/O controller 771 can be connected to the computer system through various means known in the art, such as serial port 777 . For example, serial port 777 or external interface 781 may be used to connect the computer device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus enables the central processor 773 to communicate with each subsystem and control the execution of instructions from system memory 772 or fixed disk 779, and the exchange of information between subsystems. System memory 772 and/or fixed disk 779 may embody computer readable media.

Figure 17 shows a block diagram of another phone 32 that may be used in embodiments of the present invention. These components may be combined with the functional components shown in phone 10(a) in FIG. An exemplary wireless telephone 32 may include a computer readable medium and a main body, as shown in FIG. 17 . The computer readable medium 32(b) may reside within the main body 32(h), or may be detachable therefrom. The body 32(h) may be in the form of a plastic substrate, housing, or other structure. The computer-readable medium 32(b) may be memory that stores data (eg, data related to an issuer-specific payment service) and may be in any suitable form, including magnetic strips, memory chips, and the like. The memory preferably stores information such as financial information, transport information (eg as in a subway or train pass), admission information (eg as in an access badge). Financial information may include information such as bank account information, bank identification number (BIN), credit or debit card number information, account balance information, due dates, consumer information such as name, birthday. Any of these messages can be sent by the mobile phone 32 .

In some embodiments, the information in the memory may also be in the form of data tracks traditionally associated with credit cards. These tracks include Track 1 and Track 2. Track 1 ("International Air Transport Association") stores more information than Track 2 and contains the cardholder's name as well as account number and other optional data. This track is sometimes used by airlines when they guarantee a reservation with a credit card. Track 2 ("American Banking Association") is currently the most commonly used. This is the magnetic track read by ATMs and credit card checkers. The ABA (American Banking Association) devised the specification for this track and all banks in the world have to follow it. This track contains the cardholder's account number, encrypted PIN, and other optional data.

The phone 32 may also include a contactless element 32(g), typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transmission (eg, data transmission) element such as an antenna. The contactless element 32(g) is associated with (e.g., embedded in) the telephone 32, and data or control commands sent via the cellular network can be applied to the contactless element 32 through a contactless element interface (not shown). (g). The contactless element interface is used to permit the exchange of data and/or control instructions between the mobile device circuitry (and thus the cellular network) and the optional contactless element 32(g).

The contactless element 32(g) is typically capable of transmitting and receiving data using NFC capabilities (or near field communication medium) according to a standardized protocol or data transfer mechanism (eg, ISO 14443/Near Field Communication (“NFC”)). Near field communication capabilities are short-range communication capabilities, such as RFID, Bluetooth ^™ , infrared, or other data transmission capabilities that may be used to exchange data between phone 32 and the interrogation device. Thus, the phone 32 is capable of communicating and transmitting data and/or control instructions via both the cellular network and near field communication capabilities.

The phone 32 may also include a processor 32(c) (eg, a microprocessor) for handling the functions of the phone 32 and display 32(d) to enable the customer to see the phone number and other information and messages. The phone 32 may also include: an input element 32(e) for enabling the consumer to enter information into the device; a speaker 32(f) for enabling the consumer to hear voice communications, music, etc.; The recipient can send her voice through the phone 32 to the microphone 32(i). The phone 32 may also include an antenna 32(a) for wireless data transmission (eg, data transmission).

It should be understood that the present invention may be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and understand other ways and/or methods to implement the present invention using a combination of hardware and software.

Any software component or function described in this application may be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques, using any suitable computer language, such as Java, C++, or Perl. The software code may be stored as a series of instructions or commands on a computer readable medium such as random access memory (RAM), read only memory (ROM), magnetic media such as hard or floppy disks, or optical media such as CD-ROM . Any such computer readable medium may reside on or within a single computing device, and may reside on or within different computing devices within a system or network.

The above description is illustrative rather than limiting. Many variations of the invention will become apparent to those skilled in the art upon review of the present disclosure. The scope of the invention, therefore, should be determined not with reference to the above description, but should instead be determined with reference to the appended claims along with their full scope or equivalents.

One or more features from any embodiment may be combined with one or more features from any other embodiment without departing from the scope of the invention.

References to "a", "an" or "the" are intended to mean "one or more" unless specifically indicated to the contrary.

Claims (19)

1. method comprises:

Use mobile phone to receive the account balance query response message, wherein said mobile phone comprises the contactless element that is configured to the contactless reader communication of point of sales terminal, and wherein said account balance query response message provides the account balance of the account that is associated with described mobile phone, and described mobile phone is operated by the consumer;

Use described mobile phone to receive the transaction alert message, the described consumer of wherein said transaction alert notification has used the transaction of described account; And

Receive preferential message, if wherein described consumer uses described mobile phone to carry out pre arranged trading, then described preferential message provides benefited for described consumer.

2. the method for claim 1 is characterized in that, also comprises:

Use described mobile phone to produce payment reminders message.

3. the method for claim 1 is characterized in that, also comprises receiving remaining sum threshold alerts message, and wherein when the remaining sum threshold value of previous appointment was exceeded, described remaining sum threshold alerts message was warned described consumer.

4. the method for claim 1 is characterized in that, also comprises receiving the risk alert message, and wherein said risk alert message is warned the described consumer suspicious activity relevant with described account, and notifies the described account of described consumer to be prevented from.

5. the method for claim 1 is characterized in that, also comprises using described mobile phone to receive Fail Transaction voucher message.

6. the method for claim 1 is characterized in that, described phone comprises safety element, and described safety element comprises the payment application of issuer-specific.

7. computer-readable medium comprises:

Be used to use mobile phone to receive the code of account balance query response message, wherein said mobile phone comprises the contactless element that is configured to the contactless reader communication of point of sales terminal, and wherein said account balance query response message provides the account balance of the account that is associated with described mobile phone, and described mobile phone is operated by the consumer;

Be used to use described mobile phone to receive the code of transaction alert message, wherein said transaction alert message notifies described consumer to use the transaction of described account; And

Be used to receive the code of preferential message, if wherein described consumer uses described mobile phone to carry out pre arranged trading, then described preferential message provides benefited for described consumer.

8. computer-readable medium as claimed in claim 7 is characterized in that, also comprises being used to use described mobile phone to produce the code of payment reminders.

9. computer-readable medium as claimed in claim 7 is characterized in that, also comprises the code that is used to receive remaining sum threshold alerts message, and wherein when the remaining sum threshold value of previous appointment was exceeded, described remaining sum threshold alerts message was warned described consumer.

10. computer-readable medium as claimed in claim 7 is characterized in that, also comprises the code that is used to receive Fail Transaction voucher message.

11. phone that comprises computer-readable medium as claimed in claim 7.

12. a method comprises:

The inquiry into balance response message is sent to mobile phone, wherein said mobile phone comprises the contactless element that is configured to the contactless reader communication of point of sales terminal, and wherein said account balance query response message provides the account balance of the account that is associated with described mobile phone, and described mobile phone is operated by the consumer;

The alert message of will concluding the business is sent to described mobile phone, and wherein said transaction alert message notifies described consumer to use the transaction of described account; And

Preferential message is sent to described mobile phone, if wherein described consumer uses described mobile phone to carry out pre arranged trading, then described preferential message provides benefited to described consumer.

13. method as claimed in claim 12 is characterized in that, comprising:

Payment reminders message is sent to described mobile phone.

14. method as claimed in claim 12 is characterized in that, also comprises:

The risk alert message is sent to described mobile phone, and wherein said risk alert message is warned the described consumer suspicious activity relevant with described account, and notifies the described account of described consumer to be prevented from.

15. method as claimed in claim 12 is characterized in that, also comprises:

Send remaining sum threshold alerts message, wherein when the remaining sum threshold value of previous appointment was exceeded, described remaining sum threshold alerts message was warned described consumer.

16. a computer-readable medium comprises:

Be used for the inquiry into balance response message is sent to the code of mobile phone, wherein said mobile phone comprises the contactless element that is configured to the contactless reader communication of point of sales terminal, and wherein said account balance query response message provides the account balance of the account that is associated with described mobile phone, and described mobile phone is operated by the consumer;

Be used for the transaction alert message is sent to the code of described mobile phone, wherein said transaction alert message notifies described consumer to use the transaction of described account; And

Be used for preferential message is sent to the code of described mobile phone, if wherein described consumer uses described mobile phone to carry out pre arranged trading, then described preferential message provides benefited to described consumer.

17. computer-readable medium as claimed in claim 16 is characterized in that, also comprises:

Be used for payment reminders message is sent to the code of described mobile phone.

18. computer-readable medium as claimed in claim 16 is characterized in that, also comprises:

Be used to send the code of remaining sum threshold alerts message, wherein when the remaining sum threshold value of previous appointment was exceeded, described remaining sum threshold alerts message was warned described consumer.

19. a communication server comprises the computer-readable medium as claimed in claim 16 that is coupled to described processor in processor and the operation.

Images