WO2019120538A1

WO2019120538A1 - Method and notification manager for delivering notifications to a device user

Info

Publication number: WO2019120538A1
Application number: PCT/EP2017/084054
Authority: WO
Inventors: Lakshmi Narasimham B; Magnus Lindström
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2017-12-21
Filing date: 2017-12-21
Publication date: 2019-06-27
Anticipated expiration: 2020-06-21

Abstract

A method and notification manager (200) for delivering a notification to a device user in a communication network. The notification manager (200) obtains (2:1) and saves (2:2) a notification targeted to the device user. When detecting (2:4) an activity on a client device (202A) associated with the device user, the notification manager (200) delivers (2:6) the saved notification to at least one preferred client device according to predetermined delivery preferences, in reaction to the detected activity. Thereby, the notification is not delivered until the activity, e.g. initiated by the user, is detected so that any unwanted or unsuitable delivery of notifications can be avoided.

Description

METHOD AND NOTIFICATION MANAGER FOR DELIVERING NOTIFICATIONS

TO A DEVICE USER

Technical field

The present disclosure relates generally to a method and a notification manager, for delivering notifications to a device user.

Background

In communication networks of today, it is possible to receive various event- triggered notifications automatically on a client device, as for example service and product offerings, advertisements, alerts, notifications related to billing and charging and to device management, etc. Such notifications may be triggered by some kind of event, e.g. when an event source distributes information resulting in a notification related to any of the above types of events to one or more client devices. In this context, the term“event source” basically indicates an entity or function that issues or otherwise triggers notifications towards client devices.

In this description, the term“client device” is used to represent any communication device, e.g. wireless or wired, that is capable of operating in a communication network and of receiving notifications as described herein. The client device may be operated by a person or autonomously such as a so-called Machine-to- Machine, M2M, device, also referred to as a Machine-Type Communication, MTC, device. Some non-limiting examples of client devices include mobile phones, smartphones, tablets, computers, M2M or MTC devices, and so forth. Further, the communication network mentioned herein could be any type of network, either wireless or fixed or a combination thereof. The types of interfaces, protocols and messages used in the network for communicating notifications are of no particular significance to this description.

It has been identified as a problem in this context that notifications are often received and announced on the client device, e.g. by a sound and/or some displayed alert, at times when the device user does not wish to receive them, for whatever reason, or when the device is in sleep mode to save battery power. It is sometimes possible for the user to set preferences on his/her device to control when and how notifications should be received and presented. If the user has more than one client device, it may be necessary to set such preferences on each device, or to set preferences on a network level to control notification delivery for multiple client devices by the same setting of preferences. However, such setting of preferences requires that the user keeps the preferences up to date, e.g. by suppressing or suspending incoming notifications at times when the user does not want to be disturbed.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues outlined above. It is possible to achieve this object and others by using a method and a notification manager as defined in the attached independent claims.

According to one aspect, a method is performed by a notification manager for delivering a notification to a device user in a communication network. In this method the notification manager obtains and saves a notification targeted to the device user. When detecting an activity on a client device associated with the device user, the notification manager delivers the saved notification to at least one preferred client device according to predetermined delivery preferences, in reaction to the detected activity. According to another aspect, a notification manager is arranged to deliver a notification to a device user in a communication network. The notification manager is configured to obtain and save a notification targeted to the device user. The notification manager is further configured to detect an activity on a client device associated with the device user, and to deliver the saved notification to at least one preferred client device according to predetermined delivery preferences, in reaction to the detected activity.

Thereby, the notification is not delivered until the activity, e.g. initiated by the user, is detected so that any unwanted or unsuitable delivery of notifications can be avoided. The client device on which the activity was detected may be operated by the user himself/herself, or it may be an M2M device such as when the device wakes up from sleep mode and sends a message towards a server or the like. In the latter case, it can be avoided that the device needs to be contacted and awaken from the sleep mode, e.g. resulting in consumption of precious battery power, only to receive the notification which may not be urgent or time-critical.

Another advantage is that when the user has more than one device, it is not necessary to set preferences manually on each device, which would otherwise naturally require substantial efforts from the user. The above-mentioned preference setting and suspension of incoming notifications may not even be available on some types of devices.

The above method and notification manager may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below.

A computer program is also provided which comprises instructions which, when executed on at least one processor in the notification manager, cause the at least one processor to carry out the method described above. A carrier containing the above computer program is further provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium. Brief description of drawings

The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

Fig. 1 is a communication scenario illustrating how notifications are distributed to client devices, according to the prior art. Fig. 2 is a communication scenario illustrating an example of how the solution may be employed, according to some example embodiments.

Fig. 3 is a flow chart illustrating a procedure in a notification manager, according to further example embodiments. Fig. 4 is a signaling diagram illustrating an example of a procedure when the solution is used, according to further example embodiments.

Fig. 5 is a block diagram illustrating an example of how different functions in a notification manager may be configured in practice, according to further example embodiments.

Fig. 6 is a signaling diagram illustrating another example of a procedure when the solution is used, according to further example embodiments.

Fig. 7 is a signaling diagram illustrating yet another example of a procedure when the solution is used, according to further example embodiments. Fig. 8 is a block diagram illustrating how a notification manager may be structured, according to further example embodiments.

Detailed description

Briefly described, a solution is provided to enable automatic suppression of notifications and delivery thereof to a client on a preferred client device and at times when the client is detected to be active. This solution can thus be employed to serve a client or user with notifications only when it is detected that some activity occurs on one of his/her client devices which can be detected and reported by a communication network that the active device is connected to. In this description, the term“client” is basically a synonym for device user. These features can be achieved by functionality in a“notification manager” which term denotes an entity that is operable in accordance with various embodiments and examples described herein. The notification manager may be implemented in a network management node such as a Business Support System, BSS, node of a wireless network. Flowever, the solution is not limited to any particular type of practical implementation or communication network(s) and it can thus be used for any types of communication devices and networks. An example of how the notification manager may be operable to deliver a notification to a device user in a communication network, will now be described with reference to Fig. 2. In this figure, a communication scenario is shown involving a notification manager 200, a number of client devices 202 which are associated with a device user, a communication network 204 to which at least one of the devices 202 is connected and an event source 206. The figure may serve as an illustrative example of how a procedure could be employed by the notification manager 200 for delivering a notification to a device user. It should be noted that the device user in this context basically corresponds to the term“client” as used herein. In the case of an M2M device, it can be seen as owned and/or controlled by the device user even though the user does not actually operate the device“by hand”.

It is assumed that certain delivery preferences have previously been defined for the user and stored at the notification manager 200. In this example scenario, the event source 206 issues a notification directed to the user, in a first action 2:1 , which is received or otherwise obtained by the notification manager 200 which then saves the notification in another action 2:2, for later delivery. Alternatively, the event source 206 may issue some“raw” information which could be used as a basis for generating a suitable notification, e.g. in accordance with preferences, and the solution is not limited in this respect.

At some point later, one of the client devices 202A receives some input from a schematically indicated“device user”, in an action 2:3, which results in

transmission of signals to the network 204 which thereby can detect an activity, e.g. of the user, on the client device 202A. For example, the user may initiate a call or send an SMS or perform any other detectable operation on the device 202A resulting in communication with the network 204. A following action 2:4 illustrates that the network issues an indication of the activity which is thereby detected by the notification manager 200.

In another action 2:5, the notification manager 200 then checks predetermined delivery preferences that have previously been defined for the user and stored at the notification manager 200. The delivery preferences may specify which client device notifications should be delivered to, which will be described in more detail later below. In reaction to the detected activity on the client device 202A, the notification manager 200 eventually delivers the saved notification to at least one of the client devices 202 as required by the delivery preferences, in a final action 2:6. The preferred client device for delivery may be the same as the activity was detected on as indicated by a full arrow, but alternatively or additionally it could be one of the other devices as indicated by dashed arrows. Thereby, it is an advantage that the notification is not delivered until the activity, e.g. initiated by the user, is detected so that any unwanted or unsuitable delivery of notifications can be avoided. This example involved a device that was operated by the user himself/herself when the activity was detected.

It is also possible that the above-described activity is detected on an M2M device, such as when the device wakes up from sleep mode anyway and sends some measurement or other sensed observation towards a server or the like. This way, it can be avoided that the device needs to be contacted and awaken from the sleep mode, e.g. resulting in consumption of precious battery power, only to receive the notification which may not be urgent or time-critical in any way. In more detail, an M2M device that applies sleep mode commonly needs to wake up and frequently connect to the network only to check whether there are any new notifications, such as software or firmware updates, to receive. This operation consumes precious battery power in the device as well as resources in the network, often to no avail when it turns out there is no important notification(s) to receive. It is an advantage that such frequent and battery-consuming contacting to the network to check for notifications can be avoided when the embodiments herein are used.

Further, if an M2M device has been inactive for more than a preset duration, a notification may be sent from the network to some device management center which then might connect to the device to perform some troubleshooting activities, even when there is nothing wrong with it. It is another advantage of the

embodiments herein that such contacting to the device by notification will be made only after activity detection as described above. An example will now be described with reference to the flow chart in Fig. 3, of how the solution may be employed in terms of actions performed by a notification manager such as the above-described notification manager 200. Fig. 3 is described below with further reference to Fig. 2 although without limitation to such a communication scenario involving the notification manager 200. Some optional example embodiments that could be used in this procedure will also be described below.

The actions shown in Fig. 3 are thus performed by a notification manager 200 for delivering a notification to a device user in a communication network 204. In this procedure, the device user may own and/or control any number of client devices 202 and the solution is not limited in this respect. Those client devices 202 can thereby be considered to be associated with the device user.

A first optional action 300 illustrates that the notification manager 200 may set or update delivery preferences for the device user, e.g. specifying which device(s) the user wants to be monitored or otherwise involved in the procedure for notification delivery.

For example, the delivery preferences may be manually configured or otherwise selected by the device user, e.g. over a suitable web interface or the like which may offer a selection of predefined preferences. Alternatively, some predefined default preferences may be chosen, e.g. in absence of user configured or selected preferences. The delivery preferences may be set or updated by a“client agent" or the like which may be operable to receive input from the user and to send corresponding preferences to the notification manager 200 on behalf of the device user. In the following actions, it is assumed the delivery preferences have already been set, one way or another, which are therefore referred to as“predetermined delivery preferences” in this context.

In a next action 302, the notification manager 200 obtains and saves a notification targeted to the device user. The notification may be obtained in this action by receiving it as such from an event source 206, or it may be generated by the notification manager 200 based on some event that is reported by the event source 206. As an illustrative example, the event source 206 may be a

surveillance center or the like which observes some event such as occurrence of an abnormal condition in a monitored object or space, e.g. by means of a sensor or the like. This observed condition may then be reported to the notification manager 200 which accordingly generates a suitable notification regarding the abnormal condition, to be delivered to the device user. However, the received or generated notification is suppressed for the time being, i.e. until an activity on one of the user’s client devices is detected as follows.

A further action 304 illustrates that the notification manager 200 detects an activity on a client device 202A associated with the device user, which may be detected when reported by a communication network 204 to which the used client device 202A is connected. Some examples of how an activity on a client device can be detected will be described below.

In a final shown action 306, the notification manager 200 delivers the saved notification to at least one preferred client device according to the predetermined delivery preferences, in reaction to the detected activity. The delivery preferences may indicate which client device the notification should be delivered to once the activity has been detected, which could be the same one the activity was made on or a particular device at all times. Some optional and non-limiting example embodiments that could be used in this procedure will now be described.

In one example embodiment, the activity may be detected when the

communication network indicates that the client device 202A is used so that delivery of notifications is triggered according to said delivery preferences. In this case, another example embodiment may be that the activity is detected by means of an Online Charging System, OCS connected to the communication network. Whenever the user performs a detectable activity on the device resulting in a communication over the communication network, a charging record is generated by a charging function such as the OCS, which can be reported to the notification manager 200. The charging record thus indicates an activity on the client device 202A which may also be referred to as a“usage event”.

In another example embodiment, said detected activity may include any of: making a call, sending a message such as a text message or a multimedia message, downloading data or content, browsing the web, and accessing social media. All these activities entail communication of signals being sent from the used client device 202A which thereby can be detected by the communication network.

In another example embodiment, the notification manager 200 may obtain the notification based on information from an event source 206 that operates to issue event-triggered notifications, or event-triggered information that can be used for generating notifications. An example of such an event from a surveillance center acting as event source has been described above.

In another example embodiment, the delivery preferences may be related to a set of multiple client devices 202 associated with the device user. For example, the device user may own and/or control a selection of devices, e.g. including a smartphone, a tablet and a computer, and the delivery preferences may dictate to which one of the devices notifications should be delivered once an activity on anyone of them is detected.

If the above embodiment is employed, another example embodiment may be that the delivery preferences could require that the notification is delivered to the client device 202A on which the activity is detected, e.g. to ensure that the user is able to detect and see or handle the notification more or less immediately. In the case of an M2M device, the received notification can be processed by that device. Another example embodiment may be that the delivery preferences could require that the notification is delivered to a specific prioritized client device regardless of which client device the activity is detected on. In the latter option, the user may always want to get all notifications on the tablet or the computer, e.g. to reduce load and battery power consumption on the smartphone. It is also possible that the delivery preferences may dictate that one type of notifications, e.g. urgent ones such as alarms, should be delivered to the smartphone, while another type of notifications, e.g. less urgent ones such as advertisements, should be delivered to the computer so as to reduce the number of notifications to the smartphone. Another possibility is that notifications should be delivered to one device, e.g. the smartphone, during certain hours in daytime, and to another device, e.g. the computer, during other hours. Such selective delivery of notifications to different devices may also be dependent on the current or recent usage of services, to mention some further non-limiting examples. In another example embodiment, the delivery preferences may be set or updated in response to input received directly from the device user or from a client agent 208 to which the device user has provided input, as of action 300 which has been described above.

Some examples of how the above-described embodiments could be implemented and used in different practical cases, will now be described with reference to usage cases illustrated in Figs 4-7, again using the same reference numbering as of Fig. 2.

Fig. 4 illustrates an example of how messages and information may be

communicated when the solution is employed, involving the above-mentioned notification manager 200, one or more client devices 202, an event source 206 and an optional client agent 208. In a first action 4:1 , the notification manager 200 receives delivery preferences either from one of the client devices 202 (full arrow) or from the client agent 208 (dashed arrow). The received delivery preferences are then stored by the notification manager 200 in action 4:2. At some point, the notification manager 200 receives from the event source 206 information about an event that has occurred, in an action 4:3. The notification manager 200 then creates or generates a suitable notification reflecting the event, in another action 4:4. The notification may be generated in a manner dictated by the delivery preferences, or in some“default” manner. The notification as such could be configured in any manner which is somewhat outside the solution, and this is not necessary to describe herein.

At some point later, the notification manager 200 detects activity, e.g. of the device user, on one of his/her client devices, in an action 4:5, and the notification is delivered in reaction thereto in a final shown action 4:6. Some more detailed examples of how parts of this procedure could be implemented in practice, will be described below with reference to Figs 6 and 7.

Fig. 5 illustrates an illustrative but non-limiting example of how a notification manager 500 could be configured in practice. The notification manager 500 may thus comprise the following functional components:

500A: Customer care

This component can be used by customer care agents to manage customers and their service offerings.

500B: Self-care This component can enable customers to manage their service offerings on their own, for example, update notification preferences.

500C: Customer Management

This component can interact with the customer care and self-care systems and stores customer data in a persistent data storage. 500D: Event Storage/management

This component can store customer events, for example, life cycle events, events for added or removed service offerings, events for usage charges and recurring charges. The events in the event storage is used by the customer care to view the customers’ call and account history. The events in event storage may be used for invoicing.

500E: Activity management Component that interacts with mobile networks. This component may be an OCS or charging node and can receive customers’ service usage activity over 3GPP protocols such as CAPv2, SCAPv2 and Gy and may perform rating and charging for the used services. 500F: Notification Management

This component can transform events from various event sources into customer notifications. The transformation is based on configured customer notification preferences, for example, related to delivery channel and address, language, and time/date restrictions. This component can also interact with external systems and nodes to deliver notifications over different delivery channels, such as, SMS, E- mail and Unstructured Supplementary Service Data, USSD which is a

communication protocol that can be used for various mobile services.

500G: Persistent data storage

This component can store, for example, the above-mentioned customer data and event history.

Fig. 6 illustrates an example of how an event may be handled by the notification manager 200 comprising components for notification management 200A, customer management 200B and handling of event history 200C. In a first action 6:1 , the event source 206 issues information about an event. The notification management 200A then reads delivery preferences from the customer

management 200B in an action 6:2 and generates a suitable notification based on the read delivery preferences in another action 6:3. The notification management 200A also stores and suppresses the notification in another action 6:4. The notification management 200A further subscribes to any service activities that the user might perform from the component for event history 200C, in another action

6:5. Such service activities may include one or more of calls, SMS and

communication of data. Thereby, the notification manager 200 is prepared to detect activity and deliver the stored notification as follows. Fig. 7 illustrates an example of how detection of an activity may be handled by the notification manager 200, as a continuation of Fig. 6. A charge event is received by a charging function 700 for the device user from the network 204, in an action 7:1. The charging function 700 then reads user information from the customer management 200B, in another action 7:2, and performs a rating and charging operation in a further action 7:3.

The charging function 700 also issues a usage event as a user activity, in an action 7:4, which is detected by the component for event history 200C. The usage event is then published to the notification management 200A, in an action 7:5, in accordance with the subscription of action 6:5. The detected usage event/activity may be related either to a call, an SMS or communication of data. In reaction thereto, the notification management 200A retrieves the notification in an action 7:6 and sends the notification to the client device 202 in a final action 7:7.

The block diagram in Fig. 8 illustrates a detailed but non-limiting example of how a notification manager 800 may be structured to bring about the above-described solution and embodiments thereof. The notification manager 800 may be configured to operate according to any of the examples and embodiments for employing the solution as described herein, where appropriate and as follows. The notification manager 800 is shown to comprise a processor P and a memory M, said memory comprising instructions executable by said processor whereby the notification manager 800 is operable as described herein. The notification manager 800 also comprises a communication circuit C with suitable equipment for sending and receiving information and notifications in the manner described herein.

The communication circuit C may be configured for communication with one or more client devices 802 corresponding to the client devices 202 in Fig. 2, and for communication with one or more event sources 804 corresponding to the event source 206 in Fig. 2, using suitable protocols and interfaces. Such communication may be performed over any suitable interfaces and nodes depending on the implementation, although this is not necessary to describe here as such in any detail. The solution and embodiments herein are thus not limited to using any specific types of messages or protocols for communication.

The notification manager 800 comprises means configured or arranged to basically perform at least some of the actions in Fig. 3, and more or less as described above for the notification manager 200 in various examples. In Fig. 8, the notification manager 800 is arranged or configured to deliver a notification to a device user in a communication network, as follows.

The notification manager 800 is configured to obtain and save a notification targeted to the device user. This operation may be performed by an obtaining module 800A in the notification manager 800, e.g. in the manner described above for action 302. The obtaining module 800A could alternatively be named a receiving module or event module.

The notification manager 800 is further configured to detect an activity on a client device 802 associated with the device user. This operation may be performed by a detecting module 800B in the notification manager 800, e.g. as described above for action 304. The detecting module 800B could alternatively be named an activity module or monitoring module.

The notification manager 800 is also configured to deliver the saved notification to at least one preferred client device according to predetermined delivery

preferences, in reaction to the detected activity. This operation may be performed by a delivering module 800C in the notification manager 800, basically as described above for action 306. The delivering module 800C could alternatively be named a sending module or notifying module.

It should be noted that Fig. 8 illustrates various functional modules or units in the notification manager 800, and the skilled person is able to implement these functional modules in practice using suitable software and hardware. Thus, the solution is generally not limited to the shown structures of the notification manager 800, and the functional modules or units 800A-C therein may be configured to operate according to any of the features and embodiments described in this disclosure, where appropriate.

The functional modules or units 800A-C described above could thus be implemented in the notification manager 800 by means of hardware and program modules of a computer program comprising code means which, when run by the processor P causes the notification manager 800 to perform at least some of the above-described actions and procedures.

In Fig. 8, the processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units such as CPUs. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chip sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). The processor P may also comprise a storage for caching purposes.

Each computer program may be carried by a computer program product in the notification manager 800 in the form of a memory having a computer readable medium and being connected to the processor P. The computer program product or memory in the notification manager 800 may thus comprise a computer readable medium on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM), an Electrically Erasable Programmable ROM (EEPROM) or Flard Drive storage (FIDD), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the notification manager 800.

The solution described herein may thus be implemented in the notification manager 800 by a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the above embodiments and examples, where appropriate. The solution may also be implemented in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage product or computer program product.

While the solution has been described with reference to specific exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms“notification”,“notification manager”,“client device”, “notification event”,“event source” and“communication network” have been used throughout this disclosure, although any other corresponding entities, functions, and/or parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.

Claims

1. A method performed by a notification manager (200) for delivering a notification to a device user in a communication network (204), the method comprising: - obtaining (302) and saving a notification targeted to the device user,

- detecting (304) an activity on a client device (202A) associated with the device user, and

- delivering (306) the saved notification to at least one preferred client device according to predetermined delivery preferences, in reaction to the detected activity.

2. A method according to claim 1 , wherein the activity is detected when the communication network indicates that the client device is used so that delivery of notifications is triggered according to said delivery preferences.

3. A method according to claim 2, wherein the activity is detected by means of an Online Charging System, OCS connected to the communication network.

4. A method according to any of claims 1 -3, wherein said detected activity includes any of: making a call, sending a message such as a text message or a multimedia message, downloading data or content, browsing the web, accessing social media,

5. A method according to any of claims 1 -4, wherein the notification is obtained based on information from an event source (206) that operates to issue event-triggered notifications.

6. A method according to any of claims 1 -5, wherein the delivery

preferences are related to a set of multiple client devices (202) associated with the device user.

7. A method according to claim 6, wherein the delivery preferences require that the notification is delivered to the client device (202A) on which the activity is detected.

8. A method according to claim 6, wherein the delivery preferences require that the notification is delivered to a specific prioritized client device regardless of which client device the activity is detected on.

9. A method according to any of claims 1 -8, wherein the delivery

preferences are set or updated (300) in response to input received directly from the device user or from a client agent (208) to which the device user has provided input.

10. A notification manager (800) arranged to deliver a notification to a device user in a communication network, wherein the notification manager (800) is configured to:

- obtain (800A) and save a notification targeted to the device user, - detect (800B) an activity on a client device (802A) associated with the device user, and

- deliver (800C) the saved notification to at least one preferred client device according to predetermined delivery preferences, in reaction to the detected activity.

11. A notification manager (800) according to claim 10, wherein the notification manager (800) is configured to detect the activity when the

communication network indicates that the client device is used so that delivery of notifications is triggered according to said delivery preferences.

12. A notification manager (800) according to claim 11 , wherein the notification manager (800) is configured to detect the activity by means of an Online Charging System, OCS connected to the communication network.

13. A notification manager (800) according to any of claims 10-12, wherein said detected activity includes any of: making a call, sending a message such as a text message or a multimedia message, downloading data or content, browsing the web, and accessing social media.

14. A notification manager (800) according to any of claims 10-13, wherein the notification manager (800) is configured to obtain the notification based on information from an event source (206) that operates to issue event-triggered notifications.

15. A notification manager (800) according to any of claims 10-14, wherein the delivery preferences are related to a set of multiple client devices (202) associated with the device user.

16. A notification manager (800) according to claim 15, wherein the delivery preferences require that the notification is delivered to the client device on which the activity is detected.

17. A notification manager (800) according to claim 15, wherein the delivery preferences require that the notification is delivered to a specific prioritized client device regardless of which client device the activity is detected on.

18. A notification manager (800) according to any of claims 10-17, wherein the delivery preferences are set or updated (300) in response to input received directly from the device user or from a client agent (208) to which the device user has provided input.

19. A computer program comprising instructions which, when executed on at least one processor in a notification manager, cause the at least one processor to carry out the method according to any one of claims 1 -9.

20. A carrier containing the computer program of claim 19, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.