ACCOUNT INFORMATION DISPLAY FOR PORTABLE COMMUNICATION DEVICE

TECHNICAL FIELD

[0001] The disclosed embodiments relate to user interfaces for portable communication devices.

BACKGROUND

[0002] Users of portable communication devices (e.g., mobile telephones, handhelds, media players, personal digital assistants (PDAs), BlackBerry™, pocket PCs, Smart Phones, etc.) typically enter into service contracts with service providers for voice and/or data services. The services are often organized into service plans that can be subscribed to by the user. Service plans can provide data services, voice services or a combination of voice and data services often referred to as "bundled" services. The service plans typically allocate limited amounts of minutes, bandwidth or storage based on the price of the plan. A voice service plan, for example, may charge a flat monthly fee for 400 "anytime" minutes and 200 night and weekend minutes. If the user exceeds these limits during the month they incur additional charges for each additional resource unit consumed, typically at a higher rate (e.g., $0.45/min) than the average rate (e.g., $0.15/min) for budgeted resource units. A data service plan, for example, may have a flat monthly fee for a certain amount of data storage capacity (e.g., 100 MB) for email and other data, as well as a surcharge rate (e.g., $0.01/MB) if the user consumes additional capacity during the month.

[0003] At present, users do not have a convenient way to review the current account balance(s) of service plans. If a user wants to know an account balance they must log into their account(s) on a Web page, call customer service, or send a special command via their mobile telephone. Thus, there is a need for improved access to user account balance and other account usage information.

SUMMARY OF EMBODIMENTS

[0004] In some embodiments, a portable communication device includes a display and a processor coupled to the display. The processor is configured to automatically and repeatedly present an updated account usage metric for an account associated with usage of the portable communication device. In some embodiments, the presented account usage

metric is an account balance associated with usage of the portable communication device, and the processor automatically and repeatedly presents an updated account balance on the display.

[0005] In some embodiments, a method of displaying an account balance on a portable communication device comprises: downloading account information from a service provider in response to detection of a trigger condition; updating a graphical object based on the account information; and displaying the updated graphical object on the portable communication device.

[0006] In some embodiments, a computer-readable medium includes instructions, which, when executed by a processor in a portable communication system, causes the processor to perform the operations of: downloading account information from a service provider in response to detection of a trigger condition; updating a graphical object based on the account information; and displaying the updated graphical object on the portable communication device.

[0007] In some embodiments, a graphical user interface on a portable communication device includes a graphical object that automatically and repeatedly displays an updated account usage metric associated with usage of the portable communication device.

[0008] Thus, the present invention provides improved devices, methods, and user interfaces for accessing account usage data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a better understanding of the aforementioned embodiments of the invention as well as additional embodiments thereof, reference should be made to the Description of Embodiments below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.

[0010] Figure 1 is a schematic diagram of one embodiment of a portable communication device for displaying one or more account balances.

[0011] Figures 2 A, 2B, 2C and 2D are illustrations of embodiments of meters for displaying account balances.

[0012] Figure 3 is a an illustration of one embodiment of a user interface that includes a pull-down menu containing account-related actions.

[0013] Figure 4 is a flow diagram of one embodiment of an account update process flow.

[0014] Figure 5 is a block diagram of one embodiment of an architecture for the portable communication device shown in Figure 1.

DESCRIPTION OF EMBODIMENTS

[0015] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Overview of User Interface

[0016] Figure 1 is a schematic diagram of one embodiment of a portable communication device 100 for displaying one or more account balances. The device 100 includes a display surface/graphical user interface (GUI) 102 and one or more graphical objects 108 for displaying information associated with a service account. In some embodiments, the display surface 102 is a multi-touch sensitive display, analogous to the multi-touch sensitive- touchpad described in U.S. Patent No. 6,323,846, issued November 27, 2001, entitled "Method and Apparatus for Integrating Manual Input," which is incorporated by reference herein in its entirety. Tn contrast to the touchpad in U.S. Patent No. 6,323,846, the display surface 102 can be transparent to enable the user to see and interact with the graphical object 108.

[0017] In some embodiments, the GUI 102 includes a tray portion 106 and a window

104. The tray portion 106 holds graphical objects (icons, widgets, etc.) that represent frequently used applications (e.g., email, address book, browser, music, etc.). The window 104 can be used to store other graphical objects, Web pages or other data, and/or provide a mechanism for user input (e.g., via a virtual keyboard). The graphical object 108 is used to

display information related to a service account, such as an account for providing voice and/or data services to the user of the device 100. In some embodiments, the graphical object 108 is downloaded from a network and presented in the GUI 102. In other embodiment, data and/or instructions for generating the graphical object 108 are stored locally in the device, but one or more parameter values for controlling the visual state of the object are downloaded from a network, and the resulting graphical object 108 is present in the GUI 102. In either case, the user can select the object 108 (e.g., by tapping on or near the object 108), which causes the object 108 to open at a default location in the GUI 102 (e.g., at the top of GUI 102).

[0018] In some embodiments, the graphical object 108 is an "analog" type meter

(e.g., similar to a heat gauge) that includes an arrow that indicates (A) a remaining balance on an account, and/or (B) whether the user's resource usage rate (sometimes called the "burn rate") is less than, approximately equal to, or greater than an average resource usage rate associated with a predefined or user-selected budget for the account. The state of the graphical object 108 may indicate a prediction as to whether the user will prematurely exhaust the account prior to the expiration of an accounting time period. In some embodiments, as the user uses account resources (minutes, bandwidth, data storage capacity or any other asset or resource for which there is an account balance), the meter is automatically, without user action, updated to reflect the corresponding change in account status.

[0019] When the graphical object 108 indicates an account balance, the account balance metric will depend on the type of service account to which the subscriber has subscribed. As described below, some embodiments of the invention are consistent with multi-service accounts in which the user's resource budget (e.g., for a defined period of time, sometimes herein called an accounting period) is defined by a linear combination of resource usage amounts. For example, a particular account may provide a user with a combined monthly budget for voice and data transmission services, where transmission of N megabytes (MB) of data (e.g., 20 megabytes) is treated as equivalent to one minute of voice transmission usage. In another example, another account may provide a user with a combined monthly budget for voice transmission services, data transmission services, SMS messaging services, data storage services, and perhaps other services as well. In these embodiments, the service provider and/or the device may compute a "combined usage metric" indicative of the total

resources used during an accounting period (e.g., a current or prior accounting period) as follows:

usage_metric = ^w ₁ x (usage of resource i) (1)

where i is an index having distinct values associated with two or more distinct resources, wi is a weight associated with resource i, and "usage of resource i" is a measurement of the amount of resource i used during the relevant accounting period. In some embodiments, the weights, Wj may correspond to the monetary cost per unit of resource i used, and the combined usage metric may be a monetary value indicating either a total cost, or the amount of the user's budget that has been consumed. In some embodiments, the weights may be a function of the amount of resource usage during the accounting period. For instance, one or more of the weights may increase or decrease when the usage metric passes a threshold or budget amount. Alternately, individual weights may increase or decrease when the corresponding resource usage amount passes a threshold or budget amount.

[0020] The graphical object 108 can include one or more indicia which provide feedback to the user, such as "color zones" that indicate by color the account activity or balance. For example, the graphical object 108 can be a meter with multiple color coded zones. If the user's resource usage rate is high (compared with the average usage rate allowed by the user's account type or budget) or the account balance is low, then the arrow in the graphical object points to the color A (e.g., red) zone. Likewise, if the user's resource usage rate is low (compared with the average usage rate allowed by the user's account type or budget) or the account balance is high then the arrow points to the color C (e.g., green) zone. A color B (e.g., yellow) zone can indicate a moderate resource usage rate (compared with the average usage rate allowed by the user's account type or budget) or account balance. In some embodiments, the arrow itself can change colors to provide additional indicia of account status.

[0021] Tn some embodiments, the graphical object 108 provides a single metric for multiple services. For example, if a user has subscribed to both voice and data services, the individual metrics for each type of resource usage can be combined into a single resource usage metric. In some embodiments, the combined usage metric is computed using equation (1), shown above. However, in some other embodiments, it may be more useful for

the metric used by the graphic object to indicate the remaining balance in the user's account for a current accounting period:

object_metric = (budget - usage_metric)/nf, (2)

where the combined usage metric, usage_metric, is as defined above in equation (1) and nf is a normalization factor. The scale factors used to compute the combined usage metric can be used to weight and/or convert the dimensions of the account balances. For example, if data transmission is measured in megabytes and voice transmission is measured in minutes, then the scale factors can convert the usage amounts into a common unit (e.g., dollars). In this example, W ₁ (for voice transmission) and W ₂ (for data transmission) can be $0.20/min and

$.01/MB, respectively. Optionally, the objectjmetric can be normalized by the normalization factor nf to fit within the range of the meter 108 using known normalization or linear scaling techniques. For instance, if the normalization factor is set equal to the budget, then the resulting universaljαietric indicates the fraction of the budget that remains unused. If the normalization factor is set equal to 1, then the resulting universal_metric is equal to the user's remaining budget or account balance.

[0022] To obtain an object metric that is indicative of whether the user's resource usage rate is higher or lower than the average rage associated with an account budget or subscription plan, the following computation may be performed:

usage_rate_metric = 1 - ((usage_metric/usagejperiod)*(budgetjperiod/budget)

(3)

where the "budget" is the resource usage budget for a predefined accounting period, the "budget_period" is the number of days (or other time units) in the accounting period, and the usage_period is the number of days (or other time units) of the budget_period that have already expired. The usage_rate_metric is negative when the rate of resource usage exceeds the average usage rate allowed by the account budget or subscription plan, is equal to zero when the rate of resource usage exactly equals the average usage rate allowed by the account budget, and is positive when the rate of resource usage is less than the average usage rate allowed by the account budget.

[0023] The graphical object 108 can be presented in the GUI 102 automatically, on an ongoing basis and without user action. For instance, the graphic object 108 may be displayed whenever a main menu or navigation page is displayed, and whenever the device is actively using account resources, such as during a telephone call or data transfer. Alternately, the graphical object 108 can be activated by one or more taps by the user's fingers or a stylus. In some embodiments, the user can choose how to display graphical object 108, e.g., as part of specifying user preferences. The graphical object 108 can have attributes typically associated with graphical objects, such as the ability to be moved or resized anywhere in the GUI 102. The graphical object 108 can include various buttons or other mechanisms for minimizing, restoring and closing the object 108. The graphical object 108 can include text associated with one or more account balances, such as the actual number of minutes, megabytes or other resource units used or remaining. The graphical object can optionally include other text as well, such as text indicating an account type, account budget (e.g., monthly budget), or the like. Furthermore, the graphical object can optionally include color, fill patterns or the like, to convey additional account status (or resource usage) information.

[0024] The configuration of the portable device 100 shown in Figure 1 is exemplary and other configurations are possible. For example, the graphical object 108 can be any type of object, such as a gauge, meter, dial, bar, graph, chart, animation, button, etc. In some embodiments, the user can be provided with a preference pane for selecting among a list of predefined meter types. Some additional examples of graphical objects 108 are shown in Figures 2A, 2B, 2C and 2D.

[0025] Figures 2A, 2B, 2C and 2D are illustrations of other embodiments of meters for displaying multiple account balances. Figure 2A shows a horizontal bar meter 200, having a single horizontal bar 202 that is partially filled 204 to show how much of an account budget has been consumed and how much remains as the account balance. The horizontal bar meter

200 may be rectangular, or may have rounded edges, or may have other shape variations and/or embellishments. In some embodiments, the meter 200 includes text 206 indicating the account type or budget. The meter 200 may optionally include text 208 that indicates an account balance. The graphically displayed meter state, and the optional associated text (account budget 206 and/or account balance 208) may reflect an account balance (or usage amount) for a single type of resource (e.g., voice transmission minutes), or the meter and optional text may reflect an account balance (or usage amount) for two or more resources for which a combined balance or usage metric has been established. Multi-resource accounts and

metrics are discussed above. Figure 2B shows another horizontal bar meter 210 having a single horizontal bar, as well graphics 211 and/or text 212 for representing the amount by which an account budget has been exceeded.

[0026] Figure 2C shows a digital type meter 220 that includes one or more horizontal bars 222, 224, representing account balances. For example, the top bar 222 can display an account balance for voice services, such as the amount of monthly minutes remaining in a voice services account. The lower bar 224 can display an account balance for data services, such as the amount of monthly storage capacity remaining in a data services account. In some embodiments, the bars 222, 224, can be combined into a single bar displaying a universal unit for both services similar to the meter 108 shown in Figure 1, or the meter shown in Figure 2A. In some embodiments, the actual value of the account in appropriate units is displayed proximate to the bars 222, 224, to provide further account information.

[0027] Another type of graphical object 240 is shown in Figure 2D. The graphical object 240 in Figure 2D replaces the bars 222, 224, in Figure 2C with an array of segments 242, 244, that change color or fill pattern to show the remaining account balance or usage rate. For example, as the segments 242, 244 enter various balance or usage ranges, they can change colors from, for example, green to yellow to red. The segments 242, 244, can be any geometric shape, such as circles, squares, rectangles and the like.

[0028] Although the meters shown in Figures 2A - 2D used horizontal bars, other orientations (e.g., vertical) and shapes (e.g., circles) may also be used.

Menu System Embodiment

[0029] Figure 3 is a an illustration of one embodiment of the user interface 102 that includes a pull-down menu 300 containing account-related options. In some embodiments, the user can tap on the display surface 102 at or near the object 108, or on a designated hot spot or button to invoke the pull-down menu 300. The menu 300 can include several actions that can be selected by the user via touch input, including but not limited to changing a billing plan, increasing budget for a service account, and computing and/or displaying a detailed usage analyses. Each of these actions can result in a submenu 302 being presented to the user. For example, the usage analyses option might invoke a submenu 302 including options for voice services and data services.

[0030] The menus 300, 302 can include all the attributes typically associated with pull-down menus, such as "stickiness" and "highlighting." The menus 300, 302 can be part of a menu hierarchy having multiple layers depending upon the number and types of actions.

[0031] In some embodiments, the requested actions can be performed in the device 100. In other embodiments, the requested actions are fulfilled by a server computer on a network (e.g., a server on a wireless network). The server can be any device capable of connecting with the device 100 through a network and providing a service or data to the device 100. In some embodiments, other actions may result in a telephone call being initiated. For example, if a user selects a Change Calling Plan option then the device 100 can connect the user to a customer service representative who can then change the user's calling plan.

[0032] In some embodiments, there can be interaction with a network server that is transparent to the user of the portable communication device 100. For example, if the user selects Usage Analysis, then the device 100 can contact the service provider's network server and download data needed to perform the usage analysis. The device can then perform the analyses and display the results to the user. Alternatively, in some embodiments the server performs the usage analysis and sends only the results to the device 100 for display.

[0033] In some embodiments, a Web session is established with a Web page server that provides Web pages that enable the user to accomplish various tasks, such as requesting additional minutes or storage capacity, or conferring with technical support personnel or a customer service representative.

[0034] In some embodiments, certain trigger conditions can result in an action being performed by the device 100 alone or in combination with a network server. For example, the object 108 may automatically initiate certain actions when an account balance or resource usage rate reaches a threshold level. In some embodiments, when an account balance drops below a respective threshold value (e.g., determined by the user's account time, or determined by a user selection in a preference pane), then the menu 300 is automatically displayed and the user is prompted to make a selection. Alternately, or in addition, when a resource usage rate rises above a respective threshold value, the menu 300 is automatically displayed and the user is prompted to make a selection. In some embodiments, the device

100 generates an audio or visual message to indicate that a condition has been triggered, such

as, for example, one or more tones, a music clip, a computer-generated announcement or a text message displayed in the window 104.

Account Update Process Flow

[0035] Figure 4 is a flow diagram of one embodiment of an account update process 400. While the parameter adjustment process 400 as described here includes a number of operations that appear to occur in a specific order, it should be apparent that the process can include more or fewer steps or operations, which can be executed serially or in parallel (e.g., using parallel processors or a multi-threading environment).

[0036] The process 400 begins by detecting (402) one or more trigger conditions. The trigger conditions can be automatically triggered by the portable communication device or by a service provider that is providing services to the user of the device. For example, a trigger condition can occur whenever a predefined amount of resource usage (e.g., one minute of voice transmission, 20 MB of data have been transmitted, etc.) has occurred. Alternately, or in addition, a trigger condition can occur when one or more account usage amounts, or usage rates, exceed a threshold set by default, by the service provider, or by the user, or when an account balance reaches or falls below a threshold. Another trigger condition can be the initiation of a connection between the device and the service provider, such as when the device is powered on or a connection is re-established after an interruption (i.e., a temporary loss of the connection). As noted, these trigger conditions can be detected by the device or by a service provider, depending on the implementation or embodiment. In some embodiments, another trigger condition can occur if the user manually selects a menu option (e.g., analyze device or service usage, change calling plans) or taps (or otherwise selects or signals) the usage meter. However, in other embodiments, all trigger conditions for updating usage metrics are automatic triggers that are outside the direct control of the user. In some embodiments, the trigger conditions occur periodically (e.g., every minute, 10 minutes, or hour) rather than episodically (e.g., in response to one of the predefined conditions described above).

[0037] After a trigger condition is detected the device downloads (404) account information from the service provider for the account. In some embodiments, the device establishes a secure network connection (e.g., SSL connectivity) with a service provider computer. The device can then send a message requesting the user's account information.

The message can include identifying information (e.g., MSID) that can be used by the service provider to verify the device and the user. In some embodiments, the account information is sent in an encrypted format using a known cryptography scheme (e.g., symmetric key, elliptic curve, etc.) and must therefore be decrypted by the device before being processed.

[0038] The account information downloaded from the service provider is then used to update (406) one or more account metrics. For example, a universal metric can be updated as described above with respect to Equation 1, 2 and/or 3. In some embodiments, this operation is optional if the service provider performs the update and sends the updated metric to the device. After the metric is updated, the one or more graphical objects (and any associated text) are updated (408) to reflect the change in the one or more accounts. The updated graphic object is displayed on the device, thereby providing the user with updated account status information. For example, the arrow in the graphical object 108 shown in Figure 1 (the heat gauge) can be adjusted as appropriate to reflect a resource usage rate or account balance.

[0039] The present invention can also be used when the account associated with a portable communication device is a multi-user account (also sometimes called a shared account or multi-device account), such as a "family plan" account that provides services to two or more portable communication devices. Tn such embodiments, the graphical object 108 may be configured to present the account balance and/or other account metric(s) for the entire multi-user account. The triggering conditions) for updating the graphical object 108 for embodiments that utilize multi-user accounts may be detected by one or more service provider servers, with updated account information or metrics being sent in response to the trigger conditions to one or more of the portable communication devices that is participating in the multi-user account and that is currently powered on or otherwise capable of receiving the account information or metrics.

Portable Communication Device Architecture

[0040] Figure 5 is a block diagram of one embodiment of the internal architecture for the portable communication device 500 shown in Figure 1. The portable communication device 500 generally includes one or more computer-readable mediums 502 (often called memory or storage devices), a processing system 504, an Input/Output (I/O) subsystem 506, radio frequency (RF) circuitry 508 and audio circuitry 510. These components communicate over one or more communication buses or signal lines 503, which may include a combination

of data, address and control lines. The device 500 can be any portable communication device, including but not limited to a mobile telephone, a media player, a personal digital assistant (PDA) or the like.

[0041] It should be apparent that the architecture shown in Figure 5 is only one example of an architecture for a portable communication device 500, and that the device 500 could have more or fewer components than shown, or a different configuration of components. The various components shown in Figure 5 can be implemented in hardware, software or a combination of both hardware and software.

[0042] The RF circuitry 508 is used to send and receive information over a wireless link or network to one or more other devices and includes well-known circuitry for performing this function, including but not limited to an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, memory, etc. In some embodiments, the RF circuitry 508 is capable of establishing and maintaining communications with other devices using one or more known RF communication protocols (e.g., TDMA, CDMA, etc.) and one or more known mobile networking protocols (e.g., GSM, ANSI-41, etc.). In other embodiments, the device 500 communicates with other devices over the Internet using Voice-Over-Tnternet Protocol (VoIP).

[0043] The RF circuitry 508 and the audio circuitry 510 are coupled to the processing system 504 via the peripherals interface 516. The interface 516 includes various known components for establishing and maintaining communication between peripherals and the processing system 504. The audio circuitry 510 is coupled to an audio speaker 542 and a microphone 544 and includes known circuitry for processing voice signals received from interface 516 to enable a user to communicate in real-time with other users. In some embodiments, the audio circuitry 510 includes a headphone jack (not shown). Voice and data information received by the RF circuitry 508 and the audio circuitry 510 (e.g., in speech recognition or voice command applications) is sent to one or more processors 518 via the interface 516. The one or more processors 518 are configurable to process various data formats for one or more applications 530.

[0044] Note that the term "data" includes but is not limited to text, graphics, Web pages, JAVA applets, emails, instant messages, voice, digital images or video, MP3s, etc.,

which can be used by one or more applications 530 (e.g., web browser, email client, telephone communication client, etc.) stored in medium 502. In some embodiments, the device 500 is capable of uploading and downloading various objects from the Internet over a wireless network or an external port 536, such as files, songs, digital images, videos, emails, instant messages, widgets (i.e., application programs), and the like.

[0045] The one or more processors 518 communicate with the one or more computer- readable mediums 502 via a controller 520, sometimes called a memory controller. The computer-readable medium 502 can be any device or medium that can store code and/or data for use by the one or more processors 518. The medium 502 can include a memory hierarchy, including but not limited to, cache, main memory and secondary memory. The memory hierarchy can be implemented using any combination of RAM (e.g., SRAM, DRAM, DDRAM), ROM, FLASH, magnetic and/or optical storage devices. In some embodiments, the medium 502 may further include storage remotely located from the one or more processors 518, for instance network attached storage accessed via the RF circuitry 508 or external port 536 and a communications network (not shown) such as the Internet, intranet(s), Local Area Networks (LANs), Wide Local Area Networks (WLANs), Storage Area Networks (SANs) and the like, or any suitable combination thereof.

[0046] The one or more processors 518 run various software components stored in the medium 502 to perform various functions for the device 500. In some embodiments, the software components include an operating system 522, a communication module 524, a contact/motion module 526, a graphics module 528, one or more applications 530 and a meter module 532.

[0047] The operating system 522 (e.g., Darwin, RTXC, LINUX, UNIX, OS X,

WINDOWS, or an embedded operating system such as VxWorks) includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.

[0048] The communication module 524 facilitates communication with other devices over one or more external ports 536 and the RF circuitry 508, includes various software components for handling the transmission and receipt of data via the RF circuitry 508 and/or the external port 536. The external port 536 (e.g., USB, FireWire™, etc.) is adapted for

coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.).

[0049] The graphics module 528 includes various known software components for rendering, animating and displaying graphical objects in a GUI/ display surface of the multi- touch sensitive display system 512. Note that the term "graphical object" includes any object that can be displayed to a user, including without limitation text, web pages, icons, digital images, animations and the like.

[0050] The one or more applications 530 can include any applications installed on the device 500, including without limitation, a browser, address book application, contact list application, email client, instant messaging client, word processing application, keyboard emulation application, widgets, JAVA-enabled applications, encryption application(s), digital rights management, etc.

[0051] The contact/motion module 526 includes various software components for performing various tasks associated with the multi-touch sensitive display system 512, such as receiving and processing multi-touch input from the user.

[0052] The meter module 532 includes various software components for performing the various tasks associated with the meter 108, as previously described with respect to Figures 1-4. In some embodiments, portions of the meter module 532 can be implemented in hardware.

[0053] The I/O subsystem 506 is coupled to the multi-touch sensitive display system

512 and, in some embodiments, one or more other physical control devices 514 (e.g., pushbuttons, switches, dials, LEDs, etc.) for controlling or performing various functions, such as power control, speaker volume control, ring tone loudness, keyboard input, scrolling, hold, menu, screen lock, clearing and ending communications and the like. The multi-touch sensitive display 512 communicates with the processing system 504 via a multi-touch sensitive screen controller 540 which includes various components for processing user input (e.g., scanning hardware).

[0054] The device 500 also includes a power system 538 for powering the various hardware components. The power system 538 can include a power management system, one or more power sources (e.g., battery, AC), a recharging system, a power failure detection

circuit, a power converter or inverter, a power status indicator (e.g., LED or status indicator on the display 512) and any other components typically associated with the generation, management and distribution of power in portable devices.

[0055] The disclosed embodiments arc not intended to be exhaustive or limited to the precise forms disclosed. Many modifications and variations to the disclosed embodiments are possible in view of the above teachings.