1. Technical Field of the Invention
The present invention relates in general to a presence-based interactive communications system, and in particular, to dynamically updating presence information.
2. Description of Related Art
Presence-based interactive communication services facilitate more efficient and effective communication sessions by enabling callees (presentities) to publish, in real time, their presence information (such as, the availability, activity, local time, location, current status of the active devices/applications, etc.) and their preference information (e.g., device preferences) to callers (presence watchers). The presence and preference information improves the efficiency of establishing various types of communication sessions, such as voice, text and multi-media (video+) communication sessions.
Presence systems typically incorporate a presence server that manages presence information for a plurality of presentities. Currently, presence servers are programmed to modify presence information according to manual human commands or from specific triggers from presence sources, such as calendar/scheduler applications, telephone applications or instant messaging applications. The presence server collects presence information from the presence sources, and aggregates the presence information to reflect the presence state of the presentities.
For example, whenever a predefined presentity event occurs, such as turning on or off a presentity device, modifying the registration from a device, changing the instant messaging status on a device or entering a scheduled event into the presentity's calendar, the responsible presence source generates presence information to the presence server. By way of example, if a presentity has a meeting scheduled on his or her calendar from 10:00 a.m. to 12:00 p.m., at 10:00 a.m., the calendar/scheduler application notifies the presence server to set the presentity's presence status to “In a Meeting.” As another example, when a presentity initiates or answers a phone call, the telephone application notifies the presence server to set the presentity's presence status to “On the Phone.”
However, presence servers currently are not capable of tolerating ad-hoc or dynamic changes in the presence information. For example, if a presentity's presence status indicates that the presentity is “In a Meeting” from 10:00 a.m. to 12:00 p.m., but the meeting ends at 11:00 a.m. and the presentity does not have access to his or her computer to revise the presence information, the presence server will continue to provide incorrect presence information to any watchers of the presentity. In addition, the calendar/scheduler application will also continue to provide an incorrect schedule for the presentity to any viewers of the presentity's calendar. Therefore, what is needed is a presence system for dynamically updating presence information.
Embodiments of the present invention provide a communications system that is capable of dynamically updating presence information in a presence server using an interactive voice response system. The presence server statically collects presence information on a plurality of presentities. The interactive voice response system queries and receives dynamic updated presence information from a select one of the presentities and provides the updated presence information to the presence server to update the presence information for the select presentity with the updated presence information.
In one embodiment, the interactive voice response system is configured to receive the updated presence information as dual-tone multi-frequency signals. In another embodiment, the interactive voice response system includes a speech recognition application configured to receive the updated presence information. In a further embodiment, the interactive voice response system is configured to receive the updated presence information as data.
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:
Referring to
The presence system 100 further includes one or more presence user agents 140 (PUAs), a presence agent (PA) 150, a presence server 160 and one or more watchers 170 of the presentity 110. The PUAs 140 are capable of manipulating and providing presence information for the presentity 110. In
The presence information from each of the PUAs 140 is collected by one or more presence agents (PAs) 150. In
The presence server 160 is a physical entity that can operate as either the PA 150 or as a proxy server for routing requests from watchers 170 to the PA 150. The presence server 160 stores the presence information 180 and preference information 190 for a plurality of presentities 110. Thus, the PA 150, in combination with the presence server 160, is operable to receive presence information of the presentity 110 from the PUAs 140, receive requests from watchers 170 for the presence information and provide the presence information to the watcher(s) 170. When acting as a PA 150, the presence server 160 can also be co-located with a PUA 140.
The presence system 100 uses a presence protocol to provide presence services to presentities 110 and watchers 170. An example of a presence protocol that can be used in the presence system 100 is the Session Initiation Protocol (SIP), as described in J. Rosenberg, et al., “SIP: Session Initiation Protocol” RFC: 3261, June 2002 and in A. Roach, et al., “Session Initiation Protocol (SIP)—Specific Event Notification,” RFC: 3265, June 2002, each of which are hereby incorporated by reference. SIP is an application-layer control protocol used to create, modify and terminate communication (voice, text and/or multimedia) sessions. SIP can be used with other protocols, such as the Real-time Transport Protocol (RTP), the Real-Time Streaming Protocol (RTSP), the Session Description Protocol (SDP), the International Telecommunication Union—Telecommunications (“ITU-T”) H.263 standard (video CODEC), the G.711 and G.729 standards (audio CODECs), and other or additional standards or protocols. As will be appreciated, other or additional protocols and configurations may be used.
SIP networks are capable of routing requests from any user on the network to the server that maintains the registration state for a user. Thus, SIP networks enable a caller (watcher) to transmit a SUBSCRIBE request for presence information relating to a particular callee (presentity 110) to be routed to the presence server 160 that maintains the presence information for the presentity 110. In operation, the presence server 160 and PA 150 may be co-located with the SIP proxy/registrar for efficiency purposes.
Referring now to
In
Once a call connection is established between the user device 210 and the IVR system 230, the IVR system 230 queries the user (presentity) for updated presence information. The IVR system 230 can query for default presence/preference settings or can be programmed to query for specific presence/preference settings on a company-wide or individual employee basis. For example, one employee (presentity) may be presented with only presence setting options, while another employee may be presented with both presence and preference setting options. The user (presentity) navigates through the IVR system 230 to select the presence and/or preference settings to be updated. The user (presentity) enters the updated presence and/or preference information into the user device 210, which transmits the updated presence and/or preference information to the IVR system 230.
For example, in one embodiment, the IVR system 230 provides a list of menu options for the presentity to select from, and the user device 210 transmits the updated presence and/or preference information as dual-tone multi-frequency signals. In another embodiment, the user device 210 transmits the updated presence and/or preference information as speech, and the IVR system 230 includes a speech recognition application for receiving and interpreting the speech and converting the speech into updated presence and/or preference information. In a further embodiment, the presentity enters the updated presence and/or preference information as text or other type of data on the user device 210, and the user device 210 transmits the updated presence and/or preference data.
Upon receipt of the updated presence and/or preference information, a presence IVR control application 235 interfaces with the rich presence server 270 to update the presentity's presence and/or preference information. In one embodiment, the presence IVR control application 235 is implemented as part of the IVR system 230. In another embodiment, the presence IVR control application 235 is implemented as a separate application that communicates with the IVR system 230. The presence IVR control application 235 may interface directly with the rich presence server 270 or indirectly through the calendar/scheduler application 250.
The rich presence server 270 includes a message handler 275, a compositor 280, a preference engine 285, an adapter 290 and the preference server 160. The message handler 275 is configured to receive messages (e.g., SIP messages, HTTP messages, etc.) containing presence and/or preference information from various presence sources, as described above. For example, the message handler 275 is configured to receive presence information from a telephony server application 240 (e.g., user device presence user agents that transmit the device status), the calendar/scheduler application 250 (e.g., Microsoft Exchange Server®, IBM Lotus Notes® or other similar application), an instant messaging application 260 (and other sources of presence information) and the presence IVR control application 235. The message handler 275 is also configured to receive preference information from the telephony server application 240, the presence IVR control application 235 and other sources.
The message handler 275 processes the messages to extract the presence information and provides the presence information to the compositor 280, which aggregates the presence information from each of the sources 235, 240, 250 and 260. In addition, the message handler 275 extracts preference information from the received messages and provides the preference information to the preference engine 285, which sets the presentity preferences based on the preference information. The adapter 290 interfaces with the presence server 160 to provide the aggregated presence information from the compositor 280 and the preference settings from the preference engine 285.
At block 340, the IVR system receives updated presence and/or preference information related to one or more presence and/or preference settings from the presentity. For example, the IVR system can receive the updated presence and/or preference information as DTMF signals, speech or data. Upon receipt of the updated presence and/or preference information, at block 350, the IVR system provides the updated presence and/or preference information to the presence server, which updates the presentity's presence and/or preference information with the updated presence and/or preference information at block 360.
Thereafter, the IVR system 230 authenticates the presentity based on a device identity associated with the user device 210 or via a traditional user identity and PIN. For example, at 425, the presence IVR control application 235 transmits the device identity (e.g., phone number or other presentity identification number) received during initialization at 420 to the rich presence server 270 to authenticate the user device 210 at 428. In other embodiments, the device identity and other presentity authentication information (e.g., user identity and PIN) can be registered with the presence IVR control application 235 to avoid extensive signaling between the IVR system 230 and the rich presence server 270.
If the user device 210 is not registered with the rich presence server 270, the IVR system 230 prompts the presentity for the user identity (e.g., a registered device phone number or other presentity identification number) at 430. The presentity enters the user identity on the user device 210, which transmits the user identity to the presence IVR control application 235 via the IVR system 230 at 432. At 434, the presence IVR control application 235 confirms the receipt of the user identity. Thereafter, the IVR system 230 prompts the presentity for the presentity's personal identification number (PIN) or other password at 436. The presentity enters the PIN on the user device 210, which transmits the PIN to the presence IVR control application 235 via the IVR system 230 at 438. From the entered user identity and PIN, the presence IVR control application 235 authenticates the user by either querying the rich presence server 270 at 442 and 444 or storing valid user identities/PINs.
Once the presentity is authenticated at 450, the IVR system 230 provides a welcome message (e.g., “Welcome to remote present update system”) to the presentity at 455 and queries the presentity for the desired presence setting option (e.g., “Press 1 for presence change, 2 for change in schedule”) at 460. The presentity selects the presence setting option of “presence change” by entering a “1” into the user device 210, which transmits the selection of “presence change” to the IVR system 230 at 465. Thereafter, a 470 the IVR system 230 queries the presentity for the updated presence information associated with the selected presence setting option (e.g., “Press 1 for ‘out to lunch,’ 2 for ‘on vacation,’3 for ‘be right back’ or 4 for ‘customize’”). The presentity enters the updated presence information of “out to lunch” by entering “1” into the user device 210, which transmits the selection of “out to lunch” to the IVR system 230 at 475.
Upon receipt of the updated presence information of “out to lunch,” the IVR system 230 notifies the presence IVR control application 235 to change the presence state of the presentity to “out to lunch” at 480. At 490, the presence IVR control application interfaces with the rich presence server 270 to change the presence state of the presentity to “out to lunch” at 485. Once the rich presence server 270 has updated the presentity's presence state to “out to lunch,” the rich presence server 270 notifies the presence IVR control application 235 at 490, which in turn notifies the IVR system 230 at 495. To complete the update, at 498, the IVR system 230 notifies the presentity that the presence information has been successfully updated (e.g., “Presence updated. Thank-you.”).
As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide rage of applications. Accordingly, the scope of patents subject matter should not be limited to any of the specific exemplary teachings discussed, but is instead defined by the following claims.