Field of the invention

The present invention relates to a method of operating a proxy to facilitate performing a transaction between a client device and a merchant system, a method of operating a client device to perform a transaction between the client device and a merchant system, systems and devices for performing the same, and computer programs for performing the same.

Background of the invention

It is well-known to perform various commercial transactions over the Internet (or other such networks). Such e-commerce is usually performed by having a merchant host a website with various webpages. A user can then interact with these webpages, for example by using a browser application that is running on their home computer. The user may select various goods and/or services that the merchant has advertised on his website and may then provide details of a payment mechanism (such as credit or debit card information or bank account information) to the merchant via the website. The merchant then provides the selected goods and/or services in exchange for a payment via the payment mechanism.

The advent of mobile devices (such as mobile telephones) that are able to connect to the Internet wirelessly (e.g. over telecommunication systems) and that are able to download and display webpages has meant that such e-commerce can now be performed via a mobile device.

However, the processing abilities, memory, screen size and download speed of such mobile devices is often much lower than that of conventional computing devices such as a personal/desktop computer. Consequently, it would be desirable to be able to adapt the e-commerce transactions so that, when they are performed via a mobile device, they are tailored more to the capabilities of the mobile device. In doing so, however, it is important that the security of the transaction (e.g. the security of sensitive information such as passwords and credit/debit card details) is not compromised and is maintained as high as possible.

Summary of the invention

According to an aspect of the invention, there is provided a method of operating a proxy to facilitate performing a transaction between a client device and a merchant system, the method comprising the proxy: receiving first transaction data from the client device; receiving first transaction data from the merchant system; forwarding first transaction data received from the client device to the merchant system; forwarding first transaction data received from the merchant system to the client device; identifying that a particular stage of the transaction has been reached, the particular stage to involve a transfer of second transaction data between the client device and a particular system; and in response to identifying that the particular stage of the transaction has been reached, indicating to the client device that second transaction data should be transferred directly between the client device and the particular system.

The method may comprise the proxy performing an operation to facilitate performing the transaction based on first transaction data that the proxy has received.

The operation to facilitate performing the transaction may comprise modifying at least some of the first transaction data received from the merchant system such that the modified first transaction data is suitable for use by the client device and forwarding the modified first transaction data to the client device.

The operation to facilitate performing the transaction may comprise modifying at least some of the first transaction data received from the client device such that the modified first transaction data is suitable for use by the merchant system and forwarding the modified first transaction data to the merchant system.

The operation to facilitate performing the transaction may comprise performing an action required for the transaction on behalf of the merchant system or the client device.

Identifying that the particular stage of the transaction has been reached may comprise determining whether first transaction data received by the proxy is associated with one or more predetermined URLs.

Identifying that the particular stage of the transaction has been reached may comprise determining whether first transaction data received by the proxy contains one or more predetermined keywords or phrases.

According to another aspect of the invention, there is provided, a method of operating a client device to perform a transaction between the client device and a merchant system, the method comprising the client device: receiving, from a proxy, first transaction data that the merchant system has sent to the client device via the proxy; sending first transaction data to the merchant system via the proxy; receiving, from the proxy, an indication that a particular stage of the transaction has been reached, the particular stage to involve a transfer of second transaction data between the client device and a particular system; and in response to receiving the indication, transferring second transaction data directly between the client device and the particular system.

In one embodiment, transferring second transaction data directly between the client device and the particular system comprises: sending a first amount of transaction data from the client device to the particular system; and receiving a response from the client device with a second amount of transaction data; and the method comprises forwarding the response to the proxy for processing by the proxy.

In any of the above, the second transaction data may comprise sensitive information. The sensitive information may comprise one or more of: a password; details of a credit card; details of a debit card; details of an account of an operator of the client device; personal identification information about an operator of the client device.

In any of the above, the first and/or second transaction data may comprise one or more webpages.

In any of the above, the particular system may a system of a financial institution or the merchant system (in which case the particular stage may be a stage for providing details for a payment for the transaction). The particular stage may be a stage for authenticating a user of the client device.

According to an aspect of the invention, there is provided a method for performing a transaction between a client device and a merchant system, the method comprising: operating a proxy to facilitate performing the transaction by carrying out a method of operating a proxy as set out above; and operating the client device to perform the transaction by carrying out a method of operating a client as set out above.

According to an aspect of the invention, there is provided a proxy system comprising a processor, the processor being arranged to carry out a method of operating a proxy as set out above.

According to an aspect of the invention, there is provided a device comprising a processor, the processor being arranged to carry out a method of operating a client device as set out above.

According to an aspect of the invention, there is provided a computer program which, when executed by a processor, carries out any one of the above methods.

According to an aspect of the invention, there is provided a data carrying medium carrying such a computer program. The medium may be a storage medium or a transmission medium. Brief description of the drawings

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

Figure 1 schematically illustrates a system according to an embodiment of the invention;

Figure 2 schematically illustrates an example computer system for use in embodiments of the invention; and

Figures 3A-D schematically illustrate data flows and methods by which a user terminal and a merchant system may communicate, as part of performing a transaction in accordance with an embodiment of the invention.

Detailed description of embodiments of the invention

In the description that follows and in the figures, certain embodiments of the invention are described. However, it will be appreciated that the invention is not limited to the embodiments that are described and that some embodiments may not include all of the features that are described below. It will be evident, however, that various modifications and changes may be made herein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

Embodiments of the invention are directed towards enabling a transaction between an end user (a purchaser or a customer or a client) and a merchant (a seller or a vendor or a provider). The transaction is typically a purchase by the end user of goods or services provided by the merchant in return for a monetary payment from the end user to the merchant, or some other form of payment or consideration (e.g. vouchers, loyalty points, etc). In particular, embodiments of the invention are directed towards enabling such transactions (or exchanges) to take place via a website of (or provided by) the merchant in a manner in which the transaction can be carried out (a) in a format that is convenient for the end user and (b) at a requisite level of security. Given that there is usually a financial aspect to the transaction (namely the monetary payment or other form of payment), the transaction may involve the exchange or transmission of sensitive information, which may be from the end user to the merchant or to a

banking/financial establishment that may be involved in facilitating and/or authorising and/or authenticating and/or processing at least a part of the financial side to the transaction. Naturally, it is desirable to maintain a level of security in relation to this sensitive information for the financial side of the transaction (so as to avoid, for example, the misuse or misappropriation of the sensitive

information). This sensitive information could include, for example, passwords, credit/debit card details (card numbers, expiry dates, etc.), bank account details (account numbers, sort codes, etc.), personal identification information (login-ID, date of birth, mother's maiden name, etc.), or other information that may be used in order to verify the entities involved and/or to authorise and complete the payment.

1 - System architecture

Figure 1 schematically illustrates a system 100 according to an

embodiment of the invention. The system 100 comprises: a merchant system 102 operated by a merchant; a finance system 104; a transaction proxy system (or simply a proxy) 106; a user terminal 108 operated by an end user; and a network 110.

The network 110 may be any form of communications network or infrastructure for communicating data from a sender to a receiver. The network 110 may be formed from one or more subnetworks. The network 110 may comprise one or more of the Internet, a local area network, a metropolitan area network, a wide area network, a telecommunications (e.g. mobile telephone) network, or any other form of data communication network. The network 1 10 may comprise wired and/or wireless communication paths. The merchant system 102, the finance system 104, the transaction proxy system 106 and the user terminal 108 may communicate (i.e. transmit and/or receive data) with each other via the network 110, as is well-known in this field of technology. As a more particular example, if the user terminal 108 is a mobile telephone and the merchant system 102 is a system connected to the Internet, then the network 110 may comprise the Internet, a mobile telecommunications system (e.g. base stations, antennae, etc.) and any bridges/gateways/routers/etc. between them so as to set up a communications path between the merchant system 102 and the user terminal 108. Any appropriate communications protocols (such as HTTP and TCP/IP) may be used for communicating via the network 110.

The merchant system 102 may be any system operated by a merchant to enable a transaction between an end user and the merchant. In particular, the merchant system 102 may make available (i.e. host) a merchant website 112 that comprises one or more webpages 4 for use by an end user, as is well known in this field of technology. The end user may then use his user terminal 108 to interact with the merchant website 112 provided by the merchant system 102 via the network 110 so that a transaction can be instigated between the end user and the merchant. In particular, the website 112 may provide one or more webpages 114 that allows the end user to select one or more products and/or services being offered by the merchant and to instigate and complete a transaction to obtain those selected products and/or services from the merchant in exchange for an agreed payment. This procedure is well-known in the field of e-commerce and its method of implementation shall therefore not be described in more detail herein except where necessary.

Similarly, the finance system 104 (or banking system or transaction clearance and/or approval system) may be any system operated by one or more financial institutions or organisations (such as banks, building societies, credit card companies, etc.) to carry out (or enable) at least a part of the financial side of the transaction between the merchant and the end user. This may simply involve performing authentication of credit/debit card details or account details. Additionally or alternatively, this may involve performing authentication of the end user (e.g. checking that the end user has provided valid passwords or security information in relation to a credit/debit card or a bank account so as to provide a degree of certainty that the end user is who he claims to be and/or is in physical possession of the credit/debit card). The above authentication may be performed by the finance system 104 on behalf of (or at the request of) the merchant system 102 so that the merchant has more confidence that the transaction is legitimate (i.e. valid payment details are being provided and/or the end user is actually who he claims to be). Additionally or alternatively, the finance system 04 may carry out activities to transfer money (or other forms of payment) from an account of the end user to an account of the merchant, i.e. to actually complete/perform the financial aspect of the transaction.

The finance system 104 may make available (i.e. host) a website 116 that comprises one or more webpages 1 8 for use by the end user and/or the merchant, as is well known in this field of technology. The end user and/or merchant may then to interact (via the user terminal 08 and/or the merchant system 102 as appropriate over the network 110) with the website 116 provided by the finance system 104 so that financial aspects of the transaction can take place, e.g. verification and/or authorisation of a user or account/card details and/or the actual transfer of funds etc.

As will be described later, the merchant system 102 may request and obtain a webpage 118 from the finance system 104. The merchant system 102 may then build one of its own webpages 114 by making use of the webpage 118 provided by the finance system 104 (e.g. by embedding or incorporating the webpage 118 provided by the finance system 104 into a template webpage).

The user terminal 108 may be any kind of device (or terminal or computer or apparatus) with which an end user may interact in order to carry out the transaction. The user terminal 108 may be, for example, a personal computer, a desktop computer, a laptop, a palmtop, a games console, a mobile telephone, a personal digital assistant, etc. The user terminal 108 comprises a display (or monitor or screen) for displaying the webpages 1 14, 118 of the websites 112, 116 provided by the merchant system 102 and the finance system 104. In some embodiments, some webpages 1 14, 1 8 may be complex with a large amount of information. Such webpages 1 14, 118 are typically not well-suited for display on user terminals 108 that have a small-sized display, such as a mobile telephone (i.e. small in comparison with a standard monitor of a personal computer or laptop). This is because such webpages 1 14, 1 18 require the end user to have to carry out a large amount of navigation across/along the webpage 1 14, 118 to find a particular item of information that is of interest. Such navigation is often time consuming and difficult (especially on small devices such a mobile telephones). Moreover, some webpages 114, 118 may be large in terms of the amount of data required to store and transmit those webpages 114, 118 (e.g. webpages 114, 118 with detailed pictures or large amounts of information). Such webpages 114, 118 are typically not well-suited for being transmitted to user terminals 108 that have a relatively low data reception/download rate - examples of such user terminals 108 include mobile devices (such as mobile telephones or laptops with mobile connectivity) that are arranged to communicate via a telecommunications network that forms part of the network 110.

Whilst a merchant or financial institution may wish to use webpages 114, 1 18 as described above (because they will appear attractive to end users who do not have limitations on their user terminals 108), the merchant or financial institution will also want to accommodate those end users whose user terminals 108 do have limitations as set out above. In recognition of the problems that such large and/or complex webpages 114, 118 may cause, it is known to make use of a transaction proxy system 106. Transaction proxy systems 106 are well- known in this field of technology and their operation shall therefore not be described in great detail herein. However, an example overview of their operation is given below in relation to communications between the user terminal 108 and the merchant system 102. When using a transaction proxy system 06, the user terminal 108 and the merchant system 102 communicate with each other over the network 110 not directly, but via the transaction proxy system 106. The transaction proxy system 106 therefore acts as an intermediary between the user terminal 108 and the merchant system 102, i.e. data to be communicated between the user terminal 108 and the merchant system 102 is routed via the transaction proxy system 106. The transaction proxy system 106 operates to facilitate communications and activities (such as performance of the transaction) between the user terminal 108 and the merchant system 102.

In particular, the transaction proxy system 106 may receive data from the merchant system 102, where this data is intended for the user terminal 108.

Before passing this data to the user terminal 108, the transaction proxy system 106 may perform some processing/operations on the data. For example, the transaction proxy system 106 may reformat the data before sending the reformatted data to the user terminal 108 - this is performed so that the

reformatted data can be better transmitted to the user terminal 108 and/or can be better displayed at the user terminal 108 than would be possible with the original data. Additionally, or alternatively, the transaction proxy system 106 may be able to perform actions on the data on behalf of the user terminal 108, such as completing certain fields in a webpage 1 4 (e.g. name, address, etc. of the end user) if the transaction proxy system 106 has access to the data necessary to complete these fields - this can save the end user time and reduce the

complexity of the data to be transferred to and/or displayed at the user terminal 108. Similarly, the transaction proxy system 106 may receive data from the user terminal 108, where this data is intended for the merchant system 102. Before passing this data to the merchant system 102, the transaction proxy system 106 may perform some processing/operations on the data. The

processing/operations performed may be similar to those described above.

As an example, the user terminal 108 may send (via the network 102) to the transaction proxy system 106 a request for a webpage 114. The transaction proxy system 106 then sends (via the network 102) to the merchant system 102 an analogous request for this webpage 114. The merchant system 102 responds by sending (via the network 102) the requested webpage 114 to the transaction proxy system 106. The transaction proxy system 106 then creates a replacement webpage (or perhaps even a software application/module) 120 that is better suited to the needs and capabilities of the user terminal 108, based on the webpage 114 that the transaction proxy system 106 received. This may involve, for example, the transaction proxy system 106 parsing HTML of the webpage 114 it has received from the merchant system 102 and optimising that HTML to form the replacement webpage 120 for transmission to, and display at, the user terminal 108. This could include removing unnecessary information (such as background images), removing colour, using simplified fonts, rearranging various components (e.g. input fields), etc. The transaction proxy system 106 then transmits (via the network 102) this replacement webpage 120 to the user terminal 108. The end user may interact with the replacement webpage 120 at the user terminal 108, e.g. by filling in various details (such as selecting one or more products or services being offered by the merchant). The user terminal 108 may then transmit (via the network 102) the completed webpage 120 to the transaction proxy system 106. The transaction proxy system 106 may then format the completed webpage 120 that it receives into a format that the merchant system 102 is expecting (e.g. the format that the merchant system 102 would expect if the user terminal 108 had been communicating directly with the merchant system 102 instead of communicating via the transaction proxy system 106) and then sends this reformatted completed webpage 120 to the merchant system 102. The merchant system 102 may then send a subsequent webpage 1 4 to the transaction proxy system 106, and the process may then continue along these lines until the communications session is complete.

The transaction proxy system 106 sits between the merchant system 102 and the user terminal 108 and may modify the communications between the merchant system 102 and the user terminal 108 so that they are better suited to the needs and capabilities of the user terminal 108 and/or the merchant system 102 and/or to save time for the end user if possible. From the perspective of the merchant system 02, the transaction proxy system 106 acts as a proxy of the user terminal 108; from the perspective of the user terminal 108, the transaction proxy system 106 acts as a proxy of the merchant system 102.

Figure 1 illustrates the system 100 as comprising a single merchant system 102, a single finance system 104, a single transaction proxy system 106 and a single user terminal 108. However, it will be appreciated that embodiments of the invention may involve a system 100 that comprises a plurality of one or more of the merchant system 102, the finance system 104, the transaction proxy system 106 and the user terminal 108. For example, there may be multiple finance systems 104 (e.g. one for handling Visa™ transactions and one for handling Mastercard™ transactions); there may be multiple merchant systems 102 for different merchants and each merchant system 02 may make use of one or more finance systems 104 to facilitate the financial side of the transactions that merchant system 102 gets involved in; there may be multiple transaction proxy systems 106 and each transaction proxy system 106 may act as a proxy for one or more merchant systems 102; and there may be multiple user terminals 108 for multiple end users and each user terminal 108 may communicate (either directly or via a transaction proxy system 106) with one or more merchant systems 102 and/or one or more financial systems 04.

Moreover, it will be appreciated that some of the systems illustrated in figure 1 could be combined or integrated into a single system. For example, one or more of the merchant system 102, the finance system 104 and the transaction proxy system 106 could be combined into a single system. In particular, a merchant could operate its own merchant system 102 and its own transaction proxy system 106 for that merchant system 102, with this being implemented as an integrated system.

The merchant system 102, the finance system 104, the transaction proxy system 106 and the user terminal 108 may comprise one or more computer systems (such as personal computers, servers, etc.) as appropriate and as is well-known in this field of technology. Figure 2 schematically illustrates an example computer system 200 for use in embodiments of the invention.

The system 200 comprises a computer 202. The computer 202

comprises: a storage medium 204, a memory 206, a processor 208, a storage medium interface 210, a user output interface 212, a user input interface 214 and a network interface 2 6, which are all linked together over one or more

communication buses 218.

The storage medium 204 may be any form of non-volatile data storage device such as one or more of a hard disk drive, a magnetic disc, an optical disc, a ROM, etc. The storage medium 204 may store an operating system for the processor 208 to execute in order for the computer 202 to function. The storage medium 204 may also store one or more computer programs (or software or instructions or code) that form part of an embodiment of the invention.

The memory 206 may be any random access memory (storage unit or volatile storage medium) suitable for storing data and/or computer programs (or software or instructions or code) that form part of an embodiment of the invention.

The processor 208 may be any data processing unit suitable for executing one or more computer programs (such as those stored on the storage medium 204 and/or in the memory 206) which have instructions that, when executed by the processor 208, cause the processor 208 to carry out a method according to an embodiment of the invention and configure the system 200 to be a system according to an embodiment of the invention. The processor 208 may comprise a single data processing unit or multiple data processing units operating in parallel (independently or in cooperation with each other). The processor 208, in carrying out data processing operations for embodiments of the invention, may store data to and/or read data from the storage medium 204 and/or the memory 206.

The storage medium interface 210 may be any unit for providing an interface to a data storage device 222 external to, or removable from, the computer 202. The data storage device 222 may be, for example, one or more of an optical disc, a magnetic disc, a solid-state-storage device, etc. The storage medium interface 210 may therefore read data from, or write data to, the data storage device 222 in accordance with one or more commands that it receives from the processor 208.

The user input interface 214 is arranged to receive input from a user, or operator, of the system 200. The user may provide this input via one or more input devices of the system 200, such as a mouse (or other pointing device) 226 and/or a keyboard 224, that are connected to, or in communication with, the user input interface 214. However, it will be appreciated that the user may provide input to the computer 202 via one or more additional or alternative input devices. The computer 202 may store the input received from the input devices via the user input interface 214 in the memory 206 for the processor 208 to subsequently access and process, or may pass it straight to the processor 208, so that the processor 208 can respond to the user input accordingly.

The user output interface 212 is arranged to provide a graphical/visual output to a user, or operator, of the system 200. As such, the processor 108 may be arranged to instruct the user output interface 212 to form an image/video signal representing a desired graphical output, and to provide this signal to a monitor (or screen or display unit) 220 of the system 200 that is connected to the user output interface 212.

In some embodiments, the monitor 220 may be touch sensitive, in which case the monitor 220 may provide input to the user input interface 214 based on how a user touches the monitor 220.

Finally, the network interface 216 provides functionality for the computer 202 to download data from and/or upload data to one or more data

communication networks (such as the network 110 of figure 1).

It will be appreciated that the architecture of the system 200 illustrated in figure 2 and described above is merely exemplary and that other computer systems 200 with different architectures and additional and/or alternative components may be used in embodiments of the invention. For example, if a user terminal 108 is a mobile telephone, then the keyboard 224 and mouse 226 may not be present and could be replaced by a number pad or touch sensitive screen, the storage medium interface 210 may be omitted, and the network interface 216 could be a telecommunications network interface (with antenna, modulator/demodulator, etc. as is well known in this field of technology).

Similarly, the merchant system 102 and/or the finance system 104 and/or the transaction proxy system 106 may make use of one or more servers, in which case the computer system 200 would be configured appropriately as the one or more servers (again as is well known in this field of technology).

The merchant system 102, the finance system 104, the transaction proxy system 106 and the user terminal 108 may execute one or more respective software applications or computer programs (as described above with reference to figure 2) in order to carry out embodiments of the invention as discussed below. The application executed by the user terminal 108 may take the form of a bespoke application provided to the user terminal 108 by either the transaction proxy system 106 or the merchant system 102. For example, the application executed by the user terminal 108 may be a mobile telephone application that the end user has downloaded onto his user terminal 108 (mobile telephone) from a website hosted by the transaction proxy system 106 or the merchant system 102. This application will then have the functionality to carry out embodiments of the invention as set out below. Alternatively, the application executed by the user terminal 108 may be a browser application, in which case the browser application should be configurable to be able to run custom code (such as Java applets) which may be provided by the transaction proxy system 106 or the merchant system 102. When the custom code has been downloaded to the user terminal 108, the browser application will have the functionality to carry out embodiments of the invention as set out below. 2 - Transaction processing

Figure 3A schematically illustrates a data flow and method by which the user terminal 108 and the merchant system 102 may communicate, as part of performing (or carrying out or processing) a transaction in accordance with an embodiment of the invention. As shown in figure 3A, the performance of the transaction makes use of a transaction proxy system 106 as has been described above.

To begin, a very brief overview will be given below.

At a step S300, the user terminal 108 forwards (or sends or posts) transaction data D1 to the transaction proxy system 106.

At a step S302, the transaction proxy system 106 receives the transaction data D1. The transaction proxy system 106 may perform some operations on, or manipulations or modifications of, the transaction data D1 to form transaction data D2. This is a process known as "proxification" as is well-known in this field of technology. Alternatively, if no such operations or manipulations or

modifications are performed, then the transaction data D2 may be the same as the transaction data D1.

At a step S304, the transaction proxy system 106 then forwards (or sends or posts) the transaction data D2 to the merchant system 102.

At a step S306, the merchant system 102 receives the transaction data D2. The merchant system 102 may then perform some processing on the received transaction data D2. This processing may involve any processing necessary for the current stage of the transaction being performed, e.g.

identifying relevant webpages 114 to provide to the user terminal 108, accessing account data of the end user who is operating the user terminal 108, checking an inventory of goods and/or services that the merchant provides, and their respective prices, delivery dates, etc. so that the end user can be informed accordingly (e.g. via a webpage 1 14 that the merchant system 102 constructs to represent this data). It will be appreciated that the particular processing will depend on the nature of the transaction and the current stage of the transaction (e.g. starting the transaction, being half way through the transaction, completing the transaction, aborting the transaction, backing up through previous steps of the transaction, etc.) as is well known in this field of technology. Different stages of the transaction could be, for example, one or more of: a user registration stage (at which the user provides various details about himself); a user login stage (at which the user logins in to an account held with the merchant system 102); a product selection stage (at which the user selects one or more goods or services provided by the merchant); a summary stage (at which a summary of the current transaction is provided); a payment stage (at which payment/financial details are provided by the end user and/or at which the payment is actually verified and processed); etc.

The merchant system 102 may, as part of the processing step S306, communicate with the finance system 104. For example, the merchant system 102 may request that the finance system 104 provides the merchant system 102 with one of the webpages 118 of the finance system 104. The finance system 104 may send this requested webpage 118 to the merchant system 102 and the merchant system may then use the received webpage 118 to form a webpage 114 for sending to the user terminal 108 (e.g. embedding the received webpage 118 into a template webpage of the merchant system 102).

At a step S308, the merchant system 102 forwards (or sends or posts) transaction data D3 to the transaction proxy system 106.

At a step S310, the transaction proxy system 106 receives the transaction data D3. The transaction proxy system 106 may perform some operations on, or manipulations or modifications of, the transaction data D3 to form transaction data D4. Again, this is a process known as "proxification" as is well-known in this field of technology. Alternatively, if no such operations or manipulations or modifications are performed, then the transaction data D4 may be the same as the transaction data D3. At a step S312, the transaction proxy system 106 then forwards (or sends or posts) the transaction data D4 to the user terminal 108.

At a step S314, the user terminal 108 receives the transaction data D4. The user terminal 108 may then perform some processing on the received transaction data D4, such as displaying/outputting the transaction data D4 to the end user and/or allowing the end user to interact with the transaction data D4.

The transaction data D3 may be generated by the merchant system 102 as part of the processing of the transaction data D2 at the step S306.

Alternatively, the transaction data D3 may be generated by the merchant system 102 independently of any processing of the transaction data D2 at the step S306. This is represented by the dashed line linking the steps S306 and S308.

Similarly, the transaction data D1 may be generated by the user terminal 108 as part of the processing of the transaction data D4 at the step S314.

Alternatively, the transaction data D1 may be generated by the user terminal 108 independently of any processing of the transaction data D4 at the step S314. This is represented by the dashed line linking the steps S300 and S314.

As the transaction is usually performed via webpages 114 provided by the website 112 hosted by the merchant system 102, the data D1 , D2, D3 and D4 will often comprise webpage data (encoded, for example, as HTML data). However, this need not always be the case. For example, the data D1 could simply represent a request by the user terminal 108 to initiate a transaction with the merchant system 102. The data D1 , D2, D3 and D4 could include other data in addition to HTML data representing the webpages 1 14, in which case the data D1 , D2, D3 and D4 could be formatted or packaged in numerous ways, such as in an XML structure that comprises the HTML data together with other data.

A more specific example of the processing shown in figure 3A is given below.

At the step S300, the user terminal 108 forwards (or sends or posts) a request (transaction data D1) to the transaction proxy system 106 to initiate a transaction with the merchant system 102. The request D1 could, for example, identify a URL of a webpage 114 of the merchant system 102 that is an initial "entry-point" webpage 1 14 for commencing a transaction. Alternatively, the request D1 could be a message comprising a predetermined code that the transaction proxy system 106 is arranged to identify and interpret as a request by a user terminal 108 to commence a transaction with the merchant system 102.

At the step S302, the transaction proxy system 106 receives the request D1. The transaction proxy system 106 may process this request D1 into a request (transaction data D2) for a particular webpage 114 from the merchant system 102.

At the step S304, the transaction proxy system 106 then forwards the request D2 to the merchant system 102.

At the step S306, the merchant system 102 receives the request D2, following which, at the step S308, the merchant system 102 forwards (or sends or posts) the requested webpage 114 (transaction data D3) to the transaction proxy system 106. The step S306 may involve the merchant system dynamically building the requested webpage 114.

At the step S310, the transaction proxy system 106 receives the requested webpage D3. The transaction proxy system 106 may perform some operations on, or manipulations or modifications of, the webpage D3 to form a replacement webpage (transaction data D4). This modification could include, for example, one or more of: removing unnecessary data (such as background images);

removing video objects (especially if the user terminal is unable to process video or has a processor with relatively low processing capabilities); removing audio data; simplifying fonts and colours; filling in fields present on the webpage D3 based on information that the transaction proxy system 106 already has available to it (e.g. the name of the end user); and/or rearranging information on the webpage D3 so as to be more easily navigable at the user terminal 108; etc. This processing may therefore transform the webpage D3 into a new webpage D4 that is specifically adapted to the processing abilities and/or display abilities of the user terminal 108. The processing may transform the webpage D3 into a new webpage D4 that requires less user input than would otherwise have been necessary if webpage D3 were to be provided to the user terminal 108 instead.

At the step S312, the transaction proxy system 106 then forwards (or sends or posts) the replacement webpage D4 to the user terminal 108.

At the step S314, the user terminal 108 receives the replacement webpage D4 and displays it to the end user. The end user may then interact with the displayed webpage D4 (e.g. completing one or more input fields, navigating around the webpage D4, selecting goods and/or services - and quantities thereof - that may form part of the transaction to be performed, etc.).

The user terminal 108 therefore generates a completed webpage

(transaction data D1) which the user terminal 108, at the step S300, sends to the transaction proxy system 106.

At the step S302, the transaction proxy system 106 receives the

completed webpage D1. The transaction proxy system 106 may process this completed webpage D1 to form a replacement webpage (transaction data D2) by performing any reformatting or modifications necessary in order for the

replacement webpage D2 to be compatible with the format that the merchant system 102 is expecting (i.e. to remove any incompatibilities from the webpage D1).

At the step S304, the transaction proxy system 106 then forwards the replacement webpage D2 to the merchant system 102.

At the step S306, the merchant system 102 receives the replacement webpage D2. The merchant system 102 may perform various processing based on the information that the end user has provided to the merchant system 102 via the replacement webpage D2. This could end the transaction or, alternatively, the merchant system 102 may, at the step S306, identify and/or generate another webpage 114 (transaction data D3) forming a step in the transaction which, at the step S308, the merchant system 102 sends to the transaction proxy system 106. The process may then continue as set out above. When the transaction proxy system 106 receives transaction data D3 from the merchant system 102, the transaction proxy system 106 may be able to perform all of the processing relevant to the received transaction data D3 at the step S310, i.e. the transaction proxy system 106 may be able to perform all the relevant processing without having to involve the user terminal 108. For example, if the transaction data D3 is a webpage having input fields for the end user's name and address, then if the transaction proxy system 106 has this information available to it, then the transaction proxy system 106 may complete the webpage D3 and return the completed webpage to merchant system 102 without involving the user terminal 108. As another example, the transaction data D3 may simply be a webpage that requires the end user to press a "next" or "proceed" button - the transaction proxy server 106 may carry out this task for the end user and return a webpage to the merchant system 102 indicating that the button has been pressed. Therefore, the processing may jump straight from the step S310 to the step S304 (as indicated by a dashed arrow in figure 3A).

Similarly, when the transaction proxy system 106 receives transaction data D1 from the user terminal 108, the transaction proxy system 106 may be able to perform all of the processing relevant to the received transaction data D1 at the step S302, i.e. the transaction proxy system 106 may be able to perform all the relevant processing without having to involve the merchant system 102. For example, the transaction proxy system 106 may have cached a webpage 114 of the merchant system 102 and so is able to provide that webpage 114 to the user terminal 108 without having to request it from the merchant system 102.

Therefore, the processing may jump straight from the step S302 to the step S312 (as indicated by a dashed arrow in figure 3A).

In summary, then, the transaction proxy system 106 is arranged to facilitate performing a transaction between the user terminal 108 (a client device) and the merchant system 102. This involves the transaction proxy system 106: receiving transaction data D1 from the user terminal 108; receiving transaction data D3 from the merchant system 102; forwarding transaction data D2 received from the user terminal 108 to the merchant system 102; and forwarding transaction data D4 received from the merchant system 102 to the user terminal 108. The transaction data D2 may be the same as the transaction data D1 or may be a modified version of the transaction data D1. The transaction data D4 may be the same as the transaction data D3 or may be a modified version of the transaction data D3. The transaction proxy system 106 may perform an operation (step S302 and/or S310) to facilitate performing the transaction based on transaction data that it receives.

Similarly, the user terminal 108 (a client device) is arranged to perform a transaction between the user terminal 108 and the merchant system 102 by: receiving, from the transaction proxy system 106, transaction data D4 that the merchant system 102 has sent to the user terminal 108 via the transaction proxy system 106; and sending transaction data D1 to the merchant system 102 via the transaction proxy system 106. The user terminal 108 may perform some processing (step S314) on the transaction data D4 that it receives.

The processing described above with reference to figure 3A enables a user terminal 108 to carry out a transaction via a website 1 12 of a merchant in a manner that is convenient for the end user, i.e. in a format that is adapted to the user terminal 108 being used by the end user. If the user terminal 108 is a high power personal computer, then the transaction proxy system 106 may be omitted and the user terminal 108 could communication directly with the merchant system 102. However, when the user terminal 108 has certain limitations (e.g. low processing ability, small display size, or low download speed), then use of the transaction proxy system 106 can make performance of the transaction easier and quicker.

Figure 3B schematically illustrates a data flow and method by which the user terminal 08 and the merchant system 102 may communicate, as part of performing (or carrying out or processing) a transaction according to an embodiment of the invention. Figure 3B is the same as figure 3A except that the processing performed by the transaction proxy system 106 at the step S302 and/or the step S310 involves identifying (or testing or determining) whether a particular stage of the transaction has been reached. If the transaction proxy system 106 identifies that a particular stage of the transaction has been reached (be that the start of the stage or a point further along during the stage), then processing continues at a step A, as shall be described with reference to figures 3C and 3D below. In other words, if the transaction proxy system 106 detects that the next step in the transaction is of a predetermined type, then processing continues at a step A.

Having the transaction proxy server 106 being the entity that performs this test means that the user terminal 108 does not need to perform this test, which is advantageous for user terminals 108 that have low processing capabilities.

Additionally, it is easier to adapt to changes a merchant makes in the procedures and phases for a transaction by having the transaction proxy server 106 being the entity that performs this test.

As discussed above, performance of a transaction may involve carrying out a sequence or series of different stages (or steps of phases), such as: login -» select goods→ provide delivery details→ provide payment details→ view a transaction summary -» complete the transaction. A phase may relate to an individual webpage 14 provided by the merchant system 102 or an individual webpage 118 provided by the finance system 04. The end user may progress through these stages to complete the transaction, but may also go back to previously performed stages to alter various details and may even abort the transaction during one of the stages.

Some of these stages may involve the transfer of sensitive (or security) information between the user terminal 108 and another system which is to be involved in that particular stage - i.e. they are a "sensitive" type of step in the transaction. This other system could be, for example, the merchant system 102 or the finance system 104 or, indeed, some other system. The sensitive information could include, for example, one or more of: a password; details of a credit card (e.g. card numbers, expiry dates, etc.); details of a debit card (e.g. card numbers, expiry dates, etc.); details of an account of the end user (e.g. account numbers, sort codes, etc.); personal identification information about the end user (e.g. login-ID, date of birth, billing address, mother's maiden name, etc.), or other information (e.g. home address) that may be used in order to verify the entities involved and/or to authorise and complete a payment for the transaction. In other words, the sensitive information is information that the end user would not wish to be made public, or which the merchant of financial institution would not wish made available to the transaction proxy system 106, or which a third party could use to impersonate the end user (possibly to the detriment of the end user), or which a third party could use to identify and possibly use (or misuse) an account of the end user. Embodiments of the invention aim to improve the security of carrying out particular/predetermined stages of a transaction (such as the ones that involve transferring sensitive information).

At the step S302 or S310, the transaction proxy system 106 may identify that a particular stage has been reached (or is being performed) by identifying that transaction data that the transaction proxy system 106 has received (from the merchant system 102 and/or the user terminal 108) relates to the input of, or a request for the user terminal 108 to provide, sensitive information.

The transaction proxy system 106 may identify that such a particular stage has been reached by identifying that a webpage, forming part of the transaction data received at the transaction proxy system 106, has a predetermined URL. The transaction proxy system 106 may therefore comprise a database of URLs, and the transaction proxy system 106 may be arranged, as part of the step S302 or S3 0, to determine whether transaction data that it receives is related to any of the URLs in the database, e.g. whether the transaction data comprises a webpage having a URL that corresponds to a URL stored in the database.

The transaction proxy system 106 may identify that such a particular stage has been reached by identifying that a webpage, forming part of the transaction data received at the transaction proxy system 106, contains predetermined content, such as one or more keywords or terms that would indicate that the particular stage has been reached, e.g. the keywords "password", "login", "account number", "card number", etc. The transaction proxy system 106 may therefore comprise a database of keywords, and the transaction proxy system 106 may be arranged, as part of the step S302 or S310, to determine whether transaction data that it receives contains one or more of the keywords from the database.

Examples of the stages involving sensitive information could include one or more of:

EG1. The end user logging in to an account held by the merchant system 102. This particular stage could start when the merchant system 102 sends, as transaction data D3 at the step S308, a login webpage 114 to the transaction proxy system 106 for provision to the user terminal 108. Alternatively, the start of this particular stage could be when the transaction proxy system 106 detects that the user terminal 108 requires (or has requested) a login webpage, and the transaction proxy system 106 determines, at the processing step S302, that it already has a login webpage available (e.g. one has been cached) for provision directly to the user terminal 108 without having to go via the merchant system 102.

EG2. The end user providing payment details (such as credit/debit card details, bank account details, etc.) to the merchant system 102. This particular stage could start when the merchant system 102 sends, as transaction data D3 at the step S308, a "payment details" webpage 114 to the transaction proxy system 106 for provision to the user terminal 108. Alternatively, the start of this particular stage could be when the transaction proxy system 106 detects that the user terminal 108 requires (or has requested) a "payment details" webpage, and the transaction proxy system 106 determines, at the processing step S302, that it already has a "payment details" webpage available (e.g. one has been cached) for provision directly to the user terminal 108 without having to go via the merchant system 102.

EG3. The end user providing authentication information (such as name, password, credit/debit card details, bank account details, etc.) to the finance system 104 so that the finance system 104 can authenticate that the end user is the correct person (i.e. the end user is indeed who he is claiming to be and/or is in possession of a valid debit/credit card). The particular stage could start when the merchant system 102 sends, as transaction data D3 at the step S308, an "authentication" webpage 114 to the transaction proxy system 106 for provision to the user terminal 108. Alternatively, the start of this particular stage could be when the transaction proxy system 106 detects that the user terminal 108 requires (or has requested) an "authentication" webpage, and the transaction proxy system 106 determines, at the processing step S302, that it already has an "authentication" webpage available (e.g. one has been cached) for provision directly to the user terminal 108 without having to go via the merchant system 102.

It will be appreciated that other security/sensitive stages could form part of the transaction.

Figure 3C schematically illustrates a data flow and method by which the user terminal 108 and the merchant system 102 may communicate, as part of performing (or carrying out or processing) a transaction according to an embodiment of the invention, in particular when the transaction proxy system 106 has identified that a particular stage (which is to involve transferring data between the user terminal 108 and the merchant system 102) of the transaction has been reached. This is relevant to example stages EG1 and EG2 above, but may be relevant to other types of transaction stage too. In summary, the processing of figure 3C involves the transaction proxy system 106 indicating to the user terminal 108 that this particular stage of the transaction has been reached. In particular, this indication indicates to the user terminal 108 that transaction data necessary for this particular stage should be transferred directly between the user terminal 108 and a particular system (which is the merchant system 102 in this case). Upon receiving the indication, any transaction data necessary for this particular stage is transferred directly between the user terminal 108 and the merchant system 102, i.e. the transaction data for this particular stage is not routed via the transaction proxy system 106 so that the transaction proxy system 106 does not have exposure to, and cannot process, copy, etc. any of the transaction data for this particular stage. In this way, the security of the transaction is improved (as any vulnerabilities introduced by virtue of using the transaction proxy system 106 are removed).

When the transaction proxy system 106 has identified (at the step S302 or S310 as appropriate - see figure 3B) that a particular stage (which is to involve transferring data between the user terminal 108 and the merchant system 102) of the transaction has been reached, then the processing step S302 or S310 as appropriate involves the transaction proxy system 106 forming transaction data D5 instead of transaction data D4. The transaction data D5 comprises: (a) a predetermined flag (or some other kind of indicator) that indicates to the user terminal 108 that a stage in the transaction has been reached at which the user terminal 108 should communicate directly with the merchant system 102; (b) data identifying the merchant system 102 so that the user terminal 108 will know where and how to send or post data to the merchant system 102; (c) webpage data (e.g. HTML) of a webpage to be displayed at the user terminal 108; and (d) any other relevant information, if any (such as HTTP referrer headers, etc.). Data (b) above may be in the form of a URL identifying a webpage 114 of the merchant system 102 to which the user terminal 108 should post transaction data. The webpage forming data (c) above may be a webpage for the end user to input sensitive information that is to be passed to the merchant system 102. This webpage could be, for example, a version of a "login" webpage 114 or a "payment" webpage 1 4 that the transaction proxy server 106 received from the merchant system 102 as transaction data D3 at the step S308 and which the transaction proxy server 106 has possibly amended/proxified as discussed above. The above data forming the transaction data D5 may be packaged together, for example, as an XML file/structure.

At a step S330, the transaction proxy system 106 forwards (or sends or posts) the transaction data D5 to the user terminal 108.

At a step S332, the user terminal 108 receives the transaction data D5. The user terminal 108 may then perform some processing on the received transaction data D5, such as displaying/outputting the webpage contained in the transaction data D5 to the end user and/or allowing the end user to interact with this webpage (e.g. to input the sensitive information).

Moreover, at the step S332, the user terminal 108 detects the flag in the transaction data D5 and determines that the next transaction data that the user terminal 108 is to send/post should not be sent to merchant system 102 via the transaction proxy system 106 but should, instead, be sent directly to the merchant system 102.

Once the processing step S332 has been completed (for example when the user has pressed a "submit" or "next" button on the webpage), then at a step S334 the user terminal 108 forwards (or sends or posts) the completed webpage as transaction data D6 to the merchant system 102. As mentioned, this transfer of transaction data D6 does not involve the transaction proxy system 106, i.e. is directly from the user terminal 108 to the merchant system 102. This is preferably performed by using appropriate security measures (such as using HTTPS and possibly using encryption of the transaction data D6 itself).

At a step S336, the merchant system 102 receives the transaction data D6. The merchant system 102 may then perform some processing on the received transaction data D6. This processing may involve any processing necessary for the current stage of the transaction being performed, e.g. identifying relevant webpages 114 to provide to the user terminal 108, accessing account data of the end user who is operating the user terminal 108, verifying account data, verifying debit/credit card details, etc.

The merchant system 102 generates transaction data D7 based on, and in response to, the transaction data D6 that it received. The response transaction data D7 could be, for example, a webpage 14 that informs the user of the success/failure of the current stage of the transaction (e.g. login success/failure, authentication success/failure, etc.) The response transaction data D7 could be, for example, a webpage 114 that requires further input from the end user as part of the current particular stage of the transaction (and which the transaction proxy system 106 would detect as being part of the current particular stage). Preferably the transaction data D7 does not contain any sensitive information.

At a step S338, the merchant system 102 forwards (or sends or posts) transaction data D7 to the user terminal 108. As mentioned, this transfer of transaction data D7 does not involve the transaction proxy system 106, i.e. is directly from the merchant system 102 to the user terminal 108.

At a step S340, the user terminal 102 forwards the transaction data D7 to the transaction proxy system 106. Whilst this may involve some re-packaging of the transaction data D7 to form new transaction data D7* which is sent to the transaction proxy system 106, the user terminal 108 does not perform any substantial processing on the transaction data D7. Instead, processing continues with the transaction proxy system 106 performing its processing step S310 in respect of the transaction data D7* that it has just received (i.e. any proxification of the received transaction data D7 ^* , testing whether the received transaction data D7* relates to a particular phase of the transaction, etc.).

In this way, it is the user terminal 08 that submits the sensitive

information to the merchant system 102, rather than having the transaction proxy system 106 receive and then submit the sensitive information as a proxy of the user terminal 108. In one embodiment, during the initial processing shown in figure 3A, the transaction proxy system 106 and the merchant system 102 will have established a communications session S1 via which they communicate transaction data with each other. Similarly, the transaction proxy system 106 and the user terminal 108 will have established a communications session S2 via which they

communicate transaction data with each other. When the transaction proxy system 106 detects that the above processing of figure 3C is to be performed, then the transaction data D5 sent from the transaction proxy system 106 to the user terminal 108 may identify communication session S1 to the user terminal 108 (e.g. by providing session information via cookies). The user terminal 08 may then use the same communication session S1 , taking the place of the transaction proxy system 06, for the purposes of communicating the transaction data D6 and D7 at the steps S334 and S338. This makes the communications more seamless and efficient.

Figure 3D schematically illustrates a data flow and method by which the user terminal 108 and the finance system 104 may communicate, as part of performing (or carrying out or processing) a transaction according to an embodiment of the invention, in particular when the transaction proxy system 106 has identified that a particular stage (which is to involve transferring data between the user terminal 108 and the finance system 104) of the transaction has been reached. This is relevant to example stage EG3 above, but may be relevant to other types of transaction stage too.

In summary, the processing of figure 3D involves the transaction proxy system 106 indicating to the user terminal 108 that this particular stage of the transaction has been reached. In particular, this indication indicates to the user terminal 108 that transaction data necessary for this particular stage should be transferred directly between the user terminal 108 and a particular system (which is the finance system 104 in this case). Upon receiving the indication, any transaction data necessary for this particular stage is transferred directly between the user terminal 08 and the finance system 104, i.e. the transaction data for this particular stage is not routed via the transaction proxy system 106 so that the transaction proxy system 106 does not have exposure to, and cannot process, copy, etc. any of the transaction data for this particular stage. In this way, the security of the transaction is improved (as any vulnerabilities introduced by virtue of using the transaction proxy system 106 are removed).

When the transaction proxy system 106 has identified (at the step S302 or S310 as appropriate - see figure 3B) that a particular stage (which is to involve transferring data between the user terminal 108 and the finance system 104) of the transaction has been reached, then the processing step S302 or S310 as appropriate involves the transaction proxy system 106 forming transaction data D8 instead of transaction data D4. The transaction data D8 comprises: (a) a predetermined flag (or some other kind of indicator) that indicates to the user terminal 108 that a stage in the transaction has been reached at which the user terminal 108 should communicate directly with the finance system 104; (b) data identifying the finance system 104 so that the user terminal 108 will know where and how to send or post data to the finance system 104; (c) webpage data (e.g. HTML) of a webpage to be displayed at the user terminal 108; and (d) any other relevant information, if any (such as HTTP referrer headers, etc.). Data (b) above may be in the form of a URL identifying a webpage 118 of the finance system 104 to which the user terminal 108 should post transaction data. The webpage forming data (c) above may be a webpage for the end user to input sensitive information that is to be passed to the finance system 104. This webpage could be, for example, a version of an "authentication" webpage 114 that the

transaction proxy server 106 received from the merchant system 102 as transaction data D3 at the step S308 and which the transaction proxy server 106 has possibly amended/proxified as discussed above. Such an "authentication" webpage 114 could be built by the merchant system 102 by embedding an authentication webpage 118 that the finance system 104 has provided to the merchant system 102 into a template webpage of the merchant system 102. This embedded webpage 118 (which may form data (c) above) may also contain details for data (b) above. The above data forming the transaction data D8 may be packaged together, for example, as an XML file/structure.

At a step S370, the transaction proxy system 106 forwards (or sends or posts) the transaction data D8 to the user terminal 108.

At a step S372, the user terminal 108 receives the transaction data D8. The user terminal 108 may then perform some processing on the received transaction data D8, such as displaying/outputting the webpage contained in the transaction data D8 to the end user and/or allowing the end user to interact with this webpage (e.g. to input the sensitive information).

Moreover, at the step S372, the user terminal 108 detects the flag in the transaction data D8 and determines that the next transaction data that the user terminal 108 is to send/post should not be sent to merchant system 102 via the transaction proxy system 106 but should, instead, be sent directly to the finance system 104.

Once the processing step S372 has been completed (for example when the user has pressed a "submit" or "next" button on the webpage), then at a step S374 the user terminal 108 forwards (or sends or posts) the completed webpage as transaction data D9 to the finance system 104. As mentioned, this transfer of transaction data D9 does not involve the transaction proxy system 106, i.e. is directly from the user terminal 108 to the finance system 104. This is preferably performed by using appropriate security measures (such as using HTTPS and possibly using encryption of the transaction data D9 itself).

At a step S376, the finance system 104 receives the transaction data D9. The finance system 104 may then perform some processing on the received transaction data D9. This processing may involve any processing necessary for the current stage of the transaction being performed. In particular, this processing may involve authenticating the data that the end user has provided via the received webpage (transaction data D9), e.g. checking that the user has provided a password, account details, card details, etc. that are all valid and correspond to each other. In this way, the finance system can validate that the end user is who he claims to be and/or is in physical possession of a credit/debit card and/or has provided genuine account/card numbers etc.

The finance system 104 generates transaction data D10 based on, and in response to, the transaction data D9 that it received. The response transaction data D10 could be, for example, a webpage 118 that informs the user of the success/failure of the current stage of the transaction (e.g. authentication success/failure, etc.) The response transaction data D10 could be, for example, a webpage 114 that requires further input from the end user as part of the current particular stage of the transaction, e.g. to set up a new password (and which the transaction proxy system 106 would detect as being part of the current particular stage). Preferably the transaction data D10 does not contain any sensitive information.

At a step S378, the finance system 104 forwards (or sends or posts) transaction data D10 to the user terminal 08. As mentioned, this transfer of transaction data D10 does not involve the transaction proxy system 106, i.e. is directly from the finance system 104 to the user terminal 108.

At a step S380, the user terminal 102 forwards the transaction data D10 to the transaction proxy system 06. Whilst this may involve some re-packaging of the transaction data D10 to form new transaction data D10 ^* which is sent to the transaction proxy system 106, the user terminal 108 does not perform any substantial processing on the transaction data D10. Instead, processing continues with the transaction proxy system 106 performing its processing step S310 in respect of the transaction data D10* that it has just received (i.e. any proxification of the received transaction data D10*, testing whether the received transaction data D10 ^* relates to a particular phase of the transaction, etc.).

In this way, it is the user terminal 108 that submits the sensitive

information to the finance system 104, rather than having the transaction proxy system 106 receive and then submit the sensitive information as a proxy of the user terminal 108.

As an example of a transaction using the above-described methods: • An end user may use the user terminal 108 to instigate and progress a transaction with the merchant system 102 via the transaction proxy system 106. This may involve (a) the merchant system 102 providing the user terminal 108 with one or more webpages 114 that contain details of products and/or services that the merchant has to offer and (b) the user terminal 108 providing the merchant system 102 with completed webpages that contain details of the products and/or services that the end user would like the merchant to provide. The above transfer of webpages between the merchant system 102 and the user terminal 108 may be performed via the method shown in figures 3A and 3B above - in figure 3B, the webpages 108 do not relate to sensitive information and hence the steps S302 and S310 do not move the processing to the step A, i.e. the transfer of this transaction data is performed via the transaction proxy system 106.

• Once the end user has informed the merchant of the desired products and/or services, then the merchant system 102 may provide a payment details webpage 114 for the end user to input various details about a payment mechanism for the transaction, such as credit/debit card details, bank account details, delivery address, card holder address, expiry date of a card, etc. This webpage 114 is provided to the transaction proxy server 106 which, at the step S310, detects that a particular phase in the transaction has been reached (i.e. a payment phase). In other words, at the step S310, the transaction proxy server 106 detects that a stage in the transaction has been reached at which the user terminal 108 will need to transmit sensitive information to the merchant system 102. Consequently, processing moves to step A of figure 3C. The payment information is then transmitted directly from the user terminal 108 to the merchant system 102. The merchant system 102 may reply with another payment information webpage 114 - this will be detected when the processing of figure 3C returns to the step S310, so that the processing of figure 3C can be performed in respect of this next payment information webpage 114. Alternatively, the merchant system 102 may reply with a webpage that does not involve sensitive information - this will be detected when the processing of figure 3C returns to the step S310, so that the processing of figures 3A and 3B can be repeated in respect of this next webpage 114.

• At some stage during the transaction, the merchant system 102 may provide an authentication webpage 114 for the end user to input various details so that his identity can be verified/authenticated and/or so that his physical possession of a debit/credit card can be verified/authenticated. This webpage 114 is provided to the transaction proxy server 106 which, at the step S310, detects that a particular phase in the transaction has been reached (i.e. an authentication phase). In other words, at the step S310, the transaction proxy server 106 detects that a stage in the transaction has been reached at which the user terminal 108 will need to transmit sensitive information to the finance system 104. Consequently, processing moves to step A of figure 3D. The authentication information is then transmitted directly from the user terminal 108 to the finance system 104. The finance system 104 may reply with another authentication webpage 118 - this will be detected when the processing of figure 3D returns to the step S310, so that the processing of figure 3D can be performed in respect of this next authentication webpage 118. Alternatively, the finance system 104 may reply with a webpage 118 that does not involve sensitive information - this will be detected when the processing of figure 3D returns to the step S310, so that the processing of figures 3A and 3B can be repeated in respect of this next webpage 118. It will be appreciated that, insofar as embodiments of the invention are implemented by a computer program, then a storage medium and a transmission medium carrying the computer program form aspects of the invention. The computer program may have one or more program instructions, or program code, which, when executed by a computer carries out an embodiment of the invention. The term "program," as used herein, may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, an object method, an object implementation, an executable

application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and/or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM or a BluRay disc), or a memory (such as a ROM, a RAM, EEPROM, EPROM, Flash memory or a portable/removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.