U.S. patent application number 11/268362 was filed with the patent office on 2007-05-24 for conference presence based music-on-hold suppression system and method.
Invention is credited to Jack Jachner.
Application Number | 20070117508 11/268362 |
Document ID | / |
Family ID | 37762602 |
Filed Date | 2007-05-24 |
United States Patent
Application |
20070117508 |
Kind Code |
A1 |
Jachner; Jack |
May 24, 2007 |
Conference presence based music-on-hold suppression system and
method
Abstract
A private branch exchange (PBX) (or network hosted device) is
described herein that is capable of obtaining information (e.g.,
in-a-conference presence state) that indicates a user is
participating in a multi-party conference call which is being
hosted by an external conference/collaboration bridge and is
further capable of disabling a music-on-hold feature on an
extension associated with a device belonging to the user such that
if the user places the device on-hold then no sound (e.g., music,
radio) will be injected into the multi-party conference call.
Inventors: |
Jachner; Jack; (Plano,
TX) |
Correspondence
Address: |
ALCATEL USA;INTELLECTUAL PROPERTY DEPARTMENT
3400 W. PLANO PARKWAY, MS LEGL2
PLANO
TX
75075
US
|
Family ID: |
37762602 |
Appl. No.: |
11/268362 |
Filed: |
November 7, 2005 |
Current U.S.
Class: |
455/3.06 ;
455/416 |
Current CPC
Class: |
H04M 3/42365 20130101;
H04M 3/428 20130101; H04M 3/56 20130101; H04M 3/42059 20130101;
H04M 3/42221 20130101; H04M 2203/5027 20130101 |
Class at
Publication: |
455/003.06 ;
455/416 |
International
Class: |
H04H 7/00 20060101
H04H007/00; H04M 3/42 20060101 H04M003/42 |
Claims
1. A method for enabling a device to automatically disable a
music-on-hold feature, said method comprising the steps of:
obtaining information indicating that a person is likely using a
communication unit connected to the device to participate in a
multi-party conference/collaboration session that is being hosted
by an external conference/collaboration bridge; and disabling the
music-on-hold feature on a device's extension associated with the
communication unit such that if the person places the communication
unit on-hold then no sound will be injected into the multi-party
conference/collaboration session.
2. The method of claim 1, further comprising the step of
re-enabling the music-on-hold feature on the device's extension
after determining that the person is no longer participating in the
multi-party conference/collaboration session.
3. The method of claim 1, wherein said obtaining step further
includes a step of inferring at the device that the person is
participating in the multi-party conference/collaboration session
by analyzing a phone number called by the person or a phone number
used to call the person and then determining that the phone number
is associated with the external conference/collaboration
bridge.
4. The method of claim 1, wherein said obtaining step further
includes a step of receiving the information that indicates the
person is participating in the multi-party conference/collaboration
session from the external conference/collaboration bridge which
analyzes a phone number of a called party or a calling party and
then maps that phone number to the communication unit used by the
person.
5. The method of claim 1, wherein said obtaining step further
includes a step of subscribing with a presence system to obtain an
in-a-conference presence state that indicates the person is likely
using the communication unit to participate in the multi-party
conference/collaboration session.
6. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with an conference/collaboration
connector to obtain presence information which indicates a phone
number of a party that called or was called by the external
conference/collaboration bridge to participate in the multi-party
conference/collaboration session; and a rules engine that
determines that the phone number of the party is associated with
the communication unit used by the person and then infers that the
person is participating in the multi-party conference/collaboration
session and sets the in-a-conference presence state.
7. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with a telephony connector to
obtain presence information indicating that the person used the
communication unit to call or receive a call from a particular
phone number; and a rules engine that determines that the
particular phone number is associated with the external
conference/collaboration bridge and then infers that the person is
participating in the multi-party conference/collaboration session
and sets the in-a-conference presence state.
8. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with a calendar connector to obtain
presence information which indicates the person is scheduled at a
particular time to participate in the multi-party
conference/collaboration session; and a rules engine that
determines this is the particular time in which the multi-party
conference/collaboration session is scheduled to take place and
then infers that the person is participating in the multi-party
conference/collaboration session and sets the in-a-conference
presence state.
9. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with an Instant Message connector
to obtain presence information which indicates that the person has
manually set the in-a-conference presence state.
10. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with an personal computer connector
to obtain presence information which indicates that the person has
used a graphical user interface to call a particular phone number;
and a rules engine that determines the particular phone number is
associated with the external conference/collaboration bridge and
then infers that the person is participating in the multi-party
conference/collaboration session and sets the in-a-conference
presence state.
11. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with an email connector to obtain
presence information which indicates that the person has received
and/or sent an email indicating that they are scheduled at a
particular time to participate in the multi-party
conference/collaboration session; and a rules engine that
determines this is the particular time in which the multi-party
conference/collaboration session is scheduled to take place and
then infers that the person is participating in the multi-party
conference/collaboration session and sets the in-a-conference
presence state.
12. The method of claim 5, wherein said presence system includes: a
presence server that interfaces with a connector associated with a
PC, PDA or mobile phone to obtain presence information which
indicates that the person has used a graphical user interface, a
keyboard, a keypad, a pointer or a mouse to manually set the
in-a-conference presence state.
13. The method of claim 1, wherein said device is a private branch
exchange (PBX) or a network hosted device that offers the
music-on-hold feature.
14. A device, comprising: a processor for obtaining information
which indicates a user is participating in a multi-party
conference/collaboration session that is being hosted by an
external conference/collaboration bridge; and said processor for
disabling a music-on-hold feature on an extension associated with a
communication unit used by the user such that if the user places
the communication unit on-hold then no music or other sound will be
injected into the multi-party conference/collaboration session.
15. The device of claim 14, wherein said processor subscribes with
a presence system to obtain an in-a-conference presence state which
indicates that the user is participating in the multi-party
conference/collaboration session.
16. The device of claim 14, wherein said processor infers that the
user is participating in the multi-party conference by analyzing a
phone number called by the user or a phone number used to call the
user and then determining that the phone number is associated with
the external conference/collaboration bridge.
17. The device of claim 14, wherein said processor obtains the
information which indicates the user is participating in the
multi-party conference/collaboration session from the external
conference/collaboration bridge which analyzed a phone number of a
called party or a calling party and then mapped that phone number
to a communication unit associated with the user.
18. A presence system comprising: a presence server for collecting
presence information about a person; a rules engine for aggregating
the presence information and analyzing the aggregated presence
information to determine if an in-a-conference presence state
should be set which indicates that the person is likely using a
communication unit connected to a device to participate in a
multi-party conference/collaboration session which is being hosted
by an external conference/collaboration bridge; and said presence
server for publishing the in-a-conference presence state to the
device which then disables a music-on-hold feature on an extension
attached to the communication unit associated with the user such
that if the user places the communication unit on-hold then no
music or other sound will be injected into the multi-party
conference/collaboration session.
19. The presence system of claim 18, wherein: said presence server
interfaces with an conference/collaboration connector to obtain
presence information which indicates a phone number of a party that
called or was called by the external conference/collaboration
bridge to participate in the multi-party conference; and said rules
engine determines that the phone number of the party is associated
with the communication unit used by the person and then infers that
the person is participating in the multi-party conference and sets
the in-a-conference presence state.
20. The presence system of claim 18, wherein: said presence server
interfaces with a telephony connector to obtain presence
information indicating that the person used the phone to call or
receive a call from a particular phone number; and said rules
engine determines that the particular phone number is associated
with the external conference/collaboration bridge and then infers
that the person is participating in the multi-party
conference/collaboration session and sets the in-a-conference
presence state.
21. The presence system of claim 18, wherein: said presence server
interfaces with a calendar connector to obtain presence information
which indicates the person is scheduled at a particular time to
participate in the multi-party conference/collaboration session;
and said rules engine determines that this is the particular time
in which the multi-party conference/collaboration session is
scheduled to take place and then infers that the person is
participating in the multi-party conference and sets the
in-a-conference presence state.
22. The presence system of claim 18, wherein: said presence server
interfaces with an Instant Message connector to obtain presence
information which indicates that the person has manually set the
in-a-conference presence state.
23. The presence system of claim 18, wherein: said presence server
interfaces with an personal computer connector to obtain presence
information which indicates that the person has used a graphical
user interface to call a particular phone number; and said rules
engine determines that the particular phone number is associated
with the external conference/collaboration bridge and then infers
that the person is participating in the multi-party
conference/collaboration session and sets the in-a-conference
presence state.
24. The presence system of claim 18, wherein: said presence server
interfaces with an email connector to obtain presence information
which indicates that the person has received and/or sent an email
indicating that they are scheduled at a particular time to
participate in the multi-party conference; and said rules engine
determines that this is the particular time in which the
multi-party conference is scheduled to take place and then infers
that the person is participating in the multi-party conference and
sets the in-a-conference presence state.
25. The presence system of claim 18, wherein: said presence server
interfaces with a connector associated with a PC, PDA or mobile
phone to obtain presence information which indicates that the
person has used a graphical user interface, a keyboard, a keypad, a
pointer or a mouse to manually set the in-a-conference presence
state.
26. The presence system of claim 18, wherein said device is a
private branch exchange (PBX) or a network hosted device that
offers the music-on-hold feature.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention is related to a private branch
exchange (PBX) (or network hosted device) which can automatically
disable a music-on-hold feature for one of it's extensions that is
attached to a device (e.g., phone) which belongs to a user when
that user happens to be participating in a multi-party conference
call being hosted by an external conference/collaboration bridge.
This is desirable because if the user places their device on-hold
then no music or other sound will be injected into the multi-party
conference call.
[0003] 2. Description of Related Art
[0004] A PBX typically has a music-on-hold feature such that if a
user places their phone on-hold then the other party hears
music/radio/company information etc. . . . This is fine in most
situations. But, if the user is participating in a multi-party
conference call that happens to be hosted by an external
conference/collaboration bridge then this music-on-hold feature can
be problematic. In particular, if the user places their phone on
hold to take another phone call or to simply take a break from the
multi-party conference call then music (or some other sound) is
going to be played on the conference bridge to the annoyance of the
other participants.
[0005] Today, this problem can be addressed if the
conference/collaboration bridge has a voice activity detection
(VAD) system or a signal energy detection system which can detect
the conference legs that are contributing to the call. This enables
one to determine which conference leg happens to be playing the
music-on-hold when a participant is no longer participating in the
multi-party conference call. And, if the conference/collaboration
bridge has a graphical user interface (GUI) that can be used by a
conference host to mute the offending music that is flooding the
conference bridge because that particular participant has placed
their phone on-hold. However, this solution has several drawbacks
which include: (1) the multi-party conference call is disrupted
until the extension being used by the offending person is muted;
(2) the conference host needs to have access to the GUI; and
[0006] (3) the conference host needs to focus their attention on
solving this problem which can be very disruptive especially if
they are also speaking or presenting at the same time. Accordingly,
there has been and is a need to solve this problem which is done by
the present invention.
BRIEF DESCRIPTION OF THE INVENTION
[0007] The present invention includes a PBX (or network hosted
device) which is capable of obtaining information (e.g.,
in-a-conference presence state) that a user is likely participating
in a multi-party conference call which is being hosted by an
external conference/collaboration bridge and is further capable of
disabling a music-on-hold feature on an extension connected to a
device belonging to the user such that if the user places the
device on-hold then no music or other sound will be injected into
the multi-party conference call. Several different ways in which
the PBX (or network hosted device) can obtain this information so
it can disable the music-on-hold feature are described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] A more complete understanding of the present invention may
be obtained by reference to the following detailed description when
taken in conjunction with the accompanying drawings wherein:
[0009] FIG. 1 is a block diagram that is used to help explain
several different ways a PBX (or network hosted device) can obtain
information so it knows when to disable a music-on-hold feature for
a particular user in accordance with the present invention; and
[0010] FIG. 2 is a flowchart that illustrates the basic steps of a
method for enabling a PBX (or network hosted device) to
automatically disable a music-on-hold feature for a particular user
in accordance with the present invention.
DETAILED DESCRIPTION OF THE DRAWINGS
[0011] Referring to FIG. 1, there is illustrated a diagram which is
used to help describe several different ways a PBX 100 (or network
hosted device) can obtain information so it knows when to disable a
music-on-hold feature for one of its users 106 when they happen to
be participating in a multi-party conference call being hosted by
an external conference/collaboration bridge 114a. Although the PBX
100 is used herein to describe the present invention, it should be
appreciated that a network hosted device that has a music-on-hold
feature like, for example, Centrex, IP-Centrex, a fixed line voice
switch or a mobile voice switch . . . can implement the present
invention.
[0012] The PBX 100 needs to obtain information that person 106 is
participating with several other people 108 and 110 (only two
shown) in a multi-party conference call (shown as voice legs 112)
being hosted by the external conference/collaboration bridge 114a
before it can disable the music-on-hold for an extension 102
connected to the person's device 104 (e.g., office phone 104). This
capability is important because if person 106 places their device
104 on-hold then no sound will be injected into the multi-party
conference call. There are several ways the PBX 100 can obtain this
information which indicates that person 106 is participating in a
multi-party conference call being hosted by an external
conference/collaboration bridge 114a.
[0013] In one way, the PBX 100 obtains this information directly
from the conference/collaboration bridge 114a (shown as option #1).
In this case, the PBX 100 receives information 117 directly from
the conference/collaboration bridge 114a that indicates person 106
is participating in a multi-party conference call. The
conference/collaboration bridge 114a determines this information
117 by analyzing a phone number of a called/calling party that may
be participating in a multi-party conference call and by mapping
that phone number to the device 104 used by person 106. Upon
receiving this information 117, the PBX 100 (in particular the
processor/music-on-hold suppression unit 114b) disables the
music-on-hold feature for that person's device 104.
[0014] In another way, the PBX 100 determines by itself that person
106 is likely to be participating in a multi-party conference call
which is being hosted by the external conference/collaboration
bridge 114a (shown as option #2). In this case, the PBX 100 infers
that person 106 is participating in a multi-party conference call
by analyzing either a phone number called by person 106 or a phone
number calling the person 106 and determining that the phone number
is associated with the conference/collaboration bridge 114a. The
PBX 100 (in particular the processor/music-on-hold suppression unit
114b) then disables the music-on-hold feature for that person's
device 104.
[0015] In yet another way, the PBX 100 obtains this information in
the form of an in-a-conference presence state 116 from a presence
system 118 (shown as option #3). In this case, the presence system
118 collects real-time information about the activities of person
106 and if the collected information indicates that person 106 is
likely participating in a multi-party conference being hosted by an
external conference/collaboration bridge 114a then it sets and
publishes the in-a-conference presence state 116. To enable this
way, the PBX 100 subscribes with the presence system 118 to be a
watcher of person 106 so it can obtain published presence
information about person 106 which includes the in-a-conference
presence state 116. There are many different ways the presence
system 118 can collect this real-time information about person 106
and then determine/infer that person 106 is participating in a
multi-party conference call which is being hosted by the external
conference/collaboration bridge 114a. Some of these different ways
are described after a brief discussion is provided about the basic
structure/function of the presence system 118.
[0016] As shown, the presence system 118 includes a presence server
120 which is connected to a rules engine 121. Alternatively, the
presence server 120 could be co-located with the rules engine 121.
In either case, the presence server 120 is coupled via multiple
Session Initiation Protocol (SIP) interfaces (for example) to
various connectors 122a, 122b . . . 122g which in turn are coupled
to various devices 114a, 114b . . . 114g. In this example, the
connectors 122 include a conference/collaboration connector 122a, a
telephony connector 122b, a calendar connector 122c, an IM
connector 122d, a PC connector 122e, an email connector 122f and a
miscellaneous connector 122g. And, the devices 114 include the
conference/collaboration bridge 114a, a processor/music-on-hold
suppression unit 114b (shown located in PBX 100), a calendar server
114c, an IM server 114d, a PC 114e, an email server 114f and
miscellaneous devices 114g (e.g., personal digital assistant (PDA),
mobile phone, PC). For clarity, the description provided herein
about the presence system 118, the various connectors 122a, 122b .
. . 122g and the various devices 114a, 114b . . . 114g omits those
details that are well known in the industry and are not needed to
understand the present invention.
[0017] The presence server 120 collects a wide-variety of
information about the real-time activities of person 106 and then
the rules engine 121 aggregates and analyzes this presence
information in view of preference rules/policies and if appropriate
sets the in-a-conference presence state 116. Then, the presence
server 120 publishes the in-a-conference presence state 116 so it
can be received by the PBX 100. In this way, the PBX 100 knows that
person 106 is likely to be participating in a multi-party
conference call. Several different examples are described next to
indicate how the presence server 120 and rules engine 121 can
determine when to set the in-a-conference presence state 116.
[0018] In the first example, the presence server 120 interfaces
with the conference/collaboration connector 122a and obtains
presence information via the conference/collaboration bridge 114a
which indicates a phone number of a calling party (or a called
party) that called (or was called by) the external
conference/collaboration bridge 114a to participate in a
multi-party conference call. The rules engine 121 analyzes this
information (in view of other information) and determines that the
phone number of the calling party (or called party) is associated
with the device 104 that is used by person 106. The rules engine
121 then infers that person 106 is participating in a multi-party
conference call hosted by the external conference/collaboration
bridge 114a and sets the in-a-conference presence state 116. The
presence server 120 publishes the in-a-conference presence state
116. And, the PBX 100 after receiving the published in-a-conference
presence state 116 disables the music-on-hold feature for person's
device 104.
[0019] In the second example, the presence server 120 interfaces
with the telephony connector 122b and obtains presence information
via the PBX 100 which indicates that person 106 used device 104 to
call a particular phone number or to receive a call from a
particular phone number. The rules engine 121 analyzes this
information (in view of other information) and determines that this
particular phone number is associated with the external
conference/collaboration bridge 114a. The rules engine 121 then
infers that person 106 is participating in a multi-party
conference/collaboration call hosted by the external
conference/collaboration bridge 114a and sets the in-a-conference
presence state 116. The presence server 120 publishes the
in-a-conference presence state 116. And, the PBX 100 after
receiving the published in-a-conference presence state 116 disables
the music-on-hold feature for person's device 104.
[0020] In the third example, the presence server 120 interfaces
with the calendar connector 122c and obtains presence information
via the calendar server 114c which indicates that person 106 is
scheduled at a particular time to participate in a multi-party
conference call. The rules engine 121 analyzes this information (in
view of other information) and sets the in-a-conference presence
state 116 when the multi-party conference call is scheduled to take
place. The presence server 120 publishes the in-a-conference
presence state 116. And, the PBX 100 after receiving the published
in-a-conference presence state 116 disables the music-on-hold
feature for person's device 104.
[0021] In the fourth example, the presence server 120 interfaces
with the IM connector 122d and obtains presence information via the
IM server 114d which indicates that person 106 has manually set the
in-a-conference presence state 116. The presence server 120
publishes the in-a-conference presence state 116. And, the PBX 100
after receiving the published in-a-conference presence state 116
disables the music-on-hold feature for person's device 104.
[0022] In the fifth example, the presence server 120 interfaces
with the PC connector 122e and obtains presence information via the
PC 114e which indicates that person 106 has used a GUI in their PC
114a to call a particular phone number. The rules engine 121
analyzes this information (in view of other information) and
determines that this particular phone number is associated with the
external conference/collaboration bridge 114a. The rules engine 121
then infers that person 106 is participating in a multi-party
conference/collaboration call hosted by the external
conference/collaboration bridge 114a and sets the in-a-conference
presence state 116. The presence server 120 publishes the
in-a-conference presence state 116. And, the PBX 100 after
receiving the published in-a-conference presence state 116 disables
the music-on-hold feature for person's device 104.
[0023] In the sixth example, the presence server 120 interfaces
with the email connector 122f to obtain presence information via
the email server 114f which indicates that person 106 has received
and/or sent an email indicating that they are scheduled at a
particular time to participate in a multi-party conference call.
The rules engine 121 analyzes this information (in view of other
information) and sets the in-a-conference presence state 116 when
the multi-party conference call is scheduled to take place. The
presence server 120 publishes the in-a-conference presence state
116. And, the PBX 100 after receiving the published in-a-conference
presence state 116 disables the music-on-hold feature for person's
device 104.
[0024] In the seventh example, the presence server 120 interfaces
with the miscellaneous connector 122g and obtains presence
information via a miscellaneous device 114g (e.g., PDA, mobile
phone, PC). The presence information can indicate that person 106
has used a GUI, a keyboard, a keypad, a pointer, a mouse etc . . .
to manually set the in-a-conference presence state 116. The
presence server 120 publishes the in-a-conference presence state
116. And, the PBX 100 after receiving the published in-a-conference
presence state 116 disables the music-on-hold feature for person's
device 104.
[0025] As can be seen, the presence server 120 can collect a wide
variety of presence information about the real-time activities of
person 106 and then the rules engine 121 can analyze that
information and determine/infer that person 106 is likely
participating in a multi-party conference call which is being
hosted by the external conference/collaboration bridge 114a. Of
course, it should be appreciated that the presence server 120 can
also collect other types of presence information which were not
mentioned above but could be used by the rules engine 121 to
determine/infer that person 106 is likely participating in a
multi-party conference call which is being hosted by the external
conference/collaboration bridge 114a.
[0026] Referring to FIG. 2, there is a flowchart of the basic steps
of the method 200 for enabling the PBX 100 (or network hosted
device 100) to automatically disable the music-on-hold feature for
a user 106 when they happen to be participating in a multi-party
conference call which is being hosted by an external
conference/collaboration bridge 114a. Beginning at step 202, the
PBX 100 (in particular the processor/music-on-hold suppression unit
114b) obtains information that person 106 is using a device 104
(e.g., office phone 104) connected to the PBX's extension 102 so
they can participate in a multi-party conference/collaboration
session being hosted by an external conference/collaboration bridge
114a. As discussed above, the PBX 100 can obtain this information
directly from the conference/collaboration bridge 114a (see option
#1). The PBX 100 can also determine by itself that person 106 is
participating in a multi-party conference call being hosted by the
conference/collaboration bridge 114a (see option #2). In addition,
the PBX 100 can obtain this information (e.g., in-a-conference
presence state 116) from the presence system 118 (see option #3).
At step 204, the PBX 100 (in particular the processor/music-on-hold
suppression unit 114b) after obtaining this information disables
the music-on-hold feature for extension 102 which is associated
with the device 104 that is being used by person 106. At this time,
if person 106 places the device 104 on-hold then no sound will be
injected into the multi-party conference call. At step 206, the PBX
100 (in particular the processor/music-on-hold suppression unit
114b) re-enables the music-on-hold feature for extension 102 which
is associated with device 104 after a predetermined amount of time
has passed or when it is determined that person 106 is no longer
participating in the multi-party conference call.
[0027] Following are some additional features, advantages and uses
of the present invention: [0028] The PBX 100, the presence system
118 and the method 200 can support and monitor any number of people
even though only one person 106 shown and described herein. [0029]
The presence system 118 can be configured to error on the side of
safety when it is determining whether or not person 106 is
participating in a multi-party conference call and set the
in-a-conference presence state 116. Because, if the PBX 100
disables the music-on-hold feature and person 106 is not
participating in a multi-party conference then there is little if
any harm that can be done except that another person will not hear
music when they are placed on hold. [0030] The music-on-hold
suppression unit 114b could be located external to the PBX 100. In
this case, the music-on-hold suppression unit 114b would
communicate via a computer-telephony interface (CTI) with the PBX
100. This scenario is not shown in FIG. 1. [0031] The PBX 100 can
obtain other types of presence information from the presence system
118 in addition to the in-a-conference presence state 116. However,
the presence system 118 may have rules/policies that are used to
decide which presence information should be sent to the PBX 100.
[0032] Even though person 106 is described herein as participating
in a multi-party conference call. It should be understood that the
present invention can also be used if person 106 happens to be
participating in a collaboration session. [0033] The present
invention can be related and coupled with another invention
discussed in the following documents: [0034] U.S. patent
application Ser. No. 11/233,987 filed on Sep. 23, 2005 and entitled
"Telephony/Conference Activity Presence State". [0035] U.S. patent
application Ser. No.______ filed on ______ and entitled "System and
Methods for using Data about who is speaking in a Communications
Conference to Enhance Business use of Temporal Identification of
Those Participating and of Communications Conference Archives"
(Attorney Docket No. Alcatel FIT #139409).
[0036] The contents of these documents are hereby incorporated by
reference herein. [0037] An external conference solution provider
(customer premises based or carrier based) could provide this
conference presence service and PBX enhancement system as a value
added service to their customers. For example, Alcatel's eDial
product can be enhanced in accordance with the present invention
and then be coupled with a vendor's PBXs via a GETS-like CTI
connector. [0038] For a more detailed discussion about the basics
of the presence system 118, reference is made to the following
documents: [0039] Jack Jachner et al. "Rich Presence: A New User
Communications Experience" Technology White Paper, 8 pages,
copyrighted 1st quarter 2005. [0040] J. Rosenberg, "A Data Model
for presence", draft-ietf-simple-data-model-05 (work in progress),
Sep. 22, 2005. [0041] Rosenberg, J. "A presence Event package for
the Session initiation protocol (SIP)", RFC 3856, August 2004.
[0042] H. Shulzerine et al. "RPID: Rich Presence Extensions to the
presence Information Data Format (PIDF)",
draft-ietf-simple-rpid-08, (work in progress), Jul. 16, 2005.
[0043] Rosenberg, J. "Presence Authorization Rules",
draft-ietf-simple-presence-rules-03(work in progress), Jul. 20,
2005.
[0044] The contents of these documents are incorporated by
reference herein.
[0045] Although several embodiments of the present invention have
been illustrated in the accompanying Drawings and described in the
foregoing Detailed Description, it should be understood that the
invention is not limited to the embodiments disclosed, but is
capable of numerous rearrangements, modifications and substitutions
without departing from the spirit of the invention as set forth and
defined by the following claims.
* * * * *