WO2022115586A1 - Génération et fourniture de structures de tarification instantanée - Google Patents

Génération et fourniture de structures de tarification instantanée Download PDF

Info

Publication number
WO2022115586A1
WO2022115586A1 PCT/US2021/060798 US2021060798W WO2022115586A1 WO 2022115586 A1 WO2022115586 A1 WO 2022115586A1 US 2021060798 W US2021060798 W US 2021060798W WO 2022115586 A1 WO2022115586 A1 WO 2022115586A1
Authority
WO
WIPO (PCT)
Prior art keywords
instant
inventory
vehicle
pricing structure
policy
Prior art date
Application number
PCT/US2021/060798
Other languages
English (en)
Inventor
Saman Baghestani
Brandon DRUMHELLER
Veerendra JOTE
Andrew Baldwin
Walker RAMIREZ
Original Assignee
Capital One Services, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/104,888 external-priority patent/US20220164814A1/en
Priority claimed from US17/104,684 external-priority patent/US11436561B2/en
Priority claimed from US17/133,027 external-priority patent/US20220198556A1/en
Application filed by Capital One Services, Llc filed Critical Capital One Services, Llc
Priority to CA3199990A priority Critical patent/CA3199990A1/fr
Priority to EP21899107.3A priority patent/EP4252171A1/fr
Publication of WO2022115586A1 publication Critical patent/WO2022115586A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283—Price estimation or determination
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0206—Price or cost determination based on market factors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0281—Customer communication at a business location, e.g. providing product or service information, consulting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0621—Item configuration or customization
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof

Definitions

  • the pricing option may include loan information (that meets lender requirements) and vehicle price information for the vehicle.
  • the buyer may want to change elements of the pricing option, such as loan term, vehicle price (e.g., through negotiation), interest rates, or the like, so that the buyer can meet their personal payment preference.
  • the buyer and the dealer are inaccurately guessing which elements of the pricing option can be adjusted (and the net effects of the adjustments) while remaining within the constraints of the buyer’s preferences and continuing to meet lender requirements.
  • the pricing option may not be specifically tailored to the buyer.
  • a final pricing option offered by the car dealership may be different than the pricing option initially presented to the buyer based on adjustments made during negotiations, which may result in the final pricing structure not meeting the buyer’s preferences, even if the pricing option initially presented to the buyer did meet the buyer’s preferences. Therefore, approaches are needed to ensure that buyers may be offered a pricing option that can be adjusted as needed, while remaining within the constraints of the buyer’s preferences, as well as a lender’s requirements, and which reduces wasting of time and operational resources.
  • sales management tools to manage inventories, track sales, handle finances, market goods and services, create invoices, and perform a wide- array of other tasks.
  • car dealerships traditionally harness sales management tools to track information about vehicles in stock, e.g., make, model, color, price, number of days in the inventory, etc.
  • a sales representative may access a sales management tool to review the inventory and determine suitable items to recommend to a potential customer.
  • the sales management tool may provide relevant information about the inventory in a search result that can be tailored by a sales representative using various search parameters.
  • a conventional sales management tool may allow a salesperson to configure a deal in any way that makes sense for the dealership, but there are limits.
  • FIG. 1 A illustrates an example environment generating instant pricing structures, in accordance with some embodiments.
  • FIG. IB illustrates an example environment for selecting the combination of the alternative inventory item and the associated structure, according to some embodiments.
  • FIG. 1C is a block diagram of an environment including a sales management tool, according to some embodiments.
  • FIG. 2A is an example display output, according to some embodiments, according to some embodiments.
  • FIG. 2B is a block diagram of a user interface rendered on an application of a seller device or user device, according to some embodiments.
  • FIG. 2C is an example screen display of a search result in a sales management tool, according to some embodiments.
  • FIG. 3 illustrates a plurality of clusters plotted on a two-dimensional graph, according to some embodiments.
  • FIG. 4 is a flowchart illustrating a method for determining an alternative inventory item and a structure, according to some embodiments.
  • FIG. 5 is a flowchart illustrating a process for generating sets of instant pricing structures, according to some embodiments.
  • FIG. 6 is a flowchart illustrating the process for identifying a set of instant pricing structures from a plurality of instant pricing structures, according to some embodiments.
  • FIG. 7 is a flowchart illustrating a method of displaying a search result that displays affordability indicators in a sales management tool, according to some embodiments.
  • FIG. 8 illustrates a method of calculating a policy distance for display in a search result in a sales management tool, according to some embodiments.
  • FIG. 9 is a flowchart illustrating a method of calculating a budget distance for an item displayed in a search result in a sales management tool, according to some embodiments.
  • FIG. 10 illustrates an example computer system, according to some embodiments.
  • a method that selects the combination of the alternative inventory item and the associated instant pricing structure. For example, the buyer may visit the dealership to purchase a vehicle of a particular make and model, and/or having specific features. The buyer may be interested in purchasing the vehicle, if the vehicle of the particular make, model, and/or the specific features is available at certain purchase terms. For example, the buyer may have decided not to purchase the vehicle if the monthly installment of the vehicle loan is above US$ 500 for a loan term of 5 years with a down-payment of US$2000. However, based on the buyer’s credit history and other factors, the buyer may need to provide a higher down-payment.
  • the purchase or financing terms for each vehicle may vary based on various factors related to the buyer’s credit report etc. and other factors, such as time of the year, available inventory, time for which the vehicle is on the floor, weather forecast, etc. Accordingly, presenting to the buyer vehicles similar to the vehicle of the buyer’s choice, and then approaching the lender(s) would be a time consuming process.
  • Various embodiments in this disclosure describe dynamically generating an instant pricing structure of terms for each of the alternative vehicles and calculate a combined score based on the similarity of the generated instant pricing structure and the alternative vehicle to the vehicle and terms of the buyer’s choice. Accordingly, when the buyer is presented the vehicle and the instant pricing structure based on the combined score, the buyer is more likely to proceed with the purchase of the alternative vehicle and leave as a satisfied customer. And, the dealer would be able to complete the transaction faster.
  • a dealer representing the dealership wants to be in the best possible position to close a sale.
  • a potential customer or buyer e.g., a user
  • a dealership e.g., a car dealership
  • this not only means sselling available vehicles to the customer and getting them to agree to purchase a particular vehicle but also working with the customer to agree on financial terms for the purchase that meet the customer’s goals.
  • a server receives a request to generate a plurality of sets of form data objects for a vehicle in an inventory of a dealer.
  • Form data objects may be loan pricing structures.
  • the server identifies a set of attributes associated with the dealer. These attributes may be categories that correspond to attributes of previously selected final form data objects for the dealer. Each attribute may serve as a requirement or additional constraint for the form data object. For example, the attributes may include less front end, more cash down, less backend, no back end, or the like.
  • the server For each attribute of the set of attributes, the server identifies a parameter corresponding to a given attribute of the set of attributes and determines a threshold for the parameter. Furthermore, for each attribute of the set of attributes, the server generates a set of form data objects of the requested plurality of sets of form data objects by adjusting a value for the parameter by an incremental amount within the threshold while maintaining each form data object of the set within constraints of a user-provided input and the policy of the lender.
  • the parameter for each attribute may be part of a set of parameters used to generate an form data object.
  • the server identifies parameters for a given attribute that will allow the form data object which meet the requirements of the given attribute while remaining within the constraints of the input associated with a user and a policy of a lender. For example, in the event the attribute is less front end, the server may identify parameters such as front end value and longer loan term.
  • Each form data object of the plurality of sets of form data objects is unique and constrained based on an input associated with a user and a policy of a lender.
  • the server transforms an form data object from a set of form data objects of the plurality of sets of form data objects into a final pricing structure data object, in response to a selection of the form data object and independent of further input associated with the user.
  • the server executes an action on the final pricing structure.
  • each of the forms can be actionable as they are pre-generated based on a lender’s underwriting and pricing algorithms. That is, an form data object, once selected, can share the same data (e.g., projected payments and APR information) as the final pricing structure data object that is accepted by the lender. This ensures that the form data objects do not change once the final pricing structure data object is generated. This way, each form data object is a realistic pricing option for the vehicle.
  • this configuration rather than a dealer manually generating a pricing structure and making multiple requests to a lender (as is conventionally done) for pre-approval, this configuration generates multiple potential final pricing structure data objects based on a lender’s underwriting and pricing algorithms with a single request. By doing so, this configuration saves operational resources.
  • embodiments described herein provide for displaying a search result in a sales management tool that includes affordability indicators and efficiently and effectively calculates distances to meeting underwriting policy constraints and customer budget.
  • the interface can provide these affordability indicators to a sales representative within the search result, solving a long-running pain point among sales management tools. This non-trivial solution thus bridges the gap between customer preferences, third- party lenders (which apply closely held proprietary underwriting algorithms), and dealerships’ own preferences (which may be tracked over time).
  • sales management tools provide businesses the ability to track inventory, complete sales transactions, create invoices, receive payment, record customer behaviors and preferences, and perform other sales-related functions.
  • the sales management tool may store detailed information about available items in a business’ inventory, i.e., in stock and/or available to be purchased by a potential customer.
  • the information may track the vehicles owned by the particular dealership that a potential customer may purchase.
  • the information associated with each vehicle may include a vehicle identification number, pricing information, ownership history, vehicle characteristics such as make, model, year, and color, and other information.
  • the sales management tool may update the inventory to reflect the changes.
  • a dealership may change pricing information and perform other suitable functions.
  • the sales process at a dealership commences when a potential customer visits a dealership in person, virtually, or otherwise.
  • a sales manager, representative, employee, or other suitable individual may engage with the potential customer to aid them in their search.
  • the sales representative may inquire about the potential customer’s brand preferences, desired vehicle colors, stylistic concerns, and various other consumer preferences.
  • the sales representative may also acquire a general idea of the potential customer’s financial situation, perhaps by asking the potential customer about their desired purchase price or budget.
  • the sales representative may then recommend a particular vehicle to the potential customer, allow the customer to test drive the vehicle, and otherwise conduct basic sales practices to complete a sale.
  • the sales representative may then ask for detailed information about the potential customer’s finances. This information may include the potential customer’s credit score, desired monthly payment, desired down payment, monthly income, personal debt, etc. The sales representative only then may involve potential lenders to determine an appropriate financing solution to finalize the sale.
  • the sales representative may additionally consider various characteristics and operational constraints particular to their own dealership. For example, some dealerships may focus on maximizing profits during a certain time of the year while pushing to sell vehicles that have remained on the lot for the lengthiest amount of time during another time period.
  • legacy sales management tools exist that a sales representative may leverage throughout the sales process, these tools are deficient in several respects.
  • the tools lack the ability to simultaneously consider factors spanning a multitude of lender-specific underwriting policies, inventory, dealer characteristics and customer- specific constraints and budgets.
  • a legacy sales management tool may allow a sales representative to configure a desired deal, but there are downstream limits regarding both what the customer and the financing lender will accept.
  • the sales representative operates blindly, having no way of knowing how to configure a deal to simultaneously satisfy both the customer and the lender (and the dealer itself).
  • a sales representative must guess at vehicles and associated instant pricing structures (e.g., financial structures) to recommend to the potential customer based on limited information about the potential customer’s financial situation.
  • the sales representative may only then verify that a lender offers in-policy (e.g., compliant with proprietary underwriting policies) instant pricing structure to finance the purchase transaction of the particular vehicle for the particular customer.
  • the sales representative may manually select a generic instant pricing structure and/or enter parameters statically to determine if the customer qualifies for financing. If the potential customer does not qualify, the sales representative may then select another instant pricing structure or re-enter the static parameters. If no match is found, the sales representative may be forced to move on to a different, more affordable vehicle. Time is wasted.
  • Some legacy solutions may allow a sales representative to access a lender’s system, e.g., via a web interface or programmatically using an application programming interface (API), to enter/transmit static parameters that, when considered, determine whether a potential customer qualifies to purchase a particular vehicle under the lender’s terms.
  • API application programming interface
  • these systems remain restricted by the requirement that the instant pricing structures, e.g., the rate and term are static and entered for each subsequent request, i.e., the instant pricing structures must be hard-coded on a per-request basis when accessing the lender’s site.
  • the sales representative remains in the dark in such a solution. This requirement renders such systems incapable of dynamically determining the in policy vs. out-of-policy status of vehicles to effectively display this information within a search results (or other standalone vehicle description) page.
  • legacy systems are unable to provide inventory affordability indicators — i.e., legacy systems did not calculate, and cannot calculate, policy and budget distances across each item in the inventory.
  • no deal instant pricing structure may exist that satisfies the consumer constraints and the lender policy for the desired vehicle.
  • a potential customer may be attempting to purchase a vehicle that exceeds their budget and/or acceptable risk for a lender.
  • Such a vehicle may even be very close to coverage under a policy, and perhaps just several additional dollars down payment would make the vehicle coverable in accordance with lender policy.
  • a sales representative using legacy systems has no access to this level of distancing information because, again, legacy systems operate statically with respect to a potential lender’s acceptance of terms.
  • the sales representative must resort to altering the static terms and guessing at an appropriate refinement to the financing terms or switching to an alternate vehicle. While eventually this might result in a policy match, the tactic may never result in a policy match, further wasting the sales representative’s time. Similarly, the sales representative may overshoot the estimated refinement to the search for a financing arrangement, resulting in a sub-optimum policy for the potential customer.
  • a “policy distance” bridges this gap by indicating in qualitative terms how far away a particular item is from being covered by a policy.
  • this distance can be expressed as a dollar amount required to be added to a down payment, as an amount of sales-price reduction needed, or both.
  • Other suitable approaches to express the policy distance may be adopted.
  • a policy distance could be expressed as a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • the foregoing approaches may also be combined, i.e., operate in tandem to represent a policy distance across multiple factors/variables.
  • legacy systems do not have the ability to simultaneously integrate lender- specific underwriting policies, customer-specific constraints and budget parameters, dealer preferences, and inventory, the systems are unable to calculate the affordability indicators.
  • legacy systems have no efficient, working method for assessing the impact of the variables in play, i.e., the potential customer’s unique information, the impact of additional cash down, changes to the loan-to-value ratio, reductions in a vehicle’s price, etc. so as to derive the specific policy distances in the manner described in further detail below.
  • a need exists to display a search result in a sales management tool that includes affordability indicators and calculated distances between policies and budgets. This information may be calculated by accessing constraints and budget parameters unique to a potential customer, a multitude of lender-specific underwriting policies, and stored information about an inventory of items.
  • a further technical benefit is realized in an embodiment that receives budget information about the potential customer when the sales process commences.
  • the system may further hone in on an appropriate instant pricing structure that is still in-policy for a particular lender. Specifically, the system may determine whether a proposed instant pricing structure and items fall within the specified budget information. When the proposed instant pricing structure and item do not, the system can calculate a budget distance.
  • the budget distance can be expressed as a dollar amount required to be added to a down payment, as an amount of sales-price reduction needed, or both. Other suitable approaches to express the budget distance may be adopted.
  • a budget distance could be expressed as a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • the foregoing approaches may also be combined, i.e., operate in tandem to represent a budget distance across multiple factors.
  • the system can further solve for budget constraints for a particular customer. This solves a further pain point for dealerships as non-fmancial entities are not positioned to solve for this given static rates and terms.
  • a further technical benefit is provided by the specific optimization techniques described below that allow the search result to calculate the affordability indicators in near-real-time.
  • Legacy systems have no mechanism for integrating the information describing the multitude of lender-specific underwriting policies, customer-specific constraints, and expansive inventories in a manner that can allow these calculations to occur efficiently enough for systems to provide these features in near-real time.
  • FIG. 1 A illustrates an example environment generating instant pricing structures, in accordance with some embodiments.
  • the environment may include server 100.
  • Server 100 may include a pricing engine 102.
  • the pricing engine 102 can be configured to generate form data objects.
  • the environment may further include a seller device 110, user device 140, and database 148.
  • Seller device 110 can include application 118 and display 122.
  • User device 140 can include application 144 and display 142.
  • Seller device 110 and user device 140 can use applications 118 and 144 to interface with the server 100, respectively.
  • Applications 118 or 144 can be configured to request and receive form data objects.
  • Database 148 can be one or more data storage devices configured to store data associated with a dealer, inventory, form data objects, or final pricing structure data objects.
  • data objects may describe financial arrangements for the financing of the purchase of a vehicle such as: price, rebate value, cash down, taxes, licensing/plating fees, trade-in values, estimated monthly payment, APR or interest rate, term lengths, amount of back-end product (GAP, Warranty), and a variety of other variables.
  • the devices of the environment may be connected through wired connections, wireless connections, or a combination of wired and wireless connections.
  • one or more portions of the network 130 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, any other type of network, or a combination of two or more such networks.
  • VPN virtual private network
  • LAN local area network
  • WLAN wireless LAN
  • WAN wide area network
  • WWAN wireless wide area network
  • MAN metropolitan area network
  • PSTN Public Switched Telephone Network
  • PSTN Public Switched Telephone Network
  • Backend platform 125 may include a server or a group of servers. In an embodiment, backend platform 125 may be hosted in a cloud computing system 132. It may be appreciated that the backend platform 125 may not be cloud-based, or may be partially cloud-based.
  • the cloud computing system 132 includes an environment that delivers computing as a service, whereby shared resources, services, etc. may be provided to server 100.
  • the cloud computing system 132 may provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services.
  • the cloud computing system 132 may include computing resources 126a-d.
  • Server 100 may reside inside the cloud computing system 132. Alternatively, server 100 may reside partially outside the cloud computing system 132 or entirely outside the cloud computing system 132.
  • Each computing resource 126a-d includes one or more personal computers, workstations, server devices, or other types of computation and/or communication devices.
  • the computing resource(s) 126a-d may host the backend platform 125.
  • the cloud resources may include compute instances executing in the cloud computing resources 126a-d.
  • the cloud computing resources 126a-d may communicate with other cloud computing resources 126a-d via wired connections, wireless connections, or a combination of wired and wireless connections.
  • Computing resources 126a-d may include a group of cloud resources, such as one or more applications (“APPs”) 126-1, one or more virtual machines (“VMs”) 126-2, virtualized storage (“VS”) 126-3, and one or more hypervisors (“HYPs”) 126-4.
  • APPs applications
  • VMs virtual machines
  • VS virtualized storage
  • HEPs hypervisors
  • Application 126-1 may include one or more software applications that may be provided to or accessed by server 100, seller device 110, and user device 140.
  • applications 126-1 can include pricing engine 102, application 118, and application 144.
  • server 100 may reside outside the cloud computing system 132 and may execute applications like pricing engine 102 locally.
  • the application 126-1 may eliminate a need to install and execute software applications on server 100, seller device 110, and user device 140.
  • the application 126-1 may include software associated with backend platform 125 and/or any other software configured to be provided across the cloud computing system 132.
  • the application 126-1 may send/receive information from one or more other applications 126-1, via the virtual machine 126-2.
  • Virtual machine 126-2 may include a software implementation of a machine (e.g., a computer) that executes programs like a physical machine.
  • Virtual machine 126-2 may be either a system virtual machine or a process virtual machine, depending upon the use and degree of correspondence to any real machine by virtual machine 126-2.
  • a system virtual machine may provide a complete system platform that supports the execution of a complete operating system (OS).
  • a process virtual machine may execute a single program and may support a single process.
  • the virtual machine 126-2 may execute on behalf of a user and/or on behalf of one or more other backend platforms 125 and may manage infrastructure of cloud computing system 132, such as data management, synchronization, or long-duration data transfers.
  • Virtualized storage 126-3 may include one or more storage systems and/or one or more devices that use virtualization techniques within the storage systems or devices of computing resource 126.
  • types of virtualizations may include block virtualization and file virtualization.
  • Block virtualization may refer to abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed without regard to physical storage or heterogeneous structure. The separation may permit administrators of the storage system flexibility in how administrators manage storage for end users.
  • File virtualization may eliminate dependencies between data accessed at a file level and location where files are physically stored. This may enable optimization of storage use, server consolidation, and/or performance of non-disruptive file migrations.
  • Hypervisor 126-4 may provide hardware virtualization techniques that allow multiple operations systems (e.g., “guest operating systems”) to execute concurrently on a host computer, such as computing resource 126.
  • Hypervisor 126-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems multiple instances of a variety of operating systems and may share virtualized hardware resources.
  • a user may interface with a vehicle dealership in-person or virtually using user device 140.
  • a user may be interested in purchasing a given vehicle from an inventory of the vehicle dealership. Financing options for purchasing the vehicle may be provided to the user.
  • the user may desire to generate a pricing option to project the cost of the vehicle. For example, the user may desire to project the monthly payments based on the price of the vehicle and a loan amount.
  • a user may desire to view different pricing options available to the user while staying within constraints of an input associated with the user.
  • the input may be a maximum desired monthly payment, maximum interest rate, loan term, vehicle price, or the like.
  • the pricing options may be conveyed in an form object.
  • the form data object may be a unitary data object.
  • Each form data object may store or contain data associated with a pricing option for a vehicle.
  • the data can include a price of the vehicle, loan amount, APR, projected monthly payments, loan term, or the like.
  • Each form data object may be stored in a single database record in database 148. This way, an form data object can be easily retrieved from database 148.
  • An form object may be generated using various parameters. These parameters can include term, sales price, cash down, trade value, warranty, gap, participation, rebate, alternative vehicles. Each of the parameters may correspond with values that may affect the form data object.
  • a user may provide user information for generating form data objects for the given vehicle using application 144.
  • the user can also provide information for generating form data objects to a seller or dealer.
  • the seller or dealer can input the user’s information using application 118.
  • the information may include the user’s full name, social security number, address, employment information, or other personal information, such as would be needed for credit verification or vehicle purchase.
  • the user may also provide the input for constraining the form data objects.
  • the input can be a maximum monthly payment, interest rate, vehicle price, loan term, or the like.
  • the input can be provided through a user interface of application 144 or application 118.
  • the user interface can include a text input box, dropdown menu, links, or the like, for providing the input.
  • Server 100 can forward the user information, input, and information about the given vehicle to application 118.
  • application 118 can receive the user information and input from the dealer operating seller device 110. A dealer can also hand the user the seller device 110 so that the user can input the user information and input using application 118.
  • a user may use application 144 to identify preferred vehicles that may be within the inventory of the dealer.
  • the preferred vehicles may be transmitted to server 100.
  • Server 100 may store the preferred vehicles in database 148 or some other storage device.
  • Application 118 transmits a request to server 100 to retrieve information about a user’s preferred vehicles (if any), using the user information.
  • the user information, input, and information about the given vehicle can be verified for errors. For example, if the user provides the user information and input through application 144 or directly on application 118, the dealer can review the user information and input on application 118 for any errors or missing information.
  • Application 118 can transmit a request to generate sets of form data objects for the user and the given vehicle to server 100.
  • the sets of form data objects can be two or more sets.
  • application 118 can transmit a request to generate a single set or a single form data object.
  • the request can include the user information, input, information about the given vehicle.
  • Information about the given vehicle can include make, model, year, VIN, vehicle price, or the like.
  • the request can also include a dealer identifier.
  • Server 100 can receive the request to generate the sets of form data objects for a given vehicle in the inventory of the vehicle dealer.
  • Pricing engine 102 may identify the dealer using the dealer identifier. Alternatively, pricing engine 102 can identify the dealer based on where the vehicle is currently listed in stock using the information about the given vehicle (e.g., VIN). Furthermore, pricing engine 102 can identify the dealer by identifying seller device 110 that transmitted the request. The seller device 110 can correspond with a dealer.
  • Pricing engine 102 can retrieve previous final pricing structure data objects agreed upon by the dealer. Pricing engine 102 can identify a set of attributes associated with the dealer based on the previous final pricing structure data objects.
  • the attributes may be tendencies or preferences of a dealer when agreeing upon a final pricing structure data object.
  • attributes can include a ratio of the backend value of the sales price and the frontend value of the sales price, percentage of the sales price that is the backend value as compared to the total value of the vehicle, funded structured flag, the percentage of down payment, details related to the vehicle (e.g., condition of the vehicle, whether the vehicle is new or used, type of vehicle, or the like), or the like.
  • the funded structured flag may indicate whether the seller prefers protection for assuming the credit risk.
  • the frontend value of a price of a vehicle may include the price of the vehicle itself.
  • the backend value of the price of the vehicle may include warranties and maintenance of the vehicle.
  • pricing engine 102 can implement an unsupervised machine learning algorithm to determine attributes about the dealer based on the previously agreed upon final pricing structure data objects.
  • a lender may provide their methodology and policies to database 148.
  • server 100 and database 148 may be associated with the lender.
  • Pricing engine 102 can retrieve a lender’s policy and methodology for generating an form from database 148.
  • the lender’s policy and methodology can include Bayesian regression algorithms, decision trees, pricing grids, or various equations to generate form data objects.
  • the lender’s methodology may include interfacing with a third-party credit bureau to execute a soft pull for the user.
  • Soft pulls are soft credit inquires that do not affect the user’s credit score.
  • the user information, soft pull information, input, and information about the given vehicle can be values of parameters used to generate the form data object using the lender’s policies and methodologies. Each form can be specifically generated based on the user’s unique information and the given vehicle.
  • Each form data object can be generated using the lender’s methodology (e.g., based on proprietary pricing algorithms) and within the constraints of the lender’s underwriting policies.
  • the lender’s methodology may involve calculating an APR, a required down payment, loan term, monthly payments, for the user purchasing the given vehicle, using the user information, soft pull information, and information about the given vehicle.
  • the attributes may serve as constraints or requirements when generating form data objects.
  • an attribute may be “low front end value.”
  • form data objects for this attribute may have a front value below a predetermined amount.
  • pricing engine 102 can identify one or more parameters associated with a given attribute.
  • the one or more parameters may be part of a set of parameters used to generate form data objects.
  • Pricing engine 102 may determine that values for the one or more parameters of the set may be incrementally adjusted for generating each form data object for the given attribute, while still maintaining each form data object for the given attribute within the requirement or constraint of the given attribute and the constraints of the input and lender’s policy.
  • Pricing engine 102 may also determine a threshold that one or more parameters may be adjusted. As a non-limiting example, the threshold may be determined based on one or more of a dealer’s historical sales data, predetermined information, information associated with the attribute. [0073] For example, in the event the attribute is a “low front end value” and the identified one or more parameters are front end value and loan term, pricing engine 102 may determine a threshold for how much the front end value may be adjusted and how much the loan term may be adjusted. Pricing engine 102 may determine that because the attribute is a “low front end value,” the front end value may not be higher than a predetermined amount or percentage of the final sales price.
  • pricing engine 102 may also determine, based on the dealer’s historical sales data, that the dealer does not finalize sales for which a front end value is lower than a given amount.
  • the threshold for the front end value may include a maximum and minimum amount.
  • pricing engine 102 may determine a minimum and maximum threshold, based for the loan term on one or more of: a dealer’s historical sales data, predetermined information, information associated with the attribute.
  • the predetermined information may be information based on common practices in the vehicle sale and loan business.
  • predetermined information about a loan term may include common loan terms for vehicle loans.
  • the predetermined information for loan term may indicate that loan terms more than 84 months do not exist.
  • pricing engine 102 may generate a set of form data object for the given attribute. Pricing engine 102 may incrementally vary the one or more parameters for the given attribute within the identified thresholds of the one or more parameters when generating each form. Each form data object may be within the constraints or requirements of the attribute, the input, and the lender’s policy. Similarly, pricing engine 102 may generate a set of form data objects for each attribute of the set of attributes associated with the dealer by incrementally varying the values for one or more parameters associated with each respective attribute. Each set of form can correspond with a given attribute in the set of attributes.
  • Pricing engine 102 generates each form data object to be unique and within constraints of a given attribute, the input associated with the user, and the policy of the lender. Furthermore, each form data object is unique for a specific user and vehicle.
  • a user or dealer can provide user information, an input, and vehicle information using application 118 or application 144 to generate sets of form data objects for the specific user and vehicle, as described above.
  • the input may be a maximum or target monthly loan payment amount.
  • the request to generate the sets of instant pricing data objects for the user and vehicle may be transmitted to server 100.
  • the request may include the user information, information about the vehicle, the input, an identifier of the dealer, and an identifier of a lender.
  • the request may include instructions the sets of form data objects for the user and vehicle, within the constraints of the input and credit policy of the lender. Other constraints may include credit profile of the customer, a lender’s credit policy, customer equity, income, economic profile, asset profile (i.e., vehicle details), or the like.
  • Pricing engine 102 may receive the request to generate the sets of form data objects. Pricing engine 102 may retrieve the credit policy of a lender from database 148. Furthermore, pricing engine 102 may retrieve information about the dealer using the dealer identifier from database 148. The information may include previously agreed upon final pricing structures, inventory information, sales records, or the like.
  • Pricing engine 102 may identify a set of attributes for generating the sets of form data objects.
  • the attributes may be categories which correspond with a different set of form data objects of the requested sets of form data objects.
  • attributes can include form data objects with less front end, form data objects with more cash down, form data objects with less back end, form data objects with no back end, or the like.
  • Pricing engine 102 may identify the set of attributes based on information associated with the dealer, as described above. In some embodiments, the dealer may select the set of attributes.
  • pricing engine 102 may identify one or more parameters associated with the parameters.
  • the parameters may be term, sales price, cash down, trade value, warranty, gap, participation, rebate, alternative vehicles, or the like.
  • Each of the parameters may have corresponding values. These values, when adjusted, may affect the values of the form data object. For example, adjustment of the parameters may affect Loan-to- Value (LTV), Payment to Income (PTI) ratio, Front End percentage (FE%), Front End Amount (FE$), Total Amount Financed, etc....
  • LTV Loan-to- Value
  • PKI Payment to Income
  • FE% Front End percentage
  • FE$ Front End Amount
  • Total Amount Financed etc.
  • pricing engine 102 may identify the one or more parameters identified for a given attribute, on the basis that the varying the one or more parameters would allow the form objects to remain within the constraints or requirements of the attribute, input, credit policy, and any other constraints.
  • Pricing engine 102 may also identify thresholds for the one or more parameters for each attribute, as described above. The thresholds may be a minimum and maximum value that a parameter may be adjusted. For example, if a parameter is “cash down,” the pricing engine 102 may determine that the value of cash down may not be adjusted more than the vehicle sales price and so the maximum of the value of cash down is less than the vehicle sales prices. Moreover, pricing engine 102 may determine that based on the information about the lender, the lender may require a certain percentage cash down for a given loan. Therefore, the minimum value for the cash down parameter may be the lender’s minimum cash down requirement.
  • pricing engine 102 may generate a set of forms by varying the one or more parameters associated with the respective attribute by an incremental amount within the thresholds of the one or more parameters when generating each form data object.
  • Each form may remain within the constraints of the attribute, input, credit policy, and any other constraints.
  • Pricing engine 102 may rank the form data objects within each set based on a likelihood of the form data objects being selected.
  • the likelihood of being selected may be a numerical score determined based on a comparison of the values of a given form data object to other form data objects in the set. The higher the numerical score may indicate more of a likelihood of selection. For example, the likelihood of the form data objects based on a similarity of a given form data object to a previously selected final pricing structure for the dealer.
  • the likelihood of the form data object of being selected may be determined based on the proximity of the values of a given form data object to the respective attribute, input, lender credit policy, thresholds of the one or more parameters, or other constraints.
  • Pricing engine 102 may select one or more of the highest ranked (e.g., top 3, top
  • Pricing engine 102 may generate an interface, including each of the selected form data objects categorized based on the attributes. Pricing engine 102 may cause the display of the interface on application 114 or application 118.
  • each of the form data objects for each set may be displayed on application 114 or application, categorized by attribute.
  • pricing engine 102 may rank form data objects for each set for the dealer and user. The rankings may be different for the dealer as compared for the user. For example, pricing engine 102 may rank the form data objects for each set for the dealer based on a likelihood of a dealer to agree to the form data objects. Pricing engine 102 may determine this based on elements of previous final pricing structure data objects by the dealer. Pricing engine 102 may use the elements to identify tendencies and preferences of the dealer. Pricing engine 102 may also use the elements to determine tendencies and preferences of previous users and use the tendencies and preferences of other users to rank the instant pricing data structures in each set for the user. The ranked instant pricing data structures for the user may be displayed on application 114. The ranked instant pricing data structures for the dealer may be displayed on application 118.
  • the dealer can use application 118 to specify for which attributes the dealer would like to form data objects. For example, dealer can specify that they would like to see form data objects for attributes low cash down and low front end value. Pricing engine 102 may exclude the form data objects generated for attributes other than low cash down and low front end value, when causing display of the form data objects.
  • application 118 may display each generated form data objects for each attribute.
  • the dealer may interface with application 118 to select an attribute.
  • Application 118 may remove the form data objects corresponding to the unselected attributes from the interface of application 118 and may only display the form data objects corresponding to the selected attribute.
  • pricing engine 102 may also rank the attributes based on a preference indicated by the dealer or determined by pricing engine 102 based on information about the dealer.
  • the interface may include each of the selected form data objects categorized based on the attributes and the attributes may be presented in a ranked order.
  • pricing engine 102 may include a set of instant pricing data structure objects corresponding to a single attribute on the interface. Pricing engine 102 may select the single attribute based on a selection from the dealer or based on information about the dealer.
  • pricing engine 102 may generate the sets of form data objects by varying values of different parameters within the constraints of the input, lender’s credit policy, and other constraints.
  • the sets of form data objects may be permutations of all possible form data objects of the vehicles in the inventory of a given dealer.
  • the sets of form data objects may be grouped based on attributes (e.g., low front end, high back end, no back end, etc.). As such, each group may include a set of form data objects.
  • Pricing engine 102 may identify a set of attributes associated with the dealer. For each attribute of the set of attributes, pricing engine 102 may identify one or more parameters, as described above. Pricing engine 102 may also identify thresholds for the one or more parameters, as described above. For each attribute of the set of attributes, pricing engine 102 may identify a set of form data objects from the sets of form data objects, for which the values of the one or more parameters associated with the respective attribute have been varied within a threshold of the one or more parameters, while the values of the other parameters remain constant default values. Furthermore, the values of the identified sets of form data objects for each attribute may be within the constraints of the respective attribute, input, lender’s credit policy, and other constraints. The identified sets of the form data objects may be for the specific user and vehicle.
  • pricing engine 102 may generate additional form data objects than are transmitted to application 118.
  • pricing engine 102 can generate thousands of form data objects per set, and it may be undesirable to present so many form data objects for possible selection.
  • the dealer may use application
  • Application 118 may transmit a request to transform the selected form data object into a final pricing structure data object to server 100.
  • the request may include information about the form data object.
  • Pricing engine 102 can use information in the form data object (e.g., APR, vehicle price, loan term, or the like), and transform the form data object into a final pricing structure data object.
  • the final pricing structure data object may include identical data as the form data object.
  • the final pricing structure data object may include additional details about the user and the loan, such as a hard credit inquiry about the user (e.g., a full credit report) and final loan details.
  • the final pricing structure data object may be used to obtain the loan and purchase of a vehicle.
  • Each of the form data objects can be an actionable form.
  • Server 100 may receive the selection of the form data object.
  • Pricing engine 102 may transform the form data object to a final pricing structure data object.
  • the final pricing data object can share the same information as the form data object.
  • Pricing engine 102 can execute an action on the final pricing structure. The action can be the purchase of a vehicle.
  • application 118 may transmit a request to server 100 to adjust an element of an form data object.
  • the pricing engine 102 can determine a threshold amount in which the element can be adjusted so that the form data object remains within the constraints of the input associated with the user and the policy of the lender. Pricing engine 102 can provide options for adjusting the element within the threshold amount, to application 118.
  • the element can be a price of a vehicle.
  • Pricing engine 102 can determine a threshold amount the price of the vehicle can be adjusted so that the form data object remains within the constraints of the input associated with the user and the policy of the lender. Pricing engine 102 can provide options for adjusting the vehicle price by the threshold amount to application 118.
  • FIG. IB illustrates an example environment for selecting the combination of the alternative inventory item and the associated structure, according to some embodiments.
  • the environment of FIG. IB may be a part of the environment of FIG. 1A.
  • the environment for selecting the combination of the alternative inventory item and the associated structure may include a vehicle database server 154, an application server 156, and a bank database server 156 communicatively coupled with each other via a network 130. Even though only one instance of the application server 156, the vehicle database server 154, and the bank database server 156 are shown in FIG. 1A, there may be more than one instance of the application server 156, the vehicle database server 154, and/or the bank database server 156 communicatively coupled with each other via the network 130.
  • the application server 156 may also include a database, and the bank database server 156 and the vehicle database server 154 may be an application server 156.
  • Vehicle database server 154, application server 156, bank database server 156 may be part of server 100 of FIG. 1A.
  • a user 104 may communicate via a client device 150 with the application server
  • the user 104 accesses a website at an address, which is hosted by the application server 156.
  • the user 104 may have installed a mobile application on the client device 150, and the user may perform the functions available via a web interface using the mobile application.
  • the user 104 may be a salesperson at a dealer, a bank employee, or a customer, etc., that may require to be authenticated when the user 104 accesses the website or launches the mobile application.
  • the user 104 may be authenticated using a user ID and password and/or biometric information.
  • the biometric information may include fingerprint, the shape of the hand and/or the finger, the shape of the face, iris or retina of the eye, etc.
  • the user 104 may be authenticated using 2-factor authentication for additional security.
  • the user 104 may be presented a form 152 in which the user 104 may provide values for configuration parameters that describe an inventory item the user 104 would like to purchase. For example, the user 104 is looking for a vehicle to purchase. Accordingly, the user 104 may provide values for the configuration parameters that describe a type of vehicle the user 104 would like to purchase.
  • configuration parameters are shown in FIG. 1 correspond to make, model, year, and color of the vehicle, the configuration parameters may include other features of the vehicle, such as body style, engine, mileage, trim, vehicle condition, interior color, price, etc.
  • a vehicle is used as an example of an inventory item in this disclosure, various embodiments described herein may be applied to other types of inventory items as well, for example, an appliance such as a television, a refrigerator, etc., or furniture such as a sofa, an office desk, etc.
  • the user 104 may also provide a value for a term that describes a structure, e.g., an instant pricing structure.
  • the instant pricing structure may include aspects, such as a value for a loan term, e.g., 5 years, a value for a loan amount, e.g., USD fifteen thousand, and/or a monthly installment of a vehicle loan, e.g., USD 200 per month, etc.
  • the user may also specify a monthly installment.
  • the user 104 may provide information regarding what type of vehicle the user 104 is looking for and what type of instant pricing structure the user would like to consider for the purchase of the vehicle. Accordingly, a sales person at the vehicle dealership may suggest one or more matching vehicles available according to aspects of the financial instant pricing structure.
  • the user 104 may be a customer, a salesperson at a dealer, a bank employee, etc.
  • the user 104 as the customer may provide details of the vehicle and the instant pricing structure via the form 152 to the application server 156.
  • the user 104 as the salesperson may receive details of the vehicle and the instant pricing structure from a to-be buyer of the vehicle to fill in the form 152 to send to the application server 156.
  • the user 104 as the salesperson may receive details of the vehicle from a to-be-buyer of the vehicle and provide instant pricing structure information based on the received vehicle details and the received vehicle details in the form 152 to send to the application server 156
  • the user 104 as the bank employee may be assisting the to-be buyer in finding a vehicle at one or more vehicle dealerships with a financial instant pricing structure based on the information received from the to-be buyer to fill in the form 152 to send to the application server 156.
  • a prospective buyer may select a vehicle online on a website, and obtain an initial prequalification information for the selected vehicle.
  • the prequalification information may specify instant pricing structure details based on the buyer details, such as income, full name, address, and/or information to receive a credit score or other similar information, provided for obtaining the initial prequalification information.
  • the user may adjust the financial instant pricing structure to preferred loan terms, for example, increase or decrease a loan amount, a term of the loan, and/or a monthly installment, etc.
  • the buyer details may also include trade-in value of another vehicle.
  • the application server 156 may access the vehicle database server 154 to retrieve the plurality of inventory items based on a plurality of records stored in a database at the vehicle database server 154.
  • the vehicle database server 154 may be a single database server or a plurality of database servers together, storing the plurality of records in the database.
  • one or more servers of the plurality of database servers may be located at different physical locations.
  • the one or more servers of the plurality of database servers may be owned and operated by different institutes.
  • the application server 156 may send a database query to the vehicle database server 154 or may communicate to the vehicle database server 154 using any of the mechanisms, e.g., a secure hypertext transfer protocol (HTTPS) message, a hypertext transfer protocol (HTTP) message, a web service message based on a simple object access protocol (SOAP) and/or a representational state transfer (REST) architecture.
  • HTTPS secure hypertext transfer protocol
  • HTTP hypertext transfer protocol
  • SOAP simple object access protocol
  • REST representational state transfer
  • the application server 156 may communicate with the vehicle database server using a proprietary messaging protocol to retrieve the plurality of inventory items based on the plurality of records stored in the database at the vehicle database server 154.
  • the application server 156 may send a query message that includes information identifying the vehicle based on the information received from the user 104 in the form 152 to the vehicle database server 154.
  • the application server may query the vehicle database server 154 based on the exact information received in the form 152 or may use expanded values for the search terms based on the information received in the form 152. For example, if the year of the vehicle in the form 152 is specified as 2010, the application server may query the vehicle database server 154 for the vehicles that were built in years 2008, 2009, 2010, 2011, and 2012. If the color of the vehicle in the form 152 is specified as red, the application server may query the vehicle database server 154 for the vehicle having color either red or maroon.
  • the application server 156 may query the vehicle database server 154 with the price of the vehicle as any value between USD 18,000 and USD 22,000.
  • the application server may have preconfigured values or thresholds for each search term to be used for querying the vehicle database server.
  • the preconfigured values for each search term may be enabled or disabled on a search term basis.
  • the preconfigured values for each search term may be updated periodically and/or per query, either based on input from the user 104 or based on market research.
  • the application server 156 may then generate a score value for each vehicle of the plurality of vehicles based on the plurality of records received by the application server from the vehicle database server.
  • the application server 156 may generate the score value for each vehicle based on a different weight assigned to each facet of the vehicle.
  • the different weights assigned to each facet of the vehicle helps to identify which facet is more important than other facets.
  • Various facets of the vehicle may include body style, drive type, transmission type, engine, exterior color, interior color, make, model, mileage, trim, price, year, book value, etc. Accordingly, the application server may generate the score value based on the weights assigned to each facet, and a value of each facet compared to the value of the facet received from the user 104.
  • the application server 156 may determine a subset of the plurality of vehicles based on the generated score value.
  • the application server may use artificial intelligence, including neural network and/or machine learning algorithms, to determine the subset of the plurality of vehicles.
  • Each vehicle of the plurality of vehicles is associated with a score value.
  • Each vehicle may be represented by a data point corresponding to the score value.
  • the plurality of data points that represent the plurality of vehicles may be distributed in a plurality of clusters. Accordingly, the cluster size reduces if the total number of clusters increases.
  • Each cluster has a centroid point that is arbitrarily selected. However, one of the clusters may have as its centroid a data point that corresponds to a vehicle based on the values provided in the form 152 by the user 104.
  • a vehicle corresponding to each data point may be assigned to a centroid that minimized the Euclidean distance.
  • a cluster is formed from all data points where a given centroid minimized the Euclidean distance. Next, within each cluster a new centroid may be chosen and the K-means clustering algorithm may be repeated until the cluster becomes stable.
  • the similar vehicles are the ones where their data points lie in the same cluster.
  • the distance between centroid and data points may be a weighted distance.
  • a vehicle corresponding to a data point is selected for the subset of the plurality of vehicles, if the Euclidean distance is within a preconfigured threshold distance.
  • the data points within the preconfigured threshold Euclidean distance correspond to the vehicles that match (e.g., have sufficient and relevant similarity to) the user 104 provided values for the vehicle. Accordingly, the user 104 may consider the vehicle whose data point is within the preconfigured threshold Euclidean distance from the centroid of the cluster.
  • the application server 156 may query the bank database server 156.
  • the bank database server 156 may be similar to the vehicle database server 154 and may communicate with the application server 156, similar to the vehicle database server 154.
  • the bank database server may store information regarding a to-be buyer’s financial information, including but not limited to monthly income, debt-to-income ratio, etc.
  • the application server 156 then generates one or more instant pricing structures based on a pricing algorithm and/or underwriting policies of the lender for the vehicle that corresponds with the values provided in the form 152 and for each vehicle in the subset of the plurality of vehicles.
  • the application server 156 may take into account price of the vehicle, the duration for which the vehicle remains unsold, the total inventory, time of the year, etc., in addition to the to-be buyer’s financial capabilities, to generate the one or more instant pricing structures according to the underwriting policies of the lender for the vehicle that corresponds with the values provided in the form 152 and for each vehicle in the subset of the plurality of vehicles. Accordingly, the application server 156 may generate the one or more instant pricing structures, each having a different value for one or more aspects of the instant pricing structure.
  • the aspects of the structure may be, for example, a down payment amount, a term of the loan, a monthly installment amount, warranty, etc.
  • the one or more instant pricing structures according to the underwriting policies of the lender may be generated by a policy engine server.
  • the one or more structures generated by the application server 156 or a policy engine server may also specify whether the one or more instant pricing structures are within an underwriting policy (e.g. would be approved by the lender) or out of policy.
  • the application server 156 may then score the combination of the vehicle based on the inputs in the form 152 and the one or more corresponding instant pricing structures based on a weight assigned to each aspect of the instant pricing structure and the vehicle.
  • the weight assigned to each aspect of the instant pricing structure and the vehicle may be statically and/or dynamically configurable in real-time.
  • the weight assigned to each aspect of the instant pricing structure and the vehicle may have the same or different value.
  • a score having a value between 0 and 1.0, both inclusive may be generated based on the combination of the instant pricing structure and vehicle similarity.
  • one or more vehicles may be presented to the user 104 as one or more alternatives to both the vehicle and structure as specified by the user 104 in the form 152.
  • the client device 150 may be a personal computer, a laptop, a desktop, a tablet, a phone, a smartphone, a smartwatch, etc., that enables the user 104 to send a request message to the application server 156 and receive a response message for the request message.
  • FIG. 1C is a block diagram of an environment including a sales management tool, according to some embodiments.
  • Environment 160 may include user 168, computing device 172, potential customer 166, inventory 170, and sales management tool 174.
  • Environment 160 may be implemented in combination with the environment for generating financing structures of FIG. 1 A and the environment for selecting the combination of the alternative inventory item and the associated structure.
  • sales management tool 174 may be implemented by or be a part of server 100, as shown in FIG. 1A.
  • User 168 may be a sales agent, employee, or other representative of a business or organization. In one embodiment, user 168 may be a salesperson or employee at a vehicle dealership. In another embodiment, user 168 may be a sales representative from any appropriate business or company having an inventory of other suitable items, e.g., a clothing retailer, a wine store, a grocery store, appliance vendor, etc. User 168 may be an individual (i.e., a human being) or a group of such individuals. In yet another embodiment, user 168 may be an artificial intelligence construct. In alternative embodiments, user 168 may be a potential customer of a business interacting with sales management tool 174 to determine a desired item without the assistance of a sales representative. User 168 may access sales management tool 174 by accessing a stored user account, e.g., using a usemame/password combination.
  • Computing device 172 may be a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof. Therefore, it will also be appreciated that any two or more components of environment 160 may similarly be executed using some or all of the two or more computers in communication with one another.
  • computing device 172 may connect to sales management tool 174 via network 130.
  • computing device 172 may have software installed thereon that facilitates the behaviors and functions of sales management tool 174.
  • Potential customer 166 may be an individual, group, or other construct seeking to purchase an item within an inventory.
  • potential customer 166 may be a consumer visiting, either in person, virtually, or through any other means, a dealership to investigate the purchase of an automobile, truck, motorcycle, bicycle, or other vehicle.
  • Potential customer 166 may provide consumer constraints such as a credit score, a credit history, a monthly income, debt obligations, etc., or this information may otherwise be available to sales management tool 174.
  • potential customer 166 may be tracked in sales management tool 174 with an appropriate user account associated with potential customer 166.
  • potential customer 166 may interact with systems that are ancillary to sales management tool 174, for example, personal banking systems to import or otherwise access consumer constraints about potential customer 166.
  • sales management tool 174 may have access to details about the consumer constraints of potential customer 166 by accessing the ancillary systems via an API call, micro-service, or other suitable interface.
  • Inventory 170 may be an inventory of tangible or intangible items available at a business or other commercial entity.
  • the items in inventory 170 are vehicles and the business offering the vehicles for sale is a car dealership.
  • inventory 170 may reflect the available vehicles owned by a dealership that potential customer 166 may purchase.
  • inventory 170 may be an inventory of food, electronics, clothes, or any other consumer product.
  • Inventory 170 may be digital objects, such as media files, streams, or software.
  • the items in the inventory are not sold at all, rather rented, leased, or otherwise transferred from the seller to the buyer.
  • One skilled in the relevant art(s) will appreciate that the variety of items that may kept in inventory 170 is expansive and far-reaching.
  • Sales management tool 174 may provide a seller with various tools and services, e.g., sales management capabilities, customer-relationship management tools, inventory management, personnel management, and any other suitable functions. In the context of a dealership, sales management tool 174 may manage an inventory of vehicles, track sales, handle finances, market vehicles, create invoices, and perform a wide-array of other tasks. Sales management tool 174 may include user interface component 176, search interface 178, data store 180, search results generator 182, consumer constraint engine 184, lender policy and pricing engine 186, dealer engine 187, dealer profile 188, policy distance engine 190, and budget distance engine 192.
  • sales management tool 174 may include user interface component 176, search interface 178, data store 180, search results generator 182, consumer constraint engine 184, lender policy and pricing engine 186, dealer engine 187, dealer profile 188, policy distance engine 190, and budget distance engine 192.
  • Sales management tool 174 may provide a search page, via which user 168 and/or potential customer 166 may examine a representation of the items in inventory 170 or a subset thereof. Such a search-results page is described in further detail below with reference to FIG. 2C. Sales management tool 174 may narrow, limit, and/or filter the results displayed in the search results to those items in the inventory that both satisfy consumer-affordability needs and lender-policy requirements. Sales management tool 174 may allow additional filtering, grouping, sorting, etc. of the search results. Sales management tool 174 may determine affordability indicators, e.g., a policy distance and a budget distance, for each displayed item and include the affordability indicators in the search result.
  • affordability indicators e.g., a policy distance and a budget distance
  • User interface components 176 may be employed by sales management tool 174 to render a user interface that includes a search page for view by user 168 using computing device 172.
  • User interface components 176 may include a JavaScript user interface library to facilitate dynamic interactions between user 168 and sales management tool 174.
  • User interface components 176 may allow a business or organization to upgrade components used by sales management tool 174 to change the experience for user 168 over time.
  • the screen displays displayed in FIG. 2C are merely exemplary, and the particular look and feel of the search results may change over time.
  • user interface components 176 may provide the ability to inform users as to whether a particular item is in-policy and in-budget via an in-policy indicator and an in budget indicator, described in further detail below as in-policy indicator 272 and in budget indicator 266.
  • User interface components 176 may also provide the ability to display quantitative indicators of how far out of policy /budget the item is, described below as policy distance 268 and budget distance 270.
  • Search interface 178 may provide a visual mechanism through which user 168 may examine a representation of items within inventory 170.
  • Search interface 178 may provide user 168 a search result that includes a subset of the total inventory of vehicles available at the dealership, the in-policy and in-budget indicators, the determined policy, sales-price-reduction, and budget distances, along with a wide-array of other details about the items and performable operations thereon.
  • Search interface 178 may provide additional capabilities to user 168 to further limit, refine, sort, group, and otherwise interact with the search results.
  • FIG. 2C below provides one example of search interface 178.
  • Data store 180 may be a plurality of data storage systems housing information relevant to, used in, and stored by sales management tool 174 and include a representation of inventory 170. Data store 180 may further house pricing information, customer information, sales records, etc. For instance, data store 180 may be a database management system or relational database tool. Data store 180 may further be a message queue or stream processing platform such as Apache Kafka or Apache Spark or other data storage systems like Apache Hadoop, HDFS, or Amazon S3, to name just some examples. Data store 180 may be a data lake, data silo, semi -structured data system (CSV, logs, xml, etc.), unstructured data system, binary data repository, or other suitable repository.
  • CSV semi -structured data system
  • Data store 180 may store thousands, millions, billions, or trillions (or more) of objects, rows, transactions, records, files, logs, etc. while allowing for the creation, modification, retrieval, archival, and management of this data.
  • data store 180 uses scalable, distributed computing to efficiently catalog, sort, manipulate, and access stored data.
  • Search results generator 182 may be employed by sales management tool 174 to generate search results and return the results to user 168 via search interface 178.
  • search results generator 182 may employ consumer constraint engine 184, lender policy and pricing engine 186, and dealer engine 187. By employing these components, search results generator 182 may narrow, limit, and/or filter the results displayed in the search results to those representations of items in inventory 170 that both satisfy consumer-affordability needs and lender-policy requirements.
  • search results generator 182 may further employ policy distance engine 190 to determine a policy distance, budget distance engine 192 to determine a budget difference, and sales price reduction distance engine to determine a sales-price reduction distance.
  • Consumer constraint engine 184 may derive, store, and provide a variety of consumer constraints and financial considerations about a multitude of past, current, and potential customers.
  • Example consumer constraints include income, credit score or rating, cash available for a down payment, and a variety of other individualized/personalized financial indicators.
  • consumer constraint engine 184 may ascertain particularized consumer constraints for potential customer 166 by employing a pre approval intake process. Such an embodiment may gather financial information from potential customer 166 and facilitate the generation of pre-approval documents from a lender. This acquiring of consumer constraints may also be accomplished through an intake process that automatically ascertains financial information while pre-qualifying the potential customer with a qualified lender.
  • consumer constraint engine 184 may import information about potential customer 166 from ancillary systems.
  • user 168 may manually enter consumer constraint information into sales management tool 174.
  • Lender policy and pricing engine 186 may generate and catalog permutations of instant pricing structures acceptable by one or more qualified lenders for items in inventory 170.
  • a lender policy may address factors such as an amount of down payment, an APR or interest rate, a monthly payment, a term length, as well as consumer constraints and various other financing conditions.
  • Lender policy and pricing engine 186 may harness or leverage an appropriate constraint programming toolkit or library that provides software for combinatorial optimization to catalog the numerous permutations of instant pricing structures in a reasonable amount of time.
  • Lender policy and pricing engine 186 may place additional limitations on the instant pricing structures to include in the permutations based on a calculated threshold of likely acceptability, i.e., how likely it is to be acceptable to the lender and the seller. Lender policy and pricing engine 186 may omit from the permutations instant pricing structures falling below a certain threshold of likely acceptability.
  • lender policy and pricing engine 186 may calculate structures for a single lender and determine if the instant pricing structures meet that single lender’s policies. However, in another embodiment, lender policy and pricing engine 186 may catalog instant pricing structures and perform calculations against those structures by integrating policy-information from multiple lenders. In such an embodiment, lender policy and pricing engine 186 may integrate and store policy information unique to the multiple lenders and display such information in the search results. [0129] Lender policy and pricing engine 186 may also generate and organize instant pricing structures that consider information about potential customer 166. In some embodiments, every single available financing option for at least one lender across all of the vehicles at a dealership may be cataloged.
  • Lender policy and pricing engine 186 may determine instant pricing structures may describe financial arrangements for the financing of the purchase of a vehicle such as: price, rebate value, cash down, taxes, licensing/plating fees, trade-in values, APR or interest rate, term lengths, amount of back-end product (GAP, Warranty), and a variety of other variables.
  • instant pricing structures may be grouped according to equity requirements, e.g., to increase a down payment and/or to decrease a sales price, to allocate financing into a front-end and/or backend, etc.
  • Dealer engine 187 may catalog, track, and maintain a litany of information about a dealer. Dealer engine 187 may compile information about a dealer (or other appropriate seller) as a dealer interacts with sales management tool 174 or ancillary systems. Dealer engine 187 may provide the information to search interface 178 to limit the search results to a subset of the inventory that matches dealer preferences and characteristics. Dealer engine may build a dealer profile, such as dealer profile 188, as described in further detail below with reference to FIG. 9. Dealer engine 187 may provide information about the dealer to lender policy and pricing engine 186 to allow lender policy and pricing engine 186 to vary the possible permutations based on characteristics and preferences of the dealer. For example, a dealership may have demonstrated a willingness to adjust prices downward when completing sale. For such a dealership, the lender policy and pricing engine 186 may consider the list price as a dynamic variable in determining the permutations to consider.
  • Dealer profile 188 may store information about the behavior of a dealership over time to improve search results by tailoring the search results to the dealerships unique characteristics.
  • dealer profile 188 may include a dealer class associated with a dealership.
  • a dealer class may be “no haggle,” for a dealership that does not negotiate certain contractual terms with potential customer 166.
  • Such a dealer class may be used by dealer engine 187 in tandem with search results generator 182 to provide instant pricing structures to a dealer that the dealer is more likely to accept, e.g., terms that do not include a negotiated rebate or other charges.
  • a class may be assigned to a dealership of “profit maximizing,” which would offer instant pricing structures to a dealership that increase the profits from the sale.
  • dealer profile 188 may store only one class per dealership, with the dealership placed in a suitable bucket. In other embodiments, a dealership may be placed in multiple buckets, i.e., assigned more than one class. Thus, as a dealership interacts with sales management tool 174 over time, a class may be assigned to a dealership based on that dealership’s behavior, and search results generator 182 may provide search results more suited to a dealership’s unique characteristics.
  • dealer engine 187 may allow a dealership to manually configure dealer profile 188. In this fashion, a dealership may tailor the instant pricing structures provided by lender policy and pricing engine 186 and the search results provided by search results generator 182 to match changing goals. For example, sales goals might change at a particular time of year for a particular dealership towards a focus on moving inventory. For this period, a dealership may manually configure their dealer profile 188 towards an increased likelihood of acceptance across all the instant pricing structures.
  • search results generator 182 may provide a search result that sorts by, highlights, prioritizes, etc., vehicles that simultaneously meet consumer-affordability, lender-policy requirements, and user- preferences. Given the set of consumer constraints, every single possible permutation of instant pricing structures may be considered for every vehicle within the vehicle inventory. These permutations may be grouped according to entity requirements, e.g., all cash down increase, all sales price reduction, or some combination thereof at gradients. The permutations may be further limited by considering user vehicle preferences within lender policy and pricing engine 186.
  • lender policy and pricing engine 186 may refine and pre-filter the permutations of instant pricing structures based on make, model, year, type, etc. as provided by potential customer 166. With only those vehicles and instant pricing structures displayed that satisfy the consumer constraints, a sales representative is guaranteed to select a vehicle for which financing options are available with at least one lender. This avoids the problem of demoing a vehicle that cannot ultimately be financed to potential customer 166.
  • Policy distance engine 190 may determine a distance needed for an instant pricing structure to apply to a vehicle that satisfies consumer constraints, dealership preferences, and available lender-approved instant pricing structure. In one embodiment, policy distance engine 190 may calculate a dollar amount needed to be added to the down payment for a nearest instant pricing structure to apply. In another embodiment, policy distance engine 190 may calculate a dollar amount that the sales price needs to be reduced. In another embodiment, both of these types of policy distances may be calculated and displayed. One skilled in the relevant art(s) will understand that these two approaches require separate calculations because as the sales price is reduced the loan-to- value ratio changes, thus further impacting a potential instant pricing structure.
  • policy distance engine 190 may calculate a policy distance in accordance with other variables, e.g., a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • budget distance engine 192 may determine a distance needed to bring an instant pricing structure into compliance with a potential customer’s budget. Budget distance engine 192 may calculate a dollar amount needed to be added to the down payment to bring the item and associated instant pricing structure into conformance with specified budget information. Budget distance engine 192 may also calculate a dollar amount that the sales price needs to be reduced to bring the item and associated instant pricing structure into conformance with specified budget information. In another embodiment, both of these types of budget distances may be calculated and displayed. In other embodiments, budget distance engine 192 may calculate a budget distance in accordance with other variables, e.g., a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • other variables e.g., a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • FIG. 2A is an example display output, according to some embodiments.
  • the display output may be generated by environment for selecting the combination of the alternative inventory item and the associated instant pricing structure.
  • a vehicle- 1 202 is the vehicle according to the configuration specified by the user 104 in the form 152.
  • alternative vehicles vehicle-2 through vehicle-6204 of the vehicle- 1 202 are shown in FIG. 2 A.
  • the alternative vehicles 204 are determined as described above.
  • each vehicle of the alternative vehicles 204 has one or more instant pricing structures that may be similar to the instant pricing structure of the buyer’s choice.
  • the buyer’s choice of vehicle vehicle-1 202 may be a compact size vehicle of a particular make.
  • the alternative vehicles vehicle-2 through vehicle-6204 may be identified that all meet the specific criteria of being a compact size vehicle but from other manufacturers. Since the buyer may be more interested in purchasing a compact size vehicle from other manufacturers at the terms according to the instant pricing structure of the buyer’s choice, the buyer may be more likely to proceed to select a vehicle from the alternative vehicles 204.
  • FIG. 2B is a block diagram of a user interface rendered on an application of a seller device or user device, according to some embodiments.
  • FIG. 2B shows examples meant to illustrate the concepts and may not accurately reflect realistic structures.
  • FIG. 2B shows examples meant to illustrate the concepts and may not accurately reflect realistic structures.
  • User interface 210 may be rendered on application 118 or application 144. User interface 210 may be used to generate instant pricing structure data objects for a specific vehicle and user. User interface 210 may include user interface elements 212 and 213.
  • User interface element 212 may include information about the user and the vehicle.
  • the information about the user can include the name of the user, a customer number/identifier, or monthly income.
  • the information about the vehicle may include make, model, year, buy rate (e.g., APR, interest rate, or the like), VIN, stock number, estimated payment, dealer fees, and max participation.
  • User interface element 213 may include multiple tabs 216.
  • Tabs 216 may include an updated structure tab, select vehicle tab, verify income tab, fast funding tab, and message center tab.
  • user interface element 213 may include an input box 218.
  • Input box 218 may be used to input a “goal” or constraint for generating instant pricing structure data objects. For example, input box 218 may be configured to receive a maximum monthly payment amount.
  • User interface element 213 may also include a list 230 of instant pricing structure data objects categorized based on attribute 222. Parameters 214 associated with each respective attribute may be rendered adjacent to each attribute 222. Each of the instant pricing structure data objects in list 230 may be the highest-ranked instant pricing structure data object within the set of the respective attribute 222.
  • pricing engine 102 may receive a request to generate sets of instant pricing structure data objects.
  • the request can include the user information, an input associated with the user, and information about the given vehicle.
  • the input associated with the user can be a target monthly payment of $483 for a given vehicle (e.g., 2018 Mohawk PS 200).
  • Pricing engine 102 may identify attributes 222 associated with the dealer, as described above. Attributes 222 may include less front end, more cash down, less back end, and no back end. Pricing engine 102 may identify one or more parameters 214 for each of attributes 222, for which the values may be varied such that the instant pricing structure is within the constraints of the respective attribute, input (e.g., $483), lender’s credit policy, and other constraints, as described above. Parameters 214 for less front end may be reduced front end and longer loan term. Parameters 214 for more cash down may be longer term and more cash down. Parameters 214 for less back end may be longer term and reduced back end. Parameters 214 for no back end may be remove back end and same structure.
  • Pricing engine 102 may determine thresholds for each of parameters 214, as described above. Pricing engine 102 may generate sets of instant pricing structure data objects for each attribute 222 by incrementing the values of the one or more parameters for each respective attribute within the threshold while maintaining the instant pricing structures within the constraints of the attribute, input, lender’s policy, and other constraints. Pricing engine 102 can use a lender’s methodology for calculating/generating an instant pricing structure data object. The methodology may use user information and information about the given vehicle to generate the instant pricing structure data object. Furthermore, the methodology can include Bayesian regression algorithms, decision trees, pricing grids, or various equations to generate instant pricing structure data objects
  • Pricing engine 102 may rank the instant pricing structures within each set based on the likelihood of being selected. Pricing engine 102 may identify the highest-ranked instant pricing structure data object for each attribute 222 and generate interface 200, including the identified instant pricing structure data object for each attribute 222. Pricing engine 102 may cause display of interface 210 by application 118 or application 144.
  • Information about the instant pricing structure data objects may be included in user interface element 213.
  • the information may include monthly payment amount, buy rate, term length, sales price, cash down, net trade-in, warranty, and GAP.
  • User interface element 213 may also indicate whether the instant pricing structure data object is within budget and in-policy.
  • User interface element 213 may also include options to change “goals” by selecting one of the goals button 220.
  • Each goal may correspond to a user or dealer goal.
  • different goals may correspond to different inputs.
  • different goals may correspond to desired attributes or constraints.
  • a request to generate sets of instant pricing structure data objects may be transmitted to pricing engine 102.
  • the request may include the details of the selected goal.
  • An instant pricing structure data object may be selected by selecting apply button
  • Pricing engine 102 may transform the instant pricing structure data object to a final pricing structure data object.
  • the final pricing data object can share the same information as the instant pricing structure data object.
  • Pricing engine 102 can execute an action on the final pricing structure. The action can be the purchase of a vehicle.
  • FIG. 2C is an example screen display of a search result in a sales management tool, according to some embodiments.
  • FIG. 2C will be described with reference to FIG. 1C. However, FIG. 2C is not limited to that example embodiment.
  • Screen display 250 provides a mechanism through which user 168 may view a subset of represented items in inventory 170, e.g., vehicles, and sort, filter, and otherwise interact with the subset.
  • Screen display 250 provides interface fields via which budget information may be received about potential customer 166.
  • Screen display 250 may include target monthly payment 252, term 254, cash down 256, search field 258, results 260, items 262, and monthly payment 264.
  • Screen display 250 may further include affordability indicators, e.g., indicators as to the applicability of policies and whether the policy is in budget, i.e., in-budget indicator 266 and in-policy indicator 272.
  • Screen display 250 may also include calculated distances, i.e., policy distance 268 and budget distance 270.
  • Target monthly payment 252 may be entered by user 168 to reflect a desired amount of monthly payments for potential customer 166.
  • Various methods may be employed by sales management tool 174 to receive budget information about potential customer 166.
  • Target monthly payment 252 provides one suitable approach where the amount is a dollar value desired to be paid monthly towards purchasing the item.
  • This budget information may be used subsequently by budget distance engine 192 to determine whether a selected instant pricing structure (e.g., instant pricing structure data object) is in-budget and, if out-of-budget, a distance to bring the instant pricing structure within the budget.
  • Target monthly payment 252 in FIG. 2C is displayed as being entered as dollars- per-month, however, other suitable approaches may be used, e.g., in an amount-per-year, in different currencies, using a slider or other input mechanism, etc.
  • Term 254 may be entered by user 168 to limit the instant pricing structures considered by lender policy and pricing engine 186 to a particular term length.
  • Term 254 may be entered by user 168 to limit the instant pricing structures considered by lender policy and pricing engine 186 to a particular term length.
  • user 168 has entered 60 months, i.e., a 5-year term, in term 254.
  • the result of this exemplary input is that subsequent calculations will only consider instant pricing structures having a 60-month term.
  • Other suitable input mechanisms and approaches may be employed to receive a value representing term 254.
  • user 168 may be able to specify a term range.
  • all instant pricing structures may be examined, regardless of their term.
  • Cash down 256 may be entered by user 168 to indicate an amount of a down payment offered by potential customer 166.
  • Cash down 256 may be specified in an appropriate currency using any suitable input mechanism.
  • cash down 256 may specify a range of cash down values.
  • Other fields may be included in addition to cash down 256, term 254, and target monthly payment 252 within the scope of this disclosure, e.g., a desired APR rate or range, variance ranges, overpayment amounts, etc.
  • Search field 258 provides user 168 with the ability to further refine the search results by adding additional search criteria.
  • user 168 may enter a particular VIN or Stock Number of an item in inventory 170 to limit the results.
  • user 168 may enter a year, make, model, price range, days in stock, mileage, or any other suitable characteri sites about a vehicle or instant pricing structure to further refine the search results.
  • Results 260 may display a list of items in inventory 170 that satisfy entered search criteria.
  • Results 260 may include a variety of information about each displayed item.
  • results 260 may default to displaying all items in inventory 170, with the ability to divide the results across pages to improve performance and readability.
  • results 260 may be sorted by default in a variety of ways, e.g., by year, model, price, etc.
  • results 260 may be sorted by the determined policy distance, i.e., vehicles with a positive in-policy indicator may display first, followed by the remaining vehicles sorted in descending order by the distance to being in policy. Thus, the vehicles quantitatively closest to being in policy may display first.
  • the sorting and filtering of results 260 may be controlled by user 168 through appropriate sorting/grouping mechanisms.
  • Items 262 may represent the goods in inventory 170. Items 262 may reflect a determined subset of items in inventory 170. In the exemplary embodiment illustrated in screen display 250, a variety of other information is displayed to distinguish items 262, e.g., the VIN, make, year, model number, cost, book value, days in stock, book, differential, payment per month, and APR. In this fashion, user 168 may view only those items that potential customer 166 may ultimately receive financing for from a qualified lender. This associated information may differ based on the nature of items 262 and other factors.
  • Monthly payment 264 may display in the search results when lender policy and pricing engine 186 determines a matching instant pricing structure for a particular item in inventory 170.
  • Monthly payment 264 may reflect an amount of money that potential customer 166 pays each month towards the approved financing agreement upon completion of the sales transaction.
  • lender policy and pricing engine 186 may calculate monthly payment 264 by subtracting the amount of cash down from the price of the item, then dividing this difference by the term of the loan, while considering the monthly interest rate. As indicated in FIG.
  • screen display 250 may not display monthly payment 264 or may display monthly payment 264 as zero because no matching instant pricing structure was found by lender policy and pricing engine 186.
  • In-budget indicator 266 may provide user 168 a visual indication of whether the determined instant pricing structure further complies with the provided budget information, e.g., target monthly payment 252.
  • in-budget indicator 266 may display as “In Budget,” “Near Budget,” or “Over Budget,” as “On Target,” “Near Target,” or “Over Target,” as “In Payment,” “Near Payment,” or “Over Payment,” or in other suitable language/symbols.
  • Appropriate colors or other visual cues may be included to easily convey this information to user 168, e.g., the words “In Budget” may display with a green background, the words “Near Budget” may display with a yellow background, and the words “Over Budget” may display with a red background.
  • An item may be considered “Near Budget” when the item and policy do not satisfy the budget information, but do fall within a threshold amount of satisfying the budget information. For example, an item may display as “Near Budget” if the monthly payment under the determined instant pricing structure falls within 50 dollars of target monthly payment 252. As indicated in FIG.
  • in-budget indicator 266 may be omitted from the display. The calculation of in-budget indicator 266 is described in further detail below with reference to FIG. 9.
  • Policy distance 268 may reflect the determined distance for an item to be covered by an instant pricing structure that satisfies the consumer constraints, a lender policy, and the item. Such an example is displayed in FIG. 2C with respect to item 262E and item 262F.
  • item 262A, item 262B, item 262C, and item 262D have a null value displaying in policy distance 268 because these items have a matched instant pricing structure, i.e., the search result displays an in-policy indicator of “In Policy.”
  • policy distance 268 may be displayed as a dollar (or other currency) amount required to be added to the down payment to bring the item into coverage.
  • policy distance 268 may display as a dollar amount required in the form of a sales-price reduction. In another embodiment, both of these types of policy distances may be calculated and displayed. An efficient approach to calculating policy distance 258 across all items in inventory 170 is described in further detail below with reference to FIG. 7.
  • budget distance 270 may reflect an amount needed to bring the item and determined instant pricing structure into accordance with budget information specific to potential customer 166, e.g., target monthly payment 252.
  • budget distance 270 represents an amount needed to be additionally applied to the down payment to bring the item into budget.
  • budget distance 270 can be a sales price reduction or other approach to bring a determined instant pricing structure into conformance with the specified budget information. Budget distance 270 thus operates independently from policy distance 268 to provide important information to user 168 for use in the sales process. As portrayed in FIG.
  • budget distance engine 192 determines that the item and associated payment terms complied with the budget information. For example, the monthly payment specified by the applicable policy was less than target monthly payment 272.
  • In-policy indicator 272 may provide an indication of whether an instant pricing structure was found for an item.
  • in-policy indicator 272 may display as a positive indicator when a policy is found, e.g., a green check mark, the words “In Policy”, or other suitable visual cue readily conveying the information to user 168 that lender policy and pricing engine 186 found an instant pricing structure satisfying the item, the consumer constraints, and a lender policy.
  • a negative indicator may display, e.g., a red exclamation point, the words “Not in Policy”, or other suitable visual cue.
  • in-policy indicator may display a “Near Policy” indicator when no instant pricing structure is found, but the item has a calculated policy distance falling within a certain threshold. For example, an item may display as “Near Policy” if less than 50 additional dollars added to the down payment would result in a matching instant pricing structure.
  • FIG. 3 illustrates a plurality of clusters plotted on a two-dimensional graph, according to some embodiments.
  • the two-dimensional graph may be generated by the environment for selecting the combination of the alternative inventory item and the associated structure, as shown in FIG. IB.
  • the plurality of clusters are plotted in two dimensions for easy visualization using principal component analysis (PCA),
  • PCA principal component analysis
  • the features used for comparison of vehicles can be n-dimensional.
  • an unsupervised learning technique for data classification for example, K-means
  • K-means a plurality of data points are randomly selected as a plurality of cluster centers that are also known as centroids in the art, and then each data point is assigned to a cluster center of the plurality of cluster centers with the closest mean. A new mean is calculated for the cluster, and the process is repeated until it reaches convergence.
  • various facets of the vehicle may include body style, drive type, transmission type, engine, exterior color, interior color, make, model, mileage, trim, price, year, book value, etc.
  • Each facet may be assigned a different weight, as shown in the table below as an example.
  • a data point representing a vehicle may include a plurality of vectors in which each vector may correspond to a facet of the plurality of facets.
  • Visualizing a cluster of such data points, including multi-dimensional vectors, can be simplified by performing principal components analysis to orthogonally transform possibly correlated variables into uncorrelated principal components.
  • a plurality of data points 302 are shown, in which on the X-axis principal component 1 304 may be represented, and on the Y-axis principal component 2306 may be represented.
  • the number of components for PCA may be pre-configured.
  • the number of components may be 2.
  • the principal component 1 304 and the principal component 2306 may be selected that account for the given amount of variance.
  • the amount of variance for the principal component 1 304 maybe about 80 percentages
  • the amount of variance for the principal component 2 306 maybe about 20 percentages.
  • FIG. 4 is a flowchart illustrating a method for determining an alternative inventory item and a structure (e.g., instant pricing structure), according to some embodiments.
  • Method 400 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps can be needed to perform the disclosure provided herein. Further, some of the steps can be performed simultaneously or in a different order than shown in FIG. 4, as will be understood by a person of ordinary skill in the art.
  • Method 400 shall be described with reference to FIG. IB. However, method 400 is not limited to that example embodiment.
  • the application server 156 may retrieve a plurality of inventory items based on a plurality of records stored in a database, as described above.
  • the inventory item may be, for example, a vehicle, an appliance such as a television, a refrigerator, etc., furniture such as a sofa, an office desk, etc.
  • the database may be at a separate database server, for example, as described above, the vehicle database server 154, or the database may be at the application server 156.
  • the application server 156 may generate score values of the plurality of inventory items based on configuration information.
  • the configuration information includes a plurality of facets that describe an asked inventory item, for example, a vehicle.
  • the configuration information also includes a value associated with a facet of the plurality of facets.
  • the configuration information may include one or more default values for the facet of the plurality of facets.
  • the plurality of facets may include but are not limited to make, model, year of manufacture, transmission type, engine, trim, mileage, a fuel type of the vehicle, a vehicle condition, etc.
  • the application server 156 may generate score values, as described above with reference to FIG. IB, and, therefore, the mechanism of generating a score value is not repeated.
  • the application server 156 may determine a subset of the plurality of inventory items based on a plurality of data points within a preconfigured Euclidean distance from a centroid of a cluster of a plurality of customers.
  • an artificial intelligence including a neural network and/or machine learning algorithm, may be used to determine the subset of the plurality of inventory items.
  • PCA described above may be used for training the neural network and/or machine learning algorithm. Since only a few facets of the plurality of facets may be important, the few important facets may be determined or maybe preconfigured depending on the inventory item. The PCA is based on a plurality of dimensions that correspond with the number of few important facets.
  • a number of clusters may be arbitrarily selected based on a total number of the plurality of inventory items retrieved by the application server 156 at step 402.
  • the number of clusters may be preconfigured or determined according to various methods known to a person skilled in the art, such as elbow, silhouette, and/or gap statistic methods, etc. Since one centroid is the data point that corresponds to asked inventory, centroids for the other clusters may be arbitrarily selected.
  • the plurality of data points that correspond to the plurality of inventory items retrieved at step 402 may be analyzed using the PCA for the reduced number of dimensions.
  • the application server 156 may determine a first principal component that corresponds with data points of variance up to a first variance value, and a second principal component that corresponds with data points of variance up to a second variance value.
  • the first variance value may be different from the second variance value.
  • the first variance value may be about 80 percentages
  • the second variance value may be about 20 percentages.
  • the application server 156 may generate one or more instant pricing structures corresponding to the subset of the plurality of inventory items, as described herein.
  • the one or more generated instant pricing structures may include one or more aspects that have a value within a preconfigured threshold limit.
  • the one or more aspects may include a loan term, a rate of interest, a down-payment value, a maximum loan amount, and/or a monthly installment, etc.
  • the preconfigured threshold limit may be within +/- 0.2 percentage range.
  • the application server 156 may generate the one or more instant pricing structures corresponding to the subset of the plurality of inventory items.
  • the one or more instant pricing structures may be dynamically generated based on the instant pricing structure information associated with the asked inventory item according to the configuration information.
  • the instant pricing structure information may generated based on the one or more input factors that may include at least one of a credit record, a storage time period, and an inventory condition, etc. The procedure of generating the one or more instant pricing structures is described in detail with reference to FIG. 1 above, and, therefore, is not being repeated.
  • the application server 156 may score combinations of the asked inventory item according to the configuration information and the instant pricing structure information associated with the asked inventory item, and combinations of the subset of the plurality of inventory items and the corresponding one or more instant pricing structures, for similarity to the configuration information and the instant pricing structure information associated with the asked inventory item. And, at step 412, the application server 156 may present, based on the score corresponding to the combination of the configuration information and the instant pricing structure, the subset of the plurality of inventory items as an alternative of the asked inventory item.
  • FIG. 5 is a flowchart illustrating a process for generating sets of instant pricing structures, in accordance with an embodiment.
  • Method 500 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps can be needed to perform the disclosure provided herein. Further, some of the steps can be performed simultaneously or in a different order than shown in FIG. 5, as will be understood by a person of ordinary skill in the art. [0174] Method 500 shall be described with reference to FIG. 1 A. However, method 500 is not limited to that example embodiment.
  • server 100 receives a request to generate sets of instant pricing structure data objects for a vehicle in an inventory of a dealer.
  • Each instant pricing structure data object is to be unique and constrained based on an input associated with a user, policy of a lender, and other constraints.
  • the instant pricing structure data object may be for a loan for the vehicle.
  • the input can be a desired monthly payment amount, interest rate, loan term, or the like.
  • the dealer can provide input on the seller device.
  • server 100 identifies a set of attributes associated with the dealer.
  • the attributes may be associated with previously selected final pricing structure data objects.
  • the attributes may include the preferences of a dealer for generating final pricing structure data objects.
  • the attributes can include the final sale price of the vehicle, a ratio of the backend value of the sales price and the frontend value of the sales price, percentage of the sales price that is the backend value as compared to the total value of the vehicle, funded structured flag, the percentage of down payment, details related to the vehicle (e.g., condition of the vehicle, whether the vehicle is new or used, type of vehicle, or the like), or the like.
  • server 100 identifies a parameter corresponding to each attribute.
  • the parameter may be used to generate an instant pricing structure data object.
  • Server 100 identifies the parameter for a given attribute such that the instant pricing structure data object remains within the constraints of the given attribute, input, lender’s policy, and other constraints.
  • parameters can include term, sales price, cash down, trade value, warranty, gap, participation, rebate, alternative vehicles, or the like.
  • server 100 identifies a threshold for the parameter.
  • the threshold may be a minimum or maximum value for the parameter.
  • Server 100 may determine the threshold based on constraints of the attribute, input, lender policy, or other constraints. Furthermore, server 100 may also determine the threshold based on historical data associated with the dealer, predetermined information about the parameter, or information about the user or vehicle.
  • server 100 generates a set of instant pricing structure data objects of the requested sets of instant pricing structure data objects for each attribute of the set of attributes by incrementally varying the values of the parameter within the threshold of the parameter, of each respective attribute.
  • Each instant pricing structure data object is within the constraints of the respective attribute, input, lender’s policy, and other constraints.
  • server 100 ranks the instant pricing structure data objects in each set of instant pricing structure data objects based on a score indicating a likelihood of being selected.
  • the likelihood of being selected can be determined based on previously selected instant pricing structure data objects. For example, server 100 can match characteristics of the previously selected instant pricing structure data objects to the instant pricing structure data objects in each of the set of instant pricing structure data objects. Those instant pricing structure data objects that most closely match the previously selected instant pricing structure data objects can be ranked higher within the set of instant pricing structure data objects.
  • server 100 causes display of the sets of instant pricing structure data objects on seller device 110.
  • the sets of instant pricing structure data objects can be rendered broken up by set. A portion of each set of instant pricing structure data objects of each set of instant pricing structure data rendered. For example, the top-ranked (e.g., top five, ten, or the like) instant pricing structure data objects can be rendered for each set of instant pricing structure data objects.
  • server 100 transforms an instant pricing structure data object from the sets of instant pricing structure data objects into a final pricing structure data object, in response to a selection of the instant pricing structure data object and independent of further input associated with the user.
  • the instant pricing structure data object can be an actionable instant pricing structure data object. That is, the final pricing structure data can include the same data as the pricing structure data object.
  • server 100 executes an action on the final pricing structure.
  • the action can be completing a purchase of the vehicle.
  • FIG. 6 is a flowchart illustrating the process for identifying a set of instant pricing structures from a plurality of instant pricing structures.
  • Method 600 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps can be needed to perform the disclosure provided herein. Further, some of the steps can be perfonned simultaneously or in a different order than shown in FIG. 6, as will be understood by a person of ordinary skill in the art.
  • Method 600 shall be described with reference to FIG. 1 A. However, method 600 is not limited to that example embodiment.
  • server 100 generates a plurality of instant pricing structure data objects for each vehicle in the dealer’s inventory.
  • the plurality of instant pricing structure data objects may be all the possible permutations of instant pricing structure data objects for each vehicle in the dealer’s inventory.
  • Each instant pricing structure data object is to be unique.
  • the instant pricing structure data object may be for a loan for the vehicle.
  • the input can be a desired monthly payment amount, interest rate, loan term, or the like.
  • the dealer can provide input on the seller device.
  • server 100 receives a request to identify an instant pricing structure data object for each of a set of attributes from the plurality of instant pricing structure data objects for a specific user and vehicle.
  • the request may include an input provided by the user.
  • the input may be a maximum monthly payment amount.
  • server 100 identifies a parameter from the set of parameters corresponding to the respective attribute, the value of which can be varied to generate instant pricing structure data objects within the constraints of the attribute, input, lender policy, and other constraints.
  • server 100 may identify a threshold of each parameter.
  • the threshold may be a minimum or maximum value for the parameter.
  • Server 100 may determine the threshold based on constraints of the attribute, input, lender policy, or other constraints. Furthermore, server 100 may also determine the threshold based on historical data associated with the dealer, predetermined information about the parameter, or information about the user or vehicle.
  • server 100 identifies a set of instant pricing structure data objects from the plurality of instant pricing structure data objects for which the parameter corresponding to the respective has been varied within the threshold, while the values of the other parameters remain constant default values.
  • the identified sets may be for the specific user and vehicle, and the identified sets may be within the constraints of the given attribute, input, lender policy, and other constraints.
  • server 100 identifies an instant pricing structure data object from each set.
  • Server 100 may identify an instant pricing structure data object with the highest likelihood of being selected out of each respective set.
  • Each of the identified instant pricing structure data objects may correspond to an attribute of the set of attributes.
  • server 100 generates an interface including each identified instant pricing structure data objects categorized based on attribute.
  • the interface may include information about the instant pricing structure data object.
  • server 100 causes display of the interface on application 118 or application 144.
  • a user or dealer may interact with the interface to select and finalize an instant pricing structure. Alternatively, a user or dealer may modify the constraints to generate new instant pricing structures.
  • FIG. 7 is a flowchart illustrating a method of displaying a search result that displays affordability indicators in a sales management tool, according to some embodiments.
  • Method 700 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 7, as will be understood by a person of ordinary skill in the art(s).
  • Method 700 shall be described with reference to FIGS. 1C and 2C. However, method 700 is not limited to that example embodiment.
  • sales management tool 174 may receive budget information from and/or about potential customer 166.
  • user 168 may enter an appropriate value in target monthly payment 252.
  • the value may represent an amount of desired monthly payment for potential customer 166 in dollars or other currency.
  • the budget information may take other forms and/or include additional details about the budget available to potential customer 166, e.g., a percentage of salary.
  • sales management tool 174 may calculate an appropriate target monthly payment 252 for display in the interface based upon financial factors about potential customer 166 known to sales management tool 174, e.g., by considering the monthly income and expenses of potential customer 166.
  • sales management tool 174 may receive budget information about potential customer 166 through an interaction with an external service.
  • sales management tool 174 may retrieve a multitude of instant pricing structures catalogued by lender policy and pricing engine 186. Sales management tool 174 may narrow these instant pricing structures according to parameters inputted in search field 258.
  • the instant pricing structures may include factors such as price of the item, an amount of down payment, an APR or interest rate, a monthly payment, a term length, as well as consumer constraints and various other financing conditions.
  • the instant pricing structures may comprise millions or billions or more of permutations. Accordingly, sales management tool 174 may retrieve these instant pricing structures and store them in an appropriate data structure capable of manipulating the vast number of records.
  • polices may be organized into a decision tree for use in determining whether an instant pricing structure exists that satisfies the item, lender-policies, and customer constraints.
  • sales management tool 174 may retrieve an item in inventory 108. Sales management tool 174 may limit the selection of items in inventory 170 according to parameters inputted in search field 258. For example, if the search is limited to “blue” vehicles, then sales management tool 174 may retrieve an appropriate blue vehicle in inventory 170. In one embodiment, sales management tool 174 may examine all items in inventory 170 by default, thus performing subsequent calculations for all items in inventory 170. Sales management tool 174 may examine the items in a particular order or randomly.
  • sales management tool 174 may employ lender policy and pricing engine
  • lender policy and pricing engine 186 may determine if the item retrieved in 706 is satisfied by an instant pricing structure among the instant pricing structures retrieved in 704.
  • lender policy and pricing engine 186 may consider the price of the item, consumer constrains, the loan- to-value ratio, etc..
  • lender policy and pricing engine 186 may build a decision tree of all available instant pricing structures and iteratively traverse that decision tree to heuristically determine a matching instant pricing structure.
  • the algorithm may further handle various edge cases and employ thresholds to ensure the timeliness of results. This approach is described in further detail below with reference to FIG. 4.
  • lender pricing and policy engine 118 may employ additional techniques to optimize the performance of these calculations. For example, lender policy and pricing engine 186 may use parallelization techniques across the entirety of inventory 170 or a subset relevant to the search.
  • sales management tool 174 may employ policy distance engine 190 to determine a policy distance.
  • the policy distance quantitatively indicates how close a particular item is to having a matching instant pricing structure. In one approach, this distance can be expressed as a dollar amount required to be added to the down payment, e.g., as specified in cash down 256. In another approach, this distance can be expressed as a dollar amount that the sales price of the item needs to be reduced.
  • policy distance engine 190 may employ both approaches and calculate both values. If an appropriate instant pricing structure is found in 708, then policy distance engine 190 may set the policy distance to zero or null, as an instant pricing structure covering the customer constraints, lender policy, and item characteristics has been found.
  • policy distance engine 190 may calculate the policy distance by building a decision tree based on the various policies retrieved in 704 and then iteratively traversing the decision tree using estimated cash down increments until the nearest instant pricing structure is found, a threshold is reached, or an edge case is attained. Further detail about this technique is provided below with reference to FIG. 8.
  • sales management tool 174 may employ budget distance engine 192 to calculate a budget distance based on the item retrieved in 706, the instant pricing structure determined in 708, and the budget information retrieved in 702.
  • the budget distance may quantitatively represent an amount needed to bring an item/ instant pricing structure into compliance with a potential customer’s budget.
  • the budget distance may be expressed as a dollar amount required to be added to the down payment, e.g., as specified in cash down 256, to bring the item into compliance with the budget information.
  • the budget distance may be expressed as a dollar amount that the sales price of the item needs to be reduced by to bring the item into compliance with budget information.
  • budget distance engine 192 may employ both approaches and calculate both values.
  • Policy distance engine 190 may engage lender policy and pricing engine 186 to determine if the item retrieved in 706 is satisfied by a policy among the policies retrieved in 704. Further detail about the calculation of the budget distance is provided below with reference to FIG. 9.
  • sales management tool 174 may determine if the item retrieved in 306 is the last item to be retrieved in inventory 170 and displayed in the search result. If not, then method 700 may return to 706 to retrieve the next item. If yes, then method 700 may proceed to 816. In some embodiments, steps 706 through 714 may be performed in parallel to optimize performance.
  • sales management tool 174 may display the search results for user 168.
  • the search result may include policy distance 268 and budget distance 270.
  • the search result may include in-budget indicator 266 and in-policy indicator 272.
  • Sales management tool 174 may employ many suitable design approaches to relay the search results. One such example is described above with reference to exemplary screen display 250.
  • the search results screen may facilitate further refinement of the search results through additional sorting, grouping, and filtering.
  • the results may be sorted by policy distance 268, i.e., items with matching instant pricing structures may display at the top of the search result and the items without matching instant pricing structures may appear in order of proximity, i.e. by policy distance.
  • user 168 may enter a detail applicable to items in inventory 170, and the items will be further limited to display only that detail.
  • sales management tool 174 may display search results in a table, spreadsheet, graph or other visualization, document, text file, or other suitable medium.
  • FIG. 8 illustrates a method 800 of calculating a policy distance for display in a search result in a sales management tool, according to some embodiments.
  • Method 800 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 8, as will be understood by a person of ordinary skill in the art(s).
  • sales management tool 174 may build a decision tree of the available instant pricing structures catalogued by lender policy and pricing engine 186, or a subset thereof relevant to a particular inquiry.
  • the instant pricing structures may be specified as a series of criteria or rules, and the instant pricing structures may be specified using a comma-separated value (CSV) file, XML file, JSON file, or other suitable manner of organization.
  • CSV comma-separated value
  • the rules may further specify periods of applicability, e.g., a date range or other temporal aspect.
  • the decision tree may be built such that each node of the tree- structure includes appropriate rules allowing the traversal of the tree using the customer constraints and details about the item.
  • sales management tool 174 may traverse the decision tree built in 802 by applying consumer constraints and other details, e.g., price about the particular item being examined. Sales management tool 174 may also consider term 254 and cash down 256 when traversing the decision tree. In other embodiments, sales management tool 174 may consider additional variables such as term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc. Policy distance engine 190 may examine the rules at each branch of the tree.
  • policy distance engine 190 and/or lender policy and pricing engine 186 may determine that the instant pricing structure found in the leaf node satisfies the cost of the item, the policy, and the one or more constraints. This instant pricing structure found through the traversal may be preserved for use in subsequent steps. However, when no leaf node is found matching the item and customer constraints, then policy distance engine 190 and/or lender policy and pricing engine 186 may determine a nearest instant pricing structure and calculate a policy distance after redoing the estimates in step 710. In such an instance, lender policy and pricing engine 186 may perform the above steps using the revised estimates. When the revised estimates result in a traversal of the decision tree finding a leaf node that satisfies the cost of the item, the policy, and the one or more constraints, the associated instant pricing structure may be stored and referred to as the nearest instant pricing structure.
  • sales management tool 174 may handle various edge cases. These edge cases provide safeguards that act when situations arise that would otherwise cause the decision-tree traversals to occur infinitely and/or to prevent inappropriate real-world scenarios from occurring. Such edge cases require additional logic. For example, if an extremely low financing amount is sought, e.g., 50 dollars, no instant pricing structure may exist at all to cover the amount. This is known as the “minimum amount to finance” floor. Similar edge cases may be required with respect to the sales price reduction values. In these instances, policy distance engine 190 may short circuit the evaluation to avoid unnecessary calculations and may return an appropriate error message or perform other suitable action.
  • edge cases provide safeguards that act when situations arise that would otherwise cause the decision-tree traversals to occur infinitely and/or to prevent inappropriate real-world scenarios from occurring. Such edge cases require additional logic. For example, if an extremely low financing amount is sought, e.g., 50 dollars, no instant pricing structure may exist at all to cover the amount. This is known as the “minimum amount to finance” floor. Similar edge cases may
  • sales management tool 174 may determine if a threshold has been reached.
  • policy distance engine 190 may employ a 50-cent threshold, and once the estimated cash down increments or sales price decrements drops shrinks below .5, the iterations will stop and the affordability indicators calculated and returned for the item. If a threshold has not been reached, then method 800 may return to 810 to continue iteratively traversing the decision tree. If a threshold has been reached, then method 800 may proceed to 812 to return the search result to user 168.
  • sales management tool 174 may estimate updated constraints to re-apply to the decision tree to determine if a more optimal instant pricing structure can be found, i.e., an instant pricing structure with a smaller policy distance. Sales management tool 174 may estimate a different amount of cash down and/or a different sales price reduction. These estimates may be referred to as estimated cash down increments/decrements when revising the amount of cash down. The estimates may be referred to as estimated sales price reduction increments/decrements when examining the sales price reductions.
  • sales management tool 174 may double the amount of cash down when a policy has not been matched in the prior traversal, and sales management tool 174 may halve the amount of cash down when a policy was found in the prior traversal of the decision tree.
  • Other appropriate scaling factors may be used based on the size of inventory 170 and other factors.
  • sales management tool 174 may return a result including policy distance
  • In-policy indicator 272 may be positive when a policy is found in the tree traversal during the first iteration. In policy indicator 272 may be negative when additional cash-down increments and/or sales- price reductions are determined.
  • policy distance 268 may be the optimal estimated cash down increment that results in an instant pricing structure being found that satisfies the item, the lender policies, and the customer constraints when traversing the decision tree in 404. In another embodiment, policy distance 268 may be the optimal estimated sales-price reduction decrement that results in an instant pricing structure being found by traversing the decision tree in 404. In another embodiment, both calculations may be performed and returned to determine the policy distance.
  • sales management tool 174 may return a result including policy distance
  • Sales management tool 174 may then employ a suitable design approach to displaying the affordability indicators, e.g., as displayed in FIG. 2C.
  • FIG. 9 is a flowchart illustrating a method of calculating a budget distance for an item displayed in a search result in a sales management tool, according to some embodiments.
  • Method 900 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 9, as will be understood by a person of ordinary skill in the art(s).
  • Method 900 shall be described with reference to FIGS. 1C and 2C. However, method 900 is not limited to that example embodiment.
  • budget decision engine 192 may receive an item and instant pricing structure.
  • the matching instant pricing structure may already have been determined (e.g., as described above with reference to FIG. 7 and 8) and budget distance engine 192 may receive the appropriate information for use in subsequent calculations.
  • budget distance engine 192 may re-engage lender policy and pricing engine 186 to determine the applicable instant pricing structures, nearest instant pricing structure, policy and budget distances, etc.
  • budget decision engine 192 may determine if the item being examined satisfies the budget information received from potential customer 166. If the item is within budget, then method 900 may proceed to 906. However, if the item does not satisfy the budget information, then method 900 may proceed to 908. [0217] In 906, budget decision engine 192 may return a positive in-budget indicator, e.g., in-budget indicator 266. A positive in-budget indicator alerts user 168 that the item complies with the entered budget information, e.g., target monthly payment 252, under the terms of the matched policy. Budget decision engine 192 may return the positive indicator to search results generator 182 for incorporation into the search results being calculated across inventory 170 or a subset thereof and displayed to user 168.
  • a positive in-budget indicator e.g., in-budget indicator 266.
  • a positive in-budget indicator alerts user 168 that the item complies with the entered budget information, e.g., target monthly payment 252, under the terms of
  • sales management tool 174 may calculate a budget distance, i.e., budget distance 270 for the item and policy received in 902.
  • Budget distance 270 may be represented as a sales price reduction amount, an increased cash down amount, both of the foregoing, or another suitable quantitative indicator.
  • budget distance 270 may be represented by the difference between target monthly payment 252 and the monthly payment specified in the received policy.
  • budget distance 270 may be represented as a dollar amount that the item is out of budget on a per monthly basis.
  • the budget distance may be a change to term, warranty, guaranteed-asset-protection insurance modifications, other backend and front end products, trade value, participation, rebates, incentives, etc.
  • sales management tool 174 may return the budget distance to search results generator 182 to display in the search results.
  • FIG. 10 is a block diagram of example components of computer system 1000.
  • One or more computer systems 1000 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.
  • Computer system 1000 can be used, for example, to implement methods 400 of FIG. 400, 500 of FIG. 500, 600 of FIG. 6, 700 of FIG. 7, 800 of FIG. 8, and 900 of FIG. 9.
  • computer system 1000 can be at least part of server 100, seller device 110, user device 140, database 148, client device 150, vehicle database server 154, application server 156, bank database server 158, and user device 172, as shown in FIGS. 1A-1C.
  • Computer system 1000 may include one or more processors (also called central processing units, or CPUs), such as a processor 1004.
  • processors also called central processing units, or CPUs
  • Processor 1004 may be connected to a communication infrastructure or bus 1006.
  • Computer system 1000 may also include user input/output device(s) 1003, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 1006 through user input/output interface(s) 1002.
  • processors 1004 may be a graphics processing unit (GPU).
  • a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications.
  • the GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
  • Computer system 1000 may also include a main or primary memory 1008, such as random access memory (RAM).
  • Main memory 1008 may include one or more levels of cache.
  • Main memory 1008 may have stored therein control logic (i.e., computer software) and/or data.
  • Computer system 1000 may also include one or more secondary storage devices or memory 1010.
  • Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage device or drive 1014.
  • Removable storage drive 1014 may interact with a removable storage unit 1018.
  • Removable storage unit 1018 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data.
  • Removable storage unit 1018 may be program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
  • Removable storage drive 1014 may read from and/or write to removable storage unit 1018.
  • Secondary memory 1010 may include other means, devices, components, instrumentalities, or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1000.
  • Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 1022 and an interface 1020.
  • Examples of the removable storage unit 1022 and the interface 1020 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
  • Computer system 1000 may further include a communication or network interface
  • Communication interface 1024 may enable computer system 1000 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 1028).
  • communication interface 1024 may allow computer system 1000 to communicate with external or remote devices 1028 over communications path 1026, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc.
  • Control logic and/or data may be transmitted to and from computer system 1000 via communication path 1026.
  • Computer system 1000 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.
  • PDA personal digital assistant
  • Computer system 1000 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.
  • “as a service” models e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a
  • JSON JavaScript Object Notation
  • XML Extensible Markup Language
  • YAML Yet Another Markup Language
  • XHTML Extensible Hypertext Markup Language
  • WML Wireless Markup Language
  • MessagePack XML User Interface Language
  • XUL XML User Interface Language
  • proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.
  • a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device.
  • control logic software stored thereon
  • control logic when executed by one or more data processing devices (such as computer system 1000), may cause such data processing devices to operate as described herein.

Abstract

La présente invention concerne, dans des modes de réalisation, un système, un procédé et un produit programme d'ordinateur destinés à générer et à fournir des structures de tarification instantanée.
PCT/US2021/060798 2020-11-25 2021-11-24 Génération et fourniture de structures de tarification instantanée WO2022115586A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA3199990A CA3199990A1 (fr) 2020-11-25 2021-11-24 Generation et fourniture de structures de tarification instantanee
EP21899107.3A EP4252171A1 (fr) 2020-11-25 2021-11-24 Génération et fourniture de structures de tarification instantanée

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US17/104,888 US20220164814A1 (en) 2020-11-25 2020-11-25 Automatically generating instant pricing structure data objects
US17/104,684 2020-11-25
US17/104,684 US11436561B2 (en) 2020-11-25 2020-11-25 Matching inventory characteristics and structure
US17/104,888 2020-11-25
US17/133,027 2020-12-23
US17/133,027 US20220198556A1 (en) 2020-12-23 2020-12-23 Inventory affordability and policy distance calculator

Publications (1)

Publication Number Publication Date
WO2022115586A1 true WO2022115586A1 (fr) 2022-06-02

Family

ID=81756088

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/060798 WO2022115586A1 (fr) 2020-11-25 2021-11-24 Génération et fourniture de structures de tarification instantanée

Country Status (3)

Country Link
EP (1) EP4252171A1 (fr)
CA (1) CA3199990A1 (fr)
WO (1) WO2022115586A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112036937A (zh) * 2020-08-19 2020-12-04 深圳市分期乐网络科技有限公司 一种商品的定价方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086187A1 (en) * 1999-02-05 2005-04-21 Xfi Corporation Apparatus and methods for a computer-aided decision-making system
US20080046383A1 (en) * 2006-08-17 2008-02-21 Edith Hirtenstein System and method for providing a score for a used vehicle
US20080103946A1 (en) * 1995-10-30 2008-05-01 Triton Ip, Llc Sales force automation and method
US20100023357A1 (en) * 1996-09-04 2010-01-28 Walker Jay S Conditional Purchase Offer Management System
US20100153198A1 (en) * 1999-12-13 2010-06-17 Autosavings Network, Inc. System and Method for Providing Incentives to Purchasers

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080103946A1 (en) * 1995-10-30 2008-05-01 Triton Ip, Llc Sales force automation and method
US20100023357A1 (en) * 1996-09-04 2010-01-28 Walker Jay S Conditional Purchase Offer Management System
US20050086187A1 (en) * 1999-02-05 2005-04-21 Xfi Corporation Apparatus and methods for a computer-aided decision-making system
US20100153198A1 (en) * 1999-12-13 2010-06-17 Autosavings Network, Inc. System and Method for Providing Incentives to Purchasers
US20080046383A1 (en) * 2006-08-17 2008-02-21 Edith Hirtenstein System and method for providing a score for a used vehicle

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112036937A (zh) * 2020-08-19 2020-12-04 深圳市分期乐网络科技有限公司 一种商品的定价方法、装置、计算机设备和存储介质
CN112036937B (zh) * 2020-08-19 2023-11-28 深圳市分期乐网络科技有限公司 一种商品的定价方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CA3199990A1 (fr) 2022-06-02
EP4252171A1 (fr) 2023-10-04

Similar Documents

Publication Publication Date Title
US11948128B2 (en) Intelligent preprocessing routing to decisioning services
US20220198555A1 (en) Generating optimal strategy for providing offers
US11113704B2 (en) Systems and methods for interactive annuity product services using machine learning modeling
US20180101591A1 (en) Methods and Systems for Cluster-Based Historical Data
US11080725B2 (en) Behavioral data analytics platform
US20210192437A1 (en) Automated systems for reducing computational loads in the mass execution of analytical models using scale-out computing
US20130246310A1 (en) Systems and methods for providing an online private capital marketplace
US20210065294A1 (en) Trading platforms using market sentiment and dynamic risk assessment profiles
US20220198556A1 (en) Inventory affordability and policy distance calculator
US20220164814A1 (en) Automatically generating instant pricing structure data objects
US20170083881A1 (en) System and method for automatically ranking payment promises
WO2022115586A1 (fr) Génération et fourniture de structures de tarification instantanée
US10242068B1 (en) Methods and systems for ranking leads based on given characteristics
US10255245B1 (en) Optimizing response creation and delivery for lending queries
JP7053077B1 (ja) シングルユーザアクションによる意思決定を支援するための方法及びシステム
US10860593B1 (en) Methods and systems for ranking leads based on given characteristics
US20210027317A1 (en) Inventory and structure finder
US11544727B2 (en) System and method for generating financing structures using clustering
US20200349642A1 (en) Configuring user interface functionality based on background processing of data related to pre-qualification status
US11157928B2 (en) Systems and methods for using a predictive engine to predict failures in machine-learning trained systems
US20240135395A1 (en) Systems and methods for using a predictive engine to predict failures in machine-learning trained systems
US11436561B2 (en) Matching inventory characteristics and structure
US20220277387A1 (en) Automatically generating optimized data structure objects
US20210117855A1 (en) Systems and methods for using a predictive engine to predict failures in machine-learning trained systems for display via graphical user interface
US20230360032A1 (en) Methods and systems for dynamic update to access control rules in a computing system based on blockchain monitoring

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21899107

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3199990

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021899107

Country of ref document: EP

Effective date: 20230626