WO2023089476A1

WO2023089476A1 - Computer system and method for providing location-based services

Info

Publication number: WO2023089476A1
Application number: PCT/IB2022/060970
Authority: WO
Inventors: David House
Original assignee: David House
Priority date: 2021-11-16
Filing date: 2022-11-15
Publication date: 2023-05-25

Abstract

A computer-implemented method is disclosed herein for providing a location-based service to one or more mobile client devices. The method comprises downloading a location-based tour to a mobile client device, the tour comprising a playlist for following an itinerary, the itinerary comprising an ordered set of sites. The playlist includes a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item via the mobile client device. The mobile client device is configured to receive positioning information indicating a current location of the mobile client device, and at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information. The method further comprises receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary.

Description

COMPUTER SYSTEM AND METHOD FOR PROVIDING LOCATION-BASED SERVICES

Field

The present application relates to a computer system and computer-implemented method for providing location-based services.

Background

Mobile computing devices, such as smartphones, tablets, and laptops, are in widespread use. Such devices support wireless connectivity to the Internet, typically over a Wi-Fi connection and/or a mobile telephone (cell phone) connection, for example as provided by a 4G telephone network. In the context of a telephone network, such devices are often referred to as user equipment (UE). In practice, telephone networks generally offer a large geographical range of service accessibility via a single provider. In contrast, Wi-Fi connections (wireless access points, wireless AP, WAPs) are local in nature, and different WAPs are often managed by different providers, each requiring a separate sign-on procedure. On the other hand, Wi-Fi connections may offer a higher data rate and/or lower (sometimes zero) cost compared with connections over the telephone network, and may also be configured to provide a better service inside buildings or at other locations where telephone network coverage is relatively poor. Accordingly, many mobile computing devices support a heterogeneous set of communication networks, which may also include other forms of wireless connectivity, such as Bluetooth and near-field communication (NFC).

Network connectivity as described above allows a mobile computing device to access services at various different locations using wireless communications. In such communications, the mobile computing device generally acts as a client which requests services (including data, apps, etc) from servers accessible over the wireless communication network. The servers may also ‘push’ messages and other content to devices - for example, notifications about data usage and charging. A mobile computing device typically includes a browserto support access to servers and services available over the web. The mobile computing device may also support access to services made available in other ways (rather than being available over the web); for example, such facilities might be specific to a given mobile telephone network.

Many mobile computing devices are able to determine their current location using the global positioning system (GPS) and/or any other suitable satellite navigation system (such as Galileo). Location information for the mobile computing device may also be available from other sources. For example, wireless telephone networks are able to provide some determination of UE position based on the directionality and signal strength of received communications. This location information is likely to become more accurate with the introduction of 5G networks and femtocells which provide wireless telephone connectivity over a more localised area than conventional base stations. Similarly, connecting to a wireless AP may provide location information for the device assuming that the location of the WAP itself is known (the latter will normally be fixed although might possibly be provided in a moving device, such as a train). Forming other types of network connection, such as Bluetooth or NFC, may also yield position information. (Note that the terms location and position are used interchangeably herein, and likewise for associated terms, such as location information and position information).

The availability of location information for clients has supported the development of location-based services. In such services, a client may explicitly provide a server with the location of the client (for example, as determined by a GPS-enabled client) and/orthe server may determine the client location implicitly (for example, by the client connecting to a particular wireless AP). The server may then provide the user with a service, e.g., data or functionality, that is at least partly customised to the current client location.

For example, one known form of location-based service is for vehicle routing. Typically a driver may specify a desired destination and the service may determine and display a proposed routing from the current location (e.g. as determined by GPS) to the specified destination. The mobile computing device may then display this routing to the driver on a map which also shows the location of the vehicle. The map may be further populated with ancillary information of potential relevance to the driver - e.g., locations of slow or congested traffic, fuel (gas/petrol) stations, electric car charging points, places to eat, and so on. The map can then be updated as the driver progresses along the route, this progress being tracked by using GPS or other source of vehicle location.

The present disclosure relates to a computer system and method for providing enhanced location-based services.

Summary

The invention is defined in the appended claims.

A computer-implemented method is disclosed herein for providing a location-based service to one or more mobile client devices. The method comprises downloading or streaming or preloading a location-based tour, or a segment thereof, to a mobile client device, the tour comprising a playlist for following an itinerary, the itinerary comprising an ordered set of sites. The playlist includes a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item via the mobile client device. The mobile client device is configured to receive positioning information indicating a current location of the mobile client device, and at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information. The method further comprises receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary. The step of downloading or streaming or preloading a location-based tour to a mobile client device can include preloading a segment of the tour, such as the content items associated with the next site in the itinerary based on the current location of the mobile client device, and temporarily storing the preloaded segment within a buffer ready to be retrieved when the trigger condition is satisfied.

Brief Description of the Drawings

Various aspects and implementations of the present disclosure are disclosed herein with reference to the accompanying drawings by way of example only:

Figure 1 is a high-level schematic diagram of an example of a client side for use in providing a location-based service as disclosed herein.

Figure 2 is a high-level schematic diagram of an example of a server side for use in providing a location-based service as disclosed herein. The server side of Figure 2 is complementary to the client side of Figure 1 .

Figure 3 is a high-level schematic diagram of an example of a client mobile computing device for use on the client side such as shown in Figure 1 .

Figure 4 is a schematic representation of an illustrative high-level menu presented to a user of the client device of Figure 3 for selecting between different location-based services as described herein.

Figures 5A, 5B and, 5C are schematic representations of example screens that may be presented to a user to allow selection between different itineraries in response to selecting the NOW option from the screen of Figure 4.

Figures 6A, 6E3 and 6C are schematic representations of example screens that may be presented to a user in response to selecting the PLAY option from the screen of Figure 4.

Figures 7A and 7E3 are schematic representations of example screens that may be presented to a user in response to selecting the ME option from the screen of Figure 4.

Figures 8A, 8E3, 8C and 8D are schematic representations of further example screens that may be presented to a user in response to selecting the ME option from the screen of Figure 4.

Figures 9A and 9E3 are schematic representations of example screens that may be presented to a user as part of a process for creating a user account.

Figure 10 is a schematic diagram providing an overview of an example location-based service as described herein which may be performed by the server side of Figure 2 and the client side of Figure 1 .

Figure 10A is a schematic diagram providing an example of how the location-based services may be personalised for a user.

Figure 11 is a schematic diagram providing two examples of processing flows for launching a location-based service as described herein. Figure 12 is a schematic diagram providing two examples of processing flows for launching a location-based service as described herein, the location-based service typically involving the creation of at least one customised (personalised) feature.

Figure 13 is a schematic diagram providing an example of an administration portal for use by the server side (backend) shown in Figure 2.

Figure 14 is a schematic diagram providing an example of a dashboard which may be accessed from the administration portal shown in Figure 13.

Figure 14A is a schematic diagram providing an example of a high-level screen for content creation which may be accessed from the administration portal shown in Figure 13.

Figure 15 is a schematic diagram providing an example screen for use by a developer in creating a tour playlist in accordance with one implementation.

Figure 16 is a schematic diagram providing an example screen for use by a developer in creating a GPS trigger for a tour playlist in accordance with one implementation.

Figure 17 is a schematic diagram of an example screen for use by a developer in providing location information for a tour playlist in accordance with one implementation.

Figure 18 is a schematic diagram showing an example of the structure or configuration of various components within a tour playlist.

Figure 19 is a schematic diagram showing an example of an interface for adding an Element to a tour playlist, an Element being one of the components illustrated in Figure 18.

Figure 20 is a schematic diagram showing two examples of an interface for adding a Trigger to a tour playlist, a Trigger being another one of the components illustrated in Figure 18.

Figure 20A is a schematic diagram showing two examples of an interface for adding an Event to a tour playlist, an Event being another one of the components illustrated in Figure 18.

Figure 20E3 is a schematic diagram showing an example of an interface for specifying content for a newly created Event such as shown in Figure 20A.

Figure 21 is a schematic flowchart showing an example of a method for playing content on an approach to a site of interest.

Figure 22 is a schematic flowchart showing an example of a method for implementing a location-based game on multiple different regions.

Figure 23 is a schematic flowchart showing an example of a method for monitoring usage of a tour by multiple participants.

Figure 24 is a schematic diagram showing an example of an interface for adding location information in bulk for a tour playlist in accordance with one implementation.

Figure 24A is a schematic diagram showing an example of an interface for reviewing uploaded locations; the locations being uploaded in bulk as shown in Figure 24.

Figure 25 is a schematic diagram showing an example of an interface for adding a new Tier; a Tier being an operational process for automatically creating and launching a tour playlist in multiple different locations. Figure 26 is a schematic diagram showing an example of an interface presented to a developer after requesting to add a new Tier as shown in Figure 25.

Figure 26A is a schematic diagram showing an example of an interface for specifying the locations where the tour playlist is to be made available; the tour playlist being defined in the Tier shown in Figure 25.

Figure 27 is a schematic diagram showing an example of an interface listing each of the Tours in draft mode, and showing an example menu screen associated with one of the Tours with the Rollout option highlighted.

Figure 27A is a schematic diagram showing an example of an interface for scheduling the rollout of a tour playlist in one or more of the locations specified in the Tier, as shown in Figure 26 A.

Figure 27E3 is a schematic diagram showing the Figure 27 interface after the tour playlist has been scheduled for rollout in each location, as specified in Figure 27A.

Figure 28 is a schematic diagram showing example content presented to a user when following a tour playlist after selecting the ME option.

Detailed Description

The present disclosure relates to a computer system and computer-implemented method for providing and/or performing one or more location-based services. The system and method described herein may be used to create and provide itineraries and tours. Each itinerary comprises a set of geographical places (sites or locations) to be visited by a user in accordance with a particular ordering. Such ordering is typically predefined, but may be dynamically modified in some circumstances (i.e., modified as the tour itself progresses), as described in more detail below. Some sites may correspond to a specific, localised place of interest, such as a building (or part of a building), a viewpoint, a tree or other natural feature, a geological feature, a monument, or work of art (or collection of such art works), a sports venue, and so on. Other sites may correspond to a more extended feature of interest, such as a park, a scenic route (by car, bike, foot, etc), a historical district, a lake, a beach, and so on. Accordingly, sites can span a spectrum of sizes, ranging from small, specific locations to larger, extended locations (areas). The itineraries described herein are generally developed for recreational (entertainment) purposes, including sight-seeing, location-based games, social activities and so on.

An itinerary may have a simple topology, in which there is a single, defined ordering of sites (nodes) from an initial node through to a final node- e.g., visiting sites A, E3, C, D and E in sequence, where A is the initial node and E is the final node. Other itineraries may have a more complex topology, such as including one or more branches; this can allow for multiple start nodes and/or multiple end nodes, which may be helpful such as to accommodate different user starting locations or desired ending locations. For example, an itinerary may start with nodes A, E3 and C, and then might branch to a first option of nodes D, E and F (with F representing the final node for this first branch) and a second option of G, H, I and J (with J representing the final node for this second branch). Note that a node may offer two or more branches as options for progressing from the node. A given itinerary may include zero, one or more branches. The topology may further support branches joining together as the itinerary progresses. For example, an itinerary may start with nodes A, E3 and C, and then might branch to a first option of nodes D, E and F, and a second option of nodes G, H, I and J. Both nodes F and J may then progress to (and join together at) node K, with a further node L then representing the final node of the itinerary. In some cases, the nodes may form a closed loop for some or all of the itinerary; for example, the itinerary may approximate a circle to return the user to their starting point at the end of the tour.

In some cases, a modified itinerary may be created for a particular user. For example, if an itinerary includes nodes A, B, C, D and E, the ordering or sequence of nodes might be reversed in a modified itinerary for a user who is starting near node E, so that E would become the initial node and A would be the final node. Another example is where the itinerary comprises a loop of nodes A, B, C, D and E, with node E relatively close to node A; a modified itinerary might be created (for example) of nodes C, D, E, A, B for a user who is starting near node C. Note however, that some of the location-based services described herein, such as certain games, might not support such modification of the itinerary, for example because the ordering of the itinerary may be tied to the flow of the game.

In some cases, the itineraries may be modified so that multiple users can end at the same location at the same time. For example, if two friends want to meet at node F at a particular time but their starting points are at A and G respectively, then two itineraries can be created to accommodate the different starting points and the desired endpoint at the requested time. For example, the first itinerary may include nodes A, B, C, D, E and F, and the second itinerary may include nodes G, H, I, and F. In this example, the first itinerary has more nodes than the second itinerary to account for the different travel times from A to F and from G to F. This helps to ensure that the two users have their own unique experiences, and then arrive at node F at the same time to experience the final location together.

In general, each node orsite of an itinerary can be regarded as a start node, an intermediate node, or an end node. Each start node has at least one downstream (ordered) link to another node which is an intermediate node or an end node. Each end node has at least one downstream (ordered) link from another node which is an intermediate node or a start node. Each intermediate node has at least one downstream (ordered) link to another node which is an intermediate node or an end node and at least one downstream (ordered) link from another node which is an intermediate node or a start node. Thus each node (site) has at least one ordered link associated therewith. In more complex topologies, a node may potentially have multiple roles, i.e., represent two or more of a start node, intermediate node, or an end node; in such complex topologies, each node still has at least one ordered link associated therewith. In many cases, an itinerary is predefined within the system. The system may be able to dynamically modify an itinerary (whether predefined or otherwise). Such dynamic modification may occur immediately before a user commences the itinerary, for example, to allow the user to begin the itinerary near to their present location as discussed above, and/or to reflect particular user preferences or requirements. In some cases, dynamic modification of an itinerary may occur after the user has already commenced the itinerary.

Dynamic modification may involve one or more sites being added to or removed from the itinerary. For example, the remaining time available may have decreased due to traffic delays between sites or because a user spent more time at a previous site on the itinerary than originally planned. In this case, the system may modify the itinerary to reduce the time likely to be needed to complete the itinerary. Such modification may include excising one or more sites from the itinerary and/or replacing one or more sites on the itinerary (for example, by going to an alternative site which is smaller, and which will take less time to view). Modification of the itinerary may also occur based on user feedback regarding the itinerary to date. For example, if the user thinks that an earlier site on the itinerary was crowded, the system may remove or replace a site still to be visited if this site is likely (or known) to be similarly crowded.

A dynamic modification of the itinerary by deleting or modifying one or more sites in the itinerary may be subject to user approval. For example, if there has been a traffic delay, a user may still want to complete the original itinerary, even if this means finishing later than originally scheduled. In some cases, a modification of the itinerary may be unavoidable, for example, if a traffic delay means that a site would not now be reached prior to closing; in these cases, the user might be notified of the update to the itinerary (but would not be able to reject the update).

In some cases, a user 111 may not be aware that a route has been dynamically modified. For example, a user might provide feedback that they do not enjoy the site - e.g., based on a user rating. In this situation, the system might decide that a subsequent site according to the original itinerary is too close in terms of character and interests to the site which has just been visited, and accordingly make a new choice for the subsequent site having regard to the user feedback. The system may avoid the user being aware of such a switch by only presenting the user with information about the (immediate) next site for the itinerary - hence any dynamic modification later on in the itinerary would be transparent to the user.

It will be appreciated that some of the location-based services described herein, such as certain games, might not support such dynamic modification of the itinerary. For example, an itinerary may be predefined to tie into the flow of the game. In contrast, dynamic modification may be focussed mainly on personalised tours (such as the ME option described below in relation to Figure 4).

Figure 1 is a high-level schematic diagram of an example of a client side 100 for use in providing location-based services as disclosed herein. Figure 1 is complementary to Figure 2, which is a high-level schematic diagram of an example of the server side (also referred to as the back-end) 200 for use in of providing location-based services as disclosed herein.

Figure 1 shows a client side 100 including a user 1 11 in a vehicle 1 10 with a mobile computing device 112. The mobile computing device 112 is typically a smartphone, but may be any other device with suitable computing and communication facilities, such as a tablet or a laptop. A satellite 101 which is part of the global positioning system (GPS) is transmitting a GPS signal 102 for reception by the mobile computing device 112. The mobile computing device 112 also transmits and receives wireless communication signals 121 over a mobile telephone (cell phone) network, which includes base station 120, to communicate with the server side 200.

Note that the term client side 100 is used herein as a convenient way to refer to the set of components illustrated in Figure 1 , but without implying a close technical inter-relationship between all these different components. For example, although the satellite 101 and the base station 120 both interact with the mobile computing device 112, they are quite separate systems and are part of their own respective (separate) networks (GPS and mobile telephone). Only the mobile computing device 112 of Figure 1 is typically acting as a client in the conventional sense with respect to the server side 200 in Figure 2 (as discussed below). Accordingly, references to a client herein generally refer to the mobile computing device 112, where appropriate in combination with the user 1 11 who is operating the mobile computing device 112.

It will be appreciated that although Figure 1 depicts a single GPS satellite 101 , in practice the mobile computing device 112 generally needs to receive line-of-sight signals 102 from multiple (typically at least four) different GPS satellites 101 currently above the horizon to be able to derive a GPS position by trilateration. In addition, the mobile computing device 112 may use one or more other satellite navigation systems in addition to (or instead of) the GPS satellites for providing a location of the mobile computing device 112.

Furthermore, a position for the mobile computing device 1 12 may be obtained by one or more other technologies not shown in Figure 1 in addition to (or instead of) the use of a satellite navigation system. In some cases, a user location may be estimated based on properties of the signals 121 transmitted and received between the user equipment (UE, i.e., mobile computing device 112) and the base station 120. For example, a UE may transmit a received signal strength indicator (RSSI) back to a base station 120. Since the base station 120 knows the strength with which the signal 121 was originally transmitted, the base station 120 can make an estimate of the distance between the base station and the UE (the signal attenuation may also be dependent on directionality of the UE compared to the base station 120 and intervening topography). In some cases, the UE may return RSSI values for signals received from multiple different base stations and this may allow a better estimate of position for the UE. In addition, the estimated position of the UE generally becomes more accurate the smaller the area (cell) served by the receiving base station 120 (as is the case for the deployment of 5G networks). Any position information derived by the mobile telephone (cell phone) network may be provided to the UE and/or to the server side of the computer system disclosed herein for providing location-based services. If the mobile computing device 112 is connected to a wireless access point (WAP), this may allow further positioning information to be obtained for the mobile computing device 112.

Accordingly, the location of the mobile computing device 1 12 may be determined using one or more of any available position determining technologies such as (but without limitation to) those described above. Typically, such position information may be determined directly by the mobile computing device 1 12 itself as described above from signals 102, although the mobile computing device 112 may instead (or additionally) acquire and utilise position information determined separately, such as by base station 120 (or more generally the mobile telephone network) as described above, and/or by car 1 10 as described below, or from any other suitable source. The mobile computing device 112 is then able to provide the determined and/or acquired location information to the server side 200.

In other configurations, location data for the mobile computing device 112 may be (additionally or alternatively) passed to the server side 200 by another device, rather than directly by the mobile computing device 112 itself. By way of example, the mobile telephone network may determine such location information for the UE (mobile computing device 112) as discussed above and pass this information directly to the server side 200. Another possibility is where the mobile computing device 1 12 connects to a wireless AP (not shown in Figure 1) and this wireless AP (or the network to which the wireless AP belongs) provides location information to the server side 200. A further possibility discussed below is that the server side 200 receives position information from the vehicle 110.

If multiple sources of position information are available, for example from GPS and also from the mobile telephone network, these sources may be combined into a single location estimate; another option is for the different sources to be ranked, and the highest available ranked source may be utilised - e.g., if GPS is available, then positioning is based on this GPS, with any other positioning available from (say) the mobile telephone network being discounted. Such combination or ranking may be performed client side or server side. The skilled person may be aware of other possible options, such as using GPS for a user outside a building and a wireless AP connection for a user inside a building. Whichever option is followed, the server side 200 obtains position data providing the location of the mobile computing device and such position data can then be exploited to provide location-based services as disclosed herein, for example, to support a user following an itinerary.

The provision of such location-based services further involves data communications between the client side 100, in particular mobile computing device 112, and the server side 200. These further data communications may be performed using signals 121 transmitted over the mobile telephone (cell phone) network (of which only base station 120 is shown in Figure 1), for example, based on 4G and/or 5G data connections, and/or by using a Wi-Fi link if available via a wireless AP (not shown in Figure 1). Accordingly, any suitable data communication link (or combinations thereof) may be used to support the location-based services disclosed herein.

In some cases, a user may utilise functionality provided by vehicle 110 to supplement the mobile computing device 1 12. For example, many vehicles include ‘infotainment’ systems. The mobile computing device 1 12 may connect to such a system, for example via Bluetooth pairing. The mobile computing device 112 is then able to use the speakers of the system for audio output (the vehicle 110 is typically equipped with larger and more powerful speakers than mobile computing device 1 12). Similarly, the infotainment system of the vehicle 1 10 may have a screen which is larger than that of the mobile computing device 112, and visual output from the mobile computing device 112 may therefore be routed for display on this screen. In addition, the infotainment system may allow a user to enter commands for controlling the location-based services provided through the mobile computing device 112. Such user commands might be entered via the screen of the infotainment system (if this is a touch-screen), and/or by using physical input devices such as buttons available in the vehicle. Accordingly, the infotainment system may interact with the mobile computing device 112 to provide at least some input/output functionality for the user interface of the location-based services described herein.

The vehicle 1 10 may support other functionality relevant to the location-based services, such as receiving and utilising a GPS signal (and/or other positioning information). In some implementations this positioning information may be provided to the mobile computing device 112, for example to supplement the positioning information received directly by the mobile computing device as described above.

Since vehicles are generally being provided with increasing computational power and functionality, it is further contemplated that some or all of the functionality of client 112 with respect to the location-based services disclosed herein may potentially be implemented directly by the vehicle 110. In one such configuration, the vehicle 110 may not only receive GPS signals 102 but also report them server side 200 (using some communication link available to the vehicle 1 10, e.g., via base station 120). The vehicle may also exchange data communications 121 with the base station 120 and provide a user interface to support the location-based services. Accordingly, the computing system in the vehicle 110 may potentially act as the mobile computing device 1 12 to perform the location-based functionality disclosed herein. In other cases, the computing system of the vehicle 110 may supplement (rather than replace) the mobile computing device 112. For example, the latter may be retained for use by user 111 when away from the vehicle 110.

Although Figure 1 shows the user 11 1 travelling in vehicle 1 10, a different mode of transport may be employed for at least part of the itinerary. For example, a user may walk, cycle, motorcycle, canoe, etc, or travel by bus, tram, train, taxi, or metro (subway) when following the itinerary (or use any other any other suitable form of locomotion). It will be appreciated that the particular mode of transport may be selected by the user 111 according to factors such as weather, distance, traffic, availability of different services, and so on. Figure 2 is a high-level schematic diagram of an example of a server side 200 for use in a method of providing location-based services as disclosed herein. The server side 200 includes a cloud 220 containing multiple servers S230A, S230E3, S230C (collectively server 230) and a load balancing system 232. The server 230 is linked to database 210 and also has a communication link 270 to the client side 100. The server-side 200 further comprises control system 260, a push communications system 255, and an interface 250 to a separate mapping system (not shown in Figure 2).

The communications link 270 with the client side 100 is provided over any suitable and available network, for example, by using data services over a mobile telephone (cell phone) network including base station 120. In other cases, the communications link may involve the mobile computing device 112 linking to a wireless AP (not shown in Figure 1) for data services, instead of (or in addition to) using a link via a mobile telephone network. Data communications over link 270 are typically performed based on the Internet Protocol (IP) and may also be based, for example, on the use of the hypertext transfer protocol (HTTP). Other forms of data communication between the server side and the client side will be apparent to the skilled person.

The cloud computing network 220 incorporates a set of computing devices (resources) on which service providers are able to run applications and services. Accordingly, the cloud computing network 220 and servers S230A, S230E3 and S230C host applications (programs) to implement the desired processing and functionality of the location-based services described herein. The use of a cloud computing 220 environment provides service providers with greater flexibility and scalability (compared with a situation in which a service provider has to invest in and maintain their own hardware infrastructure). In a current implementation, the server side 200 has been implemented using the Amazon web services cloud computing environment 220, but any other suitable cloud computing environment or infrastructure could be utilised, such as Microsoft Azure or Google Cloud. In other cases, some or all of the server capability for providing the location-based services described herein may be owned or directly operated by the service provider (rather than being hosted by a cloud computing environment operated by a third party). Accordingly, the configuration shown in Figure 2 is provided by way of example only, and other configurations or architectures may be used in other implementations according to the particular circumstances of such other implementations.

The cloud computing infrastructure 220 of Figure 2 is typically based on a virtual configuration. Thus servers S230A, S230E3 and S230C are generally virtual servers implemented within a virtual environment provided by one or more underlying physical hardware systems. The use of such virtualisation has a number of advantages, such as greater flexibility and scalability, including the rapid provisioning of additional virtual servers (if required). It will be appreciated therefore that while Figure 2 shows the use of three servers S230A, S230E3 and S230C for providing the location-based services described herein, this is by way of illustration only. Any given system for providing such services may utilise fewer or more servers, and the number of servers utilised by any given system or installation may vary with time, according to the current loading on the server installation.

Figure 2 also shows a load balancer 232 as part of the cloud infrastructure. The load balancer may act as a front end to the servers S230A, S230E3 and S230C. For example, when a user requests an itinerary, the load balancer 232 may forward the request to whichever of servers S230A, S230E3 and S230C is currently the least heavily loaded. After this initial allocation has been performed, the client may communicate directly with relevant server (without having to go through the load balancer 232).

The skilled person will be aware that the configuration shown in Figure 2 for the load balancer 232 is by way of example, and other configurations are available. In some implementations, the load balancing functionality may be incorporated into one or more of servers S230A, S230E3 and S230C (rather than being provided as a standalone system). For example, the servers S230A, S230E3 and S230C may communicate between themselves to determine which server is currently most lightly loaded. When a new request is sent from a client, the request is received by all three servers, but only actioned by the server which is currently most lightly loaded. Other implementations may avoid having load balancing per se - for example, if one of the servers is more heavily loaded, then this server may be allocated more hardware resources from the virtual environment, or an additional virtual server brought on-line (rather than trying to shift part of the load to one or more other servers). Accordingly, the load balancing unit 232 shown in Figure 2 may be omitted from some implementations (or configured in a different manner from that shown in Figure 2).

The server side 200 of Figure 2 further includes a database 210 for storing data relevant to the provision of location-based services as described herein. Examples of data held by database 210 include itineraries and associated material such as playlists (as described below); user information; usage data, indicating how users have interacted with the itineraries; financial and charging information; and so on.

In some systems, the database may store user profile data including (without limitation) user address, user friends or contacts within the service provider system, user interests/preferences, such as music, history, nature, specific movies or TV shows, sports, and so on, and usage data, such as itineraries followed, rating or ranking values for such itineraries and the included sites, time spent at the included sites and travelling between the sites, etc. The database may further store site and itinerary information including the features of interest (to match against user preferences), maps of sites, details of amenities available at a site (such as food outlets ortoilets), how busy a site is (which may potentially reflect a real-time condition), any special events occurring at a given site, and so on. Further information about data held within database 210 is provided below. Note that for some data relating to third parties, such as the opening times of sites, the database 210 may store a link to a third-party site which maintains this information instead of (or in addition to) local storage in database 210. The user data and the site/itinerary data are complementary in some respects. For example, the user preferences may be compared with features of a site or itinerary to determine whether or not a user is likely to enjoy or be interested in such a site or itinerary. In addition, the recorded usage information about which users have selected which itineraries and visited which sites and for how long is significant from both a user perspective and also a site/itinerary perspective, since it records information relevant both to the users and to the sites/itineraries, and the interaction therebetween.

In some implementations, various data may also be produced or collected by the client, mobile computing device 112. This data may be returned to the server 230 (or to any other appropriate server side 200 component) for saving into the database 210. Likewise, the client may access data from the database 210 for performing the location-based services described herein, either directly or via any appropriate server-side component 200.

The mobile computing device 112 may store at least some data locally relating to the location-based services. One reason for this may be to use storage on the mobile computing device 112 as a cache, for example to store images and other components which may have been received from server side 200 to assist in the fast loading of web pages, apps, etc in subsequent use of the location-based services. Another reason for local storage may be to save information about the current itinerary and progress thereon - for example, to allow the user 1 11 to continue following the current itinerary even if a connection to the server-side 200 is (temporarily) lost, such as the vehicle 110 travelling through an area of poor or no network coverage (e.g., outside the range of base station 120). If connectivity is interrupted in this manner between the client side 100 and the server side 200, the client may transmit data collected or obtained by the client to the server side 200 to update database 210 accordingly when connectivity is re-established.

The database 210 is shown in Figure 2 as located outside the cloud 220 - for example, it may be located on-site at the premises of the location-based service provider. However, in other cases, the database 210 may be located in part or in full within the cloud 220. A further possibility is that database 210 may be located as shown in Figure 2, but selected data from the database 210 may be cached within the cloud 220 for quicker access. Furthermore, while Figure 2 shows the database 210 as a single entity, database 210 may also represent multiple different storage systems. For example, database 210 might include one storage system to hold data about itineraries, and another (separate) storage system to hold user data. Accordingly, the skilled person will be aware that any appropriate configuration or combination of storage systems may be used for database 210 according to the particular circumstances and needs of any given implementation.

Figure 2 further shows a map interface (l/F) 250. In a current implementation, this component is used to link to mapping services provided by Mapbox although

the map l/F 250 could be adapted to work with other suppliers of mapping information if so desired, such as Google maps (see The

mapping l/F 250 allows the server side 200 to call the Mapbox API (or other mapping supplier) to access various mapping services, such as providing mapping for a given location, and/or routing and navigation instructions between two or more locations. Accordingly, the mapping l/F 250 may be used by the server 230 or any other server side 200 component as appropriate. The mapping information can be used for real-time monitoring of the progress of the clients in following an itinerary, for example such as shown by the Dashboard of Figure 14 (see below).

In some implementations, the mobile client device 112 may also display mapping information to the user 111 , for example a map of the local area, the current position of the vehicle 110 and client 1 12, and the location of the next site along the itinerary. In some cases, the mapping l/F 250 may be accessed by the client, namely mobile computing device 112, for example via the server 230 or other server side 200 component, to obtain mapping information for such a display. In other cases, the client may directly access the mapping service for the mapping information, whether through the server-side mapping l/F 250, and/or through a local implementation of the mapping l/F on the client. A further possibility is that a system within the vehicle 1 10 may have a separate facility to obtain mapping information.

The mapping and routing data received from the mapping service facilitates the locationbased services described herein, for example by allowing a user to navigate to a particular site which is part of an itinerary, or by guiding a user in travelling from one site to another site of the itinerary. The mapping data received from the mapping supplier may also include details of items located near to a given location - such items might (without limitation) be types of buildings or other structures, such as a church, windmill, roundabout or bridge; types of business, such as a factory or warehouse; recreational facilities, such as a park, forest trail or swimming pool; entertainment venues, such as a cinema (movie theatre), concert hall, restaurant or bar and so on. As described below, some of these items may correspond to sites in an itinerary.

Figure 2 further includes on the server side 200 a push communications system 255 which is used for sending messages to the client 112. These messages are regarded as push communications because they are initiated by the communications system 255 (rather than being a specific server reply to a corresponding prior client request). The push communications to the mobile computing device 112 may be implemented in any suitable manner, such as using emails, SMS (text) messaging, notifications, alerts, etc. The push communications system 255 is shown in Figure 2 as a separate component, but may, for example, be implemented in cloud 220, and may be partly or completely integrated into server 230, according to the details of any particular implementation.

In some cases, the push communications may be ancillary to the main data communications between the client 112 and the server 230 as a user 11 1 follows an itinerary. For example, a push communication might be used to inform the client of newly available itineraries, or to provide commercial or advertising messages, or to notify a first user 11 1 that they are in the same location as a second user. (In the latter case, the first and second users might already have some form of relationship within the system, such as a friend or contact connection, or this may be suggested by the system as a potential new connection based on a compatibility analysis performed by the system).

Advertising messages can include advertising relevant products to the user 111 at the appropriate time. For example, if a tour itinerary includes the location “Whisky A Go Go” and the content presented includes a story about a well-known musician - such as Slash, the lead guitar player in the band Guns N’ Roses - then at an appropriate time whilst at this location, the push communications system 255 can inform the user 11 1 of other itineraries which they may be interested in, such as a Slash experience tour. The user 1 11 may also be presented with a link to book the tour immediately but then save the itinerary for following at a later date, or they may save the suggested tour in a “wish list” for purchasing at a later time.

Commercial messages can include providing recommendations to the user upon receiving a request for information. For example, if a user 111 indicates that they are hungry, the push communications system 255 can inform the user of nearby cafes and restaurants which they might enjoy. The recommendations can be based on user preferences, interests, and personality type information (which can be maintained as part of the user’s profile), venue tags (such as type of food served and the atmosphere within the venue), time of day, reviews from users with similar preferences/personality types, and/or specific search terms. For example, if the user is an extroverted type, enjoys Italian food, and it is early afternoon, a nearby live music cafe that offers pizza may be recommended. In another example, if the user is introverted, likes Chinese food, and it is early evening, a nearby Chinese restaurant which has a more relaxed/quieter atmosphere may be recommended. In yet another example, the user may search generally for nearby Indian restaurants, and all Indian restaurants within a defined radius may be presented to the user. The user may then be offered the option to filter/sort the results based on various different tags (such as atmosphere type) to receive more personalised recommendations.

In some implementations, establishments can pay to be recommended to users in response to a request for information (e.g., for a fee, the establishment will be prioritised in the list of general and/or personalised results presented to the user). If the user selects a restaurant they would like to visit, Artificial Intelligence (Al) applications can be utilised to make a call to a booking API linked to the restaurant to check availability and book the user a table.

Figure 2 further shows a control system 260 for managing the server side 200. The control system is shown in Figure 2 as a single unit (e.g., computer), but may comprise multiple control systems, for example with different control systems being associated with different aspects of the server-side components and operations. The control system 260 may be used, for example, to configure, manage and maintain the operation of server 230, database 210 and other server-side components. The control system 260 may also be used to develop, configure, manage and/or maintain the location-based services available from the server side 200 - for example to upload new itineraries to the server 230 for access and use by user 111 . The control system may also be used to support the real-time behaviour of the location-based services disclosed herein - for example, if a particular site in an itinerary becomes unavailable, such as due to bad weather, flooding, staff illness, etc, the control system may update the itinerary to temporarily remove the site from the itinerary (and potentially to replace the site with an alternative if available). The control system may be further used as a help facility to assist users 11 1 should any issue arise in relation to the location-based services - for example, if a given itinerary does not load properly into a mobile computing device 112. It will be appreciated that the above examples are merely illustrative of the role and usage of the control system 260, and the skilled person will be aware of many other potential aspects and operations of the control system 260 to assist in providing the location-based services described herein.

Figure 3 is a high-level schematic diagram of an example of a client (mobile computing device 1 12) for use on the client side 100 such as shown in Figure 1 . The mobile computing device 112 may be implemented, for example, as a smartphone, tablet or laptop, and includes a processor 310 for executing program instructions (software), primarily the operating system 330 which is typically preinstalled on the client device at the time of delivery, and a set of apps (applications) 320, which may be installed later, e.g., by downloading from a server, according to user interests. The processor 310 may comprise multiple cores, and may be supplemented by other processing capability (not shown in Figure 3) within the mobile computing device, such as a graphical processing unit (GPU). The operating system 330 runs on the processor to manage general operation of the mobile computing device 112; well-known examples of a suitable operating system 330 are Android, provided by Google, and iOS from Apple.

The client further includes a user interface 340 which comprises a set of hardware input/output devices, such as a touch screen, one or more buttons, a speaker, and a microphone, etc, together with the software to operate such devices. The operating system usually provides generic user interface functionality to exploit the hardware, for example, to support display windows that can be presented on a screen, and/or to provide voice recognition to allow spoken controls and other user input to be provided through the microphone. The apps 320 are then able to use and customise this generic user interface to support the specific operations of the app - for example, to specify the particular contents of each window, and the various options or outcomes that can be selected with respect to the functionality provided by an app (in the present case, for providing the location-based services).

The client further includes memory 350 and storage 360. The memory 350 is volatile (the contents are lost when the mobile computing device is powered down) whereas the storage 360 is non-volatile (the contents are preserved when the mobile computing device is powered down). The client software (operating system 330 and apps 320) is typically saved in storage 360 but copied to memory 350 for execution by the processor 310. Typically the memory 350 provides faster data access but has a lower data storage capacity compared to the storage 360. In many devices, the memory 350 is provided as random access memory (RAM), while the storage 360 is provided as a solid state drive (also known as ROM) and/or a hard disk drive. It will be appreciated that some memory functionality may also be provided by processor 310, for example, the processor may include one or more levels of cache to provide fast access by the processor to data held therein.

As shown in Figure 3, the mobile computing device 1 12 further includes three interfaces (l/Fs): one interface 370 for interacting with the mobile telephone (cell phone) network, one interface 380 for interacting with a data (computing) communications network, and one interface 390 for interacting with the GPS system. Note that the GPS interface 390 is typically receive only, while the other two interfaces 370, 380 have both send and receive capabilities. The GPS interface 390 includes functionality to determine the current location of the mobile computing device 112 as described above, whereby this location can then be passed to the server side 200 to support the provision of location-based services.

The mobile telephony interface 370 and the data communications interface 380 both support the exchange of data relating to the location-based services between the client 112 and the server side 200. The difference between the interfaces 370, 380 reflects the network infrastructure that they utilise - the telephony interface 370 connects to the mobile telephone (cell phone) network, e.g., via base station 120, to link to the server side 200, while the data communications network interface 380 typically connects to a wireless AP and then links to the server side 200 via the local area network (LAN) of the AP and then one or more wide area networks (WANs) as appropriate. The client may further support other computer-based wireless connections, such as Bluetooth, which might be used (for example) to link to the infotainment system of vehicle 1 10 as described above.

Although the underlying network infrastructure may vary between use of the telephone interface 370 and use of the data communications network interface 380, at a higher level, the same communications protocol (e.g., TCP/IP) may be used over both networks. Accordingly, in some cases, it may be (largely) transparent to the application 320 whether the client is currently linked to the server side 200 by telephone interface 370 and/or by data communications network interface 380.

The (virtual) server 230 may have an architecture which is similar to that of the mobile computing device 112 shown in Figure 3, for example, based on a processor, operating system, applications, memory and storage. However, the server may lack a user interface comparable to the user interface 340 of the mobile computing device 1 12 because the client itself allows the user 111 to input into and to receive output from the server 230. In some cases, the control system 260 may provide a user interface to allow an operator to configure, manage and maintain the server. In some cases, the server 230 itself may provide a form of user interface to allow the operator to perform such tasks - note, however, that such a user interface would primarily be used by the operator of server 230 (rather than by the user 111 of mobile computing device 112). In addition, although the server 230 will generally be able to access and employ data communications with the client over both of the two network infrastructures mentioned above (telephony and data communications), the interface to these networks may be provided generally for the cloud 220 (rather than being specifically incorporated into each server 230). This may allow, for example, the network interfaces to be utilised (shared) by many different servers in the cloud. Note also that the network interface available to and used by the server 230 may not necessarily match that used by the client 112. For example, the client 112 may connect to the telephone network using interface 370 (for example, because no Wi-Fi is available at the current location of the client). However, the server 230 at the other end of this link may interface to a data communications network (not to the telephone network). This is feasible because as noted above, both networks may utilise the same higher-level protocol, such as TCP/IP, for data communications, and at a lower level, some interface connection is provided within the relevant networks to allow the telephony network and the data communications network to exchange messages.

The location-based services described herein are provided in a current implementation using an app which is referred to as Bounce. This app is installed as application software 320 on the client mobile computing device 112, with corresponding server software installed on the server 230. Accordingly, the overall functionality of the Bounce system is provided by the combination of the app 320 on the client and complementary server software running on the server 230. Participants in the Bounce app are sometimes referred to as “Bouncers”, and hence participation in the app, such as by following an itinerary, is sometimes referred to as “Bouncing”. The Bounce app may derive revenue from at least one of the following: presenting advertisements (which may be location specific and relevant to the user whilst following the itinerary); charging establishments to have their venues prioritised in lists of recommendations as described above; charging a user subscription for access to the functionality of the Bounce app; charging for access to particular components (e.g. tours, as described in more detail below) provided by the Bounce app, for example for individual games or expeditions.

Various aspects of the Bounce app will now be described. In particular, the focus will be primarily on those aspects of the Bounce app which are most significant for the provision of location-based services. Other aspects of the Bounce app that have lesser relevance to the provision of location-based services as described herein may be omitted for conciseness. Furthermore, it will be appreciated that the Bounce app is provided as an example implementation of the location-based services, and other implementations of these services may be created by the skilled person based on the teachings herein.

Figure 4 is a schematic representation of a high-level menu for the Bounce app, whereby the user 1 11 is able to choose between the following three main options:

NOW - this option allows the selection of a tour which is appropriate to the particular situation and interests of the user, and provides guidance to the user in following the tour. PLAY - this option provides access to one or more location-based games, each game being associated with following an itinerary.

ME - this option supports various interactions between the user 111 and the Bounce app for a range of purposes, including account management, social networking, and the creation of personalised tours.

For ease of understanding, Figure 4 just shows the 3 menu options above. This display may be supplemented in some implementations by other materials relevant to the options. For example, each option may be accompanied by images relating to content that can be accessed via that option - e.g., the GAME options may be supplemented by pictures of characters from an available game. In some implementations, certain options for a tour or game may be directly accessible from the menu screen of Figure 4; this might be especially useful for highlighting new, popular, and/or specially featured products.

The three options above are all based on providing a tour for a user. Under the PLAY option, the tour is formatted as a game, and will be referred to as a game tour. Under the NOW option, the tour is formatted generally as a sight-seeing or experience seeking trip, and will be referred to as an experience tour. Under the ME option, the user is able to create a personalised tour which likewise is formatted generally as a sight-seeing or experience seeking trip, and will again be referred to as an experience tour.

Each tour is based on an itinerary and a playlist (script). The playlist comprises a set of content items, for example, images, audio segments, user input prompts, video segments, augmented reality views, video game segments, and so on, as well as flow controls to be applied to such the content items. For example, the playlist specifies where, when, and how such content items are presented to a user:

*where - the playlist specifies that the various content items are to be presented to a user at corresponding locations (sites) within the itinerary.

*when - the playlist specifies (inter alia) whether or in what circumstances a content item is to be presented to a user at the corresponding location. For example, in a game tour, a user might have to perform a particular task or answer a particular question at a given location before the content item is presented to the user.

*how - the playlist specifies properties such as transitions into and out of a piece of content (e.g., audio or video might be faded in and/or out), and whether audio from any other content element should be muted or reduced in volume when this content element is presented.

In some cases, a particular content item from a playlist might only be presented to the user in appropriate circumstances. For example, the system may be aware of the current weather conditions at a given location (e.g., from a third-party weather information supplier). If the weather is known to be foggy, the system might not play a content item relating to distant views which would only be visible from the location in better meteorological conditions. Although the Bounce app distinguishes between game tours and experience tours, all tours are implemented as above based on an itinerary and a playlist. Thus, the distinction between game tours and experience tours primarily represents differences in the type of content items and the flow control specified in the playlist. Accordingly, there is no sharp dividing line between games and experiences; and it is possible to create hybrid playlists which combine aspects of both games and experiences if so desired.

Figures 5A, 5B and 5C are examples of screens that a user may receive in response to selecting the NOW option from the screen of Figure 4. The screen of Figure 5A may define the area (in this case, Los Angeles) or areas for which the user may select an experience tour. In some cases, the area may be presented automatically by the Bounce app based on the current location of the user 1 11 ; in other cases, the area might be set to a default, e.g., based on the home address of the user, and/or a user might enter a particular area of interest.

If a user accepts the area specified, the app progresses to the screen of Figure 5A. This screen offers an experience tour (Bounce) relating to “The Rocky Tour Experience”, which is available for pre-order in this example (meaning the experience will be available at a future date, but the user can purchase the tour now and save it to their playlist to follow when the tour becomes available). In other implementations, a selection of experience tours may be offered which are immediately available to follow. For example, a first itinerary may comprise sites relating to the Pride movement, and a second itinerary may explore Silver Lake, a neighbourhood of Los Angeles which (according to Wikipedia) is “the center of the alternative and indie rock scene in Los Angeles”. Other tour options may be accessed by selecting the appropriate menu option or button (not shown in Figure 5A).

The lower portion of the screen shown in Figure 5B provides a facility to link to other users (“Bouncers”) of the Bounce app. This represents a form of social networking based on the Bounce app, which is described further below.

Figure 5C illustrates an example screen obtained by following an experience tour (Bounce) after selecting the NOW option of Figure 4. The top portion of the screen in Figure 5C shows a map of the current user location (such as might be obtained from the Mapping interface 250) with directions to the next site in the itinerary (in this example, the next location is immediately on the user’s right-hand side). The lower portion of the screen in Figure 5C allows the user to access information relating to this site (in this example, the Philadelphia Museum of Art). This additional material might include, for example and without limitation, a short audio or video presentation providing an introduction to the site, historical and/or safety information relating to the site, a map of the site, a suggested path through the site, information about amenities at the site (e.g., food outlets, toilets) and so on. In some cases, some of this material may be provided by linking to a website or other source of material about the relevant site.

Figures 6A, 6B and 6C are examples of screens that a user may receive in response to selecting the PLAY option from the screen of Figure 4. Figure 6A shows a featured game which is available for selection by a user 111 (in this example, the game relates to “The Pink Panther and the Case of the Missing Diamond”). The featured game may be selected by the system according to one or more criteria, such as being currently the most popular selection, a major new release, or a game that is popular among other similar users - i.e., other users who share similar interests, personalities, and/or other characteristics with the present user 111 .

The user may select to play the featured game of Figure 6A or may transition (e.g., by scrolling) to access the screen of Figure 6E3 which presents multiple games for selection by the user 1 11. At least some of these games are location-based, hence presenting, and executing such a game tour within the Bounce app represents a location-based service for the user. For example, the game “Hollywood: Rise to Fame” may be based on an itinerary around Los Angeles visiting locations associated with famous movie stars, movie sets, and so on. However, rather than presenting the itinerary in the form of an experience tour (as for the NOW option from Figure 4), a game tour is provided - for example, involving quiz questions relating to different sites in the itinerary, resolving location-specific cryptic clues in order to progress to the next site, fighting off zombies in a video game segment, and so on.

Figure 6C is an example of a further screen which shows various property settings available for a game in Bounce in accordance with a current implementation. In particular, the following property settings are available from the screen of Figure 6C:

NUMBER OF PLAYERS - this game is showing as being configured for single player usage. In some cases, a game may support multiple participants playing the game at the same time and competing against each other in respect of their individual scores. In other cases, a game may support multiple participants working together as a team, whether playing against other individuals or teams, or against the game itself.

EXPECTED DURATION - the expected duration of the game is given as four hours. This estimated timing allows the participants to determine whether the game is appropriate for the time they have available.

NUMBER OF LOCATIONS - the game tour (or itinerary for the game) incorporates four locations (sites). This information gives the participants an idea of the complexity of the game and the potential amount of travelling as part of the itinerary.

ADDITIONAL FEATURES - these can represent additional aspects of the game that make it attractive to users, such as the inclusion of sound effects and augmented reality within the game.

It will be appreciated that the above listing of properties or settings is presented by way of example, and other implementations may include additional settings or properties (and may not necessarily use all of the above settings). Without limitation, examples of possible properties or settings include an age-appropriate setting in relation to difficulty and/or content, and/or mode of transport according to whether the itinerary is car-based or whether the sites on the itinerary can be accessed by walking, tram, etc. In some cases, a game may be linked to a franchise such as for a movie, a television show, a computer video game, a sports team, etc, whereby the itinerary may follow sites that are relevant to the particular franchise - for example, the itinerary may visit locations used in a television show. The content and presentation of the game may then be linked to this franchise. For example, audio instructions may be voiced by one or more characters from the show and/or the presentation of the game may utilise visual and graphical elements consistent with the franchise. The skilled person will be aware of other ways in which the game may be linked to or exploit an associated franchise.

Figures 7A and 7E3 are schematic representations of screens that a user may receive in response to selecting the ME option from the screen of Figure 4. The ME option typically involves more personalised interactions with the Bounce app compared with the NOW and PLAY options. In other words, the tours from the NOW and PLAY options are generally predefined and curated, typically to be followed “as is” by a user (although in some cases, a certain degree of user customisation may be available). In contrast, the experience tour for the ME option is generally created for a given user in a bespoke fashion.

Figures 7A and 7B illustrate one such interaction which provides the user with the option to create their own Bounce (ME experience tour). In contrast with the NOW option of Figures 5A-5C, which typically involve the selection of a pre-existing tour, the option of Figures 7A and 7B may generate a new tour or customise an existing tour to reflect the particular interests, preferences, personality type, etc for that specific user. These interests, preferences, and/or personality types, are maintained as part of a user account (profile) as described below. For example, a user might indicate an interest in subjects such as nature, music, history, etc, while preferences might relate to sites on the tour being inside or outside, price level (if there is a charge for such a tour) and so on. Note that such a user-specific tour, once created via the ME option, will have a generally similar structure to an experience tour as described above for the NOW option, in other words, it will be based on the combination of a playlist and an itinerary.

Figures 8A, 8B, 8C and 8D are schematic representations of further example screens that a user may receive in response to selecting the ME option from the screen of Figure 4. These screens represent various aspects of the Bounce app, such as a facility for users to create (or import) friend connections, analogous to other social networking applications. The social networking aspect of the Bounce app may be referred to as “Bounce Connections”. In particular, Figure 8A shows friends of the user who has selected the ME option (the screen may be scrolled to review the full listing of friends if appropriate). The user can select one or more friends from this listing and invite them to join the tour which the user is creating. This operation sends a notification to the selected friends who can then accept or decline the invitation as appropriate.

The user may also have the option to share their experiences via the Bounce app, such as by posting updates to their Bounce profile (updates can include text, photographs, video, audio, location tags, etc...) and setting the post to be private (visible only to connections) or public (visible to all users), The Bounce app can also be linked to other social media platforms which the user subscribes to, thereby allowing the user to share their updates across a variety of platforms simultaneously.

The user can also share ratings and reviews for each location, immediately after visiting that location or at a later time (e.g., after the tour has ended). The Bounce app can use these ratings and/or reviews to modify the current ME experience, and/or to curate future Bounce ME experience tours for the user (either by having more or fewer locations of a similar type), and/or to curate or personalise tours for other users (for example, many negative reviews or ratings for a particular location may lead to that location being removed from existing or future curated or personalised tours across all Bounce users).

Figure 8B illustrates a Bounce screen which allows a user to configure the estimated duration of the tour (Bounce) that the Bounce app will create for the user. The system can then create a new tour or personalise an existing tour to match this estimated duration, for example, based on the number of sites included in the itinerary, the estimated travel time between sites, and the estimated time visiting the site. The estimated travel time may be based on current locationspecific data, for example, real-time or recent traffic conditions which may be available via the Map l/F 250 or from any other appropriate source. The estimated duration at each site may be based, for example on information recorded in database 210, and may include (without limitation) one or more of the following factors:

*the duration of previous visits to that site by all Bounce users

*the duration of previous visits to that site by Bounce users who have a similar profile (e.g., tastes, interests, etc) to the present user who is creating the tour

*the duration of previous visits by the present user to other site (this factor might be limited to other sites which are similar to the present site of interest).

The skilled person will understand that many other options are available, and the exact approach adopted to estimate duration may also be dependent on the data available for the user and/or for the site. For example, if the present user is relatively new to the Bounce app, then the estimated duration might be based mainly on previous visits to the site by other Bounce users with a similar profile to the present user. On the other hand, if the site itself is new to the Bounce app, then the estimated duration might be based mainly on previous visits (by the present Bounce user and/or other Bounce users) to other sites which are similar in nature and scale to the new site.

Figure 8C illustrates a Bounce screen which allows a user to specify whether the tour (Bounce) should start at the current user location (such as might be determined by the GPS interface 390) or from some other location. The latter option might be appropriate, for example, if the user would like to pick up a friend prior to starting the tour or would like the tour to focus on an area outside their immediate neighbourhood.

Figure 8D illustrates a Bounce screen which allows a user to specify whether or not the tour (Bounce) should be based on user preferences (a user profile), which may be stored, for example, in database 210. Thus, a user profile might indicate a preference for a tour based on certain properties or interests, such as history or nature, scenic country roads or city roads, and so on, and the Bounce app is able to create or customise a tour in accordance with these preferences. The screen of Figure 8D also allows a user to request a tour which is not based on their particular profile or preferences, for example, because the user would like a new experience and/or a change from their previous tours.

Figures 9A and 9B are schematic representations of example screens which are presented to a user as part of the Bounce login and account creation procedures. If the user is already registered, they can enter their sign-in information to obtain access to the Bounce app 320 and may progress, for example, to the menu options of Figure 4. However, if the user has not previously registered with the Bounce app, the user can select the “sign-up” option of Figure 9A. The screen of Figure 9A represents a conventional sign-up screen requesting an email (or username), an associated password, date of birth, and gender. The user’s date of birth and gender may be optional information, such that the user can still proceed to register an account without this information. Other information may additionally be requested, either on a mandatory or optional basis. Note that the username and/or password may be stored securely within the mobile computing device 112, in which case the device may complete these fields automatically during sign-in based on the stored information without the user having to repeat their entry.

As part of the registration of the new user, the Bounce app may not only obtain standard information (such as address, age, and so on), but may also present one or more questions such as shown in Figure 9B, which asks the user to select a cake that corresponds to their personality (other questions can include selecting dances that correspond to the user’s personality). This type of question helps to elucidate various personality aspects of the new user, which can be saved to a user profile (such as stored in database 210). This initial information can subsequently be supplemented by further personality aspects, whether obtained from direct requests, such as shown in Figure 9B, or from observations of user behaviour, such as their rating of various sites or itineraries. The personality information may be used, for example, to help select orgenerate a tour that is suitable for a user, particularly after selecting the ME option from the screen of Figure 4. Matching a site or itinerary to a particular personality type may be done directly, for example, a site which offers white water rafting might be attractive to an adventurous personality type, or indirectly, for example, by finding sites for a given user that have been popular with other users having the same personality type as the given user.

To facilitate such matching of personality to itineraries ortours (and to any other aspects of Bounce), in a current implementation, a user profile stores personality information in a hierarchical (tree) structure. In one implementation, which employs a version of the Myers Briggs personality test, the topmost node of the tree presents four pairs of alternatives:

Extrovert (E) v Introvert (I)

Sensors (S) v Intuitives (N) Thinkers (T) v Feelers (F)

Judges (J) v Perceivers (P)

There are 16 (2⁴) possible outcomes from selecting one alternative from each pair, these sixteen options correspond to different personality types.

At the next level down in the hierarchy, four options are available, namely Diplomat, Analyst, Explorer, and Sentinel. The combination of the personality category and a selected one of the above four options is used to define personality type (which is a lower level classification than personality category). For example, a combination of Introvert, Intuitive, Feeler and Perceiver (INFP) together with Diplomat results in a personality type of Mediator, while a combination of Introvert, Intuitive, Thinker and Judge (INTJ) together with Analyst results in a personality type of Architect. It will be appreciated that there exist many other methods for assessing a user’s personality type, and the above Myers-Briggs type test is only one example that can be implemented within the Bounce app. In some implementation, a combination of methods can be used to assess a user’s overall personality type. The use of such personality types and categories provides a more quantitative mechanism for the Bounce app to utilise and exploit personality information when providing the location-based services described herein, for example in terms of suggesting tours, making friend recommendations, etc, that are well-suited to a given user who has a particular personality.

Figure 10 is a schematic overview of an example for providing some of the location-based services described herein. The left-hand portion of Figure 10 shows content and processing available to the client 112; the right-hand portion of Figure 10 shows content and processing performed by the server side 200 (backend), for example by server 230, database 210 and control system 260.

The portion of the user account (profile) which is visible to the user comprises various preferences, booking information (e.g., tours that have previously been selected by the user), and various presentation format options, such as colour schemes, etc, which can be customised for each user. As part of the registration procedure, a welcome ‘interview’ is performed, for example by using one or more questions such as shown in Figure 9B as discussed above. The results from this interview are used to provide the initial user preferences and colour scheme. The user preferences may then be updated based on further user engagement with Bounce - for example, the tours that are created for or selected by the user, and the experience on such tours. Accordingly, over time the stored preferences become increasingly personalised and relevant to the user by learning from past user behaviour.

The server-side portion of the user account contains more detailed preference information, including sub-preferences, as well as personality type as discussed above. The server-side portion also stores additional booking and transactional data, for example relating to payment history, and detailed behavioural data obtained forthe user as part of tour engagement, such as the user ratings for different tours, whether any tour content is skipped, time spent at individual sites, and so on (such as depicted in Figure 10). The server-side user account further stores information about CYOTs (“create your own tour”), i.e., tours generated specifically for or by that user. It will be appreciated that the configuration and data processing illustrated in Figure 10 is provided by way of example only, and other implementations may adopt a different configuration and/or different processing.

Figure 10A is a schematic diagram providing an example of how the location-based services may be personalised for a user. Such personalisation is particularly significant with respect to the ME option, but the PLAY and NOW options may also support some degree of personalisation or customisation. Furthermore, other implementations may support differing levels of personalisation according to the particular requirements for such other implementations.

The left-hand side of Figure 10A shows three types of user data that are collected by the server side 200 and typically stored in database 210, namely preferences indicated by the user, behavioural data for the user (e.g., which options and tours a user has selected, etc), and personality type as discussed above. The central portion of Figure 10A shows three types of material within the Bounce application which may be influenced (customised) based on the available user data, namely look and feel (e.g., colour schemes), featured experiences - i.e., which particular tours are highlighted such as in Figure 6B, and content for developing a Bounce ME tour (see Figures 7A-B and 8A-D). Note that in Figure 10A, the personality type is shown as the only influence on the look and feel, and also the personality type has no influence apart from on the look and feel. However, in other implementations, the personality may influence other types of material (such as Bounce ME content), and similarly, the look and feel might be influenced by other factors (such as user preferences).

The right-hand portion of Figure 10A gives more examples of how the Bounce ME content can be updated, for example by changing the sites (locations) included in a tour based on reviews of similar sites. In some cases, a machine-learning/artificial intelligence (Al) system may be employed to review the incoming data (from the left-hand side of Figure 10A) and to assess changes in settings, contents, etc as per the right-hand side of Figure 10A.

The user’s preferences, behaviour data, and/or personality type, can be used to identify locations and content that the user is likely to enjoy. This can be done by matching location tags with the user’s profile data. For example, the user’s profile may indicate that they enjoy rock music, and their favourite band is Metallica. The Al system can then identify locations having relevant tags, such as “music”, “rock” and/or “metal”. In addition, the ratings and reviews left by other users with similar preferences, behaviour data, and/or personality type, may also be considered to help decide if a particular location and associated content is likely to be well received by the current user. The Al system then curates a completely personalised experience for the user within the location and length of time parameters defined by the user in Figures 8B and 8C.

Once the personalised tour has been created, the user can then begin to follow the itinerary. After each location visited, the user may have the option to rate their experience at that location. In some implementations, the Bounce app may prompt the user to rate their experience, and optionally leave some comments which can be seen by other users and/or the app developers. For example, the user may be invited to give a star rating, with one star representing a bad experience and five stars representing a great experience, and also a reason for giving that rating.

If the user indicates that they had a bad experience at a location or simply just did not enjoy it (as indicated by leaving 1 or 2 stars), the Al system will identify any similar locations and/or content later in the tour (for example, by reviewing the associated tags) and will adjust the tour to reduce those locations and/or content, and/or replace them with alternative locations and/or content.

If the user indicates that they were indifferent about a location (as indicated by leaving 3 stars), then no adjustments are made to upcoming locations or content, and the tour continues as planned. However, if the user indicates that they had a great experience at a location (as indicated by leaving 4 or 5 stars), the Al system will identify any similar locations and/or content later in the tour (for example, by reviewing the associated tags) and will adjust the tour to include more locations of a similar nature.

The Bounce ME tour experience is therefore completely personalised and can be dynamically modified in real-time based on user feedback. To allow such dynamic modifications, the tour is typically stored on the server side, in the cloud 220 or database 210, and only segments/portions of the tour are preloaded into a buffer on the client device 1 12 at any one time (which may be referred to as “buffering”). For example, only the content associated with the immediate next location on the itinerary may be preloaded onto the client device 112, such that the content can be triggered and presented to the user 1 11 when the pre-defined conditions are satisfied (such as GPS location). As such, it is typically not possible to adjust the immediate next location in the itinerary if it has already been buffered or is in the process of buffering, however, locations later in the itinerary can be adjusted prior to buffering.

The curated tours from the NOW and PLAY options are also stored in the cloud 220 or database 210, with only segments of the tour preloaded onto the client device 112 at any one time. This allows a degree of customisation of upcoming locations in the tour, such as to remove a location if a traffic delay means that a site would not now be reached prior to closing, or to replace a location with a different one if the planned location has become too busy and queuing times would now prevent the tour from being completed in the allotted time. In some cases, the user may or may not be given the option to reject the modification.

The Bounce Al system can also communicate with the user’s preferred music streaming service via Application Programming Interfaces (APIs) to further personalise the user experience in the ME option. For example, the Al system can identify the “genre” from the upcoming location and content tags and then using APIs can search the user’s linked audio service provider for tracks with matching genre tags. For example, if the upcoming location and content has been tagged with the genre “rock”, the APIs will attempt to identify any audio tracks in the user’s library and/or saved playlists with matching tags, such as “Metallica”. The identified audio tracks can then be played as the user is travelling to the upcoming location to provide a more immersive experience. If no audio tracks are found with matching tags, or if the upcoming location and content does not have an associated “genre” tag, then any audio tracks saved to the user’s library and/or playlists can be randomised and played to the user as they travel between locations.

As mentioned above, the look and feel of the Bounce app interface can be customised based (at least in part) on the user’s personality type. This involves adjusting the colour scheme, themes, and other visuals displayed, to be better suited to the user’s personality. For example, an extroverted type might prefer bold and bright colours, whereas an introverted type might prefer more muted and pastel colours.

The tone of the content can also be modified based (at least in part) on the user’s personality type. This can include push notifications and other general messages to the user, as well as the content specific to each location in the tour. The type of language used when delivering the content, along with the presentation style, can be adjusted to suit the user. For example, more rebellious personality types may prefer more informal and brazen language, whereas more reserved personality types may prefer the information presented in a more factual and formal way.

In some implementations, the information presented to the user at each location may also be adjusted based on preferences. For example, if an upcoming location in the tour is a music venue, such as the Whisky A Go Go, and the user’s profile suggests they like Motley Crue, then a story about Motley Crue’s antics at the Whisky A Go Go may be presented; whereas if another user’s profile suggests they prefer Guns N’ Roses, then a story about Guns N’ Roses’ antics at the Whisky A Go Go may be presented instead. The Al system can determine a user’s music tastes via information stored in the user’s Bounce profile, and/or by making an API call to their preferred audio service provider to request information about the user’s preferences. Based on the information received, the information presented can be adjusted to better reflect the user’s preferences.

Figure 1 1 is a schematic diagram of two example processing flows for launching the location-based services described herein, especially in relation to existing tours such as provided by the NOW or PLAY selections from the menu of Figure 4. The left-hand portion of Figure 11 represents the “sign-up” processing with reference to Figure 9A. After the welcome page, the user progresses through a welcome animation/tutorial to a main feature page. In some cases, the main feature page may correspond to the menu shown in Figure 4, but populated with additional options for choosing between various tours. In other cases, the menu of Figure 4 may sit between the welcome animation/tutorial and the main feature page, whereby the latter enables a user to select between various features (tours) for the option (NOW or PLAY) chosen from the menu of Figure 4. The user can then select a desired feature, namely an experience tour such as illustrated in Figure 5A, or a game tour such as illustrated in Figure 6B. The user then creates an account (which typically includes responding to a personality quiz or interview, such as shown in Figure 9B), makes a suitable payment as required, and is then able to begin the selected tour. The left-hand portion of Figure 11 also illustrates some other functionality available in the Bounce app, such as saving a selected feature (tour) as a favourite, e.g., with a view to following this tour at a later date or adding to a playlist.

The right-hand portion of Figure 1 1 represents the processing performed with respect to an existing user who opens the Bounce app via a login page. The user then receives a welcome notification which may include a recommendation for a given feature (tour) and which can be directly selected by the user. The recommendation may be based on user preferences, new releases, positive ratings from other users, and so on. The selected feature may be saved as a favourite or launched (subject to any required payment) in a similar manner to that illustrated in the left-hand portion of Figure 11 and described above for the new user (except that for an existing account holder, the step of creating an account is omitted).

Figure 12 is a schematic diagram of two example processing flows for launching a locationbased service as described herein, especially in relation to the creation of a customised or personalised feature (experience tour) as discussed above with respect to the ME option from Figure 4. The processing flows of Figure 12 are similar in most respects to those of Figure 11 , with the left-hand portion of Figure 12 again corresponding to a new user and the right-hand portion corresponding to an existing user. In both cases, the main processing flow includes “selected CYOT”, where CYOT is an abbreviation for “Create Your Own Tour”. Accordingly, these two CYOT portions of Figure 12 (one for the new user, one for the existing user) represent the user creating their own (ME) tour as described above in relation to Figures 7A-7B and 8A-8D. Further aspects of the processing shown in Figure 12 generally correspond to those of the processing shown in Figure 11 and discussed above, hence for conciseness the description of these further aspects will not be repeated.

Figure 13 is a schematic diagram of an example of an administration (admin) portal login page for use with the server-side system shown in Figure 2. The admin portal may be provided, for example, by one or more control systems 260 such as shown in Figure 2. The admin portal provides four options for administrators who are logged into the system, namely Dashboard, Analytics, Tour Location and Content Creator. The Dashboard option, as described below in more details with reference to Figure 14, illustrates the current status of the system, typically providing real-time information on aspects such as number of users, system response times, server usage, and so on. The Analytics option generally analyses previously acquired information to better understand the operation of the Bounce app, the overall provision of services, the actions of users in selecting and following tours, etc. The Analytics option may therefore be used to process and review the usage data held in database 210 to provide information on (for example, and without limitation): which tours are the most/least popular; which types of users (in terms of personality) make the most use of the Bounce app; and whether the server 230 provides quick and reliable interaction with the client 112. The Tour Locations option in Figure 13 provides a facility for working with the tours stored in the Bounce system, for example, for adding new tours to the system or for maintaining and upgrading existing tours. The Content Creator option allows for the development or provision of content, such as videos, sound effects, and so on, which can be incorporated into one or more playlists to provide an enhanced user experience.

Figure 14 is a schematic diagram showing in more detail an example of the Dashboard from the admin portal of Figure 13. Such a Dashboard may be implemented for example on control system 260 to provide information on the current status of users 111 participating in the Bounce App, as well as information about the status of the Bounce App and any other relevant data. The left-hand portion of Figure 14 shows the actual Dashboard, while the right-hand portion of Figure 14 lists various activities that may be performed or managed using the Dashboard.

The Dashboard itself shows a mapping area with participants (subscribers) indicated by cars which are travelling to sites, the latter being indicated by balloon symbols (markers). The map shown on the Dashboard may be obtained (for example) using the Mapping interface 250 depicted in Figure 2. The positions of the sites (as indicated by the balloon symbols) can then be superimposed on the map based on knowledge of the respective itinerary being followed by each client. The current position of each active client (as indicated by the cars) can be plotted based on received position information for the clients, which can then be used to monitor the progress of the clients along their respective itineraries. This position information may be supplied to the control system 260 by the client 112 themselves and/or the position information may be received from an alternative source, such as the mobile telephone (cell phone) network.

Further information about a given participant can be accessed by clicking on the associated car symbol. The example in Figure 14 shows a box obtained in this manner presenting the subscriber’s name and contact details, plus the start time and expected finish time for the subscriber (the box shown in Figure 14 does not have the actual details completed). A bar on the right-hand portion of the map provides summary information about the active tours - in this particular case, 82 tours are indicated as active, and 9 are paused for some reason (e.g., the participants might be having a food stop). Other summary information can include cancelled tours, and first timers who have not previously used the Bounce app to follow a tour, and hence might be most likely to need administrator assistance. The lower portion of the Dashboard provides an ongoing plot of how the above numbers of tours change with time as various subscribers start or finish a given tour. This plot also includes future subscribers, for example, people who have paid for this tour, but have not yet initiated the start of the tour. (Note that the plot in the lower portion of Figure 14 is schematic only, and is not intended to correspond directly to the situation illustrated in the top portion of Figure 14).

Figure 14A is a schematic diagram providing an example of a high-level screen for content creation which may be accessed from the administration portal shown in Figure 13. The far-left portion of Figure 14A provides a listing of options that may be of interest to a developer working with the Bounce application - such as a list of available tours (Bounces), a list of available users, a list of cities in which tours are available, and so on. A developer can select the appropriate option as desired to access the relevant information and/or functionality.

The next column labelled HOME in Figure 14A is limited to three main options, namely tour creator, adding locations (sites) and a listing of all tours (Bounces). Note that these three options are also available from the far-left portion of the screen of Figure 14A, but they are featured in the HOME column for ease of finding and selection, since these are the three options of primary interest to a developer working with the Bounce application. The column of options to the immediate right of the HOME column mirrors the column of options shown to the left of the HOME column.

The right-hand portion of Figure 14A presents a facility for creating a tour (assuming that this option has been selected from the HOME column, or from one of the two other columns). The user is able to enter high-level information about the tour, such as the title (name), location, type of tour (in the example shown, PLAY, i.e., a game), genre information, cost, duration and so on.

Figure 15 is a schematic diagram of an example screen for use by a developer in creating a playlist for a tour, for example, the playlist for the tour which is initially created by the screen shown in Figure 14A. The playlist (script) in effect controls the processing and output of the Bounce app as the user follows a given itinerary. The playlist includes aspects such as audio and/or video output to the user, decision points for a user (including buttons for the user to activate), and so on. It will be appreciated that Figure 15 is provided by way of example, and the skilled person will be aware of other suitable ways and tools for creating playlists.

The top-left portion of Figure 15 contains general information about the tour, such as the title (name) of the tour, the city forthe tour, the genre, duration, and so on (this information has not yet been entered by the developer). The remainder of Figure 15 illustrates the creation of a playlist which is formed from a series of items. The right-hand portion of Figure 15 shows the sequence of items so far included in the playlist, while the lower left-hand portion of Figure 15 shows a facility for creating new items to append to the sequence shown in the right-hand portion.

As shown in the lower-left portion, each item has content, such as video, audio, text, or augmented reality; zero, one or more overlays, such as a button for user input, a timer, etc; and one or more triggers, such as GPS location, GPS speed, audio, button, and so on. The above content items may also be given a name (as per the left-hand column of the table in the right-hand portion of Figure 15).

The triggers are based on some value, action, or result. For example, if the trigger is specified as a GPS location, this trigger might be activated if the user 1 11 (more particularly client 112) arrives at this location; if the trigger is specified as audio, the trigger might be activated a certain time after this audio has completed playing; or if the trigger is specified as a button, which is provided as an overlay in conjunction with the timer, the trigger might be activated if the button is pressed by a user before the timer expires. The flow table in the right-hand portion of Figure 15 contains an example of a playlist that is under development. The playlist contains a sequence of items contained in lines of the playlist. The first line represents an introduction and comprises audio/visual content which is played in response to a GPS trigger, which may be specified to activate, for example, when the mobile device arrives at a predetermined location. The next line in the playlist also includes audio-visual content, which may relate to the location. This line specifies an overlay which seeks input from the user. Playing of the audio-visual content may be triggered according to the user input received by the overlay. Accordingly, a relatively complex and detailed playlist may be created for a tour by using the content and the triggers shown in Figure 15.

Figure 16 is a schematic diagram of an example screen for use by a developer in creating an item for a tour where the item is based on a GPS trigger. Thus, the screen shown in Figure 15 identifies various types of triggers (such as a GPS location), and the screen shown in Figure 16 then allows a developer to specify the condition(s) for that trigger to be activated. In particular, Figure 16 is used when the trigger is based on GPS information, namely a location or a speed. Thus, for operation, a client 112 obtains its GPS location (and speed) such as by using GPS interface 390 shown in Figure 3 and then tests whether the condition to activate the trigger is satisfied.

In the example of Figure 16, the trigger is based on GPS location (rather than GPS speed), and the developer is able to specify the trigger condition by way of an address or x-y coordinates (e.g., longitude and latitude), or alternatively by dragging a marker onto a map. The condition for the trigger is satisfied when the GPS location obtained for the client matches the address/x-y coordinates/marked map position as specified by the developer. The right-hand portion of Figure 16 provides further control over the response when the GPS location satisfies the trigger condition. In the example of Figure 16, the action (content such as audio and/or video) associated with the trigger is to start playing 30 seconds after the end of the previous content.

Figure 17 is a schematic diagram of an example screen for use by a developer in providing location information for a tour in accordance with a current implementation. In particular, the location information in Figure 17 relates to a particular site, namely the Whisky a Go Go, a famous Los Angeles bar and music venue. The top-left of Figure 17 provides general information about this site (such as name and address), while the bottom-left portion of Figure 17 lists various tags associated with this site. For example, under genre, the tags listed are Rock, History and Entertainment. Accordingly, if a tour is being created relating to music history (whether for use by multiple users under the NOW option, or for a single user under the ME option), this site may be identified based on searching for suitable tags - such as rock and history. Once the location (site) has been identified based on one or more matching tags, a developer (or itinerary generation tool) may decide whether or not to include the location in the tour.

The right-hand portion of Figure 17 provides two sets of content associated with this site (Whisky a Go Go). The first set of content is additional information in the form of text, while the second set of content is A/V (audio-visual). Both sets of content are triggered by a user pressing a (touch-screen) button. There may be a separate button for each set of content (so that the two sets of content can be individually launched), or there may be a single button which launches both sets of content together. The button (or buttons) may be provided as an overlay with respect to any content previously presented by client 112. Accordingly, the location content shown in Figure 17 can be incorporated into a tour playlist based on using the GPS position and these buttons as triggers. Figure 28 shows one implementation, whereby the content is displayed on a client device 112 as part of a personalised tour experience after selecting the Bounce ME option of Figure 4. In this example, the content related to the La Brea Tar Pits was uploaded using the interface in Figure 17. The top figure shows the title of the location, followed by some audio content, which may be triggered by pressing the play button. The audio content may be a spoken version of the written content underneath, or it may be additional content which expands upon the written content. The audio and written content are accompanied by visual pictures on the right-hand side, which may be directly linked to the audio and/or written information. In some implementations, the visual information may be designed to complement the audio and/or written information, or alternatively it may present different information relating to that location.

Figure 18 is a schematic diagram showing an example of the structure or configuration of different components within a tour playlist, namely Triggers, Events, Moments, and Elements. As previously described, Triggers have one or more conditions associated therewith, and are activated when such conditions are satisfied - e.g., when a client 112 arrives at specified a location. When a trigger is activated, it can be used to start or stop Events. Events are collections of Moments that may be triggered within an event, for example, based on current GPS location. Each Moment includes a collection of one or more Elements that can interact and layer with each other to create presentations for or interactions with users. The Elements are small (short) pieces of content or functionality, such as photos, music, buttons, etc, that reside in Moments.

Thus, with reference to Figure 15 (which adopts a slightly different architecture compared with Figure 18), the combination of a Trigger and corresponding Event shown in Figure 18 may be regarded as an item in the playlist, while the content and overlays shown in Figure 15 can be regarded as Elements that are grouped together into Moments. Note that different Moments within an Event may occur at different times, for example, the start of one Moment may be delayed with respect to the start of another Moment. Likewise, different Elements within a Moment may occur at different times, for example, the start of one Element may be delayed with respect to the start of another Element. Accordingly, a developer can create a playlist having a relatively complex timeline of content and actions from the different Elements starting at various times.

Figure 19 is a schematic diagram showing an example of an interface for adding an Element (such as shown in Figure 18) into the system so that the Element becomes available for inclusion in Events within a playlist. The interface allows a developer to specify various aspects of the Element, such as: its form - e.g., audio/visual or button; whether any other audio playing should be reduced while this Element is played; and any applied transition, such as fading in or out at the beginning or end of the Element. The Element can then be uploaded into the overall system (for example, into server 230 or database 210), from where the Element can be accessed or utilised by various playlists.

Figure 20 is a schematic diagram showing examples of an interface for adding a Trigger to the service provider system, wherein a Trigger is one of the components from Figure 18. (Note that Figure 20 represents alternative examples of an interface for adding a Trigger compared with that shown in Figure 16; aspects of these two different interfaces may be combined as appropriate in any given implementation).

The interface of Figure 20 allows a Trigger to be defined such that an Event commences based on the location of the user 111 or on the time since the conclusion of a previous Event (except the latter option is not available for the first Event in a tour, since in this case there is no previous Event). For a location-based Trigger, the interface allows a developer to specify whether the Trigger is activated on arriving at or departing from a given location, and also to specify a distance from the exact location at which the Trigger is activated (similar functionality may be added to the screen of Figure 16 if so desired). For a time-based Trigger, the interface allows a developer to specify whether the Trigger is activated on arriving at or departing from a given location, and also to specify an amount of time from the exact location at which the Trigger is activated (similar functionality may be added to the screen of Figure 16 if so desired).

Figure 20A is a schematic diagram showing examples of an interface for a developer to add an Event to a tour playlist, an Event being another one of the components illustrated in Figure 18. Such an Event may be added from an existing library (“Quick Add”), or a new Event may be added by hand (“Manual Add”). In the latter case the Event may specified as having an image or video to play at a given location (defined for example as an address/intersection and/or using latitude and longitude). Thus, typically as included in a playlist such as illustrated in Figure 15, a Trigger will be provided to activate (trigger) when the location of the user matches the location specified in the Event, and in response to such activation, specified audio and/or video (or image) content is displayed to the user.

As described above with reference to Figure 18, the audio/visual content is generally provided by one or more Elements which are included within a Moment, and each Moment is then included within an Event that is activated by the trigger. Figure 20E3 is a schematic diagram showing an example of an interface, in particular an Event editor for specifying this content (Moments and Elements) for a newly created Event such as shown in Figure 20A. The top-right portion of the Event editor includes a button for adding a Moment to the event, such as the Moment entitled “Adrian and Paulie’s House Approach Montage and URL”. This Moment then contains a set of Elements as shown below, namely an A/V element, a Button element, another A/V element, a URL element, and another Button element. These Elements may be previously created and saved into the system such as by using the screen interface shown in Figure 19 and are then available to insert into the desired Moment(s) using the interface of Figure 20E3.

As described above, various examples of a computer-implemented method are disclosed herein for providing a location-based service to one or more mobile client devices. The method, which may generally be implemented server-side 200, comprises downloading or streaming (or preload ing/buffering), a location-based tour, or a segment thereof, to a mobile client device, the tour comprising a playlist for following an itinerary, the itinerary comprising an ordered (and frequently predefined) set of sites. The playlist includes a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item on the mobile client device.

In some implementations, the majority of the tour playlist will remain on the cloud 220 or database 210 on the server-side 200 and is streamed or preloaded to the client device 1 12. The content items for the immediate next location are streamed or preloaded to the client device 112 prior to the user arriving at the location, so that they can be presented to the user once the appropriate trigger conditions are satisfied. The content items can be stored in a buffer (temporary memory) on the client device 1 12 until they are triggered. In some implementations, once the user has finished at a location, the content items are removed from the buffer and the content items for the next location are preloaded into the buffer. The next location in the tour and the associated content can therefore be decided prior to the user starting their journey to that location, and it cannot be changed once buffering has begun.

The mobile client device is configured to receive position information indicating a current location of the mobile client device, and at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information. The method further comprises receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary. Such monitoring may be performed, for example, by control system 260 and/or by server 230, and may be used for various purposes, such as assisting users in the case of unexpected problems (e.g., long traffic delays on the planned itinerary), and helping to ensure adherence to licensing terms (see below).

As described herein, a content item may include, for example, at least one of a video, an audio signal, an image, text, augmented reality, or any combination thereof. Furthermore, a content item may include an overlay comprising at least one of a button, a timer, a question posed to the user of the mobile device or any combination thereof. At least one of the triggers may comprise a condition that is satisfied dependent on a user pressing a button, a user answering a posed question, or a combination thereof (potentially before the expiry of a time period on the timer, if set). Accordingly, the playlist can provide a real-time, interactive experience for a user.

In some cases, the condition that is satisfied dependent on the current location of the mobile device is satisfied when the current location of the mobile client device is within a predefined distance of a position specified in the playlist and/or when the current location of the mobile client device indicates that the mobile client device is arriving at or leaving a position specified in the playlist. Options such as these provide the developer with a greater range of control over the user experience which can therefore be tailored more precisely to the particular details of the sites being visited.

In some cases, a remaining travel time from the current location of the mobile client device to a site specified in the playlist (or to within a given distance of such a site) is estimated. Such an estimate may be based, for example, by estimating an average speed from GPS (or other) location data over a prior time period, and extrapolating this travel speed forwards until the position specified in the playlist is attained. In other cases, the estimated remaining travel time may be provided by the Map interface 250 or other external sources.

The estimated remaining travel time may be used as a trigger for playing a content item, e.g., an introductory video, relating to the forthcoming (given) site. For example, if the content item is of duration Vt minutes, then the playlist may start playing this video Vt minutes prior to the expected (estimated or predicted) arrival of the user at the given site (plus possibly a little extra leeway), so that the end of the introductory video will coincide with arrival at the given site.

An example of this approach is illustrated in the flowchart of Figure 21 , in which operation 2110 involves estimating a current position of the client, and operation 2120 involves estimating a remaining time T minutes until the client arrives at the given site. As described above, this estimate of the remaining time may be made within the Bounce app or obtained from an external source such as by using Map l/F 250. At operation 2130, a test is performed to determine whether T-V(t) < 6, in which V(t) is a time for playing content (e.g., a video) relating to the given site and 6 is a threshold representing a margin of error or leeway for showing the video. If the time remaining is still significantly larger than the video duration (i.e., T-Vt > 6) then no action is taken at this stage. Rather processing returns to operation 2120 to make a further estimate of the remaining travel time. As the user 11 1 continues towards the given site, T will steadily reduce, hence the inequality T-V(t) < 6 will eventually be satisfied. This inequality can be considered as representing a condition for triggering the audio and/or video to be played at operation 2140. The timing of playing the video should now lead to the end of the video coinciding (approximately) with the arrival of the user at the given site.

In some cases, the tour comprises a game in which at least one of the triggers comprises a condition that is satisfied dependent on an interaction between the playlist and a user. For example, this interaction may comprise the user pressing a button defined in the playlist, a user answering a question defined in the playlist, or a combination thereof.

In some cases, a playlist may be created in which locations are defined generically as location types, typically in terms of features such as a park, lake, church with tower, movie theatre, railroad level crossing, hill, town square, cave, and so on. If a user is located in a particular region, then the Bounce app tries to identify corresponding features which are also located in the region of the user. The resulting specific locations which are local to the user can now be incorporated into the playlist in place of the generic location types, hence the playlist is now converted from a generic playlist to a specific (directly usable) playlist. Such conversion is typically performed server side 200 prior to the specific playlist being downloaded, such as preloaded, to a client. Note that this conversion only needs to be performed once for any given region, since subsequent users in the same region may re-use the same specific playlist created for the first user in that region. The specific playlist once created may therefore be stored, for example in database 210 (along with other tours and associated playlists).

This approach of creating a generic (location agnostic) version of the playlist which is then subsequently converted to a specific playlist for use in a particular region allows the game to be played more easily by users spread across many geographical regions. In addition, users who enjoy the game may be encouraged to play the game in different regions, since each region will provide a different experience based on the different set of mappings used for any given region. Generic locations may also be used even within a single area, for example if certain locations in a playlist are found to be very busy. In this case, multiple different specific mappings may be created all within the same area, thereby helping to avoid overcrowding at any given location within a specific mapping.

An example of this approach is illustrated in the flowchart of Figure 22, in which a playlist having generic locations is initially received at operation 2210. A determination is then made at operation 2220 of the region where the game is going to be played, and the generic locations are then mapped at operation 2230 to specific locations in this region (assuming that no set of specific mappings has already been created for this region). The playlist with the specific locations is then downloaded, such as by preloading segments thereof (buffering), to the client device 112 to allow the user to start playing the game at operation 2240.

Once a specific tour has been created, it can be made available in multiple destinations by associating it with a Tier, which allows the developer to create or modify a destination list. Before a tour can be made available in a particular destination, the individual location criteria (location type) and the distance/time between locations must be reviewed, and an assessment made as to whether or not it is even possible to make the tour available in that destination. For example, the tour “The Pink Panther and the Case of the Missing Diamond” requires certain locations to be available in a requested destination, such as a bank, a museum, a hotel, and a cafe serving French pastries. If the locations available in a requested destination satisfy the criteria, then the tour will become available at that destination. Otherwise, the destination will not be considered valid, and the tour will not made available.

A location list for each destination can be made available in a number of ways. For example, the mapping l/F 250 on the server side 250 can call the API of a mapping supplier to access a list of locations at a particular destination. Artificial Intelligence (Al) tools can then be used to organise the information about each location (such as location type), assess appropriate tags/genres, and determine appropriate locations for the tour based on the criteria set. Locations can also be made available via individual upload (as per Figure 17) or bulk upload by the developer. The bulk upload option will now be described in more detail.

Figure 24 is a schematic diagram showing an example of an interface for adding locations in bulk for a tour playlist in accordance with one implementation, and Figure 24A is a schematic diagram showing an example of an interface for reviewing the uploaded locations. The bulk upload option is preferable when a large number of locations need to be added to the database 210. The developer can organise the required information about each location into a spreadsheet (such as title, address, type, GPS co-ordinates, state, and city), and then save the spreadsheet in the required format (such as ,xls or .xlsx) before importing into the Bounce app. The spreadsheet may include locations specific to a single city, or across multiple cities. A suitable spreadsheet template can be downloaded first to assist the developer with organising and categorising the required information. The spreadsheet can then be uploaded into the Bounce app by dragging and dropping the file from the appropriate location on the developers computing device (for example, from a folder located in the non-volatile memory, such as on the hard disk drive) and into the defined location on the interface.

The developer can then roll-out tours in multiple different cities using the Tiers option, as shown in Figures 25 - 27. A Tier is an operational process for automatically creating and launching a tour playlist in multiple different cities, as compared to creating and launching each individual tour manually (which can become time consuming). This process will now be described in more detail. In some implementations, if a tour has been particularly successful in one city, the developers can choose to roll it out across other cities, including cities where users have specifically requested it be made available. As shown in Figure 25, selecting the Tiers option from the left-hand column, brings up an interface where the developer can view existing tiers and is given the option to “Add New Tier”. This takes the developer to a new screen to enter a name for the tier, as shown in Figure 26. In this example, the name information has not yet been filled in, but the tier could be named “The Pink Panther and the Case of the Missing Diamond”.

The developer can then select multiple states and cities where the tour is to be made available. For example, Figure 26A shows that Alaska has been selected as a required state, but no city has been selected yet. Once a state has been selected, the city drop-down menu is automatically populated with the cities in that state which are available in the database 210. States can also be other countries, such as Australia, as shown in Figure 26A.

Each city in the list is then validated, by assessing if the location type criteria is met by attempting to match the location types required to actual instances within the city, and then assessing if the distance or time to travel between the actual instances is below a threshold value. If both criteria are satisfied, then the city is considered a valid destination for rolling out the tour.

The developer can then select “Tour List” from the left-hand menu and view the new tier under the draft category. As can be seen in Figure 27, right clicking on the three dots to the right- hand side of the tier brings up the option to “Rollout” the tour to each of the cities specified. Selecting the rollout option brings up a new interface as shown in Figure 27A. The data fields have not yet been populated with information. However, selecting a tier from the drop-down menu (e.g., "The Pink Panther and the Case of the Missing Diamond”) will bring up a list of cities in the bottom left of the interface where the tour is to be made available. For each city, the developer can set a launch date and an expiration date. For example, the “The Pink Panther and the Case of the Missing Diamond” may be launched to coincide with the release of a Pink Panther movie, or it may be made available to celebrate an anniversary related to the franchise (in which case, it may be available for many months or a whole year). The launch and expiration date can be different for different cities.

Returning now to the Tour List screen, as shown in Figure 27E3, each individual city where the tour has been made available is listed as a separate entry along with the launch/start date. The Tiers option allows the developer to generate the same tour easily and quickly across multiple locations, but once generated, each tour can be managed separately from the others.

In some cases, receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary comprises: (i) receiving position information for first and second mobile client devices; and (ii) determining from the received position information whether the first and second mobile client devices are located together in a single vehicle. Such a determination is useful from a licensing perspective, since different users in a single vehicle may be allowed to share a single subscription. However, this sharing is not intended to extend across multiple vehicles. Accordingly, if it is determined that first and second mobile client devices which are sharing a subscription are in different vehicles, appropriate remedial action may be taken. Such action may for example comprise sending a notification to the clients, or closing down operation of the playlist for any participants in one of the vehicles.

An example of this approach is illustrated in the flowchart of Figure 23, in which position information is received at operation 2310 for different participants sharing a subscription. A test is then made at operation 2320 as to whether the participants are travelling by vehicle (rather than being on foot). Such a determination can be based on the speed with which the participants are moving, and also potentially on the location of the participants - for example a freeway location might indicate that the participants are travelling by vehicle even if they are moving slowly at present. (In some cases, such location information might be retrieved using the Mapping l/F 250). If the participants are currently on foot, the processing ends, since the license recognises that participants may wander away from one another across a site while exploring on foot. (Note that if participants are found to be on foot at different sites, rather than all at a single site, that may again indicate a license breach, although this circumstance is not addressed in the processing of Figure 23).

If the participants are found to be travelling by vehicle at operation 2320, a test is now performed at operation 2330 to determine whether the participants are located close together, as would be expected if they are all travelling in the same vehicle. If is this indeed the case, the processing ends, since there is no indication of any licensing issue. However, if the participants do not appear to be located close to one another (based on the scale of a typical vehicle), this may indicate that they are sharing a subscription across separate vehicles. In this case, a remedial action, such as discussed above, may be performed at operation 2340 to protect the licensing position.

The approach disclosed herein may include maintaining information relating to the personality type of a user of the location-based service. If the user is interested in following a tour (whether for a game or an experience), the system may use this information regarding personality type to help determine which location-based tour to download, such as by preloading segments of the tour, to the mobile client device. In some cases, such a determination may be based on looking at the properties and content of a tour, and assessing how these would appeal to different personality types. The determination may also be based on looking at tours favoured by other subscribers who have the same or similar personality type as the present user.

In some cases, the system may hold information not only on the personality type (and category) of the user, which are relatively stable parameters, but also on the current mood of the user (which is more prone to time variation). Accordingly, a determination of which locationbased tour to download to the mobile client device may be based at least partly on the current mood of the user. A user may inform the Bounce app directly of their mood, and/or the system may infer the mood from interactions between the user and the Bounce app, as well as from other indicators, such as driving style (which can be ascertained in part from GPS data available to the Bounce app). In some implementations, if the user is travelling in a personal vehicle 110 between locations, the Al system can be used to make a call to the vehicle’s ‘infotainment’ system APIs, such as the API of a mapping supplier and/or the API of the sound system, to permit the travel directions and any associated audio content to be routed through the infotainment system instead of the mobile computing device 112.

In other implementations, the Al system can make a call to an appropriate booking API to arrange for a taxicab, or other vehicle provided by private or semi-private transport services, to arrive at a specific time and location to pick the user up and take them to the next location. In yet further implementations, the Al system can make a call to an appropriate booking API to arrange for an automated vehicle (such as a driverless car) to arrive at a specific time and location to pick the user up and take them to the next location via a specific route.

Also disclosed herein is a computer system configured to provide a location-based service to one or more mobile client devices. The computer system (typically a backend or server side system 200) includes at least one processor for executing program instructions configured to: download a location-based tour to a mobile client device, which may involve preloading a segment thereof (buffering), the tour comprising a playlist and an itinerary, the itinerary comprising an ordered set of sites, the playlist including a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item to the mobile client device, wherein the mobile client device is configured to receive positioning information indicating a current location of the mobile client device, and wherein at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device. The computing system is further configured to receive the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary.

Also disclosed herein is a mobile computing device configured to receive a location-based service. The mobile computing device includes at least one processor for executing program instructions which are configured to: receive a location-based tour (or a segment thereof) comprising a playlist and an itinerary, the itinerary comprising a (predefined) ordered set of sites, the playlist including a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item on the mobile client device. The program instructions are further configured to receive position information indicating a current location of the mobile client device, and to execute the playlist to activate at least one of the triggers comprising a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information.

In conclusion, the present disclosure provides a computer-implemented method and computer system for supporting location-based services as described herein. Also provided is a computer program comprising program (software) instructions that when executed on a computing system cause the computing system to perform such a method. The computer program may be provided on a suitable storage medium such as described below. A computer system described herein may therefore be implemented using a combination of hardware and software. The hardware (machine) may comprise a standard, general-purpose computing device, or in some implementations, the hardware (computing device or system) may include more specialised components, such as a graphics card, graphical processing units (GPUs) and so on to facilitate operation of the computer system providing the location-based services. The software generally comprises one or more computer programs to run on the hardware. These computer programs comprise program instructions which are typically loaded into memory of the computer system for execution by one or more processors to cause the computer system to operate as described herein. The computer program may be stored in a non-transitory medium prior to loading into memory, for example, on flash memory, a hard disk drive, etc. The operations of the computer system with respect to the location-based services may be performed sequentially and/or in parallel as appropriate for any given implementation.

Various implementations and examples have been disclosed herein. It will be appreciated that these implementations and examples are not intended to be exhaustive, and the skilled person will be aware of many potential variations and modifications of these implementations and examples that fall within the scope of the present disclosure. For example, certain implementations may comprise any appropriate combination of the features disclosed herein without limitation to the particular combinations provided by the claims. It will also be understood that features of particular implementations and examples can typically be incorporated into other implementations and examples (unless the context clearly indicates to the contrary). In summary, the various implementations and examples herein are disclosed by way of illustration rather than by way of limitation on the scope of the appended claims.

Claims

1 . A computer-implemented method of providing a location-based service to one or more mobile client devices, the method comprising: downloading a location-based tour to a mobile client device, the tour comprising a playlist and an itinerary, the itinerary comprising an ordered set of sites, the playlist including a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item via the mobile client device, wherein the mobile client device is configured to receive position information indicating a current location of the mobile client device, and wherein at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information; and receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary.

2. The method of claim 1 , wherein a content item includes at least one of a video, an audio signal, an image, text, augmented reality, or any combination thereof.

3. The method of claim 1 or 2, wherein a content item includes an overlay comprising at least one of a button, a timer, a question posed to the user of the mobile device or any combination thereof.

4. The method of claim 3, wherein at least one of the triggers comprises a condition that is satisfied dependent on a user pressing a button, a user answering a posed question, or a combination thereof.

5. The method of claim 3, wherein at least one of the triggers comprises a condition that is satisfied dependent on a user pressing a button, a user answering a posed question, or a combination thereof, prior to expiry of a time period on the timer.

6. The method of any preceding claim, wherein said condition that is satisfied dependent on the current location of the mobile device is satisfied when the current location of the mobile client device is within a predefined distance of a position specified in the playlist.

43

7. The method of any preceding claim, wherein said condition that is satisfied dependent on the current location of the mobile device is satisfied when the current location of the mobile client device indicates that the mobile client device is leaving a position specified in the playlist.

8. The method of any preceding claim, further comprising estimating a travel time from the current location of the mobile client device to a position specified in the playlist, and wherein said condition that is satisfied dependent on the current location of the mobile client device is satisfied when the estimated travel time to the position specified in the playlist is below a threshold value.

9. The method of claim 8, wherein said threshold value is set such that particular audio-visual content can complete playing to a user as the user arrives at the position specified in the playlist.

10. The method of any preceding claim, wherein the tour comprises a game in which at least one of the triggers comprises a condition that is satisfied dependent on an interaction between the playlist and a user.

11. The method of claim 10, wherein said interaction comprises the user pressing a button defined in the playlist, a user answering a question defined in the playlist, or a combination thereof.

12. The method of claim 10 or 11 , wherein the game defines multiple location types which are specified generically and mapped to actual instances of the location types, the actual instances having positions which are accessible to a user playing the game based on the current location of the mobile client device.

13. The method of any preceding claim, wherein the tour comprises actual instances of multiple location types at a first destination which are mapped to actual instances of the same location types at a second destination, the actual instances at the second destination being selected based on the distance or time to travel between the instances being below a threshold value.

14. The method of any preceding claim, wherein receiving the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary comprises: receiving position information for first and second mobile client devices over a period of time; determining from the received position information whether the first and second mobile client devices are located together in a single vehicle.

15. The method of any preceding claim, further comprising:

44 maintaining information relating to the personality type of a user of the location-based service; and determining a location-based tour to download to the mobile client device of the user, wherein said determination is dependent upon the personality type information for the user.

16. The method of claim 15, wherein the determination of a location-based tour to download to the mobile client device is based at least partly on a current mood of the user.

17. The method of any preceding claim, wherein a content item corresponds to an Event, each Event having a collection of Moments, and each Moment having a collection of Elements, wherein each Element comprises material for presentation to a user.

18. The method of claim 17, wherein the material for presentation to a user includes at least one of photos, music, video, images or buttons.

19. The method of any preceding claim, further comprising receiving user feedback on a first portion of the tour, and based on this feedback dynamically updating a second, subsequent portion of the tour.

20. The method of any preceding claim, wherein the step of downloading the location-based tour includes preloading segments of the tour to a buffer in the mobile client device.

21 . The method of claim 20, wherein preloading segments of the tour to a buffer in the mobile client device includes preloading the content items associated with the immediate next site on the itinerary, prior to the mobile client device arriving at the immediate next site.

22. A non-transitory medium storing a computer program comprising program instructions that when executed by a processor implement the method of any preceding claim.

23. A computer system configured to provide a location-based service to one or more mobile client devices, the computer system including at least one processor for executing program instructions configured to: download a location-based tour to a mobile client device, the tour comprising a playlist and an itinerary, the itinerary comprising an ordered set of sites, the playlist including a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item via the mobile client device, wherein the mobile client device is configured to receive position information indicating a current location of the

45 mobile client device, and wherein at least one of the triggers comprises a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information; and receive the current location of the mobile client device for monitoring progress of the mobile client device in following the itinerary.

24. A mobile computing device configured to receive a location-based service, the mobile computing device including at least one processor for executing program instructions configured to: receive a location-based tour comprising a playlist and an itinerary, the itinerary comprising an ordered set of sites, the playlist including a set of content items, a content item having one or more respective triggers, each trigger comprising at least one condition which must be satisfied to activate the trigger, whereby activation of the trigger causes the client to present or play the respective content item on the mobile client device; receive position information indicating a current location of the mobile client device; and execute the playlist to activate at least one of the triggers comprising a condition that is satisfied dependent on the current location of the mobile device indicated by the received position information.