A method of, and apparatus for, location-based monitoring in a retail environment

GB2636976APending Publication Date: 2025-07-09IMPULSELOGIC LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
GB2023018672
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-12-06
Publication Date
2025-07-09

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A computer-implemented method for location-aware tracking of products in a retail environment comprises providing an inventory of products in the retail environment, each product having an associated
Need to check novelty before this filing date? Find Prior Art

Description

The present invention relates to an improved method of, and apparatus for, location-based monitoring in a retail environment. More particularly, the present invention relates to a computer-implemented method for location-aware tracking of products in a retail environment comprising a sales floor and a storeroom. Retail inventory management is a critical aspect of ensuring efficient operations and customer satisfaction. However, existing systems fail to provide accurate visibility of stock levels, leading to issues such as overstocking, stockouts, and inefficient replenishment processes. Having an accurate record of the stock within a store or other retail environment can present significant challenges with known equipment. Further, inventory distortion losses can be large and potentially up to 8% of total store sales. Despite many improvements and significant investments in the areas of supply chain optimisation and management, this loss is expected to run at around $2 trillion per year across all retail sectors. Even without stock losses, businesses often struggle to identify and optimise use of stock resource and retail staff time within the retail environment. For example, stock may be sold but not timely replenished, leading to gaps on shelves which can damage customer perception of the retail environment and potentially lead to lost or reduced sales. Sufficient stock may be present at the back of store (BOS) but without prompt and efficient replenishment of stock. It is known for retail environments to use visual technology such as aisle cameras to monitor stock. However, such technology is expensive and complex to install and operate. Therefore, there exists a technical problem that accurate real-time visibility of product items in a retail environment cannot easily be obtained with known arrangements and methods. The present invention aims, in embodiments, to address these issues. The following introduces a selection of concepts in a simplified form in order to provide a foundational understanding of some aspects of the present disclosure. The following is not an extensive overview of the disclosure and is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. The following merely summarises some of the concepts of the disclosure as a prelude to the more detailed description provided thereafter. Several preferred aspects of the methods and systems according to the present invention are outlined below. The present invention addresses the above challenges by providing a comprehensive retail environment inventory management system that utilises location-aware stock parameters to enhance stock monitoring, streamline replenishment processes, improve overall operational efficiency, and optimise on shelf product availability. According to a first aspect of the present invention there is provided a computer-implemented method for location-aware tracking of products in a retail environment comprising a sales floor and one or more storage areas, comprising: providing, at a computer server, an inventory of products in the retail environment, each product having an associated product type and a location marker associated with each product type, each location marker providing an indication of the number and location of all products of the same product type in the retail environment; receiving, at the computer server, delivery data specifying a product type and quantity of products forming part of one or more deliveries to the one or more storage areas as a function of time; receiving, at the computer server, sales data specifying the product type and quantity of products sold from the retail environment as a function of time; updating, at the computer server, the inventory of products based on the delivery receipt data and sales data; determining, using the computer server and based on the updated inventory, whether the number of products in one or more predefined display locations on the sales floor corresponds to a predetermined expected number of the products in the one or more predefined display locations; and if the determined number is lower than the expected number in one or more predefined display locations: generating an alert on one or more user terminals in communication with the computer server to replenish products in the one or more predefined display locations. In one embodiment, the one or more user terminals are handheld user terminals and each comprises a graphical user interface. In one embodiment, the step of generating an alert comprises generating one or more alert symbols on the graphical user interface of the one or more handheld user terminals. In one embodiment, the step of determining further comprises: utilising a planogram model representative of the spatial configuration of the display and storage locations for the retail environment to determine the expected number of products in the one or more predefined display locations. In one embodiment, the planogram model defines the maximum number of products of a given product type to be displayed in one or more predetermined display locations for that product type. In one embodiment, the expected number is a function of the maximum number. In one embodiment, the expected number comprises a threshold value below the maximum number. In one embodiment, wherein the step of generating the alert further comprises: generating a request to move one or more products of a product type from one or more storage areas to one or more predetermined display locations. In one embodiment, the step of generating a request further comprises: generating one or more further requests to move one or more products of a different product type from one or more storage areas to one or more predetermined display locations; and deriving a request list for product replenishment therefrom. In one embodiment, the method further comprises: updating the location marker for the one or more product types based on the requested movement of the products. In one embodiment, the alert specifies replenishment from a specific storage area selected from the group of one or more storage areas. In one embodiment, the inventory of products in the retail environment further comprises a time marker associated with one or more products, the time marker comprising a timedependent metric associated with the storage and / or sale of the respective product. In one embodiment, the time marker comprising a time-dependent metric associated with the time-criticality of parameters relating to the storage and / or sale of the respective product. In one embodiment, the time-dependent metric is associated with the age and / or expiry of the respective product. In one embodiment, the step of generating the alert further comprises: prioritising replenishment of products having the greatest time-criticality to the predefined display locations. In one embodiment, the sales data is received from one or more point-of-sales terminals located at the sales floor. In one embodiment, the sales data comprises online sales data. In one embodiment, the method further comprises: interrogating, using a user terminal, a product in the retail environment to generate an indication of the number and location of all products of the same product type. In one embodiment, the method further comprises: subsequent to the step of interrogating: generating an alert on one or more handheld user terminals to replenish additional units of the interrogated product. According to a second aspect of the present invention, there is provided a computer system for location-aware tracking of products in a retail environment, the computer system comprising: a server device and a plurality of user devices in communication with the server device, wherein the computer system is configured to carry out the method of the first aspect. In one embodiment, the user devices comprise handheld user devices. In one embodiment, the retail environment and connected to the handheld user devices via a communications network. According to a third aspect of the present invention, there is provided a non-transitory computer readable medium comprising instructions configured when executed to perform the method according to the first aspect. According to a fourth aspect of the present invention, there is provided a computer system comprising: a server device, a storage device and a computer readable medium of the third aspect. Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which: Figure 1 shows a schematic diagram of a retail environment comprising a sales floor and storeroom according to an embodiment; Figure 2 shows a schematic diagram of a control system according to an embodiment; Figure 3 shows the software module configuration of the control system shown in Figure 2 according to an embodiment; Figure 4a shows a screenshot of a graphical user interface (GUI) of a user terminal according to an embodiment; Figure 4b shows a screenshot of a graphical user interface (GUI) of a user terminal according to an embodiment; and Figure 5 shows a flow chart of a method according to an embodiment. Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numbers are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same. Various examples and embodiments of the present disclosure will now be described. The following description provides specific details for a thorough understanding and enabling description of these examples. One of ordinary skill in the relevant art will understand, however, that one or more embodiments described herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that one or more embodiments of the present disclosure can include other features and / or functions not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, so as to avoid unnecessarily obscuring the relevant description. Retail Environment Figure 1 a diagram of a retail environment 10. The retail environment 10 comprises a sales floor 12 having a plurality of aisles 14. The retail environment 10 further comprises a storeroom 16 for receipt of deliveries and for storage of stock for distribution onto the sales floor 12. The storeroom 16 may be one of a plurality of storage areas for storage of products as described below. The sales floor 12 comprises a plurality of display units 18. The display units 18 comprise aisle display units 18A which are arranged either side of the one or more aisles 14 of the sales floor 12 and comprise storage arrangements such as shelves, cabinets, drawers or similar arranged to store and present products to customers. The display units 18 further comprise endcap units 18B which are arranged at the end of one or more aisles 14 and display units 18A. It is common for promotional products to be placed on endcap units 18B due to their greater visibility and customer residence time. The sales floor 12 further comprises one or more point-of-sale (POS) terminals 20 which may be manned by retail staff or may be automated (unmanned) and which are operable to record the sale of one or more items of product purchased by a customer. The storeroom 16 comprises a plurality of storage units 22 configured to hold products. Products may be stored individually or collectively in pallets or other packages where groups of products are stored together. In embodiments, storage units 22 may be defined into specific zones or categories based on the temperature requirements of the stored products. In embodiments, the storage units 22 may be grouped into ambient, chilled and frozen storage zones or categories. Ambient storage may simply comprise a shelf or pallet storage. Chilled storage may comprise one or more fridge units and frozen storage may comprise one or more freezer units. In addition, stored product may be stored in one or more other storage areas. For example, stored product may be stored in specific areas on the sales floor 12 in a non-sale location such as on the top of shelving units. Such products are not marketed as for sale but can be conveniently used to replenish shelves or other product display areas below are adjacent. Product stored in these storage areas is known as “top stock”. Planogram model Within the retail environment 10, different locations can be defined. These may be a defined through the use of a planogram. A planogram is a schematic representation or model of the layout of the retail environment 10 indicating the spatial placement of retail products on shelves or storage units in aisle display units 18A, endcaps 18B or any other defined sales location. In embodiments, a planogram may outline the optimal arrangement of product items, and this information may be utilised by the inventory system to associate product items with specific locations or to ensure product items are placed in specific locations. The planogram defines location-specific information relation to zones or locations for particular product classes product types. This may be in the form of a general location and / or specific coordinate locations (e.g., aisle X, shelf Y). Alternatively or additionally, this information may comprise a specific zone as defined on the planogram and cross-correlated with the retail environment 10. This may comprise zones Z1, Z2 (Figure 1) specified on the planogram. A planogram may, in embodiments, take the form of a dynamic computer-implemented model of the spatial configuration of the retail environment 10. In embodiments, the planogram may be updated as required or periodically to account for stock changes, product line changes and / or seasonality of products. The planogram is accessible by the inventory control system described below. Products In the present disclosure “product” is intended to refer to any item that is stocked, offered for sale and / or sold within or by the retail environment 10. “Stock” may refer to stocked product(s) within any suitable region or zone of the retail environment 10. A product may be categorised in different ways. The broadest category of products may be to group the products by storage temperature and / or conditions. For example, products may be broadly categorised as ambient, chilled or frozen depending on their storage requirements. Products may also be defined by a particular classes; for example, fruit, vegetables, meat, condiments etc. In embodiments, products are grouped by product type. “Product type” in the present disclosure is intended to refer to a distinct type of product generally available for sale in the retail environment 10. A multiplicity of such products is usually stocked, offered for sale and / or sold within or by the retail environment 10. The definition of “product type” may comprise a stock keeping unit (SKU). For example, a product type may be a specific brand of condiment in a specific size. A barcode or other identifier may be associated with a specific product type or SKU but is not an explicit requirement. Products may also have additional data associated therewith. For example, an individual unit of product or a group of units of products (for example, a multipack or pallet of product) may have associated time-dependent data such as lifecycle dates. This may include, for example, “use by”, “sell by”, “best before” or any other suitable time-dependent metric associated with the storage and / or sale of the product or group of products. System Architecture An inventory control system 100 according to an embodiment is shown in Figure 2. The control system 100 comprises a server 102 and a plurality of user terminals 104 accessible to retail workers and operable to log retail data. The server 102 may comprise any suitable computer system operable to host the management software as described below. The server 102 comprises one or more hardware processors and is network connected and operable to communicate with any suitable server system. It may comprise a storage element 102a which may comprise any suitable local or networked storage. The server 102 and / or storage element 102a may be a local computer system or may be a remote networked compute and / or storage system. For example, the server 102 and / or storage element 102a may be in the form of an internet-connected cloud-based system. The user terminals 104 may take any suitable form and may comprise a bespoke application run on a smartphone or other handheld device or may comprise specialist handheld hardware for inventory management. In embodiments, the user terminals 104 may comprise a scanner or other device capable of interrogating stock items. Each user terminal 104 comprises a graphical user interface 106 (Figure 4a) to enable a retail worker to input data and receive information and alerts from the inventory control system 100. The server 102 hosts the inventory database and management software and is responsible for processing and analysing data from the user terminals 104. Figure 3 shows a schematic diagram of the software modules forming part of the inventory control system 100 and run on the server 102. The control system 100 comprises an inventory module 108 and a management platform 110. The inventory module 108 comprises a virtual replenishment manager 112, sales database element 114, storage database element 116 and a price optimisation module 118. The virtual replenishment manager 112 comprises an inventory management component that enables accurate inventory counts and tracking of products and product classes across both sales floor zones and locations and storeroom and other storage locations. The virtual replenishment manager 112 includes a robust database management system capable of efficiently storing and retrieving large volumes of inventory data. In embodiments, the virtual replenishment manager 112 utilises data input from the sales database element 114 and storage database element 116 to obtain real-time data on the inventory for all products within the retail environment 10. “Real-time” is defined on a timescale of typical shop processes. For example, POS terminals 20 may provide a continuous or substantially continuous data feed to the virtual replenishment manager 112 reflecting sales data. However, POS terminals 20 may, in embodiments, require a predetermined period of time to process sales transactions before providing data to the virtual replenishment manager 112. In specific embodiments, that time period may be of the order of 15 minutes. Further, in embodiments, delivery data may be received in advance or in the form of a manifest. However, there may be a time lag before the virtual replenishment manager 112 receives the updated data. Consequently, “real-time” is intended to refer to the data received from the various delivery and sales data feeds and represents the temporal evolution of the stock during a trading day on, in embodiments, a product-to-product basis. The temporal evolution of the stock is reflected in an update to the inventory of the virtual replenishment manager. As noted above, data streams from the various data sources may be received continuously and / or in real time. However, in embodiments, the data received from sales elements such as the point-of-sale the virtual replenishment manager 112 may only reflect the temporal evolution of the stock after a predetermined period of time whilst sales data is processed locally by the POS terminal 20. The sales database element 114 and storage database element 116 may take any suitable form and may take any suitable inputs. The data inputs received are described below in relation to the management platform 110 and may be received from client legacy applications 120 or any other sources. In embodiments, the management platform 110 may pre-process the data or reformat the data. Sales data for the sales database element 114 may be received from POS terminals 20 or any other suitable source. For example, in embodiments, online sales data may also be utilised. In embodiments, online sales may be processed in a similar manner to in-store sales with the exception that the picking of products are carried out by retail workers rather than customers. However, online sales may be processed through the POS terminals 20 and result in the same POS data being generated. Nevertheless, this is to be taken as non-limiting and sales data for online or other remote sales may be received in a different manner by the sales database element 114. For example, online orders may, in embodiments, be used as sales data directly to drive selection and replenishment independently of POS terminal 20 data. Online sales data is important in that online sales are generally (but not limited to) selected from the sales floor 12 rather than the storeroom 16 and so can be detrimental to inventory levels of the product displays in the sales floor area. The virtual replenishment manager 112 may comprise one or more database tables include fields for unique product identifiers, stock levels, location parameters, and historical transaction data showing stock throughput as a function of time. This data may be imported from one or more of the sales database element 114 and / or the storage database element 116. Seasonality may, in embodiments, be a further factor reflected in the transaction data showing fluctuating demand for particular products on a seasonal basis. Further, in embodiments, weather and / or environmental conditions may influence historical data reflected in the fluctuation in demand for specific products more likely to be purchased in particular environmental conditions. The virtual replenishment manager 112 may, in embodiments, utilise algorithms for real-time data analysis. In embodiments, the virtual replenishment manager 112 may utilise learning algorithms to optimally address the inventory and demand accuracy required for improved supply chain. For example, time-dependent data may be utilised to predict stock flows and drive replenishments. In embodiments, machine learning methodologies may involve one or more neural networks such as Artificial Neural Networks (ANNs) or convolutional neural networks (CNNs). Any machine learning elements may, in embodiments, comprise independent microservices addressable by the virtual replenishment manager 112. Further functions of the virtual replenishment manager 112 will be addressed later. However, functions such as comparing current stock levels to expected levels and generating alerts when necessary may be carried out by the virtual replenishment manager 112. The price optimisation module 118 is operable to process stock sale data and throughput data related to stock levels in order to track margin performance. This enables dynamic and responsive price changes to be made where a product is either overstocked or understocked. For example, the price optimisation module 118 may recommend overstock markdowns that accelerate sell-through, with minimum margin loss, to rebalance in-store supply with actual demand. Understock events triggers (where approved) mark-ups to increase margin in situations where demand exceeds supply. In addition, time-dependent data associated with products or group of products may be used to influence pricing. For example, if a significant volume of stock is close to a relevant product date (e.g. “use by” or “sell by” date) then the price optimisation module 118 could be used to drive appropriate markdowns to accelerate sell-through. In addition, if such stock resides in the storeroom, then the control system 100 is operable to ensure that this stock is picked and used to replenish display areas on the sales floor 12. The management platform 110 is operable to obtain data input streams from a plurality of input sources. In embodiments, the management platform 110 utilises extract, transform, load (ETL) execution to interface with the existing legacy applications 120 of the retail environment 10, databases and / or servers to obtain the required data elements from these applications 120. In embodiments, the management platform 110 is format and type agnostic and may engages with any suitable type of data or model. The management platform 110 enables implementation and any future repurposing of data sources to address future changes. In embodiments, the management platform 110 may comprise one or more enterprise-level Java microservices. In use, the management platform 110 is operable to read application data in the native format of the retail environments legacy software applications 120, adopt these data feed changes and provide a fully secured environment. Any data source or type may be used within the management platform 110, for example relation models, flat files, XML, and or spreadsheets. One of the advantages of the management platform 110 is that no data pre-processing is required and all data transformations are addressed within the management platform 110. A technical advantage of such a system is that the process is carried out within the management platform 110 and virtual replenishment manager 112 may be read in the native format by the user’s legacy applications. For example, even if within the management platform 110 and virtual replenishment manager 112 the inventory for a particular product or item is broken down by location such as sales floor zones and / or stockroom locations, the legacy applications 120 may still be provided with a single number representative of the total stock allocation for a particular product or item, ensuring compatibility. Data received from the legacy applications 120 may include, for example centrally sourced transactional data such as point-of-sale data relating to specific products, delivery data or other stock related information relevant to operation of the management platform 110. In embodiments, the data obtained by the management platform 110 may comprise delivery data received from legacy systems. Delivery data may be in the form of manifest data. Alternatively, delivery data may be generated through electronic scanning of products, SKUs and / or pallets received during the delivery. In embodiments, delivered products may be recorded by the storage database element 116 and utilised by the virtual replenishment manager 112. In other words, back of store or other storage areas (e.g. top stock), including the storeroom, are integrated into the control system 100. The user terminals 104 may be used to log and record stock into these areas, and the system enables monitoring of stock levels in real-time. In addition, in embodiments, point-of-sale data may be obtained by the management platform 110 either through legacy systems or directly from the point-of-sale (POS) systems 20. This data may in embodiments be utilised by the sales database element 114 and available for use by the virtual replenishment manager 112. Through use of the management platform 110 and virtual replenishment manager 112 forming part of the inventory module 108, real time inventory management and control can be achieved. This has the technical effect of enabling full closed-loop reconciliation and analysis of stock within the retail environment 10. This, in itself, can reduce stock losses and inefficiencies. However, through use of alert systems and targeted replenishment, additional technical effects can be achieved. This functionality will now be described. Location-aware inventory The ability of the inventory module 108 to obtain full closed-loop data relating to the retail environment 10 enables technical problems with product tracking and allocation to be solved. In embodiments, because delivery data and sales data are obtained and stored by the sales database element 114 and storage database element 116 for access by the virtual replenishment manager 112, this provides full accountability of the input and output of SKUs to and from the retail environment 10. It also enables classification products into product types or SKUs (and, optionally, product classes and / or categories) so that full inventories of products of the same type can be grouped to provide product-specific inventories which can be dynamically managed and utilised in real time. In other words, the accurate recordal of retail environment 10 input, output and throughput of stock enables location-aware identification of SKUs and stock more generally. In this regard, each product type / SKU is allocated a location marker. The location marker comprises a data field associated with each product type, the location marker providing an indication of the number and location of all products of the same product type / SKU in the retail environment. The location marker field may be updated each time individual products of a single product type / SKU are moved within the retail environment 10. For example, a delivery manifest may be processed to identify that 100 packets of a particular product have been received in a delivery. Initially, delivery data related to these products is recorded by the storage database element 116 logs the products as received and stored in the storeroom 16. This data is then used by the virtual replenishment manager 112. These products may be logged in numerous ways. Delivery data may be in the form of manifest data. Manifest data may specify individual SKU numbers or may specify a larger unit of stock - for example, a pallet. A pallet may be logged as received and the inventory updated with the number of SKUs in a pallet - for example, 50. In which case, two pallets have been received in this example. Manifest data may, in embodiments, be received and utilised by the virtual replenishment manager 112 in advance of the delivery taking place. This may enable replenishment using existing stock of a particular product type before additional stock arrives in the delivery. This time-dependent replenishment has significant benefits and is described in more detail below. Alternatively or additionally, delivery data may be generated through electronic scanning and / or other direct recording of products, SKUs and / or pallets received during the delivery. In embodiments, delivered products may be recorded by the storage database element 116 and utilised by the virtual replenishment manager 112. For example, manifest or other delivery data may be used to specify stock of product type(s) and quantity in the storeroom 16 within the virtual replenishment manager 112 (via the storage database element 116) in advance of the delivery and / or after the delivery has taken place. Electronic scanning or other recording of the delivered products can then optionally be performed to confirm the delivery details or provide an updated storeroom inventory to update the delivery details accurately. Initially, after delivery (and optionally confirmation recording / scanning), the location marker will specify that all of the products of a particular product type received in a delivery are located in the storeroom 16. In embodiments, more granular location data may be entered and particular shelves 22 or other storage locations within the storeroom 16 or sales floor 12 (e.g. top stock) may be specified in the location marker. In embodiments, the planogram for the retail environment 10 will comprise an area or zone for display of the type and class of SKU which has been delivered. The virtual replenishment manager 112 utilises the planogram configuration and data to determine how many products of a particular product type / SKU should be stored in each relevant zone / area of the sales floor 12. If SKUs are placed in these zones on the sales floor 12 for sale then the inventory will be updated to reflect this change. Consequently, the location marker for the type of product to which the individual product relates will reflect the number of products of that product type / SKU which have been moved from the storeroom 16 to the sales floor 12. If, for example, 50 products of a particular product type / SKU have been moved, this will be entered by a retail worker using a user terminal 104 into the relevant data field for the product type / SKU to update the sales database element 114 which will then specify 50 products of that product type in the storeroom 16 and 50 SKUs at the relevant planogram-specified zone and / or aisle / end cap on the sales floor 12. In some instances, products of a single product type may be distributed at more than one location or zone on the sales floor 12. In embodiments, both aisles and endcaps may be categorised in the system, allowing for precise tracking of products within these areas. Location parameters are assigned to each product, indicating the expected stock levels for these specific locations. When products are sold, they are logged by the point-of-sales terminals 20 and the sales recorded in the sales database element 114. Given it is known that sold stock products will have been picked from the aisles and / or end caps of the sales floor 12, the number of products on the sales floor 12 can then be reduced by the number sold. This provides an estimate of the stock remaining on the sales floor 12. Without specific product location tracking (e.g. camera or RFID tag) it is not possible to know automatically whether a sold product which is displayed in more than one area on the sales floor 12 has been removed from a particular zone or area (e.g. an endcap or an aisle). In embodiments, this may be inferred or estimated, e.g. through statistical analysis by estimating a proportion of stock which is likely to be sold from each zone or area, or by applying a weighting to particular zones to simulate higher footfall and / or more attractive retail zones which may stimulate enhanced purchase from particular zones. Time-aware inventory In optional embodiments, the products may also have additional data associated therewith. For example, an individual product of a product type or a group of products (for example, a multipack or pallet of products) may have associated time-dependent data such as lifecycle dates. This may include, for example, “use by”, “sell by”, “best before” or any other suitable time-dependent metric associated with the storage and / or sale of the product or group of products. This data can be utilised by the virtual replenishment manager 112 to enable first in first out (FIFO) rules for stock to be followed and for stock having the shortest life cycle to be displayed and / or sold first. This is a significant technical problem in the conventional art and one that cannot be addressed with conventional arrangements in this field. Optionally, the time-dependent data may be utilised by the virtual replenishment manager 112 to generate pick lists or other alerts to enable particular stock from particular regions 22 of the storeroom 16 having the earliest expiry or sell by dates to be moved to the sales floor 12 or placed in particular prominent zones Z1, Z2 of the sales floor 16. Additionally or alternatively, time-dependent data may be utilised to characterise pick lists in order of time-critical priority or vary the alert type based on criticality. This may be particularly important for perishable products. In addition, in embodiments, the time-dependent data may be used in connection with pricing markdowns to ensure prompt sale of stock. However, this is not the only scenario in which time-dependent structuring of stock replenishment may be utilised. For example, where stock is stored in different areas, a common technical problem is that stock having different time-dependent data is not used appropriately. An example may be a situation where products of the same product type / SKU are stored in different locations such as in the storeroom 16 and as top stock on the sales floor 12. Replenishment can be driven based on the relevant time-dependent data to ensure that the most time-critical stock is displayed and sold first. This is in contrast to existing systems where convenient stock such as top stock may be used to replenish the sales floor 12 locations first although there may be more time-critical stock in a less convenient location such as the storeroom 16. User terminals and functionality Figure 4a shows a graphical user interface (GUI) 106 of a user terminal 104. Figure 4b shows a view of a product query showing the location marker for a given SKU type and class. A user terminal may comprise any suitable computer system having a GU1106. In embodiments, the user terminals 104 comprise handheld user terminals 104. In Figure 4a, a plurality of icons is shown. In use, retail workers access the graphical user interface 106 to view real-time stock levels, location parameters, and alerts. In embodiments, the interface provides a customisable dashboard for displaying stock levels, location parameters, and alerts. The technical functionality of these elements will be described below in detail. Pick and replenishment In use, the user terminals 104 can be used to trigger replenishment activities through utilisation of the virtual replenishment manager 112 and control system 100. In use, the virtual replenishment manager 112 generates a replenishment task specifying the products to be restocked and their respective locations. This task is assigned to a retail worker through alerts provided to the user devices 106. As shown in Figure 4a, the control system 100 can generate alerts to trigger replenishment or other stock movement actions in response to received delivery and / or sales data and consequently the updated real-time inventory data. The virtual replenishment manager 112 may generate an alert in response to particular criteria. For example, if sales of a particular SKU have caused stock of the SKU in the sales floor 12 to drop below a particular threshold, then a replenishment action may be triggered. The virtual replenishment manager 112 receives delivery and sales data feeds, and also has a dynamic inventory relating to the number of items of a particular SKU in the retail environment 10. In addition, the virtual replenishment manager 112 is operable to utilise the planogram model to identify where products corresponding to a particular product type / SKU are located. With this information, an action item to replenish particular product display zones or areas within the retail environment 10 can be generated. The action item may be in the form of an entry in a pick list for a retail worker to select products from the storeroom 16 and replenish the relevant zone(s) of the sales floor 12. Alternatively or additionally, the action item may generate an alert on one or more user terminals 104. The alert is in the form of a graphical alert on the graphical user interface 106 and may comprise a suitable graphical symbol. The symbol may be selected in dependence upon the urgency and / or priority of the task and may comprise, for example, a star or a warning triangle, depending upon the urgency of the task. In addition or alternatively, haptic or sound alerts may be used to draw a retail worker’s attention to the task that is required to be performed. If multiple items are added to a pick list, in embodiments they may be ordered according to specific priorities. For example, high priority products may be fast selling stock or stock which is likely to sell out quickly due to few remaining products on the shelves. Threshold levels may be set before alerts are triggered. For example, when a particular percentage of products of a given product type or SKU or a specific number of products of the product type / SKU in a particular zone drop below a predetermined threshold of display stock, an alert could be triggered. The threshold(s) may, in embodiments, constitute an expected level of stock in particular zones of the sales floor 12. The virtual replenishment manager 112 may utilise the planogram model in determining expected stock levels and / or thresholds as a function of sales floor 12 location. In embodiments, the planogram for the retail environment 10 will comprise an area or zone for display of products of a particular product type or SKU which has been delivered. The planogram may specify how many products of a particular product type or SKU are expected to be stored in a particular area or zone. In embodiments, the virtual replenishment manager 112 utilises the planogram configuration and data to determine how many products of a particular product type / SKU should be stored in each relevant zone / area of the sales floor 12. If products are placed in these zones on the sales floor 12 for sale then the inventory will be updated to reflect this change. This may be done by one or more retail workers through the user devices 104. As discussed above, the expected number of products in these locations may, in embodiments, be determined by the planogram. Alternatively or additionally, in embodiments, the expected number of products may be based on another factor or be a function of the number specified on the planogram. For example, consider a planogram model which specifies a particular number of products (for example 100) to be displayed in one or more predefined locations. However, in embodiments, the expected number may be a function of the particular number specified in the planogram. For example, the expected number of products may be 80 below which replenishment is triggered. This may be more efficient in terms of stock and retail worker resource. The threshold at which replenishment is triggered may be specified to allow for time lags in sales and replenishment. For example, there will be a particular time lag from receiving data relating to a sale and the replenishment activity taking place. There may also be other time lags involved with stock replenishment. For example, for fast selling and / or popular products, the time during which a customer has a product in their basket or trolley before making a purchase may be a significant factor. In such a situation, products of stock are no longer available in the display areas of the sales floor 12 but these sales have not yet been recorded so the virtual replenishment manager 112 is not aware of the lack of stock availability. In this situation, thresholds or expected numbers may be set to be a higher proportion of the maximum number of products in any one zone or display area so that replenishment is triggered at an earlier stage the ensure stock depletion does not reach a critically low level. In this manner, the technical problem of active and efficient replenishment of stock can be achieved without the need for expensive and complex direct monitoring systems such as cameras or RFID tags. By monitoring throughput of stock, the control system 100 can determine replenishment actions and drive efficient operation of the retail environment 100. In embodiments, the method and system of the present invention enables the control system 100 to continuously monitor stock levels in each designated location of the sales floor 12. Real-time stock levels can be compared to the expected levels specified by the location parameters (e.g. on the planogram) and, if stock levels in specific zones or locations fall below the expected threshold on the sales floor 12, an alert can be generated to drive replenishment. Item inquiry In use, the user terminals 104 can be used to interrogate the inventory and control system 100. As shown in Figure 4a, a user (for example, a retail worker) can select the “item inquiry” module of the user terminal 104. The user can then input an identifier representative of a particular product either manually (by entering a product reference number) or automatically (by scanning a product using the user terminal 104) and search for level of stock of that product. The interrogation will generate a report for the entire stock of that product type in the inventory. This may comprise a list of the total number of products for that product type / SKU in the retail environment 10 together with the numbers of products of that product type / SKU in each location in the retail environment 10. In other words, the location marker for a particular product type / SKU can be used to identify all products of a particular product type in one or more product display locations and / or one or more storage areas. Gap check In use, the user terminals 104 can be used to trigger replenishment activities through utilisation of the inventory and control system 100. As shown in Figure 4a, a user (for example, a retail worker) can select the “gap check” module of the user terminal 104. A retail worker may be scanning the sales floor 12 for low stock and / or out of stock products. Low stock products are undesirable for retailers because they potentially limit the sales of that product if all products are sold without replenishment. In addition, they also present a negative appearance for the customer. In embodiments, a retail worker may scan or select a product of a product type (i.e. a SKU) that is low in stock on the sales floor 12. The gap check module then generates an action item across one or more user terminals 104. The action item may be in the form of an entry in a pick list. The retail worker may then select other items and build a pick list for retail workers to complete at a specific time. In addition, the action item may generate an alert on one or more user terminals 104. The alert is in the form of a graphical user interface alert and may comprise a star or a warning triangle, depending upon the urgency of the task. In addition, haptic or sound alerts may be used. If multiple items are added to a pick list, in embodiments they may be ordered according to specific priorities. For example, high priority items may be fast selling stock or stock which is likely to sell out quickly due to few remaining items on the shelves. In general, any item identified on a gap check will be a high priority item due to a low stock situation. If multiple retail workers create multiple pick lists, duplicated items can be removed to ensure overstocking does not occur. Once the task is complete and the items on the pick list(s) have been replenished, the pick list can be marked as complete. METHOD The following method relates to the steps occurring during operation of the method of realtime location-aware tracking of products in a retail environment. Figure 5 shows a flow chart of the method according to an embodiment. It is noted that whilst the above steps are described sequentially, this is not essential and certain steps may be performed in a different order or performed concurrently without departing from the present invention. Step 200: Provide inventory At step 200, the inventory is provided. The inventory comprises an inventory of products in the retail environment, each product having an associated product type and a location marker associated with each product type. The location marker provides an indication of the number and location of all products of the same product type in the retail environment. In embodiments, the location marker comprises a data field associated with the product type / SKU to which the product belongs, the location marker providing an indication of the number and location of all products of the same product type in the retail environment. In embodiments, the location marker field may be updated each time products are moved within the retail environment 10 as described in later steps. Initially, after delivery (and optionally confirmation recording / scanning), the location marker will specify that all of the products of a particular product type received in a delivery are located in the storeroom 16. In embodiments, more granular location data may be entered and particular shelves 22 or other storage locations within the storeroom 16 or sales floor 12 (e.g. top stock) may be specified in the location marker. In embodiments, the inventory is provided by the virtual replenishment manager 112 which comprises an inventory management component that enables accurate inventory counts and tracking of products and product classes across both sales floor zones and locations and storeroom locations. The virtual replenishment manager 112 includes a robust database management system capable of efficiently storing and retrieving large volumes of inventory data. In addition, the virtual replenishment manager 112 can access the planogram model of the retail environment 10 to identify where, and in what quantities, particular items of one or more product types / SKUs can be located and are located. Step 202: Obtain delivery data At step 202, receipt data is received by the control system 100 specifying a product type and quantity of one or more products received in the storeroom 16. In embodiments, the delivery data may be obtained by the management platform 110 and may comprise delivery data received from legacy systems and / or data in the form of manifest data. Alternatively, delivery data may be generated through electronic scanning of products, product types / SKUs and / or pallets received during the delivery. In embodiments, delivered products may be recorded by the storage database element 116 and utilised by the virtual replenishment manager 112. In more detail, the delivery data related to these products is recorded by the storage database element 116 which logs the products as received and stored in the storeroom 16. This data is then used by the virtual replenishment manager 112. These products may be logged in numerous ways. Delivery data may be in the form of manifest data. Manifest data may specify individual SKU numbers or may specify a larger unit of stock - for example, a pallet. Manifest data may, in embodiments, be received and utilised by the virtual replenishment manager 112 in advance of the delivery taking place. This may enable replenishment using existing stock of a particular product type before additional stock arrives in the delivery. This time-dependent replenishment has significant benefits and is described in more detail below. Alternatively or additionally, delivery data may be generated through electronic scanning and / or other direct recording of products, SKUs and / or pallets received during the delivery. In embodiments, delivered products may be recorded by the storage database element 116 and utilised by the virtual replenishment manager 112. For example, manifest or other delivery data may be used to specify stock of product type(s) and quantity in the storeroom 16 within the virtual replenishment manager 112 (via the storage database element 116) in advance of the delivery and / or after the delivery has taken place. Electronic scanning or other recording of the delivered products can then optionally be performed to confirm the delivery details or provide an updated storeroom inventory to update the delivery details accurately. Step 204: Obtain sales data At step 204, sales data is received by the control system 100 specifying a product class, type and quantity of one or more products sold at one or more point-of-sales terminals located at the sales floor. In embodiments, point-of-sale data may be obtained by the management platform 110 either through legacy systems or directly from the point-of-sale systems 20. This data may in embodiments be utilised by the sales database element 114 and available for use by the virtual replenishment manager 112. Sales data for the sales database element 114 may be received from POS terminals 20 or any other suitable source. For example, in embodiments, online sales data may also be utilised. In embodiments, online sales may be processed in a similar manner to in-store sales with the exception that the picking of products are carried out by retail workers rather than customers. However, online sales may be processed through the POS terminals 20 and result in the same POS data being generated. Nevertheless, this is to be taken as non-limiting and sales data for online or other remote sales may be received in a different manner by the sales database element 114. For example, online orders may, in embodiments, be used as sales data directly to drive selection and replenishment independently of POS terminal 20 data. Step 206: Update inventory At step 206, the inventory of products is updated based on the receipt data and sales data. In embodiments, through use of the management platform 110 and virtual replenishment manager 112 forming part of the inventory module 108, real time inventory management and control can be achieved. This has the technical effect of enabling full closed-loop reconciliation and analysis of stock within the retail environment 10. Step 208: Determine replenishment criteria At step 208, based on the updated inventory in step 204, it is determined whether the number of products in one or more predefined locations corresponds to an expected number of said products in the one or more predefined locations. Threshold levels may be set before alerts are triggered. For example, when a particular percentage of products of a given product type or SKU or a specific number of products of the product type / SKU in a particular zone drop below a predetermined threshold of display stock, an alert could be triggered. The threshold(s) may, in embodiments, constitute an expected level of stock in particular zones of the sales floor 12. The virtual replenishment manager 112 may utilise one or more planograms in determining expected stock levels and / or thresholds as a function of sales floor 12 location. In embodiments, the planogram for the retail environment 10 will comprise an area or zone for display of products of a particular product type or SKU which has been delivered. The planogram may specify how many products of a particular product type or SKU are expected to be stored in a particular area or zone. In embodiments, the virtual replenishment manager 112 utilises the planogram configuration and data to determine how many products of a particular product type / SKU should be stored in each relevant zone / area of the sales floor 12. If products are placed in these zones on the sales floor 12 for sale then the inventory will be updated to reflect this change. This may be done by one or more retail workers through the user devices 104. As discussed above, the expected number of products in these locations may, in embodiments, be determined by the planogram. Alternatively or additionally, in embodiments, the expected number of products may be based on another factor or be a function of the number specified on the planogram. For example, consider a planogram which specifies a particular number of products (for example 100) to be displayed in one or more predefined locations. However, in embodiments, the expected number may be a function of the particular number specified in the planogram. For example, the expected number of products may be 80 below which replenishment is triggered. This may be more efficient in terms of stock and retail worker resource. The threshold at which replenishment is triggered may be specified to allow for time lags in sales and replenishment. For example, there will be a particular time lag from receiving data relating to a sale and the replenishment activity taking place. There may also be other time lags involved with stock replenishment. For example, for fast selling and / or popular products, the time during which a customer has a product in their basket or trolley before making a purchase may be a significant factor. In such a situation, products of stock are no longer available in the display areas of the sales floor 12 but these sales have not yet been recorded so the virtual replenishment manager 112 is not aware of the lack of stock availability. In this situation, thresholds or expected numbers may be set to be a higher proportion of the maximum number of products in any one zone or display area so that replenishment is triggered at an earlier stage the ensure stock depletion does not reach a critically low level, function of the particular number to allow for time lags in sales and replenishment. For example, the expected number of products may be 80 below which replenishment is triggered. By monitoring throughput of stock, the control system 100 can determine replenishment actions and drive efficient operation of the retail environment 100. In embodiments, the method and system of the present invention enables the control system 100 to continuously monitor stock levels in each designated location of the sales floor 12. Real-time stock levels can be compared to the expected levels specified by the location parameters (e.g. on the planogram) and, if stock levels in specific zones or locations fall below the expected threshold on the sales floor 12, an alert can be generated to drive replenishment. Step 210: Generate alert If, at step 208 it is determined that the determined number is lower than the expected number in one or more predefined locations, then an alert is generated on one or more handheld user terminals to replenish products in the one or more predefined locations. In use, the virtual replenishment manager 112 generates a replenishment task specifying the products to be restocked and their respective locations. This task is assigned to a retail worker through alerts provided to the user devices 106. In embodiments, the control system 100 can generate alerts to trigger replenishment or other stock movement actions in response to received delivery and / or sales data and consequently the updated real-time inventory data. The alert is in the form of a graphical user interface alert and may comprise a star or a warning triangle, depending upon the urgency of the task. In addition or alternatively, haptic or sound alerts may be used. The alert may also comprise a pick list of items that require replenishment. The virtual replenishment manager 112 receives delivery and sales data feeds, and also has a dynamic inventory relating to the number of items of a particular SKU in the retail environment 10. Further, the virtual replenishment manager 112 is operable to utilise the planogram model to identify where products corresponding to a particular product type / SKU are located. With this information, an action item to replenish particular product display zones or areas within the retail environment 10 can be generated. The action item may be in the form of an entry in a pick list for a retail worker to select products from the storeroom 16 and replenish the relevant zone(s) of the sales floor 12. The present invention has numerous advantages over known solutions. Real-Time Visibility: The invention provides real-time visibility into stock levels on the sales floor which factors in the unique configuration of aisles, endcaps, and planograms and without requiring expensive monitoring hardware. Efficient Replenishment: The automated replenishment workflow, tailored to the configuration of the retail environment 10, ensures that retail workers are proactively alerted to replenish stock, reducing manual monitoring efforts and improving overall efficiency of the workforce and of the retail environment 10 as a whole. Optimised Inventory Control: By associating products with specific locations and considering the unique layout of the retail environment, the system optimises inventory control, reducing overstocking and preventing stockouts. Automation of delivery and sales data: Manifests and / or scanners may be used to log products into the database system upon delivery. In addition, the system integrates with point-of-sale terminals, updating the inventory database in real-time upon completing sales transactions. The methods described herein may be embodied in one or more pieces of software. The software is preferably held or otherwise encoded upon a memory device such as, but not limited to, any one or more of a hard disk drive, RAM, ROM, solid state memory or other suitable memory device or component configured to software. The methods may be realised by executing / running the software. Additionally or alternatively, the methods may be hardware encoded. The method encoded in software or hardware is preferably executed using one or more processors. The memory and / or hardware and / or processors are preferably comprised as, at least part of, one or more servers and / or other suitable computing systems. In this specification, unless expressly otherwise indicated, the word "or" is used in the sense of an operator that returns a true value when either or both of the stated conditions are met, as opposed to the operator "exclusive or" which requires only that one of the conditions is met. The word "comprising" is used in the sense of "including" rather than to mean "consisting of". All prior teachings above are hereby incorporated herein by reference. No acknowledgement of any prior published document herein should be taken to be an admission or representation that the teaching thereof was common general knowledge in Australia or elsewhere at the date thereof. Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and / or software components set forth herein may be combined into composite components comprising software, hardware, and / or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and / or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa. Software, in accordance with the present disclosure, such as program code and / or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and / or separated into sub-steps to provide features described herein. 5 While various operations have been described herein in terms of “modules”, “units” or “components,” it is noted that that terms are not limited to single units or functions. Moreover, functionality attributed to some of the modules or components described herein may be combined and attributed to fewer modules or components. to Further, whilst the present invention has been described with reference to specific embodiments and examples, those examples are intended to be illustrative only, and are not intended to limit the invention. It will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing 15 from the scope of the invention.

Claims

1. A computer-implemented method for location-aware tracking of products in a retail environment comprising a sales floor and one or more storage areas, comprising:providing, at a computer server, an inventory of products in the retail environment, each product having an associated product type and a location marker associated with each product type, each location marker providing an indication of the number and location of all products of the same product type in the retail environment;receiving, at the computer server, delivery data specifying a product type and quantity of products forming part of one or more deliveries to the one or more storage areas as a function of time;receiving, at the computer server, sales data specifying the product type and quantity of products sold from the retail environment as a function of time;updating, at the computer server, the inventory of products based on the delivery receipt data and sales data;determining, using the computer server and based on the updated inventory, whether the number of products in one or more predefined display locations on the sales floor corresponds to a predetermined expected number of the products in the one or more predefined display locations; andif the determined number is lower than the expected number in one or more predefined display locations:generating an alert on one or more user terminals in communication with the computer server to replenish products in the one or more predefined display locations.

2. A computer-implemented method according to claim 1, wherein the one or more user terminals are handheld user terminals, each user terminal comprising a graphical user interface.

3. A computer-implemented method according to claim 2, wherein the step of generating an alert comprises generating one or more alert symbols on the graphical user interface of the one or more handheld user terminals.

4. A computer-implemented method according to any one of claims 1,2 or 3, wherein the step of determining further comprises:utilising a planogram model representative of the spatial configuration of the display and storage locations for the retail environment to determine the expected number of products in the one or more predefined display locations.

5. A computer-implemented method according to claim 4, wherein the planogram model defines the maximum number of products of a given product type to be displayed in one or more predetermined display locations for that product type.

6. A computer-implemented method according to claim 5, wherein the expected number is a function of the maximum number.

7. A computer-implemented method according to claim 6, wherein the expected number comprises a threshold value below the maximum number.

8. A computer-implemented method according to any one of the preceding claims, wherein the step of generating the alert further comprises:generating a request to move one or more products of a product type from one or more storage areas to one or more predetermined display locations.

9. A computer-implemented method according to claim 8, wherein the step of generating a request further comprises:generating one or more further requests to move one or more products of one or more different product types from one or more storage areas to one or more predetermined display locations; andderiving a request list for product replenishment therefrom.

10. A computer-implemented method according to claim 8 or 9, wherein the method further comprises:updating the location marker for the one or more product types based on the requested movement of the products.

11. A computer-implemented method according to any one of the preceding claims, wherein the alert specifies replenishment from a specific storage area selected from the group of one or more storage areas.

12. A computer-implemented method according to any one of the preceding claims, wherein the inventory of products in the retail environment further comprises a time marker associated with one or more products, the time marker comprising a time-dependent metric associated with the storage and / or sale of the respective product.

13. A computer-implemented method according to claim 12, wherein the time marker comprising a time-dependent metric associated with the time-criticality of parameters relating to the storage and / or sale of the respective product.

14. A computer-implemented method according to claim 12 or 13, wherein the timedependent metric is associated with the age and / or expiry of the respective product.

15. A computer-implemented method according to claim 12,13 or 14, wherein the step of generating the alert further comprises:prioritising replenishment of products having the greatest time-criticality to the predefined display locations.

16. A computer-implemented method according to any one of the preceding claims, wherein the sales data is received from one or more point-of-sales terminals located at the sales floor.

17. A computer-implemented method according to any one of the preceding claims, wherein the sales data comprises online sales data.

18. A computer-implemented method according to any one of the preceding claims, further comprising:interrogating, using a user terminal, a product in the retail environment to generate an indication of the number and location of all products of the same product type.

19. A computer-implemented method according to claim 18, further comprising, subsequent to the step of interrogating:generating an alert on one or more handheld user terminals to replenish additional units of the interrogated product.

20. A computer system for location-aware tracking of products in a retail environment, the computer system comprising: a server device and a plurality of user devices in communication with the server device, wherein the computer system is configured to carry out the method of any one of the preceding claims.

21. A computer system according to claim 20, wherein the user devices comprise handheld user devices.

22. A computer system according to claim 21, wherein the server device is remote from the retail environment and connected to the handheld user devices via a communications network.

23. A non-transitory computer readable medium comprising instructions configured when executed to perform the method as claimed in any one of claims 1 to 19.

24. A computer system comprising: a server device, a storage device and a computer readable medium as claimed in claim 23.