WO2012032291A1 - Procédé de traitement de transaction - Google Patents

Procédé de traitement de transaction Download PDF

Info

Publication number
WO2012032291A1
WO2012032291A1 PCT/GB2011/001309 GB2011001309W WO2012032291A1 WO 2012032291 A1 WO2012032291 A1 WO 2012032291A1 GB 2011001309 W GB2011001309 W GB 2011001309W WO 2012032291 A1 WO2012032291 A1 WO 2012032291A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
transaction data
client device
proxy
data
Prior art date
Application number
PCT/GB2011/001309
Other languages
English (en)
Inventor
Dominic John Keen
Zahid Ali Younis
Original Assignee
Mobank Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mobank Limited filed Critical Mobank Limited
Priority to EP11758537.2A priority Critical patent/EP2614471A1/fr
Publication of WO2012032291A1 publication Critical patent/WO2012032291A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals

Definitions

  • 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.
  • 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.
  • a payment mechanism such as credit or debit card information or bank account information
  • a method of operating a proxy to facilitate performing a transaction between a client device and a merchant system 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.
  • a method of operating a client device to perform a transaction between the client device and a merchant system 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.
  • 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.
  • 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.
  • the first and/or second transaction data may comprise one or more webpages.
  • 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.
  • a method for performing a transaction between a client device and a merchant system 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.
  • a proxy system comprising a processor, the processor being arranged to carry out a method of operating a proxy as set out above.
  • a device comprising a processor, the processor being arranged to carry out a method of operating a client device as set out above.
  • a computer program which, when executed by a processor, carries out any one of the above methods.
  • a data carrying medium carrying such a computer program.
  • the medium may be a storage medium or a transmission medium.
  • Figure 1 schematically illustrates a system according to an embodiment of the invention
  • FIG. 2 schematically illustrates an example computer system for use in embodiments of the invention.
  • FIGS 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.
  • 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).
  • 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.
  • 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.
  • 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
  • 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.
  • Figure 1 schematically illustrates a system 100 according to an
  • 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.
  • 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.
  • 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.
  • 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.
  • the finance system 104 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).
  • financial institutions or organisations such as banks, building societies, credit card companies, etc.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • mobile devices such as mobile telephones or laptops with mobile connectivity
  • 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.
  • the transaction proxy system 106 may receive data from the merchant system 102, where this data is intended for 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
  • 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.
  • processing/operations performed may be similar to those described above.
  • 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.
  • 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.
  • 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.
  • finance systems 104 e.g.
  • 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.
  • FIG. 1 it will be appreciated that some of the systems illustrated in figure 1 could be combined or integrated into a single system.
  • 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.
  • 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 is a computer 202.
  • a storage medium 204 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
  • 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.
  • 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.
  • 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.
  • 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.
  • network interface 216 provides functionality for the computer 202 to download data from and/or upload data to one or more data
  • 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.
  • a user terminal 108 is a mobile telephone
  • 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
  • the network interface 216 could be a telecommunications network interface (with antenna, modulator/demodulator, etc. as is well known in this field of technology).
  • 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.
  • 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.
  • 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.
  • custom code such as Java applets
  • 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.
  • the performance of the transaction makes use of a transaction proxy system 106 as has been described above.
  • the user terminal 108 forwards (or sends or posts) transaction data D1 to the transaction proxy system 106.
  • 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
  • the transaction data D2 may be the same as the transaction data D1.
  • the transaction proxy system 106 then forwards (or sends or posts) the transaction data D2 to the merchant system 102.
  • 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).
  • 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.
  • 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
  • the merchant system 102 may, as part of the processing step S306, communicate with the finance system 104.
  • 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).
  • the merchant system 102 forwards (or sends or posts) transaction data D3 to the transaction proxy system 106.
  • 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.
  • the transaction proxy system 106 then forwards (or sends or posts) the transaction data D4 to the user terminal 108.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data D1 , D2, D3 and D4 will often comprise webpage data (encoded, for example, as HTML data).
  • 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.
  • 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.
  • 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.
  • 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.
  • the transaction proxy system 106 then forwards the request D2 to the merchant system 102.
  • 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.
  • 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);
  • 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.
  • the transaction proxy system 106 then forwards (or sends or posts) the replacement webpage D4 to the user terminal 108.
  • 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.
  • the transaction proxy system 106 receives the
  • 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).
  • the transaction proxy system 106 then forwards the replacement webpage D2 to the merchant system 102.
  • 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.
  • 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).
  • 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.
  • 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.
  • the processing may jump straight from the step S302 to the step S312 (as indicated by a dashed arrow in figure 3A).
  • 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.
  • 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.
  • 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.
  • 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.
  • the user terminal 108 has certain limitations (e.g. low processing ability, small display size, or low download speed)
  • 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.
  • 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.
  • 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).
  • 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.
  • stages involving sensitive information could include one or more of:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a particular stage which is to involve transferring data between the user terminal 108 and the merchant system 102
  • 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.
  • 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).
  • a particular system which is the merchant system 102 in this case.
  • 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).
  • 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.
  • the transaction proxy system 106 forwards (or sends or posts) the transaction data D5 to the user terminal 108.
  • 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).
  • 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.
  • step S334 the user terminal 108 forwards (or sends or posts) the completed webpage as transaction data D6 to the merchant system 102.
  • 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).
  • 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).
  • the transaction data D7 does not contain any sensitive information.
  • the merchant system 102 forwards (or sends or posts) transaction data D7 to the user terminal 108.
  • 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.
  • 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.).
  • 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.
  • the transaction proxy system 106 and the user terminal 108 will have established a communications session S2 via which they
  • 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.
  • stage EG3 which is to involve transferring data between the user terminal 108 and the finance system 104
  • 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.
  • 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).
  • a particular system which is the finance system 104 in this case.
  • 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.
  • the security of the transaction is improved (as any vulnerabilities introduced by virtue of using the transaction proxy system 106 are removed).
  • 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.
  • the transaction proxy system 106 forwards (or sends or posts) the transaction data D8 to the user terminal 108.
  • 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).
  • 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.
  • step S374 the user terminal 108 forwards (or sends or posts) the completed webpage as transaction data D9 to the finance system 104.
  • 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).
  • 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.
  • 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.
  • 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).
  • the transaction data D10 does not contain any sensitive information.
  • the finance system 104 forwards (or sends or posts) transaction data D10 to the user terminal 08.
  • 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.
  • 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.).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • program 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
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé permettant de faire fonctionner un serveur mandataire pour faciliter l'exécution d'une transaction entre un dispositif client et un système commerçant. Selon ledit procédé, le serveur mandataire exécute les étapes consistant à : recevoir des premières données de transaction provenant du dispositif client; recevoir des premières données de transaction provenant du système commerçant; transférer les premières données de transaction reçues du dispositif client vers le système commerçant; transférer les premières données de transaction reçues du système commerçant vers le dispositif client; identifier qu'un stade particulier de la transaction a été atteint, le stade particulier impliquant un transfert des secondes données de transaction entre le dispositif client et un système particulier; et en réponse à l'identification que le stade particulier de la transaction a été atteint, indiquer au dispositif client que les secondes données de transaction doivent être transférées directement entre le dispositif client et le système particulier.
PCT/GB2011/001309 2010-09-06 2011-09-06 Procédé de traitement de transaction WO2012032291A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11758537.2A EP2614471A1 (fr) 2010-09-06 2011-09-06 Procédé de traitement de transaction

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1014784.1A GB2483633A (en) 2010-09-06 2010-09-06 Transaction processing using a proxy
GB1014784.1 2010-09-06

Publications (1)

Publication Number Publication Date
WO2012032291A1 true WO2012032291A1 (fr) 2012-03-15

Family

ID=43037376

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2011/001309 WO2012032291A1 (fr) 2010-09-06 2011-09-06 Procédé de traitement de transaction

Country Status (3)

Country Link
EP (1) EP2614471A1 (fr)
GB (1) GB2483633A (fr)
WO (1) WO2012032291A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000039666A1 (fr) * 1998-12-28 2000-07-06 Spyglass, Inc. Procede et systeme servant a transformer le contenu de donnees electroniques pour des dispositifs sans fil
US20010007098A1 (en) * 1999-12-30 2001-07-05 Hinrichs Susan E. Gift certificate award and exchange program and method
EP1168264A2 (fr) * 2000-06-30 2002-01-02 Motorola, Inc. Système de porte-monnaie électronique reposant sur un serveur
US20040170155A1 (en) * 2001-07-12 2004-09-02 Omar Salim H. System and method for providing remote data access for a mobile communication device
WO2004092979A2 (fr) * 2003-04-11 2004-10-28 Nokia, Inc. Saisie de texte assistee
US20060129905A1 (en) * 2004-12-15 2006-06-15 Sap Ag Acquisition of user data over a network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2915001A (en) * 1999-12-30 2001-07-16 Ecatalystone.Com, Inc. Methods for managing transactions over the internet by proxy and with single-usefinancial instruments
GB2466676A (en) * 2009-01-06 2010-07-07 Visa Europe Ltd A method of processing payment authorisation requests

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000039666A1 (fr) * 1998-12-28 2000-07-06 Spyglass, Inc. Procede et systeme servant a transformer le contenu de donnees electroniques pour des dispositifs sans fil
US20010007098A1 (en) * 1999-12-30 2001-07-05 Hinrichs Susan E. Gift certificate award and exchange program and method
EP1168264A2 (fr) * 2000-06-30 2002-01-02 Motorola, Inc. Système de porte-monnaie électronique reposant sur un serveur
US20040170155A1 (en) * 2001-07-12 2004-09-02 Omar Salim H. System and method for providing remote data access for a mobile communication device
WO2004092979A2 (fr) * 2003-04-11 2004-10-28 Nokia, Inc. Saisie de texte assistee
US20060129905A1 (en) * 2004-12-15 2006-06-15 Sap Ag Acquisition of user data over a network

Also Published As

Publication number Publication date
GB201014784D0 (en) 2010-10-20
GB2483633A (en) 2012-03-21
EP2614471A1 (fr) 2013-07-17

Similar Documents

Publication Publication Date Title
US11222312B2 (en) Method and system for a secure registration
US11276045B2 (en) Vendor token generator
US10089617B2 (en) Systems and methods for facilitating card present transactions
JP5439322B2 (ja) 電子取引を行うための方法および装置
US8498940B2 (en) Unified identity verification
US20170061429A1 (en) Automated application programming interface (api) system and method
US8707048B2 (en) Dynamic pattern insertion layer
EP3859646A1 (fr) Portefeuille ouvert pour transactions électroniques
RU2252451C2 (ru) Способ проведения трансакций, компьютеризованный способ защиты сетевого сервера, трансакционная система, сервер электронного бумажника, компьютеризованный способ выполнения онлайновых покупок (варианты) и компьютеризованный способ контроля доступа
US11257059B2 (en) Keyboard application with third party engagement selectable items
KR101618675B1 (ko) 보안 지불 인스트럭션 시스템
TW201543386A (zh) 一種電子帳戶的操作方法、支付頁面的展示方法及裝置
WO2005114899A2 (fr) Traitement securise de payements pour des transactions en ligne
US20140304171A1 (en) Method and system to facilitate social ecommerce
JP2016076262A (ja) インターネット接続及び対応の端末を介した商業サイトにおける製品又はサービスの決済方法
KR101728163B1 (ko) 무선 통신 네트워크를 통한 카드 결제 서비스 시스템 및 그방법과 카드 결제 서비스 기능을 갖춘 이동통신 단말기
US20130046656A1 (en) Method and System for Navigation Free Online Payment
US20230252463A1 (en) System and method for secure web service access control
TWI653588B (zh) Method of cross-platform payment in mobile devices
WO2012032291A1 (fr) Procédé de traitement de transaction
EP3909001A1 (fr) Système, procédé et produit programme d'ordinateur permettant de personnaliser des fonctions d'un terminal de point de vente
TWI817096B (zh) 一種代碼化掃碼支付系統、方法及電腦可讀媒介
CA3195823A1 (fr) Systeme et methode de controle d'acces securise a un service web
CA3220470A1 (fr) Emission numerique instantanee
KR20140014769A (ko) 결제 서비스 시스템 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11758537

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011758537

Country of ref document: EP