FIELD

The invention relates to a method of acquiring data, specifically a method of acquiring data from an external source and providing such data to a mobile wireless communications device.

BACKGROUND

Mobile wireless communications devices often have functionality enabling them to connect to the internet when away from a wireless or "Wi-Fi" connection. This may be achieved by a 3G or 4G connection provided by a service provider. Such mobile wireless communications devices capable of accessing the internet via 3G and 4G connections include mobile phones and tablets, amongst others. Service providers limit the downloading of data from the internet via such connections by imposing a data limit which, once exceeded, prevents the further downloading of data.

When overseas and using a mobile wireless communications device configured to operate in a different country, service providers instead or additionally charge further costs for "international roaming", or, downloading data from the internet while overseas. The significant costs associated with roaming mean that internet use via a mobile wireless communications device while abroad is often extremely limited in the absence of a Wi-Fi connection.

There is therefore a desire for a method which minimises the problems associated with using mobile wireless communications devices abroad.

An invention is set out in the claims.

FIGURE LISTING

Embodiments will now be described, by way of example only, with respect to the appended figures, of which:

Figure 1 shows a flow diagram of a first phase relating to method of acquisition; Figure 2 shows a flow diagram of a second phase relating to retrieving data;

Figure 3 shows a flow diagram of a third phase relating to the processing of the retrieved data;

Figure 4 shows a flow diagram relating to requesting data associated with a selected first and second POI;

Figure 5 shows a flow diagram relating to requesting data associated with a selected third POI;

Figure 6 shows a flow diagram relating to requesting data associated with the selected first, second and third POI;

Figure 7 shows a flow diagram relating to requesting data associated with a selected fourth and subsequent POI.

OVERVIEW

The method of acquiring data at a mobile wireless communications device can be broken down into three phases. The first phase relates to data acquisition in which data is collected, analysed and stored in an intermediate server such as a database external to the mobile wireless communications device. The second phase relates to the retrieval at the mobile wireless communications device of data stored in the database based on selected criteria. The third phase relates to the processing of the retrieved data at the mobile wireless communications device.

DETAILED DESCRIPTION

The method of acquiring data will now be described in more detail with reference to the figures.

Figure 1 shows the data acquisition phase. At stage 102, the required data is identified based on a predetermined geographical area. For example, the required data may be data related to a specific city or country.

At step 104, data sources relating to the identified data are found by a remote server. This may be achieved by a systematic grid search of a distributed system, for example a systematic grid search for data contained in websites via the internet, by any conventional means as the skilled person would understand, in combination with filters, in order to find data sources that contain the identified data. The systematic grid search may be filtered based on a category of interest identified by the user, and may also be filtered based on the popularity of data sources containing the identified required data. The defining of data sources is performed by the remote server for example using a known technique of automatic web crawlers, as would be understood by one skilled in the art, in order to perform a systematic grid search of the internet to find the data identified by the user. Therefore, by filtering the systematic grid search, the total download size of any data sources found will be reduced, and the data sources found will be more relevant to the user.

When finding the data sources at step 104, the remote server will treat one data source as the primary data source to match any subsequently found data sources against. De-duplication may be performed by the remote server on the primary data source, as would be understood by one skilled in the art, in order to identify any matching records originating from the same primary data source. Therefore, the chance of duplicating matching records from a single source is minimised. The primary data source may be chosen in advance, at the beginning of step 104. Other data sources found by the web crawlers are individually de-duplicated by the remote server.

At step 106, the de-duplicated data sources, including the primary data source, are analysed at the remote server to find equivalent data present in different data sources. One method of analysing the data sources is via conventional record matching techniques. To achieve this, data sources are analysed by comparing various strings of each data source with other data sources. For example, name, address, coordinates, images or telephone numbers associated with each data source may be compared with other data sources. As would be understood by one skilled in the art, string s such as names and addresses are only matched approximately such that slight variations between names would still qualify as a match.

When data records are found to be matching, they can be said to form a "matched set". Information or data from the data sources within the matched set is combined. For example, one data source may only contain name information, and another data source may only contain address information and image information. The matched set, containing these data sources, therefore contains name, address and image information. The combination of information provided by data sources within the matched set forms a new record. When multiple data sources provide the same information, precedence rules may be used to define what information is taken from which data source, as would be understood by the skilled person.

At step 108, the server database is updated with the data records. The data records comprise entries in the database which are sorted by a score as determined by analysis of statistics from all source records contributing to the data record. For example, where the source records relate to a particular restaurant, review scores provided by each source record may be averaged and used to "score" the restaurant, and therefore score the data record. The database is indexed with a geohash, previously described, such that the coordinate elements for each data record in the database can be found quickly and efficiently. Images for each data record may be acquired during the formation of matched sets, as previously described, but alternatively images may only be acquired for those data records with a score exceeding a predetermined score threshold. By only acquiring images associated with data records that have a sufficient score, the unnecessary acquisition of images for all data records is avoided.

Figure 2 shows a method of retrieving, at the device, the data acquired according to the above method. The device can connect to the remote server in order to search for information contained in the server database. At step 202 a search area is defined by a geographical "point of search". The point of search may be manually chosen by a user operating the device, for example my selecting particular coordinates on a map, or may instead be a point centred on the coordinates of the user operating the device. The search area comprises a rectangular area centred on the point of search. The size of the rectangle may be automatically determined by the server based on the size of a map displayed on the device. The server also takes into account any zoom level for the displayed map, and therefore a smaller rectangular area is used when the map zoom is increased since the area of map displayed is reduced. The server can then define the size of the rectangular area by retrieving coordinate data sent from the device for diagonally opposite corners of the screen. Alternatively, the size of the rectangular area may be chosen by the user via the device. The rectangle therefore defines a search area within the vicinity of the user, or within the vicinity of a point of search not centred on the user. Optionally, at step 202, a filter may be used to constrain any results that come out of the search. The filter may be based on a particular category of interest defined by the user. Further optionally, automatically extractable metadata, for example the time of day and the weather, may further adjust the search results. The search results may therefore be constrained to indoor environments during unfavourable weather, for example. At step 204 the results of the search are acquired. This step may be performed using conventional methods of geohashing and string indexing. Alternatively, step 204 may be performed by linearly scanning the database from the highest score downwards until a predefined number of results have been found. The results found are constrained by the defined search area at step 202, and any optional filters or metadata.

At step 206, the scores of the search results found are adjusted by certain biases in order to improve the relevance of the acquired results. Such biases may depend on the time of day and the weather, for example. Further adjustment of the scores may be carried out in order to promote result diversity. For example, the category of each record in the list of acquired results is identified and results falling within that same category, but of a lower search score, will receive a negative bias to their score. This negative bias may increase for every subsequent search result found of a lower score and in the same category. Therefore the search result's position in the list of acquired results is adjusted such that the list favours placing results for records in different categories nearer the top.

At step 208 the search results are displayed as place-markers, images or icons on a map display on the user's device. Alternatively, the search results may be displayed in a list organised by score on the user's device. The user device may be any device external to the server, for example a mobile wireless communication device communicating over a wireless or satellite link to the server.

The third phase of processing of the retrieved data will now be discussed in relation to Figure 3. At step 302, a single result from the list of search results (displayed at step 208) falling within the search area is chosen by the user. The choosing of a single result may be via an interface provided by software on the user's device. The first chosen result may also be termed a first point of interest, or POL At step 304, data associated with the first POI is requested from the server. According to an embodiment, the request for data from the server comprises multiple individual requests:

A first request is made to retrieve all POI (all search results) within a threshold distance of the selected first POI. When this first request is received by the server, the server calculates an area encompassing the predetermined threshold distance from the first POI as a rectangular region, preferably a square region, centred on the first POI. The server then identifies POIs that are contained within that square region using a pre-calculated geohash. In order to pre-calculate the geohash, a look-up table is constructed as a list of all of the POIs that are located within a predetermined distance from each coordinate of a grid of coordinates. Each coordinate in the grid of coordinates may be spaced one hundred metres apart, for example. When all of the POIs within the square region are desired, each POI for each coordinate in the grid of coordinates which falls within the square region is added to the list.

A second request is made to retrieve all images associated with each POI within the square region. When the image for each POI has been identified, the images are packaged, by the server, for transmittal to the device. The images may be packaged as an uncompressed zip file for greater readability by software on the device. Alternatively, an image may not be retrieved and instead a default image available and already present on the device may instead be used.

A third request is made to retrieve the latitude and longitude coordinates for the square region defined by the threshold distance from the first POI on a map representation. This may be performed at the same time as the first request, therefore reducing the total number of requests by one. Only the corner coordinates of the square region need to be requested from the server in order to define the square region. Map tiles associated with the identified latitude and longitude coordinates, including a variety of different zoom levels and resolutions are retrieved. The latitude and longitude coordinates define the size of the square region to be used by an external map tile provider. Alternatively, the server itself may also be able to provide the map tiles without needing any external map tile provider.

Server data sent in response to each of these individual requests, including the map tiles, is received at the device and stored in the device database at step 306. The map tiles may alternatively be stored in an individual map tile database on the device. The stored data may therefore be used even when contact with the server is no longer desirable or possible. The data stored in the device database may be indexed to enable faster searching of the data, as would be understood by one skilled in the art.

Alternatively, at step 304 the device may instead request all of the data simultaneously in one single request. Further, the latitude and longitude coordinates may define a shape that is not a square, for example any other polygon or a circle centred on the first POI may be defined. Further alternatively, latitude and longitude coordinates may define a neighbourhood boundary for the square region, if the definition of such boundaries is available to the server. Figure 3 may terminate after step 306 by displaying representations of any of the data stored in the device database. The data to be displayed may be chosen by a user interaction with software on the device. For example, the user may be able to select to view, from the device database, the first POI and all associated POIs that are within the threshold distance of the first POI. The user may also be able to search or browse the device database for POIs that were retrieved at step 304. Any POIs found in this way may also be displayed on the device. An icon or generic image is used to display the selected or found POI at the associated coordinate by software on the device, using the map tiles obtained from the server or from an external map tile server. The displayed POIs may be individually selectable by the user. On the selection of a POI, further information including the associated image retrieved during the second request is displayed on the device.

If the method does not terminate at step 306, the method proceeds to step 308. At step 308, a second POI can be selected from the search results displayed on the device at step 208, or from any POIs displayed after step 306 as described above. The second POI may be chosen from the same list as the first POI. Alternatively, the second POI may instead be selected from a different set of data identified by the method shown in figure 1, for example the second POI may be chosen from a different list of displayed results that have been filtered at step 202 to display a different category of results.

At step 310, data associated with the selected first (if not already obtained) and second POIs is requested from the server, as described in further detail below. At step 312, data associated with the selected first and second POI s is received by the device and stored in the device database.

The step 310 of requesting data associated with a selected first and second POI will now be described in further detail in relation to Figure 4. After having received selections of the first and second POI from the device at step 308, at step 402 the server defines a path or "corridor" between the coordinates associated with the first POI and the coordinate associated with the second POI. According to the first embodiment, the corridor defines a straight-line path of predetermined width between the first POI and second POI. Alternatively, the user may be able to specify a preferred path from the first POI to the second POI, which may depend on transport/transit options between the two POIs and/or user preference as discussed below. The preferred path may therefore not be a straight-line path. The corridor may therefore instead define a non-linear path of width such that the user-preferred path is included within the corridor. At step 404, the path or corridor area is determined. The corridor area is determined using a series of rectangular areas with opposing sides of the rectangles being parallel to lines of latitude and longitude respectively. The size of each rectangle is such that the desired corridor width is achieved. For first and second POIs that share either a latitude or a longitude coordinate, in the case of a straight-line path the corridor may be a single rectangular area starting from the first POI and ending on the second POI. Alternatively, a corridor of rectangles may be arranged by adjacent placement of the rectangles in a horizontal or vertical line, starting from the first rectangle centred on the first POI, and ending on the last rectangle centred on the second POI. In both cases, the size of the rectangle(s) is such that the predetermined corridor width is achieved by using single or multiple rectangles of appropriate lengths and/or widths. In the more likely event that the first POI and second POI do not share either a latitude or longitude coordinate, the path between the first and second POIs will be diagonal. In this case, again rectangles may be placed between the coordinates of the first POI and the second POI. In order to achieve a corridor of predetermined width for a diagonal path, the rectangles will have to overlap with each other if the rectangles are to be positioned with sides parallel to latitude and longitude respectfully. Therefore, for first and second sets of POIs that do not share either latitude or longitude coordinates, the server determines the corridor area using a series of overlapping rectangles.

When a preferred path, instead of a straight-line path, is specified by the user, the corridor area is also determined using a series of rectangular areas. However, in this case, the corridor area may track with the preferred path such that a desired corridor width is achieved for each section of the non-linear path. Further, additional rectangular areas may be defined at specific locations along the path, such as at public transport stops or particular coordinates specified by the user.

The rectangles used to determine the corridor area are arranged with sides parallel to latitude and longitude respectfully for various reasons. First of all, by arranging rectangles in this way, the pre- calculated geohash which defines all the POIs within each square or rectangular region may be more easily determined. Further, external map tile providers generally work with rectangles which are aligned with latitude and longitude, and therefore by using the alignment of rectangles of the present method, greater compatibility is achieved with external map tile providers.

At step 406, the POIs, images and other data for each rectangle in the determined corridor area are provided to the device by the server. In the case of overlapping rectangular areas, the server only provides unique POI, images and other data to the device, and therefore any data found in an overlap of two rectangular areas, for example, is only provided to the device once. Alternatively, in order to avoid receiving duplicate data from the server for any of the steps of figure 4, the device may store a list of POI data already received and the server may provide a unique identifier for all POI data contained the server database, as would be understood by one skilled in the art.

The method then proceeds to step 312 of Figure 3, where the device stores the received data associated with the selected first and second POI in the device database.

In any of the embodiments above, the corridor area between two POIs could additionally or instead be determined using transit information. In a preferred embodiment, as part of step 402, transit information is retrieved by the server from a 3 ^rd party transit information service providing one or more route options between two places. The two places correspond to the chosen POIs. Route options returned by the 3 ^rd party transit information service might include one or more bus routes, underground routes, boat routes, cycle routes, walking routes or any transport route including a combination of these. The 3 ^rd party transit information service may be hosted on an external server.

The data provided to the device by the server at 406, which includes the POIs, images, map tile definitions and other data for the corridor area between the POIs, may also include additional data describing the route options. These route options are therefore stored locally on the device for later offline use.

In an embodiment, the route options could come from a local database stored on the device or on the server. The local database may include station locations and timetables, for example.

The time of day that a journey will be made may influence the available route options. The route options sent to the device by the server could be independent of the actual time of day that a chosen route option is to be taken by a user of the device, and instead the route options may be calculated based on a representative time, e.g. midday, as a reasonable compromise for most daytime travel. Alternatively, the device could provide a user interface to allow a user input to specify a time when a journey is to be made, either accurately or approximately, e.g. morning, afternoon, evening, night, and provide route options based on the specified time. In still another alternative, the server could calculate the time of day for a future journey by analysing the duration of the total journey so far, if known at that point. The route options can also be used to modify the default straight-line corridor path between two POIs. At step 404, instead of determining the corridor area based on the straight-line path between two POIs, the server could use the path of one or more of the routes options to determine the corridor area. The path could be the same as the actual path taken by various segments (walking, bus, underground, cycling etc.) of the one or more route options. Alternatively, the path could be a series of straight-line paths between start and end points of each segment of the or each route option.

If the actual path taken by a route segment is used as the path upon which the corridor area is determined at step 404, the data provided at step 406 may be provided for each rectangle in the corridor area. The corridor may have a predetermined width, e.g. 200m or other, as before.

Alternatively, the data provided at step 406 may only or additionally be provided for rectangular or other shaped areas around stations or transit stops in the one or more route options at which a change of transport line or mode is required. These areas are likely to be locations where the user may find it convenient to break their journey and explore the surrounding area instead. If data at step 406 is only provided for these areas, and not for other areas between chosen POIs, a more efficient use of bandwidth and storage capacity of the device is achieved since less data is provided from the server to the device.

In an alternative embodiment, the POIs provided at step 406 for the path between two places could be concentrated on any of the transit stops along the one or more route options, regardless of whether or not that transit stop involves a change of line or mode. The transit stops on which to provide data to the device at step 406 could be further chosen based on a determined popularity of POIs near to each transit stop. A transit stop with more popular POIs nearby is more likely to see a user interrupt their journey than a transit stop with less popular POIs nearby. A popularity score for each transit stop could be used to make a binary include/exclude decision on whether to additionally include nearby POIs as part of the data provided at step 406, or could be used to influence the amount of data provided at step 406, either by including POIs with a popularity score above a popularity threshold and/or within a set distance around each transit stop. A transit stop with more POIs of a higher popularity score may attract a high density selection, possibly over a bigger area, than a stop with POIs of a lower popularity score nearby.

In a further embodiment, the one or more route options provided between the two selected POIs may itself include further route options to other nearby POIs. The choice of further route options to provide data for could be based on the popularity score of POIs near to the start or end of the route option, or POIs near to the one or more route options between the selected POIs. The server determines possible additional POIs and retrieves further route options from the 3 ^rd party transit information service. The further route options are included in the data provided to the device at step 406. The device may then access these further route options offline if the user interrupts or modifies the chosen route option to take in one or more of these additional POIs.

The number of further route options to retrieve from the 3 ^rd party transit information service may be dependent on time, storage space and or bandwidth between the server and the device. In an embodiment, as many further route options as can be retrieved within a processing time of the server for the current request may be retrieved. As soon as the server is ready to provide the data for the POIs, images, map tiles and any other data at step 406, the server may cease retrieving further route options from the 3 ^rd party transit information service. Alternatively, the server could continue retrieving further route options until a certain maximum time is reached.

In an embodiment, the number of further route options could instead or additionally be dependent on the size of the data to be provided to the device at step 406. If the size of the data is below a certain maximum threshold, then further route options are added until that maximum threshold is reached.

The number of further route options could instead or additionally be dependent on the bandwidth available between the device and the server, which would affect the time taken to transfer the data from the server to the device. If the bandwidth is small, then fewer further route options are provided. For example, only one further route option may be provided in this case. If bandwidth is high, then multiple further route options can be retrieved provided to the device at step 406.

The methods outlined in Figures 3 and 4 allow a path from a first POI at a certain coordinate to a second POI at a different coordinate to be determined. Further, other POIs within a certain distance from the path between the first POI and the second POI are also provided along with their associated images. The user of the device is therefore able to view all points of interest between a first location defined by a first POI and a second location defined by a second POI on a map displayed on the device. The methods outlined in Figures 3 and 4 allow a user of a device to select a first POI and store associated data, then select a second POI and store associated data including data for the corridor area between the first and second POI. By performing the method in this way, the device iteratively collects data for subsequently selected POIs. This means that software in the device must keep a record of what data has already been acquired, and what new data is needed. For example, on selection of a second POI, the software determines that data relating to a first POI has already been acquired, and therefore the acquisition of only the data for the second POI and the data for the corridor area between the first and second POI is needed.

Alternatively, in a second embodiment, on selection of a second POI the device software may instead remove all data associated with the first POI. The device then proceeds to acquire data for the first and second POIs at the same time, including the corridor area between them. By doing this, the device software is simplified since it does not keep a record of any data previously collected, for example data associated with the first POI, and instead the device software acquires all data when the second POI is selected by the user. Further alternatively, the first and second POIs may be selected by the user before any data associated with the first and second POIs is requested from the server. In this case, the device proceeds to request all data for the first and second POIs from the server at the same time, including the corridor area between them.

Along with a first POI and second POI, a user may also wish to select a third POI from the list of search results and receive data related thereto on their device. In the same manner as for the second POI, the third POI may be chosen from the same list as the first POI, or may instead be chosen from a different list of search results that have been filtered for a different category. At step 502 of Figure 5 a third POI is chosen. Data associated with the third POI, such as all POIs within a predetermined distance from the coordinates associated with a third POI, images associated to these points of interest, or other information, is requested from the server by the device at step 504, as described in more detail below. At step 506 the requested data is stored in the device database.

Requesting data associated with the first, second and third POIs at step 504 is described in more detail in relation to Figure 6. At step 602, a path between the coordinates of the second and third POI is defined, in the same manner as that of step 402 of Figure 4. The path areas (corridor widths and lengths) between the coordinates of the second and third results are determined at step 604 in the same manner as that of step 404 of Figure 4. At step 606, the corridor area between the coordinates of the third and first POIs is determined in the same manner as that of step 402 of Figure 4. The server, having carried out step 606, has therefore defined and determined a complete loop of paths and corridor areas from the first POI to the second POI, the second POI to the third POI, and the third POI to the first POI.

At step 608, the data associated with the first, second and third POIs and their respective connecting corridor areas are sent to the device. This data may be displayed on the device via software which enables a user of the device to see selected POIs and the paths between each POI, including POIs located in the corridor area between each selected POI.

Alternatively, for the second embodiment, on selection of a third POI the device software may instead remove all data associated with the first POI and second POI, including the corridor area between them. The device proceeds to acquire data for the first, second and third POIs at the same time, including the corridor areas between them. By doing this, the device software is simplified since it does not keep a record of any data previously collected, for example data associated with the first and second POI, and instead the device software acquires all data when the third POI is selected by the user. Further alternatively, the first, second and third POIs may be selected by the user before any data associated with the first, second or third POIs is requested from the server. In this case, the device proceeds to request all data for the first, second and third POIs from the server at the same time, including the corridor areas between them.

The system is not limited to a selection of three different POIs, and in fact any number of POIs may be selected. Further, the user may specify a specific POI as a "home" POI to be used as the first POI and/or last POI in the loop.

Figure 7 shows the selection of yet further POIs. At step 702, a fourth POI from the list of results or POIs is selected. As mentioned previously, the selection may be made from the same results list as any of the preceding selected POIs, or the fourth POI may be selected from a new results list which is filtered by a different category or other variable.

At step 704, a sequence of selected POIs is determined. This may be determined by the same remote server used for figures 1 to 6, or may be performed by a different remote server. When there are fewer than four POIs selected, there is only one set of paths or corridors which, may be determined by the server, which connects all of the POIs. However, when a fourth or subsequent POI is selected, multiple different paths between the four or more POIs become available. At step 704, the server may simply order the POIs such that the paths are defined between the first POI to the second POI, the second POI to the third POI, the third POI to fourth POI, and the fourth POI back to the first POI. However, this may not be the most efficient sequence of POIs from a distance, time or cost perspective, or may not be a sequence desired by the user of the device. For example, the most efficient sequence may be the sequence which takes the user from the first POI to the last POI in the shortest time, with the lowest cost, or in the least distance. Therefore, at step 704 the user of the device may manually select the POI sequence based on user preference. Alternatively, software in the device may, on the selection of the fourth POI, automatically decide where in the sequence the fourth POI should be placed, based on the coordinates of the three preceding POI. The software is therefore able to calculate which position in the sequence the fourth POI should be placed, taking into consideration any of cost, path length, journey time or other variable. Further alternatively, on selection of the fourth POI, the server may determine the "best" position in the sequence to place the fourth POI. This is achieved by supplying coordinate data relating to the first, second and third POI to the server, at which point the server determines the most efficient route in terms of cost, time, distance or other variable, using any number of known algorithms. By calculating the sequencing at the server instead of at the device, the sequencing may be performed more efficiently and with less demand on device batter power.

Once the sequence of POIs has been established, at step 706 data associated with the sequence of POIs is requested from the server. The data is provided by the server in the same way as that previously described in relation to Figure 6, specifically the server calculates the path and corridor area between the POIs in the sequence, with the final path and corridor area returning the user from the last POI in the sequence back to the first POI in the sequence. Prior to the selection of the fourth POI, the previous sequence of results was simply a path from the first POI to the second POI, the second POI to the third POI, and the third POI to the first POI, since this is the only path available. However, with the inclusion of a fourth POI, the data associated with the path and corridor area from the third POI to the first POI is no longer needed, and therefore the device may delete the data associated with the path and corridor area between the third POI and the first POI. The deletion of this data therefore frees up memory capacity in the device, thereby allowing replacement data to be received by the device without necessarily increasing the device memory use. Alternatively, the device may maintain the data related to the path and corridor area from the third POI to the first POI until such a time that the device memory is full, at which point the device may delete that data. Further alternatively, the device may maintain the data relating to the path and corridor area between the third POI and the first POI for a fixed period of time. By maintaining the data for a fixed period of time, the user is provided with a window within which to change their mind about the sequence of POIs chosen.

At step 708, the data requested from the server for the chosen sequence order is provided to the device for storage in the device database. Device software allows the user to view the sequenced POIs and their associated data, including POIs within each corridor area between sequenced POIs.

As previously mentioned, at step 704 the user of the device may manually determine the sequence of POIs. Alternatively, the device software or server may determine the "best" sequence of the POIs. According to the first embodiment, the sequence of POIs is arranged by first determining a centre coordinate of all the POIs that have been selected. Starting at the first selected POI, a circular sweep is performed in a clockwise direction, centred on the centre of the selected POIs, in order to find the second POI in the sequence. Subsequent POIs in the sequence are selected by continuing the circular clockwise sweep until all the POIs have been placed in the sequence. The start point of the sweep may be not the first selected POI, but may instead be the POI closest to a user chosen starting point, or the POI closest to the user's current location. By calculating the sequence of POIs in this way, all the selected POIs are placed in the sequence with a very low demand on processor power of the device or the server. This is particularly preferable if the sweep is carried out on the device since the processing power of the device is likely to be significantly less than that of the server. Other methods of choosing the first POI in the sequence may be used. Further, the sweep may be an anticlockwise sweep instead of a clockwise sweep.

The sweep method of sequencing POIs may be non-optimal for some POI selections. Optimal may mean lowest cost, shortest route between selected POIs, shortest time between selected POIs, or may have another definition based on user preference. Many other methods of ordering selected POIs in a sequence may be used, as will be understood by one skilled in the art, such as the

Christofides algorithm for achieving a travelling salesman approximation.

Alternatively, for the second embodiment, on selection of a fourth POI the device software may instead remove all data associated with the first, second and third POI, including the corridor area between them. The device proceeds to acquire data for the first, second and third POIs at the same time, including the corridor areas between them. By doing this, the device software is simplified since it does not keep a record of any data previously collected, for example data associated with the first and second POI, and instead the device software acquires all data when the third POI is selected by the user. Further alternatively, the first, second, third, fourth or any subsequent POIs may be selected by the user before any data associated with the first , second, third, fourth or subsequent POIs is requested from the server. In this case, the device proceeds to request all data for the first, second, third, fourth and subsequent POI from the server at the same time, including the corridor areas between them.

In the second embodiment, since all data for all selected POIs is requested from the server simultaneously, the server is able to determine the sequence of POIs. Therefore, by requesting data for all POIs simultaneously, the device does not need to determine any sequencing and the server performs a greater amount of processing. As previously mentioned, the server would typically have greater processing capabilities than the device, and therefore the sequencing may be performed more efficiently by the server. Further, by removing some of the processing to be performed on the device, the battery consumption associated with using the device software is reduced.

The simultaneous selection of all POIs may alternatively be performed by the device software via the selection of a predefined "journey package" stored within the device software. The journey package may instead by downloaded from an external source such as the internet. The journey package comprises a series of POIs arranged in a predetermined sequence and may additionally include transit information as previously described. When a user of the device selects a journey package, the POI data is requested from the server and provided to the device as previously described. The use of a journey package allows a user to follow a predetermined route of POIs, which may be a recommended route or well-known route. By using a journey package, the limited processing is required by the server and/or device, since the calculation of sequences and POIs between the POIs of the journey package may not be needed as these are already set by the package. However, the journey package may only comprise a set of POIs without data relating to any POIs located in the corridor area between the set of POIs. The server may still therefore be requested to provide data for the POIs located within the corridor areas, and may further be requested to provide the sequence of POIs if this is not provided by the journey package. Alternatively, a third party service may be queried for any data desired, but missing, from the journey package.

In any of the previously described methods, when the device requests data from the server, the server may limit the amount of information or data provided to the device. This limitation may be due to the memory capacity of the device, and also may be due to the cost of maintaining an internet connection with the server. Service providers of mobile connections charge for "data roaming", i.e. connecting to the internet via a 3G or 4G connection. These costs are typically much greater when data roaming is performed overseas, and therefore it is desirable to download as little data as possible from the internet (server) to the device. The server may limit the size of the data provided to the device in a number of ways. A first way by which the server may limit the size of the data is by limiting the square or rectangular region or corridor width which defines the area to search for POIs around or between selected POIs. The larger the square or rectangular region or corridor width, the greater number of POIs found by the server and therefore the greater the amount of data that must be sent to the device. Therefore, in order to limit the amount of data sent to the device by the server, the server may reduce the size of the square or rectangular region or corridor width, thereby reducing the number of POIs and associated data sent to the device. For example, due to limited bandwidth it may be desirable to only send half of the requested data to the device. This may be achieved by scaling the square regions by a factor of 1/V2 and halving the width of the corridor areas, resulting in half the total area to acquire data from. Assuming that the number of POIs in the area is evenly distributed, only half the original number of POIs will be sent to the device.

The server may also limit the amount of data sent to the device based on one or more statistics associated with any of the POIs found. For example, a statistic concerning the popularity of a certain POI may be assessed against a minimum threshold level. Any points of interest which do not exceed the threshold level are not provided from the server to the device, thereby reducing the amount of data sent to the device. The threshold level may either be used to provide all POIs that exceed the threshold level of the device, or the threshold level may alternatively be used to provide a fixed number of POIs that exceed the threshold level.

The server may also reduce the amount of data sent to the device by varying the quality of any images associated with POIs. In order to reduce the amount of data sent, the quality of images associated with POIs may be reduced, for example, by increasing the compression of the image. When the device memory or costs associated with connecting to the server over the internet are not important, for example when a Wi-Fi network is available to the device, the server may then replace the images with higher quality images.

The amount of data desired from the server is determined by the data bandwidth available at that moment between the device and the server. Software on the device may specify the available bandwidth as an optional parameter every time a new POI is selected by the user. The available bandwidth may be assigned a value determined by monitoring the size and download time of previous data requests exchanged between the device and the server, which may also include any searches for POIs carried out by the user on the device. The determined bandwidth for the most recent requests between the device and the server may be a parameter used by the device to determine how much data to request from the server for any subsequent requests.

The described embodiments therefore allow a user of a device such as a mobile phone to plan a sequence of POIs, or a "travel itinerary", by obtaining the minimum amount of data from an external server. Obtaining less data reduces the time taken to download the data to the device, and therefore relatively slow Wi-Fi connections may be used. All of the data relating to the POIs and travel itinerary may be downloaded while a Wi-Fi connection is available, and no further data need be downloaded once the Wi-Fi connection is no longer available. Therefore a user can download the travel itinerary, and then follow the POI sequence without incurring any roaming charges and/or while the device is offline. Additionally, since only the minimum amount of data is obtained from the external server, the sequence of POIs or travel itinerary may be planned quickly and conveniently by the user.

Further, in the absence of any Wi-Fi connection, due to the small amount of data downloaded to the device, data may still be quickly and cost-effectively downloaded to the device via a roaming connection, which would not be realistic for a large amount of data due to cost and time

considerations. Further, the device memory is more efficiently used since unnecessary data is not needed. Only data related to the sequence of POIs desired by the user is downloaded to the device, and therefore an entire map containing such information does not need to be downloaded onto the device. The method therefore provides software, which may be in the form of an app, which is customisable depending on the geographical location of interest, and multiple different apps or software do not need to be downloaded to the device to account for different geographical locations, further improving memory usage.

Embodiments have been described by way of example only. It will be appreciated that variations of the described embodiments may be made. For example, the first, second and third phases may be performed by a remote single server, or may be performed by different remote servers connected by a wired or wireless link. The approach may be implemented on any appropriate device in communication via any appropriate means with a remote server which in turn can extract the data from the internet or any other appropriate source. The software can be implemented on the device as an "app" or other accessible means. Whilst the discussion focusses on geographical information, other information can be acquired similarly.