S/M for providing, reloading, and redeeming stored value cards used in transit applications

Information

  • Patent Grant
  • 11055686
  • Patent Number
    11,055,686
  • Date Filed
    Monday, August 5, 2013
    10 years ago
  • Date Issued
    Tuesday, July 6, 2021
    2 years ago
Abstract
The invention is directed to systems and methods of conducting transactions associated with a transit card. A method of conducting transactions may be conducted between a processor and a transit processor. Steps may include receiving a redemption request and determining if it is a pre-authorization request or a redemption; if the redemption request is a pre-authorization request, determining if the account is authorized for a particular transit type. If the account is authorized, communicating approval to the transit processor. If the account is not authorized communicating denial. If the redemption request is a redemption: determining if account value is sufficient to pay the redemption amount; if not, denying and if so approving the transaction and deducting the amount, and determining if the account value is below a pre-determined threshold for a particular transit types, and if so, updating the status of the account at a data store.
Description
BACKGROUND OF THE INVENTION

The present invention is generally directed to systems and methods for conducting stored value card transactions in transit applications. Specifically, the present invention is directed to the retail, distribution, reloading, and redemption of stored value cards used in transit applications.


It has become commonplace for transit systems to require or utilize different forms of payment for different transit types. For example, a subway may require subway tokens, while a bus may require a bus pass. A train may require a ticket while a road toll may require a cash payment. Payment of multiple transit types can be inconvenient to a user. Accordingly, a system in which a value source may be redeemed at one or more transit types is desirable.


Moreover, transit payment systems that allow for various stored value to be used often require timely registration and a delay between registering for a transit card or transponder and receiving it. Accordingly, the ability to purchase a transit card and/or transponder at a point of sale is desirable.


SUMMARY OF THE INVENTION

Aspects in accordance with some embodiments of the present invention may include A method of conducting transit card transactions, the method conducted amongst a central processor comprising an account associated with a transit card and a data store comprising a status of the account, and a transit processor, the method the comprising: receiving at the central processor from the transit processor a redemption request including information identifying the transit card; determining by the central processor whether the redemption request is a pre-authorization request for a particular transit type or a fee redemption request; upon a determination that the redemption request is a pre-authorization request: determining by the central processor whether the account is authorized for a transaction for the particular transit type based on factors including the status of the account; if the account is authorized for a transaction for the particular transit type, communicating approval of pre-authorization to the transit processor; if the account is not authorized for a transaction for the particular transit type, communicating denial of pre-authorization to the transit processor; upon a determination that the redemption request is a fee redemption request: determining by the central processor whether value associated with the account is greater than or equal to the amount requested by the fee redemption request; if the value associated with the account is less than the amount requested by the fee redemption request, communicating a denial of the fee redemption request to the transit processor; if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: communicating approval of the fee redemption request to the transit processor; deducting the amount of the set fee redemption request from the account; determining whether the amount of value associated with the account is below a pre-determined threshold for one or more particular transit types, and if so, updating the status of the account at the data store.


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


Some aspects in accordance with some embodiments of the invention may include a method of conducting transit card transactions, the method conducted amongst a central processor comprising an account associated with a transit card and a data store comprising a status of the account, and a transit processor, the method the comprising: receiving at the central processor from the transit processor a redemption request including information identifying the transit card; determining by the central processor whether the redemption request is a pre-authorization request for a particular transit type or a fee redemption request; upon a determination that the redemption request is a pre-authorization request: determining by the central processor whether the account is authorized for a transaction for the particular transit type based on factors including the status of the account; if the account is authorized for a transaction for the particular transit type, communicating approval of pre-authorization to the transit processor; if the account is not authorized for a transaction for the particular transit type, communicating denial of pre-authorization to the transit processor; upon a determination that the redemption request is a fee redemption request: determining by the central processor whether value associated with the account is greater than or equal to the amount requested by the fee redemption request; if the value associated with the account is less than the amount requested by the fee redemption request, determining if exit from the particular transit type used in the fee redemption is necessary; if exit is necessary, authorizing the transaction for the total amount of value in the account and deducting the fee redemption request from the account, thereby causing a negative balance in the account; if exit is not necessary, communicating a denial of the fee redemption request to the transit processor; if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: communicating approval of the fee redemption request to the transit processor; deducting the amount of the set fee redemption request from the account; determining whether the amount of value associated with the account is below a pre-determined threshold for one or more particular transit types, and if so, updating the status of the account at the data store.


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


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.





BRIEF DESCRIPTION OF THE DRAWING

The present invention can be more fully understood by reading the following detailed description together with the accompanying drawings, in which like reference indicators are used to designate like elements. The accompanying figures depict certain illustrative embodiments and may aid in understanding the following detailed description. Before any embodiment of the invention is explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. The embodiments depicted are to be understood 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 make reference to the following figures, in which:



FIG. 1A illustrates an exemplary arrangement of a transit use card with a transit reload card, in accordance with some embodiments of the present invention.



FIG. 1B illustrates an exemplary method of activating a transit use card and a transit reload card, in accordance with some embodiments of the present invention.



FIG. 2 illustrates an exemplary association between a transit use card, a transit reload card, and an account, in accordance with some embodiments of the present invention.



FIG. 3 illustrates an exemplary association between a transit use card, a transit reload card, and an account, in accordance with some embodiments of the present invention.



FIG. 4 illustrates an exemplary account arrangement with various purses, in accordance with some embodiments of the present invention.



FIG. 5 illustrates an exemplary method of conducting a transaction with a transit use card, in accordance with some embodiments of the present invention.



FIG. 6 illustrates an exemplary method of conducting a reload transaction with a transit reload card, in accordance with some embodiments of the present invention.



FIG. 7 illustrates an exemplary method of conducting a sale of a transit use card, in accordance with some embodiments of the present invention.



FIG. 8 illustrates an exemplary reload transaction, in accordance with some embodiments of the present invention.



FIG. 9 illustrates an exemplary use transaction, in accordance with some embodiments of the present invention.



FIG. 10 illustrates an exemplary sale of a transit card, in accordance with some embodiments of the present invention.





Before any embodiment of the invention is explained in detail, it is to be understood that the present invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. The present invention is capable of other embodiments and of being practiced or 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 OF THE INVENTION

The matters exemplified in this description are provided to assist in a comprehensive understanding of various exemplary embodiments disclosed with reference to the accompanying figures. Accordingly, those of ordinary skill 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 functions and constructions are omitted for clarity and conciseness. Moreover, as used herein, the singular may be interpreted in the plural, and alternately, any term in the plural may be interpreted to be in the singular.


The present invention contemplates the use of a stored value account linked to at least one card. The card may be equipped with a near field transponder or tag (for example, an RFID (radio frequency identification) tag) such that payments can be made while in the proximity of a reader, or triggered upon a contact or “tap” with a reader. The card may be used on and/or with various transit systems and/or authorities. For example, a user may use the card to pay for subway fare, bus fare, taxi fare, road and/or bridge tolls, and/or any other sort of transit charge.


The card may comprise at least one indicia setting forth a serial number or other identifying number of the card. This indicia may be associated with the stored value account such that use of the card in a transit system results in decrementation of value from the stored value account.


In accordance with some embodiments of the present invention, a second card may also be associated with the stored value account, but may not be equipped with a near field transponder, reader, or tag. The second card may comprise a machine readable indicia (for example, a bar code or magnetic stripe) that may be associated with the stored value account. Using this association, the second card may be presented at various point of sale terminals and used to add value—rather than decrement value—to the stored value account.


In this manner, a degree of anonymity may be maintained for the user of the first card. Payments that may comprise identification information—for example, a credit or debit card (dda) payment—may only be associated with the second card. The use of the first card may or may not be by the same user that provided value to the stored value account.


In this manner, parties can provide transit cards for other parties. For example, parents can provide transit cards for their children. Employers may provide transit cards to employees either as a benefit or to encourage public transportation. In accordance with some embodiments of the present invention, state or federal agencies may provide transit cards to low income or other identified parties.


The two cards—the near-field enabled card and the machine readable reload card—may be married or otherwise associated with each other. This association may occur, for example, at the printer or manufacturer of the cards, or later by a central processing party or other third party entity. In accordance with some embodiments of the present invention, an unaffiliated card may be associated with the near-field enabled card rather than the machine readable card in order to effectuate payment from other sources. For example, a generic prepaid card—such as a Visa—may be associated with the near-field enabled card to provide payment to the underlying stored value account. In accordance with some embodiments of the present invention, other forms of value accounts may be associated. For example, customer rewards or loyalty points may be associated with a quantum of value and associated with the near-field transit card. Similarly, frequent flyer miles or other such value types may be associated.


It is contemplated by the present invention that the two cards—the near-field enabled card and the machine readable reload card—may be packaged and marketed together. For example, this may be—but is not required to be—in the same package. In accordance with some embodiments of the present invention, the cards may be distributed separately, such that the machine readable reload card may be distributed even to a different user in a different location, and subsequently linked or associated with the stored value account underlying the near-field enabled transit card. Such embodiments may, for example, be advantageous for the examples of parents, employers, and federal agencies discussed above.


In accordance with some embodiments of the present invention, the ratio of association between near-field enabled cards and machine-readable reload cards need not be one-to-one. In other words, a near-field enable transit card may access a stored value account that may be funded from more than one machine-readable reload card. Accordingly, a user of the transit card may add value to the underlying stored value card, and a third party (e.g., parent, employer, governmental agency, etc.) may also add value. Similarly, a single machine readable reload card may be linked to more than one transit card. In such embodiments, the multiple transit cards may each access and decrement the same stored value account, or they may each access and decrement their own account, and reload transactions using the machine-readable reload card may need to identify the specific account into which to add value.


With reference to FIG. 1, an exemplary packaging 100 of a transit use card 110 and a transit reload card 120 is depicted. The packaging 100 may comprise a transit use card 110 and a transit reload card 120. The packaging 100 may further comprise information 101 regarding an initial load value of the use card, if any, or may indicate that the use card can be loaded with any amount the user selects, provide options of amounts, etc. The packaging may also comprise a packaging indicia 102 that may be machine readable—for example, a bar code, QR code, magnetic strip, radio frequency identification (RFID) tag, etc. The packaging indicia 102 may be associated with the packaging 100, and may, as discussed in more detail below, be used to activate the use card 110 and the reload card 120. Alternatively, the packaging indicia 102 may not be used to activate the use card 110 and the reload card 120, but rather may be used merely as a stock keeping device for a merchant or retailer to track stock and sales. In this regard, the packaging indicia 102 may be considered to be, or used as, a stock keeping unit (SKU) or a universal price code (UPC).


The use card 110 may comprise one or more indicia, machine readable, communicable, or otherwise. For example, use card 110 may comprise a use card identifying indicia 111 that may identify the use card. With reference to FIG. 1, use card identifying indicia 111 indicates that the use card number is “1234 5678.” Use card 110 may further comprise a use card machine readable indicia 112, such as a magnetic strip, bar code, etc. Use card machine readable indicia 112 may incorporate, in whole or in part, use card identifying indicia 111, and may include additional information. For example, 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 properly routed. Alternatively, the use card machine readable indicia 112 may represent an indicia entirely different than the use card identifying indicia 111.


Note that use card 110 may further comprise elements 113, 114 that may have or otherwise provide communicative abilities to the use 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 devices. In this manner, the use card 110 may be “tapped” at certain POS systems rather than manually providing the identifying indicia 111 and/or swiping or reading the machine readable indicia 112.


The reload card 120 may similarly comprise a reload identifying indicia 121 that may uniquely or semi-uniquely identify the reload card 120. For example, with reference to FIG. 1, the reload identifying indicia 121 indicates that the reload card is identified by “ABCD EFGH.” Reload card 120 may further comprise one or more reload machine readable indicia 122, 123, comprising, for example, a magnetic stripe and/or a bar code. Such machine readable indicia 122, 123 may be used to identify the reload card 120 during reload transactions.


With reference to FIG. 1B, an exemplary activation process will now be discussed. At 130 a use card and reload card are associated together. This may occur after the cards are manufactured, or by associating or marrying indicia from each card in a database, regardless of when the cards are manufactured. At 135, the use card and the reload card may be associated with an activation indicia, for example, packaging indicia 102 as set forth in FIG. 1A. Alternatively, since the reload 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 card and the reload card may be packaged together, and at 145 the activation indicia may be printed or stored on the package. Alternatively, the packaging may be printed with an activation indicia which may—after packaging—be associated with the use card and the reload card.


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


Note that it is also contemplated that the use card and the reload card be sold in an “active” state, and that the activation transaction instead activates an underlying account, either by placing value in such account or releasing a hold directed at value in such account.


With reference to FIG. 2, an exemplary association between a transit use card, a transit reload card, and an account, in accordance with some embodiments of the present invention will now be discussed. As can be seen in FIG. 2, a use card 210 is associated with a reload card 220. The use card 210 is also associated with an underlying account 230. The account 230 may be a value account (such as 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. With reference to FIG. 2, the use card 210 is the primary card, and reload transactions using the reload card 220 may require an identification of the use card 210, and then the value account 230 associated with the use card 210.


In contrast, FIG. 3 illustrates an alternative exemplary association between a transit use card, a transit reload card, and an account, in accordance with some embodiments of the present invention. With reference to FIG. 3, a use card 310 and a reload card 320 are both associated with the account 330. Additional security and/or anonymity may be achieved through this arrangement. For example, a reload card 320 may have no connection to the use card 310, and the specifics of the cards use may not be known or obtainable to or by those with access to the reload card. As noted above, such arrangements may be desirable when the party possessing or utilizing the reload card 320 is different than the party possessing or using the use card 310.


It is also contemplated by the present invention that the account associated with the use card and/or the reload card may comprise one or more purses, which in turn may comprise one or more sub-purses. Such purses may have the same or different characteristics. For example, a transportation authority may wish to encourage people to use large-scale, high efficiency transportation, such as subways or rails. Accordingly, $1.00 in a purse for use in subways or rails may be worth $1.25. In contrast, $1.00 in a toll road purse, or parking purse may be equal to $1.00.


Through the use of different purse characteristics, parties may encourage or promote certain activities. If a parent provides a transit card to his or her child, the parent may desire the child use a car rental or ZIP Car service rather than purchase their own car. The parent may then provide a value characteristic of a car rental purse such that $1.00 is equivalent to $1.50, in order to encourage the child to use the car rental. Different value characteristics of purses may be desirable because what is encouraged for one or more users may not be encouraged system wide. Accordingly, rather than adjust the price of the services purchased with the transit card, the amount of value associated with each purse in the transit card may be adjusted on an individual basis (or as group).


For example, an account may comprise a purse directed at tickets or other liabilities that may be incurred during transit. If the transit card is utilized to pay the ticket, a value characteristic may encourage immediate or prompt payment of the ticket. For example, if a ticket is paid upon issuance using a transit card, $1.00 may be equivalent to $1.15. Such increase in value (or corresponding decrease in the amount of the ticket) may be validated by the decrease in administrative costs often associated with ticket payment collection.


In accordance with some embodiments, a use card may be used to provide for transit fees, or may be used to provide payment for a ticket; but not for both. Alternatively, a transit card may be used for transit fees, but once used to pay for a ticket the transit card may be rendered inactive and a new transit card may be obtained.


With reference to FIG. 4, an account 40 may comprise one or more purses. For example, account 40 may comprise a toll road purse 410, a parking purse 420, a taxi purse 430, a ticket/liability purse 440, and a car rental/ZIP car purse 450. Similarly, account 40 may also comprise a public transportation purse 460, which may in turn comprise a bus sub-purse 461 and a subway/rail sub-purse 462. As noted above, each of these purses may comprise different value characteristics.


Such purses may be individually funded (or, for example, by the designation of funds by a party loading or reloading the account), or may be funded evenly or according to a general use algorithm which may take into account average prices, average uses, etc. Alternatively, the purses may not hold value in individual sub-accounts, but may merely reflect how value is treated when used in specific transactions. In other words, the public transportation purse 460 may not specifically hold value, but may indicate that if value associated with the overall account 40 is used in a public transportation context, that certain value characteristics should be applied.


With reference to FIG. 5, an exemplary method 50 of conducting a transaction with a transit use card, in accordance with some embodiments of the present invention will now be discussed. At 510 a transaction may be initiated at a point of sale (POS). Note that a POS may include a traditional register at a retailer, merchant, or provider of goods and/or services. A POS may further include a meter in a taxi, a fare-box in a bus, a kiosk, a turnstile (for example, at the entrance to a subway system), a parking meter or other meter, a toll booth, a toll collection device that utilizes wireless communications (such as near-field communications utilized by EZPass, EZTag, FastTrak, etc.), and/or any other system in which value is provided in a payment transaction for goods and/or services.


At 520, the use card may be presented at the POS as tender for goods and/or services. Again, the presentment of the use card may be dependent upon the type of POS conducting the transaction. A transaction at a traditional register may be performed by swiping a magnetic stripe on a use card, or reading a bar code or other machine readable indicia thereon. A transaction at a fare-box may be performed with a near-field communication, and the customer may merely tap the use card on a near-field reader. A transaction at a parking meter may involve swiping a use card, or may involve the provision of an indicia on the use card into the meter by a user. The use card may be presented at a highway toll by associating the use card with a device that can be read by the toll system, for example, associating or inserting the use card into a transponder element used in the toll system. Note that the above paragraph is not intended to be limiting, but rather to explain the breadth of what is contemplated by the present invention.


At 530 the POS may capture the use indicia on the use card. As noted above, this indicia may be captured in a variety of manners.


At 540 the POS or a processor associated with the POS (such as a POS host or other central element) may determine a processor or issuer associated with the use card (a “central processor”). Such determination may be based, for example, an IIN or BIN as noted above.


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


At 560 the central processor may receive the information from the POS or a processor associated with the POS, and at 561 the central processor may determine if the use indicia is valid. If the use indicia is not valid, then the central processor may deny the transaction at 563. If the use indicia is valid, the central processor may then identify an account associated with the use indicia and the value, if any, therein. The central processor may then determine if 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 at 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 decremented from the account at 565. The central processor may then communicate with the POS in order to instruct the POS to continue with the transaction, and at 570 the POS may conduct the transaction.


Note that in order to perform real-time or near-real-time transactions, certain heuristics or short-cuts may be utilized by the central processor. For example, and as discussed in greater detail below, the central processor may maintain a negative database that comprises use indicia associated with accounts that either have no value, insufficient value to obtain any goods and/or services, or accounts that have been associated with some type of fraud. Such negative database may be initially queried by the central processor in order to timely reject transactions associated with such use indicia. Alternatively, the POS systems themselves may be periodically updated with the negative database such that the POS itself can deny a transaction immediately if an indicia listed in the negative database is identified.


With reference to FIG. 6, an exemplary method 60 of conducting a reload transaction with a transit reload card, in accordance with some embodiments of the present invention will now be discussed. A reload transaction may be initiated at a POS at 610. The POS may comprise a variety of POS systems as noted above, including an electronic or computerized kiosk. It is also contemplated that a reload transaction may be performed at a POS unrelated to the goods and/or services purchased by the transit use card. In other words, while the use card may be used at a road toll or parking space, the reload card may be used to replenish the underlying account at a convenience store, a big-box store, a web-site or other digital storefront, an application or applet running on a mobile computing device or mobile communication device (for example, a mobile telephone, smart phone, table computer, laptop computer, navigation system, etc.).


At 611, the POS may capture or otherwise obtain the reload indicia on the reload card. The POS may capture this indicia by, for example, reading a machine readable indicia on the reload card such as a magnetic stripe, bar code, RFID tag, etc. Alternatively, the POS may obtain the reload indicia by a user manually entering the reload indicia, for example in the case of an on-line reload transaction or through the use of a mobile computing device or mobile communication device.


It is also contemplated that reload transactions may be conducted over the telephone, for example by communicating with an interactive voice response (IVR) system.


At 612, the POS or a processor associated with the POS (such as a POS host or other central element) may determine a processor or issuer associated with the reload card (the “central processor”). Such determination may be based, for example, an IIN or BIN as noted above. Note that the discussion herein assumes that the central processor that governs reload transactions is the same central processor that governs use transactions. However, it is contemplated that two or more processors may be used, or a single processor may be partitioned to act as two distinct processors. The discussion focuses on a single central processor for clarity, but the invention fully contemplates a division of labor based upon transaction type (reload compared to use or redemption) amongst one or more processors.


At 613, the POS may receive from the customer an amount with which to reload the underlying account associated with the reload card (and accordingly, associated with the use card). The customer may, in accordance with some embodiments, select any amount of value. In accordance with some embodiments, the customer may be presented with reload options, which may be based on currency amounts (e.g., $10, $25, $50) or may be based on specific uses (e.g., 20 subway trips, one (1) month of road tolls, etc.). It is further contemplated by the present invention that a transit system may provide an option of a single payment for an “all-you-can-eat” model, wherein a customer may pay an amount (e.g., $250) for a month of all transit uses, including for example, subways, buses, light-rail, road tolls, and certain limited parking.


At 614 the POS or a processor associated with the POS may communicate with the central processor and provide the reload indicia and the amount of value that is to be inserted into the underlying account.


At 620 the central processor may receive this information, and at 630 the central processor may determine if the reload indicia is valid. If the reload indicia is invalid, the transaction may be denied. If the reload indicia is valid, the reload transaction may be performed in a variety of manners. For example, if the associative structure of the use card, reload card, and underlying account is that as indicated in FIG. 2, the central processor may determine the use indicia associated with the reload indicia at 641, and then at 642 determine the account associated with the use indicia. At 643 the central processor may then increase the amount available in the account associated with the use indicia by the reload amount. If the associative structure of the use card, reload card, and underlying account is that as indicated in FIG. 3, the central processor may determine the account associated with the reload indicia at 650 and add the amount of reload value into this account at 651.


These two manners are not intended to be limiting, but rather to illustrate the variations contemplated by the present invention based upon various associations between and amongst the various cards, accounts, indicia, etc.


At 660 the central processor may send a confirmation to the POS that the reload transaction was successful. At 615 the POS may pass on a confirmation to the user that the reload transaction was 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.


Subsequently, 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 manners, including for example automated clearing house (ACH) transactions.


Providing a reload transaction may also have an impact on the heuristics of the system. For example, as noted above a use card or indicia may be placed on a negative database due to insufficient funds. Accordingly, upon a reload transaction, the central processor may at 680 cause an activation of the use indicia, thereby removing it from the negative database. If the account was in arrears, at 690 the amount of arrears may be deducted from the underlying account before rendering the use indicia available for use.


With reference to FIG. 7, an exemplary method 70 of conducting a sale of a transit use card, in accordance with some embodiments of the present invention, will now be discussed. Before discussing the individual steps, it is important to note that while numerous steps are shown in FIG. 7 and explained below, each step is not necessarily required. Rather, the method 70 as set forth in FIG. 7 may be representative of a specific arrangement and sale process; various steps may be deleted and/or added to the process without deviating from the invention.


At 701 a consumer may select a transit use card for purchase. The transit use card may be preassociated with a reload card, or may be individually sold with a pre-set value. In the case of a pre-set value, a reload may be purchased at a later time and subsequently associated with the use card and the underlying account associated with the use card. At 702, the customer may present the card to at the POS for purchase, and at 703 the POS may capture or otherwise receive an indicia off of the use card in order establish the sale of the use card.


If the use card is not preloaded with a pre-set value, at 704 the customer may be prompted to provide a load amount. The customer may be prompted through a digital communication (for example, on a screen of a kiosk, over the phone, through a text (SMS, MMS) message, etc.), or may be prompted by a sales associate asking the customer how much value to load.


At 705 the customer may tender the total amount to the POS. The total amount may include an initial fee of purchasing the card, and/or any additional taxes, fees, or charges that may be applicable and/or required.


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


Optionally, at 712, the customer may be directed to register the use card via the Internet or via an IVR system 713. If the customer selects IVR it may linked to an IVR registration system at 714, and if the customer selects web or Internet it may linked to a web registration system at 715.


Registration may be encouraged for several reasons. If a use card is registered and misplaced, a customer may request that the central processor disable the use card and provide a replacement card in its stead. If a use card is registered, a reload card may be more easily associated with the use card. Moreover, if a use card is registered, a customer may have an option to associate a payment device such as a credit card, debit card (or other open-loop or semi-open-loop type card), checking account, etc. with the use card, such that when the balance in the account underlying the use card is decremented below a certain level, a recharge of a specified amount may be automatically performed.


It is also contemplated by the present invention that the use card may be a combined purpose card with closed-loop functionality to operate within a transit system, and open loop functionality to operate outside of the transit system. For example, a prepaid Visa Card may be equipped with a closed-loop purse that may be utilized within a transit system. In such circumstances, when the closed-loop purse falls below a certain level, the closed-loop purse may be automatically recharged from the open-loop side of the product.


With reference to FIG. 8, a method 80 of an exemplary reload 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 reload transaction. It is anticipated that the customer may present a reload card, though it is also contemplated that the customer may present the use card for direct reload. At 805 the POS may receive from the customer the an indicia from the card, and at 810 the POS may receive the amount of reload sought by the customer. At 815 the POS may receive actual tender of the reload amount (plus any applicable taxes, fees, charges, etc.). At 820 the POS (or a POS host or other processor associated with the POS) may send a reload request to the central processor. At 825 the central processor may receive the reload request and at 830 the central processor may determine if the indicia identifying the card is valid, and the card is active. If the card is determined to be inactive at 835, then the process may be routed as an initial activation process at 840, much as discussed above. If the indicia is valid and the card is active as determined at 845, the central processor may identify the underlying account at 850.


At 855 the central processor may determine if the underlying account is in arrears, or if the associated cards and account are listed in the negative database. If the card and/or account is flagged in the negative database at 865, provided the reload amount is sufficient to remove the account from an arrears status the listing in the negative database will be removed at 870. If the card and/or account is determined as not being listed in the negative database at 860, or following the removal of the negative flag at 870, the central processor may add value to the underlying card account. The value may be the specific reload value specified by the customer, or may be the reload value specified by the customer less any applicable or required fees, taxes, charges, etc.


At 880 the central processor may send a message indicating success of the reload transaction to the POS, POS host, or processor associated with the POS, and the POS may then convey a confirmation of the reload transaction to the customer at 885.


With reference to FIG. 9, an exemplary use transaction 90, in accordance with some embodiments of the present invention will now be discussed. As with previous methods discussed, note that various steps may be omitted or added to the method discussed below, without deviating from the invention.


With reference to FIG. 9, the method is directed to circumstances where the final amount to be charged to the customer's use card may not be known until the customer completes his or her travel. For example, prices for subway rides may vary based upon the route, distance, and/or duration of the ride. Similarly, road tolls are often related to the overall distance traveled on the toll road, or to the municipalities passed through on the toll road. Similarly still, a customer may travel within a transit system (bus to subway, subway to light rail, light rail to parking) and be charged at the end of the travels rather than for each leg along the way. Accordingly, the method as set forth in FIG. 9 may illustrate a situation where the POS may grant access to the customer and then later charge the full amount of the customer's travels against the use card.


At 901 a customer may present a use card at a POS. Again, the POS can take many forms as noted above. At 902 the POS may, at the entrance to the transit system or specific transit device (e.g., taxi, subway, bus, toll road, etc.) capture or otherwise receive an indicia from the use card. The POS may validate the indicia against a negative database at 903 to determine if the card is associated with an invalid card, or one associated with an underlying account that is in arrears, has a zero balance, or has a balance insufficient to pay for any goods and/or services in the transit system. For example, a card may have a balance of $0.78, but a minimum bus ride, subway trip, toll road, or taxi fare may be $1.10.


If the card is listed on the negative database, at 904, the transaction may be denied at 905 and the customer prevented from entering the transit device. Prevention may comprise a locked turnstile, a gate that does not rise at a toll booth, or a bus driver preventing entrance.


Such local preauthorization of the card may be desirable in that it allows a POS to effectively screen riders who are unlikely to provide adequate payment for services, without requiring timely communications with the central processor. The central processor may periodically update the POS systems, for example by reaching into a database queried by the POS and modifying the listing of cards and/or accounts in the negative or positive database.


If the POS determines that the card is not listed on the negative database at 906 (or alternatively and equivalently listed on a positive database), the customer may be admitted 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 the total charge for the trip the customer traveled, and at 911 the POS (or a POS host or a processor associated with the POS) may send the total charge and the indicia captured or otherwise obtained from the use card to the central processor.


At 912 the central processor may determine if the card number is valid. If it is determined at 913 that the card number or indicia is not valid, then the card, indicia, or underlying account may be added to the negative database at 914. If it is determined that the card number is valid at 915, then the central processor may identify the underlying account at 916, and determine the amount of value in the underlying account at 917.


At 918, the central processor may determine if the amount of value in the underlying account is equal to or greater than the total charge. If the amount in the account is determined to be less than the total charge at 919, then at 920 the central processor may determine if a source of automatic reload is associated with the use card or underlying account. If there is no source of automatic reload at 921, then at 922 the central processor may deduct all available funds from the underlying account, and note the amount the underlying account is in arrears. The process may then move to step 914, where the card, indicia, or underlying account may be added to the negative database.


If it is determined at 923 that there is an identified automatic reload associated with the use card or underlying account, then the central processor may request a reload transaction with the identified value source at 924. If it is determined at 925 that the reload transaction is unsuccessful, then the process may be returned to step 922 where all available funds are deducted from the account and the card, indicia, or underlying account may be listed in the negative database.


If it is determined at 926 that the reload transaction was successful, then the process may continue.


Whether the reload transaction was successful in 926, or the amount in the underlying account was greater than or equal to the total charge as determined at step 918, the central processor may then deduct or decrement the amount of value in the account by the total charge at 927. At 928 the central processor may then determine if the balance remaining in the underlying account is too low to pay for any goods and/or service in the transit system (as noted above), and if at 929 the account is deemed too low for use, the card, indicia, or underlying account may be listed in the negative database at 914.


If it is determined at 930 that the amount remaining in the account is acceptable (that is, over a minimum threshold established that would allow for the purchase of at least some goods and/or services from the transit system), then the transaction is concluded at 931.


With reference to FIG. 10, an exemplary sales process 1000 of a transit card, in accordance with some embodiments of the present invention will now be discussed. Note that the method disclosed in FIG. 10 is exemplary only, and various steps may be added or omitted from the process. The method set forth in FIG. 10 is somewhat specific, as it is intended to disclose what an actual transaction may include; however, the invention as set forth herein and claimed may not require each of the elements or steps set forth in FIG. 10.


At 1001 a customer may visit a POS location, for example, an electronic or automated kiosk. At 1002 a customer may choose to purchase a transit card by utilizing a customer interface at the kiosk. At 1003, the customer may enter the amount to fund the transit card with, and at 1004 the customer may choose or select a payment method. The customer may pay for the transit card using cash, credit, debit, and/or any other value type accepted by the kiosk. The customer may pay the amount to be funded on the transit card, or may pay more, after required or appropriate taxes, expenses, charges, and/or fees are applied to the purchase transaction. The kiosk customer may, for example, at 1005 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 sequentially, according to an algorithm, random, or semi-random) and at 1007 the kiosk may send a pre-authorization request to a gateway of the central processor. At 1008 the gateway of the central processor may send the preauthorization request to the proper platform of the central processor, which may at 1009 perform preauthorization activation validations. At 1010 the central processor platform may respond to the central processor gateway, which in turn may transmit at 1011 a communication back to the kiosk.


At 1012, if the preauthorization transaction was not successful, then at 1013 the kiosk may present the customer with a friendly failure message, requesting the customer try again.


If the preauthorization transaction was successful, then at 1014 the kiosk may send a payment request to the merchant acquirer associated with the payment card presented by the customer. At 1015 the merchant acquirer may process the payment and send a response to the kiosk. At 1016 the kiosk may determine if the payment request was successful, and if not the customer may be presented with friendly failure message as in step 1013. If the payment request was successful then the kiosk may send an activation request with the load amount 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 with the amount requested, and at 1020 the central processor platform may provide confirmation of the same to the central processor gateway.


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


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


The exemplary method as set forth in FIG. 10 and the discussion above is transacted amongst several parties: a customer; a kiosk (or retailer); a central processor that issues and supports the transit card; and a payment source. It is contemplated by the present invention that the kiosk may be maintained, run by, or associated with the central processor thereby rendering some of the communications discussed above unnecessary. It is also contemplated that in the case of a cash purchase, the communications discussed above and illustrated in FIG. 10 that include the merchant acquirer may be unnecessary.


In other words, various modifications, alterations, and changes may be made, depending on the type of transaction, the identity and number of parties, the relationships amongst the parties, and/or a variety of other factors.


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

Claims
  • 1. A method of conducting a transit use card transaction, the method conducted amongst a central processor comprising an account associated with a transit use card and a data store comprising a status of the account, a point of sale (POS), and one or more transit system payment devices, the method comprising: adding value to the transit use card using a separate transit reload card, the separate transit reload card being associated with an account accessible by the transit use card and usable only to add value to the account but being incapable of accessing and using funds in the account, the funds accessible by the transit use card, the separate transit reload card comprising an identifying indicia, such that a POS is configured to receive the identifying indicia of the transit reload card during a reload transaction;activating the transit use card and the transit reload card using an indicia disposed on packaging, the packaging containing the transit use card and transit reload card together;receiving by the central processor from the transit system payment device an indicia including information identifying the transit use card at an entrance to a particular transit device of a particular transit type, the transit use card being used to pay value for any fare, toll, or any other sort of transit charge from the account;preauthorizing use of the card by determining by the transit system payment device whether the indicia is valid for the transit use card transaction for the particular transit type of the transit device based on factors including the status of the account, wherein the status of the account includes whether or not the amount of value associated with the account is over a minimum threshold established that would allow for the purchase of at least some goods or services from the particular type of the transit device;if the transit system payment device determines that the status of the account is not authorized for transit use card transaction for the particular transit type of the transit device, denying the transaction and preventing a customer of the transit use card from entering the transit device;if the transit system payment device determines that the indicia is valid for the transit use card transaction for the particular transit type of the transit device, admitting the customer of the transit use card to the transit device;determining by the central processor whether value associated with the account is greater than or equal to the amount requested by a fee redemption request for the transit use card transaction from the transit system payment device;if the value associated with the account is less than the amount requested by the fee redemption request, communicating a denial of the fee redemption request to the requesting transit system payment device;if the value associated with the account is greater than or equal to the amount requested by the fee redemption request: communicating approval of the fee redemption request to the requesting transit system payment device;deducting the amount of the fee redemption request from the account.
  • 2. The method of claim 1, wherein the indicia including information identifying the transit use card comprises a machine readable indicia printed or stored on the transit use card.
  • 3. The method of claim 1, further comprising: receiving at the central processor from a retailer point of sale (POS) an activation request comprising information identifying the transit use card;determining by the central processor: if the indicia including the information identifying the transit use card is valid; andthe account associated with the transit use card; andactivating the transit use card by the central processor.
  • 4. The method of claim 3, wherein the transit use card and a reload card are disposed 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 particular transit type of the transit device is selected from the group consisting of: a taxi, a bus, a subway, a road or bridge toll, a parking meter, a train or light rail, a trolley, and a car rental.
  • 6. The method of claim 1, wherein the transit processor is centrally located amongst a transit system.
  • 7. The method of claim 1, wherein the transit processor is associated with a particular transit type.
  • 8. The method of claim 1, wherein the transit processor is associated with a specific point of sale processor.
  • 9. The method of claim 1, further comprising: upon a determination by the central processor that exit from the particular transit type used in a fee redemption request is necessary, and that the value associated with the account is less than the amount requested by the fee redemption request:authorizing the transit use card transaction for the total amount of value in the account; anddeducting the amount of the fee redemption request from the account, thereby causing a negative balance in the account.
  • 10. The method of claim 1, wherein the method is performed in real or near real-time.
  • 11. The method of claim 1, wherein the fee redemption request is associated with a citation for parking, driving, or toll violation.
  • 12. The method of claim 11, further comprising: upon payment of the citation using the account, terminating the account thereby rendering the transit card invalid for future use.
Parent Case Info

The present invention claims priority to U.S. Provisional Patent Application No. 61/680,802, filed on Aug. 8, 2012, which is incorporated herein in its entirety.

US Referenced Citations (234)
Number Name Date Kind
3288350 Kushner Nov 1966 A
5091634 Finch et al. Feb 1992 A
5128520 Rando Jun 1992 A
5231569 Myatt Jul 1993 A
5256863 Ferguson Oct 1993 A
5375240 Grundy Dec 1994 A
5416306 Imhata May 1995 A
5602377 Beller et al. Feb 1997 A
5619559 Kennedy Apr 1997 A
5671279 Elgamal Sep 1997 A
5708780 Levergood Jan 1998 A
5729693 Holda-Fleck Mar 1998 A
5740915 Williams Apr 1998 A
5754981 Veeneman May 1998 A
5765143 Sheldon Jun 1998 A
5804803 Cragun Sep 1998 A
5850217 Cole Dec 1998 A
5857175 Day Jan 1999 A
5897625 Gustin Apr 1999 A
5903633 Lorsch May 1999 A
5907142 Kelsey May 1999 A
5950173 Perkowski Sep 1999 A
5968110 Westrope Oct 1999 A
6014635 Harris Jan 2000 A
6029139 Bezos Feb 2000 A
6039244 Finsterwald Mar 2000 A
6085167 Iguchi Jul 2000 A
6085242 Chandra Jul 2000 A
6119099 Walker Sep 2000 A
6125352 Franklin Sep 2000 A
6134533 Shell Oct 2000 A
6138911 Fredregil Oct 2000 A
6154738 Call Nov 2000 A
6222914 McMullin Apr 2001 B1
6304860 Martin Oct 2001 B1
6315193 Hogan Nov 2001 B1
6317028 Valiulis Nov 2001 B1
6360254 Linden Mar 2002 B1
6418414 Lutz et al. Jul 2002 B1
6418441 Call Jul 2002 B1
6422462 Cohen Jul 2002 B1
6424706 Katz et al. Jul 2002 B1
6442532 Kawan Aug 2002 B1
6473739 Showghi et al. Oct 2002 B1
6507823 Nel Jan 2003 B1
6529956 Smith Mar 2003 B1
6536659 Hauser Mar 2003 B1
6609106 Robertson Aug 2003 B1
6648222 McDonald et al. Nov 2003 B2
6675153 Cook et al. Jan 2004 B1
6829596 Frazee Dec 2004 B1
6834796 Anvekar et al. Dec 2004 B2
6852031 Rowe Feb 2005 B1
6886742 Stoutenburg et al. May 2005 B2
6915277 Manchester et al. Jul 2005 B1
6965866 Klein Nov 2005 B2
6993510 Guy Jan 2006 B2
7003499 Arditti et al. Feb 2006 B2
7063251 Namekawa Jun 2006 B2
7086586 Sullivan Aug 2006 B1
7108183 Cox, Jr. Sep 2006 B1
7216092 Weber May 2007 B1
7252226 Risafi et al. Aug 2007 B2
7363265 Horgan Apr 2008 B2
7434729 Cracchiolo et al. Oct 2008 B2
7475028 Loeb Jan 2009 B2
7494417 Walker Feb 2009 B2
7513422 Tucker Apr 2009 B1
7590557 Harrison Sep 2009 B2
7631803 Peyret et al. Dec 2009 B2
7702542 Aslanian Apr 2010 B2
7757944 Cline Jul 2010 B2
7769695 Robinson Aug 2010 B2
7922083 Harrison Apr 2011 B2
7970626 Cracchiolo Jun 2011 B2
8036953 Hsu Oct 2011 B2
8103520 Mueller Jan 2012 B2
8181867 Bierbaum et al. May 2012 B1
8245910 Sullivan et al. Aug 2012 B2
8265950 Howe Sep 2012 B2
8332277 Mccaffery et al. Dec 2012 B2
8577735 Wilen Nov 2013 B2
8636203 Patterson Jan 2014 B1
9098190 Zhou Aug 2015 B2
9483786 Glass Nov 2016 B2
9672687 Cage Jun 2017 B2
20010034609 Dovolis Oct 2001 A1
20010037264 Husemann et al. Nov 2001 A1
20010056410 Ishigaki Dec 2001 A1
20020010627 Lerat Jan 2002 A1
20020016749 Borecki et al. Feb 2002 A1
20020062249 Iannacci May 2002 A1
20020065713 Awada et al. May 2002 A1
20020070270 Narita et al. Jun 2002 A1
20020088855 Hodes Jul 2002 A1
20020091573 Hodes Jul 2002 A1
20020130176 Suzuki Sep 2002 A1
20020138573 Saguy Sep 2002 A1
20020153410 Santini Oct 2002 A1
20020198737 Valtanen Dec 2002 A1
20020198831 Patricelli et al. Dec 2002 A1
20030004802 Callegari Jan 2003 A1
20030009382 D'Arbeloff Jan 2003 A1
20030069846 Marcon Apr 2003 A1
20030105688 Brown et al. Jun 2003 A1
20030121967 Goldberg et al. Jul 2003 A1
20030149573 Lynton Aug 2003 A1
20030163787 Hay et al. Aug 2003 A1
20030172039 Guy Sep 2003 A1
20030197059 Tidball et al. Oct 2003 A1
20030234819 Daly et al. Dec 2003 A1
20040010449 Berardi et al. Jan 2004 A1
20040065726 McGee et al. Apr 2004 A1
20040117302 Weichert et al. Jun 2004 A1
20040153344 Bui Aug 2004 A1
20040185881 Lee Sep 2004 A1
20040193490 Pletz Sep 2004 A1
20040225560 Lewis et al. Nov 2004 A1
20040267663 Karns Dec 2004 A1
20050021458 Rowe Jan 2005 A1
20050027624 Cai Feb 2005 A1
20050045732 Whitaker Mar 2005 A1
20050086100 Yanagisawa Apr 2005 A1
20050086168 Alvarez Apr 2005 A1
20050108121 Gravett et al. May 2005 A1
20050116028 Cohen Jun 2005 A1
20050125300 Mcgill et al. Jun 2005 A1
20050182695 Lubow et al. Aug 2005 A1
20050199705 Beck et al. Sep 2005 A1
20050261968 Randall et al. Nov 2005 A1
20050274793 Cantini Dec 2005 A1
20060004631 Roberts et al. Jan 2006 A1
20060010007 Denman Jan 2006 A1
20060035631 White et al. Feb 2006 A1
20060037835 Doran Feb 2006 A1
20060041470 Filho et al. Feb 2006 A1
20060053056 Alspach-Goss et al. Mar 2006 A1
20060078100 Risafi et al. Apr 2006 A1
20060080174 Veeneman Apr 2006 A1
20060089160 Othmer Apr 2006 A1
20060113376 Reed et al. Jun 2006 A1
20060212345 Soza Sep 2006 A1
20060253320 Heywood Nov 2006 A1
20060255125 Jennings Nov 2006 A1
20060261150 Seifert et al. Nov 2006 A1
20060271423 Hiranoya Nov 2006 A1
20060277146 Dively et al. Dec 2006 A1
20070011025 Cracchiolo Jan 2007 A1
20070017975 Lewis et al. Jan 2007 A1
20070021969 Homeier-Beals Jan 2007 A1
20070030824 Ribaudo Feb 2007 A1
20070038577 Werner Feb 2007 A1
20070043682 Drapkin et al. Feb 2007 A1
20070055785 Stevens Mar 2007 A1
20070156436 Fisher Apr 2007 A1
20070125838 Law et al. Jun 2007 A1
20070136149 Woodward et al. Jun 2007 A1
20070162338 Lawe Jul 2007 A1
20110060904 Whitfield Jul 2007 A9
20070192182 Monaco et al. Aug 2007 A1
20070198433 McGee et al. Aug 2007 A1
20070214080 Babi et al. Sep 2007 A1
20070251995 Kingsborough et al. Nov 2007 A1
20070265872 Robinson Nov 2007 A1
20080028395 Motta et al. Jan 2008 A1
20080040265 Rackley Feb 2008 A1
20080052169 O'Shea et al. Feb 2008 A1
20080059226 Melker Mar 2008 A1
20080059318 Packes et al. Mar 2008 A1
20080078831 Johnson et al. Apr 2008 A1
20080097851 Bemmel et al. Apr 2008 A1
20080114696 Singh et al. May 2008 A1
20080116264 Hammad May 2008 A1
20080133351 White et al. Jun 2008 A1
20080179395 Dixon Jul 2008 A1
20080186174 Alexis et al. Aug 2008 A1
20080209511 Silverbrook Aug 2008 A1
20080255942 Craft Oct 2008 A1
20080319868 Briscoe Dec 2008 A1
20090037326 Chitti et al. Feb 2009 A1
20090076896 Dewitt Mar 2009 A1
20090078755 Sullivan et al. Mar 2009 A1
20090094126 Killian et al. Apr 2009 A1
20090111378 Sheynman Apr 2009 A1
20090112709 Barhydt et al. Apr 2009 A1
20090144161 Fisher Jun 2009 A1
20090157487 Cottrell et al. Jun 2009 A1
20090164329 Bishop et al. Jun 2009 A1
20090164375 Saunders et al. Jun 2009 A1
20090171739 De et al. Jul 2009 A1
20090172551 Kane Jul 2009 A1
20090187491 Bull Jul 2009 A1
20090192904 Patterson et al. Jul 2009 A1
20090192928 Abifaker Jul 2009 A1
20090247131 Champion Oct 2009 A1
20090254432 Mccaffery et al. Oct 2009 A1
20090281941 Worth Nov 2009 A1
20090287558 Seth et al. Nov 2009 A1
20090298427 Wilkinson Dec 2009 A1
20090314833 Ruiz Dec 2009 A1
20100010906 Grecia Jan 2010 A1
20100041368 Kumar Feb 2010 A1
20100057580 Raghunathan Mar 2010 A1
20100082490 Rosenblatt Apr 2010 A1
20100088188 Kumar et al. Apr 2010 A1
20100131415 Sartipi May 2010 A1
20100185461 Broeska et al. Jul 2010 A1
20100185505 Sprogoe Jul 2010 A1
20100205063 Mersky Aug 2010 A1
20100235290 Junger Sep 2010 A1
20100293536 Nikitin Nov 2010 A1
20100299194 Snyder et al. Nov 2010 A1
20100304852 Szrek Dec 2010 A1
20100312636 Coulter et al. Dec 2010 A1
20110035268 Rossi Feb 2011 A1
20110040684 Beck et al. Feb 2011 A1
20110106698 Isaacson May 2011 A1
20110161226 Courtion Jun 2011 A1
20110165866 Dixon Jul 2011 A1
20110166992 Dessert et al. Jul 2011 A1
20110202419 Mamdani Aug 2011 A1
20110234514 Gothard Sep 2011 A1
20110246284 Chaikin Oct 2011 A1
20120136780 El-Awady May 2012 A1
20120209688 Lamothe et al. Aug 2012 A1
20120271689 Etheredge Oct 2012 A1
20130073388 Heath Mar 2013 A1
20130179177 Dhavle et al. Jul 2013 A1
20130290121 Simakov Oct 2013 A1
20130304561 Warner et al. Nov 2013 A1
20140006268 Roberts Jan 2014 A1
20140019238 Blatchley Jan 2014 A1
20150278845 Sorem et al. Oct 2015 A1
20170076293 Cage Mar 2017 A1
Foreign Referenced Citations (14)
Number Date Country
102609839 Jul 2012 CN
1164777 Dec 2001 EP
1705610 Sep 2006 EP
1806705 Jul 2007 EP
2034435 Mar 2009 EP
2128809 Dec 2009 EP
2002189963 Jul 2002 JP
2003208541 Jul 2003 JP
2008541303 Nov 2008 JP
2010521017 Jun 2010 JP
20020027427 Apr 2002 KR
03075231 Sep 2003 WO
2005086878 Sep 2005 WO
2011079066 Jun 2011 WO
Non-Patent Literature Citations (2)
Entry
Alliance, Smart Card. “A Guide to Prepaid Cards for Transit Agencies.” A Smart. 2011. (Year: 2011).
PCT International Search Report dated Dec. 30, 2013 for PCT/US13/53734.
Related Publications (1)
Number Date Country
20140046737 A1 Feb 2014 US
Provisional Applications (1)
Number Date Country
61680802 Aug 2012 US