(19)
(11)EP 1 997 301 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
06.05.2020 Bulletin 2020/19

(21)Application number: 07753671.2

(22)Date of filing:  21.03.2007
(51)International Patent Classification (IPC): 
H04M 7/12(2006.01)
H04M 3/436(2006.01)
H04M 3/42(2006.01)
(86)International application number:
PCT/US2007/007063
(87)International publication number:
WO 2007/109342 (27.09.2007 Gazette  2007/39)

(54)

CALL NOTIFICATION WITH RICH CALLER IDENTIFICATION

ANRUFBENACHRICHTIGUNG MIT GENAUER ANRUFERIDENTIFIKATION

NOTIFICATION DES APPELS AVEC IDENTIFICATION D'APPELANT ENRICHIE


(84)Designated Contracting States:
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

(30)Priority: 21.03.2006 US 784747 P

(43)Date of publication of application:
03.12.2008 Bulletin 2008/49

(73)Proprietor: Cisco Technology, Inc.
San Jose, CA 95134 (US)

(72)Inventors:
  • CHATTERJEE, Saurav
    San Jose, CA 95134 (US)
  • PERFETTO, Josh
    San Jose, CA 95134 (US)
  • RANA, Hemendra
    San Jose, CA 95134 (US)
  • FULLARTON, Paul
    San Jose, CA 95134 (US)
  • SHAH, Ankur
    San Jose, CA 95134 (US)

(74)Representative: Kazi, Ilya et al
Mathys & Squire LLP
The Shard 32 London Bridge Street London SE1 9SG
The Shard 32 London Bridge Street London SE1 9SG (GB)


(56)References cited: : 
US-A1- 2002 055 351
US-A1- 2002 075 304
US-B1- 6 724 872
US-A1- 2002 064 260
US-B1- 6 404 860
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    TECHNICAL FIELD



    [0001] The disclosure herein relates generally to communication systems and, in particular, to wireless communication systems.

    BACKGROUND



    [0002] Mobile 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.

    [0003] As 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] US Patent Application Publication No. 2002/075304 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. US Patent No. 6,404,860 discloses a call management system which provides an Internet call management service that permits a subscriber to receive information about incoming calls, and provides a personal message to the caller over a voice channel. The caller may be given a personal notification, as a spoken audio message that includes the callers's name, advising the caller that a personal message is forthcoming and requesting that the caller stand by to receive the personal message. The subscriber enters the personal message as text, which is transmitted over a data channel to the call management system. The call management system converts the text message into speech, and then "reads" the message as a spoken, audio message to the caller, using the voice channel over which the call was received by the call management system. US Patent No. 6,724,872 discloses a method and system for delivering personalized messages to a calling party who calls a called party who is engaged in an Internet session over a telephone line not capable of receiving telephone calls without interrupting the Internet connection. The called party receives a notification on her computer screen of an incoming telephone call from a calling party. A drop box on the called party's computer temporarily interrupts the called party and identifies the calling party. The called party may answer the call, forward the call to a separate telephone number, place the call on hold, send the call to voice mail, or type, select or record a personalized message that is delivered to the calling party without interrupting the Internet session.

    BRIEF DESCRIPTION OF THE DRAWINGS



    [0005] 

    Figure 1 is a block diagram of an active mobile collaboration (AMC) system, under an embodiment.

    Figure 2 is a block diagram of a communications system that includes an AMC system, under an alternative embodiment.

    Figure 3 is a block diagram of a communications system that includes an AMC system, under another alternative embodiment.

    Figure 4 is a flow diagram of call notification with rich caller ID, under an embodiment.

    Figure 5 is a flow diagram for call notification of the AMC system, under an embodiment.

    Figure 6 is a flow diagram for call notification of the AMC system, under an embodiment.

    Figure 7 is a call flow diagram for acceptance of a call at a client device, under an embodiment.

    Figure 8 is a call flow for acceptance of a call at an enterprise telephone, under an embodiment.

    Figure 9 is a call flow for forwarding or delaying a call, under an embodiment.

    Figure 10 is a block diagram of an AMC system, under an alternative embodiment.

    Figure 11 is a block diagram of an AMC system, under another alternative embodiment.

    Figure 12 is a block diagram of an AMC system, under yet another alternative embodiment.

    Figure 13 is a block diagram of an AMC system in an enterprise domain, under another alternative embodiment.

    Figure 14 is a block diagram of an AMC system in a public domain coupled across components of an enterprise domain, under another alternative embodiment.

    Figure 15 is a block diagram of an AMC system in an enterprise domain, under still another alternative embodiment.

    Figure 16 is a block diagram of an active mobile collaboration (AMC) system, under an embodiment.


    DETAILED DESCRIPTION



    [0006] The present invention is set-out in the appended claims. Communication systems and methods are described that include call notification with rich caller identification (ID). Components of the communication systems and methods (collectively referred to herein as "communication systems") are configured to receive a call for a user via an enterprise voice channel. A call request is automatically generated in response to event data of the received call. The call request includes caller data from enterprise databases or directories. The caller data provides identifying information of the caller to the user via the call request. The call request can include response options by which the user can participate in the call. The call request is routed to an active client device of the user via a data channel. 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.

    [0007] The call request is sent to the client device over a data channel so that an enterprise voice port is not required to "ring" or notify the target device. This reduces voice port usage within the enterprise because the use of the data channel means that every desk call does not require an additional voice port; instead, only the small fraction of calls that are accepted or forwarded dynamically from the target device require the use of an additional voice port.

    [0008] The client device in response to the call request displays a notification message (e.g., pop-up message, appropriate ring tone, etc.) alerting the user of the call request and displaying the caller identifying information. The client device also provides the user with multiple action or response options via the call request. The response options include for example accepting the call, delaying the call, forwarding the call, ignoring the call, and ignoring the caller as described in detail below.

    [0009] In 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.

    [0010] The 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.

    [0011] The 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.

    [0012] The 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), 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.

    [0013] Figure 1 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.

    [0014] The 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.

    [0015] The communication devices 101 described herein include processor-based electronic devices, for example, cellular telephones, personal computers, portable computing devices, 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, and desktop clients 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.

    [0016] As 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).

    [0017] The 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 (also referred to herein as a carrier or mobile network operator), 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), wireless LANS, cellular networks, 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).

    [0018] Figure 2 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.

    [0019] The 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.

    [0020] The 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.

    [0021] An 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).

    [0022] Components 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.

    [0023] In 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.

    [0024] There 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.

    [0025] If 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.

    [0026] In 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.

    [0027] Authentication 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.

    [0028] While 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.

    [0029] Figure 3 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.

    [0030] The 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.

    [0031] The 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.

    [0032] The 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.

    [0033] Communications 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.

    [0034] A 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.

    [0035] The AMC system of an embodiment includes an Active Call Request (call request) that generally allows a caller to politely ask a receiver if the receiver can take or is ready to take a phone call, and provides discreet response options by which the receiver can provide timely feedback to the caller. Callers have the satisfaction of knowing the receiver acknowledged their call request and will make time to talk. When a call request is initiated in the AMC system, the facilitator for example monitors the call request. When the call request is delivered successfully, the facilitator sends the caller a delivery confirmation. If the user to whom the call request is addressed is not reachable (e.g., off the mobile network) the facilitator queues the request and, if applicable based on type and expiration, delivers it as soon as possible. The Active Call Request further provides discreet response options by which the recipient can provide timely feedback to the caller or originator of a communication relating to the call request.

    [0036] The AMC system of an embodiment uses the call request described above and in the Related Applications in providing call notification with rich caller ID. As an example, Figure 4 is a flow diagram of call notification with rich caller ID 400, under an embodiment. Call event data is received 402 in response to a call received from a caller via a voice channel of an enterprise. The call is an attempt by the caller to reach an AMC user or subscriber. A call request is automatically generated 404 in response to event data of the received call. The call request includes caller data from enterprise databases or directories. The caller data provides identifying information of the caller to the user via the call request. The call request can include response options by which the user can participate in the call. The call request is routed 406 to a target device of the user via a data channel of the host enterprise. The target device provides the user with multiple action or response options via the call request. The response options include for example accepting the call, delaying the call, forwarding the call, ignoring the call, and ignoring the caller as described in detail below. Consequently, the call notification described herein overcomes limitations inherent in conventional enterprise telephone systems.

    [0037] Conventional telephone systems (e.g., PBXs) include call forwarding and simultaneous ring features that enable users to know about their enterprise calls while they are away from their desk. Call forwarding enables a user to forward calls from his/her desk telephone to another telephone of their choice. The simultaneous ring feature rings two or more telephones in parallel, and the user may pick up any of these telephones to answer the call. These features are primarily used by mobile professionals to notify them via their cellular telephones of their desk calls while they are out of the office.

    [0038] The conventional call forwarding and simultaneous ring features are limited however in providing complete communication solutions to mobile professionals. For example, a forwarded call or simultaneously ringing call can be answered by a person other than the user. Therefore, a call forwarded or simultaneously ringing a user's desk telephone and home telephone can be answered by another person (e.g., spouse, child, co-worker, visitor, roommate, friend, etc.), requiring the answering person to take a message or otherwise convey the call to the intended recipient.

    [0039] As another example, a forwarded or simultaneously ringing call in conventional telephony can be answered by an external entity. A call forwarded to the user's home telephone or cellular telephone, or simultaneously ringing the desk and home or cellular telephones, may be answered first by either the home or cellular telephone's answering machine or voicemail service. This results in voicemails being stored in multiple different locations (e.g., enterprise voicemail, home voicemail, cellular telephone voicemail, etc.) making it difficult for the user to quickly and easily know about and/or retrieve voicemail at all possible locations.

    [0040] As yet another example, caller ID at the conventional device receiving a call is based on the phonebook or contact information available to that target or receiving device. Therefore, if a call is forwarded or simultaneously rings a client device, the client device attempts to map the telephone number to a name based on the phonebook of the client device. Due to memory and other restrictions, the phonebook of a mobile or remote device is generally relatively smaller than the telephone number directories available within an enterprise (e.g., corporate directories, directory servers, electronic mail servers, customer relationship management (CRM) systems, human resource systems, financial systems, personal Exchange/Outlook contacts, etc.). Therefore, the chance of missing caller ID information is significant in conventional systems.

    [0041] Additionally, simultaneous ring requires the use of two or more voice ports (depending on the number of lines to ring simultaneously). As the number of voice ports used reaches the maximum capacity for a host enterprise, other calls may be blocked, and may require costly upgrades to the enterprise to support additional voice ports.

    [0042] The AMC system of an embodiment provides call notification to overcome deficiencies with call forwarding and simultaneous ringing. Figure 5 is a flow diagram for call notification 500 of the AMC system, under an embodiment. Under call notification, the AMC user logs into the AMC system using his/her active client device. The facilitator then registers with the enterprise telephone system, the enterprise PBX for example, requesting the facilitator to send call events for the user's enterprise telephone line to the user's client device.

    [0043] In call notification operations of an embodiment, when a caller places a call to the user's desk telephone, the PBX rings 1 the user's desk telephone and simultaneously sends a call event 2 to the facilitator. The desk telephone of the user can be, for example, a telephone coupled to an enterprise telephone system, or a telephone coupled to a central exchange (centrex) that provides telephone services to the enterprise. The facilitator transforms the call event information into an AMC call request by constructing a rich caller ID as described herein. The facilitator transfers or sends 3 the call request including the rich caller ID to the user's active client device. The AMC client hosted on the client device receives the call request and in response controls display of information of the call request (e.g., pop-up message, ring tone, etc.) alerting the user of the call request and displays the rich caller ID information. The call request includes information of numerous and varied response options available to the user for dealing with the incoming call. The response options of an embodiment can be presented and/or selected via numerous interfaces (e.g., cursor selection, drop-down menu, pop-up windows, text input, audio input, etc.). When for example the user selects the option of accepting or taking the call at his/her client device, the facilitator controls or instructs the PBX receiving the call to extend or transfer 5 the call to the user's client device. Upon completion of the call between the AMC user and the caller, the client and server synchronize call logs, blacklists and other state information.

    [0044] The facilitator transfers or sends the call request to the client device over a data channel so that an enterprise voice port is not required to ring the mobile telephone. This reduces voice port usage within the enterprise because the use of the data channel means that every incoming desk call does not require an additional voice port; instead, only a small fraction of calls that are accepted or re-directed dynamically to a number external to the enterprise from the client device require the use of an additional voice port.

    [0045] Because the call notification of an embodiment does not actually utilize the cellular voice channel of the client device initially, the call notification reduces or eliminates the chances of an accidental transfer of the call to the carrier's voicemail. Unlike static forwarding rules, the user can dynamically forward calls as appropriate, so there is less chance of someone else picking up the call.

    [0046] Call requests and responses can be exchanged between the facilitator and the client device using a number of protocols, including data synchronization and session initiation protocol (SIP); different types of call requests may be exchanged using different protocols. Figure 5 is a flow diagram for call notification 500 of the AMC system, using the synchronization embodiment for call requests and responses. Figure 6 is a flow diagram for call notification 600 of the AMC system, using the SIP embodiment for call requests and responses, under an embodiment. The facilitator provides call notifications including the SIP message as described above with reference to Figure 5. Furthermore, the AMC user can respond to the SIP message as described above with reference to Figure 5.

    [0047] The AMC system of an embodiment provides the user with multiple action or response options at the client device. The action options include but are not limited to accepting the call, re-directing the call to another phone number, delaying or postponing the call, ignoring the call, and blacklisting the caller. Each of the action options are described below.

    [0048] When receiving at his/her client device a call request corresponding to an incoming call, a user can "accept" the call, which indicates that the user wants the call extended or transferred to the client device. Generally, when the user selects via the client device this response option, the facilitator instructs or controls the PBX to extend or transfer the call as described above. Although the signaling was done over the data channel, the media for the call can be extended over either a cellular voice channel or a IP-based data channel (e.g., RTP stream), based on the device capabilities, current network access, and/or QoS needs.

    [0049] When the user accepts the call, the call is transferred to the active client device. The user then participates in the transferred call using the active client device. Figure 7 is a call flow 700 for acceptance of a call at a client device under the SIP protocol, under an embodiment. This call flow 700 is presented as an example call flow 700 and does not limit the call acceptance described herein to only this call flow 700. In response to receipt of a call, the PBX sends a call event (e.g., 1.0 call "ring" event) to the facilitator. The facilitator generates and sends an invitation message to the client (e.g., 1.1 INVITE) hosted on the client device, and a response (e.g., 1.2 RINGING) is returned to the facilitator from the client. The client device plays an audio ringtone on the device, to simulate the ring of an incoming call. In parallel, the facilitator searches enterprise directories using the telephone number of the caller (e.g., 1.3 search for phone number) and, if the caller is found in the directories, the directories return detailed information of a matching contact (e.g., 1.4 returning matching contacts, if any). The facilitator sends a call notification to the client (e.g., 1.5 UPDATE) with the rich caller ID and response options, and a response (e.g., 1.6 OK) is returned to the facilitator from the client. The UPDATE is an optimization and this information can be included in the original INVITE message. The client waits for a user response at the client device (e.g., 1.7 wait for user response). In response to a user selection of a response option, the client sends a message (e.g., 1.8 OK) to the facilitator with information of the user selection. The client then waits for the call to be extended to the device phone number, and, while waiting for this incoming call, displays a call notification prompt at the client device (e.g., 1.9 invoke "waiting to transfer call" audio and visual).

    [0050] If the incoming call is answered at the enterprise desk telephone belonging to the user or sent to enterprise voicemail prior to receipt at the facilitator of a user-selected 'acceptance' response option (e.g., 1.8 OK), the facilitator notifies the client of this condition (e.g., 1.10). The client in turn discontinues the audio and visual indicators of the call notification at the client device (e.g., 1.11 stop audio/visual), and synchronizes call logs (e.g., 1.22 initiate SYNC for AC_REQ), which indicates that the call was picked up at the desk phone or diverted to the corporate voicemail system.

    [0051] If the acceptance response is received by the facilitator prior to the incoming call being answered at the enterprise desk telephone belonging to the user or sent to enterprise voicemail, the facilitator instructs the PBX to extend or transfer the call to the client device phone number (e.g., 1.12 "transfer" call (if ACK sent)). The PBX sets up a call leg with the client device via a voice channel (e.g., 1.13 call leg setup (if ACK sent)) (e.g., cellular voice channel), but not so limited. When the call is extended to the client device, the device platform API generates a call event (e.g., 1.14 call event) that is received by the client application. In response to this call event, the client automatically answers the call and stops the appropriate audio/visual transfer indication (e.g., 1.15 auto-answer call; stop "transfer" audio/visual).

    [0052] To convey to the facilitator that the call was indeed answered by the mobile device, and not sent to the corresponding mobile network operator voicemail, the client device generates and sends a dual-tone multi-frequency (DTMF) signal to the PBX (e.g., 1.16 generate in-band DTMF). The client device sends a DTMF signal to the PBX (e.g., 1.17 send "1" as DTMF) and the PBX in turn relays the DTMF to the facilitator (e.g., 1.18 relay DTMF). The facilitator instructs the PBX to connect the call legs (e.g., 1.19 join incoming call leg) upon receipt of the DTMF.

    [0053] Upon completion of the transferred voice call, the client device sends a message to the facilitator (e.g., 1.20 BYE (after voice call finished)), and the facilitator acknowledges (e.g., 1.21 OK (for BYE)). The facilitator then initiates synchronization of call logs and other state information (e.g., 1.22 initiate SYNC for AC_REQ).

    [0054] If the facilitator does not receive the DTMF signal within a specific time, it instructs the PBX to drop the call leg to the mobile line and to send the original call to the corporate voicemail system.

    [0055] In an alternative embodiment, the facilitator can instruct the PBX to extend the call to the mobile line immediately after the response (e.g., 1.6 OK) is returned to the facilitator from the client. In this embodiment, the facilitator can instruct the PBX to drop this call leg extension if the user does not affirmatively respond under with selection of a response option (e.g., 1.8 OK) or if the call is picked up at the desk phone or sent to corporate voicemail.

    [0056] When receiving at his/her client device a call request corresponding to an incoming call, a user located at his/her desk can alternatively answer the incoming call at his/her enterprise telephone instead of responding to the call request on the client device. Figure 8 is a call flow 800 for acceptance of a call at an enterprise telephone, under an embodiment. This call flow 800 is presented as an example call flow 800 and does not limit the call notification described herein to only this call flow 800. In response to receipt of a call, the PBX sends a call event (e.g., 1.0 call "ring" event) to the facilitator. The facilitator generates and sends an invitation message to the client (e.g., 1.1 INVITE) hosted on the client device, and a response (e.g., 1.2 RINGING) is returned to the facilitator from the client. The facilitator sends a call notification to the client (e.g., 1.3 UPDATE) with the rich caller ID and response options, and a response (e.g., 1.4 OK (for UPDATE)) is returned to the facilitator from the client.

    [0057] In response to the user taking the incoming call at his/her enterprise telephone, the PBX sends an event message to the facilitator indicating acceptance of the call at the enterprise telephone (e.g., 1.5 call "accept" event). The facilitator notifies the client by canceling the call notification (e.g., 1.6 CANCEL), and a response (e.g., 1.7 Response) is returned to the facilitator from the client. The facilitator sends an acknowledgement message to the client device (e.g., 1.8 for 487 response). The facilitator then initiates synchronization of call logs and other state information (e.g., 1.9 initiate SYNC for AC_REQ).

    [0058] When the user selects at the client device the option to re-direct or forward the call, the AMC system of an embodiment enables the user to select dynamic forwarding of the call to a device corresponding to another telephone number. The selection of dynamic re-directing by the user can include use of a forwarding number selected from a list of predefined user-specified forwarding numbers (e.g., hotel number, home number, another mobile phone number, etc.). Additionally, the dynamic forwarding includes the use of any number entered by the user, for example, via the client device. The facilitator, in response to receiving a selected or inputted number from the client, re-directs the call to the device corresponding to the selected forwarding telephone number.

    [0059] When the user selects at the client device the option to delay the call, the caller is verbally notified by the facilitator that the user is busy and that the user will call back at a later time; the later time for call back can be specified by the facilitator. The caller may or may not be permitted to leave a voicemail message, depending on the user's settings. When a callback time is specified by the facilitator, the facilitator forwards a postponement reminder to the user at the appropriate time; the postponement reminder reminds the user to call back the original caller. When allowing the user to select times for participating in a delayed call, as an additional feature, the facilitator may only show future times for which both parties are free, if possible, based on the (shared) calendars in the AMC system.

    [0060] Figure 9 is a call flow 900 for re-directing and postponing a call, under an embodiment. This call flow 900 is presented as an example call flow 900 and does not limit the call transfer or delay described herein to only this call flow 900. In response to receipt of a call, the PBX sends a call event (e.g., 1.0 call "ring" event) to the facilitator. The facilitator generates and sends an invitation message to the client (e.g., 1.1 INVITE) hosted on the client device, and a response (e.g., 1.2 RINGING) is returned to the facilitator from the client. The facilitator sends a call notification to the client (e.g., 1.3 UPDATE) with the rich caller ID and response options, and a response (e.g., 1.4 OK (for UPDATE)) is returned to the facilitator from the client.

    [0061] In response to a user selection of a response option, the client sends a message (e.g., 1.5 Transfer (in case of re-directing) or Postpone) to the facilitator with information of the user selection. The facilitator sends an acknowledgement message to the client device (e.g., 1.6 ACK (for postpone or transfer response).

    [0062] When the user response is to re-direct the incoming call to a third-party telephone number, the facilitator instructs the PBX to transfer the call (e.g., 1.7 call transfer (if transfer)). The PBX then transfers the call to a third-party telephone (e.g., 1.8 call transfer).

    [0063] When the user response is to postpone the incoming call until a later time, the facilitator plays audio prompts to the caller via the PBX (e.g., 1.9 play prompts to caller; hang up (if postponement)). The prompts include verbal notification that the user will call back at a future time, or verbal notification of future time(s) when the caller may attempt to call the user. The facilitator then initiates synchronization of call logs and other state information (e.g., 1.10 initiate SYNC for AC_REQ). The call log would indicate the postponement time, so the client can pop up a reminder at the appropriate time.

    [0064] A user deciding to ignore an incoming call can do nothing in response to the call request corresponding to the incoming call. If the user does nothing within a pre-specified time period, the call is routed to the enterprise voicemail. The time period for responding to a call request is programmable and can be selected by the user or administrator.

    [0065] When deciding to blacklist a caller associated with an incoming call, and depending on the user's settings under the AMC system, the incoming call is immediately forwarded to the enterprise voicemail or never answered. Furthermore, future calls from this caller do not ring the user's enterprise desk telephone or result in generation of a call request. The user may view his/her ignore list or blacklist and remove items from the list using either of the client device and/or the user portal of the AMC system.

    [0066] If the caller terminates the call before the call is accepted or re-directed by the user, the facilitator of an embodiment initiates a return call to the original caller in order to connect the original caller with the AMC user. Under a scenario in which the AMC user decides to delay the call, and the caller terminates the call before the call is delayed by the user, the facilitator calls the original caller and plays a computer-generated audio message indicating a call back time for the caller to consider in reattempting contact with the AMC user. If the callback time is not acceptable to the caller, the facilitator of an embodiment provides the caller with a list of times at which the AMC user should be available to take the call, thereby enabling the caller to choose an acceptable alternative call time; the facilitator also sets the user's postponement reminder to expire at this alternative time.

    [0067] 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 caller data) that identify the caller to the AMC user and provide additional context to help the user in deciding if and/or when to participate in the call. The rich caller ID is generated by mapping the telephone number of the caller (e.g., received as caller ID with the incoming call) to a contact within the directories of the host enterprise. 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 caller 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.

    [0068] In addition to the information automatically received or gathered from the host enterprise, the facilitator can add additional caller 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.).

    [0069] Call screening is an extension of the call notification of an embodiment. The call screening is an extension for which the call notification includes additional information beyond that of the rich caller ID described above. The additional information of an embodiment is supplied by the caller but is not so limited. In one configuration, the additional information is generated by the caller using an input/output device of his/her calling device (e.g., telephone keypad, microphone, touchscreen display, etc.) to input a message that is included in the rich caller ID. In another configuration, the caller selects from a menu (e.g., an interactive voice response (IVR) menu) a short subject to best describe the call context. In yet another configuration the caller records a short audio subject that is included in the call notification, and the AMC user can play the audio message before taking an action. In another alternative or additional configuration, and as a component of the call notification, the facilitator streams a voicemail recording to the AMC user, as it is being recorded; the AMC user may take an action pertaining to the call notification based on this streamed audio.

    [0070] When a user participates in a call using a client device that includes the AMC client, the client automatically answers the transferred call as described above, so the user is not required to "answer" the call twice. However, occasionally, the transferred call may not ring the client device but instead goes directly to the client device voicemail. To ensure the transferred call is answered by client device and not directed to the voicemail of the client device service provider, the facilitator is configured to expect receipt of a DTMF signal or sequence (e.g., "1" tone) from the AMC client when the client auto-answers the call. If the DTMF signal is not sent by the client and/or received by the facilitator within a certain period (e.g., ten (10) seconds) after the call is answered by the client, the facilitator assumes the call went to voicemail of the client device and disconnects the transferred call. Simultaneous with or following disconnection of the transferred call to the client device, the facilitator routes the transferred call to the enterprise voicemail.

    [0071] Additionally, the AMC client is configured to prevent the client from auto-answering an intervening call that is not the transferred call when the user has selected the option to accept the incoming call. An intervening call as referred to herein is a call that arrives at the client device during a period that begins when a call request is answered by the user (via selection of a response option of the call request) and ends when the transferred call is transferred to the client device. After the user accepts via the call request response options an incoming call, there is a short period before the client device actually rings and the voice channel can be established. Because the AMC client automatically answers the call to enable a better user experience, it is possible for another call to arrive and automatically answered during this intervening period. The AMC client of an embodiment is configured to differentiate between an intervening call and an accepted call by automatically declining the intervening call while waiting for the accepted call.

    [0072] To ensure the client auto-answers the correct call (transferred call), the client of an embodiment determines if the incoming caller automatic number identification (ANI) matches that of the enterprise PBX expected to extend or transfer calls to the client device. When the client determines that a match exists between the PBX expected to transfer the call and the ANI of the incoming call, the client auto-answers the call.

    [0073] The ANI of the calling PBX may not, however, be constant within a large organization depending on which PBX generated the outgoing call (e.g., depending on dial plan rules and organization PBX deployments). Therefore, in an alternative embodiment, the client automatically answers the first incoming call following acceptance of a call, and expects a DTMF signal or sequence as a handshake signal from the facilitator. The client auto-answers the incoming call upon receipt of an expected DTMF signal. If the client does not receive or detect the expected DTMF signal within a pre-specified period, the client terminates the call and auto-answers the next incoming call.

    [0074] The call notification of an embodiment includes profile-based call requests as described herein. In addition to ignore lists or blacklists, the facilitator can use availability and presence information corresponding to the user to determine whether to generate a call notification request and to ring the user's enterprise desk telephone. For example, if the availability and presence information indicates the user is "not available for voice calls", the call request is not generated but, instead, the call is immediately routed to voicemail. A caller priority list may override this profile-based decision for a select number of callers designated as high-priority callers by the user.

    [0075] The facilitator of an embodiment includes or couples to an automatic call distributor (ACD) to route calls to numerous and/or different people based on one or more algorithms. This mobile ACD of an embodiment distributes the call notification to one or more AMC users according to a routing algorithm. Therefore, while call notification maps a single telephone line to a single user, mobile ACD dynamically maps a single telephone line to one or more users and routes the call notification to one user for each call. The mobile ACD can include a provision that routes the call sequentially from the "best" user (e.g., based on rule-based routing described below), to the second best user, then to the Nth best user, until a person accepts the call notification. The mobile ACD allows for user responses including accepting, delaying, forwarding, and ignoring call notification requests in determining routing for each call as described above. Additionally, the call may first be answered by an IVR system to enable the caller to enter additional information that can help route the call request(s) accordingly.

    [0076] As an alternative, the mobile ACD of an embodiment can leverage the ACD functionality of the host enterprise PBX. In so doing, once a call is routed to an enterprise desk telephone of the user, the call notification of an embodiment sends the call request to the user's active client device, thus enabling the user to handle the call in real time while outside the enterprise.

    [0077] The 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 Figure 3. 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 generation and routing of call requests as described herein. 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.

    [0078] The call request routing described above includes rule-based routing. The rules of rule-based routing 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 includes the use of rules that can be customized. 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 request routing.

    [0079] The call request 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 request to all selected users. Parallel routing can also include a first routing of the call request to at least one target device of a first set of users simultaneous with a second routing of the call request to at least one target device of a second set of users.

    [0080] Sequential routing includes sequential routing to each of a selected set of users. For example, the sequential routing includes a first routing of the call request to a first target device of a first user, and a second or subsequent routing of the call request to a second target device of a second user 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 request routing. As another example, the sequential routing includes a first routing of the call request to at least one target device of a first set of users, and a second routing of the call request to at least one target device of a second set of users in response to a trigger condition (e.g., elapsed time, the absence of the response message to the first routing, etc.).

    [0081] Combined parallel and sequential routing includes parallel routing to a first set of users, and sequential routing to each of a second set of users. Similarly, the combined parallel and sequential routing includes sequential routing to each of a first set of users, and parallel routing to a second set of users. Additionally, the combined parallel and sequential routing includes parallel routing to a first set of users followed sequentially by parallel routing to a second set of users.

    [0082] Some examples follow of alternative AMC system configurations that include the facilitator and client described above. Figure 10 is a block diagram of an AMC system 1000, under an alternative embodiment. The AMC system 1000 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.

    [0083] Figure 11 is a block diagram of an AMC system 1100, under another alternative embodiment. The AMC system 1100 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.

    [0084] Figure 12 is a block diagram of an AMC system 1200, under yet another alternative embodiment. The AMC system 1200 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.

    [0085] Figure 13 is a block diagram of an AMC system 1300 in an enterprise domain, under another alternative embodiment. The AMC system 1300 includes a server hosting the facilitator 102 where the server/facilitator 102 is a component of a corporate or enterprise infrastructure 1302. The server can host numerous additional applications 1306 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 1304 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 1302 to provide AMC system functions among the client devices 101E as described below. The client devices 101E in the enterprise domain 1302 are shown coupled to one or more LANs, but are not so limited.

    [0086] Figure 14 is a block diagram of an AMC system 1450 in a public domain coupled across components of an enterprise domain, under another alternative embodiment. The AMC system 1450 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 1404 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 1402 including, for example, one or more client devices 101E, one or more enterprise servers 1408, 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 1402 are shown coupled to one or more LANs, but are not so limited.

    [0087] As an alternative to the couplings of this AMC system 1400, 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.

    [0088] Figure 15 is a block diagram of an AMC system 1500 in an enterprise domain, under still another alternative embodiment. The AMC system 1500 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.

    [0089] Figure 16 is a block diagram of an active mobile collaboration (AMC) system 1600, under an embodiment. The AMC system 1600 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.

    [0090] The 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.

    [0091] Aspects 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.

    [0092] It 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.

    [0093] Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of 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.

    [0094] Unless 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.


    Claims

    1. A method comprising:

    receiving (402) call event data at a server from an enterprise Private Branch Exchange, PBX, in response to a call to a telephone assigned to a user received from a caller via an enterprise voice channel by the PBX;

    the server generating (404) a call request responsive to receiving the call event data, the call request comprising caller data including caller data of databases of the enterprise, and a plurality of call response options for participating in the call;

    the server:

    i) routing (406) the call request via an enterprise data channel to a target device designated by the user;

    ii) instructing the PBX to transfer the call to the target device, when the user selects the option of accepting the call at the target device; and

    iii) cancelling the call request by sending a notification to the target device via the enterprise data channel responsive to determining that the call was answered at the telephone prior to receipt at the server of a user-selected call response option of accepting the call at the target device.


     
    2. The method of claim 1, comprising displaying the plurality of call response options at the target device.
     
    3. The method of claim 1, comprising automatically answering the call at the target device.
     
    4. The method of claim 1, comprising:

    detecting termination of the call prior to the accepting; and

    initiating a return call to the caller via the voice channel.


     
    5. The method of claim 4, comprising transferring the return call to the target device via a voice channel.
     
    6. The method of claim 1, wherein the plurality of call response options include postponing the call.
     
    7. The method of claim 6, comprising the server notifying the caller that the user to whom the call is directed is unavailable to accept the call responsive to receiving the response option postponing the call.
     
    8. The method of claim 7, comprising directing the call to a voicemail box of the user.
     
    9. The method of claim 7, wherein the notifying includes specifying a future time at which the user will be available to accept the call.
     
    10. The method of claim 9, comprising:

    generating a reminder message of the call in response to the postponing, wherein the reminder message includes the future time; and

    transferring the reminder message to a target device of the user.


     
    11. The method of claim 9, comprising receiving a selection of the future time from one or more of the caller and the user.
     
    12. The method of claim 9, comprising prompting one or more of the caller and the user for the future time.
     
    13. The method of claim 6, comprising:

    detecting termination of the call prior to the postponing; and

    initiating a return call to the caller via the voice channel.


     
    14. The method of claim 13, comprising playing a message during the return call, the message specifying a future time at which the user will be available to accept the call.
     
    15. The method of claim 14, comprising receiving a selection of an alternative future time from the caller during the return call.
     
    16. The method of claim 15, comprising:

    generating a reminder message of the call in response to the postponing, wherein the reminder message includes one or more of the future time and the alternative future time; and

    transferring the reminder message to the target device of the user.


     
    17. The method of claim 1, wherein the plurality of call response options include forward the call.
     
    18. The method of claim 17, wherein the forwarding comprises dynamically forwarding the call to a forwarding telephone number of the user via the voice channel responsive to receiving the response option forward the call.
     
    19. The method of claim 18, comprising receiving the forwarding telephone number from the user.
     
    20. The method of claim 19, wherein the receiving comprises:

    transferring to the target device of the user a set of telephone numbers including the forwarding telephone number; and

    receiving data of a selection from the target device, wherein the data of the selection includes the forwarding telephone number.


     
    21. The method of claim 19, wherein the receiving includes:

    prompting the user at the target device for the forwarding telephone number; and

    receiving data of the user input from the target device, wherein the data of the user input includes the forwarding telephone number.


     
    22. The method of claim 18, comprising:

    detecting termination of the call prior to the forwarding; and

    initiating a return call to the caller via the voice channel.


     
    23. The method of claim 22, comprising transferring the return call to the target device of the user via a voice channel and the forwarding telephone number.
     
    24. The method of claim 1, wherein the plurality of call response options include ignoring the call.
     
    25. The method of claim 24, comprising directing the call to a voicemail box of the user.
     
    26. The method of claim 1, wherein the plurality of call response options include designating the caller as an ignored caller.
     
    27. The method of claim 26, comprising directing the call to a voicemail box of the user.
     
    28. The method of claim 26, comprising ignoring the call.
     
    29. The method of claim 26, comprising ignoring a future call from the ignored caller.
     
    30. The method of claim 1, wherein caller data includes one or more of a name, address, telephone number, electronic mail address, employer, and job of the caller.
     
    31. The method of claim 1, wherein caller data includes personal data of the caller, the personal data comprising data of one or more of a spouse, relative, child, anniversary, and birthday of the caller.
     
    32. The method of claim 1, wherein caller data includes one or more of data of at least one interaction between the caller and the user.
     
    33. The method of claim 1, wherein the caller data includes screening data received from the caller.
     
    34. The method of claim 33, wherein the screening data includes one or more of data input by the caller and pre-specified data selected by the caller.
     
    35. The method of claim 34, wherein the screening data includes audio data recorded by the caller.
     
    36. The method of claim 34, wherein the screening data includes a voicemail message.
     
    37. The method of claim 36, comprising streaming the voicemail message to the user.
     
    38. The method of claim 1, wherein the routing includes distributed routing of the call request to at least one other target device of at least one other user, wherein the distributed routing includes one or more of routing to the at least one other user instead of the routing to the user and routing to the at least one other user in addition to the routing to the user.
     
    39. The method of claim 38, wherein the distributed routing includes parallel routing to a plurality of other users.
     
    40. The method of claim 39, wherein the distributed routing includes:

    a first routing of the call request to at least one target device of a first set of other users; and

    a second routing of the call request to at least one target device of a second set of other users.


     
    41. The method of claim 38, wherein the distributed routing is sequential routing to each of a plurality of other users.
     
    42. The method of claim 41, comprising determining a hierarchy of the routing, wherein the hierarchy defines an order of the routing to the plurality of other users.
     
    43. The method of claim 38, wherein the distributed routing comprises:

    parallel routing to a first plurality of other users; and

    sequential routing to each of a second plurality of other users.


     
    44. The method of claim 38, wherein the distributed routing includes routing according to availability of the resource, wherein the availability includes one or more of presence of the resource, reachable status of the resource, availability determined by a host system, and availability specified by the resource.
     
    45. The method of claim 1, wherein the plurality of call response options include generating a return data message to the caller including at least one of a text message and a voice message.
     
    46. The method of claim 1, wherein routing the call request includes routing in accordance with context information, the context information including at least one of a connectivity state and an availability profile of the target device of the user.
     
    47. The method of claim 46, where the connectivity state includes information of a state of connectivity of the target device to a communication network.
     
    48. The method of claim 46, wherein the connectivity state includes at least one of a reachable state and an unreachable state, wherein the target device is in a reachable state when the target device is in a powered state and connected to a corresponding communication network, wherein the target device is in an unreachable state when the target device is one or more of in an un-powered state, disconnected from the communication network, and engaged in a voice call.
     
    49. The method of claim 1, comprising transferring context information of the user to the caller, wherein the context information includes at least one of presence information and a current availability state of a target device of the user.
     
    50. The method of claim 1, wherein the call request is a data message that includes one or more of a text message and a voice message.
     
    51. The method of claim 1, wherein the target device includes one or more of a cellular telephone, mobile device, wireless device, wireline device, voice over Internet Protocol, VOIP, device, private branch exchange device, soft client, and desktop client.
     
    52. The method of claim 1, wherein one or more of the voice channel and the data channel is hosted by one or more of the enterprise, a service provider, and a mobile network operator.
     
    53. The method of claim 1, comprising transferring media to the target device of the user via one or more of the voice channel and the data channel.
     
    54. A system comprising:

    an enterprise Private Branch Exchange, PBX;

    a server coupled to the enterprise PBX and at least one communication network;

    a telephone assigned to a user; and

    a target device designated by the user;

    wherein the server is configured to:

    receive call event data from the PBX in response to a call to the telephone of the user received from a caller via an enterprise voice channel by the PBX;

    generate a call request responsive to receiving the call event data, the call request comprising caller data, including caller data of databases of the enterprise, and a plurality of call response options for participating in the call;

    route the call request to the target device via an enterprise data channel;

    instruct the PBX to transfer the call to the target device, when the user selects the option of accepting the call at the target device; and

    cancel the call request by sending a notification to the target device via the enterprise data channel responsive to determining that the received call was

    answered at the telephone prior to receipt at the server of a user-selected call response option of accepting the call at the target device.


     
    55. The system of claim 54, further comprising means for performing a method as claimed in any of claims 1 to 53.
     
    56. A computer readable media including executable instructions which, when executed by a processing system, provides a method according to the method of any one of claims 1 to 53.
     


    Ansprüche

    1. Verfahren, das Folgendes umfasst:

    Empfangen (402) von Anrufereignisdaten an einem Server von einer privaten Nebenstellenanlage (NStAnl) eines Unternehmens als Reaktion auf einen Anruf an ein Telefon, das einem Benutzer zugewiesen ist, der von einem Anrufer über einen Unternehmenssprachkanal von der NStAnl empfangen wurde;

    wobei der Server eine Anrufanforderung erzeugt (404), die auf den Empfang der Anrufereignisdaten reagiert, wobei die Anrufanforderung Anruferdaten einschließlich Anruferdaten von Datenbanken des Unternehmens und eine Vielzahl von Anrufantwortoptionen zur Teilnahme an dem Anruf umfasst;

    wobei der Server:

    i) die Anrufanforderung über einen Unternehmensdatenkanal an eine vom Benutzer bestimmte Zielvorrichtung weiterleitet (406);

    ii) die NStAnl anweist, den Anruf an die Zielvorrichtung weiterzuleiten, wenn der Benutzer die Option zum Annehmen des Anrufs an der Zielvorrichtung auswählt; und

    iii) die Anrufanforderung abbricht durch Senden einer Benachrichtigung an die Zielvorrichtung über den Unternehmensdatenkanal als Antwort auf die Ermittlung, dass der Anruf am Telefon beantwortet wurde, bevor auf dem Server eine vom Benutzer ausgewählte Anrufantwortoption zum Annehmen des Anrufs auf der Zielvorrichtung empfangen wurde.


     
    2. Verfahren nach Anspruch 1, das das Anzeigen der Vielzahl von Anrufantwortoptionen an der Zielvorrichtung umfasst.
     
    3. Verfahren nach Anspruch 1, das das automatische Beantworten des Anrufs an der Zielvorrichtung umfasst.
     
    4. Verfahren nach Anspruch 1, das Folgendes umfasst:

    Erkennen der Beendigung des Anrufs vor dem Annehmen; und

    Einleiten eines Rückrufs an den Anrufer über den Sprachkanal.


     
    5. Verfahren nach Anspruch 4, das das Weiterleiten des Rückrufs an die Zielvorrichtung über einen Sprachkanal umfasst.
     
    6. Verfahren nach Anspruch 1, wobei die Vielzahl von Anrufantwortoptionen das Aufschieben des Anrufs umfasst.
     
    7. Verfahren nach Anspruch 6, das umfasst, dass der Server, der den Anrufer benachrichtigt, dass der Benutzer, an den der Anruf gerichtet ist, nicht in der Lage ist, den Anruf anzunehmen, als Reaktion auf den Empfang der Antwortoption zur Aufschiebung des Anrufs.
     
    8. Verfahren nach Anspruch 7, das das Weiterleiten des Anrufs an eine Voicemail-Box des Benutzers umfasst.
     
    9. Verfahren nach Anspruch 7, wobei die Benachrichtigung das Angeben eines zukünftigen Zeitpunkts umfasst, zu dem der Benutzer verfügbar sein wird, um den Anruf anzunehmen.
     
    10. Verfahren nach Anspruch 9, das Folgendes umfasst:

    Erzeugen einer Erinnerungsnachricht des Anrufs als Antwort auf die Aufschiebung, wobei die Erinnerungsnachricht die zukünftige Zeit umfasst; und

    Übertragen der Erinnerungsnachricht an eine Zielvorrichtung des Benutzers.


     
    11. Verfahren nach Anspruch 9, das das Empfangen einer Auswahl der zukünftigen Zeit von einem oder mehreren Anrufern und dem Benutzer umfasst.
     
    12. Verfahren nach Anspruch 9, das das Auffordern eines oder mehrerer Anrufer und des Benutzers zur zukünftigen Zeit umfasst.
     
    13. Verfahren nach Anspruch 6, das Folgendes umfasst:

    Erkennen der Beendigung des Anrufs vor dem Aufschieben; und

    Einleiten eines Rückrufs an den Anrufer über den Sprachkanal.


     
    14. Verfahren nach Anspruch 13, das das Abspielen einer Nachricht während des Rückrufs umfasst, wobei die Nachricht einen zukünftigen Zeitpunkt angibt, zu dem der Benutzer verfügbar sein wird, um den Anruf anzunehmen.
     
    15. Verfahren nach Anspruch 14, das das Empfangen einer Auswahl einer alternativen zukünftigen Zeit vom Anrufer während des Rückrufs umfasst.
     
    16. Verfahren nach Anspruch 15, das Folgendes umfasst:

    Erzeugen einer Erinnerungsnachricht des Anrufs als Antwort auf die Aufschiebung, wobei die Erinnerungsnachricht die zukünftige Zeit und/oder die alternative zukünftige Zeit umfasst; und

    Übertragen der Erinnerungsnachricht an die Zielvorrichtung des Benutzers.


     
    17. Verfahren nach Anspruch 1, wobei die Vielzahl von Anrufantwortoptionen das Weiterleiten des Anrufs umfasst.
     
    18. Verfahren nach Anspruch 17, wobei das Weiterleiten das dynamische Weiterleiten des Anrufs an eine Weiterleitungstelefonnummer des Benutzers über den Sprachkanal umfasst, als Antwort auf den Empfang der Antwortoption zum Weiterleiten des Anrufs.
     
    19. Verfahren nach Anspruch 18, das das Empfangen der Weiterleitungstelefonnummer vom Benutzer umfasst.
     
    20. Verfahren nach Anspruch 19, wobei das Empfangen Folgendes umfasst:

    Übertragen eines Satzes von Telefonnummern einschließlich der Weiterleitungstelefonnummer an die Zielvorrichtung des Benutzers; und

    Empfangen von Daten einer Auswahl von der Zielvorrichtung, wobei die Daten der Auswahl die Weiterleitungstelefonnummer umfassen.


     
    21. Verfahren nach Anspruch 19, wobei das Empfangen Folgendes umfasst:

    Auffordern des Benutzers an der Zielvorrichtung zur Weiterleitung der Telefonnummer; und

    Empfangen von Daten der Benutzereingabe von der Zielvorrichtung, wobei die Daten der Benutzereingabe die Weiterleitungstelefonnummer umfassen.


     
    22. Verfahren nach Anspruch 18, das Folgendes umfasst:

    Erkennen der Beendigung des Anrufs vor der Weiterleitung; und

    Einleiten eines Rückrufs an den Anrufer über den Sprachkanal.


     
    23. Verfahren nach Anspruch 22, das das Weiterleiten des Rückrufs an die Zielvorrichtung des Benutzers über einen Sprachkanal und die Weiterleitungstelefonnummer umfasst.
     
    24. Verfahren nach Anspruch 1, wobei die Vielzahl von Anrufantwortoptionen das Ignorieren des Anrufs umfasst.
     
    25. Verfahren nach Anspruch 24, das das Weiterleiten des Anrufs an eine Voicemail-Box des Benutzers umfasst.
     
    26. Verfahren nach Anspruch 1, wobei die Vielzahl von Anrufantwortoptionen das Bestimmen des Anrufers als ignorierten Anrufer umfasst.
     
    27. Verfahren nach Anspruch 26, das das Weiterleiten des Anrufs an eine Voicemail-Box des Benutzers umfasst.
     
    28. Verfahren nach Anspruch 26, das das Ignorieren des Anrufs umfasst.
     
    29. Verfahren nach Anspruch 26, das das Ignorieren eines zukünftigen Anrufs von dem ignorierten Anrufer umfasst.
     
    30. Verfahren nach Anspruch 1, wobei Anruferdaten den Namen, die Adresse, die Telefonnummer, die E-Mail-Adresse, den Arbeitgeber und/oder den Job des Anrufers umfassen.
     
    31. Verfahren nach Anspruch 1, wobei Anruferdaten personenbezogene Daten des Anrufers umfassen, wobei die personenbezogenen Daten Daten von Folgendem umfassen: Ehepartner, Verwandter, Kind, Jahrestag und Geburtstag des Anrufers.
     
    32. Verfahren nach Anspruch 1, wobei Anruferdaten eine oder mehrere Daten von mindestens einer Interaktion zwischen dem Anrufer und dem Benutzer umfassen.
     
    33. Verfahren nach Anspruch 1, wobei die Anruferdaten Auswahldaten umfassen, die vom Anrufer empfangen wurden.
     
    34. Verfahren nach Anspruch 33, wobei die Auswahldaten vom Anrufer eingegebene Daten und/oder vom Anrufer ausgewählte vordefinierte Daten umfassen.
     
    35. Verfahren nach Anspruch 34, wobei die Auswahldaten Audiodaten umfassen, die vom Anrufer aufgezeichnet wurden.
     
    36. Verfahren nach Anspruch 34, wobei die Auswahldaten eine Voicemail-Nachricht umfassen.
     
    37. Verfahren nach Anspruch 36, das das Streamen der Voicemail-Nachricht an den Benutzer umfasst.
     
    38. Verfahren nach Anspruch 1, wobei das Routing ein verteiltes Routing der Anrufanforderung an mindestens eine andere Zielvorrichtung von mindestens einem anderen Benutzer umfasst; wobei das verteilte Routing das Routing an den mindestens einen anderen Benutzer anstelle des Routings an den Benutzer und/oder das Routing an den mindestens einen anderen Benutzer zusätzlich zum Routing an den Benutzer umfasst.
     
    39. Verfahren nach Anspruch 38, wobei das verteilte Routing ein paralleles Routing zu einer Vielzahl von anderen Benutzern umfasst.
     
    40. Verfahren nach Anspruch 39, wobei das verteilte Routing Folgendes umfasst:

    ein erstes Weiterleiten der Anrufanforderung an mindestens eine Zielvorrichtung eines ersten Satzes anderer Benutzer; und

    ein zweites Weiterleiten der Anrufanforderung an mindestens eine Zielvorrichtung eines zweiten Satzes anderer Benutzer.


     
    41. Verfahren nach Anspruch 38, wobei das verteilte Routing ein sequentielles Routing zu jedem eine Vielzahl von anderen Benutzern ist.
     
    42. Verfahren nach Anspruch 41, das das Bestimmen einer Hierarchie des Routings umfasst, wobei die Hierarchie eine Reihenfolge des Routings an die Vielzahl anderer Benutzer definiert.
     
    43. Verfahren nach Anspruch 38, wobei das verteilte Routing Folgendes umfasst:

    paralleles Routing zu einer ersten Vielzahl anderer Benutzer; und

    sequentielles Routing zu jeder zweiten Vielzahl anderer Benutzer.


     
    44. Verfahren nach Anspruch 38, wobei das verteilte Routing das Routing gemäß der Verfügbarkeit der Ressource umfasst; wobei die Verfügbarkeit Folgendes umfasst:
    Vorhandensein der Ressource, den erreichbaren Status der Ressource, die von einem Hostsystem bestimmte Verfügbarkeit und/oder die von der Ressource angegebene Verfügbarkeit.
     
    45. Verfahren nach Anspruch 1, wobei die Vielzahl von Anrufantwortoptionen das Erzeugen einer Rückgabedatennachricht an den Anrufer umfasst, die mindestens eine Textnachricht und eine Sprachnachricht umfasst.
     
    46. Verfahren nach Anspruch 1, wobei das Weiterleiten der Anrufanforderung das Weiterleiten gemäß Kontextinformationen umfasst, wobei die Kontextinformationen mindestens einen Konnektivitätsstatus und ein Verfügbarkeitsprofil der Zielvorrichtung des Benutzers umfassen.
     
    47. Verfahren nach Anspruch 46, wobei der Konnektivitätsstatus Informationen über einen Konnektivitätsstatus der Zielvorrichtung mit einem Kommunikationsnetzwerk umfasst.
     
    48. Verfahren nach Anspruch 46, wobei der Konnektivitätsstatus mindestens einen erreichbaren Zustand und einen nicht erreichbaren Zustand umfasst; wobei sich die Zielvorrichtung in einem erreichbaren Zustand befindet, wenn sich die Zielvorrichtung in einem eingeschalteten Zustand befindet und mit einem entsprechenden Kommunikationsnetzwerk verbunden ist; wobei sich die Zielvorrichtung in einem nicht erreichbaren Zustand befindet, wenn sich die Zielvorrichtung in einem ausgeschalteten Zustand befindet, vom Kommunikationsnetz getrennt ist und einen Sprachanruf tätigt.
     
    49. Verfahren nach Anspruch 1, das das Übertragen von Kontextinformationen des Benutzers an den Anrufer umfasst, wobei die Kontextinformationen Anwesenheitsinformationen und/oder einen aktuellen Verfügbarkeitsstatus einer Zielvorrichtung des Benutzers umfassen.
     
    50. Verfahren nach Anspruch 1, wobei die Anrufanforderung eine Datennachricht ist, die eine Textnachricht und/oder eine Sprachnachricht umfasst.
     
    51. Verfahren nach Anspruch 1, wobei die Zielvorrichtung Folgendes umfasst: ein Mobiltelefon, eine mobile Vorrichtung, eine drahtlose Vorrichtung, eine drahtgebundene Vorrichtung, eine Voice-over-Internet-Protokoll-, VOIP, Vorrichtung, eine Nebenstellenvermittlungsvorrichtung, einen Soft-Client und einen Desktop-Client.
     
    52. Verfahren nach Anspruch 1, wobei einer oder mehrere der Sprachkanäle und der Datenkanäle von einem Unternehmen, einem Dienstanbieter und/oder einem Mobilfunknetzbetreiber gehostet werden.
     
    53. Verfahren nach Anspruch 1, das das Übertragen von Medien zur Zielvorrichtung des Benutzers über den Sprachkanal und/oder den Datenkanal umfasst.
     
    54. System, das Folgendes umfasst:

    eine private Nebenstellenanlage eines Unternehmens, NStAnl;

    einen Server, der mit der Unternehmens-NStAnl und mindestens einem Kommunikationsnetzwerk verbunden ist;

    ein einem Benutzer zugewiesenes Telefon; und

    eine vom Benutzer bestimmte Zielvorrichtung;

    wobei der Server für Folgendes konfiguriert ist:

    Empfangen von Anrufereignisdaten von der NStAnl als Antwort auf einen Anruf an das Telefon des Benutzers, der von einem Anrufer über einen Unternehmenssprachkanal von der NStAnl empfangen wurde;

    Erzeugen einer Anrufanforderung als Antwort auf den Empfang der Anrufereignisdaten, wobei die Anrufanforderung Anruferdaten, einschließlich Anruferdaten von Datenbanken des Unternehmens, umfasst; und eine Vielzahl von Anrufantwortoptionen für die Teilnahme an dem Anruf;

    Weiterleiten der Anrufanforderung über einen Unternehmensdatenkanal an die Zielvorrichtung;

    Anweisen der NStAnl, den Anruf an die Zielvorrichtung weiterzuleiten, wenn der Benutzer die Option zum Annehmen des Anrufs an der Zielvorrichtung auswählt; und

    Abbrechen der Anrufanforderung durch Senden einer Benachrichtigung an die Zielvorrichtung über den Unternehmensdatenkanal als Antwort auf die Ermittlung, dass der empfangene Anruf am Telefon beantwortet wurde, bevor auf dem Server eine vom Benutzer ausgewählte Anrufantwortoption zum Annehmen des Anrufs auf der Zielvorrichtung empfangen wurde.


     
    55. System nach Anspruch 54, das ferner Mittel zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 53 umfasst.
     
    56. Computerlesbares Medium, das ausführbare Anweisungen umfasst, die, wenn sie von einem Verarbeitungssystem ausgeführt werden, ein Verfahren gemäß dem Verfahren nach einem der Ansprüche 1 bis 53 bereitstellen.
     


    Revendications

    1. Procédé consistant à :

    recevoir (402) des données d'événement d'appel au niveau d'un serveur en provenance d'un autocommutateur privé (PBX) d'entreprise en réponse à un appel vers un téléphone attribué à un utilisateur, reçu d'un appelant par le PBX par l'intermédiaire d'un canal vocal d'entreprise ;

    générer (404), par le serveur, une demande d'appel en réponse à la réception des données d'événement d'appel, la demande d'appel comprenant des données d'appelant, incluant des données d'appelant de bases de données de l'entreprise, et une pluralité d'options de réponse d'appel pour participer à l'appel ;

    et par le serveur :

    i) router (406) la demande d'appel par l'intermédiaire d'un canal de données d'entreprise vers un dispositif cible désigné par l'utilisateur ;

    ii) donner l'instruction au PBX de transférer l'appel vers le dispositif cible quand l'utilisateur sélectionne l'option d'accepter l'appel au niveau du dispositif cible ; et

    iii) annuler la demande d'appel en envoyant une notification au dispositif cible par l'intermédiaire du canal de données d'entreprise en réponse à la détermination du fait que l'on a répondu à l'appel au niveau du téléphone avant la réception, au niveau du serveur, d'une option de réponse d'appel, sélectionnée par l'utilisateur, d'accepter l'appel au niveau du dispositif cible.


     
    2. Procédé selon la revendication 1, consistant à afficher la pluralité d'options de réponse d'appel au niveau du dispositif cible.
     
    3. Procédé selon la revendication 1, consistant à répondre automatiquement à l'appel au niveau du dispositif cible.
     
    4. Procédé selon la revendication 1, consistant à :

    détecter la fin de l'appel avant l'acceptation ; et

    amorcer un appel de retour de l'appelant par l'intermédiaire du canal vocal.


     
    5. Procédé selon la revendication 4, consistant à transférer l'appel de retour vers le dispositif cible par l'intermédiaire d'un canal vocal.
     
    6. Procédé selon la revendication 1, dans lequel la pluralité d'options de réponse d'appel incluent le report de l'appel.
     
    7. Procédé selon la revendication 6, consistant, par le serveur, en réponse à la réception de l'option de réponse de report de l'appel, à notifier à l'appelant que l'utilisateur vers lequel l'appel est dirigé n'est pas disponible pour accepter l'appel.
     
    8. Procédé selon la revendication 7, consistant à diriger l'appel vers une boîte de messagerie vocale de l'utilisateur.
     
    9. Procédé selon la revendication 7, dans lequel la notification consiste à spécifier une heure future à laquelle l'utilisateur sera disponible pour accepter l'appel.
     
    10. Procédé selon la revendication 9, consistant à :

    générer un message de rappel de l'appel en réponse au report, le message de rappel incluant l'heure future ; et

    transférer le message de rappel vers un dispositif cible de l'utilisateur.


     
    11. Procédé selon la revendication 9, consistant à recevoir une sélection de l'heure future en provenance de l'appelant et/ou de l'utilisateur.
     
    12. Procédé selon la revendication 9, consistant à inviter l'appelant et/ou l'utilisateur à entrer l'heure future.
     
    13. Procédé selon la revendication 6, consistant à :

    détecter la fin de l'appel avant le report ; et

    amorcer un appel de retour de l'appelant par l'intermédiaire du canal vocal.


     
    14. Procédé selon la revendication 13, consistant à lire un message pendant l'appel de retour, le message spécifiant une heure future à laquelle l'utilisateur sera disponible pour accepter l'appel.
     
    15. Procédé selon la revendication 14, consistant à recevoir une sélection d'une heure future alternative en provenance de l'appelant pendant l'appel de retour.
     
    16. Procédé selon la revendication 15, consistant à :

    générer un message de rappel de l'appel en réponse au report, le message de rappel incluant l'heure future et/ou l'heure future alternative ; et

    transférer le message de rappel vers le dispositif cible de l'utilisateur.


     
    17. Procédé selon la revendication 1, dans lequel la pluralité d'options de réponse d'appel incluent le transfert de l'appel.
     
    18. Procédé selon la revendication 17, dans lequel le transfert consiste à transférer dynamiquement l'appel vers un numéro de téléphone de transfert de l'utilisateur par l'intermédiaire du canal vocal en réponse à la réception de l'option de réponse de transfert de l'appel.
     
    19. Procédé selon la revendication 18, consistant à recevoir le numéro de téléphone de transfert en provenance de l'utilisateur.
     
    20. Procédé selon la revendication 19, dans lequel la réception consiste à :

    transférer vers le dispositif cible de l'utilisateur un ensemble de numéros de téléphone incluant le numéro de téléphone de transfert ; et

    recevoir des données d'une sélection en provenance du dispositif cible, les données de la sélection incluant le numéro de téléphone de transfert.


     
    21. Procédé selon la revendication 19, dans lequel la réception consiste à :

    inviter l'utilisateur au niveau du dispositif cible à entrer le numéro de téléphone de transfert ; et

    recevoir des données de l'entrée d'utilisateur en provenance du dispositif cible, les données de l'entrée d'utilisateur incluant le numéro de téléphone de transfert.


     
    22. Procédé selon la revendication 18, consistant à :

    détecter la fin de l'appel avant le transfert ; et

    amorcer un appel de retour de l'appelant par l'intermédiaire du canal vocal.


     
    23. Procédé selon la revendication 22, consistant à transférer l'appel de retour vers le dispositif cible de l'utilisateur par l'intermédiaire d'un canal vocal et du numéro de téléphone de transfert.
     
    24. Procédé selon la revendication 1, dans lequel la pluralité d'options de réponse d'appel incluent le fait d'ignorer l'appel.
     
    25. Procédé selon la revendication 24, consistant à diriger l'appel vers une boîte de messagerie vocale de l'utilisateur.
     
    26. Procédé selon la revendication 1, dans lequel la pluralité d'options de réponse d'appel incluent le fait de désigner l'appelant comme un appelant ignoré.
     
    27. Procédé selon la revendication 26, consistant à diriger l'appel vers une boîte de messagerie vocale de l'utilisateur.
     
    28. Procédé selon la revendication 26, consistant à ignorer l'appel.
     
    29. Procédé selon la revendication 26, consistant à ignorer un appel futur de l'appelant ignoré.
     
    30. Procédé selon la revendication 1, dans lequel les données d'appelant incluent un nom, une adresse, un numéro de téléphone, une adresse de courrier électronique, un employeur et/ou un métier de l'appelant.
     
    31. Procédé selon la revendication 1, dans lequel les données d'appelant incluent des données personnelles de l'appelant, les données personnelles comprenant des données d'un conjoint, d'un parent, d'un enfant, d'une célébration et/ou d'un anniversaire de l'appelant.
     
    32. Procédé selon la revendication 1, dans lequel les données d'appelant incluent une ou plusieurs données d'au moins une interaction entre l'appelant et l'utilisateur.
     
    33. Procédé selon la revendication 1, dans lequel les données d'appelant incluent des données de filtrage reçues de l'appelant.
     
    34. Procédé selon la revendication 33, dans lequel les données de filtrage incluent des données entrées par l'appelant et/ou des données préspécifiées sélectionnées par l'appelant.
     
    35. Procédé selon la revendication 34, dans lequel les données de filtrage incluent des données audio enregistrées par l'appelant.
     
    36. Procédé selon la revendication 34, dans lequel les données de filtrage incluent un message de messagerie vocale.
     
    37. Procédé selon la revendication 36, consistant à diffuser le message de messagerie vocale à l'utilisateur.
     
    38. Procédé selon la revendication 1, dans lequel le routage comprend un routage distribué de la demande d'appel vers au moins un autre dispositif cible d'au moins un autre utilisateur, le routage distribué comprenant un routage vers l'au moins un autre utilisateur à la place d'un routage vers l'utilisateur et/ou un routage vers l'au moins un autre utilisateur en plus d'un routage vers l'utilisateur.
     
    39. Procédé selon la revendication 38, dans lequel le routage distribué comprend un routage parallèle vers une pluralité d'autres utilisateurs.
     
    40. Procédé selon la revendication 39, dans lequel le routage distribué comprend :

    un premier routage de la demande d'appel vers au moins un dispositif cible d'un premier ensemble d'autres utilisateurs ; et

    un second routage de la demande d'appel vers au moins un dispositif cible d'un second ensemble d'autres utilisateurs.


     
    41. Procédé selon la revendication 38, dans lequel le routage distribué est un routage séquentiel vers chaque autre utilisateur d'une pluralité d'autres utilisateurs.
     
    42. Procédé selon la revendication 41, consistant à déterminer une hiérarchie du routage, la hiérarchie définissant un ordre du routage vers la pluralité d'autres utilisateurs.
     
    43. Procédé selon la revendication 38, dans lequel le routage distribué comprend :

    un routage parallèle vers une première pluralité d'autres utilisateurs ; et

    un routage séquentiel vers chaque autre utilisateur d'une seconde pluralité d'autres utilisateurs.


     
    44. Procédé selon la revendication 38, dans lequel le routage distribué comprend un routage selon une disponibilité de la ressource, la disponibilité comprenant la présence de la ressource, l'état d'accessibilité de la ressource, la disponibilité déterminée par un système hôte et/ou la disponibilité spécifiée par la ressource.
     
    45. Procédé selon la revendication 1, dans lequel la pluralité d'options de réponse d'appel incluent la génération d'un message de données de retour pour l'appelant, incluant un message textuel et/ou un message vocal.
     
    46. Procédé selon la revendication 1, dans lequel le routage de la demande d'appel comprend un routage selon une information contextuelle, l'information contextuelle comprenant un état de connectivité et/ou un profil de disponibilité du dispositif cible de l'utilisateur.
     
    47. Procédé selon la revendication 46, dans lequel l'état de connectivité inclut une information d'un état de connectivité du dispositif cible à un réseau de communication.
     
    48. Procédé selon la revendication 46, dans lequel l'état de connectivité inclut un état accessible et/ou un état non accessible, le dispositif cible étant dans un état accessible quand le dispositif cible est dans un état de mise sous tension et connecté à un réseau de communication correspondant, et le dispositif cible étant dans un état non accessible quand le dispositif cible est dans un état de mise hors tension, déconnecté du réseau de communication et/ou engagé dans un appel vocal.
     
    49. Procédé selon la revendication 1, consistant à transférer une information contextuelle de l'utilisateur à l'appelant, l'information contextuelle incluant une information de présence et/ou un état de disponibilité actuel d'un dispositif cible de l'utilisateur.
     
    50. Procédé selon la revendication 1, dans lequel la demande d'appel est un message de données qui consiste en un message textuel et/ou un message vocal.
     
    51. Procédé selon la revendication 1, dans lequel le dispositif cible inclut un téléphone cellulaire, un dispositif mobile, un dispositif sans fil, un dispositif câblé, un dispositif de voix sur protocole Internet (VoIP), un dispositif autocommutateur privé, un client logiciel et/ou un client de bureau.
     
    52. Procédé selon la revendication 1, dans lequel le canal vocal et/ou le canal de données sont hébergés par l'entreprise, un fournisseur de services et/ou un opérateur de réseau mobile.
     
    53. Procédé selon la revendication 1, consistant à transférer des données multimédias vers le dispositif cible de l'utilisateur par l'intermédiaire du canal vocal et/ou du canal de données.
     
    54. Système comprenant :

    un autocommutateur privé (PBX) d'entreprise ;

    un serveur couplé au PBX d'entreprise et à au moins un réseau de communication ;

    un téléphone attribué à un utilisateur ; et

    un dispositif cible désigné par l'utilisateur ;

    le serveur étant configuré pour :

    recevoir des données d'événement d'appel en provenance du PBX en réponse à un appel vers le téléphone de l'utilisateur, reçu d'un appelant par le PBX par l'intermédiaire d'un canal vocal d'entreprise ;

    générer une demande d'appel en réponse à la réception des données d'événement d'appel, la demande d'appel comprenant des données d'appelant, incluant des données d'appelant de bases de données de l'entreprise, et une pluralité d'options de réponse d'appel pour participer à l'appel ;

    router la demande d'appel vers le dispositif cible par l'intermédiaire d'un canal de données d'entreprise ;

    donner l'instruction au PBX de transférer l'appel vers le dispositif cible quand l'utilisateur sélectionne l'option d'accepter l'appel au niveau du dispositif cible ; et

    annuler la demande d'appel en envoyant une notification au dispositif cible par l'intermédiaire du canal de données d'entreprise en réponse à la détermination du fait que l'on a répondu à l'appel reçu au niveau du téléphone avant la réception, au niveau du serveur, d'une option de réponse d'appel, sélectionnée par l'utilisateur, d'accepter l'appel au niveau du dispositif cible.


     
    55. Système selon la revendication 54, comprenant en outre un moyen permettant de réaliser un procédé selon l'une quelconque des revendications 1 à 53.
     
    56. Support lisible par ordinateur comprenant des instructions exécutables qui, lorsqu'elles sont exécutées par un système de traitement, fournissent un procédé selon le procédé selon l'une quelconque des revendications 1 à 53.
     




    Drawing







































































    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description