WO2004090825A1 - System for secure transactions - Google Patents

System for secure transactions Download PDF

Info

Publication number
WO2004090825A1
WO2004090825A1 PCT/EP2004/003792 EP2004003792W WO2004090825A1 WO 2004090825 A1 WO2004090825 A1 WO 2004090825A1 EP 2004003792 W EP2004003792 W EP 2004003792W WO 2004090825 A1 WO2004090825 A1 WO 2004090825A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
account
card
server
state
Prior art date
Application number
PCT/EP2004/003792
Other languages
French (fr)
Inventor
Mary C. Martyn
Mike Feerick
Original Assignee
Secure Transaction Processing Limited
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Secure Transaction Processing Limited filed Critical Secure Transaction Processing Limited
Publication of WO2004090825A1 publication Critical patent/WO2004090825A1/en

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/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/322—Aspects of commerce using mobile devices [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/08—Payment architectures
    • G06Q20/16—Payments settled via telecommunication 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/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/342—Cards defining paid or billed services or quantities
    • 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
    • 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/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered

Definitions

  • This invention relates in general to an auxiliary means of verifying the identity of an individual within a system where security is of paramount importance.
  • This identity verification is carried out using telephony technologies like TUIs (telephony user interfaces), GUIs (graphical user interfaces on mobile phones and the like) and/or IVRs (interactive voice response).
  • TUIs telephony user interfaces
  • GUIs graphical user interfaces on mobile phones and the like
  • IVRs interactive voice response
  • Credit card verification systems at present rely on numerous different means of linking the credit card holder to the credit card.
  • face to face transactions as in those done in person in shops, the cashier asks the card holder for his/her signature, which the former then matches to that on the back of the card. If the signatures match, the cashier assumes that the cardholder is indeed the legitimate owner of the card.
  • the credit card is "swiped", at which point authorisation for the transaction is requested. This authorisation normally checks cash limit on the card, expiry dates etc.
  • signatures can be forged thus providing a security loop-hole. Actions occurring over the telephone or the web are even less secure.
  • the present invention provides a system for enabling transactions, comprising: a server maintaining account records with approval indications; and means for establishing secure communication between an account user and a corresponding account record for enabling the account user to selectively control a state of the approval indication for the account to thereby control activation and deactivation of the account.
  • the means for establishing secure communication may comprise a user part and a server part and a communications link therebetween.
  • One application of the invention is in performing authorised transactions on credit cards or similar account tokens.
  • a credit card holder would be given the means to control the status of his or her account by (for example) a short digit code or spoken phrase which, through the use of a telephony user interface (TUT), a graphical user interface (GUI), on a mobile telephone or by an interactive voice response (IVR) system, could authorise a transaction in advance of the transaction being initiated.
  • TUT telephony user interface
  • GUI graphical user interface
  • IVR interactive voice response
  • a cardholder's identity would be established after which he or she would have the ability to use the card. He or she could therefore "switch on/off the credit card as required for use. Additionally or in the alternative, he or she could permit a certain number of transactions with the credit card, i.e. allow transactions with the credit card for a certain period/periods of time, set limits on the credit card, set amounts for subsequent transactions etc - all via the phone/mobile phone/handheld device or personal digital assistant (PDA).
  • PDA personal digital assistant
  • the means for establishing secure communication comprises means for the user to provide an authentication code to the server part.
  • the user part may be a telephone and the server part may comprise a prerecorded menu of user selections.
  • the telephone may provide digital symbols to the server part and the server part may have means responsive to digital symbols received from the user part for identifying a code entered by the user in the user part and for selectively controlling the state of the approval indication in response to symbols received.
  • the server part further comprises a voice recogniser for recognising voice commands from the user part, and means responsive to the voice recogniser for identifying a code given by the user in the user part and for selectively controlling the state of the approval indication in response to spoken commands received. Where a GUI is provided in the user part, this can enable a user to selectively enter an identifying code and to selectively control the state of approval indication.
  • the means for establishing secure communication may enable the account user to selectively activate and deactivate the account.
  • a further feature may be that the server part comprises a timer settable by the user by means of the communication link, whereby the state of approval indication is settable by the user to an approved state.
  • the server part has means for causing the indication to revert a different state responsive to the timer.
  • the server part may comprises a counter for counting transactions for a given account, wherein the counter is settable by the user by means of the communication link and wherein the server part has means for causing the indication to change from an approved state to a different state responsive to the counter.
  • the counter may be a value counter that counts the value of transactions to a user-settable limit.
  • a method of enabling a user account for a transaction comprising: establishing a first communication path between a user having an authentication token (e.g. a credit card) and a database having a record for that token, user selectively causing the database to record, for that token, that the account is enabled for at least one transaction using the first communication path, upon presentation of the token to a merchant, providing a second communication path between the merchant and the database for a transaction to be initiated and causing the transaction to proceed if the record for the token indicates that the account is enabled.
  • an authentication token e.g. a credit card
  • Figure 1 shows a system in accordance with the present invention for the purposes of illustrating a first example of use and operation of the invention.
  • FIG. 1 illustrates details of the card verification/authorisation system of Figure 1.
  • FIGs. 3 and 4 show alternative arrangements of the system of Figure 1 for the purposes of illustrating second and third examples of use and operation of the invention.
  • the system comprises a user part in the form of a telephone 10 (which may be fixed or mobile), a communications network 12, a telephony application server 14, and a card verification/authorisation system 16.
  • the telephony application 14 has a network interface 20 for receiving and answering calls from the network 12, a stored application menu 22, a user response receiver 24, a user identifier 26 and a control function 28.
  • a further connection 29 (e.g. a wideband internet connection) connects the telephony application server 14 with the card verification/authorisation system 16.
  • the operation will be described in the context of a user 30 wishing to make a transaction, for example he (or she) wishes to buy a shirt in a store, using a credit card.
  • the user 30 first calls a predefined number, which directs the call through the network 12 to the telephony application server 14 connected to the card verification/authorisation system 16.
  • the telephony application server 14 establishes the identity of the user 30. This is preferably achieved as follows.
  • a pre-recorded voice message stored in menu 22 requests a numeric identification (ID) and personal identification number
  • the user 30 provides the LD in response to a request from the menu 22 using a numeric keypad on the telephone 10, and the ID is received at the receiver 24 and provided to the identifier 26.
  • the menu 22 then (under control of the control function 28) requests the PLN, or preferably just a portion of a larger PIN, and the response received at the receiver 24 is also supplied to the identifier 26. If the PLN is correct for the particular ID, the identifier 26 responds to the application control function 28 to confirm that the user 30 has been correctly identified.
  • the telephony application server 14 is preferably a server of a mobile telephone operator.
  • the identifier 26 can be remotely located from the telephony application server 14, e.g. it can be located on another server of the mobile telephone operator or at the card verification authorisation system 16.
  • the receiver 24 can include a voice recogniser to recognise spoken digits and/or letters or other commands.
  • Alternative embodiments for identifying the user include use of the caller's line identification (CLID), use of the caller's CLID together with the entry of a PIN, and can also include voice recognition, or a combination of two or more of CLID, ID, PLN and voice recognition.
  • CLID caller's line identification
  • PIN public key infrastructure
  • the communications channel between the user part (telephone 10) and the telephony application server 14 has been described in the context of a circuit-switched voice channel through the network 12. It will be appreciated that it may alternatively use a packet switched channel employing short message service (SMS) technology. If SMS technology is used, voice commands may be encoded in the menu 22 for sending as packetised coded voice back to the user 30 through the network 12 or, if such voice commands files are too large, they may be pre-stored at the user part 10 for annunciation in response to simple codes received from the telephony application 14.
  • SMS short message service
  • the control function 28 causes the menu 22 to present a further telephone user interface (TUI) with which the user 30 can set the status of the card.
  • TTI telephone user interface
  • a sample menu might be:- "Press 1 to activate the card, press 2 to deactivate the card, press 3 to activate for one transaction, press 4 to activate for a number of transactions, press 5 to activate for period of time".
  • an appropriate option for the user is option 3, i.e. to activate the card for one transaction only.
  • the card verification/authorisation system 16 In informing the card verification/authorisation system 16 of the user's choice, the card verification/authorisation system 16 is provided with the identity of the user 30 and the particular response provided by the user. The card verification/authorisation system 16 may have to perform a look-up operation to identify the user within the domain of the card verification/authorisation system. Once the user 30 is uniquely identified to the card verification/authorisation system 16, that system locates a record for the user, updates an associated database field accordingly, and informs the control function 28 of the telephony application 14 that this has been done. When the telephony application server 14 is informed of successful completion of the operation, the control function 28 causes the menu 22 to deliver a final message to the caller and the user 30 can hang up.
  • the card verification/authorisation system 16 fails to recognise the user or determines that the user's account is blocked (e.g. because it is in arrears) or otherwise identifies an error, an error message is returned by the card verification authorisation system 16 to the telephony application server 14 and the control function 28 causes the menu 22 to generate an appropriate error message to deliver to the user. It is preferred that the control function 28 of the telephony application server recognises more than one error message from the card verification/authorisation system 16 and that the menu has more than one error response pre-stored for delivery to the user 30 in response to different error messages from the card verification/authorisation system 16.
  • the card verification/authorisation system 16 When the card verification/authorisation system 16 has successfully recorded that the user's account is enabled (e.g. enabled for a single transaction), the user 30 can now present his credit card to a cashier 32 to pay for the shirt.
  • the card processing modem 34 calls the card verification/authorisation system 16 through the network 12' (which may be the same network as network 12 but need not be) and the card verification/authorisation system 16 checks the status of the card. In this example (in addition to any other checks that the card issuer might require, and assuming that all such checks are positive), it will see that the card is good for one transaction, thus authorising the transaction and resetting the card to its inactive state.
  • the telephony application server 14 has been described as separate from the card verification/authorisation system 16, it will be appreciated that these may be integrated into a single server or may be sub-divided into further servers.
  • FIG. 2 Additional details of the card verification/authorisation system 16 are shown in Figure 2.
  • the system comprises a first interface 50 for interfacing with the network 12', a second interface 52 for interfacing with the connection 29, a control function 54 communicating with these interfaces and a memory store or database 56 storing records in tables or equivalent format.
  • the interfaces 50 and 52 are combined in the same functional element.
  • Figure 2 illustrates, by way of example only, how the data in memory store 56 is preferably subdivided into records, with one line or column or record per user account. For each user account there are a number of data fields.
  • information received from telephony application server 14 uniquely identifies a user account in memory store 56. Further information received in the form of a user command causes a change in data field 60.
  • data field 60 may contain a number to be incremented.
  • control function 54 decrements the number in data field 60 each time there is a debit transaction (normally initiated through interface 50). Thus, when the value in data field 60 is zero, no further debits can be made against the account until the account user again increments the value in this data field by means of the telephony application server 14.
  • data field 60 may contain a value in terms of a sum of money.
  • data field 60 may contain a time value, for example a time marking a duration of a period of validity or an end of a period of validity.
  • a clock 62 marks the passing of time.
  • first and second times may be stored in data field 60 marking the start and end of a period of validity. If comparisons show that the current time is outside that range, the transaction is declined.
  • Other timer arrangements can readily be devised, such as regularly decrementing (e.g. every hour or every day) a value in data field 60.
  • the user 30 may have more than one credit, debit or other transaction card or token issued by the issuer maintaining the card verification/authorisation system 16. In this case, mere identification of the user to the card verification/authorisation system 16 is insufficient. In this case it is also necessary to identify to the card verification/authorisation system 16 the particular card or account to be enabled/disabled by the user 30. This can be achieved in a number of alternative ways. One way is for the card verification/authorisation system 16 to deliver a message to the telephony application server 14 requesting identification of the particular account (e.g. the last four digits of the account).
  • Another way is for the telephony application server 14 to request this information from the user up-front as a matter of routine, so that the user is identified not only in the domain of the telephony application server 14, but the specific account is identified in the domain of the card verification/authorisation system
  • the user may have credit, debit or other cards or tokens issued by more than one issuer and may wish to control several of these.
  • the telephony application server 14 can be provided with addresses (e.g. internet addresses) of more than one card verification/authorisation system.
  • addresses e.g. internet addresses
  • the telephony application server 14 is provided with a look-up table to look up the server address for the particular (four or more) digits entered. This look-up table can be expanded as more card issuers provide the facility contemplated by the present invention.
  • the system described can cause an SMS message to be sent to a user every time that user's credit card is used.
  • a message is sent to telephony application server 14 identifying the account and some detail of the transaction (e.g. the sum debited).
  • This information is compiled into the body of a SMS text message by a message generator (not shown), the mobile telephone number of the user corresponding to that account is identified by look-up means and the compiled SMS message is sent to the user.
  • the look-up means may be located in the card verification/authorisation system 16, in which case the information transferred to the telephony application server 14 consists of the mobile telephone number and the sum debited.
  • a filter in card verification/authorisation system 16 selects certain transactions for notification (e.g. transactions in excess of a predetermined limit, or an event representing a number of transactions in a given time period in excess of a predetermined limit, or a transaction that has been requested by a merchant outside a predetermined geographic region, e.g. as identified by telephone area code or country code or other indicator of origin).
  • FIG. 3 Another example application is that shown in Figure 3.
  • a user 30 wishes to make a transaction, e.g. again he wishes to buy a shirt in a store, on his credit card.
  • the card is in the inactive sate. Again the user 30 needs to activate the card for one transaction, however this time he does this using a client side GUI on a mobile phone 70, PDA or such handheld device 70 which communicates with the server 14 which in turn is linked to the card verification/authorisation system 16.
  • the menu 22 on server 14 presents exactly the same options as that presented by the TUI, but in the form of pre-stored graphic pages which are presented on a display of the handheld device 70. From these graphic pages presented, the user can select the aforementioned option, thus enabling the card again for one transaction.
  • the user can now pay the cashier for the shirt by his credit card. Again, when the cashier swipes the card for verification and authorisation, the card verification/authorisation system 16 will check the status of the card, where it will see that the card is good for one transaction thus authorising the transaction and resetting the card to its inactive state.
  • the communications channel between the user part and the server part may use a circuit-switched channel, but in this case it preferably uses SMS (e.g. Wireless Application Protocol) technology or GSM Packet Radio System (GPRS) technology.
  • SMS e.g. Wireless Application Protocol
  • GPRS GSM Packet Radio System
  • Example 3 A user 30 in Figure 4 wishes to make a cash withdrawal at an ATM 80
  • the ATM passes the details of the card to the card verification authorisation system 16 which checks the associated database field and sees that the card has been authorised for one transaction, thus sending back authorisation to the ATM and resetting the associated field back to its original state.
  • the user then takes the cash dispensed by the machine.
  • the present invention permits the introduction of a type of state-driven card.
  • the states of such a card can include the following:-
  • On/off i.e. Available for use and not available for use respectively
  • Available for use for a specific user settable value e.g. selected multiples of a currency value.
  • the present invention extends to use of a credit/debit card or other token, the authorisation state of which can be controUably enabled and disabled by its authorised user.
  • the concept in general could be used as a secondary means of authenticating the identity of any individual within a system, for example swipe card access to a building, remote dial in of a computer to a network etc.
  • a cardholder is able to change the state of his /her card, for example, switching it off, only switching it on when they need to use it.
  • the card details were stolen it could not be used or could quickly be de-activated, since it would only be turned on when the cardholder wished to use it.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Telephonic Communication Services (AREA)

Abstract

A system for secure transactions is provided comprising a server (16) maintaining account records with approval indications; and means such as a telephony application server (14) for establishing secure communication between an account user (30) and a corresponding account record for enabling the account user to selectively control a state of the approval indication to thereby control activation and deactivation of the account. The means for establishing secure communication preferably comprises a user part such as a telephone or mobile telephone (10) and a server part (14) and a communications link (12) therebetween.

Description

SYSTEM FOR SECURE TRANSACTIONS
Field of the Invention
This invention relates in general to an auxiliary means of verifying the identity of an individual within a system where security is of paramount importance. This identity verification is carried out using telephony technologies like TUIs (telephony user interfaces), GUIs (graphical user interfaces on mobile phones and the like) and/or IVRs (interactive voice response). The concept is in general aimed at, though not confined to, aiding the current security measures surrounding credit card transactions.
Background
Credit card verification systems at present rely on numerous different means of linking the credit card holder to the credit card. In "face to face" transactions as in those done in person in shops, the cashier asks the card holder for his/her signature, which the former then matches to that on the back of the card. If the signatures match, the cashier assumes that the cardholder is indeed the legitimate owner of the card. For authorisation the credit card is "swiped", at which point authorisation for the transaction is requested. This authorisation normally checks cash limit on the card, expiry dates etc. However signatures can be forged thus providing a security loop-hole. Actions occurring over the telephone or the web are even less secure. In most cases the retailer will ask the caller/on-line user, in addition to the card number, the name on the card, valid from date, the expiry date, and a PLN/code on the back of the card. These security measures are all compromised by the fact that all of the information requested is on the card itself. If it has been stolen, the card can be used by almost anyone. Furthermore, on line transactions with credit cards are open.to security risk even where SSL (secure socket layer) is implemented.
An increasing number of fraud incidents are now occurring using ATMs (automated teller machines). Fraudsters clone users' cards initially and then monitor them entering their PIN number while making withdrawals at ATM machines. With the cloned card and knowledge of the PIN the card can be used at will.
Many card issuers introduce a limited additional security step upon issuance of a credit or debit card by requiring that the account user places a telephone call to a call centre to acknowledge receipt of a new card before that card is enabled for use. On placing the call to the call centre, some form of authentication is requested to ensure that the caller is the intended recipient of the card. This additional step mitigates against errors in delivery of the new card through the mail service, but provides no further security thereafter.
Summary of the Invention
The present invention provides a system for enabling transactions, comprising: a server maintaining account records with approval indications; and means for establishing secure communication between an account user and a corresponding account record for enabling the account user to selectively control a state of the approval indication for the account to thereby control activation and deactivation of the account. The means for establishing secure communication may comprise a user part and a server part and a communications link therebetween. One application of the invention is in performing authorised transactions on credit cards or similar account tokens. A credit card holder would be given the means to control the status of his or her account by (for example) a short digit code or spoken phrase which, through the use of a telephony user interface (TUT), a graphical user interface (GUI), on a mobile telephone or by an interactive voice response (IVR) system, could authorise a transaction in advance of the transaction being initiated.
Using either interface, a cardholder's identity would be established after which he or she would have the ability to use the card. He or she could therefore "switch on/off the credit card as required for use. Additionally or in the alternative, he or she could permit a certain number of transactions with the credit card, i.e. allow transactions with the credit card for a certain period/periods of time, set limits on the credit card, set amounts for subsequent transactions etc - all via the phone/mobile phone/handheld device or personal digital assistant (PDA).
Accordingly it is preferred that the means for establishing secure communication comprises means for the user to provide an authentication code to the server part.
The user part may be a telephone and the server part may comprise a prerecorded menu of user selections. The telephone may provide digital symbols to the server part and the server part may have means responsive to digital symbols received from the user part for identifying a code entered by the user in the user part and for selectively controlling the state of the approval indication in response to symbols received. In one embodiment the server part further comprises a voice recogniser for recognising voice commands from the user part, and means responsive to the voice recogniser for identifying a code given by the user in the user part and for selectively controlling the state of the approval indication in response to spoken commands received. Where a GUI is provided in the user part, this can enable a user to selectively enter an identifying code and to selectively control the state of approval indication.
Thus, the means for establishing secure communication may enable the account user to selectively activate and deactivate the account.
A further feature may be that the server part comprises a timer settable by the user by means of the communication link, whereby the state of approval indication is settable by the user to an approved state. In this case the server part has means for causing the indication to revert a different state responsive to the timer.
The server part may comprises a counter for counting transactions for a given account, wherein the counter is settable by the user by means of the communication link and wherein the server part has means for causing the indication to change from an approved state to a different state responsive to the counter. The counter may be a value counter that counts the value of transactions to a user-settable limit.
In another aspect of the invention, a method of enabling a user account for a transaction is provided, comprising: establishing a first communication path between a user having an authentication token (e.g. a credit card) and a database having a record for that token, user selectively causing the database to record, for that token, that the account is enabled for at least one transaction using the first communication path, upon presentation of the token to a merchant, providing a second communication path between the merchant and the database for a transaction to be initiated and causing the transaction to proceed if the record for the token indicates that the account is enabled. Brief Description of the Drawings
Figure 1 shows a system in accordance with the present invention for the purposes of illustrating a first example of use and operation of the invention.
Figure 2 illustrates details of the card verification/authorisation system of Figure 1.
Figs. 3 and 4 show alternative arrangements of the system of Figure 1 for the purposes of illustrating second and third examples of use and operation of the invention.
Detailed Description of the Preferred Embodiments Three basic applicable examples of the invention are now described with reference to the drawings.
Example 1
One example of the application is that shown in Figure 1. The system comprises a user part in the form of a telephone 10 (which may be fixed or mobile), a communications network 12, a telephony application server 14, and a card verification/authorisation system 16.
The telephony application 14 has a network interface 20 for receiving and answering calls from the network 12, a stored application menu 22, a user response receiver 24, a user identifier 26 and a control function 28. A further connection 29 (e.g. a wideband internet connection) connects the telephony application server 14 with the card verification/authorisation system 16.
The operation will be described in the context of a user 30 wishing to make a transaction, for example he (or she) wishes to buy a shirt in a store, using a credit card. Let us assume in this case that the card is in the inactive sate. The user 30 first calls a predefined number, which directs the call through the network 12 to the telephony application server 14 connected to the card verification/authorisation system 16. On answering the call the telephony application server 14 establishes the identity of the user 30. This is preferably achieved as follows. A pre-recorded voice message stored in menu 22 requests a numeric identification (ID) and personal identification number
(PIN) from the user. In this preferred embodiment, the user 30 provides the LD in response to a request from the menu 22 using a numeric keypad on the telephone 10, and the ID is received at the receiver 24 and provided to the identifier 26. The menu 22 then (under control of the control function 28) requests the PLN, or preferably just a portion of a larger PIN, and the response received at the receiver 24 is also supplied to the identifier 26. If the PLN is correct for the particular ID, the identifier 26 responds to the application control function 28 to confirm that the user 30 has been correctly identified.
The telephony application server 14 is preferably a server of a mobile telephone operator. The identifier 26 can be remotely located from the telephony application server 14, e.g. it can be located on another server of the mobile telephone operator or at the card verification authorisation system 16.
Note that instead of using the numeric keypad 10 to enter an ID and/or a PIN, the receiver 24 can include a voice recogniser to recognise spoken digits and/or letters or other commands.
Alternative embodiments for identifying the user include use of the caller's line identification (CLID), use of the caller's CLID together with the entry of a PIN, and can also include voice recognition, or a combination of two or more of CLID, ID, PLN and voice recognition.
The communications channel between the user part (telephone 10) and the telephony application server 14 has been described in the context of a circuit-switched voice channel through the network 12. It will be appreciated that it may alternatively use a packet switched channel employing short message service (SMS) technology. If SMS technology is used, voice commands may be encoded in the menu 22 for sending as packetised coded voice back to the user 30 through the network 12 or, if such voice commands files are too large, they may be pre-stored at the user part 10 for annunciation in response to simple codes received from the telephony application 14.
Once the user 30 has been satisfactorily identified (within the domain of the telephony application server 14), the control function 28 causes the menu 22 to present a further telephone user interface (TUI) with which the user 30 can set the status of the card. A sample menu might be:- "Press 1 to activate the card, press 2 to deactivate the card, press 3 to activate for one transaction, press 4 to activate for a number of transactions, press 5 to activate for period of time". In this instance an appropriate option for the user is option 3, i.e. to activate the card for one transaction only. When this is done the card verification/authorisation system 16 is informed of the decision.
In informing the card verification/authorisation system 16 of the user's choice, the card verification/authorisation system 16 is provided with the identity of the user 30 and the particular response provided by the user. The card verification/authorisation system 16 may have to perform a look-up operation to identify the user within the domain of the card verification/authorisation system. Once the user 30 is uniquely identified to the card verification/authorisation system 16, that system locates a record for the user, updates an associated database field accordingly, and informs the control function 28 of the telephony application 14 that this has been done. When the telephony application server 14 is informed of successful completion of the operation, the control function 28 causes the menu 22 to deliver a final message to the caller and the user 30 can hang up.
If, upon presentation to the card verification/authorisation system 16 of the identity of the user 30, the card verification/authorisation system 16 fails to recognise the user or determines that the user's account is blocked (e.g. because it is in arrears) or otherwise identifies an error, an error message is returned by the card verification authorisation system 16 to the telephony application server 14 and the control function 28 causes the menu 22 to generate an appropriate error message to deliver to the user. It is preferred that the control function 28 of the telephony application server recognises more than one error message from the card verification/authorisation system 16 and that the menu has more than one error response pre-stored for delivery to the user 30 in response to different error messages from the card verification/authorisation system 16. When the card verification/authorisation system 16 has successfully recorded that the user's account is enabled (e.g. enabled for a single transaction), the user 30 can now present his credit card to a cashier 32 to pay for the shirt. When the cashier 32 swipes the card through a standard card processing modem 34 for verification and authorisation, the card processing modem 34 calls the card verification/authorisation system 16 through the network 12' (which may be the same network as network 12 but need not be) and the card verification/authorisation system 16 checks the status of the card. In this example (in addition to any other checks that the card issuer might require, and assuming that all such checks are positive), it will see that the card is good for one transaction, thus authorising the transaction and resetting the card to its inactive state. Although the telephony application server 14 has been described as separate from the card verification/authorisation system 16, it will be appreciated that these may be integrated into a single server or may be sub-divided into further servers.
Additional details of the card verification/authorisation system 16 are shown in Figure 2. The system comprises a first interface 50 for interfacing with the network 12', a second interface 52 for interfacing with the connection 29, a control function 54 communicating with these interfaces and a memory store or database 56 storing records in tables or equivalent format. In cases where the connection 29 between the telephony application server 14 and the card verification authorisation system 16 passes through the network 12', the interfaces 50 and 52 are combined in the same functional element. Figure 2 illustrates, by way of example only, how the data in memory store 56 is preferably subdivided into records, with one line or column or record per user account. For each user account there are a number of data fields. Typically, of course, there will be personal data fields (name and address data fields and the like) not relevant to the present invention. Typically there will also be account status data fields, including account balance, credit limit and a default status indicator to indicate if the account is in arrears and should be blocked against further debits. An additional field 60 is added which is controllable by the account user in accordance with the present invention.
In operation, information received from telephony application server 14 uniquely identifies a user account in memory store 56. Further information received in the form of a user command causes a change in data field 60. For example data field 60 may contain a number to be incremented. In this example, control function 54 decrements the number in data field 60 each time there is a debit transaction (normally initiated through interface 50). Thus, when the value in data field 60 is zero, no further debits can be made against the account until the account user again increments the value in this data field by means of the telephony application server 14. As another example, data field 60 may contain a value in terms of a sum of money. Each time a sum is debited from the account, the same sum is debited by control function 54 from the value in data field 60. The remaining value in data field 60 sets a limit for further transactions and when a transaction is attempted that exceeds the value in data field 60, such a transaction is declined and a refusal message is sent by control function 54 to interface 50 and on to the entity attempting the transaction. As a further example, data field 60 may contain a time value, for example a time marking a duration of a period of validity or an end of a period of validity. A clock 62 marks the passing of time. When a transaction is attempted, a comparison is made by control function 54 between the time value in field 60 and the clock 62. If the time value has been exceeded, a further transaction is declined and a refusal message is sent as before. As an alternative," first and second times may be stored in data field 60 marking the start and end of a period of validity. If comparisons show that the current time is outside that range, the transaction is declined. Other timer arrangements can readily be devised, such as regularly decrementing (e.g. every hour or every day) a value in data field 60.
The user 30 may have more than one credit, debit or other transaction card or token issued by the issuer maintaining the card verification/authorisation system 16. In this case, mere identification of the user to the card verification/authorisation system 16 is insufficient. In this case it is also necessary to identify to the card verification/authorisation system 16 the particular card or account to be enabled/disabled by the user 30. This can be achieved in a number of alternative ways. One way is for the card verification/authorisation system 16 to deliver a message to the telephony application server 14 requesting identification of the particular account (e.g. the last four digits of the account). Another way is for the telephony application server 14 to request this information from the user up-front as a matter of routine, so that the user is identified not only in the domain of the telephony application server 14, but the specific account is identified in the domain of the card verification/authorisation system
16.
The user may have credit, debit or other cards or tokens issued by more than one issuer and may wish to control several of these. To accommodate this need, the telephony application server 14 can be provided with addresses (e.g. internet addresses) of more than one card verification/authorisation system. In this embodiment the menu
22 asks the user to identify the card issuer. This can take the form of presenting a limited menu of supported card issuers from which to choose, or it can take the form of requesting entry of the first digits of the credit/debit card which identify the card issuer (e.g. the first four or more digits). In the latter case, the telephony application server 14 is provided with a look-up table to look up the server address for the particular (four or more) digits entered. This look-up table can be expanded as more card issuers provide the facility contemplated by the present invention.
As a further feature, possibly independent of other features described and claimed herein, the system described can cause an SMS message to be sent to a user every time that user's credit card is used. Whenever a transaction takes place in relation to an account in card verification/authorisation system 16, a message is sent to telephony application server 14 identifying the account and some detail of the transaction (e.g. the sum debited). This information is compiled into the body of a SMS text message by a message generator (not shown), the mobile telephone number of the user corresponding to that account is identified by look-up means and the compiled SMS message is sent to the user. The look-up means may be located in the card verification/authorisation system 16, in which case the information transferred to the telephony application server 14 consists of the mobile telephone number and the sum debited. As a further optional feature, such an SMS message is not sent upon every transaction, but a filter in card verification/authorisation system 16 selects certain transactions for notification (e.g. transactions in excess of a predetermined limit, or an event representing a number of transactions in a given time period in excess of a predetermined limit, or a transaction that has been requested by a merchant outside a predetermined geographic region, e.g. as identified by telephone area code or country code or other indicator of origin).
Example 2
Another example application is that shown in Figure 3. A user 30 wishes to make a transaction, e.g. again he wishes to buy a shirt in a store, on his credit card.
Again it will be assumed that the card is in the inactive sate. Again the user 30 needs to activate the card for one transaction, however this time he does this using a client side GUI on a mobile phone 70, PDA or such handheld device 70 which communicates with the server 14 which in turn is linked to the card verification/authorisation system 16.
The menu 22 on server 14 presents exactly the same options as that presented by the TUI, but in the form of pre-stored graphic pages which are presented on a display of the handheld device 70. From these graphic pages presented, the user can select the aforementioned option, thus enabling the card again for one transaction.
The user can now pay the cashier for the shirt by his credit card. Again, when the cashier swipes the card for verification and authorisation, the card verification/authorisation system 16 will check the status of the card, where it will see that the card is good for one transaction thus authorising the transaction and resetting the card to its inactive state.
As described in rela'tion to Example 1, the communications channel between the user part and the server part may use a circuit-switched channel, but in this case it preferably uses SMS (e.g. Wireless Application Protocol) technology or GSM Packet Radio System (GPRS) technology.
Example 3 A user 30 in Figure 4 wishes to make a cash withdrawal at an ATM 80
(Automated Teller Machine), again assuming that the card is in the inactive sate. He/she first calls the predefined number, which directs the call to the telephony application server 14 connected to the card verification authorisation system 16. Again, on answering the call the application establishes the identity of the caller and once this is done the application server provides the user 30 with a TUI with which he/she can set the status of the card. Again a sample menu might be:- "Press 1 to activate the card, press 2 to deactivate the card, press 3 to activate for one transaction, press 4 to activate for a number of transactions, press 5 to activate for period of time". In this instance option 3 is again an appropriate option for the user, i.e. to activate the card for one transaction only. When this is done the card verification/authorisation system 16 is informed of the decision and updates the associated database field accordingly, and the caller can hang up.
The user can now go to the ATM and withdraw cash in the usual way. When he/she puts the card into the machine and enter his PIN in the usual manner, the ATM passes the details of the card to the card verification authorisation system 16 which checks the associated database field and sees that the card has been authorised for one transaction, thus sending back authorisation to the ATM and resetting the associated field back to its original state. The user then takes the cash dispensed by the machine.
The above examples are merely illustrative. The concept could be further expanded to include authorisation of all electronic transfer of money using credit/debit cards.
The present invention permits the introduction of a type of state-driven card. The states of such a card can include the following:-
De-activated (i.e. card is de-activated and no further state changes are allowed) • Active (i.e. card is active and further state changes allowed)
On/off (i.e. Available for use and not available for use respectively) Available for use for one transaction Available for use for a specific number of transactions Available for use for a specific period of time. • Available for use for a specific user settable value (e.g. selected multiples of a currency value).
Available for use between time one and time two (i.e. multiple time periods) Accordingly, the present invention extends to use of a credit/debit card or other token, the authorisation state of which can be controUably enabled and disabled by its authorised user.
The concept in general could be used as a secondary means of authenticating the identity of any individual within a system, for example swipe card access to a building, remote dial in of a computer to a network etc. By this means, a cardholder is able to change the state of his /her card, for example, switching it off, only switching it on when they need to use it. Thus even if the card details were stolen it could not be used or could quickly be de-activated, since it would only be turned on when the cardholder wished to use it.

Claims

C L A I M S
1. A system for enabling transactions comprising: a server maintaining account records with approval indications; and means for establishing secure communication between an account user and a corresponding account record for enabling the account user to selectively control a state of the approval indication for the account to thereby control activation and deactivation of the account.
2. A system according to claim 1, wherein the means for establishing secure communication comprises a user part and a server part and a communications link therebetween.
3. A system according to claim 2, wherein the means for establishing secure communication comprises means for the user to provide an authentication code to the server part.
4. A system according to claim 2 or 3, wherein the user part is a telephone and the server part comprises a pre-recorded menu of user selections.
5. A system according to claim 4, wherein the telephone provides digital symbols to the server part and the server part has means responsive to digital symbols received from the user part for identifying a code entered by the user in the user part and for selectively controlling the state of the approval indication in response to symbols received.
6. A system according to claim 4, wherein the server part further comprises a voice recogniser for recognising voice commands from the user part, and means responsive to the voice recogniser for identifying a code given by the user in the user part and for selectively controlling the state of the approval indication in response to spoken commands received.
7. A system according to any one of claims 2 to 6, wherein the user part has a graphical user interface enabling a user to selectively enter an identifying code and to selectively control the state of approval mdication.
8. A system according to any one of claims 2 to 7, wherein the server part comprises a timer settable by the user by means of the communication link, whereby the state of approval indication is settable by the user to an approved state and wherein the server part has means for causing the indication to revert a different state responsive to the timer.
9. A system according to claim 8, wherein the timer is settable by the user to record a start time and an end time.
10. A system according to any one of claims 2 to 7, wherein the server part comprises a counter for counting transactions for a given account, wherein the counter is settable by the user by means of the communication link and wherein the server part has means for causing the indication to change from an approved state to a different state responsive to the counter.
11. A system according to claim 10, wherein the counter is a value counter that counts the value of transactions to a user-settable limit.
12. A system according to any one of the preceding claims, wherein short message service technology is used as a means of authorisation and status control.
13. A method of enabling a user account for a transaction, comprising: establishing a first communication path between a user having an authentication token and a database having a record for that token, user selectively causing the database to record, for that token, that the account is enabled for at least one transaction using the first communication path, upon presentation of the token to a merchant, providing a second communication path between the merchant and the database for a transaction to be initiated and causing the transaction to proceed if the record for the token indicates that the account is enabled.
14. A system for enabling transactions substantially as hereinbefore described with reference to any one of Figures 1, 3 and 4.
PCT/EP2004/003792 2003-04-08 2004-04-08 System for secure transactions WO2004090825A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0308102.3 2003-04-08
GBGB0308102.3A GB0308102D0 (en) 2003-04-08 2003-04-08 System for secure transactions

Publications (1)

Publication Number Publication Date
WO2004090825A1 true WO2004090825A1 (en) 2004-10-21

Family

ID=9956411

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/003792 WO2004090825A1 (en) 2003-04-08 2004-04-08 System for secure transactions

Country Status (2)

Country Link
GB (1) GB0308102D0 (en)
WO (1) WO2004090825A1 (en)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1657684A2 (en) * 2004-11-12 2006-05-17 Fujitsu Limited Process synchronous proving system and process synchronous proving method
EP2128809A1 (en) * 2008-05-30 2009-12-02 Luc Stals Server device for controlling a transaction, first entity and second entity
US20100114768A1 (en) * 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US10621572B2 (en) 2012-12-21 2020-04-14 Sqwin Sa Online transaction system
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US10963589B1 (en) 2016-07-01 2021-03-30 Wells Fargo Bank, N.A. Control tower for defining access permissions based on data type
US10970707B1 (en) 2015-07-31 2021-04-06 Wells Fargo Bank, N.A. Connected payment card systems and methods
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US12130937B1 (en) 2016-07-01 2024-10-29 Wells Fargo Bank, N.A. Control tower for prospective transactions

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0745961A2 (en) * 1995-05-31 1996-12-04 AT&T IPM Corp. Transaction authorization and alert system
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6052675A (en) * 1998-04-21 2000-04-18 At&T Corp. Method and apparatus for preauthorizing credit card type transactions
US6226624B1 (en) * 1997-10-24 2001-05-01 Craig J. Watson System and method for pre-authorization of individual account remote transactions
WO2003001866A1 (en) * 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US20030172040A1 (en) * 2002-03-05 2003-09-11 Visa U.S.A. System for personal authorization control for card transactions

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0745961A2 (en) * 1995-05-31 1996-12-04 AT&T IPM Corp. Transaction authorization and alert system
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6226624B1 (en) * 1997-10-24 2001-05-01 Craig J. Watson System and method for pre-authorization of individual account remote transactions
US6052675A (en) * 1998-04-21 2000-04-18 At&T Corp. Method and apparatus for preauthorizing credit card type transactions
WO2003001866A1 (en) * 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US20030172040A1 (en) * 2002-03-05 2003-09-11 Visa U.S.A. System for personal authorization control for card transactions

Cited By (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1657684A3 (en) * 2004-11-12 2006-11-02 Fujitsu Limited Process synchronous proving system and process synchronous proving method
EP1657684A2 (en) * 2004-11-12 2006-05-17 Fujitsu Limited Process synchronous proving system and process synchronous proving method
EP2728528A1 (en) * 2008-05-30 2014-05-07 MR.QR10 GmbH & Co. KG Server device for controlling a transaction, first entity and second entity
EP2128809A1 (en) * 2008-05-30 2009-12-02 Luc Stals Server device for controlling a transaction, first entity and second entity
WO2009144010A1 (en) * 2008-05-30 2009-12-03 Toyota Tsusho Id Systems Gmbh Server device for controlling a transaction, first entity and second entity
AU2009253407B2 (en) * 2008-05-30 2012-09-20 Mr. Qr10 Gmbh & Co. Kg Server device for controlling a transaction, first entity and second entity
US8332323B2 (en) 2008-05-30 2012-12-11 Mr. Qr10 Gmbh & Co. Kg. Server device for controlling a transaction, first entity and second entity
US11880846B1 (en) 2008-10-31 2024-01-23 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11880827B1 (en) 2008-10-31 2024-01-23 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US10417633B1 (en) 2008-10-31 2019-09-17 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US10755282B1 (en) 2008-10-31 2020-08-25 Wells Fargo Bank, N.A. Payment vehicle with on and off functions
US11676136B1 (en) 2008-10-31 2023-06-13 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11379829B1 (en) 2008-10-31 2022-07-05 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11915230B1 (en) 2008-10-31 2024-02-27 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11900390B1 (en) 2008-10-31 2024-02-13 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11010766B1 (en) 2008-10-31 2021-05-18 Wells Fargo Bank, N.A. Payment vehicle with on and off functions
US20100114768A1 (en) * 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US11037167B1 (en) 2008-10-31 2021-06-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11055722B1 (en) 2008-10-31 2021-07-06 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20230274265A1 (en) * 2008-10-31 2023-08-31 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11068869B1 (en) 2008-10-31 2021-07-20 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11100495B1 (en) 2008-10-31 2021-08-24 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US11107070B1 (en) 2008-10-31 2021-08-31 Wells Fargo Bank, N. A. Payment vehicle with on and off function
US11868993B1 (en) 2008-10-31 2024-01-09 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US10410217B1 (en) 2008-10-31 2019-09-10 Wells Fargo Bank, Na. Payment vehicle with on and off function
US10621572B2 (en) 2012-12-21 2020-04-14 Sqwin Sa Online transaction system
US11861594B1 (en) 2015-03-27 2024-01-02 Wells Fargo Bank, N.A. Token management system
US11823205B1 (en) 2015-03-27 2023-11-21 Wells Fargo Bank, N.A. Token management system
US11651379B1 (en) 2015-03-27 2023-05-16 Wells Fargo Bank, N.A. Token management system
US11893588B1 (en) 2015-03-27 2024-02-06 Wells Fargo Bank, N.A. Token management system
US12073409B2 (en) 2015-03-27 2024-08-27 Wells Fargo Bank, N.A. Token management system
US11562347B1 (en) 2015-03-27 2023-01-24 Wells Fargo Bank, N.A. Token management system
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US11200562B1 (en) 2015-07-31 2021-12-14 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11367064B1 (en) 2015-07-31 2022-06-21 Wells Fargo Bank, N.A. Connected payment card systems and methods
US12112313B2 (en) 2015-07-31 2024-10-08 Wells Fargo Bank, N.A. Connected payment card systems and methods
US10970707B1 (en) 2015-07-31 2021-04-06 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11900362B1 (en) 2015-07-31 2024-02-13 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11727388B1 (en) 2015-07-31 2023-08-15 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
US11847633B1 (en) 2015-07-31 2023-12-19 Wells Fargo Bank, N.A. Connected payment card systems and methods
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11409902B1 (en) 2016-07-01 2022-08-09 Wells Fargo Bank, N.A. Control tower restrictions on third party platforms
US11736490B1 (en) 2016-07-01 2023-08-22 Wells Fargo Bank, N.A. Access control tower
US12130937B1 (en) 2016-07-01 2024-10-29 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11755773B1 (en) 2016-07-01 2023-09-12 Wells Fargo Bank, N.A. Access control tower
US11429742B1 (en) 2016-07-01 2022-08-30 Wells Fargo Bank, N.A. Control tower restrictions on third party platforms
US11762535B1 (en) 2016-07-01 2023-09-19 Wells Fargo Bank, N.A. Control tower restrictions on third party platforms
US10963589B1 (en) 2016-07-01 2021-03-30 Wells Fargo Bank, N.A. Control tower for defining access permissions based on data type
US11227064B1 (en) 2016-07-01 2022-01-18 Wells Fargo Bank, N.A. Scrubbing account data accessed via links to applications or devices
US12067147B1 (en) 2016-07-01 2024-08-20 Wells Fargo Bank, N.A. Control tower restrictions on third party platforms
US11853456B1 (en) 2016-07-01 2023-12-26 Wells Fargo Bank, N.A. Unlinking applications from accounts
US12050713B1 (en) 2016-07-01 2024-07-30 Wells Fargo Bank, N.A. Scrubbing account data accessed via links to applications or devices
US12039077B1 (en) 2016-07-01 2024-07-16 Wells Fargo Bank, N.A. Scrubbing account data accessed via links to applications or devices
US11645416B1 (en) 2016-07-01 2023-05-09 Wells Fargo Bank, N.A. Control tower for defining access permissions based on data type
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11928236B1 (en) 2016-07-01 2024-03-12 Wells Fargo Bank, N.A. Control tower for linking accounts to applications
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11886613B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for linking accounts to applications
US11895117B1 (en) 2016-07-01 2024-02-06 Wells Fargo Bank, N.A. Access control interface for managing entities and permissions
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11914743B1 (en) 2016-07-01 2024-02-27 Wells Fargo Bank, N.A. Control tower for unlinking applications from accounts
US11899815B1 (en) 2016-07-01 2024-02-13 Wells Fargo Bank, N.A. Access control interface for managing entities and permissions
US11875358B1 (en) 2017-04-25 2024-01-16 Wells Fargo Bank, N.A. System and method for card control
US11869013B1 (en) 2017-04-25 2024-01-09 Wells Fargo Bank, N.A. System and method for card control
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US11756114B1 (en) 2017-07-06 2023-09-12 Wells Fargo Bank, N.A. Data control tower
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
US11615253B1 (en) 2020-09-04 2023-03-28 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11947918B2 (en) 2020-09-04 2024-04-02 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11256875B1 (en) 2020-09-04 2022-02-22 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US11818135B1 (en) 2021-01-05 2023-11-14 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices

Also Published As

Publication number Publication date
GB0308102D0 (en) 2003-05-14

Similar Documents

Publication Publication Date Title
US7478065B1 (en) Payment transaction method and payment transaction system
US10108939B1 (en) Payment transaction method and payment transaction system
US8783564B2 (en) Transaction notification and authorization method
WO2004090825A1 (en) System for secure transactions
US20020035539A1 (en) System and methods of validating an authorized user of a payment card and authorization of a payment card transaction
US7774076B2 (en) System and method for validation of transactions
US7139694B2 (en) Method and system for tranferring an electronic sum of money from a credit memory
US20030171993A1 (en) Electronic payment transaction via sms
US20030075610A1 (en) Electronic credit card-ecc
US20070203850A1 (en) Multifactor authentication system
US20030191945A1 (en) System and method for secure credit and debit card transactions
US20090012901A1 (en) Multifactor authentication system for "cash back" at the point of sale
US20080257953A1 (en) System and method for the transferring an electronic sum of money from a credit memory
US20020152177A1 (en) Method and arrangement for electronically transferring an amount of money from a credit account memory
EP1490846A2 (en) System and method for secure credit and debit card transactions
WO2003032122A2 (en) System and method for conducting a financial transaction using a communication device
JP2004506997A (en) Method and apparatus for transmitting an electronic amount from a fund memory
KR20170117153A (en) Mobile device and method for financial transactions using different currencies
WO2006094316A2 (en) System for processing financial transactions
US20090307103A1 (en) System for managing and facilitating financial transactions locally or remotely made
US20020078360A1 (en) Method of conducting transactions
JP2009015500A (en) Identity authentication device
WO2009108066A1 (en) Method and arrangement for secure transactions
KR20030092710A (en) The mode of transaction about an automatic paying machine(CD,ATM) using a mobile phone
WO2001099069A2 (en) An account

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase