Patent Application
20060190600
This invention relates to presence and presence management systems that communicate presence information. In particular, this invention relates to a presence system that manages the availability of presence information in a group driven manner.
Rapid developments in communication technology, driven by strong market demand, have led to sophisticated presence systems. Presence information maintained in the presence system may indicate when a subscriber is on the phone, at his desk, in a meeting, or in other presence states. This presence information may be shared with other subscribers if the presence system permits access to the presence information.
In order to control access, the subscriber manually configures individual contacts to permit or deny access to the subscriber's presence information. Contacts, or contacts matching a pattern, that have been permitted access are allowed to receive the subscriber's presence information. Otherwise, the presence system blocks access to the subscribers presence information.
There are significant disadvantages with this approach. For example, the subscriber is required to laboriously manage access to their presence information on a contact-by-contact basis. Furthermore, automatically adjusting access to the presence information would be extremely cumbersome on a subscriber-by-subscriber basis.
A need has long existed for improved management of the availability of presence information.
A presence system manages the availability of subscriber presence information sought by a requestor. In response to a request for the presence information, the presence system determines a contact group assigned to the requestor by the system subscriber. The presence system also checks a group access parameter associated with the contact group. The group access parameter may determine whether contact group members, such as the requestor, are allowed access or are denied access to the requested presence information.
When access is allowed, the presence system may further manage the presence information delivered to the requestor. To that end, the presence system determines an allowed portion and/or a blocked portion of the requested presence information. The allowed portion of the presence information is delivered to the requestor, and the denied portion is withheld from the requestor.
The presence system may include a memory and a processor. The memory stores a contact for the presence requestor and a contact group to which the contact is assigned. A group access parameter in the memory is associated with the contact group. The group access parameter may specify whether group members are allowed access or are denied access to requested presence information.
An access determination program checks the group access parameter to determine whether the group members are allowed access to the requested presence information. When the group members are allowed access, the presence system may respond to the requestor with the subscriber presence information. The processor executes the access determination program.
The present invention is defined by the following claims, and nothing in this section should be taken as a limitation on those claims. Further aspects and advantages of the invention are discussed below in conjunction with the preferred embodiments. Any one or more of the above described aspects or aspects described below may be used independently or in combination with other aspects described herein.
The elements illustrated in the Figures interoperate as explained in more detail below. Before setting forth the detailed explanation, however, it is noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in hardware memories, all or part of systems and methods consistent with the presence systems may be stored on, distributed across, or read from other machine-readable media, for example, secondary storage devices such as hard disks, floppy disks, and CD-ROMs; a signal received from a network; or other forms of ROM or RAM either currently known or later developed.
Furthermore, although specific components of the presence systems will be described; methods, systems, and articles of manufacture consistent with the presence systems may include additional or different components. For example, a processor may be implemented as a microprocessor, microcontroller, application specific integrated circuit (ASIC), discrete logic, or a combination of other types of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash or any other type of memory. Flags, parameters, lists, data, databases, tables, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways. The programs discussed below may be parts of a single program, separate programs, or distributed across multiple memories and/or processors.
The entities may communicate over one or more networks 112, 114 or interconnection of networks. The entities 102-110 and networks 112, 114 may exchange information using a packet based protocol. For example, the messaging systems 102-106, presence information system 108, and endpoints 110 may employ the Real Time Protocol (RTP) over the User Datagram Protocol (UDP). Other protocols, including the Transmission Control Protocol/Internet Protocol (TCP/IP) or other network protocols may be additionally or alternatively employed. In addition, the signaling between the entities 102-110 may proceed according to the H.323 packet-based multimedia communications system standard published by the International Telecommunications Union (ITU). The network or interconnection of networks 112, 114 may include the Public Switched Telephone Network (PSTN) and may deliver data to home or business computers, programs, PDAs, pagers, cell phones, wireline phones, internet phones, or any other communication device, electronic system, or system component or program.
The entities in the network 100 may employ protocols that adhere to any desired specification. For example, the entities may employ the Session Initiation Protocol (SIP) developed for Internet conferencing, telephony, presence, events notification and instant messaging, the Jabber protocol, or SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). The form and content of the presence information may be established according to protocols consistent with the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2778 or IETF RFC 2779. Alternatively, the entities may employ extensions to RFC 2778 or RFC 2779, or may employ proprietary protocols.
The subscribers 116 interact with the network 100. A subscriber may be any entity that may be associated with presence information, including a human being, an electronic device, a computer program, or other entity. The subscriber 116 may have one or more presence states that may be relative to one or more endpoints 110. Table 1 shows examples of presence states and descriptions of the presence states.
The presence states shown in Table 1 may be applicable to an individual subscriber 116. The presence states may also be applicable to other entities, including aggregate entities such as workgroups, group mailboxes or group phone connections. For example, a presence state may reflect the availability of a group of customer service representatives in a complaint department. When no representative is available to handle the call, the associated presence state may be ‘On the Phone’. The presence information may reflect the availability of at least one member of the group, or may reflect other presence information applicable to the group as a whole.
For example, the ‘Be Right Back’ presence state indicates that the subscriber is in the office or otherwise available. However, the subscriber is temporarily away from the endpoint at which the subscriber receives messages. Different, fewer, or additional presence states may be used. As another example, the collection of presence states may simply be ‘Idle’, ‘Busy’, and ‘Away’.
Presence states may also reflect an aggregated media state. The aggregated media states may apply to specific typos of communication or may apply over any other subset of endpoints associated with the subscriber. As examples, the aggregated media states may apply to voice communications, instant messaging, and email messaging. Accordingly, a subscriber that is associated with multiple endpoints (e.g., phone numbers, email addresses, or instant messaging addresses) may have a presence state that aggregates availability over any subset of the endpoints. For example, a subscriber with a desk phone and a cell phone may have an aggregated media presence state of ‘Busy’ when at least one of the phones is in use. As another example, the subscriber may have an aggregated media presence state of ‘Available’ when both phones are not in use. Table 2 shows examples of aggregated media states. Different, fewer, or additional aggregated presence states may be used.
The endpoints 110 and/or subscribers 116 may communicate presence information to the presence information system 108. For example, the endpoints 110 may monitor subscriber activity and communicate a presence message to the presence information system 108. The presence message may indicate, as examples, that the subscriber has initiated a phone call, ended a phone call, started to type an instant message or email message, or may indicate any other presence information.
The presence state information may be communicated in the form of a presence document. The format of the presence document may adhere to any proposed or accepted standard for communicating presence information. In one implementation, the presence document is an extensible markup language (XML) document that identifies a subscriber and the presence or availability of the subscriber with respect to one or more ‘addresses’, including endpoints such as telephone numbers, email addresses, instant messaging addresses, or the like. When an endpoint publishes a presence document to the presence information system 108, the presence document typically only contains information about that particular endpoint. The presence information system 108 may then aggregate information from all of the subscriber's endpoints. The aggregate presence document may be made available in whole or in part to other endpoints that request the presence information.
The presence information system 108 receives the presence document. The systems 102-108 may process the presence documents and may maintain presence information for one or more subscribers. Alternatively or additionally, the messaging systems 102-106 may receive presence documents from the presence information system 108.
For example, the messaging system 102 may at any time poll or subscribe to the presence information system 108 for the current presence state of a subscriber. In response, the presence information system 108 may communicate a presence document for the subscriber to the messaging system 102. In such a case, the messaging system 102 acts as another endpoint with regard to receipt of presence information. The presence information system 108 need not send the presence document or populate the presence document with the requested information in every instance, however. Instead, the presence information system 108 may manage the availability of the subscriber presence state.
In
The presence responder 204 includes a processor 206 and a memory 208. The memory 208 includes contacts 210, 212, 214, 216, 218, and 220 organized into groups 222, 224, and 226. A contact may be any entity that the underlying infrastructure allows the subscriber to define and associate with a group. A contact may be another subscriber, a group, a program, a document, automated programs (e.g., bots), or another entity. The contacts generally represent entities interested in the subscriber's presence. In some cases, a contact group may include only contacts whose presence is also of interest to the subscriber (e.g., contacts in the subscriber's buddy lists). In other cases, the contact groups may include only contacts whose presence is not of interest to the subscriber.
In the example shown in
Additional contact groups may also be defined in the memory 208.
Furthermore, an administrator or other authorized entity may create additional contact groups in the presence system. For example, the presence system may create and populate a Management contact group. The additional contact groups may be visible or hidden from the subscriber, and may be editable or protected from editing by the subscriber.
Group access parameters guide the presence responder 204 with regard to contacts that are allowed access to subscriber presence information 228. Two examples are shown in
The access field to 230 is associated with the Friends group 222 and is set to allow access to subscriber presence information for the in the Friends group 222. The access field 232 is associated with the Project group 224 and is set to allow access to subscriber presence information for contacts in the Project group 224. The access field 234 is associated with the Unassigned group 226. The Unassigned group access field 234 or any other access field may be set by the presence system to a default value according to a predefined policy 236 established in the presence responder 204. In the example shown in
In the second example, the presence responder 204 maintains a group access/block list 238. The group access list 238 may be implemented as a list of groups containing contacts that are allowed access to the subscriber presence information. The group access list may additionally or alternatively include a list of groups containing contacts that are blocked from access to the subscriber presence information.
The presence responder 204 may also include access override parameters 240. The override parameters 240 may allow access or block access to presence information regardless of the group access parameter settings established by the subscriber. System policies 236 may establish the override parameters 240.
The memory 208 also includes an access determination program 242 and an automation program 244 As will be explained in more detail below, the access determination program 242 may include determination instructions 246 and check instructions 248. The determination instructions 246 may search the groups to ascertain to which contact groups a presence requester belongs. The check instructions 248 examine the access parameters to ascertain whether the presence requester is allowed access to subscriber presence information.
As will also be described in more detail below, the automation program 244 may automatically change group access parameters. For example the automation program 244 may process calendar entries 250 or availability rules 252 stored in the memory 208. When an availability rule 252 is applicable, or in response to a calendar entry 250, the automation program 244 may allow or block access to subscriber presence information.
From the subscriber's perspective, the Allow/Block line 312 divides the contact groups 222, 224, 226, and 306 between Blocked and Allowed. The contact groups 222 and 224 above the line are allowed access to the subscriber presence information. The contact groups 226 and 306 below the line are blocked from access to the subscriber presence information. The presence system may implement a user interface that allows the subscriber to graphically move contact groups above or below the Allow/Block line 312 and automatically update the group access parameters.
In
Also shown in
While the subscriber has set the access field 310 and/or the group Block list 316 to Block management contacts from obtaining presence information, the access override parameters 240 may apply regardless of the access field 310 or group Block list 316. Thus, in
As shown in
In the example shown in
Alternative or additionally, allow/block access may be based on any given portion of presence information. Conceptually, one or more subscriber and/or administrative Allow/Block lines specific to a given type of presence information may be placed across the contact groups. Accordingly, the access control illustrated in
On an individual basis, contact groups may then be allowed or blocked from access to portions of the presence information depending on the override and subscriber allow/block parameter settings. For example, subscriber availability presence information may be made available to selected groups, while the subscriber's email presence information may be blocked from selected groups, including those allowed access to the availability presence information. In other words, each group may be allowed access to some presence information or may be blocked from access to some presence information for any given subscriber.
It was noted above that the access determination program 242 processed presence information requests.
If the subscriber has allowed access to presence information for any group to which the requester is assigned (Act 706), the program 242 may then determine whether an access override parameter blocks access for that group (Act 708). If access is allowed, the program 242 may then determine an allowed portion or blocked portion of presence information available to the requester 202 (Act 710). The program 242 then sends the allowed portion of the presence information to the requester 202 (Act 712).
On the other hand if the subscriber has allowed access to the presence information but the access override parameters block access to the presence information, then that the program 242 may block the requester 202 (Act 714). To that end, the program 242 may respond with a ‘blocked’ response to the requester 202, may make no response to the requester 202 or may otherwise withhold the presence information.
The group access parameters may block access to the presence information (Act 706), but the override access parameters may allow access (Act 716). In this case, the program 242 may also determine an allowed portion or blocked portion of presence information (Act 710) and send the allowed portion to the requester 202 (Act 712). However, if the block is not overridden, the program 242 blocks the requester 202 (Act 714).
The program 242 and system policies 236 may establish any particular priority order for the access parameters. In one implementation, the program 242 checks first for override Blocks, then override Allows, then subscriber Blocks, then subscriber Allows. In other implementations, the program 242 may give priority to override Allows before override Blocks. Other priority orders are also possible.
System policies 236 may modify the acts taken by the access determination program 242. In one embodiment, the system policies 236 may distinguish between a restrictive mode and a permissive mode of access to presence information. For example, when the subscriber sets his mode to be restrictive, the program 242 may block access if any group that the requester belongs to has his access blocked instead of allowing access when any group that the requester belongs to has access allowed.
For example, when the calendar entry is ‘In Meeting’, the automation program 244 may set one or more of the group access parameters to block access to or allow access to the subscriber presence information for one or more groups specified in the calendar entry, by the system policies 236, or specified in other manners. The automation program 244 may change the access parameters for the duration of calendar entry (e.g., for the 2 hours the subscriber is in the meeting). After the event represented by the calendar entry, the automation program 244 may automatically change the access parameters back to their pre-event state. The automation program 244 may process any number of calendar entries in this manner (Act 808).
The automation program 244 may also process subscriber rules 252. In doing so, the automation program 244 reads the presence availability rules 252 (Act 810) on a periodic, scheduled, commanded, or other basis. If the rule fires (Act 812), then in the automation program 244 a set one or more of the group access parameters to block access to or allow access to the subscriber presence information (Act 814). For example, the subscriber may define the following rule: ‘If I am editing Critical_code.doc, then block my presence information.’ The automation program 244 may process any number of rules (Act 816).
The presence management system described above may be implemented as a presence management layer to an underlying native presence infrastructure. The native presence infrastructure may be the Microsoft Presence Agent Server (PAS). The presence management layer may be implemented on top of the native presence infrastructure even if the native infrastructure is not open to modification or replacement. In such cases, allow/block decisions are available to subscribers that employ the presence management system interface for presence information.
For example, the Microsoft PAS may maintain the contacts, the contact group definitions, and the subscriber Allow/Block list on the basis of individual contacts. The presence management layer may then overlay the Microsoft PAS. To that end, the presence management layer may maintain in a database contact groups parallel to that established in Microsoft PAS as well as additional information such as group access lists 238, override access parameters 240, rules 252, and any other data.
When a new contact group is created in Windows Messenger or the Live Communications Client, the presence management layer may create an entry for this group and place this group below the subscriber's Allow/Block line. Similarly, when a contact group is deleted in Windows Messenger, the presence management layer will delete the corresponding contact group entry. When a contact is added to or deleted from a contact group in Windows Messenger, the presence management layer will add or delete the contact to or from the corresponding parallel contact group maintained by the presence management layer. A new contact, unassigned to any group in Windows Messenger, may be assigned to the Unassigned Contact Group 226 in the presence management layer.
Changes made in Windows Messenger to Allow/Block settings for individual contacts may be checked against the parallel groups maintained in by the presence management layer. The presence management layer updates the parallel groups to be consistent with the changes made to the individual contacts. The subscriber may change the Allow/Block setting for the parallel groups. The presence management layer may then update the Windows Messenger Allow/Block lists to be consistent with the subscriber's changes.
The subscriber may add a contact using the presence management layer. The presence management layer may then add the contact to the Windows Messenger/Live Communications Client underlying roaming contact group and add the contact to the underlying roaming Allow/Block list. When a contact is deleted using the presence management layer, the presence management layer may remove contact to the Windows Messenger/Live Communications Client underlying roaming contact group and remove the contact from the underlying roaming Allow/Block list. Similarly, when a new user contact group is added or deleted using the presence management layer, the contact group will also be added to (or deleted from) the underlying set of Windows Messenger/Live Communications Client contact groups. Furthermore, subscriber changes to the Allow/Block line are reproduced in the underlying Allow/Block list on a contact-by-contact basis.
Performing presence information availability at a group level may reduce the time and mistakes made managing contacts on an individual basis. The management is less cumbersome and also allows for automated adjustment to the availability of presence information. Furthermore administrator or other authorized entity may overlay mandatory presence availability policies on top of those set by the subscriber to ensure that critical groups have access to the presence information they need, or that unnecessary groups do not have access.
It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.
