TO A DEVICE USER

Technical field

The present disclosure relates generally to a method and a notification manager, for delivering a notification 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 any entity or function that issues or otherwise triggers notifications towards client devices. Fig.

1 illustrates schematically how notifications N from an event source 100 can be distributed to various client devices 102 over a communication network 104, where the client devices 102 are associated with a device user.

In this description, the term“client device” is used to represent any communication device, either 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, traditional fixed

telephones, 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.

Device users of today typically own and/or use not just one device but a number of devices which are capable of receiving notifications. A device user is able to configure personalized preferences related to delivery of notifications, which may include specifying telephone numbers, e-mail addresses, web addresses, etc., of various devices associated with the device user, as delivery destinations for notifications, which may also be referred to as“delivery channels”. Such preferences may further dictate that different types of notifications should be delivered to different devices, and possibly also depending on the time of day or week as well as urgency if applicable. For example, the preferences may require that bills should be sent to an e-mail address while booking reminders and low balance notifications for a prepaid subscription should be sent by SMS to a mobile phone number.

However, it may sometimes happen that a delivered notification is not noticed by the user, because he/she has not watched or observed the device of delivery, and/or a client channel that was used for the delivery, for a while. The user may then complain to the network operator that no notification has been received even if it actually has been delivered according to the device user’s preferences. This can be avoided by delivering all notifications to all of the user’s devices and client channels to ensure that he/she notices at least one of them. But this solution creates much network traffic and the user also have to manage a potentially large amount of delivered notifications on all devices. Another possibility is to deliver the notifications to a device that is currently used for a session, such as an in-band notification during an ongoing voice call. The latter option requires an ongoing session, though, and cannot be used if the call is finished or when no session is currently ongoing.

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 that may be performed by a notification manager is provided for delivering a notification to a device user in a communication network. In this method, the notification manager detects user activities on a set of client channels associated with the device user, and saves the detected user activities as usage history of the device user. When a

notification targeted to the device user is obtained, the notification manager determines a target client channel in the set of client channels based on said usage history, and the notification is then delivered to the device user on the determined target client channel.

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 detect user activities on a set of client channels associated with the device user, and to save the detected user activities as usage history of the device user. When obtaining a notification targeted to the device user, the notification manager is configured to determine a target client channel in the set of client channels based on said usage history, and to deliver the notification on the determined target client channel.

When using either of the above method and notification manager, it is an advantage that the notification can be delivered on a client channel that is likely to be noticed by the device user, e.g. on the latest used client channel or on a channel that the user has a habit of using at a certain time of day and/or week, according to the usage history. Thereby, the risk for unnoticed notifications can be reduced.

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 comprising instructions which, when executed on at least one processor in the above notification manager, cause the at least one processor to carry out the method described above. A carrier is also provided which contains the above computer program, 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 that notifications are distributed to client devices.

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 related to a notification manager may be employed in practice, according to further example embodiments. Fig. 6 is a signaling diagram illustrating an example of how preferences may be set, according to further example embodiments.

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

Fig. 8 is a flow chart illustrating a more detailed procedure for selecting a target device, according to further example embodiments.

Fig. 9 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 increase the likelihood that a delivered notification will be noticed by a device user targeted by the notification, where a set of client channels are associated with the device user, by delivering the notification on a client channel that is most likely to be monitored by the user. In this description, the term“client channel” should be understood as a

communication means that could be a particular client device, or a messaging application such as e-mail or similar, or some publishing application such as a platform for social media, or any relevant combination of the above. It should be noted that messaging and social media can often be used on more than one device, and sometimes even on all of the client’s devices. For example, SMS is typically tied to a particular device, whereas an email address may be accessible on multiple devices, depending on the user’s settings. Social media is typically accessed over the Internet and can serve as a client channel in this context not tied to any particular client device(s).

For example, the user’s most recent activity may have been a voice or video call using a particular device, and in that case this device is selected as client channel for delivering the notification. In another example, the user’s most recent activity may have been made on some social media platform such as Facebook or Instagram, and in that case that social media platform can be selected as the client channel for delivery. In a third example, the user’s most recent activity may have been sending an e-mail, and in that case the e-mail application can be selected as the client channel for delivery by sending the notification in an e-mail. Throughout this description, the term client channel could be substituted by “communication means”.

This solution can thus be employed to serve a device user with notifications by finding the most suitable client channel on which the user has recently performed some activity, such as making a call, sending a message, accessing social media or downloading some information, to mention a few non-limiting but illustrative examples of detectable user activities. The notification may then be delivered on the latest used client channel which is thus the most likely channel to be noticed by the device user at the moment. Thereby, the risk for unnoticed notifications can at least be reduced. In this description, the term“client” could basically be used as a synonym for device user. The above 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. However, 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 the communication scenario in Fig. 2.

In this example, a device user owns and/or operates a set of client devices 202, which may include, without limitation, a mobile phone such as a smartphone connected to a wireless network, a laptop computer and a tablet both connected to a WiFi access point, a home telephone and a stationary computer both connected to a fixed network such as a Public Switched Telephone Network, PSTN, and so forth. The client devices 202 are included in a set of client channels associated with the device user which set may further include other communication means such as messaging and social media. It is thus generally said herein that a set of client channels 202 are associated with the device user.

Three such different client devices 202 are schematically shown in the figure as examples of client channels. An example communication network 204 is also shown. The user may, at different times, perform activities on any of these devices 202. Furthermore, various different types of applications and platforms may be used in activities on the devices 202. It was mentioned above that messaging applications, publication applications and social media platforms may be employed in user activities on the devices, and the term client channel is used herein to denote one or more of a client device, a messaging application, and a platform for social media. In the case of messaging, the client channel may be defined by an email address or an SMS reception address such as a telephone number.

A first action 2:1 illustrates that the user performs some activity on one of the client devices, 202A, which activity is detected by the notification manager 200 when reported by a communication network 204 used by the device 202A, in a following action 2:2. It should be noted that the other client devices 202 may be operable to communicate over the same network or over any other network(s) and connection(s) for communication, and the solution is not limited in this respect. It is assumed that the network 204 used is capable of somehow making the notification manager 200 aware of user activities resulting in communication over the network. This could be detectable e.g. through a charging or billing function in the network and the notification manager 200 may subscribe to charging events or the like from the charging or billing function.

When detecting the activity, the notification manager 200 further stores and/or updates a usage history by adding the latest activity on the device 202A, in another action 2:3. Said usage history may contain information about the detected activity such as time, type of activity, used device, used application or platform, duration of the activity, and so forth. The usage history can be updated repeatedly whenever activities are detected and logged, and may thus further contain such information about any number of earlier detected usage activities. Thereby, the user’s activity behavior on his/her client channels can be traced and analyzed for determination of which client channel is most likely to be noticed once a

notification is to be delivered according to the following actions.

At some point, a notification targeted to the user is triggered from an event source 206, which notification is received or otherwise obtained by the notification manager 200 in another action 2:4. For example, the event source 206 may issue or generate information that triggers a notification targeted to one or more device users, e.g. according to subscriptions to such notifications. The actual notification may be created by the event source 206 itself or by the notification manager 200 based on information from the event source 206, depending on implementation, and the solution is not limited in this respect.

The notification manager 200 then determines a target channel based on the usage history, in another action 2:5, for delivery of the notification. In this determination action, there are several possibilities that can be employed. As said above, the client channel on which the latest activity was detected may be chosen as the most likely noticed channel, e.g. provided that this activity was not too long ago.

Another possibility could be that the usage history reveals that a certain client channel is very likely to be used at a certain time of day and/or week. For example, it may be extracted from the usage history that the user spends time on his/her home computer (almost) every day essentially between 7.00 and 8.00 a.m. and also between 9.00 and 10.00 p.m. So if a notification arrives by 6.45 a.m., it can be delivered to the home computer as a target client channel likely to be noticed soon, which is not necessarily the latest used client channel.

Yet another possibility is that the latest logged activity on a client channel occurred quite long time ago, so that it may no longer be likely that the user still monitors this channel. If a certain preset duration has passed since the latest activity, a client channel may be chosen based on certain predefined preferences which have been configured for the user which may indicate preferred client channels for notification delivery depending on time of day/week. Such preferences may further indicate a first preferred channel, a next preferred channel, and so forth, independently of time of day/week.

Some non-limiting but illustrative examples and criteria were given above of how one or more target client channels could be determined for notification delivery based on the usage history and possibly also based on delivery preferences that have been defined for the device user. In this determination operation, the notification manager 200 may employ a predefined determining algorithm or the like which can be configured in any manner taking any number of factors into consideration. For example, the above-exemplified determination criteria may be combined, e.g. so that one criterion takes precedence over another, and so forth.

Flaving determined a target client channel for delivery of the notification obtained in action 2:4, the notification manager 200 accordingly delivers the notification to the target client channel 202A, in a final action 2:6. An example of how the solution may be employed in terms of actions performed by a notification manager such as the notification manager 200, is illustrated by the flow chart in Fig. 3 which will now be described with further reference to Fig. 2, although this procedure is not limited to the example of Fig. 2. Fig. 3 thus illustrates a procedure in the notification manager 200 for delivering a notification to a device user in a communication network 204. Some optional example embodiments that could be used in this procedure will also be described.

A first action 300 illustrates that the notification manager 200 detects user activities on a set of client channels 202 associated with the device user, which corresponds to action 2:2 of Fig. 2. In another action 302, the notification manager 200 further saves the detected user activities as usage history of the device user, which corresponds to action 2:3 of Fig. 2. In a practical

implementation, actions 300 and 302 are repeated whenever a user activity is detected, so that the usage history is constantly updated upon detection of activities on the user’s various client channels.

In another action 304, the notification manager 200 obtains a notification targeted to the device user, as also shown in action 2:4 of Fig. 2. In another action 306, the notification manager 200 determines a target client channel in the set of client channels based on said usage history, as also shown in action 2:5 of Fig. 2. In a final action 308, the notification manager 200 delivers the notification on the determined target client channel, as also shown in action 2:6 of Fig. 2.

Some further examples of embodiments that may be employed in the above procedure in Fig. 3 will now be described. In one example embodiment,

determining the target client channel in action 306 may comprise identifying the latest client channel on which a user activity has been detected according to said usage history. If the latest activity/client channel is used as a criterion according to the above embodiment, another example embodiment may be that said latest client channel is determined as the target client channel if the time since the latest client channel was used does not exceed a preset duration. An example of this embodiment has been described above. In further example embodiments, said set of client channels may include any of: one or more client devices, a messaging application, and a platform for social media, which channels have also been mentioned and explained above. It is naturally possible to have more than one messaging application and/or platform for social media and the solution is not limited in this respect.

In another example embodiment, delivery preferences may have been defined for the device user, and said determining a target client channel may in this case also be based on the delivery preferences. Some examples of how delivery

preferences may be employed in this context, have been described above. If the latter embodiment is used, another example embodiment may be that the latest client channel is determined as the target client channel when the latest client channel is indicated as preferred for delivery in the delivery preferences. In other words, the delivery preferences may require that the client channel chosen for notification delivery must be a preferred one. In another example embodiment, said preset duration may have been set in the delivery preferences.

In another example embodiment, at least some of the user activities may be detected in action 300 through charging or billing operations, which may be reported from a charging or billing function in the network used for communication in the detected activity. In another example embodiment, user activities may be detected in action 300 when receiving a usage report generated in the

communication network In another example embodiment, user activities may be detected in action 300 by means of an Online Charging System, OCS of the communication network.

In further example embodiments, said user activities detected in action 300 may include any of: making a call, handling a message such as a text message or a multimedia message, downloading or uploading data, browsing the web, and accessing social media.

In another example embodiment, the notification may be obtained in action 304 based on information from an event source 206 that operates to trigger notifications for device users. An example of a procedure when the solution is used will now be described with reference to the signaling diagram in Fig. 4 where the same reference numbers as for the notification manager 200, the client device(s) 202 and the event source 206 in Fig. 2 are used. A first action 4:1 illustrates that delivery preferences are set (i.e. configured) or updated in the notification manager 200 for a device user. This setup operation may be executed by the user on one of the client devices 202 in communication with the notification manager 200, or via a client agent 208 which communicates with the notification manager 200 on behalf of the user, as indicated by a dashed arrow. This operation is logged in the notification manager 200 as a client activity in an action 4:2 of updating the usage history for the user.

Action 4:3 illustrates that various client activities on the client devices 202 are detected by the notification manager 200 and the usage history is updated therein accordingly in another action 4:4.

At some point, the notification manager 200 receives information about an event from the event source 206 in an action 4:5, so that a notification can be obtained either directly in the received information or as generated based on the received information. The notification manager 200 then determines a suitable target client channel based on the up-to-date usage history, in an action 4:6, which

corresponds to actions 2:5 and 306. Several examples of how the target channel could be determined have been described above. The notification manager 200 then finally delivers the notification on the determined target client channel in an action 4:7. As mentioned above, it may be possible to deliver the notification on more than one client channel depending on how action 4:6 was executed.

It was mentioned above that the notification manager 200 may be implemented in a network management node such as a Business Support System, BSS, node of a wireless network. Fig. 5 illustrates an illustrative but non-limiting example of how a BSS node 500 may comprise various entities to realize the above-described functionality of a notification manager. The BSS node 500 may thus comprise the following functional components:

500A: Customer care This component can be used by customer care agents, in the figure indicated as client agent, 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 by updating notification preferences.

500C: Customer Management

This component can interact with the customer care and self-care systems and stores customer data such as client channel information and delivery preferences in a suitable data storage persistent data storage 500G.

500D: Usage history 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, as usage history in the data storage 500G. The stored charging-related events can be used by the customer care to view the customers’ call and account history. The charging-related events in the data storage 500G may be used for invoicing as well as for determining a target client channel for notification delivery.

500E: Charging and billing

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. The charging and billing component 500E can also act as a mediation function by collecting events from different network nodes defined by 3GPP. In this case, the charging function provides no rating and charging for the collected events, it just provides a mean to store detected client events as usage history in the data storage 500G. The charging and billing component 500E may be divided into a separate charging function responsible for the rating and charging, and a separate billing function responsible for invoicing and financial transactions. 500F: Notification Management

This component can transform events from various event sources into customer notifications. The transformation may be 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 usage history.

Fig. 6 illustrates an example of how delivery preferences may be configured in the notification manager 200 comprising the above-described components for notification management 500F, customer management 500C and data storage for usage history 500G. In a first action 6:1 , the user, through a client device 202, sets his/her delivery preferences in a message that is communicated to the customer management 500C. The setting of preferences is also logged as a client activity in the usage history 500G, in another action 6:2. The notification management 200 may further subscribe to any service activities that the user might perform on his/her client channels. Such service activities may, as mentioned above, include voice and video calls, communication of messages and data, and activities on social media platforms. Thereby, the notification manager 200 is prepared to detect activity and deliver a notification as follows.

Fig. 7 illustrates an example of how detection of an activity and delivery of a notification may be handled by the notification manager 200, as a continuation of Fig. 6. In an action 7:1 , the user performs an activity on a client device 202A. As a result, the network 204 generates a charge event for the user which is received by the charging/billing function 500E, in an action 7:2. The charging/billing function 500E then reads user information from the customer management 500C, in another action 7:3, and performs a rating and charging operation in a further action 7:4. The charging function 700 also issues an activity report for the user to the customer management 500C, in an action 7:5, which is logged as a user activity by updating the usage history 500G in an action 7:6.

The following actions illustrate how an event that triggers a notification to the user may be handled by the notification manager 200. The event source 206 issues information about the event which information arrives at the notification

management 500F in an action 7:7. The notification management 500F then reads delivery preferences from the customer management 500C in an action 7:8 and creates a suitable notification from the event information and based on the read delivery preferences, in another action 7:9.

The notification management 500F further retrieves and reads logged user activities in the usage history 500G in an action 7:10, and determines a suitable target client channel for delivery of the notification based on the usage history, in another action 7:11. In this example, the client device 202A is determined as the client channel that is most likely to be monitored by the user. The notification management 500F accordingly delivers the notification to the client device 202A, in a final action 7:12.

It was mentioned above that the latest used client channel may be determined as the target client channel if the time since it was used does not exceed a preset duration. A more detailed procedure for selecting a target device when this criterion is employed, will now be described with reference to the flow chart Fig. 8a and with further reference to Fig. 2. In a first action 800, the notification manager 200 creates or otherwise obtains a notification to be delivered to the user, which corresponds to actions 2:4 and 304. The notification manager 200 then retrieves the saved usage history and identifies the latest used client channel and its time of usage in an action 802.

Next, it is determined whether the time that has passed, i.e. duration, since the latest usage exceeds a preset duration threshold or not, in an action 804. If not, it is concluded that the user is likely to still be monitoring the same client channel which is therefore selected a target client channel for the notification, in an action 806. On the other hand, if the preset duration has expired, i.e. the time passed since usage exceeds the present duration threshold, a target client channel is selected for the notification based on the user’s delivery preferences, in an action 808. Some examples of criteria for channel selection that may be defined in the delivery preferences have been described above. In either case, the notification is delivered in action 810 on the target client channel, either selected in action 806 or in action 808 depending on the outcome of action 804.

The block diagram in Fig. 9 illustrates a detailed but non-limiting example of how a notification manager 900 may be structured to bring about the above-described solution and embodiments thereof. In this figure, the notification manager 900 may be configured to operate according to any of the examples and embodiments of employing the solution as described herein, where appropriate. The notification manager 900 is shown to comprise a processor“P”, a memory“M” and a communication circuit“C” with suitable equipment for transmitting and receiving information and messages in the manner described herein.

The communication circuit C in the notification manager 900 thus comprises equipment configured for communication using a suitable protocol for the communication depending on the implementation. The solution is however not limited to any specific types of messages or protocols.

The notification manager 900 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow chart in Fig. 3 and as follows.

The notification manager 900 is arranged to deliver a notification to a device user in a communication network. The notification manager 900 is configured to detect user activities on a set of client channels 202 associated with the device user. This operation may be performed by a detecting module 900A in the notification manager 900, as also illustrated in action 300. Examples of client channels and user activities have been presented and explained above. The notification manager 900 is also configured to save the detected user activities as usage history of the device user, e.g. in a suitable data storage 900F at the notification manager 900. This operation may be performed by a saving module 900B in the notification manager 900, as also illustrated in action 302.

The saving module 900B could alternatively be named a storing module or logging module.

The notification manager 900 is further configured to obtain a notification targeted to the device user, e.g. as issued from an event source 206. This operation may be performed by an obtaining module 900C in the notification manager 900, as also illustrated in action 304. The obtaining module 900C could alternatively be named a notification module.

The notification manager 900 is further configured to determine a target client channel in the set of client channels based on said usage history which may be retrieved from the data storage 900F. This operation may be performed by a determining module 900D in the notification manager 900, as also illustrated in action 306. The determining module 900D could alternatively be named a logic module.

The notification manager 900 is further configured to deliver the notification on the determined target client channel 202. This operation may be performed by a delivering module 900E in the notification manager 900, as also illustrated in action 308. The delivering module 900E could alternatively be named a sending module.

It should be noted that in this figure, 202 schematically denotes any client channel(s) in the set of client channels, and the determined target client channel 202 may be the latest client channel used by the user, or it may be another channel which the user habitually uses at the time of day/week the notification is to be delivered, as explained above. It is also possible that determining module 900D is configured to determine more than one target client channel and that the delivering module 900E is configured to deliver the notification to all the

determined target client channels. It should be noted that Fig. 9 illustrates various functional modules in the notification manager 900 and the skilled person is able to implement these functional modules in practice using suitable software and hardware equipment. Thus, the solution is generally not limited to the shown structure of the notification manager 900, and the functional modules therein may be configured to operate according to any of the features, examples and embodiments described in this disclosure, where appropriate.

The functional modules 900A-E described above may be implemented in the notification manager 900 by means of program modules of a computer program comprising code means which, when run by the processor P causes the

notification manager 900 to perform the above-described actions and procedures. The processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chips 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.

The computer program may be carried by a computer program product in the notification manager 900 in the form of a memory having a computer readable medium and being connected to the processor P. The computer program product or memory M in the notification manager 900 thus comprises 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 M may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the notification manager 900.

The solution described herein may be implemented in the notification manager 900 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 at the notification manager 900 in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

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”,“client channel”,“user activity”,“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.