Patent Publication Number: US-2015081341-A1

Title: Computerized Method, Apparatus and System for Issuing Surety Bonds

Description:
CROSS REFERENCES TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 13/326,616, filed on Dec. 15, 2011, which is a continuation of U.S. patent application Ser. No. 11/701,127, filed on Feb. 1, 2007, which is a continuation of U.S. application Ser. No. 09/694,776, filed on Oct. 23, 2000, which claims priority on U.S. Provisional Patent Application Ser. No. 60/161,212, filed Oct. 22, 1999. 
    
    
     FIELD OF THE INVENTION 
     The present invention is in the field of improvements in the issuance of surety bonds and related products. 
     BACKGROUND OF THE INVENTION 
     By the term surety bond is generally meant a bond issued by an insurance or other company as surety on behalf of a principal whereby the surety legally binds itself to an obligee for an amount of money guaranteed to the obligee for the faithful performance of a contract or other act of the principal. The bonds of the present invention can include bid bonds, contract, court and subdivision bonds, performance bonds, customs bonds, notary bonds, liquor license bonds, license and permit bonds, small business administration bonds, bail bonds, supersedeas bonds or other bonds required in litigation, etc. Also applicable to the invention are binding certificates of insurance and policy endorsements and other insurance related documentation. 
     When a contractor, builder or supplier etc. wishes to bid on a construction project or submit a bid in connection with a governmental purchase of equipment or supplies the entity seeking bid typically requires that for a bidder to be considered for the job a bid bond must be submitted with the bid. Many municipalities have their own bid form and others use a format approved of by the American institute of Architects. In the typical bid bond the principal is the person who is submitting the bid. The surety is typically an insurance or bonding company who pursuant to the bond is “held and firmly bound” to the entity seeking the bid for a predetermined sum, usually some percentage of the bid amount. In the event the bid is accepted the bond becomes effective and protects the entity awarding the contract by assuring the entity of faithful performance of the contract as well as prompt payment of labor and materials furnished in performing the contract. In addition, the bond protects the bid seeking entity from the failure of the winning bidder from ultimately entering into the contract that is being awarded by paying the difference between the winning bid and the amount that the entity would have to pay to another party to complete the project because of the default. 
     Each bidder submits a bid bond with its bid in the appropriate form decided upon by the entity seeking the bids. In the event the wrong form of bid bond is used the party submitting the bond runs the risk that the entity soliciting the bonds will reject the bid out of hand even if the person submitting the bond was the low bidder. Many agencies soliciting bids are reluctant to accept a bid with an improper bid bond form because there is a risk that the losing bidders who submitted the proper form may challenge the agency if it awards the bid to based on an improper bid form. 
     When a contractor, for example, is submitting a bid, much of the contractor&#39;s effort is spent massaging the bid to make sure the contractor has a bid that he considers is his best far the particular job. Since much of the pre bid effort is spent calculating and recalculating material and/or labor costs, frequently a bid bond is not sought by the contractor until just before the bidding deadline. In addition, many contractors are bidding on a plurality of jobs at a time. Furthermore, for many projects and contracts there are multiple bidders bidding on the project. For the non winning bidders their bond terminates and only the winning bidder&#39;s bond has any effect. As a result a great deal of effort has to be done in a short period of time to prepare multiple bonds. 
     Surety companies typically rely on local agents to receive the bond request and process the necessary paper work to complete the bid bond. For certain bond requests where the amount of the bond request is low the agent may have authority to issue a bond without approval from the surety company. For other requests the surety company must approve the bond requests. One of the problems that agents have in submitting bonds for approval is that the requests are typically faxed to a central location at the surety company where they sit for an extended period of time before the request is presented to the proper person for approval of the request. Once the bond request is approved, the agent must prepare the actual bond which must be signed by the agent on behalf of the surety company. In order to save time in the process many surety companies provide their agents with executed powers of attorney for them to retain at their offices until needed. While this procedure saves considerable time in the procedure of issuing bonds there is also the risk that an agent could issue a bond inappropriately to an unsatisfactory party. While the procedure described above is for bid bonds, the current steps and procedures for issuing other types of bonds are similar. 
     As a result of the time deadlines and security issues in the current methods and procedures for issuing bonds there is a need for improved methods and apparatus for obtaining bonds. 
     OBJECTS OF THE INVENTION 
     It is an object of the invention to provide a method of obtaining bonds using a computer system. 
     It is an object of the invention to provide a system and apparatus for computerizing the issuance of bonds. 
     It is an object of the present invention to provide increased security in the issuance of bonds. 
     It is an object of the invention to improve the time necessary for issuing bonds. 
     SUMMARY OF THE INVENTION 
     The invention is directed to improved methods, apparatus and system for issuing and transmitting surety bonds, including but not limited to bid bonds, contract, court and subdivision bonds, performance bonds, customs bonds, notary bands, liquor license bonds, license and permit bonds, small business administration bonds, bail bonds, supersedeas bonds or other bonds required in litigation, etc. The present invention also has applicability in the field of insurance and other businesses including but not limited to binding certificates of insurance and policy endorsements. The invention relates generally to computerized systems and more particularly to a computerized system for automated issuances of bonds through a communications linkage for communicating and processing information necessary for the issuance of a bond in a timely and efficient manner. The invention also relates to a system for the collection, processing, and dissemination of bond related information generated from the application process. 
     The present invention is a computerized system for automated execution of bonds through an Internet or Intranet website or other communications linkage for communicating and processing information. In addition, the present invention permits designated persons to view approved bonds from remote locations as a security feature. In order to log onto the system a user account and/or password are inputted. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  shows a block diagram of a representative computer system that would be used by the user to access information over a network such as an LAN, Wan, the Internet or an Intranet. 
         FIG. 1B  is a block diagram of a system that allows access to a software application of the present invention over the World-Wide Web from a standard web browser; 
         FIG. 1C  is a view of a representative logon page for access to the system. 
         FIG. 2  is a view of a representative agency main menu for the system. 
         FIG. 3  is a view of a representative agency pending bond search page for the system. 
         FIG. 4  is a view of a representative surety pending bonds page for the system. 
         FIG. 5  is a view of a representative pending bond page for the system. 
         FIG. 6  is a view of step  1  on a representative new bond page for the system. 
         FIG. 7  is a view of step  2 , the contractor search, for the preparation of a new bond. 
         FIG. 8  is a view of step  3 , the selection of the surety, for the preparation of a new bond. 
         FIG. 9  is a view of the page of  FIG. 8  with additional information added. 
         FIG. 10  is a view of a verification page for the new bond. 
         FIG. 11  is a view of an approved bond. 
         FIG. 12  is an enter contractor page which permits the agent to place his contractor information in the system prior to needing the information for a bond. 
         FIG. 12A  is a contractor search page. 
         FIG. 13  is a page listing approved employees of the agency. 
         FIG. 14  is a page for identifying the approved employees of the agency. 
         FIG. 15  is a representative page for an obligee to logon to view executed bid bonds. 
         FIG. 16  is a representative page for the obligee to submit the contractor code to view a contractors bond information. 
         FIG. 17  is a representative page showing the executed contractor&#39;s bond. 
         FIG. 18  is a flow chart showing the main client navigation. 
         FIG. 19  is a representative login dialog. 
         FIG. 20  is a flow chart showing the Managers section of the program. 
         FIG. 21  is a representative Manager&#39;s information form. 
         FIG. 22  shows a flow chart for the Sureties section of the program. 
         FIG. 23  shows a representative update form. 
         FIG. 24  shows a representative form used to add divisions. 
         FIG. 25  shows a representative form to add a surety 
         FIG. 26  depicts a representative form to add new employees of the surety to the system. 
         FIG. 27  shows a flow chart for the Sureties section of the program 
         FIG. 28  shows a representative form to update Agency information. 
         FIG. 29  shows a representative form to add subsidiaries. 
         FIG. 30  shows a representative form to add new employees of the surety to the system. 
         FIG. 31  shows a representative preferred contractor form. 
         FIG. 32  show a representative flow chart for the contractors section of the program. 
         FIG. 33  shows a representative form used to Add a Contractor. 
         FIG. 34  shows a representative format used to add new employees of the contractor into the system. 
         FIG. 35  show a representative flow chart for the owners/obligee section of the program. 
         FIG. 36  shows an add employees form used to add new employees of the owners/obligees into the system. 
         FIG. 37  shows a representative flow chart for the bonds. 
         FIG. 38  shows a representative form used to update existing surety information. 
         FIG. 39  shows a representative form used to add surety divisions appears in  FIG. 39 . 
         FIG. 40  shows a representative form that may be used to update agency information. 
         FIG. 41  shows a form to add agency subsidiaries. 
         FIG. 42  depicts a representative Database table layout. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In the present invention the agent or other person seeking a bid bond or any other bond has a password and/or account number in order to logon to the system from a remote location using the Internet, an Intranet or other communication means.  FIG. 1A  and  FIG. 1B  show representative computer systems that may be used by the agent in connection with the present invention. The present invention is directed to a system and more preferably a computer network for accessing the information on a network, such as the Internet. The term computer network as used herein is used in its broadest sense, i.e., as any configuration of data processing devices and software connected for information exchange. The present invention can include personal computers, personal digital assistants (PDA&#39;s), set top boxes used on or in connection with televisions, and any other type of appliance that can access a collection of data such as the Internet. 
     In one embodiment the appliance can include a network that serves to connect together a plurality of devices, e.g., terminals, computers, etc. Networks typically comprise a plurality of devices such as computers some of which function as servers to provide services to the other computers connected to the network. There are many types of computer networks in existence. They are known by various names including Local Area Network (LAN), Wide Area Network (WAN), Internet and the like and may be implemented in accordance with a variety of known architectures. 
     Referring to  FIG. 1A , in one embodiment of the invention there is a typical transaction between a standard web browser or other communications software  212  running on a client workstation  210  and a web server or other software application permitting communication with said workstation  222  running on a computer system  220  occurs over a connection (communication link or communication mechanism)  216 . Client workstation  210  may be coupled to other computer systems via a local area network (LAN) or via any other type of computer network or other interconnection. Likewise, computer system  220  may be coupled to other computer systems as well. Client workstation  210  may be any computer that is capable of providing access to a local area network (LAN) or via any other type of computer network or other interconnection to the WWW by using web browser or other communications software  212 . This would include handheld, portable or laptop computers, standard desktop computer systems, etc. 
     Web browser  212  is a software program running on client workstation  210  that allows a user at client workstation  210  to communicate with other computers over connection  216 . Web browser  212  would include but is not limited to any web browser, which is capable of transmitting and receiving data over the WWW. This includes commercial software applications such as IBM&#39;s WebExplorer, Internet Netscape. Navigator, Microsoft Explorer, Apple Computer&#39;s CyberDog, and any other software application which now exist or which may be developed in the future for accessing or processing information over the WWW. The preferred embodiment for connection  216  is any suitable communication link or communication mechanism to the Internet, including by telephone, cable lines or other hard wired method, infrared or other wireless communications, wireless computer network communications, or any other suitable connection between computers, whether currently known or developed in the future. 
     It should be noted that client workstation  210  and web server computer system  220  may be the same physical and/or logical computer system. Web browser  212  typically displays pages of data including but not limited to data in the form of HTML, XML, XHTML or their future incarnations to a user at client workstation  210 . Other types of data (besides HTML) may also be transmitted to web browser  212 , including text data, graphical data (e.g., Graphic Image Format (GIF) files), audio data or sound files (e.g., WAV files), Java applets (executable code) and a specialized data form known as Multipurpose Internet Mail Extensions (MIME) data (which may include combinations of the foregoing and other data types). 
     Web server application  222  is a software program running on web server computer system  220  that allows a user at client workstation  210  to access information controlled by web server  220 . One preferred embodiment of web server application  222  in accordance with the present invention is a commercial web server application such as IBM&#39;s Internet Connection Server. Other applications are also compatible with the present invention. Web server computer system  220  typically outputs pages of HTML data to WEB browser  212  in response to requests by web browser  212  that reflect action taken by the user at client workstation  210 . In addition, as explained above, web server computer system  220  may output other types of data to web browser  212  as well. Output data may include static HTML pages (meaning that the content of the page does not vary), or may include data that must be dynamically determined and inserted into the output data. Web server application  222  may dynamically build output data (e.g., an HTML page) from parts that it retrieves from memory within web server computer system  220  or from other computer systems, or may simply pass through a page that has been constructed at an earlier time or by another computer. 
     Web browser  212  typically interacts with web server application  222  by transmitting input (e.g., a Uniform Resource Locator (URL) or an HTML page) over connection  216  to web server computer system  220 . This input is typically transmitted using HyperText Transfer Protocol (HTTP) 1.0. Web server computer system  220  running web server application  222  receives the input from web browser  212 , and in response, outputs data (e.g., an HTML page) to browser  212 . Web server computer system  220  may also have numerous other software components, including Common Gateway Interface (CGI) programs or modules, for performing desired functions. The process described above illustrates a basic transaction over the Internet, recognizing that many details and variations that are within the scope of the present invention are not disclosed herein for the purpose of providing a simple context for understanding the concepts of the present invention. 
     In a preferred embodiment, the user seeking a bond accesses the web site of the bonding agency usually by inputting a URL for the appropriate web site. The web page is displayed on the monitor of client workstation  210 . Web pages are generally written in Hypertext Markup Language (HTML). However, they can be written in XML, XHTML or their future incarnations. When web server application  222  running on web server computer system  220  receives a web page request, it will build a web page in HTML or retrieve a file containing a pre-built web page and send it off across connection  216  to the requesting web browser  212 . Web browser  212  understands HTML and interprets it and outputs the web page to the monitor of client workstation  210 . This web page displayed on the user&#39;s screen may contain text, graphics, and links (which are URL addresses of other web pages.) These other web pages (i.e., those represented by links) may be on the same or on different web servers. The user can retrieve these other web pages by clicking on these links using a mouse or other pointing device. This entire system of web pages with links to other web pages on other servers across the world collectively comprises the “World-Wide Web” (WWW). 
     Referring now to  FIG. 1B , a computer system in accordance with one embodiment of the present invention may include: one or more Central Processing Units (CPUs)  110 ; a terminal interface  150 ; an auxiliary storage interface  160 ; a workstation  170 ; a Direct Access Storage Device (DASD)  180 ; a floppy disk  190 ; a bus  140 ; and a memory  130  which includes multiple locations for containing various software programs. In this example, memory  130  includes a web browser  212  running in location  132 , a web server application  222  running in location  134 , an Internet/application gateway program  332  running in location  136 , and a software application  342  running in location  138 . 
     CPUs  110  perform computation and control functions of system  100 . All CPUs associated with system  100  may each individually comprise a single integrated circuit, such as a microprocessor, or may comprise any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a central processing unit. All CPUs are capable of suitably executing the programs contained within memory  130  and acting in response to those programs or other activities that may occur in system  100 . 
     Memory  130  is any type of memory known to those skilled in the art. This would include Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash memory, cache memory, etc. While not explicitly shown in  FIG. 3 , memory  130  may be a single type of memory component or may be composed of many different types of memory components. For example, web browser  212  running in location  132  may be part of system  100 &#39;s cache memory. In addition, memory  130  and CPUs  110  may be distributed across several different computer that collectively comprise system  100 . For example, web browser  212  may reside on one computer with CPU, web server application  222  may reside on another computer system with a separate CPU.sub.2, Internet/application gateway  332  may reside on a third computer system with a different CPU.sub.n−1, and software application  342  may reside on a fourth computer with a different CPU.sub.n. Computer system  100  of  FIG. 3  simply illustrates many of the salient features, without limitation regarding the physical location of CPUs  110  or memory locations within memory  130 . 
     Bus  140  serves to transmit programs, data, status and other forms of information or signals between the various components of system  100 . The preferred embodiment for bus  140  is any suitable physical or logical means of connecting computer systems and components known to those skilled in the art. This includes, but is not limited to, direct hard-wired connections, Internet connections, Intranet connections, fiber optics, infrared (IR) and other forms of wireless connections. It is anticipated that many alternative methods and material for connecting computer systems and components will be readily adapted for use with the present invention. This would include those methods and materials not presently known but developed in the future. 
     Terminal interface  150  allows human users to communicate with system  100 , normally through programmable workstation  170 . Although system  100  as depicted in  FIG. 11  contains only a single workstation  170 , it should be understood that the actual number of workstations attached to system  100  will be a function of system design and user preference. Workstation  170  may also be a dumb terminal or other non-programmable computer input/output device which allows human interaction with computer system  100 . 
     Auxiliary storage interlace  160  represents any method of interfacing a storage apparatus to a computer system known to those skilled in the art. Auxiliary storage interface  160  allows auxiliary storage devices such as DASD  180  to be attached to and communicate with the other components of system  100 . While only one auxiliary storage interface  160  is shown, the present invention anticipates multiple interfaces and multiple auxiliary storage devices such as DASD  180 . As shown in  FIG. 3 , DASD  180  may be a floppy disk drive which is capable of reading and writing programs or data on floppy disk  190 . DASD  180  may also be any other type of DASD known to those skilled in the art. This would include CD-ROM drives, hard disk drives, optical drives, etc. Floppy disk  190  represents a typical 3.5 inch magnetic media disk known to those skilled in the art. 
     The agent using the present invention is pre-approved by a surety company just as the agent is currently pre-approved by one or more surety companies. Under the present invention the agent is not provided with a number of executed power of attorney forms by the surety company as is done with the present system. This avoids the risk of the agent granting unauthorized bonds. As seen in  FIG. 1C , the agent inputs the user name and the password to access the system. Once this data is typed, the user may be logged in. 
       FIG. 2  depicts the main menu which appears after login. The system has identified the user and the date. Once logged in properly the user can navigate any part of the system. Once the agent supplies his or her password and/or account number the agent has access where the agent can obtain a new bond, search for an approved bond, including older bonds, check on the status of a pending bond or search for a dead bond. The system is designed so that the agent will only have access to information only on those bonds which he is authorized to view. In the event the agent seeks a new bond, each bond request is entered into the system by the agency. The information inputted for each new bond typically includes the name of the contractor, its address, the identity of the owner/obligee for whom the bond is required, the bond form required, the owner/obligee&#39;s address, the bid date, the estimated contract price, the amount of the bid security, the contract number or IFB number, and a description of the job. A representative screen for a new bond is shown in  FIG. 6 . Once this information is inputted into the system the bond information the program provides a list of sureties surety where the agent has been authorized and the agent selects the surety from the list. The obligees typically include governmental agencies, private owners, construction managers, and/or general contractors  FIG. 8  and  FIG. 9 . In the event there are more than one contractors with the same name a screen similar to  FIG. 7  may appear in order for the choice to be narrowed down to the appropriate selection. 
     One advantage of the invention is that the surety can rescind the agent&#39;s authorization at any time from the website, thus preventing unauthorized bonds being issued. In the event a surety wants to cease doing business with one of its current agent, under the prior system the surety had to recall all of the outstanding powers of attorney and rely on the good faith of the agent to return all the existing executed powers of attorney that the surety had previously provided to the agent. Since an agent is usually dropped by a surety for malfeasance of misfeasance there was always a risk to the surety company as the agent could bind the company to unauthorized obligations with the existing executed powers of attorney. This problem is solved by the present invention since the surety no longer needs to supply the agents with pre-signed powers of attorney and the surety can remove an agent from its list of approved agents virtually instantaneously by access the program and removing the agent&#39;s authority. In that event the surety dropping an agent will not be identified as one of the sureties on the list for the agent to select. After selecting the surety, the agent can submit the bond for approval or the information can be retained in the system as a pending bond and can be submitted at a later time. 
     Once the agent selects the appropriate surety for the particular bid and the agent seeks approval, the agent is given an opportunity to check over the information included for errors.  FIG. 10  shows a representative screen for the user to review the key information before the bond is executed. The NAIC code identifies the surety. The date and time to the second can be archived at the time of execution on the screen of  FIG. 11 . If the information in  FIG. 10  is correct then the time of the application is recorded since many obligees require that a bond be obtained prior to a particular deadline and the bid information is transmitted directly to the appropriate person at the surety electronically. A cautionary notice should appear prior to approval of the bond. This warning will query the user to be sure that the bond is to be approved. When the bid information is transmitted to the appropriate person at the surety, that person&#39;s computer will provide a message that a bid has been received. This approach avoids the delays inherent in the prior system where facsimile transmissions of the bid information were relied on. Where a facsimile was used, the bid information would be transmitted to the fax machine which was not necessarily near the desk of the person with responsibility to act on the bid application. The agent would then have to wait until the bid was brought from the fax machine location to the surety&#39;s appropriate person. This added delays to the system that are avoided using the present invention. 
     Under the prior system of obtaining bonds once the bond was approved by the surety the agent would then have to put the paper work together and send it to the contractor. Since the bond was typically not requested by the contractor until just before the deadline delivery to the contractor usually required hand delivery or delivery by overnight courier with all the trouble that weather and other delays can engender. Under the present invention these problems are avoided. Once the bid is approved, the contractor is provided with a code number typically called an authorization code.  FIG. 11  is a screen that shows the electronic bond. The contractor places the code on his bid papers and submits them to the obligee at the bid letting. The obligee logs onto the system and provides the contractors authorization code to review the bid. The surety can also use the system to search bonds by number as seen in  FIG. 16 . The system also permits the surety to view, in real time all of the executed bonds of each agent for quality control purposes. Another advantage for the agent is that the agent can limit access to the system by limiting the individuals who access to the authorization code and/or password. Since the agent can change his password as necessary, the agent has more control over employees and can prevent certain employees from having access to the system. In addition, when an employee leaves employment the agent can change the password without having to worry about unauthorized access to bonds and bond information.  FIG. 12  is a contractor information screen for the contractor to input information.  FIG. 12A  is a screen to search for a contractor.  FIG. 13  is a screen for the agency to input employee information for the employee to have authority to issue bonds. Initially, once the surety approves of the agent one key person at the agency will be the authorized person at the agency for all bonds. This may be the owner manager or some other person. This key person can, if desired, grant sub-authorizations to other employees that permit these additional persons to issue bonds. The number of these sub-authorizations may be increased, decreased or terminated completely as needed. This authority can be readily cancelled if any impropriety is uncovered.  FIG. 14  shows a representative screen for the authorized employee of the agency to fill out to have access to the system.  FIG. 15  is a representative example of the log in page for the owner/obligee to access all the bonds information. For example, the name of the organization for whom the bonds were issued may be inserted and information on all of the selected executed bonds is accessed. No changes or transactions may be made to the bonds. 
     In  FIG. 3  an example of a screen for a user to search pending bonds is shown. The name of the contractor or the name of the owner/obligee is inserted and a search may be performed. In the event all pending bonds are to be searched, the fields are left blank and the user merely clicks the search box.  FIG. 4  shows an example of a listing of bonds in chronological order by the bid date. The list may be used as a daily or other work list of the bonds to be approved. The appropriate surety company can see the pending bond and accept it as a bid bond request.  FIG. 5  shows the screen for a pending bid bond. The screen lists all the necessary information in order for it to be approved.  FIG. 17  is an example of the electronic bid bond of the present invention. The exact date and time of the bid bond approval is archived. The name of the surety and the surety&#39;s NAIC code is identified. This code designates the exact surety and avoids the confusion of similar surety names. The name of the person who executed the bid bond is at the bottom. This form can be modified so that the necessary information for each jurisdiction is available. 
       FIGS. 18-42  show an alternate embodiment of the present invention.  FIG. 18  is a flow chart showing the main client navigation. 
     [C-01] Initial Login to BMS V2.0 
     The login requires the Manager, Surety, Agency, Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database. The representative login dialog appears in  FIG. 19   
     [C-02] Main Manager Section 
     If the user has manager access, the user will have the choice of adding a manager or searching for viewing existing managers by name 
     [C-03] Main Surety Section 
     If the user has Surety access, the user will have the choice of adding a Surety or searching for viewing existing Sureties by name 
     [C-04] Main Agency Section 
     If the user has Agency access, the user will have the choice of adding an Agency or searching for viewing existing Agencies by name 
     [C-05] Main Contractor Section 
     If the user has Contractors access, the user will have the choice of adding a Contractor or searching for viewing existing Contractors by name 
     [C-06] Main Bond Form Section 
     Lists all of the Bond forms for the company that the user logged in belongs to. 
     Managers [CM-01 Thru CM-04] 
       FIG. 20  is a flow chart showing the Managers section of the program. 
     [CM-01] Main Entry for Managers 
     If the user has manager access, the user will have the choice of adding a manager or searching for viewing existing managers by name. 
     [CM-02] Manager Search Results 
     Allows Managers to search managers within their company by first letter or by name. The user can also delete the manager&#39;s information from this page. 
     [CM-03] Add Manager Page 
     Allows users with mangers access to add managers within their company. The representative Manager&#39;s information form appears in  FIG. 21 . 
     [CM-04] Manager Action Script to Add, Update or Delete Manager Data 
     Called by the add manager above to execute additions, updates or deletions. 
     Sureties [CS-01 Thru CS-18] 
       FIG. 22  shows a flow chart for the Sureties section of the program 
     [CS-01] Surety Section Navigation 
     If the user has surety access, the user will have the choice of adding a surety or searching for viewing existing surety by name 
     [CS-02] Main Login Link 
     The login requires the Manager, Surety, Agency, Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database. 
     [CS-03] Bond Lookup 
     This page contains scripts needed to look up existing sureties and branches tied to the company ID of the logged in user. 
     [CS-04] List Surety Details 
     Allows the listing of surety details. This includes surety divisions and branches listed under the parent surety. 
     [CS-05] Edit Surety Information 
     Form used to update existing surety information. Representative update form appears in  FIG. 23 . 
     [CS-06] Add Surety Divisions 
     Contains form to add surety divisions. Representative form used to add divisions appear in  FIG. 24 . 
     [CS-07] Surety Action Script to Add, Update, Delete Surety or Add, Approve, Disapprove Divisions 
     This page is used to house scripts used to add, update, delete surety of add, approve, disapprove divisions 
     [CS-08] List Surety Branches 
     Form and logic used to display surety branches. The page also has an Add branches capability. 
     [CS-09] Add New Surety 
     Used to add a new surety. Representative form appears in  FIG. 25 . 
     [CS-10] Surety List of Approved Agencies 
     The user can list and select approved agencies from this page. The user can also view the agency, the division that the agency is in and the approved limit for that agency. New agencies can be added and existing agencies can be edited or removed. 
     [CS-11] Approved Surety Search Form to View Surety by Name 
     Search form to view approved surety by name. 
     [CS-12] Surety Approved Search Results 
     View search results for the view approved surety by name search. 
     [CS-13] List Surety Employees 
     Displays list of employees and their access level within the system. The access types are listed as administrator, Executive or Clerical. 
     [CS-14] Add Employees Form 
     The add employees form is used to add new employees of the surety to the system. A representative form is shown in  FIG. 26   
     [CS-15] Employees Add Action Script to Add Employee and Company Type 
     This script adds employees for all entities within the system (Agency, Principle, Contractors and Managers. It also checks for duplicate users within the system. 
     [CS-16] Preferred Contractors List by Name 
     Lists all preferred contractors for the logged in surety 
     [CS-17] Company Bond Form 
     Presents the appropriate bond form for the surety or agency 
     [CS-18] Company Bond Forms Action Script to Add Bonds to the Company Bonds Forms Database Table 
     Script used by the company bond form to add bonds to the system. 
     Agencies [CA-01 Thru CA-18] 
       FIG. 27  shows a flow chart for the Sureties section of the program 
     [CA-01] Navigation for Agency Section 
     If the user has Agency access, the user will have the choice of adding an Agency or searching for viewing existing Agencies by name 
     [CA-02] Link Back to Main Login 
     The login requires the Manager, Surety, Agency, Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database. 
     [CA-03] Bond Lookup 
     This page contains scripts needed to look up existing sureties and branches tied to the company ID of the logged in user. 
     [CA-04] Agency Details 
     Lists details of the agency such as Company name, Subsidiaries, Employees, Employee permissions and branches. 
     [CA-05] Update Agency Data 
     Contains form to update Agency information. A representative form used appears in  FIG. 28 : 
     [CA-06] Agency Subsidiaries Add and Lookup 
     Lists agency subsidiaries and provides a form to add subsidiaries. A representative add subsidiaries form appears in  FIG. 29 : 
     [CA-07] Contains Action Script to Update, Add Agency, Add Subsidiary or Delete 
     Uses input from the subsidiaries form above. Also is used to add or delete agencies and subsidiaries. 
     [CA-08] List and Add Agency Branches 
     This is used to list or add agency branches 
     [CA-09] Add Agency or Branches 
     Form used to add an agency or branches. 
     [CA-10] List of Agency Employees 
     Returns a list of agency employees 
     [CA-11] Employee Add Form 
     The add employees form is used to add new employees of the surety to the system. A representative form appears in  FIG. 30 . 
     [CA-12] Employees Add Action Script to Add Employee and Company Type 
     This script adds employees for all entities within the system (Agency, Principle, Contractors and Managers. It also checks for duplicate users within the system. 
     [CA-13] Search Preferred Contractors 
     Used to list preferred contractors by name 
     [CA-14] Preferred Contractors Search Results 
     Formats the above preferred contractor search results. Allows user to add preferred contractors as well. The form uses the federal tax id as the key for the search. The representative preferred contractor form appears in  FIG. 31 : 
     [CA-15] Preferred Contractor Action Script 
     This page contains scripts used to update the contractor, add the contractor or delete the contractor. This script also builds the contractor ID. 
     [CA-16] Preferred Contractors Add Results Form 
     Returns a list of preferred contractors in the system. User may also add preferred contractors from this form 
     [CA-17] Company Bond Form 
     Presents the appropriate bond form for the surety or agency 
     [CA-18] Company Bond Forms Action Script to Add Bonds to the Company Bonds Forms Database Table 
     Script used by the company bond form to add bonds to the system. 
     Contractors Area [CC-O1 Thru CC-07] 
       FIG. 32  show a representative flow chart for the contractors section of the program. 
     [CC-01] Contractor Main Navigation 
     If the user has Contractors access, the user will have the choice of adding a Contractor or searching for viewing existing Contractors by name. 
     [CC-02] Main System Login 
     The login requires the Manager, Surety, Agency, Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database. 
     [CC-03] Bonds Lookup—Look Up in Bid Bonds Table 
     This page contains scripts needed to look up existing sureties and branches tied to the company ID of the logged in user. 
     [CC-04] Contractor Details Lookup 
     Lists details of the contractor information such as Company name and address. 
     [CC-05] Contractor Employee Add, Update, Delete 
     Representative form used to Add Contractor is shown in  FIG. 33 . 
     [CC-06] Employee Add Form 
     The add employees form, a representative format which is shown in  FIG. 34 , is used to add new employees in to the system. 
     [CC-07] Employees Add Action Script to Add Employee and Company Type 
     This script adds employees for all entities within the system (Agency, Principle, Contractors and Managers. It also checks for duplicate users within the system. 
     Owners/Obligee Area [CO-01 Thru CO-07] 
       FIG. 35  show a representative flow chart for the owners/obligee section of the program. 
     [CO-01] Owner Main Navigation 
     Main navigation for users logged in as owners. 
     [CO-02] Main System Login 
     The login requires the Manager, Surety, Agency, Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database. 
     [CO-03] Get Owner Details and Search by Bond Number 
     Lists details of the contractor information such as Company name and address. This form also allows the user to search by bond number 
     [CO-04] Get Owner Bonds 
     List bonds for the logged in owner. 
     [CO-05] Owner Employees List 
     Lists the employees for the owner obligee. 
     [CO-06] Employee Add Form 
     The add employees form, a representative sample of which is shown in  FIG. 36 , is used to add new employees in to the system. 
     [CC-07] Employees, Add Action Script to Add Employee and Company Type 
     This script adds employees for all entities within the system (Agency, Principle, Contractors and Managers. It also checks for duplicate users within the system. 
     Bond Forms [CB-01-CB-16] 
     [CB-01] Bond Main Navigation 
     A representative flow chart for the bonds for is shown in  FIG. 37 . 
     [CB-02] Main System Login 
     The login requires the Manager, Surety; Agency; Principal or Contractor to enter their Company ID, Username and password. The username and password are encrypted and stored within the database 
     [CB-03] Login Action Script to Allow or Disallow Login 
     This scripts decides system login authentication logic then, directs the user to the appropriate area. 
     [CB-04] List Bonds for the Agency or Surety Logged in 
     Page Returns bonds for the agency or surety logged in 
     [CB-05] List Details of Surety 
     Allows the listing of surety details. This includes surety divisions and branches listed under the parent surety. 
     [CB-06] Edit Surety Information 
     Form used to update existing surety information. A representative update form is shown in  FIG. 38 . 
     [CB-07] Add Surety Divisions 
     Contains form to add surety divisions. A representative form used to add divisions appears in  FIG. 39 . 
     [CB-08] Surety Action Script to Add, Update, Delete Surety or Add, Approve, Disapprove Divisions 
     This page is used to house scripts used to add, update, delete surety of add, approve, disapprove divisions 
     [CB-09] Create New Bond Step  1   
     Search for a preferred contractor 
     New Bond Step  1 : Search for a Preferred Contractor 
     View Preferred Contractors By Name 
     [CB-10] Create Bond Step  2   
     New Bond Step  2 : Select Preferred Contractor from returned list. 
     [CB-11] Bond Step  3 : Enter Bond Information 
     [CB-11] List Agency Details 
     Lists details of the agency such as Company name, Subsidiaries, Employees, Employee permissions and branches 
     [CB-12] Update Agency Data 
     Contains form to update Agency information. A representative form that may be used appears in  FIG. 40 : 
     [CB-13] Agency Subsidiaries Add and Lookup 
     Lists agency subsidiaries and provides a form to add subsidiaries. The representative add subsidiaries form appears in  FIG. 41 : 
     [CB-14] Contains Action Script to Update, Add Agency, Add Subsidiary or Delete 
     Uses input from the subsidiaries form above. Also is used to add or delete agencies and subsidiaries 
     [CB-15] Contractor Details from Contractors Table 
     Lists contractor information from related to this particular bond. 
     [CB-16] Code to List and View the Bonds in the System 
     This code will list and display completed bonds in the system. 
     4.2 Server [S-01 Thru S-0X] 
     [S-01]. Server login—During the client login, the username and password are looked up in the database and granted or denied access depending on the user&#39;s account status 
     [S-02] The Database server is preferably running Microsoft SQL Server 7.0. 
     [S-03]A representative database table layout appears in  FIG. 42 . 
     Security 
     Preferably the databases are encrypted with 128 bit key encryption and the databases contain a specified list of users and specific roles the user has in the database. Preferably, the users each have a unique user name and password and the users are able to view only the sections specified. 
     In addition to the use of the present invention for bonds, those skilled in the art can also use the teachings of the invention for obtaining proof of insurance. Certificates of Insurance are also frequently required by contractors and others. Contractors are frequently required to present proof that their workers are covered by for example worker&#39;s compensation insurance. Certificates of Insurance are alsop required by many states before an automobile is registered. The present invention is useful in these applications also. One of the major advantages off the present invention is the reduction of fraud. In addition, there are significant cost reductions in the manner in which these insurance products are prepared pursuant to the teachings of the present invention.