RELATED APPLICATIONS The present application is related to U.S. application Ser. No. ______, (Attorney Docket No. 101948087US) entitled, “Automated Device Behavior Management Based on Network Charging and Rating Conditions” by Christopher White; U.S. application Ser. No. ______, (Attorney Docket No. 101948088US) entitled, “Automated Device Behavior Management Based on Preset Preferences” by Christopher White: and U.S. application Ser. No. ______, (Attorney Docket No. 101948089US) entitled, “Control of Security of Ease-of-Use Sensitivity for a Wireless Communication Device: by Christopher White, all filed on the same day herewith and commonly assigned to AT&T Wireless Services, Inc.
The disclosed embodiments relate to configuring a wireless device to automatically invoke various applications based on the occurrence of events or conditions.
Current wireless communication devices such as cellular phones and various handheld devices typically include one or more “native” application programs stored on the device by the manufacture to perform specific functions. For example, cellular phones have a call controller native application that receives and recognizes keypad inputs and responds appropriately. If the keypad entry is a valid phone number, the call controller responds by attempting to establish a communication channel with the device identified by the number.
At present, remote execution of applications on a device is done by determining, at the provider side, what the device is to do, under what conditions the device is to do it, and what applications will be executed. Currently, a signal can be sent to a device to cause the device to take a predefined action. A small subset of these actions can be invoked remotely by the user or the wireless service carrier, or provider. For example, a short message service (“SMS”) message can invoke a particular program.
As a more detailed example, some handheld devices can receive a signal that causes the device to notify the user a certain stock price has been reached. This is an example of a specific application on the wireless device performing a particular action in response to a predetermined signal. On the provider side, in response to an event (the stock reaching a predetermined price), a provider merely creates a text message and sends it to the device for display. The human user must read the message and decide how to act on it.
The ability of the user to configure automatic device behavior and the ability to remotely invoke application on a device is very limited. Currently, remote device configuration is typically done by the provider at a level below the application level. Another limitation of the current server-side remote device application invocation is the provider must know what applications are on the device and how each is configured. This does not usually present a problem because most devices, for example most cellular phones, do not store applications other than the native applications installed by the provider. In the near future, most or all cellular phones and other mobile devices will support user-downloaded applications from various third parties. Each of these downloaded applications must be configured individually by the user. Each user may configure an application differently on a device. The variety of configurations is potentially unlimited. Therefore, the current model of provider remote invocation of device behavior becomes unworkable with downloadable applications because the provider no longer knows what the device is capable of, or exactly how it performs tasks it is capable of.
Overall, there is a need for an improved user-configurable wireless device that recognizes events and conditions specified by the user and automatically performs a series of user user-configured actions using one or more user-configured applications.
FIG. 1 is a diagram of an embodiment of a wireless communication system.
FIG. 2 is a flow diagram of one embodiment of device configuration.
FIG. 3 is a flow diagram of one embodiment of remote application invocation.
FIG. 4 is a diagram of an embodiment of a wireless communication device.
FIG. 5 is a diagram of an embodiment of a Java application management service (“JAMS”).
FIG. 6 is another diagram of an embodiment of a wireless communication device.
Embodiments of the invention, described below, include a mobile communication device that automatically receives signals indicating events, and automatically takes actions in response to the events. The actions include executing one or more software applications on the device. The applications include native applications and downloaded applications that are individually configured. The events and the actions taken are configurable by a user of the device. In one embodiment, the user configures preferences that are stored by a wireless communication service carrier or provider. The provider remotely updates configuration data in the device transparently to the user. In an embodiment, the configuration data includes a list of events recognized by the device, and a list that relates those events to applications to be executed in response to the events. After the configuration data is updated, the wireless device communicates with the provider network such that each of the recognized events automatically causes desired device behavior without intervention by the user. 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.
FIG. 1 is a diagram of an embodiment of awireless communication system100. Thesystem100 is arbitrarily divided into two areas.Area104 includes equipment and applications (“provider equipment”) typically provided and maintained by a wireless communication service provider, such as a cellular phone service provider.Area102 includes equipment and applications (with the exception of radio tower116) that are typically not provided or maintained by the provider, but are designed to communicate on a wireless network with the provider equipment.System100 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.
Thearea104 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.Provider applications106 are software applications that maintain and administer the network. For example, theapplications106 include billing applications, performance monitoring applications, and many more. Theapplications106 include applications that track user accounts, 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 device. For example, some enterprises provide groups of employees with devices for limited or unlimited use in the course of employment.
Thearea104 further includes a database ordatabases108 and110. Thedatabases108 and110 are shown separately to distinguish the types of data stored, but could be one physical entity or more than two physical entities. Thedatabase110 is a billing database that stores data used by the provider to generate bills for an account. Billing data includes minutes used at different rates, and the number of minutes allowed in a time period before special rates apply, for example.
Auser preferences database108 stores a user's choices regarding what events 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 an event occurs. One example is the device automatically blocking all outbound calls upon the transition from off-peak billing rate time to on-peak billing rate time.
A short message service controller (“SMSC”)114 manages short messaging, including receiving/sending, generating, and encoding/decoding SMS messages. Thewireless communication device118 communicates over the wireless network using radio towers such asradio tower116 in the known manner. Anevent manager112 recognizes events and sends a message to the SMSC in response.
Auser120 of awireless communication device118 may configure the user preferences by accessing a dedicated provider configuration application (one of the applications106). Theapplications106 may be accessed using thedevice118, or using apersonal computer122 to access theapplication106 via theInternet124. The user preferences are developed by the provider configuration application based on user inputs and downloaded from the provider to thedevice118. Thedevice118 includes downloaded applications (not shown inFIG. 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. Theuser120, however, knows which downloaded applications are present on thedevice118 and how they are configured to behave. Theuser120 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.
FIG. 2 is a flow diagram illustrating an embodiment of thedevice118 configuration. Referring toFIG. 1 andFIG. 2, at202 the user individually configures the downloaded applications on thedevice118. Then, the user configures the user preferences at204, and the user preferences are stored (at206) in thedatabase108. When a new user configuration is stored for an account, a message is sent to the short message service controller (“SMSC”)114 at208. At210, theSMSC114 generates an encoded SMS message to thedevice118 that indicates a new user configuration is available to be downloaded. At212, thedevice118 opens a communication channel to theprovider equipment104 to retrieve the new configuration data. In one embodiment, the encoded message reaches thedevice118, indicating that thedevice118 is receiving a general packet radio service (“GRPS”) signal. In one embodiment, the condition “Home GPRS Available” is in the signal. Thedevice118 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 at214.
For the purpose ofdevice118 configuration, out-of-band signals are exchanged between thedevice118 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.
FIG. 3 is a flow diagram illustrating an example of automatic conditional application invocation. Referring toFIG. 1 andFIG. 3, At302, a message is sent to theevent manager112 to indicate that a specific event has taken place. As one example, thebilling database110 sends a message to theevent manager112 that indicates a minute “bucket” for the account has only ten more minutes left in it. At304, theevent manager112 sends a message to theSMSC114 requesting that an encoded message be generated. The SMSC encodes the message and sends it to thedevice118 at306. At308, thedevice118 receives and decodes the message, and sends a return message to retrieve the event from theevent manager112. At310, thedevice118 receives the event from theevent manager112 and processes the event using an event registry as described below. In an alternative embodiment, the SMS message sent to the device on the occurrence of an event includes the information regarding the event. In this embodiment, therefore, the device does not retrieve the event from the event manager.
FIG. 4 is a block diagram of an embodiment of thedevice118. Thedevice118 includesnative applications404, and downloadedapplications408.Radio402 includes the hardware and software required to communicate over the wireless network. AJAMS406 includes Java programs and Java program management capability.
FIG. 5 is a block diagram of theJAMS406 in one embodiment. TheJAMS406 includes downloadedJava applications502 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. TheJAMS406 also stores anevent catalog504 and anevent registry506.
FIG. 6 is another block diagram of theJAMS406 showing more detail of theevent catalog504 and theevent registry506. Theevent catalog504 includes a list of events recognized by thedevice118. The event catalog is populated when the user downloads new user preferences as previously described. Some examples of events are the transition from off-peak time to on-peak time and the reverse, the transition from being on the network to roaming and the reverse, and the occurrence of a new bucket for the account. The events shown are a subset of possible events that can be recognized by thedevice118. Theevent registry506 includes a list of the events recognized by thedevice118 for each event, and which downloadable Java applications (A, B, C, and/or D) should be executed when the event occurs. For example, when event1 (off-peak to on-peak transition) occurs, application A and C are executed. Application A may be an application that generates a user message that the transition is occurring, while application C may block outgoing calls automatically (subject to user override). In other embodiments, the applications listed in the event registry include native applications as well as downloaded applications. In other embodiments, the event catalog and event registry do not reside on the JAMS, but reside elsewhere on the device.
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.
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.
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.
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.
