AU2015101887A4 - Online shopping system and method - Google Patents

Abstract

A method of purchase of products by customers, the method comprising: in respect of a plurality of items available from each of a plurality of retailers, obtaining the price of each item for purchase from each retailer; receiving an indicator of a region from a customer (region indicator); receiving a list of items for purchase from the customer; determining the cost of each of the items in the received list for each of the retailers based on the received region indicator; and determining a shopping list for each retailer based on the determined costs.

Description

WO 2016/000044 PCT/AU2015/050375 1 2015101887 03 Μ 2015

Online Shopping System and Method Field of the Invention

The present invention relates to shopping for items utilising an on-line 5 environment, such as via the Internet. Such items include, but are not exclusively, groceries.

Background

Many retailers with so called “bricks and mortar” stores also have an on-line web 10 site store that allows customers to shop from the convenience of their home.

Typically many items are purchased at the same time and often a substantial portion of the purchase is repeated periodically. In some sectors there are also retailers that only have an on-line website store. Many of these websites have specials, that is, items on sale at a discount from the usual price. The specials 15 are often designed to attract customers to the store for the items that are on special in the hope that the customer will purchase other items that are not on sale and thus facilitate a larger overall purchase including goods with a higher profit margin. Further, sales are used by stores to clear out excess stock. Competing stores often have different items on special. Even items that are not 20 on sale often differ in price between stores.

As a result, currently, a purchaser is faced with the option of shopping at multiple stores in order to get the best prices, or attempt to discern what is available from multiple online stores and then decide how to shop. 25 US2002038255 discloses a universal shopping cart that obtains and orders products and services from different merchants located on the Internet. The consumer completes all of their shopping on the shopping site and is not directed to another merchant's site to complete an order. The universal shopping cart 30 provides a monitoring service that allows the consumer to monitor a product for specified criteria. An order injection system places orders for products contained within the universal shopping cart from merchants. Specific ordering details required from merchants external to the shopping site are hidden from the PCT/AU2015/050375 WO 2016/000044 2 2015101887 03 Μ 2015 consumer. For external merchant sites that require a consumer account before allowing the product to be purchased, the shopping site creates a new consumer account without intervention from the consumer. Once the products are ordered, the consumer may keep track of the ordered products from the shopping site. 5 W02001097143 discloses a unified product purchasing service that obtains products from different merchants and presents the user with a consistent user interface irrespective of the merchant. This allows the user to conduct a price comparison between suppliers with a consistent interface. When the user 10 decides on their purchases they proceed by completing a shopping cart without the user needing to complete the shopping carts of the merchants from which the purchase will be completed. Instead this system does it for the user.

Further AU2012100485 describes an online shopping platform for repetitive 15 purchase of a class of products by customers from a designated grocer, where the platform maintains a list of products available for purchase from selected major retailers and wherein the price of each item being offered is ascertained and recorded on a recurring basis so as to determine the lowest price of each product within an identified region in order to offer products to customers located 20 in particular identified regions a price-matched price.

The prior art in this field suffers from some limitations and deficiencies in the offerings of on-line purchasing. 25 The present invention seeks to further advance on-line website shopping so as to provide an on-line shopping platform that provides a better shopping experience. The present invention also seeks to bring advantages of online platforms to better improve traditional shopping experience of users. 30 In this specification the terms “comprising” or “comprises” are used inclusively and not exclusively or exhaustively. PCT/AU2015/050375 WO 2016/000044 3 2015101887 03 Μ 2015

Any references to documents that are made in this specification are not intended to be an admission that the information contained in those documents form part of the common general knowledge known to a person skilled in the field of the invention, unless explicitly stated as such. 5

Summary of the Present Invention

According to the present invention there is provided a method of purchase of products by customers, said method comprising: in respect of a plurality of items available from each of a plurality of retailers, 10 obtaining the price of each item for purchase from each retailer; receiving an indicator of a region from a customer (region indicator); receiving a list of items for purchase from the customer; determining the cost of each of the items in the received list for each of the retailers based on the received region indicator; and 15 determining a shopping list for each retailer based on the determined costs.

In an embodiment the method further comprises calculating an average shopping basket price of the cost of making the purchase of the items in an average shopping basket at each retailer, where the average shopping basket is a typical 20 shopping basket, so as to determine which retailer is “on average” less expensive.

In an embodiment the method further comprises calculating the cost of making the purchase of the items at each retailer. 25

In an embodiment the method further comprises determining the retailer with lowest price for each item and determining the shopping list for each retailer based on the lowest price. 30 In an embodiment the method further comprises including the cost of delivery in the cost of the purchase for each retailer in the calculated costs for each retailer. WO 2016/000044 PCT/AU2015/050375 4 2015101887 03 Μ 2015

In an embodiment the method further comprises determining whether an equivalent product is available that is cheaper than each of the original products in the shopping list at each retailer and calculating the cost of the shopping list with the equivalent product when there is an equivalent product and it is cheaper 5 in place of the original product in the shopping list.

In an embodiment the equivalent product is substantially the same type but of a different brand. 10 In an embodiment the method further comprises determining the price per quantity of each item in the list of items from the customer and determining whether an equivalent product is available that is cheaper per unit of quantity than each of the original product in the shopping list at each retailer and calculating the cost of the shopping list with the equivalent product when there is an equivalent 15 product and it is cheaper in place of the original product in the shopping list.

In an embodiment the method further comprises providing the shopping list to the user. 20 In an embodiment the shopping list is provided to the user in an electronic form via a portable device. In an embodiment the portable device is provided with a check off function that allows the item when taken from the shelf to be checked off from the shopping list. 25 In an embodiment the shopping list for each retailer is injected into an on line shopping cart of the respective retailer for completion of the purchase of the shopping list for the respective retailer.

In an embodiment determining the shopping list for each retailer comprises 30 performing a comparison of the cost of purchase of the items between the plurality of retailers that are located with a defined distance of or deliver to the user’s indicated region and selecting the list for the lower cost retailer. WO 2016/000044 PCT/AU2015/050375 5 2015101887 03 Μ 2015

In an embodiment determining the shopping list for each retailer comprises performing comparison of the cost of purchase of the items between the plurality of retailers that are located with a defined distance of or deliver to the user’s indicated region and splitting the list into sub lists according to one or more 5 criteria such that the purchase can be made from at least two retailers.

In an embodiment the one or more criteria comprise for each retailer adding those items that are lowest in price for the respective retailer to the sub-list for the respective retailer, such that a list is created for each retailer that has at least one 10 (or another selected number) of the cheapest items.

In an embodiment determining the shopping list for each retailer comprises performing a substitution for substantially equivalent products that are cheaper (such as by brand substitution and or product quantity substitution). 15

According to the present invention there is provided an online shopping platform for purchase of products by customers, said platform comprising a computer system having a database and functionally connected to a computer network accessible to the customers, wherein the computer is configured to: 20 in respect of a plurality of items available from each of a plurality of retailers, obtain the price of each item for purchase from each retailer and store the price in the database; receive an indicator of a region from a customer (region indicator); receive a list of items for purchase from the customer; 25 determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the prices stored in the database; and determine a shopping list for each retailer based on the determined costs.

According to the present invention there is provided an online shopping platform 30 for purchase of products by customers, said platform comprising: a storage; WO 2016/000044 PCT/AU2015/050375 6 2015101887 03M2015 a price collecting module for obtaining the price of each of a plurality of items available from each of a plurality of retailers, and for storing said prices in the storage; a customer region receiver for receiving an indicator of a region from a customer 5 (region indicator); a list receiver for receiving a list of items for purchase from the customer; a processor configured to determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the prices stored in the storage; and 10 determine a shopping list for each retailer based on the determined costs.

According to the present invention there is provided an online shopping server for enabling purchase of products by customers, said server comprising: a storage for storing substantially current prices of each of a plurality of items 15 available from each of a plurality of retailers; a customer region receiver for receiving an indicator of a region from a customer (region indicator); a list receiver for receiving a list of items for purchase from the customer; a processor configured to determine the cost of each of the items in the received 20 list for each of the retailers based on the received region indicator and the prices stored in the storage; and determine a shopping list for each retailer based on the determined costs.

According to the present invention there is provided an online shopping server for 25 enabling purchase of products by customers, said server comprising: means for storing substantially current prices of each of a plurality of items available from each of a plurality of retailers; means for receiving an indicator of a region from a customer (region indicator); means for receiving a list of items for purchase from the customer; 30 means for determining the cost of each of the items in the received list for each of the retailers based on the received region indicator and the stored prices; and means for determining a shopping list for each retailer based on the determined costs. 7 2015101887 03 Μ 2015 WO 2016/000044 PCT/AU2015/050375

According to the present invention there is a computer program embodied in a computer readable non-transient storage medium comprising instructions for controlling a computer to: 5 in respect of a plurality of items available from each of a plurality of retailers, obtain the price of each item for purchase from each retailer; receive an indicator of a region from a customer (region indicator); receive a list of items for purchase from the customer; determine the cost of each of the items in the received list for each of the retailers 10 based on the received region indicator and the obtained prices; and determine a shopping list for each retailer based on the determined costs.

According to the present invention there is a user shopping device comprising: an input for receiving an indicator of a region from a customer (region indicator); 15 an input for receiving a list of items for purchase from the customer; a communications device for transmitting the received region indicator and received list of item for purchase to a shopping platform; a receiver for receiving from the shopping platform a shopping list one or more retailers based on the received region indicator, the price of each item for 20 purchase from each retailer and the received list.

In an embodiment there are at least two lists received, where each list is for purchase of goods from one retailer and is determined from the cost of each of the items for each of the retailers. 25

According to the present invention there is provided a method of purchase of products by customers, said method comprising: in respect of a plurality of items available from each of a plurality of retailers, obtaining the price of each item for purchase from each retailer; 30 receiving a list of items for purchase from the customer; determining the cost of each of the items in the received list for each of the retailers; and WO 2016/000044 2015101887 03 Μ 2015 PCT/AU2015/050375 8 determining a shopping list for each retailer based on the determined costs, wherein the list for each retailer comprises the lowest price for each item from amongst the retailers and if a retailer has less than a threshold number of items on its respective list then there is no list for that retailer and those items that 5 would otherwise be on that retailer’s list are put on the list of the next lowest retailer.

According to the present invention there is provided a shopping aid system comprising: 10 receiving a geographic identifier from a user at a processor of a computer, the processor identifying at least one supplier based on the geographic identifier; the processor receiving a product list from the user, wherein the product list includes at least one product; for each said at least one supplier the processor produces a supplier product list, 15 retrieves product values for each product on each supplier product list, and combines the product values to determine a supplier list value; producing the supplier list value for each said at least one supplier for the user.

In an embodiment the processor may obtain the product values from each at least 20 one supplier.

In a further embodiment the shopping aid system may further comprise: the processor comparing the product values of respective products on each supplier product list to determine the lowest cost item for each respective product; 25 removing products from each supplier product list that are not the lowest cost item for each respective product; amending each supplier list value to only include product values of products retained in the respective supplier product list; producing respective supplier product lists for the user which omit the removed 30 goods. WO 2016/000044 PCT/AU2015/050375 9 2015101887 03M2015

Summary of the Drawings

In order to provide a better understanding of the present invention preferred embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which: 5 Figure 1 is a schematic block diagram of a shopping system according to an embodiment of the present invention;

Figure 2 is a system overview of a system according to an embodiment of the present invention.

Figure 3 is a flow chart of an aspect of a shopping system according to an 10 embodiment of the present invention;

Figure 4 is a flow chart of an aspect of a shopping system according to an embodiment of the present invention;

Figure 5 is a flow chart of an aspect of a shopping system according to an embodiment of the present invention; 15 Figure 6 is a flow chart of an aspect of a shopping system according to an embodiment of the present invention;

Figure 7 is a flow chart of an aspect of a shopping system according to an embodiment of the present invention;

Figure 8 is a schematic screen shot presented to a user according to an 20 embodiment of the present invention;

Figure 9 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 10 is another schematic screen shot presented to a user according to an embodiment of the present invention; 25 Figure 11 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 12 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 13 is another schematic screen shot presented to a user according to an 30 embodiment of the present invention;

Figure 14 is another schematic screen shot presented to a user according to an embodiment of the present invention; WO 2016/000044 PCT/AU2015/050375 10 2015101887 03 Μ 2015

Figure 15 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 16 is another schematic screen shot presented to a user according to an embodiment of the present invention; 5 Figure 17 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 18 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 19 is another schematic screen shot presented to a user according to an 10 embodiment of the present invention;

Figure 20 is another schematic screen shot presented to a user according to an embodiment of the present invention;

Figure 21 is another schematic screen shot presented to an administrator according to an embodiment of the present invention; 15 Figure 22 shows example database tables according to an embodiment of the present invention;

Figure 23 shows example database tables according to an embodiment of the present invention;

Figure 24 shows example database tables according to an embodiment of the 20 present invention;

Figure 25 shows example database tables according to an embodiment of the present invention.

Figure 26 is a process flow diagram of an aspect of a shopping system according to an embodiment of the present invention. 25

Detailed Description of Example Embodiments

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed 30 embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. The present invention is not intended to be limited to the embodiments shown, but is to be WO 2016/000044 PCT/AU2015/050375 11 2015101887 03 Μ 2015 construed at the widest scope consistent with the principles and features disclosed herein.

The shopping platform of the invention is an internet-based product marketplace 5 bringing together customers (users of the market place) and retailers and presenting the customers with a choice of pricing for products available for online purchases and in-store purchases. The platform is particularly applicable to the online purchasing of groceries where the same or similar products are purchased repetitively over a period of time, and where there is price differentiation between 10 retailers. However it is not limited to this application.

The first embodiment of the invention is directed to an online shopping platform that provides the customer with convenience by virtue of a single and consistent interface as well as means for obtaining the best or at least a better price for 15 items desired for purchase.

The system aims to compile an extensive and up-to-date collection of supplier products, product matches and match metadata to provide users of the system the ability to more easily and effectively compare product prices between local 20 suppliers. The system could be broken up into two parts. The first is the product data aggregation and product match management. The second is where users browse product matches and create shopping carts to locate the lower priced goods in their area. 25 Referring to Figure 1, there is shown a shopping system 10 including a plurality of user devices 12, 14, 16. Device 12 is a personal computer, device 14 is a smart phone, and device 16 is a portable computing device (for example a tablet). Devices 12, 14 and 16 are connected to a global computer network, such as the Internet 20. System 10 further includes a web server 22, an Application 30 Programming Interface (API) 24 and a database server 26. The server 22 includes central processing unit(s) 502, memory 504, a data storage module 506, an input module 508, an output module 510 and a communication module 512. The server 22 is able to connect to retailer computer systems 30, 32, 34 via the WO 2016/000044 PCT/AU2015/050375 12 2015101887 03 Μ 2015

Internet 20. The retailer systems 30, 32 and 34 may be web servers that allow a customer to make a purchase from the respective retailer and or APIs that allow the web server to access pricing and product information for the respective retailers, S1, S2 ...Sn. 5

The device 12 may connect to the web server 22 by use of a web browser installed on the device 12 in a known manner. Device 14 or 16 may also connect to the web server 22 by use of a web browser installed on the device 14 or 16. Device 14 or 16 may connect to the web server 22 via the API 24 and or an 10 application (App) in a known manner.

The web server 22 generates information that is transmitted over the internet 20 such that the web browser can use that information to generate a webpage for display to the user of device 12,14,16. 15

The API 24 receives a request for information from the device 14, 16 and in response provides information that is transmitted over the internet 20 such that the App can use that information in combination with information stored in the App to display information to the user of device 14,16. 20

The API 24 may also allow approved third party applications to receive requests and provide appropriate responses.

In example embodiments, the server 22 is a computer system configured by one 25 or more computer programs stored on tangible non transient media, such as a hard disk drive, flash memory, CD, DVD etc., so as to be configured as described and so as to perform the method as described. The computer system may constitute a "platform" or "module" that is configured and operates to perform certain operations. In other embodiments, the "platform" or "module" may be 30 implemented mechanically or electronically. A platform or module may comprise dedicated circuitry or logic that is permanently configured (such as within a special-purpose processor) to perform operations as described. A platform or module may also comprise programmable logic or circuitry (e.g. as encompassed PCT/AU2015/050375 WO 2016/000044 13 2015101887 03 Μ 2015 within a general-purpose processor or other programmable processor) that is configured by one or more computer programs (firmware, operating system and or software) to perform as controlled by the computer programs so as to be configured to perform as described. The decision to implement a platform or 5 module according to these options may be made according to cost, expediency or other reasons. Accordingly, the term "module" or "platform" should be understood to encompass a tangible element that is physically constructed and configured to operate in a certain manner and/or to perform certain operations as described. 10

In an embodiment the server 22 comprises central processing unit(s) 502, memory 504, a data storage module 506, an input module 508, an output module 510 and a communication module 512 in the form of a network access device to allow communication with the Internet 20. Typically the data base server 26 is 15 either a database stored in the data storage module 506, or a dedicated server with its own data storage module for storing the database. The system ideally includes two databases. The first database is located in the data storage module server 22. In some embodiments this may be a virtual server. This first database is used by a screen scrapping module to store product data collected by screen 20 scrapper agents. The data may be stored here temporarily and later transferred during the data aggregation process to the primary database, explained below.

The second database, referred to as the primary database, can be located on a separate dedicated server with its own data storage module. 25

Those skilled in the art will realise that for a computer system of the power and data storage required, the system may preferably comprise a plurality of interconnected sub-systems which together implement the functions required to constitute the complete system. They will also be aware that components need 30 not necessarily be located in one physical location. In one form the server is provided by distributed computing resources. WO 2016/000044 PCT/AU2015/050375 14 2015101887 03 Μ 2015

An alternative representation can be seen in Figure 2 which shows a system overview of a preferred embodiment of the present invention. There is seen two broad environments, a client environment 400 and a hosting environment 401 or system. The client environment 400 represents various web-based applications 5 which access the present system via the internet 20. Actual users 404 will ideally be registered or logged on, although may in some embodiments retain guest access. The users 404 can access the system through various input devices 12, 14, 16. 10 The hosting environment 401 in the preferred arrangement would be cloud based, however, ‘physical’ apparatus could equally be used to host the system. Within the hosting environment 401 in the preferred arrangement is a virtual machine 22 linked to an image directory 403, web API 24 and primary database 26. 15 The image directory 403 contains all the publicly accessible product images used by the client environment 400. The API 24 is the application programming interface which receives web requests and returns responses to connected devices 12, 14, 16 via the internet 20. The API 24 also communicates with the primary database 26 in order to query and write data. The primary database 26 20 stores all the data records utilized by the client environment 400, administration portal 410 and data aggregation service 402.

The virtual machine 22 is made up of a data aggregation service 402, administration portal 410, task scheduler 412, and user notification service 411. 25 The administration portal 410 enables a system administrator to manage matches, product and metadata data that may be stored on the primary database 26. The user notification service 411 handles the sending of emails via the sendGridService 407 which facilitates the sending of email messages, and mobile notifications via the cloud messaging service (408) which facilitates the sending of 30 mobile notification messages, for example text or sms messages, as required depending on user alert settings. For example, if enabled, a user may have requested to be alerted when a particular product comes on sale. The task PCT/AU2015/050375 WO 2016/000044 15 2015101887 03 Μ 2015 scheduler 412 is charged with scheduling the various tasks and events, which could for example include sending notifications.

The data aggregation service 402 includes a screen scrapper database 414 and 5 a screen scraping program 413, and is responsible for the data aggregation process which collects product information from supplier servers 30, 32, 34, and merges the data into both the screen scrapper database 414 and primary database 26. Agents 415 are screen scrapper configuration files which make up the instructions to be used by the screen scrapper program 413, which extracts 10 HTML mark-up from supplier servers (S1, S2,..Sn) 30, 32, 34, according to the instructions received from the agents 415. The data extracted from the supplier servers 30, 32, 34 by the screen scrapping program 413 is held in the screen scrapper database 414. 15 The data aggregation service 402 may retrieve data from the screen scrapper database 414. The product data is then parsed 417 which converts each product record collected in the screen scrapping result and stored in the screen scrapper database 414, and formats each record to a compatible structure. Each formatted product record is then merged 418 into the product table of the primary 20 database 26. A further step, if implemented, collects product images 419 by downloading images from the ImageURL of each product record collected from the collect scrapper results 416 and writes them to a location in the image directory 403. 25 The user 404, utilizing an input device 12, 14, 16, would select products for purchase through the web API 24, which facilitates the necessary communications. The products are stored on the primary database 26 and were collected through the data aggregation service 402 which used screen scrappers to collect data from suppliers 30, 32, 34. 30

An embodiment of the shopping method 150 is described first at a high level in relation to Figure 7 and then a more detailed embodiment is described in relation to Figures 3 to 6. In method 150, the user provides a geographic region identifier, WO 2016/000044 PCT/AU2015/050375 16 2015101887 03M2015 such as their suburb at 152. Alternatively the geographic region identifier could be a physical address, or the system could identify the current location of the user. Another alternative is that the system utilises a stored address for the user. The user then builds a shopping list of items desired for purchase at 154. The 5 user can then have the shopping list priced in step 156. The calculation of the total price of the shopping list will be localised to the user entered postcode, physical address or current location, and can make an effective recommendation of one or more of the available shops from which to purchase the items on the shopping list based on price information stored in the database from each of the 10 available retailers in the locality of the user. In particular the list will ideally specify which items to purchase at each of one or more shops and in a preferred embodiment two or more shops, if applicable. The purchase list for each of the shops may be separate shopping lists for each shop. If desired in some embodiments the shopping lists may take into account the delivery price for each 15 retailer to deliver the purchased goods should the user desire to order online. The shopping lists may each be a pick-list for the customer to take to the respective retailer to hand pick the products for purchase, taking into account the price for each of the products desired for purchase. The shopping list may contain, if allowed by the customer, like for like substitutions of equivalent or 20 substantially equivalent products, where the substituted product is lower in cost (cheaper than the original product). The shopping list may contain, if allowed by the customer, quantity substitutions based on price per quantity.

The database stored in the database server 26 comprises a list of products 25 available from various retailers, and their current or substantially current prices. The database may also contain a product identifier (e.g. barcode number, description or picture). Each retailer is differentiated by store location or delivery coverage such that if there are multiple stores, with differentiated pricing according to location or delivery coverage, there will be differentiation in the 30 retailer even though two or more retailers may belong to the same group or chain of stores. This allows the prices checked by a user in a particular location to be the prices provided by their local store, as prices may vary according to locality even within the same chain. 17 2015101887 03 Μ 2015 WO 2016/000044 PCT/AU2015/050375

This database may be generated on the fly as needed or may be periodically updated, such as weekly, daily, or hourly. The database is ideally updated as new products are made available and as products are removed from availability. 5 The database may be updated by interfacing with the retailers’ website or their API 30, 32, 34 or by other means, such as by taking historic purchases and determining from each item purchased the cost divided by the quantity purchased and storing this in the database. 10 The database also ideally keeps a record of all transactions concerned with the platform.

Referring to Figure 3, there is shown a flow chart of a shopping method 100 of an embodiment of the invention. Usually, as a preliminary step, the user signs up to 15 the service via the web or App with their personal information including their postcode. Commencing at 102 a user of one of the devices 12, 14 or 16 (say device 12) visits a website produced by the website server 22 and transferred to the device 12 over the Internet 20. In one embodiment the user is known, such as by registering. The return of the user to the website may be detected by use 20 of a unique identifier of the user, such as a cookie, being provided to the web server 22. The user may be required to login for each use session of use of the platform, such as by providing their username and password, so as to confirm the identity of the user, or other identification techniques may be used. 25 At step 104, the user is then served with a page, such as page 160 of Figure 8. The page 160 has a field 162 for the user to enter a geographic region signifier, such as their suburb. If the user is known, then their postcode, or other address/location identifier, is either prepopulated, may already have been provided, or the system proceeds on the previous address used for the known 30 user. An alternative to a suburb is a postcode or a town name. The system may also utilise the current location of the user determined by their mobile device, for example location services on Apple devices. When the user has entered their WO 2016/000044 PCT/AU2015/050375 18 2015101887 03 Μ 2015 suburb in the field 162 they can select button 164, which transmits the suburb to the server 22.

In the preferred arrangement as the user is typing their location, either as a 5 suburb/town or postcode, the input field that they’re entering their location into will suggest actual known locations based on their input.

The actual known locations can be initially provided as a csv document. This csv file may be imported via a SQL Script into the primary database 26 to a table 10 called Location (Fig 24). This table comprises four fields, namely ID, postcode, suburb and state. In some embodiments it may also be desired to include other fields such as latitude and longitude in the Location table. The ID is automatically allocated to the location record on import into the table. 15 As the user enters a location through their input means such as tablet 16, the underlying javascript framework which in the preferred arrangement makes up the functional component of client website sends a web request to the API 24, the API 24 then calls on the primary database 26 and performs an SQL query on the Location table to find any locations with similar characters to the input by the 20 user. The particular fields the query looks at may be the suburb and postcode fields. Any similar locations are then returned to the user.

From the suggested locations the user must then select 104 their location from the suggestions. The location may then be stored as a javascript object by the 25 client website into the browsers local storage. This means the location may be stored as a variable within the users own web browser.

The user then starts to build a shopping list by either typing in the desired item in the search box where the service will search a products database stored in the 30 database server 26 or by another technique. For example the user may select products via categories 106 or by scanning the barcode of the item they need. Scanning of the barcode may be an option built into an App for the devices 14, 16. When a barcode is scanned, the corresponding code is used to look up the PCT/AU2015/050375 WO 2016/000044 19 2015101887 03 Μ 2015 product in the database server 26, which returns the product information back to the user to be added to the shopping list.

The mobile app may include a barcode scanner utility which utilises the camera 5 feature of the device. When a user comes across an item they wish to find in the catalogue, they must open the app and use the barcode scanning utility.

When the app is opened the user can navigate to the barcode scanning utility which opens the devices camera. When the user hovers over a barcode or clicks 10 the ‘take photo’ button the app will attempt to read the barcode and determine the products EAN or International Article Number. The process of converting the vertical lines of the barcode to an EAN is handled by a third party scripting library such as: https://aithub.com/phoneaap/phoneaap-pluain-barcodescanner. Once this plugin identifies the EAN number of the barcode, the EAN is sent in a web 15 request by the app to the API 24. The API 24 then uses the EAN in a SQL query on the primary database 26 - Matches table. If a match is found with the same EAN it is returned to the device and the user may view details of the item, including for example; name, description, weight and quantity, and pricing. The user may also save this item to a new or existing list. Actions performed around 20 saving and editing lists and their items are performed in a similar manner to other server/database requests, in that the client app or website sends a request to the API 24 and the API 24 then performs either read or write commands on the primary database 26. These actions may be performed on the Profile, Cart and Cartltem tables (Fig 24) and are explained in detail below. 25

As an example, at step 106, the user is then served with a page, such as page 180 of Figure 9, which has a list of product categories 182. The user can then select one of the categories to build their shopping list. For example if the user selects ‘Dairy’ 184 then a page of dairy products , such as page 200 of Figure 10, 30 may be presented. In some cases the product categories will have sub-menus in order to make navigation more hierarchical. For example, dairy may be further broken down into milk, cheese, yoghurt, butter etc. WO 2016/000044 PCT/AU2015/050375 20 2015101887 03 Μ 2015

At step 108, and as illustrated on example 200 of Figure 10, the user is presented with at least one product in the chosen category (or sub-category). In this example, four products 202 are presented. Each product 202 ideally has at least a product description 206 and a quantity to purchase field 210, and usually a 5 picture 204 and a price range per unit 208. It is recognised that some implementations may elect not to include all this information. In an embodiment the price 208 may not be included. The price 208 may be the highest price, a price range of the product at various supermarkets or an average price across the supermarkets. At step 112, the user may be presented with the option of 10 selecting a product size, e.g. 1 litre milk or 2 litre milk. At step 114, the user can select how many of each item to purchase by entering the respective number into the quantity field 210 or by a dropdown menu. Once the selections are made the items are automatically added to the shopping list. There is also the option of calculating the total by selecting button 212. 15

If the user has more items to add to the shopping list, they can repeat the process at screen 180 of figure 9 and select a further product category, and other items. At 116 the selection and addition of products to the shopping list continues until the user has all the items and is ready to proceed to the next step, which is to 20 calculate the totals of the shopping list 118 at each retailer within their local area.

They may also have the option of expanding the locality to surrounding areas or changing the location should they wish to view an area outside their residential location. 25 30

Where available, the system will, if desired, provide additional options of categories e.g.: • Organic • Gluten Free • Dairy Free • Lactose Free • Sugar Free • Wheat Free • Egg Free WO 2016/000044 PCT/AU2015/050375 21 2015101887 03 Μ 2015 • Meat Free • Vegetarian • Australian Made • Superfood 5

Ideally a user will be able to import shopping lists from 3rd party supplier websites. In order to handle this functionality the user must first provide their 3rd party website login credentials to the client website. The user can select the supplier website that they’d like to provide their credentials for and then enter these 10 credentials which should be encrypted and stored against their account in the primary database.

Once the user has selected the supplier and entered their credentials, these three fields are sent in a request to the server over the SSL protocol. On the server, the 15 password is encrypted and then stored with the supplierld and password in the ProfileSupplierLogin table of the database.

Once the supplier credentials are stored against the users profile they may import a list. The user will be prompted to select the supplier they’d like to import their 20 lists from. As they click this button, a popup may open and ask the user to select a supplier. Once they provide the supplier, a request will be sent to the server to begin the list import process.

The import process begins by sending a login request to the supplier website. 25 Prior to the login request being performed the password entered by the user earlier and stored in the database is retrieved and unencrypted. The login credentials are then sent with the login request and an authentication cookie is returned to the server 22 making the login request. The authentication cookie is then replicated on the subsequent request to impersonate the user of the client 30 website on the 3rd party supplier websites and gain access to the account area.

With access to the account area of the user on the 3rd party supplier website, a request to retrieve the unique identifier of each 3rd party supplier list is triggered. WO 2016/000044 PCT/AU2015/050375 22 2015101887 03M2015

From the response returned by this request, individual requests to another predefined URL are performed using the unique identifier of each list. The responses returned by each of these lists provides the server with the data needed to replicate and create each list within the database against the users 5 profile. The details used are the list name and each of the items product Ids. These details are used to construct insert commands against the primary database on the Cart and Cartltem tables.

The retailers may be supermarkets in one embodiment. In other embodiments 10 the retailers may also or alternatively be a seller of one or more other products, for example: • Liquor • Pharmaceutical • Pet care 15 · Baby care • Whitegoods • Electronics • Health • Fuel 20 · Automotive tyres

While reference is made to products in this specification this may in some embodiments also encompass services. For example various beauty services could be considered a product. Similarly, various massage services may also be 25 considered products for the purposes of this specification.

Referring to Figure 4, the process of calculating the totals 118 ideally has a number of calculation options 120, 122, 124, 126 and 128. Calculation 120 provides the store totals and totals up the cost of the shopping list for each 30 retailer in the region (postcode). This is done by multiplying the cost of each item by the number of items selected for purchase, and summing these up for each retailer. WO 2016/000044 PCT/AU2015/050375 23 2015101887 03M2015

These calculations may be performed and stored, with the results displayed as required or they may be performed and displayed according to a selection by the user. 5 Calculation 122 totals the cost of the shopping list by making a substitution for an equivalent product if a generic, related or “home brand” (that is, the brand of the supermarket) is lower in cost

Prior to any calculations the system must first match between two (or more) 10 products. Products are brought into the primary database 26 by the data aggregation process described below. Each product in a match is offered by a different supplier and product records are stored in the Products table (Fig 22). Once a match is established between two products a match record is created. Match records can be stored in a Matches table of the primary database. 15

Also prior to any calculations being made, all match records stored in the Matches table should have the appropriate related group metadata associations assigned. These metadata associations may be created using related groups, which are stored in the RelatedGroups table within the primary database. 20 Additionally, to form a link between a RelatedGroup and a Match, a many-to-many table exists called MatchesToRelatedGroups. A related group record has a group type and the current type options available are; Related, Unit and Tag.

Once the above two prerequisites are met, related savings calculations may be 25 identified. The particular related groups used by calculation 122 are of the type: Related. Once a user has constructed their shopping cart a javascript object within the client website will contain the structure of the cart. When the user reaches the calculations popup by clicking any of the ‘Calculate Totals’ buttons a web request is sent to the API and attached to this request is a JSON (JavaScript 30 Object Notation) representation of their shopping cart, which is a lightweight data-interchange format.. WO 2016/000044 PCT/AU2015/050375 24 2015101887 03 Μ 2015

The API uses this representation of the shopping cart to determine which items to find lower cost alternatives for. The logic within the API looks at each cart item. Each of these cart items has an associated match ID. Using this match ID a SQL query is performed across the Matches, Products, MatchesToRelatedGroup and 5 RelatedGroups tables. The query returns an in-memory collection of the matches associated to the users cart items. With each of these matches is also a collection of alternate match records which were found to have the same RelatedGroup as the original match. A constraint put on the query is that the related group must be of type: Related. Therefore all the related matches are restricted to a type of: 10 Related.

With this in-memory data set on hand, the API logic performs an in-memory (not against the database) query for each of the active suppliers in the database table: Suppliers. For each supplier ID, the in-memory query finds the product on the 15 initial match with the same supplier ID, and then looks at the corresponding products in the collection of alternate match records which has the same supplier ID. If there is a cheaper product on one of the alternate matches (with the same supplier ID) then this product is identified as the lower cost alternative. The criteria for identifying a lower cost options is by subtracting the value in the 20 Discount field of the Product record to the Price field. The result is the total discounted price of the product.

Using the lower cost alternative the price difference is worked out between it and the product on the initial match by the same supplier. Each cart item is examined 25 this way and all price differences will be combined to form a total price difference. This is done for each supplier and the total difference amount is returned from the API to the client website to be displayed in the calculations popup window as the total related savings amount. 30 Calculation 124 totals the cost of the shopping list for each quantity unit (e.g. weight or volume). WO 2016/000044 PCT/AU2015/050375 25 2015101887 03 Μ 2015

The particular related groups used by calculation 124 are of the type: Unit. Once a user has constructed their shopping cart a javascript object within the client website will contain the structure of the cart. When the user reaches the calculations popup by clicking any of the ‘Calculate Totals’ buttons a web request 5 is sent to the API and attached to this request is a JSON representation of their shopping cart.

The API uses this representation of the shopping cart to determine which items to find lower unit cost alternatives for. The logic within the API looks at each cart 10 item. Each of these cart items has an associated match ID. Using this match ID a SQL query is performed across the Matches, Products, MatchesToRelatedGroup and RelatedGroups tables. The query specifies that all results must have the same related group as the initial match, and that this related group must have a type of: Unit. The query returns an in-memory collection of the matches 15 associated to the users cart items. With each of these matches is also a collection of alternate match records which were found to have the same RelatedGroup as the original match. A constraint put on the query is that the related group must be of type: Unit. Therefore all the related matches are restricted to a type of: Unit. 20 With this in-memory data set on hand, the API logic performs an in-memory (not against the database) query for each of the active suppliers in the database table: Suppliers. For each supplier ID, the in-memory query finds the product on the initial match with the same supplier ID, and then looks at the corresponding products in the collection of alternate match records which has the same supplier 25 ID. If there is a cheaper unit-cost product on one of the alternate matches (with the same supplier ID) then this product is identified as the lower unit-cost alternative. The criteria used to identify a lower unit-cost alternative is to first check for a cheaper CupPrice field amount. If there are no cheaper alternatives by CupPrice, the logic will check if the PerGroupQuantity field multiplied by the 30 PerGroupPrice field equates to a lower unit price than the original products Price field multiplied by the same PerGroupQuantity field. PCT/AU2015/050375 WO 2016/000044 26 2015101887 03 Μ 2015

Using the lower unit-cost alternative the price difference is worked out between it and the product on the initial match by the same supplier. Instead of determining an exact price amount the system will work out the savings comparison as a percentage to the initial price. Each cart item is examined this way and all price 5 differences will be combined to form a total price savings percentage. This is done for each supplier and the total savings percentage is returned from the API to the client website to be displayed in the calculations popup window as the total unit savings percentage. 10 Calculation 126 performs a calculation of an average shopping basket and then calculates which retailer is cheaper at the time.

Calculation 128 totals the cost for each retailer and shows the cheapest items for each store, as well as a combined cost if the user wishes to split the shopping list 15 according to the cheapest prices at a plurality of retailers.

The split shop calculation can identify savings. Once a user has constructed their shopping cart a javascript object within the client website will contain the structure of the cart. When the user reaches the calculations popup by clicking any of the 20 ‘Calculate Totals’ buttons a web request is sent to the API and attached to this request is a JSON representation of their shopping cart.

The API uses this representation of the shopping cart to determine which items to find lower cost alternatives for. The logic within the API looks at each cart item. 25 Each of these cart items has an associated match ID. Using this match ID a SQL query is performed across the Matches and Products tables. The query returns an in-memory collection of the matches associated to the users cart items. From each of these matches, the products are split by supplier and a price comparison is made. The criteria for the total price of each product is by applying the value in 30 the Discount field of the Product record to the Price field. The resulting price is the discounted price and these values are summed for each supplier. The totals for each supplier are now identified and the logic moves to calculating the cheapest total discounted price which can be achieved if the user decides to select the WO 2016/000044 PCT/AU2015/050375 27 2015101887 03 Μ 2015 cheapest alternatives for each cart item. To identify this value, the logic totals the cheapest discounted price for each product in each match.

The total discounted price for each supplier as well as the total discounted price 5 achievable by the split shop method is returned from the API to the client website and displayed in the calculations view.

Figure 5 shows the options 130 from when the user has completed the creation of a shopping list. In option 132 the user can create and save further shopping lists 10 (including updating an existing shopping list). Thus the user is able to create multiple shopping lists. These lists will be stored within the database and accessible from the mobile device 14, 16 and the device 12, via a web platform. Users will be able to name the lists as well to be able to create specific lists for specific purposes. 15

When users visit the client website, shopping carts may be created, edited, stored and removed by the underlying javascript framework, as javascript objects. When the user interacts with any of the quantity increase/decrease or remove buttons across the website, cart items, which are stored as an array on the cart object are 20 either added, removed or modified. When a user reaches a related shop, unit shop or split shop pages and proceeds to make an alternate item selection or split shop selection, item selections, which are stored as an array on the cart item object are either added, removed or modified. The cart object comprises a name and an items array and are the basis of any shopping list. 25

Cart items can be made up of a match ID, quantity value, order value, split shop selection ID and an array of selections. The match ID ties the cart item to a particular Match record in the database, the quantity value indicates how many of the item the user wishes to buy and the order value maintains the order in which 30 the item was added. The order value is used to sort item lists when they’re returned from the API to be rendered on a webpage. The split shop selection ID is the ID of a supplier that the user may have chosen during the split shop process. WO 2016/000044 PCT/AU2015/050375 28 2015101887 03 Μ 2015

Item selections comprise a supplier ID, match ID, product ID, type and selection order. Item selections are used to identify selections made from within the related and unit shop pages. The supplier ID indicates which supplier list the selection was made to. The match ID identifies the underlying match record of the alternate 5 selection, this will be different to the initial cart item match as at this point an alternate match has been chosen and so the match chosen earlier has been superseded. The product ID identifies the product record of the selection, as a selection is made at the supplier level we have access to the particular product record. The type field indicates the related group type that the selection was 10 made against, this can be either Related or Unit. The selection order specifies in what order the selection was made, a higher value indicates that the selection was made most recently. The selection item with the highest selection order is the current selection and all calculations will be performed against this item and not an earlier selection. 15

As carts are created in the client website the user can choose to save the list against their profile by clicking any ‘Save’ icon. Upon clicking the ‘Save’ icon, a web request is made to the API. Attached to the request is the active cart that the user has constructed from within the client website. When the request reaches 20 the API, the cart is deconstructed and insert, update and remove commands are executed against the Cart, Cartltem and CartltemSelection tables located in the primary database. A cart may be linked to a particular user via their Profile ID which can be allocated to them during registration. 25 Cart renaming is possible and occurs via the same process as saving a cart, however only the cart name is modified. Cart items can also be assigned to lists by selecting the ‘list’ icon located next to a product in the search/browse view. Clicking this icon retrieves the users current collection of lists from the primary database via the API. The user can then proceed to append an item to an existing 30 list by selecting the list, this in turn triggers a cart item insert command in the primary database via the API, with the mandatory Profile ID, Cart ID and Match ID being passed to the API in a web request. PCT/AU2015/050375 WO 2016/000044 29 2015101887 03 Μ 2015

The user also has the option of creating a completely new list this way and appending the item in question to this list. This is achieved by the user entering a list name in a provided text field, upon pressing enter a web request will be sent to the API with the mandatory Profile ID, name and Match ID. These values will 5 be used to first trigger a cart insert command and then a cart item insert command.

The user can view a list of their currently saved carts by accessing the List view in the client websites Account section. Upon reaching this page a call to the API will 10 trigger a query command on the primary database, at which point a list containing the users saved carts will be returned.

At this point the user has the option of clicking the ‘Calculate Totals’ button. Upon clicking this button a web request is sent to the API and the entire data structure 15 of the cart is retrieved from the primary database and returned to the app in JSON format. This JSON result is then serialized into a javascript object and assigned into the active cart javascript object in the users browser. This cart is then handled identically to any list constructed from scratch via the search/browse view. This cart can be modified as the user wishes. 20

All API requests available to the client website should also be available from the mobile app and would be handled in the same way. i.e. as standard AJAX web request. 25 Referring to Figure 14, the user may have a number of shopping lists saved, such as those listing in the example of Figure 14. The user may provide a summary 352, for example, ‘Weekly Shop’, of each list and then at a later time return to the saved shopping lists and select one for comparison or purchase when desired. 30 Users will preferably have the option to convert their shopping list to the shopping cart of their retailer/s of choice. In order to handle this functionality as noted above the user must first provide their 3rd party website login credentials to the system or client website. The user can select the supplier website that they’d like PCT/AU2015/050375 WO 2016/000044 30 2015101887 03 Μ 2015 to provide their credentials for and then enter these credentials which will be encrypted and stored against their account in the primary database.

Assuming the above precondition has been met, the user will ideally have the 5 ability to send their completed lists from the client website to a 3rd party supplier website. When the user has completed constructing their shopping cart and navigated to either the split shop checkout or supplier specific checkout the user can select to send the list to a supplier/supermarket. 10 The send process begins by sending a login request to the supplier website. Prior to the login request being performed, the password entered by the user earlier and stored in the database is retrieved and unencrypted. The login credentials are then sent with the login request and an authentication cookie is returned to the server 22 making the login request. The authentication cookie is then used on 15 the subsequent request to impersonate the user of the client website on the 3rd party supplier websites and gain access to the account area.

With access to the account area of the user on the 3rd party supplier website, a web request to a predetermined URL responsible for performing a cart item insert 20 command on the supplier website is constructed. Attached to this web request is the supplier specific product ID which is stored against the Product record.

One request is performed for each of the cart items in the users active cart, completing the cart conversion process from the system cart to 3rd party supplier 25 cart.

They can then pay the retailer/s for their items and have them delivered. Returning to Figure 5, in option 134 the user can select a simple comparison option from a selected shopping list to be taken directly to the type of display 30 shown in Figure 15.

The user can view a list of their currently saved carts by accessing the List view in the client websites Account section. Upon reaching this page a call to the API will WO 2016/000044 PCT/AU2015/050375 31 2015101887 03 Μ 2015 trigger a query command on the primary database, at which point a list containing the users saved carts will be returned.

At this point the user has the option of selecting ‘Calculate Totals’. Upon making 5 the selection a web request is sent to the API and the entire data structure of the saved cart is retrieved from the primary database and returned to the app in JSON format. This JSON result is then serialized into a javascript object and assigned into the active cart javascript object in the users browser. 10 If for example the “Weekly Shop” shopping list is selected from screen 350 of figure 14, the system can perform the required calculations and return with a screen 360 as shown in Figure 15, which provides a summary of the total cost of the shopping list from Supermarket 1 at 362, the total cost of the shopping list from Supermarket 2 at 364 and the total cost of the shopping list at 366 from a 15 split of Supermarkets 1 and 2 according to the calculation 128 described above.

Figure 6 shows options 140 for delivery or other collection of the items purchased if desired by the user. In option 142 once the user selects a single store to purchase the list from (which may default to the lowest priced store) the shopping 20 list is converted into a shopping cart in the selected store for delivery to the user. This occurs by the web server taking the user to the retailer’s shopping cart website and injecting the shopping list and delivery details into the retailer’s shopping cart. 25 In option 144 the user selects to split the shopping lists between two or more stores to purchase. Conveniently this could be the split shopping determined above. The system depending on the implementation may, or may not, include delivery costs, if any, in the calculations. The respective shopping lists would then be generated for the respective stores for delivery to the user. This occurs 30 by the web server taking the user to the retailers’ shopping cart websites and injecting the respective shopping list and delivery details into the respective retailers’ shopping carts. WO 2016/000044 PCT/AU2015/050375 32 2015101887 03 Μ 2015

In option 146 the user selects one or more stores to purchase from and the respective shopping lists are generated for the respective stores for the user to collect. There are two options here, one is for the web server to inject the respective shopping list into the respective retailers’ shopping carts and taking the 5 user to the retailers’ shopping cart websites where the user will collect the items from the retailer if a “click and collect” option is available from the store. The other option is for the respective shopping lists to be provided for the user to manually shop at each retailer using the respective shopping list. In this case, if there is a difference between the in-store price and the on-line price, the 10 calculations 118 may use the in-store prices, rather than the on-line shopping prices or vice versa.

In the event that a user of the client website decides to manually shop at a respective supplier’s store using the shopping list generated by the client website 15 they have a number of options. a) Send to Print. The user clicks the ‘Send to Print’ option from either the Split Shop or Supplier Checkout view. Upon clicking this button the client website will trigger a web request to the API. Attached to this request will be the ID of the cart 20 that the user wishes to shop for. The API logic then executes a SQL query for the cart and its items as displayed in the current checkout view that the user is looking at. This dataset will be returned and ideally rendered in a new printer friendly window. The html markup rendered is constructed in a way that is suitable for print, that being that each cart item will be laid out on its own row and 25 not forced onto a new line by the print view of the web browser. A javascript call then opens up the print document window associated with the browser that the user is using. They are then prompted to click the print button to print out their shopping list using a printer connected to their machine. 30 b) Send to App. The user clicks the ‘Send to App’ option from either the Split Shop or Supplier Checkout view. Upon clicking this button the client website will trigger a web request to the API. The server logic associated with this request will trigger an update command on the cart record which will flag the cart as visible WO 2016/000044 PCT/AU2015/050375 33 2015101887 03 Μ 2015 from within the app. When the user subsequently opens the app and views their active shopping lists, a web request will be made to the API to retrieve their lists. This request will return the carts currently marked as visible within the app by querying the primary database via the API. At this point the user will be able to 5 click on the list they wish to shop for which will trigger another request to the API to load the list, from the primary database via the API, and store it into the devices memory. This cart will then be rendered in a simple shopping list styled layout for the user to shop by. 10 c) Send to Email. The user clicks the ‘Send to Email’ option from either the Split Shop or Supplier Checkout view. Upon clicking this button the client website will trigger a web request to the API. Attached to this request will be the ID of the cart that the user wishes to shop for. The API logic then executes a SQL query for the cart and its items as displayed in the current checkout view that the user is 15 looking at. The API logic then proceeds to construct an in-memory string of html markup which is attached as the body of a html format email to be sent the users email address. Once the email is constructed with each cart item formatted inside the html email body, the message is delivered via an API web request to the 3rd party email relay service, SendGrid, then onto the users email provider. 20

In one embodiment the shopping lists are provided to the device 14, 16 and the user can check off the list as they shop using the App.

Figure 11 shows possible results of calculation 120 that could be displayed 250 to 25 a user in an embodiment of the invention. For a first retailer, e.g. Supermarket 1, various costs of the shopping list are displayed 252. These may or may not include shipping costs depending on the system and user selections. The standard costs for shopping at that retailer are displayed in 254 based on the standard price of the item when not on sale. Next the savings resulting from 30 sales are displayed in 256 by taking into account the savings from items on sale.

When the user opens up the calculation popup by clicking a ‘Calculate Totals’ button from either their cart or the search/browse page, a web request is sent to WO 2016/000044 PCT/AU2015/050375 34 2015101887 03 Μ 2015 the API with a JSON representation of their shopping cart attached. The logic in the API first queries to primary database to identify all active suppliers present in the Suppliers table. For each supplier in this table a sequence of calculations are executed to determine what values to return to the client website to present 5 alongside the radial savings strength display.

The first step in the sequences is to obtain an in-memory collection of all the match records associated with each cart item. In addition to the initial default match records tied to the cart item, all the match records of each of the cart item 10 selection objects must be retrieved also. This is done by querying the database for all match records which have an ID which is the same as the match ID on either the cart items or on the cart item selections. The query is performed on the primary database Matches and Products tables. 15 The next step in the sequence is to iterate over each cart item and increment a set of values. The values to be incremented are; Total Price, Total Discounted Price, Related Savings and Unit Savings Percentage.

As each cart item, and their respective match record, is traversed, the Product on 20 the match linked to the supplier in question will be examined. The Price value of the Product is added to the Total Price value, also the Price value minus the Discount value is added to the Total Discounted Price value. Then, if the cart item has any selections, each of these is iterated in the order define by the item selection Order value. 25

The cart item selection will have a reference to its own match, which is different to the match associated with the cart item itself. The item selections’ match will be found in the in-memory collection of matches initialized earlier. From the item selection match record, the product associated with the supplier in question will 30 be examined. If the item selection has a type of: Related, then the logic will identify the difference in price (Price - Discount) between the item selections product and the product tied to the default match on the cart item, which was examined immediately before. The price difference will then be added to the WO 2016/000044 PCT/AU2015/050375 35 2015101887 03 Μ 2015

Related Savings figure and the logic will then move onto the next item selection. If the next item selection is of type: Unit, then the logic will work out the cost difference in percentage terms of the item selection Product CupPrice value, to the previous item selections Product CupPrice value. The percentage different 5 will then be added to the Unit Savings Percentage value.

The examination of each product can be performed in order, from the Product on the default Match, to the Product on the first ordered item selection and then onto the next ordered item selection, with each examination comparing the product to 10 the previous one. There is no limit to the ordering of item selection types. For example a Unit shop selection can be made before the Related shop selection.

Once all items have been traversed, the resulting values, Total Price, Total Discounted Price, Related Savings and Unit Savings Percentage will be returned 15 from the API to the client website.

The Total Price can be assigned to one label. The Total within the radius savings strength display could be determined by the following algorithm: (Total Discounted Price - Related Savings) * Unit Savings Percentage. 20 To obtain the Savings value the Total is subtracted from the Total Price.

Additional savings may be obtained by the provider of the platform negotiating additional discounts with retailers. Next, the total of the shopping list is displayed in 258, which is the total standard cost less the savings. The result of calculation 25 120 for each retailer can be displayed to a user in a side by side comparison in this embodiment. For a second retailer, e.g. Supermarket 2, various costs of the shopping list are displayed 260. The standard costs for shopping at that retailer are displayed in 264. Next, the savings from using the present system are displayed in 266. Next, the total of the shopping list is displayed in 268, which is 30 again the total standard cost less the savings.

The user can thus see the calculated comparison between the alternate retailers and in this embodiment can decide on which retailer to proceed with a purchase WO 2016/000044 PCT/AU2015/050375 36 2015101887 03 Μ 2015 from. The cheapest retailer based on the totals 258 and 268 may be highlighted to the user. The user will also have the option to display the cost saving per individual item across all their selected items. Figure 12 shows the display 280 of a breakdown of the costs of each list for each retailer 284 and 286 of each item in 5 the shopping list 282.

Prior to any list breakdown is the establishment of matches between two (or more) products. Each product in a match is offered by a different supplier and product records are stored in the Products table. Once a match is established 10 between two products a match record is created. Match records can be stored in the Matches table of the primary database.

When the user has constructed a shopping cart, the user is able to click on the ‘Calculate Totals’ button to view the calculations result page. They may then click 15 the ‘Split shop’ button to navigate to the split shop view. Upon landing on this page a web request is sent to the API with a JSON representation of the users shopping cart attached. The logic within the API looks at each cart item. Each of these cart items has an associated match ID. Using this match ID a SQL query is performed across the Matches and Products tables. The query returns a 20 collection of the matches and their associated products, with one product per match per supplier being a system limitation. These match results are then sent back to the client website and rendered in the list view. What is displayed in the view is one match per row with 2 products, one for each supplier. 25 Under 284 the itemised list for Supermarket 1 is shown. Under 286 the itemised list for Supermarket 2 is shown. Each item 282 in the list has its respective price 290. The list also highlights the lower of the two prices, for example 290 shows the price of Cereal as $12.88 for Supermarket 2, which is lower than the price for Supermarket 1. 30

Calculation 128 can then be used to perform a ‘split shop’, which is where the shopping list is split to show the cheapest items from each store in their area, if the user chooses to 20 shop at more than one store to maximize savings. In this PCT/AU2015/050375 WO 2016/000044 37 2015101887 03 Μ 2015 case the split is in two, with the lower cost items for Supermarket 1 going to a list for Supermarket 1 and the lower cost items for Supermarket 2 going to a list for Supermarket 2. 5 Figure 13 shows a variant embodiment of Figure 12, in which the comparisons of Supermarket 1 and Supermarket 2 are made and shown in display 300 where a Split Shop Calculation is shown. In this the Total standard costs are shown at 304. The savings are shown in 306. The total costs when using this system are shown in 308. The total savings are derived from the total standard cost of the 10 split shop, less the savings. The display 280 of Figure 13 may be created if the user selects on the combined total 366 of Figure 15.

In order to display up-to-date product data, a series of processes should occur, and these processes should ideally occur at regular intervals. 15

The first process of data aggregation utilizes screen scrapping technology to collect product information from various supplier websites. This data is merged and individual products are matched, categorized, grouped and tagged accordingly. 20 A screen scrapper agent is an instance of a saved configuration file which instructs the scrapper software what to do. Conveniently one agent is configured for each of the active Suppliers. Once a scrapper agent has been started, it will feed instructions to the underlying program. The instructions will drive the 25 software to the target website, such as supermarkets online site. Here, the agent configuration will instruct the program to traverse the underlying html structure of the target website. The agent will find patterns in the html which indicate elements that the instructions are intended to follow. This may be a list of Products or a navigation structure which, when clicked on, will lead to a collection of Products 30 offered by the supplier. When a product collection is identified in the html markup, each product will be traverse and the product data embedded in the html markup of the product element will be stored in the storage module of server 22. The information captured from the html markup may comprise these properties: Code, WO 2016/000044 PCT/AU2015/050375 38 2015101887 03 Jul2015

Name, Category, SubCategory, SecondSubCategory, Brand, VolumeSize, Price, Discount, PerGroupQuantity, PerGroupPrice, CupPrice, CupWeight and the ImageURL. 5 A separate scheduled task exists to merge the data collected by the agents into the primary database. The scheduled task, named ‘Process’ is configured to run a predetermined time after the scrapper agents have completed, for example one hour. The task triggers the Process command of the Data Aggregation Service, which is a windows service installed on server 22. 10

The first step in the process command is to query the primary database to get all active suppliers from the Suppliers table. The process command assumes that each supplier has an agent configured on the server 22. 15 Each supplier is iterated over and a command is called to retrieve and in-memory collection of all product records collected during the scrapping process of that agent. This command is assumed to contact the database instance located in the storage module of server 22. 20 With the products for a particular supplier returned each item is traversed one by one and merged into the primary database Product table. The process of merging the product record involves checking to see if a product from the source table (local database) exists in the target table (primary database). This is done by querying the target table by supplierld and product code - the product code being 25 the code that the supplier has allocated to the particular product. If no product is found then the product is inserted into the target database, otherwise if it is found then its properties are updated from the source table.

Figure 21 shows a possible Matches page of the administration portal. The 30 administration portal could be setup on server 22 and enables administrators to manage product matching and match metadata which is ultimately used by the client website. PCT/AU2015/050375 WO 2016/000044 39 2015101887 03 Μ 2015

When a product has arrived in primary database the administrator can assign that product to a match. Figure 21, label (1), indicates a searchable list of products which have come from the primary database. This list can be searched using the search input at label (2). When the administrator identifies a product 5 with matching characteristics, clicking on the product from the list at label (1) will add the product as the currently matched product. If there is already a product from the same supplier connected to the match then this product will be unmatched and superseded. When a product is matched the Match ID field associated with the Product record in the primary database is set to the ID of the 10 match in question. Products can also be explicitly removed from a match by clicking the ‘Remove’ button to the right of the item in the list at label (3), this ultimately triggers an update command to the primary database to set the Match ID field on the Product to null. 15 A match will have categories and related groups (of type Related, Unit and Tag) created and updated through the administration portal’s Matches page also.

Figure 21, label (4), identifies the fields that can be used to make adjustments to the details of a match, these inputs relate to the fields on a match record in the 20 Matches table.

Categories can be assigned to a match via this page also. Categories are stored in the Categories table of the primary database and were imported via a once of import from a csv document. When the users clicks the ‘Add category’ button next 25 to label (5), the list of available categories is provided from a top down hierarchy, starting at level 1 categories and moving to either level 3 or 4. A match can have multiple categories assigned to it and these are associated in the primary database by the MatchesToCategories many-to-many table. 30 Related groups behave in a similar way to categories and are associated in the primary database by the MatchesToRelatedGroup many-to-many table. WO 2016/000044 PCT/AU2015/050375 40 2015101887 03 Μ 2015

Removing a related group or category deletes the record in the many-to-many table.

Users can then compile a product list and compare the individual products of the 5 matches between suppliers. The user can ideally be provided with a summary price for their list and a breakdown of savings using multiple methods of product comparison including related group and unit cost comparisons.

The product data aggregation may occur at a weekly interval and could be run 10 from a Virtual Machine located in a cloud hosting environment. The screen scrapping program will likely target websites of leading suppliers. For example in Australia Woolworths and Coles, and in the US, Kroger and Costco.

Alternatively, rather than screen scrapping the system may seek to gain access to 15 a suppliers product catalogue via API provided by them, or alternatively, entering product information from a supplier website manually.

In the event that a supplier made an API available, the API would be able to trigger web requests to the API to gain product information and pricing data. 20

The other alternative of manually entering product information would involve an administrator viewing each individual product on a supplier website and manually creating or updating an equivalent Product record in the primary database. This would not be an ideal solution as it would be very resource intensive. 25

Each target website requires its own scrapper agent, and these are configured to traverse each of the websites online shopping catalogues and collect a snapshot of each active product and its relevant product data. Key details collected could include the products unique code, name, description, volume size, price, 30 discount, unit weight/price and image URL. The actual details collected will depend on the implementation. WO 2016/000044 PCT/AU2015/050375 41 2015101887 03 Μ 2015

It is anticipated that the agents will typically take between 1 and 2 hours to complete the website scrapping and the resulting data could be temporarily stored in a local database. Conveniently the website scrapping could be undertaken to commence at 3 am every Thursday morning. If the agent typically 5 takes 75 minutes to complete, the process command explained above could be configured to execute at 6 am on Thursday morning. That is one hour after the agent is expected to finish.

Following completion of the website scrapping each record is subsequently 10 processed so that it’s in an appropriate format. The formatted data is then merged into and stored in the active database.

Each product should be imported into the primary database with adequate information stored against each field in its Product record. This is to ensure that 15 all calculations have enough information to identify savings and also to ensure that an adequate amount of product information is visible in the client website for the user to see. The particular format that a supplier product should preferably be added to the primary database in is as follows. A supplier product code must be present otherwise there is no way of identifying existing products from the same 20 supplier with in the Product table. This is the key used to merge product data collected from the scrapper agents back into the Product table of the primary database. The second mandatory field is the Name, this is needed to identify a product to both the administrators and users on the client website. The third mandatory field is the VolumeSize field of the product record. This field used to 25 extract weight and quantity values into their respective fields in the product table; Weight, Weight Definition, Quantity, Quantity Definition. These fields are necessary to assist grouping products in the automated matching process. By having all weights deduced to ml or grams instead of an alphanumeric VolumeSize value, the automated matching process can group products more 30 accurately. The last mandatory field is the Price field, this is needed to allow for basic calculations and is the minimum required price related field. Without any of these fields, a product is prevented from being added to the Product table and PCT/AU2015/050375 WO 2016/000044 42 2015101887 03 Μ 2015 included within the system of the preferred embodiment. The uniformity of a Product comes from these minimum required fields being present.

An example of the processing that occurs is one supermarket may include the 5 brand name inside each product description. In order for the system to effectively offer product comparisons to its end users, the brand should be stripped out into a separate field so that it reflects the format of a second supermarket. Having all records in a consistent format is a prerequisite for the comparisons engine. Another example is the separation of the weight, weight definition (e.g. ‘grams’), 10 quantity and quantity definition (e.g. ‘pack’) from the individual volume size field. As the comparisons of the product can rely heavily on weight and quantity values, these should be split into individual fields in the database and should not be left as a string such as ’20gram 2pack’. This particular separation can be performed using an extensive list of Regular Expressions. 15

Every product merged from the source scrapper products to the target primary database product should undergo the volumeSize extraction process. The list covers as many different variations of the volumeSize field as possible. Some examples of the regular expressions: 20 \b\d*\s*pk\spunnet\b .. .against 7pk punnet

This expression returns a quantity value of 7, and a quantity definition of ‘punnet’. \b\d*[\s\d]x(?=[\d]) ...against 2x200g

This expression returns a quantity of 2, and a definition which is programmatically defaulted to ‘each’. It also returns the weight of 200.00, and a weight definition of 25 ‘g’.

An extensive list of regular expressions is required to ensure each product entered into the primary database is in a uniform manner.

The result is that the up-to-date product data is stored in the primary database in 30 a uniform format which can be readily used for comparisons and calculations. Preferably the system will include an image collection step. This step uses the image URL’s collected in the screen scrapping step to retrieve the image for each product. These images can then be stored inside a folder for use by the system. 43 2015101887 03M2015 WO 2016/000044 PCT/AU2015/050375

The sub-task triggered at the completion of all product data being merged in the Process command explained above is the Image Collection process. 5 Each product captured by each of the screen scrapper agents is iterated over and the ImageURL property is used to trigger a HTTP request to the image location on the internet. Alternatively the images may be obtained through access to third party providers. Once this image is retrieved it is stored in a folder in the Data Aggregation services root directory. The image is stored with a unique and 10 identifiable name, the format of the name being [SupplierlD]_[ProductCode]. So in an example of a Coles product with a product code of 1234567J and in JPG format, the resulting image name could be: 2_1234567J.jpg.

An image is saved locally for all products collected which have a valid ImageURL 15 and also the returned response from that ImageURL returns a successful HTTP response status code of 200. This byte response of the HTTP request is then written to the local folder for use by the next step. On completion of the initial image collection for each supplier, the executing logic queries the Matches table of the primary database for all existing matches. 20

Each of these matches is traversed and the local image of the associated Product records is brought into memory. For each match the logic then compares the image size of the two products by and whichever is larger is used at the image for that match. The larger image is chosen to provide the user with the most high 25 resolution graphic available for the match. After each match is processed this way the image collection process is concluded

While a collection of products for each supplier is stored in the primary database, these products do not immediately have a connection to the same product of 30 another supplier. As product matches are important for comparison and calculation functionality, as many products as possible should have a connection, or match, to a product in the opposing suppliers collection. WO 2016/000044 PCT/AU2015/050375 44 2015101887 03 Μ 2015

One advantage offered by the system to any user is the ability to find a lower cost alternative to a product that a user is interested in buying. Although the related shop and unit shop features allow the user to find cheaper alternative offered by the same supplier, the remaining price comparisons displayed on the website are 5 focused on comparing product prices between suppliers.

To enable this, an overarching Match record which encapsulates two Product records from differing suppliers is necessary. A match can be seen as the facilitator of a comparison between to products. It is also the most logical entity to 10 attach metadata to, such as categories and related groups. This is because the match is the actual object that constitutes a cart item. The user will search or browse the website for known matches, as only matches can offer a usable comparison, not the individual products by themselves. 15 As an example, the split shop feature explained above refers to the comparison of the totalled prices between suppliers. This is achieved by identifying the matches associated with the cart items. Each of these matches contains multiple Products, one from each supplier. These products a grouped by supplier and they then have the Prices totalled to work out the overall price differences between the two. 20 Therefore, if one of the suppliers has not contributed a product to the match, that match, and therefore cart item, cannot be included in the price comparison.

If the remaining product in the incomplete match was included in that suppliers total then the numbers would be favoured towards the supplier that did not 25 contribute a product to the match and ultimately the cart price comparison would be incorrect.

There are two methods of product matching; automated and manual. 30 Automated matching could utilize a collection of base products sourced from 3rd party product libraries and would be similar to the products stored in the primary database. One key difference however is that they have an (International Article Number (EAN). An EAN-13 barcode is a 13 digit (12 data and 1 check) WO 2016/000044 PCT/AU2015/050375 45 2015101887 03 Μ 2015 barcoding standard which is a superset of the original 12-digit Universal Product Code (UPC) system. The EAN-13 barcode is defined by the standards organization GS1. The base products can be imported as a csv file. 5 During the matching process, each of the base products are iterated over and a matching algorithm is performed on each to find an appropriate matching product record from each of the suppliers.

Initially, the Brand, Quantity and Weight values of the base product can be used 10 to isolate a small subset of product records which have these similar characteristics. In order to isolate product records with similar characteristics to the base product record, the logic first queries the Product table and returns any products which have identical Weight, Weight Definition, Quantity and Quantity Definition values. This product subset is then filtered further by comparing the 15 Brand name associated with each product to that of the base product. The brand name of the base product is initially embedded at the start of the base product description. To extract the brand name from the base product description, the description is broken up by each word, the logic iterates over incrementally more words of the description from start to finish, until it finds the optimal match count 20 in comparison to the product subset established earlier. To identify the optimum match count, every iteration cross references the brand names in the subset and returns a count of how many of these products have the same brand name as the current description fragments, be it just the first word, the first and second, and so on. The optimum value is identified by noting a decrease from the prior iteration 25 in the number of matches following a peak in the count. Then, the name of the base product is broken down into an array of words, for example ‘Soap Lavender’ will become [Soap, Lavender], The Name properties of all the product records in the subset will then also be broken down. Each product record name will then be compared to that of the base product. The record from each supplier which has 30 the most words in common with base product name will be deemed a match.

To summarize the prerequisites for a match to be identified, the following conditions should be met: WO 2016/000044 2015101887 03 Μ 2015 PCT/AU2015/050375 46 1. The base product must be included in the file import in step one. 2. The supplier product records (grocery items) must be collected in the scrapping process. 3. Each of the base products and supplier product records must have the 5 Name, Brand, Quantity and Weight values present.

The Name of both the base product and the product record must contain a high enough number of common words. In one embodiment a configurable threshold of 70% is used to define the cutoff where two products have an insufficient amount of matching words to be deemed a match. In the event that 70% or more 10 words match in the product description, the product is deemed a match. This number was identified as a suitable number by running the matching logic on actual Product datasets and investigating the results. A setting of 70% returned the optimum accuracy to quantity ratio.

Examples: 15 Base product name: Advantage Chocolate Mint

Supermarket 1 name: Advantage Bar Chocolate & Mint Supermarket 2 name: Advantage Chocolate Mint Bar

Base product name: Lemon & Parsley Steam Fish 20 Supermarket 1 name: Steam Fish Lemon And Parsley

Supermarket 2 name: Steamfresh Lemon Parsley Frozen Fish Fillets

An alternative to automated matching is a manual matching process. Starting from an export of each of the supplier’s product collections direct from the primary 25 database, matching can be performed using a Fuzzy Logic tool to identify potential matches between the various suppliers collection and provide the administrator with a match accuracy score. For example the fuzzy lookup tool in Microsoft excel can identify and match textually similar string data in data tables, and in this case helps to identify and match products between the stores. These 30 matches can then be either accepted or rejected by an operator. PCT/AU2015/050375 WO 2016/000044 47 2015101887 03 Μ 2015

Upon completion of the manual matching, the results are imported back into the primary database with the product match identifiers generating the match connections between products. 5 One advantage of manual matching is that in order for matches and their associated products to be more easily compared and calculated against, a set of metadata properties should be assigned to each match. These metadata properties can include; Categories, Related Groups, Unit Cost Groups and Tags. 10 Categories can be used to determine which category the match appears in from within the Browse/Search view. Multiple categories can be assigned to a match and the search function queries these categories also.

Related Groups and Unit Cost Groups will likely be used solely for comparison 15 and calculation purposes.

Tags can be used to identify broad ranging categories such as ‘Australian Made’ and ‘Lactose Free’ if desired. 20

Figure 26 provides an overview of the system automated data aggregation for the preferred embodiment. The agents are queued 500 and set the task to scrape the data from various suppliers. The system will check the status of the agents 501. If the system receives a status response of ‘Queued’ or ‘Running’ by all 25 agents the system will wait one hour (or other predetermined time) before checking the agent’s statuses again. If one agent returns a status response of ‘Completed’ 502, then the system will begin processing the data collected by that agent 503. Upon completion of data processing of that agent the system will repeat step 501, 502 and 503 until the system identifies that all agents return a 30 status of ‘Completed’ 504.

The processing 503 can include converting all supplier specific scrapper items with inconsistent field values or properties into uniformly structured Product WO 2016/000044 PCT/AU2015/050375 48 2015101887 03 Μ 2015 records. Each collected item is merged into the Product table of the database 26 using the supplier ID and item code as a unique identifier. Existing items are updated and new items are inserted into the Product table. In some cases the processing may also include removing or expiring existing products stored in the 5 database 26 if the item code no longer appears in the scrapper results. The products will be stored 507 in the primary database 26.

Once the products have been scraped and processed they should where possible be matched 505. The matching phase can involve identifying product subsets 10 508. This can include grouping products collected from the scrapper agents by brand, weight and quantity. Each product subset can be associated to a library record 509. This may be achieved by finding a suitable match between a library record and one of the subsets identified in step 508. This may include comparing the brand, weight and quantity fields of the subset to that of the library record. 15 Once the match has been made between the product subset and the library record the system can consider the products within the subset and identify 510 the closest matching product to the library record.

This can involve finding the product within the subset with the closest matching 20 name. The name field of each of the product records and the name field of the library record are broken down into individual words. The product with the highest number of matching individual words when compared to the library records name will be identified as the closest match. The highest number word count is determined by comparing the number of matching words in relation to the highest 25 number achieved by other products in the subset. The product which is found to have the highest matching words to the library record will be considered a match to the library record. Once the matching process has completed the aggregation process may be concluded 506. 30 Best Savings Based On Specials

Users will have the ability to enter in a postcode and the system will calculate which supermarket in their desired area has the best savings overall via their currently active specials. This will be achieved via a backend calculation of an PCT/AU2015/050375 WO 2016/000044 49 2015101887 03 Μ 2015 average shopping basket of items. This is option is for users who are time limited in certain scenarios. This will be presented to the user in a similar manner to that shown in Figure 18. The average shopping basket may be determined by recording the items purchased over a time period, say a month, and dividing by 5 the number of shopping purchases, ignoring fractions. For example an “average shopping basket” may contain 2 loaves of bread, 2 litre of milk, a packet of cereal, 1 litre of orange juice, fruit and vegetables, a can of baked beans etc. While individual shopping carts may vary from one person to the next the “average shopping basket” will be indicative of the cost of shopping at each retailer. As 10 shopping trends can change over time there may be other ways of determining the “average shopping basket”, including making seasonal adjustments, or by this being manually predefined.

Frequent Product Storing 15 The system may store every product added by the customer to their shopping lists and the frequency they have been added. When a registered user creates and saves a cart (shopping list) using the process explained above, the cart and its content is stored against the Cart, Cartltem and CartltemSelection tables in the primary database. These records are ultimately used to construct a list of frequent 20 Products collected by a user.

When the authenticated user navigates to the Frequent Products tab in the client websites Account section a web request is made to the API. The server logic then queries the Cartltem, CartltemSelection and Matches tables to retrieve a dataset 25 of all the matches associated with their cart items and item selections. The query also applies a group clause to the match ID and obtains the count of each group. The resulting dataset returns a match with summary information as well as a count of how many instances of that match ID are contained within the users cart item and item selection records. 30

This dataset is then serialized into JSON format and returned to the client website. The website renders the results into the view of the user, in descending order of the instance count. 50 2015101887 03 Μ 2015 WO 2016/000044 PCT/AU2015/050375

The user may then be presented with the opportunity to add the item to their active cart or save it to another list. 5 This list can be returned to the user via the mobile and web application in an ordered list where users will be able to then add them to their shopping list. This gives the user the option to populate their shopping list in a quicker manner once they have used the system. 10 The database server may count each user’s items purchased over a period of time so as to suggest items for the next shopping list.

Additional Notes

Each user will ideally have the option to add any notes via the App with regards to 15 their Shopping. A field on the Cartltem table in the primary database called Note can be responsible for presenting note data added by a user for a particular item. A user is able to add and edit notes for any cart item via the mobile app and desktop client website. From within the desktop website, the user can click a note button located within each checkout item row. Clicking this button displays a text 20 box overlay on top of the item where the user can enter text relating to their item. On clicking outside the textbox overlay, a web request is sent to the API which in turn executes an insert or edit command against the record of the cart item in question. Note information can be retrieved along with the web request which returns either the checkout or split shop list results. 25

Notes should also be editable from within the app. When a user has opened up a shopping list and the list is returned from the database via the API. The user then has a similar icon to add or edit notes for an individual item. The insert or update API endpoint is the same as that used by the desktop site and therefore behaves 30 the same way.

In addition to the user being able to add and edit notes via the app, when a user has flagged the item as collected from within the app, the note can be displayed WO 2016/000044 PCT/AU2015/050375 51 2015101887 03 Μ 2015 in a popup view to ensure the user has read the note. This can then be displayed at any time the user chooses. The user can also add notes in the desktop device 12 and this can be transferred to the device 14, 16 and displayed using the App when the user chooses, such as when the user is in-store. 5

Interactive Shopping List

Each user can tick off items as they are purchased via the App and the system will grey these out, giving the user the ability to see what has already been collected into their shopping basket. The system can also give a running total of 10 costs in real time, as the user is shopping. A field on the Cartltem table in the primary database called IsCollected is responsible for presenting a flag which indicates whether or not the user has marked an item as collected during their shopping trip. Any item which is added to a cart and saved against a users profile is defaulted to false value for the IsCollected field. 15

The user is able to mark an item as collected by clicking a button labelled ‘collected’ which is located beside the cart item from within the mobile app shopping list view. Clicking this button sends a web request to the API which in turn changes the IsCollected flag to a value of true via an SQL update command. 20 On completion of this web request, the item is greyed out within their shopping list.

Per Quantity (e.g. Gram/ltem) Costs Option

Calculation 124 allows the user to choose to save even more money by using this 25 option. Where available, the system will break down and work out the true actual cost of an item in comparison to a related product. Please see the following 'front loader laundry powder' product example: 1. 1kg at a cost of $12.19 a. Cost per 1kg is 12.19. 30 2. 5kg at a cost of $30.00 a. Cost per 1 kg is 6.00 WO 2016/000044 PCT/AU2015/050375 52 2015101887 03 Μ 2015

Although item 2 seems more expensive, in actual fact it is cheaper if based on the per kilogram unit costing.

Related shop function 5 Preferably the system will allow the user to swap selected items to items that are related and lower in cost if desired. For example 1kg of a brand name sugar may be more expensive than 1 kg of a homebrand sugar. Accordingly, the system may enable the user to swap and select the lower cost item. This could be done by selecting the relevant lower cost product (shown by the “click to swap” feature 10 370 in figure 17), this will then swap the item over and place the lower cost item in the users shopping cart.

As per figure 17 the system can initially start with all the original items. Ideally these will be colour coded for the users convenience, for example the price of the 15 selected items could be shown in green. When the user chooses to swap an item, the item that they swapped over from becomes greyed out and the new item that they have chosen will then show the price in green. Alternatively rather than colour coding an alternate system could highlight the selected products, for example an enlarged image could be used. 20

It’s not just necessarily the “homebrands” that are cheaper. At times premium brands may be cheaper simply because they may be on special at that time or have a special promotion running on that item at that time. 25 The example of Figure 17 shows the running total at the top of the screen shown in the figure by “-$50” and “-$43”. It is expected that as the user swaps an item for a lower cost item, this change is then reflected by a change to the amount shown, thus showing the user a running total tally of what the extra savings are every time the user swaps an item. 30

Related savings suggestions may be identified by the system. The particular related groups used by the list in figure 17 are of the type: Related. Once a user has constructed their shopping cart a javascript object within the client website PCT/AU2015/050375 WO 2016/000044 53 2015101887 03 Μ 2015 may contain the structure of the cart. When the user selects the related shop view, a web request is sent to the API and attached to this request is a JSON representation of their shopping cart. 5 The API uses this representation of the shopping cart to determine which items to find lower cost alternatives for. The logic within the API looks at each cart item. Each of these cart items has an associated match ID. Using this match ID an SQL query is performed across the Matches, Products, MatchesToRelatedGroup and RelatedGroups tables. The query returns an in-memory collection of the 10 matches associated to the users cart items. With each of these matches is also a collection of alternate match records which were found to have the same RelatedGroup as the original match. A constraint that should be put on the query is that the related group must be of type: Related. Therefore all the related matches should be restricted to a type of: Related. 15

With this in-memory data set on hand, the API logic performs an in-memory (not against the database) query for each of the active suppliers in the database table: Suppliers. For each supplier ID, the in-memory query finds the product on the initial match with the same supplier ID, and then looks at the corresponding 20 products in the collection of alternate match records which has the same supplier ID. If there is a cheaper product on one of the alternate matches (with the same supplier ID) then this product is identified as the lower cost alternative. The criteria for identifying a lower cost option is to subtract the value in the Discount field of the Product record to the Price field. The result is the total discounted 25 price of the product.

The alternate product which has the lowest total discounted price, if any, is identified as the lower cost suggestion to be returned with the original product by the same supplier. The API then returns a collection of comparisons, one for each 30 supplier. Each of these comparisons will refer to a cart item/match and contain two products, both by the same supplier, but one being the original product from their cart item and the other being a lower cost alternative from a different match altogether. 54 2015101887 03 Μ 2015 WO 2016/000044 PCT/AU2015/050375

Once the dataset is returned to the client website, the javascript front-end renders the list in the view and calculates the total price difference between all original and lower cost products per supplier. This total is then displayed at the top of 5 each list.

Unit cost option

Preferably the system will enable the user to swap to items that are related and have a lower unit cost. For example 500g of Brand X Sugar may be more 10 expensive than 2kg of Brand X sugar. This is done by the user selecting the relevant lower unit cost product (shown by the “click to swap” feature 390 in figure 19), this will then swap the item over and place the lower unit cost item in the users shopping cart if desired. 15 As per figure 19 the system again starts with all the original items preferably showing the price in green. When the user chooses to swap an item, the item that they swapped over from becomes greyed out and the new item that they have chosen will then show the price in green. The unit cost of each product may also be shown in addition to the actual cost for the users reference. 20

Figure 19 shows the running total percentage at the top of the screen shown in the figure by “+12%” and +15%”. As the user swaps a selected item for a lower unit cost item, this can then be reflected by a change to the amount shown, thus showing the user a running total tally of what the extra percentage savings are 25 every time they swap an item

The system will preferably identify and display unit savings suggestions. The particular related groups used by the unit shop view in figure 19 are of the type: Unit. When the user selects the unit savings view a web request is sent to the API 30 and attached to this request is a JSON representation of their shopping cart.

The API uses this representation of the shopping cart to determine which items to find lower cost alternatives for. The logic within the API looks at each cart item. WO 2016/000044 PCT/AU2015/050375 55 2015101887 03 Μ 2015

Each of these cart items has an associated match ID. Using this match ID a SQL query is performed across the Matches, Products, MatchesToRelatedGroup and RelatedGroups tables. The query specifies that all results must have the same related group as the initial match, and that this related group must have a type of: 5 Unit. The query returns an in-memory collection of the matches associated to the users cart items. With each of these matches is also a collection of alternate match records which were found to have the same RelatedGroup as the original match. A constraint should be put on the query that the related group must be of type: Unit. Therefore all the related matches should be restricted to a type of: 10 Unit.

With this in-memory data set on hand, the API logic performs an in-memory (not against the database) query for each of the active suppliers in the database table: Suppliers. For each supplier ID, the in-memory query finds the product on the 15 initial match with the same supplier ID, and then looks at the corresponding products in the collection of alternate match records which has the same supplier ID. If there is a cheaper product on one of the alternate matches (with the same supplier ID) then this product is identified as the lower unit-cost alternative. The criteria used to identify a lower unit-cost alternative is to first check for a cheaper 20 CupPrice field amount. If there are no cheaper alternatives by CupPrice. The logic will check if the PerGroupQuantity field multiplied by the PerGroupPrice field equates to a lower unit price than the original products Price field multiplied by the same PerGroupQuantity field. 25 The product identified as providing the user with the greatest price savings by this criteria should be chosen as the lower unit-cost alternative suggestion.

The API preferably then returns a collection of comparisons, one for each supplier. Each of these comparisons will refer to a cart item/match and contain 30 two or more products, both by the same supplier, but one being the original product from the users cart item and the other being a lower unit-cost alternative from a different match altogether. PCT/AU2015/050375 WO 2016/000044 56 2015101887 03 M2015

Once the dataset is returned to the client website, the javascript front-end renders the list in the view and calculates the total price difference in percentage terms between all original and lower unit-cost products per supplier. This total percentage value can then be displayed at the top of each list. 5

Add Match

In some circumstances the majority of products in one store are not necessarily available in another retailer. For example Aldi brands or products are not available in rival supermarkets and vice versa. Even so, that’s not to say that a 10 loaf of wholemeal bread from Aldi is going to be a very different product from a loaf of wholemeal bread from another supermarket. Accordingly in the preferred embodiment the system also enables a general comparison between products rather than an exact comparison. 15 When there is no exact product comparison to conduct the price comparison across stores, the user can have the option to select a product which may have a “match item” button next to it and provides the option to add a similar item from another store. 20 Although a Match record is intending on forming a relationship between two product records in the primary database, a match can still exist with only one product attached to it. This will form an incomplete match however the client website can still include this match within the search/browse view list results as a supplier exclusive item. Supplier exclusive items could be viewed in the search 25 results.

Each of the supplier exclusive match records listed in a search/browse results list of the client website can be suggested by the user as a match of another match record. To suggest a match between supplier exclusive match records, the user 30 may select a ‘Find a match’ popup. Upon opening this popup, a web request is sent to the API, with the match ID attached, to find a list of suggested matches with similar characteristics to the match in question. The API logic queries the Matches and Products table in the primary database and loosely filters the results WO 2016/000044 PCT/AU2015/050375 57 2015101887 03 Μ 2015 by Category ID, Brand, Weight and Quantity. A filter is also applied to return only matches that have associated products of opposing suppliers only. The results from this query are then returned to the client website and displayed in a list view by the underlying javascript framework. 5

The user may also be given the opportunity to search the matches catalogue by Name and Brand. Upon entering text input in the search field and clicking the Search button, a web request is sent to the server, with the search term attached, and the Matches and Products table is again queried but with the search term on 10 the Name and Brand as the filter. The results are then returned and displayed in the suggestions list in the same way as the initial default suggestions.

If the user finds a match in the suggested results that they believe to be identical to the match in question, they may select to ‘Add the match’. Doing so sends a 15 web request to the API with both the original and suggested match IDs attached. The API logic then triggers an insert command on the UserMatchSuggestion table in the primary database. A success result should be returned to the client website and the ‘Find a match’ popup closed. 20 Once a user has suggested a connection between a pair of supplier exclusive Match records in the primary database, all calculations and suggestions, may perform an additional step prior to determining results. Before determining savings calculations and suggestions against the active cart sent to the API with the web request, a query can be triggered against the UserMatchSuggestions 25 table for any suggestions made by the user for any items in their cart. If a suggestion is made, the logic will insert the product contained within the suggested match into the original match. The savings calculations and suggestions logic may then execute as normal and the users suggestion will be taken into account. 30

User suggested matches can also be brought to the attention of the administrators via the Match administration page. When the API queries against the primary database for the Match record, the query also includes results from WO 2016/000044 PCT/AU2015/050375 58 2015101887 03 Μ 2015 the UserMatchSuggestion table in the result returned to the admin page. The administrator may then associate the product from the suggested match record to the match they are managing. 5 Client Portal

Preferably a portal will be provided for local businesses/suppliers/providers to log in, add products and update their product costings. Local suppliers which do not have a large enough product catalogue to warrant an online store could be given the opportunity to contribute their product catalogue online via a self-managed 10 portal. Each local supplier will be added as a separate record in the Suppliers table of the primary database. These local suppliers will be distinguished from the large scale suppliers by a SelfManaged flag field, which will be set to true. Self-managed suppliers would be provided with an individual login which will provide them with access to a separate area of the administration portal. Here they can 15 add/edit and remove their own products stored in the Products table. These products will then be handled by the system in the same way as any product from one of the main supplier. All queries and calculations will behave the same.

For each additional supplier, a new shopping cart breakdown similar to 362 and 20 364 of figure 15 can be rendered in the calculation results. This will allow them to ensure they are included in the comparison along with the local major supermarket chains. An account can be created for these local businesses/suppliers/providers and they’ll be able to log in via the web desktop browser and update their pricing as needed. 25

Monitoring Service A service may be provided that allows a user to select one or more products and when these products are on sale, the user will be notified via their device 12, 14, or 16. A user interested in being alerted when a product in a particular match is 30 being offered at a discounted price has the option of subscribing to a notification mechanism in order to receive an email and mobile device notification when the system identifies that one of the products has changed to a discounted price. PCT/AU2015/050375 WO 2016/000044 59 2015101887 03 Μ 2015

For a user to subscribe to a product discount price notification, they must find the match from within the search/browse view of the client website. From here each of the matches are displayed in the list, and the user may click on the match to see a detailed view of the match. In the match detail view, the user can click on 5 the ‘Notify when on Special’ button. Upon clicking this button, a web request is sent to the API which in turn triggers an insert command into the DiscountedMatchWatch table. The user is also able to click the button when an existing watch on the match is also present. Doing so will trigger a delete command through the API which will remove the DiscountedMatchWatch record. 10 A scheduled task is preferably configured to run not long after the main Process aggregation task has completed. When the task is triggered, a batch file is run which in turn starts the User Notification service. 15 Once the service has started it immediately queries the DiscountedMatchWatch, Profile, Matches and Products tables in the primary database. If a product within a match has a Discount amount set, then the DiscountedMatchWatch along with the Profile and Match record will be returned to an in memory collection. 20 Each watch record should be iterated over and an email and mobile push notification will be sent to the user.

An explanation of the particular product which is at a discounted price will be constructed by the service and embedded in a html string. The html string is then 25 injected into the body of a html email which is then delivered via an API web request to the 3rd party email relay service, then onto the users email provider.

For mobile device targets, a simple text string containing the product name, and price and can be constructed and sent as a web request to a messaging service 30 end point, which will them forward the message to the users device. The notification will be received by the device using a cordova notification plugin which will handle and display the notification forwarded by GCM: https://qithub.com/phoneqap-build/PushPluain. The online shopping platform of WO 2016/000044 2015101887 03 Μ 2015 PCT/AU2015/050375 60 the embodiment provides customers with convenience and best price online for their area.

Modifications may be made to the present invention within the context of that 5 described and shown in the drawings. Such modifications are intended to form part of the invention described in this specification.

Claims (27)

1. Claims 1 A method of purchase of products by customers, said method comprising: in respect of a plurality of items available from each of a plurality of retailers, obtaining the price of each item for purchase from each retailer; receiving an indicator of a region from a customer (region indicator); receiving a list of items for purchase from the customer; determining the cost of each of the items in the received list for each of the retailers based on the received region indicator; and determining a shopping list for each retailer based on the determined costs.
2. 2 A method as claimed in claim 1 further comprising calculating an average shopping basket price of the cost of making the purchase of the items in an average shopping basket at each retailer, where the average shopping basket is a typical shopping basket, so as to determine which retailer is “on average” less expensive.
3. 3 A method as claimed in claim 1 or 2 further comprising calculating the cost of making the purchase of the items at each retailer.
4. 4 A method as claimed in any one of claims 1 to 3 further comprising determining the retailer with lowest price for each item and determining the shopping list for each retailer based on the lowest price.
5. 5 A method as claimed in any one of claims 1 to 4 further comprising including the cost of delivery in the cost of the purchase for each retailer in the calculated costs for each retailer.
6. 6 A method as claimed in any one of claims 1 to 5 further comprising determining whether an equivalent product is available that is cheaper than each of the original products in the shopping list at each retailer and calculating the cost of the shopping list with the equivalent product when there is an equivalent product and it is cheaper in place of the original product in the shopping list.
7. 7 A method as claimed in claim 6 wherein the equivalent product is substantially the same type but of a different brand.
8. 8 A method as claimed in any one of claims 1 to 7 further comprising determining the price per quantity of each item in the list of items from the customer and determining whether an equivalent product is available that is cheaper per unit of quantity than each of the original product in the shopping list at each retailer and calculating the cost of the shopping list with the equivalent product when there is an equivalent product and has a lower unit cost in place of the original product in the shopping list.
9. 9 A method as claimed in any one of claims 1 to 8 further comprising providing the shopping list to the user.
10. 10 A method as claimed in claim 9 wherein the shopping list is provided to the user in an electronic form via a portable device.
11. 11 A method as claimed in claim 10 wherein the portable device is provided with a check off function that allows the item when taken from the shelf to be checked off from the shopping list.
12. 12 A method as claimed in any one of claims 1 to 11 wherein the shopping list for each retailer is injected into an on line shopping cart of the respective retailer for completion of the purchase of the shopping list for the respective retailer.
13. 13 A method as claimed in any one of claims 1 to 12 wherein determining the shopping list for each retailer comprises performing a comparison of the cost of purchase of the items between the plurality of retailers that are located with a defined distance of or deliver to the user’s indicated region and selecting the list for the lower cost retailer.
14. 14 A method as claimed in any one of claims 1 to 12 further comprising determining the shopping list for each retailer comprises performing comparison of the cost of purchase of the items between the plurality of retailers that are located with a defined distance of or deliver to the user’s indicated region and splitting the list into sub lists according to one or more criteria such that the purchase can be made from at least two retailers.
15. 15 A method as claimed in claim 14 wherein the one or more criteria comprise for each retailer adding those items that are lowest in price for the respective retailer to the sub-list for the respective retailer, such that a list is created for each retailer that has at least one (or another selected number) of the cheapest items.
16. 16 A method as claimed in any one of claims 1 to 15 wherein determining the shopping list for each retailer comprises performing a substitution for substantially equivalent products that are cheaper.
17. 17 An online shopping platform for purchase of products by customers, said platform comprising a computer system having a database and functionally connected to a computer network accessible to the customers, wherein the computer is configured to: in respect of a plurality of items available from each of a plurality of retailers, obtain the price of each item for purchase from each retailer and store the price in the database; receive an indicator of a region from a customer (region indicator); receive a list of items for purchase from the customer; determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the prices stored in the database; and determine a shopping list for each retailer based on the determined costs.
18. 18 An online shopping platform for purchase of products by customers, said platform comprising: a storage; a price collecting module for obtaining the price of each of a plurality of items available from each of a plurality of retailers, and for storing said prices in the storage; a customer region receiver for receiving an indicator of a region from a customer (region indicator); a list receiver for receiving a list of items for purchase from the customer; a processor configured to determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the prices stored in the storage; and determine a shopping list for each retailer based on the determined costs.
19. 19 An online shopping server for enabling purchase of products by customers, said server comprising: a storage for storing substantially current prices of each of a plurality of items available from each of a plurality of retailers; a customer region receiver for receiving an indicator of a region from a customer (region indicator); a list receiver for receiving a list of items for purchase from the customer; a processor configured to determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the prices stored in the storage; and determine a shopping list for each retailer based on the determined costs.
20. 20 An online shopping server for enabling purchase of products by customers, said server comprising: means for storing substantially current prices of each of a plurality of items available from each of a plurality of retailers; means for receiving an indicator of a region from a customer (region indicator); means for receiving a list of items for purchase from the customer; means for determining the cost of each of the items in the received list for each of the retailers based on the received region indicator and the stored prices; and means for determining a shopping list for each retailer based on the determined costs.
21. 21 A computer program embodied in a computer readable non-transient storage medium comprising instructions for controlling a computer to: in respect of a plurality of items available from each of a plurality of retailers, obtain the price of each item for purchase from each retailer; receive an indicator of a region from a customer (region indicator); receive a list of items for purchase from the customer; determine the cost of each of the items in the received list for each of the retailers based on the received region indicator and the obtained prices; and determine a shopping list for each retailer based on the determined costs.
22. 22 A user shopping device comprising: an input for receiving an indicator of a region from a customer (region indicator); an input for receiving a list of items for purchase from the customer; a communications device for transmitting the received region indicator and received list of item for purchase to a shopping platform; a receiver for receiving from the shopping platform a shopping list for one or more retailers based on the received region indicator, the price of each item for purchase from each retailer and the received list.
23. 23 A user shopping device as claimed in claim 22 wherein there are at least two lists received, where each list is for purchase of goods from one retailer and is determined from the cost of each of the items for each of the retailers.
24. 24 A method of purchase of products by customers, said method comprising: in respect of a plurality of items available from each of a plurality of retailers, obtaining the price of each item for purchase from each retailer; receiving a list of items for purchase from the customer; determining the cost of each of the items in the received list for each of the retailers; and determining a shopping list for each retailer based on the determined costs, wherein the list for each retailer comprises the lowest price for each item from amongst the retailers and if a retailer has less than a threshold number of items on its respective list then there is no list for that retailer and those items that would otherwise be on that retailer’s list are put on the list of the next lowest retailer.
25. 25 A shopping aid system comprising: receiving a geographic identifier from a user at a processor of a computer, the processor identifying at least one supplier based on the geographic identifier; the processor receiving a product list from the user, wherein the product list includes at least one product; for each said at least one supplier the processor produces a supplier product list, retrieves product values for each product on each supplier product list, and combines the product values to determine a supplier list value; producing the supplier list value for each said at least one supplier for the user.
26. 26 A system as claimed in claim 25, wherein the processor obtains the product values from each said at least one supplier.
27. 27 A system as claimed in claim 25 or 26, further comprising the processor comparing the product values of respective products on each supplier product list to determine the lowest cost item for each respective product; removing products from each supplier product list that are not the lowest cost item for each respective product; amending each supplier list value to only include product values of products retained in the respective supplier product list; producing respective supplier product lists for the user which omit the removed goods.