IE20210089U1 - Method of configuring a transaction at a mobile device - Google Patents

Abstract

method of configuring a transaction checkout at a mobile device is provided, comprising the operations of: loading a checkout module and transaction data from a remote terminal; loading a conditional transaction module; processing transaction data with the conditional transaction module; providing at the mobile device, a user With an input choice to either confirm the transaction data to the remote terminal or chance the transaction data; increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful.

Description

Title Method of configuring a transaction at a mobile device Field of the Invention The present invention relates to a configuration oftransactions at a mobile device.

Background to the Invention Physical transaction checkouts are used in most retail environments. An example of such a physical retail environment is shown in Figure 1, in which a customer 101 is shown as having selected an item 102 which he wishes to purchase. The item 102 is habitually presented to a retail staff member 103, who inputs the respective price of the item in a point- of—sale terminal 104, which is a data processing terminal, before requesting payment from customer 101 to complete the transaction. Such payment is effected by the customer 101 with any conventional payment means, such as with cash, a cheque, a voucher or a payment card 105. In the case of a payment card 105, the customer 101 lends the card to the staff member 103 for inputting the details thereof in the POS terminal 104, either by reading the data stored in a magnetic stripe 106 of the card with a magnetic card reader 107 interfaced with POS terminal 104, or reading the data stored in a microprocessor 108 of the card with a chip-and-PIN device 109 interfaced with POS terminal 104, depending on the configuration of the card 105. The terminal 104 then traditionally obtains a remote authorisation for debiting the card account, or is configured to authorise the debiting of the card account locally, whereby the card account ofthe customer 101 is debited with the price of the item 102, the transaction is complete and customer 101 has purchased item 102. The retail store account is eventually credited with the amount debited from the card, minus a commission deducted from the card transaction by financial institutions permitting such card transactions.

The typical constituent parts of data processing terminal 104 are shown in further detail in Figure 2. Terminal 104 includes processing means 201, memory means 202 and 203, goods identification means 204, a modem 205, a data input/output interface 206 and data display means 207, all of which are connected by a data input/output bus 208, over which they communicate and to which further or optional components of terminal 104, such as card readers 107, 109, are similarly linked via |/O interface 206 in order to provide the functionality described in Figure 1.

Memory means 202 includes for instance a Non-Volatile Random Access Memory (NVRAM), which provides non-volatile storage of instructions and data (such as product description and price for product 102) for processing means 201, which is a Central Processing Unit (CPU) such as a general—purpose microprocessor, acting as the main controller of terminal 104. Memory means 203 includes for instance a Random Access Memory (RAM), which is used by CPU 201 at runtime to accumulate transaction data of any given transaction and to temporarily store instructions and/or data for CPU 201 obtained via modem 205. Transaction data of any given transaction comprises for instance the respective prices of multiple products 102 fetched from NVRAM 202 upon each of said products being identified via goods identification means 204, which in the example is a barcode scanner. If a payment card is used to conduct the transaction, transaction data in RAM 203 will also include the card details obtained from either of readers 107 or 109 and transmitted via 110 interface 206.

Terminal communication functionality is provided by modern 205, which provides the interface to the remote terminals 207 of the financial institutions from which card authorisation is sought, or to which batched card transactions are periodically sent for further processing and eventual account debiting and crediting, as described hereinabove.

With respect to the pervasive development of the Internet, virtual transaction checkouts have also become well known, and have become widely used both by physical retail environments such as depicted in Figure 1 to increase their sales without however incurring any real estate expenditure, and by retail stores which are entirely virtual, i.e. which have no traditional, physical presence whatsoever, if only for a warehouse from which to despatch goods, when these are not despatched directly from the manufacturer instead. An example of such a virtual retail environment is shown in Figure 3, in which the customer 101 who is for instance at home, is shown interfacing with a Personal Computer (PC), which is another type of data processing terminal 301. The customer 101 accesses virtual stores via a Wide Area Network (WAN) such as the Internet 302, via an Internet Service Provider 303. The virtual stores are a combination of textual, image, video and/or audio data broadcast under the form of Web pages 304 by other remote terminals 305, and which data is usually stored at said remote terminals 305 in databases of products or services and broadcast therefrom on request. The user requests such broadcasts by providing selection input with a combination of a keyboard 306 and a human/terminal interface such as a conventional mouse 307, the selection amounting to the navigation of network addresses and selection of respective data contents thereof for retrieval and display as said Web pages on a Video Display Unit (VDU) 308 of terminal 301.

When using the Internet to purchase goods or services presented on web pages of a virtual store, a customer will eventually be presented with a web page 304 configured as an online transaction checkout, in which the customer is requested to enter payment details and then confirm the transaction to the remote terminal hosting the virtual store, before physical goods can be despatched or services performed. Such payment details traditionally comprise either particulars of a payment card 105, whereby the processing of the transaction does not differ from the physical transaction described in Figure 1, save for the fact that the card data stored in the stripe 106 or microprocessor 108 is not read but the card particulars (card number, expiry date and the like) are input by customer 101 instead in data fields of the checkout, or particulars of accounts with an online payment system such as Paypal TM or Revolut TM. An online transaction checkout is usually secured against interception of and/or unauthorised access to the payment details for fraudulent use, by a combination of encoding, ciphering and/or encrypting of the distributed data.

The typical constituent parts of data processing terminals 301, 305 are shown in further detailed in Figure 4. Terminal 301 is a computer terminal configured with a data processing unit 301, which is interfaced with data display means (VDU 308), data input means (keyboard 306 and 25 mouse 307) and data input/output means such as WAN connection 302, magnetic data-carrying medium reader/writer 401 and optical data-carrying medium reader/writer 402. 8.

Within data processing unit 301, a central processing unit (CPU) 403, provides task co- ordination and data processing functionality. Instructions and data for the CPU 403 are stored in main memory 404 and a hard disk storage unit 405 facilitates non-volatile storage of data and several sets of instructions for CPU 403. A modern 406 provides a wired connection to the Internet 302. A universal serial bus (IJSB) input/output interface 407 facilitates connection to the keyboard and pointing device 306, 307. All of the above devices are connected to a data input/output bus 408, to which said magnetic data—carrying medium reader/writer 401 and optical data-canying medium reader/writer 402 are also connected. A video adapter 409 receives CPU instructions over said bus 408 for outputting processed data to VDU 308.

A representation of on-line transaction check out 304 as displayed on VDU 308 is provided in Figure 5. The virtual check out typically first comprises a summary 501 of the order particulars, including the products selected by the user 101, the respective quantity of each product or service selected and respective prices. The check out will preferably also include shipping charges if applicable and a total amount payable for the order.

A second portion of the virtual check out will be dedicated to collecting payment details as described hereinbefore and depending upon the store payment choices, will comprise either only a payment card details section 502 or will also include respective network addresses represented as user selectable buttons 503 of virtual financial institutions in a further portion of the virtual checkout. In accordance with the known art of virtual transaction checkouts, the card payment section 502 includes a field 505 for entering the card number, a field 506 for entering the expiry date of the card and a selection of user-selectable buttons 507 respectively corresponding to card schemes for identifying the particular type of payment card (Mastercard, Visa or America Express in the example). Upon entering the details, customer 101 may eventually confirm the order and payment for same with selecting a "pay" button 508. Transaction checkouts as described in relation to Figures 1 and 5 are well- known and the respective functionalities of those checkouts are very much standardised, as their purpose is simply to confirm the particulars of a transaction and the payment for the said transaction. It would be advantageous to configure such transaction checkouts with additional functionality, for instance in order to increase any of the number of customers 101 accessing a physical or virtual retail environment, increase the transaction conversion rate of virtual stores (understood as orders confirmed and paid for, as opposed to orders placed up to a point but never actually confirmed), increasing the revenue of the physical or virtual stores without however increasing stock turnover, or a combination of these advantages, without however requiring the replacement of physical transaction systems (101, 107, 109) with new physical transaction systems, or an extensive re-engineering of the set of instructions underlying the functionality of virtual transaction checkouts, such as checkout 305 in Figure 5. In particular, it would be advantageous to configure such transaction checkouts for use with a mobile device.

Summary of the Invention The present invention provides a method of configuring a transaction checkout at a mobile device, comprising the operations of: i) loading a checkout module and transaction data from a remote terminal; ii) loading a conditional transaction module; iii) processing transaction data with the conditional transaction module; iv) providing at the mobile device, a user with an input choice to either confirm the transaction data to the remote terminal or chance the transaction data; v) increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful.

This is advantageous as it provides that a user may interact with a mobile device when completing a transaction and decide whether to complete the transaction or whether to perform an additional step which could result in a price increase or decrease. Allowing the user to interact via their mobile device provides enhanced flexibility for a range of transactions.

The method may comprise loading the checkout module and transaction data from the remote terminal and loading a conditional transaction module i) via a Bluetooth connection between the mobile device and a point of sale terminal g ii) via an internet connection to a remote web server.

This is advantageous as it provides that a user may connect via Bluetooth to a point of sale terminal which is processing a given transaction. This allows the user to communicate directly via their mobile device with a point of sale terminal and further allows the point of sale terminal to act as a conduit between a mobile device and a remote server. This facilitates a user’s interaction with a transaction for a real life purchase, for example in a shop or other retail environment. In addition, a user may connect via an internet connection to remote web server which is processing a given transaction. This allows the user to communicate directly via their mobile device with a remote server. This facilitates a user’s interaction with a transaction for a on online purchase managed by a remote sever, for example in an online marketplace such as Amazon TM or eBay TM .

The mobile device may be one of a mobile telephone, a tablet device, a wearable device or a watch device. This provides that a user may interact for a transaction across multiple platforms.

The operations i) to v) of the method may be performed via an application pre-installed on the mobile device. This provides for a seamless experience for the user when completing the transaction. With an application pre—installed on a user’s mobile device, this provides for example, that the application can be automatically activated and opened on the mobile device once a transaction is initiated by a user.

The invention further provides a mobile device having processing means, memory means, data input and output means and networking means, the memory means storing instructions which configure the processing means to configure a transaction checkout at the mobile device for performing the operations comprising loading a checkout module and transaction data from a remote terminal; loading a conditional transaction module; processing transaction data with the conditional transaction module; providing a user of the mobile device with an input choice to either confirm the transaction data to the remote terminal or chance the transaction data; increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful.

Brief Description of the Drawings Figure 1 shows a physical retail environment, comprising a physical transaction checkout system having a data processing terminal; Figure 2 shows the constituent parts of the data processing terminal of Figure 1 in further details; Figure 3 provides a representation of a virtual retail environment, comprising a data processing terminal having a video display unit displaying online or virtual transaction checkout Figure 4 shows the constituent parts of the data processing terminal shown in Figure 3; Figure 5 provides a representation of the virtual transaction checkout displayed by the VDU shown in Figure 3; Figure 6 illustrates both a physical retail environment and a virtual environment as respectively shown in Figures 1 and 3, in which a physical transaction checkout and a virtual transaction checkout are configured; Figure 7 details the operational steps according to which either of the physical or virtual transaction checkouts of Figure 6 process transaction data with a conditional transaction module; Figure 8 details the operational steps according to which the virtual transaction checkout of Figure 6 processes transaction data with a conditional transaction module; Figure 9 illustrates the contents of the respective memories of the physical and the virtual transaction checkout of Figure 6 when processing transaction data with the conditional transaction module; Figure 10 illustrates the virtual transaction checkout of Figure 5 configured by the conditional transaction module; Figure 11 shows the virtual transaction checkout of Figure 10, in which the transaction amount has been incremented by the conditional transaction module; Figure 12 shows the virtual transaction checkout of Figure 10, in which the transaction amount has been decremented by the conditional transaction module; Figure 13 provides a representation of a virtual product display configured by the conditional transaction module according to the alternative embodiment described in Figure 8; Figure 14 details the operational steps according to which the conditional transaction module 25 provider terminal shown in Figure 6 processes data Figure 15 illustrates the contents of the memory of the conditional transaction module provider terminal shown in Figures 6 and 12.

Figure 16 illustrates a mobile device being configured via a wireless connection between a mobile device and a point of sale terminal Figure 17 illustrates an application display on a mobile terminal Detailed Description The present invention provides a method of configuring a transaction checkout at a mobile device. Thus a user may interact and engage with a transaction via their mobile device. The method includes loading a checkout module and transaction data from a remote terminal and loading a conditional transaction module onto the mobile device. Once loaded onto the mobile device, the method comprises processing transaction data with the conditional transaction module and providing at the mobile device, a user with an input choice to either confirm the transaction data to the remote terminal or chance the transaction data. This input choice may be displayed to the user on the screen of their mobile device. They may provide their input directly to the device via touchscreen input.

The method further comprises increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful.

The transaction amount may be automatically added to a user’s bank account via a mobile banking application installed on their mobile device.

The method may further comprise loading the checkout module and transaction data from the remote terminal and loading a conditional transaction module via a Bluetooth connection between the mobile device and a point of sale terminal Figure 16 illustrates a mobile device (1601) being configured via a wireless connection, for example a Bluetooth connection, between a mobile device and a point of sale terminal (1602). This provides that data may be seamlessly transferred from a point of sale terminal to a mobile device without the need for a user to specifically request a connection. For example, if the mobile device is set to automatically pair with Bluetooth devices in the vicinity, it will pair with the point of sale terminal upon approach by the user. In this manner, the mobile device may automatically load the checkout module and transaction data from the remote terminal and load a conditional transaction module in order to provide the user with the option to "chance" the transaction. Furthermore, a specific transaction application may be downloaded by a user at an earlier point in time and be pre-installed on the user’s mobile device. In such a scenario, for example, the checkout module and transaction module may be pre-installed on the mobile device.

Furthermore, the application may be linked to user’s payment cards or further to their online banking application. Thus, use of their payment card or their online banking application automatically triggers the transaction application and presents the user with the option to confirm (1701) the transaction or chance (1702) the transaction. (Figure 17) illustrates an application display on a mobile terminal in this manner.

Aspects of typical retail environments in which the present invention may be utilised along with aspects of the checkout module, transaction data and conditional transaction module are now described. Aspects of confirming or chancing a transaction are also further described.

An environment is shown in Figure 6, in which the data processing terminal 104 of the transaction checkout described in Figure 1 is connected to both the data processing terminal 207 of a financial institution and the data processing terminal 601 of a conditional transaction module provider by means of a network connection 603 via a standard PSTN network, with which terminal 104 is interfaced with modern 205. In the same environment, the data processing terminal 301 of a customer 101 accesses any one of a plurality of virtual stores, the respective data for which is stored at a plurality of remote data processing terminals 305, via the Internet 302. Terminal 301 is also network—connected with the terminal 601 of the conditional module provider via the Internet 302.

In the environment depicted in Figure 6, the possibility therefore exists for both terminal 104 of the physical retail environment and the terminal 301 processing and displaying virtual retail environments to send data to terminal 601 and receive data therefrom.

Either of the transaction checkouts are configured by a transaction module to perform the additional functionality of allowing a customer 101 to not only carry out a transaction in a physical or virtual store, but also to part take in a game of chance for decreasing the amount of the transaction in the case of a winning entry or, conversely, increasing the amount of the transaction in the case of a losing entry.

The operational steps according to which either terminal 104 or terminal 301 process data are further detailed in Figure 7. The terminal is initially started, or switched on, at the first step 701. Thereafter, an operating system is loaded into the memory of the terminal at step 702, which configures processing means within the terminal with basic data processing functionality, such as addressing data between the various constituent parts of the terminal over the bus (208, 408), reading and interpreting input data and outputting video data to a display.

A conditional transaction module is then loaded at step 703. In the case of a POS terminal, the CT module may be permanently stored in NVRAM 202 and is loaded substantially at the same time as the operating system of terminal 104. In the case of computer 301, the CT module may either also be loaded at start up or is downloaded from terminal 601 via the Internet 302 whenever the virtual retail environment consulted by the terminal user 101 potentially requires the functionality of the module, as will be described in further details herein below and, in the preferred embodiment, when the online or virtual transaction checkout data is requested form the virtual store terminal 305 and in alternative embodiment, when product data is instead accessed from the said terminal 305.

Transaction parameters may subsequently be entered into the terminal at step 704, which for instance comprise one or many products with respective quantities. In the case of terminal 104, step 704 will for instance involve the successive scanning of the respective bar codes of one or many products brought by customer 101 to the checkout desks depicted in Figure 1. In the context of the virtual retail environment, step 704 will involve the iterative selection by a customer of product data accessed from a virtual store terminal 305, for instance as described in relation to Figures 8 and 13. Upon completing the inputting of transaction parameters, therefore the selection of products or services to purchase, a customer 101 eventually proceeds to a checkout at step 705, at which user parameters are input. Such user parameters preferably include payment details for the transaction and, in the preferred embodiment, payment card details. It will be readily understood by those skilled in the art that the present invention shall not however be limited to payment cards and particularly in the case of virtual transaction checkouts, the use of online payment accounts such as provided by Paypal TM and the like is equally contemplated herein.

A first question is asked at step 706 as to whether the customer 101 wishes to invoke the functionality of the CT module therefore whether the customer 101 wishes to partake in the game of chance to hopefully decrease or otherwise increase the amount of the transaction. If the question of step 706 is answered positively, the terminal broadcasts a request across the network to the terminal 601 of the CT module provider to obtain a decision as to whether the entry is either a winning entry or a losing entry at step 707. The decision is preferably received in return within a very short period of time and at step 708 from terminal 601, the length of time elapsed to receive the response for instance amounting to the latency of the network 302, 603 used to broadcast the request and receive the decision in addition to the time taken to process the request arid broadcast the decision at the CT provider terminal 601.

A second question is therefore asked at step 709, as to whether the decision data received from terminal 601 corresponds to a winning entry. If the question of step 709 is answered negatively, both the CT module data initialised at step 707 when first invoking the CT module and the transaction parameters are up dated at step 710, the transaction amount being incremented by the price data of the user entry and a count of winning attempts is incremented within the CT module data. A question is then asked at step 711, as to whether customer 101 wishes to partake in the game again, whereby if the question of step 711 is answered positively, control returns to step 707, so that a new decision may be requested and received and so on and so forth. Alternatively, the customer 101 does not wish to invoke the functionality of the CT module anymore and, as would be the case if the question of step 709 is answered positively and the decision data identifies a winning entry the CT module data initialised at step 707 arid up dated at step 710 is sent to the CT module provider terminal 601 at step 712 for billing of the appropriate number of entries and further reconciliation of a winning entry with the respective virtual store terminal 305. A question is subsequently asked at step 701 as would be directly asked if the customer 101 chooses to invoke the CT module at the question of step 706, as to whether the customer 101 now wishes to complete the transaction. A customer 101 may choose not to complete the transaction for any number to of reasons, either in refuses to sign the sales slip or is unable to remember the personal identification number for the card) or the virtual retail environment (for instance the user in the end decides not to go ahead with the order, particularly if a large number of attempts to obtain a winning decision have been undertaken and the increased transaction amount is more than the customer is willing to pay). If the question of step 713 is answered negatively, then the customer 101 may still choose to input transaction parameters in the same or in a new order, in which case control returns to step 704, or may choose to leave the physical retail environment of Figure 1 or access product data of a different virtual store of another virtual store server 305 or any other task, whereby a further operational step shown at 714 may vary.

Alternatively, the customer 101 confirms the transaction at step 715 and a final question is asked at step 716, as to whether the customer 101 wishes to carry out a further transaction with terminal 301, or another customer 101 is queuing for a further transaction at P08 |. terminal 104 at step 716. If the question at step 716 is answered positively, control returns to step 714 as previously described. In the alternative, the terminal is eventually switched off at step 717.

The operational steps according to which data processing terminal 301 processes data with the CT module according to an alternative embodiment are further detailed in Figure 8, in which the terminal is again started at step 701 and the operating system of the terminal is again loaded at step 702.

Alternatively, customer 101 does not input transaction parameters at step 704 but instead accesses product data from any one virtual store terminal 305 at step 801.

Product data may be broadcast by the said any one of virtual store terminals 305 as a web page 304 including any textual, graphical and or audio data and may include a user- selectable button for adding the product to a virtual shopping cart, i.e. inputting transaction parameters according to step 704. Alternatively, product data may be broadcast by a search engine such as Google TM under the form of a listing of URLs (Uniform Resource Locators) which are user-selectable representations of the respective network addresses of data stored at any one of the said virtual store serves 305 and related to a product which customer 101 is interested in locating and possibly purchasing.

Alternatively, upon accessing the virtual store page 304 containing the product data accessed at step 801, or upon receiving the network address of same in a URL listing provided by a search engine as described immediately above, the CT module is loaded as per step 703 and a user-selectable representation of the module functionality is generated for output to the display 308 as part of the web page 304 also output to the display 308.

The question of step 706, as to whether potential customer 101 wishes to invoke the functionality of the CT module is next asked, whereby the potential customer 101 is offered the chance to try to win the product accessed at step 801 without however having to initiate a transaction procedure, for instance with inputting transaction parameters according to step 704 and so on and so forth. Therefore, if the question of step 706 is answered positively, the user inputs user parameters at step 802 as he would according to step 705 in the preferred embodiment, so that payment details may again be initialised as part of the CT module data at step 707, when a request for a decision is again broadcast to the terminal 601 of the CT module provider. Process steps 707 -712 are thereafter performed as hereinbefore described and upon the potential customer 101 deciding not to invoke the functionality of the CT module anymore and answer the question of step 711 negatively, and the CT module data being sent back to the terminal 601 a question is asked at step 803, as to whether the potential customer 101 now wishes to access new product data, of the same virtual store for another. lfthe question at 803 is answered positively, control returns to step 801 and so on and so forth.

Alternatively the question of step 803 is answered negatively and the user is asked at step 804, as to whether the product data accessed at step 801 should be selected for purchase, and therefore transaction parameters input, at the nominal price at which the virtual store offers the product for sale. If the question of step 804 is answered positively, then transaction parameters are input according to step 704 and the reminder of the transaction process conforms to the previously described steps 705-716. The question of step 716 may eventually be answered positively, so that in the alternative embodiment, control returns to the question of step 804. Alternatively, the question of step 716 or the question of step 804 is answered negatively, whereby the terminal may eventually be switched off at step 717, as previously described.

The memory means 202, 203 of POS terminal 104 and the memory 404 of terminal 301 are both shown in Figure 9 and the respective contents thereof are respectively illustrated. For the purpose of not unnecessarily obscuring the present description, the memories 202 and 203 of POS terminal 104 are represented as a single memory in Figure 9, since the respective contents thereof maybe accessed by CPU 201 at any time during run time. The memory therefore includes an operating system 901, a bar code reading/scanning application 902, product data 903 that may comprise product description and/or part number and unit price, a communication and batching application 904, used to communicate payment card transaction data to the terminal 207 of financial institutions once or many times a day for account reconciliation as described in relation to Figure 1. The memory also includes the conditional transaction module 905, the respective module data for which is shown at 906, in addition to transaction data at 907.

The memory 404 of terminal 301 also includes an operating system 901 for ensuring basic data and data file processing functionality. Memory 404 includes a browser application 908 which translates alphanumerical and selection data input by the user 101 into data requests to remote terminals, and processes data broadcast from the said remote terminals in return as web pages 304, shown at 909 and which eventually comprises the virtual transaction checkout. The conditional transaction module 905 is also stored in memory 404, and those skilled in the art of programming data processing terminals will appreciate that the set of instructions embodying the functionality of CT module 905 may vary to a smaller or larger extent, depending up on the particulars of the OS 901 and the data processing capabilities of the device which the module is intended to configure. Module data 906 is therefore also represented in memory 404 and user input 901 includes the afore-mentioned alphanumerical and selection data, which comprises transaction parameters, user parameters and selections defining answers to the procedural or operational questions described in Figures 7 and 8.

Module data 906 comprises locally-input user data for sending back to terminal 601 at step 712, and this user data includes at least the user parameters consisting of payment details such as payment card data or online financial account data, as well as a count of the number of decisions requested according to steps 706 to 711. Module data 906 also comprises price data, and at least the total order amount in the preferred embodiment of Figure 7, and at least the product or service price in the alternative embodiment of Figure 8. Module data 906 also comprises decision data, which is received from remote terminal 601 at step 708 in the preferred embodiment.

Alternatively, decision data may be locally processed and output by the CT module 905 loaded at step 703 further to accessing product data at step 801, so for instance wherein the CT module is downloaded from terminal 601 for loading into the memory 404 of terminal 301 at the said step 703 and is downloaded complete with decision rule data. In this alternative embodiment and with reference to the description of Figure 8, the step 707 of requesting decision data does not involve broadcasting a request message to terminal 601, but instead processing the request locally with CPU 403 according to the decision rule data of CT module 905.

The virtual transaction checkout shown in Figure 5 according to the prior art is again shown in Figure 10 as configured by the CT module 905.The transaction checkout 304 comprises substantially the same sections 501, 502 and optionally 504, as well as the same user— selectable buttons 503, 507, 508 and data entry fields 505, 506.

If the virtual store 305 provides the functionality of CT module 905 in conjunction with terminal 601, the transaction checkout 304 comprises a further user-selectable button 1001, the selection of which by customer 101 in effect answers the question of step 706 positively.

The selection by customer 101 of button 1001 initiates the processing of the set of instructions embodying the CT module 905 by CPU 403, and a graphical user interface 1002 is output to VDU 308, and which comprises data entry fields 505, 506 and 507 which, depending upon the preferred implementation, are either respectively and automatically completed with user parameter data 901 already inputted by customer 101 within transaction checkout section 502 before selecting button 101, or require the re-inputting of said user parameter data 901 therein (for instance as a security measure), or require the input of said user parameter data for the first time if the customer 101 has not yet inputted appropriate data within section 502. The total amount of the order for which a "win or lose" decision is sought, which is shown at 1003. GUI 1002 also includes a user-selectable "confirmation" button 1004, which the customer 101 selects to request and obtain the "win or lose" decision, which is only provided if the user parameters in data entry fields 505-507 of GUi have been filled with appropriate data.

In the example shown in Figure 10, the GUI 1002 of CT module 905 is represented as a window overlaid over transaction checkout 304, which is known to those skilled in the art as a "pop up window". It will be readily apparent to those skilled in the art, that this configuration is provided by way of example only and that alternative embodiments contemplate the reconfiguration of web page transaction checkout 304 instead, or any other graphical user interface representation deemed appropriate. For instance, the GUI 1002 may not be required at all if customer 101 has inputted the appropriate data in data entry fields 505-507 of section 502 and the selection by customer 101 of button 1001 performs the decision request described in relation to button 1004, itself. Similarly, it will be readily understood by those skilled in the art that the representation of Figure 10 is inappropriate in the context of a physical retail environment using a POS terminal 104, wherein processing operations 706- 711 are performed with one or a plurality of binary "yes/no" data input, for instance using key pad 109.

Further to requesting a "win or lose" decision according to step 707, i.e. selecting button 1001 and/or 1004, the decision received in return either identifies a winning entry, in which case the order total 1003 is decremented, or identifies a losing entry, in which case the order total 1003 is incremented, for instance by the unit price associated with requesting a decision,,i.e. partaking in the game of chance. The virtual transaction check out 304 of Figure 10 is again represented in Figure 11, in which a "losing entry" decision has been received at step 708 in the example. In the example still, the unit price for each decision is $1, whereby the order total 1003 has been suitably incremented by $1. With reference to the description of Figure 7, the customer 101 may then invoke CT module 905 again by answering the question of step 711 positively with selecting button 1001 again, and the GUI 1002 subsequently output now shows the updated order total at 1101 further to the updating of the module data 906 at step 710.

Conversely, the transaction checkout 304 of Figure 10 is again shown in Figure 12, further to receiving a "winning entry" decision at step 708, and therefore wherein the order total has been decremented (1201) in consequence. In the example, the amount of the decrease provided by the store 305 of the example is the total amount 1003 of the store order, but excluding the price associated with the number of decisions requested. GUI 1002 is suitably updated with a notification 1202 of the "win" decision. It will be readily apparent to those skilled in the art, that the amount by which the transaction amount may be incremented or decremented depends entirely upon the commercial parameters of the store, which are preferably communicated to the CT module provider terminal 601 before the functionality of CT module 905 is provided to visiting customers 101. Again, it will be readily understood by those skilled in the art that the functionality of CT module 905 as described in relation to a is virtual transaction checkout 304 in Figures 10-12 may be easily implemented in a POS terminal 104, reprising an identical processing logic.

With reference to Figure 8, a web page 304 is represented on VDU 308 in Figure 13. The user 101 accesses product data 909 from a remote virtual store 305 at step 801, the product data including alpha numerical data such as a product name or description 1301 a product description 1302 , and a product unit price 1303, as well as image data such as a product photograph 1304. In accordance with known principals of virtual store product page configuration, the web page 304, 909 also include a user—selectable button 1305, which the user/customer 101 would select to add the particular product to a virtual shopping cart and the eventual inclusion of said data in a virtual transaction checkout 304 shown in Figures 10— , within order description section 501.

Alternatively, the product web page 304 again includes a user-selectable button 1001, substantially as described hereinbefore and the selection of which by the customer 101 again generates GUI 1002 and constituent parts 505—507 and 1004 thereof, but this time including the product prize data 1303 instead of an order total 1003. In conformance with the present description, the customer 101 may eventually button 1004, whereby a decision returned according to step 708 may identify either a winning entry or a losing entry. lfthe decision of step 708 identified a losing entry, the product price data 1303 is incremented instead of an order total 1003, and this outcome is illustrated by an updated product page 1306, in which the product price 1303 has been incremented by $1, amounting to the cost associated with requesting a decision as previously described in this example.

The customer 101 may request a further decision by again selecting button 1001, or alternatively still decide to purchase the product by selecting 0 button 1305, in which latter case the price data in the eventual virtual transaction checkout 304 will correspond to that shown in product page 1306, as opposed to product price 1303.

Conversely, if the decision of step 708 defines a winning entry, then again in accordance with the present description, the product price data 1303 is decremented and this outcome is shown at 1307 in which, in accordance with the example, the price data 1303 has been reduced to only the cost associated with requesting the decision, per the description of Figure 12. The customer may now select button 1305 for adding the product to a virtual shopping cart and the eventual online transaction checkout 304 will include the selected products at the unit price shown at 1307.

The operational steps according to which terminal 601 of the provider of CT module 905 processes data received from consumer terminals 301 or POS terminal 104, are further detailed in Figure 14. The terminal is yet again initially started, or switched on, at the first step 1401. Thereafter, an operating system is loaded into the 25 memory 404 of the terminal at step 1402, for instance of the same operating system as shown at 901, which configures the processing means 403 within the terminal 601 with basic data processing functionality, such as addressing data between the various constituent parts of the terminal over the bus 408, reading and interpreting input data and outputting decision data and optionally video data to a display 308.

Further to the OS—loading step 1402, a conditional transaction application is loaded at step 1403, as a set of instructions which configure the processing means of terminal 601 to process local and remote data as described in further details hereinafter.

A fist question is asked at step 1404 as to whether new "win or lose" decision parameters should be input as part of a set of data records loaded by terminal 601 at the same application-loading step 1403. lfthe question of step 1404 is answered positively, then at step 1405, a data record uniquely identifying a physical or virtual store must first be generated, whenever a retail environment wishes to provide the functionality of CT module 905 to its customers 101 for the first time. Such a data record may include data uniquely identifying both the store and the terminal 104 and/or 305, to ensure that decision requests of steps 707 are routed back to the correct requesting terminal 104 or customer requesting terminal 301 via the correct store terminal 305.

It is expected that a store may want to offer the functionality of CT module 905 for a plurality of products P, each of which may have varying levels of profitability and/or inventory levels and other such parameters which influence directly or indirectly the number of "winning entry" decision to be issued. Such parameters are therefore input at step 1406 in respect of each product for which CT module 905 will be used for the respective store that a record currently selected and/or generated at the previous step 1405.

A second question is asked at step 1407, which is asked immediately after the question of step 1404 if this latter is answered negatively, as to whether a decision request has been received from a remote terminal over the network connections of terminal 601. Ifthe question of step 1407 is answered positively, then the CT application of step 1403 extracts data uniquely identifying the requesting terminal, which has issued the request at step 1408 and, in addition :: to validating the authenticity of the user parameters entered in appropriate data entry fields of GUI 1002, also matches the extracted data against the set of data records loaded at step 1403 and optionally updated according to steps 1405 and 1406, in order to match the request to the appropriate store, product and "win or lose" conditional transaction parameters set according to step 1406.

At the next step 1409, the CT application processes a random decision for the combination of store and product matched at step 1408, based on the corresponding transaction parameters, and maintains a record of the request received at step 1407 and the decision reached at step 1409, before broadcasting the data output at the said step 1409 as the decision to the requesting terminal at step 1410. A question is then asked at step 1411, as to whether any further input data has been received, which is also asked if no decision request has been received at step 1407. Ifthe question of step 1411 is answered positively, control returns to the question of step 1404 and a determination is made as to whether the next input identified in step 1411 comprises data for generating or updating transaction decision parameters or whether this next input comprises data of a decision request, and so on and so forth.

Conversely, if the question of step 1411 is answered negatively, then the terminal 601 may perform any manner of other data processing tasks, for instance involving liaising with the respective terminals 104, 305 of client stores for reconciliation data of losing entries, winning entries, revenue and apportioning of revenue between the stores and the CT module provider. Terminal 601 may eventually be shut down at step 1412.

The memory means 404 of terminal 601 is shown in Figure 15 are respectively illustrated at run time. The memory 404 includes an operating system 1501 loaded at step 1402, the CT application 1502 loaded at step 1403 and a plurality of data records as described in relation to the description of steps 1405 and 1406 herein before.

An example of a store data record is shown at 1503 as comprising data 1504 uniquely identifying the physical or virtual store and/or its single terminal 104, 305, in addition to data defining transaction decision parameters in respect of each product for which CT module 905 may be involved. Those skilled in the art will easily understand that the transaction decision parameters may be applied to any other commercial variable and not necessarily in respect of individual products, therefore for instance transaction decision parameters may be defined in relation to ranges of order amounts, or the like. Further store data records 1506 are shown in Figure 15 to illustrate the possibility of a plurality of respective store data sets, substantially identical to data set 1503.

A compilation of data records is shown as a database 1507, which corresponds to the unique data records maintained by the CT application at step 1409 of each unique decision provided in reply to each decision request received at step 1407.

Input data 1508 is also shown in memory 404 of terminal 601, which comprises locally-input data, for instance data input according to steps 1405 or 1406 to generate or update records 1503, 1506, in addition to remote data received from remote terminals and comprising decision requests, user parameters for validating payment data at step 1408 and store and customer terminal network identification data. Output data 1509 is shown in memory 404 and comprises at any given time decision data output at step 1409 and yet to be broadcast at step 1410, CT module 905 to be broadcast to any user terminal 301 when accessing product data and requiring its functionality.

Transaction checkouts may be easily configured with the additional functionality provided by CT module 905, for instance in order to increase any of the number of customers 101 accessing a physical or virtual retail environment, increase the transaction conversion rate of virtual stores (understood as orders confirmed and paid for, as opposed to orders placed up to a point but never actually confirmed), increasing the revenue of the physical or virtual stores without however increasing stock turnover, or a combination of these advantages, without however requiring the replacement of physical transaction systems (101, 107, 109) or an extensive re-engineering of the set of instructions : underlying the functionality of physical transaction checkouts 104 or virtual transaction checkouts 304.

The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

Claims (5)

1. A method of configuring a transaction checkout at a mobile device, comprising the operations of: i) loading a checkout module and transaction data from a remote terminal; ii) loading a conditional transaction module; iii) processing transaction data with the conditional transaction module; iv) providing at the mobile device, a user with an input choice to either confirm the transaction data to the remote terminal or chance the transaction data; v) increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful.

2. The method of claim 1 comprising loading the checkout module and transaction data from the remote terminal and loading a conditional transaction module i) via a Bluetooth connection between the mobile device and a point of sale terminal o_r ii) via an internet connection to a remote web server.

3. The method of any of claims 1 to 2 wherein the mobile device is one of a mobile telephone, a tablet device, a wearable device or a watch device.

4. The method of any of claims 1 to 3 wherein the operations of i) to v) are performed via an application pre-installed on the mobile device.

5. A mobile device having processing means, memory means, data input and output means and networking means, the memory means storing instructions which configure the processing means to configure a transaction checkout at the mobile device for performing the operations comprising : loading a checkout module and transaction data from a remote terminal; loading a conditional transaction module; processing transaction data with the conditional transaction module; providing a user of the mobile device with an input choice to either confirm the transaction data to the remote terminal or chance the transaction data; increasing a price data element of the transaction data if the transaction data chancing is unsuccessful; and decreasing the price data element of the transaction data if the transaction data chancing is successful. TOMKINS & CO.