Abstract:
The present invention is a method and apparatus for gathering information from issuers of municipal securities and distributing information evenly to municipal disclosure repositories, regulatory bodies and the public. A central aspect of the present invention is a computer application, which can be implemented on a computer system that is attached to a network of computers and other communication devices, such as the Internet. Initially, the application accepts the full name description of a particular municipal security issue, together with a unique identifier assigned by CUSIP. The system grants a secured and encrypted user id and password to the issuer enabling the issuer to enter ongoing information about the issue. This information may include annual audits of the issuer, certain operating data, and any event notices deemed material by the issuer. Such information is provided to comply with the contractual obligations of the issuer to the bond holders and to provide Brokers and Dealers with a procedure for facilitating regulatory requirements that provide prompt notice of events relating to bonds they recommend to customers. For information that is required to be submitted on a periodic basis, the system determines when the information is due to be submitted, and prompts the issuer to file such information with the system. This information is then published to the public, and, simultaneously, transmitted to the municipal disclosure repositories and/or regulatory bodies via a one-click dissemination system. If the issuer does not submit the required information by the due date, the system files a notice that the required information was not submitted by the issuer. Additionally, the system establishes an audit trail for gathering and the distribution of the information. Another important aspect of the audit includes receiving and archiving a receipt that information was transmitted to the municipal disclosure repositories and/or regulatory body. Finally, the system provides a secure platform for communication and teleconferencing among issuers and their investors.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Technical Field  
         [0002]     The present invention relates generally to a method and apparatus for managing bonds. More specifically, the present invention accepts initial information about a municipal bond as well as subsequent information about the bond that is required to be disclosed. The present invention also makes this information available to regulated entities required to access the information, to central locations designated by regulators to receive the information, to the public and to other entities.  
         [0003]     2. Description of the Related Art  
         [0004]     The issuance, offer and sale of municipal bonds is regulated by federal securities law. These regulations, in part, mandate brokers and dealers transacting in municipal bonds to have reliable access to disclosed material information concerning the bond issuer&#39;s financial condition and operation to require bond issuers to provide these disclosures at the time the bonds are issued, and periodically over the lifetime of the bond. In addition, the issuer must disclose certain important events as they occur.  
         [0005]     Traditionally, disclosing this information in a satisfactory and coherent manner was difficult, as was accessing information regarding a municipal bond prior to a broker&#39;s recommending it to a customer. For some time, the Securities and Exchange Commission (SEC) has required bond issuers to disclose the above-mentioned information to Nationally Recognized Municipal Securities Information Repositories (NRMSIRs), State Information Depositories (“SIDs”), and disclosure information systems established and operated by the Municipal Securities Rulemaking Board (“MSRB Systems,” and, together with NRMSIRs and SIDs “Municipal Disclosure Repositories,” referred to herein as MDRs). MDRs were created by the SEC to serve as points where information could be deposited by issuers and retrieved by interested parties. As a means of preventing fraud in the municipal market, Brokers and Dealers (as those terms are legally defined by the SEC) in municipal securities are required to have access to systems, including Municipal Disclosure Repositories that provide reliable information about municipal issuers and their bonds.  
         [0006]     Issuers, however, have had difficulty in fully utilizing NRMSIRs, SIDs and MSRB Systems. Some issuers contend that NRMSIRs are not “user friendly,” and that there is little feedback when incomplete information is accidentally submitted. Further, NRMSIRs do not affirmatively remind issuers when information is due to be submitted. Brokers and Dealers transacting in municipal bonds have had difficulty in meeting regulatory requirements, because of uncertainty-over the reliability of information available through NRMSIRs. Specifically, whether information required to be filed was, in fact, received by the NRMSIRs and whether the information was received have been difficult to determine. Brokers and Dealers have complained that the information on file at each of four current NRMSIRs is inconsistent and the SEC staff has noted inconsistent filings among NRMSIRs in sample studies. Also, Issuers cannot verify that their disclosure filings have been received and accurately filed with NRMSIRs, SIDs and MSRB Systems. Brokers and Dealers transacting in municipal bonds cannot easily verify the reliability of Municipal Disclosure Repositories. As a result, Brokers and Dealers transacting in municipal bonds cannot with certainty comply with current regulatory mandates.  
         [0007]     Thus, a need exists for a system that reliably indicates whether required information with respect to a municipal bond or similar security has or has not been timely filed. This system should allow for the simple, timely, and reliable submission of bond information as required by the SEC. This system should verify, to the extent possible, that all required information has been filed and is contained within an issuer&#39;s submitted bond information. The system should then simultaneously “publish” the information by making it available on the Internet. In addition, the system should send the information on to the NRMSIRs, SIDs and MSRB Systems to fulfill the issuers&#39; legal obligations. The system should provide Brokers and Dealers transacting in a municipal bond reasonable assurance that it will receive prompt notice of any event relating to that municipal bond disclosed pursuant to SEC regulation applicable to municipal securities. The system should provide a secure system for the electronic submission, storage, transmission and retrieval of audited financial statements and other information in conformity with professional standards. The system should also provide a secure means for communication among issuers, their agents, and investors, including by electronic mail and teleconferencing. The system should also periodically remind the issuers when new information about their bonds is due.  
       SUMMARY OF THE INVENTION  
       [0008]     Generally, the present invention is a method and apparatus for gathering information from issuers of municipal securities and distributing information evenly to municipal disclosure repositories, regulatory bodies and the public. A central aspect of the present invention is a computer application, which can be implemented on a computer system that is attached to a network of computers and other communication devices, such as the Internet. Initially, the application accepts the full name description of a particular municipal security issue, together with a unique identifier assigned by CUSIP. The system grants a secured and encrypted password to the issuer enabling the issuer to enter ongoing information about the issue. This information may include annual audits of the issuer, certain operating data, and any event notices deemed material by the issuer. Such information is provided to comply with the contractual obligations of the issuer to the bond holders and to provide Brokers and Dealers with a procedure for meeting regulatory requirements that provide prompt notice of events relating to bonds they recommend to customers. For information that is required to be submitted on a periodic basis, the system determines when the information is due to be submitted, and prompts the issuer to file such information with the system. This information is then published to the public, and, simultaneously, transmitted to the municipal disclosure repositories and/or regulatory bodies via a one-click dissemination system. If the issuer does not submit the required information by the due date, the system files a notice that the required information was not submitted by the issuer. Additionally, the system establishes an audit trail for gathering and the distribution of the information. Another important aspect of the audit includes receiving and archiving a receipt that information was transmitted to the municipal disclosure repositories and/or regulatory body. Finally, the system provides a secure platform for communication among issuers and their investors via electronic mail and teleconferencing.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]     The novel features which are believed to be characteristic of the present invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:  
         [0010]      FIG. 1  illustrates a connected network and a series of computers upon which the present invention can be implemented;  
         [0011]      FIG. 2  is a flowchart that shows how an issuer creates an entry for a new bond;  
         [0012]      FIG. 3  is the main menu presented to-an issuer;  
         [0013]      FIG. 4  is a form presented by the application in a screen that collects information from an issuer about a new bond;  
         [0014]      FIG. 5  is a screen that presents a summary of the information entered in the form shown on the previous screen;  
         [0015]      FIG. 6  is a screen that allows the bond to be added to the bond application;  
         [0016]      FIG. 7  is a screen that confirms the bond has been successfully entered into the bond application;  
         [0017]      FIG. 8  is a flowchart illustrating some of the options available from screen  300 ;  
         [0018]      FIG. 9  is a screen from which an issuer begins the process of submitting a disclosure document;  
         [0019]      FIG. 10  is a screen from which an issuer continues to enter information for a disclosure document;  
         [0020]      FIG. 11  is a screen that confirms the input of the disclosure document (previously entered in screen  1000 ) and allows information to be transmitted to MDRs;  
         [0021]      FIG. 12  is a screen from which an issuer begins the process of submitting an MEN;  
         [0022]      FIG. 13  is a screen from which an issuer continues to enter information about the MEN;  
         [0023]      FIG. 14A  is a screen that shows an e-version of the MSRB coversheet that will be sent to the MDRs;  
         [0024]      FIG. 14B  is a screen that presents a summary of the MENs that have been submitted and their status;  
         [0025]      FIG. 15  is a screen showing the various submissions that have been made to NRMSIRs;  
         [0026]      FIG. 16  is a screen that presents a variety of messages to an issuer;  
         [0027]      FIG. 17  is a screen from which an issuer can reply to an inquiry;  
         [0028]      FIG. 18  is a screen from which an issuer can draft a reply to an inquiry;  
         [0029]      FIG. 19  is a screen that shows the status of an issuer&#39;s messages;  
         [0030]      FIG. 20  is a flowchart illustrating a method by which a visitor can search and retrieve information about a bond;  
         [0031]      FIG. 21  is a screen from which the visitor can initiate a search;  
         [0032]      FIG. 22A  is a screen showing the search results;  
         [0033]      FIG. 22B  is a screen that displays the document categories;  
         [0034]      FIG. 23  is a screen that shows the bond selected in screen  2200 ;  
         [0035]      FIG. 24  is a screen that shows the MSRB coversheet related to a filed MEN;  
         [0036]      FIG. 25  is a screen that shows detailed information about disclosure documents associated with the selected bond;  
         [0037]      FIG. 26  is a screen that allows a visitor to draft an email message to an issuer;  
         [0038]      FIG. 27  is a screen that shows replies to emails sent by the visitor, among other email messages; and  
         [0039]      FIG. 28  is a screen that provides information on conference calls concerning the selected bond.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0040]     Generally, the present invention is comprised of a computer system and software program that causes the computer system to operate as described below. In a particular embodiment of the present invention, these items function as a web site, and enable municipal bond issuers (issuers) to post information so that the potential buyers and sellers of the issuers&#39; bonds can review the information in order to make informed decisions.  
         [0041]      FIG. 1  illustrates a connected network and a series of-computers upon which the present invention can be implemented. As illustrated in  FIG. 1 , host network  102  is a connected network of computers, an example of which is the Internet. Host network  102  can also be implemented by using a private access wide area network (WAN) or any other network. The size of the network is not material to operation of the present invention.  
         [0042]     Attached to host network  102  is application server  104 . In most implementations, application server  104  is a network of computers that store, access, and process all of the information relating to a number of municipal bonds. As shown in  FIG. 1 , application server  104  is composed of web server  112  for interacting with host network  102 , workstation  108  for executing various programs such as a relational database management program for organizing and indexing information associated with the bonds being tracked by the system, and storage server  110  for providing disk storage for the various data required by web server  112  and workstation  108 . This is but one embodiment of application server  104 . Depending upon the computational and storage requirements placed on application server  104 , application server  104  could be implemented as a single personal computer or a complex of several mainframes. The enact configuration of application server  104  is not material to the present invention, and will undoubtedly vary over time and on the demands placed upon application server  104 .  
         [0043]     Also connected to host network  102  are customer computers  106 . These computers can be implemented using any general-purpose computer configured to transmit and receive information via host network  102 . Customer computers  106  can be implemented using personal computers or workstations such as those sold by Dell, Compaq, Sun, Apple and others. These computers often operate under the control of an operating system having a graphical-user interface, and execute a software program that enables customers to request, receive, display and manipulate data from the connected network, examples of which are Microsoft&#39;s Internet Explorer and Netscape Navigator. Customer computers  106  allow customers to receive and view screens transmitted from application server  104 , and allow customers to transmit information back to application server  104  via host network  102 .  
         [0044]     Although the description of  FIG. 1  contemplates that customer computers  106  will be implemented using traditional personal computers, a variety of other communication devices can-be used instead of traditional personal computers. For example, personal digital assistants (PDA&#39;s) and cellular phones are now capable of transmitting data to and receiving data from a connected network. Since these devices can transmit data to and receive data from a connected network, they can perform all of the tasks required by customer computers as these computers are used in the-present invention. Thus, any device that can transmit data to/receive data from a connected network is, for purposes of the specification and claims, to be considered equivalent to a customer computer.  
         [0045]     The following discussion refers to three types of entities: administrators, issuers, and visitors. For the purposes of this disclosure, an administrator is the operator of the web site embodying the invention. An issuer is the entity that has actually issued the bond, or its designated representative. The issuer is responsible for continually submitting information that is related to the bond. For municipal bonds, the issuer will usually be a city, state, or other governmental taxing entity (e.g., a school district). As used herein, an issuer can also be an attorney, underwriter, insurance provider etc. representing the actual issuer of the bond. A distinction will be made between issuers and their attorney, but, otherwise, the term “issuer” applies to both of these entities. A visitor is any person (or entity) seeking information about a bond on the web site.  
         [0046]     Some of the figures discussed below are flowcharts that describe methods of operation according to the present invention. Numbers found in parentheses in the following discussion (e.g., ( 504 )) refer to a step in one of the flowcharts. The discussion of the methods shown in the flowcharts is intertwined with discussions of various figures that contain screen images. These screens depict images that appear on a display device of a user accessing a web site operating according to the present invention. The code for these screens is run on the application server and is transmitted via host network to a computer, which displays the code in the form of images and/or text on the computer&#39;s display device. When information is entered in a screen, this information is transmitted back to the application server via the connected network.  
         [0047]     The software application which operates according to the present invention (the bond application) is designed to be accessed by administrators, issuers, and visitors. Data exchanged between these entities&#39; and the bond application occurs using the secure socket layer protocol or other comparable secure environment. Operating in such a manner ensures that information exchanged with the bond application is authentic, and, in the case of confidential information, is secure.  
         [0048]     The discussion below first discusses the bond application from the perspective of the issuer. Then, the application is described from a visitor&#39;s perspective.  
         [0049]      FIG. 3  shows the screen that is displayed when the issuer logs-in to the bond application. In a preferred embodiment of the present invention, the login is accomplished by the issuer inputting a user name and password. Screen  300  initially presents an overview of the bonds belonging to the person who logged-in to the bond application. If the person logging in is an issuer, a list of all bonds issued by the issuer is presented. On the other hand, if the person logging in is an attorney, all of the bonds being handled by the attorney is displayed. In this particular example, screen  300  shows only a single bond. From screen  300 , the issuer can select button  314  to create an entry for a new bond, or the issuer can select from buttons/links  302 - 312  to take action with respect to a particular bond.  
         [0050]     If the issuer selects button  314  from screen  300 , form  400 , shown in  FIG. 4 , is displayed on one or more screens. Initially, the issuer completes the information requested in form  400  ( 202 ) then selects button  402 . Among the information entered by the issuer is the full issue description of the bond. Requiring the full issue description of the bond to be entered makes identifying the bond easier than if ad hoc abbreviations are used for certain words.  
         [0051]     The bond application then presents the issuer with screen  500  ( FIG. 5 ). This screen is an overview of the information previously entered by the issuer in form  400 . The issuer reviews the information in screen  500  and corrects the information as necessary ( 204 ). In one embodiment of the present invention, the information described in form  400  is entered and reviewed, the bond application verifies the CUSIP number ( 206 ). Verification of the CUSIP number can be accomplished by cross-referencing the CUSIP (Committee on Uniform Securities Identification Procedures) database, and, assuming it is a valid number, the bond application creates an entry in a database that is used to store the various bonds that are managed by the bond application.  
         [0052]     Once the issuer concludes that the information is all correct, the issuer selects button  502  to add the bond to the bond application ( 208 ). Once a bond is entered into the bond application, a tracking ID is associated with the bond ( 210 ). The tracking ID is a unique ID to track an individual issue. The system will then allow this person to file disclosure documents and material event notices (as will be described below) for the bond.  
         [0053]     After the issuer selects buttons  502  and  602  ( FIG. 6 ), the bond application presents confirmation screen  700  ( FIG. 7 ). This screen confirms that the bond has been successfully logged in to the bond application, and that a confirmation message has been sent to the issuer, bond counsel, and others as specified in form  400 . Upon selection of button  702 , the issuer is returned to screen  300 .  
         [0054]     From screen  300 , the issuer can select buttons/links  302 - 312  to manage various aspects of a particular bond. Selection of one of these buttons opens a new window on the issuer&#39;s computer system and subsequent screens related to a particular button are presented in that new window.  
         [0055]     Upon selecting button  302 , the issuer is taken to screen  900  ( FIG. 9 ). Screen  900  allows the issuer to begin the process of submitting a disclosure document about the financial condition of the issuer. Initially, the issuer selects one of the applicable descriptions  902 / 906 . The selection by the issuer depends on the type of disclosure document the issuer is filing ( 802 ) ( FIG. 8 ). The button selected by the issuer depends on whether the issuer is filing a new disclosure document or an amended document ( 802 ) ( FIG. 8 ). As shown in screen  900 , the issuer is submitting an audited financial statement. If the information being submitted by the issuer is not found in options  904 , the issuer may submit custom information by selecting option  906 . In addition, in future embodiments, the issuer can specify additional bonds for which the disclosure document will apply by entering their CUSIP number ( 804 ). After the proper buttons have been selected, the issuer advances to the next screen in the process by selecting button  908 .  
         [0056]     Screen  1000  ( FIG. 10 ) is displayed after the issuer selects button  908 . From screen  1000 , the issuer enters information about the disclosure, and can attach a file as an attachment to support the disclosure. Filing box  1002  allows the issuer to specify how often this type of disclosure document should be filed. Date box  1004  accepts the date of the disclosure, and date box  1006  accepts the fiscal year end. Boxes  1008  accept data that specifies the due date for future disclosures of this type ( 806 ). Using the information specified in boxes  1006 - 1008 , the bond application computes the due date for the next disclosure of this type, and will send email reminders at predefined frequency to the issuer that a disclosure is coming due ( 808 ).  
         [0057]     For example, as shown in screen  1000 , the due date for this type of disclosure is shown as being 90 days from the fiscal year end, which is December 31. Also, this type of disclosure is to be submitted on an annual basis. Thus, at some point before June 30 of the next year, the bond application will send emails to the issuer reminding it that a new disclosure is due. In a preferred embodiment of the present invention, reminders are sent to the issuer 60, 30, 15 and 7 days before the disclosure is due.  
         [0058]     If the issuer does not submit the required disclosure information by the due date, the bond application automatically generates a “failure to file notice.” A failure to file notice is a notice that a required (SEC Rule 15c2-12) disclosure document for a particular bond was not timely submitted by the issuer. This failure to file notice is made available to the public via the bond application and is also transmitted to the Municipal Disclosure Repositories. As used herein, the term “Municipal Disclosure Repositories” (MDRs) includes Nationally Recognized Municipal Securities Information Repositories (NRMSIRs), State Information Depositories (SIDs), the Municipal Securities Rulemaking Board (MSRB) and any other entity that has been designated as a repository of bond information or is otherwise required to receive such information. In one embodiment of the present invention, a human has to approve the generation and transmission of the failure to file notice. In other embodiments, however, the generation and transmission of such notices can be performed by the bond application without human intervention.  
         [0059]     Also in screen  1000 , the issuer can choose to upload/attach a file supporting the disclosure ( 810 ). These files usually contain more detailed information about the disclosure. The issuer can specify that a certain file be attached to the information by entering the name and location of the file in the box  1010 .  
         [0060]     After the issuer finishes completing the information shown in screen  1000 , the issuer selects button  1012  to advance to screen  1100  ( FIG. 11 ). Screen  1100  is similar to screen  900 , except that the disclosure document previously entered in screen  1000  is now shown under status bar  1102 . Using the “Delete” icon  1104 , the issuer can delete the disclosure document previously entered. On the other hand, if the issuer is satisfied with the information, the issuer can activate “Send to NRMSIRs” icon  1106 . In one embodiment of the present invention, an MSRB coversheet accompanies the disclosure information, an example of which is shown in screen  2400 . However, the generation of such notices can be performed by the bond application without human intervention ( 812 ). Finally, the information will be sent on to the NRMSIRs and other MDRs, and will, simultaneously, be made available to visitors using the bond application, as will be discussed below ( 814 ).  
         [0061]     The issuer can select button  304  to submit an MEN (Material Event Notice). Upon selecting button  304 , screen  1200  ( FIG. 12 ), is presented to the issuer. Screen  1200  displays a list of the different types of MENs. From this screen, the issuer can select the applicable event the issuer is reporting ( 820 ). If none of the options are appropriate, the issuer can select the last option entitled “Other material event notice (specify)” and describe the action. After selecting the “Principal and interest payment delinquencies” option, screen  1300  ( FIG. 13 ) appears. If the issuer had selected one of the other options, a different screen would have appeared. Generally, the various screens simply ask for information related to the event selected in screen  1200 . In screen  1300 , the issuer can select additional bonds that this MEN is applicable to by specifying their CUSIP numbers ( 822 ). In addition, the user is prompted to fill in various boxes with information related to the selection made in screen  1200  ( 824 ). The issuer can also specify that a certain file be attached to the information by entering the name and location of the file in box  1302  ( 826 ). The issuer has to affirm the accuracy of the information entered in this screen by checking box  1304 . When the issuer finishes inputting information into screen  1300 , the issuer advances to screen  1400  ( FIG. 14A ) by selecting button  1306 .  
         [0062]     Screen  1400  is a summary of the information to be sent to the MDRs regarding the MEN selected in screen  1200  in the form of an MSRB coversheet ( 828 ). The issuer reviews this information, then selects button  1402  to edit the information, or button  1404  to save the information and proceed to screen  1450  ( FIG. 14B ). Screen  1450  shows the various MENs that have been submitted to the bond application and whether the information has been submitted to the MDRs. Selection of button  1452  presents the MEN as it will be (or has been) submitted to the MDRs, while selection of button  1454  allows a particular MEN to be deleted if it has not been submitted to an MDP Button  1456  will send a particular MEN to the MDRs if it has not been sent already. At the same time the MEN is sent to the MDRs, it is also made available to visitors using the bond application ( 830 ).  
         [0063]     All documents associated with the bond (e.g., disclosure documents and MENs).are stored by the bond application for the life of the bond or until termination of engagement. In one embodiment of the present invention, a human can publish documents without transmission to the MDRs. In other embodiments, however, publishing without transmission can be performed by the bond application without human intervention.  
         [0064]     The issuer can review all of the information that has been submitted to the MDRs by selecting button  306  from screen  300 . Upon selecting this button, screen  1500  ( FIG. 15 ) appears. This screen contains a list of all of the events/information which have been submitted to the MDRs, the particular MDRs to which a particular data item was submitted, the date the information was sent, and the CUSIP number of the bond for which the information was submitted.  
         [0065]     After either a disclosure document or an MEN is submitted to the MDRs, the bond application expects to receive a confirmation of receipt from the MDRs to which information was sent. If the expected confirmation is not received, the bond application alerts an operator that certain MDRs failed to receive information transmitted to them. Otherwise, the application posts an e-receipt confirming delivery of the information to the MDRs with a date/time stamp.  
         [0066]     Selection of link  310  allows the issuer to request a conference call about the bond. Upon selection of link  310 , a screen is displayed that allows the issuer to specify the time of the call This information, along with the phone number to call and the option to listen/participate in the call, is then made available to visitors as described below.  
         [0067]     Another option available from screen  300  is to reply to investor inquiries. As is described below, visitors can ask the issuer questions by posting a message to the web site, as is known in the art and as described in more detail below. By selecting link  312 , the issuer can initiate the process of responding to these inquires. After selecting link  312 , screen  1600  ( FIG. 16 ) is presented to the issuer. New messages are listed under new message banner  1602 . Old messages and replies thereto are noted by old messages indicator  1604  and  1606 , respectively ( 840 ). To view anew message, the investor selects new mail icon  1602 . Selection of this icon displays screen  1700  ( FIG. 17 ): This screen displays the message and gives the issuer a chance to respond ( 842 ). To respond to the message, the issuer selects reply button  1702 , which, in turn, causes screen  1800  ( FIG. 18 ) to be displayed. From within screen  1800 , the issuer drafts a reply to the question contained in the message ( 844 ). When the issuer is finished, the issuer selects reply button  1802 , whereupon screen  1900  ( FIG. 19 ) is displayed. This screen is similar to screen  1600 , but now, no new messages are indicated, while the replied message count (item  1602 ) is incremented by one. The issuer may review any old message or replies by selecting old messages icon  1604  or  1606 , respectively.  
         [0068]     Turning now to how a visitor interacts with the bond application, the visitor initially logs into the bond application using a password and username provided through the registration process. Once the username and password are accepted, the visitor is presented with screen  2100  ( FIG. 21 ) whereby the visitor can search for various bonds.  FIG. 20  contains a flowchart that depicts this process. As shown in screen  2100 , the visitor can search for a bond by specifying information in one or more fields as shown in screen  2100  ( 2002 ). Although not shown in screen  2100 , a search can also be conducted by specifying key words that appear in the bond information. After the search criteria are entered into screen  2100 , the visitor initiates the search by selecting button  2102 .  
         [0069]     After the search is conducted, screen  2200  ( FIG. 22A ) is displayed showing the bonds that matched the search criteria ( 2004 ). As shown in screen  2200 , only one bond was retrieved in this particular example. A visitor can view more information on this bond by selecting link  2202  ( 2006 ) which displays screen  2250  ( FIG. 22B ). Screen  2250  displays document categories  2258 . Selecting the “MEN Notices” displays screen  2300  which displays a list of MENs and other options that allow the visitor to view more information about the bond ( 2008 ).  
         [0070]     The visitor can view more information about an MEN by selecting view option  2302  from screen  2300  ( 2010 ). Upon selection of this option, the MSRB coversheet, screen  2400  ( FIG. 24 ), is displayed showing detailed information about the selected MEN. For additional information, the visitor can download and view the file(s) listed in attachment field  2402 .  
         [0071]     Assuming the visitor navigates back to screen  2250 , the visitor can choose to view “Official Statements,” which includes disclosure documents ( 2012 ). Once this option is selected, screen  2500  ( FIG. 25 ) is displayed. This screen lists disclosure documents that have been submitted by the issuer. To view the disclosure documents, the visitor selects the document description icon  2502  ( 2014 ). Upon selection of icon  2502 , the file can be viewed or downloaded to the visitor&#39;s computer system. The visitor can then view the file to review the disclosure documents.  
         [0072]     With reference again to screen  2250 , the visitor can select ask a question option  2256  to post a question to the issuer. Upon selection of this option, screen  2600  ( FIG. 26 ) is presented so that the visitor can draft a message to the issuer ( 2016 ). After the message is drafted, the visitor selects submit button  2602  to post the message. Also from screen  2600 , the visitor can review previous questions and answers by selecting option  2604 . The visitor can return to option  2604  some time after submitting the question to see if the issuer has submitted a reply to the question. If the visitor selects this option, screen  2700  ( FIG. 27 ) appears. Screen  2700  displays questions that have been previously submitted to the issuer, along with any responses ( 2018 ). In this manner, the visitor can get answers to questions he has about a particular bond.  
         [0073]     Returning to screen  2250 , the visitor can select option  2254  to retrieve information about upcoming conference calls related to the bond. Upon making this selection, screen  2800  ( FIG. 28 ) is displayed ( 2020 ). Screen  2800  displays information about upcoming call as well as previous conference calls. These previous calls are stored for some period of time and can be played back by the visitor by selecting achieved call icon  2802 .  
         [0074]     Returning to screen  2250 , a user can also select option  2252  to view reference material about various types of bonds.  
         [0075]     As indicated above, aspects of this invention pertain to specific “method functions” that can be implemented through various computer systems. In an alternate embodiment, the invention may be implemented as a computer program product for use with a computer system. Those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms, which include, but are not limited to: (a) information permanently stored on non-writeable storage media (e.g. read only memory devices within a computer such as ROMs or CD-ROM disks readable only by a computer I/O attachment); (b) information alterably stored on writeable storage media (e.g. floppy disks and hard drives); or (c) information conveyed to a computer through communication media, such as a local area network (LAN), a telephone network, or a public network like the Internet. It should be understood, therefore, that such media, when carrying computer readable instructions that direct the method functions of the present invention, represent alternate embodiments of the present invention.  
         [0076]     While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.