BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    This invention relates to a business method for verifying salary information, and/or other types of employment data, over the Internet.  
           [0003]    2. Prior Art  
           [0004]    When a person applies for a home loan, they typically fill out a credit application and submit it to a mortgage company. This application requires the applicant to disclose personal financial information including bank account numbers and balances, loan payments, credit card account numbers and balances, employment history, current salary and perhaps other information.  
           [0005]    Mortgage companies have typically compared the financial information in the credit application with financial information obtained from a service provider (sometimes called a credit bureau). Some mortgage companies input this financial information into various formula to produce a numeric credit score. However, verification of current salary and employment data was more difficult. Mortgage companies were often forced to make direct contact with the employer to obtain and verify current employment data. This verification process with the employer typically required a written inquiry from the mortgage company to the employer and a written response from the employer to the mortgage company. This written verification process for salary and employment data was time-consuming and sometimes subject to fraud. It was also expensive because employers with thousands of employees were required to dedicate a portion of their Human Resources Department to the verification process.  
           [0006]    In 1994, TALX Corporation, the assignee of the present application, pioneered a new method of doing business whereby this written verification process (which was previously accomplished by the employer&#39;s Human Resource Department) could be out-sourced. This new verification system was called The Work Number®. This verification system allowed the mortgage company to contact TALX over a touch-tone telephone and verify the current salary and employment data for the loan applicant. In exchange for this information, the mortgage company paid TALX a transaction fee.  
           [0007]    This touch-tone verification system had great appeal to large employers because it reduced operating expenses and headaches in the Human Resources Department. This touch-tone verification system had great appeal to mortgage companies because it was faster than the old written system and it was less subject to fraud. Because of these advantages, a large number of the Fortune 100 companies have adopted the Work Number verification system as the preferred means for salary and employment verification.  
           [0008]    This sort of verification system is useful to a number of different companies, which extend credit to consumers. For example, apartment rental companies will often access the system to verify employment data before signing a property rental agreement. Furniture companies and subprime lenders will often access the system to verify employment data before signing a loan. All of these different companies that access The Work Number verification system to confirm employment data will hereinafter be generically referred to as “verifiers.” 
           [0009]    The TALX Work Number verification system introduced in 1994 allowed an employer to provide employment data via magnetic tape or over a telephone line via a modem which was loaded to a database. When employees applied for a loan which required a comprehensive disclosure of employment data, they would call TALX over the telephone and be orally given a salary key code (“SKC”). The employee orally disclosed the SKC over the telephone or face-to-face to the verifier. The verifier then called TALX over the telephone to access the Work Number database. Once connected over the telephone, the verifier entered the SKC and other identification data using the keypad of a touch-tone telephone. If the inquiry was authorized, TALX would issue a report containing employment data to the verifier using interactive voice response technology and, as an option, could also automatically fax the, report to the verifier. The TALX end of the transaction was automated. The verifier end of the transaction was initiated by a person who made numeric entry of data using the keypad of a touch-tone telephone.  
           [0010]    When employees applied for a loan which required minimal disclosure of employment data, a less comprehensive report was prepared by TALX and given to the verifier. When the report contained only a minimal amount of employment data, the SKC was not required by TALX. In this situation, the verifier entered identification data (but not a SKC) using the keypad of a touch-tone telephone. If the inquiry were authorized, TALX would issue a report containing minimal employment data to the verifier using interactive voice response technology and, as an option, could also automatically fax the report to its verifier.  
           [0011]    Most verifiers required a faxed report so they would have a hard copy in their file. Many verifiers would not authorize a loan, or other transaction until the hard copy had been received at the verifier&#39;s office. Unfortunately, this often presented delivery problems because of a limited number of fax machines at the verifier&#39;s office, which were often busy. This slowed the process down and caused problems at the service provider because it had to revisit the transmission issue when the fax was not delivered.  
           [0012]    To overcome these delivery problems, TALX decided to reconfigure The Work Number verification system so that it would also be accessible over the Internet (a.k.a. worldwide web.) This would bypass the fax machine bottleneck and allow the verifier to print a hard copy of the report at their office. Initially, TALX intended to modify proprietary TALX software to make The Work Number verification system Internet accessible. The task was laborious and time-consuming, even with the help of outside consultants. Unfortunately, this approach did not work and it was abandoned in favor of off-the-shelf software and hardware. This course correction delayed the project even further.  
           [0013]    The task was still daunting and the web site proved to be unstable during internal testing. The web site would repeatedly crash and further modifications were made. Finally, on Jan. 25, 1999, a press release was issued by TALX Corporation announcing to the world that the Work Number verification system was now accessible over the Internet. Even this announcement proved to be premature. The web site continued to have problems and further changes were made before the web site became stable in the summer of 1999.  
           [0014]    In conclusion, confirmation of employment data by verifiers has moved through various evolutionary phases. a) For decades verification was a time-consuming, expensive process that typically required the exchange of one or more letters between the verifier and the employer. b) In 1994, TALX introduced a service provider concept that allowed employment data to be verified using a touch-tone keypad with interactive voice response. In most situations, a hard copy of the report was also faxed to the verifier. c) In 1999, TALX perfected a new service provider concept that allowed employment data to be verified over the Internet, which bypassed the fax machine bottleneck that was often encountered at busy verifiers.  
         SUMMARY OF THE INVENTION  
         [0015]    Four parties are typically involved in this verification process, i.e., the employer, the employee, a verifier and the service provider. Three of these parties maintain computer systems that are capable of communicating over the Internet and, in the best mode, encrypting such data before it is sent. At least one employer periodically loads employment data including, but not limited to, current salary and employment history into a database maintained by a service provider. In the best mode, this loading process occurs over the Internet, however, other less efficient loading modes are within the scope of the invention, including magnetic tape loading and loading of information over a telephone line with a modem.  
           [0016]    The employee contacts the service provider and obtains at least one salary key code (SKC), if required. The SKC gives the verifier authority to verify salary information for a single transaction and thus enhances security in the system regarding release of employee salary information. In the best mode, the employee will contact the service provider over the Internet to receive at least one SKC. However, the invention can be practiced in a less efficient mode by the employee if they contact the service provider by telephone.  
           [0017]    The employee then discloses at least one SKC to the verifier, if required. In the best mode, the disclosure of the SKC to the verifier occurs over the Internet. However, the invention can be practiced in a less efficient mode whereby the employee discloses the SKC to the verifier orally over the telephone or, in a face-to-face meeting.  
           [0018]    Finally, the verifier contacts the service provider web site and enters appropriate identification data and the SKC, if required. The identification data and the SKC are compared against a list of valid SKCs and identification data in the service provider database. If the SKC is valid and the other identification data is valid, the service provider will generate a report to the verifier containing employment information. This report is sent to the verifier over the Internet, preferably in encrypted form. Various types of reports can be generated containing employment data.  
           [0019]    In some circumstances, when only minimal employment data is required by the verifier, the SKC is not required. This reduction in security is acceptable to employers and employees when only minimal employment data is being disclosed. In this situation, the verifier enters identification data (but not a SKC) into the service provider computer system. If the inquiry is authorized, the service provider issues a report containing only minimal employment data.  
           [0020]    In an alternative embodiment, a governmental agency can access the service provider database to verify information necessary to determine if an applicant qualifies for public assistance. The report to a governmental agency will likewise include employment data. In yet another alternative embodiment, governmental agencies can look up all occurrences of a social security number (“SSN”) on a database for a particular employee.  
           [0021]    The verifier pays the service provider for each report that it receives. The cost of the reports varies depending on the amount of information contained therein. The governmental agencies likewise pay the service provider when conducting inquiries concerning applications for public assistance or when conducting a SSN search.  
           [0022]    In an alternative embodiment, the employer may assume the function of the service provider and respond to inquiries from the verifier directly. The employer may or may not charge for this verification process.  
           [0023]    This invention is efficiently practiced using Active Server Page (ASP) technology well known to those skilled in the art. However, it may also be practiced by the process of downloading Java Script Code to the users. In yet another way, the invention may be practiced by down loading Active X code to the users. Both Java Script and Active X are well known to those skilled in the Art and are within the scope of this invention. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0024]    The advantages of this invention will be better understood by referring to the accompanying drawings, in which:  
         [0025]    [0025]FIG. 1 is a block diagram of the relationship between the employer, the employee, the service provider and the verifier.  
         [0026]    [0026]FIG. 2 is a block diagram of the connection over the Internet between the employer and the service provider when the employer loads employment information. This diagram also contains the hardware configuration that the service provider uses for this purpose.  
         [0027]    [0027]FIG. 3 is a block diagram of the connection over the Internet between the employee and the service provider when the employee is assigned a SKC. This diagram also contains the hardware configuration that the service provider uses for this purpose.  
         [0028]    [0028]FIG. 4 is a block diagram of the connection over the Internet between the verifier and the service provider during the verification process. This diagram also contains the hardware configuration that the service provider uses for this purpose.  
         [0029]    [0029]FIG. 5 is a block diagram similar to FIG. 4 except the verifier is storing data from multiple employers instead of a single employer as shown in FIG. 4 and is simultaneously handling inquiries from multiple verifiers. FIG. 5 is the best mode currently known to applicants.  
         [0030]    [0030]FIG. 6 is a flowchart of the data loading process by the employer. This flowchart corresponds with the block diagram FIG. 2.  
         [0031]    [0031]FIG. 7 is a flowchart of the main screen selection process at the service provider.  
         [0032]    [0032]FIG. 8 is a flowchart of the employee access procedure.  
         [0033]    [0033]FIG. 9 is a flowchart of the process for assigning a SKC to an employee. This flowchart corresponds with the block diagram FIG. 3.  
         [0034]    [0034]FIG. 10 is a flowchart for the verifier login at the service provider.  
         [0035]    [0035]FIG. 11 is a flowchart for the verification process. This flowchart corresponds with the block diagram FIG. 4.  
         [0036]    [0036]FIG. 12 is a sample report containing minimal employment data.  
         [0037]    [0037]FIG. 13 is a sample report containing more employment data than the report FIG. 12.  
         [0038]    [0038]FIG. 14 is a sample report containing more employment data than the reports FIG. 12 and FIG. 13.  
         [0039]    [0039]FIG. 15 is a flowchart for a governmental agency to login at the service provider.  
         [0040]    [0040]FIG. 16 is a flowchart for a governmental agency to make verification requests and to request a SSN report.  
         [0041]    [0041]FIG. 17 is a sample report containing employment data to a governmental agency.  
         [0042]    [0042]FIG. 18 is a sample SSN report.  
         [0043]    [0043]FIG. 19 is a flowchart of the employer login at the service provider.  
         [0044]    [0044]FIG. 20 is a flowchart for various employer functions including blocking employee information, reactivating an employee and placing an employee on inactive status.  
         [0045]    [0045]FIG. 21 is a flowchart of the process to assign an employee a new personal identification number (PIN).  
         [0046]    [0046]FIG. 22 is a block diagram of an alternative embodiment of this verification system wherein the employer subsumes the functions of the service provider and deals directly with the verifier.  
         [0047]    [0047]FIG. 23 is a block diagram of the alternative embodiment of FIG. 22 showing the connection over the Internet between the employer and the verifier during the verification process. This diagram also contains the hardware configuration that the employer uses for this purpose.  
         [0048]    [0048]FIG. 24 is a block diagram of another alternative embodiment wherein the employment data is stored on a database maintained by the employer, but the verifier accesses the employment data via a service provider. This diagram also contains the hardware configuration that the service provider and employer use for this purpose.  
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0049]    [0049]FIG. 1 is a block diagram indicating the overall relationship between the employer  10 , the employee  12 , the service provider  14  and the verifier  16 . The arrows in the diagram indicate the exchange of data between the parties over the Internet  20 . The employer  10  transmits employment data over the Internet  20  to the service provider  14 . In the preferred embodiment, the employer  10  encrypts the data before it is sent to the service provider  14 .  
         [0050]    The employee  12  fills out a credit application and gives it to the verifier  16 . The credit application requires disclosure of the name of the employer  10 , the employee&#39;s  12  SSN and other financial information. The employee  12  contacts the service provider  14  over the Internet  20  and requests a salary key code (SKC), if required. The employee  12  then contacts the verifier  16  over the Internet  20  and discloses the SKC to the verifier  16 . The verifier  16  then contacts the service provider  14  over the Internet  20 , inputting the SKC and other identification data. The service provider  14  compares the SKC and the identification data against a list of valid SKCs and valid identification data to determine if the verifier  16  should receive a report containing employment data from the service provider  14 . If the verifier  16  can demonstrate proper authority by inputting a valid SKC and valid identification data, the service provider  14  generates a report and sends the report over the Internet to the verifier  16 . In the preferred embodiment, the report is encrypted and then sent to the verifier  16 . The verifier  16  will typically print a hard copy of the report on a printer at their office for inclusion in the employee&#39;s  12  loan application file.  
         [0051]    Although it is less efficient, the employer  10  may also transmit data to the service provider  14  via magnetic tapes, or over the telephone lines via a modem. In the preferred embodiment, transmission of employee data occurs over the Internet  20 . In a less efficient version of this invention, the employee  12  can also acquire an SKC from the service provider  14  over the telephone. In the preferred embodiment, the transaction between the employee  12  and the service provider  14  occurs over the Internet  20 . All interactions between the service provider  14  and the verifier  16  occur over the Internet  20 .  
         [0052]    The employer  10  can also obtain data from the service provider  14  such as real time system activity reports which include a total of SKCs issued to their employees, a total of verification reports performed against their employees  12 , and other information. Further, the employer  10  may access the system&#39;s employee  12  maintenance functions to block/unblock an employee&#39;s  12  record, check and/or change an employee&#39;s  12  status code, and check and/or change the termination date for an employee  12 .  
         [0053]    The verifier  16  is charged a transaction fee for each report prepared by the service provider  14 . The service provider  14  maintains accurate records and prepares periodic invoices which are typically mailed to the verifier  16 . These invoices can also be delivered electronically and payments can be made by check, credit card, wire or any other means acceptable to the verifier  16 .  
         [0054]    [0054]FIG. 2 is a block diagram showing the connection between the employer  10  and the service provider  14  over the Internet  20  when the employer  10  transfers employment data to the service provider  14  computer system. The employer  10  establishes a connection in conventional fashion with the Internet  20  in order to connect with the service provider  14 . The service provider  14  is connected to the Internet  20  by pipes  21  which could be T1 lines or other types of connections. The pipes  21  connect to a router  22 . Applicant has found that a Cisco 3620 router is suitable for this purpose. These routers are available from Cisco Systems of Santa Clara, Calif. The data is then transferred from the router  22  through a firewall  24 . Applicant has found that a Sun Solaris server is suitable to be used as the firewall  24 , running a Sun OS 5.6 operating system with McAffee anitivirus protection and Check Point Firewall software. The Sun Solaris Server is available from Sun Microsystems of Palo Alto, Calif. The McAfee software is available from Network Associates of Santa Clara, Calif. The Check Point Firewall software is avilable from Check Point Software Technologies of Redwood City, Calif. The data moves through the firewall  24  to the File Transfer Protocol (FTP) server  26 . Applicant has found that the following hardware and software are suitable for the FTP server  26 : Intel ALT server available from Intel Corporation of Santa Clara, California; and Redhat Linux 6.0 operating system available from Redhat of Durham, N.C. The data is temporarily stored in the FTP Server in a user name, password protected directory. Each employer  10  utilizing this preferred method of data transfer is assigned such an account.  
         [0055]    When the data is retrieved from FTP server  26  in prepartion for loading to primary database server  32 , the data then goes back through the firewall  24  to the ethernet  28 . Other types of networks could also be suitable including a token-ring. Various types of network topologies are well known to those skilled in the art and are within the scope of this invention. The data passes across ethernet  28  to a workstation  30  for loading of the FTP data. Applicant has found that the following hardware and software are suitable for the workstation  30 : a Portland personal computer (“PC”) available from Intel Corporation of Santa Clara, Calif.; running Microsoft Windows NT 4.0 operating system available from Microsoft Corporation of Redmond, Wash. Additionally workstation  30  has the following software installed to be run as required: PGP Encryption/Decryption software available from Network Associates of Santa Clara, Calif.; PKZip data compression software available from PKWARE Incorporated of Brown Deer, Wis. and IBM Compress data encryption\decryption software available from IBM of Armond, N.Y. In preparation for loading, data is decrypted using appropriate software discussed above. The data then moves along the ethernet  28  to the primary database server  32  and is copied to redundant database server  34 . Anytime data is stored in primary datase server  32  it is also copied to redundant database server  34 . Applicant has found that a Compaq Proliant 7000 server running MS Windows NT 4.0 as an operating system and the Oracle 8.05 database system works well for this purpose. The Proliant servers can be obtained from Compaq Computers of Houston, Tex. The MS Windows NT can be obtained from Microsoft of Redmond, Was. and the Oracle software can be obtained from Oracle of Redwood Shores, Calif. A redundant database server  34  also connects to the ethernet  28  in case of any problems with the primary database server  32 . The same hardware and software used for the primary database server  32  also work well for the redundant database server  34 .  
         [0056]    In review, employment data from the employer  10  is routed over the Internet  20 . The data arrives at the service provider  14  and is transmitted via pipes  21  to router  22 . The data then moves from the router  22  to the firewall  24  and into the FTP server  26 . The data then moves back through the firewall  24  to the ethernet  28  to workstation  30  where it is then prepared for loading. The data then moves back over the ethernet  28  to the primary database server  32  and the redundant database server  34  where it is stored.  
         [0057]    Although not as efficient as loading data over the Internet  20 , the employer  10  can also load data over the telephone lines via the data modem  36  where it is received by workstation  38 . Data received is temporarily stored in a user named, password protected directory. Applicant has found that U.S. Robotic 28.8 modems are suitable for this application. The modems can be obtained from 3-Com Corporation of Santa Clara, Calif. Applicant has determined that the following hardware and software are suitable for the workstation  38 : an Intel Portland PC with Microsoft Windows NT 4.0 operating System, PGP software for data encryption, IBM Compress software for data encryption and compression, PK Zip for data compression, Hyper Access 5.0 modem control software and McAffee Virus for virus protection. These products can be obtained from the following vendors: Intel Portland PC from Intel Corporation of Sata Clara, Calif., Hyper Access 5 modem control software from Hillgraeve of Monroe, Mich., PGP 6.5 encryption software available from Network Associates of Santa Clara, Calif.; IBM compress software available from IBM of Armond, N.Y.; PKZIP available from PKWARE Incorporated Brown Deer, Wis., and McAffee Anti-virus 4.0.4, available from Network Associates of Santa Clara, Calif. Employer  10  data is uncompressed or decrypted as appropriate, scanned for viruses, prepared for loading, and moved across a dedicated link through workstation  40  across the ethernet to primary datbase server  32  and redundant database server  34  where the data is stored. A dedicated link to workstation  40  is used to insure that access to TALX internal networks is not possible via modem and completly under the control of the firewall  24 .  
         [0058]    Applicant has determined that the following hardware and software are suitable for the workstation  40 : an Intel Portland PC available form Intel Corporation of Sata Clara, Calif. running MS Windows NT 4.0 operating system available from Microsoft Corporation of Remond, Wash.  
         [0059]    In review, data from the employer  10  can be transmitted through the data modem  36  which is then prepared for loading at the workstation  38  and transmitted through the workstation  40  through the ethernet  28  and is thereafter stored on the primary database server  32  and the redundant database server  34 .  
         [0060]    In the alternative, the employer  10  can also supply employment data through 9 track magnetic tape via tape drive  46 . Applicant has found that the following equipment is suitable for tape drive  46 : Qualstar 3412S 9-track tape drive, available from Qualstar Corporation of Canoga Park, Calif. with PC workstation  40  running Nova Xchange 2.00 software from Novastar Corporation of Simi Valley, Calif. In another alternative, the employer  10  can supply employment data through cartridge magnetic tape via multi cartridge tape drive  42 . Applicant has found that the Xcerta VDS MS-843 EWS-XL multi-cartridge magnetic tape unit available from Comco Incorporated of Bettendorf, Iowa with PC workstation  40  running Nova Xchange 2.00 software from Novastar Corporation of Simi Valley, Calif. is suitable for this purpose. In another alternative the employer  10  can supply employment data on CD ROM via CD ROM drive  44 . Applicant has found that the following equipment is suitable for the CD ROM  44 : Sony 8×CD from Sony Electronics, Inc. of Park Ridge, N.J.  
         [0061]    Suitable backup systems for the primary database server  32  and redundant database server  34 , known to those skilled in the art, are also used in this system but are not shown in the drawings.  
         [0062]    In review, data loaded on the 9-track tape drive is prepared for loading at workstation  40 , is transmitted over the ethernet  28  and stored in the primary database server  32  and the secondary database server  34 . Likewise, data loaded by the CD ROM  44  and the cartridge tape drive  42  is prepared for loading by the PC workstation  40  and is transmitted via the ethernet  28  to primary database server  32  and redundant database server  34 . Other types of data transfer methods that may be used to transfer data from the employer  10  to the service provider  14 , are within the scope of this invention, and are known to those skilled in the art.  
         [0063]    [0063]FIG. 3 is a block diagram showing the connection between the employee  12  and the service provider  14  over the Internet when the employee is assigned a SKC.  
         [0064]    In the best mode, employee  12  gains access to the Internet  20 , and enters the domain name (Uniform Resource Locator) for the service provider  14  web site. Data from pipes  21 , moves through the router  22  into the firewall  24  and into the web server  25 . The URL currently used by TALX is www.theworknumber.com. Applicant has successfully used the following hardware and software for the web server  25 : Intel Madronna server available from Intel Corporation of Santa Clara, Calif. running Microsoft Windows NT 4.0 operating system and Microsoft Internet Information Server 4.0 (IIS) web application engine.  
         [0065]    When the URL is entered, the main selection screen, (home page) is displayed to the employee  12 . When the employee  12  selects the employee  12  login function the connection between the employee  12  and the service provider  14  is encrypted using Secure Socket Layer (SSL) technology with 40 bit encryption. This technology is native to web browser software and well known to those skilled in the art. Other types of encryption methods known to those skilled in the art are within the scope of this invention. The employee selects their company via a drop down menu, enters their SSN, and their PIN. The web application then compares the employee PIN entered to the PIN stored on the primary database  32  and redundant database  34 . If the company, SSN and PIN match the data in the database, the employee is validated and allowed access. The employee may select to receive an SKC; the web application randomly generates at least one SKC that is assigned to that employee, writes a record of the transaction through firewall  24  to the ethernet  28  and stores it on primary database server  32  and transmits the SKC as indicated by the arrows, to the employee  12 . In the present configuration, the employee can request up to three SKCs at a time. This is important because an employee may be making concurrent loan applications through several mortgage companies in an effort to locate better rates or for other reasons.  
         [0066]    In review, the SKC is a number that is randomly generated by the service provider  14 . The service provider  14  typically generates thousands of valid SKCs which are stored in the primary database server  32  and redundant database server  34 . Each unique SKC is valid for only a single transaction. In other words, once a unique SKC is used, it cannot be re-used or re-assigned by the employee, the service provider, or another verifier. In a less efficient fashion, the employee may also contact the service provider  14  over the telephone to receive at least one SKC.  
         [0067]    [0067]FIG. 4 is a block diagram of the verification process. The verifier  16  gains access to the Internet  20  and enters the URL for the service provider  14  web site. The URL request from the verifier  16  is transmitted via pipes  21  to router  22  through firewall  24  to web server  25 . The verifier sees the home page for the service provider  14  and with sufficient prompts, moves to another screen for entering identification data and the SKC. When the verifier  16  selects the verifier  16  login option the connection between the verifier  16  and the service provider  14  is encrypted using Secure Socket Layer (SSL) technology, with 128 bit encryption. This technology is native to web browser software and well known to those skilled in the art. The service provider  14  may also use other encryption methods well known to those skilled in the art. Once the data are entered by the verifier  16 , it will be compared against valid identification data and valid SKCs for that employee  12  fetched from primary database server  32  via the ethernet  28  through firewall  24  and loaded to the web application on web server  25 . If the information entered by the verifier  16  can be validated against the identification data and the SKC in the database  32 , a report will be generated by the web application on web server  25  and a transaction record will be written to the primary database server  32  and redundant database server  32 , through the Firewall  24  via the ethernet  28 . The report is transmitted through the Firewall  24  to the router  22  and through the pipes  21 . The report then passes over the Internet  20  to verifier  16 .  
         [0068]    Various types of reports can be generated depending on the needs of the verifier  16 . The reports contain employment and salary data.  
         [0069]    If a governmental agency is making an inquiry, a public assistance report is generated. If a governmental agency is seeking all occurrences of a social security number on the database, a social security search report is generated.  
         [0070]    In review, the verifier  16  accesses the service provider  14  via the Internet  20 , enters employee identification data and, if required, a valid SKC. If all entered data is validated against data stored in primary database server  32  the verifier  16  may order a report on the employee  12 . Reports on employees  12  contain varying amounts of information depending on the verifier  16  needs. State governmental organizations may order Public Assistance verification reports as well as a report listing all occurences of the SSN on the primary database server  32  and server  34  for employee  12 . The service provider  14  charges for all reports.  
         [0071]    [0071]FIG. 5 is a block diagram of the verification system in the best mode as currently known to applicant. Multiple verifiers enter into agreements with the service provider  14  and are able to access the verification system simultaneously over the Internet  20 . (Today more than a thousand verifiers have entered into such agreements with TALX and are using this verification system over the Internet  20 .) In FIG. 5, multiple verifiers are shown, i.e., verifier A, identified by numeral  16  and verifier B, identified by numeral  17 .  
         [0072]    Likewise, multiple employers  10  enter into agreements with the service provider  14  and employment data from each employer  10  is stored on primary database server  32  and copied to redundant database server  34  at the service provider&#39;s  14  place of business. Today hundreds of employers  10  have entered into such agreements to use this verification system over the Internet  20 . Employment data for millions of employees  12  from various employers  10  is securely stored on primary database server  32  and redundant database server  34  at the service provider&#39;s  14  place of business.  
         [0073]    When each verifier  16  enters into an agreement with the service provider  14 , they are assigned specific identification codes, which act as a user name password, so the verifier  16  can login to the verification system. The first ID code is called the Lender ID code which identifies the business entity and the second ID code is called the Verifier ID code which identifies the office or location for verifiers  16  with more than one office. For example, ABC Mortgage Company has several offices throughout the United States. ABC Mortgage Company could be assigned a Lender ID code of 12345678. Each office or location of ABC Mortgage Company would have a unique Verifier ID code. For example, ABC Mortgage Company has an office in Arlington, Va., with a Verifier ID code of 91011. When logging in to the service provider  14 , via the Internet  20 , the verifier  16 , ABC Mortgage Company in Arlington, Va. enters both the Lender ID code, 12345678, and the Verifier ID code, 91011. The service provider  14  is then able to compare these ID codes against valid ID codes stored in the primary database server  32  and validate whether the verifier  16  has proper access to the system. These ID codes identify that the inquiry for employment information is being made by a known and authorized verifier  16  from its Arlington, Va. office. Other types of identification codes are within the scope of this invention.  
         [0074]    These verifier  16  ID codes also facilitate proper billing by the service provider  14 . A fee is charged by the service provider  14  for each report sent to a verifier  16 . A unique transaction ID, known as a reference number, is assigned to each report that is sent to a verifier  16 .  
         [0075]    In the best mode, multiple employers  10  enter into contracts with the service provider  14  so a plurality of employees  12  can take advantage of this verification system. FIG. 5 is a block diagram similar to FIG. 4 except that the service provider  14  is storing data for multiple employers A, B, and C with thousands of employees  12  and is handling requests from multiple verifiers  16 ,  17  simultaneously. The Work Number verification system that is presently in use at TALX Corporation uses the model shown in FIG. 5. This makes the system more cost-efficient and attractive from the perspective of the service provider  14 .  
         [0076]    This invention is currently practiced using Active Server Page (ASP) technology well known to those skilled in the art. In the alternative, it may also be practiced by the process of downloading Java Script Code to the users (i.e. employee  10 , verifier  16  or employer  10 ). In yet another way, the invention may be practiced by down loading Active X code to the users. Both Java Script and Active X are well known to those skilled in the art and are within the scope of this invention.  
         [0077]    [0077]FIG. 6 is a flowchart for the employer  10  data load process described in the block diagram FIG. 2. The system first determines if the employer  10  data is being transferred to the service provider  14  by Electronic Data Interchange (EDI) or some other means. If the data is not being transferred EDI, the data will be transferred either through diskette, magnetic tape or CD ROM to the service provider  14  for loading to the primary database server  32  and the redundant database server  34 .  
         [0078]    If the employer data is being transferred EDI over a modem, the data moves to workstation  38 . If the transferred data is compressed using PKZip, the data is uncompressed and prepared for loading. The data then moves through workstation  40  over the ethernet  28  to a temporary load area in primary database server  32  from where it is loaded to the production database in primary database server  32  and copied via the ethernet  28  to the redudant database server  34 .  
         [0079]    In the best mode, the employer  10  data is tranferred via the Internet  20  through the pipes  21 , through router  22 , through firewall  24  to FTP Server  26 , utilizing File Transfer Protocol (FTP). The data is then moved from the FTP server  26  through the firewall  24  to the FTP Data Load  30  via the ethernet  28 . If the received employee data is in encrypted form it is decrypted using the appropriate decryption software and prepared for loading. The data is then loaded via the ethernet  28  to a temporary load area on primary database server  32  from where it is loaded to the production database on the primary database server  32  and copied via the ethernet  28  to the redundant database server  34 .  
         [0080]    For purposes of claim interpretation the term “employment data” may include, but is not limited to, company identification code, employee PIN, SSN, employment status, i.e., actively employed, retired, no longer employed, etc.; most recent start date; total time with employer; current title; rate of pay, i.e., weekly, biweekly or monthly, etc.; average hours worked; total dollars paid, year to date; total dollars paid for prior years; last pay date and other types of employment data.  
         [0081]    All of this employment data is stored in the primary database server  32  and is copied to the redundant database server  34 . This employment data is transferred by the employer  10  periodically, typically following each pay period, so as to maintain the most accurate information possible. Transferring of employment data by the employer  10  does not require access to the service provider&#39;s  14  web site.  
         [0082]    [0082]FIG. 7 is a flowchart that explains how the software functions when an employee  12 , verifier  16  or employer  10  makes a connection over the Internet  20  with the service provider&#39;s  14  web site. Once the connection has been established, the main screen (home page) is displayed for the employee  12 , the verifier  16  or the employer  10  presenting three distinct options. The employee  12  may login to the employee  12  portion of the system for obtaining a SKC. The verifier  16  may login to the verifier  16  portion of the system to obtain reports with employment data. The employer  10  may login to the system to update employee status and perform file maintenance.  
         [0083]    [0083]FIG. 8 is a flowchart explaining the employee  12  login procedure. After the employee  12  makes a selection, an employee login screen will be displayed to the employee  12 . The employee login screen displays a drop-down menu containing a list of all employers. The employee selects their employer. Each employer has a distinct Company Code number which the sytsem utilizes based upon the employee&#39;s employer selection. The employee  12  login screen also displays several input fields including the employee&#39;s SSN and the employee&#39;s personal identification number (PIN). After the employee  12  has selected their company and entered their SSN and PIN, the system will compare these entries against valid company codes, SSN and employee PIN numbers in the primary database  32 . If the information entered by the employee  12  is validated against corresponding information in the service provider  14  primary database  32 , another screen will be presented to the employee whereby he can view active (unused) SKCs, request or delete one or more SKCs, and change their PIN. During the employee  12  login process an employee  12  may make up to three attempts to login. If for whatever reason, i.e., mis-typed, forgotten PIN, etc., login is not achieved the employee  12  sees a message screen that the login attempt was unsuccessful and he may make another attempt. If after three attempts the employee  12  has not sucessfully logged in, the employee  12  sees a message screen telling them that they are locked out of the system for a period of thirty minutes. The web application writes a lock out record for this employee  12  to the primary database  32  as previously described. Upon the next attempt to login, the system compares the date and time stamps on any lock out records for the employee  12  to the system date and time. If at least thirty minutes have passed since the lock out record was written, the employee  12  may attempt to log into the system. If at least thirty minutes have not passed the employee sees a lock out message screen. This lock out feature enhances employee  12  security by preventing long periods of login attempts for the purpose of trying unlimited combinations of ID information, either manually or via a software program, to discover valid combinations of employee  12  ID information and surreptitiously gain system access.  
         [0084]    [0084]FIG. 9 is a flowchart of the system software for assigning one or more SKCs to an employee  12  or deleting one or more SKCs previously assigned. The screen displays active (unused) SKCs. The screen prompts the employee  12  to request or delete an SKC. One or more SKCs are then displayed on the screen for the employee  12  or one or more SKCs disappear from the screen. After the employee  12  finishes selecting or deleting SKCs, they select “finish” and see a “thank you” message screen.  
         [0085]    [0085]FIG. 10 is a flowchart for the verifier  16  login procedure. A verifier  16  goes from the main menu (home page) to a verifier  16  login screen which has several input fields including the lender ID and the verifier ID. The lender ID is a preassigned number for a verifier which may have multiple offices throughout the United States. The verifier ID is a separate number for each individual office. After the lender ID and the verifier ID have been entered into the input fields, the system compares this identification data with valid lender ID numbers and verifier ID numbers in the database. If the lender ID and the verification ID are valid, another screen will be presented to the verifier  16 . During the verifier  16  login process a verifier  16  may make up to three attempts to login. If for whatever reason, i.e., mis-typed lender ID, or forgotten verifier ID, etc, login is not achieved the verifier  16  sees a message screen telling them the login failed and allows them to attempt another login. After three attempts the verifier  16  sees a message screen telling them that they are locked out of the system for a period of thirty minutes. The web application writes a lock out record for this verifier  16  to the primary database  32  as previously described.  
         [0086]    Upon the next attempt to login, the system compares the date and time stamps on any lock out records for the verifier  16  to the system date and time. If at least thirty minutes have passed since the lock out record was written, the verifier  16  may again attempt to log into the system. If at least thirty minutes have not passed the verifier  16  sees a lock out message screen and is not allowed to attempt login. This lock out feature enhances verifier  16  security by preventing long periods of login attempts for the purpose of trying unlimited combinations of ID information, either manually or via a software program, to discover a valid combination of lender ID and verifier ID and to surreptitiously gain system access. Other types of lock out methodology known to those skilled in the art are within the scope of this invention.  
         [0087]    [0087]FIG. 11 is a flowchart of the software program for the verification request process, including generation of a report. After the verifier  16  has appropriately logged in, the verification screen displays a drop-down menu containing a list of all employers  10 . The verifier  16  selects the appropriate employer  10  for a specific employee  12 . Several input fields are displayed including, employee SSN, the type of report requested, and the SKC. Again, the system compares this identification data with valid identification data in the database. If the information that has been entered in the various input fields corresponds to valid identification data in the database, the verifier  16  will be issued a report as requested. The report will be sent to the verifier  16  over the Internet  20 , as previosly described. The service provider  14  generates a standard report containing employment data and transmits the report to the verifier  16 . The format and content of standard reports are selected by the service provider  14  but the verifier  16  selects the type of report it needs. In practice, applicant has found it useful to offer a variety of standard reports at different price points. The verifier  16  can then select the type of standard report that is most practical for their particular purpose and then pays the verifier for each report.  
         [0088]    Applicant currently offers three standard reports to verifiers  16  called Basic, Basic+, and Full, as well as other reports for governmental agencies. The Basic report has the lowest price point, Basic+ has an intermediate price point and the Full report is the most expensive. A mortgage company that is contemplating a large home loan may be willing to pay for the Full report. In contrast, a furniture company that is making a loan for a sofa may only be willing to pay for the Basic report. Offering several different types of reports at different price points gives the verifier  16  a choice. A description of these three standard reports follows. Other reports with different types of employment data are also within the scope of this invention. These reports are therefore mere examples and not limitations on the invention.  
         [0089]    The Basic report currently contains the following employment data: date of verification (supplied by the system), current as of date (date of last data update or employer pay date), employer name, employee name, employee&#39;s SSN, employment status (active, inactive, retired, etc.), employee&#39;s most recent start date, total time in years and months the employee has been with the employer, current job title, and verification reference number (supplied by the system). A sample of the Basic report is included as FIG. 12. Currently no SKC is required by TALX to obtain a Basic report.  
         [0090]    The Basic+ report currently contains the following employment data: date of verification (supplied by the system), current as of date (date of last data update or employer pay date), employer name, employee name, employee&#39;s SSN, employment status (active, inactive, retired, etc.), employee&#39;s most recent start date, total time in years and months the employee has been with the employer, current job title, employee&#39;s rate of pay (hourly, weekly, etc.), average hours worked per pay period, and verification reference number (supplied by the system). A sample of the Basic+ report is included as FIG. 13. A Basic+ report requires the use of a SKC because it contains salary information.  
         [0091]    The Full report currently contains the following employment data: date of verification (supplied by the system), current as of date (date of last data update or employer pay date), employer name, employee name, employee&#39;s SSN, employment status (active, inactive, retired, etc.), employee&#39;s most recent start date, total time in years and months the employee has been with the employer, current job title, employee&#39;s rate of pay (hourly, weekly, etc.), average hours worked per pay period, employee&#39;s year-to-date pay information, previous years income information, previous two years income information (current, previous, and two years previous income information is broken down at the option of the employer, into the following categories; base pay, overtime pay, bonus, commissions, other pay, and total pay), likelihood of bonus (optional), next projected date of pay increase (optional), last date of pay increase (optional), next projected amount of pay increase (optional), last amount of pay increase (optional), on leave start date (optional), on leave stop date (optional) and verification reference number (supplied by the system). Optional data may or may not be supplied by the employer and is left to their discretion. All optional and required data that is supplied by the employer to the system is in the report. A sample of the Full report is included as FIG. 14. A Full report requires the use of a SKC because it contains salary information.  
         [0092]    At the service provider&#39;s option, an SKC may or may not be required for access to a particular report. As currently practiced by applicant, the SKC is required for a Full report and a Basic+ report, but is not required for a Basic report or a Public Assistance report. At the employer&#39;s option the use of an SKC may be required for a Basic report.  
         [0093]    A reference number record is created for each report that is sent to the verifier  16 . A billing record is entered in the system database. If an SKC has been used, it is inactivated.  
         [0094]    [0094]FIG. 15 is a flowchart of the software that is used when a governmental agency logs in for the purpose of determining whether public assistance should be granted. The governmental agency verification process uses a different URL not accessible from the home page of other verifiers. A login screen is presented with various input fields including the State ID number and the authorized user&#39;s ID number. The State ID number identifies the state wherein the governmental agency resides and the authorized user&#39;s ID number may identify various agencies/users from offices of a State within a given geographical area.  
         [0095]    For example, State ID 53 refers to Texas. The user ID 123456 has two components, 123 identifies a specific governmental agency, 456 identifies a person who is an authorized user within the specific governmental agency. The State ID number and the authorized user&#39;s ID number entered on the login screen will be compared against valid State ID numbers and valid authorized user ID numbers in the database. If there is a match, another screen will be presented to the user for processing its request. Other types of identification codes unique to an agency/user are within the scope of this invention.  
         [0096]    During the governmental agency login process a governmental agency user may make up to three attempts to login. If for whatever reason, i.e., mis-typed State code, forgotten Authorized User ID, etc., login is not achieved the governmental agency user sees a message screen telling him that login was unsuccessful and allows him to attempt login again. If after three attempts the governmental agency user has not sucessfully logged in, the governmental agency user sees a meesage screen telling him that he is locked out of the system for a period of thirty minutes. The web application writes a lock out record for this governmental agency user to the primary database  32  as previously described. Upon the next attempt to login, the system compares the date and time stamps on any lock out records for the governmental agency user to the system date and time. If at least thirty minutes have passed since the lock out record was written, the governmental agency user may again attempt to log into the system. If at least thirty minutes have not passed the governmental agency user sees a lock out message screen and is not allowed to attempt login. This lock out feature enhances governmental agency security by preventing long periods of login attempts for the purpose of trying unlimited combinations of ID information, either manually or via a software program, to discover a valid combination of State ID and authorized user ID and to surreptiticiously gain system access. Other types of lock out methodology unique to each service provider are within the scope of this invention.  
         [0097]    [0097]FIG. 16 is a flowchart of the system software for a governmental agency request for a verification. The user selects the applicants employer  10  from a drop down menu that displays a list of employers  10 . The user then enters the public assistance applicant&#39;s SSN. If the information selected and entered is validated against corresponding information in the service provider  14  primary database  32 , a governmental report will be generated.  
         [0098]    The public assistance report contains the following employment data: date of verification (supplied by the system), current as of date (date of last data update or employer pay date), employer name, employee name, employee&#39;s address (optional), employee&#39;s SSN, employment status (active, inactive, retired, etc.), employee&#39;s most recent start date, total time in years and months that the employee has been with the employer, current job title, employee&#39;s rate of pay (hourly, weekly, etc.), average hours worked per pay period, totay pay for current year, total pay for previous year, total pay for previous second year, twelve pay periods of pay period ending dates, pay dates, hours worked and gross earnings, medical insurance coverage (yes/no, optional), medical insurance carrier (optional), dental insurance coverage (yes/no, optional), dental insurance carrier (optional), and verification reference number (supplied by the system). Public assistance verifications are only available to governmental agencies, not the general verifying community. A sample public assistance report is included as FIG. 17. Other public assistance reports with different types of employment data are also within the scope of this invention. This public assistance report is therefore merely an example and not a limitation on the invention.  
         [0099]    Social Security Search is a system function that lists all incidents of an employee&#39;s SSN on the system and is composed of; date of request, employee&#39;s  12  SSN, companies  10  that the SSN was found under, and employment status for each company. The SSN search function is only available to governmental agencies, not the general verifying  16  community. A sample of the Social Security Search report is included as FIG. 18.  
         [0100]    [0100]FIG. 19 is a flowchart explaining how the system software allows the employer  10  to gain access to the system for a specific function including blocking or unblocking a particular employee&#39;s  12  records, making changes to employee&#39;s  12  status to activate or inactivate the employee, to enter new term date information for the employee  12  and to update employee  12  records. A login entry screen is presented to the employer  10  with a drop-down menu containing a list of all employers  10 . The employer  10  selects their company. The login screen displays a single input field for a company personal identification number (PIN). The system will compare the selected company&#39;s company code and the entered company PIN with valid company codes and valid company PINs in the system database. If there is a match, another screen will be presented for the various employer  10  functions. During the employer  10  login process an employer  10  may make up to three attempts to login.  
         [0101]    If for whatever reason, i.e., mis-typed company PIN, forgotten company PIN, etc., login is unsuccessful, the employer  10  sees a message screen telling them that login was unsucessful and allows them to attempt to login. If after three attempts the employer  10  has not sucessfully logged in, the employer  10  sees a message screen telling them that they are locked out of the system for a period of thirty minutes. The web application writes a lock out record for this employer  10  to the primary database  32  as previously described. Upon the next attempt to login, the system compares the date and time stamps on any lock out records for the employer  10  to the system date and time. If at least thirty minutes have passed since the lock out record was written, the employer  10  may again attempt to log into the system. If at least thirty minutes have not passed the employer  10  sees a lock out message screen and is not allowed to attempt login. This lock out feature enhances employer  10  security by preventing long periods of login attempts for the purpose of trying unlimited combinations of ID information, either manually or via a software program, to discover valid combinations of employer ID information and surreptitiously gain system access. Other types of lock out methodology known to those skilled in the art are within the scope of this invention.  
         [0102]    [0102]FIG. 20 is a flowchart for the software for the various employer  10  functions. The various input fields are displayed on the input screen for the employer&#39;s  10  use. The employer  10  may select to block or unblock data for a particular employee  12  at the employee&#39;s  12  request. If an employee  12  is no longer employed during a pay cycle, the employer  10  can change the employee&#39;s  12  status from active to inactive and vice versa. A new employment end date may also be entered and the employee&#39;s  12  information updated.  
         [0103]    Record blocking refers to the system function that will allow subscribing employers  10  to make any employee  12  record inaccessible for whatever reason. For legal reasons, an employer  10  may block an employee  12  record at any time. Any employee  12  record blocks placed by the employer  10  will remain in place until removed by the employer  10 . Record blocks are under the sole control and discretion of the employer  10  and the employee  12 .  
         [0104]    Termination date change refers to the system function that will allow employers  10  to change an employee&#39;s  12  termination date. Employers  10  may change a termination date on any employee  12  at any time. The use of this system function insures that employees  12  suddenly terminated or with termination dates reported incorrectly can be maintained outside of the normal payroll cycle data update.  
         [0105]    Status Code Change refers to the system function which will allow subscribing employers  10  to change an employee&#39;s  12  status code. The system supports a number of status codes that function to disclose an employee&#39;s  12  employment status; active, inactive, on leave, part-time, as needed, etc. Employers  10  may change the status code of an employee  12  at any time. The use of this system function insures that employees  12  with changes to their employment status can be maintained outside of the normal payroll cycle data update, i.e., an employee  12  has a system status code indicating that he/she is actively employed at the time of the last employer&#39;s  10  data download. If prior to the next data load, the employee  12  resigns, is laid off, etc., the employer  10  may access the system and change the employee&#39;s  12  status code to one that properly indicates that the employee  12  is no longer actively employed by employer  10 .  
         [0106]    At the completion of any of the employer  10  functions listed above a transaction record and employee  12  data update is written to the primary database  32 .  
         [0107]    Reference number refers to a unique identifying number that the system assigns to every verification performed by the system. The reference number may be used by a verifier  16  to audit the validity of a verification at some future date. At the time that a reference number is assigned by the system, the current data provided for that verification is retained in toto in primary database  32 . By accessing the system via the Internet  20 , a verifier  16  may request an audit by reference number verification. The verification received will be an exact duplicate of the original verification. Use of audit by reference number is generally by a party not directly involved in the original verification.  
         [0108]    For example, AJAX Mortgage wishes to sell a loan to a secondary market, the purchaser of that loan wants to verify that the loan was made appropriately, following accepted guidelines, and that no collusion with the borrower has occurred. The purchaser of the loan may access the system via the Internet  20  and request verification based on the reference number. Comparison of the audit by reference number verification to the original verification will reveal that the verification used as part of the underwriting criteria for making the loan is indeed valid and has not been modified or changed, thus preventing fraud.  
         [0109]    [0109]FIG. 21 is a flowchart for the system software whereby an employee  12  can update or change their PIN in the database. An entry screen is presented to the employee  12  with various input fields, including a field to enter an old PIN and a new PIN. Upon entering the old PIN, the new PIN, and re-typing the new PIN to confirm it, the old PIN entered is validated against existing PINs in the database. If the old PIN is correct and the new PIN matches the re-typed new PIN, the employee  12  sees a message screen that their PIN has been successfully changed, and the employee PIN record in the primary datase  32  is updated. For security reasons, PIN entries are never displayed as the numbers entered, but rather appear as stars. This method of allowing PIN changes and not displaying entries is well known to those skilled in the Art.  
         [0110]    [0110]FIG. 22 is a block diagram of an alternative embodiment of this invention. This block diagram differs from the diagram in FIG. 1 because the duties and functions of the service provider  14  have been subsumed by the employer  10 . In this alternative embodiment, the database servers are maintained by or for the employer  10  and the employer  10  may or may not charge for reports generated. This alternative embodiment provides a system to an employer  10  that wishes to keep the traditional verification process in-house, or at least partially in-house.  
         [0111]    In this alternative system, the employer  10  loads the employment data directly on to the employer&#39;s database servers  110  and  112  and updates them on a periodic basis in the same fashion as it would if this employment data was being transferred to the database servers  32  and  34  of the service provider  14 . However, in this alternative embodiment, the database servers  110  and  112  are located at the employer&#39;s  10  place of business or are maintained by a third party on behalf of the employer  10 . If required, the employee  12  accesses the database servers  110  and  112  for assignment of an SKC, if an SKC must be disclosed to the verifier  16 . The verifier  16  accesses the employer  10  databases  110  and  112  and upon entry of valid identification codes and a valid SKC, if required, will receive a report as requested. If a fee is charged by the employer  10 , it is paid by the verifier  16 . In this alternative embodiment, the connections made between the employee  12 , verifier  16  and employer  10  may or may not utilize SSL technology for encryption. Other types of encryption methods known to those skilled in the art are within the scope of this invention.  
         [0112]    [0112]FIG. 23 is a block diagram showing the Internet  20  connection between the verifier  16  and the employer&#39;s  10  primary database server  110  and redundant database server  112 . The verifier  16  enters the URL for the employer&#39;s  10  web site and establishes a connection over the Internet  20 . The employer  10  is connected via pipes  100 , for example, T1 lines, to the employer&#39;s router  102 . The inquiry from the verifier  16  then moves from the router  102  to the firewall  104 , to the web server  106 , back to the firewall  104 , to the ethernet  108 , to the employer&#39;s primary database server  110  and redundant database server  112 . If the identification codes and the SKC are validated by the employer  10  database server  110 , a report will be generated for the verifier  16 . The report moves from the ethernet  108  to the firewall  104  to the web server  106 , back to the firewall  104  and through the router  102  as indicated by the arrows in the drawing. The report then moves through the pipes  100  to the Internet  20  and back to the verifier  16 . In this alternative embodiment, the connections made between the employee  12 , verifier  16  and employer  10  may or may not utilize SSL technology for encryption. Other types of encryption methods unique to each employer  10  are within the scope of this invention.  
         [0113]    [0113]FIG. 24 is an alternative embodiment of the verification system of FIG. 5. In FIG. 5, multiple verifiers  16 , 17  simultaneously access the service provider  14  over the Internet  20  and upon authorization, reports from multiple employers  10  are sent back over the Internet  20  to the verifiers  16 ,  17 . In FIG. 5, the primary database server  32  and the redundant database server  34  are located at the service provider&#39;s place of business or they are maintained offsite under the servicer provider&#39;s  14  control. In the alternative embodiment of FIG. 24, the primary database server  121  is located at the employer&#39;s  10  place of business or offsite under the employer&#39;s  10  control. This alternative configuration is attractive to employers  10  that do not wish to relinquish control of their employment data to a third party, i.e., the service provider  14 .  
         [0114]    In the alternative embodiment of FIG. 24, the verifiers  16 ,  17  enter the URL for the service provider  14 , previously described. A properly authorized request is sent over ethernet  28  to a router  22  which accesses the employer  10  database  121  over a connection, for example, a leased telephone line  124 . The employment data for a report is sent from the employer database  121  over leased line  124 , through router  120  across ethernet  28  to firewall  24  to the service provider web server  25  where a report, previously described, is generated and sent back to the firewall  24 , through router  22  and connection  21  to the Internet  20  and finally to the verifiers  16 ,  17 . In this alternative embodiment the connections made between the employee  12 , verifier  16 , service provider  14  and employer  10  may or may not utilize SSL technology for encryption. Other types of encryption methods known to those skilled in the art are within the scope of this invention.  
         [0115]    The service provider  14  typically will have the followig hardware/software at its place of business: router  22 , firewall  24 , web server  25 , ethernet  28  and router  120 . The employer  10  will have the following hardware/software at its place of business: router  122  and employer database server  121 .
The method for verifying employment data provides a quick and convenient means for a mortgage company to verify salary and employment data for a loan applicant. The system may be used by any entity that needs to verify salary and employement data, such as furniture companies, subprime lenders and apartment rental agencies. The system is of benefit to large employers that wish to out-source this verification process. Employee data is transmitted from an employer to a service provider. In some situations, the loan applicant (an employee) contacts the service provider to obtain a salary key code ("SKC"). The SKC is disclosed to the mortgage company or other verifier. The verfiier contacts the service provider and upon presentation of a valid SKC and identification data, the verifier is provided with a report containing employment data. In the preferred mode, all of these interchanges occur over the Internet. In an alternative embodiment, a governmental agency can access the service provider to obtain employment data to aid in its decision of whether to grant public assistance. In another alternative embodiment, the employer can perform all of the functions of the service provider and verify inquiries for employment data itself.