WO2015015332A1

WO2015015332A1 - Charge card validation

Info

Publication number: WO2015015332A1
Application number: PCT/IB2014/062516
Authority: WO
Inventors: Eliyahu CHACHAM
Original assignee: Byrkat Eliyahu Security Card Guard Ltd.
Priority date: 2013-07-30
Filing date: 2014-06-22
Publication date: 2015-02-05

Abstract

A method for transaction security includes receiving at a validation server (28) a message transmitted over a communication network (32) by a mobile communication device (24) belonging to a user (22) of a charge card (25) to request validation of the charge card for a predefined period of time no greater than twelve hours. Responsively to the message, a record of the validation is automatically updated in a computer-readable memory (64). Subsequently to receiving the message and updating the record, a request is received from a merchant (40) to authorize a transaction using the charge card. Responsively to the request, the record is checked and, when the request occurs within the predefined period, an approval to complete the transaction is transmitted.

Description

CHARGE CARD VALIDATION

FIELD OF THE INVENTION

The present invention relates generally to systems and methods for electronic purchase and payments, and particularly for prevention of fraud and abuse of charge cards. BACKGROUND

Charge cards have become the most common and preferred instrument of payment in consumer purchases. The term "charge card" is used herein to refer broadly to all types of electronic payment cards, including (but not limited to) credit cards, debit cards and smart cards used in purchase transactions.

Charge card fraud and other types of identity theft are rampant, resulting in millions of fraudulent transactions every year and billions of dollars in losses. Charge card details are frequently stolen - whether by a petty thief who steals a wallet and uses the cards it contains, or by hackers who steal details of thousands of charge accounts from supposedly secure repositories. Although sophisticated automated systems have been deployed to identify and block fraudulent use of charge cards, thieves are frequently able to run up substantial charges on a given account before the fraudulent use can be detected and shut down.

A number of methods and systems have been proposed to make use of mobile communication devices to enhance transaction security. For example, U.S. Patent Application Publication 2010/0299220 describes systems and methods to facilitate online transactions via mobile communications. In one aspect, a system includes a data storage facility to store an account identifier of a user and a phone number of the user and an interchange coupled with the data storage facility. The interchange includes converters to interface with a plurality of different controllers of mobile communications in order to facilitate electronic payment transactions using the account identifier.

As another example, U.S. Patent Application Publication 2012/0173429 describes systems, methods, and software for location-based authorization of financial card transactions using a network-connected device. The device may transmit a set of data identifying the location of the device and an identifier unique to the device to a server. The server may also receive an action request associated with the identifier. The server may select a rule in a database to address the action request, wherein the rule is applicable to the identifier and location of the device. SUMMARY

Embodiments of the present invention provide methods, systems and software for charge card validation.

There is therefore provided, in accordance with an embodiment of the present invention, a method for transaction security, which includes receiving at a validation server a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours. Responsively to the message, a record of the validation is automatically updated in a computer-readable memory. Subsequently to receiving the message and updating the record, a request is received from a merchant to authorize a transaction using the charge card. Responsively to the request, the record is checked and, when the request occurs within the predefined period, an approval to complete the transaction is transmitted.

In a disclosed embodiment, the message is transmitted over the air by the mobile communication device.

In one embodiment, receiving the message includes receiving, in a server application running on the validation server, a data packet transmitted by a validation client application running on the mobile communication device. Alternatively, receiving the message includes receiving and automatically responding to a call placed over a telephone network to a number associated with the validation server.

Typically, checking the record includes refusing the transaction when the request is received outside the predefined period. In a disclosed embodiment, automatically updating the record includes maintaining respective records in the validation server with regard to a plurality of charge cards, wherein the record for any given charge card is maintained in an invalid state until the validation server receives the message requesting validation with respect to the given charge card and is invalidated again after the predefined period has elapsed.

In some embodiments, the predefined period has a duration that is set by the user of the charge card, and receiving the message includes receiving an instruction from the user to validate the charge card for a selected time period including no more than four hours. The selected time period may include no more than one hour.

Additionally or alternatively, receiving the message includes receiving an instruction from the user to validate the charge card for no more than a predefined number of transactions, such that the validation is terminated after the predefined number of transactions have been completed. Further additionally or alternatively, receiving the message includes receiving an instruction from the user to validate the charge card for no more than a predefined transaction value, such that the approval is transmitted only when an amount of the transaction is no greater than the predefined transaction value.

There is also provided, in accordance with an embodiment of the present invention, apparatus for transaction security, including a memory, which is configured to store validation records with respect to multiple charge cards that are respectively assigned to multiple users. A communication interface is configured to receive a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours and to receive requests submitted by merchants to authorize transactions using the charge card. A processor is configured to update automatically, responsively to the message, a record of the validation in the memory, and upon receiving a request, subsequently to receiving the message and updating the record, from a merchant to authorize a transaction using the charge card, to check the record and, when the request occurs within the predefined period, to transmit an approval to complete the transaction.

There is additionally provided, in accordance with an embodiment of the present invention, a computer software product, including a computer-readable medium in which program instructions are stored, which instructions, when read by a computer, cause the computer to receive a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours, to update automatically, responsively to the message, a record of the validation in a computer-readable memory, to receive, subsequently to receiving the message and updating the record, a request from a merchant to authorize a transaction using the charge card, and responsively to the request, to check the record and, when the request occurs within the predefined period, to transmit an approval to complete the transaction.

The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic pictorial illustration showing validation of a charge card by a user, in accordance with an embodiment of the present invention; Fig. 2 is a schematic pictorial illustration showing authorization of a charge card in a purchase transaction, in accordance with an embodiment of the present invention;

Fig. 3 is a block diagram that schematically illustrates elements of a system for charge card validation, in accordance with an embodiment of the present invention;

Fig. 4 is a flow chart that schematically illustrates a method for charge card validation, in accordance with an embodiment of the present invention; and

Fig. 5 is a flow chart that schematically illustrates a method for purchase authorization, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

At times, when a charge card user makes a large purchase or a pattern of purchases that appears to be suspicious, the charge card operator will place a call to the user's mobile telephone in order to verify that the purchases are legitimate. The charge card operator will then authorize the transaction only after the user has responded and approved the purchase in question. This mode of authorization, however, is at best cumbersome and detracts from the user's shopping experience (not to mention those waiting in line behind the user at the checkout counter). In many cases, authorization by telephone at the time of purchase is not practical at all and for this reason is not widely used.

Embodiments of the present invention that are described herein provide a novel, alternative solution that enhances transaction security with little or no deleterious effect on the user's shopping experience. In the disclosed embodiments, users pre-validate their charge cards by sending messages from their mobile communication devices to a validation server before making a purchase. The message indicates that the charge card is to be validated for a predefined period. Typically, the validation period is no more than twelve hours, and is frequently shorter- no more than four hours in most cases, or possibly no longer than two hours, one hour, or even a single purchase. The validation period may be preset to a default value, or the user may be able to select the duration of validation.

In response to the message from a given user, the server automatically updates a record in its memory, indicating the time period for which the user's charge card has been validated. When a merchant subsequently submits a request to authorize a transaction using the charge card, the server checks the record and, when the request occurs within the predefined period of validity, may transmit an approval to complete the transaction. As a rule, the server maintains its record for any given charge card in an invalid state until it receives an appropriate message requesting validation of the given charge card, and it invalidates the record once again after the predefined validation period has elapsed. Consequently, the validation server typically refuses to authorize transactions outside the validation period (or in such a case may send a message to the user's mobile communication device requesting approval).

Thus, embodiments of the present invention enable the charge card operator to achieve enhanced security and user accountability for transactions without detracting from the actual shopping experience. Furthermore, these embodiments have the advantageous technical effects of reducing the time required and communications involved in authorizing a transaction, since they make use of a single validation record that is created in advance, rather than requiring additional communication with the user's mobile communication device at the time of each transaction.

In general, the users' mobile communication devices communicate over the air with the validation server, typically via a cellular or other wireless data network. Users with smart phones or other mobile data devices may use a client application, running on their device, to communicate with a server application running on the validation server by transmitting and receiving data packets. Alternatively or additionally, users may place a telephone call, such as a voice call or cellular text message, to the validation server, which responds automatically, for example by interactive voice response (IVR).

In addition to validating their charge cards for predefined time periods, users may also place other limits on the use of their cards at the time of validation. For example, a user may issue an instruction to validate the charge card for no more than a predefined number of transactions, such that the validation is terminated after the predefined number of transactions have been completed. Additionally or alternatively, a user may validate the charge card for no more than a predefined transaction value, such that the approval is transmitted only when an amount of the transaction is no greater than the predefined transaction value.

Fig. 1 is a schematic pictorial illustration showing a system 20 for charge card validation, in accordance with an embodiment of the present invention. In this example scenario, a user 22 of a charge card 25 uses his smart phone 24 (or other mobile communication device) to validate his card before beginning to shop in a shopping center 26. For this purpose, an application running on smart phone 24 communicates with a validation server 28 via a network 32, such as the Internet. The smart phone typically accesses the Internet via a wireless access network 30, such as a cellular or Wi-Fi data link. Alternatively, user 22 may place a telephone call via phone 24 to a telephone number that is assigned to server 28. As described in greater detail hereinbelow, in the pictured example, the application running on smart phone 24 sends a message to server 28 that identifies charge card 25 and indicates to the server the period of time for which the card is to be validated. The message may also include other limitations on use of the card during the period in question, such as the number and/or value of transactions that may be authorized. Server 28 creates or otherwise updates a validation record accordingly, which may subsequently be accessed in transaction authorization by a credit card operator 34. Although for the sake of clarity, server 28 and operator 34 are shown in the figures as separate entities, in practice server 28 may be integrated with the communication and processing facilities of operator 34. Alternatively, server 28 may be operated independently of credit card operator 34 and may, in some cases, serve two or more different credit card operators.

Fig. 2 is a schematic pictorial illustration showing authorization of charge card 25 in a purchase transaction by user 22, in accordance with an embodiment of the present invention. Continuing the example scenario of Fig. 1, user 22 has entered a store 40, chosen an article to purchase, and given his charge card 25 to a salesperson 42, who inserts the card in a reader attached to a standard point-of-sale (POS) terminal 44. The terminal automatically requests approval of the transaction from credit card operator 34, which then queries validation server 28. Assuming the transaction is within the time period and other limits that the user entered previously via phone 24, server 28 will authorize the transaction automatically. No further communications with user 22 are required at this stage.

After completing his purchases or leaving shopping center 26, user 22 may reopen the application on phone 24 (or place a call to validation server 28) and send an invalidation message to server 28 in order to ensure that no further purchases can be made using card 25. Alternatively, if user 22 takes no action to re-validate card 25, server 28 will automatically switch the status of the card in its records to "invalid" when the time for which the card was validated has elapsed.

Fig. 3 is a block diagram that schematically shows details of smart phone 24 and validation server 28 in system 20, in accordance with an embodiment of the present invention. These particular apparatus features are shown here by way of example, to illustrate one mode of implementation of the techniques that are described herein. Alternative implementations will be apparent to those skilled in the art and are considered to be within the scope of the present invention.

Thus, smart phone 24 is presented here as an example of a mobile communication device, but its functions, as described herein, could alternatively be performed by devices of other types, such as a tablet or laptop computer or a personal digital assistant (PDA). Phone 24 comprises a central processing unit (CPU) 50, with a communication interface 52, such as a radio interface for communicating via access network 30, and a user interface (UI) 54, such as a touch screen. A memory 56 contains data and program instructions used by CPU 50, specifically including a validation application 58 for use in communication with validation server 28, typically by packet data communications over network 32. Memory 56 typically comprises a non-transitory computer-readable medium, such as flash memory, into which application 58 is downloaded and stored.

Validation server 28 typically comprises a general-purpose computer, comprising a processor 60 with a communication interface 62 and a memory 64. Interface 62 couples server 28 to network 32 and/or to an internal network belonging to credit card operator 34. Memory 64 typically comprises a non-transitory computer-readable medium, such as electronic, optical, and/or magnetic memory media. Processor 60 performs the functions that are described herein under the control of server application software that is stored in memory 64.

Based on messages received from the mobile communication devices of charge card users, processor 60 creates and maintains a validation database in memory 64, containing respective records indicating the status of each enrolled credit card. The validation database may have the following form, for example:

TABLE I - VALIDATION DATABASE

Each row in the table above contains the validation record for a given card, which is keyed by the card number listed in the first column. The records are normally maintained in an invalid state until validation server 28 receives a suitable message from the corresponding card user requesting validation of the card. Alternatively, when a given card is in the invalid state, the corresponding record may simply be removed from the database and then created again the next time the card is validated. (In this latter case, processor 60 updates the record for the given card by creating a new record, and the term "updating a record," as used herein, should therefore be understood as including creating a record, at least in certain implementations.)

When server 28 receives an appropriate validation message from the user of a given card, it updates the status of the card to valid and records the time at which the validation is to expire. As noted earlier, the user may specify the duration of the period for which the card is to be validated (such as one, two, four or more hours), or server 28 may apply a default period. When the period has elapsed, as indicated by the expiration time, server 28 returns the status of the given charge card to invalid. Thus, it is likely that at any given time, most of the cards in the validation database will be marked invalid.

Optionally, the database records may contain additional parameters, corresponding to further conditions and limitations on the use of the corresponding credit cards. These parameters are represented by the columns in Table I that are labeled "Limit 1" and "Limit 2." These limits may represent, for example, the number of transactions and transaction amount (cumulative and/or per transaction) that the card user has authorized. If the user does not specify a number or amount, these parameters may be set to default values or may not be applied at all by server 28 in validating transactions using the given card. Although two such additional parameters are shown in Table I, in practice the validation database may apply more or fewer parameters in addition to the time period for validation (or even no additional parameters at all).

Fig. 4 is a flow chart that schematically illustrates a method for charge card validation, in accordance with an embodiment of the present invention. This method, as well as the method of Fig. 5 below, is described, for the sake of clarity and convenience, with reference to the elements of system 20 that are shown in the preceding figures. The principles of this method, however, may similarly be implemented in systems that use other sorts of mobile devices and servers for validation.

To validate card 25, user 22 opens validation application 58 on his smart phone 24, at an application initiation step 70. Typically (although not necessarily), the application requires the user to authenticate himself, at a user authentication step 72. For example, the user may be required to enter a password or passcode. Additionally or alternatively, application 58 may make use of biometric means of identification provided by the user's mobile device, such as a fingerprint reader.

Once application 58 has opened and, if necessary, authenticated user 22, the user enters a request to the application to validate card 25, at a validation input step 74. As explained above, the user may, at this stage, input the desired duration of the period of validation, as well as other validation parameters. Alternatively, the validation period and other parameters may be set to default values that have been preset by user 22 or by an operator of system 20. Application 58 then sends a validation message over network 32 to server 28, requesting validation of card 25, at a message transmission step 76. In response to the message, server 28 updates the corresponding record in memory 64 to indicate that card 25 is now valid for transactions, along with the time period and any other limitations to be applied to such transactions.

Alternatively, as noted earlier, user 22 may use smart phone 24 or another sort of mobile telephone to carry out the validation functions described above by placing a telephone call to a number associated with validation server 28. The call may comprise a voice call or a text message. In the case of a voice call, for example, server 28 may, upon receiving the call, activate an IVR facility to prompt the user to press certain keys on the phone and/or enunciate certain words in order to identify himself, request validation, and possibly specify the validation period and other parameters. In this case, there is no need to run application 58 on phone 24, but otherwise, system 20 operates substantially as described above.

Fig. 5 is a flow chart that schematically illustrates a method for purchase authorization in system 20, in accordance with an embodiment of the present invention. This method is initiated when user 22 makes a purchase using charge card 25, at a purchase request step 80. For example, in the scenario illustrated in Fig. 2, step 80 occurs when terminal 44 receives and reads card 25. Terminal 44 automatically sends the card and transaction details to credit card company 34 with a request to authorize the transaction, at an authorization request step 82. The credit card company then queries validation server 28 to ascertain whether card 25 is currently valid, at a validation query step 84.

In response to this query, validation server 28 checks the record corresponding to card 25 in the validation database in memory 64, at a validation check step 86. If the record indicates that the card is valid, server 28 may also check the additional validation parameters, such as limits on the number and amounts of transactions, at a parameter checking step 88. As long as the card is valid and the purchase is within the specified limits, server 28 approves the transaction, at an approval step 90. Credit card company 34 receives and conveys this approval to terminal 44 and charges the appropriate amount to the account of card 25, and the transaction is thus consummated.

Alternatively, if the card is found to be currently invalid at step 86, or the transaction is outside the authorized limits at step 88, validation server 28 declines the transaction, at a transaction refusal step 92. The validation server may optionally be configured in such cases to place a call or otherwise send a message to the user's phone 24, requesting user approval. If the user grants approval in the appropriate manner, the transaction may then be approved.

It will be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.

Claims

1. A method for transaction security, comprising:

receiving at a validation server a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours;

responsively to the message, automatically updating a record of the validation in a computer-readable memory;

subsequently to receiving the message and updating the record, receiving a request from a merchant to authorize a transaction using the charge card; and

responsively to the request, checking the record and, when the request occurs within the predefined period, transmitting an approval to complete the transaction.

2. The method according to claim 1, wherein the message is transmitted over the air by the mobile communication device.

3. The method according to claim 1, wherein receiving the message comprises receiving, in a server application running on the validation server, a data packet transmitted by a validation client application running on the mobile communication device.

4. The method according to claim 1, wherein receiving the message comprises receiving and automatically responding to a call placed over a telephone network to a number associated with the validation server.

5. The method according to claim 1, wherein checking the record comprises refusing the transaction when the request is received outside the predefined period.

6. The method according to claim 5, wherein automatically updating the record comprises maintaining respective records in the validation server with regard to a plurality of charge cards, wherein the record for any given charge card is maintained in an invalid state until the validation server receives the message requesting validation with respect to the given charge card and is invalidated again after the predefined period has elapsed.

7. The method according to any of claims 1-6, wherein the predefined period has a duration that is set by the user of the charge card.

8. The method according to claim 7, wherein receiving the message comprises receiving an instruction from the user to validate the charge card for a selected time period comprising no more than four hours.

9. The method according to claim 8, wherein the selected time period comprises no more than one hour.

10. The method according to any of claims 1-6, wherein receiving the message comprises receiving an instruction from the user to validate the charge card for no more than a predefined number of transactions, such that the validation is terminated after the predefined number of transactions have been completed.

11. The method according to any of claims 1-6, wherein receiving the message comprises receiving an instruction from the user to validate the charge card for no more than a predefined transaction value, such that the approval is transmitted only when an amount of the transaction is no greater than the predefined transaction value.

12. Apparatus for transaction security, comprising:

a memory, which is configured to store validation records with respect to multiple charge cards that are respectively assigned to multiple users;

a communication interface, which is configured to receive a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours and to receive requests submitted by merchants to authorize transactions using the charge card; and

a processor, which is configured to update automatically, responsively to the message, a record of the validation in the memory, and upon receiving a request, subsequently to receiving the message and updating the record, from a merchant to authorize a transaction using the charge card, to check the record and, when the request occurs within the predefined period, to transmit an approval to complete the transaction.

13. The apparatus according to claim 12, wherein the message is transmitted over the air by the mobile communication device.

14. The apparatus according to claim 12, wherein the message comprises a data packet transmitted by a validation client application running on the mobile communication device.

15. The apparatus according to claim 12, wherein the message comprises a call placed over a telephone network to a number associated with the validation server.

16. The apparatus according to claim 12, wherein the processor is configured to refuse the transaction when the request is received outside the predefined period.

17. The apparatus according to claim 16, wherein the processor is configured to maintain respective records in the memory with regard to a plurality of charge cards, wherein the record for any given charge card is maintained in an invalid state until the processor receives the message requesting validation with respect to the given charge card and is invalidated again after the predefined period has elapsed.

18. The apparatus according to any of claims 12-18, wherein the predefined period has a duration that is set by the user of the charge card.

19. The apparatus according to claim 18, wherein the message comprises an instruction from the user to validate the charge card for a selected time period comprising no more than four hours.

20. The apparatus according to claim 19, wherein the selected time period comprises no more than one hour.

21. The apparatus according to any of claims 12-18, wherein the message comprises an instruction from the user to validate the charge card for no more than a predefined number of transactions, such that the validation is terminated after the predefined number of transactions have been completed.

22. The apparatus according to any of claims 12-18, wherein the message comprises an instruction from the user to validate the charge card for no more than a predefined transaction value, such that the approval is transmitted only when an amount of the transaction is no greater than the predefined transaction value.

23. A computer software product, comprising a computer-readable medium in which program instructions are stored, which instructions, when read by a computer, cause the computer to receive a message transmitted over a communication network by a mobile communication device belonging to a user of a charge card to request validation of the charge card for a predefined period of time no greater than twelve hours, to update automatically, responsively to the message, a record of the validation in a computer-readable memory, to receive, subsequently to receiving the message and updating the record, a request from a merchant to authorize a transaction using the charge card, and responsively to the request, to check the record and, when the request occurs within the predefined period, to transmit an approval to complete the transaction.