Interface for synchronizing automated replies between different messaging systems

Systems and techniques are provided for synchronizing automated reply configuration settings between different messaging services for an individual user of a mobile device. User account information and an authentication key are registered at a server of a first messaging service associated with the mobile device and a second messaging service associated with a client of the second messaging service. In response to a request for access to an automated reply function of the first messaging service from the client of the second messaging service, it is determined whether or not the client is authorized for access based on a comparison of authentication information included in the client's request with the authentication key registered for the mobile device. If the client is authorized successfully, the client is allowed to access the automated reply function in accordance with configuration information specified in the request from the client.

BACKGROUND

In recent years, mobile communication services have expanded and increased in popularity around the world. Many operators of modem mobile communication networks offer their users or subscribers advanced data communication services in addition to the standard wireless mobile communication service for voice calls and mobile messaging services (e.g., text and/or multimedia). Such advanced data services may include, for example, voicemail services enabling the user to record an automated greeting for callers when the user is unable to answer incoming calls directed to the user's mobile device and later, play each caller's recorded voice message. Additionally, such advanced data services may be provided through, for example, a client application program executable at the user's mobile device. The client application program may be provided by the mobile communication network operator via, for example, a virtual store of mobile applications, which the user may select for download and installation to the user's mobile device. For example, the client application program may be an electronic mail (or “e-mail”) application that enables the user to receive copies of e-mail messages associated with one or more e-mail accounts of the user.

However, there is generally very little integration between the data services provided to a user by a mobile communication network operator based on a wireless service account of the user and other data services or functionality provided by other communication service providers based on other communication service accounts of the user. For example, voicemail services may be associated with a wireless service account of the user and may be provided by the wireless carrier or operator of the mobile communication network, whereas e-mail services may be associated with an e-mail account and may be provided by a third-party enterprise that is separate from the wireless carrier and mobile communication network. Further, there may be little or no integration between different client application programs on different computing platforms or devices of the user (e.g., voicemail application at user's mobile device vs. e-mail application at user's desktop or personal computer).

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The systems and techniques disclosed herein enable a user to configure automated reply settings for multiple messaging systems in a communication network environment using a single interface provided at a computing device of the user. In some implementations, the interface may be provided via a client application executable at a desktop or personal computing device of the user or a mobile client application executable at a mobile device (e.g., mobile handset, cellular phone, a tablet computer or the like) of the user. Further, both client applications may be preconfigured by the user so as to synchronize different user-specified options or settings for automated reply messages or notifications across different communication systems related to different messaging services.

In an example, the interface is provided via an electronic mail (or “e-mail”) client application (or plug-in module of the e-mail client) executable at the user's desktop or personal computing device. However, it is noted that a similar interface may be provided via a mobile client application executable at the user's mobile device. In this example, the automated reply messages may be automated out-of-office reply messages, including for e-mail and voice messages, sent or returned by the e-mail and voicemail communication systems, respectively. The automated out-of-office messages may be enabled by the user through, for example, a user option associated with an out-of-office assistant feature of the desktop (or mobile) e-mail client application. The automated reply messages sent/played by the voicemail system may be associated with a subscriber account of the user for cellular, wireless or mobile communication services provided to the user's mobile device by a wireless carrier or operator of a mobile communications network. Further, this mobile communication service provider may be a separate entity from the service provider for e-mail communication services associated with an e-mail account of the user.

In some implementations, the user may configure personalized options for an automated out-of-office reply feature for both incoming emails received at the e-mail messaging system and phone calls delivered to the cellular voicemail system via an interface of an e-mail client executable at the user's desktop computing device. For example, the user may use the interface to enable default or personalized e-mail messages that are automatically sent in response to inbound e-mail messages directed to an e-mail account of the user and received at an e-mail exchange server associated with the e-mail account. Additionally, the user may use the same interface to enable default or personalized recordings automatically delivered or played in response to inbound voice calls directed to a mobile device of the user and received at the voicemail messaging system associated with a mobile account of the user for mobile communication services.

While the example provided herein may be described in the context of voicemail systems for mobile communication services and mobile devices, it is noted that the subject technology is not intended to be limited thereto. Thus, the subject technology may be applied to voicemail systems associated with “landline” telephone services including, for example, Voice-over Internet Protocol (VoIP) services that enable users to use a personal computer or similar computing device to make and receive phone calls over Internet Protocol (IP) networks including the Internet or similar networks. Also, while the examples provided herein may be described in the context of automated out-of-office reply messaging systems (e.g., an “out-of-office assistant”) of e-mail client applications executable at, for example, a desktop computing device of the user, it should be noted that the techniques described herein are not intended to be limited thereto.

Further, while the examples described herein relate to e-mail and voicemail communication systems, it is noted that the subject technology may be used for synchronizing automated reply settings between any user-selectable combination of various communication systems. Examples of such communication systems providing different messaging services to the user may include, but are not limited to, e-mail systems (e.g., including one or more e-mail exchange servers), messaging systems for short messaging service (SMS), enhanced message service (EMS) messages and multimedia message service (MMS), and a voicemail system for voicemail messages (e.g., including one or more voicemail systems associated with one or more phones/lines of a user or subscriber). Hence, the techniques described herein may be applied to other types of message notification systems that may be automated for other types of application programs executable at different types of computing platforms or devices of the user.

The detailed description below uses a number of terms with respect to various system components and operations. Although generally known, use of several of these terms may not be strictly standardized in the art. For the convenience of the reader, the following definitions for some of the relevant terms are presented, as used by way of example in the detailed description below.

The terms “client” and “client application” are used interchangeably herein to refer broadly and inclusively to any program or process configured to consume a functionality offered by an application server (or simply, “server”). For example, a client executing at a computing device of a user may communicate over a communication network to utilize a function of a web application or service hosted at the server. Such a client may be executed at any type of computing device including, for example and without limitation, a desktop computer or workstation, a mobile device, or a host or network device that may operate at other times as a server to other clients. Further, a client can be any type of remote or local process with respect to the computing device executing or hosting the service. Also, a client can be another service.

Similarly, a “server” may be any type of computing device capable of communicating data to one or more clients over the communication network. A server includes, for example, a data communication interface for packet data communication and a central processing unit (CPU), in the form of one or more processors, for executing program instructions. The server platform typically includes an internal communication bus, program storage and data storage for various data files to be processed and/or communicated by the server, although the server often receives programming and data via network communications. The server or server functions may be implemented using, for example, a clustered computing system or server farm in a distributed environment across a number of computing devices having similar platforms (e.g., operating system and other programming). The communication network can include, but is not limited to, the Internet or World Wide Web. The client device and server may use a number of different technologies and communication protocols for transmitting messages or data across the network. Examples of such technologies may include, but are not limited to, Hyper-Text Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP), Service Oriented Architecture, Web 2.0 application features and Lightweight Directory Access Protocol (LDAP). Further, messages transmitted across the network may be formatted using any of various markup, scripting or other programming languages including, for example and without limitation, Hyper-Text Markup Language (HTML), extensible markup language (XML) and JavaScript. With respect to a client accessing the functionality provided by the server, the term “authentication” may be used herein to refer generally to the function of verifying the identity of the particular client for purposes of allowing access to the functionality provided by the application server.

Reference now is made in detail to the examples illustrated in the accompanying drawings and discussed below. An exemplary communication network environment is described initially with respect toFIG. 1. The network environment provides a variety of communication services between different clients and servers, including communications for configuring automated out-of-office (or other personalized) replies for multiple computing platforms or devices simultaneously based on options provided by a user via an interface at a computing device of the user. Following the description of the network environment, network processes related to the interaction between the various elements or systems within the network environment are described with respect toFIGS. 2-5.

FIG. 1illustrates a functional block diagram of an exemplary wireless network environment100for providing mobile voice telephone services and various data services across different communication networks. In the example illustrated inFIG. 1, network environment100includes a mobile communication network130that facilitates communications between a mobile device110and various other devices and systems including, but not limited to, a computing device120, via different types of networks including, but not limited to, a private network132, the Internet134, and a private network136, as will be described in further detail below. As shown inFIG. 1, private network132is associated with the wireless carrier providing data communication services to mobile device110. Network132may be implemented as a local area network, medium area network, and/or wide area network. Similarly, private network136may be a private local, medium-area or wide-area network of, for example, an enterprise or business organization providing various services, including e-mail exchange services for an e-mail account of the user, to computing device120.

Mobile device110can be any type of mobile telecommunication device with at least one processor, a memory, a display and one or more user input devices (e.g., a touch-screen display, microphone, QWERTY keyboard or T9 keypad). Examples of such mobile telecommunication devices include, but are not limited to, portable handsets, smart-phones, tablet computers and personal digital assistants. Computing device120can be any type of personal computing, desktop or workstation device having at least one processor, a network communication interface, a memory, a display, and one or more user input devices (e.g., a mouse, keyboard, etc.).

In this example, mobile device110and computing device120are associated with the same user. For example, third-party private network136may be associated with an enterprise organization or employer of the user, and thus, computing device120may be the user's office workstation computer that executes e-mail client associated with an office or work e-mail account of the user. Further, mobile device110may be a personal (or employer-issued) mobile device that the user can use to retrieve personal and/or work-related e-mail messages via, for example, an interface or mobile e-mail client application executable at mobile device110. In some implementations, mobile device110is configured to execute a client application (or “client”)115and computing device120is configured to execute a client125. As will be described in further detail below, clients115and125each may be configured to provide an interface enabling an individual user associated with both devices to synchronize automated out-of-office settings, including default and personalized settings, for different types of messaging service accounts of the user (e.g., an e-mail account and a wireless service account for voicemail and instant messaging services for sending/receiving text or multimedia content).

While the example inFIG. 1shows only mobile device110, network environment100can be used to facilitate voice and/or data communications for additional computing devices (not shown) over communication network130. Furthermore, the subject technology described herein may be implemented in communication network130using any of a variety of available communication networks and/or on any type of computing device compatible with such a network. As such,FIG. 1is used herein to provide only a very simplified example of a few relevant elements of network environment100and network130, for purposes of discussion and explanation.

Also, for purposes of discussion, mobile communication network130will be described in the context of a network supporting both CDMA and 3rd Generation Partnership Project (3GPP) network technologies including, for example and without limitation, 3GPP type 2 (or 3GPP2) and 3GPP Long Term Evolution (LTE, at times also referred to as 4G). As described above, network130may use separate communication channels and radio access networks for communicating voice and data, respectively, to mobile device110. In an example, the radio access network for data communications is a 3G or 4G data network using 3GPP or 4G LTE technology and the radio access network for voice calls is a CDMA network. Although not shown inFIG. 1, mobile communication network130may include various systems and components for supporting 3G and 4G network data traffic, including an Internet Protocol (IP) Multimedia Subsystem (IMS) for network data traffic using IP and/or other network communication protocols. However, it should be noted that the present techniques are not intended to be limited thereto and may be implemented using other types of mobile communication network technologies that do not provide simultaneous voice and data communications for mobile devices, as described above.

Mobile communication network130provides communications between mobile device110and other mobile devices on mobile communication network130as well as other devices outside of mobile communication network130(e.g., devices on third-party mobile communication networks operated by a different wireless carrier). An inter-carrier or other intermediate network gateway may provide communication connectivity between mobile communication network130and other networks. Mobile communication network130allows a user of mobile device110to initiate and receive telephone calls to and from other mobile device users as well as users of traditional “landline” telephones connected through a public switched telephone network (PSTN).

In some implementations, mobile communication network130includes a number of interconnected access networks for providing voice and data communication services to mobile device subscribers/users. Hence, the overall network130may include a number of radio access networks (RANs), as well as regional ground networks interconnecting a number of RANs and a wide area network (WAN) interconnecting the regional ground networks to core network elements. A regional portion of network130, such as that serving mobile device110will typically include one or more RANs and a regional circuit and/or packet switched network and associated signaling network facilities. Physical elements of a RAN are generally operated by a mobile network operator or wireless carrier of mobile communication network130. Such physical elements include a number of base stations, as represented in the example shown inFIG. 1by a base station (BS)102.

In an example, mobile communication network130offers a variety of communication services including both voice and data services to different user devices. Examples of different data services that may be offered by mobile communication network130include, but are not limited to, over-the-air downloads, web browsing, e-mail and other messaging services. In addition, mobile communication network130may offer voicemail and other voice services via various server systems including, but not limited to, a voicemail (VM) proxy server system (or “VM proxy”)140, a registration server system (or “registrar”)141, a VM system142and other servers or systems associated with mobile communication network130. Examples of such voice services may include, but are not limited to, call answering, caller greeting playback and message recording. Further, mobile communication network130may provide some “traditional” voice services (e.g., traditionally provided through a voice subsystem of network130) as data services (e.g., through a data network subsystem). For example, mobile communication network130may provide a visual voicemail service as a data service including message download and playback functionality involving data communications via a graphical user interface (GUI) at mobile device110. In addition, mobile communication network130facilitates communications for one or more services via the Internet134, including communications with a third-party VM system150. VM system150in this example is associated with another mobile communication network (not shown) operated by a different wireless carrier. Mobile communication network130also facilitates communications between server systems140-142and desktop or workstation device120an e-mail server160or other server(s) associated with a third-party private network136.

Further, VM proxy140is an application server system including a database or local data store communicatively coupled to a registrar141and a VM system142via another network132. Also, network130is operated by a wireless carrier or mobile communication services provider and network132is a private network of the wireless carrier. VM proxy140is configured to communicate with registrar141and VM system142(via network132) based on one or more requests received from devices110and120(e.g., via network130or the Internet134), as will be described in further detail below. Accordingly, VM proxy140functions as a communication interface between mobile device110via mobile communication network130and registrar141and VM system142via private network132. In a further example, VM proxy140also functions as a communication interface between the private network132and devices/systems connected thereto (registrar141and VM system142) and computing device120, e-mail server160and third-party VM system150via Internet134. In this example, third-party VM system150is associated with a different mobile communications network of another wireless carrier or operator. For example, third-party VM system150may be associated with a third-party VM service provider that provides VM services for a different VM account of the same user.

In some implementations, VM proxy140is configured to authenticate or validate the credentials of devices110and120or other devices (not shown) to ensure that the functionality offered by VM proxy140is available only to authorized devices (client applications executing at the respective devices). As such, devices110and120may be authenticated by VM proxy140initially, upon establishing a data connection, in order to verify the client's identity, based on the client-specific information associated with the respective communication request messages from each of devices110and120. In an example, VM proxy140is communicatively coupled to one or more separate physical servers (not shown) including, but not limited to, one or more authentication server(s) as well as one or more database server(s) via network132. Alternatively, the authentication or client validation process may be implemented as an internal authentication program module executable at VM proxy140.

As described above, mobile device110and computing device120are both associated with the same user who, for example, may use each device for different purposes or accessing services from different service providers. In an example, mobile device110is associated with a wireless service account of a user/subscriber for mobile communication services provided by a wireless carrier or operator of communication network130. The services provided by the wireless carrier generally include advanced data services for various applications executable at different users' respective mobile devices. Such an application may include, but is not limited to, an e-mail application for retrieving e-mail messages associated with an e-mail account of the user. Additional services provided by the carrier generally include voicemail services allowing callers to leave voice messages for the user/subscriber, for example, when mobile device110is unavailable to communication network130(e.g., powered off or out of signal range) as well as instant messaging services for sending text messages using SMS and/or messages including image or other multimedia content using MMS.

In an example, an interface may be provided at each of client applications115and125for enabling the user to configure automatic out-of-office reply notification messages to be sent in response to inbound e-mail messages directed to an e-mail service account of the user. Alternatively, client115may be a standalone mobile application that includes an interface for synchronizing user-configured options for automated (e.g., out-of-office) reply messages with e-mail client125via mobile communication network130and that may be configured to communicate with a separate e-mail client application also executable at mobile device110. In this way, user-configured options for automated (e.g., out-of-office) reply messages from an e-mail client application associated with an e-mail account of the user may be used to configure automated reply messages from a voicemail service associated with a voicemail or wireless service account of the user. The capability to configure such options for automated reply messages and also, enable automated reply messages using a single interface (e.g., at e-mail client115or125) can increase efficiency and save time for the user.

The e-mail service for the user's e-mail account in this example may be hosted at an e-mail exchange server160. Accordingly, client115and client125(or “e-mail client125”) may be configured to communicate with e-mail server160to retrieve or request e-mail messages associated with the user's e-mail account via communication network130and one or more other interconnected networks (e.g., networks130,132,136and Internet134), as shown inFIG. 1. As shown inFIG. 1, device120and e-mail client125may communicate with e-mail server160via network136. Additionally, the user may use the same interface to enable default or personalized audio messages or recordings to be automatically delivered or played to callers in response to inbound voice calls directed to mobile device110and received at VM system142.

In some implementations, an interface for synchronizing automated reply settings between different messaging systems (e.g., e-mail server160and VM system142) in network environment100may be implemented as a plug-in module of client125. A similar interface may be implemented for client115. Client115and/or the “plug-in” for e-mail client125may be downloaded to mobile device110and/or computing device120, respectively, via Internet134from an application store or virtual storefront including an online catalog of various applications targeting one or more computing platforms/devices. The application store may be provided by, for example, the operator of communication network130(or “wireless carrier”).

In particular, the plug-in for e-mail client125may be delivered to the user's desktop computer (e.g., computing device120) as part of an installer executable file, which the user can launch for installing the plug-in as a module of e-mail client125already installed on the desktop computer. In some implementations, the installed plug-in module provides a user interface integrated with the existing user interface of e-mail client125. For example, the plug-in may be implemented as a new preference or settings panel in addition to other settings panels of e-mail client125, as shown in the example ofFIG. 2, as will be described in further detail below. Such a preference panel may be similar in appearance to the existing or default user preference panels for configuring various other settings of the e-mail client and provided to the user in a separate window of the e-mail client. Also, like the default or existing settings panels of e-mail client125, the new plug-in preference panel may be accessible to the user via a menu option within e-mail client125.

In some implementations, the installed plug-in of client125may provide user options for configuring client125with authentication and authorization information related to the user's wireless service account associated with mobile device110. As will be described in further detail below in reference toFIG. 3, e-mail client125and mobile device110(or mobile client115at device110) communicate with each other and with VM proxy140as part of a registration process for registering relevant authentication/identification and authorization information related to the user's e-mail account and wireless service and voicemail account. This information may be sent, for example, in the form of an authorization vector data structure or parameter list. The registered information at VM proxy140allows automated “out-of-office” messages or recording to be played for inbound voice calls directed to mobile device110, when out-of-office system (or “out-of-office assistant”) of e-mail client125is engaged (e.g., based on user input at device120).

In an example using the plug-in for e-mail client125, the enhanced client offers a user option to configure e-mail client125to receive registration information, including authorization information for the e-mail and wireless service (or voicemail) accounts of the user, from mobile device110(e.g., via client115). Such an option may be displayed in the above-described plug-in preference panel interface of e-mail client125, for example, as a toggle control element of the interface, e.g., as a checkbox or radio button control of the preference panel.

FIG. 2shows an example user interface of a plug-in preference panel200including different user options for configuring automated reply settings for a voicemail (VM) service account of the user from e-mail client125. As shown inFIG. 2, the plug-in preference panel200in this example includes various user interface controls enabling the user to input additional configuration settings. Such configuration information includes, for example and without limitation, a mobile device number (MDN) or other unique device identifier associated with mobile device110, the user's voicemail account information and information identifying the wireless carrier associated with the user's wireless service or voicemail account and mobile device110. Thus, in addition to a control element202(e.g., checkbox or radio button) for enabling/disabling registration process, preference panel200includes additional user interface controls including, for example and without limitation, text fields204for entering MDN and other relevant account information (e.g., voicemail account password) and a drop-down menu206with preconfigured list of supported wireless carriers.

Also, as shown by the example interface of plug-in panel200, a set of recording options208may be provided for the user to specify a default or custom voicemail greeting to be played for callers. As shown inFIG. 2, recording options208may include, for example, user controls to record one or more custom audio reply messages or greetings. Additionally or alternatively, the interface may enable the user to provide a location of a digital audio file of a previously recorded audio message. The audio file may be stored either locally at the user's computing device (e.g., device120) or at a remote network location. While not shown inFIG. 2, plug-in preference panel200may include additional settings options that the user can use to specify additional configuration information for e-mail client125. Examples of such additional settings options may include, but are not limited to, an authentication key or secret hash password associated with the user's mobile device (e.g., mobile device110ofFIG. 1) as well as the name or network location address of the dynamic name server (DNS) or fully qualified domain name (FQDN) of VM proxy140. Alternatively, information related to VM proxy140may be preconfigured in the interface and may be based on, for example, the wireless carrier selected by the user via the aforementioned list of supported wireless carriers in menu206.

In some implementations, the registered e-mail account and MDN of mobile device110associated with the user in VM proxy140is used (e.g., by the virtual application store or marketplace of the selected carrier) to automatically provide software updates related to the plug-in of e-mail client125or client115, or notifications of such updates (e.g., via e-mail), to computing device120and/or mobile device110. Once the registration process, described in further detail below with respect toFIG. 2, has completed successfully, the registration option of the plug-in interface of client125is automatically reset or disabled and the corresponding toggle option displayed in the plug-in preference panel of e-mail client125is unchecked or deselected. Thus, this option would need to be selected again (e.g., by the user via the plug-in interface) to initiate a new registration process so as to reconfigure the plug-in and e-mail client125for any further events related to any new information that needs to be registered with VM proxy140. For example, a new registration process is initiated to register new information or to register changes to the information previously registered with VM proxy140(e.g., if the user changes to a new or different mobile device, mobile device number or e-mail account).

In addition to the above-described plug-in user interface provided for e-mail client125of personal computing device120, client115is used to provide an interface for the user to configure automated out-of-office reply settings at mobile device110. As described above, client115is a mobile client application program executable at mobile device110. Similar to the above-described plug-in for e-mail client125, client115may be downloaded via communications network130(and Internet134) from an online or virtual store for mobile applications. In an example, client115is a mobile e-mail client application that is configured to communicate with VM proxy140for registering authentication and authorization information, as described above. In this example, client115communicates directly with e-mail server160or other e-mail exchange server to retrieve e-mail messages sent by other users to the user's e-mail account or send e-mail messages to other users via e-mail server160. Thus, client115in this example is used in place of a default e-mail client application program previously installed at mobile device110(e.g., by the device manufacturer or mobile operating system provider). Additionally or alternatively, client115may be implemented as a plug-in for the default e-mail client program of device110, similar to the desktop e-mail client plug-in, as described above.

In a different example, client115is a standalone application executable at mobile device110that is configured to communication with a separate or default mobile e-mail client of mobile device110or with e-mail client125at computing device120via communication network130. In this example, the client115is implemented as a background process or service that communicates with the default e-mail client via an application or other functional layer of a mobile operating system of mobile device110. In a further example, client115is used to provide the automated reply message functionality as described herein at mobile device110, e.g., whether or not it is executable in parallel with the default e-mail client program.

FIG. 3is a flowchart of an exemplary process300for registering authorization information associated with a mobile device and an e-mail client of the user so as to enable synchronization of automated reply settings for e-mail and voicemail communication services associated with respective e-mail and voicemail accounts of the user. By way of example, process300will be described using the component systems/devices of networking environment100ofFIG. 1, as described above. Thus, in the example shown inFIG. 3, the steps of process300implement the above-described registration process for registering relevant authentication and authorization information related to mobile device110(or client115) and e-mail client125with VM proxy140of networking environment100ofFIG. 1, as described above. Thus, while process300is described using mobile device110, e-mail client125and VM proxy140, it should be noted that process300is not intended to be limited thereto and that process300may be used with devices and systems of different networking environments.

As shown inFIG. 3, process300begins at step301, in which a registration request including authorization information in the form of one or more authorization vectors including user account identifiers and authorization information for e-mail and voicemail messaging accounts associated with the user at mobile device110. In the example ofFIG. 3, the user account information for these respective messaging services include an e-mail address of the user and a target MDN associated with the user and mobile device110. The MDN is a unique number assigned to mobile device110by the wireless carrier or operator of mobile communication network130. The MDN is used as a unique identifier by the wireless carrier to provide various communication services, including the automated “out-of-office” reply e-mail and voicemail synchronization service described herein, for the user via mobile device110.

In some implementations, mobile device110is configured to simultaneously send the MDN and e-mail address as part of an authorization vector to VM proxy140, based on input from the user via client115, as described above. In an example, the e-mail address and MDN are provided by the user via an interface of client115at mobile device110. In a different example, client115is configured to automatically retrieve the MDN and e-mail address from device configuration settings previously stored at the mobile device MDN. For example, the e-mail address may be retrieved from e-mail account settings previously stored at an internal memory of mobile device110for a separate e-mail client application executable at mobile device110. If mobile device110has multiple e-mail accounts or e-mail clients, client115provides the user with an option to specify a default account and/or e-mail client or select one from a list provided via an interface of client115. The e-mail address provided by the user in this example may be associated with an e-mail account and services provided by e-mail server160and generally accessible to the user through e-mail client125. As such, the same user may retrieve e-mail messages associated with this account via e-mail client125executable at computing device120.

The authorization vector information sent with the e-mail address and MDN from mobile device110to VM proxy140may include, for example and without limitation, username and password information used to authenticate the user for e-mail and voicemail messaging services, respectively. Alternatively, this information may be provided by e-mail client125based on input from the user via the plug-in interface module installed at e-mail client125, as described above. Further, the authorization vector includes an authentication key generated by mobile device110and used for authentication/authorization purposes when synchronizing automated reply settings between mobile device110(or client115), e-mail client125and VM proxy140. Such an authentication key may be, for example, an encrypted password shared by mobile device110(or client115) with only e-mail client125and VM proxy140for purposes of verifying or authenticating e-mail client125in response to requests from e-mail client125received by mobile device110and/or VM proxy140. In some implementations, the authentication key is in the form of a hash key or password generated by client115using a hash algorithm. Further, as the hash password/key is shared between only client115, e-mail client125and VM proxy140, security is improved by mitigating the potential for any unauthorized access.

If the authorization vector information, e-mail address and MDN have been registered successfully with VM proxy140, an acknowledgement reply indicating successful registration is sent from VM proxy140at step302to mobile device110at step301. Process300then proceeds to step303, which includes registering the authorization vector information, e-mail address and MDN with e-mail client125. If this information is registered successfully, an acknowledgement reply indicating successful registration is sent in step304from e-mail client125to mobile device110(or client115).

Further, once the authorization vector (including the above-described secret hash password), e-mail account and MDN information is registered successfully at VM proxy140and e-mail client125, automated message settings for both e-mail and voicemail messaging services associated with mobile device110can be synchronized between e-mail and voicemail messaging systems. This includes synchronizing settings for automated out-of-office reply settings for both default messages and user-customized messages, as will be described in further detail below with respect toFIGS. 4 and 5, respectively. As described previously, the e-mail plug-in or interface module of e-mail client125is configured to communicate with a voicemail system (e.g., VM system142or third-party VM system150ofFIG. 1) so as to enable an automated “out-of-office” message or recording to be played for inbound callers in response to inbound calls made by these callers to a mobile device (e.g., mobile device110ofFIG. 1) of the user. Furthermore, the automated audio reply is activated automatically when the user enables an out-of-office option (or “out-of-office assistant”) of e-mail client125executable at the user's desktop computing device (e.g., computing device120ofFIG. 1).

FIG. 4is a flowchart of an exemplary process400for synchronizing settings for default automated reply messages between e-mail client125and VM proxy140, following successful registration of authorization and account information (e.g., following the steps of process300ofFIG. 3, as described above). Like process300ofFIG. 3, described above, process400will be described using the component systems/devices of networking environment100ofFIG. 1, as described above. However, process400is not intended to be limited thereto. For example, VM proxy140, registrar141and VM system142may be associated with a private network (e.g., private network132), while e-mail client125may be associated with a different private network (e.g., private network136), as described above with respect to network environment100ofFIG. 1. As such, VM proxy140serves as an interface for communications to and from e-mail client125(e.g., via the Internet134, as shown inFIG. 1and described above) and VM system142and registrar141(via private network132)

As shown inFIG. 4, process400begins in step401, in which the user configures e-mail client125to synchronize default message reply settings when an automated reply feature (e.g., “out-of-office assistant”) of e-mail client125is enabled. While the automated messages in this example are described as out-of-office reply messages, the techniques described herein are not intended to be limited thereto. As will be described in further detail below with respect toFIG. 6, these techniques thus may be applied to any kind of automated message and message settings associated with different messaging services (e.g., EMS, SMS and MMS) for the user. For example, different automated out-of-office responses may be configured for inbound communications directed to a voice or messaging service account of the user based on information related to the identity or location of the calling party or message-sender. This information may be derived from the received inbound communication itself and may include, for example and without limitation, a phone number (or area code), e-mail address or other identifier associated with the particular calling party or sender. In an example, the user may be an enterprise employee who specifies one type of automated response (e.g., message indicating the user is out of the office but will be checking email regularly) for communications (e.g., e-mails or phone calls) determined to be from colleagues or originate from geographic regions corresponding to different office locations, while specifying another type of automated response for communications from private parties or unknown locations (e.g., out-of-office message indicating that the user is unreachable and including an alternate contact for any urgent issues.) As described above, these settings may be configured by the user via the interface of e-mail client125. Further, such settings are used to configure each messaging service to automatically send messages in response to inbound communications directed to each service. Thus, an automated out-of-office e-mail message is sent in response to inbound e-mails directed an e-mail account hosted at an e-mail exchange server (e.g., e-mail server160ofFIG. 1), as described above.

Also, as described above, the user may use the interface of e-mail client125to configure settings to be applied to an automated recording (or greeting) played for callers for inbound voice calls directed to the MDN associated with a mobile device of the user (e.g., mobile device110) and received at a voicemail system (e.g., VM system142) providing voicemail services for the user at the mobile device. Voicemail services are provided by a wireless carrier or operator of a mobile communications network (e.g., network130ofFIG. 1, as described above) in addition to various other communication services. Further, the application of out-of-office settings configured for both received emails (e.g., at e-mail server160) and received voice calls (e.g., at VM system142) may be enabled simultaneously when the user enables an out-of-office setting within the e-mail client.

In step402, e-mail client125sends a request specifying a default message option (as opposed to a customized message option, as will be described below in reference toFIG. 4) to VM proxy140. In addition to an indication of the type of message option, the request from e-mail client125includes authentication information, for example, the authentication key or secret hash password registered previously for the user's mobile device (e.g., from client115of mobile device110, as described above). As noted previously, the registered authentication key or password is stored in association with the MDN of the mobile device in, for example, a local data store accessible to e-mail client125. The hash password in this example was received previously from the device. In a different example, the hash password is provided by the user via an interface of e-mail client125. In some implementations, for increased security, VM proxy140may require additional account authorization information (e.g., username and password information for the user's e-mail and voicemail accounts) from e-mail client125. The account authorization information received from e-mail client125is compared with previously registered information stored in association with the MDN of the mobile device.

In step403, VM proxy140authorizes the request by comparing the information received in the request from e-mail client125with information stored previously for the user's mobile device (e.g., as previously registered in steps201-202of process200ofFIG. 2, as described above). Additionally, VM proxy140determines whether or not the VM system associated with the MDN of the mobile device can be identified or located based on locally stored or cached information available to VM proxy140(e.g., as stored in a local database or storage device coupled to VM proxy140). VM proxy140may not have stored information for the appropriate VM system if, for example and without limitation, this is the first time message settings from e-mail client125are being synchronized or such information is stored by VM proxy for only a temporary duration according to a predetermined time.

In a case where VM proxy140where the VM system is unknown or cannot be identified by VM proxy140, process400proceeds to step404, in which VM proxy140sends a request to registrar141for the identity or location of the appropriate VM system. In response to receiving the request, registrar141identifies the VM system based on, for example, the MDN of the mobile device, as included in the request from VM proxy140. VM proxy140identifies the MDN by, for example, retrieving previously registered information based on the hash password received in step402(e.g., if not provided in the initial request from e-mail client125in step402).

In step405, registrar141provides the requested location, e.g., in the form of an Internet Protocol (IP) address associated with the VM system (VM system142, in this example). For example, registrar141retrieves this location information from a local database storing a mapping between MDNs and corresponding network location or IP addresses associated with VM systems of the same or different wireless carriers. Thus, the location information sent by registrar141in step405may correspond to a third-party voicemail system (e.g., VM system150ofFIG. 1) in a mobile communication network of different wireless carrier than that of VM proxy140. In a further example, registrar141communicates with a remote database or data repository via Internet134in order to identify the location of the appropriate third-party VM system associated with the MDN.

In step406, VM proxy140subscribes to receive updates to the relevant VM system location information from registrar141. As VM proxy140caches the location information of VM system142, subscribing to updates helps to ensure the cached information is accurate and up-to-date for future use. Once the network location (e.g., IP address) of VM system142is known, VM proxy140sends a request to VM system142in step407so as to enable a default out-of-office message to be played for callers in response to calls received at VM system142. Such a default message may be, for example, an automated audio message provided by VM system142.

In step408, VM system142sends a reply message to VM proxy140that includes either an acknowledgement (e.g., “ACK”) that the default message has been enabled successfully, as requested in step407, or a failure notification (e.g., a “NACK”) due to a system error (e.g., the MDN or voicemail account of the subscriber is not active). VM proxy140then sends to e-mail client125either an acknowledgement or failure notification in step409in reply to the initial request from e-mail client125in step402.

In addition to default voice messages, the user may also enable customized audio messages be played by VM system142or third-party VM system150through e-mail client125or plug-in module/interface installed for e-mail client125.FIG. 5is a flowchart of an exemplary process500for synchronizing settings for user-customized out-of-office reply messages between the e-mail client125and voicemail proxy140, as described above and as shown inFIGS. 1,3and4. Many of the steps of process500are similar to that of process300. However, in addition to enabling the “out-of-office assistant” feature of e-mail client125and the automated message setting synchronization service, as described herein, the user in step501may provide a custom audio message to be played as the out-of-office reply message played to callers by VM system142(or third-party VM system150) via the installed plug-in of e-mail client125. As described previously, the plug-in interface may provide an interface for the user to record one or more custom audio messages for this purpose. Additionally or alternatively, the interface may enable the user to provide a location of a digital audio file of a previously recorded audio message. The audio file may be stored either locally at the user's computing device (e.g., device120) or at a remote network location.

In step502, e-mail client125sends the custom audio message, as provided by the user, to VM proxy140. For example, the audio message may be included in the payload of the request along with the hash password registered previously for the user's mobile device, as described above. VM proxy140authorizes the request in step503by comparing the information received in the request from e-mail client125with information stored previously for the user's mobile device. Once authorized, VM proxy140sends a request in step504to registrar141for the network location of the appropriate VM system associated with the user's voicemail or wireless service account, based on the MDN associated with the user's mobile device (e.g., as previously registered with VM proxy140by client115, as described above).

In step505, registrar141provides the requested location, e.g., in the form of an Internet Protocol (IP) address associated with the VM system (VM system142, in this example). As in step306of process300, described above, VM proxy140subscribes to receive updates to the relevant VM system location information from registrar141in step506. In step507, VM proxy140uses the network location received in step506to send a request, including the custom audio message received from the user, to VM system142so as to enable the use of the user-provided custom audio.

In step508, VM system142sends a reply message to VM proxy140that includes either an acknowledgement (e.g., “ACK”) that the default message has been enabled successfully, as requested in step507, or a failure notification (e.g., a “HACK”) due to a system error (e.g., the MDN or voicemail account of the subscriber is not active). VM proxy140then sends to e-mail client125either an acknowledgement or failure notification in step509in reply to the initial request from e-mail client125in step502.

FIG. 6is a flowchart of an exemplary process600for synchronizing default automated reply settings for e-mail and other mobile messaging communication services. By way of example, process600will be described using the component systems/devices of networking environment100ofFIG. 1, as described above. Thus, process600will be described using mobile device110(or client115), e-mail client125and VM proxy140ofFIG. 1, as described above. However, it should be noted that process600is not intended to be limited thereto and that process600may be used with devices and systems of different networking environments. Also, by way of example, process600will be described with respect to process300ofFIG. 3, as described above, but process600is not intended to be limited thereto.

In the example shown inFIG. 6, VM proxy140serves as an interface for communications between e-mail client125and client115. Process600begins at step601, in which the user configures e-mail client125to synchronize default message reply settings for SMS/MMS messages when an automated reply feature (e.g., “out-of-office assistant”) of e-mail client125is enabled. As described above, these settings may be configured by the user via the interface of e-mail client125. Also, as described above, the user may use the interface of e-mail client125to configure settings to be applied with respect to an automated message (e.g., including text and/or image content) sent in response to inbound SMS or MMS messages directed to the MDN associated with mobile device110. The SMS/MMS messages may be sent by other mobile device users. While not shown inFIG. 6, such messages may be routed by a message server or router of the wireless carrier or operator of a mobile communications network (e.g., network130ofFIG. 1, as described above) through the carrier's private internal network to mobile device110. In this example, the application of out-of-office settings configured for both received emails (e.g., at e-mail server160) and inbound SMS/MMS messages may be enabled simultaneously when the user enables an out-of-office setting using e-mail client125.

In step603, VM proxy140authorizes the request by comparing the information received in the request from e-mail client125with information stored previously for the user's mobile device (e.g., as previously received from mobile device110in step301of process300ofFIG. 3, as described above). In step604, VM proxy140sends a request to enable automated SMS/MMS out-of-office replies to mobile device110(e.g., via client115). In step605, mobile device110sends a reply message to VM proxy140that includes either an acknowledgement (e.g., “ACK”) that the default message has been enabled successfully, as requested in step407, or a failure notification (e.g., a “NACK”) due to a system error (e.g., the MDN or voicemail account of the subscriber is not active). Depending on the reply from mobile device110in step604, VM proxy140, in step606, sends to e-mail client125either an acknowledgement or failure notification in reply to the initial request from e-mail client125in step602.

FIG. 7is a high-level functional block diagram of an example mobile device700in which portions of the subject technology may be implemented. In the example ofFIG. 7, mobile device700is in the form of a mobile handset including a touch-screen display. Examples of touch-screen type mobile devices that may be used to implement mobile device700may include, but are not limited to, a smart phone device or tablet computer. However, the structure and operation of the touch-screen type mobile device700, as will be described in further detail below, is provided by way of example, and the subject technology as described herein is not intended to be limited thereto. It should be appreciated that the disclosed subject matter may be implemented using a non-touch screen type mobile or portable device having communication and data processing capabilities, including capabilities to receive and display caller-specific information including image data associated with the caller at the device. Examples of such mobile devices may include, but are not limited to, net-book computers, tablets, notebook computers and the like. For example, the relevant functional elements/aspects of mobile device110ofFIGS. 1,3and6, as described above, may be implemented using the example mobile device700illustrated inFIG. 7.

For purposes of discussion,FIG. 7provides a block diagram illustration of an exemplary mobile device700having a touch-screen user interface. As such, mobile device700can be any smart mobile device (e.g., smart-phone or tablet device). Although possible configured somewhat differently, at least logically, a number of the elements of the exemplary touch-screen type mobile device700are similar to the elements of mobile device700, and are identified by like reference numbers inFIG. 7. For example, the touch-screen type mobile device700includes a microphone702, speaker704and vocoder706, for audio input and output functions, much like in the earlier example. The mobile device700also includes at least one digital transceiver (XCVR)708, for digital wireless communications, although the mobile device700may include an additional digital or analog transceiver. The concepts discussed here encompass embodiments of the mobile device700utilizing any digital transceivers that conform to current or future developed digital wireless communication standards. As in mobile device700, the transceiver708provides two-way wireless communication of information, such as vocoded speech samples and/or digital information, in accordance with the technology of a network, as described above. The transceiver708also sends and receives a variety of signaling messages in support of the various voice and data services provided via the mobile device700and the communication network. Each transceiver708connects through RF send and receive amplifiers (not separately shown) to an antenna710. The transceiver may also support various types of mobile messaging services, such as short message service (SMS), enhanced messaging service (EMS) and/or multimedia messaging service (MMS).

As in the example of mobile device700, a microprocessor712serves as a programmable controller for the mobile device700, in that it controls all operations of the mobile device700in accord with programming that it executes, for all general operations, and for operations involved in the procedure for registering mobile device identifier information (e.g., MDN) and generated hash password or security key for enabling synchronization of automated reply message settings, as described above. Mobile device700includes flash type program memory714, for storage of various program routines and mobile configuration settings including, but not limited to, a client application715for implementing the functionality of the automated or out-of-office reply message synchronization functionality described herein. Client application715may be implemented using, for example, client115ofFIG. 1, as described above. The mobile device700may also include a non-volatile random access memory (RAM)716for a working data processing memory. Of course, other storage devices or configurations may be added to or substituted for those in the example. Hence, as outlined above, the mobile device700includes a processor, and programming stored in the flash memory714configures the processor so that the mobile device is capable of performing various desired functions, including in this case the functions associated with client application715executing on the mobile device, involved in the techniques for providing message synchronization services by the carrier.

In the example shown inFIG. 7, the user input elements for mobile device700include a touch-screen display722(also referred to herein as “display screen722” or simply, “display722”) and a keypad including one or more hardware keys730. For example, the keypad may be implemented as a sliding keyboard of mobile device700and keys730may correspond to the keys of such a keyboard. Alternatively, the hardware keys730(including keyboard) of mobile device700may be replaced by soft keys presented in an appropriate arrangement on the touch-screen display722. The soft keys presented on the touch-screen display722may operate similarly to hardware keys and thus, can be used to invoke the same user interface functions as with the hardware keys.

In general, the touch-screen display722of mobile device700is used to present information (e.g., text, video, graphics or other content) to the user of the mobile device. Touch-screen display722may be, for example and without limitation, a capacitive touch-screen display. In operation, touch-screen display722includes a touch/position sensor726for detecting the occurrence and relative location of user input with respect to the viewable area of the display screen. The user input may be an actual touch of the display device with the user's finger, stylus or similar type of peripheral device used for user input with a touch-screen. Use of such a touch-screen display as part of the user interface enables a user to interact directly with the information presented on the display.

Accordingly, microprocessor712controls display722via a display driver724, to present visible outputs to the device user. The touch sensor726is relatively transparent, so that the user may view the information presented on the display722. Mobile device700may also include a sense circuit228for sensing signals from elements of the touch/position sensor726and detects occurrence and position of each touch of the screen formed by the display722and sensor726. The sense circuit728provides touch position information to the microprocessor712, which can correlate that information to the information currently displayed via the display722, to determine the nature of user input via the screen. The display722and touch sensor726(and possibly one or more keys730, if included) are the physical elements providing the textual and graphical user interface for the mobile device700. The microphone702and speaker704may be used as additional user interface elements, for audio input and output, including with respect to some functions related to the automated picture caller-ID feature for incoming voice calls, as described herein.

In the illustrated example ofFIG. 7, the mobile device700also includes a digital camera740, for capturing still images and/or video clips. Although digital camera740is shown as an integrated camera of mobile device700, it should be noted that digital camera740may be implemented using an external camera device communicatively coupled to mobile device700. The user may, for example, operate one or more keys730or provide input via touch sensor726(e.g., via a soft key displayed via the touch-screen display722) to take a still image, which essentially activates the camera740to create a digital representation of an optical image visible to the image sensor through the lens of the camera. For example, the image may be of the subscriber or user associated with mobile device700, as described previously. The camera740supplies the digital representation of the image to the microprocessor712, which stores the representation as an image file in one of the device memories. The microprocessor712may also process the image file to generate a visible image output as a presentation to the user on the display722, when the user takes the picture or at a later time when the user recalls the picture from device memory. Video images could be similarly processed and displayed. An audio file or the audio associated with a video clip could be decoded by the microprocessor712or the vocoder706, for output to the user as an audible signal via the speaker704.

As shown by the above discussion, some functions relating to synchronization of automated reply message settings for different messaging services may be implemented on a mobile device of a user, as shown by mobile device110ofFIGS. 1,3and6and mobile device700ofFIG. 7, as described above, whereas other functions of the disclosed methodologies may be implemented on computers configured as servers, as shown at140-142,150and160ofFIG. 1, as described above. It should be noted that user device functions are not limited to mobile device implementation and that such functions as well as server functions may be implemented using any general-purpose computing device including, for example and without limitation, a personal desktop computer or workstation device.

A general-purpose computer used for data processing and communications applications typically comprises a central processor or other processing device, an internal communication bus, various types of memory or storage media (RAM, ROM, EEPROM, cache memory, disk drives etc.) for code and data storage, and one or more network interface cards or ports for communication purposes. The software functionalities involve programming, including executable code as well as associated stored data, as described herein. The software code is executable by the general-purpose computer. In operation, the code is stored within the general-purpose computer platform. At other times, however, the software may be stored at other locations and/or transported for loading into the appropriate general-purpose computer system. Execution of such code by a processor of the computer platform enables the platform to implement the methodology for synchronization of automated reply message settings for different messaging services, in essentially the manner performed in the implementations discussed and illustrated herein.

FIGS. 8 and 9provide functional block diagram illustrations of general purpose computer hardware platforms.FIG. 8illustrates a network or host computer platform, as may typically be used to implement a server (e.g., VM proxy140, registrar141and servers of VM systems142and150and e-mail server160ofFIG. 1, as described above).FIG. 9depicts a computer with user interface elements, as may be used to implement a workstation, desktop computing device or personal computer (e.g., computing device120ofFIG. 1, as described above). It is believed that the structure, programming and general operation of such computer equipment and as a result the drawings should be self-explanatory.

A server, for example, includes a data communication interface for packet data communication. The server also includes a central processing unit (CPU), in the form of one or more processors, for executing program instructions. The server platform typically includes an internal communication bus, program storage and data storage for various data files to be processed and/or communicated by the server, although the server often receives programming and data via network communications. The hardware elements, operating systems and programming languages of such servers are conventional in nature. Of course, the server functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.

Hence, aspects of processes300,400,500and600ofFIGS. 3-6, respectively, as described above, may be embodied in programming. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code or process instructions and/or associated data that is stored on or embodied in a type of machine readable medium. “Storage” type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of a service provider into the computer platform of the application or server that will be hosting the service.

Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, unless restricted to “non-transitory” media such as tangible storage media, terms such as “computer” or “machine readable medium” refer to any medium that participates in providing instructions to a processor for execution.

As noted above, the computer as illustrated in the example ofFIG. 9may be used to implement a workstation, desktop or personal computer with user interface elements. For example, such a device may include a display for user input and output. It is believed that the structure, programming, and general operation of such computing equipment and as a result the drawing should be self-explanatory. As shown by the example ofFIG. 9, the computer comprises a central processor or other processing device, an internal communication bus, various types of memory or storage media (RAM, ROM, EEPROM, cache memory, disk drives, etc.) for code and data storage, and one or more network interface cards or ports for communication purposes. Although not shown inFIG. 9, the computer can further comprise various wireless transceiver modules (or components) such as WiFi, IrDA, Bluetooth, etc. The software functionalities involve programming, including executable code, associated stored data, and graphical user interface code for implementing a client application program at the computer. The software code is executable by the processor of the computer. In operation, the code is stored within the computer or within a storage device integrated with or coupled to the computer. At other times, however, the software may be stored at other locations and/or transported for loading into the appropriate computer or storage device thereof. Execution of such code by a processor of the computer enables the computer to implement the methodology for a client (e.g., e-mail client125of FIGS.1and3-6, as described above) for requesting access to one or more functions offered by a service, in essentially the manner performed in the implementation discussed and illustrated herein.

The service can be implemented in a remote computer (or server) on a network. In an example, a user device sends authentication information to the remote server for requesting access to a function of a service hosted at the server; and the remote server processes the request based on the authentication of the user device and returns an appropriate response to the user device over the network. In the example above, the user device operates as a client terminal and the remote computer as a server in a client-server network environment.