Patent Description:
<CIT> discloses a method for providing autocomplete suggestions. A computing device receives an n-gram of characters. Cached autocomplete suggestions are identified in a local cache of the computing device. Additional autocomplete suggestions are requested from a remote system.

<CIT> discloses receiving a context comprising data that is indicative of one or more characters input by a user at a first computing device, sending to a remote second computing device information comprising at least a portion of the context, determining a first predicted word based at least in part on the context and receiving a second predicted word from the second computing device.

The following presents a simplified summary of one or more features described herein in order to provide a basic understanding of such features. This summary is not an extensive overview of all contemplated features, and is intended to neither identify key or critical elements of all features nor delineate the scope of any or all implementations. Its sole purpose is to present some concepts of one or more features in a simplified form as a prelude to the more detailed description that is presented later.

Aspects of the present disclosure include methods, apparatus, and computer-readable media for receiving one or more user inputs from a user via a user interface, transmitting the one or more user inputs to a remote server, obtaining an expected user input interval and an expected response latency, and displaying, via the user interface, either one or more predicted inputs associated with a content of a local cache or one or more predicted inputs received from the remote server, based at least on whether the expected user input interval is greater than a product of the expected response latency and a factor.

In particular, according to the present disclosure, there is provided a mobile device configured to carry out a method, a method carried out by a mobile device and a computer program which causes a mobile device to carry out a method comprising:.

The foregoing has outlined rather broadly the features and technical advantages of examples in order that the detailed description that follows may be better understood. The conception and specific examples disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present application. Each of the figures is provided for the purpose of illustration and description only, and not as a definition of the limits of the claims.

In some implementations, a mobile device, such as a cellular phone, a personal digital assistant, or a tablet computer, may implement a predictive text entry technique on an incomplete written content by a user. The predictive text may be generated locally based on the text input by the user and data stored in a local cache on the mobile device. The predictive text may also be generated remotely at a server. The mobile device may perform the predictive text entry technique by sending the text input by the user to the remote server and receiving the predictive text. The incomplete written content may be part of a word, phrase, hashtag, brand name, celebrity name, venue, product or service entered by the user into the mobile device. The incomplete written content may include one or more user inputs, such as characters, symbols, or numbers. The predictive text includes one or more predicted inputs generated locally or remotely based on the text input by the user. In certain examples, the predictive text may be configured as a query including the one or more predicted inputs. The query may include a request for response, the text input by the user, and/or other control or payload information.

During operation, the mobile device receives a text input from a user for an incomplete written content, such as a word, phrase, hashtag, brand name, celebrity name, venue, product, or service. The mobile device may send the text input of the incomplete written content to the remote server. The mobile device estimates an expected user input interval (i.e. projected time between successive character entry) and an expected response latency (i.e. projected time between sending the incomplete written content to the remote server and receiving the predictive text). If the expected user input interval is larger than the expected response latency, the mobile device waits for the predictive text sent by the remote server, and present the predictive text sent by the remote server to the user. If, on the other hand, the expected user input interval is smaller than or equal to the expected response latency, the mobile device presents the predictive text generated locally based on the incomplete written content and the data stored in the local cache of the mobile device.

Referring to <FIG>, an example of a system <NUM> for predictive text entry may include a remote server <NUM> and a mobile device <NUM>. The mobile device <NUM> includes a decision engine <NUM> that controls generating predictive text based on a local cache, or based on communication with the remote server <NUM>, depending on a speed of user input and an expected response time associated with the remote server <NUM>. The mobile device <NUM> and the remote server <NUM> may communicate via a communication network <NUM>. The communication network <NUM> may include a wired or a wireless network such as local area network (LAN), a wide area network (WAN), a cloud network, a wireless fidelity (Wi-Fi) network, or a mobile network. The mobile device <NUM> and the remote server <NUM> may exchange data via the communication network <NUM>.

In certain implementations, the mobile device <NUM> includes a communication module <NUM> configured to communicate with the remote server <NUM>. For example, the communication module <NUM> may transmit one or more user inputs <NUM> to the remote server <NUM> and receive predictive text(s) <NUM> from the remote server <NUM>. The mobile device <NUM> may further include a local prediction engine <NUM> and a local cache <NUM>. When the mobile device <NUM> receives the one or more user inputs, the local prediction engine <NUM> may analyze the one or more user inputs and content of the local cache <NUM> to generate the predictive text. The cache local <NUM> may store incomplete textual strings (e.g. the one or more user inputs), potential predictive texts associated with the incomplete textual strings, and/or contextual relationships between the incomplete textual strings and the associated predictive texts. In some examples, the local cache <NUM> may store less information than the data store <NUM>. The incomplete textual strings may be one or more user inputs. The potential predictive texts may include the one or more predicted inputs. In some examples, the one or more predicted inputs may include a most-likely candidate for the one or more user inputs, and other potential candidates.

the mobile device <NUM> includes a decision engine <NUM> configured to determine whether an expected user input interval is larger than an expected response latency and whether to perform predictive text entry remotely or locally. if the expected user input interval is larger than the expected response latency, the decision engine <NUM> of the mobile device <NUM> decides to transmit the one or more user inputs to the remote server <NUM> so the remote server <NUM> performs predictive text entry remotely. If the expected user input interval is smaller than or equal to the expected response latency, the decision engine <NUM> decides to perform predictive text entry locally.

In certain implementations, the mobile device <NUM> includes a clock <NUM> and a timing module <NUM>. The timing module <NUM> may utilize the clock <NUM> to measure the expected user input interval and/or the expected response latency. The timing module <NUM> may be a hardware (e.g. processor), a software (computer executable code), or a combination of hardware/software module in the mobile device <NUM> that measures and provides timing data. For example, the timing module <NUM> may keep track of the time, as indicated by the clock <NUM>, of when the user provides inputs. The differences between successive inputs are used to compute the expected user input interval as described below. Further, the timing module <NUM> may also keep track of the time, as indicated by the clock <NUM>, of a round-trip time of a message sent to and received from the remote server <NUM>. The communication module <NUM>, the local prediction engine <NUM>, the decision engine <NUM>, the clock <NUM>, and the timing module <NUM> may be part of a local service <NUM> configured to provide predictive text entry services locally to the mobile device <NUM>.

In some implementations, the mobile device <NUM> includes a user interface (UI) module <NUM> configured to receive the one or more user inputs typed by a user <NUM>, and display the obtained predictive text to the user <NUM>. In certain examples, the UI module <NUM> may include a touch-sensitive display <NUM> and a touch-sensitive keyboard <NUM>.

In one non-limiting example, the user <NUM> may input "#Micr" via the UI module <NUM>. The timing module <NUM> may determine that the expected user input interval is <NUM> milliseconds and the expected response latency is <NUM> milliseconds (including the transmission time from the mobile device <NUM> to the remote server <NUM> and back, and the computation time at the remote server). The decision engine <NUM> may decide that the expected user input interval is larger than the expected response latency. In response to this determination, the communication module <NUM> sends the input string "#Micr" to a communication module <NUM> of the remote server for a cloud service <NUM> to perform the predictive text entry. After the communication module <NUM> receives the #Micr" string, a remote prediction engine <NUM> may search in the data store <NUM> for possible predictive texts. If the mobile device <NUM> has previously typed words such as "Word", "Excel", and "PowerPoint", the remote prediction engine <NUM> may decide that "#Microsoft™" is the most likely predictive text. If the mobile device <NUM> has just arrived in Boise, Idaho (based on its global positioning system data), the remote prediction engine <NUM> may decide that "#Micron™" is the most likely predictive text. If the user <NUM> has just purchased books authored by Gregory Mankiw or books relating to marginal utility and demand, the remote prediction engine <NUM> may decide that "#Microeconomics" is the most likely predictive text. After the remote prediction engine <NUM> determines the most likely predictive text, the communication module <NUM> may transmit the most likely predictive text back to the mobile device <NUM> to be displayed to the user <NUM> via the UI module <NUM>. The mobile device <NUM> may be a computer device, e.g., including a processor and a memory, such as an example system described in greater detail in <FIG>.

In some implementations, the remote server <NUM> may include the communication module <NUM> configured to communicate with the mobile device <NUM>. The communication module <NUM> may be configured using one or more of a transceiver, a transmitter, a receiver, a modem, or software that sends and receives digital data via the communication network <NUM>. For example, the communication module <NUM> may receive one or more user inputs (e.g. characters, numbers, symbols) transmitted by the mobile device <NUM>, and transmit a predictive text to the mobile device <NUM>. The one or more user inputs may be characters, numbers, and symbols typed or otherwise entered by the user into the mobile device <NUM>. The remote server <NUM> may also include the remote prediction engine <NUM> and a data store <NUM>. The remote prediction engine <NUM> may include, but is not limited to, hardware (e.g. processors) and/or software (computer executable code) configured to estimate the likely predictive text based on the one or more user inputs. When the remote server <NUM> receives the one or more user inputs, the remote prediction engine <NUM> may analyze the one or more user inputs and content of the data store <NUM> to generate the predictive text. The data store <NUM> may store incomplete textual strings, potential predictive texts associated with the incomplete textual strings, and/or contextual relationships between the incomplete textual strings and the associated predictive texts. The incomplete textual strings may be one or more user inputs. The potential predictive texts may include the one or more predicted inputs. In some examples, the one or more predicted inputs may include a most-likely candidate for the one or more user inputs, and other potential candidates. For example, the data store may include an incomplete textual string of "bru", and the associated predictive texts may include "Brussel" (contextual relationship "geographic location"), "Bruce Springsteen" (contextual relationship "singer" or "music"), "Brussels sprout" (contextual relationship "food"), "brush" (contextual relationship "tool"), and "brusque" (contextual relationship "behavior"). In another example, the data store <NUM> may store potential predictive texts with associated contextual information. In addition, in some implementations, the data store <NUM> may also store a match likelihood metric, or a confidence metric, associated with each respective incomplete textual string that identifies a value associated with a likelihood or confidence that the incomplete textual string may be intended to be an input that matches the respective one of the predictive texts. The remote prediction engine <NUM> may search for a desired predictive text by entering an incomplete textual string, such as "pr", and receive one or more of the following predictive texts: "Prince" (contextual relationship "musician"), "Pringles™" (contextual relationship "food"), "Price is Right™" (contextual relationship "game show"), or "program" (contextual relationship "software"). In some implementations, the remote prediction engine <NUM> may order the one or more predictive texts based on the match likelihood metric, or the confidence metric, or may include these metrics with the predictive texts. The communication module <NUM> and the remote prediction engine <NUM> may be part of the cloud service <NUM> configured to provide predictive text entry services to clients such as the mobile device <NUM>. The remote device <NUM> may be a computer device, e.g., including a processor and a memory, such as an example system described in greater detail in <FIG>.

Turning now to <FIG>, a process flow diagram <NUM> illustrates an example of a method for predictive text entry. First, the user provides (<NUM>) one or more user inputs to the UI module <NUM>. The one or more user inputs may include characters, alphabets, numbers, symbols, phonetics, keys, or other textual representations. For example, the one or more user inputs may be part of a hashtag (e.g. "#La" for "#Lakers"), part of a brand name (e.g. "Este" for "Estee Lauder™"), or part of an item (e.g. "tele" for "telephone"). In a non-limiting example, the one or more user inputs may be "#Yose" or "#Yoes" (user inputs with a typographical error) for "#Yosemite".

Next, the UI module <NUM> may send (<NUM>) the one or more user inputs to the local service <NUM> of the mobile device <NUM>. The local service <NUM> of the mobile device may then send (<NUM>) the one or more user inputs to the cloud service <NUM>.

After sending (<NUM>) the one or more user inputs to the cloud service <NUM>, the local service <NUM> determines (<NUM>) that the expected user input interval is greater than the expected response latency. In other examples, the local service <NUM> may determine (<NUM>) that the expected user input interval is greater than a product of a factor and the expected response latency. The factor may be used to provide a "buffer" time that the mobile device <NUM> may use to display the predictive text after receiving the predictive text from the remote server <NUM>. For example, if the mobile device <NUM> expects a long "buffer" time, the factor may be set as <NUM>. If the mobile device <NUM> expects a short "buffer" time, the factor may be set as <NUM>. The factor may range from <NUM> to <NUM>, <NUM> to <NUM>, or <NUM> to <NUM>. The factor may be <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>.

In an example, the timing module <NUM> of the local service <NUM> may determine the expected user input interval by calculating an average of intervals of previous user inputs as measured by the clock <NUM>. For example, if the user <NUM> previously typed the words "janitor", and the intervals between "j" and "a", "a" and "n", "n" and "i", "i" and "t", "t" and "o", and "o" and "r" are <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> milliseconds, respectively, the average interval is <NUM> milliseconds. The timing module <NUM> may use the average interval of <NUM> milliseconds as the expected user input interval. Alternatively, the timing module <NUM> may use a simple moving average, a weighted moving average, a cumulative moving average, or an exponential moving average to calculate the expected user input interval.

If the local service <NUM> determines (<NUM>) that the expected user input interval is greater than the expected response latency, the local service <NUM> waits for the remote service <NUM> to send the predictive text. Next, the cloud service <NUM> may analyze the one or more user inputs and content of the data store <NUM> to generate (<NUM>) information relating to the predictive text. For example, the remote prediction engine <NUM> of the cloud service <NUM> may receive the one or more user inputs of "#Yose" and determine the most likely predictive text is "#Yosemite". The information may include the entire hashtag "#Yosemite" or the characters "mite". The remote prediction engine <NUM> may rely on a location of the mobile device <NUM>, context of the one or more user inputs, a frequency of usage of the hashtag "#Yosemite", popular items at the time of the prediction, popular brands at the time of the prediction, common hashtags, company names relevant to the user <NUM>, venues near the mobile device <NUM>, and/or languages used by the user <NUM> to determine the most likely predictive text. In some examples, the remote prediction engine <NUM> may generate information relating to multiple predictive texts.

Next, the cloud service <NUM> may send (<NUM>) the information relating to the predictive text. After receiving the information, the local service <NUM> may send (<NUM>) the predictive text of "#Yosemite" or "mite" to the UI module <NUM>. The UI module <NUM> may display (<NUM>) the hashtag "#Yosemite" to the user <NUM>.

Turning now to <FIG>, a process flow diagram <NUM> illustrates another example of a method for predictive text entry. First, in certain implementations, the user provides (<NUM>) one or more user inputs to the UI module <NUM>. The one or more user inputs may include characters, alphabetic characters, numbers, symbols, phonetics, keys, or other textual representations. In a non-limiting example, the one or more user inputs may be "#fo".

Next, the UI module <NUM> may send (<NUM>) the one or more user inputs to the local service <NUM> of the mobile device <NUM>. The local service <NUM> of the mobile device may then send (<NUM>) the one or more user inputs to the cloud service <NUM>. After sending (<NUM>) the one or more user inputs to the cloud service <NUM>, the local service <NUM> may determine (<NUM>) that the expected user input interval is less than or equal to the expected response latency.

If the local service <NUM> determines (<NUM>) that the expected user input interval is less than or equal to the expected response latency, the local service <NUM> analyzes the one or more user inputs and the local cache <NUM> to generate (<NUM>) the predictive text. For example, the local prediction engine <NUM> of the local service <NUM> may receive the one or more user inputs of "#fo" and determine the most likely predictive text is "#foodie". The local prediction engine <NUM> may rely on a location of the mobile device <NUM>, context of the one or more user inputs, a frequency of usage of the hashtag "#Yosemite", popular items at the time of the prediction, popular brands at the time of the prediction, common hashtags, company names relevant to the user <NUM>, venues near the mobile device <NUM>, and/or languages used by the user <NUM> to determine the most likely predictive text. In some examples, the local prediction engine <NUM> may generate multiple predictive texts, such as "#foodie", "#food", and "#follow".

Next, the local service <NUM> may send (<NUM>) the predictive text of "#foodie" to the UI module <NUM>. The UI module <NUM> may display (<NUM>) the hashtag "#Yosemite" to the user <NUM>.

Referring to <FIG>, a process flow diagram <NUM> illustrates an example of a method for predictive text entry. First, in certain implementations, the user may provides (<NUM>) one or more user inputs to the UI module <NUM>. The one or more user inputs may include characters, alphabetic characters, numbers, symbols, phonetics, keys, or other textual representations. In a non-limiting example, the one or more user inputs may be "#Ca".

After sending (<NUM>) the one or more user inputs to the cloud service <NUM>, the local service <NUM> may determine (<NUM>) that the expected user input interval is less than or equal to the expected response latency. In other examples, the local service <NUM> may determine (<NUM>) that the expected user input interval is greater than a product of a factor and the expected response latency.

If the local service <NUM> determines (<NUM>) that the expected user input interval is greater than the expected response latency, the local service <NUM> waits (<NUM>) for the remote service <NUM> to send the predictive text. The local service <NUM> may wait (<NUM>) for information from the remote service <NUM> for a predetermined period of time. During the wait, the local service <NUM> may not send any predictive text to the UI module <NUM>. Further, during the wait, the UI module <NUM> may continue to send the one or more user inputs to solicit a response. However, if the remote service <NUM> fails to send the predictive text within the predetermined period of time, e.g. <NUM> milliseconds after the local service sending (<NUM>) the one or more user inputs, the local service <NUM> may analyze the one or more user inputs and the local cache <NUM> to generate (<NUM>) the predictive text. For example, the local prediction engine <NUM> of the local service <NUM> may receive the one or more user inputs of "#Ca" and determine the most likely predictive text is "#California".

Next, the cloud service <NUM> may send (<NUM>) the predictive text to the UI module <NUM>. The UI module <NUM> may display (<NUM>) the hashtag "#California" to the user <NUM>.

Referring now to <FIG>, the mobile device <NUM> may perform a method <NUM> of predictive text entry. At block <NUM>, the method <NUM> receives one or more user inputs from a user via a user interface. For example, the UI module <NUM> may receive four characters "#MeT" from the user <NUM> via the touch-sensitive keyboard <NUM>. The user <NUM> may sequentially provide <NUM> inputs (i.e. #, M, e, T) by physically contacting the respective keys on the touch-sensitive keyboard <NUM>.

At block <NUM>, the method <NUM> may transmit the one or more user inputs to a remote server. For example, the communication module <NUM> may transmit the four characters "#MeT" to the remote server <NUM> via the communication network <NUM>.

At block <NUM>, the method <NUM> obtains an expected user input interval and an expected response latency. For example, the timing module <NUM> may obtain an expected user input interval and an expected response latency. The timing module <NUM> may utilize the clock <NUM> to measure the expected user input interval and the expected response latency. the expected user input interval is the projected temporal pause between successive user inputs. In one implementation, if the user <NUM> previously typed the words "Amadeus Mozart", and the intervals between "A" and "m", "m" and "a", "a" and "d", "d" and "e", "e" and "u", and "u" and "s" are <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> milliseconds, respectively, and the intervals between "M" and "o", "o" and "z", "z" and "a", "a" and "r", and "r" and "t" are <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> milliseconds. The interval between "s" and "M" may or may not be included in the calculation for the expected user input interval. Without including the interval between "s" and "M", the average interval for the term "Amadeus Mozart" is <NUM> milliseconds. The timing module <NUM> may use the average interval of <NUM> milliseconds as the expected user input interval. Alternatively, the timing module <NUM> may use a simple moving average, a weighted moving average, a cumulative moving average, or an exponential moving average to calculate the expected user input interval. In other examples, the timing module <NUM> may measure previous n response latencies to obtain the expected response latency. In one implementation, the timing module <NUM> may set the expected response latency as the average response latencies for the previous n response requests, e.g. <NUM> milliseconds. In other implementations, the timing module <NUM> use a simple moving average, a weighted moving average, a cumulative moving average, or an exponential moving average to calculate the expected response latency based on the response latencies of the previous n response requests.

At block <NUM>, the method <NUM> determines whether the expected user input interval is greater than a product of the expected response latency and a factor. For example, the decision engine <NUM> may determine that the expected user input interval (<NUM> milliseconds) is greater than the product of the expected response latency (<NUM> milliseconds) and a factor of <NUM>. In some implementations, the factor may range from <NUM> to <NUM>, including <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. The factor may account for delay between step <NUM> and step <NUM> (described below).

At block <NUM>, the method <NUM> displays um) via the user interface, one or more predicted inputs received from the remote server, if the method <NUM> determines the expected user input interval is greater than the product of the expected response latency and the factor. For example, the touch-sensitive display <NUM> of the UI module <NUM> may display "#MeToo" to the user <NUM> if the decision engine <NUM> determines <NUM> milliseconds is greater than <NUM> x <NUM> milliseconds. In some examples, prior to displaying the one or more predicted inputs, the local prediction engine <NUM> may first identify "#MeToo" or "oo" from the remote server <NUM> including receiving "#MeToo" or "oo" from the remote server <NUM> in response to transmitting "#MeT" to the remote server <NUM>. The hashtag "#MeToo" may be the selected by the remote prediction engine <NUM> as the most likely predictive text due to its popularity at the time of the prediction. In certain implementations, the communication module <NUM> may receive "#MeToo" or "oo" from the remote server <NUM>. In other implementations, the one or more user inputs received by the communication module <NUM> may include "#MeToo" and other candidate predictive texts, such as "#metmuseum", "#metopera", and "#Met". In some examples, for example, the local prediction engine <NUM> may predict "#MeToo" based on the one or more predicted inputs sent by the remote server <NUM>.

at block <NUM>, the method <NUM> displays via the user interface, one or more predicted inputs associated with a content of a local cache, if the method <NUM> determined the expected user input interval is not greater than a product of the expected response latency and a factor. For example, the touch-sensitive display <NUM> of the UI module <NUM> may display "#MeToo" to the user <NUM>, if the decision engine <NUM> determines the expected user input interval is not greater than the product of the expected response latency and the factor. In some examples, prior to displaying the one or more predicted inputs, the local prediction engine <NUM> may identify "#MeToo" based on the content of the local cache <NUM>, and "#MeT"The prediction may be based on a location of the mobile device <NUM>, context of the one or more user inputs, an event associated with the user <NUM> or the mobile device <NUM>, a frequency of usage of the hashtag "#Yosemite", popular items at the time of the prediction, popular brands at the time of the prediction, common hashtags, company names relevant to the user <NUM>, venues near the mobile device <NUM>, and/or languages used by the user <NUM>.

In certain implementations, the mobile device <NUM> may prepopulate the local cache <NUM> prior to the UI module <NUM> receiving one or more user inputs by downloading at least a portion of the content from the remote server <NUM>. The at least a portion of the content may be selected based on a location of the mobile device <NUM>, a current time, or a user history of the user.

In other implementations, the mobile device <NUM> may use the information from the remote server <NUM> to update the content of the local cache <NUM>. The local cache <NUM> may be updated periodically, such as every <NUM> minutes, every hour, every <NUM> hours, every <NUM> hours, every <NUM> hours, or every <NUM> hours.

In some examples, the mobile device <NUM> may prune the content of the local cache <NUM> by deleting a portion of the potential predictive texts. When determining the portion of the potential predictive texts to delete, the mobile device <NUM> may use a most-specific-first policy (i.e. deleting the most specific texts first), a longest-first policy (i.e. deleting the longest texts first), a shortest-first policy (i.e. deleting the shortest texts first), an oldest-first policy (i.e. deleting the oldest texts first), a youngest-first policy (i.e. deleting the youngest texts first), a least-recently-first policy (i.e. deleting the least recently used texts first), or a least-frequently-first policy (i.e. deleting the least frequently used texts first).

Referring to <FIG>, the mobile device <NUM> may include a processor <NUM> configured to implement the local service <NUM>. Components of the local service <NUM> may be implemented as hardware in the processor <NUM> for example, as software code executed by the processor <NUM>, or a combination thereof. The processor <NUM> may include one or more processors or cores, and may be implemented as a semiconductor processor, a field programmable gate array, a programmable logic device, a processing cluster, an application specific integrated circuit, or other suitable architectures. The mobile device <NUM> includes a memory <NUM> including the local cache <NUM>. The memory may be static or dynamic memory such as flash memory, random access memory, magnetic memory, or semiconductor memory. The memory <NUM> may include external memory accessible via the network communication <NUM> such as a cloud storage. The mobile device <NUM> further includes a modem <NUM> for communicating with the remote server <NUM>. The mobile device <NUM> also includes a RAM <NUM>, such as static or dynamic random access memory (RAM). The mobile device <NUM> may also include an Input/Output (I/O) device <NUM> connected to the touch sensitive display <NUM>. The I/O device <NUM> may be configured to implement the UI module <NUM>. The components within the mobile device <NUM> may be interconnected by a bus <NUM>.

Referring to <FIG>, one example of the remote server <NUM> may include a variety of components, some of which have already been described above. The remote server <NUM> may include a processor <NUM> configured to implement the remote service <NUM>. Components of the remote service <NUM> may be implemented as hardware in the processor <NUM> for example, as software code executed by the processor <NUM>, or a combination thereof. The remote server <NUM> includes a memory <NUM> including the data store <NUM>. A RAM <NUM>, a modem <NUM>, an I/O device <NUM>, and a bus <NUM> of the remote server <NUM> may be the same as or similar to the corresponding components of the mobile device <NUM>, as described above, but configured or otherwise programmed for server operations as opposed to mobile device operations. The remote server <NUM> may also include an external storage <NUM> such as external hard drives, backup drives, cloud storage, network drives. In some examples, a portion of all of the data store <NUM> may be stored in the external storage <NUM>.

As used in this application, the terms "device," "component," "system," and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal.

Furthermore, various examples are described herein in connection with a device, which can be a wired device or a wireless device. A wireless device may be a computer, a gaming device, cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem. Further, a wired device may include a server operable in a data centers (e.g., cloud computing).

It is understood that the specific order or hierarchy of blocks in the processes / flow charts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flow charts may be rearranged.

The previous description is provided to enable any person skilled in the art to practice the various examples described herein. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples. Thus, the claims are not intended to be limited to the examples shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more. " The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. " Any example described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other examples. Unless specifically stated otherwise, the term "some" refers to one or more. Combinations such as "at least one of A, B, or C," "at least one of A, B, and C," and "A, B, C, or any combination thereof" include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as "at least one of A, B, or C," "at least one of A, B, and C," and "A, B, C, or any combination thereof" may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various examples described throughout this application that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase "means for.

It should be appreciated to those of ordinary skill that various examples or features are presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc., and/or may not include all of the devices, components, modules etc. discussed in connection with the figures.

The various illustrative logics, logical blocks, and actions of methods described in connection with the embodiments disclosed herein may be implemented or performed with a specially-programmed one of a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof specially-designed to perform the functions described herein. A specially programmed general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. Additionally, at least one processor may comprise one or more components operable to perform one or more of the steps and/or actions described above.

Further, the steps and/or actions of a method or algorithm described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium. Further, in some examples, the processor and the storage medium may reside in an ASIC. Additionally, in some examples, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product.

If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium, which includes a non-transitory computer-readable medium. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers.

Claim 1:
A mobile device (<NUM>), comprising:
a memory including a local cache (<NUM>);
a user interface (<NUM>) including an input device (<NUM>) configured to receive user inputs and a display (<NUM>); and
a processor operatively coupled to the memory, the processor being configured to:
receive one or more user inputs from a user via the input device (<NUM>) of the user interface (<NUM>);
obtain an expected user input interval, the expected user input interval being a projected temporal pause between successive user inputs;
characterized by the processor being configured to:
obtain an expected response latency for responses from a remote server (<NUM>);
determine whether the expected user input interval is larger than a product of the expected response latency and a factor; and
if the expected user input interval is larger than the expected response latency multiplied by the factor, then transmit the one or more user inputs to the remote server (<NUM>), and display, via the user interface (<NUM>), one or more predicted inputs received from the remote server (<NUM>); else:
if the expected user input interval is smaller than or equal to the expected response latency multiplied by the factor, display, via the user interface (<NUM>), one or more predicted inputs received from the local cache (<NUM>) of the mobile device (<NUM>).