Using a Custom Printer Driver to Automatically Electronically Create, Capture and Manage all Documents Utilized in a Transaction

Abstract

A plurality of electronic documents utilized in a transaction are automatically managed. For each separate document of the plurality, a custom printer driver receives instructions to a printer for printing the document. Instead of printing the document, the custom printer driver creates a file in a standard format such as PDF containing the document, based on the received print instructions. Content concerning the transaction is automatically added to at least one corresponding field of the file containing the document in the standard format. At least one electronic signature for the document is received, and automatically added to at least one corresponding location of the document in the standard format. The file containing the document in the standard format is saved with the added content concerning the transaction and the at least one electronic signature, and the saved file is associated with the transaction.

Description

TECHNICAL FIELD

This disclosure pertains generally to electronic management of documents used in a transaction such as the purchase or lease of a vehicle, and more specifically to using a custom printer driver to automatically create, capture and manage all documents utilized in a transaction electronically, without requiring the actual printing or utilization of physical documents, and where the documents for the transaction may vary based on geolocation and/or other circumstances.

BACKGROUND

Many transactions are now conducted entirely online without the need for customers to leave their home, such as purchasing clothes, electronics, household goods, etc. However, certain types of transactions are still often performed at least partially in-person, outside of the customer's home. One example of such a transaction is the purchase or lease of a car or other vehicle. These transactions require the execution of a large number of documents from different sources, such as a sales contract from the dealer, licensing and registration forms from the state, financing documentation from a financial institution, an extended warranty from another party, etc. In such a transaction, the number and type of specific documents to be executed varies, depending upon the location at which the purchase occurs (e.g., different states and counties have different licensing, registration and taxing schemes, and different forms for the execution thereof). The specific documents to be signed also vary based on the exact nature of the transaction (e.g., whether the customer has a trade-in, the terms of the financing if any, whether the customer is purchasing specific third-party add-on services such as rustproofing, an extended warranty, etc.).

Conventionally, the customer takes time out from his or her busy schedule to make one or multiple trips to the dealership to select and purchase a vehicle, and execute this large collection of paper documents. These trips to the dealership and the signing process itself are extremely inconvenient for the customer. In addition, managing and organizing all of these different documents is inconvenient for both the customer and the dealer. The customer is typically handed a large stack of copies of the executed paper documents, which ideally the customer files but in practice often loses. The dealer has legal record keeping requirements, which are burdensome. For example, federal and state law requires different forms to be maintained by the dealer for given periods of time.

Some conventional online systems exist to assist a customer in the online purchase of a vehicle. By using such a conventional system, a customer may be able to select a specific vehicle and initiate the purchase process online. Nonetheless, the large collection of documents described above still need to be executed to complete the transaction. Because these forms are from multiple sources and vary by geographic region, conventional systems manage these forms piecemeal. An individual dealer may support an electronic sales contract, whereas some states may allow online completion of registration or licensing documents. Some conventional systems may electronically communicate with these parties and provide support for electronic completion of a subset of the forms required for the transaction. However, when using conventional systems, at some point the customer needs to physically sign at least some physical documents to complete the process.

From the dealer's perspective, some conventional electronic systems exist for transaction management. These conventional systems support maintaining some documents electronically, but because of the varied nature of the forms and their sources, no conventional systems support managing all of the forms for the transaction even for a single dealer, much less for any dealer in any state. To access specific forms electronically, conventional systems access the servers of individual document sources (e.g., departments of motor vehicles, financial institutions, providers of warranties, etc.) through separate Application Programming Interfaces (APIs) exposed by these parties. This is less than ideal because not all parties that provide documents needed for the transaction make their documents available electronically in this way. Even for those that do so, the exposed APIs tend to be updated less frequently than the documents themselves, and thus the conventional systems do not necessarily support current versions of the required documents. Further, conventional systems do not support the different requirements based on geographic location, and thus a conventional system used by a dealer in one state would not automatically work for a dealer located in another.

It would be desirable to address these issues.

SUMMARY

A collection of documents utilized in a transaction such as the purchase or lease of an automobile from a dealership is automatically managed through the use of a custom printer driver. Completing such a transaction typically requires the processing of multiple documents in various formats from different sources. For example, the purchase of a car may require the execution of a sales contract provided by the dealership, local state licensing and registration documents provided by the Department of Motor Vehicles or Department/Secretary of State, a financing contract provided by a lender and an extended warranty provided by a separate external company. This is of course just an example, and the specific documents and sources vary based on the nature of the transaction, the state in which it occurs, the financing plan, the terms/options selected by the customer, etc.

As described in detail below, an electronic transaction management system running on one or more computer system(s) at the dealership and/or in the cloud in conjunction with a custom printer driver enables all of the documents for the entire transaction to be completed, managed and signed electronically, without requiring any ink signatures or processing of paper documents. The customer can start the transaction by browsing the dealer's website, either on his/her own or after being redirected there by a vehicle Original Equipment Manufacturer (OEM). Once the customer has selected a vehicle online and initiated the transaction, the dealer may start the process using the electronic transaction management system.

The electronic transaction management system assembles the electronic documents that will be utilized in the transaction. The dealer will already have electronic versions of at least some of these documents, for example stored in a database or file system. For example, the dealer will typically have blank electronic copies of the current versions of its own sales and leasing contracts, as well as current versions of the state licensing and registration forms. If the dealer does not have a current electronic version of a document to be used in the transaction, in one implementation the electronic transaction management system may automatically obtain one. In this implementation, the electronic transaction management system may obtain new versions of relevant documents when they are made available, and/or may check for updates from time to time as desired. In other embodiments, the dealer or another party may download third party documents as desired, e.g., from target websites.

The documents in question will be in different formats. Some documents such as those created and maintained by the dealer (e.g., sales and leasing contracts) may be in editable, printable formats, such as Portable Document Format (PDF) or the native format of a standard word processor. Such documents may be edited on screen (or programmatically by extracting information concerning the transaction from a database or other source) to fill in transaction specific fields on the document (e.g., the transaction identifier, the customer's name, driver's license number, address, the vehicle identification number, etc.). Other documents are in formats intended to be printed on pre-formatted No Carbon Required (NCR) paper forms (Carbonless Paper), typically known as impact printer forms. An impact printer form is an NCR paper form that is loaded into a special printer called an impact printer, and when the document is printed the instructions to the printer direct the printing of specific fields at specific pre-determined locations on the pre-formatted NCR paper form (for example, printing the customer's name in a pre-formatted box on the paper form labelled “name,” the address in a pre-formatted box on the paper form labelled “address,” etc.). An impact printer form typically comprises multiple copies of NCR paper, so that when the impact printer prints the form, multiple copies are created (e.g., one for the dealer, one for the customer, one for the state, etc.). These forms are typically provided (e.g., sold) to the dealership along with operating software for completing the fields on screen and then printing the form. Impact printer forms are used in transactions such as auto sales for certain documents, such as title and registration related documentation used in some states.

An impact printer generally works by direct contact of an ink ribbon with paper. A metal or plastic head strikes the ink ribbon, whereby the ribbon is pressed against the paper and the desired character (letter, digit, dot, line) impression is printed on the sheet. Because of the force of the impact of the print head, impact printers are well suited to printing multiple page NCR paper copies. Prior to the adaptation of these forms for use in impact printers, the forms were completed by typing the information into the given boxes using a typewriter. The use of an impact printer to complete a form is a technological improvement over typing. Nonetheless, the fixed nature of impact printer forms intended for the printing of specific fields at specific pre-determined locations on the pre-formatted NCR paper requires that a new impact form be provided by the source (e.g., the Department of Motor Vehicles or the like) whenever any change is made to the form (e.g., if the positions of the boxes to be completed are moved, or if a new field is required in a new version of the form). Conventionally, different impact forms are supplied by different parties and differ across different geolocations as well. Conventionally, any and all impact printer forms used in a transaction are printed out, and then must be ink signed by the relevant parties to the transaction in pre-formatted signature boxes.

In some implementations, the electronic transaction management system automates and greatly improves this process by sending documents that are used in the transaction, regardless of the source or format, to a custom printer driver. As described in detail below, the custom printer driver receives the instructions to print each document, for example in a standard language used to control printers. Instead of printing the document, the custom printer driver interprets the print instructions to create a file in a standard format (e.g., PDF), containing the document. In the case of a document sent to the printer driver that is already in editable format, the custom printer driver simply saves the contents of the document into a file in the target standard format, e.g., a PDF file.

For impact printer forms and the like, the electronic transaction management system can create an electronic version of each impact printer form one time (e.g., by scanning or otherwise digitizing the paper form), and then use that copy multiple times, whenever that form is used in a transaction. When an instance of an impact printer form is used in a specific transaction, the electronic transaction management system may send instructions for printing specific fields of the specific document at pre-determined locations on a pre-formatted paper form to the custom printer driver. As with any type of form, instead of printing the document the custom printer driver interprets the print instructions to create a file in the standard format (e.g., PDF) containing the document. In the case of an impact form, instead of printing the specific document, the custom printer driver may add the specific fields of the specific document at the correct locations to a file in the standard format containing an electronic representation of the pre-formatted paper form. This representation of the pre-formatted paper form was created one time and may be used multiple times, as described above.

Regardless of the format and source of the document, a file containing the document in a standard format now exists. The specific fields of the documents can be automatically filled in with information concerning the transaction, taken automatically either from the dealer's records (e.g., in a database), from another source, and/or typed into an electronic representation of the document displayed on a computer screen. In the case of information concerning the customer, at the initiation of the transaction the customer may upload his/her driver's license to the dealership (e.g., using a web browser or a provided app for interfacing with and monitoring the transaction). The customer may also upload an authorization to complete the transaction electronically. Other content added to the documents can be information concerning the dealership, the vehicle being purchased or leased, licensing or other information from a government agency, information identifying the transaction itself, etc.

The completed electronic documents in the standard format may be electronically routed to the appropriate parties for electronic signature (e.g., the sales manager, financing manager, customer, etc.). The relevant parties may electronically sign the documents, thus completing the documentation for the transaction end-to-end, without requiring any ink signatures or paper documents, and without requiring the customer to physically come into the dealership. Once the transaction is completed, the vehicle may be delivered to the customer.

The electronic transaction management system can save all of the files used in the transaction, for example in directory or other location in a file system associated with the transaction. In another implementation, the contents of the files making up the transaction may be stored as a record in a database system or the like.

In one implementation, the electronic transaction management system may analyze the form itself and determine which type of content is associated with which box on the form. In this implementation the system may add metadata to the electronic representations of the pre-formatted paper forms, such that metadata identifies which type of content is associated with which specific pre-determined locations (e.g., this box is for entry of the customer's name, this box is for entry of the vehicle identification number, etc.). This enables the editing of the layout of the electronic representation of the pre-formatted paper, while preserving the metadata identifying specific content associated with specific locations on the edited form.

In another implementation, the electronic transaction management system can add metadata to the files in the standard format associated with the transaction, such that the metadata identifies types of content associated with specific fields (e.g., this field contains the customer's driver's license number, this field contains the transaction identifier, etc.). The electronic transaction management system can then save specific fields of specific ones of the files in the standard format associated with the transaction as a single record. In one implementation, this record is stored on a publicly accessible transaction log, such as a blockchain (e.g., Bitcoin, Ethereum, etc.).

Although this summary uses the purchase or lease of a vehicle from an automobile dealership as an example of a transaction, it is to be understood that the functionality of the electronic transaction management system and the custom printer driver may be utilized in the context of other types of transactions as desired.

The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages may be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network environment in which an electronic transaction management system can operate, according to some implementations.

FIG. 2 illustrates the operation of an electronic transaction management system, according to some implementations.

FIG. 3 illustrates another implementation of the operation of an electronic transaction management system, in which content concerning a completed transaction is stored on a blockchain.

FIG. 4 illustrates a computer system suitable for implementing an electronic transaction management system, according to some implementations.

The Figures depict various implementations for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that other implementations of the structures and methods illustrated herein may be employed without departing from the principles described herein.

DETAILED DESCRIPTION

FIG. 1 is a high-level block diagram illustrating an exemplary network architecture 100 in which an electronic transaction management system 101 can be implemented. The illustrated network architecture 100 comprises multiple servers 105A and 105N (together may be referred to as “server 105”) as well as multiple clients 103A, 103B, and 103N (together may be referred to as “client 103”). In FIG. 1, a frontend component 101_FRONTEND of the electronic transaction management system 101 is illustrated as residing on the client 103A, and a backend component 101_BACKEND of the electronic transaction management system 101 and a database system 111 are illustrated as residing on the server 105A. In one implementation, server 105A can be in the form of a backend server 105 made available by, e.g., a publisher of the electronic transaction management system 101. Cloud storage 115 is illustrating as residing on the server 105N. Cloud storage 115 may be in the form of, e.g., secure storage provided by, e.g., Amazon Web Services (AWS) or another cloud provider. A client agent 109 is illustrated as running on each of clients 103B-N. It is to be understood that this is an example only. In various implementations, various functionalities of electronic transaction management system 101 can be instantiated on a server 105, a client 103, or can be distributed among multiple servers 105 and/or clients 103. Additionally, although the database system 111 and cloud storage 115 are each illustrated as residing on a single server (105A and 105N respectively), it is to be understood that the database system 111 and/or the cloud storage 115 may (and often will) be distributed across multiple computing devices.

In FIG. 1 a custom printer driver 113 is illustrated as being a part of the frontend component of electronic transaction management system 101_FRONTEND. It is to be understood that in some implementations the custom printer driver 113 may be instantiated separately from rather than as a part of the electronic transaction management system 101, or the functionalities of these systems may be distributed in other ways between different applications and systems as desired.

The clients 103B-N can be in the form of computing devices operated by users (e.g., customers). A user of a client computing device 103 can interact with the backend component electronic transaction management system 101_BACKEND, for example by operating the client agent 109. A client agent 109 may be in the form of an application containing user-level functionality for utilizing and/or interacting with the electronic transaction management system 101. In some implementations, client agents 109 are not utilized. Clients 103B-N can be in the form of laptops, desktops and/or other types of computers/computing devices such as mobile computing devices capable of connecting to a network 115 and running applications (e.g., smartphones, tablet computers, wearable computing devices, etc.). Clients 103B-N are able to access the electronic transaction management system 101 over the network 115 via, for example, the client agent 109, a web browser or other client software (not shown).

Clients 103 and servers 105 can be implemented using computer systems 210 such as the one illustrated in FIG. 4 and described below. The clients 103 and servers 105 are communicatively coupled to a network 107, for example via a network interface 248 as described below in conjunction with FIG. 4. Servers 105 can be in the form of, e.g., desktop and/or rack-mounted computing devices, located, e.g., in IT departments and/or data centers. Although FIG. 1 illustrates three clients 103 and two servers 105 as an example, in practice many more (or fewer) clients 103 and/or servers 105 can be deployed. In one implementation, the network 107 is in the form of the Internet. Other and/or additional networks 107 or network-based environments can be used in other implementations.

FIG. 2 illustrates a frontend component of the electronic transaction management system 101_FRONTEND and custom printer driver 113 running in the system memory 217 of client 103A, the backend component of the electronic transaction management system 101_BACKEND and a database system 111 running in the system memory of server 105A, and cloud storage 115 residing on server 105N. As described above, the functionalities of the electronic transaction management system 101 and the custom printer driver 113 can be distributed among multiple computer systems 210, including within a cloud-based computing environment in which the functionalities of the electronic transaction management system 101 are provided as a service over a network 107. It is to be understood that although the frontend and backend of the electronic transaction management system 101, the custom printer driver 113 and the client agents 109 are illustrated in the Figures as discrete entities, the illustrated electronic transaction management system 101, custom printer driver 113 and client agents 109 represent collections of functionalities, which can be instantiated as a single or multiple modules on one or more computing devices 210 as desired.

It is to be understood that the functionalities of the electronic transaction management system 101, custom printer driver 113 and client agents 109 can be instantiated (for example as object code or executable images) within the system memory 217 (e.g., RAM, ROM, flash memory) of any computer system 210, such that when the processor 214 of the computer system 210 processes a module, the computer system 210 executes the associated functionality. As used herein, the terms “computer system,” “computer,” “client,” “client computer,” “server,” “server computer” and “computing device” mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of the electronic transaction management system 101, custom printer driver 113 and client agents 109 can be stored on computer-readable storage media. Any form of tangible computer readable storage medium can be used in this context, such as magnetic or optical storage media. As used herein, the term “computer-readable storage medium” does not mean an electrical signal separate from an underlying physical medium.

As illustrated in FIG. 2, the electronic transaction management system 101 can automatically manage multiple electronic documents utilized in a given transaction. In the description of FIGS. 2-3, the purchase or lease of a vehicle is used as an example of a transaction. As explained above this is just an example, and the functionality of the electronic transaction management system 101 may be utilized in the context of other types of transactions as desired. In the example described in conjunction with FIGS. 2-3, the purchase of a vehicle is in the context of such a purchase being made from an auto dealership, by an individual customer. As described above, a plurality of different types of electronic documents in different formats and from different sources may be used in such a transaction, such as, for example, a sales or lease contract provided by the dealer, one or more licensing document(s) provided by a government agency of the state in which the transaction is occurring, and one or more additional documents provided by at least one third party, such as financing or warranty documents.

As explained above, the custom printer driver 113 may be installed at the dealership as part of the frontend of the electronic transaction management system 101_FRONTEND. In the context of the operation of the electronic transaction management system 101, the term “custom printer driver” is used to mean a collection of functionalities instantiated that facilitates sending a document to a selected printer from the frontend of the electronic transaction management system 101_FRONTEND, with the document being converted into instructions to a printer for printing the specific document, and subsequently, instead of actually printing the document, creating a file in a standard format 203 (e.g., PDF) containing the document, based on the received instructions to the printer for printing the specific document. In many implementations the custom printer driver 113 is instantiated in software, although a custom printer driver 113 may be instantiated as software, hardware, firmware or any combination of the three.

A conventional printer driver may be thought of as functionality (typically although not necessarily instantiated in software) that enables an application or system program on a computer to communicate with a printer. Because the custom printer driver 113 does not actually print the documents, the term “custom printer driver” is being used herein with a non-conventional meaning. The custom printer driver 113 enables an application program to specially process documents as described herein by sending them to a printer, although the end result is not printing the documents. As described in detail below, in some implementations the custom printer driver 113 utilizes conventional printer drivers to execute some of its functionalities, for example converting the contents of a file sent to the printer into instructions to a printer for printing that content.

In one implementation, the custom printer driver 113 includes multiple installed conventional printer drivers for printing documents in different formats (for example a printer driver that supports printing impact forms 201 to an impact printer, and a printer driver that supports printing documents in a standard format 203, such as PDF). Contemporary available operating systems such as Microsoft Windows provide such printer drivers for download. In this implementation, when a party operating the frontend of the electronic transaction management system 101_FRONTEND wishes to provide an electronic document to the customer printer driver 113 for processing as a part of the transaction, the party (e.g., a sales manager at the automobile dealership) may open the document, select print, and select an appropriate target printer (e.g., print “Impact Form to Transaction” for an impact form 201, print “To Transaction” for a PDF or word processing document). It is to be understood that the names given to the target printers given above are just examples, and other names may be assigned in other implementations as desired. Sending the document to the target printer may result in the contents of the document being sent to a corresponding conventional printer driver (e.g., for printing impact forms 201 or documents in a standard format 203) which translates the contents of the file into instructions for a corresponding printer to print the specific document. In the case of an impact form 201, those instructions can be in the form of a file in a printer control language containing instructions for printing specific fields of the specific document at pre-determined locations on a pre-formatted paper form. A file in such a format contains the text itself, as well as control characters for moving the print head to specific locations before printing corresponding content. This format can be, for example, Epson Standard Code for Printers or XML Paper Specification (XPS), although different printer control languages can be used in different implementations. In the case of a document in PDF or Word format or the like, the instructions for a corresponding printer may be in, for example, PostScript (PS) or another page description language. Where the file is a PDF, it is already in PS and does not need to be translated. Where the file is, e.g., a .docx file, it may be translated to PS, for example by the corresponding underlying conventional printer driver.

The custom printer driver 113 may receive the output of the conventional printer driver(s) (i.e., the instructions to a printer for printing specific documents). Instead of sending that output to any printer, the custom printer driver 113 may create, for each given document, a file in a standard format 203 such as PDF containing the specific document, based on the received instructions to the printer for printing that document. In one implementation, files in a printer control language (e.g., instructions for printing impact forms 201) are placed in a given directory or folder. The custom printer driver 113 reads that directory, and detects new files that have been placed there, thus receiving the instructions to the printer. Based on the these received instructions to the printer for a given document, the custom printer driver 113 can parse the file in printer control language, and write the specific fields of the specific document to a file in a standard format 203 such as PDF containing an electronic representation of the pre-formatted paper form, at the pre-determined locations. To do so, the electronic transaction management system 101 can create an electronic representation of the pre-formatted paper form in the standard format one time (e.g., by scanning the given impact form 201 to a PDF file), store the created electronic representation of the pre-formatted paper form, and then use a copy of the created form whenever instructions to print given content to that specific form are being processed. When parsing the file in printer control language, the custom printer driver 113 interprets the control characters that direct the movement of the print head to a specific location on the paper form prior to printing corresponding text, and uses those instructions to locate the corresponding location in the PDF file at which to place the textual content. The custom printer driver 113 then writes the content to that location in the PDF file. The result is an editable document in the standard format 203 such as PDF, containing the content of the impact printer form 201, with the textual content that was sent to the printer filled in at the appropriate locations. In the case of instructions to print laser ready documents such as PDF or Word files, the corresponding conventional printer driver may output content in PS format describing the document (e.g., as a PDF file), which the custom printer driver 113 can then process.

In some implementations, when the electronic transaction management system 101 creates an electronic representation of a pre-formatted paper form in the standard format as described above, the electronic transaction management system 101 can also add metadata to the electronic representation of the pre-formatted paper form, such that the metadata identifies specific content associated with specific pre-determined locations. For example, the metadata could identify what type of text is to be placed in or at some or all boxes or other pre-formatted objects on the form (i.e., one specific box is for the customer's name, another specific box is for the customer's address, etc.). Such metadata enables the editing the electronic representation of the pre-formatted paper form, for example by moving the position of pre-formatted objects on the form as desired, while preserving the metadata identifying associated specific content.

The electronic transaction management system 101 may automatically add content concerning the transaction to one or more corresponding fields of a file containing a specific document in the standard format 203, whether the file originated from an impact form 201 or otherwise. Such content may be present in the electronic records of the dealership, in which case the electronic transaction management system 101 may automatically glean that content from the dealership's records (e.g., by reading a local database or filesystem). In other cases, the provider of the electronic transaction management system 101 may create and/or maintain records with information concerning transactions. In this scenario, relevant content may be automatically supplied by the backend of electronic transaction management system 101_BACKEND. In some cases, content concerning the transaction provided by a human user operating a computing device may be automatically added to a document, such as information typed in by a sales manager at the dealership. In some implementations, the electronic transaction management system 101 may automatically retrieve desired information from additional third party data sources as desired.

As an example of content concerning the transaction being automatically added to a document, content concerning the customer participating in the transaction may be added to at least one corresponding field of a file containing a specific document. Such content may include the customer's name, address, driver's license number, etc. Another example of content concerning the transaction that can be automatically added to a document is content concerning a merchant participating in the transaction, such as the name of the auto dealership, the dealership's address, licensing information concerning the dealership, etc. Content concerning an item being purchased or leased in the transaction can also be automatically added to a document, such as the vehicle identification number, make, model, year, color, options, etc. Another example of content is information provided by a governing agency to the transaction, such as the DMV or the like. In such cases, the information may be gleaned and managed by the backend of electronic transaction management system 101_BACKEND. Content identifying the specific transaction may also be added to the document, such as a transaction number or the like.

The electronic transaction management system 101 may receive one or more electronic signatures for various specific documents concerning the transaction, and add those electronic signatures to the documents in the standard format 203 (e.g., PDF) at the appropriate location (e.g., the signature block for the signing party). More specifically, where a document is to be signed, the electronic transaction management system 101 may automatically route the document to the parties whose signatures are required (e.g., the sales manager at the auto dealership, the customer, etc.) and request electronic signatures. For example, to route the document to the sales manager, the electronic transaction management system 101 can notify the sales manager via the user interface of the frontend component of electronic transaction management system 101_FRONTEND. The electronic transaction management system 101 may also notify the sales manager to e-sign the document by sending an email, instant message, etc. In the case of a customer, the electronic transaction management system 101 can notify the customer to e-sign a document via the interface of the client agent 109, which is on, for example, the customer's phone or laptop. The client agent 109 can use notifications to get the customer's attention. In addition or instead, the electronic transaction management system 101 may also notify/remind the customer to e-sign the document by sending a text, email, etc. Once an electronic-signature has been obtained, the electronic transaction management system 101 may automatically add the electronic signature to a corresponding location of the document. The process can be utilized to obtain all of the requisite electronic signatures for all of the documents that are part of the transaction, in the standard format (e.g., PDF files).

The electronic transaction management system 101 may then save the files containing all of the specific documents associated with the transaction, in the standard format, with the added content concerning the transaction and the electronic signature(s). In some implementations, the electronic transaction management system 101 associates each such file with the transaction, for example by adding or otherwise associating a transaction number or the like to or with the file. Such files may be stored, for example, as a database record associated with the transaction, or at a location in a file system associated with the transaction. Such electronic storage may be on backend server(s), in the cloud, at the dealership, or at other location(s) as desired.

FIG. 3 illustrates another implementation of the operation of an electronic transaction management system, in which content concerning a completed transaction is stored on a blockchain 301. In some implementations, the electronic transaction management system 101 adds metadata to the files in the standard format associated with the transaction, where metadata identifies types of content associated with specific fields. For example, the metadata could identify one field in a file as the name of the customer, another as the transaction identifier, another as the vehicle identification number, etc. In such as implementation, the electronic transaction management system 101 may automatically extract the content of specific fields of specific ones of the files associated with the transaction, and store them as a single record, for example on a publicly accessible transaction log. In other words, instead of (or in addition to) storing all of the files associated with the transaction, the electronic transaction management system 101 may extract desired fields from the files, and store the resulting extracted data concerning the transaction 303 as a single record. It is to be understood that which specific fields to extract from which specific documents is a variable design parameter, which can change between different implementations and scenarios as desired. In some implementations, the publicly accessible transaction log is in the form of a blockchain 301 such as Bitcoin or Ethereum.

FIG. 4 is a block diagram of an example computer system 210 suitable for implementing an electronic transaction management system 101. Both endpoint computing devices 103 and backend computer systems can be implemented in the form of such computer systems 210. As illustrated, one component of the computer system 210 is a bus 212. The bus 212 communicatively couples other components of the computer system 210, such as at least one processor 214, system memory 217 (e.g., random access memory (RAM), read-only memory (ROM), flash memory), an input/output (I/O) controller 218, an audio output interface 222 communicatively coupled to an audio output device such as a speaker 220, a display adapter 226 communicatively coupled to a video output device such as a display screen 224, one or more interfaces such as Universal Serial Bus (USB) receptacles 228, serial ports 230, parallel ports (not illustrated), etc., a keyboard controller 233 communicatively coupled to a keyboard 232, a storage interface 234 communicatively coupled to one or more hard disk(s) 244 (or other form(s) of storage media), a host bus adapter (HBA) interface card 235A configured to connect with a Fiber Channel (FC) network 290, an HBA interface card 235B configured to connect to a SCSI bus 239, an optical disk drive 240 configured to receive an optical disk 242, a mouse 246 (or other pointing device) coupled to the bus 212, e.g., via a USB receptacle 228, a modem 247 coupled to bus 212, e.g., via a serial port 230, and one or more wired and/or wireless network interface(s) 248 coupled, e.g., directly to bus 212.

Other components (not illustrated) may be connected in a similar manner (e.g., document scanners, digital cameras, printers, etc.). Conversely, all of the components illustrated in FIG. 4 need not be present (e.g., smartphones and tablets typically do not have optical disk drives 240, external keyboards 232 or external pointing devices 246, although various external components can be coupled to mobile computing devices via, e.g., USB receptacles 228). The various components can be interconnected in different ways from that shown in FIG. 4.

The bus 212 allows data communication between the processor 214 and system memory 217, which, as noted above may include ROM and/or flash memory as well as RAM. The RAM is typically the main memory into which the operating system 250 and application programs are loaded. The ROM and/or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls certain basic hardware operations. Application programs can be stored on a local computer readable medium (e.g., hard disk 244, optical disk 242) and loaded into system memory 217 and executed by the processor 214. Application programs can also be loaded into system memory 217 from a remote location (i.e., a remotely located computer system 210), for example via the network interface 248 or modem 247. In FIG. 4, the electronic transaction management system 101 is illustrated as residing in system memory 217.

The storage interface 234 is coupled to one or more hard disks 244 (and/or other standard storage media). The hard disk(s) 244 may be a part of computer system 210 or may be physically separate and accessed through other interface systems.

The network interface 248 and/or modem 247 can be directly or indirectly communicatively coupled to a network 115 such as the internet. Such coupling can be wired or wireless.

As will be understood by those familiar with the art, the subject matter described herein may be embodied in other specific forms without departing from the spirit or integral characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, data structures and other aspects are not mandatory or significant, and the entities used that implement the subject matter described herein may have different names, divisions and/or formats. The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen and described in order to best explain relevant principles and their practical applications, to thereby enable others skilled in the art to best utilize various implementations with or without various modifications as may be suited to the particular use contemplated.

In some instances, various implementations may be presented herein in terms of algorithms and symbolic representations of operations on data bits within a computer memory. An algorithm is here, and generally, conceived to be a self-consistent set of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, bytes, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout this disclosure, discussions utilizing terms including “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Finally, the structure, algorithms, and/or interfaces presented herein are not inherently tied to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the method blocks. The structure for a variety of these systems will appear from the description above. In addition, the specification is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the specification as described herein.

Accordingly, the disclosure is intended to be illustrative, but not limiting.

Claims

1. A computer implemented method for automatically managing a plurality of electronic documents utilized in a transaction, the method comprising: for separate ones of the documents of the plurality of documents: receiving, by a custom printer driver, instructions to a printer for printing the specific document;instead of printing the specific document, creating, by the custom printer driver, a file in a standard format containing the specific document, based on the received instructions to the printer for printing the specific document;automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format;receiving at least one electronic signature for the specific document;automatically adding the at least one electronic signature to at least one corresponding location of the specific document in the standard format;saving the file containing the specific document in the standard format with the added content concerning the transaction and the at least one electronic signature; andassociating the file containing the specific document in the standard format with the transaction.

2. The method of claim 1 wherein the plurality of electronic documents utilized in the transaction further comprises: different documents originating from multiple separate sources.

3. The method of claim 1 wherein the plurality of electronic documents utilized in the transaction further comprises: different documents in multiple separate formats.

4. The method of claim 1 wherein received instructions to the printer for printing a given specific document of the plurality of electronic documents utilized in the transaction further comprise: instructions for printing specific fields of the specific document at pre-determined locations on a pre-formatted paper form.

5. The method of claim 4 further comprising: instead of printing the specific document, adding, by the custom printer driver, the specific fields of the specific document to a file in the standard format containing an electronic representation of the pre-formatted paper form, at the pre-determined locations.

6. The method of claim 4 further comprising: creating an electronic representation of the pre-formatted paper form one time; andusing the created electronic representation of the pre-formatted paper form multiple times.

7. The method of claim 6 further comprising: adding metadata to the electronic representation of the pre-formatted paper form, the metadata identifying specific content associated with specific pre-determined locations.

8. The method of claim 6 further comprising: editing the electronic representation of the pre-formatted paper form.

9. The method of claim 8 wherein editing the electronic representation of the pre-formatted paper form further comprises: editing an electronic representation of a pre-determined location while preserving metadata identifying associated specific content.

10. The method of claim 4 wherein the pre-formatted paper form from comprises: an impact printer form.

11. The method of claim 1 wherein the standard format comprises: a Portable Document Format (“PDF”) file.

12. The method of claim 1 further comprising: adding metadata to the files in the standard format associated with the transaction, the metadata identifying types of content associated with specific fields.

13. The method of claim 12 further comprising: saving specific fields of specific ones of the files in the standard format associated with the transaction as a single record on a publicly accessible transaction log.

14. The method of claim 13, wherein the publicly accessible transaction log is a blockchain.

15. The method of claim 14, wherein the blockchain is Bitcoin.

16. The method of claim 14, wherein the blockchain is Ethereum.

17. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content concerning a customer participating in the transaction to at least one corresponding field of the file containing the specific document in the standard format.

18. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content concerning a merchant participating in the transaction to at least one corresponding field of the file containing the specific document in the standard format.

19. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content concerning an item being purchased or leased in the transaction to at least one corresponding field of the file containing the specific document in the standard format.

20. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content being provided by a governing agency to the transaction to at least one corresponding field of the file containing the specific document in the standard format.

21. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content concerning the transaction retrieved from a database, to at least one corresponding field of the file containing the specific document in the standard format.

22. The method of claim 1 wherein automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format further comprises: automatically adding content concerning the transaction provided by a human user operating a computing device, to at least one corresponding field of the file containing the specific document in the standard format.

23. The method of claim 1 wherein associating the file containing the specific document in the standard format with the transaction further comprises: adding content identifying the transaction to the file containing the specific document in the standard format.

24. The method of claim 1 wherein associating the file containing the specific document in the standard format with the transaction further comprises: storing contents of the file containing the specific document in the standard format as a record in a database associated with the transaction.

25. The method of claim 1 wherein associating the file containing the specific document in the standard format with the transaction further comprises: storing the file containing the specific document in the standard format at a location in a file system associated with the transaction.

26. The method of claim 1 wherein the transaction further comprises: a purchase or lease of a vehicle.

27. The method of claim 26 wherein the purchase or lease of the vehicle comprises: a purchase or lease of an automobile, from an auto dealership, by an individual customer.

28. The method of claim 27 wherein the plurality of electronic documents utilized in the transaction further comprise at least: a sales or lease contract provided by the dealer, at least one licensing document provided by a government agency of the state in which the transaction is occurring, and at least one additional document provided by at least one additional party.

29. At least one non-transitory computer-readable storage medium for automatically managing a plurality of electronic documents utilized in a transaction, the at least one non-transitory computer-readable storage medium storing computer executable instructions that, when loaded into computer memory and executed by at least one processor of a computing device, cause the computing device to perform the following steps: for separate ones of the documents of the plurality of documents: receiving, by a custom printer driver, instructions to a printer for printing the specific document;instead of printing the specific document, creating, by the custom printer driver, a file in a standard format containing the specific document, based on the received instructions to the printer for printing the specific document;automatically adding content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format;receiving at least one electronic signature for the specific document;automatically adding at least one electronic signature to at least one corresponding location of the specific document in the standard format;saving the file containing the specific document in the standard format with the added content concerning the transaction and at least one electronic signature; andassociating the file containing the specific document in the standard format with the transaction.

30. A computer system for automatically managing a plurality of electronic documents utilized in a transaction, the computing device comprising: at least one processor;system memory;a custom printer driver residing in the system memory, the custom printer driver being configured to, for separate ones of the documents of the plurality of documents, receive instructions for printing the specific document, and instead of printing the specific document, to create a file in a standard format containing the specific document, based on the received instructions to the printer for printing the specific document;a content adding module residing in the system memory, the content adding module being configured to, for separate ones of the documents of the plurality of documents, automatically add content concerning the transaction to at least one corresponding field of the file containing the specific document in the standard format;an electronic-signature processing module residing in the system memory, the electronic-signature processing module being configured to, for separate ones of the documents of the plurality of documents, receive at least one electronic-signature for the specific document, and to automatically add the at least one electronic-signature to at least one corresponding location of the specific document in the standard format;a document saving module residing in the system memory, the document saving module being configured to, for separate ones of the documents of the plurality of documents, save the file containing the specific document in the standard format with the added content concerning the transaction and the at least one electronic signature; andan association module residing in the system memory, the association module being configured to, for separate ones of the documents of the plurality of documents, associate the file containing the specific document in the standard format with the transaction.