Mobile device calls via private branch exchange

TECHNICAL FIELD

0001The invention herein relates generally to communication systems and, in particular, to wireless communication systems.

BACKGROUND

0002Mobile communications in today's real-time enterprise can be challenging. The problem is further complicated by changes in the workplace which have led to a more geographically dispersed and highly mobile workforce. In spite of the popularity of electronic mail (email), large numbers of people and employees still depend upon numerous other types of communications to collaborate with colleagues and drive business success. This is especially true for those in sales, service, operations and management roles who rely upon timely access to and coordination with colleagues as well as other employees, customers, partners and suppliers. Thus, communications remain an essential means of conducting business and staying in contact.

0003As a result of communications being so critical to business today, many professionals and enterprise employees now handle very large numbers of communications each business day. These communications can include disparate types of communications like emails, voicemails, instant messaging to name a few. Managing these large numbers and disparate types of communications consumes large amounts of time during the typical business day. For the growing number of people who spend a significant part of their day away from their offices or in meetings or other events, managing this large number of communications, is highly time-consuming, frustrating and inefficient. Consequently, there is a need for communication systems that provide efficient, timely, and proactive real-time management of multiple types of communications.

0004<patcit id="pcit0001" dnum="US2002075304"><text>US Patent Application Publication No. 2002/075304</text></patcit> discloses a collaboration services suite adapted to support a plurality of integrated telecommunications services accessed by geographically dispersed team members using a virtual team environment (VTE) client that generates a graphical user interface (GUI) for each of the respective team members. Communications sessions are automatically set up by the collaboration services suite in response to request messages generated by the VTE client when a team member initiates a communications session request using the GUI. Team members require no knowledge of another team member's communications device address in order to initiate a communications session. <patcit id="pcit0002" dnum="US2002191595"><text>US Patent Application Publication No. 2002/191595</text></patcit> discloses a softswitch at a network operations center (NOC) which is in data communication with one or more enterprises. The softswitch performs call processing, mobility management, and media connection switching and signaling to provide communications capabilities including basic and enhanced calling features to mobile devices at the enterprises. The softswitch routes control signals for calls between the enterprises and the NOC, but routes call media on the most efficient point-to-point paths between the devices on the calls. <patcit id="pcit0003" dnum="WO03039181A"><text>WO 03/039181</text></patcit> discloses a system for enabling setup and control of conference calls using short message service (SMS) messages (SMs). The SMS messages may be used to set up, or control a scheduled or real-time conference call. The SMS messages can also be used to exercise real-time control over a conference call. Invitations can be sent in real time to add participants to a call in progress, or to transfer the call from any participant's telephone to another telephone connected to the PSTN.

0005The invention is set out in the appended set of claims. The embodiments and/or examples of the following description which are not covered by the appended claims are considered as not being part of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0006<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001"><b>Figure 1</b></figref> is a block diagram of an active mobile collaboration (AMC) system, under an embodiment.</li><li><figref idref="f0002"><b>Figure 2</b></figref> is a block diagram of a communications system that includes an AMC system, under an alternative embodiment.</li><li><figref idref="f0003"><b>Figure 3</b></figref> is a block diagram of a communications system that includes an AMC system, under another alternative embodiment.</li><li><figref idref="f0004"><b>Figure 4</b></figref> is a flow diagram for dial via PBX, under an embodiment.</li><li><figref idref="f0005"><b>Figure 5</b></figref> is a flow diagram for forward dial via PBX, under an embodiment.</li><li><figref idref="f0006"><b>Figure 6</b></figref> is a call flow diagram for forward dial via PBX, under an embodiment.</li><li><figref idref="f0007"><b>Figure 7</b></figref> is a flow diagram for reverse dial via PBX, under an embodiment.</li><li><figref idref="f0008"><b>Figure 8</b></figref> is a call flow diagram for reverse dial via PBX, under an embodiment.</li><li><figref idref="f0009"><b>Figure 9</b></figref> is a detailed call flow diagram for dial via PBX, under an embodiment.</li><li><figref idref="f0010"><b>Figure 10</b></figref> is a call flow diagram for forward dial via PBX using ad-hoc conferencing, under an embodiment.</li><li><figref idref="f0011"><b>Figure 11</b></figref> is a call flow diagram for reverse dial via PBX using ad-hoc conferencing, under an embodiment.</li><li><figref idref="f0012"><b>Figure 12</b></figref> is a block diagram for dial via PBX using class-based call routing, under an embodiment.</li><li><figref idref="f0013"><b>Figure 13</b></figref> is a block diagram of an AMC system, under an alternative embodiment. <figref idref="f0014"><b>Figure 14</b></figref> is a block diagram of an AMC system, under another alternative embodiment.</li><li><figref idref="f0015"><b>Figure 15</b></figref> is a block diagram of an AMC system, under yet another alternative embodiment.</li><li><figref idref="f0016"><b>Figure 16</b></figref> is a block diagram of an AMC system in an enterprise domain, under another alternative embodiment.</li><li><figref idref="f0017"><b>Figure 17</b></figref> is a block diagram of an AMC system in a public domain coupled across components of an enterprise domain, under another alternative embodiment.</li><li><figref idref="f0018"><b>Figure 18</b></figref> is a block diagram of an AMC system in an enterprise domain, under still another alternative embodiment.</li><li><figref idref="f0019"><b>Figure 19</b></figref> is a block diagram of an active mobile collaboration (AMC) system, under an embodiment.</li></ul>

DETAILED DESCRIPTION

0007Communication systems and methods are described that enable mobile devices to route telephone calls via an enterprise telephone system. The communication systems and methods are referred to herein as "dial via PBX." The communication system is configured to receive via a data channel a request from the mobile device. The mobile device, which for example includes a cellular telephone, corresponds to a user making a call. The server receiving the request includes a private branch exchange (PBX) and one or more other servers hosted by or coupled to the enterprise. A first call leg is initiated over a first voice channel in response to the request. The first call leg is coupled to the server and mobile device. A second call leg is initiated over a second voice channel, and the second call leg is coupled to the server and a client device corresponding to an intended call recipient. The client device includes, for example, a telephone or other communication device coupled to a communication network and accessible via a telephone number. A voice conference call is formed between the mobile device and client device by joining the first and second call legs. The voice channel and/or the data channel as described herein is hosted by an enterprise, a service provider, and/or a mobile network operator.

0008The dial via PBX of an embodiment reduces costs of telephone calls (e.g., long distance, international, etc.) made from mobile devices like cellular telephones by leveraging an enterprise telephone system. To reduce costs, AMC users may route long distance and/or international telephone calls made from their mobile devices via the enterprise PBX with which the users are associated. This telephone call routing via the enterprise PBX, enables a user to leverage the PBX to bypass international toll charges from the cellular telephone. The dial via PBX thus reduces the cost of telephone usage by using the data channel of the mobile device for signaling while using the cellular voice channel for audio. The client and facilitator of the AMC system are configured to couple with the enterprise PBX to provide the dial via PBX functionality as described in detail below.

0009The dial via PBX, by allowing users to make telephone calls using an enterprise PBX infrastructure, allows users and enterprises to reduce costs by leveraging the enterprise voice gateways and wide are network (WAN) trunks. Furthermore, the user can dial telephone calls using short code dialing (e.g., dialing only an extension number). Additionally, the dial via PBX provides the user with the ability to hide his/her personal caller identification (ID) because the calls initiated via the enterprise PBX infrastructure carry the caller ID of the PBX.

0010In the following description, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the communications systems. 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.

0011The communication systems described herein use loosely-coupled client-server architectures to improve the efficiency of multiple types of communications. The communication systems, referred to herein as the active mobile collaboration (AMC) system, include a client application and a facilitator application. The client application, also referred to as the client or AMC client, is a component application of a variety of processor-based mobile communication devices and telephones.

0012The facilitator application of an embodiment, also referred to as the facilitator or AMC facilitator, is an application hosted on one or more servers or other processor-based devices. The facilitator communicates with a portable or mobile communications device via one or more couplings and the client hosted on the communications device. The facilitator communicates with the AMC client of a host portable device via a network coupling for example. The facilitator of alternative embodiments can be distributed among one or more portable processor-based devices including the same communication devices as the client application.

0013The components of the AMC system function to improve efficiency of communications by allowing communication device users to increase accessibility of enterprise and personal contact information from mobile phones and other personal digital assistants (PDAs), as well as enabling users to leverage their enterprise telephone system (e.g., enterprise PBX) by routing telephone calls from their mobile devices through their enterprise PBX in order to bypass long distance toll charges to the cellular telephone. Furthermore, the AMC systems allows users to dynamically manage how and when mobile communications take place, intelligently screen messages, regardless of message type, based on identity of a messaging party, urgency, and subject matter, and determine which contacts in a directory are available to talk and which ones choose not to be disturbed, to name a few.

0014<figref idref="f0001"><b>Figure 1</b></figref> is a block diagram of an active mobile collaboration (AMC) system 100, under an embodiment. The AMC system 100 includes any number X(n) of communication devices 101 coupled for communication via one or more facilitators 102 and one or more couplings 104. One or more of the communication devices 101 include an AMC client application. Likewise, the facilitator 102, also referred to herein as the AMC server 102, includes a facilitator application. The AMC client and facilitator function to allow users of the communication devices to dynamically manage how, when, and with whom mobile calls take place, intelligently screen calls based on caller identity, urgency, and subject matter, determine which contacts in a directory are available to talk and which ones choose not to be disturbed, and increase accessibility of enterprise and personal information (e.g., voicemail, contacts, calendars, etc.) from mobile phones. The AMC system 100 of an embodiment also includes couplings with one or more portals 106 and/or one or more databases 108, but is not so limited.

0015The communication devices 101 and facilitators 102 described herein are processor-based components running or hosting numerous applications or programs. As such, the communication devices 101 and facilitators 102 can include one or more processors (not shown) coupled among any number/combination of components (not shown) known in the art, for example buses, controllers, memory devices, and data input/output (I/O) devices, in any number of combinations.

0016The communication devices 101 described herein include processor-based electronic devices, for example, cellular telephones, personal computers, portable computing devices, portable telephones, non-portable telephones, portable communication devices, subscriber devices or units, PDAs, mobile devices, wireless devices, wireline devices, voice over Internet Protocol (VOIP) devices, private branch exchange (PBX) devices, soft clients, desktop clients, telephones coupled to an enterprise telephone system, and telephones coupled to a central exchange (centrex) that provides telephone services to an enterprise, to name a few. The communication devices 101, also referred to as target devices, handsets, client devices, mobile devices, mobile communication devices, and portable communication devices, can include all such devices and equivalents, and are not limited to the communication devices described above.

0017As described above, the AMC clients are hosted on or run on communication devices 101 or handsets. The AMC client is an application that runs under control of processors on a variety of off-the-shelf mobile devices and telephones, for example, supporting open application environments such as the Symbian OS™, QUALCOMM's Binary Runtime Environment for Wireless (BREW™), as well as other application environments available from Palm, Microsoft, and Sun Microsystems, but is not so limited. Users or subscribers can download and deploy the AMC client over the air and/or over wired connections; further, the AMC client can be pre-loaded in the memory of the host device, or displayed as a thin client (e.g., browser or web client).

0018The couplings 104 include wired couplings, wireless couplings, and hybrid wired/wireless couplings, but are not so limited. Furthermore, the couplings 104 can include various networks and/or network components (not shown) of a communication service provider or carrier, but are not so limited. The network and corresponding network components, when present in the couplings 104, can be any of a number of network types known in the art including, but not limited to, local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, backend networks, and the Internet. The coupling may be via a number of protocols including but not limited to Hypertext Transport Protocol (HTTP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Session Initiation Protocol (SIP), and Wireless Application Protocol (WAP). Furthermore, the coupling may be via a number of messaging standards including but not limited to Multimedia Messaging Service (MMS), Short Message Service (SMS), and Enhanced Messaging Service (EMS).

0019<figref idref="f0002"><b>Figure 2</b></figref> is a block diagram of a communications system 200 that includes an AMC system, under an embodiment. The AMC system includes a facilitator 202 and a client 222 as described elsewhere herein. The facilitator 202 can be one or more facilitators that form a facilitator server cluster 204 and/or database cluster 206 within the enterprise 200E that are resident behind the enterprise firewall 200F, but the AMC system is not so limited. The host enterprise 200E also includes numerous other components, for example, corporate directories and servers 250, authentication servers 252, and enterprise management consoles 254 to name a few. The facilitator 202 is an integrated component of the host enterprise 200E and as such integrates with one or more components of the enterprise 200E. For example, couplings between the facilitator 202 and messaging and collaboration servers (e.g. Microsoft® Exchange) and/or corporate or other directories of the enterprise 200E allow easy, over-the-air download of personal and corporate contact information to devices, as well as searching of personal and corporate contact directories from the device. Other information of the enterprise 200E can also be delivered to the devices using the AMC system, information including but not limited to calendar information, calendar alerts, calendar reminders, etc.

0020The facilitator 202 couples to a client device or device of one or more users via one or more network couplings. The facilitator 202 couples to one or more devices using one or more service provider networks 200S, as an example. In this example configuration, the facilitator 202 couples to one or more service provider networks or infrastructures 200S via network couplings 230 (e.g. Internet), and then couples to devices 200M via the respective service provider networks 232. The AMC system protects data transfers between the facilitators 202 and the devices 200M using secure couplings, for example, protected with end-to-end security protocols like Secure Sockets Layer (SSL) or Transport Layer Security TLS cryptographic protocols.

0021The devices 200M of an embodiment include the AMC client 222. The AMC client 222, also referred to as the client 222, includes a graphical user interface 224 that integrates with the device applications and allows users to receive and scan enterprise information of the enterprise 200E. The enterprise information includes voicemail information (e.g., voicemail messages), contact information, directory information, calendar information, alerts that can include calendar reminders, conference notifications and call requests from colleagues, as described herein and in the Related Applications. Call requests include relevant details such as name, urgency, and subject matter to help users move business forward while screening out unwanted interruptions. The client 222 further provides a presence-aware phonebook that lets users find a contact and determine if the contact is available to talk, even before placing a call. The client 222 eliminates the need to manually enter contacts into the host device 200M. Instead, users download personal and/or corporate contact information over-the-air to their devices. The facilitator 202 and client 222 of the AMC system therefore provide automated, two-way synchronization to ensure contacts are backed up and up to date at the enterprise 200E.

0022An example of the AMC system of an embodiment is available as the Orative Enterprise Software from Orative Corporation of San Jose, California. The facilitator is available as the Orative Enterprise Server (e.g. runs on a standards-based, Java 2, Enterprise Edition (J2EE) platform that operates securely behind the enterprise firewall). The client is available as the Orative Client Software (e.g. runs on a variety of popular mobile devices, and leverages the latest application development environments including Symbian OS, Java and BREW to name a few).

0023Components of the AMC system generally include intra-domain and inter-domain routers. These routers serve to route messages between AMC clients and facilitators, between different facilitators, or a specific functional module within a facilitator. The routers operate in an incoming mode and an outgoing mode. In the incoming mode (caller is the client interface layer) the routers receive commands from AMC clients and route them to a functional module based on the message type. In the incoming mode therefore the router acts like a simple router; it examines the message type and routes it to the appropriate functional module of a facilitator.

0024In the outgoing mode (caller is a server functional module) the routers receive outgoing commands and route them to either an AMC device, to another facilitator within the domain, or to another domain. The router uses the target username/domain pair of the message to determine the target server where: if the target domain is the same as its facilitator's domain, the router looks up the home facilitator of the target in a (database) table and assigns this value as the destination facilitator; and if the target domain is different from its facilitator's domain, the router assigns the value "amc.<domain name>" as the name of the destination facilitator.

0025There is always a destination facilitator for a message, even if the session of the message's target user has expired. The message is always routed to the user's home facilitator. If the home facilitator has failed, the message is instead routed to the user's backup facilitator. The assumption is that foreign domains don't have a single point of failure and can always receive the message.

0026If the destination facilitator is the originating facilitator, this indicates the message needs to be routed to one or more destination clients. The set of active destination devices for this user is found in a database table map (key is username and active flag; value is a set of destination device unique identifiers). A device is uniquely identified by a device ID and DNS name/Internet Protocol (IP) address and port pair or phone number and carrier pair. The message is then placed in the user's queue and the rate controller per each active destination device is notified of the event.

0027In case of facilitator-to-facilitator routing, the message is placed in the facilitator's queue and the target facilitator's rate controller is signaled with the event. Facilitator-to-domain routing is identical to facilitator-to-facilitator routing.

0028Authentication ascertains the user identity for AMC client-facilitator and portal-facilitator communications and the server identity for facilitator-facilitator communication. User authentication of an embodiment is performed via an API of the facilitator, where the API supports many forms of authentication including basic username/password mechanisms to more complex challenge/response mechanisms, but the embodiment is not so limited.

0029While dynamically managing how and when mobile calls take place and intelligently screening calls based on numerous factors described above, the components of the AMC system also improve efficiency of voice communications by increasing accessibility of enterprise and personal contact information from mobile phones. Components of the AMC system of an embodiment support aggregation and management of contact information from various sources including, but not limited to, directories resident on desktop computers, corporate/enterprise directories, and contact information of the mobile device native phonebook, and provide data coupling between those sources and mobile devices hosting the AMC client, as described herein and in the Related Applications. This contact information is managed by providing the user with access via the mobile device to dynamically integrated contacts of a contact list and a number of phonebooks from multiple sources. The dynamic integration of multiple disparate directories provided by the AMC system of an embodiment allows a user to indicate the contacts he/she desires among all directories of a corresponding enterprise server, and then dynamically synchronizes all enterprise directories so as to place the desired information from the directories together into a common AMC phonebook. The integrated contact information available to the user is used in generating and routing call requests of the call notification described in detail below.

0030<figref idref="f0003"><b>Figure 3</b></figref> is a block diagram of a communications system 300 that includes an AMC system, under an embodiment. The communications system 300 includes enterprise components, with which the AMC system is integrated, coupled to client devices via a communication or network infrastructure. The enterprise components include, but are not limited to, one or more of a corporate directory, Personal Information Manager (PIM) server, presence server, Private Branch Exchange (PBX) server, management console, and voicemail system (e.g., voicemail servers), to name a few.

0031The AMC system includes a facilitator as described herein. The facilitator includes an adapter or adapter framework by which the facilitator simultaneously integrates with components of the enterprise and enterprise servers. The facilitator uses an adapter for each enterprise component to which it integrates. The adapter of an embodiment is a protocol-specific adapter for each enterprise component to which it integrates; alternatively, the adapter includes vendor-specific adapters. The facilitator integrates with multiple components simultaneously. The AMC adapters convert the data from the enterprise components (e.g. external) into a common data structure.

0032The facilitator includes one or more applications that support multiple functions provided by the AMC system. The AMC system functions include integrated access to enterprise voicemail as described here and, additionally, text messaging, pre-call management, appointments and contacts, notifications, availability (presence), voicemail, and PBX remote control as described herein and in the Related Applications.

0033The facilitator couples to a client device of one or more users via one or more network couplings or infrastructures. As an example, the facilitator couples to a mobile network using a coupling with another communications network (e.g. Internet). The mobile network or mobile infrastructure, which includes one or more service provider networks associated with respective ones of the client devices, provides a coupling to individual client devices.

0034Communications between the facilitator and the client device are controlled by the facilitator using one or more components and applications. The functions provided by the facilitator in controlling communications include one or more of rate control, synchronization (sync), call signaling, data transfer, over the air (OTA) provisioning, and device management to name a few. Optionally, the communications path between the facilitator and the communications network includes an AMC proxy server.

0035A protocol used between the client and the facilitator can be different from protocols used between other components of the AMC system and/or enterprise. More particularly, the protocol used between the client and the facilitator may not be the same as the protocol used between facilitator and PBX server. For example, the client to facilitator protocol may include session initiation protocol (SIP) or sync messages, while the facilitator to PBX protocol may include SIP, HTTP, or web services in which the facilitator acts as gateway.

0036As described above, AMC users may route telephone calls made from their mobile devices via the enterprise PBX with which the users are associated. This telephone call routing under the dial via PBX of an embodiment enables users to leverage the PBX to bypass international toll charges to their cellular telephones. The client and facilitator of the AMC system are configured to couple with the enterprise PBX to provide the dial via PBX functionality as described in detail below.

0037In the descriptions herein, the mobile device corresponds to a caller initiating or originating a call. Furthermore, a client device reachable via a telephone number corresponds to an intended recipient or recipient of the call.

0038Generally, <figref idref="f0004"><b>Figure 4</b></figref> is a flow diagram for dial via PBX 400, under an embodiment. The mobile device under the dial via PBX 400 first sends a dial-via-PBX request via a data channel, and the dial-via-PBX request is received 402 at a server of the enterprise. The mobile device corresponds to a caller attempting to reach an intended call recipient. The server can be a component of the enterprise and/or coupled to the enterprise. For example, the server includes one or more of the facilitator and a PBX server (alternatively referred to as a telephone server) hosted by the enterprise with which the caller is affiliated. A first call leg is initiated 404 between the server, on behalf of the user from his enterprise landline telephone number, and the mobile device and its telephone number in response to the request. The first call leg includes an outbound call leg from the mobile device to the server or an outbound call leg from the server to the mobile device, as described in detail below. A first voice channel hosts the first call leg. A second call leg is initiated 406 between the server, on behalf of the user from his enterprise landline telephone number, and the recipient's client device or telephone in response to the request, and a second voice channel hosts the second call leg. The telephone corresponds to the intended call recipient. The server forms 408 a voice call between the mobile device (caller) and the telephone (call recipient) by joining the first call leg and the second call leg.

0039The AMC system of an embodiment provides dial via PBX through use of a "forward" dial via PBX that includes an outbound call leg from the mobile device of the call originator to the PBX. The call recipient is connected using an outbound call leg from the PBX to the recipient's telephone line. The forward dial via PBX provides a more natural user experience but may not be optimal if the call originator is roaming or if the call from the mobile device to the PBX is expensive and can be reduced via toll bypass options.

0040<figref idref="f0005"><b>Figure 5</b></figref> is a flow diagram for forward dial via PBX 500, under an embodiment. The AMC client of the mobile device under the forward dial via PBX 500 initiates the transfer or transmittal of a dial-via-PBX request via a data channel, and the dial-via-PBX request is received 502 at the facilitator. The facilitator responds to the request by transmitting 504 a call initiation message to the client of the requesting mobile device. The call initiation message includes a transaction ID and a call-in telephone number but is not so limited. The call-in telephone number is a telephone number by which the mobile device can establish a telephone connection with the PBX. The client is configured to control the mobile device to automatically initiate 506 a first call leg with the PBX by dialing the call-in telephone number received from the facilitator. The client is also configured to transmit the transaction ID to the PBX using, for example, an in-band DTMF sequence. The PBX is configured, in response to the transaction ID received from the mobile device, to initiate 508 a second call leg to the intended call recipient, and join 510 the second call leg to the call recipient with the first call leg from the mobile device. Alternatively, the facilitator may generate a unique number to call for each transaction (at least within a time period) and therefore not require the mobile device to transmit the transaction ID to the PBX, or only require a shorter transaction ID.

0041<figref idref="f0006"><b>Figure 6</b></figref> is a call flow diagram for forward dial via PBX 600, under an embodiment. This call flow 600 is presented as an example call flow 600 and does not limit the forward dial via PBX described herein to only this call flow 600. Using a client, the user of a mobile device selects an intended call recipient from a phonebook, The client initiates the forward dial via PBX call flow 600 by generating and sending a dial-via-PBX request or invitation message (e.g., INVITE) to the corresponding facilitator via a data channel. The request message includes contact information of the intended call recipient but is not so limited.

0042The facilitator generates and transmits a call initiation instruction (e.g., INVITE (w/SDP) to a PBX hosted by the enterprise. The facilitator also responds to the client request by transmitting a call initiation message (e.g., 183 Progress) to the requesting mobile device. The call initiation message includes a transaction ID and a call-in telephone number (e.g., a TLDN) but is not so limited. The facilitator of an embodiment provides an optional response message to the client to supply rich identification information (e.g., rich caller ID as described herein) for the intended call recipient.

0043The call-in telephone number is a telephone number by which the mobile device can establish a telephone connection with the PBX during the forward dial via PBX. The call-in telephone number is provided to the facilitator by the PBX in an embodiment, but the embodiment is not so limited as one or more other components of the AMC system and/or host enterprise can provide the call-in telephone number.

0044The client of the mobile device initiating the call is configured to automatically initiate a first call leg via a voice channel with the PBX (e.g., call into TLDN) by controlling the mobile device to dial the call-in telephone number received from the facilitator. Once connected with the PBX the client is configured to control the mobile device to transmit the transaction ID to the PBX using, for example, a DTMF tone or sequence. The PBX is configured, in response to receipt or detection of the transaction ID received from the mobile device, to initiate a second outbound call leg to the intended call recipient. Once the PBX establishes the second outbound call leg with the destination telephone number, the PBX joins the first and second outbound call legs into a conference call (e.g., dial out to recipient, connect call legs together).

0045In one embodiment, to ensure that the second outbound call leg to the call recipient does not get answered by a voicemail machine, the second outbound call leg is considered successful only if the call recipient responds with a DTMF signal upon answering the call. When the recipient answers the call, for example, the facilitator plays a prompt (e.g., "Jane Doe wants to talk with John Smith. Please press 1 if you are John Smith and would like to accept the call"). If the DTMF is not received from the client device of the call recipient within a time period, the second outbound call leg is dropped and the caller is informed that the intended call recipient corresponding to the dropped call leg could not be reached.

0046The AMC system of an alternative embodiment provides dial via PBX through use of a "reverse" dial via PBX that includes an inbound call leg from the PBX to the mobile device of the call originator. The call recipient is connected using an outbound call leg from the PBX to the client device of the call recipient. The reverse dial via PBX may be preferred when the PBX-initiated call to the mobile device is relatively cheaper than a call originated at the mobile device to the PBX (forward dial via PBX).

0047<figref idref="f0007"><b>Figure 7</b></figref> is a flow diagram for reverse dial via PBX 700, under an embodiment. The AMC client of the mobile device under the reverse dial via PBX 700 initiates transfer or transmittal of a dial-via-PBX request via a data channel, and the dial-via-PBX request is received 702 at the facilitator. The facilitator generates 704 and transmits to a PBX a call initiation instruction in response to the dial-via-PBX request. The PBX is configured to automatically initiate 706 a first call leg with the mobile device in response to the call initiation instruction. The client of the caller's mobile device is configured to automatically answer the call from the PBX. To determine that the first call leg from the PBX was answered by the mobile device and not sent to the mobile device voicemail, in one embodiment, the client controls the mobile device of an embodiment to transmit a DTMF sequence to the PBX when the client answers the call. If the PBX does not receive the DTMF sequence within a given time frame, the PBX is configured to assume the call went to the mobile device voicemail and to re-attempt the call leg to the mobile device. The PBX is instructed, in response to the mobile device answering the call, to initiate 708 a second call leg to the intended call recipient, and to join 710 the second call leg to the call recipient with the first call leg to the mobile device.

0048<figref idref="f0008"><b>Figure 8</b></figref> is a call flow diagram for reverse dial via PBX 800, under an embodiment. This call flow 800 is presented as an example call flow 800 and does not limit the reverse dial via PBX described herein to only this call flow 800. The user of a mobile device selects an intended call recipient from a phonebook, and information of the intended call recipient is provided to the client hosted on the mobile device. The client initiates the reverse dial via PBX call flow 800 by generating and sending a dial-via-PBX request or invitation message (e.g., INVITE) to the corresponding facilitator via a data channel. The request message includes contact information of the intended call recipient but is not so limited.

0049The facilitator generates and transmits a call initiation instruction (e.g., INVITE) to a PBX hosted by the enterprise. The facilitator of an embodiment is configured to act as a gateway that translates protocols between the client or client device and the PBX or other communication system or network. Thus, the facilitator of an embodiment is configured to relay or transfer the message from the client and, additionally, to change or modify the message before or during the transfer. In one example, the INVITE from the client does not include a Session Description Protocol (SDP) but the message from the facilitator to the PBX does include the SDP. In another example, the message from the client to the facilitator may be a call request that is synchronized but the message between the facilitator and the PBX may be SIP or JTAPI.

0050The call initiation instruction, generated in response to the dial-via-PBX request from the client, instructs the PBX to create a first outbound call leg with the requesting mobile device hosting the client via a landline number of the enterprise and a voice channel of the mobile device. The PBX is configured to automatically initiate the first outbound call leg (e.g., dial mobile handset, setup cellular voice cal leg) with the mobile device of the call initiator in response to the call initiation instruction.

0051The client of an embodiment is configured to automatically answer (e.g., auto-answer) the call from the PBX; alternatively, the user can manually answer the incoming call. The PBX is instructed, in response to detecting that the mobile device has answered the call, to initiate a second outbound call leg to the intended call recipient. Once the PBX establishes the second outbound call leg with the destination telephone number, the PBX joins the first and second outbound call legs into a conference call (e.g., dial out to recipient, connect call legs together).

0052More specifically, <figref idref="f0009"><b>Figure 9</b></figref> is a detailed call flow diagram for dial via PBX 900, under an embodiment. This call flow 900 is presented as an example call flow 900 and does not limit the dial via PBX described herein to only this call flow 900. The client hosted on a mobile device initiates the dial via PBX call flow 900 by generating and sending a dial-via-PBX request or invitation message (e.g., 1.1 INVITE) to the corresponding facilitator via a data channel. A field of the request message includes a valid destination telephone URL but is not so limited. The facilitator responds to the client with an optional message (e.g., 1.2 UPDATE) to supply rich identification information (e.g., rich caller ID as described herein) for the intended call recipient. The facilitator returns a response to the client indicating that the invitation was correct (e.g., 1.3 OK), and the client returns an acknowledgment message (e.g., 1.4 ACK). Alternatively, the facilitator returns a response to the client indicating the invitation was malformed (e.g., 1.3 Bad Request). The client initiates play of an audible feedback message for the user of the mobile device hosting the client (e.g., 1.5 play audio for feedback) when the client receives the message from the facilitator indicating that the invitation was correct (e.g., 1.3 OK).

0053The facilitator generates and transmits a call initiation instruction (e.g., 1.6 invoke caller call leg) to a PBX hosted by the enterprise. The call initiation instruction, generated in response to the dial-via-PBX request from the client, instructs the PBX to create an outbound call leg between a landline number of the enterprise and a voice channel of the mobile device hosting the client. The enterprise landline number of an embodiment is a landline number corresponding to the user but is not so limited. The PBX is configured to automatically initiate the outbound call leg (e.g., 1.7 invoke caller cal leg) with the mobile device in response to the call initiation instruction. If the mobile device does not answer the outbound call from the PBX within a pre-specified period (as determined by the facilitator) or the line is busy, the facilitator disconnects the line and ends the dialog.

0054The mobile device generates a call event message (e.g., 1.8 call event) to the client in response to the call from the PBX. The client of an embodiment is configured to automatically answer (e.g., 1.9 auto-answer) the call from the PBX in response to the call event message. Alternatively, the user can manually answer the incoming call.

0055When the client is configured to automatically answer the incoming call from the PBX, and to ensure that the call from the PBX was initiated by the facilitator, the facilitator generates and sends a dual-tone multi-frequency (DTMF) tone or sequence to the client (e.g., 1.10 send "1" DTMF signal). The client of an embodiment disconnects the incoming call if it does not receive the DTMF tone or sequence within a pre-specified time period.

0056Furthermore, to determine that the outbound call leg from the PBX was answered by the client and not sent to the mobile device voicemail, the client of an embodiment signals the client device to generate and send a DTMF signal to the PBX (e.g., 1.11 send "2" DTMF signal) in response to the client answering the call. If the PBX does not receive the DTMF tone or sequence from the mobile device within a given time period, the facilitator is configured to assume the call went to the mobile device voicemail and to terminate the session. The facilitator of an embodiment is configured to subsequently initiate a re-attempt of the outbound call leg to the mobile device. Once the outbound call leg is established, the caller will hear an "on hold" indication (e.g., music, message, etc.) (e.g., 1.12 hear PBX-generated ringing or on-hold audio); when the caller is subsequently connected with the intended call recipient, the caller will hear the call ringing (or a busy signal).

0057The PBX is instructed, in response to the mobile device answering the call, to initiate a second call leg to the intended call recipient. Therefore, the PBX relays the DTMF signal received from the mobile device to the facilitator (e.g., 1.13 relay DTMF). When the facilitator receives a signal from the PBX (supplanted by the DTMF tone on certain devices), it instructs the PBX (e.g., invoke recipient call leg) to create an outbound call leg between an enterprise voice channel and the destination telephone number and join the two call legs into a conference call (e.g., 1.15 recipient call leg). If the outbound call leg to the destination telephone number cannot be created, the facilitator disconnects the outbound call leg to the mobile device and terminates the dial via PBX event.

0058The PBX generates and sends an event message to the facilitator when either the outbound call leg to the caller or the outbound call leg to the call recipient disconnects (e.g., 1.16 caller/callee call leg disconnected event). When the facilitator receives the disconnect event notice, the facilitator instructs the PBX to disconnect the other call leg and end the conference call (e.g., 1.17 disconnect callee/caller call leg command and end conf). In one embodiment, neither the facilitator nor the client is required to send an event completion or "BYE" message to the other in response to a disconnect event; instead the facilitator and the client implicitly generate a local BYE when each gets an event that the call has disconnected. Therefore, the facilitator receives a PBX call disconnect event from which it locally generates its BYE, and the client receives a device call termination event from which it locally generates its BYE.

0059As described above, the client receives a device call termination event (e.g., 1.18 client receives disconnect event) from which it generates locally an event completion message (e.g., BYE). The client of an embodiment, in response to generation of a local BYE, reconnects to the facilitator (e.g., 1.19 establish data channel to server). The facilitator generates a call log and synchronizes the call log to the client (e.g., 1.20 initiate SYNC to send AC_REQ).

0060The PBX may also be instructed by the facilitator, based on information sent from the mobile device, to initiate an outbound call leg not to the initiating mobile client but to another phone number (e.g., a hotel phone number). If this outbound call from the PBX to this alternative phone number is not answered within a pre-specified period (as determined by the facilitator) or the line is busy, the facilitator disconnects the line and ends the dialog. When this call is answered, the PBX creates a second call leg, as describe above, to the recipient's phone number and conferences in the two call legs. This enables the mobile client to act as a remote controller, via the data channel to the facilitator, to initiate a call between two phone numbers via the PBX. As in all cases, a call log is generated and transferred to the mobile client after the call is completed or after an error occurred.

0061The dial via PBX of an embodiment includes ad-hoc conferencing between a caller and numerous call recipients. The AMC user generally selects via his/her mobile device a group or set of call recipients. The mobile device sends a dial-via-PBX request to the facilitator with a list that includes the telephone numbers of all selected call recipients. Once the first call leg is initiated with the client device of the caller, the facilitator initiates a call leg for each recipient and then joins the caller and all recipients together into a conference call. The first call leg between the facilitator and the client device of the caller can be established under the forward dial via PBX or reverse dial via PBX as described herein.

0062To ensure that the call legs to each recipient of the group do not get answered by a voicemail machine, a call leg is considered successful only if the call recipient of a call leg responds with a DTMF signal upon answering the call. When the recipient answers the call, for example, the facilitator plays a prompt (e.g., "Jane Doe wants to talk with John Smith. Please press 1 if you are John Smith and would like to accept the call"). If the DTMF is not received from the client device of the call recipient within a time period, the call leg is dropped and the facilitator is informed that the intended call recipient corresponding to the dropped call leg could not be reached. The facilitator then conveys this information to the client device via the data channel.

0063<figref idref="f0010"><b>Figure 10</b></figref> is a call flow diagram for forward dial via PBX using ad-hoc conferencing 1000, under an embodiment. This call flow 1000 is presented as an example call flow 1000 and does not limit the forward dial via PBX using ad-hoc conferencing described herein to only this call flow 1000. The user of a mobile device selects numerous intended call recipients from a phonebook or directory, and information of the intended call recipients is provided to the client hosted on the mobile device; this example includes five (5) call recipients, but the embodiment is not limited to this number of recipients. The client initiates the forward dial via PBX call flow 1000 by generating and sending a dial-via-PBX request or invitation message (e.g., INVITE) to the corresponding facilitator via a data channel. The request message includes contact information of the intended call recipients but is not so limited.

0064The facilitator generates and transmits a call initiation instruction (e.g., INVITE (w/SDP) to a PBX hosted by the enterprise. The facilitator also responds to the client request by transmitting a call initiation message to the requesting mobile device. The call initiation message includes a transaction ID and a call-in telephone number (e.g., a TLDN) but is not so limited. The call-in telephone number is a telephone number by which the mobile device can establish a telephone connection with the PBX during the forward dial via PBX. The call-in telephone number is provided to the facilitator by the PBX in an \ embodiment, but the embodiment is not so limited as one or more other components of the AMC system and/or host enterprise can provide the call-in telephone number.

0065The client of the mobile device initiating the call is configured to automatically initiate a first call leg via a voice channel with the PBX (e.g., call into TLDN) by controlling the mobile device to dial the call-in telephone number received from the facilitator. Once connected with the PBX the client is configured to control the mobile device to transmit the transaction ID to the PBX using, for example, a DTMF tone or sequence. The PBX is configured, in response to receipt or detection of the transaction ID received from the mobile device, to initiate a second outbound call leg to each of the intended call recipients. Once the PBX establishes the outbound call legs with the destination telephone numbers of available ones of the intended recipients, the PBX joins the first outbound call leg and the outbound call legs to the available call recipients into a conference call (e.g., dial out to recipient, connect call legs together).

0066The AMC system of an alternative embodiment provides dial via PBX through use of a "reverse" dial via PBX using ad-hoc conferencing that includes an inbound call leg from the PBX to the mobile device of the call originator. The numerous call recipients are connected using an outbound call leg from the PBX to the client device of the call recipients. The reverse dial via PBX may be preferred when the PBX-initiated call to the mobile device is relatively cheaper than a call originated at the mobile device to the PBX (forward dial via PBX).

0067<figref idref="f0011"><b>Figure 11</b></figref> is a call flow diagram for reverse dial via PBX using ad-hoc conferencing 1100, under an embodiment. This call flow 1100 is presented as an example call flow 1100 and does not limit the reverse dial via PBX using ad-hoc conferencing described herein to only this call flow 1100. The user of a mobile device selects numerous intended call recipients from a phonebook or directory, and information of the intended call recipient is provided to the client hosted on the mobile device; this example includes four (4) call recipients, but the embodiment is not limited to this number of recipients. The client initiates the reverse dial via PBX call flow 1100 by generating and sending a dial-via-PBX request or invitation message (e.g., INVITE) to the corresponding facilitator via a data channel. The request message includes contact information of the intended call recipients but is not so limited.

0068The facilitator generates and transmits a call initiation instruction (e.g., INVITE (w/SDP) to a PBX hosted by the enterprise. The call initiation instruction, generated in response to the dial-via-PBX request from the client, instructs the PBX to create a first outbound call leg with the requesting mobile device hosting the client via a landline number of the enterprise and a voice channel of the mobile device. The PBX is configured to automatically initiate the first outbound call leg (e.g., dial mobile handset, setup cellular voice cal leg) with the mobile device of the call initiator in response to the call initiation instruction.

0069The client of an embodiment is configured to automatically answer (e.g., auto-answer) the call from the PBX; alternatively, the user can manually answer the incoming call. The PBX is configured, in response to detecting that the mobile device has answered the call, to initiate outbound call legs to each intended call recipient. Once the PBX establishes the outbound call legs with the destination telephone numbers of the recipients, the PBX joins the first outbound call leg and the outbound call legs to the available call recipients into a conference call (e.g., dial out to recipient, connect call legs together).

0070While embodiments of the dial via PBX described above include contacting one or more individuals, the dial via PBX of an alternative embodiment enables a caller to contact a resource using class-based call routing. Instead of selecting a person or persons to receive a call, the AMC user selects a class or class group at the mobile device from which he/she is initiating the call. Resources of the class group all possess a common attribute. The attributes by which classes are organized includes one or more of a skill, job specialty code, job title, company, department, and division to name a few. The client of the mobile device and the facilitator operating under the dial via PBX described herein establish a call leg with the facilitator. The facilitator establishes contact with one or more people represented by this resource by establishing call legs with client devices of one or more class resources. Communications are established between the caller and at least one resource when the facilitator forms a conference call including the established call legs.

0071<figref idref="f0012"><b>Figure 12</b></figref> is an information flow 1200 for dial via PBX using class-based call routing, under an embodiment. In this example, the caller initiates a call to members of a group using skill-based call routing, but the embodiment is not limited to skill-based routing. While membership in the group of this example is according to a skill (e.g., Support Team), group membership could be organized by any attribute (e.g., job title, company department/division, etc.) common to members of a group as determined by the originator when he/she configures or selects the groups using components of the AMC system described herein.

0072The caller in this example has a need to reach someone in the support team and initiates a call and class-based call request routing by selecting 1 a skill-based group ("Team, Support") at his/her client device. Selection 1 of the skill-based group includes use of phonebook information displayed on the client device user interface 1202 via one or more of the AMC client and facilitator as described above. The phonebook information can include one or more of personal contacts and various ones of enterprise contacts or phonebooks as described herein.

0073Upon selection of the skill-based group, the facilitator controls or directs the establishment 4 of a call leg between the mobile device of the caller and the enterprise PBX, as described above. Furthermore, the facilitator automatically routes 2 the call to at least one resource or member ("Production Support Agent") of the selected group. The call can be routed to any number of resources of the group, and the resources of the group are defined by one or more attributes of the resource being assigned to or included in the group. The call routing is performed by one or more components or algorithms of the AMC system according to a routing scheme, and the routing scheme is applied under the dial via PBX to control establishment of call legs with one or more call recipients.

0074A routing scheme of an embodiment determines a routing using information like availability, activity rate, sender preference or search criteria, and resource preference to name a few. As one example, the facilitator attempts to establish a call leg with the first available, least recently used call recipient of the group. The facilitator attempts to establish a call leg with the next available call recipient of the group if the first called recipient does not respond within a predetermined amount of time. This process continues until a call leg is established with a call recipient of the group. If the facilitator is unable to establish a call leg with any recipient, the caller is notified of the situation. While the call routing is sequential in this example, alternative examples or embodiments use parallel routing or more complex routing models (e.g., first try every member of group X, then broadcast call request message to every member of group Y), as described below.

0075When a resource of the group accepts the call, using his/her client device 1204, a call leg is established 3 with the resource accepting the call. The facilitator then establishes communication 5 between the mobile device of the caller and the client device of the resource by joining the call legs as described above.

0076The AMC facilitator includes an adapter or adapter framework by which the facilitator simultaneously integrates with components of the enterprise and enterprise servers, as described above with reference to <figref idref="f0003">Figure 3</figref>. The facilitator uses an adapter for each enterprise component to which it integrates. The adapter of an embodiment is a protocol-specific adapter for each enterprise component to which it integrates; alternatively, the adapter includes vendor-specific adapters. As an example, the AMC adapters are used in the configuration of groups (classes) and group membership (resources). The AMC adapters can include a set of interfaces and utilities that receive or fetch and convert the data from one or more enterprise components into a common data structure. For example, the AMC adapters can receive information from external systems and use the received information to automatically generate and update configuration of groups and group membership to name a few. This AMC adapter configuration can leverage such external systems as human resource systems, financial systems, customer relationship management (CRM) systems, telephone systems (ACD, etc), directory servers, and email servers to name a few.

0077The class-based call routing described above includes rule-based routing. The rule-based routing includes the use of rules that can be customized on a group and/or class basis. The rules of an embodiment can be defined via static configuration or dynamic custom processes. A rule can be based on any number of dynamic data inputs, from any number of disparate systems. Further, a rule can trigger additional processes to run before, after, or during the call routing.

0078The call routing described above can be performed using a variety of routing schemes including, but not limited to, parallel routing, sequential routing, and combined parallel and sequential routing. For example, parallel routing can include simultaneous routing of the call to all resources of the selected group. Parallel routing can also include a first routing of the call to at least one target device of a first set of resources simultaneous with a second routing of the call to at least one target device of a second set of resources.

0079Sequential routing includes sequential routing to each of the resources of the class group. For example, the sequential routing includes a first routing of the call to a first target device of a first resource, and a second or subsequent routing of the call to a second target device of a second resource in response to a trigger condition (e.g., elapsed time, the absence of the response message to the first routing, etc.). One or more algorithms of the AMC system select an order of call routing to resources of the class group. As another example, the sequential routing includes a first routing of the call to at least one target device of a first set of resources, and a second routing of the call to at least one target device of a second set of resources in response to a trigger condition (e.g., elapsed time, the absence of the response message to the first routing, etc.).

0080The routing of a subsequent call under sequential routing of an embodiment occurs in response to a trigger condition but is not so limited. The trigger condition can be any condition selected by a user and/or provided by a host enterprise and includes, for example, expiration or termination of a time period since the first routing, receipt of a negative response from the preceding routing, and absence of a response message to the preceding routing to name a few.

0081The combined parallel and sequential routing includes parallel routing to a first set of resources of the class group, and sequential routing to each of a second set of resources of the class group. Similarly, the combined parallel and sequential routing includes sequential routing to each of a first set of resources of the class group, and parallel routing to a second set of resources of the class group. Additionally, the combined parallel and sequential routing includes parallel routing to a first set of resources of the class group followed sequentially by parallel routing to a second set of resources of the class group.

0082Resources of a group can be included or excluded from a routing scheme according to routing rules of the AMC system under rule-based routing of an embodiment. The routing rules are determined, for example, by an enterprise hosting the AMC system, and are controlled by one or more of the AMC facilitator and AMC client. The rule-based routing can include routing according to use status of the resource (e.g., routing first to relatively most-used resources, routing first to relatively least-used resources, etc.). The rule-based routing can also include routing according to skill level of the resource (e.g., routing first to relatively higher-skilled resources, routing first to relatively lower-skilled resources, etc.). Furthermore, the rule-based routing includes routing according to availability of the resource, where availability can be inferred by the system or set by the resource (e.g., routing first to available resources, etc.). Additionally, the rule-based routing includes routing according to one or more of class level of the resource and expense level of the resource.

0083The dial via PBX of an embodiment includes the use of rich caller ID as described herein and in the Related Applications. The facilitator of an embodiment constructs or generates a rich caller ID in response to or upon receipt of a call event, as described above. The rich caller ID includes information, messages, and/or other communications (referred to herein as contact data or caller data) that provide additional context to help in making calls and to help a user in deciding if and/or when to participate in a call. The rich caller ID is generated by mapping a telephone number to a contact within directories of a host enterprise. The telephone number used in the mapping can be, for example, received as caller ID with the incoming call, and input by a user making a call, to name a few. The directories of the host enterprise used by the facilitator in generating the rich caller ID include internal and/or external directories of the enterprise comprising one or more of corporate directories, directory servers, electronic mail servers, CRM systems (e.g., sales lead telephone numbers), telephone systems, human resource systems, financial systems, personal contacts of the user in personal or enterprise directories, and white pages to name a few. As an example, the contact data includes one or more of a name, address, telephone number, electronic mail address, employer, and job of the caller, but the embodiment is not so limited.

0084In addition to the information automatically received or gathered from the host enterprise, the facilitator can add additional contact data to the rich caller ID. Examples of additional caller data or information added by the facilitator generally include but are not limited to ice breaker information and sales information, for example. Ice breakers include information available in the user's personal contacts that one might find useful in initiating a conversation. As an example, ice breakers can include personal information of the caller (e.g., family, spouse, relative, children, siblings, birthday, anniversary, etc.). Sales information includes status information about one or more previous interactions with the caller or events involving the caller (e.g., a message indicating a status of work promised to the caller, etc.).

0085The dial via PBX described above enables or includes a number of possible usage scenarios. Descriptions follow of numerous usage scenarios; these usage scenarios are provided as examples only and are not to limit the dial via PBX described herein to only to these usage scenarios.

0086Under an example usage scenario, a caller through use of the mobile device selects the name of a call recipient from a phone book or contact list and dials the call recipient using the one-click dial (green button) of the mobile device. The phone book or contact list includes local lists or directories of the mobile device as well as one or more directories of the enterprise with which the caller is affiliated. In response, the call is placed directly through a voice channel of the cellular network with which the mobile device is associated.

0087The caller of another usage scenario selects the name of a call recipient or class group from a phone book or contact list and dials the call recipient(s) using the Options Menu of the AMC user interface. The client controls display of the AMC user interface at the mobile device. The Options menu includes options for "Dial Direct" and "Dial via PBX." Selection of the Dial Direct option results in the call being placed directly through a voice channel of the cellular network with which the mobile device is associated. Selection of the Dial Via PBX option results in the call being placed through the enterprise PBX as described herein.

0088A caller under yet another example usage scenario uses the mobile device to select the name of a call recipient from a conversation list, and dials the call recipient using the one-click dial (green button) of the mobile device. In response, the call is placed directly through a voice channel of the cellular network with which the mobile device is associated.

0089Another example usage scenario involves the caller selecting the name of a call recipient from a conversation list and dialing the call recipient through use of the Options Menu of the AMC client interface. The Options menu includes options for "Dial Direct" and "Dial via PBX." Selection of the Dial Direct option results in the call being placed directly through a voice channel of the cellular network with which the mobile device is associated. Selection of the Dial Via PBX option results in the call being placed through the enterprise PBX as described herein.

0090Using a home screen of the mobile device, under still another usage scenario, a caller enters digits of a telephone number to dial. When the caller dials the call recipient using the one-click dial (green button) of the mobile device, the call is placed directly through a voice channel of the cellular network with which the mobile device is associated. The caller can also choose a dialing preference by pressing a soft key displayed on the phone. The preferences available for selection include "Dial Direct" and "Dial via PBX." Selection of the Dial Direct option results in the call being placed directly through a voice channel of the cellular network with which the mobile device is associated. Selection of the Dial Via PBX option results in the call being placed through the enterprise PBX as described herein.

0091Alternatively, the caller selects the Dial via PBX option using the Options Menu of the AMC client interface, and enters digits of a telephone number to dial. The caller then dials the call recipient using either the one-click dial (green button) of the mobile device or the Dial menu of the mobile device. The call is placed through the enterprise PBX as described herein.

0092Using a home screen of the mobile device under other usage scenarios, a caller enters digits of a telephone number to dial; alternatively, the telephone number of the intended call recipient is stored on an enterprise directory. The format of the telephone number is one of the following: Area Code + Number (408-625-3000); Long Distance access code + Area Code + Number (1408-625-3000); "+" Country code + Area Code + Number (+1408-625-3000); International Prefix + Country Code + Area Code + Number (011-91-11-524768); Number (768-3000); and PBX Extension (3001). Following entry or selection of a telephone number, the caller selects the Dial via PBX option using the Options Menu of the AMC client interface. The client of the mobile device directly transfers the telephone number digits entered or selected by the user to the facilitator. The facilitator is configured to apply normalization rules and appropriate prefixes to the telephone number and initiates the outbound call via the PBX.

0093An example caller experience at the mobile device is as follows when the telephone number of the intended recipient is dialed via the enterprise PBX, and the mobile device supports the telephony API to intercept incoming call. The caller is provided a visual and audio indication at the mobile device that the call is being placed. For example, the caller may hear or see displayed a message such as "Please wait while call is dialed" along with an audible indication (beep or tones). The facilitator places an outbound call to the caller, as described herein, and the client of the caller's mobile device intercepts the call and changes the caller message to "Connecting." The facilitator then dials the called party and the caller is provided a ring back tone. When the called party answers, the caller and called party are joined or bridged. When the caller terminates the call before the call is connected to the called party, the facilitator receives a hang up event and terminates the outbound leg of the call to the called party. When the called party number is busy, the facilitator joins the caller and the called party resulting in the caller hearing all tones (e.g., busy) of the outbound call leg to the called party. Similarly, while dialing the called party and the telephone network plays error tones, the facilitator joins the caller and the called party resulting in the caller hearing all tones (e.g., error) of the outbound call leg to the called party. A call log is synchronized from the facilitator to the client. Further, a dialed call log is generated in cases where the called party is busy or other error conditions occur on the network carrying the call.

0094Another example caller experience at the mobile device is as follows when the telephone number of the intended recipient is dialed via the enterprise PBX, and the mobile device does not support the telephony API to intercept incoming call. The caller is provided a visual indication at the mobile device instructing him/her to pick up an incoming call and wait a short period to hear a call progress tone. For example, the caller may see displayed a message such as "Accept incoming call and wait few seconds for call progress tone." The facilitator places an outbound call to the caller, as described herein, and the outbound call received at the mobile device causes the mobile device to ring. The caller is required to manually accept the call. The facilitator then dials the called party and the caller is provided a ring back tone. When the called party answers, the caller and called party are joined or bridged. When the caller terminates the call before the call is connected to the called party, the facilitator receives a hang up event and terminates the outbound leg of the call to the called party. When the called party number is busy, the facilitator joins the caller and the called party resulting in the caller hearing all tones (e.g., busy) of the outbound call leg to the called party. Similarly, while dialing the called party and the telephone network plays error tones, the facilitator joins the caller and the called party resulting in the caller hearing all tones (e.g., error) of the outbound call leg to the called party. A call log is synchronized from the facilitator to the client. Further, a dialed call log is synchronized from the facilitator to the client. A call log is also generated in cases where the called party is busy or other error conditions occur on the network carrying the call.

0095An example experience of a called party at his/her client device when a caller dials via PBX includes the called party receiving a caller ID of the calling PBX.

0096Some examples follow of alternative AMC system configurations that include the facilitator and client described above. <figref idref="f0013"><b>Figure 13</b></figref> is a block diagram of an AMC system 1300, under an alternative embodiment. The AMC system 1300 includes a server or other processor-based device hosting the facilitator 102. The facilitator 102 communicates with one or more client devices 101 to provide AMC system functions among the client devices 101 via network couplings that include the Internet 104a and a telecommunications network 104b. The telecommunications network 104b includes, for example, a cellular telephone network or a public switched telephone network (PTSN), but can be other voice and data communication networks as known in the art. The cellular telephone network can use communication protocols that include, for example, Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), and Time Division Multiple Access (TDMA), but are not so limited.

0097<figref idref="f0014"><b>Figure 14</b></figref> is a block diagram of an AMC system 1400, under another alternative embodiment. The AMC system 1400 includes a server hosting the facilitator 102, and the facilitator 102 communicates with one or more client devices 101 to provide AMC system functions among the client devices 101 via network couplings that include the Internet 104a and/or multiple telecommunications networks 104b1 to 104bn. The telecommunications networks 104b1-104bn are as described above, but are not so limited.

0098<figref idref="f0015"><b>Figure 15</b></figref> is a block diagram of an AMC system 1500, under yet another alternative embodiment. The AMC system 1500 includes a server hosting the facilitator 102, and the server/facilitator 102 is a component of a telecommunications network operator infrastructure. The facilitator 102 communicates with one or more client devices 101 to provide AMC system functions among the client devices 101 via network couplings 104, as described above, but is not so limited. In an alternative embodiment, the server/facilitator 102 may not be a component of a telecommunications network operator infrastructure. In another alternative embodiment, the server/facilitator 102 can be a component of one or more other network infrastructures.

0099<figref idref="f0016"><b>Figure 16</b></figref> is a block diagram of an AMC system 1600 in an enterprise domain, under another alternative embodiment. The AMC system 1600 includes a server hosting the facilitator 102 where the server/facilitator 102 is a component of a corporate or enterprise infrastructure 1602. The server can host numerous additional applications 1606 in addition to the facilitator 102 or can be dedicated to the facilitator 102. The facilitator 102 communicates with one or more client devices 101 in the public domain 1604 to provide AMC system functions among the client devices 101 via network couplings 104. The network couplings 104 include, for example, the Internet and one or more telecommunication service provider infrastructures, but can include any number/type of couplings. The facilitator 102 also communicates with one or more client devices 101E in the enterprise domain 1602 to provide AMC system functions among the client devices 101E as described below. The client devices 101E in the enterprise domain 1602 are shown coupled to one or more LANs, but are not so limited.

0100<figref idref="f0017"><b>Figure 17</b></figref> is a block diagram of an AMC system 1750 in a public domain coupled across components of an enterprise domain, under another alternative embodiment. The AMC system 1750 includes a server hosting the facilitator 102 where the server/facilitator 102 is a component of a carrier or service provider infrastructure or hosted data center infrastructure for example, but is not so limited. The facilitator 102 communicates with one or more client devices 101 in the public domain 1704 to provide AMC system functions among the client devices 101 via network couplings 104. The network couplings 104 include, for example, the Internet and one or more telecommunication service provider infrastructures, but can include any number/type of couplings. The facilitator 102 also communicates with components of the enterprise domain 1702 including, for example, one or more client devices 101E, one or more enterprise servers 1708, and one or more LANs. The facilitator 102 provides AMC system functions among the client devices 101E as described below. The client devices 101E in the enterprise domain 1702 are shown coupled to one or more LANs, but are not so limited.

0101As an alternative to the couplings of this AMC system 1750, the facilitator can be hosted on one or more servers (not shown) of the telecommunications network operator. The facilitator of the telecommunications network operator couples to the enterprise servers via local contact servers (not shown) and/or Virtual Private Network (VPN) couplings, but is not so limited.

0102<figref idref="f0018"><b>Figure 18</b></figref> is a block diagram of an AMC system 1800 in an enterprise domain, under still another alternative embodiment. The AMC system 1800 includes one or more facilitators that form facilitator clusters 602a and 602b within each of a number of enterprise domains 603a and 603b. Facilitators of the facilitator clusters 602a and 602b communicate with one or more client devices 101 to provide AMC system functions among the client devices 101 via network couplings 104. The network couplings 104 include, for example, at least one of the Internet and multiple telecommunication service providers 604a and 604b, but can include any number/type of couplings. The facilitators also couple with at least one of corporate directory servers and/or electronic mail (email) servers 610a/610b, authentication servers 612a/612b, and management consoles 614a/614b of the enterprise domains 603a/603b, but are not so limited.

0103<figref idref="f0019"><b>Figure 19</b></figref> is a block diagram of an active mobile collaboration (AMC) system 1900, under an embodiment. The AMC system 1900 includes any number X(n) of communication devices 101 coupled for communication via one or more facilitators 102 and one or more couplings 104. One or more of the communication devices 101 include an AMC client application. Additionally, one or more of the communication devices 101 include the facilitator 102. The AMC client applications and facilitator applications function to allow users of the communication devices to dynamically manage how and when mobile calls take place, intelligently screen calls based on caller identity, urgency, and subject matter, determine which contacts in a directory are available to talk and which ones choose not to be disturbed, and increase accessibility of enterprise and personal contact information from mobile phones, as described in detail below.

0104The AMC system components including the facilitator and AMC client described above function to allow users of the client devices or handsets like cellular telephones to quickly coordinate conversations, screen unwanted calls and interruptions and access enterprise directories. Specifically, the AMC system components increase call success rates by dynamically managing how and when mobile calls take place, let users intelligently screen calls based on caller identity, urgency and subject matter, quickly show which contacts are available to talk and which contacts choose not to be disturbed, reduce interruptions while encouraging urgently needed call-backs, and increase accessibility of enterprise and personal contact information from mobile phones.

0105Aspects of the communications systems 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 communications systems include: microcontrollers with memory (such as electronically erasable programmable read-only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the communications systems 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.

0106It should be noted that components of the various systems and methods disclosed herein may be described using computer aided design tools and expressed (or represented), 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.

0107Examples 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 the above described systems and methods 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.

0108Unless the context clearly requires otherwise, throughout the description, 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.