CROSS-REFERENCE TO RELATED APPLICATIONThis application claims the benefit of U.S. Provisional Application No. 62/375,572, filed Aug. 16, 2016, which is hereby incorporated by reference in its entirety.
TECHNICAL FIELDThis disclosure relates generally to vehicle transfer services and more particularly to a computing system that allows a vehicle transfer transaction to be performed on a vehicle dealer's website.
BACKGROUNDConventional transactions between vehicle dealers and customers have several disadvantages. For instance, the estimates for loan and lease payments provided by many vehicle dealers are often inaccurate because they are based on incomplete information about the prospective customer. Moreover, such estimates fail to take into account a variety of factors that may impact the amount of the payments. This makes the process of performing a transaction more frustrating and inefficient for both the vehicle dealer and the customer.
Furthermore, vehicle transactions are often subject to a short transaction window. In other words, a dealer is more likely to retain a customer if the dealer is able to initiate a transaction, negotiate the terms of a transaction, and close the transaction in a shorter time window. Thus, in addition to the added frustration and inefficiency, the inability to rapidly and accurately provide data to a prospective customer may result in the dealer losing a vehicle sale or lease to a competitor.
BRIEF DESCRIPTION OF THE DRAWINGSThe disclosed embodiments have advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.
FIG. 1 illustrates an example system environment for a vehicle transfer system, according to one embodiment.
FIG. 2 is a block diagram illustrating components of the vehicle transfer system, according to one embodiment.
FIG. 3A is a flow chart illustrating a process for performing a vehicle transfer transaction with the vehicle transfer system, according to one embodiment.
FIGS. 3B-3H are example screenshots of the transaction interface, according to one embodiment.
FIG. 4A is a flow chart illustrating a process for selecting an operating mode for a vehicle transfer transaction, according to one embodiment.
FIG. 4B is an example screenshot of another portion of the transaction interface, according to one embodiment.
FIG. 5A is a flow chart illustrating a process for providing a loan selection interface that presents loan offers from a plurality of different lenders, according to one embodiment.
FIGS. 5B-5E illustrate example data structures for providing a loan selection interface that presents loan offers from a plurality of different lenders, according to one embodiment.
FIGS. 5F-5H are example screenshots of the loan selection interface, according to one embodiment.
FIG. 6A is a flow chart illustrating a process for performing a lease calculation and presenting the results in a lease calculation interface, according to one embodiment.
FIGS. 6B-6D are example screenshots of the lease calculation interface, according to one embodiment.
FIG. 7 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in one or more processors (or controllers), according to one embodiment.
DETAILED DESCRIPTIONThe Figures (FIGS.) and the following description relate to preferred embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.
Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
Overview of the DisclosureMany conventional vehicle dealer websites provide financing calculator tools that can calculate monthly payments on a loan or a lease for a vehicle. However, such calculator tools simply provide rough estimates of monthly payments and typically do not account for any user-specific information. For example, a payment calculator on a typical vehicle dealer's website may provide a sample loan payment based on a single annual percentage rate (APR), loan term, and down payment that cannot be adjusted. As a result, the same monthly payment estimate is provided for display to each customer who views the website, regardless of the customer's particular circumstances, such as the customer's credit score, desired loan term, desired down payment amount, and whether the customer wishes to trade in a vehicle. Furthermore, the calculator tools on traditional dealer websites simply provide non-binding estimates; in order to actually purchase or lease a vehicle from the vehicle dealer, a customer typically has to visit the dealership and complete a transaction in person with a vehicle dealer, which commonly results in a different set of loan or lease terms than what was indicated on the website's calculator tool.
In contrast to the calculator tools on traditional websites, a vehicle transfer system provides a transaction interface for display as part of a vehicle dealer's website. The transaction interface makes the vehicle dealer's website transactional, which means the customer can complete an entire vehicle transfer transaction (e.g., pay for a vehicle with cash, pay for a vehicle with a loan, or lease a vehicle) by interacting with the transaction interface without having to make an in-person visit to the vehicle dealer.
The vehicle transfer system collects information about the customer. For example, the transaction interface prompts the customer to provide biographical and identifying information, such as the customer's name, address, and birth date, and information about the customer's trade-in vehicle. The vehicle transfer system also interacts with other systems to collect information about the vehicle and additional information about the customer. For example, the system performs a web scraping process on the dealer's website to collect information about the particular vehicle being transferred and about rebates that the dealer is offering. The system may also perform calls to an application programming interface (API) provided by the vehicle's manufacturer to request general information about the vehicle, such as the vehicle's manufacturer suggested retail price (MSRP). As another example, the system may communicate with a credit reporting agency to request a credit score for the customer, or communicate with an automobile valuation service (e.g., a server that provides KELLY BLUE BOOK values) to request a value for the trade-in vehicle.
If the customer wishes to finance the transaction with a loan, the vehicle transfer system provides a loan selection interface that allows the customer to adjust loan parameters (e.g., loan term and down payment) and view different loan offers matching the selected loan parameters. The vehicle transfer system requests the loan offers from a plurality of different lender systems by sending information about both the customer and the vehicle to the lender systems. This method of selecting a loan offer provides at least two key advantages. First, unlike the estimated of loan payments generated by tools on conventional dealer websites, each of the loan offers is customized to the vehicle transfer transaction and represents an offer that the customer can accept. Second, the vehicle transfer system requests a plurality of loan offers with different sets of loan parameters (e.g., different loan terms and down payments), and the customer can use the loan selection interface to rapidly browse through the different loan offers. In contrast, conventional method of applying for a vehicle loan require the customer to specify a single set of loan parameters and only display a single loan offer matching the specified parameters.
If the customer wishes the finance the transaction with a lease, the vehicle transfer system provides a lease calculation interface that allows the customer to adjust lease parameters (e.g., down payment, lease term, and annual mileage allowance), and view a monthly loan payment for those lease parameters. The vehicle transfer system performs a leasing calculation that divides the available upfront capital for the vehicle transfer transaction into first portion that is allocated to capitalized cost reduction and a second portion that is allocated to upfront expenses. Dividing the available upfront capital in this manner is advantageous because it uses a portion of the available upfront capital to cover the upfront expenses, which means the customer does not have to make any additional out-of-pocket payments at lease signing. In contrast, a conventional lease allocates the entirety of the available upfront capital to capitalized cost reduction, which means that the customer has to pay for upfront expenses in addition to any cash down payment or vehicle trade-in that the customer was already planning to make.
System EnvironmentFIG. 1 illustrates anexample system environment100 for avehicle transfer system110, in accordance with one example embodiment. As shown inFIG. 1, thesystem environment100 includes avehicle transfer system110, avehicle dealer system120, a customer device130, alender system140, and athird party system150. Although the example shown inFIG. 1 includes a singlevehicle dealer system120, customer device130,lender system140, andthird party system150, thesystem environment100 may include multiple instances of one or more of these devices andsystems120 through150.
The system environment also includes anetwork160 through which the systems anddevices110 through150 may communicate with each other. Thenetwork160 may comprise any combination of local area and/or wide area networks, using both wired and/or wireless communication systems. In one embodiment, thenetwork160 uses standard communications technologies and/or protocols. For example, thenetwork160 includes communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of networking protocols used for communicating via thenetwork160 include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over thenetwork160 may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some example embodiments, all or some of the communication links of thenetwork160 may be encrypted using any suitable technique or techniques.
Thevehicle transfer system110 interacts with some or all of the other systems anddevices120 through150 to perform a vehicle transfer transaction. As referred to herein, a vehicle transfer transaction is a financial transaction in which the right to possess and use a vehicle is transferred from a vehicle dealer to a customer in exchange for some sort of compensation. Thevehicle transfer system110 may further communicate with some or all of theother systems120 through150 to secure one or more forms for financing for the vehicle transfer transaction. More particularly, thevehicle transfer system110 may, as part of the vehicle transfer transaction, provide interfaces that allow the customer to select terms for a financing agreement (e.g., a loan or a lease agreement) and formally agree to be bound by the financing agreement (e.g., sign for the loan or the lease).
Thevehicle dealer system120 is a computing system operated by a vehicle dealer that provides information about the vehicle dealer, such as contact information for the vehicle dealer, information about one or more vehicles in the possession of the vehicle dealer, and rebates being offered by the dealer. In one embodiment, thevehicle dealer system120 is a web server that provides a publicly available website operated by the vehicle dealer. As referred to herein, a vehicle dealer is an entity that possesses or otherwise has the right to sell, lease, rent, or temporarily transfer control of a vehicle to another entity (e.g., a customer). A vehicle dealer may be a licensed vehicle dealership or vehicle manufacturer (e.g., a business entity) or a solo independent being (e.g., a human entity) that interfaces with thevehicle transfer system100 for transferring control of a vehicle to facilitate a vehicle transfer transaction.
The customer device130 is a computing device operated by a customer to view the information provided by thedealer system120. The customer device130 may be a computing device that belongs to the customer, such as a personal laptop computer, desktop computer, tablet computer, or smartphone. The customer device130 may alternatively be a computing device that a vehicle dealer provides for customer to use. For example, the customer device130 may be a computing device that is physically located inside a vehicle dealer in a manner that is accessible to customers, which allows a customer to view the information provided by thevehicle dealer system120 during an in-person visit to the vehicle dealership. As referred to herein, a customer is a person or entity that seeks to possess or otherwise buy, lease, rent, or otherwise at least temporarily obtain control of a vehicle from another entity (e.g., a vehicle dealer). A customer may be a licensed vehicle dealership (e.g., a business entity) or a solo independent being (e.g., a person) that may interface with thevehicle transfer system100 for obtaining control of a vehicle to facilitate a vehicle transfer transaction.
Thelender system140 is operated by a loan lender, banker, or other capital source that seeks to make funds available in a loan to another entity (e.g., to a customer for use in at least temporarily obtaining control of a vehicle from a vehicle dealer) with the expectation that the element of value will be repaid (e.g., within a certain amount of time, in addition to any interest and/or fees, either in increments or as a lump sum). Such a loan lender may be a licensed public or private group or a financial institution (e.g., a business entity or collection of individuals) or a solo independent being (e.g., a human entity) that may interface withVehicle transfer system100 for making a loan to a vehicle borrower to facilitate a vehicle transfer transaction.
The third-party system150 provides a third party application or service that processes or provides any suitable subject matter that may be used by any other system or device in thesystem environment100 to enable a vehicle transfer transaction. In one embodiment, thethird party system150 is operated by a financial institution (e.g., banks) that provides financial information or credit scores for any suitable users or vehicles of the platform. For example, the third-party system may be operated by an information management service and credit information service, such as TransUnion of Chicago, Ill., Equifax Inc. of Atlanta, Ga., Experian PLC of Dublin, Republic of Ireland, Edmunds.com, Inc. of Santa Monica, Calif., Black Book auto valuation of Heart Business Media Corporation of New York, N.Y., Kelley Blue Book auto valuation of Cox Automotive of Atlanta, Ga., Plaid Technologies, Inc. of San Francisco, Calif., Twilio of San Francisco, Calif., and the like, from which data may be collected by any suitable data hub or data management system (“DMS”) and shared with the vehicle transfer system110).
As other examples, the third-party system150 may be operated by a risk management research entity (e.g., LEXISNEXIS GROUP of Dayton, Ohio), an ancillary goods/services provisioning entity (e.g., IASDIRECT.com and/or any other suitable entity that may provide vehicle service contract (“VSC”) products and/or finance and insurance (“F&I”) products and/or guaranteed auto protection (“GAP”) products and/or tire and wheel coverage (“T&W”) products to another entity of the system environment100), backup and recovery provider entities (e.g., EVAULT, a SEAGATE COMPANY of San Francisco, Calif.), an underwriter, a loan servicer, a financial transaction electronic network (e.g., Automated Clearing House (“ACH”) that may at least partially manage the National Automated Clearing House Association (“NACHA”) of Washington, D.C., and/or UCB), electronic signature facilitator entities (e.g., DOCUSIGN of San Francisco, Calif.), a loan agent, an investor, a social network that provides any suitable connection information between various parties, a government agency/regulator, a licensing body, a third party advertiser, an owner of relevant data, a seller of relevant goods/materials, a software provider, a maintenance service provider, or a scheduling service provider.
Although thesystem environment100 and the systems anddevices110 through150 are described herein with respect to the transfer of a vehicle from a dealer to a customer, the system environment can alternatively be used to transfer a different type of good or service (e.g., a real estate property, business supply, etc.) according to one or more of the concepts described in this disclosure.
Example Vehicle Transfer SystemFIG. 2 is a block diagram illustrating components of thevehicle transfer system110, according to one example embodiment. In the embodiment shown inFIG. 2, thevehicle transfer system110 includes an operating mode selection module, atransaction module210, aninformation collection module215, aloan selection module220, and alease calculation module225. In other embodiments, thevehicle transfer system110 may include additional, fewer, or different components, and the functionality described herein may be distributed among the components of thevehicle transfer system110 in a different manner. It is noted that the modules described herein may be configured to execute their functionality on a computing system, for example, such as one having components of the architecture described with reference toFIG. 7.
The operatingmode selection module205 receives information indicating whether a customer interacting with thevehicle transfer system110 is in the presence of the dealer and selects an operating mode for the customer's vehicle transfer transaction. In one embodiment, the operatingmode selection module205 selects one of three operating modes based on the received information: an assisted mode, which is selected when the customer is in the physical presence of a dealer; a remote-assisted mode, which is selected when the customer is engaged in communication with a dealer (e.g., via phone, video conference, text messaging, or email) but is not in the physical presence of the dealer; and an unassisted mode, which is selected when the customer neither in the physical presence of a dealer nor engaged in real-time communication with a dealer. An example process for selecting the operating mode for a vehicle transfer transaction is described in more detail below with reference toFIG. 4A.
Thetransaction module210 provides a transaction interface that facilitates a vehicle transfer transaction between a customer and a dealer. The transaction interface prompts the customer to provide information, such as biographical information and credit information, and the information is sent from the device displaying the transaction interface (e.g., the customer device130) to thevehicle transfer system110. Other components of thevehicle transfer system110, such as theinformation collection module215, theloan selection module220, and thelease calculation225 receive and use the information to perform other functions of thevehicle transfer system110.
Theinformation collection module215 interacts with other systems in thesystem environment110 to collect information that is not provided as user input to a user interface. The collected information may be any information that is used to facilitate a vehicle transfer transaction, such as information about a make and model of a vehicle (e.g., the vehicle's MSRP), information about a particular vehicle that is available to be transferred (e.g., the vehicle's mileage, vehicle identification number, make and model, trim options, and asking price), or additional information about a customer (e.g., a credit score or some other measure of the customer's creditworthiness).
Theinformation collection module215 can use a variety of different techniques to collect information for a vehicle transfer transaction. In one embodiment, theinformation collection module215 requests information by querying an application programming interface provided by a third-party system150. For example, themodule215 may query an application programming interface (API) of a vehicle manufacturer to request information about a particular make and model of a vehicle. As another example, themodule215 may receive biographical information about a customer via the user interface provided by thetransaction module210 and provide the biographical information to an API of a credit reporting agency in order to request the customer's credit score. In one embodiment, theinformation module215 additionally or alternatively collects information by scraping the content of one more websites. For example, themodule215 scrapes a dealer's website (e.g., a website provided by the dealer system120) to collect information about rebates offered by the dealer or information about one or more vehicles that the dealer currently has in its possession.
Theloan selection module220 provides a loan selection interface that presents loan offers from a plurality of different lenders. In one embodiment, theloan selection module220 receives loan offers from a plurality of lenders and generates a loan array that contains loan offers for a plurality of different loan terms and down payment amounts. The loan selection interface includes graphical elements, such as sliders, that allow the customer to input a desired loan term and down payment amounts. After receiving the customer's desired loan term and down payment amount, theloan selection module220 accesses the loan array to identify loan offers matching the desired loan term and down payment amount and displays the identified loan offers. The operation of theloan selection module220 is described in further detail below with reference toFIGS. 5A-5H.
Thelease calculation module225 receives lease parameters from a plurality of different sources, performs a lease calculation based on the lease parameters, and provides the results of the lease calculation for display in a lease calculation interface. The lease calculation interface also allows a customer to adjust certain lease parameters. If the customer adjusts one or more lease parameters, the lease calculation performs an updated lease calculation and presents the results of the updated lease calculation in the lease calculation interface. In one embodiment, the lease calculation solves for a balancing point between the total upfront capital that is available to the customer and the total amount that the customer is to pay upfront when formally agreeing to the lease (e.g., at lease signing). The operation of thelease calculation module225 is described in further detail below with reference toFIGS. 6A-6D.
Performing a Vehicle Transfer TransactionFIG. 3A is a flow chart illustrating aprocess300 for performing a vehicle transfer transaction with thevehicle transfer system110, according to one embodiment. In other embodiments, theprocess300 may include additional, fewer, or different steps, and some of the steps shown inFIG. 3A may be performed concurrently or in a different order.FIGS. 3B-3D are example screenshots of the transaction interface, according to one embodiment. For ease of discussion, theprocess300 shown inFIG. 3A will be described in conjunction with the example screenshots shown inFIGS. 3B-3D.
Thevehicle transfer system110 collects305 information about the vehicle to be transferred. The collected information can include any information about the vehicle that is used over the course of the vehicle transfer transaction, such as the vehicle's MSRP, the vehicle dealer's asking price for the vehicle, any rebates that are applicable to the vehicle, the vehicle identification number (VIN) of the vehicle, and the mileage of the vehicle.
In one embodiment, the information is collected305 by theinformation collection module215. For example, theinformation collection module215 performs a web scraping process on a vehicle dealer's website to collect information about rebates offered by the dealer (e.g., the amount of the rebate, whether the rebate is available for a loan, a lease, or both, the vehicles for which the rebate is available, and other conditions of the rebate), and information about particular vehicles that are available on the vehicle dealer's website (e.g., the vehicle's mileage, vehicle identification number, make and model, trim options, and asking price). In one embodiment, the vehicle dealer's website maintains separate web pages for each available vehicle and for available rebates, and the web scraping process collects information from one or more of these web pages.
As another example, theinformation collection module215 queries an API provided by the vehicle manufacturer or a third party to request general information for the vehicle's make and model, such as the vehicle's MSRP. In one embodiment, theinformation collection module215 submits the API call to request vehicle information from a vehicle manufacturer when the customer (e.g., via the customer device130) views a web page for the vehicle on the vehicle dealer's website. Theinformation collection module215 may also query an API provided by the vehicle manufacturer, the vehicle dealer, or a third party to request rebates that are applicable to the vehicle. For instance, theinformation collection module215 submits an API call with the VIN of a vehicle, and the API returns a data structure (e.g., in JSON format) containing information about each rebate applicable to the vehicle. As still another example, theinformation collection module215 can receive information from another system, such as avehicle dealer system120, through a direct data transfer (e.g., through the file transfer protocol (FTP)). In one embodiment, thevehicle dealer system120 sends the vehicle dealer's current vehicle inventory to theinformation collection module215 via an FTP transfer at regular intervals (e.g., once per day at a predetermined time of day, once per week at a predetermined time on a predetermined day of the week, etc.).
Thevehicle transfer system110 provides310 a transaction interface. In one embodiment, thetransaction module210 provides310 the transaction interface as part of a web page for the vehicle that is provided by thevehicle dealer system120. In other words, the web page for the vehicle includes the transaction interface, which is provided by thetransaction module210 of thevehicle transfer system110, and also includes information about the vehicle that is provided by the vehicle dealer via thedealer system120.
A web page containing an example of a transaction interface is shown inFIG. 3B. In the example shown inFIG. 3B, thetransaction interface340 displays a portion of the information that was collected110 by thevehicle transfer system110. In particular, the example transaction interface displays the dealer's asking price for the vehicle and the total amount of the rebates available for the vehicle. In the example shown inFIG. 3B, thetransaction module210 also computes a preliminary estimate of monthly loan payments for the vehicle based on the information that was collected205 about the vehicle and on a default set of financing parameters (e.g., for the loan estimate shown inFIG. 3B, the default set of financing parameters specify a down payment of $0, a loan term of 60 months, and that the customer's credit rating can be characterized as “excellent”). The estimated loan payments and default financing parameters are then provided for display as part of the transaction interface. Although not included in the example shown inFIG. 3B, thetransaction module210 may additionally or alternatively compute a preliminary estimate of monthly lease payments for the vehicle and provide the estimated lease payments for display in the transaction interface.
Thevehicle transfer system110 receives315 a selection of a financing method for the vehicle transfer transaction. In one embodiment, thetransaction module210 facilitates three financing methods: a lease, a loan, or an upfront cash payment for the full price of the vehicle. In this embodiment, thetransaction module210 may allow the vehicle dealer to enable a subset of the three financing options for a particular vehicle. For instance, in the example shown inFIG. 3B, the cash and loan options are enabled, but the lease options is disabled. If multiple options are enabled for a vehicle, the transaction interface for the vehicle allows the customer to select one of the enabled financing options, and thetransaction module210 receives315 the customer's selection. If a single financing option is enabled for a vehicle, then the enabled option automatically becomes the selected option.
Thevehicle transfer system110 receives320 information from the customer. For example, thetransaction module210 provides one or more screens as part of the transaction interface that prompt the customer to provide biographic information (e.g., the customer's name and address), information about the customer's creditworthiness (e.g., the customer's employment information and housing expenses), and information about a vehicle that the customer is trading in (e.g., the make, model, and year of the trade-in vehicle, the number of miles on the trade-in vehicle's odometer, and other information about the condition of the trade-in vehicle). An example screen for providing biographic information is shown inFIG. 3C.
Thevehicle transfer system110 may also use some of the received information to request additional information. For example, theinformation collection module205 may provide information about the trade-in vehicle to athird party system150 operated by an automobile valuation service (e.g., a server that provides Kelley Blue Book values for vehicles) to request a valuation for the trade-in vehicle. As another example, theinformation collection module205 may provide biographical information about the customer to a third-party system150 operated by a credit information service (e.g., TransUnion, Equifax, Experian) to request a credit score (or some other measure of creditworthiness) of the customer.
Thevehicle transfer system110 provides an interface that allows the customer to customize the financing method by adjusting financing parameters via an interface provided by thevehicle transfer system110. In particular, if the transaction is to be financed with a loan, thevehicle transfer system110 selects320 a loan based on the customer's interactions with a loan selection interface provided by thesystem110. The loan selection interface may allow the customer to adjust parameters such as loan term and down payment percentage and then display loan offers matching the parameters. If the transaction is to be financed with a lease, thevehicle transfer system110 calculates325 a lease based on the customer's interactions with a lease calculation interface provided by thesystem110. The lease calculation interface may allow the customer to adjust parameters such as down payment amount and miles driven per year, and then display the results of a lease calculation that is performed based on the parameters. Example processes for selecting320 a loan and calculating325 a lease are described in further detail below with reference toFIGS. 5A and 6A, respectively.
After the customer has finished adjusting the parameters, thevehicle transfer system110 completes330 the vehicle transfer transaction. In one embodiment, thetransaction module210 presents a summary interface to the customer (e.g., to be displayed on the customer device130). An example summary interface is shown inFIGS. 3D-3F. As shown inFIGS. 3D-3F, the summary interface summarizes the terms of the vehicle transfer transaction, such as pricing information for the vehicle being transferred, rebates that are being applied, taxes and fees for the transaction, a total cost of the transaction, and how the transaction will be financed. The summary interface also includes a graphical element (e.g., the “I'm ready to sign” button) that allows the customer to formally agree to the terms of the vehicle transfer transaction. If the customer formally agrees to the transaction, thetransaction module210 may present a confirmation interface that confirms the transaction and provides the customer with details on how to take possession of the vehicle. An example confirmation interface is shown inFIGS. 3G-3H.
Selection of Operating ModeFIG. 4A is a flow chart illustrating aprocess400 for selecting an operating mode for a vehicle transfer transaction, according to one embodiment. In other embodiments, theprocess400 may include additional, fewer, or different steps, and the steps shown inFIG. 4A may be performed in a different order. The first twosteps405,410 of theprocess400 are described below as being performed by the operatingmode selection module205. However, in other embodiments, thesesteps405,410 of theprocess400 may be performed by a different component of thevehicle transfer system110 or by a different device in the system environment. For example, these steps of theprocess400 may instead be performed on thecustomer device120.
The operatingmode selection module205 receives405 presence data for a customer. As referred to herein, presence data is any data that can be used to determine whether the customer is inside a vehicle dealership or whether the customer is engaged in communication with a vehicle dealer. Examples of presence data include, for example, a device identifier of the customer device130 (e.g., a MAC address), an IP address used by the customer device to communicate with other systems on thenetwork160, location information for the customer device130 (e.g., latitude-longitude coordinates from a GPS receiver on the customer device130), user input received from the customer via the customer device130 (e.g., the customer's response to an interface prompt that asks the customer to indicate whether he or she is presently inside a vehicle dealership or communicating with a vehicle dealer), or an indication that a real-time communication feature (e.g., a text chat feature, a voice chat feature, or a video chat feature) is being used on the customer device130 to facilitate communication between the customer and the vehicle dealer.
After receiving405 one or more items of presence data, the operatingmode selection module205 selects410 an operating mode based on the presence data. As noted above, the operatingmode selection module205 can select one of three operating modes: an assisted mode, a remote-assisted mode, and an unassisted mode. The operatingmode selection module205 selects410 the assisted mode if the presence data indicates that the customer device130 in a location associated with a vehicle dealer. Themodule205 selects410 the remote-assisted mode if the presence data indicates that the customer not in a location associated with a vehicle dealer but is in real-time communication with a vehicle dealer. Finally, themodule205 selects410 the unassisted mode if the presence data indicates that the customer is neither in a location associated with a vehicle dealer nor engaged in real-time communication with a vehicle dealer.
In one embodiment, the operatingmode selection module205 first uses the presence data to determine whether the customer is in a location associated with a vehicle dealer. If the presence data indicates that the customer is in a location associated with a vehicle dealer, then the operatingmode selection module205 selects410 the assisted mode. For example, if the operatingmode selection module205 received405 an IP address for the customer device130, then themodule205 determines whether the IP address belongs to a vehicle dealer. If the IP address belongs to a vehicle dealer, then the customer device130 is likely to be accessing thevehicle transfer system110 from the physical premises of the vehicle dealer. As another example, if the operatingmode selection module205 received405 a device identifier for the customer device130, then themodule205 determines whether the device identifier is associated with a vehicle dealer. As still another example, if the operatingmode selection module205 received405 a location for the customer device130, then themodule205 determines whether the location is inside a geofence surrounding a vehicle dealer's location.
If the presence data indicates that the customer is not in a location associated with a vehicle dealer, then operatingmodule selection module205 selects410 between the remote-assisted mode and the unassisted mode based on whether the presence data indicates that the customer is engaged in real-time communication with a vehicle dealer. For example, the presence data may additionally include an indication that a real-time communication feature is being used on the customer device103 to facilitate communication between a customer and a vehicle dealer.
After an operating mode is selected410, thevehicle transfer system110 may modify415 one or more screens of the transaction interface based on the operated mode. In one embodiment, the operatingmode selection module205 configures thetransaction module210 to operate in the selected operating mode, and thetransaction module210 presents different transaction interfaces when operating in different operating modes. In the assisted mode, it is assumed that both the vehicle dealer and customer both have physical access to the customer device130, so thetransaction module210 may modify the transaction interface to include dealer-use-only fields to input custom values for rebate amounts and selling price (e.g., resulting from an in-person negotiation between the customer and the vehicle dealer) or a custom amount for a trade-in value (e.g., resulting from the vehicle dealer performing an in-person inspection of the customer's trade-in vehicle).
In both the assisted mode and the remote-assisted mode, it is assumed that the vehicle dealer is available to explain various details of the transaction to the customer and to help the customer fill in the fields that are displayed in the transaction interface. Thus, when operating in one of these modes, thetransaction module210 may modify the transaction interface to display a larger number of input fields on fewer screens (e.g., a “power user” mode), to display fewer educational screens that provide textual explanations of different portion of the transaction, and to display fewer follow-up steps to the customer (e.g., because the vehicle dealer can simply provide verbal instructions to perform these follow-up steps).
Apart from the modifications noted above, thetransaction module210 may make additional modifications to the transaction interface when operating in the remote-assisted mode. For example, thetransaction module210 may omit follow-up instructions that can be performed via remote communication with a vehicle dealer, such as scheduling an in-person appointment at the vehicle dealership, but display follow-up steps that involve physical interaction with the dealer, such as bringing hard copy documents to the vehicle dealership.
In the unassisted mode, it is assumed that the customer is not in communication with the dealer and is not inside the dealership. As a result, thetransaction module210 modifies the transaction interface to make the interface more user-friendly when operating in the unassisted mode. For instance, thetransaction module210 modifies the interface to include fewer input fields in each screen to avoid overwhelming the customer, more explanatory text and graphics, and more follow-up steps. Furthermore, thetransaction module210 omits the dealer-use-only fields described above; instead, the trade-in value, selling price, and rebate amounts are collected in the manner described above with reference to theinformation collection module215 and theprocess300 ofFIG. 3A.
Thisprocess400 of selecting an operating mode may be performed multiple times throughout a vehicle transfer transaction and may lead to a change in operating mode while a transaction is in progress. In one embodiment, thevehicle transfer system110 provides a customer with the ability to save his or her progress when making a transaction so the customer can return later to complete the transaction. For example, thevehicle transfer system110 may store data related to the transaction as part of a user account associated with the customer. In this embodiment, theprocess400 for selecting an operating mode is performed each time the customer returns to the transaction by resuming interaction with thevehicle transfer system110.
For example, the customer may begin the vehicle transaction during an in-person visit to a vehicle dealership. Upon starting the vehicle transaction during the in-person visit, thevehicle transfer system110 performs theprocess400 and selects410 the assisted mode. As a result, the vehicle dealer can the dealer-use-only fields that are provided in the assisted mode to input custom values for rebates, selling price, and trade-in value. The customer may then save the transaction on thevehicle transfer system110 and resume the transaction from his or her home computer several days later. For example, thevehicle transfer system110 may provide the customer with an interface that includes a link to resume the transaction along with a timer representing the length of time the transaction data will be stored on thesystem110. An example of this interface is shown inFIG. 4B. Although the example shown inFIG. 4B states that the transaction data will be stored on thesystem110 for a 10-day time window, in other embodiments thesystem110 may store the transaction data for a shorter length of time (e.g., 5 days, 1 day, 6 hours, 1 hour) to provide additional incentive for the customer to resume and complete the transaction. Upon resuming the transaction, thevehicle transfer system110 performs theprocess400 again and selects410 the unassisted mode, and the customer completes the transaction in the unassisted mode.
The ability to switch between different operating modes during the course of a single vehicle transfer transaction is advantageous because it allows portions of the transaction to be performed with the benefit of having a vehicle dealer present (e.g., the customer can negotiate for higher rebate amounts or a lower selling price, and the vehicle dealer can inspect the customer's trade-in vehicle to arrive at a more accurate trade-in value), and it also allows the customer to complete other portions of the transaction alone (e.g., finalizing and formally agreeing to the transaction), without the social pressure of being in the physical presence of a vehicle dealer.
Loan Selection InterfaceFIG. 5A is a flow chart illustrating aprocess500 for providing a loan selection interface that presents loan offers from a plurality of different lenders, according to one embodiment. In other embodiments, theprocess500 may include additional, fewer, or different steps, and the steps shown inFIG. 5A may be performed in a different order. Theprocess500 is described below as being performed by theloan selection module220. However, in other embodiments, theprocess500 may be performed by a different component of thevehicle transfer system110 or by a different device in the system environment.FIGS. 5B-5E illustrate example data structures for providing the loan selection interface, andFIGS. 5F-5H are example screenshots of the loan selection interface, according to various embodiments. For ease of discussion, theprocess500 shown inFIG. 3A will be described in conjunction with the example data structures shown inFIGS. 5B-5E and the example screenshots shown inFIGS. 5F-5H.
Theloan selection module220requests505 loan offers from a plurality oflender systems140. In one embodiment, theloan selection module220 generates the request by combining information about the customer, about the vehicle to be transferred, and other information about the transaction. For example, theloan selection module220 receives information about the vehicle and information about applicable rebates that was collected by performing a web scraping process on the vehicle dealer's website. Similarly, theloan collection module220 receives information about the customer that the customer provided as input to the transaction interface. Theloan collection module220 may additionally receive a measure of the customer's creditworthiness from a third-party server150 operated by a credit reporting agency or a self-reported credit range provided by the customer (e.g., as input to the transaction interface). After generating the request, theloan selection module220 sends the request to the plurality oflender systems140. Thelender systems140 are configured to send a loan offer array to thevehicle transfer system110 in response to receiving the request for loan offers.
Theloan selection module220 receives510 a loan offer array from each of thelender systems140. As referred to herein, a loan offer array is a data structure that stores a plurality of offers. Each loan offer in the loan offer array includes a loan rate and one or more loan parameters, such as the loan term and down payment amount. Examples of loan offer arrays received from three different lenders are shown inFIGS. 5B-5D. In these examples, each loan offer array is a two-dimensional matrix where each cell stores the loan rate, a first index for each cell represents the loan term, and a second index for each cell represents the down payment percentage. In other embodiments, the loan offer array may have a different structure.
In some embodiments, theloan selection module220 generates an aggregated loan offer array that combines the one or more of the loan offer arrays into a single array. In one embodiment, each cell of the aggregated loan offer array stores the loan offer having the lowest loan rate for the corresponding set of loan parameters. For example, in the aggregated loan offer array shown inFIG. 5E, each cell stores the lowest loan rate and corresponding lender for the loan term and down payment percentage represented by the indices for the cell. In another embodiment, each cell in the aggregated loan offer array stores a plurality of loan offers that each have the corresponding set of loan parameters. This is advantageous, for example, because theloan selection module220 can later access a single array (rather than each individual loan offer array) to identify every loan offer having a particular set of loan parameters.
Theloan selection module220 provides515 a loan selection interface for display to the customer on the customer device130. The loan selection interface includes one or more interface elements that allow the customer to select one or more desired loan parameters. Screenshots of an example loan selection interface are shown inFIGS. 5F and 5G. This example loan selection interface includes two sliders that allow the customer to select two desired loan parameters: a desired loan term (in months) and a desired down payment amount (in dollars). In the first screenshot shown inFIG. 5F, the sliders are set to default values that specify a loan term of36 months and a down payment of $0, and the interface also displays the loan offers matching these default values. In the second screenshot shown inFIG. 5G, the customer has adjusted the sliders to select a loan term of 48 months and a down payment of $2,600.
Theloan selection module220 receives520 a set of desired loan parameters from the customer device130 based on the customer's selections in the interface elements in the loan selection interface. For example, after the customer adjusts the sliders as shown inFIG. 5G, theloan selection module220 receives520 a set of desired loan parameters specifying a loan term of48 months and a down payment of $2,600.
After receiving520 a set of desired loan parameters, theloan selection module220 provides525 one or more loan offers that match the desired loan parameters for display to the customer as part of the loan selection interface. In an embodiment where theloan selection module220 generated an aggregated loan offer array, theloan selection module220 accesses the aggregated loan offer array at the indices corresponding to the desired loan parameters to identify one or more loan offers having the desired loan parameters and provides525 the identified loan offers for display.
After the loan offers are displayed to the customer, the customer may adjust the interface elements to select different desired loan parameters. In this case, theloan selection module220 receives520 a second set of desired loan parameters (e.g., containing at least one parameter with a different value than in the previous set of desired loan parameters) and provides525 one or more different loan offers that match the second set of desired loan parameters.
The customer may alternatively select one of the displayed loan offers, in which case theloan selection module220 receives530 the customer's selection of the loan offer. In one embodiment, each loan offer is displayed with a “view offer” button, as shown in the examples illustrated inFIGS. 5F and 5G, and the customer selects a loan offer by selecting the “view offer” option for the loan offer to display a loan summary screen (e.g., as shown inFIG. 5H), and then selecting an “accept offer” option on the loan summary screen.
Lease Calculation InterfaceFIG. 6A is a flow chart illustrating aprocess600 for performing a lease calculation and presenting the results in a lease calculation interface, according to one embodiment. In other embodiments, theprocess600 may include additional, fewer, or different steps, and the steps shown inFIG. 6A may be performed in a different order. Theprocess600 is described below as being performed by thelease calculation module225. However, in other embodiments, theprocess600 may be performed by a different component of thevehicle transfer system110 or by a different device in the system environment.FIGS. 6B-6D are example screenshots of the lease calculation interface, according to one embodiment. For ease of discussion, theprocess600 shown inFIG. 6A will be described in conjunction with the example screenshots shown inFIGS. 6B-6D.
Although not shown as part of the process,600, thelease calculation module225 may determine a gross capitalized cost for the vehicle based on information collected by theinformation collection module210. In one embodiment, theinformation collection module215 provides the vehicle's MSRP, the dealer's discount (e.g., the difference between the vehicle's MSRP and the dealer's asking price), and fees to be paid upon the transfer of the vehicle to thelease calculation module225, and thelease calculation module225 determines the gross capitalized cost for the vehicle by calculating a sum of these values. As noted above, theinformation collection module215 can collect these values from a variety of different sources and with a variety of different techniques, such as API calls, a web scraping process, and user input.
Thelease calculation module225 provides605 a lease calculation interface to be displayed to the customer on the customer device130. Similar to the loan selection interface, the lease calculation interface includes one or more interface elements that allow the customer to select one or more lease parameters. Screenshots of an example lease selection interface are shown inFIGS. 6B and 6C. This example lease selection interface includes three sliders that allow the customer to select values for three lease parameters: the amount of a cash down payment, a lease term (in months), and the number of miles that the vehicle may be driven during each year of the lease term. In the first screenshot shown inFIG. 6B, the customer has used the sliders to select a cash down payment of $2000, a lease term of 36 months, and an annual mileage allowance of 12,000 miles.
Thelease calculation module225 receives610 a set of lease parameters from the customer device130 based on the customer's selections in the interface elements in lease calculation interface. For example, after the customer adjusts the sliders as shown inFIG. 6B, thelease calculation module225 receives610 a set of lease parameters specifying a down payment of $2000, a lease term of 36 months, and an annual mileage allowance of 12,000 miles.
Thelease calculation module225 performs calculations to divide615 the available upfront capital for the vehicle transfer transaction into two portions. As referred to herein, the available upfront capital refers to the sum of the credits that can be applied toward the transaction at the time the transaction is formally agreed to (e.g., at the time the customer signs the lease). The available upfront capital may include, for example, a cash down payment, the value of a trade-in vehicle, or one or more rebates available for the vehicle.
The first portion of the available upfront capital is allocated to capitalized cost reduction. In other words, the first portion is used to reduce the net capitalized cost of the vehicle (i.e., the gross capitalized cost minus the capitalized cost reduction), which in turn reduces the monthly lease payments.
The second portion of the available upfront capital is allocated to upfront expenses. As referred to herein, upfront expenses are expenses to be paid at the beginning of the lease term, or at the time the vehicle transfer transaction is formally agreed to (e.g., at lease signing). These expenses may include, for example, tax paid on the capitalized cost reduction (e.g., the first portion), fees associated with title and registration, and the first monthly payment for the lease.
Thelease calculation module225 divides615 the available upfront capital into the first portion and the second portion in a manner that causes the second portion to be the same as the total of the upfront expenses. In conventional leases, the entirety of the available upfront capital is allocated to capitalized cost reduction, which means that the customer had to pay for upfront expenses in addition to any cash down payment or vehicle trade-in that the customer was already planning to make. By dividing615 the available upfront capital between the capitalized cost reduction and the upfront expenses in this manner, the customer is not required to make any upfront payments apart from the down payment. If the customer is not making a down payment and is not trading in a vehicle, the upfront capital is divided615 so that a portion of the rebates are allocated to the upfront expenses, which means the customer is not required to pay for any upfront expenses out of pocket. In either case, dividing225 the available upfront capital in this manner advantageously allows for a more streamlined and transparent transaction process with fewer unexpected expenses.
In one embodiment, thelease calculation module225 divides615 the available upfront capital using a different set of formulae depending on whether the vehicle transfer transaction takes place in a jurisdiction that imposes monthly sales taxes on lease payments or a jurisdiction that imposes a lump sum sales taxes on the total value of the lease payments. The jurisdiction of the transaction may be determined, for example, based on the customer's biographical information (e.g., the ZIP code in which the customer resides). As noted above, the available upfront capital includes cash (both a cash down payment and/or a cash value for a trade-in vehicle) and rebates. Each set of formulae below includes separate formulae for dividing the cash into two portions and for dividing the rebates into two portions. In particular, xcrepresents the portion of the cash to allocate to capital cost reduction, ycrepresents the portion of the cash to allocate to upfront expenses, xrrepresents the portion of the rebates to allocate to capitalized cost reduction, and yrrepresents the portion of the rebates to allocate to upfront expenses.
In a jurisdiction that imposes monthly sales taxes on lease payments, thelease calculation module225 divides615 the available upfront capital using the following set of formulae:
However, if any of these formulae returns a negative value, then the lease calculation module invalidates the results and instead divides615 the available upfront capital using a secondary set of formulae:
Finally, if one of the secondary formulae returns a negative value, then thelease calculation module225 instead returns the following default solution, which allocates the entirety of the available upfront capital to the upfront expenses:
xr=0
yr=Trebates
xc=0
yc=Tcash
In these formulae, Tcashrepresents the customer's cash down payment, Trebatesrepresents the total value of the rebates available for the transaction, Tproductsrepresents the total value of the product add-ons that the customer has selected for the lease, t represents the term of the lease in months, Rarepresents the APR of the lease (which is received from alender system140 and has a value that depends on the customer's creditworthiness),
Fupfrontrepresents the sum of the fees that the vehicle dealer charges the customer at lease signing, Fcaprepresents the sum of the fees that are rolled into the lease and are not charged at lease signing, Flocalrepresents local fees in the customer's state, Vpricerepresents the MSRP of the vehicle, Vdiscountsrepresents the value of any discounts applied by the vehicle dealer for the vehicle (e.g., the difference between the MSRP and the dealer's selling price), Vresidualrepresents the residual value of the vehicle (which is received from a lender system140 and has a value that depends on the make and model of the vehicle, the lease term, and the annual mileage allowance), TIvrepresents the value of the customer's trade-in vehicle, TIprepresents the remaining loan balance on the customer's trade-in vehicle, ti=max(0, TIv−TIp), tin=max(0, Tlp−Tlv), Rtaxrepresents the sales tax rate in the customer's jurisdiction, Gpretax=Vprice−Vdiscounts+Fcap+tin=Tproducts, Lcashis a binary value indicating whether the customer's jurisdiction collects taxes on a cash down payment for a lease, Lrebatesis a binary value indicating whether the customer's jurisdiction collects taxes on rebates applied toward a lease, and Ltradeinis a binary value indicating whether the customer's jurisdiction collects taxes on a trade-in vehicle whose value is applied toward a lease.
The term “factor” in these formulae represents the following constant:
In a jurisdiction that imposes a lump sum sales tax on the total value of lease payments, thelease calculation module225 divides615 the available upfront capital using the following set of formulae:
Similarly, if any of these formulae returns a negative value, then thelease calculation module225 invalidates the results and instead divides615 the available upfront capital using a secondary set of formulae:
Lastly, if one of the secondary formulae returns a negative value, then thelease calculation module225 instead returns the following default solution, which allocates the entirety of the available upfront capital to the upfront expenses:
xr=0
yr=Trebates
xc=0
yc=Tcash
In these formulae, each variable represents the same value as noted above. The terms “multiple” and “factor” represent the following constants:
Thelease calculation module225 calculates620 a monthly lease payment. In one embodiment, thelease calculation module225 first calculates the depreciation in the vehicle's value over the lease term. For example, the depreciation is the difference between the vehicle's net capitalized cost and the residual value of the vehicle. Thelease calculation module225 also calculates a rent charge based on the APR of the lease. After calculating the depreciation and the rent charge, thelease calculation module225 computes a total lease payment by computing a sum containing the two values, and then themodule225 divides the total lease payment by the number of months in the lease term to calculate620 the monthly lease payment.
Thelease calculation module225 provides625 the monthly lease payment to the customer device130 for display to the customer as part of the lease calculation interface. For example, in the screenshot shown inFIG. 6B, the monthly lease payment is $224. After the monthly lease payment is displayed to the customer, the customer may adjust the interface elements to select different lease parameters. If the customer adjusts one of the interface elements, thelease calculation module220 receives610 a second set of lease parameters (e.g., containing at least one parameter with a different value than in the previous set of lease parameters), performs the dividing615 and calculating620 steps again, and provides625 an updated monthly lease payment for display to the customer. For example, in the second screenshot shown inFIG. 6C, the customer has adjusted the mileage allowance slider from 12,000 miles to 15,000 miles, which yields an updated monthly lease payment of $242.
The customer may alternatively select the lease, in which case thelease calculation module225 receives630 a selection of the lease. In one embodiment, the monthly lease payment displayed with a “details” option, as shown in the examples illustrated inFIGS. 6B and 6C, and the customer selects the lease by selecting the “details” option to display a lease detail screen (e.g., as shown inFIG. 6D), and then selecting a “select this lease” option on the lease detail screen.
In an alternative embodiment, thelease calculation module220 performs the dividing615 and calculating620 steps ahead of time (e.g., after receiving the necessary information and before receiving610 any desired lease parameters) for each possible combination of lease parameters (or a subset of the possible combinations of lease parameters) and stores the results in a lease calculation array that is indexed according to the lease parameters. In this embodiment, rather than performing the dividing615 and calculating620 steps again responsive to receiving a second set of lease parameters, thelease calculation module220 accesses the result for the second set of parameters in the lease calculation array and provides625 the results (including the monthly lease payment) for display to the customer. Performing the dividing615 and calculating620 steps ahead of time in this manner may advantageously make the lease calculation interface faster and more responsive because theleast calculation module220 is accessing an array (rather than performing the more computationallyintensive dividing615 and calculating620 steps) when the customer adjusts one of the interface elements.
Example Machine ArchitectureFIG. 7 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in one or more processors (or controllers), according to one embodiment.
InFIG. 7 there is a diagrammatic representation of a machine in the example form of acomputer system700. Thecomputer system700 can be used to execute instructions724 (e.g., program code or software) for causing the machine to perform any one or more of the methodologies (or processes) described herein. In alternative embodiments, the machine operates as a standalone device or a connected (e.g., networked) device that connects to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
The machine in this example can be any of the devices orsystems110 through150 shown in the system environment, such as thevehicle transfer system110, thevehicle dealer system120, the customer device130, thelender system140, or the third-party system150. However, the architecture described may be applicable to other computer systems that operate in thesystem environment100. These other example computer systems include a server computer, a client computer, a personal computer (PC), a tablet PC, a smartphone, an internet of things (IoT) appliance, a network router, switch or bridge, or any machine capable of executing instructions724 (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly executeinstructions724 to perform any one or more of the methodologies discussed herein.
Theexample computer system700 includes one or more processing units (generally processor702). Theprocessor702 is, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these. Thecomputer system700 also includes amain memory704. The computer system may include astorage unit716. Theprocessor702,memory704 and thestorage unit716 communicate via abus708.
In addition, thecomputer system700 can include astatic memory706, a screen driver710 (e.g., to drive a screen, such as a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). Thecomputer system700 may also include input/output devices, e.g., an alphanumeric input device712 (e.g., a keyboard), a dimensional (e.g., 2-D or 3-D) control device714 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a signal generation device718 (e.g., a speaker), and anetwork interface device720, which also are configured to communicate via thebus708.
Thestorage unit716 includes a machine-readable medium722. The machinereadable medium722 may be flash, a magnetic disk, and/or optical storage. The machine readable medium722 stores instructions724 (e.g., software) embodying any one or more of the methodologies or functions described herein. Theinstructions724 may also reside, completely or at least partially, within themain memory704 or within the processor702 (e.g., within a processor's cache memory) during execution thereof by thecomputer system700, themain memory704 and theprocessor702 also constituting machine-readable media. Theinstructions724 may be transmitted or received over anetwork726 via thenetwork interface device720.
While machine-readable medium722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store theinstructions724. The term “machine-readable medium” shall also be taken to include any medium that is capable of storinginstructions724 for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.
Additional Configuration ConsiderationsThe disclosed configurations offer several benefits and advantages over conventional methods of performing a vehicle transfer transaction. In particular, a process for applying for a loan via a conventional online system requires the customer to provide his or her biographical information and select a single set of loan parameters when submitting an online loan application, and the customer receives a single loan offer in response to the loan application. Furthermore, it takes between several minutes and several days for a lender to provide the loan offer in response to the loan application. If the customer is dissatisfied with the loan offer, the customer typically has to submit another online loan application, either to the same lender or to a different lender, and wait to receive another loan offer. As a result, a customer may need to submit several online loan applications in order to receive a satisfactory loan offer, which can be a long, drawn-out, and inconvenient process for the customer.
In contrast, the loan selection process disclosed herein provides a structured user interface that prompts the customer to provide his or her biographical information a single time, uses the information to request a plurality of loan offers from several different lenders, and then provides the customer with a loan selection interface that allows the customer to browse through the loan offers. This provides a much faster and more streamlined process that allows the customer to select a loan offer that is satisfactory to the customer without having to submit and wait for multiple online loan applications. Thus, it takes significantly less time for the customer to select a satisfactory loan offer, which reduces the overall length of time taken to complete the transaction.
Similarly, lease information provided by conventional online calculation tools simply provide estimates of the upfront payment and monthly payments for a lease. Conventional tools are only able to provide estimates, rather than perform a more accurate calculation, because they do not have access to sufficient information (e.g., applicable rebates, the customer's creditworthiness, information about taxes and fees, etc.). As a result, the estimates produced by conventional lease calculation tools may differ from the actual upfront and monthly payments that a customer commits to, which may cause the customer to place less trust in the estimate and hesitate before proceeding with the transaction.
In contrast, the leasing calculation process described herein is part of a broader process for performing an entire vehicle transfer transaction, which means thevehicle transfer system110 has access to enough information to perform a more accurate calculation (and, in some embodiments, an exact calculation down to the penny) to determine the amount of each monthly payment. In addition, the leasing calculation process described herein is a specific process for calculating a lease that divides the available upfront capital between capitalized cost reduction and upfront expenses, whereas a conventional leasing calculation simply allocates the entirety of the available upfront capital to the capitalized cost reduction. As noted above, dividing the available upfront capital in this manner is advantageous because it allocates a portion of the available upfront capital to the upfront expenses, which means the customer does not have to make any additional out-of-pocket payments at lease signing. Finally, the result of the leasing calculation is provided for display to the customer in a lease calculation interface that allows the customer to view immediate and accurate data about the lease before committing to it, which means the customer may place more trust in the calculation and lead to a faster completion of the vehicle transfer transaction on the vehicle dealer's website.
More broadly, the vehicle transaction process described herein provides several features that allow for a vehicle transfer transaction to be completed more quickly and efficiently. First, thevehicle transfer system110 collects information from multiple sources and via multiple methods, such as API calls, web scraping processes, direct file transfers, and user inputs, and is capable automatically combining the information to rapidly provide accurate data for the various financing options that the customer may choose from. Second, both the loan selection interface and the lease calculation interface are capable of rapidly displaying updated financing data (e.g., by accessing data in an array or recalculating certain values) in response to the customer making a change to one or more financing parameters. Third, even though the dealer system (which provides the dealer website) is separate from the vehicle transfer system (which provides the vehicle transfer interface and facilitates the transaction), the vehicle transfer interface is displayed as part of the dealer website so the customer can perform the entire vehicle transfer transaction without leaving the dealer's website. Because vehicle transfer transactions can be subject to a quick time window in which to enter into, negotiate, and close the transaction, these features (and other features) of the disclosed embodiments advantageously allow a dealer to carry out an online vehicle transfer transaction more rapidly, which advantageously increases the likelihood of retaining customers who begin the vehicle transfer transaction on the vehicle transfer interface provided on the dealer's website.
Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms, for example, as illustrated inFIG. 2. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
The various operations of example methods described herein may be performed, at least partially, by one or more processors, e.g.,processor702, that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.
As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for automatically detecting and executing a return path for a vehicle through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.