CA2710341A1 - Systems, methods and computer program products for performing mass transit merchant transactions - Google Patents
Systems, methods and computer program products for performing mass transit merchant transactions Download PDFInfo
- Publication number
- CA2710341A1 CA2710341A1 CA2710341A CA2710341A CA2710341A1 CA 2710341 A1 CA2710341 A1 CA 2710341A1 CA 2710341 A CA2710341 A CA 2710341A CA 2710341 A CA2710341 A CA 2710341A CA 2710341 A1 CA2710341 A1 CA 2710341A1
- Authority
- CA
- Canada
- Prior art keywords
- account
- status
- financial transaction
- mass transit
- processor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/352—Contactless payments by cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
Abstract
Methods, systems and computer program products are provided for enabling access to mass transit systems using a financial transaction instrument including reading an identifier including financial payment information from the financial transaction instrument and determining whether the identifier is stored in a database.
Access to a holder of the financial transaction instrument is provided based on the determining.
Access to a holder of the financial transaction instrument is provided based on the determining.
Description
TITLE
SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR
PERFORMING MASS TRANSIT MERCHANT TRANSACTIONS
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to, and the benefit of, U.S.
Provisional Patent Application Serial No. 61/016,069, filed December 21, 2007, which is hereby incorporated by reference in its entirety.
BACKGROUND
Field [0002] Example aspects of the present invention generally relate to mass transit fare collection systems, and more particularly to leveraging such collection systems to utilize financial transaction devices.
Related Art [0003] Regular commuters as well as infrequent mass transit riders would like the convenience of not requiring a separate payment device for paying transit fares. Particularly in today's "plastic economy", riders are anxious to use their financial transaction cards, such as credit cards, to make instant fare payments as with any other category of purchase.
SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR
PERFORMING MASS TRANSIT MERCHANT TRANSACTIONS
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to, and the benefit of, U.S.
Provisional Patent Application Serial No. 61/016,069, filed December 21, 2007, which is hereby incorporated by reference in its entirety.
BACKGROUND
Field [0002] Example aspects of the present invention generally relate to mass transit fare collection systems, and more particularly to leveraging such collection systems to utilize financial transaction devices.
Related Art [0003] Regular commuters as well as infrequent mass transit riders would like the convenience of not requiring a separate payment device for paying transit fares. Particularly in today's "plastic economy", riders are anxious to use their financial transaction cards, such as credit cards, to make instant fare payments as with any other category of purchase.
[0004] Typically, authorization of a financial transaction occurs online which allows a financial transaction card issuer to verify that suitable credit or funds are available before the purchase is completed. Offline authorizations are also used by issuers if they have an intelligent payment device that is able to determine risk and provide authorization to the merchant to approve a purchase transaction.
In addition, mass transit operators typically use prepaid financial instruments to allow access through gates and use proprietary technology that is not conventionally used by financial issuers/processors.
BRIEF DESCRIPTION OF THE INVENTION
In addition, mass transit operators typically use prepaid financial instruments to allow access through gates and use proprietary technology that is not conventionally used by financial issuers/processors.
BRIEF DESCRIPTION OF THE INVENTION
[0005] The present invention provides systems, methods and computer program products for performing mass transit merchant transactions.
[0006] In accordance with one embodiment of the present invention, there is provided a system, method and computer program product for enabling access to mass transit systems using a financial transaction instrument, including reading an identifier including financial payment information from the financial transaction instrument and determining whether the identifier is stored in a database. Also included is providing access to a holder of the financial transaction instrument based on the determining.
[0007] In accordance with another embodiment of the present invention, there is provided a system, method and computer program product for registering a financial instrument for use at a mass transit agency including requesting a device identifier, translating the device identifier to an alias account number, and associating the alias account number to a mass transit registration account.
[0008] In accordance with another embodiment of the present invention, there is provided a system, method and computer program product for processing a request, from a mass transit fare collector, to provide an account status for one or more mass transit registration accounts, including transmitting a status request for the status of mass transit registration accounts to a financial transaction account issuer and/or a financial transaction account processor. The financial transaction account issuer and/or the financial transaction account processor determine a status for each mass transit registration account associated with the status request and the status is stored based on the determination.
[0009] In yet another embodiment of the present invention, there is provided a system, method and computer program product for providing an account status for a non-registered user accessing a mass transit system using a financial transaction instrument including requesting a status of an alias account from at least one of a financial transaction account issuer and financial transaction account processor, receiving, from the financial transaction account issuer or processor the status, and storing the status in a table.
[0010] Further features and advantages, as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings.
[0012] Figure 1 is an example block diagram showing a system and procedure for approving authorization for a single ride using a financial transaction device.
[0013] Figure 2 is an example block diagram showing a system and procedure for declining authorization for a single ride using a financial transaction device.
[0014] Figure 3 is an example block diagram showing a system and procedure for registering to view ride history for a single ride.
[0015] Figure 4 is an example block diagram showing a system and procedure for registering a cardmember and purchasing a multi-ride ticket/pass using a financial transaction device.
[0016] Figure 5 is an example block diagram showing a system and procedure for approving authorization for a multi-ride ticket/pass using a financial transaction device.
[0017] Figure 6 is an example block diagram showing a system and procedure for authorizing a batch account status request for registered accounts.
[0018] Figure 7 is a block diagram showing a procedure for determining whether an account number should no longer to be used for riding the transit system.
[0019] Figure 8 is a block diagram showing a system and procedure for providing customer servicing.
[0020] Figure 9 is a block diagram of an exemplary computer system useful for implementing the present invention.
[0021] Figure 10 is a collaboration diagram of functional modules deployed on a computer system for performing mass transit merchant transactions.
DETAILED DESCRIPTION
DETAILED DESCRIPTION
[0022] The example embodiments of the invention presented herein are directed to systems, methods and computer program products for performing mass transit merchant transactions, which are now described herein in terms of an example mass transit payment system. This description is not intended to limit the application of the example embodiments presented herein. In fact, after reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following example embodiments in alternative embodiments involving any system for providing rapid access in theme park environments, movie theaters, museums, and the like.
[0023] The terms "user," "end user," "consumer," "customer," "participant,"
and/or the plural form of these terms are used interchangeably throughout herein to refer to those persons or entities capable of accessing, using, being affected by and/or benefiting from the tool that the present invention provides for systems, methods and computer program products for performing mass transit merchant transactions.
and/or the plural form of these terms are used interchangeably throughout herein to refer to those persons or entities capable of accessing, using, being affected by and/or benefiting from the tool that the present invention provides for systems, methods and computer program products for performing mass transit merchant transactions.
[0024] A "transaction account" as used herein refers to an account associated with an open account or a closed account system (as described below). The transaction account may exist in a physical or non-physical embodiment. For example, a transaction account may be distributed in non-physical embodiments such as an account number, frequent-flyer account, telephone calling account or the like. Furthermore, a physical embodiment of a transaction account may be distributed as a financial instrument.
[0025] A financial transaction instrument (also referred to as a "payment device") may be traditional plastic transaction cards, titanium-containing, or other metal-containing, transaction cards, clear and/or translucent transaction cards, foldable or otherwise unconventionally-sized transaction cards, radio-frequency enabled transaction cards, or other types of transaction cards, such as credit, charge, debit, pre-paid or stored-value cards, or any other like financial transaction instrument. A financial transaction instrument may also have electronic functionality provided by a network of electronic circuitry that is printed or otherwise incorporated onto or within the transaction instrument (and typically referred to as a "smart card"), or be a fob having a transponder and an RFID reader.
[0026] An "account," "account number" or "account code", as used herein, may include any device, code, number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric or other identifier/indicia suitably configured to allow a consumer to access, interact with or communicate with a financial transaction system. The account number may optionally be located on or associated with any financial transaction instrument (e.g., a rewards, charge, credit, debit, prepaid, telephone, embossed, smart, magnetic stripe, bar code, transponder or radio frequency card).
[0027] The account number may be distributed and stored in any form of plastic, electronic, magnetic, radio frequency (RF), wireless, audio and/or optical device capable of transmitting or downloading data from itself to a second device. A
customer account number may be, for example, a sixteen-digit credit card number. Each credit card issuer has its own numbering system, such as the fifteen-digit numbering system used by American Express Company of New York, NY. Each issuer's credit card numbers comply with that company's standardized format such that an issuer using a fifteen-digit format will generally use sets of four, six, and five numbers, respectively, in the form of:
NjN2N3N4 N5N6N7N8 N9 NioNi1N12 N13N14N15 The first five to seven digits are reserved for processing purposes and identify the issuing institution, card type, etc. The last (fifteenth) digit in a fifteen-digit credit card is typically used as a sum check for the fifteen-digit number. The intermediary eight-to-eleven digits are used to uniquely identify the customer, card holder or cardmember.
customer account number may be, for example, a sixteen-digit credit card number. Each credit card issuer has its own numbering system, such as the fifteen-digit numbering system used by American Express Company of New York, NY. Each issuer's credit card numbers comply with that company's standardized format such that an issuer using a fifteen-digit format will generally use sets of four, six, and five numbers, respectively, in the form of:
NjN2N3N4 N5N6N7N8 N9 NioNi1N12 N13N14N15 The first five to seven digits are reserved for processing purposes and identify the issuing institution, card type, etc. The last (fifteenth) digit in a fifteen-digit credit card is typically used as a sum check for the fifteen-digit number. The intermediary eight-to-eleven digits are used to uniquely identify the customer, card holder or cardmember.
[0028] A visible device identifier ("VID") as used herein refers to an identifier associated with a device. For example, a VID could be an account number embossed on the front of a credit card (e.g., the 15 or 16 digit number described above), a phone number associated with a mobile phone, a number on a fob, a combination of a phone number and an index into a list of multiple payment instruments on the mobile phone, to name a few.
[0029] A merchant account number may be, for example, any number or alpha-numeric characters that identifies a particular merchant for purposes of card acceptance, account reconciliation, reporting and the like. It should be noted that the transfer of information in accordance with the present invention, may be done in a format recognizable by a merchant system or account issuer. In that regard, by way of example, the information may be transmitted from an RFID
device to an RFID reader, or from the RFID reader to the merchant system in magnetic stripe or multi-track magnetic stripe format.
device to an RFID reader, or from the RFID reader to the merchant system in magnetic stripe or multi-track magnetic stripe format.
[0030] Generally speaking, the example embodiments described below use "delayed authorization" such as secure static data authentication ("SDA"), combined data authentication ("CDA"), or dynamic data authentication ("DDA").
A delayed authorization is a purchase that completes without any authorization from the issuer or third party transaction processor (for simplicity both the issuer and processor are referred to as "issuer") or the payment device, based on the merchants' assumption that there are enough funds available in the transaction account associated with the payment device for the purchase. At a later time the authorization request is sent to the issuer and the issuer checks for available funds or credit to cover the transaction.
A delayed authorization is a purchase that completes without any authorization from the issuer or third party transaction processor (for simplicity both the issuer and processor are referred to as "issuer") or the payment device, based on the merchants' assumption that there are enough funds available in the transaction account associated with the payment device for the purchase. At a later time the authorization request is sent to the issuer and the issuer checks for available funds or credit to cover the transaction.
[0031] Figure 1 is an example block diagram showing a system and procedure for approving authorization for a single ride using a financial transaction device.
As shown in Figure 1, system 100 includes a user 100a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 100b, an MTFC processor 100c, and an issuer/processor system 100d. In block 102, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 104, the MTFC reader 100b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 106, either concurrently with the initial check performed in block 104 or thereafter, the MTFC reader 100b forms a transaction request and forwards the transaction request to the MTFC processor 100c. In block 108, the MTFC processor 100c makes a determination based on the issuer/processor alias account number whether a single ride was authorized. At block 110, the MTFC processor 100c routes the transaction request (or a derivative thereof) to the issuer/processor to provide authorization services.
The issuer/processor system 100c then confirms approval of the transaction, as shown in block 112.
As shown in Figure 1, system 100 includes a user 100a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 100b, an MTFC processor 100c, and an issuer/processor system 100d. In block 102, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 104, the MTFC reader 100b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 106, either concurrently with the initial check performed in block 104 or thereafter, the MTFC reader 100b forms a transaction request and forwards the transaction request to the MTFC processor 100c. In block 108, the MTFC processor 100c makes a determination based on the issuer/processor alias account number whether a single ride was authorized. At block 110, the MTFC processor 100c routes the transaction request (or a derivative thereof) to the issuer/processor to provide authorization services.
The issuer/processor system 100c then confirms approval of the transaction, as shown in block 112.
[0032] Figure 2 is an example block diagram showing a system and procedure for declining authorization for a single ride using a financial transaction device.
As shown, system 200 includes a user 200a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 200b, an MTFC processor 200c, and an issuer/processor system 200d. In block 202, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 204, the MTFC reader 200b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 206, either concurrently with the initial check performed in block 204 or thereafter, the MTFC reader forms a transaction request and forwards the transaction request to the MTFC processor 200c. In block 208, the MTFC processor 200c makes a determination based on the issuer/processor alias account number whether a single ride was authorized. At block 210 the MTFC processor 200c routes the transaction request (or a derivative thereof) to the issuer/processor to provide authorization services.
In this example embodiment, the issuer/processor system 200d has declined approval of the transaction, as shown in block 211. Based on the declined transaction, at block 212, the MTFC processor 200c adds the alias account number to a temporary file on a database containing restricted alias accounts.
As shown, system 200 includes a user 200a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 200b, an MTFC processor 200c, and an issuer/processor system 200d. In block 202, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 204, the MTFC reader 200b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 206, either concurrently with the initial check performed in block 204 or thereafter, the MTFC reader forms a transaction request and forwards the transaction request to the MTFC processor 200c. In block 208, the MTFC processor 200c makes a determination based on the issuer/processor alias account number whether a single ride was authorized. At block 210 the MTFC processor 200c routes the transaction request (or a derivative thereof) to the issuer/processor to provide authorization services.
In this example embodiment, the issuer/processor system 200d has declined approval of the transaction, as shown in block 211. Based on the declined transaction, at block 212, the MTFC processor 200c adds the alias account number to a temporary file on a database containing restricted alias accounts.
[0033] The MTFC processor 200c, at block 214, requests the latest status of an alias account from the issuer/processor 200d via a web service interface, which in turn provides the MTFC processor 200c status updates. In block 220, the issuer/processor 200d returns the latest status of the alias account.
Depending on whether the account is active, the MTFC processor 200c performs different procedures. If a determination is made at block 222 that the account status is not active, then at block 216, the MTFC processor 200c adds the account to a permanent database table containing restricted alias accounts. This can be accomplished, for example, by transmitting a message such as "CANCEL" to the MTFC processor 200c. If at block 222, a determination is made that the account status is active, then the MTFC processor 200c will not add the account to a permanent table containing restricted alias accounts, as shown at block 218.
This can be accomplished, for example, by transmitting a message such as "ACTIVE"
to the MTFC processor 200c. If the alias account already exists in the temporary file on the database containing restricted alias accounts and the status returned is "ACTIVE", the MTFC processor 200c removes the account from the temporary file.
Depending on whether the account is active, the MTFC processor 200c performs different procedures. If a determination is made at block 222 that the account status is not active, then at block 216, the MTFC processor 200c adds the account to a permanent database table containing restricted alias accounts. This can be accomplished, for example, by transmitting a message such as "CANCEL" to the MTFC processor 200c. If at block 222, a determination is made that the account status is active, then the MTFC processor 200c will not add the account to a permanent table containing restricted alias accounts, as shown at block 218.
This can be accomplished, for example, by transmitting a message such as "ACTIVE"
to the MTFC processor 200c. If the alias account already exists in the temporary file on the database containing restricted alias accounts and the status returned is "ACTIVE", the MTFC processor 200c removes the account from the temporary file.
[0034] Figure 3 is an example block diagram showing a system and procedure for registering to view the ride history for a single ride. As shown, system includes a user 300a (e.g., "cardmember"), a mass transit fare collector ("MTFC") website 300b, an MTFC processor 300c, and an issuer/processor system 300d. At block 302, the cardmember 300a accesses the MTFC website 300b (via an interface, not shown) and registers to view a particular history, such as a single ride history. At block 304, the MTFC website 300b requests the cardmember 300a to enter a payment device identifier or visible device identifier ("VID") of the transaction device (e.g., a wireless device such as an expresspay transaction device) which the cardmember would like to register. Once entered, this information is passed to the MTFC processor 300c, which in turn requests the issuer/processor 300d to translate the VID to an alias account number via the web service interface, as shown in block 306. At block 310, the issuer/processor 300d returns to the MTFC processor 300c the alias account number associated with the VID, which in turn associates the alias account number for the cardmember with a single-ride registration account, as shown in block 308.
[0035] At block 312, the MTFC processor 300c sends a registration message to the issuer/processor 300d informing it about whether the registration via the web service interface was successful and provides any necessary details. In turn, issuer/processor 300d stores the registration details associated with the cardmember, as shown in block 314.
[0036] Figure 4 is an example block diagram showing a system and procedure for registering a cardmember and purchasing a multi-ride ticket/pass using a financial transaction device. As shown, system 400 includes a user 400a (e.g., "cardmember"), mass transit fare collector ("MTFC") website 400b, MTFC
processor 400c, and an issuer/processor system 400d. At block 402, the cardmember accesses the MTFC website 400b (via an interface, not shown) and registers to receive multiple rides. At block 404 the cardmember is requested to enter a payment device identifier or visible device identifier ("VID") of a transaction device (e.g., a wireless device such as an expresspay transaction device) which the cardmember wishes to register. The MTFC website 400b forwards the formatted information, and sends it to the MTFC processor 400c which, in turn, requests the issuer/processor system 400d to translate the VID
to an alias account number via a web service interface, as shown in block 406. At block 408, issuer/processor 400d returns an associate alias account number to a VID. At block 410, the MTFC processor 400c routes the transaction request (or derivative thereof) to the issuer/processor 400d which, in turn, performs an authorization check, as shown in block 412. If the transaction is authorized, the MTFC processor 400c associates the alias account number with the cardmember's multi-ride ticket/pass, as shown in block 414.
processor 400c, and an issuer/processor system 400d. At block 402, the cardmember accesses the MTFC website 400b (via an interface, not shown) and registers to receive multiple rides. At block 404 the cardmember is requested to enter a payment device identifier or visible device identifier ("VID") of a transaction device (e.g., a wireless device such as an expresspay transaction device) which the cardmember wishes to register. The MTFC website 400b forwards the formatted information, and sends it to the MTFC processor 400c which, in turn, requests the issuer/processor system 400d to translate the VID
to an alias account number via a web service interface, as shown in block 406. At block 408, issuer/processor 400d returns an associate alias account number to a VID. At block 410, the MTFC processor 400c routes the transaction request (or derivative thereof) to the issuer/processor 400d which, in turn, performs an authorization check, as shown in block 412. If the transaction is authorized, the MTFC processor 400c associates the alias account number with the cardmember's multi-ride ticket/pass, as shown in block 414.
[0037] In block 416, the MTFC processor 400c transmits a registration message including some registration details to the issuer/process 400d via the web service interface, informing the issuer/processor 400d whether the registration was successful, and, upon receiving the message, the issuer/processor 400d stores the registration details associated with the cardmember.
[0038] Figure 5 is an example block diagram showing a system and procedure for approving authorization for a multi-ride ticket/pass using a financial transaction device. As shown in Figure 5, system 500 includes a user 500a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 500b, an MTFC
processor 500c, and an issuer/processor system 500d. In block 502, a cardmember 110a presents the issuer/processor a transaction device (e.g., wireless device such as expresspay transaction devices). In block 504, the MTFC
reader 500b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 506, either concurrently with the initial check performed in block 504 or thereafter, the MTFC reader forms a transaction request and forwards the transaction request to the MTFC processor 500c. In block 508, the MTFC processor 500c makes a determination based on the issuer/processor alias account number whether that a member's multi-ride ticket/pass was authorized. At block 510 the MTFC
processor 500c stores the details for the individual ride for which access was granted.
processor 500c, and an issuer/processor system 500d. In block 502, a cardmember 110a presents the issuer/processor a transaction device (e.g., wireless device such as expresspay transaction devices). In block 504, the MTFC
reader 500b queries a database table containing restricted alias accounts to determine whether the cardmember should be authorized to pass through an entry, such as a gate, and hence board a transportation vehicle. In block 506, either concurrently with the initial check performed in block 504 or thereafter, the MTFC reader forms a transaction request and forwards the transaction request to the MTFC processor 500c. In block 508, the MTFC processor 500c makes a determination based on the issuer/processor alias account number whether that a member's multi-ride ticket/pass was authorized. At block 510 the MTFC
processor 500c stores the details for the individual ride for which access was granted.
[0039] Figure 6 is an example block diagram showing a system and procedure for processing a batch account status request for registered accounts. As shown in Figure 6, system 600 includes a user 600a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 600b, an MTFC processor 600c, and an issuer/processor system 600d. With reference to system 600, a batch account status service for all registers account will now be described. In block 602, the MTFC processor 600c, at predetermined intervals, sends a request to the issuer/processor 600d for the status of all registered account numbers. The request can also be transmitted at some other predetermined time, such as upon operator request, at predetermined times, based on server or network usage, and the like. At block 604, the issuer/processor 600d returns the status of all registered alias accounts which have changed from the last time a report was sent and updates the alias account numbers as necessary. As shown at block 606, if a determination is made that an account status is not active, then at block 608 the MTFC processor 600c adds the account to a permanent database table containing restricted alias accounts. This can be accomplished by communicating a message, such as a "CANCEL" message to the MTFC processor 600c.
[0040] If a determination is made at block 606, that an account status is active, then a message is sent to the MTFC processor 600c which, in turn, recognizes the message to indicate that the account should not be added to a permanent database table containing restricted alias accounts, as shown at block 610. This can be accomplished by communicating a message, such as an "ACTIVE" message to the MTFC processor 600c. At block 612, if the alias account already exists on the database table containing restricted alias accounts and the status returned is "ACTIVE", the MTFC processor 600c removes the account from the table. If a transaction device has been replaced or renewed, MTFC processor 600c updates the registration data based on the updates received from issuer/processor 600d, as shown at block 614.
[0041] Figure 7 is a block diagram showing a system and procedure for determining whether an account number should no longer be used for riding the transit system. As shown in Figure 7, system 700 includes a user 700a (e.g., "cardmember"), mass transit fare collector ("MTFC") readers 700b, an MTFC
processor 700c, and an issuer/processor system 700d. In block 702, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 704, the MTFC
reader 700b checks a database table containing restricted alias accounts. If an alias account corresponding to the transaction device exists on the database table, then the cardmember 700a is declined from taking the transportation vehicle.
processor 700c, and an issuer/processor system 700d. In block 702, a cardmember presents the issuer/processor a transaction device (e.g., wireless device such as an expresspay transaction device). In block 704, the MTFC
reader 700b checks a database table containing restricted alias accounts. If an alias account corresponding to the transaction device exists on the database table, then the cardmember 700a is declined from taking the transportation vehicle.
[0042] Figure 8 is a block diagram showing a system and procedure for providing customer servicing. As shown in Figure 8, system 800 includes a user 800a (e.g., "cardmember"), a mass transit fare collector ("MTFC") customer service representative 800b, an MTFC processor 800c, and an issuer/processor system 800d. At block 802, a cardmember 800a communicates by, for example, calling the MTFC customer service representative 800b. Upon receiving the communication, MTFC customer service representative 800b requests the cardmember for a payment device identifier or visible device identifier ("VID").
Via a web service interface, the representative then processes the VID by sending it to MTFC processor 800c, which in turn requests the issuer/processor system 800d to translate the VID to an alias account number, as shown at block 806.
Issuer/processor 800d returns the associated alias account number to the MTFC
processor 800c, as shown in block 808. At block 810, the MTFC processor 800c retrieves the requested cardmember information, such as ride details, based on the alias account number, and provides the information to the MTFC customer service representative 800b who in turn processes the cardmember inquiry, as shown in block 812.
Via a web service interface, the representative then processes the VID by sending it to MTFC processor 800c, which in turn requests the issuer/processor system 800d to translate the VID to an alias account number, as shown at block 806.
Issuer/processor 800d returns the associated alias account number to the MTFC
processor 800c, as shown in block 808. At block 810, the MTFC processor 800c retrieves the requested cardmember information, such as ride details, based on the alias account number, and provides the information to the MTFC customer service representative 800b who in turn processes the cardmember inquiry, as shown in block 812.
[0043] Figure 10 is a collaboration diagram of functional modules deployed on a computer system for performing mass transit merchant transactions. Mass transit fare collector unit 1002 generates authorization and submissions to a business to business web services unit 1004. In one example embodiment, secure hypertext transfer protocol ("HTML") is used to communicate messages. In addition, Extended Markup Language ("XML") can be used as an extension to HTML, both being communicated over a Virtual Private Network. Enquiry component 1006 is a software system at the issuer/processor side that translates the requests received from an MTFC processor into an internal request for account status or for the linkage between the VID and the funding account number. An optional pseudo account translation service unit 1010 is communicatively coupled to both the enquiry component 1006 and one or more interfacing systems 1012.
[0044] Interfacing system(s) 1012 are used by the issuer/processor to manage financial transaction accounts, authorize payments and provide settlement of fees.
The enquiry component 1006 also is communicatively coupled to the interfacing system(s) 1012 to retrieve the status of the alias account(s). A customer servicing unit 1008 is also communicatively coupled to the interfacing system(s) 1018.
Pseudo account translation service unit 1010 provides a linkage between the VID
and the alias account number used by the MTFC processor to identify the rider or the payment device holder.
The enquiry component 1006 also is communicatively coupled to the interfacing system(s) 1012 to retrieve the status of the alias account(s). A customer servicing unit 1008 is also communicatively coupled to the interfacing system(s) 1018.
Pseudo account translation service unit 1010 provides a linkage between the VID
and the alias account number used by the MTFC processor to identify the rider or the payment device holder.
[0045] Risk management features will now be described. In one example embodiment, the use of invalid account numbers are reduced by checking that the account number provided is a correct format. For example, a card issuer may issue payment cards with numbers in a specific range and each account number has a Mod 10 check digit. In another example embodiment, risk is reduced by keeping a list of account numbers that have been previously used without sufficient funds. This list can be held by a merchant or some other third party provider. When a delayed authorization is sent to the issuer and it is declined for whatever reason, the merchant can record this number and never allow it to be used again, or at least not be used until the funding/credit issue has been corrected.
[0046] In another example embodiment, a merchant can specifically make a request to the issuer to provide a status, such as a "good/no-good" (e.g.
active/cancelled), status for an account number if the merchant suspects it is being used fraudulently. This approach allows the issuer to better control the experience of their users and not leave it to the merchant to independently reject a payment device. For example, a financial transaction account instrument holder (referred to sometimes as a "cardmember") with a very large credit limit could be using the card to pay for a train ride and when the delayed authorization request is sent, the issuer may send a decline due to a temporary credit issue.
However, the issuer may not want the merchant to prevent that cardmember from using their card again and so would prefer the approach of specifically being able to provide status on the customer as a separate process (outside of the financial network).
active/cancelled), status for an account number if the merchant suspects it is being used fraudulently. This approach allows the issuer to better control the experience of their users and not leave it to the merchant to independently reject a payment device. For example, a financial transaction account instrument holder (referred to sometimes as a "cardmember") with a very large credit limit could be using the card to pay for a train ride and when the delayed authorization request is sent, the issuer may send a decline due to a temporary credit issue.
However, the issuer may not want the merchant to prevent that cardmember from using their card again and so would prefer the approach of specifically being able to provide status on the customer as a separate process (outside of the financial network).
[0047] In order to reduce per transaction costs individual transactions can be aggregated together and sent in a single authorization request (specifically for an individual cardmember and merchant). In order to keep the security of a card holder's cryptogram the mass transit fare collector ("MTFC") will take the payment data from the last available data image from the transaction device and update the transaction amount with the aggregated amount of the multiple transactions. This has the added benefit of ensuring that the latest application transaction counter ("ATC") values are updated on the issuer side.
[0048] Customers can identify themselves using a payment device identifier or visible device identifier ("VID"). Such an identifier, could, for example, be an embossed number on the card, a cell phone number or a Fob ID. These identifiers can also be used for customer servicing for all products. And the embossed number can be used to purchase both in physical merchant locations and also over the phone or via the internet. For independent devices, e.g., expresspay fob or expresspay on mobile devices, cardmembers also can make purchases via the internet using the visible device identifier ("VID").
[0049] In an example embodiment, a list of accounts enrolled in monthly or time based program (collectively referred to herein as "multi-ride ticket/pass") is maintained. This list can be used to provide updates on account statuses to merchants. Each account number can be associated with an indication of whether the status of the account has changed since the issuer last provided details to the MTFC processor. Thus, only those accounts which have changed will be communicated. The status changes can also be stored in an audit log, which can be used, for example, for legal purposes or other security or performance related purposes.
[0050] The present approach provides the ability to use a payment device, such as a wireless device (e.g., expresspay enabled devices), to provide a transit system with the account number to be used for payment processing. This is accomplished without submitting a request for the account number associated with the payment device.
[0051] The above-described example embodiments further reduce risk to the merchant by allowing the merchant to store a list of previously used account numbers that are no longer to be used for riding the transit system. This is driven by declines to previous transactions followed by a good/no good (e.g., active/cancelled) status being provided by the issuer at the request of the transit system.
[0052] Aggregated transactions take the payment data from the chip's last available data image and update the transaction amount with aggregated amount of the multiple transactions. The last data image can be signed with a digital signature and contain a cryptogram.
[0053] In another example embodiment, an alias account number on the transaction device is used as a link to a multi-ride ticket/pass. This allows the pass to be transferred from one alias account number to another, for example, on a replaced card of the account holder. To manage this, an issuer can maintain a list of multi-ride account numbers and provide status updates to the MTFC
processor as requested. This also enables the transit authority to use the alias account number for continuous billing [0054] In yet another example embodiment, the cardmember is able to identify themselves to a customer service representative using the visible device identifier ("VID") of the device. The transit authority would then be able to call the issuer via a web interface to get the alias account number to match up to the account in question. This could be used, for example, to inform the cardmember as to how many rides are left on a multi-ride ticket/pass or to allow the cardmember to cancel continuous billing or perform other account management.
processor as requested. This also enables the transit authority to use the alias account number for continuous billing [0054] In yet another example embodiment, the cardmember is able to identify themselves to a customer service representative using the visible device identifier ("VID") of the device. The transit authority would then be able to call the issuer via a web interface to get the alias account number to match up to the account in question. This could be used, for example, to inform the cardmember as to how many rides are left on a multi-ride ticket/pass or to allow the cardmember to cancel continuous billing or perform other account management.
[0055] The present invention (i.e., systems 100-1000 and the processes depicted in FIGs. 1-8 and 10 or any part(s) or function(s) thereof) may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. However, the manipulations performed by the present invention were often referred to in terms, such as requesting, inquiring or performing customer services, which are commonly associated with mental operations performed by a human operator.
No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices. Referring to Figure 8, for example, the MTFC
customer service representative 800b could be a processor and related hardware and software configured to provide visual or audible responses to cardmember 800a inquiries.
No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices. Referring to Figure 8, for example, the MTFC
customer service representative 800b could be a processor and related hardware and software configured to provide visual or audible responses to cardmember 800a inquiries.
[0056] In fact, in one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of a computer system 900 is shown in Figure 9.
[0057] The computer system 900 includes one or more processors, such as processor 904. The processor 904 is connected to a communication infrastructure 906 (e.g., a communications bus, cross-over bar, or network).
Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
[0058] Computer system 900 can include a display interface 902 that forwards graphics, text, and other data from the communication infrastructure 906 (or from a frame buffer not shown) for display on the display unit 930. Computer system 900 also includes a main memory 908, preferably random access memory (RAM), and may also include a secondary memory 910. The secondary memory 910 may include, for example, a hard disk drive 912 and/or a removable storage drive 914, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 914 reads from and/or writes to a removable storage unit 918 in a well known manner.
Removable storage unit 918 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 914. As will be appreciated, the removable storage unit 918 includes a computer usable storage medium having stored therein computer software and/or data.
Removable storage unit 918 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 914. As will be appreciated, the removable storage unit 918 includes a computer usable storage medium having stored therein computer software and/or data.
[0059] In alternative embodiments, secondary memory 910 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 900. Such devices may include, for example, a removable storage unit 922 and an interface 920. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an electrically erasable programmable read only memory (EEPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 922 and interfaces 920, which allow software and data to be transferred from the removable storage unit 922 to computer system 900.
[0060] Computer system 900 may also include a communications interface 924.
Communications interface 924 allows software and data to be transferred between computer system 900 and external devices. Examples of communications interface 924 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 924 are in the form of signals 928 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 924. These signals 928 are provided to communications interface 924 via a communications path (e.g., channel) 926. This channel 926 carries signals 928 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communications channels.
Communications interface 924 allows software and data to be transferred between computer system 900 and external devices. Examples of communications interface 924 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 924 are in the form of signals 928 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 924. These signals 928 are provided to communications interface 924 via a communications path (e.g., channel) 926. This channel 926 carries signals 928 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communications channels.
[0061] In this document, the terms "computer program medium" and "computer usable medium" are used to generally refer to media such as removable storage drive 914, a hard disk installed in hard disk drive 912, and signals 928.
These computer program products provide software to computer system 900. The invention is directed to such computer program products.
These computer program products provide software to computer system 900. The invention is directed to such computer program products.
[0062] Computer programs (also referred to as computer control logic) are stored in main memory 908 and/or secondary memory 910. Computer programs may also be received via communications interface 924. Such computer programs, when executed, enable the computer system 900 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 904 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 900.
[0063] In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 900 using removable storage drive 914, hard drive 912 or communications interface 924. The control logic (software), when executed by the processor 904, causes the processor 904 to perform the functions of the invention as described herein.
[0064] In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
[0065] In yet another embodiment, the invention is implemented using a combination of both hardware and software.
[0066] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
[0067] In addition, it should be understood that the figures and screen shots illustrated in the attachments, which highlight the functionality and advantages of the present invention, are presented for example purposes only. The architecture of the present invention is sufficiently flexible and configurable, such that it may be utilized (and navigated) in ways other than that shown in the accompanying figures.
[0068] Further, the purpose of the foregoing Abstract is to enable the U.S.
Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way.
It is also to be understood that the steps and processes recited in the claims need not be performed in the order presented.
Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way.
It is also to be understood that the steps and processes recited in the claims need not be performed in the order presented.
Claims (33)
1. A method for enabling access to a mass transit system using a financial transaction instrument, said method comprising the steps of:
reading an identifier including financial payment information from the financial transaction instrument;
determining whether the identifier is stored in a database; and providing access to a holder of the financial transaction instrument based on the determining.
reading an identifier including financial payment information from the financial transaction instrument;
determining whether the identifier is stored in a database; and providing access to a holder of the financial transaction instrument based on the determining.
2. The method of Claim 1, further comprising the steps of:
generating a transaction request corresponding to a mass transit transaction;
routing the transaction request to a transaction processor;
performing an authorization service on the transaction request; and storing at least one of an approval and denial value associated with the identifier of the financial transaction instrument in the database based on the result of the authorization service.
generating a transaction request corresponding to a mass transit transaction;
routing the transaction request to a transaction processor;
performing an authorization service on the transaction request; and storing at least one of an approval and denial value associated with the identifier of the financial transaction instrument in the database based on the result of the authorization service.
3. The method of Claim 1, further comprising:
generating a funding settlement request for a distribution of funds.
generating a funding settlement request for a distribution of funds.
4. The method of Claim 1, further comprising:
updating the database with at least one of an approval and denial value associated with the identifier prior to the reading.
updating the database with at least one of an approval and denial value associated with the identifier prior to the reading.
5. A computer-readable medium having stored thereon sequences of instructions, the sequences of instructions including instructions which when executed by a computer system causes the computer system to perform:
reading an identifier including financial payment information from a financial transaction instrument;
determining whether the identifier is stored in a database; and providing access to a holder of the financial transaction instrument based on the determining.
reading an identifier including financial payment information from a financial transaction instrument;
determining whether the identifier is stored in a database; and providing access to a holder of the financial transaction instrument based on the determining.
6. The computer-readable medium of Claim 5, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
generating a transaction request corresponding to a mass transit transaction;
routing the transaction request to a transaction processor;
performing an authorization service on the transaction request; and storing at least one of an approval and denial value associated with the identifier of the financial transaction instrument in the database based on the result of the authorization service.
generating a transaction request corresponding to a mass transit transaction;
routing the transaction request to a transaction processor;
performing an authorization service on the transaction request; and storing at least one of an approval and denial value associated with the identifier of the financial transaction instrument in the database based on the result of the authorization service.
7. The computer-readable medium of Claim 5, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
generating a funding settlement request for a distribution of funds.
generating a funding settlement request for a distribution of funds.
8. The computer-readable medium of Claim 5, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
updating the database with at least one of an approval and denial value associated with the identifier prior to the reading.
updating the database with at least one of an approval and denial value associated with the identifier prior to the reading.
9. A system including a processor for enabling access to a mass transit system using a financial transaction instrument, comprising:
a reader configured to read an identifier including financial payment information from the financial transaction instrument;
an access module configured to determine whether the identifier is stored in a database; and a request module configured to generate a transaction request including the identifier, transmit the request to a transaction processor, and store at least one of an approval and a denial value associated with the financial transaction instrument in the database based on the result of an authorization service executed by the transaction processor.
a reader configured to read an identifier including financial payment information from the financial transaction instrument;
an access module configured to determine whether the identifier is stored in a database; and a request module configured to generate a transaction request including the identifier, transmit the request to a transaction processor, and store at least one of an approval and a denial value associated with the financial transaction instrument in the database based on the result of an authorization service executed by the transaction processor.
10. A method for registering a financial instrument for use at a mass transit agency, comprising the steps of:
requesting an identifier;
translating the identifier to an alias account number; and associating the alias account number to a mass transit registration account.
requesting an identifier;
translating the identifier to an alias account number; and associating the alias account number to a mass transit registration account.
11. The method of Claim 10, wherein the mass transit registration account is at least one of (i) single ride registration account, and (ii) a multi-ride ticket/pass.
12. The method of Claim 10, further comprising:
transmitting a registration message indicating a status of registration associated with the alias account number.
transmitting a registration message indicating a status of registration associated with the alias account number.
13. The method of Claim 10, wherein the identifier is a visual device identifier.
14. The method according to Claim 10, further comprising the steps of:
requesting a status of the alias account from at least one of a financial transaction account issuer and a financial transaction account processor;
receiving the status from the at least one of the financial transaction account issuer and financial transaction account processor; and storing the status in a table.
requesting a status of the alias account from at least one of a financial transaction account issuer and a financial transaction account processor;
receiving the status from the at least one of the financial transaction account issuer and financial transaction account processor; and storing the status in a table.
15. A computer-readable medium having stored thereon sequences of instructions, the sequences of instructions including instructions which when executed by a computer system causes the computer system to perform:
requesting an identifier;
translating the identifier to an alias account number; and associating the alias account number to a mass transit registration account.
requesting an identifier;
translating the identifier to an alias account number; and associating the alias account number to a mass transit registration account.
16. The computer-readable medium of Claim 15, wherein the mass transit registration account is at least one of (i) single ride registration account, and (ii) a multi-ride ticket/pass.
17. The computer-readable medium of Claim 15, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
transmitting a registration message indicating a status of registration associated with the alias account number.
transmitting a registration message indicating a status of registration associated with the alias account number.
18. The computer-readable medium of Claim 15, wherein the identifier is a visual device identifier.
19. The computer-readable medium of Claim 15, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
requesting a status of the alias account from at least one of a financial transaction account issuer and a financial transaction account processor;
receiving the status from the at least one of the financial transaction account issuer and financial transaction account processor; and storing the status in a table.
requesting a status of the alias account from at least one of a financial transaction account issuer and a financial transaction account processor;
receiving the status from the at least one of the financial transaction account issuer and financial transaction account processor; and storing the status in a table.
20. A system including a processor for registering a financial instrument for use at a mass transit agency, comprising:
an interface configured to request an identifier of the financial transaction instrument;
a translator module configured to translate the identifier to an alias account number;
an association module configured to associate the alias account number to a mass transit registration account.
an interface configured to request an identifier of the financial transaction instrument;
a translator module configured to translate the identifier to an alias account number;
an association module configured to associate the alias account number to a mass transit registration account.
21. The system method of Claim 20, wherein the mass transit registration account is at least one of (i) single ride registration account, and (ii) a multi-ride ticket/pass.
22. The system of Claim 21, further comprising:
a transaction module configured to communicate a registration message indicating a status of registration associated with the alias account number.
a transaction module configured to communicate a registration message indicating a status of registration associated with the alias account number.
23. The system of Claim 20, wherein the identifier is a visual device identifier.
24. The system of Claim 20, further comprising:
an enquiry module configured to generate a request for a status of an alias account from at least one of a financial transaction account issuer and a financial transaction account processor, receive the status from at least one of the financial transaction account issuer and the financial transaction account processor, and a store the status in a table.
an enquiry module configured to generate a request for a status of an alias account from at least one of a financial transaction account issuer and a financial transaction account processor, receive the status from at least one of the financial transaction account issuer and the financial transaction account processor, and a store the status in a table.
25. A method for processing a request, from a mass transit fare collector, to provide an account status for one or more mass transit registration accounts, the steps comprising:
transmitting a status request for the status of the one or more mass transit registration accounts to at least one of a financial transaction account issuer and a financial transaction account processor;
determining, by at least one of the financial transaction account issuer and the financial transaction account processor a status for each mass transit registration account associated with the status request; and storing the status based on the determining.
transmitting a status request for the status of the one or more mass transit registration accounts to at least one of a financial transaction account issuer and a financial transaction account processor;
determining, by at least one of the financial transaction account issuer and the financial transaction account processor a status for each mass transit registration account associated with the status request; and storing the status based on the determining.
26. The method of Claim 25, wherein the request is a batch request for the status of a plurality of mass transit registration accounts.
27. The method of Claim 25, further comprising the step of:
removing a mass transit registration account based on the determining.
removing a mass transit registration account based on the determining.
28. The method of Claim 25, further comprising the step of:
updating each mass transit registration account status based on the determining.
updating each mass transit registration account status based on the determining.
29. A computer-readable medium having stored thereon sequences of instructions, the sequences of instructions including instructions which when executed by a computer system causes the computer system to perform:
transmitting a status request for a status of the one or more mass transit registration accounts to at least one of a financial transaction account issuer and a financial transaction account processor;
determining, by at least one of the financial transaction account issuer and the financial transaction account processor a status for each mass transit registration account associated with the status request; and storing the status based on the determining.
transmitting a status request for a status of the one or more mass transit registration accounts to at least one of a financial transaction account issuer and a financial transaction account processor;
determining, by at least one of the financial transaction account issuer and the financial transaction account processor a status for each mass transit registration account associated with the status request; and storing the status based on the determining.
30. The computer-readable medium of Claim 29, wherein the request is a batch request for the status of a plurality of mass transit registration accounts.
31. The computer-readable medium of Claim 29, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
removing a mass transit registration account based on the determining.
removing a mass transit registration account based on the determining.
32. The computer-readable medium of Claim 29, further including a sequence of instructions which when executed by a computer system causes the computer system to perform:
updating each mass transit registration account status based on the determining.
updating each mass transit registration account status based on the determining.
33. A system including a processor for processing a request from a mass transit fare collector to provide an account status for one or more mass transit registration accounts, comprising:
a status module configured to determine a status for each mass transit registration account associated to a respective one of a plurality of registered users;
and a database constructed to store the status determined by the status module.
a status module configured to determine a status for each mass transit registration account associated to a respective one of a plurality of registered users;
and a database constructed to store the status determined by the status module.
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US1606907P | 2007-12-21 | 2007-12-21 | |
US61/016,069 | 2007-12-21 | ||
US12/273,738 US8117129B2 (en) | 2007-12-21 | 2008-11-19 | Systems, methods and computer program products for performing mass transit merchant transactions |
US12/273,738 | 2008-11-19 | ||
PCT/US2008/086970 WO2009082645A1 (en) | 2007-12-21 | 2008-12-16 | Systems, methods and computer program products for performing mass transit merchant transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2710341A1 true CA2710341A1 (en) | 2009-07-02 |
Family
ID=40789771
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2710341A Abandoned CA2710341A1 (en) | 2007-12-21 | 2008-12-16 | Systems, methods and computer program products for performing mass transit merchant transactions |
Country Status (6)
Country | Link |
---|---|
US (2) | US8117129B2 (en) |
EP (1) | EP2243119A4 (en) |
AU (1) | AU2008340301B2 (en) |
CA (1) | CA2710341A1 (en) |
MX (1) | MX2010007035A (en) |
WO (1) | WO2009082645A1 (en) |
Families Citing this family (132)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140019352A1 (en) | 2011-02-22 | 2014-01-16 | Visa International Service Association | Multi-purpose virtual card transaction apparatuses, methods and systems |
US8762263B2 (en) | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
ES2372833B1 (en) * | 2006-11-16 | 2013-01-29 | Net1 Ueps Technologies Inc. | VERIFICATION OF THE IDENTITY OF A PERSON WHO CARRIED OUT A TRANSACTION. |
US8121956B2 (en) | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Cardless challenge systems and methods |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US7937324B2 (en) | 2007-09-13 | 2011-05-03 | Visa U.S.A. Inc. | Account permanence |
US8219489B2 (en) | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
WO2010053899A2 (en) | 2008-11-06 | 2010-05-14 | Visa International Service Association | Online challenge-response |
US9715681B2 (en) | 2009-04-28 | 2017-07-25 | Visa International Service Association | Verification of portable consumer devices |
US9105027B2 (en) | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US8602293B2 (en) | 2009-05-15 | 2013-12-10 | Visa International Service Association | Integration of verification tokens with portable computing devices |
US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
US7891560B2 (en) | 2009-05-15 | 2011-02-22 | Visa International Service Assocation | Verification of portable consumer devices |
US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
US8893967B2 (en) | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
US10140598B2 (en) | 2009-05-20 | 2018-11-27 | Visa International Service Association | Device including encrypted data for expiration date and verification value creation |
US10454693B2 (en) * | 2009-09-30 | 2019-10-22 | Visa International Service Association | Mobile payment application architecture |
US10255591B2 (en) | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
US9098843B2 (en) * | 2010-01-06 | 2015-08-04 | Visa International Service Association | System and method for temporarily enabling proprietary transit payments on a hotel room key |
CN102713922B (en) | 2010-01-12 | 2015-11-25 | 维萨国际服务协会 | For the method whenever confirmed to checking token |
US9424413B2 (en) | 2010-02-24 | 2016-08-23 | Visa International Service Association | Integration of payment capability into secure elements of computers |
US10255601B2 (en) | 2010-02-25 | 2019-04-09 | Visa International Service Association | Multifactor authentication using a directory server |
US9245267B2 (en) | 2010-03-03 | 2016-01-26 | Visa International Service Association | Portable account number for consumer payment account |
US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
CN109118199A (en) | 2011-02-16 | 2019-01-01 | 维萨国际服务协会 | Snap mobile payment device, method and system |
SG193510A1 (en) | 2011-02-22 | 2013-10-30 | Visa Int Service Ass | Universal electronic payment apparatuses, methods and systems |
US8769071B2 (en) * | 2011-02-25 | 2014-07-01 | Red Hat, Inc. | Dynamic mapping of identifiers in a multi-tenant computing system |
WO2012142045A2 (en) | 2011-04-11 | 2012-10-18 | Visa International Service Association | Multiple tokenization for authentication |
WO2013006725A2 (en) | 2011-07-05 | 2013-01-10 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
WO2013019567A2 (en) | 2011-07-29 | 2013-02-07 | Visa International Service Association | Passing payment tokens through an hop/sop |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9165294B2 (en) | 2011-08-24 | 2015-10-20 | Visa International Service Association | Method for using barcodes and mobile devices to conduct payment transactions |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
RU2631983C2 (en) | 2012-01-05 | 2017-09-29 | Виза Интернэшнл Сервис Ассосиэйшн | Data protection with translation |
US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
WO2013113004A1 (en) | 2012-01-26 | 2013-08-01 | Visa International Service Association | System and method of providing tokenization as a service |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
US10282724B2 (en) | 2012-03-06 | 2019-05-07 | Visa International Service Association | Security system incorporating mobile device |
US20130282550A1 (en) * | 2012-04-20 | 2013-10-24 | Andrew Garrett SYCOFF | Monetizing Financial Brokerage Data |
WO2013166501A1 (en) | 2012-05-04 | 2013-11-07 | Visa International Service Association | System and method for local data conversion |
US9524501B2 (en) | 2012-06-06 | 2016-12-20 | Visa International Service Association | Method and system for correlating diverse transaction data |
US9547769B2 (en) | 2012-07-03 | 2017-01-17 | Visa International Service Association | Data protection hub |
US10496977B2 (en) | 2012-07-16 | 2019-12-03 | Square, Inc. | Storing and forwarding payment transactions |
US9846861B2 (en) | 2012-07-25 | 2017-12-19 | Visa International Service Association | Upstream and downstream data conversion |
US9256871B2 (en) | 2012-07-26 | 2016-02-09 | Visa U.S.A. Inc. | Configurable payment tokens |
US11055686B2 (en) | 2012-08-08 | 2021-07-06 | E2Interactive, Inc. | S/M for providing, reloading, and redeeming stored value cards used in transit applications |
US9665722B2 (en) | 2012-08-10 | 2017-05-30 | Visa International Service Association | Privacy firewall |
WO2014043278A1 (en) | 2012-09-11 | 2014-03-20 | Visa International Service Association | Cloud-based virtual wallet nfc apparatuses, methods and systems |
US10176478B2 (en) | 2012-10-23 | 2019-01-08 | Visa International Service Association | Transaction initiation determination system utilizing transaction data elements |
US9911118B2 (en) | 2012-11-21 | 2018-03-06 | Visa International Service Association | Device pairing via trusted intermediary |
US10304047B2 (en) | 2012-12-07 | 2019-05-28 | Visa International Service Association | Token generating component |
US9741051B2 (en) | 2013-01-02 | 2017-08-22 | Visa International Service Association | Tokenization and third-party interaction |
US10740731B2 (en) | 2013-01-02 | 2020-08-11 | Visa International Service Association | Third party settlement |
US11055710B2 (en) | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
SG11201509386UA (en) | 2013-05-15 | 2015-12-30 | Visa Int Service Ass | Mobile tokenization hub |
US10878422B2 (en) | 2013-06-17 | 2020-12-29 | Visa International Service Association | System and method using merchant token |
CN113469670B (en) | 2013-07-24 | 2024-04-05 | 维萨国际服务协会 | System and method for ensuring data transfer risk using tokens |
AU2014294613B2 (en) | 2013-07-26 | 2017-03-16 | Visa International Service Association | Provisioning payment credentials to a consumer |
US10496986B2 (en) | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
SG11201600909QA (en) | 2013-08-08 | 2016-03-30 | Visa Int Service Ass | Methods and systems for provisioning mobile devices with payment credentials |
US9978094B2 (en) | 2013-10-11 | 2018-05-22 | Visa International Service Association | Tokenization revocation list |
EP3937108A1 (en) | 2013-10-11 | 2022-01-12 | Visa International Service Association | Network token system |
US10515358B2 (en) | 2013-10-18 | 2019-12-24 | Visa International Service Association | Contextual transaction token methods and systems |
US10489779B2 (en) | 2013-10-21 | 2019-11-26 | Visa International Service Association | Multi-network token bin routing with defined verification parameters |
US10366387B2 (en) | 2013-10-29 | 2019-07-30 | Visa International Service Association | Digital wallet system and method |
SG10201900029SA (en) | 2013-11-19 | 2019-02-27 | Visa Int Service Ass | Automated account provisioning |
AU2014368949A1 (en) | 2013-12-19 | 2016-06-09 | Visa International Service Association | Cloud-based transactions methods and systems |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
US10433128B2 (en) | 2014-01-07 | 2019-10-01 | Visa International Service Association | Methods and systems for provisioning multiple devices |
US9846878B2 (en) | 2014-01-14 | 2017-12-19 | Visa International Service Association | Payment account identifier system |
GB2524282A (en) | 2014-03-19 | 2015-09-23 | Mastercard International Inc | Automatic data transfer |
US10026087B2 (en) | 2014-04-08 | 2018-07-17 | Visa International Service Association | Data passed in an interaction |
US9942043B2 (en) | 2014-04-23 | 2018-04-10 | Visa International Service Association | Token security on a communication device |
CA2946150A1 (en) | 2014-05-01 | 2015-11-05 | Visa International Service Association | Data verification using access device |
EP3140798A4 (en) | 2014-05-05 | 2017-12-20 | Visa International Service Association | System and method for token domain control |
CN106465112A (en) | 2014-05-21 | 2017-02-22 | 维萨国际服务协会 | Offline authentication |
US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
US9780953B2 (en) | 2014-07-23 | 2017-10-03 | Visa International Service Association | Systems and methods for secure detokenization |
US10484345B2 (en) | 2014-07-31 | 2019-11-19 | Visa International Service Association | System and method for identity verification across mobile applications |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
US10140615B2 (en) | 2014-09-22 | 2018-11-27 | Visa International Service Association | Secure mobile device credential provisioning using risk decision non-overrides |
ES2732564T3 (en) | 2014-09-26 | 2019-11-25 | Visa Int Service Ass | Remote server encrypted data provisioning system and procedures |
US11257074B2 (en) | 2014-09-29 | 2022-02-22 | Visa International Service Association | Transaction risk based token |
US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
GB201419016D0 (en) | 2014-10-24 | 2014-12-10 | Visa Europe Ltd | Transaction Messaging |
US10325261B2 (en) | 2014-11-25 | 2019-06-18 | Visa International Service Association | Systems communications with non-sensitive identifiers |
US11620643B2 (en) | 2014-11-26 | 2023-04-04 | Visa International Service Association | Tokenization request via access device |
US10257185B2 (en) | 2014-12-12 | 2019-04-09 | Visa International Service Association | Automated access data provisioning |
AU2015361023B2 (en) | 2014-12-12 | 2019-08-29 | Visa International Service Association | Provisioning platform for machine-to-machine devices |
US10187363B2 (en) | 2014-12-31 | 2019-01-22 | Visa International Service Association | Hybrid integration of software development kit with secure execution environment |
US10096009B2 (en) | 2015-01-20 | 2018-10-09 | Visa International Service Association | Secure payment processing using authorization request |
US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
WO2016126729A1 (en) | 2015-02-03 | 2016-08-11 | Visa International Service Association | Validation identity tokens for transactions |
US10977657B2 (en) | 2015-02-09 | 2021-04-13 | Visa International Service Association | Token processing utilizing multiple authorizations |
US10164996B2 (en) | 2015-03-12 | 2018-12-25 | Visa International Service Association | Methods and systems for providing a low value token buffer |
EP3281164B1 (en) | 2015-04-10 | 2019-06-05 | Visa International Service Association | Browser integration with cryptogram |
US9998978B2 (en) | 2015-04-16 | 2018-06-12 | Visa International Service Association | Systems and methods for processing dormant virtual access devices |
US10552834B2 (en) | 2015-04-30 | 2020-02-04 | Visa International Service Association | Tokenization capable authentication framework |
CN114529300A (en) | 2015-10-15 | 2022-05-24 | 维萨国际服务协会 | Instant token issuing system |
US20170140450A1 (en) | 2015-11-17 | 2017-05-18 | Fazahl Ashby | Visual cable builder |
CN108370319B (en) | 2015-12-04 | 2021-08-17 | 维萨国际服务协会 | Method and computer for token verification |
US11049096B2 (en) | 2015-12-31 | 2021-06-29 | Paypal, Inc. | Fault tolerant token based transaction systems |
CA3009659C (en) | 2016-01-07 | 2022-12-13 | Visa International Service Association | Systems and methods for device push provisioning |
EP3411846A4 (en) | 2016-02-01 | 2018-12-12 | Visa International Service Association | Systems and methods for code display and use |
US11501288B2 (en) | 2016-02-09 | 2022-11-15 | Visa International Service Association | Resource provider account token provisioning and processing |
US10313321B2 (en) | 2016-04-07 | 2019-06-04 | Visa International Service Association | Tokenization of co-network accounts |
AU2016403734B2 (en) | 2016-04-19 | 2022-11-17 | Visa International Service Association | Systems and methods for performing push transactions |
US11250424B2 (en) | 2016-05-19 | 2022-02-15 | Visa International Service Association | Systems and methods for creating subtokens using primary tokens |
EP3466017B1 (en) | 2016-06-03 | 2021-05-19 | Visa International Service Association | Subtoken management system for connected devices |
US11068899B2 (en) | 2016-06-17 | 2021-07-20 | Visa International Service Association | Token aggregation for multi-party transactions |
AU2017281938A1 (en) | 2016-06-24 | 2018-10-25 | Visa International Service Association | Unique token authentication cryptogram |
AU2017295842A1 (en) | 2016-07-11 | 2018-11-01 | Visa International Service Association | Encryption key exchange process using access device |
CN109478287B (en) | 2016-07-19 | 2023-08-15 | 维萨国际服务协会 | Method for distributing tokens and managing token relationships |
US10740699B2 (en) * | 2016-07-20 | 2020-08-11 | Conduent Business Services, Llc | System and method for specializing transactions according to the service provider |
US10509779B2 (en) | 2016-09-14 | 2019-12-17 | Visa International Service Association | Self-cleaning token vault |
CN117009946A (en) | 2016-11-28 | 2023-11-07 | 维萨国际服务协会 | Access identifier supplied to application program |
US20180174210A1 (en) * | 2016-12-15 | 2018-06-21 | Mastercard International Incorporated | Systems and methods for detecting data inconsistencies |
US10915899B2 (en) | 2017-03-17 | 2021-02-09 | Visa International Service Association | Replacing token on a multi-token user device |
US10902418B2 (en) | 2017-05-02 | 2021-01-26 | Visa International Service Association | System and method using interaction token |
US11494765B2 (en) | 2017-05-11 | 2022-11-08 | Visa International Service Association | Secure remote transaction system using mobile devices |
US10491389B2 (en) | 2017-07-14 | 2019-11-26 | Visa International Service Association | Token provisioning utilizing a secure authentication system |
SG11202008451RA (en) | 2018-03-07 | 2020-09-29 | Visa Int Service Ass | Secure remote token release with online authentication |
US11256789B2 (en) | 2018-06-18 | 2022-02-22 | Visa International Service Association | Recurring token transactions |
CN112740207A (en) | 2018-08-22 | 2021-04-30 | 维萨国际服务协会 | Method and system for token provisioning and processing |
EP3881258A4 (en) | 2018-11-14 | 2022-01-12 | Visa International Service Association | Cloud token provisioning of multiple tokens |
WO2020236135A1 (en) | 2019-05-17 | 2020-11-26 | Visa International Service Association | Virtual access credential interaction system and method |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9401924D0 (en) | 1994-02-01 | 1994-03-30 | Jonhig Ltd | System for road toll payment |
US5828044A (en) | 1996-03-14 | 1998-10-27 | Kookmin Credit Card Co., Ltd. | Non-contacting type radio frequency recognizing credit card system |
JP3869065B2 (en) | 1997-03-03 | 2007-01-17 | 株式会社東芝 | Ticket gate system, search device, and ticket management system traffic management method |
WO2001013338A1 (en) | 1999-08-11 | 2001-02-22 | Mark Iv Industries Limited | Method and means for rf toll collection |
AU779316B2 (en) | 2000-03-16 | 2005-01-13 | Harex Infotech Inc. | Optical payment transceiver and system using the same |
MXPA03010355A (en) * | 2001-05-14 | 2005-03-07 | Cubic Corp | System enablement of automatic fare collection devices using a network. |
KR100378445B1 (en) * | 2002-06-24 | 2003-03-29 | C & C Entpr Co Ltd | Method for managing card approval information using memory address and credit card system using the same |
US7331522B2 (en) | 2003-08-07 | 2008-02-19 | Cubic Corporation | Virtual gate system |
RU2421812C2 (en) * | 2005-05-16 | 2011-06-20 | Мастеркард Интернэшнл Инкорпорейтед | Method and system for use contactless payment cards in transport system |
WO2006135779A2 (en) * | 2005-06-10 | 2006-12-21 | American Express Travel Related Services Company, Inc. | System and method for mass transit merchant payment |
US7566003B2 (en) * | 2006-12-07 | 2009-07-28 | Specialty Acquirer Llc | Learning fare collection system for mass transit |
-
2008
- 2008-11-19 US US12/273,738 patent/US8117129B2/en not_active Expired - Fee Related
- 2008-12-16 EP EP08865172A patent/EP2243119A4/en not_active Withdrawn
- 2008-12-16 CA CA2710341A patent/CA2710341A1/en not_active Abandoned
- 2008-12-16 MX MX2010007035A patent/MX2010007035A/en not_active Application Discontinuation
- 2008-12-16 WO PCT/US2008/086970 patent/WO2009082645A1/en active Application Filing
- 2008-12-16 AU AU2008340301A patent/AU2008340301B2/en not_active Ceased
-
2012
- 2012-01-03 US US13/342,576 patent/US8504478B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US20090164375A1 (en) | 2009-06-25 |
WO2009082645A1 (en) | 2009-07-02 |
US8504478B2 (en) | 2013-08-06 |
AU2008340301A1 (en) | 2009-07-02 |
US20120109722A1 (en) | 2012-05-03 |
AU2008340301B2 (en) | 2012-06-07 |
EP2243119A4 (en) | 2012-02-15 |
MX2010007035A (en) | 2010-08-25 |
US8117129B2 (en) | 2012-02-14 |
EP2243119A1 (en) | 2010-10-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2008340301B2 (en) | Systems, methods and computer program products for performing mass transit merchant transactions | |
US8025223B2 (en) | System and method for mass transit merchant payment | |
US8973818B2 (en) | Processing transactions of different payment devices of the same issuer account | |
US7311249B2 (en) | System and method for conducting a return transaction for a PIN-activated account | |
US20050173518A1 (en) | Secure device and mobile terminal which carry out data exchange between card applications | |
JP2003108777A (en) | Method, device for informing settlement information, settlement information managing device and program | |
CN101558414A (en) | System and method for user selection of fraud detection rules | |
US9038888B2 (en) | Fraud control when granting instant credit | |
US8571953B2 (en) | System and method for processing travel expense vouchers | |
US20070179844A1 (en) | System and method for insuring frequent traveler reward miles | |
KR20120100283A (en) | System and method for electronic payment | |
US20120271763A1 (en) | Method and system for mobile remittance | |
US20030120590A1 (en) | Electronic settlement method and system | |
WO2007095372A2 (en) | System and method for collection and processing of transit fares | |
RU2686618C1 (en) | Method of providing user access to services of local service operator, user terminal device and system server for implementation of method | |
US20240054467A1 (en) | Method and System for Transaction Processing | |
KR20160075451A (en) | Method for Processing Payment of Offline Affiliated Store by using USIM | |
KR20180033161A (en) | Method for Processing Payment of Offline Affiliated Store by using Mobile Device | |
JP2013101439A (en) | Season ticket use system, ticket issue device and season ticket use method | |
KR20050110141A (en) | Mobile ticket service system | |
KR20150109315A (en) | Method for Processing Payment of Offline Affiliated Store by using USIM | |
KR20080101350A (en) | Prepayment processing system and prepayment processing method using auto fill card | |
KR20130019305A (en) | System and method for automatic exchange included card | |
KR20100053913A (en) | System and method for processing settlement free traffic fare and recording medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |
Effective date: 20151216 |