Method and system for rideshare detection

Abstract

To provide a computer-implemented method and a ride-sharing detection system for detecting ride-sharing by two or more occupants traveling in a sharing vehicle.SOLUTION: The method includes receiving data indicating that a first device associated with a first occupant and a second device associated with a second occupant are in physical proximity to each other, receiving first motion data from the first device, receiving second motion data from the second device, and comparing the first motion data and the second motion data to determine whether the first and second devices are traveling in the same vehicle.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a computer-implemented method for detecting two or more occupants traveling in a shared vehicle and a rideshare detection system. [Background technology]

[0002] Detecting ride-sharing occupants in shared vehicles can be used, for example, for reporting statistical surveys, managing ride-sharing lanes, or operating travel discount schemes to encourage environmentally friendly travel. However, existing techniques for ride-sharing detection can be inaccurate and inconvenient to use.

[0003] For example, some existing methods involve the use of location-based tracking of user devices, such as smartphones. However, such location-based techniques are subject to inaccuracies in determining the device's location and timing records. For example, when a user device is in a highly congested area, errors in estimated location can be significant, leading to false detection of user devices in nearby vehicles. Additionally, some existing systems use proximity detection by detecting communication signals, such as Bluetooth®, to detect nearby user devices in the same vehicle. However, these communication signals can also be detected between adjacent vehicles, potentially leading to false detection of devices in nearby vehicles. Furthermore, such rideshare detection systems typically require the collection of location or proximity data by the user device for the entire journey, which can consume system resources, such as device battery, device storage, mobile network bandwidth, server storage, and server computational resources. Summary of the Invention [Problem to be solved by the invention]

[0004] Therefore, a less resource intensive and more accurate method of rideshare detection is desired.The present invention has been devised with the above considerations in mind. [Means for solving the problem]

[0005] Broadly described, the present invention relates to a method for verifying whether two user devices are traveling in the same vehicle by analyzing motion data from each device. By comparing how each device moves, a determination can be made as to whether the devices are located in the same vehicle based on how similar the motion of each device is in both shape and time.

[0006] Accordingly, in a first aspect of the present invention, there is provided a computer-implemented method for detecting ridesharing by two or more passengers traveling in a shared vehicle, the method comprising receiving first motion data from a first device associated with a first passenger, receiving second motion data from a second device associated with a second passenger, and comparing the first motion data and the second motion data to determine whether the first and second devices are traveling in the same vehicle.

[0007] Advantageously, by comparing how the devices move, an accurate determination can be made as to whether the devices are in the same vehicle. The local behavior of each device, which is affected by vehicle type and travel path, is monitored. In this way, a more accurate determination can be made as to whether the devices are in the same vehicle compared to existing systems that may only monitor the distance between the devices and therefore may confuse two devices that are in close proximity but in different vehicles.

[0008] The computer-implemented method may include receiving data indicating that the first device and the second device are in physical proximity to each other. Thus, candidate rideshare devices may be identified before comparing the first and second operational data to verify whether the candidate devices are located in the same vehicle. For example, the computer-implemented method may include receiving data indicating a relative distance between the first device and the second device, and then determining from the received data that the first and second devices are in physical proximity to each other.

[0009] The first and / or second device may be a user device such as a smartphone or a computer, and in some examples, the first and / or second device may be a computing system of a shared vehicle.

[0010] A shared vehicle may be any suitable vehicle for transporting multiple passengers, such as a car, bus, motorcycle, or train.

[0011] The data indicating the physical proximity between the first and second devices may include estimated locations of the first and second devices. Therefore, the relative distance between the devices may be determined by calculating the distance between the estimated locations. In some examples, the data indicating the physical proximity may include proximity data indicating that the first device has detected the second device by receiving a communication signal from the second device. Therefore, the relative distance between the devices in this example may be indicated by the detection range of the first device. Accordingly, the received data indicating that the first and second devices are in physical proximity to each other may also be referred to herein as location data and / or proximity data. The first operational data, the second operational data, and the received data indicating that the first and second devices are in physical proximity to each other may be collectively referred to as sensor data.

[0012] In a further example, the method may include receiving an indication from a first device that the first device has reached a predetermined physical location and receiving an indication from a second device that the second device is at or near the same predetermined physical location. The devices may therefore be determined to be in proximity to one another. The predetermined physical location may correspond to a node in a feature map (described in more detail below).

[0013] Determining that the first and second devices are in physical proximity to one another based on the received data may include determining whether the first and second devices are within a predetermined distance threshold of one another. For example, when the received data includes estimated locations of the first and second devices, the method may include determining that the relative distance between the first and second devices is less than a predetermined distance threshold. The predetermined distance threshold may be a fixed value, such as 10 meters or 5 meters. In another example, the predetermined distance threshold may be based on the size of the shared vehicle. For example, for an automobile, the predetermined distance threshold may be 5 meters. In a further example, when the received data includes a proximity indication, the physical proximity may be the detection range of the first and / or second devices.

[0014] In some examples, the computer-implemented method may include using the received data to determine whether the first and second devices are traveling together, which may include determining whether the first and second devices are in physical proximity for a predetermined time and / or for multiple locations. In some examples, determining whether the first and second devices are traveling together may include determining whether an estimated location has changed over time while the relative distance between the first and second devices remains the same or is within a predetermined distance threshold (i.e., the devices have moved but remain in physical proximity to each other).

[0015] The first and second operational data may include time series of operational measurements indicative of acceleration of each device induced by vehicle motion. For example, the first and second operational data may include acceleration measurements recorded by operational sensors, such as an IMU (Inertial Measurement Unit) or accelerometer, located on or connected to each of the first and second devices. Accordingly, the operational data may be referred to herein as acceleration data, IMU data, force data, or vibration data.

[0016] The computer-implemented method of the first aspect may be performed by a remote server in communication with the first and / or second device, which may run an application configured to communicate with the remote server and activate or deactivate device sensors, such as motion sensors, Bluetooth modules, or GPS receivers, based on communications from the remote server.

[0017] Alternatively, the computer-implemented method of the first aspect may be performed by the first and / or second devices, for example, the first and / or second devices may operate an application configured to use the method of the first aspect to detect whether each device is traveling in the same vehicle as another device.

[0018] The received data indicating that the first and second devices are in physical proximity to one another may include first location data and / or first proximity data from the first device and second location data and / or second proximity data from the second device. The data from the second device may optionally be received via the first device. For example, a computer-implemented method may include receiving, from the first device, data indicating that the first and second devices are in physical proximity to one another, first operational data, and second operational data. Alternatively, the data from the second device may be received (directly) from the second device. In some examples, the first and second location data may include an indication that the first and second devices have reached predetermined physical locations corresponding to nodes in a feature map (described in more detail below).

[0019] Thus, when the computer-implemented method is performed by a remote server, the remote server may (in some examples only) be in communication with the first device. The second device may be in communication with the first device, for example, using Bluetooth. In other examples, the first and second devices may be configured to communicate separately with the remote server. Alternatively, when the computer-implemented method is performed by a first device, the second operational data and / or the second location data may be received at the first device from the second device (e.g., via Bluetooth). In this example, receiving the first operational data and / or the first location data may include receiving the data from a local memory of the first device.

[0020] As described above, the received data indicating that the first and second devices are in physical proximity to one another may include an indication that the first device has detected a signal from the second device. The signal may be a Bluetooth signal. Alternatively or additionally, the received data indicating that the first and second devices are in physical proximity to one another may include an estimated location of the first device and an estimated location of the second device. The first and second estimated locations may be GPS locations received from GPS receivers of the first and second devices.

[0021] Comparing the first and second motion data may include identifying motion characteristics in each of the first and second motion data and comparing the motion characteristics to determine whether the devices share the same travel route and / or the same vehicle type and / or the same vehicle. For example, comparing the first and second motion data may include identifying vibration patterns in the first and second motion data and comparing the vibration patterns to determine whether the devices share the same travel route and / or the same vehicle type. Further, the vibration patterns may be compared to determine whether the first and second devices are traveling in the same vehicle.

[0022] For example, comparing the first motion data and the second motion data may include identifying a vibration pattern in the first motion data and identifying the same vibration pattern in the second motion data. Identifying the vibration pattern may include extracting a portion of the first motion data. A corresponding portion of the second motion data may then be extracted within the same time period. The motion data portions may then be compared to calculate a similarity score between each portion of the motion data. If the similarity score exceeds a predetermined threshold, the portions may be considered to contain the same vibration pattern. Alternatively, if the similarity score is below a predetermined threshold, the vibration patterns of each portion may be determined to be different. If an identical vibration pattern cannot be found in the second motion data, the method may include determining that the devices are traveling in different vehicles (i.e., the owners of these devices are not engaged in ride sharing).

[0023] In some examples, identifying the vibration pattern may include extracting vibration features by performing peak detection or by analyzing the motion data to find known vibration patterns. The method may then include comparing the identified vibration pattern from the first motion data with the second motion data, for example, using a convolutional neural network (CNN), to classify or identify portions of the second motion data that contain the same vibration pattern. When the same vibration pattern is identified in the second motion data, it may be inferred that the first and second devices are in vehicles with the same motion characteristics (e.g., due to vehicle suspension, vehicle size, or make and model) and are traveling the same motion path (e.g., so that the first and second motion data exhibit the same characteristics indicative of the motion path, such as a bump or traffic light).

[0024] The computer-implemented method may then include calculating a time difference between the vibration patterns identified in the first and second motion data. When the time difference is below a time difference threshold, the first and second devices may be determined to be traveling in the same vehicle. Alternatively, if the same vibration pattern is identified in the second motion data but after the time difference threshold has passed, the first and second devices may be determined to be in different vehicles but still traveling the same travel route in similar vehicle types. The time difference threshold may be a predetermined threshold. In some examples, the time difference threshold may be determined according to the mode of travel (e.g., vehicle type of a shared vehicle).

[0025] In some examples, the computer-implemented method may include using operational data from the first and second devices to determine a vehicle type in which the first and second devices are traveling. The time difference threshold may then depend on the determined vehicle type. The operational data for determining the vehicle type may be any operational data from the first and second devices (recorded on the same journey), including, in some examples, the first and second operational data used to verify ridesharing. If the first and second devices are determined to be traveling in different vehicle types, the method may include determining that the first and second devices are not traveling in the same vehicle (e.g., generating a negative ridesharing indication signal).

[0026] In some examples, the computer-implemented method may include activating the first and second devices to record first and second motion data for a predetermined period of time. In this manner, battery and other resource consumption may be reduced because motion data need not be recorded for the entire journey. This concept may also be applied to detecting, recording, and transmitting location and / or proximity data. For example, the computer-implemented method may include activating the first and / or second devices to record proximity and / or location data for a predetermined period of time.

[0027] Thus, the computer-implemented method may include generating timing information and providing the timing information to the first and second devices, the timing information configured to cause sensors of the first and second devices to initiate measuring and recording of the first and second motion data over a predetermined period of time. Generating the timing information may include determining a physical location of the first and / or second devices (e.g., from the received data) and comparing the physical location to a location in the feature map to determine whether the physical location corresponds to one of a plurality of vibration feature points identified in the feature map.

[0028] The signature map may be a database of vibration signatures associated with each location. Each of the plurality of vibration signatures may indicate a location associated with a previously detected vibration pattern. For example, the vibration signatures may include locations associated with road bumps or traffic lights where a prominent vibration pattern has been observed. When the physical location corresponds to one of the plurality of vibration signatures (e.g., when the first and / or second device is determined to have reached the vibration signature), the computer-implemented method may include generating timing information (or a trigger signal) and providing the timing information (or trigger signal) to the first and / or second device. Thus, the device sensors may be activated at a time when they are likely to record operational data useful for verifying whether the devices are in the same vehicle, and deactivated when less useful operational data is expected. Thus, the first and second operational data are likely to include a distinguishable vibration pattern, eliminating the need to record operational data for the entire journey.

[0029] The timing information may include a time delay for when the motion sensor should be activated. Thus, generating the timing information may include receiving a current physical location of the first and / or second device, identifying a node of a vibration signature map corresponding to the current physical location, and determining one or more predicted future nodes of the vibration signature map for the first and / or second device. The one or more predicted future nodes may correspond to an estimated future location of the first and / or second device predicted based on the current physical location. Thus, when the one or more predicted future nodes include a vibration signature point, the computer-implemented method may include generating timing information, the timing information configured to cause activation of the motion sensor at a time when the first and / or second device is predicted to reach one of the estimated future locations.

[0030] In some examples, the signature map may be a database that stores copies of known vibration profiles associated with each location. The computer-implemented method may then include comparing the motion data with one or more of the known vibration profiles to verify the physical location of the first and / or second devices.

[0031] The computer-implemented method may further include detecting a significant vibration pattern in the first and / or second motion data and updating the vibration signature map based on the detected vibration pattern. For example, a significant vibration pattern may be a portion of the motion data where one or more peaks in the data exceed a predetermined threshold or where new frequency components appear in the motion data. This portion of the motion data and the device's location at the time the significant vibration pattern was detected may then be recorded and stored as a new node in the vibration signature map.

[0032] The computer-implemented method may be for determining whether multiple occupants are sharing a ride in a shared vehicle. The multiple occupants may include three or more occupants. For example, the computer-implemented method may include receiving data indicating that one or more additional devices are in physical proximity with the first and / or second devices. For example, location data indicating respective locations of the one or more additional devices may be received, and / or proximity data indicating that the one or more additional devices have been detected by the first device may be received. The computer-implemented method may further include receiving additional operational data from the one or more additional devices and comparing the additional operational data with the first and / or second operational data to determine whether the one or more additional devices are traveling in the same vehicle as the first and / or second devices. The additional operational data may be compared with the first and / or second operational data using any of the techniques for comparing the first and second operational data discussed herein.

[0033] When the first and second devices are determined to be in the same vehicle, the computer-implemented method may include generating a rideshare indication signal. The rideshare indication signal may be provided to, for example, the first and / or second devices, an access control system, a parking management system, a rideshare lane management system, a discount management system, etc. For example, the access control system may be configured to grant a vehicle access to a parking lot if the occupant of the vehicle is determined to be engaging in a rideshare. In a further example, the rideshare lane management system may be configured to activate CCTV cameras or automatic signage, for example, depending on whether the occupant of a vehicle in a rideshare lane is determined to be engaging in a rideshare.

[0034] In a second aspect of the present invention, a computer-implemented method for verifying ridesharing by two or more occupants of a shared vehicle is provided, the method comprising: recording, by a first device associated with one of the occupants, data indicating that the first device and a second device associated with a second occupant are in physical proximity to one another; recording, by the first device, operation of the first device using a sensor to generate first operation data; and providing the data indicating that the first and second devices are in physical proximity to one another and the operation data to a rideshare detection system, the rideshare detection system being configured to determine whether the first and second devices are traveling together in the same vehicle using the method of the first aspect.

[0035] For example, the computer-implemented method of the second aspect may be performed by a first device running an application for verifying that a user of the first device is sharing a vehicle with another person. The rideshare detection system may be a module running on the first device or a remote server configured to perform the computer-implemented method of the first aspect. Thus, the computer-implemented method of the second aspect may include any of the steps of the first aspect that may be performed by the remote server and / or the first device.

[0036] Accordingly, in a third aspect of the present invention, there is provided a computer-implemented method for detecting ridesharing between two or more passengers traveling in a shared vehicle, the method including: collecting, by a first device associated with one of the passengers, data indicating that the first device and a second device associated with a second passenger are in physical proximity to one another; measuring, by the first device, motion of the first device using an IMU sensor to generate first motion data; and transmitting, by the first device, the data indicating that the first and second devices are in physical proximity to one another and the motion data to a rideshare detection server. The computer-implemented method further includes receiving, by the rideshare detection server, the first motion data from the first device, the data indicating that the first and second devices are in physical proximity to one another, and second motion data from the second device (optionally transmitted via the first device); and comparing, by the rideshare detection server, the first motion data and the second motion data to verify whether the first and second devices are traveling in the same vehicle.

[0037] In a fourth aspect of the present invention, there is provided a rideshare detection system configured to implement the computer-implemented method of the first aspect. For example, a rideshare detection system for detecting a rideshare by two or more passengers traveling in a shared vehicle may include a data collection module configured to receive data indicating that a first device associated with a first passenger and a second device associated with a second passenger are in physical proximity to one another, first motion data from the first device, and second motion data from the second device, a proximity detection module configured to determine from the received data whether the first and second devices are traveling together, and a rideshare verification module configured to compare the first motion data and the second motion data to determine whether the first and second devices are traveling together in the same vehicle.

[0038] The system further includes a first device configured to record first motion data using a sensor that detects motion of the first device, optionally receive second motion data from the second device, and provide the first motion data to the data collection module. The data collection module, proximity detection module, and rideshare verification module may be located on a remote rideshare detection server in communication with the first and / or second devices.

[0039] An additional aspect of the present invention may relate to a system configured to perform the computer-implemented method of any one of the first, second and third aspects of the present invention. In particular, the system may comprise one or more processors configured to perform the computer-implemented method of each of the first, second and third aspects of the present invention.

[0040] An additional aspect of the present invention may provide a computer program comprising instructions which, when executed by a computer, cause the computer to perform the steps of the computer-implemented method of any one of the first, second and third aspects of the present invention. A further aspect of the present invention may provide a computer-readable storage medium having stored thereon the computer program of the preceding aspect of the present invention.

[0041] The present invention includes combinations of the described embodiments and preferred features, but excludes cases where such combinations are clearly unacceptable or clearly avoided.

[0042] BRIEF DESCRIPTION OF THE DRAWINGS Embodiments and experiments illustrating the principles of the invention will now be discussed with reference to the accompanying drawings. [Brief explanation of the drawings]

[0043] [Figure 1] 1 illustrates a flow diagram of a computer-implemented method according to an aspect of the present invention for determining whether an occupant is traveling in a shared vehicle. [Figure 2] 1 illustrates a system for implementing a rideshare detection method according to an aspect of the present invention. [Figure 3] 1 illustrates another diagram of a system for implementing a rideshare detection method according to an aspect of the present invention. [Figure 4A] 1 shows an example of vibration data from a vehicle traveling over a bump. [Figure 4B] 1 shows an example of vibration data from a vehicle traveling over a bump. [Figure 5] 1 illustrates an exemplary vibration feature map. [Figure 6] 1 illustrates a flow diagram of a method for determining whether an occupant is traveling in a shared vehicle. [Figure 7] 1 shows a flow diagram of a method for determining timing information using a vibration feature map. [Figure 8] 1 shows a flow diagram of a method for generating a vibration feature map. [Figure 9] 10 is a table illustrating example input data received from a user device by a rideshare detection server. [Figure 10] 10 is a table showing an example of timing control data for activating a sensor of a device. [Figure 11] 1 is a table illustrating exemplary timing threshold data for determining whether two devices are in the same vehicle. [Figure 12] 10 is a table illustrating exemplary output data from a rideshare detection server. DETAILED DESCRIPTION OF THE INVENTION

[0044] Aspects and embodiments of the present invention will now be discussed with reference to the accompanying drawings, in which: Further aspects and embodiments will be apparent to those skilled in the art.

[0045] FIG. 1 illustrates a method for determining whether a passenger is traveling in a shared vehicle. For example, the method may be implemented by a remote server in communication with user devices, such as smartphones, associated with the passengers. The user devices are configured to communicate with the remote server via the Internet. At least one of the devices may operate an application configured to transmit sensor data to the remote server and receive commands from the server to activate or deactivate sensors. However, in some examples, some or all of the method may be implemented locally on one of the user devices.

[0046] In step S100, the remote server receives data indicating that the first and second user devices are in proximity to one another. For example, the server may receive a first GPS location from the first device and a second GPS location from the second device, with the relative distance between the devices therefore indicated by the distance between the first and second GPS locations. Additionally, one of the devices may detect a PAN (Personal Area Network) signal from another device, such as a Bluetooth advertising signal, indicating that another device is nearby. In this example, proximity data indicating that a signal has been detected is transmitted to the remote server. In another example, the received data may indicate that both the first and second user devices have been detected at or near a predetermined location (e.g., corresponding to a node in a feature map described below).

[0047] In step S102, the remote server determines whether the first and second devices are traveling together by determining whether the first and second GPS locations of the user devices are moving together and / or whether the devices remain within detection range of each other. If the first and second devices are determined to be traveling together or at least in physical proximity to each other, the server proceeds to step S104 to verify whether the first and second devices are traveling in a shared vehicle.

[0048] In step S104, the remote server receives first motion data from the first user device and second motion data from the second user device. The motion data is time series data that indicates, at least in part, the motion experienced by the device due to the motion of the vehicle in which the device is traveling, as measured, for example, by an integrated IMU sensor in each device. Comparing the motion data allows the server to determine whether the devices are in the same vehicle or simply in nearby vehicles.

[0049] Thus, in step S106, the remote server compares the first and second motion data. As discussed in more detail below, this step includes identifying vibration patterns in the first and second motion data by calculating a similarity score between the first and second motion data. If the similarity score exceeds a threshold similarity, the method includes determining a time difference between the vibrations experienced by the first and second devices.

[0050] In step S108, the remote server determines whether the first and second devices are traveling in the same vehicle by determining whether both devices experience the same vibration pattern and whether the time difference between the vibrations experienced by each device is below a threshold. If the devices are determined to be in the same vehicle, the server may send a confirmation signal to the first and / or second devices, to an access control gate, or to a rideshare discount scheme, for example.

[0051] In each of the above steps, each of the user devices may communicate with the remote server to provide location data, proximity data, and operation data. However, in some examples, the remote server may communicate with only one of the user devices. The location and operation data from the other user devices may then be received (e.g., via Bluetooth) by the first user device, which forwards the data to the remote server. In this way, only one device needs to be in communication with the remote server to determine whether a passenger is participating in a rideshare.

[0052] FIG. 2 illustrates an exemplary system for implementing the rideshare detection method described above.

[0053] The system includes a monitoring server 100 (which may also be referred to herein as a rideshare detection server) configured to send commands to and receive sensor data from user devices 200a-200n via the Internet to determine whether the user devices are traveling in a shared vehicle, such as a car or bus. In this example, three user devices 200a-200n are shown. However, any number of user devices 200a-200n may be connected to the monitoring server 100 to determine whether the user devices 200a-200n are traveling in a shared vehicle.

[0054] Each user device 200a-200n is equipped with multiple sensors, including a Bluetooth module 202, a GPS receiver 204, and an accelerometer 206. These sensors are used to collect time-series sensor data during the journey. The sensor data is transmitted to the monitoring server 100 via the Internet.

[0055] The monitoring server 100 includes a data collection module 102 configured to receive sensor data from the user devices 200a-200n, a proximity detection module 104 configured to determine from the received data which of the user devices 200a-200n are traveling together by analyzing Bluetooth signals received by each device and / or by comparing the GPS locations of each device, and a rideshare detection module 106 configured to determine whether the user devices 200a-200n are traveling in the same vehicle by comparing vibration data from the accelerometers 106 (e.g., using a vibration data comparison function 108). The rideshare detection module 106 also includes a travel mode detection function 110 for determining the vehicle type in which the devices 200a-200n are traveling, a timing control function 112 for generating timing data for selectively activating and deactivating device sensors according to a vibration signature map, and a feature map update function 114 for updating the vibration signature map. These functions are described in more detail below with respect to FIGS. 3-9.

[0056] FIG. 3 shows a more detailed diagram of a system for implementing the rideshare detection method. In this example, two passengers (Passenger A and Passenger B) each have a user device: a first device 200a—"Smartphone A"—and a second device 200b—"Smartphone B." As discussed above with respect to FIG. 2, each device 200a-b includes a Bluetooth module 202 for collecting proximity data 11 indicative of nearby devices detected by each device 200a-b, a GPS receiver 204 for generating location data 12 including an estimated location of each device 200a-b, and an accelerometer 206 for measuring motion data, referred to in FIG. 3 as vibration data 13. The proximity data 11, location data 12, and vibration data 13 are transmitted by a data controller 208 over the Internet to the data collection module 102 of the monitoring server 100.

[0057] The monitoring server 100 is configured to use the proximity data 11 and location data 12 to determine which user devices are in physical proximity to one another. User devices 200a-b that are determined to be near one another are grouped as candidate devices that may travel in a shared vehicle. Alternatively, if the proximity data or GPS location data 12 indicates that the devices 200a-b are too far apart to travel together—for example, if the relative distance between the devices 200a-b is determined to be greater than a predetermined threshold, or if Bluetooth proximity detection is sporadic—the devices 200a-b are determined to be in different vehicles, and a negative detection result 17 is generated by the rideshare detection function 116.

[0058] Next, the monitoring server 100 is configured to compare the vibration data 13 from each device 200a-200b in the candidate group to verify whether they are traveling in the same vehicle (see, e.g., vibration comparison 108). To do this, the vibration data 13 from each device 200a-b is analyzed to identify a vibration pattern in the data 13. If a particular vibration pattern is identified in the vibration data 13 from both devices 200a-b, the time difference between the vibration patterns (referred to as "timing deviation" 15 in FIG. 3) is calculated. If the calculated time difference 15 is less than a time difference threshold, the devices 200a-b are determined to be traveling in the same vehicle, and a positive detection result 17 is generated by the rideshare detection function 116. However, if the time difference 15 is too large (i.e., greater than the time difference threshold) or no common vibration pattern is identified, the devices 200a-b are determined to be traveling in different vehicles, and a negative detection result 17 is generated.

[0059] To aid in rideshare detection, the monitoring server 100 is configured to implement a travel mode detection function 110 to determine a travel mode 14 in which the first and second devices are traveling based on the vibration data 13. For example, the travel mode 14 may be walking, car, motorcycle, bus, or train. The determined travel mode 14 is then used to adjust a time difference threshold for comparing the vibration data 13. For example, the determined travel mode 14 may be used to retrieve (e.g., from memory) a time difference threshold that depends on the vehicle type indicated by the travel mode 14. The time difference threshold is determined based on the size or length of the vehicle indicated by the travel mode, such that large vehicles, such as buses and trains, are assigned a long time difference threshold and small vehicles, such as cars and motorcycles, are assigned a short time difference threshold. If the determined travel modes 14 for each device 200a-b in the candidate group are different, the devices 200a-b may be determined to be in different vehicles, and a negative detection result 17 is generated by the rideshare detection function 116. Additionally, if the determined travel mode 14 for one or more of the user devices is walking (or some other travel mode that is not the target ridesharing travel mode), the monitoring server is configured to generate a negative detection result 17 because ridesharing is not possible for the devices in this scenario.

[0060] The travel mode 14 is determined using a trained machine learning model, such as a convolutional neural network (CNN), to classify the travel mode 14 based on the vibration data 13 from each device 200a-c. However, in other examples, the travel mode 14 may be a variable set in a system setup procedure, or the travel mode may be received from the first and / or second devices 200a-b. For example, a user of an application running on one of the devices 200a-b may input which travel mode 14 they are using.

[0061] Additionally, the monitoring server 100 is configured to broadcast timing information 19 to the user devices, which is configured to activate and deactivate the sensors of the user devices at times specified in the timing information 19. In this way, the sensors do not need to record data for the entire journey, thereby optimizing resource consumption, such as battery life. The timing information 19 is determined by comparing the current location of the user devices with nodes in the vibration feature map 16. Each node in the vibration feature map 16 is a vibration feature point associated with a physical location. When the location data 12 indicates that a given user device is approaching a vibration feature point in the feature map 16, the wake-up timing data 19 is calculated and transmitted to each user device, thereby activating the accelerometer 206 for a predetermined period of time. Each vibration feature point corresponds to a known location where a distinguishable vibration feature was observed. The generation of the wake-up timing data 19 and the vibration feature map 16 is discussed in more detail below with respect to FIGS. 5-7.

[0062] 3, the location data 12 and vibration data 13 are also used to update the vibration feature map 16 to include newly detected vibration feature points detected by the user devices 200a-b (see map update function 114). By updating the vibration feature map 16 in this manner, the vibration feature map 16 can become more detailed over time and adapt to changing route conditions and vehicle types.

[0063] The ride-sharing detection result 17 may be used in a variety of applications. For example, in FIG. 3 , the detection result 17 is provided to a cost server 300, which performs a discount calculation 118 to generate a discounted estimated cost 20 depending on whether the user is determined to be ride-sharing. The discount estimate 20 is provided to the user device 200a-b as feedback 210 to the user. For example, this application may be used when an employer encourages employees to use ride-sharing to promote carbon dioxide reduction during their commute or to reduce parking congestion.

[0064] Additionally, the detection result 17 of Figure 3 may be provided to the access control server 400, which opens the access control gate 120 in response to the detection result 17. For example, the access control gate may be configured to allow access to parking lots or lanes specially provided for ride-sharing users to promote environmentally friendly travel.

[0065] 4A illustrates an exemplary situation in which two occupants, users A and B, are sharing a ride in a shared vehicle and a third occupant, user C, is in a single-occupant vehicle. Both vehicles are adjacent to each other, and therefore, it is difficult to detect using GPS location or Bluetooth detection alone whether all three users are using individual vehicles or whether some are sharing the vehicle. Thus, by analyzing motion data from the devices using methods such as those discussed herein, differences in vehicle dynamics (e.g., due to suspension type) and time differences in encountering vibration features (such as the bump shown in FIG. 4A) can be detected to determine which occupants are sharing the vehicle.

[0066] FIG. 4B shows exemplary vibration data and timing control information for the situation shown in FIG. 4A.

[0067] In this example, similar vibration patterns are detected for all three users when the vehicle encounters the bump shown in Figure 4A. However, as shown in the vibration plot, the vibration patterns are observed at or near the same time for users A and B, while the same pattern is seen later for user C. Therefore, by measuring the time difference when the vibration pattern is observed by each device, the system can detect whether the users are in the same vehicle.

[0068] Additionally, as discussed above, timing control is introduced. Collecting acceleration data for the entire journey can be resource intensive (e.g., battery and network intensive). Therefore, as shown in the bottom of Figure 4B, the times at which motion sensors (e.g., accelerometers) are activated on each user device are controlled so that vibration data is collected only when the vehicle passes over vibration features, such as the bumps shown in Figure 4A.

[0069] These vibration signature points are predicted using the vibration signature map as described above. An exemplary vibration signature map is shown in FIG. 5. The vibration signature map is a graph containing geographic nodes and directional edges. Each node corresponds to a location, a travel mode (e.g., vehicle type), and optionally, a stored vibration pattern. The directional edges connect the nodes so that user devices moving between nodes can be tracked based on detected GPS location data. For each device, the current GPS location and, optionally, the detected travel mode can be used to calculate a predicted time at which the device is expected to arrive at a location with an associated stored vibration pattern in the vibration signature map. Nodes in the signature map that have an associated stored vibration pattern are referred to herein as vibration signature points. The predicted time is then used to determine a wake-up time for broadcasting to user devices to activate their sensors and record vibration data at the vibration signature points. When a node does not have a stored vibration pattern, this may simply indicate that devices expected to arrive there at a similar time should activate their sensors so that nearby devices capture temporally overlapping data.

[0070] In some examples, the vibration signature map may include copies of observed vibration patterns determined from historical vibration data. Thus, the method may include comparing vibration data from the user devices with stored vibration patterns to verify the current location of each user device.

[0071] FIG. 6 illustrates a flow diagram of a method for using a detected travel mode to determine whether an occupant is traveling in a shared vehicle.

[0072] First, in step S200, a travel mode is detected for each user device individually (e.g., by using motion data recorded using the device accelerometer or another method discussed above). Next, in step S202, the Bluetooth proximity data, location data, and detected travel mode are used to divide all available user devices into groups of devices that have a common travel mode and are in physical proximity to each other. Thus, the user devices in each group are rideshare candidate devices that may be traveling in a shared vehicle.

[0073] Next, in steps S204a-S204c, for each candidate group, the motion data from each user device is compared to identify a vibration pattern. If identical vibration patterns are identified in the motion data from multiple devices in the candidate group, the time difference between the identified vibration patterns is calculated to identify which devices saw the vibration patterns at or near the same time. To do this, the time difference is compared to a threshold time difference, which, as discussed above, depends on the detected mode of movement. Additionally, a similarity score is calculated that indicates how similar the vibration patterns recorded on the different devices are.

[0074] In step S206, it is determined whether the devices are in the same vehicle based on the similarity score and the time difference. For example, if the similarity score is high (e.g., above a predetermined confidence threshold) and the time difference is small (e.g., below a time difference threshold), it is determined that the devices are traveling in the same vehicle. However, if the vibration patterns are not similar enough or the time difference is too large, it is determined that the devices are in different vehicles.

[0075] Additionally, a confidence value is determined for each detection result. In this example, if the confidence value exceeds a threshold, the process ends. However, if the confidence value is below the threshold, the process proceeds to step S208, where timing control information is generated and broadcast to the user device to restart the sensor, record another vibration pattern, and repeat the process until a confidence score above the threshold is obtained. The confidence value may be defined as the absolute difference between the similarity score and the threshold. For example, the similarity score may range from 0.0 to 1.0, and the threshold may be 0.8. In the first case, if the similarity score is 0.95, the difference is 0.15. In the second case, the similarity score may be 0.4, so the difference is 0.4. Both of these examples correspond to high confidence values, one positive and one negative. In another case, if the similarity score is 0.75, the difference is 0.05. Here, the confidence value is low, so to achieve a higher confidence value, the timing control may need to be changed to obtain more data.

[0076] 7 shows a flow chart of a method for determining timing information for activating a device sensor using a vibration feature map. First, in step S300, the current location of the user device is determined from the location data, and the node closest to the current location is determined in the vibration feature map. In some examples, the determined travel mode (e.g., bus, train, or automobile) is used to determine the closest node corresponding to this travel mode. For example, vibration feature points in the vibration feature map may be registered for a train rather than for an automobile.

[0077] Next, in steps S302-S304, for each nearest node associated with a corresponding vibration pattern, the arrival time of the device at this node is calculated. The arrival time is used to generate timing information for activating the user device's motion sensor. For example, if a device determined to be traveling by bus is predicted to reach a bump in a bus lane within 30 seconds, the timing information is configured to activate the motion sensor for 20 seconds within the 30-second period to record the user device's motion as the bus travels over the bump.

[0078] When timing information is generated for each candidate node, steps S302-S304 are repeated for each candidate node in the vibration feature map corresponding to the closest vibration feature point, up to step S306. In step S306, it is determined whether a search limit has been reached. This search limit represents how far nodes from the current node should be searched. It is selected based on several factors. If the limit is a large number, nodes farther from the current node may be searched to provide longer timing information. However, this incurs additional computational cost and may introduce errors into the resulting timing information, making it less relevant if nodes are searched too far.

[0079] Finally, in step S308, the calculated timing information is sent to each of the devices in the candidate group (a candidate group being devices determined to be near each other) so that the motion sensors of these devices are activated simultaneously or at least partially overlapping.

[0080] 8 shows a flow diagram of a method for generating a vibration feature map. The vibration feature map may be generated manually, for example, using known data for a geographic region. However, the feature map may also be generated and / or updated automatically using recorded location and vibration data from the user device.

[0081] First, in step S400, vibration data histories from multiple devices are grouped by the device's location and travel mode at the time the data was recorded. Next, in steps S402-S408, the vibration data for each group is divided into windows (e.g., 60 seconds long), and the windows are analyzed to identify whether they contain similar vibration patterns. If a vibration pattern is identified in some vibration data examples for this group, in step S408, a new node is added to the feature map for the location and travel mode associated with this group. Vibration patterns can be identified by applying clustering techniques. For example, in a first step, the vibration history can be sampled over a specific window (e.g., 1 second), and some features, such as a spectral pattern, can be calculated for each sample. Next, the samples can be clustered using some clustering technique (e.g., k-means) using these features. The results can primarily contain large, indistinguishable clusters reflecting vibration patterns from flat sections of the road, but can occasionally contain small, distinct clusters reflecting distinctive parts of the road, such as bumps (see FIGS. 4A and 4B). If the samples of a cluster are from the same location, they are considered to be a significant vibration pattern and can therefore be added to the feature map.

[0082] Figure 9 is a table showing example input data from a user's smartphone to the rideshare detection server. The input data consists of the user ID, the time when the sensor data (e.g., motion, proximity, and location data) was observed, and the sensor data itself (e.g., motion, location, and proximity data).

[0083] 10 is a table showing an example of timing control data for activating device sensors. The timing control data broadcast by the server to the user devices consists of a target user ID, a time, and an operation that specifies when to activate or deactivate each of the device sensors, such as the accelerometer, GPS receiver, and Bluetooth module.

[0084] 11 is a table showing exemplary timing threshold data for determining whether two devices are in the same vehicle. The timing threshold data consists of a travel mode and a timing threshold that applies to that travel mode.

[0085] Finally, Figure 12 is a table showing exemplary output data from the rideshare detection server. The output data consists of an assigned share ID, user ID, start time, and end time. User devices determined to be ridesharing in the same vehicle are assigned the same share ID. The "start time" and "end time" values ​​are the times when the rideshare is determined to have started and ended, respectively.

[0086] The features disclosed in the foregoing description, or in the following claims, or in the accompanying drawings, and expressed in terms of specific forms or means for carrying out a disclosed function, or methods or processes for obtaining a disclosed result, may be used separately or in any combination of such features as appropriate to realize the invention in its various forms.

[0087] While the present invention has been described in conjunction with the exemplary embodiments set forth above, many equivalent modifications and variations will be apparent to those skilled in the art given this disclosure. Accordingly, the exemplary embodiments of the invention set forth above are considered to be illustrative and not limiting. Various changes can be made to the described embodiments without departing from the spirit and scope of the invention.

[0088] For the avoidance of doubt, any theoretical explanations presented herein are presented for the purpose of enhancing the understanding of the reader, and the inventors do not wish to be bound by any of these theoretical explanations.

[0089] The section headings used herein are for organizational purposes only and should not be construed as limiting the subject matter described.

[0090] Throughout this specification, including the claims which follow, unless the context requires otherwise, the words "comprise" and "include", and variations such as "comprises", "comprising" and "including", will be understood to imply the inclusion of a stated integer, step or group of integers or steps, but not the exclusion of any other integer, step or group of integers or steps.

[0091] As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. As used herein, ranges may be expressed "about" one particular value and / or to "about" another particular value. When such a range is expressed, another embodiment includes from the one particular value and / or to the other particular value. Similarly, when values ​​are expressed as approximations, it will be understood that the particular value forms another embodiment by use of "about." The use of "about" in reference to numerical values ​​is arbitrary and means, for example, + / - 10%. [Explanation of symbols]

[0092] 11 Proximity Data 12 Location Data 13 Vibration data 14 Movement Mode 15 Timing deviation 16 Feature Maps 17 Detection Results 18 Startup Timing 19 Startup Timing 20 Estimated Costs 100 monitoring servers 102 Data Collection Module 104 Proximity Detection Module 106 Rideshare Detection Module 108 Vibration data comparison function 110 Movement mode detection function 112 Timing control function 114 Feature map update function 116 Rideshare detection function 118 Discount Calculation 120 Gate Control 200a, 200b, 200n User Devices 202 Bluetooth module 204 GPS receiver 206 Accelerometer 208 Data Controller 210 Feedback 300 Expense Server 400 Access Control Server

Claims

1. 1. A computer-implemented method for detecting rideshares of two or more occupants traveling in a shared vehicle, comprising: receiving data indicating that a first device associated with a first occupant and a second device associated with a second occupant are in physical proximity to one another; receiving first operational data from the first device; receiving second operational data from the second device; comparing the first motion data with the second motion data to verify whether the first and second devices are traveling in the same vehicle; A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the received data includes an indication that the first device detected a signal from the second device.

3. the received data includes a location estimate of the first device and a location estimate of the second device; determining that the first and second devices are in physical proximity to one another includes comparing the position estimates to determine a relative distance between the first and second devices. The computer-implemented method of claim 2 .

4. The computer-implemented method of claim 3 , wherein the first and second motion data include acceleration measurements recorded by IMU sensors of the first and second devices.

5. The comparison of the first motion data and the second motion data includes: identifying a vibration pattern of the first and second motion data; comparing the vibration patterns to determine if the devices share the same travel path and / or the same vehicle type; The computer-implemented method of claim 4 , comprising:

6. The comparison of the first motion data and the second motion data includes: identifying a vibration pattern in the first accelerometer data; identifying identical or corresponding vibration patterns in the second accelerometer data; calculating a time difference between the vibration patterns identified in the first and second motion data; determining that the first and second devices are traveling in the same vehicle when the time difference is less than a time difference threshold; The computer-implemented method of claim 5 , comprising:

7. 7. The computer-implemented method of claim 6, wherein the method further comprises using operational data from the first and second devices to determine a vehicle type in which the first and second devices are traveling, and wherein the time difference threshold is dependent on the determined vehicle type.

8. 8. The computer-implemented method of claim 7, further comprising generating timing information and providing the timing information to the first and second devices, the timing information configured to instruct the first and second devices to begin recording the first and second motion data during a predetermined time using one or more respective sensors.

9. generating the timing information determining a physical location estimate of the first and / or second device from the received data; comparing the physical location estimate to a vibration signature map to determine whether the physical location estimate corresponds to one of a plurality of vibration signature points identified in the vibration signature map; generating the timing information when the physical location corresponds to one of the plurality of vibration feature points; It encompasses each of the plurality of vibration feature points indicates a position associated with a previously detected vibration pattern; 9. The computer-implemented method of claim 8.

10. receiving data indicating that one or more additional devices are in physical proximity to the first and / or second device; receiving additional operational data from the one or more additional devices; comparing the additional operational data with the first and / or second operational data to determine whether the one or more additional devices are traveling in the same vehicle as the first and / or second devices; 10. The computer-implemented method of claim 9, comprising:

11. When it is determined that the first and second devices are in the same vehicle, the computer-implemented method further comprises: generating a positive rideshare indication signal; providing the positive rideshare indication signal to an access control system; The computer-implemented method of claim 10, comprising:

12. 1. A computer-implemented method for verifying ride sharing by two or more occupants of a shared vehicle, comprising: recording, by a first device associated with one of the occupants, data indicating that the first device and a second device associated with a second of the occupants are in physical proximity to one another; recording, by the first device, a motion of the first device using a sensor to generate first motion data; providing the data indicating that the first and second devices are in physical proximity to one another and the operational data to a rideshare detection system, the rideshare detection system being configured to determine whether the first and second devices are traveling together in the same vehicle according to the method of any preceding claim; A computer-implemented method comprising:

13. detecting, by the first device, a signal from the second device, wherein the data indicating that the first and second devices are in physical proximity to one another includes an indication that the second device has been detected; receiving, by the first device, second operational data from the second device; providing the second motion data to the rideshare detection system; and The computer-implemented method of claim 12 further comprising:

14. 1. A rideshare detection system for detecting a rideshare by two or more occupants traveling in a shared vehicle, comprising: a data collection module configured to receive data indicating that a first device associated with a first occupant and a second device associated with a second occupant are in physical proximity to one another, first operational data from the first device, and second operational data from the second device; a proximity detection module configured to determine from the received data whether the first and second devices are moving together; a rideshare verification module configured to compare the first motion data with the second motion data to determine whether the first and second devices are traveling together in the same vehicle; A rideshare detection system comprising:

15. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the computer-implemented method of any one of claims 1 to 13.

Images