CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of application Ser. No. 11/933,321, filed Oct. 31, 2007, which is a continuation-in-part of application Ser. No. 11/467,441, filed Aug. 25, 2006, now abandoned, which claims priority to U.S. Provisional Patent Application No. 60/766,171 and U.S. Provisional Patent Application No. 60/766,172, both filed on Dec. 31, 2005, all of which are incorporated by reference herein in their entireties.
FIELD OF INVENTION
The present invention relates to data communications and wireless devices.
BACKGROUND OF THE INVENTION
Online transactions—e.g., for purchasing goods, receiving downloads, and so on—which involve personal computers and the Internet are well known. Further, wireless mobile communication devices, such as cell phones, blackberries or other personal digital assistants, are also being used for making transactions. For example, U.S. Patent Application No. US/2003/0172028 provides a description of a personal payment system that utilizes a wireless enabled device such as a cell phone. As described, the personal payment system interacts using a Bluetooth protocol with a terminal located nearby the wireless enabled device. In another example, U.S. Pat. No. 7,031,945 describes a system and method that provides an electronic ticket to a smart card or standard wireless device that is identified with a user's account.
Further, wireless mobile devices that include a near field communication (NFC) device and a smart card (that uses an RFID for identification purposes) allow a person to securely make a simple transaction, such as for example, purchasing a bus ticket. In such an example, the person typically waves the wireless mobile device near a reader installed in a bus, and a price of the bus ticket is deducted from a total amount that is available and stored on the smart card of the wireless mobile device. Optionally, the amount of the bus ticket can be forwarded to a server that can identify the identification code of the particular RFID and then subsequently charge the person for the purchase of the bus ticket.
While the references discussed above illustrate that certain transactions are possible using wireless mobile devices, one problem associated with the references are is that implementations described in the references are not useful in a wide variety of different platforms, but rather are typically tied to a specific platform. For example, NFC devices are only usable with NFC readers. Another problem is that conventional wireless mobile devices generally have a very limited ability to be used in transactions.
SUMMARY OF THE INVENTION
In general, in one aspect, this specification describes a method and system for configuring a mobile communication device to perform transactions using a second communication channel that is different from a first communication channel through which the mobile communication device sends voice data. The method includes attaching a secure element to the mobile communication device. The secure element includes a memory storing an application, a processor configured to execute the application stored in the memory; and a wireless transceiver configured to send transaction data associated with the executed application through the second communication channel to a terminal that is remote from the mobile communication device.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates one implementation of a block diagram of a communication system including a wireless mobile communication device.
FIG. 2 illustrates one implementation of radio element in the wireless mobile communication device of FIG. 1.
FIG. 3 illustrates one implementation of a wireless mobile communication device.
FIGS. 4A-4C respectively illustrate an implementation of a secure element in the wireless mobile communication device of FIG. 1.
FIG. 5 illustrates one implementation of a point of sale terminal.
FIGS. 6A-6D illustrate a flowchart for conducting a transaction according to one implementation.
FIG. 7 illustrates one implementation of a secure element that is attachable to a wireless communication device.
FIG. 8 illustrates a communication system in accordance with one implementation.
FIG. 9 illustrates a communication system in accordance with one implementation.
FIGS. 10A-10B illustrate example client user interfaces that are displayable on a display of the mobile communication device of FIG. 9.
Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTION OF THE INVENTION
This disclosure describes a communication system and method for assisting a user to complete a transaction. FIG. 1 illustrates one implementation of a communication system 100. The communication system 100 includes a hand-held, wireless mobile communication device 110 that (in one implementation) includes a radio element 120 and a secure element 130. A display 124 is shown associated with the radio element 120, and antennas (not labeled) are shown as associated with each of the radio element 120 and the secure element 130. Each antenna can physically be implemented in a manner that is different from the wireless antennas shown in FIG. 1. For example, an antenna can comprise a stripe that is passed along a reader, or comprise some suitable transmission mechanism. Although elements 120 and 130 are shown as distinct and separate, and display 124 is shown as connected to the radio element 120, other configurations are possible. In particular, a combination in which a single processor is used to execute the functions that are currently performed and described herein as being provided by both the radio element 120 and the secure element 130. Further as illustrated in FIG. 1, both the radio element 120 and the secure element 130 are internal to the mobile communication device 110, although in other implementations the secure element 130 can be external to the mobile communication device 110, as described below. Also, various different functionalities can be included within the radio element 120 and the secure element 130.
In one implementation, the mobile communication device 110 has the functionality to communicate with one of many different a point of sale (POS) terminals 150-1 to 150-n—e.g., in a contactless manner using a wireless protocol. The mobile communication device 110 can also similarly communicate with one or more point of entry (POE) terminals 190-1 to 190-n. The point-of-sale terminal 150 receives one of the transaction request signals from the mobile communication device 110 and transmits the one transaction request signal to a transaction server 170, typically using a communication channel 160 such as the Internet. The transaction server 170 verifies the transaction, and forwards a transaction verification signal to the management server 180. The management server 180 identifies the user corresponding to the transaction verification signal, and provides a first transaction response signal back to the mobile communication device 110 as one of the transaction signals.
In one implementation, the first transaction response signal is communicated back to the mobile communication device 110 using a communication channel that is different from the communication channel used to initiate the transaction. In one implementation, different transaction response signals can be communicated back to the mobile communication device 110 using communication channels from the management server 180 to the radio element 120 associated with the device 110, as well as from the management server 180 to the secure element 130 through the POS terminal 150 or the POE terminal 190. Further detailed descriptions of these implementations are discussed in greater detail below.
FIG. 2 illustrates one implementation of the radio element 120 associated with the mobile communication device 110, and illustrates the radio element 120 connected to the display 124 of the mobile communication device 110. In one implementation, the radio element 120 includes a radio transceiver 122 that is adapted to send outgoing voice and data signals and receive incoming voice and data signals over a radio communication channel. The radio communication channel can be a digital radio communication channel, such as CDMA or GSM. Such a radio communication channel has the capacity to communicate both voice and data messages using conventional techniques. The radio transceiver 122 communicates with a radio processor 123, which processor has the capability to perform not only the radio communication services necessary to allow for phone and data communications, but can also execute various programs that are stored in the memory 126, which programs can receive inputs from the user via the display 124 and/or a keypad 125 associated with the mobile communication device 110.
In one implementation, application programs running on the radio processor 123 are, e.g., BREW or J2ME applications and can encompass a broad array of application types. For example, current applications include games, enterprise applications, and multimedia applications. In one implementation, the radio processor 123 runs an application that provides movie and event information. Such an application can comprise ticketing applications, content, item and service purchase applications, and/or payment management applications (referred to herein also as “wallet applications”). In one implementation, the radio processor 123 also has the capability of recognizing secure communications, and transmits data which must be stored in a secure environment to the secure element driver 128 for transmission to the secure element 130. In one implementation, in which both the radio element 120 and the secure element 130 are internal to the mobile communication device 110, transmissions to the secure element 130 can take place using an internal wired communication channel. In one implementation, the radio processor 123 also has the capability of receiving data from the secure element 130, e.g., using the internal wired communication channel. In one implementation, the secure element 130 and the radio element 120 communicate using signals described in the Java Card 2.1 Platform API Specification.
In one implementation, both the radio element 120 and the secure element 130 are disposed internally within a body of the mobile communication device 110. For example, referring to FIG. 3, the mobile communication device 110 is shown including a slot 400, which allows for the insertion of a secure element 130 into the slot 400. In this configuration, the secure element 130 can be purchased independently of the mobile communication device 110. The secure element 130 can also be disposed into a slot that only provides for physical insertion and mechanical connection to the body of the mobile communication device 110. In such an implementation, the secure element can include a transceiver that allows for the communication with the radio element 130 through a wireless local communication channel. The radio element 120 also is illustrated as optionally including another transceiver 129, such as a Bluetooth or WIFI transceiver, which can transmit and receive signals with an external device and then communicate signals to and from the radio processor 123. This additional communication channel allows for communications between other external devices, such as an external Bluetooth enabled smartcard, and provides an additional communication channel that is useful for certain transactions, as described further herein.
FIG. 4A illustrates one implementation of the secure element 130 associated with the mobile communication device 110. The secure element 130 can be a smart card. In one implementation, the secure element 130 includes a secure processor 132, a secure memory 133, and a POS transceiver 134 adapted to send transaction request signals and receive transaction response signals over a first communication channel. In one implementation, the secure processor 132 communicates via the secure element driver 128 with the radio processor 123 using signals as described in the Java Card 2.1 Platform API Specification. The transaction request signals and the transaction response signals associated with the transaction can include an identification code associated with the user, as well as information relative to the transaction, such as item, quantity, vendor, and so on. In one implementation, the POS transceiver 134 is an NFC device, which uses an NFC modem. The POS transceiver 134 can also be a Bluetooth, WIFI or other transceiver. In an implementation in which the POS transceiver is an NFC modem, such an NFC modem will typically have a set of registers that can be read/written by the secure processor 132. These registers are in turn available for reading and writing over the RFID communications channel and serve as a shared memory between the secure processor 123 within the secure element 130 and the RFID reader that is associated with the POS terminal 150. This communication is specified, for example, in the ISO 14443A/B standard. The secure element can optionally include a radio/Bluetooth/WIFI transceiver 136, which can communicate with other devices, such as a transceiver associated with the radio processor 120 or for other external devices having those communication capabilities, thus allowing for more flexibility.
FIG. 4B shows another implementation of a secure element 130, in which the radio element 120 does not communicate with the secure element 130 through a secure element driver 128. In this case, for example, the secure element 130 may be external to the mobile communication device 110 and as such is not connected to the radio element through the secure element driver 128. In such an implementation, however, if the transceiver 136 as described above is included, and a similar transceiver 129 associated with the radio element 130 as described previously with respect to FIG. 2 is included, then this communication channel can be used to wirelessly obtain direct communications between the radio element 120 and the secure element 130. This implementation allows for certain bidirectional communications with other devices, as well as with the radio element 120, and as such more functionality and flexibility is achieved. This implementation is particularly useful since it establishes a direct local communication path with the radio element 120, since there is not communications with the radio element 120 via the path of driver 128.
This implementation allows for certain bidirectional communications with other devices, as well as with the radio element 120, and as such more functionality and flexibility is achieved. This implementation is particularly useful for establishing a direct local communication path with the radio element 120, since there are no communications with the radio element 120 via the path of driver 128. If either of the transceivers 129 or 136 are not associated with the respective radio element 120 or secure element 130, and there is no direct connection between the radio element 120 and the secure element 130, then a direct communication link between the radio element 120 an the secure element 130 will not exist. As such, while ticketing and many transactions can still exist, data from a real-time transaction performed using the secure element 130 cannot be made directly available to the radio processor and the applications stored thereon. In such an implementation, certain redundancy checks may not occur. For example, a ticketing application can be programmed to provide an alert if a ticket receipt has not been received within a certain period of time. Such an alert would not be possible to program directly (although it could be programmed indirectly via the button panel on the phone).
FIG. 7 illustrates one implementation of a secure element 130 that can be attached (or affixed) externally to a wireless communication device (e.g., mobile communication device 110). In one implementation, the secure element 130 has circular shape. The secure element 130 can have other suitable shapes—e.g., rectangular, triangular, and so on. In one implementation, the secure element 130 includes an embedded smart chip 702 that is capable of executing proximity services (e.g., services related to payments, ticketing, identification, sending coupons, etc.). In one implementation, the smart chip 702 is capable of 2-way wireless communication (e.g., RFID, NFC, Bluetooth, etc.) with a supporting 3rdParty terminal. In one implementation, the 2-way communication is performed using a communication protocol that is different from a communication protocol through which the mobile communication device sends or receives voice and/or data signals. Multiple application protocols (NFC, MiFare, etc.) can be supported. In one implementation, the smart chip 702 is programmable. Accordingly, different application (for payments, ticketing, identification, coupons, etc.) can be developed, downloaded to the smart chip, and commissioned. Thus in operation, in response to the secure element 130 being placed in close proximity with a suitable terminal, the terminal will trigger (via application protocol) an appropriate application stored in the smart chip, and the smart chip will respond appropriately with the terminal.
In one implementation, the smart chip uses a low-power RF transmitter/receiver to communicate with a terminal. The low-power output of the smart chip makes it susceptible to RF interference from neighboring devices. Specifically problematic are components associated with the mobile communication device, e.g., battery, antennae (internal or external), to which the secure element 130 is affixed. Thus, in one implementation, the secure element 130 includes an RF shield to insulate the smart chip from external interference. In one implementation, a lining of the secure element 130 is composed of an RF absorbent material/lining. In general, each phone has different levels of interference, and a material, size and thickness of the RF lining can determine an effectiveness of the RF shield. In one implementation, an RF shield can be placed between the secure element 130 and the mobile communication device 110.
Given the abuse a mobile communication device can take, components that are affixed externally to a mobile communication device need to be able to withstand some abuse. Thus, in one implementation, the secure element includes a ruggedized shell 704 that encases a smart chip (with antennae). In one implementation, the shell 704 is formed from a composite plastic or polymer. The shell 70 can be hard (and substantially inflexible) or be soft (and pliable). In one implementation, the shell 704 provides a protective membrane for the smart chip which prevents damage to internal circuitry, a surface to adhere to an RF lining and/or a mobile communication device with appropriate adhesive, and a surface to print branding and advertising. Types of adhesives that can be used to affix the secure element 130 to a mobile communication device include, for example, paper glue, super glue, polymers, and the like. In one implementation, the shell 704 has a maximum width (or diameter) of 25 mm, and has a maximum thickness (or depth) of 5 mm.
FIG. 4C shows another implementation of a secure element 130, in which the secure element 130 does not include a processor that is capable of bidirectional communications, but instead includes a passive device 138. The passive device 138 can be an RFID sticker or suitable tag that allows for uniquely identifying a user, such that a transaction that is initiated with the passive device 138 will cause the management server 180 to perform transaction details. In this implementation, the code received from the POS terminal 150 (or the POE terminal 190) is transmitted from the POS terminal 150 (or the POE terminal 190) to the management server 190, which then takes over the transaction. This passive device 138, with the identification code stored thereon, can thus be associated with a mobile communication device 110 not otherwise equipped for such communications, and the management server 190 can provide transactional information to the mobile communication device 110 using available channels on the mobile communication device (such as audio, SMS, or other known data transmission methods). While bidirectional communications do not occur with other devices, transactions are possible, because the management server 190 is involved.
SMS (Short Messaging Service) As A Data Transmission Method
As discussed above SMS (Short Message Service) can be used as a data transmission method between the management server 190 and the mobile communication device 110. SMS is generally unstructured. Thus, when messages arrive in an inbox of a user inbox, the user cannot easily search, retrieve, or organize the messages. In addition, due to SMS's send-and-forget characteristics, it cannot be assumed that messages are received by the terminating point, or if received, received in a particular sequence. FIG. 8 illustrates a communication system 800 in accordance with one implementation. The communication system 800 includes a mobile communication device 802 that communicates with a remote server 804 (e.g., a transaction server) via SMS. The mobile communication device 802 includes a mobile application 806 that receives SMS messages from the remote server 804 and organizes the SMS messages (including linking corresponding messages into a pre-determined order) so that data can be stored and displayed to a user in an organized and easily retrievable fashion, unlike a conventional application that implements SMS as a data transmission method in which SMS messages remain in an unstructured format and are unlinked. Such an unstructured format does not allow the user to retrieve, organize, or manage the display of messages. The mobile application 806 can be, for example, a J2ME, BREW, Windows Mobile, or other type of application.
In one implementation, the mobile application 806 is a rich client application (also commonly referred to as a fat client application or thick client application). A rich client application is a client application that performs the bulk of any data processing operations itself, and does not necessarily rely on a server (e.g., remote server 804). The mobile application 806 can also be a thin client application or hybrid client application. In one implementation, the mobile application 806 is the Blaze Mobile Wallet Lite application available from Mobile Candy Dish Inc. or Berkeley, Calif.. In one implementation, the mobile application 806 provides banking and money management transaction services, and transmits data from the wireless communication device 802 via SMS in accordance with a connectionless protocol.
FIG. 9 illustrates a communication system 900 in accordance with one implementation. The communication system 900 includes a mobile communication device 902, a management server 904, a user/profile database 906, and a money management database 908. In one implementation, the management server 904 is a Blaze server. In one implementation, the mobile communication device 902 stores a mobile application 910 that uses short message service (SMS) over a connectionless protocol to transmit data to the management server 904. SMS permits the mobile application 910 to send messages of a fixed size, for example, up to 160 characters, to and from the wireless mobile communication device 902. In one implementation, the management server 904 includes an SMS aggregator 912 to aggregate each message received from the wireless mobile communication device 902 and keep track of the ordering of each message, and (in one implementation) also groups each message into a corresponding group. In one implementation, the mobile application 910 also includes an SMS aggregator (not shown).
Thus, in one implementation, the mobile application 910 is not browser HTTP based, and delivers banking and money management services. The mobile application 910 also leverages a low-end communication infrastructure (also referred to herein as a “bearer service”). A bearer service that is universal on all mobile devices is the Short Message Service (SMS). SMS is a means of sending short messages to and from mobile phones to the Application Service Provider (ASP) Server “Server”. It is inherently a connectionless communication protocol, i.e., send and forget. There is no acknowledgement to the Mobile Originating (MO) sender that the message sent was successfully received by the Mobile Terminating (MT) recipient. There is no concept of timeouts, message lost, message not received, etc. Leveraging SMS as a bearer service to support a ‘rich’ client application. The Client will listen to a specific incoming SMS port to be defined based on Network Operator/Carrier, Phone Vendor, etc.
In one implementation, the mobile application 910 provides banking and money management service, which includes (but is not limited to):
Registration: User creates new MW Lite account with PIN (PIN and user info can be stored in user/profile database 306)
Security & Encryption: Sensitive information may optionally by encrypted using 3rdParty or native phone tools (Bouncy Castle, etc.). Encryption (Public/Private) keys may be managed or proxy'd by Server which may additionally be out-sourced to 3rdparty Key Management vendor.
Install & Configuration (I&C): Refers to setting up proxies to
payment accounts (virtual, credit, debit & banking)
Payees (BillPay, PayAnyone, etc.) and associated rules
Specify default payment account to debit fund transfers/unloading
Specify default payment account to credit fund transfers/loading
Activation of 3rdParty Services (Account Balance, Bill Pay, Fund Transfer, Funds Loading, Funds Unloading)
It is assumed Client application is pre-installed or downloaded to mobile device.
I&C to be performed via Kiosk, ATM, 3rdParty/Carrier Web Portal, MCD Web Portal, on mobile device, or other suitable device.
Banking or financial data
Bill Pay—Biller Direct
Fund Transfer—Intra Bank; Me-2-Me
Fund Transfer—Inter Bank; Me-2-Me
Fund Transfer—Inter Bank; Me-2-You (based on Bank Routing/Account#)
Fund Transfer—Inter Bank; Me-2-You (based on WalletID)
Fund Transfer—Inter Bank; Me-2-You (based on ACH Check). A.k.a. Bill Pay Anyone
Unload Funds (ATM Withdrawal, etc.)
Sync: Ensures server-side objects are downloaded to client and locally cached. This includes payment accounts, payees, payment rules, server-side cached account info (account balance, Last-N transaction history), etc.
This info will be cached on Client.
Users can create transaction either in ONLINE or OFFLINE (no network connectivity) mode
Initiating/Triggering Banking Services:
Storage: Storage of Users MWLite info, User\'s payment account info (credentials, account balance, history, etc.); Banking Payment History (BillPay, Fund Transfer, Fund Loads, Fund Unloads, etc.)
1. Overlaying connection protocol properties over SMS. This includes: segmenting complex command and control (C&C) messages into 1 or more SMS messages, and re-constructing one or more SMS messages into complex C&C resultset messages. Re-constructing the one or more messages into complex C&C resultset messages can include one or more of the following providing acknowledgement, handling out-of-sequence incoming messages, handling unexpected messages or messages considered lost (due to timeout, etc.), Managing encryption as needed, and so on.
2. User uses the mobile application 910 to initiate/trigger appropriate banking service. For example, referring to FIG. 10A a user can initiate a bill paying service through which a payee (e.g., PG&E) can be paid. In one implementation, the display of the bill pay screen can include an advertisement as shown in FIG. 10A.
3. The mobile application 910 formulates appropriate banking services commands, for example: