DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/18/2025 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-11, 14, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (US 20190012603 A1, published 01/10/2019), hereinafter Miller, in view of Vardharajan (US 20210179125 A1, published 06/17/2021) in further view of Toprak et al. (US 20170337573 A1, published 11/23/2017), hereinafter Toprak.
Regarding claim 1, Miller teaches the claim comprising:
A system for predicting driver-vehicle compatibility using machine learning, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to (Miller Figs. 1-3; abs. A system includes a processor configured to wirelessly receive data indicating vehicle-feature usage for an individual vehicle. The processor is also configured to aggregate received data to form a feature-usage customer profile defining feature preferences. The processor is further configured to select vehicles associated with a customer-classification, including predefined feature-usage characteristics, the customer-classification determined based on a correlation between the predefined feature-usage characteristics and the aggregated data in the feature-usage profile defining feature preferences; [0029], a general purpose processor may be temporarily enabled as a special purpose processor for the purpose of executing some or all of the exemplary methods shown by these figures. When executing code providing instructions to perform some or all steps of the method, the processor may be temporarily repurposed as a special purpose processor, until such time as the method is completed; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations):
receive, from an on-board device of a vehicle or from a vehicle simulator, driving data for a plurality of drivers, wherein the driving data indicates, for at least a portion of the plurality of drivers, driving behavior and a plurality of importance values corresponding to a plurality of driving categories associated with the driving behavior, wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle, and wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle; 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 (Miller Figs. 1-3; [0013], FIG. 1 illustrates an example block topology for a vehicle based computing system 1 (VCS) for a vehicle 31; [0014], In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor allows onboard processing of commands and routines; [0020], Data may be communicated between CPU 3 and network 61; [0020], Data may be communicated between CPU 3 and network 61; [0027], exemplary processes executed by a vehicle computing system located in a vehicle; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.);
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; generate a data structure that indicates a strength of relationship score 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 (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1); claim 8, compare the weighted values of each vehicle feature to weighted values associated with the selected vehicles);
receive, in real-time, 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; adjust at least one importance value based on the data measured during vehicle operation (Miller Figs. 1-3; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years. Thus, even though 4WD might be one of the safety recommendations associated with “safe” driving, this particular feature is either unimportant to the driver, or the driver may have never known the feature existed. While an assumption may need to be made, assuming that the driver simply does not care about 4WD will allow a vehicle recommendation to focus on features that may be more appealing to this particular driver; [0034], FIG. 2 shows an illustrative process for vehicle system usage monitoring. This illustrative system gathers vehicle driving history and vehicle-use pattern recognition to determine patterns between customers' driving data and customers' desired attributes. This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis; [0049], a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 ideal vehicle importance));
determine a driver cluster, of the plurality of driver clusters, to which the user belongs based on the driver preference data and the at least one adjusted importance value; determine one or more compatible vehicles for the user based on the driver cluster and the data structure; and output vehicle information that indicates the one or more compatible vehicles (Miller Figs. 1-3; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044-0045], For features that can be measured in terms of “use,” the weighting correlation could be based on frequency of usage (times/drive, times/month, etc.). For features that are more loosely defined, such as “acceleration preference,” the weighting could be based on commonality of occurrence, e.g., how many times does the user accelerate aggressively from a stopped position; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles; a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 ideal vehicle importance); [0052], The process may determine a point in a vehicle life-cycle at which to recommend a new vehicle, or the customer may actually request recommendations at any particular time. The recommendation data can also be sent to dealers or advertisers who can tailor offerings based on the recommendation, so the customer only receives offers and mail pertaining to vehicles the customer might most likely want)
However, Miller fails to expressly disclose wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios. In the same field of endeavor, Vardharajan teaches:
wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios (Vardharajan Figs. 1-6; [0014], a system can capture driving information for a driver by monitoring vehicle context and control information during a vehicle driving session. The system can generate a personalized driving style profile for the driver based on the driving information from the driving session; [0029], FIG. 2A is a block diagram illustrating an example, non-limiting embodiment of a system determining personalized driving style profiles; factors as vehicle acceleration, deceleration, signaling, distances from other vehicles or objects or traffic markers, lane changing, reversing, parking, and/or road conditions; [0030], The DPS 230 can use this additional information to build a context for the driving information that is captured during the real-world driving session; [0031], the DPS 230 can capture this driving information via a simulated vehicle 220 and/or simulated driving; Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes; the simulated vehicle can be a specialized simulator device; [0032], the DPS 230 can analyze the driving profile information that has been captured during the vehicle driving session, whether the driving profile information is captured via a real vehicle 220, a simulator vehicle 220, a software-based simulation, or a combination of these tools; The DPS 230 can use a machine learning based application or a machine learning engine. The DPS 230 can digest the driving information from the vehicle driving session into a set of key driving style parameter values for this driver 210. The key driving style parameters can be collated into a personalized driving style profile; [0040], The personalized driving style profile is portable; [0041], FIG. 2C depicts an illustrative embodiment of a method in accordance with various aspects described herein. The method 260 is an illustrative embodiment of a process for determining a personalized driving style profile for a driver and providing this profile for use at an autonomous vehicle when the driver becomes a passenger in the autonomous vehicle. In step 262, a driving profile server can capture driving information as a driver engages in a vehicle driving session. The driving session can include actual real-world driving of a vehicle, driving of a vehicle simulator, interaction with vehicle simulation software, or a combination of these approaches; [0090], the driving profile server 230 can use machine learning to determine a personalized driving style profile for a driver based on driving style information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios as suggested in Vardharajan into Miller. Doing so would be desirable because drivers may know, first hand, the complexity, potential hazards, and “unwritten” rules of driving that they have personally relied upon for achieving safety, comfort, efficiency, and “driving the right way” (see Vardharajan [0028]). The system of Vardharajan would improve the system of Miller by providing a portable driver profile (see Vardharajan [0040]), that captures additional driver in additional environments, both real and simulated (see Vardharajan [0029-0032]), useable for machine learning (see Vardharajan [0090]). Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes. Whereas achieving this range of driving situations can be impractical using real-world driving of an actual vehicle 220. Simulated driving also allows for capture of driving information in a standardized way that can make analysis easier and more predictable (see Vardharajan [0031]).
However, Miller in view of Vardharajan fails to expressly disclose receive, in real-time, driver preference data for a user, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the user for each driving category of the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation. In the same field of endeavor, Toprak teaches:
receive, in real-time, driver preference data for a user, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the user for each driving category of the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation (Toprak Figs. 1-46; [0047], During vehicle operation, different sets of OBD data may be collected, including, but not limited to, vehicle performance data and engine malfunction warning data. Performance data of a vehicle may be related to diagnostics information, such as oxygen levels, vehicle speed, temperature, and/or the like, and may be collected by the VMSP; [0049], As shown by diagram 4000 of FIG. 40, for example, the VMSP (e.g., CarHub Connect app) may collect OBD data (e.g., PID/vehicle performance data, MIL/maintenance needs and events, and/or accident event data (e.g., IMU/collision event data)). OBD data and any other suitable data, such as time data, location data, user/operator data, weather data, traffic data, road type/condition data, any other suitable vehicle environment data, accident event data, and/or the like, which may be collected by any suitable VMSP subsystem associated with the vehicle (e.g., by a CarHub Connect app of a vehicle operator) may be combined with OBD data and processed by the VMSP to provide a CarProfile for the vehicle and/or a CarScore for the vehicle and/or a DriverScore for a particular operator. As shown, certain CarProfile data may be used in conjunction with Cartron to determine a vehicle recommendation. Performance data, such as acceleration profile data, speed profile data, braking profile data, fuel efficiency data, mileage data, O2 sensor data, and/or the like for a certain vehicle and/or operator, and/or direct service needs data (e.g., OEM error decoding data) may be provided as at least a portion of CarProfile data. Quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs match the user's actual operation behavior, then the Cartron profile prediction may be reinforced and maintained. However, if the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace; [0052], Cartron may be an application or platform product that may present a user with questions or any other suitable questionnaire or data collection interface, and, based upon the answers collected, may provide a profile of the user that may quantify the preferences of the user with regards to needs of a vehicle as well as their needs for specific vehicle types. The output of Cartron may integrate as an input to a CarHub Car Recommendation Engine (“CRE”) of the VMSP in order to provide the user with vehicles that may fit the user's needs and financial situation. Cartron may be accessed through the MyCar section of the CarHub product, and can also be accessed through the buying process of new and used cars on the CarHub platform (e.g., via the CHC app). For example, as shown by screens 1200-1500 of FIGS. 12-15, a Cartron test may include a collection of quantitative and qualitative questions for users, to which the answers may be used to create a profile of the needs of a user with respect to the ideal vehicle for them to drive (e.g., answers indicative of budget, preferred vehicle styles, values, financing, car age, and/or the like). The Cartron results may be combined with driving behavior quantified by the OBD data (e.g., via CarHub Connect) to validate that a particular vehicle fits to a particular user/driver. The Cartron results may also integrate directly with a vehicle configurator and new/used inventory in the geographic location of the user, as well as with vehicle alerts (e.g., to notify when vehicles are available in the future). Cartron can be accessed during the vehicle configuration process (e.g., a new/used vehicle search) in order to help users understand their vehicle needs; [0053], data from trim specifications along with trim feature ratings, in combination with user personality variable(s) and/or user personal values variable(s) and car feature preference data to provide for preferred trim features, may be used to determine a trim recommendation; [0063], As shown by screens 2500-3000 of FIGS. 25-30, the Marketplace product of the platform may provide a user with the ability to configure a new vehicle search for potential purchase using any suitable information; see also [0068], [0074], virtual test drives)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated receive, in real-time, driver preference data for a user, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the user for each driving category of the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation as suggested in Toprak into Miller in view of Vardharajan. Doing so would be desirable because conventional transactions between vehicle sellers and vehicle buyers have several disadvantages including, but not limited to, inefficient networking between potential parties to a vehicle transaction, inability to foster trust in the health of a vehicle, and/or inability to facilitate identification of a fair market price for a vehicle (see Toprak [0003]). Cartron may help to remove/overcome the burden of searching for a vehicle configuration, in particular for users who do not have a defined concept of what they need in a vehicle. Cartron can speed up the buying process by addressing the burden of searching through vehicles and making decisions on search criteria which may be needed before a vehicle configuration can be proposed (see Toprak [0052]). Additionally, quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace(see Toprak [0049]), thereby providing improved suggestions based on additional data points, which would enhance the car search process with suggestions that are better tailored to the user.
Regarding claim 4, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein the on-board device measures the driving behavior by monitoring or measuring performance of the vehicle of a corresponding one of the plurality of drivers (Miller Figs. 1-3; [0013], FIG. 1 illustrates an example block topology for a vehicle based computing system 1 (VCS) for a vehicle 31; [0014], In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor allows onboard processing of commands and routines; [0020], Data may be communicated between CPU 3 and network 61; [0027], exemplary processes executed by a vehicle computing system located in a vehicle; [0031], a system may classify driver groupings based on observed driving data and statistical pattern recognition; By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0034], FIG. 2 shows an illustrative process for vehicle system usage monitoring. This illustrative system gathers vehicle driving history and vehicle-use pattern recognition to determine patterns between customers' driving data and customers' desired attributes; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis; see also [0007-0008], [0042-0049])
Regarding claim 5, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 4, further comprising:
wherein the one or more processors are further configured to: determine, for each driving category, a condition, of a plurality of conditions, that is satisfied by one or more measurements related to the driving category, wherein an importance value is associated with the condition; and assign, for each driving category, the importance value associated with the condition (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1)).
Regarding claim 6, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1. Vardharajan further teaches:
wherein the vehicle simulator includes a steering wheel, a gas pedal, or a brake pedal (Vardharajan Figs. 1-6; [0029], FIG. 2A is a block diagram illustrating an example, non-limiting embodiment of a system determining personalized driving style profiles; factors as vehicle acceleration, deceleration, signaling, distances from other vehicles or objects or traffic markers, lane changing, reversing, parking, and/or road conditions; [0031], the DPS 230 can capture this driving information via a simulated vehicle 220 (see Fig. 2A) and/or simulated driving; Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes; the simulated vehicle can be a specialized simulator device; [0032], the DPS 230 can analyze the driving profile information that has been captured during the vehicle driving session, whether the driving profile information is captured via a real vehicle 220, a simulator vehicle 220, a software-based simulation, or a combination of these tools; see also [0014], [0029], [0040-0041], [0090])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein the vehicle simulator includes a steering wheel, a gas pedal, or a brake pedal as suggested in Vardharajan into Miller. Doing so would be desirable because drivers may know, first hand, the complexity, potential hazards, and “unwritten” rules of driving that they have personally relied upon for achieving safety, comfort, efficiency, and “driving the right way” (see Vardharajan [0028]). The system of would improve the system of Miller by providing a portable driver profile (see Vardharajan [0040]), that captures additional driver behavior in both simulated and real environments (see Vardharajan [0029-0032]) useable for machine learning (see Vardharajan [0090]). Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes. Whereas achieving this range of driving situations can be impractical using real-world driving of an actual vehicle 220. Simulated driving also allows for capture of driving information in a standardized way that can make analysis easier and more predictable (see Vardharajan [0031]).
Regarding claim 7, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein one or more driver clusters, of the plurality of driver clusters, are generated based on at least one of: demographic information common to the drivers in the one or more driver clusters; a geographic location associated with the drivers common to the drivers in the one or more driver clusters; or each driver in the one or more driver clusters requiring adaptive equipment for driving (Miller Figs. 1-3; [0008], choosing one of a plurality of customer groups based on correspondence between customer vehicle-attribute preference values associated with a customer profile and attribute-preference parameters defining each of the customer groups; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles; see also [0007], [0003], [0038-0044])
Regarding claim 8, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein one or more driver clusters, of the plurality of driver clusters, are generated based on combinations of driver importance values of the drivers in the one or more driver clusters (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1)).
Regarding claim 9, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein the one or more processors are further configured to: determine, using a second unsupervised machine learning model, a plurality of vehicle clusters for categorizing the plurality of vehicles, wherein each vehicle cluster is based on vehicle performance and the plurality of performance values, wherein the vehicle performance is measured during operation of each of the plurality of vehicles (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1)).
Regarding claim 10, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein each of the plurality of performance values indicates performance of a vehicle in association with a corresponding one of the plurality of driving categories (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1)).
Regarding claim 11, Miller teaches the claim comprising:
A method of predicting driver-vehicle compatibility, comprising (Miller Figs. 1-3; abs. A system includes a processor configured to wirelessly receive data indicating vehicle-feature usage for an individual vehicle. The processor is also configured to aggregate received data to form a feature-usage customer profile defining feature preferences. The processor is further configured to select vehicles associated with a customer-classification, including predefined feature-usage characteristics, the customer-classification determined based on a correlation between the predefined feature-usage characteristics and the aggregated data in the feature-usage profile defining feature preferences; [0029], a general purpose processor may be temporarily enabled as a special purpose processor for the purpose of executing some or all of the exemplary methods shown by these figures. When executing code providing instructions to perform some or all steps of the method, the processor may be temporarily repurposed as a special purpose processor, until such time as the method is completed; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations):
receiving, from an on-board device of a vehicle or from a vehicle simulator, driving data for a plurality of drivers, wherein the driving data indicates, for at least a portion of the plurality of drivers, driving behavior and a plurality of importance values corresponding to a plurality of driving categories associated with the driving behavior, wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle, and wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle; determining, 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 (Miller Figs. 1-3; [0013], FIG. 1 illustrates an example block topology for a vehicle based computing system 1 (VCS) for a vehicle 31; [0014], In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor allows onboard processing of commands and routines; [0020], Data may be communicated between CPU 3 and network 61; [0020], Data may be communicated between CPU 3 and network 61; [0027], exemplary processes executed by a vehicle computing system located in a vehicle; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.);
receiving, by a system and in real-time, driver preference data for a driver, 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; adjusting at least one importance value based on the data measured during vehicle operation (Miller Figs. 1-3; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years. Thus, even though 4WD might be one of the safety recommendations associated with “safe” driving, this particular feature is either unimportant to the driver, or the driver may have never known the feature existed. While an assumption may need to be made, assuming that the driver simply does not care about 4WD will allow a vehicle recommendation to focus on features that may be more appealing to this particular driver; [0034], FIG. 2 shows an illustrative process for vehicle system usage monitoring. This illustrative system gathers vehicle driving history and vehicle-use pattern recognition to determine patterns between customers' driving data and customers' desired attributes. This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis; [0049], a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 ideal vehicle importance));
associating, by the system and based on the plurality of driver clusters and the at least one adjusted importance value, the driver with a driver archetype, wherein data corresponding to the driver archetype indicates a combination of ranges of values for the plurality of driving categories, and wherein 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 (Miller Figs. 1-3; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years ([0038], monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.); [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044-0045], For features that can be measured in terms of “use,” the weighting correlation could be based on frequency of usage (times/drive, times/month, etc.). For features that are more loosely defined, such as “acceleration preference,” the weighting could be based on commonality of occurrence, e.g., how many times does the user accelerate aggressively from a stopped position; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles; a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 ideal vehicle importance));
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 (Miller Figs. 1-3; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044], Since a driver may exhibit multiple driving behavior patterns or driving types, weighting can also be used to further refine classifications; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches);
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 (Miller Figs. 1-3; [0006], a system includes a processor configured to wirelessly receive data indicating vehicle-feature usage for an individual vehicle. The processor is also configured to aggregate received data to form a feature-usage customer profile defining feature preferences. The processor is further configured to select vehicles associated with a customer-classification, including predefined feature-usage characteristics, the customer-classification determined based on a correlation between the predefined feature-usage characteristics and the aggregated data in the feature-usage profile defining feature preferences. The processor is also configured to compare the aggregated data to the selected vehicles to determine a vehicle having features preferred by a customer as indicated by the aggregated data in the feature-usage profile and recommend the determined vehicle to the customer; [0007], The processor is also configured to select vehicles driven by other customers having the same weighted customer vehicle-attribute preferences as the customer's vehicle-attribute preferences; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; [0048], the process can choose a vehicle based on which of the vehicles has the same ordered ranking of weightings (e.g., top down), or, for example, based on which of the vehicles has the closest total value of rankings (e.g., the total difference between customer weightings and vehicle-associated weightings; claim 8, compare the weighted values of each vehicle feature to weighted values associated with the selected vehicles);
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; and transmitting, by the system, data indicating the compatibility score (Miller Figs. 1-3; [0007], a system includes a processor configured to determine and weight a customer's vehicle-attribute preferences based on data received from the customer's vehicle indicating the customer's behavior; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0027], a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote computing system (e.g., and without limitation, a server) connected through the wireless device. Collectively, such systems may be referred to as vehicle associated computing systems (VACS). In certain embodiments particular components of the VACS may perform particular portions of a process depending on the particular implementation of the system; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044-0045], For features that can be measured in terms of “use,” the weighting correlation could be based on frequency of usage (times/drive, times/month, etc.). For features that are more loosely defined, such as “acceleration preference,” the weighting could be based on commonality of occurrence, e.g., how many times does the user accelerate aggressively from a stopped position; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 vehicle compatibility score); [0052], The process may determine a point in a vehicle life-cycle at which to recommend a new vehicle, or the customer may actually request recommendations at any particular time. The recommendation data can also be sent to dealers or advertisers who can tailor offerings based on the recommendation, so the customer only receives offers and mail pertaining to vehicles the customer might most likely want).
However, Miller fails to expressly disclose wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios. In the same field of endeavor, Vardharajan teaches:
wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios (Vardharajan Figs. 1-6; [0014], a system can capture driving information for a driver by monitoring vehicle context and control information during a vehicle driving session. The system can generate a personalized driving style profile for the driver based on the driving information from the driving session; [0029], FIG. 2A is a block diagram illustrating an example, non-limiting embodiment of a system determining personalized driving style profiles; factors as vehicle acceleration, deceleration, signaling, distances from other vehicles or objects or traffic markers, lane changing, reversing, parking, and/or road conditions; [0030], The DPS 230 can use this additional information to build a context for the driving information that is captured during the real-world driving session; [0031], the DPS 230 can capture this driving information via a simulated vehicle 220 and/or simulated driving; Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes; the simulated vehicle can be a specialized simulator device; [0032], the DPS 230 can analyze the driving profile information that has been captured during the vehicle driving session, whether the driving profile information is captured via a real vehicle 220, a simulator vehicle 220, a software-based simulation, or a combination of these tools; The DPS 230 can use a machine learning based application or a machine learning engine. The DPS 230 can digest the driving information from the vehicle driving session into a set of key driving style parameter values for this driver 210. The key driving style parameters can be collated into a personalized driving style profile; [0040], The personalized driving style profile is portable; [0041], FIG. 2C depicts an illustrative embodiment of a method in accordance with various aspects described herein. The method 260 is an illustrative embodiment of a process for determining a personalized driving style profile for a driver and providing this profile for use at an autonomous vehicle when the driver becomes a passenger in the autonomous vehicle. In step 262, a driving profile server can capture driving information as a driver engages in a vehicle driving session. The driving session can include actual real-world driving of a vehicle, driving of a vehicle simulator, interaction with vehicle simulation software, or a combination of these approaches; [0090], the driving profile server 230 can use machine learning to determine a personalized driving style profile for a driver based on driving style information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios as suggested in Vardharajan into Miller. Doing so would be desirable because drivers may know, first hand, the complexity, potential hazards, and “unwritten” rules of driving that they have personally relied upon for achieving safety, comfort, efficiency, and “driving the right way” (see Vardharajan [0028]). The system of would improve the system of Miller by providing a portable driver profile (see Vardharajan [0040]), that captures additional driver behavior in both simulated and real environments (see Vardharajan [0029-0032]) useable for machine learning (see Vardharajan [0090]). Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes. Whereas achieving this range of driving situations can be impractical using real-world driving of an actual vehicle 220. Simulated driving also allows for capture of driving information in a standardized way that can make analysis easier and more predictable (see Vardharajan [0031]).
However, Miller in view of Vardharajan fails to expressly disclose receiving, by a system and in real-time, driver preference data for a driver, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the driver for each driving category of the plurality of driving categories; adjusting at least one importance value input by the driver based on the data measured during vehicle operation. In the same field of endeavor, Toprak teaches:
receiving, by a system and in real-time, driver preference data for a driver, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the driver for each driving category of the plurality of driving categories; adjusting at least one importance value input by the driver based on the data measured during vehicle operation (Toprak Figs. 1-46; [0047], During vehicle operation, different sets of OBD data may be collected, including, but not limited to, vehicle performance data and engine malfunction warning data. Performance data of a vehicle may be related to diagnostics information, such as oxygen levels, vehicle speed, temperature, and/or the like, and may be collected by the VMSP; [0049], As shown by diagram 4000 of FIG. 40, for example, the VMSP (e.g., CarHub Connect app) may collect OBD data (e.g., PID/vehicle performance data, MIL/maintenance needs and events, and/or accident event data (e.g., IMU/collision event data)). OBD data and any other suitable data, such as time data, location data, user/operator data, weather data, traffic data, road type/condition data, any other suitable vehicle environment data, accident event data, and/or the like, which may be collected by any suitable VMSP subsystem associated with the vehicle (e.g., by a CarHub Connect app of a vehicle operator) may be combined with OBD data and processed by the VMSP to provide a CarProfile for the vehicle and/or a CarScore for the vehicle and/or a DriverScore for a particular operator. As shown, certain CarProfile data may be used in conjunction with Cartron to determine a vehicle recommendation. Performance data, such as acceleration profile data, speed profile data, braking profile data, fuel efficiency data, mileage data, O2 sensor data, and/or the like for a certain vehicle and/or operator, and/or direct service needs data (e.g., OEM error decoding data) may be provided as at least a portion of CarProfile data. Quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs match the user's actual operation behavior, then the Cartron profile prediction may be reinforced and maintained. However, if the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace; [0052], Cartron may be an application or platform product that may present a user with questions or any other suitable questionnaire or data collection interface, and, based upon the answers collected, may provide a profile of the user that may quantify the preferences of the user with regards to needs of a vehicle as well as their needs for specific vehicle types. The output of Cartron may integrate as an input to a CarHub Car Recommendation Engine (“CRE”) of the VMSP in order to provide the user with vehicles that may fit the user's needs and financial situation. Cartron may be accessed through the MyCar section of the CarHub product, and can also be accessed through the buying process of new and used cars on the CarHub platform (e.g., via the CHC app). For example, as shown by screens 1200-1500 of FIGS. 12-15, a Cartron test may include a collection of quantitative and qualitative questions for users, to which the answers may be used to create a profile of the needs of a user with respect to the ideal vehicle for them to drive (e.g., answers indicative of budget, preferred vehicle styles, values, financing, car age, and/or the like). The Cartron results may be combined with driving behavior quantified by the OBD data (e.g., via CarHub Connect) to validate that a particular vehicle fits to a particular user/driver. The Cartron results may also integrate directly with a vehicle configurator and new/used inventory in the geographic location of the user, as well as with vehicle alerts (e.g., to notify when vehicles are available in the future). Cartron can be accessed during the vehicle configuration process (e.g., a new/used vehicle search) in order to help users understand their vehicle needs; [0053], data from trim specifications along with trim feature ratings, in combination with user personality variable(s) and/or user personal values variable(s) and car feature preference data to provide for preferred trim features, may be used to determine a trim recommendation; [0063], As shown by screens 2500-3000 of FIGS. 25-30, the Marketplace product of the platform may provide a user with the ability to configure a new vehicle search for potential purchase using any suitable information; see also [0068], [0074], virtual test drives).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated receiving, by a system and in real-time, driver preference data for a driver, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the driver for each driving category of the plurality of driving categories; adjusting at least one importance value input by the driver based on the data measured during vehicle operation as suggested in Toprak into Miller in view of Vardharajan. Doing so would be desirable because conventional transactions between vehicle sellers and vehicle buyers have several disadvantages including, but not limited to, inefficient networking between potential parties to a vehicle transaction, inability to foster trust in the health of a vehicle, and/or inability to facilitate identification of a fair market price for a vehicle (see Toprak [0003]). Cartron may help to remove/overcome the burden of searching for a vehicle configuration, in particular for users who do not have a defined concept of what they need in a vehicle. Cartron can speed up the buying process by addressing the burden of searching through vehicles and making decisions on search criteria which may be needed before a vehicle configuration can be proposed (see Toprak [0052]). Additionally, quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace(see Toprak [0049]), thereby providing improved suggestions based on additional data points, which would enhance the car search process with suggestions that are better tailored to the user.
Regarding claim 14, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein the compatibility score is determined based on a machine learning model (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1 see Table 1 vehicle compatibility score)).
Regarding claim 16, Miller teaches the claim comprising:
A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to (Miller Figs. 1-3; abs. A system includes a processor configured to wirelessly receive data indicating vehicle-feature usage for an individual vehicle. The processor is also configured to aggregate received data to form a feature-usage customer profile defining feature preferences. The processor is further configured to select vehicles associated with a customer-classification, including predefined feature-usage characteristics, the customer-classification determined based on a correlation between the predefined feature-usage characteristics and the aggregated data in the feature-usage profile defining feature preferences; [0029], a general purpose processor may be temporarily enabled as a special purpose processor for the purpose of executing some or all of the exemplary methods shown by these figures. When executing code providing instructions to perform some or all steps of the method, the processor may be temporarily repurposed as a special purpose processor, until such time as the method is completed; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations):
receive, from an on-board device of a vehicle or from a vehicle simulator, driving data for a plurality of drivers, wherein the driving data indicates, for at least a portion of the plurality of drivers, driving behavior and a plurality of importance values corresponding to a plurality of driving categories associated with the driving behavior, wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle, and wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle; 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 (Miller Figs. 1-3; [0013], FIG. 1 illustrates an example block topology for a vehicle based computing system 1 (VCS) for a vehicle 31; [0014], In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor allows onboard processing of commands and routines; [0020], Data may be communicated between CPU 3 and network 61; [0020], Data may be communicated between CPU 3 and network 61; [0027], exemplary processes executed by a vehicle computing system located in a vehicle; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.);
obtain data corresponding to a plurality of driver archetypes, wherein the plurality of driver archetypes are based on the plurality of driver clusters, and 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 (Miller Figs. 1-3; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud; [0044-0045], For features that can be measured in terms of “use,” the weighting correlation could be based on frequency of usage (times/drive, times/month, etc.). For features that are more loosely defined, such as “acceleration preference,” the weighting could be based on commonality of occurrence, e.g., how many times does the user accelerate aggressively from a stopped position);
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; generate a data structure that indicates a corresponding strength of relationship score 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 (Miller Figs. 1-3; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters. It is even possible, for example, to determine which vehicle a person eventually selected, and fine tune groupings into which that person fell based on the actual vehicle purchased; [0034], This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time. The process detects 205 any usage of a designated monitored system or parameter, and logs 207 the usage accordingly. Consumable fuel usage, and similar variables, can also be logged periodically to build a record; [0041], it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; [0045], the weighting can be standardized in the sense that if a customer uses a “usable” feature more frequently than 90% of observed customers, that feature could be given a weight of 0.9, and if the customer drives as fuel consciously as 50% of customers, that feature could be given a weight of 0.5, which standardizes the values on a common scale based on comparison to other customers; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see table 1); claim 8, compare the weighted values of each vehicle feature to weighted values associated with the selected vehicles);
receive, in real-time, driver preference data for a user, wherein the driver preference data indicates a plurality of importance values and corresponding to the plurality of driving categories; adjust at least one importance value based on the data measured during vehicle operation; assign a driver archetype to the user based on the driver preference data and the at least one adjusted importance value (Miller Figs. 1-3; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years. Thus, even though 4WD might be one of the safety recommendations associated with “safe” driving, this particular feature is either unimportant to the driver, or the driver may have never known the feature existed. While an assumption may need to be made, assuming that the driver simply does not care about 4WD will allow a vehicle recommendation to focus on features that may be more appealing to this particular driver; [0034], FIG. 2 shows an illustrative process for vehicle system usage monitoring. This illustrative system gathers vehicle driving history and vehicle-use pattern recognition to determine patterns between customers' driving data and customers' desired attributes. This data is then compared to established groupings to recommend products and services that matches a customer's likely desired vehicle attributes and/or likely desired vehicle attributes observed or predicted for other customers of similar driving behavior; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis; [0049], a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 ideal vehicle importance));
determine a suggested vehicle, of the plurality of vehicles, based on the data structure, wherein the suggested vehicle has a strength of relationship score that satisfies a threshold value in connection with the driver archetype; and transmit, to a user device, data indicating the suggested vehicle (Miller Figs. 1-3; [0007], a system includes a processor configured to determine and weight a customer's vehicle-attribute preferences based on data received from the customer's vehicle indicating the customer's behavior; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0027], a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote computing system (e.g., and without limitation, a server) connected through the wireless device. Collectively, such systems may be referred to as vehicle associated computing systems (VACS). In certain embodiments particular components of the VACS may perform particular portions of a process depending on the particular implementation of the system; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044-0045], For features that can be measured in terms of “use,” the weighting correlation could be based on frequency of usage (times/drive, times/month, etc.). For features that are more loosely defined, such as “acceleration preference,” the weighting could be based on commonality of occurrence, e.g., how many times does the user accelerate aggressively from a stopped position; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches; [0049], The process can even attempt to recommend several “optimal” vehicle choices, based on assigning attribute prioritization to an “ideal” (but not necessarily existent) vehicle based on observed customer behavior compared to existing group profiles, and then finding a vehicle for which predefined attributes most closely match the “ideal” vehicle profile. For example, such a process may result in the following (using an importance scale or weighting of 0-1) (see Table 1 vehicle compatibility score); [0052], The process may determine a point in a vehicle life-cycle at which to recommend a new vehicle, or the customer may actually request recommendations at any particular time. The recommendation data can also be sent to dealers or advertisers who can tailor offerings based on the recommendation, so the customer only receives offers and mail pertaining to vehicles the customer might most likely want).
However, Miller fails to expressly disclose wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios. In the same field of endeavor, Vardharajan teaches:
wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios (Vardharajan Figs. 1-6; [0014], a system can capture driving information for a driver by monitoring vehicle context and control information during a vehicle driving session. The system can generate a personalized driving style profile for the driver based on the driving information from the driving session; [0029], FIG. 2A is a block diagram illustrating an example, non-limiting embodiment of a system determining personalized driving style profiles; factors as vehicle acceleration, deceleration, signaling, distances from other vehicles or objects or traffic markers, lane changing, reversing, parking, and/or road conditions; [0030], The DPS 230 can use this additional information to build a context for the driving information that is captured during the real-world driving session; [0031], the DPS 230 can capture this driving information via a simulated vehicle 220 and/or simulated driving; Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes; the simulated vehicle can be a specialized simulator device; [0032], the DPS 230 can analyze the driving profile information that has been captured during the vehicle driving session, whether the driving profile information is captured via a real vehicle 220, a simulator vehicle 220, a software-based simulation, or a combination of these tools; The DPS 230 can use a machine learning based application or a machine learning engine. The DPS 230 can digest the driving information from the vehicle driving session into a set of key driving style parameter values for this driver 210. The key driving style parameters can be collated into a personalized driving style profile; [0040], The personalized driving style profile is portable; [0041], FIG. 2C depicts an illustrative embodiment of a method in accordance with various aspects described herein. The method 260 is an illustrative embodiment of a process for determining a personalized driving style profile for a driver and providing this profile for use at an autonomous vehicle when the driver becomes a passenger in the autonomous vehicle. In step 262, a driving profile server can capture driving information as a driver engages in a vehicle driving session. The driving session can include actual real-world driving of a vehicle, driving of a vehicle simulator, interaction with vehicle simulation software, or a combination of these approaches; [0090], the driving profile server 230 can use machine learning to determine a personalized driving style profile for a driver based on driving style information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein, for at least a portion of the plurality of drivers, the driving behavior is measured during operation of the vehicle simulator, wherein the vehicle simulator is configured to measure driver input in response to simulated driving scenarios as suggested in Vardharajan into Miller. Doing so would be desirable because drivers may know, first hand, the complexity, potential hazards, and “unwritten” rules of driving that they have personally relied upon for achieving safety, comfort, efficiency, and “driving the right way” (see Vardharajan [0028]). The system of would improve the system of Miller by providing a portable driver profile (see Vardharajan [0040]), that captures additional driver behavior in both simulated and real environments (see Vardharajan [0029-0032]) useable for machine learning (see Vardharajan [0090]). Capturing this driving information from a driver executing a simulated, self-drive driving course can provide an efficient and safe means for capturing driving habits and responses. For example, the simulated driving sequence can provide various weather conditions, road conditions, traffic, pedestrians, urban, rural, and/or highway conditions over a condensed period of minutes. Whereas achieving this range of driving situations can be impractical using real-world driving of an actual vehicle 220. Simulated driving also allows for capture of driving information in a standardized way that can make analysis easier and more predictable (see Vardharajan [0031]).
However, Miller in view of Vardharajan fails to expressly disclose receive, in real-time, driver preference data for a user, wherein the driver preference data indicates a plurality of importance values input by the user and corresponding to the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation. In the same field of endeavor, Toprak teaches:
receive, in real-time, driver preference data for a user, wherein the driver preference data indicates a plurality of importance values input by the user and corresponding to the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation (Toprak Figs. 1-46; [0047], During vehicle operation, different sets of OBD data may be collected, including, but not limited to, vehicle performance data and engine malfunction warning data. Performance data of a vehicle may be related to diagnostics information, such as oxygen levels, vehicle speed, temperature, and/or the like, and may be collected by the VMSP; [0049], As shown by diagram 4000 of FIG. 40, for example, the VMSP (e.g., CarHub Connect app) may collect OBD data (e.g., PID/vehicle performance data, MIL/maintenance needs and events, and/or accident event data (e.g., IMU/collision event data)). OBD data and any other suitable data, such as time data, location data, user/operator data, weather data, traffic data, road type/condition data, any other suitable vehicle environment data, accident event data, and/or the like, which may be collected by any suitable VMSP subsystem associated with the vehicle (e.g., by a CarHub Connect app of a vehicle operator) may be combined with OBD data and processed by the VMSP to provide a CarProfile for the vehicle and/or a CarScore for the vehicle and/or a DriverScore for a particular operator. As shown, certain CarProfile data may be used in conjunction with Cartron to determine a vehicle recommendation. Performance data, such as acceleration profile data, speed profile data, braking profile data, fuel efficiency data, mileage data, O2 sensor data, and/or the like for a certain vehicle and/or operator, and/or direct service needs data (e.g., OEM error decoding data) may be provided as at least a portion of CarProfile data. Quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs match the user's actual operation behavior, then the Cartron profile prediction may be reinforced and maintained. However, if the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace; [0052], Cartron may be an application or platform product that may present a user with questions or any other suitable questionnaire or data collection interface, and, based upon the answers collected, may provide a profile of the user that may quantify the preferences of the user with regards to needs of a vehicle as well as their needs for specific vehicle types. The output of Cartron may integrate as an input to a CarHub Car Recommendation Engine (“CRE”) of the VMSP in order to provide the user with vehicles that may fit the user's needs and financial situation. Cartron may be accessed through the MyCar section of the CarHub product, and can also be accessed through the buying process of new and used cars on the CarHub platform (e.g., via the CHC app). For example, as shown by screens 1200-1500 of FIGS. 12-15, a Cartron test may include a collection of quantitative and qualitative questions for users, to which the answers may be used to create a profile of the needs of a user with respect to the ideal vehicle for them to drive (e.g., answers indicative of budget, preferred vehicle styles, values, financing, car age, and/or the like). The Cartron results may be combined with driving behavior quantified by the OBD data (e.g., via CarHub Connect) to validate that a particular vehicle fits to a particular user/driver. The Cartron results may also integrate directly with a vehicle configurator and new/used inventory in the geographic location of the user, as well as with vehicle alerts (e.g., to notify when vehicles are available in the future). Cartron can be accessed during the vehicle configuration process (e.g., a new/used vehicle search) in order to help users understand their vehicle needs; [0053], data from trim specifications along with trim feature ratings, in combination with user personality variable(s) and/or user personal values variable(s) and car feature preference data to provide for preferred trim features, may be used to determine a trim recommendation; [0063], As shown by screens 2500-3000 of FIGS. 25-30, the Marketplace product of the platform may provide a user with the ability to configure a new vehicle search for potential purchase using any suitable information; see also [0068], [0074], virtual test drives)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated receive, in real-time, driver preference data for a user, wherein the driver preference data indicates a plurality of importance values input by the user and corresponding to the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation as suggested in Toprak into Miller in view of Vardharajan. Doing so would be desirable because conventional transactions between vehicle sellers and vehicle buyers have several disadvantages including, but not limited to, inefficient networking between potential parties to a vehicle transaction, inability to foster trust in the health of a vehicle, and/or inability to facilitate identification of a fair market price for a vehicle (see Toprak [0003]). Cartron may help to remove/overcome the burden of searching for a vehicle configuration, in particular for users who do not have a defined concept of what they need in a vehicle. Cartron can speed up the buying process by addressing the burden of searching through vehicles and making decisions on search criteria which may be needed before a vehicle configuration can be proposed (see Toprak [0052]). Additionally, quantitative history of such vehicle performance data may be analyzed by the VMSP to assess the actual vehicle operation behavior of a user operator and the VMSP may compare such behavior with a qualitative assessment of user needs from a Cartron profile to determine whether the user's vehicle needs from the Cartron profile match the user's actual operation behavior. If the user's Cartron profile needs do not match the user's actual operation behavior, then the Cartron profile may be updated to suggest a different vehicle type, which may facilitate the VMSP to suggest one or more particular vehicles in the VMSP marketplace(see Toprak [0049]), thereby providing improved suggestions based on additional data points, which would enhance the car search process with suggestions that are better tailored to the user.
Regarding claim 19, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 16, further comprising:
store, in a driver profile database under a user account associated with a driver identifier for the user, the driver preference data of the user and data indicating the driver archetype associated with the user (Miller Figs. 1-3; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; [0042], FIG. 3 shows an illustrative process for vehicle recommendation. In this example, the cloud can then use the uploaded data to build 301 drive pattern profiles for the individual user. This can include usage patterns, drive duration patterns, aggressive/defensive patterns, weather driving behavior, etc. Feature usage statistics and/or patterns can also be built and observed by the cloud. The cloud can use the data to assemble a comprehensive driver profile, and the attributes of this profile can allow for alignment of the driver with one or more customer profiles indicative of larger consumer groups; [0043], Once the process has built a profile, having certain characteristics or parameters associated therewith, the process can compare 303 these aspects of the profile to larger customer groupings. This can allow the process to classify 305 the customer based on multiple customer groupings; [0044], Since a driver may exhibit multiple driving behavior patterns or driving types, weighting can also be used to further refine classifications; [0046-0047], Once a weighted classification of a customer has been built, the process can use recommended vehicles associated with high-value customer group matches).
Regarding claim 20, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 16, further comprising:
wherein the one or more instructions, that cause the device to receive the vehicle data for the plurality of vehicles, cause the device to: obtain the vehicle data from a vehicle profile database (Miller Figs. 1-3; [0006], a system includes a processor configured to wirelessly receive data indicating vehicle-feature usage for an individual vehicle. The processor is also configured to aggregate received data to form a feature-usage customer profile defining feature preferences. The processor is further configured to select vehicles associated with a customer-classification, including predefined feature-usage characteristics, the customer-classification determined based on a correlation between the predefined feature-usage characteristics and the aggregated data in the feature-usage profile defining feature preferences. The processor is also configured to compare the aggregated data to the selected vehicles to determine a vehicle having features preferred by a customer as indicated by the aggregated data in the feature-usage profile and recommend the determined vehicle to the customer; [0007], The processor is also configured to select vehicles driven by other customers having the same weighted customer vehicle-attribute preferences as the customer's vehicle-attribute preferences; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; [0048], the process can choose a vehicle based on which of the vehicles has the same ordered ranking of weightings (e.g., top down), or, for example, based on which of the vehicles has the closest total value of rankings (e.g., the total difference between customer weightings and vehicle-associated weightings; claim 8, compare the weighted values of each vehicle feature to weighted values associated with the selected vehicles).
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Miller in view of Vardharajan in further view of Toprak in further view of Latronico et al. (US 11010827 B1, published 05/18/2021), hereinafter Latronico.
Regarding claim 2, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 1, further comprising:
wherein the one or more processors, to output the vehicle information, are configured to provide, to a user device, the vehicle information with each of the one or more compatible vehicles (Miller Figs. 1-3; [0007], a system includes a processor configured to determine and weight a customer's vehicle-attribute preferences based on data received from the customer's vehicle indicating the customer's behavior; [0008], comparing the customer vehicle-attribute preference values to predefined attribute values associated with a plurality of vehicles pre-associated with chosen group to determine vehicles having attribute values within a predefined tolerance of the customer vehicle-attribute preference values and recommending the determined vehicles; [0052], The process may determine a point in a vehicle life-cycle at which to recommend a new vehicle, or the customer may actually request recommendations at any particular time. The recommendation data can also be sent to dealers or advertisers who can tailor offerings based on the recommendation, so the customer only receives offers and mail pertaining to vehicles the customer might most likely want; see also [0042-0049]).
However, Miller in view of Vardharajan in further view of Toprak fails to expressly disclose wherein the one or more processors, to output the vehicle information, are configured to provide, to a user device, the vehicle information with each of the one or more compatible vehicles as a selectable option; and wherein the one or more processors are further configured to: receive, from the user device, data indicating a selection of a compatible vehicle from the one or more compatible vehicles; and provide, to the user device, data indicating one or more third party entities within a threshold distance of a user location and having an inventory of vehicles that includes the compatible vehicle selected by the user. In the same field of endeavor, Latronico teaches:
wherein the one or more processors, to output the vehicle information, are configured to provide, to a user device, the vehicle information with each of the one or more compatible vehicles as a selectable option; and wherein the one or more processors are further configured to: receive, from the user device, data indicating a selection of a compatible vehicle from the one or more compatible vehicles; and provide, to the user device, data indicating one or more third party entities within a threshold distance of a user location and having an inventory of vehicles that includes the compatible vehicle selected by the user (Latronico Figs. 1-8; col. 10 [line 30], Other vehicle information, including the availability and/or price of other instances of the same and/or similar vehicle at other (e.g., nearby) sellers. In some implementations, the interface may enable the user to specify a distance or range to search for similar nearby vehicles, e.g., within 5 miles of the current location, within 50 miles of the current location, and so forth. Implementations may employ any suitable technique for determining the current location of the user and/or the user device. For example, location may be determined using a satellite-based navigation system such as the global positioning system (GPS). Nearby vehicle(s) may include new vehicle(s), used vehicle(s), and/or both new and used vehicle(s), according to the expressed preferences of the user for new versus used vehicles. Nearby vehicle(s) may include vehicle(s) that are available for purchase and/or vehicle(s) that are available for rental or lease, according to the expressed preferences of the user for purchasing versus leasing a vehicle; col. 12 [line 59], the interface 110 may present a list of vehicles that are search results and/or recommended for the user 102, and the interface 110 may present total cost of ownership information for each vehicle along with the user's other financial information regarding how much they can afford to spend each month. In some implementations, the user 102 may select a vehicle from the search results and/or recommendations list and, in response, the interface 110 may present details regarding the selected vehicle along with the total cost of ownership and the user's budget information; col. 13 [line 38], After the user 102 has indicated the particular vehicle to be purchased, the integration engine 112 may submit a request to one or more of the remote data services 118, requesting an initial estimate of a purchase price for the selected vehicle and a list of (e.g., local) sellers that have the vehicle available for sale. The remote service(s) may respond with the initial price estimate, and may also provide a list of sellers that have the vehicle available for sale (or that may obtain the vehicle within a short period of time). The sellers may be determined based on their current inventory, and/or based on their location being in proximity to the user's location. For example, seller(s) within a same city, county, and/or metropolitan area may be identified, and/or seller(s) within a threshold distance (e.g., 25 miles) of the user's location; col. 15 [line 48], The “Find My Next Car”) screen may present a list of vehicles that are recommended for the user and/or vehicles that the user has previously flagged (e.g., liked, favorited, preferenced, etc.) through the vehicle search data service interface; col. 16 [line 35], FIG. 5 shows an example of the interface 110 that is shown to provide information regarding the pre-negotiation process. In some implementations, the screen of FIG. 5 may be shown as part of the application 106, such as a screen that is shown as one of the “How to Make the Purchase” features of the application. As shown in this example, the screen may include a section 502 describing the characteristics of the vehicle that the user has selected for purchase; col. 16 [line 51], FIG. 6 depicts a flow diagram of an example process for pre-negotiating an item purchase).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein the one or more processors, to output the vehicle information, are configured to provide, to a user device, the vehicle information with each of the one or more compatible vehicles as a selectable option; and wherein the one or more processors are further configured to: receive, from the user device, data indicating a selection of a compatible vehicle from the one or more compatible vehicles; and provide, to the user device, data indicating one or more third party entities within a threshold distance of a user location and having an inventory of vehicles that includes the compatible vehicle selected by the user as suggested in Latronico into Miller in view of Vardharajan in further view of Toprak. Doing so would be desirable because typically, purchasing a vehicle or other expensive item may be a stressful experience for an individual. The potential purchaser walking through a showroom or a vehicle sales lot may be confronted with sales personnel whose goal is to maximize the sale price and who may not necessarily be focused on the purchaser's concerns. Moreover, the purchaser may be disadvantaged during negotiations with the seller, given that the purchaser may not have ready access to objective information that would inform the purchase decision. For these reasons, the purchaser may lack confidence that they are getting the best deal or that their other concerns have been adequately addressed (see Latronico col. 1 [line 15]). Implementations of the present disclosure are generally directed to facilitating and/or optimizing a transaction. More specifically, implementations are directed to providing an integrated transaction interface and platform that integrates information from various data services to provide cost information and recommendations for a transaction, and that provides an auction-based pre-negotiation to optimize a transaction (see Latronico col. 1 [line 30]). Traditionally, purchase of an item such as a vehicle involves considerable haggling on the part of the buyer, and the buyer may be at a disadvantage given a lack of information regarding the item being purchased as well as other add-ons, such as a warranty or optional features. For example, a buyer may enter a car dealership with a previously arranged loan from their bank, and with an idea of which vehicle they wish to purchase. The dealer may, on-site, make a counter-offer regarding the loan and/or attempt to up-sell the buyer. Lacking complete information, the buyer may accept the counter-offer even though it may not be in the best financial interests of the buyer. The dealer may even convince the buyer to purchase a different vehicle, which the buyer cannot afford and/or which may not be optimal for the buyer's needs (see Latronico col. 4 [line 7]). Implementations support various entry points for the user (e.g., buyer) to identify the item (e.g., vehicle) they wish to buy, and to initiate the pre-negotiation process. In some implementations, the user accesses a user interface (UI) provided by the platform, and uses the UI to search for and identify the particular item that the user wishes to buy (see Latronico col. 4 [line 32]).
Regarding claim 3, Miller in view of Vardharajan in further view of Toprak in further view of Latronico teaches all the limitations of claim 2. Latronico further teaches:
wherein the one or more processors are further configured to: provide, to a third party device of each of the one or more third party entities, at least one of the data indicating the selection of the compatible vehicle or contact information of the user (Latronico Figs. 1-8; col. 12 [line 59], the user 102 may select a vehicle from the search results and/or recommendations list and, in response, the interface 110 may present details regarding the selected vehicle along with the total cost of ownership and the user's budget information; col. 13 [line 38], After the user 102 has indicated the particular vehicle to be purchased, the integration engine 112 may submit a request to one or more of the remote data services 118, requesting an initial estimate of a purchase price for the selected vehicle and a list of (e.g., local) sellers that have the vehicle available for sale. The remote service(s) may respond with the initial price estimate, and may also provide a list of sellers that have the vehicle available for sale (or that may obtain the vehicle within a short period of time). The sellers may be determined based on their current inventory, and/or based on their location being in proximity to the user's location. For example, seller(s) within a same city, county, and/or metropolitan area may be identified, and/or seller(s) within a threshold distance (e.g., 25 miles) of the user's location; col. 15 [line 48], The “Find My Next Car”) screen may present a list of vehicles that are recommended for the user and/or vehicles that the user has previously flagged (e.g., liked, favorited, preferenced, etc.) through the vehicle search data service interface; col. 16 [line 35], FIG. 5 shows an example of the interface 110 that is shown to provide information regarding the pre-negotiation process; col. 16 [line 51], FIG. 6 depicts a flow diagram of an example process for pre-negotiating an item purchase; see also col. 10 [line 30]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein the one or more processors are further configured to: provide, to a third party device of each of the one or more third party entities, at least one of the data indicating the selection of the compatible vehicle or contact information of the user as suggested in Latronico into Miller in view of Vardharajan in further view of Toprak. Doing so would be desirable because typically, purchasing a vehicle or other expensive item may be a stressful experience for an individual. The potential purchaser walking through a showroom or a vehicle sales lot may be confronted with sales personnel whose goal is to maximize the sale price and who may not necessarily be focused on the purchaser's concerns. Moreover, the purchaser may be disadvantaged during negotiations with the seller, given that the purchaser may not have ready access to objective information that would inform the purchase decision. For these reasons, the purchaser may lack confidence that they are getting the best deal or that their other concerns have been adequately addressed (see Latronico col. 1 [line 15]). Implementations of the present disclosure are generally directed to facilitating and/or optimizing a transaction. More specifically, implementations are directed to providing an integrated transaction interface and platform that integrates information from various data services to provide cost information and recommendations for a transaction, and that provides an auction-based pre-negotiation to optimize a transaction (see Latronico col. 1 [line 30]). Traditionally, purchase of an item such as a vehicle involves considerable haggling on the part of the buyer, and the buyer may be at a disadvantage given a lack of information regarding the item being purchased as well as other add-ons, such as a warranty or optional features. For example, a buyer may enter a car dealership with a previously arranged loan from their bank, and with an idea of which vehicle they wish to purchase. The dealer may, on-site, make a counter-offer regarding the loan and/or attempt to up-sell the buyer. Lacking complete information, the buyer may accept the counter-offer even though it may not be in the best financial interests of the buyer. The dealer may even convince the buyer to purchase a different vehicle, which the buyer cannot afford and/or which may not be optimal for the buyer's needs (see Latronico col. 4 [line 7]). Implementations support various entry points for the user (e.g., buyer) to identify the item (e.g., vehicle) they wish to buy, and to initiate the pre-negotiation process. In some implementations, the user accesses a user interface (UI) provided by the platform, and uses the UI to search for and identify the particular item that the user wishes to buy (see Latronico col. 4 [line 32]).
Claims 12, 13, 15, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Miller in view of Vardharajan in further view of Toprak in further view of Jackson et al. (US 20210166103 A1, published 06/03/2021), hereinafter Jackson.
Regarding claim 12, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 11, further comprising:
receiving, from the user device, data indicating a particular performance value for each of the plurality of driving categories (Miller Figs. 1-3; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; see also [0007-0008], [0033-0035], [0038], [0040-0049]).
However, Miller in view of Vardharajan in further view of Toprak fails to expressly disclose transmitting, to a user device, data indicating a plurality of queries relating to driver satisfaction in connection with the plurality of driving categories for the vehicle; and receiving, from the user device, data indicating a particular performance value for each of the plurality of driving categories in response to the plurality of queries. In the same field of endeavor, Jackson teaches:
transmitting, to a user device, data indicating a plurality of queries relating to driver satisfaction in connection with the plurality of driving categories for the vehicle; and receiving, from the user device, data indicating a particular performance value for each of the plurality of driving categories in response to the plurality of queries (Jackson Figs. 1-5; [0023], Inputs to the neural network may include driver profile data, vehicle attribute data, and/or driver attribute target values. For example, a matrix input may be provided, such as a driver-vehicle matrix. Explicit and/or implicit feedback may be utilized as input to the model; [0024], Driver vehicle ratings are captured for current vehicles and recommendations, aggregated and used as input data to improve recommendation quality; [0026], A set of vehicle attributes 26 is established, which is a list of categories—e.g., capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. The categories define the structure for the vehicle and driver datasets, where vehicles are rated and drivers and vehicles are matched based thereon. In the depicted example, the vehicle attributes include capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. Each vehicle will be given a value for each vehicle attribute based on the vehicle data. Additionally, a target value will be determined for each vehicle attribute category for each driver, which is referred to herein as driver attribute target values; [0027], the vehicle attribute data may comprise a vehicle attribute value as a rating between 0 and 10 for each of the vehicle attribute categories 26; [0029], FIG. 3B depicts on example of a user interface display showing vehicle ownership information for a driver, including current vehicle information and past vehicle information inputted by the driver; each current and past vehicle may be rated by the user, which may be a single overall rating or may be a rating based on various categories. These categories may have overlap with the vehicle attribute categories; [0030], the user interface may prompt a user to input, or assign, their own preferences for the vehicle attribute categories 26; [0035], The recommender neural network 50 is configured to receive the driver and vehicle data and to generate a vehicle recommendation, or a set of vehicle recommendations; the recommender neural network 50 provides sequence-based user representation that evaluates a driver's past vehicles and discounts the weight of older vehicles and older driver profile data, using that information to predict the next appropriate vehicle for that driver; [0038], Referring again to FIG. 2, the vehicle recommendation(s) 80 may be provided to a purchase optimizer engine 81 that generates one or more vehicle purchase recommendations 82 based on the vehicle recommendation(s) 80; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time; [0042], FIG. 6 shows one exemplary user interface visually depicting driver profile data, vehicle recommendations 80, and vehicle purchase recommendations 82 for a particular driver; A radial chart 135 visually represents information regarding the vehicle recommendations 80, including how the vehicle attribute data for each of the recommended vehicles aligns with the driver attribute target values for each vehicle attribute category).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated transmitting, to a user device, data indicating a plurality of queries relating to driver satisfaction in connection with the plurality of driving categories for the vehicle; and receiving, from the user device, data indicating a particular performance value for each of the plurality of driving categories in response to the plurality of queries as suggested in Jackson into Miller in view of Vardharajan in further view of Toprak. Doing so would be desirable because the inventor has recognized a need for an improved system for optimizing the vehicle purchase process and helping drivers determine an optimal vehicle for them based on their driving habits, cargo and transportation needs, financial constraints, location, preferences, etc. The inventor has also recognized that the vehicle purchasing process is different than most other product purchasing processes, and that standard product recommender systems are not appropriate or easily adapted for recommending vehicles to purchasers for several reasons. Vehicle purchases are very high dollar and low frequency purchases. Moreover, vehicle shopping is often done in person, such as by visiting a car lots or other sales locations of vehicles so that the purchaser can view and drive the vehicle. Thus, very little information is available about user actions that are useful to standard recommender systems, such as those utilized in online marketplaces (see Jackson [0016]). Moreover, the inventor has recognized that the purchasing process and/or payment arrangements for vehicles are more complex than for other lesser-value products, and that individuals spend varying percentages of their income on vehicles and have varying preferences regarding vehicle payment arrangements. (see Jackson [0017]). The inventor has developed a personalized vehicle recommender system that enables users, which may include individual drivers, dealerships, and manufacturers, and or automotive organizations, to interact with the system and with each other. The recommender system allows individual drivers to create a profile, and the system has been designed to collect relevant information from a driver from which, based on an agglomeration of collected information, a personalized vehicle recommendation can be made for that individual driver. The system is configured to elicit user-generated information from each driver, which may include personal information (name, birthdate, address, demographic information, contact information, etc.), driving practices information (passenger and cargo demands, driving routes and times, total weekly/monthly/annual mileage, and the like), and vehicle ownership information (current vehicles, current vehicle ratings, past vehicles, past vehicle ratings, purchase method, and the like) (see Jackson [0019]). Based on their substantial expertise in the relevant field, the inventor has recognized that providing accurate and useful vehicle recommendations requires a wide range of information about both the driver and about all available vehicle types, or vehicle classes (see Jackson [0020]). Through experimentation and research, and based on expert knowledge relevant to the vehicle market, the inventor has also recognized that employing deep learning methods improves the vehicle recommendation outcomes and provides a flexible and adaptive system (see Jackson [0023]).
Regarding claim 13, Miller in view of Vardharajan in further view of Toprak in further view of Jackson teaches all the limitations of claim 12, further comprising:
further comprising: receiving, from another user device, data indicating another performance value for each of the plurality of driving categories for the vehicle; and updating the particular performance value for each of the plurality of driving categories based on the data indicating the other performance value for each of the plurality of driving categories (Miller Figs. 1-3; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; see also [0007-0008], [0033-0035], [0040-0049]).
Regarding claim 15, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 14, further comprising:
receiving, from the user device or the third party device, data indicating a satisfaction score (Miller Figs. 1-3; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; see also [0007-0008], [0033-0035], [0038], [0040-0049]).
However, Miller fails to expressly disclose transmitting, to a user device or a third party device, data indicating one or more queries of a satisfaction of the vehicle in one or more driving categories of the plurality of driving categories; receiving, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries; and retraining the machine learning model based on the data indicating the satisfaction score in response to one or more of the queries. In the same field of endeavor, Jackson teaches:
transmitting, to a user device or a third party device, data indicating one or more queries of a satisfaction of the vehicle in one or more driving categories of the plurality of driving categories; receiving, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries; and retraining the machine learning model based on the data indicating the satisfaction score in response to one or more of the queries (Jackson Figs. 1-5; [0023], Inputs to the neural network may include driver profile data, vehicle attribute data, and/or driver attribute target values. For example, a matrix input may be provided, such as a driver-vehicle matrix. Explicit and/or implicit feedback may be utilized as input to the model; [0024], Recommendations automatically update for all drivers when at least one driver edits their profile, adds a vehicle, rates a vehicle, or accepts or declines a vehicle recommendation. In certain examples, recommendations are regenerated for a driver when their current vehicle odometer reading is automatically adjusted based on their profile, driving patterns, life stage, past driving behavior and current date. Separately, as a driver progresses through the various life stages recommendations are regenerated to personalize ownership preferences by age. The learning system runs epochs (iterations) of different models to fit the data. The most accurate models survive and less accurate discarded. Randomness is built into the model to distribute and vary the recommendations across the universe of drivers. The vehicle recommender system 10 is a continuous cycle. Driver vehicle ratings are captured for current vehicles and recommendations, aggregated and used as input data to improve recommendation quality; [0026], A set of vehicle attributes 26 is established, which is a list of categories—e.g., capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. The categories define the structure for the vehicle and driver datasets, where vehicles are rated and drivers and vehicles are matched based thereon. In the depicted example, the vehicle attributes include capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. Each vehicle will be given a value for each vehicle attribute based on the vehicle data. Additionally, a target value will be determined for each vehicle attribute category for each driver, which is referred to herein as driver attribute target values; [0027], the vehicle attribute data may comprise a vehicle attribute value as a rating between 0 and 10 for each of the vehicle attribute categories 26; [0029], FIG. 3B depicts on example of a user interface display showing vehicle ownership information for a driver, including current vehicle information and past vehicle information inputted by the driver; each current and past vehicle may be rated by the user, which may be a single overall rating or may be a rating based on various categories. These categories may have overlap with the vehicle attribute categories; [0030], the user interface may prompt a user to input, or assign, their own preferences for the vehicle attribute categories 26; [0035], The recommender neural network 50 is configured to receive the driver and vehicle data and to generate a vehicle recommendation, or a set of vehicle recommendations; the recommender neural network 50 provides sequence-based user representation that evaluates a driver's past vehicles and discounts the weight of older vehicles and older driver profile data, using that information to predict the next appropriate vehicle for that driver; [0037], The user input 60 can be used as explicit feedback to the neural network 50. Implicit feedback may also be provided, such as by changes to the user-generated profile data 22 and user-item interaction matrices 61. In one embodiment, WARP loss function and AUC accuracy scoring may be utilized as the learning algorithm; [0038], Referring again to FIG. 2, the vehicle recommendation(s) 80 may be provided to a purchase optimizer engine 81 that generates one or more vehicle purchase recommendations 82 based on the vehicle recommendation(s) 80; [0042], FIG. 6 shows one exemplary user interface visually depicting driver profile data, vehicle recommendations 80, and vehicle purchase recommendations 82 for a particular driver; A radial chart 135 visually represents information regarding the vehicle recommendations 80, including how the vehicle attribute data for each of the recommended vehicles aligns with the driver attribute target values for each vehicle attribute category).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated transmitting, to a user device or a third party device, data indicating one or more queries of a satisfaction of the vehicle in one or more driving categories of the plurality of driving categories; receiving, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries; and retraining the machine learning model based on the data indicating the satisfaction score in response to one or more of the queries as suggested in Jackson into Miller. Doing so would be desirable because the inventor has recognized a need for an improved system for optimizing the vehicle purchase process and helping drivers determine an optimal vehicle for them based on their driving habits, cargo and transportation needs, financial constraints, location, preferences, etc. The inventor has also recognized that the vehicle purchasing process is different than most other product purchasing processes, and that standard product recommender systems are not appropriate or easily adapted for recommending vehicles to purchasers for several reasons. Vehicle purchases are very high dollar and low frequency purchases. Moreover, vehicle shopping is often done in person, such as by visiting a car lots or other sales locations of vehicles so that the purchaser can view and drive the vehicle. Thus, very little information is available about user actions that are useful to standard recommender systems, such as those utilized in online marketplaces (see Jackson [0016]). Moreover, the inventor has recognized that the purchasing process and/or payment arrangements for vehicles are more complex than for other lesser-value products, and that individuals spend varying percentages of their income on vehicles and have varying preferences regarding vehicle payment arrangements. (see Jackson [0017]). The inventor has developed a personalized vehicle recommender system that enables users, which may include individual drivers, dealerships, and manufacturers, and or automotive organizations, to interact with the system and with each other. The recommender system allows individual drivers to create a profile, and the system has been designed to collect relevant information from a driver from which, based on an agglomeration of collected information, a personalized vehicle recommendation can be made for that individual driver. The system is configured to elicit user-generated information from each driver, which may include personal information (name, birthdate, address, demographic information, contact information, etc.), driving practices information (passenger and cargo demands, driving routes and times, total weekly/monthly/annual mileage, and the like), and vehicle ownership information (current vehicles, current vehicle ratings, past vehicles, past vehicle ratings, purchase method, and the like) (see Jackson [0019]). Based on their substantial expertise in the relevant field, the inventor has recognized that providing accurate and useful vehicle recommendations requires a wide range of information about both the driver and about all available vehicle types, or vehicle classes (see Jackson [0020]). Through experimentation and research, and based on expert knowledge relevant to the vehicle market, the inventor has also recognized that employing deep learning methods improves the vehicle recommendation outcomes and provides a flexible and adaptive system (see Jackson [0023]).
Regarding claim 17, Miller in view of Vardharajan in further view of Toprak teaches all the limitations of claim 16, further comprising:
receive, from the user device or the third party device, data indicating a satisfaction score (Miller Figs. 1-3; [0031], By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time; [0041], The process further logs 209 driving data, which can include aggressiveness, braking habits, acceleration habits, turn radius, speed through turns, etc. Once the drive ends, the process can upload all of this data to the cloud for analysis. Alternatively, the process can periodically upload the data, or even locally store the data until such time as a new vehicle may be needed. Since the process may also use this data to fine tune other predictions, however, it will probably be more common to at least periodically upload the observation data, so that the cloud can fine-tune the aggregate data sets; see also [0007-0008], [0033-0035], [0038], [0040-0049])
However, Miller in view of Vardharajan in further view of Toprak fails to expressly disclose transmit, to the user device or a third party device, data indicating one or more queries of a satisfaction of the user with the suggested vehicle; and receive, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries. In the same field of endeavor, Jackson teaches:
transmit, to the user device or a third party device, data indicating one or more queries of a satisfaction of the user with the suggested vehicle; and receive, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries (Jackson Figs. 1-5; [0023], Inputs to the neural network may include driver profile data, vehicle attribute data, and/or driver attribute target values. For example, a matrix input may be provided, such as a driver-vehicle matrix. Explicit and/or implicit feedback may be utilized as input to the model; [0024], Recommendations automatically update for all drivers when at least one driver edits their profile, adds a vehicle, rates a vehicle, or accepts or declines a vehicle recommendation; [0026], A set of vehicle attributes 26 is established, which is a list of categories—e.g., capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. The categories define the structure for the vehicle and driver datasets, where vehicles are rated and drivers and vehicles are matched based thereon. In the depicted example, the vehicle attributes include capacity, cargo, cost, efficiency, performance, safety, style, utility, and telematics. Each vehicle will be given a value for each vehicle attribute based on the vehicle data. Additionally, a target value will be determined for each vehicle attribute category for each driver, which is referred to herein as driver attribute target values; [0027], the vehicle attribute data may comprise a vehicle attribute value as a rating between 0 and 10 for each of the vehicle attribute categories 26; [0029], FIG. 3B depicts on example of a user interface display showing vehicle ownership information for a driver, including current vehicle information and past vehicle information inputted by the driver; each current and past vehicle may be rated by the user, which may be a single overall rating or may be a rating based on various categories. These categories may have overlap with the vehicle attribute categories; [0030], the user interface may prompt a user to input, or assign, their own preferences for the vehicle attribute categories 26; [0035], The recommender neural network 50 is configured to receive the driver and vehicle data and to generate a vehicle recommendation, or a set of vehicle recommendations; the recommender neural network 50 provides sequence-based user representation that evaluates a driver's past vehicles and discounts the weight of older vehicles and older driver profile data, using that information to predict the next appropriate vehicle for that driver; [0037], The user input 60 can be used as explicit feedback to the neural network 50. Implicit feedback may also be provided, such as by changes to the user-generated profile data 22 and user-item interaction matrices 61. In one embodiment, WARP loss function and AUC accuracy scoring may be utilized as the learning algorithm; [0038], Referring again to FIG. 2, the vehicle recommendation(s) 80 may be provided to a purchase optimizer engine 81 that generates one or more vehicle purchase recommendations 82 based on the vehicle recommendation(s) 80; [0042], FIG. 6 shows one exemplary user interface visually depicting driver profile data, vehicle recommendations 80, and vehicle purchase recommendations 82 for a particular driver; A radial chart 135 visually represents information regarding the vehicle recommendations 80, including how the vehicle attribute data for each of the recommended vehicles aligns with the driver attribute target values for each vehicle attribute category).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated transmit, to the user device or a third party device, data indicating one or more queries of a satisfaction of the user with the suggested vehicle; and receive, from the user device or the third party device, data indicating a satisfaction score in response to each of the one or more queries as suggested in Jackson into Miller in view of Vardharajan in further view of Toprak. Doing so would be desirable because the inventor has recognized a need for an improved system for optimizing the vehicle purchase process and helping drivers determine an optimal vehicle for them based on their driving habits, cargo and transportation needs, financial constraints, location, preferences, etc. The inventor has also recognized that the vehicle purchasing process is different than most other product purchasing processes, and that standard product recommender systems are not appropriate or easily adapted for recommending vehicles to purchasers for several reasons. Vehicle purchases are very high dollar and low frequency purchases. Moreover, vehicle shopping is often done in person, such as by visiting a car lots or other sales locations of vehicles so that the purchaser can view and drive the vehicle. Thus, very little information is available about user actions that are useful to standard recommender systems, such as those utilized in online marketplaces (see Jackson [0016]). Moreover, the inventor has recognized that the purchasing process and/or payment arrangements for vehicles are more complex than for other lesser-value products, and that individuals spend varying percentages of their income on vehicles and have varying preferences regarding vehicle payment arrangements (see Jackson [0017]). The inventor has developed a personalized vehicle recommender system that enables users, which may include individual drivers, dealerships, and manufacturers, and or automotive organizations, to interact with the system and with each other. The recommender system allows individual drivers to create a profile, and the system has been designed to collect relevant information from a driver from which, based on an agglomeration of collected information, a personalized vehicle recommendation can be made for that individual driver. The system is configured to elicit user-generated information from each driver, which may include personal information (name, birthdate, address, demographic information, contact information, etc.), driving practices information (passenger and cargo demands, driving routes and times, total weekly/monthly/annual mileage, and the like), and vehicle ownership information (current vehicles, current vehicle ratings, past vehicles, past vehicle ratings, purchase method, and the like) (see Jackson [0019]). Based on their substantial expertise in the relevant field, the inventor has recognized that providing accurate and useful vehicle recommendations requires a wide range of information about both the driver and about all available vehicle types, or vehicle classes (see Jackson [0020]). Through experimentation and research, and based on expert knowledge relevant to the vehicle market, the inventor has also recognized that employing deep learning methods improves the vehicle recommendation outcomes and provides a flexible and adaptive system (see Jackson [0023]).
Regarding claim 18, Miller in view of Vardharajan in further view of Toprak in further view of Jackson teaches all the limitations of claim 17, further comprising:
adjust the performance value of one or more of the plurality of driving categories of the suggested vehicle based on the data indicating the satisfaction score (Miller Figs. 1-3; [0030], With the proliferation of improved analytic usage, such as that provided by artificial intelligence, cognitive computing, big data, etc., vehicle OEMS can utilize enhanced methods that use each customer's individual driving data and feature usage to provide reliable customized product and service recommendations; [0031], Initially, a system may classify driver groupings based on observed driving data and statistical pattern recognition. The groupings are potentially limitless, and can also share overlap. For example, there could be a group of drivers who drive aggressively when alone and defensively when there are other occupants. This could overlap with a group of drivers who drive aggressively at all times. In both groupings, aggressive drivers of at least some degree might benefit from enhanced traction control, acceleration and braking. In the first group, the aggressive drivers might also benefit from side-curtain airbags and inflatable seat belts, since those people are also safety conscious (at least at times). By using characteristics common to each group, and by comparing gathered data on an individual driver to the characteristics, a driver can be placed into any number of possible groupings, and those groupings may have recommended features or vehicle systems associated therewith; [0032], Driver feature usage can also be considered. For example, the “aggressive/safe” driver above may currently drive a vehicle having 4WD, but may literally never have used 4WD once in two years; [0033], Once initial parameters have been formulated for groupings, the system can begin to compare individual driving data against the grouped parameters; [0038], the process detects 201 that a drive has begun, and begins to monitor 203 a variety of vehicle systems and features. These systems can include virtually any system, such as engine speed, acceleration, pedal position, braking, window state, HVAC state, seat position, wheel position, etc. Other systems features can include, for example, media players, media streaming, telematics usage, application usage, navigation usage, etc.; [0040], Additional values measured could include usage statistics such as fuel usage, refueling propensity, cruise control usage, power take-off usage, lift gate usage, even rear seat usage and rear seat stowage time).
Jackson further teaches:
adjust the performance value of one or more of the plurality of driving categories of the suggested vehicle based on the data indicating the satisfaction score in response to the one or more queries (Jackson Figs. 1-5; [0023], Inputs to the neural network may include driver profile data, vehicle attribute data, and/or driver attribute target values. For example, a matrix input may be provided, such as a driver-vehicle matrix. Explicit and/or implicit feedback may be utilized as input to the model; [0024], Recommendations automatically update for all drivers when at least one driver edits their profile, adds a vehicle, rates a vehicle, or accepts or declines a vehicle recommendation; [0026-0027], the vehicle attribute data may comprise a vehicle attribute value as a rating between 0 and 10 for each of the vehicle attribute categories 26; [0029], FIG. 3B depicts on example of a user interface display showing vehicle ownership information for a driver; [0030], the user interface may prompt a user to input, or assign, their own preferences for the vehicle attribute categories 26; [0035], The recommender neural network 50 is configured to receive the driver and vehicle data and to generate a vehicle recommendation, or a set of vehicle recommendations; the recommender neural network 50 provides sequence-based user representation that evaluates a driver's past vehicles and discounts the weight of older vehicles and older driver profile data, using that information to predict the next appropriate vehicle for that driver; [0037-0038], The user input 60 can be used as explicit feedback to the neural network 50. Implicit feedback may also be provided, such as by changes to the user-generated profile data 22 and user-item interaction matrices 61. In one embodiment, WARP loss function and AUC accuracy scoring may be utilized as the learning algorithm).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated adjust the performance value of one or more of the plurality of driving categories of the suggested vehicle based on the data indicating the satisfaction score in response to the one or more queries as suggested in Jackson into Miller in view of Vardharajan in further view of Toprak. Doing so would be desirable because the inventor has recognized a need for an improved system for optimizing the vehicle purchase process and helping drivers determine an optimal vehicle for them based on their driving habits, cargo and transportation needs, financial constraints, location, preferences, etc. The inventor has also recognized that the vehicle purchasing process is different than most other product purchasing processes, and that standard product recommender systems are not appropriate or easily adapted for recommending vehicles to purchasers for several reasons. Vehicle purchases are very high dollar and low frequency purchases. Moreover, vehicle shopping is often done in person, such as by visiting a car lots or other sales locations of vehicles so that the purchaser can view and drive the vehicle. Thus, very little information is available about user actions that are useful to standard recommender systems, such as those utilized in online marketplaces (see Jackson [0016]). Moreover, the inventor has recognized that the purchasing process and/or payment arrangements for vehicles are more complex than for other lesser-value products, and that individuals spend varying percentages of their income on vehicles and have varying preferences regarding vehicle payment arrangements. (see Jackson [0017]). The inventor has developed a personalized vehicle recommender system that enables users, which may include individual drivers, dealerships, and manufacturers, and or automotive organizations, to interact with the system and with each other. The recommender system allows individual drivers to create a profile, and the system has been designed to collect relevant information from a driver from which, based on an agglomeration of collected information, a personalized vehicle recommendation can be made for that individual driver. The system is configured to elicit user-generated information from each driver, which may include personal information (name, birthdate, address, demographic information, contact information, etc.), driving practices information (passenger and cargo demands, driving routes and times, total weekly/monthly/annual mileage, and the like), and vehicle ownership information (current vehicles, current vehicle ratings, past vehicles, past vehicle ratings, purchase method, and the like) (see Jackson [0019]). Based on their substantial expertise in the relevant field, the inventor has recognized that providing accurate and useful vehicle recommendations requires a wide range of information about both the driver and about all available vehicle types, or vehicle classes (see Jackson [0020]). Through experimentation and research, and based on expert knowledge relevant to the vehicle market, the inventor has also recognized that employing deep learning methods improves the vehicle recommendation outcomes and provides a flexible and adaptive system (see Jackson [0023]).
Response to Arguments
The Examiner acknowledges the Applicant’s amendments to claims 1, 6, 11, and 16. The rejections of claims 1-20 under 35 U.S.C. § 101 for being directed to an abstract idea without significantly more are respectfully withdrawn.
Applicant alleges that Miller in view of Vardharajan as described in the previous Office action, does not explicitly teach generate a data structure that indicates a strength of relationship score 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; receive, in real-time, driver preference data for a user, wherein the driver preference data includes data measured during vehicle operation and an importance value input by the user for each driving category of the plurality of driving categories; adjust at least one importance value input by the user based on the data measured during vehicle operation: determine a driver cluster, of the plurality of driver clusters, to which the user belongs based on the driver preference data and the at least one adjusted importance value, as has been amended to the claim. Examiner has therefore rejected independent claim 1 under 35 U.S.C § 103 as unpatentable over Miller in view of Vardharajan in further view of Toprak.
Similar arguments have been presented for claims 11 and 16 and thus, Applicant’s arguments are not persuasive for the same reasons.
Applicant states that the dependent claims recite all the limitations of the independent claims, and thus, are allowable in view of the remarks set forth regarding the independent claims. However, as discussed above, Miller in view of Vardharajan in further view of Toprak is considered to teach the independent claims, and consequently, the dependent claims are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Dagley (US 20230194291 A1) see Figs. 1-4 and [0203-0213].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUANG FU CHEN whose telephone number is (571)272-1393. The examiner can normally be reached M-F 9:00-5:30pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jennifer Welch can be reached at (571) 272-7212. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KC CHEN/Primary Patent Examiner, Art Unit 2143