WO2017003871A1

WO2017003871A1 - System and method for notification to a user as resource limits are reached

Info

Publication number: WO2017003871A1
Application number: PCT/US2016/039287
Authority: WO
Inventors: Jeffrey METZGER
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2015-07-02
Filing date: 2016-06-24
Publication date: 2017-01-05

Abstract

Systems and methods are described for notifying a user of resource limits on a user device capable of executing a plurality of applications. In an exemplary method, cumulative use of a data resource by the user device is measured. A prediction is made regarding whether activation of an application is expected to cause cumulative use of the data resource to exceed a budgeted amount of data. In response to a prediction that activation of an application would cause cumulative use of the data resource to exceed a budgeted amount of data, an icon for the application is modified. For example, the icon may be greyed out to indicate the risk of exceeding the data budget. An access control may block the user from activating the application or may require acknowledgement, before activating the application, that the budget will potentially be exceeded.

Description

SYSTEM AND METHOD FOR NOTIFICATION TO A USER

AS RESOURCE LIMITS ARE REACHED

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims the benefit under 35 U.S.C. §119(e) from, U.S. Provisional Patent Application Serial No. 62/188,193, filed August 12, 2015, incorporated herein by reference in its entirety.

BACKGROUND

[0002] To prevent unexpected charges for excessive use of network resources, users of networked technology need to monitor and consciously limit their usage of those resources. However, those users may have limited conceptual understanding of activities that consume disproportionate amounts of network resources, and there is often no intuitive way for a user obtain information on the use of network resources. Given the wide array of different wireless network types with different costs and different data rates, even a knowledgeable user of network services may have difficulty making cost-effective decisions in managing his or her use of network resources. Even in connected networking environments, the service provider providing an internet connection may have different tariff schedules, performance characteristics, bandwidth reduction, and the like, as a function of which application is accessing remote resources, further complicating any efforts to manage and budget for network access charges.

SUMMARY

[0003] Embodiments of the present disclosure provide immediate notification to users if resource budgets of data usage (such as mobile data usage) are at, near, or anticipated to be exceeded by the use of an application on a currently available service. Resource constraints (financial or otherwise) imposed on the user's device are conveniently and intuitively presented to the user.

[0004] Embodiments disclosed herein leverage awareness of how budgets, account tariffs can be built into a management model or service. This information (both the budget and use against that budget) is made actionable to the user, particularly in grossly heterogeneous connectivity environments (subscription based, fee based, network as a service, free, etc.), in a simple and intuitive manner. Data use and connectivity options are continuously monitored, and determinations are made of whether a user terminal application or service is able to be initiated based on the wireless services available at the current moment in time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIG. 1A illustrates a view of a mobile device display under conditions of free Wi-Fi connectivity.

[0006] FIG. IB illustrates a view of the mobile device display of FIG. 1A under conditions in which a data budget has been reached or is expected to be reached.

[0007] FIG. 2 is a flow chart illustrating a method of determining icon modifications in some embodiments.

[0008] FIG. 3 is a flow chart illustrating a method of displaying predicted future connectivity in accordance with an embodiment.

[0009] FIG. 4 illustrates a view of a mobile device display under conditions in which network connectivity conditions are predicted to change.

[0010] FIG. 5 is a functional block diagram illustrating components of an exemplary system for modifying and displaying application icons in accordance with resource usage.

[0011] FIG. 6 illustrates a wireless transmit-receive unit (WTRU) on which some embodiments are implemented.

DETAILED DESCRIPTION

[0012] Embodiments of the present disclosure operate to inform users in a meaningful and intuitive way of the outcome of a comparison between actual and budgeted resource use.

[0013] In a first aspect of a method described herein, a budget is established for one or more applications and/or services. In some embodiments, the user enters a fixed budget for each application. As an alternative, or in addition to manual entry of a budget, the device guides the user in creating a fixed or automatic budget based on historic use and user-identified interest level/priority of use and/or various data services/subscriptions purchased by the user (or the user's family) for individual or multiple applications. [0014] A user's actual cost of network usage is monitored on a continual basis using information relating to the charges that apply for the user's network access. For example, one or more service providers sell the user a rate plan containing a fixed number of transactions or volume of data over a fixed period of time. The user's networked device is able to reference that information and to maintain a cached copy for offline review or decision making. The service providers in this case could be one or more cellular carriers, Wi-Fi service providers, or other wireless services. The service purchased by the user may be access to a service-enabled network, in which a user is provided with the ability to access to a particular service (e.g. Netflix) through a plurality of different wired or wireless data service providers.

[0015] On a continual basis, the device monitors usage against the established budget(s) and with regard to detectable alternate resources. In response to this monitoring, the device takes one or more of the following steps. If the budget has been reached for one or more applications, the user can be notified, and/or an ongoing application session that has reached the prescribed budget may be halted. The device may grey out or otherwise provide a visual notification on icons for all applications that have become unavailable in view of networking resources that have been exhausted. If a user attempts to select a greyed-out icon, the device may block the corresponding application from being initiated, or it may allow initiation of the application only if the user affirms an understanding and overrides the budget lockdown, e.g. by providing an acknowledgement in a pop-up dialog box.

[0016] In an exemplary embodiment, the user device receives an indication of a cost budget for a group of activities, such as a group of application programs. The device further receives information regarding the resource requirements and the expected resource consumption of one or more of the activities in the group. The device receives cost information regarding at least one available alternative provider of the resource.

[0017] When in use, the device receives an indication from a user that the user wishes to engage at least one of the activities. This indication may be received in the form of a user's selection of an application's icon on a touch screen. The device computes an estimated cost of the selected activity, based at least in part on the cost information and estimated resource consumption. In computing the estimated cost, the device uses the cost estimate for those resources that are capable of fulfilling the resource requirements of the selected activity. The device compares the estimated cost with the cost budget. The device then presents the result of the comparison to the user by changing visual, tactile, or other characteristics of the application icon and/or application initiation process. In some embodiments, the device further changes the interaction model required to initiate the application if the budget has been exceeded, e.g. by requiring separate approval for above-budget resource use. The change to the interaction module further operates to communicate to the user that he is exceeding the allocated budget.

[0018] In order to determine whether the use of the application is likely to meet or exceed a budgeted cost or resource usage, the user device may combine knowledge of network access costs (e.g. cost per Mbyte or cost per other unit of network resource usage) and network availability with knowledge of anticipated, calculated or observed (e.g. based on past history) resource usage of a particular application. The budgeted amount may be a global amount, or it may be budgeted specifically for the use of the application. The determination may take into account a current action or usage mode within the application. For example, if an application has one mode in which it displays text content and another mode in which it streams video content, then selection of the application in the text display mode may result in a determination that the application is not likely to meet or exceed the budgeted amount, whereas usage of the application in the video streaming mode may result in a determination that the application is likely to meet or exceed the budgeted amount. A determination that the budgeted amount is likely to be met or exceeded may trigger the system to change the application icon and/or to change the interaction model as described above.

[0019] Budgeting and usage monitoring can be performed in several different distinct ways, or a combination of various approaches can be used, with each having its own characteristics from a usability or implementation robustness point of view.

[0020] The present disclosure describes a number of alternative embodiments. These embodiments can be implemented as described, or they can be combined in whole or in part into additional embodiments with other functionalities. For example, some embodiments are resident on a single device, while other embodiments operate to leverage processing functions available over a network, such as cloud services. Some embodiments are implemented using a level of device OS enablement. Various embodiments may further include cloud based eco-system services to provide a multi-device and/or multi-user seamless experience. However, in some embodiments, an application level environment provides a platform on which sub applications could be advertised and launched in support of the principles and methods described herein.

Method Implemented on Operating System.

[0021] In an exemplary embodiment, the methods described herein are implemented using software instructions incorporated in the operating system (OS) of the user's device. In such an embodiment, changes to the appearance of icons and determination of network availability can be provided by system service calls. In such an embodiment, each application registers with the OS on installation, via background application agents messaging, OS polling, or event driven update requests. During the registration process, an application shares the nominal network connectivity demands (bandwidth, latency, quality of service, etc.). Alternatively, or in addition, the application can share its recent historical (or anticipated) network requirements. In some embodiments, the operating system captures historic information regarding an application's use of network resources.

[0022] In an operating-system-based embodiment, the operating system alters the appearance of, animates, or alters the behavior of icons as a function of the anticipated network resource usage requirements, the network services that are available at that moment, and the budget that has been established. The nature of the icon modification/animation will ultimately be a function of either system or application provided alternatives/animations, and/or conventions established by the platform, or industry norms.

[0023] In an exemplary embodiment, "Home Screen" application icons are active when the OS services are in a foreground processing activity, and animations/alterations to application icons are rendered/presented as an element of the operating system's user interface services. It should be understood that other software modules either within or outside the operating system can be implemented for presenting alterations to application icons. Use of the operating system's user interface functionality provides a straightforward implementation of the described methods of indicating network availability with respect to different applications.

[0024] It should be noted that however there are applications that are partially usable with alternate network resources or alternate tariff schemes, or that do not require network connectivity for certain functions. One example is an application that caches data in anticipation of user interaction when the device is offline. In that case, a method may be performed in which the application notifies the operating system of its various potential network connectivity requirements, and the operating system determines the appropriate appearance and/or behavior of the icon accordingly.

[0025] In some embodiments, functions within an application are also available based on the network resources they require, network availability, and budget. Because these touch points, icons, rolling lists, etc. are rendered through operating system service calls, the rendering of those user interface elements can be modified by the operating system using the principles described above to provide an indication of network availability. Method Implemented on Cloud Services.

[0026] In some embodiments, the system provides a networked service (e.g. a cloud-based service) to support the seamless presentation of the user experience in situations such as a multi- device single user, single network service, multi-network service (heterogeneous, or homogeneous), multi-user single device, and/or multi-user multi-device situations. In such embodiments, information is provided to the cloud service regarding the applications and associated resource demands, recent application usage (particularly to support device transitions), cumulative user and/or device resource consumption, and budgeted/allocated resource amounts for each network resource. The use of a cloud service allows for a UI that is consistent (e.g. consistent across devices) and also allows for a means of providing an ecosystem-enabled experience that permits the user to seamlessly transition between devices. Embodiments using a cloud service may provide for proper tracking of network resource usage across devices and may enable shared network resource multi-user scenarios.

[0027] Exemplary cloud services provide a common resource for the connected devices to retrieve resource budget allotments (e.g. per device, per network service, or per user), current tracked usage against the budgeted allotments, as well as information to smoothly transition between devices. In alternative embodiments, the common resource may be provided using other components, such as a real or virtual master device accessible by the various devices being supported.

Establishment of a Budget.

[0028] The capturing of the gross budget for a specific service can be performed using various different techniques. In some embodiments, the desired information being captured and maintained includes not only the purchased amount of services, but also information regarding charges that would be incurred if the contracted levels are exceeded.

[0029] In some embodiments, establishment of a baseline budget is performed through the automatic communication of that budget from a service provider (or from providers of service enabled applications) at whatever periodicity each service provides. For example, on the first day of every month, the cellular service provider provides an update to the user device and/or cloud service indicating that the user has X minutes, Y messages, Z bytes of data available through the end of the month. As an alternative, or in addition, that information can be provided via an application program interface (API), and/or push notification from the service provider on a regular, or automatic basis during the course of the month. This automatic approach not only forms the basis for setting up the basic budget for a user, but also could allow the service provider a means of offering services at different tariff levels based on times of the day, or dynamically due to overall network loading. Budget information can also be provided via a network services message or through an application that provides network service access itself.

[0030] In some embodiments, one or more network service providers have respective network services managers that communicate with user devices and/or cloud services using an API to provide real-time information on network resource costs and availability. Examples of API functions calls and potential responsive actions by compatible network services managers are illustrated in Table 1.

Table 1.

[0031] In some embodiments, gross budget information can be entered and/or modified using manual entry of data by a user. Budget information can also be entered with the assistance of a third-party service or other service provider, or by a web crawler, screen scrubbing, or data scraping application capable of extracting budget information from, for example, a service provider web site.

[0032] In some embodiments, a gross budget is apportioned among various devices and/or applications based on the characteristics of the application, network availability, specific users, user's rolls, and the like. In some embodiments, the gross budget is apportioned with a user interface on a wireless connected device, or through a standard web interface used to manage the individual, or groups of individuals sharing the gross budget, or restricted use of particular applications. [0033] The budget may be annotated to provide additional information (whether at a low or high level of detail) as to what applications and/or network services will allow a level of flexibility with respect to exceeding either the apportioned, or the gross budgeted amount; altemately the set budget limits may be based on limits of extra charges based on application, user, and/or application anticipated overages either in network units, dollars, or shared resources that have been underutilized for the period.

[0034] The operating system tracks and identifies to the user the identity of individual applications and/or features of a given application that are allowed to override the over budget scenario based on pre-configured information, or based on dynamically calculated anticipated network usage cost per network resource unit, as compared with limits on overage charges.

Tracking Usage.

[0035] In exemplary embodiments, the device (and/or cloud service) tracks network data usage against the allotted service elements with a level of granularity determined based on the tariffing, usage sharing model, and/or device eco-system contracts. An example of usage tracking is illustrated in Table 2.

Table 2 - Exemplary Determination Method - Application.

[0036] In the example of Table 2, the "most recent 2 hour period" refers to the last 120 minute period prior to the current time (from T. uo minutes to T₀ = NOW) which is intended to capture both the potential for the user to initiate this particular application and, if initiated, how much budgeted service is expected to be consumed based on activity during that recent time period. This allows decisions based on the expectation of use, and network resource consumption. [0037] An exemplary allocation of gross budget resources among different users is illustrated in Table 3.

Table 3 - Exemplary Determination Method - Service Provider.

User Interface Modification.

[0038] In embodiments disclosed herein, the user interface modification occurs as the device operating system re-calculates the current and/or anticipated usage against budget and available services (to be reflected in the UI presentation/animation). The re-calculation may be performed on an event-driven basis when there is a change to any variable element of the settings (e.g. budget, usage to date, services available). The re-calculation may be performed on a regular basis (polling), with the frequency of re-calculations being selected so as to be low enough to minimize overhead while being frequent enough to maintain a high quality user experience.

[0039] In exemplary embodiments, the device (e.g. the device OS) determines how to display application icons based on the expected data usage of the application, the current network connections and conditions, and the state of data usage of one or more networks. For example, some application icons may be displayed normally, and others may be "greyed out" (e.g. displayed with a certain 'grey level' shading, or with a reduced brightness). The actual determination of the "grey level" shading, as illustrated in the examples below, can be set in any manner but generally would be configured either as a device default, user interface or eco-system default, or on the basis of an application, service provider, context, or user-configured profile. Modifications to the display of application icons provide an illustration to the user in an intuitive and useful manner of which applications are available to the user in the current situation. [0040] The following pseudocode illustrates exemplary logic by which application icon modification is determined in a situation in which, for purposes of illustration, the AT&T network is the only available network. In this example the grey mask level indicates whether the application is usable.

Grey Mask Level

[0041] In the sample code above, a Grey Mask Level of 0 indicates that the application icon is displayed without any greying (or equivalently, at full brightness). A Grey Mask Level of 10 indicates that the application icon is displayed with a noticeable or significant amount of greying (or with a noticeably reduced brightness level). In different embodiments or based on different user preferences or device settings, different Gray Mask Level numbers may represent different alterations to the application icon.

[0042] In exemplary embodiments, modification to the icon display modification relies on the overall communication services budget, use against that budget, and the level of resources expected to be consumed by that device in a typical session based on historic observation and recent usage profile. This is illustrated in the following pseudocode.

If (the application is sponsored through this service provider) then

If (the month to date amount of this sponsored data [that has been used] + the anticipated amount of data that would be consumed if a typical user session was initiated) is less than

The amount of budgeted data still available for use, then

Set the grey level mask to 0

[0043] The actual determination of the "grey level" shading can be set either as a device default, user interface or eco-system default, or set on the basis of an application, service provider, context, or user configured profile.

[0044] In some embodiments, the appearance of an icon is subtly modified to indicate that the user may have hit or is near hitting a soft limit. One example of this is an individual hitting an allocated limit as part of a larger pool (e.g., as a member of a family plan) where the pool is configured to allow this. Another example is a user with a plan in which a service provider allows rolling over of unused capacity from one month to the next. In this case, the soft limit is the month's allotment, and the icon border color changes when the user begins consuming the carried over capacity from the prior month(s).

[0045] The following pseudocode represents logic that changes the icon border color to indicate whether a total plan budget has been exhausted (e.g. a family plan) or whether only the specific user's budget has been exhausted.

Icon Border Color ^: 0 If Application Sponsored (AT&T) & (MTD(AT&T Sponsored)

+ Application Nominal) < User Budget(AT&T Sponsored)

0 If (MTD(AT&T) + Application Nominal) < User

Budget(AT&T)

9 If Application Sponsored (AT&T) & (MTD(AT&T Sponsored) + Application Nominal) > User Budget(AT&T Sponsored) & < Total Plan Budget (AT&T Sponsored)

9 If (MTD(AT&T) + Application Nominal) > User

Budget(AT&T) & < Total Plan Budget (AT&T)

10 Else

[0046] In exemplary embodiments, the system determines whether free network services are available. If a free network service is available, all applications icons are displayed as available.

[0047] In some exemplary embodiments, the determination of how to display application icons is performed as a two-step process. In a first step, as described above, the available network resources are identified, and in the second step, the appropriate services and available data are determined on an application-by-application basis. This application-by-application determination generally requires an additional interface/exchange between the application and the operating system either at install time, or in real time to allow either the operating system or the respective application to make the determination that these cloud services or data are accessible for the specific application.

Additional Features.

[0048] In some embodiments, the user device collects usage statistics for each application and service interface as a means of anticipating the usage of a particular application given the currently available services. An outcome of the analysis of usage statistics is presented to the user using a technique such as an alternate visual or tactile response, or a warning message.

[0049] In some embodiments, the user device operates to bring alternate available services to the user's attention, including alternate network access services/technologies, or even network services to compress content or to provide link aggregation (heterogeneous or homogeneous), and including other user devices containing the desired content, or other user devices that have the desired content or access to that content.

[0050] In some embodiments, users are provided a means to interact with the application or services icon to override the greyed-out icon's indication of a lack of ability to start the associated application or service. This provides a means to the user to override the budget exceeded blockage of use of that application and allows the user to exceed the budget on a case by case basis.

[0051] In some embodiments, the user device in conjunction with a location based network services system provides information to the user via an hour glass, clock, or other indicator on an application-by-application basis indicating, due to either movement of the user, or loading levels on a network device or segment, that the application will be below the threshold for use and will be available (not greyed out) in the approximate time indicated. Such an indication of a predicted time of accessibility may be provided when, for example, a user's flight has landed and the device predicts that public Wi-Fi will be useable at the terminal, which the user is predicted to reach in approximately 20 minutes.

[0052] In some embodiments, hovering over an icon (e.g. with a cursor controlled by a mouse or trackpad) triggers the device to provide information such as which budget has been or is near being exceeded and what types of connectivity resources should be sought out by the user to re- enable the application. This information may be provided in the form of, for example, a hover box, tool tip, or screen tip. In some embodiments, the display of such information is triggered by an expression of interest other than hovering, such as, without limitation, gentle touch of an icon, a quick touch of an icon, or, in embodiments enabled with eye tracking capability (using, e.g., a front-facing camera), a determination that the user is gazing at the icon. In some embodiments, haptic feedback is used to alert a user to the likelihood that a budget will be exceeded. For example, hovering over, gently touching, or quickly touching an icon of a program that is likely to exceed a budget may result in a haptic feedback such as a vibration of the user device (or of a peripheral input device such as a mouse or trackpad), indicating to the user that an attempt to activate the icon will be subject to an access control. [0053] The techniques described herein may also be implemented in the case of wired networks, which themselves may impose resource limitations. For example, the access providers' tariffed plans may include a usage limit (gross total bytes), performance limit (throttled bandwidth), or a dynamic performance limit (bandwidth throttling based on application data type, usage to date, time of day, loading of the network). Multiple content providers or application providers may also benefit from service-enabled networking approaches, allowing various applications to continue to have premium access to the network resources even when general access has been deemed to exceed the subscribed service level provided by the broadband provider.

[0054] Making use of the user interface enhancements described herein, ecosystem-integrated device offerings with a differing set of network service provider relationships (e.g. smart phone, tablet, and TV) can be managed and supported in the same way.

[0055] In some embodiments, the device user interface significantly changes based on the network services available. Changes could include reordering the application icons, partitioning the user interface screen, or highlighting or animating the screen background, among other alternatives.

[0056] In some embodiments of the systems disclosed herein, when two or more network connections are available, the user device (or cloud service) operates to select a network connection for use by a particular application or a particular operation within an application. The selection may be based on service enabled networking. For example, the selection of the particular network connection may be made based on the cost of access through a particular network (e.g. a cost per megabyte), or the selection may be made based on quality of service (QoS) requirements for the application or operation within an application. In some embodiments, the user device compares information regarding nominal data resource usage (such as, for example, the information in Table 2) with information regarding data rates and costs of different available networks (such as, for example, the information regarding data rates in Table 3) and assigns a network according to the outcome of the comparison. As a consequence of assigning network connectivity separately to different applications or operations within an application, it should be noted that different applications or operations within an application on the same device may be connected to different networks, such that the device as a whole simultaneously maintains network connections through a plurality of access points. In some embodiments, the assignment of different networks to different applications or operations within an application is conducted in such a way as to minimize total data costs while still meeting predetermined quality of service requirements for the particular applications or operations within those applications. User Interface Illustration.

[0057] An exemplary user interface is illustrated in FIGs. 1A and IB, representing the user interface of the same user device under different network conditions. FIG. 1A illustrates the appearance of the user interface 102 when the user device has access to a Wi-Fi connection with unlimited data access. Icon 104 serves as an indicator of the availability of a Wi-Fi connection.

[0058] All application icons, such as icon 106 for a video application and icon 108 for a social media application are displayed in their native, unaltered state because the applications are not subject to any data limitations. The icons will similarly appear in their native unaltered state as illustrated in FIG. 1A if the user is well below the data budget for the various applications, as may occur, for example, at the start of a new billing cycle.

[0059] FIG. IB illustrates the appearance of the user interface 110 when the user device has moved out of range of the Wi-Fi connection and has attached to the AT&T LTE network. Several applications have already reached or are expected to reach their budgeted limits on that network. Consequently, the appearance of the relevant application icons has been modified to provide an indication to the user of the extent to which the application is unavailable or only partially available.

[0060] In the example of FIG. IB, for illustrative purposes, square hatching is used to indicate icons that are at least partially greyed-out. Solid dark borders represent greyed-out applications to which access limitations cannot be overridden. Dashed dark borders represent greyed-out applications to which access limitations can be overridden. Because user interfaces are often capable of displaying a multitude of colors and shades of grey, it is to be understood that the square hatching and the dark and dashed borders of FIG. IB may be implemented on a user device using, for examples, different colors, different levels of grey, and different levels of brightness. Other user interface indications, such as haptic or auditory feedback, may also be implemented to identify applications that have reached (or are about to reach) a budgeted level of access.

[0061] In FIG. IB, the icon 110 labeled "Browse" represents a web browser application, the use of which requires internet access. The Browse icon 110 is thus completely greyed out. In this example, the Browse icon 110 is greyed out with a solid dark border, indicating to the user that access controls on the Browse application cannot be overridden. Similarly, the icon 112 for the "Weather" application is greyed out with a solid border, indicating that downloading of new weather data is not currently available. [0062] In contrast, the "Coffee" icon 1 14 associated with a chain of coffee shops is greyed out with a dashed border, indicating that the network access controls can be overridden. For example, the Coffee application may provide money-saving offers to the user, so that allowing the user to access the Coffee application may be financially beneficial even if use of the application results in a sufficiently small overage charge. The "Chat" icon 116, representing a text messaging application, is indicated as being unavailable, but the unavailability can be overridden to allow for communication if necessary. In implementations on a full-color display, a red border may indicate that an access control cannot be overridden, and a yellow border may indicate that the access control can be overridden.

[0063] In some embodiments, icons can be modified to indicate that some, but not all, features of an application are unavailable in view of a resource budget that has been or is expected to be reached. For example, the "Social" icon 118 for a social media application is partially greyed out, indicating that some features of the application are still available. For example, a user may be able to draft new social media messages and to read messages that have already been downloaded, but not allowed to upload or download new messages. Similarly, the "Flix" icon 120, corresponding to a video application, is partially greyed out, indicating that it is possible to view videos that have already been downloaded, but not possible to download or stream new videos. The "Music" icon 122 is partially greyed out, with a dotted border indicating that access controls can be overridden. This may indicate, for example, that the user can listen to pre- downloaded music, but can also download or stream new music if the user acknowledges the likelihood that the budget will be exceeded (possibly incurring overage charges).

[0064] The determination of whether or not access controls can be overridden may be set by user preference. For example, consistent with the display of FIG. IB, a user may set a preference indicating that above-budget access controls cannot be overridden in the case of the video application ("Flix"), because video can consume a large amount of data and lead to large overage charges. Conversely, the user may set a preference indicating that above-budget access controls can be overridden in the case of the "Music" application, possibly because music consumes less bandwidth than video and may incur lower overage charges.

[0065] In some embodiments, user preferences indicating whether access controls can or cannot be overridden are set via account settings through, for example, a service provider web site. This allows, for example, a parent to determine whether a child is permitted to override access controls for particular programs on the child's smartphone. For example, a parent may allow access controls to be overridden for applications the child requires to complete homework or to contact the parents, but may otherwise prohibit access controls from being overridden for social media and entertainment applications.

[0066] Several of the icons of FIG. IB are not greyed out and thus are displayed in their normal format. Some of the icons that are not greyed out are applications that do not consume network resources. Some examples include the icons "Boom" 124 and "Solitaire" 126 which correspond to games that can be played by a user without network access.

[0067] Another icon of FIG. IB that is not greyed out is the icon "SponsorStream" 128, which corresponds to a service (e.g., streaming media) in a service-enabled network. For example, the user may pay to the SponsorStream service a subscription fee that includes not only access to the streaming media, but also the network connectivity used to access the SponsorStream content. Service-enabled sponsored content does not count against the user's budgeted network access limits, so icons corresponding to such content are not greyed out even if the user has otherwise reached the budgeted limits.

[0068] In some embodiments, the budgeted amount can be altered automatically in view of changed circumstances. For example, a user may have a monthly plan in which he pays a flat rate for up to 3GB of data, with additional charges being incurred when the user exceeds 3GB, 4GB, etc. That is, the user purchases additional data, beyond the base plan, in blocks of 1GB. As the user is approaching cumulative use of 3GB for the month, application icons begin to be greyed out, as illustrated in FIG. IB. However, the user may choose to override the access control (e.g. to send an important work-related email). Overriding the access control may then lead to the user incurring an overage charge for exceeding 3GB. However, no additional charges would be incurred until the user reaches 4GB of cumulative usage. Consequently, the system in this exemplary embodiment automatically increments the user's data budget to 4GB, and program icons revert to their native (normal) appearance as illustrated in FIG. 1 A.

[0069] With respect to FIGs. 1A and IB, a single user device in the same state relative to the data, message, and voice use versus budget on the AT&T LTE network is illustrated. The device image in FIG. 1A is accessing wide area data services via a Wi-Fi network, and in this circumstance it is a free network (or well below the paid for threshold). All icons are normal as all applications can be initiated on the device without concern of passing a budget use threshold for a typical application session.

[0070] FIG. IB illustrates this same device when moved outside the range of the free Wi-Fi. The device attaches to the LTE network and automatically adjusts the display of the application icons to indicate to the user that these applications have reached the allowed budget on LTE, or will soon reach it (based on a historic characterization of what level of resources the application typically consumes per session). In some cases, such as the SponsorStream application, since the user has a paid subscription that includes network access, their icons are not modified as these services are still accessible.

[0071] It should be noted that the greying out of an application icon is only one possible technique, among others, of providing an indication that a budget threshold has been reached or is expected to be reached. In some embodiments, the icon is removed altogether. In some embodiments, an icon is animated. Any other visual, audio, and/or tactile manipulation or modification may also be employed.

Exemplary Icon Modification Method.

[0072] An exemplary method is illustrated in FIG. 2. In step 210, an operating system of a user device displays an application icon in its normal, default state. In step 212, the operating system or other software component on the user device operates to predict whether activation of the relevant application is likely to cause a budget (e.g. a data or cost budget) to be exceeded (or, e.g. if the budget is already exceeded). If not, the operating system continues to display the icon in its normal format. If the application is likely to cause a budget to be exceeded, then in step 214, it is determined whether budget override is permitted (e.g. permitted according to user or administrator settings). If budget override is permitted, then in step 216, the icon for the application is displayed with a first modification (e.g. displayed with a yellow border). If budget override is not permitted, then in step 218, the icon for the application is displayed with a second modification (e.g. displayed with a red border). The first and second modifications are visually distinct from one another to indicate to a user whether overriding of the budget will be permitted.

Exemplary Prediction Method.

[0073] An exemplary method is illustrated in FIG. 3. In step 302, an operating system of a user device displays an application icon in its normal, default state. In step 304, the operating system or other software component of the device operates to determine whether activation of the application is likely to cause a budget to be exceeded under the current network connectivity conditions. If not, the operating system continues to display the normal application icon. If so, the operating system displays a modified version of the application icon in step 306. In step 308, the operating system or other software component operates to predict future network connectivity.

[0074] The prediction of future network connectivity in step 308 may include identifying a predicted set of future available network connections. In some embodiments, this is done by identifying a predicted destination of the user and identifying a set of network connections at the predicted destination. The prediction may include a time at which the user is expected to arrive at a location served by the future network connection. In some embodiments, the user device may store or have access to information indicating the location of free Wi-Fi access points, and the device may operate to predict when the user is expected to arrive at a location with a free Wi-Fi access point.

[0075] In step 310, the user device determines whether activation of the application risks exceeding a budget given the predicted future network connectivity. If so (that is, if the application risks exceeding the budget under both the current and future network connectivity environments), then the operating system continues to display the modified icon 306. If, however, the application is not likely to exceed the budget under the future connectivity conditions, then in step 312, the application icon is modified to reflect the prediction. For example, the application icon may be modified to display the predicted time at which the future connectivity is predicted to be available (e.g. the number of minutes before the connectivity is available, or the wall-clock time at which the connectivity is predicted to be available). This information enables a user to make the decision of whether to risk exceeding the budget to use the application immediately or whether to wait until other connectivity (e.g. free Wi-Fi) will be available to allow use without exceeding the budget.

[0076] FIG. 4 illustrates an exemplary user interface display 402 of a user device that employs the method of FIG. 3. In the embodiment of FIG. 4, icons 404, 406, and 408 (among others) are at least partially greyed out to indicate to the user that activating the associated applications (or at least some features of those applications) is likely to cause a budget to be exceeded. However, in the example of FIG. 4, the user device has determined that free Wi-Fi is likely to become available to the user in approximately ten minutes. The icons of the application programs have thus been further modified to indicate the predicted network availability to a user. For example, icons may be modified with the addition of a badge-type notification 410 that indicates the expected time remaining until the application can be used without risk of exceeding a budget. While FIG. 4 illustrates the use of a badge-type notification, other techniques may be used to provide an indication of the prediction.

[0077] In the examples of FIGs. 3 and 4, notification regarding future network availability may be made on an application-by-application basis. For example, it may be the case that the user is ten minutes away from completely free Wi-Fi, but that the user is only five minutes away from a coffee shop that offers free connectivity for use of the "Coffee" application (icon 408). The user device may thus display an indication for icon 408 showing that, in around five minutes, the application can likely be used without risking the budget.

Exemplary Functional Architecture.

[0078] FIG. 5 illustrates a functional architecture of a user device in an exemplary embodiment. In this embodiment, a communications interface 502 provides information quantifying the data resources consumed by a user (which may be an amount used since the start of the most recent billing period). This information on the user's actual data use is stored in location 506 of a memory 504. Information on actual data resource use may be stored separately for use of data over different network connections. For example, memory location 506 may store separate information on the use of data resources over one or more unmetered WiFi connections and the use of data resources over one or more metered connections (e.g. one or more 3G, 4G, or other mobile telecommunications connections). An exemplary table structure for memory location 505 is illustrated in Table 3.

Table 3. Data structure for data use memory location.

[0079] As illustrated in the example of Table 3, information on resource use may be categorized by the application using the data (e.g. Appl, App2, and App3) and by the particular connection used (e.g. Unmetered Connection A, Unmetered Connection B, Metered Connection C, Metered Connection D). Information regarding the number of times each application has been launched in the relevant period may also be stored in the memory or in another memory location. In some embodiments, one data structure may store information on the data use for the most recent billing cycle, for use in comparing actual versus budgeted data use, while another data structure stores information on data use for a longer period (e.g. for several months) for use in predicting likely data use per launch of each application. Information on the total data usage for each application may be used in predicting expected future data usage by the application. That total may include data usage over both metered and unmetered connections. Information on the total data usage for each connection may be used in comparing actual data usage on a connection with budgeted data usage for that connection. These totals may be stored in the memory, or they may be calculated on an as-needed basis.

[0080] In some embodiments, a single network service provider may be represented as being associated with both a metered and an unmetered connection. This may be done when, for example, some applications can be used over the network without metering, while use of other applications over the network is subject to metering. For example, suppose a 4G mobile data provider offers unmetered use of a particular streaming video service (e.g. App2). Then the use of that data provider for App2 may be tracked as "Unmetered Connection B", while the use of that data provider for other applications may be tracked as "Metered Connection C".

[0081] The user device may also receive through the communications interface 502 (e.g. from a cloud service) information quantifying the data resources consumed by a group to which the user belongs (e.g. by the user's family, in a case where the user's family shares a data plan). The information quantifying the group's data use may be stored in a location 508 of the memory 504. The memory 504 further stores in location 510 information identifying one or more budgeted data limits applicable to the user (e.g. the amount of data the user can consume over a cellular data connection before incurring additional charges). Memory location 512 may store information identifying one or more budgeted data limits applicable to the user's group. Budgeted data limits may be stored separately for different metered connections (e.g. for Metered Connection A and Metered Connection B).

[0082] In the embodiment of FIG. 5, memory location 513 stores data regarding the expected data resource use of various applications. For example, memory location 513 may store, for each application, a quantity representing the average amount of data resources consumed when that application is launched. This quantity may be a running average such that more recent information on data resource usage is weighted more heavily. Memory location 513 may be populated by a data use prediction module 522. In some embodiments, the data use prediction module 522 operates using the data stored in data use memory location 506 by dividing total data use for an application (across all network connections, including unmetered connections) by the number of times that application has been launched. In some embodiments, data usage for more recent launches of the application is weighted more heavily than past data usage.

[0083] Modification selection logic 516 operates to determine what type of modification, if any, is to be applied to an application icon. The modification selection logic 516 receives information from the communications interface 502 indicating which connection or connections is currently available. If all connections are unmetered with respect to a particular application (e.g. a home Wi-Fi network is available, or a mobile network that offers unmetered data for that application is available), the modification selection logic 516 may determine that no modification is to be applied to an application icon. If, however, only a metered connection is available, the modification selection logic 516 obtains from user budget data 510 and group budget data 512 the appropriate budget within which it is desirable to constrain data use. The modification selection logic 516 further obtains from memory locations 506 and 508 information on the actual cumulative use of that metered connection for the current billing cycle. The modification selection logic 516 may operate using the method illustrated in FIG. 2 to determine the type of modification, if any, to apply to an icon. Exemplary modifications include, for example, addition of a colored border to an icon or partial greying out of an icon. Application icons may be stored as image data 514 in the memory 504. Based on the type of modification (if any) selected by the modification selection logic 516, icon image modification logic 518 applies the selected modification to the image data. The resulting icon is displayed on a display 520 of the user device.

Exemplary System Architecture.

[0084] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network node, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0085] FIG. 6 is a system diagram of an exemplary WTRU 1102, which may be employed as a user device in embodiments described herein. As shown in FIG. 6, the WTRU 1102 may include a processor 1118, a communication interface 1119 including a transceiver 1120, a transmit/receive element 1122, a speaker/microphone 1124, a keypad 1126, a display/touchpad 1128, a non-removable memory 1130, a removable memory 1132, a power source 1134, a global positioning system (GPS) chipset 1136, and sensors 1138. It will be appreciated that the WTRU 1102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0086] The processor 1118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor

1118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 1102 to operate in a wireless environment. The processor 1118 may be coupled to the transceiver 1120, which may be coupled to the transmit/receive element 1 122. While FIG. 6 depicts the processor 11 18 and the transceiver 1120 as separate components, it will be appreciated that the processor 1 118 and the transceiver 1120 may be integrated together in an electronic package or chip.

[0087] The transmit receive element 1 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 11 15/1 116/11 17. For example, in one embodiment, the transmit/receive element 1122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 1 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 1 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 1122 may be configured to transmit and/or receive any combination of wireless signals.

[0088] In addition, although the transmit/receive element 1 122 is depicted in FIG. 6 as a single element, the WTRU 1102 may include any number of transmit/receive elements 1122. More specifically, the WTRU 1102 may employ MIMO technology. Thus, in one embodiment, the WTRU 1102 may include two or more transmit/receive elements 1122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 11 15/1 116/1 117.

[0089] The transceiver 1 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 1122 and to demodulate the signals that are received by the transmit/receive element 1 122. As noted above, the WTRU 1102 may have multi-mode capabilities. Thus, the transceiver 1120 may include multiple transceivers for enabling the WTRU 1 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11 , as examples.

[0090] The processor 1 118 of the WTRU 1 102 may be coupled to, and may receive user input data from, the speaker/microphone 1124, the keypad 1 126, and/or the display/touchpad 1 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 1 1 18 may also output user data to the speaker/microphone 1 124, the keypad 1 126, and/or the display/touchpad 1128. In addition, the processor 11 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 1130 and/or the removable memory 1 132. The non-removable memory 1130 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 1132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 1 102, such as on a server or a home computer (not shown). [0091] The processor 11 18 may receive power from the power source 1 134, and may be configured to distribute and/or control the power to the other components in the WTRU 1 102. The power source 1134 may be any suitable device for powering the WTRU 1 102. As examples, the power source 1134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.

[0092] The processor 11 18 may also be coupled to the GPS chipset 1136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 1102. In addition to, or in lieu of, the information from the GPS chipset 1 136, the WTRU 102 may receive location information over the air interface 1 1 15/11 16/11 17 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 1102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0093] The processor 1 118 may further be coupled to other peripherals 1 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 1138 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0094] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer- readable medium or media, such as commonly referred to as RAM, ROM, etc. [0095] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit-Receive Unit (WTRU), User Equipment (UE), terminal, base station, RNC, or any host computer.

Claims

1. A method performed on a user device having a plurality of applications activatable through respective associated normal icons, the method comprising:

from among the applications, identifying a set of budget-risking applications, wherein the activation of a budget-risking application is expected to cause use of a resource to exceed a budgeted amount;

for each of the budget-risking applications, determining whether the user is permitted to override the budget for the application;

for each of the budget-risking applications for which a user is permitted to override the budget, applying a first modification to the normal icon of the respective application; and

for each of the budget-risking applications for which a user is not permitted to override the budget, applying a second modification to the normal icon of the respective application, the second modification being visually distinct from the first modification.

2. The method of claim 1, wherein at least one of the first and second modifications includes partially greying out the respective normal icon.

3. The method of any of the preceding claims, wherein at least one of the first and second modifications includes outlining the respective normal icon.

4. The method of any of the preceding claims, wherein the determination of whether the user is permitted to override the budget is based on user preference settings.

5. The method of any of the preceding claims, further comprising, in response to a user selection of an icon having the second modification, alerting the user that activation of the application associated with the user-selected icon is blocked.

6. The method of any of the preceding claims, further comprising, in response to user selection of an icon of a budget-risking application, providing an alert to a user indicating that the budget is predicted to be exceeded.

7. The method of any of the preceding claims, wherein the identification of budget-risking applications is based at least in part on historic resource usage of the applications.

8. The method of any of the preceding claims, wherein the resource is a quantity of data, and the budget is a data budget.

9. The method of any of claims 1-7, wherein the resource is monetary, and the budget is a cost budget.

10. The method of any of the preceding claims, further comprising:

applying a first access control to each of the budget-risking applications for which a user is permitted to override the budget; and

applying a second access control to each of the budget-risking applications for which a user is not permitted to override the budget.

1 1. The method of claim 10, further comprising, in response to a user selection of an icon having the first modification:

providing the user the option to override the first access control; and

in response to a user override, activating the application associated with the user-selected icon.

12. The method of any of claims 10-1 1, wherein the second access control prevents activation of the associated application.

13. A user device on which a plurality of applications are activatable through respective associated normal icons, the device comprising a processor and a non-transitory computer- readable storage medium storing instructions operative, when executed on the processor, to perform functions comprising:

14. A method performed on a user device having at least one application activatable through an associated normal icon, the method comprising:

identifying a current set of currently available network connections;

identifying a predicted set of future available network connections;

predicting whether activation of the application is expected to cause a resource budget to be exceeded using the currently available network connections;

predicting whether activation of the application is expected to cause the resource budget to be exceeded using the future available network connections; and

in response to a determination that i) activation of the application is expected to exceed the budget using the currently available network connections, and that ii) activation of the application is not expected to exceed the budget using the future available network connections, modifying the icon of the application to provide information regarding the prediction.

15. The method of claim 14, wherein the icon is modified to indicate a time at which the future available network connections are predicted to be available.

16. The method of any of claims 14-15, wherein identifying a predicted set of future available network connections includes:

identifying a predicted destination of the user; and

identifying a set of network connections at the predicted destination.

17. The method of any of claims 14-16, wherein the resource is a quantity of data, and the budget is a data budget.

18. The method of any of claims 14-16, wherein the resource is monetary, and the budget is a cost budget.

19. The method of any of claims 14-18, wherein the prediction of whether activation of the application is expected to cause a resource budget to be exceeded using the currently available network connections is based on historic resource use of the application.

20. The method of any of claims 14-19, wherein predicting whether activation of the application is expected to cause the resource budget to be exceeded using the future available network connections comprises determining whether free network resources are predicted to be available.