BACKGROUND TO THE INVENTION

1. FIELD OF THE INVENTION

The present invention relates to a system and method for transmitting and receiving data over a network. Such a method and system can, for example, in one embodiment, be used to enable parties to undertake transactions. Examples of the nature of the transactions concerned include a retail transaction in which a purchaser makes a payment to a retailer.

2. DESCRIPTION OF RELATED ART

Currently, the conclusion of, say, a retail transaction involves many different data exchange operations between several different computing entities. Thus, for example, the customer must interact with a payment terminal to complete a 'challenge-response' authentication of their credentials. The payment terminal is operated by the retailer but the operation is undertaken on behalf of one or more intermediate parties who are, in effect, putting themselves forward as trusted intermediaries between the retailer and the retailer's bank. A consequence of this multi- noded data exchange is that data is continuously aggregated with other data along what can be thought of as a daisy chain of data processing steps. This is inefficient and costly.

GB2446706 describes a method of information exchange which can be used in the accessing of goods or services. A mobile device obtains an image of a visual symbol, e.g. by using its camera to photograph a two-dimensional barcode. The visual symbol is parsed into a code, and a network address of a first server that corresponds to the code is obtained. The address is modified to include an identification of the mobile device, such as the IMEI number, and a request preferably in the form of a URL is sent to the modified network address. The server receives the request and obtains account details such as a user name that correspond with the identification of the mobile device.

SUMMARY OF THE INVENTION

The present application discloses, inter alia, alternative methods of information transmission and retrieval. According to an embodiment of the present invention a one-time code is generated which is stored against a user's ID value by a trusted administrator; the one-time code is rendered into an indicium which the user is then able to offer to a counterparty in a transaction as a token; the counterparty, upon receiving confirmation of the authenticity of the token from the trusted administrator then, in reliance upon the trusted administrator's confirmation, completes the transaction with the user. In a further embodiment, the trusted administrator may settle the transaction by receiving details of the transaction, including the one-time code and some further data from the counterparty, using the one-time code to establish the identification of the user, and whether the user has authorised the trusted administrator to conclude the transaction on the user's behalf, and upon confirmation that the user has thus authorised the trusted administrator, sending a transaction data package to a third party which instructs the third party to perform a transaction settlement act. In one example the third party is the user's bank and the settlement act is payment of funds from the user's account to the counterparty.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the present invention will now be described, by way of example, and with reference to the accompanying drawings, in which:

Figs. 1 to 3 illustrate generation of a one-time code and administration of such codes;

Figs 4 to 8 each illustrate different stages in a scenario according to an embodiment of the present invention;

Fig.9 is a drawing illustrating various hardware and computing entities involved in the scenario of Figs. 4 to 8; and

Fig.10 is a flow diagram of the scenario illustrated in Figs. 4 to 8. DETAILED EMBODIMENTS

Description of embodiments of the present invention will be most suitably made by reference to a sequence of drawings illustrating a scenario. Referring to Fig. 1 , one element or 'tool' of relevance to embodiments of the present invention is a code format which provides sufficient address space to enable what amounts to, for all practical purposes, an unlimited number of different codes to be generated. One embodiment of such a code format is based upon a 14 character hexadecimal number H _n . This provides an address space with around 2x10 ¹⁸ different numbers. Codes are generated using a random number generator 500. Once the number H _n has been generated, it is then encoded into an indicium by a processor 502 running a dedicated algorithm. Encoding the number H _n into an indicium serves a number of purposes. First, where the encoding algorithm is not made public, it performs an encryption function, since the value H _n of the number cannot be parsed from the indicium without the algorithm. Secondly, encoding a number into an indicium then provides a means by which the number may more readily and robustly be transferred between parties and transmitted across networks. The indicium may take any form that enables both encryption and representation of a code number of the requisite format. The indicium may therefore be a light pattern (varying, over time, for example), a sound sequence or a visual symbol. In the present embodiment a visual symbol V is adopted in which the presence of black marks upon the white pathways represent the values of the 14 characters in the code H _n .

Referring to Fig. 2, one manner in which a code number H _n and its corresponding visual symbol V can be generated is by a suitable software application A running on a mobile device, such as, for example, a laptop computer, tablet computer, PDA or mobile telephone with appropriate processing capability. In the illustrated example the mobile device is a mobile phone 12 of a user 10. Upon generation of the code and its associated visual symbol V, the application running on the mobile phone additionally retrieves a UserlD. The UserlD (as the name suggests) is a stable identifier for the User 10 which is relied upon by an trusted administrator of the code, whose role will be discussed subsequently. In an alternative embodiment, the application running on the phone can send a request to the server 520 of the trusted administrator to generate a code and to send that code back to the phone of the User.

Once generated, the symbol V is then translated into packet data (for example in the form of a visual image bitmap) together with the UserlD and encrypted, typically via Secure Sockets Layer (SSL) and transmitted to an Administration server 520, at the URL value http://www.administrationoftrustedcode.fake (used in the illustrated scenario for exemplification purposes) operated by the trusted administrator. The URL of administration server 520 is stored within the application running on the phone 12 so that, upon generation of the code H _n and transformation into the symbol V, both the digitised symbol V and the UserlD are then transmitted to it in encrypted form.

Referring to Fig. 3, one role of the trusted administrator is to run an administration server 520 which operates a database comprising a number of inter-relational data tables, some examples of which are illustrated in schematic form in Fig. 3. These tables will be usable by the trusted administrator in providing authorisations for transactions between a user and a counterparty. A first group of tables T relate to values which are stored against UserlD. These include table T1 stores code values H _n against UserlD (e.g. XYZXYZ). A second table T2 stores UserlD values against bank account details. A third table T3 is illustrated and demonstrates that other user- related values may be stored, such as club memberships (e.g. loyalty cards or the like). A second group of tables, S, all relate to data values which point to a single UserlD in some way. The purpose of these tables will become apparent subsequently. Thus, table S1 maps the origin of HTTP GET requests to certain Counterparty's identification ('CParty'); table S2 maps Cparty to Data types such as User bank details. Referring now to Fig. 4, the phone 12 has a number of capabilities beyond the ability to make and receive calls via the GPRS mobile telephony system. These additional capabilities include: a camera to capture images, processing and memory capable of running applications programs which may typically perform cryptographic calculations, and memory sufficient to store captured images.

In the present scenario, the user 10 wishes to enter into a transaction with a counterparty; in the present example by making a purchase from a retailer 20. The user 10 has selected an item 14 carrying an indicium which encodes data relating to the item. In the present embodiment the indicium is a visual symbol in the form of a standard bar code 16 but other indicia, such as RFI Ds and other visual symbols may equally be employed. The user 10 presents the item 14 to the retailer 20 and, in the usual manner, the retailer scans the bar code 16 using an Electronic Point of Sale (EPOS) system 22. This results in the bar code 16 being parsed into a character string 24 which is then sent to a database 30 as a query. That query returns a value 32 which is the price of the item which is then displayed by the EPOS system. Thus far the scenario as described is entirely standard.

Referring now to Fig. 5, the user 10 then uses the application running on the phone to obtain a one time code H _n . There are a number of ways in which such a code may be obtained, but, in each instance, in order to initiate this process, the payment app first requires the user to authenticate their identity. This therefore avoids the possibility of a fraudulent transaction by a third party who has possession of the phone. Authentication is, in one preferred embodiment, biometrically performed, by reference to facial recognition, voice, retinal scan or, thumb print scan. Alternatively, authentication can be made by the use of a PIN, which is preferably six or more characters long. In the present embodiment authentication is made by the scan of a thumb print 40. The scanned thumb print 40 is then compared with benchmark print or scan held, in encrypted form within the phone 12, and which was created by the user 10 when the payment app was first initialised. Authentication of the person making the transaction therefore takes place within the phone.

Referring additionally to Fig. 6, once authentication has occurred, in a first embodiment, the payment app then contacts the server 520 of the trusted administrator to request a one-time code. The request for such a code is an encrypted data package includes the following data elements:

{UserlD} {TimeStamp} {LocationStamp} {CodeRequest} UserlD is a string of characters which identifies the user to the Trusted Administrator.

The TimeStamp is simply the time, as established from the user's mobile phone network signal 44, at which the code was generated, typically in the format DDMMYYYYHH:MM:SS/TZ, where TZ is the Time Zone which the user and bank have agreed upon. In a preferred embodiment the TimeStamp may contain a further hash string which authenticates the network time as genuine, since this may assist in combating fraud.

The LocationStamp can typically be established with reference to the mobile phone network (and therefore referencing a mobile phone cell) or, as in the present embodiment, GPS coordinates 46. In an alternative embodiment, some external reference (for example a beacon located in the retailer premises having a unique retailer ID and branch ID) can be used to establish location.

The CodeRequest is simply a request for a code to be sent

The server then generates a unique one-time code number H _n . As described previously this is rendered into the form of an indicium, in the present embodiment a visual indicium has the form of the symbol V. In the present embodiment, the rendering takes place at the server prior to transmission so that the server 520 transmits a digitised packaged of data which describes the visual symbol; alternatively the rendering can take place at the phone based on the data sent by the server.

In a modification the trusted administrator server 520 sends back a plurality of One-Time Codes H _n which are then stored in the phone. This can be useful for circumstances where the User is unable to gain access to the data network but may still wish to make a payment.

In an alternative embodiment, the software application running on the phone generates a code which is then sent, in enctrypted form, to the trusted administrator server 520 where a check is made to see if there are any collisions. This is not a preferred embodiment but is a viable alternative.

Once the code has been generated (and, where relevant, verified against collisions), the trusted administrator then stores the OneTimeCode against the UserlD in table T1 . Referring now additionally to Fig. 7, the Retailer 20 trusts the trusted administrator. Accordingly, to settle payment for the transaction between the retailer and the user, the user displays the symbol V which renders the OneTimeCode to the retailer. The retailer then scans that code and sends that OneTimeCode to the trusted administrator, together with further data, as part of a package of data TransactionDetails, which includes the following elements:

{PaymentSum} {PaymentDestination} {transaction! D} {OneTimeCode}

The further data therefore comprises:

PaymentSum is simply the amount that the retailer wishes to obtain from the User

PaymentDestination is details of the retailer's bank account and sort code

Transaction! D is an identifier generated by the retailer which enables the retailer then to link payments received from the bank to transactions made with customers and thereby allocate receipt of a sum to the relevant customer transaction

The TransactionDetails data package, once received at the Administration Server 520, is decrypted and parsed by the trusted administrator. First, the trusted administrator searches Table T1 for the OneTimeCode included with the TransactionDetails and the UserlD held in table T1 against that value. Having done so, it is then able to locate two further values with reference to the UserlD. The first of these is to search one or more of the other tables T2 to T _n for values held against the UserlD value which may be required in order for the transaction to proceed (such as the bank details stored in respect of the UserlD). Next the trusted administrator addresses the relevant set of tables S, all of which relate to the UserlD value. Each of those tables maps a particular counterparty, thus Cparty (A, or B and so on) to a URL from which a request enclosing a TransactionDetails data package may come. This is set out in table S1. Next, table S2 is searched for the value of CParty returned from table S1 , in order to retrieve from that table the values held against CParty which indicate the nature of the data which the trusted administrator may use in a transaction with CParty. In the present example, S2 indicates that, in transactions with Cparty A, the user's bank details may be used - which of course is required in this instance in order to settle the transaction. Those bank details are held by the trusted administrator against the value UserlD in table T2.

To settle the transaction, the trusted administrator then generates a transaction data package, here known as the {PaymentDetails} data package. This package bundles the further data which comprises the {PaymentSum} {PaymentDestination} {transaction ID} data received from the retailer together with an {Authorisation ID} data element, freshly generated by the trusted administrator. The {Authorisation ID} data element is trusted and relied upon by banks as a basis for acting upon transaction requests received from the trusted administrator. The {PaymentDetails} data package is then encrypted and sent to the User bank 60.

The user Bank 60 then uses the decrypted and parsed data elements within the transaction data package {PaymentDetails} first of all, to authenticate the transaction request as genuine on the basis of an AuthorisationID having the requisite form. Once authenticated, the user Bank 60 then sends the payment to the Retailer Bank 80 in accordance with the {PaymentSum} {PaymentDestination} {transaction ID} data elements included within the {PaymentDetails} data package. That payment is bundled with the {Transaction! D} in order that the retailer 20 can then identify the payment and allocated receipt of it to the relevant customer transaction.

Referring to Fig.9, the various hardware and computing entities over and above the administration server 520 of the trusted administrator which are involved in the scenario are shown. The phone 12 of the user 10 is connected to a mobile phone network via a one or more cellular network radio masts 100 to enable the making and receiving of calls and SMS messages, as well, additionally, to receive digitally-encoded time data. In addition, the mobile phone network is connected to a gateway server 1 10 which interfaces with the Internet to enable the transmission of data to and receipt of data from other entities within the Internet. Further, when the GPS capability of the phone 12 is activated, it receives signals from GPS satellites 120 which enable it to establish its coordinates.

The retailer 20 operates a server 200 which records and operates its stock database function 30, processes EPOS generated data (such as relating to a UserOneTimeCode) and attends to the assembly and transmission of TransactiondDetails over the Internet to and from the user's Bank 60 and the retailer bank 80. Finally, each of the user bank 60 and retailer bank 80 operate one or more servers 320 and 330 to receive transaction details, process transactions accordingly and dispatch messages confirming the performance of such transactions.

Referring to Fig.10, the operation of the entities set out in Fig. is as follows.

602 User authenticates their identity to their phone 12

604 App running on phone 12 requests a OneTimeCode from Trusted Administrator 606 Trusted Admin generates OneTimeCode and stores against UserlD

608 Trusted Admin sends OneTimeCode to User

610 User gives OneTimeCode, rendered in V code symbol to the retailer

612 the retailer scans the code symbol V, generates further data to bundle with the OneTimeCode to form the {Transaction Details} data package and sends these to the Trusted Admin.

614 The Trusted Admin retrieves the UserlD corresponding to the OneTimeCode sent with the {Transaction Details} package

616 The Trusted Admin generates Authorisation ID which it bundles with data elements enabling payment to be made to create to create the transaction data package {PaymentDetails} and sends {PaymentDetails} to User Bank 60

618 User Bank authenticates

620 User Bank makes payment to Retailer Bank

622 Retailer bank receives payment

624 Retailer bank confirms receipt

In an enhanced modification of this embodiment, the payment app additionally generates a further data element known as {TransactionLimit}. This is a value up to which the user's bank 60 is prepared to honour any transaction concluded upon the basis of the respective {OneTimeCode}. This figure may be generated in several ways. In one embodiment of this modification, prior to generating the {OneTimeCode}, the payment app first contacts the user's bank 60 with details of the user, whereupon the user bank 60 then returns a value for {TransactionLimit} based upon (for example) a combination of the user's balance and its own internal policies. In an alternative embodiment, the user bank 60 provides a figure for {TransactionLimit} to the payment app on the user's phone 12 which applies for a set period (such as a day, in which case the figure is updated daily). In this embodiment, the value of the variable {TransactionLimit} is then used throughout that set period. In yet a further embodiment, that figure is adjusted with each transaction undertaken; though this will need the payment app to receive data (for example from the trusted administrator) concerning the value of transactions which ought to be taken into account in adjusting the value of {TransactionLimit}.

As mentioned above, the {LocationStamp} can be generated by reference to a number of external (i.e. external to the phone 12) references. A preferred external reference is one generated in relation to what may be thought of a 'logical', quasi geographical location rather than actual geographical location. An example of such a location and related reference is a reference that specifies the premises of a retailer. This reference could, for example, be generated by a suitable wireless transmitter beacon which generates a code having an address space which is unique to both the retailer organisation in which the transaction is to take place, and the branch (where the retailer is a multiple branch owner) of that organisation. In addition, that code is hashed based on the time of its generation. The benefit of a {LocationStamp} generated on such a basis is that it is harder to mimic from another location. GPS coordinates, for example, could conceivably be generated by a user simply typing them in meaning that they do not relate to the actual location of the user 10. By generating a more trustworthy {LocationStamp} this parameter can then be used and relied upon to a greater extent as part of the user and transaction authentication process, resulting in a more secure transaction.

According to a second embodiment, the application which generates the OneTimeCode is operated by the retailer. To avoid confusion this kind of user authorisation will be referred to henceforth as {OneTimeCode2}. The initial interaction involves the user assembling those goods it wishes to purchase. These are then scanned by the retailer 20 in the manner indicated previously to generate a total sum which the user must pay to the retailer to conclude the transaction. The user 10 then displays an indicium which is a rendered manifestation of the data element {UserlD} to the retailer 20 which is unique to the user 10.

The retailer then scans the {UserlD} indicium and assimilates an authenticating credential, which may be a PIN or some biometric feature as previously described. The {UserlD} and authenticator are encrypted and sent to the trusted administrator together with {OneTimeCode2}, all of which is then bundled with the other data elements described above and sent to the trusted administrator. Thereafter, settlement of the transaction takes place as previously described.