Patent Application
20160308685
The present disclosure is generally directed to presence indicators for subscribers to an electronic communication system.
Users of presence services, such as Avaya Aura™ Presence Services, receive updates based on a “buddy list” setup by the user to receive presence information for a set of other users of the system (“buddies”). A user subscribes to other users for updates and shared knowledge about the users. Once the buddy list is defined, the presence server and endpoints can share information.
Buddy lists tend to be resource intensive as each user notifies each subscriber of their change in availability, even if few or no subscribers are currently interested in the user's current status. Buddy lists also tend to grow over time. A user may be on a project with one group where having presence information is useful for a period of time. However, even if the project ends, few users will unsubscribe the users of the group. As a result, a user's endpoint may receive a substantial volume of presence notifications, even if few are of current interest.
It is with respect to the above issues and other problems that the embodiments presented herein were contemplated. In one embodiment, a dynamic presence resource list mechanism is provided that allows a user to remove and add presence subscriptions dynamically for a set amount of time and which is managed automatically by a server. Once the time lapses, the subscribed users are unsubscribed. The presence server may carry the subscribe/unsubscribe deltas and may more readily facilitate a re-subscribe to one of the unsubscribed users. In other embodiments, events may use need-based triggers to cause the subscription of presence information. When the need no longer exists, the presence information may be unsubscribed.
In another embodiment, a user may want presence information for people who are not on their buddy list. The presence server can allow the user to request presence for non-buddy list users. For example, in systems that provide presence for users on an email distribution list, the user can see presence information for some or all of those users (e.g., sender, other recipients, and/or “cc” recipients), even for those users who are not on the buddy list. In a further embodiment, the presence information for non-buddy list users may be limited by time. For example, presence for parties associated with an email may be useful for a limited timeframe, (e.g., follow-up questions, schedule a meeting, correct an error, etc.), however, the steps of adding such users to a buddy list (e.g., formulating a request, sending the request, the recipient seeing the request, the recipient acting on the request, the server updating the buddy list, etc.) may be difficult for the user to justify. As a benefit, users may find it helpful to have and manage contacts on the buddy list (static relationship) as well as to have context-based presence displayed (ad hoc relationship) dynamically.
In one embodiment, the initial subscription request carries the initial resource list in a message body. The initial resource list may be modified, such as by a subscription refresh request comprising a list of additions and deletions.
For each entry in the resource list, a subscribing application can specify appropriate treatment of the request according to the access control policy, which applies to a specific entry: (1) if the policy is CONFIRM, which may trigger a presence watching authorization request—this is more appropriate for longer-term watching, or (2) the CONFIRM policy may be processed in a manner equivalent to that of a BLOCK policy for such ad hoc relationships. Requests that are blocked may omit notification to the receiving and/or providing user, such as when the providing user is subject to a default personal, corporate, or other entity's BLOCK policy.
As a benefit, a user or group of users (e.g., department, position, company, enterprise, etc.) may maintain privacy according to a default policy in order to manage privacy concerns. User's may still issue a request to subscribe to a user's presence via an explicit request, which may then explicitly notify the user of the acceptance/refusal response.
Reducing the number of “transactions” between the endpoint and the presence server related to managing the dynamic list by:
1. Allowing one or more presence data, including specific presence datum for the one or more users providing the presence data, to be added/removed from the list by a single “transaction” between the endpoint and the presence server; and/or
2. Allowing specifying the “privacy handling instructions” per individual basis.
In one embodiment, a system is disclosed, comprising: a presence server; an input interface of the presence server configured to receive a triggering event from a triggering device; wherein the triggering device notifies the presence server, via the input interface, of a triggering event associating the first user with the second user; wherein the presence server, in response to the triggering event, automatically and without human intervention, in response to the triggering event, subscribes the first user to presence data for the second user; and an output interface of the presence server configured to provide presence information of the second user to a first endpoint associated with the first user while the first user is subscribed to the presence data of the second user.
In another embodiment, a method is disclosed, comprising: receiving a triggering event from a triggering device indicating an association between a first user and a second user; in response to the triggering event, automatically and without human intervention, subscribing the first user to presence data for the second user; receiving presence data of the second user from a second endpoint associated with the second user; and determining the first user is presently subscribed to the presence data of the second user, and in response to the determining, outputting the presence data of the second user to a first endpoint associated with the first user.
In another embodiment, a non-transitory computer-readable medium is disclosed that when read by a computer causes the computer to perform: receiving a triggering event from a triggering device indicating an association between a first user and a second user; in response to the triggering event, automatically and without human intervention, subscribing the first user to presence data for the second user; receiving presence data of the second user from a second endpoint associated with the second user; and determining the first user is presently subscribed to the presence data of the second user, and in response to the determining, outputting the presence data of the second user to a first endpoint associated with the first user.
The phrases “at least one,” “one or more,” and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C,” “at least one of A, B, or C,” “one or more of A, B, and C,” “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.
The term “a” or “an” entity refers to one or more of that entity. As such, the terms “a” (or “an”), “one or more” and “at least one” can be used interchangeably herein. It is also to be noted that the terms “comprising,” “including,” and “having” can be used interchangeably.
The term “automatic” and variations thereof, as used herein, refers to any process or operation done without material human input when the process or operation is performed. However, a process or operation can be automatic, even though performance of the process or operation uses material or immaterial human input, if the input is received before performance of the process or operation. Human input is deemed to be material if such input influences how the process or operation will be performed. Human input that consents to the performance of the process or operation is not deemed to be “material.”
The term “computer-readable medium,” as used herein, refers to any tangible storage that participates in providing instructions to a processor for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, NVRAM, or magnetic or optical disks. Volatile media includes dynamic memory, such as main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, magneto-optical medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, a solid-state medium like a memory card, any other memory chip or cartridge, or any other medium from which a computer can read. When the computer-readable media is configured as a database, it is to be understood that the database may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Accordingly, the disclosure is considered to include a tangible storage medium and prior art-recognized equivalents and successor media, in which the software implementations of the presence disclosure are stored.
The terms “determine,” “calculate,” and “compute,” and variations thereof, as used herein, are used interchangeably and include any type of methodology, process, mathematical operation or technique.
The term “module,” as used herein, refers to any known or later-developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing the functionality associated with that element. Also, while the disclosure is described in terms of exemplary embodiments, it should be appreciated that other aspects of the disclosure can be separately claimed.
The presence disclosure is described in conjunction with the appended figures:
The ensuing description provides embodiments only and is not intended to limit the scope, applicability, or configuration of the claims. Rather, the ensuing description will provide those skilled in the art with an enabling description for implementing the embodiments. It will be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the appended claims.
Any reference in the description comprising an element number, without a subelement identifier when a subelement identifier exists in the figures, when used in the plural, is intended to reference any two or more elements with a like element number. When such a reference is made in the singular form, it is intended to reference one of the elements with the like element number without limitation to a specific one of the elements. Any explicit usage herein to the contrary or providing further qualification or identification shall take precedence.
The exemplary systems and methods of this disclosure will also be described in relation to analysis software, modules, and associated analysis hardware. However, to avoid unnecessarily obscuring the presence disclosure, the following description omits well-known structures, components, and devices that may be shown in block diagram form, and are well known, or are otherwise summarized.
For purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present disclosure. It should be appreciated, however, that the present disclosure may be practiced in a variety of ways beyond the specific details set forth herein.
In another embodiment, presence server 112 manages presence information, such as for presentation by and/or receiving presence inputs from, first endpoint 106, second endpoint 108, and/or other in endpoints utilizing network 110. Associating server 114 provides one source of associations between second user 104 and/or first user 102. Associating server 114 may provide one or more other services to first user 102 and/or second user 104, such as email, telephony, video, and/or text as well as other services such as may be provided in a particular business environment, such as management, document processing, scheduling, artistic and creative, science and engineering, accounting and financial, human resources, and/or other business or project services. In a further embodiment, associating server 114 may be physically and/or logically local to a particular enterprise, off-site (e.g., cloud, software as a service, etc.), or a combination thereof.
Network 110 may be entirely within the confines of a particular physical structure, such as one building or a portion of the building, or span multiple physical locations. Network 110 may comprise portions of public networks (e.g., Internet), private networks (e.g., PBX, WAN, LAN, WLAN, etc.) and/or other communications networks operable to convey presence data gathered from one endpoint (e.g., second endpoint 108) and provide the presence data to another endpoint (e.g., first endpoint 106).
Network 110 may comprise two or more endpoints, such as endpoints 106, 108, with the endpoints being variously embodied. In one embodiment, one or both of first endpoint 106 and/or second endpoint 108 may be or comprise a digital telephone, a computer, portable device (e.g., cell phone, smart phone, laptop, personal data assistant, tablet, smart watch, etc.), or other device operable to facilitate communication and/or the exchange of presence data between at least first user 102 and second user 104 via network 110.
Presence server 112 and associating server 114 may be distinct physical and/or logical devices. In another embodiment presence server 112 and associating server 114 are a single physical and/or logical device. Presence server 112 and associating server 114 may communicate directly or via network 110. Presence server 112 may also comprise or access an electronic data storage, such as to maintain user preferences for receiving and/or reporting presence information, default settings for an organization, a department, a group of individuals, and/or a specific individual. Presence server 112 may also maintain historical records of presence events, providing subscribing and unsubscribing services, and/or other management services.
In one embodiment, first user 102 is interacting with second user 104. Associating server 114 determines whether an association between first user 102 and second user 104 has been created. For example second user 104 may send first user 102 an email utilizing associating server 114 when configured as an email server. Accordingly presence server 112 is notified of the triggering event causing an association to be created between first user 102 and second user 104. Presence server 112 then subscribes first user 102 second user 104's presence, which may then be displayed on first endpoint 106. In another embodiment, the presence information for first user 102 is subscribed to by second user 104. The nature of the subscription may be determined by default settings provided by the users themselves and/or an enterprise, department, and/or other grouping of users providing default settings for users.
The automatic subscription request and the acceptance or blocking thereof is provided based upon an appropriate default setting and without human interaction. As is performed in the prior art systems, a user may issue a request to subscribe to presence information for another user, for example, to add a user to a “buddy list.” The subject of such a subscription request to be added to a “buddy list” may accept or decline, based upon default rules or be presented with the request to manually accept or decline. However, these prior art systems require human initiation, often a human response, and the presentation back to the initiator as to the acceptance or rejection.
In one embodiment, the request is automatically generated based upon another action unrelated to creating a subscription to the presence information, such as sending or receiving an email, and by automatically granting or denying the request: human interaction with the system is not required. If a request defaults to CONFIRM or BLOCK, the request and the response may be unknown to first user 102 and/or second user 104. For example, ACCEPT allows for the creation of a subscription; but, as CONFIRM requires human interaction, such a default policy may be considered as BLOCK for automatically generated subscription requests provided by certain embodiments herein.
In another embodiment, the subscription process may be for an additional subscription datum. For example, second user 104 may send subscribing user 102 an email. Associating server 114, such as when associating server 114 is an email server, may present the email as a triggering event to presence server 112. Presence server 112 may then attempt to create a subscription for the presence of one or both of first user 102 and second user 104 for the other. However, a certain presence datum, such as AVAILABLE/BUSY, may already be provided. Subscription information based upon the triggering event may add additional presence datum to the subscription, such as “in a meeting,” “out of the office,” “do not disturb,” etc.
In another embodiment, the subscription resulting from the triggering event is time-limited. The specific time may be determined as a matter of design choice. The duration of time may be a default value for all automatic subscriptions. However, in another embodiment, the specific triggering event determines the duration of the subscription. For example, second user 104 may send an email via server 114 to first user 102 and cause presence server 112 to create a subscription for one length of time, such as a week or two. However, if that same email was sent to every employee in a large organization including first user 102, then the relationship may be considered less personal and may result in a triggering event whereby presence server 112 creates the subscription for a shorter length of time, such as a few hours or a few days. As a further option, certain events may not be considered triggering events. A large organization receiving an email to all employees from the organization's CEO may be excluded as a triggering event. Other events, such as a scheduled meeting, may result in a subscription for a number of days or weeks following the meeting. As a further option, certain meetings may result in a subscription that is initiated upon a delay. For example, second user 104 may be a human resources officer who has little interaction with first user 102 except for an annual performance review of first user 102. First user 102 may schedule a meeting to discuss the annual review months in advance. However, presence information may be unwarranted until the scheduled meeting is a few days or weeks prior, such as to manage any developing scheduling conflicts, discuss any information that should be brought to the meeting, etc. Optionally, the presence information may be continued for a period of time, such as a few days or weeks following the meeting, such as to facilitate any follow-up discussions.
In one embodiment, presence information may be granted for any user on a system. However, in order to avoid unnecessary data traffic caused by presence information, presence information is not provided except when indicia thereof is operable to being observed, such as by display 202 of first endpoint 106 displaying certain users. First user 102's scrolling display 202 may cause presence server 112 to subscribe first user 102 to the subscription information for one or more other users as their indicia is made available on display 202. As a result, users whose presence is displayed on display 202 are subscribed for presentation by first endpoint 106. In another embodiment, the duration of the subscription may be limited to a particular user's indicia no longer being presented on display 202, such as being beyond a certain level of display (e.g., five pages below the current page of user indicia, ten pages above the current page of user indicia, etc.), or the occurrence of another event, such as first user 102 performing an operation (e.g., placing a call, closing the user directory, etc.) on first endpoint 106 indicating no additional user presence information is desired.
In another embodiment, step 304 may provide additional information, such as a particular presence datum not provided under step 308, such as “do not disturb” as opposed to “unavailable,” in which case processing may continue to step 306 to add the additional presence datum to the subscription. Step 306 causes a subscription request to be issued on behalf of the subscribing user to receive presence information for the subscribed user, such as first user 102 requesting presence information for second user 104. However, it should be noted that step 306 is an automated process done on behalf of first user 102. Next, step 310 determines if there is an entity default. The entity may be a business organization, a default based on position (e.g., executives, those with access to sensitive data, etc.), department, and/or other grouping of individuals. If step 310 determines the entity default is to ACCEPT request for subscription information, processing may continue to user default step 312 whereby the particular individual, whose presence information is desired, may then have the appropriate default rule applied. If step 310 and/or step 312 have a default to CONFIRM or BLOCK, such subscription request process 300 may end. Optionally, the user may have an explicit request to the user to add the user to a buddy list. However, if steps 310 and 312 have ACCEPT as a default position, processing may continue to steps 314 and optionally step 316.
Steps 314 and 316 are shown as discrete process steps executed in parallel. However, in other embodiments, steps 314 and 316 may be executed serially or as one combined step. Step 314 subscribes the user to the presence information for the other user. Step 316 starts a timer, sets a timestamp, or other appropriate indicator of start time, duration, and/or end time so that the subscription initiated in step 314 may terminate at the appropriate time. Step 318 then determines if the threshold time has been met and, if yes, step 320 unsubscribes the user from the presence information and, if no, step 318 may loop until determined in the affirmative.
Upon step 320 executing, the subscription or additional subscription datum that was subscribed in step 314 is unsubscribed for the user. Optionally, some subscription data may be maintained, such as by defaulting to a corporate or other default policy and/or a buddy list policy provided in optional step 308. During the time between step 314 and step 320 executing, the presence information subscribed to is active and the presence information of the subscribed user (e.g., second user 104) is made available to a subscribing user (e.g., presenting subscription information to first user 102 on first endpoint 106).
In another embodiment, process 300 may encounter another event 302 prior to the execution of step 320 and after step 314. In such an embodiment, step 316 may be re-executed to reset the time or otherwise extend the time. In another embodiment, if the subsequent event 302 has a shorter duration than a prior event 302, the shorter duration event may be ignored or added to the total subscription time as a matter of design choice. In a further embodiment, two events 302 may have an associated time set in step 316 and may be combined by simple addition or other factor as a matter of design choice. For example, a subscription lasting one week followed by a second event also associated with a subscription lasting one week may, when combined, result in a subscription of three weeks.
In one embodiment, process 400 executes step 402 wherein a user is added to a group. Next, block 404 submits a subscription request on behalf of at least one other member of the group or other interested party of the group. As described with respect to
In another embodiment, step 412 determines if the subscribed user has been removed from the group. If no, step 412 may be reconsidered at a later time or upon an event, such as an indication that the user is no longer a member of the group. If step 412 is answered in the affirmative, step 320 then unsubscribes from the user's presence information that was subscribed in step 314.
In another embodiment, step 506 may determine if the user's indicia is still displayed. If determined in the affirmative, process 500 may be suspended or loop back to step 506. If step 506 is determined in the negative, process 500 may proceed to optional steps 508, 510 and directly to step 320 to unsubscribe. In another embodiment, step 508 is executed to provide a delay, such as to prevent unnecessary subscribing/unsubscribing when a user is performing actions quickly (e.g., scrolling up and down a list of indicia on display 202). Step 510 may optionally be executed to determine if the indicia for the user has been re-displayed. Such as when a user has returned to the user. If no, step 320 may be executed to unsubscribe the user. IF yes, step 506 may be re-executed to determine continue the process and otherwise delay the execution of step 320.
In the foregoing description, for the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods may be performed in a different order than that described. It should also be appreciated that the methods described above may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general-purpose or special-purpose processor (GPU or CPU), or logic circuits programmed with the instructions to perform the methods (FPGA). These machine-executable instructions may be stored on one or more machine-readable mediums, such as CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable mediums suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.
Specific details were given in the description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Also, it is noted that the embodiments were described as a process, which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium, such as a storage medium. A processor(s) may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
While illustrative embodiments of the disclosure have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.
