US20060117050A1 - Methods and apparatus for determining a presence of a user - Google Patents

Abstract

Methods and apparatus are disclosed for collecting presence information about a user from one or more presence sources associated with the user, such as applications, devices and locations. A presence agent is associated with each presence source; and the presence agents provide presence information to one or more presence servers. Typically, the presence agents execute on a processor associated with the corresponding presence source. The presence agent reports one or more of macropresence events and micropresence events. The presence agent optionally prompts the user to update the presence information based on one or more criteria, such as exceeding a time threshold since the last presence event. Continuous presence functions are generated for each presence source that characterize the likelihood of the user to be present on the corresponding presence source at a given time.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• The present application is related to U.S. patent application, entitled “Methods and Apparatus for Determining a Proxy Presence of a User,” (Attorney Docket No. 504089-A-01 (John)), filed contemporaneously herewith and incorporated by reference herein.
FIELD OF THE INVENTION
• The present invention relates generally to communication methods and systems, and more particularly, to methods and systems that determine the presence of a user based on multiple sources of presence information.
BACKGROUND OF THE INVENTION
• A number of techniques have been proposed or suggested for determining whether or not a person is “present” at a given device, location or application. Presence information is becoming increasingly important for many applications. For example, as friends and colleagues become more distributed in time or location (or both), it becomes even more desirable for a user to determine, prior to a given communication attempt, whether or not the intended recipient of the contemplated communication is currently available at one or more communication devices. The provided presence information allows a user to make a more informed decision about how to best communicate with another person. In this manner, productivity is enhanced by enabling a better selection of the best way to contact the other person. This informed choice leads to a more efficient, productive and cost effective communication.
• Determining a user's presence and availability at a given device, location or application can generally not be done with certainty. Presence and availability are a prediction of current presence and availability based on presence and availability in the past (i.e., either the immediate past or over an extended history). For example, presence information based on login activity (e.g., whether the user is currently logged on to a given service) can grow stale over time, since a user may remain logged in to an application for several days at a time. Thus, many presence-tracking systems supplement the user login activity with other determinable user activity, such as keyboard or mouse activity and whether a user remains idle for a time period exceeding a specified interval. Existing presence awareness systems can distinguish between a user who is connected to the service (present) or not connected to the service (absent), and most systems allow some sort of busy or unavailable flag to be set.
• A number of techniques have been proposed or suggested for evaluating the likelihood that a user will be present at a device or location at some time, t, based on knowledge that the user was present at the device or location at some prior time. Such techniques are sometimes referred to as “presence aging.” For example, Horvitz et al., “Coordinate: Probabilistic Forecasting of Presence and Availability,” 18^thConf. on Uncertainty and Artificial Intelligence, 224-233 (July, 2002), describes a system that attempts to predict a user's presence and availability based on historical data, as well as future known data about the user's activities, for example, from a user's calendar. The Horvitz system attempts to evaluate the probability of the user's presence and availability being associated with one or more discrete presence/availability states.
• While existing presence awareness systems provide valuable presence information, they suffer from a number of limitations, which if overcome, could further improve the ability of users to efficiently communicate. For example, existing presence awareness systems are typically proprietary, closed architecture systems that only provide presence information within the domain of the service provider (i.e., one service subscriber can only determine if another service subscriber is present). Moreover, such systems typically require the user to actively perform a system login before these systems can track user presence and availability. In addition, existing presence aging techniques employ discrete stepwise functions that consider a presence state, such as “available,” to be in full effect until a certain time interval (or event) has passed, then the presence state changes to another, generally lower, discrete value, such as “away.”
• A need therefore exists for methods and systems that can evaluate a number of different sources of presence information for a user, independent of the providers of the devices and systems that constitute presence sources and without requiring active user logins, using a presence agent associated with each source of presence information. A further need exists for a method and apparatus for evaluating presence information on a continuous scale.
SUMMARY OF THE INVENTION
• Generally, methods and apparatus are provided for collecting presence information about a user from one or more presence sources associated with the user, such as applications, devices and locations. A presence agent is associated with each presence source; and the presence agents provide presence information to one or more presence servers. Typically, the presence agents execute on a processor associated with the corresponding presence source. The presence agent reports one or more of macropresence events and micropresence events. The presence agent optionally prompts the user to update the presence information based on one or more criteria, such as exceeding a time threshold since the last presence event.
• According to another aspect of the invention, continuous presence functions are generated for each presence source that characterize the likelihood of the user to be present on the corresponding presence source at a given time. The continuous presence functions are optionally recomputed if a time since a last computation exceeds a threshold.
• A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a network environment where the present invention can operate;
• FIGS. 2 and 3 illustrate two exemplary presence functions for different presence sources, s, as a function of a time difference between the current time and earlier presence events;
• FIG. 4 is a flow chart describing an exemplary implementation of the software agent process ofFIG. 1;
• FIG. 5 is a schematic block diagram of an exemplary presence server ofFIG. 1;
• FIG. 6 is a flow chart describing an exemplary implementation of a presence information maintenance process ofFIG. 5;
• FIG. 7 is a flow chart describing an exemplary implementation of a presence information request process ofFIG. 5; and
• FIG. 8 is a sample table for an exemplary database trigger database that records one or more database triggers that can be used to report presence events to a proxy presence agent of a user.
DETAILED DESCRIPTION
• The present invention provides techniques for approximating the current presence and availability status of a user.FIG. 1 illustrates anetwork environment100 where the present invention can operate. As shown inFIG. 1, a number of users communicate over one or more wired orwireless networks150. In the exemplary embodiment, each user employs amobile telephone110. While the present invention is illustrated in the context ofmobile telephones110, the invention may be applied to many other devices and applications, as would be apparent to a person of ordinary skill in the art.
• Macropresence According to one aspect of the invention, asoftware agent400, discussed below in conjunction withFIG. 4, is deployed on amobile phone device110. Thesoftware agent400 automatically reports powering up and down the phone device to apresence server500, discussed below in conjunction withFIGS. 5 through 7. The interval between the device “on” and “off” events constitutes the phone user's macropresence. Subscribers to this user's macropresence through thepresence server500 can thus be notified when the user turns on or off thephone110 or of other presence events. In one exemplary implementation, the user of thephone device110 does not have to invoke any software on thephone110 nor does the user have to use any software to explicitly propagate macropresence changes to thepresence server500. In other words, there is no effort or intervention required from the user to indicate macropresence changes. Moreover, because this process of reporting macropresence changes to apresence server500 is automatic, the user cannot forget to indicate or to report a macropresence change.
• A presence subscriber, such as applications and other users, may be interested in a user's macropresence as one of potentially many disparate sources of presence information about this user. A subscriber to a user's macropresence might use macropresence to influence the routing of communications to this user. For example, if the macropresence subscriber knows that the user has turned on his or hermobile phone110, the macropresence subscriber could decide to route a phone call to the user'smobile phone110 rather than to his or her desk phone or to send an email or instant message to the email/instant message address associated with hermobile phone110 rather than that associated with their work environment.
• In the illustrative embodiment, thesoftware agent400 is deployed on themobile phone110 rather than in the phone provider'snetwork150. Thus, in such an embodiment, reporting mobile phone macropresence is independent of theprovider network150 and its capabilities. However, there may be situations where it is desirable to have theprovider network150 host the macropresence reporting software, e.g., in cases where mobile phones are not capable of running additional software or where a network provider would like to offer a fee-based macropresence service. In such cases, the phone network provider can offer the same functionality of reporting macropresence by using software in thephone network150.
• Micropresence
• The present invention recognizes that mobile phone users tend to leave their mobile phones on for extended periods of time even though they may not be truly available on their mobile phones. For example, mobile phone users might leave their phone in their car while being in a store. A mobile phone user might mute the ringer of the phone while being in a movie theater. In such cases, the user's macropresence cannot be used to accurately infer the availability of the user to receive communications at that time.
• Thus, according to another aspect of the invention, micropresence supplements macropresence information with button press events and channel usage information on themobile phone110. In between mobile phone “on” and “off” events, there is typically a sequence of button pushes related to user activities such as receiving calls, making calls, checking voice mail, running applications, receiving messages, changing ring tones and modifying the configurations of the phone. Thesoftware agent400 can propagate macropresence changes to thepresence server500, as well as button presses and other user activities.
• The accuracy of decisions based on presence information is directly related to how recently a reported macropresence or micropresence event occurred. However, apresence server500 can be easily overwhelmed with micropresence events if a large number ofmobile phones110 report micropresence events. To prevent flooding of the presence server, the number of micropresence events may be limited by only propagating micropresence events to thepresence server500 from a givenmobile phone110 if no such event has been propagated to theserver500 in the last t_ftime units, where t_fis a configurable parameter in thesoftware agent400. To this end, thesoftware agent400 keeps track of the time of the last micropresence event that was propagated to the presence server. If the next event falls within t time units of the last recorded event, the event will not be propagated to the presence server.
• The macropresence and micropresence information collected by thepresence agent400 is independent of the service provider associated with themobile telephone110 and independent of the technology employed by the service provider. Thepresence agent400, deployed on themobile telephone110 itself, can thus provide presence information to any application outside of the realm of the service provider.
• In addition, because thepresence agent400 is deployed on themobile telephone110 itself, thepresence agent400 has access to all button presses on thetelephone110, whether or not such button presses result in a transmission to the service provider (who only knows of transmitted events). For example, if a user locks or unlocks thetelephone110 or checks a call log, these operations do not result in communications and would not be known to the service provider but would be known to the presence agent400 (and can be propagated to the presence server).
• Presence Aging and Fuzzy Presence
• When a subscriber to a user's macropresence and micropresence needs to make a decision based on the user's presence on a device or application or at a location, the last reported macro presence or micropresence event for this user lies in the past. Depending on how long ago the last event of this kind was, it may not be a good indication of what the user's current presence and availability is. This effect is referred to as presence aging.
• Another aspect of the invention ranks presence events, originating at all presence event sources including mobile phone macropresence and micropresence, according to the timeliness of presence events. To each element s in the set S(u) of presence event sources for a user, u, a monotonically decreasing and continuous function f_u,s(d) is applied as a function of the time difference d between the current time and the last presence event originating at s. The most appropriate function f_u,scan be determined based on experimental results. To determine the likeliest device or application or location that a user is present and available at, the function f_u,sis computed for each presence source s and the list of computed values is sorted in descending order. The presence source at the top of the list is generally associated with the presence source that the user is likeliest to be present and available at. Evaluation of the function f_u,sindicates the user's current level of presence/availability, on a continuous scale, based on the type of presence source and the amount of time that has passed since the last presence event from that presence source (as opposed to a history of past presence events).
• As discussed further below, the continuous values of presence/availability levels provided by the present invention allow the presence/availability levels of a user to be aggregated across all presence sources for this user and subsets of a given set of users to be identified with certain presence/availability levels (such as the most available user, the least available user, and the subset of users with a certain minimum or maximum presence/availability level).
• The values of f_u,s(d) are referred to as fuzzy presence values to distinguish them from the known concept of discrete presence states. The latter are equivalent to using discrete functions with non-numerical values instead of continuous functions. A discrete presence state could be “available” or “away” or “extended away,” to use an example from the instant messaging world. The uncertainty about a user's presence status at a presence source is better accounted for by fuzzy presence, i.e., by continuous functions rather than by discrete functions. More importantly, using continuous functions instead of discrete functions with non-numerical values allows computations on presence values to be performed much more easily and efficiently. For example, computing the average or a weighted average for f_u,sat all presence sources s at a given point d for a specific user u is trivial and would allow the presence subscriber to easily discern the “overall presence” of this user. Comparing the overall presence values for different users is a potentially very useful exercise.
• If a presence subscriber is not interested in determining a specific user's presence but rather in the question of who is the “most” available person f(U) among a set U of users, the presence subscriber could easily compute the following value:
  f(U)=max {f_u,s(d)|u ε U, s ε S(u)}.
  This concept of the “most” available person may be applied, for example, in a help desk where a dispatcher (a presence subscriber) needs to find the first available help desk person. It is again noted that the use of continuous functions f_u,smakes the computation of the function f(U) very simple and efficient.
• This concept of the “most” available person may be extrapolated to compute subsets of U with a given minimum or maximum level of presence/availability or subsets that fall into a given interval of presence/availability levels. For example, the subset of U that includes all the users whose presence/availability does not exceed 0.1 and who therefore have to be reminded of the necessity to be more available to customer questions can be identified, for example, for a manager or supervisor. Alternatively, the subsets of all users whose presence/availability level exceeds 0.85 can be identified on behalf of an important customer that needs to speak to an expert in U as quickly as possible.
• In order to deal with presence aging, a user could be prompted to interact with the presence source s to confirm and refresh his or her presence and availability status, if the value of the function f_u,sfalls below a configurable threshold t_s. In the case of amobile phone110 as the source of macropresence and micropresence events, thesoftware agent400 that reports macropresence and micropresence events can optionally prompt the user through a visual or acoustic signal to press an arbitrary button if the value of f_u,sfalls below the threshold t_s. The button would count as a micropresence event as described above. The use of fuzzy presence allows fine-grained values to be selected for t_s, compared with discrete presence states.
• In one exemplary implementation, a user can change, override, or influence the value of f_u,sfor a given presence source s and at a given point d. Changing the value of f_u,seither manually or through a presence application or an application that influences presence values, allows the user to determine or establish how available he or she wants to be to a presence subscriber. A more fine-grained approach would be to adjust the value of f_u,sdifferently for different presence subscribers. For example, users could choose to be0.9 available for their superior but only 0.3 available for presence subscribers outside their department.
• FIGS. 2 and 3 are graphs illustrating two exemplary presence functions for different presence sources, s, as a function of the time difference d between the current time and earlier presence events originating at s. For example, consider a user A having two presence sources, a mobile phone and an IM client, i.e., S equals {cellphone, IMclient}. Two presence functions are defined, f_A,cellPhoneand f_A,IMclient, and assume the experience with user A in these two functions reflects that presence levels for user A on the mobile phone decrease more rapidly than presence levels on the IM client. Thus, the exemplary functions are defined as followed:
  f_A,cellPhone(d)=25/(d+25); and
  f_A,IMclient(d)=10/(√{square root over (d)}+10).
• Suppose A is a member of the universe U of all database experts in an organization and the subscriber to A's presence is an expert locator application that is looking for a database expert at 10:05 AM on a given day. It is assumed that the last time A touched a button on her mobile phone was at time t_cellPhoneequal to 9:20 AM on the same day and the last time she used her IM client was at time t_IMclientequal to 8:35 AM on the same day. Assume further that the presence subscriber in question prefers an expert available on voice over an expert available on IM with a ratio of 2 to 1. Thus, the two functions are assigned weights of ⅔ and ⅓, respectively, to compute the overall availability of each expert. It is noted that the parameters in a weighted function typically add up to 1. This yields the following function:
  f_A,overall(t)=⅔*f_A,cellPhone(t−t_cellPhone)+1/3*(t−t_IMclient)=50/(3*(t−t_cellPhone)+75)+10/(3*√{square root over (t−t_IMclient)}+30)
• At 10:05 AM, the overall presence/availability level of A is therefore 0.4091. If all other experts in U have presence/availability levels lower than 0.4091, then the expert locator application will select A at this time. A's presence level at 10:05 AM is higher on her IM client than her mobile phone according to the functions f_A,cellPhoneand f_A,IMclient. The expert locator application might thus try to reach A on her IM client first despite the locator's preference for voice or might indeed try to reach A on her mobile phone first. This discussion, however, is beyond the scope of the presence/availability level computation.
• Presence Agent
• As previously indicated, thepresence agent400 is a software entity that communicates with thepresence server500 over thenetwork150. The network connection need not be a direct one, i.e., the data connection does not necessarily terminate at thepresence server500. Intermediaries may be present and thepresence agents400 can connect to thepresence server500, for example, through a gateway or proxy; via a database, shared file, or shared memory from where thepresence server500 picks up presence events frompresence agents400; or via an application that performs some type of preprocessing or filtering on presence events. For the sake of illustration, it is assumed that thepresence agent400 is connected to thepresence server500 without any intermediate proxy or system.
• Thepresence agent400 can be deployed on any commercially availablemobile phone110 that can execute thepresence agent400 and allow thepresence agent400 to intercept all button presses or can notify thepresence agent400 of button presses. Thepresence agent400 can be deployed, for example, on adevice110 that executes the Symbian operating system or another embedded operating system. As previously indicated, an alternate embodiment of the present invention allows the functionality of thepresence agent400 to be implemented on one or more nodes in thenetwork150.
• FIG. 4 is a flow chart describing an exemplary implementation of thesoftware agent process400. Generally, when the user powers up themobile phone110, thesoftware agent400 is launched automatically and establishes a data connection to thepresence server500. The first exchange of data over this connection indicates to thepresence server500 that themobile phone110 has been powered up and includes, for example, the telephone number and potentially other parameters, such as a user name.
• Thepresence agent400 can strive to maintain the data connection until the user turns off themobile phone110 or can tear down the data connection after each data exchange with thepresence server500 and then re-establish the connection before the next data exchange. In the latter case, a periodic data connection re-establishment can optionally be employed even in the absence of presence events on themobile phone110, as a heartbeat signal to thepresence server500.
• As shown inFIG. 4, a test is performed duringstep410 to determine if a powering up or down of thephone device110 is detected. If it is determined duringstep410 that a powering up or down of thephone device110 has been detected, then the macropresence event is reported to thepresence server500 duringstep420.
• Similarly, a test is performed duringstep430 to determine if a button press is detected. As previously indicated, thepresence agent400 reports button presses and other events on themobile phone110 to thepresence server500. Thepresence agent400 may include, for example, an indication of the pressed button, as well as the mobile phone's phone number and potentially other parameters in the ensuing data exchange with thepresence server500. As discussed below in conjunction withFIG. 6, thepresence server500 will record the time of the button press in the user's micropresence information. In the special case of the user pressing the power button (to power off the phone), thepresence server500 will also update the macropresence of the user.
• In order to prevent flooding thepresence server500 with micropresence presence events frommobile phones110, thepresence agent400 can optionally propagate button presses or other events related to micropresence only if the last such button press or event was more than t_ftime units ago where t_fis a configurable parameter. To this end, the presence agent must store the time t_lof the last macro/micropresence event on the phone.
• Thus, if it is determined duringstep430 that a button press (or another event) has been detected, then a further test is performed duringstep440 to determine if the time, t_l, since the last reported micropresence event exceeds the threshold, t_f. If it is determined duringstep440 that the threshold has not been exceeded then there is no need to report the current micropresence event. If, however, it is determined duringstep440 that the threshold has been exceeded then the current micropresence event is reported to thepresence server500 duringstep450. In this manner, when a micropresence event occurs, thepresence agent400 compares the current time t_cwith t_land propagates the event to the presence server if the difference between t_cand t_lexceeds the threshold, t_f. If t_fis set to zero, the presence agent reports every micropresence event. Setting t_fto zero might be desirable for reporting purposes, advanced queries from presence subscribers, and with fewmobile phones110 connected to thepresence server500.
• Presence agents may also periodically recompute the values f_u,swith a configurable frequency to determine whether the user must be prompted for a presence and availability status update. A test is thus optionally performed duringstep460 to determine if one or more functions f_u,sfalls below a configured threshold, t_s(i.e., if the value of f_u,sat this time is smaller than the configurable threshold t_s). If it is determined duringstep460 that the value of f_u,sfalls below the threshold, t_s, thepresence agent400 will prompt the user duringstep470 for a presence/availability status update.
• In an alternate implementation where thepresence server500 requests the prompting, thepresence server500 can monitor the functions f_u,sand if the presence server detects that the value of f_u,sfor a given user u and presence source s has fallen below the configurable threshold t_s, thepresence server500 can send a signal to thepresence agent400 connected to the presence source s.
• In either implementation, thepresence agent400 can then prompt the user u for a presence and availability update on the presence source s, for example, by playing a sound or displaying a message on the telephone display. The user may respond, for example, by pressing an arbitrary button on thephone110. The button press constitutes a micropresence event that thepresence agent400 propagates to thepresence server500. If the user does not respond to the prompting, the user can be prompted again. The reprompting should occur with a low frequency f_p, for example on the order of tens of minutes. It is noted that if the user does not respond to the prompting, the presence server (or the presence agent, depending on the implementation) will determine with frequency f_pthat the value of the function f_u,sis below the threshold t_s. If the communication overhead of sending prompting signals from thepresence server500 to theagents400 is considered too high, it is preferred that theagents400 themselves recompute the values of f_u,sand perform the user prompting, when necessary, in the manner shown inFIG. 4. Otherwise, centralized computation of the values of f_u,sby thepresence server500 is preferred.
• Presence Server
• FIG. 5 is a schematic block diagram of anexemplary presence server500. Thepresence server500 comprises a computer system that optionally interacts withmedia550. Thepresence server500 comprises aprocessor520, anetwork interface525, amemory530, amedia interface535 and anoptional display540.Network interface525 allows thepresence server500 to connect to thenetwork150, whilemedia interface535 optionally allows thepresence server500 to interact withmedia550, such as a Digital Versatile Disk (DVD) or a hard drive.Optional video display540 is any type of video display suitable for interacting with a human user of thepresence server500. Generally,video display540 is a computer monitor or other similar video display.
• As shown inFIG. 5 and discussed further below in conjunction withFIGS. 6 and 7, respectively, theexemplary memory530 stores a presenceinformation maintenance process600 and a presenceinformation request process700. For a discussion of suitable techniques for processing such presence information, see, for example, U.S. patent application Ser. No. 10/672,633, entitled “Method and Apparatus for Delivering a Voice Mail Message With an Indication of the Presence of the Sender,” or U.S. patent application Ser. No. 10/672,635, entitled “Programmable Presence Proxy for Determining a Presence Status of a User,” each assigned to the assignee of the present invention and incorporated by reference herein.
• FIG. 6 is a flow chart describing an exemplary implementation of a presenceinformation maintenance process600 incorporating features of the present invention. As shown inFIG. 6, the presenceinformation maintenance process600 initially performs a test duringstep610 to determine if a macro or micro presence event has been received from apresence agent400. If it is determined duringstep610 that a macro or micro presence event has been received from apresence agent400, then the event is recorded duringstep620 including a time stamp.
• A test is performed duringstep630 to determine if the time since the last received heartbeat signal exceeds a threshold of n intervals. If thepresence server500 does not receive the heartbeat for n consecutive intervals, where n is a configurable parameter, thepresence server500 will consider the macropresence of this user to have ended duringstep640. This heartbeat mechanism addresses situations where the connection is lost due to, for example, dropped mobile phone signals, software errors and hardware problems with the phone (including a drained battery). These are cases where the likelihood is large that the user indeed cannot be reached on his or her mobile phone. In the case of a permanent data connection between thepresence agent400 and thepresence server500, unavailability of the user due to events such as those mentioned above will result in the termination of the data connection, which thepresence server500 can interpret as the end of the macropresence of the user.
• A further test is performed duringstep650 to determine if the time since the last computation of the fuzzy presence functions, f_u,s, exceeds a threshold, 1/f_p. If it is determined duringstep650 that the time since the last computation of the fuzzy presence functions, f_u,sexceeds the threshold, 1/f_p, then the fuzzy presence functions, f_u,sare recomputed and cached duringstep660.
• Assuming that there is a high frequency of presence queries against the fuzzy presence values of users, such a periodic recomputation and caching of the fuzzy presence of users can be performed with the configurable frequency of f_pby thepresence server500. Typically, the recomputation will take place no more often than once in a few minutes. For each user, thepresence server500 stores at a minimum the time of the last presence event from that user'smobile phone110. If storage capacity is not an issue, the type of event (“power on”, type of button last pressed, “power off”, “missed heartbeat” or “data connection terminated”, etc.) should also be stored, as well as a log of past presence events for the purpose of reporting and enabling presence queries that include the history of user presence.
• An example of the latter would be “find all users with phone numbers in the908 area code who were present between 2 PM and 4 PM today and checked their call logs during that time”. After each interval of 1/f_ptime units, thepresence server500 recomputes f_u,sfor each user u and each of u's presence sources s using the difference between the current time and the time of the last presence event from s for u as the input for f_u,s. Additional computations such as that of f(U) that aggregate values of f_u,sfor different presence sources and users, in the manner described above, may be performed by the presenceinformation request process700, shown inFIG. 7, at the time of a presence query from a presence subscriber. Typically, there is a large number of aggregations that queries may request and thus pre-computing their values is likely to be wasteful if only a small subset of such aggregations is requested on a regular basis. If, however, a small known subset of aggregations is requested regularly, their values may be computed and cached at the times of the periodic recomputation of the f_u,svalues instead of performing on-demand computations of these aggregations. If the expected frequency of presence queries is small, an on-demand computation and caching can be performed of the f_u,svalues as well as of the aggregations.
• FIG. 7 is a flow chart describing an exemplary implementation of a presenceinformation request process700. As shown inFIG. 7, the presenceinformation request process700 initially computes the presence function f_u,s(d) for each presence source duringstep710. Thereafter, the presenceinformation request process700 sorts the computed f_u,s(d) functions duringstep720 and then selects, duringstep730, the first presence source in the sorted list as the presence source where user u is most likely to be present and available.
• Proxy Presence
• The presence of a user refers to the physical presence of the user at a device, application, computer or system, generally at a given time and in a certain location. The user presence is of interest as an indication of where a user is or was at a certain time, what activity the user is or was engaged in, and how to currently reach this user with a communication. The user is seen as an actor (in the sense of being active) and as a subject. However, the user can also be viewed as an object of business and personal processes in which application-dependent representations of the user are processed. For example, a user's loan application in a bank business process represents the user, and the bank business process is doing something to the user's representation in a loan application by processing it. The user behind that loan application becomes the object of the bank business process. In another example, the user's contact information and address might get added to an electronic address book by another user. The former user becomes the object of the latter user's personal process of adding somebody to the address book, and the former user's contact information and address constitute that user's representation from the point of view of this personal process.
• In both examples, the user's representation is present in the process in question for as long as the process is working on the user's representation. This type of presence is referred to as proxy presence and the representation of the user becomes a proxy presence source. The beginning and end of a proxy presence interval, i.e., the macro proxy presence, of a user, as well as the micro proxy presence, has to be determined in an application-specific manner.
• Proxy presence may be interesting to various proxy presence subscribers for a variety of reasons. The user himself might be interested in his loan application proxy presence. For example, a customer service branch of a bank could employ the proxy presence techniques described herein to notify the user when the bank business process begins and ends processing the loan application. The beginning and end of the loan application can be considered the user's macro proxy presence whereas each major step or event along the way in the loan processing can be considered a micro proxy presence event. An example of the latter is a review, access or update of the loan application by a loan officer, or when an appraisal is performed in conjunction with the loan application.
• Similarly, in an insurance company, an insurance policy, such as a life, car, home or umbrella policy, can be considered as a proxy representation of the user. Since a policy is typically a long-lived proxy presence source, the macro presence interval may be defined as the time that passes between the beginning of an insurance process that operates on the policy and the end of this process. If the insurance process has an extended duration, micro proxy presence can be introduced for policies as events that touch upon the processing of the policy. For example, retrieving the policy and reviewing the clauses of the policy by a claims adjustor could be considered micro proxy presence events. A proxy presence subscriber may want to identify the 5% least “proxy present” users for a new marketing campaign. A different proxy presence subscriber might be interested in all currently proxy present users so that it can send status updates for these users' insurance policies.
• Users might be curious about the proxy presence of their contact information in the electronic address books of friends or colleagues. The proxy presence subscriber client might periodically request a proxy presence update from the proxy presence server and notify the user when a friend has terminated his or her proxy presence.
• The concepts of presence aging and fuzzy presence, as discussed above, apply to proxy presence sources under certain circumstances, as would be apparent to a person of ordinary skill in the art. Thus, the presence aging and fuzzy presence techniques described above can be employed to rank proxy presence events, originating at all proxy presence event sources, according to the timeliness of the proxy presence events.
• As previously indicated, to determine real presence,presence agents400 are deployed on or in conjunction withuser devices110, such as personal computers, mobile phones, or applications. To determine proxy presence, the applications and systems that contain user representations have to either containproxy presence agents400 as integral parts or they have to giveproxy presence agents400 access to proxy presence. In either implementation, the same options that apply to connectingreal presence agents400 toreal presence servers500 are valid for connecting proxy presence agents with proxy presence servers.
• If an application or system does not containproxy presence agents400 as integral parts, access to externalproxy presence agents400 can be provided in many different ways. For example, access to external proxy presence agents can be provided (i) through databases, shared files, or shared memory, from whichproxy presence agents400 retrieve changes in proxy presence information (in the case of a database, theproxy presence agent400 can be built around a database trigger that gets invoked when the content of a proxy presence table changes, as discussed below in conjunction withFIG. 8); (ii) by pushing proxy presence changes toproxy presence agents400 via data connections, for example, by a node in a business workflow sending a notification of a proxy presence event to aproxy presence agent400; or (iii) by allowing a proxy presence agent to periodically poll the application for proxy presence changes. For a detailed discussion of suitable techniques for adding such communication tasks to a workflow, see U.S. patent application Ser. No. 10/955,918, entitled “Method and Apparatus for Providing Communication Tasks in a Workflow,” incorporated by reference herein.
• If aproxy presence agent400 is given access to complete knowledge of every user's proxy presence, fuzzy proxy presence is not a particularly meaningful concept, and discrete proxy presence states, such as “present” or “not present” can be employed. Otherwise, fuzzy proxy presence may be computed in analogy to fuzzy real presence.
• FIG. 8 is a sample table for an exemplarydatabase trigger database800 that records one or more database triggers that can be used to report presence events to aproxy presence agent400 of a user. The exemplary database triggers in thesample database800 are based on the loan application example discussed above.
• Such database triggers provide a mechanism for a service provider, such as a bank, to notify aproxy presence agent400 of presence events, such as macropresence and micropresence events. The loan process is considered a proxy presence source, in the manner described above for real proxy events. Generally, as the service provider logs information in a database, one or more database triggers executing on the database server can monitor the recorded information for presence related information that should be reported to aproxy presence agent400. A database trigger is typically comprised of three parts:
• • 1. a description of triggering events, such as database inserts, updates, or deletes (for example, a triggering event may be that a given user's loan application record has been updated in the database);
  • 2. one or more conditions that describe restrictions on the triggering events (the conditions must evaluate to TRUE to allow the trigger to proceed to part3; for example, the conditions may require that the given user's loan application record in the database has a new entry in the “status” column that says either “accepted” or “rejected”);
  • 3. an action expressed as code (embodied, for example, as code in a database-centric programming language that can call external programs, such as aproxy presence agent400 and send data to that external program; because database-centric programming languages are typically too restrictive to allow coding aproxy presence agent400, theproxy presence agent400 would typically be an external program rather than the trigger itself).
• System and Article of Manufacture Details
• As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
• The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
• It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.

Claims (42)

1. A method for collecting presence information about a user from one or more presence sources associated with said user, comprising:

associating a presence agent with each of said presence sources; and

obtaining presence information from said presence agents.

2. The method ofclaim 1, wherein said presence agent reports one or more macropresence events.

3. The method ofclaim 1, wherein said presence agent reports one or more micropresence events.

4. The method ofclaim 3, wherein said presence agent limits a number of said reported micropresence events.

5. The method ofclaim 1, wherein said presence agent prompts said user to update said presence information based on one or more criteria.

6. The method ofclaim 1, further comprising the step of ensuring that said presence agents are still active.

7. The method ofclaim 6, wherein an inactive status of one or more of said presence agents is treated as a macropresence event.

8. The method ofclaim 1, further comprising the step of generating a continuous presence function for each of said presence sources that characterizes the likelihood of said user to be present on said corresponding presence source at a given time.

9. The method ofclaim 8, further comprising the step of recomputing one or more of said continuous presence functions if a time since a last computation exceeds a threshold.

10. The method ofclaim 1, further comprising the step of recording said obtained presence information with an indication of a time associated with said obtained presence information.

11. The method ofclaim 1, wherein said presence information indicates a likelihood that said user can be reached at one or more presence sources.

12. The method ofclaim 1, wherein said one or more presence sources includes one or more of applications, devices and locations.

13. A method for collecting presence information about a user from a presence source associated with said user, comprising:

detecting presence events by executing on said presence source; and

reporting said detected presence events to one or more servers.

14. The method ofclaim 13, wherein said presence events are one or more macropresence events.

15. The method ofclaim 13, wherein said presence events are one or more micropresence events.

16. The method ofclaim 15, further comprising the step of limiting a number of said reported micropresence events.

17. The method ofclaim 15, wherein said reported micropresence events include at least one event that does not normally initiate a communication by said presence source.

18. The method ofclaim 13, further comprising the step of prompting said user to update said presence information based on one or more criteria.

19. The method ofclaim 13, further comprising the step of generating a continuous presence function that characterizes the likelihood of said user to be present on said presence source at a given time.

20. The method ofclaim 13, wherein said presence source is one or more of an application, device or location.

21. The method ofclaim 13, wherein said presence events can be detected without an active user login.

22. The method ofclaim 13, wherein said presence agents events enable presence reporting to a presence server or application provided by a third party.

23. A method for characterizing a presence of a user at one or more presence sources associated with said user, comprising:

receiving an indication of one or more presence events related to at least one of said presence sources; and

generating a continuous presence function based on said one or more presence events for said at least one presence source that characterizes the likelihood of said user to be present on said corresponding presence source at a given time.

24. The method ofclaim 23, further comprising the step of recomputing said continuous presence function if a time since a last computation exceeds a threshold.

25. The method ofclaim 23, further comprising the step of recording at least one of said received presence events with an indication of a time associated with said presence event.

26. The method ofclaim 23, wherein said presence source is one or more of an application, device or location.

27. The method ofclaim 23, wherein said continuous presence function indicates a current level of presence or availability of said user on a continuous scale based on said presence source and an amount of time since a last presence event occurred from said presence source.

28. An apparatus for collecting presence information about a user from one or more presence sources associated with said user, the apparatus comprising:

a memory; and

at least one processor, coupled to the memory, operative to:

associate a presence agent with each of said presence sources; and

obtain presence information from said presence agents.

29. The apparatus ofclaim 28, wherein said presence agents execute on said corresponding presence source.

30. The apparatus ofclaim 28, wherein said presence agent reports one or more macropresence events and micropresence events.

31. The apparatus ofclaim 28, wherein said presence agent prompts said user to update said presence information based on one or more criteria.

32. The apparatus ofclaim 28, wherein said processor is further configured to generate a continuous presence function for each of said presence sources that characterizes the likelihood of said user to be present on said corresponding presence source at a given time.

33. The apparatus ofclaim 32, wherein said processor is further configured to recompute one or more of said continuous presence functions if a time since a last computation exceeds a threshold.

34. The apparatus ofclaim 28, wherein said processor is further configured to record said obtained presence information with an indication of a time associated with said obtained presence information.

35. The apparatus ofclaim 28, wherein said presence information indicates a likelihood that said user can be reached at one or more presence sources.

36. The apparatus ofclaim 28, wherein said one or more presence sources includes one or more of applications, devices and locations.

37. An article of manufacture for collecting presence information about a user from one or more presence sources associated with said user, comprising a machine readable medium containing one or more programs which when executed implement the steps of:

associating a presence agent with each of said presence sources; and

obtaining presence information from said presence agents.

38. An apparatus for characterizing a presence of a user at one or more presence sources associated with said user, the apparatus comprising:

a memory; and

at least one processor, coupled to the memory, operative to:

receive an indication of one or more presence events related to at least one of said presence sources; and

generate a continuous presence function based on said one or more presence events for said at least one presence source that characterizes the likelihood of said user to be present on said corresponding presence source at a given time.

39. The apparatus ofclaim 38, wherein said processor is further configured to recomputed said continuous presence function if a time since a last computation exceeds a threshold.

40. The apparatus ofclaim 38, wherein said processor is further configured to record at least one of said received presence events with an indication of a time associated with said presence event.

41. The apparatus ofclaim 38, wherein said continuous presence function indicates a current level of presence or availability of said user on a continuous scale based on said presence source and an amount of time since a last presence event occurred from said presence source.

42. An article of manufacture for characterizing a presence of a user at one or more presence sources associated with said user, comprising a machine readable medium containing one or more programs which when executed implement the steps of:

receiving an indication of one or more presence events related to at least one of said presence sources; and

generating a continuous presence function based on said one or more presence events for said at least one presence source that characterizes the likelihood of said user to be present on said corresponding presence source at a given time.

Images