Financial transaction processing using a mobile communications device

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This 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

0002The present invention relates to data communications and wireless devices.

BACKGROUND OF THE INVENTION

0003Online 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. U.S./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.

0004Further, 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.

0005While 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.

BRIEF SUMMARY OF THE INVENTION

0006In 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.

0007The 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

0008<figref idref="DRAWINGS">FIG. 1</figref> illustrates one implementation of a block diagram of a communication system including a wireless mobile communication device.

0009<figref idref="DRAWINGS">FIG. 2</figref> illustrates one implementation of radio element in the wireless mobile communication device of <figref idref="DRAWINGS">FIG. 1</figref>.

0010<figref idref="DRAWINGS">FIG. 3</figref> illustrates one implementation of a wireless mobile communication device.

0011<figref idref="DRAWINGS">FIGS. 4A-4C</figref> respectively illustrate an implementation of a secure element in the wireless mobile communication device of <figref idref="DRAWINGS">FIG. 1</figref>.

0012<figref idref="DRAWINGS">FIG. 5</figref> illustrates one implementation of a point of sale terminal.

0013<figref idref="DRAWINGS">FIGS. 6A-6D</figref> illustrate a flowchart for conducting a transaction according to one implementation.

0014<figref idref="DRAWINGS">FIG. 7</figref> illustrates one implementation of a secure element that is attachable to a wireless communication device.

0015<figref idref="DRAWINGS">FIG. 8</figref> illustrates a communication system in accordance with one implementation.

0016<figref idref="DRAWINGS">FIG. 9</figref> illustrates a communication system in accordance with one implementation.

0017<figref idref="DRAWINGS">FIGS. 10A-10B</figref> illustrate example client user interfaces that are displayable on a display of the mobile communication device of <figref idref="DRAWINGS">FIG. 9</figref>.

0018Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION OF THE INVENTION

0019This disclosure describes a communication system and method for assisting a user to complete a transaction. <figref idref="DRAWINGS">FIG. 1</figref> illustrates one implementation of a communication system <b>100</b>. The communication system <b>100</b> includes a hand-held, wireless mobile communication device <b>110</b> that (in one implementation) includes a radio element <b>120</b> and a secure element <b>130</b>. A display <b>124</b> is shown associated with the radio element <b>120</b>, and antennas (not labeled) are shown as associated with each of the radio element <b>120</b> and the secure element <b>130</b>. Each antenna can physically be implemented in a manner that is different from the wireless antennas shown in <figref idref="DRAWINGS">FIG. 1</figref>. For example, an antenna can comprise a stripe that is passed along a reader, or comprise some suitable transmission mechanism. Although elements <b>120</b> and <b>130</b> are shown as distinct and separate, and display <b>124</b> is shown as connected to the radio element <b>120</b>, 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 <b>120</b> and the secure element <b>130</b>. Further as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, both the radio element <b>120</b> and the secure element <b>130</b> are internal to the mobile communication device <b>110</b>, although in other implementations the secure element <b>130</b> can be external to the mobile communication device <b>110</b>, as described below. Also, various different functionalities can be included within the radio element <b>120</b> and the secure element <b>130</b>.

0020In one implementation, the mobile communication device <b>110</b> has the functionality to communicate with one of many different a point of sale (POS) terminals <b>150</b>-<b>1</b> to <b>150</b>-<i>n</i>—e.g., in a contactless manner using a wireless protocol. The mobile communication device <b>110</b> can also similarly communicate with one or more point of entry (POE) terminals <b>190</b>-<b>1</b> to <b>190</b>-<i>n</i>. The point-of-sale terminal <b>150</b> receives one of the transaction request signals from the mobile communication device <b>110</b> and transmits the one transaction request signal to a transaction server <b>170</b>, typically using a communication channel <b>160</b> such as the Internet. The transaction server <b>170</b> verifies the transaction, and forwards a transaction verification signal to the management server <b>180</b>. The management server <b>180</b> identifies the user corresponding to the transaction verification signal, and provides a first transaction response signal back to the mobile communication device <b>110</b> as one of the transaction signals.

0021In one implementation, the first transaction response signal is communicated back to the mobile communication device <b>110</b> 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 <b>110</b> using communication channels from the management server <b>180</b> to the radio element <b>120</b> associated with the device <b>110</b>, as well as from the management server <b>180</b> to the secure element <b>130</b> through the POS terminal <b>150</b> or the POE terminal <b>190</b>. Further detailed descriptions of these implementations are discussed in greater detail below.

0022<figref idref="DRAWINGS">FIG. 2</figref> illustrates one implementation of the radio element <b>120</b> associated with the mobile communication device <b>110</b>, and illustrates the radio element <b>120</b> connected to the display <b>124</b> of the mobile communication device <b>110</b>. In one implementation, the radio element <b>120</b> includes a radio transceiver <b>122</b> 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 <b>122</b> communicates with a radio processor <b>123</b>, 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 <b>126</b>, which programs can receive inputs from the user via the display <b>124</b> and/or a keypad <b>125</b> associated with the mobile communication device <b>110</b>.

0023In one implementation, application programs running on the radio processor <b>123</b> 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 <b>123</b> 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 <b>123</b> also has the capability of recognizing secure communications, and transmits data which must be stored in a secure environment to the secure element driver <b>128</b> for transmission to the secure element <b>130</b>. In one implementation, in which both the radio element <b>120</b> and the secure element <b>130</b> are internal to the mobile communication device <b>110</b>, transmissions to the secure element <b>130</b> can take place using an internal wired communication channel. In one implementation, the radio processor <b>123</b> also has the capability of receiving data from the secure element <b>130</b>, e.g., using the internal wired communication channel. In one implementation, the secure element <b>130</b> and the radio element <b>120</b> communicate using signals described in the Java Card 2.1 Platform API Specification.

0024In one implementation, both the radio element <b>120</b> and the secure element <b>130</b> are disposed internally within a body of the mobile communication device <b>110</b>. For example, referring to <figref idref="DRAWINGS">FIG. 3</figref>, the mobile communication device <b>110</b> is shown including a slot <b>400</b>, which allows for the insertion of a secure element <b>130</b> into the slot <b>400</b>. In this configuration, the secure element <b>130</b> can be purchased independently of the mobile communication device <b>110</b>. The secure element <b>130</b> can also be disposed into a slot that only provides for physical insertion and mechanical connection to the body of the mobile communication device <b>110</b>. In such an implementation, the secure element can include a transceiver that allows for the communication with the radio element <b>130</b> through a wireless local communication channel. The radio element <b>120</b> also is illustrated as optionally including another transceiver <b>129</b>, 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 <b>123</b>. 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.

0025<figref idref="DRAWINGS">FIG. 4A</figref> illustrates one implementation of the secure element <b>130</b> associated with the mobile communication device <b>110</b>. The secure element <b>130</b> can be a smart card. In one implementation, the secure element <b>130</b> includes a secure processor <b>132</b>, a secure memory <b>133</b>, and a POS transceiver <b>134</b> adapted to send transaction request signals and receive transaction response signals over a first communication channel. In one implementation, the secure processor <b>132</b> communicates via the secure element driver <b>128</b> with the radio processor <b>123</b> 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 <b>134</b> is an NFC device, which uses an NFC modem. The POS transceiver <b>134</b> 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 <b>132</b>. 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 <b>123</b> within the secure element <b>130</b> and the RFID reader that is associated with the POS terminal <b>150</b>. This communication is specified, for example, in the ISO 14443A/B standard. The secure element can optionally include a radio/Bluetooth/WIFI transceiver <b>136</b>, which can communicate with other devices, such as a transceiver associated with the radio processor <b>120</b> or for other external devices having those communication capabilities, thus allowing for more flexibility.

0026<figref idref="DRAWINGS">FIG. 4B</figref> shows another implementation of a secure element <b>130</b>, in which the radio element <b>120</b> does not communicate with the secure element <b>130</b> through a secure element driver <b>128</b>. In this case, for example, the secure element <b>130</b> may be external to the mobile communication device <b>110</b> and as such is not connected to the radio element through the secure element driver <b>128</b>. In such an implementation, however, if the transceiver <b>136</b> as described above is included, and a similar transceiver <b>129</b> associated with the radio element <b>130</b> as described previously with respect to <figref idref="DRAWINGS">FIG. 2</figref> is included, then this communication channel can be used to wirelessly obtain direct communications between the radio element <b>120</b> and the secure element <b>130</b>. This implementation allows for certain bidirectional communications with other devices, as well as with the radio element <b>120</b>, 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 <b>120</b>, since there is not communications with the radio element <b>120</b> via the path of driver <b>128</b>.

0027This implementation allows for certain bidirectional communications with other devices, as well as with the radio element <b>120</b>, 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 <b>120</b>, since there are no communications with the radio element <b>120</b> via the path of driver <b>128</b>. If either of the transceivers <b>129</b> or <b>136</b> are not associated with the respective radio element <b>120</b> or secure element <b>130</b>, and there is no direct connection between the radio element <b>120</b> and the secure element <b>130</b>, then a direct communication link between the radio element <b>120</b> an the secure element <b>130</b> will not exist. As such, while ticketing and many transactions can still exist, data from a real-time transaction performed using the secure element <b>130</b> 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).

0028<figref idref="DRAWINGS">FIG. 7</figref> illustrates one implementation of a secure element <b>130</b> that can be attached (or affixed) externally to a wireless communication device (e.g., mobile communication device <b>110</b>). In one implementation, the secure element <b>130</b> has circular shape. The secure element <b>130</b> can have other suitable shapes—e.g., rectangular, triangular, and so on. In one implementation, the secure element <b>130</b> includes an embedded smart chip <b>702</b> that is capable of executing proximity services (e.g., services related to payments, ticketing, identification, sending coupons, etc.). In one implementation, the smart chip <b>702</b> 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 <b>702</b> 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 <b>130</b> 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.

0029In 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 <b>130</b> is affixed. Thus, in one implementation, the secure element <b>130</b> includes an RF shield to insulate the smart chip from external interference. In one implementation, a lining of the secure element <b>130</b> 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 <b>130</b> and the mobile communication device <b>110</b>.

0030Given 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 <b>704</b> that encases a smart chip (with antennae). In one implementation, the shell <b>704</b> is formed from a composite plastic or polymer. The shell <b>70</b> can be hard (and substantially inflexible) or be soft (and pliable). In one implementation, the shell <b>704</b> 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 <b>130</b> to a mobile communication device include, for example, paper glue, super glue, polymers, and the like. In one implementation, the shell <b>704</b> has a maximum width (or diameter) of 25 mm, and has a maximum thickness (or depth) of 5 mm.

0031<figref idref="DRAWINGS">FIG. 4C</figref> shows another implementation of a secure element <b>130</b>, in which the secure element <b>130</b> does not include a processor that is capable of bidirectional communications, but instead includes a passive device <b>138</b>. The passive device <b>138</b> 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 <b>138</b> will cause the management server <b>180</b> to perform transaction details. In this implementation, the code received from the POS terminal <b>150</b> (or the POE terminal <b>190</b>) is transmitted from the POS terminal <b>150</b> (or the POE terminal <b>190</b>) to the management server <b>190</b>, which then takes over the transaction. This passive device <b>138</b>, with the identification code stored thereon, can thus be associated with a mobile communication device <b>110</b> not otherwise equipped for such communications, and the management server <b>190</b> can provide transactional information to the mobile communication device <b>110</b> 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 <b>190</b> is involved.

0000SMS (Short Messaging Service) As A Data Transmission Method

0032As discussed above SMS (Short Message Service) can be used as a data transmission method between the management server <b>190</b> and the mobile communication device <b>110</b>. 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. <figref idref="DRAWINGS">FIG. 8</figref> illustrates a communication system <b>800</b> in accordance with one implementation. The communication system <b>800</b> includes a mobile communication device <b>802</b> that communicates with a remote server <b>804</b> (e.g., a transaction server) via SMS. The mobile communication device <b>802</b> includes a mobile application <b>806</b> that receives SMS messages from the remote server <b>804</b> 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 <b>806</b> can be, for example, a J2ME, BREW, Windows Mobile, or other type of application.

0033In one implementation, the mobile application <b>806</b> 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 <b>804</b>). The mobile application <b>806</b> can also be a thin client application or hybrid client application. In one implementation, the mobile application <b>806</b> is the Blaze Mobile Wallet Lite application available from Mobile Candy Dish Inc. or Berkeley, Calif. In one implementation, the mobile application <b>806</b> provides banking and money management transaction services, and transmits data from the wireless communication device <b>802</b> via SMS in accordance with a connectionless protocol.

0034<figref idref="DRAWINGS">FIG. 9</figref> illustrates a communication system <b>900</b> in accordance with one implementation. The communication system <b>900</b> includes a mobile communication device <b>902</b>, a management server <b>904</b>, a user/profile database <b>906</b>, and a money management database <b>908</b>. In one implementation, the management server <b>904</b> is a Blaze server. In one implementation, the mobile communication device <b>902</b> stores a mobile application <b>910</b> that uses short message service (SMS) over a connectionless protocol to transmit data to the management server <b>904</b>. SMS permits the mobile application <b>910</b> to send messages of a fixed size, for example, up to 160 characters, to and from the wireless mobile communication device <b>902</b>. In one implementation, the management server <b>904</b> includes an SMS aggregator <b>912</b> to aggregate each message received from the wireless mobile communication device <b>902</b> 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 <b>910</b> also includes an SMS aggregator (not shown).

0035Thus, in one implementation, the mobile application <b>910</b> is not browser HTTP based, and delivers banking and money management services. The mobile application <b>910</b> 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.

0036In one implementation, the mobile application <b>910</b> provides banking and money management service, which includes (but is not limited to): <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0037">Registration: User creates new MW Lite account with PIN (PIN and user info can be stored in user/profile database <b>306</b>)</li><li id="ul0002-0002" num="0038">Security &amp; 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.</li><li id="ul0002-0003" num="0039">Install &amp; Configuration (I&amp;C): Refers to setting up proxies to <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0040">payment accounts (virtual, credit, debit &amp; banking)</li><li id="ul0003-0002" num="0041">Payees (BillPay, PayAnyone, etc.) and associated rules</li><li id="ul0003-0003" num="0042">Specify default payment account to debit fund transfers/unloading</li><li id="ul0003-0004" num="0043">Specify default payment account to credit fund transfers/loading</li><li id="ul0003-0005" num="0044">Activation of 3rdParty Services (Account Balance, Bill Pay, Fund Transfer, Funds Loading, Funds Unloading)</li><li id="ul0003-0006" num="0045">It is assumed Client application is pre-installed or downloaded to mobile device.</li><li id="ul0003-0007" num="0046">I&amp;C to be performed via Kiosk, ATM, 3rdParty/Carrier Web Portal, MCD Web Portal, on mobile device, or other suitable device.</li></ul></li><li id="ul0002-0004" num="0047">Loading Funds</li><li id="ul0002-0005" num="0048">Banking or financial data <ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0049">Account balance</li><li id="ul0004-0002" num="0050">Transaction history</li><li id="ul0004-0003" num="0051">Bill Pay—Biller Direct</li><li id="ul0004-0004" num="0052">Fund Transfer—Intra Bank; Me-2-Me</li><li id="ul0004-0005" num="0053">Fund Transfer—Inter Bank; Me-2-Me</li><li id="ul0004-0006" num="0054">Fund Transfer—Inter Bank; Me-2-You (based on Bank Routing/Account #)</li><li id="ul0004-0007" num="0055">Fund Transfer—Inter Bank; Me-2-You (based on WalletID)</li><li id="ul0004-0008" num="0056">Fund Transfer—Inter Bank; Me-2-You (based on ACH Check). A.k.a. Bill Pay Anyone</li><li id="ul0004-0009" num="0057">Load Fund</li></ul></li><li id="ul0002-0006" num="0058">Unload Funds (ATM Withdrawal, etc.)</li><li id="ul0002-0007" num="0059">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. <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0060">This info will be cached on Client.</li><li id="ul0005-0002" num="0061">Users can create transaction either in ONLINE or OFFLINE (no network connectivity) mode</li></ul></li><li id="ul0002-0008" num="0062">Initiating/Triggering Banking Services:</li><li id="ul0002-0009" num="0063">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.) <br /> Scenarios/Features </li></ul></li></ul>

00641. Overlaying connection protocol properties over SMS. This includes: segmenting complex command and control (C&amp;C) messages into 1 or more SMS messages, and re-constructing one or more SMS messages into complex C&amp;C resultset messages. Re-constructing the one or more messages into complex C&amp;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.

00652. User uses the mobile application <b>910</b> to initiate/trigger appropriate banking service. For example, referring to <figref idref="DRAWINGS">FIG. 10A</figref> a user can initiate a bill paying service through which a payee (e.g., PG&amp;E) can be paid. In one implementation, the display of the bill pay screen can include an advertisement as shown in <figref idref="DRAWINGS">FIG. 10A</figref>.

00663. The mobile application <b>910</b> formulates appropriate banking services commands, for example: <ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0000"><ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0067">“<command><PaymentAccount> <Payee> <$amt> <transferDate> <PIN> <sequenceID> <message> <messages>” <ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0068">billpay MCC-2345 PG&E 110.23 20070328 1234 36 1 1</li><li id="ul0008-0002" num="0069">transfer bofa-1007 jdoe 25.00 20070328 1234 36 1 1 #where jdoe is a walletID</li><li id="ul0008-0003" num="0070">transfer bofa-1007 8005550001 25.00 20070328 1234 36 1 1 #where 8005550001 is the phoneNumber of unloading station.</li><li id="ul0008-0004" num="0071">fundstransfer bofa-1007 gwbush 30.00 20070328 1234 36 1 1 #gwbush is a payee</li></ul></li><li id="ul0007-0002" num="0072">“<command> <PaymentAccount> <PIN> <sequenceID> <message> <messages>” <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0073">Balance bofa-1007 1234 36 1 1</li></ul></li></ul></li></ul>

00744. A Loading Station (Kiosk, etc.) can load funds by sending command to MCD's Loading Shortcode. <ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0000"><ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0075">“<command> <PaymentAccount> <Payee> <$amt> <transferDate> <PIN> <sequenceID> <message> <messages>” <ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0076">load CorpBankPayrollAccount-2007 8005550001 4000.00 20070328 0987 43 1 1 (#Debit account CorpBankPayrollAccount-2007 by $4000 and credit account held by user with phone Number 8005550001)</li></ul></li></ul></li></ul>

00775. Receive multiple (in/out sequence, missing, lost, etc.) messages to reconstruct a complex messages. <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0078"><sequenceID>:<message>:<messages>; <body> <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0079">“36:1:6; acct:Bofa-1007 bal:40123.32 date:20071009”</li><li id="ul0015-0002" num="0080">“36:3:6; date:20071009 name:Merchant2 amt:123.81”</li><li id="ul0015-0003" num="0081">“36:6:6; date:20071009 name:Merchant5 amt:423.81”</li><li id="ul0015-0004" num="0082">“36:4:6; date:20071009 name:Merchant3 amt:223.81”</li><li id="ul0015-0005" num="0083">“36:2:6; date:20071009 name:Merchant1 amt:23.81”</li><li id="ul0015-0006" num="0084">“36:5:6; date:20071009 name:Merchant4 amt:323.81”</li></ul></li></ul></li></ul>

0085In one implementation, post processing of these multiple messages results in the screen shown in <figref idref="DRAWINGS">FIG. 10B</figref> which displays the account balance and the last five transactions in a transaction history list. The list can be cached on the mobile communication device <b>902</b> for later use.

00866. Cashed data is refreshed upon user request. This in turn invokes a command similar to the following: <ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0000"><ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0087"><command> <account> <PIN> <sequenceID> <message> <messages> <ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0088">Balance Bofa-1007 1234 37 1 1 (#Where 37 is the next <sequenceID>) <br /> Connection Protocol Properties </li></ul></li></ul></li></ul>

0089The above description introduced the concept on <sequenceID> <message> <messages>. The sequenceID is a rotating pool per Client, issued by the Client, used as a callback mechanism, i.e., match outgoing command messages and incoming resultset messages. Since resultsets can be long and complex, the resultset is broken into pages, where each page can fit with the allowed payload size of an SMS message. Hence, “<message> <messages>” implies “Page 1 of 5”. The Client (or mobile application) then has to wait for all <messages> to arrive before re-constructing the original resultset. Due to characteristics of SMS, the client has to handle scenarios when a message with an un-expected sequenceID arrives. In addition, if a missing page within the expected sequenceID fails to arrive within a specified time interval, the client needs to request retransmission, e.g., “retransmit 36:4:6 1234” which will instruct server to retransmit resultset 36, part 4 of 6.

0090The pool size (or range of valid sequenceID's) controls the asynchronous aspect of the application. The sequenceID is mapped to the command (at least until the sequenceID is re-used). Hence, the client will use the sequenceID to determine to command and associate the appropriate display style sheet to best display the resultset to the user. For example, if sequenceID=36 was issued by the command ‘balance’ which determines account balance, it makes sense to leverage the ‘Account Balance &amp; History’ style sheet to present this information.

0091SMS messages to and from the mobile communication device has to be acknowledged. A simple protocol is necessary, for example, as follows: <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0000"><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0092">1. #Mobile Originated (MO) command <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0093"><command> <body> <sequenceID> <message> <messages> balance Bofa-1007 1234 37 1 1</li></ul></li><li id="ul0020-0002" num="0094">2. #Server, a.k.a., Mobile Terminating (MT) receives and acknowledges receipt of message “37 part 1 of 1.” <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0095">ack 37 1 1</li></ul></li><li id="ul0020-0003" num="0096">3. #MT responds with resultset <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0097">36:1:2; acct:Bofa-1007 bal:40123.32 date:20071009</li></ul></li><li id="ul0020-0004" num="0098">4. #MO receives and acknowledges receipt of message “36 part 1 of 2.” <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0099">ack 37 1 2</li></ul></li><li id="ul0020-0005" num="0100">5. #MT responds with resultset (part 2 of 2) <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0101">“36:2:2; date:20071009 name:Merchant1 amt:23.81”</li></ul></li><li id="ul0020-0006" num="0102">6. #MO receives and acknowledges receipt of message “36 part 2 of 2.” <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0103">ack 37 2 2</li></ul></li><li id="ul0020-0007" num="0104">7. #MO has received all messages. Reconstruct & store message</li><li id="ul0020-0008" num="0105">8. #Next time user view account balance, display cached (local store) information: <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0106">Bank Account: Bofa-1007</li><li id="ul0027-0002" num="0107">Balance: $40,123.32 as of 10/9/2007</li><li id="ul0027-0003" num="0108">10/9/2007 Merchant1 $23.81 <br /> Online/Offline Access </li></ul></li></ul></li></ul>

0109In one implementation, a mobile communication device creates task/objects either while connected with a Server (online-mode) or when no connection is available (offline-mode). Tasks/objects are specific to mobile banking service and include for example: schedule (or cancel) a fund transfer transaction, schedule (or cancel) a bill pay transaction, and manage other banking transactions. In addition, digital artifacts (coupons, tickets, etc.) that possess a state (or status) (e.g., Assigned, Saves, Redeemed, Deleted, etc.) can undergo changes on the mobile communication device. Given these tasks/objects associated to Banking Services and Digital Artifacts has ‘states’ that can be changed in either an online-mode or offline-mode, the Server has to be refreshed/updated either in real-time (online-mode) or in batch (offline-mode).

0110For example, given a situation in which a user is travelling in a region in which the user's mobile communication device does not have network access and the user needs to transfer funds into a checking account, the user can use the mobile communication device (with the Mobile Wallet Client application) to schedules a fund transfer in offline mode. Since the mobile communication device has no network connectivity, the Client (in OFFLINE mode) creates a ‘task’ to represent the fund transfer (or any other banking service) using banking information (Banks accounts, etc.) previously cached on mobile device. The task can have an initial state (e.g., “pending”). While the Client is enabled the Client will actively monitor network access. When the user travels into a region where network access is available, the client will identify the network and automatically re-connect to the network. The client will then negotiate with a server and any tasks having a “pending” state on the client are then uploaded to server (either in batch mode or one task at a time). The client (in ONLINE mode) will refresh states of all task from the server (including the recently added tasks) to present to the user the updated status of all tasks managed by the server. Other services possible include, for example: request schedule (or cancellation) of Bill Pay transaction, request schedule (or cancellation) of Fund Transfer transaction, request schedule (or cancellation) of Pay Anyone transaction, any other state-based banking transaction service.

0111Using the client (or mobile application), a user can store digital artifacts (e.g., coupons, tickets, etc.) on a mobile communication device. These digital artifacts are objects that are consumed by a 3rdParty, e.g., a ticket can be redeemed at a theater, and a coupon can be redeemed at the Point-Of-Sale of a retail merchant. Hence, this is a 3-way sync: 1) mobile communication device with server, 2. mobile communication device with 3rdParty Merchant, and 3) server with 3rdParty Merchant. For user's convenience, redemption of digital artifacts by a 3rdParty must be enabled in an environment with or without network access. For example, a user with an electronic ticket on a mobile communication device may wish to redeem an eTicket at a theater. However, if there is no network access inside the theater, the user will still need access the eTicket on the client. In ONLINE mode, the client will cache (local store) the eTicket (and any other digital artifact.) In the theater, the client (in OFFLINE mode) will be able to redeem the eTicket and update the state of the eTicket on the mobile communication device (e.g., change state from ‘valid’ to ‘redeemed’). This prevents the user from re-using the eTicket. At some point when the mobile communication device re-acquires network connectivity, the client will then negotiate with the server and any artifacts with a state change (e.g., ‘valid’ to ‘redeemed’, etc.) on the client are then uploaded to the server (e.g., either in batch mode or one task at a time).

0112The client (in ONLINE mode) will manage and refresh states of all artifacts from the server (including the recently added tasks) to present to the user. In one implementation, the server is the master repository. In the process of redeeming the eTicket, the eTicket is uploaded to the merchant (via secondary out-of-band communication link, e.g., RFID/NFC, Bluetooth, etc.). This is necessary for theater to update their inventory systems. The 3rdParty may liaise (via an internet connection) with the server to validate eTicket and authenticate the user.

0000POS (Point of Sale) Terminal

0113The point of sale terminal <b>150</b> illustrated in <figref idref="DRAWINGS">FIG. 5</figref> is conventional, in that it has the capability of electronically reading information from a device equipped to transmit information in a format that it reads. Thus, the reader <b>152</b> within the point of sale terminal <b>150</b> can be of one or many types. If the point of sale terminal reader <b>152</b> includes the provision for NFC communications, then simply bringing the secure element <b>130</b> with the NFC transceiver will cause initiation of a transaction and the transmission of the identification code associated with the secure element <b>130</b> and thus the user.

0114In one implementation, various software that is downloaded into the memory <b>126</b> of the radio element <b>120</b> and the secure memory <b>132</b> of the secure element <b>130</b>, along with software resident on the management server <b>180</b>, cooperate at a layer that is above the physical layer of the communications, in order for the desired transaction to occur. This software is implemented using based upon known knowledge of mobile communication device <b>110</b> internals and application platforms, NFC, smartcard internals and application platforms, payment protocols (e.g. PayPass), and the working/workflow associated with POS and POE terminals, and the transaction and management servers. In addition, the present invention provides for piggybacking a tunneling protocol on top of the payment protocol, so that the secure elements <b>130</b> can communicate with the transaction server <b>170</b> and/or the management server <b>180</b>, without modification to the POS terminal <b>150</b> or the POE terminal <b>190</b>. As such, this includes software within the secure element <b>130</b> that embeds the required information in fields which will not adversely affect the performance of the POS terminal <b>150</b> and/or the POE terminal <b>190</b>, and also software in transaction server <b>170</b> that will extract the piggybacked payload, associate the payload with the management server <b>180</b> if needed, and then authenticate, authorize, and execute transfers of transaction information to the management server <b>180</b>. In one implementation, the piggybacked payload is sent, instead of to the transaction server <b>170</b>, to the management server <b>180</b>, which can then associate the transaction and notify the transaction server <b>170</b>, the POS terminal <b>150</b> and/or the POE terminal as needed.

0115In one implementation, the management server <b>180</b> has the capability of storing codes that are from a variety of different mobile communication devices. Thus, codes that are associated with a smart card having an RFID can be stored, as can be codes stored from an RFID sticker, as well as codes that are associated with a smart card that communicates using a slide reader, Bluetooth, or an NFC channel, for example. As such, the management server <b>180</b> can store user personal and credit and transactional information and history, including a code associated with the user, for a variety of different mobile communication devices, thereby allowing a system which can scale.

0116<figref idref="DRAWINGS">FIGS. 6A-6D</figref> illustrate a flowchart of a transaction in accordance with one implementation, and the various steps that are included in the transaction, with reference to which of the various devices are implementing this step. Referring to <figref idref="DRAWINGS">FIG. 6A</figref>, a user first waves a mobile communication device <b>530</b> (e.g., a NFC device or device having an attached sticker) across (or near) a POS terminal <b>540</b>. The POS terminal <b>540</b> identifies the technology associated with the mobile communication device, a payment method, user credentials, and payment credentials. Irrespective if t mobile communication device is a NFC-Phone or includes an attached sticker, the mobile communication device sends to the POS Terminal <b>540</b> payment credentials including optional credentials (e.g., WalletID). As shown in <figref idref="DRAWINGS">FIG. 6B</figref>, using optional credentials (e.g., WalletID), contact is made with a transaction server <b>510</b> to request payment credentials. The POS terminal <b>540</b> determines if a security code prompt (e.g., a PIN) is needed? If yes, a prompt is made for the security code (PIN) on the POS terminal <b>540</b> and the process continues with processing of the payment. Otherwise, the POS terminal <b>540</b> simply proceeds with processing of the payment. As an alternative, the POS terminal <b>540</b> can integrate via the back office to a management server <b>510</b> and trigger a PIN prompt on the mobile communication device. In such a case, the user can enter the PIN on the mobile communication device (instead of through the POS terminal <b>540</b>). The POS terminal <b>540</b> hands processing to a payment broker.

0117Referring to <figref idref="DRAWINGS">FIG. 6C</figref>, assuming the POS terminal <b>540</b> was capable of 2-way communication, if the POS terminal <b>540</b> determines that the mobile communication device is a NFC Phone, the POS terminal <b>540</b> can write digital artifacts (e.g, eReceipts, eTickets, eCoupons, etc.) to the mobile communication device. Non-secure data is stored in the mobile communication device. Otherwise, the POS terminal <b>540</b> sends optional digital artifacts to the management server <b>510</b>. As part of an out-of-band sync between the management server <b>510</b> and the mobile communication device, the non-secure digital artifacts are downloaded and stored in the mobile communication device. Secure digital artifacts are downloaded to the mobile communication device and stored on a secure element of the mobile communication device (if possible).

0118In <figref idref="DRAWINGS">FIG. 6D</figref>, upon successful payment processing and assuming the POS terminal <b>540</b> was capable of 2-way communication, if the POS terminal <b>540</b> determines that the mobile communication device is not an NFC Phone, the POS terminal <b>540</b> triggers the management server <b>510</b> of payment processing completion. Note, this can be time delayed due to a difference when a payment is posted and cleared. The management server <b>510</b> can send a notification to the mobile communication device (via SMS, etc.). Since the mobile communication device could be shutdown, the notification will wake-up the mobile application running on the mobile communication device, and initiate SYNC operations between the management server <b>510</b> and the mobile application (or client). Any pending digital artifacts (including notifications, etc.) are displayed on the mobile communication device.

0119The present invention, as described previously, allows for various different programs to exist within the memory <b>126</b> of the radio element <b>120</b>, as well as in the secure memory <b>132</b> of the secure element <b>130</b>.

0000Mobile Tickets (eTickets)

0120In one implementation, a mobile ticket (also referred to herein as “electronic ticket” or “eTicket”) includes both a unique code that is sent to the consumer's cell phone and a database that allows for the validation of the consumer using their cell phone number and the unique code. The mobile ticket can be used at kiosks in addition to interfacing with a ticket agent. The mobile ticket may be used with or without cell phones equipped with radio technology (i.e., RFID or NFC). In operation, a mobile ticket works when the user is sent a unique code (alpha-numeric, numeric, etc.) to their cell phone. The user is validated as a customer by their cell phone number and their code. If these match the information stored in a central database, the user is allowed admission into a venue by either manual validation by a ticket agent or automatically using RFID or NFC technology.

0121In general, an electronic ticket can be delivered to a mobile device and allow a consumer admission into a sports venue, entertainment venue (e.g. concert or movies), or other point of sale location either manually if the consumer displays the electronic ticket to an agent who may issue a paper ticket to the consumer or automatically if the consumer waves their cell phone (if equipped with a radio transmitter) over a POS device which contains a radio receiver. In one implementation, an electronic ticket (or tickets) is selected by viewing an image of the venue seating map. The seating map can be rendered on the mobile device. Users can zoom in/out of the seating map. As User zooms in, additional layers (details, info, etc.) is presented. For example, a user can view Venue→Quadrant→Level→Section→Row. The ability to zoom in/out and present additional levels of details can be processed either on the mobile device (Client) or on the Content Server, the end result is an updated image rendered on the mobile device. In one implementation, seats are color coded to represent availability and price. In this manner, seat inventory (what's available and at what price) can be illustrated graphically. Once user has navigated to lowest level, the image is granular enough to select individual seats. In one implementation, a seat selection will automatically cause a price to be calculated. Any service fee can be included in the ticket price. Once user confirms purchase, reservation request is sent to ticket inventory system. If reservation is successful, a valid electronic ticket is returned to the mobile device.

0122The present invention can also be interfaced with certain known and implanted payment protocols, such as Paypass. For implementing these additional payment protocols, implementation of streaming communication protocols (in the full NFC case), protocols for session setup, and configuration of communications modules and secure data areas as needed is necessary, taking into account the communication protocol used (e.g. NFC, Bluetooth, WIFI, CDMA, 3.sup.rd Generation CDMA for example) as well as file transfer protocols and facilities access protocols. In particular, in implementing such protocols, the ability to extract transaction information from the POS terminal <b>150</b> to the secure element <b>130</b> can be provided during the course of the local interaction between the POS terminal <b>150</b> and the secure element <b>130</b>. For instance, the implementation of PayPass within the invention will take note, and alert the application running on the radio processor <b>123</b> that a purchase or purchase attempt has occurred, as noted above in the context of the alert discussion. In one implementation, a feature is provided that permits information passed via the PayPass protocol to the POS terminal <b>150</b> (and thence to the transaction server <b>170</b>) to be augmented with additional fields containing the elements of the tunneling protocol, for subsequent processing by the transaction server <b>170</b>, either directly, or through the management server <b>180</b>.

0123The two transaction workflows that have been specifically discussed above are the credit card and ticketing workflows. Other transaction flows can also be implemented. Debit card and cash card transactions are similar to credit card transactions, with variations being implemented to account for the differences that exist in those types of transactions, which types of transactions are well understood. Coupons can be implemented with the invention, in much the same manner as tickets, though coupons can be transmitted without there being payment. Many of the transaction types noted herein will, as is apparent, require communication between the secure element <b>130</b> and the radio element <b>120</b>. As such, due to that requirement, a significant part of the preceding discussion has been directed to how to implement that communication, particularly for mobile communication devices <b>110</b> that are not manufactured to allow for such communications.

0124An example of a typical transaction requiring such communication between the secure element <b>130</b> and the radio element <b>120</b> is one in which the POS terminal <b>150</b> allows for the transfer of detailed purchase information from the POS terminal <b>150</b> to the secure element <b>130</b>, as well as transactional information from the POS terminal <b>150</b> and/or the transaction server <b>170</b> to the management server <b>180</b>. The management server <b>180</b> can then also communicate with the radio element <b>120</b> via the radio channel. This allows for the matching and reconciliation of detailed purchase information and, if the transaction fails, failure details can be matched to the purchase information, and forwarded in real-time to the user via the radio element <b>120</b>. In one implementation, there is included the provision for different phones to communicate the results of a transaction, particularly using the POS transceiver or one of the Bluetooth/Wifi transceivers. In this implementation, after a transaction has been completed with one of the mobile communication devices <b>110</b><i>a</i>, another mobile communication device <b>110</b><i>b </i>can receive information regarding the transaction completed. Thus, for instance, if mobile communication device <b>110</b><i>a </i>purchases two tickets, one of the tickets can be transmitted to the mobile communication device <b>110</b><i>b </i>by each using a POS transceiver or one of the Bluetooth/Wifi transceivers.

0125Although the present invention has been particularly described with reference to implementations discussed above, various changes, modifications and substitutes are can be made. Accordingly, it will be appreciated that in numerous instances some features of the invention can be employed without a corresponding use of other features. Further, variations can be made in the number and arrangement of components illustrated in the figures discussed above.