Patent Application
20080020752
For a more complete understanding of the disclosure and the advantages thereof, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that although an illustrative implementation of one embodiment of the disclosure is illustrated below, the system may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
The WebOS concept might be extended for use on handheld mobile electronic devices that have the capability for a wireless connection to the Internet or other networks. That is, devices such as mobile telephones, personal digital assistants, handheld computers, and similar devices might use a locally installed browser to wirelessly interface with a network and gain access to applications and data that are stored on a remote server. Such devices will be referred to herein as handsets. The use of WebOS can give a handset with limited resources, such as limited processing and storage, access to applications that it would not be able to execute locally and can thus allow an inexpensive handset to have functionality that would otherwise be available only in more expensive handsets. Similarly, more expensive handsets can be given functionality that might otherwise require a potentially infeasible amount of processing power and/or memory.
However, the use of WebOS on handsets might be limited by the fact that network connectivity for handsets can be unreliable. Multi-path fading in a radio frequency transmission, network perturbations, and other well-known wireless networking problems can cause a temporary loss of connection between a handset and a WebOS server. If a handset user is using an application that is executing on a WebOS server and the connection to the server is lost, the user could no longer send data to or receive data from the application and the functions available through the application would be lost until the network connection is restored. This can lead to a user experience that is less satisfactory than the use of a locally installed application.
Embodiments of the disclosure give a handset user the impression that a connection is still present when network connectivity is temporarily lost. Data appears to continue to arrive from the server and data entered by the user into the handset appears to cause the appropriate actions in the browser as if the application the user had been using were still responsive. In an embodiment, this fault tolerance capability may include one or more of the following three components: a ‘flywheel’ buffer, a state table framework, and a heuristic component.
The flywheel buffer temporarily stores data streaming from the server and then makes the data available to the browser. Data can be retrieved from the flywheel buffer to cover a brief connection failure. The state table framework uses the present state of the handset to anticipate the likely next states of the handset and then causes an output appropriate to the next state to appear in the browser based on an input from the user. The heuristic component learns the user's behavior and reduces the number of likely next states for a given present state based on the user's past actions in the present state.
The handset 30 includes a flywheel buffer 32 and a state table framework 33. The flywheel buffer 32 can receive and retain streaming data from the server 20. The state table framework 33 includes a state table memory location 34 and a state table driver 36. The state table memory 34 can receive and retain state table information from the server 20 and the state table driver 36 can read the state table information from the state table memory 34. The flywheel buffer 32 and the state table driver 36 can input data into a display 40 that can display digital images. The display 40 can also determine whether data from the flywheel buffer 32 or from the state table driver 36 is displayed.
Although the display 40 is depicted in
The handset 30 also includes a keypad 42 or a similar mechanism for inputting data into the handset 30. The keypad 42 can send data to the state table driver 36 and to a user input memory location 44.
Data that is entered into the display 40, perhaps through the keypad 42, is transmitted wirelessly to the server 20 as user input 56. The user input 56 might launch one of the applications 26 on the server 20 or request data 28 from the server 20. If one of the applications 26 is launched, further user input 56 might be entered into the application 26 for processing. The application 26 might then return processed data for display on the display 40. In a WebOS environment, the data that is returned to the display 40 is typically a digital image of how the display 40 should appear. That is, the display 40 can take on the appropriate appearance without any further processing by the handset 30 of the data returned from the server 20. The user is given the impression that the processing of the data occurred on the handset 30 and that the handset 30 caused the display 40 to take on the appropriate appearance when, in reality, the image that appears on the display 40, or information that promotes the display of that image, was transmitted from the server 20.
If the wireless connection between the server 20 and the handset 30 is disrupted, user input 56 may not be transmitted from the handset 30 to the server 20 and a digital image may not be transmitted from the server 20 to the handset 30. The user will no longer have access to the applications 26 and the data 28 on the server 20. In an embodiment, when such an outage occurs, the flywheel buffer 32 can continue to send digital images to the display 40 for a brief period of time.
Each digital image that is sent to the handset 30 during normal operation can be referred to as a current image 52. Current images 52 are stored temporarily in the flywheel buffer 32 and after a certain amount of current image data has accumulated in the flywheel buffer 32, the current images 52 are sent to the display 40 in a first in, first out fashion. When a connection failure occurs, current images 52 no longer enter the flywheel buffer 32 but the flywheel buffer 32 can continue to send the current images 52 it had previously accumulated to the display 40. If a connection to the server 20 is reestablished before the flywheel buffer 32 sends out all of its accumulated current images 52, the flywheel buffer 32 can again begin to accumulate current images 52 and will continue to send out previously accumulated current images 52. The user will see data continuing to appear on the display 40 as if no outage had occurred. It is anticipated that the flywheel buffer 32 might cover outages lasting less than about one second.
One of skill in the art will recognize that the flywheel buffer 32 may be configured in various well-known ways, such as in a configuration similar to that of a vibration buffer in a compact disc player. It will also be recognized that the length of time over which the flywheel buffer 32 can compensate for a connection failure depends on the amount of memory in the flywheel buffer 32. A flywheel buffer 32 having a large storage capacity can bridge a long connection gap but might cause an unacceptably long delay in transferring data from the server 20 to the handset 30. A smaller flywheel buffer 32 might provide an unnoticeable delay time but might be able to bridge only small gaps.
The flywheel buffer 32 generally deals with data that flows from the server 20 to the handset 30. When a user is interacting with one of the applications 26, a two-way data flow, from the server 20 to the handset 30 and from the handset 30 to the server 20, might occur. When a network outage occurs in such situations, the state table framework 33 can give the user the impression that a connection to the server 20 is still present. The state table framework 33 is able to send one or more digital images to the display 40 so that the display 40 appears to be receiving data from the server 20. The state table framework 33 is also able to modify the display 40 in response to user actions as if the response were coming from the server 20.
In an embodiment, the server 20 sends information to the state table framework 33 in the form of a state table 54. As is well known in the art, a state table typically includes a set of present states, a set of possible inputs, a set of next states that can result when each of the possible inputs is applied to each of the present states, and a set of outputs associated with each of the next states. The state information is context-based, the context being the applications or handset operations currently being accessed.
As is well known in the art, a present state of a device is an aggregation of information related to the circumstances under which the device is currently operating. A present state might include one or more outputs the device is currently providing. One or more of the current outputs might be a digital image. Hereinafter, the terms “digital image” and “output” will be used interchangeably but it should be understood that, in more general terms, an output specified in a state table is not necessarily a digital image and might include sounds or other types of output.
It is also well known in the art that a next state is a mode of operation into which a device can enter from a present state. One or more digital images or other types of output might be associated with a next state.
As mentioned previously, a series of current images 52 can be stored temporarily in the flywheel buffer 32 and the current images 52 can be sent sequentially to the display 40. In an embodiment, each time a current image 52 is sent from the server 20 to the flywheel buffer 32, a state table 54 is sent from the server 20 to the state table memory 34. The state table 54 contains one or more next states 66 that might follow from the present state 62 associated with the current image 52 that was sent. Although the current image 52 and the state table 54 are depicted in
In an embodiment, each output 68 associated with one of the next states 66 represents one possible appearance the display 40 could assume after the display 40 assumes the appearance specified by the present state 62. That is, when one of the outputs 68 associated with one of the present states 62 appears on the display 40, an action the user performs in response to that output 68 might result in one of the outputs 68 associated with one of the next states 66 appearing on the display 40. Since the number of functions that can be performed on the handset 30 tends to be limited, when any particular output 68 appears on the display 40, the number of next states 66 that can be entered tends to be limited.
The state table driver 36 can accept inputs 64 from the keypad 42, find the corresponding input 64 in the state table 54 that is stored in the state table memory 34, and cause the output 68 that is associated with that input 64 and the present state 62 to appear on the display 40. For example, for present state X 62a, the possible inputs 64 are 1, 2, and 3, which might represent keystrokes or other actions the user could take on the handset 30. When the connection between the handset 30 and the server 20 is lost and when the handset 30 is in present state X 62a and the user selects input 1, then next state A is entered and output Q is provided to the display 40. If the user selects input 2, next state B is entered and output R is provided to the display 40. If the user selects input 3, next state C is entered and output S is provided to the display 40.
Thus, if the handset 30 loses its connection to the server 20, the user can still enter data into the keypad 42. The display 40 will display the output 68 or digital image appropriate to the user input 64 but the digital image will have been retrieved from the state table memory 34 instead of being generated by the server 20 at the time of the input 64. To the user, it will appear that the display 40 responded appropriately to the input 64.
If the user makes an additional input 64 in response to a first next state 66 that is entered after an initial input 64, the state table driver 36 might be able to retrieve a second next state 66 based on the additional input 64 and the first next state 66. However, a state table capable of containing all possible inputs for a given present state, all possible first next states that could result from those inputs, all possible additional inputs into all of the possible first next states, and all possible second next states that could result from each of the first next states could become unmanageably large. In one embodiment, the state table 54 stored in the state table memory 34 contains only the inputs 64 that apply to the present state 62 and the next states 66 and outputs 68 that could result from those inputs 64 and that present state 62. In other embodiments, depending on the size of the state table memory 34, the processing power of the state table driver 36, the judgment of the designer of the fault tolerance system 10, and other factors, additional inputs 64, next states 66, and outputs 68 could be included in the state table 54.
It is conceivable that the server 20 could maintain a master state table that includes every possible state that the handset 30 could enter, every possible input available in those possible states, and every possible next state and output that could result from those inputs and those initial states. The server 20 could then send to the handset 30 only the portion of the master state table that applied to the current state of the handset 30. However, such a master state table would be likely to be so large that it could not practically be implemented.
Instead, in an embodiment, the state table generation component 22 on the server 20 generates appropriate state tables 54 ‘on the fly’. That is, whenever a new current image 52 is sent to the handset 30, the state table generation component 22 determines the inputs 64 that could be entered into the handset 30 when that current image 52 is displayed. The state table generation component 22 also determines the next states 66 and outputs 68 that could result from those inputs 64. Those inputs 64, next states 66, and outputs 68 are then placed in the state table 54 and transmitted to the state table memory 34.
The state table 54 might include a cluster of related present states 62 and next states 66. That is, a group of present states 62 might be similar to one another and might have one or more next states 66 in common. Some of the next states 66 might belong to the group of present states 62 such that one or more present states 62 and one or more next states 66 might appear on the display 40 in cyclical manner. Thus, the images that appear on the display 40 might all be selected from this closed group of present states 62 and next states 66 that make up a cluster. It is possible that a next state 66 that is unlikely to be reached from a given present state 62 will be included in the state table 54 or that a next state 66 that is likely to be reached from a given present state 62 will be omitted from the state table 54. However, it is anticipated that the state table generation component 22 will have sufficient intelligence to appropriately populate the state table 54 or a cluster within the state table 54 and that such imperfections in the state table 54 can be kept to a minimum.
In an embodiment, the state table generation component 22 includes a heuristic component 24 that can further reduce the size of the state table 54 that is sent to the state table memory 34. The heuristic component 24 can observe the behavior of the handset user and learn which inputs 64 the user typically enters in each present state 62. If there are inputs 64 that the user rarely makes in a particular present state 62, the heuristic component 24 can inform the state table generation component 22 to eliminate those inputs 64 and their associated next states 66 and outputs 68 from the state table 54 for that present state 62. This reduced-size state table 54 can be more efficient for the server 20 to transmit and more efficient for the state table driver 36 to read from the state table memory 34. Alternatively, when rarely used inputs 64, next states 66, and outputs 68 are eliminated, the state table 54, rather than being reduced in size, can include additional inputs 64, next states 66, and outputs 68 that might be relevant to the present state 62 but that might not have been included in state table 54 otherwise. This may allow even longer service disruptions to go unnoticed by the user.
In an embodiment, a browser or other component in the display 40 determines whether the data that appears on the display 40 will come from the flywheel buffer 32 or from the state table driver 36. When the handset 30 is connected wirelessly to the server 20, the browser allows digital images from the server 20 to pass through the flywheel buffer 32 to the display 40. When a network outage occurs, and when no user data entry occurs, the browser will continue to allow the digital images that have accumulated in the flywheel buffer 32 to pass to the display 40.
If a user data entry does occur, the browser might cause data from the state table driver 36 to be sent to the display 40. That is, if the user makes an input 64 into the keypad 42, the state table driver 36 might look up the input 64 in the state table 54 stored in the state table memory 34. The state table driver 36 might then send the output 68 associated with that input 64 to the browser and the browser might pass that output 68 to the display 40. Other methods of determining when transitions between flywheel buffer data and state table driver data should be made will be apparent to one of skill in the art.
When a wireless connection to the server 20 is lost, a standard connection module in the handset 30 tries to reconnect to the server 20, as is well known in the art. The fault tolerance actions described above take place while this reconnection is sought. Any inputs 64 the user makes into the keypad 42 during the outage merely cause a particular digital image stored in the state table memory 34 to be sent to the display 40. These inputs 64 do not have any actual impact on any applications 26 that might have been executing before the outage.
In an embodiment, any inputs 64 the user makes into the keypad 42 during a network outage are stored in the user input memory 44. When a connection to the server 20 is regained, a synchronization procedure can occur in which the contents of the user input memory 44 are sent to the server 20 for the appropriate processing. This data from the user input memory 44 can then be entered into the applications 26 to which it applies and the applications 26 can perform the appropriate processing on the data. The applications 26 can then resume their normal operations and return current images 52 and the state table 54 to the handset 30 as if the network outage had not occurred. The handset 30 thus begins to again receive ‘live’ data from the server 20.
The transmission of current images 52 and the state table 54 from the server 20 to the handset 30 can occur via well-known wireless data transmission protocols. In an embodiment, the asynchronous JavaScript and XML (Ajax) programming tools might be used to encode the data that is sent from the server 20 to the handset 30. As is well known in the art, Ajax allows only a portion of a web page to be updated while the remainder of the web page is unchanged. The use of Ajax in the fault tolerance system 10 allows only the data needed to update the display 40, rather than the entire image to be displayed, to be sent to the handset 30. This can promote efficient transmission of current images 52 and state tables 54 from the server 20 to the handset 30.
While this method cannot guarantee continued operation during a network failure, fault tolerance can be provided for short durations. Longer network outages might cause the handset to revert to a minimal operation mode in which the applications on the remote server cannot be accessed.
The handset 30 includes a display 102, which may be equivalent in whole or in part to the display 40 of
Among the various applications executable by the handset 30 are a web browser, which enables the display 102 to show a web page. The web page is obtained via wireless communications with a cell tower 406, a wireless network access node, or any other wireless communication network or system. The cell tower 406 (or wireless network access node) is coupled to a wired network 408, such as the Internet. Via the wireless link and the wired network, the handset 30 has access to information on various servers, such as a server 410. The server 410 may provide content that may be shown on the display 102.
The DSP 502 or some other form of controller or central processing unit operates to control the various components of the handset 30 in accordance with embedded software or firmware stored in memory 504. In addition to the embedded software or firmware, the DSP 502 may execute other applications stored in the memory 504 or made available via information carrier media such as portable data storage media like the removable memory card 520 or via wired or wireless network communications. The application software may comprise a compiled set of machine-readable instructions that configure the DSP 502 to provide the desired functionality, or the application software may be high-level software instructions to be processed by an interpreter or compiler to indirectly configure the DSP 502.
The antenna and front end unit 506 may be provided to convert between wireless signals and electrical signals, enabling the handset 30 to send and receive information from a cellular network or some other available wireless communications network. The RF transceiver 508 provides frequency shifting, converting received RF signals to baseband and converting baseband transmit signals to RF. The analog baseband processing unit 510 may provide channel equalization and signal demodulation to extract information from received signals, may modulate information to create transmit signals, and may provide analog filtering for audio signals. To that end, the analog baseband processing unit 510 may have ports for connecting to the built-in microphone 512 and the earpiece speaker 514 that enable the handset 30 to be used as a cell phone. The analog baseband processing unit 510 may further include a port for connecting to a headset or other hands-free microphone and speaker configuration.
The DSP 502 may send and receive digital communications with a wireless network via the analog baseband processing unit 510. In some embodiments, these digital communications may provide Internet connectivity, enabling a user to gain access to content on the Internet and to send and receive e-mail or text messages. The input/output interface 518 interconnects the DSP 502 and various memories and interfaces. The memory 504 and the removable memory card 520 may provide software and data to configure the operation of the DSP 502. Among the interfaces may be the USB interface 522 and the infrared port 524. The USB interface 522 may enable the handset 30 to function as a peripheral device to exchange information with a personal computer or other computer system. The infrared port 524 and other optional ports such as a Bluetooth interface or an IEEE 802.11 compliant wireless interface may enable the handset 30 to communicate wirelessly with other nearby handsets and/or wireless base stations.
The input/output interface 518 may further connect the DSP 502 to the vibrator 526 that, when triggered, causes the handset 30 to vibrate. The vibrator 526 may serve as a mechanism for silently alerting the user to any of various events such as an incoming call, a new text message, and an appointment reminder.
The keypad 528 couples to the DSP 502 via the interface 518 to provide one mechanism for the user to make selections, enter information, and otherwise provide input to the handset 30. Another input mechanism may be the touch screen LCD 530, which may also display text and/or graphics to the user. The touch screen LCD controller 532 couples the DSP 502 to the touch screen LCD 530.
The CCD camera 534 enables the handset 30 to take digital pictures. The DSP 502 communicates with the CCD camera 534 via the camera controller 536. The GPS sensor 538 is coupled to the DSP 502 to decode global positioning system signals, thereby enabling the handset 30 to determine its position. Various other peripherals may also be included to provide additional functions, e.g., radio and television reception.
While several embodiments have been provided in the disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the disclosure. The examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
Also, techniques, systems, subsystems and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the disclosure. Other items shown or discussed as directly coupled or communicating with each other may be coupled through some interface or device, such that the items may no longer be considered directly coupled to each other but may still be indirectly coupled and in communication, whether electrically, mechanically, or otherwise with one another. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.
This application claims priority to U.S. Provisional Patent Application No. 60/820,199, entitled “Fault Tolerant UI for Wireless WebOS”, filed on Jul. 24, 2006, by Ronald J. Webb, which is incorporated herein by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60820199 | Jul 2006 | US |
