Patent Publication Number: US-9432473-B2

Title: Online presence management for web sites

Description:
FIELD 
     The present disclosure relates generally to web sites, and in a specific example embodiment, to online presence management for web sites. 
     BACKGROUND 
     Determining presence of other users within a system is often desired. Conventional systems may require a browser to continuously broadcast a presence indication message to a server (e.g., using extensible messaging and presence protocol (XMPP)). Typically, the presence detected is one of a general offline, online, or away (e.g., online but have not performed any actions within a certain time period). Because the browser is continuously broadcasting its presence, more network traffic may be required to track presence. For example, over 70% of XMPP inter-server traffic may be presence data, of which 60% may be redundantly transmitted. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       Various ones of the appended drawings merely illustrate example embodiments of the present invention and cannot be considered as limiting its scope. 
         FIG. 1  is a block diagram illustrating an example of an environment in which example embodiments may be deployed. 
         FIG. 2  is a block diagram illustrating an example embodiment of a Comet server. 
         FIG. 3  is a flowchart of an example method to trigger presence management. 
         FIG. 4  is a flowchart of an example method to determine presence states for a user. 
         FIG. 5  is a flowchart of an example method to provide presence information to subscribers. 
         FIG. 6  is a sequence diagram depicting communication flows within example embodiments. 
         FIG. 7 a   - FIG. 7 d    provide a graphical illustration of  FIG. 5 . 
         FIG. 8  is a simplified block diagram of a machine in an example form of a computing system within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. 
     
    
    
     DETAILED DESCRIPTION 
     The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the present invention. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail. 
     Systems and methods for online presence management of web sites are provided. In example embodiments, users in a hosted network are able to determine status or presence state of other users within groups. The groups can be diverse such an association of people that make use of a collaborative website or tool (e.g., project groups, common interest groups, social networking groups, committees, boards, company teams, intercompany teams, standards groups). For example, the group may be a group directed to a particular software project at work, a stamp collecting interest group, a single parent support group, and so forth. These groups, also known as activities, comprise an area where documents, pictures, business tools (e.g., pro/con tables, polls), and other forms of information may be shared between group members. In some embodiments, the groups are private groups. A user may join a private group by invitation or as a creator and owner of the private group. As will be discussed in more detail below, each user and private group may be associated with different channels of communication. These channels of communication include a presence channel (hereinafter referred to as a “channel”) for each user and activity. Channels are part of the Comet protocol. Each Comet message is a JSON formatted text message where the JSON object includes a “channel” property. 
     In accordance with example embodiments, a presence message is received from a browser associated with a user. The presence message may be generated by the browser when a presence state change occurs and returned to a presence management system. One or more channels indicated by the presence message are determined, each channel being associated with an activity or the user. A presence state change for each of the one or more channels is then identified, and a presence storage may be updated accordingly. Presence information comprising the presence state change for the user may be provided to browsers of subscribers (e.g., other online users) who subscribe to the same one or more channels. The presence information may be provided whenever a change in presence occurs and without an explicit request from the browsers. 
     With reference to  FIG. 1 , an embodiment of an environment  100 , in which example embodiments of the present invention may be deployed, is shown. A user device  102  having a browser  104  is communicatively coupled to a Comet server  106 . The user device  102  may be coupled via any one or more of a local or wide area network (e.g., the Internet). While a Comet server  106  is provided, it is noted that other types of servers may be utilized to provide the presence management system. For example, other types of AJAX or JavaScript-enabled servers may be used. The Comet server  106  will be discussed in more detail in connection with  FIG. 2 . 
     In example embodiments, the browser  104  communicates with various components of the environment  100  in order to obtain data for display at the user device  102 . As such, the browser  104  may send a HyperText Transfer Protocol (HTTP) request to a web server  110 . The web server  110  renders HTML  112 , which includes JavaScript and links to JavaScript files associated with presence management. The HTML  112  is then returned to the browser  104 . When the browser  104  executes the JavaScript, online presence management may be triggered. 
     The links from the HTML  112  access the JavaScript files on a load balancer  108  and the JavaScript files may be downloaded to the browser  104  in some embodiments. Because the JavaScript files seldom change, these files may be statically downloaded in accordance with one embodiment. The browser  104  may perform a handshake with the Comet server  106  and establish a protocol via a Comet protocol module  114 . The protocol enables connection and tracking of presence at the browser  104 . 
     The JavaScript files may be associated with or used by a presence communication module  116 . The presence communication module  116 , when executing the JavaScript files, exchanges publication or subscription presence information with the Comet server  106 . For example, the presence communication module  116  may publish presence information (e.g., “I am online and active in Activity 20 .”) to the Comet server  106  whenever a change in presence occurs. The presence communication module  116  may also receive presence information (e.g., User 5  is online and active in Activity 15 ) regarding other users when the user of the user device  102  is a subscriber to channels associated with the other users. A presence visual module  118  takes the presence information received from the Comet server  106  and visually presents the presence information on the browser  104 . 
     While only one Comet server  106  is shown in  FIG. 1 , it is noted that more than one Comet server  106  may be utilized. In these embodiments, an active message queue (AMQ) may be present in front of the web server  110  and be coupled with a plurality of Comet servers. The AMQ allows any server process to connect to it with a port number using some network socket communication. As such, the AMQ may communicate messages back and forth between different server processes and different Comet servers. In the present case, presence state may be exchanged between the different Comet servers. 
     Referring now to  FIG. 2 , an example block diagram of the Comet server  106  is shown. Among other components, the Comet server  106  comprises a user presence engine  202  for conducting presence management. The user presence engine  202  comprises a channel subscription module  204 , a channel states module  206 , a presence storage  208 , and a presence communication module  210 . 
     The channel subscription module  204  handles subscription to activities and their associated channels. In some embodiments, a user may be invited to join an activity via the channel subscription module  204 . In other embodiments, the user may create an activity and invite other users to join the activity. The activity may be created by the channel subscription module  204  or another component of the Comet server  106 . Once an activity is created or a user joins a pre-existing activity, the corresponding information may be stored to the presence storage  208  by the channel subscription module  204 . A user is allowed to subscribe to channels for activities that the user is invited to or created. In other words, a first user may be allowed to subscribe to channels associated with other users in the same activities as the first user. 
     In some embodiments, the channel subscription module  204  also determines which channels the user (and browser associated with the user) is subscribed to when the user accesses the hosted network associated with the Comet server  106 . For instance, when the user joins an activity, the user may decide to be a subscriber to the corresponding channel for the activity (e.g., Activity 20 ). Additionally, the user may, in some cases, be a subscriber to channels associated with one or more of the other users (e.g., User 5 ) in the same activity. The channel subscription module  204  determines these channels in order to provide instructions to the channel states module  206  and presence communication module  210  to provide the presence information to subscribers of those channels. 
     It is noted that the user subscribes to channels that the user is interested in and not all channels with which the user is associated (e.g., all channels for activities/groups that the user is a member). For example, the user may be a member of several activities, but is not interested in determining presence state for some of these activities. In these cases, the user does not need to subscribe to the channels associated with these activities not of interest. 
     The channel states module  206  determines presence state information for users of the hosted network. In example embodiments, the presence message received from the browser comprises a private message generated by the browser and sent to a server/presence channel handled by the channel states module  206 . The channel states module  206  determines affected channels and associated presence state changes for the affected channels from the presence message. 
     The presence storage  208  comprises any storage device or storage mechanism that maintains presence information. For example, the presence storage  208  may be a cache, a database, or a hash table. In the hash table embodiment, the hash table may comprise a mapping of session identifiers, user identifiers, client identifiers, and channel attributes. The session identifier is a cookie value for a web application session, and the user identifier is derived from the session identifier. For example, a lookup process may be performed at the web server  110  to determine the user identifier. The client identifier is assigned by the Comet server  106  for the duration of the Comet connection and corresponds to a browser tab. 
     The channel attributes identify the channel that corresponds to where the client (e.g., the browser of the user) is online or active. The channel attributes may be a name of an arbitrary channel which conveys a status or state. In example embodiments, two conventions for channel attributes are used. The first is directed to a user identifier to indicate the channel where the user is online. The second is directed to an activity to indicate the channel containing the online users who are also active in the activity (e.g., activityID). Thus, a user may subscribe to any number of user channels and activity channels in order to obtain presence status for specific users or for all users within a specific activity, respectively. However, the user, in accordance with one embodiment, is allowed to subscribe to channels for which the user is a member of the activity or for users associated with these activities. In this manner, the presence state is provided to select subscribers (e.g., fellow group/activity members). 
     It is noted that multiple browsers may be open at the same time at the user device  102 . In this case, presence information in the presence storage  208  may indicate multiple presence states for a user. 
     In example embodiments, the presence state may include offline (e.g., not logged in), online (e.g., logged in somewhere in the hosted network such as on a profile page or other activity), and active. An “active” state indicates that the user is online and working (e.g., viewing or editing) within an activity of which a subscriber has subscribed to the corresponding channel. An “online” state may be provided if the user is online and working within an activity to which a subscriber has not subscribed. For example, a subscriber subscribes to an Activity 20  channel for User 5 , but User 5  is only active in Activity 15 . Thus, the subscriber will only get an indication that User 5  is “online.” However, if User 5  becomes active in Activity 20 , the subscriber will receive a presence update indicating that User 5  is now “active” in Activity 20 . 
     In further embodiments, the presence information may include more details. For example, in channels where the user is active, presence information may be provided that indicates what the user is doing within the activity (e.g., viewing a document, adding an image, editing a document, using a business tool). Other presence information that may be provided include, for example, time online, time active in the activity, and actions performed within the activity since beginning of current session. Additionally, further embodiments may include presence states such as “away” (e.g., inactive for a certain period of time, but still logged in), “do not want to share,” or “editing an item.” 
     The presence communication module  210  performs communication exchanges with the browsers of users and subscribers. For instance, the presence communication module  210  receives the published presence information from the browser  104  and provides the published presence information to the channel states module  206  for processing. The presence communication module  210  also pushes the presence information comprising presence state changes to subscribers. 
       FIG. 3  is a flowchart  300  of an example method to trigger presence management. The method may occur when a user first logs into the hosted network and attempts to access data. In operation  302 , the browser  104  sends an HTTP request to the web server  110  for the data. 
     In operation  304 , the web server  110  renders an HTML including the requested data. The HTML may further include JavaScript or links to JavaScript files associated with presence management. The HTML  112  is then returned to the browser  104  in operation  306 . 
     In operation  308 , the browser  104  may perform a handshake with the Comet server  106  and establish a protocol. The protocol enables connection and tracking of user presence in the hosted network. 
     Once the protocol is established, online presence management may be triggered in operation  310 . Presence management comprises receiving published presence information from the browser  104 , which will be discussed in more detail in connection with  FIG. 4 . Presence management further comprises providing presence information to subscribers, which will be discussed in more detail in connection with  FIG. 5 . 
       FIG. 4  is a flowchart  400  of an example method to determine presence state of a user. In operation  402 , a browser associated with the user sends an HTTP request to the web server  110 . The HTTP request may be associated with a navigation within the hosted network (e.g., between activities, profile page, or any other location of the hosted network) or a logoff from the hosted network, for example. 
     The web server  110  renders an HTML page with a code (e.g., JavaScript) in response to the HTTP request and returns the HTML page to the requesting browser  104  in operation  404 . The browser  104  loads and displays the HTML page. The loading of the code on the browser  104  may cause publication of a message indicating a presence state change of the user in operation  406 . For example, if the user (e.g., having a user identifier User 5 ) logs out of the hosted network, the code in the HTML page sends a message to the Comet server  106  to indicate a disconnect. In an example where the user navigates from an activity (e.g., Activity 20 ) to a non-activity (e.g., a profile page), the code causes the browser to publish a message indicating the navigation (e.g., online and inactive in Activity 20 ). 
     It is noted that in examples where the user&#39;s presence does not change (e.g., HTTP request for data within a same activity), the code is not triggered to publish a presence message. Thus, the network traffic is reduced since only presence state changes are published to the Comet server  106 . 
     In operation  408 , the Comet server  106  receives the presence message from the browser  104  and determines the presence state change from the presence message. In the logoff example, the Comet server  106  detects that the user is no longer present on the User 5  channel and Activity 20  channel. For the page navigation example where the user navigates from the activity to the profile page, the Comet server  106  will detect that the user is still present on the User 5  channel but is no longer active in the Activity 20  channel. In operation  410 , the user&#39;s presence information is updated in the presence storage  208 . Subsequently, the Comet server  106  broadcasts presence state changes to relevant subscribers as is described in more detail in connection with  FIG. 5 . 
     In an embodiment where a system crash occurs at the user device  102 , a timeout period may be imposed. For example, if after two minutes the Comet server  106  detects that there is no browser  104  present, the Comet server  106  will update the presence storage  208  and, as will be discussed in  FIG. 5 , broadcast presence (change) information to online subscribers of the affected channel(s). 
       FIG. 5  is a flowchart  500  of an example method to provide presence state to a subscriber at a browser  104 . When the subscriber initially logs onto the hosted network, the channel subscription module  204  determines all channels the subscriber subscribes to in operation  502 . The channels may comprise user channels, activity channels, or a combination of both. 
     State information for each of the subscribed to channels is determined and provided to the subscriber in operation  504 . In example embodiments, the channel states module  206  accesses a presence storage  208  and determines the presence information for the channels determined in operation  502 . 
     If a presence state change is detected in operation  508 , then the presence information related to the presence state change is provided to the subscriber in operation  510 . The detection of state change in operation  508  may occur in operation  408  of  FIG. 4 . That is, when the state change is detected in operation  408 , the Comet server  106  broadcasts a notification indicating the presence (state change) information to all online subscribers of the channel(s) in which the presence state change is detected. Because the presence information is broadcast (e.g., pushed to the browser  104 ) when a presence state change occurs, network traffic may be reduced over conventional presence management systems which continuously broadcast presence information. 
       FIG. 6  is a sequence diagram depicting communication flows within example embodiments. Initially, the browser  104  of the user device  102  associated with a user sends an HTTP request to the web server  110 . The HTTP request may be associated with a login to the hosted network, navigation within the hosted network (e.g., between activities, profile page, or any other location of the hosted network), or a logoff from the hosted network. In response, the web server  110  renders an HTML page with a code (e.g., JavaScript). 
     The HTML and code is returned to the user device  102  where the browser  104  loads and displays the HTML page. In cases where the presence state changes, the loading of the code causes publication of a message indicating a presence state change. For example, if the user (e.g., having a user identifier User 5 ) logs out of the hosted network, the code sends a presence message to the Comet server  106  to indicate a disconnect. In example embodiments, the presence message comprises presence state change information (e.g., a change from “online” to “away”, a change from “online” to “active”, or any other states that may be defined). If the user&#39;s presence does not change (e.g., HTTP request for data within a same activity), the code is not triggered to publish the presence message. The Comet server  106  receives the presence message from the user device  102  determines the presence state change from the presence message. In the logoff example, the Comet server  106  detects that the user is no longer present on the User 5  channel and Activity 20  channel. 
     Since example embodiments provide presence messages when the presence state changes, detection of state change is automatic and will trigger the Comet server  106  to determine affected subscribers. The Comet server  106  broadcasts a notification indicating the presence (state change) information to subscriber devices  600  of all online subscribers of the channel(s) in which the presence state change has occurred. The Comet server  106  also may return the presence state change to the user device  102  since the user device  102  is an instance of the subscriber devices  600 . Accordingly, in an example embodiment, only a state change is communicated between the various devices (e.g., user device  102 , Comet server  106 , subscriber device  600 , or any other devices). 
     For a better understanding of example embodiments,  FIG. 7 a   - FIG. 7 d    provide a graphical illustration of an example embodiment of the method of  FIG. 5 .  FIG. 7 a    depicts a list of channels for User 5 . User 5  may be assigned a User 5  channel, which is User 5 &#39;s presence channel on the hosted network. Additionally, User 5  is a member of Activity 15 , Activity 17 , and Activity 20 . As such, corresponding (presence) channels for each of these activities are associated with User 5 . 
     Subsciber 1  is also a member of Activity 15  and Activity  20 . Therefore, Subscriber 1  subscribes to these channels. However, Subscriber 1  is not a member of Activity 17 , and cannot subscribe to the Activity 17  channel. Alternatively, Subscriber 1  may be a member of Activity 17 , but chooses not to subscribe to the Activity 17  channel (e.g., marked as “not subscribed”). Similarly, Subscriber 2  has subscribed to the User 5  channel and the Activity 15  channel. It is noted that User 5  may be a subscriber to channels, such as the Activity 15  channel, Activity 17  channel, or Activity 20  channels as well as user channels (e.g., user channels of Subscriber 1 , Subscriber 2 , and other users in the same activities as User 5 ). 
     While embodiments have been described in which subscribers are only allowed to subscribe to channels associated with activities in which the subscribers are members, it is noted that alternative embodiments may contemplate allowance for subscription to channels in which the subscriber is not a member of the corresponding activity. 
     Referring now to  FIG. 7 b   , User 5  logs onto the hosted network and performs some action in Activity 20  (whereby active activities are indicated in bold). When User 5  first logs on and accesses data on Activity 20 , a presence message is sent to the user presence engine  202  that will indicate the state change (e.g., online and active in Activity 20 ). When this occurs, subscribers that subscribe to the User 5  channel and the Activity 20  channel will receive the presence state change. In the present case, Subscriber 1  will receive presence information indicating that User 5  is online and active in Activity 20 . However, since Subscriber 2  does not subscribe to the Activity 20  channel, Subscriber 2  only receives presence information indicating that User 5  is online. 
     User 5  may be active in more than one activity at a time (e.g., has multiple browsers opened to different activities).  FIG. 7 c    depicts a case where User 5 , who was previously active in Activity 20  (as shown in  FIG. 7 b   ), opens a new browser and performs an action in Activity 15 . The initial access to Activity 15  will trigger a presence message to the user presence engine  202 . Based on the presence state change, Subscriber 1  receives presence information indicating that User 5  is active on Activity 15 . The presence information on Subscriber 1 &#39;s browser will now indicate that User 5  is online and active in Activity 15  and Activity 20 . Similarly, Subscriber 2  receives presence information indicating that User 5  is active on Activity 15  and the browser will now indicate User 5  is online and active in Activity  15 . 
     When User 5  leaves an activity, a presence message is sent to the user presence engine  202  indicating the presence state change. As shown in  FIG. 7 d   , User 5  leaves Activity 20  and becomes active in Activity  17 . The user presence engine  202  detects the presence state change and forwards the presence state change information to subscribers of the affect channel, the Activity 20  channel and Activity 17  channel. In the present case, Subscriber 1  receives presence information that will remove the active state from Activity 20 . However, Subscriber 1  will still have the online and active in Activity 15  states unchanged. Because Subscriber 2  did not subscribe to the Activity 20  channel or the Activity  17  channel, the change in states with respect to Activity 20  and Activity 17  do not affect Subscriber 2 . Therefore, Subscriber 2  does not receive a presence information message with the presence state change. 
     Modules, Components, and Logic 
     Certain embodiments described herein may be implemented as logic or a number of modules, engines, components, or mechanisms. A module, engine, logic, component, or mechanism (collectively referred to as a “module”) may be a tangible unit capable of performing certain operations and configured or arranged in a certain manner. In certain exemplary embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) or firmware (note that software and firmware can generally be used interchangeably herein as is known by a skilled artisan) as a module that operates to perform certain operations described herein. 
     In various embodiments, a module may be implemented mechanically or electronically. For example, a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor, application specific integrated circuit (ASIC), or programmable logic array (PLA)) to perform certain operations. A module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software or firmware to perform certain operations. It will be appreciated that a decision to implement a module mechanically, in the dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by, for example, cost, time, energy-usage, and package size considerations. 
     Accordingly, the term module should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which modules or components are temporarily configured (e.g., programmed), each of the modules or components need not be configured or instantiated at any one instance in time. For example, where the modules or components comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different modules at different times. Software may accordingly configure the processor to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. 
     Modules can provide information to, and receive information from, other modules. Accordingly, the described modules may be regarded as being communicatively coupled. Where multiples of such modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices and can operate on a resource (e.g., a collection of information). 
     Example Machine Architecture and Machine-Readable Medium 
     With reference to  FIG. 8 , an exemplary embodiment extends to a machine in the example form of a computer system  800  within which instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative exemplary embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, a switch or bridge, a server, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
     The exemplary computer system  800  may include a processor  802  (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory  804  and a static memory  806 , which communicate with each other via a bus  808 . The computer system  800  may further include a video display unit  810  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). In exemplary embodiments, the computer system  800  also includes one or more of an alpha-numeric input device  812  (e.g., a keyboard), a user interface (UI) navigation device or cursor control device  814  (e.g., a mouse), a disk drive unit  816 , a signal generation device  818  (e.g., a speaker), and a network interface device  820 . 
     Machine-Readable Medium 
     The disk drive unit  816  includes a machine-readable storage medium  822  on which is stored one or more sets of instructions  824  and data structures (e.g., software instructions) embodying or used by any one or more of the methodologies or functions described herein. The instructions  824  may also reside, completely or at least partially, within the main memory  804  or within the processor  802  during execution thereof by the computer system  800 , the main memory  804  and the processor  802  also constituting machine-readable media. 
     While the machine-readable storage medium  822  is shown in an exemplary embodiment to be a single medium, the term “machine-readable storage medium” may include a single storage medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store the one or more instructions. The term “machine-readable storage medium” shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of embodiments of the present invention, or that is capable of storing, encoding, or carrying data structures used by or associated with such instructions. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media. Specific examples of machine-readable storage media include non-volatile memory, including by way of example semiconductor memory devices (e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices); magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. 
     Transmission Medium 
     The instructions  824  may further be transmitted or received over a communications network  826  using a transmission medium via the network interface device  820  and utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software. 
     Although an overview of the inventive subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of embodiments of the present invention. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is, in fact, disclosed. 
     As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Additionally, although various example embodiments discussed focus on a specific network-based environment, the embodiments are given merely for clarity in disclosure. Thus, any type of electronic system, including various system architectures, may employ various embodiments of the search system described herein and is considered as being within a scope of example embodiments. 
     The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. For example, while particular components are provided in the presence management system (e.g., web server, Comet server), those skilled in the art will appreciate that other similar components may be used to obtain similar functionalities provided by example embodiments. 
     Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present invention. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present invention as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.