WO2015124776A1

WO2015124776A1 - A system and method of processing a secure payment transaction

Info

Publication number: WO2015124776A1
Application number: PCT/EP2015/053756
Authority: WO
Inventors: Seamus DOLAN
Original assignee: Domulas Limited
Priority date: 2014-02-21
Filing date: 2015-02-23
Publication date: 2015-08-27
Also published as: GB201403097D0; GB2523358A

Abstract

This invention relates to a system (1) and method of processing a secure payment transaction. The system (1) comprises a purchaser's mobile computing device (MCD)(3) having a mobile payments application loaded thereon, a seller's webserver (5) hosting an e-commerce website, an independent authentication webserver (9) and an independent payment service provider (PSP) server (11). The system architecture and method ensure that authenticating communications are sent to the purchaser from two separate entities, the authentication webserver and the PSP server. The method ensures that both the purchaser and the payer are each authenticated in distinct two- step authentication processes, resulting in a four step authentication process in total. This provides a robust system and method. The system and method are device-specific in that they are tied to the purchaser's MCD, specifically a mobile telephone or smartphone,for additional payment transaction processing security.

Description

Title of Invention:

"A System and Method of Processing a Secure Payment Transaction" Technical Field:

This invention relates to a system and method of processing a secure payment transaction with an e-Commerce website. Background Art:

At present, the number of e-Commerce transactions is growing rapidly year on year. Various sources have estimated that in 2012, the value of global e-Commerce business- to-consumer transactions was in excess of US$1 ,000,000,000,000 (One Trillion US Dollars) and the total value of e-Commerce transactions continues to rise. Despite the apparent increase in popularity and the growth in total value of transactions, it is generally accepted that there are still serious concerns regarding the security surrounding e-Commerce transactions. These concerns have dissuaded many consumers from purchasing goods online and restricted even better growth in e- Commerce transactions.

Various systems and methods have been put in place to address these security concerns. For example, PayPal (Registered Trade Mark ®) offers a service in which they effectively act as a trusted third party intermediary between the purchaser and the seller. The purchaser opens a PayPal ® account and provides their billing details including either a credit card, a debit card or bank details to PayPal ®. The sellers offer PayPal ® as a payment method on their site. If a purchaser chooses to carry out an e-Commerce transaction and pay through PayPal ®, they will be redirected to the PayPal ® site and PayPal ® will effectively process the transaction. PayPal ® will pay the seller through PayPal ® accounts and will bill the purchaser using the purchaser's previously provided billing details. In this way, the purchaser's credit card or other financial information does not have to be divulged to the seller each time the purchaser wishes to make an e- Commerce transaction. This has improved the confidence of many consumers in e- Commerce transactions. However, many purchasers still remain sceptical and reluctant to engage in e-Commerce transactions and would prefer even greater security than the security offered at present.

In addition to the foregoing, it is well known that mobile telephone technology and internet connectivity has advanced appreciably in the last 20 years to the point that mobile telephones or so-called smartphones are now commonly used to execute e- Commerce transactions. Furthermore, these smartphones are practically ubiquitous amongst the population aged 15-65 of many developed countries. Accordingly, it is an object of the present invention to provide a system and method of processing a secure payment transaction that offers a useful alternative to the known systems and methods of executing secure payment transactions. It is a further object of the present invention to provide a system and method of processing a secure payment transaction that introduces additional layers of security into each e-Commerce transaction. Finally, it is an object of the present invention to provide a system and method of executing secure payment transactions that is particularly suitable for use with a smartphone.

Summary of Invention:

According to the invention there is provided a method of processing a secure payment transaction in a system comprising a purchaser's mobile computing device (MCD) having a mobile payments application loaded thereon, a seller's webserver hosting an e- commerce website, an independent authentication webserver and an independent payment service provider (PSP) server, the method comprising the steps of:

(i) the MCD operator selecting a secure payment transaction option on the e- commerce website checkout page; (ii) launching an authentication webserver payment transaction page from the e-commerce website checkout page;

(iii) the MCD operator entering a unique contact identifier specific to their MCD into the authentication webserver payment transaction page and submitting the completed authentication webserver payment transaction page to the authentication webserver; the authentication webserver, upon receiving the completed authentication webserver payment transaction page, sending a transaction payment request (TPR) to the MCD identified by the unique contact identifier; the MCD operator, upon receiving the TPR on their MCD, fulfilling the TPR on their MCD, and the MCD sending a TPR fulfillment response to the authentication webserver;

(vi) the authentication webserver, on receiving a TPR fulfillment response from the MCD, instructing the PSP server to proceed with the secure payment transaction;

(vii) the PSP server, on receiving the instruction to proceed with the secure payment transaction from the authentication server, transmitting a secure payment transaction action command to the MCD;

(viii) the MCD operator, upon receiving the secure payment transaction action command, fulfilling the secure payment transaction action command on their MCD, and the MCD sending a secure payment transaction action command fulfillment response to the PSP server; and

(ix) the PSP server, upon receiving the secure payment transaction action command fulfillment response, processing the payment with the e- commerce website. By having such a method of processing a secure payment transaction, the method will be device specific, or in other words will be tied to the MCD operator's device, and will therefore provide a highly secure method of executing e-Commerce transactions. The method described comprises four factor authentication (4FA) of the purchaser by means of a two stage verification process that first of all validates the identity of the purchaser (the person who is attempting to buy the goods) and secondly validates the identity of the payer (the individual whose card or account is debited and who therefore pays for the goods) in one seamless application. Each stage of verification itself has two factor authentication. The purchaser's identity is validated by sending a TPR to the purchasers MCD and then requiring the purchaser to fulfil the TPR. If this is done successfully, the payer's identity is validated by the PSP sending a secure payment transaction action command to the MCD associated with the billing details and requiring the MCD operator to fulfil the secure payment transaction action command before the payment is processed. This provides a very robust method of executing the secure payment transaction and overcomes the inherent security problems with many of the known offerings.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the MCD operator uses their MCD to select a secure payment transaction option on the e-commerce website checkout page. In this way, the MCD operator may instigate a payment using the MCD device itself. Alternatively, the MCD operator could use an alternative computing device to instigate the purchase however the execution of the payment will require the use of the MCD. In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the steps of: (i) the MCD operator selecting a secure payment transaction option on the e-commerce website checkout page and (ii) launching an authentication webserver payment transaction page from the e-commerce website checkout page are performed automatically in response to the MCD operator selecting a purchase option on the e-commerce website. It is envisaged that the MCD operator will not in all cases have to specify that they wish for their payment to be executed according to the method described but instead the method will be executed as a matter of course when carrying out a transaction on certain e-Commerce sites. In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the step of the MCD operator fulfilling the TPR on their MCD comprises the MCD operator logging in to the mobile payments application. This is a particularly simple way for the MCD operator to fulfill the TPR that is quick, simple to perform and not too taxing on the MCD operator. ln one embodiment of the invention there is provided a method of processing a secure payment transaction in which the MCD operator logs in to the mobile payments application by entering a private identification number (PIN) into the mobile payments application. A PIN is seen as a suitable way for the MCD operator to log into their mobile payments application. Alternatively, a password and/or a login name that is only known to the MCD user may be used in place of or in addition to the PIN.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which if the authentication webserver has not received a TPR fulfillment response from the MCD within a first predetermined period of time, the transaction is cancelled. In other words, the TPR will be time limited and will expire after a predetermined period of time. If the MCD user has not confirmed that they wish for the transaction to proceed within a given time limit this may be indicative of a fraudulent transaction or a change of mind on the part of the consumer and the transaction will effectively be cancelled on the cancellation of the TPR.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which if the PSP server has not received a secure payment transaction action command fulfillment response within a second predetermined period of time, the transaction is cancelled. Again, if the MCD user has not confirmed that they wish for the transaction to proceed within a given time limit this may be indicative of a fraudulent transaction or a change of mind on the part of the consumer and the transaction will effectively be cancelled on the failure of the MCD operator to fulfill the secure payment transaction action command.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the TPR is transmitted as a push notification to the mobile payments application. This is seen as a particularly preferred way of implementing the present invention. In this way, the TPR is sent as part of the mobile payments application environment and can be used to automatically launch the mobile payments application in a seamless fashion, simplifying the method and improving functionality and user satisfaction. ln one embodiment of the invention there is provided a method of processing a secure payment transaction in which the secure payment transaction action command is transmitted as a notification to the mobile payments application. Again, in this way, the secure payment transaction action command is sent as part of the mobile payments application environment and can be used to communicate through the mobile payments application on the MCD in a seamless fashion, simplifying the method, improving functionality as well as user satisfaction and encouraging future usage.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the method comprises the preliminary steps of the MCD operator registering their MCD with the independent authorization webserver and providing their payment card information to the PSP server. In this way, there is a degree of separation between the payment details and the customer's details. In the highly unlikely event of a fraudulent attack or fraudulent activity on the authentication webserver, there will not be sufficient information to process a payment. Furthermore, it will not be necessary for the consumer to provide their card details each time they wish to make a purchase.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which, upon completion of the secure payment transaction, the PSP server transmits a payment completed message to the purchaser MCD.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the unique contact identifier is a cellular telephone number. In this way, the MCD can be identified with ease and it will be relatively simple for the MCD operator to recall this unique contact identifier.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the MCD is a smartphone. The present invention is ideally suited to application on a smartphone and to executing secure payment transactions that have been instigated on the smartphone. As smartphones advance further and broadband coverage and availability improve, it is envisaged that these devices will be used more frequently for e-Commerce transaction and will replace more and more commonplace transactions. In one embodiment of the invention there is provided a computer program product having program instructions thereon that when loaded on a computer cause the computer to carry out one or more of the method steps.

In one embodiment of the invention there is provided a method of processing a secure payment transaction by a purchaser's mobile computing device (MCD) in a system comprising a purchaser's MCD having a mobile payments application loaded thereon, a remote seller's webserver hosting an e-commerce website, a remote independent authentication webserver and a remote independent payment service provider (PSP) server, the method comprising the steps of: the MCD operator selecting a secure payment transaction option on the e- commerce website checkout page; the MCD operator entering a unique contact identifier specific to their MCD into an authentication webserver payment transaction page and submitting the completed authentication webserver payment transaction page to the remote authentication webserver; the MCD operator, receiving a transaction payment request (TPR) from the remote authentication webserver on their MCD, the MCD operator fulfilling the TPR on their MCD and sending a TPR fulfillment response to the remote authentication webserver; the MCD operator, receiving a secure payment transaction action command from the remote PSP server on their MCD, the MCD operator fulfilling the secure payment transaction action command on their MCD and sending a secure payment transaction action command fulfillment response to the PSP server.

By having such a method, the MCD user will be able to process a secure payment transaction in a simple and effective manner yet in a very robust, secure manner. The method is specific to the MCD user's device and the MCD user will be afforded four factor authentication security to their purchases.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the step of the MCD operator fulfilling the TPR on their MCD comprises the MCD operator logging in to the mobile payments application.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the MCD operator logs in to the mobile payments application by entering a private identification number (PIN) into the mobile payments application.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the method comprises the preliminary steps of the MCD operator registering their MCD with the independent authorization webserver and providing their payment card information to the PSP server.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which the unique contact identifier is a cellular telephone number.

In one embodiment of the invention there is provided a method of processing a secure payment transaction by an independent authentication webserver, in a system comprising a remote purchaser's mobile computing device (MCD) having a mobile payments application loaded thereon, a remote seller's webserver hosting an e- commerce website, the independent authentication webserver and a remote independent payment service provider (PSP) server, the method comprising the steps of: (x) the authentication webserver receiving a completed authentication webserver payment transaction page including a unique contact identifier specific to the MCD; (iv) the authentication webserver, upon receiving the completed authentication webserver payment transaction page, sending a transaction payment request (TPR) to the MCD identified by the unique contact identifier;

(vi) the authentication webserver, on receiving a TPR fulfillment response from the MCD, instructing the e-commerce website and the PSP server to proceed with the secure payment transaction. By having such a method, an independent authentication webserver will be able to verify the identity of a person intending to make a purchase in a straightforward and unobtrusive way. The method steps undertaken will allow the authentication webserver to check that the person with the MCD in question is the same person that has an account with the independent authentication webserver and has access to the codes to access the mobile payments application.

In one embodiment of the invention there is provided a method of processing a secure payment transaction by an independent authentication webserver in which the authentication server sends the transaction payment request (TPR) to the MCD identified by the unique contact identifier in a push notification to the mobile payments application on the MCD.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which if the authentication webserver has not received a TPR fulfillment response from the MCD within a first predetermined period of time, the transaction is cancelled.

In one embodiment of the invention there is provided a method of processing a secure payment transaction by an independent payment service provider (PSP) server, in a system comprising a remote purchaser's mobile computing device (MCD) having a mobile payments application loaded thereon, a remote seller's webserver hosting an e- commerce website, a remote independent authentication webserver and the independent PSP server, the method comprising the steps of: (xi) the PSP server receiving from the authentication webserver an instruction to proceed with a secure payment transaction;

(vii) the PSP server, on receiving the instruction to proceed with the secure payment transaction from the authentication server, transmitting a secure payment transaction action command to the remote MCD;

(xi) the PSP server receiving from the MCD a secure payment transaction action command fulfillment response; and

(ix) the PSP server, upon receiving the secure payment transaction action command fulfillment response, processing the payment with the e- commerce website. This is seen as a particularly useful way for the PSP server to operate as the identity of the individual wishing to make a payment has already been established and the PSP server can then check that the person attempting to make the payment is the person authorised to use the account and charge the card or the bank account in PSP memory. This will provide a robust, secure method of processing the payment transaction.

In one embodiment of the invention there is provided a method of processing a secure payment transaction by an independent PSP server in which the PSP server sends the secure payment transaction action command to the remote MCD in a push notification to the mobile payments application on the MCD.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in which if the PSP server has not received a secure payment transaction action command fulfillment response within a second predetermined period of time, the transaction is cancelled.

In one embodiment of the invention there is provided a method of processing a secure payment transaction in a system comprising a purchaser's mobile computing device (MCD) having a mobile payments application loaded thereon, a seller's webserver hosting an e-commerce website, an independent authentication webserver and an independent payment service provider (PSP) server, the method comprising the steps of: the MCD operator transmitting an MCD unique contact identifier to the independent authentication webserver; the authentication webserver sending a transaction payment request (TPR) to the MCD identified by the unique contact identifier; the MCD operator fulfilling the TPR on their MCD and sending a TPR response to the authentication webserver; the authentication webserver, on receiving the TPR response, signaling the e- commerce website and the PSP server to proceed with the secure payment transaction; the PSP server, on receiving the signal to proceed, transmitting a secure payment transaction action command to the MCD; the MCD operator, upon receiving the secure payment transaction action command, fulfilling the secure payment transaction action command on their MCD and sending a secure payment transaction action command fulfillment response to the PSP server; and the PSP server, upon receiving the secure payment transaction action command fulfillment response, processing the payment with the e-commerce website.

As before, by having such a method of processing a secure payment transaction, the method will be device specific, tied to the MCD operator's device, and will therefore provide a highly secure method of executing e-Commerce transactions. The method uses four factor authentication of the purchaser by means of a two stage verification process that first of all validates the identity of the purchaser (the person who is attempting to buy the goods) and secondly validates the identity of the payer (the individual whose card is debited and who therefore pays for the goods) in one seamless application. Each stage of verification itself has two factor authentication. The purchaser's identity is validated by sending a TPR to the purchasers MCD and then requiring the purchaser to fulfil the TPR. If this is done successfully, the payer's identity is validated by the PSP sending a secure payment transaction action command to the MCD associated with the billing details and requiring the MCD operator to fulfil the secure payment transaction action command before the payment is processed. This provides a very robust method of executing the secure payment transaction and overcomes the inherent security problems with many of the known offerings. In one embodiment of the invention there is provided a system for processing a secure payment transaction with a seller's e-commerce website, the system comprising: a purchaser's mobile computing device (MCD), an independent authentication webserver, and an independent payment service provider (PSP) server; and in which:- the MCD has a mobile payments application loaded thereon for communication with the authentication webserver; the independent authentication webserver comprises a first communications module to communicate with the mobile payments application on the MCD and a second communications module to communicate with the PSP server; and the independent PSP having a first communications module to communicate with the mobile payments application on the MCD, a second communications module to communicate with the independent authentication webserver and a third communications module to communicate with the seller's e-commerce website. This system is seen as a relatively simple system to implement and will provide a secure environment in which the payment transactions may be executed. The fact that there is a separate PSP and separate authentication server leads to a more robust system that will be less prone to attack than other existing architectures. ln one embodiment of the invention there is provided a system in which the independent authentication webserver comprises a database having a plurality of MCD operator mobile payment application account records thereon, the mobile payment application account records each including an MCD unique contact identifier and an MCD operator's personal identification number (PIN). This structure will allow the MCD to be identified by the independent authentication webserver quickly with minimum computational overhead.

In one embodiment of the invention there is provided a system in which the independent authentication webserver comprises a pair of webservers, each having a database having a portion of each of the MCD operator mobile payment application account records thereon. By providing a pair of servers, a more secure system will be provided as a successful attack, however unlikely that may be, on one of the servers will be of relatively little benefit as the information available will be incomplete and not sufficient to enable a fraudster to manipulate the data to their advantage.

In one embodiment of the invention there is provided a system in which the MCD unique contact identifier is stored on the database of one of the pair of webservers and the MCD operator's PIN is stored on the other database of the other of the pair of webservers.

In one embodiment of the invention there is provided a system in which the independent PSP comprises a database having a plurality of MCD operator mobile payment application payment records thereon, the mobile payment application payment records each including payment card details for the MCD operator.

In one embodiment of the invention there is provided a system in which the independent authentication webserver and the independent PSP server communicate with each other through an Application Programming Interface (API). Preferably, any communications between the servers avails of secure socket layer (SSL) technology.

In one embodiment of the invention there is provided a system in which the MCD is a smartphone. Brief Description of the Drawings:

The invention will now be more clearly understood from the following description of some embodiments thereof given by way of example only with reference to the accompanying drawing, in which:-

Figure 1 is a diagrammatic representation of a system according to the invention; Figure 2 is a diagrammatic representation of the system of Figure 1 but showing the sequence of steps of the method according to the invention; and

Figure 3 is a diagrammatic representation of a system and sequence of steps of an alternative method according to the invention.

Detailed Description of the Drawings:

Referring to Figure 1 , there is shown a system for executing secure payment transactions, indicated generally by the reference numeral 1 , comprising a purchaser's mobile computing device (MCD), in this instance a smartphone 3 having a mobile payments application loaded thereon, and a seller's webserver 5 hosting an e- Commerce website that is accessible by a browser on the MCD over the internet 7. The system 1 further comprises an independent authentication webserver 9 and an independent payment service provider (PSP) server 1 1. The MCD 3, the seller's webserver 5, the authentication webserver 9 and the PSP server 1 1 are all able to communicate over the internet, as represented by the communication channels 13, 15, 17 and 19.

Referring now to Figure 2, there is shown the sequence of communications between the various devices in order to execute the secure payment transaction. Initially, the operator of the MCD is using the MCD 3 or indeed another computing device capable of browsing web pages (not shown) to browse the e-Commerce website hosted by the seller's webserver 5. The purchaser sees an item that they wish to purchase and in order to purchase that item, they proceed to the checkout page on the e-Commerce website. On the website checkout page, there may be provided a number of payment options such as, but not limited to, credit card payment, debit card payment, PayPal ® payment and another icon for payment using the system and method according to the present invention, which for simplicity may be referred to hereinafter as a PAYDAP (trade mark, ™) payment. The MCD operator selects the PAYDAP icon and as a response to the MCD operator's selection, the e-Commerce website launches a PAYDAP web page by redirecting the MCD to the URL of the PAYDAP page and providing details about the payment, such as amount, seller and the like to the PAYDAP page. It will be understood that the rest of the transaction process is effectively carried out away from the e- Commerce webserver and the PAYDAP webserver notifies the e-Commerce webserver when the payment is confirmed, cancelled, or declined.

The MCD operator enters their MCD unique contact identifier, in this instance their MCD's mobile telephone number, into the PAYDAP web page and thereafter their mobile phone number along with details of the transaction including, but not limited to, the seller and the amount of the transaction, are submitted from the merchant webserver to the PAYDAP independent authentication webserver 9 in step 100. On receiving the mobile telephone number and the details of the transaction, the independent authentication webserver 9 creates a time-limited transaction payment request (TPR) which is transmitted to the mobile telephone having the mobile telephone number previously provided in step 200. The TPR is sent as a notification to the mobile payments application on the MCD.

When the MCD 3 operator receives the TPR, it fulfils the TPR by carrying out one or more specified acts, such as logging in to the mobile payments application on the MCD and authorising the purchase. The log-in may require a password, a user name, a personal identification number (PIN) or a combination of two or more of these. Indeed, the log-in may require biometric data included but not limited to a fingerprint or a retinal scan. This logging-in action may itself be sufficient to authorise the purchase and authenticate the person having the MCD as the operator of that MCDs mobile payments application account. Preferably, upon the MCD operator receiving the TPR notification and activating the application, he/she will be first presented with the option to accept or reject the TPR by hitting either "OK" or "Cancel" buttons. This is designed to avoid operator confusion on the MCD user interface. Hitting the "cancel" button will reject the process and alert the authentication server. Hitting the "OK" button will instantly bring up the "Enter PIN" screen and on entering the PIN the MCD operator will again hit "OK" to proceed or he/she can still hit "Cancel". If the MCD operator hits "OK" after entering their PIN, it confirm his/her acceptance of the TPR.

In step 300, as the MCD operator fulfils the TPR, a TPR fulfilment message is transmitted from the MCD back to the authentication webserver 9. The PIN in the TPR is verified by the authentication webserver 9. This two factor authentication has now authenticated the purchaser as the person controlling the MCD 3 and is the first part of the two part, four factor authentication process. In step 400, the independent authentication webserver (also referred to as the PAYDAP server) sends an instruction to the independent payment service provider (PSP) to continue with the payment processing. On receipt of this instruction from the authentication webserver 9, the independent PSP server 1 1 , in step 500, transmits a secure payment transaction action command to the MCD 3. In this instance, the secure payment transaction action command is a unique eight character random transaction secure ID that is sent in the notification. Again, the secure payment transaction action command is sent by way of a notification directly to the MCD 3, bypassing the authentication webserver 9. The PSP will have been provided with the mobile phone number of the MCD upon registration of the card or account details and will be stored with those details in PSP memory. Furthermore, the PAYDAP server and the PSP server communicate securely so in the preceding step 400 when the PAYDAP server sends the notification to the PSP webserver to process the payment, the notification includes the mobile phone number of the MCD along with the details of the transaction so that the PSP can draw on the card/bank account details stored in its database.

In step 600, the MCD operator, upon receiving the secure payment transaction action command from the PSP server, fulfills the secure payment transaction action command on their MCD and the MCD 3 sends a secure payment transaction action command fulfillment response to the PSP server 1 1. Again, this fulfillment action may be achieved by logging into the mobile payments application on the MCD or may simply be by acknowledging the communication by pressing an "OK" button or similar action button that appears on the graphical user interface of their MCD. In step 700, the PSP continues to process the payment with the seller's website and informs the authentication webserver 9. If there are insufficient funds in the account or the card, or the card is not valid (i.e. out of date), the payment will not be processed by the PSP and payment declined message will be sent to one or both of the MCD and the e-Commerce webserver. Various other aspects of the system will now be discussed in more detail. Prior to using the service, various registration steps must be performed by a user. For example, the app must be downloaded and the User must go through a simple 3 stage registration process by completing a number of tasks including: 1. Validating the phone (the app is phone specific) by entering User's phone number including national code, entering a 4 (or more) digit PIN and confirming PIN, and choosing and answering 3 security questions; 2. Creating a PAYDAP account by entering User's name and address, and accepting the Terms & Conditions of use; and 3. Obtaining PSP authorisation by entering the details of the debit/credit card to be used as the payment source. As the card details will be stored with the PSP, the User will not need to enter his card details again when using the app. This registration information is cross checked between the PSP and PAYDAP servers. As a further or alternative step in the registration process, the authenticity of the MCD device can be proven at registration by the authentication server sending an SMS to the MCD device with a 5 digit verification code which in turn is entered by the registering user to validate their phone and activate their account.

In practice, the notification that issues from the authentication webserver when the app user enters his/her phone number in the webserver payment transaction page takes the form of a unique 8-10 character transaction ID code. When the MCD operator enters its PIN to login to the application that ID code is sent back to the authentication server to prove that the MCD operator has actually received the notification and authorized the transaction. This same secure ID code is then sent from the authentication webserver to the PSP as the transaction identifier and the PSP forwards it to the MCD as its payment confirmation request notification. The same code comes back again to the PSP when the MCD operator confirms payment.

The service operates in part due to the fact that the independent authentication webserver 9 and its partner Payment Service Provider (PSP) server 1 1 link and communicate with each other through their APIs. Preferably, there are three servers rather than two servers involved: one server at the PSP and two servers forming the independent authentication server and they all communicate in real time. When a User registers, the User's card details are verified against the User's name and address and the necessary details to complete the payment are stored on the PSP server. These details stored on the PSP may be solely the user's phone number and their card or account details (once verified). However, other details may be stored on the PSP including their name and billing address may be provided if required. The User's PIN, phone number and address is stored on PAYDAP server 1 while the User's phone number, name and security questions are stored on PAYDAP server 2 for security reasons. The only common data stored on all three servers will be the user's mobile phone number. The mobile phone number of the MCD is in effect the MCD operators PAYDAP account number. Critical data is also encrypted as necessary with SSL communications. The service may be offered as a complete payment package to online and offline retailers integrating with the retailer's backend through an API key the same way as other payment service companies such as PayPal ® operate. This is quickly and easily done by the retailer's IT provider. Once the retailer is signed up the PAYDAP icon will appear on the retailer's checkout page, along the other payment options icons.

As described above in relation to Figure 2, in order to use the service in an online purchase transaction (on the smart-phone itself or on another device) the User, now the Purchaser, selects the PAYDAP icon on the e-Commerce checkout page. The PAYDAP page opens and asks the Purchaser to enter his phone number and the PAYDAP software captures the value of the transaction. When the Purchaser enters his/her phone number the software issues a Transaction Payment Request (TPR) to that phone number. This is stage 1 of the verification process - verifying the Purchaser. The TPR appears as a notification on the Purchaser's smart-phone and is time limited. The Purchaser taps the notification and the PAYDAP app opens displaying the TPR amount and retailer's name and offers the User the choice to "Enter PIN to pay" or "Reject". If the Purchaser rejects, the transaction is cancelled. If the Purchaser fails to act, the TPR will lapse, cancelling the transaction. If the Purchaser enters his PIN (which only he knows), it signals to the PAYDAP independent authentication server that the purchaser has the phone to which that phone number relates and therefore closes the circuit, verifies his identity and signals his intention to proceed to pay. If the PIN is incorrectly entered 3 times, the app locks out and the transaction is cancelled e.g. stolen phone. The PAYDAP independent authentication server signals the checkout page and instructs the PSP server 1 1 to process the payment. This it stage 2 of the verification process - verifying the payer (the payment card being tied to the app on that phone). The PSP server 1 1 sends a time limited action command directly to the Purchaser's phone 5, bypassing the PAYDAP independent authentication server, asking the Purchaser to confirm payment of the said amount to the said retailer by tapping "OK" or "Confirm". If the Purchaser fails to act, the payment transaction is cancelled. If the Purchaser taps "OK" the PSP 1 1 processes the payment and confirms same to the retailer (seller) and the Purchaser. The transaction is now complete and the User closes the app. The software stores the User's recent transactions for recording purposes.

It can be seen from the foregoing that there is provided a device specific, mobile payments application that provides a highly secure method of payment for online purchases through four factor authentication (4FA) of the purchaser by means of a two stage verification process that (1 ) validates the identity of the purchaser and (2) validates the identity of the payer (the individual whose card is debited) in one seamless application with each stage of verification having two factor authentication (2FA).

Stage one of the four factor authentication comprises the "Purchaser Verification Stage" whereby the online seller validates the identity of the purchaser through a) the use of a Transaction Payment Request (TPR) being sent to the mobile payments application on the mobile device (1^st Factor Authentication - something the purchaser has) requiring b) the purchaser to authorise the purchase by logging into the mobile payments application using a 4 digit Personal Identification Number (PIN) to instigate the payment (2^nd Factor Authentication - something the purchaser knows). Stage two of the four factor authentication comprises the "Payment Authorisation Stage" whereby the Payment Service Provider (PSP) validates the purchaser as the payer through (c) the use of an independently communicated action command being sent directly from PSP to the mobile payments application on the mobile device (3^rd Factor Authentication - something the purchaser has) requiring (d) the purchaser to authorise the payment for the purchase by completing the action command on the mobile payments application (4^th Factor Authentication - something the purchaser does). Referring now to Figure 3 of the drawings, there is shown a diagrammatic representation of an alternative method and system according to the present invention. It is envisaged that the verification steps and payment processing steps may be carried out by separate entities. For example, it is conceivable that a first party will be involved in the verification of a payment and the actual payment processing will be carried out by a second party. In such circumstances, the first party will also carry out the authorisation steps previously described as being handled by the PSP server 1 1.

In the embodiment shown in Figure 3, there is shown (diagrammatically), a mobile terminal 3, a merchant terminal 5, a first verification (authentication) server 9, a second verification (authentication) server 21 and a payment service provider (PSP) server 23. A communication network (not shown) permits communications between the individual components. In the embodiment shown, the first verification server 9 and the second verification server 21 are operated by a first party and the PSP server 23 is a payment processing server operated by a second party in partnership with the first party.

In use, once a MCD user has selected the PAYDAP option and entered their MCD 3 mobile telephone number into the PAYDAP payment option API on the Merchant Server's checkout page, the merchant server 5 transmits the MCD phone number, the Merchant ID and the Value of the transaction to the first verification server 9 in step 1000. In this way, the transaction is registered on the first verification server. In step 1 100, the first verification server 9 sends a Transaction ID packet push notification to the device ID of the phone registered under that phone number. The Transaction ID packet includes the Merchant ID and the transaction value. In step 1200, the MCD user responds to the notification launching the app, entering their PIN and tapping OK. This sends the Transaction ID back to the first verification server 9. At this stage, stage 1 of the verification process is complete.

Once the transaction ID has been returned to the verification server 9 with a valid PIN, the first verification server 9 sends the Transaction ID packet including a Merchant ID, an MCD user ID and a transaction value to the second verification server 21 in step 1300. In step 1400, the second verification server 21 having received the Transaction ID packet, creates a random one-time transaction code (OTC) for this transaction and sends it as the secure payment transaction action command (i.e. the "confirm" command) to the app on the MCD 3. The second verification server 21 has stored the device ID corresponding to the MCD user ID from registration so it knows the appropriate MCD 3 to send the action command to. After receipt of the secure payment transaction action command, in step 1500, the MCD user then 'confirms' the transaction and the OTC is returned to the second verification server 21. At this point, stage 2 of the verification is complete. It will be understood that the payment processing has not yet begun.

In step 1600, once the verification steps have been completed, the second verification server 21 sends the transaction ID packet containing the Merchant ID, the user ID and the transaction value to the PSP server 23 to make the payment. In step 1700, the PSP server 23 confirms the payment or failure of the payment to the second verification server 21 . The second verification server then sends confirmation or failure of the payment to the first verification server 9 in step 1800 and the first verification server 9 sends confirmation or failure of the payment to the merchant in step 1900 and to the app on the MCD in step 2000.

It can be seen from the foregoing description of Figure 3, that the verification steps and the payment processing steps are performed independently. This will allow for another degree of security to be introduced into the system and method and will also allow for the verification provider to be largely autonomous from the payment processor. This is achieved by effectively taking the authorization/verification steps performed by the PSP server 1 1 in the previous embodiment described in relation to Figures 1 and 2 and having those authorization steps performed by a second verification server 21. It is important that this second verification/authentication server 21 is separate to the first verification/authentication server 9 to maintain a high level of security against potential man-in-the-middle attacks.

The second verification server 21 and the PSP server 23 are enclosed by a dashed box indicated by the reference numeral 1 1 , which signifies that the combination of the second verification server 21 and the PSP server 23 are effectively equivalent to the PSP server 1 1 of Figures 1 and 2. Furthermore, dashed line A in Figure 3 indicates that if there was a single PSP server 1 1 carrying out authentication as described in the embodiments shown in Figures 1 and 2, the communications passing over the dashed line A would be either simply to or from the unitary PSP server 1 1 rather than one of the second verification server 21 and the PSP server 23.

It will be appreciated from the foregoing that the present invention has numerous benefits, many of which are technical in nature and that address technical problems inherent in the existing solutions. For example, the present invention reduces consumer time required to execute a transaction and therefore saves MCD device processing, memory and battery resources. Furthermore, the present invention eliminates the need for the consumer to enter or transmit payment card data with each purchase reducing the possibility of the data being compromised but also reducing the time required to execute a transaction. In addition to this, the use of two separate servers in the authentication of a consumer in the manner described will reduce the risk of a man in the middle attack mimicking a user response for a mobile device. There are numerous other advantages to the present invention. For example, it is possible to store Card Data in one secure location on a third party server. In this way, data will not have to be stored on the phone or with the merchant, thereby reducing the risk of unauthorized access to the card details. Secondly, the present invention eliminates the need for the merchant to transmit or store payment card data reducing the cost of PCI DSS compliance. Third, the method simplifies the consumer's payment experience while increasing the verification of the consumer and reducing the potential for card-not-present fraud. Fourth, by implementing the invention the permission of the purchaser and the payer is obtained while still making the payment in a few simple moves. Fifth, the present invention enables a consumer to purchase goods on a phone, a tablet, a laptop, or a PC, but allows them to execute the transaction on the phone. This provides strong authentication and a secure method. Sixth, the present invention effectively makes a card not present transaction as secure as a card present transaction by the introduction of something the consumer has and something the consumer knows to the online transaction. Finally, by inputting authentication details e.g. PIN on an in- phone app rather than on a merchant or a card issuer remotely hosted form reduces the likelihood of phishing fraud.

It will be understood that various modifications could be made to the foregoing examples without departing from the spirit of the invention or the scope of the appended claims. For example, the unique contact identifier has been described as a mobile phone number however it is envisaged that another identifier could be used in its place. Indeed, the unique contact identifier could be a URL or other identifier for the MCD. The seller does not necessarily have to own the website and by seller's webserver, it will be understood that this is simply implying the webserver on which the seller's e-Commerce website is hosted and does not mean that the seller must own the webserver.

Throughout the specification, reference is made to an e-Commerce website and a transaction with an e-Commerce website. However, it will be understood that the present invention could be implemented with a multitude of web-enabled devices. For example, the present invention could be used to good effect with, inter alia, vending machines such as ticket kiosks, drinks dispensers, payment terminals, and the like, as many of these devices will be linked to the internet with interactive screens thereby allowing the customer to select a payment method as if on an e-commerce website.

It is further envisaged that the transaction payment request could be raised on another MCD where the user of that MCD has an appropriate "account" into which to receive a payment enabling tradesmen, servicemen and the like to accept payments through their MCDs from payers not present or without the need to have card readers. It is apparent that the present invention could be used to good effect making payments to these providers. For example, a user of the app who has a merchant account can send a payment request to another user. The payment request will appear on the payer's phone, and the authentication process is handled in the same manner as for the e- commerce transaction. This means that the "tradesman" or "professional" with a merchant account can request the payment from his customer not present if they are also users of the app. It is envisaged that all of the MCD users may have a current account recognized by the system provided by the PSP or other appropriate provider, which will mean that all users would then be able to receive payments. This means that all users of the method can request a payment from another user present or not present, if they are also users of the app, by simply sending a payment request. For users who are not users of the app and from whom a user wants to receive payment, a push notification prompting them to "pay with PAYDAP, download PAYDAP now" can be sent with the payment request. For payer present, the payee can raise a QR-code (or like code) on his/her MCD and the payer can simply scan it with their MCD to make the payment. Scanning the QR-code with the payer's MCD causes a payment request to be raised on the payer's app and the payment process will proceed as before.

Accordingly, throughout this specification, when reference is made to an e-Commerce website, it is deemed to also include vending machines such as ticket kiosks, drinks dispensers, payment terminals, other MCDs that can be used to raise a payment request and the like and will be so interpreted.

Furthermore, reference is made throughout the specification to payment card details being made available to facilitate the payment. It will be understood that instead of credit or debit card details, the PSP server could use bank details to charge the bank account of the payer rather than charge a card. Furthermore, an electronic currency account such as a Bit-Coin ® account could be used if desired. Therefore, when a reference is made to the card details or charging a card or variants thereof, this will be understood to also include bank account details or charging a bank account or an electronic currency account details or charging that electronic currency account. It is envisaged that the details of more than one credit card and/or debit card can be provided and there will be the facility and option for an MCD user to select the card or account that they wish to pay with.

It will be understood that the method according to the present invention will be performed largely in software and therefore the present invention extends also to computer programs, on or in a carrier, comprising program instructions for causing a computer or a payment terminal to carry out steps of the method. The computer program may be in source code format, object code format or a format intermediate source code and object code. The computer program may be stored on or in a carrier, in other words a computer program product, including any computer readable medium, including but not limited to a floppy disc, a CD, a DVD, a memory stick, a tape, a RAM, a ROM, a PROM, an EPROM or a hardware circuit. The computer program product may be stored in the memory of a computing device and the present invention is intended to extend to computing devices programmed to implement the method according to the present invention. It will be further understood that the present invention may be performed on two, three or more machines or components with certain parts of the computer-implemented method being performed by one machine or component and other parts of the computer- implemented method being performed by another machine or component. The devices may be part of a LAN, WLAN or could be connected together over a communications network including but not limited to the internet. One or more of the method steps could be performed "in the cloud", meaning that remotely located processing power may be utilised to process certain method steps of the present invention. Accordingly, it will be understood that many of the method steps may be performed remotely, by which it is meant that the method steps could be performed either on a separate machine in the same locality or jurisdiction or indeed on a separate machine or machines in one or several remote jurisdictions. For example, the independent authentication webserver 9 and the PSP server 1 1 may be in one jurisdiction or located in different jurisdictions. The present invention and claims are intended to also cover those instances where the method is performed across two or more machines or pieces of apparatus located in one or more jurisdictions and those situations where the parts of the system are spread out over one or more jurisdictions.

In this specification the terms "include, includes, included and including" and the terms "comprise, comprises, comprised and comprising" are all deemed totally interchangeable and should be afforded the widest possible interpretation.

The invention is in no way limited to the embodiment hereinbefore described but may be varied in both construction and detail within the scope of the appended claims.

Claims

Claims:

(1 ) A method of processing a secure payment transaction in a system (1 ) comprising a purchaser's mobile computing device (MCD) (3) having a mobile payments application loaded thereon, a seller's webserver (5) hosting an e-commerce website, an independent authentication webserver (9) and an independent payment service provider (PSP) server (1 1 ), the method comprising the steps of:

(i) the MCD operator selecting a secure payment transaction option on the e- commerce website checkout page;

(ii) launching an authentication webserver payment transaction page from the e-commerce website checkout page;

(iii) the MCD operator entering a unique contact identifier specific to their MCD into the authentication webserver payment transaction page and submitting the completed authentication webserver payment transaction page to the authentication webserver;

(iv) the authentication webserver (9), upon receiving the completed authentication webserver payment transaction page, sending a transaction payment request (TPR) to the MCD (3) identified by the unique contact identifier;

(v) the MCD operator, upon receiving the TPR on their MCD, fulfilling the TPR on their MCD, and the MCD (3) sending a TPR fulfillment response to the authentication webserver (9);

(vi) the authentication webserver (9), on receiving a TPR fulfillment response from the MCD, instructing the PSP server (11 ) to proceed with the secure payment transaction;

(vii) the PSP server (11 ), on receiving the instruction to proceed with the secure payment transaction from the authentication server, transmitting a secure payment transaction action command to the MCD (3); (viii) the MCD operator, upon receiving the secure payment transaction action command, fulfilling the secure payment transaction action command on their MCD, and the MCD (3) sending a secure payment transaction action command fulfillment response to the PSP server; and

(ix) the PSP server (1 1 ), upon receiving the secure payment transaction action command fulfillment response, processing the payment with the e- commerce website.

A method of processing a secure payment transaction as claimed in claim 1 in which the MCD operator uses their MCD (3) to select a secure payment transaction option on the e-commerce website checkout page.

A method of processing a secure payment transaction as claimed in claim 1 or 2 in which the steps of: (i) the MCD operator selecting a secure payment transaction option on the e-commerce website checkout page and (ii) launching an authentication webserver (9) payment transaction page from the e-commerce website checkout page are performed automatically in response to the MCD operator selecting a purchase option on the e-commerce website.

A method of processing a secure payment transaction as claimed in any preceding claim in which the step of the MCD operator fulfilling the TPR on their MCD comprises the MCD operator logging in to the mobile payments application.

A method of processing a secure payment transaction as claimed in claim 4 in which the MCD operator logs in to the mobile payments application by entering a private identification number (PIN) into the mobile payments application.

A method of processing a secure payment transaction as claimed in any preceding claim in which if the authentication webserver (9) has not received a TPR fulfillment response from the MCD (3) within a first predetermined period of time, the transaction is cancelled. A method of processing a secure payment transaction as claimed in any preceding claim in which if the PSP server (11 ) has not received a secure payment transaction action command fulfillment response within a second predetermined period of time, the transaction is cancelled.

A method of processing a secure payment transaction as claimed in any preceding claim in which the TPR is transmitted as a push notification to the mobile payments application.

A method of processing a secure payment transaction as claimed in any preceding claim in which the secure payment transaction action command is transmitted as a notification to the mobile payments application.

A method of processing a secure payment transaction as claimed in any preceding claim in which the method comprises the preliminary steps of the MCD operator registering their MCD with the independent authorization webserver (9) and providing their payment card information to the PSP server (1 1 ).

A method of processing a secure payment transaction as claimed in any preceding claim in which, upon completion of the secure payment transaction, the PSP server (1 1 ) transmits a payment completed message to the purchaser MCD.

A method of processing a secure payment transaction as claimed in any preceding claim in which the unique contact identifier is a cellular telephone number.

(13) A method of processing a secure payment transaction as claimed in any preceding claim in which the MCD (3) is a smartphone. (14) A computer program product having program instructions thereon that when loaded on a computer cause the computer to carry out one or more of the method steps of any of claims 1 to 13. A method of processing a secure payment transaction by a purchaser's mobile computing device (MCD) (3) in a system comprising a purchaser's MCD having a mobile payments application loaded thereon, a remote seller's webserver (5) hosting an e-commerce website, a remote independent authentication webserver (9) and a remote independent payment service provider (PSP) server (1 1 ), the method comprising the steps of:

(iii) the MCD operator entering a unique contact identifier specific to their MCD into an authentication webserver payment transaction page and submitting the completed authentication webserver payment transaction page to the remote authentication webserver;

(v) the MCD operator, receiving a transaction payment request (TPR) from the remote authentication webserver (9) on their MCD, the MCD operator fulfilling the TPR on their MCD and sending a TPR fulfillment response to the remote authentication webserver;

(viii) the MCD operator, receiving a secure payment transaction action command from the remote PSP server (1 1 ) on their MCD, the MCD operator fulfilling the secure payment transaction action command on their MCD and sending a secure payment transaction action command fulfillment response to the PSP server (1 1 ).

A method of processing a secure payment transaction as claimed in claim 15 in which the step of the MCD operator fulfilling the TPR on their MCD comprises the MCD operator logging in to the mobile payments application.

A method of processing a secure payment transaction as claimed in claim 16 in which the MCD operator logs in to the mobile payments application by entering a private identification number (PIN) into the mobile payments application. A method of processing a secure payment transaction as claimed in claims 15 to

17 in which the method comprises the preliminary steps of the MCD operator registering their MCD (3) with the independent authorization webserver (9) and providing their payment card information to the PSP server.

A method of processing a secure payment transaction as claimed in claims 15 to

18 in which the unique contact identifier is a cellular telephone number.

A computer program product having program instructions thereon that when loaded on an MCD, causes the MCD to carry out the steps of Claims 15 to 19.

A method of processing a secure payment transaction by an independent authentication webserver (9), in a system comprising a remote purchaser's mobile computing device (MCD) (3) having a mobile payments application loaded thereon, a remote seller's webserver (5) hosting an e-commerce website, the independent authentication webserver and a remote independent payment service provider (PSP) server (11 ), the method comprising the steps of:

(x) the authentication webserver (9) receiving a completed authentication webserver payment transaction page including a unique contact identifier specific to the MCD;

(iv) the authentication webserver (9), upon receiving the completed authentication webserver payment transaction page, sending a transaction payment request (TPR) to the MCD identified by the unique contact identifier;

(vi) the authentication webserver (9), on receiving a TPR fulfillment response from the MCD (3), instructing the e-commerce website and the PSP server (1 1 ) to proceed with the secure payment transaction.

(22) A method of processing a secure payment transaction as claimed in claim 21 in which the authentication server (9) sends the transaction payment request (TPR) to the MCD identified by the unique contact identifier in a push notification to the mobile payments application on the MCD (3).

A method of processing a secure payment transaction as claimed in claims 21 or 22 in which if the authentication webserver (9) has not received a TPR fulfillment response from the MCD (3) within a first predetermined period of time, the transaction is cancelled.

A computer program product having program instructions thereon that when loaded on a computer cause the computer to carry out the method of any of claims 21 to 23.

A method of processing a secure payment transaction by an independent payment service provider (PSP) server (11 ), in a system comprising a remote purchaser's mobile computing device (MCD) (3) having a mobile payments application loaded thereon, a remote seller's webserver (5) hosting an e- commerce website, a remote independent authentication webserver (9) and the independent PSP server (1 1 ), the method comprising the steps of:

(xi) the PSP server (1 1 ) receiving from the authentication webserver an instruction to proceed with a secure payment transaction;

(vii) the PSP server (11 ), on receiving the instruction to proceed with the secure payment transaction from the authentication server, transmitting a secure payment transaction action command to the remote MCD;

(xi) then PSP server (1 1 ) receiving from the MCD (3) a secure payment transaction action command fulfillment response; and

(ix) the PSP server (1 1 ), upon receiving the secure payment transaction action command fulfillment response, processing the payment with the e- commerce website. A method of processing a secure payment transaction as claimed in claim 25 in which the PSP server (1 1 ) sends the secure payment transaction action command to the remote MCD (3) in a push notification to the mobile payments application on the MCD.

A method of processing a secure payment transaction as claimed claims 25 or 26 in which if the PSP server (1 1 ) has not received a secure payment transaction action command fulfillment response within a second predetermined period of time, the transaction is cancelled.

A computer program product having program instructions thereon that when loaded on a computer cause the computer to carry out the method of any of claims 25 to 27.

A system (1 ) for processing a secure payment transaction with a seller's e- commerce website (5), the system comprising: a purchaser's mobile computing device (MCD) (3), an independent authentication webserver (9), and an independent payment service provider (PSP) server (1 1 ); and in which:- the MCD (3) has a mobile payments application loaded thereon for communication with the authentication webserver; the independent authentication webserver (9) comprises a first communications module to communicate with the mobile payments application on the MCD (3) and a second communications module to communicate with the PSP server (1 1 ); and the independent PSP server (1 1 ) having a first communications module to communicate with the mobile payments application on the MCD (3), a second communications module to communicate with the independent authentication webserver (9) and a third communications module to communicate with the seller's e-commerce website (5).

A system (1 ) as claimed in claim 29 in which the independent authentication webserver comprises a database having a plurality of MCD operator mobile payment application account records thereon, the mobile payment application account records each including an MCD unique contact identifier and an MCD operator's personal identification number (PIN). (31 ) A system (1 ) as claimed in claim 30 in which the independent authentication webserver comprises a pair of webservers, each having a database having a portion of each of the MCD operator mobile payment application account records thereon. (32) A system (1 ) as claimed in claim 31 in which the MCD unique contact identifier is stored on the database of one of the pair of webservers and the MCD operator's PIN is stored on the other database of the other of the pair of webservers.

A system (1 ) as claimed in claims 29 to 32 inclusive in which the independent PSP server (1 1 ) comprises a database having a plurality of MCD operator mobile payment application payment records thereon, the mobile payment application payment records each including payment card details for the MCD operator.

A system (1 ) as claimed in claims 29 to 33 in which the independent authentication webserver and the independent PSP server (11 ) communicate with each other through an Application Programming Interface (API).

(35) A system as claimed in claims 29 to 34 in which the MCD (3) is a smartphone.