WO2006038963A1

WO2006038963A1 - System and method for predicting availability

Info

Publication number: WO2006038963A1
Application number: PCT/US2005/026789
Authority: WO
Inventors: William J. Beyda; Rami Caspi
Original assignee: Siemens Communications, Inc.
Priority date: 2004-09-30
Filing date: 2005-07-28
Publication date: 2006-04-13
Also published as: WO2006038962A1

Abstract

A telecommunications system includes a network (202); a plurality of client devices (212) operably coupled to said network, said plurality of client devices adapted to select one or more of others of said plurality as contacts on a contact list (404); a presence server (204) coupled to said network and adapted to monitor presence status of selected ones of said others, wherein said presence server maintains one or more records of past presence data for said selected ones; a calendar server (1304) adapted to maintain a calendar for selected ones of said plurality; and a scheduler (1306) adapted to receive said one or more records and said calendar and determine a likely presence status at a predetermined time.

Description

SYSTEM AND METHOD FOR PREDICTING AVAILABILITY

CROSS REFERENCE TO RELATED APPLICATIONS

[1001] The present invention is related to co-pending, commonly assigned

U.S. Patent Application Serial No. , titled SYSTEM AND METHOD

FOR PROVIDING PRESENCE AGE INFORMATION IN A UNIFIED

MESSAGING SYSTEM, and U.S. Patent Application Serial No. , titled,

SYSTEM AND METHOD FOR HISTORICAL PRESENCE MAP, filed concurrently herewith.

BACKGROUND OF THE INVENTION

Field of the Invention

[1002] The present invention is directed generally to telecommunications systems and, particularly, to improvements in providing presence information.

Description of the Related Art

[1003] Presence-based communications applications are entering the mainstream telecommunications environment. In such applications, a user maintains one or more "contact lists" of other parties whose presence status is to be monitored and displayed to the user. If the other party is determined to be "present," the user's contact list will display the available status. The user can then contact the other party.

[1004] Often, however, the management of contact lists can become cumbersome, particularly to the inexperienced or casual user. For example, over a period of time, a user may continually add "buddies" or contacts to the contact list, while neglecting to remove "stale" buddies, i.e., those who have not been contacted in a while or those whose presence status has not changed to "present" in a while. When this happens, the number of "active" buddies on the list can be overwhelmed by the number of stale buddies. In this case, it can become difficult to identify useful contact information.

[1005] Further, while contact lists are typically used to provide the user a current status of other parties, it is often the case that a user will wish to plan a call or conference at a certain future date. Current presence systems, however, do not provide such prospective presence information.

[1006] As such, there is a need for an improved system and method for contact list management. There is a still further need for a system and method for identifying stale buddies from a contact list. There is a still further need for a system and method for using presence information to determine a future schedule.

SUMMARY OF THE INVENTION

[1007] These and other drawbacks in the prior art are overcome in large part by a system and method according to embodiments of the present invention.

[1008] A telecommunications system according to an embodiment of the present invention includes a network; a plurality of client devices operably coupled to said network, said plurality of client devices adapted to set one or more time contact parameters for buddies on a contact list; and a presence server including a timer, and adapted to maintain a timing of time contacts for selected buddies responsive to said parameters.

[1009] A telecommunications presence system according to an embodiment of the present invention includes a network; a plurality of network clients coupled to the network, said network clients including presence control units configured to maintain contact lists of other clients whose presence status is to be monitored; a presence server coupled to the network, said presence server including a master presence control unit adapted to receive said contact lists and configured to monitor presence status across a plurality of media and distribute presence information to corresponding ones of said plurality of network clients; wherein said presence server maintains presence status age information.

[1010] A telecommunications system according to embodiments of the present invention is adapted to maintain presence information across a plurality of media including, for example, messaging, real-time voice and video, and conferencing. The system further allows users to set age monitoring for parties on the user's contact list(s). The age monitoring may be specific to the user, to other parties, or to media, or all three

[1011] A telecommunications system according to an embodiment of the present invention includes a network; a plurality of client devices operably coupled to said network, said plurality of client devices adapted to select one or more of others of said plurality as contacts on a contact list; a presence server coupled to said network and adapted to monitor presence status of selected ones of said others; wherein said presence server maintains one or more records of past presence data for said selected ones and is configured to provide said one or more records to a requesting one of said plurality.

[1012] A telecommunications system according to an embodiment of the present invention includes a network; a plurality of client devices operably coupled to said network, said plurality of client devices adapted to select one or more of others of said plurality as contacts on a contact list; a presence server coupled to said network and adapted to monitor presence status of selected ones of said others, wherein said presence server maintains one or more records of past presence data for said selected ones; a calendar server adapted to maintain a calendar for selected ones of said plurality; and a scheduler adapted to receive said one or more records and said calendar and determine a likely presence status at a predetermined time.

Brief Description of the Drawings

[1013] The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[1014] FIG. 1 illustrates a multi-modal presence system according to embodiments of the present invention.

[1015] FIG. 2 is a block diagram of a telecommunications system according to an embodiment of the present invention.

[1016] FIG. 3 is a block diagram of a multimedia server according to embodiments of the present invention.

[1017] FIG. 4 - FIG. 8 are diagrams of a graphical user interfaces according to embodiments of the present invention.

[1018] FIG. 9 - FIG. 10 are flowcharts illustrating operation of embodiments of the present invention.

[1019] FIG. 11 is a simplified block diagram of a system according to embodiments of the present invention.

[1020] FIG. 12 - FIG. 14 are a diagrams illustrating graphical user interfaces for use with a system according to embodiments of the present invention.

[1021] FIG. 15- FIG. 18 are flowcharts illistrating operation of embodiments of the present invention.

[1022] FIG. 19 is a diagram illustrating a graphical user interface for use with a system according to emboidments of the present invention.

[1023] FIG. 20 and FIG. 21 illustrate schedule prediction according to embodiments of the present invention.

[1024] FIG. 22 is a flowchart illustrating operation of an embodiment of the present invention. DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[1025] Turning now to the drawings and, with particular attention to FIG. 1 , a diagram schematically illustrating a multi-modal presence-based telecommunications system 100 according to an embodiment of the present invention is shown. The telecommunications system 100 includes real-time communication capabilities 106, messaging capabilities 104, network business applications 108, and collaboration applications 110. Real-time communication 106 can include, for example, voice, video, or cellular. Messaging 104 includes e-mail, instant messaging, short messaging service (SMS) or other text-based services. Business applications 108 can include, for example, Customer Relationship Management (CRM) and Enterprise Resource Planning (ERP) software packages. Collaboration applications 110 can include conferencing, whiteboarding, and document sharing applications.

[1026] In addition, a multi-modal presence feature 102 can provide presence services, including age, history, and scheduling information, aggregated across the various media 104, 106, 108, 110. More particularly, as will be explained in greater detail below, the presence system 102 can monitor one or more user contact lists for specified presence or availability. In addition, the presence system 102 maintains one or more timers to determine a time since a party on the contact list was last available, either across all media or with reference to particular media. Furthermore, embodiments of the present invention can monitor age with respect to particular parties or age across all parties. As will be explained in greater detail below, users can actively manage their contact lists based on the presence age/ time contact information.

[1027] Other embodiments of the present invention provide a historical presence feature wherein the presence server will record a presence status history of registered parties (i.e., will provide a record of past presence data). The histories are accessible by selected users to determine an optimal contact time and/or medium. Still other embodiments of the present invention provide a scheduler that can access the presence status histories of other parties and the requesting user. The scheduler can then determine a projected optimal contact time based on minimizing conflicts in the schedules and projected schedules.

[1028] It is noted that while illustrated as a multi-modal presence system, the teachings of the present invention are equally applicable to system employing only single presence-based media. Thus, the figures are exemplary only.

[1029] FIG. 2 illustrates an exemplary enterprise network 200 including a presence system in accordance with embodiments of the present invention. It is noted that, while a particular network configuration is shown, the invention is not limited to the specific embodiment illustrated. As shown, the enterprise network 200 includes a local area network (LAN) 202. The LAN 202 may be implemented using a TCP/IP network and may implement voice or multimedia over IP using, for example, the Session Initiation Protocol (SIP) or ITU Recommendation H.323. Coupled to the local area network 102 is a multimedia enterprise or presence server 204.

[1030] The server 204 may include one or more controllers (not shown), such as one or more microprocessors, and memory for storing application programs and data. As will be explained in greater detail below, the server 204 may provide a variety of services to various associated client devices, including telephones, personal digital assistants, text messaging units, and the like. Thus, as will be explained in greater detail below, the server 204 may implement suite of applications 213 as well as, or including, a master presence control unit 211 , according to embodiments of the present invention.

[1031] Also coupled to the LAN 202 is a gateway 206 which may be implemented as a gateway to a private branch exchange (PBX), the public switched telephone network (PSTN) 208, or any of a variety of other networks, such as a wireless, PCS, a cellular network, or the Internet. In addition, one or more client endpoints such as LAN or IP telephones 21 Oa- 21On and one or more computers 212a-212n may be operably coupled to the LAN 202. [1032] The computers 212a-212n may be personal computers implementing the Windows XP operating system and thus, running Windows Messenger client (It is noted, however, that other Instant Messaging Programs could be implemented.). In addition, the computers 212a-212n may include telephony and other multimedia messaging capabilities using, for example, peripheral cameras, microphones and speakers (not shown) or peripheral telephony handsets. In other embodiments, one or more of the computers may be implemented as wireless telephones, digital telephones, or personal digital assistants (PDAs). Thus, the figures are exemplary only. The computers 212a-212n may include one or more processors, such as Pentium- type microprocessors, and storage for applications and other programs. The computers 212a-212n may implement network application programs 220 including one or more presence control units 222 in accordance with embodiments of the present invention. In operation, as will be explained in greater detail below, the presence control units 222 allow the client endpoints to interact with the presence service(s) provided by the presence server 204, including, for example, age, historical, and predictive services.

[1033] Turning now to FIG. 3, a block diagram illustrating a server 204 according to embodiments of the invention is shown. As shown, the server 204 implements a master presence control unit 211 and a server application suite 213. In the embodiment illustrated, the multimedia server 204 also provides interfaces, such as application programming interfaces (APIs) to IP phones/clients 310, gateways 312, and software developer toolkits 314. An exemplary server environment capable of being adapted for use in a system according to embodiments of the present invention is the OpenScape system, available from Siemens Information and Communication Networks, Inc. Such an environment can be implemented, for example, in conjunction with Windows Server, Microsoft Office Live Communications Server, Microsoft Active Directory, Microsoft Exchange and SQL Server.

[1034] As will be explained in greater detail below, the master presence control unit 211 collectively includes one or more presence timers 301 , presence applications 316c, a context manager 320a, and can also include one or more real time clocks 309. In certain embodiments, personal profiles 316a interface to the master presence control unit 211 , as well, and may be considered part of it. Thus, the master presence control unit 211 interfaces to productivity applications to provide presence services according to embodiments of the present invention.

[1035] In the embodiment illustrated, the application suite 213 includes a personal productivity application 316, a workgroup application 318, and a communication broker 320. The personal productivity application 316 implements various application modules: priority profiles 316a, word web 316b, presence 316c, voice portal 316d, self-service portal 316e, and personal portal 316f. The workgroup collaboration application 318 implements audio conferencing 318a, multimedia conferencing 318b, touch conferencing 318c, instant conferencing 318d, media advance 318e, and a workgroup portal 318f. The communications broker 320 implements a context manager 320a, configuration unit 320b, telephony features 320c, reports/data storage 32Od, as well as interworking services.

[1036] The personal productivity portal 318f and workgroup portal 318f allow a user to access features using a standard Web browser, or via network application plugins.

[1037] The priority profiles 316a provide for handling of a user's communications and initiating specified actions, such as voice calls, e-mails and instant messages. It allows the user to configure personal rules for each status such as "In the Office", "On Business Trip", or "On Vacation;" and allows use of information such as who is calling and the media type to determine an action. The action may include routing to a specific device, routing to the preferred device at the time, sending a notification, and/or logging the transaction.

[1038] The presence application 316d functions as a contact list control unit and allows, through the use of the contact lists, monitoring the status of contacts (e.g., "In the Office," "On Vacation," "Working Remote," etc.); and monitoring the "aggregated presence by media type" for each contact (i.e., whether the contact is accessible by phone, IM, or email).

[1039] The Word web 316b provides a Microsoft Word-based scripting for development of telephony applications. The self service portal 316c provides guest access to messaging, calendaring, and document retrieval features, such as Voicemail Functions - leave a message, transfer from voicemail; Calendar Functions - schedule / cancel / modify appointments with a subscriber, get email confirmation; and Document Access Functions - authenticate user based on PIN and allow reading, email or fax-back of documents stored in Exchange folders. The voice portal 316e provides user access to groupware features via the telephone. These can include, for example, Calendar Access functions - accept / decline / modify appointments, block out time; voicemail, email access functions - Inbox access with message sorting options (List total, retrieve (listen), skip, forward, reply, etc.).

[1040] In general, default user rules and actions are provided by the system users to specify custom rules and actions using the Personal Productivity Portal 316f, e.g., an interface to a client browser . During runtime, users can set their Presence State or specify a Preferred Device using either the Personal Productivity Portal 316f or the Voice Portal 316d.

[1041] The Workgroup Collaboration Portal 318f, which may be implemented as a browser interface, allows users to initiate audio or multi¬ media conferencing sessions and view documents that have been checked in to the Workgroup Repository (not shown). The audio conferencing module 318a and the multimedia conferencing module 318b allow the user to set up audio or multimedia conference sessions. The Instant Conference module 318d launches an audio or WebEx multimedia conferencing session, based on contact lists or address book(s). The Touch Conference module 318c allows the user to see the participant list and their presence status. The Media Advance module 318e offers users the point and click option to advance an existing audio conference to a multimedia collaborative session. [1042] The communications broker 320 provides various communication services. The Context Manager 320a provides user presence/availability states for users, such as "In the Office", "On Vacation", "Working Remote", etc.; and provides device presence and device context for both SIP registered devices and User defined non-SIP devices. In addition, the context manager 320a provides, across the set of devices for a user, aggregated presence by media type, e.g., voice, IM, and email. For example, if a user is accessible by any phone device such as an office phone, a home phone, or a mobile phone; the aggregated presence for the user would indicate accessibility via the media type "telephone." Based on the aggregated presence information for each media type (e.g. available via telephone, not available via IM, available via email), others can choose the best medium of making contact with this user.

[1043] The telephony features 320c gives applications access to connection management features via CSTA (e.g. make a call, transfer call, set-up conference, etc.); provides address translation from dialing digits to SIP URL to broker connectivity between telephony devices and soft clients. The Interworking Services provide SIP gateway interworking (e.g., interworking with PSTN and PBX networks). Reports Data Storage 32Od provides a repository for system and data reports.

[1044] . The Context Manager 320a is a service that ties together a view of all users. This view may include the presence and availability of users, the state of users (e.g. in a voice call), each user's collaboration session associations, etc. The result is a detailed view of what the user and their devices are doing at any point in time. This information is used by other network users and system components to make decisions about how to contact the user, as will be described in greater detail below.

[1045] Collectively, the presence application 318c and context manager 320a operate in conjunction with the presence timer 211 , clock 309, and priority profiles 316a to provide presence service according to embodiments of the present invention. In particular, as will be explained in greater detail below, the presence service operates to determine the age and history of predetermined contacts and undertake actions responsive thereto.

[1046] It is noted that, while a presence server in a unified messaging system is shown, the teachings of the present invention are equally applicable to a presence system associated with a single medium, such as Instant Messaging. Thus, the figures are exemplary only.

[1047] Turning now to FIG. 4, a diagram illustrating a graphical user interface personal portal 400 according to an embodiment of the present invention is shown. The GUI personal portal 400 may be a browser that interacts with portal 316f (FIG. 3) and allows the user to handle communication tasks associated with applications 213 (FIG. 3), including, for example, handling voice calls, e-mails, and instant messages. In addition, the personal portal 400 allows the user to manage contacts and set age timer and management.

[1048] In particular, as shown, the GUI personal portal 400 includes Calls window 402, Contacts window 404, Groups window 406, Calendar 408, Inbox 410, and User Status window 412. The Calls window 402 allows, for example, the user to enter a phone number and make a call the number; show current call status; and provides a call log. The Contacts window 404 allows the user to set one or more other parties as contacts and displays current contact status, including age information and history, as will be explained in greater detail below.

[1049] The Collaboration Groups window 406 similarly allows the user to display collaboration groups and status. The calendar window 408 allows the user to set times and dates, e.g., for making calls or setting meetings times. The Inbox window 410 permits receiving of e-mail or other multimedia messages. The user status window 412 allows the user to set current presence status.

[1050] In particular, FIG. 5 is a diagram illustrating an exemplary user status window 412. The user can use drop-down window 416 to set a preferred telephone or other communication medium, which is then received by personal profiles module 316a and can be provided to the master presence control unit 211. Current status can be set using drop-down 414. In the example illustrated, the user can set Current Status as In Office, Working Remotely, Be Right Back, In Meeting, Do Not Disturb, Out of Office, On Business Trip, or On Vacation. As will be explained in greater detail below, in embodiments in which the user can set specific out of office type status, the presence age system will take into account the user's lack of access in determining whether the user has become "stale." Once the client makes the settings, the settings are uploaded to the server. Changes in setting may be detected by the presence control unit to reset the age timer 301 , as will be explained in greater detail below.

[1051] In addition to setting user status, the user can also set time contact parameters such as age thresholds to associate with other parties. That is, the user can set an age threshold for another party, and associate it with one or more media. The timer 301 will then count to the threshold if no change in presence status is detected thereafter. If the timer expires, then the server or local client software can take one or more actions in response.

[1052] FIG. 6 illustrates an exemplary time contact parameter (age) setting window according to embodiments of the present invention. The age setting window 600 may be accessible via, for example, the portal 400. In the embodiment illustrated, the age setting window 600 includes contact 602, medium 604, threshold 606, and action 608 options. In operation, the user can select a contact 602 and associate a medium 604 with the contact. The settings are received by the priority profiles module 316a. The presence application 316d and the context manager 320a then monitor the presence status and can clear, activate, or read the timer 301 of the party according to medium selected. Exemplary selections include All (for all media); Telephone, for telephone only; E-mail, for e-mail only; or Instant Messaging, for instant messaging only. The user can also set a threshold; in the example illustrated, the user can set no threshold, or thresholds of 30, 60, and 90 days. [1053] Further, as shown in FIG. 7, the user can set or reset an age timer specific to an individual party, or all parties on his contact list. In particular, FIG. 7 illustrates an exemplary interface that allows the user to reset the timer or set it to a desired time. Again, inputs to the interface 700 are received at the master presence control unit 211 to coordinate timer activities. In particular, once the user has selected a corresponding party in the contact list, he can select RESET 702 to reset the timer. Similarly, the user can select SET TIME 704 and enter a particular time in window 706 to set a particular timer setting. In certain embodiments, the user can also elect to reset all timers associated with all contacts.

[1054] Embodiments of the present invention display the age status to the user in a convenient format, such as a browser format. For example, FIG. 8 illustrates an exemplary age status window in accordance with an embodiment of the present invention. In the embodiment illustrated, the user is able to view a list of contacts 802 and a last contact medium 804. Last contact information is shown at 806. As can be seen, depending on the embodiment, the last contact information can take a variety of forms. For example, as seen at 808, the last contact information can be displayed as a number of months, days, hours, etc., since last contact, or a specific date, as shown at 809. The real time and date information may be provided by the real time clock 309 (FIG. 3). Alternatively, as shown at 810 and 812, the age information can be displayed as an icon that gradually "ages," e.g., by showing white "hair," etc. In one embodiment, the icon will gradually shift, or may shift upon expiration of timer 301.

[1055] FIG. 9 illustrates operation of an embodiment of the present invention in greater detail. In a step 902, a user can use his client software 222 to log in to the presence/telecommunications server 204. This can include, for example, opening a TCP connection and sending the user password and user name. The server 204 itself maintains a database of users (as shown at 904), which it can use to check the password and user name, as shown at step 906. Next, at a step 908, the user can receive an acknowledge from the server 204 and can then send its contact list to the presence server 204 and, particularly, the master presence control unit 211. At a step 910, the presence server 204's master presence control unit 211 checks the contacts' presence status and age. As noted above, a contact's age can be the age since any change in status or a change in status of a particular medium. Further, as noted above, this can be done according to a default rule or one or more user-supplied rules. In addition, the presence age can be determined with respect to contacting the user or with respect to contacting any user, either overall or on a per medium basis. That is, the presence timer 301 can receive the identity of the party whose presence information is to be determined, and can provide the age information to the presence application 316d, for provision to the client.

[1056] It is noted that the function of the timer can be to actually perform a "count" of the absolute time since a contact, or can function to simply read the real time clock 309 at times indicated by a change in presence or manual entry. Finally, returning to FIG. 9, at 912, the server 204 sends the user the appropriate presence information for the parties on the contact list. As noted above, this can include sending the information via a browser interface.

[1057] Operation of an embodiment of the present invention is shown in greater detail with reference to FIG. 10. In particular, the flowchart of FIG. 10 illustrates the checking of contacts and associated age information (if any) according to an embodiment of the present invention. As noted above, the master presence control unit 211 checks user contacts from the contact list, as shown in step 1002. In particular, the presence application 316d monitors presence status and context manager 320a identifies the particular medium. Typically, the master presence control unit 211 may monitor all registered users and age since last contact or contact by the requesting user; when a contact list is received, the appropriate information corresponding to those users to transmitted to the requesting user. At a step 1004, the master presence control unit 211 checks any special settings associated with a contact party, e.g., related to age information, that a user may have uploaded previously. If, in step 1006, the master presence control unit 211 determines there are no special settings, then the system simply returns the standard contact and presence information, at A. If, however, special settings are detected, then in step 1008, the master presence control unit 211 checks whether the conditions have occurred. For example, a time (age) threshold on the timer 301 may have been set, which is checked by the system at 1008. If the timer 301 associated with the party has not expired, the system returns to A. Otherwise, the master presence control unit 211 can cause the server 204 to automatically perform the action, at step 1010. Alternatively, at 1012, the server 204 can send the client a prompt, to notify that the condition has occurred. It is noted that the action could be an action to be performed by the server and/or the client itself. For example, the action could be deleting the party from the user's contact list, as stored locally and uploaded. The client can then accept or reject the action, in step 1014.

[1058] As noted above, in certain embodiments, parties can set their own presence status (e.g., FIG. 5). Thus, a failure to detect an active presence may be attributable to the party being out of town, on vacation, etc., rather than the party actually having lapsed. As can be appreciated, when this occurs, it is undesirable to automatically delete the out of town party from a given user's contact list, even if the user has specified automatic deletions. In these cases, a system of embodiments of the present invention may override an "automatic" action and provide a prompt for confirmation. In other embodiments, the aging timer may simply be paused until the presence state changes. In still other embodiments, an additional threshold may be required before determining that a party whose last state was "On Vacation" is indeed "stale." Thus, certain embodiments of the present invention examine presence states as well as presence aging, before determining if the party is "stale."

[1059] In addition to determining an age of a party's presence status, embodiments of the present invention may be used to provide a presence history and to predict, based on the history, whether another party or parties will be available at a particular time. [1060] More particularly, as shown in FIG. 11 , in certain embodiments, the server 204's master presence control unit 211 includes a historical presence control unit (HPCU) 1302 that functions as a presence record unit and operates in conjunction with a calendar control unit 1304. An exemplary calendar control unit suitable for use with embodiments of the invention is the Microsoft Exchange server. These are accessible by the network client 212 via the presence control unit 222, which may include a suitable graphical user interface, such as a Web browser and/or one or more plug ins. In addition, a scheduler 1306 may be provided, which receives the historical presence information, as well as user calendar information, to predict a future availability.

[1061] In operation, the historical presence control unit 1302 operates in conjunction with the calendar 1304 and, in certain embodiments, the timer 301 and real time clock 309, to record the actual time and date of changes in party status. That is, the historical presence control unit 1302 maintains one or more parties' presence histories in associated memory (not shown). This information record can then be provided to other users, i.e., be made available in a presence map or calendar format to other users. For example, the server can provide the data to be displayed or generated locally in a web type browser as a presence map or calendar.

[1062] In operation, users can use their status portals 412 (FIG. 5) to select whether they want their presence history to be accessible to other users. Thus, for example, the GUI 412 of FIG. 5 provides an interface 502 for selecting Display History YES or NO. The associated command signaling is received at the HPCU 1302 to allow other user access, as will be explained in greater detail below.

[1063] Other users can access another party's presence history by clicking on one or more menu buttons, for example, when a particular party is highlighted in the user's contact list. In the embodiment illustrated in FIG. 12, the user then has the option of selecting whether to view day 1402, a week 1404, or month 1406. In other embodiments, as shown at 1408a, 1408, the user can select a date or a range of dates for historical presence display.

[1064] If, for example, the user clicks on Month 1406, a month display 1502 such as shown in FIG. 13 can be generated. In certain embodiments, each date will have one or more presence status displayed. Different conditions, such as presence state or media, can be displayed using different colors, for example. If more than one historical presence status is associated with a particular day, then the user can then select a day 1504, for example, by scrolling cursor 1506 over it. The presence status can then be shown in an enlarged display.

[1065] A particular day can be selected, e.g., by using the GUI of FIG. 12 or, for example, by double clicking a day on the month calendar of FIG. 13. An exemplary day status display is shown in FIG. 14. In the example illustrated, a twelve hour display is shown, from 8 AM to 8 PM, in hourly increments. Availability can be displayed according to color or textually. For example, as shown, the party is At Home from 8 AM to 10 AM; in the office from 11 AM to 12 PM; at lunch from 12 to 1 ; and at work again from 1 to 3 PM and has set 3 PM to Do Not Disturb. In certain embodiments, a default entry during daytime or work hours may be "available at work;" similarly, during non-daytime or work hours may be "unavailable."

[1066] Turning now to FIG. 15, a flowchart illustrating operation of an embodiment of the invention is shown. In particular, the flowchart of FIG. 15 illustrates server operation according to an embodiment of the present invention. Initially, at a step 1702, the server is initialized or configured with the registered users. This may be accomplished, for example, by a system administrator using a browser interface. Once the users have been registered, the server 204 and, particularly, the master presence control unit 211 , is set up to receive user contact lists and personal preferences, as shown at step 1704. At step 1706, the master presence control unit 211 monitors the presence status of the registered users and, particularly, those on received contact lists. That is, the master presence control unit 211 can record the time and dates (and aging) of presence status changes for registered users. In step 1708, the master presence control unit 211 's historical presence control unit 1302 stores the historical presence information, along with time and date indicia, in one or more databases (not shown). As noted above, when a presence change occurs, the master presence control unit 211 and, particularly, the historical presence control unit 1302 can access the calendar 1304 and/or access the real time clock 1309 to determine the time and date of a presence change and store it in one or more memory locations assigned to the party.

[1067] At step 1710, the master presence control unit 211 can receive a user request for a party's historical presence information. For example, as discussed above, such a request can be received using a suitably programmed web interface and can be customized to media or state. Once the request has been received, the master presence control unit 211's historical presence control unit 1302 checks to determine if the requested party has chosen to allow his presence history to be accessed, as shown at step 1712. Such permission may be associated with all users or only particular users. If permission is not allowed, the master presence control unit 211 will continue monitoring, as shown at 1706. If permission is given, then at step 1714, 1716, 1718, the historical presence control unit 1302 will access past day, week, or month (or user-specified day, week, or month, or combinations thereof). Finally, at step 1720, the presence information is provided to the requesting user as a calendar map. The map can be customized to display presence media or states in different colors, etc.

[1068] FIG. 16 illustrates in greater detail server recording the historical presence state of the corresponding parties. In a step 1602, the master presence control unit 211 monitors the parties' presence states. At step 1604, the master presence control unit 211 detects a change in a selected party's presence state. Then, depending on the implementation, the server can proceed along branch 1601 or 1603. [1069] If branch 1601 is implemented, then in step 1606, the historical presence control unit 1302 accesses the system clock 309 (FIG. 3) and/or calendar 1302 and, at step 1608, records the time and date of the change in presence state. Then monitoring continues at step 1610 until the next change in presence state is detected.

[1070] If branch 1603 is implemented, then in step 1612, after a change in presence state is detected at step 1604, a timer (e.g., timer 1301) is started at step 1612. A next change in presence state is detected at step 1614. In a step 1616, the timer entry is stored, the timer itself is cleared, and begins timing again until the next change in presence status for the party is determined. In this embodiment, the amount of time at a given presence state can thus be directly determined. Alternatively, of course, the amount of time could be calculated from the exact hour, minute data determined using branch 1601. As will be explained in greater detail below, such information may be useful in predicting whether a party will be available on a particular date.

[1071] FIG. 17 and FIG. 18 illustrate operation of an embodiment of the present invention on the client side. Turning now to FIG. 17, at a step 1902, the user can open a settings menu using his graphical user interface. As noted above, the graphical user interface can be implemented as a web page or browser page provided by the server 204. The user then selects whether to allow other party access to his presence history, in step 1904. As noted above, this can be universal permission or party-specific permission. A default may be no permission.

[1072] In operation, as shown in FIG. 18, a user can open his contact list(s), in step 2002. In a step 2004, the user can select a party from the contact list, e.g., by highlighting or double-clicking the corresponding entry. At 2006, the user may open a history menu (FIG. 12). The history menu allows the user to select a day, week, month, or other time period, or a date or time range for viewing the particular party's presence history, as seen at step 2008. In addition, in certain embodiments, the presence state and media can be specifically set; a default would be to display all media and states. Finally, at step 2010, the presence history may be displayed for the user, as discussed above.

[1073] As noted above, one aspect of embodiments of the present invention is determining an availability of a party and scheduling a communication, such as an audio or multimedia teleconference. As will be explained in greater detail below, in operation, a scheduler 1306 (FIG. 11) accesses the party history to make a prediction of when the party is available, and can access the calendar to schedule the conference. In certain embodiments, the scheduler 1306 determines a next best available time or one or more next best available times for contacting the other party.

[1074] A graphical user interface that allows the user to select various scheduling parameters is shown in FIG. 19. The GUI of FIG. 19 may be implemented as a browser window or windows capable of sending form data to the server. Once the user has accessed his contact list, he can select a particular contact (or enter a contact name) 2102. The user can also select a contact medium using menu 2104. That is, the user can select a media constraint, i.e., whether to contact the other party via telephone, IM, or the like. The user can then use menu 2106 to select a day, time or range of dates and times, that would be preferred for the contact. In operation, the information is received at the server, which accesses the party history and also, in certain embodiments, the party calendar, to make the prediction of availability and schedule the user call.

[1075] One example of this predictive scheduling is shown with reference to FIG. 20. In the example illustrated, it is assumed that the user has chosen to attempt to schedule a call with a party for "Next week." In response, the scheduler 1306 (FIG. 13) will access a history 2202 and, in certain embodiments, also a calendar 1304. The history 2202 may yield a history of availability of a corresponding week 2212. For example, the week could be a most recent (last) week; or the same week last month (or year), or an "average" (i.e., a cumulative summation) of a past predetermined number of weeks. As shown, the party shows a past availability on Monday and Thursday. In certain embodiments of the present invention, the scheduler 1306 would then attempt to schedule the user to make the call sometime Monday or Thursday. However, in other embodiments, the scheduler 1306 also has access to the party's calendar 1304 for the period in question. In the example illustrated, the calendar shows 1304 a week 2210 and indicates that the party has an availability on Tuesday, Thursday morning, and Friday. The scheduler 1306 thus schedules the call for Thursday morning, as shown at 2204. The scheduler 1306 can display a web page or browser window that shows the calendar and available time to the user. The user may then be given the option of entering the appointed time on his calendar, and also transmitting a request to the other party. It is noted that, while not illustrated, in a similar fashion, embodiments of the present invention can also use the user's history and calendar (as well as the other party history and calendar) as constraints on the schedule.

[1076] As will be discussed below, "availability" on a particular day can include an actual hour-by-hour analysis of the days of the week. In other embodiments, however, the system may determine that the user is not available at a given day if he has been unavailable for more than, for example, four hours during the day in the past. Similarly, the party may be deemed unavailable during half days if the user has in past not been available more than an hour in each half day. Such a determination may be made, for example, using the timer as described above.

[1077] FIG. 21 illustrates scheduling and/or analysis on a particular day. That is, in this example, the user has selected to determine whether a call can be scheduled for a particular day. Thus, at 2302, the scheduler 1306 pulls up the user history for a particular day. Similar to the week scheduling discussed above, the history can be for yesterday, the same day last week, or an average of most recent days or same days during previous weeks. In the example illustrated, the party is available at 8 AM, 11 AM, 1 PM, and 3-5 PM. This embodiment also can access the party calendar 1304, as shown at 2304. As can be seen, on the days requested, the party is available from 8 AM to 10 AM; at 11 AM; and from 1 PM to 5 PM. [1078] Thus, the scheduler 1306 determines that the party is available at 11 AM, 1 PM, and from 3 to 5 PM. The scheduler 1306 can then request a call with the other party, or simply indicate to the user when that party is available. In addition, in certain embodiments, the scheduler 1306 can also access the user's own calendar and history to constrain the availability determination.

[1079] FIG. 22 is a flowchart illustrating operation of an embodiment of the present invention. Initially, in a step 2402, the master presence control unit's scheduler 1306 can receive the schedule command and associated parameters (i.e., party, date or range of dates desired, medium, and the like). At a step 2404, the scheduler 1306 can use the party information to access the party's calendar 1304. Similarly, the information can be used to access the party's presence history, in a step 2406. The scheduler 1306 then uses the availability, etc., information to make a presence prediction, in a step 2408. The presence prediction may include one or more times and dates. As noted above, the presence prediction can also take into account the user's own history and calendar. Next, in a step 2410, the schedule information is provided to the user, e.g., via a web page interface. The user can then select which of the options to schedule the call, in step 2412. This information can then be scheduled in his calendar. It is noted that, while discussed in terms of a call to a single other party, the present invention is equally applicable to scheduling a conference among several parties; in this case, a common period of availability (both past and future) may be defined for all parties.

[1080] The foregoing description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The drawings and description were chosen in order to explain the principles of the invention and its practical application. The drawings are not necessarily to scale and illustrate the device in schematic block format. It is intended that the scope of the invention be defined by the claims appended hereto, and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A telecommunications system, characterized by: a network (202); a plurality of client devices (212) operably coupled to said network (202), said plurality of client devices (212) adapted to select one or more of others of said plurality as contacts on a contact list (404); a presence server (204) coupled to said network (202) and adapted to monitor presence status of selected ones of said others, wherein said presence server (204) maintains one or more records of past presence data for said selected ones; a calendar server (1304) adapted to maintain a calendar for selected ones of said plurality; and a scheduler (1306) adapted to receive said one or more records and said calendar and determine a likely presence status at a predetermined time.

2. A telecommunications system in accordance with claim 1 , wherein said scheduler (1306) adapted to assign a prediction score to one or more of said records and determine said likely presence state by optimizing said prediction score.

3. A telecommunications system in accordance with claim 1 , wherein said scheduler (1306) is adapted to receive a plurality of calendars and a plurality of records and determine an optimal time to schedule a communication for each party associated with the records and calendars.

4. A telecommunications system in accordance with claim 1 , wherein said presence server (204) is adapted to receive authorization for other parties to download a presence history of a particular party.

5. A telecommunications system in accordance with claim 1 , wherein said scheduler (1306) is adapted to provide said likely presence status via a browser interface.

6. A telecommunications system, characterized by: a network (202); a plurality of client devices (212) operably coupled to said network (202), said plurality of client devices (212) adapted to select one or more of others of said plurality as contacts on a contact list (404); a presence server (204) coupled to said network (202) and adapted to monitor presence status of selected ones of said others, wherein said presence server (204) maintains one or more records of past presence data for said selected ones; and means (1302, 1306) for predicting an availability of one or more of said plurality based on said one or more records.

7. A telecommunications system in accordance with claim 6, said predicting means (1302) further including calendar means (1304) for accounting for previously scheduled availability when making said prediction.

8. A telecommunications system in accordance with claim 7, wherein said predicting means (1302, 1306) includes means for authorizing a party to access said one or more records of other parties.

9. A telecommunications system in accordance with claim 6, wherein said predicting means predicts a best next available time.

10. A telecommunications system in accordance with claim 9, wherein said predicting means predicts a plurality of next available times.

11. A telecommunications system in accordance with claim 4, wherein said predicting means predicts a next available time based on a media constraint.

12. A telecommunications method, characterized by: maintaining a list of users (404) whose presence is monitored; maintaining a record (2202) of past presence status of said user; and predicting a future presence status (2204) of said user based on said record.

13. A telecommunications method in accordance with claim 12, wherein said predicting comprises predicting a next best available period.

14. A telecommunications method in accordance with claim 12, wherein said predicting is constrained by an existing calendar (1304) of availability for said user.

15. A telecommunications method in accordance with claim 12, wherein said predicting comprises predicting a common period of availability for a plurality of users.