GB2534863A

GB2534863A - Mobile transaction validation

Info

Publication number: GB2534863A
Application number: GB1501594.4A
Authority: GB
Inventors: Babbage Steven; Bone Nicholas; David Pudney Christopher
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2015-01-30
Filing date: 2015-01-30
Publication date: 2016-08-10
Also published as: GB201501594D0

Abstract

Method and system for transferring funds in a mobile telephone based money transfer system comprising receiving an input 110 including a MSISDN of a recipient of the funds, wherein the input includes a check digit generated from at least a part of the MSISDN. Validating 120 the at least part of the MSISDN using the check digit. If the at least part of the MSISDN is validated then transferring 140 the funds to the recipient. The MSISDN, or mobile phone number, may include the at least one check digit.

Description

MOBILE TRANSACTION VALIDATION

Field of the Invention

The present invention relates to a method and system for carrying out mobile transactions and in particular mobile transactions in a mobile telephone payments system.

Background of the Invention

Cell phone based money transfer systems such as M-PESA for example, provide a facility for transferring funds between mobile users. Cash may be exchanged for electronic money, which may be sent to family and friends, to pay bills or to purchase mobile airtime, for example. Such systems are designed to work on limited functionality mobile handsets using an installed SIM toolkit (STK) to provide additional menus dedicated to funds transfer, Unstructured Supplementary Service Data (USSD) sessions or interactive voice response (IVR) systems. SMS messages may be used to confirm to a sender and a receiver that an amount has been transferred following a transaction or payment. At the sender's end, cash may be redeemed or exchanged for electronic money (or "e-money") at outlets, which may be grocery stores or airtime resellers, for example. At the receiver's end, e-money may be redeemed or exchanged for cash at similar outlets.

An example of such a system is described at: 30 http://www.vodafone.com/content/index/about/aboutus/money transfer.html -2 -Such money transfer systems are popular in countries with a limited banking infrastructure, where the population may not have access to basic financial services. Such systems are gaining popularity with millions of transactions occurring daily.

Users of these systems may be identified from their mobile telephone number alone. Therefore, users can send funds to a particular person or business based on the recipient's telephone number without requiring further details. Whilst this is convenient and simple, there exists the possibility that an incorrect telephone number is entered by the sender. Any resultant transfers to this Incorrect number may provide funds to the wrong recipient.

In financial terms, this can be costly for the sender who will need to repeat the transaction with the correct recipient. The incorrect recipient may be unwilling to return the funds or may even be unaware that they have received funds in error. Furthermore, this can increase the overhead on the operator of the mobile telephone based money transfer system as it can increase the number of transactions that are required (incorrect transactions plus transactions to restore the funds to the originator) and also generate additional load on the system as queries and requests for refunds to the operator can increase. This is a particular problem where a large number of transactions occur and where the transactions are of low values, meaning that the cost in both infrastructure terms (e.g. bandwidth, computing power and other network operating overheads) can be significant.

Peer-to-peer mobile money transfer is becoming more popular, especially in some parts of the world. This type of money transfer is also becoming popular in more developed markets as is provides a more convenient option compared with paper cheques.

In summary, to pay money a customer may type in a

recipient's telephone number. However, difficulties can arise if an incorrect number is entered. The number may have been written down incorrectly; it may be written in such a way that it isn't clear which particular digit is meant (e.g. 1 or 7); or the user may be clumsy when typing the number into the telephone. Therefore, there exists a risk of payments being made to the wrong person or recipient by mistake.

This problem may be addressed by providing users with a 15 method of correcting misdirected transactions. For example, the Safaricom Kenya website provides the following advice: What does one do in case they send M-PESA to the wrong number? kindly contact us via safaricom live chat on selfcare page https://selfcare.safaricom.co.ke OR Call M-PESA helpline on 234 from safaricom line.

Another system provides the following on its website: If you send money to the wrong number: Call Line 234 immediately and provide them with the 30 number that has erroneously received the cash.

Funds sent to a wrong number will be reversed only if still available in the wrong recipients account. -4 -

If successful, you will receive an SMS indicating that a reversal has been done.

W02014031887 describes a system for processing transactions via a mobile phone (e.g. payments from a retailer to their supplier). Upon entry of a supplier's mobile phone number, a confirmation screen is shown so that a retailer can verify whether or not the correct supplier company will receive the payment. However, this requires that the supplier's company name is stored against their phone number and a database needs to be consulted. Furthermore, payment systems may rely on the sender to press a "confirm" button after carefully reviewing the payment details. However, users that are expecting this button may click it without any careful review or reading what they are confirming. This can lead to errors not being picked up at this stage.

Therefore, there is required a system and method that overcomes these problems.

Summary of the Invention

In order to ensure that the correct mobile phone number has been entered when carrying out a mobile payment transaction, at least one check digit (e.g. checksum digit, checksum character or integer) is added to the mobile phone number (MSISDN). This check digit is generated from the remaining parts of the mobile phone number according to one of several possible algorithms (e.g. the Luhn or modulo algorithms). The algorithm has the same result if repeated with the same input number. On receipt of the telephone -5 -number and check digit, the algorithm is used to confirm that the input details are correct. If the generated check digit does not match the calculated value then it may be determined that an incorrect telephone number has been provided and the user may be prompted to correct the number or enter a new number. A single check digit may be used but more than one digit may also provide a higher level of certainty (some errors may not be detected with a single integer but may be picked up with two characters, for

example).

Whilst it has been previously proposed to include check digits in mobile telephone numbers for the purpose of avoiding misdialled calls (e.g. ThalfbeIcepy,com/idea/MD. :6Number 26 t and Ottpp://wikL /0i y (.7 1c4-12) r.

both accessed on 30 January 2015) this has usually been discounted as it would involve formidable technical changes to telecommunications networks and infrastructure. In any case, the use of check digits in mobile phone numbers for money transfer purposes is not known but provides particular advantages, as discussed below.

According to a first aspect there is provided a method of transferring funds in a mobile telephone based money transfer system comprising the steps of: receiving an input including a MSISDN of a recipient of the funds, wherein the input includes a checksum character generated from at least a part of the MSISDN; validating the at least part of the MSISDN using the checksum character; and if the at least part of the MSISDN is validated then transferring the funds to the recipient. The MSISDN may conform to the E.164 -6 -standard (i.e. country code (CC) plus national destination code (NDC) plus subscriber number (SN)). Therefore, if an Incorrect number has been entered by a user then the transaction can be prevented. The MSISDN may include the check digit. In this case, the MSISDN without the check digit can be validated. All or part of the MSISDN may be validated or confirmed. The full MSISDN (including checksum) may be used as the telephone number. In other words, all digits may be included when dialling (_ncluding the checksum) as well as when making a payment. The check digit may be ignored when the number is used to make a call or send an SMS. The check digit may be generated from a part of the MSISDN or the whole number. A MSISDN may be formed from a CC, NDC and SN. The check digit may be generated only from the SN of the MSISDN, NDC plus SN or CC plus NDS plus SN, for example.

Preferably, the method may further comprise the step of: if the at least part of the MSISDN is not validated then requesting a further input.

Optionally, at least part of the MSISDN may be validated by carrying out a Luhn algorithm on the at least part of the MSISDN to generate a validation character and comparing the check digitof the input with the validation character. Other algorithms may be used. This may include other modular algorithms (modulo 5, 10, 11, etc.) or more complex algorithms such as Verhoeff's or Datum's.

Preferably, the input may be entered by a user on a mobile device. Input may follow a prompt to enter the recipient's mobile telephone number, for example. -7 -

Optionally, the at least part of the MSISDN nay be validated on the mobile device. Validation may alternatively, take place outside of the mobile device (e.g. on a server or a payments server) and the result of validation returned to the mobile device.

Optionally, the mobile device may be a feature phone. In other words, a smartphone may not be required (but may be 10 used) for the system to work.

The MSISDN is a telephone number (e.g.) or other identifier of the recipient.

Optionally, the MSISDN of the recipient (without the check digit) may be suitable for placing a call or sending an SMS to the recipient. In other words, the MSISDN including the check digit (i.e. an extended MSISDN) is used when initiating a money transfer but the MSISDN excluding (or including) the check digit may be used to call or send an SMS to the recipient (or otherwise access the recipient over a mobile network).

According to a second aspect there is provided a mobile 25 telephone based money transfer system comprising logic arranged to: receive an input including a MSISDN of a recipient of the funds, wherein the input includes a check digitgenerated from at least a part of the MSISDN; validate the at least part of the MSISDN using the check digit; and if the at least part of the MSISDN is validated then transfer the funds to the recipient. -8 -

Preferably, the telephone based money transfer system may further comprise a server configured to transfer the funds to the recipient. This may be the same or a separate 5 entity that validates the MSISDN.

Optionally, the at least part of the MSISDN nay be validated on or by the server. It may also be validated on the mobile device.

According to a third aspect there is provided a mobile device comprising logic configured to: receive an input including a MSISDN of a recipient of the funds, wherein the input includes a check digit generated from at least a part of the MSISDN; validate the at least part of the MSISDN using the check digit; and if the at least part of the MSISDN is validated then proceeding with the funds transfer. This may be a cellular phone, a feature phone or a smartphone (e.g. running an OS such as Android, iOS or Windows).

Preferably, if the at least part of the MSISDN is not validated or fails validation then the funds transfer may be 25 prevented from proceeding.

Optionally, validating the at least part of the MSISDN using the check digit may further comprise sending the at least a part of the MSISDN and the check digit to a server and receiving a validation signal from the server in response. -9 -

Advantageously, the logic may be implemented in a SIM application toolkit, STK. Therefore, lower specification handsets may be used. These may be more popular in less developed countries.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example.

It should be noted that any feature described above may be used with any particular aspect or embodiment of the 25 invention.

-10 -

Brief description of the Figures

The present invention may be put into practice in a number of ways and embodiments will now be described by way 5 of example only and with reference to the accompanying drawings, in which: FIG. 1 shows a flowchart of a method for transferring funds in a mobile telephone based money transfer system, given by way of example only; and FIG. 2 shows a schematic diagram of the mobile telephone based money transfer system of figure 1.

It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

Detailed description of the preferred embodiments

Check digits may be used to pick up accidental errors in the entry of a string of numbers. Credit card numbers include a single check digit, computed using the Luhn algorithm (http://en.wiLlpedia.crg/wili/Luhn algorithm), for example. This allows a system to detect automatically when many typical errors are made in the number string entry (individual wrong digits are always detectable; most transpositions of two adjacent digits are also detectable).

A check digit may be added to a mobile phone number (or MSISDN), for use when entering the recipient number in a money transfer scheme. This may be implemented by: a) Including one or more check digits in each telephone number; b) Each user having a separate telephone number, incorporating a check digit, for use when receiving money transfer. This may be their usual telephone number (for calls and SMS) with one or more extra digits appended.

Checking the validity of an entered phone number, and preventing the money transfer from proceeding if It's not valid, may be done: a) On the sender's phone (especially if some kind of 5 mobile application is being used); or b) At a server that receives the instruction from the sender's mobile device or phone.

This makes it less likely that money will be sent to a wrong recipient (number) by mistake. A money transfer won't 10 proceed if the number entered is detected as being invalid (based on comparing the check digit or character that is entered with one that is calculated). This procedure may be used with any money transfer system in which either (a) some intelligence can be applied on the phone/SIM to check the entry before sending the money transfer request or (b) the request goes to a server rather than directly to the recipient's phone.

For example, the check digit may be included at the beginning or end of (or any other location within) a user's MSISDN; e.g. instead of 07123456789, a user's MSISDN may be 07123456789n (where n is an integer or a series of integers). This feature is advantageous as its inclusion mitigates the risk of sending data (e.g. payment instructions) in error, and is compatible with any type of UE (e.g. mobile handset) from feature-free UEs to feature-rich UEs (e.g. feature phones and smart phones).

More than one check digits may be included (e.g. two 30 extra digits). This may provide further assistance with other features, e.g.: -12 - * Customer search/look-up; and * Beneficiary look-up by browsing a device's address book or contacts list.

Furthermore, the MSISDN may be used as an identifier that may replace the primary account number (PAN) on debit or credit cards or bank account numbers.

Figure 1 shows at a high level a flow chart of a method 100 for transferring funds in a mobile telephone based money transfer system. Not all of the steps in this procedure are shown in this figure. At step 110, an input is received that includes the MSISDN and check digit. This check digit is validated at step 120. For example, this validation may take place by calculating (according to a particular algorithm) a number from the remaining portion of the MSISDN. If the calculated number matches the check digit of the received input, then validation is confirmed, in which case the fund transfer proceeds at step 140. However, if validation fails and the digits (input and calculated) do not match then the user may be prompted for a correct number as a new input at step 130 and the procedure may Loop back to step 110. The procedure may loop until the check digits match or be stopped after a pre-determined number of attempts.

Figure 2 illustrates schematically a system 200 for implementing the method described with regards to figure 1. In this example, a sender's mobile telephone 220 Ls used to enter the MSISDN 210 and check digit 215 using a keypad of the mobile telephone (or device) 220 when prompted by a particular menu or function within payment software loaded -13 -on mobile telephone 220 (not shown in this figure). When a feature phone is used then the software may be implemented as a SIM application toolkit (i.e. menu-based). Other implementations may be used. For example, when a smartphone is used (e.g. running iOS, Windows, Android, etc.) then a mobile application may carry out the method 100.

The check digit may be validated within the mobile telephone 220 or at a server 240. The request may be sent 10 via a mobile network 230 to the server 240. In this example, the server 240 calculates and validates the check digit. This avoids the need for high specification mobile telephones in the procedure. Once validated, the recipient mobile telephone 250 may receive a message to confirm that the funds have been transferred. The sender's mobile telephone 220 may also receive confirmation of this transfer. In one example, the user may be prompted to enter the check digit separately from the remaining part of the telephone number (MSISDN). In other words, the digits may be entered in a similar way to a username and password combination (in separate boxes of fields).

As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from 25 the scope of the present invention, as defined by the appended claims.

For example, different checksum or check digit algorithms may be used. The data may be transferred over the Internet or over a cellular data connection.

Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the -14 -invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

Claims

-15 -CLAIMS: 1. A method of transferring funds in a mobile telephone based money transfer system comprising the steps of: receiving an input including a MSISDN of a recipient of the funds, wherein the input includes at least one check digit generated from at least a part of the MSISDN; validating the at least part of the MSISDN using the at least one check digit; and if the at least part of the MSISDN is validated then transferring the funds to the recipient.
2. The method of claim 1 further comprising the step of: if the at least part of the MSISDN is not validated 15 then requesting a further input.
3. The method of claim 1 or claim 2, wherein the at least part of the MSISDN is validated by carrying out a Luhn algorithm on the at least part of the MSISDN to generate a validation character and comparing the at least one check digit of the input with the validation character.
4. The method according to any previous claim, wherein the input is entered by a user on a mobile device.
S. The method of claim 4, wherein the at least part of the MSISDN is validated on the mobile device.
6. The method of claim 4 or claim 5, wherein the mobile device is a feature phone.
7. The method according to any previous claim, wherein the MSISDN includes the at least one check digit.

-16 -
8. The method according to any previous claim, wherein the MSISDN of the recipient without the at least one check digit is suitable for placing a call or sending an SMS to the 5 recipient.
9. A mobile telephone based money transfer system comprising logic arranged to: receive an input including a MSISDN of a recipient of 10 the funds, wherein the input includes at least one check digit generated from at least a part of the MSISDN; validate the at least part of the MSISDN using the at least one check digit; and if the at least part of the MSISDN is validated then 15 transfer the funds to the recipient.
10. The telephone based money transfer system of claim 9 further comprising a server configured to transfer the funds to the recipient.
11. The telephone based money transfer system of claim 10, wherein the at least part of the MSISDN is validated on the server.
12. A mobile device comprising logic configured to: receive an input including a MSISDN of a recipient of the funds, wherein the input includes at least one check digit generated from at least a part of the MSISDN; validate the at least part of the MSISDN using the at 30 least one check digit; and if the at least part of the MSISDN is validated then proceeding with the funds transfer.

-17 -
13. The mobile device of claim 12, wherein if the at least part of the MSISDN is not validated then preventing the funds transfer from proceeding.
14. The mobile device of claim 12 or claim 13, wherein validating the at least part of the MSISDN using the at least one check digit further comprises sending the at least a part of the MSISDN and the at least one check digit to a server and receiving a validation signal from the server in response.
15. The mobile device according to any of claims 12 to 14, wherein the logic is implemented in a SIM application toolkit, STK.