WO2017042644A1

WO2017042644A1 - Method for dynamic management of an itinerary, and corresponding computer system and product

Info

Publication number: WO2017042644A1
Application number: PCT/IB2016/054337
Authority: WO
Inventors: Mauro BENNICI
Original assignee: You Are My Guide S.R.L.
Priority date: 2015-09-08
Filing date: 2016-07-21
Publication date: 2017-03-16
Also published as: ITUB20153469A1

Abstract

A method for dynamic management of an itinerary, comprising the steps providing a first database (10) containing information on the preferences of a user, thus generating a user profile, providing a second database (20) containing travel information for each itinerary, comprising the places to visit in each itinerary, starting date and time and date and time of arrival for each itinerary, the bookings and the latest positions of the user. A route is identified, on the basis of processing of the information regarding the places to visit (20) and the user's preferences (10). Moreover provided is a third database (30) for storing raw information made available by different data sources (A) present on the web. The processed information (B) is stored in a fourth database (40), by selecting from the raw information the data that present a high reliability. The method provides: - calculating the impact of the processed information on the route identified; - generating an itinerary; and - pre-arranging bookings on the basis of the itinerary generated. Moreover provided is an itinerary- modification module (H), which, on the basis of recognition, from the processed information (40), of a new event that has an impact on the itinerary generated, calculates a plurality of alternative routes taking into account the user's preferences and notifies these alternative routes to the user and stores in the second database (20) the possible changes of itinerary selected by the user.

Description

"Method for dynamic management of an itinerary, and corresponding computer system and product"

~k ~k ~k ~k

TEXT OF THE DESCRIPTION

Technical field

The present description relates to a method for managing an itinerary. In particular, the method enables dynamic generation and modification of the defined itinerary.

Technological background

Typically, before starting out, travellers establish a travel plan with a pre-set itinerary. Prior planning comprises purchase and confirmation of flights, booking of hotel accommodation, programming of train journeys or journeys using other means of surface transport, definition of entertainment, and possibly booking tables in restaurants for lunches and/or dinners, thus generating a detailed itinerary for the j ourney .

The most recent prior art consists in a system for managing itineraries that enables modification of the itineraries and/or routes established on the basis of matching between information on the received events and the rules predefined by the user of the system. This solution proves far from flexible because it requires prior profiling of user preferences in a "rigid" and very detailed way.

To provide an optimal service, the prior art requires the user to know beforehand the events that could arise during his journey and generalise them and/or the system to know perfectly the preferences and habits of the user who will follow the itinerary defined. In this case, the system, upon arrival of news of an event that might affect the pre-set itinerary, on the basis of the rules set by the user automatically modifies the itinerary, following the indications provided by the predefined rules.

Furthermore, in the prior-art system the data on the points of interest (POIs) must be known to the user (entered manually and/or imported from various known sources) .

Both of the above modalities start from the assumption that the user is travelling from a starting point to a point of arrival that are known, that the displacement takes place in a known time, and that the user (has to) can know beforehand the places in which he or she will move around, this being something that normally does not happen when a traveller visits a new city that he or she does not know.

The known solutions are moreover based upon a precise knowledge of the territory in which the user will have to move to be able to include this information in the preferences and in the indications regarding the decisions taken during creation of the itinerary .

Object and summary

An object of one or more embodiments is to provide a method for dynamic creation and modification of itineraries for travellers.

One or more embodiments comprise various components that communicate with one another for creating a dynamically updated multidimensional virtual map, based upon the digital information generated by the interactions between humans and the surrounding environment. Consequently, using the map thus generated, it is possible to create a travel plan optimised on the basis of the preferences and of the requests of the user.

The travel itinerary may be updated, once again dynamically, by updating the map itself and on the basis of external events and/or of requests of the user.

The solution proposed enables the user to be relieved of manual modification of the itinerary, eliminating the need to define rules beforehand on the possible events and the need to know beforehand the places of the journey in order to express preferences.

The final object is to overcome the current dynamics of planning processes based upon saving of fuel and time, or upon optimisation of the route, choosing the shortest, as well as upon the presumed static knowledge of the territory, providing the user, instead, with a greater freedom of action, a greater flexibility and dynamic response to unforeseeable events, whether positive, neutral, or negative, and a greater weight to the degree of final satisfaction of the user.

The system creates a dynamic plan for the user that is able to follow the latter' s snap choices (for example, the user notices a group of people and decides to stop at an event) , his or her physical conditions (the user is tired and wants to skip/shift stops that he or she previously intended to make) , or sudden external events, such as problems of mobility or inaccessibility of the places of interest (a strike, a technical breakdown, the non-programmed closing of a museum because it is unserviceable, etc.), weather conditions also as regards the modalities of use of places and events.

One or more embodiments achieve the above object thanks to a method presenting the characteristics recalled in the ensuing claims. In particular, a method for dynamic management of an itinerary is described, comprising the steps of:

- providing a first database containing information on the preferences of a user, thus generating a user profile;

- providing a second database containing travel information for each itinerary, comprising the places to visit in said itinerary, starting date and time and date and time of arrival for said itinerary, bookings and latest positions of the user, where the latest positions are calculated on the basis of the pre-set itinerary; and

- identifying a route, on the basis of processing of information regarding the places to visit and the user's preferences.

The method further provides:

- providing a third database containing raw information made available by different data sources present on the web, and constantly updating said database with new information;

- processing said raw information for creating a fourth database containing processed information that may regard events, selecting from the raw information the data that present a high reliability;

- calculating the impact of the processed information on the route identified;

- generating an itinerary; and

- pre-arranging bookings on the basis of the itinerary generated.

The method further provides the step of providing an itinerary-modification module, which, on the basis of recognition, from the processed information, of a new event that has an impact on the generated itinerary, calculates a plurality of alternative routes, taking into account the user's preferences and notifies these alternative routes to the user, wherein the itinerary-modification module is pre-arranged for storing the possible changes of itinerary selected by the user and for managing the variations of the bookings on the basis of the alternative itinerary selected by the user.

One or more embodiments may refer to a corresponding system, as well as to a computer program product, which can be loaded into the memory of at least one computer and comprises portions of software code for executing the steps of the method according to one or more embodiments when the product is run on at least one computer. As used herein, reference to such a computer program product is understood as being equivalent to reference to a computer-readable means containing instructions for controlling the processing system in order to co-ordinate implementation of the method according to the invention. Reference to "at least one computer" is intended to highlight the possibility for one or more embodiments being implemented in a modular and/or distributed form.

The claims form an integral part of the description provided herein in relation to one or more embodiments .

Brief description of the drawings

One or more embodiments will now be described, purely by way of non-limiting example, with reference to the annexed drawings, wherein:

- Figures 1 to 9 exemplify embodiments of the various processing modules;

- Figures 10a and 10b show an example of alternative routes; and

- Figure 11 shows an example of the flows of the data gathered on the web. Detailed description

In the ensuing description one or more specific details are illustrated, aimed at enabling an in-depth understanding of various embodiments provided by way of example. The embodiments may be obtained without one or more of these specific details, or else through other methods, components, materials, etc. In other cases, known structures, materials, or operations are not represented or described in detail so that certain aspects of the embodiments will not be obscured.

Reference to "an embodiment" or "one embodiment" in the context of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is comprised in at least one embodiment. Hence, phrases such as "in an embodiment" or "in one embodiment" that may be present in one or more points of the present description do not necessarily refer to one and the same embodiment. Furthermore, particular configurations, structures, or characteristics may be combined in any adequate way in one or more embodiments .

The references used herein are provided merely for convenience and hence do not define the sphere of protection or the scope of the embodiments.

In particular, an itinerary, as understood herein, may comprise visits to sights and/or museums, participation in musical events, sporting events, etc., and may entail displacements with means of transport (whether public or private) and stays in hotels or other structures.

One or more embodiments may be used for creating an itinerary (for example, planning of the points of interest to be visited in a town) and/or for adapting and modifying the aforesaid itinerary on the basis of new events or conditions that arise and have an impact on the itinerary.

In particular, one or more embodiments may provide proposing to the traveller/user alternative itineraries, with stops selected on the basis of the preferences specified by the user.

One or more embodiments provide providing databases that contain information useful for creation and possible modification of the itinerary.

A first database 10 contains the profiling data and the preferences of users. These data are stored, for example, in records that contain the user forms with encoded and known information indicated by the users. Each user form may contain the demographic data of the user and a set of information on the user (for example, preferences, habits, interests, physical or food needs/limitations) acquired via user profiling.

A second database 20 contains the travel data, the itineraries, the bookings, and the latest positions of the users, where the most recent positions are calculated on the basis of the pre-set itinerary.

A third database 30 contains the information not yet processed gathered in the system on events and news coming from the external environment.

Moreover provided is a fourth database 40 that contains the information on the events after processing has been carried out by the system.

The information contained in these databases is used for creation and the possible modification of the itineraries requested by the user.

One or more embodiments moreover provide the pre- arrangement of macromodules with different functions:

1) Module "A", for capturing information;

2) Module "B", for processing the data and filtering them in order to obtain a greater adherence to the topic of interest and, in particular, of tourist interest ;

3) Module "C", for data aggregation;

4) Module "D", for genesis and creation of the multidimensional map;

5) Module "E", for comfort, which enables generation of an itinerary that takes into account the interests of the user;

6) Module "F", for generation of an itinerary;

7) Module "G", for integration with (internal and external) third parties;

8) Module "H", for modification of the itinerary; and

9) Module "I", for notification of variations of itinerary .

In the sequel of the present description, the functions of each module and the various possible interactions between the modules will be examined in greater depth in order to organise and manage the travel itinerary as well as possible.

1) Module "A": capture of information

The Information-capture Module "A" acquires raw information from different data sources, whether aggregate or not (for example, websites, social networks, blogs, open data, forums, weather-forecast services, news-groups, user-generated content, etc.) in any form (text, image, audio, video, etc.) in a passive and/or active way.

The Information-capture Module "A" is made up of different components:

i) Crawlers "Al": these are sub-modules that scan the Internet looking for any readable and freely accessible information;

ii) Importers "A2": these are sub-modules that import data from known sources, such as RSS (Rich Site Summary) sources, social networks, and open-data sources ;

iii) Databases "A3": these are memory structures that store the data gathered directly in the original format ;

iv) Text AntiSpam "A4": this is a sub-module that eliminates any data containing potentially offensive words and/or phrases with unsupervised-machine-learning (USML) techniques;

v) Image AntiSpam "A5": this is a sub-module that eliminates the photos, chiefly selfies, where the human figure covers the relevant part of the image (thus preventing a clear understanding of the non-human subject in the photo and possible information appearing therein) .

2) Module "B": data processing

The Data-processing Module "B" analyses the data acquired via the Information-capture Module "A", and catalogues them on the basis of their importance, the semantic meaning of the elements contained, the date of receipt, the date of the event, the geographical position, etc., and extracts the meaning of this information and the impact of the event according to a predefined scale of values of importance.

The Data-processing Module "B" catalogues, with the aid of artificial-intelligence techniques, the raw data acquired via the Information-capture Module "A" and divides them into macrocategories:

a) Place of interest: data regarding a Point Of

Interest (POI) ;

b) Event: data regarding an event in progress, a future event, or a past event (but with repercussions on the future, for example the end of a football match implies that the roads around the football ground are overcrowded) ;

c) Photos: data of a visual type;

d) Spam: all the information that is not relevant for the system; and

e) Weather forecasts: information on the weather conditions and possible weather-forecast alerts.

The data, each for each category, are stored in separate databases, one for each macrocategory .

Once new data coming from the Information-capture Module "A" have been received at input, the Data- processing Module "B" extracts and saves the data of interest in a proprietary format, different for each macrocategory .

The Data-processing Module "B", during processing and self-learning, uses the historic of the previous data already present in the databases and moreover also takes into account the latest news and classification of reliability of the source of the news.

In particular, the self-learning procedure is based upon the possible manual corrections made to the datum by comparing the interpretation given by the Data-processing Module "B" and the correct interpretation given by a human operator. These operations have the purpose of favouring automatic learning and of improving the correct automatic interpretation by the Data-processing Module.

Once this first step is through, the comparison is again made between the new datum and all the data present and active in the system regarding the specific element in order to assign a value of importance, such as, for example, a weight or a value of importance.

The final datum is consequently calculated as a conservative average of the variation.

In the case of presence of a new event or of a new source of information, the system will take it into consideration and will render it usable only after a reliability threshold has at least been reached, i.e., a given number of different sources that publish information regarding the event and/or the reliability of the sources by which the information has been sent.

By way of non-limiting example, a new place of interest notified by the Ministry of Cultural Affairs can be deemed always certainly valid, i.e., it can be entered in the database as reliable information.

Instead, an event notified only by a couple of anonymous (and not accredited) users will have to await gathering of further information, useful for contributing to the increase in the value of reliability, before being made available as event to the Information-capture Module "A".

The macrocategories of interest for the solution proposed herein, i.e., the categories that are taken into consideration by the Information-capture Module "A", may for example be:

- Place of interest;

- Event;

- Photos;

- Spam; and

- Weather forecasts.

Each macrocategory will then in turn have a series of data and/or of information of interest, which identify and categorise the information.

For instance, for the category "Place of interest", the data of interest may be the following: a) Date (day, month, year) ;

b) Source;

c) Name (multilingual);

d) Address;

e) GPS Geographical Position;

f) Description (multilingual); g) Photographs;

h) Opening and closing times;

i) Extraordinary opening and closing times; and j) Entry-ticket price.

Of course, in various embodiments some data may be added, may be absent, and/or may be replaced by other more relevant information.

Instead, for the category "Event", the data of interest may be the following:

a) Date (day, month, year) ;

b) Source;

c) Name (multilingual);

d) Address;

e) GPS Geographical Position;

f) Description (multilingual);

g) Photographs;

h) Opening and closing times;

i) Extraordinary opening and closing times; and j) Entry-ticket price.

Instead, for the category "Photos", the data of interest may be the following:

a) Date (day, month, year) ;

b) Source;

c) User Name;

d) User historic (date of registration) ;

e) Social relations of the user (number of followers/ friends , periodicity of publications);

f) GPS Geographical Position of generation of the content ;

g) Photograph; and

h) Attached text.

As regards, instead, the category "Spam", the data of interest may be the following:

a) Date (day, month, year) ;

b) Source; c) Text; and

d) Photographs.

The data that end up in the category "Spam" are used for instructing all the "AntiSpam" engines of the solution, in order to recognise this information in the future (for example, the information that comes from the same source) .

Finally, for the category "Weather forecasts", the data of interest may be the following:

a) Date (day, month, year) ;

b) Source;

c) GPS Geographical Position;

d) Time expected for weather change; and

e) Change (temperature, humidity, and weather conditions: rain, snow, wind, etc.)

3) Module "C": data aggregation

At this point the Data-aggregation Module carries out two processing operations:

CI) a first data-processing operation to convert the data received for each individual event of each macrocategory into a flow with ups and downs in relation to diffusion on the Internet and to their importance; and

C2) a second data-processing operation for aggregating all the flows that may regard one and the same event/place (via Description and GPS Geographical Position) into a new flow that, once certain (upper or lower) threshold values are exceeded, gives rise to requests for intervention by the Itinerary-modification Module "H" (as described more fully in what follows) .

The first data-processing operation creates three two-dimensional matrices in order to understand when a set of data departs from the normal activity of the place (whether this is a new activity or an activity provided and/or announced) . The first element of the matrix is always represented by each of the individual minutes of the last 12 months, whereas the second element is for each of the following different samples:

X) The historic of the activities of the place with minute-by-minute detail of the last 12 months;

Y) The expected activities of the place in the minute of interest of the last 12 months;

Z) The new and real sampling of the activities of the place in the current minute compared with the expected activities Y) for that minute.

In the case where the datum X) were not yet present, the Data-aggregation Module "C" generates an average of the nearest places for each time gap to be filled. For any datum Y) absent, the Data-aggregation Module "C" considers as forecast the information previously generated by a similar event wherever this has been generated; in the absence also of possible comparisons, the value of the field X) itself is considered.

The second data-processing operation combines the flows X), Y) and Z) of each place and of the places nearest thereto in order to intercept any variation of the flow (see Figure 11) .

In Figure 11, the dashed line indicates the real flows whereas the dotted line indicates the expected flows. The solid line indicates the flows of the history of the event.

At time 10:01, the expected flow corresponds to the real flow; hence, everything is as expected.

At time 10:02, the expected flow exceeds the real flow; consequently there is an anomaly. The event is less important than expected, and the impact of the event is downgraded. Hence, the users involved could decide to change itinerary. At time 10:03, the real flow exceeds the expected flow; hence, everything is normal. The event is more important than expected, and so participation of the users is confirmed.

At time 10:04, the real flow is lower than the historic flow, but greater than the expected flow; hence, everything is normal. The event will be processed in a different way next year, if it presents.

In the case of an expected flow, the Data- aggregation Module "C" checks that the data received correspond to the ones expected (for example, a concert) and previously calculated.

In the case of different data, the flow is considered as "unexpected".

In the case where the resulting flow is

"unexpected" the Data-aggregation Module "C" extracts new data, selecting the best description possible of the event in progress (as will be described more fully in what follows in relation to the Influencer Module) .

By "unexpected" flow is meant a flow of data that departs from the normal activity detected previously and of which the system did not know the possible presence. An "expected" flow, instead, is an activity expected by the system through comparison both of prior data and of information stored in the previous days, such as an increase of data on sports events in the vicinity of a sports stadium on a Sunday afternoon or an activity in an auditorium for a concert that is expected and has been publicised, or an annual event, such as a fair or exhibition.

3. a) Influencer Module

Once all the data and the events have been obtained and/or checked, control passes to the Influencer Module for calculating the impact of the new data acquired. A new datum has a greater effect:

when information is present in regard to the datum/event in question, in more than one data source;

the higher the number of users that share the event;

when the user sharing peak is between 15 minutes and 240 minutes;

the higher the number of users that share the event who do not have relations with each other;

- the longer the time for subscription of a user to the data source used for sharing;

according to the number of shares the user makes;

according to the subjects that the user shares;

according to the average time between two shares made by the user; and

on the basis of the position from which the share is made by the user.

If the datum has a negative, positive, or neutral impact, it is extracted by the Influencer Module according to a semantic analysis of the "sentiment" used in the shares made. The module extracts different "sentiments" according to the categories set down previously in a table present in the database containing also the historic of the previous events (e.g., a fireworks display is potentially positive if a user is moving on foot in the direction of the fireworks display, whereas it is negative if a user is sitting in a car and is about to arrive at a road closed to traffic on account of the fireworks display) .

4) Module "D": creation of the multidimensional map

At this point, the system via the Generation Module "D", creates a multidimensional virtual map of the YTM planet of its own using the data flows of the Data-aggregation Module "C" and the values of the Influencer Module.

Assigned to each new "place of interest" and to each new road are GPS co-ordinates (equivalent to the real ones), opening/closing times, if applicable, a description, a photographic gallery, and finally negative and positive scores according to the data provided by the Influencer Module for each category potentially impacted.

The assignment of the points is in proportion to the other scores already established, as if it were a percentage. For instance, the system starts to receive information on two places and starts to apply the rules for the score.

The first place is receiving a lot of shares from people who are in relation with one another and are present on the spot, but the place is not present in any other data source nor is it shared by other people not in relation with one another. The system will assign to this place a basic value of 100.

The second place is shared by fewer people than the first, but these do not have relations with one another; the people are sharing from different social networks and are veterans of the respective social networks. In this case, the system will assign a hypothetical value of 200 (twice the previous one) deeming it of greater interest. The first event may well, in fact, be a private party.

The difficulty in estimating the scores derives from the fact that an artificial intelligence does not have mathematically predictable results.

It is possible to display the aggregate map for each single category provided by the Influencer Module.

5) Comfort Module "E": generation of an itinerary that takes into account the interests of the user

To be able to generate an optimised and unique itinerary, the Comfort Module "E" creates a matrix of interests of the user starting from the data shared by the latter on the web, from the data gathered from the previous itineraries created and modified by the user, and any other manual or automatic interaction of the user with the system (for example, initial profiling) .

Some of the information that the Comfort Module "E" takes into account may be:

Early or late wakening;

Average sleeping hours;

Early to bed or late night;

Walking preference: in the shade or in the sun;

Tolerance to heat and to cold;

Eating preferences, and/or food needs due to particular allergies/ intolerances ;

Leisure preferences (museums, entertainment, seaside, mountains, etc.);

Sports preferences;

Music preferences;

Theatre preferences; and

Preferences regarding the individual or the group (travelling alone, in a couple, with friends, with children, etc.)

This module takes into account any other information that can improve the travelling experience of the user.

5) Module "F": generation of an itinerary

Once the multidimensional matrices and the user' s preferences have been acquired, the system is able to generate an optimised itinerary by comparing the multidimensional matrix and the user' s preferences with the dates and places that the user will provide to the system, such as starting date and time and/or date and time of arrival.

The Itinerary-generation Module "F" applies the matrix of interests generated in the Comfort Module "E" to the multidimensional virtual map YTM and uses these data for calculating, with a bonus/malus system, the entire itinerary taking into account:

a) User's preferences;

b) Times of travel;

c) Opening and closing times;

d) Time of visits to places;

e) Tendencies/ Importance ; and

f) Weather conditions.

In various embodiments, calculation of the itinerary includes 4 steps:

1) For each point of interest (POI) entered by the user in the itinerary, a circle map YUTM is created that has as centre the point of interest (POI) itself; in this map, surrounding POIs/events that fall within the radius of the circle are selected. The radius of the circle is variable in relation to the dimensions of the search area. Hence, it is smaller in an urban itinerary and larger in an itinerary between two or more states.

2) Each circle map YUTM is divided into hundreds of sub-maps YUTTM for each time space having a duration of down to a minute for each possible variation (opening/closing of a point of interest POI, start/end of an event, etc.), and the bonus/malus of each individual sub-map YUTTM is calculated.

3) From each sub-map YUTTM there is generated a weather-forecast sub-map YUTWTM by applying the weather information available to the system.

4) Starting from the weather-forecast sub-maps YUTWTM with the highest value, hence containing the options preferred by the user, a scan is made to identify the combinations of compatible weather- forecast sub-maps YUTWTM, the combination of which will give rise to the highest possible score.

Figures XXX illustrate examples of options rejected and of options accepted by the system according to the value assigned to the solution on the basis of the parameters considered so far.

By way of example, the first route includes a sub- map YUTWTM that envisages a displacement in the rain for approximately 500 m to be covered on foot, a sub- map YUTWTM with a displacement out of the town centre, followed immediately by another sub-map with a displacement towards the town centre to see two distant places in the same day; the stop envisaged is in a pizza restaurant (but the user is not keen on pizza) . The second option includes a sub-map YUTWTM that envisages a displacement in the rain for approximately 1.1 km to be covered on a tram and sub-maps YUTWTM that make it possible to see all the places in sequence, participating in an event that attracts the user along the way. A pause is envisaged in an Italian restaurant, something that the user appreciates from previous experiences. Both of the options are valid but the second is certainly preferable to the first.

In general, the highest scores are obtained when the route is in dry weather conditions and is convenient, without the user getting stuck in queues (strikes, traffic, etc.), and where he or she can participate in one or more possible events, and can eat/rest in places or take part in activities that he or she likes (Italian restaurant, events in the square, etc . ) .

For instance, Figure XXa shows a rejected option, with a negative value of the solution, equal to -121; the negative value results from the information on some places that have run out of tickets at that particular time and a from the fact that stretch of the itinerary would be in the rain.

Instead, Figure XXb shows an accepted option, with a positive value of the solution, equal to +23: all the places are open are can be visited (there are still tickets available), and it isn't raining.

7) Module "G": integration with (internal and external) third parties

The Integration Module "G" contacts internal and/or external services to help the user to complete his travel itinerary in the case where it is not possible to generate one with just the information contained in the map YTM or with the information provided by the user.

This module, in the case in point, retrieves information on displacements (by plane, underground, train, ship, car, etc.), food and refreshment services (restaurants, bars, pizza restaurants, etc.), and booking (hotels, entrance tickets, museums, exhibitions, shows, football matches, concerts, events, etc.) in the case where it is useful for a correct planning of the itinerary itself.

In the case in point, when the Itinerary- generation Module "F" detects that some weather- forecast sub-maps YUTWTM are missing in the course of a day (for example, there is no stop to eat), the Integration Module "G" is activated to obtain one or more points of interest (POI) in line with the user's preferences. In this way, it is possible to enrich the weather-forecast sub-maps YUTWTM present or to create new ones and complete generation of the itinerary by introducing a pause for lunch.

This new information will be useful also to enrich the main map YTM.

The weather-forecast sub-maps YUTWTM deemed necessary, by default, are:

a) 2 pauses per day (lunch and dinner);

b) Use of a means of transport for displacements of longer than 2 km;

c) Purchase of the ticket for an event/museum where booking or prior purchase is necessary/available; d) Stops necessary for the conditions of health of the user; and

e) Any other stop that may increase the pleasure of the user's experience.

The user will once again be able to supply manually data to the system to complete his or her own weather-forecast sub-maps YUTWTM, which are missing, and to add/modify the rules of the integration module (i.e., the necessary weather-forecast sub-maps YUTWTM) .

Once the best combination has been found and the itinerary has been generated, this is saved as an orderly set of weather-forecast sub-maps YUTWTM divided according to days and times of visits/stops.

The Integration Module "G" can also be used for generating in complete autonomy an itinerary by adding places (such as POIs and events) according to the tastes of the user, freeing the latter from the burden of selecting the points of interest.

8) Module "H": modification of the itinerary

Once an itinerary has been saved, it enters the LIVE mode; i.e., it is considered immediately active. From this instant up to the natural end of the itinerary (the last visits in program) , it may be modified both by the user and by the system itself.

Through the Itinerary-modification Module "H" all the new information is detected, as well as the corresponding events processed by the Data-processing Module "B".

In the case where a new element happens in the proximity (in space and time) of a weather-forecast sub-map YUTWTM present in the itinerary of a user, or in a weather-forecast sub-map YUTWTM on his route, the Itinerary-modification Module "H" will compare the previous weather-forecast sub-maps YUTWTM with all the possible new weather-forecast sub-maps YUTWTM generated by the new data and will prepare various actions of modification divided into two categories:

1) Actions of automatic modification if the event is not avoidable (closing of the museum, road block, etc . ) .

2) Actions of modification upon request if the event is avoidable, but of potential interest

(flashmobs, "Festa in Piazza", latest discounts applied to goods of interest for the user, etc.) .

The new actions will be applied (if not avoidable) or displayed awaiting a decision (in the case of an avoidable event) through the Itinerary- notification Module "I".

Of course, the alternative routes are generated taking into account all the information available.

9) Module "I": notifications of variations of itinerary

The Itinerary-notification Module "I" displays for the user on any device (PC, palmtop, smart-phone, tablet) at his or her disposal the salient information of the modification to the current itinerary.

In the case of a non-avoidable event, it shows the necessary modification and the new itinerary.

In the case of an avoidable event, or of an event of potential interest for the user, the system requires the user to select the preferred modification.

The user will be free to accept one of the modifications proposed, leave the route unvaried, or finally ask to avoid the event at all costs in order to avoid any possible negative impact thereof (for example, a strike, a "Festa in Piazza", etc.) .

The choices of the user will help the system to profile him or her better (i.e., information that may serve in future) and to make better decisions starting from the next choices.

The Data-processing Module "B", the Integration Module "G", and the Itinerary-modification Module "H" may be consulted, also on demand by the user, in the case of doubts or in the case of a request for more information on the itinerary.

The interactions and exchange of information between the various modules will now be described with reference to the figures, which represent block diagrams .

In a step 100 the creation of a new itinerary is requested. In a conditional step 102, a check is made to verify whether the user is a new user or else is a user already profiled. In the case of a new user, the program proceeds to a step 104, where the user fills in a questionnaire to indicate his or her own interests and preferences. The data gathered in step 104 are stored in the database 10, which contains profiling data and user preferences.

In the case where the user is already profiled, i.e., if in the database 10 there already exists a record with all the information on the user, and at the end of the step of profiling of a new user, the program then proceeds to a step 106, in which the places of interest are entered, i.e., the points of interest that the user intends to visit during his or her travel. In step 108, there are moreover entered the date and time of arrival in the place to be visited, and in step 110 the starting date and time.

In step 112, a check is made to verify whether bookings for travel or hotel accommodation are necessary. If so, the Integration Module "G" is activated for managing the various bookings. In the case where no bookings are necessary, and at the end of the booking operations carried out in the Module "G", control passes to the Itinerary-generation Module "F". The Itinerary-generation Module "F" has access to the various databases and in particular can read the information on the user from the database 10, the information on the journey from the database 20, and the processed information on events from the database 40.

The Itinerary-generation Module "F", at the end of processing, writes in the database 20 the information regarding the itinerary created.

The Itinerary-generation Module "F" is in communication with the other modules via a bus 50.

Figure 2 illustrates the sources S that make available information and data. A source S may be any data source accessible via the Internet or a connection and communication network. In particular, the set of the sources S may comprise videos SI, the web S2, the RSS news S3, social networks S4, blogs S5, photographs S6, and generic data S7.

The Information-capture Module "A" receives at input the data from the structure 200, which includes the passive or third-party services that handle the public services and the call-back services, and the data from the structure 202, which includes the active services .

By "call-back services" is meant the services whereby the system periodically makes an updating request and awaits a response at non-preset and/or non- defined times; hence, it is a service half-way between an active service and a passive service.

In particular, the active structure 202 comprises the Crawlers "Al", which, as has already been said, consist of sub-modules that scan the Internet looking for any readable and freely accessible information; i.e., they periodically query the various sources S.

The Information-capture Module "A" generates raw data and stores them in the database 30, which contains the non-processed information, just as it is acquired.

Also the Information-capture Module "A" communicates with the other modules via the bus 50.

In Figure 3, the Data-processing Module "B" receives the non-processed data at input from the database 30. In a step 210, an AntiSpam filter is applied to the raw input data, in a step 212 is an OCR (Optical Character Recognition) processing operation and applied, which converts the images with writings into encoded text, to which a semantic analysis may be applied. In a next step 214, the geographical location of the information (i.e., the GPS co-ordinates) is sought, and in step 216 the reliability of the source that has generated the information is analysed. The next step 218 checks whether the datum is a valid datum. If it is, it is converted, in a conversion module 220, into proprietary format for storage in the database 40 containing structured and processed data.

With reference to Figure 4, the Itinerary- modification Module "H" receives data at input from the user database 10, the itinerary database 20, and the database 40 for the structured information that has been processed in the Data-processing Module "B".

In the case of generation of an event, the Itinerary-modification Module "H" passes on to the procedure 300 for generation of new possible itineraries. The procedure 300 generates a plurality of modifications 302 that are saved in the itinerary database 20 and in the notification database 60.

The notification database 60 is read by the Itinerary-notification Module "I" for notification to the user of possible variations of itinerary. The Module "I" checks, in a step 310, whether the modification is avoidable. In the case where the modification is avoidable, the program waits for the answer from the user, in a step 320, regarding confirmation of the modification. If the modification is confirmed, the user selects in a step 330 the new option; i.e., from the modifications available the user chooses the one that appeals to him or her most.

In the case where the modification is unavoidable

(negative outcome from step 310) control passes to step 330, where the user is asked to select a new option, i.e., to select one modification from the ones presented .

At the end of step 330 (as illustrated in Figure

6) , the Itinerary-modification Module "H" is recalled. In a step 400, a check is made to verify whether the itinerary envisages bookings. If it does, the Integration Module "G" is activated to check whether the bookings made can be modified. In step 402, a check is made to verify whether the modification has been successful. If it has, the itinerary database 20 is modified.

Otherwise, if the itinerary does not contain any bookings, the itinerary database 20 is modified directly, and consequently also the notification database 60.

Next (see Figure 7), the Notification Module "I" receives from the database 60 the notifications of the changes to be made to the itinerary, and in a step 404 a check is made to verify whether the modification has been made successfully. If so, the modification step terminates; if not, the program returns to step 330 to ask the user to select a new option from the ones available.

Figure 8 illustrates operation of the Itinerary- generation Module "F". The Module "F" communicates with the databases 10, 20, and 40. The Module "F" contains a list Fl of places of interest, associated to which are the GPS co-ordinates F2 of the places. Indicated in the list F3 are all the opening and closing times of the places, and stored in the list F4 are the road maps. Stored in the list designated by F5 are the user' s bookings, whereas gathered together in the list F6 are the user's preferences. Designated by F7 are the itineraries associated to the user, and designated by F8 are the itineraries of the other users. The statistical information of the places is stored in the boxes F9, whereas the real-time information on the places is stored in the boxes F10.

Stored in the boxes Fll are the past weather conditions, and stored in the boxes F12 are the forecast weather conditions. Designated by F13 is the catalogue of the bookings, which comprises a list of bookings, and designated by F14 are the GPS co^¬ ordinates of the user.

The Itinerary-generation Module "F" starts with a step 500 for calculation of the itinerary. In step 502, the user selects the places of interest, and in step 504 the opening and closing times of the places selected are calculated. In a step 506, a self-learning or machine-learning function is carried out on the user preferences, whereas in step 508 a self-learning function is carried out on the user itineraries. In step 510, the artificial intelligence is applied to the information on the places compared with the user' s preferences in order to calculate and define, in the next step 512, the importance of the various places on the basis of the user's tastes. Next, in step 514, the impact of the weather conditions is calculated, and in step 516 the best route for the various displacements between the points of interest is computed, respecting the user's tastes. In step 518, the various bookings are made, and finally in step 520 the itinerary is saved in the database 20.

Illustrated in Figure 9, is operation of the Itinerary-modification Module "H". The Module "H" communicates with the databases 10, 20, and 40. The Module "H" contains the same elements as the ones listed for the Module "F", which are here designated by the references HI to H14.

The first steps from 600 to 616 of the method for modification of the itinerary correspond to the steps 500 to 516 described previously. In the case of modification of itinerary, step 616 is followed by a step 618, in which the alternatives to the current itinerary are calculated. In step 620, the notifications of the possible alternative itineraries are saved, and the possible alternative itineraries are saved in step 622.

Some examples of situations managed by the system will now be described.

In a first example, the user is driving a rented car, and the navigator is not showing any delay along the route envisaged.

In a square, along the route, a "Festa in Piazza" has just started. The people on the spot start to share the event, for example on social networks or by publishing photos and comments. The Information-capture Module "A" starts to gather the data. The Data-processing Module "B" extracts the event and evaluates it as markedly negative for the user.

The Itinerary-modification Module "H" prepares alternatives .

The Notification Module "I" warns the user of the event, showing the news on the event and the multimedia content (if present), as well as the possible alternatives proposed for changing the itinerary in the light of the new event.

The user can decide to avoid the square, and proceed on his journey, without any setbacks or delays.

In a second example, the user is in a museum and is taking part in a guided tour.

In the vicinity, in a square that is not among the points of interest present in the established itinerary, a "Festa in Piazza" has just started.

The people on the spot start to share the event, for example on social networks.

The Information-capture Module "A" starts to gather the data. The Data-processing Module "B" extracts the event and evaluates it as positive for the user .

The Itinerary-modification Module "H" prepares the alternatives to enable the user to participate in or to avoid the event.

The Notification Module "I" warns the user of the possibility, showing the news and the multimedia content (if present), as well as the possible alternatives proposed for changing the itinerary in the light of the new event.

The user decides to participate in the event and, once the visit to the museum has terminated, joins the "Festa in Piazza".

In a third example, the user today has to visit a museum that has been booked, and has planned for tomorrow a visit to the botanical gardens.

The weather-forecast service forecasts that tomorrow there is a marked likelihood of rain.

The Information-capture Module "A" starts to gather the data.

The Data-processing Module "B" extracts the event and evaluates it as potentially negative for the user.

The Itinerary-modification Module "H" calculates the alternatives to enable the user, for example, to swap the visit to the museum planned for today with a visit to the gardens planned for tomorrow. This situation takes into account the fact that today it is sunny and it is pleasant to be in the open air, whereas tomorrow rain is forecast and it is convenient to visit places indoors. Of course, the module has previously checked that the timetables are compatible and that there is the possibility of changing the tickets (postponing the date of the ticket to the museum and finding a ticket for the gardens for today) .

The Notification Module "H" notifies the possibility to the user by displaying the news and the possible alternatives proposed for changing the itinerary in the light of the new event.

The user decides to accept (conditionally) the modification by swapping around the visit to the gardens with the visit to the museum in order to avoid the rain.

The Integration Module "G" contacts the e- ticketing service of the museum and makes the change of date, postponing by one day booking of the ticket for the visit to the museum.

The Notification Module "I" notifies the user of the correct modification of the itinerary and guides him or her towards the visit to the gardens.

In a fourth example, the user on foot is faced with a choice: either to turn to the left or to the right to reach the end of the road or a square. The roads are of the same length and the user does not know the town.

The system described herein is able to guide the user in making the choice, for example by avoiding the road to the left where there have been a number of cases of bag-snatching recently. Consequently, the system proposes the road to the right, where moreover a couple of shops are present that are likely to appeal to the user, or else suggests a third road, justifying the choice.

The modalities whereby the system according to the description enables the problems of the prior art to be overcome will now be described.

With reference to the first example, current planning systems would have had to wait for notification of the traffic by the other users already in the queue, and the user would also have an extremely high likelihood of ending up in the queue.

With reference to the second example, current planning systems would not even have come into play. The user would not have known about the "Festa in Piazza".

With reference to the third example, current planning systems are not able to provide swapping with other elements planned for the next few days.

With reference to the fourth example, current planning systems would have chosen a road at random, potentially exposing the user to the risk of getting robbed, or else having to endure a walk that is of no interest .

In general, the systems currently available tend to privilege the saving of time/fuel during a displacement and not what the user experiences during the displacement itself. Furthermore, re-planning, in the case where it is not point-to-point, is entirely performed by the user.

The solution proposed herein makes it possible to go beyond the classic rules upon which current planning systems are based, i.e., saving time and/or fuel in the displacements, by concentrating the choices on the preferences expressed by the user who makes the displacement, improving his or her travel experience whatever the means with which he or she may be moving around (in a car, on foot, on a bike, etc.) .

Generation of an itinerary becomes automatic, and in the calculation of the best itinerary the system also takes into account the preferences indicated by the user, as well as the weather conditions.

Given the same initial conditions and choices, the itinerary is in this case optimised, personalised, and unique for each user, being based not only on the historic of the place and on the real-time information coming from the environment, but also on the preferences and on the historic of the user's choices.

The solution provides recalculation of an itinerary defined on the basis of events that in some way have an effect and an impact on the itinerary.

Consequently, without prejudice to the principle of the invention, the details of implementation and the embodiments may vary, even significantly, with respect to what has been described and illustrated herein purely by way of non-limiting example, without thereby departing from the scope of the invention, as defined by the ensuing claims.

Claims

1. A method for dynamic management of an itinerary, comprising the steps of:

- providing a first database (10) containing information on the preferences of a user, thus generating a user profile;

- providing a second database (20) containing travel information for each itinerary, comprising the places to visit in each itinerary, starting date and time and date and time of arrival for each itinerary, the bookings and the latest positions of the user;

- identifying a route, on the basis of processing of the information regarding the places to visit (20) and the user's preferences (10);

- providing a third database (30) for storing raw information made available by different data source (A) on the web, and constantly updating this database with the new information available;

- processing (B) said raw information for creating a fourth database (40) containing processed information that may regard events, selecting from the raw information the data that present a high reliability;

- calculating the impact of the processed information on the route identified;

- generating an itinerary; and

- pre-arranging bookings on the basis of the itinerary generated,

the method further envisaging providing an itinerary-modification module (H) , which, on the basis of the recognition, from the processed information (40), of a new event that has an impact on the itinerary generated, calculates a plurality of alternative routes taking into account the user' s preferences and notifies said alternative routes to the user, wherein said modification module (H) is provided for storing in the second database (20) the possible changes of itinerary selected by the user and managing the variations of the bookings on the basis of the alternative itinerary selected by the user.

2. The method according to Claim 1, wherein a step of user profiling is provided, which acquires the demographic data of the user, preferences, habits, interests, needs, and/or physical and/or food limitations and stores them in said first database (10) .

3. The method according to Claim 1 or Claim 2, wherein the step of creation and updating of said third database (30) provides acquisition in a passive and/or active way of raw aggregate and non-aggregate information from different data sources, such as websites, social networks, blogs, open data, forums, weather-forecast services, news-groups, user-generated content, etc., wherein said raw information may be made available in any form including text, image, audio, and video .

4. The method according to Claim 3, wherein the step of creation and updating of said third database

(30) provides the steps of:

i) scanning (Al) the Internet communication network looking for any readable and freely accessible information;

ii) importing (A2) data from sources known to be reliable sources, such s Rich Site Summary, social networks, and open data;

iii) generating memory structures (A3) for storing the data gathered directly in the original format;

iv) eliminating (A4) any data containing potentially offensive words and/or phrases with unsupervised machine-learning techniques; and

v) eliminating (A5) the photos where the human figure covers the relevant part of the total area.

5. The method according to Claim 4, wherein said step of processing (B) raw information comprises:

- analysing the data contained in said third database ( 30 ) ;

- cataloguing said raw data on the basis of their importance, semantic meaning of the elements contained, date of receipt, date of the event, geographical position;

- extracting the meaning of said information that may regard events; and

- evaluating the impact of the events detected according to a predefined scale of values of importance .

6 . The method according to Claim 5, wherein said step of cataloguing the raw data comprises dividing said data into macrocategories comprising:

a) Point of interest (POI);

b) Current, future, or past event;

c) Photo or datum of a visual type;

d) Spam, non-relevant information; and

e) Weather forecast.

7. The method according to Claim 6, wherein said step of processing (B) raw information comprises the steps of:

- converting (CI) the data received for each individual event of each macrocategory into a flow presenting a pattern that depends upon the diffusion on the web and upon their importance; and - combining (C2) all the flows that may regard one and the same event in a new flow that, once certain threshold values are exceeded, gives rise to requests for intervention for modification of the itinerary.

8 . The method according to any one of Claims 5 to 7, wherein said step of evaluating the impact of the processed information on the route identified, comprises assigning a value of importance to the information on the basis of strategies of reliability, and in particular a higher value in the following situations :

when information is present in regard to that same datum/event in more than one data source;

- the higher the number of users that share the event ;

when the user sharing peak is between 15 minutes and 240 minutes;

the higher the number of users that share the event that do not have relations with one another;

the longer the time of subscription of a user to the data source used for sharing;

according to the number of shares the user makes;

- according to the subjects that the user shares ;

according to the average time between two shares made by the user; and

on the basis of the position from which the share is made by the user.

9 . The method according to any one of the preceding claims, wherein the step of generation of an itinerary comprises modifying the route identified, taking into account the interests of the user starting from the data shared by him or her on the web, from the data gathered from the previous itineraries created, and from the possible modifications applied, and any other manual or automatic interaction of the user.

10. The method according to any one of the preceding claims, wherein the itinerary-modification step may be:

- automatic if the event detected is not avoidable; or

- upon request for confirmation and selection if the event detected is avoidable, but of potential interest .

11. A system for dynamic management of an itinerary, comprising an interface and communication device, the system being configured for implementing the method according to any one of Claims 1 to 10.

12. A computer-program product that can be loaded into the memory of at least one computer and comprises portions of software code that are able to implement the method according to any one of Claims 1 to 10 when the product is run on at least one computer.