WO2014005190A2

WO2014005190A2 - Methods, systems or computer programs for logistic planning based on proximity constraints and/or price optimization

Info

Publication number: WO2014005190A2
Application number: PCT/AU2013/000736
Authority: WO
Inventors: Michael Timothy SCHOLES
Original assignee: Scholes Michael Timothy
Priority date: 2012-07-05
Filing date: 2013-07-05
Publication date: 2014-01-09
Also published as: AU2013286819A1; WO2014005190A3; AU2013286819B2

Abstract

The present invention provides an electronic device for determining a route comprising: a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, through a data network; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; wherein the central server calculate the routing results.

Description

METHODS, SYSTEMS OR COMPUTER PROGRAMS FOR LOGISTIC PLANNING BASED ON PROXIMITY CONSTRAINTS AND/OR PRICE

OPTIMIZATION

Technical Field

The present invention relates to methods, systems or computer programs for logistic planning based on proximity constraints and/or price optimization. In particular, the present invention is related to methods, systems or computer programs for searching, planning and/or recommending vendors along a route for a completing shopping list based on various constraints such as locations and/or areas defined by users, and prices given by the vendors, etc.

Background

Logistics planning with a given list of locations to find the optimized route is a complex problem . The focus of the studies of this kind of problem was usually based on the number of locations to visit and the distance between each pair of adjacent locations. This problem is sometime known as the travelling salesmen problem .

However, in real life situations, a customer may have a predefined route or area to visit such as the route which the customer takes to go to work or visit a friend. Under this condition, the customer would like to find the best place to make all the purchases in a predefined shopping list. While the solution for the travelling salesman problem may help to optimize the distance and time of the route, it fails to take other constraints such as the shopping list, best prices, preferable stops, proximity of an area into consideration.

US Patent Application No 20070288497 discloses an apparatus and method for providing route-based advertising and vendor reported business information to a user over a network. In particular, the invention relates to a method of providing information about vendors to a user, which comprises the steps: receiving from the user a query identifying a contemplated route; providing a computer database of self-reported business information from the vendors, each vendor having an identified geographic location; and providing to the user, via a server accessible over a network, information from the database concerning the business information of a set of vendors extracted from the database on the basis of geographic proximity to the route identified by the user

However, the prior art does not provide a user friendly interface for a user to define the route or shopping area. It does not address the issues of different travelling patterns. Also it does not allow users to plan and calculate the logistic strategy for purchasing goods other than fuel .

Moreover, it does not link items to unique identifiers and thus does not allow for unambiguous product identification and price comparisons.

It is an object of the present invention to provide methods, systems or computer programs for searching, planning and/or recommending vendors along a route for a shopping list based on various constraints such as locations and/or areas defined by users, and prices given by the vendors, etc. that ameliorates any of the disadvantages of the prior art or provides an alternative thereto.

Summary of the Invention The present invention provides an electronic device for determining a route comprising : a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, through a data network; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; wherein the central server calculate the routing results with the following steps:

(a) retrieving the vendors and the product information thereof from the database, wherein the each vendor is located in the one or more eligible areas or eligible routes;

(b) looping through each item on the list and performing the following steps;

(i) in the event that no match is found for the item in the list of products, updating the item availability register;

(ii) in the event that at least one match is found for an item on the list, updating the item availability register and updating the eligible vendor list; and

(iii) comparing and sorting the vendors in an order based on products and vendors information;

(c) calculating the percentage of items available; and

(d) calculating the route for visiting all the vendors .

Preferably, the database contains information related to vendors who has populated products and vendors information in the database through a vendor application executed a computer device, wherein the products and vendors information comprises one or more of the following data : product name, product description, price, expiry date of the price, status of the product, number of unit available, discount status, expiry date of the discount, amount of discount, condition of the discount, vendor's name, vendor's address.

Preferably, the central server is adapted to assign a unique identify for each of the product stored in the database.

Preferably, the user interface is adapted to receive one or more constraint situations for calculating the route, where in the constraint situations comprising : minimum price, maximum number of shop allowed, locality for purchasing an item, weight of an item, traveling time, or petrol costs. Preferably, the comparing products and vendors information step further comprises the steps of in the event that the constraint is minimum price or not specified, find the vendors who provide the minimum price for an item.

Preferably, the comparing products and vendors information step further comprises the steps of in the event that the constraint is travel time, find the vendors who has the shortest distant from the centre of a eligible area or eligible route.

Preferably, the looping step comprises the following steps: in the event that the constraint is maximum number of shops allowed,

(i) finding all unique combinations of vendors containing no more than the number of maximum shops allowed;

(ii) for each element in each of the unique combination sets, further perform steps defined in claim 1.

Preferably, the central processing unit is further adapted control the user interface to provide the function allowing a user to record or save a special, deal, discount, or product of interest in the user profile, wherein the central processing unit will communicate with the central server and retrieve the status of the deal, and notify the user about any change in the status. Preferably, the geographic information system is adapted to obtain the location information from a user through the user interface and connect to a third party application such as Google maps to obtain the location information.

Preferably, the geographic information system comprises a geographic positioning system which is adapted to generate coordinates of the current location of the electronic device.

Preferably, the geographic information system is adapted to obtain a radius of the eligible area from the user interface.

Preferably, the user interface is adapted to receive product information comprising one or more of a picture, bar code, ISDN, or description of a product; the central processing unit will send the product information to the central server for retrieving the unique identifier, and record on the list.

Preferably, the route displayed on the user interface further comprises one or more of the following information : which items should be purchased at each vendor; the best route to take in order to visit all vendors; or directions.

Preferably, the user interface is adapted to receive payment and online ordering information; the central processing unit will submit the payment and online ordering information to the central server.

Preferably, the device is in the form of a smart phone executing a software application.

Preferably, the device is a computer system executing a web base software.

In another embodiment of the present invention there is provided an electronic system for determining a route comprising : a customer application device connecting to a vendor application device and a central server through data network, wherein the customer application device comprises: a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, a data network; a vendor application device adapted to receiving information of a vendor and information of products provided by the vendor; a central server comprising a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; the central server calculates the routing results with the following steps:

(b) looping through each item on the list and performing the following steps;

(i) in the event that no match is found for the item in the list of products, updating the item availability register; (ii) in the event that at least one match is found for an item on the list, updating the item availability register and updating the eligible vendor list; and

(c) calculating the percentage of items available; and

(d) calculating the route for visiting all the vendors.

In one embodiment of the present invention, there is provided a method for determining a route, using an electronic device comprising a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow between the user interface, geographic information system, a data network; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; comprising the steps: (a) retrieving the vendors and the product information thereof from the database, wherein the each vendor is located in the one or more eligible areas or eligible routes;

(b) looping through each item on the list and performing the following steps; (i) in the event that no match is found for the item in the list of products, updating the item availability register;

(iii) comparing and sorting the vendors in an order based products and vendors information;

(c) calculating the percentage of items available;

(d) calculating the route for visiting all the vendors

(e) displaying the route on the user interface.

In another embodiment, there is provided a computer readable media for storing the aforementioned method.

Brief Description of the Drawings

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

Figure 1 is a schematic diagram of the system according to one embodiment of the present invention;

Figure 2 is a control flow diagram of a vendor application according to the system of Figure 1 ; Figure 3 is a schematic diagram of an interface for a vendor to create a vendor account from the vendor applications in the system of Figure 1;

Figure 4 is a schematic diagram of an interface for a vendor to login to the vendor account from the vendor applications in the system of Figure 1;

Figure 5 is a schematic diagram of an interface for the vendor to manage their inventory information from the vendor application in the system of Figure i ; Figure 6 is a schematic diagram of the product information schema for use in the system of Figure 1 ;

Figure 7 is a schematic diagram of a search interface for searching products using a third party application; Figure 8 is a schematic diagram of the control flow of a customer application in the system of Figure 1;

Figure 9 is a schematic diagram of an interface for a customer or user to create a customer account from the customer applications in the system of Figure 1; Figure 10 is a schematic diagram of an interface for a customer or user to login to the customer account from the customer applications in the system of Figure 1;

Figure 11 is a schematic diagram showing the relationship of the third party application and the system of Figure 1; Figure 12 is a schematic diagram of a shopping area defined from a customer application in the system of Figure 1;

Figure 13 is a schematic diagram of an interface for a customer or user to view the list of shopping areas in the system of Figure 1;

Figure 14 is a schematic diagram of an interface for a customer or user to define a new shopping area in the system of Figure 1;

Figure 15 is a schematic diagram of an interface for a customer or user to view the map of shopping areas in the system of Figure 1 ;

Figure 16 is a schematic diagram of an interface for a customer or user to define the centre and the radius of a shopping area in the system of Figure 1; Figure 17 is another schematic diagram of an interface for a customer or user to define the centre and the radius of a shopping area in the system of Figure 1; Figure 18 is a schematic diagram of an interface for a customer or user to remove a shopping area in the system of Figure 1;

Figure 19 is another schematic diagram of an interface for a customer or user to view the map of shopping areas in the system of Figure 1; Figure 20 is a schematic diagram of an interface for a user to define a new route in the system of Figure 1;

Figure 21 was a schematic representation of a shopping area formed by linking three shopping area components - two point and radius components and one route. Figure 22 is a schematic diagram of a finger gesture to define the size of the radius of a shopping area of Figure 12;

Figure 23 is a schematic diagram of a map result displayed by the customer application in the system of Figure 1;

Figure 24 is a schematic diagram representing the data structure relationship between the shopping list and shopping areas in the system of Figure 1;

Figure 25 is a schematic diagram of an interface for a customer or user to manage a shopping list in the system of Figure 1 ;

Figure 26 is a schematic diagram of an interface for a customer or user to add a shopping list in the system of Figure 1; Figure 27 is a flow chart of the method for generating a shopping plan with optimized the prices for a predefined shopping list and shopping areas and/or route in the system of Figure 1;

Figure 28 is a flow chart of the method for generating a shopping plan with optimized the prices for a predefined shopping list and shopping areas and/or route with limited number of shops in the system of Figure 1;

Figure 29 is a schematic diagram of a print out of the search results displayed by the customer application showing a preferred shopping area in the system of Figure 1; Figure 30 is a schematic diagram of a print out of the search results displayed by the customer application in the system of Figure 1; and

Figure 31 is a schematic diagram showing the online ordering function of the system of Figure 1. Detailed Description of the Preferred Embodiment

Reference is now made to Figure 1, there is provided a system 1 for searching, planning and/or recommending vendors along a route which offers items on a shopping list based on various constraints such as locations and/or areas defined by customers or users, and prices given by the vendors. The system comprises a customer application 10 interacting with a central server 14 through a network 12 on one side and a vendor application 16 interacting with the central server 14 through the network on the other side.

In one embodiment, the customer application 10 is software running on a PC, smart phone or terminal, the vendor application 16 is another software system/component running on a PC, smart phone or terminal. The central server 14 comprises a server system running database management software. In another embodiment, the customer application 10 and the vendor application 16 are software clients, such as in the form of a web browser, which can download the suitable interface and implementation when the customer or user logs into the web server. In one embodiment, the customer application 10 and the vendor application 16 can be a mobile app, a web application or a standalone application running on a personal computer (PC).

The vendor application 16 provides an interface for vendors to self-report business information which is then stored in the database through the central server 14. The business information includes the vendor's geographic location information, information on the products, such as any discount, special or deal available from the vendors, the price for each product, the expiry date of the price, whether the product is on special or not, etc.

The vendor application 16 is connected to the central server 14 through a network 12 such as the Internet. The central server 14 stores business information from various vendors in a centralized aggregated depository. However, one or more physical databases may be located in a number of different locations.

The customer application 10 provides an interface for the customer or user to set up an account and gain access to the customer account information, specify a shopping list, define location information, query about status of the product such as whether it is on special or not, and query the locations where purchase can be made. The customer application 10 connects to the central server 14 through the network 12, forwards the queries to the central server 14, and presents the results to the customer or user when the results are returned from the central server 14. In one embodiment, the customer application 10 provides the interface for the customer or user to record or save a special, deal, discount, or product of interest in the user profile. The customer application 10 can notify the user when the status of the special, deal, discount, or product of interest is about to change, for example, the expiry date of the deal is approaching.

Figure 2 shows the control flow of the vendor application 16. The vendor application 16 provides the interface for the vendor to create or login to a vendor account. Figure 3 shows an example for the interface for the vendor to create a vendor account and Figure 4 shows an example of the interface for the vendor to login to the vendor account.

Each vendor may have one vendor account in the system. Referring to Figure 3 where an example of the interface to create a vendor account is shown, the vendor has to at least specify the business name and a store location. It is envisaged that some vendors may have multiple stores which are located in different locations, and each store may provide a different set of items for sale to customers.

The vendor application 16 may obtain the location information of the store using a number of methods. The vendor application 16 may provide a set of application programming interface (API) to a third party application such as Google maps to obtain the location information, optionally with the function of automatically completing an address. In another embodiment, the vendor application 16 may request the GPS location data from a mobile device such as a smart phone which has a GPS embedded therein. The vendor application 16 may also provide the interface for the vendor to directly key in the address or geographic coordinates of the store. In yet another embodiment, the vendor application 16 may provide a touch screen interface where a map is displayed on the touch screen. The vendor may input the location of the store by touching the particular location of the map displayed on the touch screen. The vendor application 16 then calculates the exact location or coordinates of the store identified by the vendor.

Referring to Figure 2, once a vendor logins to the vendor account, the vendor may edit the vendor information stored in the database through the vendor application 16. The vendor may choose a store and start managing the inventory information in that store. The vendor may choose to add a new store or edit the store information such as the address of the store. A vendor may have more than one store. Also, there may be multiple user logins for a single vendor so that more than one person can manage the vendor or store information.

After the vendor chooses a store from the vendor application 16, the vendor may manage their inventory information in that store from the vendor application through an example of the interface as shown in Figure 5. The vendor may choose a store at a specific location and input the name and descriptions of a product, one or more pictures representing the product, the barcode for the product, a price or a price range for the product, the expiry date of the price, the number of that product available for sale, etc. Through the vendor application 16, a vendor may, from time to time, update the business information stored in the database that is located in the central server 14. For example, the vendor may change the price of an item that is sold in one of the stores. In one example, the product may be on special in a particular store for a period of time. In another example, the special offer for a particular product now comes to an end. The vendor may simply update the price of that item from the vendor application 16. In one embodiment, the vendor application 16 is installed on a customized vendor system that comprises a scanning device which captures the barcode, UPC or ISDN of the product. The vendor application 16 can be in the form of a web interface on a PC or mobile device. The vendor application 16 can also be in the form of a standalone software application running on a PC or mobile device. This PC or mobile device may comprise a scanner or a camera for capturing the photograph, barcode, UPC or ISDN of the product. The customized vendor system then processes the captured data and fetches the product name, descriptions, photographs, etc from the database through the central server 14. Should the product name and descriptions not be available in the database, then the central server 14 will try to fetch the information from the Internet. The vendor may then edit the name and descriptions from the vendor application 16 as shown in Figure 5.

In yet another embodiment, a middleware is provided to integrate the vendor application 16 with the inventory management system of the vendor such that any change of the inventory information in the inventory management system, it will be automatically forwarded to the vendor application 16. In another embodiment, the vendor application 16 provides an interface for bulk uploading inventory information to the system 1.

After the vendor application 16 collects the data input by the vendor, the vendor application will forward the data to the database through the central server 14. The database holds the information of all known products that is self- reported by the vendors. In one embodiment, database will initially be primed with as many products (and as much product information) as possible. In that case vendors will almost always find the product information in the system already. Each product is associated with one or more identifiers. At least one of the identifiers, or a combination of identifiers associated with each product can be used to uniquely identify the product in the database. If no such identifier is available, the central server 14 will assign a unique identifier to that product, service or item. Typical externally assigned identifiers:

• Barcode

• UPC

• ISBN In one example as shown in Figure 6, the vendor, who is a book seller, self- reports the book "The Art of Computer Programming" being sold for price $14.99. The vendor may directly enter the ISBN number "978-0201853926" from the vendor application 16. The central server 14 may use this number as an unique identifier for this book.

However, the system may have additional information gathered from other source which is linked to the unique identifier, such as the ISBN "978- 0201853926" e.g. The book is a non-fiction, first published in 2005, author is "Donald E Knuth", average retail price is $19.99 etc. This information can be used to facilitate product searching for customers or users when creating shopping lists or when performing product searches.

In addition to external identifiers, each item can also be associated with an internal identifier. This internal identifier is a parameter visible only to the database but transparent to the customers or vendors etc. Internal identifier can be assigned if external identifier is insufficient to uniquely identify the product or if there is no external identifier e.g. large cup of coffee.

An Internal identifier (ID) uniquely identifies a certain item. The ID may also act as a classifier which classifies the type of goods or service for price comparison and assists in fuzzy matching. The ID is important in order to allow price comparisons between items that have no external ID. In one embodiment, for vendors who provide a large, medium and small coffee for sale, the database thus assigns an ID for each of these for classification : · Small coffee - ID1

• Medium coffee - ID2

• Large coffee - ID3

For example, vendor A sells a small coffee for $1 and Vendor B sells a small coffee for $1.50. Although, the small coffee sold by Vendor A and Vendor B may not be identical, they are in general similar, and neither has an external identifier such as a barcode or UPC. Therefore, both products are assigned the same ID for small coffee in the database.

In another example, Vendor A provides dry cleaning service and Vendor B also provides dry cleaning service. Dry cleaning service is rarely associated with any external identifier such as barcode, UPC or ISBN . The central server 14 will perform a search for the appropriated ID to classify this service within the database. Otherwise, the central server 14 will assign a new ID when this service is first created in the database. For example, dry cleaning a pair of jeans will get a Unique Identifier. A 30 minutes massage and 45 minutes massage each will be assigned a Unique Identifier. If a vendor wishes to sell a product or service with no internal or external identifier, then the vendor may apply to have the product or service classified and added to the database. A new ID will then be assigned. For example, when a new product is available from a vendor, such as medium chai latte, the vendor can create a new product in the database by submitting a request through the vendor application 16. The central server 14 will perform a search in the database to try to find a match for the product. If the ID of the product is found in the database, the product will have that ID assigned to it. Otherwise, a new ID will be created in the database and assigned to this product. The vendor will then be notified that the new product is now created in the database and the vendor can now insert other information such as descriptions, price, expiry date of the price, number of units available, and photographs for the product, etc. Hence, each product available for sale from a vendor has at least the following data in the database :

1. Unique identifier (ID);

2. Price;

3. Validity period; and

4. Vendor (and therefore a GPS location or coordinates).

The central server 14 can then compare the prices of a product with the same ID from different vendors. To assist the searching and classification of products in the database, the central server 14 may further classify the product into a category and a subcategory. Lower-level categorization can go to any level e.g. consumable - grocery item - fruit - citrus - orange - naval oranges. For example, a vendor may run a restaurant and provide modern Australian cuisine. When this service is added to the database, a new ID will be assigned if it does not exist already in the database. The central server 14 may also classify the service in the category of "Dining" and in the sub-category of "Australian Cuisine". Following is a schematic table showing the relationship of the product information.

The vendor profile stored in the database may comprise a list of favourite products of the vendor. In one embodiment, after a few updates operation of a particular product, for example, the product is regularly offered on special or sold, the central server 14 will include this product in a favourite product list such that the vendor can pull the profile of that product from the database easily and perform editing, as such in Figure 5. Following is a schematic representation of the database based on vendor reporting for items/products. Link is made through UI .

The vendor application 16 also provides a reporting function which can generate sales and prices comparison report for a vendor as a reference to improve future sales strategy - this information would be sourced and processed on the central server 14. In one embodiment, a vendor may request a report on all the products that has a status "on special". Without revealing any private information of any customer or user, the vendor application 16 may request the central server 14 to generate statistical reports showing the co-relationship of different data, such as the route, products purchased, and the prices, etc. For example, the central server 14 may generate a report with respect to the relation between the route or location and the products purchased. These functions can be accessed when the vendor uses a web page or standard app on a mobile device to login to the system 1 and executes the reporting subroutines from there.

The information held in the database may be exported into different formats for use in different third party applications such as enhanced analysis or searching. The export information may include one or a combination of the following data :

• Locations of retailers;

• Self-reported prices linked to unique identifiers;

• User defined shopping areas;

· User defined shopping lists; and

• Associations between shopping lists and shopping areas for a user.

This would allow customers or users to search for products using a third party application as shown in Figure 7. The customers or users can still make use of shopping areas and shopping lists defined in with the customer application 10. The central server 14 may provide the application programming interface to interact with a third party application and keep feeding the third party application updates regularly. The third part application may carry certain functions for the customer application 10 or the vendor application 16.

Reference is now made to Figure 8 where the control flow of a customer application 10 is shown. The customer application 10 provides the interface for the customer or user to create or login to a customer account. Figure 9 shows an example of an interface for the customer or user to create a customer account and Figure 10 shows an example of an interface for the customer or user to login to the customer account. It is optional to have a customer account in order to perform some operations provided by the customer application 10. However, it is impossible to perform certain functions without logging into a pre-existing customer account, for example, storing a shopping list or route, etc. A user may be a customer or any person.

Each user may have one customer account in the system . Referring to Figure 9 where an example of the interface to create a customer account is shown. The user may specify a user name, and a password to create a user profile. An user identification number (hereafter referred as "User ID") is then assigned by the central server 14 when the user account is created. The user may then insert other data such as an address, favourite products, and categories of interest etc. into a user profile in the database. In one embodiment, the customer application 10 will be a web/mobile client (thin client) application displaying information that is actually stored/processed on the central server 14. Therefore, any third party systems would communicate with the central server 14 through API/web services. The link between an account on system 1 and a third party system may be created by associating the user identity with the same user account information such as username and password. For example, the user may log into a Google account, and choose to link information with system 1. The user may provide login details to Google which uses them to access relevant information for the user from the central server 14. In this case, every time the user logs into Google, it is possible for the user to access to all shopping areas and lists in the user profile stored in central server 14.

In one preferred embodiment, a user may link the user account to a Google account. The customer application 10 may comprise the API to share the user information stored in the Google account. The customer application 10 may also interact with other third party application, such as Google map or Google search to fetch information not readily available in the database as shown in Figure 11.

In one embodiment, the customer application 10 provides an interface for a user to define a geographical data of interested, such as a shopping area component, a shopping area or a shopping route. In one embodiment, the customer application 10 may be a web page or mobile application through which the user can login to the central server 14 of the system 1.

A shopping area component designates an area where a user has a preference area to shop. The user may directly enter an address (or GPS coordinates or other information which can be resolved to GPS co-ordinates e.g. Sydney Aquarium) as the centre of a shopping area and then provide a radius to specify the size (diameter) of the shopping area, as shown in Figure 12. The customer application 10 may have a default or pre-defined radius such that the user is not required to define the radius all the time, but just provides the centre point.

The customer application 10 provides a number of means for the user to define the centre of the shopping area component. In one embodiment, the central server 14 communicating with Google using Google Maps API, so that the user may use Google map to define the location information. In another embodiment, the customer application 10 may request the current GPS location data from a mobile device which has a GPS embedded therein. The customer application 10 also provides an interface for the user to directly key in the address or geographic coordinates. In yet another embodiment, the customer application 10 may provide a touch screen interface where a map is displayed on the touch screen. The user may input the location of the store by touching the particular location of the map displayed on the touch screen. The customer application 10 then calculates the exact location or coordinates of the location identified by the user.

The customer application 10 may store the radius in the user profile such that the next time when the user defines a shopping area component, the customer application 10 can retrieve the previous radius stored in the user profile.

The customer application 10 may obtain feedback to improve the radius of the shopping area component. In one embodiment, the customer application 10 provides a questionnaire to the user asking whether the radius of the shopping area component is too big or too small, and then made makes adjustment to the radius stored in the user profile. The customer application 10 may obtain geographic data from a GPS system which detects the travelling behavior of the user and makes the adjustments based on the GPS data. For example, the default radius may be 1 km, but the GPS detects that the user usually wander around a shopping area component of 1.5km, the customer application 10 may user this information to change the default radius to 1.5km.

A shopping area is a set of one or more shopping area components. A user may combine one or more shopping area components to form a shopping area (hereinafter referred as "SA"). A shopping area component is the most basic form of geographical information, it may comprise a point and a radius, a route, a postal area, a shopping centre, a city or a region, etc. Each shopping area component in the shopping area may consist of one or a combination of the following :

Shopping area component: centre point and radius, route, postal area, shopping centre, or city etc.

Shopping area (SA) : any combination of the above - also the ability to "remove" areas/specific shopping centres e.g. remove a point and radius from within a larger point in additional to the radius.

• Geographical locations (identified by GPS co-ordinates) and an associated radius/distance;

• Routes between two geographical locations (identified by GPS coordinates) and an associated radius/distance;

• Countries;

• Cities;

• Postal codes;

• Suburbs; and

• Shopping centres;

In one embodiment, an interface as shown in Figure 13 is provided by the customer application 10 to define a Shopping Area. The user may select the option "Define New Shopping Area" to add a new shopping area component in a list. When the interface "Define New Shopping Area" is selected, the customer application 10 will take the user to the "Define New Shopping Area" interface as shown in Figure 14. In this interface, the user may add, remove or edit a new shopping area component. Preferably, this interface provide the option for the user to view the details of shopping area and/or shopping area component, such as in a map or in combination with other geographical information as shown in Figure 15.

Referring to Figure 16 and Figure 17, there is provided an interface of the customer application 10 which displays the addition of a centre point and radius of a shopping area component. The centre point can be defined by specifying the street address or GPS coordinates. In the PC environment, this can be done by moving the cursor of the pointing device on the map display on the interface. On a mobile device with a touch screen, the user may touch the point on the map displayed on the touch screen.

Referring to Figure 18, there is shown an example of an interface of the customer application 10 to remove a shopping area component i.e. an area that will be removed from some other SA component. Figure 19 shows an example of the resulting interface of the customer application 10 after adding and removing of shopping areas and/or shopping area component. Figure 19 shows SA 5 consisting of two SA components - one defined a "removal".

In one embodiment, the list of SAs is related to train or bus stations along certain train or bus line. In this type of transportation travelling from station A to station B, the vehicle may only stop at certain stations but not anywhere in between unless there is an emergency. A commuter may board the train at station A and disembark at station B. The commuter may also disembark and embark at any station in between station A and station B. The user may define a SA by including station A, station B and/or any station in between. Understandably, a user may pass through some places along the train line, but it may not be practical to shop in those places. Therefore vendors from those places may be excluded from the search.

In another embodiment, the customer application 10 may provide an interface as shown in Figure 20 for a user may define a shopping route by specifying a start location A, an end location B, and the commuting route between location A and B route could be proposed. In one embodiment, the customer application 10 may provide a set of application programming interfaces (APIs) to a third party application such as Google map, so that the user may use this third party application to define the location and route information. The APIs will capture the information from the third party application in order to define the shopping route for the user.

The customer application 10 also may provide an interface for the user to directly key in the address or geographic coordinate of the route. The user may adjust the route with the map displayed by the customer application 10.

In yet another embodiment, as shown in Figure 21, the customer application 10 may provide a touch screen interface where a map is displayed on the touch screen. The user may input the start location or the end location by touching a particular place on the map displayed on the touch screen. The user may drag along the touch screen to define the commuting route. Default radius or specified radius is used at starting and ending point and along route. The user may use finger gesture to define the size of the radius for the shopping route. For example, as shown in Figure 22, when the two fingers move apart, the customer application 10 will interpret as increasing the radius of the shopping route. On the other hand, when two fingers move towards each other, the customer application 10 will interpret as decreasing the radius of the shopping route. The customer application 10 then calculates the exact location or coordinates of the route identified by the user.

In one embodiment, it is possible for the user to define a combination of shopping area components and shopping area. For example, a user may define a GPS location A as the centre of a first shopping area with a radius of 30 km and GPS location B as the centre of a second shopping area with a radius of 20 km. The user may also define the shopping route join the first shopping area and the second shopping area.

In another example, a user lives in location A, commutes to station B to catch a train to station C. Defining a single area to include the route taken from station B to station C would not be helpful as the commuter is on train and cannot jump off to shop anywhere along the route. The user may define a first shopping area centered at location A, a second shopping area centered at location B and a third shopping area centered at location C. The user may also include the route commuting between location A and location B. Once the location information is defined, the customer application 10 may retrieve all the products that are advertised on special by the vendors within the shopping areas, or routes or those specified in a Shopping List.

Further, the customer application 10 allows a user to perform a search for a particular product or service that is available within the shopping areas. The shopping areas may associate one or a combination of the followings: County; Region; City; Postal code; Suburb; or Shopping Centre. In one example, a user may want to search where to obtain a pack of AAA battery along the route to work or within a particular shopping centre. The user first defines the shopping areas or routes as described above and then performs a search for AAA battery selling by vendors within the shopping areas or routes.

In one embodiment, the user may remove or exclude a shopping area . This can be done by specifying the shopping area component or shopping area to be removed or excluded. The user may re-define the radius of the shopping areas or shopping area components. The user may exclude a particular postcode, suburb or country. The user may also exclude a particular vendor or shopping mall. In one embodiment, the user may compile an exclusion list which specifies the shopping area or route which the system 1 will not take into consideration when calculating the shopping plan.

In one embodiment, the customer application 10 may provide the function to allow a user to conduct a search based on any of the product information, such as description of the product in the database e.g. Nike Air Max shoes under $120.

As described before, this product has a unique identifier, such as a bar code, UPC or ISBN or Internal Identifier assigned to it. Sometimes the identifier can have additional connotations associated with it. For example, the product is classified under the category of clothing and the sub-category of shoes. Therefore, extended searches can be performed based on the associated characteristics, including : category search, brand search, etc. In a category search operation, the central server 14 will retrieve products in the same category or sub-category. In a brand search, the central server 14 will retrieve products of the same brand. The customer application 10 may have functions to allow the customer or user to combine a number of different criteria in the search, such as a particular sub-category of goods from a particular brand. The user may carry out a search in a predefined SA or in one defined at the time of search .e.g. radius of 10km from current location. Here we would have: search for "Nike Air Max" in SA 1 (which has already been defined as a postal area and a route.

In another embodiment, the customer application 10 may provide the device driver to interface with a scanning device. The scanning device can be used for capturing the barcode, UPC or ISBN of a product and passing it to the customer application 10 through the device driver. The user may then add the barcode, UPC or ISBN as one of the searching criteria to perform a search.

In one embodiment, the search result may be displayed using a map directly. The results may also include the distance from the user (mobile device or other specified location), prices, and product details. Following is an example of the result of a search on "Nike Air Max".

A map result of a preferred embodiment is shown in Figure 23. The map result contains the information with respect to the vendors, the prices at which the item is offered by the each Vendor, the route to get there and the distance along those routes.

When a user wants to buy more than one product, the customer application 10 allows the user to define a shopping list. To compile the shopping list, the customer application 10 provides an interface for the user to key in or scan the name, barcode, UPC, ISBN, etc of the product.

A Shopping List (hereafter refer as "SL") is a list of items of interest to customers. A shopping list can consist of one or more items. Each shopping list has a field to store the description of the list i.e. each SL can be named. A shopping list can exist as a permanent entity on a database or as a temporary list stored on the database or in memory during all or part of a user's session. Each item on a shopping list is linked to a unique identifier (one or more standard identifiers or an internally assigned identifier) on the database e.g.

Shopping list A

Item 1 : A can of coke - Barcode (5901234123457) Item 2 : A book entitled "Wuthering Heights" - ISBN (978-3-16-148410-0) Item 3 : A tyre - UPC (123456789999)

Generally, users would search the database (on the central server 14) by using a product description e.g. "coke". The central server 14 responds to the customer application 10 all the items with "coke" in the description e.g.

A Can of coke 220 ml

2 liter coke

1 liter coke

500ml coke Each item associated with an unique identifier (UI). The user can select which item they wish to add to the SL.

Each Shopping List can be linked to one or more shopping areas. Products listed by retailers registered in the shopping areas will be interrogated for pricing information. Figure 24 shows the relationship between the shopping list and the shopping areas.

Each item on a SL can be associated with a number e.g. 4 * tyres X [UPC (123456789999)] . A vendor may choose to apply a discount, special, or deals when more than one item of a particular type is purchased. For example : A vendor ABC normally sells a particular brand of tyre (X) for $100. However, they may self-report that a special/deal will apply if 4 tyres are bought in the same transaction. The number of the specific item a user's shopping list could be used to determine if the special/deal applies. If a user requests only 1 unit of an item, such as 1 * Tyre X then the user will be notified that the price of the tyre from vendor ABC is $100. In another example, when a user request multiple units of an item, such as 4 * Tyre X then the user will be notified the price for 4 tyres from Vendor ABC is $360 having $10 discounted per Tyre X.

A user can set up a shopping list with one or more validity dates and/or validity periods. A validity date/period will define the time for which a user is interested in purchasing items on the shopping list. The customer application 10 or central server 14 can filter items that are not due to be purchased so the user is only made aware of specials/prices that are available in the validity period for the shopping list.

When the vendors self-report the prices of the items, each price can be associated with a start and end date.

A vendor may report a number of prices for an item, and each price links to a validity period. For example, vendor ABC reports that the following specials/prices/deals on Item 1 will be available:

From 01.01.2013 to 15.02.2013 Price : $1

From 16.02.2013 to 31.02.2013 Price: $2

If a user has Item 1 in a shopping list, and the shopping list is attached to a shopping area which comprises vendor ABC, then the system 1 will report a different price according to the date of the shopping list, for example : when the shopping list has a validity date of 02.01.2013 then the price of Item 1 from Vendor ABC is $1; when the shopping list has a validity date of 17.02.2013, then the price of Item 1 from Vendor ABC is $2.

In one embodiment, the shopping list may contain more complex validity date information. For example:

Shopping list A - validity dates:

Including

• Every Saturday from 01.01.2013 to 31.12.2014 (as user goes

shopping on Saturdays)

• Every Wednesday from 01.01.2013 to 31.12.2014 (as user has

Wednesdays off and can go shopping)

· Period 01.02.2013 to 15.02.2012 (on holiday from work and staying at home)

Excluding

• Period 01.06.2013 to 15.07.2012 (on holiday overseas)

• 10.02.2013 (Son's birthday) Further a shopping list may have an end date associated with it. The system 1 and/or the customer application 10 will render the list expired on or after the date. This could be used when a shopping list was created for a specific purpose e.g. a person's birthday. The list is no longer valid after this date and will become dormant.

Referring to Figure 25, there is provided an interface for managing a shopping list in the customer application 10 according to a preferred embodiment of the present invention. Figure 26 shows an interface for adding a shopping list in the customer application 10 according to a preferred embodiment of the present invention.

A user may add an item into the shopping list with the interface as shown in Figure 26. In one embodiment, a user may scan the barcode of an item in order to add an item to the shopping list. A scanner on a mobile device or other device may be used to scan the barcode of an item . This will generally provide a link to the external identifier against which merchants report product prices

In another embodiment, a user can enter some text in a text field provided by an interface of the customer application 10. The system 1 may use matching method (exact match, phonetic match, close spellings match) on descriptions for searching items in the database to provide a list of possible items to which the user may be referring. An exact match on the description will result in the specific item being added to the SL. If more than one item was returned by the searching subroutine from the central server 14, the user can choose the sought after item from the compiled list or perform another or refined search. If the user selects an item, then the system's unique identifier and other information associated with that item will be added to the SL.

In yet another embodiment, a user can enter an external or internal identifier manually e.g. barcode number. In another embodiment, a user can upload a scanned receipt for multiple items. The system 1 may provide character recognition convert the receipt image into digital text. Each item is then used to perform an item search based on item descriptions. User may need to make selections from multiple possibilities where item cannot be fully resolved. In one embodiment, the customer application 10 may accept a photograph of the product. The customer application 10 then performs a search on the database through the central server 14 for match of the product. If the product cannot be found in the database, the customer application 10 may extend the search on the Internet for the product appearing in the photograph and retrieve the product information therefrom.

For each item, a user can select a number, a weight or unit to denote the quantity of the item(s).

The customer application 10 allows the user to create multiple shopping lists.

Each product on the users shopping list may be associated with a unique identifier (external or internal) on the database. Hence, for each product entered in the shopping list, customer application 10 will try to fetch the ID from the database through the central server 14. This can be done in a number of different methods, for example :

• performing a search based on product name or descriptions e.g. a bottle of 500 ml of Tasmanian rain water, lettuce, etc. The customer application 10 interrogates the database running on central server 14 and searches for the matching product using natural language search, fuzzy search, other searching algorithm;

• performing a search on external identifier such as barcode, or scanning item for barcode;

• performing a search on any other external identifier e.g. UPC/ISBN; · directly matching the internal identifier which should it be provided by the user;

• performing a category based search e.g. lettuce is a vegetable, which is a foodstuff etc.

It is possible to add constraints or searching criteria to the shopping list, such as limiting the price range. In one embodiment, the customer application 10 allows the user to constrain the purchase of a particular product in the shopping list to certain predefined shopping areas. In other words, different products on the user's shopping list can be associated with different shopping areas

For example, product 1 is heavy and therefore not easy to carry e.g. a box of 36 cans of soda. In this case, the user may not wish to carry product 1 on the train and hence even the product may be cheaper in a shopping area centered at location B and C. The user may still want to constrain the purchase of product 1 in shopping area centered at location A because purchasing in this area is more practical where a car can used to commute and transport product 1.

In another situation, a product 2 is small and easy to carry, for example a pack of AAA batteries. The user may search availability of product 2 in shopping areas centered at any of the locations A, B, and C.

Following is a table showing this relation.

In additional to the shopping list, the customer application 10 may allow a user to define a watch list. The customer application 10 will notify the user if all conditional criteria associated with a product on the watch list are satisfied. For example, a user may want to be notified when a particular product becomes available or becomes unavailable in a shopping area. In another situation a user may want to be notified when the availability price of a particular product/service on the wish list falls below a price threshold. Products can be on shopping list, watch list or both. Following is a table showing the relationship schema of a watch list.

The customer application 10 may further provides the function of different types of optimizations. In one embodiment, the customer application 10 can search for the best vendors to complete all the purchases on a shopping list. For example, a user defined a shopping list containing the following products:

Product 1;

Product 2;

Product 3;

Product 4; and

Product 5

For example, there are 3 vendors in the shopping area that is defined by the user. The products provided by each of the vendors and also exist on the shopping list are listed as follows.

When the user requests to find the best vendors to complete the purchase of the products on the shopping list, the central server 14 performs the following steps:

• fetches all the vendors that can provide at least one of the products in the user's shopping list which are located in the eligible shopping areas; and

• iterates through each of the products on the list and identifies the best vendor, i .e. the one which offers the product at the lowest price by comparing the price of the product among the vendors which resulted from the fetching step.

In the above example, after performing the above steps, the central server 14 may present the following results.

Shopping list Vendor A Vendor B Vendor C Best Vendor

Product 1 $1 $0.50 N/A Vendor B

Product 2 $2 $1.50 N/A Vendor B Product 3 $2 $2.50 N/A Vendor A

Product 4 $2 N/A $1 Vendor C

Product 5 N/A N/A N/A Not available

In another embodiment, the central server 14 keeps an item availability register and an eligible vendors list for storing the results of the optimization algorithm . As shown in Figure 27 there is provided a method of generating a shopping plan for shopping in one or more shopping areas or routes according to a shopping list comprising the step of: retrieving the vendors and the product information thereof from the central server 14 in the one or more shopping areas or route (101, 102); looping through the shopping list items (103); in the event that no match is found for the item in the list of products, updating item availability register (104, 105 and 106); in the event that at least one matching item/product is found for the item in the list of products, then updating the item availability register and the eligible vendor list; and comparing and sorting the vendors in ascending or descending order based on prices of the item provided by each of the vendors (104, 107, 108 and 109); reiterating the comparing steps above for all items on the shopping list (110); calculating % items available in area; calculating the route to all the vendors on the eligible list; and outputting the results (111).

When performing this algorithm, the system 1 has to receive one or more shopping lists in association with one or more shopping areas collected from the customer application 10. Each of the items defined in the shopping should be linked to a unique identifier. The central server 14 should have received vendor information such as the coordinates of the vendors, the items available, the prices and the associated price validity periods etc. collected by the vendor application 16. The best or shortest route to take when purchasing items from vendors may also be provided.

In one example, the customer application 10 will produce the following results:

Item 1 Item 2 Item 3 Item 4 Item 5 Item 6

Availability: 4 out of 6 items available = 67%

Purchase instructions

Go to Vendor A

Purchase :

Item 1 : $1

Item6 : $10

Total : £11 Then go to Vendor D

Purchase

Item 3 : $21

Total : $21 Then go to Vendor Z

Purchase

Item 4: $55

Total : $55 Grand total : $8_Z

Items unavailable in Shopping Area : Item 2, Item 5

In one embodiment, the present invention provides an algorithm for the system 1 to handle a constraint situation where the maximum number of shops is defined by the customer. The method, as shown in Figure 28, comprising the steps: finding all unique combinations of vendors containing the number of stops customer wishes to make (201, 202). Suppose there are 3 Vendors (A, B, C) and customer wishes to make 2 stops. Then set of unique combinations of 2 vendors is {(A, B), (A, C), (B, C)}. Suppose there are 5 Vendors (A, B, C, D, E) and customer wishes to make 3 stops. Then set of unique combinations of 3 vendors is {(A, B, C), (A, B, D), (A, B, E), (B, C, D), (B, C, E), (C, D, E), (A, C, D), (A, C, E), (A, D, E), (B, D, E)} for each element in the unique combination set (209, 215), further perform the following steps: retrieving the vendors and the products information thereof from the central server 14 in the one or more shopping areas or route (203, 204); comparing an item on the shopping list with the list of products provided by each of the vendors using the predefined unique identifiers of the items and the products (205); in the condition that no matching is found for the item in the list of products, updating item availability register (206, 207); in the condition that at least one matching is found for the item in the list of products, then updating item availability register; and comparing and sorting the vendors in ascending or descending order based on prices of the item provided by each of the vendors (211, 212, and 213); reiterating the comparing steps above for all items on the shopping list (208, 214); and calculating % items available in area and output the results (210).

An example of the output from the system 1 will be shown as follows.

Item 1 Item 2 Item 3 Item 4

Comb (A, B) BP Vendor A: $ 1 Not available BP Vendor A: $ 10 BP Vendor B: $20

Comb (A, C) BP Vendor C: $0.50 BP Vendor C: $30 BP Vendor A: $10 BP Vendor A: $22

Comb (B, C) BP Vendor C: $0.50 BP Vendor C: $30 BP Vendor B: $ 15 BP Vendor B: $20

Percentage items Savings (based on average price)

Best option : Vendors A and Vendor C - 100% items available with saving of $10.

Purchase instructions

Go to Vendor A

Purchase :

Item 3 : $10

Item 4: $22

Total : $32

Then go to Vendor C

Purchase

Item 1 : $0.50

Item 2 : $30

Total : $30.50

Grand total : $64.50

All items available

In another embodiment, the user defines a shopping list and one or more shopping areas through the customer application 10. A default shopping area could also be used where none has been provided. In one embodiment, the default shopping area is centered at the current location. Following is a table representing the shopping list.

Shopping List A

Shopping Areas: SA1, SA 2, SA3

The user may search for a number of optimized solutions, such as the best price based on one or more constraints defined by the user. The constraints may include the followings:

• Maximum number of stops at vendors allowed; • Validity dates (and or periods);

• Include petrol costs; and

• Include travel time.

In one embodiment, the user may specify the date for shopping as a constraint through the customer application 10. This date may be today's date or any other date. On receiving the request, the central server 14 may fetch all the vendors which provide at least one product on the shopping list and rank the vendors according to the price of each product on the shopping list. Following is a table representing the ranking results.

Shopping List A

Shopping Areas: SA1, SA 2

Date: 01.01.2013

In another embodiment, a user may request to compare the total purchase price of the products in the shopping list for a number of specified dates. Each of the date may individually be defined through an interface of the customer application 10. The customer application 10 may also provide an interface for the user to define a period of time for price comparison. Following is a table showing the price comparison result of a number of different dates. Shopping List A

The customer application 10 may display the above table to the user highlighting the date on which the best price can be achieved. The customer application 10 may allow the user drill into any of the squares and see prices for product by different vendors. For example, the user clicks on square containing "$1 Vendor A" for Product 1 on 01.01.2013 and the customer application 10 will retrieve the relevant data from the database through the central server 14. In the above example, the following table will be presented to the user.

Other constraints and changes can be applied. These could include maximum number of stops allowed, travel time minimisation, or petrol price for travel .

In another embodiment, the user may specify the maximum number of stops allowed for a shopping list and request to search for the best pricing. The customer application 10 sends the request to the central server 14 which will return best pricing limiting with the specified number of stops at vendors (all of which are located in the pre-defined shopping areas associated with the shopping list). Following is an example of the table representation of the search result. Shopping List A

Shopping Areas: SA1, SA 2

Date: 01.01.2013

Number stops: 10

When the user adjusts the maximum number of stops from 10 to 3, the above results will become the followings.

Shopping List A

Shopping Areas: SA1, SA 2

Date: 01.01.2013

Number stops: 3

Reference is now made to one of the above example where the central server 14 fetches all the vendors that can provide at least one product defined in the shopping list and the customer application 10 presents the following table as a result. Shopping list Vendor A Vendor B Vendor C Best Vendor

Product 1 $1 $0.5 N/A Vendor B

Product 2 $2 $1.50 N/A Vendor B

Product 3 $2 $2.50 N/A Vendor A

Product 4 $2 N/A $1 Vendor C

Product 5 N/A N/A N/A Not available

The user may defined the maximum number of stops allowed is 2. The central server 14 may try to find a solution for purchasing the maximum number of products on the shopping list under this constraint. The central server 14 may also find a solution for maximum saving under this constraint. Depending on the choice of the user, the database management 14 can search through different combination of vendors to maximize the number of produce available for purchase or to maximize the amount of saving in monetary term or in percentage term. The user may just visit Vendor A and Vendor B to complete most number of products on the shopping list. Following is a table showing the solution for purchasing maximum number of products.

However, the central server 14 may also find a solution for maximum saving Following is a table showing the solution for maximizing the amount of saving.

Shopping Best Vendor Price

list

Product 1 Vendor B $0.5

Product 2 Vendor B $1.50

Product 3 Not available

Product 4 Vendor C $1

Product 5 Not available The user can take the suggestions presented by the customer application 10 into account in order to plan the shopping trip.

In another embodiment, the user may put a constraint on the estimated maximum travel time through the customer application 10. Followings are tables presented to the user by the customer application 10 without and with estimated maximum travel time constraint respectively.

Shopping List A

Shopping Areas: SA1, SA 2

Date: 01.01.2013

Max travel time: no limit

Shopping List A

Shopping Areas: SA1, SA 2

Max travel time: 15 mins

Once the user has applied restrictions and criteria, the customer application 10 may further provide user with the following options: Which items should be purchased at each vendor;

The best route to take in order to visit all vendors;

Directions;

Print the results.

Figure 24 is an example print out of the search results.

In another embodiment, the customer application 10 provides a function for the user to search for the best shopping area in a large geographical location e.g. city, suburb based on a specific shopping list. To perform the searching function, the user specifies a shopping list of items linked to unique identifiers in the central server 14. The user further defines additional parameters, such as shopping radius, maximum number of stops and shopping region (e.g. Sydney) etc in the customer application 10.

The system 1 will consider the maximum number of stops allowed, and generate a unique set of combinations of vendors containing the maximum number of stops defined. Then for each element in the unique set, the system 1 will compare the items on the shopping list to the items provided by vendors in the element. The system 1 is able to determine one or more sets of vendors (all the vendors of each set fall within a circle of radius specified by the customer) and items to purchase at each vendor according to the one or more of the following criteria :

• Maximise the percentage of available items as specified on customer's SL (and at best price);and

• Maximise savings by comparing each item price to an average price for each item in some region .

Example : A customer lives in some region of Sydney. The customer has 5 items on a shopping list, each of which is linked to an unique identifier. The user specifies a shopping radius of 10 km and a maximum number of stops as 3. The input parameters from the user are as follows:

Input

Shopping list

• Item 1

• Item 2

• Item 3 • Item 4

• Item 5

Radius: 10 km

Maximum number stops: 3

The customer application may generate the follow output in addition to the map shown in Figure 29.

Max percentage of items

Availability: 5 out of 5 items available = 100% available

Purchase instructions

Go to Vendor A

Purchase :

Item 1 : $1

Item5 : $10

Total : iii

Then go to Vendor B

Purchase

Item 3 : $21

Total : $21

Then go to Vendor C

Purchase

Item 2 : $55

Item 4: $1

Total : $56

Grand total : $88

Savinas: $15

Max savings

Availability: 3 out of 5 items available = 60% available

Purchase instructions

Go to Vendor D

Purchase :

Item 1 : $1

Item5 : $2

Total : $3

Then go to Vendor E

Purchase

Item 3 : $12

Total : $12

Grand total : $15

Savinas: $18

In one embodiment, the system 1 performs searches and/or optimisations for items on a customer's shopping list in a specified Shopping area, route or region . The system 1 generally proposes which items should be purchased from which vendors. Sometimes these items may be available for purchase online. In this case the customer is notified and has the option to make an online purchase.

When an online purchase is made, the customer application 10 sends a request to the central system 14 containing the list of items to be purchased. The central system may have an account for the customer that includes the customer's home address and/or delivery address. The user account may also contain payment information such as credit card details.

In one embodiment, the central system 14 process the purchase transaction directly for the items to be purchased, and then passes information to the vendor application/account 16 which includes:

• Delivery/home address of the customer;

• Proof that payment has been made;

• Information that allows the vendor to redeem payment from central

system ;

• Other user information such as name etc; and

• The list of items purchased and the prices at which they were advertised .

In this case, the customer's payment details are only ever made known to the central system 14, and therefore the customer has less risk that their payment details will be used for fraudulent purposes.

In another embodiment, the customer's payment information is distributed to the vendor application 16 where the transaction process is handled by the vendor. In this case, the vendor is responsible for processing the payment and order. The following information could be passed to the vendor:

· Delivery/home address of the customer;

• Credit card details or other payment information for customer;

• Other user information such as name etc; and

• The list of items purchased and the prices at which they were advertised.

In one embodiment, as shown in Figure 31, the customer application 10 is running on a mobile device e.g. a mobile app. The mobile device application 10 constantly reports its location (GPS coordinates) to the central server 14. The user specifies a search radius. Using the mobile device's location and the search radius, the central system 14 is able to calculate which vendors fall within the radius specified by the user with respect to the mobile device. The central system 14 could report all items offered by vendors that fall in the search radius, or only items which match items on a shopping list specified by the customer. In some cases, items/specials may be available in the search radius or for online purchase. In this case the user will be notified. The user is able to choose to make a purchase of the items online and the instructions to purchase the items from a specific vendor are sent from the customer application 10 to the central server 14. The central server 14 is then able to pass relevant information to the vendor, such that the vendor is able to send the items directly to the customer's designated deliver address. The information sent from the central server 14 to the vendor application 16 could include one or any combination of the followings:

• Delivery/home address of the customer;

· Proof that payment has been made;

• Information that allows the vendor to redeem payment from central

system ;

• Other user information such as name etc. ;

• The list of items purchased and the prices at which they were advertised; · Delivery/home address of the customer;

• Credit card details or other payment information for customer;

• Other user information such as name etc. ; and

• The list of items purchased and the prices at which they were advertised.

Any mobile device can be used for hosting the customer application 10 or vendor application 16. Mobile device can use all specified methods above.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge, unless otherwise indicated.

Claims

1. An electronic device for determining a route comprising : a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, through a data network; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; wherein the central server calculate the routing results with the following steps:

(e) retrieving the vendors and the product information thereof from the database, wherein the each vendor is located in the one or more eligible areas or eligible routes; (f) looping through each item on the list and performing the following steps;

(g) calculating the percentage of items available; and

(h) calculating the route for visiting all the vendors .

2. An electronic device of claim 1, wherein the database contains information related to vendors who has populated products and vendors information in the database through a vendor application executed a computer device, wherein the products and vendors information comprises one or more of the following data : product name, product description, price, expiry date of the price, status of the product, number of unit available, discount status, expiry date of the discount, amount of discount, condition of the discount, vendor's name, vendor's address.

3. An electronic device of claim 2, wherein the central server is adapted to assign a unique identify for each of the product stored in the database.

4. An electronic device of claim 1, wherein the user interface is adapted to receive one or more constraint situations for calculating the route, where in the constraint situations comprising : minimum price, maximum number of shop allowed, locality for purchasing an item, weight of an item, traveling time, or petrol costs.

5. An electronic device of claim 4, wherein the comparing products and vendors information step further comprises the steps of in the event that the constraint is minimum price or not specified, find the vendors who provide the minimum price for an item .

6. An electronic device of claim 4, wherein the comparing products and vendors information step further comprises the steps of in the event that the constraint is travel time, find the vendors who has the shortest distant from the centre of a eligible area or eligible route.

7. An electronic device of claim 4, wherein the looping step comprises the following steps: in the event that the constraint is maximum number of shops allowed,

8. An electronic device of claim 2, wherein the central processing unit is further adapted control the user interface to provide the function allowing a user to record or save a special, deal, discount, or product of interest in the user profile, wherein the central processing unit will communicate with the central server and retrieve the status of the deal, and notify the user about any change in the status.

9. An electronic device of claim 1, wherein the geographic information system is adapted to obtain the location information from a user through the user interface and connect to a third party application such as Google maps to obtain the location information.

10. An electronic device of claim 1, wherein the geographic information system comprises a geographic positioning system which is adapted to generate coordinates of the current location of the electronic device.

11. An electronic device of claim 1, wherein the geographic information system is adapted to obtain a radius of the eligible area from the user interface.

12. An electronic device of claim 1, wherein the user interface is adapted to receive product information comprising one or more of a picture, bar code, ISDN, or description of a product; the central processing unit will send the product information to the central server for retrieving the unique identifier, and record on the list.

13. An electronic device of claim 1, wherein the route displayed on the user interface further comprises one or more of the following information : which items should be purchased at each vendor; the best route to take in order to visit all vendors; or directions.

14. An electronic device of claim 1, wherein the user interface is adapted to receive payment and online ordering information; the central processing unit will submit the payment and online ordering information to the central server.

15. An electronic device of claim 1, wherein the device is in the form of a smart phone executing a software application.

16. An electronic device of claim 1, wherein the device is a computer system executing a web base software.

17. A electronic system for determining a route comprising : a customer application device connecting to a vendor application device and a central server through data network, wherein the customer application device comprises: a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, a data network; a vendor application device adapted to receiving information of a vendor and information of products provided by the vendor; a central server comprising a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; the central server calculates the routing results with the following steps:

(e) retrieving the vendors and the product information thereof from the database, wherein the each vendor is located in the one or more eligible areas or eligible routes;

(f) looping through each item on the list and performing the following steps;

(iii) comparing and sorting the vendors in an order based on products and vendors information; calculating the percentage of items available; and calculating the route for visiting all the vendors .

18. A method for determining a route, using an electronic device comprising a geographic information system wherein the geographic information system is adapted to detect location information of the device; a user interface for accepting input from a user and displaying output to a user, and a central processing unit adapted to control the data flow to and from the user interface, geographic information system, through a data network; wherein the user interface is adapted to accept a list of items, and displaying the route thereon; the geographic information system is adapted to retrieve location information of one or more eligible areas or eligible routes; the central processing unit is adapted to send the geographic information and the list of product information to a central server, and to receive a routing results from a central server, wherein the central server comprises a item availability register and hosts a database containing information of vendors who has populated products and vendors information in the database; comprising the steps:

(f) retrieving the vendors and the product information thereof from the database, wherein the each vendor is located in the one or more eligible areas or eligible routes;

(g) looping through each item on the list and performing the following steps; (i) in the event that no match is found for the item in the list of products, updating the item availability register;

(h) calculating the percentage of items available;

(i) calculating the route for visiting all the vendors

(j) displaying the route on the user interface.

19. A computer readable media for storing the method of claim 18.