GB2505423A - Facilitating purchases within a retail environment - Google Patents

Abstract

A server 510 for facilitating the purchase by a user of at least one product within a retail environment 540, 550, 560, comprises: an input module 110 for receiving product identification data indicating said at least one product that the user wishes to purchase; a data interface 112 for interfacing with at least one database containing retail environment data that encodes at least one property of the retail environment; a processing module 114 for processing the product identification data in conjunction with said retail environment data to generate product location data encoding the location of said at least one product within the retail environment; and an output module 116 for outputting the product location data. The server forms part of a system enables a user to input a shopping list on a mobile device and determines an optimum route around the retail environment which is displayed to the user on the device. The system can further enable shopping amongst multiple stores and can provide a map of shops and locations to facilitate the acquisition of products. The mobile device includes an application.

Description

FACILITATING PURCHASES WITHIN A RETAIL ENVIRONMENT

Field of the invention

The presenc invention relates to a server and system for facilitating the purchase by a user of at least one product within a retail environment.

Background of the invention

Many online shopping systems exist which allow users to carry out purchases from retail environments without physically having to select products or to be physically present within a retail environment such as a shop or supermarket. Such systems are often provided as web pages on the Internet and may typically be accessed from a user's home or workplace.

Onlino shopping brings many convonioncos, but has certain drawbacks. For example, users cannot physically inspect products until they are purchased, for example to check for defecus or to select particular types of product most of interesu to the customer. In addition, the need for products to be delivered to the user can introduce extra cost and delay, and can be damaging to the environment.

There thus remains a need for some customers, many of whom may not have access to the Internet or appropriate computing facilities in the first place, to be able to make purchases in a physical retail environment such as a shop or supermarket. For many this can be a time-consuming, frustrating or confusing experience due to the large number of products than may be displayed in a physical retail establishment. To counteract this problem, retailers conventionally direct customers to online shopping alternatives as described above. Hcwever, as noted above, in some cases this is not desirable or not possible.

Summary of the invention

The present invention overcomes these deficiencies of the background art by providing a server for facilitating the purchase by a user of at least one product within a retail environment, the server comprising: an input module for receiving product identification data indicating said at least one produot that the user wishes to purchase; a data interface for interfacing with at least one database containing retail environment data that encodes at least one property of the retail environment; a processing module for processing the product identification data in conjunction with said retail environment data to generate product location data encoding the location of said at least one product within the retail environment; and an output module for outputting the product location data, whereby to facilitatc tho acguioition of oaid at loast onc product by the user within the retail environment.

From the point of view of a user, this can increase the ease and efficiency of purchasing products within a retail environment, and this can also provide a greater through-flow and turnover for the retailer. The advantages may extend to reducing interruptions to shelf-stackers, for example, in order that they can direct a user to a particular product in the store, making this part of the retail operation more efficient.

It is noted that the product identification data can be a list of products or an identifier or similar allowing an identification of a pre-existing list of products and the like. In the latter case, the pre-existing list of products may be transmitted to the server in a previous step or may be stored on a remote database and accessed as and when reguired by the server, for example. This can reduce the amount of network bandwidth reguired during normal operation of the server. The location data may be include one or more of: a list of locations, a map indicating one or more locations and/or one or more route plans, audio and/or visual data ccnuaining instructions for locating at least one of said products, and data suitable for use by a navigational aid for directing the consumer to at least cne of said products. The location is preferably but not necessarily a physical location.

Tt will also be appreciated that the input module and output module may exist only virtually, and may be physically embodied in a single input/output device or suite of input/output devices. The input and output data may for example be transmitted via a single wired (such as Ethernet/Internet) or wireless (such as Wi-Fi) connection, or via differenc respective connections.

Tt is appreciated that, while the server as aforesaid is described in the context of products available for purchase within a retail environment, the invention can also extend in related aspects to transactions other than purchasos, to non-transactional oircumstanoos, and/or to non-retail environments as appropriate. For example, a user need not be physically located in the retail environment during any stages of operation of the server and/or related systems or processes, and the server may be incorporated virtually or otherwise into an online service such as an online shopping service or otherwise.

The output module is operable to output additional data encoding at least one of: price information, total or expected cost, a promotional code, product type information, product brand name information, and suggested alternative product types or brand names.

In another aspect of the invention there is provided a system for facilitating the purchase by a user of at least one product within a retail environment, the system comprising: at least one database containing retail environment data that encodes at least one property of the retail environment; a location assistance server, including: an input module for receiving product identification data indicating said at least one product that the user wishes to purchase; a data interface for interfacing with said database; a processing module for processing the product identification data in conjunction with said retail environment data to generate product location data encoding the location of said at least one product within the retail environment; and an output module for outputting the product location data, whereby to facilitate the acquisition of said at least one product by the user within the retail environment; and a user device, including: input means for receiving a user selection indicating said at least one product that the user wishes to purchase; output means for transmitting the user selection to the location assistance server in the form of product identification data; input means for receiving product location data from the location assistance server; and display means for displaying the product location data to the user.

In a further aspect of the invention there is provided a usor dovico including a ocrvor as afoycsaid. In an alternative embodiment there is provided a user device (including a processor and input/output module and optionally a display) operable to interact with a server as aforesaid.

The user device may further comprise a wireless communication module, in which case the database may be accessed via the wireless communication module.

The user device preferably includes or is operable with a software application that provides an interface between the user and the server, and also (optionally) provides an interface between the server and the user device hardware (for example by interpreting and acting on commands received from the server) , for example to facilitate usage of the wireless (or wired) communication module to communicate with other devices such as servers associated with a retailer or a particular recailer's store in order to obtain the retail environment data. In an alternative embodiment, the user device may communicate with a retail-related server via a mobile phone or other (wired or wireless) network, and in particular via the aforementioned server (if separate to the user device) or another server such as a centralised server associated with a particular retailer or group of retailers.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The materials, methods, and examples provided herein are illustrative only and not intended to be limiting.

Implementation of the method and system of the present invention involves performing or ccmpleting certain selected tasks or stages manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of preferred embodiments of the method and system of the present invention, several selected stages could be implemented by hardware or by software on any operating systom of any firmwaro or a combination thoroof. For example, as hardware, selected stages of the invention could be implemented as a chip or a circuit. As software, selected stages of the invention oculd be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In any case, selected stages of the method and system of the invention could be described as being performed by a data processor, such as a computing platform for executing a plurality of instructions.

Although various aspects and embodiments of the present invention have been described separately above, any of the aspects and features of the present invention can be used in conjunction with any other aspect, embodiment or feature where appropriate. For example apparatus features may where appropriate be interchanged with method features.

Brief description of the drawings

The invention will now be described further, by way of example, with reference to the acccmpanying drawings, in which: Figure 1 is a schematic block diagram of a system according to a first embodiment including a service provider server and a customer device; Figure 2 is a block diagram of a system including a customer device, a plurality of retailer systems, and the service provider server of Figure 1; Figure 3 is a block diagram showing an alternative configuration of the system of Figure 2; Figure 4 is a block diagram showing a further alternative configuration of the system of Figure 2; Figure 5 is a block diagram illustrating an example configuration of a system that interconnects a plurality of retail stores, a customer computer, a customer handset, a retailer server, and the service provider server of Figure 1; Figures 6a to 6h are exemplary screen shots of a computer application designed for use with the service provider server of Figure 1; and Figure 7 is an example annotated map for use with the application of Figures 6a to 6h.

Detailed description of the preferred embodiment(s) With specific reference now tc the drawings in detail, it is stressed chat the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in order to provide what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to thcse skilled in the art how the several forms of the invention may be embodied in practice.

Various different systems for facilitating the purchase of products within a retail environment are described below.

In overview, the system allows the user to specify a list of products, and then provides the user with location information which allows the user to find the selected products more easily within a particular retail environment.

The operation of the system will now be described in more detail.

Figure 1 is a schematic block diagram of a system according to a first embodiment including a service provider server and a customer device. The server 100 includes an input module 110 (typically an input/output subsystem), a retail data interface 112 (typically the same or a further input/output subsystem, or in some cases a hard disk, flash memory or other mass storage interface) for accessing a databasc 120 containing rolcvant rctail cnvironmcnt data (see below), a processor 114 (in some cases one processor and in other cases a plurality of processors which may be arranged in a distributed or cloud computing' fashion), and an output module 116 (again, typically the same or a further input/output subsystem as the input module 110 and/or retail data interface 112) . The customer device 130, which may be a handheld device such as a mobile telephone or PDA or a fixed device such as a desktop computer, includes a processor 132, a display 134 and an input/output module 136 (which may include a network communications mcdule such as a Wi-Fi and/or mobile telephone transceiver unit, a touchscreen and/or keyboard or pointing device input, an Ethernet connection, and so on) It will be appreciated that the service provider server described herein can be a physical entity (such as a stand- alone computer), a virtual entity, such as a software sub-component of an application (running on a desktop computer, tablet computer, mobile telephone, and any other appropriate form of computing device, mobile or otherwise), or somewhere inbetween, such as a stand-alcne software module executing on a hardware sub-component of a server farm and the like.

Figures 2 to 5 below illustrate a principal embodiment in which the service provider server is a network entity with which the customer device can cormuunicate in a client-server architecture, allowing more efficient use of the customer device because it does not have to carry out the bulk of the processing. In a further embodiment (not shown) , more suitable for domestic desktop computers, work computers, and more advanced computing facilities, the functionality of the service provider is incorporated within the customer device (or the like), in which case it will be appreciated that necessary and appropriate modifications will be made: the functionality of the input module 110, output module 116, retail data interface 112 and input/output module 136 may be combined into less than four (and as few as one) modules, and likewise for the processors 114, 132, and so on.

In uso, tho input modulo 110 rocoivos an indication of a list of products that a customer wishes to purchase. In a first variant, The indication is a list of the products, which is identified by plain text cr the like, or encoded using commonly understood identifiers or other any other appropriate code. In a second variant, the indication is a reference to a pre-existing or dynamically generated list of products. The indication may, as before, be transmitted as a plain text string or in any suitable encoding containing identifiers or The like. In a further variant, the input module is operable in either mode as the need arises. When appropriate, the server 100 performs a look up' operation when it receives a reference to a pre-existing or dynamically generated list (using optional further modules, not shown) , such that the next stage of processing will begin in all cases with a list of products in an appropriate format understood by the server. In the case of a pre-existing list, The list may be stored locally to the server 100, or may be retrieved from elsewhere, for example from another server on a related network (or otherwise) The processor 114 takes the list of products and processes the list in conjunction with data retrieved from the retail environment database. The result of the processing is a list of locations of each respective product within the retail environment. The output module 116 then transmits the list of locations to the customer, who can then use the location information to assist him in finding the relevant products within the retail environment.

The retail environment database is typically a database maintained by a retailer, or a full or selective mirror thereof, which includes information that allows the location of a particular product to be determined, even indirectly.

The database may for example be the main (or subsidiary) stock control database, which may have exemplary fields as illustrated in Table 1 below: TABLE 1: EXEMPLARY FIELDS OF RETAIL ENVIRONMENT DATABASE

Exemplary field name Exemplary data in field

Product code 1234511563 Product type name Eggs Product brand code 252352 Product brand name Supershop own brand Product subtype Large eggs Undiscounted cost £2.50 Units in stock 125 Aisle 5 Shelf 1 In this example, certain fields (in particular Aisle' and Shelf', indicating the aisle and shelf on which the product should be stocked, contain information pertaining to the retail environment and in particular designate a geographical location of the product) It will be appreciated that different database formats exist and that the data in Table 1 may typically be generated by joining different tables (for example to look up' a brand name from a brand -10 -code, and so on), and in this example has been filtered (if necessary) to show data relating tc a particular store (such that the Aisle and Shelf fields in this oase have a useful meaning, as the locations may vary in different stores and for different retailers) In the case of the processing that might be carried out by the processor 114 in this example, the processor would typically find database records matching a product type corresponding to a product in the customer's list of products, and would extract the aisle and shelf fields, which provide a geographical location of the product. The processing may be more complicated, for example if the location is given only indirectly or if different/further data sources need to be accessed and combined. (The management of data by retailer and by store, and different associated configurations of the above-described system, is described in more detail below.) Thc list of locations may bc proccsocd furthcr, cithcr at the server, at a customer device, or elsewhere, in order to provide different degrees of sophistication of location information. Wirh regard to the exemplary database of Table 1, Table 2 below shows arguably the simplest form of output, essentially by joining the two tables consisting of the product list and the retail database (and, as noted above, the operation may be more complicated in other examples) TABLE 2: EXEMPLARY LOCATION DATA Product name Aisle Shelf Milk 2 2 Eggs 5 1 Bread 4 4 Chocolate 1 1 Potatoes 6 5 Orange Juice 2 6

-U -

Further steps of processing may involve calculating optimal routes and rearranging the location data accordingly, as well as processing to allow the location data to be displayed graphically and/or to be incorporated into mapping systems, as will be described in more detail below.

On the user device 130, functionality is typically provided by a software application (not shown) which provides an interface between the user and the server 100.

The application (described in more detail below) typically handles the creation and/or management of the product (or shopping') liscs, which may in require communication with the same or a further server that may retain persistent copies of a user's shopping/product lists, for example. The application typically controls the submission of the shopping list, as well as the appropriate selection of a location (that is to say, shop or supermarket and the like) whoro tho products arc dcsircd to bo found.

Functionality may be provided to identify appropriate or convenient locations to find particular specified products (for example by interrogating the relevant stock lists and also oomparing the user's location with locations of appropriate retail locations) For example, in one embodiment an additional server and application module are provided (not shown) whereby the software application reports the user's location and desired product list to the server, and the server returns a list of suggested retail locations in a suggested order of priorities. In this case the server mighc suggest a shop that is a little further away than a shop that is more convenient, on the basis that the shop further away has a more complete (or fully complete) selecrion of the products in stock at that time.

It will also be appreciated that the examples of products given herein are overly simplistic in order to facilitate ease of understanding of the present embodiments.

The reality is more complicated and requires more sophisticated treatment of the product list management and -12 - processing steps described above, such that turning a user-specified shopping list into a list of locations is not at all straightforward. One reason why this is so is firstly because different retailers may employ different data formats and may use different internal product codes and/or product names. Secondly, retailers may stock multiple brands or types of a generic product; customers typically describe the products they want in generic terms, so that a translation has to be made between a generic product type (such as eggs, milk, and so on) and specific brands or types. In the event that a customer does describe a specific product type (such as the particular brand or sub-type of a product) , problems may still remain because there may be a variety of package sizes, or the particular brand or sub-type sought by che customer may be out of stock but they might consider another brand to be a perfectly acceptable alternative.

It is usually thc aim of rotailcrs to prosont all sub-types of a product in the same place (to facilitate choice and convenience), such that in many cases it does not matter if there is ambiguity or uncertainty over which particular sub-type of product the customer is interested in, at least to an apprnpriace degree of geographical accuracy. In some cases, however, similar products can be stored in widely differing locations within a retail environment. Kosher products may have their own locaticn, for example, and other products may be put in prominent lccations if they are on special offer, and so on. In the preferred embodiment the system addresses the problem as follows: the system allows the user to specify products with differing and user-defined degrees of precision (such as milk' in the generic case, or Supershop own brand milk' or semi-skimmed milk 2 litre bottle' more precisely, or with full precision such as Supershop own brand semi-skimmed milk 2 litre bottle', and so on) . When processing the product list in conjunction with the retail environment database, all relevant possibilities are considered. If all possibilities are located in the same -1_3 -location (such as aisle 3, shelf 1') cr sufficiently closely within a user-defined (or ctherwise) degree of geographical precision (which may be, for example, within the same shelf in an aisle, within three adjacent shelves, within the same aisle, or on shelves immediately opposite each other on adjacent aisles, within 1 metre, within 5 metres, within sight of each other within a minimum distance or otherwise, and so on), then a single location is output and the processing continues to the next item. In the case where a specified product type can be found in multiple locations, the behaviour can be oustomised or calibrated as appropriate, but typically one or more of the following actions will occur: for relatively small numbers of candidate locations, the server will simply output multiple locations and these will be presented to the user. Tnstead, or additionally, the user may be prompted to choose a more specific choice of product. Most easily and obviously the uoor can simply bo prosontcd with all poosiblo product sub-types (such as Supershop own brand semi-skimmed milk 2 litre bottle', Supershop own brand semi-skimmed milk 4 litre bottle', and so on) but this can be onerous for the user to view and/or scroll through and deliberate on.

Instead, the user is typically presented with a list of choices of product at a level of specificity sufficient to resolve the location ambiguity and no more, such that he might be presented with a choice, for example, of milk, all types and sizes' and milk, 4 litre bottle all types, special offer' and the like. To this end, in this embodiment, a product disambiguaticn module (not shown) is provided in the server and/or in the customer device in order to facilitate these computations. The task of reclassifying products can be quite involved and therefore may be carried out entirely on the server using the server-client architecture, but the result can greatly increase ease of use.

As noted above, a translation module may also be provided to mediate between product descriptions used by -1_4 -different retailers in order to provide a oonsistent interface to the user despite a variety of data formats (though clearly many efforts have been made to ensure consistency where possible using various universal codes and the like) . In one embodiment a mediatinc database (not shown) is provided, accessible to and optionally concurrent with the server 100, which database contains standard terms for use on the customer side and/or with the customer application, and retailer-specific terms that are used to facilitate the processing of the retail environment database as described above. In a further embodiment, product descriptions are handled in a more dynamic fashion, such that in the event of a mismatch between product names, less and less specific product types are used (courtesy of the disambiguation module described above) until a match can be made. Optionally any ambiguities or mismatches/ mistranslations can be presented to the user to allow the usor to choooo a product typc corrcsponding to what thcy intended to purchase. This selection can then be stored for future reference in a user history, to assist with any future mismatches and the like.

Disambiguanion can be assisted further in one embodiment where retailers feed back (with the permission of the customer where appropriate) purchase histories of the customer, so that the system can learn preferred package sizes, particular brands of generic products desired by the customer, and so on. This can take transparently to the user, all the time reducing the input required from the user in order to disambiquate or specify more precisely products of interest.

For convenience, straightforward product examples will continue to be used herein but it should be borne in mind that the systems described above can be used as and when appropriate to deal with more complicated real-world

examples.

Various different oonfiguraticns of the system, in conjunction with various retailers, will now be described.

-1_S -Figure 2 is a block diagram of a system including a customer device, a plurality of retailer systems, and the service provider server of Figure 1. A customer device 210, a service provider server 220, and a group of retailer systems 230 are shown. The retailer systems 230 include a central server 240 for a first retailer, and databases 242, 244 specifically associated with (and typically local to) two exemplary shops cperated by the first retailer. The systems 230 also include a correspcnding server 250 and databases 252, 254 of a second retailer, and a corresponding server 260 and databases 262, 264 of a third retailer.

In this system, the (product location service) service provider server 220 communicates via the retailer servers/firewalls 240, 250, 260 in order to access the databases 242, 244, 252, 254, 262, 264 of particular shops.

Thus if, for example, a user wishes to find products in Shop 1 of Retailer 1, the service provider server 220 accesses tho data in databaso 242 via rctailor oorvcr 240. Thc database 242 may typically be a standard stock control database with additional fields containing the geographical location of each product. In a variant, an additional or alternative database, separate to a stock control database, is provided (locally or centrally -see below) which specifies the geographical location of particular products.

This may be useful, for example, to provide a more coarse level of detail that the stock database. The stock database lists all types and brands of products, whereas the database 242 may for example only specify the location of generic products, resulcing in far less data, bandwidth, and maintenance of The database. The discrepancy between specific prcduors that may be specified by the user and the generic product data of the database 242 (in this example) may be resolved by the disambiguation processes mentioned above.

Figure 3 is a block diagram showing an alternative configuration of the system of Figure 2. In this example, a customer device 310, service provider server 320 and group -16 -of retailer sysrems 330 are again shown. In this example, the retail environment data is stored centrally. There are shown, in particular, retailer servers 340, 350, 360 and associated central databases 342, 352, 362. The operation of the system is as described before, although there will typically be required more filtering on the databases 342, 352, 362 in order to isolate data pertaining to a particular retail environment. It may be that only some shops have the necessary data, or a complete set of data, and the server 320 adapts as necessary.

Figure 4 is a block diagram showing a further alternative configuration of the system of Figure 2. As before a customer device 410, service provider server 420 and group of renailers 430 are shown. In this example, the service provider 420 communicates directly with the databases 442, 444, 452, 454, 462, 464 of the retailers 440, 450, 460, very much as before but with appropriate authontioation as nooossary oarrioci out dirootly with tho databases (in reality servers attached to databases) Figure 5 is a block diagram illustrating an example configuration of a system that interconnects a plurality of retail stores, a customer computer, a customer handset, a retailer server, and the service provider server of Figure 1. This figure illustrates a number of interconnections that may exist in practice in relation (for ease of illustration) to only one retailer (though of course the figure could be extended to other retailers as described above) . A service provider server 510, retailer server 520, customer location 530 (such as a home or workplace), customer handset 536 (which may be a mobile phone or other device) and three stores 540, 550, 560 are shown. At the (optional) customer location, a computer 532 and (optional) printer 534 are shown. The customer location is connected to the service provider 510 by the Internet 502 (though other arrangements are possible, including the above-mentioned arrangement in which the service provider 510 functionality is incorporated directly or indirectly into the user computer 532 and/or -1_7 -handset 536) . The customer handset 536 is typically connected to the servioe provider 510 by a mobile phone network 504 (in partioular an Internet connection thereon) but other connections are of course possible (such as via wireless access points, WAPs, and the like) . The retailer server 520 is actached to a central database 522 that includes retail environment information.

In the first store 540 a store server 542, store database 544 and Ethernet connection 546 are shown. The operation of the system with regard to this store 540 is essentially as described above. Additionally, a user at the customer location 530 may, for example, print out (using the printer 534 or otherwise output) a shopping list prepared using the application software in conjunction with the service provider server 510. The list may for example contain the liso of products specified by the user, disambiguated or made more specific as appropriate and as doscribod abovo, and may contain for cach product a summary of where the product may be found (for example an aisle and shelf number) . Alternatively or additionally the print-out may contain a physical (or logical) map of the shop with the locations of each product marked on, as is described in more detail below wiTh reference to Figure 7.

In the second store 550, the retail environment data is stored centrally on the database 522. This database can be queried as before via computer 532, Internet 502, server 510 (if done via computer 532), server 520 or via handset 536, network 504, server 510, server 520 (if done via handset) However, in this important embodiment the handset 536 can (relatively) directly guery the store 552 via the Wi-Fl router 556 and a corresponding Wi-Fi tranceiver in the handset (not shown), or via a similar wireless or wired communication medium. In response to requests received from the handset 536 via router 556, the server 552 communicates with the retailer server 520 to obtain the necessary data from the central database 522.

-18 -In the third store 560, the retail environment data is stored locally This Lime in database 564, and there is provided a store server 562 and Wi-Fi router 566.

Communication takes place directly between the handset 536 and server 562 and database 564 and no communication is required external to the store. Thus the full functionality of the system can be provided using only local communication within the retail environment. Thus devices lacking independent network or telephone connectivity can in appropriate circumstances provide the full functionality as described above.

It will be appreciated that the elements of Figure 5 are neither exhaustive, nor in all cases mandatory. The elements at the customer location 530 may be omitted, for example or, conversely, so could the handset 536, and so on.

Figures 6a to 6h are exemplary screen shots of a computer application designed for use with the service providor scrvcr of Figurc 1. Thc picturcd application is of a type suitable for a mobile phone or smaller form portable computer, for example, and different and/or more sophisticated interfaces are of course possible.

Figure 6a is a screen shot of a simple product selection and/or listing screen, containing a (simplified) shopping list chosen by the user. Lists can, for example be saved and recalled. In this example, one button advances to a store selection screen.

Figure Gb is a screen shot of a store selection screen.

In this embodiment, based on the product list supplied by the user and the location of the user as reported (for example) by the user device, the application has offered a number of alternative shops. This list may, as previously mentioned, be prioritised by distance and/cr other factors such as whether any of the products are out of stock at the locations. This information is determined by interrogating the relevant stock control databases, which is typically done server-side to minimise network bandwidth and processing required of the user device. This screen may be -1_9 -supplemented or replaced by a map-based display and may, for example, integrate into existing mapping and positioning applications. In will be appreciated that the store selection and product selection are interchangeable and/or combinable, such that a user can fcr example browse/search products available at a particular selected shop, or browse/search products stocked by a particular retailer, and so on.

Figure 6c is a screen shot of a summary page, in which the same or a further (as the case may be) database check has been carried out, in this case presenting an estimated total cost of the purchase of the selected products. It will be appreciated chat information such as this can be presented at other stages, for example to allow a comparison of particular retailers or shops based on price as well as distance, stock availability, and other factors. The options presented on this screen shot (re-check availability, view altcrnativcs, and so on) arc mcrcly cxcmplary and arc neither exhaustive nor mandatory.

Figure 6d is a screen shot showing a simple list of products and locations, indicating (in this case) the aisle and shelf on which they may be found. It will be appreciated that any appropriate geographical location may be used, such as actual coordinates (useful to feed into positioning applications and the like) , relative or absolute designations, such as opposite the large blue doors' , next to the rotisserie', and so on.

Figure 6e is a screen shot illustrating the list of Figure 6d after it has been optimised, in this case in ascending aisle number though more generally this will be done in accordance with an appropriate algorithm (for example one addressing the travelling salesman' problem) to provide a list in an order that results in an efficient route through the retail environment, and typically a route of least (or at least minimal) distance.

Figure 6f is a screen shot with an alternative, graphical display of the retail environment, showing (with -20 -X) products than have been selected. This is of course one of many different approaches to presenting the information graphically. Location data may for example be displayed using dedicated/pre-existing/inbuilt mapping applications.

Typically the user is able to re-orient, scroll around, resize the map, and so on. Using a graphical display such as this, the user can more easily orient themselves and see where they need to go to find their products.

Figure 6g is a screen shot with an example interface showing the effect of a user selecting one of the items displayed on the map (which may be applied equally to list-based displays such as Figures 6e and Of, for example) Different available brands and prices can be viewed, for example, and various further processing options can be provided. The user can for example look for alternatives, directions, prices, different sizes, comparisons with other stores and retailers, and so on. The user can also mark the product as found so that it is romovod from thc map and/or marked as complete on, or deleted from, the current copy of the product lisn.

Figure 6h is a screen shot showing a simple product finder that can be used within a particular retail environment or more generally (for example in combination with a store locator of the type shown in Figure 6b or otherwise) . A user can for example browse (via this interface or otherwise) any brand or product type or sub-type, and see what is in stock, how much products cost, obtain directions, and so on. A user can in particular (for example) find out which one (or more) of a group of retailers stocks a particular product or brand (or size, and so on as before), which can be useful for finding rarer products.

Figure 7 is an example annotated map for use with the application of Figures Oa to Oh. In this example, a suggested route (dotted line) is shown, being (in theory and not in this case) an optimal or near optimal solution of a route that passes all selected products while minimising the -21 -amount travelled. The route can be computed as described above using any appropriate algorithm. The user can for example modify The route, if appropriate. The map may also be updated, resized, and so on, to track the user's progress. If the user passes a product and moves on, the system may assume and/or prompt the user to confirm that the product in guesrion has been found. The system may also provide prompts and directions, for example in a sat-nay' style while the user is in the retail environment, and may for example sound an alarm when the user is in proximity to a selected product.

A map such as that shown in Figure 7, optionally including additional information such as an indication of what products are located where, and so on, could be provided in a print out as described in relation to Figure

5, for example.

From the retailer's perspective, additional work may be rcquircd in order to allow the gcographical location of particular products to be extracted or deduced. However, as noted, this may be simplified by recording positions for large classes of product rather than recording a position for each producu type and sub-type. The process of recording locations of stock can also be combined relatively easily with existing (and largely automated) stock checking processes. Retailers may benefit through advertising tie-ins with the above-described system, or through an ability to offer more customised promotions and the like, for example.

There are additional benefits in that less information would need to be given to consumers by members of staff in the shops, allowing for various efficiencies.

Additional benefits may flow to the mobile telephone and other companies involved in the networking aspects of the system through the issuing of licences and similar provisions.

It will be appreciated that the screen shots illustrated in The figures and described above are exemplary and other arrangements, including different selections of -22 -information to display or input on any given soreen, are of course possible. In one variant, applicable to any embodiment, advertisements or other information can be displayed on one or more screens. This can for example include informarion provided by the service provider or by other entities such as one or more of the retailers. A retailer can, for example, display offers of the day' or similar advertisements and/or information in a portion of the screen. Offers can be tailored in response to information displayed to or provided by the user.

In one embodiment, if any products in the store are not where they are expected, users can provide feedback to the system in any appropriate form (such as, for example, inputting an aisle and shelf reference or similar, or merely indicating that they are standing in the appropriate place and letting positioning systems in a user device provide location data) . In response the system may do one or more of: inform thc rctaiicr and/or storo of thc diocropancy and request an updace, and maintain a separate record of the location of parnicuiar products which will override a retailer's own version so that future location requests will yield the corrected result.

In another embodiment, the user indicates -or the system infers -any retail environments which are commonly frequented or of particular interest, and the system ensures that the user device, or any appropriate device local to the user, has a locally-cached version of the relevant data which is updated at appropriate moments (for example when locations and/or prices change) This can ensure that the user has instanr access to location data when in the relevant retail environment, without requiring a network or other data connection at the time. The amount of data can be kept manageable by limiting to generic or semi-generic product types and/or by limiting tc product types historically of interest to the user and/or predicted to be possibly of interest. Accordingly the service provider -23 -server and/or looator application may include a predictive module (not shown) for this purpose.

It will also be appreciated that different embodiments (such as the last two embodiments described immediately above) have been distinguished above for ease of understanding and on the understanding that any aspect of any embodiment can be combined with any aspect of any other embodiment unless there exists a clear reason why such a combination is not possible or appropriate.

Although the present invention has been described above with reference cc specific embodiments, it will be apparent to a skilled person in the art that modifications lie within the spirit and scope of the present invention.

Claims (8)

1. -24 -CLAIMS1. A server for facilitating the purchase by a user of at least one product within a retail environment, the server comprising: an input module for receiving product identification data indicating said at least one product that the user wishes to purchase; a data interface for interfacing with at least one database containing retail environment data that encodes at least one property of the retail environment; a processing module for processing the product identification data in conjunction with said retail environment data to generate product location data encoding the location of said at least one product within the retail environment; and an output module for outputting the product location data, whoroby to facilitato tho acquisition of said at best one product by The user within the retail environment.
2. 2. A server according to Claim 1, wherein the output module is operable to output additional data encoding at least one of: price information, tctal or expected cost, a promotional code, product type information, product brand name information, and suggested alternative product types or brand names.
3. 3. A syscem for facilitating the purchase by a user of at least one product within a retail environment, the system comprising: at least one database containing retail environment data that encodes at least one property of the retail environment; a location assistance server, including: an input module for receiving product identification data indicating said at least one product that the user wishes to purchase; -25 -a data interface for interfacing with said database; a processing module for prooessing the product identification data in conjunction with said retail environment data to generate product location data encoding the location of said at least one product within the retail environment; and an output module for outputting the product location data, whereby to facilitate the acquisition of said at least one product by the user within the retail environment; and a user device, including: input means for receiving a user selection indicating said at least one product that the user wishes to purchase; outpur means for transmitting the user selection to the location assistance server in the form of product idontification data; input means for receiving product location data from the location assistance server; and display means for displaying the product location data to the user.
4. 4. A user device including a server as defined in Claim 1 or 2.
5. 5. A user device operable to interact with a server as defined in Claim 1 or 2.
6. 6. A user device according to Claim 4 or 5, further comprising a wireless communication module, and wherein the database is accessed via the wireless communication module.
7. 7. Apparatus substantially as herein described with reference to Figures 1 to 7.-26 -
8. 8. A method substantially as herein described with reference to Figures 1 to 7.