GB2425921A - Retail management system for use with a mobile communication device - Google Patents

Abstract

A retail management system is provided for interaction with mobile user interface apparatus in a retail environment. The apparatus supports the detection of arrival of a registered device in the environment and subsequent download of code and data to the device to enable location-based and personalised services. Routing information to direct the user to specified goods or services can be provided by the system, this being tailored to a user's current store position. Thus an embodiment of the invention can send personalised information to users as they shop, the personalised information being tailored to the user's actual position in the store.

Description

APPARATUS FOR LOCATION-BASED INFORMATION DELIVERY

The present invention relates to apparatus for location-based information delivery. It finds particular, but not exclusive, application in supporting communication between a retail data management system and a user device to provide in-store information and/or navigation.

Copending International patent application PCT/GB2004/001626 in the name TAGBOARD LTD, published as W02004/0908 19, describes a payment system in which a mobile telephone can be used as an interface to trigger payment from one or more user accounts. The system includes personalisation by use of user profiles and can support for instance loyalty incentives such as discounts for users, dependent on their purchasing history.

However, the system described in W02004/090819 comes into play as the user finishes shopping and exits the store.

Copending British patent application GB0509061.8 in the name TAGBOARD LTD describes a payment system in which a user can assemble a shopping list on their mobile telephone which is then read into the payment system as a goods list at the checkout till.

The goods list is read by using a near field communications link from a transponder mounted on the telephone. This means that the user can assemble a shopping list in advance and re-use past shopping lists. Additionally, bar codes and the like on individual items no longer have to be read by a portable scanner or at the checkout till.

It is known to use Bluetooth enabled transmitters to send local information to shoppers in- store. The transmitters take advantage of the short range of Bluetooth connections so that a Bluetooth enabled mobile device will receive information about products and promotions on shelves near them in the store. However, communication is limited, non- user specific and unidirectional. The transmitters simply send the same information to all shoppers.

According to a first aspect of embodiments of the present invention, there is provided a retail information management system, the system comprising: i) a detector for detecting arrival of a mobile communications device in a retail environment; ii) a delivery system for delivering software code to a detected device; and iii) an information storage and transmission system for sending information in respect of the retail environment to the detected device for reception by the delivered software code, whereby the detected device is enabled to provide information to a user in respect of the retail environment.

Information in respect of the retail environment might comprise data concerning the layout of the store, goods or services provided in the environment or at other locations, either internal or external, in relation to the environment.

Preferably in embodiments of the invention, the information storage and transmission system is adapted to store user profiles for use in personalizing information provided to the user. Whether or not it stores user profiles, it may be adapted to store routing data in respect of the retail environment for use in providing routing information to the user. Thus embodiments of the invention can enable the delivery of personalised, location-specific information, such as a selection of nearby special offers that the user will have an interest in, or non-personalised routing information from the location of the user to an in-store destination. Indeed, routing information could include out of store destinations such as the nearest automatic telling machine ("ATM") or taxi rank.

Preferably in embodiments of the invention, the routing data is selectable according to one or more identifiers for goods, services or access points in or to the environment, such that routing information provided to the user includes location data for selected goods andlor services and/or access points. This supports a "Take me there" style of service in which promotional information in relation to goods or services can be displayed on a device when present in the retail environment and the user can request routing information to the goods or services potentially by one key stroke or other simple input.

Optionally, the detector might be present on the device itself, working for example by receiving a signal within the retail environment that it is adapted to recognize, for example by Bluetooth or telephony communication, or the detector might be present as a function of the information storage and transmission system. In the latter case, the detector will be adapted to recognize a signal received from the device. In either case, the detector may be adapted to provide an alert signal to the information storage and transmission system on detecting arrival of the device in the retail environment.

Preferably in embodiments of the invention, the detector can detect a change in location of the mobile communications device in the retail environment. This might be for example because it detects a change in cell identity in a cellular network, or because it detects a change in Bluetooth transmitter identity, or because it detects a change in received signal strength in relation to at least one Bluetooth transmitter identity. The detection of a change in location allows the system to provide real-time routing information to a user via the device which can be sufficiently detailed to correct movements in the wrong direction with respect to a previously selected target location.

Preferably, embodiments of the system further comprise a service selector, triggerable on detection of arrival of the device in the retail environment to offer the user selection between at least two different levels of service, at least one of the two levels of service being personalized. This allows the user to decide on any one occasion whether they wish to receive a personalised service. Even where the user decides against personalisation, the system is still able to offer at least one non-personalised option, this being routing.

Preferably in embodiments of the invention, the system is capable of checking the status of software code andlor data already present on the device against the status of software code and/or data available for delivery by the delivery system and updating the software code and/or data present on the device in accordance with the result of the status check.

This means that a device that already has code and/or data loaded can be maintained up to date for every visit to a retail environment covered by the service.

It is convenient if the system of an embodiment of the invention further comprises an interface for obtaining data from a data store in addition to the information storage and transmission system. This can be used to maintain data within the system from an external retail database, for instance independently maintained for the purpose of managing the retail environment. It also gives a relatively simple mechanism by means of which embodiments of the invention can be tailored to a particular retail environment although the same general and familiar functionality may be available in many different retail environments. It also supports provision of branding Because information can be downloaded on entry to a retail environment, the user may receive the same functionality in several different retail environments, and can expect to be offered the same general services such as use of a shopping list as described in British patent application GB0509061.8 and delivery of personalised information including loyalty-based discounts, but the information content may be specific to each of the different retail environments. Thus the user might be entitled to different discounts in different retail environments or each different environment might be running different promotions, or indeed sell different goods.

Alternatively, different retail environments might offer a different selection or form of services and this will be reflected in the software code delivered to the user's mobile communications device after it has been detected in-store.

An additional advantage of delivering software code to a device each time it is detected in- store is that the device will always receive updates and changes at the time when they are particularly relevant.

According to a second aspect of embodiments of the invention, there is provided a mobile communications device adapted for use with a system as described above. For example, such a device might itself carry the detector and/or routing data to support provision of routing information to the user.

Preferably, a mobile communications device according to an embodiment of the invention also provides a shopping list management facility for managing or constructing a shopping list. A shopping list in this context is usually a list of goods (or IDs for goods) for which there arc associated prices to which the retail information management system has access.

For example, a shopping list might be stored in advance of a shopping trip by the user on their mobile communications device, or it might be constructed as the user goes round a retail environment. If done in advance, shopping list construction can be done for example by use of the keypad or touch screen of the communications device, or by use of a personal computer.

As mentioned above, to support personalized services, the information storage and transmission system of embodiments of the invention in its first aspect will have access to a profile data store for storing data profiles against user identifiers. Preferably, at least one data profile is adapted to store at least one set of till roll data. Till roll data in this context might be for example equivalent to a shopping list in which all goods in the list have been at least selected for, or have been subject to, a purchasing transaction. This can conveniently interact with the shopping list management facility on a mobile communications device to convert a shopping list to till roll data and vice versa.

Embodiments of the present invention are particularly suitable for use with a point of sale transaction system such as that described in W02004/0908 19, referred to above. They are also suitable for use with the payment system described in British patent application GB0509061.8 in which a user can assemble a shopping list on their mobile telephone which is then read into the payment system as a goods list at the checkout till. However, embodiments of the present invention mean that near field communications devices are no longer required, being replaced by Bluetooth or telephony or IP-based communications.

It might be noted that individual features described herein in relation to one embodiment may be capable of use in another embodiment of the invention and thus an embodiment of the invention might comprise any combination of features described.

A retail information management system will now be described as an embodiment of the present invention, by way of example only, with reference to the accompanying figures in which: Figure 1 shows a functional block diagram of the system and indicates schematically mobile device detection occurring at start up of the system, using a picocell; Figure 2 shows a functional block diagram of the system and indicates schematically an array of Bluetooth devices for locating a mobile device in use of the system; Figure 3 shows a functional block diagram of processes which run on the server shown in Figure 1; Figure 4 shows a functional block diagram of processes and data present on a mobile device in use of the system of Figure 2; Figure 5 shows a flow diagram of process steps occurring at start up of the system; Figure 6 shows a flow diagram of process steps occurring during movement in store, using the system of Figure 2; Figure 7 shows a flow diagram of process steps occurring to support real time personalisation of the system, using the system of Figure 2; Figure 8 shows a flow diagram of process steps occurring at checkout; Figure 9 shows an extract from a real-time register of location event data collected during movement of a user in store; Figure 10 shows an extract from user profile data for use in the system of Figures 1 and 2; Figure 11 shows an extract from a real-time register of message data collected during movement of a user in store; Figure 12 shows an embodiment of the system in the context of a retail environment, showing in particular software processes and a communications layout; and Figure 13 shows an alternate view of an array of Bluetooth devices for locating a mobile device in use of the system to that of Figure 2.

It should be noted that the figures are schematic only and none is drawn to scale.

1. Initial Registration Referring to Figures 1 and 2, in order to use most aspects of the retail management system, particularly any depending on personalisation, it is necessary for a user to pre- register with the system. This can be done in any convenient way, for example over the Internet or by completing a paper form. User data is then entered to a database 150 of a server 135 associated with the system called herein the "Tagboard" server 135, by a user profile readlwrite process 175 on the server 135. User data will comprise for example a system-based user ID, name and title, telephone numbers, Bluetooth device ID if relevant, preferences and status of the data. This data is further discussed below with reference to Figure 10.

An option to entering user data to the database 150 is just to enter an identifier such as the IMSI or telephone number of a mobile device 100. Although this does not support personalisation, it can support locationbased services in store.

Referring to Figure 4, once registered with the retail management system, the user will receive initial software code and data to support the system in use, this being for loading to their mobile communications device 100. That is, they will receive an activation or background process 451 which is the first of a set of processes 405 which will need to be present on the mobile device 100 to use the system in-store, together with supporting data 410. For example the code and data can conveniently be downloaded directly to the device 100 by a code update process 130 together with a communications process 170 on the server 135. The communications process 170 will generally be of known type, for example using the known IP process called data tunnelling. Once the device 100 is registered, further software and data can be loaded automatically to the device 100 by the code update process 130 when it is first detected in-store. The code update process 130, with its access to code and data 150 stored on the server 135 and the communications process 170 for transmitting code and data updates to the mobile device 100 thus together provide a delivery system for delivering software code to a mobile device 100, both on pre-registration and when detected in store.

The background software code 451 and data 410 is sufficient to enable the device 100 to respond appropriately when later entering a retail environment and thus comprises: * in a Bluetooth enabled device 100, a screen display offering the user the option to use the retail management system and a response mechanism triggerable by a Bluetooth transmitter to show the screen display * in a non-Bluetooth enabled device 100, the same screen display supported by a list of picocell transmitter IDs and a SMS message sending facility for notif'ing a retail management system of presence of the device 100 in the event that the device 100 is transferred into a picocell showing a listed transmitter ID.

The response mechanism triggerable by a Bluetooth transmitter and the SMS message facility which responds to transfer into a picocell with a listed ID each effectively provide a detector for detecting the arrival of the device 100 in a relevant retail environment.

It is an option that the background software code and data comprises a full current version of an application for use in the retail environment.

2. Picocell In-Store Startup Referring to Figure 1, a retail environment, in this case provided with shelving 105 to create aisles, is allocated a picocell of a cellular telephony system, the cell being served by a transmitter 115. The extent of the picocell at least roughly coincides with the extent of the retail environment on one floor and thus a live mobile communications device 100 will be transferred to the transmitter 115 by a cellular telephone network on entry to the retail environment, in the known manner of handover. The mobile device 100 will receive a transmitter ID from the transmitter 115 as part of the known handover process.

The mobile device 100 is shown in Figure 1 as a telephone but it will be understood that other mobile communications devices could be used, such as a personal digital assistant ("PDA").

The server 135 associated with the retail environment supports data 150 and software processes 140 embodying the retail information management system of the invention and is connected to a public telephone network. The server can thus be reached via the transmitter 115 of the picocell.

There are at least two alternative ways that startup can be enabled.

In a first method, because the user has previously registered with the system, the mobile device 100 has the background software process installed which runs whenever the telephone is switched on. Once the mobile device 100 receives a transmitter ID which is on its list of picocell transmitter IDs, because it has entered a relevant picocell, the background process recognises the transmitter ID and either alerts the user and offers a prompt whereby the user can choose to send a "Short Message Service" ("SMS") message or it transmits the SMS message automatically. In either case, the SMS message is addressed to a stored telephone number for the server 135. The SMS message constitutes an alert signal to a detection signal processor 195 on the server 135 and the retail information management system is now alerted to the presence of the mobile device 100.

In a second method, the picocell can be used to transmit a regular cell broadcast message, using existing technology enabled by network providers primarily for use by emergency services. This broadcast message will be received by all live mobile devices in the picocell and can alert the background software process in the same manner as recognition of the picocell ID described above.

There are several technologies available for communicating with a handheld mobile communications device 100 which is connectable to a public network, such as voice, SMS and the Internet using the "Wireless Applications Protocol" (WAP). Such devices are necessarily equipped with unique identifiers (IDs) for example in the form of the "International Mobile Subscriber Identity" (IMSI) which is stored on a "Subscriber Identity Module" (SIM card) inserted in the device. When the device 100 communicates, whichever protocol is in use will include an ID such as the IMSI with the communication and thus the server 135 automatically receives a device ID, either the IMSI or a telephone number representing the IMSI, with the SMS message from the mobile device 100 which has newly entered the retail environment.

Once the server 135 has received an alert signal from the mobile device 100, either a user request to use the system or an automated message from the background process, the detection signal processor 195 on the server 135 responds by checking the user profiles held in the server database 150. If the device ID is registered but the message was an automated one, the detection signal processor 195 now transmits an invitation message to the device 100, offering its service to the user while they are in the retail environment. If the user fails to respond or responds in the negative, nothing further transpires. If the user accepts, or the first communication from the device 100 was instigated by the user, a code update process 130 on the server 135 now uses the user profile read/write process 175 to run a status check, using the relevant user profile 145 to determine the version of its service that the mobile device 100 already has installed. (Responses by the user can be made for example using the red and green keys of a mobile device.) If the version is out of date, the code update process 130 downloads a current version of its service, both software code and data, to the mobile device 100 by using the known IP process known as data tunnelling. The background software process on the mobile device 100 receives the code and data and installs it, deleting any previous version. If the service software installed on the mobile device 100 is up to date, the code update process 130 checks the relevant user profile 145 for the date that the mobile device 100 last received data. If the data is out of date, the code update process 130 delivers current data to the mobile device 100. For example, the user may have updated their shopping list stored on the server 135 directly, using a personal computer, and the fresh shopping list will now be delivered to the mobile device 100.

The detection signal processor 195 and the invitation message mechanism together constitute a "service selector", allowing the user to choose whether to use the system on any particular occasion in the retail environment. Preferably, the invitation message offers more than one level of service, for instance personalised or non-personalised, that the user can select on that occasion.

The mobile device 100 is now enabled to use any of the services offered by the retail management system on the server 135 while in store and has a fully up to date version of all necessary code and data.

In an alternative arrangement, the code update process 130 on the server 135 might interrogate the background software process on the mobile device 100 to determine the version of the service that the mobile device 100 already has installed. This would allow the service to be updated in different retail environments. Or the servers 135 in different retail environments might be adapted to co-ordinate the information amongst themselves.

3. Bluetooth In-Store Startup Referring to Figure 2, in an alternative arrangement, there is an array of Bluetooth devices 200, 205 disposed about the aisles or departmental floors of the retail environment. One Bluetooth transmitter 200 is positioned at the entrance to the retail environment and a regular array of additional devices 200, 205 is disposed along the shelving 105. Each device 200, 205 has a unique ID and can communicate with a Bluetooth-enabled mobile device 100 in known manner.

When a live mobile communications device 100 which is Bluetooth-enabled enters the retail environment, the transmitter 200 at the entrance can "discover" the device 100 and communicate with it using a known Bluetooth connection establishment procedure. Some of the Bluetooth devices 200 are connected to a local area network ("LAN") 210 and thereby to the server 135. As part of the Bluetooth connection establishment procedure, the transmitter 200 at the entrance will receive an ID from the mobile device 100 and this is delivered as an alert signal to the detection signal processor 195 on the server 135 over the LAN 210. The detection signal processor 195 again checks the ID against the user profiles 145 stored in its database 150 and, if the result is positive, sends an invitation message using the Bluetooth link. The message operates in the same way as in the SMS version described above under the heading "2. Picocell InStore Startup". If the user accepts the invitation by selecting to use a service of the retail management system, the code update process 130 on the server 135 again runs a status check and downloads a current version of its service as necessary, software code andlor data, to the mobile device 100, using the Bluetooth link as bearer. The background software on the mobile device receives the code and data and installs it, deleting or overwriting any previous version.

As further discussed below, as well as the Bluetooth devices 200 connected to the LAN 210, there are "dumb" Bluetooth markers 205 which are not connected to the LAN but which can broadcast static, non-personalised information. The information broadcast by the dumb markers 205 is loaded to each marker by wireless connection and can be changed in the same manner.

4. Server Processes and Data Referring to Figures 1, 2 and 3, there are eleven primary processes 140 to support the retail management system installed on the server 135. Seven of these are enabling and four are concerned with user data processing. Several of the processes 140 enter and process data stored in the data store 150.

The seven enabling processes are: 1. user profile readlwrite 175 for accessing user profile data 145 2. real-time register update 160 for keeping a register 151 of users having a user profile 145 and being currently present in-store 3. detection signal processing 195 for detecting presence of a registered user in the retail environment and updating the real-time register 151 accordingly 4. clock 155 for synchronization and time stamping of collected data 5. code update 130 for delivering background code on initial registration and the full service code 405 and data 410 once a device 100 is in the retail environment 6. dumb marker update 112 for updating information broadcast by the dumb markers 7. communications 170 dealing with all the communications types the server 135 will use, including for example SMS messaging, data tunneling, Bluetooth and information on the LAN 210 The communications process 170 deals with constructing messages (such as text or email) in known manner and transmitting them to users' mobile devices 100 based on contact data held in user profiles 145 on the Tagboard server 135.

The four processes concerned with user data processing are: 1. a shopping list processor 185 for use by the user in assembling a shopping list and subsequently converting it to till roll data 2. a routing data processor 190 for delivering routing information to a user in-store 3. a location-based special offers 110 for alerting a user to special offers, depending on their location in the store and logging, for example, special offers already notified, and also optionally depending on their registered preferences, and 4. a marketing data processor 165 for assembling data from user behaviour Any one or more of these four processes, together with supporting data stored in the server database 150 or otherwise accessible via the server 135, and the communications process 170, constitute an information storage and transmission system for sending information in respect of the retail environment to a mobile device 100.

The shopping list processor 185 can also receive data concerning a shopping list from a handheld mobile device 100, such as changes to a shopping list stored on the server 135, and process it to produce till roll data with such factors as loyalty points and special offers taken into account.

In a Bluetooth enabled environment, there is an additional process 112 for updating the information being broadcast by the dumb markers 205.

Other functionality of the Tagboard server 135 is as described in WO 2004/0908 19, referred to above, and it may be supported by various payment systems in the same manner as there-described.

There are two routes for incoming data to the server 135, concerning the identity and location of the customer, this being either from Bluetooth devices via the intelligent transmitters 20 and the LAN 210 or directly from the user's mobile device 100 via the picocell, using for example SMS messaging or an internet protocol.

As shown on Figures 1 and 2, data stored on the server database 150 to support the retail management system comprises: * the user profiles 145 * a real-time register 151 of user selections and timestamped locations for the device 100 when moving in-store * a set of messages 152 the system might send to or receive from the mobile device * a set of maps 153 of the store for annotation to show location of goods or services specified bythe user via their mobile device 100 * a list of goods 154 to support the shopping list process 185, the routing data processor 190 and the location-based offers process 110 * dumb marker data 157: data presently transmitted by each dumb Bluetooth marker 205 (Bluetooth-based embodiments only) Also stored on the database 150 is the background code 451 (see Figure 4) and full system code 156 that will be downloaded to mobile devices 100 on initial registration and store entry.

Although software and data available on the server 135 may take various forms, a convenient form of database may often be found to be a Structured Query Language ("SQL") server database which can interact with existing store facilities. This potentially allows authorised personnel to addlamend data for example to support special offers and navigation information and to update store layouts. Preferably, the server software is browser -based so that it can easily be accessed over an Intranet or even the Internet. It will also require an appropriate interface for interaction with the existing store facilities, software and websites.

5. Mobile Device Processes and Data Referring to Figure 4, the processes 405 that will be present on a registered mobile device will at all times comprise an activation (background) process 451 for detecting a relevant picocell transmitter ID or cell broadcast, or responding to Bluetooth messages, when the user enters a retail environment. The processes which are subsequently downloaded will then include support for additional menus 452 for display, a location process 453 for transmitting timestamped signal strength measurements or picocell ID, a shopping list process 454 for assembling, amending and delivering shopping list data and a routing process 455 for requesting and displaying routing information from a known position in the retail environment, optionally in relation to specified goods or servicees.

The display 400 of the user's mobile communications device 100 can be used to show a variety of things, such as lists of goods or locations that the user might want to find, messages from the retail management system, including promotional material, routing advice and maps, a bar code to indicate a promotional offer has been taken up, and a shopping list. Data present on the device 100 to support some of the displays, such as the lists of goods and/or locations, is stored in the device's own memory 410, not on an insertable SIM card or the like, and the software processes 405 for managing the data also reside in the device's memory.

The processes 405 can conveniently be written for example in a software language such as Visual Basic or C++ and provide tools for use by the user in viewing and amending stored data. Alternatively, the processes 405 might be written in a Java-based language such as J2ME (Java 2 platform, Micro Edition) or, if Bluetooth is to be used as a bearer for the Wireless Applications Protocol ("WAP"), in WML ("Wireless Markup Language") Thus the processes 405 can provide navigation about a list and "select", "enter" and "delete" functions as well as supporting downloading and updating of data and software and delivery of signal strength measurements and picocell data for use in location by the retail management system. The form of the display will be determined by the nature of the mobile communications device 100 but might be for example text-based, as used for short message services (SMS), or an image in the case of a more sophisticated device such as an email-enabled device.

The user might input data and commands using a touch-based input such as a keypad or touch screen of the communications device 100. However, a first alternative is to use a personal computer and to load data to the device 100 using a mechanism such as "Activesync" 415, a Microsoft protocol for synchronizing e-mail, calendar, contacts, and other personal information management (PIM) data on mobile communications devices.

To enable communication to the device 100 in general, it will have various known communication systems in addition to standard SMS and voice telephony (not shown), these potentially including "Activesync" 415 as mentioned above, Bluetooth 420 and Internet protocols 445. These enable the device 100 to communicate with system checkout equipment 440, referred to here as "Tagbox", a personal computer 435, over the Internet 430 or embodied in an email.

Data supporting the retail management system includes, in the nonBluetooth-enabled device 100, a list 411 of picocell transmitter IDs (or cell broadcast content) the device 100 must recognise in order to initiate the activation process 451. Data that can be downloaded after activation comprises shopping list data 412 specific to the user, a list of goods categories 413 specific to the retail environment and a list of locations 414 that the user might wish to be directed to, such as a restaurant, a nearest exit or a specified car park. The list of goods categories 413 and the list of locations 414 are necessary to support the routing process 455. If the user is to be able to request routing information to find specified goods or locations, then it is necessary to supply a limited description of the goods and locations for which routing instructions are available. Otherwise the system would be unable to interpret user inputs attempting to specify the goods or locations concerned.

Operations supported by the processes downloaded in-store onto the mobile device 100 are as follows: Support for additional menus- Signal strength or picocell ID transmission- Shopping list- Routing and goods/services/access point information- For example, the menu delivery process 452 supports display of a pop-up menu providing the options of: "View special offers"; "View Events"; "Locate an Item"; and "Locate a Place In-store". Applicable menus 416 are downloaded to the mobile device 100 together

with the background process 451.

The location process 453 deals with reading picocell or transmitter IDs together with RSSIs, timestamping them and delivering them to the realtime register update process 160 on the server 135. Once present in the real-time register 151 (see Figures 9 and 11), this data can be accessed by for example the routing data processor 190.

The shopping list process 454 uses shopping list data 412 to code and decode goods codes 413 to ordinary English descriptions for use in shopping lists provided to the user on screen so that the user can make intelligent selections but only goods codes 413 need be transmitted to and from the server 135.

The routing process 455 similarly will use location data 414 to code and decode locations for use in displaying location information to the user on screen so that the user can make inputs intelligible to them but only codes for goods, services, access points and/or locations need be transmitted to and from the server 135. The routing process 455 also needs to be able to receive and display routing data such as routing instructions and/or maps from the location-based services process 110 on the server for the user.

6. Mobile Device Interactions Interaction between the retail information management system installed on the server 135 and the mobile device 100 might be as follows.

6.1 Detection and Startup Referring to Figure 5, STEP 500: If a mobile device 100 enters the store which is switched on, there are several scenarios: 1. The user isn't registered with the system and doesn't have Bluetooth enabled or it is switched off 2. The user isn't registered but has Bluetooth enabled and switched on 3. The user is registered but doesn't have Bluetooth enabled or it is switched off 4. The user is registered and has Bluetooth enabled and switched on If the user has never been registered with the system, there will be no activation (background) process 451 on the mobile device 100. The retail management system can only become aware of the presence of the mobile device 100 in- store if it has Bluetooth enabled and switched on. If the user is registered, or has been in the past and still has the activation process 451 installed on their mobile device 100, and has their mobile device switched on, then the retail management system will become aware of the in-store presence of the mobile device 100 either via a Bluetooth transmitter 200, or because the activation process present on the mobile device 100 makes itself known via a picocell transmitter 115, as described above under the headings "2. Picocell In-Store Startup" and "3. Bluetooth In-Store Startup ".

It might be noted that even if the user has never been registered with the system, it is still possible to send location-based information. In the Bluetooth-enabled environment, this can take into account the location of the mobile device 100 in relation to goods, or individual stores of a shopping mall for instance. In picocell-based embodiments of the invention, information can still be delivered by cell broadcast but cannot generally take the location of a mobile device 100 into account within the picocell.

STEP 505: Once the retail management system is aware of the presence of the mobile device 100, it will have an ID for the device, whether obtained via SMS message from the activation process 451 or via the Bluetooth connection. Once it has a mobile ID, the detection signal processor 195 triggers the user profile readlwrite process 175 to search the user profiles on its database 150 to check whether the user is currently registered with the system.

If the user is registered, the detection signal processor 195 will send a welcome to the user, offering personalised or non-personalised use of the system while in-store. If the user is not currently registered, for instance registration is out of date, the detection signal processor 195 will send a different welcome to the user, pointing out the nonregistered status and offering non-personalised use of the system while in-store.

STEP 510: If the user is registered and has accepted personalised use of the system, the processor 195 sends a personalised greeting to the user while it checks the version of software 405 and data 410 already present on the mobile device 100. If the user has not accepted personalised use, the processor 195 sends a generic greeting. Both greetings may be branded according to the retail environment. Even if the user is not currently registered, it is still an option to send a generic, branded greeting either via SMS message if the mobile device 100 has the activation process 451 present, via cell broadcast if not, or via the Bluetooth connection. It is also of course an option that the user chooses not to use the system at all on this occasion, in which case nothing further takes place.

STEP 515: If either code or data 405, 410 on a registered user's mobile device 100 is out of date, the processor 195 triggers a download from the server 135 to the mobile device 100. If the user proceeds with using the system, this will now be based on the most recent software anddata405,410.

STEP 520: The detection signal processor 195 updates the user profile 145 with respect to the software and data versions now present on the mobile device 100 and the level of service last selected by the user. It also triggers the real-time register update process 160 to flag the relevant device ID in the real-time register 151 (further discussed below in relation to Figures 9 to 11) as "present in-store".

The following description relates to interaction with the mobile device 100 of a registered user.

6.2 Movement in-store Referring to Figure 6, STEP 600: The user takes their mobile device 100 into the aisles or departments of the retail environment.

STEP 605: One of the processes 405 present on the mobile device 100 is a location process 453 for regular transmission of detection signals, in the form of either a picocell ID or measured signal strengths in respect of Bluetooth signals received by the device 100, to the retail information management system on the server 135. Either of these can be used to give a location of the device 100.

In the case of using the picocell ID, the mobile device 100 will receive the picocell ID as part of standard operation. A mobile device 100 will measure received signal strength for any cell from which it can detect a signal and transmit a Received Signal Strength Indicator ("RSSI") together with the relevant cell ID to the network for use in handover.

In embodiments of the present invention, it is thus possible for a location process 453 on the mobile device 100 to read the cell ID and send it to the retail management system on the server 135. The location will be relatively inaccurate as it covers the whole picocell.

However, it is known to use a 3-cell base station identity' which effectively creates three picocells at one location. Each of these has its own ID. In the context of a retail environment, this produces three delectably different locations of a device 100 which can be applied for example to different floors. Thus it is possible for the retail information management system to find out at least which floor of a department store the device 100 is present on. If the device 100 is taken to a different floor, the picocell ID it is transmitting will change.

In the case of using Bluetooth signal strengths, then it is possible to locate the device 100 with considerably greater accuracy. Bluetooth device protocols generally also support the use of RSSIs and the more limited range of the Bluetooth transmitters 200 and dumb markers 205 provides the greater accuracy. This is further discussed below under the heading "7. Real lime personalization and location-based services".

STEP 610: Detection signals received at the server 135 are saved to the real-time register 151 by the detection signal processor 195 (using the real-time register update process 160), together with a time stamp. This allows the retail information management system to track movement of the mobile device 100 while it is present in-store.

6.3 Location Resolution Referring to Figure 7, STEP 700: Detection signals received in STEP 610 can be processed to give a location in store. This might simply be conversion of a picocell ID to a floor ID or might be conversion of a set of Bluetooth signal strengths to a location within a floor, at least to the accuracy of the type of goods available at that location, such as "Hardware" or "Cold Meats".

STEP 705: If the user has accepted personalised or location-based use of the system, at this point personalised and/or location-based information can be sent to the user. This can include local special offers based on loyalty points or directions to another location in store in response to a user question via their mobile device 100. This aspect of the system is more fully discussed below, under the heading "7. Real time personalisation and location- based services".

6.4 Checkout Referring to Figure 8, STEP 800: In the case of using a Bluetooth connection, detection signals received in STEP 610 will be processed to give a "checkout" location in store.

STEP 805: Whether Bluetooth- or picocell-connected, the customer can select amongst payment methods and the method selected will be entered to the retail management system via the till. Available payment methods are as described in W02004/0908 19 and/or GB0509061.8 and will comprise or include cash, account, credit or Tagbox.

When the user reaches checkout, it is necessary to deliver till roll data to the till. This can be done conventionally, by scanning bar codes on the goods but it is considerably more efficient to use a shopping list which has been assembled on the mobile device 100 and converted by the user to till roll data, for example by confirming or deleting items listed.

In the case of using an in-store picocell, it may not be feasible to send complete till roll data from the mobile device 100 to a process on the server 135 by SMS message but if the server 135 already holds a shopping list compiled previously for the user, it is practicable to send markers, for instance quantities, against goods codes, or to send just changes to a previously compiled list. If the device 100 is WAP-enabled, till roll data could of course be transferred via an internet connection to the server 135. This can be selected by the user as an option at checkout via a menu of the processes 405 present on the device 100.

Alternatively, the Bluetooth connection, if present, can be used to carry the till roll data.

STEP 810: A loyalty discount may be applicable, determined by the relevant user profile 145 and optionally taking into account the till roll data. This is applied in the manner described in W02004/0908 19, referred to above.

STEPS 815, 820, 825: It is preferable but not essential that the retail management system is aware that the user has reached checkout. This allows the system to take the "in-store" flag off the relevant device ID in the real-time register 151 and to close down the application running on the mobile device 100. In the case of a Bluetooth connection, the location of the mobile device 100 at checkout can be detected. In the case of either a Bluetooth connection or a picocell connection, interaction at the till may equally give the retail management system the information that the user has reached checkout. This will occur if the user downloads till roll data from their mobile device 100 or pays using a credit or store card or the Tagbox system. In any of these payment methods, user-specific information will be entered at the till which can identify the user concerned by means of their user profile 145.

At this point, the relevant user profile 145 can be updated as necessary, for instance to record purchases made for use in loyalty discounting.

In the case of a registered user paying by cash in a picocell-based environment, the activation process 451 running on the device 100 can detect a change in cell ID when the user leaves the picocell and be triggered to send an SMS message to the server 135 via the public network. In this case, the application can close itself down, or go into snooze mode.

Alternatively, the system can take the "in-store" flag off the relevant device ID in the real- time register 151 and the application on the mobile device 100 can go into "snooze" mode when there has been a period of inaction or closedown.

7. Real time personalization and location-based services Referring to Figures 1 and 2, once the retail management system is alerted to presence of a registered mobile device 100, a personalised information service can be offered by accessing a user profile 145 available at or via the server 135. For instance, the user profile might include contact data such as a telephone number which can be used to send personalised text or voicebased information to the user, the content of which is tailored according to the user profile. This might be for example selected special offers or current loyalty discount status. Whether or not the user has opted to receive personalised information on this occasion, location-based services can still be made available, based on the mobile device's location in-store.

7.1 Location detection Whether or not a user has selected to receive personalised services, as long as the mobile device 100 is switched on and, in the Bluetooth embodiment, has the Bluetooth connection enabled, then it is possible for the retail management system to obtain at least limited positional information.

Positional information is available at three different levels: * that the mobile device 100 is present in-store * that the mobile device 100 is present on a particular floor of the store * that the mobile device 100 is in a particular location within the store, for example "hardware".

As mentioned above, the first two levels of information are available from the mobile device 100 by means of picocell identity. That is, the system receives from the mobile its own ID and the ID of the picocell it is present in, this mapping onto a particular floor of the store. Referring to Figure 2, the third level of information is only available when the mobile device 100 has a Bluetooth connection which is active.

As mentioned above, in a Bluetooth-enabled embodiment of the invention, there is an array of Bluetooth devices 200, 205 disposed about the aisles of the retail environment.

Some of these are "intelligent" in that they are connected to the LAN 210 and can be used to send real-time, personalised or location-dependent information to a specific mobile device 100 while some are "dumb" in that they are not connected to the LAN 210 and simply transmit their ID, location code and static information, such as non-personalised promotional information, to any mobile device 100 having its Bluetooth capability switched on. Dumb Bluetooth transmitters 205 are called "markers" herein and are provided with sufficient software to enable transmission of static data and to receive updates by wireless connection. An intelligent Bluetooth transmitter 200 is positioned at the entrance to the retail environment and a regular array of additional transmitters 200 and markers 205 is disposed along the shelving 105. Intelligent transmitters 200 are used at any point where personalised or location- based information may need to be sent to a mobile device 100 while dumb markers 205 are interspersed at regular intervals. As shown in Figure 2 for example, intelligent Bluetooth transmitters 200 may be placed at intervals down one side of each aisle while markers 205 are placed at intervals down the other side of the aisles.

The signals transmitted by both the intelligent transmitters 200 and the dumb markers 205 can be used to obtain the in-store location of the mobile device 100. These have at least a 30m range and transmit unique addresses. Using a grid of transmitters 200 and markers 205 at 30m intervals allows the location of a mobile device 100 to be calculated to an accuracy of 8m.

Referring to Figure 13, although each transmitter 200 or marker 205 will not be uniformly omni-directional, each one will have a known transmission footprint determined by the distance 1300 in each direction at which a signal can be usefully detected, the footprint being for example elliptical as shown in Figure 13. Navigation can then be based on the grid of transmitters 200 and markers 205. The general direction of a mobile device 100 moving within the grid can be calculated based on consecutive readings of comparative signal strengths measured for transmitters 200 and/or markers 205 in the grid, together with the known grid interval 1305. Clearly, signal strength affects the size and/or shape of the transmission footprint. Optimal signal strengths can allow a resolution as good as 1116th of the grid interval 1305.

Appropriate Bluetooth-based solutions are available for example from BLIP Systems, a company developing products such as "BlipNet", "BlipZones" and "BlipExplorer" from technology originating from Ericsson Denmark. The BlipNet for example has an associated Applications Programming Interface ("API") which offers the following features: * Event- or poli based monitoring * Dynamic configuration * Interaction with Bluetooth enabled devices o Link and session control o Signal strength and link quality monitoring o Push, pull, and exchange of objects o File transfer o Serial data communication o System initiated connections * Monitoring and interacting with server services o File transfer server o Object push server * Control of access points by applications (An "access point" in the context of BlipNet is equivalent to an intelligent transmitter 200 in an embodiment of the present invention.) Referring to Figures 2, 4 and 13, as long as the retail management system incorporates the ability to receive RSSI measurements from the Bluetooth enabled device 100, it can accumulate signal strength data associated with each in-range Bluetooth transmitter 200 or marker 205 for a mobile device 100. As long as the positions of the transmitters 200 and markers 205 are known to the system, it can resolve the position of the mobile device 100 in relation to the array, or "grid", of transmitters 200 and markers 205. As shown in Figures 2 and 13, each transmitter 200 and marker 205 has an area 215, 220 over which its signal can be received. Any mobile device 100 moving down the aisles of the in-store environment will receive Bluetooth signals including the ID for each in-range transmitter or marker 205. On receipt, a location process 453 present on the device 100 stores the ID, the Received Signal Strength Indicator ("RSSI") and a timestamp in related fashion in its memory 410 and sends these to the retail management system. The retail management system can then run an algorithm, using its location-based services process 110, to calculate the in-store position of the mobile device 100 from the relative RSSIs and IDs.

The algorithm necessarily operates in the context of the physical positioning of the transmitters 200 and markers 205 in-store, stored as data by the retail management system, and can therefore be updated as necessary.

In the above, it is the retail management system, based on the server 135, which converts the Bluetooth IDs and RSSI measurements to an in-store position of a mobile device 100.

However, it would alternatively be possible that the algorithm for the conversion is installed on the mobile device 100 as part of the background process 451 or during in- store startup and thus the mobile device 100 can calculate its own position in store. This reduces the necessity for communication between the mobile device 100 and the server but increases the amount of code and data downloaded to the mobile device 100.

Referring additionally to Figure 9, where the server has the in-store position of the mobile device 100, the mechanisms described above for detecting a user presence in-store and for tracking that user generate location data in the real-time register 151 held on the server database 150 which is maintained by the detection signal processing process 195 mentioned above. Firstly, a list of detection events 900 is made, each event being numbered. For each event, the user ID 905 is recorded and the detector (or picocell) IDs 910. In a Bluetooth environment, the RSSI data 915 for each detector received from the mobile device 100 is entered, followed by date and time 920 and a location code 925 based on running an algorithm using the RSSI data 915 and detector IDs 910. In practice, the algorithm can be relatively simple and might even be a matter of calibrating the RSSI readings 915 received in-store against location codes 925 by taking a set of readings prior to running the system live.

In a picocell-based system, the location codes 925 will only have values in respect of the floor a mobile device 100 has entered and there is no need of the RSSI data 915.

7.2 Location-based services Referring to Figures 1, 2 and 4, once data concerning the location of a mobile device 100 has been obtained, either by the retail management system on the server 135 or by the mobile device 100 itself, it becomes possible to support location-based services. Such a service might be called on in different circumstances. For example, three scenarios initiated at the mobile device 100 are as follows: * a user looking for specified goods * a user looking for a specified location, such as a restaurant * as a result of a promotional message, the user selecting a "take me there" option offered by a routing process 455 on their mobile device 100 In order to support a response in each of these scenarios, location data 154 is structured (on the mobile device 100 or in the server database 150) for referencing between: * names of goods items and service locations (restaurants for example) * departments * floors * access points (such as escalators, lifts, concession exits and the like) * map data * Bluetooth transmitters 200 and markers 205 (in a Bluetooth-based embodiment) Referring additionally to Figure 9, each location code 925 entered to the mobile device memory 410 or to thereal-time register 151 held on the database 150, for a user present in-store, can be translated to any and each of these "views" of the current location of the user. However, a particularly useful scenario is where the user has indicated goods items they wish to find and thus the more usual starting point for searching the memory 410 or database 150 might be an identifier for goods items.

Referring again to Figure 9, more than one event type can be recorded in the real-time register 15 1 in the database 1 50. In Figure 9, it can be seen that there are detector-based entries where a mobile device 100 has delivered RSSI data 915 against detector IDs 910 and this has been mapped to a location code 925 for the mobile device 100 in-store. A second type of entry has been triggered on a couple of occasions however where the user has caused a goods item or service location code 929, 925 to appear. This might have been done by selecting the code on their mobile device 100, because they want to buy dinnerware or to find the nearest restaurant for example, or by responding to a promotional offer by selecting "take me there".

From the user's point of view, there is no necessity for knowing what the goods item or service location code 929, 925 should be: it has been identified by the user selecting amongst plain English descriptions offered on-screen, using the data 410 present on the mobile device 100.

To respond to one of these events which are location-based requests for information, the system needs to specify floor and department, referenced by the goods items or service locations selected by the user, and to send this information back to the user in response.

Preferably, it can also deliver a map with the location of the goods indicated, for instance with a flashing icon. The structuring of the location-based data 153, 154 in the server database 150 easily supports such information delivery.

In a picocell-based embodiment of the invention, the location of the mobile device 100 is only known as far as which floor the device 100 is present on. In this case, the map need only show the floor where the specified goods are located, with perhaps a flashing icon to show the target location. Data to support this would be relatively straight forward since the map would be common to all queries received in relation to one floor and the position of the flashing icon is known from the specified goods, translated in accordance with data provided from a retailer's store layout.

In a Bluetooth-based embodiment of the invention, the location of the mobile device 100 may be known to within approximately 8m. Preferably, the map delivered to the mobile device 100 in such an embodiment also shows the device location. Further, in these embodiments it becomes possible to monitor the location of the mobile device 100 in real time and thus to track movement. This supports real time provision of guidance to the user to bring them to the target location. When a request for information is received, the routing data process 190 can be triggered to monitor subsequent events in which RSSI and detector ID data 915, 910 are received against the relevant user ID 905 and to modify subsequent routing instructions to the user.

Again, data to support this real time provision of guidance would be relatively straight forward since the map could again be common to all queries received in relation to one floor. It is necessary to track movement of the mobile device 100 subsequent to sending routing information and to interpret the movement as being towards or away from a target location. However, one way to do it is that the routing data processor 190 has access to sets of location data pairing user position with target location. Each user/target pair has an associated set of subsequent user positions which can be interpreted as moving towards the target location. Any subsequent user position that doesn't comply with the associated set will be interpreted as moving away from the target location and thus generate a second routing message. By analysing subsequent user positions, it would be possible to do this at a sufficiently detailed level that the second routing message is of the form: "Turn left", "Turn right" or "Go straight ahead".

It would also be possible in the Bluetooth embodiment to provide maps in tiles, dividing each floor of the store into areas so that a more detailed level of routing information could be provided, depending on how far the user is from the target location.

If a user is to be able to request information in-store in a Bluetoothbased embodiment of the invention, they can only do so via the intelligent transmitters 200 and not via the dumb markers 205 since the latter are not connected to the server 135. Preferably, there is an intelligent transmitter 200 located at least at each access point, such as at doors and lifts, since this is where a user is likely to request information and will then get good reception.

In a retail environment, the retailer will usually already hold data representing store layout, goods and access points. For example, it is known to use Computer Aided Design/Computer Aided Machinery ("CAD/CAM") software in designing store layouts.

The designer can evaluate different scenarios in a virtual environment, changing factors such as store layouts, goods layouts, lighting and promotional material to achieve an optimum design. This can be done at the level of the entire store layout or a single display. The resultant design can be made available over the Internet to stores in a chain or franchise, or to commercial partners, thus providing clear and consistent branding and retail strategies. It is convenient in embodiments of the invention to use the data already put together for this purpose of store design as base data for creating maps and routing instructions. This is particularly convenient in that it will already have been made available at a store location via the Internet.

7.3 Personalisation: promotional offers Referring to Figures 1, 2 and 9 to 11, it is known to deliver location-based promotional information. However, embodiments of the invention can go further by also offering personalisation as well as the navigation information described above. If a user has accepted personalisation (see STEP 505 above) on entry to the retail environment, and the user ID is found to be current in relation to the user profiles 145, the user profile read/write process 175 will read data from the relevant user profile 145 in order to assemble a personalised greeting. Using the communications process 170, and contact data from the user profile 145, a personalised greeting message is assembled and sent to the mobile device 100 of the user. This message can include pcrsonalised information concerning special offers and/or loyalty discount status.

Real-time personalisation is described in copending British patent application GB0509061.8 in the name TAGBOARD LTD, mentioned above, and the same functionality can be offered by use of embodiments of the present invention, the difference being primarily the different methods used here for location detection and for communication with the mobile device 100. However, in a novel extension of personalisation, special offers can be implemented by the transmission of a bar code from the retail management system to the mobile device 100. Such a bar code can be read at checkout and translated into price reductions, two-for-one offers and the like.

Referring also to Figure 9, as described in GB0509061.8, to provide real time personalisation, message content concerning special offers and the like is stored in relation to store location. This becomes available as the user reaches a relevant location, known to the system as the location code 925. If message content is relevant at a detected location, and also to the user in accordance with their user profile 145, then the user profile read/write process 175 and the communications process 170 assemble an appropriate message for transmission to the user's mobile telephone.

In the case that the user's current shopping total is known to the system, a further option for personalisation is to assemble and send a message to the user regarding their current discount situation. For example, the user may be approaching a threshold amount, above which they get increased discount. This can be made known to the user via their mobile telephone.

Referring to Figures 9 to 11, the data supporting the above processes 140 may be embodied in different formats and software technologies. However, an example might be represented in tabular form.

Referring to Figure 10, a user profile store 145 has eight columns for entering user IDs 1030, name and title 1035, 1040, 1045, telephone numbers 1050, preferences 1055, status of the data 1060 and the version number 1065 of the background/activation process 451 present on their mobile device 100. The user preferences 1055 provide profile-specific behaviour of the system by including for example identifiers for types of goods for which the user wishes to receive special offer alerts and/or rules for behaviour of the system such as triggers for sending special offer alerts. A rule might for example specify that special offer data is sent when the user's mobile telephone is first detected in a retail environment, or on a particular day of the week. The column for status of the data 1060 provides a roll- back position for error correction. If data has to be deleted, rather than actually deleting the data it is marked "deleted". Thus data deleted in error can be simply reinstated by taking off the "deleted" marking.

Referring to Figures 9 and 11, the real-time register 151 can be used both to monitor real- time store location 925 and to record message content 1199 sent to users in accordance with their user profiles 145 when the user ID is detected in a retail environment.

The structure of a part of the real-time register 151 for monitoring realtime store location 925 is shown in Figure 9 and is largely described above, under the heading "7.1 Location detection". However, it has two additional columns 927, 929 for recording a user selection of the level of service requested on entry to the store and for recording a goods code identified by a user input. The level of service can be selected from at least three different levels, "1", "2" and "3", which might represent requests for "no service", "non- personalised service" and "personalised service" respectively.

The structure of a part of the real-time register 151 for recording message content 1199 is shown in Figure 11 and has eight columns, the columns of primary interest being a first colunm for entering a messaging event 1165, a fifth column for entering the telephone number to which a message has been sent 1185, a seventh column for entering a date stamp 1195 to avoid repeating a message on the same day and an eighth column for entering the message content 1199 as sent. Typical message content might be: * Message content 1: Mr X, you asked for dinnerware. This is located on Aisle 7, near the restaurant.

* Message content 2: Fancy something exotic today Mrs Y? Aisle 12 has Fava beans at just 7Sp a tin! * Message content 3: Mr X, perhaps you've changed your mind.., but should you still wish to locate dinnerware, you might prefer to turn left when you reach Aisle 9 and then left again when you reach the end of Aisle 9.

(The name used in each case above is substituted by reference to the user ID and relevant user profile 145.) 8. Worked example: User Chooses Personalised Service Referring to Figures 2, 9 and 11, in a simple sequence of data collection and messaging, the following entries to the register 151 might occur.

Referring particularly to Figure 9, at 11.38 am, a user having user ID "325" enters the retail environment with a registered mobile device 100. The system detects the user ID, the detector IDs "03,15" and RSSI values "6,2" and enters these with a date/time stamp 920 (03/03/2005 11.38) to the register 151. The detector IDs "03,15" are related to location code "EN", indicating entrance. The user ID 325 is entered as current.

Referring additionally to Figures 1, 2, 10 and 11, a first process, "location based services" 110, uses the location code "EN" to review the user profile 145 for user ID "325" to see if the relevant user preferences 1055 indicate a message should be sent to this user at this point. Any appropriate message content 1199 is sent and recorded. This first message may offer the user the choice of level of service. In this example, the user selects a level "2", indicating personalised service.

Referring additionally to Figure 4, in an alternative arrangement the background process 451 on the mobile device 100 may instead detect that the mobile device 100 has entered a relevant retail environment and itself offer the user the choice of level of service. If the user selects levels "1" or "2", these being non-personalised or personalised service respectively, the device 100 will communicate this to the retail management system for example by Bluetooth or SMS communication, this triggering entry of data to the register 151.

The user enters the store and their mobile device 100 next sends RSSI data 915 for detectors "4 1,53,54" in an aisle adjacent to hardware goods "HW". This new detection event is time stamped 11.39. The process "location based services" 110 uses the location code "HW" to review the user profile 145 for user ID "325" to see if special offers on hardware are of interest to this user. If the result if positive, the location based services process 110 will search for message content relating to hardware goods, using the location code "HW", and if special offers are current will assemble a message for transmission to the mobile telephone of user ID "325" and update the register 150.

The next two detection events relate to user ID 601 who is moving in the kitchen goods areas of the store "KG1" and "KG2" and are of similar nature.

The user having the ID "325" now requests routing information by selecting a "plain English" description from a menu on their mobile device 100 which the routing data processor 190 can translate to the code "HWahi". This event is timestamped 11.50. The routing data processor 190 now refers to the last known location of user 325, "11W", and assembles a message for user 325 giving guidance as to where in "HW" the goods identified as "HWahi" can be found. The next event regarding user 325 puts them in a different location "EN". It would be possible to send user 325 another message about the location of goods "HWahi" but the probability is that they have found the goods and moved on, since they were so close. No message is sent.

The user 601 subsequently asks for routing information to goods identified as "KGtkt".

The routing data processor 190 refers to the last known location of 601 which in practice is "EN", remote from "KG". The routing data processor 190 assembles a message with routing information from EN to KG and sends it to user 601. The next location event is receipt of RSSI data 915 indicating that user 601 has in fact moved in a wrong direction for KG. The routing data processor 190 now assembles a message to correct the situation, such as "Message content 3" described above: "Mr X, perhaps you've changed your mind but should you still wish to locate dinnerware, you might prefer to turn left when you reach Aisle 9 and then left again when you reach the end of Aisle 9." If user 601 does not appear to respond to this advice, no further messages will be sent.

In the above description, the location of the users is entered to the register 151 in a relatively "coarse" fashion since the changed location of user 325 is only registered in relation to a new location code 925; "EN". In practice, it would be possible to monitor incoming detector ID and RSSI readings 910, 915 in much more detail so that a move in the wrong direction for the mobile device 100 of user 325 could be detected very quickly and further routing advice offered.

9. Software and Communications Environment Referring to Figure 12, the software and communications environment for embodiments of the invention include: 1. the server 135 carrying the software processes 140 specific to the system, 2. data and processes normally present in a retail environment, such as a discounting system 1255 and store layout 1260, 3. an electronic point of sale ("EPOS") 1285, 4. additional equipment for supporting checkout processes in the context of the retail management system, called here the "Tagbox" 1280, 5. theLAN2lOand 6. thelnternet43O.

The Tagbox 1280 as used herein provides the same functionality as already described in W02004/0908 19 and British patent application GB050906 1.8 mentioned above but relies on either Bluetooth communications protocols, such as the Service Discovery Protocol ("SDP"), or telephony/internet protocols, in place of radio frequency communications.

SDP for example enables network devices, applications and services to seek out and find other complimentary network devices, applications and services needed to properly complete specified tasks.

Thus embodiments of the invention are capable of providing both navigation and personalised services to the user. They can also provide all the functionality of the system as described in W02004/0908 19 and British patent application GB050906 1.8, the communication with the mobile device 100 now being supported by Bluetooth connections or by telephony or internet protocols via the public network providing the Picocell, and by the software 405 present on the mobile device 100.

In summary, embodiments of the invention can be adapted to: * Maintain a set of user profiles 145 including IDs for mobile devices 100 * Detect entry of a registered device 100 to a retail environment * Load software, or software updates as necessary, andlor data to a detected device 100 * Monitor location of a mobile device 100 in the retail environment, including multi- floor settings * Compute routes for the customer to reach a desired location in-store * Support the user in finding specified goods or facilities in-store * Make special offers generated by proximity as well as based on personalized services * Provide an interface to a retailer's database, for instance via a LAN 210, so as to access promotional and navigational data that the retailer maintains, in a form that can be delivered to and understood by the customer These various functionalities can easily be customised for particular retailers, for example to reflect their own branding and marketing propositions.

Advantageously, when a customer leaves the retail outlet, their mobile device 100 is returned to the state it was in before entry and, while in the environment, its normal functions remain unaffected. No cost need be incurred by the user and embodiments of the invention can be used with a wide range of mobile devices 100, including 2G, 2.5G, 3G enabled devices 100 and any Bluetooth-enabled device 100. Business benefits lie in a combination of features such as reduction of "not found" items, improved and targeted marketing and the potential gathering of data such as locations where users tend to spend increased time.

It is an option to include a help facility whereby the user can be connected to store personnel via the Bluetooth or picocell connection.

It should be noted that the location of the various data stores and processes described above as being on the server 135 may in practice be different. The specific distribution of data and processes, and the network arrangement, are not important and are likely to depend in practice on local (or even remote) availability of processing capacity. Further, certain data andlor processes can be either loaded to the mobile device 100 or stored on the server 135. For example, although all the user profiles 145 together are clearly inappropriate for storage on the mobile device 100, at least some aspects of the real time register 151 could be kept on the mobile device, such as RSSI measurements, together with one or more non-personalised processes for acting on the real time data. Hence the routing process 455 on the mobile device 100 may be capable of analysing the RSSI measurements in terms of a store map and displaying routing instructions, such as "turn left", for the user. This avoids unnecessary communication with the server 135 but means data representing the store map and the distribution of Bluetooth transmitters 20 and markers 205 has to be downloaded and maintained up to date on the mobile device 100. It would also be an alternative that at least aspects of the relevant user profile 145 for a particular mobile device 100 are stored on the device 100, this then supporting real time, personalised service without recourse to data held on the server 135.

In preferred embodiments, the data and processes present on the mobile device 100 andlor on the server 135 can together provide the following: * A set of user profiles 145 including an identifier and/or contact data, such as a telephone number or email address, for at least one mobile device 100 for each user pre-registered with the system * A real-time register 151 recording presence of a mobile device 100 in store together with a series of detected locations * Routing data 153, 414 and a process 190, 455 for selecting routing data in accordance with a detected location for a mobile device 100 recorded in the register * Goods and/or services data 154, 413, and a process 110, 455 for selecting goods and/or services data in accordance with a detected location, and optionally in accordance with a user profile 145, associated with a mobile device 100 recorded in the register * A selection mechanism 451, 452 enabling the user to select a level of service via a mobile device 100 * A delivery mechanism 110, 190, 454, 455 for delivering selected routing and/or goods and/or services data to the display of a mobile device 100 recorded in the register This set of data and processes allows the system to target delivery of routing and goods and services information, optionally in a personalised manner, to users in real time in the retail environment.

It should be noted that, for the purposes of the present specification, the word "comprising" is intended to be interpreted, unless the context indicates otherwise, so as to include for instance at least the meaning of either of the following phrases: "consisting solely of" and "including amongst other things".

Claims (24)

1. A retail information management system, the system comprising: a detector for detecting arrival of a mobile communications device in a retail environment; a delivery system for delivering software code to a detected device; and an information storage and transmission system for sending information in respect of the retail environment to the detected device for reception by the delivered software code, whereby the detected device is enabled to provide information to a user in respect of the retail environment.

2. A system according to Claim 1 wherein the information storage and transmission system is adapted to store user profiles for use in personalizing information provided to the user.

3. A system according to either one of the preceding claims wherein the information storage and transmission system is adapted to store routing data in respect of the retail environment for use in providing routing information to the user.

4. A system according to Claim 3 wherein said routing data is selectable according to one or more identifiers for goods or services, such that routing information provided to the user includes location data for selected goods and/or services.

5. A system according to any one of the preceding claims wherein the detector is adapted to provide an alert signal to the information storage and transmission system on detecting arrival of the device in the retail environment.

6. A system according to any one of the preceding claims, wherein the detector is present on the detected device.

7. A system according to any one of the preceding claims wherein the detector is provided as part of the information storage and transmission system.

8. A system according to Claim 6 wherein the detector is adapted to detect said arrival on receipt of a specified identifier for a cell, on handover in a cellular telephony network, by the device.

9. A system according to Claim 8 wherein the detector is further adapted to detect a change in location of the mobile communications device in the retail environment on receipt of a further specified identifier for a cell, on handover in a cellular telephony network, by the device.

10. A system according to any one of Claims ito 7 wherein the device is equipped with Bluetooth communications, the retail environment is equipped with at least one Bluetooth transmitter, and the detector is adapted to detect said arrival on receipt of specified data via a Bluetooth connection.

11. A system according to Claim 10 wherein the detector is further adapted to detect location of the device within the retail environment.

12. A system according to Claim 11 wherein the detector is adapted to detect said location by means of respective signal strength measurements in respect of at least two separately identifiable Bluetooth transmitters in the retail environment.

13. A system according to any one of Claims 9, 11 or 12, further comprising location- dependent routing data and a routing data selector for selecting routing data to support provision of routing information to the user via the device, the routing information being at least partly dependent on a current location of the device in the retail environment.

14. A system according to any one of the preceding claims, further comprising a service selector, triggerable on detection of arrival of the device in the retail environment to offer the user selection between at least two different levels of service, at least one of the two levels of service being personalized.

15. A system according to any one of the preceding claims wherein the delivery system for delivering software code is triggerable on detection of arrival of the device in the retail environment to run at least one process.

16. A system according to Claim 15 wherein said at least one process comprises a process for checking the status of software code and/or data already present on the device against the status of software code and/or data available for delivery by the delivery system and updating the software code and/or data present on the device in accordance with the result of the status check.

17. A system according to any one of the preceding claims, further comprising an interface for obtaining data from a data store in addition to the information storage and transmission system.

18. A mobile communications device adapted for use with a system according to any one of the preceding claims.

19. A device according to Claim 18, said device comprising said detector.

20. A device according to either one of Claims 18 or 19, the device being adapted to store routing data in respect of the retail environment for use in providing routing information to the user.

21. A device according to either one of Claims 19 or 20, wherein the detector is further adapted to detect location of the device within the retail environment.

22. A device according to Claim 21 wherein the detector is adapted to detect location of the device by means of signal strength measurements made in relation to Bluetooth signals received by the device.

23. A device according to Claim 21 wherein the detector is adapted to detect a change in location of the mobile communications device in the retail environment on receipt of a specified identifier for a cell, on handover in a cellular telephony network, by the device.

24. A device according to any one of Claims 18 to 23, further comprising a shopping list management facility for managing or constructing a shopping list.