TECHNICAL FIELD

The present invention relates to an e-commerce system for managing online transactions between a merchant and their customers. Reference will be made to use of the e- commerce system, although this should not be seen as limiting.

BACKGROUND TO THE INVENTION

Consumers are increasingly reliant on purchasing goods and services over the internet, providing them with more consumer choices at competitive pricing. Online merchants are incentivised to take advantage of this opportunity, by providing their customers with the opportunity to purchase their products and services from a website hosted by the online merchant. Existing methods usually require the consumer to create a purchasing account with the online merchant, in which the consumer provides an email address and password. Sometimes, the consumer may be asked to provide credit card details in advance so that the online merchant is able to auto-populate the consumer's payment details during the online checkout process.

A shortcoming of this existing method is that consumers have to create different purchasing accounts from different online merchants. This creates an inconvenience, because consumers are required to either remember, or store different usernames, email addresses, and password. Another shortcoming of this existing method is that the consumer has to keep re-entering their credit card details every time they register a new purchasing account with a different online merchant. This creates potential issues with security and encryption, and increases the consumer's likelihood of falling victim to third parties with malicious intent, such as hacking and the like.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an e-commerce system and/or method, or at least ameliorate and/or overcome the problems identified above.

In a first aspect, the present invention is said to consist in a system for facilitating an e- commerce transaction comprising : one or more e-retailing servers corresponding to one or more e-retailers, each server configured to: provide content for display on a computer device of a customer, the content relating to products available for purchase from the one or more e-retailers, and a transaction facilitator configured to: receive a customer reference, a product selection and a purchase request entered by a customer on a computer device, the customer reference corresponding to a customer account managed by a transaction facilitator, send a purchase request validation to a personal mobile device of the customer corresponding to the customer reference, upon receiving confirmation from the personal mobile device that the purchase request is valid, facilitating the transaction.

Optionally, the computer device is a mobile device, a personal computer or kiosk and the content is displayed via an app or a web browser on the mobile device, personal computer or kiosk.

Optionally, code on each e-retailing server: a) displays capture fields on the app or web browser to enable a customer to enter a reference, product selection and purchase request, and b) sends the entered customer reference, product selection and purchase request to the transaction facilitator.

Optionally, the transaction is facilitated without logging in to an account of any e-retailer.

In another aspect, the present invention is said to consist in a system for facilitating an e-commerce transaction comprising : a transaction facilitator configured to: receive a purchase request on behalf of an e-retailer, and receive a customer reference and product selection, the customer reference corresponding to a customer account managed by the transaction facilitator send a purchase request validation to a personal mobile device of a customer corresponding to the customer reference, upon receiving

confirmation from the personal mobile device that the purchase request is valid, facilitating the transaction.

Optionally, the product selection is by way of a photo, scan or other

capture/ representation of an identifying feature of the product for purchase.

Optionally, the product selection is by way of a customer selecting content that is displayed via an app or a web browser on a mobile device, personal computer or kiosk.

Optionally, code on an e-retailing server: a) displays capture fields on the app or web browser to enable a customer to enter a reference, product selection and purchase request, and b) sends the entered customer reference, product selection and purchase request to the transaction facilitator.

Optionally, the transaction is facilitated without logging in to an account of any e-retailer. In another aspect, the present invention is said to consist in a method of facilitating an e- com merce transaction comprising : at a transaction facilitator: receiving a pu rchase request on behalf of an e-retailer, and receiving a customer reference a nd product selection, the customer reference corresponding to a customer account managed by the transaction facilitator sending a pu rchase request validation to a personal mobile device of a customer corresponding to the customer reference, u pon receiving confirmation from the personal mobile device that the pu rchase request is valid, facilitating the transaction .

Optional ly, the product selection is by way of a photo, scan or other

capture/ representation of an identifying feature of the product for pu rchase.

Optional ly, the product selection is by way of a customer selecting content that is displayed via an app or a web browser on a mobile device, personal com puter or kiosk.

Optionally, code on an e-retailing server: a) displays capture fields on the app or web browser to enable a customer to enter a reference, product selection and purchase request, and b) sends the entered customer reference, product selection and pu rchase request to the transaction facilitator.

Optionally, the transaction is facilitated without logging in to an account of any e-retailer.

Optionally, the method or system according to any aspect of the present invention sends a pu rchase request validation to a personal mobile device of a customer corresponding to the customer reference, and receives confirmation from the personal mobile device that the purchase request is valid provides a proxy for validating a purchase via logging in to a n accou nt.

The term "com prising" as used in this specification and claims means "consisting at least in part of". When interpreting each statement in this specification and claims that includes the term "com prising", featu res other than that or those prefaced by the term may also be present. Related terms such as "com prise" and "comprises" are to be interpreted in the same manner.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred em bodiments of the invention wil l be described by way of exa mple on ly and with reference to the drawings, in which :

Figu re 1 is a general overview of the e-commerce system .

Figu re 1A is a flow diagram of the e-commerce system . Figure 2 is a flow diagram showing the method of conducting e-commerce transactions on the system via the various modes.

Figure 3 is a work flow diagram of the user interaction that gives a general indication of the user interactions in the method of Figure 2.

Figure 4 is a flow diagram of the method of setting up an account with the third-party facilitator.

Figure 5 is an example of a web page provided by an e-retailer displaying various products for purchase.

Figure 6 is a method flow diagram of selecting and purchasing according the web browser mode of engagement.

Figure 7 is an example of a web page provided by an e-retailer displaying various products for purchase as an alternative embodiment.

Figure 8 is a method flow diagram of selecting and purchasing according to an alternative embodiment of the web browser mode of engagement.

Figure 9 is a software flow diagram of the e-commerce app according to alternative modes of engagement.

Figure 10 is a screenshot template of a log-in page that the customer sees when they start up the app for the first time.

Figure 11 is a screenshot template of what the customer sees when creating a customer account.

Figure 12 is an exemplary screenshot of the products list page.

Figure 13 is an exemplary screenshot of the product page, providing further details about the nature of the selected shopping item .

Figure 14 is an exemplary notification screenshot according to an alternative

embodiment.

Figure 15 is an exemplary screenshot of the products list page according to an alternative embodiment.

Figure 16 is an exemplary screenshot of the product page according to an alternative embodiment.

Figure 17 is an exemplary screenshot of the product order system .

Figure 18 is an exemplary screenshot of the product ID capture page according to another mode of engagement.

DETAILED DESCRIPTION

1. Overview

The present description relates to a sales as a service system/method, whereby retailers can utilise the service to provide e-commerce transactions to customers. In general terms, and as shown in Figure 1A, the sales as a service system/method 10 (termed "e- commerce system" or "e-commerce method" enables retailers to offer an e-commerce service to customers that provides the following :

1. A product (goods/services) selection platform, to enable a customer to select products to purchase via various modes of engagement. The platform/modes of engagement could be, for example:

o a web page, app or similar on a computer, mobile device and/or kiosk; o a product scanning device and system, for scanning products to purchase;

2. Inventory validation to ensure selected products are actually available for

purchase.

3. Purchase validation to enable the customer to confirm a purchase.

4. Funds transfer between the purchaser and the retailer

5. Product dispatch .

Figure 1 shows in diagrammatic form an overview of a system 10 that facilitates e- commerce transactions between a customer 1 and one or more participating e-retailers 11 ( 11A to 11D) using a third-party e-commerce transaction facilitator 16. The system in Figure 1 allows a customer 1 to conduct e-commerce transactions with multiple e- retailers 11 using various modes of engagement, but without the need to have an account with/login to an account with any of the e-retailers 11. Figure 2 is a flow diagram showing the method of conducting e-commerce transactions on the system 10 via the various modes. It should be noted that Figures 1 and 2 and the accompanying

description demonstrate the end-to-end system/method from the customer 2 to the e- retailers 11, utilising the third-party e-commerce facilitator 16 to facilitate the

transactions in conjunction with financial institutions 20. This end-to-end

description/depiction is provided for context and to show the use. However, the invention is not necessarily restricted to requiring all these components/sub-systems, steps and parties. For example, the invention may correspond just to aspects of the system/method that can be used to facilitate the end-to-end e-commerce transactions, such as the system of the third-party facilitator 16. As another example, the method shown in Figure 2 shows the steps carried out by various parties, including the customer, e-retailer, third party facilitator, and the financial institution ; however, the invention might be just one aspect of that, such as the method steps carried out by the facilitator.

Referring to Figure 1, the system 10 comprises a plurality of e-retailers 11 (for example comprising e-retailers 11A to 11D) who wish to provide the ability for their customers 1 to purchase goods and/or services ("products") using an e-commerce channel. Each e- retailer 11 could be a traditional "bricks and mortar" retailer who also wants to provide e- commerce options to customers, or could be solely be an e-retailer. The term "e- retailer" should not limit the nature or function of retailers (also termed "merchant") who may utilise or participate in the system. The user can interact with the e-retailer to select products for purchase via the facilitator using one or modes of engagement such as a web page, app, scanning a product. For example, in accordance with one

embodiment, each e-retailer 11 provides a website that the customer 2 (or "user") can access to view and select products that they wish to purchase. Referring by way of example to e-retailer 11A, 11B the website might be provided/hosted by the e-retailer 11A, 11B themselves, by way of a web server 12A, 12B with a computer system and inventory database 13A, 13B (that is, inventory of goods and/or services for purchase). Alternatively, in the case of e-retailers 11C, 11D the website might be provided/hosted on behalf of the e-retailer by a third party website hosting provider 12C, which provides the computer system and database 13C. That third-party website hosting provider 11D could be also the third-party transaction facilitator 16 itself, which would provide the computer system and database 13D of the webserver 12D. The website of each e-retailer 11 can be accessed by a customer 2, and so they can view the products that are available for purchase from that particular e-retailer.

A customer 1 who may wish to view the products of an e-retailer 11 for purchase can use a computer device, such as a computer 3, mobile device 4 (such as a mobile telephone) or the like, which operates a web browser 6A on a processor 6 that displays a website 19 on a browser in a screen 8 of the computer device. Using the web browser, the customer can via the Internet 5 access the e-retailer's website 19 via the webserver 12A to 12D, download a web page 19 that displays the various products available for purchase and browse those products. There is also a "buy" button 19A (such as an icon or similar - see e.g. Figure 5, item 55) displayed in relation to each product displayed. For example, there could be a button for each product, or a button for a group of products or a shopping cart. There are also one or more fields for entering a customer account reference, which corresponds to a customer account on the e-commerce transaction facilitator 16. By utilising a buy button 19A and the customer identification field, a customer can buy products from each e-retailer 11 as desired. This will be explained further below. The customer also uses a personal mobile device (such as the same mobile telephone 4 as above) running an app 6B that facilitates validation (also termed "confirmation", "verification" or "authentication" of a purchase requested ("purchase verification request")) by the customer. This will be explained further below.

The third-party e-commerce transaction facilitator 16 facilitates the e-commerce transaction requested by the customer - that is, the facilitator 16 can carry out e- commerce purchase transactions on behalf of the e-retailers 11. The e-commerce facilitator 16 maintains a database 16A of accounts for customers 1 who wish to utilise the system 10 to purchase products from the participating e-retailers 11. The account for a customer 2 can be used for purchase from any, or all, of the e-retailers 11. For each customer account, the database 16A will contain the credentials required to identify and confirm the customer, validate the e-commerce purchase and perform the transaction with the financial institution 20. Such credentials could comprise (but are not restricted to)

• customer name, address and other customer identification details,

• a customer account reference (also termed "user identifier"), this could be an email address, or something else such as a mobile telephone number or a unique alphanumeric identifier,

• access credentials for a mobile device 4 of the customer,

• credit card or other payment details

The customer account reference is linked to the customer credentials, including being linked to the access credentials (such as an IP address or telephone number) for the customer's mobile device 4. This means that when the customer account reference is provided to the e-commerce transaction facilitator 16, the mobile device 4 of the customer can be identified and accessed by the facilitator 16.

The e-commerce transaction facilitator 16 also comprises the inventory details of all the e-retailers 11 participating in the system, including product identification information ("product identifier") of all goods and services available for purchase, the respective purchase prices, respective stock numbers and the like. This enables the e-commerce transaction facilitator to carry out e-commerce transactions on behalf of the e-retailers 11.

Referring to Figure 2, an e-commerce transaction using system can take place according to a first mode of engagement as follows. The customer 2 uses the web browser 6A on their computer device 3, 4 (computer, or mobile telephone, for example) to access the website 19 of an e-retailer 11 that they wish to purchase products from, step 21A. The website 19 is displayed on the browser 6A on the screen 8 of the computer device, and the customer browses through the goods and/or services on offer. When the customer is ready to purchase they initiate a transaction, step 21B. First they provide their customer reference. This activates the customer account with the e-commerce transaction server to enable purchasing. Importantly, this can occur without the customer needing to login to an account of any e-retailer participating in the system . They then select the products that they wish to purchase. This can be done for example by placing them in a virtual shopping cart, for example. When the customer is then ready to purchase they activate the buy button. This activates a chain of events that ultimately results in the e-commerce transaction being carried out as facilitated by the e-commerce transaction facilitator, step 21C. Importantly, this chain of events occurs without taking the customer away from the website and without requiring the customer to login to an account of the e-retailer. First, e-retailer identification details and the customer account reference as entered by the customer is passed from the e-retailer web server to the e-commerce transaction facilitator, along with product identifiers for the selection of the goods and/or services to be purchased, step 21D. This is termed "transaction data", and forms part of a "buy request". The e- commerce transaction facilitator 16 verifies the customer reference, the E - retailer and the product identifiers against its own records, step 21E. As an example, it verifies a customer reference, the customer's region, that the product identifier(s) of the goods and/or services being selected are real products, being sold by that e-retailer that operates in the customer's region and that the website of the E retailer at the request originates from is one that the retailer allows sale of the product. Not necessarily all of these checks need to be done, however, depending on the nature of the E retailer's requirements over purchase control.

Once the validation step has been carried out, a purchase verification request, such as via "push notification", is sent from the e-commerce transaction facilitator 16 to an app 6B on the customer mobile device 4, step 21F. In this provides a buy request validation notification to the customer 2 via the app 6B and screen 8, which contains the names of the products to be purchased, the respective product identifiers, the prices and an option to confirm or cancel the buy request. If the customer 2 confirms the buy request, the app 6B on the customer device 4 sends a notification to the e-commerce transaction facilitator 16, which triggers the facilitator to complete the transaction with a financial institution, step 21G. The facilitator arranges transfer of funds from the purchaser's financial institution to the e-retailer's financial institution, using mechanisms known to those skilled in the art. For example, credit card, debit card, internet banking, and/or funds transfer mechanisms could be used to transfer funds.

The e-retailer(s) is then notified of the purchase, including details of the product, quantity, purchase details, purchaser dispatch address etc. and the product or products are then dispatched by the respective e-retailer(s) via their product distribution channels, step 21H.

It will be appreciated that the above chain of events, steps 21A to 21H could occur in a different order. For example the customer reference could be processed first, and some time later the product selection is made, passed to the e-commerce transaction facilitator and the transaction then is facilitated.

Figure 3 shows a work flow diagram of the user interaction that gives a general indication of the user interactions in the method of Figure 2, but should not be considered limiting. The customer 2 requests access (e.g. via a browser) to an e-retailer website using a computer device. The e-retailer website sends webs pages for viewing by the customer. The customer selects items of interest and clicks the buy button, actions which are received by the e-retailer web server. The e-retailer sends transaction data ("buy request") to the third party facilitator 16, which then sends a purchase verification request to the customer, via the app on their mobile device. The customer accepts the request, and the third party facilitator facilitates the transaction and passes the order to the e-retailer for dispatch.

Other modes of activating the transaction, browsing products to be purchase, selecting those for purchase and triggering the purchase, can be used. For example, kiosk, app on user device or other modes could be used.

For example, in an alternative, the customer 2 may use an app on the mobile device 4, which displays products for purchase from the e-retailers 11, step 21A. This might be the same app 6A used for purchase validation, or a different app. The app can be

maintained by the e-retailer 11 directly, or via a third party provider. The app can display a screen similar to that of the web browser 19, where a field is provided for entering the customer account reference and a buy button is provided for activating the transaction . When the transaction is activated, step 21B, the product information and customer references is passed to the e-commerce transaction facilitator 16, step 21D and the transaction is validated, completed and dispatched as per the method above, step 21C (steps 21D to 21G).

In another alternative, the customer 2 can utilise an app and the camera 7 on their mobile device 4 to take a picture of a product, or some identifying feature of the product (such as a barcode, brand, product name or picture or the like) to identify the product for purchase and/or the e-retailer 11 that provides the product. Alternatively, a scan of the product could be done - such as a scan of a barcode/QR code or similar. Again, the customer account reference and the product identifier (extracted from the photo/scan) can be sent to the e-commerce transaction facilitator, and the transaction completed in the manner described previously, steps 21A to 21H. In another alternative, the customer utilises a kiosk 18. This could work in much the same way as the app or browser modes of engagement described above using the mobile device or computer, except the selection is made by a kiosk type computer device operated by a third party. The kiosk 18 is coupled to the system 10 in a suitable manner and accesses, displays and takes product selections using a suitable app 6A or browser 6B, hosted on processor 6.

It will be appreciated that the configuration/architecture of the system provides the following characteristics.

First, the customer does not have to log into an account of any particular e-retailer 11, but rather simply has a central account with the e-commerce transaction facilitator 16. This does not require a login, but rather a customer account reference. The e-retailers do not need to maintain a database of customers 2 nor their credentials, and the customer does not need the inconvenience of having account credentials loaded and login details required for each retailer. Rather, they just need a customer account reference for the central account with the e-commerce transaction facilitator 16.

Second, each e-retailer does not need to transfer the customer to a separate transaction website. Rather, they retain the customer on their e-retail website or app, and simply send the customer account reference and product information to the facilitator 16 to facilitate the transaction . This improves customer experience.

Third, the e-retailer 11 does not need to manage transactions; rather they transfer that task to the facilitator 16. This greatly simplifies the requirements of the e-retailer - they do not need to maintain databases and transaction systems for e-retailing, and can simply provide a website with product information, - and even that function can be outsourced to a third party.

Fourth, confidential information such as logins, customer identification information, credit card details and the like do not need to be passed between the customer 2 and that the e-retailer 11. This information is all stored centrally at the e-commerce transaction facilitator 16. All that is required is a customer reference, so that the e-retailer can indicate to the E commerce transaction server which customer is requesting the purchase.

Fifth, validation or verification of the purchase is conducted during using two factor authentication with the customer's mobile device. Again, this removes the need for logins or other secure data to be transferred. Rather, on the assumption that the customer is in control of their own personal mobile device, that assumption is used to validate the transaction, independently from the selection/purchase activation process via the web browser. The two factor authentication validation via the app and mobile device is based on the premise that the mobile device will be in the possession of the person who owns the customer account. While the customer will have an account with the facilitator comprising their credentials, they do not need to log in to that account (or any account for that matter) to make a purchase. Rather, the user simply selects products via the mode of engagement, without need for logging in to an account (of a retailer or facilitor), and can confirm the purchase via a validation request sent to their device, again which can occur without the need to log in to an account. The entire e-commerce experience can be conducted without the need to: login to an account, remember login details, or have an account for any of the e-retailers. The mobile device validation acts as a proxy for logging in to an account. As the mobile device is presumed to be in the possession and control of the customer, this provides the required level of security and obviates the need for credential checking via e.g. logging in to an account. Sending a purchase request validation to a personal mobile device of a customer corresponding to the customer reference, and receiving confirmation from the personal mobile device that the purchase request is valid provides a proxy for validating a purchase via logging in to an account.

The user can add select products for purchase to a cart and purchase at any point in time. There is no time limit and purchases can be approved as and when required, on demand at any time.

Therefore, from the user's perspective, an advantage of the disclosed e-commerce system is that it allows a customer to place and approve multiple online purchases without the usual hassle of remembering login details. This allows the customer to purchase multiple goods and/or services from one or more different merchants without having to create multiple online account for each different e-retailer site. Since all online transactions are conducted on this e-commerce system using details in a centralised customer account with the facilitator, it avoids the customer from having to provide their payment and shipping address details to multiple merchants. As part of validating the transaction, the customer uses the downloaded validation app to link the customer's customer account to a device in their possession . This removes the need for the customer to provide a password or other login credentials for validation every time they wish to conduct an online transaction, whilst ensuring their online transactions are kept secure from other third parties with malicious intent. Therefore, from the e-retailer's perspective, an advantage of the disclosed e-commerce system is that the barrier to entry for customers to purchase from them is reduced. No account sign-up is required for a retailer, and no login is required when purchasing. A user can simply engage with the retailer via a suitable mode of engagement, and start selecting items for purchase.

The above embodiments provide a broad overview of the architecture, configuration and/or functionalities of the system, which is facilitated by the e-commerce transaction facilitator 16. Particular limitations of this broad embodiment will now be described, without limitation .

2. Example embodiments

Various embodiments are now described. These all fall within and are possible implementations of part or all of the general embodiments described above.

2.1 SYSTEM AND METHOD OF FACILITATING E-COMMERCE TRANSACTIONS USING A BROWSER

Figure 1 shows an embodiment of an e-commerce system 10 in which a customer 2 selects products and purchases them using a web browser, and in which a third party facilitator facilitates the purchase transaction. The web browser could be operating on a computer device, such as a computer or mobile device like a mobile telephone. Figure 2 shows the method carried out in this embodiment in general (and as previously described) and Figure 4 shows details of various aspects of the method. Figures 5 to 8 show various screen shots of what is displayed to the customer on the web browser.

Prior to browsing and purchasing, the customer 2 sets up an account with the third party facilitator, see Figure 4. This happens before step 21A in Figure 2. This could happen in any suitable way, and the customer could access the sign up procedure through any suitable channel, such as via the third party facilitator or via one of the e-retailers.

Figure 4 shows the method of sign-up for a customer who is new to the e-commerce system and is using it for the first time, according to one example. In step 41, the customer accesses the e-retailer's website to select one or more goods and/or services offered for sale by the merchant. The customer enters their email address on the e- retailer's website. At step 42, the customer is emailed a link that allows the customer to sign up to the e-commerce system . The customer is redirected at step 43 to an app store corresponding to a mobile device 4 they will use later to validate purchase transactions. This could be the Google Play™ store, Apple App™ store, or any other app store depending on the device operating system . The customer is able to download and install a purchase request verification (PRV or verification) app 6B on their device, which will facilitate the customer to confirm transactions. In some embodiments, the app 6B might also enable product browsing - in which case it can be more generally termed an e- commerce app. This option will be described later. Once the verification app is downloaded, the customer 2 creates a customer account 100, shown in Figure 10 by providing various credentials, which are stored centrally as a centralised account with the third party facilitator and linked with the mobile device of the user with the validation app. For example, the customer provides a customer account reference (such as their email address 102 (or any other unique identifier)), and agreeing to the terms and conditions 105 and 107 of the verification app and/or e-commerce system . At step 44, the customer is asked to enter a delivery address 112, shown in Figure 11, so that goods purchased by the customer using the e-commerce system can be delivered. At step 45, the customer enters their credit card 113 or other payment details. All these details are stored as credentials as part of the central customer account 16. At step 46, the validation app 6B redirects the customer back to the web page containing the products on offer for sale. It should be noted, as an alternative, the customer could sign-up to the third party facilitator via another means, by-passing the e-retailer website. This could happen, for example, when they are not actually about to purchase a product, but are signing up in anticipation of future purchases. Once signed up, the customer can then proceed with a purchase. But once set up, logging into the account is not required to actually make a purchase. This will now be described.

On the assumption that a customer account has been created, the purchase process will now be described. The process could carry on directly after the account creation process, or could happen at some later date. Referring to Figure 2, the customer 2 accesses an e- retailer website using a browser, step 21A, using the computer device, which then receives and displays product information from the e-retailer web server 13 (which can be hosted in any manner previously described). See, for example, Figure 5, which shows and example of a web page 19 provided by an e-retailer displaying various products for purchase. The web pages shows canned beans, socks, pantyhose, baking powder, packaged food, and coconut flour - all examples of products this particular e-retailer sells. Referring to the canned beans by way of example, each product has a profile showing a product picture 52, product description 51 and price 53. A field 54 is provided for entering the customer account reference (an email address in this case), and the buy button 55 is displayed, in this case and icon "B". The buy button is preferably placed adjacent to, or near the product. The buy button 55 acts as a transaction initiator to relay the online purchase to the validation app linked with the customer's customer account. This avoids the need for the customer 2 to log-in or sign up to the e-retailer website. Furthermore, the customer is not redirected from the webpage to continue the transaction. Rather, they remain on the static web page showing the items for sale, but continue the transaction via the validation app. Once the customer clicks the buy button 55, a handover is initiated so that the online transaction is instead processed by the third party facilitator. Each other product on sale is indicated with equivalent information.

The customer 2 browses through the catalogue of goods and/or services that the e- retailer is selling. Once the customer 2 has decided on the goods and/or services to purchase, (e.g. canned beans as shown in step 61 on Figure 6), the customer 2 proceeds to enter the customer account reference, in this case their email address, into the customer account reference field 94 - see step 62 on Figure 6. This identifies the customer account on the third party e-commerce facilitator 16. The customer 2 then clicks the buy button 55 to indicate they want to buy the product, which triggers the purchase transaction . They may do this for more than one product. The entering of the customer account reference and clicking the buy button 55 initiates the transaction, step 21B. At this point, the e-retailer website 14 sends transaction data (e.g. e-retailer identification details and the customer reference as entered by the customer, along with product identifiers for the selection of the goods and/or services to be purchased) to the third party facilitator 16, step 21D. This could be termed a "buy request". The third party facilitator verifies the transaction, step 21E. For example, it verifies a customer reference, the customer's region, that the product identifier(s) of the goods and/or services being selected are real products, being sold by that e-retailer that operates in the customer's region and that the website of the e-retailer at the request originates from is one that the retailer allows sale of the product. The customer 2 then receives a buy notification (purchase verification request) on the customer's mobile device verification app, step 21F, and the customer has the choice of approving the transaction and payment, or has the option to decline the purchase. Referring to the right hand side of Figure 6 (which shows the screen of the verification app), product identification details 67 are displayed, and the option to "buy" 68 or "cancel" 69. The verification app notification is displayed on the customer's device 4 as a pop-up notification 66.

Preferably the customer authenticates and approves all online transactions using a mobile device 4 in their possession, such as a mobile telephone. However it is envisioned that the customer can also authenticate and approve online transactions in other ways. For example, they could approve a transaction by downloading and installing the validation app on any other type of electronic and/or computing device, irrespective of whether it is always in the customer's possession or whether such device is portable. For instance, it is envisioned that the validation app can be downloaded onto a tablet, PC, smart television, or the like. If the customer does not already have a customer account, they are still able to approve online transactions via an email notification sent by the third party facilitator. The email notification can optionally invite the customer 2 to sign up to the e-commerce system . If the customer 11 approves the transaction, the mobile device transmits the accepted buy request to the third party facilitator. The server processes the transaction, step 21G, by debiting the bank account, credit card, debit or the like linked to the customer, or otherwise effecting funds transfer to the retailer, before passing the order to the e- retailer for dispatch, step 21H.

In another embodiment, Figures 7, 8 show the purchasing of multiple items in a single transaction using a shopping cart. This example assumes that the customer 2 has already set up a customer account and is therefore ready to use the e-commerce system . Like as described in relation to Figure 5, the customer 2 accesses an e-retailer website using a browser, step 21A, using the computer device, which then receives and displays product information from the e-retailer web server 13 (which can be hosted in any manner previously described). The web pages shows canned beans, socks, pantyhose, baking powder, packaged food, and coconut flour - all examples of products this particular e-retailer sells. Referring to the canned beans by way of example, each product has a profile showing a product picture 52, product description 51 and price 53. A field 54 is provided for entering the customer account reference (an email address in this case), and the buy button 55 is displayed, in this case and icon "B". Instead of buying individual items as described previously, the customer can select multiple items (beans 72, socks 73, chocolate 74) by pressing the buy button 55 as shown in step 81 on Figure 8, which places them in a shopping cart 71 displayed on the website. Products can be added or deleted from the cart, and/or selected to indicate which might be actually be purchased (for example if the customer wants to put a "short list" of items in the cart for consideration, but not actually buy them all). At step 82, the customer 2 proceeds to enter the customer account reference, in this case their email address, into the customer account reference field 75 in the shopping cart - see Figures 7, 8. This identifies the customer account on the third party e-commerce facilitator 16. The customer 2 then clicks a checkout button 76 in shopping cart 71 to indicate they want to buy the products in the cart, which triggers the purchase transaction. The entering of the customer account reference and clicking the checkout button 76 initiates the transaction, step 21B. The transaction then proceeds as previously described. At this point, the e- retailer website 14 sends transaction data to the third party facilitator 16, step 21D. This could be termed a "buy request". The third party facilitator verifies the transaction, step 21E. The customer 2 then receives a buy notification (purchase verification request) on the customer's mobile device verification app, step 21F. The app shows all the items in the shopping cart (or those selected) and the customer has the choice of approving the transaction and payment, or has the option to decline the purchase. Also, the customer has the option of approving purchase of just some of the items from the cart. This provides a two layer cart system - that shown on the website, and that shown on the app. Referring to the right hand side of Figure 8 (which shows the screen of the verification app), product identification details of all items 87A, 87B, 87C, in the cart are displayed, and the option to "buy" 88 or "cancel" 89. The verification app notification is displayed on the customer's device 4 as a pop-up notification 86. The remaining transaction occurs as previously described.

The embodiments above are described with reference to a single retailer, but it will be appreciated that the products of multiple retailers can be bought in a similar manner to that above. The websites of multiple e-retailers 11, 11A, 11B, 11C, 11D can be accessed, and products selected from those multiple e-retailers. There can be a shopping cart in each website, which can consolidate to a single buy request on the app. Alternatively, a consolidated website shopping cart could be used to aggregate the products from various retailers. An advantage of the consolidated shopping cart 71 is that multiple items 72-74 can be added from multiple e-retailer websites and/or from multiple e-retailers into a centralised shopping cart. Another advantage of the centralised shopping cart 71 is that multiple items selected from different e-retailer websites and/or different e-retailer can be purchased under a single transaction when the customer approves the transaction on their authenticated device.

Irrespective of how the selection is made, if the customer 11 approves the transaction, the mobile device transmits the accepted buy request to the third party facilitator. The server processes the transaction, step 21G, by debiting the bank account, credit card, debit or the like linked to the customer, or otherwise effecting funds transfer to the retailer, before passing the order to the e-retailer for dispatch, step 21H.

A recurring purchase option could be set up. For example, for consumable items, the customer could set up a purchase to happen weekly or similar. For example, milk could be on a weekly purchase.

The third party facilitator could provide, design and/or manage/host the websites for one or more of the retailers. Or, the retailer could do that themselves, but the third party facilitator provides template websites for the retailer to use. The third party facilitator will maintain a database of products that the retailers sell. The retailers might also maintain a database of such products, and optionally inventory levels. The system could work with existing stock systems.

As part of hosting a database of products that the e-retailers sell, the third party facilitator is able to supply the e-retailer with a code for generating the buy box 55. The generated buy button code is unique to the shopping item on offer for sale by the e- retailer, and is shown below by way of example :

<script type="application/javascript" >

(function (d, s , id, key) {

if (d . getElementByld (id) ) return;

var js, fjs = d.getElementsByTagName (s) [0] ;

js = d.createElement (s) ;

j s . id= ¹ buyence-b3- js ¹ ;

j s . src= ¹ https : //b3. buyence . com/b3. j s ¹ ;

d.b3 = { key : key } ;

fj s .parentNode . insertBefore ( j s , fj s)

} (document , ¹ script ¹ , ¹ buyence-b3 j s ¹ , ¹ b3 -key ¹ ) ) ;

</script>

The e-retailer is also able to choose where they place the buy button 55 on their website by using the build target code, shown below by way of example.

<div class= "buyence-b3-stockcode" data-stockcode="STOCKCODE"

style= "visibility : hidden" ></div>

When the customer is interested in buying the shopping item and selects the buy button 55, the third party facilitator is able to retrieve and add the correct shopping item into the transaction .

Alternative embodiments of the e-commerce system will now be described. This section describes the differences between the alternative embodiment and the main

embodiments. However, other aspects of the alternative embodiment, such as purchase verification will not be discussed in this section, as they have already been described in the main embodiment.

2.2 SYSTEM AND METHOD OF FACILITATING AN E-COMMERCE

TRANSACTION USING AN APP

In another embodiment, instead of using a browser on a computer device to browse and select products and initiate purchases, the customer uses a product selection app on a mobile device. This is an alternative mode of engagement. The app works in a similar manner to the browser embodiment, except that an app provides the visual interface. The mobile device typically is the same device used to confirm purchases using the purchase request verification app, although that is not essential. Typically, although it is not essential, the product selection app also functions as the purchase request verification app, as shown as steps 95 and 98 in Figure 9 for example. More generally, the product selection app, with or without the purchase request verification functionality could be called an e-commerce app. The app could be provided and/or designed by the retailer, third party facilitator, or a third party. Prior to use, the customer downloads the e-commerce app. This could be downloaded in the same manner as previously described for the purchase request verification app. Once the customer downloads the app, they start-up the app to begin using the e- commerce system . The app provides a screen and user experience similar to that provided by and described earlier in relation to the browser mode of engagement.

Logging in and creation of the customer account will be described with reference to the flow diagram in Figure 9, and the screen shots in Figures 10 to 11.

Figure 10 shows a screenshot template 100 of log-in page that the customer 2 sees when they start up the app for the first time, 94C. At the top of the screenshot 100 is the welcome/ login text 101 that explains to the customer 2 that they are required to either log into their customer account, or create a new customer account. If the customer 2 already has an existing customer account, the customer 2 can provide their email address 102 and password 103 linked to their customer account. The customer 2 clicks on the sign in/up button 104 to log-in and access the home page 94A, 106.

If the customer 2 is new to the e-commerce system, the customer 2 will need to select button 104 to create a customer account 94E. Figure 11 shows a screenshot template 110 of what the customer 2 sees when creating a customer account. Text box 111 contains welcome text and/or explanation outlining the process of creating and using a customer account. The customer provides their address information 94F and their credit card information 94G, and any other information required, which is then saved to the created customer account. The customer 2 provides an email address that can either be linked to a Google™ account, which creates a seamless experience for the customer 2 if the app is being used on an Android™ device. Alternatively, the customer 2 can use an email address of their own choosing. Alternatively, the customer 2 can provide an identifier other than an email address, such as a mobile phone number, or any kind of alpha-numeric identifier. The customer 2 enters their credit card information at 113, or any other type of bank details such as PayPal™, bank account number, Bitcoin™, HOP™ card account, or the like. The customer 2 can also select the terms and conditions button 105 to review the terms and conditions of use 107 of the app and/or the e-commerce system. Once details 112 and 113 are entered, the customer 2 proceeds to complete sign up 114, in which they will be redirected to a home welcome page 94H, before being redirected to the home page 94A, 115. Product selection and purchase using the e-commerce app will be described with reference to the flow diagram in Figures 2 and 9, and the screen shots in Figures 12 to 14.

By way of example, the customer 2 uses the home page 94A to browse for goods sold by the e-retailers 21A. The customer 2 can select an item of interest, in which the app retrieves the relevant product information from the third-party facilitator 16 and adds the shopping item into a centralised virtual shopping cart. The customer 2 has the option to browse goods offered by one or more e-retailers.

From the home page 94A, the customer can access the product list 94N to review one or more shopping items that have been added into the centralised shopping cart. The shopping cart can contain shopping items selected from one or more e-retailers. Figure

12 shows a screenshot 120 of the products list page 121 by way of example. The customer 2 can review a selected item in more detail by selecting the products list page 141, in which the app redirects 123 the customer 2 to the product page 940, 130. The customer 2 can also select button 122 to be redirected to the purchase multiple items page 124. By selecting button 122, the customer 2 initiates the transaction, step 21B.

The product page 940, such as screenshot 130 in Figure 13 for example, provides further details about the nature of the selected shopping item . By way of example, the product page 940 displays a product image 131 of interest, as well as the product name 132, and product description/price 133. The customer 2 can select the product information button 134 to access the product information page 136. Alternatively, if the customer 2 receives a shipping notification 97 that indicates their shipment order has been delivered to their address, the customer 2 can be redirected to the relevant product page 940, 130. Once the customer 2 is ready to checkout, the customer 2 selects button 135, shown in Figure

13 to initiate the purchasing transaction, step 21B.

A transaction request is sent from the app 6B to the third-party facilitator. The third- party facilitator 16 retrieves the transaction data (e.g. e-retailer identification details and the customer reference as entered by the customer, along with product identifiers for the selection of the goods and/or services to be purchased) from the app to the third party facilitator 16, step 21D (in a similar way to the web page mode of engagement). This could be termed a "buy request". The third party facilitator verifies the transaction, step 21E, like for the web page mode of engagement.

The customer 2 then receives a buy notification (purchase verification request) 140, such as item 141 on Figure 14 for instance, on the customer's mobile device verification app, step 21F, and the customer has the choice of approving 142, 145 the transaction and payment, or has the option to decline 143, 144 the purchase.

If the customer 11 approves the transaction, the mobile device transmits the accepted buy request to the third party facilitator. The server processes the transaction, step 21G, by debiting the bank account, credit card, debit or the like linked to the customer, or otherwise effecting funds transfer to the retailer, before passing the order 94T to the e- retailer for dispatch, step 21H.

In an alternative embodiment, settings menu 941 can be accessed from the home page 94A. The customer 2 has the option to review the terms and conditions 94J, access the help menu 94K, update their credit card details 94L, or change their account password 94M.

In an alternative embodiment, screenshot 150 of Figure 15 shows another example of a product list 151. In such a page, the customer 2 reviews the selected goods and/or services that the customer 2 is considering purchasing. The customer 2 has the option of removing any items from the product list 151. Text box 152 displays the total price of the online transaction . The customer 2 can select button 153 to purchase all selected items 154. By selecting the purchase button 153, the customer 2 initiates the transaction, step 21B.

In an alternative embodiment, screenshot 160 of Figure 16 shows another example of a product page 161. The product page contains a cart fragment view 161, and a merchant fragment 163A. The merchant fragment 163A gives an indication of what item the customer 2 is purchasing and the merchant the customer 2 is purchasing from . Item 165A indicates the product name that the customer 2 is browsing. Product image 165B provides a visual aid to the customer 2 as to what it is they are purchasing. Item 165C indicates the quantity the customer 2 is purchasing. Item 165D indicates the price of the item . This may be the price per unit, or the total price if quantity is more than one. Item 165E is a drop-down box that displays any special discounts, offers or promotions. If the customer 2 wishes to qualify for the special discount, offer or promotion displayed in item 165E, the customer 2 can select item 165F to qualify 165G. If the customer 2 is not interested in the special discount, offer or promotion displayed in item 165E, the customer 2 can select item 1651 to dismiss the drop down 1651. Item 164A indicates the merchant's stock number of the relevant item. Item 164B indicates the minimum shipping price. Button 164C allows the customer 2 to buy all merchant products 164D. Button 162A allows the customer 2 to select an item for purchase 162, and initiate the transaction, step 21B.

In an alternative embodiment, if the customer 2 has already purchased the item of interest and/or purchases the item on a recurring basis, the customer 2 can review the product order history 94R, such as the screenshot 170 shown in Figure 17 for instance. The product order history 172 provides details about the nature of the purchase transaction e.g . the time of purchase, sum of money transferred, quantity, etc. The customer 2 can select button 171 to be redirected back to the product information page. The customer 2 can also select the 'unsubscribe' button 173 to unsubscribe 94Q from the product and/or service. The customer 2 will be redirected to confirm 176 that they wish to unsubscribe. The customer 2 can also select button 174 to purchase 177 the product and/or service.

In an alternative embodiment, the security settings/preferences page can optionally be accessed from the settings menu 941. This allows the customer 2 to modify app behaviour based on how easily or quickly they want to be able to place an order. In one option, the customer 2 is prompted to provide a PIN every time they wish to open the app. If the device has fingerprint recognition, this option can also be used. In another option, the customer 2 may undo their latest order. This works by delaying the approval of the online transaction 21G, 94S for two seconds, or a short period of time, and displaying an undo button that prevents the purchase order from being placed. In another option, the customer 2 is presented with an 'instant buy' notification each time a product and/or service is selected by the customer 2. If this option is disabled, the selected product and/or service will simply be added to the user's virtual shopping cart.

It should be noted that the software functionality described above does not have to be implemented on an app. For instance, the customer can authenticate and approve an online transaction on a PC instead of a mobile device in their possession . In such scenario, it may be more appropriate to implement a software module or a software program, such as an .exe file that carries out similar functions to the e-commerce app discussed in this section .

2.3 SYSTEM AND METHOD OF FACILITATING AN E-COMMERCE

TRANSACTION USING PRODUCT ID CAPTURE

In another embodiment, instead of using a browser or app on a computer device to browse and select products and initiate purchases, the customer uses a product scanning app (ID capture app) on a mobile device. This is an alternative mode of engagement. The ID capture app can be used to capture some identifying feature (ID capture) from an actual product that the customer wants to purchase, such as barcode, QR code, product name, product type, brand or even a product image. This can be captured by any suitable ID capture process such as by photo, scanning or the like. The mobile device typically is the same device used to confirm purchases using the purchase request verification app, although that is not essential . Typically, although it is not essential, the product ID capture app also functions as the purchase request verification app, as shown as steps 95 and 98 in Figure 9 for example. It might also function as the product selection app, although this is not essential. More generally, the product ID capture app, with or without the purchase request verification and/or product selection functionalities could be called an e-commerce app. The app could be provided and/or designed by the retailer, third party facilitator, or a third party.

Prior to use, the customer 2 downloads the e-commerce app. This could be downloaded in the same manner as previously described for the purchase request verification and/or product selection app. Once the customer downloads the app, they start-up the app to begin using the e-commerce system .

Logging in and creation of the customer account will be described with reference to the flow diagram in Figures 9, and the screen shots in Figures 10 to 11.

Figure 10 shows a screenshot template 100 of log-in page that the customer 2 sees when they start up the app for the first time. At the top of the screenshot 100 is the welcome/ login text 101 that explains to the customer 2 that they are required to either log into their customer account, or create a new customer account. If the customer 2 already has an existing customer account, the customer 2 can provide their email address 102 and password 103 linked to their customer account. The customer 2 clicks on the sign in/up button 104 to log-in and access the home page 106.

If the customer 2 is new to the e-commerce system, the customer 2 will need to select button 104 to create a customer account 94E. Figure 11 shows a screenshot template 110 of what the customer 2 sees when creating a customer account. Text box 111 contains welcome text and/or explanation outlining the process of creating and using a customer account. The customer provides their address information 94F and their credit card information 94G, and any other information required, which is then saved to the created customer account. The customer 2 provides an email address that can either be linked to a Google™ account, which creates a seamless experience for the customer 2 if the app is being used on an Android™ device. Alternatively, the customer 2 can use an email address of their own choosing. Alternatively, the customer 2 can provide an identifier other than an email address, such as a mobile phone number, or any kind of alpha-numeric identifier. The customer 2 enters their credit card information at 113, or any other type of bank details such as PayPal™, bank account number, Bitcoin™, HOP™ card account, or the like. The customer 2 can also select the terms and conditions button 105 to review the terms and conditions of use 107 of the app and/or the e-commerce system. Once details 112 and 113 are entered, the customer 2 proceeds to complete sign up 114, in which they will be redirected to a home welcome page 94H, before being redirected to the home page 94A, 115.

Product selection and purchase using the product scanning app will be described with reference to the flow diagram in Figures 2 and 9, and the screen shots in Figures 18, 13 and 14.

To select and purchase a product, the customer first finds the product they want, step 21A. They may find the product while out shopping, or they may have the product at home, but want a replacement, for example. The customer 2 opens the app, and the customer 2 is redirected to the home page 180 and/or product ID capture 181, as shown in Figure 18. The customer the uses the app to capture/scan an identifying feature of the product, step 21B. In this embodiment, a QR code will be used as the identifying feature, by way of example, but this should not be considered limiting. In alternatives, the identifying feature could be a barcode, product name or even a product image. Once the customer 2 has captured an image of a QR code linked to an item of interest, the customer 2 can select item 181 to purchase the item of interest 183, or the customer 2 can select button 182 to add the item of interest to the product list 184 at step 94N.

The product page 940, 130 provides further details about the nature of the product of interest. By way of example, the product page 940 displays a product image 131 of interest, as well as the product name 132, and product description/price 133. The app, third party facilitator and/or other part of the system can also hold information about the retailer or retailers that can sell and supply the produce. The customer 2 can select the product information button 134 to access the product information page 136.

Alternatively, if the customer 2 receives a shipping notification 97 that indicates their shipment order has been delivered to their address, the customer 2 can be redirected to the relevant product page 940, 130. Once the customer 2 is ready to checkout, the customer 2 selects button 135, shown in Figure 13 to initiate the purchasing transaction, step 21B. The customer also has the option to select which retailer to buy from, in some embodiments, although in some embodiments there might only be a single retailer that provides any particular product. A transaction request is sent from the app 6B to the third-party facilitator. The third- party facilitator 16 retrieves the transaction data (e.g. e-retailer identification details and the customer reference as entered by the customer, along with product identifiers for the selection of the goods and/or services to be purchased) to the third party facilitator 16, step 21D. This could be termed a "buy request". The third party facilitator verifies the transaction, step 21E.

The customer 2 then receives a buy notification (purchase verification request) 140, such as item 141 on Figure 14 for instance, on the customer's mobile device verification app, step 21F, and the customer has the choice of approving 142, 145 the transaction and payment, or has the option to decline 143, 144 the purchase. Like other embodiments, the customer does not need to be logged in to any account, retailer, facilitator or otherwise. Sending a purchase request validation to a personal mobile device of a customer corresponding to the customer reference, and receiving confirmation from the personal mobile device that the purchase request is valid provides a proxy for validating a purchase via logging in to an account.

If the customer 11 approves the transaction, the mobile device transmits the accepted buy request to the third party facilitator. The server processes 94S the transaction, step 21G, by debiting the bank account, credit card, debit or the like linked to the customer, or otherwise effecting funds transfer to the retailer, before passing the order 94T to the e-retailer for dispatch, step 21H.

In an alternative embodiment, settings menu 941 can be accessed from the home page 94A. The customer 2 has the option to review the terms and conditions 94J, access the help menu 94K, update their credit card details 94L, or change their account password 94M.

In an alternative embodiment, the customer 2 may scan the product identifier on their mobile device without having to open the app. Once the customer 2 has scanned the product identifier, the customer 2 can optionally be redirected to the app. If the customer 2 has already logged in, shown in step 96 as the QR scan purchase method, they are directed to a notification screenshot 141, shown in Figure 14 at step 98. If the customer 2 has not logged in, the customer 2 will be prompted at step 94C to either log-in or sign up to the e-commerce system - similar to as previously described.

In an alternative embodiment, screenshot 160 of Figure 16 shows another example of a product page 161. The product page contains a cart fragment 161, and a merchant fragment 163A. The merchant fragment 163A gives an indication of what item the customer 2 is purchasing and the merchant the customer 2 is purchasing from . Item 165A indicates the product name that the customer 2 is browsing. Product image 165B provides a visual aid to the customer 2 as to what it is they are purchasing. Item 165C indicates the quantity the customer 2 is purchasing. Item 165D indicates the price of the item . This may be the price per unit, or the total price if quantity is more than one. Item 165E is a drop-down box that displays any special discounts, offers or promotions. If the customer 2 wishes to qualify for the special discount, offer or promotion displayed in item 165E, the customer 2 can select item 165F to qualify 165G. If the customer 2 is not interested in the special discount, offer or promotion displayed in item 165E, the customer 2 can select item 1651 to dismiss the drop down 1651. Item 164A indicates the merchant's stock number of the relevant item. Item 164B indicates the minimum shipping price. Button 162A allows the customer 2 to select an item for purchase 162. By selecting the purchase button 162A, the customer 2 initiates the transaction, step 21B.

In an alternative embodiment, if the customer 2 has already purchased the item of interest and/or purchases the item on a recurring basis, the customer 2 can review the product order history 94R, such as the screenshot 170 shown in Figure 17 for instance. The product order history 172 provides details about the nature of the purchase transaction e.g . the time of purchase, sum of money transferred, quantity, etc. The customer 2 can select button 171 to be redirected back to the product information page. The customer 2 can also select the 'unsubscribe' button 173 to unsubscribe 94Q from the product and/or service. The customer 2 will be redirected to confirm 176 that they wish to unsubscribe. The customer 2 can also select button 174 to purchase 177 the product and/or service.

In an alternative embodiment, the security settings/preferences page can optionally be accessed from the settings menu 941. This allows the customer 2 to modify app behaviour based on how easily or quickly they want to be able to place an order. In one option, the customer 2 is prompted to provide a PIN every time they wish to open the app. If the device has fingerprint recognition, this option can also be used. In another option, the customer 2 may undo their latest order. This works by delaying the approval of the online transaction 21G, 94S for two seconds, or a short period of time, and displaying an undo button that prevents the purchase order from being placed. In another option, the customer 2 is presented with an 'instant buy' notification each time a product and/or service is selected by the customer 2. If this option is disabled, the selected product and/or service will simply be added to the user's virtual shopping cart. 2.3 SYSTEM AND METHOD OF FACILITATING AN E-COMMERCE

TRANSACTION USING A KIOSK

As shown in Figure 2, the customer uses a merchant kiosk 33 to access the merchant's electronic catalogue of goods and/or services on offer for sale by the merchant. The merchant kiosk 33 could be stationed in the merchant's store, in a shopping mall, or in any other location that the targeted shopping demographic is likely to encounter the merchant kiosk 33. This kiosk can work in the same way as the browser or app based modes of engagement. The kiosk is in effect a computer built for public use that provides the same function as the browser or app modes of engagement. The merchant kiosk 33 displays the products and/or services that the customer 31 can browse through and decide which goods and/or services he wishes to purchase. Once the customer 31 is ready to proceed to checkout and finalise purchase, the customer 31 enters their email address or some other identifier into the merchant kiosk 34, which triggers the merchant kiosk 34 to transmit a buy request through to the server 35. The customer 31 receives a buy request notification on an authenticated device 32 that is in possession of the customer 31. The customer 31 proceeds to either approve or decline the transaction on the authenticated device 32. If the customer 31 accepts the transaction, the accepted buy request is transmitted from the authenticated device 32 to the server 36, which debits the bank account linked to the customer 31, before passing the order to the merchant 37.

Other modes of engagement could comprise:

• Audio recognition - e.g. song, product

The entire disclosures of all applications, patents and publications cited above and below, if any, are herein incorporated by reference.

Reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that that prior art forms part of the common general knowledge in the field of endeavour in any country in the world.

To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting. Where specific integers are mentioned herein which have known equivalents in the art to which this invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth. It should be noted that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be made without departing from the spirit and scope of the invention and without diminishing its attendant advantages. It is therefore intended that such changes and modifications be included within the present invention.

Aspects of the present invention have been described by way of example only and it should be appreciated that modifications and additions may be made thereto without departing from the scope thereof.