Automatic document reader and form population system and method

FIELD OF THE INVENTION

0001The present invention generally relates to identification systems for documents. More particularly, the present invention relates to a system and method for reading and/or verifying the authenticity of identification documents such as a drivers' license, credit card or Government issued ID and utilizing the data from such identification documents to populate fields in ancillary documents or forms.

BACKGROUND OF THE INVENTION

0002Over the course of years, various attempts have been made to prevent or detect the use of fake identification cards, but not with a great deal of success. In 1986 with the implementation of the Commercial Motor Vehicle Safety Act (legislation aimed at dealing with the ever-growing problem of multiple licenses being held by one driver) a number of security loopholes were identified and a concerted effort was made to tighten up the process and the driver license documents. The American Association of Motor Vehicle Administrators (trade association representing the various license issuing authorities in the United States and Canada) introduced best practices (Uniform Identification Practices Model Program) that eventually became standards (DL/ID Security Framework). These new driver licenses/identification cards have embedded coded, or even encrypted coded information, with machine-readable formats that attempt to conform to the AAMVA standards. The U.S. federal government (Department of Homeland Security) has now passed a law (REAL ID) that will likely impact what the various states are doing not just with their driver license documents but the processes that exist around the issuance.

0003It is desirable to provide a means to verify the authenticity of identification documents and provide a robust population mechanism that can utilize the data to populate fields in ancillary forms thereby safeguarding businesses/organizations that rely on such information against losses/crimes that may otherwise be encountered in connection with the use of fake identification cards. It is generally known to provide script based keyboard macros with various types of input data to populate forms and/or otherwise assist in data entry. For example, keyboard macros can allow short sequences of keystrokes to substitute for long sequences of commands. Similarly, keyboard scripts can automate repetitive tasks automatically by sending pre-programmed sets of keystrokes and/or data from various input devices. However such scripts and/or macros suffer from several deficiencies. For example, it can be difficult for the user to fashion a robust script that can tolerate a variety of conditions and still function adequately. Often a minor change in a form can cause the script to malfunction. Similarly, a mouse or keystroke input by a user while the script is running can cause erroneous population of data. To this end, the invention encompasses a system and method to verify the authenticity of identification documents and a robust population mechanism that can utilize the data to populate fields in ancillary forms thereby increasing the confidence in the ancillary form. Such forms can include on-line applications for permits, licenses, credit applications and the like.

BRIEF SUMMARY OF THE INVENTION

0004The invention is directed to a system and method for automatic population of a form with data from an identification document. The system has a computer and identification document reader or card scanner coupled to the computer. The card scanner is operable to read machine-readable indicia (e.g., magnetic stripe, bar codes, smart card) from one or more identification documents (e.g., driver's licenses, credit cards, Government issued IDs such as Military IDs, passports and the like). The system stores at least one population definition that maps at least one form field to an identification document field. At least one machine readable indicia is read from the identification document, the machine readable indicia representing at least one field from the identification document. The invention verifies the authenticity of the identification document and at least one identification document field is populated into the appropriate form field based on the population definition.

BRIEF DESCRIPTION OF THE DRAWINGS

0005For a better understanding of the present invention, reference is made to the following description and accompanying drawings, while the scope of the invention is set forth in the appended claims:

0006<figref idref="DRAWINGS">FIG. 1</figref> shows an exemplary system diagram in accordance with the invention;

0007<figref idref="DRAWINGS">FIG. 2</figref> shows a block diagram illustrating exemplary operation of a system in accordance with the invention;

0008<figref idref="DRAWINGS">FIG. 3</figref> shows a block diagram of an exemplary device controller module in accordance with the invention;

0009<figref idref="DRAWINGS">FIG. 4</figref> shows a block diagram of an exemplary Jurisdiction engine module in accordance with the invention;

0010<figref idref="DRAWINGS">FIG. 5</figref> shows a block diagram of an exemplary device service module in accordance with the invention;

0011<figref idref="DRAWINGS">FIG. 6</figref> shows a block diagram of an exemplary form filler module in accordance with the invention;

0012<figref idref="DRAWINGS">FIG. 7</figref> shows a block diagram of an exemplary configuration module in accordance with the invention;

0013<figref idref="DRAWINGS">FIG. 8</figref> shows an exemplary display screen showing configuration information with multiple document types in accordance with the invention;

0014<figref idref="DRAWINGS">FIG. 9</figref> shows an exemplary display screen showing configuration information for an exemplary Driver's License identification document in accordance with the invention;

0015<figref idref="DRAWINGS">FIG. 10</figref> shows an exemplary display screen showing additional configuration information for an exemplary Driver's License identification document in accordance with the invention;

0016<figref idref="DRAWINGS">FIG. 11</figref> shows an exemplary display screen showing menu information in accordance with the invention;

0017<figref idref="DRAWINGS">FIG. 12</figref> shows an exemplary display screen showing a translation definition for an exemplary Driver's License identification document in accordance with the invention; and

0018<figref idref="DRAWINGS">FIG. 13</figref> shows an exemplary display screen showing various system settings in accordance with the invention.

DETAILED DESCRIPTION OF THE INVENTION

I. Overview

0019<figref idref="DRAWINGS">FIG. 1</figref> shows an exemplary system diagram in accordance with the invention. In operation, the system <b>10</b> is operable to read one or more identification documents, and utilize the data from such documents to automatically populate one or more fields contained in a form <b>40</b>. The system <b>10</b> has a computer <b>20</b> and an identification document reader or card scanner <b>60</b> shown coupled to computer <b>20</b> via path <b>62</b>. Card scanner <b>60</b> is coupled to computer <b>20</b> via conventional means that are well known in the art (e.g., serial, parallel, wired, wireless and the like). Card scanner <b>60</b> is preferably operable to read machine readable indicia (e.g., magnetic stripe, bar codes, smart card and the like) from one or more identification documents <b>50</b> (e.g., driver's licenses, credit cards, Government Issued IDs and the like). Aside from typical software associated with a computing device such as an operating system, browser and the like (not shown), computer <b>20</b> also has associated form filling software <b>30</b>. In this example, the form filling software is divided into several modules namely, a configuration module <b>33</b>, one or more form filler modules <b>34</b>, a device service module <b>35</b>, a jurisdiction engine module <b>36</b>, and a device controller module <b>37</b>.

0020Computer <b>20</b> also has access to one or more forms <b>40</b>. In this example, each form is associated with a single instance of a form filler module (e.g., <b>34</b> and <b>40</b>, <b>34</b>′ and <b>40</b>′, <b>34</b>″ and <b>40</b>″ . . . ). It is understood that the precise number of forms <b>40</b> and associated form filler modules <b>34</b> may vary depending on the particular implementation. Computer <b>20</b> is optionally coupled to one or more networks <b>70</b> (e.g., LAN, WAN, Internet and the like) via path <b>22</b>. One or more remote computers or servers <b>80</b>. <b>80</b>′, <b>80</b>″, operable to communicate with computer <b>20</b> may also be optionally connected to network <b>70</b> as shown by paths <b>82</b>, <b>82</b>′, and <b>82</b>″. The connection between computers (e.g., <b>20</b>, <b>80</b>, <b>80</b>′, <b>80</b>″) and network <b>70</b> can be carried out conventional techniques as is well known in the art.

0021<figref idref="DRAWINGS">FIG. 2</figref> shows a block diagram illustrating exemplary operation of a system in accordance with the invention. The card scanner <b>60</b> is generally operable to read machine-readable indicia from an identification document <b>50</b>. The identification document <b>50</b> includes a set of fields <b>51</b> related to the entity subject to identification. In the current example, the card scanner <b>60</b> extracts raw data from the identification document (e.g., parsing, data extraction and the like are carried out via other system components). The card scanner <b>60</b> sends or communicates the raw data to device controller <b>37</b>. In the absence of any errors, device controller <b>37</b> is operable to communicate the raw data to the jurisdiction engine <b>36</b>. The jurisdiction engine generally extracts useful portions of data from the raw data and communicates the data and verification status back to the device controller <b>37</b>. The device controller <b>37</b> then communicates the data and verification status to the device service module <b>35</b>. Assuming no errors are detected, the device service module is operable to receive the data and verification status from the device controller and distribute the data to one or more form fillers <b>34</b>. The form filler <b>34</b> is operable to populate one or more fields <b>41</b> (e.g., web form fields) in the form <b>40</b>. Configuration module <b>33</b> can optionally access configuration data <b>38</b> and configure or modify various parameters that control, modify or effect operation of the system. A more detailed description of various exemplary system components follows.

II. Device Controller Module

0022<figref idref="DRAWINGS">FIG. 3</figref> shows a block diagram of a device controller module <b>37</b> in accordance with the invention. In general, the device controller receives data from the card scanner, communicates the data to the jurisdiction engine, receives data and verification status from the jurisdiction engine and communicates the data to the device service module. For matters of clarity, <figref idref="DRAWINGS">FIG. 3</figref> illustrates only a portion of the device controller module functionality. For example, <figref idref="DRAWINGS">FIG. 3</figref> is generally depicted as a loop since the device controller typically waits for input before initiating any form of processing. It is understood that other program entry and exit points, time out functions, error checking routines and the like (not shown) would normally be implemented in the device controller. Implementation of these aspects of the device controller are readily apparent and well within the grasp of those skilled in the art.

0023In the current example, the invention is implemented on a MICROSOFT platform and utilizes Component Object Model (COM) and .NET development technologies. It is understood that the invention can be implemented utilizing one or more of a variety of computing environments (e.g., MICROSOFT WINDOWS family, APPLE MAC OS X, PALM OS, and the like). In the current example, the device controller is implemented as an ActiveX DLL.

0024Upon initial execution, the device controller module performs typical initialization tasks. These tasks can include initializing various parameters and initialization of any associated hardware and the like, as represented by block <b>110</b>. In the current example, card scanner <b>60</b> is coupled to the computer <b>20</b> via a serial port (e.g., USB or RS-232 serial communication port—see <figref idref="DRAWINGS">FIG. 1</figref>). It is understood that other interfaces can be used without departing from the scope of the invention. The device controller utilizes well know techniques (e.g., opening and initialization of a COM port) to establish communication with the card scanner. Configuration and initialization of devices such as a card scanner is well known to those skilled in the art.

0025Once initialization is complete control passes to block <b>120</b>, where the device controller waits for raw data input from the card scanner. If the data received from the card scanner is a read error, detected at block <b>130</b>, an appropriate error message is sent to the Device Service module as represented by block <b>140</b>. Control is then passed to block <b>120</b> and the device controller again waits for data from the card scanner. If the data received from the card scanner is not an error message, the data is then sent or communicated to the jurisdiction engine <b>36</b> for further processing as represented by block <b>150</b>. Control is then passed to block <b>160</b> where the device controller waits for data input from the jurisdiction engine (e.g., data and verification status). The data and verification status is then communicated to the device service module <b>35</b> as represented by block <b>170</b>. Control is then passed to block <b>120</b> and the device controller again waits for data from the card scanner.

0026The terms “send” or “communicate” are used in this description in a general sense and are intended to include any type of communication between system components and/or a system user. As outlined above, raw data is communicated from the device controller module to the jurisdiction engine. In the current example, the jurisdiction engine is also implemented as an ActiveX DLL. Accordingly, communication between the device controller and the jurisdiction engine is carried out via ActiveX as is well known in the art. In this example, the device service module is implemented as an ActiveX executable. Accordingly, communication between the device controller and the device service is carried out via ActiveX as is well known in the art.

III. Jurisdiction Engine Module

0027<figref idref="DRAWINGS">FIG. 4</figref> shows a block diagram of a jurisdiction engine module <b>36</b> in accordance with the invention. In general, the jurisdiction engine receives raw data from the device controller, extracts and verifies the data and communicates the data and verification status to the device controller module. For matters of clarity, <figref idref="DRAWINGS">FIG. 4</figref> illustrates only a portion of the jurisdiction engine module functionality. For example, <figref idref="DRAWINGS">FIG. 4</figref> is generally depicted as a loop since the jurisdiction engine typically waits for input before initiating any form of processing. It is understood that other program entry and exit points, time out functions, error checking routines and the like (not shown) would normally be implemented in the jurisdiction engine module. Implementation of these aspects of the jurisdiction engine are readily apparent and well within the grasp of those skilled in the art.

0028The jurisdiction engine can verify the raw data using the techniques disclosed in U.S. Pat. Nos. 5,864,623, 6,463,416, and 6,920,437, which are herein incorporated by reference. For example, typical machine-readable identification documents such as a driver's license contain a set of information fields or segments related to the entity subject to identification. These information fields are organized according to one of a plurality of known formats. The raw data is compared to known organizational formats to determine conformance. Upon making a conformance determination, a particular field can be selected for comparison with a predetermined acceptance criteria. For example, AAMVA compliant documents include an issuing jurisdiction field that is six numeric characters in length, and begins with “6.” Also, other fields can be parsed to determine that they are in the proper format. For example, the fields can be parsed to verify the proper use of delimiters. Some fields can be parsed to verify that the data is within expected ranges.

0029With reference to <figref idref="DRAWINGS">FIG. 4</figref>, upon initial execution, the jurisdiction engine module performs typical initialization tasks. These tasks can include initializing various parameters and the like, as represented by block <b>205</b>. Once initialization is complete control passes to block <b>210</b>, where the jurisdiction engine software waits for data input from the device controller. Once the data is received, it is compared to known organizational formats to identify that particular data format as represented by blocks <b>215</b> and <b>220</b>. If the format cannot be identified, an appropriate verification status is sent to the device controller as shown by block <b>225</b>. Control is then passed to block <b>210</b> and the jurisdiction engine again waits for data from the device controller. If the format of the data received from the card scanner is identified, the data is extracted and verified as represented by block <b>230</b>. The term “extract” as used herein refers to the parsing of the raw data into the appropriate fields corresponding to the identified format. It is understood that only a subset of data may be utilized for further processing. The following example refers to identification documents encoded with AAMVA magnetic stripe data. It is understood that other machine-readable indicia (e.g., bar codes, smart card and the like) can be utilized without departing from the scope of the invention. Typical AAMVA compliant magnetic stripe data is divided into a plurality of tracks each having a plurality of segments or fields including e.g., Track 1: State, City, Name, Address; Track 2: Issuer Identification Number, Drivers License number, Expiration date, Birth date; Track 3: Version number, Security Version number, Postal code, Vehicle Class, Restriction, Endorsements, Sex, Height, Weight, Hair Color, Eye Color, discretionary data.

0030The data is then verified or tested for errors (e.g., the identification document is not expired, verify certain values in certain fields such as M, F or 1, 2 denoting for male or female and the like). If an error is detected an appropriate verification status is set. If no error is detected, then an appropriate verification status is set. The data and verification status are then sent to the device controller as shown by block <b>240</b>. Control is then passed to block <b>210</b> and the jurisdiction engine again waits for data from the device controller module.

IV. Device Service Module

0031<figref idref="DRAWINGS">FIG. 5</figref> shows a block diagram of a device service module <b>35</b> in accordance with the invention. In general the device service module accepts data verification status from the device controller and (assuming the data is verified) sends or communicates the data to one or more form filler modules. For matters of clarity, <figref idref="DRAWINGS">FIG. 5</figref> illustrates only a portion of the device service module functionality. For example, <figref idref="DRAWINGS">FIG. 5</figref> is generally depicted as a loop since the device service typically waits for input before initiating any form of processing. It is understood that other program entry and exit points, time out functions, error checking routines and the like (not shown) would normally be implemented in the device service module. Implementation of these aspects of the device service module software are readily apparent and well within the grasp of those skilled in the art.

0032Upon initial execution, the device service module performs typical initialization tasks. These tasks can include initializing various device service configuration parameters and the like, as represented by block <b>310</b>. Once initialization is complete control passes to block <b>320</b>, where the device service module waits for data and verification status from the device controller. If the data received from the device controller is a read error message (detected at block <b>330</b>), an appropriate user error message is formatted and displayed to the user as represented by block <b>340</b> (e.g., Read Error—please re-swipe card). Control is then passed to block <b>320</b> and the device service module again waits for data from the device controller. Block <b>350</b> illustrates program control based on a device service parameter. For example, the device service module can be configured to ignore data. For example, the device service module can be configured to ignore data based on a invalid or otherwise undesirable processing result. In the alternative, data can be ignored based on the type of identification document (e.g., credit card). If the device service module is configured to send the type of data received from device controller, then control is passed to block <b>360</b>. The data is then sent or communicated to one or more form filler modules and control is passed back to block <b>320</b>. Otherwise, an appropriate user error message (e.g., “Document Verification Failed” or “Please Scan a Driver's License”) is then formatted and displayed to the user as represented by block <b>370</b> and control is then passed back to block <b>320</b>. In this example, each form filler module is implemented as ActiveX DLLs. Accordingly, communication between the device service module and a form filler module is carried out via ActiveX as is well known in the art.

0033a. Device Service Registration—Connection Class

0034As discussed above, the device service module is generally operable to accept verified data from the device controller module and communicate the verified data to one or more form filler modules. Before the device controller can communicate with any external modules, the device service module must be able to locate these modules. Utilizing well-known ActiveX techniques, the device service module can provide a connection class to each of these modules. Accordingly, upon initialization of each instance the form filler module requests a connection class from the device service. Similarly, upon initialization the device service module establishes a connection class with the device controller.

0035b. Exemplary Device Service Parameters

0036As stated above, the device service module may utilize device service parameters to vary its functionality. These parameters can be stored by techniques that are well known in the art. In the current example, device service parameters are stored in an .ini file that is read during initialization. Several exemplary parameters are shown in Table 1 below:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameter</entry><entry /></row><row><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Enabled</entry><entry>When set to “False”, the Device Service module closes the</entry></row><row><entry /><entry>Device Controller down. When set to “True”, the system</entry></row><row><entry /><entry>operates normally.</entry></row><row><entry>ComPort</entry><entry>Upon initialization, the device service module communicates</entry></row><row><entry /><entry>the com port number to the device controller module. The</entry></row><row><entry /><entry>device controller module uses the com port number to connect</entry></row><row><entry /><entry>to the card reader.</entry></row><row><entry>Smartcard</entry><entry>Upon initialization, the device service module communicates</entry></row><row><entry /><entry>this parameter to the device controller module. The device</entry></row><row><entry /><entry>controller module uses this parameter to “enable (1) or disable</entry></row><row><entry /><entry>(0)” getting data from a smart card reader device.</entry></row><row><entry>TimeOut</entry><entry>Amount of time the device service module displays a message</entry></row><row><entry /><entry>before clearing it. Messages also get cleared if a new “data</entry></row><row><entry /><entry>event” occurs from the Device Controller or if a new web</entry></row><row><entry /><entry>page is displayed.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0037An exemplary sample from a .ini file pertaining to the foregoing parameters appears below. The exemplary parameters listed below are associated with the “Global” section name since these parameters apply to the entire system.

0038[GLOBAL]

0039ENABLED=TRUE

0040TIMEOUT=1000

0041COMPORT=4

0042SMARTCARD=1

0043It is understood that a wide variety of device service parameters can be utilized without departing from the scope of the invention. The storage, modification and use of parameters such as those set out above is well within the grasp of those skilled in the art.

V. Form Filler Module

0044<figref idref="DRAWINGS">FIG. 6</figref> shows a block diagram of a form filler module in accordance with the invention. In general the form filler module accepts verified data from the device service module and, if configured properly, populates one or more fields from an identification document to the appropriate form field. In the current example, the form filler module is implemented as a Browser Helper Object (BHO) as is well know in the art. In this form, a new instance of the form filler module is created upon the opening of each new browser window and/or frame. Thus the invention is operable to utilize data scanned from a single identification document to populate multiple forms spread across multiple browser windows. For matters of clarity, <figref idref="DRAWINGS">FIG. 6</figref> illustrates only a portion of the form filler module functionality. For example, <figref idref="DRAWINGS">FIG. 6</figref> is generally depicted as a loop since the form filler typically waits for input before initiating any form of processing. It is understood that other program entry and exit points, time out functions, error checking routines and the like (not shown) would normally be implemented in the form filler module. Implementation of these aspects of the form filler module software are readily apparent and well within the grasp of those skilled in the art.

0045Upon initial execution, the form filler module performs typical initialization tasks. These tasks can include establishing a connection class with the device service module (i.e., registering with the device service module), reading the configuration file created by the configuration module (discussed in more detail below), initializing various form filler configuration parameters and the like, as represented by block <b>410</b>. Once initialization is complete, control passes to block <b>420</b> where the form filler reads configuration data previously set by the configuration module. In general, the configuration data specifies the URL(s) having one or more specific form fields to be populated, and which portion or field within the verified data should be used to populate such form fields. A more detailed discussion of field mapping and data translation follows below.

0046Data input from the device service module is represented at block <b>440</b>. Once the data is received, control is passed to block <b>460</b>. If one or more URL has fields configured for population then the form filler populates those fields as represented by block <b>470</b> and control is passed back to block <b>430</b>. A more detailed description of how population is carried out is set out below in the description of the configuration module. The configuration module may request identification of the available fields. Accordingly, this request is handled at block <b>450</b>. In this example, the configuration module is implemented as .NET module. Communication between the configuration module and the form filler module can be carried out via conventional techniques such as windows broadcast messaging and response via a windows message.

VI. Configuration Module

0047<figref idref="DRAWINGS">FIG. 7</figref> shows a block diagram of a configuration module in accordance with the invention. In general the configuration module provides a user interface for the invention. The configuration module is utilized to configure URL(s) and/or field(s) for population. The configuration module also provides various utility functions such as the ability to save configuration data, import/export configuration data, create/modify translation definitions and modify parameters. For matters of clarity, <figref idref="DRAWINGS">FIG. 7</figref> illustrates only a portion of the configuration module functionality. For example, <figref idref="DRAWINGS">FIG. 7</figref> is generally depicted as a loop since the configuration module typically waits for user input before initiating any form of processing. It is understood that other program entry and exit points, time out functions, error checking routines and the like (not shown) would normally be implemented in the configuration module. Implementation of these aspects of the configuration module software is readily apparent and well within the grasp of those skilled in the art.

0048Upon initial execution, the configuration module performs typical initialization tasks. These tasks can include reading the configuration file and/or initializing various configuration parameters and the like, as represented by block <b>510</b>. Once initialization is complete control passes to block <b>520</b>, where the configuration module waits for user input. Upon receipt of user input (e.g., typically from keyboard or mouse input), control is passed to the appropriate block. As stated above, the configuration module can create a population definition (blocks <b>570</b>-<b>590</b>), mapping fields associated with an identification document to fields associated with a form such as a web page having one or more form fields. The configuration module can also provide various utility functions such as the ability to save configuration data (block <b>530</b>), import/export configuration data (block <b>540</b>), create/modify translation definitions (block <b>550</b>) and modify parameters (block <b>560</b>). A more detailed discussion of each of these functions is set forth below.

0049a. Population Definition

0050When a user wishes to create or modify a population definition, control is passed to block <b>570</b>. In this example, basic configuration information is contained in a configuration file, which can contain a variety of data including population definitions, translation definitions, parameters and the like. The configuration file is read by the configuration manager upon start up. In the current example, each instance of the form filler module, upon start up, reads the configuration file. Thus the configuration file provides a mechanism for managing configuration information to be access by several system modules. In general, a population definition can be formatted in different ways. For example, a population definition can be created based on fields appearing in any form (All URL mode). In this mode, if a form has a field with a name matching an existing population definition, the field is populated with the specified data from the identification document regardless of the form name or URL. In the alternative, a population definition can be created based on fields associated with a specific form located a specific URL. Optionally, a population definition can be associated with a specific type of identification document (e.g., driver's license, financial document, military Document . . . ). In the examples that follow, the user has chosen to create a population definition associated with a specific form. Accordingly, control would be passed to block <b>580</b> and then back to block <b>520</b>. It will be readily apparent to those skilled in the art how to create a population definition corresponding to All URL mode.

0051<figref idref="DRAWINGS">FIG. 8</figref> shows an exemplary configuration manager display screen showing configuration information in accordance with the invention. In this example, the display screen is broken up into a folder view portion <b>600</b>, and a detail view portion <b>610</b>. Looking at the folder view portion <b>600</b>, it is readily apparent that the various population definitions are associated with a form located at a specific URL <b>605</b> (www.intellicheck.com). The folder view portion <b>600</b> is organized by the type of identification document with folders for driver's license documents <b>612</b>, financial documents <b>618</b>, military documents <b>624</b> and other documents <b>630</b>. Each document type is associated with a plurality of identification document fields that are organized by folders <b>613</b>, <b>619</b>, <b>625</b> and <b>631</b>. Similarly each document type can be associated with one or more translation definitions (discussed in more detail below) that are organized by folders <b>615</b>, <b>621</b>, <b>627</b> and <b>633</b>. Looking at the detail view portion <b>610</b>, it is readily apparent that details of selected fields and other information can be displayed in this portion as discussed in more detail below.

0052<figref idref="DRAWINGS">FIG. 9</figref> shows an expanded view of an exemplary drivers license document folder <b>612</b> in accordance with the invention. In this example, the document fields folder <b>613</b> has been expanded. A portion of the available drivers license document fields are displayed as identification document field folders <b>614</b>. In this example the Date of Birth Month folder <b>640</b> and DLID Unformatted folder <b>642</b> are further expanded to reveal associated form field folders <b>650</b> and <b>652</b>. In this particular example the birthmonth form field as shown by <b>650</b> is mapped to the Date of Birth Month identification document field as shown by <b>640</b>. Similarly, the dlidRaw form field as shown by <b>652</b> is mapped to the DLID Unformatted identification document field as shown by <b>642</b>. In this example, the dlidRaw form field was selected by the user. Accordingly, the detail view portion <b>610</b> contains details about this particular form field. In this case, the dlidRaw field is a text field. It is understood that a form can contain one or more field types including text fields, check boxes, drop down boxes and the like. The configuration manager is operable to populate each of these field types.

0053<figref idref="DRAWINGS">FIG. 10</figref> shows additional population definitions in accordance with the invention. In this example, the state form field as shown by <b>654</b> is mapped to the Jurisdiction identification document field as shown by <b>644</b>. The organDonor form field as shown by <b>656</b> is mapped to the Organ Donor identification document field as shown by <b>646</b>. In this example, the organDonor form field was selected by the user. Accordingly, the detail view portion <b>610</b> contains details about this particular form field. In this case, the organDonor form field is a check box field. The box will be checked if the Organ Donor identification document field has a value of “y”. The default for this particular field is unchecked. Accordingly, if the Organ Donor identification document field contains any value other than “y”, the organDonor form field will be unchecked.

0054In the current example, the configuration module stores one or more population definitions in Extensible Markup Language or XML. It is understood that other file formats, e.g., flat file, .ini file, windows registry, database files and the like can be used to store the configuration file and/or population definitions without departing from the scope of the invention. The configuration module is operable to read and modify the configuration file so that the user can create and modify the rules pertaining to field population. As is well known in the art, XML uses a self-describing and simple syntax. Each element begins with an opening tag and ends with a closing tag that includes the “/” prefix. Elements may have one or more nested sub elements. An exemplary sample of XML code pertaining to the population definitions shown in <figref idref="DRAWINGS">FIG. 9</figref> appears below.

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><MappingValues></entry></row><row><entry /><entry><Document></entry></row><row><entry /><entry> <URL>www.intellicheck.com</URL></entry></row><row><entry /><entry>  <Date of Birth Month></entry></row><row><entry /><entry>   <Value>birthmonth</Value></entry></row><row><entry /><entry>  </Date of Birth Month></entry></row><row><entry /><entry>  <DLID Unformatted></entry></row><row><entry /><entry>   <Value>dlidRaw</Value></entry></row><row><entry /><entry>  </DLID Unformatted></entry></row><row><entry /><entry></Document></entry></row><row><entry /><entry></MappingValues></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0055In this example, the population definition is defined by a series of tags associated with (i.e., nested under) the MappingValues XML tag. As is readily apparent, the MappingValues element includes several child elements. One such child element is delimited by the “Document” XML tag, so named because it contains mapping information related to one or more documents. The URL child element contains the URL of the form <b>40</b>. The term “URL” as used herein generally refers to the address of a form (such as the full path name of a local file, internet address of a web form or the like). In this particular example, the form is located at the world wide web address www.intellicheck.com. In this example, the form <b>40</b> contains a form field called “birthmonth”, which can be populated with data from an identification document <b>50</b>. The “Date of Birth Month” XML tag maps the “Date of Birth Month” ID document field from the identification document <b>50</b> to the form field specified by the nested “value” element (“birthmonth”). Similarly, the “DLID Unformatted” XML tag maps the “DLID Unformatted” ID document field from the identification document <b>50</b> to the form field specified by the nested “value” element (“dlidRaw”). Based on the foregoing description, it is readily apparent how population is carried out by the form filler module(s).

0056b. Create/Save Configuration and Import/Export

0057<figref idref="DRAWINGS">FIG. 11</figref> shows an exemplary display screen showing additional functions in accordance with the invention. The following types of file operations are well known in the art. For matters of completeness, a brief explanation follows. Referring also to <figref idref="DRAWINGS">FIG. 7</figref>, in the event the user wishes to create or save a configuration, as shown by block <b>530</b>, a file typical menu <b>710</b> is provided with the typical options such as new <b>720</b> and save <b>730</b>. Once the selection is made the configuration file is created or saved and control is passed back to block <b>520</b>. Similarly, if the user wishes to import or export a configuration (e.g., to or from another computer), menu entries <b>740</b> or <b>750</b> are selected, the desired operation is carried out and control is passed to block <b>520</b>. If the user elects to import a configuration, the existing XML configuration file is overwritten. If the user elects to export the current configuration, at least a portion of the existing XML configuration file is written to an export file. Once the import/export operation is complete, control is passed to block <b>520</b> again.

0058c. Create/Modify Translation Definition

0059The invention also includes the capability to translate occurrences of text appearing the ID document fields into corresponding text for population in a form field. In the event the user wishes to create or modify a translation definition, as shown by block <b>550</b>, a corresponding entry is created or modified in the configuration file. Once the translation definition is created or modified, control is again passed to block <b>520</b>. <figref idref="DRAWINGS">FIG. 12</figref> shows an exemplary translation definition display in accordance with the invention. In this example, the user has created translation definitions for the Date of Birth Month and DLID Jurisdiction ID document fields as shown by <b>640</b> and <b>648</b>. The user has selected the Date of Birth Month form field. Accordingly, the detail view portion <b>610</b> contains details about this particular form field. In this case, the Date of Birth Month form field has a set of translation definitions that translate numeric date information (from a field in the identification document <b>50</b>) to text information (for population into a field in the form <b>40</b>). An exemplary portion of XML code associated with the exemplary translation definitions shown in <figref idref="DRAWINGS">FIG. 12</figref> appears below. It is readily apparent that translation definitions are nested under the “Translation” XML tag:

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><Translation></entry></row><row><entry /><entry> <Date of Birth Month></entry></row><row><entry /><entry>  <From>01</From></entry></row><row><entry /><entry>  <To>Jan</To></entry></row><row><entry /><entry> </Date of Birth Month></entry></row><row><entry /><entry> <Date of Birth Month></entry></row><row><entry /><entry>  <From>02</From></entry></row><row><entry /><entry>  <To>Feb</To></entry></row><row><entry /><entry> </Date of Birth Month></entry></row><row><entry /><entry>. . .</entry></row><row><entry /><entry>  <From>12</From></entry></row><row><entry /><entry>  <To>Dec</To></entry></row><row><entry /><entry> </Date of Birth Month></entry></row><row><entry /><entry></Translation></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0060In this example, the ID document field at issue is the “Date of Birth Month” field. The range of expected values for this field is 01-12. The above translation definitions will populate the form field with appropriate text corresponding to the numeric date representation, namely Jan-Dec. For example, in the event the Date of Birth Month field has a value of “01”, this field is translated to “Jan”, as denoted by values enclosed within the nested “From” and “To” tags. In the event the Date of Birth Month field has a value of “02”, this field is translated to “Feb”. It is understood that each of the remaining 12 months has a similar definition (March-November, not shown). It is readily apparent that the ability to translate text in this way provides a simple mechanism for the invention to harmonize a wide range of ID document data with the specific formatting needs associated with a given form. It is also understood that a wide variety of translation definitions can be implement using the techniques disclosed herein.

0061d. Modify Parameters

0062The invention also includes the capability to modify system parameters. The storage, modification and use of parameters is well within the grasp of those skilled in the art. For matters of completeness, a brief explanation follows. In the event the user wishes to modify a parameter, control is passed to block <b>560</b>. In this event, the desired parameter is modified in the configuration file. It is understood that a wide variety of configuration parameters can be utilized without departing from the scope of the invention. <figref idref="DRAWINGS">FIG. 13</figref> shows an exemplary display screen showing various system settings in accordance with the invention. Several exemplary categories of parameters are displayed such as those pertaining to: whether the system is enabled <b>810</b>, the input device port <b>820</b> (e.g., DCM Port corresponds to the ComPort parameter discussed above), population behavior <b>830</b>, error message behavior <b>840</b> (e.g., Error Message Display Timeout corresponds to the TimeOut parameter discussed above), and data locations <b>850</b>.

VII. Exemplary Applications

0063Based on the foregoing, it is readily apparent that the invention is suitable for use in a wide variety of applications. The invention is particularly suited for applications in which on-line users (potentially in remote locations) are asked to complete an application form for permits, licenses, credit applications and the like. Such applications are benefited by the data entry aspects of the invention (i.e., less data entry is required by the user and the data is more accurate). The invention can also provide verification of one or more identification document, thereby increasing the confidence in any form populated based on the verified identification document. For example, a financial institution may wish to deploy a plurality of kiosks directed at collecting credit applications or forms <b>40</b> (potentially in locations that are remote from the financial institution). Referring again to <figref idref="DRAWINGS">FIG. 1</figref>, in such an example, the kiosk would include a computer <b>20</b>, card scanner <b>60</b> and form filling software <b>30</b>. The form <b>40</b> can reside locally on computer <b>20</b> or may be provided via server <b>80</b>. The user is prompted to scan an identification document <b>50</b> using card scanner <b>60</b>. The raw data is then verified and one or more fields in the form <b>40</b> is populated with at least a portion of the verified data. The user can complete any remaining fields that are required to complete the form <b>40</b>. Once the form is completed is can be transmitted to the financial institution in real time, or batch format via conventional means. Upon receiving the form, the financial institution has increased confidence that the information contained in the completed form is correct.

0064While the foregoing description and drawings represent the preferred embodiments of the present invention, it will be understood that various changes and modifications may be made without departing from the scope of the present invention.