CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. Provisional Patent Application Serial No. 61/179,072 filed on May 18, 2009, now pending, which is hereby incorporated by reference in its entirety into this specification.

BACKGROUND OF THE INVENTION

Conventional communication systems exist for SMS, standard voice, voice blast and voice mail. Such conventional systems only allow individuals to access voice mail left as a file/individual piece of data/recording on their account/phone device/email. Conventional systems do not allow persons to send and access a single unique file from multiple channels (cell phone, personal computer, or telephone land line) nor do they allow individuals to respond to the single unique file via multiple channels (cell phone, personal computer, or telephone land lines).

SUMMARY OF THE INVENTION

The present invention is a system and method for sending, accessing, and responding to a mobile network message (MNM), with or without an attached survey, between a person or company and a large group of recipients across multiple communication devices. By way of example only, the communication device may be a cell phone, personal computer, or telephone land line. A MNM is defined as an audio and/or a visual message file that is stored and accessed by senders and recipients of the system. In one embodiment, the system comprises a data base server having a first data base configured to store a MNM recorded by a sender and a second data base configured to store recipients selected by the sender to have access to the MNM. The system further comprises a phone communication server and a web server in dual communication with the data base server.

The phone communication server comprises an application software having first and second script configured to allow the user to record and store a first MNM in the first data base. The application software comprises third and fourth script configured to allow the user to create and store a first group of recipients in the second data base to receive notice of and access to the first MNM.

The web communication server comprises an application software having first and second configured to allow the user to record ad store a second MNM in the first data base. The application software comprises third and fourth script configured to allow the user to create and store in the second data base a second group of recipients to receive notice of and access to the second MNM.

The system further comprises a message server stored on the data base server that is generally adapted to manage sending of an e-mail or SMS notification to all recipients that a MNM is waiting to be retrieved. The message server comprises a mail management module having a first script configured to create first and second notifications corresponding to the first and second MNM. Each of the first and second notifications comprises a first data field providing a telephone number so the first and second group of recipients may elect to call the phone communication server to listen to the first and second MNMs, respectively. Each of the first and second notifications further comprises a second data field providing a web address so the first and second group of recipients may elect to access the web communication server to listen to the first and second MNMs, respectively. The mail management module further comprises a second script configured to send the first and second notifications to the communication devices of the first and second group of recipients, respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description of the invention will be fully understood with reference to the accompanying drawings in which:

FIG. 1 is a high level block diagram showing system 100 according to the present invention;

FIGS.2-10 are detailed flow charts showing the operation of IVR Communication Server according to the present invention;

FIGS. 11-21 are detailed flow chart showing the operation of Web Communication Server according to the present invention; and

FIG.22 is a flow chart showing the operation of the Mail Management Software according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 1, where a system 100 is illustrated that allows sending, accessing, and responding to a mobile network message (MNM) and/or a survey between a user and a large group of recipients across multiple communication channels or devices such as cell phones, personal computers, or telephone land lines. A MNM is defined as an audio and/or a visual message file that is stored and accessed by senders and recipients of the system. A user is a person who is either a member or a contact. A user may become a member by joining system 100. A person who has not joined system 100 is a contact. As will be described more fully herein, only a member can send a MNM and/or a survey.

System 100 generally comprises a User Interface 102 in communication with a File Manager 124 and a Database Server 134. A person may communicate with system 100 via User Interface 102 over a world wide web 20 and/or a public telephone network 30. File Manager 124 provides management of MNM files and surveys created by User Interface 102 to be stored on Database Server 134.

User Interface 102 generally comprises a Web Communication Server 114 and a Phone Communication Server 104. Phone Communication Server 104 generally comprises a Call Handling Software 108 stored and running on Call Handling Hardware 106. Call Handling Hardware 106 is of conventional design. Call Handling Software 108 comprises an Operating System Software 110 of conventional design and an Application Software 112. As will be described more fully herein, Application Software 112 comprises computer code or software that controls the manner in which the user may communicate with system 100 over public telephone network 30. Server 104 is an Asterisk IVR server available as a download over the internet from http://www.asterisk.org. Web Communication Server 114 generally comprises a Web Interface Software 118 stored and running on Web Interface Hardware 116. Web Interface Hardware 116 is of well known conventional design. Web Interface Software 118 comprises an Operating System Software 120 of well known conventional design and an Application Software 122. As will be described more fully herein, Application Software 122 comprises computer code that controls the manner in which the user may communicate with system 100 over web 20. Server 114 is a HTTP server widely available as a download over the internet from http://httpd.apache.org/.

User Interface 102 maintains bidirectional communication with File Manager 124. File Managerl24 comprises two sub-modules: Hardware 126 and File Management Software 132. File Manager 124 maintains bidirectional communication with Database Server 134.

Database Server 134 comprises a MySQL Server 136 and a Message Server 142. Database Server 134 further comprises several databases: Caller ID Database 156; Member Database 158; Message Database 160; Message Recipient Database 162; Survey Data Base 161; Conference Data Basel63; 2VOO System ID Data Base 164; Contacts Data Base 166; Groups Data Base 168; and Available Slot Table 170. Caller ID Database 156 is a list of caller Ids added and recognized by phone communication server 104. Member Database 158 is a list of all members of system 100. A member is a person or user that has joined system 100. Message Database 160 is a list of all recorded MNMs indexed or flagged to the member who created the MNM. Message Recipient Database 162 is a list of all recipients entered by any member to receive one or more MNMs indexed or flagged to the member who created the recipient. Survey Data Base 161 is a list of all surveys created by any member indexed or flagged to the member who created the survey Conference Data Base 163 is a list of all conference calls scheduled by any member. System ID Data Base 164 is a list of all system Ids indexed or flagged to member. A new system Id is created and assigned to every new member. Contacts Data Base 166 is a list of all contacts. A contact is a user or person who has not joined system 100. Groups Data Base 168 is a list of all groups designated by a sender (user who is a member) to receive notice of a MNM stored in message data base 160. Slots Database 170 is a list of time intervals that are predicted to be free for users to respond to MNM's. Slots Database 170 is used by the Message Server 142 to schedule the sending of MNM's to prevent the system 100 from becoming overloaded with MNM responses.

MySQL Server 136 comprises a Server Hardware 138 and a Server Software 140 stored on a storage device (not shown) of Server Hardware 138. Server Software 140 comprises conventional computer coding well known in the art to store and retrieve files stored in the data bases in response to a query from Phone Communication Server 104, Web Communication Server 114 or Message Server 142. Server 136 is a relational data base server widely available as a download over the internet from http://dev.mysql.com/downloads/.

Message Server 142 comprises a Server Hardware 144 and a Server Software 146 stored on a storage device (not shown) of Server Hardware 144. Server Software Module 146 comprises a Mail Management Module 148, an E-mail Send Module 150, and a SMS API Module 152. As will be described more fully herein, Message Server 142 communicates with an external SMS Gateway 70 to send a notification to each recipient. The notification provides the recipient with access to the MNM. As will be described more fully herein (FIG. 22), Mail Management Module 148 comprises computing coding or software that controls when notifications corresponding to a MNM and/or survey are sent to the recipients. E-mail Send Module 150 is configured to transfer notifications corresponding to a MNM and/or survey to the SMS Gateway 70 using the API provided in SMS API Module 152. SMS API Module 152 is an SMS API widely available from several vendors, one of which is Clickatell Chttp://www.clickatell.com/).

Referring to FIG.2, where a flow chart shows a portion of the structure and operation of Application Software 112. As shown by block 202, Application Software 112 is configured to determine whether not the caller ID of telephone 50 is recognized. Application Software 112 is configured to query MySQL Server 136 to see if the incoming caller ID matches any caller ID stored in Caller ID Data Base 156. If the incoming caller ID does not match any authorized Caller ID stored in Caller ID Data Base 156 then control passes to block 204 upon a response signal from MySQL Server 136. As indicated by block 204, Application Software 112 is configured to prompt the user to enter his/her 2voo ID that was given to the user when he/she joined system 100. Control is then passed to block 206, where Application Software 112 is configured to determine whether or not the 2voo ID is valid. Application Software 112 is configured to look-up whether or not the entered 2voo ED matches any 2voo ID stored in Data Base 164. Control is returned to block 204 if the 2voo ID is not valid. Returning to block 206, control passes to block 208 if the entered 2voo ID is valid. As shown by block 206, Application Software 112 is configured to prompt the user to enter a personal identification number (PIN) that was given to the user when he/she joined system 100. Control is passed to block 210 where Application Software 112 is configured to determine whether or not the PIN is valid. If the PEST is not valid the control returned to block 208. If the PIN is valid then control passes to block 212. Returning to block 202, control is passed to block 212 if the User's caller ID is not recognized. As shown by block 212, Application Software 112 is configured to determine whether not the User is a member or a contact. Application Software 112 is configured to query MySQL Server 158 to look-up whether the User is member or contact. Control is passed to block 214 upon a response signal from MySQL Server 158 that the user is a contact or to block 216 upon a response signal from MySQL Server 158 that the user is a member.

As shown by block 216, Application Software 212 is configured to serve a Member Main Menu 216 from which the user may select several options. As shown by block 218, the user may select the option of sending a MNM. As shown by block 220, the user may select the option of listening to a MNM. As shown by block 222, the user may select the option of creating feedback (a survey). As shown by block 224, the user may select the option of creating a conference call. As shown by block 226, the user may select the option of joining a conference call. Finally, as shown by block 228, the user may select the option of signing off system 100.

As shown by block 214, Application Software 212 is configured to serve a Contact Main Menu 214 from which the user may select several options. As shown by block 230, the user may select the option of joining system 100. As shown by block 232, the user may select the option of listening to a MNM. As shown by block 234, the user may select the option of joining a conference call. Finally, as shown by block 236, the user may select the option of signing off system 100.

Referring to FIG. 3, where a more detailed flow chart describing the structure and operation of option 218 (Send MNM) of Member Main Menu 216 is provided. As shown by block 302, Application Software 112 is configured to playback instructions for creating and sending a MNM. As shown by block 306, Application Software 112 is configured to record a MNM by the user. Control is then passed to a block 308 where Application Software is configured to present the user with a Send MNM Menu 308 from which the user may select one or more options. As shown by block 310, the user may select the option of checking the recorded MNM. Control is passed to block 318 where Application Software 112 is configured to play back the recorded MNM to the user. Control is passed to block 320 where Application Software 112 is configured to prompt the user to confirm sending of the recorded MNM. If the user does not confirm sending of the recorded MNM than control is returned to Send MNM Menu 308. If the user confirms sending of the MNM the control is passed to block 322. As shown by block 322, Application Software 112 is configured to create entries in the data base for recipients of the MNM. Control is then passed to the Mail Management Module 148. As shown in block 312 the user can select the option Send MNM from the Send MNM Menu. If the user selects this option control is pass to block 322. As shown by block 322, Application Software 112 is configured to create entries in the data base for recipients of the MNM. Control is then passed to the Mail Management Module 148. As shown in block 314 the user can select Create Survey. If the user selects this option control is passed to block 326 and a survey is created. Control is then passed to block 322. As shown by block 322, Application Software 112 is configured to create entries in the data base for recipients of the MNM. Control is then passed to the Mail Management Module 148. As shown in block 316 the user can select the option to Cancel MNM. The Application Software 112 is configured in block 328 to prompt the user to confirm the intent to cancel sending the MNM. As shown by block 328, if the user confirms then control is passed to block 330 and the message is deleted. Control is then passed to block 216 and user is presented with the main menu. If the user does not confirm cancelation of the MNM, then control is passed to block 308 and the user is presented with the Send MNM Menu.

Referring to FIG. 4, a more detailed flow chart describing the structure and operation of option 220 (Listen to MNM) of Member Main Menu 216 (FIG. 2) and option 232 (Listen to MNM) of Contact Main Menu 214 (FIG. 2) is provided. As shown by block 402, Application Software 112 is configured to query the message database to build a table of unread MNM messages. Control is then passed to block 404 where the next unread MNM is played back to the user. Then control is passed to block 406 where the message status is changed to indicate that the message has been read. This will cause two events to occur. First, as shown by block 408, the message recipients table is updated to show that the user has seen the message. Second, as shown by a block 409, a Post Playback Menu is presented. The user can select one of three options from Post Playback Menu block 409. If the first option 410 (Save MNM) is selected, the MNM is saved and control is passed to block 416. If the second option 412 (Delete MNM) is selected, the MNM is deleted and control is passed to block 416. The Application Software 112 is configured so that block 416 updates the message status and passes control to block 418. If there is another unread message, control is passed back to block 404 and the next unheard message is played back. If there are no unheard messages, control is passed to block 420 where Application Software 112 is configured to pass control to block 422 if the user is a member. If the user is a contact, control is passed to block 421 where the user may join system 100 as shown in FIG. 9. If the user selects third option 414 (Leave Survey Response) from the Post playback menu 409, control is passed to block 415 where the user enters the Leave Survey Response code of FIG. 6. Upon completing the Leave Survey Response code of FIG 6, the user is presented with Post playback menu 409.

Referring to FIG. 5, a more detailed flow chart describing the structure and operation of option 222 (Create Feedback/Survey) of Member Main Menu 216 and option 232 (Listen to MNM) of Contact Main Menu is provided. As shown by block 502, the flow begins with block 502 where the instructions for creating feedback/survey are played. The Application Software 112 is configured to pass control to block 504 which presents the user with a menu for selecting the feedback question type. Control is then passed to block 518 which prompts the user and records the question. Control is then passed to block 520 which plays the question back for the user to review. The Application Software 112 is configured to ask the user in block 521 whether the recording is acceptable. If the user wishes to redo the recording, control is passed to block 518. If the recording is acceptable, control is passed to block 522 which prompts the user for options. Options are possible choices the receiver of the MNM will have when answering a question. For instance, if the question is a rank type 512, the options will be the items being ranked. If options are required, control is passed to block 524 where the user will record the next option. Control is passed to block 526 where the option is played back for the user to review. Control is then passed to block 528 which asks the user if the option should be changed. If the user wants to change the option, control is passed back to block 524. If the user is satisfied with the option, then control is passed to block 530 and the user is asked whether there are more options. If there are more options, control is passed back to block 524 and the next option is recorded. If there are no more options, control is passed to block 532. Block 532 asks the user if there is another question. If there is another question, the user is presented with the Question type menu and control is passed back to block 504. If there are no more questions, the user is presented with the Member Main Menu and control is passed to block 216.

Referring to FIG. 6, a more detailed flow chart describing the structure and operation of option 414 (Leave feedback response) of Post playback menu 409 is provided. The flow begins with block 602 where instructions for leaving feedback are played. Control is then passed to block 604 which plays back the number of questions in the survey. The next question is played back in block 606 and control is passed to block 608. The Application Software 112 is configured to check if the question is a "Free Text" type question in block 608. If it is, then control is passed to block 610 and "Free Text" instructions are played back to the user. Then block 612 records the user's response and control is passed to block 658 where a check is performed to detect if there is another question. If there are no more questions, control is passed to block 660 where the user is thanked for leaving feedback and control is passed back to the Post Playback Menu 409 of the Retrieve MNM flow (FIG. 4). If there is another question, control is passed back to block 606 and the next question is played back for the user. If the question is a type 'Tick', control is passed to block 616 where the instructions for answering a 'Tick' question are played back. The next 'Tick' option is played back in block 618 and the user indicates whether this option is selected in box 620. If the option is selected, the response is recorded in box 622. If there are no more options, control is passed to block 658 where a check is performed to detect if there is another question. If this is not the last option, control is passed back to block 618 which plays back the next option.

The Software Application Module 112 is configured to detect if the question is a 'Rank' type question in box 626. If the question is a type 'Rank' control is passed to block 628 which plays the instructions for dealing with 'Rank' type questions. Control is then passed to block 630 which plays the next option to the user. If this is the top rank control is passed to block 636 which records the response. Control then passes to block 640 which detects if this was the last option. If it is the last option, control is passed to block 658 where a check is performed to detect if there is another question. If this is not the top rank, it is removed from the list of options in block 638. Control is then passed to block 640 which detects if this was the last option. If it is not the last option, control is passed to back to block 630 which plays the next option to the user.

The Software Application Module 112 is configured to detect if the question is a 'Dropdown' type question in box 642. If the question is a 'Drop-down' type question control is pass to block 644 plays the instructions for dealing with 'Drop-down' type questions. Control is then passed to block 646 which plays back the available options. The user selects and option when control is passed to block 648 and then control is passed to block 658 where a check is performed to detect if there is another question.

The Software Application Module 112 is configured to present a Yes/No/Don't know Menu 650 if the question is not one of the other defined types. The user selects an option from the menu and control is passed to block 658 where a check is performed to detect if there is another question. If there is another question, control is passed back to block 606. If there are no more questions, control is passed to block 660 which plays back a thank you to the user. The user is then returned back to the Post Playback Menu 409.

Referring to FIG. 7, a more detailed flow chart describing the structure and operation of option 4 (Create Conference Call) of Member Main Menu 216 is provided. The flow begins with block 702 where the instructions for creating a conference are played back to the user. Control is then passed to block 704 and the instructions for setting a mod PIN are played back to the user. The user then enters a PIN in block 706. Control is passed to block 708 where the user must confirm the PIN entered in block 706. Control is then passed to block 710 where the Software Application Module 112 is configured to check whether the PIN entered in block 706 matches the PIN entered in block 708. If the two PINs do not match, control is passed back to block 706. If the two PINs match, control is passed to block 714 which plays back instructions for setting the user PIN. The user enters a user pin in block 716, and confirms the PIN by entering it again in block 718. Control is then passed to block 720 in which the two PINs are compared. If they do not match, control is passed to block 716 and the user will re-enter a PBSf and re-confirm in block 718. If the user PDSf is confirmed, control is passed to block 722 which prompts the user whether the conference will be announced. Control is passed to block 724 where the Software Application Module 112 is configured to record and playback the announcement if the user has chosen to announce the conference. Control is then passed to block 728 where the user either accepts the recorded announcement or rejects it. If the user rejects the announcement, control is passed back to block 722. If the user accepts the announcement, control is passed to block 730 which prompts the user as to whether the conference is a Listen Only conference for some attendees. If the user has chosen in block 724 that the conference will not be announced, control is also passed to block 730. If the user desires a Listen Only conference, then control is passed to block 734 where the user is prompted as to whether the attendees will wait for the conference leader. If they will not wait, then control is passed back to block 732. If the attendees will wait, then control is passed to block 738 and the user is prompted for the conference date. If the user has chosen that the conference is not a Listen Only conference in block 732, control will be passed from block 732 to block 738. Control is passed from block 738 to block 740 where the user enters the conference date. The Software Application Module 112 is configured to confirm the conference date when control is passed from block 740 to block 742. If the date is not confirmed, block 744 passes control back to block 740. If the date is confirmed, block 744 control is passed to block 746 where the user is prompted to enter the conference time. Control is passed to block 748 where the user enters the conference time. The user is prompted and confirms the conference time in block 750. Control is passed to block 752 where the conference times entered in block 748 and 750 are compared and checked for a match in block 752. If they do not match, control is passed back to block 748. If they do match, control is passed to block 754 where the user is prompted for the conference duration. The user enters the conference duration when control is passed to block 756. Control is passed to block 758 where the user is prompted for and enters the conference duration again. Control is then passed to block 760 where the durations entered in blocks 756 and 758 are compared and checked for a match. If they do not match, control is passed to block 756 where the user will re-enter the duration. If they do match, then control is passed to block 762 where the user is prompted to enter whether the conference is recurring. Control is then passed to block 764. If the conference is recurring, block 764 will pass control to block 766 where the user is prompted to enter the frequency of recurrence. The frequency of recurrence is entered in block 768 and control is passed to block 770 where the user is prompted for the length of recurrence. The user enters the length of recurrence in block 772 and control is passed to block 774 where the user is prompted to select the group that is invited to the conference. The Software Application Module 112 is configured to prompt the user whether another group is to be added to the list of attendees in block 776. If a group is to be added, control is passed to block 778 where the user selects the group. Control is passed to block 780 where the list of attendees is added to the message recipients database 162 so that they will receive a message regarding the conference. Control is then passed to block 776 where the user is again prompted to add another group. If no more groups need to be added, control is passed to block 782 where the conferences database 163 is updated.

Referring to FIG. 8, a more detailed flow chart describing the structure and operation of option 3 (Join Conference Call 226) of Member Main Menu 216 is provided. The flow begins with block 802 where the user is requested to enter a conference PIN. When the PIN is entered, two events occur. First, the MYSQL Server 136 queries the Messages Recipient Database 162 and the Conferences Database so that the user can be connected with the correct conference. Second, control is transferred to the block 804 where the conference title is played back to the user. Then control is transferred to block 806 where the conference status is updated to indicate that the user is present at the conference by updating the Messages Recipients Database 162 via the MySQL Server 136. The Software Application Module 112 is configured to transfer control to block 808 while the users hold the conference. Control is transferred to block 810 to update the conference status to indicate that the conference is in progress. The update is done by the MySQL Server 136 accessing the Conferences Database 163. Block 810 then transfers control to block 812 where Application Software 112 checks whether the conference will be recorded. If it will be recorded, control is transferred to block 816 and the file location containing the recording is written to both the Message Database 160 and the Messages Recipient Database 162. If the conference will not be recorded, block 812 transfers control to block 814. Block 816 also transfers control to block 814. The Application Software 112 is configured to check in block 814 whether the user is a member or a contact. If the user is a contact, the user is presented with the Member Main Menu 216. If the user is a contact, the Contact Main Menu 214 is presented.

Referring to FIG. 9, a more detailed flow chart describing the structure and operation of option 1 (Join 2voo 230) of Contact Main Menu 214 is provided. The flow begins with block 902 which plays a message asking the user to join 2voo. Control is then transferred to block 904 which plays a legal disclaimer message. Next, the user is prompted to accept the disclaimer. If the user does not accept, control is transferred to block 906 where the user is informs that joining 2voo is not possible. Control is then transferred to block 908 where the user is asked to exit. If the user chooses to exit, control is transferred to block 910 which will disconnect the user. If the user chooses not to exit, the user will again be informed by block 906 that joining 2voo is not possible without accepting the legal disclaimer played in box 904. If the user accepts the disclaimer, control is passed to block 912 where a PBSf is requested. Control is transferred to block 914 where the user will enter a PIN. The Application Software 112 is configured to transfer control to block 916 which requests the user to enter the PIN again so that it can be confirmed. Control is transferred to block 918 where the confirmation of the PIN is performed. The User Database 156 is updated with the pin via the MySQL Server 136. The user is then prompted in block 920 to enter his Caller ID. The caller Id is checked for correctness in block 922 and the Caller ID Database 156 is updated. If the Caller Id is determined to be not correct, control is passed to block 924 where the user is prompted for a phone number. Control is then passed to block 926 where the user enters a phone number. The phone number is validated in block 928 and control is then passed to block 930. If the validation was not successful, the user is return to block 926 and prompted to enter a phone number. If the validation was successful control is passed to block 932 and registration is complete. If the Caller Id was determined to be correct in block 922, control is also passed to block 932. The user is then presented with the Member Main Menu 216.

Referring to FIG. 10, a more detailed flow chart describing the structure and operation of Option 6 228 (Sign-off 2voo) of Member Main Menu 214 and Option 4236 (Sign-off 2voo) of Contact Main Menu 214 is provided. If the user is a member, the flow begins with block 1002 where playback sign-off options are given. Control is then passed to block 1004 which determines whether future contact with the user is permitted. If future contact is permitted, control is passed to block 1008 and a thank you is played back to the user. Control is passed to block 1006, which edits the Users table modifying the Users Database 158. If block 1004 determines that future contact is not permitted, control is passed to block 1012. If the user is a contact, the flow begins with block 1012. Block 1012 plays a message to the user expressing that 2voo is sorry to lose the user. The Software Application Module 112 is configured to edit the users table to block future messages to the user.

Referring to FIG.l 1, a flow chart shows a portion of the structure and operation of Application Software 122 is provided. As shown by block 1202, Application Software 122 is configured to determine whether a the Web Communication Server 114 is accessed with a onetime link. If is, then the system is being accessed by a contact and control is passed to block 1118 which will determine if the link has already been used. If the link is unused, control is passed to block 1122 which will provide a one-time URL. The contact is then presented the Contact Home page 1124 which comprises a number of links including a Message Player 1126 and a link to Join 2voo 1126. If the one time link has already been used, control is passed to block 1120 and the user is invited to join 2voo. If block 1102 determines that the link is not a one-time link, then the user is a member and control is passed to block 1104. Block 1104 is the 2voo home page and presents the user with a link to login with block 1106. The login is authenticated in block 1108 with a query to the Users database 158 via the MySQL server 136. If the login cannot be authenticated, control is kept at block 1108 until the user can login with the correct login info. Then control is passed to block 1110 and the Member is presented with a Member Home page which includes several links including Upload File 1112, Send MNM 1114 and Manage Feedback 1116.

Referring to FIG. 12, a more detailed flow chart describing the structure and operation of sending an MNM with the Web Communication Server 114 is provided. The flow is entered from any of three links: Manage Feedback 1116, Upload File 1114 or Send MNM 1112 and is entered after the flow from those links has been executed. From the Send MNM link 1114, control is passed to block 1202 which prompts the user to select recipients for the MNM. Control is then passed to block 1204 which determines if the audio file for the MNM has already been associated with this MNM. If not, then the Application Software 122 is configured to determine if an audio file to associate with the MNM exists. If it does not, then the flow for uploading a file 1114 is followed. If the audio file does exist, then the user associates the file with the MNM in block 1208. Control is then passed to block 1210. Block 1204 passes control to block 1210 if the audio file to associate with the MNM was previously associated with the MNM. Block 1210 determines if feedback is previously associated with the MNM. If not, then control is passed to block 1212 which determines if feedback is required. If feedback is required, then control is passed to block 1214 which determines if there is feedback to associate with the MNM. If there is feedback to associate, control is passed to block 1216 and the user associates feedback. If block 1214 determines that feedback does not exist to associate with the MNM, then control is passed to the flow Manage Feedback 1116 which will create the feedback. If block 1212 determines that feedback is not required, then control is passed to block 1218. Also, if block 1210 determines that feedback has already been associated with the MNM control is passed to block 1218. Block 1218 creates database entries for the MNM and updates the MNM message recipients with a MySQL server 136 update. Control is then passed to block 1220 and the user is presented with a message indicating success in sending the MNM. The Mail Management Module 148 is invoked and the user is presented the Member Home 1104 page.

Referring to FIG. 13, a more detailed flow chart describing the structure and operation of Uploading a file with the Web Communication Server 114 is provided. The flow is entered from block 1302 via the link to upload a message 1112. The Application Software Module 122 is configured to present the user with a link to 'Upload new file' 1304. Upon pressing this link, the user selects the 'Browse' button in block 1306. Control is transferred to block 1308 where the local operating system manages file selection. When the user selects the desired file, control is passed to block 1310 where the user presses the 'Save' button. A database entry for the file is created in block 1312 and control is then passed to block 1314 where the file is copied to the file system. The user is then returned to the page to Upload Messagesl 112.

Referring to FIG. 14, a more detailed flow chart describing the structure and operation of Retrieving an MNM with the Web Communication Server 114 is provided. The flow begins differently if the user is a member vs. a contact. If the user is a member, the flow begins from the Member Home Page 1104. The user follows the 'Messages' link in block 1402 by clicking the Messages button 1404. Control is passed to block 1408 where the user selects a message to read from the message list This will cause the Messages Database 160 and the Messages Recipients Database 162 to be accessed. Control is passed to block 1412 and the user selects the Play icon in the message player to hear the message.

If the user is a contact, the flow begins from the Contact Home page 1124. The user selects the Message Player icon 1126. Control is then passed to block 1410 where the user chooses 'Play' in the message player.

Control is passed from block 1412 (if the user is a member) or block 1410 (if the user is a contact) to block 1414. The Application Software 122 is configured to communicate with the File Manager Module 124 and retrieve the MNM from the file system. Control is then passed to block 1416 and the message is played back to the user. Control is then passed to block 1418 where the system determines whether there is feedback associated with the MNM. If feedback is associated with the MNM control is passed to block 1420 where the user is requested to leave feedback. Control is then passed to block 1424 and the user either accepts or rejects the request to leave feedback. If the user accepts the request, control is passed to block 1426 and the user leaves a survey response. Control is then passed to block 1428. If the user rejects the request to leave feedback, control is passed to block 1428, bypassing block 1426. If no feedback is associated with the MNM in block 1418, control is passed to block 1428. The Software Application Module 122 is configured so that block 1428 determines whether the user is a member or a contact. If the user is a member, control is passed to block 1434 and control is passed to the 'Messages' page 1404. If the user is a contact, control is passed to block 1430 and the user is invited to sign-up with 2voo. Control is then passed to block 1432 where the user enters the flow to Join 2voo 1128.

Referring to FIG. 15, a more detailed flow chart describing the structure and operation of Creating a Survey with the Web Communication Server 114 is provided. The flow begins from the member home page 1104. Control is passed to block 1502 where the user determines whether a file needs to be uploaded to create the survey. If uploading a file is required, the user clicks the link Upload File 1112 and control is passed to block 1506 where the user follows the flow for uploading a file (FIG. 13). Control is then passed to block 1508 where the user clicks the Add new Survey link 1508. If the user determines that no files need to be uploaded, then control is passed to block 1504 and the user clicks the Surveys link. This will pass control to block 1508. In block 1508 the user clicks the Add New Survey link which causes control to pass to block 1510. The Application Software 122 is configured so that the user completes the survey form presented in block 1510 and then transfers control to block 1512. The completed survey form is validated in block 1512 and control is passed to block 1514. Block 1514 determines whether the completed survey form is valid. If it is not valid, control is passed back to block 1510 and the user completes the form again. If the form is valid, control is passed to block 1516 and the survey is created. Control is then passed to block 1518 which returns the user to the Surveys page 1504.

Referring to FIG. 16, a more detailed flow chart describing the structure and operation of Leaving a Survey Response with the Web Communication Server 114 is provided. The flow begins from block 1426. The Software Application Module 122 is configured to present the user a custom survey page when control is transferred to block 1602. Control is then transferred to block 1604 and the survey is displayed. This is accomplished when control is transferred to block 1606 and the File Manager 124 fetches the survey from the Surveys Database 161. When the survey is displayed, control is transferred to block 1610 and the user responds. The response is response is recorded in the Surveys Database 161 via a MySQL Server 136 update. Control is then transferred to block 1612 where the user is thanked and the survey is closed.

Referring to FIG. 17, a more detailed flow chart describing the structure and operation of Creating a Conference Call with the Web Communication Server 114 is provided. The flow begins when the user follows the 'Conferences' link 1702 from the Member Home page 1104. The user is then presented with the Conferences page in block 1704. Control is then passed to block 1706 where the user selects the 'Add new' button. The Software Application Module 122 is configured to pass control to block 1708 and presents the user with a conference form. The user fills out the form and control is passed to block 1710 for validation. Block 1712 determines whether the form is valid. If it is determined to be not valid, control is passed back to block 1708 and the user is presented with the form again. If block 1712 determines that the form is valid, the conference is created in 1714. Control is then passed to block 1716 which invokes the Mail Management Module 148 to send out notification of the conference call. The user is then returned to the conferences page 1704 via block 1718.

Referring to FIG. 18, a more detailed flow chart describing the structure and operation of Joining 2voo with the Web Communication Server 114 is provided. The flow begins from the sign-up page 1120. The user is presented with and completes the Join 2voo form 1128. Control is then transferred to block 1802 which checks the form for validation. From block 1802, control is passed to block 1804. If the form is determined to be invalid, the user is presented again with the Join 2voo form 1128. If the form is valid, control is passed to block 1806 and email is sent to the user to confirm the user' s desire to join. Control is then passed to block 1808 when the system receives confirmation from the user. Then, the activation page 1810 is presented. The User's database 158 is update via the MySQL Server 136. At this point, the User has successfully joined 2voo and is presented with a login page 1106.

Referring to FIG. 19, a more detailed flow chart describing the structure and operation of Managing Account Information with the Web Communication Server 114 is provided. The flow begins from the Member Home page 1104. The user follows the 'Edit my profile' link in block 1902. Control is then transferred to block 1904 where the user is presented with the Profile Home Page. The user completes the Profile form in block 1906. Control is transferred to block 1908 where the form is checked for validation. The Software Application Module is configured to transfer control to block 1910. If the form is not valid, control is return to block 1906 and the user is presented again with the Profile form. If the form is valid, control is passed to block 1912. The Users data is updated via a MySQL Server 136 update to the Users Database 158. This completes the flow for Managing Account Data and the user is returned to the Member Home page 1104.

Referring to FIG. 20, a more detailed flow chart describing the structure and operation of Adding a Contact with the Web Communication Server 114 is provided. The flow begins from the Member Home Page 1104. The user can do one of two actions. The user can select the 'Add Contact' link and control is passed to block 2008. Alternatively, the user can follow the 'Contacts' link in block 2002 and is presented with the Contacts page in block 2004. The user selects, 'Add Contact', in block 2006 and control is passed to block 2008 where the user is presented with and completes the Add Contact form. Control is then passed to block 2010, form is checked for validation and control is passed to block 2012. If the form is determined to be invalid, control is passed back to block 2008 and the user completes the Add Contact form again. If the form is determined to be valid, control is passed to block 2014 and the Contacts Database 166 is updated. The addition of the contact is now complete and the user is returned to the contacts page 2004.

Referring to FIG.21, a more detailed flow chart describing the structure and operation of Add/Edit of a group with the Web Communication Server 114 is provided. The flow begins from the Member Home Page 1104. The user can do one of two actions. The user can select the 'Add Group link and control is passed to block 2108. Alternatively, the user can follow the 'Groups' link in block 2102 and is presented with the Contacts page in block 2104. The user selects, 'Add Group' or 'Edit Group', in block 2106 and control is passed to block 2108 where the user is presented with and completes the Group Details form. Control is then passed to block 2110, form is checked for validation and control is passed to block 2112. If the form is determined to be invalid, control is passed back to block 2108 and the user completes the Group Details form again. If the form is determined to be valid, control is passed to block 2114 and the Groups Database 168 is updated. The addition of the group is now complete and the user is returned to the groups page 2104.

Referring to FIG. 22, where a more detailed flow chart describes the structure and operation of the mail management module 144. Mail management module 144 is generally configured to intuitively control or manage the amount of notifications send at any given time based upon the capacity of system 100. Capacity is defined as the ratio of the total number of needed slots to the total number of available slots. Mail management module 144 continuously monitors how many outstanding notifications exist. An outstanding notification is defined as a notification sent by mail management module 144 that has not be used by a recipient to access system 100. Mail management module 144 maintains and updates an available slot table 170 stored on database server 134 with the total number of available slots. One available slot is equal to one outstanding notification. This feature allows system 100 to employ a cost effective infrastructure while preventing overloading of system 100 when too many recipients of notifications from one or more users are logged on to system 100 or attempting to retrieve unread MNMs from data base 160. As will be described more fully herein, mail management module 144 limits the total amount of notifications to be sent from one or more users at any give time (the total amount fo needed slots) to less than two percent (2%) of the total number of available slots. Mail management module 144 allows system 100 to employ a cost effective infrastructure with a maximum number of available slots being less than ten thousand audio messages being accessed at any given time.

As shown by block 2202, upon receipt of a MNM to be sent, mail management module 144 is configured to first check load of system 100 by determining the total number of time slots available. The total number of time slots available equals the total number of outstanding notifications less the maximum number of time slots which in the preferred embodiment is ten thousand. As shown by block 2204, mail management module 144 is then configured to compare the total number of time slots needed for sending the current MNM with the total number of time slots available. If the need is less than two (2%) of available, control is passed to block 2216 where a time slot is allocated to send the MNM to all recipients.

Returning to block 2204, if the need for time slots is between 2% and 19.9% of the available time slots, control is passed to block 2212. The Mail Management Module 144 is configured to create a submessage with a volume of 2% of the available time slots. A submessage contains the content of the MNM, but the list of recipients has been reduced. Control is then passed to block 2216 to allocate a time slot.

Returning to block 2204, if the need for time slots is greater than 20% of the available time slots, control is passed to block 2206 where mail management module 144 is configured to determine if response data is available. Response data tracks the number of outstanding notifications to the number of used notifications at any give time. If the system determines that response data is available, then control is passed to block 2208 and the system determines what percent of the remaining recipients on the MNM list to send the MNM. Control is passed to block 2212 and a submessage is created for the selected recipients. Return to block 2206, if response data is not available, control is passed to block 2210. The Mail Management Module 148 is configured to use default response stats. Control is then passed to block 2214 which schedules 2% of the messages. From block 2214, two events occur. First, control is passed to block 2212 which creates a submessage from the 2% of messages scheduled in block 2214. Second, 2% of the remaining messages are scheduled into a submessage and control is passed to block 2234. Block 2234 adds the remaining submessages to a bulk message queue and passes them to block 2240. Block 2240 monitors system usage statistics and passes control to block 2238. Block 2238 checks the system load and passes control to block 2236 which checks time slot availability. When a time slot becomes available, control passes to block 2218 and the next submessage is added to the planned send. Returning to block 2216, after allocating a time slot, control is passed to block 2218. Block 2218 adds a submessage to planned send and passes control to block 2220. Block 2220 checks the current time slot and passes control to block 2222 to check the system load before sending the MNM in block 2224. Block 2226 determines whether the MNM is a submessage. If block 2226 determines that the MNM is a submessage, control is passed to block 2228 to compile stats for scheduling sending of the next submessage. Control is then passed to block 2230. The Mail Management Module 148 is configured in block 2230 to determine if the send is complete to all recipients. If it is determined that the send is not complete, control is passed to block 2212 to create another submessage from the list of remaining recipients with volume of 2% of the available time slots. Returning to block 2230, if it is determined that the send is complete, then control is passed to block 2232 and the Mail Management Module returns. Return to block 2226, if the MNM is not a submessage, control is passed to block 2232 and the Mail Management Module returns.

The foregoing description is intended for purposes of illustration. The invention may be embodied in other forms or carried out in other ways without departing from the spirit or scope of the invention.