Browse Prior Art Database

Consolidation of information from heterogeneous status tracking systems

IP.com Disclosure Number: IPCOM000202311D
Publication Date: 2010-Dec-13
Document File: 2 page(s) / 48K

Publishing Venue

The IP.com Prior Art Database

Abstract

Consolidation of information from heterogeneous status tracking systems

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 2

Consolidation of information from heterogeneous status tracking systems

At present, there is a large, and growing, number of systems which give some sort of an indication of a user's status. For example, we have Instant Messaging (IM) presence, including location and activity, out of office messages, voicemail greetings, calendar entries, vacation planner entries and so on. At various levels of granularity, these systems all expose aspects of the more general user status. For a user to update all these systems and keep them in sync is a tiresome and inconvenient task. Often different and conflicting information is given out by some or all of the systems which might be interrogated to get information about the status of a user.

    Known solutions to this problem focus on quite a narrow domain, and are often ad hoc. For example, booking vacation may give the user the option to update their personal calendar. However, there is no mechanism which addresses the more general issue of tying together all these status systems so that a user only has to make the update through one central interface, after which all the status front ends presented to other users will reflect this update.

    Instead of each end-user application implementing its own status tracking system, a central status server will be established, that end user systems can subscribe to. When status changes occur, the listening end-user applications will be notified and can take appropriate action. This information will be supplied at various levels of granularity, so that applications can choose to ignore the background noise if they so wish - out of office notes should not be sent when a user goes to get a coffee, for example. The user will be able to configure any number of applications to receive updates from the status server. The system involves the abstraction of a user status away from end-user applications and into a dedicated server which draws information from a number of configured sources, makes inferences based on input events and internal state and outputs sanitised and enriched status data.

  There are three immediate benefits to using a centralised server approach: The status server can infer richer user status information from a number of

1.

sources than the individual applications can in isolation. At present, we settle for terse status messages from each of the applications, mainly because updating each one is a chore. If a status server is used, all applications can benefit from the centralised data. For example, IM clients might present "in a meeting in room D213 until 4pm" rather than simply "Away".

A more reliable indication of the user's status can be inferred due to the larger

2.

amount of data available. If each system operates in isolation, they can only consider the limited data available in whatever domain they're working in. By having a cross-domain server tracking changes from a number of data sources, status updates can be rationalised and cross-ref...