US9489644B2 - Vehicle drive matching system and method - Google Patents
Vehicle drive matching system and method Download PDFInfo
- Publication number
- US9489644B2 US9489644B2 US13/402,963 US201213402963A US9489644B2 US 9489644 B2 US9489644 B2 US 9489644B2 US 201213402963 A US201213402963 A US 201213402963A US 9489644 B2 US9489644 B2 US 9489644B2
- Authority
- US
- United States
- Prior art keywords
- vehicle
- user
- routes
- drive data
- another vehicle
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
- 238000000034 method Methods 0.000 title claims description 17
- 230000000977 initiatory effect Effects 0.000 claims 1
- 238000004422 calculation algorithm Methods 0.000 description 21
- 238000004891 communication Methods 0.000 description 7
- 239000011159 matrix material Substances 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000005303 weighing Methods 0.000 description 4
- 230000002354 daily effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003203 everyday effect Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
- G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/30—Transportation; Communications
-
- G06Q50/40—
Definitions
- This disclosure relates to systems and methods for finding carpool partners.
- a method for drive profile matching includes receiving, by a processing device, a plurality of drive histories associated with a plurality of vehicles. Each of the drive histories identifies one of the vehicles and a plurality of routes traversed by the one of the vehicles. Each of the routes has associated departure and arrival times. The method further includes generating data values representing a similarity between at least two of the routes each traversed by a different one of the vehicles based on a path defined by each of the routes and the associated departure and arrival times, identifying at least two or more of the vehicles based on the generated data values, and providing output about the identified vehicles to facilitate ride sharing among drivers of the identified vehicles.
- FIG. 1 is a schematic diagram detailing an example computer network and vehicle network environment embodied in the present application.
- FIG. 2 is a flow chart detailing the matching sub-algorithm for finding carpool partners.
- FIG. 3 is a flow chart detailing the scoring sub-algorithm for potential carpool partners.
- FIG. 4 details the weighing function to determine best match based on optional parameters.
- FIG. 5 is a flow chart detailing automatic carpool matches based on the user's drive history.
- Carpooling has become popular due to longer commute times, higher fuel prices and an increased desire to be environmentally friendly. Many users may indicate a preference for carpooling over driving alone. Finding successful carpool partner(s), however, can be challenging because of the difficulty in finding a partner whose daily schedule closely resembles a user's schedule. Many people may not accurately report information required to find a successful carpool partner. In the past, people have attempted to advertise a desire to carpool via the Internet. These listings often have people manually input their commute times and locations. Since, manual inputs are prone to human error, people's actual commute times may be unpredictably different. If people's schedules are too dissimilar, they are less likely to carpool together. In this application, the vehicle's route history and travel times are automatically collected to improve the quality of carpool matches by obtaining enhanced data.
- the telematics device 8 may contain an internal clock or alternatively, the telematics device 8 may receive the current time through the mobile network connection 9 . Using data regarding the current time, the telematics device 8 may record arrival times and departure times for each of the routes traveled by the vehicle 4 . An amalgamated set of data regarding vehicle commutes can be received by a network cloud server 20 . The server 20 , using the data received from other vehicles and the vehicle 4 , may ascertain a carpool match as explained below.
- a network cloud 12 can represent one or more interconnected network systems through which the systems and hosts described can communicate.
- the network cloud 12 can include packet-based networks that operate through a wide area network such as a 3G network on a mobile phone.
- Vehicle nodes 14 are communicatively connected to the network cloud through a multitude of communications devices. These communication devices can include an internal communication device capable of connecting with a wide-area network located on the vehicle 4 . Alternatively, the vehicle 4 can interface with the mobile phone network of the user.
- the network cloud 12 can contain physical servers 20 which can be used to implement the functionality described.
- the physical server 20 can contain a multitude of hardware processors and cache systems for data-processing.
- the physical server 20 is also in communication with a database which stores both the vehicle-gathered data and the user-defined data stored in various data structures.
- the vehicle 4 collects the data automatically using the telematics equipment 8 .
- the vehicle 4 also matches the most suitable carpool matches using a variety of factors that would lead to a more successful carpooling match.
- FIG. 2 is a flow chart detailing a car-pool matching algorithm.
- the vehicle 4 can collect data relevant for finding optimal carpool matches.
- the data collected can include recently traveled routes, frequency of the routes traveled, and arrival times and departure times. This can be accomplished using the built-in vehicle GPS receiver that is located on a variety of vehicles.
- the built-in GPS receiver can track the present position of the vehicle at any given time. By sampling the location of the vehicle during certain pre-defined intervals, the GPS receiver can discern the vehicle route.
- the arrival times and departure times can be gathered through an internal vehicle clock that can be embedded in many vehicle control systems.
- the frequency of travelling a particular route can be gleaned through a counter for each of the routes. Some routes, such as children's activities, could be traveled only 2-3 times a week. It would be possible to commute with others doing the same activities.
- the vehicle 4 sends a log of previously traveled routes to a network cloud 12 .
- the server 10 communicates with a database, which can store the log of previously traveled routes to a network cloud 12 .
- the database can be indexed by route. This would enable the database to remember and associate previously matched routes.
- the server 10 receives a notification from a user requesting a carpool partner.
- the notification can be either for a specific route or a general request. If there is a request for a specific route, the user will be asked to identify for which of the most frequently traveled routes she wishes to find a carpool partner.
- the user can manually input a specific route or select a pre-identified route that the user travels.
- the user can also send optional preferences during this time. Alternatively, the user can preload these optional preferences using either his home computer or his mobile phone.
- the optional preferences can include possible flexibility regarding commute times, willingness to deviate from the route to accommodate carpooling partners, user network restrictions, and music and radio station preferences.
- User network restrictions can be a limiting factor to ensure that the carpool match is a trusted user.
- the network restrictions could be limited to people working at a certain company. Alternatively, it can be people located within a certain radius from the user, or people located within a specific sub-division. Users can optionally choose to enroll in specific networks.
- the network cloud 12 identifies other users who are traveling similar route patterns. This will be discussed more in detail with reference to FIG. 3 . This is accomplished by looking at the similarity between user's routes. There are many route-matching algorithms available in the art. One possible method includes comparing the starting points and ending points for each of the routes. After this step is performed, there is an associated list of users who drive substantially similar routes. When users who travel a substantially similar route are identified, the algorithm further refines the candidates based on other factors. This allows the server to limit its search space from all users to a set of users who are located closer to each other, thereby resulting in quicker solutions.
- the list of candidates is further refined.
- Users can be filtered, for example, based on other criteria selected by the first user.
- the algorithm can also use a system default if no other criteria have been uploaded by the first user. For example if a user has a flexible time to return from work, but has to go to work every day at 8:00 am, the algorithm can give more weight to the similarity between the start times and less weight to the similarities between the return times. The algorithm creates a weighting function that will give users who are more similar a higher matching score. This will be discussed more in detail in FIG. 4 .
- the list of remaining candidates is ordered based on their similarity score.
- the candidates with the highest similarity score to the first user will be deemed as the “best” match.
- the matches with the higher similarity score, as calculated at operation 38 are listed first while the less suitable matches are listed later on the list. This allows the users an opportunity to contact the “best” matches first followed by the less suitable matches if the best matches are either unresponsive or do not lead to a successful carpool partner for other reasons.
- FIG. 3 is a flow chart detailing how users with similar routes are identified.
- the driver uploads a set of preferences for ride-sharing.
- the user's driving history is retrieved from a database and parsed into a matrix that contains the values of the primary parameters that need to be matched.
- These primary parameters may include routes defined by a starting point, ending point, starting time and ending time.
- the primary parameters are loaded into the matrix.
- methods available in the art for comparing data for similarity can include, for example, singular-value decomposition, Bayesian matching, and Hidden Markov Models. In this particular embodiment, the nearest-neighbor matching will be shown. Any of these techniques, however, can be used to find similarity between data parameters.
- the entries into the matrix are converted into a numerical value representing the routes for analysis.
- These factors can include the physical distance between starting and ending points, starting time and ending time for each of the previously traveled routes.
- the starting point can be a function of the latitude and longitude of a given point.
- Other data points could have other heuristics to convert them into numerical values.
- a similarity table can be created by computing the distance between the numerical values.
- One way of doing that is using a simple Euclidean least-squares method where the difference between each of the parameters is calculated to determine similarity between the users.
- Other possible methods can include Bayesian matching or Hidden Markov Model algorithms to find similarity between two users.
- the algorithm identifies a set of users. These users are mapped to the primary user in a way that it can reflect the similarity in routes with the primary user.
- One such example includes having the similarity in routes be represented by a graph with weighted nodes. This will allow the algorithm to keep track of other similar users in case the first carpool match does not work out.
- the algorithm then compares these similarity values against a threshold value to see if the routes are close enough for the user to be matched.
- the threshold value is different for each user as users have a different tolerance for deviations. For example, one user could have a job where he has flextime. Therefore, the starting and ending times are not as important to him as it is to other users. This algorithm accounts for the variations that are acceptable to each user.
- FIG. 4 details the weighing function to determine best match based on optional parameters.
- the primary step involves identifying secondary parameters or factors that the user would like the algorithm to consider.
- the user can upload an optional “user-profile” into the database.
- the database stores vehicle-specific information.
- the secondary parameters can include networks to limit the search, driving style, flexibility in scheduling, willingness to deviate in order to accommodate carpool, and radio-station preferences among others.
- the user using either the telematics device located on his vehicle or a computing device, can rank these factors among others in order of importance. Additionally, the user can also give a numerical weight to the factors he considers important. This list of preferences can be stored in a matrix representing each user.
- a weighting function is devised for each of the corresponding parameters.
- the weighing function is constructed using the user's rankings or numerical weights.
- the weighing function can be a simple multiplier, or alternatively a more complicated polynomial function.
- the values for the secondary parameters for users that were at operation 46 are loaded into the matrix.
- the values are amended using the weight function.
- a least-distance analysis is completed and the users who most closely match are then put in an ordered list.
- a list of acceptable users is sent to the display screen located on the telematics device or alternatively through a text message or email to the user indicating possible carpool matches.
- a link with the other user's contact information can appear. Once selected, the link could directly call or send a message to the other user.
- FIG. 5 is a flow chart indicating automatic carpool matches based on the user's drive history.
- a user can identify a route that he wishes to find a carpool partner, sometimes users do not think to input the route. Alternatively, they could be oblivious to the possibility of available carpool matches.
- the vehicle user has routes that are suitable for carpool matches suggested to him as well as potential partners.
- a log of recently traversed routes is examined to identify potential routes that are suitable for carpooling.
- the user manually inputted a route for which he wished to find a carpool match.
- the server attempts to automatically find suitable routes for carpool matches. For example, if the user traveled a particular route every day, the user could be more inclined to want to find a carpool match. This may be accomplished by examining the log of recently traveled routes by a first user. Using the log, the algorithm can ascertain suitable routes for carpooling.
- the routes are filtered by these predetermined parameters that would make it more likely that the user would want to carpool.
- the algorithm can take into account how frequent the route is traversed, additionally, the algorithm can also take into consideration arrival times and departure times. If for example the arrival time and departure time is closer to rush hour, the user is more likely to want to carpool, as opposed to being later in the evening when there is less traffic.
- the filter can be created by weighting different parameters and creating a function such that the results with the highest scores would be the ones that are most suitable.
- the routes are ranked based on the score received in the filter.
- the highest ranking route is selected as this maybe the route that would be most suitable for carpool matching.
- the highest ranking route is presented to the user. It can be presented either on the mobile device of the user or the telematics screen.
- the processes, methods, or algorithms disclosed herein can be deliverable to/implemented by a processing device, controller, or computer, which can include any existing programmable electronic control unit or dedicated electronic control unit.
- the processes, methods, or algorithms can be stored as data and instructions executable by a controller or computer in many forms including, but not limited to, information permanently stored on non-writable storage media such as ROM devices and information alterably stored on writeable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media.
- the processes, methods, or algorithms can also be implemented in a software executable object.
- the algorithms can be embodied in whole or in part using suitable hardware components, such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), state machines, or other hardware components or devices, or a combination of hardware, software and firmware components.
- suitable hardware components such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), state machines, or other hardware components or devices, or a combination of hardware, software and firmware components.
Abstract
A vehicle includes a route collection module that collects drive history data describing a plurality of routes traveled by the vehicle and associated departure and arrival times for each of the routes, and a vehicle computing system that sends the drive history data and, in response, receives contact information for at least one driver of at least one other vehicle based on a similarity between the collected drive history data and drive history data associated with the at least one other vehicle. The vehicle further includes an interface that displays or plays the contact information to facilitate ride sharing between a driver of the vehicle and the at least one driver of the at least one other vehicle.
Description
This disclosure relates to systems and methods for finding carpool partners.
Automated recommendation systems have been used in book and music retail. For example, current systems give recommendations regarding which books or music to buy based on past purchases and the purchases of others. Similarly, with Global Positioning Systems (GPS), it may be possible to determine a vehicle's routes and recommend driving partners based on the previous routes traveled by the vehicle.
A method for drive profile matching includes receiving, by a processing device, a plurality of drive histories associated with a plurality of vehicles. Each of the drive histories identifies one of the vehicles and a plurality of routes traversed by the one of the vehicles. Each of the routes has associated departure and arrival times. The method further includes generating data values representing a similarity between at least two of the routes each traversed by a different one of the vehicles based on a path defined by each of the routes and the associated departure and arrival times, identifying at least two or more of the vehicles based on the generated data values, and providing output about the identified vehicles to facilitate ride sharing among drivers of the identified vehicles.
Embodiments of the present disclosure are described herein; however, it is to be understood that the disclosed embodiments are merely examples and other embodiments can take various and alternative forms. The figures are not necessarily to scale; some features could be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention. As those of ordinary skill in the art will understand, various features illustrated and described with reference to any one of the figures can be combined with features illustrated in one or more other figures to produce embodiments that are not explicitly illustrated or described. The combinations of features illustrated provide representative embodiments for typical applications. Various combinations and modifications of the features consistent with the teachings of this disclosure, however, could be desired for particular applications or implementations.
Carpooling has become popular due to longer commute times, higher fuel prices and an increased desire to be environmentally friendly. Many users may indicate a preference for carpooling over driving alone. Finding successful carpool partner(s), however, can be challenging because of the difficulty in finding a partner whose daily schedule closely resembles a user's schedule. Many people may not accurately report information required to find a successful carpool partner. In the past, people have attempted to advertise a desire to carpool via the Internet. These listings often have people manually input their commute times and locations. Since, manual inputs are prone to human error, people's actual commute times may be unpredictably different. If people's schedules are too dissimilar, they are less likely to carpool together. In this application, the vehicle's route history and travel times are automatically collected to improve the quality of carpool matches by obtaining enhanced data.
A network cloud 12 can represent one or more interconnected network systems through which the systems and hosts described can communicate. The network cloud 12 can include packet-based networks that operate through a wide area network such as a 3G network on a mobile phone. Vehicle nodes 14 are communicatively connected to the network cloud through a multitude of communications devices. These communication devices can include an internal communication device capable of connecting with a wide-area network located on the vehicle 4. Alternatively, the vehicle 4 can interface with the mobile phone network of the user. Additionally, there can be optional computer nodes 16 that are communicatively connected to the network. These computer nodes 16 can be personal computers of the users, mobile phones or other computing devices. These computer nodes 16 can be used to communicate other preferences or data from the user that is not gathered automatically through the vehicle 4. Some examples of user-defined preferences can include the user's driving style, his flexibility with regards to start and end times, and the user's flexibility in regards to deviating slightly from the daily route.
The network cloud 12 can contain physical servers 20 which can be used to implement the functionality described. In one example, the physical server 20 can contain a multitude of hardware processors and cache systems for data-processing. The physical server 20 is also in communication with a database which stores both the vehicle-gathered data and the user-defined data stored in various data structures.
Current methods of finding carpooling matches often require the user to input commute times and locations manually. People may not accurately input their commute times. Many people claim they work from Monday-Friday from 9 to 5 pm. Some people can be habitually late. Their actual commute times can vary significantly from their inputted times. For example, two users Alan and Bob, both could manually input their work hours as Monday-Friday starting at 9 am and returning at 5 pm. Alan, however, could be habitually late and therefore he could actually go to work at 9:30 am and return home at 6:15 pm. Bob, on the other hand, could leave earlier than he inputs. Therefore, Bob's actual commute would be going to work at 8:30 am and returning at 4:45 pm. If Alan and Bob attempted to carpool with each other believing that they have the same working hours, they could be frustrated because there is over one hour difference in their actual work hours. This can diminish the likelihood that they would repeatedly commute because both parties are required to make significant adjustments to their commuting practices.
Instead of relying on users to provide estimations regarding their commute times and routes, the vehicle 4 collects the data automatically using the telematics equipment 8. The vehicle 4 also matches the most suitable carpool matches using a variety of factors that would lead to a more successful carpooling match.
At operation 32, the vehicle 4 sends a log of previously traveled routes to a network cloud 12. The server 10 communicates with a database, which can store the log of previously traveled routes to a network cloud 12. When uploading the data, the database can be indexed by route. This would enable the database to remember and associate previously matched routes.
At operation 34 in one of the embodiments, the server 10 receives a notification from a user requesting a carpool partner. The notification can be either for a specific route or a general request. If there is a request for a specific route, the user will be asked to identify for which of the most frequently traveled routes she wishes to find a carpool partner. The user can manually input a specific route or select a pre-identified route that the user travels. The user can also send optional preferences during this time. Alternatively, the user can preload these optional preferences using either his home computer or his mobile phone. The optional preferences can include possible flexibility regarding commute times, willingness to deviate from the route to accommodate carpooling partners, user network restrictions, and music and radio station preferences. User network restrictions can be a limiting factor to ensure that the carpool match is a trusted user. The network restrictions, for example, could be limited to people working at a certain company. Alternatively, it can be people located within a certain radius from the user, or people located within a specific sub-division. Users can optionally choose to enroll in specific networks.
At operation 36, the network cloud 12 identifies other users who are traveling similar route patterns. This will be discussed more in detail with reference to FIG. 3 . This is accomplished by looking at the similarity between user's routes. There are many route-matching algorithms available in the art. One possible method includes comparing the starting points and ending points for each of the routes. After this step is performed, there is an associated list of users who drive substantially similar routes. When users who travel a substantially similar route are identified, the algorithm further refines the candidates based on other factors. This allows the server to limit its search space from all users to a set of users who are located closer to each other, thereby resulting in quicker solutions.
At operation 38, the list of candidates is further refined. Users can be filtered, for example, based on other criteria selected by the first user. The algorithm can also use a system default if no other criteria have been uploaded by the first user. For example if a user has a flexible time to return from work, but has to go to work every day at 8:00 am, the algorithm can give more weight to the similarity between the start times and less weight to the similarities between the return times. The algorithm creates a weighting function that will give users who are more similar a higher matching score. This will be discussed more in detail in FIG. 4 .
At operation 40, the list of remaining candidates is ordered based on their similarity score. The candidates with the highest similarity score to the first user will be deemed as the “best” match. The matches with the higher similarity score, as calculated at operation 38, are listed first while the less suitable matches are listed later on the list. This allows the users an opportunity to contact the “best” matches first followed by the less suitable matches if the best matches are either unresponsive or do not lead to a successful carpool partner for other reasons.
Although there are currently many recommendation systems for various products such as books and music, most of these recommendation systems perform a discrete analysis between the products used by the users. Therefore, they are able to give a list of “similar” items, but they are not able to rank the items on the basis of similarity. For example, there are recommendation systems that suggest to a user to buy a certain book B after the user buys another related book A. These recommendation systems work by looking at other purchases by users who purchased the related book A and recommend the book that was most frequently bought by purchasers of book A. In this system, a secondary analysis examines many different factors for similarity between routes that cannot be discretely quantified such as the number of books purchased. For example, the difference in commute time could range from 1 minute to 10 minutes. Therefore, one would need to be able to figure out “how similar” the commute times are. In other recommendation systems, the similarities can be mostly limited to binary matches such as whether or not the users bought the same book or downloaded the same song.
At operation 42, the user's driving history is retrieved from a database and parsed into a matrix that contains the values of the primary parameters that need to be matched. These primary parameters may include routes defined by a starting point, ending point, starting time and ending time.
At operation 43, the primary parameters are loaded into the matrix. There are many methods available in the art for comparing data for similarity. These can include, for example, singular-value decomposition, Bayesian matching, and Hidden Markov Models. In this particular embodiment, the nearest-neighbor matching will be shown. Any of these techniques, however, can be used to find similarity between data parameters.
At operation 44, the entries into the matrix are converted into a numerical value representing the routes for analysis. These factors can include the physical distance between starting and ending points, starting time and ending time for each of the previously traveled routes. For example, the starting point can be a function of the latitude and longitude of a given point. Other data points could have other heuristics to convert them into numerical values.
At operation 45, a similarity table can be created by computing the distance between the numerical values. One way of doing that is using a simple Euclidean least-squares method where the difference between each of the parameters is calculated to determine similarity between the users. Other possible methods can include Bayesian matching or Hidden Markov Model algorithms to find similarity between two users.
At operation 46 using the similarity table, the algorithm identifies a set of users. These users are mapped to the primary user in a way that it can reflect the similarity in routes with the primary user. There are various data structures that could accomplish this. One such example includes having the similarity in routes be represented by a graph with weighted nodes. This will allow the algorithm to keep track of other similar users in case the first carpool match does not work out. Referring to FIG. 3 , at operation 36 the algorithm then compares these similarity values against a threshold value to see if the routes are close enough for the user to be matched. The threshold value is different for each user as users have a different tolerance for deviations. For example, one user could have a job where he has flextime. Therefore, the starting and ending times are not as important to him as it is to other users. This algorithm accounts for the variations that are acceptable to each user.
At operation 54, a weighting function is devised for each of the corresponding parameters. The weighing function is constructed using the user's rankings or numerical weights. The weighing function can be a simple multiplier, or alternatively a more complicated polynomial function. At operation 56, the values for the secondary parameters for users that were at operation 46 are loaded into the matrix.
At operation 58, the values are amended using the weight function. At operation 50, a least-distance analysis is completed and the users who most closely match are then put in an ordered list. At operation 52, a list of acceptable users is sent to the display screen located on the telematics device or alternatively through a text message or email to the user indicating possible carpool matches. In the telematics display screen, a link with the other user's contact information can appear. Once selected, the link could directly call or send a message to the other user.
At operation 60, a log of recently traversed routes is examined to identify potential routes that are suitable for carpooling. In FIG. 2 , the user manually inputted a route for which he wished to find a carpool match. In operation 60, the server attempts to automatically find suitable routes for carpool matches. For example, if the user traveled a particular route every day, the user could be more inclined to want to find a carpool match. This may be accomplished by examining the log of recently traveled routes by a first user. Using the log, the algorithm can ascertain suitable routes for carpooling.
At operation 62, the routes are filtered by these predetermined parameters that would make it more likely that the user would want to carpool. The algorithm can take into account how frequent the route is traversed, additionally, the algorithm can also take into consideration arrival times and departure times. If for example the arrival time and departure time is closer to rush hour, the user is more likely to want to carpool, as opposed to being later in the evening when there is less traffic. The filter can be created by weighting different parameters and creating a function such that the results with the highest scores would be the ones that are most suitable.
At operation 64, the routes are ranked based on the score received in the filter. The highest ranking route is selected as this maybe the route that would be most suitable for carpool matching. At operation 66, the highest ranking route is presented to the user. It can be presented either on the mobile device of the user or the telematics screen.
The processes, methods, or algorithms disclosed herein can be deliverable to/implemented by a processing device, controller, or computer, which can include any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms can be stored as data and instructions executable by a controller or computer in many forms including, but not limited to, information permanently stored on non-writable storage media such as ROM devices and information alterably stored on writeable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The processes, methods, or algorithms can also be implemented in a software executable object. Alternatively, the algorithms can be embodied in whole or in part using suitable hardware components, such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), state machines, or other hardware components or devices, or a combination of hardware, software and firmware components.
While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The words used in the specification are words of description rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the disclosure and claims. As previously described, the features of various embodiments can be combined to form further embodiments of the invention that may not be explicitly described or illustrated. While various embodiments could have been described as providing advantages or being preferred over other embodiments or prior art implementations with respect to one or more desired characteristics, those of ordinary skill in the art recognize that one or more features or characteristics can be compromised to achieve desired overall system attributes, which depend on the specific application and implementation. These attributes can include, but are not limited to, cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, serviceability, weight, manufacturability, ease of assembly, etc. As such, embodiments described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics are not outside the scope of the disclosure and could be desirable for particular applications.
Claims (3)
1. A vehicle comprising:
a controller configured to
collect drive data describing travelled routes,
send, off-board, the drive data,
responsive to the sending, receive and display information for a driver of another vehicle based on a degree of similarity between the drive data and drive data of the another vehicle that depends on a user specified schedule deviation tolerance, and
responsive to input selecting the information, initiate a telephone call to the another vehicle.
2. A method comprising:
by a vehicle,
collecting drive data describing travelled routes,
sending, off-board, the drive data,
responsive to the sending, receiving and displaying information for a driver of another vehicle based on a degree of similarity between the drive data and drive data of the another vehicle that depends on a user specified schedule deviation tolerance, and
responsive to input selecting the information, initiating a message to the another vehicle.
3. A vehicle comprising:
a controller configured to
collect drive data describing travelled routes,
send, off-board, the drive data,
responsive to the sending, receive and play information for a driver of another vehicle based on a degree of similarity between the drive data and drive data of the another vehicle that depends on a user specified schedule deviation tolerance, and
responsive to input selecting the information, initiate a telephone call or message to the another vehicle.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/402,963 US9489644B2 (en) | 2012-02-23 | 2012-02-23 | Vehicle drive matching system and method |
CN201310054887.8A CN103294758B (en) | 2012-02-23 | 2013-02-20 | Vehicle drive matching system and method |
DE102013202692A DE102013202692A1 (en) | 2012-02-23 | 2013-02-20 | SYSTEM FOR FINDING VEHICLE DRIVING CONDITIONS AND METHODS |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/402,963 US9489644B2 (en) | 2012-02-23 | 2012-02-23 | Vehicle drive matching system and method |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130226365A1 US20130226365A1 (en) | 2013-08-29 |
US9489644B2 true US9489644B2 (en) | 2016-11-08 |
Family
ID=48950983
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/402,963 Active 2034-10-20 US9489644B2 (en) | 2012-02-23 | 2012-02-23 | Vehicle drive matching system and method |
Country Status (3)
Country | Link |
---|---|
US (1) | US9489644B2 (en) |
CN (1) | CN103294758B (en) |
DE (1) | DE102013202692A1 (en) |
Families Citing this family (91)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10445799B2 (en) | 2004-09-30 | 2019-10-15 | Uber Technologies, Inc. | Supply-chain side assistance |
US10514816B2 (en) | 2004-12-01 | 2019-12-24 | Uber Technologies, Inc. | Enhanced user assistance |
US10687166B2 (en) | 2004-09-30 | 2020-06-16 | Uber Technologies, Inc. | Obtaining user assistance |
US8358976B2 (en) | 2006-03-24 | 2013-01-22 | The Invention Science Fund I, Llc | Wireless device with an aggregate user interface for controlling other devices |
CN103247091B (en) * | 2012-02-07 | 2016-01-20 | 厦门金龙联合汽车工业有限公司 | A kind of driving evaluation system and method |
US9489644B2 (en) * | 2012-02-23 | 2016-11-08 | Ford Global Technologies, Llc | Vehicle drive matching system and method |
WO2014172327A1 (en) | 2013-04-15 | 2014-10-23 | Flextronics Ap, Llc | Synchronization between vehicle and user device calendar |
WO2014172369A2 (en) | 2013-04-15 | 2014-10-23 | Flextronics Ap, Llc | Intelligent vehicle for assisting vehicle occupants and incorporating vehicle crate for blade processors |
US9378601B2 (en) | 2012-03-14 | 2016-06-28 | Autoconnect Holdings Llc | Providing home automation information via communication with a vehicle |
US9412273B2 (en) | 2012-03-14 | 2016-08-09 | Autoconnect Holdings Llc | Radar sensing and emergency response vehicle detection |
US9147298B2 (en) | 2012-03-14 | 2015-09-29 | Flextronics Ap, Llc | Behavior modification via altered map routes based on user profile information |
US20140309893A1 (en) | 2013-04-15 | 2014-10-16 | Flextronics Ap, Llc | Health statistics and communications of associated vehicle users |
US9384609B2 (en) | 2012-03-14 | 2016-07-05 | Autoconnect Holdings Llc | Vehicle to vehicle safety and traffic communications |
TWI475507B (en) * | 2012-08-20 | 2015-03-01 | Univ Nat Taiwan Science Tech | Network matchmaking system |
US9127958B2 (en) * | 2013-01-03 | 2015-09-08 | Sap Se | Shared ride driver determination |
US9506768B2 (en) * | 2013-02-28 | 2016-11-29 | Sap Se | Adaptive route proposals based on prior rides |
US9434389B2 (en) * | 2013-11-18 | 2016-09-06 | Mitsubishi Electric Research Laboratories, Inc. | Actions prediction for hypothetical driving conditions |
CN104751625A (en) * | 2013-12-25 | 2015-07-01 | 上海博泰悦臻网络技术服务有限公司 | Carpooling method and carpooling system based on trajectory analysis |
DE112014006337B4 (en) * | 2014-02-07 | 2024-01-18 | Mitsubishi Electric Corporation | Functional candidate presentation device |
JP6340866B2 (en) * | 2014-03-27 | 2018-06-13 | 富士通株式会社 | Carpool request method, carpool request apparatus and program |
US9792574B2 (en) | 2014-05-06 | 2017-10-17 | Elwha Llc | System and methods for verifying that one or more end user transport directives do not conflict with one or more package delivery directives |
US9483744B2 (en) * | 2014-05-06 | 2016-11-01 | Elwha Llc | Real-time carpooling coordinating systems and methods |
US9569740B2 (en) | 2014-05-06 | 2017-02-14 | Elwha Llc | System and methods for directiing one or more transportation vehicle units to transport one or more end users |
US10458801B2 (en) | 2014-05-06 | 2019-10-29 | Uber Technologies, Inc. | Systems and methods for travel planning that calls for at least one transportation vehicle unit |
US9581455B2 (en) | 2014-05-06 | 2017-02-28 | Elwha Llc | Systems and methods for providing at least a portion of a travel plan that calls for at least one transportation vehicle unit |
US9552559B2 (en) | 2014-05-06 | 2017-01-24 | Elwha Llc | System and methods for verifying that one or more directives that direct transport of a second end user does not conflict with one or more obligations to transport a first end user |
US9599481B2 (en) | 2014-05-06 | 2017-03-21 | Elwha Llc | System and methods for identifying one or more transportation vehicle units with or without package delivery obligation for transporting one or more end users |
US11100434B2 (en) | 2014-05-06 | 2021-08-24 | Uber Technologies, Inc. | Real-time carpooling coordinating system and methods |
US9671239B2 (en) | 2014-05-06 | 2017-06-06 | Elwha Llc | System and methods for facilitating real-time carpooling |
DE102015208287A1 (en) * | 2014-05-07 | 2015-11-12 | Ford Global Technologies, Llc | COMMUNITY VEHICLE SYSTEMS AND METHODS |
CN104217249B (en) * | 2014-07-02 | 2017-06-23 | 浙江工业大学 | A kind of dynamic share-car matching process based on time Yu expense restriction |
US20160026935A1 (en) * | 2014-07-24 | 2016-01-28 | International Business Machines Corporation | Multiple individual travel scheduling |
US9612127B2 (en) * | 2014-07-25 | 2017-04-04 | GM Global Technology Operations LLC | Carpool finder assistance |
EP3183707A4 (en) | 2014-08-21 | 2018-02-28 | Uber Technologies Inc. | Arranging a transport service for a user based on the estimated time of arrival of the user |
CN105430031B (en) * | 2014-09-17 | 2018-08-24 | 口碑控股有限公司 | A kind of share-car information transmitting methods and device |
US10197410B2 (en) * | 2014-11-18 | 2019-02-05 | International Business Machines Corporation | Dynamic real-time carpool matching |
US20160140480A1 (en) * | 2014-11-18 | 2016-05-19 | Adp, Llc | Transportation Coordination System |
WO2016156900A1 (en) * | 2015-04-02 | 2016-10-06 | Nokia Technologies Oy | An apparatus and associated methods for use in planning a group journey |
CN104933136B (en) * | 2015-06-15 | 2019-05-03 | 北方工业大学 | Dynamic share-car method and system based on magnanimity license auto-recognition system data |
CN105407127A (en) * | 2015-06-26 | 2016-03-16 | 乌海涛 | Method, apparatus, and system for free sharing of passenger tool resources |
US10212536B2 (en) | 2015-07-10 | 2019-02-19 | Uber Technologies, Inc. | Selecting a messaging protocol for transmitting data in connection with a location-based service |
US20170046891A1 (en) * | 2015-08-12 | 2017-02-16 | Tyco Fire & Security Gmbh | Systems and methods for location identification and tracking using a camera |
RU2701986C2 (en) * | 2015-08-21 | 2019-10-02 | ФОРД ГЛОУБАЛ ТЕКНОЛОДЖИЗ, ЭлЭлСи | Radio station recommendation system and method |
US10692126B2 (en) | 2015-11-17 | 2020-06-23 | Nio Usa, Inc. | Network-based system for selling and servicing cars |
CN105631531A (en) * | 2015-11-26 | 2016-06-01 | 东莞酷派软件技术有限公司 | Driving friend recommendation method, driving friend recommendation device and server |
CN108292308A (en) * | 2015-11-27 | 2018-07-17 | 宝马股份公司 | It is that user recommends vehicle/passenger's resource according to mobile custom |
US9989374B2 (en) | 2015-12-31 | 2018-06-05 | Gt Gettaxi Limited | System for generating travel route to be serviced by primary transportation service and secondary transportation service |
CN107016584B (en) * | 2016-01-27 | 2021-01-05 | 北京嘀嘀无限科技发展有限公司 | Order screening method and device |
US10242574B2 (en) | 2016-03-21 | 2019-03-26 | Uber Technologies, Inc. | Network computer system to address service providers to contacts |
CN105957337A (en) * | 2016-06-02 | 2016-09-21 | 深圳市永兴元科技有限公司 | Order processing method and apparatus |
US20180012197A1 (en) | 2016-07-07 | 2018-01-11 | NextEv USA, Inc. | Battery exchange licensing program based on state of charge of battery pack |
US9928734B2 (en) | 2016-08-02 | 2018-03-27 | Nio Usa, Inc. | Vehicle-to-pedestrian communication systems |
US11024160B2 (en) | 2016-11-07 | 2021-06-01 | Nio Usa, Inc. | Feedback performance control and tracking |
US10694357B2 (en) | 2016-11-11 | 2020-06-23 | Nio Usa, Inc. | Using vehicle sensor data to monitor pedestrian health |
US10410064B2 (en) | 2016-11-11 | 2019-09-10 | Nio Usa, Inc. | System for tracking and identifying vehicles and pedestrians |
US10708547B2 (en) | 2016-11-11 | 2020-07-07 | Nio Usa, Inc. | Using vehicle sensor data to monitor environmental and geologic conditions |
WO2018093381A1 (en) * | 2016-11-18 | 2018-05-24 | Ford Motor Company | Methods and apparatus to enable vehicle-to-vehicle guidance and tracking |
US10515390B2 (en) | 2016-11-21 | 2019-12-24 | Nio Usa, Inc. | Method and system for data optimization |
US20180143027A1 (en) * | 2016-11-22 | 2018-05-24 | Microsoft Technology Licensing, Llc | Dynamic route planning for demand-based transport |
US10249104B2 (en) | 2016-12-06 | 2019-04-02 | Nio Usa, Inc. | Lease observation and event recording |
US10074223B2 (en) | 2017-01-13 | 2018-09-11 | Nio Usa, Inc. | Secured vehicle for user use only |
US10471829B2 (en) | 2017-01-16 | 2019-11-12 | Nio Usa, Inc. | Self-destruct zone and autonomous vehicle navigation |
US10031521B1 (en) | 2017-01-16 | 2018-07-24 | Nio Usa, Inc. | Method and system for using weather information in operation of autonomous vehicles |
US9984572B1 (en) | 2017-01-16 | 2018-05-29 | Nio Usa, Inc. | Method and system for sharing parking space availability among autonomous vehicles |
US10464530B2 (en) | 2017-01-17 | 2019-11-05 | Nio Usa, Inc. | Voice biometric pre-purchase enrollment for autonomous vehicles |
US10286915B2 (en) | 2017-01-17 | 2019-05-14 | Nio Usa, Inc. | Machine learning for personalized driving |
GB2559159A (en) * | 2017-01-27 | 2018-08-01 | Kbd Tech Limited | System and methods for data correlation between a telematics system and a fleet management system |
US10897469B2 (en) | 2017-02-02 | 2021-01-19 | Nio Usa, Inc. | System and method for firewalls between vehicle networks |
US11361594B1 (en) | 2017-05-17 | 2022-06-14 | Wells Fargo Bank, N.A. | Utilization of free time in autonomous vehicles |
US10234302B2 (en) | 2017-06-27 | 2019-03-19 | Nio Usa, Inc. | Adaptive route and motion planning based on learned external and internal vehicle environment |
US10369974B2 (en) | 2017-07-14 | 2019-08-06 | Nio Usa, Inc. | Control and coordination of driverless fuel replenishment for autonomous vehicles |
US10710633B2 (en) | 2017-07-14 | 2020-07-14 | Nio Usa, Inc. | Control of complex parking maneuvers and autonomous fuel replenishment of driverless vehicles |
US10837790B2 (en) | 2017-08-01 | 2020-11-17 | Nio Usa, Inc. | Productive and accident-free driving modes for a vehicle |
US10703366B2 (en) * | 2017-08-29 | 2020-07-07 | Ford Global Technologies, Llc | Inhibiting highway assist mode |
US10567520B2 (en) | 2017-10-10 | 2020-02-18 | Uber Technologies, Inc. | Multi-user requests for service and optimizations thereof |
US10635109B2 (en) | 2017-10-17 | 2020-04-28 | Nio Usa, Inc. | Vehicle path-planner monitor and controller |
US10935978B2 (en) | 2017-10-30 | 2021-03-02 | Nio Usa, Inc. | Vehicle self-localization using particle filters and visual odometry |
US10606274B2 (en) | 2017-10-30 | 2020-03-31 | Nio Usa, Inc. | Visual place recognition based self-localization for autonomous vehicles |
CN107889061B (en) * | 2017-11-08 | 2020-06-02 | 洛阳师范学院 | Method for evaluating vehicle mobility in Internet of vehicles and application of method in video transmission field |
US10717412B2 (en) | 2017-11-13 | 2020-07-21 | Nio Usa, Inc. | System and method for controlling a vehicle using secondary access methods |
US10788329B2 (en) * | 2018-01-09 | 2020-09-29 | Uber Technologies, Inc. | Network system for multi-leg transport |
JP7006468B2 (en) * | 2018-04-09 | 2022-01-24 | トヨタ自動車株式会社 | Information processing equipment, carpool proposal method and program |
US10369966B1 (en) | 2018-05-23 | 2019-08-06 | Nio Usa, Inc. | Controlling access to a vehicle using wireless access devices |
JP7214983B2 (en) * | 2018-06-12 | 2023-01-31 | トヨタ自動車株式会社 | Information processing device and information processing method |
JP7196440B2 (en) * | 2018-07-03 | 2022-12-27 | トヨタ自動車株式会社 | Information processing device and information processing method |
CN109242127B (en) * | 2018-08-23 | 2022-06-24 | 蜜小蜂智慧(北京)科技有限公司 | Vehicle reservation method and device |
JP6978992B2 (en) * | 2018-08-27 | 2021-12-08 | 日立Astemo株式会社 | Update system, electronic control device |
CN110610268A (en) * | 2019-09-11 | 2019-12-24 | 西安工程大学 | Trajectory prediction method for unmanned driving |
CN113711254A (en) * | 2019-11-28 | 2021-11-26 | 松下知识产权经营株式会社 | Information processing method and information processing system |
CN111126909B (en) * | 2019-12-20 | 2023-08-08 | 贵阳货车帮科技有限公司 | Data processing method, device, equipment and storage medium for goods source route |
US11669786B2 (en) | 2020-02-14 | 2023-06-06 | Uber Technologies, Inc. | On-demand transport services |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010056363A1 (en) * | 2000-06-26 | 2001-12-27 | Gantz Donald T. | System for providing ride matching services using e-mail and the internet |
DE20309319U1 (en) | 2003-06-15 | 2003-12-11 | Haas, Karl-Heinz | Car-sharing data storage device, uses data acquisition device which receives radio signals, e.g. SMS messages containing information relating to driver and person wanting lift |
US20040049424A1 (en) * | 2002-06-21 | 2004-03-11 | Murray Thomas A. | System and method for facilitating ridesharing |
US20060059023A1 (en) * | 2002-08-02 | 2006-03-16 | Alex Mashinsky | Method system and apparatus for providing transportation services |
US20070162550A1 (en) | 2006-01-06 | 2007-07-12 | Outland Research, Llc | Vehicle-to-vehicle instant messaging with locative addressing |
US20080077309A1 (en) * | 2006-09-22 | 2008-03-27 | Nortel Networks Limited | Method and apparatus for enabling commuter groups |
US20080195428A1 (en) | 2007-02-12 | 2008-08-14 | O'sullivan Sean | Shared transport system and service network |
US20080275990A1 (en) | 2007-05-01 | 2008-11-06 | Ford Motor Company | Method and system for selecting, in a vehicle, an active preference group |
US20090170434A1 (en) | 2007-12-31 | 2009-07-02 | General Motors Corporation | Method of vehicle to vehicle communication |
US20100207812A1 (en) * | 2009-02-18 | 2010-08-19 | Toyota Motor Engineering & Manufacturing Na | Rideshare system and associated methodology |
US7941267B2 (en) * | 2003-06-24 | 2011-05-10 | At&T Intellectual Property I, Lp | Methods, systems and computer program products for ride matching based on selection criteria and driver characteristic information |
US20120290652A1 (en) * | 2011-05-13 | 2012-11-15 | Zeljko BOSKOVIC | Arrangement and method for transport sharing |
US20130096827A1 (en) * | 2011-10-17 | 2013-04-18 | GM Global Technology Operations LLC | Ride-share service |
US8489326B1 (en) * | 2010-02-09 | 2013-07-16 | Google Inc. | Placemarked based navigation and ad auction based on placemarks |
US8498953B2 (en) * | 2010-03-30 | 2013-07-30 | Sap Ag | Method for allocating trip sharing |
US8504295B2 (en) * | 2011-12-19 | 2013-08-06 | Sap Ag | Preserving assigned carpools after a cancellation |
US20130226365A1 (en) * | 2012-02-23 | 2013-08-29 | Ford Global Technologies, Llc | Vehicle drive matching system and method |
US8612273B2 (en) * | 2010-04-01 | 2013-12-17 | The Crawford Group, Inc. | Method and system for managing vehicle travel |
US8730033B2 (en) * | 2010-02-17 | 2014-05-20 | Hti Ip, L.L.C. | Method and system for sending information from a user device to a car |
US8868529B2 (en) * | 2011-12-16 | 2014-10-21 | Sap Se | N-dimensional locking |
US8909462B2 (en) * | 2011-07-07 | 2014-12-09 | International Business Machines Corporation | Context-based traffic flow control |
US8918231B2 (en) * | 2012-05-02 | 2014-12-23 | Toyota Motor Engineering & Manufacturing North America, Inc. | Dynamic geometry support for vehicle components |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101355714A (en) * | 2007-07-24 | 2009-01-28 | 梁宇杰 | System and method for real time pooling vehicle |
US20090248587A1 (en) * | 2007-08-31 | 2009-10-01 | Van Buskirk Peter C | Selectively negotiated ridershare system comprising riders, drivers, and vehicles |
CN101630320A (en) * | 2009-07-23 | 2010-01-20 | 烟台麦特电子有限公司 | Car pooling control method and vehicle-mounted intelligent terminal device thereof |
-
2012
- 2012-02-23 US US13/402,963 patent/US9489644B2/en active Active
-
2013
- 2013-02-20 CN CN201310054887.8A patent/CN103294758B/en active Active
- 2013-02-20 DE DE102013202692A patent/DE102013202692A1/en active Pending
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010056363A1 (en) * | 2000-06-26 | 2001-12-27 | Gantz Donald T. | System for providing ride matching services using e-mail and the internet |
US20040049424A1 (en) * | 2002-06-21 | 2004-03-11 | Murray Thomas A. | System and method for facilitating ridesharing |
US20060059023A1 (en) * | 2002-08-02 | 2006-03-16 | Alex Mashinsky | Method system and apparatus for providing transportation services |
DE20309319U1 (en) | 2003-06-15 | 2003-12-11 | Haas, Karl-Heinz | Car-sharing data storage device, uses data acquisition device which receives radio signals, e.g. SMS messages containing information relating to driver and person wanting lift |
US7941267B2 (en) * | 2003-06-24 | 2011-05-10 | At&T Intellectual Property I, Lp | Methods, systems and computer program products for ride matching based on selection criteria and driver characteristic information |
US20070162550A1 (en) | 2006-01-06 | 2007-07-12 | Outland Research, Llc | Vehicle-to-vehicle instant messaging with locative addressing |
US20080077309A1 (en) * | 2006-09-22 | 2008-03-27 | Nortel Networks Limited | Method and apparatus for enabling commuter groups |
US20080195428A1 (en) | 2007-02-12 | 2008-08-14 | O'sullivan Sean | Shared transport system and service network |
US20080275990A1 (en) | 2007-05-01 | 2008-11-06 | Ford Motor Company | Method and system for selecting, in a vehicle, an active preference group |
US20090170434A1 (en) | 2007-12-31 | 2009-07-02 | General Motors Corporation | Method of vehicle to vehicle communication |
US20100207812A1 (en) * | 2009-02-18 | 2010-08-19 | Toyota Motor Engineering & Manufacturing Na | Rideshare system and associated methodology |
US8285571B2 (en) * | 2009-02-18 | 2012-10-09 | Toyota Motor Engineering & Manufacturing North America (Tema) | Rideshare system and associated methodology |
US8489326B1 (en) * | 2010-02-09 | 2013-07-16 | Google Inc. | Placemarked based navigation and ad auction based on placemarks |
US8730033B2 (en) * | 2010-02-17 | 2014-05-20 | Hti Ip, L.L.C. | Method and system for sending information from a user device to a car |
US8498953B2 (en) * | 2010-03-30 | 2013-07-30 | Sap Ag | Method for allocating trip sharing |
US8612273B2 (en) * | 2010-04-01 | 2013-12-17 | The Crawford Group, Inc. | Method and system for managing vehicle travel |
US20120290652A1 (en) * | 2011-05-13 | 2012-11-15 | Zeljko BOSKOVIC | Arrangement and method for transport sharing |
US8909462B2 (en) * | 2011-07-07 | 2014-12-09 | International Business Machines Corporation | Context-based traffic flow control |
US20130096827A1 (en) * | 2011-10-17 | 2013-04-18 | GM Global Technology Operations LLC | Ride-share service |
US8868529B2 (en) * | 2011-12-16 | 2014-10-21 | Sap Se | N-dimensional locking |
US8504295B2 (en) * | 2011-12-19 | 2013-08-06 | Sap Ag | Preserving assigned carpools after a cancellation |
US20130226365A1 (en) * | 2012-02-23 | 2013-08-29 | Ford Global Technologies, Llc | Vehicle drive matching system and method |
US8918231B2 (en) * | 2012-05-02 | 2014-12-23 | Toyota Motor Engineering & Manufacturing North America, Inc. | Dynamic geometry support for vehicle components |
Also Published As
Publication number | Publication date |
---|---|
CN103294758B (en) | 2018-09-14 |
US20130226365A1 (en) | 2013-08-29 |
DE102013202692A1 (en) | 2013-08-29 |
CN103294758A (en) | 2013-09-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9489644B2 (en) | Vehicle drive matching system and method | |
US10909464B2 (en) | Semantic locations prediction | |
US10567568B2 (en) | User event pattern prediction and presentation | |
US10446009B2 (en) | Contextual notification engine | |
US20140108307A1 (en) | Methods and systems for providing personalized and context-aware suggestions | |
US9501745B2 (en) | Method, system and device for inferring a mobile user's current context and proactively providing assistance | |
KR101512278B1 (en) | Using mobile device data to create a storyline, model user routine and personality, and create customized recommendation agents | |
CN107209776B (en) | Methods, systems, and media for presenting information related to an event based on metadata | |
US10163058B2 (en) | Method, system and device for inferring a mobile user's current context and proactively providing assistance | |
US20160292584A1 (en) | Inferring User Sleep Patterns | |
WO2017196615A2 (en) | Enhanced user efficiency in route planning using route preferences | |
US20130345958A1 (en) | Computing Recommendations for Stopping During a Trip | |
US20160321616A1 (en) | Unusualness of Events Based On User Routine Models | |
WO2015075848A1 (en) | Content recommendation based on efficacy models | |
US10739146B1 (en) | Transport communication pairing | |
CN113424175A (en) | Intuitive speech search | |
CN113454669A (en) | Characterizing a place by user visited features | |
JP7086785B2 (en) | Calculation device, calculation method and calculation program | |
US20190090197A1 (en) | Saving battery life with inferred location | |
US20220373346A1 (en) | Personalized route recommendation and navigation | |
Hiesel et al. | A user interface concept for context-aware recommender systems | |
US9945683B1 (en) | Transport communication | |
JP2020017130A (en) | Information processing apparatus, information processing system, and information processing method | |
WO2020106499A1 (en) | Saving battery life using an inferred location | |
TW201528187A (en) | People searching method and system for finding targeted person through recommended contact |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FORD GLOBAL TECHNOLOGIES, LLC, MICHIGAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROZOVICH, SHAWN DANIEL;REEL/FRAME:027749/0713 Effective date: 20120110 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |