WO2014125332A1

WO2014125332A1 - Capturing activities performed in a presence access layer (pal)

Info

Publication number: WO2014125332A1
Application number: PCT/IB2013/051211
Authority: WO
Inventors: Brian Edward Anthony Mccolgan; Zoltán ÖRDÖGH
Original assignee: Blackberry Limited
Priority date: 2013-02-14
Filing date: 2013-02-14
Publication date: 2014-08-21

Abstract

A presence context (62,64,66) is established in a presence access layer 'PAL' (43) coupled to a presence server (22). An activity log (72,74,76,320,340) is associated with the presence context. Entries (326,346) are created in the activity log, each entry identifying, chronicling, and documenting an activity applicable to the presence context that was performed in the presence access layer.

Description

Capturing activities performed in a presence access layer (PAL) TECHNICAL FIELD

[0001] The present disclosure relates to recordation of operations in a presence environment.

BACKGROUND

[0002] A presence access layer (PAL) provides presence aware applications and/or services with simplified interfaces such that core service functionality that relies on presence functions may be fulfilled. A presence context has associated therewith presence aspects that are exposed to the presence aware applications and/or services. The presence aspects are evaluated by the presence access layer in keeping with the presence context.

SUMMARY

[0003] This disclosure proposes associating an activity log with a presence context that was established in a presence access layer (PAL) coupled to a presence server, and creating entries in the activity log, each entry identifying, chronicling, and documenting an activity applicable to the presence context that was performed in the presence access layer. The entry chronicles the activity in that it includes an indication (for example a timestamp) of when the activity was performed. The entry documents the activity in that it provides information from which the activity or results of the performance of the activity can be recreated.

[0004] The introduction of the activity log may enhance the presence access layer in various ways. An activity log tracks the history of a presence context through time or a specific time period. An activity log enables processing of a presence context by a PAL client to be deferred and then resumed. An activity log enables processing of a presence context by a PAL client to be replayed, thus generating metadata for a specific timeframe. Metadata for a specific timeframe can also be generated by replaying interface operations tracked in multiple records at a PAL client. An activity log enables decoupling of PAL servers and PAL clients. Presence contexts can be logically joined, combined, or pipelined. Statistical analysis and data mining can be performed on the contents of one or more activity logs, thus generating useful information. BRIEF DESCRIPTION OF DRAWINGS

[0005] FIG. 1 is an illustration of an example presence environment having a presence access layer (PAL);

[0006] FIG. 2 is an entity relationship diagram illustrating the relationship between the descriptors of a presence context;

[0007] FIG. 3-1 and FIG. 3-2 jointly illustrate a concrete example presence environment having a PAL;

[0008] FIG. 4 is an illustration of a record at a PAL client;

[0009] FIG. 5-1 is an illustration of a activity log associated with a presence context;

[0010] FIG. 5-2 is an illustration of an alternate activity log associated with a presence context;

[0011] FIG. 6 is a simplified flowchart of an example method performed by a PAL server, for establishing a presence context and recording activities;

[0012] FIG. 7 is a simplified flowchart illustration of a method for generating metadata;

[0013] FIG. 8 is a simplified flowchart illustration of a method for tracking operations applicable to a presence context; and

[0014] FIG. 9 is a variant of what is illustrated in FIG. 3-2;

[0015] FIG. 10 is a simplified flowchart illustration of a method for transferring a presence context from one PAL client to another PAL client; and

[0016] FIG. 11 and FIG. 12 are variants of what is illustrated in FIG. 3-2. DETAILED DESCRIPTION

[0017] FIG. 1 is an illustration of an example presence environment. A presentity is an entity whose state can change. In the case of a human, the state may include, for example, the human's alertness, the human's mood, the location of the human, etc. In the case of a group of employees, the state may include, for example, the group's productivity, the group's cohesiveness, etc. In the case of a non-human presentity such as a software bug, the state may include the status of the software bug. In the case where the state relates to multiple presentities, the multiple presentities are a single presence source. In the case where the state relates to a single entity, the presentity is itself a presence source. For example, a presentity 2 is a presence source 4, and presentities 6 and 7 are a presence source 8.

[0018] A presence-aware application generates or reflects presence information for a presence source. For example, presence-aware applications 10 and 12 on an apparatus 14 generate or reflect presence information for the presence source 4, and a presence-aware application 16 on an apparatus 18 generates or reflects presence information for the presence source 8. In general, presence information is information that relates to the state of the presence source. For example, if alertness can be expressed as {asleep, drowsy, unfocused, alert, vigilant} , the presence information may specify the alertness experienced by the human at a particular time. In another example, the cohesiveness of group of employees may be assessed on a scale of 1 to 5, and the presence information is the assessed cohesiveness at a particular time. In another example, the status of a software bug may be expressed as {reported, assigned, problem identified, problem resolved} the presence information is the status of the software bug at a particular time.

[0019] A presence user agent is an application that publishes presence information generated or reflected by a presence-aware application over a network to a presence server. The presence-aware application and the presence user agent may be on an apparatus such as a smartphone, a personal computer, a tablet computer, a slate computer, a laptop computer, a server computer, or any other apparatus able to execute the presence-aware application and the presence user agent. For example, a presence user agent 20 is an application on the apparatus 14 that publishes presence information over a network (not shown) to a presence server 22, and a presence user agent 24 is an application on the apparatus 18 that publishes presence information over a network (not shown) to the presence server 22. The presence information published by the presence user agent 20 (as illustrated by an arrow 26) is generated or reflected by the presence-aware applications 10 and 12, and the presence information published by the presence user agent 24 (as illustrated by an arrow 28) is generated or reflected solely by the presence-aware application 16. In the example illustrated in FIG. 1, the presence-aware application 16 comprises the presence user agent 24, however in other instances the presence user agent 24 and the presence-aware application 16 could be separate applications that communicate therebetween.

[0020] A presence user agent may store or encode the presence information in any format. Presence information is published in a format compatible with the presence server. For example, the published presence information may be included in one or more documents compliant with a presence information data format (PIDF), for example, the PIDF defined in Request for Comments (RFC) 3863 and extended in RFC4480, and publication may involve transmission of the one or more formatted documents from the presence user agent to the presence server.

[0021] A presence server shares presence information to authorized entities, referred to as watchers, or rather, to watcher applications or watcher services acting on behalf of the watchers. Watcher applications and services are applications and services that consume or otherwise make use of presence information, generally to fulfill another function, capability or goal. For example, a watcher 30 may be authorized by the presence server 22 for a watcher service 32 on an apparatus 34 to consume or otherwise make use of presence information relating to the presence source 4, and a watcher 36 may be authorized by the presence server 22 for watcher applications 38 and 40 on an apparatus 42 to consume or otherwise make use of presence information relating to the presence sources 4 and 8. As will be evident from examples provided in this document, a presence-consuming application or service may also be a presence-aware application that generates or reflects presence information for a presence source.

[0022] The presence environment includes a presence access layer that simplifies the consumption of presence information by the watchers. In the example illustrated in FIG. 1, a presence access layer (PAL) 43 is implemented with a client-server architecture. For example, as illustrated by an arrow 45, a PAL server (PAL-S) 44 communicates over a network (not shown) with a PAL client (PAL-C) 46 on the apparatus 34, and, as illustrated by an arrow 47, communicates over a network (not shown) with a PAL client 48 on an apparatus 50. In the example illustrated in FIG. 1, the PAL-S 44 is a separate network component than the presence server 22 and the PAL server 44 and the presence server 22 communicate therebetween over a network (not shown), however in other instances the presence server 22 could comprise or otherwise be co-located with the PAL server 44. In the example illustrated in FIG. 1, the watcher server 32 comprises the PAL client 46, however in other instances the PAL client 46 and the watcher service 32 could be separate applications that communicate therebetween. In the example illustrated in FIG. 1, the PAL client 48 is on a different apparatus than the watcher applications 38 and 40, and the apparatuses 42 and 50 communicate therebetween over a network (not shown). However in other instances the PAL client 48 could be on the apparatus 42. The PAL server 44 or any network component that it is on or comprised in or otherwise co-located with is operable to perform the methods described in this disclosure as being performed by a PAL server, and comprises means for performing those methods. For example, a PAL server may be implementable, at least partially, as executable software or firmware that is executed by one or more processors (not shown) of the network component. The apparatuses 42 and 50 are operable to perform the methods described in this disclosure as being performed by a PAL client, and comprise means for performing those methods. For example, a PAL client may be implemented, at least partially, as executable software or firmware that is executed by processors (not shown) of the apparatuses 42 and 50.

[0023] Rather than the watcher 30 subscribing directly to the presence server 22 so that presence information for specified presence sources is sent to the watcher service 32, the PAL server 44 subscribes on behalf of the watcher 30, as illustrated by an arrow 52. Rather than the watcher 36 subscribing directly to the presence server 22 so that presence information for specified presence sources is sent to the watcher application 38, the PAL server 44 subscribes on behalf of the watcher 36, as illustrated by an arrow 54. Rather than the watcher 36 subscribing directly to the presence server 22 so that presence information for specified presence sources is sent to the watcher application 40, the PAL server 44 subscribes on behalf of the watcher 36, as illustrated by an arrow 56. The presence information for all subscriptions made by the PAL server 44 is shared with the PAL server 44 by the presence server 22, as illustrated by an arrow 58.

[0024] A presence server may store or encode presence information to be shared in one or more formatted documents. Sharing of the presence information with a PAL server may involve transmission of the one or more formatted documents from the presence server to the PAL server. A PAL server may store or encode subscription information in one or more formatted documents. Subscription by a PAL server may involve transmission of the one or more formatted documents from the PAL server to the presence server.

[0025] Context is that which surrounds, and gives meaning to, something else. Presence information is processed by the PAL server in accordance with a presence context established at the request of a PAL client on behalf of a presence-consuming service or application. A presence context determines i) which presence information is relevant to a presence- consuming service or application, ii) how that presence information, once shared by the presence server, is parsed and interpreted by the PAL server, and iii) how a consolidated view of the relevant presence information is provided by the PAL server to the PAL client for consumption by that presence-consuming service or application. For example, a presence context 62 is established by the PAL server 44 at the request of the PAL client 46 to provide a framework for the consumption of presence information by the watcher service 32, a presence context 64 is established by the PAL server 44 at the request of the PAL client 48 to provide a framework for the consumption of presence information by the watcher application 38, and a presence context 66 is established by the PAL server 44 at the request of the PAL client 48 to provide a framework for the consumption of presence information by the watcher application 40.

[0026] A presence access layer has previously been proposed for use in conjunction with an Open Mobile Alliance (OMA) Presence/SIMPLE type environment. (SIMPLE is the acronym "SIP (Session Initiation Protocol) for Instant Messaging and Presence Leveraging Extensions".) In those proposals, a presence context has been described in terms of presence aspects, policies, rules and triggers. FIG. 2 is an entity relationship diagram illustrating the relationship between the descriptors of a presence context 90. [0027] A presence aspect 92 is a logical abstraction relating to one or more underlying presence information elements corresponding to a given presentity. Some example presence aspects are illustrated in the following table:

Table 1

[0028] Rules 94 establish a sequence of steps or logic flows required to compute presence aspects based on the metadata provided by the underlying presence platform. A policy specifies the behaviour or treatment of presence aspects. Policies 96 augment rules/logic flows in terms of how they operate, to provide a more accurate and meaningful computation of aspects on behalf of a watcher application or service, for example, when there may be an indeterminate result due to missing or incorrect presence information. Triggers 98 associate a sequence of steps or logic flows based on an underlying presence state change detected in the presence platform. Triggers are, by default, initially notifications, for example, push delivery notifications or asynchronous notifications.

[0029] Thus a presence server will share with a PAL server presence information according to the subscriptions made by the PAL server, and the PAL server will parse and interpret the presence information according to the policies and rules associated with the presence contexts that have been established, thus computing values for the presence aspects associated with a given presence context. Presence aspects are exposed to PAL clients by the PAL server via an interface. In general, the presence aspects themselves will determine what policies and rules are applied. However, different PAL clients for which different contexts have been established may see different presence aspects with different values, computed from the same underlying presence information, due to differences in the policies and rules associated with the different presence contexts.

[0030] An example established presence context, stored by the PAL server and returned as a formatted document to a PAL client, is as follows:

<?xml version="l .0" encoding="UTF-8" standalone="yes " ?>

<pal-message xmlns="urn : oma : xml : prs : pal : payloads : 1.0 "

xmlns : ns2="urn : oma : xml : xdm : pal-profile : 1.0 ">

<pal-response>

<pres-context version=" 1.0 "

presence-context-id="pttchat@localhost/ {aliceOlocalhost}/ 00001 "> <aspects>

<ns2 : aspect id="oma :prs :pal : aspect : optin" name="aspect0ptln"> <ns2 : alue-type>ns2 : optIn</ns2 : alue-type>

<ns2 :pa-rule-ref>oma:prs :pal :rules :hasOptedInForService</ns2 :pa- rule-ref>

</ns2 : aspect>

</aspects>

</pres-context>

</pal-response>

</pal-message>

[0031] This example presence context exposes the presence aspect opt-in. The rules (e.g. hasOptedlnForService) define how the PAL server will actually navigate the presence information to evaluate the presence aspect opt-in.

[0032] A PAL client may initiate suspension of a presence context, by sending an appropriate message to the PAL server that is currently processing the presence context. The PAL client may initiate resumption of a suspended presence context, by sending an appropriate message to the PAL server to resume the presence context. While the presence context is suspended, the PAL server does not provide presence information for that presence context to the PAL client. Suspension of a presence context requires connectivity between the PAL client and the PAL server. Resumption of a suspended presence context requires connectivity between the PAL client and the PAL server.

[0033] A PAL client may initiate termination of a presence context, by sending an appropriate message to the PAL server that is currently processing the presence context. A terminated presence context cannot be revived. A PAL server will not process requests received from a PAL client in connection with a terminated presence context. A presence context that has been established and not terminated is referred to in this disclosure as an active presence context. [0034] A more concrete example presence environment is illustrated jointly in FIG. 3-1 and FIG. 3-2, helpful in understanding the concepts described above with respect to FIG. 1. The generation or reflection of presence information for presence sources and the publication of that presence information to a presence server is illustrated in FIG. 3-1. Subscriptions to a presence server on behalf of presence-consuming services and applications, sharing of presence information to a PAL server, processing of the presence information by the PAL server according to an established presence context based on PAL rules (associated with the presence context), and providing the consolidated view of the presence information by the PAL server to the PAL client in the form of presence aspects, is illustrated in FIG. 3-2.

[0035] As illustrated in FIG. 3-2, the core of the example presence environment is a presence server 102, which is an example of the presence server 22, PAL servers 104 and 106, which are examples of the PAL server 44, and PAL clients 108, 110, 112, 114, 115, 116, and 118, which are examples of the PAL clients 46 and 48.

[0036] As illustrated in FIG. 3-1, the presentities involved in the example presence environment include human presentities Alice 122, Bob 124, and Carol 126, and non-human presentities Carol's blood pressure 128, Carol's stock portfolio 130, and software bugs 132. Each of those presentities is itself a presence source.

[0037] As illustrated in FIG. 3-2, the watchers involved in the example presence environment include human watchers Alice 122, Bob 124, Carol 126, and Quality Assurance (QA) Manager 134, and a non-human watcher Push-to-talk-over-Cellular (PoC) service 136.

[0038] Alice 122 has a smartphone 138, Bob 124 has a tablet computer 140 and a smartphone 142, and Carol 126 has a personal computer (PC) 144. The PAL clients 108 and 110 are on Bob's tablet computer 140 and smartphone 142, respectively. The PAL client 114 is on Alice's smartphone 138, and the PAL client 116 is on Carol's PC 144.

[0039] Alice 122, Bob 124 and Carol 126 are all subscribed to an instant messaging (IM) service provided by one or more IM servers (not shown), and therefore have an IM client 146 on Alice's smartphone 138, on Bob's tablet computer 140 and on Bob's smartphone 142, and on Carol's PC 144, respectively. IM client 146 is an example of the presence-aware applications and an example of the watcher applications described above with respect to FIG. 1 , because an IM client on an apparatus generates or reflects state of the user of the apparatus and consumes presence information regarding friends or buddies of the user that have also subscribed to the IM service and have authorized the user of the apparatus to be a watcher of their IM-related presence information. For example, if Alice 122, Bob 124, and Carol 126 are all authorized IM-buddies of each other, Alice's IM client consumes presence information generated or reflected by Bob's IM client and by Carol's IM client that has been authorized by the presence platform to Alice. A presence user agent 148 on Alice's smartphone 138 publishes (as illustrated in FIG. 3-1 by an arrow 150) to the presence server 102 IM-related presence information generated or reflected by Alice's IM client 146. A presence user agent 152 on Carol's personal computer (PC) 144 publishes (as illustrated in FIG. 3-1 by an arrow 154) to the presence server 102 IM-related presence information generated or reflected by Carol's IM client 146. A presence user agent 156 on Bob's tablet computer 140 publishes (as illustrated in FIG. 3-1 by an arrow 158) to the presence server 102 IM-related presence information generated or reflected by Bob's IM client 146 on Bob's tablet computer 140.

[0040] The PAL server 106 subscribes (as illustrated in FIG. 3-2 by an arrow 160) to the presence server 102 on behalf of Alice 122, so that the PAL server 106 can expose to the PAL client 114 presence aspects for Alice's IM buddies, including Bob 124 and Carol 126, in keeping with a presence context 162 established by the PAL server 106 at the request of the PAL client 114.

[0041] The PAL server 106 subscribes (as illustrated in FIG. 3-2 by an arrow 164) to the presence server 102 on behalf of Carol 126, so that the PAL server 106 can expose to the PAL client 116 presence aspects for Carol's IM buddies, including Alice 122 and Bob 124, in keeping with a presence context 166 established by the PAL server 106 at the request of the PAL client 116.

[0042] The PAL server 104 subscribes (as illustrated in FIG. 3-2 by an arrow 168) to the presence server 102 on behalf of Bob 124, so that the PAL server 104 can expose to the PAL client 108 presence aspects for Bob's IM buddies, including Alice 122 and Carol 126, in keeping with a presence context 170 established by the PAL server 104 at the request of the PAL client 108. The IM client 146 on Bob's tablet computer 140 consumes the presence aspects for Bob's IM buddies that are exposed to the PAL client 108.

[0043] Bob 124 is subscribed to the PoC service 136 and therefore, as illustrated in FIG. 3-1, has a PoC client 172 on the smartphone 142. A presence user agent 174 on Bob's smartphone 142 publishes (as illustrated in FIG. 3-1 by an arrow 176) to the presence server 102 IM -related presence information generated or reflected by Bob's IM client 146 on Bob's smartphone 142 and PoC-related presence information generated or reflected by the PoC client 172 on Bob's smartphone 142. Presence information generated or reflected by the PoC client 172 is consumed, as illustrated in FIG. 3-2, by a PoC server 178 on a server 180 operated on behalf of the PoC service 136. The PAL server 104 subscribes (as illustrated in FIG. 3-2 by an arrow 182) to the presence server 102 on behalf of the PoC service 136, so that the PAL server 104 can expose to the PAL client 112, in keeping with a presence context 184 established by the PAL server 104 at the request of the PAL client 112, presence aspects calculated from PoC-related presence information generated by the PoC client 172 on Bob's smartphone 142. The PAL client 112 is on the server 180.

[0044] A stock-ticker service 186 on a server 188 may reflect presence information (e.g. current market price) for stocks 130, for example, via a real-time market feed from a source (not shown in FIG. 3-1) of stock information. Alice 122, Bob 124 and Carol 126 may all be subscribers to the stock-ticker server 186. A presence user agent 190 on the server 188 publishes (as illustrated in FIG. 3-1 by an arrow 192) to the presence server 102 stock-related presence information generated or reflected by the stock-ticker service 186. The presence user agent 190, operating as a delegate presence user agent on behalf of Alice 122, Bob 124 and Carol 126, may work in concert with the stock-ticker service 186 to decipher which stocks are in which person's stock portfolio for those individuals who have subscribed to the stock-ticker service 186. A financial application 194 on Carol's PC 144 consumes the presence information related to her stock portfolio that is reflected by the stock-ticker service 186. The PAL server 106 subscribes (as illustrated in FIG. 3-2 by an arrow 196) to the presence server 102 on behalf of Carol 126, so that the PAL server 106 can expose to the PAL client 116, in keeping with a presence context 198 established by the PAL server 106 at the request of the PAL client 116, presence aspects calculated from stock-related presence information generated by the stock-ticker service 186.

[0045] As illustrated in FIG. 3-1, a blood pressure sensor application 202 on Carol's PC 144 reflects presence information for Carol's blood pressure 128 as generated by a physical blood pressure sensor (not shown). A presence user agent 204 on Carol's PC 144 publishes (as illustrated in FIG. 3-1 by an arrow 206) to the presence server 102 blood-pressure -related presence information reflected by the blood pressure sensor application 202. Alice 122 may be Carol's physician, authorized by Carol to monitor her published blood-pressure -related presence information. As illustrated in FIG. 3-2, a medical diagnostics application 208 on Alice's smartphone 138 consumes the presence information reflected by the blood pressure sensor application 202. The PAL server 106 subscribes (as illustrated in FIG. 3-2 by an arrow 209) to the presence server 102 on behalf of Alice 122, so that the PAL server 106 can expose to the PAL client 115, in keeping with a presence context 210 established by the PAL server 106 at the request of the PAL client 115, presence aspects calculated from the blood-pressure- related presence information reflected by the blood pressure sensor application 202.

[0046] As illustrated in FIG. 3-1, a bug reporting application 212 on a server 214 may generate presence information (e.g. fixed or pending) for the identified defects or bugs 132 in a software product (not shown). A presence user agent 216 on the server 214 publishes (as illustrated in FIG. 3-1 by an arrow 218) to the presence server 102 bug-related presence information reflected by the bug reporting application 212. As illustrated in FIG. 3-2, a bug tracking application 220 on an apparatus 222 operated by or on behalf of the QA manager 134 consumes the presence information generated by the bug reporting application 212. The PAL server 106 subscribes (as illustrated in FIG. 3-2 by an arrow 224) to the presence server 102 on behalf of the QA manager 134, so that the PAL server 106 can expose to the PAL client 118, in keeping with a presence context 226 established by the PAL server 106 at the request of the PAL client 118, presence aspects calculated from bug-related presence information generated by the bug reporting application 212.

[0047] This disclosure proposes identifying, chronicling, and documenting activities and operations applicable to a presence context that are performed in (or on behalf of) a presence access layer.

[0048] A PAL server may associate an activity log with an established presence context, and create entries in the activity log, each entry identifying, chronicling, and documenting an activity applicable to the presence context that was performed in the PAL server. Such activities may include operations that involve the interface between the PAL server and PAL clients ("interface operations"), and may also include activities that the PAL server executes or invokes in support of the interface operations. [0049] Examples of the interface operations include: establishment of the presence context; providing baseline values of presence aspects upon request; providing current (possibly updated) values of presence aspects upon request; sending/receiving a notification of updated values of presence aspects; suspending a presence context upon request; resuming a suspended presence context upon request.

[0050] Activities that the PAL server executes or invokes or performs in support of the interface operations include: subscribing to a presence server, receiving a notification of updated presence information from the presence server; executing rules and policies to process received presence information; and evaluating presence aspects of active contexts.

[0051] A PAL client may use one or more records to keep track of a most recent interface operation carried out at the PAL client for a given presence context. For an example where the PAL client uses a single record per presence context, the PAL client carries out a first operation for a given presence context, and notes the first operation and a first timestamp related thereto in the record. Then the PAL client carries out a second operation for that presence context, and notes the second operation and a second timestamp related thereto in the record. Noting the second operation and its related timestamp in the record may overwrite the existing contents of the record, thus deleting any indication of the first operation and its related timestamp from the record. Then the PAL client carries out a third operation for that presence context, and notes the third operation and a third timestamp related thereto in the record. Noting the third operation and its related timestamp in the record may overwrite the existing contents of the record, thus deleting any indication of the second operation and its related timestamp from the record. In other examples, the PAL client may use a small number (e.g. five) of records to keep track of recent operations carried out successfully at the PAL client for a given presence context, overwriting the existing contents as needed.

[0052] Returning briefly to the example presence environment of FIG. 1, the PAL server 44 creates entries in an activity log 72 associated with the presence context 62, in an activity log 74 associated with the presence context 64, and in an activity log 76 associated with the presence context 66. The PAL client 46 uses one or more records 82 to keep track of a most recent operation carried out successfully at the PAL client 46 for the presence context 62, the PAL client 48 uses one or more records 84 to keep track of a most recent operation carried out successfully at the PAL client 48 for the presence context 64, and the PAL client 48 uses one or more records 86 to keep track of a most recent operation carried out successfully at the PAL client 48 for the presence context 66.

[0053] FIG. 4 is an illustration of a record at a PAL client. The information stored in a record 302 may include, for example, an identifier 304 of the presence context, a timestamp 306 to a predefined precision, and an operation identifier 308 of an interface operation. Additional fields (not shown) may be included in the record. An example interface operation performed by a PAL client in connection with a presence context is to send a request to the PAL server for the value of specific presence aspect.

<?xml version="l .0" encoding="UTF-8"?>

<pal-message xmlns : pl="urn : oma : xml : prs : pal : payloads : 1.0 "

xmlns : p2="urn : oma : xml : xdm : pal-profile : 1.0 ">

<pal-request>

<establish-pres-context service-id="pttchat@example . com"

pal-client-id="alice@example . com" quality-of-service="Gold">

</establish-pres-context>

</pal-request>

</pal-message>

[0054] For this example, the operation identifier could be a hash of the information used in the request itself. Additional fields in the record could be anything not included in the operation identifier, for example, the Quality of Service (QoS) and/or the aspect-value "oma:prs:pal:aspec:allApplicable" could be provided separately. Further, other information (not in the payload) could be included, such as the protocol used for the operation (e.g. HTTP or SIP), the field-values (e.g. the target URI that the protocol message was sent to), etc.

[0055] FIG. 5-1 is an illustration of an activity log associated with a presence context. The information stored in an activity log 320 may include, for example, an identifier 322 of the presence context and one or more descriptors 324 of the presence context. The information included in each entry 326 may include, for example, a timestamp 328 to a predefined precision, an identifier 330 of an activity applicable to the presence context, and, if applicable, data 332 representing the operands or argument data of the activity and the result 334 or results of performing the activity on the data.

[0056] The descriptors 324 fully describe the presence context, and are sufficiently complete that any PAL server can determine from the descriptors i) which presence information is relevant to a presence-consuming service or application, ii) how that presence information, once shared by the presence server, is parsed and interpreted by the PAL server, and iii) how a consolidated view of the relevant presence information is provided by the PAL server to the PAL client for consumption by that presence-consuming service or application. The descriptors 324 identify the presence aspects, the rules, the policies and, optionally, the triggers associated with the presence context for which the activity log is being maintained.

[0057] FIG. 5-2 is an illustration of an alternate activity log associated with a presence context. An activity log 340 differs from the activity log 320 in that its entries 346 are tagged with entry identifiers 348.

[0058] In one example, the entry identifiers 348 are incremental. As each is created in the activity log, the entry identifier included in that has a higher value than any entry identifier that tags any previously created entry in that activity log. By consulting this entry identifier, a PAL client is able to obtain the PAL server's timestamp for an interface operation without time synchronization and network latency issues, and to guess the previous or next activities in the activity log (for the case where logical pointers are not available). The use of incremental entry identifiers may render time synchronization between a PAL server and a PAL client less important or even insignificant. The user of incremental entry identifiers may render insignificant the predefined precision of the timestamps in the record kept by the PAL client.

[0059] In another example, the entry identifiers 348 may be hashed values of some of the inputs used to generate or execute the activity identified, chronicled and documented in that entry. For example, performing a hash-code of the subscribe payload, and other inputs, to calculate a value that is not repeated in any other entry.

[0060] The identifier 304, 322 of a presence context is generated by a PAL server when the PAL server established the presence context at the request of a PAL client. The identifier of the presence context is generally unique, and may incorporate a universal identifier (UID) of a user or watcher associated with the PAL client that requested the establishment of the presence context. An example presence context identifier may be: pttchat@example . com/ { sip : alice @example . com} / 02.

[0061] An entry identifier may be an eTag, as defined in Internet Engineering Task Force (IETF) rfc4825 "The extensible Markup Language (XML) Configuration Access Protocol (XCAP)", or a unique identifier such as a universally unique identifier (UUID) (also known as a globally unique identifier (GUID)). The entry identifier may include an existing, unique identifier for the user or watcher, e.g. International Mobile Subscriber Identity (IMSI), Mobile Station Integrated Services Digital Network Number (MSISDN), International Mobile Equipment Identity (IMEI), Globally Routable User Agent URI (GRUU), IP Multimedia Public Identity (IMPI, also known as IMPU), etc., and may be partly generated by the PAL client (for example, a unique identifier for the user is provided by the PAL client) and by the PAL server (for example, the incremental part of the entry identifier, such as an incrementing number).

[0062] In some implementations, the data structure of the activity log is such that logical relative pointers such as "previous entry" and "next entry" may be used to access entries in an activity log associated with a presence context, without providing a specific timestamp or a specific identifier of a PAL activity. A linked list, for example, is accessible by logical relative pointers. Similarly, a queue mechanism, for example, a last-in-first-out (LIFO) type queue, is accessible by logical relative pointers, as is a stack that pushes and subsequently pops entries. In some implementations, the data structure of the activity log is such that absolute pointers such as "first entry", "last entry" and "entry (entry identifier)" may be used to access entries in an activity log. An indexed array, for example, is accessible by absolute pointers. A structured document, for example, is accessible by reference to an identifier or by reference into the structure itself. A PAL client may use a similar data structure to those described above for activity logs for its one or more records, although that is not described in detail in this disclosure.

[0063] Depending on the data structure for the activity log and the contents of the activity log, the PAL server may also use a record to keep track of a most recent activity carried out successfully at the PAL server for a given presence context.

[0064] FIG. 6 is a simplified flowchart of an example method to be performed by a PAL server, for establishing a presence context and recording activities. At 412, the PAL server receives a request from a PAL client to establish a presence context. At 414, responsive to receiving the request, the PAL server determines an identifier of the presence context. At 416, responsive to determining the identifier of the presence context, the PAL server associates an activity log with the identifier of the presence context, and thus with the presence context itself. For example, this may involve creating a data structure to hold the contents of the activity log and linking the data structure to the identifier of the presence context. This act of associating the activity log with the identifier of the presence context may implicitly be used to capture the notion of the established presence context, especially considering that the activity log's descriptors fully describe the presence context. At 418, the PAL server performs an activity applicable to the presence context. At 420, responsive to performing the activity applicable to the presence context, the PAL server creates an entry in the activity log for the activity, where the entry identifies, chronicles, and documents the activity. The performance of activities and creation of entries in the activity log is repeated (as illustrated by an arrow 426). At various points in time, one or more entries may be removed from the activity log, at 428.

[0065] Removal of entries from an activity log, also known as garbage collection, will reclaim storage space occupied by the activity log. The removal may occur automatically in the PAL server according to a schedule (e.g., remove entries from an activity log at 12:00 AM each day), or may be initiated by a command (e.g. initiated by a human service administrator). The garbage collection behavior of the PAL server may be configured, for example, using policies (local or otherwise). For example, to compact the activity log, the PAL server may use one or any combination of the following techniques: removing from the activity log all entries older than some threshold (e.g., older than 90 days); removing from the activity log all entries identifying activities that have no effect on the values of the presence aspects; removing from the activity log older entries related to a presence aspect while retaining in the activity log a newer entry identifying a notification of an updated value of the presence aspect.

[0066] For example, the following sequence of simplified example entries may be created l activity log for a presence context (omitting data and results).

2012-1 1-26 08: 12, Context established

2012-1 1-26 08:45 Fetch (initial value of presence aspects associated with context)

2012-1 1-26 10: 15 Context suspended

2012-1 1-26 1 1 :57, Context resumed

2012-1 1-26 12:48 Notify (updated value of one or more presence aspects)

2012-1 1-27 15:03 Notify (updated value of one or more presence aspects)

2012-1 1-30 09: 15; Notify (updated value of one or more presence aspects)

Sequence 1 [0067] The activities "Context established", "Context suspended" and "Context resumed" are all examples of interface operations that may not have any effect on the values of the presence aspects. Therefore it may not be detrimental to remove the entries for those activities from the activity log, resulting in an activity log having the following sequence:

2012-1 1-26 08:45; Fetch (initial value of presence aspects associated with context)

2012-1 1-26 12:48; Notify (updated value of one or more presence aspects)

2012-1 1-27 15:03; Notify (updated value of one or more presence aspects)

2012-1 1-30 09: 15; Notify (updated value of one or more presence aspects)

Sequence 2

[0068] In another example, the following sequence of simplified example entries having entry identifiers may be created for a presence context (omitting data and results). In this example, a single presence aspect is associated with the established presence context.

Sequence 3

[0069] The activity having entry identifier id2 is a fetch of the initial value of the single presence aspect, and the activities having entry identifiers id3, id4 and id5 are all notifications of updated values of the single presence aspect. The notifications of updated values for the single presence aspect result from triggers associated with the presence context that was established (see entry identifier idl). The notification identified in the entry id5 is the most recent update of the value of the single presence aspect and supersedes any previous fetches and notifications of the value of the single presence aspect. Therefore it may not be detrimental to remove the entries id2, id3 and id4 from the activity log, resulting in an activity log having the following sequence:

idl ; 2012-10-16 08: 12; Context established

id5; 2012-10-20 09: 15; Notify (updated value of presence aspect)

Sequence 4 [0070] The introduction of the activity log enhances the presence access layer in numerous ways.

[0071] An activity log tracks the history of an active presence context through time or a specific time period (since the moment of establishment - or since a later time, if earlier entries have been removed). Thus an activity log represents all operations which bring a presence context and values of its associated presence aspects from one point to another. Activities that are identified, chronicled, and documented in entries of an activity log can be processed/replayed by any corresponding component of the presence access layer - much like repeating a chess game step-by- step. That is, the activity log can be replayed by another PAL server, and interface operations can be replayed by any authorized PAL client.

[0072] FIG. 7 is a simplified flowchart illustration of a method for generating metadata for a specific timeframe. The method illustrated in FIG. 7 may be performed by a PAL client. At 452, a PAL client may receive an identifier of a presence context that is already established in a presence access layer. For example, the presence context may have been established by a PAL server at the request of the PAL client on behalf of a particular watcher or at the request of a different PAL client on behalf of the particular watcher. In the latter case, the PAL client may also receive one or more records for the presence context that were used by the different PAL client to track interface operations for the presence context. At 454, the PAL client receiving the identifier of the presence context may request access to an activity log associated or stored with the presence context at a PAL server, or may access multiple records for the presence context stored at the PAL client.

[0073] The activity log includes entries identifying, chronicling, and documenting activities applicable to the presence context that were performed at the PAL server on behalf of a PAL client. For example, accessing the activity log may involve the PAL client making one or more access requests of the PAL server that established the presence context. The access requests may include the identifier of the presence context, so that the PAL server handles the access requests with respect to the activity log associated with that presence context. Responses from the PAL server to access requests from a PAL client may include details of the entries in the activity log, for those entries that identify, chronicle, and document interface operations. That is, an entry regarding sending a notification of an updated value of a presence aspect is interpreted by the PAL client as an interface operation of receiving the notification with the updated value of the presence aspect.

[0074] Consider a timeframe that starts at a specific earlier time and ends at a specific later time. At 456, the PAL client may review/replay the interface operations tracked in the multiple records or identified, chronicled, and documented in the entries of the activity log having a timestamp between the specific earlier time and the specific later time, thus generating metadata on behalf of the PAL client for the presence context for the timeframe.

[0075] An activity log enables processing of a presence context by a PAL client to be deferred and then resumed. Consider the situation where a PAL client experiences a period of non-connectivity with a PAL server. The non-connectivity may be unexpected. For example, the non-connectivity may result from the PAL client's apparatus suddenly losing power, or from the apparatus entering a location where wireless connectivity is blocked. The sudden, unexpected, or abnormal loss of connectivity means that the PAL client is unable to initiate suspension of the presence context, and the PAL server may continue to send triggered notifications to the PAL client as the evaluated values of presence aspects change, although the PAL client will not be able to receive the notifications. However, the PAL server records the notifications of updated values in the activity log associated with the presence context. This enables the PAL client to recover missing updates for the presence context, after reestablishing connectivity with the PAL server.

[0076] FIG. 8 is a simplified flowchart illustration of a method for tracking operations applicable to a presence context. The method illustrated in FIG. 8 may be performed by a PAL client. At 462, a PAL client may request establishment of a presence context at a PAL server, by issuing a presence context establishment request to the PAL server. The request may include an identity of the watcher, an identifier of the presence-consuming service on behalf of which the request is being made, and optionally a list of one or more presentities of interest. At 464, responsive to the PAL server having established the presence context, the PAL client may receive an identifier of the presence context, for use in further communications regarding the presence context. At 468, the PAL client carries out an interface operation applicable to the presence context. At 470, responsive to carrying out the interface operation applicable to the presence context, the PAL client keeps track of the interface operation in a record for the presence context. The carrying out of interface operations and the tracking of the interface operations in the record is repeated (as illustrated by an arrow 472). As interface operations applicable to the presence context are carried out at the PAL client, the PAL client uses a record to keep track of a most recent one of the interface operations.

[0077] A period of non-connectivity may occur (as illustrated by dashed arrow 473), following which connectivity is re-established at 474. At that point, the PAL client's record identifies the most recent interface operation for the presence context carried out at the PAL client prior to the period of non-connectivity. Interface operations performed at the PAL server during the period of non-connectivity have been "missed" by the PAL client. Because none of the interface operations performed at the PAL server during the period of non-connectivity will have originated at the PAL client, it is expected that the "missed" interface operations will be notifications of updated values of presence aspects.

[0078] Upon re-establishing the connectivity, the PAL client may direct the PAL server to access interface operations in the activity log that occurred after the most recent timestamp in the PAL client's record. For example, the PAL client may access the activity log corresponding to that timestamp, then use relative pointers "next entry" to access the interface operations that were performed during the period of non-connectivity.

[0079] Alternatively, the PAL client may communicate the most recent timestamp in the PAL client's record to the PAL server, and the PAL server may begin replaying the interface operations that occurred after that timestamp, thus bringing the PAL client up to date. In some situations, the PAL server may replay only the latest of the interface operations that occurred after that timestamp.

[0080] Responsive to re-establishing connectivity with the PAL server after a period of non-connectivity with the PAL server, the PAL client may receive, at 478, from the PAL server one or more notifications for the presence context that were originally sent by the PAL server - but not received by the PAL client - during the period of non-connectivity. The PAL client may receive all notifications for the presence context that were originally sent by the PAL server during the period of non-connectivity, or just the most recent notification for the presence context that was originally sent by the PAL server during the period of non- connectivity. [0081] An alternative action taken by a PAL client responsive to re-establishing connectivity with a PAL server after a period of non-connectivity could be simply to request resumption of the presence context from the PAL server, even though the presence context may not have ever been suspended. A "resume presence context" request from the PAL client may result in the PAL server sending one or more notifications related to the presence aspects.

[0082] An activity log enables decoupling of PAL servers and PAL clients.

[0083] In one aspect, responsibility for or utilization of a presence context can be transferred from one PAL client to another PAL client. Suppose that a presence context was established at a PAL server at the request of a first PAL client to provide a framework for the consumption of presence information by a presence-consuming application/service. For example, referring to FIG. 3-2, Bob 124 used the IM client 146 on his tablet computer 140, thus the presence context 170 was established at the PAL server 104 at the request of the PAL client 108 and the PAL server 104 subscribed to the presence server 102 on behalf of Bob 124, so that the PAL server 104 could expose to the PAL client 108 (for use by the IM client 146 on Bob's tablet computer 140) presence aspects for Bob's IM buddies. Thus the IM client 146 on Bob's tablet computer 140 is up-to-date with the latest presence aspects for Bob's IM buddies. Now Bob switches from his tablet computer 140 to his smartphone 142, and wants to continue his IM experience, by using the IM client 146 on the smartphone 142. By transferring the responsibility for the presence context 170 from the PAL client 108 on Bob's tablet computer 140 to the PAL client 110 on Bob's smartphone 142, as illustrated in FIG. 9, the IM client 146 is able to proceed as if the presence context 170 had been established from the start at the request of the PAL client 110. FIG. 9 differs from FIG. 3-2 in that the PAL client 110 on Bob's smartphone 142 (rather than the PAL client 108 on Bob's tablet computer 140) is now responsible for the presence context 170, for the benefit of the IM client 146 on Bob's smartphone 142.

[0084] At a minimum, transferring the responsibility for the presence context 170 entails providing the PAL client 110 on Bob's smartphone 142 with an identifier of the presence context 170, so that the PAL client 110 can access the activity log at the PAL server 104 that is associated with the presence context 170. FIG. 10 is a simplified illustration of an example method for transferring responsibility for a presence context from a first PAL client on a first apparatus to a second PAL client on a second apparatus. At 504, a migrate function is initiated by a user of the watcher application/service on the first apparatus. At 506, the watcher application/service issues a synchronization operation to the corresponding watcher application/service on the second apparatus. The synchronization operation may be network- based or may occur using a third apparatus (not shown), such as a desktop PC using one or more Universal Serial Bus (USB) connections. The watcher application/service on the first apparatus performs at 508 a transport protocol handshake (including a possible authorization step) toward the watcher application/service on the second apparatus, successfully resulting at 510 in the transfer of objects (including the presence context identifier) from the first apparatus to the second apparatus. In some implementations, the migrate function may be underlying to the apparatuses' operating system functionality, thus enabling any application to migrate aspects (e.g. presence contexts) from the first apparatus to the second apparatus. At 512, the watcher application/service on the second apparatus may notify the PAL server that it is responsible for the transferred presence context, so that future communications will be with the PAL client coupled to the watcher application/service on the second apparatus.

[0085] In another aspect, processing of a presence context can be transferred from one PAL server to another PAL server. This transfer may done as part of a live 'in-place upgrade' of the PAL service, or for load balancing between PAL servers. Suppose that a presence context was established at a first PAL server at the request of a PAL client to provide a framework for the consumption of presence information by a presence-consuming application/server. For example, referring to FIG. 3-2, the presence context 162 was established at the PAL server 106 at the request of the PAL client 114 and the PAL server 106 subscribed to the presence server 102 on behalf of Alice 122 so that the PAL server 106 could expose to the PAL client 114 (for use by the IM client 146 on Alice's smartphone 138) presence aspects for Alice's IM buddies. In the interest of load balancing between PAL servers, or for any other reason, processing of the presence context 162 may be transferred from the PAL server 106 to the PAL server 104, as illustrated in FIG. 11. FIG. 11 differs from FIG. 3-2 in that the activity log associated with the presence context 170 has been transferred (via inter-PAL-server communication) from the PAL server 106 to the PAL server 104, and processing of the presence context 170 is handled by the PAL server 106 instead of by the PAL server 104. To transfer the subscription (at the presence server 102) of the PAL server 106 on behalf of Alice 122 to the PAL server 104, the PAL server 104 takes over as a delegate watcher of the presence context 162. In some examples, this may require the PAL server 104 to re-subscribe at the presence server 102 for the presence information.

[0086] The transfer of processing of a presence context from one PAL server to another PAL server may occur without having to suspend or release or terminate the presence context to be 'handed over'. This enable the other PAL server, which may be a newly upgraded PAL server, to pick up processing of one or more presence contexts from the point where the previous PAL server left off, without losing or omitting any significant events. Further, any PAL client connected to the PAL server may be unable to detect the transfer (whether due to an in-service upgrade or for load balancing), because any operations that occur during the actual transfer are deferred and applied or picked up based on the activity logs.

[0087] In a further aspect, the ability to defer processing of operations is itself a form of decoupling, because the PAL client does not need to suspend a presence context in order to handle scenarios such as loss of network connectivity (i.e. by an apparatus) or migrating an active (non-terminated) presence context from one apparatus to another.

[0088] Presence contexts can be logically joined, combined, or pipelined. This logical joining, combining, or pipelining may be effected by combining the activity logs associated with the different presence contexts.

[0089] For example, referring to FIG. 3-2, the presence context 170 was established at the PAL server 104 at the request of the PAL client 108 and the PAL server 104 subscribed (as illustrated by the arrow 168) to the presence server 102 on behalf of Bob 124, so that the PAL server 104 could expose to the PAL client 108 (for use by the IM client 146 on Bob's tablet computer 140) presence aspects for Bob's IM buddies. Referring now to FIG. 12, consider a presence context 171 established at the PAL server 104 at the request of the PAL client 110, and that the PAL server 104 subscribed (as illustrated by an arrow 169) to the presence server 102 on behalf of Bob 124, so that the PAL server 104 could expose to the PAL client 110 (for use by the IM client 146 on Bob's smartphone 142) presence aspects for Bob's IM buddies. Because the presence context 170 and the presence context 171 are both providing a framework for the consumption of IM-related presence information by the same IM client (albeit on different apparatuses) for the same presentities, the presence context 170 and the presence context 171 can be logically joined or combined. [0090] If the timestamps in the activity log associated with the presence context 170 are earlier than the timestamps in the activity log associated with the presence context 171, then a simple concatenation of the two activity logs can result in a single activity log representing the complete timeframe (from the earlier of the timestamps to the latest of the timestamps). For example, the activity log associated with the presence context 170 may cover 1 January 2013 through 12 January 2013, and the activity log associated with the presence context 171 may cover 13 January 2013 onwards. By appending the activity log associated with the presence context 171 to the activity log associated with the presence context 170, the result is a single activity log that covers 1 January 2013 onwards.

[0091] If the timestamps in the activity log associated with the presence context 170 overlap the timestamps in the activity log associated with the presence context 171, then, depending on the data structures used for the activity logs, the combination of the two activity logs into a single activity log representing the complete timeframe (from the earlier of the timestamps to the latest of the timestamps) may be done in a manner that preserves an inherent order of time-stamped entries. For example, the activity log associated with the presence context 170 may cover 1 January 2013 through 8 January 2013 and 11 January 2013 through 12 January 2013, and the activity log associated with the presence context 171 may cover 9 January 2013 through 10 January 2013.

[0092] Statistical analysis and data mining can be performed on the contents of one or more activity logs, thus generating useful information. Such analysis and data mining will involve queries based on an understanding of the relevant presence information. A PAL server, or any other component with access to an activity log or multiple activity logs may calculate results from one or more entries in the activity log or multiple activity logs, each statistical result corresponding to a statistical measures (for example, minimum, maximum, average, count or quantity). Further, one or more first statistical results may be related or compared or otherwise analysed with respect to one or more second statistical results, and responsive to that relation or comparison or analysis, a corrective action may be taken or recommended or suggested. For example, an activity log associated with the presence context 226 could be analysed to calculate statistical measures (for example, minimum, maximum, average, count or quantity) about the time spent on fixing software bugs 132 for use with a Bug Tracking Application 220. In another example, the financial application 194 on Carol's PC 144 could create timeline charts of financial/stock-portfolio information, based on the contents of the activity log for the presence context 198, because the financial application 194 has access to the history of the presence information and not just the most recent data. In yet another example, the contents of an activity log associated with a presence context for handling the presence information reflected by the blood pressure sensor application 202 (illustrated in FIG. 3-1) and published by the presence user agent 204 could be analysed to create a chart of Carol's blood pressure over any given period of time. Such a chart may be helpful in identifying moments in time when Carol did not take her medication on time or did something unexpected that upset the balance. An analysis of that activity log and the activity log for the presence context 198 (illustrated in FIG. 3-2) could be done to see how Carol's blood pressure correlates with the performance of her stock portfolio. In a further example, if the presence aspect contained or pertained to a user's online status, one could check whether a person was online at a specific time, check how often the user was online over the last month, what is the most likely time of the day for a user to come online, how long a period does the person spend online, etc. In yet a further example, if the presence aspect contained or pertained to a lock in an entry system (physical or logical), one could check whose key was used to unlock the lock (e.g. open the door, access the system, enter and exit) and when. Additional use cases, including those involving the corrective action of administration of a medicine, are contemplated.

[0093] A timeline of presence information as recorded in an activity log could itself be a distinct presence aspect that is processed by a PAL server and exposed to a PAL client. For example, the presence aspect onlineSummary may be a new presence aspect associated with another presence capable service (e.g. a reporting application) that provides a summary for a given user of when that person is online. Alternatively, the presence aspect onlineSummary may be expressed as an absolute percentage (e.g. the value for Bob for onlineSummary is 35, which means that Bob was online for 35% of the total time over the last 30 days). Higher level abstractions allow for generating more advanced, service-level statistics/summaries while watching multiple presentities or all presentities (e.g., users, bugs, blood pressure sensors) in the given system. The underlying PAL rule (to evaluate the presence aspect onlineSummary) may be different, based on the presence context. For example, the PAL rule to evaluate onlineSummary may be different for an IM platform than for a logical entry/exit system. Further, the presence information and other inputs used to evaluate onlineSummary may be entirely different, based on the presence context. In other words, the meaning, importance and significance of onlineSummary will depend entirely upon the presence context.

Claims

What is claimed is:

1. A method for recording activities at a presence access layer 'PAL' server (44,104,106), the method comprising: associating (416) an activity log (72,74,76,320,340) with a presence context

(62,64,66), the presence context having been established in a presence access layer (43) coupled to a presence server (22); and creating (420) entries (326,346) in the activity log, each entry identifying, chronicling, and documenting an activity applicable to the presence context that was performed in the presence access layer.

2. The method as claimed in claim 1, wherein the activity log includes identifiers (324) of triggers, presence aspects, rules and policies associated with the presence context.

3. The method as claimed in claim 1 or claim 2, wherein each entry is tagged with an entry identifier (348), such that as each entry is created in the activity log, the entry identifier included in that entry has a higher value than the entry identifier that tags any previously created entry in that activity log.

4. The method as claimed in claim 1 or claim 2, wherein each entry is tagged with an entry identifier (348), such that as each entry is created in the activity log, the entry identifier included in that entry differs from the entry identifier that tags any previously created entry in that activity log.

5. The method as claimed in any one of claims 1 to 4, further comprising removing (428) from the activity log entries identifying activities that have no effect on the values of the presence aspects associated with the presence context.

6. The method as claimed in any one of claims 1 to 5, further comprising removing (428) from the activity log older entries related to a presence aspect while retaining in the activity log a newer entry identifying a notification of an updated value of the presence aspect.

7. The method as claimed in any one of claims 1 to 6, further comprising combining the activity log with another activity log associated with another presence context.

8. The method as claimed in any one of claims 1 to 6, further comprising calculating statistical results from at least one entry (326,346) in the activity log (72,74,76,320,340), each result corresponding to a statistical measure.

9. The method as claimed in claim 8, wherein the statistical measure is at least one of minimum, maximum, average, count or quantity.

10. The method as claimed in claim 8 or claim 9, further comprising: relating a first of the statistical results to a second of the statistical results; and taking or recommending a corrective action.

11. The method as claimed in claim 10, wherein the first statistical result is a room temperature, the second statistical result is a body temperature, and the corrective action is administration of a medicine.

12. The method as claimed in claim 10, wherein the first statistical result is a stock price and the second statistical result is a blood pressure.

13. A method at a presence access layer 'PAL' client (46,48) for generating metadata, the method comprising: receiving (452) an identifier (304) of a presence context (62,64,66) already established in a presence access layer (43); and accessing (454) an activity log (72,74,76,320,340) associated with the presence context, the activity log including entries (326,346) in the activity log, each entry identifying, chronicling, and documenting an activity applicable to the presence context that was performed in the presence access layer; and replaying (456) the interface operations identified in the entries of the activity log having a timestamp between a specific earlier time and a specific later time, thus generating metadata for the presence context for a timeframe starting at the specific earlier time and ending at the specific later time.

14. A method at a presence access layer 'PAL' client (46,48) for generating metadata, the method comprising: receiving (452) an identifier (304) of a presence context (62,64,66) already established in a presence access layer (43); and accessing (454) multiple records (302) for the presence context, the records tracking interface operations applicable to the presence context that were performed in the presence access layer; and replaying (456) the interface operations tracked in the multiple records having a timestamp between a specific earlier time and a specific later time, thus generating metadata for the presence context for a timeframe starting at the specific earlier time and ending at the specific later time.

15. A method for tracking interface operations for a presence context (62,64,66) at a presence access layer 'PAL' client (46,48), the method comprising: using one or more records (82,84,86,302) to keep track of one or more interface operations applicable to the presence context that are carried out at the PAL client; responsive to re-establishing connectivity with a PAL server (44,104,106) after a period of non-connectivity with the PAL server, receiving from the PAL server one or more notifications for the presence context that were sent by the PAL server - but not received by the PAL client - during the period of non-connectivity.

16. The method as claimed in claim 15, further comprising directing the PAL server to access one or more interface operations in an activity log maintained by the PAL server that occurred after a most recent timestamp (306) in the one or more records.

17. The method as claimed in claim 15, further comprising communicating to the PAL server a most recent timestamp (306) in the one or more records, resulting in the PAL server replaying one or more interface operations in an activity log maintained by the PAL server that occurred after the most recent timestamp.

18. A network component having a presence access layer 'PAL' server, the network component operable to perform the method as claimed in any one of claims 1 to 12.

19. An apparatus having a presence access layer 'PAL' client, the device operable to perform the method as claimed in any one of claims 13 to 17.