MX2007004842A - Systems and method for managing dealer information . - Google Patents

Abstract

Embodiments of systems and methods are disclosed that manage transactions and communication between car dealers and lenders. In one embodiment, the system lessens risks for lenders and makes relationships with dealers safer and easier to administer. In one embodiment, a dealer may utilize the system to manage its inventory, obtain and manage credit history information about potential customers, help customers apply for credit, transact credit applications and credit approvals with various lenders, submit applications to multiple lenders, select from among the accepting lenders, and manage forms used to complete a transaction.

Description

SYSTEMS AND METHODS FOR HANDLING TRADER INFORMATION FIELD OF THE INVENTION The present invention is concerned with the field of computer management systems in general and in particular with a computer system to handle the consummation aspects of vehicle sales.

BACKGROUND OF THE INVENTION The purchase of a large ticket item, as a vehicle, can be a complex and time-consuming process involving numerous entities. A typical vehicle purchase process may include finding a vendor from which to buy a vehicle and finding an appropriate vehicle. A vehicle buyer may wish to finance the purchase of the vehicle using a loan product from a bank or other money lender. In order to consummate a deal, the buyer, money lender and vehicle seller commonly enter into an agreement with purchase and financing terms. The terms of purchase and financing may depend on the vehicle that the buyer wants to buy. In addition, a credit bureau may be involved in providing credit information for a lender to evaluate a potential buyer or loan applicant. Data, such as scores and credit histories, must be gathered and numerous forms commonly exchange hands, such as requests for loan, sales receipts, loan contracts, title transfers, registrations and many other possibilities. The time delay in filling and submitting these forms can often create a frustrating experience for the buyer. Sellers are often forced to learn numerous systems and forms with the limes interacting with the different entities involved. The purchase of a used vehicle, particularly from an independent vendor, can present special difficulties. Lenders are often not interested in approving loans and dealing with independent used vehicle sellers due to a number of factors. In some cases, buyers may be more of a credit risk. In others, the used vehicle may be less attractive collateral to another type of new or used vehicle. In still others, a lender may be cautious of the seller of the used vehicle due to the smaller size of the seller, low volume of transaction or even the possibility of f aude. However, lenders have an incentive to interact in transactions with used vehicle sellers, because each loan that a lender is able to successfully fund and collect generally increases the lender's earnings. Sellers of used vehicles must overcome many of these risk factors, whether real or imagined, in order to maintain and grow a business. successful BRIEF DESCRIPTION OF THE INVENTION Thus, in one embodiment, it would be advantageous to provide a system that handles all transactions and communications between the various parties involved. In addition, in one modality, a system that decreases the risks for the lenders and makes used car dealers safer and easier to deal with is desirable. It is an object of one modality to provide a robust sales management system and methods that modernize the seller's credit, loan and inventory systems by providing an interface through which an entire credit-based purchase transaction can be concluded. Through the system and methods a salesperson can manage their inventory, obtain and manage credit history information about potential buyers, assist buyers, apply for credit, process credit applications and credit approvals with various lenders, and manage used forms to complete a transaction. A seller can simultaneously submit credit applications in the name of a potential buyer to multiple lenders and can choose from among the lenders that accept. It is an additional object of a modality to provide incentives for lenders to participate in this system by reducing the risks involved in transactions based on used cars or other credit-based transactions. In one modality, the systems and methods filter credit requests based on the lender's criteria and only send requests to lenders who meet the criteria. This reduces the hassles in examining and rejecting requests that the lender is rarely or never comfortable to grant. In addition, in one modality, lenders can also filter credit applications based on collateral. In the case of used vehicles, this would include the vehicle itself. The lender can specify certain vehicle models, brand, years, colors and the like. In another form, the sales management system and methods can verify the final terms of the seller against the loan offer requirements approved by a lender who has accepted an application. This can help the seller and lender do not have to bargain or dispute about the final terms. In another modality, an audit trail of the applications entered and the data changed in the application is maintained. It is an additional object of a modality to provide a primary source for forms required to consummate a transaction. In one modality, the required forms are propagated based on customer data, application data, inventory data and the like. These forms are then printable by the seller. In one mode, the sales management system is able to seamlessly update any forms changed by lenders, government entities and the like, so that a seller prints out updated forms that include the current data for any given transaction. It is another object of a modality to facilitate and / or incorporate the use of an agreement account process to complete the purchase of used cars. In one mode, the lender presents the funds it has agreed to disburse to an agreement account and the seller presents the title and registration documents to an entity or module of the agreement account. After the agreement entity or module takes care of any outstanding obligations and completes the presentation of the title and registration documents to the correct government office, then it will release the funds. This provides significant protection for the cautious sellers of used car dealers. In one embodiment, one is provided to help a seller sell a vehicle to a customer. The system includes an input module that allows the entry of data concerning the customer and data concerning the proposed purchase of a vehicle by the customer of the seller, a filter module corresponds or match at least some of the customer's data or the data concerning the proposed purchase with the criteria of the lender, where the criteria of the lender are selected to identify lenders who are willing to consider providing a loan for the purchase of the vehicle. A lender selection module is configured to select a subset of the corresponding lenders to increase the likelihood that at least one of the corresponding lenders will approve the loan. A transmission module is configured to allow customer data to the subset of lenders. In a further embodiment, a system is provided to assist a seller in selling a vehicle to a customer. The system includes an input module that allows the entry of data concerning the customer and data concerning a proposed purchase of a vehicle by the seller's customer, a lender management module matches or corresponds by at least some of the data of the client or the data concerning the proposed purchase with the criteria of the lender, where the criteria of the lender are selected to identify lenders who are willing to consider providing a loan for the purchase of the vehicle. A transmission module is configured to transmit the customer data to at least some of the corresponding or matching lenders. A document receivable module is configured to provide one or ^ more tools to help the seller to service a loan provided by the seller. In a further modality, a used vehicle financing system is provided. The used vehicle financing system includes a loan request module configured to accept customer data and vehicle data where the vehicle data includes data specific to used vehicles, a lender filter module is configured to match criteria of the vehicle. lender with the information collected by the loan application module to determine which lenders are willing to finance a given buyer and vehicle combination, where the lender's criteria includes factors that are specific to used vehicles. One mode provides a method to facilitate the sale of a vehicle from a seller to a buyer. The method includes placing funds from a designated lender for sale to an account that can not be accessed by the seller. The electronic title to the vehicle that is sold is received from the seller. The electronic title is retained in such a way that the lender does not have access to the electronic title. The funds are released to the seller and the title to the lender after confirmation that the lender has approved the electronic title and a lien on the vehicle. One modality provides a management system for sale of computer base vehicles. The vehicle sales management system includes a server module configured to communicate with a remote computer system. A vendor management module is in communication with the server module. The seller's management module includes an inventory module to maintain information about a vehicle inventory of a vendor. A management module of the lender is in communication with the seller's management module. The lender's management module is configured to receive loan request data from the vendor's management module, receive loan request decision information from at least one lender, and provide the loan request decision information to the loan module. seller's handling An additional modality provides a system for marketing a used product. The system includes an inventory module that maintains information about the product used, where information about the product used includes an image of the product used. An interface module receives a program or schedule to obtain complementary advertising placements of a user of the system. A retail listing module is configured to place advertisements for the used product with at least one retail listing service according to the program while the used product remains unsold.

For purposes of summarizing the invention, certain aspects, advantages and new elements have been described herein. Of course, it will be understood that not necessarily all of such aspects, advantages or elements will be implemented in any particular mode. In addition, it will be understood that not necessarily all of such advantages or benefits can be obtained in accordance with any particular embodiment of the invention. Thus, for example, those skilled in the art will recognize that the invention can be implemented or effected in a way that obtains an advantage or group of advantages as taught herein without necessarily obtaining other advantages or benefits as can be taught or suggested in the present.

BRIEF DESCRIPTION OF THE FIGURES A general architecture that implements the various elements of the invention will now be described with reference to the figures. The figures and associated descriptions are provided to illustrate embodiments of the invention and not to limit the scope of the invention. In the figures, reference numbers are reused to indicate correspondence between elements to which reference is made. Figure 1 is a high-level block diagram of a modality of a sales management system that includes a management server in communication with a system of seller, a lender system and other systems. Figure 2 illustrates one mode of a registration page of the total sales management system. Figure 3? illustrates a modality of a total sales management home page. Figure 3B illustrates an alternative mode of a total sales management home page that incorporates direct loan information from the seller. Figure 4 illustrates a modality of a page listing loan applications. Figure 5A illustrates a modality of a new request page. Figure 5B illustrates one modality of a new deal page. Figure 6 illustrates a modality of a loan application loan page. Figure 7 illustrates a modality of a loan application employment information page. Figure 8 illustrates a modality of a loan application trade page. Figure 9 illustrates a modality of a loan request desk page. Figures 10A and 10B illustrate one-page mode of the loan application lender. Figure 11 illustrates one page mode of loan application funds. Figure 12 illustrates a form of a loan request form page. Figure 13 illustrates a modality of a loan silicate note page. Figure 14 illustrates a mode of an inventory list page. Figure 15 illustrates a one-page mode of adding inventory. Figure 16 illustrates a modality of a report page. Figure 17 illustrates one mode of a calculator page. Figure 18 illustrates a modality of a calendar page. Fig. 19 is a high-level block diagram of a mode of a management server. Figure 20 is a flow diagram of a method mode for processing a loan application. Figure 21 is a flow diagram of a method modality for a vendor to use an agreement service for a loan application. Fig. 22 is a flowchart of a method mode for a lender utilizing a service agreement for a loan application. Figure 23 is a block diagram of a mode of a management server in communication with a vendor system, lender systems, and other systems. Figure 24 is a block diagram of a mode of a management server that includes modules of programming elements to implement at least some elements of a sales management system. Figure 25 illustrates a modality of a page of documents receivable.

DETAILED DESCRIPTION OF PREFERRED MODALITIES Systems and methods representing various exemplary embodiments and applications of the present disclosure will now be described with reference to the figures. For purposes of illustration, some modalities will be described in the context of car sales. The present invention is not limited by the type of environment in which the systems and methods are used. Systems and methods can be used in other environments, such as, for example, new car sales, mortgage transactions, merchandise sales, other sales and so on. The figures and descriptions, however, are concerned with modalities in a sales environment of automobiles The system may include a variety of uses, including, but not limited to, vendors, lenders and their equipment and personnel. It is also recognized that in other modalities, systems and methods can be implemented as a single module and / or implemented in conjunction with a variety of other modules and the like. In addition, the specific implementations described herein are summarized in order to illustrate, and not limit, the invention. The scope of the invention is defined by the appended claims.

I. Overview The sales management system as contemplated by one embodiment of the disclosure herein generally comprises a management server connected to one or more vendor systems and one or more lender systems by means of a network or networks of communications. The communications network may include one or more of a local area network ("LAN"), a wide area network ("WAN"), an intranet, a wired network, a wireless network, the Internet or the like. In one embodiment, the management server comprises a web service connected to the World Wide Web. The vendors, call centers and lenders are then able to connect to the management server by means of their respective systems comprising any network enabled and connected device, such as for example a personal computer ("PC"). Some embodiments of the present invention may be particularly appropriate for applications of used car dealers. In other embodiments, instead of and / or in addition to a web-based system, some or all of the system may be implemented using one or more autonomous executable programs within an environment such as a computer operating system. An example that considers the use of a system with a hypothetical buyer, Paula and seller Dan, can be illustrative. Paula arrives at the sale of Dan one day and decides to buy a BMW 2001, having heard that the German car was well built and maintains its value for a long time than most cars. Dan is eager to sell the car, but Paula does not have enough cash on hand to buy the car directly. I could leave the lot and get financing from a bank and later return to buy the car, but that would take a long time and it would be quite annoying. Dan could also ask questions with several lenders with whom he has dealings, but this may also take time and require duplication of effort that you need to verify with more than one lender. However, Dan can modernize the entire purchase by using a modality of a sales management system. The sales management system tracks Dan's customers and their car inventory and maintains their connections with a number of lenders. To consummate this transaction, Dan sits on his web-enabled PC, opens an Internet browser program, such as, for example, internet explorer and registers with the management server, hosted on an accessible web server in a network such as the World Wide Web. Here, Dan can enter information about Paula, such as her name, social security number, and address. Using this information, the system can retrieve a credit history and credit score report. Dan can then link the selected BMW of his inventory to Paula's request. Then the management server uses that accumulated data to determine to determine lenders who can accept Paula's credit application. Dan then selects five of the lenders. The system sends Paula's request to those lenders and the lenders are able to review their information, and approve or deny the request. The system transmits these answers to Dan who can then choose, from the approved applications, the best lender offer. After choosing a lender, Paula and Dan finalize the terms of the deal and the system transmits those details to the lender. The system also propagates the purchase agreement, forms of credit, title and registration and any other forms necessary to consummate the transaction. Dan is able to print these for Paula to sign. The title and registration can then be placed in agreement while the lender presents the funds to the agreement as well. Once the title and registration are properly updated and filled in with the state department dealing with motor vehicles ("DMV"), the agreement entity releases the funds to Dan, and Paula is able to manage her BMW. Because the system is fully integrated, Dan's inventory will now show that the BMW was sold and can retrieve information regarding the lender's response. Figure 1 illustrates one embodiment of a sales management system in which a management server 102 communicates with one or more vendor systems 106 and one or more lender systems 108 via a communication network or networks 104. In one preferred embodiment of the sales management system, vendor systems 106, lender systems 108, and / or management server 102 may also be in communication with a convention entity 110. This may be through a communications network similar or different such as the one marked with 104 in figure 1. In this case, forms propagated by the system that may include electronic signatures of the parties involved can be transferred to an agreement entity 110. Such modality would reduce or eliminate the need for appropriate documents and reduce the transmission time. Although not shown in Figure 1, in one embodiment, the management server 102 may interact directly with the agreement entity or module. 110 and / or the convention module or entity 110 may be part of the management server 102. In addition, Figure 1 illustrates a mode wherein the management server 102 is in communication with third party systems 111 via the communication network 104. The third-party system 111 may include, for example, total sales value guide systems (eg, Kelley Blue Book and so on), detailed financial floor plan systems, sales systems (eg, bahia- e, public auction websites and so on), payroll systems (for example, EDT and so on), insurance systems (for example, State Farm, ??? and so on), financial systems (eg. web of loan rates, bank sites and so on), credit reporting systems, vehicle information systems (eg, VIN decoder systems, CARFAX and so on), vendor system (eg, other used car dealers and so on), guarantee systems, and government systems (for example, motor vehicle department systems, state tax systems, local tax systems and so on). This communication network 104 may be considered a similar or different communications network as that used by the vendor system 106 and / or the lender system 108. In one embodiment, the information is received directly from the third-party systems 111 and / or via a partner that collects such information. In addition, in one embodiment, the third party information is stored as electronic documents in the management server 102 and one or more of the documents can be made available to the vendors and / or the lenders. This allows for example that the lender sees the set of documents that will be received at the end of the treatment project, improves the response time of the lender by ensuring that the necessary documents are complete, thus improving the loan process and the probability of that the loan treaty will advance.

II. Sales Management System As mentioned above, Figure 1 illustrates a modality of a sales management system in which a management server 102 communicates with a vendor system 106, a lender system 108, and third party systems. part 111 via communication networks 104.

A. Management server 102 Figure 19 illustrates a mode of a management server 102, comprising a processing module 212, a lender database 214, a vendor database 216, and a customer database 218, which stores data from the lender 220, data from the vendor 222, and data from the client 224 respectively. These databases can be included in a single physical database or numerous databases in various modalities. The processing module 212 communicates with the communication network 104 by means of a network interface module (not shown) such as, for example, an Ethernet card, modem, cable modem or the like. 1. Processing Module 212 Processing Module 212 communicates with vendor systems 106 and lender systems 108 in communication network (s) 104. In one embodiment, this communication is effected by means of web-based communications. secure, such as HTTPS, the use of a secure enclosure layer encrypted with the hypertext transfer protocol. In one embodiment, the processing module 212 acts as a web server, accepting data requests from browsers located in the vendor and lender systems 106, 108 and responding with appropriate web pages. The processing module 212 also communicates with databases 214, 216, 218 for storing data from the lender 214, vendor data 216, and customer data 218 sent from the vendor and lender's systems, as well as for retrieving requested data for display or edit in vendor and lender systems 106, 108. 2. Databases As stated, in one embodiment, the management server 102 includes a lender database 214, a vendor database 216 and a customer database 218. The lender database 214 is used. to store data from the lender 214. This data from the lender may include, for example, the name of the lender, ID, contact information, minimum acceptable credit / collateral criteria, approved vendors, individualized request or loan forms, and various other types of data associated with given lenders. The data of the lender can also include rules of the lender that indicate the criteria of the lender. The criteria may include, for example, a minimum credit score, a maximum credit score, a minimum loan amount, a maximum loan amount, a minimum percentage of the total sale price, a maximum percentage of the total sale price and so on In addition, the criteria may include information about the cars for which they are willing to grant approval, such as, for example, the year, make, model, mileage, accident history, number of previous owners, age of the vehicle and so on. In addition, the criteria may include a range or set of acceptable values and / or unacceptable values. As an example, lender A can request that loans of more than $ 5000, the buyer must have a credit score greater than 540, but not lower than 700; for loans less than or equal to $ 5000, the buyer must have a credit score greater than 440, but lower than 650 and so on. As another example, lender A may wish to exclude loans for older Ford escorts of 2000 or any Honda with mileage greater than 100,000 miles. As an additional example, lender A may wish to exclude loans for 1986 Toyota Corollas with mileage greater than 150,000 miles for any buyer who lives more than 30 miles from a major city. Those of skill in the art will appreciate the wide range of possible lender criteria that can be used. In addition, the lender's database 214 may also include "seller agreements" that are provided by the lenders and filled out by the sellers to establish a relationship between the lender and the seller. Sellers can see the various lenders available, decide to sign with a lender and sign electronically to start a relationship with that lender. The vendor database 216 is used to store vendor data 222, such as, for example, vendor name or ID, inventory data for the vendor, inventory data for other vendors, customer data (or links related to a client database 218), Preferred lenders, account data, transaction histories, configuration data, collection data, treaty data, vendor data and other information associated with a vendor. Finally, the customer data 224 is stored in a customer database 218. The customer data 224 may include, for example, the buyer's name, ID, contact information, credit history, credit score, automobile or desired cars and other information that may be associated with a buyer, such as the seller's notes. It is recognized that the management server 102 may include other types of information as well, such as inventory data, automobile price data, general credit, loan and registration or title forms, forms of lender and so forth. In addition, in other embodiments, the lender database 214, the vendor database 216 and / or the customer database 218 may be implemented as one or more databases, such as one or more flat files or as individual data items stored in an addressable memory space, non-volatile random access memory, flash memory or mass storage, such as is found on a hard disk drive. It is recognized that the database of the lender 214, the database of the vendor 216 and / or the database of the client 218 can be implemented using a relational database, such as CodeBase, Sybase, Oracle and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, a database of entity relationship and database oriented to the low and / or a database based on registration. For example, the lender database 214, the vendor database 216 and / or the customer database 218 may include a single database with separate tables or as other data structures that are well known in the industry. art such as linked lists and binary trees. In addition, while the lender's database, the vendor's database and / or the client's database are shown as three databases, it will be recognized that in other modalities, the database can be stored as a single database, such as two databases or more than three databases. In other embodiments, the databases may be integrated with the management server 102 or alternatively, directly or indirectly connected to the management server 102. In one embodiment, one or more of the databases may be connected to an end component. Later (not shown) that receives requests for databases via server programs, small programs that run on servers and sends a corresponding request to the network interface module. It is recognized that in other modalities access to data it can be done directly, for example a different type of back end component can be used. 3. Network interface module The management server 102 may also include a network interface module (not shown) that communicates with the management server 102 to facilitate communication with the management server 102 and the vendor system 106 and / or the lender system 108 via the communications network (s) 104. The network interface module may use a variety of network protocols. In one embodiment, the network interface module includes the hypertext transfer protocol (http). However, it will be appreciated that other types of network communication protocols may be used, such as secure HTTP (HTTPS), file transfer protocol (FTP), simple mail transfer protocol (SMTP), and data control protocol. transmission / internet protocol (TCP / IP). 4. Input and output devices The management server 102 can communicate with a set of input and output devices. For example, the input device (s) may include a keyboard, a rolling ball, pen and fountain pen, mouse, ball tracking, voice recognition system or switches or pre-designed buttons. The input device (s) may (also) include a contact screen associated with the output device. Textual or graphic information can be entered by the user through the input device. The output device (s) can include a loudspeaker, a screen, a printer or a speech synthesizer. It will be recognized that in some embodiments, one or more of the input and output devices may be included in the management server 102. For example, the management server 102 may include an integrated set of speakers and an integrated contact keypad.

. Information Management Server 102 The management server 102 may include a single-chip or multi-chip conventional general-purpose chips such as a Pentium® processor, a Pentium® II processor, a Pentium® Pro processor, a xx86 processor, a Centrino® processor, 8051 processor, MIPS® processor, Power PC® processor or ALFA® processor. In addition, the microprocessor may be any conventional special purpose microprocessor such as a digital signal processor. In addition, the management server 102 can each be used in connection with various operating systems such as: Microsoft® Windows® 3.X, Microsoft® Windows 95, Microsoft® Windows 98, Microsoft® Windows® NT, Microsoft® XP, Microsoft® Vista, Microsoft® Windows® CE, Palm Pilot OS, OS / 2, Apple® MacOS®, Disk Operating System (DOS), UNIX, Linux®, VxWorks or IBM® OS / 2®, Sun OS, Solaris OS, IRIX OS operating systems and so on. In one embodiment, the management server 102 is a server, personal computer, portable computer, portable computing device, a computer workstation, a local area network of individual computers, an interactive kiosk, a personal digital assistant, a interactive wireless communications device, a manual computer, an embedded computing device or the like. In some embodiments, the management server 102 includes two or more computer systems, each of which performs at least some of the operations associated with the management server 102. As can be appreciated by that of ordinary skill in the art. , the management server 102 may include several sub-routines, procedures, definitional assertions and macros. Each of the above modules are compiled and commonly linked separately to a single executable program. However, it will be appreciated by one of ordinary skill in the art that the processes that are performed by selected modules can be arbitrarily redistributed. to one of the other modules, combined together in a single module, made available in a dynamic link library shareable or distributed in any other logical way. For example, in one embodiment of the invention, the processing module 212 and the network interface module are integrated into a single executable module. Further, for example, in another embodiment, the processing module 212 is maintained in a dynamic link library that is separate from the network interface module. In addition, the processing module 212, the network interface and / or the databases may be either an "application program", reside as part of the operating system for the device or may reside partially in both. As used herein, the word module refers to logic implemented in physical elements or permanent elements or to an instruction collection of programming elements, possibly having entry and exit points. In addition, the modules can be written in any programming language such as C, C ++, BASIC, Pascal, Java and FORTRAN compiled and linked to an executable program, installed in a dynamic link library or written in an interpreted programming language such as BASIC, Perl or Python. It will be appreciated that modules of programming elements can be called from other modules or from themselves and / or can be invoked in response to events or Interruptions detected. Instructions for programming elements can be embedded in physical elements, such as an EPROM. It will further be appreciated that physical element modules may consist of connected logical units, such as gates and multivibrators and / or may consist of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as modules of programming elements, but can be represented in physical elements or permanent elements. 6. Module handling server 102 Figure 23 is a block diagram of a form of a sales management system that includes a management server 102 in communication with a vendor system 106, a lender system 108 and other systems, such as , for example, via one or more communication networks 104. The management server 102 includes a component 604 of the vendor management system (DMS) and a component 604 of the lender management system (LMS) 606. to. Component 604 of the vendor management system (DMS) In the embodiment shown in figure 23, the DMS component 604 (also referred to as the vendor management module) includes an inventory module 608, a sales module 610, a management module 612, a service module 614, and a document receivables module 630. In one embodiment, the inventory module 608 includes a repository of information about products that are devices for sale. In some embodiments, the inventory module 608 includes a database of information about vehicles in the seller's lot, which include the inventory number, the model year, the make, the model, the exterior color, Vehicle identification number (VIN), location, age of inventory, status, nominal price, inventory cost, mileage, one or more images and / or one or more expenses associated with the vehicle. Other information in the inventory database may include the total sale price, the normal nominal price, the nominal minimum price, nominal terms, the packaging rights, the type of vehicle, the body style, the interior color, the transmission, drive type, engine, fuel, vehicle weight, vehicle condition, type or identifier of the recovery device, license plate number, plate expiration date, inspection expiration data , additional notes, one or more valuations associated with the vehicle and so on. In some embodiments, the inventory module 608 is interconnected with one or more third party systems to obtain or report data. For example, the inventory module 608 may be configured to obtain vehicle valuation information from one or more price book services 616. The inventory module 608 may also be configured to provide inventory information to a sales listing service. at retail 618. Examples of retail sales listing services 618 with which inventory module 608 may be linked include, without limitation, a vendor's website (such as a website hosted by management server 102), the retail sales list service AÜTOTRADER.COM®, and the retail sales list service CARS.COM®. The inventory module 608 may be configured to provide real-time inventory information or regularly updated inventory information to one or more retail sales listing services 618. The inventory module 608 may include an interface to one or more retail services. retail sales list 618 that creates a list of retail sales adapted for a particular service. The inventory module 608 may also be configured to automatically purchase supplementary advertising from a retail sales list service 618 according to a program specified by a vendor. For example, in some embodiments, the inventory module 608 can create an ad adapted for a product in a vendor inventory and place the adapted advertisement in a Listing service such as EBAY® after the product fails to be sold within a specified period of time. After the seller selects an advertising program, the creation, purchase and / or placement of complementary ads can be automatic. In one embodiment, the 610 treatment module includes a deposit of information concerning vehicle purchase agreements negotiated between a vendor and its customers. For example, the 610 treatment module can maintain a list of outstanding and / or completed vehicle sales transactions, in which financial details are included, if applicable. The list of transactions may include information such as for example the deal date, a deal identifier, a customer name, a credit score, one or more vehicles, a deal type identifier, one or more names of lenders, one or more treatment status identifiers, one or more financial decision dates, one or more notes about the deal, information about credit applicants, employment information, credit information, customer contact information or a combination thereof information. The deal module 610 may also be configured to retain information about previous sales requests and / or transactions. In some modalities, the treatment module may send information to and / or receive information from third-party systems such as, for example, one or more third-party services. credit scrutiny. The 622 credit screening services can generally provide information about the customer's credit history and / or credit score. Examples of 622 credit screening services include, without limitation, Equifax® and Credco®. In one embodiment, the administration module 612 includes settings and information pertaining to the use of the sales management system vendor and / or the management server 102. For example, the management module 612 may store information about users of the sales management system. management of sales and suppliers (sometimes referred to as channels, for example) of products offered through the sales management system. The 612 administration module may also maintain associations between users and sellers, vendors and forms of the customer and documents, vendors and lenders, and other associations between parties such as vendors, users, third-party service provider lenders. In one embodiment, the service module 614 includes functionality for sending facsimiles, sending email, printing and transmitting information in one or more formats. For example, the service module 614 may be configured to periodically or sporadically transmit customer credit experiences to a 626 credit reporting service. The 626 credit reporting service may be for example, an interface to credit reporting programming elements such as METRO 2. As another example, the service module may be configured to interface with a 624 provider of contracts and / or documents such as LAW printing or Burrell printing. The provider of contracts and documents 624 can provide updated loan forms and regulatory information to the service module 614. In one embodiment, the service module 614 also includes support for sending and receiving communications between the management server 102 and other systems, such as as the lender system 108 and an agreement entity 110. For example, the service module 614 may be configured to receive signals or messages from the convention entity 110 which provides instructions for updating the inventory module 608. The service module 614 can support communications that take place via a communications network (for example, via HTTP or via email), via facsimile, via regular mail or via other appropriate means of delivery. In one modality, the document receivable module 630 contains functionality for the automation of invoice creation, notifications of overdue payments and records of settlement of debts. In some modalities, the document receivable module 630 includes functionality to integrate and display rows of account services, such as rows for accounts in various stages of delinquency or accounts with collateral insurance problems. The 630 document receivable module can also include a collection transaction reporting tool that displays reports of collection activity during a selected period of time. In some modalities, the collection activity can be classified into collection activity by collector, by cashier and by branch. The document receivable module 630 can also be interconnected with a payment protection client module 722 (figure 24) to provide collateral tracking to assist in the recovery of assets. The 630 document receivable module can also report collector statistics, including calls made, calls made, promises of payment procured, the value of promises of payment, insurance pledges, repositions placed, replacements canceled, letters sent , notes, average time spent per account, maximum time spent on an account, minimum time spent on an account and other appropriate collector statistics. b. Component 606 of the lender management system (LMS) The management server 102 shown in Figure 23 includes an LMS component 606 (also referred to as a lender management module). In some modalities, the deal module 610 includes an LMS component interface 606 of the management server 102. In one embodiment, shown in figure 23, the deal module 610 presents loan request information to the LMS component 606. The LMS component 606 may include data connections to, for example, one or more lender systems 108, convention entities 110, and / or vehicle history services 620. The convention entity 110 with which the LMS component 606 may be interconnected includes, without limitation, online convention service, such as ESCROW.COM ™, provided by Escrow.com, Inc. of Irvine, CA. The vehicle history services 620 with which the LMS component 606 can be interconnected, include, without limitation, a vehicle history reporting service such as CARFAX®, provided by CARFAX, Inc. Communications among the LMS 606 component. and one or more of the lender systems 108, the convention entity 110 or the vehicle history services 620 may occur, for example, via a communications network 104, via facsimile or via other appropriate communications means. In some modalities, the LMS 610 component includes functionality to handle the processing of loans provided by the seller (also known as purchase loans here pay here or vendor financing), full-sale loans, loans provided by the local lender , loans from Lenders who have an established relationship with a 100 sales management system provider, loans from lenders that do not have an established relationship with a 100 sales management system provider and / or deals with cash. The handling of deals with cash and other deals can include the procurement of a loan or short-term note for the seller and / or customer. For example, a financing or cash treatment deal may invoke one or more deferred payments, a deferred payment or another adapted financing plan that includes the use of short-term financial instruments. In some modalities, the LMS component compares a loan application for a client with a credit scorecard from the lender that contains criteria to identify lenders who would be willing to consider the loan application. In some modalities, the LMS 610 component sends the results of the scorecard comparison, in which matching lenders are included, with the seller system in such a way that the seller and / or customer can select one or more lenders to which the loan request will be sent. In alternative modalities, the LMS 610 component selects a subset of matching lenders to increase the likelihood that at least one of the matching lenders will approve the client's loan application. By example, the LMS component 610 may select a number (such as less than six, between two and five and another number) or a percentage (such as no more than 20%, between 5% and 20%, less than about 10% or another percentage) of corresponding lenders using, for example, experience data from previous loan applications. The data from previous loan application experiences may include the proportion of claims founded by a lender on applications considered by the lender, the proportion of applications founded by a lender to applications approved by the lender or the proportion of applications approved by a lender to applications considered by the lender. In alternative modalities, the LMS 610 component selects a subset of matching lenders to spread founding opportunities to frequently used lenders in order to maintain relationships with a greater variety of lenders. In some modalities, the component of LMS 606 submits a loan request from the client to one or more lenders, such as three, four or five lenders for consideration. In some embodiments, the LMS component 606 requests and / or receives loan request status information from the lender systems 108. The loan request status information may be sent to the 610 treatment module as a loan response. For example, the lender's decision or loan response may be sent in response to a loan application transmission or customer request. c. Other modules of the management server 102 Figure 24 is a block diagram of a mode of a management server that includes other modules of programming elements to implement various elements of a sales management system. The illustrated mode of the management server 102 includes modules of programming elements to perform a wide variety of functions and tasks. The modules operating on the management server 102 may include a document module 702 that provides batches of deal-specific documents, forms and / or third-party agreements. The document module 702 can be configured to provide intelligent document selection. For example, in some modalities, the document module 702 only displays and prints forms relevant to the type of treatment that is done. The management server 102 may include a delivery module 704 for sending information and documents via, for example, facsimile (using, for example, a Global fax interface), electronic mail, telephone, text messaging or other appropriate means. The management server 102 may include a report module 706 that reports customer credit experiences to a 612 credit reporting service. management server 102 may include a calculator module 708 that calculates values for regulatory disclosure requirements Z ("RegZ") and / or incorporates rules to ensure that federal, state and / or local loan laws and regulations are not violated . For example, the calculator module can ensure that document rights, interest rates, finance charges, and other rights do not fall outside the ranges allowed by state regulations. The calculator can provide an indicator to a user of the sales management system 100, which informs the user when a treaty does not conform to one or more government regulations. The indicator can be updated in real time as a deal is entered. In some embodiments, the management server 102 includes a configuration module 710 that maintains information about vendor relationships with vendors such as mechanics, rescuers, insurance companies, and the like. The management server 102 may also include a security module 712 that maintains settings for user security rights, file access permissions, document encryption, and so forth. The management server 102 may also include a user module 714 that provides user access control for one or more vendors associated with a user. For example, access control can restrict the days when a user can register, the locations from which the user can gain access to the system, the accounts to which the user has access and / or the reports, deals, documents, inventory, other tools or administrative actions available to a user. In one embodiment, multiple users may be associated with a vendor and multiple vendors may be associated with a user. The management server 102 may include an account module 716 that stores information about vendor accounts, such as, for example, cash accounts, long-term loan accounts, short-term note accounts, and so forth. In some embodiments, the management server 102 includes a retail sales listing module 718 that provides product information of the vendor to one or more retail sales listing services, which include a vendor's website and / or other online services. The retail listing module 718 may be configured to list inventory automatically when it becomes available or according to a schedule. The schedule can be determined, for example, by the number of days a product has been in a seller's inventory. For example, a seller may choose to list the inventory on the seller's website and immediately and configure the retail list module 718 to list a vehicle at an external service such as CARS.COM® only after the Vehicle has not been sold for several days or weeks. The management server 102 may also include an accounting interface module 720 that supports export information about, for example, accounts, expenses, inventory, sales, accumulated interest and / or vendors to an accounting system or accounting company. books. The accounting systems to which the accounting interface module 720 can export data include, without limitation, QuickBooks, SAP, Dynamics GP, and other accounting programming item packages. The management server 102 may include a payment protection client module 722 that can display the subsidiary or collateral security locations on a map with the help of a payment protection service provider 628. The service protection provider 628 payment can use Global Positioning System (GPS) tracking technology and GPS receivers installed in subsidiary or collateral guarantee vehicles to track and manage the collateral or collateral. For example, some 628 payment protection service providers can provide vehicle recovery assistance or disable electronic vehicles at the request of a mortgage carrier. Payment protection service providers 628 include, for example Ontime and Passtime. In one embodiment, the plague protection client module 722 displays a map showing the (s) location (s) of subsidiary or collateral guarantee and / or a list of subsidiary or collateral security that shows the type of vehicle, street or geographic neighborhood, action (s) carried out, the location (s) of action (s) completed, date (s) for which GPS tracking is requested and other appropriate information relevant to the recovery of assets. The management server 102 may include a lender module 724 that maintains the lender's relationship information, such as lender-specific loan application formats, amortization standards, rate cards, vendor financial participation incentives, application volume loan and volume of loan acceptance. The 724 lender module can help the seller and / or customer to select lenders in order to achieve objectives such as, for example, maximizing the seller's profits, maximizing loan availability and / or spreading the volume of loan foundation between Several lenders in order to maintain lender channel relationships.

B. Vendor System 106 In one embodiment, the vendor system 106 provides remote access to the information stored in the management server 102. In one embodiment, the system vendor 106 is a PC comprising at least one of input and output devices also as a network interface module for communications with the management server 106. It will be understood, however, that the vendor system 106 and management server 102 can reside on the same physical machine, such as a PC. In such a case a network interface module may not be required since a single processor may perform the actions of both the vendor system 106 and the management system 102 and internal communications may be sufficient in such a mode. In one embodiment, a user may use the vendor system 106 to electronically send and receive data from the management server 102, via a browser module. The vendor system 106 can send and receive data using one of any number of network protocols. In one embodiment of the invention, the request comprises a request for a hypertext transfer protocol (HTTP). However, it will be appreciated that other types of network communication protocols may be used. In other embodiments, the vendor system 106 may include some or all of the programs and / or data stored in the management server 102. 1. Browser or browser module In one embodiment, the vendor system 106 includes an explorer or browser module (not shown). The module The browser presents information to the user such as inventory data or lender data. The browser module and / or a web page accessible via the browser module may allow the user to request additional data, add data, database and / or modify data. The browser module can be implemented as a module that uses text, graphics, audio, video and other means to present data and to allow interaction with the data via the communications medium. The browser module can be implemented as a combination of an addressable screen of all points such as a cathode ray tube an all points addressable display such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma screen or other types and / or combinations of screens. In addition, the browser module can be implemented to communicate with input devices and can also include programming elements with appropriate interfaces that allow the user to access data through the use of stylized screen elements such as menus, windows, dialog boxes, toolbars, and controls (for example, radio buttons, check boxes, sliding scales, and so on). In addition, the browser module communicates with a set of input and output devices to receive user signals. It is recognized that in other modalities, the browser module can be implemented as a general interface that does not include access to the communication medium. 2. Network Interface Module The vendor system 106 may also include a network interface module (not shown) that communicates with the management server 102 to facilitate communication between the management server 102 and the vendor system 106 via the means of communications. The network interface module can use a variety of network protocols. In one embodiment, the network interface module includes the hypertext transfer protocol (HTTP). However, it will be appreciated that other types of network communication protocols may be used. 3. Input and output devices In one embodiment, the vendor system 106 communicates with a set of input and output devices. For example, the input device (s) may include a keyboard, a rolling ball, pen and fountain pen, mouse, trackball, speech recognition system or pre-designed switches or buttons. The input device (s) may (also) include a contact screen associated with an output device. Textual information or graphic can be entered by the user through the input device. The output device (s) can include a loudspeaker, a screen, a printer or a speech synthesizer. It is recognized that in some embodiments, one or more of the input and output devices may be included in the vendor system. For example, the vendor system may include an integrated set of speakers and an integrated keyboard. 4. Seller System Information The vendor system 106 may include a single-chip or multi-chip conventional general purpose microprocessor such as a Pentium® processor, a Pentium® II processor, a Pentium® Pro processor, a xx86 processor, a Centrino® processor, 8051 processor, MIPS® processor, Power PC® processor or ALFA® processor. In addition, the microprocessor can be any conventional special purpose microprocessor, such as a digital signal processor. In addition, the vendor system 106 can each be used in connection with various operating systems such as: Microsoft® Windows® 3.X, Microsoft® Windows 95, Microsoft® Windows 98, Microsoft® Windows® NT, Microsoft® XP, Microsoft ® Vista, Microsoft® Windows® CE, Palm Pilot OS, OS / 2, Apple® MacOS®, Disk Operating System (DOS), UNIX, Linux®, VxWorks or IBM® OS / 2®, Sun OS, Solaris OS, IRIX OS and so on. In one embodiment, the vendor system 106 is a personal computer, a laptop, a Blackberry® device, a portable computing device, a server, a computer workstation, a local area network of individual computers, a kiosk interactive, a personal digital assistant, a cell phone, an interactive wireless communications device, a manual computer, an embedded computing device or the like. As can be appreciated by anyone of ordinary skill in the art, the vendor system 106 may include various sub-routines, procedures, definition claims and macros. Each of the above modules are compiled, commonly linked separately, to a single executable program. However, it will be understood by one of ordinary skill in the art that the processes that are carried out by the modules selected from the modules can be arbitrarily redistributed to another of the modules, combined together in a single module, made available in a link library dynamics sharable or distributed in any other logical way. For example, in one embodiment of the invention, the browser module and the network interface module are integrated into a single executable module. In addition, for example, in another mode, the browser module is maintained in a link library that is separate from the network interface module. In addition, the browser module and the network interface module can be either an "application program", reside as part of the operating system for the device, or can reside partially in both.

C. Lender System 108 In one embodiment, the lender system 108 provides remote access to the information stored in the management server 102. It consists of the same or similar composition and has the same or similar functionality as the vendor system 106. In one embodiment, the lender system 108 is a PC comprising at least one each of the input and output devices also as a network access module for communications with the management server 108. It will be understood, however, that the lender system 108 and management server 102 may reside on the same physical machine, such as a PC. In such a case, a network access module may not be required since a single processor can perform the actions of both the lender system 108 and the management system 102 and internal communications may be sufficient in such a mode. In one embodiment, the user can use the lender system 108 to electronically send and receive data from the management server 102, via a browser module. The lender system 108 can send and receive data using one of any number of network protocols. In one embodiment of the invention, the request comprises a request for a hypertext transfer protocol (HTTP). However, it will be appreciated that other types of network communication protocols may be used. In other embodiments, the lender system 108 may include some or all of the programs and / or data stored in the management server 102. 1. Explorer Module In one embodiment, the lender system 108 includes a browser module. The browser module presents information to the user such as inventory data or data from the lender. The browser module and / or a web page accessible via the browser module may allow the user to request additional data, add data, cancel data and / or modify data. The browser module can be implemented as a module that uses text, graphics, audio, video, and other means to present data and to allow interaction with the data via the communications medium. The browser module can be implemented as a combination of an addressable screen at all points such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma screen or other types and / or combinations of screens. In addition, the browser module can be implemented to communicate with input devices and can also include programming elements with appropriate interfaces that allow the user to access data through the use of stylized screen elements, such as, for example, menus , windows, dialog boxes, toolbars, and controls (for example, radio buttons, check boxes, sliding scales, and so on). In addition, the browser module communicates with a set of input and output devices to receive signals from the user. It is recognized that in other modalities, the browser module can be implemented as a general interface that does not include access to the communication medium. 2. Network Interface Module The lender system 108 may also include a network interface module (not shown) that communicates with the management server 102 to facilitate communication between the management server 102 and the lender system 108 via the means of communications. The network interface module can use a variety of network protocols. In one embodiment, the network interface module includes the hypertext transfer protocol (HTTP). However, it will be appreciated that other types of Network communication protocols can be used. 3. Input and output devices In one embodiment, the lender system 108 communicates with a set of input and output devices. For example, the input device (s) may include a keyboard, a rolling ball, pen and fountain pen, mouse, trackball, speech recognition system or predesigned switches or buttons. The input device (s) may (also) include a contact screen associated with an output device. Textual or graphic information can be entered by the user through the input device. The output device (s) can include a loudspeaker, a screen, a printer or a speech synthesizer. It will be recognized that in some modalities, one or more of the input and output devices may be included in the lender system. For example, the lender system may include an integrated set of speakers and an integrated keyboard. 4. Lender system information The lender system 108 may include a single-chip or multi-chip conventional general purpose microprocessor such as a Pentium® processor, a Pentium® II processor, a Pentium® Pro processor, an xx86 processor, a Centrino® processor, an 8051 processor, a MIPS® processor, a Power PC® processor or an ALFA® processor. In addition, the microprocessor may be any conventional special purpose microprocessor such as a digital signal processor. In addition, the lender system 108 can each be used in connection with various operating systems such as: Microsoft® Windows® 3.X operating systems, Microsoft® Windows 95, Microsoft® Windows 98, Microsoft® Windows® NT, Microsoft® XP , Microsoft® Windows® CE, Microsoft® Vista, Palm Pilot OS, OS / 2, Apple® MacOS®, Disk Operating System (DOS), UNIX, Linux®, VxWorks or IBM® OS / 2®, Sun OS, Solaris OS , IRIX OS and so on. In one embodiment, the lender system 108 is a personal computer, a laptop, a Blackberry® device, a portable computing device, a server, a computer workstation, a local area network of individual computers, a kiosk interactive, a personal digital assistant, a cell phone, an interactive wireless communications device, a manual computer, an embedded computing device or the like. As can be appreciated by one of ordinary skill in the art, the lender system 108 may include various sub-routines, procedures, assertions of definitions, and macros. Each of the above modules are compiled and commonly linked separately to a single executable program. However, it will be understood by one of ordinary skill in the art that the processes that are carried out by modules selected from the modules can be arbitrarily redistributed to one of the other modules, combined together in a single module, made available in a link library dynamically sharable or distributed in any other logical way. For example, in one embodiment of the invention, the browser module and the network interface module are integrated into a single executable module. Furthermore, for example, in another embodiment, the browser module is maintained in a dynamic link library that is separate from the network interface module. In addition, the browser module and the network interface module can be either an "application program", reside as part of the operating system for the device, or can reside partially in both.

D. Communication networks In one embodiment, the management server 120 communicates with the vendor system 130 and the lender system 140 via the communication network (s) 104. The network (s) of Communications 104 can (include) any type of electronic connection (s) between a group of computers that include, for example, one or more of the following networks: a virtual private network, public internet, private internet, secure internet, a private network, a public network, a value-added network, a wired network, a wireless network, an intranet and the like. In addition, the connectivity to the network can be, for example, remote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), fiber-distributed data link interface (FDDI) or asynchronous transfer mode (ATM). The communication network (s) 104 can be connected to the management server 102, the vendor system 106 and / or the lender system 108, for example by the use of a modem or by the use of a network interface card that resides in each of the systems. In addition, the same (s) or different communications network (s) 104 can (be) used to facilitate communication between the management server 102 and the vendor system 106 and between the management server 102 and the lender system 108.

IV. Sales management methods In one embodiment, the management server 102 includes a credit application process, a vendor confirmation process and a lender confirmation process.

A. Credit application process In one modality, the credit application process determines a buyer-loan correspondence, as shown in figure 20. The credit application process gathers data about a potential buyer (via the seller ) 330 and lender's criteria 332. Customer's data in preferably, buyer's ID, credit score, income information, credit history, and amount of credit required. The criteria of the lender may include authorization of a seller and credit score or credit history data representing absolute threshold requirements. The process then compares the lender's criteria and the application data to determine whether the lender would consider granting the 334 credit to the potential buyer. Of the set of lenders that will consider the credit application, the process chooses a number N of potential lenders 336. The number N is preferably of a sufficiently high number to have a reasonable probability that at least one of the lenders will accept the request for a loan. Credit, but not so high that lenders would systematically lose credit for a loan they would commonly accept. In some modalities, N is fixed whereas in other modalities, N varies. In a preferred embodiment, N is approximately 5. Once the potential lenders are chosen, the application data is sent to each of them. potential lenders 338. At this point, lenders can review the application to determine if they wish to extend the credit to the buyer / borrower. The process receives the answers from the lender 340 and presents the lenders who accept the seller to choose the final lender 342. Once the lender is chosen, the process can use the collected request data and the lender's data to enact the required forms to complete the 344 credit transaction. In 346, copies of the required forms are distributed to the seller and the lender.

B. Seller confirmation process In one embodiment, a seller confirmation process begins when the credit application process described with reference to figure 20 ends. In one embodiment of the seller confirmation method shown in Figure 21, the vendor takes the forms he has received from the management server 120, finalizes the forms with the help of the buyer and sends the forms to the lender 450. When the seller receives approval of the lender 452, the seller responds by sending the title to the module or convention entity 110 (454). In some embodiments, the seller sends the electronic title to the convention entity 110. Then the seller waits for an approval from the convention entity 110 that the The lender has submitted the funds and the title and registration have been updated 456. At 458, the seller then receives the funds distributed from the convention entity 110 to complete the credit purchase from the seller's perspective. In one embodiment, the seller confirmation process is automated, such that information between the management server 102, the vendor system 106, the lender system 108 and / or the convention entity or module 110 is automatically sent. using for example, digital signatures, electronic funds transfers and so on. In some embodiments, a certified authority (CA) for electronic title, such as, for example, a governmental motor vehicle division (DMV) establishes trust between the vendor system 106, the convention entity 110, and the lender system 108 by medium of a private key / public key infrastructure. In one mode, a CA issues a certificate to an entity in a network after verifying the identity of the entity. The certificate may contain an identifier for the entity and a public key belonging to the entity. The public key can be used to authenticate that a communication is signed with a private key of the entity and has originated from the entity. The private key is mathematically related to the public key. In order to provide some degree of Confidence that a particular certificate is valid, the certificate is signed with the private key of the CA, in such a way that other entities can use the public key of the CA to verify that the certificate has been signed by the CA. The fact that the certificate has been signed by the CA indicates that the CA has verified that the certificate belongs to a reliable party. In some embodiments, a verified certificate accompanies the electronic title sent from the vendor system 106 to the convention entity 110. Thus, the public key / private key system provides a security level for electronic title transfers.

C. Lender's Confirmation Process In a modality shown in Figure 22, the lender's confirmation process begins at 560 with the receipt of a copy of the management server forms 120. At this point, the lender has the option of confirm that the buyer is the one who says and that the data presented by the buyer and seller are accurate when performing their own due diligence 562. In some modalities, all or part of the due diligence is automated. This is not required to obtain the functionality of the system. However, a recommended modality includes verification of such data in order to reduce risks that the lender has been deceived by fraud. After satisfaction with the results of due diligence, the lender will approve the 564 loan and send the funds to an agreement entity at 566. If the request fails due to due diligence 562, the lender can deny the loan, break the transaction, and end the process. Assuming that the lender has approved and sent the funds to the agreement, the lender waits to receive confirmation that the seller has provided the title, registration and / or other relevant recommendation 568 and confirmed the lender's security interest in the title to the automobile 570 In one embodiment, the confirmation process of the lender is automated in such a way that the information between the management server 102, the vendor system 106, the lender system 108 and / or the convention entity or module 110 is automatically sent. using, for example, digital signatures, electronic funds transfers and so on. In addition, in one modality, the credit application process includes automatic interaction with the seller's confirmation process, the lender's confirmation process, the agreement module or entity 110, and third-party entities. In addition, in one modality, the process may include a certified electronic box in which authorized documents are stored. The credit application process could then authenticate the documents as having been signed by the parties in the transaction, which include, for example, the lender, seller, buyer, guarantee company, insurance company and so on. Thus, in one modality, the loan application process can be considered as a paperless loan. For example, in one modality, the entire process is automatic, using documents and electronic forms from the moment a vendor begins typing an application at the time the title and fund are released from the agreement, including, for example, registration with the DMV, payment of state and / or local taxes, payment of pre-existing mortgages and so on. While the previous figures illustrate modalities of the flowcharts, it is recognized that in other embodiments, other flowcharts may be used. In addition, some of the items may be effected at least partially in parallel or at least partially in series.

IV. Sample operation For purposes of illustration, a sample scenario will now be discussed in which the systems and methods are used in operation. In this sample scenario, the system is used by a used car dealer to process a loan application via an internet website.

In one mode, the management server executes a program or system that is referenced in the modalities shown in the figures such as Finance Express or FEX. In one modality, this program provides a service capable of contracting with and becoming the primary management system for thousands of independent automobile dealers throughout the United States of America and potentially worldwide. The program begins when the automobile vendor uses his vendor system 106 to register with the management server 102. The system is preferably protected by password and ID. In one modality, the program issues a password and free access ID to qualified vendors and only begins to charge vendors only when they are fully activated in the system. A modality of a take-up of such registration page is shown in Figure 2. After granting access to the system, the seller will see a home page such as the modality shown in Figure 3A. As shown, there is a row of tabs near the top of the page corresponding to the various aspects of the system and to web pages or screens, such as "Apps" to access and handle credit requests and "Inventory" to view and manage the seller's personal automobile inventory. Each tab will be described in more detail herein. At this point, the seller can start a new credit application for a car buyer, review the status of current applications in process, view driving reports, request to sign with new lenders in the system and so on. An alternative mode of a home page is shown in Figure 3B. The homepage illustrated in Figure 3B provides the user with an instant snapshot of the total sales value for the day, the seller's inventory, and information about accounts receivable, overdue accounts, and a summary of transactions. The modality of the homepage shown in Figure 3B is adapted for a seller who offers financing from the seller of the cars he sells (for example, a "buy here, pay here" seller). In some embodiments of a sales management system, a user may select the format of the home page displayed after access to the system is granted. For example, at least some users may be given the ability to select a home page similar to the one shown in Figure 3A, a home page similar to the one shown in Figure 3B, or another appropriate home page format . Users who select a seller's home page from buy here, pay here (BHPH) can also be provided with an alternative source that allows access to several other relevant items to the BHPH vendor, such such as, for example, those provided by the 630 document receivable module. The document receivable module 630 can be configured to track and manage the debt collection efforts of the BHPH seller. One modality of a notes receivable page is shown in figure 25. In one modality, the notes receivable page includes functionality to consult customer accounts. For example, a database of client accounts can be searched by surname, name, social security number, telephone number, loan number, account number, inventory number, vehicle identification number (VIN) or other appropriate identifier. An account inquiry module returns a list that summarizes outstanding, withdrawn and predetermined notes. The list may include the name of the lender, the loan and / or account numbers, the inventory and / or plate numbers, the type of vehicle and / or VIN, the account status, the account row, the number of days the account is due, the account balance and other relevant account details. One or more interface elements such as buttons can be provided in the listing to add notes to the client's accounts and perform actions, such as pasting a payment, on the client's accounts. When selecting an interface element, such as an "Apps" tab or alternatively, a "Deals" tab, the vendor is taken to a screen such as the mode shown in figure 4. This page shows a list of all loan applications of the seller and their status. In some modalities, the page also shows a list of other varieties of treatment that are pending or completed, in which deals with cash are included. In one modality, when selecting "New App" the seller is directed to a page such as the one illustrated in figure 5A. Here, the seller can enter information about a new credit applicant and present that information to obtain a credit report. In an alternative embodiment, the vendor may select a "New Deal" interface element such as that shown in Figure 5B. The modality shown in Figure 5B allows the seller to select the type of treatment that the seller wishes to initiate. The sales management system can select worksheets and forms for the salesperson to complete that are adapted to the type of treatment selected. For example, the seller may be presented with a screen as shown in Figure 5B, from which the seller may select a new cash deal, a new financial deal or a new full sale deal. Depending on the type of deal selected, the sales management system may submit additional questions to further adapt the information required to complete a deal. For example, the sales management system can Ask if a deal will involve one or more buyers. Information about a permuted vehicle may also be required. Before proceeding with the purchase request, the sales management system may also allow the user to consult a customer by name or social security number in a customer database 218 (Figure 19). If a matching customer record is found, the information already in the database can be inserted into a purchase request automatically. If the new deal is a financial deal, can the user be directed to a page such as the one illustrated in figure 5? to enter purchase request information. The purchase request shown can be adapted to suit the type of treatment and can also include validation indicators that show that the required information must be entered and / or identify potential errors in the application. Once a credit report is retrieved, the seller can select the "Credit" tab to access credit report information, as illustrated in the modality shown in Figure 6. Figure 7 shows a credit modality. a page of employment information ("Emp Info") that allows the entry of employment information. If you are going to consider a co-signer in the loan, the seller _ selects the "Co Info" tab and enters the information in the co-signer as well as the information of applicant was introduced in figure 5 ?. In some embodiments, the "Emp Info" page is adapted to selectively hide the co-lender information fields depending on the prior deal information provided by the user. The "swap" page allows the seller to enter information about any potential swap of the buyer as illustrated in the mode shown in Figure 8. The "swap" page may not be displayed if the user has previously indicated that no swap is in effect. included in the deal. Once the information is entered, the "Desking" page (or worksheet) shows the loan opportunities available based on the buyer's information, which includes, for example, credit data, automobiles in the inventory of the seller and available loan programs as illustrated in the modality shown in figure 9. This page classifies the vehicles for which the client qualifies and is acceptable to the lender for that client. In addition, compare each vehicle with the requirements of the approval guidelines of each lender. It also lists the make / year / model of each vehicle and the number of days the vehicle has been in inventory. This page allows the seller to find what is potentially the best deal and to adapt the deal structure to try to get the lender's solution. The worksheet of This can also include a scratch pad to show various discounts or vendor reservations and vehicle information. The vehicle information can be selected, searched or retrieved, for example, from the inventory module 608 (figure 24) or from another source. The treaty worksheet can show a calculator for the amount to be financed, taking into account, for example, the contract date, the sale price, the cash payment, the net swap value, the product value after of market, the proportion of the loan and the payment program. The calculator can calculate the amount of a periodic loan page, disclosure values of Z regulation, gross benefit of total treatment, net profit and other values relevant to the deal. In some embodiments, a deal list page (not shown) indicates the sale price of the vehicle for one or more lenders, the customer's monthly payment and what the interest rate will be (for example, the contract rate) for the customer . The detail list page may also list the purchase rate in the event that the lender provides the seller with a financial reserve share. It also lists the payment with cash from the customer. The number of days that an inventory is displayed, allowing the seller to handle the aging of the inventory. For example, the seller may choose to adjust the terms of sale, such as the sale price, to vehicles that have been in inventory for a large number of days. The seller may wish to sell a vehicle that has been in inventory for an extended period of time and accept a lower benefit amount for a vehicle that was recently purchased from an auction. In one modality, the sale price begins with the maximum sale price, so that each transaction can be compared in relation to its maximum potential sale price. The monthly payment is indicated based on these maximum sales prices. Once a vendor selects the best deal, the vendor can begin structuring the deal by selecting an inferred item with the user associated with the desired deal, such as the "Deal" button or a "View" button. This loads the selected vehicle to the desktop tool or worksheet as the desired vehicle for the customer. After a vehicle has been selected and the seller wants additional information regarding the selected vehicle, the seller can press the "view vehicle" button that will immediately display the information for that particular vehicle, as it is entered, to the inventory record. In one modality, the desktop page includes four electronic tables. The four tables include the sale price, the monthly payment, the barter allowance or swap and payment in cash. This section of the system provides the ability to manipulate or change the values of these four components with the click of a rolling ball button. When selecting a given lender (under "Select all lenders of all rows"), the system automatically charges the maximum advance fee percentage of the lender to the four frames. The system also introduces the terms acceptable by the lender, contract rate and purchase rate. The seller can then enter the amount of the payment with cash from the customer and fill the permutation allowance given in the customer's car. The seller can also enter the maximum monthly payment that the customer is willing to pay in the "Maximum payment" box located above the green "Monthly payment" box. By highlighting the small "rolling ball" button to the left of the sales price box you determine that the sale price needs in order to get the maximum monthly payment. The selection of this option adjusts the calculations based on the amount that was entered in the cash field. The third "rolling ball" calculates the transaction based on the given permutation allowance. In this way, the entire transaction can be re-calculated repeatedly using different values for the various criteria. The lower left section of the page Desktop includes a check box that is marked as "Customer View". The selection of this check box changes the view on the screen to only that information that is related to the client. In other words, information that is related to the seller (such as benefit) is hidden from view. The background of the page includes a table of outstanding issues. This box informs the seller if there is any problem with the structure of the deal. If the seller does something that is outside the program approved by the lender, the box will turn bright red. This indicates that there is a problem and at the same time, the question will be detailed in the table of outstanding issues, indicating what can be done to correct the problem. For example, lender A can approve a loan to Mary Smith for 115% of the total sale price. The seller can type the form that the loan is for $ 3500, which is 118% of the total sale price. When the seller tries to save the form or leave the screen with the information, the program can then alert the seller that the loan amount entered does not match the amount approved by the lender. After a lender has been selected and the deal is finalized, the next thing is to select the button in the lower left corner marked "Go to Funds." The system sends an email to the lender notifying the lender that the seller is sending the lender the deal in accordance with the terms of the lender's approval. The system also selects the relevant forms of the library of forms that are required by this lender for this particular transaction. In addition, the system creates the record of funds or "Recap Sheet" (sometimes referred to as the "wash sheet"), which includes accounting data for this particular transaction. In some embodiments, the seller may select a "Lender" tab, causing the system to display a screen such as the mode shown in Figures 10A and 10B. On the lender selection page, one or more credit requests associated with a customer can be reviewed and selected. In one modality, the user can select from lenders different from those selected on the desktop page. In alternative modalities, the lender selection process can be integrated with the treatment worksheet. For example, each worksheet may be associated with an individual financing package or lender. Figure 11 shows a modality of a page of "Funds". The background page is a transaction recap sheet for accounting purposes. The center of the page includes the notes section, which tracks any communications between the seller and the lender, such as necessary items, anticipated date of funds and open questions. This allows anyone familiar with the transaction to register and obtain an understanding of the status of the funds. In addition, the captured notes can be sent to any approved lender. Thus, the approved lender will be able to see, for example, if the seller has incorrectly approved more than one lender, if the seller has "altered" any of the buyer's request data and so on. This information helps the lender identify possible fraudulent changes and protect the lender from seller fraud that they might not otherwise be able to notify. In addition, it allows the lender to correct any errors before the final deal increases the likelihood that the documents are prepared correctly and the lender will be able to accept the final draft. The rest of the fund page is divided into the various sections of the transaction, which include the customer information, the vehicle sold, the swap information, the deal structure, the inventory detail and a summary of the transaction. Applications introduced to the sales management system may be specific to the lender, which allows the lender to obtain data directly from a vendor, such as financial statements, balance sheets, inventory and duration in the business. In one mode, the lender must first accept a seller as qualified. Once the lender has done this, the seller can immediately begin submitting applications to that lender. In one modality, the system preferably processes the information and filters it against the lender's credit criteria to see if the client meets the lender's loan criteria. If the client is accepted, the system sends the request to the lender, time in which the client approves or declines. Preferably this process occurs in real time. In one modality, the information concerning all the loans presented by the seller is reflected in the main interface screen of the vendor of the system. At first glance, the seller can see the status of pending requests. The deal structure is filled in the desk section of the sales management system, allowing the vendor to communicate and reveal the structure of the loan approved with the client. Once this is finished, the seller prints all the necessary forms for the client, lender and seller. In some modalities, the forms can be accessed from the "Forms" tab, as illustrated in the modality shown in Figure 12. The forms may also be available by selecting a "Credit Request" tab or by making Click on a "Print forms" button in a selection area of the lender. In order to update the collection of a given transaction, the seller can choose to enter notes as illustrated in the mode shown in figure 13. These notes allow the seller to quickly provide the seller with the status of the application, loan and transaction. like an everything. In addition, lenders can also receive copies of the forms to see draft copies of the documents the seller prepares or is preparing. Lenders can use this information to help them make decisions and / or provide guidelines on how they would suggest that the seller structure the deal. For example, lender A can agree to the seller's terms as presented, but also suggest that it go with 15.2% for 60 months instead of 48 months or any other combination between 15% and 17%. In addition, the lender may specify a purchase rate that the lender wishes the seller to use, but also allow the seller to use a higher contract rate with the buyer. In addition, sellers and lenders can also allow the seller to share some of the benefits and share them with the seller on the desktop page (or treatment worksheet). This information gives the seller an advantage of being able to see a benefit estimated more accurately by the deal that is being structured. Without This information, the seller has commonly to guess and frequently the seller's conjecture is not accurate. Once the seller selects a deal, the system can then send an electronic file (e-file) to the lender, so that he has a copy of the transaction. In order to provide a safer transaction for lenders and buyers likewise, in one mode, the system also sends the information to an agreement module or convention entity 110, which initiates the mortgage registration process for the lender. The convention module or entity 110 may be Escrow.com, or another module or convention entity. The Escrow.com 110 agreement entity or module then consummates the transaction and the DMV title process. When the lender is prepared to give funds to this loan, the funds are delivered to the module or convention entity 110, instead of the lender. The module or convention entity 110 holds the funds in the name of the lender, to assure the lender that the mortgage has been registered on the vehicle. When the title process is complete, the funds are released to the lender. In one modality, the sales management system uses electronic files, such as titles and / or electronic mortgages, with a governmental division of motor vehicles (DMV). The use of electronic securities and mortgages may shorten the time in which a sale of vehicles and title transfer can be consummated. An electronic title is a title that exists in electronic form, for example in a DMV database. An electronic title can be a paperless equivalent of a paper title certificate. Closely integrate the sales management system and the agreement service now time and money for the lender, who can avoid a title tracking and protects the lender from losses due to unreliable sellers. When the lender has accepted the final loan documents, the settlement company for any outstanding mortgages in the title, pays any processing fees and / or taxes and submits the new title application to the state. Another aspect of a program modality that improves efficiency for the lender is the fact that the request can be sent to the lender's credit review system with a direct data interface. This cuts the costs for the lender by eliminating the input and data processing requirements. In one modality, approval or denial is returned to the seller in as little as a few seconds to a maximum of 45 minutes, for example. In one modality, elements of the system are designed to improve the "look to book" ratio and the performance of the lender, provided by this extra incentive for lenders to participate in the system. By limiting loan applications to those that meet the criteria of the lender and / or to limit the number of lenders to whom approval may be requested, for each sale, the lenders have a higher probability of obtaining a loan for each application they review for approval. For example, a lender is more likely to take the time to review the application if the lender knows that the application meets its criteria and that the lender is one of only five lenders who compete for the loan. If the number of lenders is not limited, there may be fifty, a hundred or even more lenders who receive the request and thus a lower probability that a particular lender will get the loan. As discussed in general, a modality of the sales management system tracks the seller's inventory. In some modalities, the seller's inventory can be easily viewed by accessing the "Inventory" tab, a mode of a sample inventory listing is illustrated in Figure 14. In some embodiments, the vendor's inventory list may also Include one or more pictures of the vehicles, the location of the vehicles, the age of the inventory, the status of the vehicles or other vehicle information. In some modalities, the user can select an "Add Expense" interface item in the inventory list to adjust the costs associated with vehicles in the inventory. Figure 14 shows a modality of a screen for adding a new car to inventory. This can be done as the user chooses a car or preferably the database would be updated each time the seller buys additional cars for sale. Additional elements may also be present in the sales management system in some modalities. For example, a page of reports can provide an easy method for obtaining pre-designed impressions of the important information processed by the system as illustrated in the modality shown in Figure 16. Although most of the information needed by most of the Vendors are available online at any time, one or more reports can also be printed. Available reports may include, for example, inventory reports, sales reports, vendor account reports, transaction reports, expired account reports, sold account reports, general ledger reports, compliance reports, channel reports and other reports of activities and information related to the seller. In some modalities, the reports can be filed in a warehouse of the sales management system, adapted and sent via facsimile or email (for example, as an Adobe® PDF file attached to an email message). Similarly, the sales management system can replace other devices or programs, such as calculators and calendars as illustrated in the modalities shown in Figures 17 and 18, respectively. Although these elements may not be required to effect a transaction, their inclusion aids transactions and further reduces the vendor's need to rely on other programs and / or management tools when operating a sale. While the previous example involves a used car salesman and specific modalities of Web pages and screen shots, it will be recognized that these modalities are used only to illustrate elements of various modalities of the systems and methods. In addition, the systems and methods can be used in other environments and can be used with other types of and / or combinations of loans, which include, for example, car sales, house sales, rents and data, data from audio, graphic files, multimedia data, executable data and so on. Additionally, a creditor may obtain a security interest against collateral or collateral security different from the car to be purchased, such as in the buyer's house.

V. Exemplary pricing structures It will be recognized that a variety of pricing structures can be used with the management system of sales. For example, sellers can be charged a fixed fee, a subscription fee and / or individual fees for particular items, such as, for example, credit reports, printing forms and so on. As another example, lenders can be charged a fixed fee, a subscription fee and / or individual fees for particular items, such as, for example, each time they are listed as a potential lender, each time an application is sent to them. for review, each time they are selected as the lender and / or whenever they actually give funds to the loan.

SAW. Additional Modalities Although the systems and methods of the credit application process, the lender's confirmation process and the vendor confirmation process are disclosed with reference to preferred embodiments, the invention is not intended to be limited thereto. Rather, the one skilled in the art will recognize from the disclosure herein a wide number of alternatives for the exact ordering of the stages and how the convention module 110 is implemented. In addition, in other modalities, the seller's management system may include an accounting system to manage the vendor's finances, an internal financing system that allows the vendor to provide financing, a digital signature system that allows the sending of electronic documents using digital signatures, a campaign system to send announcements to potential buyers, an extended service contract or guarantee system that allows sellers to manage and provide services extended internally or with third parties, a sticker system that allows sellers to print decals such as window decals, a summary generation system that provides lenders and / or sellers with summaries, a credit reporting system that accesses information from buyers credit and so on. It will also be recognized that the term "remote" may include data, objects, devices, components and / or modules not stored locally, that are not accessible via the local main distribution line. Thus remote data may include a device that is physically stored in the same room and connected to the user device via a network. In other situations, a remote device may also be located in a separate geographical area, such as, for example, in a different location, country, and so on. It will be recognized that the term "module" may include programming elements that are independently executable or autonomous. A module also includes program codes that are not independently executable.

For example, a program code module may form at least a portion of an application program, at least a portion of a linked library, at least a portion of a component of programming elements or at least a portion thereof. of a service of programming elements. Thus, a module may not be autonomous but may depend on an external program code or data in the course of a typical operation. Although the above invention has been described in terms of certain preferred embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. In addition, the embodiments described have been presented by way of example only and are not intended to limit the scope of the invention. Of course, the novel methods and systems described herein can be implemented in a variety of other ways without deviating from the spirit of the same. Thus, other combinations, omissions, substitutions and modifications will be evident to those experienced in the art in view of the disclosure in the present. Thus, it is not intended that the present invention be limited by the disclosed embodiments, but that it be defined by reference to the appended claims. It is intended that the appended claims and their equivalents cover forms or modifications as they would fall within the scope and spirit of the invention.

Claims (36)

1. CLAIMS 1. A system to help a seller to sell a vehicle to a customer, characterized in that it comprises: an input module that allows the entry of data concerning the customer and data concerning a proposed purchase of the vehicle by the seller's customer; a filter module to match at least some of the customer data or data concerning the proposed purchase with the lender's criteria, where the lender's criteria are selected to identify lenders who are willing to consider providing a loan for the purchase of the vehicle; a lender selection module, configured to select a subset of the matching lenders to increase the likelihood that at least one of the matching lenders will approve the loan and a transmission module configured to transmit the customer's data to the subset of lenders. The system according to claim 1, characterized in that the lender selection module selects between two and five of the matching lenders that are likely to approve the loan based on experience data processing previous loan applications maintained by the system. 3. The system according to claim 1, characterized in that the lender selection module selects between five percent and twenty percent of the matching lenders that are likely to approve the loan based on experience of processing previous loan applications from the seller . The system according to claim 1, characterized in that the criteria of the lender comprise at least one of model year interval of the vehicles preferred by the lender, a preferred vehicle brand, history of previous owners, vehicle mileage. , if the vehicle has been in an accident and the severity of the accident. 5. The system according to claim 1, characterized in that the criteria of the lender comprise a credit profile of the preferred customer. The system according to claim 1, characterized in that the criteria of the lender comprise a preferred range for a credit score of the client. 7. A system to help a seller to sell a vehicle to a customer, characterized in that it comprises: an input module that allows the entry of data concerning the customer and data concerning a proposed purchase of a vehicle by the seller's customer; a lender management module to match at least some of the customer data or data concerning the proposed purchase with the lender's criteria, where the lender's criteria are selected to identify lenders who are willing to consider providing a loan for the purchase of the vehicle; a transmission module configured to transmit the customer data to at least some of the matching lenders and a document receivable module configured to provide one or more tools to assist the seller in servicing a loan provided by the vendor. The system according to claim 7, characterized in that the one or more tools comprise at least one tool to automate the creation of invoices, a tool to automate the creation of expired payment notifications or a tool to manage settlement records. of debt. The system according to claim 7, characterized in that the transmission module comprises a delivery server configured to send documents via at least one of facsimile, email or http. 10. The system according to claim 7, characterized in that it also comprises a module of inventory to maintain information concerning vehicles used in a seller's inventory. 11. The system in accordance with the claim 10, characterized in that the inventory module is configured to place complementary advertisements with at least one retail listing service, according to a schedule specified by the vendor. The system according to claim 12, characterized in that the at least one retail listing service comprises a website published by the seller. 13. The system in accordance with the claim 11, characterized in that the inventory module automatically purchases an advertising placement in the at least one retail listing service. The system according to claim 11, characterized in that the at least one retail listing service comprises a third party retail listing service. 15. The system in accordance with the claim 7, characterized in that it further comprises a calculator module that calculates and displays Z-regulation disclosure requirements for the deal. 16. The system according to claim 15, characterized in that the calculator module is configured to generate on a screen of a vendor system disclosure text by disclosure requirements of Z regulation for the deal. The system according to claim 7, characterized in that it also comprises a calculator module configured to: determine whether the proposed purchase complies with one or more government regulations that regulate at least one of a document fee, an interest rate or a financial charge and provide a real-time indicator to the seller that alerts the seller when a proposed purchase term creates a compliance problem with one or more government regulations. 18. A used vehicle financing system, characterized in that it comprises: a credit application module configured to accept customer data and vehicle data, wherein the vehicle data includes data specific to used vehicles and a filter module of a lender , configured to match the lender's criteria with the information collected by the loan application module to determine which lenders may be willing to finance a given combination of buyer and vehicle, in where the lender's criteria include factors that are specific to used vehicles. 19. The system for financing used vehicles according to claim 18, characterized in that the criteria of the lender comprise a vehicle model year interval preferred by the lender. 20. The used vehicle financing system according to claim 18, characterized in that the criteria of the lender comprise at least one of whether the lender is willing to finance a vehicle that has been in an accident, the number of accidents or a indication of the severity of the accident. 21. The used vehicle financing system according to claim 18, characterized in that the vehicle data includes at least one year of the model, history of previous owners, the make of the vehicle, the mileage of the vehicle, whether the vehicle You have been in an accident or an indicator of damage resulting from the accident. 22. A method for facilitating a sale of a vehicle from a seller to a buyer, characterized in that it comprises: placing funds from a designated lender for sale to an account that can not be accessed by the seller; receive the electronic title to the vehicle that is sold by the seller; retain the electronic title, in such a way that the lender does not have access to the electronic title; release the funds to the seller and the title to the lender, after confirmation that the lender has approved the electronic title and a mortgage on the vehicle. 23. The method according to claim 22, characterized in that it further comprises providing a signal to a sales management system of the vendor to update information in an inventory module of the sales management system. 24. A computer-based vehicle sales management system, characterized in that it comprises: a server module configured to communicate with a remote computer system; a vendor management module in communication with the server module, the vendor management module comprises an inventory module to maintain information about an inventory of vendor vehicles and a lender management module in communication with the management module from the vendor, the lender's management module is configured to: receive loan request data from the vendor's management module; receive request decision information loan from at least one lender and provide the loan request decision information to the seller's management module. 25. The vehicle sales management system according to claim 24, characterized in that it further comprises a document receivable module configured to provide one or more tools to assist the seller in servicing a loan provided by the vendor. 26. The vehicle sales management system according to claim 24, characterized in that it also comprises a transaction module that keeps records of one or more loan applications created by the seller and at least one status of each of the loan applications. 27. The vehicle sales management system according to claim 24, characterized in that it also comprises a reporting module that provides credit experience of the seller's customer to a credit reporting service. 28. The vehicle sales management system according to claim 24, characterized in that it also comprises a deposit for keeping electronic documents selected for file by the vendor. 29. The vehicle sales management system of according to claim 24, characterized in that the inventory module is configured to select one or more vehicles from an inventory database for which a lender would be willing to provide a loan of purchase money to a customer and wherein the server provides information for the selected vehicle of one or more vehicles for display in a vendor's system. 30. The vehicle sales management system according to claim 24, characterized in that it also comprises an account module configured to allow a user of the sales management system to track documents receivable and debt collection information. . 31. The vehicle sales management system according to claim 24, characterized in that the sales management system also comprises a payment protection customer module to help a user of the vehicle sales system locate subsidiary warranty. or collateral for vehicle loans. 32. The vehicle sales management system according to claim 24, characterized in that a loan for a vehicle that serves as at least a portion of the collateral or collateral is provided by the seller. 33. A system to market a used product, characterized in that it comprises: an inventory module that maintains information about the product used, wherein the information about the product used comprises an image of the product used; an interface module to receive a schedule to obtain complementary ad placements from a user of the system and a retail listing module configured to place advertisements for the used product with at least one retail listing service, according to the schedule, while the used product remains unsold. 34. The system according to claim 33, characterized in that the retail listing module is configured to discontinue collocations of complementary assumptions associated with the product used, in response to a received signal that the used product has been sold. 35. The system according to claim 33, characterized in that the inventory module is configured to remove the used product from an inventory database, in response to a received signal that the used product has been sold. 36. The system according to claim 33, characterized in that the schedule includes at least two dates to place advertisements with at least two services of stado of retail sale diferent