Methods and systems for mobile telepresence

Exemplary methods and systems relate to telepresence at mobile devices. Aspects comprise dynamic configuration of video provided from a server that intermediates between a mobile device and a telepresence system during a telepresence session. The server receives high definition video from the telepresence system and transcodes into a format that can indicated by the mobile device. The mobile device can dynamically update the format in response to real-time battery life and network interface status. A progressive reduction in bandwidth and power consumptive activities can be implemented. The device can implement face detection and face centering, front/back mobile device camera switching, and automatic contrast control and other video quality controls in an outgoing video stream.

BACKGROUND

The following relates to data-enabled mobile devices, such as data-enabled mobile phones, digital assistants, smartphones, and more particularly to enabling telepresence on mobile devices.

2. Related Art

Telepresence uses high quality video and audio to enable virtual gatherings. Telepresence typically relies on very high bandwidth connections between fixed points, such as between two telepresence studios. Each telepresence studio is often carefully designed to provide a high quality experience, including carefully controlling for acoustic effects, and lighting. High quality displays, such as full 1080p displays, are provided, as well as high-definition cameras that include features such as auto-focusing on a current speaker, and switching of a video stream for such focus.

Providing a telepresence experience on a mobile device would be desirable, but remains challenging because of various differences between an environment in which a mobile device operates and the typical telepresence installation.

DESCRIPTION

The following description provides examples and other disclosure, which teach those of ordinary skill in the art how to practice implementations and embodiments of the present disclosure. As such, the description is not limiting, but rather is exemplary.

For convenience, in this description, the term “mobile device” is generally used to refer to any portable or mobile network-enabled device that has capabilities comparatively limited to a state of the art non-mobile network-enabled device. Categories of mobile devices include smartphones, netbooks, cellular phones, and laptops. Each of these categories is more limited in one or more types of capability, than a wired desktop computer, or an installation of computers provided at a fixed site. For example, smartphones, cellular phones and netbooks typically have limited, smaller sized, and lower resolution displays. All these devices are intended to run on batteries, and therefore, power consumption is an important consideration. All these devices include a wireless communication capability, and in some cases, wireless communication is a primary or only means of communication for such a device. Wireless communications are often less reliable, more variable, and lower bandwidth than a wired connection. Smartphones and cell phones typically also are held while being used, rather than being placed on a surface. Smartphones and cell phones also typically have reduced size keyboards, no keyboard, and possibly a touch screen for receiving input.

Such example differences between these types of devices and equipment used in a typical telepresence installation calls for enabling telepresence on these types of devices by implementing features, and techniques described herein. Such features and techniques can be implemented in systems, which can operate according to methods described herein. In some aspects, a desired composition of telepresence session data is determined at a mobile device, and provided to a remote server that assembles the telepresence session data according to this desired composition. The desired composition can include a specified composition of video streams available at the remote server, which pertain to the telepresence session in which the remote device participates. Thus, the telepresence session data sent to the mobile device can comprise a video stream. The video stream, as explained herein, can be formed from one or more video streams available at the server. The server can make a composite video stream by reducing resolutions of the input streams according to a specified display resolution of the remote device. Other techniques and aspects are explained below.

FIG1depicts a logical organization of an example telepresence architecture100in which elements described below can function (FIG2presents aspects of an example physical organization of such an architecture). A telepresence system110can be provided, for example, in a specially-designed room at a corporation or at a conference hosting service. Telepresence system110can interface devices provided in a telepresence studio, collectively represented by telepresence studio devices107. Such devices can include a plurality of high definition video cameras, microphone arrays, high definition display devices, and devices to accept control commands from participants in a conference at that location. Telepresence system also can provide functionality to other devices, including voice-only devices105and computers103. The characteristics of such devices generally will dictate what kinds of services can be provided by telepresence system110to them. For example, a computer with a large display, a good quality microphone and camera installation, and a fast network connection can have capabilties similar to that provided by devices in studio107, although an environment in which the computer103generally will not be as carefully controlled as that of studio107.

Telepresence system110interfaces with a mobile telepresence server115over one or more network connections, which can comprise public and provide networks, which can be interconnected through routers. For example, system110and server115can be connected using the Internet, and preferably system110and server115are connected using low latency and high bandwidth communication links, which provide capability to implement quality of service (QoS) techniques. Mobile telepresence server115communicates through a network(s)120with telepresence-enabled mobile devices125and130(for convenience, hereinafter identified as mobile devices). Network(s)120can comprise a plurality of physical networks or different networks at different times, as explained in further detail with respect to FIG2.

Logical flows of data that will be described further below include data flows between mobile devices125130and telepresence server115. These data flows include video uplink136between devices125and130, video downlink138from server115and each of devices125and130, audio channel148, and control uplink140, which is representative of transmission of control commands and status information described below. Other data flows can include a secondary data uplink146, which can be used, for example, in uplink of application data, such as a presentation, spreadsheets, and other data that may be a topic for discussion during a telepresence session. FIG1depicts an example where separate TCP or UDP flows can be provided for each device, and for each type of data being exchanged. For example, a separate UDP flow can be provided for each of devices125and130video uplink and for each downlink received by each of devices125and130. Other embodiments can be provided in accordance with this description.

Similarly, logical flows of data between server115and telepresence system110can include video uplink134, video downlink132, audio uplink142and downlink141channel142, and data uplink144and downlink145. These identified communication uplinks and downlinks each can be implemented as separate flows, or can be implemented as a unified flow with elements that can be parsed by the respective recipient of the data. For example, separate UDP or TCP sessions can be made for each data type, or each uplink and downlink, or one UPD or TCP session for each telepresence occurring, or other implementations, as may be appropriate. Server115mediates between telepresence system110and mobile devices125and130to provide enhanced telepresence-like services to those devices.

In embodiments using TCP/IP, server110can terminate TCP sessions of mobile devices125and130and establish new TCP/IP sessions with telepresence system110on behalf of mobile devices125and130.

FIG2depicts further aspects of an example implementation of architecture100. FIG2depicts that mobile telepresence server115can have a connection to public network210and to a broadband wireless network224, such as a cellular network, and by more particular example, a data-enabled network, such as GPRS, EDGE, CDMA-W, LTE, UMTS, and so on. Network224can implement a voice quality channel202, which can be used to carry voice data between mobile device125and server115(device130not illustrated in FIG2). Network224also comprises a data channel that here can be used for transmission of video data and other data, as described with respect to FIG1, and below. Public network210also can couple with a local area network wireless access point (e.g., an IEEE 802.11 series access point). Device125can implement interfaces for both the cellular network and for the local area wireless network. Public Network210also can couple with a firewall212, which in turn can communicate through a router214to telepresence system110(firewall212and router214can be implemented together, as well). Telepresence studio devices107, computers103, and voice-only devices105couple with telepresence system110, as in FIG1. Mobile telepresence server115also can couple directly with telepresence system110, such as by the use of a dedicated communication link or leased line. Such linkages also can traverse firewall212and router214, without traversing public network210. Server115and system110can communicate over public network210using virtual private network technology.

Thus, FIG2depicts that a telepresence-enabled mobile device can have a capability to communicate over a plurality of wireless communication networks, which can have different bandwidth. For example, with a strong link to an IEEE 802.11G or N base station, mobile device125typically would have access to more bandwidth than what would generally be available over a cellular network connection. Further, all such wireless networks generally are more subject to variation in bandwidth and latency than a wired network, and especially a voice-quality network.

Therefore, a telepresence-enabled mobile device should be provided with a capability to beneficially use increased bandwidth, when available, and be tolerant of variation in bandwidth and latency.

When using a local area wireless network connection, data typically would travel over a network of an Internet Service Provider (ISP), before entering public network210, and arriving at server115. Both cellular network224and public network210can implement IP addressing for data communications, as well as IP addressing for both voice and data communications. Session Initiation Protocol (SIP) can be used as a signaling mechanism between server115and mobile device125, as well as between server115and system110. Various encapsulation layers can be provided for communications between server115and device125, such as using ATM-type QoS for the voice quality network202portion.

QoS can be implemented for data channel204based on what type of network technology is employed, and can include technology, such as MPLS or DiffSery for QoS implementation. Further explanation of server115and device125is provided following the example operational explanation provided with respect toFIGS. 3-7.

FIG3depicts aspects of a method that can be implemented at device125for initiating a telepresence session with telepresence studio107, using server115. FIG3depicts that device125can receive a request to establish a telepresence session, such a request can be initiated responsive to input. Device125can sense or otherwise receive information about current operating conditions, including a battery status, which network is currently being used for communication, whether an alternative network is available, and what overall signal strength is attributable to the current network. Based on these operating conditions, and other considerations, such as user preferences, mobile device125can establish (356) settings to be used at a start of the telepresence session. These settings can include selection of what data mobile device125is to receive, such as which video elements, if any (as explained below.) Mobile device125can request initiation (356) of a telepresence session of server115. Such request can be made before, after, or concurrently with determining what settings are to be initially used for the session. The initially determined settings are transmitted (358) to telepresence server115. Thereafter, a telepresence session can be conducted (359), which can comprise receiving (360) telepresence data, which can include video and audio data and performing (361) video and audio respectively on a display and a speaker based on such received data.

FIG4depicts example aspects of a dynamically updating telepresence functionality for providing enhanced telepresence to mobile devices. Device125monitors (401) status and other parameters of relevance to the telepresence session. Such status and parameter information can include battery information, network access charges, and availability of a faster network, for example. Device125also can sense403environmental conditions, such as include lighting conditions that can affect video quality transmitted from mobile device125.

Responsive to one or more of the status and parameter information, device125can determine (405) to adjust aspects of the incoming audio and/or video streams. Such adjustment is accomplished by commanding server115to adjust such streams appropriately using a control command determined (407) by device125. Such determinations and control command formation can be described more generally as a determination of a desired composition of telepresence session data. Such control command is transmitted to server115(which implements the command as explained below). Device125also can transmit audio and video in the session, and device125thus determines what such content comprises. For example, in some embodiments, elements of a presentation can be transmitted with video of a user of device125. Other aspects include that the video content can be altered to increase the quality of the video. One such aspect can include adjusting for changing lighting conditions through contrast control techniques. Another aspect can include using face recognition technology to keep a face of the user centered in the video stream that is transmitted. These aspects are represented by adjustment (413) of the captured video streams.

Other selections that affect the content transmitted from device125include whether one or more of a front camera and a back camera are selected for operation (415), in devices that have multiple cameras, and presentation content to be made available (417) from device125. The content thus processed and otherwise made available is transmitted (419) from device125to server115.

In some aspects, a telepresence experience on mobile device125is enhanced by dynamic controls for changing device status and environment conditions while a telepresence session proceeds. Such dynamic control of an ongoing telepresence session can include a real-time exchange of telepresence session settings, status information that allows dynamically changing such settings, as well as both settings and status information. In this context, real-time exchange of telepresence-related data, such as control or status information exchanges, provides a capability to adjust telepresence session data transmitted to the mobile device as a telepresence session continues. FIG5depicts examples of such dynamic control that can occur during a telepresence session. In one aspect, device125monitors (501) whether a battery that is powering device125has less than a threshold of power left, and if so, then user preferences stored at device125are checked (503) to determine whether the device is permitted to automatically adjust elements of the telepresence to conserve power. If such preference information allows the device to make automatically adjustments, then device125selects (505) a reduced power consumption video display mode. In one example, selecting a lower quality video display mode can save device battery life in one or more ways. One way is that radio power can be conserved, and another way is that display power consumption also can be reduced by reducing one or more of resolution, frame rate, or an amount of display area occupied by video. Examples of screen arrangements that implemented a tiered reduction of power consumption are provided inFIGS. 10-13.

If user preferences do not permit automatic adjustments, then a method according to FIG5can further include determining (507) whether those user preferences specify a response to the battery power threshold comparison. For example, the user preferences can indicate an order of power reducing activities to implement. The user preferences also can indicate that no power reducing activities are to be implemented. Still further, the method can include alerting (509) a user of device125of the power threshold condition and querying (509) the user for a response, or for an indication that the device is to conduct power conservation activities.

If no battery power threshold concern is indicated, or otherwise after the battery power threshold concern has been processed, then changes in characteristics of network access can be detected (511). Such changes can be characterized (513); such characterization can include that a higher speed network is available, or that a network with better signal strength or other desirable characteristics is available. These changed network characteristics and the battery power aspects can then be used in formulating a control command component (515), which is transmitted (517) to server115. Such control command component can indicate changes to the video stream being transmitted from server115for reception by device125.

Depending on the circumstances, either the battery power condition, the network condition, neither, or both can be used in formulating a control command. The depicted method also can include not transmitting any control command, in the absence of changes, or depending on user configuration or preference information.

Now turning to FIG6, there is depicted aspects of a method that can be implemented on telepresence server115. The depicted method includes receiving (601) a telepresence session initiation request from mobile device125. Configuration information for mobile device125can be accessed, from a storage local to server115, accessed from the session initiation request from device125, or both. For example, if server115has previously handled telepresence sessions for device125, then that device can have a profile registered with server115, which also can include user preference information. The session request can include identification of a particular telepresence system with which device125is to communicate. The server configures (605) itself to function as a proxy between device125and the telepresence system (e.g., system110).

Server115also establishes one or more connections with telepresence system110, such as TCP sessions for one or more of video, audio, and presentation data, as can be indicated in the configuration information provided from device125.

During the ensuing telepresence session, server115functions to transcode one or more of audio and video between high definition formations, with potentially a number of separate streams for a number of cameras located at one or more sites. In a contrasting example, a telepresence studio can receive High Definition (HD) video feeds from a number of other participating telepresence studios. However, to conserve bandwidth and radio usage, server125can receive these high definition streams, and transcode (609) them into a selected composite format, or otherwise cull feeds that are not presented indicated for reception. For example, device125can indicate a total screen resolution, and a partition of the screen space between an active speaker in the conference and video feeds from other sites. A frame rate for the composite video stream also can be indicated, which can be different from the native frame rate of the full HD feeds.

With respect to audio, codecs can be changed, if desired. However, in some examples, the audio can be transmitted at full resolution. As depicted in FIG2, the audio also can be transmitted over a separate voice quality channel, using one or more codecs provided for use on that channel.

The transcoded video/audio is transmitted (609) to device125. Audio and/or video streams also can be received (613) from device125, as can presentation content and other data. In turn, these received video/audio streams can be transcoded, if desired. For example, video resolution can be upscaled, and/or filtered. The audio, video and/or data can then be transmitted by server115to system110.

As described above, device125can send control commands during a telepresence session to server115. FIG7depicts aspects of an example of how server115can process such control commands. In FIG7, a telepresence session is continued (701) by proxying between system110and device125. FIG7depicts that server115detects (703) reception of a command and/or status data from device125. Server115determines whether the command indicates, or the status data dictates, a change (705) to current transcoding settings. If so, such change is implemented to the a/v stream(s) from server115to device125. If not, then other status information provided from device125can be interpreted (709). For example, rather than implementing an explicit command from device125, server115can interpret status information from the mobile device and select an appropriate format change, such as one indicated by a ranked ordering of quality versus bandwidth consumption video compositions. Other examples can include a change in audio codec to increase or decrease quality (determination (711) and implementation (713) of other changes). The depicted method ultimately returns to continuing proxy (701) between system110and device125by server115.

Device125described above can be implemented according to the example of FIG8, described below. For example, device125can have a variety of components by which input can be received (collectively identified as user interface816), including a camera825, a keyboard827, a touch screen829, and a microphone that can be used for speech recognition831, for example. These ways of receiving input can be processed with processing resource819that can be comprised of a plurality of components, such as a programmable processor845, one or more Application Specific Integrated Circuits (ASICs)847, as well as other co-processors849. For example, an ASIC or co-processor can be provided for implementing graphics functionality, encryption and decryption, audio filtering, and other such functions that often involve many repetitive, math-intensive steps.

Processing resources819also can interface with one or more network interfaces817, each of which can be comprised of one or more Media Access Controllers (MACs)851, which in turn interface with physical layers853. Such MACs851also can function to monitor heir respective physical channels, to determine what kind of signal quality and power is being used to communicate on its channel. That information can be provided to software running on processing resources819, for use in making determinations according to the methods described above.

Processing resource819also can interface with a memory resource818which can be comprised of a plurality of memories, including a RAM855, and a non-volatile memory857, which can be implemented with one or more of Flash memory, PROM, EPROM, and the like. Processing resource819also can interface with output820components, which can include a display841, which can be used for performing video or still images, and a speaker843, which can be used for text to speech and for performing audio.

Processing resource819also can receive information from a battery interface888, which can monitor conditions of a battery889, such as charge remaining, and a rate of discharge. This information can be used as inputs into the methods for selecting telepresence session characteristics and effecting a telepresence session based on those characteristics, in accordance with the above description.

FIG9depicts an example organization of telepresence server115. Telepresence server115can include a plurality of MAC/Physical Layers (PHYs) for interfacing with a variety of networks, and can for example include fiber and copper based Ethernet connections to a switch, which in turn communicates with a router. A transport protocol layer915manages transport layer activities for telepresence sessions and can implement a TCP protocol, for example. Telepresence server115can implement a video transcoder911and an audio transcoder913. Video transcoder911can implement functions including changing a resolution of a plurality of images and compositing images. For example video transcoder911can receive a plurality of high definition video streams over MAC/PHY917and convert those streams into lower resolution streams and composite the lower resolution streams into a new video stream where the lower resolution streams each occupy a screen portion of the new video stream. Similarly, audio transcoder913can change codecs used in encoding audio. For example, codecs can be changed between any of International Telecommunications Union (ITU) Recommendations G.721, G.722, G.729, and so on.

A variety of telepresence session state and other information can be used in controller activities conducted by video transcoder911and audio transcoder913. For example, a telepresence session layer925can manage session state907for telepresence sessions in which a mobile device uses server115as a proxy to a telepresence system (e.g., system110). For example, such maintained state can include current video streams being sent to and received from mobile device125, as well as other data, such as a presentation that can be sourced from remote device125. Server115also can maintain a store of information about devices that have used and/or are using server115for telepresence, as represented by mobile device state909, which can include more permanent data such as screen resolution, user preferences, network capabilities and so on. Other more dynamic information can be maintained in mobile device state909store as well, including information such as battery status and current network being used by such devices (e.g., device125). Such state information can be used in selecting appropriate video formats that will be used in controlling video transcoder911to produce a video stream appropriate for each mobile device. Examples of screen arrangements are described below.

FIG10depicts a roster view that can be used both at a telepresence session initiation and in bandwidth and power conserving modes of operation. FIG10depicts that a roster view can include thumbnail displays (1001,1007,1013) either of static images or of video sequences of the participants (e.g., people or sites) in the telepresence session. In one example, the roster view can begin with video of each site, and reduce frame rate of the video as one intermediate step of resource intensiveness reduction, and switch to a static or infrequently updated image sequence as a further step of reduction. Other portions of the roster view can include information about the session participants (1003,1009,1015). Respective buttons (1005,1011,1017) can be provided to allow selection of video from any of the sites in the roster view. In other examples involving a touch sensitive display, any information such as the thumbnail or the information can be selected to focus on a particular participant, and a separate button for that purpose need not be provided. As described below, non-touch screen implementations can provide an overlay of numbers on thumbnails that indicate a key to press in order to focus on each participant. An area for a keyboard1021can be provided, if desired. Such keyboard1021can be virtual or physical.

FIG11depicts a plurality of thumbnails1101-1106displayed to occupy most of an available screen. This mode can be indicated as a control command from device125to server115. Numerals overlayed on the respective thumbnails allow selection of a thumbnail to further expand the video from that site.

Selection of a particular thumbnail can result in the screen depicted in FIG12here, a larger portion of the screen is devoted to a particular participant, a return button1205can be provided, which can return the display to that of FIG11.

A still further example screen organization is depicted in FIG13, wherein one or more thumbnails1304and1305are presented, which can include, for example, a video of an active speaker or speakers. These thumbnails can be provided with overlayed numbers, which function as described with respect to FIG11. A slide show portion1307can be provided, which can be used for display of slides presented by a remote location.

Keyboards1113,1203, and1309are depicted, and as described with respect to FIG10can be implemented virtually or physically. In some cases, the keyboard can be omitted, or can appear when an indication of its need is inputted.

The screen changes exemplified byFIGS. 10-13preferably are implemented by control commands sent from device125to server115, which changes the data sent to device125responsively. This approach is in contrast to the device continuing to receive a superset of the data that can be displayed and locally selecting from that superset a smaller set of data for display.

FIG14depicts a functional module architecture of an example of device125. Device125can include both a local area network wireless MAC/PHY (e.g., Wi-Fi)1435and a broadband MAC/PHY (e.g., 3G MAC/PHY1437). Each of these network interfaces can communicate through one or more transport protocol layers with functional modules implemented in device125. Such functional modules can include incoming video processing1431, outgoing video processing1429, outgoing audio processing1427and incoming audio processing1425. In some examples, e.g., if using a broadband network, such as through 3G MAC/PHY1437, audio can be carried on a voice grade channel logically separate from data representative of video sent from and received by device125.

Other modules include a control command formulation module1421, which receives input from device parameter sensing module1413, and from UI input reception processing1415. Control command formulation can control outgoing video and audio processing1429and1427. Its control commands also can be transmitted through the depicted network layers to server115. A UI display configuration module1419can control a UI display controller1417, which also can receive configuration information from a device configuration store1423. Outgoing video processing also can implement functionality such as outgoing video freezing during lapses in network connectivity or loss of focus detected. Such functionality can be overridden by user preferences, or selectively enabled.

Device parameter sensing module1413can receive information concerning or otherwise monitor status of network status1411and battery1409. Incoming audio processing1425can output audio to speaker843. Microphone831can output captured audio to outgoing audio processing1427. Inputs can provided through any of the input devices depicted in FIG8and identified generally as input devices816.

Further explanation concerning a device125and a system environment in which it can operate is presented in relation to the block diagram depicted in FIG15. The mobile electronic device300can include a microprocessor module338that can control the operation of the mobile electronic device300. A communication subsystem311can perform transmission and reception operations with a wireless network309or with a wired network (not shown). For example, the subsystem311can include a receiver312, a local oscillator313, a transmitter314, a receive antenna316, a transmit antenna318and a digital signal processor320. The microprocessor module338further can be connected with an auxiliary input/output (I/O) subsystem328, which can be connected to the mobile electronic device300. In at least one embodiment, the microprocessor module338can be connected to a serial port330(for example, a Universal Serial Bus port), which can allow for communication with other devices or systems. The display322can be connected to the microprocessor module338to allow for displaying of information to an operator of the mobile electronic device300. When the mobile electronic device300is equipped with a keyboard332, the keyboard332can also be connected with the microprocessor module338. The mobile electronic device300can also include a speaker334, a microphone336, random access memory (RAM)326, and flash memory324, all of which can be connected to the microprocessor module338. Other similar components can also be provided on the mobile electronic device300and optionally connected to the microprocessor module338. Other communication subsystems340and other communication device subsystems342are generally indicated as being functionally connected with the microprocessor module338, as well. An example of a communication subsystem340is a short range communication system, such as a BLUETOOTH® communication module or a WI-FI® communication module (a communication module in compliance with any of the IEEE 802.11 set of protocols) and associated circuits and components.

The microprocessor module338is able to perform operating system functions and enables execution of programs on the mobile electronic device300. In some embodiments, not all of the above components can be included in the mobile electronic device300. For example, in at least one embodiment the keyboard332is not provided as a separate component and is displayed as required on a dynamic touch display. In an embodiment having a dynamic touch display, the keyboard332can be displayed as a touchscreen keyboard. A touchscreen module can be incorporated in such an embodiment such that it is in communication with the microprocessor338. When inputs are received on the touchscreen keyboard, the touchscreen module can send or relay messages corresponding to those inputs to the microprocessor338.

The auxiliary input-output (I/O) subsystem328can take the form of a trackball navigation tool, a thumbwheel, a navigation pad, a joystick, touch-sensitive interface, or other I/O interface. Other auxiliary I/O subsystems can include external display devices and externally connected keyboards (not shown). While the above examples have been provided in relation to the auxiliary I/O subsystem328, other subsystems capable of providing input or receiving output from the mobile electronic device300are considered within the scope of this disclosure. Other keys can be placed along the side of the mobile electronic device300to function as escape keys, volume control keys, scrolling keys, power switches, or user programmable keys, and can likewise be programmed accordingly.

Furthermore, the mobile electronic device300can be equipped with components to enable operation of various programs, as shown in FIG10. For example, the flash memory324can be enabled to provide a storage location for an operating system304, device programs358, and data. The operating system304is generally configured to manage other device programs358that are also stored in the memory324and are executable on the processor338. The operating system304can honor requests for services made by device programs358through predefined program interfaces. More specifically, the operating system304typically determines the order in which multiple programs358are executed on the processor338and the execution time allotted for each program358, manages the sharing of memory324among multiple programs358, handles input and output to and from other device subsystems342, and so on. In addition, operators can typically interact directly with the operating system304through any suitable user interface. While in one example the operating system304can be stored in flash memory324, the operating system304in other embodiments can be stored in read-only memory (ROM) or another similar storage element (not shown). As those skilled in the art will appreciate, the operating system304, device program358or parts thereof can be loaded in RAM326or other volatile memory.

In one embodiment, the flash memory324can contain programs358for execution on the mobile electronic device300, including—but not limited to—an address book352, a personal information manager (PIM)354, and a device state302. Furthermore, programs358and other information356including data can be segregated upon storage in the flash memory324of the mobile electronic device300.

When the mobile electronic device300is enabled for two-way communication within the wireless communication network309, it can send and receive messages from a mobile communication service. Examples of communication systems enabled for two-way communication include, but are not limited to, a General Packet Radio Service (GPRS) network, a Universal Mobile Telecommunication Service (UMTS) network, an Enhanced Data for Global Evolution (EDGE) network, a Code Division Multiple Access (CDMA) network, High-Speed Packet Access (HSPA) networks, Universal Mobile Telecommunication Service Time Division Duplexing (UMTS-TDD) networks, Ultra Mobile Broadband (UMB) networks, Worldwide Interoperability for Microwave Access (WiMAX) networks, Long Term Evolution (LTE) networks and other systems using other suitable protocols or standards that can be used for carrying data and voice, or just data or voice. For the systems listed above, the mobile electronic device300can require a unique identifier to enable the mobile electronic device300to transmit and receive messages from the communication network309. Other systems may not require such identifying information. GPRS, UMTS, and EDGE use a Subscriber Identity Module (SIM) in order to allow communication with the communication network309. Likewise, most CDMA systems use a Removable User Identity Module (RUIM) in order to communicate with the CDMA network. The RUIM and SIM card can be used in multiple different mobile electronic devices300. A SIM/RUIM interface344located within the communication mobile electronic device300allows for removal or insertion of a SIM/RUIM card (not shown). The SIM/RUIM card features memory and holds key configurations351, and other information353such as identification and subscriber related information. With a properly enabled mobile electronic device300, two-way communication between the mobile electronic device300and communication network309is possible. It is also understood that the mobile electronic device300can be configured to communicate in asynchronous networks, such as when two or more mobile electronic devices communicate without the assistance of fixed network equipment. If the mobile electronic device300is enabled as described above or the communication network309does not require such enablement, the two-way communication enabled mobile electronic device300is able to both transmit and receive information from the communication network309. The transfer of communication can be from the mobile electronic device300or to the mobile electronic device300. To communicate with the communication network309, the mobile electronic device300in the presently described example, as noted earlier, can be equipped with a transmit antenna318for transmitting messages to the communication network309. Likewise the mobile electronic device300in the presently described example is equipped with a receive antenna316for receiving communication from the communication network309. In another arrangement, these antennae316,318are combined into a single antenna (not shown). As one skilled in the art would appreciate, the antenna or antennae316,318can be externally mounted on or internally mounted in the mobile electronic device300.

Aspects described above can be implemented as computer executable code modules that can be stored on computer readable media, read by one or more processors, and executed thereon. In addition, separate boxes or illustrated separation of functional elements of illustrated systems does not necessarily require physical separation of such functions, as communications between such elements can occur by way of messaging, function calls, shared memory space, and so on, without any such physical separation. More generally, a person of ordinary skill would be able to adapt these disclosures to implementations of any of a variety of communication devices. Similarly, a person of ordinary skill would be able to use these disclosures to produce implementations and embodiments on different physical platforms or form factors without deviating from the scope of the claims and their equivalents.