The invention relates to a terminal and a method of authentication.

BACKGROUND

Existing methods of payment rely on the use of account information. Credit card payments rely on the use of credit card numbers and credit card verification codes. Electronic payment solutions rely on the reading of a bank account number from a magnetic card issued by a bank, as well as the entering of a secret Personal Identification Number (PIN) code.

In these methods of payment however, the account information may be easily seen and thus stolen by a third party e.g. a sales assistant or a bystander; credit card numbers and verification codes are visibly printed onto credit cards. In the case of electronic payment solutions, the magnetic cards are vulnerable to card skimming and the PIN codes may be seen and/or recorded by the third party. Accordingly, these methods of payment are vulnerable to information theft. SUMMARY OF THE INVENTION

In general terms the invention relates to a method that automatically extracts an encoded identity code from a screen of a mobile device, the encoded identity code being useable for authorizing a transaction and/or performing identity authentication. The identity code is encoded and it may not be possible for third parties to copy and/or extract the information within the encoded identity code. This may thus prevent a subsequent unauthorized use by a third party.

In a first specific expression of the invention there is provided a method of authentication as claimed in claim 1. This may have the advantage of allowing for secure authentication that is less vulnerable to spoofing or data eavesdropping. Spoofing occurs when a thief masquerades as an authority e.g. a bank in order to steal payment information. In a second specific expression of the invention there is provided a payment terminal according to claim 15. This may have the advantage of a payment terminal that is capable of securely requesting for payment information from a user, whilst also being capable of reading an encoded response containing the payment information.

A method and/or payment terminal according to one or more of the embodiments may have one or more advantages including:

- being more secure as information is stored as an encrypted picture;

- being more secure as information transmitted between terminals, devices and servers are encoded and encrypted;

- permitting multiple levels of encoding and encryption;

- being capable of using personal mobile devices to store sensitive payment information;

- allowing for a speedy authentication of payment information; - being highly flexible and easily reconfigurable to suit different modes of payment e.g. different credit cards;

- allowing for a secure way of requesting for payment information; and/or

- allowing for payment information to be transmitted from a mobile device in a secure manner.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more example embodiments of the invention will now be described, with reference to the following figures, in which:

Figure 1 is a schematic drawing of a system for transaction payment according to an example embodiment comprising a mobile device, a payment terminal and a server;

Figure 2a is a schematic drawing of an outer view of the mobile device of Figure 1 ;

Figure 2b is a schematic drawing of an inner view of the mobile device of Figure 1 ;

Figure 3 is a schematic drawing of the payment terminal of Figure 1 ;

Figure 4 is a flow chart of a method of payment in the system of Figure 1 ; and

Figure 5 is a schematic drawing of a system for security access control according to another example embodiment, comprising a first security terminal and a second security terminal, and the mobile device and server of Figure . DETAILED DESCRIPTION

Payment system 100

A system 100 for transaction payment according to an example embodiment is now described with the aid of Figures 1 , 2a, 2b and 3. Figure 1 shows a schematic drawing of the system 100. The system 100 comprises a mobile device 200, a payment terminal 300 and a server 120. Figures 2a and 2b then respectively show schematic drawings of an outer view and an inner view of the mobile device 200 of Figure 1 , while Figure 3 shows a schematic drawing of the payment terminal 300 of Figure 1.

Mobile device 200

Referring primarily to Figures 2a and 2b, the mobile device 200 is described. The mobile device 200 comprises a touch screen 210 and may be any touch screen enabled device; it may for example be a smart phone, a tablet device, a mobile Internet device (MID), or an IPhone™ device. As shown in Figure 2b, the mobile device 200 includes a processor 220 and a storage device 230. The processor is configured to execute a payment application 232 that is stored in the storage device 230. The payment application 232 is an application that is associated with a mode of payment, e.g. a credit card or a bank that is installed onto the mobile device 200.

Optionally, the payment application 232 may be password protected such that the entry of a password is required to execute the payment application 232. This may allow for greater security and may avoid unauthorized monetary transactions. Additionally, upon execution of the payment application 232, the application may ask for transaction parameters e.g. the amount of a monetary transaction, an account number, a credit card number, a checksum, and/or a public key for encryption. Alternatively, these communication parameters may be pre-configured and read off the data storage 230.

When performing a payment for a transaction, the payment application 232 is configured to receive an encoded request from the touch screen 210. The coded request is then decoded and verified by the application 232 in the processor 220. Should the decoded request pass verification, the payment application 232 will proceed to display a response image 212 on the touch screen 210. Alternatively, should the decoded request fail verification, the payment application 232 will ignore the request and await another coded request.

The response image 212 that is displayed on the touch screen 2 0 is encoded to contain identification information 234 identifying the payee (i.e. the payment account from which money is to be debited). This identification information 234 may for example include an account identity (e.g. an account number), a checksum, or a public key. The identification information 234 is read from the storage device 230 of the mobile device 200.

While displaying the response image 212, the payment application 232 awaits an acknowledgement or feedback in the form of another sequence of touches from the stylus array 310 on the touch screen 210 i.e. the "acknowledgement" sequence. When the "acknowledgement" sequence is received on the touch screen 210, the payment application 232 discontinues the display of the response image 212.

Payment terminal 300

Reference is made primarily to Figure 3. The payment terminal 300 comprises a processor 330, a camera 320 and the stylus array 310 mentioned earlier. The payment terminal 300 is configured to carry out "two-way communications" 140 with the mobile device 200; "downstream" information is transmitted from the payment terminal 300 to the mobile device 200, and "upstream" information is transmitted from the mobile device 200 to the payment terminal 300. An example of "downstream" information is the encoded request from the payment terminal 300 taking the form of a sequence of touches made by the stylus array 310 on the touch screen 210. An example of "upstream" information is the encoded response image 212 that is displayed on the touch screen 210. The displayed response image 212 is captured by the camera 320 to produce a picture 325 of the displayed response image 212. Note that since information is transmitted to and from the payment terminal 300 to the mobile device 200, the communication between them is thus bi-directional and described as "two-way". The communication channel for each direction does not have to be of the same type or symmetrical, and it is envisaged that the channels of the "two-way communications" may optionally instead include a wired communications link, or a wireless radio link.

The processor 330 is configured to run a terminal software. The terminal software first receives an external signal indicating the carrying out of a transaction. This external signal may for example be generated and sent to the processor 330 when the touch screen 210 of the mobile device 200 is placed on the stylus array 310, and in the field of view of the camera 320.

The terminal software then generates a request instruction to the stylus array 310. When the request instruction is received at the stylus array 310, the stylus array 310 executes the sequence of touches on the touch screen 210 of the mobile device 200. The sequence of touches thus encodes a request that is transmitted to the touch screen 210. The stylus array 310 comprises a plurality of styluses arranged with their respective touching points facing outwardly. Each of these stylus points may be moved to touch a touch screen positioned on the stylus array 310, and thus register a touch on a touch screen. The touching points of the styluses are capable of registering a touch on any type of touch screen e.g. a resistive or a capacitive touch screen.

The camera 320 is then configured to monitor the display of the touch screen 210. Should the touch screen 210 display an encoded response image 212, the camera 320 then takes a picture 325 of the image 212 and transmits the picture 325 to the processor 330 for processing by the terminal software.

Upon receiving the picture 325 at the processor 330, the terminal software decodes the picture 325 on the processor 330. If encryption is applied to the information during encoding, the decoded information is then decrypted. The resultant information after decoding and decryption is a decoded version of the identification information 234 that is encoded into the image 212.

The decoded identification information is transmitted from the payment terminal 300 to a server 120 for authentication. The payment terminal 300 further comprises a transceiver 340, and the decoded identification information is transmitted via the transceiver 340 to the server 120 over the network connection 130. The network connection 130 may be a wired or wireless connection and may for example be a telephone line to the server 120. It is envisaged that the network connection 30 be a secure connection and the traffic transmitted within the network connection 130 may thus be further encrypted by network appliances within and at both ends of the network connection 30.

The processor 330 receives the results of the authentication from the transceiver 340. The terminal software processes the results and if authentication is deemed to be a failure, the payment terminal 300. displays a negative visual indication, e.g. an LED light indicating that payment is not successful, or a monitor display text indicating that payment is not successful. If authentication is deemed to be a success, the terminal software generates an acknowledgement instruction to the stylus array 310. Upon receiving the acknowledgement instruction, the stylus array 310 executes another sequence of touches on the touch screen 210 of the mobile device 200 i.e. an "acknowledgement" sequence.

Server 120

Referring primarily to Figure 1 , the server 120 is now described. The server 120 comprises a database 122. The database 122 stores a copy of the corresponding identification information 234 for each of a plurality of mobile devices 200 that are enrolled to use the system 00. Additionally, the server 120 is connected to the payment terminal 300 via the network 130.

The server 120 receives a decoded copy of the identification information 234 for a mobile device 200. Authentication is performed on the decoded identification information by looking up the decoded identification information in the database 122. Should the decoded information be found in the database 122, authentication is deemed to be successful, and a message authorizing payment is transmitted over the network 130 from the server 120 to the transceiver 340 of the payment terminal 300. Additionally, the server 120 facilitates the payment by for example debiting the transaction amount from a bank account that is associated with the identification information.

Should the decoded information be not found in the database 122, authentication is unsuccessful and an authentication failure message is similarly transmitted over the network 130 from the server 120 to the transceiver 340 of the payment terminal 300. In other embodiments, it is envisaged that the server 120 may be located within the payment terminal 300. In such a case, the network 130 may be an internal network connection, or may be a computer bus connecting the server 20 as a peripheral to the payment terminal 300.

Method 400 of payment

An embodiment of a method 400 of payment in the system 100 of Figure 1 is described next with the aid of Figure 4. Figure 4 is a flow chart showing the method 400 of payment in the system 100. It is envisaged that this method be carried out in a retail scenario where the payment terminal 300 is located at a point-of-sale terminal for a retail store.

In 402, a payment transaction is initiated. A purchaser at the point-of-sale terminal of a retail store is shown a sum in which he is to pay. The purchaser thus executes the payment application 232 on his mobile phone 200. If necessary, the purchaser enters a password into the mobile phone 200 in order to permit the execution of the application 232. The purchaser then places (or "taps") the mobile device 200 on the payment terminal 300 adjacent to the stylus array 310 and camera 320 of the payment terminal 300. The method 400 then proceeds to step 410. In 410, an encoded request is provided to a touch screen 210 of a mobile device 200. The encoded request is provided to the touch screen 210 by the stylus array 310 of the payment terminal 300. In other words, the payment terminal 300 initiates the encoded request by using the stylus array 310 to provide a sequence of touches to the touch screen 210.

Each of the sequence of touches is performed at a respective time and on a respective position of the touch screen 210. Thus, the request is encoded within the sequence of touches using code representations such as for example, the time interval between the respective times of two consecutive touches, or the relative displacement between the respective positions of two consecutive touches. Optionally, the request may also be encoded by the relative position of a touch of the sequence from an origin of the touch screen 210 e.g. using the top-right hand corner of the touch screen 210 as a reference.

In 420, the encoded request is verified at the mobile device 200 to produce a verification result. The encoded request is decoded and verified by the payment application 232 in the processor 220. Should the decoded request pass verification, the payment application 232 will proceed to display a response image 212 on the touch screen 210.

The sequence of touches is decoded by converting it into a sequence of code representations e.g. a sequence of time intervals between consecutive touches. The sequence of code representations is then compared with a template and verification is a success if the sequence is similar to the template. In this case, the method proceeds to step 430. In 430, the mobile device 200 encodes a response image based on the verification result. The encoded response image contains identification information 234 identifying the purchaser (i.e. the payment account from which money is to be debited). This identification information 234 may for example include an account identity (e.g. an account number), a checksum, a credit card number or a public key. The identification information 234 is read from the storage device 230 of the mobile device 200.

In 440, the encoded response image is displayed on the touch screen 2 0 of the mobile device 200. The displayed response image 212 may for example be a barcode, a QR code, or a steganographic image. In the case where the response image 212 is a barcode or QR code, the identification information 234 may be encoded within the barcode or QR code respectively. In the case where the response image 212 is a steganographic image, the identification information 234 may be encoded within the image using steganography.

Additionally, in order to provide an additional level of data security, the identification information 234 that is encoded within the displayed response image 212 may be encrypted, e.g. using a tripleDES encryption. By doing so, even if the displayed response image 212 were to be captured by a third-party, the identification information 234 would be encrypted and thus may be inaccessible to the third-party.

In 450, a picture 325 of the displayed encoded image is captured by a camera 320 of the payment terminal 300. The captured picture 325 is then transmitted to the processor 330.

In 460, the picture 325 of the displayed image is decoded in the processor 330 to identify the mobile device 200. If encryption is applied to the information during encoding, the decoded information is further decrypted. The resultant information after decoding and decryption is a decoded version of the identification information 234 that is encoded into the image 212.

In 470, the decoded identification information is transmitted to a server 120 and is received at the server 120.

In 480, the received decoded identification information is authenticated. Authentication is performed on the received identification information by looking up the identification information in the database 122. Should the identification information be found in the database 122, authentication is deemed to be successful and a payment authorization is generated.

In 490, the payment authorization is transmitted from the server 120 to the payment terminal 300. In 492, the payment terminal 300 provides an acknowledgement of the payment authorization to the mobile device 200. The stylus array 310 thus executes another sequence of touches on the touch screen 210 i.e. an "acknowledgement" sequence. The "acknowledgement" sequence once again may be encoded as is done for the sequence of touches of step 410. The "acknowledgement" sequence thus confirms the conclusion of the transaction to the mobile device 200. Additionally, the payment terminal 300 prints a paper receipt that is given to the purchaser. It is also envisaged that the mobile device 200 may store the details of the transaction as identification information 234 in the storage device 230 of the mobile phone 200. These payment details may then be reused in future transactions.

Security system 500

In an alternative embodiment, a system 500 for security access control is envisaged. Figure 5 is a schematic drawing showing the system 500 for security access control. Parts of the system 500 which are identical to those of the system 100 of Figure 1 , or those of the payment terminal 300 of Figure 3, are referred to using like reference numerals.

The system 500 differs from the system 100 in having two security terminals 5 0a and 510b in place of the payment terminal 300. The parts of the security terminals 510a and 510b are similar to each other, as well as similar to that for the payment terminal 300 except for a control port 530. Both the security terminals 510a and 510b are capable of having "two-way communications" 140 with the mobile device 200. Additionally, the security terminals 510a and 510b are connected to the server 120 by the network 130. It is envisaged that the first security terminal 510a may be located in an access enrolment point e.g. at the front desk check-in station of a hotel, while the second security terminal 510b may be built into the doors of a secure area, e.g. a hotel room. The control port 530 of the second security terminal 510b is connected to a security mechanism 540. The security mechanism 540 may for example be an electric lock, or may be an electric gate. It is envisaged that such a system 500 may permit cost savings by reducing or eliminating the need for issuing card keys to the user.

The mobile device 200 is first enrolled into the system 500 using the first security terminal 510a. The owner of the mobile device 200 executes a security application (not shown) on the mobile device 200. The owner places (or "taps") the mobile device 200 on the first security terminal 510a adjacent to the stylus array 310 and camera 320 of the first security terminal 5 0a. The first security terminal 510 then uses the stylus array 310 to send an access code to the mobile device 200. This is sent as a sequence of touches on the touch screen 210 of the mobile device 200 similar to that done in step 410 of the method 400 for payment. Additionally, the first security terminal 510a transmits the access code to the server 120 for storage in the database 122. When the mobile device 200 is to be used for obtaining access, the owner of the mobile device 200 then places (or "taps") the mobile device 200 on the second security terminal 510b adjacent to the stylus array 310 and camera 320 of the second security terminal 510b. Another sequence of touches is placed on the touch screen 210 by the stylus array 310 of the second security device 510b. The mobile device 200 verifies the other sequence of touches received on the touch screen 210 and should the sequence of touches pass verification, the mobile device 200 displays an encoded response image 212 on the touch screen 210. The encoded response image 212 encodes the access code that is obtained from the first security terminal 510a.

The camera 320 of the second security terminal 510b then captures a picture 325 of the displayed response image 212. The captured picture 325 is decoded in the processor 330 of the second security terminal 510b to yield the decoded access code. The decoded access code is then transmitted to the server 120 for authentication. Should authentication of the access code be successful, the server 120 returns an access authorization to the security terminal 510. The security terminal 510 thus activates the security mechanism 540 to grant access to the user. This is done via the control port 530 of the security terminal 510.

It is envisaged that the encoded response image 212 that is displayed by the second security terminal 510b may additionally also encode information identifying the mobile device 200. This may allow the second security terminal 510b to additionally verify the identity of the mobile device 200 and thus implement an extra level of security check.

Whilst exemplary embodiments of the invention have been described in detail, many variations are possible within the scope of the invention as will be clear to a skilled reader.