Mobile device and system for automatic trip familiarity recognition and corresponding methods thereof

Abstract

A method and system for electronic trip familiarization detection (114) based on sensor data (3) measured by a plurality of sensors (102) of a mobile telematics device (10) associated with a user (6) and / or a vehicle, the plurality of sensors (102) comprising at least a GPS sensor (1024) and / or an accelerometer (1025), the mobile device (10) comprising one or more wireless connections (105), wherein, by means of at least one of the wireless connections (105), the mobile device (10) acts as a wireless node (221, …, 225) within a cellular data transmission network (2) by means of an antenna connection of the mobile device (10) to the cellular data transmission network (2), and the plurality of sensors (102) are connected to a monitoring mobile node application (101) of the mobile device (10), wherein the monitoring mobile node application (101) captures usage-based sensor data (3) and / or user-based sensor data (3) of the plurality of sensors (102) of the mobile device (10).

Description

Technical Field

[0001] This invention generally relates to sensor-based electronic trip familiarity recognition systems and devices, and more particularly to systems and methods for mobile phone sensor data, such as transportation mode detection based on smartphone sensor data and / or trip familiarity recognition or detection based on vehicle sensor measurement data. More generally, this invention relates to mobile real-time systems that dynamically respond to captured sensor data based on specific environmental or operational parameters, particularly to vehicle usage monitoring, capture, and response to vehicle or user-related parameters in the context of motor vehicle operation. More specifically, this invention relates to devices and systems based on telematics for trip familiarity recognition or detection. Finally, this invention also relates to real-time recognition and detection systems based on telematics. The term telematics (particularly, transportation telematics) refers to sensing systems and information technologies used for communication, instrumentation, and control in the transportation sector (such as land-based, sea-based, or air-based transportation). Therefore, this invention relates to telematics and / or the use of mobile phone sensor data, and to real-time measurement, monitoring, dynamic, and automatic adaptation systems based on captured and measured telematics data based on usage and / or user. Background Technology

[0002] In daily life, people's travel patterns and behaviors (whether walking, cycling, driving, or using public transportation) are often similar or identical in familiar environments. This makes automated trip recognition possible. The automatic detection and sensor-based identification of people's travel chains (especially door-to-door travel chains) has a variety of technological applications. For large-area steering control and optimization by infrastructure planners, public transport providers, and / or traffic control systems, measuring and understanding the number of commuters or others moving from one location to another—from origin to destination—is fundamental to understanding the technical requirements of road and transport networks, road infrastructure, and traffic control systems.

[0003] To provide users in private or public transportation with relevant information about opportunities and issues, it is technologically crucial to be able to generate predictions of the next destination, travel time, and the public transportation mode that person will use. For many, the same journeys repeat in regular cycles—daily, on (certain) weekdays, weekly, or monthly. Such travelers can be proactively given targeted information about unforeseen events on the road traffic or public transport routes they frequently use during their regular personal time. Therefore, real-time identification of journeys based on familiarity patterns and current modes of transportation, along with predictions of possible destinations, is essential when connected to travelers or their mobile devices, such as smartphones, for various technological reasons.

[0004] Furthermore, a traveler's familiarity with a route has a direct impact on the measurement of the probability of an accident in many situations (such as driving), for example, in relation to driving, considering not only the selected route in a specific environment but also the driver's familiarity with the route itself. It is a known fact that road safety is closely related to human factors, which play a key role in approximately 90% of crashes. Of all driver-related crash variables, this invention focuses particularly on route familiarity, and the accompanying driver's route familiarity, and its various relationships with road safety. Route familiarity, compared to route familiarity which represents the frequency of choosing a particular or familiar route, is defined herein as the familiarity of a particular driver with routes on repeatedly driven selected routes, and therefore, the driver's familiarity with the road elements that make up these routes. In the context of route familiarity, word familiarity relates to the frequency of a given stimulus experienced in the past, while in the context of route familiarity, word familiarity relates to the similarity of (frequently) chosen routes. Thus, by applying these preliminary concepts, a driver familiar with routes is a driver who drives on familiar, frequently chosen routes, and driving on that particular route consists of different routes and road elements, which are repeatedly experienced stimuli.

[0005] It should be noted that drivers can also drive different vehicles and navigate numerous individuals, environments, and traffic conditions that may or may not be familiar to them. All of these factors can be influential: for example, familiar routes may only be recommended to the driver at specific times or under given conditions. For appropriate risk measurement, such as measuring the probability of an accident occurring during a given route, automated systems should also be able to capture the impact of the driver's familiarity / unfamiliarity with a given route, as well as other unfamiliar aspects of the system's human-vehicle-environment familiarity.

[0006] Route familiarity can be easily correlated with frequently occurring driving tasks, such as those involving commuting to the same workplace (e.g., commuters), school, shops, etc., almost daily. Therefore, route familiarity is a very common phenomenon for drivers (or general mobility patterns) worldwide. Some examples of drivers with high route familiarity in traffic flow are reported below. Approximately one-third of the vehicle miles driven by private vehicles in the United States are for commuting. Over 60% of the surveyed Italian sample repeated a given route at least 3 days a week, and over 60% of this was an average daily trip. One reason for considering route familiarity is its impact on driving behavior. However, by influencing driving behavior, route familiarity can affect safety aspects based on road and traffic behavior. Nevertheless, existing technological systems lack the ability to measure the impact of route familiarity on aspects such as road safety. Therefore, there is a need for automated systems capable of capturing the impact on the relationship between route familiarity, route familiarity, and road safety. Furthermore, while basic definitions of trip familiarity and route familiarity can be provided, along with some examples of familiar drivers (such as commuters), existing technologies lack a system capable of accurately measuring, classifying, and categorizing different levels of route familiarity. This means it is difficult to find a clear threshold to determine when an unfamiliar driver begins to become familiar after a given frequency of travel on the same trip. One of the main technical problems is the difficulty in comparing measurement results.

[0007] Trip familiarity, and consequently, the driver's route familiarity, impacts road safety because it affects the driving task itself. Driving tasks are complex and are often defined as intricately organized across different hierarchical levels described by varying levels of performance. Furthermore, driving tasks may require attention or, under given conditions, partial / fully automated operation. By combining the levels of driving tasks with a focus on familiarity, the following relationships emerge: (A) Familiarity can be associated with skill-based task automation, requiring less attention (e.g., during commuting, negotiating familiar road elements, or operating short-term driving modes). A switch to automation can occur when one or more factors of the road system are familiar (i.e., familiarity with the road, vehicle, and environment). However, drivers familiar with these factors can also transition to rule-based behavior (e.g., in an unfamiliar car, by applying well-known rules to other vehicles); (B) Unfamiliarity may be associated with knowledge-based driving task awareness, requiring attention to resolve unknown situations (e.g., as a first-time driver, or as a skilled driver, when navigating in an unfamiliar environment or operating unfamiliar maneuvers).

[0008] To technically capture the habituation process, existing technological systems are typically based on a two-process approach. A person exposed to the same repetitive stimulus over time gradually reduces their response to that stimulus until an asymptotic value is reached. However, this habituation effect can persist for a short or long period (even weeks: long-term habituation), in which case existing technological systems typically cannot parameterize the time variance. Additionally, in the case of new stimuli, some responses can be recovered: in the so-called dishabituation effect. The response decays further regardless of whether the stimulus is maintained. When driving on the same journey under given boundary conditions is a repetitive stimulus, it should be expected that the driver will gradually become accustomed to it. Therefore, the driver's response should asymptotically approach a low level at which mental workload and attentional capacity can be significantly reduced, as explained by the Malleable Attentional Resources Theory (MART). However, under low attentional conditions, the mind may be unconsciously occupied by thoughts unrelated to driving, a phenomenon known as "mind wandering." Furthermore, the lower the demands of the driving scenario, the more time may be spent driving with a wandering mind. Therefore, route familiarity obtained from measured trip familiarity may lead to driver distraction through mental wandering.

[0009] This potential relationship between measured route and route familiarity and distraction could have implications for road safety. In fact, distraction is a key cause of crashes and driving errors. These findings are consistent with the “cognitive ability law”: the greater the decline in cognitive ability (in this case, through distraction), the greater the increase in accident rates. A dual effect of familiarity can be hypothesized: it can cause distraction by worsening responses to hazardous events, but it also leads to overconfidence and risk underestimation. Overconfidence in familiar drivers can be explained by an optimistic bias in perceived accident risk, which increases with driving experience and can potentially transfer to familiar routes. Relatedly, the perceived involvement of familiar drivers in accidents may be underestimated compared to unfamiliar drivers. Furthermore, route familiarity is often measured under self-perceived safest driving conditions. This often leads to overconfident measures in existing technological systems.

[0010] Furthermore, in the case of behavioral adaptation to road changes, habituation can also be observed, which is a set of unintended behaviors following the introduction of changes to the road transport system. Driver adaptation is troubling if road safety measures cause negative behavioral changes (e.g., speeding and inattention in well-lit conditions, or decreased compliance with mandatory speed limits over time). Adaptation is only possible when drivers are repeatedly exposed to the measures, and then readily notice the measures, potentially ruling out measures designed to reduce crash outcomes (e.g., restraint systems). Drivers familiar with the routes may adapt particularly easily because they can repeatedly test new situations (i.e., safety measures) and follow the usual habituation process, modifying their behavior to adapt to the new situation.

[0011] The simplified equation for quantifying the risk R of an event is: R = P × I, where P = the probability of the event being measured, and I = the strength of the consequences or effects. It can be measured using abstract terms like loss (such as the replacement cost caused by a traffic accident that occurs as an event).

[0012] While it is clear that road safety measures can reduce the probability of accidents (e.g., in the case of lighting), drivers who perceive this improvement may feel safer and modify their behavior to reduce driving time (by driving faster) or mental workload (by focusing less on driving, as in the case of lighting). However, these behavioral tendencies are associated with higher risk and can partially or completely undermine the risk reduction. This phenomenon represents the drawback of behavioral adaptation (previously associated with familiar drivers): the so-called "risk compensation." Although this effect is known, existing measurement systems often fail to address the technical challenges of capturing this complex interplay.

[0013] Regarding available sensing devices, the latest engineering in vehicle driving (including fully manual driving, partially autonomous driving, driverless cars, self-driving cars, and robotic cars) is associated with vehicles capable of sensing their environment and operational status or usage. Meanwhile, the use of sensors in cellular mobile phones (especially in so-called "smartphones") has increased significantly in recent years, enabling the monitoring or reliance on time-tracking of smartphone operating patterns and the surrounding environment, usage, or even user behavior. Modern mobile smartphones include various sensors such as touchscreens, accelerometers, gyroscopes, GPS, cameras, microphones, etc., allowing the capture of a large number of mixed contextual parameters during mobile device use. On the other hand, a vehicle's digital system may include transceivers and / or interfaces configured to communicate with the driver's mobile phone. Typically, the driver can utilize the vehicle's computer system to handle hands-free communication using vehicle characteristics. For example, conversations can be output to the vehicle's speakers and answered using the vehicle's microphone. Other occupants and / or passengers can participate in the conversation while the driver has initiated it.

[0014] Because modern automotive engineering vehicles can use devices such as radar, LIDAR (a measuring device that measures distance using lasers), GPS (Global Positioning System), odometers (a measuring device that measures changes in position over time using data from moving sensors), and computer vision to detect various operational or environmental parameters, communication between mobile devices and the vehicle's computer system can relate to data other than voice transmission. In modern vehicles, advanced control systems typically interpret sensed information to identify appropriate navigation paths, obstacles, and relevant signs. Sensors can include active and passive sensing devices, where sensors are physical converters that measure physical quantities and convert those quantities into signals that can be read by an observer or by another instrument, circuit, or system. Common sensors used in automobiles or mobile cellular phones include, for example, infrared sensors containing infrared emitters and infrared detectors used with contactless switches; passive infrared (PIR) sensors that react to and detect only ambient IR, such as motion sensors; speed detectors, such as radar guns, microwave radars that use the Doppler effect (the return echo from a moving object will be frequency-shifted), or IR / lidar sensors that send light pulses to determine the reflection time difference between consecutive pulses to determine speed; ultrasonic sensors that emit sound and detect the echo to determine range; accelerometers that measure the rate of change of capacitance and convert it into acceleration by means of a mass; and gyroscopes that measure along a first axis. The following are examples of sensors: a mass oscillating back and forth along a line, and a plate on either side of the mass along a third direction, where capacitance changes when rotation about a second direction is detected; an IMU sensor (Inertial Measurement Unit) that provides a sensor with all six degrees of freedom by using a combination of accelerometers and gyroscopes; force-sensing resistors, such as those used for contact sensing, touchscreens based on resistance, capacitance, or surface acoustic wave sensing; position sensors, such as GPS (Global Positioning System), triangulation, or cellular recognition systems; vision sensors, such as cameras and computer vision; SIM-based or RFID-based (Radio Frequency Identification) sensors; or environmental sensors, such as moisture sensors, humidity sensors, temperature sensors, magnetometers, etc. Thanks to the assistance of these digital systems and improved sensor data, vehicle driving becomes steadily safer by combining them with automated systems to monitor vehicle operation while the vehicle is in motion and provide coordinated alerts and assistance as needed.

[0015] In summary, challenges remain in the reliable and automated detection of trip familiarity, as well as the measurement of route familiarity and associated risk assessment. Trip familiarity identification is important in many technological applications, including in-depth traffic monitoring and machine-based intelligent analytics, urban planning, health monitoring, computer-supported elderly care, epidemiology, and more. Knowing a traveler's itinerary and frequency allows for targeted and customized e-advertising to be routed and sent to their devices. This information is also useful for developing context-aware mobile phones that sense the current situation and adjust their behavior accordingly. Furthermore, detecting, measuring, and / or monitoring the precise trip familiarity of individual users (e.g., along with transportation patterns) provides a more realistic picture of travel demand. This knowledge can help determine the environmental impact of travel patterns, such as a user's carbon footprint, and optimize travel patterns or track a user's daily steps and calories burned. Another application is the detection of real-time traffic conditions, as companies like Google collect data from mobile phones to estimate and measure traffic speeds on roads, or as technical traffic guidance or navigation systems are used to optimize traffic lighting, particularly real-time steering. Similarly, in the context of automated detection of trip familiarity (e.g., in conjunction with transportation modes), distinguishing different application categories is important. Accurate trip familiarity classification (again, in conjunction with transportation mode recognition and classification) can be critical when the system aims to trigger assistance or implement measures to notify, warn, or protect users, or when measuring user-specific exposure parameters in situations that may impact or affect ongoing events (such as accidents or disasters).

[0016] To determine trip familiarity and / or transportation patterns based on smartphones, data from various sensors built into the smartphone can be used. Most modern smartphone devices have sensors that measure motion, orientation, and various environmental conditions. They provide data with high measurement accuracy and precision. These sensors can be used to monitor the movement or positioning of a three-dimensional device, or to monitor changes in the surrounding environment near the device. Motion sensors include accelerometers, gravity sensors, gyroscopes, and rotation vector sensors. Position sensors include orientation sensors and magnetometers. Environmental sensors include barometers, photometers, and thermometers. In addition to information from mobile device sensors, some external data sources can also be valuable.

[0017] The smartphone sensors and external data sources commonly used in travel and / or transportation measurements can be summarized as follows: (A) Accelerometers are capable of measuring the physical motion of solid objects. In effect, they measure the accelerating forces applied to the device along all three physical axes, including gravity. Accelerometers are primarily used for orientation sensing in smartphones. However, travel and / or transportation measurements show that the acceleration generated during human movement varies throughout the body and depends on the activity being performed. A key feature that makes this sensor attractive is low power consumption; (B) Gyroscopes measure the rate of rotation of the device around each of the three physical axes. It can provide orientation information and add an additional dimension to the information provided by the accelerometer. Gyroscopes are typically characterized by low power consumption, but they are prone to error accumulation due to significant calibration errors, electronic noise, and temperature; (C) Magnetometers measure the ambient geomagnetic field along all three physical axes. It provides the mobile phone with simple orientation relative to the Earth's magnetic field; (D) Global Positioning System (GPS) sensors provide the user's position and velocity, which are measured based on the distance between the mobile phone and each of multiple satellites in two dimensions. Two-dimensional positioning requires a connection to at least three satellites, and accuracy increases with the number of visible satellites. GPS does not work indoors and is therefore primarily used for outdoor positioning. Another technical limitation is that positioning accuracy decreases in dense urban environments due to the fact that buildings reflect and block satellite signals. GPS is considered the most power-intensive positioning technology for mobile computing, and it significantly reduces phone battery life. The system's accuracy is between 50 and 80 meters and can be improved to up to 10 meters; (E) cellular network signals, which phones use for calls and data transmission. The most prevalent cellular phone standard in the world is the Global System for Mobile Communications (GSM). GSM base stations are typically equipped with multiple directional antennas that define coverage sectors or cells. Thus, a cell is a geographical area in a cellular communication network in which a mobile device can communicate with a specific base station. Each cell has a unique cell identifier. The hierarchical pattern of cell identifiers, along with signal strength, can provide information about the phone's location. To collect this type of data, an application must be installed on the mobile device to measure and record the surrounding radio environment. Mobile phones can be tracked in both outdoor and indoor scenarios. Accuracy varies from 50 to 200 meters depending on cell size, but may be even worse in low-density areas. Cellular network signals are associated with the "ping-pong" phenomenon, which occurs when a user is within the coverage area of ​​two or more base stations. Even when the user is stationary, the signal strength from the base stations weakens, causing repeated changes in associated cells. Data from mobile phone operators can be analyzed, consisting of anonymous location measurements generated each time a device connects to the cellular network (e.g., when making or receiving a call, when sending or receiving a text message, when the user connects to the internet, etc.).However, these measurements are only available during device use or when the associated cell changes over time (e.g., during a trip); (F) Bluetooth, which allows wireless connectivity and short-range communication. Bluetooth sensors can sense nearby devices and obtain their Bluetooth identifier, name, and type. The range and penetration of Bluetooth scanners vary between 10 and 100 meters and between 7% and 11%, respectively; (G) Wi-Fi, which provides wireless connectivity to devices within a wireless local area network (WLAN). WLANs offer a communication range of up to 100 meters and allow tracking of both outdoor and indoor devices. Smartphones do not need to log into a WLAN, but their Wi-Fi antennas must be turned on. Positioning accuracy is relatively low. When more than one access point is available, positioning can be improved using methods such as signal triangulation and digital printing. When used to provide location information, Wi-Fi is the second most power-consuming sensor after GPS. The so-called "ping-pong" effect is also typical for Wi-Fi data; (H) other sensors, including barometers that measure atmospheric pressure and can be used to detect how high a phone is above sea level, thermometers and humidity sensors that measure ambient temperature and humidity, cameras, microphones, etc.; and (I) external data sources that can provide additional useful information in trip and / or transportation measurements. These include network infrastructure data and route maps, as well as public transportation timetables in static or real-time form.

[0018] In existing technology systems, raw data measured and collected by various smartphone sensors is typically transformed into feature sets that are more computationally efficient and have lower dimensionality. The extracted features are intended to provide information and are, for example, relevant to a learning task. Various feature extraction techniques are used in existing technologies based on different data processing methods, algorithmic structures, and statistical processes. Raw sensor data is typically segmented into several windows, and features are extracted from these sample windows. Window size and sampling frequency are important parameters because they both affect the computation and power consumption of the sensing algorithm. Since some features are not effective (e.g., accelerometer frequency), smaller window sizes lead to higher classification accuracy, while larger window sizes may introduce noise into the data.

[0019] Time-domain and frequency-domain features are used for trip familiarity and / or transportation pattern detection tasks. Time-domain features are used to characterize information within time-varying signals. Many existing technology systems use raw velocity or acceleration data along with GPS positioning information over time as input features. Distance differences covered between measurements and heading changes are also used. For accelerometer signals, features such as the mean, standard deviation, median, minimum, or maximum value of the signal are most commonly used in the time domain. GSM signal strength and cell tower frequencies are used to infer different states of user motion. Compared to time-domain features, frequency-domain features are considered technically more computationally demanding. This is due to the additional processing steps associated with the data transformation from the time domain to the frequency domain. An example of these features is the peak frequency of the power spectral density of an accelerometer signal. Finally, features extracted based on external data typically include bus location proximity, bus stop proximity, and rail route proximity.

[0020] Existing algorithmic architectures for trip familiarity and / or transportation pattern detection can generally be categorized as discriminative or generative. Generative algorithms are based on modeling and / or simulating class conditional probability density functions and backward time probabilities. Therefore, they allow for the generation of samples from derived joint distributions and often flexibly express dependencies in complex learning tasks. For this group, existing system architectures include Naive Bayes algorithms, Bayesian networks, mixture models, and Hidden Markov Models. Discriminative algorithms do not attempt to model the underlying probability distribution. Instead, they focus on the direct estimation of posterior probabilities. Popular discriminative algorithms include Support Vector Machines, Neural Networks, Nearest Neighbors, Decision Trees, Random Forests, Clustering, etc.

[0021] Prior art document US 10,630,723B1 discloses a system for adjusting strategy characteristics based on the similarity between determined routes. A similarity metric can be determined, indicating the similarity between a first route followed by the vehicle and / or driver and a second (e.g., previously) route followed by the vehicle and / or driver. A suitably defined similarity metric indicates the similarity and variation in movement exhibited by the vehicle on the route. Specifically, the similarity metric is determined by applying analysis to real-time data collected from onboard sensors, mobile user equipment, external sensors, or other data sources. Based on the similarity metric, surcharges, deductibles, prices, or other characteristics of the strategy are determined. As a variation, if the driver is following a route different from a typical route, strategy characteristics are adjusted (e.g., in real-time) based on an analysis of the changing risk situation. Finally, EP 3 091 498 A1 discloses a mobile device-based system for classifying transport modes during a journey. The system includes a mobile device comprising a location detection system and an accelerometer. The mobile device collects location data and acceleration data during the journey. The system also includes a data processing unit for receiving location data from a mobile device, receiving contextual data associated with multiple transportation systems, and processing a first portion of the location data and contextual data using a first transportation mode classifier associated with a first transportation system, and processing a second portion of the contextual data using a second transportation mode classifier associated with a second transportation system. The data processing unit also classifies transportation modes during the journey and updates the classifier based on user input. Summary of the Invention

[0022] One object of this invention is to provide a more reliable and accurate automated system for automatic trip familiarity detection using sensor data from measurement-based mobile devices (such as cellular mobile phones or smartphones). The mobile device should be able to automatically detect and identify trip and / or route familiarity. Furthermore, the system should not be limited to frequency-based, distance-based, or pattern-based detection. Independent of potentially available dedicated vehicle hardware, alternative solutions can be provided, and this invention will provide suitable systems and methods for trip familiarity detection (particularly real-time trip familiarity detection, more particularly, continuous real-time or near-real-time tracking and familiarity detection) based solely on the available sensors of the smartphone user's smartphone. The output signaling for trip familiarity detection should achieve the accuracy required to be used as input signaling for electronic triggering or transfer to various technologies, trip familiarity-related processes and systems, such as navigation systems, traffic control systems, or risk measurement systems, particularly use-based risk transfer processes and / or appropriate use-based real-time risk transfer systems. Automatic use-based real-time risk transfer systems are enabled by the signaling of electronic trip familiarity detection to perform location- and / or familiarity-related risk transfer processes.

[0023] According to the invention, these objectives are achieved in particular by the features of the independent claims. Furthermore, other advantageous embodiments can be derived from the dependent claims and related descriptions.

[0024] According to the present invention, the aforementioned objective for trip familiarity detection based on sensor data measured by one or more sensors of a mobile device associated with a trip familiarity detection system for a user and / or vehicle is specifically achieved as follows: the one or more sensors include at least a GPS sensor and / or an accelerometer; the mobile device includes one or more wireless connections, wherein, via at least one of the wireless connections, by means of an antenna connection from the mobile device to a cellular data transmission network, the mobile device 10 acts as a wireless node within the cellular data transmission network; and the one or more sensors are connected to a mobile node monitoring application of the mobile device, wherein the mobile node monitoring application captures usage-based data from the one or more sensors of the mobile device. Based on sensor data and / or user-based sensor data, the mobile device measures multiple time series of sensor parameter values ​​based on measurement parameters obtained from the mobile device's sensors. Each time series includes at least a time series of sensor parameter values ​​measured by the GPS sensor's position and / or velocity. The GPS sensor measures the mobile device's longitude, latitude, and altitude as a time series by measuring different light speed delays in signals received from two or more satellites. For each measured time series, the start and end points of at least a portion of the measured sensor parameter values ​​are detected, thereby triggering the assignment of at least a portion of the measurement series to a specific trip with the detected start and end points. For any detected trip pairing, a first geographic distance is measured between the start points and the end points of the detected trip pairing based on GPS-based location parameter values ​​of at least a portion of the measurement sequence of sensor parameters 32. A second geographic distance is measured between the start point of the detected first trip and the end point of the detected second trip of the trip pairing, and between the start point of the detected second trip and the end point of the detected first trip of the trip pairing, based on GPS-based location parameter values ​​of at least a portion of the measurement sequence of sensor parameters. The start and end points of each detected trip of the trip pairing are measured for each of the two paired trips. The third geographic distance is measured by the distance between the two measured distances, where the third geographic distance is given by the relative difference between the two measured distances. The geographic distances of the three measured distances are normalized to each other by applying a modified sigmoid transition by mapping the geographic distances of the three measured distances to a normalized range from 0 to 1. The measured geographic distances are mapped to a range between 0 and 1. The total familiarity parameter value is measured by combining the three normalized geographic distance values ​​into a weighted average of the three normalized geographic distance values. The measured total familiarity parameter value is in a normalized range from 0 to 1, and a total familiarity parameter value of 0 indicates the same trip and a total familiarity parameter value of 1 indicates completely different trips.As a variation of the embodiment, the mobile device can also access sensor data from external sensing devices (such as vehicle sensors or smart home sensors) via interfaces such as Bluetooth or Wi-Fi. It should be noted that the trip length is not only the geographical "aerial" distance between the starting and ending points, but also takes into account route matching or can be generated, for example, as the sum of point-to-point distances of all GPS points in the trip time series. Additionally, a circular trip will have a distance of 0.

[0025] As a variation of the embodiment, clusters with start and end regions having defined radii can be stored, for example. The center of the start and / or end regions can be defined, for example, by the average of all start and end points of the trips associated with the cluster, and the radius is defined as the corresponding standard deviation. For the cluster, the average distance traveled and its standard deviation can also be generated and stored, for example, by system 114. Trips can be matched, for example, by generating the distance between the start and / or end points in units of the corresponding radius and the distance in units of the standard deviation based on the distance traveled in kilometers.

[0026] As another embodiment variation, trips can be clustered, for example, using a machine learning structure that iteratively groups the most closely associated trips together until no remaining trips are more closely associated than a defined threshold. Electronic trip familiarity detection can, for example, include one or more predefined hyperparameters that are dynamically optimized based on performance measurements of increases and decreases in electronic trip familiarity detection. To generate a first geographic distance, a second geographic distance, and / or a third geographic distance, for example, at least two hyperparameters can exist, which are weights for the origin and destination components and for the travel distance component. For clustering, for example, at least two hyperparameters can exist as distance thresholds, wherein two trips are detected within their range to form a cluster, and a minimum number of trips required to form a new cluster. Hyperparameter optimization can, for example, be performed individually for each possible technology application including different transport modes and / or different geographic locations and / or driver-to-passenger trips. Hyperparameter optimization can, for example, be performed individually for each possible transport mode, wherein the hyperparameters are optimized by varying them in a manner that maximizes the purity of the clusters found based on the transport mode.

[0027] In a variation of the embodiment, the mobile device may be implemented, for example, as a mobile telecommunications device, and one or more sensors are integrated sensors of the mobile telecommunications device. The mobile telecommunications device may be, for example, a cellular mobile phone and / or a smartphone.

[0028] In variations of the embodiments, the possible modes of transport that can be distinguished by the method may include, for example, at least land-based vehicles and / or sea-based vehicles and / or air-based vehicles and / or hiking and / or skiing. Land-based vehicles may, for example, include at least distinguishable modes for cars and / or motorcycles and / or bicycles. Attached Figure Description

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

[0030] Figure 1A block diagram schematically illustrating an exemplary system for the automated trip familiarity detection system 114 of the present invention is shown. The electronic trip familiarity detection 114 is based on sensing data 3 measured by one or more sensors 102 of a mobile device 10 associated with the trip familiarity detection system 114 and / or the vehicle. The one or more sensors 102 include at least a GPS sensor 1024 and / or an accelerometer 1025. The mobile device 10 includes one or more wireless connections 105, wherein, via at least one of the wireless connections 105, the mobile device 10 acts as a wireless node 221, ..., 225 within the cellular data transmission network 2 by means of an antenna connection from the mobile device 10 to the cellular data transmission network 2, and the one or more sensors 102 are connected to the mobile device 10. A mobile node monitoring application 101 captures usage-based and / or user-based sensor data 3 from one or more sensors 102 of a mobile device 10; the mobile device 10 measures multiple time series 331, ..., 33t of sensor parameter values ​​based on measurement parameters 3 obtained from the sensors 102 of the mobile device 10, each time series 331, ..., 33t including at least a time series 33i2 of sensor parameter values ​​32 measured by the position and / or velocity of the GPS sensors 1024 / 102, wherein the GPS sensors 1024 / 102 measure the position and / or velocity of the sensor parameters 32 by measuring different light speed delays in signals received from two or more satellites. The longitude position 10241, latitude position 10242, and altitude position 10243 of the measuring mobile device 10 are used as time series 33i2; for each measured time series 331, ..., 33t, the start point 11411 and end point 11412 of at least a portion of the measured time series 331, ..., 33t are detected, thereby triggering the assignment of at least a portion of the measured sequence 331, ..., 33t to a specific journey 1141 with the detected start point 11411 and the detected end point 11412; for any pair 1142 of the detected journey 1141, based on the measured sequences 311, 312, 313; 32 1. At least a portion of the GPS-based location parameter values ​​of sensing parameters 32 of 321, 322, 323 are used to measure a first geographic distance between the start points of the detected trip pair and the end points of the trip pair, and based on the measured sequences 311, 312, 313; 2. At least a portion of the GPS-based location parameter values ​​of sensing parameters 32 of 321, 322, 323 are used to measure a second geographic distance between the start point of the first trip of the detected trip pair and the end point of the second trip of the detected trip pair, and between the start point of the second trip of the detected trip pair and the end point of the first trip of the detected trip pair;A third geographic distance is measured by measuring the trip length between the start and end points of each detected trip in the trip pair for each of the two paired trips, wherein the third geographic distance is given by the relative difference between the two measured trip lengths; and the three measured geographic distances are normalized to each other by applying a modified sigmoid transition by mapping the three measured geographic distances to a normalization range from 0 to 1, wherein the measured geographic distances are mapped to a range between 0 and 1, wherein a total familiarity parameter value is measured by combining the three normalized geographic distance values ​​to a weighted average of the three normalized geographic distance values, wherein the measured total familiarity parameter value is in a normalization range from 0 to 1, and wherein a total familiarity parameter value of 0 indicates the same trip and a total familiarity parameter value of 1 indicates completely different trips. As a variation of the embodiment, the mobile device 10 can also access sensing data from external sensing devices (e.g., vehicle sensors or smart home sensors) via an interface such as Bluetooth or Wi-Fi. The measured time series 331, ..., 33t consists of a sequence of discrete-time measurements taken at consecutively equal, speed-related, or transport mode-related time points, describing the time course of the measured route or journey.

[0031] Figure 2A block diagram schematically illustrating an embodiment variant of an exemplary system for automatic transportation pattern recognition 113 is shown. During the supervised learning phase, a supervised learning structure 1136 is applied to a gradient-boosted machine learning classifier 1131 for transportation pattern recognition 113. The transportation pattern movement pattern 11351 of the measured trip 1135 is stored in the trip database 33. The mobile device 10 measures sensing motion parameters 311, 312, 313; 321, 322, 323 based on measurement parameters obtained from sensors 102 of the mobile devices 10 of the heterogeneous user group 6. The transportation mode 11351 of trip 1135 is identified by the transportation mode recognition device or system 113 from measured sensor motion parameter values ​​311, 312, 313; 321, 322, 323, wherein each trip includes at least the sensor motion parameter values ​​311, 312, 313; 321, 322, 323 of the GPS position measured by the GPS sensor 1024 / 102, the acceleration force applied to the mobile device 10 on all three physical axes by the 3-axis accelerometer 1025 / 1902, the operating system action parameter values ​​of the operating system of the mobile device 10, and the transportation mode marker value 1134. Trips 1135 with transportation mode marker 1134 detected by the gradient boosting machine learning classifier 1131 are fed into the user loop 1136 for dynamic correction by the user associated with the corresponding trip 1135, and are saved to the trip database 33 by updating the learned transportation mode 1135 of the measured trip 1135 in the trip database 33. The reliability of automatic transport pattern recognition increases with the accumulation of more data points. If system 113 fails to correctly identify a transport pattern, the user can choose to manually correct the predicted transport pattern in system 113. Automatic detection of changes and retraining of the supervised learning structure avoids repeating the same errors and improves overall performance: the predictive ability of TMR system 113 improves in continuous iterations.

[0032] Figure 3Another block diagram is shown, schematically illustrating an exemplary example of how the TMR system 113 generates average latitude and average longitude for each candidate sequence to obtain candidate stopping locations for each sequence / stop. Using the public transport algorithm inputs and outputs, the TMR system 113 can generate the following additional features: (i) the number of candidate stops (track stops) for the trip (CandidateStopsCount), (ii) the number of candidate stops (track stops) for the trip divided by the cumulative sum of the haversine distances between 16 sampled GPS points sorted in ascending order of time, in meters (CandidateStopsCountNormalized), and (iii) the number of suggested stops recommended by the best-match API (PublicRoute). (iv) the cumulative half-sine distance of suggested stops divided by the cumulative half-sine distance of 16 sampled GPS points in traversal order (PublicRoutingDistRatio), (v) the cumulative half-sine distance of candidate stops divided by the cumulative half-sine distance of 16 sampled GPS points (PublicRoutingCandidateDistRatio), and / or (vi) the percentile from 0 to 100 of the minimum distance from suggested stops to candidate stops, with a step size of 10 (this is the standard public stop algorithm). These features can be generated for all suggestions, but the selected features are those concerning suggestions with the minimum distance between suggested stops and candidate stops.

[0033] Figure 4 A block diagram schematically illustrating exemplary performance achieved by the overall automated TMR system 113 is shown, which... Figure 4 The confusion matrix is ​​described in the table below, and is obtained by using a 5-fold cross-measurement with a leave k-usersout splitting technique to reduce overfitting.

[0034]

[0035]

[0036] Figure 5A diagram illustrating an exemplary architecture for data preprocessing is shown. Before being input into the machine learning structure of the TMR system 113, the time series undergoes the following preprocessing steps: (i) rotating the 3-axis accelerometer from the smartphone reference system to the vehicle reference system, (ii) aligning the accelerometer with the GPS, sharing a common 10Hz sampling grid, and (iii) dividing each trip into multiple 5-minute mini-trips. For this exemplary case, the final input to the TMR system 113 is a fixed-length 4D time series with 3000 time steps (5 minutes * 10Hz).

[0037] Figure 6 A graph illustrating the exemplary performance of the automated TMR system 113 is shown. Performance has been evaluated using a 5x cross-measurement or cross-validation measurement technique with k users retained. Figure 6 And the results shown in the table below:

[0038] car 93,63％ 94,58％ 94,10％ motorcycle 89,02％ 87,23％ 88,11％

[0039] Figure 7 Another block diagram illustrating an exemplary overview of the architecture of the transportation pattern recognition system portion of System 1 is shown.

[0040] Figure 8 A block diagram schematically illustrates an exemplary overview of the trip extraction process.

[0041] Figure 9 A schematic diagram illustrating an exemplary car / non-car performance (F1 score) with minimum accuracy as a free parameter is shown.

[0042] Figure 10a and Figure 10b A schematic diagram illustrating an exemplary TMR performance (F1 score) with the number of sampling points as a free parameter is shown.

[0043] Figure 11 A schematic diagram illustrating exemplary candidate stop point extraction is shown.

[0044] Figure 12 A block diagram schematically illustrating an exemplary process enrichment is shown.

[0045] Figure 13 A block diagram schematically illustrating an exemplary feature extraction module is shown.

[0046] Figure 14 A diagram illustrating an exemplary recursive feature elimination method for Transportation Pattern Recognition (TMR) in System 1 is shown.

[0047] Figure 15An exemplary grid exploration diagram schematically illustrating the number of trees and tree depth parameters is shown.

[0048] Figure 16 A diagram illustrating an exemplary early TMR detection for the F1 score of the car / non-car classifier is shown.

[0049] Figure 17 and Figure 18 The performance of the current TMR service and the proposed solution are shown respectively, where Figure 17 The distribution of real-world markers and the performance of the deployed solution (baseline) are shown. Figure 18 The distribution of the real labels and the proposed solution are shown.

[0050] Figure 19 A diagram illustrating an exemplary F1 score showing the alteration of TMR label weights (probability quality assigned to automatic labeling) is shown.

[0051] Figure 20 A diagram illustrating an exemplary design for generating an index value for familiarity and familiarity score is shown, such that it sorts users in the following order (x-axis: cluster number, y-axis: cluster dimension) given a cluster dimension.

[0052] Figure 21 A graph schematically illustrating the correlation between the Gini index and the index used in the proposed variant of the embodiment (denoted as the "new index") is shown.

[0053] Figure 22 The diagram illustrates, schematically, an exemplary user traveling from the same point A to the same point B via different links. This behavior results in low aggregation in the link familiarity embodiment variant and high aggregation in the start-stop embodiment variant.

[0054] Figure 23 The diagram illustrates an exemplary situation where a user is traveling on the same street, but the geocoding measurement (e.g., HERE) gives links in a way that leads to incorrect behavior in the linking method. Typically, this occurs when a major street has two different link IDs for the two directions of the street, or when two streets are too close together and HERE places the user in the wrong one.

[0055] Figure 24 A diagram schematically illustrates an exemplary occurrence of the second scenario, where the user travels once from point A to point B1 (session S1) and once from A to B2 (session S2), as shown below. Figure 23As shown. If S1 and S2 have enough common links (users travel along the same path but stop at different places), the two trips are clustered together in the linking method, but not in the start-stop method (if the stopping points are not close enough).

[0056] Figure 25 A diagram schematically illustrates an exemplary embodiment variant of the Linked Packages (BOL) that does not generate clusters and therefore cannot perform direct comparisons regarding how trips are aggregated. However, the `get_familiarity` procedure can be considered to provide a good check of the method relative to other `get_familiarity` values ​​in other embodiment variants. The BOL embodiment variant becomes useful when a user makes a new trip using only links that have already been traversed in each of previous sessions, but does not cover 80% of the shortest of those sessions. In this case, the start and stop points are far apart, so `get_familiarity start / stop` will return 0, and the number of common links is insufficient to cover 80% of the links, so the `get_familiarity` of the linking method will also return a low score. Conversely, this new method will give a maximum score of 1 (see [link to BOL implementation]). Figure 23 ).

[0057] Figure 26 A diagram schematically illustrates an exemplary trip measurement using an appropriate trip summary. Upon receiving a TMR 113 request in real time, System 1 (corresponding to TMR 113) checks whether the user has already annotated or corrected a similar trip. Therefore, System 1 must be able to efficiently retrieve historical annotated trip data and define trajectory similarity measurements. Since the TMR 113 real-time request contains a representation of a trip with 19 points, it makes sense in this embodiment variant to store this representation for each annotated trip segmented by the user identifier. This can be done, for example, in a database or file system (e.g., one line per trip). User annotations can preferably be stored, for example, along with the trip summary. This trip summary can be built / updated in batches using, for example, Databricks (e.g., nightly). Embodiment variants may imply information availability within 24 / 48 hours of user annotation. Existing facilities and other methods are also contemplated.

[0058] Figure 27 A plot with a TMR baseline (given by a straight line) is shown, schematically illustrating exemplary weighting of parameters and evaluating performance under TMR 113. Multiclass probabilities can, for example, be weighted to be less than the annotation probabilities. This is consistent with the fact that if a user has corrected trips in the past and System 1 observes similar trips, the user should be trustworthy. A suggested value for the weights is 0.4.

[0059] Figure 28 A diagram illustrating an exemplary embodiment variation of the illustrated DPD 112 is shown, which can be used for trip familiarity detection 115, and may include, for example, the following technical steps performed by system 1 and trip familiarity detection and measurement 115 respectively: (1) collecting user history, (2) clustering similar trips, (3) defining centroid trips, (4) new trip arrival: seeking a match with existing clusters, and (5) checking cluster DPD tags. In the diagram, (i) N is the total number of sessions with DPD scores in the cluster, (ii) D i ∈[0,1]P i ∈[0,1] and X i ∈[0,1] is the final confidence score returned by DPD for each session (including entry / exit and BT connection), and (iii) the cluster score can also be generated from user comments (truth values) or ultimately from a combination of the two sources.

[0060] Figure 29 The diagram illustrates an exemplary target for creating a familiarity score, a measurement used to rate how much a user has traveled on a familiar road. This might require, for example, three different methods, such as... Figure 29 As shown, (1) clustering by link ID, (ii) link package: link ID frequency, and (iii) start & stop.

[0061] Figure 30 A diagram illustrating an exemplary implementation of the start & stop method as a powerful approach is shown.

[0062] Figure 31 An exemplary overview of a possible general architecture for trip familiarity detection and measurement is shown.

[0063] Figure 32 A diagram illustrating an exemplary implementation of a variant of an embodiment using a similarity pre-filtering technique is shown, particularly for TMR 113, where data processing is preferably performed only on a subset of possible candidates. A trip is considered a valid candidate for its start and end points, both of which are located within a certain radius of the start / end point of the current trip (the trip evaluated in the TMR live request). Based on empirical observation, for this example, the radius could be set to, for example, 500 meters. Since user annotations can be finite (under normal operating conditions) and using the proposed similarity pre-filter, trajectory similarity is effectively generated for a small subset of trips, as illustrated in the figure.

[0064] Figure 33A diagram illustrating an exemplary visual representation of the cluster is shown. Hollow circles mark the starting and ending regions. Blue lines represent routes for various journeys belonging to this cluster. Green (red) dots highlight the starting (ending) positions of the corresponding journeys.

[0065] Figure 34 The diagram illustrates an exemplary overview of a variant of an embodiment of travel measurement data collection and reporting, which may optionally be combined with travel pattern detection and / or travel purpose detection and / or travel additional detection and measurement.

[0066] Figure 35 A diagram illustrating an exemplary process for travel / travel segment detection based on time-series measurement data captured from a smartphone sensor is shown. Detailed Implementation

[0067] Figure 1 The diagram schematically illustrates the architecture of a possible implementation of an embodiment of a system and method for automated trip familiarity detection 114. Electronic trip familiarity detection 114 is based on sensing data 3 measured by one or more sensors 102 of a mobile device 10 of the trip familiarity detection system 114. The mobile device may, for example, be associated with a user 6 and / or embedded in a vehicle (such as a car or a marine vessel). The mobile device 10 may, for example, be implemented as a mobile telecommunications device 10, and the one or more sensors 102 are integrated sensors 102 of the mobile telecommunications device 10. As a variation of the embodiment, the mobile device 10 may also access sensing data from external sensing devices (e.g., vehicle sensors or smart home sensors) via an interface such as Bluetooth or Wi-Fi. The mobile telecommunications device 10 may, for example, be a cellular mobile phone and / or a smartphone. The one or more sensors 102 include at least a GPS sensor 1024 and / or an accelerometer 1025. Mobile device 10 includes one or more wireless connections 105, wherein, via at least one of the wireless connections 105, mobile device 10 acts as a wireless node 221, ..., 225 within cellular data transmission network 2 by means of an antenna connection from mobile device 10 to cellular data transmission network 2. One or more sensors 102 are connected to a monitoring mobile node application 101 of mobile device 10, wherein monitoring mobile node application 101 captures usage-based and / or user-based sensor data 3 from one or more sensors 102 of mobile device 10.

[0068] The mobile device 10 measures multiple time series 331, ..., 33t of sensing parameter values ​​based on measurement parameters 3 obtained from sensors 102 of the mobile device 10. The measured time series 331, ..., 33t consist of a sequence of discrete-time measurements at consecutively equal, speed-related, or transport mode-related time measurement points, describing the time course of the measured route or journey. Each time series 331, ..., 33t includes at least a time series 33i2 of sensing parameter values ​​32 from the position and / or speed measurements of GPS sensors 1024 / 102, wherein the GPS sensors 1024 / 102 measure the longitude position 10241, latitude position 10242, and altitude position 10243 of the mobile device 10 as time series 33i2 by measuring different light speed delays in signals received from two or more satellites.

[0069] For each measured time series 331, ..., 33t, the start point 11411 and end point 11412 of at least a portion of the measured sensor parameter values ​​of the time series 331, ..., 33t are detected, thereby triggering the assignment of at least a portion of the measured sequence 331, ..., 33t to a specific journey 1141 with the detected start point 11411 and the detected end point 11412. The detection of the start point 11411 and / or end point 11412 is triggered based on the measured sensor parameter values ​​of the time series 331, ..., 33t, wherein the earliest geographic coordinates (latitude and longitude) of the journey start point and the latest geographic coordinates of the journey end point are selected.

[0070] The detection of the start point 11411 and end point 11412 in at least a portion of the time series 331, ..., 33t of the measured sensor parameter values ​​may, for example, include: if a “start recording” trigger is fired and a “stop recording” trigger is fired, the monitoring module and / or application reports the precise geographic coordinates. The “start recording” and “stop recording” triggers may, for example, be based on the firing of an edge module operating in a mobile device monitoring different sensor parameters, the edge module including a motion detector and geofencing service built into the mobile phone. The process for automatic trip recording is based on the following steps:

[0071] Both app implementations (Android and iOS) handle "Start Recording" in the background, monitoring Bluetooth device connectivity, motion chip output, pedometer sensor activity, significant location changes (SLC event for iOS, FLP event for Android), and the AppStart event when the app is brought to the foreground. The "Start Recording" event is triggered if any of the following events are detected during background processing, and the next step, "Trip Verification," begins:

[0072] Bluetooth connection has been activated.

[0073] The action chip returns "Automotive" (for iOS) or "IN_Vehic" (for Android) with at least moderate confidence.

[0074] The pedometer sensor did not detect any steps within 25 seconds after the walking session.

[0075] SLC events are triggered by the operating system, such as changes in the wireless cell.

[0076] o Application launch

[0077] • Trip verification is the period following the triggering of the "Start Recording" trip event, after the application has monitored GPS speed for up to 120 seconds. Trip verification is successfully completed and the "Trip Recording" phase begins if at least five GPS speed values ​​of 20 km / h or higher are detected within 120 seconds. On Android, trip verification stops if walking-related actions are detected. There is no similar rule on iOS.

[0078] • “Trip Recording” is the time period during which the application records GPS at 1Hz, accelerometer at 10Hz, and distraction events. Recording stops when a “Stop Recording” trigger is detected.

[0079] The "Stop Recording" event trigger is the "Stop Trip Verification" phase, which will be explained in the next point. The "Stop Recording" trigger is fired based on the following rules:

[0080] Bluetooth connection lost for 120 seconds

[0081] The motion chip detects "walking" or "stationary" movements and GPS speeds below 10 km / h.

[0082] o GPS receiver fails to receive valid location information, accuracy is greater than or equal to 50 meters, or speed is less than 10 km / h for 10 minutes.

[0083] • If no GPS speed value exceeds 20 km / h within 90 seconds, the “trip termination verification” is successful; otherwise, the current “trip termination verification” is canceled, and the application continues recording until the next “stop recording” event.

[0084] It should be noted that, for mobile devices, several GPS-assisted data collection and recording methods (or simply GPS methods) are known in the prior art, providing time-series blocks of measurement parameter values ​​associated with the start and end of a trip. These systems or applications can run on mobile devices. However, many of these methods typically require significant financial and human resources to implement and impose additional tasks on participants. Recent advancements in smartphone-based positioning and communication technologies have allowed for overcoming the limitations of current GPS methods. However, considering the battery consumption process when using smartphones to record driving data, continuous recording of an individual's driving actions is not always possible in smartphone-assisted methods. To address this issue, an active data collection method can be envisioned to minimize the duration of trip recording. This method requires active participation from the participant during data collection and during the start / stop of trip recording. However, the accuracy of the data collected using this method may be negatively impacted by the high level of participant involvement. If a participant forgets to start / stop trip recording on time, they will miss the trip. Another technical possibility is to reduce positioning accuracy by increasing the recording interval or relying on inaccurate positioning algorithms. However, these alternatives adversely affect the quality of the collected data. As an alternative to the aforementioned embodiment variation for measuring travel data blocks with start and end points, a smartphone-based travel data measurement method is proposed, which addresses battery consumption issues and minimizes participant involvement while improving data collection accuracy. The proposed data processing can, for example, be designed to automatically detect individual single-mode travel segments based on a combination of real-time and post-processing. Figure 34 As shown, this method can automatically detect single-mode travel segments in smartphone-assisted driving data collection. The proposed method consists of a data collection process supported by an enhanced travel / travel segment detection model. A combination of real-time processing and post-processing was employed in the development of the proposed travel / travel segment detection model. The reliable performance of this model is crucial for accurately detecting and recording the participant's driving actions with high accuracy while managing smartphone battery consumption. This model is developed based on data automatically collected by the smartphone's sensors.

[0085] In this variant of the embodiment, data collection can be performed, for example, by a smartphone application running on a smartphone. It should be able to automatically record the driving behavior of survey participants throughout the workday, relying on its enhanced battery optimization. Figure 1An overview of embodiments of data measurement, collection, and / or reporting is presented. When the smartphone application is installed and launched on a smartphone, it runs in the background without interfering with the participant's normal phone use. It automatically starts and stops the trip recording process based on significant movement of the participant that triggers "start trip" and "stop trip" detection. During recording, the application automatically records the participant's travel attributes (e.g., timestamps, GPS coordinates, speed, heading, and location accuracy), for example, movement every 10 meters. The application automatically stops recording when the participant remains stationary for a predefined time threshold (e.g., six minutes). During the initial learning phase, at the end of the travel day, as a control loop, the participant can, for example, view his / her recorded trips and mark them on their phone by specifying purpose, travel mode, and accompanying persons. His / her marked trips can then be uploaded to a web server, for example, via a menu in a smartphone application, etc.

[0086] This embodiment variation can combine real-time processing and post-processing of the collected data. Real-time processing occurs within a smartphone application, while post-processing begins once the collected data has been uploaded to the research server. See, for example, [link to relevant documentation]. Figure 35 Real-time data processing can be used in smartphone applications for data cleaning, detecting stationary situations, splitting trips, and trip refinement. In this variant, the application performs initial data cleaning while storing logs on the smartphone. A threshold is defined for the horizontal position accuracy of the recorded points to remove points with a horizontal position accuracy exceeding 200 meters. These logs are automatically discarded by the smartphone application before trip data is stored. This criterion is important for excluding inaccurate logs and for efficiently storing and transmitting accurate data. The threshold is defined as the dwell time used to detect stationary situations. For example, if a stationary situation is detected beyond this interval, trip recording can be automatically stopped. Choosing an appropriate value for the dwell time can be crucial, as small values ​​will result in several incorrect trip / action detections. For example, traffic congestion or waiting at a red light can significantly increase the time difference between two consecutive trip logs. The dwell time must be appropriately chosen to ignore all intermittent points in a single-mode trip and detect actual start / end or mode transition points. Several values ​​for the dwell time have been tested during trial and error. A dwell time of 360 seconds for real-time processing returned the most accurate results. Since GSM signals are used to detect any significant movement, and any changes in GSM signals can lead to incorrect trip recordings (erroneous trips) in the trip refinement step, a 150-second threshold is defined to remove erroneous and very short trips.

[0087] In a variant of the combined embodiment, post-processing may include, for example, the following steps: (i) data cleaning, (ii) trip / trip segment identification, (iii) pattern category identification, (iv) trip merging, and (v) final trip refinement. Unlike previously proposed trip detection methods, it is proposed to discard data smoothing in the proposed trip detection framework. Many existing systems use data smoothing on raw GPS data; however, it should be noted that this may result in the removal of some informative trip logs that can be used for subsequent steps (specifically, trip detection) of trip attribute extraction.

[0088] For data cleanup, the following exemplary thresholds can be used to remove inaccurate logs that were not removed during the initial (real-time) data cleanup: (1) If (speed < 0) delete the trip log (unavailable speed (speed should be positive), (2) If (speed > 42 m / s) delete the trip log (speed based on incorrectly recorded historical data), (iii) If (acceleration > 10 m / s 2 The trip logs (based on unrealistic accelerations from historical data) are then deleted. A first threshold removes logs where the smartphone cannot detect the instantaneous speed (for which the instantaneous speed is recorded as -1). The second and third thresholds are defined based on the maximum speed and possible acceleration from historical data. These thresholds can be defined, for example, as 42 m / s and 10 m / s². 2 .

[0089] The system can process the cleaned data based on, for example, four different aspects: dwell time, participant ID, significant speed changes, and low-speed threshold. These rules are proposed based on the specifications of the collected data and can be calibrated, for example, as follows: (1) Dwell time: This rule is used to initially identify trips / trip segments. A threshold of 240 seconds is selected for this rule. This threshold is reduced compared to the dwell time threshold for real-time processing (i.e., 360 seconds) to more accurately detect stationary situations. To merge those trip segments that may be incorrectly segmented, a trip merging step is performed after the proposed trip segmentation model; (2) Participant ID: Participant ID is used to distinguish the driving actions of different participants; (3) Motorized / non-motorized trip identification: The following rules are applied to specifically identify non-motorized trip segments that immediately precede or follow a motorized trip: (a) Significant speed changes: A speed change threshold of 10 m / s is defined to detect significant speed changes. A point is marked as a significant speed change point if the difference between the average speeds of the 10 previous logs and the 10 later logs is greater than 10 m / s. These points can be indices for mode transitions; (b) Velocity change cluster detection: Since significant velocity changes can occur in continuous logs, this rule is defined to detect and cluster those continuous logs where significant velocity changes occur; (c) Low-velocity threshold: To list those mode transition points that change from motorized to non-motorized mode (or vice versa), a low-velocity threshold of 2 m / s is defined. This rule applies to those points selected based on the previous two rules, as well as those points that are in non-motorized mode on one side.

[0090] In a variation of this combination, for example, a rule-based structure can be used to classify detected trips / trip segments based on their pattern categories (motorized trips vs. non-motorized trips). The purpose of this step is to identify and merge trip segments that are not correctly segmented. The structure is based on outlier analysis of the average speed and acceleration of the reported trips and the movement patterns of the tagged participants. For example, outlier analysis (with 95% accuracy) can be performed on the average speed of the reported trips to distinguish between motorized and non-motorized trips. Furthermore, outlier analysis can be performed on the average acceleration of outliers for speed-related rules. For example, rules for pattern category identification can be defined as follows: (1) Pattern: Non-motorized pattern (cycling and walking) - Pattern - Detection rule: (a) Average speed ≤ 5.60 (m / s), and (b) Average acceleration ≤ 0.23 (m / s). 2 (1) In units); (2) Mode: Motorized mode (passenger cars, buses and trains) - Mode - Detection rules: (a) 5.60 < average speed (in m / s), and (b) 0.23 < average acceleration (in m / s). 2(Unit: ). Because a single trip may be split into several trip segments during the "trip splitting" step, a trip merging step is needed to identify and merge incorrectly split trip segments. Previously labeled consecutive trip segments are reviewed based on pattern category and time difference. If the time difference between two consecutive trip segments of a participant is, for example, less than 120 seconds and their patterns are composable, then the two consecutive trip segments are merged. As discussed (e.g., see...), Figure 35 There can be feedback loops from the "trip merging" step to the "trip detection" step. These feedback loops are controlled by a logical test of the total number of trips detected. This means the loop will continue until the same total number of trips is detected in two consecutive loops. To avoid over-segmentation of trips / trip segments and to facilitate further data refinement, predefined rules can be applied to identify and remove them. For example, a trip segment can be discarded if its travel distance is less than 50m or its duration is less than 30 seconds.

[0091] For any pair 1142 of the detected trip 1141, a first geographic distance is measured between the start points and the end points of the detected trip pair based on GPS-based position parameter values ​​of sensing parameters 32 of at least a portion of the measured sequences 311, 312, 313; 321, 322, 323. A second geographic distance is measured between the start point of the detected first trip and the end point of the detected second trip of the trip pair, and between the start point of the detected second trip and the end point of the detected first trip of the trip pair, based on GPS-based position parameter values ​​of sensing parameters 32 of at least a portion of the measured sequences 311, 312, 313; 321, 322, 323. A third geographic distance is measured by measuring the trip length between the start and end points of each detected trip of the trip pair for each of the two trips in the pair. The third geographic distance is given by the relative difference between the two measured trip lengths. The geographic distances of the three measurements are normalized to each other by applying a modified sigmoid transition, mapping the geographic distances of the measurements to a normalized range from 0 to 1. The total familiarity parameter value is measured by combining the three normalized geographic distance values ​​into a weighted average of the three normalized geographic distance values, where the measured total familiarity parameter value is within a normalized range from 0 to 1, and where a total familiarity parameter value of 0 indicates the same trip and a total familiarity parameter value of 1 indicates completely different trips.

[0092] In another embodiment variation, the signaling output of this trip familiarity detection system 114 can, for example, be used as a steering or input signal for an advanced driver assistance system (ADAS), traffic control system, navigation system, usage-based risk measurement and monitoring system, etc. For example, system 1 may include 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 system 12 may include at least one electronic first-tier resource aggregation system 121, and the automated second-tier risk transfer system 13 may, for example, include at least one electronic second-tier resource aggregation system 131. Resource aggregation system 121 / 131 is a system for automatically and electronically aggregating resources from designated risk-exposed occupants / drivers / passengers 6, thereby transferring defined risks associated with the risk-exposed user 6 to automated first-level and / or second-level systems 12 / 13. The operation of the risk transfer is defined by risk transfer parameters 122 / 132, for example, predefined by means of predefined parameters given by a risk transfer strategy. Furthermore, in the event that a defined risk has occurred at user 6, the automated resource aggregation system 121 / 131 differentiates the occurrence and detection of losses at the relevant risk-exposed user 6 by triggering a specific resource transfer from resource aggregation system 121 / 131 to the associated risk-exposed user 6, for example, by appropriate signaling based on generated payment transfer parameters 123 / 133. The operation of such system 1 will be described in detail below. Risk transfer parameters 122 / 132 may, for example, include parameters defining physical measurement parameters to detect the occurrence of risk events at the risk-exposed user 6 by means of system 1 and / or time- or quantity-related thresholds. The user 6 exposed to the risk can be any type of person, and the risk can be associated, for example, with vehicle or car driving or traffic risks, such as with a driver or passenger. The risk is related to the probability of an impactful event occurring in connection with the user 6 exposed to the risk. The automated system 1 may, for example, include at least a processor and an associated memory module. The operation of the system 1 is controlled, monitored, and manipulated by an electronic control device 11, particularly generating appropriate signaling and manipulating the activation and coordination of various components of the automated system 1. The automated system 1 may also include one or more display units and operating elements, such as a keyboard and / or graphical indicating devices (such as a computer mouse). The system 1 is a technical device, particularly including electronic devices used in the fields of computer and data processing technology, telematics technology, and automated risk transfer or insurance technology. This invention seeks to technically capture, manage, and automate the complex related operations of monitoring devices.

[0093] Transportation Pattern Recognition (TMR) 113

[0094] The architecture of a Transportation Pattern Recognition (TMR) system represents a machine learning (ML)-based solution: measuring and analyzing a set of labeled trips performed by heterogeneous user groups to extract a set of features for training a supervised multi-class machine learning architecture. The output of the pure machine learning architecture is then post-processed through a set of hard-coded rules to prevent the algorithm from making significantly incorrect or underconfident predictions. An additional module based on trip familiarity can identify user routes and can be enabled to increase model performance. The reliability of automated transportation pattern recognition increases as more data points are accumulated, where accumulation can be performed by an automated process, as described below. As a variation of the embodiment, if the ML architecture fails to correctly identify a transportation pattern, the user can choose to manually correct the predicted transportation pattern in the system. Changes can be automatically detected, and the supervised model can be retrained to avoid repeating the same errors and improve overall performance: the model's predictive ability improves in successive iterations (see...). Figure 2 ).

[0095] The measurement data used to construct a TMR system consists of trips captured and maintained through appropriate data structures, where each trip includes the following measurement parameters measured and recorded by the mobile device: (i) GPS location, (ii) 3-axis accelerometer, (iii) operating system actions, and (iv) transportation mode markings. Trips may include, for example, measurement data of transportation modes such as cars, motorcycles, trams, buses, bicycles, skiing, trains, airplanes, ships, or others.

[0096] The system can, for example, apply data filtering and preprocessing. For instance, during a trip, data can be filtered out based on criteria such as: (i) at least one minute in length, (ii) at least 30 GPS locations, and (iii) precise transport mode annotations. As a further preprocessing step, trips including GPS locations copied via timestamps, GPS locations with negative velocities, and GPS locations with an accuracy >50m can be removed, for example.

[0097] The system may also include a data enrichment process. For example, trip data may be enriched. As a variation of the embodiment, the enrichment process may also be based on an external API from a third-party provider. The enrichment performed may include, for example, (i) route matching to understand whether the trip is being performed on a road, (ii) querying the geometry near the trip using a Geographic Information System (GIS), where the GIS captures spatial and geographic data, and (iii) public transport matching. As a variation of the data enrichment, it is not necessary to perform enrichment on the entire GPS track to be performed; instead, it may be possible (e.g., due to some API limitations) to use only equally spaced subsets of GPS locations.

[0098] Features used for measuring and generating available travel data may include, for example:

[0099] (1) GPS characteristics, including (i) the mean, (ii) the standard deviation, and (iii) the percentiles from 0 to 100 in 10 increments (those with percentiles of 0, 10, 20, etc.) on the array of measured GPS velocities. The standard deviation is given on the array of measured GPS altitudes over the distance traveled, and (i) the standard deviation is given on the array of measured GPS accelerations, and (ii) the variance of the array obtained by measuring the angles between triplets of consecutive GPS points. GPS acceleration is defined in this paper as the ratio between the following two arrays: (i) the velocity difference between a GPS sample and the previous sample, and (ii) the time difference (in milliseconds) between a GPS sample and the previous sample.

[0100] (2) Accelerometer characteristics: If two or more accelerometer samples have the same timestamp, the last accelerometer sample can be selected, for example, relative to the array order. The accelerometer norm array is then calculated, and the mean of that array is removed from all identical arrays. From the norm array, the following parameters can be extracted: (i) percentiles from 0 to 100, with a step size of 10; (ii) interquartile range, which is the difference between the 75th percentile and the 25th percentile.

[0101] (3) Features based on operating system actions: Two features of operating system activities can be selected, for example, based on the following criteria: (i) "Forward integration" processing is chosen because of the event-wise behavior of the action tag, and because it is usually the most informative feature; (ii) "Assumed most likely" processing can be chosen, for example, for simplicity. An action event can be defined as a measurement object with a unique timestamp and a tag mapping with probabilities (if no tag exists, it is assumed to have zero probability). Two features are computed for each possible tag. The tags can be normalized to Android names: 'car', 'bicycle', 'hiking', 'running', 'stationary', 'unknown', 'walking', 'tilting', for feature vector naming compliance between the two operating systems. "Forward integration" can be implemented by assuming that the tag probabilities are valid until the next event. Each tag probability can be multiplied by the number of milliseconds elapsed until the end of the trip until the last received action event. This must be done for each tag in the list of possible tags. The results of these multiplications can be summed for each tag, and each sum can be divided by the difference between the trip end time and the first action event time, both in milliseconds. If a tag is never returned, the corresponding feature should be set to zero. Therefore, if there is no action at all for a run, all features should be set to zero. For example, a "treat as most likely" approach could be implemented where, for each possible tag, the number of events for which the tag is the most likely tag is counted, and then the count is divided by the total number of events (or the number of unique timestamps). In a 50 / 50 extraction, the most likely tag can be selected in any way.

[0102] (3) Public Transportation Characteristics: Given a set of GPS locations, candidate stops can be identified, for example, as sequences of points that meet the following conditions: (i) speed <= 3 m / s, (ii) sequence length > 5 seconds. The calculation can be performed after applying a moving average with a window length of 9 to the speed array. This means that each sample is replaced by the average of the sample itself plus the four samples before and after it. For each of these candidate sequences, the average latitude and average longitude can be generated to obtain the candidate stopping location for each sequence / stop (see...). Figure 3Using the public transport algorithm input and output, several additional features can be generated, including: (1) the number of candidate stops for the trip (track stops), (2) the number of candidate stops for the trip (track stops) divided by the cumulative sum of the half-sine distances between 16 sampled GPS points sorted in ascending order of time, in meters, (3) the number of suggested stops suggested by the best-match API, (4) the cumulative half-sine distance of suggested stops in traversal order divided by the cumulative half-sine distance of the sampled GPS points, (5) the cumulative half-sine distance of candidate stops divided by the cumulative half-sine distance of the 16 sampled GPS points (see point 2), and (6) the percentile from 0 to 100 of the minimum distance from suggested stops to candidate stops, for example, with a step size of 10 (this is the standard public transport stop algorithm). These features can be generated for all suggestions, but the selected features are those concerning suggestions with the minimum distance between suggested stops and candidate stops.

[0103] (4) Route matching (RM features): Route matching features can be generated, for example, to estimate whether a trip was not performed on a road based on sampled GPS points. Two statistical descriptors can be generated, for example, on the confidence of the tracking points: (i) the mean of the confidence and (ii) the variance of the confidence.

[0104] (5) Geofencing (GFE) Features: Using the geometry returned by a general geofencing, the features used by proximity search can be generalized, for example. Basically, given the enrichment of sampled GPS points, the percentage of points with the geometry can be generated within 10, 20, 30…100 meters. This may include points within the geometry whose distance is <0. These distributions can be generated, for example, for the following: (i) the percentage of points that only see roads within a radius of XX (XX from 10 to 100, with a step size of 10), (ii) the percentage of points that only see tracks within a radius of XX, (iii) the percentage of points that see either roads or tracks within a radius of XX, (iv) the percentage of points within airports (negative geometric distance), and (v) the percentage of points within airports (negative geometric distance).

[0105] The aforementioned feature set can be used, for example, to feed the following hyperparameter configuration to a machine learning gradient boosting structure (e.g., LightGBM): 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.

[0106] For hard-coded filtering rules, such as those added after a machine learning classifier, custom logic can be used to limit unwanted errors. The first set of rules applies to run-length features to correct obviously erroneous predictions. The second set of rules applies only to run-length patterns with low precision, adjusting predictions with low confidence levels, with the goal of reducing the false positive rate.

[0107] Rules based on trip characteristics could include, for example, (i) labeling the trip as “ship” if GFEWater0 > 0.5, (ii) labeling the trip as “other” if GFEWater0 < 0.2 and TMR-prediction = “ship”, (iii) labeling the trip as “airplane” if SpeedQuantile90 > 150 m / s, and (iv) labeling the trip as “other” if TMR-prediction = “airplane”, SpeedQuantile100 < 20 m / s, and GFEAirport = 0. For example, rules based on model confidence could be implemented, where the prediction would be changed to a fallback transportation mode if the predicted transport mode > a score threshold.

[0108]

[0109] Figure 4 Exemplary performance implemented by the TMR system is shown, such as... Figure 4 The confusion matrix and table are shown, and were obtained by using a 5x cross-validation technique with k users left to reduce overfitting.

[0110] As a variation of the implementation, in addition to the supervised learning structure used for TMR, a trip similarity strategy can be applied to further improve TMR performance and accuracy. The idea is to leverage user annotations on previous similar trips (if any) and use this information to correct TMR labeling, if necessary. Therefore, to find similar trips, a clustering algorithm can be run on, for example, the following features: (i) distance between trip start points*, (ii) distance between trip end points*, and (iii) trip distance (*the distance between the start / end points of two trips repeated after reversing one trip, ignoring the direction of travel).

[0111] To improve the identification of car and motorcycle transportation patterns, a dedicated binary classifier can be applied in a further embodiment variant. Leveraging the deep learning architecture used, the dedicated binary classifier aims to extract discriminative features directly from smartphone sensor time series: (i) 3-axis accelerometer data and (ii) GPS speed.

[0112] As further data preprocessing, the time series can be preprocessed, for example, before being received by the neural network, through the following steps: (i) rotating the 3-axis accelerometer from the smartphone reference system to the vehicle reference system, (ii) aligning the accelerometer with the GPS, sharing a common 10Hz sampling grid, and (iii) dividing each trip into multiple 5-minute mini-trips. The final input to the model can then be, for example, a 4-dimensional time series with a fixed length of 3000 time steps (5 minutes * 10Hz).

[0113] Figure 3 An exemplary model architecture is shown. Furthermore, performance can be evaluated, for example, by using a 5x cross-validation technique with k users retained, as shown below. Figure 4 The results are shown.

[0114] It is important to note that the architecture of the transport pattern recognition system is highly flexible across various implementation variations and can be executed in a variety of environments, such as the Databricks environment. Examples of Databricks environments offer advantages such as: (1) a shared codebase for rapid prototyping and testing; (2) the ability to directly reuse output code in solution deployments; and (3) the benefit of native Spark parallelism for performing multiple experiments and testing different approaches. Other environments may offer different advantages. Databricks is a technology environment developed from the AMPLab project at UC Berkeley, which contributed to the creation of Apache Spark, an open-source distributed computing framework built on Scala. In particular, Databricks provides a web-based platform for working with Spark, offering automated cluster management and IPython-style (interactive Python) notebooks—that is, a command shell for interactive computation in multiple programming languages, particularly Python, providing introspection, rich media, shell syntax, tab completion, and history.

[0115] For this invention, the analysis pipeline architecture is shaped as a process reflecting the real-time solution. The pipeline used can be divided into the following logical components: (1) extracting data (location, sensor, annotation debugging data) from TMR activities and IoT platforms and enriching it using GIS services (HERE); (2) extracting descriptors / features from valid trip data; and (3) learning a TMR classification model in a supervised learning setting. These three steps are the objects described below. The final output of the last step is a classification model structure that can be used by the production service. This structure is a standard estimator (scikit-learn) object that can be deployed on, for example, any architecture that supports Python. Figure 7 A block diagram illustrating an exemplary overview of the architecture of the transportation pattern recognition system portion of System 1 is shown, including (i) data extraction, data extraction and filtering, (iii) location sampling, (iv) candidate stops, (v) data enrichment, (vi) feature description, particularly GPS features, accelerometer features, operating system action-based features, public transportation features, RME features and GFE features, (vii) machine learning, (viii) hard-coded filtering rules, and (ix) early detection.

[0116] For data extraction, trip data must be merged from different tables. As trip identifiers, start / stop boundaries can be used, for example, boundaries uploaded as debug data by the appropriate debug module or application. This data is uploaded to a container and copied to the corresponding table stored in a data store. In principle, any trip boundary information can be used. For example, JSON (JavaScript Object Notation) trip boundaries can be used to ensure consistency with the debug application logic, but this is not a constraint. Furthermore, additional data that may not be included in the table within the first time period can be extracted from the JSON, most notably OS actions and TMR library tags. Since embodiment variations can use only the OS action tags of both, and these tags can be uploaded in the normal application data stream, debug JSON data is not a requirement of the solution of this invention (see [link to documentation]). Figure 8 ).

[0117] For data extraction and filtering, trip boundaries can be merged with the following exemplary data sources: (1) analyticsmodel_np0.positions for GPS positions, (2) analyticsmodel_np0.userannotation(Coloride) for ground reality provided by other users, (3) OS actions contained in JSON, (4) (optional) analyticsmodel_np0.accelerometers, and (5) (optional) analyticsmodel_np0.deviceevents. Within these trips, data is filtered by System 1 based on the following criteria: (1) at least one minute in length, (2) at least 30 GPS positions, and (3) exactly one user annotation. As a preprocessing step, System 1 can remove duplicate GPS positions, GPS positions with negative velocities, and GPS positions with an accuracy >50m by timestamps. Figure 9 The motivation for the latter option is illustrated, showing the performance change of the TMR classifier when the minimum accuracy threshold is varied. Since the performance change is not significant, it maintains consistency with the previously used threshold.

[0118] For location sampling, in order to perform real-time TMR calls, System 1 needs to perform data processing on a subset of data points because an arbitrary number of data points cannot be sent in a remote synchronous call. Based on performance analysis of multiple sampled GPS locations, the points to be sampled could, for example, be set to 16 points at equal intervals on the GPS location array. Other sampling strategies can also be used; however, no significant performance gain has been shown in this example. Furthermore, although more points can be sampled, there is currently no evidence that sampling more than 16 points may be beneficial. For example, 16 points could be chosen because it is the boundary of the HERE geofence API used for batch calls (see...). Figure 10a and Figure 10b ).

[0119] Candidate stop extraction can be performed, for example, by System 1, which is the same as the current TMR implementation. Given a set of GPS locations, candidate stops are identified as sequences of points that meet the following criteria: (i) velocity <= 3 m / s, and (ii) sequence length > 5 seconds. Data analysis is performed after applying a moving average with a window length of 9 to the velocity array. This means that each sample is replaced by System 1 with the sample itself plus the average of the four samples before and after it. For each of these candidate sequences, System 1 generates an average latitude and an average longitude, thus obtaining the candidate stopping position for each sequence / stop (see [link to documentation]). Figure 11 ).

[0120] For data enrichment, System 1 then uses external APIs (Application Programming Interfaces) (most notably the HERE service and appropriate proximity search) to enrich the trip data. The enrichment process can be described as follows: Figure 12 As shown. In addition to baseline data, the enrichment performed may include, for example: (1) route matching to understand whether the trip was performed on a road. In the experimental setup, the service used is HERE Route Matching Extension (RME). Alternative services or normalized data sources may be used, (2) querying the geographic information system (GIS) geometry near the trip, performed using the HERE GFE API / layer. This step is essentially a generalization of the GFE approach used in possible TMR solutions (same source, more general features), and (3) public transport recommendations, in this case the HERE Route API. In the analytical data processing pipeline of System 1, the data may be written to the file system, for example, after this stage. This can happen for the entire dataset, and it can happen slowly or incrementally on a monthly basis. This is because the enrichment step is a “slow” step.

[0121] For feature descriptions, System 1 generates multiple features based on all available or historical trip data (e.g., see...). Figure 13(Feature extraction is shown in the diagram). The calculated feature list is a superset of the features used. The features actually used in the TMR solution are described below; therefore, most of the generated features not described are typically outside the scope. This extraction method is primarily contained in the second step of the TMR analysis pipeline. In a production solution, if the constraint is a real-time TMR call, some features must be generated locally on the phone 10 used and sent along with the TMR API call. Alternatively, if TMR can be performed asynchronously, these features can also be generated once the trip data falls onto the IoT platform of System 1.

[0122] Regarding GPS features, on a GPS velocity array, for example, the following features can be generated: (1) the mean, (2) the standard deviation, and (3) percentiles from 0 to 100, with a step size of 10 (those percentiles are 0, 10, 20, etc.). In the exemplary Databricks implementation, the percentile NumPy function can be used, for example, with the interpolation parameter set to "nearest," and the known NumPy functions provide a large number of predefined mathematical operations, including standard trigonometric functions, functions for arithmetic operations, and functions for handling complex numbers.

[0123] On the GPS altitude array, for example, the following feature can be generated: standard deviation. Furthermore, GPS acceleration can be implemented as a ratio between the following two arrays: (1) the velocity difference between a GPS sample and the previous sample, and (2) the time difference (in milliseconds) between a GPS sample and the previous sample. Finally, on the resulting array of GPS acceleration, the following feature can be generated: standard deviation. Following the pipelined implementation, a measure of travel direction variance can also be generated. For example, zero values ​​can be removed from the azimuth array.

[0124] Regarding accelerometer characteristics: If two or more accelerometer samples have the same timestamp, the last one is selected relative to the array order. An accelerometer norm array can then be generated, and the mean of that array can be removed from all identical arrays. From the norm array, several statistics can be extracted, including: (i) percentiles from 0 to 100 with a step size of 10, and (ii) the quartile range, which is the difference between the 75th and 25th percentiles.

[0125] Regarding features based on operating system actions: Two features of the operating system actions can be selected based on the following basic principles: (1) Forward Integral can be selected because of the event-wise behavior of the action tag and because it is usually the most informative feature, and (ii) for simplicity, it can be selected as the most probable (CountAsMostProb). As used in this paper, an action event is an object with a unique timestamp and a tag mapping with a probability (if no tag exists, it is considered to have zero probability). Two features are generated for each possible tag. The tag can be normalized to Android names, for example: 'car', 'bicycle', 'hiking', 'running', 'stationary', 'unknown', 'walking', 'tilting', for feature vector naming compliance between the two operating systems. To perform the forward integral calculation, it can be assumed that the tag probability is valid before the next event. Each tag probability can be multiplied by the number of milliseconds elapsed until the next event or until the end of the journey of the last received action event. This must be done for each tag in the list of possible tags. System 1 sums the results of these multiplications for each tag and divides each sum by the difference between the trip termination time and the first action event time, both in milliseconds. If a tag is never returned, the corresponding feature should be set to zero. Therefore, if there is no action at all for the trip, all features should be set to zero. Furthermore, System 1 performs a counting as a most probable calculation, where for each possible tag, the number of events for which the tag is the most probable tag is counted and divided by the total number of events (or the number of unique timestamps). In the case of a 50 / 50 sampling, the most probable can be selected in any manner.

[0126] Regarding public transportation features, the input and output of the public transportation algorithm are used to generate some additional features: (1) CandidateStopsCount: the number of candidate stops (track stops) for the trip; (2) CandidateStopsCountNormalized: the number of candidate stops (track stops) for the trip divided by the sum of the half-sine distances between 16 sampled GPS points sorted in ascending order of time, in meters; (3) PublicRoutingNumStops: the number of suggested stops recommended by the best matching API. The features are calculated as follows: (4) PublicRoutingDistRatio: the cumulative half-sine distance of the suggested stops in traversal order divided by the cumulative half-sine distance of the 16 sampled GPS points (see point 2); (5) PublicRoutingCandidateDistRatio: the cumulative half-sine distance of the candidate stops divided by the cumulative half-sine distance of the 16 sampled GPS points (see point 2); and (6) the percentile of the minimum distance from the suggested stops to the candidate stops from 0 to 100, with a step size of 10 (this is the standard public stop algorithm). These features are calculated for all suggestions, but the selected features are those of suggestions with the minimum distance between the suggested stops and the candidate stops.

[0127] Regarding RME features: RME features are generated to estimate whether a trip was not performed on a road based on 16 GPS points. Two statistical descriptors are generated on the tracking point confidence: (1) the mean of the confidence using, for example, the RMEsampledTracePointsConfMean routine, and (2) the variance of the confidence using, for example, the RMEsampledTracePointsConfVariance routine.

[0128] Regarding GFE features: Using the geometry returned by the GFE API (e.g., HERE GFE API), System 1 can generalize the features used by proximity search. Basically, given the enrichment of 16 points, System 1 generates the percentage of points with the geometry within 10, 20, 30…100 meters. This may include points with a distance <0 within the geometry. These distributions are calculated: (1) GFERoadOnlyXX, the percentage of points generated that only see roads within a radius of XX (XX from 10 to 100, with a step size of 10), (2) GFERailOnlyXX, the percentage of points generated that only see tracks within a radius of XX (see point 1), (3) GFERailRoadXX, the percentage of points generated that see either roads or tracks within a radius of XX (see point 1), and (4) GFEAirport0, the percentage of points generated within the airport (negative geometric distance). The exhaustive way of mapping the geometry to the source points is to make a separate call for each of the 16 sampled GPS points. However, this can be expensive in terms of resources. For example, a batch call can be performed on all 16 points together, and then the geometry can be mapped back to the source points by minimizing the half-sine distance between each point of the geometry and the nearestLat / nearestLon attribute (for differences and details, see the batch version variant in the first step of the TMR pipeline - where GFE_API_Call should be replaced in step 1 and GFEFaits should be replaced in step 2). It should be noted that the second method is less expensive but also less accurate, so the overall performance may be slightly lower.

[0129] Following the feature generation stage, the run-length representation is serialized to the file system. To select the aforementioned features from a larger pool of generated features, cross-validated recursive feature elimination (see [link to relevant documentation]) can be used. Figure 14 To obtain an estimate of the optimal feature set, the results of multiple experiments are averaged in a leave-k-users-out setup. Feature importance can be evaluated for each classification setting (see below).

[0130] For machine learning, to maximize classifier performance and meet technical requirements, a two-stage classifier can be constructed, for example. The first classification stage is a dedicated "car" / "non-car" detection. This step maximizes performance on the primary mode of transportation of interest. Trips classified as "car" in the first step are permanently labeled as "car". Trips not classified as car are then fed into a multi-class classifier, which attempts to assign the correct mode of transportation among the available classes. If the multi-class class predicts "car" when it was not classified as "car" in the first step, the trip is labeled as "unknown". This is motivated by precise measurement evaluation. The classifier can be trained, for example, on the following modes of transportation using TMR NP0 pilot data: car, train, public transport, bicycle, motorcycle, ski, and airplane. An exemplary choice of classification algorithm is random forest. Other algorithms are also conceivable. The motivation for this choice may stem, for example, from the need to control overfitting in the model, controlling overfitting with probability estimates of predictions. Furthermore, this algorithm has the advantage of providing a good method for estimating feature importance. To tune the algorithm parameters, a grid exploration is performed after the feature selection stage (see...). Figure 15 An exemplary configuration is: (1) 250 trees with a maximum depth of 8 for a binary classifier, and (2) 250 trees with a maximum depth of 10 for a multi-class classifier. After successful training, the model and results can be serialized for consumption, for example, via a live service.

[0131] In addition, hard-coded filtering rules can be applied. Based on technical requirements, some custom logic can be added after the two-step automatic classifier to limit unwanted errors. The applied rules can be implemented as follows: (1) If PublicRoutingNumStops<3 or CandidateStopsCount<3 or PublicRoutingDistRatio<0.6 and the predicted TMR label is public (bus or tram), then the prediction is changed to "unknown". This rule aims to limit false positives for public transportation (car trips are predicted as bus trips), (2) If RMESampledTracePointsConfMean<0.25 and the predicted TMR label is not airplane, train or bicycle, then the trip is labeled as "unknown". This rule aims to remove non-road trips from car candidates, and (3) If SpeedQuantile90>320, then the trip is labeled as "airplane".

[0132] In addition to the full-track classification method described above, early classification can be performed, for example, when the classifier highly determines that the trip should not be classified as "car". This variant uses the exact same features and methods as the full-track mode, but calculates features only at the start of the trip. With an appropriate amount of data, early filtering of train and bicycle trips can be achieved, assuming early decisions are made for different categories simultaneously, similar to a production setup. The recommended time for early classification is 300 seconds, which can be based, for example, on empirical studies of the response to time windows based on F1 scores (see...). Figure 16 The exemplary production setup showed good performance at 180 seconds:

[0133] train 97％ 78％ 3％ bike 93％ 71％ 18％

[0134] The example classifier performed even better in the case of early detection at 300 seconds:

[0135] train 98％ 93％ 1％ bike 97％ 65％ 5％

[0136] Generally, higher accuracy may lead to over-serving, but mixing results in a rollback (very convenient for trains, but less effective for bicycles). The ability to filter out non-vehicle trips from car predictions always seems better.

[0137] The overall solution technically improves performance (see below). To obtain realistic performance predictions, performance was evaluated in a leave-k-users-out cross-validated setup. 3695 annotated trips collected using Coloride NP0 (TMR tenant) were fed as training data for the classifier, with the following label counts:

[0138]

[0139]

[0140] Passenger trips can, for example, be reassigned as “car” trips for TMR purposes. Figure 17 and Figure 18 The performance of the current TMR service and the proposed solution are shown separately. Read the two tables ( Figure 17 / 18), typically System 1 seeks two effects: (1) higher values ​​on the diagonal, which are better because they represent the percentage of trips correctly labeled by the classifier for each category, and (2) lower values ​​on the “Cars” column (outside the diagonal), which are better because they represent the percentage of trips mislabeled as cars for each category. Comparing the two tables, the following can be noted: (1) 96% of car trips are labeled as cars, which is a fallback value. This is slightly worse than the alternative solution, which defaults to cars and has a higher car coverage. The latter value is indeed high, but it is provided at the expense of accuracy, which is 82% on the baseline, while in the current solution, it improves to 89% for cars. (2) Introducing new unknown categories to capture trips that cannot be labeled based on sufficient evidence, and (3) a combination of machine learning and custom logic, both rooted in past experience from TMRs from different groups, thus helping to reduce the number of false car reports, i.e., non-car trips labeled as cars, for point 1. This is evident across all categories considered: -22% of bicycle trips were classified as cars (from 23% to 1%), -10% of public transport trips (from 33% to 13%), -2% of train trips, -6% of airplane trips, and -8% of ski trips. As already observed, the resulting accuracy effect is that car trips are predicted more cleanly, (4) while the accuracy of individual non-car categories is generally higher: +16% of train trips are correctly classified (98% correct), +10% of public transport trips, and +1% of bicycle trips. Airplane trips are an exception (-16% back), but it's worth remembering that these trips are labeled "unknown" instead of cars, (5) motorcycle trips proved practically indistinguishable from cars using available signals. Almost all motorcycle trips were regularly labeled as car trips. (6) Most ski trips (92%) are now classified as "unknown". This is not ideal, but far from dangerous, as they were never classified as car trips.

[0141] Furthermore, similarity supplementation can be performed at System 1 of the present invention. Therefore, in addition to supervised learning methods for TMR, a trip similarity strategy can be applied to further improve TMR performance. An additional method is to leverage user annotations (if any) on previous similar trips and use this information to correct the TMR label, if necessary. This feature can be easily integrated into the production API, where a 16-point representation of the user-segmented annotated trip is required to be available to the API. The service can, for example, receive the 16-point representation of a new trip along with the TMR probability output and match that trip with similar annotated trips (if they exist). Similarity is calculated using the Euclidean pseudo-distance between trajectories. If one or more matches are found, a simple weighted algorithm modifies the TMR probability based on annotation evidence. The new most probable category is then selected as the TMR label. Figure 19 An example F1 score is shown for changing the TMR label weights (probability quality assigned to automatic labeling).

[0142] The number of similar annotated runs for the examples to be considered is two, or one if only one exists. Using this parameter, the performance gain can be expressed as follows, for the F1 performance gain of the importance class, #annotation=2:

[0143] car 0.91 0.94 train 0.98 0.98 public 0.84 0.88 bike 0.88 0.85 motorcycle 0.00 0.51

[0144] Trip familiarity score or index measurement

[0145] According to the invention, there are different implementation variations to technically assign scores to users and sessions based on how much they follow a habit (i.e., familiarity score measurement). The first two implementation variations use clustering methods and then evaluate familiarity based on the dimensions of the clusters (and evaluate session familiarity based on the dimensions of the clusters they are assigned to).

[0146] The following describes variations of the clustering and scoring methods used:

[0147] In the first embodiment variant using a set of links per session (referred to herein as the link version), clusters are created using Jaccard similarity between the links of the sessions. Jaccard similarity (coefficient) measures the similarity between sets. It is defined as the measured size of the intersection of two sets divided by the size of the union. Specifically, the similarity between two sessions is calculated in this manner:

[0148]

[0149] Where L Sx It is a set of links to session x. For each session, aggregation starts from a cluster and proceeds by aggregating clusters with a similarity of at least 0.8. When a cluster has more than one session, the similarity between clusters is determined by considering the maximum similarity among all possible combinations of sessions.

[0150] In the second embodiment variant, the start and stop points of each session (referred to herein as start version and stop version) are used for clustering. The distance between two sessions is generated as follows:

[0151] D(S1,S2)=hav(P A1 ,P A2 )+hav(P B1 ,P B2 )

[0152] Where P XnLet A be the starting point (A) or ending point (B) of session n, and hav() be the half-sine distance between the two points. The half-sine distance measures the great circle distance between two points on a sphere with given longitude and latitude. For example, clustering can begin with the clusters of each session, considering the coupled starting and ending points of the sessions as the centroids of the clusters. The next step is to iteratively cluster clusters within 300 meters of each other. Whenever two clusters are connected, the centroid of the cluster is recalculated using a simple average of the latitude and longitude of the centroids A and B. Then another clustering is performed as before, but considering the centroid distances of points matched in reverse (starting and ending points matched).

[0153] After generating and clustering user familiarity scores, the Gini coefficient can be used along the cluster dimension to assign a familiarity score to each user. The Gini coefficient measures the inequality between values ​​in the frequency distribution (in this case, trip familiarity). A Gini coefficient of zero indicates perfect equality, where all values ​​are identical (e.g., all measurement points for the trip match). A Gini coefficient of 1 (or 100%) indicates the maximum inequality between values ​​(e.g., for a large number of trips where only one trip has a different measurement point, and all other trips match perfectly, the Gini coefficient will be close to 1). Note that for large sets of trips, it is unlikely to have a value close to 1.

[0154] The following relationship provides possible indices that can be used to generate familiarity and familiarity scores, respectively:

[0155]

[0156] Where |C i | represents the percentage of user sessions in the i-th cluster, with clusters decreasing in order of dimension. λ is a parameter between 0 and 1 that indicates how clusters are considered in the suggested score. This value defines the weight of each cluster in the final score, depending on the cluster's position in the ranking. For example, if this value is set to 0.5, the first cluster will be counted as 1, the second as 0.5, the third as 0.25, and so on. If the value is set to 1, each cluster is considered in the same way; if the value is set to 0, only the first cluster is considered. In a variant of the implementation, this value is set to 0.5. The main idea of ​​this index is to design a value that, given a cluster dimension, ranks users in the following order (x-axis: cluster number, y-axis: cluster dimension), such that... Figure 20 As shown.

[0157] To compare the Gini index with the index used in this variant, the index used is generated to adjust for the fact that the first and last two cases in the ranking have a desired score of 0 in the Gini index, which is an acceptable value only for the last case. Figure 21 The graph illustrates the correlation between the Gini index and the index used. It shows a set of values ​​that score 0 in the Gini index but appear significant in the new index. Furthermore, the correlation between the two indices appears to exhibit some regularity in a pair of values. The graph shows some groups of points placed on the same line. This implies that further exploration could lead to some clustering algorithm using a combination of these two indices.

[0158] In any case, the general correlation between these two indices should not be too high because they are based on two different concepts. The Gini coefficient defines a certain variance of the cluster dimension, while the new index defines a measure of how sessions are distributed across clusters, focusing on the primary cluster. Both can be considered measures of user familiarity. Finally, to score session familiarity, the session familiarity score is measured as the relative dimension of the cluster in which the session is placed, generated by dividing the number of sessions in the cluster by the total number of sessions for the user.

[0159] A third embodiment variant of familiarity (referred herein to as the "Bag of Links" embodiment variant (BOL)) starts with a familiarity score for each link to calculate familiarity for sessions and users. The familiarity score for each link for each user is generated as a percentage of the user's sessions in which the link appears. Session familiarity is generated as the average of the link scores within the session, and user familiarity is generated as the average of the scores of the links traversed by the user.

[0160] To compare the three proposed implementation variations, the following can be observed: In the first two implementation variations, familiarity depends on how the sessions are clustered. Upon examination of the results, the two methods yield different results in the following cases: Users travel from the same point A to the same point B, but via different links (see...). Figure 22 This behavior results in low clustering in the link familiarity variant and high clustering in the start-stop variant. Several cases have been found in the dataset where users are walking on the same streets, but the geocoding measurement (e.g., HERE) assigns links in a way that leads to incorrect behavior in the link implementation variant. Typically, this can happen if a larger street has two different link IDs for the two directions of the street, or if two streets are very close and the geocoding measurement (e.g., HERE) places the user in the wrong one. (See also...) Figure 23 ).

[0161] The second scenario occurs when the user travels once from point A to point B1 (session S1) and once from A to B2 (session S2), as follows: Figure 23 As shown. If S1 and S2 have enough common links (users travel the same path but end at different points), the two trips are clustered together in the linking method, but not in the start / stop method (if the stopping points are not close enough) (see...). Figure 24 ).

[0162] The BOL (Bundle of Links) implementation variant does not generate clusters, therefore a direct comparison of how trips are clustered cannot be performed. However, the get_familiarity procedure can be considered, which performs a good check relative to other get_familiarities in other implementation variants. The BOL implementation variant becomes useful when a user makes a new trip using only links that have already been traversed in each of the previous sessions, but does not cover 80% of the shortest trips in those sessions. In this case, the start and stop points are far apart, so get_familiarity start-stop will return 0, and the number of common links is insufficient to cover 80% of the links, so the get_familiarity of the linking method will also return a low score. Conversely, the new method will give a maximum score of 1 (see...). Figure 25 ).

[0163] To implement different implementation variations, different libraries can be used, for example, to generate familiarity and related examples of usage. Each library may require specific input and retrieve the same output consisting of three different data frames. An exemplary data frame may include the following components: (i) familiarity_user:UserID:User_ID,SessionSize[]: an array of dimensions containing the cluster of the user, Familiarity: an index calculated using the Gini index, Familiarity_v_2: an index calculated using the new index (as described above); (ii) familiarity_session:UserID:User_ID,SessionID:Session_ID,familiarity_sess: session familiarity, which is the relative dimension of the cluster where the session is placed (sessions in the cluster / total sessions of the user); and (iii) clusters:UserID:User_ID,Cluster: the identifier of the generated cluster,Sessions[]: sessions in the cluster,Centroid: centroids calculated differently depending on the situation. Each library can provide a function called `get_familiarity` (as mentioned above), which takes as input a data frame containing the previously computed cluster and a data frame containing a set of new sessions (each session must have the same shape as the data frame used to generate the cluster). The function returns a familiarity score for each session in the input set. Instead of updating the cluster, the function simply assigns each new session to an existing cluster and returns a slightly modified session familiarity score for that cluster (returning the session familiarity score of sessions contained in that cluster, as if it contained a new session). If the session comes from a new user, the function returns -1.

[0164] In a familiarity linking library such as Databricks, a familiarity function can be implemented with one line for each session and the following fields as input: (i) UserID: the user's identifier, (ii) StartTimeUTC: the start time of the session, used as the session ID, and (iii) LinkIDs[]: the set of links the user travels through in the session. For example, the absolute value of the LinkID can be taken so that only the links are considered, regardless of the direction of travel. Furthermore, in a familiarity linking deployment such as Databricks, an example of using a previous familiarity linking library can be provided. An environment can be selected on the widget, and the function saves three resulting data frames about three variables: familiarity_user, familiarity_session, and clusters. Databricks can be deployed in the described environment.

[0165] In the familiarity start / stop library, a function could be provided, for example, that requires a data frame with the following components as input: (i) UserID: User ID; (ii) StartTimeUTC: Session start time, used as the session ID; (iii) Coordinates{'lat_a':StartLatitude,'long_a':StartLongitude,'lat_b':EndLatitude,'long_b':EndLongitude}: A structure containing information about the start and end points of the session. As an example library for the familiarity start / stop library, a familiarity start / stop deployment could be provided, for example, as another databrick. This is an example of the use of the previous library. An environment can be selected on the widget, and the function saves three resulting data frames about three variables: familiarity_user, familiarity_session, and clusters. This databrick can be deployed, for example, in the described environment.

[0166] Furthermore, the output dataframe can differ from the previous one via, for example, the familiarity linking package. The three tables can have the following shapes: (1) Familiarity_user: (i) UserID: identifies the user, and (ii) UserFamiliarity: the user's familiarity, calculated as described above; (2) Familiarity_session: (i) UserID: identifies the user, (ii) SessionID: identifies the session, and (iii) SessionFamiliarity: the session's familiarity, calculated as described above; (3) Scores: (i) UserID: identifies the user, (ii) LinkID: identifies the link, and (iii) scores: the link's scores, calculated as described above. The scores table replaces the cluster table. When it is desired to generate a new set of familiarities for sessions, the library's get_familiarity function can be used, but a scores dataframe is passed instead of a cluster dataframe. The functions in this library can be implemented, for example, to require input with the following shape: (i) UserID: identifying the user, (ii) StartTimeUTC: the start time of the session, used as the session ID, and (iii) links[]: an array containing the absolute values ​​of the link IDs of the links the user traversed in the corresponding session. A familiarity linking package deployment can be provided as an example of the use of the previous library. An environment can be selected on the widget, and the functions store three resulting data frames with respect to three variables: familiarity_user, familiarity_session, and score. The database can be deployed in the described environment.

[0167] Trip familiarity test 114

[0168] The trip familiarity detection and measurement 114 of the present invention can be implemented as an integrated detection engine based on the aforementioned Driver-Passenger Detection (DPD) 112, Transportation Pattern Recognition (TMR) 113, and trip familiarity score measurement. That is, trip familiarity detection can be implemented using TMR 113, which measures the similarity to the annotated trip; DPD 112, which measures familiarity via the aforementioned link ID v1; and familiarity score measurement 114 using (i) familiarity via the described link ID v2 and / or (ii) start & stop and / or (iii) link packages. A total of five different exemplary familiarity clustering data processing and algorithms are disclosed herein. However, other processes are conceivable based on the disclosed techniques.

[0169] First, the disclosed TMR 113 can be used to provide the technical strategy and data processing considerations of this invention. When a TMR 113 request is received in real time, System 1 (corresponding to TMR 113) checks whether the user has already annotated or corrected similar trips. Therefore, System 1 must be able to efficiently retrieve historically annotated trip data and define a trajectory similarity metric. Since the TMR 113 real-time request contains a representation of a trip with 19 points, it is meaningful in this embodiment variant to store this representation of the trip for each annotated trip, partitioned by the user identifier. This can be done, for example, in a database or file system (e.g., one line per trip). User annotations can preferably be stored, for example, along with a trip summary. This trip summary can be built / updated in batches using, for example, Databricks (e.g., nightly). Embodiment variants can imply the availability of information from user annotations within 24 / 48 hours. Existing facilities and other methods can also be considered (see [link to documentation]). Figure 26 To weight the parameters and evaluate performance under TMR 113, the multi-class probabilities can, for example, be weighted to be less than the annotation probabilities. This is consistent with the fact that if a user has corrected a trip in the past and System 1 observes a similar trip, then the user should be trustworthy. A suggested value for the weights is 0.4. Figure 27 An example chart with a TMR baseline is shown.

[0170] An exemplary embodiment variant of DPD 112 can be used for trip familiarity detection 115, and it can, for example, include the following technical steps performed by system 1 and trip familiarity detection and measurement 115: (1) collecting user history, (2) clustering similar trips, (3) defining centroid trips, (4) new trip arrival: seeking a match with existing clusters, and (5) checking cluster DPD tags. This is by Figure 28 The diagram shows that N is the total number of sessions with DPD scores in the cluster, where D... i ∈[0,1]Pi ∈[0,1] and X i ∈[0,1] is the final confidence score returned by DPD for each session (including entry / exit and BT connection), and the cluster score can also be generated from user comments (real) or ultimately from a combination of the two sources.

[0171] The purpose of a familiarity score is to create a metric for rating how much a user has traveled on familiar routes. This might require, for example, three different methods, such as... Figure 29 As shown, that is, (1) clustering by linkID, (ii) link packet: linkID frequency, and (iii) start & stop. Figure 30 The start & stop method shown is a powerful approach in this context.

[0172] The DPD used in the familiarity detection 114 scenario may include the following: (1) for each user: (i) collecting trip history (~weeks), (ii) clustering similar trips (hierarchical clustering via Jaccard distance).

[0173]

[0174] Routes sharing 80% of geocoded measurements (e.g., HERE) links are defined as similar, and (iii) the average DPD tag is assigned to the cluster (using both user annotations and algorithm results); and (2) for the new arrival: (i) find a match with the existing cluster (Jaccard distance between the new route and the centroid), and (ii) check the cluster DPD tag.

[0175] Figure 30 An exemplary overview of a possible general architecture for trip familiarity detection and measurement 114 is shown. It must be noted that, given the performance and cost of System 1, measuring the similarity between trajectories can be computationally challenging. Therefore, as a variation of the embodiment, a similarity pre-filter can be used in System 1, particularly for TMR 113, where data processing is performed only on a subset of possible candidates. Trips whose start and end points are both within a certain radius of the start / end of the current trip (the trip evaluated in the TMR live request) are considered valid candidates. Based on empirical observation, for this example, the radius could be set to, for example, 500 meters. Since user annotations can be finite (under normal operating conditions) and using the proposed similarity pre-filter, trajectory similarity is actually generated for a small subset of trips, such as... Figure 31 As shown.

[0176] One of the technical objectives of trip familiarity detection is to automatically identify groups (“clusters”) of similar trips. These clusters reflect user habits and can be used to help predict, for example, transportation patterns or whether a user is traveling as a driver or a passenger. A good example is how people commute to work. Commuters often travel along the same routes and are likely to use the same modes of transportation each time. To cluster trips, it is necessary to find a way to quantify how similar two trips are. Below, two different implementation variations A / B of trip familiarity detection 114 and familiarity scoring are discussed in more detail:

[0177] (A) Jaccard index of HERE link ID:

[0178] 1. Trip sensor data is processed and enriched using additional data capturing location content such as road networks, buildings, parks, and transportation patterns. This data can also be accessed from external sources, such as map and location data providers and related service providers like HERE Technologies (hereinafter referred to as HERE). Therefore, route matching can be accomplished using information from providers like HERE. HERE represents routes as sequences of link IDs, where a single link ID represents a segment of road with uniform characteristics. A new link ID is initiated whenever a traveler is likely to turn or contextual information changes. The similarity of two link ID sequences can be measured using a Jaccard score, defined as the ratio of intersection to union. The intersection represents the number of unique link IDs present in both routes, and the union represents the number of unique link IDs present in at least one of the two routes. Scores range from 0 (completely dissimilar) to 1 (two sequences are identical).

[0179] 2. Clustering is typically performed on distance measurements, which can be obtained by subtracting a score from 1.

[0180] 3. To match a new trip with an existing cluster, a "centroid" must be stored. A centroid is defined as the set of link IDs that exist in the majority of trips belonging to the corresponding cluster. The degree of match between the new trip and the cluster is quantified by the Jaccard index between the link IDs of the centroid and the link IDs of the new trip.

[0181] (B) Starting point, ending point, and distance traveled:

[0182] 1. Use the Haversine formula to generate geographical distances between the start points of two trips and between the end points of the same trip. We want the cluster to also include trips executed in the opposite direction, and therefore additionally compare "start point 1" with "end point 2" and "end point 1" with "start point 2", then use the comparison that results in a smaller distance (greater similarity).

[0183] 2. Further compare and / or match the two trips based on their length, using kilometers as the unit. More precisely, use the relative difference in their lengths to properly handle trips that start and end at similar locations but have different routes.

[0184] 3. To ensure that all components contribute equally to the overall similarity of the two journeys, we apply a modified sigmoid function that maps all three components to a range between 0 and 1.

[0185] 4. Then, the overall familiarity is grouped into a weighted average of the three components, again yielding a number between 0 (same route) and 1 (completely different route).

[0186] 5. In this method, the cluster is stored as a starting region and an ending region defined as a circle. The center of the starting (ending) region is defined by the average of all starting (ending) points, and the radius is the corresponding standard deviation. Additionally, the average travel distance and its standard deviation are stored. This visual representation of the cluster is... Figure 33 As shown in the image.

[0187] 6. The new journey is matched by calculating the distance between the starting (ending) points in units of the corresponding radius and the distance in units of standard deviation based on the distance traveled in kilometers. Similarly, the sensitivity to the direction of travel (A→B and B→A) is avoided by using the same technique described above.

[0188] The preferred implementation follows the second method. This is because users frequently use parallel roads to avoid heavy traffic. For the link ID method, this results in completely different journeys, while for the second method, the resulting differences are negligible in most cases.

[0189] Routes are clustered by iteratively grouping the most closely associated routes together until no remaining routes are more closely associated than a configured threshold. For this purpose, machine learning structures, such as those from scikit-learn using the Python programming language, can be applied based on hierarchical clustering. With the machine learning-based clustering proposed in this paper, routes are grouped into sets of objects such that routes within the same group (cluster) are more similar to each other (in some sense) than routes in other groups (clusters).

[0190] According to the present invention, a cluster is a group of cluster members with definable small distances, dense regions of data space, intervals, and specific distributions. Utilizing the structure of the present invention, clustering is therefore technically approximated herein as a multi-objective optimization problem. Appropriate clustering structures and parameter settings (including parameters such as the distance to be used (also implemented as a distance function in variations), density thresholds, or the expected number of clusters) depend on the user's individual dataset and expected usage and / or transportation patterns. The clustering described herein is implemented as an automated task based on an iterative process of multi-objective optimization involving knowledge discovery and / or machine learning structures through trial and error. Therefore, the "starting point, ending point, and travel distance" method of the present invention includes certain hyperparameters that need to be optimized to achieve optimal performance. During distance generation, there are two parameters: the weights for the starting point and ending point components and the weights for the travel distance components. During clustering, there are also two hyperparameters: a distance threshold (at which we consider two trips sufficiently similar to form a cluster) and the minimum number of trips required to create a new cluster. Therefore, a total of four hyperparameters need to be selected. Optimization can preferably be performed individually for different use cases. For example, at least two such styles can be used: one for driver and passenger classification, where it is desired that clusters consist primarily of driver or passenger trips in order to generate valuable information to distinguish between the two categories. A second style is created for transportation pattern recognition 113, where parameters are selected in a way that maximizes the purity of the clusters found based on transportation patterns.

[0191] Machine learning-based clustering provides a set of clusters containing all or most objects in a dataset. Furthermore, the machine learning-based clustering of this invention can specify the relationships between clusters based on criteria such as frequency, the most frequent daytime hours of routes within a cluster, transportation patterns, etc., for example, the hierarchy of clusters embedded within each other. If the trip familiarity detection also includes risk measurement, i.e., a measurement of the probability of occurrence of events such as accidents, traffic congestion, etc., the criteria can be associated with different weights to calibrate the risk measurement to the relevant conditions. In this case, it should be noted that the criteria used to identify driver familiarity are crucial for most prior art systems. In prior art systems, two main criteria based on different scales are typically used to identify driver familiarity: (i) using a frequency-based scale (i.e., previously driven more than once a day to never driven on the route); and (ii) using a distance-based scale (i.e., from drivers near home to strangers). Clearly, on both detection criteria, a driver may become familiar with a route due to repeated exposure. The first scale (frequency-based) directly identifies familiarity, while the second scale (distance-based) indirectly identifies familiarity. Therefore, the recognition performance of existing technology systems is limited. By introducing the aforementioned weights, the system of the present invention does not have such limitations, but instead allows for detection that is technically dependent on different scales and standards.

[0192] It should be noted that since the clusters are stored as starting and ending regions defined as circles, where the center of the starting (ending) region can be defined by the average of all starting (ending) points, and the radius is the corresponding standard deviation, and where the distance can be defined as the average travel distance with its standard deviation as the variance, the clustering currently applied can be described as a distribution-based clustering structure. Therefore, for the technical aspects of detection, clusters are implemented as objects most likely to belong to the same distribution, where the probability of a measured route triggers an association with a cluster identified by a machine learning structure, where the recognition performance of route familiarity detection 114 refers to the ability to recognize previously experienced sensor inputs.

[0193] As another embodiment variation, for example, to further improve the performance of System 1, driver DNA measurement can be applied and performed by System 1. One purpose of System 1 and, for example, the corresponding telematics application is to measure and score driver behavior by recording GPS, accelerometers, gyroscopes, and other integrated sensors present in a personal mobile phone or black box. Different combinations of drivers and transportation modes result in different driving styles; furthermore, each driver has a different driving style based on external factors (e.g., weather, road type) and personal factors (e.g., trip motivation, time constraints, and trip familiarity). Given the prior assumptions, transportation mode recognition 113 and driver-passenger detection 112 can be improved based on System 1's in-depth identification and / or analysis of an individual's driving style in conjunction with their trip history. Another purpose of the telematics application is to provide machine-based guidance to the driver to reduce their risk while improving their driving style. Analyzing each user's driving style using relevant risk estimates will allow for the provision of personalized feedback and procedures to reduce each driver's risk exposure with a minimal amount of trip history. As a variation of the embodiment, different assumptions can be used to design features that can help technically define driving style: (i) the correlation between accelerometer and GPS speeds, (ii) the frequency of maneuvering and phone distraction events per kilometer, (iii) in-depth analysis of speed distribution while considering curvature during turns, (iv) analysis of speed distribution considering road curvature, speed limits, and road categories, and (v) analysis and feature extraction from accelerometer and gyroscope distributions based on road category, curvature, and shape. The use of clustering algorithms and the aforementioned features extracted from a single user's historical trip set allows for the definition and measurement of a driver's driving style. For driver DNA, as described above, System 1 clusters the features that measure and describe a user's driving style and associates each cluster with the frequency of transportation patterns, driver, or passenger trips present in the cluster. Finally, for each cluster, there will be a ranking of possible transportation patterns and the most likely output of the driver or passenger. This combination is referred to herein as the measurement of driver DNA.

[0194] Driver and Passenger Detection (DPD) 112

[0195] To identify and / or classify occupants of vehicles 41, 42, 43… based on sensor data measured by multiple sensors 102 of the cellular mobile device 10 of occupants 6 / 61 / 62, the multiple sensors 102 include at least an accelerometer 1025 and a gyroscope 1026. The mobile device 10 also includes one or more wireless connections 105, wherein, through at least one of the wireless connections, the cellular mobile device 10 acts as a wireless node 221,…,225 within the cellular data transmission network 2 by means of an antenna connection from the cellular mobile device to the cellular data transmission network 2, and the multiple sensors 102 are connected to a monitoring mobile node application 101 of the mobile device 10. One or more wireless connections 105 or wired connections of the mobile telecommunications device 10 may include, for example, Bluetooth as a wireless connection for exchanging data via a personal area network (PAN) built on the Wi-Fi 802.11 standard with in-vehicle Bluetooth capability and / or 3G and / or 4G and / or GPS and / or Bluetooth LE (Low Energy) and / or BT using short-wavelength UHF (Ultra-High Frequency) radio waves in the ISM (Industrial, Scientific and Medical) radio band of 2.4 to 2.485 GHz, and / or contactless or contact smart cards and / or SD cards (Secure Digital Storage Cards) or another interchangeable non-volatile memory card. In order to provide wireless connectivity 105, mobile telecommunications equipment 10 can, for example, act as a wireless node within a corresponding data transmission network by means of its antenna connection, particularly mobile telecommunications networks as described above, such as 3G, 4G, 5G LTE (Long Term Evolution) networks or mobile WiMAX or other network technologies based on GSM / EDGE and UMTS / HSPA, and more particularly has appropriate identification devices, such as SIM (Subscriber Identity Module).

[0196] The monitoring mobile node application 101 captures usage-based and / or user-based telematics data of cellular mobile device 10 and / or users 6 / 61 / 62 of cellular mobile device 10. The mobile telecommunications device 10 and the monitoring cellular mobile node application 101 may, for example, be connected to on-board diagnostic systems 431, ..., 435 and / or on-board interactive devices 441, ..., 445, wherein the mobile telecommunications device 10 captures vehicle data 3 based on usage 31 and / or user 32 of motor vehicles 41, 42, 43, ... and / or users. The mobile telecommunications device 10 may provide one or more wireless connections 1024, for example, by means of a Radio Data System (RDS) module 10241, and / or a 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 voice unit 10244 communicating with the Radio Data System 10241, the Positioning System 10242, or the Cellular Phone Module 10243. The satellite receiving module 10242 may include, for example, a Global Positioning System (GPS) circuit and / or a digital radio service module including at least a Global System for Mobile Communications (GSM) unit. Multiple interfaces of the mobile telecommunications device 10 for connection to at least one of the vehicle's data transmission buses may include, for example, at least one interface for connection to the vehicle's Controller Area Network (CAN) bus, such as a connection to an On-Board Diagnostics (OBD) port, or another connection, such as for a battery mounting device, or OEM (Original Equipment Manufacturer) installed systems gaining access to information from on-board sensors or entertainment systems (such as Apple CarPlay) to provide necessary vehicle sensor information.

[0197] As described above, a data link 21 is established on the mobile telecommunications network 2 between the mobile telematics application 101 (acting as a client) and the intelligent central vehicle circuit 11 via the wireless connection 105 of the mobile telecommunications device 10. The mobile telecommunications device 10 acts as wireless nodes 221, ..., 225 within the mobile telecommunications network 2. Operating parameters 40121 and environmental parameters 40111 are measured by the mobile telecommunications device 10 via the mobile telematics application 101 during operation of the vehicles 41, 42, 43... and collected as vehicle telematics data 3 in the data flow path 103, and transmitted to the central circuit 11. The intelligent central circuit 11 includes a sensor data-driven core aggregator 110 with multiple dynamically applied sensor data-based triggers 1012 that trigger, capture, and monitor the sensor parameters in the data flow path 103 via the mobile telematics application 101 of the mobile telecommunications device 10. Mobile telecommunications equipment 10 may include, for example, at least one GPS module (Global Positioning System) and / or a geological compass module based on a 3-axis teslameter and a 3-axis accelerometer, and / or a gyroscope sensor or gyroscope, and / or a MEMS accelerometer sensor, and / or a MEMS magnetometer or a magnetoresistive permalloy sensor or another 3-axis magnetometer, the MEMS accelerometer sensor including a cantilever beam with seismic mass as proof mass for measuring appropriate acceleration or gravitational acceleration.

[0198] Mobile device 10 measures gravitational acceleration motion sensing data using accelerometers based on measurement parameters obtained from the accelerometers. The user's vehicle 41, 42, ... entry or exit movement patterns are detected from the acceleration motion sensing data, which includes at least the base axis and rotation patterns associated with the user's vehicle entry or exit. The detected vehicle entry or exit movement patterns of user 10 are used as input features to trigger the identification of the user's vehicle entry or exit movement by performing decision tree classification on the input features to exclude whether the user entered or exited the vehicle from the left or right side. It should be noted that system 1 can also be implemented using other classification algorithms or structures (e.g., augmented trees or neural networks).

[0199] The DPD system 112 allows for the selection of (as few as possible) characteristic input features to reduce the number of model parameters to be used. The DPD (Driver / Passenger Detection) method and system of the present invention includes at least the following three main steps: 1. Detecting the exact moment a user enters / exits the vehicle by analyzing acceleration. 2. Using gyroscope data to select various features, such as the direction and angle of rotation associated with entry / exit. 3. Performing decision tree classification on the input features to rule out whether the user entered (exited) from the left / right side of the vehicle. This system provides the detection of the exact moment a person enters / exits the vehicle. It should be noted that without this information, any further analysis of the gyroscope sensor would be useless for the DPD problem, as users can perform many rotations in a wide variety of movements. The detection step is accomplished by collecting information about the variance of acceleration in the upward / downward (Earth reference system) direction and the presence (or absence) of certain discontinuities in the acceleration signal in the smartphone reference system (unrotated).

[0200] One advantage of this invention is its ease of adaptation and applicability for use in modular systems, for example, to technically provide trip familiarity detection. Therefore, the Driver-Passenger Detection (DPD) system of this invention can, for example, be implemented as part of an inventive, more complex, and composite modular monitoring and detection system 1, having interactive Driver-Passenger Detection (DPD) 112, Transportation Pattern Recognition (TMR) 113, and trip familiarity detection and / or scoring 114, allowing for broad use in monitoring user actions related to his / her mobile phone usage.

[0201] List of reference numerals

[0202] 1. Mobile recognition and classification system

[0203] 10 Mobile telecommunications equipment

[0204] 101 Mobile Telematics Applications (Cellular Mobile Node Applications)

[0205] 102 Integrated Sensors for Mobile Nodes

[0206] 1020 MEMS magnetometer

[0207] 1021 Proximity Sensor

[0208] 1022 fingerprint sensor

[0209] 1023 Ambient Light Sensor

[0210] 1024 GPS sensor

[0211] 10241 Longitude position

[0212] Latitude 10242

[0213] 10243 Altitude Position

[0214] 1025 Accelerometer

[0215] 1026 Gyroscope

[0216] 1027 camera

[0217] 1028 Touchscreen

[0218] 1029 MEMS Compass Module

[0219] 1030 Back-illuminated sensor

[0220] 1031 NFC sensor

[0221] 103 Data Flow Path

[0222] 105 Wireless Connection

[0223] 1051 GSM

[0224] 1052 WLAN

[0225] 1053 Bluetooth

[0226] 1054 Near Field Communication (NFC) (for NFC sensors)

[0227] 11 Central Circuit

[0228] 110 Telematics-Driven Aggregators

[0229] 1101 Data Interface

[0230] 111 Machine Learning Module

[0231] 112 Driver and Passenger Detection (DPD) System

[0232] 113 Transportation Pattern Recognition (TMR)

[0233] 1131 Gradient Boosting Machine Learning Classifier

[0234] 1132 Input feature values

[0235] 1133 Transportation Mode

[0236] 11331 Public Transportation

[0237] 11332 Motorcycle

[0238] 11333 Bicycle

[0239] Train 11334

[0240] 11335 Tram

[0241] Airplane 11336

[0242] 11337 Car

[0243] 11338 Skiing

[0244] Ship 11339

[0245] 1134 Transmission Mode Flag (Output Value)

[0246] 1135 Itinerary

[0247] 11351 Transportation Mode - Mobile Mode

[0248] 1136 Supervised Learning Structure

[0249] 114. Trip Familiarity Measurement and Testing

[0250] 1141 Itinerary 1, ..., t

[0251] 11411 Starting points of journey 1, ..., t

[0252] 11412 Termination points of journey 1, ..., t

[0253] 11413 The length of the distance traveled as a measure of geographical distance, 1, ..., t.

[0254] 1142 Pairing of 1, ..., t with 1, ..., p, where

[0255] 1143 Familiarity parameters for measurements of pairing 1, ..., p

[0256] 11431 First geographical distance

[0257] 11432 Second geographical distance

[0258] 11433 Third geographical distance

[0259] 1144 Itinerary cluster 1, ..., c

[0260] 11421 Distance threshold for similarity

[0261] 11422 Minimum number of trips required to create a cluster

[0262] 12 First-level automated risk transfer system

[0263] 121 Electronic First-Level Resource Aggregation System

[0264] 122 First-level risk transfer parameters

[0265] 123 First-level payment transfer parameters

[0266] 13 Second-tier automated risk transfer system

[0267] 131 Electronic Second-Tier Resource Aggregation System

[0268] 132 Second-level risk transfer parameters

[0269] 133 Second-level payment transfer parameters

[0270] 2. Data transmission network

[0271] 20 Cellular Network Mesh

[0272] 201, ..., 203 Network cell / basic service area

[0273] 211, ..., 213 Base stations (transceivers)

[0274] Cell Global Identifier (CGI) 2111, ..., 2131

[0275] 221, ..., 226 Cellular network nodes

[0276] 21. One-way or two-way data link

[0277] 3. Sensing parameters of mobile device 10

[0278] 31 Sensing parameter values ​​of a 3-axis accelerometer

[0279] 32. Sensing parameter values ​​of GPS sensor

[0280] 33 Trip Database

[0281] 331, ..., 33t are time series of measured sensor parameter values ​​stored for strokes 1, ..., t.

[0282] 33i1 stores the time series of sensor parameter values ​​measured by the 3-axis accelerometer for stroke i.

[0283] The 33i2 stores the time series of GPS sensor parameter values ​​measured for trip i.

[0284] 41, 42, 43, ... motor vehicles

[0285] 401, ..., 405 Vehicle-mounted sensors and measuring equipment

[0286] 411, ..., 415 OEM (Original Equipment Manufacturer) Equipment

[0287] 421, ..., 425 Data Transmission Bus Interface

[0288] 431, ..., 435 On-board Diagnostic Systems

[0289] 441, ..., 445 In-vehicle interactive devices

[0290] 451, ..., 455 Automotive Telematics Equipment

[0291] 6 mobile device users

Claims

1. A method for electronic trip familiarity detection (114), the method being based on sensing data (3) measured by one or more sensors (102) of a mobile device (10) associated with a user (6) and / or a vehicle, said one or more sensors (102) including at least a GPS sensor (1024) and / or an accelerometer (1025), said mobile device (10) including one or more wireless connections (105), wherein, Through at least one of the wireless connections (105), the mobile device (10) acts as a wireless node (221, ..., 225) within the cellular data transmission network (2) by means of an antenna connection from the mobile device (10) to the cellular data transmission network (2), and the one or more sensors (102) are connected to a monitoring mobile node application (101) of the mobile device (10), wherein the monitoring mobile node application (101) captures usage-based sensing data (3) and / or user-based sensing data (3) from one or more sensors (102) of the mobile device (10). The mobile device (10) is characterized in that it measures multiple time series (331, ..., 33t) of sensing parameter values ​​based on sensing data (3) obtained from the sensor (102) of the mobile device (10), each time series (331, ..., 33t) including at least a time series (33i2) of sensing parameter values ​​(32) of the position and / or velocity measurement of the GPS sensor (1024 / 102), wherein the GPS sensor (1024 / 102) measures the longitude position (10241), latitude position (10242) and altitude position (10243) of the mobile device (10) as a time series (33i2) by measuring different light speed delays in signals received from two or more satellites. The feature is that, for each measured time series (331, ..., 33t), the start point (11411) and end point (11412) of at least a portion of the measured sensor parameter values ​​are detected, thereby triggering the assignment of at least a portion of the measured time series (331, ..., 33t) to a specific journey (1141) having the detected start point (11411) and the detected end point (11412), wherein the start point (11411) and end point (11412) of at least a portion of the measured sensor parameter values ​​are detected. The detection in 412) includes: if a start recording trigger is fired and if a stop recording trigger is fired, the monitoring module reports precise geographic coordinates, wherein the start recording trigger and the stop recording trigger are fired based on an edge module running in a mobile device monitoring different sensor parameters, the different sensor parameters including at least parameters from motion detection and / or geofencing built into the mobile phone, and wherein the start recording trigger is triggered by detecting at least a significant change in location, and the stop recording trigger is triggered by detecting a GPS speed below a threshold for at least a predefined time period. The feature is that, for any pairing (1142) of the detected trips (1141), a first geographical distance between the starting points of the detected trip pair and a first geographical distance between the ending points of the trip pair are measured based on the GPS-based position parameter values ​​of at least a portion of the measured sensor motion parameter values ​​(311, 312, 313; 321, 322, 323); and a second geographical distance between the starting point of the detected first trip of the trip pair and the ending point of the detected second trip of the trip pair and a second geographical distance between the starting point of the detected second trip of the trip pair and the ending point of the detected first trip of the trip pair are measured based on the GPS-based position parameter values ​​of at least a portion of the measured sensor motion parameter values ​​(311, 312, 313; 321, 322, 323). The feature is that a third geographic distance is measured by measuring the trip length between the detected start and end points of each trip in the paired trips, wherein the third geographic distance is given by the relative difference between the two measured trip lengths. The feature is that the geographic distances of the three measurements are normalized by applying a modified sigmoid transfer function by mapping the geographic distances of the three measurements to a normalized range from 0 to 1, wherein the total familiarity parameter value is measured by combining the three normalized geographic distance values ​​into a weighted average of the three normalized geographic distance values, and wherein the measured total familiarity parameter value is mapped to a normalized range from 0 to 1.

2. The method for electronic journey familiarity detection (114) according to claim 1, characterized in that, The storage has a cluster with a starting region and an ending region with a defined radius.

3. The method for electronic journey familiarity detection (114) according to claim 2, characterized in that, The center of the starting and / or ending regions is defined by the average of all starting and ending points of the journeys associated with the cluster, and the radius is defined as the corresponding standard deviation.

4. The method for electronic journey familiarity detection (114) according to claim 3, characterized in that, For clusters, the average travel distance and its standard deviation are also stored.

5. The method for electronic journey familiarity detection (114) according to claim 3, characterized in that, The trip is matched by generating the distance between the starting point and / or the ending point in units of the corresponding radius and the distance in units of the standard deviation based on the number of kilometers traveled.

6. The method for electronic journey familiarity detection (114) according to any one of claims 1 to 5, characterized in that, The machine learning structure uses hierarchical clustering to cluster the trips, iteratively grouping the trips that are most closely linked together until there are no remaining trips that are more closely linked than a defined threshold.

7. The method for electronic journey familiarity detection (114) according to claim 6, characterized in that, The electronic trip familiarity detection (114) includes one or more predefined hyperparameters that are dynamically optimized based on performance measurements of the increase and decrease of the electronic trip familiarity detection (114).

8. The method for electronic journey familiarity detection (114) according to claim 7, characterized in that, To generate the first geographic distance, the second geographic distance, and / or the third geographic distance, there are at least two hyperparameters, which are weights for the start and end point components and for the travel distance component.

9. The method for electronic journey familiarity detection (114) according to claim 7, characterized in that, For the clustering, there are at least two hyperparameters serving as distance thresholds, wherein two trips are detected within the range of the hyperparameters to form a cluster, and a minimum number of trips required to form a new cluster is defined.

10. The method for electronic journey familiarity detection (114) according to claim 8, characterized in that, For the clustering, there are at least two hyperparameters serving as distance thresholds, wherein two trips are detected within the range of the hyperparameters to form a cluster, and a minimum number of trips required to form a new cluster is defined.

11. The method for electronic journey familiarity detection (114) according to claim 7, characterized in that, Hyperparameter optimization is performed individually for each technology application, including different transportation modes and / or different geographical locations and / or driver-to-passenger journeys.

12. The method for electronic journey familiarity detection (114) according to any one of claims 1 to 5, characterized in that, The mobile device (10) is implemented as a mobile telecommunications device (10), and the one or more sensors (102) are integrated sensors (102) of the mobile telecommunications device (10).

13. The method for electronic journey familiarity detection (114) according to claim 12, characterized in that, The mobile telecommunications device (10) is a cellular mobile phone and / or a smartphone.

14. The method for electronic journey familiarity detection (114) according to any one of claims 1 to 5, characterized in that, The modes of transport that can be distinguished by the method include at least land-based vehicles and / or sea-based vehicles and / or air-based vehicles and / or hiking and / or skiing.

15. The method for electronic journey familiarity detection (114) according to claim 14, characterized in that, The land-based vehicles include at least distinguishable modes for automobiles and / or motorcycles and / or bicycles.

16. The method for electronic journey familiarity detection (114) according to any one of claims 1 to 5, characterized in that, The detection of the start point (11411) and end point (11412) of at least a portion of the time series (331, ..., 33t) of the measured sensor parameter values ​​includes selecting the earliest geographic coordinates for the start point of the journey and the latest geographic coordinates for the end point of the journey, said geographic coordinates including latitude and longitude.

17. The method for electronic journey familiarity detection (114) according to any one of claims 1 to 5, characterized in that, The detection of the start point (11411) and end point (11412) of at least a portion of the time series (331, ..., 33t) of the measured sensor parameter values ​​includes: the monitoring module and / or the application reporting the precise geographic coordinates if the start recording trigger is fired and when the stop recording trigger is fired.

Images