Patent Application
20230214712
A vehicle experience may provide an individual, such as a driver, access to a vehicle for a period of time to permit the individual to review the vehicle. For example, prior to leasing or purchasing a vehicle, an individual may have access to the vehicle, via a test drive, to review the vehicle and/or confirm whether the vehicle satisfies the individual's expectations.
Some implementations described herein relate to a system for predicting driver-vehicle compatibility using machine learning. The system may include one or more memories and one or more processors communicatively coupled to the one or more memories. The one or more processors may be configured to receive driving data for a plurality of drivers, wherein the driving data indicates, for each of the plurality of drivers, driving behavior measured during vehicle operation and a plurality of importance values corresponding to a plurality of driving categories associated with the driving behavior. The one or more processors may be configured to determine, using an unsupervised machine learning model and based on the driving behavior and the plurality of importance values, a plurality of driver clusters for categorizing the plurality of drivers. The one or more processors may be configured to receive vehicle data for a plurality of vehicles, wherein the vehicle data indicates, for each of the plurality of vehicles, a plurality of performance values corresponding to the plurality of driving categories. The one or more processors may be configured to generate a data structure that indicates a degree of association between a vehicle, or a vehicle cluster that includes the vehicle, and each driver cluster of the plurality of driver clusters based on the driving behavior, the plurality of importance values, and the plurality of performance values. The one or more processors may be configured to receive driver preference data for a user, wherein the driver preference data includes data measured during vehicle operation and an importance value for each driving category of the plurality of driving categories. The one or more processors may be configured to determine a driver cluster, of the plurality of driver clusters, to which the user belongs based on the driver preference data. The one or more processors may be configured to determine one or more compatible vehicles for the user based on the driver cluster and the data structure. The one or more processors may be configured to output vehicle information that indicates the one or more compatible vehicles.
Some implementations described herein relate to a method of predicting driver-vehicle compatibility. The method may include receiving, by a system, driver preference data for a driver, wherein the driver preference data indicates an importance value for each of a plurality of driving categories. The method may include associating, by the system, the driver with a driver archetype, where data corresponding to the driver archetype indicates a combination of ranges of values for the plurality of driving categories, and where an individual importance value for a driving category, of the plurality of driving categories, for the driver falls within a corresponding range of values for the driving category in connection with the driver archetype. The method may include storing, by the system, the driver preference data and an indication of the driver archetype in a driver profile database, wherein the driver preference data and the indication of the driver archetype are associated with a driver identifier associated with the driver. The method may include receiving, by the system, data indicating a vehicle, wherein performance data of the vehicle is stored in a vehicle profile database and indicates a plurality of performance values corresponding to the plurality of driving categories. The method may include determining, by the system, a compatibility score indicating a compatibility between the driver and the vehicle, wherein the compatibility score is based on a comparison of the performance data of the vehicle with the data corresponding to the driver archetype. The method may include transmitting, by the system, data indicating the compatibility score.
Some implementations described herein relate to a non-transitory computer-readable medium that stores a set of instructions for a device. The set of instructions, when executed by one or more processors of the device, may cause the device to obtain data corresponding to a plurality of driver archetypes, wherein the data corresponding to each of the plurality of driver archetypes indicates a combination of ranges of values for a plurality of driving categories. The set of instructions, when executed by one or more processors of the device, may cause the device to receive vehicle data for a plurality of vehicles, wherein the vehicle data indicates, for each of the plurality of vehicles, a plurality of performance values corresponding to the plurality of driving categories. The set of instructions, when executed by one or more processors of the device, may cause the device to generate a data structure that indicates a corresponding degree of association between each vehicle, of the plurality of vehicles, and each driver archetype, of the plurality of driver archetypes, based on the plurality of performance values and the combination of ranges of values for the plurality of driving categories. The set of instructions, when executed by one or more processors of the device, may cause the device to receive driver preference data for a user, wherein the driver preference data indicates a plurality of importance values corresponding to the plurality of driving categories. The set of instructions, when executed by one or more processors of the device, may cause the device to assign a driver archetype to the user based on the driver preference data. The set of instructions, when executed by one or more processors of the device, may cause the device to determine a suggested vehicle, of the plurality of vehicles, based on the data structure, wherein the suggested vehicle has a degree of association that satisfies a threshold value in connection with the driver archetype. The set of instructions, when executed by one or more processors of the device, may cause the device to transmit, to a user device, data indicating the suggested vehicle.
The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
A test drive typically involves an individual requesting a seller (e.g., an individual or organization, such as a manufacturer, dealer, or other entity that sells vehicles) to allow the individual to drive a vehicle for a period of time and accessing the vehicle from a location of the seller. For example, a consumer may arrive at a dealership and request the dealership to authorize the test drive. However, in some situations, the consumer may be unable to travel to the dealership to participate in the test drive, and therefore, may not be able to experience the vehicle firsthand. The consumer may be able to look at reviews of the vehicle to gain a foundational idea of whether or not the vehicle meets the consumer's preferences. However, the reviews alone may not be able to provide an accurate gauge on how compatible the vehicle may be for the consumer.
Some implementations described herein provide a system that predicts a compatibility between a consumer (e.g., a driver) and one or more vehicles in lieu of the consumer having to actually participate in a test drive. The system may also be used for a consumer interested in renting a vehicle and desiring to know if the vehicle will be compatible for the consumer's intended driving use of the vehicle. The system bases the predictions on a relationship between driving data related to the driving behavior of drivers in various driving categories and performance data related to the performance of vehicles in the driving categories. The system may collect the driving data and the performance data from different sources (e.g., direct input from the user and/or monitoring and measuring actual driver performance). From the collected data, the system may generate driver profiles, which may be associated with one or more driver archetypes representative of the driver's driving behavior, and vehicle profiles. The system may generate and/or determine a data structure that indicates a relationship between the vehicles and different driver profiles and/or driver archetypes.
A consumer interested in finding vehicles with which the consumer is compatible may provide, to the system, information related to the consumer's preferences. The system may use the consumer's preferences to determine a particular driver profile or driver archetype under which the consumer may fall. From the determined driver profile or driver archetype, the system may be able to identify one or more compatible vehicles based on the data structure of the relationship between vehicles and the driver profiles and/or driver archetypes.
In some implementations described herein, the system may determine a compatibility score between a consumer (e.g., a driver) and a particular vehicle in which the consumer is interested. The consumer may provide, to the system, vehicle information (e.g., make and model), along with the consumer's driver identifier. From the driver identifier, the system may identify the consumer's driver profile and/or driver archetype and the driving data associated therewith. Additionally, from the vehicle information, the system may obtain vehicle performance data, which the system may compare with the driving data. Based on this comparison (e.g., how similar the driving data and the vehicle performance data are), the system may determine a compatibility score representative of the compatibility between the consumer and the particular vehicle.
By using data related to drivers' driving behavior and associating that data with actual performance data of vehicles, the system may improve accuracy in predicting compatibility between a consumer and vehicles (e.g., compared to systems only considering consumer preferences and vehicle statistics). Additionally, incorporating real data across many drivers further improves the accuracy and lessens variability of the prediction of compatibility between the consumer and the vehicles.
As shown in
As further shown by reference number 102, the responses to the queries may be in the form of numeric values (e.g., a value between 1 and 10). The driver (e.g., the user) may input the numeric value by pressing a designated button or area on the driver device corresponding to the particular value. Alternatively, the user may manually input the numeric value into dedicated entry fields presented on a display of the driver device (e.g., via a physical keyboard, a virtual keyboard, or a voice entry).
Additionally, or alternatively, the response to the queries may be a selection of one option out of multiple options. For example, for a query relating to a height of the vehicle and/or the driver seat from the ground, the options from which the driver may select the response may be “High,” “Medium,” or “Low.” The options may be displayed on the device, and the driver may select the option by pressing a designated button or area on the driver device corresponding to the particular option.
As shown by reference number 104, the prediction system may receive the driving data from the driver device (e.g., over a network, as described in more detail below). For example, the driver may interact with the driver device to submit responses to the queries, which may cause the driver device to transmit the driving data to the prediction system.
In some implementations, the prediction system may receive the driving data via passive input from the driver. For example, as shown by reference number 106, a driver (e.g., Driver2) may participate in a vehicle simulator that simulates operation of a vehicle, where the driving data may be obtained from the driver's simulated operation of the vehicle. The vehicle simulator may incorporate a steering wheel, a gas pedal, and a brake pedal for the driver to use during a simulation. Additionally, the vehicle simulator may incorporate a virtual reality (VR) headset so that the driver may have a more realistic driving experience. Alternatively, the vehicle simulator may incorporate a screen that displays the simulated driving view (e.g., first person view). Additionally, the vehicle simulator may incorporate any other mechanisms (e.g., hydraulic systems) to simulate driving conditions, such as tilting and/or shaking of the vehicle.
During a driving simulation, the vehicle simulator may present a simulated driving environment for the driver. For example, the simulated driving environment may include a roadway with other vehicles on the roadway and various traffic signals (e.g., traffic lights, stop signs, merges, etc.) along the route. The simulation may provide a specific route for the driver so as to lead the driver through various simulated conditions (e.g., local driving, with multiple turns and stops, highway driving at higher speeds, varying degrees of traffic, and different weather conditions). The vehicle simulator may include various sensors, such as in connection with the steering wheel, the gas pedal, and the brake pedal. For example, a sensor in connection with the steering wheel may measure the angular velocity at which the driver rotates the steering wheel. As another example, sensors in connection with the gas pedal and brake pedal may measure displacement of the pedals and/or force applied to the pedals. From such measurements, the vehicle simulator (e.g., one or more processors of the vehicle simulator) may determine simulated driving metrics, such as vehicle speed, acceleration, deceleration, centripetal force, centrifugal force, or the like. The simulated driving metrics may be representative of the driver's driving behavior in different driving categories.
As shown by reference number 108, the prediction system may receive, from the vehicle simulator, data corresponding to the simulated driving metrics. For example, the vehicle simulator may transmit the data after the driving simulation is complete and/or based on driver input (e.g., the driver selects an option to submit the data or a subset of the data to the prediction system). Alternatively, the vehicle simulator may transmit the data in real-time as the driving simulation is in progress (e.g., transmit blocks of data in intervals of 10 seconds).
As another example of passive input of driving data from the driver, as shown by reference number 110, the driver's actual driving performance and behavior may be monitored, for example, by an on-board device of a vehicle of a driver (e.g., Drivern). The on-board device may include or communicate with a navigation system that may track and/or measure actual driving metrics of the vehicle (e.g., via one or more sensors and/or devices). Similar to the vehicle simulator, the actual driving metrics may include, but are not limited to, vehicle speed, acceleration, deceleration, centripetal force, centrifugal force, or the like. Additionally, or alternatively, the actual driving metrics may be measured and/or determined via the driver device (e.g., mobile phone) of the driver while operating the vehicle. The actual driving metrics may be representative of the driver's driving behavior in the different driving categories. Utilizing data from actual driving behavior provides more accuracy than either simulated driving behavior or driver input on driving behavior because the data represents the way the driver actually would use any of the vehicles for which the system is determining compatibility.
As shown by reference number 112, the prediction system may receive, from the vehicle on-board device (and/or from the driver device), data corresponding to the actual driving metrics. For example, the vehicle on-board device may transmit the data after a particular route is completed (e.g., after the driver has turned the ignition off or the vehicle has been at a standstill for a set duration) and/or based on driver input (e.g., the driver selects an option presented on a display of the vehicle on-board device to submit the data or a subset of the data to the prediction system). Alternatively, the vehicle on-board device may transmit the data in real-time as the route is in progress (e.g., transmit blocks of data in intervals of 10 seconds). Additionally, or alternatively, the driver device may similarly transmit data after the route is completed, based on driver input, or in real-time when the route is in progress.
As explained above, the driving data received from the various sources may be in different forms (e.g., numeric ratings, numeric measurements, or text inputs). As such, as shown by reference number 114, the prediction system may convert the different forms of driving data into a common value system (e.g., into importance values representative of the importance of each driving category to the driving behavior of the driver) so that the driving data collected from the different sources may be more easily compared and associated with one another.
For example, when the driver directly provides input of importance values for different driving categories (e.g., 10, 7, and 7 for braking, acceleration, and handling, respectively, as shown in
When the driving data is in the form of metrics (e.g., simulated or actual), the prediction system may apply one or more rules to convert the metrics into importance values. For example, the prediction system may assign an importance value for a specific range of values of the metric, as defined in the rules. As an example, if the metrics indicate an average acceleration that is above 10 m/s2, then the prediction system may apply an importance value of 10, and if the average acceleration is below 1 m/s2, then the prediction system may apply an importance value of 1.
Additionally, or alternatively, after the importance values have been obtained, the prediction system may apply a tolerance to each importance value so that the driver profile has a range of importance values for each driving category. In some implementations, the tolerance may be a set value (e.g., 1) for all the driving categories. For example, an importance value of 7 would have a range of importance values from 6-8. Alternatively, for driving categories having greater importance to the driver (e.g., having a higher importance value), the tolerance value may be greater than for driving categories of less importance (e.g., having a lower tolerance value). For example, an importance value of 8 may have a tolerance value of 2, for a range of 6-10, whereas an importance value of 5 may have a tolerance value of 1, for a range of 4-6.
As shown by reference number 116, the prediction system may store the driving data (e.g., importance values or ranges of importance values) for each driver in a driver profile database as a driver profile under the driver's account. The driver's account may be associated with a driver identifier that uniquely identifies the driver.
Although
Additionally, or alternatively, the prediction system may use the simulated driving metrics and/or the actual driving metrics (e.g., without being converted to importance values) to adjust importance values for one or more of the driving categories input by the driver (e.g., the user) when creating a driver profile for the driver. For example, if the driver inputs a high importance value (e.g., 10) for acceleration, but the actual driving metrics indicate an average acceleration of only a moderate importance (e.g., 5 m/s2), the prediction system may adjust the importance value associated with the driver profile by a set amount. The adjustment amount may be based on one or more rules.
As an example, if the driving metrics (e.g., simulated and/or actual) fall within a specific range indicating a specific level of importance (e.g., less than 3 m/s2 indicating a low importance level, between 3 m/s2 and 7 m/s2 indicating a medium importance level, and/or greater than 7 m/s2 indicating a high level importance), then the prediction system may adjust the user-provided importance value by a set amount corresponding to the importance level. For example, for a low importance level, the prediction system may decrease the importance value for the particular category (e.g., acceleration) by 1 for a medium range of user-provided values (e.g., 4-7) or by 2 for a high range of user-provided values (e.g., 8-10). For a medium importance level, the prediction system may increase the importance value for the particular category by 1 for a low range of user-provided values (e.g., 1-3) or decrease the importance value by 1 for a high range of user-provided values (e.g., 8-10). For a high importance level, the prediction system may increase the importance value for the particular category by 1 for a medium range of user-provided values (e.g., 4-7) or by 2 for a low range of user-provided values (e.g., 1-3).
The adjustment to the importance values in one or more driving categories may affect the compatible vehicles with the user and/or the user's compatibility with a particular vehicle (e.g., a compatibility score with the vehicle, as described in more detail below in connection with
As shown by reference number 118, the prediction system may determine a driver archetype for each driver profile. The prediction system may determine the driver archetype based on different rules or conditions for the different types of driver archetypes. For example, each driver archetype may be based on a range of importance values for each driving category. If the driver profile has importance values that fall within the ranges of a particular driver archetype for a minimum number of the driving categories (e.g., all of the driving categories, 8 out of 10 driving categories, etc.), then the prediction system may apply that driver archetype to that driver profile.
As an example, a driver archetype of a “Safe” driver may have importance value ranges of 8-10 for braking, 6-8 for acceleration, and 7-9 for handling. A driver profile having importance values of 10, 7, and 7 for those respective categories would have a “Safe” driver archetype. When the driver profile has ranges of importance values for the different driving categories (as opposed to single values), the driver profile may be assigned a driver archetype where the ranges in the driving profile overlap the ranges of the driver archetype by a threshold amount (e.g., 100%, 75%, etc.). For example, a driver profile having ranges of 8-10 for braking, 5-7 for acceleration, and 8-10 for handling may be assigned the “Safe” driver archetype.
Other examples of driver archetypes may include “Luxury,” “Comfort,” “Sporty,” “City,” “Highway,” “Long Distance,” “Commuter,” etc. Each driver archetype may have multiple combinations of ranges corresponding to the multiple driving categories to be able to cover all different possible combinations of importance values (or ranges of importance values) in the driver profiles (e.g., so that each driver profile may be assigned a driver archetype). The driver archetype may be stored with the driver profile in the driver profile database and associated with the driver identifier.
As shown by reference number 120, the prediction system may determine one or more driver clusters in which drivers have common driver profiles. In some implementations, the prediction system may use a machine learning model (e.g., an unsupervised machine learning model) to determine the driver cluster(s), as described in more detail below in connection with
As another example, the prediction system may determine a driver cluster of drivers having importance values within a threshold range of each other for a minimum number of driving categories. Additionally, driver clusters may be refined based on the simulated driving metrics and/or the actual driving metrics. For example, if multiple drivers belong to a driver cluster based on similar provided importance values (e.g., importance values falling within a range of 8-10 for acceleration), the prediction system may break the driver cluster into sub-driving clusters in which the simulated driving metrics and/or the actual driving metrics indicate different levels of importance (e.g., low importance level, medium importance level, or high importance level).
As another example, the prediction system may determine a driver cluster of drivers requiring adaptive driving equipment (e.g., hand controls, swivel seating, wheelchair securement, etc.). The driver cluster may be for drivers requiring any adaptive driving equipment. Alternatively, there may be multiple driver clusters each for drivers requiring the same, specific type of adaptive driving equipment.
As another example, the prediction system may determine a driver cluster based on demographic information (e.g., sex and/or age group) and/or geographic location (e.g., zip code or drivers within a threshold distance of a common location) of the drivers. For example, all male drivers with an age between 25 and 40 and located in the same zip code may be in the same driver cluster.
Although the importance values are described with respect to
As shown in
As further shown by reference number 122, the responses to the queries may be in the form of numeric values (e.g., a value between 1 and 10). The driver may input the numeric value by pressing a designated button or area on the driver device corresponding to the particular value. Alternatively, the user may manually input the numeric value into dedicated entry fields presented on a display of the driver device (e.g., via a physical keyboard, a virtual keyboard, or a voice entry).
Additionally, or alternatively, the response to the queries may be a selection of one option out of multiple options. For example, for a query relating to a height of the vehicle and/or the driver seat from the ground, the options from which the driver may select the response may be “Too High,” “Just Right,” or “Too Low.” The options may be displayed on the device, and the driver may select the option by pressing a designated button or area on the driver device corresponding to the particular option. Additionally, the driver may input the driver's vehicle (e.g., make, model, and/or year), for example, in dedicated entry fields or selections from a list (e.g., a drop-down list) populated on the display of the driver device.
As shown by reference number 124, the prediction system may receive the performance data and the data indicating the vehicle information from the driver device (e.g., over a network). For example, the driver may interact with the driver device to submit responses to the queries, which may cause the driver device to transmit the driver data to the prediction system.
In some implementations, as shown by reference number 126, the performance of the vehicle of a driver (e.g., Drivern) may be measured and/or monitored, for example, by an on-board device of the vehicle. The on-board device may include or communicate with a navigation system that may track and/or measure actual driving metrics of the vehicle (e.g., via one or more sensors and/or devices). The actual driving metrics may include, but are not limited to, vehicle speed, acceleration, deceleration, centripetal force, centrifugal force, and the like. Additionally, or alternatively, the actual vehicle performance metrics may be measured and/or determined via the driver device (e.g., mobile phone) of the driver while operating the vehicle.
As shown by reference number 128, the prediction system may receive, from the on-board (and/or from the driver device), data corresponding to the performance metrics of the vehicle. For example, the vehicle on-board device may transmit the data after a particular route is completed (e.g., after the driver has turned the ignition has turned off or the vehicle has been at a standstill for a set duration) and/or based on driver input (e.g., the driver selects an option presented on a display of the vehicle on-board device to submit the data or a subset of the data to the prediction system). Alternatively, the vehicle on-board device may transmit the data in real-time as the route is in progress (e.g., transmit blocks of data in intervals of 10 seconds). Additionally, or alternatively, the driver device may similarly transmit data after the route is completed, based on driver input, or in real-time when the route is in progress. In some implementations, the vehicle performance metrics may be the same as the actual driving metrics (e.g., the prediction system may process and/or store the same data received from the on-board device and/or driver device under the driver profile and under the vehicle profile. Alternatively, the prediction system may receive, process, and/or store separate sets of data for the vehicle performance and for the actual driving behavior from the on-board device and/or the driver device.
In some implementations, as shown by reference number 130, the prediction system may obtain performance data for a plurality of vehicles from a vehicle review system (e.g., via a third party review website) from which the prediction system may extract performance values for different categories from the vehicle review system. For example, the prediction system may search the code or text associated with the third party review website for tags or keywords relating to the different categories, and extract values and/or grades associated with the tags or keywords. Obtaining performance data from the vehicle review system may provide access to a larger database of vehicles than just the vehicles of the drivers having accounts, which may be limited (e.g., in make, model, and/or year).
As shown by reference number 132, the prediction system may convert the different forms of performance data into a common value system (e.g., into performance values representative of the performance of the vehicle in each driving category) so that the vehicle performance data collected from the different sources may be more easily compared and associated with one another and other data (e.g., driver archetypes).
For example, when the driver directly provides input of performance values for different driving categories (e.g., 7, 7, and 9 for driver categories of braking, acceleration, and handling, respectively, as shown in
When the driving data is in the form of metrics, the prediction system may apply one or more rules to convert the metrics into performance values. For example, the prediction system may assign a performance value for a specific range of values of the metric, as defined in the rules. As an example, if the metrics indicate an average acceleration that is above 10 m/s2, then the prediction system may apply a performance importance value of 10, and if the average acceleration is below 1 m/s2, then the prediction system may apply a performance value of 1.
Additionally, or alternatively, after the performance values have been obtained, the prediction system may further apply a tolerance to each performance value so that the vehicle profile has a range of performance values for each driving category. In some implementations, the tolerance may be a set value (e.g., 1) for all the driving categories. For example, a performance value of 7 would have a range of importance values from 6-8. Alternatively, for driving categories having greater performance (e.g., having a higher performance value), the tolerance value may be greater than for driving categories having less performance (e.g., having a lower performance value). For example, a performance value of 8 may have a tolerance value of 2, for a range of 6-10, whereas a performance value of 5 may have a tolerance value of 1, for a range of 4-6.
In implementations when the performance data is obtained from a vehicle review system, if the reviews are on the same scale as the performance values (e.g., 1 to 10), then the prediction system may maintain the values extracted from the third party reviews. Additionally, or alternatively, if the reviews are on a different scale (e.g., 1 to 5), the prediction system may extrapolate the extracted values to be on the same scale. Additionally, or alternatively, where the extracted data is a letter grade (e.g., A, B, C, D, F), then each letter grade may be assigned a performance value (e.g., A=10, B=8, etc.).
As shown by reference number 134, the prediction system may store the performance data (e.g., performance values or ranges of performance values) for each vehicle in a vehicle profile database as a vehicle profile. The vehicle profile may be associated with a vehicle identifier (e.g., make, model, and/or year of the vehicle).
In some scenarios, the vehicle profile database may have gaps in the vehicles (e.g., vehicle profiles) stored. For example, the vehicle profile database may have vehicles of only a certain year. In such instances, the prediction system may extrapolate the vehicle data for a vehicle of one year to a vehicle of the same make and model for another year that is not included in the vehicle profile database. If the years are within a threshold distance of each other (e.g., 3 years), then the prediction system may use the same vehicle performance values for the vehicle profile of the missing vehicle. If the years are outside of the threshold distance, then the prediction system may apply an adjustment factor. For example, if the vehicle profile in the vehicle profile database is for a vehicle from 2017, then the prediction system may adjust the performance values for a vehicle from 2021 by a value of 0.5 for one or more of the driving categories. The value of the adjustment factor may depend on how far apart the years are (e.g., the greater the difference between years, the greater the adjustment factor may be).
Although
In some implementations, the prediction system may determine vehicle clusters in which vehicles have common vehicle profiles. The prediction system may determine the vehicle cluster(s) based on one or more rules. For example, the prediction system may determine a vehicle cluster of all vehicles having the same make or model. Additionally, or alternatively, the prediction system may determine a vehicle cluster of vehicles having performance values within a threshold range of each other (e.g., within 1 value) for a minimum number of vehicle categories (e.g., all of the driving categories, 8 out of 10 driving categories, etc.). Additionally, or alternatively, the prediction system may use a machine learning model (e.g., an unsupervised machine learning model) to determine the vehicle cluster(s), as described in more detail below in connection with
As shown by reference number 136, the prediction system may generate a data structure indicating a degree of association between a vehicle (or a vehicle cluster) having a vehicle profile in the vehicle profile database, and each driver cluster based on the importance values associated with the drivers in the driver clusters and the performance values of the vehicle (or vehicle cluster). For example, the prediction system may determine and assign a strength of relationship (e.g., as indicated by a strength score) in the data structure between the vehicle (or the vehicle cluster) and a driver archetype associated with each driver cluster based on a proximity between the performance values and the corresponding importance values in the driving categories. For example, as shown in
In some implementations, the prediction system may also generate data structures between driver archetypes that represent how similar those driver archetypes are with each other. For example, a “Luxury” driver archetype may have moderate similarity with a “Comfort” driver archetype, and a “Sporty” driver archetype may have a weak similarity with a “Safe” driver archetype. Additionally, or alternatively, the prediction system may further generate data structures between different vehicles that indicate how similar the vehicles are with each other. For example, the data structure may indicate a strong similarity between a Honda Civic and a Toyota Camry, but a weak similarity between either a Honda Civic or a Toyota Camry with an Acura MDX. As such, data (e.g., importance values) from a certain driver archetype may be used for another driver archetype having a strong similarity (e.g., where there is more data with respect to the driver archetype). Similarly, data from a certain vehicle (e.g., performance values) from a certain vehicle may be used for another vehicle having a strong similarity. As described above, the degree of similarity may be determined by how close the importance values or performance values of one item or group are with the corresponding importance values or performance values of the other item or group in the relationship. Additionally, or alternatively, the prediction system may determine the degrees of association (e.g., between a driver cluster/driver archetype and a vehicle, between one vehicle and another vehicle, or between one driver archetype and another driver archetype) via a machine learning model, such as described in more detail below in connection with
As shown in
In some implementations, as shown by reference number 142, using the user preference data, the prediction system may determine a driver cluster to which the user belongs. For example, the prediction system may access the driver profile database and search for driver profiles that have similar importance ratings as the user, which the prediction system may determine based on one or more rules. As an example, for a particular driving category, the prediction system may determine that the respective importance values from the user preference data and from the one or more driver profiles are similar if they fall within the same range of values. For example, the prediction system may determine that, in a category for braking, the importance values are similar if they fall within a range of 8-10. The prediction system may determine that the user belongs in a particular driver cluster if the user preference data has similar importance ratings as the driver cluster in a threshold number of categories.
Additionally, or alternatively, the prediction system may use the user preference data to determine a driver archetype in which the user falls. For example, if the user preference data indicates importance values that fall within the ranges of a particular driver archetype for a minimum number of the driving categories (e.g., all of the driving categories, 8 out of 10 driving categories, etc.), then the prediction system may apply that driver archetype to the user. As an example, a driver archetype of a “Safe” driver may have importance value ranges of 8-10 for braking, 6-8 for acceleration, and 7-9 for handling. User preference data indicating importance values of 10, 7, and 7 would have a “Safe” driver archetype. In some implementations, the prediction system may store the user preference data in the driver profile database under the user's account.
Alternatively, the user may have an account associated with a driver profile and a driver identifier stored in the driver profile database (e.g., Driver1, Driver2 . . . Drivern). In such a scenario, the prediction system may obtain the user's account via the user's driver identifier, which may be received from the user device (e.g., when the user logs into the user's account via the application) and obtain the user's driver profile, which includes the driver's driving data (e.g., importance values) and/or the driving archetype.
As shown by reference number 144, the prediction system may identify one or more compatible vehicles for the user based on the driver cluster and/or driver archetype of the driver and the data structure. For example, the prediction system may identify vehicles having strength values in the data structure above a threshold value (e.g., strength value of at least 9). As shown in
As shown in
As shown by reference number 156, the prediction system may transmit, to the user device, data corresponding to the third party information, such as the name, address, contact information, and inventory including the selected vehicle. As shown by reference number 158, the prediction system may transmit, to a third party device of any identified third parties, data associated with the selected vehicle and/or the contact information of the user. As such, the third party entity may anticipate interest in particular vehicles. Additionally, even if the third party entity does not have the suggested vehicle in inventory, the third party entity may be able to use the information to determine which vehicles are more popular and therefore attempt to obtain those vehicles for the inventory.
As explained above, the system utilizes data related to drivers' driving behavior (e.g., importance values) and associates that data with actual performance data of vehicles (e.g., performance values). By determining and applying relationships between the data, the system may provide greater accuracy in predicting compatibility between a consumer (e.g., a driver) and vehicles (e.g., compared to systems only considering consumer preferences and vehicle statistics).
As indicated above,
As shown in
Additionally, the prediction system may also receive, from the user device, a driver identifier associated with an account of the user. The driver identifier may automatically be associated with the user's compatibility query, for example, by way of the user logging into the user's account (e.g., via the application) to initiate the query. Alternatively, the user may manually input the driver identifier, for example, before, after or at the same time as the vehicle information. From the driver identifier, the prediction system may access the user's account and the driver information associated with the user, including a driver archetype assigned to the user based on the driving data provided to the prediction system, as described elsewhere herein. As shown by reference number 215, the prediction system may identify the driver archetype associated with the user (e.g., based on the driver profile). Alternatively, when the driver archetype of the user is not known or stored in the driver profile database, the prediction system may transmit data corresponding to a series of queries regarding the user's driver behavior in different driving categories (e.g., as described above in connection with reference number 102 and shown in
As shown in
As shown by reference number 225, based on the comparison, the prediction system may determine a compatibility score based on one or more rules. For example, the compatibility score may depend upon how close the performance values of the vehicle and the importance values associated with the driver archetype are within each other across the different categories. As an example, if the performance values and the importance values are within a threshold amount for all the driving categories, the compatibility score may be 10. If the performance values and the importance values are outside the threshold amount for all the driving categories, the compatibility score may be 0. In some implementations, the compatibility score may be determined based on a machine learning model, as described in more detail below in connection with
In some implementations, after the user has actually driven the vehicle (e.g., after purchasing the vehicle, renting the vehicle, or test driving the vehicle), the prediction system may transmit, to the user device, data indicating one or more queries requesting the user's satisfaction with the vehicle in one or more driving categories (e.g., braking, acceleration, handling, etc.). For example, the user device may display dedicated entry fields for the user to select and/or enter a satisfaction score (e.g., a numerical value between 1 and 10). Additionally, or alternatively, the prediction system may transmit the queries to a third party device, such as at a dealership or a rental agency, via which the responses to the queries may be input by an agent of the third party entity. In implementations in which the compatibility score is determined using a machine learning model, the prediction system may use the satisfaction score to retrain the machine learning model (e.g., if the satisfaction score differs from the compatibility score by a threshold amount).
In some implementations, when the user has not provided a vehicle, such as in example 100 described above, the prediction system may calculate compatibility scores for all of the vehicles having vehicle profiles in the vehicle profile database. Alternatively, the prediction system may determine a subset of the vehicles determined to be compatible with the user (e.g., based on the user preference data as explained above) and provide data indicating the compatible vehicles to the user device in order of compatibility (e.g., the vehicles with the highest compatibility score first).
As explained above, the system utilizes driver archetypes, for which data (e.g., importance values) has been collected, processed, and stored, to compare with performance data of vehicles (e.g., performance values) to determine compatibility scores. The compatibility scores provide a quantifiable metric to determine compatibility between a consumer (e.g., a driver) and a particular vehicle.
As indicated above,
As shown by reference number 305, a machine learning model may be trained using a set of observations. The set of observations may be obtained from training data (e.g., historical data), such as data gathered during one or more processes described herein. In some implementations, the machine learning system may receive the set of observations (e.g., as input) from a user device, a driver device, a prediction system, a driver profile database, and/or a vehicle profile database, as described elsewhere herein.
As shown by reference number 310, the set of observations includes a feature set. The feature set may include a set of variables, and a variable may be referred to as a feature. A specific observation may include a set of variable values (or feature values) corresponding to the set of variables. In some implementations, the machine learning system may determine variables for a set of observations and/or variable values for a specific observation based on input received from the user or driver device, the prediction system, the driver profile database, and/or the vehicle profile database. For example, the machine learning system may identify a feature set (e.g., one or more features and/or feature values) by extracting the feature set from structured data, by performing natural language processing to extract the feature set from unstructured data, and/or by receiving input from an operator.
As an example, a feature set for a set of observations may include driving data (e.g., importance values in a plurality of categories indicating a driver's driving behavior), driver preference data (e.g., importance values in the plurality of categories indicating the driver's driving preferences), a vehicle (e.g., a selected vehicle by the driver from one or more suggested vehicles), and so on. As shown, for a first observation, the first feature may have a value of “10, 7, 7” (representative of importance values, such as those converted from actual driving metrics, in driving categories such as braking, acceleration, and handling), the second feature may have a value of “8, 8, 8” (representative of importance values in the same driving categories as in the first feature set), the third feature may have a value of “Toyota Camry,” and so on. These features and feature values are provided as examples, and may differ in other examples. For example, the feature set may include one or more of the following features: driver archetypes (e.g., casual driver, sporty driver, comfort driver, safe driver, luxury driver, etc.), vehicle performance data (e.g., performance values of vehicles having vehicle profiles stored in the vehicle profile database) and/or vehicle archetypes or categories (e.g., sports, luxury, off-roading, coupe, convertible, sedan, etc.).
In some implementations, the observations used to train a machine learning model may be user-specific. For example, a machine learning model may be trained for and/or applied to a particular user or driver, and the observations may be based on driving behavior and/or driving preferences associated with that particular user or driver. Alternatively, the observations used to train a machine learning model may be associated with other drivers obtained from the driver profile database and associated with respective driver identifiers. For example, the observations may be based on driving behavior of all drivers having accounts stored in the driver profile database. Alternatively, the observations may be based on driving behavior of a subset of drivers, such as one or more clusters of users to which the particular user or driver belongs (e.g., based on specific common characteristics, as described below). Thus, the prediction system and/or the machine learning system may train multiple machine learning models for different users/drivers and/or clusters of drivers, and may select a machine learning model to be applied to determine suggested categories for a user/driver based on the user/driver and/or a cluster to which the user/driver belongs.
As shown by reference number 315, the set of observations may be associated with a target variable. The target variable may represent a variable having a numeric value, may represent a variable having a numeric value that falls within a range of values or has some discrete possible values, may represent a variable that is selectable from one of multiple options (e.g., one of multiples classes, classifications, or labels) and/or may represent a variable having a Boolean value. A target variable may be associated with a target variable value, and a target variable value may be specific to an observation. In example 300, the target variable is a compatibility score (e.g., a score indicating a level of compatibility between the user/driver and the vehicle in the feature set), which has a value of “9” for the first observation.
The target variable may represent a value that a machine learning model is being trained to predict, and the feature set may represent the variables that are input to a trained machine learning model to predict a value for the target variable. The set of observations may include target variable values so that the machine learning model can be trained to recognize patterns in the feature set that lead to a target variable value. A machine learning model that is trained to predict a target variable value may be referred to as a supervised learning model.
In the supervised learning model shown in
In some implementations, the machine learning model may be trained on a set of observations that do not include a target variable. This may be referred to as an unsupervised learning model. In this case, the machine learning model may learn patterns from the set of observations without labeling or supervision, and may provide output that indicates such patterns, such as by using clustering and/or association to identify related groups of items within the set of observations.
As shown by reference number 320, the machine learning system may train a machine learning model using the set of observations and using one or more machine learning algorithms, such as a regression algorithm, a decision tree algorithm, a neural network algorithm, a k-nearest neighbor algorithm, a support vector machine algorithm, or the like. After training, the machine learning system may store the machine learning model as a trained machine learning model 325 to be used to analyze new observations.
As shown by reference number 330, the machine learning system may apply the trained machine learning model 325 to a new observation, such as by receiving a new observation and inputting the new observation to the trained machine learning model 325. As shown, the new observation may include a first feature of “8, 8, 8,” a second feature of “8, 8, 8,” a third feature of “Toyota Camry,” and so on, as an example. The machine learning system may apply the trained machine learning model 325 to the new observation to generate an output (e.g., a result). The type of output may depend on the type of machine learning model and/or the type of machine learning task being performed. For example, the output may include a predicted value of a target variable, such as when supervised learning is employed.
As an example of a supervised learning model, the trained machine learning model 325 may predict a value of “10” for the interaction category for the new observation, as shown by reference number 335. Based on this prediction, the machine learning system may provide a first recommendation. The first recommendation may include, for example, a compatibility score representative of the compatibility between the user and a particular vehicle. In some implementations, the machine learning model may determine, for each vehicle out of a plurality of vehicles, a compatibility score associated with that vehicle. For example, the machine learning model may determine a compatibility score for a first vehicle, a compatibility score for a second vehicle, and so on. The machine learning model may output data corresponding to a set of vehicles for which a corresponding set of compatibility scores satisfy a threshold (e.g., a minimum compatibility score of 9). These categories may be used by the processing system as compatible vehicles to provide to the user device, as described above in connection with
In some implementations, the prediction system and/or the machine learning system may train and/or apply an unsupervised machine learning model, such as to cluster drivers or to cluster vehicles. To cluster drivers, the observations may include driver archetypes, demographic information (e.g., sex and/or age group), geographic location (e.g., zip code or drivers within a threshold distance of a common location) of the drivers, and/or use of adaptive driving equipment, among other examples. To cluster vehicles, the observations may include a make and/or model of the vehicles, among other examples. In these cases, the output of the machine learning model may include information that identifies a cluster to which a new observation belongs and/or information that indicates a degree of similarity between the new observation and one or more other observations. As an example of an unsupervised learning model, the trained machine learning model 325 may classify (e.g., cluster) the new observation in a cluster, as shown by reference number 340. The observations within a cluster may have a threshold degree of similarity. For example, the drivers in the cluster of drivers may have the same driver archetype and/or driver profiles having similar driving data and/or driver preference data (e.g., importance values within threshold amounts of each other in a threshold number of driving categories, as described elsewhere herein). Additionally, the clusters of drivers may be refined based on one or more other similarities, such as the same sex (e.g., all male), the same age group (e.g., all between the ages of 25-40), and/or the same geographic location (e.g., zip code). As another example, the vehicles in the cluster of vehicles may have similar vehicle profiles (e.g., performance values within threshold amounts of each other in a threshold number of driving categories, as described elsewhere herein). Additionally, the clusters of drivers may be refined based on one or more other similarities, such as the same make, model, and within a same group of years (e.g., 2018-2021).
In this way, the machine learning system may apply a rigorous and automated process to provide suggestions of categories for interactions between the user and the terminal. The machine learning system enables recognition and/or identification of tens, hundreds, thousands, or millions of features and/or feature values for tens, hundreds, thousands, or millions of observations, thereby increasing accuracy and consistency and reducing delay associated with providing compatibility scores for drivers with particular vehicles relative to requiring computing resources to be allocated for tens, hundreds, or thousands of operators to manually provide compatibility scores for the drivers with the particular vehicles using the features or feature values.
As indicated above,
The prediction system 405 includes one or more devices capable of receiving, generating, storing, processing, providing, and/or routing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The prediction system 405 may include a communication device and/or a computing device. For example, the prediction system 405 may include a server, such as an application server, a client server, a web server, a database server, a host server, or a server in a cloud computing system. In some implementations, the prediction system 405 includes computing hardware used in a cloud computing environment.
The driver profile database 410 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The driver profile database 410 may include a communication device and/or a computing device. For example, the driver profile database 410 may include a data structure, a database, a data source, a server, a database server, an application server, a client server, a web server, a host server, a virtual server (e.g., executing on computing hardware), a server in a cloud computing system, a device that includes computing hardware used in a cloud computing environment, or a similar type of device. As an example, the driver profile database 410 may store account information, including an account identifier, of one or more drivers. The account information may include driving data for each driver, such as driving behavior measured during vehicle operation and a plurality of importance values corresponding to a plurality of driving categories associated with the driving behavior. The account information may also include each driver's contact information.
The vehicle profile database 415 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The vehicle profile database 415 may include a communication device and/or a computing device. For example, the vehicle profile database 415 may include a data structure, a database, a data source, a server, a database server, an application server, a client server, a web server, a host server, a virtual server (e.g., executing on computing hardware), a server in a cloud computing system, a device that includes computing hardware used in a cloud computing environment, or a similar type of device. As an example, the vehicle profile database 415 may store vehicle information, including a vehicle identifier (e.g., a make and/or a model), of one or more vehicles. The vehicle information may include, for each vehicle, data indicating a plurality of performance values corresponding to a plurality of driving categories.
The user or driver device 420 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The user or driver device 420 may include a communication device and/or a computing device. For example, the user or driver device 420 may include a wireless communication device, a mobile phone, a user equipment, a laptop computer, a tablet computer, a desktop computer, a gaming console, a set-top box, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, a head mounted display, or a virtual reality headset), or a similar type of device. In some implementations, a user device and a driver device may be the same device. In some implementations, a user device and a driver device may be different devices.
The vehicle on-board device 425 may include one or more communication components (e.g., one or more wireless communication components and/or one or more wired communication components) to communicate with one or more other devices of
The vehicle on-board device 425 may also include or communicate with a navigation system that includes one or more devices capable of determining and/or outputting route information for navigating a route, as described elsewhere herein. For example, the navigation system may include a global navigation satellite system (GNSS) device, a Global Positioning System (GPS) device, or the like. Additionally, or alternatively, the navigation system may be integrated into the user or driver device 420.
The vehicle simulator 430 may include one or more devices capable of receiving, determining, processing, storing, and/or providing information associated with a virtual reality (VR) environment (e.g., a VR driving environment). For example, the vehicle simulator 430 may include a server device (e.g., a host server, a web server, an application server, etc.), a cloud device, a data center device, or a similar device. In some implementations, the vehicle simulator 430 may be associated with a VR program that includes a VR driving environment (e.g., an environment in which a user operates a vehicle). The VR program may be a computer program designed to perform a group of coordinated functions, tasks, or activities for the vehicle simulator 430. For example, the VR program may integrate the vehicle simulator 430 with a graphical user interface (GUI) of the vehicle simulator 430.
The vehicle simulator 430 may also include one or more vehicle components, such as a steering wheel, a gas pedal, and a brake pedal. The vehicle simulator 430 may also include one or more sensors in connection with the steering, wheel, the gas pedal, and the brake pedal. For example, a sensor in connection with the steering wheel may measure the angular velocity at which a user rotates the steering wheel. As another example, sensors in connection with the gas pedal and brake pedal may measure displacement of the pedals and/or force applied to the pedals. From such measurements, the vehicle simulator 430 may determine simulated driving metrics, such as vehicle speed, acceleration, deceleration, centripetal force, centrifugal force, and the like and/or transmit the measurements to the prediction system 405 to determine such metrics. Additionally, the vehicle simulator 430 may incorporate any other mechanisms (e.g., hydraulic systems) to simulate driving conditions, such as tilting and/or shaking of the vehicle.
The vehicle review system 435 includes one or more devices capable of receiving, generating, storing, processing, providing, and/or routing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The vehicle review system 435 may include a communication device and/or a computing device. For example, the vehicle review system 435 may include a server, such as an application server, a client server, a web server, a database server, a host server, or a server in a cloud computing system. In some implementations, the vehicle review system 435 includes computing hardware used in a cloud computing environment.
The third party entity database 440 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The third party entity database 440 may include a communication device and/or a computing device. For example, the third party entity database 440 may include a data structure, a database, a data source, a server, a database server, an application server, a client server, a web server, a host server, a virtual server (e.g., executing on computing hardware), a server in a cloud computing system, a device that includes computing hardware used in a cloud computing environment, or a similar type of device. As an example, the third party entity database 440 may store third party entity information, including a third party identifier, of one or more third party entities (e.g., a dealership or a rental agency). The third party entity information may include data corresponding to inventory of each third party entity (e.g., vehicle inventory). The third party entity information may also include the geographic location (e.g., address, zip code, and/or geographic coordinate) of each third party entity.
The third party device 445 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with predicting driver-vehicle compatibility, as described elsewhere herein. The third party device 445 may include a communication device and/or a computing device. For example, the third party device 445 may include a wireless communication device, a user equipment, a laptop computer, a tablet computer, a desktop computer, or a similar type of device.
The network 450 includes one or more wired and/or wireless networks. For example, the network 450 may include a wireless wide area network (e.g., a cellular network or a public land mobile network), a local area network (e.g., a wired local area network or a wireless local area network (WLAN), such as a Wi-Fi network), a personal area network (e.g., a Bluetooth network), a near-field communication network, a telephone network, a private network, the Internet, and/or a combination of these or other types of networks. The network 450 enables communication among the devices of environment 400.
The number and arrangement of devices and networks shown in
Bus 510 includes one or more components that enable wired and/or wireless communication among the components of device 500. Bus 510 may couple together two or more components of
Memory 530 includes volatile and/or nonvolatile memory. For example, memory 530 may include random access memory (RAM), read only memory (ROM), a hard disk drive, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory). Memory 530 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and/or removable memory (e.g., removable via a universal serial bus connection). Memory 530 may be a non-transitory computer-readable medium. Memory 530 stores information, instructions, and/or software (e.g., one or more software applications) related to the operation of device 500. In some implementations, memory 530 includes one or more memories that are coupled to one or more processors (e.g., processor 520), such as via bus 510.
Input component 540 enables device 500 to receive input, such as user input and/or sensed input. For example, input component 540 may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system sensor, an accelerometer, a gyroscope, and/or an actuator. Output component 550 enables device 500 to provide output, such as via a display, a speaker, and/or a light-emitting diode. Communication component 560 enables device 500 to communicate with other devices via a wired connection and/or a wireless connection. For example, communication component 560 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and/or an antenna.
Device 500 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 530) may store a set of instructions (e.g., one or more instructions or code) for execution by processor 520. Processor 520 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, execution of the set of instructions, by one or more processors 520, causes the one or more processors 520 and/or the device 500 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry is used instead of or in combination with the instructions to perform one or more operations or processes described herein. Additionally, or alternatively, processor 520 may be configured to perform one or more operations or processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
The number and arrangement of components shown in
As shown in
Although
As shown in
Although
The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications may be made in light of the above disclosure or may be acquired from practice of the implementations.
As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It will be apparent that systems and/or methods described herein may be implemented in different forms of hardware, firmware, and/or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods are described herein without reference to specific software code—it being understood that software and hardware can be used to implement the systems and/or methods based on the description herein.
As used herein, satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.
Although particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set. As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.
No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and/or,” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of”).
