Automated confirmation of transit card fund replenishment

• US 7,797,248 B1
• Filed: 07/11/2008
• Issued: 09/14/2010
• Est. Priority Date: 07/11/2008
• Status: Expired due to Fees

• Current Assignee: T-Mobile Innovations LLC (Deutsche Telekom AG)
• Original Assignee: Sprint Communications Company LP (Deutsche Telekom AG)
• Inventors: Zhu, Kevin, Katzer, Robin D., Bierbaum, Christopher J., Koellner, Todd N.
• Primary Examiner(s): Abdi; Kambiz
• Assistant Examiner(s): Rosen; Elizabeth H
• Application Number:
  US12/172,085
• Time in Patent Office: 795 Days
• Field of Search: 705/35
• US Class Current: 705/66
• CPC Class Codes: G06Q 20/0652 e-cash with decreasing value according to a parameter, e.g. time
• CPC Class Codes: G06Q 20/085 involving remote charge determination or related payment systems
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 20/105 involving programming of a portable memory device, e.g. IC cards, "electronic purses"
• CPC Class Codes: G06Q 20/28 Pre-payment schemes, e.g. "pay before"
• CPC Class Codes: G06Q 20/349 Rechargeable cards
• CPC Class Codes: G06Q 20/353 Payments by cards read by M-devices
• CPC Class Codes: G06Q 20/363 with the personal data of a user
• CPC Class Codes: G06Q 20/3672 initialising or reloading thereof
• CPC Class Codes: G06Q 20/3676 Balancing accounts
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G07F 7/02 by keys or other credit registering devices

Abstract

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.

Claims

1. A method of managing a balance of a transit card, comprising:

wirelessly receiving a request from a mobile device to add funds to the transit card;

requesting by a server a charge in an amount of the funds to a credit card;

wirelessly transmitting by the server an instruction to the mobile device to increment the balance of the transit card by the amount of the funds;

determining that a confirmation that the balance of the transit card is incremented is not received by the server from the mobile device,

subsequent to the determining that the confirmation that the balance of the transit card is incremented is not received, requesting a status of the transit card, wherein the status of the transit card indicates whether the balance of the transit card has been incremented;

determining, responsive to the requesting, that the status of the transit card does not confirm that the balance of the transit card is incremented,

subsequent to the determining that the status of the transit card does not confirm that the balance of the transit card is incremented, analyzing by the server a transaction history of changes in the balance of the transit card;

determining that the analyzing the transaction history cannot confirm that the balance of the transit card is incremented,

subsequent to the determining that the analyzing the transaction history cannot confirm that the balance of the transit card is incremented, attempting to back out by the server the charge to the credit card in the amount of the funds; and

determining that the charge to the credit card cannot be backed out,

subsequent to the determining that the charge to the credit card cannot be backed out, reporting an anomaly of the balance of the transit card.

2. The method of claim 1, wherein the amount of the funds is a uniform quantity for each request to add funds to the transit card.

3. The method of claim 2, wherein the amount of the funds is a predefined quantity.

4. The method of claim 1, wherein the transit card is an application on the mobile device, wherein the mobile device is one of a mobile phone, a personal digital assistant, and a media player.

5. The method of claim 1, further including receiving by the server at least a portion of the transaction history as a batch transfer on a periodic basis.

6. The method of claim 5, wherein the transaction history is received about once per day.

7. The method of claim 1, wherein the transit card is associated with funds to wirelessly pay fares in a mass transportation system.

8. The method of claim 1, wherein the analyzing by the server of the transaction history associated with the transit card further comprises comparing by the server a first transaction record of the transaction history with a second transaction record of the transaction history, where the second transaction record immediately follows the first transaction record in time order in the transaction history.

9. The method of claim 8, wherein the server determines that analyzing the transaction history cannot confirm that the balance of the transit card is incremented based on a funds balance of the second transaction record not being greater than a funds balance of the first transaction record.