Customer preference driven vehicle supply management system

The subject matter described herein relates to systems, devices, and methods for managing vehicle supply and demand. This vehicle supply management system has particular, but not exclusive utility for supply chain management for cars and trucks.

Today, it is not unusual for a vehicle brand and model to have hundreds options or specifications for its configuration. The options or specifications include not only exterior color(s), interior color(s), engine type, and transmission type, but also accessories, trim, option packages, etc. The possible permutations and combinations may thus be more numerous than the number of vehicles actually produced. It can therefore be difficult for a dealer or manufacturer to manage these vehicle specifications, which are continuously changing and growing due to rapid technological advancements. At the same time, customers are becoming more sophisticated, and want to find vehicles online that match their detailed requirements, preferences, and utility functions in a way that is easy to understand. Given these evolving customer and technological needs, manufacturers are finding it difficult to incorporate these personalized preferences into their demand and supply planning and management.

It should therefore be appreciated that current vehicle supply and demand management systems have numerous drawbacks, including slow response, limited customer satisfaction, and otherwise. Accordingly, a need exists for improved vehicle supply management systems that address the forgoing and other concerns.

The information included in this Background section of the specification, including any references cited herein and any description or discussion thereof, is included for technical reference purposes only and is not to be regarded as subject matter by which the scope of the disclosure is to be bound.

Disclosed is a vehicle supply management system. The vehicle supply management system disclosed herein has particular, but not exclusive, utility for supply chain management for cars and trucks. The vehicle supply management system allows purchasers to find the available vehicles that most closely match their preferences, and allows manufacturers to ship and manufacture vehicles based on detailed knowledge of gaps and/or gluts in the current vehicle supply.

The vehicle supply management system includes a system of one or more computers that can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a system including a user application configured to, based on inputs from a user, generate a target vehicle specification. The system also includes a database that may include a plurality of inventory specifications of a respective plurality of vehicles in a vehicle inventory. The system also includes a spec encoder configured to: encode the target vehicle specification as a first code; encode the plurality of inventory specifications as a plurality of respective second codes; and map the target vehicle specification and the plurality of inventory specifications into a multidimensional specification space, where the multidimensional specification space includes one dimension for each specification category of the target vehicle specification. The system also includes a preference class vector that may include a respective weight for each dimension of the multidimensional specification space. The system also includes a matching engine configured to: based on the preference class vector, define a search neighborhood around the target vehicle specification in the multidimensional specification space; identify inventory specifications of the plurality of inventory specifications that fall within the search neighborhood; and for each identified inventory specification: compute a match score; and report, to the user, the match score and the vehicle corresponding to the identified inventory specification. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. In some embodiments, the first code and the plurality of second codes are SR codes. In some embodiments, the first code and the plurality of second codes are hexadecimal strings. In some embodiments, the specification categories of the target vehicle specification include at least one of an exterior color, an interior color, an engine type, a transmission type, an accessory, or a trim package. In some embodiments, the system may include a user feedback module configured to: receive user feedback regarding the vehicles corresponding to the identified inventory specifications; and based on the user feedback, update the preference class vector. In some embodiments, the system may include a specification manager configured to, based on changes in the vehicle inventory, update the database may include the plurality of inventory specifications. In some embodiments, the system may include a tightness updater configured to: based on the mapped target vehicle specification, the mapped plurality of inventory specifications, and the search neighborhood, compute a tightness for the target vehicle specification; and report the tightness to the user, or to a dealer or manufacturer. In some embodiments, the system may include gap glut analyzer configured to: based on a plurality of target vehicle specifications and the plurality of inventory specifications, compute a gap-glut estimate; and report the gap-glut estimate to a dealer or manufacturer. In some embodiments, the system may include a goal maximizer configured to, based on the gap-glut estimate: request changes to the vehicle inventory; or adjust prices of at least some vehicles in the vehicle inventory. In some embodiments, the user application is a smartphone application or web application. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

One general aspect includes a non-transitory computer-readable medium containing instructions for: with a user application, based on inputs from a user, generating a target vehicle specification; with a database stored in a first memory, storing a plurality of inventory specifications of a respective plurality of vehicles in a vehicle inventory; with a spec encoder: encoding the target vehicle specification as a first code; encoding the plurality of inventory specifications as a plurality of respective second codes; and mapping the target vehicle specification and the plurality of inventory specifications into a multidimensional specification space, where the multidimensional specification space includes one dimension for each specification category of the target vehicle specification; with a preference class vector stored in a second memory, storing a respective weight for each dimension of the multidimensional specification space; with a matching engine: based on the preference class vector, defining a search neighborhood around the target vehicle specification in the multidimensional specification space; identifying inventory specifications of the plurality of inventory specifications that fall within the search neighborhood; and for each identified inventory specification: computing a match score; and reporting, to the user, the match score and the vehicle corresponding to the identified inventory specification. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. In some embodiments, the first code and the plurality of second codes are SR codes. In some embodiments, the first code and the plurality of second codes are hexadecimal strings. In some embodiments, the specification categories of the target vehicle specification include at least one of an exterior color, an interior color, an engine type, a transmission type, an accessory, or a trim package. In some embodiments, the instructions further may include, with a user feedback module: receiving user feedback regarding the vehicles corresponding to the identified inventory specifications; and based on the user feedback, updating the preference class vector. In some embodiments, the instructions further may include, with a specification manager, based on changes in the vehicle inventory, updating the database may include the plurality of inventory specifications. In some embodiments, the instructions further may include, with a tightness updater: based on the mapped target vehicle specification, the mapped plurality of inventory specifications, and the search neighborhood, computing a tightness for the target vehicle specification; and reporting the tightness to the user, or to a dealer or manufacturer. In some embodiments, the instructions further may include, with a gap glut analyzer: based on a plurality of target vehicle specifications and the plurality of inventory specifications, computing a gap-glut estimate; and reporting the gap-glut estimate to a dealer or manufacturer. In some embodiments, the instructions further may include, with a goal maximizer, based on the gap-glut estimate: requesting changes to the vehicle inventory; or adjusting prices of at least some vehicles in the vehicle inventory. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

One general aspect includes a computer implemented method. The computer implemented method includes defining a vehicle specification format that may include a plurality of specification categories. The method also includes defining a specification code format that may include at least one digit for each specification category of the plurality of specification categories. The method also includes receiving a vehicle specification in the vehicle specification format. The method also includes mapping the vehicle specification into the specification code format. The method also includes representing the mapped vehicle specification as a two-dimensional SR code. The method also includes storing the two-dimensional SR code. The method also includes receiving a user request. The method also includes, based on the user request, electronically transmitting the two-dimensional SR code to a second processor. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. A more extensive presentation of features, details, utilities, and advantages of the vehicle supply management system, as defined in the claims, is provided in the following written description of various embodiments of the disclosure and illustrated in the accompanying drawings.

In accordance with at least one embodiment of the present disclosure, a vehicle supply management system is provided which allows purchasers to find the available vehicles that most closely match their preferences, and allows manufacturers to manufacture and ship vehicles based on detailed knowledge of gaps and/or gluts in the current vehicle supply, at the level of configuration dimensions, utilizing real-time capture and aggregation of individual utility functions.

1. Capture, encode, transmit, display, decode vehicle specification information using a universal specification record (SR) code. The SR code may be a two-dimensional bar code that is similar in some respects to a quick response (QR) code. 2. On-demand personalized consumer-utility based search and matching of encoded vehicle specifications against a user defined target specification, presenting the user with vehicles most similar to the specification, and receiving real-time feedback for adaptive learning of customer preferences, and the weightings thereof. 3. Estimate dynamic market tightness of any given configurations using customer-specific utilities, preferences, desired specification, and matched specification outcomes. 4. Estimate gaps and gluts of any specification in the current vehicle supply, using customer-preference-driven neighborhood demand profiles and supply profiles. 5. Match and score any two vehicles based on their respective specifications using SR code scanning from a standard mobile app. There is no utility or application that addresses the following business needs:

The present disclosure provides a system and method for a utility or application that provides these features, and thus provides a new automotive standard for sharing, consumption, and transmission of specification information. Today, vehicle specifications are stored in a key-value store. Option specification information is highly sparse and continuously growing, making it very hard to store and process in an effective manner. The vehicle supply management system can provide user-driven vehicle specification matching and scoring based on user specified preferences and utilities, and can analyze demand and supply gap/glut by incorporating user preferences on vehicle specification sets, and aids in planning to actively manage the gaps and/or gluts in the current vehicle supply.

This vehicle supply management system transforms the specification information capture, dissemination and processing by leveraging the sparse information structure and performing on-line, low-dimensional embedding in terms of an SR code. This low dimensional embedding allows efficient storage and dissemination. Any loss of information during decoding can be recaptured using an effective rules engine that facilitates the accuracy of decoded information.

The vehicle supply management system of the present disclosure uses a real-time, user-feedback-based classification system to identify a user preference/utility class, which is then mapped to a specification category and class-defined weight functions. Given a user-defined target vehicle specification, the system performs the low-dimensional embedding of this target specification and stores it in the local system (e.g., an app on the user's mobile device, or a web app accessible from a laptop, etc.). A vehicle is displayed with its specification SR code. When a vehicle is selected, the calculator first computes a vector-valued function of the bit-wise difference (logical and/or/xor) between the target specification SR code and the selected vehicle's SR code. Each computed value is mapped to a specification category. The class- and category-dependent weights are then multiplied to appropriate computed values and aggregated to form a match score, which is displayed to the user. The user's feedback is evaluated and used to update the class prediction module.

The vehicle supply management system uses the target specification, customer preferences and the matched vehicle specification codes to compute and update a tightness factor, which describes demand and supply at the regional level for each target specification. The tightness is high when the match scores are consistently low, indicating low supply to customer demand specification and vice versa. As the supply situation changes or demand declines, it is expected that the tightness factor will decrease. The tightness factor is used to control the display of match results to the user, thus providing active management of market demand for certain high-demand specifications. This control is applied to keep the tightness ranges within certain specified threshold ranges.

The vehicle supply management system uses the preference class and population estimates for each preference class to evaluate expected specification level gap and glut over the planning horizon. Specification category weights for the class define a smoothening kernel that is used to evaluate estimated demand profile in a specification space (e.g., a multidimensional space with one axis per vehicle option or specification). Similarly, a supply profile is created in the specification space, given the dealer stock and pipeline vehicles. The gap and glut is then computed using the difference between the demand profile and supply profile within the specification space.

The present disclosure aids substantially in the buying and selling of vehicles, by matching customer demand to available vehicles, as well as providing detailed information about in-demand vehicle specs or options that should be added to the available supply. These features are accomplished by improving the encoding, decoding, and analysis of vehicle spec information. Implemented on processors in communication with a user and a database, the vehicle supply management system disclosed herein provides practical improvements in vehicle supply chain management. This improved knowledge of the relationship between customer demand and available supply allows each user to obtain the vehicle closest to their needs, without the normally routine need to custom-manufacture a vehicle to meet customer's specifications, and/or to match customers with vehicles that do not meet all of their specifications. This unconventional approach improves the functioning of the supply chain management computers, by reducing the amount of computation required to match vehicles to customers, and by improving the accuracy of the matches.

The vehicle supply management system may be implemented as a process at least partially viewable on a display, and operated by a control process executing on a processor that accepts user inputs from a keyboard, mouse, or touchscreen interface, and that is in communication with one or more databases. In that regard, the control process performs certain specific operations in response to different inputs or selections made at different times. Outputs of the vehicle supply management system may be printed, shown on a display, or otherwise communicated to human operators. Certain structures, functions, and operations of the processor, display, sensors, and user input systems are known in the art, while others are recited herein to enable novel features or aspects of the present disclosure with particularity.

These descriptions are provided for exemplary purposes only, and should not be considered to limit the scope of the vehicle supply management system. Certain features may be added, removed, or modified without departing from the spirit of the claimed subject matter.

For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It is nevertheless understood that no limitation to the scope of the disclosure is intended. Any alterations and further modifications to the described devices, systems, and methods, and any further application of the principles of the present disclosure are fully contemplated and included within the present disclosure as would normally occur to one skilled in the art to which the disclosure relates. In particular, it is fully contemplated that the features, components, and/or steps described with respect to one embodiment may be combined with the features, components, and/or steps described with respect to other embodiments of the present disclosure. For the sake of brevity, however, the numerous iterations of these combinations will not be described separately.

1 FIG. 1 FIG. 100 105 100 100 105 1050 is a schematic, diagrammatic representation, in hybrid flow diagram and block diagram form, of an example vehicle supply management method, executable by a vehicle supply management system, in accordance with at least one embodiment of the present disclosure. It is understood that the blocks of methodmay be performed in a different order than shown in, additional blocks can be provided before, during, and after the steps, and/or some of the blocks described can be replaced or eliminated in other embodiments. One or more of blocks of the methodcan be carried by one or more devices and/or systems described herein, such as components of the systemand/or processor circuit.

100 108 110 115 130 120 125 160 110 185 190 192 194 108 194 196 190 196 180 The methodbegins with preference classesand a user-defined target spec, the details of which are provided below. These are received by a prediction enginethat predicts the user preference class, which is then passed to a spec score match calculator. The spec score match calculator also has access to class weights, spec categories, and spec supply profiles(e.g. profiles of the currently available vehicles), and produces a score describing how well any given vehicle matches the user-defined target spec. These scores are then passed to a spec search and matching engine, which passes vehicle matches to a reporting module. User feedback(e.g. via a user feedback nodule) is then collected, and passed to a tightness updates, as well as being used to update the preference classes(e.g., the weights for each specification, as described below). The tightness updaterupdates the spec tightness profiles, which may be passed to the reporting module. Spec tightness profilesare also passed, along with business objectives, to the expected goal maximizer, which may for example determine which vehicles to manufacture in order to reduce gaps and gluts.

160 135 140 155 145 150 160 165 160 165 170 180 135 140 To update the spec supply profiles, new order eventsand order change eventsare fed to a spec manager, which receives information from a spec encoderand a spec decoder, and which updates the spec supply profiles. The user-defined target spec is also used to update spec demand profiles. Both the supply profilesand the demand profilesare fed to the gap-glut analyzer, whose outputs are received by the goal maximizer, whose outputs may include new order eventsand new order change events.

Flow diagrams and block diagrams are provided herein for exemplary purposes; a person of ordinary skill in the art will recognize myriad variations that nonetheless fall within the scope of the present disclosure. For example, any of the steps described herein may optionally include an output to a user of information relevant to the step, and may thus represent an improvement in the user interface over existing art by providing information not otherwise available.

Similarly, block diagrams may show a particular arrangement of components, modules, services, steps, processes, or layers, resulting in a particular data flow. It is understood that some embodiments of the systems disclosed herein may include additional components, that some components shown may be absent from some embodiments, and that the arrangement of components may be different than shown, resulting in different data flows while still performing the methods described herein.

Similarly, the logic of flow diagrams may be shown as sequential. However, similar logic could be parallel, massively parallel, object oriented, real-time, event-driven, cellular automaton, or otherwise, while accomplishing the same or similar functions. In order to perform the methods described herein, a processor may divide each of the steps described herein into a plurality of machine instructions, and may execute these instructions at the rate of several hundred, several thousand, several million, or several billion per second, in a single processor or across a plurality of processors. Such rapid execution may be necessary in order to execute the method in real time or near-real time as described herein. For example, once a user has provided their preferences for a new vehicle, the system may have to, in real time, search a specification space containing thousands of vehicles, and return the five or ten vehicles that most closely match the user's preferences, all within the span of less than one second, to avoid an impression of lag or latency on the part of the user. It is noted that such search engine functions, where large, multidimensional data spaces are searched in real time for sparse data, cannot practically be performed in the human mind, and that searches performed by a human, even given much longer timescales, typically return fewer and less relevant results.

2 FIG. 2 FIG. 200 220 210 is a schematic, diagrammatic representation of an example vehicle searching process, in accordance with at least one embodiment of the present disclosure. In the example shown in, a new user-defined target specificationis represented as a specification record (SR) code, a two-dimensional barcode which encodes all of the customer's preferences for each specification, or “no preference” for specifications that are not important to the customer. For example, a customer may state (e.g., through the mobile application) that they firmly desire a given make and model of vehicle (e.g., a Toyota Prius), and mildly prefer a blue exterior and black interior, and weakly prefer leather seats. Other features, not specified by the user, may be listed as having no preference.

220 230 230 2 FIG. The target specificationis then mapped into a location or position vector in a multidimensional specification space, which may for example have one axis or dimension per vehicle option or specification. In the example shown in, the spec spacehas only three dimensions, but it is understood that in practice it could have hundreds or even thousands of dimensions. Order change events may then trigger the spec encoder thus update the encoded vector.

240 230 230 240 230 The supply of available vehiclesis also mapped into the spec space, in such a way that similar vehicles are closer to one another in spec space, whereas dissimilar vehicles are farther from one another. An addition event (e.g., new vehicles arriving at a location) or deletion event (e.g., a vehicle being sold) may add or remove vehiclesfrom the spec space.

250 220 230 260 260 A neighborhood or match regionis defined around the target specification, and may for example be an ellipsoid whose diameter along any given dimension is defined by the weight given to that parameter, with strong preferences resulting in a small diameter and “no preference” resulting in a large or infinite diameter. A search of the spec spacemay for example build a space partitioning tree on encoded spec vectors with these user-defined distance metrics, resulting in personalized matching using user defined preferences, target SR and inventory SR codes. This results in a listof matching vehicles. The listmay for example include the dealer number, vehicle identification number (VIN), and estimated time of arrival (ETA) of each vehicle. For example, if the vehicle is located at the same dealership where the customer is currently shopping, then the ETA may be zero, whereas if the vehicle is located at a distant dealership, or is still in a manufacturer lot, then the ETA may be several days.

270 250 250 6 FIG. Also generated is a demand/supply table, which includes the regions in which matching vehicles are found, a demand index indicating demand in that region for vehicles within the target spec neighborhood, a supply index indicating supply in that region for vehicles within the target spec neighborhood, and a tightness score relating supply and demand within that region for vehicles within the target spec neighborhood. Calculation of the tightness score is described below in.

3 FIG. 3 FIG. 300 220 320 310 220 210 330 210 330 340 350 360 399 320 is a schematic, diagrammatic representation of an example vehicle searching process, in accordance with at least one embodiment of the present disclosure. In the example shown in, a new user-defined target specificationis constructed when the user answers questions via an applicationrunning on a mobile device. The user-defined target specificationis then represented as an SR code, which encodes all of the customer's preferences for each specification, or “no preference” for specifications that are not important to the customer. Similarly, each available vehicle is represented as an inventory spec SR code. These specs,are received by a spec differentiator or spec scorer, whose scores are then passed to a mapping blockand a weighting block. The scoresare then reported to the user via the app(e.g., displayed on a screen, or otherwise).

360 395 3 FIG. The weighting blockmakes use of a preference class, which is a vector containing a weight for each specification category (e.g., each axis of the multidimensional specification space), with larger weights indicating more importance and a zero value indicating low or zero importance. In the example shown in, The preference class is a matric with each row containing a binary value representing the weight for that spec category.

395 370 380 390 395 Initially, the preference classmay be a default preference class aggregated across all users. However, a user feedback blockcan be used to allow the user to rate the suggested vehicle matches (e.g., a binary rating of yes/no, or a numerical score, etc.). This information can then be used to update the classifier model weights, which are fed to the user preference class predictor, and used to update the preference class. In an example, every time the user expresses a preference or non-preference for a given vehicle, the system can use this information to deduce the weighting the user is applying (whether consciously or otherwise) to each spec category.

4 FIG. 4 FIG. 400 410 145 420 420 430 440 221 330 is a schematic, diagrammatic representation of an example specification SR code encoder/decoder, in accordance with at least one embodiment of the present disclosure. In the example shown in, the spec change events hubsends a new vehicle specification (whether a demand spec or a supply/inventory spec) to the spec encoder, which encodes it as a 60-digit hexadecimal code or string(e.g., 8 digits for series, model, year, and grade, 8 digits for power train, drive train, transmission, and engine, 16 digits for interior and exterior color, 4 digits for bed length, cab type, and seating, etc.). This stringis fed into a low-dimensional network encoderto yield a 4×4 hexadecimal matrix, which can be represented as an SR codeor.

150 440 450 460 To decode, the 4×4 hexadecimal matrix is fed into a spec decoder, where a network decoderunpacks it back into a 60-digit hexadecimal string. Lost information is then restored by a spec rules validator/corrector, which receives a spec options guide tablethat contains information such as the series code, model code, model year, model grade, and other specifications as needed to restore the missing information.

145 150 210 330 It is noted that the spec encoderand spec decodermay reside on a user device, a dealer/manufacturer device, or both. Depending on the implementation, mapping of the target vehicle specand the inventory specsinto the multidimensional specification space may also be performed by the spec encoder.

5 FIG. 5 FIG. 5 FIG. 5 FIG. 221 330 510 520 530 540 560 520 530 540 550 560 221 330 is an example SR codeor, in accordance with at least one embodiment of the present disclosure. In the example shown in, the SR code includes three corner markers, a manufacturer code regionfor storing manufacturing related specifications, a main code regionfor storing model, power train, drive train, transmission, engine related specifications, an option code regionfor storing vehicle options, a color code region for storing vehicle exterior and interior colors, and a miscellaneous code regionfor storing bed length, cab type and seating related specifications. It is understood that the regions,,,, andmay be of different dimensions or location than shown in, or that the information stored in the SR code,may be organized differently than shown in, without departing from the spirit of the present disclosure.

6 FIG. 6 FIG. 600 210 185 194 185 610 is a schematic, diagrammatic representation, in block diagram form, of an example customer demand-supply tightness calculator, in accordance with at least one embodiment of the present disclosure. In the example shown in, a customer sales order or target SR codeis fed into both a specification match and search engineand a tightness update model. The specification match and search engineproduces match results, each of which includes a match SR code and a match score.

t t The tightness update model yields a tightness score for the target SR, where:Tightness(SR)=(1−LR)*Tightness(SR)+LR*(1−max(MatchScore))  EQN. 1where LR is a tunable learning rate.

210 Thus, the tightness can be updated every time a new customer orderis received, or the vehicle inventory is updated (e.g., because new vehicles are shipped to a region). It is noted that there may be significant regional variation in the desirability of different vehicle models and options. For example, four-wheel drive (4WD) and all-wheel drive (AWD) may be more popular in regions where it snows, whereas a sunroof may be more popular in regions with plentiful sunshine and temperate weather.

If tightness for a particular vehicle configuration or spec category falls outside of a pre-defined acceptable range for a given region, the system may for example issue an alert, notifying dealers and/or manufacturers that there is a shortage of vehicles with the specified configuration or spec category within the specified region, or globally of the tightness is detected across multiple regions.

7 FIG. 7 FIG. 185 185 730 710 720 410 730 740 750 760 210 320 is a schematic, diagrammatic representation, in block diagram form, of an example specification search and match engine, in accordance with at least one embodiment of the present disclosure. In the example shown in, the specification search and match engineincludes a partition generator and updater, which receives an order change event streamand a production confirmation/dealer allocation/retail delivery record (Procon/DA/RDR) event streamfrom the vehicle spec change events hub. The partition generator and updatergenerates specification partitionsin the specification space utilizing a tree-based space partitioning method to iteratively slice the space in each dimension in two nearly equally populated partitions every iteration. During the search process, this partitioning helps direct the algorithm in a direction where it is most likely to find specifications which are similar to the queried specification, and is used by the partition search and matching engineto identify matchesin response to user requestsfrom a querying application.

8 FIG.A 810 240 230 240 is a two-dimensional slice or projectionof the vehicle specsin the multidimensional spec space, with each axis representing a particular spec category (e.g., exterior color and interior color), in accordance with at least one embodiment of the present disclosure. Each dot or vehicle specwithin the slice or projection represents a vehicle in the current dealer/manufacturer inventory.

8 FIG.B 3 FIG. 810 240 230 220 810 230 250 220 395 810 250 395 is a two-dimensional slice or projectionof the vehicle specsin the multidimensional spec space, in accordance with at least one embodiment of the present disclosure. Each dot within the slide or spec represents a vehicle in the current dealer/manufacturer inventory. A target specis defined as a location within the slice or projectionof the spec space, and a match region or target neighborhooddefines the vehicles that are considered close enough to meet the customer's desires, as defined by the target specand the weights defined in the preference class(see). Within the 2-dimensional slice or projection, the diameters or semimajor axes of the match region or target neighborhoodare a function of the weights in the preference class, as described above.

9 FIG. 9 FIG. 170 910 210 930 920 395 930 940 230 940 940 230 is a schematic, diagrammatic representation of an example gap-glut analyzer, in accordance with at least one embodiment of the present disclosure. In the example shown in, customer search data target spec vectorsare extracted from a plurality of customer target spec SR codes, and are fed into an unconstrained spec demand profile estimator, along with customer preference class weights, which are extracted from the customer preference class. The unconstrained spec demand profile estimatorthen produces an estimated spec demand profilein the multidimensional spec space, where each occupied point in the spec demand profilerepresents a vehicle desired by a customer. The spec demand profilemay be represented as a surface in the multidimensional spec space.

230 950 960 970 230 970 970 230 In parallel, in-stock vehicle specifications(e.g., SR codes for vehicles in inventory) and pipeline specifications(e.g., SR codes for vehicles in transit or production) are fed to a spec supply estimator, which produces an estimated spec supply profilein the multidimensional spec space, where each occupied point in the spec supply profilerepresents a vehicle currently in inventory or expected to soon be in inventory. The spec supply profilemay be represented as a surface in the multidimensional spec space.

940 970 980 940 970 970 940 940 970 990 The estimated spec demand profileand the estimated spec supply profileare fed to a differentiator, which looks at the difference or distance between the spec demand profileand the spec supply profile. Any points in the spec supply profilefor which there are no nearby points in the spec demand profilerepresent “glut” vehicles, for which there is supply but no demand. Similarly, any points in the demand supply profilefor which there are no nearby points in the spec supply profilerepresent “gap” vehicles, for which there is demand but no supply. This information is captured in a gap-glut estimate. In an example, the dealer or manufacturer may choose to discount glut vehicles in order to increase demand. This may be particularly useful in implementations where price is a highly weighted customer preference, such that if there is low demand for, e.g., white vehicles, the demand can be increased by dropping the price of white vehicles. It may also be desirable to decrease the number of undesired vehicles being manufactured.

180 1 FIG. Similarly, the dealer may choose to order, and/or the manufacturer may choose to manufacture, gap vehicles to address the unmet demand (e.g., request changes to the existing vehicle inventory). For example, if there is high demand and limited supply for red vehicles, the manufacturer may choose to manufacture more red vehicles, or to repaint existing vehicles whose colors are in low demand, or to raise the price of red vehicles in order to reduce the demand-supply gap. In some embodiments, these actions may be recommended by and/or performed automatically by the goal maximizerof.

10 FIG. 1050 1050 105 1100 310 1050 1060 1064 1068 is a schematic diagram of a processor circuit, in accordance with at least one embodiment of the present disclosure. The processor circuitmay be implemented in the system, the system, the mobile device, or other devices or workstations (e.g., third-party workstations, network routers, etc.), or on a cloud processor or other remote processing unit, as necessary to implement the method. As shown, the processor circuitmay include a processor, a memory, and a communication module. These elements may be in direct or indirect communication with each other, for example via one or more buses.

1060 1060 1060 The processormay include a central processing unit (CPU), a digital signal processor (DSP), an ASIC, a controller, or any combination of general-purpose computing devices, reduced instruction set computing (RISC) devices, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other related logic devices, including mechanical and quantum computers. The processormay also comprise another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein. The processormay also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

1064 1060 1064 1064 1066 1066 1060 1060 1066 The memorymay include a cache memory (e.g., a cache memory of the processor), random access memory (RAM), magnetoresistive RAM (MRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory device, hard disk drives, other forms of volatile and non-volatile memory, or a combination of different types of memory. In an embodiment, the memoryincludes a non-transitory computer-readable medium. The memorymay store instructions. The instructionsmay include instructions that, when executed by the processor, cause the processorto perform the operations described herein. Instructionsmay also be referred to as code. The terms “instructions” and “code” should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms “instructions” and “code” may refer to one or more programs, routines, sub-routines, functions, procedures, etc. “Instructions” and “code” may include a single computer-readable statement or many computer-readable statements.

1068 1050 1068 1068 1050 105 1068 1050 2 The communication modulecan include any electronic circuitry and/or logic circuitry to facilitate direct or indirect communication of data between the processor circuit, and other processors or devices. In that regard, the communication modulecan be an input/output (I/O) device. In some instances, the communication modulefacilitates direct or indirect communication between various elements of the processor circuitand/or the system. The communication modulemay communicate within the processor circuitthrough numerous methods or protocols. Serial communication protocols may include but are not limited to United States Serial Protocol Interface (US SPI), Inter-Integrated Circuit (IC), Recommended Standard 232 (RS-232), RS-485, Controller Area Network (CAN), Ethernet, Aeronautical Radio, Incorporated 429 (ARINC 429), MODBUS, Military Standard 1553 (MIL-STD-1553), or any other suitable method or protocol. Parallel protocols include but are not limited to Industry Standard Architecture (ISA), Advanced Technology Attachment (ATA), Small Computer System Interface (SCSI), Peripheral Component Interconnect (PCI), Institute of Electrical and Electronics Engineers 488 (IEEE-488), IEEE-1284, and other suitable protocols. Where appropriate, serial and parallel communications may be bridged by a Universal Asynchronous Receiver Transmitter (UART), Universal Synchronous Receiver Transmitter (USART), or other appropriate subsystem.

External communication (including but not limited to software updates, firmware updates, preset sharing between the processor and central server, or communication between a user device and a dealer/manufacturer device, may be accomplished using any suitable wireless or wired communication technology, such as a cable interface such as a universal serial bus (USB), micro USB, Lightning, or FireWire interface, Bluetooth, Wi-Fi, ZigBee, Li-Fi, or cellular data connections such as 2G/GSM (global system for mobiles), 3G/UMTS (universal mobile telecommunications system), 4G, long term evolution (LTE), WiMax, or 5G. For example, a Bluetooth Low Energy (BLE) radio can be used to establish connectivity with a cloud service, for transmission of data, and for receipt of software patches. The controller may be configured to communicate with a remote server, or a local device such as a laptop, tablet, or handheld device, or may include a display capable of showing status variables and other information. Information may also be transferred on physical media such as a USB flash drive or memory stick.

11 FIG. 1100 1100 1102 310 1104 1130 is a schematic, diagrammatic representation, in block diagram form, of an example vehicle supply management system, in accordance with at least one embodiment of the present disclosure. The systemincludes elements on a demand sidewhich includes a user device, and a supply sidewhich includes a dealer/manufacturer device.

310 1110 1120 320 320 1110 210 192 185 1130 The user deviceincludes a user interface, memory, and a demand matching application. The demand matching applicationreceives inputs from the user, via the user interface, and produces the user demand spec or target spec, as well as user feedback(e.g., via a user feedback module) on the desirability of matched vehicles, both of which are communicated to a spec search and matching engineon the dealer/manufacturer device.

1130 1140 1150 1150 240 155 130 170 180 180 1140 The dealer/manufacturer deviceincludes a user interfaceand memory. Operatively stored within the memoryare the supply specs(e.g., within a supply specs database), spec manager, spec score match calculator, gap-glut analyzer, and goal maximizer. The goal maximizermay for example provide a report that is viewable or otherwise accessible via the user interface.

185 190 1130 320 310 11 FIG. The spec searching and matching engineand reportingare shown inas executing on the dealer/manufacturer device(e.g., when triggered by the demand matching application). However, in some embodiments, these blocks, or portions thereof, may execute on the user device.

310 1130 It is noted that the user device or customer deviceand the dealer device or manufacturer devicemay be in network communication with one another, e.g., via a wireless Internet or cellular connection, and may thus not need to be in proximity to one another.

12 FIG. 1200 1200 is a schematic, diagrammatic representation, in flow diagram form, of an example vehicle matching method, in accordance with at least one embodiment of the present disclosure. The methodmay be performed in real time.

1210 1200 1220 In block, the methodincludes storing a plurality of inventory specifications of a respective plurality of available vehicles. Execution then proceeds to block.

1220 1200 1230 In block, the methodincludes, based on inputs from the user, generating a target vehicle specification. Execution then proceeds to step.

1230 1200 1230 In block, the methodincludes mapping the target vehicle specification and the plurality of inventory specifications into a multidimensional specification space that includes one dimension for each specification category of the target vehicle specification. Execution then proceeds to step.

1240 1200 1230 In block, the methodincludes storing a respective weight for each dimension of the multidimensional specification space. These weights may be based at least in part on the inputs from the user. For example, if the user states an order of preference for spec categories within the target vehicle spec, then this order can be used to define the weights. Execution then proceeds to step.

1250 1200 1230 In block, the methodincludes, based on the weights for each dimension of the multidimensional space, defining a search neighborhood around the target vehicle specification in the multidimensional specification space. Execution then proceeds to step.

1260 1200 1230 In block, the methodincludes identifying those inventory specifications, of the plurality of inventory specifications, that fall within the search neighborhood. Execution then proceeds to step.

1270 1200 1200 In block, the methodincludes, for each identified inventory specification within the search neighborhood, reporting, to the user, the available vehicle corresponding to the identified inventory specification. The methodis now complete.

1. The ability to efficiently encode and decode vehicle specifications in a convenient, information-dense, machine-readable format. 2. The ability to effectively store, consume and transmit vehicle specification data. 3. The ability to capture user preferences and utility functions in the specification space, and classify them accordingly. 4. The ability to partition specification space for efficient search, matching and comparing. 5. The ability to apply class-based and spec-category-based weights to compute a personalized match score between a given vehicle specification and user defined target specification. 6. The ability to obtain user feedback on the match results, and update the class prediction model (e.g., the weights) and the classifier outputs accordingly. 7. The ability to compute customer preference and specification level tightness of demand and supply. 8. The ability to manage and control the matching and search function to ascertain whether tightness values lie within a pre-specified range. 9. The ability to leverage user-defined target specifications to estimate specification demand profiles. 10. The ability to compute and estimate gap and glut over the specification space by applying class-specific weights defined neighborhood skewness. In some embodiments, the neighborhood does not have to be symmetric in every direction. Rather, the skewness can be defined by the customer preferences and utilities along one direction over another. This skewness is reflected into the gap and glut estimates by biasing the gap or glut in a direction that is more preferred by the customers. 11. The ability to dynamically adjust the supply pool through change of order specifications to minimize expected gap-glut, regional tightness and/or achieving a given business objective over the planning period. As will be readily appreciated by those having ordinary skill in the art after becoming familiar with the teachings herein, the vehicle supply management system disclosed herein adds at least the following capabilities to existing vehicle supply chains:

Accordingly, it can be seen that the vehicle supply management system fills a long-felt need in the art, by providing user-friendly tools that help customers find the right vehicle and help dealers and manufacturers adjust their supply to meet demand.

A number of variations are possible on the examples and embodiments described above. For example, tightness, match scores, and gap-glut estimates may be calculated differently than described herein. SR codes may be replaced with QR codes, bar codes, hexadecimal strings, or other machine-readable or human-readable codes representing the target spec and supply specs. The encoding scheme (e.g., number of digits, etc.) may be different than described herein, without departing from the spirit of the present disclosure.

The logical operations making up the embodiments of the technology described herein are referred to variously as operations, steps, blocks, objects, elements, components, or modules. Furthermore, it should be understood that these may occur or be performed or arranged in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.

All directional references e.g., upper, lower, inner, outer, upward, downward, left, right, lateral, front, back, top, bottom, above, below, vertical, horizontal, clockwise, counterclockwise, proximal, and distal are only used for identification purposes to aid the reader's understanding of the claimed subject matter, and do not create limitations, particularly as to the position, orientation, or use of the vehicle supply management system. Connection references, e.g., attached, coupled, connected, joined, or “in communication with” are to be construed broadly and may include intermediate members between a collection of elements and relative movement between elements unless otherwise indicated. As such, connection references do not necessarily imply that two elements are directly connected and in fixed relation to each other. The term “or” shall be interpreted to mean “and/or” rather than “exclusive or.” The word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. Unless otherwise noted in the claims, stated values shall be interpreted as illustrative only and shall not be taken to be limiting.

The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the vehicle supply management system as defined in the claims. Although various embodiments of the claimed subject matter have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of the claimed subject matter.

Still other embodiments are contemplated. It is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative only of particular embodiments and not limiting. Changes in detail or structure may be made without departing from the basic elements of the subject matter as defined in the following claims.