U.S. patent application number 10/876422 was filed with the patent office on 2005-06-30 for personal call routing between pbx and sip networks.
Invention is credited to Wengrovitz, Michael S..
Application Number | 20050141689 10/876422 |
Document ID | / |
Family ID | 34574816 |
Filed Date | 2005-06-30 |
United States Patent
Application |
20050141689 |
Kind Code |
A1 |
Wengrovitz, Michael S. |
June 30, 2005 |
Personal call routing between PBX and SIP networks
Abstract
This invention integrates instant messaging, presence, and other
collaborative capabilities with conventional PBX functionality
through use of a PBX-Messaging Integration Client (PMIC). The
invention in its several embodiments features a method and system
for using the PMIC-based computer interface to perform
off-hook/on-hook presence notification for a PBX phone, establish
media sessions concurrent with PBX telephonic communication,
execute custom call treatment in conjunction with a PBX phone,
implement call transfer capability between a PBX phone and numerous
other devices, and provide PBX call control. The PBX is generally
enabled with computer telephony integration (CTI) and, depending on
the embodiment, a Voice-over-Internet Protocol (VoIP) such as
Session Initiation Protocol (SIP). The invention empowers
enterprise workers with a diverse, unified and integrated set of
both PBX functions and SIP-based collaboration tools.
Inventors: |
Wengrovitz, Michael S.;
(Concord, MA) |
Correspondence
Address: |
ALCATEL INTERNETWORKING, INC.
ALCATEL-INTELLECTUAL PROPERTY DEPARTMENT
3400 W. PLANO PARKWAY, MS LEGL2
PLANO
TX
75075
US
|
Family ID: |
34574816 |
Appl. No.: |
10/876422 |
Filed: |
June 25, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10876422 |
Jun 25, 2004 |
|
|
|
10750795 |
Dec 31, 2003 |
|
|
|
Current U.S.
Class: |
379/207.02 ;
379/225 |
Current CPC
Class: |
H04L 51/04 20130101;
H04M 3/5191 20130101; H04M 3/54 20130101; H04L 51/36 20130101; H04M
3/42093 20130101; H04M 3/60 20130101; H04M 7/0027 20130101; H04M
3/42323 20130101; H04M 3/42365 20130101; H04M 2203/2011 20130101;
H04M 3/42059 20130101 |
Class at
Publication: |
379/207.02 ;
379/225 |
International
Class: |
H04M 003/42; H04M
007/00 |
Claims
I claim:
1. A call routing method for a first computer interface operatively
coupled to a system comprising a private branch exchange (PBX) and
a first PBX phone, the call routing method comprising the steps of:
receiving from the PBX a first message indicating an incoming call
to the first PBX phone; determining from a call routing table
maintained by the first computer interface an incoming call
response to the incoming call; and transmitting to the PBX a group
of one or more messages based on the incoming call response.
2. The call routing method of claim 1, wherein the group of
messages comprises a message answering the incoming call.
3. The call routing method of claim 1, wherein the group of
messages comprises a message causing the PBX to discontinue a ring
signal to the first PBX phone.
4. The call routing method of claim 1, wherein the group of
messages comprises a message causing the PBX to transfer the
incoming call to a second PBX phone.
5. The call routing method of claim 1, wherein the group of
messages comprises a message causing the PBX to transfer the
incoming call to the first computer interface.
6. The call routing method of claim 5, wherein the method further
includes the step of establishing a voice-over-IP session between
the PBX and the first computer interface.
7. The call routing method of claim 1, wherein the group of
messages comprises a message causing the PBX to transfer the
incoming call to a client.
8. The call routing method of claim 7, wherein the client is a SIP
user agent operatively coupled to the system.
9. The call routing method of claim 1, wherein the group of
messages comprises a message causing the PBX to terminate the
incoming call and transmit an instant message.
10. The call routing method of claim 9, wherein the instant message
is directed to a second computer interface identified based upon a
phone number associated with the incoming call.
11. The call routing method of claim 1, wherein the call routing
table comprises call processing rules structured as a function of
the time and the day the incoming call is received, the telephone
number or extension associated with the incoming call, and the
presence-state of the user associated with the first PBX phone.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of prior application Ser.
No. 10/750,795 filed Dec. 31, 2003, which is hereby incorporated
herein by reference for all purposes.
FIELD OF THE INVENTION
[0002] The present invention relates to a technique for integrating
one or more user interfaces with a PBX phone system. In particular,
the invention relates to a method and system for providing
off-hook/on-hook presence notification for a PBX phone,
establishing media sessions concurrent with PBX telephonic
communication, customized call treatment for a PBX phone, call
transfer capability between a PBX phone and numerous other devices,
and PBX call control.
BACKGROUND
[0003] Private Branch Exchange (PBX) telephone systems are used in
many businesses to enable workers to make and receive calls from
the Public Switched Telephone Network (PSTN) and other PBX phones
within the enterprise. PBX systems also provide a host of
telephonic services to the enterprise workers including call
forwarding, transferring, conferencing, voice mail, personalized
greetings, and the like.
[0004] In many cases, an enterprise worker's phone resides on the
desktop in immediate proximity to the worker's personal computer.
The personal computer may provide tools for word processing,
viewgraph editing, email, and web browsing, as well as other
communications tools such as instant messaging, buddy lists,
presence, video, and other tools for collaboration. Instant
messaging allows people with network access to send text messages
and other media to other individuals listed in a buddy or contact
list. An instant text message is sent in near-real time to a
contact where it is then displayed in a graphical user interface
window within the context of an on-going text-based conversation.
In addition to text messages, instant messaging may also be used
within chat sessions and custom chat rooms where friends or
co-workers can interact and share media. Some instant messaging
applications are also enabled with a presence protocol used by a
one person to determine whether a buddy or contact is "present"
online and to subscribe to changes in the presence state or
information.
[0005] Despite the prevalence of PBX phones and
communications-enabled personal computers in the enterprise, there
is an absence of sufficient integration between these two types of
communication systems. For example, an enterprise worker's instant
messaging application may be aware of the worker's online presence
but is oblivious to the worker's telephonic presence, i.e. buddies
do not know that a worker is occupied on his PBX phone. Or, as a
second example, although a worker sets up a voice session to
another worker by dialing a PBX extension, an entirely separate
process must be followed to setup a session for exchanging a
document. Therefore, there is a need for a solution that integrates
the PBX system and communications applications on enterprise
workers' computers to provide greater interoperability, simplified
PBX control, and enhanced sharing and collaboration.
SUMMARY
[0006] The invention in its several embodiments features a method
and system for using a computer interface to perform
off-hook/on-hook presence notification for a PBX phone, establish
media sessions concurrent with PBX telephonic communication,
execute custom call treatment in conjunction with a PBX phone,
implement call transfer capability between a PBX phone and numerous
other devices, and provide PBX call control. The PBX is generally
enabled with computer telephony integration (CTI) capabilities and
may also, depending on the embodiment, be enabled with
Voice-over-Internet Protocol (VoIP) capabilities such as Session
Initiation Protocol (SIP). The computer interface may be any number
of computer appliances including personal computer also enabled
with CTI, for example.
[0007] In one embodiment, the invention relates to a presence
notification method for communicating an enterprise worker's
on-phone/off-phone presence state to other workers using a computer
interface operatively coupled to a system comprising a private
branch exchange (PBX) and a first PBX phone. The presence
notification method preferably comprises the steps of: receiving
from the PBX a first message indicating an off-hook state of the
first PBX phone; consulting a subscriber table including the
identity of one or more presence-state subscribers; and
transmitting a second message to at least one of the one or more
presence-state subscribers indicating the off-hook state of the
first PBX phone.
[0008] In a second embodiment, the invention relates to a method
for establishing a collateral communication session between a
plurality of enterprise workers' computer interfaces in response to
a call between the workers. The collateral communication session,
referred to herein as a concurrent media session, may take a number
of forms including text messaging, document exchange, desktop
sharing, and video, for example. The method for establishing
concurrent media session setup using a first computer interface
operatively coupled to a system comprising a private branch
exchange (PBX) and a second computer interface preferably comprises
the steps of: receiving from the PBX a first message signifying
that the second PBX phone has called the first PBX phone;
transmitting a second message from the first computer interface to
the second computer interface requesting a media session;
determining whether the media session request has been accepted at
the second computer interface; and establishing a media session
between the first computer interface and second computer interface
if the session request message is accepted.
[0009] In a third embodiment, the invention relates to a method for
performing custom call treatment allowing a recipient of an
incoming PBX call to respond to the call by transferring the call
to another device or responding with an instant message, for
example, depending on various factors including the caller, the
time, and date. The call treatment method in a first computer
interface operatively coupled to a system comprising a private
branch exchange (PBX) and a first PBX phone preferably comprises
the steps of: receiving from the PBX a first message indicating an
incoming call; determining from a call routing table maintained by
the first computer interface an incoming call response to the
incoming call; and transmitting a group of one or more messages
based on the incoming call response, wherein the group comprises a
second message answering the incoming call.
[0010] In a fourth embodiment, the invention relates to a method
for transferring a call between an enterprise worker's PBX phone
and an associated computer interface. The call transfer method in a
first computer operatively coupled to a system comprising a private
branch exchange (PBX) and a first PBX phone, preferably comprises
the steps of: transmitting to the PBX a first message for
transferring a telephone call associated with the first PBX phone;
establishing a voice-over-IP session between the PBX and the first
computer; and replacing the telephone call to first PBX phone with
a call to the first computer via the voice-over-IP session.
[0011] In a fifth embodiment, the present invention relates to a
method of controlling PBX telephone calls to a worker's PBX phone
using a computer interface operatively coupled to a system
comprising a PBX and a first PBX phone. The PBX call control method
preferably comprises the steps of: receiving from the PBX a first
message indicating the presence of a telephone call associated with
the first PBX phone; and transmitting to the PBX a call control
message, such as a call-hold command, or call-forwarding command
directing the PBX to another PBX phone or VoIP client, for
example.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The present invention is illustrated by way of example and
not limitation in the figures of the accompanying drawings, and in
which:
[0013] FIG. 1 is a functional block diagram of an enterprise
network including a PBX system and Internet Protocol (IP) network,
according to the preferred embodiment;
[0014] FIG. 2A is a functional block diagram of a PBX, according to
the preferred embodiment;
[0015] FIG. 2B is a functional block diagram of a PBX processing
module, according to the preferred embodiment;
[0016] FIG. 3 is a functional block diagram of a PBX user phone,
according to the preferred embodiment;
[0017] FIG. 4A is a functional block diagram of a enterprise
worker's PBX-Messaging Integration Client (PMIC), according to the
preferred embodiment;
[0018] FIG. 4B is a functional block diagram of a PMIC processing
module, according to the preferred embodiment;
[0019] FIGS. 5A and 5B is a state diagram characterizing the PBX
with which the preferred embodiment interoperates, according to the
preferred embodiment;
[0020] FIG. 6 is a flowchart of the PBX external-call-placed
processing, according to the preferred embodiment;
[0021] FIG. 7A is a flowchart of the PBX internal-call-placed
processing, according to the preferred embodiment;
[0022] FIG. 8 is a flowchart of the PBX voice-over-IP (VoIP)
session setup, according to the preferred embodiment;
[0023] FIG. 9 is a flowchart of the PBX call-receiving state
processing, according to the preferred embodiment;
[0024] FIG. 10 is a flowchart of the PBX call-answered state
processing, according to the preferred embodiment;
[0025] FIG. 11 is a state diagram characterizing the PBX-Messaging
Integration Client (PMIC) processing, according to the preferred
embodiment;
[0026] FIG. 12A is a flowchart of the on-phone presence state
processing, according to the preferred embodiment;
[0027] FIG. 12B is a flowchart of the off-phone presence state
processing, according to the preferred embodiment;
[0028] FIG. 13 is a flowchart of the concurrent media session setup
procedure, according to the preferred embodiment;
[0029] FIG. 14 is flow diagram depicting the method of distributing
telephonic presence-sense notices, according to the preferred
embodiment;
[0030] FIG. 15 is a flow diagram demonstrating the use of a
networked intermediate server with which the PBX and one or more
PMICs may interoperate, according to the preferred embodiment;
[0031] FIG. 16A is a flow diagram demonstrating the procedure for
establishing a first category of CMS between calling parties,
according to the preferred embodiment;
[0032] FIG. 16B is a flow diagram demonstrating a first procedure
for establishing a second category of CMS between calling parties,
according to the preferred embodiment;
[0033] FIG. 16C is a flow diagram demonstrating a first procedure
for establishing a third category of CMS between calling parties,
according to the preferred embodiment;
[0034] FIG. 17 is a flow diagram demonstrating a call initiated
from the PMIC, according to the preferred embodiment;
[0035] FIG. 18A is a flow diagram demonstrating an on-going
telephone communication being transferred from a user PBX phone to
an associated PMIC, according to the preferred embodiment;
[0036] FIG. 18B is a flow diagram demonstrating an on-going
telephone communication being transferred from PMIC to an
associated PBX phone, according to the preferred embodiment;
[0037] FIG. 19 is a flow diagram demonstrating a PMIC automatically
answering an incoming call, according to the preferred
embodiment;
[0038] FIG. 20A is a flow diagram demonstrating an incoming call
being automatically forwarded by a PMIC, according to the preferred
embodiment;
[0039] FIG. 20B is a flow diagram demonstrating a PMIC
automatically responded to an incoming call with an instant
message, according to the preferred embodiment;
[0040] FIG. 21 is a functional block diagram of a PMIC with a
plurality of selectable SIP user agents, according to the second
preferred embodiment; and
[0041] FIG. 22 is a CTI server with a plurality of PBX interfaces,
according to the preferred embodiment.
DETAILED DESCRIPTION
[0042] FIG. 1 is a block diagram of a PBX system operably coupled
to a data network. The PBX system 100 comprises a PBX 110 and a
plurality of PBX phones 130-132, each phone being associated with a
unique extension number. The PBX 110 manages calls between the
plurality of user phones 131-133 and a set of trunk lines operably
coupled to the Public Switch Telephone Network (PSTN) 102 while
supporting call forwarding between PBX phones, conference calling,
call holding, voice mail, personalized greetings, and the like. The
PBX system 100 is consistent with both new telephone systems and a
vast number of legacy telephone systems currently located at and
operated by enterprises today.
[0043] Also operating within the enterprise is a data
communications network 150 embodied in or operably coupled to a
local area network (LAN), a wide area network (WAN), a metropolitan
area network (MAN), the Internet Protocol (IP) network 104, or a
combination thereof. The communications network 150 operably
couples a plurality of computers enabled with a PBX-Messaging
Integration Client (PMIC) 140-142 distributed throughout the
enterprise to each other and to the resources available through the
World Wide Web using Ethernet and or the transmission control
protocol (TCP)/IP protocol suite. Each of the PMICs 140-142 is
generally associated with an individual enterprise worker. In most
cases, an individual's PMIC is located in the immediate proximity
to the individual's phone, thus giving rise to a logical
association between a user PMIC and a user phone. The logical
association between a PMIC, a phone, and a single user exist for a
multiplicity of enterprise workers including a first user 120,
second user 121, and third user 122, and so on.
[0044] In the preferred embodiment, the PBX 110 is enabled with a
computer telephone integration (CTI) protocol, which refers to a
signaling convention by which the PMICs 140-142 may control and
monitor PBX functions. In the preferred embodiment, the PMICs
140-142 are adapted to act as individualized clients for: (1)
placing and answering PBX calls without a PBX phone, (2) routing
incoming call directed PBX extensions to other devices, (3)
forwarding calls away from PBX phones to other devices, and (4)
placing calls on hold. In addition to receiving CTI commands, the
PBX or the CTI client associated thereto is also adapted to
transmit CTI messages upon occurrence of certain events, as is
described in greater detail below. Also in the preferred
embodiment, the PMIC provides an interface to presence, instant
messaging, document exchange, desktop sharing and other
capabilities typically resident in applications such Microsoft's
Real-Time Communications (RTC) Messenger.
[0045] FIG. 2A represents a functional block diagram of the PBX 110
with which the enterprise PMICs 140-142 interoperate. The PBX 110
generally includes a cabinet or backplane including one or more
trunk interfaces 220 for converting between the signal format and
voice transmission of the PSTN 102 and the internal convention used
by the PBX system 100, a plurality of PBX phone interfaces or line
cards 222 providing a connection to the user PBX phones 130-132, a
CTI interface 224 for transmitting and receiving CTI messages
transmitted via the network 150, and a switch controller 202 for
creating and managing voice circuits between the trunk interfaces
220, line cards 222, and CTI interface 224. The switch control 202
is generally an element of a processing module 200 embodying
various call management services 204 including voice mail 206 and
other interactive voice response (IVR) systems 208, for
example.
[0046] Signaling and voice communications between the PBX 110 and
phones 130-132 are conventionally performed using a digital
protocol, although an analog protocol may also be employed. The
digital protocol, referred to herein a private digital signaling
and voice (PDSV) protocol, comprises a signaling convention that
includes operation-codes used to exchange voice communications as
well control signals. Although well understood by those skilled in
the art, PDSV protocols are generally proprietary implementations
and differ between vendors. The major CTI standards are Telephony
Application Programming interface (TAPI) and Telephony Services
Application Programming Interface (TSAPI), as well as the European
Communications Manufacturers Association (ECMA) standard for CTI,
namely the Computer Supported Telecommunications Applications
(CSTA) protocol.
[0047] Illustrated in FIG. 2B is a functional block diagram of a
PBX processing module 200. The PBX processing module 200 in the
preferred embodiment incorporates one or more software and or
firmware components that cooperate with switch control 202 to
provide the PBX services 204. The PBX processing module 200 may
include an operating system 232, e.g. UNIX-based system or
proprietary implementation, that in turn supports a CTI message
handler 234 adapted to generate and respond to various CTI commands
in the manner set forth in greater detail below. When a CTI
registration command is used to associate a PBX with a PMIC, for
example, the CTI message handler 234 is adapted to transmit various
event messages to the PMIC is response to various types of
activities involving one or more PBX phones. In particular, the CTI
handler 234 in the preferred embodiment is adapted to transmit a
CTI off-hook event to a registered PMIC in response to an off-hook
signal received from the associated PBX phone, transmit a CTI
on-hook event to a registered PMIC in response to an on-hook signal
from the associated PBX phone, transmit a incoming-call event to
the PMIC associated with a PBX phone to which the PBX transmits a
ring signal, a first call-answered event to the PMIC when the
associated phone is used to answer an incoming call, and transmit a
second call-answered event to the PMIC associated with the PBX
phone used to place a call to another PBX phone when it is
answered.
[0048] Illustrating in a FIG. 3 is a functional block diagram of a
PBX phone typical of user phones 130-132. The user PBX phone
preferably includes a handset and base unit 300 comprising a phone
microprocessor module 310 that enables incoming and outgoing calls.
The phone microprocessor module 310, in combination with the user
interface logic 316, transmits input from the dial pad 314 and
display relevant information at display 312. The phone
microprocessor module 310, in cooperation with coder/decoder 322,
conveys incoming voice signals to an audio user interface (AUI) 320
speaker and outgoing voice signals received at an AUI 320
microphone to the PDSV interface 330.
[0049] Illustrated in FIG. 4A is a functional block diagram of a
user's PMIC 140-142. The PMIC 400 generally includes the hardware
and software necessary to provide access to and exchange voice and
control signals with another VoIP client including, in some
embodiments, the PBX 110. In particular, the PMIC 400 comprises a
processing module 410, display 440, tactile user interface 450
preferably including a keyboard, a AUI 460 with sound card and
speaker, and a network interface card (NIC) 470 operably coupled to
the data communications network 150.
[0050] The processing module 410 generally comprises hardware
components including a central processing unit 412, computer memory
414, and random access memory (RAM). As illustrated in FIG. 4B, the
processing module 410 may further comprise software and or firmware
components including a PMIC controller 428 and a PMIC graphical
user interface (GUI) 434 used by the enterprise worker to monitor
and configure the PMIC 428 as well as bridge between the PBX domain
and the VoIP domain. The PMIC 428 in the preferred embodiment is
adapted to monitor calls involving a PBX phone 130-132, intervene
in calls under certain circumstances in a manner defined by the
user, and establish media sessions on behalf of an enterprise
worker in parallel with a telephone call.
[0051] Upon receipt of an incoming call, the PMIC 428 generally
consults routing logic 430 to whether to forward an incoming call
to another PBX phone or other device, for example, or respond with
a message transmitted via the network 150. In the process of
monitoring calls involving a user's PBX phone, the PMIC 428 may
consult the subscriber table 432 to identify any Instant Messaging
(IM) buddies in a contact list of changes in the enterprise
worker's telephonic presence. In some circumstances, the PMIC 428
may also consult the concurrent media session (CMS) handler 434 to
initiate transmission of an instant message, text chat or other
voice and/or video media session between the PMICs of the users
that are engaged in telephonic communication.
[0052] PMIC processing module 410 further comprises a CTI client
422, preferably a CTI protocol stack, and Real-Time Communications
(RTC) client 426 running on top of an operating system 418 such MS
WINDOWS also by Microsoft Corporation. The CTI client 422 together
with its CTI application programming interface (API) 420 provides
the underlying functionality used to implement the various call
control functionality embodied in the PMIC processing of the
preferred embodiment. The RTC client 426 with RTC API 426 provides
support for the Session Initiation Protocol (SIP) used in some
embodiments to enable the CMSs, as discussed in greater detail
below.
[0053] Although the PMICs 140-142 in the preferred embodiment are
personal computers, one skilled in the art will appreciate that any
of a variety of processing devices including desktop computers,
laptop computers, personal digital assistants (PDA),
Internet-enabled appliances, or mobile communication devices such
as cellular phones may be adapted for purposes of this
invention.
[0054] Illustrated in FIGS. 5A and 5B is a state diagram
characterizing the PBX with which the preferred embodiment
interoperates. The PBX 110 generally monitors (state 502) the trunk
lines to PSTN 102 as well as the internal phones 130-132. The
operation of the PBX 110 characterized by the method of FIGS. 5A
and 5B generally falls into at least one of three different
categories, namely, an outgoing call placed by a PBX user phone
130-132 to a device external to the PBX 110, a internal call placed
by a user phone 130-132 to another phone 130-132 within the PBX
110, and or an incoming call to a user phone 130-132 from a device
external to the PBX 110.
[0055] When a call is initiated by a user phone 130-132, an
off-hook signal is transmitted from the phone to the PBX 110 with
"digits" or dual-tone multi-frequency (DTMF) signals representing a
phone number or a PBX extension number. If the off-hook signal 520
is accompanied by the phone number to an external phone, the PBX
110 transitions to an external call-placed state 504, illustrated
in greater detail in the external call process 600 of FIG. 6.
Referring to FIG. 6, the PBX 110 identifies the digits representing
external phone number received (step 610) from user phone and
transmits (step 620) a connection request out to the PSTN 102.
Since the preferred embodiment of the PBX 110 is enabled with CTI,
the PBX also transmits (step 630) off-hook plus dialed-number
events to the associated caller's computer 140-142 via the IP
network 150. The off-hook and dialed-number events are messages
used to notify a device registered with the PBX, i.e. the caller's
PMIC, that user phone has transitioned from on-hook to off-hook to
make the call. In the preferred embodiment, a client on the network
150 must have registered for the notification at the PBX 110 using
a registration event, e.g. a CTI message, requesting notifications
about the state of user phone 130-132 identified by its extension
number. Once registered, the PBX 110 directs the off-hook plus
dialed-number events registered client.
[0056] Referring again to FIG. 5A, if the off-hook signal 530 is
transmitted from the PBX phone 130-132 is accompanied by an
extension number of a PBX phone 130-132 within the PBX 110, the PBX
transitions to an internal call-placed state 506 illustrated in
greater detail in the internal call process 700 of FIG. 7.
Referring to FIG. 7, the PBX 110 identifies the extension number
received (step 710) from user phone and transmits (step 720) a ring
signal to the call recipient's phone. The PBX also transmits (step
730) an off-hook plus dialed-number event with the recipient's
extension number to the caller's PMIC 140-142 via the IP network
150. The off-hook dialed-number event is preferably a CTI message,
used to notify the caller's computer that caller's phone is now in
the off-hook state as well as the particular extension dialed. In
the preferred embodiment, the off-hook plus dialed-number event
including the extension is transmitted indirectly from the PBX 110
through a CTI Server to the caller's computer, although the PBX may
be used to directly transmit the event to the caller's PMIC.
[0057] Referring to FIG. 5A, if the PBX 110 receives an answered
signal 522 from the external call recipient, the PBX transitions
from the external call-placed state 504 to the PDSV voice
communication state 510. Similarly, an off-hook signal 532 from the
call recipient in response to the internal call-placed 506 will
also cause the PBX 110 to transition to the PDSV voice
communication state 510. The PDSV voice communication state 510
represents the processing necessary for the PBX 110 to maintain
voice communication, which may involve switch control 202
operations such as analog-to-digital conversion and filtering,
signaling and the like. If the call recipient answers using is a
PBX phone, the PBX 110 may also send a call-answered event
comprising the extension of the call recipient's PBX phone to the
same registered client that the off-hook plus dialed-extension
event was sent. The PDSV voice communication generally continues
until a calling or called party goes on-hook 528 and terminates the
voice communication (state 516).
[0058] At nny time during the PDSV voice communications (state
510), the call in progress may be transferred to another device. If
the PBX 110 is enabled with a VoIP protocol, for example, the PBX
can transfer the call in response to a transfer command 534, e.g. a
CTI message, with an identifier specifying the device to which the
voice communication is to be redirected. If transferred to a VoIP
client in the enterprise worker's PMIC, for example, the PBX 110
attempts to establish a VoIP session (state 512) and transfer the
caller side of the communication to a VoIP device. In the session
setup process 800 associated with the session setup (state 512)
illustrated in FIG. 8, the PBX 110 uses the identifier from the
transfer command received (step 810) to determine in the transfer
selection mode (step 820) where to forward the VoIP call. A
transfer command including a universal resource (URI) designating
the caller's PMIC, for example, causes the PBX 110 to issue (step
840) a session request message, e.g., a SIP INVITE, to a VoIP
client in the caller's PMIC. If the PBX 110 receives a SIP OK
message 542 in response to the session request message, the SIP OK
testing (step 850) is answered in the affirmative and SIP VoIP
session (state 514) replaces the prior PDSV communication between
the caller's phone and PBX 110. The PBX 110 may also be adapted to
transfer calls to other resources (step 830) including other PBX
phones or external phones, for example.
[0059] After the SIP VoIP session is established (state 514), a
participant in the session may terminate the session and
effectively end the call (state 516) by issuing a VoIP termination
message such as a SIP BYE message 544. In the alternative, the
participant may transfer the call back to a phone set (state 510)
using a transfer command 536 including the appropriate phone
extension.
[0060] Any time during the PDSV voice communications (state 510),
the call in progress may be placed on hold (state 518) by a hold
PDSV operation code from the user's PBX phone or by a hold command
524 received by the PBX 110 from the user's PMIC 428 via the
network 150. Similarly, the call may be taken off hold in response
to the appropriate operation code or an un-hold command from the
user's PMIC 428.
[0061] In addition to outgoing calls discussed above, the PBX 110
is also enabled to facilitate incoming calls. When a call 540 is
directed to a user phone 130-132 from either another PBX user phone
130-132 or external PSTN line, the PBX 110 transitions into the
initial call receiving state 508. As illustrated the call receiving
procedure 900 of FIG. 9 associated with the initial call receiving
state 508 of FIG. 5B, the PBX 110 transmits (step 910) the incoming
connection request to the recipient's phone in the form of a ring
signal. The PBX 110 in the preferred embodiment also transmits
(step 920) an incoming-call event, e.g. a CTI message, via the
network 150 to notify the recipient's PMIC of the connection
request.
[0062] In the preferred embodiment, the incoming call may be
answered at the recipient's PBX phone or by way of a CTI answer
event received by the PBX 110 from the user's PMIC via the network
150. Upon receipt of an off-hook signal 570 from the PBX phone, the
PBX 110 transitions to the call answered (state 552) illustrated in
more detail in the call answered process 1000 of FIG. 10. As shown,
receipt of the off-hook signal (step 1010) causes the PBX 110 to
transmit (step 1020) a first call-answered event, e.g., a CTI
message, notifying the recipient's PMIC that the call has been
accepted at the associated PBX phone. If the call is also initiated
from a PBX phone 130-132 within the PBX system 100, internal-caller
testing (step 1030) is answered in the affirmative and the PBX 110
generates a second call-answered event transmitted (step 1040) to
the caller's PMIC. The second call-answered event, e.g. a CTI
message, notifies the caller's PMIC when the call is answered by
the call recipient at the recipient's PBX phone or other
device.
[0063] Subsequent PDSV voice communications in state 554 are
analogous to that discussed above in context of PDSV voice
communication state 510.
[0064] When the incoming call is answered at the call recipient's
PMIC, the PBX 110 generally receives an answer command accompanied
by a transfer command from the PMIC. The transfer command includes
a URI designating the user's PMIC or a SIP user agent therein and
the PBX 110 transitions to the PBX's VoIP session setup state 556
consistent with the VoIP session setup state 514 discussed above.
If the session request message issued by the PBX 110 is accepted,
the PBX transitions into the PBX's VoIP session (state 558) and the
PDSV voice communication terminated. The recipient may subsequently
transfer 586 the call between the PDSV voice communication (state
554) and the VoIP session (state 558) in the manner described
above.
[0065] If the transfer command 590 received while in the initial
call receiving (state 508) includes a URI designating a phone,
computer, or user agent other than that of the recipient, the PBX
110 effectively transfers the call to the other device and returns
to monitoring the phone status (state 502).
[0066] Illustrated in FIG. 11 is a state diagram characterizing the
PMIC for extending the scope and control of a PBX system and
extending the scope of the presence sensing into the telephonic
domain. The PMIC process 1100 is preferably embodied in one or more
user computers within an enterprise that may have a new or existing
PBX system consistent with operations discussed above. Each user
computer 140-142 is adapted to execute the PMIC process 1100,
thereby making them PMICs. The plurality of PMICs that interoperate
with one another and the PBX 110 constitute a PMIC system. In
general, there is a one-to-one relationship between a PMIC and an
enterprise worker's PBX phone.
[0067] A PMIC generally monitors (state 1102) the IP network 150
for messages transmitted by the PBX 110 as well as other PMICs in
the enterprise. The messages from the PBX 110 generally fall into
one of two categories, namely, call-placed messages indicating that
the PBX phone 130-132 with which the PMIC is associated is being
used to place a call or incoming call messages indicating that the
associated PBX phone is receiving a call from either another PBX
user phone or external line.
[0068] When the PBX phone associated with the PMIC is used to place
a call, the PMIC receives the off-hook event 1130 generated by PBX
102 and transitions into the on-phone presence-state (P-S)
processing (state 1104). The P-S processing (state 1104) is
illustrated in greater detail in the on-phone P-S processing method
1200 of FIG. 12A. As illustrated, the PMIC consults (step 1210) its
local subscriber table 432 to identify the call recipient's
presence-state subscribers. A P-S subscriber is party that has
registered to receive notice of a co-worker's online presence and
or telephonic availability. If one or more subscribers are
identified (step 1220), an on-phone event, e.g., a SIP message, is
transmitted (step 1230) to each subscriber to indicate that the
party whose presence-state is being monitored has picked up the PBX
phone. Referring to FIG. 11, the PMIC then indirectly monitors the
telephonic communications (state 1106) by listening for any CTI
events signifying a change in the ongoing telephonic
communication.
[0069] When the PBX phone associated with the PMIC receives a call,
the PMIC receives an incoming-call event 1140 and transitions to a
call-routing mode (state 1110) in which the PMIC consults its
routing logic 430. The routing logic 430 is customized by the user
and prescribes the action to be taken in response to an incoming
call. In the preferred embodiment, the PMIC is adapted to perform
one or more of the following: (1) permit the incoming call to ring
at the user PBX phone without intervention, (2) transfer the
incoming call to the user's PMIC, (3) transfer the incoming call to
another device. e.g., the user's cell phone, (4) transfer the
incoming call to another PBX phone, or (5) transmit an instant
message to the caller. In the preferred embodiment, the user can
define individual call-routing rules that prescribe how to respond
to the incoming calls as a function of when the call is received,
the telephone number or extension of the caller, the time of day
and day of week, and the user's presence-state, for example.
[0070] If the routing logic 430 prescribes no action and the call
recipient answers the PBX phone, the PMIC receives an off-hook
event 1142 from the PBX 110. The PMIC process 1100 advances to an
on-phone presence-state (state 1112), as illustrated in FIG. 12A,
as well as a concurrent media session (CMS) setup (state 1114). The
on-phone presence-state (state 1112) is consistent with the
on-phone P-S processing (state 1104) described above. As
illustrated in the CMS setup procedure 1300 of FIG. 13 associated
with the CMS setup (state 1114), the PMIC uses the extension and or
phone number from the off-hook event received (step 1310) to
determine (step 1320) whether to initiate a media session
concurrently with the telephonic communication that began when the
phone was answered. A media session as used herein refers to a
network-domain dialogue between the caller and call recipient
established and maintained separate from the telephonic
communication. In the preferred embodiment, the concurrent media
session may take one of more of the following four forms: (1) a
"message session" such as a SIP instant message, (2) a "text
session" such as a SIP text chat session, (3) a "multimedia
session" in which a SIP video or audio is exchanged, (4) a document
exchange session, or (5) computer GUI interface sharing such as a
window-based operating system's "desktop sharing."
[0071] Referring again to FIG. 13, the CMS testing (step 1330) is
answered in the affirmative if, for example, call recipient's PMIC
is configured to automatically attempt to initiate a CMS with all
incoming PBX calls, or if the incoming call is from a PBX extension
included in a group of one or more numbers pre-selected or
otherwise approved by the call recipient. The selection of the
type(s) of CMS(s) to be established are determined from
user-defined CMS configuration parameters maintained by the call
recipient's PMIC handler 434. A CMS configuration parameter may be
set with a default value so that a text chat session or a video
session, for example, is automatically established in response to a
telephone call. Independent of the initial session type, either
user may then manually escalate to a supplemental CMS including
document share, screen share mode, or video session, for example.
The one or more CMSs are initiated with a session request, e.g., a
SIP message, directed from the recipient's PMIC to the caller's
PMIC or other SIP conference calling center, e.g., a multi-point
control unit known to those skilled in the art. If the session
request is accepted with a SIP OK message, the
session-request-answered testing (step 1360) is indicated in the
affirmative and the media session launched (step 1370) between the
PMICs of the caller and recipient. In the preferred embodiment, the
CMS may be maintained or terminated separate and independent of the
telephonic communication. Alternately, the CMS sessions could be
terminated with the telephone communication session ended.
[0072] Referring again to FIG. 11, the PMIC process 1100 proceeds
to passively monitor (state 1106) the network 150 for any events
signifying a change in the ongoing telephonic communication. When
the phone is hung up, for example, the PBX 110 transmits an on-hook
event 1136, e.g. a CTI message, to the recipient's PMIC that causes
the PMIC process 1110 to transition to the off-phone P-S processing
(state 1108). In the off-phone P-S processing of FIG. 12B,
associated with the phone P-S state 1108, the PMIC consults (step
1250) its local subscriber table 432 to identify the call
recipient's current presence-state subscribers. If one or more
subscribers are identified, the subscriptions testing (step 1260)
is answered in the affirmative and each subscribers sent (step
1270) an P-S status event, e.g., a SIP message, indicating the
availability status of the call recipient immediately prior to
going off-hook to answering the call. In an alternate embodiment,
the availability status sent to each subscriber is on-line
status.
[0073] Apart from the monitoring function (state 1106), the PMIC in
some embodiments is also adapted to issue commands to the PBX 110
to alter the telephonic communication involving the associated PBX
phone. In the preferred embodiment, the caller may alter the
ongoing telephonic communication by taking one of the following
actions: (1) terminate the call, (2) place the call on hold, (3)
transfer the call, or (4) establish a conference call with one or
more additional parties. The user may terminate the call from the
PMIC by issuing a terminate command 1162, e.g. a CTI message, that
instructs the PBX 110 to end (state 124) voice communications with
the user' PBX phone. The user may also issue a hold command 1134A,
e.g., a CTI message, to temporarily discontinue the voice
communications, after which the PMIC process 1100 resumes passively
monitoring (state 1106) the PBX 110. An analogous release-hold
command 1134B may be issued by the user from the PMIC to remove the
hold and enable voice communication.
[0074] Prior to ending the call, the user may also transfer the
call from the PBX phone to another device by issuing a transfer
command to the PBX 110. Depending on the identifier--URI, phone
number, or extension--the PBX 110 may transfer the call to the
user's PMIC, the user's cell phone, or another PBX extension, for
example. When transferred by command 1144 to the user's PMIC, the
PMIC process 1100 transitions to the PMIC session setup (state
1116) in which the PMIC and PBX 110 exchange SIP INVITE and OK
messages necessary to establish a VoIP session (state 1118) to
replace the telephonic communication. While in the PMIC VoIP
session (state 1118), the user acting through the PMIC GUI 436 can
issue a PBX phone transfer command 1148 to restore the telephonic
communication (state 1106), issue a SIP BYE 1158 message to end the
call (state 1124), or issue an external-device transfer command
1160 causing the PBX 110 to forward (state 1120) the call to any
device specified by the user.
[0075] In addition to permitting an incoming call to be answered at
the user's PBX phone, the call routing logic 430 may be configured
to cause the PMIC in the call routing mode (state 1110) to
automatically respond with one or more of the following actions:
(1) transfer an incoming call to the PMIC session setup (state
1116), transfer or forward the call to an external device (state
1112), or (3) reply with a message to the caller's PMIC using an
Instant Message. In the preferred embodiment, routing logic 430 is
configured by the user to direct calls depending on the caller's
identification, the time, and the date, for example.
[0076] The flow diagrams in FIGS. 14 through 20 discussed below
illustrate various aspects of the PMIC processing 1100 of the
preferred embodiment. These figures are provided by way of example
and not limitation.
[0077] Illustrated in FIG. 14 is flow diagram depicting the method
of distributing telephonic presence-state notices in the PBX system
100. Prior to configuring a user's PMIC to perform P-S
notification, a user generally transmits a registration command to
the PBX 110 to associate the user's PMIC with the user's phone
extension. This causes the PBX 110 to transmit subsequent event
messages pertaining to the user's PBX phone to the user's PMIC. The
class of events transmitted by the PBX to a PMIC generally
includes, but is not limited to: off-hook plus digits events,
off-hook plus extension events, extension-dialed events, transfer
events, incoming-call events, and answer events. In the following
examples illustrated in FIG. 14 through FIG. 20B, the first user
PBX phone 130 is identified by extension number x1234, the first
user PMIC 140 identified by URI 1234@proxy.com, the second user PBX
phone 131 is identified by extension number x5678, and the second
user PMIC 141 identified by URI 5678@proxy.com.
[0078] The registration command 1402 causes the PBX 110 to send to
the first user's PMIC various CTI events relating to the first
user's phone 130. The registration command 1402 may require that
the first user 120 enter a user identifier and password, although
other forms of authentication may be implemented. Similarly, the
PBX 110 is able to associate CTI commands from this first user's
120 PMIC 140 with the phone 130 extension.
[0079] At some later point in time, when the first user 120 picks
up the phone 130, an off-hook signal 1404 is relayed by the PBX 110
to the first user PMIC 140 in the form of an off-hook event,
preferably a CTI off-hook message 1406. Receipt of the CTI event
stimulates the PMIC 140 to automatically change the presence-state
for the first user to "on-phone" state. As prescribed by the
on-phone presence-state processing 1200, the PMIC 140 consults
(method 1200) its subscriber table 432 and transmits a notify
message 1408, 1410 to all subscribers 121, 122 by way of the
associated PMICs 141, 142. The notify message is preferably a SIP
on-phone message advertising the change in the first user's
telephonic availability.
[0080] When the first user completes the call, the on-hook signal
1412 from the first user phone 130 causes the PBX 110 to send the
first user's PMIC 140 an on-hook event 1414, preferably a CTI
message. As prescribed by the off-phone present state processing
1250, the PMIC 140 consults (method 1250) the subscriber table 430
and notifies all subscribers 141, 142 of the change in the presence
state by way of a SIP notify messages 1416, 1418. In the preferred
embodiment, the presence state indicated by the SIP notify messages
1416, 1418 is the presence state that existed just prior to the
placement of the call. In an alternative embodiment, the presence
state sent when the user goes off-phone may be "on-line" notice.
The selection between the two embodiments might be a
user-manageable setting.
[0081] One skilled in the art will appreciate that the linkage
between the PBX phone operation and the presence state is performed
entirely within the associated PMIC endpoint itself. Moreover, the
presence-state for the user is changed automatically based on
receipt of a CTI event without the user manually changing his or
her presence state via GUI interaction or other manual input. A
principal advantage of this method of presence integration is that
it can completely coexist and fully interoperate with all other
presence servers, presence collection/distribution servers, and any
other SIP proxy servers that might be operational within the
network 150. The proposed method is also highly scalable, since it
each PMIC is only responsible for the presence management of its
associated user PBX phone.
[0082] In some embodiments, the PBX 110 is both the source of CTI
events and recipient of CTI commands. One skilled in the art will
recognize, however, the a PBX may employ a separate and external
CTI server (not shown) that provides fan-out capability, user
authentication, and other CTI management tasks, as well as protocol
translation between the PBX and the CTI client, for example.
[0083] Illustrated in FIG. 15 is a flow diagram demonstrating the
use of a networked intermediate server with which the PBX and one
or more PMICs may interoperate. The CTI server 1502 is adapted to
relay messages between the PBX 110 and one or more PMICs using CTI
and/or extensible Markup Language (XML) protocols between the CTI
server 1502 and the one or more PMICs 120, 121. The proxy server
1502 relays CTI messages between the CTI server 1502 and the PBX
110 using the CSTA CTI protocol, for example. Other protocol
translations might also be possible including, but not limited to,
HTTP using Get or Post messages via a dedicated IP socket, or SIP
using textual information transmitted with SIP MESSAGEs sent
between the CTI server 1502 and a PMIC.
[0084] As illustrated in FIG. 15, a first user PMIC 140 transmits a
registration command 1510, preferably a CTI or XML message, to the
CTI server 1502. The registration command 1510 comprises the
extension number of the first user phone 130 and enables the CTI
server 1502 to create an association between the first user PBX
phone 130 and the first user PMIC 140. When the first user phone
130 is used to place a call or answer a call, the PBX 110 relays
the off-hook signal 1512 to the CTI server 1502 in the form of a
CTI off-hook event 1514. The server 1502, in turn, forwards the
CTI/XML off-hook event 1516 to the first user PMIC 140. Reception
of CTI off-hook event 1516 stimulates a change in first user's
presence state that is propagated to any subscribers via an
off-phone notification event 1518, e.g., a SIP message. Similarly,
an on-hook signal 1520 is transmitted to the CTI server 1502 in the
form of a CTI on-hook event 1522, then transmitted to the first
user PMIC 140 in the form of CTI/XML off-hook event 1524. The first
user identifies (step 1250) the presence state subscribers to be
sent a SIP notify event 1526. One skilled in the art will
appreciate that the presence state management in the one or more
PMICs of FIG. 14 is functionally equivalent to those in FIG. 14,
independent of whether the event messages originating from the PBX
110 are sent directly to the PMICs or indirectly via the CTI server
1502.
[0085] Illustrated in FIG. 16A is a flow diagram demonstrating the
procedure for establishing a first category of CMS between calling
parties. In this example, a CMS in the form of a SIP session is
automatically initiated between a caller and recipient in the PBX
system 100 in response to a telephone call. For purposes of
demonstration, let the first user phone 130 have extension number
x1234 and the second user phone 131 have extension number x5678.
When the first user 120 depresses Dual Tone Multi Frequency (DTMF)
keys on the PBX phone 130 to call the second user 130, an off-hook
signal 1602 comprising the call recipient's extension is
transmitted to the PBX 110. In addition to the ring signal 1606
transmitted (step 720) to the second user's phone 131, the PBX 110
also generates (step 730) an extension-dialed event 1604 to the
caller's computer, PMIC 140, as notice that a call has been placed
to the extension number x5678. Similarly, the second user's PMIC
141 is notified via the incoming-call event 1608 of the incoming
call from extension x1234.
[0086] If the incoming call is answered with off-hook signal 1610,
the PBX 110 puts the first user phone 130 and second user phone 131
in telephonic voice communication 1616. The CTI-enabled PBX 110
also responds to the off-hook signal 1610 with a first
call-answered event 1612 transmitted (step 1020) to the second
user's PMIC 141 as well as a second call-answered event 1614
transmitted (step 1040) to the first user's PMIC 140.
[0087] In response to the first call-answered event 1612, the
second user's PMIC 141 automatically initiates (step 1650) a media
session, preferably a SIP chat session, concurrent with the
telephonic voice communication 1616. The process of initiating
(step 1650) the media session is set forth in greater detail in CMS
setup 1114 of FIG. 13. In this example, the media session is a SIP
session including a simple SIP:MESSAGE message sent from second
user's PMIC 141 to the first user's PMIC 140. In order to generate
this SIP message 1620, in the preferred embodiment, the second
user's PMIC 141 derives the SIP URI of the first user's PMIC 140 in
accordance with a SIP dial-plan. The dial-plan associates an
extension, e.g., abcd, included in an event message with a SIP URI,
e.g., SIP:abcd@someproxy.com. In this manner, the second user PMIC
141 extracts the extension number 1234 from the incoming-call event
1608 and generates a SIP MESSAGE transmitted to SIP:
1234@proxy.com. Other suitable dial-plans that allow the call
recipient's PMIC to deduce the caller's URI from the calling
extension are also possible. For example another dialing plan might
associate extension 1234 with SIP:user91234@proxy.com where user
1234's PMIC has this SIP URI.
[0088] After the SIP exchange is completed with SIP OK 1622, SIP
text messaging windows are open on both first user's PMIC 140 and
second user's PMIC 141, thereby allowing the first user 120 and
second user 121 to text chat with one another concurrent with the
voice communication 1616. One skilled in the art will appreciate
that there is no need for the first user 120 or second user 121 to
appear on each other's contact lists, nor a need for either user to
lookup an IP address or SIP URI. Instead, the SIP session is
established automatically based on the PBX call.
[0089] Illustrated in FIG. 16B is a flow diagram demonstrating a
second procedure for establishing a CMS between calling parties. In
this example, the various signals, CTI event messages, and SIP
messages in FIG. 16B are replicated from FIG. 16A beginning with
the off-hook plus dialed number signal 1602 through the SIP MESSAGE
1620. Here, however, the presence of the SIP MESSAGE 1620, and the
corresponding SIP: OK, has established a line of communication
between first user 120 and second user 121 that may be exploited to
open additional forms of communication. After the SIP session
signified by SIP MESSAGE 1620 has been between established, either
the first user 120 or the second user 121 may escalate the
interaction to other forms of supplemental CMS using built-in
capabilities of RTC, for example. In the preferred embodiment,
either call participant may establish a supplemental CMS, e.g., a
document exchange or a screen sharing session, that runs in
parallel to the SIP:MESSAGE 1620. The supplemental CMS 1624 may be
manually selected (step 1652) by a user via the user's PMIC GUI 436
or other form of selection input device.
[0090] Illustrated in FIG. 16C is a flow diagram demonstrating a
third procedure for establishing a CMS between calling parties.
Here, the various signals, CTI event messages, and SIP messages are
replicated from FIG. 16A beginning with the off-hook plus dialed
number signal 1602 through the SIP MESSAGE 1620. In this example,
the first user 120 and second user 121 have desktop video cameras
used by the CMS handler 434 of each user's PMIC 140, 141 to
automatically setup (step 1654) a supplemental CMS such as video
session 1626 with the primary CMS session 1620. The call
recipient's CMS handler 434 automatically issues an additional SIP
INVITE containing video session description protocol (SDP)
information. In the preferred embodiment, the video session is a
user-manageable setting, thereby allowing a call recipient to
configure the CMS handler 434 to: (1) automatically enable and
start the camera for every call, (2) fully disable the camera to
prevent the camera from starting, (3) manual enable the camera to
start at the discretion of the user, or (4) selectively enable the
camera to start depending on the caller identification, i.e.,
caller ID.
[0091] As illustrated in more detail below, the integration of a
CTI client capability into a PMIC permits the user to execute
standard telephone set control functions from the individual's
computer. In the preferred embodiment, the PMIC is adapted to
transmit PBX call control commands including, but not limited to,
make-call commands to initiate a call, answer-call commands to
accept an incoming call, hold-call commands to temporarily pause an
on-going call at the PBX, transfer-call commands to redirect a call
between the PBX phone and user PMIC or other device,
conference-call commands to establish a call with three or more
parties, and forward-call commands to direct a call to a device
specified by the user.
[0092] Illustrated in FIG. 17 is a flow diagram demonstrating a
PBX-supported call initiated from a PMIC. First, the user enters a
destination telephone number into the user's PMIC GUI and activates
a make-call routine in the PMIC controller. The PMIC issues a
make-call command 1702 that causes the PBX 110 to issue a ring
signal 1704 to the user's phone 130. After the handset is picked up
and an off-hook signal 1706 transmitted, the PBX 110 places the
call to the destination number corresponding to second user phone
131, for example, via a ring signal 1708. When the second user
phone 131 is answered and an off-hook signal 1710 transmitted, the
parties are enabled for telephonic voice communications 1712, 1714.
In another embodiment, the caller's PBX phone 130 automatically
enters a hands-free speakerphone mode and the recipient called
immediately after the destination number is entered at the PMIC
140.
[0093] Illustrated in FIG. 18A and FIG. 18B are flow diagrams
demonstrating an on-going communications being transferred between
a user PBX phone and the associated PMIC. In this embodiment, the
PMIC is adapted to interoperate with a PBX 110 enabled with SIP or
other VoIP protocol in addition to CTI client functionality. This
PBX system, referred to as a SIP-PBX, has native SIP capabilities
including the ability to make and receive SIP voice calls.
[0094] As illustrated in FIG. 18A, an enterprise worker may
transfer an on-going call on the PBX phone to the user's PMIC. At
any time during a telephonic voice conversation 1802, 1804 between
the first user phone 130 and the second user phone 131, a user may
transfer the call from to his or her PMIC 141 by issuing a PMIC
transfer command 1806, preferably a CTI message, comprising the
identifier of the device to which to transfer the call. In the case
of a PMIC 141 enabled with a SIP user agent, the transfer command
1806 may include the SIP URI used by the PBX 110 to execute a call
transfer to the PMIC SIP voice client. When the SIP INVITE 1808 to
5678@proxy.com is accepted by the PMIC 141 by means of a SIP OK
message 1810, the PBX 110 bridges the first leg of the conversation
1814 with the first user phone 130 in the PDSV domain with the
second leg of the conversation 1816 with the second user PMIC 131
in the SIP domain. In the preferred embodiment, the SIP URI is
derived from extension number of the user phone with which it is
associated.
[0095] As illustrated in FIG. 18B, the second user 121 may at any
time transfer the SIP domain call 1816 directed to the second user
PMIC 141 back to the second user PBX phone 141 A PBX phone transfer
command 1818, e.g. a CTI message, comprising the 110 second user's
phone extension, number x5678, is issued by the second PMIC 141 to
the PBX 110. Upon receipt, the PBX 110 terminates the SIP session
with a SIP BYE message 1820 and enables the PDSV voice
communication 1826 between the PBX 110 and the second user phone
131.
[0096] As illustrated in FIG. 19, a PMIC may also be used to answer
an incoming call destined to a PBX phone independently of the
user's PBX phone. In response to an incoming call 1902, the PBX 110
in the preferred embodiment transmits a ring signal 1906 an
incoming-call event 1908, e.g. a CTI message, to the call
recipient's PMIC 141. The second user 121 may then click an
answered button in the PMIC GUI causing it to issue an answer
command 1910 and transfer command 1912. The transfer command 1912
comprises the identification of the device to which the call is to
be forwarded. The identification of the PMIC 141 is the SIP URI,
SIP:5678@proxy.com. In response, the PBX 110 issues a SIP INVITE
message 1914, to which the PMIC 141 automatically responds with a
SIP OK message 1916. The subsequent conversation between the caller
120 and recipient 121 includes PDSV domain voice 1920 between the
caller 120 and SIP PBX 110, and SIP domain VoIP 1922 between the
SIP PBX 110 and recipient's PMIC 141.
[0097] Illustrated in FIG. 20A and FIG. 20B are flow diagrams
demonstrating an incoming call to a PBX phone being automatically
processes by an associated PMIC without user intervention. In FIG.
20A, the PMIC answers an incoming call to a user's PBX phone and
then forwards the call to another device previously specified by
the user.
[0098] In response to an incoming call 2002, the PBX 110 in the
preferred embodiment transmits ring signal 2006 to the second user
phone 131 and an incoming-call event 2008 to the call recipient's
PMIC 141. Upon receipt of the incoming-call event 2008, the second
user PMIC 141 implements call routing processing (state 1110) that
dictates how this call is to be treated. If the call routing logic
430 of FIG. 4B indicates that the call should be transferred to
another device, the second user PMIC 141 issues an answer-call
command 2010 preventing the PBX 110 from forwarding the call in
accordance with its no-answer procedure, e.g. voice mail 206. The
second user PMIC 141 also issues to the PBX 110 a call-transfer
command 2012 identifying the destination device to which the call
is to be forwarded, e.g., device ABCD. The destination device may
be another PBX extension, a PSTN telephone, or a SIP user
agent.
[0099] The call routing logic 430 in the preferred embodiment
comprises user-managed preferences include forwarding criteria and
the action to be taken when the forwarding criteria are satisfied.
These criteria may include the phone number or extension of the
calling party and the time-of-day and date, for example. The call
routing logic 430 may dictate that (1) on Wednesday evenings the
call should be answered and transferred to PBX phone extension
number x6789, on (2) Thursday evenings the call should be answered
and transferred to John@acme.com, and (3) at all other times, the
call is not answered by the PMIC, thereby allowing the PBX 110 to
automatically forward to call voicemail 206 if not answered.
[0100] The call routing logic 430 in some embodiments may also
depend on the presence state of its user. For example, if a user's
presence state is set to "away," determined either via manual
operation or automatically in the absence of keyboard activity for
a period of time, the call routing logic 430 may be configured to
forward to an incoming call to the extension of an administrative
assistance. Similarly, an incoming call might be directed to the
SIP user agent of another enterprise colleague selected by the
user, thereby providing an alternative point of contact while the
user is unavailable or out of the office. In the preferred
embodiment, the call routing logic 430 is in the form of a script
created by the user, although it may also be configured via a
graphical and or menu-based interface on the PMIC GUI 436.
[0101] The call routing logic 430 of a PMIC in some embodiments
also includes the SIP text messaging and document transfer
capabilities as part of the call treatment for incoming and
outgoing calls at the PBX phone. Illustrated in FIG. 20B is a flow
diagram demonstrating an instant message being transmitted by a
PMIC in response to an incoming call. The PBX 110 responds to
incoming call 2002 with ring signal 2006 and an incoming-call event
2008 sent to the call recipient's PMIC 141. Upon receipt of the
incoming-call event 2008, the second user PMIC 141 implements call
routing processing 1110 that dictates how this call is to be
treated. When configured accordingly, the second user's PMIC 141
transmits an instant message 2020 from the user's PMIC to the
caller's PMIC 140. The caller's SIP URI, SIP: 1234@proxy.com, is
derived from the caller's extension, number x1234, learned by the
second user's PMIC 141 from the preceding incoming call event
2008.
[0102] The instant message may include a standardized greeting or a
customized Instant Message including information specifically
intended for the caller about. A person may, for example, generate
a personal message including the anticipated return time or an
alternate contact number. Similarly, the call routing logic 430 in
some embodiments is adapted to transmit a document that may contain
text, graphics, spreadsheet, or other information of interest to
the caller in response to an incoming call directed to a specific
PBX extension.
[0103] After the instant message 2020, the incoming call may
further processed in any number of ways defined by the call routing
logic 430. In this example, the second PMIC 141 causes the PBX 110
to transfer the incoming call to device ABCD using transfer command
2022.
[0104] In some embodiments, the caller's PMIC may also be
configured to respond to the call recipient's instant message with
another instant message sent to the call recipient's PMIC 141. For
example, when the second user 121 receives a telephone call from
extension number x1234, the call routing logic 432 generates the
appropriate URI and sends an instant message to
SIP:SecondUser@pda.com to inform the second user 121 that the first
user phone 131, i.e., extension number x1234, had called. The call
routing logic 430 may be tailored to inform a call recipient of the
call and the time of the call.
[0105] The call routing logic 430 may also be configured to
automatically send an instant message when an outbound call is
placed from the PBX phone associated PMIC. A specific SIP emergency
message, for example, may be sent to a pre-selected SIP user when
the Emergency 911 number is dialed.
[0106] Illustrated in FIG. 21 is a functional block diagram of a
user PMIC with a plurality of selectable SIP user agents. In
addition to Microsoft's RTC SIP client 424 and a CTI client 420
discussed above, a PMIC 2100 may further include one or more
additional SIP instant messaging applications such as a SAMETIME
client 2102 by IBM Lotus Corp. and/or any other commercial SIP User
Agent Client The user may select one of the plurality of SIP client
via PMIC GUI 436, for example, by entering a user-selectable
parameter causing the SIP/IM selection module 2110 to use the
selected SIP client for subsequent IM exchanges. To aid in the
selection, the various features supported by each individual SIP
client may be indicated as present or not present, or selectable
and non-selectable. As with other GUIs, the features that are not
present in a particular client may be indicated by representing the
feature in greyed-out text or icon form. To the degree that two or
more SIP clients support common functionality, in the preferred
embodiment the user experience is identical and independent of the
SIP client selected.
[0107] Illustrated in FIG. 22 is a CTI server with which the
present invention may be made to interoperate with one of a
plurality of different types of PBX systems. The CTI server 2200 in
this embodiment comprises a plurality of PBX interfaces from which
the network administrator may choose. Using the PBX selection 2208,
for example, the system administrator may configure the CTI server
2200 to use either PBX-A interface 2202, PBX-B interface 2204, or
PBX-C interface 2206, depending on the hardware and vendor
requirements of the PBX 110. CTI server 2200 capable of
communicating with multiple types of PBXs using a single common CTI
interface 2210 protocol to/from a CTI client are available from
Genesys Telecommunications Laboratories, Inc. of San Fransisco,
Calif., for example. In this manner, the PMIC is generally able to
provide the functionality of the several embodiments in a manner
independent of the type PBX system or vendor.
[0108] Although the description above contains many specifications,
these should not be construed as limiting the scope of the
invention but as merely providing illustrations of some of the
presently preferred embodiments of this invention.
[0109] Therefore, the invention has been disclosed by way of
example and not limitation, and reference should be made to the
following claims to determine the scope of the present
invention.
* * * * *