Automated confirmation of transit card fund replenishment

An electronic transit fare payment system is disclosed. The system comprises a plurality of mobile devices adapted to store a transit fare payment application and a server in wireless communication with the mobile devices. The transit fare payment application decrements a transit fare funds balance by a fare amount after completing a transit ride, wirelessly requests a top-up of the transit funds balance when the transit funds balance drops below a threshold, wirelessly receives a top-up instruction, increments the transit fare funds balance in response to executing the top-up instruction, and wirelessly transmits a top-up confirmation. The server receives the request for the top-up, charges the top-up to a credit card associated with the mobile device requesting the top-up, transmits the top-up instruction to the mobile device requesting the top-up, receives the top-up confirmation. When the top-up confirmation is not received, the server requests top-up confirmation from the mobile device. When the mobile device does not reply to the request, the server analyzes a transit fare transaction history associated with the mobile device to determine that the top-up has completed. When the top-up is not confirmed, the server rolls-back the charge of the top-up to the credit card associated with the mobile device.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

A point-of-sale (POS) terminal may receive payment information from a contactless card. A contactless card communicates with a point-of-sale terminal or other device at least in part without physically contacting the point-of-sale terminal, for example through radio frequency communication conducted in the proximity of the point-of-sale terminal. This radio frequency communication may include near field communication (NFC) technology. Other contactless communication links may be established using optical signals and/or sonic signals. In one payment scenario, a commuter may present a transit card to pay a fare and obtain access to a transportation provider vehicle, for example a bus, a train, or a subway train. In another payment scenario, an electronic purse may be provided as an application on a portable electronic device, for example on a mobile phone, a personal digital assistant, or other device, a payment may be made from the electronic purse. In some designs, some financial information, for example fund balances, may be stored in a limited access portion of memory referred to as a secure element (SE).

SUMMARY

In an embodiment, a method of managing a transit card is provided. The method comprises wirelessly transmitting a command to replenish funds in the transit card. When a confirmation of replenishment of funds in the transit card is received, the method comprises recording the completion of the command to replenish funds in the transit card. When a confirmation of replenishment of funds in the transit card is not received before a confirmation time out period expires, the method comprises wirelessly transmitting a query about a funds replenishment status of the transit card and receiving a response to the query. When the response indicates the funds in the transit card are replenished, the method comprises recording the completion of the command to replenish funds in the transit card. When the response does not indicate the funds in the transit card are replenished, the method comprises analyzing a transaction history associated with the use of the transit card. When an inference that the funds in the transit card are replenished results from analyzing the transaction history, the method comprises recording the completion of the command to replenish funds in the electronic wallet. When an inference that the funds in the transit card are not replenished results from analyzing the transaction history, the method comprises reporting a transit card funds replenishment anomaly.

In an embodiment, a method of managing a balance of a transit card is provided. The method comprises wirelessly receiving a request to add funds to the transit card, requesting a charge in the amount of the funds to a credit card, and wirelessly transmitting an instruction to increment the balance of the transit card by the amount of the funds. When a confirmation that the balance of the transit card is incremented is not received, the method comprises wirelessly requesting a status of the transit card. When the status of the transit card does not confirm that the balance of the transit card is incremented, the method comprises analyzing a transaction history associated with the transit card. When the analyzing the transaction history cannot confirm that the balance of the transit card is incremented, the method comprises backing out the charge to the credit card in the amount of the funds. When the charge to the credit card cannot be backed out, the method comprises reporting an anomaly of the balance of the transit card.

In an embodiment, an electronic transit fare payment system is disclosed. The system comprises a plurality of mobile devices adapted to store a transit fare payment application and a server in wireless communication with the mobile devices. The transit fare payment application decrements a transit fare funds balance by a fare amount after completing a transit ride, wirelessly requests a top-up of the transit funds balance when the transit funds balance drops below a threshold, wirelessly receives a top-up instruction, increments the transit fare funds balance in response to executing the top-up instruction, and wirelessly transmits a top-up confirmation. The server receives the request for the top-up, charges the top-up to a credit card associated with the mobile device requesting the top-up, transmits the top-up instruction to the mobile device requesting the top-up, receives the top-up confirmation. When the top-up confirmation is not received, the server requests top-up confirmation from the mobile device. When the mobile device does not reply to the request, the server analyzes a transit fare transaction history associated with the mobile device to determine that the top-up has completed. When the top-up is not confirmed, the server rolls-back the charge of the top-up to the credit card associated with the mobile device.

DETAILED DESCRIPTION

A system and method of automated confirmation of replenishment of funds in a mobile electronic device, for example in an electronic purse application of the mobile device and/or a transit card application of the mobile device, is disclosed herein. In an embodiment, payment for use of the transportation services is advanced to a transportation provider payment system by charging a credit card associated with the mobile device, for example a credit card belonging to a user of the mobile device. The exchange of the payment for actual use of the transportation services is managed by allocating funds substantially equivalent to the payment to a funds balance of the transit card application on the mobile device and decrementing the funds balance of the transit card application as the mobile device is used to access the transportation system. For example, the user may present their mobile device to a fare gate to record an entry into the transportation system and again present their mobile device to a fare gate to calculate and deduct a fare from the funds balance of the transit card application on exit from the transportation system.

When the funds balance of the transit card application drops below an established threshold, the transit card application initiates a funds replenishment transaction. In an embodiment, the mobile device sends a replenishment request to the provisioning server via a wireless communication link between the mobile device and a base transceiver station (BTS) and via a wired communication link from the base transceiver station to the provisioning server. In response to the replenishment request, the provisioning server initiates the payment to the transportation provider payment system by charging the credit card associated with the mobile device. Upon initiating the credit card payment, the provisioning server sends an instruction to the mobile device—via the wired communication link to the base transceiver station and via the wireless communication link from the base transceiver station to the mobile device—to allocate appropriate funds to the funds balance of the transit card application. Under normal conditions, the instruction is received by the mobile device, the appropriate funds are allocated to the funds balance of the transit card application, the mobile device sends a replenishment confirmation to the provisioning server, and the provisioning server records the replenishment transaction as confirmed and/or completed.

Under some conditions, however, the provisioning server may not receive the expected replenishment confirmation. In one circumstance, the wireless communication link between the mobile device and the base transceiver station may be unavailable, for example the wireless link may go out of service after the mobile device requests the funds replenishment, and the instruction to allocate funds to the funds balance of the transit card application that is sent by the provisioning server is not received by the mobile device. In another circumstance, the mobile device may be turned off, for example because the power level of the mobile device drops below a threshold and the mobile device automatically turned off, and the instruction to allocate funds to the funds balance to the transit card application sent by the provisioning server is not received by the mobile device. In another circumstance, however, the instruction to allocate funds to the funds balance of the transit card application is received by the mobile device, the funds are allocated to the funds balance of the transit card application, but the replenishment confirmation cannot be sent by the mobile device, for example because the power level of the mobile device drops below a threshold and the mobile device automatically turns off. In another circumstance, the instruction to allocate funds to the funds balance of the transit card application is received by the mobile device, the funds are allocated to the funds balance of the transit card application, the replenishment confirmation is sent by the mobile device, but the wireless communication link between the mobile device and the base transceiver station is out of service. A variety of other operating scenarios may also interfere with the completion of the replenishment transaction.

One approach to addressing the alternative replenishment scenarios is to rely upon the user of the mobile device to determine that the replenishment transaction has not completed and to request an adjustment through a human operator associated with the transportation provider. This approach, however, may involve greater operational costs for the transportation provider, loss of time for the user of the mobile device, and loss of satisfaction with the transportation system. A system and a variety of methods of automated confirmation of funds replenishment that address some of the alternative replenishment scenarios and reduce the number of occasions that a user of the transportation system resorts to requesting operator adjustments are described herein. It is contemplated that the system and methods disclosed herein may be generally applicable beyond the transportation system payment system described in detail herein after and may also apply, for example, to replenishment procedures associated with an electronic purse application or other electronic payment applications that may reside on the mobile device.

In one embodiment, when no confirmation of replenishment of the funds in the transit card is received, the provisioning server sends a query to the mobile device. If the mobile device confirms replenishment, the provisioning server records the replenishment transaction as confirmed and/or completed. If the mobile device replies that no instruction to allocate funds was received, the provisioning server may retransmit the replenishment request. When the mobile device does not reply to the query, the provisioning server may periodically retransmit the query a limited number of times or for a limited duration of time. When the mobile device does not reply to the query within the limited number of retries or the limited duration of time, for example because the mobile device is out of wireless communications or is powered off, the provisioning server may try to infer the replenishment state of the transit card application on the mobile device from analyzing a transit card transaction history. For example, if a first transit card record indicates a first balance and the next transit card record indicates a second balance, where the second balance is greater than the first balance, the provisioning server may infer that the replenishment transaction completed. In the event that the provisioning server cannot draw an inference that the replenishment transaction completed, the provisioning server may generate and transmit a replenishment anomaly report to the transportation provider for investigation by an operator or other employee of the transportation provider. Alternatively, the provisioning server may attempt to back-out the transaction to increase timeliness and customer satisfaction, for example by backing out a credit card payment before the payment settles with the credit card issuer.

Turning now toFIG. 1, a system100for payment for transportation services with a transit card application on a mobile device is described. The system100comprises a plurality of mobile devices102(only one mobile device is shown) and a plurality of fare gates104(only two fare gates shown, an entry fare gate104aand an exit fare gate104b). The mobile device102may be presented to the entry fare gate104a, for example the mobile device102may tap the entry fare gate104a, and information may be exchanged between the mobile device102and the entry fare gate104ato gain entrance to the transportation system, for example a bus, a subway or train platform, or other. The mobile device102may be any of a variety of portable electronic devices including a mobile phone, a personal digital assistant, a media player, a digital camera, a laptop computer, a tablet computer, and others. In some embodiments, the entry fare gate104aand/or the exit fare gate104bmay function both as an entry and an exit fare gate. An exemplary embodiment of the mobile device102is described in detail hereinafter.

The exchange of information between the mobile device102and the entry fare gate104amay be carried over a contactless communication link, for example over a near field communication (NFC) link. In an embodiment, the mobile device102may comprise a near field communication transceiver106to promote near field communications with fare gates104and other devices. The user of the mobile device102may ride on the transportation vehicle to a destination point where the mobile device102may be presented to the exit fare gate104b, for example the mobile device102may tap the exit fare gate104b, and information may be exchanged between the mobile device102and the exit fare gate104bto calculate the fare for traveling to the destination point, to deduct the fare from a funds balance of a transit card application112contained in an electronic wallet110of the mobile device102, and to exit the transportation system.

The mobile device102also comprises a radio access network (RAN) transceiver118with which the mobile device102communicates over a wireless link with a base transceiver station (BTS)120. The base transceiver station120provides communications connectivity to a network122to the mobile device102through a wired communication link and/or a wireless communication link. The system100further comprises a provisioning server124, a credit card payment processor126, and a transportation provider payment system128that communicate via wired and/or wireless connections to the network122. The fare gates104, the provisioning server124, the credit card payment processor126, and the transportation provider payment system128may each be implemented as a general purpose computer system. General purpose computer systems are described in more detail hereinafter.

In an embodiment, the transit card application112may be downloaded to the mobile device102from the provisioning server124, for example when the user of the mobile device102requests or subscribes to the transportation provider payment system128. The provisioning server124may wirelessly transmit the transit card application112to the mobile device102, for example by sending the transit card application112over a wired link to the base transceiver station120via the network122and via a wireless link from the base transceiver station120to the mobile device102. The provisioning server124may wirelessly transmit the transit card application112to the mobile device102with a zero balance, that is with a funds balance of zero on the transit card application. When the funds balance of the transit card application112drops below a threshold, for example below a threshold of about ten dollars, the transit card application112initiates a replenishment transaction. In some contexts the threshold may be referred to as a predefined quantity. In some contexts herein, the replenishment transaction may also be referred to as a top-up. In a normal top-up, the mobile device102sends a replenishment request to the provisioning server124via the wireless link between the mobile device102and the base transceiver station120and via the wired link between the base transceiver station120, the network122, and the provisioning server124. The provisioning server124sends a credit card payment request to the credit card payment processor126via the network122. In an embodiment, the provisioning server124may comprise a credit card transactions component142to manage communications and/or interactions with the credit card payment processor126. The credit card payment processor126validates the request and, if the subject credit card account balance after the payment remains within any applicable credit limits and if any authentication information is verified, returns a charge approved response to the provisioning server124.

The credit card payment processor126provides a payment to the transportation provider payment system128via the network122. In an embodiment, the payment amount may be a predefined amount of money, for example about forty-five dollars. In other embodiments, a different predefined amount of money may be used. In yet other embodiments, the amount of payment is defined by the mobile device102in its replenishment request, and the credit card payment processor126provides payment in the amount to the transportation provider payment system128. In an embodiment, the completion of the credit card transaction and transfer of funds to the transportation provider payment system128remains pending until a periodic settlement time, for example an about hourly settlement time or an about daily settlement time.

After the provisioning server124has received the charge approved response from the credit card payment processor126, the provisioning server124sends an instruction to the mobile device102to allocate appropriate funds to the funds balance of the transit card application112. In an embodiment, the transit card application112may allocate funds equal to the payment amount that is to be made to the transportation provider payment system128, for example about forty-five dollars. In another embodiment, however, a different amount of funds may be allocated to the funds balance of the transit card application112. For example, in an embodiment, the transportation provider payment system128may provide an incentive for using the transit card application112by granting that for a payment of forty-five dollars an allocation of forty-eight dollars to the funds balance of the transit card application112is permitted. In another embodiment, a different incentive value may be provided.

When the mobile device102receives the instruction to allocate funds, the instruction is provided to the transit card application112. In an embodiment, the transit card application112may execute the instruction and increment the funds balance promptly. In another embodiment, however, the transit card application112may place the instruction in a secure element130of the transit card application112where the instruction will remain pending until a trigger event causes the instruction to be processed and the funds balance to be incremented by code or instructions inside the secure element130. In an embodiment, the trigger event that causes the instruction to be processed and the funds balance to be incremented may be tapping the exit fare gate104b. In another embodiment, however, a different trigger event may be employed. Making the execution of the instruction depend upon a triggering event associated with the transportation company and/or transit authority allows the transportation company to maintain tighter control and/or access to the sensitive portions of the secure element130.

After the mobile device102receives the instruction to allocate funds, the mobile device102transmits a replenishment confirmation to the provisioning server124. When the provisioning server124receives the replenishment confirmation, the provisioning server124may judge the top-up to be completed and/or confirmed. In an embodiment, the provisioning server124is in communication with a database144that comprises a top-up transaction table146. The top-up transaction table146includes records related to top-up transactions. Each record in the top-up transaction table146may identify the mobile device102and a top-up transaction state as one of tentative, confirmed, or other states. The provisioning server124may create a new record in the top-up transaction table146when the provisioning server124receives the charge approved response from the credit card payment processor126. After sending the instruction to allocate funds to the mobile device102, the provisioning server124may set the state of the associated record in the top-up transaction table146to tentative. After receiving the replenishment confirmation from the mobile device102, the provisioning server124may set the state of the associated record in the top-up transaction table146to confirmed.

It will be appreciated that a number of time lags and pending operations may occur in the system100. For example, while the transit card application112may have replenished its funds, the actual payment and/or transfer of funds to the transportation provider payment system128may not occur until later, for example until a later settlement time. Again, while the actual payment and/or transfer of funds to the transportation provider payment system128may have occurred and the settlement time passed, the funds balance of the transit card application112may not have been replenished, topped-up, or incremented, for example if the mobile device102has not tapped on the exit fare gate104bor if the mobile device102was powered down after the mobile device102transmitted the replenishment request but before receiving the instruction to allocate funds to the funds balance of the transit card application112.

In an embodiment, the provisioning server124may comprise a top-up event reconciliation component140that monitors the progress of top-up transactions and performs automated confirmation of top-up transactions. In another embodiment, a different portion and/or component of the provisioning server124may provide similar functionality. The top-up event reconciliation component140may analyze the top-up transaction table146on a periodic basis and take action to attempt to confirm top-up transactions that are associated with a record in the top-up transaction table146that has a tentative state. For example, the top-up event reconciliation component140may trigger the provisioning server124to send a query to the mobile device102to ask if the mobile device102has received the instruction to allocate funds. If the mobile device102replies that the instruction to allocate funds has been received, the top-up event reconciliation component140may set the associated record in the top-up transaction table146to confirmed. If the mobile device102replies that the instruction to allocate funds has not been received, the top-up event reconciliation component140may trigger the provisioning server124to resend the instruction to allocated funds to the mobile device102. In an embodiment, rather than setting the associated record in the top-up transaction table146to confirmed, the top-up event reconciliation component140may remove the associated record from the top-up transaction table146. If the mobile device102does not reply to the query, the top-up event reconciliation component140may periodically retransmit the query to the mobile device102, either for a predefined number of attempts or for a predefined duration of time.

If the top-up event reconciliation component140does not receive a reply from the mobile device102after exhausting the predefined number of attempts or the predefined duration of time, the top-up event reconciliation component140may attempt to infer the top-up state of the transit card application112of the mobile device102from an analysis of fare transactions between the mobile device102and the fare gates104. In an embodiment, the provisioning server124may have access to a record of fare transactions completed using the transit card application112of the mobile devices102. In an embodiment, the transportation provider may push a selection of fare transactions to the provisioning server124in a batch mode on a periodic basis, for example about hourly or about daily. Alternatively, the provisioning server124may request selected fare transactions from the transportation provider when needed, for example to confirm top-up transaction states. The fare transactions may be stored in the database144as records in a fare transaction history table148.

The top-up event reconciliation component140may analyze the fare transaction history table148to infer the top-up state of the mobile device102. For example, if the top-up event reconciliation component140finds a first fare transaction record associated with the mobile device102having a first funds balance of the transit card application112and a second fare transaction record associated with the mobile device102having a funds balance greater than the first funds balance, if the second fare transaction record has a timestamp later than a timestamp associated with the provisioning server124sending the instruction to allocate funds to the transit card application112of the mobile device102, the top-up event reconciliation component140may infer that the top-up transaction completed. In an embodiment, the top-up event reconciliation component140may further condition the inference that the top-up transaction completed on the determination that the second fare transaction record is the next fare transaction of the transit card application112of the mobile device102in sequence after the first fare transaction.

The top-up event reconciliation component140may draw the negative inference that the top-up transaction did not complete if a contiguous time ordered sequence of fare transactions show an always decreasing fund balance of the transit card application112of the mobile device102and the contiguous time ordered sequence of fare transactions begins before the timestamp of the instruction to allocate funds to the transit card application112and extends after the timestamp of the instruction to allocate funds to the transit card application112. If the negative inference is drawn, the top-up event reconciliation component140may trigger the provisioning server124to resend the instruction to allocate funds to the mobile device102.

When the top-up event reconciliation component140cannot draw any inference from analyzing the fare transaction history table148, for example when no records in the fare transaction history table148associated with the mobile device102bear a timestamp later than the timestamp of the instruction to allocate funds to the transit card application112, the top-up event reconciliation component140may periodically retry the analysis at a later time. After a predefined number of retries or after a predefined duration of time, however, the top-up event reconciliation component140may discontinue attempts to infer the state of the top-up transaction. When the top-up event reconciliation component140discontinues attempts to infer the state of the top-up transaction, the top-up reconciliation component may transmit a report or other notice to an operator or other member of the transportation provider to promote human intervention and resolution of the unconfirmed top-up transaction. While in this case human and/or manual intervention is employed, it is anticipated that many, even a majority, of the various top-up scenarios that would otherwise have been deferred to operator resolution may be automatically resolved by the disclosed system and methods.

Turning now toFIG. 2, a method200of automated confirmation of replenishment is discussed. In block204, a command to replenish funds in a transit card is wirelessly transmitted. This command may be sent by the provisioning server124to the mobile device102via a wired link from the provisioning server124to the base transceiver station120via the network122and via a wireless link from the base transceiver station120to the mobile device102. This command may also be referred to as an instruction to allocate funds. In some scenarios, this may lead to the transit card application112on the mobile device102incrementing the funds balance by substantially the amount paid with a credit card associated with the mobile device102to the transportation provider payment system128.

In block208, if the replenishment is confirmed, for example if the mobile device102sends a replenishment confirmation to the provisioning server124, the method200proceeds to block212where the completion of the replenishment of funds action is recorded. This may also be referred to as the completion of a top-up transaction. In block208, if the replenishment is not confirmed, for example if no replenishment confirmation is received by the provisioning server124before a timeout period expires, the method200proceeds to block216. In block216, a query about the replenishment status or top-up status of the transit card application112is wirelessly transmitted. In an embodiment, the query may be sent by the provisioning server124to the mobile device102, via a wired link, from the provisioning server124to the base transceiver station120via the network122, and via a wireless link from the base transceiver station120to the mobile device102.

In block220, if the replenishment is confirmed, for example if the mobile device102sends a query response that indicates the top-up transaction has completed and/or the instruction to allocate funds to the funds balance of the transit card application112has been received, the method200proceeds to block212where the completion of the replenishment of funds is recorded. If the mobile device102sends a query response that indicates that no replenishment instruction or replenishment command has been received by the mobile device102, the provisioning server124may resume the process at block204and wirelessly retransmit the replenishment command. If the mobile device102does not reply to the query response, the method200may retry wirelessly transmitting the query several times over the course of one hour, two hours, or three hours. If the mobile device102does not reply after a predefined number of retries or after a predefined duration of time, the method200proceeds to block224.

In block224, a fare transaction history is analyzed in an attempt to draw an inference that the replenishment transaction has been completed or that the replenishment command was not received by the mobile device102. The provisioning server124may analyze the fare transaction history table148associated with the mobile device102to find a later fare transaction associated with a higher funds balance on the transit card application112relative to an immediately preceding in sequence fare transaction associated with a lower funds balance on the transit card application112. If this situation is identified in the fare transactions associated with the mobile device102, it can be inferred that the replenishment transaction completed, and the processing proceeds to block212. The provisioning server124may also infer that the replenishment command was not received by the mobile device102if a plurality of fare transactions having a timestamp later than the timestamp associated with the replenishment command that was sent by the provisioning server. In this case, the provisioning server124may resume the process at block204and wirelessly retransmit the replenishment command. In other cases, however, no inference can be drawn from analyzing the fare transaction history table148. When no inference can be drawn from the fare transaction history, the process200may repeat the processing of block224after waiting for predefined periods of time.

At block228, if the replenishment is confirmed by the analysis, the processing proceeds from block224to block212, otherwise the processing proceeds from block224to block232.

After a time, if no inference can be drawn from analyzing the fare transaction history table148, the method200proceeds to block232where a funds replenishment anomaly is reported, for example to an operator or an other employee of the transportation provider for manual recovery and/or adjustment of the funds balance of the transit card application112. The method200then exits.

Turning now toFIG. 3, a method250for automatic confirmation of funds replenishment is described. In block254, a request to add funds is received wirelessly. In block258, a request is made to charge a credit card in the amount of the funds replenishment, for example by the provisioning server124to the credit card payment processor126. In block262, an instruction to increment a funds balance is wirelessly transmitted. For example, the provisioning server124sends an instruction to increment the balance of the transit card application112via the network122to the base transceiver station120and wirelessly from the base transceiver station120to the mobile device102.

In block266, when confirmation of the balance increment is not received, for example within a predefined time period, the status of the balance increment transaction is wirelessly requested. If the confirmation of the balance increment is received, the method250exits. In block270, when a reply to the status query is received, if the reply indicates the balance increment is pending on the mobile device102, the process exits. In block270, if the reply indicates the balance increment is not pending and has not completed, the provisioning server124may resend the balance increment instruction. The process250exits. In block270, if no reply is returned, the transaction history is analyzed. The provisioning server124, for example the top-up event reconciliation component140, may analyze a series of entries in the fare transaction history table148associated with the mobile device102to infer the status of the balance increment transaction. In block274, when no inference can be drawn from analyzing the fare transaction history table148, for example after multiple attempts staggered in time to allow for the opportunity for the mobile device102to conduct a fare transaction with a fare gate104and/or for the fare transaction history table148to be updated, the charge to the credit card is backed out. For example, the credit card may not be charged by the credit card payment processor126and funds transferred to the transportation provider payment system128until a settlement time. If the settlement time has not occurred after the charge to the credit card was authorized, it may be possible to back out the charge without the charge ever being made to the credit card. In addition to backing out the charge from the credit card, a notification may be sent to the mobile device102that the funds transfer and/or top-up did not complete successfully. This may promote the user of the mobile device102taking some remedial action before simply being denied access to the transportation system. In block278, when the charge to the credit card cannot be backed out, an anomaly report is generated and sent to an operator of the transport provider or to another for remediation of the funds balance of the transit card application112. The transport provider may contact a user of the mobile device102to correct the funds balance on the mobile device102or to perform a charge back to the credit card. The method250then exits.

FIG. 4shows a wireless communications system including the mobile device102.FIG. 4depicts the mobile device102, which is operable for implementing aspects of the present disclosure, but the present disclosure should not be limited to these implementations. Though illustrated as a mobile phone, the mobile device102may take various forms including a wireless handset, a pager, a personal digital assistant (PDA), a portable computer, a tablet computer, or a laptop computer. Many suitable handsets combine some or all of these functions. In some embodiments of the present disclosure, the mobile device102is not a general purpose computing device like a portable, laptop or tablet computer, but rather is a special-purpose communications device such as a mobile phone, wireless handset, pager, or PDA. The mobile device102may support specialized activities such as gaming, inventory control, job control, and/or task management functions, and so on.

The mobile device102includes a display402and a touch-sensitive surface or keys404for input by a user. The mobile device102may present options for the user to select, controls for the user to actuate, and/or cursors or other indicators for the user to direct. The mobile device102may further accept data entry from the user, including numbers to dial or various parameter values for configuring the operation of the handset. The mobile device102may further execute one or more software or firmware applications in response to user commands. These applications may configure the mobile device102to perform various customized functions in response to user interaction. Additionally, the mobile device102may be programmed and/or configured over-the-air, for example from a wireless base station, a wireless access point, or a peer handset102.

The mobile device102may execute a web browser application which enables the display402to show a web page. The web page may be obtained via wireless communications with the base transceiver station120, a wireless network access node, a peer handset102or any other wireless communication network or system. The base transceiver station120(or wireless network access node) is coupled to the network122. Via the wireless link and the wired network, the mobile device102has access to information on various servers, such as the provisioning server124. The provisioning server124may provide content that may be shown on the display402. Alternately, the mobile device102may access the base transceiver station120through a peer handset102acting as an intermediary, in a relay type or hop type of connection.

FIG. 5shows a block diagram of the mobile device102. While a variety of known components of handsets102are depicted, in an embodiment a subset of the listed components and/or additional components not listed may be included in the mobile device102. The mobile device102includes a digital signal processor (DSP)502and a memory504. As shown, the mobile device102may further include an antenna and front end unit506, a radio frequency (RF) transceiver508, an analog baseband processing unit510, a microphone512, an earpiece speaker514, a headset port516, an input/output interface518, a removable memory card520, a universal serial bus (USB) port522, an infrared port524, a vibrator526, a keypad528, a touch screen liquid crystal display (LCD) with a touch sensitive surface530, a touch screen/LCD controller532, a charge-coupled device (CCD) camera534, a camera controller536, and a global positioning system (GPS) sensor538. In an embodiment, the mobile device102may include another kind of display that does not provide a touch sensitive screen. In an embodiment, the DSP502may communicate directly with the memory504without passing through the input/output interface518.

The antenna and front end unit506may be provided to convert between wireless signals and electrical signals, enabling the mobile device102to send and receive information from a cellular network or some other available wireless communications network or from a peer handset102. In an embodiment, the antenna and front end unit506may include multiple antennas to support beam forming and/or multiple input multiple output (MIMO) operations. As is known to those skilled in the art, MIMO operations may provide spatial diversity which can be used to overcome difficult channel conditions and/or increase channel throughput. The antenna and front end unit506may include antenna tuning and/or impedance matching components, RF power amplifiers, and/or low noise amplifiers.

The RF transceiver508provides frequency shifting, converting received RF signals to baseband and converting baseband transmit signals to RF. In some descriptions a radio transceiver or RF transceiver508may be understood to include other signal processing functionality such as modulation/demodulation, coding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transforming (IFFT)/fast Fourier transforming (FFT), cyclic prefix appending/removal, and other signal processing functions. For the purposes of clarity, the description here separates the description of this signal processing from the RF and/or radio stage and conceptually allocates that signal processing to the analog baseband processing unit510and/or the DSP502or other central processing unit. In some embodiments, the RF transceiver508, portions of the antenna and front end506, and the analog baseband processing unit510may be combined in one or more processing units and/or application specific integrated circuits (ASICs).

The analog baseband processing unit510may provide various analog processing of inputs and outputs, for example analog processing of inputs from the microphone512and the headset port516and outputs to the earpiece speaker514and the headset port516. To that end, the analog baseband processing unit510may have ports for connecting to the built-in microphone512and the earpiece speaker514that enable the mobile device102to be used as a cell phone. The analog baseband processing unit510may further include a port for connecting to a headset or other hands-free microphone and speaker configuration. The analog baseband processing unit510may provide digital-to-analog conversion in one signal direction and analog-to-digital conversion in the opposing signal direction. In some embodiments, at least some of the functionality of the analog baseband processing unit510may be provided by digital processing components, for example by the DSP502or by other central processing units.

The input/output interface518may further connect the DSP502to the vibrator526that, when triggered, causes the mobile device102to vibrate. The vibrator526may serve as a mechanism for silently alerting the user to any of various events such as an incoming call, a new text message, and an appointment reminder.

The keypad528couples to the DSP502via the input/output interface518to provide one mechanism for the user to make selections, enter information, and otherwise provide input to the mobile device102. Another input mechanism may be the touch screen LCD530, which may also display text and/or graphics to the user. The touch screen LCD controller532couples the DSP502to the touch screen LCD530.

The CCD camera534enables the mobile device102to take digital pictures. The DSP502communicates with the CCD camera534via the camera controller536. The GPS sensor538is coupled to the DSP502to decode global positioning system signals, thereby enabling the mobile device102to determine its position. In another embodiment, a camera operating according to a technology other than charge coupled device cameras may be employed. Various other peripherals may also be included to provide additional functions, e.g., radio and television reception.

FIG. 6illustrates a software environment602that may be implemented by the DSP502. The DSP502executes operating system drivers604that provide a platform from which the rest of the software operates. The operating system drivers604provide drivers for the handset hardware with standardized interfaces that are accessible to application software. The operating system drivers604include application management services (“AMS”)606that transfer control between applications running on the mobile device102. Also shown inFIG. 6are a web browser application608, a media player application610, a plurality of JAVA applets612, and the transit card application112. The web browser application608configures the mobile device102to operate as a web browser, allowing a user to enter information into forms and select links to retrieve and view web pages. The media player application610configures the mobile device102to retrieve and play audio or audiovisual media. The JAVA applets612configure the mobile device102to provide games, utilities, and other functionality.

Aspects of the system100described above may be implemented on any general-purpose computer with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.FIG. 7illustrates a typical, general-purpose computer system suitable for implementing one or more embodiments disclosed herein. The computer system700includes a processor710(which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage750, read only memory (ROM)730, random access memory (RAM)720, input/output (I/O) devices760, and network connectivity devices740. The processor710may be implemented as one or more CPU chips.

The secondary storage750is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM720is not large enough to hold all working data. Secondary storage750may be used to store programs which are loaded into RAM720when such programs are selected for execution. The ROM730is used to store instructions and perhaps data which are read during program execution. ROM730is a non-volatile memory device which typically has a small memory capacity relative to the larger memory capacity of secondary storage750. The RAM720is used to store volatile data and perhaps to store instructions. Access to both ROM730and RAM720is typically faster than to secondary storage750.

The processor710executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage750), ROM730, RAM720, or the network connectivity devices740. While only one processor710is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.