Patent Description:
Streaming media devices are becoming more and more popular. Streaming media devices allow a user to browse, search, and watch media content on demand. However, the input mechanisms for these streaming media devices are often simple remote controls without keyboards that require a user to hunt and select individual text characters when entering a search query into a text input control (e.g., text input box). Thus, the process of providing textual input to these streaming media devices can be burdensome to the user.

Some streaming media devices have a corresponding application by which a user can provide text input using a virtual keyboard on the user's handheld device (e.g., smartphone, tablet computer, etc.). However, the user must install and invoke the application before being able to use the virtual keyboard to provide text input to the streaming media device.

Publication "<NPL> discloses virtual keyboards and user input to dismiss them.

Publication "<NPL>) discloses automatic dismissal of a virtual keyboard at the expiration of a timeout.

<CIT> discloses a digital media device that broadcasts a beacon signal upon displaying a password entry field to let a user enter a password.

The systems described herein provide a remote keyboard service for a media device on a separate computing device without having to invoke an application or unlock the computing device. The computing device can receive a message indicating that a text input field on the other device is selected and present a notification to the user prompting the user to invoke the virtual keyboard on the computing device to provide text input to the selected text input field. The computing device can receive user input selecting the notification and present a virtual keyboard for providing text input to the other device. The computing device can receive keyboard input from the user selecting characters and send the characters to the other device. The other device can then user the characters as text input to the selected text input field.

Particular implementations provide at least the following advantages. A remote virtual keyboard can be provided by user devices without having to invoke a specific application. The remote virtual keyboard can be provided even when the user's device is locked. Because the need for the keyboard is advertised to all user devices, the user can select the user device most convenient to the user.

Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and potential advantages will be apparent from the description and drawings, and from the claims.

Examples of a method, apparatus, and computer program for providing a remote keyboard service on a user device are disclosed below. In the following description, for the purposes of providing explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.

<FIG> is a block diagram of an example system <NUM> for providing a remote keyboard service on a user device. In some implementations, system <NUM> can include user devices <NUM> (e.g., 102a, 102b. For example, user device 102a can be a computing device, such as a smartphone, tablet computer, television, desktop computer, laptop computer, household device, electronic book device, game device, smart watch, smart glasses and/or other mobile or wearable device, the accessories and peripherals of these devices, or any combination thereof.

In some implementations, user devices <NUM> (e.g., user device 102a, user device102b. user device 102n) can be configured with respective operating systems <NUM> that provide a variety of services and features. For example, operating systems <NUM> can be configured to receive and decode state advertising messages (e.g., Bluetooth packets, Bluetooth LE packets, etc.) from different devices within close proximity of user devices <NUM>. The state advertising messages can include information describing the current state of other devices, including the availability of different services, data necessary for the coordination of processing between different devices, and/or requests for information and/or services from other devices. For example, user device 102a can receive state advertising messages from user device 102b and/or 102n describing the current state of these devices.

In some implementations, user devices <NUM> can receive state advertising messages from media device <NUM>. For example, media device <NUM> can be a computing device, such as a streaming media player, a set top box, a smart television, a laptop computer, or other computing device. The user of user devices <NUM> may interact with media device <NUM> to browse and search for media items to play and/or other content to view. For example, media device <NUM> can present graphical user interfaces on a display (e.g., television, computer monitor, etc.) connected to media device <NUM> that allow the user to browse, search, and select media items (e.g., movies, websites, images, photos, etc,) for media device <NUM> to present on the display of media device <NUM>.

In some implementations, media device <NUM> may require text input from the user. For example, media device <NUM> may require text input from the user when searching for media items. Media device <NUM> may require text input from the user when logging into a subscription service that requires the user's login credentials. Sometimes operating system <NUM> of media device <NUM> will require some text input. For example, media device <NUM> can present a prompt and a text input control on the display of media device <NUM> for receiving network configuration input, login credentials, etc. Sometimes application <NUM> (e.g., a media content provider software application, video application, music application, gaming application, weather application, etc.) will present a prompt and a text input control for receiving text input from the user. For example, application <NUM> may provide a media item search feature that allows the user to input text that defines a search query.

In some implementations, a user can provide text input using a remote control device <NUM>. For example, media device <NUM> may have been sold with or work with a remote control device <NUM> with a few directional buttons and a select button to move a cursor on media device <NUM> and select items on a display. Sometimes remote control device <NUM> can have a touch interface and remote control device <NUM> can receive touch input gestures (e.g., swipe up, swipe down, swipe left, swipe right, tap, etc.) to move a cursor on media device <NUM> and select items on a display. When providing text input to media device <NUM> with remote control device <NUM>, the user typically has to use the remote control device <NUM> to move a cursor over an array of characters presented on a graphical user interface and select one character at a time until the appropriate string is built. This process can be slow a burdensome to the user and generally results in a frustrated user if the user has to perform this hunt-and-peck process repeatedly to find a media item the user would like for media device <NUM> to play.

To solve the above problem with entering text with remote control device <NUM>, user devices <NUM> can be configured with remote control applications <NUM> (e.g., 104a, 104b) for remotely interacting with media device <NUM>. For example, remote control applications can control media device <NUM> over network <NUM>. Network <NUM> can be, for example, a local area network, wide area network, local Wi-Fi network, adhoc peer-to-peer network, etc. Network <NUM> can be implemented using internet protocol, Bluetooth, Bluetooth Low Energy, or any other networking protocol.

In some implementations, remote control applications <NUM> can be configured to provide similar functionality as remote control device <NUM>. For example, remote control applications <NUM> can present on a display of user devices <NUM> directional controls for moving a cursor and a selection control for selecting an item presented by media device <NUM>. However, remote control applications <NUM> can also provide a virtual keyboard that the user can use to provide textual input to media device <NUM>. For example, the virtual keyboard can be presented by remote control application 104a on a touch sensitive display of user device 102a and the user can type on the virtual keyboard to select characters and create strings corresponding to the required textual input. User device 102a can then send the textual input to media device <NUM> through network <NUM>. Media device <NUM> can then use the textual input to perform a search, configure operating system <NUM>, configure application <NUM>, or for any other purpose.

While providing text input to the virtual keyboard provided by remote control application <NUM> is an improvement over entering text using remote control device <NUM>, the user is still burdened with unlocking user device 102a and invoking remote control application 104a before being able to access and use the virtual keyboard to provide textual input to media device <NUM>. Thus, in some implementations, operating system 104a of user device 102a can provide a virtual keyboard service for providing text input to media device <NUM>. For example, user device 102a can provide the virtual keyboard service without unlocking user device 102a. User device 102a can provide the virtual keyboard service without invoking remote control application 104a.

In some implementations, media device <NUM> can broadcast a remote keyboard service request to connect to a remote keyboard service provided by user devices <NUM>. For example, the remote keyboard service request can be (e.g., part of) a device state advertising message indicating that a text input control has been selected on media device <NUM>. For example, when the user is interacting with media device <NUM> (e.g., using remote control device <NUM>) and selects a text input field, media device <NUM> can generate a state advertising message indicating that the text input field has been selected. For example, if application <NUM> is presenting a media item search graphical user interface, the user may select a text input control on the graphical user interface so that the user can provide a search query. In response to selecting the text input control, application <NUM> can invoke an application programming interface (API) of operating system <NUM> to request keyboard support for providing input to the selected text input control.

If operating system <NUM> is presenting a configuration graphical user interface requiring text input, the user may select a text input control on the graphical user interface so that the user can provide the appropriate configuration string (e.g., network identifier, account credentials, etc.). In response to selecting the text input control, operating system <NUM> can invoke an API of operating system <NUM> to request keyboard support for providing input to the selected text input control. When the keyboard support API is invoked, operating system <NUM> can generate a state advertising message that includes data indicating that a text input control has been selected on media device <NUM>. For example, the state advertising message can include an identifier for media device <NUM>, an identifier for application <NUM>, data (e.g., true/false) indicating that the text input control has been selected, data describing the text input control or the text input to be provided by the user, and/or text input already provided by the user to media device <NUM>. The state advertising message data can be encoded into and decoded from the state advertising message using a state advertising message schema.

In some implementations, media device <NUM> can broadcast the generated state advertising message. For example, media device <NUM> can broadcast the generated state advertising message using a wireless (e.g., peer-to-peer) technology, such as Bluetooth, Bluetooth Low Energy, peer-to-peer Wi-Fi, or some other wireless technology. The state advertising message can, for example, be broadcasted without selecting a specific recipient device. For example, any user devices (e.g., user devices <NUM>) within range of the wireless signal transmitted by media device <NUM> can receive and/or process the advertising message generated by media device <NUM>. Alternatively, only user devices associated with the same user account (e.g., a subscriber account, cloud service account, etc.) as the sending device can receive and decode messages from the sending device. Alternatively, the sending and/or receiving devices do not have to be associated with the same user and/or same user account. For example, user devices <NUM> and media device <NUM> can all be associated with different user accounts or no user account. User devices <NUM> and media device <NUM> can be different types of computing devices, from different manufacturers, with different configurations, and/or different operating systems.

In some implementations, user devices <NUM> can receive the broadcasted state advertisement message. For example, user devices <NUM> (e.g., user device 102a, user device 102b,. user device 102n) within the broadcast range of media device <NUM> can receive the state advertisement message. In response to receiving the state advertisement message, user devices <NUM> can determine based on the state data in the state advertisement message that the text input control on media device <NUM> is currently selected. When user devices <NUM> determine that the text input control is selected on media device <NUM>, operating systems <NUM> on user devices <NUM> will present a graphical notification on the respective devices prompting the user to invoke a virtual keyboard. For example, if the user has user device 102a (e.g., smartphone), user device 102b (e.g., laptop), and user device 102n (e.g., tablet) all within the broadcasting range of media device <NUM>, all these devices can determine the text input control on media device <NUM> is currently selected based on the state advertisement message and all these user devices can present the graphical notification prompting the user to invoke the virtual keyboard on each of these user devices.

In some implementations, user devices <NUM> (e.g., user device 102a, user device 102b,. user device 102n) can present the keyboard notification on the screen of the user device even when the screen of the user device is locked. For example, user devices <NUM> can present the remote keyboard notification upon receiving the state advertisement message being broadcasted from media device <NUM>.

Continuing the above example, assuming the user has user device 102a within the broadcasting range of the media device <NUM>, user device 102a can present the remote keyboard notification on a display of user device 102a. After the user selects the notification on user device 102a (e.g., by touching, swiping, etc. the notification), user device 102a can establish a bidirectional communication session with media device <NUM> through communication network <NUM>. For example, communication network <NUM> may include various networks such as a data network, a wireless network, a telephony network, or any combination thereof. After user device 102a responds to the remote keyboard service request (e.g., embodied in the state advertisement message), media device <NUM> can broadcast another state advertising message indicating that media device <NUM> has connected to a remote keyboard. Thus, in response to receiving the state advertising message indicating that media device <NUM> has connected to a remote keyboard, the other user devices (e.g., user device 102b, user device 102n, etc.) can dismiss (e.g., hide, remove from display) their respective keyboard notifications.

In some implementations, media device <NUM> can send user device 102a information describing the required text input. For example, after establishing the bidirectional communication session through network <NUM>, operating system <NUM> of media device <NUM> can send operating system 104a of user device 102a information describing the text input to be provided by the user through the remote keyboard. For example, the information can include a prompt for the text input field (e.g., "Enter user name:", "Enter password:", "Enter search query:", etc.). The information can include an identification or representation for application <NUM> or operating system <NUM>. For example, the information can include an image, icon, or graphic representing the application <NUM> or the manufacturer of operating system <NUM>. Operating system 104a can then use this information to present a text input control and/or virtual keyboard on a display of user device 102a, as described further below. Alternatively, this information can be obtained from the state advertising message received by user device 102a, as described above.

In some implementations, operating system 104a can send virtual keyboard input to media device <NUM>. For example, operating system 104a can detect when the user provides input selecting characters or other graphical elements presented on the virtual keyboard. After detecting each input, operating system 104a can send a message to operating system <NUM> identifying the selected character or graphical element. For example, operating system 104a can send each character or graphical element individually as they are selected so that operating system <NUM> and/or application <NUM> can respond to each keyboard input appropriately (e.g., by presenting search results, moving between text input controls, etc.). For example, operating system <NUM> can send the keyboard input to application <NUM> so that application <NUM> can respond to the keyboard input according to the programming of application <NUM>. In some implementations, the keyboard service provided by user device 102a can be terminated after the user provides input indicating that the user has finished providing textual input to the selected control. For example, the keyboard service can be terminated and the virtual keyboard dismissed or hidden when the user selects a graphical element (e.g., "enter" key, "done" element, etc.) on the virtual keyboard.

In some implementations, operating system 104a can wait a period of time before terminating the remote virtual keyboard service. For example, even though the user may have finished providing input to a text control presented by media device <NUM>, operating system 104a can continue presenting the virtual keyboard for a period of time (e.g., <NUM> seconds, <NUM> seconds, etc.) after the last input to allow the user to provide input to additional text controls presented by media device <NUM>. Thus, the user does not have to be burdened with invoking the virtual keyboard again if additional textual input is required by media device <NUM>.

<FIG> illustrates an example graphical user interface <NUM> for presenting a remote keyboard notification <NUM> on user device 102a. For example, notification <NUM> can be a graphical element presented by operating system 104a on a display of user device 102a in response to receiving a state advertising message indicating that a text input control is selected on media device <NUM>, as described above. Notification <NUM> can be presented on each user device <NUM> that receives the state advertising message. Notification <NUM> can include, for example, description <NUM> and/or image <NUM> representing media device <NUM> and/or application <NUM>. Notification <NUM> can include prompt <NUM> describing how to invoke the virtual keyboard on user device 102a. For example, the user can invoke the virtual keyboard by selecting (e.g., long touch, pressure touch, tap, swipe, etc.) notification <NUM>.

In some implementations, the user devices <NUM> (e.g., user device 102a, user device 102b,. user device 102n) can present keyboard notification <NUM> on GUI <NUM> of user device 102a when user device 102a is locked. For example, GUI <NUM> can be a lock screen of user device 102a. GUI <NUM> can be a home screen of user device 102a when user device 102a is unlocked (e.g., the user has been authenticated as the user of user device 102a).

<FIG> illustrates an example graphical user interface <NUM> for presenting a virtual keyboard on user device 102a. For example, GUI <NUM> can be presented by operating system 104a on a display of user device 102a in response to the user selecting notification <NUM>, as described above with reference to GUI <NUM> of <FIG>. In some implementations, user device 102a can present graphical element <NUM> representing application <NUM> and/or media device <NUM>. For example, graphical element <NUM> can include description <NUM> and/or image <NUM> representing the media device <NUM>. When the selected text input control is associated with application <NUM>, graphical element <NUM> can include a graphical representation <NUM> (e.g., an image, icon, graphic, etc.) of application <NUM>.

In some implementations, graphical element <NUM> can include prompt <NUM> describing the text input the user should provide. For example, prompt <NUM> can include an instruction to "enter your password" or "enter search term," etc. In some implementations, graphical element <NUM> can include prompt instruction <NUM> describing how to invoke the virtual keyboard on user device 102a. For example, prompt <NUM> can include an instruction to provide a tap, swipe, long touch, or pressure touch gesture to graphical element <NUM> to invoke the virtual keyboard.

In some implementations, GUI <NUM> can include virtual keyboard <NUM>. For example, virtual keyboard <NUM> can be presented on GUI <NUM> in response to the user selecting graphical element <NUM> to invoke virtual keyboard <NUM>. Virtual keyboard <NUM> can be presented in response to user device 102a receiving the input specified by prompt <NUM>, for example. Virtual keyboard can, for example, include a typical virtual keyboard layout for selecting characters. In some implementations, GUI <NUM> can be presented without graphical element <NUM>. For example, virtual keyboard <NUM> can be presented as in GUI <NUM> of <FIG> but without graphical element <NUM>.

In some implementations, user device 102a can present virtual keyboard <NUM> in response to detecting motion. For example, user device 102a can present notification <NUM> on GUI <NUM> of <FIG>. When the user picks up user device 102a to view notification <NUM>, user device 102a can detect the motion of user device 102a (e.g., with a built in motion sensor, accelerometer, etc.), and operating system 104a automatically present virtual keyboard <NUM> on a display of user device 102a. For example, in response to detecting the movement of user device 102a, operating system 104a can present GUI <NUM> of <FIG>. Thus, the user of user device 102a can invoke virtual keyboard <NUM> simply by picking up user device 102a.

In some implementations, virtual keyboard <NUM> can include text control <NUM>. For example, as the user selects characters presented on virtual keyboard <NUM>, the selected characters can be represented on text control <NUM>. Since, as described above, the characters are also sent to media device <NUM> as they are selected on virtual keyboard <NUM>, both user device 102a and media device <NUM> may present similar character strings based on which characters the user has selected. Thus, the user does not have to divert the user's attention from the display of user device 102a while entering text but can compare the text entered on user device 102a with the text received by media device <NUM> when needed.

In some implementations, virtual keyboard <NUM> can include graphical elements <NUM> and/or <NUM> for navigating between text controls (e.g., text input boxes, text input fields, etc.) presented on the display of media device <NUM>. For example, operating system <NUM> or application <NUM> on media device <NUM> may require text input to multiple text input controls. Operating system <NUM> or application <NUM> may require the user's user name and password, for example. The user can select graphical element <NUM> to select the next text input control. The user can select graphical element <NUM> to select the previous text input control.

In some implementations, virtual keyboard <NUM> can include graphical element <NUM> for indicating that the user has finished providing text input. For example, the user can select graphical element <NUM> to indicate that the user is finished providing input to the current text control. When the user selects graphical element <NUM>, user device 102a can send a message to media device <NUM> to cause another (e.g., the next) text input control to be selected on media device <NUM>. When the user selects graphical element <NUM>, user device 102a can send a message to media device <NUM> to terminate the remote virtual keyboard service. Alternatively, the user can select graphical element <NUM> to terminate the remote virtual keyboard service and dismiss graphical element <NUM> and virtual keyboard <NUM>. However, in some implementations, termination of the service may be delayed to allow for selection of additional text input controls on media device <NUM> and provision of additional text input, as described above.

<FIG> illustrates an example graphical user interface <NUM> for presenting a virtual keyboard on a user device. For example, GUI <NUM> can be presented by operating system 104a on a display of user device 102a in response to the user selecting notification <NUM> of <FIG>. GUI <NUM> can, for example, be presented as an alternative to GUI <NUM> based on the features (or lack thereof) provided by various user devices <NUM>. For example, if user device 102a is configured with a pressure touch input feature, user device 102a can present GUI <NUM>. If user device 102a is not configured with a pressure touch input feature, user device 102a can present GUI <NUM>.

In some implementations, GUI <NUM> can include graphical element <NUM> for presenting text input. For example, graphical element <NUM> can be presented in response to a selection of notification <NUM>. Graphical element <NUM> can be presented adjacent to or abutted to notification <NUM>. Graphical element <NUM> can include prompt <NUM>. For example, prompt <NUM> can provide instructions to the user describing what type of information the user should provide to the selected text input control. Graphical element <NUM> can include text input control <NUM>. For example, text input control <NUM> can present the text input provided by the user using the virtual keyboard, as described above.

In some implementations, GUI <NUM> can include virtual keyboard <NUM>. For example, virtual keyboard <NUM> can be presented on GUI <NUM> in response to the user selecting graphical element <NUM>. Virtual keyboard <NUM> can be presented simultaneously or near simultaneously with graphical element <NUM>, for example. Virtual keyboard <NUM> can be presented in response to user device 102a receiving the input specified by prompt <NUM>, for example. Virtual keyboard <NUM> can include a typical virtual keyboard layout for selecting characters.

<FIG> is a flow diagram of an example process <NUM> for providing a remote keyboard service on a user device. More specifically, process <NUM> described herein is an approach for providing a remote keyboard service from a user device to a media device (or any other type of computing device). A user device that implements process <NUM> can provide a remote keyboard service and present a remote keyboard without invoking a user application (e.g., remote control application 104a) on the user device. Process <NUM> can be handled efficiently by the operating system and makes the remote keyboard service available regardless of applications installed on the user device and irrespective of the locked or unlocked state of the user device.

At step <NUM>, user device 102a can receive a state advertisement message broadcast from media device <NUM>. For example, the state advertisement message can identify the media device and include data describing the current state of the media device. According to implementations described herein, the state advertisement message can include data indicating that a text input control presented by media device <NUM> is currently selected. Alternatively, the state advertisement message can include data indicating that media device <NUM> is requesting a connection to a remote keyboard.

At step <NUM>, user device 102a can determine the text input control on the media device is currently selected. For example, based on the state advertisement message received at step <NUM>, user device 102a can determine that a text input control on media device <NUM> is currently selected.

At step <NUM>, user device 102a can present the remote keyboard notification. For example, in response to determining that a text input control on media device <NUM> is currently selected, user device 102a can present a graphical keyboard notification prompting the user to invoke a virtual keyboard on user device 102a. For example, when the user has user device 102a (e.g., smartphone), user device 102b (e.g., laptop) and user device 102n (e.g., tablet) all within the broadcasting range of media device <NUM>, each of these devices can determine the text input control on the media device is currently selected based on the state advertisement message and present the graphical notification prompting the user to invoke the virtual keyboard on each of these user devices.

At step <NUM>, user device 102a can receive the user's selection of the notification. For example, user device 102a can receive user input (e.g., tap, swipe, long touch, pressure touch, etc.) to the notification selecting the notification. In some implementations, the first device the user selects (e.g., the user might tap the graphical notification to invoke the virtual keyboard on that device) will present the remote keyboard on the selected device for the user to input the text into the text field on media device <NUM>. The rest of the devices will dismiss the graphical notification from their screen but still keep the notification in those devices.

At step <NUM>, user device 102a can establish a connection with media device <NUM>. As we discussed above, after the user selects the notification on user device 102a by tapping or clicking the notification, user device 102a can establish a bidirectional communication session with media device <NUM> through communication network <NUM>. For example, user device 102a can establish the session with media device <NUM> through network <NUM> because communication session through network <NUM> may allow for the transmission of more data than the state advertisement message.

At step <NUM>, user device 102a can receive application data from the media device <NUM>. For example, after establishing a communication session with media device <NUM>, media device <NUM> can send application data to user device 102a. For example, the application data can include media device data, such as description <NUM> and/or image <NUM> representing the media device <NUM>. The application data may include a graphical representation <NUM> of application <NUM> and/or prompt <NUM> (e.g., please enter your password) from application <NUM>, as shown in <FIG>.

At step <NUM>, user device 102a can present the device data, application data and/or keyboard on a display of user device 102a. For example, after receiving the device data and/or application data, user device 102a can present the device data and/or application data, as shown in <FIG>.

At step <NUM>, user device 102a can receive user input to the virtual keyboard presented on the user device. For example, the user input can be a selection of a single character or other object (such as graphical elements <NUM> and/or <NUM> for navigating between text controls) presented on the virtual keyboard.

At step <NUM>, user device 102a can send the user input to media device <NUM>. For example, user device 102a can send the user input to the media device <NUM> through communication network <NUM>. For example, after step <NUM> process <NUM> can return to step <NUM>. Steps <NUM> and <NUM> can be repeated until the user has finished providing input to the virtual keyboard. Thus, media device <NUM> can respond to each keyboard input as if the keyboard was directly connected to or part of media device <NUM>.

<FIG> is a flow diagram of an example process <NUM> for requesting a remote keyboard service from user devices. More specifically, the process <NUM> described herein is an approach for advertising the need for a remote keyboard so that the user can select the most convenient device for invoking the remote keyboard, as described above.

At step <NUM>, media device <NUM> can present application <NUM> on a display associated with media device <NUM>. In some implementations, media device <NUM> can be configured with a variety of media applications for presenting media items to the user. The user may invoke application <NUM> on media device <NUM> using a remote control device. Application <NUM> can present a graphical user interface that allows the user to control application <NUM>. For example, application <NUM> can present graphical user interfaces that allow the user to browse, search, and view media items available through application <NUM>.

At step <NUM>, media device <NUM> can receive the indication from application <NUM> that the text input control is selected. For example, while interacting with application <NUM>, application <NUM> may require the user to provide text input. Application <NUM> may require a user name and password. Application <NUM> may require search parameters for performing a search for media. In either case, application <NUM> can present and the user can select (e.g., using remote control device <NUM>), a text input control presented by application <NUM>. When a text input control is selected, application <NUM> can send a message (e.g., using the aforementioned API) to operating system <NUM> on media device <NUM> indicating that a text input control has been selected and/or providing a description of the information required by the text input control. In some implementations, the message can include an identifier for application <NUM> and/or other application metadata, such as graphical representation <NUM>.

At step <NUM>, media device <NUM> can generate the advertising message indicating that the text input control is selected. In some implementations, media device <NUM> can generate a state advertising message including state information indicating that the text input control presented by application <NUM> is selected. For example, in response to receiving the message from application <NUM> at step <NUM>, operating system <NUM> can generate a state advertising message that includes data indicating that a text input control is currently selected on media device <NUM>.

At step <NUM>, media device <NUM> can broadcast the state advertising message. In some implementations, after media device <NUM> generates the state advertising message indicating that the text input control is selected, media device <NUM> can broadcast the state advertisement message. For example, the advertising message can be broadcast without identifying a specific recipient device. Thus, all user devices within the broadcasting range of media device <NUM> may receive the state advertising message.

At step <NUM>, media device <NUM> can receive a message indicating that a user device will provide the remote keyboard for the media device. For example, after all user devices <NUM> within the broadcasting range of media device <NUM> receive the media device state advertisement broadcast from media device <NUM>, media device <NUM> can receive a message indicating that user device 102a will provide the remote keyboard for media device <NUM>. For example, the message can be sent to media device <NUM> through network <NUM>. The message can initiate a bidirectional communication session between media device <NUM> and user device 102a so that media device <NUM> and user device 102a can exchange data related to the text input control.

At step <NUM>, media device <NUM> can send user device 102a application data. For example, the application data may include device data, such as description <NUM> and/or image <NUM> representing the media device (e.g., the media device <NUM>). The application data may include a graphical representation <NUM> of application <NUM> and/or prompt <NUM> (e.g., please enter your password) from application <NUM>, as shown in <FIG>. The application data can be received from application <NUM> by operating system <NUM>, as described above in step <NUM>.

At step <NUM>, media device <NUM> can receive the user's keyboard input from the user device 102a. For example, when user device 102a receives user input selecting characters and/or other objects on the remote keyboard (e.g., keyboard <NUM>, keyboard <NUM>) presented on user device 102a, user device 102a can send the user input (e.g., selected characters or other objects) to media device <NUM>.

At step <NUM>, media device <NUM> can send the user's keyboard input to application <NUM>. For example, after receiving the user's keyboard input from user device 102a, operating system <NUM> can send the keyboard input to application <NUM>. Application <NUM> can then perform an operation according to the purpose of the selected text control. For example, if the currently selected text control is configured to receive user name and/or password input, then application <NUM> can process the keyboard input to determine whether the entered user name and/or password are correct for the user. If the currently selected text control is configured to receive search parameters, then application <NUM> can process the keyboard input by performing a search after each character is entered by the user.

Since media device <NUM> receives and processes each keyboard input (e.g., character selection, object selection, etc.) as the input is received, process <NUM> can return the step <NUM> to receive the next keyboard input and <NUM> to process the next keyboard input. Thus, process <NUM> can repeat steps <NUM> and <NUM> until the user has finished providing input to the selected text control.

Moreover, while process <NUM> describes receiving text input for application <NUM>, process <NUM> can be implemented to receive text input for operating system <NUM> as well. For example, application <NUM> can be replaced in process <NUM> with operating system <NUM> to obtain a remote keyboard service for operating system <NUM> and receive text input for a text input control presented by operating system <NUM>.

This disclosure above describes various Graphical User Interfaces (GUIs) for implementing various features, processes or workflows. These GUIs can be presented on a variety of electronic devices including but not limited to laptop computers, desktop computers, computer terminals, television systems, tablet computers, e-book readers and smart phones. One or more of these electronic devices can include a touch-sensitive surface. The touch-sensitive surface can process multiple simultaneous points of input, including processing data related to the pressure, degree or position of each point of input. Such processing can facilitate gestures with multiple fingers, including pinching and swiping.

When the disclosure refers to "select" or "selecting" user interface elements in a GUI, these terms are understood to include clicking or "hovering" with a mouse or other input device over a user interface element, or touching, tapping or gesturing with one or more fingers or stylus on a user interface element. User interface elements can be virtual buttons, menus, selectors, switches, sliders, scrubbers, knobs, thumbnails, links, icons, radio buttons, checkboxes and any other mechanism for receiving input from, or providing feedback to a user.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that is of greater interest to the user. Accordingly, use of such personal information data enables calculated control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure.

The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. For example, personal information from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection should occur only after receiving the informed consent of the users. Additionally, such entities would take any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services. In another example, users can select not to provide location information for targeted content delivery services. In yet another example, users can select to not provide precise location information, but permit the transfer of location zone information.

<FIG> is a block diagram of an example computing device <NUM> that can implement the features and processes of <FIG>. The computing device <NUM> can include a memory interface <NUM>, one or more data processors, image processors and/or central processing units <NUM>, and a peripherals interface <NUM>. The memory interface <NUM>, the one or more processors <NUM> and/or the peripherals interface <NUM> can be separate components or can be integrated in one or more integrated circuits. The various components in the computing device <NUM> can be coupled by one or more communication buses or signal lines.

Sensors, devices, and subsystems can be coupled to the peripherals interface <NUM> to facilitate multiple functionalities. For example, a motion sensor <NUM>, a light sensor <NUM>, and a proximity sensor <NUM> can be coupled to the peripherals interface <NUM> to facilitate orientation, lighting, and proximity functions. Other sensors <NUM> can also be connected to the peripherals interface <NUM>, such as a global navigation satellite system (GNSS) (e.g., GPS receiver), a temperature sensor, a biometric sensor, magnetometer or other sensing device, to facilitate related functionalities.

A camera subsystem <NUM> and an optical sensor <NUM>, e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips. The camera subsystem <NUM> and the optical sensor <NUM> can be used to collect images of a user to be used during authentication of a user, e.g., by performing facial recognition analysis.

Communication functions can be facilitated through one or more wireless communication subsystems <NUM>, which can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem <NUM> can depend on the communication network(s) over which the computing device <NUM> is intended to operate. For example, the computing device <NUM> can include communication subsystems <NUM> designed to operate over a GSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth™ network. In particular, the wireless communication subsystems <NUM> can include hosting protocols such that the device <NUM> can be configured as a base station for other wireless devices.

An audio subsystem <NUM> can be coupled to a speaker <NUM> and a microphone <NUM> to facilitate voice-enabled functions, such as speaker recognition, voice replication, digital recording, and telephony functions. The audio subsystem <NUM> can be configured to facilitate processing voice commands, voiceprinting and voice authentication, for example.

The I/O subsystem <NUM> can include a touch-surface controller <NUM> and/or other input controller(s) <NUM>. The touch-surface controller <NUM> can be coupled to a touch surface <NUM>. The touch surface <NUM> and touch-surface controller <NUM> can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch surface <NUM>.

The other input controller(s) <NUM> can be coupled to other input/control devices <NUM>, such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of the speaker <NUM> and/or the microphone <NUM>.

In one implementation, a pressing of the button for a first duration can disengage a lock of the touch surface <NUM>; and a pressing of the button for a second duration that is longer than the first duration can turn power to the computing device <NUM> on or off. Pressing the button for a third duration can activate a voice control, or voice command, module that enables the user to speak commands into the microphone <NUM> to cause the device to execute the spoken command. The user can customize a functionality of one or more of the buttons. The touch surface <NUM> can, for example, also be used to implement virtual or soft buttons and/or a keyboard.

In some implementations, the computing device <NUM> can present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, the computing device <NUM> can include the functionality of an MP3 player, such as an iPod™. The computing device <NUM> can, therefore, include a <NUM>-pin connector that is compatible with the iPod. Other input/output and control devices can also be used.

The memory interface <NUM> can be coupled to memory <NUM>. The memory <NUM> can include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). The memory <NUM> can store an operating system <NUM>, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks.

The operating system <NUM> can include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, the operating system <NUM> can be a kernel (e.g., UNIX kernel). In some implementations, the operating system <NUM> can include instructions for performing voice authentication. For example, operating system <NUM> can implement the remote keyboard features as described with reference to <FIG>.

The memory <NUM> can also store communication instructions <NUM> to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers. The memory <NUM> can include graphical user interface instructions <NUM> to facilitate graphic user interface processing; sensor processing instructions <NUM> to facilitate sensor-related processing and functions; phone instructions <NUM> to facilitate phone-related processes and functions; electronic messaging instructions <NUM> to facilitate electronic-messaging related processes and functions; web browsing instructions <NUM> to facilitate web browsing-related processes and functions; media processing instructions <NUM> to facilitate media processing-related processes and functions; GNSS/Navigation instructions <NUM> to facilitate GNSS and navigation-related processes and instructions; and/or camera instructions <NUM> to facilitate camera-related processes and functions.

The memory <NUM> can store other software instructions <NUM> to facilitate other processes and functions, such as the remote keyboard processes and functions as described with reference to <FIG>.

The memory <NUM> can also store other software instructions <NUM>, such as web video instructions to facilitate web video-related processes and functions; and/or web shopping instructions to facilitate web shopping-related processes and functions. In some implementations, the media processing instructions <NUM> are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively.

Claim 1:
A method (<NUM>), comprising:
receiving (<NUM>), by a user device (102a, 102b, 102n), a state advertisement message broadcast from a media device (<NUM>);
based on the state advertisement message, determining (<NUM>), by the user device, that an input control (<NUM>) on the media device (<NUM>) is currently selected;
responsive to a determination that the input control on the media device is currently selected:
presenting (<NUM>), by the user device, a first graphical notification (<NUM>) prompting a user to invoke a virtual keyboard (<NUM>) on the user device;
receiving (<NUM>), by the user device via the first graphical notification, a first user input invoking the virtual keyboard on the user device;
presenting (<NUM>), on a display of the user device, the virtual keyboard for providing input to the text input control selected on the media device, wherein the virtual keyboard is provided by an operating system of the user device that is distinct from any user application on the user device;
receiving, by the user device, user input dismissing the virtual keyboard; and delaying, by the user device, dismissal of the virtual keyboard for a period of time after receiving the user input dismissing the virtual keyboard.