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

Abstract

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.

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 75.sup.th and the 25.sup.th 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.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

TABLE-US-00001 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%

[0025] 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).

[0026] 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:

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

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

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

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

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

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

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

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

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

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

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

[0037] 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.

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

[0039] 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).

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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).

[0044] 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).

[0045] 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.

[0046] 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.

[0047] 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) D.sub.i∈[0, 1]P.sub.1∈[0,1] and X.sub.i∈[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.

[0048] 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.

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

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

[0051] 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

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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

[0059] 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).

[0060] 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.

[0061] 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.

[0062] 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.

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

[0064] (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.

[0065] (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.

[0066] (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.

[0067] (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.

[0068] (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.

[0069] (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).

[0070] 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.

[0071] 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.

[0072] 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

TABLE-US-00003 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

[0073] 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.

[0074] 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).

[0075] 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.

[0076] 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).

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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).

[0081] 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.

[0082] 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).

[0083] 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).

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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).

[0094] 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.

[0095] 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:

TABLE-US-00004 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%

[0096] 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)

TABLE-US-00005 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%

[0097] 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

[0098] 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).

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

[0100] 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:

[00001] $Sim (S_{1}, S_{2}) = \frac{.Math. L_{S 1} .Math. L_{S 2} .Math.}{.Math. L_{S 1} .Math. L_{S 2} .Math.}$

[0101] where L.sub.Sx 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.

[0102] 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(S.sub.1,S.sub.2)=hav(P.sub.A1,P.sub.A2)+hav(P.sub.B1,P.sub.B2)

[0103] where P.sub.Xn 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).

[0104] 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.

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

[00002] ${Fam}_{2} (U) = \underset{i}{.Math.} .Math. C_{i} .Math. {(λ)}^{i}$

[0106] where |C.sub.i| 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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)

[0111] 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)

[0112] 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).

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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

[0117] 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.

[0118] 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.

[0119] 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 D.sub.i∈[0, 1]P.sub.i∈[0,1] and X.sub.i∈[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.

[0120] 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.

[0121] 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

[00003] $J (A, B) = \frac{.Math. A .Math. B .Math.}{.Math. A .Math. B .Math.}$

[0122] 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.

[0123] 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.

[0124] 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

[0125] 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..

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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).

[0130] 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

[0131] 1 Mobile identification and classification system [0132] 10 Mobile telecommunications apparatus [0133] 101 Mobile telematics application (cellular mobile node application) [0134] 102 Integrated Sensors of the mobile node [0135] 1020 MEMS magnetometer [0136] 1021 Proximity Sensor [0137] 1022 Fingerprint Sensor [0138] 1023 Ambient Light Sensor [0139] 1024 GPS Sensor [0140] 10241 Longitude position [0141] 10242 Latitude position [0142] 10243 Altitude position [0143] 1025 Accelerometer [0144] 1026 Gyroscope [0145] 1027 Cameras [0146] 1028 Touchscreen [0147] 1029 MEMS compass module [0148] 1030 Back Illuminated Sensor [0149] 1031 NFC Sensor [0150] 103 Dataflow pathway [0151] 105 Wireless connections [0152] 1051 GSM [0153] 1052 WLAN [0154] 1053 Bluetooth [0155] 1054 Near Field Communication NFC (for NFC Sensors) [0156] 11 Central circuit [0157] 110 Telematics-driven aggregator [0158] 1101 Data Interface [0159] 111 Machine-learning module [0160] 112 Driver Passenger Detection (DPD) system [0161] 113 Transport Mode Recognition (TMR) [0162] 1131 Gradient boosting machine-learning classifier [0163] 1132 Input feature values [0164] 1133 Transportation modes [0165] 11331 Public transportation [0166] 11332 Motorcycle [0167] 11333 Cycling [0168] 11334 Train [0169] 11335 Tram [0170] 11336 Plane [0171] 11337 Car [0172] 11338 Skiing [0173] 11339 Boat [0174] 1134 Transport mode label (Output value) [0175] 1135 Trips [0176] 11351 Transport mode movement pattern [0177] 1136 Supervised learning structure [0178] 114 Trip familiarity Measuring and Detection [0179] 12 First-tier automated risk-transfer system [0180] 121 Electronic first-tier resource-pooling system [0181] 122 First-tier risk-transfer parameters [0182] 123 First-tier payment-transfer parameters [0183] 13 Second-tier automated risk-transfer system [0184] 131 Electronic second-tier resource-pooling system [0185] 132 Second-tier risk-transfer parameters [0186] 133 Second-tier payment-transfer parameters

[0187] 2 Data transmission network [0188] 20 Cellular network grid [0189] 201, . . . , 203 Network cell/Basic service area [0190] 211, . . . , 213 Base (transceiver) station [0191] 2111, . . . , 2131 Cell Global Identity (CGI) [0192] 221, . . . , 226 Cellular network node [0193] 21 Uni- or bidirectional data link

[0194] 3 Sensory data of the mobile device 10 [0195] 31 Sensory parameter values of the 3-axis accelerometer [0196] 32 Sensory parameter values of the GPS sensor [0197] 33 Trips database [0198] 331 Measured Time Serie of Sensory Parameter Values of Stored Trips 1, . . . , t

[0199] 41, 42,43, . . . Motor vehicles [0200] 401, . . . , 405 On-board sensors and measuring devices [0201] 411, . . . , 415 OEM (Original Equipment Manufacturer) devices [0202] 421, . . . , 425 Data transmission bus interface [0203] 431, . . . , 435 On-board diagnostic system [0204] 441, . . . , 445 In-car interactive device [0205] 451, . . . , 455 Automotive telematics devices

[0206] 6 User of the mobile device

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

Assignee

Inventors

Cpc classification

Classification Explorer

G06Q50/30

PHYSICS

Classification Explorer

H04W4/48

ELECTRICITY

Classification Explorer

H04W4/029

ELECTRICITY

Classification Explorer

B60W2556/45

PERFORMING OPERATIONS; TRANSPORTING

Classification Explorer

G06N20/20

PHYSICS

Classification Explorer

G06F18/00

PHYSICS

Classification Explorer

G06Q50/26

PHYSICS

Classification Explorer

B60W2540/227

PERFORMING OPERATIONS; TRANSPORTING

Classification Explorer

H04W4/027

ELECTRICITY

Classification Explorer

G01C21/30

PHYSICS

Classification Explorer

H04W4/38

ELECTRICITY

Classification Explorer

G06F2218/12

PHYSICS

Classification Explorer

B60W40/08

PERFORMING OPERATIONS; TRANSPORTING

International classification

Classification Explorer

G06N20/20

PHYSICS

Classification Explorer

H04W4/029

ELECTRICITY

Classification Explorer

G06Q50/26

PHYSICS

Classification Explorer

G06Q50/30

PHYSICS

Classification Explorer

G01C21/30

PHYSICS

Abstract

Claims

Description