HK1204703B - Systems and methods for providing, reloading, and redeeming stored value cards used in transit applications - Google Patents

Description

System and method for providing, recharging and reimbursing stored value cards for use in transportation applications

Background

The present invention claims priority from U.S. provisional patent application No.61/680,802, filed 8/2012, which is incorporated herein in its entirety. The present application relates generally to systems and methods for conducting stored value card transactions in transportation applications. In particular, the invention relates to the retail, distribution, loading and redemption of stored value cards for use in transportation applications.

It has become commonplace for traffic systems to require or use different forms of payment for different traffic types. For example, subways may require subway tokens, while buses may require bus tickets. The train may require tickets and the highway toll may require cash payments. Payment for multiple traffic types may be inconvenient for the user. Accordingly, it is desirable to have a system that can reimburse a value source for one or more traffic types.

In addition, transit payment systems that allow the use of various stored values typically require timely registration and delay between registering and receiving a transit card or transponder. Accordingly, the ability to purchase a transportation card and/or transponder at a point of sale is desirable.

Disclosure of Invention

Aspects according to some embodiments of the invention may include a method of conducting a transportation card transaction between a central processor and a transportation processor, the central processor including an account associated with a transportation card and a data store, the data store including an account status, the method comprising: receiving, at the central processor, a redemption request from the traffic processor, the redemption request including information identifying the traffic card; determining, by the central processor, whether the redemption request is a pre-authorization request or a fee redemption request for a particular traffic type; upon determining that the redemption request is a pre-authorization request: determining, by the central processor, whether the account is authorized to conduct transactions for the particular traffic type based on factors including a status of the account; transmitting permission for pre-authorization to the traffic processor if the account is authorized to conduct a transaction for the particular traffic type; transmitting a denial of pre-authorization to the traffic processor if the account is not authorized to conduct transactions for the particular traffic type; upon determining that the redemption request is a fee redemption request: determining, by the central processor, whether a value associated with the account is greater than or equal to an amount requested by the fee redemption request; transmitting a rejection of the fee redemption request to the traffic processor if the value associated with the account is less than the amount requested by the fee redemption request; if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: transmitting permission for the fee reimbursement request to the traffic processor; deducting an amount of the set fee reimbursement request from the account; determining whether an amount of value associated with the account is below a predetermined threshold for one or more particular traffic types, and if so, updating the status of the account at the data store.

Some aspects according to some embodiments of the invention may include a method of conducting a transportation card transaction between a central processor and a transportation processor, the central processor including an account associated with a transportation card and a data store, the data store including an account status, the method comprising: receiving, at the central processor, an activation request from a retailer point of sale (POS) that includes information identifying the transportation card; determining, by the central processor: identifying whether the information of the traffic card is valid; and an account associated with the transportation card; and activating the traffic card by a central processor; receiving, at the central processor, a redemption request from the traffic processor, the redemption request including information identifying the traffic card; determining, by the central processor, whether the redemption request is a pre-authorization request or a fee redemption request for a particular traffic type; upon determining that the redemption request is a pre-authorization request: determining, by the central processor, whether the account is authorized to conduct transactions for the particular traffic type based on factors including a status of the account; transmitting permission for pre-authorization to the traffic processor if the account is authorized to conduct a transaction for the particular traffic type; transmitting a denial of pre-authorization to the traffic processor if the account is not authorized to conduct transactions for the particular traffic type; upon determining that the redemption request is a fee redemption request: determining, by the central processor, whether a value associated with the account is greater than or equal to an amount requested by the fee redemption request; transmitting a rejection of the fee redemption request to the traffic processor if the value associated with the account is less than the amount requested by the fee redemption request; if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: transmitting permission for the fee reimbursement request to the traffic processor; deducting an amount of the set fee reimbursement request from the account; determining whether an amount of value associated with the account is below a predetermined threshold for one or more particular traffic types, and if so, updating the status of the account at the data store.

Some aspects according to some embodiments of the invention may include a method of conducting a transportation card transaction between a central processor and a transportation processor, the central processor including an account associated with a transportation card and a data store, the data store including an account status, the method comprising: receiving, at the central processor, a redemption request from the traffic processor, the redemption request including information identifying the traffic card; determining, by the central processor, whether the redemption request is a pre-authorization request or a fee redemption request for a particular traffic type; upon determining that the redemption request is a pre-authorization request: determining, by the central processor, whether the account is authorized to conduct transactions for the particular traffic type based on factors including a status of the account; transmitting permission for pre-authorization to the traffic processor if the account is authorized to conduct a transaction for the particular traffic type; transmitting a denial of pre-authorization to the traffic processor if the account is not authorized to conduct transactions for the particular traffic type; upon determining that the redemption request is a fee redemption request: determining, by the central processor, whether a value associated with the account is greater than or equal to an amount requested by the fee redemption request; determining whether a withdrawal from the particular traffic type used in the fee redemption is necessary if the value associated with the account is less than the amount requested by the fee redemption request; authorizing the transaction for a total amount of value in the account if withdrawal is necessary; and deducting said request for fee reimbursement from said account, thereby resulting in a negative balance in said account; transmitting a rejection of the fee redemption request to the traffic processor if no exit is necessary; if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: transmitting permission for the fee reimbursement request to the traffic processor; deducting an amount of the set fee reimbursement request from the account; determining whether an amount of value associated with the account is below a predetermined threshold for one or more particular traffic types, and if so, updating the status of the account at the data store.

Some aspects according to some embodiments of the invention may include a system for conducting transactions using or associated with a transportation card, comprising: a retailer point of sale (POS); a traffic processor: a central processor in selective communication with the retailer POS and the traffic processor, the central processor comprising: a first data store comprising one or more records associated with the transportation card and indicating an amount of value associated with the transportation card; a second data store comprising one or more records associated with one or more transit cards that are not authorized to conduct transactions, the one or more transit cards capable of including the transit card; a processor configured to: receiving an activation request from the merchant POS to activate a transaction card, the activation request including information identifying the transit card; receiving a redemption request from the traffic processor; determining whether the redemption request is a pre-authorization request for a particular type of transportation and, if so, determining whether the account is authorized to conduct transactions for the particular type of transportation based on factors including a status of the account; determining whether the redemption request is a fee redemption request and transmitting permission for the transaction request to the traffic processor if the value associated with the account is greater than or equal to the amount requested by the fee redemption request.

These and other aspects will become apparent from the following description of the invention taken in conjunction with the following drawings, although variations and modifications may be effected without departing from the spirit and scope of the novel concepts of the invention.

Drawings

The present invention will be understood more fully from the detailed description given below in conjunction with the accompanying drawings, in which like reference numerals are used to designate like elements. The accompanying drawings illustrate certain illustrative embodiments and may be helpful in understanding the following detailed description. Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The illustrated embodiments should be considered as exemplary and in no way limiting of the overall scope of the invention. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The detailed description will refer to the following drawings, in which:

FIG. 1A illustrates an exemplary configuration of a traffic-using card and a traffic-rechargeable card, according to some embodiments of the invention.

FIG. 1B illustrates an exemplary method of activating a traffic-using card and a traffic-rechargeable card, according to some embodiments of the invention.

FIG. 2 illustrates an exemplary association between a traffic-using card, a traffic-rechargeable card, and an account, according to some embodiments of the invention.

FIG. 3 illustrates an exemplary association between a traffic-using card, a traffic-rechargeable card, and an account, according to some embodiments of the invention.

Fig. 4 illustrates an exemplary account configuration with various wallets, according to some embodiments of the invention.

FIG. 5 illustrates an exemplary method of conducting transactions using transit use cards, according to some embodiments of the invention.

Fig. 6 illustrates an exemplary method of conducting a top-up transaction using a traffic recharge card, according to some embodiments of the invention.

FIG. 7 illustrates an exemplary method of conducting a transportation use card sale, according to some embodiments of the invention.

Fig. 8 illustrates an exemplary top-up transaction according to some embodiments of the invention.

FIG. 9 illustrates an exemplary usage transaction according to some embodiments of the inventions.

Figure 10 illustrates an exemplary communication card sale, according to some embodiments of the invention.

Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

Detailed Description

The matters illustrated in this description are provided to assist in a comprehensive understanding of the various exemplary embodiments disclosed with reference to the accompanying drawings. Accordingly, those skilled in the art will recognize that various changes and modifications of the exemplary embodiments described herein can be made without departing from the spirit and scope of the claimed invention. Descriptions of well-known functional machine structures are omitted for clarity and conciseness. Furthermore, as used herein, the singular may be interpreted in the plural, and alternatively, terms of the plural may be interpreted in the singular.

The present invention contemplates the use of a stored value account associated with at least one card. The card may be equipped with a near field transponder or tag (e.g., an RFID (radio frequency identification) tag) so that payment can be made when in proximity to the reader, or payment can be triggered when the reader is contacted or "tapped" on the card. The card may be used on and/or with various transportation systems and/or mechanisms. For example, the user may pay subway fares, bus fares, taxi fares, and/or bridge-crossing fares, and/or any other type of transportation fare using the card.

The card may include at least one indicia representing a serial number or other identification number of the card. The indicia may be associated with the stored-value account such that use of the card in the transportation system may result in the consumption of value from the stored-value account.

According to some embodiments of the invention, a second card may also be associated with the stored value account, but the second card may not be equipped with a near field transponder, reader, or tag. The second card may include machine-readable indicia (e.g., a barcode or magnetic stripe) that may be associated with the stored value account. Using this association, a second card may be presented at each point-of-sale terminal and used to add value to the stored value account, rather than to consume value.

In this way, the anonymity of the user of the first card may be maintained. A payment (e.g., a credit or debit card (dda) payment), which may include identification information, may be associated with only the second card. The first card may or may not be used by the same user that provided value to the stored value account.

In this way, each party may provide a transportation card to the other parties. For example, a parent may provide a transportation card for their children. An employer may provide a transportation card to an employee as a benefit or to encourage public transportation. According to some embodiments of the invention, a state or federal agency may provide a transportation card for low-income or other identified groups of people.

The two cards (near field enabled card and machine readable rechargeable card) may be closely coupled or otherwise associated with each other. The association may occur, for example, at the printer or manufacturer of the card, or later by a central processing party or other third party entity. According to some embodiments of the invention, non-attached cards may be associated with near field enabled cards rather than machine readable cards in order to complete payments from other sources. For example, a generic prepaid card (e.g., Visa) may be associated with a near field enabled card to provide payment to an associated stored value account. Other forms of value accounts may be associated according to some embodiments of the invention. For example, customer rewards or loyalty points may be associated with the amount of value and with the near field transportation card. Similarly, frequent flyer miles or other such value types may be associated.

The present invention contemplates that the two cards (near field enabled card and machine readable rechargeable card) may be packaged and sold together. For example, this may be (but is not required to be) in the same package. According to some embodiments of the invention, cards may be distributed separately such that machine-readable rechargeable cards may be distributed to different users at different locations and subsequently linked or associated with stored-value accounts associated with near-field enabled transportation cards. Such an embodiment may be advantageous, for example, for the parent, employer and federal agency examples discussed above.

According to some embodiments of the present invention, the association ratio between the near field enabled card and the machine readable rechargeable card need not be 1 to 1. In other words, the near field enabled transportation card may access a stored value account that may be funded by more than one machine-readable rechargeable card. Thus, users of the transportation card may add value to their associated stored-value card, and third parties (e.g., parents, employers, government agencies, etc.) may also add value. Similarly, a single machine-readable rechargeable card may be associated with more than one transit card. In such embodiments, multiple transit cards may each access and consume the same stored value account, or they may each access and consume their own accounts, and a recharge transaction using a machine-readable recharge card may require identifying the particular account into which value is to be added.

Referring to fig. 1, an exemplary package 100 of a transportation use card 110 and a transportation charge card 120 is depicted. The package 100 may include a transportation use card 110 and a transportation charge card 120. The package 100 may also include information 101 regarding the initial value of credit (if any) for the use of the card, or may indicate that the use of the card may be credited using any account selected by the user, offer an amount option, etc. The package may also include a package label 102, and the package label 102 may be machine readable, such as a bar code, QR code, magnetic strip, Radio Frequency Identification (RFID) tag, and the like. Package indicia 102 may be associated with package 100 and used to activate use card 110 and rechargeable card 120, as discussed in more detail below. Alternatively, rather than using packaging indicia 102 to activate use card 110 and rechargeable card 120, packaging indicia 102 may be used merely as an inventory-keeping device for merchants or retailers to track inventory and sales. In this regard, the packaging indicia 102 may be considered or used as a Stock Keeping Unit (SKU) or a Universal Price Code (UPC).

The usage card 110 may include one or more indicia that are machine readable, transferable, or otherwise. For example, the use card 110 may include a use card identification mark 111 that can identify the use card. Referring to fig. 1, the usage card identification number 110 indicates that the usage card number is "12345678". Use of the card 110 may also include use of card machine-readable indicia 112, such as magnetic strips, bar codes, and the like. The usage card machine-readable indicia 112 may be incorporated in whole or in part into the usage card identification indicia 111 and may include additional information. For example, the use card machine-readable indicia 112 may include an Issuer Identification Number (IIN) or a Bank Identification Number (BIN) so that transactions using the use card 110 may be routed correctly. Alternatively, the use of card machine-readable indicia 112 may represent indicia that is completely different from the use of card identification indicia 110.

It is noted that usage card 110 may also include elements 113, 114, elements 113, 114 having or otherwise providing communications capabilities to usage card 110. For example, element 113 may be an RFID tag (passive or otherwise) that may provide communication with an RFID-enabled point of sale (POS) system. Similarly, element 114 may be a powered near field transmitter that may communicate with various POS identifications. In this manner, the use card 110 may be "tapped" at some POS systems, rather than manually providing the identification indicia 111 and/or swiping or reading the machine-readable indicia 112.

The prepaid card 120 may similarly include a prepaid identification tag 121 that may uniquely or semi-uniquely identify the prepaid card 120. For example, referring to fig. 1, the top-up identification mark 121 indicates that the top-up card is identified by "ABCD EFGH". The charge card 120 may also include one or more charge machine readable indicia 122, 123, the charge machine readable indicia 122, 123 including, for example, a magnetic stripe and/or a bar code. Such machine-readable indicia 122, 123 may be used to identify the charge card 120 during a charge transaction.

Referring to FIG. 1B, an exemplary activation process will now be discussed. At 130, the use card and the recharge card are associated together. This may occur after the cards are manufactured, or by associating or binding the indicia from each card in a database, regardless of when the cards were manufactured. At 135, the use card and the recharge card may be associated with an activation indicia (e.g., the package indicia 102 illustrated in fig. 1A). Alternatively, since the rechargeable card and the use card are associated with each other, only one of the cards may be directly associated with the activation indicia.

At 140, the use and recharge cards can be packaged together, and at 145, the activation indicia can be printed or stored on the packaging. Alternatively, the packaging may be printed with activation indicia, which may be associated with the use and rechargeable cards after packaging.

At a subsequent time, at 150, an activation indicia may be received at the central processor from the POS. The central processor may confirm that the activation indicia is valid at 155 and identify the use card and the rechargeable card based on the activation indicia at 160. The use card may then be activated for use, and the recharge card may be activated to provide recharge capabilities.

It is noted that it is also contemplated that the use and top-up cards will be sold in an "activated" state, and that instead the activation transaction activates the relevant account by placing value into such account or releasing the value-related reservation in such account.

Referring to FIG. 2, an exemplary association between a transportation use card, a transportation recharge card, and an account according to some embodiments of the present invention will now be discussed. As can be seen in fig. 2, the usage card 210 is associated with a rechargeable card 220. The usage card 210 is also associated with a related account 230. Account 230 may be a value account (e.g., a bank account, credit account, or other financial account) or may be a database account that is in turn associated with a financial amount or account. Referring to fig. 2, the use card 210 is a master card and a top-up transaction using the recharge card 220 may require identifying the use card 210 and then identifying a value account 230 associated with the use card 210.

In contrast, FIG. 3 illustrates an alternative exemplary association between a traffic-using card, a traffic-rechargeable card, and an account according to some embodiments of the invention. Referring to fig. 3, both the use card 310 and the recharge card 320 are associated with an account 330. Additional security and/or anonymity may be achieved through this configuration. For example, the rechargeable card 320 may not have a connection to the use card 310, and the details of the card use may be unknown or unavailable to the person having access to the rechargeable card. As described above, such a configuration may be desirable when the party owning or utilizing the rechargeable card 320 is different from the party owning or using the card 310.

The present invention also contemplates that the account associated with using and/or recharging the card may include one or more wallets, which in turn may include one or more sub-wallets. Such purses may have the same or different characteristics. For example, a transportation facility may wish to encourage people to use large, efficient traffic, such as subways or railways. Therefore, a $1.00 possible value of $1.25 in a wallet for use in a subway or track. Conversely, $1.00 in a toll road wallet or parking lot wallet may equal $ 1.00.

By using different wallet characteristics, parties may encourage or promote certain activities. If a parent provides a transportation card to his or her child, the parent may wish the child to use the car rental or ZIPCAR service instead of purchasing their own car. Thus, to encourage children to use car rental, parents may provide the value characteristic of car rental purses such that $1.00 is equivalent to $ 1.50. Different value characteristics of the wallet may be desirable because activities encouraged for one or more users may be discouraged system-wide. Thus, instead of adjusting the price of the service purchased with the transportation card, the amount of value associated with each wallet in the transportation card may be adjusted individually (or in groups).

For example, the account may include a wallet related to a ticket or other debt that may be caused during transit. If the ticket is paid using a transportation card, the value feature may encourage payment of the ticket directly or quickly. For example, $1.00 might be equivalent to $1.15 if the ticket was paid using a transportation card when issued. Such an increase in value (or a corresponding decrease in the amount of the ticket) may be effected by a decrease in administrative costs typically associated with the collection of ticket payments.

According to some embodiments, the use of a card may be used to provide transit fare, or the use of a card may be used to provide payment for a ticket, but not both. Alternatively, a transportation card may be used for transportation fees, however once used to pay the ticket, the transportation card may be deactivated and a new transportation card may be obtained.

Referring to fig. 4, the account 40 may include one or more purses. For example, the account 40 may include a toll road wallet 410, a parking lot wallet 420, a taxi cab wallet 430, a ticket/debt wallet 440, and a car rental/ZIPCAR wallet 450. Similarly, the account 40 may also include a public transportation wallet 460, which public transportation wallet 460 in turn may include a bus sub-wallet 461 and a subway/rail sub-wallet 462. As described above, each of these wallets may include different value characteristics.

These purses may be funded individually (or by a party that deposits or loads an account, for example), or may be funded on average or according to a general usage algorithm that may take into account average price, average usage, and the like. Alternatively, the wallet may not retain value in a separate sub-account, but may simply reflect how the value is processed when used in a particular transaction. In other words, the public transportation wallet 460 may not exclusively retain value, but may indicate that certain value characteristics should be applied if the value associated with the master account 40 is used in a public transportation context.

Referring to fig. 5, an exemplary method 50 of conducting transactions using transit use cards according to some embodiments of the invention will now be discussed. At 510, a transaction may be initiated at a point of sale (POS). It is noted that the POS may comprise a conventional cash register at a retailer, merchant, or provider of goods and/or services. POS may also include pricing tables in taxis, ticket boxes in buses, kiosks, turnstiles (e.g., at the entrance to a subway system), parking pricing tables or other tables, tollgates, toll devices utilizing wireless communications (e.g., near field communications utilized by EZPass, EZTag, FastTrak, etc.), and/or any other system that provides value in payment transactions for goods and/or services.

At 520, the use card may be presented at the POS as payment for goods and/or services. Again, the presentation of the use card may depend on the type of POS at which the transaction is being conducted. Transactions at a conventional cash register may be performed by swiping a magnetic strip on the card or reading a bar code or other machine-readable indicia thereon. The transaction at the ticket box may be performed using near field communication and the customer may tap the use card only on the near field reader. The transaction at the parking meter may involve swiping a use card or may involve the user providing indicia on the use card into the meter. The use card may be presented at a highway toll booth by associating the use card with a device readable by the toll collection system (e.g., associating or inserting the use card into a transponder unit used in the toll collection system). It is noted that the above paragraphs are not intended as limitations, but rather are intended to explain the breadth of the considerations made by the present invention.

At 530, the POS may capture the usage indicia on the usage card. It is noted that the label may be captured in various ways.

At 540, the POS or a processor associated with the POS (e.g., a POS host or other central unit) may determine a processor or issuer ("central processor") associated with using the card. Such a determination may be based on the IIN or BIN described above, for example.

At 550, the POS or a processor associated with the POS may route information related to the transaction to the central processor. This information may include indicia from the use of the card and the amount of the desired transaction. Additional information may also be included in the communication, such as the location, time, date, etc. of the transaction, which may be used for record keeping, fraud determination, etc.

At 560, the central processor may receive information from the POS or a processor associated with the POS, and at 561, the central processor may determine whether the usage flag is valid. If the usage flag is not valid, the central processor may deny the transaction at 563. If the usage token is valid, the central processor may identify the account associated with the usage token and the value (if any) therein. The central processor may then determine whether the value in the account is greater than or equal to the amount of the requested transaction at 562. If the amount in the account is not greater than or equal to the amount of the requested transaction, the transaction may be denied 563. If the amount in the account is greater than or equal to the amount of the requested transaction, the transaction may be authorized at 564 and the amount of the transaction may be subtracted from the account at 565. The central processor may then communicate with the POS to instruct the POS to proceed with the transaction, and at 570, the POS may proceed with the transaction.

It is noted that in order to perform real-time or near real-time transactions, the central processor may utilize some heuristic or shortcut. For example, and as discussed in more detail below, the central processor may maintain a denial database that includes indicia of use associated with accounts that have no value or insufficient value to obtain any goods and/or services, or that have been associated with some type of fraud. The central processor may initially query such a decline database and, in time, decline the transaction associated with such usage indicia. Alternatively, the POS system itself may be periodically updated with a rejection database so that if the indicia listed in the rejection database is identified, the POS itself may immediately reject the transaction.

Referring to fig. 6, an exemplary method 60 of conducting a top-up transaction using a traffic top-up card according to some embodiments of the invention will now be discussed. At 610, a load transaction may be initiated at the POS. The POS may include the various POS systems described above, including electronic or computerized kiosks. It is also contemplated that the top-up transaction may be performed at a POS that is unrelated to the goods and/or services purchased using the transportation use card. In other words, while the use card may be used at a road toll or parking space, the relevant account may be supplemented with a recharge card at a convenience store, a big store, a website or other digital storefront, an application or applet running on a mobile computing device or mobile communication device (e.g., mobile phone, smart phone, tablet computer, laptop computer, navigation system, etc.).

At 611, the POS may capture or otherwise obtain the top-up indicia on the top-up card. For example, the POS may capture the indicia by reading a machine-readable indicia (e.g., a magnetic strip, a barcode, an RFID tag, etc.) on the rechargeable card. Alternatively, the POS may obtain the top-up indicia by the user manually entering the top-up indicia (e.g., in the case of an online top-up transaction or by using a mobile computing device or mobile communication device).

It is also contemplated that the recharge transaction may be conducted over the telephone, such as by communicating with an Interactive Voice Response (IVR) system.

At 612, the POS or a processor associated with the POS (e.g., a POS host or other central unit) may determine a processor or issuer ("central processor") associated with the rechargeable card. Such a determination may be based on the IIN or BIN described above, for example. It is noted that the discussion herein assumes that the central processor managing the top-up transaction is the same central processor managing the user transaction. However, it is contemplated that two or more processors may be used or that a single processor may be divided to act as two different processors. The discussion focuses on a single central processor for clarity, however the present invention fully contemplates division of labor between one or more processors based on the type of transaction (recharge versus use or reimbursement).

At 613, the POS may receive an amount from the customer to top up the relevant account associated with the prepaid card (and thus associated with using the card). According to some embodiments, the customer may select a value for any amount. According to some embodiments, the customer may be presented with a recharge option, which may be based on the monetary amount (e.g., $10, $25, $50), or may be based on a particular use (e.g., 20 subway trips, one (1) month road charge, etc.). The present invention also contemplates that the transportation system may provide a single payment option for an "all-you-can-eat" model, where the customer may pay for an account (e.g., $250) for all transportation (including subway, bus, light rail, road tolling, and certain restricted parking lots, for example) usage for one month.

At 614, the POS or a processor associated with the POS may communicate with the central processor and provide the top-up indicia and the amount of value to be inserted into the associated account.

At 620, the central processor may receive the information, and at 630, the central processor may determine whether the top-up flag is valid. If the load indicia is not valid, the transaction may be denied. If the top-up token is valid, the top-up transaction may be performed in various ways. For example, if the association structure of the use card, the refill card, and the related account is the one indicated in fig. 2, the central processor may determine the use token associated with the refill token 641 and then determine the account associated with the use token 642. At 643, the central processor may then add a top-up amount to the amount available in the account associated with the usage indicia. If the association of the use card, the refill card and the associated account is the one indicated in fig. 3, the central processor may determine the account associated with the refill token at 650 and add the amount of the refill value to the account at 651.

These two ways are not intended to be limiting but are used to illustrate variations of the invention based on various association considerations between various cards, accounts, tokens, etc.

At 660, the central processor may send confirmation to the POS that the recharge transaction has been successful. At 615, the POS may communicate confirmation to the user that the recharge transaction has been successful. Such confirmation may be, for example, a receipt, a confirmation email, an audio confirmation, a text (SMS or MMS) message, or a confirmation screen presented on a computer or kiosk.

Thereafter, at 616, 670, settlement may occur between the POS or a processor associated with the POS and the central processor. Such settlement may occur in a variety of ways, including, for example, an automated exchange (ACH) transaction.

Providing a top-up transaction may also impact the heuristics of the system. For example, as described above, the use card or token may be placed in the rejection database because of insufficient funds. Thus, upon a load transaction, the central processor may activate the usage token at 680, thereby removing it from the deny database. If the account is owed, the amount owed may be deducted from the associated account at 690 before the usage flag is made available for use.

Referring to FIG. 7, an exemplary method 70 of conducting transit use card sales in accordance with some embodiments of the present invention will now be discussed. Before discussing the individual steps, it is important to note that although numerous steps are shown in FIG. 7 and explained below, each step is not necessarily required. Rather, the method 70 illustrated in FIG. 7 may be representative of a particular configuration and sales process; various steps may be deleted and/or added to the process without departing from the invention.

At 701, a customer may select a transportation card to make a purchase. The transportation use card may be pre-associated with the rechargeable card or may be sold separately with a preset value. In the case of a preset value, a top-up may be purchased at a later time and later associated with the use of the card and the associated account associated with the use of the card. At 702, the customer may present the card at the POS for purchase, and at 703, the POS may capture or otherwise receive indicia of use of the card to establish a sale of the use of the card.

If the user card is not pre-stored with a preset value, the customer may be prompted to provide a credit amount at 704. The customer may be prompted by digital communication (e.g., on the kiosk screen, by telephone, by text (SMS, MMS) message, etc.), or may be prompted by the sales assistant asking the customer how much value to deposit.

At 705, the customer may pay the POS the total amount. The total amount may include an initial charge for purchasing the card and/or any additional taxes, fees, or charges that may be appropriate and/or required.

At 706, the POS or a processor associated with the POS may send an activation request that is ultimately routed to a central processor that processes transactions related to using the card. Initially, the communication may be routed to the POS host at 706, and from the POS host to the central processor at 707. The central processor may process the activation request at 708 and, if successful, send a response back to the POS host at 709. At 710, the POS host may send a response to the particular POS that is conducting the transaction indicating that the activation was successful. The transaction may then be completed and, at 711, the POS may generate a receipt detailing the transaction. Such receipts may be in paper form, provided digitally, or may include audio information that may be played to the customer.

Alternatively, at 712, the customer may be directed to register for use of the card via the internet or via the IVR system 713. If the customer selects an IVR, it may link to the IVR registration system at 714, and if the customer selects the web or Internet, it may link to the web registration system at 715.

Registration may be encouraged for several reasons. If the user registers and forgets where to place the use card, the customer may request that the central processor disable the use card and provide a replacement card in its place. If a usage card is registered, it is easier to associate a rechargeable card with the usage card. Further, if a use card is registered, the customer may have the option of associating a payment device (e.g., credit card, debit card (or other open or half-open loop type cards), checking account, etc.) with the use card, such that when the balance of the account associated with the use card is reduced below a certain level, the charging of the specified amount may be automatically performed.

The present invention also contemplates that the use card may be a combination use card having a closed loop function for operation within the transit system and an open loop function for operation outside the transit system. For example, a prepaid Visa card may be equipped with a closed loop wallet that may be used within a transit system. In this case, the closed-loop purse may be automatically filled from the open-loop side of the product when the closed-loop purse falls below a certain level.

Referring to fig. 8, a method 80 of an exemplary top-up transaction in accordance with some embodiments of the present invention will now be discussed. At 800, a customer may present a card at a POS for a recharge transaction. It is contemplated that the customer may present the recharge card, however it is also contemplated that the customer may present the use of the card for direct recharge. The POS may receive indicia from the customer from the card at 805, and the POS may receive a top-up amount sought by the customer at 810. At 815, the POS may receive actual payment of the top-up amount (plus any appropriate taxes, fees, charges, etc.). At 820, the POS (or POS host or other processor associated with the POS) may send a recharge request to the central processor. At 825, the central processor may receive a recharge request, and at 830, the central processor may determine whether the indicia identifying the card is valid and whether the card is active. If the card is not active, as determined at 835, the process can be routed at 840 as an initial activation process substantially the same as discussed above. If the indicia is valid and the card is active, as determined at 845, the central processor may identify the associated account, at 850.

At 855, the central processor may determine whether the associated account is owed or whether the associated card and account are listed in the rejection database. If the card and/or account is marked in the rejection database at 865, the entry will be removed in the rejection database at 870, assuming that the recharge amount is sufficient to remove the account from the arrears status. If it is determined at 860 that the card and/or account is not listed in the rejection database, or after removing the rejection flag at 870, the central processor may add value to the associated card account. The value may be a customer-specified value of the charge, or may be the customer-specified value of the charge minus any suitable or required fee, tax, charge, etc.

At 880, the central processor may send a message to the POS, POS host, or processor associated with the POS indicating that the refill transaction was successful, and then, at 885, the POS may communicate confirmation of the refill transaction to the customer.

Referring to FIG. 9, an exemplary usage transaction 90 according to some embodiments of the invention will now be discussed. As with the previously discussed methods, it is noted that various steps may be omitted or added to the methods discussed below without departing from the invention.

Referring to fig. 9, the method involves the following scenario: the final amount to be charged to the customer's use of the card may not be known until the customer completes his or her trip. For example, the price for riding a subway may change based on the route, distance, and/or duration of the ride. Similarly, the toll fee is generally related to the total distance traveled on the toll road or to the urban area (city) passed on the toll road. Similarly, customers may travel within the transportation system (bus to subway, subway to light rail, light rail to parking lot) and be charged at the end of the travel rather than for each section on the road. Thus, the method illustrated in fig. 9 may show the following: the POS may authorize access to the customer and thereby charge the customer for the total amount of travel using the card at a later time.

At 901, a customer may present a use card at a POS. Again, the POS may take many of the forms described above. At 902, the POS may capture or otherwise receive indicia from a use card at an entrance of a transportation system or at a particular transportation device (e.g., taxi, subway, bus, toll road, etc.). At 903, the POS may verify the indicia against a denial database to determine if the card is associated with an invalid card or if the card is associated with an associated account that is owed, has a zero balance, or has a balance insufficient to pay for any goods and/or services in the transit system. For example, the card may have a balance of $0.78, whereas the minimum bus ride, subway trip, toll road, or taxi fee may be $ 1.10.

If the card is listed in the rejection database at 904, the transaction may be rejected at 905 and the customer is prevented from entering the transit device. Blocking may include locking a turnstile, a toll gate not being raised, or a bus driver blocking access.

Such local pre-authorization of the card may be desirable because it allows the POS to efficiently block passengers who are unlikely to provide sufficient payment for the service, without requiring timely communication with the central processor. The central processor may periodically update the POS system, for example, by accessing a database queried by the POS or modifying a list of cards and/or accounts in a deny database or allow database.

If the POS determines that the card is not listed in the deny database (or alternatively and equivalently, in the allow database) at 906, the customer may be allowed access to the transit system at 907. At 908, the customer may travel in the transit system to his or her destination, and at 909, the customer may exit the transit system and again present the use card at the POS. At 910, the POS may determine a total charge for the itinerary traveled by the customer, and at 911, the POS (or POS host or processor associated with the POS) may send the total charge to the central processor along with indicia captured or otherwise obtained from the user card.

At 912, the central processor may determine whether the card number is valid. If the card number or token is determined to be invalid at 913, the card, token, or associated account may be added to the rejection database at 914. If the card number is determined to be valid 915, the central processor may identify the associated account 916 and determine the amount of value in the associated account 917.

At 918, the central processor may determine whether the amount of value in the associated account is greater than or equal to the total charge. If the amount in the account is less than the total charge, as determined at 919, the central processor may determine if the source of the automatic refill is associated with using the card or related account, at 920. If there is no source of automatic recharge 921, the central processor may deduct all available funds from the relevant account 922 and note that the amount of the relevant account is in arrears. Processing may then move to step 914 where a card, token, or related account may be added to the rejection database at step 914.

If it is determined at 923 that there is an identified automatic refill associated with using the card or related account, the central processor may request a refill transaction with the identified value source at 924. If the recharge transaction is determined to be unsuccessful at 925, the process may return to step 922, at step 922, all available funds are deducted from the account, and the card, token, or related account may be listed in the refusal database.

If the recharge transaction is determined to be successful at 926, the process may continue.

Whether the recharge transaction is successful in 926 or the amount in the associated account is determined to be greater than or equal to the total charge at step 918, the central processor may then deduct or subtract the total charge from the amount of value in the account at 927. The central processor may then determine whether the remaining balance in the associated account is too low to pay for any goods and/or services in the transit system (as described above) at 928, and if the account is deemed too low to be used at 929, the card, token, or associated account may be listed in the denial database at 914.

If it is determined at 930 that the amount remaining in the account is acceptable (i.e., above an established minimum threshold that will allow the purchase of at least some of the goods and/or services of the transit system), the transaction is ended at 931.

Referring to FIG. 10, an exemplary sales process 1000 for a transit card according to some embodiments of the invention will now be discussed. It is noted that the method disclosed in fig. 10 is merely exemplary, and various steps may be added or omitted from the process. The method illustrated in FIG. 10 is somewhat specific in that it is intended to disclose what an actual transaction may include; however, the invention illustrated and claimed herein may not require each of the elements or steps illustrated in fig. 10.

At 1001, a customer may access a POS location, such as an electronic or automated kiosk. At 1002, the customer may choose to purchase a transportation card by utilizing a customer interface at a kiosk. At 1003, the customer may input an amount to fund the transportation card, and at 1004, the customer may select or choose a payment method. The customer may pay for the transit card using cash, credit, debit, and/or any other type of value accepted by the kiosk. The customer may pay the amount of funds to be provided on the transportation card or more after being required or after applying the appropriate tax, fee, charge and/or fee to the purchase transaction. At 1005, the kiosk customer may, for example, select a payment method using a credit or debit card, and may swipe or tap the credit or debit card. At 1006, the kiosk may identify the next available card number (which may be continuous, random, or semi-random according to an algorithm), and at 1007, the kiosk may send a pre-authorization request to the gateway of the central processor. At 1008, the gateway of the central processor may send a pre-authorization request to the appropriate platform of the central processor, which may perform pre-authorization activation verification at 1009. At 1010, the central processor platform may respond to the central processor gateway, which may in turn send communications back to the kiosk at 1011.

If the pre-authorization transaction is not successful at 1012, the kiosk may present a friendly failure message to the user requesting the customer to try again at 1013.

If the pre-authorization transaction is successful, the kiosk may send a payment request to a merchant acquirer associated with the payment card presented by the customer at 1014. At 1015, the merchant acquirer can process the payment and send a response to the kiosk. At 1016, the kiosk can determine whether the payment request was successful and, if not, can present a friendly failure message to the customer as in step 1013. If the payment request is successful, the kiosk may send an activation request with the credit to the central processor gateway at 1017, which may then be routed to the appropriate central processor platform at 1018. At 1019, the central processor platform may activate the card and fund the associated account for the requested amount, and at 1020, the central processor platform may provide confirmation of this to the central processor gateway.

At 1021, the central processor gateway can respond to the kiosk with the current status. If the activation is successful at 1022, the kiosk may distribute the transportation card and receipt to the customer at 1023. Settlement may then occur between the central processor and the kiosk at 1024, and the records may be synchronized at 1025.

If the activation was not successful at 1022, a friendly failure message may be presented to the customer at 1026, and at 1027 the kiosk may then resupply the customer's payment card by sending a credit request to the merchant acquirer at 1027, which is received by the merchant acquirer at 1028 and responded to back to the kiosk at 1028. If the payment credit is determined to be unsuccessful at 1029, the payment can be recorded for manual reconciliation at a later time at 1030. If the payment credit transaction is successful at 1029, the process may continue to 1020, at 1020, settlement may occur later (now between the kiosk and the merchant acquirer), and the records may be synchronized at 1025.

The exemplary method set forth in FIG. 10 and the above discussion are handled among several parties: a customer; kiosks (or retailers); a central processor for sending and supporting the traffic card; and a payment source. The present invention contemplates that the kiosk may be maintained, operated, or otherwise associated with the central processor, whereby it is not necessary to present some of the above-described communications. It is also considered that: in the case of a cash purchase, the communication discussed above and shown in FIG. 10 including the merchant acquirer may not be necessary.

In other words, various modifications, alterations, and changes may be made depending on the type of transaction, the identities and numbers of the parties, the relationships between the parties, and/or various other factors.

It should be understood that the particular embodiments of the invention shown and described herein are merely exemplary. Numerous variations, changes, substitutions and equivalents will now occur to those skilled in the art without departing from the spirit and scope of the present invention. Accordingly, it is intended that all subject matter described herein and shown with reference to the accompanying drawings be regarded as illustrative only and not in a limiting sense and that the scope of the invention be solely determined by the appended claims.

Claims (15)

1. A method of conducting a transportation use card transaction, the method conducted between a central processor and a point of sale, POS, the central processor including an account associated with a transportation use card and a data store, the data store including an account status, the method comprising:

adding value to the transit user card using a separate transit recharge card that is associated with an account accessible to the transit user card and that is only operable to add value to the account and not to access and use funds in the account accessible to the transit user card, the separate transit recharge card including an identification token, such that the POS is configured to receive the identification token of the transit recharge card during a recharge transaction;

the POS receiving indicia at an entrance of a particular transportation device of a particular transportation type, the indicia including information identifying the transportation usage card for paying any fees, tolls, and/or values for any other type of transportation fee from an account associated with the transportation usage card, rather than adding value to the account using a separate transportation charge card associated with the transportation usage card;

pre-authorizing card use by the POS based on determining whether the indicia is valid for a transit use card transaction for a transit device of a particular transit type based on factors including a status of the account, wherein the status of the account includes whether an amount of value associated with the account is above an established minimum threshold that would allow purchase of at least some goods and/or services from a transit device of a particular transit type;

if the POS determines that the account's status is not authorized to conduct a transit card transaction for a transit device of a particular transit type, denying the transaction and preventing a transit card-using customer from entering the transit device;

allowing a customer of the transit use card to enter the transit device if the POS determines that the tag is valid for a transit use card transaction for a transit device of a particular transit type;

determining, by the central processor, whether a value associated with the account is greater than or equal to an amount requested by a fee redemption request from a POS for a transit use card transaction;

transmitting a rejection of the fee redemption request to the requesting POS if the value associated with the account is less than the amount requested by the fee redemption request;

if the value associated with the account is greater than or equal to the amount requested by the fee redemption request:

transmitting permission for the fee reimbursement request to the requesting POS;

deducting the amount of the fee reimbursement request from the account.

2. The method of claim 1, wherein the indicia comprising information identifying the transportation use card comprises machine-readable indicia printed or stored on the transportation use card.

3. The method of claim 1, further comprising:

receiving, at the central processor, an activation request from a retailer point of sale (POS) including information identifying the transportation use card;

determining, by the central processor:

whether a flag including information identifying the transportation use card is valid; and

an account associated with the transportation use card; and

activating the transportation use card by a central processor.

4. The method of claim 3, wherein the transportation use card and the recharge card are placed in a package prior to activation, and the activation request further comprises information read or obtained by the POS from the package.

5. The method of claim 1, wherein the traffic device of the particular traffic type is selected from the group consisting of: taxis, buses, subways, road or bridge tolls, parking meters, trains or light rails, trams, and car rentals.

6. The method of claim 1, further comprising:

when the central processor determines that it is necessary to withdraw from the particular type of transportation used in the fee redemption request and the value associated with the account is less than the amount requested by the fee redemption request:

authorizing the transit use card transaction for a total amount of value in the account; and

deducting the amount of the fee redemption request from the account, thereby resulting in a negative balance in the account.

7. The method of claim 1, wherein the method is performed in real-time or near real-time.

8. The method of claim 1 wherein the fee redemption request is associated with a summons for parking, driving or toll violations.

9. The method of claim 8, further comprising:

terminating the account when the ticket is paid using the account, thereby invalidating the transit use card for future use.

10. A system for conducting transactions using or associated with a transportation card for paying the value of any fee, toll, and/or any other type of transportation fee from an account associated with the transportation card, rather than adding value to the account using a separate transportation charge card associated with the transportation card, comprising:

a retailer point of sale (POS);

a central processor in selective communication with the retailer POS and a traffic processor, the central processor comprising:

a first data store comprising one or more records associated with the transportation use card and indicating an amount of value associated with the transportation use card;

a second data store comprising one or more records associated with one or more transit use cards that are not authorized to conduct transactions;

a processing module configured to receive an activation request from the retailer POS to activate a transportation use card, the activation request including information identifying the transportation use card,

pre-authorization by the traffic processor at an entrance to a traffic device for a particular traffic type, determining whether an account associated with a traffic-use card is authorized for a transaction for the traffic device for the particular traffic type based on factors including a status of the account, wherein the status of the account includes whether an amount of value associated with the account is above an established minimum threshold that would allow purchase of at least some goods and/or services from the traffic device for the particular traffic type;

if the transportation processor determines that the account is not authorized for a transportation-using card transaction for a transportation device of a particular transportation type, the transportation processor denies the transaction and prevents a customer of the transportation-using card from entering the transportation device;

if the traffic processor determines that the account is authorized for a traffic-using-card transaction for a traffic device of a particular traffic type, then a customer of the traffic-using-card is allowed access to the traffic device.

11. The system of claim 10, further comprising: a point of sale disposed about, or associated with, each of the one or more traffic types.

12. The system of claim 11, wherein the one or more traffic types are selected from the group consisting of: taxis, buses, subways, road or bridge tolls, parking meters, trains or light rails, trams, and car rentals.

13. The system of claim 10, further comprising: a government processor associated with a government agency, the processor configured to process transactions relating to summons, the central processor in selective communication with the government processor.

14. The system of claim 10, further comprising:

a traffic rechargeable card including an identification tag,

wherein the transportation use card comprises an identification mark,

wherein the identification mark of the transportation use card and the identification mark of the transportation charge card are associated with each other to activate the transportation use card and the transportation charge card;

wherein the transportation processor is configured to receive an identification indicia of the transportation use card in a redemption transaction; and

wherein the retailer POS is configured to receive an identification token of the transportation charge card in a charge transaction.

15. The system of claim 10, further comprising:

a package, comprising:

a transit-use card, including an identifying indicia, for paying the value of any fee, toll, and/or any other type of transit fee from an account associated with the transit-use card, rather than adding value to the account;

a separate transportation charge card including an identification indicia, the transportation charge card for adding value to an account associated with the transportation use card rather than paying value from the account;

a package label used by the retailer POS to activate the transportation usage card and the transportation rechargeable card,

wherein the identification mark of the transportation use card and the identification mark of the transportation charge card are associated with each other by associating the identification mark of the transportation use card and the identification mark of the transportation charge card with the packaging mark.