User simulation for model initialization

The subject technology provides generating configuration files that represent user interaction scenarios on a device, the configuration files including a set of user interface (UI) elements to display and a set of interactions corresponding to user activity to perform on at least one UI element of the set of UI elements. The subject technology processes the configuration files using a relevance engine to determine a relevance score of each UI element of the set of UI elements, wherein the relevance score is based at least in part on weights assigned to features based on the user activity and respective variance values of the features, and the features include information related to a location or time. The subject technology generates a user simulation based machine learning model based at least on each relevance score of each UI element. The subject technology stores the user simulation based machine learning model on the device.

TECHNICAL FIELD

The present description relates generally to simulating user behavior with an electronic device, including simulating user behavior for model initialization.

BACKGROUND

Mobile electronic devices (e.g., watch or smartphone) are popular and are often carried by users while performing daily, and/or recurring, tasks. For example, a user of a mobile electronic device may interact with the device over the course of a day by using mobile applications that are installed locally on the device. The mobile electronic device, however, may have a small screen that limits the amount of information that can be provided to the user at any given time. Thus, if the information provided to a user at any given time is not relevant to the user, the user may need to further interact with the mobile electronic device to find relevant information and/or applications.

DETAILED DESCRIPTION

A machine learning model may be utilized to determine relevant information for presenting to a user. With the introduction of wearable electronic devices (e.g., a smartwatch) that may have limited processing power and/or small display screens, ensuring that the user experience (upon activation) is tailored to the user may be difficult to provide (since the user has not yet interacted with the device and therefore user specific attributes are not known). Such wearable electronic devices may execute various applications on the devices that provide information, in the form of visual graphical elements, that are presented to the user. Examples of such applications may include, for example, calendar, weather, sports, among many others (as discussed further herein).

A wearable electronic device may provide, for display, a user interface (UI). For example, the UI may include an arrangement of UI elements depicting cards (e.g., wearable device face tiles) in which each of the cards may contain information (e.g., content including text, images, graphical elements, etc.) that is visually displayed to the user. As used herein, a card may refer to a wearable device face tile or vice versa. Due to the limited size of the display screen on the wearable electronic device, it may be more vital to provide relevant information for display such that the user is able to interact with the wearable electronic device in a more efficient and/or productive manner. For example, a visual arrangement of cards may include several UI elements. In some implementations, information associated with a single card may only be visible, while information associated with the other cards may not be visible at the display. Thus, if only a single card is visible at a time there may be an increased importance for ensuring that the first card presented to the user includes information that is relevant to the user.

The subject technology simulates user behavior, using configuration files representing particular user scenarios, for generating a user simulation based machine learning model. The user simulation based machine learning model, based on a set of configuration files, may then be utilized for pre-training a machine learning (ML) model which provides relevant information. The ML model may then be stored on a particular electronic device. In an example, the ML model, when executing on the particular electronic device, adjusts relevance scores based on the behavior of a user of the electronic device over time. By providing the user simulation based machine learning model for training, or pre-training, the ML model, the electronic device works in an expected manner to the user after being initially activated, such as by presenting relevant information to the user on the first card that is displayed.

More specifically, implementations described herein provide a system that enables recommendations (e.g., suggested content) to be provided after an electronic device is activated, using a ML model generated based on configuration files. In an example, recommendations may be provided in the form of user interface (UI) elements, displayed on a particular electronic device, that indicate suggested interactions for the user to perform and/or that provide relevant content to the user.

The network environment100includes an electronic device110and a server130. The network106may communicatively (directly or indirectly) couple, for example, any two or more of the electronic device110, and/or the server130. In one or more implementations, the network106may be an interconnected network of devices that may include, or may be communicatively coupled to, the Internet. For explanatory purposes, the network environment100is illustrated inFIG. 1as including an electronic device110, and a server130; however, the network environment100may include any number of electronic devices and any number of servers.

The server130may be part of a network of computers or a group of servers, such as in a cloud computing or data center implementation. The server130may store data, such as photos, music, text, web pages and/or content provided therein, etc., that may be accessible on the electronic device110. The server130may be, and/or may include all or part of the electronic device discussed below with respect toFIG. 8.

The electronic device110may be, for example, a wearable device configured to be worn on a user's arm that includes, for example, one or more wireless interfaces, such as WLAN radios, cellular radios, Bluetooth radios, Zigbee radios, near field communication (NFC) radios, and/or other wireless radios. The electronic device110may be, and/or may include all or part of the electronic device discussed below with respect toFIG. 7.

Although the electronic device110is illustrated as being capable of communicating with another device or server using the network106, in one or more implementations described herein, the electronic device110performs operations locally on the device itself to provide relevant information to a user.

FIG. 2illustrates an example diagram of an architecture200of a system for providing a user simulation for model initialization in accordance with one or more implementations. For explanatory purposes, the architecture200is described as being implemented by the server130ofFIG. 1, such as by a processor and/or memory of the server130; however, the architecture200may be implemented by the electronic device110, or any other electronic device(s). Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

As illustrated, the architecture200may be implemented on the server130for providing a user simulation for model initialization. The server130includes a relevance engine and recommendation provider240, a database205including input file210, a database206including configuration files230, a database207including a user simulation based machine learning model250, and a configuration file generator220. Although separate databases are shown in the example ofFIG. 2for purposes of explanation, it is appreciated that in some implementations fewer than three databases can be utilized such that the input file210, the configuration files230and/or the user simulation based machine learning model250are stored in the same database.

As illustrated, input file210is provided, such as by user input. In an implementation, the input file210includes information indicating which cards to show on the display of the electronic device110in a given state. In an implementation, each state may correspond to a particular scenario of a user corresponding to a particular time and/or location (e.g., morning, commute, work, school, gym, and home that relate to different routines or periods of time during the day or night). Further, the input file may include information indicating which interaction(s) are available for each card. An example input file is discussed in more detail inFIG. 3. As a particular card provided for display can correspond to a particular application, the types of interactions available for the card may be dependent on the particular application. For example, interactions may be gesture-based (e.g., tap, press, swipe, drag, etc.) that can invoke different functionality provided by the application.

In one or more implementations, from the input file, the configuration file generator220generates a set of configuration files in which each configuration file can represent a particular scenario for a user. Such scenarios may include, without limitation, scenarios for morning, commute, work, school, gym, and home that relate to different routines or periods of time during the day or night. In an example, the configuration file may include 1) a list of the data or content to show at a specific time or date for each card, and 2) a list of interactions simulated to perform for each card. Further, the configuration file may include information related to a current location of the user for that particular scenario represented by the configuration file. Thus, each configuration may represent user behavior that may be simulated as user interactions (e.g., user activity) with one or more cards provided by one or more applications. An example of a configuration file is further discussed inFIG. 4.

Moreover, interactions in a particular configuration file may include user activity indicating types of simulated interactions (e.g., usage information) with a particular card provided by an electronic device application including, for example, a dwell time, tap through and/or scrolling performed by the user. As referred to herein, dwell time corresponds to how long a user hovers over a particular UI element provided by an electronic device application. Scrolling activity may correspond to how far the user scrolls down a list of UI elements provided by one or more electronic device applications. Further, tap through or not activity corresponds to whether a user taps on a UI element or not which indicates whether the user wanted to get more information related to content provided by the UI element.

A particular UI element (e.g., card or watch face tile) as discussed herein may be provided by a particular application that is local to a particular electronic device (e.g., the electronic device110) that utilizes a machine learning model that is pre-trained by the user simulation based machine learning model250. Some non-limiting examples of applications local to the electronic device may include wearable device applications, widgets, or programs, etc., such as the following: calendar, reminders, alarms, timers, stopwatch, weather, stocks, sports, TV shows, maps, turn-by-turn navigation, sunrise, sunset, activity, breathe, fitness, heartbeat information, active workout, commute, news, Internet of things (IoT), home automation, digital wallet, and/or other wearable device applications providing donated information, etc.

In one or more implementations, the configuration file generator220stores the generated configuration files230in the database206. As illustrated, the relevance engine and recommendation provider240may receive the configuration files230for processing to generate a user simulation based machine learning model (e.g., the user simulation based machine learning model250), which may be utilized to training, or pre-train, a machine learning (ML) model. As discussed above, the configuration files230include user activity (e.g., interactions for cards) that is simulated for one or more cards. In an implementation, the relevance engine and recommendation provider240simulates the interactions of one or more cards based on the information from the configuration files230. In addition, the relevance engine and recommendation provider240determines relevance scores based on the simulated user activity of the configuration files230which may be used to train, or pre-train, a machine learning model for providing recommendations on electronic devices, such as the electronic device110. The server130may then store the machine learning model on one or more electronic devices, such as the electronic device110. For example, the machine learning model may be stored on the electronic device110at the time of manufacturing, and/or at some time prior to providing the electronic device110to one or more users.

The electronic device110, upon activation, utilizes the stored machine learning model to determine a set of cards to initially provide for display to a user (e.g., UI elements corresponding to particular watch tile faces as discussed inFIG. 6). Since the machine learning model has been trained based on scenarios that users may typically encounter, there is an increased likelihood that the set of cards initially provided for display to the user will be relevant to the user.

The relevance engine and recommendation provider240receives the configuration files230. The configuration files230are utilized by the relevance engine and recommendation provider240to pre-train the machine learning model that is subsequently stored in the particular electronic device. In this regard, the machine learning model is pre-trained based at least in part on the information from the configuration files230. Using the configuration files230, the relevant engine and recommendation provider240can then determine the relevance scores, and to determine recommendations based on a ranking of the relevance scores, where the relevance scores may be provided to the machine learning model as part of the pre-training of the machine learning model. Alternatively or conjunctively, the relevance engine and recommendation provider240may provide information from the configuration files230(e.g., the simulated user activity) to the ML model in order to determine a relevance score(s) and then subsequently provide this relevance score(s) to the relevance engine and recommendation provider240for providing one or more recommendations. Such recommendations, as mentioned before, may be in the form of respective UI elements (e.g., wearable device face tiles as shown inFIG. 6) that are provided for display on the electronic device110. In an example, such UI elements are provided as wearable device face tiles that may be presented in manner that the user may interact with the wearable device face tiles (e.g., as discussed further inFIG. 4) through touch input, gestures and/or scrolling, etc.

To determine a relevance score for a particular UI element that may be provided as a recommendation, the relevance engine and recommendation provider240may calculate a Gaussian curve for each particular feature where the Gaussian curve indicates an affinity value (e.g., mean of the Gaussian curve) and a confidence value (e.g., variance of the Gaussian curve) of the particular feature. In an implementation, a respective Gaussian curve for a particular feature is calculated using an affinity value and a variance value of a particular feature, which is based on an assumption that a given affinity value is normally distributed. Examples of features, related to different types of inputs, are discussed further below. The relevance score for the particular UI element may be determined based at least in part on a sum of different Gaussian curves for a number of different features and/or other values discussed further below.

The mean of the Gaussian curve discussed above corresponds to value indicating an affinity (e.g., relevance) of the feature to the user. The variance indicates a confidence value of the affinity of the feature to the user. In an example, a positive affinity of a feature may correspond to user behavior such as when the user taps or clicks on a UI element associated with a wearable device application. Additionally, a negative affinity of a feature may correspond to user behavior such as when the user scrolls by, without any additional interaction, the UI element associated with the wearable device application and/or does not tap or click on the UI element. Further, as an example, a high variance of a particular feature indicates that the affinity value (e.g., mean of the Gaussian curve) of the feature has a low confidence, and a low variance of a particular feature indicates that the affinity value of the feature has a high confidence.

Further, the relevance engine and recommendation provider240include a “bias” value for the particular UI element that may be utilized as part of determining the relevance score. In an example, an initial value for a bias value may be a value such as ten percent (e.g., 0.1), and can be adjusted over time based on how often the user interacts with the particular UI element. The bias value, as used herein, refers to a likelihood or indication that the user will click on or tap the particular UI element, and in at least one implementation, is a particular feature that is always included in determining the relevance score for the particular UI element. For determining a final value for the relevance score, the relevance engine and recommendation provider240determines a sum of the aforementioned Gaussian curves and the bias value. In one or more implementations, the relevance engine and recommendation provider240may utilize a ML model to determine the relevance score in the manner described above. For example, the ML model may implemented using a deep neural network, convolutional network, unsupervised learning technique (e.g., clustering), Bayesian network, hidden Markov model, collaborative filtering, and/or matrix decomposition, and the like. Based at least in part on the relevance scores, the relevance engine and recommendation provider240generates and/or trains the ML model (e.g., the user simulation based machine learning model250), which is then stored on a particular electronic device (e.g., the electronic device110), where the particular electronic device may then utilize the machine learning model for providing recommendations for display on the device itself.

Some non-limiting examples of the aforementioned features (e.g., that a relevance score may be calculated for) may include information that describes the user's current environment and/or that describes historical or likely user behavior such as a current location of user, current time of day or particular time period of the day (e.g., morning, afternoon evening), recent user activity (e.g., what was the user doing), personal digital assistant information, historical topic information requested or other information searched by user (e.g., stocks, weather, sports, categories of applications, etc.), locally stored user profile information, dwell time, scrolling activity (e.g., how far does the user scroll down a list of UI elements), tap through or not activity (e.g., does a user tap on the UI element), a likelihood that the user will launch an application (e.g., based on information such as prior user activity and a probability calculation), and/or when the user puts on or takes off the wearable device or device (e.g., to determine the beginning and end of a user's typical). The content of a particular UI element may be considered a feature that may be included in the relevance score. Other examples of features can include an application identifier for a particular application, and an identifier for a particular UI element provided by an application.

In at least an implementation, features may be included in different groups. For example, features may be included in either a “generalizing” group, which includes features that are not specific to a particular application(s), or a “memorizing” group that include features specific to a particular application. Further, a particular feature group may include different levels of features. Examples of features included in the generalizing group include features indicating a current location, a current time, and a time period of the day. Examples of features included in the memorizing group include features related to a dwell time, tap through for a particular application, scrolling past a particular application performed by the user, a likelihood that the user will launch an application, an application identifier for a particular application, and a specific time and/or location. Examples of levels of features for the generalizing group may include a first level including features related to time and/or location, and a second level for categories of applications (e.g., business, game, etc.). Examples of levels of features for the memorizing group may include a first level including features related to a specific time and/or specific location, and a second level for features related to particular graphical elements of the particular application.

In an example, when a new UI element (e.g., wearable device face tile) for a particular application is introduced, features included in the generalizing group may be weighted more than other features included in the memorizing group. Initially, for this new UI element, the generalizing features may have lower variances (e.g., indicating greater confidence) in comparison with higher variances (e.g., indicating lower confidence) for the memorizing features. Over time as the user increases interaction to provide additional information related to user activity with the new UI element, the features included in the memorizing group may be weighted more than features included in the generalizing group. Further, in an example, after the user performs an initial action for the new UI element, for each subsequent action on the new UI element, a given feature with a very high variance can be weighted more than another feature with a lower variance. In this manner, the system enables a feature with less confidence to have a greater chance to be explored, and enables another feature with greater confidence to have a greater chance to be exploited.

FIG. 3illustrates an example input file300in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

In an example, the input file300may be utilized by components of the server130, such as those illustrated inFIG. 2as discussed above, in order to generate a set of configuration files for pre-training a model learning model that is then stored on a particular electronic device for providing recommendations. The input file300includes information for cards312and information of available interactions314for each of the cards312. In an implementation, the information for cards312includes information indicating which cards to show on the display of an electronic device (e.g., the electronic device110) in a given state. As mentioned before, in an implementation, each state may correspond to a particular scenario of a user corresponding to a particular time and/or location (e.g., morning, commute, work, school, gym, and home that relate to different routines or periods of time during the day or night). In an implementation, the information of available interactions314includes information indicating which interaction(s) are available for each card such as, without limitation, interactions may be gesture-based (e.g., tap, press, swipe, drag, etc.) that can invoke different functionality provided by a particular application.

In an example, the configuration file400is generated, based on the input file300, by components of the server130, such as those illustrated inFIG. 2. The configuration file400may be included in a set of configuration files for pre-training a model learning model (e.g., the user simulation based machine learning model250) that is then stored on a particular electronic device for providing recommendations. The configuration file400pertains to a particular scenario and includes information for content412of a set of cards, information of actions to perform414for the set of cards, and information related to a location416of the user for that particular scenario represented by the configuration file400. In an implementation, the information for content412includes information including a list of the data or content to show at a specific time or date for each card. In an implementation, the information of interactions to perform414includes information including a list of interactions to perform for each card. The configuration file400may also include information regarding the user's environment for the scenario, e.g. time of day, location, etc.

FIG. 5illustrates a flow diagram of an example process500for generating a user simulation based machine learning model with one or more implementations. For explanatory purposes, the process500is primarily described herein with reference to the server130ofFIG. 1. However, the process500is not limited to the server130ofFIG. 1, and one or more blocks (or operations) of the process500may be performed by other suitable devices. Further for explanatory purposes, the blocks of the process500are described herein as occurring in serial, or linearly. However, multiple blocks of the process500may occur in parallel. In addition, the blocks of the process500need not be performed in the order shown and/or one or more blocks of the process500need not be performed and/or can be replaced by other operations.

As illustrated inFIG. 5, the server130generates configuration files that represent user interaction scenarios on the device, the configuration files including a set of user interface (UI) elements to display and a set of interactions corresponding to user activity to perform on at least one UI element of the set of UI elements, where the user activity comprises simulated activity performed by a user over a period of time (502).

User activity may include interactions that are performed on applications local to the server130. Some non-limiting examples of applications local to the server130may include wearable device applications, widgets, or programs, etc., such as the following: calendar, reminders, alarms, timers, stopwatch, weather, stocks, sports, TV shows, maps, turn-by-turn navigation, sunrise, sunset, activity, breathe, fitness, heartbeat information, active workout, commute, news, Internet of things (IoT), home automation, digital wallet, and/or other wearable device applications, etc.

The server130processes the configuration files using a relevance engine to determine a relevance score of each UI element of the set of UI elements in which the relevance score is based at least in part on weights assigned to features based on the simulated user activity and respective variance values of the features, and the features include information related to a location or time (504).

In one or more implementations, a Gaussian curve for each particular feature may be determined where the Gaussian curve indicates an affinity value (e.g., mean of the Gaussian curve) and a confidence value (e.g., variance of the Gaussian curve) of the particular feature. The relevance score for the particular UI element may be determined based at least in part on a sum of different Gaussian curves for a number of different features and/or other values. Examples of signals related to features that could affect the relevance score include an order that the user launches one or more apps on the device and an importance of a UI element based on other factors (e.g., important person in a calendar invite). In a touch interface implementation, the relevance score may be further based on a history of not tapping or interacting with a UI element, such that UI element can be scored lower.

The server130generates a user simulation based machine learning model based at least on each relevance score of each UI element of the set of U elements (506). The server130stores the user simulation based machine learning model on a particular device (508). The particular device in an example is separate device from the server130, such as the electronic device110described above inFIG. 1.

FIG. 6illustrates an example graphical user interface displaying recommendations in the form of respective user interface elements in accordance with one or more implementations. A relevance engine and recommendation provider of the electronic device110may provide for display a user interface600for presenting UI elements610,620,630, and640, which may include respective content therein for display. In this example, the relevance engine and recommendation provider of the electronic device may provide similar functionality for determining relevance scores as discussed above for the relevance engine and recommendation provider240of the server130. In one or more implementations, the UI elements610,620,630,640may each be a respective wearable device face tile displayed by the electronic device110based on the stored user simulation based machine learning model. Each UI element may have a different relevance score, and the relevance scores are ranked by the relevance engine and recommendation provider. In this example, the UL elements610,620,630, and640are sorted from highest relevance score to lowest relevance score. However, it is appreciated that the UI elements610,620,630, and640may be sorted in a different order(s) than the example shown inFIG. 6. Further, relevance engine and recommendation provider may concurrently display any number of the ranked UI elements (or subset thereof) even though, for purposes of explanation, four UI elements are shown inFIG. 6.

FIG. 7is an example block diagram of a wearable device700(e.g., a smart watch) according to one or more implementations of the subject technology. The wearable device700can be, and/or can be a part of, the electronic device110shown inFIG. 1. Wearable device700can include processing subsystem702, storage subsystem704, input/output706, RF interface708, connector interface710, power subsystem712, environmental sensors714, and strap sensors716. Wearable device700can also include other components (not explicitly shown).

In many implementations, the wearable device700may keep and display time, essentially functioning as a wristwatch among other things. Time may be displayed in an analog or digital format, depending on the device, its settings, and (in some cases) a user's preferences. Typically, time is displayed on a digital display stack forming part of the exterior of the device.

Storage subsystem704can be implemented, e.g., using magnetic storage media, flash memory, other semiconductor memory (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination of media, and can include volatile and/or non-volatile media. In some implementations, storage subsystem704can store media items such as audio files, video files, image or artwork files; information about a user's contacts (names, addresses, phone numbers, etc.); information about a user's scheduled appointments and events; notes; and/or other types of information, examples of which are described below. In some implementations, storage subsystem704can also store one or more application programs to be executed by processing subsystem702(e.g., video game programs, personal information management programs, media playback programs, interface programs associated with particular host devices and/or host device functionalities, etc.).

Input/output706can include any combination of input and output devices. A user can operate input devices of input/output706to invoke the functionality of wearable device700and can view, hear, and/or otherwise experience output from wearable device700via output devices of input/output706.

Examples of output devices include display720, speakers722, and haptic output generator724. Display720can be implemented using compact display technologies, e.g., LCD (liquid crystal display), LED (light-emitting diode), OLED (organic light-emitting diode), or the like. In some implementations, display720can incorporate a flexible display element or curved-glass display element, allowing wearable device700to conform to a desired shape. One or more speakers722can be provided using small-form-factor speaker technologies, including any technology capable of converting electronic signals into audible sound waves. In some implementations, speakers722can be used to produce tones (e.g., beeping or ringing) and can but need not be capable of reproducing sounds such as speech or music with any particular degree of fidelity. Haptic output generator724can be, e.g., a device that converts electronic signals into vibrations; in some implementations, the vibrations can be strong enough to be felt by a user wearing wearable device700but not so strong as to produce distinct sounds.

Examples of input devices include microphone726, touch sensor728, and camera729. Microphone726can include any device that converts sound waves into electronic signals. In some implementations, microphone726can be sufficiently sensitive to provide a representation of specific words spoken by a user, in other implementations, microphone726can be usable to provide indications of general ambient sound levels without necessarily providing a high-quality electronic representation of specific sounds.

Touch sensor728can include, e.g., a capacitive sensor array with the ability to localize contacts to a particular point or region on the surface of the sensor and in some instances, the ability to distinguish multiple simultaneous contacts. In some implementations, touch sensor728can be overlaid over display720to provide a touchscreen interface, and processing subsystem702can translate touch events (including taps and/or other gestures made with one or more contacts) into specific user inputs depending on what is currently displayed on display720. In some implementations, touch sensor728can also determine a location of a touch on the cover glass. A touch sensor may be incorporated into or on the display stack in order to determine a location of a touch. The touch sensor may be self-capacitive in certain implementations, mutual-capacitive in others, or a combination thereof.

Camera729can include, e.g., a compact digital camera that includes an image sensor such as a CMOS sensor and optical components (e.g., lenses) arranged to focus an image onto the image sensor, along with control logic operable to use the imaging components to capture and store still and/or video images. Images can be stored, e.g., in storage subsystem704and/or transmitted by wearable device700to other devices for storage. Depending on implementation, the optical components can provide fixed focal distance or variable focal distance; in the latter case, autofocus can be provided. Zero, one, or more cameras can be provided, depending on implementation.

In some implementations, input/output706can provide output to and/or receive input from an auxiliary device such as a headset. For example, audio jack730can connect via an audio cable (e.g., a standard 2.7-mm or 3.7-mm audio cable) to an auxiliary device. Audio jack730can include input and/or output paths. Accordingly, audio jack730can provide audio to the auxiliary device and/or receive audio from the auxiliary device. In some implementations, a wireless connection interface can be used to communicate with an auxiliary device.

Processing subsystem702can be implemented as any electronic device capable of processing, receiving, or transmitting data or instructions. Processing subsystem702can include one or more integrated circuits. For example, processing subsystem702may include one or more of: one or more single-core or multi-core microprocessors or microcontrollers, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), or additional combinations of such devices. In operation, processing subsystem702can control the operation of wearable device700. In various implementations, processing subsystem702can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processing subsystem702and/or in storage media such as storage subsystem704.

Through suitable programming, processing subsystem702can provide various functionality for wearable device700. For example, in some implementations, processing subsystem702can execute an operating system (OS)732and various applications for interfacing with a host device, such as a phone-interface application734, a text-interface application736, and/or a media interface application738.

In some implementations, processing subsystem702can also execute a host security process760that provides support for establishing and maintaining a verified communication session with a host device. User data762can include any information specific to a user, such as identification information, user-specified settings and preferences, customized information (e.g., contacts, predefined text messages), and any other user-related data or content.

RF (radio frequency) interface708can allow wearable device700to communicate wirelessly with various host devices. RF interface708can include RF transceiver components such as an antenna and supporting circuitry to enable data communication over a wireless medium, e.g., using Wi-Fi (IEEE 702.7 family standards), Bluetooth™ (a family of standards promulgated by Bluetooth SIG, Inc.), or other protocols for wireless data communication. RF interface708can be implemented using a combination of hardware (e.g., driver circuits, antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components. In some implementations, RF interface708can provide near-field communication (“NFC”) capability, e.g., implementing the ISO/IEC 18092 standards or the like; NFC can support wireless data exchange between devices over a very short range (e.g., 20 centimeters or less). Multiple different wireless communication protocols and associated hardware can be incorporated into RF interface708.

Connector interface710can allow wearable device700to communicate with various host devices via a wired communication path, e.g., using Universal Serial Bus (USB), universal asynchronous receiver/transmitter (UART), or other protocols for wired data communication. In some implementations, connector interface710can provide a power port, allowing wearable device700to receive power, e.g., to charge an internal battery. For example, connector interface710can include a connector such as a mini-USB connector or a custom connector, as well as supporting circuitry.

Environmental sensors714can include various electronic, mechanical, electromechanical, optical, or other devices that provide information related to external conditions around wearable device700. Sensors714in some implementations can provide digital signals to processing subsystem702, e.g., on a streaming basis or in response to polling by processing subsystem702as desired. Any type and combination of environmental sensors can be used; shown by way of example are accelerometer742, a magnetometer744, a gyroscope sensor746, and a GPS receiver748.

Sensors716can include various electronic, mechanical, electromechanical, optical, or other devices that provide information to wearable device700, such as clasp sensor750that can detect when clasp members are engaged with each other or disengaged from each other. As another example, one or more crown sensors752can be disposed to detect input from a crown. Crown sensors752can also include motion sensors, accelerometers, pressure sensors (e.g., piezoelectric devices), or the like.

Power subsystem712can provide power and power management capabilities for wearable device700. For example, power subsystem712can include a battery740(e.g., a rechargeable battery) and associated circuitry to distribute power from battery740to other components of wearable device700that require electrical power. In some implementations, power subsystem712can also include circuitry operable to charge battery740, e.g., when connector interface710is connected to a power source. In some implementations, power subsystem712can include a “wireless” charger, such as an inductive charger, to charge battery740without relying on connector interface710. An inductive charging base may transmit power to an inductive receiver within the device in order to charge a battery of the device.

It will be appreciated that wearable device700is illustrative and that variations and modifications are possible.

FIG. 8illustrates an electronic system800with which one or more implementations of the subject technology may be implemented. The electronic system800can be, and/or can be a part of the server130shown inFIG. 1. The electronic system800may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system800includes a bus808, one or more processing unit(s)812, a system memory804(and/or buffer), a ROM810, a permanent storage device802, an input device interface814, an output device interface806, and one or more network interfaces816, or subsets and variations thereof.

The bus808collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system800. In one or more implementations, the bus808communicatively connects the one or more processing unit(s)812with the ROM810, the system memory804, and the permanent storage device802. From these various memory units, the one or more processing unit(s)812retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The one or more processing unit(s)812can be a single processor or a multi-core processor in different implementations.

The ROM810stores static data and instructions that are needed by the one or more processing unit(s)812and other modules of the electronic system800. The permanent storage device802, on the other hand, may be a read-and-write memory device. The permanent storage device802may be a non-volatile memory unit that stores instructions and data even when the electronic system800is off. In one or more implementations, a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) may be used as the permanent storage device802.

In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) may be used as the permanent storage device802. Like the permanent storage device802, the system memory804may be a read-and-write memory device. However, unlike the permanent storage device802, the system memory804may be a volatile read-and-write memory, such as random access memory. The system memory804may store any of the instructions and data that one or more processing unit(s)812may need at runtime. In one or more implementations, the processes of the subject disclosure are stored in the system memory804, the permanent storage device802, and/or the ROM810. From these various memory units, the one or more processing unit(s)812retrieves instructions to execute and data to process in order to execute the processes of one or more implementations.

The bus808also connects to the input and output device interfaces814and806. The input device interface814enables a user to communicate information and select commands to the electronic system800. Input devices that may be used with the input device interface814may include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output device interface806may enable, for example, the display of images generated by electronic system800. Output devices that may be used with the output device interface806may include, for example, printers and display devices, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a flexible display, a flat panel display, a solid state display, a projector, or any other device for outputting information. One or more implementations may include devices that function as both input and output devices, such as a touchscreen. In these implementations, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

Finally, as shown inFIG. 8, the bus808also couples the electronic system800to one or more networks and/or to one or more network nodes, such as the server130shown inFIG. 1, through the one or more network interface(s)816. In this manner, the electronic system800can be a part of a network of computers (such as a LAN, a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system800can be used in conjunction with the subject disclosure.