WO2016209738A1

WO2016209738A1 - Method for estimating resource costs of mobile usage

Info

Publication number: WO2016209738A1
Application number: PCT/US2016/038215
Authority: WO
Inventors: Ville J. Ollikainen; Raimo J. Launonen; Markku KYLÄNPÄÄ; Caj Gustav SÖDERGÅRD; Sari Eliisa VAINIKAINEN; Magnus Melin
Original assignee: Pcms Holdings, Inc.
Priority date: 2015-06-25
Filing date: 2016-06-17
Publication date: 2016-12-29

Abstract

Systems and methods are disclosed for estimating resource use and preventing excessive use of resources, particularly on mobile devices such as smartphones. In an embodiment a user device receives an input identifying a desired activity, such as selection of an application to operate. The application is a member of a group of applications, and the group of applications has a resource budget. The system determines an estimated resource consumption associated with the activity, such as an estimated use of wireless data resources. The system further determines an estimated cost associated with the estimated resource consumption, such as a cost of the estimated data use. If the estimated cost exceeds the resource budget, a user is alerted and provided with the choice of whether or not to proceed with the desired activity.

Description

METHOD FOR ESTIMATING RESOURCE COSTS OF MOBILE USAGE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application Serial No. 62/184,761, filed June 25, 2015 and entitled "METHOD FOR ESTIMATING RESOURCE COSTS OF MOBILE USAGE," the full contents of which are hereby incorporated herein by reference.

BACKGROUND

[0002] The present disclosure relates to estimating costs of mobile usage, particularly in cases where the user of a mobile device is travelling. A typical mobile device has a myriad of applications, with each application consuming different amount of resources (e.g., different amounts of Internet data usage), and with these resources having certain costs.

[0003] When the user of a mobile device is traveling, one option for preventing excessive use of resources is to provide the user with the ability to switch particular resources on or off for each application. Alternatively, a user may simply decide not to use certain applications when known resource costs are expected to be high. Most mobile devices with 3G or 4G data capabilities have an option to automatically switch off mobile data when roaming.

SUMMARY

[0004] Embodiments of systems and methods described herein enable users to optimize resource costs of mobile usage by performing one or more functions including defining maximum resource cost in each Context, associating each application with at least one Context, measuring resource consumption of applications in advance, obtaining resource costs, calculating an estimate of resource usage costs for each application associated with a Context, determining if the estimated usage cost exceeds said maximum cost, and alerting the user accordingly.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0006] FIG. 1 is a flow diagram illustrating a resource cost method performed in some embodiments.

[0007] FIG. 2 is a flow diagram illustrating a resource cost estimation method performed in some embodiments. [0008] FIG. 3 is a schematic block diagram illustrating a wireless transmit/receive unit on which embodiments disclosed herein may be implemented.

[0009] FIG. 4 is a block diagram illustrating an exemplary functional architecture of components of a wireless transmit/receive unit in accordance with an exemplary embodiment of the present disclosure.

DETAILED DESCRIPTION

[0010] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application. 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.

[0011] One issue addressed by systems and methods disclosed herein is providing the ability to define and manage costs of operating different applications in mobile devices, particularly while roaming. In exemplary embodiments described herein, the costs at issue are costs related to Internet access, but embodiments described herein can be applied to the management of other types of costs, such as battery life.

[0012] In an exemplary situation in which the disclosed system is applicable, a traveler may have a large number of different applications (e.g., 50 or more) in his mobile phone. These applications may be categorized into different Contexts. For example, some applications may be related to games and entertainment, some to travelling, and some to work. Some of the applications may consume more resources compared to the others, and some may not consume a particular resource at all. Some applications may be operable but provide a limited user experience or limited functionality when resource consumption is limited.

[0013] Resource cost and availability can change substantially when the traveler moves from one area to another. Similarly, using different functions of applications may require different levels of resources and thus incur different costs. Some alternatives have properties which enable certain functionality for applications. For example, reading email headers generally does not consume much Internet data, but reading all emails and downloading all attachments may be costly or time- consuming if access to resources is limited. Also, while global positioning system (GPS) services are free, the service generally benefits when the traveler's mobile device is synchronized with mobile network base station data to provide assisted GPS (A-GPS) service. Games typically retrieve data from the Internet; they may not work at all or provide only limited user experience without being connected.

[0014] In some embodiments, applications may be organized by users, by default, or otherwise into different "Context Modules." Different Context Modules may be associated with different user contexts. In some embodiments, different Context Modules are executed in different secure computing environments, such as different virtual machines, to prevent unauthorized data leakage from one Context Module to another (e.g., between Context Modules related to work and Context Modules related to personal life and entertainment). Examples of possible Context Modules include, without limitation, "MyWork", "MyGardening", "My Traveling" or "MyGames." These Context Modules are advantageously visible in user interface, enabling a user to launch an application from a Context.

[0015] In exemplary embodiments, a user is provided with the ability to set maximum resource cost preferences for each Context. For instance, a user may accept costs up to $1 per day for all applications in a "MyGames" Context and up to $100 per day (and up to $500 per month) for applications in a "MyWork" Context. Applications in a "My Traveling" Context may have a limit of $30 per day. These preferences are illustrated in Table 1. In embodiments disclosed herein, the information in Table 1 may be stored in, for example, a table of a relational database. Cost Preferences for Contexts

Context Cost Limits

Games $1 / day

Travel $30 / day

Work $100 / day

Work $500 / month

Table 1.

[0016] Resource monitors are available for use on most mobile operating systems. Some of these resource monitors are capable of maintaining statistics, how much energy each application is draining from the battery, and they may also keep track on Internet consumption. In exemplary embodiments, a resource monitor may be further operative to track resource consumption statistics and infer the respective requirements. An example of resource consumption and requirements information, as well as typical (e.g., median) usage information, is illustrated in Table 2. In embodiments disclosed herein, the information in Table 2 may be stored in, for example, a table of a relational database.

Table 2.

[0017] Table 3 illustrates exemplary data regarding alternatives for available resources, such as available network connectivity options. In this example, each alternative has different properties and different pricing. These alternatives may vary from place to place, even on a local scale, for instance when entering or leaving a cafeteria. As illustrated, not all alternatives are suitable for all circumstances. For example, as shown in Table 2, League of Legends requires network connectivity with at least 1Mbps, whereas the information in Table 3 illustrates that Samargabat Democratic Wi-Fi offers only 64kbps, so it is not an option to play League of Legends using connectivity from Samargabat Democratic Wi-Fi.

Table 3.

[0018] Exemplary embodiments employ a Usage Cost Evaluator which informs the user of excessive costs related to an intended action. For example, suppose the user selects the game League of Legends in the "Games" Context. The game requires network connectivity of at least 1Mbps. If the free connectivity of Kosmobucks Wi-Fi is unavailable (e.g., it is out of range, or the user has already exhausted the free hour), then the Usage Cost Evaluator identifies Telecom Turkbekistan 3.5G and Merry odd Hotel Wi-Fi as the services offering sufficient connectivity. Based on the typical 30-minute session, the Usage Cost Evaluator calculates the cost of the estimated required data of 240MB/h over 30 minutes, which amounts to 120 MB. The Usage Cost Evaluator thus determines that costs would amount to $120 using Telecom Turkbekistan 3.5G or to $7 using Menyodd Hotel Wi-Fi (assuming that the Wi-Fi is not yet opened). Since both of these costs exceed the maximum cost preference, the Usage Cost Evaluator shows these options to the user and lets the user decide whether or not to open the Menyodd Hotel Wi-Fi for the next 24h. If, on the other hand, the user attempts to launch the Angry Birds app, the estimated cost remains under the preferred cost limit for Games, and there is no requirement to prompt the user. [0019] In another example, an employer has confirmed to pay any work related costs up to $100 per day or $500 per month, and these figures have been set as the cost preferences of "Work" Context. The user can use practically any resource for work context during his 10-day vacation abroad.

[0020] Embodiments disclosed herein simplify how to control resource costs for user in a foreign environment. In some embodiments, if cost information for resource alternatives is available, the user may set the preference for each Context and may not be required to set a preference for each individual application. These preferences are applied to each of the applications within the Context.

[0021] Exemplary embodiments have been described above using exemplary use cases. In some embodiments, systems disclosed herein perform the following steps. The system receives an indication of a cost budget for a group of activities (e.g. activities performed using applications in the same Context Module). The system further receives information regarding resource requirements of one or more activities, such as minimum data rates for playing of a game, checking in on a dining application, or synchronizing email headers. The system further receives information regarding estimated resource consumption of these activities, such as estimated rate of data usage and estimated duration of use of the resource (e.g., estimate length of a game). These estimates may be based on a past average of the duration of these activities.

[0022] The system further receives cost information for one or more of the available alternative providers of the resources, such as one or more available networks or network access points. The system also receives information regarding the resource properties of the resources offered by the providers, such as available data rates offered by different network access providers.

[0023] The system receives an indication that the user wishes to engage at least one of the supported activities. In response to the indication, the system identifies the available services that have sufficient resources to support the selected activity. The system then computes the estimated cost of the activity using each of the available services. The computation may be based on the cost information and estimated resource consumption. The system compares the results of the estimated cost calculations with the cost budget for the associated group of activities. The results of the comparison are then presented to the user, at least in the situation where the estimated cost exceeds the budgeted cost. In some embodiments, the result is presented to the user in the form of an inquiry as to whether or not the user wishes to move forward with the activity and thus to incur the cost. In some embodiments, only the lowest-cost option is presented to the user. [0024] An exemplary embodiment 100 is illustrated in FIG. 1. The system receives an indication of a desired action (105), e.g., when a user selects an icon corresponding to an application on a touch screen. The system operates to determine an estimated resource cost of completing the desired action (110). If more than one alternative provider for the resource is available and adequate for performing the desired action, then the system may determine an estimated resource cost for all of the available adequate resources and select the one with the lowest estimated cost. If the estimated cost would bring the total expenditures for the relevant Context beyond the budgeted cost level (115, 120), then the system requests user approval of the cost overrun (125), for example through a pop-up or other type of notification. The user may either approve or deny the cost (130). If the user does approve the cost overrun, then the requested action is completed (135). Otherwise, the action is canceled (140). Similarly, if the requested action does not result in an expense that exceeds the budget for the relevant Context, the requested action is completed (135).

[0025] In exemplary embodiments, the system stores, for each Context, data representing a running total of resource costs allocated to that Context over one or more predetermined periods of time. For example, the Work Context may be associated with a first data structure storing the costs incurred by the Work Context so far during the relevant calendar day, and the Work Context may be associated with a second data structure storing the costs incurred by the Work Context so far during the relevant calendar month. These totals can be used by the system to determine when periodic (e.g., daily, monthly) budgets are estimated to be reached.

[0026] In some embodiments, as illustrated in FIG. 2, determination of an estimated cost is based on determination of an estimated marginal cost of a desired action (205). The marginal cost (220) may represent the difference between the estimated total costs if the desired action is performed (210) and the estimated total costs if the desired action is not performed (215). Estimated total costs may be based on historic data usage, which may be historic data usage under the current situation (e.g., while roaming or traveling).

[0027] For example, consider a case in which the only available network resource is the Merry odd Hotel Wi-Fi of Table 3, which provides unlimited data at a rate of 1Mbps for 24 hours at a cost of $7. Now, suppose the user indicates a desire to play League of Legends. In embodiments in which the estimated cost is not an estimated marginal cost, the system determines that playing League of Legends will cost $7 and warns the user that this would exceed the $1 daily budget for the Games Context. If the user accepts, then the Games Context is over-budget, but the other Contexts will remain under budget because Wi-Fi access will incur no additional charges for the remainder of the day. This would be the case even if most of network resources are used by other Contexts (e.g., the Work Context) over the rest of the day.

[0028] On the other hand, in embodiments in which the estimated cost is an estimated marginal cost, when the user identifies a desired action, the system estimates the resource cost with and without performance of the desired action. These estimated resource costs may be based on historic behavior of the user or on historic behavior of similarly-situated users. Consider the above example in which Merry odd Hotel Wi-Fi is the only available network access point. Based on the user's historic behavior, the system determines that the user has a high probability of synchronizing email that day, which itself would require network access and thus would incur the cost of $7 even if the user did not play League of Legends. Of course, if the user does play League of Legends, this also incurs the cost of $7. Thus, in this example, there is no difference in expected total cost, whether or not the user plays League of Legends. As a result, the estimated marginal cost of playing League of Legends is determined to be $0.

[0029] A similar calculation of marginal costs may be performed for situations in which network data is sold in blocks. For example, access to 1Gb of network data may be available for a flat monthly fee, with an additional fee of, for example, $20 for each additional 1GB of network data, and so on. In such a case, historic data may indicate that the user is expected to access 900MB of data for work-related purposes. If the user indicates a desire to play a game that would require 200MB of network data, the system may estimate a marginal cost of $20 and alert the user accordingly. However, if the user is expected to incur (or already has incurred) the surcharge of $20 for work-related purposes (e.g., email), and is not expected to use a full 2GB, the system may determine that the marginal cost of playing the 200MB game is zero. In some embodiments, the estimated marginal cost may be weighted statistically. For example, if there is a 50% chance that gameplay will cause the user to incur the $20 overage charge, then the system may inform the user that charges for gameplay are estimated at $10. Other embodiments may alert the user to the probability (e.g., with a notification, "If you play this game, there is a 50% chance of incurring overage charges of $20. Would you like to continue?").

[0030] Similarly, some embodiments make use of resource quotas with at least one specific property that is changing after the quota is exceeded. For instance, a data package may include

100MB data at full speed, but may provide data only at 64kbps after the 100MB threshold (see

"Ashgant Mobile" in Table 3). Now, assume that the user is launching League of Legends which consumes 240MB/h (equal to 4MB/minute), and the typical usage was 30 minutes per day, it can be calculated that the high speed quota will be exceeded in 24 minutes, after which a) playing the game and b) using other resource critical applications are no longer possible unless more resources are bought. The user is informed that this will happen advantageously using a popup message or an audible alert.

[0031] In some embodiments, the Usage Cost Evaluator operates to estimate resource usage for a period of time, such as for the rest of the day. For instance, since usage statistics are advantageously available, the Usage Cost Evaluator is able to subtract the amount of resources consumed in the current period of time from the typical and/or previous resource consumption, advantageously per Context, and estimate the total amount of resources still required. This amount can be in turn subtracted from available resources while launching an application. In the example, League of Legends would still consume 4MB/minute, but work emails, 25MB have not yet been read for today, so the conveniently available quota would be 100MB-25MB = 75MB, which will be exceeded after 75MB/(4MB/minute) = 19 minutes. The user would then have a choice, for instance, a) to accept exceeding the quota, or b) to receive an alert when 75MB has been used for the game.

[0032] In some embodiments, the cost budget is set explicitly by the user, for example through a preferences menu. In other embodiments, the cost budget is set implicitly, as described in further detail below.

[0033] Keeping in mind that in some Contexts cost budgets may still be set explicitly, for instance the employer may have defined a cost budget for work Context, some Contexts may have cost budgets which are flexible and self-learning by nature. As an example, when launching an application associated with a Context the following steps may be processed. a) Using history data to determine the typical session time of the application and the typical resource usage of the application.

b) Calculating estimated resource use per session accordingly.

c) Using minimum requirements for the application to determine which resource alternatives are viable.

d) From the estimated resource use and costs of viable alternative resources, calculating estimated session costs for each viable alternative.

e) Comparing the alternatives and comparing a previously stored cost budget for the Context. At this step, the previously discussed quota issues, like saving some resource quota for other daily activities, may be taken into account. f) If the estimated session cost is higher than or almost as high as (e.g., 2/3 of) the cost budget for the Context, then prompt the user about possibly exceeding the cost budget. There may be alternatives such as "OK", "OK just this time", or "Not OK".

• If the user replies "OK", the estimated cost is saved as the revised cost budget for the Context. Alternatively, and advantageously, the cost budget can be adjusted using current cost budget and the estimated cost, for instance saving their average as the new cost budget.

• Otherwise, the user is advantageously informed of how long a session he/she could have while still remaining within the cost budget

g) Resource usage is advantageously monitored, and if/when the user exceeds the budget he/she is informed accordingly, for instance by a popup window or an audible warning.

[0034] In exemplary embodiments, information regarding resource costs (such as mobile roaming costs) may be obtained over the network by mobile operator web sites. In some embodiments, cost information is entered manually. The system may provide a user interface that offers a simple means for users to enter information regarding resource costs whenever a new provider becomes available.

[0035] As noted above, the setting of cost budgets may be implicit rather than explicit. For example, the cost budget may be set based on what costs have been deemed acceptable in previous situations. Implicit setting of cost budgets may further involve determining a total cost budget within a certain time window and average usage of the group of activities in the past.

[0036] In some embodiments, instead of manually entering prices to the Usage Cost Evaluator, there are a couple of alternatives a resource provider can enter the information into a Global Database from where the cost information would be made available. This option would be most effective in circumstances where embodiments disclosed herein have a large market penetration.

[0037] In some embodiments, crowdsourcing is used for sharing of resource cost information. When one user enters the data into the Usage Cost Evaluator, the information is also uploaded to the Global Database for subsequent requests from other users.

[0038] In some embodiments, a web crawler is used to collect cost information. When a new resource appears to the user, the Usage Cost Evaluator checks the Global Database first, and if the information is not found, the system launches a web crawling / search instance to find appropriate information from the web. Advantageously, when an appropriate web page has been found, the page is displayed to the user, parsing cost information from the page and asking the user if the cost information is correct. [0039] In some embodiments, one or more of the Contexts relates to an activity as to which costs are paid or reimbursed by a third party. For example, costs incurred by the "Work" Context may be paid by an employer. In such embodiments, the third party (e.g., the employer) may be provided the opportunity to monitor accumulating costs, to control which applications are allowed in the Context, and to receive a report after the trip, including all accumulated costs. In some embodiments, where the total resource bill is to be paid by the third party, the report may extract costs of Context other than those approved by the third party.

[0040] In some embodiments, the budgeted resource may be a resource other than total financial cost. For example, battery consumption by application is measured by some resource monitors, such as "Battery Monitor" in Symbian ^A3 OS. A resource monitor can be used to estimate the current (e.g. how many mA) each application consumes while in use. The resources in this case would be, e.g., a built-in battery with X mAh remaining, an external power pack, with Y mAh remaining, and a wall charger (available only at certain locations, such as in the hotel). The cost preference may then indicate how many hours/minutes of battery the user wants to save for nominal usage, and the Usage Cost Evaluator may take into consideration nominal battery draining. In the case of a mobile phone, the nominal draining would cover phone standby plus average calls. Indeed, nominal phone usage may be treated as a Context with at least two applications: "standby" and "call". For other devices, the nominal draining may be statistical information, for instance average use from the past 24 hours.

[0041] In accordance with the present disclosure, in one embodiment there is method comprising: receiving an input identifying a desired activity, wherein the desired activity is associated with a first group of applications, the group of applications having a first resource budget; determining an estimated resource consumption associated with the desired activity; determining an estimated resource cost associated with the estimated resource consumption; comparing the estimated resource cost with the first resource budget; and determining whether to perform the desired activity based at least in part on the outcome of the comparison.

[0042] In one embodiment, the desired activity is use of an application. The resource may be, for example, network data and/or battery life. In one embodiment, determining whether to perform the desired activity includes, if the estimated resource cost exceeds the first resource budget, offering a user the option of whether to proceed with the desired activity. The estimated resource cost may be reported to a user. In some embodiments, the first group of applications is a Context Module. The desired activity may be an activity such as synchronizing an email inbox, synchronizing email headers, and/or assisted GPS (A-GPS) localization. [0043] In some embodiments, the resource budget may be a daily budget, a weekly budget, and/or a monthly budget. In one embodiment, the estimated resource consumption is determined based at least in part on a minimum resource consumption for the desired activity. In one embodiment, the estimated resource consumption is determined based at least in part on an estimated duration of desired activity. In a further embodiment, the estimated duration is based at least in part on durations of the activity in the past. In one embodiment, a user is prompted if the estimated resource costs exceed the first resource budget. In one embodiment, the method further comprises identifying a plurality of resource provider alternatives, wherein determining an estimated resource cost includes determining estimated resource costs for a plurality of the resource provider alternatives. In a further embodiment, the method further comprises selecting a resource provider based at least in part on the estimated resource costs for the plurality of resource provider alternatives. In a further embodiment, the lowest-cost provider is selected. In one embodiment, the first resource budget is set manually.

[0044] In one embodiment of the present disclosure, a wireless transmit-receive unit may be configured to perform functions including: receiving an input identifying a desired activity, wherein the desired activity is associated with a first group of applications, the group of applications having a first resource budget; determining an estimated resource consumption associated with the desired activity; determining an estimated resource cost associated with the estimated resource consumption; comparing the estimated resource cost with the first resource budget; and determining whether to perform the desired activity based at least in part on the outcome of the comparison.

[0045] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity. FIG. 3 is a system diagram of an exemplary WTRU 302, which may be employed as a user device in embodiments described herein. As shown in FIG. 3, the WTRU 302 may include a processor 318, a communication interface 319 including a transceiver 320, a transmit/receive element 322, a speaker/microphone 324, a keypad 326, a display/touchpad 328, a non-removable memory 330, a removable memory 332, a power source 334, a global positioning system (GPS) chipset 336, and sensors 338. It will be appreciated that the WTRU 302 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0046] The processor 318 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 318 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 302 to operate in a wireless environment. The processor 318 may be coupled to the transceiver 320, which may be coupled to the transmit/receive element 322. While FIG. 3 depicts the processor 318 and the transceiver 320 as separate components, it will be appreciated that the processor 318 and the transceiver 320 may be integrated together in an electronic package or chip.

[0047] The transmit/receive element 322 may be configured to transmit signals to, or receive signals from, a base station over the air interface 315/316/317. For example, in one embodiment, the transmit/receive element 322 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 322 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 322 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 322 may be configured to transmit and/or receive any combination of wireless signals.

[0048] In addition, although the transmit/receive element 322 is depicted in FIG. 3 as a single element, the WTRU 302 may include any number of transmit/receive elements 322. More specifically, the WTRU 302 may employ MIMO technology. Thus, in one embodiment, the WTRU 302 may include two or more transmit/receive elements 322 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 315/316/317.

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

[0050] The processor 318 of the WTRU 302 may be coupled to, and may receive user input data from, the speaker/microphone 324, the keypad 326, and/or the display/touchpad 328 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 318 may also output user data to the speaker/microphone 324, the keypad 326, and/or the display/touchpad 328. In addition, the processor 318 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 330 and/or the removable memory 332. The non-removable memory 330 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 332 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 318 may access information from, and store data in, memory that is not physically located on the WTRU 302, such as on a server or a home computer (not shown).

[0051] The processor 318 may receive power from the power source 334, and may be configured to distribute and/or control the power to the other components in the WTRU 302. The power source 334 may be any suitable device for powering the WTRU 302. As examples, the power source 334 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.

[0052] The processor 318 may also be coupled to the GPS chipset 336, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 302. In addition to, or in lieu of, the information from the GPS chipset 336, the WTRU 302 may receive location information over the air interface 315/316/317 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 302 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0053] The processor 318 may further be coupled to other peripherals 338, 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 338 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.

[0054] FIG. 4 illustrates a functional architecture of a WTRU in accordance with an embodiment. A request manager module 405 may operate within an operating system 400 on a device. The request manager module 405 may include a request evaluation module 410. The request evaluation module 410 may include sub modules, for example, a minimum requirements sub module 411, a budget sub module 412, a rules application sub module 413, a user input sub module 414. The request manager 405 and request evaluation 410, as well as other modules, may communicate with a memory 415. The memory may include data tables. One example of such a data table is a rules data table 416 for implementation of the disclosed methods (e.g., related to use of separate work and personal budgets, when to switch to a lower cost provider, disabling certain apps if current throughput is insufficient, and/or the like). Another example of a data table may be a budget table 417 for all resources, where the budget table may include various contexts (e.g., work, game, travel, etc.), various categories of cost for each context (e.g., battery usage permitted, monetary cost per day), live tracking of resource consumption for each context (e.g., amount of battery used by context so far today, monetary cost of context so far today, etc.). Another example of a data table may be a resources table 418, including such as various resource names, resource types (e.g., wifi, 3G, 4G, etc.), resource properties (e.g., speed, speed dependent on usage, etc.), resource cost (e.g., $/Mb, ad view requirements, etc.), current availability (e.g., able to connect at this time), and/or the like. Another data table 419 may record historical patterns of use for particular apps and/or contexts.

[0055] At various times, the request evaluation module may receive indication of a user input from a GUI 401, such as an attempt to launch an app. The request evaluation module may communicate with the memory to obtain relevant minimum requirements, budgets, rules, and/or the like.

[0056] In some embodiments, the request evaluation module 410 may include a resource usage prediction sub module 421 operative to evaluate the marginal costs of a requested action (e.g., launching a game, checking work email, etc.). In some embodiments, the resource usage prediction sub module 421 may determine an available excess of at least one resource for a requested action, such as where the direct resource cost of an action would exceed a budget but where, in view of predictions (such as estimated use later the same day of a hotel WiFi for work emails), such action's marginal cost does not exceed the budget. Based on a result from the request evaluation module 410, the request manager may, through a physical configuration module, control a multiple radio access technology (MRAT) communication manager module 423 to connect the device to one or more resources (e.g., connect to a hotel WiFi network, connect to a 3G or 4G wireless network, etc.). In some embodiments, the request manager may communicate with the MRAT manager 423 to scan for available resources, and update the memory as appropriate (e.g., whether particular resource providers are currently available to connect to).

[0057] In some embodiments, the request manager may communicate with a GUI module to prompt a user to authorize a requested action, such as if the requested action would exceed a preset budget.

[0058] In some embodiments, if the determination of the request manager module is that the requested action is permissible in view of the stored rules, predicted resource costs and usages, and/or the like, the request manager module may indicate that the requested action, such as launching a particular app (e.g. app 402), may proceed, and a message may be sent through the operating system to the app as to launch the app.

[0059] In some embodiments, the request evaluation module 410 may continue to monitor an ongoing action, such as in cases where a user's actual actions (e.g., play time of a game) exceed a historical prediction.

[0060] 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 WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method comprising:

receiving an input identifying a desired activity, wherein the desired activity is associated with a first group of applications, the first group of applications having a first resource budget; determining an estimated resource consumption associated with the desired activity; determining an estimated marginal resource cost associated with the estimated resource consumption by:

determining a first estimated total resource costs without the desired activity; determining a second estimated total resource costs with the desired activity; and subtracting the first estimated total resource costs from the second estimated total resource costs;

comparing the estimated marginal resource cost with the first resource budget; and determining whether to perform the desired activity based at least in part on the outcome of the comparison.

2. The method of claim 1, wherein determining whether to perform the desired activity includes, if the estimated resource cost exceeds the first resource budget, offering a user the option of whether to proceed with the desired activity.

3. The method of any of claims 1-2, wherein the first and second estimated total resource costs are based at least in part on a user's historic usage patterns.

4. The method of any of claims 1-3, further comprising identifying a plurality of resource provider alternatives, wherein determining an estimated marginal resource cost includes determining estimated marginal resource costs for a plurality of the resource provider alternatives.

5. The method of claim 4, further comprising selecting a resource provider based at least in part on the estimated marginal resource costs for the plurality of resource provider alternatives.

6. The method of claim 5, wherein the lowest-cost provider is selected.

8. The method of any of claims 1-6, further comprising reporting the estimated resource cost to a user.

9. The method of any of claims 1-8 wherein the first group of applications is a Context Module.

10. The method of any of claims 1-9, wherein the resource comprises at least one of: battery life, and network data.

11. The method of any of claims 1-10, wherein the first group of applications comprises at least one of: a group of work-related applications; a group of hobby-related applications; a group of travel -related applications; or a group of game applications.

12. The method of any of claims 1-11, wherein the resource budget is at least one of: a daily budget; a weekly budget; or a monthly budget.

13. The method of any of claims 1-12, wherein the estimated resource consumption is determined based on historic resource consumption of a user.

14. The method of any of claims 1-13, wherein the estimated resource consumption is determined based on historic resource consumption of a plurality of users.

15. The method of any of claims 1-14, wherein the estimated resource consumption is determined based at least in part on a minimum resource consumption for the desired activity.

16. The method of any of claims 1-15, wherein the estimated resource consumption is determined based at least in part on an estimated duration of desired activity.

17. The method of claim 16, wherein the estimated duration is based at least in part on durations of the activity in the past.

18. The method of claim any of claims 1-17, wherein setting of cost budgets is performed automatically based at least in part on a user's past decisions on whether to accept charges.

19. A wireless transmit-receive unit comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: receiving an input identifying a desired activity, wherein the desired activity is associated with a first group of applications, the first group of applications having a first resource budget; determining an estimated resource consumption associated with the desired activity; determining an estimated marginal resource cost associated with the estimated resource consumption by:

20. A method comprising:

receiving at a wireless transmit-receive unit an input identifying a desired activity, wherein the desired activity is associated with a first group of applications, the first group of applications having a first resource budget;

determining an estimated resource consumption associated with the desired activity; determining an estimated marginal resource cost associated with the estimated resource consumption by:

comparing the estimated marginal resource cost with the first resource budget; and in response to a determination whether to perform the desired activity based at least in part on the outcome of the comparison:

performing the desired activity.