WO2014118525A1

WO2014118525A1 - Mobile to mobile payment process

Info

Publication number: WO2014118525A1
Application number: PCT/GB2014/050222
Authority: WO
Inventors: Dave DUKE; Sean Patrick KEARNEY
Original assignee: Cashincode Limited
Priority date: 2013-01-29
Filing date: 2014-01-29
Publication date: 2014-08-07
Also published as: GB201301563D0; GB201322086D0; GB2510190A

Abstract

We describe herein a mobile to mobile payment method comprising sending a one time usable encrypted code from a first mobile device associated with a payor, the one time usable encrypted code comprising an identifier of the first mobile device, an amount of payment and at least a card number of a payment of the payor. The method further comprises receiving the one time usable encrypted code at a second mobile device associated with a payee; receiving the one time usable encrypted code at a server from the second mobile device; decrypting at the server the one time usable encrypted code to obtain the identifier of the first mobile device, the amount of payment and the card number of the payment card of the payor, wherein the encrypted code is expired after the decryption; and using the server to execute a transfer of the amount of payment to an account associated with the payee using the payment card number of the payor.

Description

Mobile to Mobile Payment Process

FIELD OF THE INVENTION

The present invention relates to a payment system between mobile devices and a method of making a payment between mobile devices. BACKGROUND TO THE INVENTION

Intelligent and multi-functional mobile communication devices, such as so-called smartphones and tablet computers are now ubiquitous for business or personal applications. However, the one area in which mobile devices have seen very little penetration is in the area of mobile banking, and more particularly with payments made using a mobile device. This is primarily due to security concerns and the difficulty in keeping the integrity of data that is transmitted to and from each mobile device. Secondarily, however no less a problem, many wireless networks have reliability issues, which puts further uncertainty on transactions executed by the mobile devices connected with these wireless networks. Furthermore, financial transactions require a high level of accuracy, and any platform executing such transactions needs to be robust, reliable, accurate and secure.

SUMMARY OF THE INVENTION

Aspects and preferred features of the invention are set out in the accompanying claims.

In accordance with one aspect of the invention there is provided a mobile to mobile payment method which comprises:

sending a one-time usable encrypted code from a first mobile device associated with a payor, the one-time usable encrypted code comprising an identifier of the first mobile device, an amount of payment and at least a card number of a payment of the payor;

receiving the one time usable encrypted code at a second mobile device associated with a payee; receiving the one time usable encrypted code at a server from the second mobile device;

decrypting at the server the one time usable encrypted code to obtain the identifier of the first mobile device, the amount of payment and the card number of the payment card of the payor, wherein the encrypted code is expired after the decryption; and

using the server to execute a transfer of the amount of payment to an account associated with the payee using the payment card number of the payor. The invention provides a secure payment process between two mobile devices. It will be appreciated that the one-time usable encrypted code can have a one-time usable password which is generated during the generation of the code. Generally only the server has the one time usable password which it uses for decrypting the code. Once the code has been decrypted, it cannot be reused. The second mobile device associated with the payee is generally not capable of decrypting the code.

The step of sending the encrypted code from said first mobile device to said second mobile device, may use a short range communications link between the first and second mobile devices so that interception of the encrypted code is restricted at beyond an operating range of the link. This ensures that the mobile to mobile payment process only takes place between a restricted distance. However, it would be apparent that the invention is not limited to this feature.

The method may further comprise:

prior to sending the encrypted code from the first device to the second device, receiving at the server the identifier of the first mobile device from the first mobile device in association with an identifier of the second mobile device from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices;

receiving, in association with said encrypted code from said second mobile device, an identifier of said second mobile device; and

wherein said execution of said transfer is conditional on said identifier of said second mobile device received in association with said encrypted code matching said identifier of said second mobile device received in association with said identifier of said first mobile device; and conditional on the decrypted said identifier of said first mobile device matching the said identifier of said first mobile device received in association with said identifier of said second mobile device.

This arrangement is applicable when both devices have internet access and they separately transmit their IDs to the server. However, the server may be configured to ensure that a payment will only take place between these two devices and to confirm the transaction if it can verify that both devices IDs are matched between those received earlier and those received with the encrypted code for making the payment. The method may further comprise:

prior to sending the encrypted code from the first device to the second device, receiving at the second mobile device from the first mobile device the identifier of the first mobile device, and

receiving at the server from the second mobile device the identifier of the first mobile device and an identifier of the second mobile device so as to confirm that a payment transaction will take place between the first and second mobile devices;

This arrangement is used when the payor's device does not have internet connection to connect the server. Therefore it sends its ID to the payee's device and then the payee's device sends both devices' IDs to the server. The step of sending the encrypted code from said first mobile device to said second mobile device may comprise sending the code over a direct link between said first and second mobile devices. The direct link may comprise an audio signal link transmitted from a speaker of the first mobile device to a microphone of said second mobile device. The step of receiving the encrypted code at the second mobile device may comprise receiving the code via a direct signal from said first mobile device. The step of receiving the encrypted code at the second mobile device may comprise receiving the code via an audio signal received at a microphone of the second mobile device and wherein said server receives a version of said audio signal. This arrangement may provide a secure communication between two devices. For example, the communication between the devices may take place in a short distance (for example, between 5 to 10 meters) and therefore the communication may have less chance of being hijacked. Furthermore, this arrangement is advantageous because it provides flexibility in making mobile payments. For example, a user may not need to have a so called smart device with a camera. An ordinary mobile device can transmit encrypted codes using the sound signal.

Although using the sound signal is advantageous, it would be appreciated that the invention is not limited to the use of the sound signal. Alternatively the direct link can comprise an image, and means using near field communications or infra-ray communications.

The method may further comprise generating the one time usable encrypted code by a first payment application on the first mobile device. The method may further comprise generating at the server the one time usable encrypted code comprising the card number of the payment of the payor and the identifier of the first mobile device; receiving at the first mobile device the one time usable encrypted code, and incorporating the payment amount in the encrypted code by a first payment application.

The method may further comprise receiving a message at the second mobile device from the server to confirm that the payment has been successfully made.

In one embodiment, the encrypted code further comprises secondary payor authentication data comprising one or more of fingerprint, voice and/or picture of the payor.

The method may further comprise generating at the second mobile device secondary payee authentication data comprising one or more of fingerprint, voice and/or picture of the payee.

The method may further com prior to sending the encrypted code from the first device to the second device, receiving at the server the identifier of the first mobile device and the secondary payor authentication data from the first mobile device in association with an identifier of the second mobile device and the secondary payee authentication data from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices;

receiving at the server, in association with said encrypted code from said second mobile device, an identifier of said second mobile device and the secondary payee authentication data; and

wherein said execution of said transfer is conditional on said identifier and the secondary payee authentication data of said second mobile device received in association with said encrypted code matching said identifier and the secondary payee authentication data of said second mobile device received in association with said identifier and the secondary payor authentication data of said first mobile device; and conditional on the decrypted said identifier and secondary payor authentication data of said first mobile device matching the said identifier and secondary payor authentication data of said first mobile device received in association with said identifier of said second mobile device. The method may further comprise:

prior to sending the encrypted code from the first device to the second device, receiving at the second mobile device from the first mobile device the identifier of the first mobile device and the secondary payor authentication data, and

receiving at the server from the second mobile device the identifier of the first mobile device and the secondary payor authentication data and an identifier of the second mobile device and the secondary payee authentication data so as to confirm that a payment transaction will take place between the first and second mobile devices; receiving, in association with said encrypted code from said second mobile device, said identifier of said second mobile device and said secondary payee authentication data; and

wherein said execution of said transfer is conditional on said identifier and the secondary payee authentication data of said second mobile device received in association with said encrypted code matching said identifier and the secondary payee authentication data of said second mobile device received in association with said identifier and the secondary payor authentication data of said first mobile device; and conditional on the decrypted said identifier and secondary payor authentication data of said first mobile device matching the said identifier and secondary payor authentication data of said first mobile device received in association with said identifier of said second mobile device.

Secondary authentication means are provided in the encrypted code. The secondary authentication means are generally biometric authentication data which can be selected from one or more of fingerprint, voice and/or picture of the payor and/or payee. These means can be automated in the encrypted code. The payor and/or payee can generate these secondary authentication means by using mobile devices. In one embodiment, a fingerprint sensor of the mobile device can be used to generate the fingerprint. Any voice processing techniques available in the smart devices can be used to process the voice of the payor and/or payee. Any face detection techniques available in the mobile devices can be used to generate and/or detect a picture of the payor and/or payee. In one embodiment, the secondary authentication means or data are stored in the server as well while the payor and/or the payee register with the server. The secondary authentication means or data can be generated by the mobile applications installed on the mobile devices of the payor and/or payee as well. These features provide a secondary authentication step in the payment process and hence make the payment process more secure. The server not only can verify the unique IDs of the devices of the payor and/or payee, but also can verify the secondary authentication means. This second level of security in the payment system is advantageous over the existing payment systems. In accordance with a further aspect of the present invention there is provided a mobile to mobile payment system comprising:

a first mobile device associated with a payor configured to send a one-time usable encrypted code, the one-time usable encrypted code comprising an identifier of the first mobile device, an amount of payment and at least a card number of a payment of the payor;

a second mobile device associated with a payee configured to receive the one time usable encrypted code from the first mobile device;

a server configured to receive the one time usable encrypted code from the second mobile device, wherein the server is configured to decrypt the one time usable encrypted code to obtain the identifier of the first mobile device, the amount of payment and the card number of the payment of the payor, wherein the encrypted code is expired after the decryption, and

wherein the system is configured to use the server to execute a transfer of the amount of payment from the payment card of the payor to an account associated with the payee.

The payment system may be configured to send the encrypted code from said first mobile device to said second mobile device using a short range communications link between the first and second mobile devices so that interception of the encrypted code is restricted at beyond an operating range of the link.

Prior to sending the encrypted code from the first device to the second device, the server may be configured to receive the identifier of the first mobile device from the first mobile device in association with an identifier of the second mobile device from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices. The server may be configured to receive, in association with the encrypted code from said second mobile device, an identifier of said second mobile device. The execution of the transfer may be conditional on the identifier of the second mobile device received in association with the encrypted code matching the identifier of said second mobile device received in association with the identifier of said first mobile device; and conditional on the decrypted said identifier of said first mobile device matching the said identifier of said first mobile device received in association with said identifier of said second mobile device. Alternatively, prior to sending the encrypted code from the first device to the second device, the second device may be configured to receive from the first mobile device the identifier of the first mobile device, and the server may be configured to receive from the second mobile device the identifier of the first mobile device and an identifier of the second mobile device so as to confirm that a payment will take place between the first and second mobile devices. The server may be configured to receive, in association with said encrypted code from said second mobile device, an identifier of said second mobile device. The execution of the transfer may be conditional on the identifier of the second mobile device received in association with the encrypted code matching the identifier of said second mobile device received in association with the identifier of said first mobile device; and conditional on the decrypted said identifier of said first mobile device matching the said identifier of said first mobile device received in association with said identifier of said second mobile device.

The first device may be configured to send the code over a direct link between said first and second mobile devices. The direct link may comprise an audio signal link transmitted from a speaker of the first mobile device to a microphone of said second mobile device.

The second mobile device may be configured to receive the encrypted code via a direct signal from said first mobile device.

The second mobile device may be configured to receive the encrypted code via an audio signal received at a microphone of the second mobile device and wherein said server receives a version of said audio signal.

The first mobile device may be configured to generate the one time usable encrypted code by a first payment application on the first mobile device.

The server may be configured to generate the one time usable encrypted code comprising the card number of the payment of the payor and the identifier of the first mobile device, and the first mobile device is configured to receive the one time usable encrypted code and incorporate the payment amount in the encrypted code by a first payment application. The second mobile device may be configured to receive a message from the server which confirms that the payment has been successfully made.

In accordance with a further aspect of the present invention, there is provided a mobile device for making a payment to a further mobile device, the mobile device comprising: a memory configured to store a payment application with a user interface to receive instruction data for making the payment;

a processor configured to generate a one time usable encrypted code based on the instruction data, the one time usable encrypted code comprising an identifier of the mobile device, an amount of payment and at least a card number of a payment of a payor associated with the mobile device, and a transmitter configured to transmit the encrypted code to the further mobile device via an audio signal.

Preferably the transmitter comprises a speaker.

In accordance with a further aspect of the present invention, there is provided a mobile device for receiving a payment from a further mobile device, the mobile device comprising:

a receiver configured to receive an audio signal from the further mobile device; a memory configured to store a payment application with a user interface to receive instruction data for receiving the payment;

a processor configured to control the receiver based on the instruction data so that a one time usable encrypted code is received in the form of the audio signal. The mobile device may further comprise a transmitter configured to transmit the one time usable encrypted code to a server.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the invention will now be further described, by way of example only, with reference to the accompanying figures in which:

Figure 1 llustrates a mobile to mobile payment system;

Figure 2 llustrates a first scenario of a mobile to mobile payment process;

Figure 3 llustrates a second scenario of a mobile to mobile payment process;

Figure 4 llustrates a third scenario of a mobile to mobile payment process;

Figure 5 llustrates a fourth scenario of a mobile to mobile payment process;

Figure 6 llustrates an alternative mobile to mobile payment system;

Figure 7 llustrates an example of a mobile to mobile payment process using the mobile to mobile payment system of Figure 6; and

Figure 8 illustrates an alternative mobile to mobile payment system. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

This invention describes systems and methods for mobile-to-mobile payment. The term "mobile" can include a device such as a cellular phone or other wireless communication device. The system and method facilitates payment from a payor's mobile device to a payee's mobile device through an encrypted code without compromising credit card details. Both mobile devices of the payor and payee are installed with a predetermined application and the predetermined application is able to communicate with an application server through a network communication, e.g. internet. The application server is typically connected with a banking server through e.g. internet.

The mobile devices are generally located fairly close to each other so as to make the payment from one device to another. The mobile devices generally communicate with each other through an audio signal for transmitting and receiving the encrypted code including the payment details.

Figure 1 illustrates a mobile to mobile payment system 100. The system 100 includes a first mobile device 101 and a second mobile device 120. For sake of simplicity and for exemplary purposes only, the first mobile device 101 is associated with a payor, and the second mobile device 120 is associated with a payee. The first mobile device 101 includes a memory 103 which stores a mobile payment application 105. The mobile payment application 105 is provided by a particular vendor. The payment application 105 includes a user interface for receiving instruction data to perform the mobile to mobile payment process. The first mobile device 101 also includes a processor 107 connected to the memory 103, which controls the instruction data provided by the payment application 105. The first mobile device 101 also includes a speaker 1 10 and a microphone 115.

The second mobile device 120 also has the same features as the first mobile device 101 , i.e. a memory 123 to store the same mobile payment application 125 provided by the same vendor, a processor 127 connected to the memory 123, a speaker 130 and a microphone 135.

The payment system 100 also includes an application server 140 which is set up by the same vendor. The server 140 includes a database 145 which is connected to a processor 150. The application server also includes a transmitter 155 and a receiver 160, which are coupled with the processor 150.

The application server 140 is configured to be connected with a banking server (not shown in Figure 1) so as to complete a payment transaction.

Both the mobile devices 101 , 120 can generally communicate with the application server 140, preferably via an internet communication. However, the first mobile device 101 associated with the payor can be a mobile device which is not capable of connecting the application server 140 via the internet. In such a case, the payment server 140 can include a website that may include a mobile-formatted webpage which the payor can use to register with the server 140. The server can then provide a code to the payor which he types manually on the application 105 running on the first device 101. The payment applications 105, 125 running on both mobile devices 101 , 120 enable the mobile devices to interact with the application server 140.

In one embodiment, the payment process takes place when both the mobile devices 101 , 120 are located fairly close to one another so that when one device generates an audio signal through a speaker 1 10, 130, the other device can receive the audio signal through a microphone 1 15, 135.

In one embodiment, when the mobile devices 101 , 120 communicate with the application server 140 through the internet, the processor 150 deals with the communication through the receiver 160. The database 145 generally stores the IDs of the mobile devices 101 , 125. The processor 150 enables the transmitter 155 and the receiver 160 to communicate with the mobile devices 101 , 120.

Figure 2 illustrates an example of a first scenario of a mobile to mobile payment process. In particular the figure shows the following steps.

At S1 , the payee sets up an account with the application server 140 so that the payee's mobile device 120 can accept money from a payor. The payee submits its bank account details with the application server 140. The application server 140 generates a unique ID for the payee's device 120. The payee also installs the mobile payment application 125 on its mobile device 120. The mobile payment application 125 contains the unique ID given by the application server 140 and therefore the application server 140 will recognise the payee's device120 through this unique ID.

At S2, the payor's device 101 has the same mobile payment application 105 (as running on the payee's device) running on it. In one example, the payment application 105 already stores the credit/debit card details. Alternatively the payor can enter the details of a credit/debit card in the payment application 105.

At S3, the payor brings its mobile device 101 near the payee's mobile device 120 and the payor confirms that he would like to make a payment to the payee's device 120. The payor's device 101 sends a payor's ID to the payee's device. This communication can for example take place through a sms, an audio signal or other suitable way. The payor and payee's devices 101 , 120 are generally kept fairly close to each other, preferably within 5-10 meter distance so that an audio signal can transmit from one device to another.

At S4, the payee's mobile device 120 sends the payor's ID and a payee's ID to the application server 140 to confirm that a transaction will take place particularly between the payor and payee's devices 101 , 120. The main aim of the steps S3 and S4 is to ensure that the application server 140 is aware of the identifications of the two dedicated devices between which a transaction will take place.

At S5, the payor enters on the payment application running on his mobile device the amount he wishes to pay the payee. In this example the application 105 already securely stores the credit/debit card information of the payor. The application 105 then encodes the credit card details, the amount of payment and the payor's ID into an encrypted code which is only one time usable.

At S6, the application 105 running on the payor's device 101 is configured to transmit the one time encrypted code to the payee's device 120. In one embodiment, the payor's device 101 transmits the code through an audio signal using the speaker 1 10 of the payor's device 101. The audio signal can be in any frequencies and therefore it may or may be not heard by a human. At S7, the payee's device 120 uses its microphone 135 to receive the audio signal containing the one time encrypted code including the payment information (credit card information and payment amount) and payor's ID. The payee's device 120 is unable to decrypt the code received from the payor's device. Therefore the payee's device does not get any credit/debit card details of the payor.

At S8, the application running on the payee's device 120 is configured to send the encrypted code to the application server 140, preferably through internet communication. The payee's device 120 can also send a further payee ID to the server in association with the one-time encoded code.

At S9, the application server decrypts the encrypted code to obtain the credit card details and payment value. The encrypted code now expires and cannot be used again as this is only one time usable. In one embodiment, the server can then compare the decrypted payor ID with the payer ID sent in S4 and further may compare the payee's ID sent in S4 and in S8. If a matching is found, the server may authorise the transaction.

At S10, the application server 140 sends the payor's card details to the relevant banking server and completes the transaction.

At S1 1 , once the payment is authorised from the banking server, the application server 140 sends confirmation to the payee's device 120 that the transaction has been completed.

In the first scenario, the payor's mobile device 101 may or may not have internet connection to connect the application server 140. The payor's mobile device 101 may not have registration with the application server. The payor's device 101 may simply have the mobile payment application 105 installed on the mobile device 101. The payee's device 120 generally has internet connection so that it can connect to the application server 140 during or after the transaction.

Figure 3 illustrates an example of a second scenario of a mobile to mobile payment process. In particular the figure shows the following steps. At S1 , the same steps are performed as described above with reference to the first scenario.

At S2, the payor's device 101 sets up a registration with the application server 140. The payor submits its credit/debit card information with the server 140. The payor's device 101 has the same mobile payment application 105 (as running on the payee's device) running on it.

At S3, the payor brings its mobile device 101 near the payee's mobile device 120 and the payor confirms that he would like to make a payment to the payee's device 120. The payor's device 101 sends a payor's ID to the payee's device 120. This communication can for example take place though an audio signal or other suitable way. At S4, the payee's mobile device 120 sends the payor's ID and a payor's ID to the application server 140 to confirm that a transaction will take place particularly between the payor and payee's devices 101 ,120.

As an alternative option to S3 and S4, the payor device can send payor's ID to the server and the payee's device can send the payee's ID to the server but these two communications are linked or associated to indicate to the server that a payment transaction would take place between the devices of the payor and payee. The main aim of steps S3 and S4 is to ensure that the application server 140 is aware of the identifications of the two dedicated devices between which a transaction will take place.

At S5, if the payor's device 101 has internet connection, it connects to the application server 140 and requests to generate a unique code. In one embodiment, the application server 140 uses the microprocessor 150 to encode the payor's card details and payor ID in the unique code and sends it to the payor's device. Alternatively, if the payor's device 101 does not have internet connection, the payor would separately connect to the application server, for example using a computer prior to visiting the payee for making the payment. The application server 140 will then generate the unique code which the payor will manually type on the mobile payment application 105 running on its mobile device 101. At S6, the payor enters the amount he wishes to pay the payee. The payment application then encodes the code from the application server 140 and the payment amount into a one-time usable encrypted code. At S7, the application 105 running on the payor's device 101 is configured to transmit the one time encrypted code to the payee's device 120. In one embodiment, the payor's device 101 transmits the code through an audio signal using the speaker 110 of the payor's device 101. The audio signal can be in any frequencies and therefore it may or may be not heard by a human.

At S8, the payee's device 120 uses its microphone 135 to receive the audio signal containing the one time encrypted code including the payment information (credit card information and payment amount) and payor's ID. The payee's device 120 is unable to decrypt the code received from the payor's device. Therefore the payee's device does not get any credit/debit card details of the payor.

At S9, the application running on the payee's device 120 is configured to send the encrypted code to the application server 140, preferably through internet communication. The payee's device may send a further payee's ID in association with the one-time usable encrypted code.

At S10, the application server uses the encrypted code to obtain the credit card details and payment value. The encrypted code now expires and cannot be used again as this is one time usable. In one embodiment, the server can then compare the decrypted payor ID with the payer ID sent in S4 and further may compare the payee's ID sent in S4 and in S9. If a matching is found, the server may authorise the transaction.

At S11 , the application server 140 sends the payor's card details to the relevant banking server and completes the transaction.

At S12, once the payment is authorised from the banking server, the application server 140 sends confirmation to the payee's device 120 that the transaction has been completed. Figure 4 illustrates an example of a third scenario of a mobile to mobile payment process. In particular the figure shows the following steps.

At S1 , the same steps are performed as described above with reference to the first scenario, except that the payee also provides additional authentication means or data. In one example, the payee generally provides one or more of the payee's unique finger print, voice and/or face detection functionality. For example, the payee can take his finger print by using a relevant application in a mobile device. The finger print can then be transferred to the server which stores the finger print under the payee's account. Similarly, the payee can record his voice using a mobile device and transfers to the service which saves the voice under the payee's account. This voice can be verified when with a voice file sent again from the payee, for example, with the unique one time transaction code. Furthermore, the payee can also take the picture of his/her face and transfers that to the server. The server stores the picture under the payee's account. This picture of the payee can be verified with a state-of-the-art face detection technique when the payee sends a further picture, for example, with a transaction code. The information, for example, finger print, voice, picture, of the payee are also registered in the server so that the server can use them as secondary authentication means or data of the payment system. The unique ID generated by the server for the payee is associated with the fingerprint, voice and picture of the payee.

At S2, the payor's device 101 has the same mobile payment application 105 (as running on the payee's device) running on it. In one example, the payment application 105 already stores the credit/debit card details. Alternatively the payor can enter the details of a credit/debit card in the payment application 105. The payment application also stores further authentication information such as payor's fingerprint, voice and/or picture. The further authentication information can be automated such that the mobile payment application 105 can use it. The further authentication information of the payor is associated with the payor's ID generated by the application 105.

At S3, the payor brings its mobile device 101 near the payee's mobile device 120 and the payor confirms that s/he would like to make a payment to the payee's device 120. The payor's device 101 sends a payor's ID and the associated fingerprint, voice and/or picture to the payee's device. At S4, the payee's mobile device 120 sends the payor's ID and the associated fingerprint, voice and/or picture of the payor to the application server 140 to confirm that a transaction will take place particularly between the payor and payee's devices 101 , 120. The payee's device 120 can also send its own ID and further authentication information to the service. The main aim of the steps S3 and S4 is to ensure that the application server 140 is aware of the identifications of the two devices between which a transaction will take place.

At S5, the payor enters on the payment application running on his mobile device the amount he wishes to pay the payee. In this example the application 105 already securely stores the credit/debit card information of the payor. The application 105 then encodes the credit card details, the amount of payment, the payor's ID, finger print, voice and/or picture of the payor into an encrypted code which is only one time usable. It will be appreciated the application can encode one or more of the fingerprint, voice and picture. The application 105 can provide the choice to select one or more of the further authentication information.

At S6, the application 105 running on the payor's device 101 is configured to transmit the one time encrypted code to the payee's device 120. In one embodiment, the payor's device 101 transmits the code through an audio signal using the speaker 110 of the payor's device 101. The audio signal can be in any frequencies and therefore it may or may be not heard by a human.

At S7, the payee's device 120 uses its microphone 135 to receive the audio signal containing the one time encrypted code including the payment information (credit card information and payment amount) and payor's ID. The payee's device 120 is unable to decrypt the code received from the payor's device. Therefore the payee's device does not get any credit/debit card details of the payor. At S8, the application running on the payee's device 120 is configured to send the encrypted code to the application server 140, preferably through an internet communication. In one example, the payee's device 120 can also send the fingerprint, voice and/or picture of the payee to the server along with the encrypted code. It will be appreciated that other types of communication between the server and the payee's device is possible. At S9, the application server decrypts the encrypted code to obtain the credit card details, payment value, payor's ID, and one or more of the payor's fingerprint, voice and picture. The encrypted code now expires and cannot be used again as this is only one time usable. The server then compares the decrypted payor's ID and payor's fingerprint, voice and/or picture with those received from the payee's device in S4. The server also compares the payee's ID and fingerprint, voice and/or picture of payee stored at the time of payee's registration, or alternatively those sent for the payee in S4, with those sent from the payee's device at the time of sending the encrypted code from the payee's device. If the server finds match between these information for both the payor and payee then the server would authorise a transaction.

At S1 1 , once the payment is authorised from the banking server, the application server 140 sends confirmation to the payee's device 120 that the transaction has been completed. Similar to the situation in the first scenario, in the third scenario, the payor's mobile device 101 may or may not have internet connection to connect the application server 140. The payor's mobile device 101 may not have registration with the application server. The payor's device 101 may simply have the mobile payment application 105 installed on the mobile device 101. The payee's device 120 generally has internet connection so that it can connect to the application server 140 during or after the transaction.

Figure 5 illustrates an example of a fourth scenario of a mobile to mobile payment process. In particular the figure shows the following steps.

At S1 , the same steps are performed as described above with reference to the third scenario in Figure 4.

At S2, the payor's device 101 sets up a registration with the application server 140. The payor submits its credit/debit card information with the server 140. The payor also submits to the server one or more authentication information such as fingerprint, voice and/or picture of the payor. The payor's device 101 has the same mobile payment application 105 (as running on the payee's device) running on it. At S3, the payor brings its mobile device 101 near the payee's mobile device 120 and the payor confirms that he would like to make a payment to the payee's device 120. The payor's device 101 sends a payor's ID to the payee's device 120. This communication can for example take place though an audio signal or other suitable way.

At S4, the payee's mobile device 120 sends the payor's ID to the application server 140 to confirm that a transaction will take place particularly between the payor and payee's devices 101 , 120. As an alternative option to S3 and S4, the payor device can send payor's ID to the server and the payee's device can send the payee's ID to the server but these two communications are linked or associated to indicate to the server that a payment transaction would take place between the devices of the payor and payee. The main aim of steps S3 and S4 is to ensure that the application server 140 is aware of the identifications of the two dedicated devices between which a transaction will take place.

At S5, if the payor's device 101 has internet connection, it connects to the application server 140 and requests to generate a unique one time usable code. In one embodiment, the application server 140 uses the microprocessor 150 to encode the payor's card details, payor ID, and the further authentication information such as fingerprint, voice and/or picture of the payor in the unique code and sends it to the payor's device. Alternatively, if the payor's device 101 does not have internet connection, the payor would separately connect to the application server, for example, using a computer prior to visiting the payee for making the payment. The application server 140 will then generate the unique code which the payor will manually type on the mobile payment application 105 running on its mobile device 101.

At S6, the payor enters the amount he wishes to pay the payee. The payment application then encodes the unique code from the application server 140 and the payment amount into a one-time usable encrypted code. This one time usable encrypted code also includes the further authentication information such as fingerprint, voice and/or picture of the payor.

At S7, the application 105 running on the payor's device 101 is configured to transmit the one time encrypted code to the payee's device 120. In one embodiment, the payor's device 101 transmits the code through an audio signal using the speaker 110 of the payor's device 101. The audio signal can be in any frequencies and therefore it may or may be not heard by a human. At S8, the payee's device 120 uses its microphone 135 to receive the audio signal containing the one time encrypted code including the payment information (credit card information and payment amount) and payor's ID. The payee's device 120 is unable to decrypt the code received from the payor's device. Therefore the payee's device does not get any credit/debit card details of the payor.

At S9, the application running on the payee's device 120 is configured to send the encrypted code to the application server 140, preferably through internet communication. The application on the payee's device 120 also sends the payee's ID and the payee's fingerprint, voice and/or picture along with the one-time usable encrypted code to the server.

At S10, the application server uses the encrypted code to obtain the credit card details and payment value. The application server also obtains the payor's fingerprint, voice and/or picture from the decrypted code. The encrypted code now expires and cannot be used again as this is one time usable. The server then compares the decrypted payor's ID and payor's fingerprint, voice and/or picture with those stored during the registration of the payor in S2. The server also compares the payee's ID and fingerprint, voice and/or picture of payee stored at the time of payee's registration (in S1) with those sent (in S9) from the payee's device at the time of sending the encrypted code from the payee's device. If the server finds match between these information for both the payor and payee then the server would authorise a transaction.

At S11 , the application server 140 sends the payor's card details to the relevant banking server and completes the transaction. At S12, once the payment is authorised from the banking server, the application server 140 sends confirmation to the payee's device 120 that the transaction has been completed. It will be appreciated that the secondary authentication information can be automated to encode it in the one-time usable code. It may not be necessary to encode all of these variations in one code, i.e. it can be possible to encode only one of them. Alternatively it can be possible to encode more than two or all of them. It will be appreciated that the invention is not limited to a particular type of encryption/decryption technique. Any suitable technique for this can be used. It will be also appreciated that transmitting an encrypted code via an audio signal can use any suitable audio signal encoding technique usable to a standard mobile communication device. The audio signal can be in both ultrasound frequencies and infrasound frequencies.

Figure 6 illustrates an alternative mobile to mobile payment system 100. Many features of the payment system 100 are similar to that of Figure 1 , and therefore carry the same reference numerals. However, the payment system 100 additionally includes a reviewing server 610. The reviewing server 610 includes IDs of the devices 101 , 120 of the payor and payee. The reviewing server 610 also includes reviewing information for both payor and payee. The reviewing information is linked with the IDs of the payor and payee. Figure 7 illustrates an example of a mobile to mobile payment process using the mobile to mobile payment system of Figure 6. In particular the figure shows the following steps.

At S1 , the same steps are performed as described above with reference to the first scenario in Figure 2.

At S2, the payor's device 101 sets up a registration with the application server 140. The payor submits its credit/debit card information with the server 140. The payor's device 101 has the same mobile payment application 105 (as running on the payee's device) running on it. At S3, the payor brings its mobile device 101 near the payee's mobile device 120 and the payor confirms that s/he intends to initiate a payment to the payee's device 120. The payor's device 101 sends a payor's ID to the payee's device 120. This communication can for example take place though an audio signal or other suitable way.

At S4, the payee's mobile device 120 sends the payor's ID and a payor's ID to the application server 140 to indicate that a transaction may take place particularly between the payor and payee's devices 101 ,120. The application server then sends the IDs of the associated payor and payee to the reviewing server 610. The reviewing server 610 then fetches (retrieves) the previously reviewed information for the payee and can send that information directly to the associated payor's device 101. The payor therefore can view the review of the payee prior to making the decision whether or not to make a payment to the payee. For example, if the review is positive the payor may wish to make a payment to the payee.

As an alternative option to S3 and S4, the payor device can send payor's ID to the server and the payee's device can send the payee's ID to the server but these two communications are linked or associated to indicate to the server that a payment transaction would take place between the devices of the payor and payee. The main aim of steps S3 and S4 is to ensure that the application server 140 is aware of the identifications of the two dedicated devices between which a transaction may take place. The server then sends the associated IDs of the payor and payee to the reviewing server 610 which is then configured to fetch the reviewing information of the payee and send that directly to the payor's device 101.

At S5, if the payor is happy that s/he would like to pursue with the transaction based on the reviewing information received from the reviewing server 610, s/he would like to generate the unique one-time usable code. If the payor's device 101 has internet connection, it connects to the application server 140 and requests to generate a unique code. In one embodiment, the application server 140 uses the microprocessor 150 to encode the payor's card details and payor ID in the unique code and sends it to the payor's device. Alternatively, if the payor's device 101 does not have internet connection, the payor would separately connect to the application server, for example using a computer prior to visiting the payee for making the payment. The application server 140 will then generate the unique code. The payor can then manually type the unique code on the mobile payment application 105 running on its mobile device 101. At S6, the payor enters the amount he wishes to pay the payee. The payment application then encodes the code from the application server 140 and the payment amount into a one-time usable encrypted code.

At S7, the application 105 running on the payor's device 101 is configured to transmit the one time encrypted code to the payee's device 120. In one embodiment, the payor's device 101 transmits the code through an audio signal using the speaker 110 of the payor's device 101. The audio signal can be in any frequencies and therefore it may or may be not heard by a human. Alternatively, the one-time usable code can be transmitted through other medium, for example a voice over IP (VoIP) medium such as Skype.

At S8, the payee's device 120 uses its microphone 135 to receive the audio signal containing the one time encrypted code including the payment information (credit card information and payment amount) and payor's ID. It will be appreciated that the encrypted code can be received through other medium such as VoIP. The payee's device 120 is unable to decrypt the code received from the payor's device. Therefore the payee's device does not get any credit/debit card details of the payor.

At S10, the application server uses the encrypted code to obtain the credit card details and payment value. The encrypted code now expires and cannot be used again as this is one time usable. In one embodiment, the server can then compare the decrypted payor ID with the payer ID sent in S4 and further may compare the payee's I D sent in S4 and in S9. If a matching is found, the server may authorise the transaction. At S11 , the application server 140 sends the payor's card details to the relevant banking server and completes the transaction.

At S12, once the payment is authorised from the banking server, the application server 140 sends confirmation to the payee's device 120 that the transaction has been completed.

At S13, the server 140 notifies the reviewing server 610 that a payment has been made between the payor and payee. The reviewing server 610 then sends a new reviewing option to the payor device 101 so that the payor can provide a new review on the payee, for example, on the service of the payee. If and when the payor has processed the new review information, it is stored in the reviewing server 610.

Although the aforementioned description describes a short range communication between two mobile devices through a sound signal, it will be appreciated that the communication between two mobile devices is not limited to a short distance communication.

Figure 8 illustrates an alternative mobile to mobile payment system. Many features of this system are similar to those shown in Figures 1 and 6 and therefore carry the same reference numerals. However, the communication between two mobile devices is conducted through a VoIP network, for example Skype. Therefore the payment process described above with reference to Figures 1 to 7 is applied but in this process the mobile devices do not communicate using a short distance communication technique in which a speaker and a microphone of the mobile devices are used. Instead, the mobile devices communicate using the VoIP network. One mobile device 101 may generate the one-time usable code as described above and then can transmit the one-time usable code through the VoIP network. The other mobile device 120 can receive the one-time usable code through the VoIP network. It would be appreciated that the transmission of the one-time usable code is conducted when the payor makes a VoIP call to the payee. When the one-time usable code is transmitted over the VoIP network, it would be understood that the one-time usable code is encoded in a sound signal which is then transmitted through the VoIP network. The recipient device 120 is configured to listen to the sound signal transmitted over the VoIP network and recognise the sound signal including the one-time usable code. In a further embodiment, the payment process can be completed even when the recipient device does not answer the VoIP call from the first mobile device (e.g. the payor mobile device). In such a case, the sound signal including the one-time usable code can be encoded into a voice message. When the payee listens to the voice message at a later stage, the mobile device 120 of the payee is able to recognise the one-time usable code from the voice message and then complete the payment process as described in the embodiments of Figures 1 to 8. It will be appreciated that the mobile to mobile communication can be conducted using a standard telecommunication network (instead of a VoIP network). The one-time usable code can be transmitted through the telecommunication network and the recipient mobile device 120 can accept the one-time usable code through the telecommunication network. In such a case, for example, the payor can use the payor device 101 to make a phone call to a phone of the payee and if the payee is not able to pick up the call, the payor is able to leave voice message including the one-time usable code. The payee can then listens to the voice message and use the payee device 120 to recognise the one-time usable code. The payee device then sends the one-time usable code to the application server which then completes the payment transaction.

It would be apparent to the skilled person that the payment process is very similar as described with reference to Figures 1 to 8, but the differences are based on the ways the one-time usable code including the transaction information is transmitted between the two mobile devices. It would be apparent that the mobile devices do not have to be located in a short distance to transmit the one-time usable code through a speaker (of the first device 101) and receive the one-time usable code using a microphone (of the second device 120). Both devices can be located in a long distance, for example, in different countries and the one-time usable code carrying the transaction details can be transmitted through a VoIP network or other known telecommunications network.

In a further embodiment, the payment process can be completed when, for example, the payor browsed to a specific website using the payor device 101. The website can be for example associated with the application software running on the payor device 101. The website is capable of generating the required one-time usable code including the transaction details. In one example, the website can then embed the one-time usable code into a sound signal and then the sound signal is played from the website. The mobile device is able to transmit the sound signal including the one-time usable code played from the website through the speaker of the payor mobile device 101. In one example, the payee's device 120 can receive the sound signal through the microphone of the payee's device 120. The payee's device 120 can then send the sound signal to the server and the payment transaction can be completed in the same steps described hereinbefore. It will be appreciated that the sound signal from the payor's device 101 can be transmitted through VoIP or any other telecommunications network as described in the relevant embodiments above.

Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.

Claims

CLAIMS:

1. A mobile to mobile payment method comprising:

sending a one-time usable encrypted code from a first mobile device associated with a payor, the one-time usable encrypted code comprising an identifier of the first mobile device and an amount of payment;

receiving the one-time usable encrypted code at a second mobile device associated with a payee;

receiving the one-time usable encrypted code at a server from the second mobile device;

using the server to execute a transfer of the amount of payment to an account associated with the payee using the payment card number of the payor.

2. A mobile to mobile payment method according to claim 1 , wherein the one time usable encrypted code further comprises at least a card number of a payment of the payor.

3. A mobile to mobile payment method comprising:

receiving the one time usable encrypted code at a second mobile device associated with a payee;

receiving the one time usable encrypted code at a server from the second mobile device;

decrypting at the server the one time usable encrypted code to obtain the identifier of the first mobile device, the amount of payment and the card number of the payment card of the payor, wherein the encrypted code is expired after the decryption; and using the server to execute a transfer of the amount of payment to an account associated with the payee using the payment card number of the payor.

4. A method according to any preceding claim, further comprising:

5. A method according to claim 1 , 2 or 3, further comprising:

6. A method according to any preceding claim, wherein the encrypted code further comprises secondary payor authentication data comprising one or more of fingerprint, voice and/or picture of the payor.

7. A method according to claim 6, further comprising generating at the second mobile device secondary payee authentication data comprising one or more of fingerprint, voice and/or picture of the payee.

8. A method according to claim 7, further comprising:

prior to sending the encrypted code from the first device to the second device, receiving at the server the identifier of the first mobile device and the secondary payor authentication data from the first mobile device in association with an identifier of the second mobile device and the secondary payee authentication data from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices;

9. A method according to claim 7, further comprising:

10. A mobile to mobile payment method according to any preceding claim, further comprising:

receiving the identifier of the first mobile device in association with the identifier of the second mobile device at a reviewing server from the server such that the reviewing server identifies that the payment transaction can take place between the first and second mobile devices;

retrieving prior reviewing information associated with the second mobile device based on the identifier of the second mobile device received in association of the identifier of the first mobile device; and

sending the prior reviewing information associated with the second mobile device to the first mobile device so that the payor of the first mobile device can view the review information of the payee associated with the second mobile device prior to making the payment to the second mobile device.

1 1. A mobile to mobile payment method according to claim 10, further comprising: after the payment has been made to the second device, receiving a reviewing panel at the first mobile device from the reviewing server so that the payor associated with the first mobile device can provide a new review on the payee associated with the second mobile device.

12. A mobile to mobile payment method according to claim 1 1 , further comprising receiving the new review information at the reviewing server from the first mobile device.

13. A method according to any preceding claim, wherein the step of sending the encrypted code from said first mobile device to said second mobile device, uses a short range communications link between the first and second mobile devices so that interception of the encrypted code is restricted at beyond an operating range of the link.

14. A method according to any preceding claim, wherein the step of sending the encrypted code from said first mobile device to said second mobile device comprises sending the code over a direct link between said first and second mobile devices.

15. A method according to claim 14, wherein said direct link comprises an audio signal link transmitted from a speaker of the first mobile device to a microphone of said second mobile device.

16. A method according to any one of claims 1 to 12, wherein the step of receiving the encrypted code at the second mobile device comprises receiving the code via a direct signal from said first mobile device.

17. A method according to any preceding claim, wherein the step of receiving the encrypted code at the second mobile device comprises receiving the code via an audio signal received at a microphone of the second mobile device and wherein said server receives a version of said audio signal.

18. A method according to any one of claims 1 to 12, wherein the step of sending the encrypted code from first mobile device to said second mobile device comprises sending the code over a voice over IP, VoIP, network.

19. A method according to any one of claims 1 to 12, wherein the step of sending the encrypted code from first mobile device to said second mobile device comprises sending the code over a telecommunications network.

20. A method according to claim 18 or 19, further comprising embedding the code in a sound signal and transmitting the sound signal over the VoIP network or the telecommunications network.

21. A method according to claim 18, 19 or 20, further comprising embedding the code in a voice message of a VoIP call and/or a standard telecommunications call.

22. A method according to claim 21 , further comprising receiving the sound signal at the second device when the voice message is being played.

23. A method according to any one of claims 1 to 12, further comprising: generating the code in a website;

embedding the code in a sound signal at the website;

accessing the website at the first device;

playing the sound signal from the website which is being run on the first device; and

receiving the sound signal including the one-time usable code at the second device from the first device.

24. A method according to any one of claims 1 to 12, further comprising generating the one time usable encrypted code by a first payment application on the first mobile device.

25. A method according to any one of claims 1 to 12, further comprising:

generating at the server the one time usable encrypted code comprising the card number of the payment of the payor and the identifier of the first mobile device; receiving at the first mobile device the one time usable encrypted code, and incorporating the payment amount in the encrypted code by a first payment application.

26. A method according to any preceding claim, further comprising receiving a message at the second mobile device from the server to confirm that the payment has been successfully made.

27. A mobile to mobile payment system comprising: a first mobile device associated with a payor configured to send a one-time usable encrypted code, the one-time usable encrypted code comprising an identifier of the first mobile device and an amount of payment;

28. A payment system according to claim 27, wherein the one-time usable encrypted code further comprises at least a card number of a payment of the payor.

29. A mobile to mobile payment system comprising:

30. A payment system according to claim 27, 28 or 29, wherein, prior to sending the encrypted code from the first device to the second device, the server is configured to receive the identifier of the first mobile device from the first mobile device in association with an identifier of the second mobile device from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices; wherein the server is configured to receive, in association with said encrypted code from said second mobile device, an identifier of said second mobile device; and wherein said execution of said transfer is conditional on said identifier of said second mobile device received in association with said encrypted code matching said identifier of said second mobile device received in association with said identifier of said first mobile device; and conditional on the decrypted said identifier of said first mobile device matching the said identifier of said first mobile device received in association with said identifier of said second mobile device.

31. A payment system according to claim 27, 28 or 29, wherein, prior to sending the encrypted code from the first device to the second device, the second device is configured to receive from the first mobile device the identifier of the first mobile device, and the server is configured to receive from the second mobile device the identifier of the first mobile device and an identifier of the second mobile device so as to confirm that a payment will take place between the first and second mobile devices,

wherein the server is configured to receive, in association with said encrypted code from said second mobile device, an identifier of said second mobile device; and wherein said execution of said transfer is conditional on said identifier of said second mobile device received in association with said encrypted code matching said identifier of said second mobile device received in association with said identifier of said first mobile device; and conditional on the decrypted said identifier of said first mobile device matching the said identifier of said first mobile device received in association with said identifier of said second mobile device.

32. A payment system according to any one of claims 27 to 31 , wherein the encrypted code further comprises secondary payor authentication data comprising one or more of fingerprint, voice and/or picture of the payor.

33. A payment system according to claim 32, wherein the second mobile device is configured to generate secondary payee authentication data comprising one or more of fingerprint, voice and/or picture of the payee.

34. A payment system according to claim 33, wherein, prior to sending the encrypted code from the first device to the second device, the server is configured to receive the identifier of the first mobile device and the secondary payor authentication data from the first mobile device in association with an identifier of the second mobile device and the secondary payee authentication data from the second mobile device to confirm that a payment transaction will take place between the first and second mobile devices;

wherein the server is configured to receive, in association with said encrypted code from said second mobile device, an identifier of said second mobile device and the secondary payee i authentication data; and

35. A payment system according to claim 33, wherein, prior to sending the encrypted code from the first device to the second device, the server is configured to receive at the second mobile device from the first mobile device the identifier of the first mobile device and the secondary payor authentication data, and

wherein the server is configured to receive from the second mobile device the identifier of the first mobile device and the secondary payor authentication data and an identifier of the second mobile device and the secondary payee authentication data so as to confirm that a payment transaction will take place between the first and second mobile devices; wherein the server is configured to receive, in association with said encrypted code from said second mobile device, said identifier of said second mobile device and said secondary payee authentication data; and

36. A payment system according to any one of claims 27 to 35, being configured to send the encrypted code from said first mobile device to said second mobile device using a short range communications link between the first and second mobile devices so that interception of the encrypted code is restricted at beyond an operating range of the link.

37. A payment system according to any one of claims 27 to 36, wherein the first device is configured to send the code over a direct link between said first and second mobile devices.

38. A payment system according to claim 37, wherein said direct link comprises an audio signal link transmitted from a speaker of the first mobile device to a microphone of said second mobile device.

39. A payment system according to any one of claims 27 to 35, wherein the second mobile device is configured to receive the encrypted code via a direct signal from said first mobile device.

40. A payment system according to any one of claims 27 to 39, wherein the second mobile device is configured to receive the encrypted code via an audio signal received at a microphone of the second mobile device and wherein said server receives a version of said audio signal.

41. A payment system according to any one of claims 27 to 35, wherein the first mobile device is configured to send the encrypted code to said second mobile device over a voice over IP, VoIP, network.

42. A payment system according to any one of claims 27 to 35, wherein the first mobile device is configured to send the encrypted code to said second mobile device over a telecommunications network.

43. A payment system according to claim 41 or 42, being configured to embed the code in a sound signal and transmit the sound signal over the VoIP network or the telecommunications network.

44. A payment system according to claim 41 , 42 or 43, being configured to embed the code in a voice message of a VoIP call and/or a standard telecommunications call.

45. A payment system according to claim 44, wherine the second device is configured to receive the sound signal when the voice message is being played.

46. A payment system according to any one of claims 27 to 35,

wherein a website is configured to generate the code and embed the code in a sound signal,

wherein the first device is configured to access the website and play the sound signal from the website, and

wherein the second device is configured to receive the sound signal including the one-time usable code from the first device.

47. A payment system according to any one of claims 27 to 35, wherein the first mobile device is configured to generate the one time usable encrypted code by a first payment application on the first mobile device.

48. A payment system according to any one of claims 27 to 48, wherein the server is configured to generate the one time usable encrypted code comprising the card number of the payment of the payor and the identifier of the first mobile device, and the first mobile device is configured to receive the one time usable encrypted code and incorporate the payment amount in the encrypted code by a first payment application.

49. A payment system according to any one of claims 27 to 48, wherein the second mobile device is configured to receive a message from the server which confirms that the payment has been successfully made.

50. A mobile to mobile payment system comprising:

a first mobile device associated with a payor configured to send a one-time usable encrypted code, the one-time usable encrypted code comprising an identifier of the first mobile device, an amount of payment, at least a card number of a payment of the payor and secondary payor authentication data comprising one or more of fingerprint, voice and/or picture of the payor;

51. A mobile device for making a payment to a further mobile device, the mobile device comprising:

a memory configured to store a payment application with a user interface to receive instruction data for making the payment;

a processor configured to generate a one time usable encrypted code based on the instruction data, the one time usable encrypted code comprising an identifier of the mobile device, an amount of payment and at least a card number of a payment of a payor associated with the mobile device; and

a transmitter configured to transmit the encrypted code to the further mobile device via an audio signal.

52. A mobile device according to claim 51 , wherein the transmitter comprises a speaker.

53. A mobile device for receiving a payment from a further mobile device, the mobile device comprising:

a processor configured to control the receiver based on the instruction data so that a one-time usable encrypted code is received in the form of the audio signal.

54. A mobile device according to claim 53, further comprising a transmitter configured to transmit the one time usable encrypted code to a server.