Payment-driven Sourcing

Abstract

Systems, methods and products for one embodiment comprises a method including providing a demand model which generates a payment in response to receiving input identifying a consumer profile and a vehicle type. A cashflow model is provided, and in response to receiving the payment output by the demand model and a desired return on a converted vehicle transaction, the cashflow model generates an acquisition price as an output. A comparison engine is provided which, in response to receiving the acquisition price output by the cashflow model, retrieves vehicle inventory records and compares a corresponding purchase price to the acquisition price to determine whether the corresponding vehicle is qualified. A list of qualified vehicles for a given consumer profile and vehicle type is stored and used to generate real time displays of qualified vehicles (with no unqualified vehicles) in response to a request from a specific consumer having this profile.

Description

RELATED APPLICATIONS

[0001] This application claims priority under 35 U.S.C. .sctn. 119(e) to United States Provisional Patent Application No. 62/868,535, entitled "PAYMENT-DRIVEN SOURCING", filed Jun. 28, 2019, and U.S. Provisional Patent Application No. 62/883,374, entitled "DEMAND-BASED PRICING", filed Aug. 6, 2019, which are fully incorporated herein by reference for all purposes.

TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of data processing systems and methods, and more particularly to data processing systems and methods for determining requirements associated with a consumer and an operator of an automotive data processing system, identifying vehicles that are available to the automotive data processing system from one or more dealers, determining which of the available vehicles meet the requirements of the consumer and system operator, and generating displays that include only ones of the available vehicles that meet the identified requirements.

BACKGROUND

[0003] Internet-based systems and other computer systems that facilitate purchasing (buying or leasing) various goods and services from multiple sellers have become increasingly popular tools for both consumers and sellers. Intermediary search sites allow users to search for items (e.g., vehicles) from a large number of available items. When a user selects a vehicle, the intermediary site typically puts the buyer in touch with the dealer to finalize a business transaction on the vehicle. The consumer may schedule a test drive with the dealership and may thereafter choose to, for example, lease the vehicle. In order to complete the lease transaction, the lease payments and the residual value of the vehicle must typically be determined.

[0004] In many conventional internet-based systems for facilitating vehicle purchase or lease transactions, the operators of these systems may be caught in the middle between sellers that want to get high prices for their vehicles and consumers who want to obtain the vehicles at the lowest possible price. The system operator's costs to operate the system and facilitate the transactions may be constrained by the competing interests of the sellers and consumers, so that it is not profitable to provide their services in facilitating the transactions (or not as profitable as desired). Conventional systems do not provide the ability to source the vehicles (purchase them from sellers) in a way that ensures that the system achieves a desired return on the transactions.

SUMMARY

[0005] Embodiments of the present invention are designed to enable acquisition of inventory items at prices which meet a system operator's business goals as well as a consumer's payment needs. Embodiments disclosed herein also provide means for rapidly identifying, retrieving and providing to consumers items which meet these requirements.

[0006] The present systems and methods use information relating to payments by the consumer, as well as information relating to the system operator's services (e.g., a required level of profitability) to determine which of a seller's products meet the constraints associated with both the consumer and the system operator. Then, these products are presented to the consumer so that the system operator can be confident that its own requirements, such as a desired net return, can be met. In one embodiment, a consumer-facing price is determined without regard to the price for a vehicle set by a seller. The consumer-facing price is used in conjunction with expense information and a desired rate of return to determine a target vehicle acquisition price. This target price is then compared to prices which are set for vehicles by their respective sellers in order to determine which of the vehicles are priced at or below the target and may be presented to the consumer.

[0007] In one exemplary method, a demand model is used to determine a consumer payment without regard to particular vehicles that may be available to the consumer. The demand model uses historical transaction data to determine the demand for a particular type of vehicle with respect to a particular type of consumer. Based on the historical data, it can be determined how much this type of consumer is willing to pay for this type of vehicle. The resulting payment information can be provided to a cash flow model that also accepts a return-on-investment input. The cash flow model generates an acquisition price at which this type of vehicle can be acquired for lease to this type of consumer, while meeting the return requirements of the system operator. Again, this acquisition price is determined without regard to particular vehicles that may be available to the consumer. This acquisition price can then be compared to the vehicles of the indicated type that are available through the system. Those of the available vehicles which have a price that is equal to or less than the computed acquisition price are then made available to display to the identified type of consumer, while vehicles which have prices greater than the acquisition price are blocked from being displayed. The qualified vehicles (those which are available to this consumer type) may be contained in a list associated with the consumer type so that when a specific consumer who is identified as this type of consumer interacts with the system, the qualified vehicles for the consumer type can be quickly identified and presented to the specific consumer.

[0008] In one embodiment, this method is implemented in a rules-based data processing system which may include a processor and a memory coupled to the processor to store a set of computer instructions executable by the processor. The system uses a demand model to determine a monthly payment corresponding to a given consumer profile and a given vehicle type. The monthly payment is provided to a cashflow model, along with an expected return value, and the cashflow model produces an acquisition value that corresponds to the received monthly payment and expected return values. The acquisition value is then compared to a set of inventory vehicles to determine whether purchase prices of the inventory vehicles are less than or equal to the acquisition value. Vehicles for which the corresponding purchase price is less than or equal to the acquisition value (qualified vehicles) are made available for display to a consumer. Vehicles for which the corresponding purchase price is greater than the acquisition value are blocked from being displayed to the consumer. Identifiers for qualified vehicles may be stored in a list that is associated with the consumer profile so that the vehicles can be quickly identified when a consumer having the corresponding consumer profile uses the system.

[0009] One embodiment comprises an automotive data processing system having one or more processors that are communicatively coupled to one or more data storage devices. The processors are coupled to a non-transitory computer-readable medium that stores instructions which are executable by the processor to cause the processor to execute a demand model, a cashflow model and a comparison engine. The demand model is configured to, in response to receiving input identifying a consumer profile and a vehicle type, generate a corresponding payment as an output. The cashflow model receives the payment as an input and, in response to this input and input identifying a desired return on a converted vehicle transaction, generates an acquisition price as an output. The comparison engine is configured to receiving the acquisition price output by the cashflow model and to retrieve a set of vehicle inventory records and, for each of the vehicle inventory records. The comparison engine then compares a purchase price of each vehicle inventory record to the acquisition price and generates an indication of whether or not a vehicle corresponding to the vehicle inventory record is qualified. In one embodiment, the comparison engine determines that each vehicle is qualified if the corresponding purchase price is no more than the acquisition price. Otherwise, the vehicle is disqualified. A list of qualified vehicles corresponding to the consumer profile and a vehicle type is then generated. This list may be stored by the system for later use in generating real time displays of qualified vehicles in response to a request from a specific consumer (where unqualified vehicles are excluded from the displays).

[0010] In some embodiments, the demand model is configured to generate the payment by identifying, in a collection of historical transaction records, a subset of the historical transaction records that correspond to a specific combination of the consumer profile and the vehicle type. This subset of historical transaction records is ranked by corresponding prices, and a target price corresponding to a desired percentile of converted transactions represented by the historical transaction records is selected as the payment for the specified consumer profile and vehicle type. In one embodiment, a list of qualified vehicles is created for each of a plurality of unique combinations of consumer profiles and vehicle types. In response to a user request of a specific consumer, a corresponding one of the consumer profiles that is associated with the specific consumer is identified. A specific vehicle type associated with the user request is also identified. Then, one of the lists of qualified vehicles which corresponds to the identified consumer profile and vehicle type is retrieved. This list of qualified vehicles is used to generate a display which is presented in a user interface of a client computing device. The display includes one or more qualified vehicles from the retrieved list, but excludes disqualified vehicles.

[0011] It should be noted that, while the embodiments herein are described in terms of leasing vehicles, alternative embodiments may be used in the sale of vehicles, or in the sale or lease of items other than vehicles.

[0012] Other embodiments are also possible.

BRIEF DESCRIPTION OF THE FIGURES

[0013] The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore non-limiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale.

[0014] FIG. 1 is a high level block diagram of one embodiment of a network topology.

[0015] FIG. 2 is a diagram illustrating the operation of an automotive data processing system to generate an acquisition price for a vehicle in accordance with one embodiment.

[0016] FIG. 3 is a flow diagram illustrating the generation of an acquisition price for a vehicle in accordance with one embodiment.

[0017] FIG. 4 is a diagram illustrating the use of the generated acquisition price by the vehicle data system to identify qualified vehicles in accordance with one embodiment.

[0018] FIG. 5 is a flow diagram illustrating the use of a generated acquisition price to identify qualified vehicles in accordance with one embodiment.

[0019] FIG. 6 is a flow diagram illustrating the use of a list of qualified vehicles to generate displays responsive to a consumer having a given profile in accordance with one embodiment.

[0020] FIG. 7 is a diagrammatic representation of a distributed network computing environment in which some embodiments may be implemented.

DETAILED DESCRIPTION

[0021] The invention and various features and advantageous details thereof are explained more fully with reference to the exemplary, and therefore non-limiting, embodiments illustrated in the accompanying drawings and detailed in the following description and appendices. It should be understood, however, that the detailed description and the specific examples, while indicating the preferred embodiments, are given by way of illustration only and not by way of limitation. Descriptions of known programming techniques, computer software, hardware, operating platforms and protocols may be omitted so as not to unnecessarily obscure the disclosure in detail. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

[0022] The present disclosure is directed to systems and methods for enabling consumers to purchase or lease items such as vehicles online. For purposes of clarity, the systems and methods described herein will focus on the leasing of vehicles to consumers, but other embodiments may involve the leasing or purchase of vehicles or other items.

[0023] An automotive data processing system is configured to interact with consumers and vehicle sellers (e.g., automotive dealerships) via client applications running on the respective client devices of the users. The present systems and methods enable sellers to present vehicles that are available for lease to consumers. The sellers set purchase prices for the vehicles that are available through the system. Consumers may view one or more of the vehicles and may choose to lease one of the vehicles through the system. If this is the case, the automotive data processing system may perform various processing to facilitate the consumer's lease of the vehicle. In one embodiment, if the consumer wishes to proceed with the lease transaction, the selected vehicle is purchased by the operator of the automotive data processing system and is then leased to the consumer.

[0024] The system operator is compensated for the services that are provided in association with the lease transaction(s) by pricing the vehicle lease to the consumer at a level which is high enough that it is expected to cover the price at which the vehicle was purchased from the original seller and the associated costs (e.g., cost of capital, marketing, origination, servicing, depreciation, liquidation) and a net return, less the residual value. It is desirable for the operator of the automotive data processing system to be able to ensure that the acquisition price (the price at which the vehicle is required from the original seller) is low enough that the system operator makes a desired return on the vehicle. Because the vehicle seller, rather than the system operator, sets the price at which the vehicle may be acquired by the system operator, the system operator conventionally has no control over this price. The present systems and methods, however, provide means to ensure that the acquisition price is low enough to achieve the desired return on vehicles leased using the system.

[0025] The present systems and methods effectively achieve control of the acquisition prices of vehicles that may be leased by consumers by determining the payments that can be made by consumers, determining the desired return on the system operators investment in the leased vehicles, determining the acquisition price that is necessary to achieve the desired return, and limiting the vehicles that are available through the system only to those which are priced to provide the desired return. The present systems and methods use a demand model which determines the payment corresponding to a particular type of consumer and a particular type of vehicle, then providing this payment and a desired return to a cash flow model, which then determines a required acquisition price for that type of vehicle. The computed acquisition price can then be compared to vehicles of this type which have been made available by sellers through the system. Available vehicles which have prices at or below the acquisition price may be displayed to consumers who may potentially lease the vehicles, while available vehicles that have prices above the acquisition price are not displayed. Thus, it will be assured that any lease transaction that may be completed through the system will provide the desired return on the acquisition cost.

[0026] Some embodiments of the present systems and methods can be implemented in a data processing system that automates and facilitates a leasing process, including inventory selection, financing qualification and document generation. In an exemplary embodiment, the system facilitates selection of a vehicle by providing vehicle information to a consumer through an interface on a mobile device. In this context, a "consumer" is any individual, group of individuals, or business entity seeking to lease a vehicle (or other asset) through the system. The consumer may select a particular vehicle that is used as the basis for determining similarity (i.e., the other vehicles are compared to the selected vehicle). The similarity scores are used to identify vehicles similar to the consumer-selected vehicle, and the similar vehicles are presented to the consumer to facilitate the consumer's search for a vehicle that the consumer may wish to lease.

[0027] Embodiments of a system for facilitating transactions may be implemented in a network topology. FIG. 1 is a high level block diagram of one embodiment of an example topology. The network topology of FIG. 1 comprises an automotive data processing system 100 which is coupled through network 105 to client computing devices 110 (e.g. computer systems, personal data assistants, smart phones or other client computing devices). Network 105 may be, for example, a wireless or wireline communication network such as the Internet or wide area network (WAN), publicly switched telephone network (PSTN) or any other type of communication link. The system may further include one or more information provider systems 120, one or more dealer management systems (DMS) 122, inventory systems 124, department of motor vehicles (DMV) systems 126 or other systems.

[0028] Automotive data processing system 100 may provide a comprehensive computer system for automating and facilitating a leasing process including inventory selection, financing qualification, document generation and transaction finalization, as described in detail in U.S. Patent Application Pub. No. 2018/0204281, which is hereby incorporated by reference. The present disclosure focuses primarily on aspects of the system involving inventory selection, and more particularly components of the system relating to the ranking of displayed inventory items, the tracking of user actions associated with the displayed inventory items, and tuning of the ranking engine that generates the ranking of the displayed inventory items.

[0029] Using a client application 114 executing on a client device 110, a consumer user may search dealer inventory, apply for financing, select a vehicle of interest from a dealer and review and execute documents related to the lease of the vehicle, and execute automated clearing housing (ACH) transactions through automotive data processing system 100 to complete the transaction.

[0030] Turning briefly to the various other entities in the topology FIG. 1, dealers may use a dealer management system ("DMS") 122 to track or otherwise manage sales, finance, parts, service, inventory and back office administration needs. Since many DMS 122 are Active Server Pages (ASP) based, data may be obtained directly from a DMS 122 with a "key" (for example, an ID and Password with set permissions within the DMS 122) that enables data to be retrieved from the DMS 122. Many dealers may also have one or more web sites which may be accessed over network 105, where inventory and pricing data may be presented on those web sites.

[0031] Inventory systems 124 may be systems of, for example, one or more inventory polling companies, inventory management companies or listing aggregators which may obtain and store inventory data from one or more of dealers (for example, obtaining such data from DMS 122). Inventory polling companies are typically commissioned by the dealer to pull data from a DMS 122 and format the data for use on websites and by other systems. Inventory systems 124 may provide information on inventory vehicles that is used in the ranking of the vehicles when they are presented to a consumer, such as prices of the vehicles and locations of the vehicles.

[0032] DMV systems 126 may collectively include systems for any type of government entity to which a user provides data related to a vehicle. For example, when a user purchases a vehicle it must be registered with the state (for example, DMV, Secretary of State, etc.) for tax and titling purposes. This data typically includes vehicle features (for example, model year, make, model, mileage, etc.) and sales transaction prices for tax purposes. Additionally, DMVs may maintain tax records of used vehicle transactions, inspection, mileages, etc.).

[0033] Information provider systems 120 may be systems of entities that provide information used in approving a user or lease. Examples of information provider systems 120 may include computer systems controlled by credit bureaus, fraud and ID vendors, vehicle data vendors or financial institutions. A financial institution may be any entity such as a bank, savings and loan, credit union, etc. that provides any type of financial services to a participant involved in the lease of a vehicle. Information provider systems 120 may comprise any number of other various sources accessible over network 105, which may provide other types of desired data, for example, data used in identity verification, fraud detection, credit checks, credit risk predictions, income predictions, affordability determinations, residual value determinations or other processes.

[0034] Automotive data processing system 100 utilizes interfaces configured to, for example, receive and respond to queries from users at client computing devices 110, interface with information provider systems 120, DMS 122, inventory systems 124 and DMV systems 126, obtain data from or provide data obtained or determined by automotive data processing system 100 to any of information provider systems 120, DMS 122, inventory systems 124, DMV systems 126. It will be understood that the particular interface utilized in a given context may depend on the functionality being implemented by automotive data processing system 100, the type of network utilized to communicate with any particular entity, the type of data to be obtained or presented, the time interval at which data is obtained from the entities, the types of systems utilized at the various entities, etc. Thus, these interfaces may include, for example, web pages, web services, a data entry or database application to which data can be entered or otherwise accessed by an operator, APIs, libraries or other type of interface which it is desired to utilize in a particular context.

[0035] Client computing devices 110, 111 may comprise one or more computer systems with central processing units executing instructions embodied on one or more computer readable media where the instructions are configured to interface with automotive data processing system 100. A client computing device 110, 111 may comprise, for example, a desktop, laptop, smart phone or other device. According to one embodiment, a client computing device 110 is a mobile device that has a touchscreen display and relies on a virtual keyboard for consumer data input. Client application 114 may be a mobile application ("mobile app") that runs in a mobile operating system (e.g., Android OS, iOS), and is specifically configured to interface with automotive data processing system 100 to generate application pages for display to a consumer. In another embodiment, the client application 114 may be a web browser on a desktop computer or mobile device. A client computing device 111 may run an application through which a dealer portal can be accessed.

[0036] In accordance with one embodiment, a consumer can utilize client application 114 to register with automotive data processing system 100, view inventory, select a vehicle, apply for financing, review documents and finalize a sales transaction through a low friction mobile app running on a smart phone. Client application 114 can be configured with an interface module 115 to communicate data to/from automotive data processing system 100 and generate a user interface for inputting one or more pieces of information or displaying information received from automotive data processing system 100. In some embodiments, the application 114 may comprise a set of application pages through which application 114 collects information from the consumer or which client application 114 populates with data provided via an interface. Application 114 may collect information that is manually input by the consumer so that it can be processed by automotive data processing system 100 with other information associated with the consumer. This information can be used to determine, for example, the consumer's qualification for a vehicle lease, financing options available to the consumer, or pricing for particular vehicles. Application 114 may also collect automatically information associated with the consumer's views of displayed vehicles and identification of particular vehicles as favorites or subscribed vehicles. This information may be used to tune the weights that are applied to signals input to a ranking engine that determines an order in which vehicles are displayed to the consumer.

[0037] Vehicle data application 150 can comprise a set of processing modules to process obtained data or processed data to generate further processed data. Different combinations of hardware, software, and/or firmware may be provided to enable interconnection between different modules of the system to provide for the obtaining of input information, processing of information and generating outputs.

[0038] In the embodiment of FIG. 1, vehicle data application 150 includes a demand model 152 and a cashflow module 154. Demand model 152 uses historical transaction data 134 stored in data store 130 to determine the payments for a consumer having a particular profile that will be likely to result in a completed lease transaction. Cashflow model 154 uses contract records 132 and information on customers' performance on those contracts 133 to take input payment information from demand model 152 and information on the desired return for a transaction so that it can determine an acquisition price for particular types of vehicles. This acquisition price is compared to prices set by sellers for inventory vehicles 131 in order to determine which of these vehicles is priced to meet the return requirement. A list of qualified vehicles 135 for the consumer profile (vehicles that are priced at or below the acquisition price for that type of vehicle) is stored in data store 130 for quick retrieval when a consumer uses the system.

[0039] Vehicle data application 150 may also include various other modules which are not described in detail herein. These modules may include, for example, dealer interaction modules, user interaction modules, inventory modules, order modules, financing modules, document modules, and various other modules that may be necessary or desirable to perform the functions of the vehicle data application.

[0040] Referring to FIG. 2, a diagram illustrating the flow of data through a demand model and a cashflow model in accordance with one embodiment is shown. As depicted in this figure, a consumer profile 202 and a vehicle type 204 are provided to a demand model 152. The consumer profile may include various types of information, such as income, credit score, rent, debt-to-income ratio, etc. Alternatively, the consumer profile may comprise an indication of a particular classification or categorization of the consumer, where the classification may be used to identify a group or class of consumer whose behavior can be collectively characterized.

[0041] In one embodiment, the acquisition price is determined without regard to a specific consumer. In other words, the consumer profile is a unique classification or set of characteristics that describe a segment of the consumer population. The consumer profile may be defined by particular values or ranges of values for one or more consumer characteristics (e.g., income, credit score, rent, debt-to-income ratio). These characteristics are used to identify subsets of the historical transaction data that are used as the basis for the demand model. Each subset of the data is analyzed to determine the payments that are associated with the corresponding consumer profile and various vehicle types. Because personally identifiable consumer information is often protected by applicable laws and/or regulations, one embodiment generates its own internal risk scores for consumers based on available information and then uses the consumer's internal risk score and state as a consumer profile.

[0042] The vehicle type provided to the demand model does not identify a specific vehicle, but instead identifies a class or group of vehicles. The vehicle type may, for example, be identified by various characteristics of a class of vehicles, such as the body style (e.g., sedan, coupe, SUV, etc.), size (e.g., sub-compact, compact, mid-size, etc.), and the like. The particular characteristics that are used to identify the vehicle type may differ from one embodiment to another, depending upon the requirements of the demand model. These characteristics may also be encoded into a record or number such as a vehicle identification number, or VIN number. One embodiment may use a "VIN10", which comprises the first 10 digits of the VIN. This number identifies such things as the manufacturer, model, body type and model year (the remainder of the VIN--digits 11-17--contains a serial number that can be used to identify the specific vehicle associated with the transaction record, but which is not necessary in this embodiment).

[0043] The vehicle type may be derived from the user request to access the automotive data processing system. The user may, for example, explicitly identify a vehicle type when the request is initiated, so the request itself may identify the vehicle type (e.g., by including a VIN that identifies the vehicle type). In one embodiment, the VIN is decoded to identify information such as the make, model, model year, trim, and equipment of the vehicle. Alternatively, the user may have searched for particular vehicles or for vehicles with particular characteristics, and this search activity may be used to identify a vehicle type which can then be provided to the demand model.

[0044] Demand model 152 is derived from historical transaction data that identifies lease transactions. Each of the transaction records that contain the transaction data has associated consumer information, vehicle type information, and payment information. This information is analyzed to determine the payment levels at which consumers having particular profiles are likely to complete lease transactions for particular types of vehicles. Various different algorithms may be used to identify the payments corresponding to the different consumer profiles and vehicle types. For example, in one embodiment, the historical transaction data may be segregated by consumer profile classifications, and further segregated into vehicle types. Then, for each combination of a particular consumer profile classification and a particular vehicle type, the data for this combination may be examined to identify a payment level (e.g., maximum monthly payment) at which a predetermined number of transactions are converted. The model in this example might therefore be a table that stores payment values corresponding to the consumer profile classifications and vehicle types.

[0045] Demand model 152 is designed to receive consumer profile 202 and vehicle type 204 as inputs, and to provide the corresponding payment 206 as an output. In the example of a demand model that comprises a table storing payment values, the input consumer profile and vehicle type may be used to look up a corresponding payment value in the table. In alternative embodiments, the demand model may be a more complex structure, and it may be necessary to compute the payment value after the consumer profile and vehicle type are input to the model. It should be noted that the payment generated using the demand model is consumer-facing and is generated without regard to any particular vehicle that is being offered for sale or lease, or any costs that may be associated with selling or leasing a vehicle.

[0046] The payment 206 that is produced by demand model 152 corresponding to the identified consumer profile 202 and vehicle type 204 is then itself provided as an input to a cash flow model 154. In one embodiment, a desired return 208 is also input to the cash flow model. Cash flow model 154 is derived in this embodiment from historical contract performance data which is collected by the system. This data is analyzed to determine the costs associated with transactions involving particular types of vehicles. In one embodiment, this is accomplished using an ensemble of a logistic regression and a tree-based model that use price, make, model, and state as inputs. The cash flow model is designed to determine, based upon the input return information 208 and the payment information 206 from the demand model a maximum acquisition price 210 that is necessary to provide the desired return for the particular type of vehicle at the payment level indicated by the demand model. Acquisition price 210, similar to the customer-facing payment 206, is independent of any particular vehicle that may be available for sale on the system.

[0047] The cash flow model is a hybrid of two models. The first model is a survival model, which is a logistic regression trained on historical payment data to determine the customer and vehicle attributes that predict the probability of voluntarily returning a car or defaulting on the contract in each time period. This may be replaced with a neural network survival model in some alternative embodiments. The second model is a unit economics model, which is a mechanistic model capturing the cash inflows and outflows that comprise the relevant economics. The survival model and the unit economics model are combined to produce a probability weighted set of cash flows that describe the expected financial performance of a given deal.

[0048] Referring to FIG. 3, a flow diagram illustrating a method for generating a vehicle acquisition price in an automotive data processing system in accordance with one embodiment is shown. In this method, a consumer profile and a desired vehicle type are provided to a demand model (302). The demand model processes the input consumer profile and vehicle type and generates a payment as an output (304). The payment generated by the demand model and a desired rate of return are then provided as inputs to a cashflow model (306). The cashflow model processes these inputs and generates an acquisition price corresponding to the consumer profile, vehicle type and rate of return which were input to the demand and cashflow models (308).

[0049] Referring to FIG. 4, a diagram illustrating the flow of data through a comparison engine in accordance with one embodiment is shown. As depicted in this figure, the acquisition price 210 generated by the demand model is provided to a comparison engine 156. The comparison engine also receives inventory records 131, each of which corresponds to a particular vehicle that is available to the automotive data processing system. Each of the vehicle inventory records identifies the purchase price for the corresponding vehicle, which is set by the seller of the vehicle. Comparison engine 156 compares the purchase price for each inventory vehicle with the acquisition price and either qualifies or disqualifies the vehicle based upon the comparison. If the purchase price is less than or equal to the acquisition price, the vehicle is qualified, and if the purchase price is greater than the acquisition price, the vehicle is disqualified. It should be noted that, although the automotive data processing system may store inventory records for vehicles of many different types, acquisition price 210 is only applicable to vehicles of the type originally input to the demand model (see FIGS. 2 and 3), so inventory records 131 are filtered so that only records for vehicles of the type input to the demand model are processed by comparison engine 156. The qualified vehicles may be identified by the automotive data processing system in any suitable manner. For instance, qualified vehicle records may be separately stored, existing inventory records for qualified vehicles may be flagged, lists of qualified vehicles may be stored, or any other type of indication of the qualified vehicles may be maintained. These indicators can then be used to identify the qualified vehicles for presentation through a user interface of the vehicle data application, while disqualified vehicles are blocked from being displayed to consumers.

[0050] Referring to FIG. 5, a flow diagram illustrating a method for generating displays of qualified vehicles in an automotive data processing system user interface in accordance with one embodiment is shown.

[0051] As depicted in this figure, the acquisition price that was previously generated for the identified consumer profile and vehicle type is provided to a comparison engine (502). Inventory records for vehicles that are available through the automotive data processing system are then filtered to exclude vehicles other than the particular vehicle type associated with the acquisition price, and the filtered records are provided to the comparison engine (504). The comparison engine compares the purchase price identified in each of the filtered vehicle records to the received acquisition price (506). The comparison engine qualifies or disqualifies each of the filtered vehicle records based on the corresponding vehicle price and the acquisition price (508). More specifically, if the purchase price is less than or equal to the acquisition price, the vehicle is qualified, and if the purchase price is greater than the acquisition price, the vehicle is disqualified. An indication of the qualified vehicles (e.g., a list, copies of the vehicle records, or the like) is stored by the system. The automotive data processing system then generates one or more displays to be presented via a user interface of the vehicle data application (510). The displays include only qualified vehicles, so that if a user completes a transaction (e.g., lease) on one of these vehicles, it is ensured that the transaction will meet the requirements (e.g., minimum return on investment) of the system operator. Disqualified vehicles (which would not meet these requirements on completion o foreign associate transaction) are excluded from the generated displays.

[0052] As noted above, the acquisition price is associated with a particular consumer profile and vehicle type. As it is determined whether each vehicle is qualified or not, qualified vehicles are added to a list of qualified vehicles for the corresponding consumer profile and vehicle type, while disqualified vehicles are not. This same process is repeated for each of a set of possible consumer profiles and vehicle types so that multiple lists of qualified vehicles are stored by the system, with each list being associated with a corresponding consumer profile and vehicle type. Then, when a specific consumer interacts with the system, one of the consumer profiles which is associated with the consumer is identified, a vehicle type of interest to the consumer is identified, and the corresponding list of qualified vehicles is retrieved. This list is used to identify particular ones of the available inventory vehicles of the desired type that are qualified for this specific consumer. Since only vehicles that have acquisition prices at or below the acquisition price are qualified for display to the consumer through the application, any lease transactions that are completed necessarily involve vehicles that are priced at a level sufficient to provide the desired return for the system operator.

[0053] It should be noted that "list", as used herein, should be construed to cover lists, tables, databases, or any other data structures that are capable of storing the qualified vehicles corresponding to each combination of consumer profile and vehicle type for the desired return. It should also be noted that the automotive data processing system may be configured to store a list of payments generated by the demand model for corresponding combinations of consumer profiles and vehicle types. The automotive data processing system may further be configured to store a list of acquisition prices generated by the cashflow model for corresponding combinations of consumer profiles and vehicle types for a desired return.

[0054] As mentioned above, the demand model is intended to identify a payment at which a consumer having a particular profile is likely to complete a lease transaction for a vehicle of a given type. In one embodiment, the demand model is developed by examining portions of the historical transaction data corresponding to particular combinations of consumer profile and vehicle type. The consumer profile may be defined by any suitable set of values for a defined set of factors that might potentially drive the rate of default or return (e.g., FICO score, income, payment-to-income ratio, loan-to-value ratio, down payment amount, recurring monthly payment amount, depreciation, vehicle year make model and miles, vehicle value, origination location, origination channel (rideshare/consumer), etc.). The vehicle type may be defined by factors such as make and model, or make, model and year.

[0055] In one embodiment, for each combination of consumer profile and vehicle type, the corresponding records in the historical transaction data can be ranked according to the associated purchase prices. (In this case, the historical transaction data will include data for both converted transactions representing actual sales or leases and browsing or viewing transactions that were not converted.) Then, a target price is determined by identifying the price corresponding to a specific percentile of the completed transactions. For example, the 5th percentile may correspond to a target price of $400. Thus, 5% of the consumers that fall within the identified consumer profile will complete a lease for a vehicle of the identified type if the lease price is $400. The selected percentile may be increased or decreased, which may in turn affect the pace at which vehicles are leased through the application. For instance, if a greater percentile is selected (e.g., 6% instead of 5%), the target price will be slightly lower, reflecting the greater number of consumers leasing at the target price. A similar analysis is performed for each combination of consumer profile and vehicle type, so that the demand model can, for each combination of these inputs, provide a corresponding target price at which the selected percentile of transactions will be converted.

[0056] The target price output by the demand model corresponding to the identified consumer profile and vehicle type is provided as an input to the cash flow model. The cash flow model is designed to determine the cash flow that is generated by a transaction for a particular type of vehicle at a given price. In one embodiment, the vehicle data system collects information relating to all contracts for vehicle leases that are made using the system. This information is then used to develop the cash flow model. The collected contract information is used to determine, for a given vehicle type and at a given price, the probabilities that a consumer will maintain the contract, return the vehicle, or default on the contract.

[0057] In one embodiment, the cash flow model is developed using a database that is created with attributes which are known at the point of origination and which might potentially drive the rate of default or return on a contract, such as FICO score, start payment, regular payment, vehicle year make model miles, vehicle value, origination location, origination channel (rideshare/consumer), etc. The status of the loan at the beginning and the end of each contract period (e.g., defaulted, returned as agreed, actively paying) is also included.

[0058] The database contains a row for every contract for every due date from inception of the contract. For example, Rideshare contracts that involve weekly payments have one row per week for every account (e.g., 52 rows for a one year old account), while consumer loans which are due for monthly payments have 12 rows of status results for a year. In both cases, the origination attributes are repeated on every row. The database may have hundreds of thousands of rows (records).

[0059] An analysis is performed on the records in the database to predict the likelihood of return or default for any configuration of attributes known at origination, for any period in the life of the subscription. The output is a formula that predicts the likelihood of default, return, or continued payment for every invoice period (typically for 36 months in the case of rideshare and 48 months in the case of consumer). In this embodiment, it is assumed that after the full length of the loan period, the customers will return their vehicles.

[0060] An example of such a formula may be

g(.SIGMA..sub.i=1.sup.N.sub.f(x.sub.i.beta.)),

where N is the number of feature attributes in the model, x is an attribute, .beta. is some estimated coefficient and g is a functional form, and f is also a functional form such as a linear combination.

[0061] Based upon these probabilities, the expected net gross cash flow from a contract for this type of vehicle at this price can be determined. The formula for the probabilities of default, return, or continued payment is then put into a model that includes business costs, such as cost of capital, marketing, origination costs, servicing costs, depreciation, and liquidation costs. When these costs are added to the cost of acquisition of the vehicle from the dealer, the result is a gross cash flow expectation for the vehicle.

[0062] When the details of any of the previously originated vehicles are input to the model, the model might predict that, on average, the actual payment results in an expected return that is very high. Alternatively, the expected return may possibly be negative. Thousands of deals are therefore loaded, one by one, into the model, and are solved for a target return by adjusting the regular payment, saving the regular payment, and then using statistics on the deals with the ideal regular payment (the one that results in the desired return) to develop a general formula using the known origination attributes as inputs to drive a payment appropriate for a deal on a particular type of vehicle.

[0063] In one embodiment, a separate filter (not included in the model) is used to exclude certain vehicles which are not good fits with the consumer. For example, the vehicles may be excluded because the payment is not competitive, or because the vehicle is a type that is usually not preferred by the consumer (e.g., pickup trucks are not usually preferred by uber drivers). These vehicles are considered outliers and may skew the result that best fits the bulk of the vehicles.

[0064] As noted above, the acquisition price determined by the cash flow model is used in the selection of qualified vehicles that can be displayed to a consumer. In one embodiment, the acquisition price for a particular type of vehicle is compared to each of the vehicles of that type that have been made available by sellers through the vehicle data system. In this embodiment, there are a predetermined set of consumer profiles into which a given consumer can be classified. For example, there may be three consumer profiles corresponding to low risk, medium risk and high risk consumers. The consumer profiles may segment the consumer population in many different ways, and there may be any desired number of different profiles. In this particular embodiment, the system maintains a list of qualified vehicles for each combination of consumer profile and vehicle type, so that the vehicles which are qualified and can be displayed to a particular consumer can be quickly identified and displayed in real time when the consumers profile is determined. In other embodiments, the qualified vehicles can be dynamically determined.

[0065] Referring to FIG. 6, the use of the qualified vehicle list in accordance with some embodiments is shown. As depicted in this figure, a consumer first logs onto a client application which interacts with the vehicle data application (602). The vehicle data application identifies the consumer profile that is associated with the consumer (604) and then retrieves the corresponding list of qualified vehicles from a data store (606). The consumer profile may be determined in one embodiment based on information that is derived from a user request to access the automotive data processing system. For example, the user request may include a name, user ID, system registration ID, or other information that is unique to the particular consumer that is accessing the system. This identifying information may be used to access consumer profile information that was previously provided to the system during a registration process and stored by the system. Alternatively, the identifying information may be used to access information that is publicly available, or is collected and provided by external information services.

[0066] As noted above, each of the vehicles in the list has been compared to an acquisition price associated with the consumer profile, so it is not necessary to separately qualify vehicles for each consumer, or to expend the time and computational resources necessary to do so when the consumer logs in. This allows the system to generate displays of qualified vehicles to the consumer in real time. After retrieving the list of qualified vehicles, the consumer may interact with the vehicle data application, such as by submitting vehicle queries (608). In response to the consumer's queries, the vehicle data application will generate displays (e.g., vehicle listings) that are presented to the consumer via a user interface (610). Because the vehicles that are displayed to the consumer responsive to these queries or in the course of browsing are only selected from the qualified vehicles that were previously identified by the vehicle data application, it is assured that any transaction completed by the consumer on one of these vehicles will provide the return desired by the system operator.

[0067] It should be noted that the sellers of the vehicles may be provided with the ability to view the vehicles that are displayed to users having particular consumer profiles, and may therefore be able to determine whether or not particular vehicles that they have made available for purchase or lease through the vehicle data system are qualified for display. If a seller determines that a particular vehicle is not being displayed to consumers having a particular profile, the seller may change the purchase price of the vehicle in order to ensure that the vehicle is qualified. For example, if the seller prices a particular vehicle at $25,000, but the acquisition price is $24,500, the vehicle will not be qualified and consequently will not be presented to the consumer. The seller may therefore reduce the price to $24,500 or less in order to have the vehicle presented to the consumer. In one embodiment, the seller may use a client application which includes a tool such as a slider bar to adjust the price to a level which is at or below the acquisition price corresponding to that type of vehicle, thereby allowing the vehicle to be qualified and displayed to consumers.

[0068] Embodiments of the automotive data processing system may be implemented in a variety of different computing systems. FIG. 7 depicts a diagrammatic representation of a distributed network computing environment where embodiments disclosed can be implemented. In the example illustrated, network computing environment 700 includes network 704 that can be bi-directionally coupled to a client computing device 714, a server system 716 and one or more third party system 717. Server system 716 can be bi-directionally coupled to data store 718. Network 704 may represent a combination of wired and wireless networks that network computing environment 700 may utilize for various types of network communications known to those skilled in the art.

[0069] For the purpose of illustration, a single system is shown for each of client computing device 714 and server system 716. However, a plurality of computers may be interconnected to each other over network 704. For example, a plurality client computing devices 714 and server systems 716 may be coupled to network 704.

[0070] Client computer device 714 can include central processing unit ("CPU") 720, read-only memory ("ROM") 722, random access memory ("RAM") 724, hard drive ("HD") or storage memory 726, and input/output device(s) ("I/O") 728. I/O 728 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. In one embodiment I/O 728 comprises a touch screen interface and a virtual keyboard. Client computer device 714 may implement software instructions to provide a client application configured to communicate with an automotive data processing system. Likewise, server system 716 may include CPU 760, ROM 762, RAM 764, HD 766, and I/O 768. Server system 716 may implement software instructions to implement a variety of services for an automotive data processing system. These services may utilize data stored in data store 718 and obtain data from third party systems 717. Many other alternative configurations are possible and known to skilled artisans.

[0071] Each of the computers in FIG. 7 may have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For the sake of brevity, each computer is illustrated as having one of each of the hardware components, even if more than one is used. Each of computers 714 and 716 is an example of a data processing system. ROM 722 and 762; RAM 724 and 764; HD 726, and 766; and data store 718 can include media that can be read by CPU 720 or 760. Therefore, these types of memories include non-transitory computer-readable storage media. These memories may be internal or external to computers 714 or 716.

[0072] Portions of the methods described herein may be implemented in suitable software code that may reside within ROM 722 or 762; RAM 724 or 764; or HD 726 or 766. The instructions may be stored as software code elements on a data storage array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

[0073] While the foregoing embodiments were provided primarily in the context of an automotive data processing system, it will be appreciated that embodiments described herein may be applied to other assets (e.g., real-estate, boats, etc.). In particular, embodiments may be adapted for assets for which depreciation can be modeled. Moreover, those skilled in the relevant art will appreciate that the invention can be implemented or practiced with other computer system configurations, including without limitation multi-processor systems, network devices, mini-computers, mainframe computers, data processors, and the like. The invention can be embodied in a computer or data processor that is specifically programmed, configured, or constructed to perform the functions described in detail herein. The invention can also be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a local area network (LAN), wide area network (WAN), and/or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. These program modules or subroutines may, for example, be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks).

[0074] ROM, RAM, and HD are computer memories for storing computer-executable instructions executable by the CPU or capable of being compiled or interpreted to be executable by the CPU. Suitable computer-executable instructions may reside on a computer readable medium (e.g., ROM, RAM, and/or HD), hardware circuitry or the like, or any combination thereof. Within this disclosure, the term "computer readable medium" is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. Examples of computer-readable storage media can include, but are not limited to, volatile and non-volatile computer memories and storage devices such as random access memories, read-only memories, hard drives, data cartridges, direct access storage device arrays, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. Thus, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

[0075] Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein. Other software/hardware/network architectures may be used. For example, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.

[0076] Different programming techniques can be employed such as procedural or object oriented. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage mediums, and may reside in a single database or multiple databases (or other data storage techniques). Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.

[0077] Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention.

[0078] It is also within the spirit and scope of the invention to implement in software programming or code an of the steps, operations, methods, routines or portions thereof described herein, where such software programming or code can be stored in a computer-readable medium and can be operated on by a processor to permit a computer to perform any of the steps, operations, methods, routines or portions thereof described herein. The invention may be implemented by using software programming or code in one or more digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. The functions of the invention can be achieved by distributed or networked systems. Communication or transfer (or otherwise moving from one place to another) of data may be wired, wireless, or by any other means.

[0079] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition "A or B" is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0080] To the extent particular values are provided in any example embodiments in the description, such values are provided by way of example and not limitation. Moreover, while in some embodiments rules may use hardcoded values, in other embodiments rules may use flexible values. In one embodiment, one or more of the values may be specified in a registry, allowing the value(s) to be easily updated without changing the code. The values can be changed, for example, in response to analyzing system performance.

[0081] Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: "for example," "for instance," "e.g.," "in one embodiment."

[0082] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component.

Claims

1. A method implemented in an automotive data processing system, the method comprising: providing a demand model, wherein in response to receiving input identifying a consumer profile and a vehicle type, the demand model is configured to generate a corresponding payment as an output; providing a cashflow model, wherein in response to receiving the payment output by the demand model and input identifying a desired return on a converted vehicle transaction, the cashflow model is configured to generate an acquisition price as an output; and providing a comparison engine, wherein in response to receiving the acquisition price output by the cashflow model, the comparison engine is configured to retrieve a set of vehicle inventory records, for each of the vehicle inventory records, compare a corresponding purchase price to the acquisition price and generate an indication of whether or not a vehicle corresponding to the vehicle inventory record is qualified, and generate a list of qualified vehicles.

2. The method of claim 1, further comprising generating, for each of a plurality of unique combinations of consumer profiles and vehicle types, a corresponding list of qualified vehicles and storing the lists of qualified vehicles.

3. The method of claim 2, further comprising, in response to a user request of a specific consumer: identifying one of the consumer profiles that is associated with the specific consumer; identifying a vehicle type associated with the user request; retrieving one of the lists of qualified vehicles which corresponds to the identified one of the consumer profiles and the identified vehicle type; and generating a display which is presented in a user interface of a client computing device, wherein the display includes one or more qualified vehicles in the retrieved one of the lists of qualified vehicles and excludes disqualified vehicles.

4. The method of claim 1, further comprising generating a display which is presented in a user interface of a client computing device, wherein the display includes one or more of the qualified vehicles and excludes disqualified vehicles.

5. The method of claim 1, wherein the comparison engine is configured to determine that each vehicle is qualified if the corresponding purchase price is no more than the acquisition price, and is otherwise disqualified.

6. The method of claim 1, wherein the demand model is configured to generate the payment by: identifying, in a collection of historical transaction records, a subset of the historical transaction records that correspond to the combination of the consumer profile and the vehicle type; ranking the subset of historical transaction records by corresponding prices; and selecting as the payment a target price corresponding to a desired percentile of converted transactions represented by the historical transaction records.

7. An automotive data processing system comprising: one or more processors communicatively coupled to one or more data storage devices, the one or more processors coupled to a non-transitory computer-readable medium that stores instructions which are executable by the processor to cause the processor to execute: a demand model, wherein in response to receiving input identifying a consumer profile and a vehicle type, the demand model is configured to generate a corresponding payment as an output; a cashflow model, wherein in response to receiving the payment output by the demand model and input identifying a desired return on a converted vehicle transaction, the cashflow model is configured to generate an acquisition price as an output; and a comparison engine, wherein in response to receiving the acquisition price output by the cashflow model, the comparison engine is configured to retrieve a set of vehicle inventory records, for each of the vehicle inventory records, compare a corresponding purchase price to the acquisition price and generate an indication of whether or not a vehicle corresponding to the vehicle inventory record is qualified, and generate a list of qualified vehicles

8. The automotive data processing system of claim 7, wherein the instructions are further executable by the processor to generate, for each of a plurality of unique combinations of consumer profiles and vehicle types, a corresponding list of qualified vehicles and storing the lists of qualified vehicles.

9. The automotive data processing system of claim 8, wherein the instructions are further executable by the processor to, in response to a user request of a specific consumer: identify one of the consumer profiles that is associated with the specific consumer; identify a vehicle type associated with the user request; retrieve one of the lists of qualified vehicles which corresponds to the identified one of the consumer profiles and the identified vehicle type; and generate a display which is presented in a user interface of a client computing device, wherein the display includes one or more qualified vehicles in the retrieved one of the lists of qualified vehicles and excludes disqualified vehicles.

10. The automotive data processing system of claim 7, wherein the instructions are further executable by the processor to generate a display which is presented in a user interface of a client computing device, wherein the display includes one or more of the qualified vehicles and excludes disqualified vehicles.

11. The automotive data processing system of claim 7, wherein the comparison engine is configured to determine that each vehicle is qualified if the corresponding purchase price is no more than the acquisition price, and is otherwise disqualified.

12. The automotive data processing system of claim 7, wherein the demand model is configured to generate the payment by: identifying, in a collection of historical transaction records, a subset of the historical transaction records that correspond to the combination of the consumer profile and the vehicle type; ranking the subset of historical transaction records by corresponding prices; and selecting as the payment a target price corresponding to a desired percentile of converted transactions represented by the historical transaction records.

13. A computer program product for generating vehicle encodings, the computer program product comprising a non-transitory computer-readable medium storing instructions executable by a processor to cause the processor to perform: providing a demand model, wherein in response to receiving input identifying a consumer profile and a vehicle type, the demand model is configured to generate a corresponding payment as an output; providing a cashflow model, wherein in response to receiving the payment output by the demand model and input identifying a desired return on a converted vehicle transaction, the cashflow model is configured to generate an acquisition price as an output; and providing a comparison engine, wherein in response to receiving the acquisition price output by the cashflow model, the comparison engine is configured to retrieve a set of vehicle inventory records, for each of the vehicle inventory records, compare a corresponding purchase price to the acquisition price and generate an indication of whether or not a vehicle corresponding to the vehicle inventory record is qualified, and generate a list of qualified vehicles.

14. The computer program product of claim 13, further comprising generating, for each of a plurality of unique combinations of consumer profiles and vehicle types, a corresponding list of qualified vehicles and storing the lists of qualified vehicles.

15. The computer program product of claim 14, further comprising, in response to a user request of a specific consumer: identifying one of the consumer profiles that is associated with the specific consumer; identifying a vehicle type associated with the user request; retrieving one of the lists of qualified vehicles which corresponds to the identified one of the consumer profiles and the identified vehicle type; and generating a display which is presented in a user interface of a client computing device, wherein the display includes one or more qualified vehicles in the retrieved one of the lists of qualified vehicles and excludes disqualified vehicles.

16. The computer program product of claim 13, further comprising generating a display which is presented in a user interface of a client computing device, wherein the display includes one or more of the qualified vehicles and excludes disqualified vehicles.

17. The computer program product of claim 13, wherein the comparison engine is configured to determine that each vehicle is qualified if the corresponding purchase price is no more than the acquisition price, and is otherwise disqualified.

18. The computer program product of claim 13, wherein the demand model is configured to generate the payment by: identifying, in a collection of historical transaction records, a subset of the historical transaction records that correspond to the combination of the consumer profile and the vehicle type; ranking the subset of historical transaction records by corresponding prices; and selecting as the payment a target price corresponding to a desired percentile of converted transactions represented by the historical transaction records.