Patent Publication Number: US-7724880-B2

Title: Networked voicemail

Description:
CROSS-REFERENCE 
     This application is related to the following U.S. patent applications: 
     Integrated Multi-Media Communication System, U.S. application Ser. No. 11/053,271, invented by Jens Skakkebaek, Heine Frifeldt, and Anthony Shaffer, filed Feb. 7, 2005; 
     Form-Based User Interface For Controlling Messaging, U.S. application Ser. No. 11/053,537, invented by Heine Frifeldt, Anthony Shaffer, and Willem R. B. Potze, filed Feb. 7, 2005; 
     Controlling Messaging Actions Using Form-Based User Interface, U.S. application Ser. No. 11/053,146, invented by Heine Frifeldt, Anthony Shaffer, and Willem R. B. Potze, filed Feb. 7, 2005; 
     Caching Message Information In An Integrated Communication System, U.S. application Ser. No. 11/053,147, invented by Shahriar Vaghar, Yang Wang, and Jens Skakkebaek, filed Feb. 7, 2005; 
     Distributed Cache System, U.S. application Ser. No. 11/053,411, invented by Shahriar Vaghar, Yang Wang, and Jens Skakkebaek, filed Feb. 7, 2005; 
     Caching User Information In An Integrated Communication System, U.S. application Ser. No. 11/053,272, invented by Jens Skakkebaek, Willem R. B. Potze, and Heine Frifeldt, filed Feb. 7, 2005; 
     Integrating Messaging Server Directory Service With Communication System Voice Mail Message Interface, U.S. application Ser. No. 11/053,709, invented by Heine Frifeldt, David Forney, and Anthony Shaffer, filed Feb. 7, 2005; 
     Improved Message Data Access In Multi-Media Communication System, U.S. application Ser. No. 11/053,736, invented by Jens Skakkebaek and Heine Frifeldt, filed Feb. 7, 2005; 
     System And Method For Voicemail Privacy, U.S. application Ser. No. 11/053,054, invented by Anthony Shaffer, Heine Frifeldt and David Forney, filed Feb. 7, 2005; 
     Extensible Diagnostic Tool, U.S. application Ser. No. 11/053,270, invented by David Forney, Heine Frifeldt, and Anthony Shaffer, filed Feb. 7, 2005; 
     System And Method For Providing Data On Voicemail Appliance, U.S. application Ser. No. 11/053,538, invented by Jens Skakkebaek and Lutz Birkhahn, filed Feb. 7, 2005; 
     Integrated Voice Mail User/Email System User Setup in Integrated Multi-Media Communication System, U.S. application Ser. No. 11/053,539, invented by Heine Frifeldt, David Forney, and Anthony Shaffer, filed Feb. 7, 2005; and 
     System And Method For Providing Code On Voicemail Appliance, U.S. application Ser. No. 11/053,376, invented by Jens Skakkebaek and Lutz Birkhahn, Feb. 7, 2005. 
     Each of the foregoing applications is incorporated herein by reference in its entirety. 
     TECHNICAL FIELD 
     The disclosure herein relates generally to communication systems, and more particularly to integrated communication and messaging systems. 
     BACKGROUND 
     As methods of communication continue to proliferate, enterprises continue to desire integrated systems for handling all aspects of multi-media communication for enterprise users. An enterprise can be any collection of users of communication media having some common purpose, but a typical example is a company with one or more sites and some number of employees who are users of communication media. Communication media include electronic mail (“email”) messaging, Short Messaging Service (“SMS”) messaging, voice messaging, and more. Users receive and send messages over a variety of wired and wireless networks via a variety of devices, such as desktop computers, wired phones, wireless devices (e.g., phones and personal digital assistants (“PDAs”)), and more. 
     Enterprises currently have the ability to centralize and manage email messaging using commercially available groupware that centrally stores information about all of the users and their messages. Enterprises also have the ability to centrally manage traditional voice messaging using a Private Branch Exchange (“PBX”). However, the systems for managing email messaging and the systems for managing voice mail messaging are not at all well integrated. For example, when a new user is added to the enterprise, a system administrator for the enterprise sets up the user in the email system using the groupware application and its set methods, data and protocols. In addition, a different administrator specializing in telephony must set up the user in the voice messaging system using different methods, data and protocols. Voice data and email data are typically stored in separate databases. Both initial user setup and updating user information are complicated by the fact that the email and voice systems are so distinct. 
     The management of and access to the voice mail message information and email information in the enterprise is also complicated by the current lack of integration of the two (voice and email) systems. There are various challenges to be overcome if one were to attempt to integrate the two systems. 
     INCORPORATION BY REFERENCE 
     All publications and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a network of communications systems with voicemail networking, according to an embodiment of the invention. 
         FIG. 2  is a flow diagram of receiving and sending an email containing a voicemail message, according to an embodiment of the invention. 
         FIG. 3  is a block diagram of two communications systems with voicemail networking and encapsulation and extraction devices, according to an embodiment of the invention. 
         FIG. 4A  is a block diagram of communications systems, some with voicemail networking, according to an embodiment of the invention. 
         FIG. 4B  is a block diagram of communications systems, some with voicemail networking, and a network enabled lookup device, according to an embodiment of the invention. 
         FIG. 5  is a flow diagram of receiving and routing an email containing a voicemail message, according to an embodiment of the invention. 
         FIG. 1-X  is a block diagram of a system that includes an integrated communication system (“ICS”), under an embodiment. 
         FIG. 2-X  is a flow diagram for providing integrated communication processes using the ICS, under an embodiment. 
         FIG. 3-X  is a block diagram of example information flows in a system that includes the ICS, under an embodiment. 
         FIG. 4-X  is another flow diagram for providing integrated communication processes using the ICS, under an embodiment. 
         FIG. 5-X  is a block diagram of an enterprise network system that includes a communication server and Interface Module (“IM”) of an ICS, under an embodiment. 
         FIG. 6-X  is a block diagram of an enterprise network system that includes the ICS, under an embodiment. 
         FIG. 7-X  is a block diagram that shows interactions between the IM and components of a messaging server (“MSERV”) environment, under an embodiment. 
         FIG. 8-X  is an information flow for routing and accessing voice mail messages via the ICS when the MSERV is in an online state, under an embodiment. 
         FIG. 9-X  is an alternative information flow for routing and accessing voice mail messages via the ICS when the MSERV is in an online state, under an embodiment. 
         FIG. 10-X  is an information flow for routing and accessing voice mail messages via the ICS when the MSERV is in an offline state, under an embodiment. 
         FIG. 11-X  is a block diagram of a system that includes the ICS with a Form-Based User Interface (“FBUI”), under an embodiment. 
         FIG. 12-X  is a sample FBUI as displayed on a client device, under an embodiment. 
         FIG. 13-X  is a block diagram of a system that uses a form-based interface transferred in a first type of message for controlling actions on a second type of message, along with the corresponding information flows, under an embodiment. 
         FIG. 14-X  is a selection popup the ICS provides during execution of the Play on Phone action, under an embodiment. 
         FIG. 15-X  is a status popup the ICS provides during execution of the Play on Phone action, under an embodiment. 
         FIG. 16-X  is another status popup the ICS provides during execution of the Play on Phone action, under an embodiment. 
         FIG. 17-X  is an information flow in a system that includes an ICS supporting Play on Phone operations, under an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     An embodiment of the invention is directed to allowing users in different organizations to exchange voicemail messages through electronic mail. The voicemail system stores voicemails as emails and uses a special format to store information about the voicemail. This format allows the user to access special voicemail features when the user accesses the email containing the voicemail. Under certain circumstances, a user, for example, a user in company A, may want to forward this email to an individual in another organization, for example, in company B. Ideally, the user would want for the recipient in company B to also be able to access some of the special voicemail features associated with the email. However, a standard email system may not support sending of the rich format of the email that was provided. Thus, the user in company B would not be able to have the benefit of the special voicemail features associated with the email. 
     An embodiment of the invention is directed to helping the recipient in company B to access some of the special voicemail features associated with the email. When the user in company A sends the email to the recipient in company B, the special voicemail formatting is encapsulated into a format that can be included in the email sent from company A to company B. When the email is received at company B, the special voicemail formatting can be extracted. As a result, the recipient in company B will be able to access some of the special voicemail features associated with the email. According to an embodiment of the invention, the system in company A checks whether the recipient&#39;s system supports emails with the special voicemail formatting. If the recipient&#39;s system supports this kind of email, the special voicemail formatting is encapsulated and sent in the email as described above, and if the recipient&#39;s system does not support this kind of email, the special formatting is not included with the email. 
       FIG. 1  is a block diagram of a network of communications systems with voicemail networking, according to an embodiment of the invention. In the combination of systems shown in  FIG. 1 , emails containing voicemail messages can be forwarded from one email system to various other email systems and retain particular features not generally part of an email communication system. 
       FIG. 1  includes system A  101 , system B  102 , system C  103 , system D  104  and internet  114 . System A includes private communication network  105 , system A voicemail system  106 , system A email system  107 , user A  108  and user B  109 . System B includes system B voicemail system  116 , system B email system  115  and user C  117 . User A  108  includes computer system  110  and telephone device  112 , and user B  109  includes computer system  111  and telephone device  113 . System A email system  107  includes a rich format voicemail email  121 , encapsulation block  122 , and email with encapsulated data  123 . System B email system  115  includes email with encapsulated data  118 , extraction block  119 , and rich format voicemail email  120 . 
     Each of system A  101 , system B  102 , system C  103 , and system D  104  is coupled to Internet  114 . The various systems include various components of communications and computer network systems. For example, in system A  101 , private communications network  105 , system A voicemail system  106 , system A email system  107 , user A  108  and user B  109  are coupled together through one or several networks. Similarly, the other systems shown include elements of voice and data communications networks. For example, system B  102  includes system B voicemail system  116  coupled to system B email system  115  and user C  117 , which is also coupled to system B email system  115 . The various components of the systems shown in  FIG. 1  are coupled through Internet  114 . The blocks shown in  FIG. 1  and other descriptions herein of the invention may be implemented as software, hardware or combinations of software and hardware. 
     According to an embodiment of the invention, system A  101 , system B  102 , system C  103 , and system D  104  each represents communications systems of different organizations, such as different companies. Users of these different systems of the various organizations would like to be able to exchange voicemail messages to others having similar equipment even though they are at different organizations. In the system, voicemail messages may be stored as a rich format voicemail email. This may mean that the email containing the voicemail message has various particular features beyond those that are included in a standard email. This would allow a user, for example, to see certain special choices or buttons on the user interface that would allow the user to take certain actions that relate to voicemail messages, such as playing, forwarding or other unique voicemail actions. Such rich format voicemail email may not be supported by a typical email that is sent over the Internet, such as an email that is sent over Internet  114 . Thus, a recipient on another organization&#39;s system may not be able to use some of the particular features of the voicemail system for the received email if the rich format is not retained. In order to allow for the rich format to be used on another system, certain data from rich format voicemail email  121  is encapsulated in encapsulation block  122 . The result is email with encapsulated data  123 . 
     Email with encapsulated data  123  is passed to another email system, such as system B email system  115 . This email is received in system B email system  115 , as email with encapsulated data  118  as shown in  FIG. 1 . The rich format of the email is extracted in extraction block  119 . The result is a corresponding rich format voicemail email  120 , which corresponds to the rich format of rich format voicemail email  121  from system A email system  107 . Thus, user C  117  is able to view rich format voicemail email  120  and experience some of the unique voicemail actions and particular features of the user interface that were available on system A email system  107  to users such as user A  108  or user B  109 . 
     If system C  103  is similarly enabled to extract and use the rich format of the email with encapsulated data  123 , a user on system C  103  will similarly be able to experience the unique voicemail actions and particular features of the received email. However, other systems not equipped with the requisite extraction logic and/or voicemail system may not necessarily be able to display the rich format email, or extract the rich format of the email, and therefore not be able to provide the corresponding unique voicemail actions or particular features of the received email. System A email system  107  may account for this by not encapsulating the data from the rich format voicemail email and instead by sending a simplified form of the email with the included voicemail audio data. For example if system D  104  is not able to extract and use the rich format of the email, according to an embodiment of the invention, system A email system  107  does not encapsulate the data from the rich format voicemail email and instead sends a simplified form of the email with the included voicemail audio data to system D  104 . 
       FIG. 2  is a flow diagram of receiving and sending an email containing a voicemail message, according to an embodiment of the invention. A user receives a rich format voicemail email (block  201 ). The rich format may mean that the email containing the voicemail message has various particular features beyond those that are available with a standard email, which would allow the user, for example, to see certain special choices or buttons on the user interface that would allow the user to take certain actions that relate to voicemail messages, such as playing, forwarding or other unique voicemail actions. 
     The user requests to forward the rich format voicemail email to a recipient on a remote voicemail system, for example to a recipient at a different organization with its own voicemail system. Such request may be made by an action on a user interface, such as by a command in a voice interface or selection of a button on a graphical user interface. The rich format data is encapsulated (block  202 ) and packaged into the outgoing email (block  203 ). The email with the encapsulated data is sent to the remote system, which is a different communication system that is coupled to the intended recipient of the email (block  204 ). The remote system extracts the rich format data from the received email (block  205 ). The remote system then provides a rich format voicemail email from the received email and the extracted data (block  206 ). The resulting rich format voicemail email is then displayed to the user that was the intended recipient of the email containing the voicemail (block  207 ). The user is then able to experience some of the same unique voicemail actions and particular features that were available to the user sending the rich format voicemail email. 
       FIG. 3  is a block diagram of two communications systems with voicemail networking and encapsulation and extraction devices, according to an embodiment of the invention. In the systems shown in  FIG. 3 , a rich format voicemail email is transmitted from one system to the other system, while preserving the rich format data through the use of encapsulation logic and extraction logic applied when the email is sent and received, respectively. 
       FIG. 3  includes a system A  301  and system B  302 . System A includes system A email system  303 , and system B  302  includes system B email system  304  and user C  305 . System A email system includes a rich format voicemail email  306 , encapsulation block  307 , and forwarded email  308 . Rich format voicemail email  306  includes voicemail properties  309 , and forwarded email  308  includes encapsulated data  310  and standard email attributes  311 . System B email system  304  includes received email  312 , extraction block  313 , and rich format voicemail email  314 . Received email  312  includes encapsulated data  315  and standard email attributes  316 , and rich format voicemail email  314  includes voicemail properties  317 . User C  305  includes computer system  318  and telephone device  319 . Also shown is message  320  displayed from computer system  318 . Message  320  includes play button  321  and forward button  322 . 
     System A  301  and System B  302  are each part of various communications and computer network systems. System A email system  303  and system B email system  304  are coupled by way of Internet  323 . User C  305  is coupled to system B email system  304 . 
     In the system, a rich format voicemail email may be forwarded to a user on a different email system. So long as the email system from which the rich format voicemail email is forwarded and the email system to which the rich format voicemail email is forwarded both have the capability to recognize and use the particular format, the rich format properties will be preserved. The rich format may mean that the email containing the voicemail message has various particular features beyond those that are available with a standard email, which would allow the user, for example, to see certain special choices or buttons on the user interface that would allow the user to take certain actions that relate to voicemail messages, such as playing, forwarding or other unique voicemail actions, or other voicemail properties. 
     In one embodiment of the invention, Messaging Application Programming Interface (MAPI) is used as a method of preserving the rich format data contained in the rich format email by assigning MAPI properties to corresponding rich format data. MAPI is used by various industry-standard email clients, such as the Microsoft Exchange client. MAPI is a mechanism to access information in Exchange and enables different email systems to work together to distribute email. In Exchange, email message properties are stored as MAPI properties, which contain general email message properties, including recipient, sender, email body and email subject, and Exchange specific email message properties, including unique identifiers for the sender, each recipient and the message itself. However, MAPI does not work well outside an intranet. Thus, if the sending and receiving email systems utilize Exchange to handle emails, and are each part of the same organization using one intranet, all MAPI properties, which preserve the rich format data of an email, will be preserved by Exchange when sent from the sending system to the receiving system. However, when the sending system is a member of one organization using one intranet, and the receiving system is a member of a different organization not using the same intranet, even if they both utilize Exchange to handle emails, when the sending system sends the email to the receiving system, Exchange may strip off the Exchange specific email message MAPI properties from the email. In this situation, Exchange provides a simplified form of the email with only the general email message MAPI properties, which may include voicemail audio data, but none of the Exchange specific email message MAPI properties, which include voicemail properties. 
     In an embodiment of the invention, Exchange specific MAPI properties are assigned for each of the voicemail properties  309  contained in rich format voicemail email  306 , resulting in voicemail properties  309  being stored in MAPI format. If system A  301  and system B  302  are each part of the same organization, using the same intranet that uses Exchange to handle emails, the MAPI format is preserved when a user in system A  301  sends rich format voicemail email  306  to a user in system B  302 . However, if system B  302  is part of a different organization not using the same intranet as system A  301 , Exchange may strip off the Exchange specific MAPI properties associated with voicemail properties  309 . 
     Thus, given that system A  301  and system B  302  are each part of a common network of voicemail systems, rich format voicemail email  306 , containing the voicemail properties  309 , is encapsulated in block  307 . System A email system  303  uses a MAPI transport provider to convert MAPI properties into a Transport-Neutral Encapsulated Format (TNEF) serial data stream. TNEF defines several TNEF-specific attributes, each of which corresponds to a particular MAPI property. These attributes are used to encode the corresponding MAPI properties into the TNEF serial data stream. TNEF is primarily used by transport providers that need to encode MAPI message properties for transmission through a messaging system that does not support those properties directly. Thus, before an email containing MAPI properties is sent, the MAPI transport provider converts the MAPI Properties into a TNEF data stream, and encapsulates the TNEF data stream into a special attachment on the outgoing email, using the underlying email system&#39;s attachment model. For example, Simple Mail Transfer Protocol (SMTP)-based transport, which is a protocol for sending email messages between email systems, uses a MAPI transport provider to encode MAPI properties into a TNEF data stream. Exchange, which is utilized by system A email system  303  to handle email, sends message  308 , which includes standard email attributes  311 , such as “to” and “from” fields, and the TNEF data stream attachment, as encapsulated data  310 , which is usually named “winmail.dat.” 
     The received email  312 , which contains the encapsulated data  315  and the standard email attributes  316 , is delivered to system B email system  304 . Exchange, which is utilized by system B email system  304  to handle email, uses the MAPI transport provider in extraction block  313  and extracts the MAPI properties from the TNEF serial data stream contained in encapsulated data  315 . Exchange recognizes the MAPI properties corresponding to rich format data. The result is a corresponding rich format voicemail email  314 , containing voicemail properties  317 , which corresponds to the rich format voicemail email  306 , containing voicemail properties  309 , from system A email system  303 . As a result, the users in the organizations associated with system A  301  and system B  302  may get the experience of having their voicemail systems networked. 
     Thus, user C  305  is able to view rich format voicemail email  314  on computer system  318 , along with the voicemail properties  317 , in a similar manner as displayed in message  320 . User C  305  can then take certain actions that relate to voicemail messages, such as playing, forwarding or other unique voicemail actions, by pressing the appropriate button displayed on the user interface. For example, user C  305  may play the voicemail message by pressing play button  321 , or forward the voicemail message by pressing the forward button  322 . One feature supported by the voicemail system based on the special voicemail formatting may be that a voicemail email message can be played on the user&#39;s telephone. Thus user C  305  may be able to play voicemail email message  317  on telephone device  319  using the special voicemail formatting in voicemail email  314 . 
       FIG. 4A  is a block diagram of communications systems, some with voicemail networking, according to an embodiment of the invention. In the system shown in  FIG. 4A , a rich format voicemail email is routed and sent according to the network properties of the recipient system.  FIG. 4A  includes system A  401 , system B  402 , system C  403 , system D  404  and Internet  405 . System A  401  includes system A email system  406 , rich format voicemail email  407 , routing block  408 , network enabled lookup block  409 , dividing block  410 , encapsulation block  411 , no encapsulation block  412  and send email block  413 . 
     Each of system A  401 , system B  402 , system C  403 , and system D  404  is coupled to Internet  405 . The various systems may or may not be members of a common network of voicemail systems. For example, system A  401 , system B  402  and system C  403  have corresponding voicemail capabilities that allow for special voicemail features of inbound emails to be used. The various systems may contain various components of communications and computer network systems. For example, system A includes system A email system  406 . 
     In the system, a rich format voicemail email, such as rich format voicemail email  407 , may be forwarded to a user on a different email system, such as a user coupled to system B  402 , a user coupled to system C  403 , or a user coupled to system D  404 . When a user of system A email system  406  forwards a rich format voicemail email  407 , before email  407  is sent, it is analyzed in routing block  408 . Routing block  408  will use network enabled lookup  409  to determine if the recipient system is able to receive and use the special voicemail formatting of voicemail email  407 . 
     If network enabled lookup  409  determines the recipient network is a member of the common network of voicemail systems, routing block  408  causes dividing block  410  to provide rich format voicemail email  407  to be encapsulated in encapsulation block  411 . If network enabled lookup  409  determines the recipient network is not a member of the common network of voicemail systems, routing block  408  causes dividing block  410  to provide rich format voicemail email  407  to no encapsulation block  412  and rich format voicemail email  407  is not encapsulated. If rich format voicemail email  407  is sent to encapsulation block  411 , the rich format data is encapsulated. The sent email block  413  then sends the forwarded email, whether or not the rich format data has been encapsulated, to the recipient system. 
     If the recipient system is a member of the common network of voicemail systems to which system A  401  is a member, it will receive the forwarded email with encapsulated rich format data. If the recipient system is not a member of the common network of voicemail systems, it will receive a simplified form of the email with the included voicemail audio data. For example, given that system A  401 , system B  402  and system C  403  are all members of a common network of voicemail systems, system B  402  and system C  403  receive the forwarded email with encapsulated rich format data. Given that system D  404  is not a member of the common network of voicemail systems, system D  404  only receives a simplified version of the email. The email system corresponding to system B  402  or system C  403 , as the case may be, then extracts the encapsulated rich format data from the forwarded email, and provides to its users a rich format voicemail email corresponding to the rich format voicemail email  407  in system A email system  406 . 
       FIG. 4B  is a block diagram of communications systems, some with voicemail networking, and a network enabled lookup device, according to an embodiment of the invention. Before a user on a system sends a rich format voicemail email outside the system, a network enabled lookup device checks to see if the remote system of the intended recipient is registered to receive emails in a format that preserves the rich format properties of the email. If the remote system of the intended recipient is registered, the two systems are compatible with one another, and each is part of a virtual network of voicemail systems.  FIG. 4B  includes system A  450 , system B  451 , system C  452 , registration service  460 , and Internet  462 . System A  450  includes system A voicemail system  453  and system A email system  454 , system B  451  includes system B email system  455  and system B voicemail system  456 , and system C  452  includes system C email system  457 . Also shown is registration service  460 , which includes database  461 , and the entry chart  465 . 
     Each of system A  450 , system B  451 , system C  452  and registration service  460  is coupled to Internet  462 . The various systems may or may not include voice mail systems, and may or may not be registered to be compatible with one another. For example, system A  450  and system B  451  contain system A voicemail system  453 , and system B voicemail system  456 , respectively. Company A, which uses system A  450 , and company B, which uses system B  451 , may then be registered to receive and use emails in a format that preserves the rich format properties of the voicemail email, but company C, which uses system C  452 , is not registered, as shown in entry chart  465 . By registering, company A and company B each becomes part of a virtual network. 
     Thus, before a user from company A sends a rich format voicemail email to a user from company B and a user from company C, network enabled lookup  458  checks with database  461  of registration service  460 , and since company B is registered, routing block  459  sends email  463  containing the rich format data to the user from company B; however, since company C is not registered, routing block  459  sends email  464  not containing the rich format data to the user from company C. Therefore, the users from company A may forward rich format voicemail emails to users from company B, and the company B users experience the voicemail properties in a similar manner experienced by the company A users. However, since they are not part of the virtual network, the company C users only receive a simplified form of the email with the included voicemail audio data delivered to system C email system  457 . 
     Optionally, system A  450  may have local cache  466 , and the registration data corresponding to a remote system is stored locally on cache  466 . Thus, before a user from company A sends a rich format voicemail email to a user from a different company, for example a user from company B, network enabled lookup checks with database  461  of registration service  460 , and stores company B&#39;s registration data in cache  466 . Thereafter every time before a user from company A sends a rich format voicemail email to a user from company B, network enabled lookup  458  checks registration data from cache  466 . Network enabled lookup  458  may periodically check registration data in database  461  for updates. 
     In one embodiment of the invention, network enabled lookup  458  uses a Domain Name System (DNS) lookup of the domain name recipient service (SRV) record. DNS translates domain names into Internet Protocol (IP) addresses, and an SRV record provides information on available services for a given domain name. When an email system sends out an email, it uses DNS to convert the domain name corresponding to the email address to an IP address. DNS also performs a lookup of the domain name and determines where to send the email, based on the SRV record of the domain name. In such an embodiment of the invention, the SRV record for a domain name of a system, which is part of the virtual network, will include some identification that the system is part of the virtual network. DNS also determines if the domain name is part of the virtual network. For example if a user from company A desires to forward a rich format voicemail email to a user on company B, whose email address is “user@companyB.com,” before the voicemail email is sent, network enabled lookup  458  looks up “companyB.com” using a DNS lookup and, given that company A and company B are members of the virtual network, network enabled lookup  458  finds that the SRV record of companyB.com contains an identification that companyB.com is part of the virtual network of voicemail systems. Given that company D is not a member of the virtual network of voicemail systems, if a user from company A sends a rich format voicemail email to a user from company B, the DNS lookup of company B&#39;s domain finds that the SRV record of companyD.com will not contain any identification that company D is a member of the virtual network. 
     In another embodiment of the invention, a system administrator of system A  450  system specifies which remote systems belong to the virtual network, and stores such data in a database or file that may be located on optional cache  466 , or in a database outside system A  450 . Network enabled lookup  458  then checks compatibility of the recipient system against the database or file. In such an embodiment of the invention, the system may not include registration service  460 . Alternatively, registration service  460  may be used in combination with information maintained by the system administrator. 
     In another embodiment of the invention, compatibility data normally stored in database  461 , which is located outside system A  450 , may be downloaded by system A email system  454  and be stored in local cache  466 . Network enabled lookup  458  then checks compatibility of the recipient system against the downloaded data. 
     In another embodiment of the invention, web services are used to check compatibility recipient system to receive the rich formatted voicemail. Such web services may be used as an alternative to the DNS lookup described herein. Embodiments of web services may include integration of Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. According to various embodiments, XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. According to an embodiment of the invention, a service is used to check compatibility recipient system to receive the rich formatted voicemail, such as web services, which share business logic, data and processes through a programmatic interface across a network. 
       FIG. 5  is a flow diagram of receiving and routing an email containing a voicemail message, according to an embodiment of the invention. A user receives a rich format voicemail email (block  501 ). The rich format may mean that the email containing the voicemail message has various particular features beyond those that are available with a standard email, which would allow the user, for example, to see certain special choices or buttons on the user interface that would allow the user to take certain actions that relate to voicemail messages, such as playing, forwarding or other unique voicemail actions. 
     The user desires to forward the rich format voicemail email to another individual on a recipient system. Prior to the email being forwarded, lookup logic determines if the recipient system is a part of the common network of voicemail systems to which the sending system is a member (block  502 ). If the recipient system is a member of the common network of voicemail systems, then both systems are part of a virtual network. 
     In one embodiment of the invention, the lookup logic uses a DNS lookup of the domain name SRV record. When an email system sends out an email, DNS performs a lookup of the recipient domain name and determines where to send the email, based on the SRV record of the domain name. In such an embodiment, the SRV record for a domain name of a system, which is part of the virtual network of voicemail systems, will include some identification that the system is part of the virtual network. In the same manner DNS lookup allocates where to send the email within a domain name, it will also determine if the domain name is part of the virtual network of voicemail systems. 
     In another embodiment of the invention, the system administrator of the sending system specifies which recipient systems belong to the virtual network of voicemail systems, and stores such data in a database or file that may be located on sending system local cache, or in a database outside the sending system. The lookup logic would then check the virtual network status of the recipient system against the database or file. 
     In another embodiment of the invention, virtual network status of recipient systems normally stored in a media outside the sending system may be downloaded by the email system of the sending system and be stored in local cache. The lookup logic checks virtual network status of the recipient system against the downloaded data. 
     If the receiving system is part of the virtual network of voicemail systems, the rich format data is encapsulated (block  503 ) and packaged into the outgoing email. If the receiving system is not a member of the virtual network of voicemail systems, the rich format data is not encapsulated, and a simplified form of the email with the included voicemail audio data is queued for transmission. 
     The email, whether or not the rich format data has been encapsulated, is sent to recipient system (block  504 ). Recipient systems that are part of the virtual network of voicemail systems extract the rich format data from the received email and provide a rich format voicemail email from the received email and the extracted data. The resulting rich format voicemail email is then displayed to the user that was the intended recipient of the rich format voicemail email. The user is then able to experience some of the same unique voicemail actions and particular features of the user interface that were available to the user sending the rich format voicemail email. Recipient systems that are not part of the virtual network of voicemail systems only receive the simplified form of the email with the included voicemail audio data. 
     The following is a non-exhaustive description of various embodiments of systems and methods with which the methods and systems described above may be combined. For example, the systems and methods described above for networking of voicemail systems may be employed in combination with the form-based interface for use in retrieving voice mail messages and controlling actions taken on voice mail messages received in an enterprise network system. Thus, according to an embodiment, a rich-format email is used to allow a user to use a form-based interface even when the email is sent over a network to a different system. 
     Integrated multi-media communication systems and methods are provided below. These communication systems and methods, collectively referred to herein as “integrated communication systems” or “ICS,” integrate different types of messaging so that a user of the ICS can access multiple types of messages (e.g., voice mail messages, electronic mail, email messages, instant messaging messages, SMS (Short Messaging System) messages, MMS (Multimedia Messaging System) messages, etc. with a single message interface. In providing integrated messaging functionality via a single message interface, the ICS of an embodiment relieves the dependency of a voice mail system, for example, by providing users with access to voice mail messages and capabilities of the voice mail system through the local groupware applications and email messaging system. 
     The ICS generally includes a communication server, a cache system, and an interface module. The ICS integrates with a messaging and collaboration system and the corresponding groupware applications in a network environment for example. In providing integrated messaging capabilities, the communication server and interface module function to route a call received from a caller to a user and, in the event the user is not available, to receive and route a voice mail message left by the caller. The ICS uses caching processes during the receiving and routing of voice mail messages that provide users with fast access to voice mail messages, user information and contact information. Using caching process, the ICS also provides access to the voice mail messaging system during periods when the messaging and collaboration system is offline. The ICS also leverages the storage capability of the messaging and collaboration system to eliminate the need for a separate voice mail database. 
     The message interface of the ICS includes a form-based interface for use in retrieving voice mail messages and controlling actions taken on voice mail messages received in the enterprise network system. This form-based interface enables a user to retrieve and take various actions on voice mail messages using data of a form provided to the user&#39;s client device by the enterprise network email system. Use of the form-based interface thus provides users with access to the integrated messaging functions offered by the ICS without a requirement to install or run a dedicated client application on the user&#39;s client device. 
     In the following description, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the ICS. One skilled in the relevant art, however, will recognize that these embodiments can be practiced without one or more of the specific details, or with other components, systems, etc. In other instances, well-known structures or operations are not shown, or are not described in detail, to avoid obscuring aspects of the disclosed embodiments. 
       FIG. 1-X  is a block diagram of a system  10 -X that includes an integrated communication system (“ICS”)  100 -X, under an embodiment. ICS  100 -X includes a communication server  110 -X, an interface module (“IM”)  120 -X, and a cache system  130 -X (also referred to as the “cache”), but is not so limited. Communication server  100 -X couples to components of any number of networks  150 -X and  160 -X using any of a variety of communication protocols, where networks  150 -X and  160 -X may be of the same or of different types. Networks  150 -X and  160 -X allow for information transfers between various client devices  170 -X and  199 -X, also referred to as user devices  170 -X and  199 -X. 
     IM  120 -X of ICS  100 -X couples to transfer information or data with communication server  110 -X. Additionally, IM  120 -X couples to transfer information with one or more components of a messaging server  140 -X, where transferring information includes one or more of pulling, receiving, retrieving, polling, transmitting, and pushing operations, to name a few. As an example of an information transfer between IM  120 -X and messaging server  140 -X, IM  120 -X pulls user information from messaging server  140 -X and makes the pulled user information available to other components of ICS  100 -X, wherein the user information includes information relevant to at least network  150 -X. 
     The components of messaging server  140 -X may include for example one or more processors  142 -X, also referred to as “central processing units” or “CPUs,” and one or more databases  144 -X coupled to CPU  142 -X. In an embodiment, IM  120 -X may be hosted on or running under control of messaging server  140 -X, but is not limited to this configuration. Further, messaging server  140 -X may be a component of network  150 -X that hosts communication server  110 -X, but is not so limited. For example, messaging server  140 -X may be hosting a groupware application (e.g., Microsoft Exchange, LotusNotes, etc.) of an enterprise network  150 -X. 
     Cache  130 -X couples to communication server  110 -X and communicates to transfer information with one or more of communication server  110 -X, IM  120 -X, and one or more components of messaging server  140 -X, as described below. Cache  130 -X may also couple to additional components (not shown) of network  150 -X. 
     As an example of information transfers between cache  130 -X and communication server  110 -X, cache  130 -X may receive caller information (e.g., voice mail messages, caller identification, etc.) from client devices  199 -X via communication server  110 -X. An example of information transfers between cache  130 -X and messaging server  140 -X includes transfers in which cache  130 -X receives user information from messaging server  140 -X, where the user information may be routed from messaging server  140 -X via IM  120 -X and/or communication server  110 -X. Another example of information transfers between cache  130 -X and messaging server  140 -X includes transfers in which messaging server  140 -X receives information from cache  130 -X routed from cache  130 -X via communication server  110 -X and/or IM  120 -X. 
     Examples of information transfers between cache  130 -X and IM  120 -X include transfers of user information pulled from messaging server  140 -X by IM  120 -X and directed to cache  130 -X, and transfers in which IM  120 -X directs a message from at least one of messaging server  140 -X and cache  130 -X to at least one device on networks  150 -X and  160 -X using the user information. Cache  130 -X holds or temporarily stores the received information under the above examples. 
     Networks  150 -X and  160 -X include various network components (not shown) of one or more communication service providers or carriers, but are not so limited. Further, networks  150 -X and  160 -X and corresponding network components can be any of a number/combination of network types known in the art for providing communications among coupled devices  170 -X and  199 -X including, but not limited to, proprietary networks, local area networks (“LANs”), metropolitan area networks (“MANs”), wide area networks (“WANs”), backend networks, public switched telephone networks (“PSTN”), the Internet, and other public networks for example. Additionally, networks  150 -X and  160 -X may include hybrid networks that use a proprietary network for some portion of the communications routing, for example, while using one or more different public networks for other portions of the communications routing. 
     Client devices  170 -X and  199 -X include communication devices like telephones, cellular telephones, and radio telephones. Client devices  170 -X and  199 -X also include processor-based devices like, for example, portable computers (“PC”), portable computing devices, personal digital assistants (“PDA”), communication devices, cellular telephones, portable telephones, portable communication devices, and user devices or units. Client devices can include so-called multi-modal devices, where the user can interact with the device and/or the ICS through any form of input and output, such as text input, speech recognition, text output, text-to-speech, graphics, recorded files and video. In such devices, the speech recognition and text-to-speech generation may partly take place in the device and partly in the ICS. Sound and/or video may be generated by the ICS by a continuous stream of sound and/or video data sent to the device. Client devices can include all such devices and equivalents, and are not limited to any particular type of communication and/or processor-based device. In an embodiment client devices  170 -X are client devices operating in a private network environment like an enterprise network, while client devices  199 -X are client devices operating in different private network environments or under any number of public networks. 
       FIG. 2-X  is a flow diagram for providing integrated communication processes  200 -X using ICS  100 -X, under an embodiment. Processes  200 -X include receiving data streams from networks of different types, at block  202 -X. The data streams may include a variety of data including, for example, audio or voice data. Further, the data streams may be received from any number of networks or client devices operating on the networks. Processes  200 -X further include generating messages at a communication server using information of the data streams, at block  204 -X. The generated messages may be any of a number of message types. Returning to the above example in which the received data stream includes audio data, the generated message is a voice mail message, but is not so limited. Processes  200 -X also include transferring the messages, at block  206 -X. The transferring operation includes for example caching information of the messages in the ICS cache and/or forwarding the messages to a messaging server. 
     Continuing, processes  200 -X include pulling user information from a messaging server coupled to the ICS, at block  208 -X, as described above. The user information includes information relevant to users of at least the network hosting the ICS, but is not so limited. Processes  200 -X also include caching pulled user information from the messaging server, at block  210 -X. Additionally, processes  200 -X include use of the user information of the cache to direct a message from at least one of the messaging server and the cache to one or more client devices on any of the networks, at block  212 -X. 
     The ICS of an embodiment integrates different types of messaging so that a user of the ICS can access all of the message types (e.g., voice mail messages, electronic mail or email messages, etc.) with a single message interface (also referred to as a “user interface” or “UI”). In providing integrated messaging functionality via a single message interface, the ICS of an embodiment relieves the dependency on a voice mail system with a dedicated voicemail and user database, for example, by providing users with access to voice mail messages and capabilities of the voice mail system through the local email messaging system. 
       FIG. 3-X  is a block diagram of example information flows  300 -X in a system  30 -X that includes ICS  100 -X, under an embodiment. The system also includes a messaging server  140 -X and any number of client devices  170 -X that couple to ICS  100 -X. In addition, ICS  100 -X couples to a communications network  160 -X. ICS  100 -X, messaging server  140 -X, and client devices  170 -X may be hosted under a network  150 -X, but are not so limited. System  30 -X is shown with one each of ICS  100 -X, messaging server  140 -X, and client device  170 -X for purposes of this description, but may include any number of each of ICS  100 -X, messaging server  140 -X, and client device  170 -X coupled in any combination. System  30 -X may also couple to one or more other systems (not shown) or networks via any number of backend couplings (not shown) 
     Components of ICS  100 -X include a communication server and an interface (not shown). The interface of ICS  100 -X may run under control of messaging server  140 -X, as described above, but is not so limited. Information flow  300 -X begins when, in response to receiving data streams from networks  160 -X of different types, ICS  100 -X generates a first message  302 -X and transfers first message  302 -X to messaging server  140 -X via a communication with messaging server  140 -X. First message  302 -X may be a voice mail message (“Voice Mail Type” or “VMT”) but is not limited to this type of message. For purposes of the description herein, a voice mail message is left by a “caller” to the ICS. For example, in an embodiment where Microsoft Exchange is the messaging server  140 -X, the VMT may be implemented using “Message Class” and/or “Message Type” fields associated with messages in Microsoft Exchange. 
     Following or simultaneous with receipt of first message  302 -X, the messaging server  140 -X detects or identifies a type of first message  302 -X using information of the first message and generates a second message  312 -X. Second message  312 -X is of a different type from that of first message  302 -X, and includes information of first message  302 -X. Second message  312 -X may for example be an email message but is not limited to this type of message. Second message  312 -X is transferred to a client device  170 -X via a communication with client device  170 -X, where the communication uses a communication protocol of network  150 -X. 
     Responsive to receipt of second message  312 -X, client device  170 -X determines a type of the second message and requests form data  314 -X that corresponds to second message  312 -X. Messaging server  140 -X, in response to the request for form data  314 -X, transfers form data  314  to client device  170 -X via the second coupling. One or more components of ICS  100 -X generate and/or provide form data  314 -X for storage in messaging server  140 -X, and form data  314 -X is generated under the communication infrastructure of network  150 -X. The form data may be displayed to the user using the corresponding form. 
     Client device  170 -X uses form data  314 -X to view contents of second message  312 -X. The client device also uses form data  314 -X to establish communications with communication server  110 -X (of ICS  100 -X) via a third coupling. The communication protocol of the third coupling is different than the communication protocol of the second coupling, but is not so limited. An “embedded control” controls activation of the third coupling. Furthermore, the client device allows a “user” using the client device to direct actions  322 -X on first message  302 -X via the third coupling with the ICS using the form data. For purposes of the description herein, a “user” is an individual with enabled capability to use functions within the ICS. 
     As an example under information flows  300 -X,  FIG. 4-X  is a flow diagram for integrated communication processes  400 -X using ICS  100 -X, under an embodiment. Processes  400 -X include transferring a first message to a messaging server from a communication server via a first coupling, at block  402 -X. Processes  400 -X also include generating a second message at the messaging server in response to a type of the first message and transferring the second message to a client device via a second coupling, at block  404 -X. The second message may be of a different type than the first message and includes data of the first message. Processes  400 -X further include transferring to the client device form data that corresponds to the first message, at block  406 -X. Additionally, processes  400 -X include establishing a third coupling between the client device and the communication server using the form data, at block  408 -X. Moreover, processes  400 -X include directing actions on the first message from the client device using the form data, the actions directed via the third coupling, at block  410 -X. 
     The ICS of an embodiment integrates messages of different types to enable a user to access a number of message types through components of the ICS. Thus, an application of the ICS of an embodiment is as a substitute for a voice mail system in an enterprise network, where the ICS enables a user to receive and/or take action on voice mail messages using the enterprise email system. 
       FIG. 5-X  is a block diagram of an enterprise network system  500 -X that includes a communication server  110 -X and IM  120 -X of an ICS, under an embodiment. Communication server  110 -X couples to at least one messaging server  140 -X via IM  120 -X. IM  120 -X runs under messaging server  140 -X, but is not limited to running under this server. Messaging server also couples to one or more databases  144 -X. Messaging server  140 -X of an embodiment supports the messaging capabilities of enterprise network system  500 -X using a groupware application (e.g., Microsoft Exchange) (not shown) along with other applications as appropriate to the size and type of enterprise network system  500 -X. Messaging server  140 -X, database  144 -X, and groupware application (not shown) may be referred to as collectively forming a “messaging environment.” 
     Communication server  110 -X couples to any number of client devices  199 -X external to enterprise network  500 -X via one or more networks (not shown), as described above with reference to  FIG. 1 . Similarly, communication server  110 -X couples to any number of client devices  170 -X local to enterprise network  500 -X. 
     Communication server  110 -X includes an operating system  518 -X as well as numerous components or subsystems. These components include but are not limited to one or more Voice Applications  512 -X, an Execution Engine  514 -X, and any number of Mobile Application Modules  516 -X, as described below, or any other type of application module. 
       FIG. 6-X  is a block diagram of an enterprise network system  600 -X that includes an ICS, under an embodiment. The ICS includes a communication server  610 -X as described above, also referred to as a “Messaging Communication Server” or “MCS.” The MCS may be highly scalable. According to an embodiment of the invention, the MCS may be configured as a modular “appliance” that is essentially self-contained, and may be, for example, encased in a stackable, “pizza-box” style server. The ICS also includes IM  620 -X (also referred to herein as the “IM”) and a Management Console  660 -X. The IM, which in one embodiment runs under control of a messaging server  640 -X (also referred to herein as “MSERV  640 -X” or “MSERV”), couples to components of the MCS, the MSERV, and a Database  644 -X (also referred to herein as a “Database”) in a number of sequences as described herein and as appropriate to enterprise network system  600 -X. The IM also couples to MCS Management Console  660 -X. The MCS and the MSERV couple to the LAN for communication with other components (not shown) of enterprise network system  600 -X. 
     The MCS of an embodiment includes an “Operating System” along with an “Execution Engine,” some number of “Voice Applications,” and some number of “Mobile Applications.” The Operating System includes for example a Linux kernel with a journaling file system that provides integrity of file system tables and the data structure. The storage on the MCS may be configured as a RAID (Redundant Array of Independent Disks) configuration to provide high reliability access to software and data. The Operating System supports operations of numerous other components of the MCS as described below. 
     With regard to the Operating System, the MCS includes a “Telephony Interface” that couples calls and connects callers and users to/from the MCS. The Telephony Interface couples call information to/from a private branch exchange (“PBX”) (not shown) for example, where the PBX is a component of enterprise network system  600 -X. The Telephony Interface couples to the PBX using a variety of telephony integrations that include one or more of analog, Simplified Message Desk Interface (“SMDI”), T1/E1, Voice over Internet Protocol (“VoIP”), and Digital Set Emulation (“DSE”) signals, but may couple using other signals/signaling protocols. When receiving a call from the PBX, for example, the MCS receives data of an incoming call from the PBX, where the data includes called party information, a reason for transfer of call (e.g., called party line busy, no answer by called party, called party using call forwarding, etc.), and calling parting information (caller ID, etc.). 
     A “Driver” couples information received at the Telephony Interface to the “Telephony Services” component of the MCS. The Driver may perform low level signaling and/or data conversion as appropriate to the received signals. The Telephony Services include one or more components for use in processing the received signals. These components include, for example, voice processing, switching/control, and PBX signaling, but are not limited to these components. 
     The MCS of an embodiment includes at least one “Voice Browser” that, when the MCS receives a call, receives voice information of the call. The Voice Browser controls the use of automatic speech recognition (“ASR”) for speech recognition and DTMF recognition. The Voice Browser of an embodiment couples to a cache or other temporary store that holds voice recordings and/or name grammars (“Voice Recordings/Grammars”) (the name grammars are cached after being generated from names in a user list, as described below). The ASR may use information of the name grammars. Further, the Voice Browser controls the use of text-to-speech (“TTS”) as well as the play of any number of pre-recorded prompts (e.g., WAVE format files). The Voice Browser uses voice extensible markup language (“VXML”) but is not limited to this protocol. Alternative embodiments of the MCS may not include the Voice Browser. As an alternative to a Voice Browser, the MCS may directly communicate with, or use other software or processes, for communication between the voice application and the Telephony Services and/or Driver. 
     The Virtual Machine, Voice Applications, and Execution Engine form a hierarchical state machine framework in which the Virtual Machine runs a number of APIs and modules. Consequently, the Voice Applications can include one component controlling the user interfaces (“UI”) to the MCS, and another component handling lower-level communications with the modules. Use of a loose coupling between the modules and the Voice Browser provided by the state machine framework allows independence between the languages used in the different modules and the Voice Browser. The state machine framework may receive hypertext transport protocol (“HTTP”) requests from the Voice Browser, for example, and generate VXML or Speech Application Language Tags (“SALT”) (SALT extends existing mark-up languages such as hypertext markup language (“HTML”), extensible hypertext markup language (“XHTML”), and extensible markup language (“XML”), and enables multimodal and telephony-enabled access to information, applications, and web services from devices like PCs, telephones, and PDAs for example). 
     The Voice Applications of an embodiment include a number of components including an automatic attendant, a caller interface, a user interface, and a system main menu, but may include other types of voice applications. The automatic attendant is speech enabled, but may be dual tone multi-frequency (“DTMF”)-enabled. The automatic attendant, which can be enabled or disabled, uses information of contact lists (e.g., User List) in the Cache. 
     The Voice Applications also include at least one voice mail application. The voice mail application uses information of the Cache (e.g., User List, Global Address List, Public Folders, Personal Contact Folders) in operations that include sending a new voice mail and/or forwarding a received voice mail. The voice mail application also uses Cache information in support of voice mail networking in which voice mails and corresponding information are exchanged with groupware applications of enterprise network system  600 -X, as described below. 
     The voice mail application couples to the MCS state machine framework described above via one or more application programming interfaces (“API”). The APIs handle the different data formats/types in use by enterprise network system  600 -X (e.g., greeting data, PIN (Personal Identification Number) code data, voice mail message data, system parameters, etc.). Similarly, the Cache also couples to the state machine framework, where the Cache includes one or more of local cache and distributed cache. Therefore, communications among the voice mail application, the Cache, and the MSERV take place via the state machine framework and the APIs as appropriate to the state (e.g., offline, online) of the MSERV. 
     In addition to the Voice Applications, the modules running under the Virtual Machine of an embodiment include Mobile Applications. The Mobile Applications provide access to user information via mobile devices, where the access may include transferring information of email, calendar, and/or contacts to a user&#39;s mobile client device via an electronic message (e.g., SMS, MMS, and/or pager). 
     The MCS also includes an “Administration/Configuration” manager. The Administration/Configuration manager provides access to and control of a unified configuration file of the MCS. The Administration/Configuration manager uses information of the unified configuration file to provide separate Configuration Files to one or more of the components of the MCS as appropriate. The unified configuration file can be copied from the MCS and stored for backup purposes. Additionally, a predefined configuration file may be uploaded to the MCS to provide the appropriate configuration for the MCS. A browser interface to the Administration/Configuration manager allows remote access to the MCS. 
     The MCS also includes a “Self Maintenance Supervisor” or reliability server that monitors MCS components and restarts failed processes when necessary, for example. In addition, the MCS also includes “Security Restrictions” for use in controlling MCS/port security. 
     As described above, the MCS of an embodiment interfaces with the MSERV via the IM. The MCS communicates with the IM via the Groupware Connector for example, but is not so limited. The Groupware Connector of an embodiment includes a “Web Server,” but is not so limited. The MSERV functions as a messaging and collaboration server. The IM is an interface that runs under the MSERV in one embodiment to provide communications and information transfers between components of the MCS and components of the MSERV. In other embodiments, the IM may run under control of the MCS, for example. The IM includes and/or couples with Management Console  660 -X as well as with a diagnostics component (“Diagnostics Component”) and/or a run time component (“RTC”) (not shown). 
     Management Console  660 -X supports access to the MCS by a system administrator of enterprise network system  600 -X for purposes of managing user access. Consequently, Management Console  660 -X allows a system administrator to enable new users with integrated messaging functionality of the ICS and administer and monitor one or more MCSs. 
     The Diagnostics Component of the IM supports on-the-fly diagnostics gathering, computing, and/or compiling of pre-specified diagnostics information or parameters from the MSERV. In this manner the MCS may provide diagnostics information and a user may provide dynamically updateable diagnostics information. 
     The RTC translates communications between components of the MCS and components of the MSERV. As an example the RTC may be used to retrieve user information from the directory service (e.g., Active Directory) of a groupware application in response to a request from the MCS, as described below. Communications between the RTC and components of the MCS use for example XML and Web Services. Communications between the RTC and the MSERV may use one or more APIs of the MSERV (e.g., MAPI, Collaboration Data Objects (“CDO”), Web Distributed Authoring and Versioning (“WebDAV”), etc.). 
     The MSERV of an embodiment represents a messaging and collaboration server. The messaging and collaboration server includes a groupware application that runs on one or more servers and enables users via local client devices to send and/or receive electronic mail and other forms of interactive communication through computer networks. The MCS of an embodiment interoperates with groupware applications that include, but are not limited to, Microsoft Exchange Server, but alternative embodiments may use other types of messaging and collaboration servers. Therefore, the MCS of an embodiment interoperates with client device applications (“client applications”) such as Microsoft Outlook, as well as with other email client applications (e.g., Microsoft Outlook Express). 
     The MSERV sends and receives email messages through what is commonly referred to as a client device such as a personal computer, workstation, or a mobile device including mobile phones or PDAs. The client device typically connects to the LAN, which may include any number and/or combination of servers or mainframe computers where the email mailboxes and public folders are stored. The centralized servers connect to numerous other types of networks (e.g., private or proprietary, and the Internet) to transmit and receive email messages to other email users. Consequently, the MCS uses the MSERV for storing and forwarding email messages in an embodiment. 
     The MSERV also couples to a directory service (not shown), which is a database of information on each user account in the enterprise network system. Access to the directory service may use for example a Lightweight Directory Access Protocol (“LDAP”). 
     With regard to client device access functionality, the MSERV provides integrated collaborative messaging features such as scheduling, contact, and task management capabilities. As an example MSERV configuration, when the MSERV is Microsoft Exchange, the MSERV runs on a version of the Microsoft Windows Server operating system. A version of Microsoft Office Outlook runs on Windows-based local client devices and communicates with the MSERV through the messaging application programming interface (“MAPI”) protocol. The MSERV also accommodates other client device access by supporting one or more of Post Office Protocol 3 (“POP3”) and Internet Message Access Protocol 4 (“IMAP4”) protocols as well as support for Simple Mail Transfer Protocol (“SMTP”). Using this same MSERV configuration example, the MCS of an embodiment, along with Microsoft Outlook Web Access (a service in Microsoft Exchange) accommodates web browser-based access clients, also referred to as thin clients. 
     The MSERV collaboration features support information sharing among users. Collaborative scenarios include maintaining shared address lists that all users can view and edit, scheduling meetings that include people and conference rooms by viewing associated free or busy schedules, the ability to grant other people, such as administrators, access to user mailboxes on behalf of the user. 
     As described above, the IM serves as an interface for the transfer of information between components of the MCS and components of the MSERV. Transferring information includes for example pulling, receiving, retrieving, polling, transmitting, and pushing operations, to name a few. As an example of information transfers between the MCS and the MSERV, the IM pulls information from one or more components of the MSERV and makes the pulled information available to, for example, the MCS Cache. The IM also pushes information from one or more components of the MCS to the MSERV. 
     In serving as an interface between the MCS and the MSERV, the components of the IM (e.g., RTC) translate communications between components of the MCS (e.g., Virtual Machine, Cache, etc.) and components of the MSERV environment. As an example the IM retrieves user information from components of the directory service (e.g., Active Directory) in response to a request from the MCS/Cache. 
     Embodiments of the IM may include one or more of the following components: an RTC, a Management Console, a desktop component, messaging actions control component, Diagnostics Component and/or a message waiting indication component. The desktop component allows the user to configure aspects of the user&#39;s integrated messaging account, such as voice message greetings, extended absence greeting, PIN code data, and presence information. The messaging actions control component receives and responds to user generated requests from the FBUI (defined herein) to take actions such as playing, replaying to and forwarding voice messages, as well as calling the sender of a voice mail message. The message waiting indication component receives events from the user&#39;s message inbox folder and requests corresponding action from the PBX or other aspect of the telephony system, such turning on message waiting indicators on the user&#39;s device(s). The message waiting indication component may send notifications by way of SMS, MMS and/or pager. 
       FIG. 7-X  is a block diagram  700 -X that shows interactions between the IM and components of the MSERV environment  740 -X, under an embodiment. The components of MSERV environment  740 -X include the MSERV and one or more Databases as described above. The Database of an embodiment includes a directory service  742 -X. 
     Directory service  742 -X provides a location for storage of information about network-based entities, such as applications, files, and printers to name a few. Directory service  742 -X also stores information about individuals, also referred to as users, and this information is referred to herein as “User Information.” As such directory service  742 -X provides a consistent way to name, describe, locate, access, manage, and secure information about individual resources in an enterprise network environment. Directory service  742 -X uses the stored information to act as the main switchboard of the enterprise network operating system and is therefore the central authority that manages the identities and brokers the relationships between distributed resources of the enterprise network, thus enabling the resources to work together. Directory service  742 -X of an embodiment may be Microsoft Active Directory (“AD”), but is not so limited. 
     In embodiments including AD, there is a user object stored in an AD Database for each enterprise user. For example, the user object for enterprise USER  2  is shown as USER  2  object  702 -X. The user object includes many fixed attributes such as user name, user phone number, user mailbox location, and user email address. 
     The user object further includes a number of “Custom Attributes.” The number of Custom Attributes is small, for example fifteen, compared to the number of fixed attributes. The Custom Attributes are usable to store information not provided for in the predefined fixed attributes. In one embodiment, a Custom Attribute stores user-specific data that is used by the Voice Applications. Examples of such user-specific data include a class of service (“COS”) for the user, a voice mail extension for the user, whether voice mail is enabled for the user, etc. The data is stored as a data stream in the Custom Attribute with a maximum size of 2048 bytes. In an alternative embodiment, the user-specific data that is used by the Voice Applications is stored as individual data items in fixed attributes by extending AD in a known manner. 
     The user mailbox location fixed attribute indicates where the user&#39;s email mailbox is stored in the enterprise. In some large enterprises, there may be many MSERVs, each including a database storing many user mailboxes. As shown, the mailbox location fixed attribute points to USER  2  mailbox  704 -X on an MSERV called MSERV  1 . 
     User mailbox  704 -X stores email messages sent to the user, as well as outgoing messages and other items, for predetermined periods of time. In an embodiment, the messages can be of at least two types, one of which is a “normal” message that is routinely accessible by the user. Another message type is a “hidden” message that is not routinely accessible by the user through the normal user email interfaces. In an embodiment, a hidden message is used to store data used by the Voice Applications. In contrast to the data stored in the Custom Attribute, however, the data stored in the hidden message can be much larger than the 2048 byte limit of the custom attribute. In one embodiment, among the data stored in the hidden message are audio files stored as attachments to the hidden message, such as a “busy” greeting for the user&#39;s voice mail mailbox, a “no answer” greeting for the user&#39;s voice mail mailbox, and a recorded name for the user&#39;s voice mail mailbox. 
     An example of the MCS accessing the MSERV environment  740 -X through IM  620 -X is a phone caller calling the voice mail mailbox of USER  2  when USER  2  is on the phone. The MCS transmits an action via IM  620 -X with a request to “play busy greeting.” The transmission includes information to access the USER  2  object  702 -X fixed attributes to determine the user&#39;s email mailbox location. In addition the transmission includes information to access the USER  2  object  702 -X Custom Attribute and to transfer the contents of the Custom Attribute to the MCS via IM  620 -X. When the user&#39;s email mailbox is accessed, the hidden message is opened to transfer the appropriate audio file (“busy” greeting in this case) to the MCS for playing over the phone to the caller. In many cases, it may not be necessary to transfer either the Custom Attribute or the audio file from the MSERV environment  740 -X because the current custom attributes and audio file are cached on the MCS. 
     As described above, operations of the Voice Applications and the Virtual Machine couple the Cache and other components of the MCS to components of the MSERV via the IM. As such, the MCS and the IM support the transfer of information between the Cache and backend network components like the MSERV and the database. This configuration provides transparency between the Voice Applications and data stored in the database when using information of the database to support voice mail messaging functions of the MCS, as described below. 
     The information transfers between the Cache and the MSERV along with use of the Custom Attributes and Hidden Messages as described above allow the ICS to overcome the need for an external database to store information stored by a typical voice mail system. This is because the information used by the MCS in providing voice mail message capabilities integrated with the email messaging capabilities of the enterprise network is pulled by the MCS from the MSERV via the IM. The pulling or retrieving may be performed periodically, continually, on demand, and/or in response to particular events (e.g., update of the information in the MSERV) but is not so limited. The information pulled by the MCS includes information of a “Global Address List” (“GAL”), information of one or more “Public Folders,” “Personal Contacts,” and information of a “User List.” 
     The GAL includes information of all users in the enterprise network having access privileges that include the use of email. Public Folders include information of the network enterprise (e.g., contacts, calendars, etc.) that are shared with all users. The Personal Contacts include contact information for each user. 
     The User List includes User Information for a subset of users in the GAL each of whom has access privileged that include the use of the ICS. The User List therefore is a subset of the GAL and is retrieved and/or cached as a separate list or stream in order to improve efficiency of communications and minimize the delays associated with having the MCS search the entire contents of the GAL for information used in executing a user-requested action on a voice mail message. The User List of an embodiment includes one or more of the following parameters corresponding to each user, but is not limited to these parameters: Site identification, mail box number, pronounceable name, office telephone extension, COS, automatic attendant state (e.g., enabled, disabled), voice mail state (e.g., enabled, disabled), Voice User Interface (“VUI”) state (e.g., enabled, disabled), mobile access state (e.g., enabled, disabled), bad logins, locked out, attendant destination, force change of PIN code, mobile gateway identification, full name, first name, last name, user name, home telephone number, office telephone number, cellular telephone number, identification, email address, department, active greeting state, time and date announcement, voice mail notification state (e.g., enabled, disabled), mail box status, PIN code in encrypted or raw form, no answer greeting, busy greeting, extended absence greeting, recorded name, and system greeting. 
     Instead of storing the information pulled from the MSERV in a separate voice mail database as would be done in a typical voice mail system, the pulled information is pushed by the IM to the MCS and held in the Cache. The MCS uses the pulled information in subsequent voice mail message manipulation operations as described below. This pulling and caching of information by the MCS improves the speed and efficiency of voice mail message operations and prevents unnecessary loads on the MSERV resulting from the nearly continuous stream of read requests to the MSERV database in typical messaging systems. 
     The pulling of information from the MSERV by the MCS includes pulling and caching of information including the GAL, Public Folder, and User List. The pulled information is cached by the MCS on a system or non-individual basis because this information applies throughout the enterprise. This information is pulled and cached periodically, for example at 24-hour intervals (e.g., each morning at 2:00 am), or may be loaded on demand, but is not so limited. 
     In contrast the MCS pulls and caches information of the Personal Contacts on a per user basis because this information is different for each user. The Personal Contacts may be requested and cached by the MCS periodically or on demand (e.g., at the time a user logs in to the ICS, in response to modifications of the Personal Contacts, etc.). 
     In operating to provide integrated messaging capabilities, the MCS and the IM function to route a call placed by a caller to a user and, in the event the user is not available, to receive and route a voice mail message left by the caller. The MCS and the IM also function to provide a user with access to voice mail messages using the messaging server of the enterprise email system. The voice mail access supports both online and offline modes of the messaging server. 
     An example of call routing by the MCS, and with further reference to  FIG. 6-X , the MCS receives and detects a call at the Telephony Interface. Data of the call (e.g., called party information, calling party information, reason for call transfer, etc.) invokes the Voice Browser. The Voice Browser transfers a request to the Voice Applications in response to the call data. 
     A Dispatcher component of the Voice Applications routes the call to one or more other Voice Application components in accordance with information of the User List. As an example, the Dispatcher identifies the target user for the call, and determines whether the target user&#39;s automatic attendant is enabled. If the automatic attendant is enabled then the automatic attendant receives the call request and provides the caller with one or more call routing options (e.g., caller selects call routing by selecting and/or saying extension number, selecting and/or saying name, etc.) and routes the call according to the caller&#39;s input. 
     As an example, one or more of the Voice Applications determine an active greeting currently designated by the user for use in responding to calls (e.g., system greeting, no answer greeting, busy greeting, extended absence greeting, etc.), and retrieve the designated active greeting from one of the Cache or MSERV as appropriate to a state of the MSERV. The respective application(s) play the greeting, activate a “record mode” to record the voice mail message of the caller, and provide the caller with additional options available for call and/or message routing (e.g., message marking options, message delivery options, send message, route message to additional users, etc.). Upon completion of the recording and/or selection of a message routing option by the caller, the respective application(s) terminate the call (hangs up) and transfer the recorded voice mail message to one or more locations in the Cache and/or MSERV (e.g., a mail box) that correspond to the user, as described below with reference to  FIGS. 8-X ,  9 -X, and  10 -X. Alternatively, the voice mail message may be transferred before the application terminates the call. 
     As referenced above, the MCS of an embodiment in conjunction with the IM supports availability of and access to the voice mail applications when the MSERV is both “online” and “offline” through the use of the Cache. The MCS of an embodiment includes an “Offline Detector” that monitors an availability state of the MSERV and detects unavailability (“offline condition” or “offline state”) of the MSERV. Upon detecting MSERV unavailability, the MCS transitions to a mode that supports voice mail message recording and retrieval during the MSERV offline condition. 
     Caching of select information received and/or generated in the MCS, including User Information and voice mail information, enhances performance of the enterprise network voice messaging system by reducing the instances of data retrieval from the MSERV. Further, caching of select information improves the reliability of the enterprise network voice messaging system by allowing access to the voice messaging system during periods when the MSERV is offline. 
     Information received at the MCS is routed and held in the Cache in accordance with policies running in the state machine framework and/or the availability state of the MSERV. Examples of information held in the Cache include but are not limited to the User List, Global Address List, information of Public Folders, information of Personal Contact Folders, voice mail message information (both the text description portion and the audio message portion of the voice mail message), greetings, and other user parameters/permissions, and personal information of users (e.g., PIN codes). 
     Regarding actions taken by the MCS following receiving and recording of a voice mail message when the MSERV is online, the MCS generally holds information of the recorded message in the Cache. The MCS may also transfer the recorded voice mail message via the IM to the MSERV where it is stored in the Database. 
     As an example,  FIG. 8-X  is an information flow  800 -X for routing and accessing voice mail messages via the ICS when the MSERV is in an online state, under an embodiment. This information flow  800 -X shows one MCS and one MSERV in an enterprise network environment, but this is shown only as an example and does not limit the network environment to the types, numbers, and/or coupling of components shown as alternative embodiments may have any number of MCSs and/or MSERVs. 
     Information flow  800 -X begins when a caller places a call  802 -X to a user and availability of the user results in the caller leaving a voice mail message (referred to herein as the “VMSG”) for the user. The voice mail message VMSG is received at the MCS and routed  804 C-X to the Cache where it is assigned an identification (referred to herein as the “CACHEID”) and held. The voice mail message VMSG may be held in the Cache for a pre-specified period of time, but the embodiment is not so limited. The voice mail message VMSG and the CACHEID are also routed  804 M-X to the MSERV via the IM, as described above. The MSERV assigns an identification (referred to herein as the “VMSGID”) to the incoming voice mail message VMSG and stores  806 -X the voice mail message VMSG along with the VMSGID and CACHEID in one or more areas of memory (not shown) available to the MSERV. Memory may include any various form of storage or computer-readable memories such as, but not limited to, volatile memory (random access memory (“RAM”), non-volatile memory (read-only memory (“ROM”), EEPROM, disk, and/or other storage devices that may include one or more of magnetic and optical storage media. 
     As described above, the MCS pulls information (e.g., periodically, on demand, etc.) from the MSERV via the IM and uses the pulled information in providing voice mail message capabilities integrated with email messaging capabilities of the enterprise network. Therefore, pulling operations by the IM include pulling of information identifying the stored voice mail message VMSG, where the information identifying the voice mail message VMSG includes but is not limited to the CACHEID. Upon request from the MCS, the IM may pull  808 -X a voice mail list (referred to herein as a “VMLIST”  809 -X), which includes CACHEIDs and VMSGIDs for any stored messages from the MSERV environment. The IM pushes  810 -X VMLIST  809 -X to the MCS where it is held. VMLIST  809 -X may be generated from the user&#39;s inbox upon each request from the IM or may be stored and maintained in the MSERV or in the cache as a current representation of the contents of a user&#39;s voice mailbox, or inbox. If and when a time period for holding a VMSG in the Cache expires, the VMSG is still identifiable from VMLIST  809 , and can be found in the MSERV if requested, using the VMSGID. 
     Information flow  800 -X continues when a user accesses  820 -X the enterprise network system to retrieve his/her voice mail messages. In an embodiment, the user access  820 -X causes the VMLIST to be pulled  808 -X from the MSERV and pushed  810 -X by the IM to the Cache, and also or alternatively to the MCS Upon being provided with access to the MCS, the user selects one or many voice mail message(s) by selecting a VMSGID/CACHEID item from the VMLIST. In response to the user selection, MCS searches  822 -X the Cache for a message, using the Cache identification CACHEID of the selected message. In a scenario in which the message was left by the caller and the time period for holding the message VMSG in the Cache has not expired, the MCS will locate the CACHEID and the message contents VMSG in the Cache. Once located through use of the CACHEID, the MCS retrieves  814 R-X the voice mail message contents VMSG from the Cache, and plays the voice mail message for the user as appropriate to the action selected by the user. 
     In this manner the MCS provides user access to the contents of the voice mail message VMSG via a mapping and without storing voice mail message contents in the MCS. The mapping includes a mapping of voice mail message contents to identification information of the email environment (MSERV environment), and mapping identification information of the email environment to identification information of the voice mail environment (MCS). In this embodiment, therefore, the mapping includes mapping of voice mail message contents to the message identification VMSGID, and mapping of the message identification VMSGID of the email environment to the MCS identification CACHEID. 
     As used herein “pushing” data or information indicates an action of a component or entity that has the affect of transferring the data or information to another component or entity. Transferring includes sending in response to a request, query or command, and sending on the initiative of the transferring component or entity. The transfer may be an internetwork transfer, an intranetwork transfer, or a transfer between a network component or entity and a non-network component or entity. 
     As used herein “pulling” data or information indicates a component or entity receiving transferred data or information. Receiving includes receiving in response to a request, query or command, and retrieving in response to a request, query or command. The transfer may be an inter-network transfer, an intra-network transfer, or a transfer between a network component or entity and a non-network component or entity. 
       FIG. 9-X  is an alternative information flow  900 -X for routing and accessing voice mail messages via the ICS when the MSERV is in an online state, under an embodiment. This alternative information flow  900 -X describes the scenario in which the message VMSG is left by the caller and stored in the cache and in the MSERV environment, and after expiration of the time for holding the message VMSG in the cache. 
     Information flow  900 -X begins when a caller places a call  802 -X to a user and availability of the user results in the caller leaving a voice mail message VMSG for the user. The voice mail message VMSG is received at the MCS and routed  804 C-X to the cache as described above, and the VMSG and CACHEID is routed  804 -X to the MSERV via the IM, also as described above. The MSERV assigns identification VMSGID to the incoming voice mail message VMSG and stores  806 -X the voice mail message VMSG along with the VMSGID in one or more areas of memory (not shown) available to the MSERV. 
     Information flow  900 -X continues when a user accesses  820 -X the enterprise network system to retrieve his/her voice mail messages. VMLIST  809 -X is pulled  808 -X from the MSERV and pushed  810 -X by the IM to the MCS. Upon being provided with access to the MCS, the user selects a voice mail message from VMLIST  809 -X, by selecting a CACHEID/VMSGID item. The MCS searches  822 -X the Cache for the Cache identification CACHEID of the selected message in response to the user selection. Because the message was left by the caller and stored in the MSERV environment and expired in the cache before the user calls in, the MCS will not locate the CACHEID in the Cache. Consequently, the MCS accesses the MSERV, identifies the message VMSG, and pulls  924 R-X the voice mail message contents from the MSERV environment via the IM. The MCS plays the pulled voice mail message VMSG for the user as appropriate to the action selected by the user. 
     In addition to the online scenarios described above, the MCS of an embodiment provides offline behavior that allows for holding, storing, and retrieving voice mail messages when the MSERV is offline or unavailable for some reason, or during times when the connection between the MCS and the MSERV is unreliable. Offline behavior means absence of a coupling between the MSERV and the MCS. Regarding actions taken by the MCS following recording of a voice mail message when the MSERV is offline, a component of the MCS (e.g., Offline Detector) detects the MSERV is offline. The MCS holds the recorded voice mail message in the in response to detecting the MSERV state as offline. At such time as the MCS detects the MSERV is online, the Groupware Connector pulls the voice mail message from the Cache and transfers the recorded voice mail message via the IM to the MSERV where it is stored in the Database. 
     As an example,  FIG. 10-X  is an information flow  1000 -X for routing and accessing voice mail messages via the ICS when the MSERV is in an offline state, under an embodiment. This information flow  1000 -X shows one MCS and one MSERV in an enterprise network environment, but this is shown only as an example and does not limit the network environment to these components as alternative embodiments may have any number of MCSs and/or MSERVs. 
     The information flow  1000 -X begins when a caller places a call  802 -X to a user and availability of the user results in the caller leaving a voice mail message VMSG for the user. The voice mail message VMSG is received at the MCS, however a component of the MCS detects an unavailable or offline condition of the MSERV. In response to detecting the offline condition, the MCS assigns a CACHEID to the incoming message VMSG, and holds  1004 C-X the message contents VMSG along with the CACHEID in the Cache. 
     Information flow  1000 -X continues when a user accesses  820 -X the enterprise network system to retrieve his/her voice mail messages while the MSERV remains in an offline condition. Upon being provided with access to the MCS, the user selects a voice mail message from a list of CACHEIDs generated from the collection of voice mail messages held for him/her in the cache. In response to the user selection, the MCS searches  1022 -X the Cache using the Cache identification CACHEID of the selected message. Upon locating the voice mail message by its CACHEID in the Cache, the MCS pulls  1014 R-X the voice mail message contents from the Cache, and plays the voice mail message for the user as appropriate to the action selected by the user. 
     The MCS continues to monitor the condition of the MSERV. At such time as the MCS detects a return of the MSERV to an online condition, the MCS pulls  1004 P-X the voice mail message VMSG and its CACHEID from the Cache, and transfers  1004 M-X the voice mail message and CACHEID via the IM to the MSERV. The MSERV assigns an identification VMSGID to the incoming voice mail message VMSG and stores  1006 -X the voice mail message VMSG along with the VMSGID and CACHEID in one or more areas of memory as described above. 
     In addition to the capabilities described above, the ICS of an embodiment provides a Form-Based User Interface (“FBUI”). The FBUI is a form-based messaging or communication interface for use by users in retrieving voice mail messages and controlling actions taken on voice mail messages received in the enterprise network system. This FBUI enables a user to retrieve and take various actions on voice mail messages using data of a form (referred to herein as the “FBUI FORM”) that is presented to the user&#39;s client device by the enterprise network email system. Use of the FBUI Form thus provides the user with access to the integrated messaging functions offered by the ICS without a requirement to install or run a dedicated client application on the user&#39;s client device. 
       FIG. 11-X  is a block diagram of a system  11 -X that includes ICS  1100 -X with FBUI  1180 , under an embodiment. System  11 -X includes an enterprise network  1101 -X that provides integrated voice mail and email messaging through the use of ICS  1100 -X. Enterprise network  1101 -X includes a LAN that couples to components of ICS  1100 -X and a messaging server environment  1140 -X. ICS  1100 -X includes MCS  1110  IM  1120 -X, and FBUI  1180 -X, but is not so limited. FBUI  1180 -X is presented to a user (e.g., USER Z) via one or more local devices like PCs or other processor-based devices. 
     Messaging server environment  1140 -X includes the MSERV and a Database  1144 -X, but is not so limited. The LAN couples to any number of other networks  1150 -X and  1160 -X using any of a variety of communication protocols, where the networks  1150 -X and  1160 -X may be of the same or of different types. As an example, the networks may include a public communications network  1150 -X and a private communications network  1160 -X. Private communications network  1160 -X may be a PBX coupled to the LAN of the enterprise network, for example. Networks  1150 -X and  1160 -X allow for information transfers between client devices  11170 -X that are local to enterprise network  1101 -X and client devices  1199 -X that are external to enterprise network  1101 -X. The client devices may alternatively be referred to as “user devices”  1   170 -X and  1199 -X. 
     ICS  1100 -X replaces the voice mail server typically found in enterprise networks with at least one MCS  1110 -X. MCS  1110 -X is coupled to the private communications network (e.g., PBX) of each network enterprise. While one MCS is shown in this example system  11 -X, the enterprise network may include multiple MCSs  1110 -X coupled to enterprise network in an “N+1” configuration, where “N” is any number 1, 2 . . . X. 
     For security reasons, communication to and from the MCS is restricted in an embodiment. The MCS communicates with the IM servers, the private communications network, other MCSs and selected client devices. According to an embodiment of the invention, communications with the MCS may be restricted to network components having particular known addresses. Additionally or alternatively, communications with the MCS may require authentication by passcode or other security measures for certain kinds of access, for example, for access by the administrator. Security may also or alternatively be encrypted and/or provided by requiring a physical connection between the MCS and other component, such as in the case of a connection between an MCS and a private communications network through a direct cable connection. 
     The MCS via the FBUI generally provides a form to a client device from a first server (e.g., messaging server, MSERV, etc.) via a network connection. The form includes data or code that when executed by the receiving client device results in presentation of a FBUI on a display of the client device. The FBUI includes a number of buttons or icons that allow a user to select an action on an item via a second server (e.g., communication server, MCS, etc.), where the item is stored on the first and/or second servers, and the first and second servers are different servers. The FBUI of an embodiment uses a web browser embedded in the form as the means for coupling and/or communicating with a corresponding browser control of the second server. Communications between the client device and the second server thus avoid security and/or other network policy issues that would prohibit the client device from communicating with the second server via the network coupling between the client device and the first server. 
     As described above, the FBUI operates as a form-based messaging interface to transfer a first message (e.g., voice mail message) to a messaging server (e.g., MSERV) from a communication server (e.g., MCS) via a first coupling (e.g., IM). The messaging server generates a second message (e.g., email message) in response to a type of the first message and transfers the second message to a client device via a second coupling (e.g., LAN). The type of the first message is specified by the communication server using properties on the message that identify the message as a “Voice Mail Type” (“VMT”) message. The second message is of a different type and includes data of the first message, but is not so limited. The communication server also transfers to the client device form data that corresponds to the first message. The client device uses the form data to establish a third coupling (e.g., browser link) between the client device and the communication server. The user may direct actions on the first message from the client device via the third coupling using the form data. 
     The ICS of an embodiment provides the FBUI  1180 -X to a user via his/her local client device. The FBUI is provided to the client device through the use of a FBUI Form, where the structure of the FBUI Form conforms to the message structure of the messaging server environment. For example, when the messaging server environment includes the use of Microsoft Exchange and Microsoft Outlook, the FBUI Form is generated to comply with Microsoft formats as appropriate to Exchange and Outlook 
     Information for generation of the FBUI Form is provided to the messaging server environment by the MCS via the IM, and the code used for FBUI Form generation is hosted by the MSERV in an embodiment. The FBUI Form of an embodiment includes code that generates information of the FBUI display as well as the buttons of the display. The FBUI Form further includes an embedded browser control for use in establishing communications between the client device displaying the FBUI Form and a web server (e.g., MCS, IM, other server) for example. The embedded browser control therefore allows the host client device to couple and communicate with a server that is different from the MSERV via a communication channel that is outside the enterprise network LAN. Thus, the FBUI Form enables a communication channel between the local client device currently executing the form and a component like the MCS and/or IM in spite of network policy issues that otherwise might prohibit the client device from communicating outside the enterprise network message infrastructure. 
     Using the FBUI, a user can access/view and take a variety of actions on his/her voice mail messages within an email framework of the host enterprise network system. As an example, when the MCS of an embodiment receives a voice mail message it transfers the voice mail message to the MSERV, as described above. In transferring the voice mail message to the MSERV, the MCS specifies properties on the message that identify the message as a “Voice Mail Type” (“VMT”) message. The message is received and stored by the MSERV as a VMT message using the same storage and retrieval structure as used with other message types like email messages. 
     At such time as a user wishes to access his/her messages via his/her client device, the active message browser of the client device receives the VMT message along with any other mail messages currently stored in his/her electronic mail box. The message browser corresponds to the message structure of the messaging server environment (e.g., Outlook in a Microsoft environment). Upon receipt of the message, the message browser identifies the message as a VMT message. As the code that implements the FBUI Form is stored on the MSERV, implementation of the functionality and/or features associated with the FBUI Form uses communication between the user&#39;s client device and the MSERV via the LAN. For example, the client device message browser requests the FBUI Form from the MSERV in response to identifying a message as a VMT message because this is the form that corresponds to the VMT message type. The MSERV transfers the FBUI Form to the requesting client device, and the client device message browser launches the form in response to the user selecting a VMT message for viewing. 
     The message browser uses data or code of the FBUI Form to display the FBUI on the user&#39;s client device.  FIG. 12-X  is a sample FBUI  1200 -X as displayed on a client device, under an embodiment. The FBUI  1200 -X includes three areas  1202 -X- 1206 -X that present information to a user. The areas include a folder area  1202 -X, a contents area  1204 -X, and a function area  1206 -X, but are not limited to these areas as the UIs of alternative embodiments may present any number and/or type of areas. In alternative embodiments, all three areas  1202 -X- 1206 -X may be presented at the same time, as shown in FBUI  1200 -X, or various subsets of the three areas may be presented at the same time in various combinations. 
     Folder area  1202 -X presents one or more folders to which the user has access via the FBUI  1200 -X and the client device. The “INBOX” may contain a list of voice mail messages in the same listing as other messages, including email messages. Alternatively, the Inbox may include a subfolder (“VOICE MESSAGES”) which includes the voice mail messages, and selection of this folder results in the presentation of voice mail messages of the user&#39;s mail box in the contents area  1204 -X. 
     The contents area  1204 -X generally presents the contents of the folder selected using the folder area  1202 -X. As an example, the contents area  1204 -X presents information corresponding to any number of voice mail messages in the user&#39;s mail box when the INBOX or VOICE MESSAGES folder is selected. Contents area  1204 -X allows the user to select a particular voice mail message by placing a cursor on “VOICE MESSAGE 1 INFORMATION” for example. By (double) clicking a message in the contents area  1204 -X or otherwise indicating to the message browser to display a voice message, a new window (referred to as the “ICS Window”) is displayed. The ICS Window now includes function are  1206 -X. 
     Function area  1206 -X of FBUI  1200 -X presents one or more “voice mail action buttons”  1206 A-X- 1206 E-X (also referred to herein as “buttons”) each of which represents an action the user may select for a voice mail message. In this example, the VOICE MESSAGES folder is selected, and selection of a message in contents area  1204 -X allows the user to take an action on the selected message using buttons  1206 A-X - 1206 E-X. Placing the cursor of contents area  1204 -X on a particular message and choosing an action on the selected message with a button  1206 A-X- 1206 E-X therefore invokes operations on the message via components of the ICS (e.g., MCS, Cache, IM). The buttons  1206 A-X- 1206 E-X of an embodiment include a “Play on Phone” button  1206 A-X, a “Play on Computer” button  1206 B-X, a “Call Sender” button  1206 C-X, a “Reply by Voicemail” button  1206 D-X, and a “Forward by Voicemail” button  1206 E-X, but the embodiment is not limited to this same number of buttons or to buttons offering the same functionality. 
     In other embodiments, presentation of areas or information of the FBUI may vary in many ways. For example, in one embodiment, the action buttons  1206 -X appear after the user has selected (for example by double clicking a particular voice message from the contents area  1204 -X. Action buttons  1206 -X may also appear when the user right clicks on a particular voice message in the contents area  1204 -X. 
     The folder area  1202 -X may also include a subfolder (“VOICE MESSAGE SYSTEM”) under the Public Folder. As such, the VOICE MESSAGE SYSTEM folder may not be considered an actual folder but instead a uniform resource locator (“URL”) that, when selected, sends an HTTP request to a web server and launches/displays an ICS browser inside the client device message browser. The web server may, for example, be a component of the MCS and/or IM, but is not so limited. The ICS browser is an embedded or hidden browser that displays the ICS Window in the area of the client device message browser where emails would typically appear, and the voice mail messages are displayed in the ICS Window. 
     As an example, the ICS Window is displayed in the contents area  1204 -X of an embodiment. The ICS Window may be served from the IM and may contain any information related to the voice messaging system that is user specific. In one embodiment, the ICS Window will display a user login prompt where the user enters the user name and PIN code. Subsequently, the system displays the user&#39;s configuration date, such as PIN code, attendant extension, greeting type, and other applicable information. 
     The hidden browser enables an HTTP link and communications with the IM, for example, which then brokers communications (via HTTP) with the MCS via the MCS Web Server ( FIG. 6-X ) for example. Therefore, while typical messaging servers and LANs use security policies that restrict the use of “special” code in form data, use of the hidden browser embedded in a form structure that is native to the host system overcomes this restriction because the browser is not detected or considered as special code. Use of the hidden browser thus supports communication with the corresponding browser control in the MCS and/or the IM, thereby allowing the integration of voice mail messaging provided by the MCS with the email messaging system of the enterprise network 
     A “voice mail message” in the ICS is generally any message created using a client device generating an audio stream. A “voice mail message” is also any VMT message, such as a message created using the “Reply by Voice Message” and “Forward by Voice Message” buttons of the FBUI. An “email” is any message created using buttons of a host mail message system that function to generate a reply message or to forward a message in response to receipt of a message, even if replying or forwarding a voice mail message. The ICS of an embodiment presents a voice mail message to a user in an email message system using the FBUI as the presentation form. 
     As described above, FBUI  1200 -X allows a user to take action on a voice mail message via buttons  1206 A-X- 1206 E-X of FBUI  1200 -X. Therefore, placing the cursor of contents area  1204 -X on a particular message and choosing an action on the selected message with a button  1206 A-X- 1206 E-X invokes the action on the message via components of the MCS and/or the enterprise network environment. 
     As one example of an action on a voice mail message, and with further reference to  FIG. 11-X , the user may select a “Play on Phone” action using button  1206 A-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. The client device receives a pop-up message from the ICS via the browser link and the ICS Window, where the pop-up message allows the user to choose or enter a telephone number to which he/she would like the selected voice mail message routed. The pop-up message also includes a “connect” button by which the user initiates routing of the selected voice mail message to the selected telephone. In response to selection of the “connect” button, the IM couples with an MCS, and the MCS causes the PBX to initiate a call to the telephone number selected by the user via the pop-up window. Upon connection of the call from the PBX to the selected telephone, the MCS pushes the contents of the voice mail message to the selected telephone. 
     Another example of an action on a voice mail message includes selection of a “Play on Computer” action by the user via button  1206 B-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. In response to selection of the “Play on Computer” button, the IM couples with an MCS, and the MCS pushes a form to the user&#39;s computer that resembles a typical email. The form includes an attachment that is an audio file (e.g., WAVE, MP3, other audio formats, etc.). When the user selects the attachment the client device may launch the default audio player of the client device. 
     Alternatively, selection of the attachment in a “Play on Computer” action may result in the browser form controlling launch of a pre-specified audio player instead of the default audio player. This is similar to the hidden browser described above with reference to presentation of the FBUI. 
     The user may also select a “Call Sender” action on a voice mail message using button  1206 C-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. In response to selection of the “Call Sender” button, the IM couples with an MCS, and the MCS retrieves the selected message from the Cache or the MSERV. Using the caller information from the retrieved message, the MCS causes the PBX to connect the call to the user&#39;s local telephone. Upon connection of the call from the PBX to the user&#39;s telephone, the MCS causes the PBX to initiate a call to the sender&#39;s telephone number as determined from the caller information associated with the voice message. 
     Additionally, the user may select a “Reply by Voice Message” action on a voice mail message using button  1206 D-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. In response to selection of the “Reply by Voice Message” button, the IM couples with an MCS, and the MCS retrieves the selected message from the Cache or the MSERV. The MCS causes a reply message to be generated corresponding to the received message, and prompts the user to record an audio message for the reply. The user records the audio for the reply via a microphone coupled to his/her client device. Alternatively, the user may record the audio for the reply via his/her local telephone. Upon completing the audio reply recording, the MCS causes the reply message to be transmitted to the designated addressees via the MSERV. A user is not required to listen to a message to invoke the “Reply by Voice Message” action. 
     The user may also select a “Forward by Voice Message” action on a voice mail message using button  1206 E-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. The client device receives a pop-up message from the ICS via the browser link, where the pop-up message allows the user to choose or enter a telephone number to which he/she would like the selected voice mail message routed. The pop-up message also includes a “connect” button by which the user initiates routing of the selected voice mail message to the selected telephone. In response to selection of the “connect” button, the IM couples with an MCS, and the MCS causes the PBX to initiate a call to the telephone number selected by the user via the pop-up window. Upon connection of the call from the PBX to the called telephone selected by the user, the MCS pushes the contents of the voice mail message to the called telephone and the user. During the session, and in addition to the contents of the voice mail message, the MCS may provide a verbal prompt to the user requesting information of the party to whom the message is to be forwarded, and/or a prompt to the user to record an audio message to be forwarded along with the forwarded message. A user is not required to listen to a message to invoke the “Forward by Voice Message” action. 
     More generally,  FIG. 13-X  is a block diagram of a system  1300 -X that uses a form-based interface  1380 -X transferred in a first type of message for controlling actions on a second type of message, along with the corresponding information flows, under an embodiment. System  1300 -X generally includes an enterprise network  1301  coupled to one or more public communications networks  1350 -X via a private communication network  1360 -X. Enterprise network  1301 -X includes at least one first server (“Server A”) and at least one interface module  1320 -X, both of which couple to a LAN. Server A also couples to private communication network  1360 -X. In an embodiment, components of Server A and interface module  1320 -X function collectively to form an ICS, as described herein, but are not limited to ICS functionality. 
     System  1300 -X further includes a backend network environment  1340 -X and a user workstation  1370 -X, each of which couple to the LAN. Backend network environment  1340 -X includes at least one server (“Server B”) but may include any number of servers, databases, and/or other components. Components of user workstation  1370 -X also couple to the LAN, the workstation components including a telephone  1370 P-X and a client device  1370 C-X that are local to enterprise network  1301 -X. Server A and interface module  1320 -X cause form-based interface  1380 -X to be displayed to User Z via Server B and client device  1370 C-X. Public communications network  1350 -X and enterprise network  1301 -X allow information transfers between components that are local to enterprise network  1301 -X and client devices  1399 -X that are external to enterprise network  1301 -X. 
     In response to receiving a data stream at an input of private communication network  1360 -X, enterprise network  1301 -X uses the integrated communication processes described herein to cause Server A to generate and transfer a first message to Server B. The first message is transferred to Server B via interface module  1320 -X. Server B generates a second message in response to properties of the first message, and transfers the second message to local client device  1370 C-X via the LAN. The second message is a different type message than the first message and includes information of the first message. In an embodiment, a type of the first message is a voice mail type, and a type of the second message is an email type. 
     Local client device  1370 C-X requests form data from Server B in response to information of the first message, and Server B in turn provides the requested form data to local client device  1370 C-X via the LAN. Local client device  1370 C-X executes the form data resulting in presentation of form-based interface  1380  on a display of user workstation  1370 -X. 
     While local client device  1370 C-X is described as being local to enterprise network  1301 , it is understood that client device  1370 C-X is not required to reside at any particular physical location within enterprise network  1301 -X. For example, “local” client device  1370 C-X may be a tablet PC  1370 C-X from which User Z (who is off site) remotely accesses components of enterprise network  1301 -X (e.g., Server B) via a virtual private network (“VPN”) for example. 
     Upon display on local client device  1370 C-X form-based interface  1380 -X presents a number of soft buttons  1306 -X or action buttons  1306 -X that allow User Z to control actions on data that resides at Server A and/or Server B via communications with interface module  1320 -X and Server A. These actions are controlled via a form browser control embedded in the form data. This form browser control thus allows the local client device (via the form-based interface) to couple to and communicate with Server A via an “Independent Access Channel” (“IAC”) (e.g., browser link) that is independent of the LAN. The coupling between local client device  1370 C-X and Server A is via a corresponding browser control of Server A and interface module  1320 -X but is not so limited. 
     Action buttons  1306 -X of form-based interface  1380 -X enable User Z to control or direct actions on data held and/or stored at Server A and/or Server B. The data may be the first message that was previously transferred to Server B, but is not so limited; this first message may be held at Server A and/or stored at Server B as appropriate to a state (e.g., online, offline) of Server B, as described above. Action buttons  1306 -X of form-based interface  1380 -X enable user control of actions on the data held and/or stored at Server A and/or Server B via the IAC between local client device  1370 C-X, interface module  1320 -X, and Server A. 
     Each of action buttons  1306 -X, when selected by User Z, calls the form data of the form-based interface form as appropriate to the action corresponding to the selected action button  1306 -X. The form data locates the browser control corresponding to the action selected by User Z, and the browser control directs the embedded browser of the form-based interface form to the corresponding URL of interface module  1320 -X and/or Server A. As such, selection of an action button establishes the IAC between local client device  1370 C-X, interface module  1320 -X, and Server A. 
     In response to selection of one or more actions via the action buttons, Server A may transfer status and/or control data (referred to as “status/control data”) to local client device  1370 C-X via the established IAC. Server A of an embodiment transfers the status/control data via interface module  1320 -X, but is not so limited. Execution of the status/control data on local client device  1370 C-X results in the display of popup  1382 -X, where popup  1382 -X is a web browser window that may be smaller than form-based interface window  1380 -X and without some of the standard features such as tool bars. 
     Popup  1382 -X may present User Z with information regarding status of the selected action, prompts to select information via popup  1382 -X, prompts to enter information via one or more fields of popup  1382 -X, and prompts to initiate further actions, but is not limited to presentation of only this information. In response to entry of any additional information into popup  1382 -X in response to queries or prompts and/or selection of any further actions by User Z, local client device  1370 C-X transfers data of the additional information and/or selection to Server A via the established IAC and interface module  1320 -X. 
     In an example in which server actions are controlled via a form-based interface, with continued reference to  FIG. 13-X , Server A generates and transfers a first message to Server B via interface module  1320 -X. Server B in turn generates a second message in response to properties of the first message, and transfers the second message to local client device  1370 C-X via the LAN. Local client device  1370 C-X requests and receives via the LAN form data from Server B in response to information of the first message. Local client device  1370 C-X executes the form data and presents form-based interface  1380 -X on a display of local client device  1370 C-X. 
     Form-based interface  1380 -X, as described above, presents one or more soft action buttons  1306 -X to User Z. Selection of an action button  1306 -X by User Z establishes communication  1306 - 1 -X between local client device  1370 C-X and Server A via the IAC and interface module  1320 -X. Server A determines a location of information needed to fulfill the requested action. If Server A determines the action corresponding to selected action button  1306 -X uses information from backend network environment  1340 -X (e.g., Server B), then Server A directs  1306 - 2 -X interface module  1320 -X to pull  1306 - 2 -X the information from components of the backend network environment as described above, and interface module  1320 -X pushes  1306 - 2 -X the pulled information to Server A. 
     Server A executes the action on the information as appropriate to selected action button  1306 -X. As an example, the action may include establishing communication with  1306 - 3 A-X and/or forwarding the information to an external client device  1399 -X. Establishing communication  1306 - 3 A-X and/or forwarding takes place via a coupling between Server A and external client device  1399 -X that includes one or more of private communication network  1360 -X and public communications network  1350 -X, but is not so limited. 
     As another example, the selected action may include establishing communication with  1306 - 3 B-X and/or forwarding the information to a client device  1370 -X within enterprise network  1301 -X. The client device of enterprise network  1301 -X includes a local user telephone  1370 P-X or client device  1370 C-X, for example, but can include a variety of devices. Establishing communication  1306 - 3 B-X and/or forwarding takes place via a coupling between Server A and local client device  1370 P-X/ 1370 C-X that includes one or more couplings via the LAN, but is not necessarily so limited. 
     In response to selection of one or more actions via the action buttons, Server A may transfer  1310 -SC-X status/control data to local client device  1370 C-X via the established IAC. Server A of an embodiment transfers  1310 -SC-X the status/control data via interface module  1320 -X, but is not so limited. Execution of the status/control data on local client device  1370 C-X results in the display of a popup  1382 -X on a display of local client device  1370 C-X via the form-based interface. Popup  1382 -X presents the status/control data to User Z. In response to entry of any additional information into popup  1382 -X in response to queries or prompts and/or selection of any further actions by User Z, local client device  1370 C-X transfers  1306 - 1 -X data of the additional information and/or selection to Server A via the established IAC and interface module  1320 -X. 
     As generally described above, the form-based interface of an embodiment more specifically includes the FBUI of the ICS. The FBUI operates as a form-based messaging interface to transfer a first message (e.g., voice mail message) to a messaging server (e.g., MSERV) from a communication server (e.g., MCS) via a first coupling (e.g., IM). The messaging server generates a second message (e.g., email message) in response to a type of the first message and transfers the second message to a client device via a second coupling (e.g., LAN). The type of the first message is specified by the communication server using properties on the message that identify the message as a “Voice Mail Type” (“VMT”) message. The second message is of a different type and includes data of the first message, but is not so limited. The communication server also transfers to the client device form data that includes the FBUI Form, where the FBUI Form corresponds to the first message. The client device uses the FBUI Form data to establish a third coupling (e.g., browser link) between the client device and the communication server. The user may direct actions on the first message from the client device via the third coupling using the form data. 
     Referring again to  FIGS. 12-X  and  13 -X, the ICS of an embodiment provides the FBUI to a user via his/her local client device. The FBUI is provided to the client device through the use of a FBUI Form, where the structure of the FBUI Form conforms to the message structure of the messaging server environment. For example, when the messaging server environment includes the use of Microsoft Exchange and Microsoft Outlook, the FBUI Form is generated to comply with Microsoft formats as appropriate to Exchange and Outlook. 
     Information for generation of the FBUI Form is provided to the messaging server environment by the MCS via the IM, and the code used for FBUI Form generation is hosted by the MSERV in an embodiment. The FBUI Form of an embodiment includes code that generates information of the FBUI display as well as the buttons of the display. The FBUI Form further includes an embedded browser control for use in establishing communications between the client device displaying the FBUI Form and a web server (e.g., MCS, IM, other server) for example. The embedded browser control therefore allows the host client device to couple and communicate with a server that is different from the MSERV via a communication channel IAC that is outside the enterprise network LAN. Thus, the FBUI Form enables a communication channel between the local client device currently executing the form and a component like the MCS and/or IM in spite of network policy issues that otherwise prohibit the client device from communicating outside the enterprise network message infrastructure. 
     The FBUI thus allows a user to access, view and take a variety of actions on his/her voice mail messages within an email framework of the host enterprise network system. As an example, when the MCS of an embodiment receives a voice mail message it transfers the voice mail message to the MSERV, as described above. In transferring the voice mail message to the MSERV, the MCS specifies properties on the message that identify the message as a VMT message. The message is received and stored by the MSERV as a VMT message using the same storage and retrieval structure as used with other message types like email messages. 
     At such time as a user wishes to access his/her messages via his/her client device, the active message browser of the client device receives the VMT message along with any other mail messages currently stored in his/her electronic mail box. The message browser corresponds to the message structure of the messaging server environment (e.g., Outlook in a Microsoft environment). Upon receipt of the message, the message browser identifies the message as a VMT message. As the code that implements the FBUI Form is stored on the MSERV, implementation of the functionality and/or features associated with the FBUI Form uses communication between the user&#39;s client device and the MSERV via the LAN. For example, the client device message browser requests the FBUI Form from the MSERV in response to identifying a message as a VMT message because this is the form that corresponds to the VMT message type. The MSERV transfers the FBUI Form to the requesting client device as client-side code, and the client device message browser launches the form in response to the user selecting a VMT message for viewing. 
     As one example of an action on a voice mail message, and with further reference to  FIG. 12-X , the user may select a “Play on Phone” action using button  1206 A-X. In response the user&#39;s client device couples to a component of the ICS (e.g., IM) using the hidden browser of the FBUI. The client device receives a popup message from the ICS via the browser link, where the popup message allows the user to choose or enter a telephone number to which he/she would like the selected voice mail message routed (the MCS may not display the popup window if, during an active Play on Phone session, a user selects a second voice mail message for play). The popup message also includes a “connect” button by which the user initiates routing of the selected voice mail message to the selected telephone. In response to selection of the “connect” button, the IM couples with an MCS, and the MCS causes the PBX to initiate a call to the telephone number selected by the user via the popup window. Upon connection of the call from the PBX to the selected telephone, the MCS pushes the contents of the voice mail message to the selected telephone. 
     In response to selection of one or more actions via the action buttons, ICS components of an embodiment may transfer status/control data in response to actions selected via the action buttons. As described above with reference to  FIG. 13-X , execution of the status/control data on the local client device results in the display of a popup window. The popup is a web browser window that may present a user with information that includes prompts to select information needed by the ICS to complete an action, prompts to enter information needed by the ICS to complete an action, status of a selected action, and prompts to initiate further actions, but is not limited to presentation of only this information. 
     As an example,  FIG. 14-X  is a selection popup  1400 -X, or ICS Window the ICS provides during execution of the Play on Phone action, under an embodiment. The ICS presents selection popup  1400 -X as a means by which a user selects or enters information needed by the ICS to complete an action corresponding to a selected action button. Selection popup  1400 -X of this example (“Voice Message Interface Call Number”) allows the user to choose a telephone number (e.g., “Work Phone”  1402 -X, “Cell Phone”  1404 -X, “Home Phone”  1406 -X) to which he/she would like the selected voice mail message routed. Selection popup  1400 -X also allows the user to enter into a popup field  1408 -X a telephone number to which he/she would like the selected voice mail message routed. Popup message  1400 -X also includes a “Call” button  1410 -X by which the user initiates connection and/or routing of the selected voice mail message to the selected telephone. Selection/entry of a telephone number and activation of “Call” button  1410 -X by the user causes the local client device to transfer the selection/entry to the ICS. 
     As another example,  FIG. 15-X  is a status popup  1500 -X the ICS provides during execution of the Play on Phone action, under an embodiment. The ICS presents status popup  1500 -X to provide the user with status information of the selected action (e.g., “Play on Phone”). Status popup  1500 -X of this example (“Voice Message Call Status”) informs the user that current status  1502 -X of the call to the number previously selected/entered ( FIG. 14-X ) is “Connecting”, but the status may include other status information including but not limited to “dialing”, “line busy”, “unable to complete call”, “no answer”, etc. Any amount or type of status information may be displayed using any number and/or combination of popup windows in alternative embodiments. 
       FIG. 16-X  is another status popup  1600 -X the ICS provides during execution of the Play on Phone action, under an embodiment. The ICS presents status popup  1600 -X to provide the user with status information of the selected action (e.g., “Play on Phone”). Status popup  1600 -X of this example (“Voice Message Call Status”) informs the user that current status  1602 -X of the call to the number previously selected/entered ( FIG. 14-X ) is “Line Busy”. Status popup  1600 -X also includes a “Close” button  1602 -X by which a user terminates presentation of popup  1600 -X. 
     Components of the ICS of an embodiment provide for storage of voice mail messages in an email messaging structure of an enterprise network as described above. The ICS components also provide a form-based interface to a client device via the messaging server. The ICS and form-based interface also provide the user with a system for accessing and directing action on the voice mail messages outside of the communication policies of the enterprise network. The form-based interface also eliminates the requirement for a dedicated client application on the user&#39;s client device. 
     One action the ICS allows on voice mail messages is the Play on Phone action described above. Play on Phone allows a user accessing the enterprise network via a local client device to select a telephone to which voice mail messages can be forwarded. As an example, a user who is away from the office on vacation may access the enterprise network using a portable computer (e.g., via VPN) and use the Play on Phone action of the FBUI to direct his/her voice mail messages to be routed to his/her cellular telephone. In response, components of the enterprise network including the ICS initiate a call to the user&#39;s cellular telephone number, retrieve the selected voice mail messages, and play the messages over the call. 
     The operation of routing voice mail messages to a user-selected device like a telephone during the Play on Phone action includes a number of information transfers among components of the ICS and the host enterprise network.  FIG. 17-X  is an information flow in a system  1700 -X that includes an ICS supporting Play on Phone operations, under an embodiment. System  1700 -X includes an enterprise network  1701 -X coupled to one or more public communications networks  1750 -X via a PBX. Enterprise network  1701 -X includes at least one MCS and at least one IM, both of which couple between the PBX and a messaging and collaboration server MSERV. In an embodiment, components of the MCS and IM function collectively to form the ICS, as described herein, but operation of the MCS and/or IM is not limited to ICS functionality. System  1200  further includes at least one local client device  1770 -X that couples to enterprise network  1701 -X. 
     The MCS and IM operate to cause FBUI  1780 -X to be displayed to User Z via the MSERV and local client device  1770 -X. Public communications network  1750 -X and enterprise network  1701 -X allow information transfers between client devices  1770 -X that are local to enterprise network  1701 -X and client devices  1799 -X that are external to enterprise network  1701 -X. In this example external client device  1799 -X is a cellular telephone of User Z, but is not so limited. 
     The information flow begins when the PBX transfers  1702 -X a data stream to the MCS. The data stream may for example be an audio stream of an incoming call from a caller to User Z. Enterprise network  1701 -X uses processes of the ICS described herein to cause the MCS to generate and transfer  1703 -X a first message to the IM. The first message includes information of the received data stream, and a type of the first message is a voice mail message, but is not so limited. The IM in turn transfers  1704 -X the first message to the MSERV. The MSERV generates a second message in response to properties of the first message, and transfers  1705  the second message to local client device  1770 -X via communications over the enterprise network. The type of the second message is an email message, where the email message includes information of the first message, but is not so limited. 
     Local client device  1770 -X receives the second message and requests  1706 -X form data from the MSERV in response to information of the second message. The MSERV retrieves  1707 -X the requested form data, and transfers  1708 -X the retrieved form data to local client device  1770 -X via the enterprise network. Local client device  1770 -X executes the form data resulting in presentation of FBUI  1780 -X on a display of user workstation  1770 -X. 
     While local client device  1770 -X is described as being local to enterprise network  1701 -X, it is understood that client device  1770 -X is not required to reside at any particular physical location within enterprise network  1701 -X. For example, “local” client device  1770 -X may be a portable PC  1770 -X from which User Z (off site) remotely accesses components of enterprise network  1701 -X (e.g., MSERV) via a VPN. 
     FBUI  1780 -X, as described above, presents one or more soft action buttons  1782 -X to User Z. This example assumes selection of Play on Phone button  1782 -X by User Z. Selection of Play on Phone establishes communication  1710 -X between local client device  1770 -X and the MCS via the IAC and the IM. 
     As an example of establishing communication  1710 , selecting Play on Phone via the FBUI causes the client device local browser to call the function in the form data that corresponds to the Play on Phone operation. The form data when called generates a URL request (code) corresponding to the Play on Phone action, and the URL request expresses the ICS data that is to be transferred to the IM and the MCS. The ICS data of the URL request includes for example a message identification corresponding to the selected voice mail message (for use by the IM/MCS in accessing the voice mail message stored in the MSERV environment), user identification, and identification information of the action desired by User Z (Play on Phone). The URL request subsequently directs the FBUI embedded browser to the specified URL. 
     In response to receiving the URL request via communication  1710 -X from local client device  1770 -X, the MCS determines a location of information (e.g., user information, voice mail message contents, etc.) needed to fulfill the Play on Phone operation. If the MCS determines the Play on Phone uses information from the MSERV environment, then the MCS directs  1703 -X the IM to pull  1712 -X the information from components of the MSERV environment as described above (e.g., directory service), and the IM returns  1703 -X the pulled information to the MCS. 
     In response to selection of Play on Phone, the MCS generates and transfers  1714 -X status/control data (e.g., HTML) to local client device  1770 -X via the IAC. Execution of the status/control data on local client device  1770 -X causes the FBUI embedded browser to display a popup window  1784 . 
     Popup window  1784 -X corresponding to status/control data transfer  1714 -X for example is selection popup  1400 -X described with reference to  FIG. 14-X . This example assumes User Z directs  1716 -X routing of his/her voice mail messages to his/her cellular telephone  1799 -X by selecting “Cell Phone” in popup  1784 -X, but the embodiment is not so limited. The selection of “Cell Phone” along with activation of the “Call” button via popup  1784 -X causes the form data to generate another URL request (code) that is transferred  1716 -X to the IM and the MCS. 
     Upon receiving the URL request with the selected cellular telephone number from local client device  1770 -X, the IM uses the message identification of the selected voice mail message, user identification, and the selected cellular telephone number to transfer a request to the MCS for initiation of the Play on Phone call. 
     The MCS initiates a call to cellular telephone  1799 -X via communications  1702 -X with the PBX. The MCS, which manages call functions of the ICS, initiates the call by directing the PBX to place the call to cellular telephone  1799 -X. The MCS enforces any User Z COS parameters of enterprise network  1701 -X. The call is made via any number of telephony interfaces including T1/E1, DSE, VoIP, and analog, but is not so limited. 
     During the process of initiating  1702 -X the call, the MCS transfers  1718 -X status information of the call (e.g., from the PBX) to local client device  1770 -X. The MCS transfers  1718 -X via the IM the status information using a status message in popup window  1784 -X to provide the user with status information of the Play on Phone call to his/her cellular telephone. An example of status message/popup  1784 -X is described above with reference to  FIG. 15-X . The status information is continually updated during the process of making the call, but is not so limited. 
     When the call to cellular telephone  1799 -X is successfully connected by the PBX, the MCS transfers  1720 -X the selected voice mail messages to cellular telephone  1799 -X. Successful connection of the call causes status message/popup  1784 -X to close. In contrast, when the call is not successfully connected for any reason (e.g., error, line busy, no answer, call not authorized, etc.), then a status message indicating failure of the call is displayed in popup  1784 -X along with the “close” button. 
     An embodiment of the invention is directed to a method of handling voicemail messages in a distributed environment. The environment includes a local voicemail system and a remote voicemail system. An email containing formatting and data adapted for particular features of the local voicemail system is stored in the local voicemail system. The formatting and data is encapsulated such that the formatting and data may be included in an email to be sent over a public network. The formatting and data is encapsulated into an email, and the email is sent with the encapsulated formatting and data to the remote voicemail system. The local and remote voicemail systems are separated by the public network and are in communication by way of an email communication system. The local voicemail system has particular features not generally part of the email communication system, and the remote voicemail system has corresponding features. An email containing the formatting and data adapted for features of the voicemail system is received on the remote voicemail system, and the formatting and data are extracted on the remote voicemail system. An email containing the extracted formatting and data is provided. The email containing the extracted formatting and data is displayed and actions are taken on the email based on the particular features of the voicemail system and the formatting and data in the email. The features may provide access to integrated messaging functions of the voicemail system. 
     According to an embodiment of the invention, the formatting and data are stored in Messaging Application Programming Interface (MAPI) format. According to another embodiment of the invention, the formatting and data are encapsulated in Transport Neutral Encoded Format (TNEF). The email with the encapsulated formatting and data may be sent to the remote system using Simple Mail Transfer Protocol (SMTP). 
     According to an embodiment of the invention, the actions include actions selected from among a set including playing a voice message, replaying to a voice message, forwarding a voice message, and calling the sender of a voice mail message. 
     The method may include resenting a form-based interface on the device of a recipient of the email, wherein the interface provides options to take the actions on the email based on the particular features of the voicemail system. The interface may include inputs that allow the recipient to take actions via a server separate from the recipient&#39;s device on which the recipient views the email. The interface may include buttons for actions particular to voice mail messages. The form may include a web browser, wherein the web browser communicates with a corresponding browser control of the server. The form may comply with format for communication between Outlook and Exchange. 
     The server may comprise a messaging and communication server (MCS) of the remote voicemail system and wherein the email is provided to the recipient via a messaging and communication server (MSERV). 
     Another embodiment of the invention is directed to a method of handling voicemail messages in a distributed environment including a local voicemail system and a remote voicemail system in which a particular decision is made in connection with the routing of the outgoing email. The local and remote voicemail systems are separated by a public network and are in communication by way of an email communication system. The local voicemail system has particular features not generally part of the email communication system. In the local voicemail system, an email is stored containing formatting and data adapted for the particular features of the voicemail system. It is determined whether the remote voicemail system possesses the particular features not generally part of the email communication system corresponding to the local voicemail system features. If the remote voicemail system possesses the particular features, an outgoing email containing the formatting and data adapted for the particular features of the voicemail system is routed, and an outgoing email is sent. 
     According to an embodiment of the invention, if the remote voicemail system possesses the particular features of the local voicemail system, the formatting and data are encapsulated into an email such that the formatting and data may be included in an email to be sent over the public network. The email is sent with the encapsulated formatting and data to the remote system. The formatting and data adapted for features of the voicemail system for the received email are extracted on the remote system. An email is provided containing the formatting and data adapted for the features of the voicemail system, and actions are taken on the email based on the particular features of the voicemail system and the formatting and data in the email. 
     According to another embodiment of the invention, if the remote voicemail system does not possess the particular features which are generally not part of the email communication system corresponding to the local voicemail system features, a simplified version of the email is sent to the remote system with the included audio data. 
     According to an embodiment of the invention, information is retrieved from a DNS lookup to determine whether the remote voicemail system possesses the particular features not generally part of the email communication system corresponding to the local voicemail system features. According to another embodiment of the invention, information is checked in a cache in the local voicemail system to determine whether the remote voicemail system possesses the particular features not generally part of the email communication system corresponding to the local voicemail system features. According to another embodiment of the invention, information is received from web services to determine whether the remote voicemail system possesses the particular features not generally part of the email communication system corresponding to the local voicemail system features. 
     Another embodiment of the invention is directed to a distributed voicemail system. Included in the distributed voicemail system is a local voicemail system and a remote voicemail system. The local and remote voicemail systems are separated by a public network and are in communication by way of an email system. The local voicemail system has particular features not generally part of the email communication system, and the remote voicemail system has corresponding features. The local voicemail system includes resources that store an email containing formatting and data adapted for the particular features of the local voicemail system. The local voicemail system also includes resources that encapsulate the formatting and data such that the formatting and data may be included in an email to be sent over the public network. The encapsulated formatting and data are packaged by resources in the local voicemail system into an email, which is sent to the remote voicemail system. 
     The remote voicemail system includes resources that extract the formatting and data adapted for features of the voicemail system from a received email. Resources in the remote voicemail system provide an email containing the formatting and data adapted for features of the voicemail system and display the email containing the formatting and data adapted for features of the voicemail system. Additional resources take actions on the email based on the particular features of the voicemail system and the formatting and data in the email. 
     Another embodiment of the invention is directed to a method of handling voicemail messages in a distributed environment. A rich format voicemail email is received. The rich format from the voicemail email is encapsulated. The encapsulated rich format data is packaged into an email. The email with the encapsulated rich format data is sent to a remote system. The remote system receives an email containing the encapsulated rich format data. The rich format data is extracted from the received email. A rich format voicemail email is provided from the received email and the extracted rich format data. The rich format email is displayed to a user of the remote system. According to an embodiment of the invention, the rich format contains Messaging Application Programming Interface formatting. According to another embodiment of the invention, the rich format data is encapsulated in Transport Neutral Encoded Format. According to another embodiment of the invention, the email with the encapsulated rich format data is sent to the remote system using Simple Mail Transfer Protocol. According to another embodiment of the invention, the email with encapsulated rich format data is sent to the remote system across the Internet. 
     Another embodiment of the invention is directed to an electronic message. The message includes: an audio stream including a voice message; a header designating a recipient of the message; and formatting and data adapted for particular features of a local voicemail system, the formatting and data encapsulated so that the formatting and data may be included in an email to be sent over a public network and extracted at a remote voicemail system at which actions can be taken based on the particular features of the voicemail system and the formatting and data in the email. 
     The components of the ICS described above include any collection of computing components and devices operating together. The components of the ICS can also be components or subsystems within a larger computer system or network. The ICS components can also be coupled among any number of components (not shown), for example other buses, controllers, memory devices, and data input/output (I/O) devices, in any number of combinations. Further, components of the ICS can be distributed among any number/combination of other processor-based components. 
     Aspects of the ICS described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the ICS include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the ICS may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc. 
     It should be noted that the various functions or processes disclosed herein may be described as data and/or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of components and/or processes under the ICS may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs. 
     Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list. 
     The above description of illustrated embodiments of the ICS is not intended to be exhaustive or to limit the ICS to the precise form disclosed. While specific embodiments of, and examples for, the ICS are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the ICS, as those skilled in the relevant art will recognize. The teachings of the ICS provided herein can be applied to other processing systems and methods, not only for the systems and methods described above. 
     The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the ICS in light of the above detailed description. 
     In general, in the following claims, the terms used should not be construed to limit the ICS to the specific embodiments disclosed in the specification and the claims, but should be construed to include all processing systems that operate under the claims. Accordingly, the ICS is not limited by the disclosure, but instead the scope of the ICS is to be determined entirely by the claims. 
     While certain aspects of the ICS are presented below in certain claim forms, the inventors contemplate the various aspects of the ICS in any number of claim forms. For example, while only one aspect of the ICS is recited as embodied in machine-readable medium, other aspects may likewise be embodied in machine-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the ICS.