Patent Application
20120284208
The technical field relates to radio and/or wireless communications, and more particularly, to notification delivery systems and methods.
Mobile networks are becoming increasing ubiquitous in society. Initially, mobile networks were used simply for voice communication. However, more recently other types of communication services have been adapted to mobile networks. Text messages, music and video streaming, email, web browsing, and others have all been adapted to work with mobile networks. This increase in breadth of service has coincided with society's increased reliance on the connectivity provided by mobile networks. For example, in the past, a customer may have watched a movie over a cable connection, now the movie may be sent to the user over a mobile network.
In certain instances, mobile network service to users may be provided by allocating a set amount of resources per user. For example, a user may pre-pay for 300 minutes, 20 texts, and/or 50 megabytes of data traffic for a given month. However, unless a user is scrupulous about keeping usage records, the user may be unaware of when (or if) the “cap” for that month has been reached. Thus, a user may continue to use the mobile service while being unaware of possible overage charges. This can lead to an unpleasant surprise when the user receives the monthly bill.
Mobile network capacity is typically unaffected by the time of day or day of the week. In contrast, the usage of mobile network resources may be tied to a particular time of day (e.g., increased usage during the daytime). Such a usage pattern inefficient uses the total capacity available in the mobile network. On way of addressing the “unevenness” in network utilization is to implement a management solution that aims to change subscriber call patterns in a mobile network. A conventional solution may seek to decrease network traffic at peak times and increase network traffic during quiet times. This may be accomplished by adjusting rates based on the time of day or the location of a call/data session. Such a solution may be implemented to help operators more efficiently use their network capacity.
A conventional technique for addressing the sticker shock and/or the network resource problem discussed above is to provide users with more information and/or incentive relating to their account and current network status. This is typically done through sending the user a notification to the device of the user. Examples of notifications include: 1) that a bonus has been given (“You have sent 10 SMS's in last 24 hours and you have received 2 free MMS's that can be used within the next 48 hours”; 2) the cost rate is announced (“Your current rate is 0.25 USD/minute”; 3) a limit has been passed (“Account balance is below 5 USD—refill now to avoid empty”); or 4) a rate has been changed (“Current rate has changed from 0.25 USD/min to 0.05 USD/min”) Such notifications my provide users with more up-to-date information on the status of their account (e.g., point 3) and may help to shape usage patterns (e.g., point 4).
Notifications are typically delivered through USSD, SMS or, if applicable, call announcements or IP based notification solutions. Notifications are usually triggered or sent based on a condition that is checked by the mobile communications network. One such condition may be the start of a phone call. Here, the user is notified of the current rate or applicable discounts. Next, when there is a change in a condition such as time, location, discount, etc, a new notification may be sent relating to the changed discount/rate/etc.
While the above system does provide a notification, it may not be sufficient in certain instances. For example, such an implementation may not help in providing a service provider with tools to efficiently manage network resources. Furthermore, such implementations may not be as helpful to users in certain instances either because the wrong information is provided and/or too much information is provided to a user (e.g., too many notifications). Accordingly, it would be desirable to provide systems and/or methods for providing improved notifications to users and their associated user equipment devices.
The inventors of the instant application determined that notifications based only on fixed consumption patterns may be less useful for users/service providers in certain instances. For example, a user may not be interested in notifications when the cost to the user is low. The low cost may be a result of low consumption or a low price per consumption charge (e.g., one dollar per megabyte). Conversely, a user may be more interested when the amount of data transferred is high and results in a higher overall cost for the user. Thus, certain example embodiments may send notifications based on the significance of the current cost to that user.
In certain example embodiments, notifications sent to a user may be sent when consumption or a value derived from consumption exceeds a threshold. The consumption value may be based on a tracked amount of resources of a time period.
In certain example embodiments calculated consumption values may be compared against threshold values that are predetermined or dynamically created. In certain example embodiments, calculated consumption values are compared against other calculated consumption values.
Certain example embodiments store a history of tracked resource usage and use the tracked history to compare multiple different calculated consumption values.
In certain example embodiments, a message may be suppressed by suppression criteria. The suppression criteria may result in decreasing the overall number of messages that are processed by a mobile network and sent to a customer.
In certain example embodiments, triggered notification events may be ordered according to a prioritization order.
In certain example embodiments, an operator may implement an active/passive service distinction between the consumption of resources.
In certain example embodiments, a user may receive notifications as to how to continue to use the mobile service based on personal preferences (e.g., preferences that are defined by the user of the mobile service provider).
Certain example embodiments provide a computer implemented method for providing a notification to a user equipment device. Mobile network resources consumed by a first user equipment device are tracked. A rate is calculated based on the track resources and a time period. The calculated rate is compared against another rate. Based on the comparison, a notification event is triggered. Based on the triggered notification event a notification message is sent to a second user equipment device.
In certain example embodiments the first and second user equipment devices are the same device. In certain example embodiments, the first and second user equipment devices are different user equipment devices.
Certain example embodiments provide a computer implemented method for sending a notification to a user. Resources are tracked or otherwise determined over first and second time periods. Resource usage relating to the first and second time periods are assigned predetermined or dynamically determined levels of consumption. First and second prices per consumption over the first and second time periods are assigned to respective levels. Based on the levels of consumption a first state and a second state are determined. A notification event is triggered based on the difference between the first state and the second state. A notification is sent to a user equipment device based on the notification event. The method may be embodied in a non-transitory computer readable storage medium.
Certain example embodiments provide a node that is configured to communicate with a communications network. The node may include a processing system where the processing system is configured to perform a method of sending a notification to a user.
Certain example embodiments may facilitate user knowledge of resource usage and/or improved network management of mobile resources.
In the following description, for purposes of explanation and non-limitation, specific details are set forth, such as particular nodes, functional entities, techniques, protocols, standards, etc. in order to provide an understanding of the described technology. It will be apparent to one skilled in the art that other embodiments may be practiced apart from the specific details disclosed below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc. are omitted so as not to obscure the description with unnecessary detail. Individual function blocks are shown in the figures. Those skilled in the art will appreciate that the functions of those blocks may be implemented using individual hardware circuits, using software programs and data in conjunction with a suitably programmed microprocessor or general purpose computer, using applications specific integrated circuitry (ASIC), and/or using one or more digital signal processors (DSPs). The software program instructions and data may be stored on computer-readable storage medium and when the instructions are executed by a computer or other suitable processor control, the computer or processor performs the functions.
Thus, for example, it will be appreciated by those skilled in the art that block diagrams herein can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in a non-transitory computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
The functions of the various elements including functional blocks, including but not limited to those labeled or described as “computer”, “processor” or “controller” may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being hardware-implemented and/or computer-implemented, (e.g., machine-implemented).
In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC), and (where appropriate) state machines capable of performing such functions.
In terms of computer implementation, a computer is generally understood to comprise one or more processors, or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer, processor, or controller, by a single shared computer, processor, or controller, or by a plurality of individual computers, processors, or controllers, some of which may be shared or distributed. Moreover, use of the term “processor” or “controller” shall also be construed to refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
The technology may be used in any type of cellular radio communications (e.g., GSM, CDMA, 3G, 4G, etc). For ease of description, the term user equipment (UE) encompasses any kind of radio communications terminal/device, mobile station (MS), PDAs, cell phones, laptops, etc.
Referring now more particularly to the drawings in which like reference numerals indicate like parts throughout the several views.
When the consumption calculator 102 receives/retrieves tariff data 106 and usage data 108, one or more calculations may be performed. Consumption calculator 102 may include calculations 1, 2, and 3 that are different types of calculations that use the tariff data and/or usage data. Example calculations according to certain example embodiments are explained in greater details below. Also, as explained in greater detail below, the calculations may be combined to form yet further calculations (e.g., Calculation 1 AND Calculation 2).
Based on calculations 1, 2, and/or 3 the consumption calculator may communicate with a notification trigger subsystem that may operate to determine what notifications to send, where to send the notifications, to assist in the creation of the notifications, etc. The notifications trigger subsystem 104 may then facilitate communication with a target UE.
The charging system may operate in conjunction with, or a part of, of a mobile communications network.
Core network 208 provides various core functionalities for a communications network of a service provider. It will be appreciated that core network 208 may include numerous separate core networks that may interface with each other. The core network 208 may provide various services. Such services may include, for example: 1) an authentication capability to determine whether a UE requesting a service from the communication network is authorized to do so; 2) a call routing or switching functionality that directs and/or determines how calls are routed/switched within the communications network and/or other networks; 3) communication between nodes of the core network 208 and/or RAN layer; and 4) statistic gathering capability such as, for example, the number of calls being handled, the number of subscribers attached to the network, the type of services being used, or the like.
Base stations 214A, 214B, 214C, and 214D (e.g., NodeBs) facilitate mobile radio communications for a network operator of core network 208 to UEs 216A, 216B, 216C, and 216D that are subscribed to the network operator's mobile network. The individual UEs may obtain service through a base station that facilitates mobile communications service with a given geographical area. Thus, UE 216A obtains service (e.g., over allocated radio resources through techniques such as TDM or FDM) through base station 214A; UE 216B obtains service through base station 214B; UE 216C obtains service through base station 214C; UE 216D obtains service through base station 214D.
It will be appreciated that the example network architecture of
In certain example embodiments, the core network 208 may communicate with a charging node 210 to facilitate notification delivery (e.g., when to send a notification and/or where to send a notification). In certain example embodiments, the charging node may be a node within the core network.
In certain example embodiments, usage is monitored on a per device level. For example, UE 216A is monitored by the core network 208 and the core network 208 reports usage of network resources to the charging node 210. Based on this information, notifications may be triggered that are then sent to the same UE being monitored, UE 216A. In certain example embodiments, the core network and/or the charging node may aggregate the usage of multiple UEs. For example, UEs 216A and 216B may acquire service from the service provider under the same service plan. Thus, the core network may communicate the usage data of both UE 216A and UE 216B to the charging node. Based on the combined usage data, notifications may then be sent to one or all of the UEs associated with the service plan. For example, a notification may be configured to be sent to the “primary” UE associated with the service plan (e.g., the head of household for a family plan). Alternatively, notifications may be sent to all, or a subset, of the UEs under the service plan. In certain example embodiments, the usage of one UE may be monitored and notifications may be sent to another UE based on the monitored usage. For example, UE 216A may consume a large amount of data over a short period of time. Core network 208 may report this usage to the charging node 210. The charging node 210 may perform calculations based on the reported usage, and then determine that a notification should be triggered. An option may be sent to send all notifications related to UE 216A to UE 216B. Alternatively, or in addition, the type of triggered notification may determine the destination (e.g., a UE) of the notification. In certain example embodiments, multiple different UE's may be assigned to multiple different types of notifications. For example, a triggered decrease notification may be sent to 216A; a triggered increase notification may be sent to UE 216B; and/or a triggered continue notification may be sent to UE 216C. It will be appreciated that other embodiments may be implemented in determining where and/or how notifications may be sent to various UEs.
Next, the reservation process may include a check in the charging system. This check may cause a traversal to be performed through a tariff structure in step 402. The output from this check may be related to the cost per resource. Next, in step 404, fixed notifications related to account thresholds, account limits, rate, and/or discounts may be checked. After checking for fixed notifications, consumption dependant notifications may be checked in step 406. In certain example embodiments, the output from the consumption dependent check may be a measurement related to resources consumed over time. After the above notification steps, the triggered/detected notifications may be analyzed in step 408. The analysis may include an evaluation of output from the consumption dependant notification check, suppression of low consumption values, and/or commands to send notifications related to high consumption values. When a command to send a notification is triggered the notification (e.g., the notification message) is sent in step 410.
In certain example embodiments, one or more of the above steps may be omitted depending on design or other considerations. For example, step 404, may be omitted if fixed notifications are not to be detected.
In certain example embodiments, notifications may depend on the cost rate (resource usage) of a service over time. The cost rate may depend on the price plan and/or discount of a service but may also depend on the “intensity” of certain chargeable parameters due to usage behavior.
As noted above, there may be multiple different types of calculations for detecting consumption dependent notification requests.
Check consumption over last reservation period 502 uses input from a report resource usage report (e.g., the latest report) and may return a resulting value (e.g., consumed resource/consumption report time). This method may check how fast a given reservation was consumed. The output may be dependant on reservation amount (e.g., 5 MB vs. 500 MB) and allowed reservation times. In certain example embodiments, using this type of consumption check may facilitate detection of fast and/or drastic changes in usage rates. For example, consumption of 2 megabytes over a 4 second reservation may indicate a drastic change in the consumption of resources and trigger an associated notification.
Check consumption average over predefined time 504 uses input from a specified number of report resource usage reports that fit in the predefined time frame. Alternatively, in certain example embodiments, the time frame may be dynamically determined. In certain example embodiments, a sliding average is calculated for the time frame time (explained in more detail below). In certain example embodiments, this check may detect changes that impact ongoing sessions. For example, a virus program may start to download data without user's knowledge. Further, this consumption check may facilitate notifications that alert a user to the possibility of postponing a transfer until a later or cheaper period.
Check consumption average over total session time 506 uses input from all resource usage reports over a given session. Accordingly, an average is calculated for the session. This check may detect long term high consumption. For example, the session average may show that operating at this rate correspond to a user spending $20 or more per 24 hours in an ongoing session.
Check consumption average over total account time 508 uses input from all resource usage reports for all sessions and services and a predefined time. Thus, an average is calculated for the account. This check may detect long term high consumption per account. For example, an account average that shows at a calculated rate the user will spend $20 or more per 24 hours including all services.
In certain example embodiments, a calculated average can be weighted so that older data points may not influence the resulting calculation as much as more recently acquired values. For example, in the case of interrogation based averages, a discrete weighting scheme can be applied. In the case of a session or time based average, either a continuous weighting function can be applied or a discrete function can be applied (e.g., if the session or time span is discretized first). In certain example embodiments, the weight may be arithmetically decreasing, exponentially decreasing, or a variation of some other calculation.
Furthermore, as explained below, the consumption checks of
In one example embodiment the following consumption checks may be performed: 1) 502 AND 504; 2) 504 AND 506; 3) 506 AND 508; 4) 508 AND 502 (where “AND” is a Boolean operator). Each of these example calculations may be compared to a threshold value in step 602. Thus, for example, the calculation related to 502 and the calculation related to 504 may each be compared to respective thresholds. Based on the threshold determination in step 602, a decision may be made to send a notification in step 604 or not to send a notification in step 606. In certain example embodiments, a threshold determination may be successful if either of the calculations is above a threshold (e.g., an OR Boolean operator). Certain example embodiments may use other types of logic to combine calculations (e.g., XOR).
As shown above, multiple different threshold calculations may be performed. Accordingly, in certain example embodiments, the order of the different calculations may be adjusted. Different orderings may function to prioritize the multiple threshold determinations. For example, if the first option is successful and sends a message, the next three determinations may be skipped. Accordingly, different notifications tied to different types of threshold calculations may be ignored. This may allow only “important” notification to be sent out rather than notifications that are not important. Alternatively, the next determination may be performed and the associated notification sent out. In certain example embodiments, the threshold determinations may be stored for later triggering. In certain example embodiments, the priority of the threshold determinations may be configured by a user and/or an administrator. For example, a user may setup different types of notifications based on individual preferences. Alternatively, or in addition, an administrator (e.g., of a service operator) may determine the priority of threshold determinations.
Certain example embodiments may perform consumption calculations based on active/passive service.
As discussed herein, a notification may be related to a calculated consumption rate (e.g., as shown in
As noted above, usage rates may be based on a usage/time calculation.
As discussed herein, notifications may depend on a calculated utilization rate. In certain example embodiments, the utilization rate may also be based on the price of the service (e.g., the tariff rate or price per unit consumed). This information may assist a user in using (or planning) the use of resources of a mobile service provider. It may also help a service provider to better manage network resources.
In certain example embodiments, the rate may be used to determine transitions between high/low cost and/or high/low utilization. Thus, a change in rating (e.g., a calculated consumption or the like) that is a significant change in cost rate for the user may trigger a notification with a message informing the user of the changed conditions with a recommended course of action. Certain example embodiments may include different types of actions. Each of the actions may have different sub-actions. The sub-actions may be related to how transitions between two or more calculated consumptions are analyzed. Below are example actions that may be used according to certain example embodiments.
Action 1: “Decrease” (At high usage at high prices)
Action 2: “Wait” (At low usage at high prices)
Action 3: “Increase” (At low usage at low prices)
Action 4: “Continue” (At high usage at low prices)
Certain notifications may be suppressible depending upon the changed property. For example, the “continue” message may be sent when the price has decreased and the volume remains the same. However, an increase in volume combined with the same or similar price may result in a notification system suppressing (e.g., not triggering) the “continue” notification.
Usage may include different types of usage. For example usage can be volume in a mobile network data session, length of a phone call, or other usages, such as usages in a congestion pricing network (e.g., electricity usage—if rated in a charging system). Cost rates according to certain example embodiments may depend on the price of a service and the usage of the service for a specific time period. For example, if the price for downloading data is $3 per megabyte downloaded and the user consumed 5 megabytes in 10 minutes the cost rate may be calculated to be $1.5 per minute. Accordingly, notifications may be triggered based on context aware thresholds that are related to resource utilization over a sampling interval (e.g., a reservation period, session period, etc).
As discussed herein, resource usage by a UE, account, or other element may be monitored by a charging system and/or other functionality within the core network of a mobile network. Accordingly, in step 1300 of
Based on the calculated price and consumption in steps 1302 and 1304, a state may be determined in step 1306. In other words, the individual methods e.g., 1-4 for A and B discussed above may be individually compared. Thus, the combination of A and B may decide the currently classified state. For example, in
In certain example embodiments, the number of individual levels for A and for B may be two. However, certain example embodiments may have more levels (e.g., 5 levels). This increased number of levels may allow a service provider greater granularity over the when notifications are sent to a user. Additionally, while the number of levels shown in
After calculating a state change, a notification may be selected (or determined) based on the state change and level of state change in step 1310. For example, the above described messages associated with notifications may be triggered based on the current state, the prior state, and/or the degree of change between the states.
Next, the triggered notifications may be suppressed in step 1312. This may include prioritization criteria to rank notifications. Thus, notifications that are not as important may be suppressed in favor or more important notifications. Alternatively, or in addition, the triggered notification list may be compared with a message suppression list. The suppression list may include notification messages that a user does not wish to be sent to an associated UE. This list may be manually updated by the service provider and/or users. Further, in certain example embodiments the list may be dynamically generated. For example, a notification may be added to the suppression list if the particular notification has been sent to the user recently. If a notification is not suppressed, it may be passed off to the send notification step 1316 (e.g., to send a notification message). Alternatively, the message may be suppressed, and not sent, in step 1314.
As discussed above, a state change may be determined by classifying at least two calculations in a state table. In certain example embodiments, state determinations may be made with respect to a value (e.g., the cost of resources used over time) calculated from the consumption and the price per unit.
Certain example embodiments may include multiple different types of calculations. These calculations may include: F1) Last reservation period (short time perspective); F2) Average over predefined time (sliding average, avoiding bursts); F3) Average over total session (long time perspective; and F4) Average over total account time (historical perspective). The calculations may be used individual or in combination. Based on the above calculation, a state may be determined in step 1504.
After determining the current state, a state change may be calculated in step 1506. For example, illustrative state changes are shown as arrows 1400, 1402, 1404, and 1406 in
The selected notification may be compared against a suppression list or subject to a suppression procedure in step 1510 to determine whether the notification should be sent in step 1512 or suppressed in step 1514. In certain example embodiments, the message not suppressed may then be subjected to an additional prioritization procedure that may further determine which messages are of a higher priority. Messages with lower priorities may not be sent (e.g., to avoid bombarding the customer with multiple messages) while higher priority messages are sent.
Certain example embodiments may detect cost rate changes and apply notifications based on the change in cost rate. The notifications may be suppressed if the detected change is below a certain threshold.
During a communication session the core network may report the usage of resources to a charging system in step 1800. Further, information from prior reports may be stored by the charging system. Thus, in step 1802 an old cost rate may be determined over time period 1604. In step 1804 a new cost rate may be determined over time period 1606. As with the above consumption calculations, different methods of calculating consumption or rate of consumption may be used. Some example methods may include: 1) Last reservation period (short time perspective); 2) Average over predefined time (sliding average, avoiding bursts); 3) Average over total session (long time perspective); 4) Average over total account time (historical perspective). These methods, and other illustrative methods, may be used individually or in combination.
The calculated values from steps 1802 and 1804 may be used to evaluate a change in cost rate in step 1806.
Returning to
The priority ordering may be combined with suppression of notifications in step 1810. A suppression list may be maintained by the service provider such that before each notification is sent, it is first compared with a suppression list. If a notification is listed on the suppression list it may be removed or prevented from being sent in step 1812. Alternatively, the notification may be sent in step 1814.
As described above, certain example embodiments may derive notifications based on state transitions between or to/from different states.
As discussed above, certain example embodiments may be implemented using a machine, e.g., electronic circuitry or a processing system in the form of a computing system or hardware circuit.
Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. For example, although certain example embodiments may be described in relation to a particular type of telecommunication architecture, it will be appreciated that techniques described herein may be applied to other types of telecommunication architectures—e.g., GSM, Edge, CDMA, IP based systems, etc. None of the above description should be read as implying that any particular element, step, range, or function is essential such that it must be included in the claims scope. The scope of patented subject matter is defined only by the claims. The extent of legal protection is defined by the words recited in the allowed claims and their equivalents. All structural and functional equivalents to the elements of the above-described preferred embodiment that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the technology described, for it to be encompassed by the present claims. No claim is intended to invoke 35 U.S.C §112, 6th paragraph unless the words “means for” or “step for” are used. Furthermore, no embodiment, feature, component, or step in this specification is intended to be dedicated to the public regardless of whether the embodiment, feature, component, or step is recited in the claims.
