US20060277133A1

US20060277133A1 - Method and apparatus for managing information and communications related to municipal bonds and other securities

Info

Publication number: US20060277133A1
Application number: US11/499,767
Authority: US
Inventors: Sharda Hebbar; Mario Camchong
Original assignee: Digital Assurance Certification LLC
Current assignee: Digital Assurance Certification LLC
Priority date: 2002-04-25
Filing date: 2006-08-07
Publication date: 2006-12-07
Also published as: US20030204464A1; US20070136174A1; US7801791B2; US7155408B2

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

1. Technical Field
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.
2. Description of the Related Art
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'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.
Traditionally, disclosing this information in a satisfactory and coherent manner was difficult, as was accessing information regarding a municipal bond prior to a broker'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.
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.
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'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' 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

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

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:
FIG. 1 illustrates a connected network and a series of computers upon which the present invention can be implemented;
FIG. 2 is a flowchart that shows how an issuer creates an entry for a new bond;
FIG. 3 is the main menu presented to-an issuer;
FIG. 4 is a form presented by the application in a screen that collects information from an issuer about a new bond;
FIG. 5 is a screen that presents a summary of the information entered in the form shown on the previous screen;
FIG. 6 is a screen that allows the bond to be added to the bond application;
FIG. 7 is a screen that confirms the bond has been successfully entered into the bond application;
FIG. 8 is a flowchart illustrating some of the options available from screen 300;
FIG. 9 is a screen from which an issuer begins the process of submitting a disclosure document;
FIG. 10 is a screen from which an issuer continues to enter information for a disclosure document;
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;
FIG. 12 is a screen from which an issuer begins the process of submitting an MEN;
FIG. 13 is a screen from which an issuer continues to enter information about the MEN;
FIG. 14A is a screen that shows an e-version of the MSRB coversheet that will be sent to the MDRs;
FIG. 14B is a screen that presents a summary of the MENs that have been submitted and their status;
FIG. 15 is a screen showing the various submissions that have been made to NRMSIRs;
FIG. 16 is a screen that presents a variety of messages to an issuer;
FIG. 17 is a screen from which an issuer can reply to an inquiry;
FIG. 18 is a screen from which an issuer can draft a reply to an inquiry;
FIG. 19 is a screen that shows the status of an issuer's messages;
FIG. 20 is a flowchart illustrating a method by which a visitor can search and retrieve information about a bond;
FIG. 21 is a screen from which the visitor can initiate a search;
FIG. 22A is a screen showing the search results;
FIG. 22B is a screen that displays the document categories;
FIG. 23 is a screen that shows the bond selected in screen 2200;
FIG. 24 is a screen that shows the MSRB coversheet related to a filed MEN;
FIG. 25 is a screen that shows detailed information about disclosure documents associated with the selected bond;
FIG. 26 is a screen that allows a visitor to draft an email message to an issuer;
FIG. 27 is a screen that shows replies to emails sent by the visitor, among other email messages; and
FIG. 28 is a screen that provides information on conference calls concerning the selected bond.

DETAILED DESCRIPTION OF THE INVENTION

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' bonds can review the information in order to make informed decisions.
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.
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.
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'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.
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'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.
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.
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's display device. When information is entered in a screen, this information is transmitted back to the application server via the connected network.
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' 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.
The discussion below first discusses the bond application from the perspective of the issuer. Then, the application is described from a visitor's perspective.
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.
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.
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.
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.
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.
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's computer system and subsequent screens related to a particular button are presented in that new window.
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.
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).
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
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's computer system. The visitor can then view the file to review the disclosure documents.
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.
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.
Returning to screen 2250, a user can also select option 2252 to view reference material about various types of bonds.
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.
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.

Claims

1. A method of managing bonds, comprising:

entering disclosure documents and material event notices about a bond into a computer system;

making the disclosure documents and material event notices available to others using a computer network;

sending the disclosure documents and material event notices to others computer systems via the computer network; and

sending electronic reminders when additional disclosure documents are required.

2. The method described in claim 1, wherein the entering step includes providing templates containing common items of disclosure documents and material event notices, and attaching files that contain additional information to one of the disclosure documents and material event notices.

3. The method as described in claim 1, wherein the step of sending the disclosure documents and material event notices further includes sending the disclosure documents and material event notices to an MDR.

4. The method as described in claim 1, further comprising:

viewing questions from visitors; and

displaying replies to the questions over the computer network.

5. The method as described in claim 1, further comprising displaying a list of information that has been sent to an MDR.

6. A computer system for managing bonds, comprising:

a computer system, connected to a network of other computers, wherein the computer system is operable in a particular mode of operation where the computer system

receives disclosure documents and material event notices about a bond;

makes the disclosure documents and material event notices available to others via the computer network;

sends the disclosure documents and material event notices to other computer systems via the computer network; and

sends electronic reminders when additional disclosure documents are required.

7. The computer system described in claim 6, wherein the particular mode of operation further includes the computer system:

providing templates containing common items of disclosure documents and material event notices, and

attaching files that contain additional information to one of the disclosure documents and material event notices.

8. The computer system as described in claim 6, wherein the particular mode of operation further includes the computer system sending the disclosure documents and material event notices to an MDR.

9. The computer system as described in claim 6, wherein the particular mode of operation further includes the computer system:

viewing questions from visitors; and

displaying replies to the questions over the computer network.

10. The computer system as described in claim 6, wherein the particular mode of operation further includes the computer system displaying a list of information that has been sent to an MDR.

11. A computer system for managing bonds, comprising:

reception means for receiving disclosure documents and material event notices about a bond;

communication means for communicating the disclosure documents and material event notices to others via the computer network;

sending means for sending the disclosure documents and material event notices to other computer systems via the computer network; and

reminding means for sending electronic reminders when additional disclosure documents are required.

12. The computer system described in claim 11, further comprising:

template provision means for providing templates containing common items of disclosure documents and material event notices; and

attachment means for attaching a file that contains additional information to one of the disclosure documents and material event notices.

13. The computer system as described in claim 11, further comprising MDR sending means for sending the disclosure documents and material event notices to an MDR.

14. The computer system as described in claim 11, further comprising:

viewing means for viewing questions from visitors; and

reply displaying means for displaying replies to the questions.

15. The computer system as described in claim 11, further comprising MDR display means for displaying a list of information that has been sent to an MDR.