Automated device behavior management based on network charging and rating conditions

[0001] The present application is related to U.S. application Ser. No. 10/324,494 filed on Dec. 19, 2002, U.S. application Ser. No. 10/324,159 filed on Dec. 19, 2002, and U.S. application Ser. No. 10/324,870 filed Dec. 19, 2002, all commonly assigned to Cingular Wireless II, LLC and incorporated by reference in their entirety.

[0002] The disclosed embodiments relate to automatic wireless communication device awareness of current conditions related to network charges and rates (“financial conditions”), and user-defined device behavior based on those conditions. The disclosed embodiments give a wireless device user greater automatic control over how rating and charging conditions affect device use.

[0003] Users of wireless communication devices agree on rating and charging terms in a service provider agreement. The network service provider, or carrier, typically offers a variety of plans with different variables. The variables include the amount of air time per billing cycle that is charged at a minimum rate, more favorable rates during “off-peak” times such as nights and weekends (as opposed to “on-peak” or “peak”) times, different rates for on-network use and roaming use, fees for special services such as call conferencing and email usage, etc. The amount of time available per billing cycle at a certain rate is sometimes referred to as the amount of time in a “bucket”. For example, the user typically chooses a number of minutes per month, e.g., 100 minutes per month, that are free or charged at a minimal rate. After the 100 bucket minutes are used, airtime is charged, or is charged at a higher rate.

[0004] Users benefit from having an awareness of how much money they will spend if they use their device at a certain time or in a certain way. For example, the user might like to know that only five minutes are left in the bucket. This rating and charging awareness is even more important with data connections than with voice connections. For example, sending or receiving email during peak hours may be much more expensive than during off-peak hours. For the user to adjust device usage based on rating and charging conditions, however, the user currently must affirmatively: 1) find out what the conditions are; 2) act or refrain from acting accordingly. For example, for some devices, the user can press keys on the keypad to find out how many minutes are left in the bucket.

[0005] Currently, the ability to automatically manage device use based on financial conditions is very limited, and also costly and awkward. For example, if a user wishes for an action be taken based on a condition, such as having particular phone numbers disabled under certain conditions, this is currently handles on an occurrence-by-occurrence basis at the provider site. The provider must program a local provider application to recognize that the device belonging to the particular account is making a particular call when a specified condition is current. The provider must then invoke a native application on the device, such as the call controller, to disable the specified phone numbers. This has several limitations and disadvantages. The user must make a written or verbal request to the provider. The provider must assign someone to program the provider application, and activities of the affected device must be monitored, which slows call handling. The provider can only invoke native applications, not downloaded applications, which limits the actions that can be taken in response to a condition.

[0006] Overall, there is a need for an improved ability to automatically manage wireless device behavior based on rating and charging conditions. There is a need to allow the wireless device user greater flexibility to automatically control device use with minimal provider intervention using all of the capability of the device, including the capabilities of downloaded applications.

[0013] Embodiments of the invention, described below, include a method for automatically managing wireless device actions based on network provider financial conditions, such as the current rate (e.g., cents/minute) for a voice or data communication. The financial conditions are typically agreed upon by the network provider and the user, but are controlled by the provider. The user configures preferences indicating how the device should behave based on certain financial conditions. Embodiments of the invention include storing data on the wireless device, on provider equipment or both, based on the preferences. The device and the provider communicate transparently to the user to monitor current financial conditions and take actions automatically based on the user preferences. Depending on the class of the device, communication and device behavior as described herein can occur during, or not during, a voice connection. In the latter case, the communication is queued until the voice connection is closed. The communication and behavior does not occur when the device is powered down.

[0014] In one embodiment, the user device includes native applications and downloaded applications. The downloaded applications could come from a variety of sources (vendors) and are individually configured by the user and/or the vendor. The provider may have no knowledge of the downloaded applications. Embodiments of the inventions, however, allow the user configuration to dictate which applications are automatically executed at particular times based on financial conditions, such that the provider does not need to be aware of downloaded applications on a device. The user configuration is applicable at an account level, making the user configuration automatically applicable to multiple devices on one account. The provider does not need to intercept or specially process calls in order to affect the device behavior. The provider only recognizes the condition and passes it to the device for processing.

[0015] FIG. 1 is a diagram of an embodiment of a wireless communication system 100. The system 100 is arbitrarily divided into two areas. Area 104 includes equipment and applications (“provider equipment”) typically provided and maintained by a wireless communication service provider, such as a cellular phone service provider. Area 102 includes equipment and applications (with the exception of radio tower 116) that are typically not provided or maintained by the provider, but are designed to communicate on the wireless network with the provider equipment. System 100 is an example of one arrangement of elements, but others are possible. A cellular phone service provider is one example of a provider, but other examples include any wireless service provider that provides wireless communication capabilities through a user device over a wireless network. For example, service providers that support personal digital assistants (“PDAs”) are also providers for purposes of the embodiments described.

[0016] The area 104 includes various elements useful to illustrate embodiments. Many typically known elements of provider equipment are not shown because they do not add to the understanding of the embodiments. For example, various computers or data processors are not shown, but are known to be part of the provider equipment. Provider applications 106 are software applications that maintain and administer the network. For example, the applications 106 include billing applications, performance monitoring applications, and many more. The applications 106 include applications that track user accounts, which are typically designated by a responsible billing party. The account may include one user with one device, or a group of many users each with a respective device. For example, some enterprises provide groups of employees with devices for limited or unlimited use in the course of employment.

[0017] The area 104 further includes a database or databases 108 and 110. The databases 108 and 110 are shown separately to distinguish the types of data stored, but could be one physical entity or more than two physical entities. The database 110 is a billing database that stores data used by the provider to generate bills for an account. Billing data includes all of the information in the user's rate plan, such as number of minutes in a bucket, bucket rates, out of bucket rates, etc.

[0018] A user preferences database 108 stores a user's choices regarding what financial conditions the user would like the device to be automatically notified of. The user preference database also includes actions the user would like the device to take when a financial condition occurs. One example is the device automatically blocking all outbound calls upon during peak billing rate time.

[0019] A short message service controller (“SMSC”) 114 manages short messaging, including receiving/sending, generating, and encoding/decoding SMS messages. The wireless communication device 118 communicates over the wireless network using radio towers such as radio tower 116 in the known manner. An event manager 112 recognizes events and sends a message to the SMSC in response. An event manager 112 recognizes events that indicate a change in the current financial condition (such as change from off-peak to peak) and sends a message to the SMSC in response.

[0020] A user 120 of a wireless communication device 118 may configure the user preferences by accessing a dedicated provider configuration application (one of the applications 106). The applications 106 may be accessed using the device 118, or using a personal computer 122 to access the application 106 via the Internet 124. The user preferences are developed by the provider configuration application based on user inputs and downloaded from the provider to the device 118. The device 118 includes downloaded applications (not shown in FIG. 1) that may come from the provider or any third party. Downloaded applications from the provider may be configured in the same way as preferences, as described. Downloaded applications from third parties may be configured in any way dictated by the third party source. The provider has no knowledge of the configuration of the third party downloaded applications or their individual configurations. The user 120, however, knows which downloaded applications are present on the device 118 and how they are configured to behave. The user 120 can therefore configure the user preferences accordingly. For example, the user may configure the user preferences such that a downloaded email application only sends or receives emails during an off-peak period.

[0021] FIG. 2 is a flow diagram illustrating an embodiment of the device 118 configuration. Referring to FIG. 1 and FIG. 2, at 202 the user individually configures the downloaded applications on the device 118. Then, the user configures the user preferences at 204, and the user preferences are stored (at 206) in the database 108. When a new user configuration is stored for an account, a message is sent to the short message service controller (“SMSC”) 114 at 208. At 210, the SMSC 114 generates an encoded SMS message to the device 118 that indicates a new user configuration is available to be downloaded. At 212, the device 118 opens a communication channel to the provider equipment 104 to retrieve the new configuration data. In one embodiment, the encoded message reaches the device 118, indicating that the device 118 is receiving a general packet radio service (“GRPS”) signal. In one embodiment, the condition “Home GPRS Available” is in the signal. The device 118 invokes a Java application management service (“JAMS”, described further below), which looks for applications with a “Refresh when new data connection becomes available” flag set. The indicated applications start and perform data refreshes. The user need not take any actions. The new configuration data is received, and a condition catalog and a condition registry (described below) are updated at 214.

[0022] For the purpose of device 118 configuration, out-of-band signals are exchanged between the device 118 and the provider equipment, although in-band signaling could be used. These signals may be exchanged via a hypertext transfer protocol (“HTTP”) connection, a wireless application protocol (“WAP”) connection, or any other wireless communication method.

[0023] FIG. 3 is a flow diagram illustrating an example of automatic conditional application invocation. Referring to FIG. 1 and FIG. 3, At 302, a message is sent to the event manager 112 to indicate that a new condition is becoming current. As one example, the billing database 110 sends a message to the event manager 112 indicating that the bucket is empty. At 304, the event manager 112 sends a message to the SMSC 114 requesting that an encoded message be generated. The SMSC encodes the message and sends it to the device 118 at 306. At 308, the device 118 receives and decodes the message, and sends a return message to retrieve the financial condition from the event manager 112. At 310, the device 118 receives the financial condition from the event manager 112 and processes the financial condition using a condition registry as described below. In an alternative embodiment, the SMS message sent to the device includes the financial condition. In this embodiment, therefore, the device does not retrieve the condition from the event manager 112.

[0024] Once the financial conditions and the conditions are available to the device, the device is able to make decisions based on the user-selected choices. One scenario is a user, Bob, writing an email to send to Tom. Bob's device is currently set to send email only during off-peak periods. The message thus queues in Bob's device, along with any other email he has written, until the network notifies the device of a rate change. When the device receives notification that rates have changed downward, the device wakes up the email application and sends out all mail in the queue.

[0025] Another scenario is Bob setting his email preferences to send and receive high-priority messages whenever they are generated. All other emails wait for the change to an off-peak period. Tom's email marked high-priority would be delivered immediately to the device. This represents a conscious choice made by the user, which can be changed at any time.

[0026] In yet another scenario, Tom wishes to limit the amount of time his son Billy can talk to certain people each month on his cellular phone. For example, Tom sets his preferences such that Billy can only talk to his best friend Sam for 60 minutes per month. Once Billy has reached that limit, the phone will no longer dial that number or accept incoming calls from that number. When the bill cycle completes, the phone will receive a new bucket message from the network and reset its counter for Sam's number. The limitation extends only to the numbers preselected by Tom. Calls to Tom, or Tom's wife, to 911, 611, or 311, would not be affected.

[0027] FIG. 4 is a block diagram of an embodiment of the device 118. The device 118 includes native applications 404, and downloaded applications 408. Radio 402 includes the hardware and software required to communicate over the wireless network. A JAMS 406 includes Java programs and Java program management capability. Many other known elements of the device 118, such as on-board processors and storage elements, are not shown.

[0028] FIG. 5 is a block diagram of the JAMS 406 in one embodiment. The JAMS 406 includes downloaded Java applications 502 designated A, B, C, and D. The number of downloaded Java applications shown is an arbitrary example. The actual number of downloaded Java applications stored can be greater or less than four, and is only limited by storage capacity. The JAMS 406 also stores a condition catalog 504 and a condition registry 506.

[0029] FIG. 6 is another block diagram of the JAMS 406 showing more detail of the condition catalog 504 and the condition registry 506. The condition catalog 504 includes a list of conditions recognized by the device 118. The condition catalog is populated when the user downloads new user preferences as previously described. Some examples of financial conditions are off-peak rate time, peak rate time, being on the network, roaming for service, and the bucket being empty. The conditions shown are a subset of possible conditions that can be recognized by the device 118. The condition registry 506 includes a list of the conditions recognized by the device 118 for each condition, and which downloadable Java applications (A, B, C, and/or D) should be executed when the condition occurs. For example, when condition 2 (peak rates are current) occurs, application A and B are executed. Application A may be an application that generates a user message that the transition is occurring, while application B may block outgoing calls automatically (subject to user override). In other embodiments, the applications listed in the condition registry include native applications as well as downloaded applications. In other embodiments, the condition catalog and condition registry do not reside on the JAMS, but reside elsewhere on the device.

[0030] Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above”, “below,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application.

[0031] The above detailed descriptions of embodiments of the invention are not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while steps are presented in a given order, alternative embodiments may perform routines having steps in a different order. The teachings of the invention provided herein can be applied to other systems, not necessarily only wireless communication system described herein. The various embodiments described herein can be combined to provide further embodiments.

[0032] These and other changes can be made to the invention in light of the above detailed description. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification, unless the above detailed description explicitly defines such terms. Accordingly, the actual scope of the invention encompasses the disclosed embodiments and all equivalent ways of practicing or implementing the invention under the claims.

[0033] While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as embodied in a computer-readable medium, other aspects may likewise be embodied in a computer-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.