CA2475275C - Wireless data processing system for credit payment - Google Patents
Wireless data processing system for credit payment Download PDFInfo
- Publication number
- CA2475275C CA2475275C CA2475275A CA2475275A CA2475275C CA 2475275 C CA2475275 C CA 2475275C CA 2475275 A CA2475275 A CA 2475275A CA 2475275 A CA2475275 A CA 2475275A CA 2475275 C CA2475275 C CA 2475275C
- Authority
- CA
- Canada
- Prior art keywords
- card
- payment authorization
- service provider
- token
- mobile device
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- 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
- 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
- G06Q20/403—Solvency checks
- G06Q20/4037—Remote solvency checks
-
- 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
- H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
Abstract
A wireless payment processing system is applicable for secure payment by Credit Cards or Debit Cards for goods or services with the use of mobile devices. The payment authorization centre delivers public portion of the authorization token to the service provider via the existing communications channels and the private portion of the authorization token is delivered to the mobile device via Short Message Service (SMS) or Unstructured Supplementary Service Data (USSD) or e-mail short message. The mobile device delivers the private authorization token to the service provider via private local network based on Bluetooth (trade mark), infrared or other short radio frequency based technology. The credit card or debit card number is never revealed and a temporary card token replaces it.
Description
WIRELESS DATA PROCESSING SYSTEM FOR CREDIT PAYMENT
FIELD OF INVENTION
This invention relates to a data processing system for credit card and debit card payments. Specifically, this invention relates to data processing systems with the use of wireless devices such as cell phones or FDA's.
Every payment system has to be deployed in a context of customer-merchant interaction architecture and this invention is well suited to be deployed as part of a purpose Bluetooth(trade mark) application profile. The profile could be designed to enable the user to interact with a local environment using a variety of electronic devices such as cellular phones, PDAs, etc. The local environment is defined as a set of service offerings and interaction points that can be accessed and affected by the user. For example, the user will be able to complete a vending machine purchase, make a payment at a checkout counter or purchase a ticket at a train station.
Subsequent description of this invention will be presented in the context of Bluetooth(trade mark) profile environment. However this invention is applicable to any wireless payment environment.
BACKGROUND OF THE INVENTION
Credit card and debit card payment systems have been developed to enable cashless payment for goods and services at the point of purchase by the use of credit card or debit card. The cards are issued to users (card owners) by financial institutions such as banks, Credit Unions or Trusts and they represent identification of a bank account with the issuing financial institution. In order to enable the card owners to use the cards at the point of purchase locations payment systems have been developed that allow transfer of an electronic purchase request transaction to the financial institution for authorization against the user's bank account. Once the balance of the bank account is checked and determined sufficient to cover the requested purchase amount an authorization transaction is sent back to the point of purchase location, which in turn instructs the merchant that the purchase amount is guaranteed and the goods can be released to the card owner.
The biggest challenge facing any card payment system is security of the credit card information. This is especially difficult for credit card based systems where there is no Personal Identification Number (PIN) assigned to the card. In recent years VISA has introduced their own PIN for Visa cards only but that solution is not available on majority of credit cards in circulation. However, those types of solutions cannot solve the major weakness in the existing card payment systems that exclude the card owner from the transaction flow and solely rely on merchant ¨ card issuer interaction to authorize the payment.
SUMMARY OF THE INVENTION
It is a principal object of the present invention to provide a card payment system that makes the card owner an integral part of the payment authorization flow.
It is another object of the present invention to provide a card payment system that creates a highly secured environment for exchanging credit or debit card information where the card number is never exposed.
It is another object of the present invention to provide a card payment system with an enhanced security for credit card financial transactions by implementing real time cardholder notification.
FIELD OF INVENTION
This invention relates to a data processing system for credit card and debit card payments. Specifically, this invention relates to data processing systems with the use of wireless devices such as cell phones or FDA's.
Every payment system has to be deployed in a context of customer-merchant interaction architecture and this invention is well suited to be deployed as part of a purpose Bluetooth(trade mark) application profile. The profile could be designed to enable the user to interact with a local environment using a variety of electronic devices such as cellular phones, PDAs, etc. The local environment is defined as a set of service offerings and interaction points that can be accessed and affected by the user. For example, the user will be able to complete a vending machine purchase, make a payment at a checkout counter or purchase a ticket at a train station.
Subsequent description of this invention will be presented in the context of Bluetooth(trade mark) profile environment. However this invention is applicable to any wireless payment environment.
BACKGROUND OF THE INVENTION
Credit card and debit card payment systems have been developed to enable cashless payment for goods and services at the point of purchase by the use of credit card or debit card. The cards are issued to users (card owners) by financial institutions such as banks, Credit Unions or Trusts and they represent identification of a bank account with the issuing financial institution. In order to enable the card owners to use the cards at the point of purchase locations payment systems have been developed that allow transfer of an electronic purchase request transaction to the financial institution for authorization against the user's bank account. Once the balance of the bank account is checked and determined sufficient to cover the requested purchase amount an authorization transaction is sent back to the point of purchase location, which in turn instructs the merchant that the purchase amount is guaranteed and the goods can be released to the card owner.
The biggest challenge facing any card payment system is security of the credit card information. This is especially difficult for credit card based systems where there is no Personal Identification Number (PIN) assigned to the card. In recent years VISA has introduced their own PIN for Visa cards only but that solution is not available on majority of credit cards in circulation. However, those types of solutions cannot solve the major weakness in the existing card payment systems that exclude the card owner from the transaction flow and solely rely on merchant ¨ card issuer interaction to authorize the payment.
SUMMARY OF THE INVENTION
It is a principal object of the present invention to provide a card payment system that makes the card owner an integral part of the payment authorization flow.
It is another object of the present invention to provide a card payment system that creates a highly secured environment for exchanging credit or debit card information where the card number is never exposed.
It is another object of the present invention to provide a card payment system with an enhanced security for credit card financial transactions by implementing real time cardholder notification.
-2-It is another object of the present invention to provide a card payment system that eliminates the use of encryption technology for exchanging credit or debit card information.
It is another object of the present invention to provide a public card vault facility so a card owner can register his/her list of cards to be used by him/her at merchant locations.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic view of the card payment transaction authorization flow which comprises the system of the present invention.
Figure 2 is a schematic view of the card payment transaction authorization flow with alternate embodiment of the system of the present invention.
Figure 3 is a schematic view of the card payment transaction authorization flow with alternate transaction flow providing notification based mode of the system of the present invention.
Figure 4 is a schematic view of an alternative embodiment of the transaction authorization process.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Best Mode For Carrying Out the Invention Referring now to the drawings and particularly to Figure 1 there is shown therein a schematic view of a transaction authorization process carried out with a preferred embodiment of the system of the present invention, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider 21, which in preferred embodiment is the Bluetooth(trade mark) Retail
It is another object of the present invention to provide a public card vault facility so a card owner can register his/her list of cards to be used by him/her at merchant locations.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic view of the card payment transaction authorization flow which comprises the system of the present invention.
Figure 2 is a schematic view of the card payment transaction authorization flow with alternate embodiment of the system of the present invention.
Figure 3 is a schematic view of the card payment transaction authorization flow with alternate transaction flow providing notification based mode of the system of the present invention.
Figure 4 is a schematic view of an alternative embodiment of the transaction authorization process.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Best Mode For Carrying Out the Invention Referring now to the drawings and particularly to Figure 1 there is shown therein a schematic view of a transaction authorization process carried out with a preferred embodiment of the system of the present invention, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider 21, which in preferred embodiment is the Bluetooth(trade mark) Retail
-3-Server, is operated at the retailer location and is responsible for managing interaction with card owner 23 and the Card Validation Platform 25. A bank or other entities responsible for processing transactions operate the validation platform.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in preferred embodiment is a Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending GetCredential request message 1 to the Mobile Device 22. The credential token could be PIN, password or any biometric reading of the card owner's body (voice, retina scan, etc.), which in the preferred embodiment is providing voice token by the card owner 23 represented by activity GetCredential 2.
The Mobile Device 22 sends the credential token back to the Service Provider along with Mobile device's International Mobile Equipment Identity (IMEI).
Next the Service Provider 21 sends GetCardList request message 3 to the Public Card Vault Platform 24 passing along the credential token and IMEI.
The Public Card Vault Platform is a repository of card names list for card owner's mobile device. Any card owner who wishes to create his card vault list would come to a Web based interface and create a new account for his mobile device by providing his/her mobile device's IMEI number and account credential token (i.e. voice token) and then s/he would select from the list of card names by financial institution. For each card name selected the card owner would provide last 2 digits of his/her card number, a credential token type for the card, and s/he would assign his own friendly display name for the card.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in preferred embodiment is a Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending GetCredential request message 1 to the Mobile Device 22. The credential token could be PIN, password or any biometric reading of the card owner's body (voice, retina scan, etc.), which in the preferred embodiment is providing voice token by the card owner 23 represented by activity GetCredential 2.
The Mobile Device 22 sends the credential token back to the Service Provider along with Mobile device's International Mobile Equipment Identity (IMEI).
Next the Service Provider 21 sends GetCardList request message 3 to the Public Card Vault Platform 24 passing along the credential token and IMEI.
The Public Card Vault Platform is a repository of card names list for card owner's mobile device. Any card owner who wishes to create his card vault list would come to a Web based interface and create a new account for his mobile device by providing his/her mobile device's IMEI number and account credential token (i.e. voice token) and then s/he would select from the list of card names by financial institution. For each card name selected the card owner would provide last 2 digits of his/her card number, a credential token type for the card, and s/he would assign his own friendly display name for the card.
-4-The Card Vault Provider would store the card's financial Institution BIN
number, last 2 digits of the card, display name, credential token type for each card selected and also credential token and its status (i.e. required/optional) for the account itself.
The Service Provider 21 sends the card name list obtained form the Public Card Vault Platform 24 to the Mobile Device 22 with SelectCard message 4. The card owner 23 selects one of the card names and action GetSelection 5 depicts that process.
Once the Service Provider 21 receives the card name selection information it sends the GetPreAuth request message 6 to the Card Validation Platform 25 passing along the amount, credential token for the card (i.e. voice token), IEMI, card BIN, and last 2 digits of the card. Based on that data set (voice token, Card BIN, and last 2 digits of the card, IMEI) the Card Validation Platform 25 can identify the card account and performs preauthorization for the requested amount. If the preauthorization succeeds then the Card Validation Platform 25 generates temporary Card token and sends it back to the Service Provider 21 in response. Of course the pre-requisite is that the card owner updates his card account with the card issuer and associates his card with IMEI and phone number of his mobile device.
Next, the Service Provider 21 sends GetAuth message 7 to the Card Validation Platform 25 passing along the transaction amount and card token. The Card Validation Platform 25 performs final authorization of the payment and sends back to the Service Provider 21 public portion of the authorization token for the authorized payment and check digit of private part of the authorization token. At the same time the Card Validation Platform 25 sends unsolicited SMS Notify message 8 to the card owner's phone number along with the card token and private part of the authorization token.
number, last 2 digits of the card, display name, credential token type for each card selected and also credential token and its status (i.e. required/optional) for the account itself.
The Service Provider 21 sends the card name list obtained form the Public Card Vault Platform 24 to the Mobile Device 22 with SelectCard message 4. The card owner 23 selects one of the card names and action GetSelection 5 depicts that process.
Once the Service Provider 21 receives the card name selection information it sends the GetPreAuth request message 6 to the Card Validation Platform 25 passing along the amount, credential token for the card (i.e. voice token), IEMI, card BIN, and last 2 digits of the card. Based on that data set (voice token, Card BIN, and last 2 digits of the card, IMEI) the Card Validation Platform 25 can identify the card account and performs preauthorization for the requested amount. If the preauthorization succeeds then the Card Validation Platform 25 generates temporary Card token and sends it back to the Service Provider 21 in response. Of course the pre-requisite is that the card owner updates his card account with the card issuer and associates his card with IMEI and phone number of his mobile device.
Next, the Service Provider 21 sends GetAuth message 7 to the Card Validation Platform 25 passing along the transaction amount and card token. The Card Validation Platform 25 performs final authorization of the payment and sends back to the Service Provider 21 public portion of the authorization token for the authorized payment and check digit of private part of the authorization token. At the same time the Card Validation Platform 25 sends unsolicited SMS Notify message 8 to the card owner's phone number along with the card token and private part of the authorization token.
-5-Once the Mobile Device 22 receives the SMS (Short Message Service) Notify message 8, it presents the Card Owner 23 the option to authorize the transaction 9. If the card owner selects to authorize the transaction then the Mobile Device 22 sends Authorize message 10 to the Service Provider 21 along with the card token and the private portion of the authorization token and by doing that it completes the payment transaction.
At this moment the Service Provider 21 has both public and private authorization tokens for a given card token so it verify private authorization tokens' check digit and then it can send Settle message 11 to the Card Validation Platform 25 to instruct the Card Validation Platform to transfer the money.
Note:
The described flow of messages assumes that the Credential Token Type specified for the cards in the Card Vault server is a 'Voice Token Type' so there is no need to ask card owner for the credential token after his selection of a card from the list. If this is not the case then another message 1 will be sent between the Service Provider 21 and the Mobile Device 22 requesting credential token for the selected card.
Alternate Mode For Carrying Out the Invention An alternate embodiment of the present invention can be applicable for closed card environments like Loyalty cards or private credit cards. In those systems the card can be accepted only at specific retail locations where the issuer of the private card provides transaction processing for those cards. In the embodiment of the present invention for the Loyalty type card systems the wireless devices' IMEI becomes the 'card' number therefore there will be substantial savings in operation of those systems.
At this moment the Service Provider 21 has both public and private authorization tokens for a given card token so it verify private authorization tokens' check digit and then it can send Settle message 11 to the Card Validation Platform 25 to instruct the Card Validation Platform to transfer the money.
Note:
The described flow of messages assumes that the Credential Token Type specified for the cards in the Card Vault server is a 'Voice Token Type' so there is no need to ask card owner for the credential token after his selection of a card from the list. If this is not the case then another message 1 will be sent between the Service Provider 21 and the Mobile Device 22 requesting credential token for the selected card.
Alternate Mode For Carrying Out the Invention An alternate embodiment of the present invention can be applicable for closed card environments like Loyalty cards or private credit cards. In those systems the card can be accepted only at specific retail locations where the issuer of the private card provides transaction processing for those cards. In the embodiment of the present invention for the Loyalty type card systems the wireless devices' IMEI becomes the 'card' number therefore there will be substantial savings in operation of those systems.
-6-The closed card transaction processing system would perform two major functions from the point of view of the present invention. First it would provide functionality of the Public Card Vault Platform 24 (Fig 1), and second it would store cross-reference between the Loyalty card in the form of the 1MIE number and the real credit card number provided by the loyalty card holder.
Referring now to the drawings and particularly to Figure 2 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider, which in alternate embodiment is the Bluetooth(trade mark) Service Provider 21, is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Loyalty Server 24. The Loyalty Server 24 is responsible for maintaining the credit card names list and the correlation of the credit card numbers to the Loyalty card in the form of the IMIE number. Also the Loyalty Server 24 is responsible for interaction with the Card Validation Platform 25 to perform credit card transaction authorization.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in alternate embodiment is Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending Get Credential request message 1 to the Mobile Device 22. The credential token could be PIN, password or any biometric reading of the card owner's body (voice, retina scan,
Referring now to the drawings and particularly to Figure 2 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider, which in alternate embodiment is the Bluetooth(trade mark) Service Provider 21, is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Loyalty Server 24. The Loyalty Server 24 is responsible for maintaining the credit card names list and the correlation of the credit card numbers to the Loyalty card in the form of the IMIE number. Also the Loyalty Server 24 is responsible for interaction with the Card Validation Platform 25 to perform credit card transaction authorization.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in alternate embodiment is Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending Get Credential request message 1 to the Mobile Device 22. The credential token could be PIN, password or any biometric reading of the card owner's body (voice, retina scan,
-7-etc.), which in the alternate embodiment is a voice token provided by the Card Owner 23 represented by activity Get Credential 2.
The Mobile Device 22 sends the credential token back to the Service Provider along with its (Mobile Device 22) International Mobile Equipment Identity (IMEI).
Next, the Service Provider 21 sends Get Card List request message 3 to the Loyalty Server 24, passing along the credential token and IMEI.
The Loyalty Server 24 is also fulfilling role of the Public Card Vault provider with one difference that the cardholder would also provide the credit card number and its expiration date. The Loyalty Server 24 would store securely the credit card number, its expiration date along with other data elements of standard Card Vault provider. The Loyalty Server 24 would become a trusted server once the cardholder releases the credit card information.
The Loyalty Server sends back the card name list along with the temporary Card token for each card name on the list.
The Service Provider 21 sends the card name list obtained form the Loyalty Server 24 to the Mobile Device 22 with Select Card message 4. The Card Owner selects one of the card names and action Get Selection 5 depicts that process.
This step can be omitted if there is only one card on the list.
Once the Service Provider 21 receives the card selection information, or there is only one card on the list, it sends the Get Auth request message 6 to the Loyalty Server 24, passing along the amount and the card token. Based on that data set the Loyalty Server 24 retrieves the correlated credit card number for that card token and sends Get Card Auth message 7 to the Card Validation Platform 25. The Card Validation Platform
The Mobile Device 22 sends the credential token back to the Service Provider along with its (Mobile Device 22) International Mobile Equipment Identity (IMEI).
Next, the Service Provider 21 sends Get Card List request message 3 to the Loyalty Server 24, passing along the credential token and IMEI.
The Loyalty Server 24 is also fulfilling role of the Public Card Vault provider with one difference that the cardholder would also provide the credit card number and its expiration date. The Loyalty Server 24 would store securely the credit card number, its expiration date along with other data elements of standard Card Vault provider. The Loyalty Server 24 would become a trusted server once the cardholder releases the credit card information.
The Loyalty Server sends back the card name list along with the temporary Card token for each card name on the list.
The Service Provider 21 sends the card name list obtained form the Loyalty Server 24 to the Mobile Device 22 with Select Card message 4. The Card Owner selects one of the card names and action Get Selection 5 depicts that process.
This step can be omitted if there is only one card on the list.
Once the Service Provider 21 receives the card selection information, or there is only one card on the list, it sends the Get Auth request message 6 to the Loyalty Server 24, passing along the amount and the card token. Based on that data set the Loyalty Server 24 retrieves the correlated credit card number for that card token and sends Get Card Auth message 7 to the Card Validation Platform 25. The Card Validation Platform
-8-25 performs its normal authorization processing and sends back the authorization number. The Loyalty Server stores the authorization information received from the Card Validation Platform 25 and generates its own Private and Public authorization tokens.
Next, the Loyalty Server 24 sends Auth Resp message 8 back to the Service Provider 21 with public portion of the authorization token for the authorized payment and check digit of private portion of the authorization token. At the same time the Loyalty Server 24 sends unsolicited SMS Notify message 9 to the card owner phone number along with card token and private authorization token.
Once the Mobile Device 22 receives the SMS Notify message 9, it presents the Card Owner 23 the option to authorize the transaction 10. If the card owner selects to authorize the transaction then the Mobile Device 22 sends Authorize message 11 to the Service Provider 21 along with card token and the private authorization token and by doing that it completes the payment transaction.
At this moment the Service Provider 21 has both public and private authorization tokens for a given card token so it verify the check digit of private authorization token and then it can send Settle message 12 to the Loyalty Server 24, which in turn correlates the message to the real authorization information and sends Settle message 13 to the Card Validation Platform 25 to instruct the back to transfer the money.
Notification Mode For Carrying Out the Invention Another alternate embodiment of the present invention can be applicable as security enhancement to the current credit cart authorization systems.
Implementation of the present invention in the notification mode brings the card owner into the loop of the credit card authorization process. This mode is not fully secured from the perspective of
Next, the Loyalty Server 24 sends Auth Resp message 8 back to the Service Provider 21 with public portion of the authorization token for the authorized payment and check digit of private portion of the authorization token. At the same time the Loyalty Server 24 sends unsolicited SMS Notify message 9 to the card owner phone number along with card token and private authorization token.
Once the Mobile Device 22 receives the SMS Notify message 9, it presents the Card Owner 23 the option to authorize the transaction 10. If the card owner selects to authorize the transaction then the Mobile Device 22 sends Authorize message 11 to the Service Provider 21 along with card token and the private authorization token and by doing that it completes the payment transaction.
At this moment the Service Provider 21 has both public and private authorization tokens for a given card token so it verify the check digit of private authorization token and then it can send Settle message 12 to the Loyalty Server 24, which in turn correlates the message to the real authorization information and sends Settle message 13 to the Card Validation Platform 25 to instruct the back to transfer the money.
Notification Mode For Carrying Out the Invention Another alternate embodiment of the present invention can be applicable as security enhancement to the current credit cart authorization systems.
Implementation of the present invention in the notification mode brings the card owner into the loop of the credit card authorization process. This mode is not fully secured from the perspective of
-9-the card owner but it provides the card owner with a notification every time a credit card transaction is attempted and it gives the card owner time to contact the bank and stop the transaction from going through settlement process.
Referring now to the drawings and particularly to Figure 3 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention in the notification mode, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, service provider, which in alternate embodiment is the Bluetooth(trade mark) Service Provider 21, is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Card Validation Platform 24. The Card Validation Platform 24 performs credit card transaction authorization.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in alternate embodiment is Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending Get Card Info request message 1 to the Mobile Device 22, passing along the Reference Number to be used for subsequent authorization messages. The card information can be keyed in by the card owner (not practical), or retrieved from any type of secure storage applications on the Mobile Device 22 like `Nokia(trade mark) Wallet'.
The Mobile Device 22 sends the card information to the Service Provider 21 along with its (Mobile Device 22) International Mobile Equipment Identity (IMEI).
Next the Service Provider 21 sends Get Auth request message 3 to the Card Validation Platform 24 passing along all information required by the currently defined credit card authorization protocols. Note that there is no change to the interaction between the Service Provider 21 and the Card Validation Platform 24 as we know it today.
Next, Card Validation Platform 24 sends Auth Resp message 4 back to the Service Provider 21 with the transaction reference number and authorization number.
Again note that there is no change to the interaction between the Service Provider 21 and the Card Validation Platform 24 as we know it today. At the same time the Card Validation Platform 24 sends unsolicited SMS Notify message 5 to the card owner's phone number along with a copy of the Auth Resp message 4 sent to the Service Provider 21. The Card Validation Platform needs to maintain correlation between the credit card number and the card owner's cell phone number in order to support the notification mode of the present invention.
Once the Mobile Device 22 receives the SMS Notify message 5, it presents the Card Owner 23 the option to authorize the transaction 6. If the card owner selects to authorize the transaction then the Mobile Device 22 sends Authorize message 7 to the Service Provider 21 along with received message from the Card Validation Platform 24 and by doing that it completes the payment transaction.
At this moment the Service Provider 21 compares the two messages and if they match then the transaction is authorized so it can send Settle message 8 to the Card Validation Platform 24.
Alternate Embodiment of Notification Mode For Carrying Out the Invention Another alternate embodiment of the present invention can be applicable as security enhancement to the existing credit cart authorization systems. This implementation of the present invention in the notification mode brings the card owner into the loop of the credit card authorization process. The card owner gets notification every time his credit card it used to perform transaction authorization and it gives the card owner time to contact the bank and stop the transaction from going through settlement process when the card owner perceives the transaction as fraudulent.
Referring now to the drawings and particularly to Figure 4 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention in the notification mode, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider 21 is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Card Validation Platform 24. The Card Validation Platform 24 performs credit card transaction authorization.
The Service Provider 21 sends Get Auth request message 1 to the Card Validation Platform 24 passing along credit card information obtained from the card owner in any presently known systems.
Next, the Card Validation Platform 24 sends Auth Resp message 2 back to the Service Provider 21 with the transaction reference number and authorization number. At the same time the Card Validation Platform 24 sends unsolicited SMS Notify message 3 to the card owner phone number along with a copy of the Auth Resp message 4 sent to the Service Provider 21. The bank needs to maintain correlation between the credit card number and the card owner's cell phone number in order to support the notification mode of the present invention.
The Card Owner 23 can review the notification messages and act when any of the transaction appears to be fraudulent.
Referring now to the drawings and particularly to Figure 3 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention in the notification mode, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, service provider, which in alternate embodiment is the Bluetooth(trade mark) Service Provider 21, is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Card Validation Platform 24. The Card Validation Platform 24 performs credit card transaction authorization.
The card owner generally indicated 23, operates his Mobile Device 22 that is used to interact with Service Provider 21. The server uses some sort of interaction protocol, which in alternate embodiment is Bluetooth(trade mark) Profile, to exchange messages with Mobile Device 22.
The card payment process starts with the Service Provider 21 sending Get Card Info request message 1 to the Mobile Device 22, passing along the Reference Number to be used for subsequent authorization messages. The card information can be keyed in by the card owner (not practical), or retrieved from any type of secure storage applications on the Mobile Device 22 like `Nokia(trade mark) Wallet'.
The Mobile Device 22 sends the card information to the Service Provider 21 along with its (Mobile Device 22) International Mobile Equipment Identity (IMEI).
Next the Service Provider 21 sends Get Auth request message 3 to the Card Validation Platform 24 passing along all information required by the currently defined credit card authorization protocols. Note that there is no change to the interaction between the Service Provider 21 and the Card Validation Platform 24 as we know it today.
Next, Card Validation Platform 24 sends Auth Resp message 4 back to the Service Provider 21 with the transaction reference number and authorization number.
Again note that there is no change to the interaction between the Service Provider 21 and the Card Validation Platform 24 as we know it today. At the same time the Card Validation Platform 24 sends unsolicited SMS Notify message 5 to the card owner's phone number along with a copy of the Auth Resp message 4 sent to the Service Provider 21. The Card Validation Platform needs to maintain correlation between the credit card number and the card owner's cell phone number in order to support the notification mode of the present invention.
Once the Mobile Device 22 receives the SMS Notify message 5, it presents the Card Owner 23 the option to authorize the transaction 6. If the card owner selects to authorize the transaction then the Mobile Device 22 sends Authorize message 7 to the Service Provider 21 along with received message from the Card Validation Platform 24 and by doing that it completes the payment transaction.
At this moment the Service Provider 21 compares the two messages and if they match then the transaction is authorized so it can send Settle message 8 to the Card Validation Platform 24.
Alternate Embodiment of Notification Mode For Carrying Out the Invention Another alternate embodiment of the present invention can be applicable as security enhancement to the existing credit cart authorization systems. This implementation of the present invention in the notification mode brings the card owner into the loop of the credit card authorization process. The card owner gets notification every time his credit card it used to perform transaction authorization and it gives the card owner time to contact the bank and stop the transaction from going through settlement process when the card owner perceives the transaction as fraudulent.
Referring now to the drawings and particularly to Figure 4 there is shown therein a schematic view of a transaction authorization process carried out with an alternate embodiment of the system of the present invention in the notification mode, which process is generally indicated 20. In the transaction authorization process carried out in connection with the invention, Service Provider 21 is operated at the retailer location and is responsible for managing interaction with Card Owner 23 and the Card Validation Platform 24. The Card Validation Platform 24 performs credit card transaction authorization.
The Service Provider 21 sends Get Auth request message 1 to the Card Validation Platform 24 passing along credit card information obtained from the card owner in any presently known systems.
Next, the Card Validation Platform 24 sends Auth Resp message 2 back to the Service Provider 21 with the transaction reference number and authorization number. At the same time the Card Validation Platform 24 sends unsolicited SMS Notify message 3 to the card owner phone number along with a copy of the Auth Resp message 4 sent to the Service Provider 21. The bank needs to maintain correlation between the credit card number and the card owner's cell phone number in order to support the notification mode of the present invention.
The Card Owner 23 can review the notification messages and act when any of the transaction appears to be fraudulent.
Claims (8)
1. A wireless data processing method for credit card payment authorization by transmitting data representing a public part of a payment authorization token from a validation platform to a service provider, and by transmitting data representing a private part of payment authorization token from a validation platform to a mobile device and by transmitting a private part of payment authorization token from a mobile device to a service provider, comprising:
transmitting data, including a personal virtual identity representing by IMEI
(International Mobile Equipment Identity) number and partial credit card account data, representing said payment authorization request directly from said service provider to said validation platform connected via private communication networks;
transmitting data representing at least certain payment authorization request data entered by said service provider with said validation platform generating a private part of payment authorization token from said validation platform, with data representing a short message to said mobile device of a customer and displaying said short message on said mobile device, prompting for validation of said credit card payment authorization request; upon receiving data representing said customer validation credit card payment authorization request including said private part of payment authorization token and transaction details, for sending a copy of said short message to said service provider from said mobile device;
transmitting data representing at least certain payment authorization request data entered by said service provider with validation platform generated public part of payment authorization token and check digit of said private part of payment authorization token from said validation platform back to said service provider; and combining said private part of payment authorization token with said public part of payment authorization token by said service provider into a final data representing the complete payment authorization token, and transmitting data, representing the complete token with at least certain payment authorization request data to said validation platform for settlement of the credit card payment.
transmitting data, including a personal virtual identity representing by IMEI
(International Mobile Equipment Identity) number and partial credit card account data, representing said payment authorization request directly from said service provider to said validation platform connected via private communication networks;
transmitting data representing at least certain payment authorization request data entered by said service provider with said validation platform generating a private part of payment authorization token from said validation platform, with data representing a short message to said mobile device of a customer and displaying said short message on said mobile device, prompting for validation of said credit card payment authorization request; upon receiving data representing said customer validation credit card payment authorization request including said private part of payment authorization token and transaction details, for sending a copy of said short message to said service provider from said mobile device;
transmitting data representing at least certain payment authorization request data entered by said service provider with validation platform generated public part of payment authorization token and check digit of said private part of payment authorization token from said validation platform back to said service provider; and combining said private part of payment authorization token with said public part of payment authorization token by said service provider into a final data representing the complete payment authorization token, and transmitting data, representing the complete token with at least certain payment authorization request data to said validation platform for settlement of the credit card payment.
2. A data processing method according to Claim 1 wherein said short message is a Short Message Service (SMS) message.
3. A data processing method according to Claim 1 wherein said short message is an Unstructured Supplementary Service (USSD) message.
4. A data processing method according to Claim 1 wherein said customer validates credit card payment authorization request by entering a password verified against passwords stored in a Subscriber Identity Module (SIM) card of said mobile device.
5. A data processing method according to Claim 1 wherein said customer validates credit card payment authorization request by entering a password accepting wireless connection to said service provider.
6. A data processing method according to Claim 1 wherein said credit card is a bank credit card.
7. A data processing method according to Claim 1 wherein said wireless communication network includes selectively an infrared wireless network, a Short Message Service (SMS) network, and emails.
8. A data processing system according to Claim 1 wherein said wireless communication network is an interface provided by said service provider and said private part of payment authorization token is entered manually into said interface.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2475275A CA2475275C (en) | 2004-07-20 | 2004-07-20 | Wireless data processing system for credit payment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2475275A CA2475275C (en) | 2004-07-20 | 2004-07-20 | Wireless data processing system for credit payment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2475275A1 CA2475275A1 (en) | 2006-01-20 |
| CA2475275C true CA2475275C (en) | 2015-06-16 |
Family
ID=35637006
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2475275A Expired - Fee Related CA2475275C (en) | 2004-07-20 | 2004-07-20 | Wireless data processing system for credit payment |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2475275C (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090127334A1 (en) | 2007-11-19 | 2009-05-21 | Korea Information & Communications Co.,Ltd. | Method for Processing Settlement by VoIP Terminal and Recording Medium |
| EP2733869A1 (en) * | 2012-11-14 | 2014-05-21 | Gemalto SA | Method of communication using coded patterns |
| CN109285247B (en) * | 2015-07-06 | 2021-03-09 | 福建省新泽尔资讯科技有限公司 | Bluetooth unlocking method capable of simultaneously activating one-card function |
-
2004
- 2004-07-20 CA CA2475275A patent/CA2475275C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2475275A1 (en) | 2006-01-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7014107B2 (en) | Wireless payment processing system | |
| US7533065B2 (en) | Advanced method and arrangement for performing electronic payment transactions | |
| US8046261B2 (en) | EMV transaction in mobile terminals | |
| US20190356489A1 (en) | Method and system for access token processing | |
| US9846866B2 (en) | Processing of financial transactions using debit networks | |
| CN111357025A (en) | Secure QR code services | |
| US20090150248A1 (en) | System for enhancing payment security, method thereof and payment center | |
| US20130226721A1 (en) | Method and apparatus enabling improved protection of consumer information in electronic transactions | |
| US20030191945A1 (en) | System and method for secure credit and debit card transactions | |
| US8055581B2 (en) | Management of financial transactions using debit networks | |
| US10922690B2 (en) | System and method for purchasing using biometric authentication | |
| WO2003044710A1 (en) | Apparatus, method and system for payment using a mobile device | |
| CN115907763A (en) | Providing payment credentials to a consumer | |
| US20010005832A1 (en) | Transaction system and method | |
| MX2011003056A (en) | Apparatus and method for preventing unauthorized access to payment application installed in contactless payment device. | |
| JP2013529327A (en) | A secure and sharable payment system using trusted personal devices | |
| NZ535428A (en) | System and method for secure credit and debit card transactions using dynamic random CVV2 code to mobile communications device | |
| CN105556550A (en) | Method for securing a validation step of an online transaction | |
| KR102574524B1 (en) | Remote transaction system, method and point of sale terminal | |
| CN110574032A (en) | system and method for generating access credentials | |
| WO2011056156A1 (en) | A mobile payment method of high security and authorization system for this method | |
| MX2012010196A (en) | Method and system for performing a transaction. | |
| Almuairfi et al. | Anonymous proximity mobile payment (APMP) | |
| CA2475275C (en) | Wireless data processing system for credit payment | |
| Madlmayr et al. | Secure communication between web browsers and NFC targets by the example of an e-ticketing system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20180720 |