Mobile Device And System For Automated Transport Mode Recognition And Corresponding Method Thereof

A method and system for automated transportation mode recognition based on sensory data measured by a plurality of sensors of a cellular mobile device of a user, the plurality of sensors at least comprising an accelerometer and a gyroscope, the plurality of sensors being connected to a monitoring mobile node application of the mobile device, wherein the mobile device measures time series of sensory parameter values based on measuring parameters obtained from the sensors, the measuring parameters comprise time series of sensory parameter values of a 3-axis accelerometer as sensor and time series of sensory parameter values of GPS-based speed measurements of a GPS receiver as sensor, and wherein the measured time series of sensory parameter values trigger the automated transportation mode recognition as input feature values to a gradient boosting machine-learning classifier, the transportation modes at least comprising the modes public transportation and/or motorcycle and/or cycling and/or train and/or tram and/or plane and/or car and/or skiing and/or boat, and the transportation mode recognition generating a transport mode label for a transport mode movement pattern of a trip.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of International Patent Application No. PCT/EP2021/074817, filed Sep. 9, 2021, which claims priority to PCT/EP2020/075548, filed Sep. 11, 2020, the contents of each of which are hereby incorporated by reference in their entirety.

FIELD OF THE INVENTION

The present invention relates generally to transport mode recognition systems particularly to systems and methods for mobile phone sensory data, as smartphone sensory data based transportation mode detection (TMR). More generally, the invention relates to mobile real-time systems reacting dynamically to captured environmental or operational parameters, in particular to automotive use monitoring, capturing, and reacting to automotive or user-related parameters in the context of motor vehicle operation. More particularly, the present invention relates to telematics based devices and systems for transport mode recognition. Finally, the invention also relates to telematics-based real-time recognition systems. The term telematics, in particular traffic telematics, refers to sensory systems that are used for communications, instrumentation and control, and information technology in the field of transportation. Thus, the present invention relates to the use of telematics and/or mobile phone sensory data together with real-time measuring, monitoring, dynamically and automatedly adapting systems based on captured and measured usage-based and/or user-based telematics data.

BACKGROUND OF THE INVENTION

With the technical advances in functionality and capability, mobile phone can act, nowadays, not only as a mere communication tool, but often a monitor and service platform technically bridging applications and the end user. Modern mobile phones, such as smartphones, are being integrated with a variety of physical and virtual sensors capturing the user's real-time contextual and situational information, such as location, activity, etc. The present invention is focused on mobile phone based transportation mode recognition systems and automated methods thereof. There are different systems in the prior art for automated transport mode recognition (TMR), in particular in the context of mobile devices, such as cellular mobile phones or smart phones. TMR systems are known under different technical terms such as transport mode detection, travel mode detection, automated transport mode identification, and recognition of travel pattern. The last category often concerns machine learning, supervised learning, semi-supervised learning, unsupervised learning, statistical methods, and rule-based method. The prior art systems often rely on GPS data, GPS tracks, GPS processing methods, trip identification, trip recognition, GPS data cleaning, GPS trajectories, and map matching. However, huge technical hurdles remain in providing reliable and automated detection of transportation modes of a smartphone user, inter alia, often related to the limited availability of data processing power, the fragmentariness or incompleteness of the sensory data of the mobile device, limited battery power etc.. Nevertheless, transport mode recognition is important for many technical applications, including transportation in-depth monitoring and machine-based intelligence analysis, urban planning, health monitoring, computer supported elder-care, epidemiology, etc. With the knowledge of travelers' transportation mode, targeted and customized electronic advertisements may be routed and sent to their devices. This information is also useful for the development of context aware cell phones that sense the current context and adapt their behavior accordingly. Also, if the precise transportation modes of individual users are detected and/or monitored, it is possible to provide a more realistic picture of travel demand. This knowledge may help to determine the environmental impact of travel patterns, such as carbon footprints of users and optimize the travel patterns or track the daily step count of users and amount of calories they burn etc. Another application is the detection of real-time traffic states because companies such as Google collect data from mobile phones in order to estimate and measure the traffic speed on roads, or technical traffic guidance systems or navigation systems for optimization of traffic lightening, in particular real-time steering. Further, in the context of automated detection of transport modes it is important to differentiate between the different applied classifications. The accurate classification of a transport mode can be critical when the system is attempting to assist or enact measures to inform, warn, or protect a user or in measuring user-specific exposure parameters in the context of possibly impacting or affecting occurring event, as accidents or disaster events.

However, as mentioned above, for GPS based recognition, poor reception of GPS information and heavy energy consumption make real implementation difficult; for GSM based recognition, it needs long time to observe the change of cell information and the recognition accuracy is often low. Comparatively, merely accelerometer based recognition is often more acceptable because: 1) the accelerometer consumes much less energy than GPS; 2) the accelerometer needs a little starting time; 3) the accelerometer can obtain sensor data all the time; 4) this method does not depend on any external equipment and will not affected by different deployment of cell towers. However, as to the accelerometer based transportation mode recognition on mobile phones, in real applications, it is difficult to determine the position and orientation of mobile phone because the user can place his mobile phone at any places he would like to, such as in his hand, in the trouser pocket, in the bag, etc. Thus, some prior art systems try to recognize transportation modes using the combination of GPS and accelerometer. At there, the acceleration features are extracted from the series of acceleration magnitude, which is the value of acceleration synthetization of three axes. However, the accelerometer signal averages over a reasonable time period often does not produce a good measure of the gravity related component. Then, the gravity vector estimate in turn cannot enable proper measurements of the vertical component and the magnitude of the horizontal component of dynamic acceleration caused by user. Even if two methods to recognize user's physical activities are used, unseen the problem of energy consumption of the mobile device, such acceleration decomposition based approaches do not perform substantially better than mere acceleration synthetization based approaches.

In any case, to determine the mode of transportation based on smartphones, the data from different built-in smartphone sensors is typically used. Most modern smartphone devices have sensors that measure motion, orientation, and various environmental conditions. They are capable of providing data with high measuring precision and accuracy. These sensors are useful for monitoring three-dimensional device movement or positioning, or for monitoring changes in the ambient environment near a device. Motion sensors include accelerometers, gravity sensors, gyroscopes, and rotational vector sensors. Position sensors include orientation sensors and magnetometers. Environmental sensors include barometers, photometers, and thermometers. In addition to mobile device sensor information, some external data source can also be valuable.

The smartphone sensors and external data sources typically employed in transportation measuring can be summarized as follows: (A) Accelerometers are able to measure the physical motion of a solid object. Id est, they measure the acceleration force that is applied to a device on all three physical axes, including the force of gravity. Accelerometers are primarily used for orientation sensing in smartphones. However, transportation measuring shows that the acceleration generated during human movement varies across the body and depends upon the activity being performed. The key feature that makes this sensor attractive is low energy consumption; (B) Gyroscope measures a device's rate of rotation around each of the three physical axes. It can provide orientation information, and provides an additional dimension to the information supplied by the accelerometer. Gyroscopes are typically characterized by low power consumption, but are, however, prone to error accumulation as a result of significant calibration errors, electronic noise, and temperature; (C) Magnetometer measures the ambient geomagnetic field for all three physical axes. It provides mobile phones with a simple orientation in relation to the Earth's magnetic field; (D) Global Positioning System (GPS) sensor provides the position and velocity of the user that is measured based upon the distance of the mobile phone and each of a number of satellites in two dimensions. Connection to at least three satellites is required for two-dimensional positioning, and the precision increases with more visible satellites. GPS does not work indoors, and is therefore primarily used for outdoor positioning. A further technical limitation is, that it is characterized by reduced precision of positioning in dense urban environments, due to the fact that buildings reflect and occlude satellite signals. GPS is considered as the most power consuming localization technique for mobile computing, and it reduces the battery life of the phone significantly. The accuracy of this system is between 50 to 80 meters and can be improved to an accuracy of up to 10 meters; (E) Cellular network signals are used by the phone for calls and data transfer. The most widespread cellular telephony standard in the world is Global System for Mobile Communication (GSM). A GSM base station is typically equipped with a number of directional antennas that define sectors of coverage or cells. A cell is therefore a geographic region in a cellular communication network within which mobile devices can communicate with a particular base station. Each cell has a unique cell identifier. The fluctuation pattern of cell identifiers together with signal strength can provide information on the position of a phone. To collect this type of data, an application that measures and records the surrounding radio environment has to be installed on a mobile device. Mobile phones can be tracked in outdoor and indoor contexts. A precision varies depending on cell size from 50 to 200 meters, but can deteriorate even more in low density areas. Cellular network signals are associated with “ping-pong” phenomenon, which appears when a user is within the coverage of two or more stations. Signal strength from the stations fluctuates and causes repetitive changes of associated cell even when users are stationary. The data from mobile phone operators can be analyzed consisting of anonymous location measurements generated each time a device connects to the cellular network (e.g. when a call is placed or received, when a short message is sent or received, when the user connects to the Internet, etc.). However, these measurements are available only during the time that the device is in use, or when the associated cell changes over time (e.g. during a trip); (F) Bluetooth allows wireless connectivity and short range communication. Bluetooth sensors are able to sense devices in their vicinity, and to obtain their Bluetooth identifiers, names and types. The range of Bluetooth scanners and penetration rate vary between 10 to 100 meters, respectively between 7% and 11%; (G) WIFI provides wireless connectivity to devices inside a Wireless Local Area Network (WLAN). The WLAN provides communication ranges of up to 100 meters and allows to track devices outdoor and indoor. Smartphones do not need to be logged on to the WLAN, but their WIFI antennas has to be turned on. The positioning accuracy is low. It is possible to improve the localization in case when there is more than one access point available using for instance signal triangulation and fingerprinting. WIFI is the most power-demanding sensor after GPS when used to provide location information. The effect called “ping-pong” is also typical for WIFI data; (H) Other sensors include barometers that measure atmospheric pressure and can be used to detect how high the phone is above sea level, thermometers and humidity sensors that measure ambient temperature and air humidity, cameras, microphones, etc.; and (I) External data sources can provide additional useful information in transportation measuring. They include network infrastructure data and route maps, as well as the time schedules of public transportation modes in a static or a real-time form.

In the prior art systems, raw data measured and collected by different smartphone sensors are typically transformed into more computationally efficient and lower dimensional sets of features. The extracted features are intended to be informative and e.g. relevant for the learning task. A variety of feature-extraction techniques are used in the state of the art, based on different data processing approaches, algorithm structures and statistical procedures. The raw sensor data are typically segmented into several windows and features are extracted from a window of samples. The window size, as well as the sampling frequency, are important parameters, as they both affect computation and power consumption of sensing algorithms. Smaller window sizes cause classification accuracy to suffer due to certain features not being effective (e.g. accelerometer frequencies) and larger window sizes may introduce noise in the data.

Time domain and frequency domain features are used for transportation mode detection tasks. Time domain features are used to characterize the information within the time varying signal. Many prior art systems use raw speed or acceleration data, and GPS positioning information over time as input features. The difference in distance covered between measurements and heading changes are used in addition. For accelerometer signals, the features such as mean, standard deviation, median, minimum, or maximum of the signal are the most commonly used in time domain. GSM signal strength and cell tower fluctuations are utilized for inferring different states of user motion. Frequency domain features are regarded as technically more computationally demanding compared to the time domain features. This is due to an additional processing step, related to the data transformation from the time to the frequency domain. An example of these features is the peak frequency of the power spectral density of the accelerometer signal. Finally, features extracted based on external data typically include bus location closeness, bus stop closeness and rail line closeness.

The prior art algorithm structures used for transportation mode detection can typically be categorized as discriminative or generative. Generative algorithms are based on modelling and/or simulating class-conditional probability density functions and backward in time probabilities. As such, they allow to generate samples from the derived joint distributions, and are typically flexible in expressing dependencies in complex learning tasks. For this group, structures of prior art systems comprise the algorithms Naïve Bayes, Bayesian Networks, Mixture Models and Hidden Markov Models. Discriminative algorithms do not attempt to model underlying probability distributions. Instead, they are focused on a direct estimation of posterior probabilities. Popular discriminative algorithms include Support Vector Machines, Neural Networks, Nearest Neighbor, Decision Tree, Random Forests, Clustering, etc.

One further deficiency of the prior art system lies in the fact that the prior art systems in the field use a great variety of different categorization of transportation modes. In general, transportation modes can be roughly classified into motorized and non-motorized (also referred as soft modes). Motorized modes include cars, motorcycles, trucks, buses, trams, metros, and trains. Walking, running, and biking are typical representatives of soft modes. Soft modes can e.g. be considered to contribute to the reduction of congestion and pollution, the enrichment of the local environment, the improvement of quality of life, enhanced accessibility, and social equity. An often found governmental objective in many countries is therefore the promotion of soft modes, which together with public transport represents an energy-efficient and low resource-consuming means of transport, in particular in order to achieve the climate goals as set in the Paris climate conference of 2015. It seems to be clear that different transportation modes should show different mobility patterns. For instance, motorized modes generally have a higher speed than soft modes. FIG. 1 shows examples of prior art measurements of normalized histograms of the recorded speed data and the estimated speed distributions for five modes. Technically, walking, and biking modes are typically easier to differentiated from other modes. However, slow walking can be rather similar to no movement, and biking can be very similar to the cars. As for the latter, the similarities are reflected through similar speeds and routes of bikes and cars in the cities and absence of fixed schedules. Buses are supposed to follow fixed routes and schedules, which places them apart from the categories above. However, due to high volumes of traffic, significant discrepancies may occur making buses one of the categories that are more difficult to measure and predict. Trams, metros, and trains follow routes and schedules like buses, but are not subject of delays induced by traffic congestion. Their routes may contain underground parts, causing poor quality or non-existence of certain smartphone signals. Some of the prior art systems additionally consider stationary mode, which refers to a not moving state of an object, and as such significantly differs from other categories. Whatsoever, there is strong demand in the technical field for a reliable system for efficient automated transport mode recognition.

In the following, some of the prior art systems are discussed more detailed: (i) One of the prior art systems is based on an unsupervised method of learning a Bayesian model from a measured GPS sensor stream. This technical approach simultaneously learns a unified model of the traveler's current mode of transportation and her most likely route. Car, bus, and walking are considered transportation mode categories. For this kind of prior art systems it can be shown that the accuracy of the approach is improved by adding more external GIS knowledge; (ii) Another prior art system is based on using the patterns of GSM signal strength fluctuations and changes to the current serving cell and monitored neighboring cells it is possible to distinguish between various states of movement such as walking, driving in a motor car, and remaining stationary. The system uses a Hidden Markov Model for inferring the current activity of the cell phone carrier; (iii) In a further prior art system, coarse-grained GSM data from mobile phones are used to recognize high-level properties of user mobility. This approach is a two-stage classification scheme. The first stage classifies an instance as stationary or not. If the instance was classified as not stationary, a second classifier determines if the instance was walking or driving. Both classifiers are trained using a boosted logistic regression technique. The algorithm structure is able to distinguish if a person is walking, driving, or remaining at one place. Typically, such two-stage classification have a superiority compared to Naïve Bayes, Support Vector Machines, and heuristic-based systems; (iv) Another prior art system is focused on the transportation mode of an individual based on GPS and accelerometer smartphone data. The goal in such systems is to determine whether an individual is stationary, walking, running, biking, or uses motorized transport. This classification system consists of a decision tree followed by a first-order Hidden Markov Model; (v) One prior art system uses a Decision Tree-based algorithm, that utilizes GSM and WIFI traces for transportation mode detection. The algorithm structure infers a user's mobility, being either dwelling, walking, or driving; (vi) A further prior art system is based on supervised learning to infer transportation modes from GPS logs. The system uses a graph-based post-processing algorithm, that considers both the constraint of real world and typical user behavior based on location in a probabilistic manner. This approach focuses on transportation modes including driving, walking, taking a bus and riding a bicycle; (vii) One prior art system is based on a rule learning algorithm to determine whether a smartphone user is sitting, standing, walking, or running. The system is based on accelerometer measuring data. The derived classifiers execute in part on the phones and in part on the backend servers to achieve scalable inference; (viii) A further prior art system is a classification system that uses a mobile phone with a built-in GPS receiver and an accelerometer. The transportation modes identified include whether an individual is stationary, walking, running, biking, or in motorized transport. The classification is composed of a decision tree followed by a discrete Hidden Markov Model; (ix) A prior art system uses a technical approach which is based on inferring a mode of transportation based on the GPS data collected via smartphones and the underlying transportation network data. The system is able to detect various transportation modes including car, bus, train, walking, biking and stationary. Five different inference models, Bayesian Net, Decision Tree, Random Forest, Naïve Bayesian and Multilayer Perception, can typically be used with this system; (x) Another prior art transportation mode detection system uses speed statistics derived from GPS and cellular network information and measurements, together with statistics obtained from accelerometer samples. The system uses decision tree rules and is able to distinguish between bus, Mass Rapid Transit (MRT) and taxi; (xi) A prior art system infers multi-modal itineraries from a combination of smartphone sensor data (e.g., GPS, WIFI, accelerometer) and the transport network infrastructure data (e.g., road and rail maps, public transportation timetables). In the first phase, the system uses a dynamic Bayesian network based on network and sensor data, and can distinguish between and recognize walking, biking, road vehicle, and train. The second phase attempts to match parts recognized as road vehicle or train with possible bus, train, metro, or tram based on their timetables; (xii) A probabilistic prior art system is based on inferring the transport modes and the physical paths of trips. This system uses data from GPS, Bluetooth, and accelerometer smartphone sensors. The system is based on a smartphone measurement model that is able to generate the likelihood of observing the smartphone data in the multi-modal transport network. It is formed of a structural travel model that captures the dynamic of the state of a smartphone user in the transport network, and sensor measurement models that capture the operation of sensors. The system distinguishes between five transport modes: walking, biking, car, bus and metro; and finally (xiii) a further prior art system is based on accurate determination of the transportation mode while minimizing the strain on the phone's processor and battery. The data from the internal sensors such as accelerometer, gyroscope and magnetometer are used. Different algorithm structures can be used, such as Decision Trees, Random Forest and k-Nearest Neighbors, however, typically Decision Trees structures are used. In this system, the transportation modes are limited to walking, running, riding a bike and driving a car.

In summary, the prior art systems are typically based on using one or two sensors, mostly GPS and accelerometer for transportation mode detection, mainly due to energy-consumption and computing-power reasons. The accelerometer is particularly attractive, given that it captures relevant features while being energy efficient. Thus, prior art systems that use three or more smartphone sensors are quite rare, and the accuracy and reliability of the detections is relatively low. In general, accuracy of transportation mode detection is typically higher if more data sources are utilized. External data sources are rarely employed in prior art systems, and typically include transportation network data and timetables of public transportation services. The features used in the classification task typically depend on the used sensors and the classification techniques. Most of the prior art systems try to use as few features as possible in order to minimize the computational burden of feature extractions as well as the risk of model over-fitting. However, this goes often to the disadvantage of accuracy and reliability of the systems. Due to computational consumption reasons, generative model structures are often used in cases when mobile phones are used only as a sensing system and the data analysis and classification are performed on back end servers. If the detection is intended to run on mobile devices directly, the use of generative model structures is technically limited due to their computational costs in contrast discriminative models. For such cases, technical approaches based on Decision Trees are typically used to achieving satisfactory accuracy while using the least resources.

All prior art systems are focused on stationary, walking, biking and motorized modes. In general, walking and stationary modes are predicted with higher accuracy compared to other modes by the prior art systems. This is a fundamental disadvantage of the known prior art systems. Contributions that achieve high accuracies are typically forced to be limited to the detection of a unique motorized transport mode. This is a technical problem given that a key challenge in transportation mode detection appears to be the differentiation between motorized classes such as bus, car, train and metro. With multiple motorized modes, the detection problem becomes technically difficult using the known prior art systems due to common characteristics that these modes share (e.g. the average speed and accelerations). Some prior art systems that employ external data have demonstrated their added value in detecting various motorized transportation modes. However, in the prior art, public transportation modes can only be detected when external data sources are combined with smartphone sensor data. Sometimes, external data are also used to improve the accuracy of detecting running and biking as well, which can be similar to driving. However, there it is less efficient. A further technical problem of the prior art systems is that GPS sensors may not provide reliable location and time information. The location or movement, for example, may be recorded via GPS devices or GPS-enable cellular phones or smart phone. As described above, Global Positioning System (GPS) is a satellite based navigation system that provides positioning, navigation, and timing services to users on a continuous basis. GPS is made up of three parts: orbiting satellites, control and monitoring stations, and GPS receivers. A GPS need to receiver obtains signals from at least two GPS satellites to measure the three-dimensional location (latitude, longitude, and altitude) plus the time of a GPS-enabled device. However, there may be a lack of tracking information attributed to a poor or a nonexistent connection to GPS satellites. This poor or non-existent connection to GPS satellites may be due to the user being inside a building or other structure, due to reflection off the exteriors of large buildings or other objects, due to destructive interference of the signals from towers in urban areas, or due to the type of construction materials used in some buildings. Thus, it is difficult to rely on the GPS sensor essentially or alone to track locations of the user and detect transportation modes.

Finally, in the prior art, EP 3 091 498 A1 discloses a mobile-device-based system for classifying a mode of transportation during a trip. The system comprises a mobile device including a location detection system, as a GPS system and an accelerometer. Location data and acceleration data are collected during the trip by the mobile device. The system further receives contextual data related to a plurality of transportation systems and processes the location data and first contextual data using a first transportation mode classifier associated with a first set of transportation systems and second contextual data using a second transportation mode classifier associated with a second set of transportation systems. The mode of transportation is classified by data processing during the trip and update the classifiers based on user input. Further, U.S. Pat. No. 10,630,723 B1 discloses a method for automated adjustment of policy characteristics based on a determined similarity between routes. A similarity metric is determined indicating the similarity between a first route followed by a vehicle and/or driver and a second (e.g., previous) route followed by the vehicle and/or driver. A similarity metric indicates the similarity in movements, and changes in movement, exhibited by the vehicle on the routes. The similarity metric is applied through analysis of real time data collected by in-vehicle sensors, mobile user devices, external sensors or other data sources. Based on the similarity metric, a premium, a deductible, a price, or other parameters of a policy are determined. The policy characteristics can be adjusted (e.g., in real time) based on the analysis according to changing risk conditions if a driver is following routes that are dissimilar from typical routes.

SUMMARY OF THE INVENTION

It is one object of the present invention to provide a more reliable and accurate automated system for transportation mode recognition of a user based on measured sensory data of a mobile device, such as a cellular mobile phone or a smart phone. The mobile device should be able to automatically detect and identify a user activity, and distinguishing between different walking and driving modes, or other manual and mechanical locomotion patterns. Independent of possibly available, dedicated in-vehicle hardware, maybe providing alternative solutions, the invention shall provide an appropriate system and method for transportation mode recognition, in particular real-time transportation mode recognition, and more particularly continuous real-time tracking and transportation mode recognition, solely based on the available sensors of a smartphone user. The output signaling of the transport mode recognition should achieve an accuracy to be usable for as input signaling for electronically triggering or steering various technical, transport-mode dependent processes. For example, the present automated transport mode recognition should be applicable to location and/or transport mode dependent, automated systems, such as personal navigation systems enabling to automatically switch modes to appropriate data capturing processes or formats, the mode reflecting the type of locomotion. Other location and/or transport mode dependent, automated systems can e.g. comprise usage-based risk-transfer processes and/or appropriate usage-based real-time risk-transfer systems, the automated usage-based real-time risk-transfer systems being enabled by the signaling of the automated transport mode recognition to perform the location and/or transport-mode dependent risk-transfer processes.

According to the present invention, these objects are in particular achieved with the features of the independent claims. In addition, further advantageous embodiments can be derived from the dependent claims and the related descriptions.

According to the present invention, the above-mentioned objects for automated transportation mode recognition based on sensory data measured by a plurality of sensors of a cellular mobile device of a user are in particular achieved in that, the plurality of sensors at least comprise an accelerometer and a GPS sensor and the mobile device comprises one or more wireless connections, wherein by at least one of the wireless connection, the cellular mobile device acts as a wireless node within a cellular data transmission network by means of antenna connections of the cellular mobile device to the cellular data transmission network, and the plurality of sensors being connected to a monitoring mobile node application of the mobile device, wherein the monitoring mobile node application captures usage-based and/or user-based sensory data of the cellular mobile device and/or the user of the cellular mobile device, in that the mobile device measures time series of sensory parameter values based on measuring parameters obtained from the mobile device's sensors, the measuring parameters comprise time series of sensory parameter values of a 3-axis accelerometer as sensor and time series of sensory parameter values of GPS-based speed measurements of a GPS receiver as sensor, wherein the GPS sensor measures the mobile device's longitude, latitude and altitude position by measuring different speed of light delays in the signals coming from two or more satellites, and in that the measured time series of sensory parameter values trigger the automated transportation mode recognition as input feature values to a gradient boosting machine-learning classifier, the transportation modes at least comprising the modes public transportation (train and/or tram and/or bus) and/or motorcycle and/or cycling and/or plane and/or car and/or skiing and/or boat, and the transportation mode recognition generating a transport mode label for a transport mode movement pattern of a trip.

As an embodiment variant, a supervised learning structure can e.g. applied to the gradient boosting machine-learning classifier during a supervised learning phase, wherein transport mode movement patterns of measured trips are stored to a trips database, in that the mobile device measures sensory movement parameters based on measuring parameters obtained from mobile devices' sensors of a heterogeneous set of users, wherein transport mode movement patterns of a trip are identified from the measured sensory movement parameter values, and wherein each trip comprises measured sensory movement parameter values of GPS positions by a GPS-sensor device, and of acceleration forces being applied to the mobile device on all three physical axes by a 3-axis accelerometer, and of operating system activities parameter values of an operating system of the mobile device, and a transport mode label value, and in that trips with transport mode labels detected by the gradient boosting machine-learning classifier are fed into a user back-loop for dynamic correction by a user associated with the respective trip and saved to the trips database by updating the learning transport mode movement patterns of measured trips in the trips database.

As further embodiment variants the trips database can e.g. be monitored by the system automatically detecting changes in the trips database, wherein upon detecting a change in the trips database, the supervised learning phase is reinitiated. The trips database can e.g. be updated continuously and/or dynamically based on the applied user back-loop. For the supervised learning phase, the trips of the trips database can e.g. be preprocessed by filtering out transport mode movement patterns, which have a time duration shorter than 1 minute and/or comprise less than 30 GPS positions and/or do not have a proper transport mode labelling. For the supervised learning phase, the trips of the trips database can e.g. be preprocessed by filtering out transport mode movement patterns having duplicated GPS locations by timestamp and/or transport mode movement patterns with GPS locations having negative speed and/or transport mode movement patterns having GPS locations with an accuracy>50 m. Upon detection by the gradient boosting machine-learning classifier and the generation of the transport mode label for a transport mode movement pattern of a trip, the trips can e.g. be postprocessed by a set of hard coded rules, reinforcing avoidance of incorrect and/or insufficiently confident recognition. User's routines can e.g. be automatically detected by a trip familiarity-based recognition structure increasing the accuracy of the automated transportation mode recognition. The transport mode movement patterns of measured trips stored to the trips database can e.g. be processed for data enrichment, where the data enrichment process comprises route-matching of the trips with the transport mode movement patterns based on roadmaps and/or GIS-geometry mapping of the trips with the transport mode movement patterns based on spatial and geographic GIS data, and/or public transport mapping based on public transport road maps and timetable data. The measuring parameters of the time series of sensory parameter values of the GPS-based speed measurements can e.g. further comprise extracted average GPS-based speed measurements and/or standard deviation of the GPS-based speed measurements and/or percentiles values from 0 to 100 of the GPS-based speed measurements in predefined percentile steps. The percentile steps can e.g. comprise a granularity of a factor 10. The measuring parameters of the time series of sensory parameter values of the GPS-based altitude position measurements can e.g. further comprise measuring a standard deviation extracted from the altitude position measurement. The measured time series of sensory parameter values can e.g. comprise GPS-based acceleration measurements derived based on the measured ratio between (a) the measured speed difference between a measured set of GPS parameter values and a measured subsequent set of GPS parameter values, and (b) the measured time difference between the measured set of GPS parameter values and the measured subsequent set of GPS parameter values. The GPS-based measurement of the acceleration can e.g. comprise measuring a standard deviation extracted from the acceleration measurement and/or measuring a variance value of the measured GPS-based accelerations by measuring the angle between triplets of consecutive GPS points. The measuring parameters of the time series of sensory parameter values of the accelerometer measurements can e.g. further comprise percentiles values from 0 to 100 of the accelerometer measurements in predefined percentile steps and/or interquartile range values measured by the difference between the 75th and the 25th percentile. Said percentile steps can e.g. comprise a granularity of a factor 10. In case of two or more accelerometer measurements having the same timestamps, the last one with respect to an accelerometer measurement order can e.g. be selected, and an accelerometer measurement norm value is generated over the accelerometer measurements of the measured trip, wherein an average of the accelerometer measurements of the measured trip is removed form said measured trip. The operating system activities parameter values of an operating system of the mobile device can e.g. comprise unique timestamp and a map of labels with probability measures, wherein in case of the absence of a label, the probability measure is set to 0. Said labels of the map can e.g. be normalized to ‘Automotive’, ‘Cycling’, ‘OnFoot’, ‘Running’, ‘Stationary’, ‘Unknown’, ‘Walking’, and ‘Tilting’ denoting a feature vector for naming compliance between the two operating systems. For achieving a forward integral generation by the system, a label probability can e.g. be assumed to be valid until a next event is measured, wherein each label probability is multiplied by the measured milliseconds elapsed until the next event, or until the end of the trip for the last received activity event, wherein this multiplication is performed for each label of the label list, wherein the multiplied label probabilities for each label are summed up, and wherein each sum is divided by the difference between trip end time and the first activity event time, both in milliseconds. In case of a label being never returned, the corresponding feature can e.g. be set to 0, so that if there are no activities at all for a measured trip, all the operating system activities parameter values are set to 0. The data enrichment process comprising public transport mapping based on public transport road maps and timetable data can e.g. comprise identifying for a set of measured GPS location parameters candidate stops as sequences of points that fulfill the condition of: (i) measured speed<=3 m/s; and (ii) candidate sequences are longer than 5 seconds, wherein the identification is performed after applying a moving average with window length 9 over an array of measured speeds, replacing each sample the average of the sample itself and the 4 samples before and after, and wherein for each of these candidate sequences, the average latitude and average longitude is generated, obtaining a candidate stop position for each sequence/stop. Further a hyperparameter configuration can e.g. be applied to the gradient boosting machine-learning classifier comprising the values 225 for the n-estimators, 0.03 for the learning-rate, 30 for the max-depth, 50 for the num-leaves, 0.8 for the subsample, 0.7 for the colsample-bytree and 5 for the min-sum-hessian-in-leaf.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be explained in more detail, by way of example, with reference to the drawings in which:

FIG. 1 shows a block diagram schematically illustrating an exemplary system for the inventive transport mode recognition system 113. The automated transportation mode recognition 113 is based on sensory data 3/31/32/33 measured by a plurality of sensors 102 of a cellular mobile device 10 of a user 6. The plurality of sensors 102 at least comprise an accelerometer 1025 and a GPS sensing device 1024. The mobile device 10 comprising one or more wireless connections 105. By at least one of the wireless connection 105 the cellular mobile device 10 acts as a wireless node 221, . . . , 225 within a cellular data transmission network 2 by means of antenna connections of the cellular mobile device 10 to the cellular data transmission network 2. The plurality of sensors 102 is connected to a monitoring mobile node application 101 of the mobile device 10. The monitoring mobile node application 101 captures usage-based 3 and/or user-based sensory data 3 by means of the sensors 102 of the cellular mobile device 10 and/or the user 6 of the cellular mobile device 10. As an embodiment variant, the mobile device 10 can also access sensory data of external sensory devices, as e.g. in-car sensors, or smart-house sensors, over interfaces as Bluetooth or WIFI etc.

FIG. 2 shows a block diagram schematically illustrating an embodiment variant of an exemplary system for automated transportation mode recognition 113. A supervised learning structure 1136 is applied to the gradient boosting machine-learning classifier 1131 of the transportation mode recognition 113 during a supervised learning phase. Transport mode movement patterns 11351 of measured trips 1135 are stored to a trips database 33. The mobile device 10 measures sensory movement parameters 311,312,313;321,322,323 based on measuring parameters obtained from sensors 102 of mobile devices 10 of a heterogeneous set of users 6. Transport mode movement patterns 11351 of a trip 1135 are identified from the measured sensory movement parameter values 311,312,313;321,322,323 by the transportation mode recognition devices or system 113, wherein each trip comprises at least measured sensory movement parameter values 311,312,313;321,322,323 of GPS positions by the GPS-sensor 1024/102, and of acceleration forces being applied to the mobile device 10 on all three physical axes by a 3-axis accelerometer 1025/1902, and of operating system activities parameter values of an operating system of the mobile device 10, and a transport mode label value 1134.bTrips (1135) with transport mode labels 1134 detected by the gradient boosting machine-learning classifier 1131 are fed into a user back-loop 1136 for dynamic correction by a user associated with the respective trip 1135 and saved to the trips database 33 by updating the learning transport mode movement patterns of measured trips 1135 in the trips database 33. The reliability of the automated transport-mode recognition increases as more data points are accumulated. If the system 113 fails to recognize the mode of transport correctly, users have the option to manually correct the predicted transport mode in the system 113. The changes are automatically detected and the supervised learning structure is retrained in order to avoid repetition of the same mistake and improve the overall performance: the TMR-system's 113 prediction capabilities improve in a continuous cycle.

FIG. 3 shows another block diagram schematically illustrating exemplary how for each of candidate sequences, the average latitude and average longitude is generated by the TMR system 113, obtaining a candidate stop position for each sequence/stop. By using the public transport algorithm inputs and outputs, additional features can be generated by the TMR system 113: (i) the number of candidate stops of the trip (trajectory stops) (CandidateStopsCount), (ii) the number of candidate stops of the trip (trajectory stops) divided by the cumulated sum of haversine distances between the 16 sampled GPS points, ordered increasingly by time, in meters (CandidateStopsCountNormalized), (iii) the number of suggested stops for the best matching API suggestion (PublicRoutingNumStops), (iv) the cumulated haversine distance of the suggestion stops, in order of traversal, divided by the cumulated haversine distance of the 16 sampled GPS points (PublicRoutingDistRatio), (v) the cumulated haversine distance of the candidate stops, divided by the cumulated haversine distance of the 16 sampled GPS points (PublicRoutingCandidateDistRatio), and/or (vi) the percentiles from 0 to 100, with step 10, of the minimum distances from the suggestion stops to the candidate stops (this is the standard public stop algorithm). These features can be generated for all the suggestions, but the ones selected are the ones regarding the suggestion with minimum distance between suggestion stops and candidate stops.

FIG. 4 shows block diagram schematically illustrating an exemplary performances achieved by the overall automated TMR system 113, which are described by the confusion matrix of FIG. 4 and the following table, and obtained through a 5-fold Cross-Measurement with a leave k-users out splitting technique, in order to reduce overfitting.

Transport Mode Support Recall Precision boat 12 100.00% 100.00% car 12710  98.68%  94.98% cycling 407  71.74%  91.54% motorcycle 851  53.94%  88.78% other 13  30.77%   2.60% plane 115  77.39%  88.12% public 1000  77.90%  92.63% skiing 349  93.70%  92.90% train 316  82.59%  95.96%

FIG. 5 shows a diagram illustrating an exemplary architecture of the data preprocessing. Before being inputted to the machine learning structure of the TMR system 113, the time series pass through the following preprocessing steps: (i) Rotation of the 3-axis accelerometer from the smartphone reference system to the vehicle reference system, (ii) Alignment between accelerometer and GPS, sharing a common 10 Hz sampling grid, and (iii) Each trip is split into multiple 5 minutes long mini-trips. The final input to the TMR system 113 is for this exemplary case a 4-dimensional time series, with a fixed length of 3000 timesteps (5 minutes*10 Hz).

FIG. 6 shows a diagram illustrating an exemplary performance of the automated TMR system 113. Performances have been measured and assessed through a 5-fold Cross-Measurement or Cross-Validation with a leave k-users out splitting technique, leading to the results shown in FIG. 6 and the following table:

Transport Mode Precision Recall F1−Score Car 93.63% 94.58% 94.10% Moto 89.02% 87.23% 88.11%

FIG. 7 shows another block diagram illustrating schematic an exemplary overview of the architecture of the Transport Mode Recognition system part of system 1.

FIG. 8 shows a block diagram illustrating schematic an exemplary overview of the trip extraction process.

FIG. 9 shows a diagram illustrating schematic an exemplary Car/NoCar performance (F1 score) with minimum accuracy as a free parameter.

FIGS. 10a and 10b show diagrams illustrating schematic an exemplary TMR performance (F1 score) with number of sampled points as a free parameter.

FIG. 11 show a diagram illustrating schematic an exemplary candidate stops extraction.

FIG. 12 shows a block diagram illustrating schematic an exemplary trip enrichment process.

FIG. 13 shows a block diagram illustrating schematic exemplary feature extraction modules.

FIG. 14 shows a diagram illustrating schematic an exemplary recursive feature elimination used for the transport mode recognition TMR of the system 1.

FIG. 15 shows a diagram illustrating schematic an exemplary Grid exploration of the number of trees and tree depth parameters.

FIG. 16 shows a diagram illustrating schematic an exemplary early TMR detection for car/nocar classifier, F1 score.

FIG. 17 and FIG. 18 show respectively the performances of the current TMR service and the proposed solution, where FIG. 17 shows the distributions of true labels, performance of the deployed solution (baseline), and FIG. 18 shows the distributions of true labels, proposed solution.

FIG. 19 shows a diagram illustrating schematic an exemplary F1 score varying TMR label weight (probability mass assigned to the automatic label).

FIG. 20 shows a diagram illustrating schematic an exemplary the design of an index value used for the generation of the familiarity and familiarity score, so that it orders the users with the following order, given the clusters dimensions (x-axis: cluster number, y-axis: cluster dimension).

FIG. 21 shows a diagram illustrating schematic the correlation between the Gini index and the index (denoted as “new index”), used in the proposed embodiment variant.

FIG. 22 shows a diagram illustrating schematic an exemplary user going from the same point A to the same point B, but passing through different links. This behavior causes low aggregation in Link familiarity embodiment variant and high aggregation in Start Stop embodiment variant.

FIG. 23 shows a diagram illustrating schematic exemplary cases in which the user travels the same streets but the way the geocoding measuring (e.g. HERE) gives the links causes a wrong behavior in the link method. Typically happens that big streets have two different linkIDs for the two direction of the street, or two streets are too near and HERE spots the user in the wrong one.

FIG. 24 shows a diagram illustrating schematic an exemplary occurrence of the second case when the user goes once from point A to point B1 (session S1), and once from A to B2 (session S2), as shown in FIG. 23. If S1 and S2 have enough links in common (the user travels the same path but ends up in different places) the two trips are clustered together in the Link method but not in the Start Stop method (in the cases in which the stop points are not enough near).

FIG. 25 shows a diagram illustrating schematic an exemplary embodiment variant of the Bag of Links (BOL), which does not generate clusters, so a direct comparison on how the trips are agglomerated cannot be performed. However, a good inspection on this method can be done considering the get_familiarity process, respect to the other get_familiarity of the other embodiment variants. The case in which the BOL embodiment variant becomes useful is when the user does a new trip using only link that has already travelled in each of the previous sessions, but without covering the 80 percent of the shortest of these sessions. In this case the start and stop points are far away so the get_familiarity start stop will return 0, also the number of links in common are not enough to cover the 80 percent of links so also the get_familiarity of the link methods will return a low score. This new method instead will give a maximum scores of 1 (see FIG. 23).

FIG. 26 shows a diagram illustrating schematic an exemplary measuring of a trip using an appropriate trip summary. When a TMR 113 request is received live, the system 1 respectively the TMR 113 checks if a user already annotated or corrected a similar trip. Consequently, the system 1 must be able to efficiently retrieve historical annotated trip data and define a trajectory similarity measure. Since the TMR 113 live request contains a representation of the trip with 19 points, in the present embodiment variant, it makes sense to store this representation for each annotated trip, partitioned by a user identifier. This can e.g. be done in a database or a filesystem (e.g. one row per trip). The user annotation preferably can e.g. be stored together with the trip summary. This trip summary can be built/updated in batch using, for example, Databricks (e.g. nightly). The embodiment variant can imply information availability within 24/48 h from user annotation. Existing facilities and other approaches can be considered as well.

FIG. 27 shows a diagram with a TMR baseline (given by the straight line) illustrating schematic an exemplary weighting of the parameters and evaluating the performance under TMR 113. The multiclass probabilities can e.g. be weighted less than the annotation probability. This is in line with the fact, that, if the user corrected a trip in the past and a similar trip was observed by the system 1, the user should be trusted. The proposed value for the weight is 0.4.

FIG. 28 shows a diagram illustrating an exemplary embodiment variant of the DPD 112, which can be used for the trip familiarity detection 115, and which can e.g. comprise the following technical steps performed by the system 1 and the trip familiarity detection and measuring 115, respectively: (1) Collect user history, (2) Cluster similar trips, (3) Define centroid trip, (4) New trips arrives: seek match with existing clusters, and (5) Check cluster DPD label. In FIG. 76, (i) N is the total number of sessions with DPD score in the cluster, (ii) Di∈[0, 1]P1∈[0,1] and Xi∈[0, 1] are final confidence scores returned by DPD for each sessions (including enter/exit and BT connection), and (iii) cluster scores can be also generated from user annotations (Truth) or eventually from a combination of both sources.

FIG. 29 shows a diagram illustrating the exemplary objective of the familiarity score to create a measure for scoring purposes on how much a user travel on familiar roads. This can e.g. require the three different methods, as illustrated by FIG. 29, i.e. (1) Clustering through linkID, (ii) bag of links: linkIDs frequency, and (iii) start & stop.

FIG. 30 shows a diagram illustrating an exemplary realization of the start&stop method, as a powerful approach.

FIG. 31 shows an exemplary overview of a possible general architecture of the trip familiarity detection and measuring.

FIG. 32 shows a diagram illustrating an exemplary realization of an embodiment variant using a similarity prefilter technique, in particular for TMR 113, where the data processing is preferably performed only on a subset of likely candidates. A trip is considered a valid candidate of its start and end both lie within a certain radius from the start/end of the current trip (the one that is evaluating in a TMR live request). The radius can e.g. be set to 500 meters for this example, based on empirical observation. Since user annotations can be in limited number (in normal operating conditions) and using the proposed similarity prefilter, the trajectory similarity is actually generated against a small subset of trips, which is illustrated in FIG. 80.

 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 schematically illustrates an architecture for a possible implementation of an embodiment of the system and method for automated transportation mode recognition 113 based on sensory data 3/31/32/33 measured by a plurality of sensors 102 of a cellular mobile device 10 of a user 6. The plurality of sensors 102 at least comprise each an accelerometer 1025 and a GPS sensor 1024. The mobile device 10 comprise one or more wireless connections 105. By at least one of the wireless connection 105 the cellular mobile device 10 acts as a wireless node 221, . . . , 225 within a cellular data transmission network 2 by means of antenna connections of the cellular mobile device 10 to the cellular data transmission network 2. The plurality of sensors 102 are connected to a monitoring mobile node application 101 of the mobile device 10. The monitoring mobile node application 101 captures usage-based 3 and/or user-based sensory data 3 of the cellular mobile device 10 and/or the user 6 of the cellular mobile device 10.

The mobile device 10 measures time series 311,312,313;321,322,323 of sensory parameter values based on measuring parameters 3 obtained from the mobile device's 10 sensors 102. The measuring parameters 3 comprise time series 311,312,313 of sensory parameter values 31 of a 3-axis accelerometer 1025/102 and time series 321,322,323 of sensory parameter values 32 of GPS-based speed measurements of a GPS sensor 1024 /102. The GPS sensor 1024/102 measures the mobile device's 10 longitude 10241, latitude 10242 and altitude 10243 position by measuring different speed of light delays in the signals coming from two or more satellites.

The measured time series 31 1,312,313;321,322,323 of sensory parameter values trigger the automated transportation mode recognition 113 as input feature values 1132 to a gradient boosting machine-learning classifier 1131. The transportation modes 1133 at least comprise the modes (i) public transportation 11331 and/or (ii) motorcycle 11332 and/or (iii) cycling 11333 and/or (iv) train 11334 and/or (v) tram 11335 and/or (vi) plane 11336 and/or (vii) car 11337 and/or (viii) skiing 11338 and/or (ix) boat 11339. The transportation mode recognition 113 generates a transport mode label 1134 fora transport mode movement pattern 11351 of a trip 1135.

In a learning phase, which also can be dynamically or periodically applied, as FIG. 2 shows, a supervised learning structure 1136 is applied to the gradient boosting machine-learning classifier 1131 during a supervised learning phase. The transport mode movement patterns 11351 of measured trips 1135 are stored to a trips database 33, The mobile device 10 measures sensory movement parameters 311,312,313;321,322,323 based on measuring parameters obtained from sensors 102 of mobile devices 10 of heterogeneous set of users. The transport mode movement patterns 11351 of a trip 1135 are identified from the measured sensory movement parameter values 311,312,313;321,322,323. Each recognized trip comprises measured sensory movement parameter values 311,312,313;321,322,323 of GPS positions by the GPS-sensor 1024/102, and of acceleration forces being applied to the mobile device 10 on all three physical axes by a 3-axis accelerometer 1025/1902, and of operating system activities parameter values of an operating system of the mobile device 10, and a transport mode label value 1134. Trips 1135 with transport mode labels 1134 detected by the gradient boosting machine-learning classifier 1131 are fed into a user back-loop 1136 for dynamic correction by a user associated with the respective trip 1135 and saved to the trips database 33 by updating the learning transport mode movement patterns of measured trips 1135 in the trips database 33. As an embodiment variant, the trips database 33 is monitored by the system automatically detecting changes in the trips database 33, wherein upon detecting a change in the trips database 33, the supervised learning phase 1136 is reinitiated. In particular, the trips database can be updated continuously and/or dynamically based on the applied user back-loop. Further, for the supervised learning phase, the trips of the trips database 33 can e.g. be preprocessed by filtering out transport mode movement patterns, which have a time duration shorter than 1 minute and/or comprise less than 30 GPS positions and/or do not have a proper transport mode labelling. For the supervised learning phase, the trips of the trips database 33 can e.g. preprocessed by filtering out transport mode movement patterns having duplicated GPS locations by timestamp and/or transport mode movement patterns with GPS locations having negative speed and/or transport mode movement patterns having GPS locations with an accuracy>50 m.

It is important to note, that the present disclosure focus on smartphone data used for transportation mode detection (TMR). Automated TMR is an essential technical requirement for many applications, including transportation monitoring, optimization, analysis and studies, urban planning, health monitoring, computer supported elder-care, epidemiology, dynamic usage-based risk-transfer, electronic traffic guidance systems, navigation systems and mobile applications etc. With the knowledge of travelers' transportation mode, targeted and customized advertisements may be sent to their devices, allowing a new way auf automation. The output signaling of automated TMR systems is also useful for the development of context aware cell phones that sense the current context and adapt their behavior accordingly. Also, if the precise transportation modes of individual users are discovered, it is possible to provide a more realistic picture of travel demand. The TMR detection may also help to monitor and detect the environmental impact of measured travel patterns, such as carbon footprints of users, and track the daily step count of users and amount of calories they burn. Another application is the detection of real-time traffic state because companies such as Google or TomTom collect data from mobile phones in order to estimate the traffic speed on roads. In summary, automated TMR systems have a plurality of technical applications and solve a variety of technical problems.

The fact that transport mode detection based on GPS tracking data is technically extremely challenging, especially when the GPS tracking data is unlabeled, i.e., there is no information regarding the transport mode used during a trip, it can technically be advantageously to use the present automated TMR system 113 as a part of a more integrated technical environment, such as in combination with automated trip familiarity detection 114 (as discussed below), and/or automated passenger-driver detection 112 by sensory parameter value patterns of mobile devices 10, as also exemplary shown in FIG. 1.

In further embodiment variants, the signaling output of the present transport mode recognition system 113 can e.g. be used as steering or input signals for Advanced Driver Assistance Systems (ADAS), traffic control systems, navigation system, usage-based risk measuring and monitoring systems etc. For example, the system 1 can e.g. comprise one or more automated first-tier risk-transfer systems 12 (automated primary insurance systems) and one or more automated second-tier risk-transfer systems 13 (automated reinsurance systems). The automated first-tier risk-transfer systems 12 can comprise at least one electronic first-tier resource-pooling system 121 and the automated second-tier risk-transfer systems 13 can e.g. comprise at least one electronic second-tier resource-pooling system 131. Resource-pooling systems 121/131 are systems for automated, electronically steered pooling of resources from assigned risk exposed occupants/drivers/passengers 6/61/62, thereby transferring a defined risk associated with the risk exposed user 6 to the automated first-tier and/or second-tier systems 12/13, wherein the operation of the transferred risk is defined by risk-transfer parameters 122/132, e.g. predefined by means of predefined parameters given by risk-transfer policies, and wherein in case of triggering the occurrence of the defined risk at a user 6, an occurring and detected loss of the concerned risk exposed user 6 is distinctively covered by the automated resource-pooling systems 121/131 by triggering the specific transfer of resources from the resource-pooling system 121/131 to the concerned risk exposed user 6, e.g. through appropriate signaling based on generated payment transfer parameters 123/133. The operation of such a system 1 will be described in detail below. The risk-transfer parameters 122/132 can e.g. comprise parameters defining physical measuring parameters to detect the occurrence of a risk event at the risk exposed user 6, by means of the system 1 and/or time—or amount related threshold values. The risk exposed user 6 can be any type of person and the risk can e.g. be associated with vehicle-or car-driving or traffic risk, e.g. associated with a driver or passenger. A risk is related to the probability for the occurrence of an impacting event in relation to risk-exposed user 6. The automated system 1 can e.g. include at least a processor and associated memory modules. The operation of the system 1 is controlled, monitored and steered by the electronic control device 11, in particular generating appropriate signaling and steering the activation and interworking of the various components of the automated system 1. The automated system 1 can also include one or more display units and operating elements, such as a keyboard, and/or graphic pointing devices, such as a computer mouse. The system 1 is a technical device inter alia comprising electronic means used in the field of computer and data processing technology, telematic technology and automated risk transfer or insurance technology. The invention seeks to technically capture, manage and automate complex related operations of monitoring devices.

Transport Mode Recognition (TMR) 113

The architecture of the Transport Mode Recognition (TMR) system represents a Machine Learning (ML) based solution: a collection of labeled trips performed by a heterogeneous set of users is measured and analyzed to extract a set of features that is used to train a supervised multiclassification Machine Learning structure. The output of the pure Machine Learning structure is then postprocessed by a set of hard coded rules, in order to avoid the algorithm to make clearly incorrect or insufficiently confident predictions. An additional add-on module based on Trip Familiarity can recognize the user's routines and can be activated to increase the model performances. The reliability of the automated transport-mode recognition increases as more data points are accumulated, where the accumulation can be performed by an automated process, das described below. As an embodiment variant, if the ML structure fails to recognize the mode of transport correctly, users can have the option to manually correct the predicted transport mode in the system. The changes can be automatically detected, and the supervised model is retrained in order to avoid repetition of the same mistake and improve the overall performance: the model's prediction capabilities improve in a continuous cycle (see FIG. 2).

The measuring data used to build the TMR system consist of trips being captured and hold by appropriate data structures, wherein each trip comprises the following measuring parameters measured and recorded by a mobile device: (i) GPS Positions, (ii) 3-axis Accelerometer, (iii) Operating System Activities, and (iv) Transport Mode Label annotation. The trips can comprise, for example, measuring data for transport modes as car, motorcycle, tram, bus, cycling, skiing, train, plane, boat, or others.

The system can e.g. apply a data filtering and preprocessing. For example, of the trips, data can be filtered out based on the following conditions: (i) At least one minute long, (ii) At least 30 GPS positions, and (iii) Exactly transport mode annotation. As a further preprocessing step, trips comprising duplicated GPS locations by timestamp, GPS locations that have negative speed and GPS locations that have accuracy>50 m can e.g. be removed.

The system can further comprise a data enrichment process. For example, the trip data can be enriched. As an embodiment variant, the enrichment processes can also be based on external APIs of third party providers. The performed enrichments can e.g. comprise: (i) Route matching, in order to understand if the trip was performed on a road, (ii) Query using a Geographic Information System (GIS) geometries near the trip, the GIS capturing spatial and geographic data, (iii) Public transport matching. For the data enrichment, as a variant, the enrichment does not need to be performed on the full GPS track to perform, but (for example due to some APIs limitations) only a subset equally spaced GPS positions can be used.

The measured and generated features for the available trip data can e.g. comprise:

(1) GPS features comprising over the array of measured GPS speeds (i) Average, (ii) Standard deviation, and (iii) Percentiles from 0 to 100, with step 10 (so percentile 0, 10, 20 . . . ). Over the array of measured GPS altitudes of a trip the standard deviation, and over the measured array of GPS accelerations (i) the standard deviation, and (ii) the variance of the array obtained by measuring the angle between triplets of consecutive GPS points. GPS acceleration is defined herein as the ratio between the following two arrays: (i) Speed difference between a GPS sample and the preceding sample, (ii) Time difference (in ms) between a GPS sample and the preceding sample.

(2) Accelerometer features: If two or more accelerometer samples have the same timestamps, the last one can e.g. be selected with respect to array order. The acceleration norm array is then computed and, the average of this array is removed from all the same array. From the norm array, the following parameters can be extracted: (i) The percentiles from 0 to 100, with step 10; (ii) The interquartile range, which is the difference between the 75th and the 25th percentile.

(3) Features based on operating system activities: Two features using the operating system activities can e.g. be selected, based on the following criteria: (i) “Forward integral” processing is chosen because of the event-wise behavior of the activity labels, and since it's generally the most informative feature, (ii) “Count as most probable” processing can e.g. be chosen for simplicity. An activity event can be defined as a measuring object with a unique timestamp and a map of labels with probabilities (if a label is absent is considered to have zero probability). The two features are calculated for each possible label. Labels can be normalized to the Android names: ‘Automotive’, ‘Cycling’, ‘OnFoot’, ‘Running’, ‘Stationary’, ‘Unknown’, ‘Walking’, ‘Tilting’ for feature vector naming compliance between the two operating systems. The “forward Integral processing” can be implemented by assuming that a label probability is valid until the next event. Each label probability can be multiplied by the milliseconds elapsed until the next event, or until the end of the trip for the last received activity event. This must be done for each label of the possible label list. The results of these multiplications can be summed up for each label, and each sum can be divided by the difference between trip end time and the first activity event time, both in milliseconds. If a label is never returned, the corresponding feature should be set to zero. So, if there are no activities at all for a trip, all the features should be set to zero. The “count as most probable” processing can e.g. be implemented, in that for each possible label the number of events is counted, in which the label was the most probable one, where the count is then divided by the total number of events (or the number of unique timestamps). In case of a 50/50 draw, the most probable can be selected in any way.

(3) Public transport features: Given the set of GPS locations, candidate stops can e.g. be identified as sequences of points that fulfill the following conditions: (i) Speed<=3 m/s, (ii) Sequences are longer than 5 seconds. The calculation can be performed after applying a moving average with window length 9 over the array of speeds. This means that every sample is replaced by the average of the sample itself and the 4 samples before and after. For each of these candidate sequences, the average latitude and average longitude can be generated, obtaining a candidate stop position for each sequence/stop (see FIG. 3). Using the public transport algorithm inputs and outputs, some additional features can be generated, comprising: (1) the number of candidate stops of the trip (trajectory stops), (2) the number of candidate stops of the trip (trajectory stops) divided by the cumulated sum of haversine distances between the 16 sampled GPS points, ordered increasingly by time, in meters, (3) the number of suggested stops for the best matching API suggestion, (4) the cumulated haversine distance of the suggestion stops, in order of traversal, divided by the cumulated haversine distance of the sampled GPS points, (5) the cumulated haversine distance of the candidate stops, divided by the cumulated haversine distance of the 16 sampled GPS points (see point 2), and (6) the percentiles from 0 to 100, with e.g. step 10, of the minimum distances from the suggestion stops to the candidate stops (this is the standard public stop algorithm). These features can be generated for all the suggestions, but the ones selected are the ones regarding the suggestion with minimum distance between suggestion stops and candidate stops.

(4) Route Matching (RM features: Route matching features can e.g. be generated in order to estimate, based on the sampled GPS points, if the trip was not performed on a road. Two statistical descriptors can e.g. be generated over the trace points confidences: (i) the average of the confidences, and (ii) the variance of confidences.

(5) Geofencing (GFE) features: Using the geometries returned by general geofencing, the features used by the proximity search can e.g. be generalized. Basically, given the enrichment for the sampled GPS points, the percentage of points can be generated having geometries within 10, 20, 30 . . . 100 meters. This possibly includes points within a geometry, having distance<0. These distributions are can e.g. be generated for: (i) percentage of points seeing only roads within a XX radius (XX from 10 to 100, with step 10), (ii) the percentage of points seeing only rail tracks within a XX radius, (iii) the percentage of points seeing or roads or rail tracks within a XX radius, (iv) the percentage of points within an airport (negative geometry distance), and (v) the percentage of points within an airport (negative geometry distance).

The set of features described above can e.g. be used to feed the machine-learning gradient boosting structure (e.g. LightGBM) with the following hyperparameters configuration: n-estimators=225, learning-rate=0.03, max-depth=30, num-leaves =50, subsample=0.8, subsample=0.7, and min-sum-hessian-in-leaf=5.

For the hardcoded filtering rules, for example, some custom logic can be added after the Machine Learning classifier in order to limit unwanted mistakes. The first set of rules works on the trip features, to correct predictions that are clearly wrong. The second set of rules acts only on the trip modes with low precision, adjusting the predictions that have a low level of confidence, with the goal to reduce the false positive rate.

The rules based on trip features can e.g. comprise: (i) If GFEWater0>0.5 mark this trip as ‘boat’, (ii) If GFEWater0<0.2 and TMR-prediction=‘boat’, mark this trip as ‘other’, (iii) If SpeedQuantile90>150 m/s, mark the trip as ‘plane’, and (iv) If TMR-prediction=‘plane’ and SpeedQuantile100<20 m/s and GFEAirport=0, mark this trip as ‘other’. A rules based on model confidence can e.g. be implemented, where if Predicted Transport Mode>Score Threshold, the prediction will be changed to Fallback Transport Mode

Predicted Score Fallback Transport Mode Threshold Transport Mode Public 0.80 Car Motorcycle 0.90 Car Cycling 0.88 Other Train 0.85 Other Plane 0.85 Other

FIG. 4 shows exemplary performances achieved by the TMR system as illustrated by the confusion matrix and table of FIG. 4 and obtained through a 5-fold Cross-Validation with a leave k-users out splitting technique, in order to reduce overfitting.

As an embodiment variant, in addition to the supervised learning structure for TMR, a trip similarity strategy can be applied to further raise the TMR performances and accuracy. The idea is leveraging user annotations over previous similar trips, if any, and use this information to correct TMR labels, if needed. Thus, to find similar trips, a clustering algorithm can e.g. be run on the following features: (i) Distance between Trips Starting point*, (ii) Distance between Trips Ending point*, (iii) Trip Distances (* distance between start/ending points of the two trips is repeated after reversing one trip, to ignore the travel direction).

In order to improve the recognition between Car and Moto modes of transport, in an even further embodiment variant, a dedicated binary classifier can be applied. Leveraging the used Deep Learning architectures, the dedicated binary classifier aims to extract discriminating features directly from smartphone sensor time series: (i) 3-axis accelerometer, and (ii) GPS Speed.

As further data preprocessing, the time series can e.g. pass through the following preprocessing steps, before being ingested by the neural network: (i) Rotation of the 3-axis accelerometer from the smartphone reference system to the vehicle reference system, (ii) Alignment between accelerometer and GPS, sharing a common 10 Hz sampling grid, (iii) Each trip is split into multiple 5 minutes long mini-trips. The final input to model can e.g. be then a 4-dimensional time series, with a fixed length of 3000 timesteps (5 minutes*10 Hz).

An exemplary model architecture is shown in FIG. 3. Further, performances can e.g. be assessed through a 5-fold Cross-Validation with a leave k-users out splitting technique, leading to the results as shown in FIG. 4.

It has to be noted, that in various embodiment variants, the architecture of the Transport Mode Recognition system is very flexible and can be performed on a variety of environments, as e.g. the Databricks environment. The example of the Databricks environment has e.g. the advantages: (1) Having a shared codebase for quick prototyping and testing; (2) Enabling the reuse of the output code directly in the solution deploy; and (3) Get advantage of native Spark parallelism in order to perform multiple experiments and test different approaches. Other environments may have different advantages. Databricks is a technical environment growing out of the AMPLab project at University of California, Berkeley that was involved in making Apache Spark, an open-source distributed computing framework built atop Scala. Databricks provides inter alia a web-based platform for working with Spark, that provides automated cluster management and IPython-style (Interactive Python) notebooks, i.e. providing a command shell for interactive computing in multiple programming languages, in particular the Python programming language, offering introspection, rich media, shell syntax, tab completion, and history.

For the present invention, the analytics pipeline architecture was shaped to reflect, the flow of the live solution. The used pipeline can be separated in the following logical components: (1) Extract data from TMR campaign and IoT Platform (positions, sensors, annotations debug data), and enrich it with GIS services (HERE); (2) Extract descriptors/features from valid trip data; and (3) Learn a TMR classification model in a supervised learning setup. These three steps are the object of the following description. The final output of the last step is a classification model structure that can be consumed by a production service. This structure is a standard scikit-learn object that can be deployed e.g. in any Python enabled architecture. FIG. 7 shows a block diagram illustrating schematic an exemplary overview of the architecture of the Transport Mode Recognition system part of system 1, comprising (i) data extraction, data extraction and filtering, (iii) Position sampling, (iv) Candidate stops, (v) Data enrichment, (vi) Feature description, in particular GPS features, Accelerometer features, Feature based on operating system activities, Public transport features, RME features, and GFE features, (vii) Machine learning, (viii) Hardcoded filtering rules, and (ix) Early detection.

For the data extraction, trip data have to be merged from different tables. As a trip identifier, start/stop boundaries can e.g. be used, for example such ones uploaded as debug data by an appropriate debug module or application. This data is e.g. be uploaded to a container and be copied to corresponding tables stored in a data repository. In principle, one could use any trip boundary information. For example, JSON (JavaScript Object Notation) trip boundaries can be used in order to ensure consistency with the debug application logic, but this is not a constraint. Moreover, additional data can be extracted from the JSON which may not contained in the tables in a first time period, most notably the OS Activity and TMR library labels. Since an embodiment variant may use only the OS Activity labels among the two, and these labels can be uploaded in the normal application data flow, the debug JSON data is not a requirement for the inventive solution (cf. FIG. 8).

For the data extraction and filtering, the trip boundaries can e.g. be merged with the following exemplary data sources: (1) analyticsmodel_np0.positions for the GPS locations (Note that “np0” refers to the environment and can change depending on user or testing framework), (2) analyticsmodel_np0.userannotations for the ground truth provided by Coloride users, (3) OS Activities contained in the JSON, (4) (optional) analyticsmodel_np0.accelerometers, and (5) (optional) analyticsmodel_np0.deviceevents. Of these trips, data are filtered out by the system 1 based on the following conditions: (1) At least one minute long, (2) At least 30 GPS positions, and (3) Exactly one user annotation. As a preprocessing step, the system 1 can remove duplicated GPS locations by timestamp, GPS locations that have negative speed and GPS locations that have accuracy>50 m. Motivation for the latter choice is illustrated by FIG. 9, which shows the performance variation of the TMR classifier when varying the minimum accuracy threshold. Since the performance variation is not strong, compliance can be kept with the previously used threshold.

For the position sampling, in order to perform the TMR live call the system 1 needs to perform data processing on a subset of data points, since an arbitrary amount of data cannot be sent in a remote synchronous call. However, it should be noted that the process can e.g. also be implemented to use the full trip data. Based on the analysis of the performance over the number of sampled GPS locations, the points to be sampled can e.g. be set to 16 points equally spaced over the GPS locations array. Other sampling strategies could also be used, however, in the present example did not show a significant performance gain. Also, though more points could be sampled, there is up-to-now no evidence suggesting that sampling more than 16 points may be beneficial. 16 points can e.g. be chosen because it is the HERE Geofencing API limit for a batch call (cf. FIGS. 10a and 10b).

Candidate stop extraction can e.g. be performed by the system 1 identically to the current TMR implementation. Given the set of GPS locations, candidate stops are identified as sequences of points that fulfill these conditions: (i) Speed<=3 m/s, and (ii) Sequences are longer than 5 seconds. The data analysis is performed after applying a moving average with window length 9 over the array of speeds. This means that every sample is replaced by the system 1 by the average of the sample itself and the 4 samples before and after. For each of these candidate sequences, the system 1 generates the average latitude and average longitude, obtaining a candidate stop position for each sequence/stop (cf. FIG. 11).

For the data enrichment, trip data is then enriched by the system 1 with e.g. external APIs (Application Programming Interface), for example using HERE services and an appropriate proximity search. However, also other appropriate map providers can be used of the map can be generated based on own sensory and/or other data. A depiction of the enrichment can be seen in FIG. 12. Apart for baseline data, the performed enrichments can e.g. comprise: (1) Route matching, in order to understand if the trip was performed on a road. In the experimental setup the service used is HERE Route Match Extension (RME). Alternative services or a normalized data source can be used, (2) Query of Geographic Information System (GIS) geometries near the trip, performed using a HERE GFE API/layers. This step is basically a generalization of the GFE approach used in a possible TMR solution (same source, more general features), and (3) Public transport suggestions, in this case HERE Routing API. In the analytics data processing pipeline of the system 1, data can e.g. be written on filesystem after this stage. This can happen for the overall data, which can be slow, or incrementally on a monthly basis. This is performed since the enrichment step is the “slow” one.

For the features description, the system 1 generates a number of features based on all available or historic trip data (e.g. see feature extraction illustrated in FIG. 13). The computed feature list is a superset of the used features. Below, the features actually used are described in the TMR solution, so generated features that are not described are typically mostly out of scope. The implementation of such extractions is mostly contained in the second step of the TMR analytics pipeline. In the production solution, if the constraint is a live TMR call, some of the features must be generated locally on the used phone 10 and sent together with the TMR API call. Alternatively, if TMR can be performed asynchronously, these features can also be generated as soon as trip data lands on the IoT platform of the system 1.

Regarding the GPS features, over the array of GPS speeds, the following features can e.g. be generated: (1) Average, (2) Standard deviation, and (3) Percentiles from 0 to 100, with step 10 (so percentile 0, 10, 20 . . . ). In the exemplary Databricks implementation, the percentile NumPy function can e.g. be used, with the interpolation parameter set to “nearest”, whereas the known NumPy function provides a large number of predefined mathematical operations including standard trigonometric functions, functions for arithmetic operations, handling complex numbers, etc.

Over the array of GPS altitudes, the following feature can e.g. be generated: Standard deviation. Further, GPS acceleration can be implemented as the ratio between the following two arrays: (1) Speed difference between a GPS sample and the preceding sample, and (2) Time difference (in ms) between a GPS sample and the preceding sample. Finally, over the resulting array of GPS accelerations, the following feature can be generated: Standard deviation. A measure of direction variance of the trip can also be generated, following of the pipeline implementation. Zero values from the bearing array can e.g. be removed.

Regarding the accelerometer features: If two or more accelerometer samples have the same timestamps, select the last one w.r.t. to array order. The acceleration norm array can then be generated and, the average of this array can be removed from all the same array. From the norm array, some statistics can be extracted comprising: (i) The percentiles from 0 to 100, with step 10, (ii) The interquartile range, which is the difference between the 75th and the 25th percentile.

Regarding the feature based on operating system activities: Two features using the operating system activities can be selected, with the following rationales: (1) ForwardIntegral can be chosen because of the event-wise behavior of the activity labels, and since it's generally the most informative feature, and (ii) CountAsMostProb can be chosen for simplicity. An activity event, as used herein, is an object with a unique timestamp and a map of labels with probabilities (if a label is absent is considered to have zero probability). The two features are generated for each possible label. Labels can e.g. be normalized to the Android names: ‘Automotive’, ‘Cycling’, ‘OnFoot’, ‘Running’, ‘Stationary’, ‘Unknown’, ‘Walking’, ‘Tilting’ for feature vector naming compliance between the two operating systems. To perform a forward integral calculation, it can be assumed that a label probability is valid until the next event. Each label probability can be multiplied by the milliseconds elapsed until the next event, or until the end of the trip for the last received activity event. This must be done for each label of the possible label list. The system 1 sums the results of these multiplications for each label, and divide each sum by the difference between trip end time and the first activity event time, both in milliseconds. If a label is never returned, the corresponding feature should be set to zero. So, if there are no activities at all for a trip, all the features should be set to zero. Further, the system 1 performs a count as most probable calculation, where for each possible label the number of events is counted in which the label was the most probable one, and divide by the total number of events (or the number of unique timestamps). In case of a 50/50 draw, the most probable can be selected in any way.

Regarding the public transport features, public transport algorithm inputs and outputs are used to generate some additional features: (1) CandidateStopsCount: the number of candidate stops of the trip (trajectory stops), (2) CandidateStopsCountNormalized: the number of candidate stops of the trip (trajectory stops) divided by the cumulated sum of haversine distances between the 16 sampled GPS points, ordered increasingly by time, in meters, (3) PublicRoutingNumStops: the number of suggested stops for the best matching API suggestion, (4) PublicRoutingDistRatio: the cumulated haversine distance of the suggestion stops, in order of traversal, divided by the cumulated haversine distance of the 16 sampled GPS points (see point 2), (5) PublicRoutingCandidateDistRatio: the cumulated haversine distance of the candidate stops, divided by the cumulated haversine distance of the 16 sampled GPS points (see point 2), and (6) The percentiles from 0 to 100, with step 10, of the minimum distances from the suggestion stops to the candidate stops (this is the standard public stop algorithm). These features are calculated for all the suggestions, but the ones selected are the ones regarding the suggestion with minimum distance between suggestion stops and candidate stops.

Regarding the RME features: RME features are generated in order to estimate, based on 16 GPS points, if the trip was not performed on a road. Two statistical descriptors are generated over the trace points confidences: (1) The average of the confidences using e.g. an implemented RMESampledTracePointsConfMean routine, and (2) the variance of confidences, using e.g. an implemented RMESampledTracePointsConfVariance routine.

Regarding the GFE features: Using the geometries returned by the GFE API (e.g. the HERE GFE API), the system 1 can generalize the features used by the Proximity Search. Basically, given the enrichment for the 16 points, the system 1 generates the percentage of points having geometries within 10, 20, 30 . . . 100 meters. This possibly includes points within a geometry, having distance <0. These distributions are computed for: (1) GFERoadOnlyXX generating percentage of points seeing only roads within a XX radius (XX from 10 to 100, with step 10), (2) GFERailOnlyXX generating percentage of points seeing only rail tracks within a XX radius (see point 1), (3) GFERailRoadXX generating percentage of points seeing or roads or rail tracks within a XX radius (see point 1), and(4) GFEAirport0 generating percentage of points within an airport (negative geometry distance). The exhaustive way of mapping geometries to originating points is to do a separate call for each of the 16 sampled GPS points. However, this can be expensive in terms of resources. A batch call with all the 16 points together can e.g. be performed, and then the geometries mapped back to the originating points by minimizing the haversine distance between the points and the nearestLat/nearestLon attributes for each geometry (for differences and details, see the batch version variant in the first step of the TMR pipeline—where GFE_API_Call should be replaced above in step1, and GFEFeats should be replaced in step2). It is to be noted that the second approach is less expensive but it's also less exact, so the overall performance can be slightly lower.

After the feature generation phase, the trip representation is serialized to the filesystem. For selecting the above described features from the larger generated features pool, a cross-validated Recursive Feature Elimination (see FIG. 14) can be used in order to get an estimate of the optimal feature set, averaging results over multiple experiments in a leave-k-users-out setup. Feature importance can be assessed for each classification setup (see below).

For the machine learning, in order to maximize classifier performances and fulfill the technical requirements, a two-stage classifier can e.g. be built. The first classification stage is a specialized “car”/“nocar” detection. This step maximizes performances over the transportation mode of main interest. Trips that are classified as “car” in the first step are permanently marked as “car”. Trips that are not classified as car are then fed to a multiclass classifier that tries to assign the correct transport mode over the available classes. If the multiclass predicts “car” when the first step did not, we mark the trip as “unknown”. This is motivated by precision measure evaluation. The classifier can e.g. be trained, leveraging TMR NP0 pilot data, over the following transport modes: car, train, public transport, bicycle, motorcycle, skiing, plane. The exemplarily chosen classification algorithm is Random Forest. Other algorithms are also imaginable. Motivation for this choice can e.g. stem from the need of controlling overfitting in the model, having probability estimates in the prediction. Moreover, this algorithm has the advantage of providing a good method for estimating feature importance. For tuning the algorithm parameters a grid exploration was performed after the feature selection phase (see FIG. 15). An exemplary configuration is: (1) 250 trees with maximum depth 8 for the binary classifier, and (2) 250 trees with maximum depth 10 for the multiclass classifier. After a successful training, models and results can e.g. be serialized for consumption, e.g. by a live service.

In addition to the full track classification approach described above, an early classification can e.g. be performed. Early check recognition can e.g. be performed among all trip modes, using, for example, the first 5 and 10 minutes of the trip. The following table shows F1-Score performance degradation using the first n minutes of the trip, respect to the Full Trip performances:

5 minutes 10 minutes Boat −4.0% −4.0% Car −1.0% −0.5% Cycling −1.2% −1.2% Motorcycle −8.5% −4.2% Plane −1.3%  1.3% Public −3.5% −7.0% Skiing  2.2%  2.2% Train −6.5% −5.4%

The final and best performance of the TMR algorithm can e.g. be obtained by the single multiclass gradient boosting classifier. Performance can be evaluated in a leave-k-users-out cross-validated setup, in order to get a realistic performance projection, and it is inclusive of all the post processing hardcoded rules. (see below)

Transport Mode Support Recall Precision Boat 12 100.00% 100.00% Car 12710  98.68%  94.98% Cycling 407  71.74%  91.54% Motorcycling 851  53.94%  88.78% Other 13  30.77%   2.60% Plane 115  77.39%  88.12% Public 1000  77.90%  88.12% Skiig 349  93.70%  92.90% Train 316  82.59%  95.96%

Further, it is possible a make similarity add-on at the inventive system 1. Thus, in addition to the supervised learning approach for TMR, a trip similarity strategy can be applied, for example, in order to further raise TMR performances. The additional approach can, for example, leveraging user annotations over previous similar trips, if any, and use this information to correct TMR labels, if needed. This feature can be easily integrated in a production API, where the requirement is to have the 16-points representation of annotated trips available to the API, partitioned by user. The service can e.g. receive a new 16-points representation of a trip, together with TMR probability output, and matches this trip with similar annotated trips, if they exist. Similarity is calculated using a Euclidean pseudo-distance between trajectories. If one or more matches are found, a simple weighting algorithm modifies the TMR probabilities based on the annotation evidence. The new most probable class is then chosen as the TMR label. FIG. 19 show an exemplary F1 score varying TMR label weight (probability mass assigned to the automatic label).

Trip Familiarity Score or Index Measuring

According to the present invention, there are different embodiment variants to technically assign to users and to sessions a score of how much of them follow habits (i.e. familiarity score measuring 114). The first two embodiment variants use a clustering method and then evaluate the familiarity from the dimensions of the clusters (and the familiarity of sessions from the dimension of the clusters in which them are assigned).

Below, the used variants of clustering method and the scoring method are described:

In a fist embodiment variant, which uses a set of links of each session (herein denoted as link version), the clusters are created using jacquard similarity between the link of the sessions. Jaccard Similarity (coefficient) measures similarities between sets. It is defined as the measured size of the intersection divided by the size of the union of two sets. In particular, the similarity between two sessions are calculated in this way:

Sim ⁡ ( S 1 , S 2 ) = ❘ "\[LeftBracketingBar]" L S ⁢ 1 ⋂ L S ⁢ 2 ❘ "\[RightBracketingBar]" ❘ "\[LeftBracketingBar]" L S ⁢ 1 ⋃ L S ⁢ 2 ❘ "\[RightBracketingBar]"

where LSx is the set of links of the session x. The agglomeration is done starting from one cluster for each session, and by agglomerating clusters that have a similarity of at least 0.8. The similarity between clusters with more than one session in it is done by considering the maximum similarity between all the possible combinations of sessions.

In a second embodiment variant, using start and stop points of each session (herein denoted as Start and Stop version), the start and stop points of each the sessions are used for clustering. The distances between two sessions are generated in the following way:


D(S1,S2)=hav(PA1,PA2)+hav(PB1,PB2)

where PXn is the start(A) or end(B) point of the session n, and hav( ) is the Haversine distance between two points. The Haversine distance measures the great-circle distance between two points on a sphere given their longitudes and latitudes. The agglomeration can e.g. be done starting with a cluster for each session, considering as centroid of the cluster the couple start and end points of the session. The next step is done by agglomerating the clusters with a distance of 300 meters or less, iteratively. Every time two clusters are joined the centroid of the cluster are recalculated with a simple average of latitude and longitude of both A and B points of the centroids. Then another agglomeration is done like the previous but considering the centroids distance with the points matched in reverse way (start-points matched with end-points).

For the scoring generation of user familiarity and after the clustering, the Gini coefficient can be used on the dimensions of the clusters to assign to each user a familiarity score. The Gini coefficient measures the inequality among values of a frequency distribution (here the familiarity of trips). A Gini coefficient of zero expresses perfect equality, where all values are the same (for example, where all measured points of the trip match). A Gini coefficient of one (or 100%) expresses maximal inequality among values (e.g., for a large number of trips where only one trip has different measure points and all other trips have complete match, the Gini coefficient will be nearly one). Note that for larger sets of trips, values close to one are unlikely.

The following relation gives a possible index, which can be used for the generation of the familiarity and familiarity score, respectively:

Fam 2 ( U ) = ∑ i ❘ "\[LeftBracketingBar]" C i ❘ "\[RightBracketingBar]" ⁢ ( λ ) i

where |Ci| is the percentage of user session in the i-th cluster, taking the clusters in dimension order, decreasing. λ is a parameter between 0 and 1 that indicates how clusters are considered in the proposed scoring. This value defines the weight given to each cluster in the final score, depending on the position of the cluster in the ordering. For example, if the value is set to 0.5, the first cluster will count 1, the second 0.5, the third 0.25 and so on. If the value is set to 1, each clusters is considered in the same way, if the value is set to 0, just the first cluster is considered. In an embodiment variant, this value is stetted to 0.5. The main idea of this index is to design a value that orders the users with the following order, given the clusters dimensions (x-axis: cluster number, y-axis: cluster dimension), as illustrated in FIG. 20.

For comparison between the Gini index and the index used in this embodiment variant, the used index is generated to adjust the fact that the first and the last two cases of the ordering wanted score 0 in the Gini index, that is an acceptable value just for the last one case. In FIG. 21 the correlation between the Gini index and the used index is shown. As it can be seen, there is a set of value that scored 0 in Gini but they assume a significative value in this new index. Further, it can be seen that the correlation between this two indexes seems to show some kind of regularity in the couple of values. The graph shows that there is some groups of points placed on the same line. This means that further exploration can lead to some kind of clustering algorithm, that uses a combination of this two indexes.

In any case, no general correlation can be overserved between the two indexes because they have two different concepts behind. Gini defines some kind of variance of the cluster dimensions, the new index defines a measure on how the sessions is distribute into the clusters, focusing on the main clusters. Both can be considered as measures of the user Familiarity. Finally, to score for the session familiarity, the familiarity score for a session is measured as the relative dimension of the cluster in which the session is placed, generated as the division between the session in cluster and the total sessions of the user.

A third embodiment variant of Familiarity (denoted herein as “Bag of Links” embodiment variant (BOL)) starts from a scores of familiarity for each link to calculate familiarity of sessions and users. A score of familiarity for each link of each user is generated as the percentage of sessions of the user in which the link appears. The session familiarity is generated as the average of the links scores in the session, the user familiarity is generated as the average of the scores of the links travelled by the user.

To compare the three proposed embodiment variants, the following can be observed: In the first two embodiment variants the familiarity depends on the way the sessions are clustered. After an inspection on the results, the cases in which the two methods give different results are the following. The user goes from the same point A to the same point B, but passing through different links (see FIG. 22). This behavior causes low aggregation in Link familiarity variant and high aggregation in Start Stop variant. In the dataset it has been spotted some cases in which the user travels the same streets but the way the geocoding measuring (e.g. HERE) gives the links causes a wrong behavior in the Link embodiment variant. Typically, it can happen that big streets have two different linkIDs for the two direction of the street, or two streets are too near and the geocoding measuring (e.g. HERE) spots the user in the wrong one. (see FIG. 23)

A second case happens when the user goes once from point A to point B1 (session S1), and once from A to B2 (session S2), as shown in FIG. 23. If S1 and S2 have enough links in common (the user travels the same path but ends up in different places) the two trips are clustered together in the Link method but not in the Start Stop method (in the cases in which the stop points are not enough near). (see FIG. 24)

The Bag of Links (BOL) embodiment variant does not generate clusters so a direct comparison on how the trips are agglomerated cannot be performed. However, a good inspection on this method can be done considering the get_familiarity process, respect to the other get_familiarity of the other embodiment variants. The case in which the BOL embodiment variant becomes useful is when the user does a new trip using only link that has already travelled in each of the previous sessions, but without covering the 80 percent of the shortest of these sessions. In this case the start and stop points are far away so the get_familiarity start stop will return 0, also the number of links in common are not enough to cover the 80 percent of links so also the get_familiarity of the link methods will return a low score. This new method instead will give a maximum scores of 1 (see FIG. 25).

To realize the different embodiment variants, different libraries can e.g. be used to generate the familiarity and relative examples of usage. Each libraries can require a specific input and retrieve the same output composed of three different dataframes. Exemplary dataframes my comprise the following composition: (i) familiarity_user: UserID: User_ID, SessionSize[ ]: Array containing the dimensions of clusters of that user, Familiarity: Index calculated with Gini index, Familiarity_v_2: Index calculated with the new index (described above); (ii) familiarity_session: UserID: User_ID, SessionID: Session_ID, familiarity_sess: Session familiarity, it is the relative dimension of the cluster in which the session is placed (session in cluster/total sessions of the user), and (iii) clusters: UserID: User_ID, Cluster: Generated identifier of the cluster, Sessions [ ]: Sessions in the cluster, Centroid: Centroid calculated in different ways, depending on the case. Each library can provide a function called get_familiarity (as already mentioned above), that takes as input a dataframe containing the clusters previous calculated and a data frame containing a set of new sessions (each session must have the same shape of the data fame used to generate the cluster data frame). This function returns a score of familiarity for each session in the input set. This function does not update the clusters and simply assigns each new session to an existing cluster and return a slightly modified session-familiarity of that cluster (return the session familiarity of the sessions contained in that cluster, calculated as if the new session were contained in it). The function returns −1 if the session comes from a new user.

In a Familiarity Link Library, e.g. of databricks, a familiarity function can be implemented having as input one row for each session and the following fields: (i) UserID: Identifier for the user, (ii) StartTimeUTC: Start time of the session, used as a session ID, (iii) LinkIDs [ ]: Set of links traveled by the user in the session. The absolute value of the LinkID can e.g. be taken in order to consider just the link and not the travelled direction. Further, in a Familiarity Link Deployable, e.g. of databricks, an example of the usage of the previous library Familiarity Link Library can be provided. The environment can be selected on the widget and the function saves the three results dataframes on the three variables familiarity_user, familiarity_session and clusters. This databricks can be deployed on the described environments.

In a Familiarity Start Stop Library, a function can e.g. be provided which needs in input a data frame with the following composition: (i) UserID:User ID; (ii) StartTimeUTC: Start time of the session, used as a session ID; (iii) Coordinates{‘lat_a’:StartLatitude, ‘long_a’:StartLongitude, ‘lat_b’:EndLatitude, ‘long_b’:EndLongitude}: a structure containing the information of starting and ending points of the session. As an example library of the Familiarity Start Stop Library a Familiarity Start Stop Deployable can e.g. be provided, e.g. as another databricks. This is an example of the usage of the previous library. The environment can be selected on the widget and the function saves the three results dataframes on the three variables familiarity_user, familiarity_session and clusters. This databricks can e.g. be deployed on the described environments.

Further by e.g. a Familiarity Bag of Links, the output data frames can be different from the previous cases. The three tables can have the following shape: (1) Familiarity_user: (i) UserID: identify the user, and (ii) UserFamiliarity: familiarity of user, calculated as described above; (2) Familiarity_session: (i) UserID: identify the user, (ii) SessionID: identify the session, and (iii) SessionFamiliarity: familiarity of session, calculated as described above; (3) Scores: (i) UserID: identify the user, (ii) LinkID: identify the link, and (iii) scores: score of the link, calculated as described above. The scores table substitutes the cluster table. When it is desired to generate the familiarity of a set of new sessions, the get_familiarity of this library can be used but passing the scores data frames, instead of the cluster one. The functions of this library can e.g. be implemented to need the input with the following shape df: (i) UserID: identify the user, (ii) StartTimeUTC: starting time of the session, used as SessionID, and (iii) Links[ ]: array containing the absolute values of linkID of links traveled by the user in the correspondent session. A Familiarity Bag of Links Deployable can be provided as an example of the usage of the previous library. The environment can be selected on the widget and the function saves the three results dataframes on the three variables familiarity_user, familiarity_session and score. This databricks can be deployed on the des cribbed environments.

Trip Familiarity Detection 114

As an embodiment variant, a trip familiarity detection and measuring 115 can be realized as an integrated detection engine based on the above described Driver Passenger Detection (DPD) 112, Transport Mode Recognition (TMR) 113 and trip familiarity score measuring 114. I.e. the trip familiarity detection can be realized using TMR 113 measuring similarity with annotated trips, DPD 112 measuring familiarity through the above described LinkID v1, and the Familiarity Score measuring 114 using (i) the familiarity through the described LinkID v2, (ii) start & stop, and (iii) bag of links. A total of 5 different exemplary familiarity clustering data processing and algorithms are disclosed herein. However, other processes are imaginable based on the disclosed techniques.

First, the disclosed TMR 113 is used providing the inventive technical strategy and data considerations. When a TMR 113 request is received live, the system 1 respectively the TMR 113 checks if a user already annotated or corrected a similar trip. Consequently, the system 1 must be able to efficiently retrieve historical annotated trip data and define a trajectory similarity measure. Since the TMR 113 live request contains a representation of the trip with 19 points, in the present embodiment variant, it makes sense to store this representation for each annotated trip, partitioned by a user identifier. This can e.g. be done in a database or a filesystem (e.g. one row per trip). The user annotation preferably can e.g. be stored together with the trip summary. This trip summary can be built/updated in batch using, for example, Databricks (e.g. nightly). The embodiment variant can imply information availability within 24/48 h from user annotation. Existing facilities and other approaches can be considered as well (cf. FIG. 26). For weighting the parameters and evaluating the performance under TMR 113, the multiclass probabilities can e.g. be weighted less than the annotation probability. This is in line with the fact, that, if the user corrected a trip in the past and a similar trip was observed by the system 1, the user should be trusted. The proposed value for the weight is 0.4. FIG. 27 show an exemplary graph, with a TMR baseline.

An exemplary embodiment variant of the DPD 112, which can be used for the trip familiarity detection 115, and which can e.g. comprise the following technical steps performed by the system 1 and the trip familiarity detection and measuring 115, respectively: (1) Collect user history, (2) Cluster similar trips, (3) Define centroid trip, (4) New trips arrives: seek match with existing clusters, and (5) Check cluster DPD label. This is illustrated by FIG. 28, where N is the total number of sessions with DPD score in the cluster, where Di∈[0, 1]Pi∈[0,1] and Xi∈[0, 1] are final confidence scores returned by DPD for each sessions (including enter/exit and BT connection), and where cluster scores can be also generated from user annotations (Truth) or eventually from a combination of both sources.

The objective of the familiarity score is to create a measure for scoring purposes on how much a user travel on familiar roads. This can e.g. require the three different methods, as illustrated by FIG. 29, i.e. (1) Clustering through linkID, (ii) bag of links: linkIDs frequency, and (iii) start & stop. The start&stop method, as illustrated in FIG. 30 is in this context a powerful approach.

DPD used in the context of familiarity detection 115 can comprise the following: (1) For each user: (i) collect trip history (˜few weeks), (ii) cluster similar trips (hierarchical agglomerative clustering via Jaccard distance

J ⁡ ( A , B ) = ❘ "\[LeftBracketingBar]" A ⋂ B ❘ "\[RightBracketingBar]" ❘ "\[LeftBracketingBar]" A ⋃ B ❘ "\[RightBracketingBar]"

where trips that share 80% of the geocoding measuring (e.g. HERE) links are defined similar), and (iii) assign DPD average label to the cluster (using both user annotations+algorithm results); and (2) For new trip arriving: (i) seek match with existing clusters (Jaccard distance between new trip & the centroids), and (ii) check cluster DPD label.

FIG. 30 shows an exemplary overview of a possible general architecture of the trip familiarity detection and measuring 115. It has to be noted that to measure similarity between trajectories can be computationally challenging in regard to the performance and consumption of the system 1. Thus, as an embodiment variant, a similarity prefilter can be used in the system 1, in particular for TMR 113, where the data processing is only performed on a subset of likely candidates. A trip is considered a valid candidate of its start and end both lie within a certain radius from the start/end of the current trip (the one that is evaluating in a TMR live request). The radius can e.g. be set to 500 meters for this example, based on empirical observation. Since user annotations can be in limited number (in normal operating conditions) and using the proposed similarity prefilter, the trajectory similarity is actually generated against a small subset of trips, which is illustrated in FIG. 31.

As a further embodiment variant, e.g. to further improve the performance of the system 1, a Driver DNA measurement can e.g. be applied and performed by the system 1. One of the aims of the system 1 and e.g. a corresponding telematics app is to measure and to score the driver behavior through the recording of GPS, Accelerometer, Gyroscope and other integrated sensors present in personal mobile phone or black boxes. Different combination of driver and transport mode have different driving style, moreover each driver has a different driving style depending on external factors e.g. weather, road type, and on personal factors e.g. motivation of the trip, time constraints and trip familiarity. Given previous assumptions, the transport mode recognition 113 and driver passenger detection 112 can be improved based on an in depth recognition and/or analysis of a single person driving style in combination with his trip history by the system 1. Another aim of telematics app is the machine-based coaching of the driver to reduce his risk while improving his driving style. The analysis of the driving style for each user with a related risk estimation will allow to provide personalized feedbacks and programs to reduce the risk exposure of each driver after a minimum amount of trip history. As an embodiment variant, different assumption for designing features that can contribute to technically define a driving style, can be used as follows: (i) Correlation between accelerometer and GPS speed, (ii) Frequency of maneuvers and phone distraction events per kilometers, (iii) In depth analysis of speed distribution while turning taking into consideration curvature degrees, (iv) Analysis of speed distribution taking in consideration road sinuosity, speed limit and road class, and (v) Analysis and feature extraction from accelerometer and gyroscope distribution as a function of road class, sinuosity and shape. Using clustering algorithms together with the above feature extracted from an historical set of trips of a single user allows to define and measure the driver's driving style. For the Driver DNA, as defined above, the system 1 clusters the feature measuring and describing the driving style of a user and to correlate each cluster with the frequency of transport mode, driver or passenger trips present in the cluster. In the end for each cluster there will be a rank of possible transport mode and a most probable output of driver or passenger. This combination is what is called herein the measuring of a DriverDNA.

Driver Passenger Detection (DPD) 112

For identifying and/or classifying an occupant of a vehicle 41, 42, 43, . . . based on sensory data measured by a plurality of sensors 102 of a cellular mobile device 10 of the occupant 6/61/62, the plurality of sensors 102 at least comprise an accelerometer 1025 and a gyroscope 1026. The mobile device 10 further comprises one or more wireless connections 105, wherein by at least one of the wireless connection, the cellular mobile device 10 acts as a wireless node 221, . . . , 225 within a cellular data transmission network 2 by means of antenna connections of the cellular mobile device to the cellular data transmission network 2, and the plurality of sensors 102 being connected to a monitoring mobile node application 101 of the mobile device 10. The one or more wireless connections 105 or wired connections of the mobile telecommunication apparatus 10 can for example comprise Bluetooth as wireless connection for exchanging data using short-wavelength UHF (Ultra high frequency) radio waves in the ISM (industrial, scientific and medical) radio band from 2.4 to 2.485 GHz by building a personal area networks (PAN) with the on-board Bluetooth capabilities and/or 3G and/or 4G and/or GPS and/or Bluetooth LE (Low Energy) and/or BT based on the Wi-Fi 802.11 standard, and/or a contactless or contact smart card, and/or a SD card (Secure Digital Memory Card) or another interchangeable non-volatile memory card. For providing the wireless connection 105, the mobile telecommunication apparatus 10 can for example act as a wireless node within a corresponding data transmission network by means of antenna connections of the mobile telecommunications apparatuses 10, in particular, as mentioned, mobile telecommunication networks such as 3G, 4G, 5G LTE (Long-Term Evolution) networks or mobile WiMAX or other GSM/EDGE- and UMTS/HSPA-based network technologies etc., and more particularly with appropriate identification means as SIM (Subscriber Identity Module) etc..

The monitoring mobile node application 101 captures usage-based and/or user-based telematics data of the cellular mobile device 10 and/or the user 6/61/62 of the cellular mobile device 10. The mobile telecommunications apparatuses 10 and the monitoring cellular mobile node application 101 can e.g. be connected to an on-board diagnostic system 431, . . . , 435 and/or an in-car interactive device 441, . . . , 445, wherein the mobile telecommunications apparatuses 10 capture usage-based 31 and/or user-based 32 automotive data 3 of the motor vehicle 41, 42, 43, . . . and/or user. The mobile telecommunications apparatuses 10 can for example provide the one or more wireless connections 1024 by means of radio data systems (RDS) modules 10241 and/or positioning system 10242 including a satellite receiving module and/or a mobile cellular phone module 10243 including a digital radio service module and/or a language unit 10244 in communication with the radio data system 10241 or the positioning system 10242 or the cellular telephone module 10243. The satellite receiving module 10242 can for example comprise a Global Positioning System (GPS) circuit and/or the digital radio service module comprises at least a Global System for Mobile Communications (GSM) unit. The plurality of interfaces of the mobile telecommunications apparatuses 10 for connection with at least one of a motor vehicle's data transmission bus can for example comprise at least on interface for connection with a motor vehicle's Controller Area Network (CAN) bus, e.g. in connection with an on-board diagnostics (OBD) port, or another connection for example for battery installed devices, or also OEM (Original Equipment Manufacturer) installed systems obtaining information access to on-board sensors or entertainment systems (such as Apple Carplay etc.) providing the necessary vehicle sensor information.

As mentioned, a data link 21 is set by means of the wireless connection 105 of the mobile telecommunication apparatus 10 over the mobile telecommunication network 2 between the mobile telematics application 101 as client and an intelligent central automotive circuit 11, wherein the mobile telecommunication apparatus 10 acts as wireless node 221, . . . , 225 within said mobile telecommunication network 2, and wherein the operating parameters 40121 and the environmental parameters 40111 are measured and collected in dataflow pathway 103 as automotive telematics data 3 during operation of the motor vehicle 41, 42, 43, . . . via the mobile telecommunication apparatus 10 by means of a mobile telematics application 101 and transmitted to the central circuit 11. The intelligent central circuit 11 comprises a sensory-data-driven core aggregator 110 with a plurality of dynamically applied sensory data-based triggers 1012 triggering, capturing, and monitoring said sensory parameters in the dataflow pathway 103 by means of a mobile telematics application 101 of the mobile telecommunication apparatus 10. The mobile telecommunication apparatus 10 can for example comprise at least a GPS module (Global Positioning System) and/or geological compass module based on a 3-axis teslameter and a 3-axis accelerometer, and/or gyrosensor or gyrometer, and/or a MEMS accelerometer sensor comprising a cantilever beam with the seismic mass as a proof mass measuring the proper or g-force acceleration, and/or a MEMS magnetometer or a magnetoresistive permalloy sensor or another three-axis magnetometers.

The mobile device 10 measures gravitational acceleration movement sensory data by means of the accelerometer based on measuring parameters obtained from the accelerometer. Vehicle 41, 42, . . . entering or exiting movement patterns of the user are detected from the acceleration movement sensory data at least comprising pattern for base axis and degree of rotation associated with a vehicle entrance or exit of the user 6. The detected vehicle entering or exiting movement patterns of the user 10 trigger as input features the recognition of a vehicle entering or exiting movement of the user by performing a decision-tree classification on the input features to rule out whether the user entered or exited from a left or right side of the vehicle. It is to be noted that the system 1 can also be realized by using other classification algorithms or structures e.g. boosted tree or neural network etc.

The DPD system 112 allows to select (as few as possible) characteristic input features to reduce the number of model parameters to be used. The inventive DPD (Driver Passenger Detection) method and system comprise at least the following three main steps: 1. Detect the exact moment when the user is entering/exiting the car by analyzing the acceleration. 2. Use the gyroscope data to select various features such as the verse and the degree of the rotation associated to the entrance/exit. 3. Perform a decision-tree classification on the input features to rule out whether the user entered (exited) from the left/right side of the car. The system provides a detection of the exact moment when a person is entering/exiting the car. It is to be mentioned that without this information, any other analysis of the Gyroscope sensor will be useless to the DPD problem due to the many rotations that a user can perform in a huge variety of movements. The detection step is accomplished by collecting information both on the variance of the acceleration in the up/down (Earth reference system) directions and on the presence (or not) of some particular discontinuities in the acceleration signals in the smartphone reference system (not rotated).

One of the advantages of the present invention is its easy adaptability and suitability for its use in modular systems, e.g. to technically provide familiarity detection of trips. Thus, the present Driver Passenger Detection (DPD) system can e.g. be realized as part of an inventive, more complex, and composite modular monitoring and detection system 1 with interactive Driver Passenger Detection (DPD) 112, Transport Mode Recognition (TMR) 113 and trip familiarity detection and/or score 114, allowing a broad monitoring of user actions related to the use of his/her mobile phone.

LIST OF REFERENCE SIGNS

1 Mobile identification and classification system

    • 10 Mobile telecommunications apparatus
      • 101 Mobile telematics application (cellular mobile node application)
      • 102 Integrated Sensors of the mobile node
        • 1020 MEMS magnetometer
        • 1021 Proximity Sensor
        • 1022 Fingerprint Sensor
        • 1023 Ambient Light Sensor
        • 1024 GPS Sensor
          • 10241 Longitude position
          • 10242 Latitude position
          • 10243 Altitude position
        • 1025 Accelerometer
        • 1026 Gyroscope
        • 1027 Cameras
        • 1028 Touchscreen
        • 1029 MEMS compass module
        • 1030 Back Illuminated Sensor
        • 1031 NFC Sensor
      • 103 Dataflow pathway
      • 105 Wireless connections
        • 1051 GSM
        • 1052 WLAN
        • 1053 Bluetooth
        • 1054 Near Field Communication NFC (for NFC Sensors)
    • 11 Central circuit
      • 110 Telematics-driven aggregator
        • 1101 Data Interface
      • 111 Machine-learning module
      • 112 Driver Passenger Detection (DPD) system
      • 113 Transport Mode Recognition (TMR)
        • 1131 Gradient boosting machine-learning classifier
        • 1132 Input feature values
        • 1133 Transportation modes
          • 11331 Public transportation
          • 11332 Motorcycle
          • 11333 Cycling
          • 11334 Train
          • 11335 Tram
          • 11336 Plane
          • 11337 Car
          • 11338 Skiing
          • 11339 Boat
        • 1134 Transport mode label (Output value)
        • 1135 Trips
          • 11351 Transport mode movement pattern
        • 1136 Supervised learning structure
      • 114 Trip familiarity Measuring and Detection
    • 12 First-tier automated risk-transfer system
      • 121 Electronic first-tier resource-pooling system
      • 122 First-tier risk-transfer parameters
      • 123 First-tier payment-transfer parameters
    • 13 Second-tier automated risk-transfer system
      • 131 Electronic second-tier resource-pooling system
      • 132 Second-tier risk-transfer parameters
      • 133 Second-tier payment-transfer parameters

2 Data transmission network

    • 20 Cellular network grid
      • 201, . . . , 203 Network cell/Basic service area
      • 211, . . . , 213 Base (transceiver) station
        • 2111, . . . , 2131 Cell Global Identity (CGI)
      • 221, . . . , 226 Cellular network node
    • 21 Uni- or bidirectional data link

3 Sensory data of the mobile device 10

    • 31 Sensory parameter values of the 3-axis accelerometer
    • 32 Sensory parameter values of the GPS sensor
    • 33 Trips database
      • 331 Measured Time Serie of Sensory Parameter Values of Stored Trips 1, . . . , t

41, 42,43, . . . Motor vehicles

    • 401, . . . , 405 On-board sensors and measuring devices
    • 411, . . . , 415 OEM (Original Equipment Manufacturer) devices
    • 421, . . . , 425 Data transmission bus interface
    • 431, . . . , 435 On-board diagnostic system
    • 441, . . . , 445 In-car interactive device
    • 451, . . . , 455 Automotive telematics devices

6 User of the mobile device

Claims

1. A method for automated transportation mode recognition based on sensory data measured by a plurality of sensors of a mobile device of a user, the plurality of sensors at least comprising an accelerometer and a GPS sensor, the mobile device comprising one or more wireless connections, the mobile device acting as a wireless node within a cellular data transmission network by means of antenna connections of the mobile device to the cellular data transmission network, the plurality of sensors being connected to a monitoring mobile node application of the mobile device, and the monitoring mobile node application capturing usage-based and/or user-based sensory data of the mobile device and/or the user of the mobile device, the method comprising:

measuring time series of sensory parameter values based on measuring parameters obtained from the plurality of sensor of the mobile device, the measuring parameters comprising a time series of sensory parameter values of the accelerometer measurements and a time series of sensory parameter values of GPS-based speed measurements of the GPS sensor, the GPS sensor measuring longitude, latitude, and altitude positions of the mobile device by measuring different speeds of light delays in signals coming from two or more satellites, and
triggering the automated transportation mode recognition using the measured time series of the sensory parameter values as input feature values to a gradient boosting machine-learning classifier, wherein
the transportation mode includes at least one of public transportation, motorcycle, cycling, train, tram, plane, car, skiing, and boat, and
the transportation mode recognition generates a transport mode label for a transport mode movement pattern of a trip.

2. The method for automated transportation mode recognition according to claim 1, wherein

a supervised learning structure is applied to the gradient boosting machine-learning classifier during a supervised learning phase,
transport mode movement patterns of measured trips are stored in a trips database,
the sensory parameter values include sensory movement parameter values,
transport mode movement patterns of the trip are identified from the sensory movement parameter values,
each of the trips comprises the sensory movement parameter values of GPS positions by the GPSsensor and acceleration forces being applied to the mobile device on all three physical axes by the accelerometer, operating system activities parameter values of an operating system of the mobile device, and a transport mode label value, and
trips with transport mode labels detected by the gradient boosting machine-learning classifier are fed into a user back-loop for dynamic correction by a user associated with a respective trip and saved to the trips database by updating learning transport mode movement patterns of the measured trips in the trips database.

3. The method for automated transportation mode recognition according to claim 2, further comprising monitoring the trips database to automatically detect changes in the trips database, wherein upon detecting a change in the trips database, the supervised learning phase is reinitiated.

4. The method for automated transportation mode recognition according to claim 2, wherein the trips database is updated continuously and/or dynamically based on the user back-loop.

5. The method for automated transportation mode recognition according to claim 2, wherein, for the supervised learning phase, the trips of the trips database are preprocessed by filtering out transport mode movement patterns, which have a time duration shorter than 1 minute and/or comprise less than 30 GPS positions and/or do not have a proper transport mode labelling.

6. The method for automated transportation mode recognition according to claim 2, wherein, for the supervised learning phase, the trips of the trips database are preprocessed by filtering out transport mode movement patterns having duplicated GPS locations by timestamp and/or transport mode movement patterns with GPS locations having negative speed and/or transport mode movement patterns having GPS locations with an accuracy>50 m.

7. The method for automated transportation mode recognition according to claim 1, wherein, upon detection by the gradient boosting machine-learning classifier and the generation of the transport mode label for the transport mode movement pattern of the trip, the trips are postprocessed by a set of hard coded rules, reinforcing avoidance of incorrect and/or insufficiently confident recognition.

8. The method for automated transportation mode recognition according to claim 1, wherein users routines are automatically detected by a trip familiarity-based recognition structure increasing the accuracy of the automated transportation mode recognition.

9. The method for automated transportation mode recognition according to claim 2, wherein the transport mode movement patterns of measured trips stored to the trips database are processed for data enrichment, where the data enrichment process comprises route-matching of the trips with the transport mode movement patterns based on roadmaps and/or GIS-geometry mapping of the trips with the transport mode movement patterns based on spatial and geographic GIS data, and/or public transport mapping based on public transport road maps and timetable data.

10. The method for automated transportation mode recognition according to claim 1, wherein the measuring parameters of the time series of sensory parameter values of the GPS-based speed measurements further comprise extracted average GPS-based speed measurements and/or standard deviation of the GPS-based speed measurements and/or percentiles values from 0 to 100 of the GPS-based speed measurements in predefined percentile steps.

11. The method for automated transportation mode recognition according to claim 10, wherein the percentile steps comprise a granularity of a factor 10.

12. The method for automated transportation mode recognition according to claim 1, wherein the altitude position further comprises a standard deviation extracted from the altitude position measurements.

13. The method for automated transportation mode recognition according to claim 1, wherein the measured time series of the sensory parameter values comprise GPS-based acceleration measurements derived based on a measured ratio between (a) a measured speed difference between a measured set of GPS parameter values and a measured subsequent set of GPS parameter values, and (b) a measured time difference between the measured set of GPS parameter values and the measured subsequent set of GPS parameter values.

14. The method for automated transportation mode recognition according to claim 13, wherein the GPS-based acceleration measurements comprise a standard deviation extracted from the GPS-based acceleration measurements and/or a variance value of the GPS-based acceleration measurements derived based on an angle between triplets of consecutive GPS points.

15. The method for automated transportation mode recognition according to claim 1, wherein the measuring parameters of the time series of sensory parameter values of the accelerometer measurements further comprise percentile values from 0 to 100 of the accelerometer measurements in predefined percentile steps and/or interquartile range values measured by a difference between the 75th and the 25th percentile.

16. The method for automated transportation mode recognition according to claim 15, wherein said percentile steps comprise a granularity of a factor 10.

17. The method for automated transportation mode recognition according to claim 2, wherein

in a case of two or more accelerometer measurements having the same timestamps, a last one with respect to an accelerometer measurement order is selected, and an accelerometer measurement norm value is generated over the accelerometer measurements of a measured trip, and
an average of the accelerometer measurements of the measured trip is removed form said measured trip.

18. The method for automated transportation mode recognition according to claim 2, wherein

the operating system activities parameter values of the operating system of the mobile device comprise a unique timestamp and a map of labels with probability measures, and
in a case of an absence of a label, the probability measure is set to 0.

19. The method for automated transportation mode recognition according to claim 18, wherein said labels of the map are normalized to ‘Automotive’, ‘Cycling’, ‘OnFoot’, ‘Running’, ‘Stationary’, ‘Unknown’, ‘Walking’, and ‘Tilting’ denoting a feature vector for naming compliance between two operating systems.

20. The method for automated transportation mode recognition according to claim 18, further comprising assuming a label probability is valid until a next event is measured, wherein

each label probability is multiplied by measured milliseconds elapsed until the next event, or until an end of the trip for a last received activity event,
the multiplication is performed for each label of a label list,
the multiplied label probabilities for each label are summed up, and
each sum is divided by a difference between a trip end time and a first activity event time, both in milliseconds.

21. The method for automated transportation mode recognition according to claim 20, wherein, in a case of a label being never returned, a corresponding feature is set to 0, so that if there are no activities at all for a measured trip, all the operating system activities parameter values are set to 0.

22. The method for automated transportation mode recognition according to claim 9, wherein

the public transport mapping based on public transport road maps and timetable data comprises identifying for a set of measured GPS location parameters candidate stops as sequences of points that fulfill conditions of: (i) measured speed<=3 m/s; and (ii) candidate sequences are longer than 5 seconds,
the identification is performed after applying a moving average with window length 9 over an array of measured speeds, replacing each sample an average of the sample itself and the 4 samples before and after, and
for each of the candidate sequences, an average latitude and an average longitude is generated, obtaining a candidate stop position for each sequence/stop.

23. The method for automated transportation mode recognition according to claim 1, wherein a hyperparameter configuration is applied to the gradient boosting machine-learning classifier comprising the values 225 for the n-estimators, 0.03 for the learning-rate, 30 for the max-depth, 50 for the num-leaves, 0.8 for the subsample, 0.7 for the colsample-bytree, and 5 for the min-sum-hessian-in-leaf.

Patent History
Publication number: 20230076568
Type: Application
Filed: Oct 10, 2022
Publication Date: Mar 9, 2023
Applicant: Swiss Reinsurance Company Ltd. (Zurich)
Inventors: Riccardo TISSEUR (Aramengo), Elia GIACOMINI (Vigonza)
Application Number: 18/045,326
Classifications
International Classification: G06N 20/20 (20060101); H04W 4/029 (20060101); G06Q 50/30 (20060101); G06Q 50/26 (20060101); G01C 21/30 (20060101);