WO2010140955A1

WO2010140955A1 - Selection of transaction functions based on user identity

Info

Publication number: WO2010140955A1
Application number: PCT/SE2010/050531
Authority: WO
Inventors: Stefan Hultberg; Magnus Westling
Original assignee: Accumulate Ab
Priority date: 2009-06-04
Filing date: 2010-05-17
Publication date: 2010-12-09
Also published as: SE533449C2; SE0950406A1; EP2438558A1; EP2438558A4; CN102449653A

Abstract

The present invention relates to methods, a device and a computer program product for a secure transaction utilizing a portable radio communication device (10), wherein possible transaction functions are only accessible for a user upon verification of transaction part verifying data.

Description

SELECTION OF TRANSACTION FUNCTIONS BASED ON USER IDENTITY

FIELD OF INVENTION

The present invention relates generally to transactions, and particularly to secure transactions utilizing a portable radio communication device, such as a mobile phone, personal digital assistant, portable computer or similar.

BACKGROUND

It is today common with transactions initiated and performed via e.g. Internet. Further, with mobile phones or similar devices it is today possible to perform transactions and related actions through data communication via wireless communication. This provides for a very neat way of performing secure transactions, by always having an electronic authentication device at hand, which could be used as a secure wallet/bank solution. However, this also provides for a variety of ways to manipulate the transaction systems in order to fraud one or both of the parts in a transaction.

SUMMARY OF THE INVENTION

An object of the present invention is thus to provide improved security in relation to transactions for portable radio communication devices.

This object, among others, is according to the present invention attained by methods a transaction server and a computer program product as defined by the appended claims.

The invention provides methods, a transaction server and a computer program product enabling secure transactions, where possible transaction functions are only accessible for a user upon verification of transaction part verifying data. In this way improved security in relation to transactions is obtained. This also allows a more dynamic and flexible provisioning of a variety of transaction functions to the user. Transaction function mixes can also be customized for different users.

According to one variation of the invention also transaction function presenting data specifying how the selected transaction functions are to be presented is provided to the transaction software upon verification, which allows a flexible presentation of available functions to a user.

By providing both parts in a transaction, connected to a predefined transaction server, where the transaction is linked to a transaction identity, and independently approving the transaction an even higher security is obtained.

The transaction identity may be kept unique only during a specific transaction, whereby the necessary amount of transaction identities can be kept very low at the transaction server, being limiting only for handling parallel transactions at the transaction server.

The unique transaction identity may be created by the transaction server upon request from the first transaction part, which provides for an assured solution for the first transaction part. Alternatively, the transaction identity may be created by the second transaction part, which facilitates the transaction for the first transaction part. Further, for e.g. Internet bank login a predefined transaction identity may be used.

Further features and advantages of the present invention will be evident from the following description. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more fully understood from the detailed description of embodiments given below and the accompanying figures, which are given by way of illustration only, and thus, are not limitative of the present invention, wherein:

Fig. 1 schematically shows communication between transaction parts according to an embodiment of the present invention,

Fig. 2 schematically shows method steps performed by an application provided by transaction software in a portable radio communication device for initiating a transaction session with a transaction server,

Fig. 3 schematically shows method steps performed by a transaction server when a transaction session is initiated by a user using the application provided by the transaction software in the portable radio communication device, and

Fig. 4 schematically shows method steps of a method for secure transactions according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

In the following description, for purpose of explanation and not limitation, specific details are set forth, such as particular techniques and applications in order to provide a thorough understanding of the present invention. However, it will be apparent for a person skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed description of well-known methods and apparatuses are omitted so as not to obscure the description of the present invention with unnecessary details.

An embodiment of the present invention will now first be described with reference to Figs. 1 2 and 3.

In order to secure all links of a transaction, transaction software 9 may be installed in a portable communication device 10 of a first transaction part or user in a secure way, wherein a user is identified in a secure way and tied to the installation. One secure way is to, at e.g. a bank office or other known part, install the transaction software in the portable radio communication device of the first transaction part or give a memory card or similar device having an installation program for the first transaction part thereon. The identity of the owner of the portable radio communication device is checked in connection with the installation or delivery of the transaction software. Instead of checking the identity directly at a bank office or other known part e.g. a registered letter sent to the intended user can be used to verify the identity of the intended user. Here it is also possible that the identity of the portable radio communication device is registered for later verification. Finally the transaction software is connected to an account at the bank or other part, such as a credit card account, a user account, an electronic wallet, etc. Another secure way to install the transaction software is to, at e.g. an authenticated Internet bank office or similar part, through a secure connection, e.g. a https connection, install the transaction software in the portable radio communication device of the first transaction part. The identity of the owner of the portable radio communication device is checked in connection with the installation through e.g. PIN, which makes up a user identifier. Finally the transaction software is connected to an account at the bank or other part, such as a credit card account, a user account, an electronic wallet, etc. The transaction software being installed typically also has a transaction software identifier.

The transaction software is arranged to communicate with a predefined transaction server 12 when secure transactions are to be performed. Information of which account a transaction software is connected to can be predefined directly at the transaction server or be accessed by the transaction server from the first transaction part whenever a transaction is to take place. Account balance and similar checks are preferably performed prior to any finalization of a transaction.

When a secure Internet installation is utilized a mobile phone number is preferably given to the distribution site, which in response thereto sends a text message, such as an SMS, with a download URL to that mobile phone number, i.e. a so called over the air installation (OTA installation) . By following that link in the mobile phone the transaction software is installed in the mobile phone. This phone number may also be used in later verifications. To first start the application run by the transaction software an activation code, given by the distribution site, may be entered. Further, a PIN is also required to be entered to run the application.

After such installing has been made it is then possible to perform transactions. According to the invention, when the application being provided by the transaction software 9 in the phone 10 is started, step 24, by a user, the user is first asked to enter a user identifier, which may with advantage be a PIN such as the above-descried PIN. The application thus receives the user identity. It is here possible that the transaction application is shut down in case no user identifier is received or is not provided within a pre-determined time.

After this has been done the application optionally fetches a transaction software identifier, i.e. a code identifying the specific copy of the transaction software. The user identifier and optionally transaction software identifier here make up transaction part verification data, i.e. data used to verify a presumptive transaction part, which part is normally the user. In this way the application obtains transaction part verification data, step 26.

The application then sends a request for a transaction session to the transaction server 10, step 28. This request is in this embodiment accompanied by the transaction part verification data, step 29, which may furthermore also include a portable radio communication device identifier. This is furthermore sent to the transactions server over an encrypted wireless connection.

When the transaction server receives this request, step 36, and transaction part verification data, step 37, it proceeds and verifies the transaction part verification data, step 38. This here normally involves comparing the received user identifier with a the user identifier previously stored for the user, comparing the transaction software identity with the identity of transaction software known to be installed on the portable radio communication device as well as a possible comparison of the portable radio communication device identifier with a previously registered identifier.

In case the comparison indicates that the transaction part verification data was correct, i.e. the transaction part in question is verified, the transaction server 12 selects transaction functions for the user, step 40. These may be a number of transaction functions, the mix of which is customized for the user. The functions may furthermore include new transaction functions that did not exist at an earlier transaction session. The transaction functions are here provided by the transaction server 12 and are furthermore provided by the transaction server through dedicated function interfaces 16, 18, 20 and 22. As an example there are here four transaction interfaces 16, 18, 20 and 22, each being provided through a corresponding API (Application Programming Interface). After the functions have been selected, links to the interfaces of the selected functions are sent to the portable radio communication device, step 42. Such links may be handles, pointers or for instance uniform resource locators (URL) . Here the transaction server may also send transaction function presenting data, step 44. Such transaction function presenting data may include instructions on how and where the functions are to be presented via the portable radio communication device, for instance via a display of this device. It is possible that the transaction application is already in possession of such transaction function presenting data, in which case there may be no need for the transmission of it. Also this data is with advantage transferred using an encrypted wireless connection.

The application in the portable radio communication device thus receives the links to the interfaces of the selected transaction functions, step 30, and perhaps also transaction function presenting data, step 32. Thereafter it presents the transaction functions via the portable radio communication device, step 34, so that the user can select transaction functions and perform transactions. This may typically be done through presenting a link to the function, through which the user is forwarded to the function on the transaction server. It may also involve presenting a function entry window and a function presenting window, where data entered in the function entry window is transmitted to the function on the transaction server using a received link and data collected from the transaction function via the link is presented in the function presenting window. Such data is also here sent via wireless encrypted communication. In this way there is provided a safe frame within which the user can perform various transactions as well as some other activities.

It should here be realized that as a variation of the above described embodiment, the application may first only send the request and provide the transaction part verification data in a later stage after having received a request for such data from the transaction server. In this case it is possible that the user is prompted to enter the user identifier after such a request for transaction part verification data has been received by the application.

The actual carrying out of one transaction will now be described with reference being made to fig 1 and 4.

When a transaction 13 is to take place, wherein the second transaction part is Internet based, such as an authenticated merchant secure Internet site 11 or a secure login, the transaction comprises the following steps. The user of the portable radio communication device, i.e. the first transaction part, selects a "transaction" function of the transaction software. As the user selects a function, selection data is sent to the interface of the transaction server defined through the associated link. The transaction server 12 thus receives selection data via the function interface. It then starts the corresponding transaction function for the user. In relation to this starting of the transaction function on the transaction server there is an activation of the first transaction part 10 on the transaction server 12, which activation is performed through encoded/encrypted wireless communication. Thereby the transaction server 12 puts the first transaction part 10 in an active transaction state on the transaction server 12. Activation may as an alternative be performed in relation to the verification of transaction part mentioned above.

The first transaction part 10 preferably stays in the active transaction state on the transaction server 12 until the first transaction part 10 requests a non-active transaction state. Alternatively, the first transaction part 10 will be put into a non-active transaction state by the transaction server 12 after a time-out. Further, the transaction server 12 could also put the first transaction part 10 in a non- active state after finalization of a transaction. By waiting for a request before putting the first transaction part into a non-active state the advantage is obtained that the user can perform several consecutive transactions without having to reselect the "transaction" section of the transaction software. This is however preferably combined with a time out, which gives the advantage that the user does not forget to put the portable radio communication device in a non- active transaction state, which would be risky if another person gets hold of the portable radio communication device. From a secure perspective it would be advantageous to put the first transaction part in a non-active transaction state also after a transaction have been completed.

The first transaction part thereafter initiates the transaction by requesting, through an encoded/encrypted wireless communication, a transaction identity of the transaction server. The wireless communication can e.g. be performed through GPRS, 3G data, Wi-Fi or WiMAC, all of which could have some kind of built-in identity verification, and even infrared or Bluetooth, which however are anonymous and could require some added identity verification. The transaction server responds by sending 14 a transaction identity to the first transaction part, which transaction identity is unique during the whole transaction but is preferably reusable after finalization of the transaction, advantageously directly after finalization of the transaction, i.e. when the transaction receipt has been sent.

The first transaction part enters 46 the returned transaction identity at the merchant secure Internet site 11, i.e. the second transaction part 11. The second transaction part 11 therefore connects to the transaction server 12, step 48. The second transaction part thereafter sends information of the transaction connected to the transaction identity to the transaction server 12, preferably encrypted. The connection and the following information of the transaction could be performed in one action. Transaction information from the second transaction part that is sent with a transaction can vary, but typically includes the name of the second transaction part and the transaction amount, and possibly also the product name, at a purchase. The name of the second transaction part could alternatively be extracted from the login of the second transaction part to the system instead of being sent together with the transaction, to ensure that such information is not distorted. This is usually performed via a landline communication, but could also be performed via wireless communication. The second transaction part has previously registered an account at the transaction server, in a way similarly performed for the first transaction part. Account information or similar information of the first transaction part is not necessary to give to the second transaction part and vice versa, since such information is known by the transaction server, and such information should thus not be given to the second transaction part and vice versa.

The transaction server 12 identifies the first transaction part by the unique transaction identity sent by the second transaction part and preferably requests 50, through an encoded/encrypted wireless communication, a verification by the first transaction part of the transaction information connected to the transaction identity. The application requests 52 e.g. a PIN as verification of the transaction information, such as name of the second transaction part and transaction amount. The verification is returned, through an encoded/encrypted wireless communication, to the transaction server connected to the transaction identity.

After verification from the first transaction part the transaction server finalizes 54 the transaction connected to the unique transaction identity and sends a transaction receipt to both the first transaction part, through an encoded/encrypted wireless communication, and the second transaction part. The transaction is only finalized provided that the accounts of both the first transaction part and the second transaction part accept the transaction. The connection between the transaction server and the first transaction part is thus different from the connection between the transaction server and the second transaction part. This means that the connection paths used are different. Communication between the first transaction part and the transaction server is here furthermore performed via the function interface of the transaction server. Also the second transaction part may here communicate with the transactions server via this interface.

The transaction has been described with a portable radio communication device as the first transaction part and a merchant as the second transaction part. The reverse is however also possible wherein the merchant requests a unique transaction identity of the transaction server, in this case preferably through a land line communication. The unique transaction identity is then communicated to the portable radio communication device from the merchant. However, information of the transaction connected to the unique transaction identity is again sent from merchant to the predefined transaction server, which, by wireless communication, sends the information of the transaction connected to the unique transaction identity to the portable radio communication device. The transaction connected to the unique transaction identity is still verified at the portable radio communication device by a user verification, which verification connected to the unique transaction identity is sent to the transaction server. The transaction connected to the unique transaction identity is thereafter finalized based on the information of the transaction and the unique transaction identity, and a transaction receipt of the finalized transaction is sent from the transaction server to the first and second transaction parts. Also in this reverse procedure the first transaction part has put itself in an active transaction state on the transaction server. Without the first transaction part in the active transaction state the transaction will not be finalized. A similar method can be used for e.g. Internet bank login, or other kinds of secure login or secure authentication. Instead of requesting a transaction identity from the transaction server a predefined identity is utilized, known by both the first transaction part and the transaction server, such as a social security number, account number or similar. The user of the first transaction part preferably enters this predefined identity at the second transaction part and thereby initiates the login at the second transaction part. Alternatively the first and second transaction parts are e.g. equipped with electronic communication means, providing the possibility for the first transaction part to enter the predefined identity at the second transaction part without the user needing to perform it manually. The user of the first transaction part also selects a "secure login" section of the transaction software to connect the portable radio communication device to the transaction server and thereby puts the first transaction part in an active transaction state on the transaction server.

After receiving the predefined identity at the second transaction part the second transaction part puts itself in an active transaction state on the transaction server and requests a verification connected to the login of the transaction server, based on the predefined identity. The transaction server checks that the portable radio communication device corresponding to the predefined identity is connected to the transaction server, at least by checking that the first transaction part is in an active transaction state on the transaction server. The transaction server preferably additionally requests a verification connected to the login from the first transaction part, or alternatively checks that the portable radio communication device of the first transaction part is on, which is performed without any active action by the user thereof.

The verification in the portable radio communication device is e.g. a PIN. The transaction server will when both transaction parts are in the active state, or after verification when used, send a verification to the second transaction part confirming that the portable radio communication device has been verified, which will allow log in of the first transaction part into the second transaction part. In this case no PIN or other password has been transferred via the Internet connection. Further, the PIN has not been transferred between the transaction server and the second transaction part. The second transaction part only receives a confirmation that the identification is verified. Transactions at the second transaction part can hereafter be performed as previously described.

Examples of different transaction are e.g. point of sales (POS) transaction, person to person (P2P) transfer, micro payments, person to machine (vending machine) transaction, secure identification, electronic identification, secure authentication, etc.

At such a transaction it is possible that the first transaction part, i.e. the user, purchases an item, like an object or a service, provided by a service provider. Such an item may for instance be a ticket, for instance in the form of an image, which may be stored by the transaction server. Such an item may then later be transferred to the application in the transaction software of the portable radio communication device as the user requests a transaction session by starting the application. This has the advantage of providing the item in the context of a safe frame following proper identification of the user. The item may also be stored in a third-party system and retrieved from there when the user needs to use the item. In order to verify that it actually is the user that fetches the item from this third-party system, the storing may be linked to a user identifier, like a pre-defined transaction identifier of the user or the transaction software identifier.

A few examples on transaction part verification data has been described above. Another example on this are private encryption keys provided in the transaction software. These may be private encryption keys and then soft or hard private encryption keys. This means that transaction part verifying data being verified are the encryption keys used by the transaction software. This verification may furthermore be performed through an encryption scheme where the transaction server uses the public keys of the transaction software, while the application uses the private keys.

The application in the transaction software may here, as one example, be required to encrypt data by the transaction server, which data may be a known string of text. The application then encrypts this string and sends it to the transaction server. The transaction server decrypts the data using public keys that it has stored as corresponding to the private keys of the transaction software. In case it manages to decrypt the string, the transaction server knows that the keys are correct.

In another example this may be done through the transaction server sending a public RSA key associated with the session to the application. The application then encrypts an identifier, for instance the transaction software identifier, using this public RSA key and sending the thus encrypted identifier to the transaction server. The transaction server then decrypts the identifier using the corresponding private RSA key and thereby identifies the transaction software. Based on this identifier it then locates the public RSA key of the transaction software, encrypts an AES (Advanced Encryption Standard) key using this public RSA key of the transaction software and sends the encrypted AES key to the application. If it is the right transaction software, the application is the only part that can decrypt the AES key using its private RSA key. In this way it is also possible to verify the encryption keys of the transaction software.

The transaction server may be realized through the use of one or more processors together with memory including computer program code carrying out the functionality of the device when being run by such a processor.

It will be obvious that the present invention may be varied in a plurality of ways. Such variations are not to be regarded as departure from the scope of the present invention as defined by the appended claims. All such variations as would be obvious for a person skilled in the art are intended to be included within the scope of the present invention as defined by the appended claims.

Claims

1. A method for enabling secure transactions between a user and a transaction server utilizing a portable radio communication device (10) comprising the steps of:

- receiving (36), in the transaction server, a request for a transaction session from a portable radio communication device;

- receiving (37), in the transaction server, transaction part verification data from said portable radio communication device;

- verifying (38) the transaction part verification data;

- selecting (40) a number of transaction functions accessible to said user based on the verification; and

- providing (42) the portable radio communication device with links to interfaces (16, 18, 20, 22) of the transaction server where the selected transaction functions are accessible.

2. A method according to claim 1, wherein communication between the transaction server and the portable radio communication device is performed using wireless encrypted communication .

3. A method according to claim 1 or 2 , further comprising the step of providing (44) the portable radio communication device with transaction function presenting data specifying how the selected transaction functions are to be presented via the portable radio communication device.

4. A method according to any previous claim further comprising the steps of, putting the portable radio communication device in an active transaction state as a first transaction part on said transaction server after having verified the transaction part verification data, thereby allowing a transaction (13) connected to a transaction identity to be initiated between said first transaction part utilizing transaction software in said portable radio communication device and a second transaction part (11) utilizing a service provider software;

- receiving an initiation of said second transaction part on said predefined transaction server (12), which second transaction part thereby is put in an active transaction state on said transaction server;

- receiving (15) information of said transaction connected to said transaction identity from said second transaction part to said predefined transaction server;

- identifying said first transaction part and said second transaction part on said transaction server by said transaction identity and checking that said first transaction part and said second transaction part are in said active transaction state on said transaction server;

- finalizing said transaction connected to said transaction identity based on said information of said transaction and said transaction identity; and

- sending (14, 15) a transaction receipt of the finalized transaction connected to said transaction identity from said transaction server to said first and second transaction parts.

5. The method according to claim 4, wherein said transaction identity is created by said transaction server upon request from said first transaction part and sent to said first transaction part.

6. The method according to claim 5, wherein said transaction identity is a unique transaction identity and reusable for another transaction after the transaction receipt has been sent.

7. The method according to claim 5, wherein said transaction identity is predefined and known by said transaction part and said first transaction part.

8. The method as claimed in any of claims 4-7, comprising the steps of:

- sending (14), by encrypted wireless communication, said information of said transaction connected to said transaction identity from said predefined transaction server to said first transaction part; and

- receiving a user verification (6) of said transaction connected to said transaction identity from said first transaction part .

9. The method according to claim 8, wherein said verification is performed by entering a personal identification number in said portable radio communication device.

10. A transaction server (12) for enabling secure transactions for a user that utilizes a portable radio communication device (10) and configured to

- receive a request for a transaction session from the portable radio communication device; - receive transaction part verification data from said portable radio communication device;

- verify the transaction part verification data;

- select a number of transaction functions accessible to said user based on the verification; and

- provide the portable radio communication device with links to interfaces (16, 18, 290, 22) of the transaction server where the selected transaction functions are accessible.

11. A transaction server according to claim 10, being further configured to provide the portable radio communication device with transaction function presenting data specifying how the selected transaction functions are to be presented vie the portable radio communication device.

12. A transaction server according to claim 10 or 11, being further configured to

- put the portable radio communication device in an active transaction state as a first transaction part after having verified the transaction part verifying data, thereby allowing a transaction (13) connected to a transaction identity to be initiated between said first transaction part utilizing transaction software in said portable radio communication device and a second transaction part (11) utilizing a service provider software;

- receive an initiation of said second transaction part, which second transaction part is thereby put in an active transaction state;

- receive (15) information of said transaction connected to said transaction identity from said second transaction part; identify said first transaction part and said second transaction part by said transaction identity and check that said first transaction part and said second transaction part are in said active transaction state on said transaction server;

- finalize said transaction connected to said transaction identity based on said information of said transaction and said transaction identity; and

send (14, 15) a transaction receipt of the finalized transaction connected to said transaction identity to said first and second transaction parts.

13. The transaction server according to claim 12, being further configured to create said transaction identity upon request from said first transaction part and send said transaction identity to said first transaction part.

14. The transaction server according to claim 12 or 13, being further configured to

send (14), by encrypted wireless communication, said information of said transaction connected to said transaction identity to said first transaction part; and

receive a user verification (6) of said transaction connected to said transaction identity from said first transaction part.

15. A method performed in a portable radio communication device (10) for enabling secure transactions between a user and a transaction server (12) comprising the steps of:

obtaining (26) transaction part verifying data; - sending (28) a request for a transaction session to the transaction server (12);

- submitting (29) said transaction part verifying data to the transaction server; and

- receiving (30) links to interfaces (16, 18, 20, 22) of the transaction server where a number of transaction functions selected by the transaction server are accessible.

16. A method according to claim 15, further comprising the step of receiving transaction function presenting data (32) specifying how the selected transaction functions are to be presented via the portable radio communication device.

17. A method according to claim 15 or 16, wherein the step of obtaining transaction part verifying data comprises receiving a user identifier from the user.

18. A method according to any of claims 15 — 17, wherein the step of obtaining transaction part verifying data comprises fetching a software identifier from transaction software in the portable radio communication device.

19. A computer program product for enabling secure transactions provided on a computer readable means and comprising computer program code configured to make a portable radio communication device (10) perform, when said computer program code is being run on the portable radio communication device:

- obtain transaction part verifying data;

- send a request for a transaction session to the transaction server (12); - submit said transaction part verifying data to the transaction server; and

- receive links to interfaces (16, 18, 20, 22) of the transaction server where a number of transaction functions selected by the transaction server are accessible.