Providing information on an electronic watch

Abstract

This disclosure relates to providing information on an electronic watch. In particular, the invention discloses systems, methods, and devices that can allow an application to provide function bar data that is displayed in a function bar of a watch face. A client application can create a function bar data object according to a template to effectively select how the function bar data is to be displayed. For example, a function bar controller on the watch can receive new data and determine which template to use. The function bar data object can be sent to a display manager, which can identify the selected template and display the data according to the template.

Description

[0001] This application is filed on May 26, 2016, and the invention is entitled " Provide information on electronic watches This is a divisional application of Chinese patent application 201680031623.2.

[0002] Cross-references to related applications

[0003] This patent application claims the benefit and priority of U.S. Patent Application 14 / 872,136, filed September 30, 2015, and U.S. Provisional Patent Application 62 / 171,978, filed June 5, 2015, both of which are incorporated herein by reference for all purposes. Background Technology

[0004] People often view historical and future information on computers. An example of historical information could be the score at the end of each quarter in a football game. An example of future information could be a weather forecast for the next few days or hours. Typically, this type of information is provided in a list.

[0005] However, some devices (such as watches) may have display screens of limited size, making it impractical to display lists of historical and / or future information. Nevertheless, it is still expected that users of such small devices will have convenient access to this information. Summary of the Invention

[0006] Embodiments of this invention allow applications to provide function bar data for display in the watch face's function bar. Client applications can create function bar data objects based on templates to effectively select how the function bar data should be displayed. The function bar data objects can be sent to the watch's system routines, such as to the display manager.

[0007] In some implementations, function bar data for a specific function bar can be arranged according to a template to create function bar data objects. For example, a function bar controller on a watch can receive new data and determine which template to use. Each template can be specified for displaying data in a different way. System routines on the watch (such as a display manager) can be configured to identify the selected template and display the function bar appropriately. The function bar data object can be sent to the display manager using a public API. The display manager can determine specific aspects of the function bar data to be displayed, such as the current watch face color and style.

[0008] Other implementations involve systems, portable consumer devices, and computer-readable media associated with the methods described herein.

[0009] The essence and advantages of the embodiments of the present invention can be better understood by referring to the following detailed description and accompanying drawings. Attached Figure Description

[0010] Figure 1A A first exemplary dial of an electronic watch according to an embodiment of the present invention is shown.

[0011] Figure 1B A second exemplary dial of an electronic watch according to an embodiment of the present invention is shown.

[0012] Figure 2 A modular dial of an electronic watch according to an embodiment of the present invention is shown.

[0013] Figure 3 An accompanying device for communicating with a watch according to an embodiment of the present invention is shown.

[0014] Figure 4A A flowchart of a method according to an embodiment of the present invention is shown, wherein a watch requests an update to function bar data from a specific companion application.

[0015] Figure 4B A flowchart of a method according to an embodiment of the present invention is shown, wherein a specific companion application provides the watch with updates to the function bar data.

[0016] Figure 5A A watch with a dial including a first set of templates is shown according to an embodiment of the present invention. Figure 5B A dial with a second set of templates according to an embodiment of the present invention is shown.

[0017] Figure 6 This is a flowchart illustrating a method for displaying information on an electronic watch according to an embodiment of the present invention.

[0018] Figure 7 A process for initializing and using a template to display data in the function bar of a watch, according to an embodiment of the present invention, is shown.

[0019] Figure 8 The process of providing new function bar data to a watch by an accompanying device according to an embodiment of the present invention is illustrated.

[0020] Figure 9 This is a flowchart illustrating a method by which an accompanying device provides new function bar data to a watch according to an embodiment of the present invention.

[0021] Figure 10 A wearable watch device according to an embodiment of the present invention is shown.

[0022] Figure 11 This is a simplified block diagram of an exemplary companion device or watch device according to an embodiment of the present invention.

[0023] the term

[0024] A watch (or watchmaking device or electronic watch) refers to any device that displays time. An example is a wristwatch or pocket watch. Watches may have configurable dials.

[0025] A "dial" corresponds to a specific layout used to display time and any function bars. A device may have multiple dials defined for use. A "dial" can be defined to display time in a specific way and includes one or more "style windows".

[0026] The "function bar" refers to items on the watch face that do not indicate the time, such as date, weather, atmospheric pressure, and calendar information. A specific function bar corresponds to a specific application running on the device displaying the watch face. The function bar can be displayed within a specific "style window" on the watch face. A "sample window" can correspond to the portion of the watch face designated for displaying the function bar. In some implementations, the user can configure the watch face by determining which data to display in a specific style window (e.g., by selecting a watch application).

[0027] A "template" can be defined as a "style window". A style window can have one or more templates, each specifying data to be displayed in a different way. Different data can also be displayed, or the same data can be displayed in a different way.

[0028] A “companion device” (or companion device) can refer to any device that communicates with the watch. For example, a companion device can refer to a telephone, tablet, or laptop computer. When the watch can communicate with a network, the companion device can also be a server computer. The “watch application” on the watch can have a corresponding “companion application” on the companion device. For example, a new application on the companion device can have a watch version on the watch, and the companion device application can communicate with the watch application, for example, via a “companion extension” that is part of the companion application.

[0029] The accompanying application's "Function Bar Controller" controls the sending of updated function bar data to the watch. The Function Bar Controller can be included in an extension of the accompanying application, which enables communication on the watch.

[0030] "Travel Time" refers to the past or future time selected by the user. The travel time will differ from the current time, and historical / future data corresponding to the selected travel time can be retrieved from the watch's memory to be displayed to the user. Detailed Implementation

[0031] Systems, methods, and devices allow applications to provide function bar data to be displayed in the function bar of the watch face. Client applications can create function bar data objects based on templates to effectively select how the function bar data should be displayed. The function bar data objects can be sent to the watch's system routines, such as to the display manager.

[0032] In some implementations, function bar data for a specific function bar can be arranged according to a template to create function bar data objects. For example, a function bar controller on a watch can receive new data and determine which template to use. Each template can be specified for displaying data in a different way. System routines on the watch (such as a display manager) can be configured to identify the selected template and display the function bar appropriately. The function bar data object can be sent to the display manager using a public API. The display manager can determine specific aspects of the function bar data to be displayed, such as the current watch face color and style.

[0033] Templates can be available for each type of style window (corresponding to the function bar) on the watch face. Each function bar template can define what data should be provided by the application. The application can support a variety of style windows and templates. A list of supported style windows can be provided in the watch application, ensuring that only available applications are provided to the user when configuring the function bar on the watch face.

[0034] When and how frequently to update the function bar data can be influenced by a number of factors, either on the accompanying device or on the watch. These factors may include the application's communication budget, the user's historical usage of the application, current battery level (and other system considerations), current usage, and user preferences.

[0035] I. Function Bar

[0036] Function bars allow users to efficiently view data beyond the time when viewing the watch face. In mechanical watches, function bars function by moving gears within the watch that provide periodic information. In some implementations, electronic watches may be equipped with numerous different function bars, where data can be retrieved from other devices. New applications installed on the watch can be used to add new function bars to specific style windows on various watch faces.

[0037] A. An example dial with function bars

[0038] Figure 1A A first exemplary dial 105 of an electronic watch 100 according to an embodiment of the present invention is shown. The exemplary dial 105 displays a mechanical dial with minute and hour hands. The exemplary dial 105 includes four function bars 110, 112, 114 and 116.

[0039] The function bar 110 displays the sunrise time for the current day or possibly the following day. As shown, the sunrise time is 7:10. An icon indicating that half the sun is visible indicates the sunrise time. The function bar 110 therefore includes changing time data and also includes a normally static image. The function bar 110 can also be configured to display sunset, or both sunrise and sunset. The arrow direction indicates sunrise or sunset. At some point after sunrise, the function bar 110 can change to display the sunset time, and similarly, after sunset, it displays the sunrise time for the following day.

[0040] Function bar 112 displays the time at a specific location, which in this example is the time in New York City. Here, the information in function bar 112 may be derived from the current time of the watch's current location. Other function bars may require data from another device, such as a companion device.

[0041] Various function bars can be used in different windows of the dial. For example, for the window in the upper right corner, the function bar could show the moon phase (how much of the moon will be visible that night). The moon phase can change periodically, for example, once a day at a specified time. New data can be received at said specified time, and function bar 112 can be updated accordingly. Function bar 110 can also be updated at a specified time once new data has been received.

[0042] Function bar 114 displays the current temperature, such as the outside temperature near the electronic watch 100. This is the most recent temperature currently received. The temperature can be received from a weather app running on the watch or accompanying device, which obtains the temperature from a server communicating with a weather service. Such a weather service could be a private or public service that has weather sensors in the vicinity of the electronic watch 100's location.

[0043] The frequency of receiving new temperatures can depend on several factors, such as the current battery level of the electronic watch 100, the power consumption of acquiring the new temperature, and user preferences regarding how frequently the user wants the temperature updated. In various implementations, updates to any function bar may depend on one or more of these and other factors.

[0044] The function bar 116 displays activity information from the electronic watch 100. As shown, there are three concentric rings, each with a different amount highlighted. Each ring corresponds to a different type of activity. Examples of activity types include movement (e.g., walking), exercise (e.g., faster movements than movement, such as running), and standing. The highlighted amount in a ring corresponds to the amount of this activity completed in a day relative to a target amount. The entire ring corresponds to achieving the target amount.

[0045] Figure 1BA second exemplary dial 155 of an electronic watch 100 according to an embodiment of the present invention is shown. The second exemplary dial 155 corresponds to a modular dial for displaying digital time. Window 150 displays digital time with four digits. Various types of digital time can be displayed, such as 24-hour format or 12-hour format indicating above and below. The exemplary dial 155 includes five function bars 160, 162, 164, 166, and 168.

[0046] The function bar 160 displays the day of the week and the date of the month. Therefore, the function bar 160 displays two pieces of information. This information can be generated by an application on the electronic watch 100, such as a calendar application, and is provided to the second exemplary watch face 155. In some embodiments, the exact format for displaying the day of the week and the date can be configured by the user for a specific watch face, or changed by selecting a different watch face.

[0047] The function bar 162 displays calendar event information. It can display various information such as the day of the week, date and / or time, and information about any calendar events associated with that day and / or time. For example, the function bar 162 can display the word "calendar" to indicate the type of data. Calendar event data can be displayed for the associated day and / or time. For instance, the function bar 162 can also display event titles starting from the displayed time. Another example includes displaying the number of events after a specific time.

[0048] As shown in the figure, function bar 164 displays the current temperature. Function bar 166 displays concentric rings showing activity completion. Function bar 168 displays battery level. Other illustrative function bars include alarm clock time, timer (with a different symbol than the alarm clock), stopwatch, world clock (for example, for a specific city) to get the time in another time zone, and stock market quotes.

[0049] Other examples could include any application (such as a third-party application) that provides function bar data in a template format. Such third-party applications can be formed from a variety of applications, such as news, social media, sports, and weather.

[0050] In some implementations, certain function bars may receive updated data (e.g., in a template format), and the watch face's display routines may determine how to display the updated data. In some implementations, once time travel mode is enabled, the function bars may change in response to user input selecting historical and / or future times. This new data may be received by the function bars from an application running on the watch or from an application running on another device that can communicate with the watch application.

[0051] B. A dial with a style window

[0052] On mechanical watches, the function bar layout is fixed. If you want a different function bar, you'll need to buy a new watch. On electronic devices, however, users can select a specific watch face from a list of available watch faces. Different watch faces can have different function bar layouts, different numbers of function bars, and different sizes of windows used to display the function bars. These watch face windows can be called style windows, and a specific watch face can correspond to a specific style.

[0053] Figure 2 A modular dial 205 of an electronic watch 200 according to an embodiment of the present invention is shown. The modular dial 205 includes a time window 210 and five style windows 220-228 for a function bar. The modular dial 205 is illustrated as having a specific function bar layout. Different style windows may have different sizes and display different amounts of data. For example, style window 222 may display more data because it is larger than style windows 224-228. Therefore, a user may wish to configure style window 222 to display a function bar corresponding to an application that needs to display more than one piece of data (e.g., more than one number).

[0054] One or more display windows on the dial (which may correspond to style windows) may overlap each other, such that the graphic of one display window can be overlaid on the graphic of another display window. For example, time window 210 may display the time above a graphic corresponding to the current time (e.g., the position of the Earth or the Sun).

[0055] In some implementations, the user can enter a custom mode where a function bar is selected for display in a specific style window. The electronic watch 200 may include a digital crown 230 for selecting the function bar to appear in the selected window. Different style windows may have different templates for displaying (formatting) information. The same style window may be used for more than one watch face. Different style windows may have different shapes and different aspect ratios. The same style window may have different sizes.

[0056] Indicative style windows used for the function bar include: small (e.g., for a simulated clock face, such as 112), small modular, large modular, small utilities (e.g., rectangles for a simulated clock face), large utilities, and circles. A style window can be thought of as a container for displaying the function bar. Therefore, the same application can display different information in different types of style windows, resulting in different function bars in different style windows for the same clock face. Another example of a clock face is shown below.

[0057] C. Other exemplary dials

[0058] The celestial dial may display one or more graphical function bars for the solar system (e.g., the positions of the Moon, Sun, Earth, or other planets), day of the week, date, and current time. In some embodiments, no function bars are to be customized, while in others they can be customized. In some implementations, one or more of the graphical function bars may change in response to user input (e.g., moving the numeric crown 230). For example, a user can move the planets forward and backward in time by rotating the numeric crown 230.

[0059] The solar dial displays the sun's current position in the sky on a curve based on the current location and time of day. In some implementations (e.g., using a digital crown), the user can move the sun on the curve to see its position at dusk, dawn, zenith (solar noon), sunset, and dusk (solar midnight). The dial's color can change as the day progresses to match the time.

[0060] In some implementations, time can be displayed using such physical features, rather than digital or analog time. For example, the position of the sun can indicate the time, thus corresponding to time information. Other function bars can then be added to such a dial.

[0061] On an analog watch, two hands can be used: one for total time and a second for the number of revolutions to model a chronograph dial. Customizable hour markers can measure long or short time intervals. Different dials can have different function bars available. For example, a chronograph dial can have a specific set of function bars available, such as: date, calendar, moon phase, sunrise and sunset, weather, stock market, event summary, alarm, timer, battery life, and world clock. A specific set of third-party function bars can also be used.

[0062] Colored watch faces can display the time using a range of vibrant colors to suit the user's mood, for example, by using a digital crown to select the color. In some implementations, watch faces with options for a function bar allow the user to leave the function bar blank in the style window. Some watch faces can add images or characters to the analog watch face display. Additionally, graphical function bars can provide motion videos, such as videos of objects moving in nature.

[0063] The watch allows configuration of any watch face, and users can save specific configurations for custom watch faces. Such configurations can include settings for the specific watch face, such as color and layout. Customization can also include specific function bars selected for the configuration. In one example of a custom watch face, the watch screen can be pressed firmly, and the user can then swipe in a specific direction to access add input (e.g., a + icon). The user can swipe up and down to browse watch faces and tap on watch faces they wish to add. The user can then customize the watch face according to their preferences. A watch face can be deleted by pressing firmly on the display, swiping towards an unwanted watch face, then swiping up and tapping delete.

[0064] II. Communication with accompanying equipment

[0065] A smartwatch can communicate with a companion device to obtain updated information, such as for the function bar. For example, a sports application can run on the companion device, retrieve sports data from a server, and provide the sports data to the watch for display in the function bar. Various mechanisms can exist on both the companion device and the watch to control how and when such function bar data is provided.

[0066] To retrieve new function bar data, the companion application may need to be woken up (launched). Implementations may determine the trigger for launching the companion application, for example, based on previous use of the companion application or the corresponding watch application. Once a particular companion application is launched, the companion device may instruct that particular companion application to retrieve new data, for example, from a server. New function bar data may also be pushed by the server. Modules on the companion device may determine when to send function bar data, for example, based on the usage of both devices, the power status of both devices, and one or more of the user's preferences. The watch application and / or system routines on the watch may process the new function bar data, for example, determining how to display it. And then, the new function bar data can be displayed.

[0067] A. System Diagram

[0068] Figure 3 An accompanying device 310 communicating with a watch 320 according to an embodiment of the present invention is shown. Figure 3 The lines in the diagram correspond to communication occurring in either direction.

[0069] The application package for a specific software application may include software components for the companion device 310 and for the watch 320, such as companion application 312 and watch application 322, respectively. For example, a new application from a specific publisher (e.g., for a specific newspaper, television program, or website) may have a component running on companion device 310 and a corresponding component running on watch 320. Furthermore, the software application may include application extensions (not shown). Application extensions can be used for communication between watch application 322 and companion application 312. Application extensions may run on either the watch or the companion device. These software components may execute independently or together, for example, as part of providing updated function bar data to watch 320. In other embodiments, the software components may be downloaded separately to both devices. Companion application 312 and watch application 322 are examples of client applications.

[0070] The companion application 312 can function as a standalone application operating on the companion device 310 without any interaction with the watch 320. The companion application 312 may include extensions for communicating with the watch 320. Such extensions may be downloaded and installed separately from the companion application, for example, to provide additional functionality.

[0071] The Watch Communication Daemon (WCD) 316 determines how to communicate with the watch 320. WCD 316 determines the specific method for sending any data (such as function bar data) from the accompanying application 312 to the watch 320. For example, WCD 316 can determine which watch applications are currently running and only send data to a specific watch application while that application is running. If a specific watch application is not running, data can be queued. As another example, WCD 316 can execute a background process for sending data (such as files) according to specified rules, such as sending data for a specified amount of time and interrupting it if it is not completed (e.g., allowing other data to be sent).

[0072] WCD 316 can also process any data in a format that the watch 320 can determine. For example, the companion application 312 can send data in the same format regardless of the target device, and WCD 316 can convert the data into a format suitable for the watch. For example, only higher-level communication options can be exposed to the companion application, while all lower-level options available for the companion transport daemon (CTD) 318 can be kept secret from the companion application. WCD 316 can perform conversions between higher-level concepts within the lower-level features of CTD 318. Other daemons can be used for processing other types of devices.

[0073] The WCD 316 can also convert data received from the watch 320 into a format readable by the companion application 312 or any other companion application. The WCD 316 can also interpret one or more request commands from the watch 320, which request data (e.g., function bar data) from the companion application 312 or other companion applications. The WCD 316 can then send the data request to the companion application in a suitable format. If needed, the WCD 316 can interact with an application manager (not shown) that can launch companion applications.

[0074] CTD 318 can transmit and receive data to and from watch 320. WCD 316 can provide logic for specifically determining how to communicate with watch 320, while CTD 318 can communicate with various other devices besides the watch. CTD 318 can be an identity service daemon, as described, for example, in U.S. Patent Application 14 / 475,060, filed September 2, 2014, entitled “Proxied Push,” the entire disclosure of which is incorporated herein by reference. WCD 316 and CTD 318 can be part of the operating system of companion device 310.

[0075] If WCD 316 determines that data should not be sent, it may decide not to provide the data to CTD 318. WCD 316 can do this in several ways. For example, WCD 316 may not notify the accompanying application 312 that the data should be sent. Alternatively, WCD 316 may notify the accompanying application 312 that the data cannot be sent, so the accompanying application 312 can wait until it later attempts to send the data. In another example, WCD 316 may queue the data. WCD 316 may further track which data has not yet been sent and may remind the accompanying application 312 at a later time.

[0076] The accompanying sampling daemon (CSD) 319 tracks user interactions with the device as events and determines predictive interactions and responds proactively. CSD 319 can communicate with other modules on the accompanying device 310, such as an application manager. For example, CSD 319 can determine when a particular accompanying application should retrieve data to send to watch 320, such as when to retrieve new function bar data as part of an update. Similarly, CSD 319 can track user interactions with watch 320 (e.g., by receiving tracking information from watch 320) and determine when to retrieve and send data to watch 320. CSD 319 can perform such actions by creating models and determining predictive probabilities of how a user might interact with accompanying device 310. Further details of the sampling daemon and transmission daemons (e.g., push daemons) can be found in U.S. Patent Publication 2014 / 0366041.

[0077] In some implementations, CTD 318 may queue data in queue 317 to conserve the battery life of watch 320, and send the queued data when other data is requested by watch 320 or when other data is sent to watch 320 (e.g., when some high-priority data is sent or a sufficient amount of data is to be sent). For example, specific data (or a specific accompanying application) may be marked as permissible to send data when other data is not sent, such as regardless of the current state of watch 320. When CTD 318 prompts for this data, WCD 316 may store a record of what the data is, such that when a response is received in response to a specific message, the response can be associated with the specific message sent.

[0078] The Watch Transmission Daemon (WTD) 328 on watch 320 can communicate data sent to / from CTD 318. The Companion Communication Daemon (CCD) 326 provides a protocol specifically for communicating with companion device 310. CCD 326 provides translation of communications to and from watch applications such as watch application 322. The Watch Sampling Daemon (WSD) 329 can track previous user interactions with watch 320 in a manner similar to how CSD 319 tracks user interactions with companion device 310. WSD 329 can also predict how the user might interact with watch 320. In response to such predictions, WSD 329 can cause a request for data to be sent to companion device 310.

[0079] The watch application 322 may include a style window support list 323 that identifies the style windows supported by the watch application 322. Some watch applications may only support certain style windows. In some implementations, if a watch application supports a style window, the support applies to all watch faces using that specific style window. In one implementation, the watch application 322 may run code from the developer in an extension, and the system may provide code to ensure that data from the developer code is correctly interpreted by system modules such as the display manager 340.

[0080] The function bar controller 325 determines when and how function bar data is sent to the display manager 340, which manages the display of data on the screen of the watch 320. The function bar 334 can be generated as an object on the watch face 330, and the function bar 334 can be specifically associated with the watch application 322. Function bar data can be sent from the accompanying application 312 to the watch application 322 via various components. In some embodiments, the function bar controller 325 can determine a specific template corresponding to the style window being used to display the function bar 334.

[0081] The function bar controller 325 can create a function bar data object based on the selected template and send the function bar data object to the display manager 340. The display manager 340 can identify the template used to identify the new function bar data. Based on the specific template used, the display manager 340 can determine how to display the new function bar data, for example, using other settings of the dial 330, such as color or display style.

[0082] In some implementations, when watch application 322 is launched in the foreground, it can send a command to companion device 310 to launch companion application 312, allowing any data to be transferred between the two applications. In one example, watch application 322 can launch and receive user input to transfer one or more files from companion device 310 using companion application 312. When watch application 322 is only running in the background, launching companion application 312 can be prevented.

[0083] The companion device 310 and / or watch 320 can track which applications are currently providing function bar data to the watch face 330. This information can be used to determine which applications can transfer data between the companion device 310 and the watch 320. Additionally, the watch 320 can determine, for example, which watch applications support a specific style window by reviewing the support list for each watch application. This information can be used when configuring the watch face.

[0084] The function bar controller 325 can provide a preferred data refresh rate for how frequently the data in the function bar should be refreshed. This data refresh rate can be used to determine how frequently data should be requested from the accompanying device 310, or how frequently the accompanying device 310 should send data to the watch 320. In various embodiments, the CSD 319 and WSD 329 can use the data refresh rate along with other factors (such as power status and other predicted user interactions) to determine how frequently the function bar 334 on the watch face 330 should be updated. Therefore, the preferred refresh rate can be overridden based on system considerations (power, etc.). The preferred refresh rate can be defined in various ways, such as the time of the next update, the amount of update per time interval, the amount of data per time interval, etc., and combinations thereof. In some embodiments, the function bar controller 325 can make interactive requests to obtain new function bar data.

[0085] Display manager 340 can display icons for watch apps and host watch faces. Display manager 340 can also act as a carousel app to provide information when needed. In some implementations, display manager 340 can access function bar data in memory 342, which can store historical and / or future function bar data. Memory 342 can be various types of memory and includes different memory modules of different types for different purposes. For example, memory 342 may include a cache that acts as runtime memory for currently running processes, and persistent memory (e.g., flash memory) that can store data after the device is turned off.

[0086] Display manager 340 can identify accompanying applications that provide function bar data to dial 330 and determine when to wake up a specific accompanying application based on resources. In other implementations, such determination may be made by WSD 329, which can communicate with display manager 340, or by both. Display manager 340 can determine how long to cache data in memory 342 to keep dial 330 responsive, but not to cause it to stall due to over-caching.

[0087] Companion application 312 can obtain updated function bar data from server 360. Different companion applications can correspond to different servers. Therefore, the server can provide updated data for a specific function bar. The server can be associated with a specific topic (also known as feed).

[0088] In one example, suppose there are two watch faces, each with five different function bars, and the user switches to the other watch face. The list of active function bars can be updated on companion device 310 and / or watch 320. Companion device 310 can notify any servers associated with the active function bar (e.g., based on the activity topic) and any servers previously associated with the active function bar but no longer associated with it. Servers can now change the deliberate priority of pushes to companion device 310 based on the activity status of the function bars on watch 320. For example, a server for a function bar in the activity list might prioritize pushes to companion device 310. Such low-priority data might be sent to watch 320 only when watch 320 is awake or only when other data is sent, as data can be sent from server 360 to companion device 310, while messages for the currently active function bar receive special handling, where they can wake watch 320. In some implementations, high-priority messages from server 360 can wake companion device 310, while low-priority messages can wait until companion device 310 wakes up.

[0089] In some implementations, messages with regular or low priority on the accompanying device 310 may be sent to watch 320 while watch requests data or other data is being sent. For example, a user may have already requested a file transfer, and since watch 320 is known to be awake, other messages may be sent at that time. The longer a message waits in the queue, the higher its priority is increased, and eventually, if the amount of time has been sufficient, it will be sent immediately upon connection to watch 320.

[0090] exist Figure 3 In other embodiments shown, the companion application 312 may have an application extension designated for communicating with the watch. The application package may include the companion application, the application extension, and the watch application, which may include interface files specifying how the watch application's data is displayed. In some embodiments, the companion device 310 may assist in installing the watch application on the watch 320 by downloading the application package and providing the watch application to the watch 320.

[0091] B. Obtain updates from accompanying devices

[0092] New data for watch 320 can be received at companion device 310 in several ways. A corresponding companion application can be launched to retrieve the data. The companion application can be launched in response to a push notification from the server (e.g., the latest score of a sports event). Alternatively, the companion application can be launched in response to a signal from CSD 319, which can be determined that the user may be using the companion application and therefore the companion application can be launched in the background. Once the companion application is launched, data can be retrieved via push and pull from the server. This data can then be sent to watch 320 according to the protocol described above.

[0093] In one implementation, a preferred refresh rate can be sent from watch 320 to companion device 310, and the corresponding companion application can periodically retrieve new data from the server. For example, current weather information can be retrieved hourly. In some specific implementations, CSD 319 can still determine whether the preferred refresh rate will be executed. The priority of a particular companion application can be used to determine whether to execute the preferred refresh rate. The preferred refresh rate can be based on developer settings and / or user input. Therefore, CSD 319 can give more weight to the preferred refresh rate for companion applications with higher priority.

[0094] 1. Background processes on the device

[0095] In some implementations, the companion application may optionally be launched in the background to fetch new function bar data to send to the watch. The companion application may be launched periodically based on analytics such as CSD 319. The companion application may be allocated a budget for the amount of data and / or power that can be used to update data on the watch, such as function bar data.

[0096] As an example of a background process, CSD 319 can track when a user launches a specific companion app or watch app at a specific time each day, such as 9:00 AM. CSD 319 can then enable the specific companion app to launch, fetch new data, and push that data to the watch. Therefore, the data is readily available regardless of whether the user launches a watch app or views a watch face with the corresponding function bar.

[0097] 2. Push notifications from the server

[0098] The server can send push notifications for events, such as displaying notifications or informing users that new content is available. In some implementations, the server can notify companion applications of updates to the function bar. The message notifying the companion application may include the updated data in the function bar. For example, updates to a sporting event can be pushed from the server to companion device 310, and then to watch 320.

[0099] When a push notification is received by the companion device 316, the corresponding companion application can be launched. The companion application processes the data and then sends a request to the WCD 316 to request any data to be sent to the watch 320, such as new function bar data. Then, according to any associated scheduling determined by the CSD 319, the push message can be sent to the watch 320. The watch 320 can receive the push message and wake up the corresponding watch application. The corresponding function bar controller can then provide the updated function bar data object to the display manager 340 for updating the corresponding function bar. Regardless of how the companion device 310 acquires data, the operation on the watch can be the same.

[0100] C. Obtain an update to the watch

[0101] The accompanying device and watch can exchange information to determine how frequently the function bar should be updated. In various implementations, logic within either device can determine the appropriate time to update the function bar data.

[0102] In some implementations, the companion application can send preferences regarding when and how frequently it wishes to update the function bar data, for example, by specifying a refresh rate. The watch (e.g., via WSD 329 and / or display manager 340) can then determine when to request an update to the function bar. The watch may request updated function bar data from the companion device at different times, for example, based on battery level, power consumption, user preferences, etc. Additionally, certain actions on the watch may prompt requests from the companion device, for example, when the watch application is launched in the foreground.

[0103] In other implementations, the companion application may determine whether to send function bar data to the watch, for example, based on preferences received from the watch. Companion application 312 corresponds to the active function bar, and such companion applications may be allowed more budget to be allocated to sending messages to the watch.

[0104] Refresh rates can vary across different companion applications. For example, some toolbars might refresh every few minutes for certain time periods, while others might update only a few times a day or less. For instance, an application that identifies birthdays might refresh less than once a day. Therefore, companion applications could have long periods of downtime without any refresh. Social media applications, on the other hand, refresh many times throughout the day, and users might want to see many of those refreshes.

[0105] These two devices can balance the expected refresh rate based on the expected number of refreshes for the function bar on the active dial. In some implementations, the accompanying application may have a summary window that is allowed to be updated frequently. However, due to power constraints, the function bar cannot be updated frequently for extended periods of time.

[0106] Figure 4A and Figure 4B A flowchart illustrating the steps performed by the accompanying device and the watch to update the application on the watch with new data is shown.

[0107] 1. Pull

[0108] Figure 4A A flowchart of method 400 according to an embodiment of the present invention is shown, wherein a watch (e.g., via WSD 329 and / or display manager 340) requests an update to function bar data from a specific companion application. The individual boxes of method 400 may be optional. Method 400 involves updating a specific function bar corresponding to a specific companion application.

[0109] At box 402, the accompanying application can send refresh preferences. Examples of refresh preferences may include the refresh rate, the start time for updating the function bar data (e.g., for a given day of the week or date), and the end time for updating the function bar data. The accompanying application can be aware that refresh preferences are merely preferences, and the actual refresh rate from the watch may differ.

[0110] In some implementations, the function bar controller in the accompanying application can provide refresh preferences. The function bar controller can determine refresh preferences based on information obtained from the accompanying application, such as the expected rate of data change and the nature of the data (e.g., the specific time at which data change can be expected, such as in the case of a sporting event).

[0111] At box 404, an internal trigger is received. This internal trigger can be generated within the watch, for example, when determining the appropriate time to update the function bar data for a specific accompanying application. Such determination can be based on application-specific refresh preferences and the watch's current state (e.g., battery life, whether it is in active user use, or how much power such a refresh would consume), and can be determined by WSD 329. In some implementations, the user can explicitly request an update to the function bar, for example, by selecting it via touch or otherwise activating it (e.g., via voice).

[0112] At box 406, the watch can request new function bar data, for example, via WTD 328. CTD 318 can identify the message corresponding to WCD 316, for example, because the communication originates from the watch. WCD 316 can identify the corresponding companion application. Along with the request for function bar data, the watch can request any new refresh preferences. Therefore, in some implementations, the companion application can provide new refresh preferences.

[0113] At box 408, the companion application may retrieve new toolbar data in response to the request. For example, companion application 312 may retrieve toolbar data from a server. In some implementations, the companion application may request new toolbar data from the server, or such new toolbar data may be pushed to the companion device, for example, periodically. In other implementations, the new toolbar data may already be stored by the companion device. For example, the companion application may periodically request such data from the server, such as periodically retrieving headlines. The companion device may request from the server to identify any new reports and only retrieve reports that the companion device is currently retrieving.

[0114] The accompanying device can also determine whether to acquire new function bar data. For example, the accompanying device can determine the battery level for each connection status with the network based on the accompanying device's status. Therefore, the accompanying device's management process (e.g., CSD319) can determine whether the accompanying application starts or stops running.

[0115] When new ribbon data is acquired, the accompanying application (e.g., via a ribbon controller) can create an update object that includes the new ribbon data. The update object can specify a particular template for displaying the new data. In other implementations, the watch application can specify the particular template.

[0116] At box 410, the accompanying device can determine whether to send new function bar data. This determination can be made by the WCD 316, which tracks the function bars currently used by the watch, and may be influenced by other state information about the watch (such as connectivity status and resources), as determined by the CSD 319. This determination can be made selectively, for example, if acquiring new function bar data has taken longer than a threshold amount of time, and therefore the watch's operation may have changed. This determination can also be made for other communications involving the watch, such as when a file is being transferred.

[0117] At box 412, new toolbar data is sent to the watch, for example, once it has been determined that new toolbar data can be sent. New refresh preferences can also be sent simultaneously, for example, in the same message. New preferences can specify the preferred time for the watch to request the next update for that particular toolbar application.

[0118] At box 414, the watch can update the corresponding function bar. In some implementations, the new function bar data can be sent in a specific format (e.g., from the function bar controller in the watch) that identifies a specific template for displaying the data in the corresponding style window. The display manager can interpret the data corresponding to the specific template in the function bar update. The specific template can be one of the predetermined templates of the plurality of style windows selected for displaying the function bar. The display manager can use the specific template in conjunction with other settings of the watch face (e.g., colors).

[0119] In this way, the watch can control how frequently the function bar data is updated. Otherwise, the accompanying applications corresponding to the function bars on the active dial could cause undesirable processing on the watch. This control over the function bar data can reduce situations where the watch unnecessarily slows down due to new data from accompanying applications.

[0120] For example, the function bar could correspond to a sports application that provides scores for a specific match. In such an example, the sports application's extension could send user preferences to the watch, indicating a specific start time for displaying when an updated score can be expected in the function bar. The watch could then refrain from sending any requests for new data before that start time, thus conserving power.

[0121] User preferences in sports applications can also indicate the preferred refresh rate once the match begins. An application may have a specific refresh allocation for the function bar throughout the day, so a sports application can determine a specific refresh rate based on its given refresh allocation and the expected length of the match. The watch can then send a request based on the preferred refresh rate, and the sports application can retrieve the score at that time or provide the score if it has already been retrieved.

[0122] 2. Push notifications

[0123] Figure 4B A flowchart of method 450 according to an embodiment of the present invention is shown, wherein a specific companion application provides an update of function bar data to a watch. The various blocks of method 450 may be optional. Method 450 may be executed in the logic components of the companion device to manage the transmission of new data to the watch, for example, to prevent overloading the watch and draining the battery.

[0124] At box 452, the watch can send refresh preferences to the corresponding companion application. Refresh preferences can be sent at various times, such as once a day or multiple times during a day. Refresh preferences can include the watch's current state information, which can be used by the companion device to determine the appropriate refresh rate for pushing new data to the watch. For example, refresh preferences can be determined by the display manager 340 and / or WSD 329.

[0125] At box 454, the trigger can be received by the companion device. In various implementations, the trigger can be a system routine on the companion device (e.g., a watch communication daemon) or a periodic trigger generated by the companion application. Alternatively, the companion application can receive a push notification from a server when new data appears (e.g., a new score is generated). This new score acts as a trigger to send new feature bar data to the watch. Such use for new scores is suitable for certain low-scoring sports, such as football and ice hockey, and possibly rugby. Updating only when there is a score saves battery life compared to periodic refreshes. Even when there is a score update, updates can be provided at certain times, such as at the end of a period or during halftime.

[0126] At box 456, new widget data can be retrieved. New data can be retrieved in several ways. For example, if the trigger is a periodic internal trigger, the new data can be retrieved from the server after the trigger has been received (e.g., by accompanying application 312). New widget data can also be received as a push notification from a corresponding server (e.g., a server where the user has subscribed to push notifications), where the notification of the new data can act as the trigger.

[0127] At box 458, the companion device determines whether new data can be sent to a specific companion application. This determination can be performed by individual modules, such as the Watch Communication Daemon (WCD). The WCD can track which watch applications are running, for example, by tracking which function bars are being used on the active watch face. If the active watch function bar corresponds to a companion application that provides new data, the WCD can determine whether sending the new data is appropriate. The WCD can manage the number of updates to ensure that the number of updates does not violate any policy restrictions on updating function bars.

[0128] In some implementations, the WCD can wait until the watch initiates communication with the companion device before sending any new data. This way, the companion device knows the watch is awake and doesn't need to worry about having to wake it with a push notification. In other implementations, push notifications may be allowed, for example, for companion apps or messages marked as special. When a message is marked as special, the companion device can know that the message can be pushed to the watch to wake the corresponding watch app, such as when the corresponding function bar is active on the watch face.

[0129] At box 460, new data is sent to the watch, as shown in box 412.

[0130] At box 462, the function bar is updated, as shown in box 414.

[0131] In one example, a companion app might be budgeted to send 30 or 40 (or other numbers) updates to the watch daily. If the companion app knows of a specific activity window (e.g., for sports events), it might budget updates to allow for more updates during that window. However, a weather app might distribute updates evenly throughout the day.

[0132] D. Provide watch information to accompanying devices

[0133] Watch information can also be sent to accompanying devices. Users can explicitly request that data be sent to accompanying devices. Alternatively, a background mode can be used to queue content, which will be delivered to the accompanying device at a later time. This can happen while the watch is generating content, and once the data is queued, it can be transmitted to the accompanying device. For example, if the watch is tracking health data, it can have a certain type of process for determining when it is appropriate to send data. Such processes can be managed by WSD 329.

[0134] E. Budget

[0135] CSD 319 and WSD 329 can use budgets to determine what actions the companion device and watch should perform. For example, there can be three budgets related to communication between the devices. One is the total number of messages that can be sent in a day between the server and the companion device, for a specific application and for a specific type of message (such as server pushes or requests from the companion device). Another budget category is how many times the system chooses to launch applications in the background, such as to fetch or process new data. Yet another budget type is the total number of messages that can be sent in a day between the watch and the companion device, for a specific application and for a specific type of message (such as companion device pushes or requests from the watch).

[0136] For example, a weather app might only need to check at a specific time, such as 9:00 a.m., because that's when users wake up. However, the weather app might want to update hourly, which could be too much for the budget determined by the sampling daemon. In some implementations, a hybrid model can be used, where the app wants to update every half hour, but also wants to be able to receive push notifications. The budget can be tracked on both devices, for example, a function bar budget for actions on both devices.

[0137] If the budget runs out, some updates may not be able to be sent at the end of the day. For example, if an application expects to update every 10 minutes, the budget may run out before the end of the day. Additionally, messages at the end of the day may not be allowed to have high priority because they consume the budget allocated to scheduled updates.

[0138] CSD 319 can determine whether a message should be sent based on a budget, such as whether the message is sent via WCD 316. A message can be sent immediately upon CSD approval, but otherwise it can be queued in queue 317, for example. Alternatively, the message can be discarded, and the accompanying application can attempt to send it later.

[0139] III. Template

[0140] Function bar data for a specific function bar can be arranged according to a template to create function bar data objects. For example, the function bar controller on a watch (e.g.) Figure 3 (325) can receive new data and determine which template to use. Each template can be specified to display data in a different way. System routines on the watch (such as the display manager) can be configured to identify the selected template and display the function bar in an appropriate manner. Function bar data objects can be sent to the display manager (e.g., using a public API) via a public API. Figure 3 (340 in the text). The display manager can determine specific aspects used to display function bar data, such as the color and style of the current dial.

[0141] Each style window can have multiple templates (e.g., 5-15) that can be used with it. For example, a dial style window can have eight different templates available. Each template can have a different name to be included in the corresponding function bar data object to identify the template used. In some implementations, different templates can provide different amounts of data. For example, one template can provide three pieces of text data, while another template can provide only one piece of text data or provide five pieces of text data. Different text data can be of different sizes within a template and are different for different templates. Other templates can include numbers, images, and combinations of any data types.

[0142] Figure 5A A watch 500 according to an embodiment of the present invention is shown, having a dial 505 including a first set of templates. The dial 505 has style windows 520 and 522, as well as other style windows. Style window 520 has a first watch application selected to display a corresponding function bar, and style window 522 has a second watch application selected to display a corresponding function bar. In some embodiments, the larger style window 522 may have more available templates than style window 520, because a larger window offers more possibilities.

[0143] Style window 520 displays a template 530 that combines numbers (represented by the "#" symbol) and images according to the first watch application. The image corresponds to a circle with a fill corresponding to the number. The number can be limited to between 0 and 100 (e.g., as a percentage), where 100 provides a fully filled circle. Such templates can be used in activity tracking applications, such as for tracking the percentage of steps taken towards a goal. The numbers are displayed in a small text size.

[0144] Style window 522 displays a template 532 using five text data points according to the second watch application. These five text points are displayed at a first size, for example, a small size. This text can be any text that the second application decides to display. The text can include letters, symbols, numbers, etc.

[0145] As an example of a sports application, the text at the top center indicates the sports league, while four other data points display the score of a specific match. As another example of an investment application, the text at the top center indicates a stock exchange, while four other data points display the prices of four stocks listed on that exchange.

[0146] Figure 5B A dial 505 with a second set of templates according to an embodiment of the present invention is shown. Style window 520 displays another template 540 for a first watch application. In this other template option, the numerals are displayed in larger sizes, and there are no partially filled circles in the image.

[0147] Style window 522 displays another template 542 for the second watch application. In this additional template option, there are only two texts. The top text is smaller, while the bottom text is in a larger font. This type of template is suitable for calendar applications, where the top text provides the date, and the bottom text provides information about the event on the given date and time.

[0148] In some implementations, the watch application (e.g., via a function bar controller) determines which template to use. In other implementations, the template options can be selected by the user. For example, after the user selects which application to use for the function bar, template options can be provided for how data from that application should be displayed. The appropriate options for the corresponding watch application can be displayed. Thus, the list of templates that may be used for the style window can be filtered by the corresponding watch application so that only templates suitable for that application are displayed.

[0149] A. Definition

[0150] As mentioned above, the function bar data object can be defined according to a specific template, allowing the function bar data to be displayed in the desired manner. Different templates can use different amounts of data. Therefore, a specific template will have a fixed amount of data. If different amounts of data are used, they will correspond to different templates. Various template specifications can be published along with how the template is displayed (e.g., as a screenshot), allowing watch application developers to determine which templates are suitable for a specific application and therefore which templates should be supported.

[0151] Templates can be specified using specific names. For example, the fourth template in the first style window can be specified as "1.4," which can be provided as a title or header in the function bar data object. Following the title / header, multiple data items can be provided in a specific order. The order affects how a piece of data will be displayed. For example, the first piece of data in template 532 could correspond to data to be displayed centered at the top. Or, for template 542, the second piece of data could be specified for display as large text. Each piece of data in a template can be allocated specific space (e.g., a specific length) for display.

[0152] In some implementations, the template can be defined as a specific class object. The class can be specified by the name of the template, and the specific class can have a specified amount of data. The function bar data object can therefore represent a specific example of the desired class object. Specific syntax can be used to specify the template to be used and to provide the corresponding data. In one example, the class object may include: title text in the first row, then data in the second row corresponding to the data to be displayed in the first column, then data in the third row corresponding to the data to be displayed in the second column, and so on. In some implementations, the template may specify a font size (e.g., the relative font size between two texts). In other implementations, the font size may be fixed for a given template for specific data.

[0153] As mentioned above, the style window can include names such as "Small," "Small Modular," "Large Modular," "Small Utility," "Large Utility," and "Round." These names can be used as part of the template name. For example, the template could be "Small.One" or "Small.1" to specify the first template for the small style window. These names can be used in the name field of the function bar data object to specify which template should be used. The watch's display manager can read the names and thus determine which template is being provided.

[0154] B. Templates of various types

[0155] As mentioned above, various templates can include images, text, numbers, symbols, and combinations thereof. Images can be static images, such as a specific logo of a company associated with a particular application. Such images can be specified for display in a specific section of the function bar window.

[0156] In other implementations, the image may depend on one of these data. For example, the image may correspond to a specific number. Template 530 is such an example. A specific image may not be provided by the ribbon data object, as the image may be defined by the system. However, the ribbon data object can specify the exact form of the image by providing a number that can be a floating-point number from 0 to 1.

[0157] For example, templates can display specific text within an image. Letters might be displayed inside a circle, as used to specify a particular bus route or other public transportation. The letters can be one color, and the circle another. Templates can specify the image to use, such as circles or squares surrounding the text. Templates can include data (such as text or numbers) to be displayed on the image. Email applications can provide an icon and a number representing the number of messages, with the number displayed on the icon in a specified manner.

[0158] IV. Configure dials for the function bar

[0159] Users can configure the style windows on the dial to display the desired information. For each style window, users can select the application to display the data as a function bar. At this point, template options can be provided for how the user wants the function bar of a particular application to be displayed. Template options can be provided in a visual format. As other examples, template options can be provided in text format or as questions. For example, the user could be asked whether they want to display a graph of the completion percentage. Alternatively, the selected application can determine the best template to use.

[0160] A. List of Supported Applications

[0161] For example, regarding Figure 3 The application may include a list of supported style windows. This list informs the application of the style windows for which it can provide function bar data. The watch application developer can determine which style windows are suitable for the application and then determine which templates for a particular style window are used. In some implementations, a style window will appear in the application's list of supported style windows as long as the application supports at least one template for that style window.

[0162] The watch application may also include a list of supported templates, which can be provided as a single list combined with a list of supported style windows. For example, the application's supported templates may be provided in alphabetical (or other order), with the style window as the first text in the name. The list can be parsed to determine the supported style windows by identifying the different style windows that appear in the template name.

[0163] This list, along with lists from other applications, can be used to determine which application offers an option when the user configures the watch face's style window. Therefore, the watch can identify all applications that support a particular style window based on separate lists received from the various applications on the watch.

[0164] B. User Configuration

[0165] Users can configure various aspects of the watch face, such as color or display style. The function bar can also be configured in various ways. As mentioned above, when a user configures the style window to display the desired function bar for a specific application, the user can be presented with available applications and then select the desired application. Such a list can be quite long, so the user can pre-specify which applications will appear on the list. In some implementations, the user can also specify the template to use.

[0166] 1. User filtering available function bar

[0167] In some implementations, users can disable applications for specific style windows. Applications may support style windows, but users may not want that application to appear in the configuration list. Users may have many applications that support specific style windows, and it can be tedious for them to go through the entire list every time they decide to reconfigure the watch face's function bar.

[0168] There are several ways to prevent an application from being listed in the available applications list in the style window. For example, a user can configure a companion application that provides commands to disable the watch application. Alternatively, a user can launch the watch application and navigate to a screen to prevent it from providing support for a specific style window. Another option is to view a full list of available applications for a specific style window and delete applications (e.g., by swiping in a specific direction). Additionally, users can view the list of available applications and mark certain applications as favorites, thereby enabling those applications. Applications not on the enabled list will be disabled.

[0169] 2. The user selects the function bar application for the style window.

[0170] Users can choose from multiple watch face designs and then adjust the color, features, and other details of the selected watch face. Watch faces can be browsed (e.g., by swiping), and watches can be selected, for example, by pressing firmly on the display. Users can enter configuration mode in several ways, such as by tapping the screen firmly enough. Users can then select a style window and browse available applications, such as using the digital crown. This list can be provided based on the user's configuration of which applications are available, or even if no such user configuration exists.

[0171] Once a user has selected a specific style window, the display manager running on the watch determines the available applications. This list can be stored in persistent storage. The list can be updated, for example, when the user disables one or more applications for a specific style window. The list can also be updated each time a new application is installed. As part of the installation, the watch can retrieve the supported list from the new application and then add the application to any supported style windows. At this point, the option can be provided to the user to disable the application in the future for any style windows for which the user does not wish to use the function bar. The user can then re-enable the application at a later time.

[0172] 3. The user selects a template (feature bar) for the style window.

[0173] In some implementations, once an application has been selected to provide a function bar for a specific style of window, the user is provided with the option to select a template for the function bar. When selecting an application, supported templates can be requested from the application. The application can provide names of such templates, and the user can learn how a particular template displays data through, for example, an application user guide from an accompanying device or a website.

[0174] In some implementations, the watch application may provide an exemplary function bar data object, which can be used to display the function bar to the user. This allows the user to see different data and how it will be displayed. Therefore, the user can make decisions based on the visual data regarding how the function bar will be presented.

[0175] C. Method

[0176] Figure 6 This is a flowchart illustrating a method 600 for displaying information on an electronic watch according to an embodiment of the present invention. Method 600 can be performed using an electronic watch.

[0177] At box 610, a user interface is provided for the user to configure information displayed in one or more style windows in conjunction with the time on the dial. The style windows may correspond to the function bars on the dial. The user interface may be provided in response to specific user input.

[0178] At box 620, a first window selection is received for the first style window of the dial. The first style window is associated with a first plurality of templates for displaying information. The templates may have the features described above.

[0179] In box 630, the identifier is designated as a list of applications that support the first style window. This list can be obtained, for example, from the corresponding application on the smartwatch via the style window support list.

[0180] In some implementations, users can filter the list to remove certain applications, even those that support the first style window. Therefore, users can provide one or more remove commands to remove one or more applications from the first application list. The removal of these one or more applications results in a modified first application list. This modified first application list can be provided to the user upon subsequent selection of the first style window.

[0181] At box 640, a list of applications can be provided to the user. The list can be provided as application names, display examples of applications, or any other suitable method.

[0182] At box 650, a first application selection is received from the first application list. This selection is made by the user in any suitable manner, such as via tap, swipe, or voice command.

[0183] At box 660, a first data object is received from a first application. The first application may be running on an electronic watch and provides the first data object to a display manager. In other embodiments, the first data object may be obtained from an accompanying device on which the first application is running. The first data object may specify a first template among the plurality of templates and may include one or more data items for display according to the first template.

[0184] In some implementations, the first data object may be generated by a function bar controller in a first application, which is executing on the smartwatch. In other implementations, the function bar may be in an accompanying device that provides new function bar data to the smartwatch. The watch's refresh preferences may be sent to the accompanying device to retrieve new data from the first style window. The refresh preferences may specify how frequently and / or when the accompanying device should send new function bar data.

[0185] In some implementations, refresh preferences can be received from the accompanying device. The refresh preferences can specify how frequently and when the accompanying device wants to provide new data for the first style window, where the new data will be used to generate the first data object. The smartwatch can monitor the smartwatch's status and the number of updates from the first application. Thus, the smartwatch (e.g., via a sampling daemon) can determine when to request new data from the accompanying device based on the smartwatch's status and the number of updates.

[0186] At box 670, a first template is retrieved. One or more properties of the first template can be retrieved, allowing data to be formatted for display according to the template. In one embodiment, the first template includes an image whose display depends on the numbers provided in the first data object. Template 530 provides such an example. The first data object can be received by a display manager, which notifies the first application's function bar controller that the first application has been assigned to a first style window. This allows the function bar controller to know which template to use.

[0187] At box 680, the one or more data items are displayed in a first style window on the dial according to a first template. The first data object may include one or more data items, wherein the one or more data items include one or more data types. The one or more data types may be selected from a group including text, images, and numbers. Therefore, one data item may include all three types. Alternatively, three different data items may each include a different data type.

[0188] The same process can be performed for a second style window. A second window selection for the second style window of the dial can be received. The second style window can be associated with a second plurality of templates. A second application list can be specified to support the second style window. After providing the second application list to the user, the user can select a second application from the second application list. The second application can provide a second template specifying the second plurality of templates and include a second data object for displaying one or more data items according to the second template. The one or more second data items can be displayed in the second style window on the dial according to the second template.

[0189] V. Using templates on watches

[0190] Once the watch face has been configured to have a function bar using the selected application, the selected application can use a template to provide function bar data for updating the function bar on the watch face. The application can create a function bar data object based on the desired template that the application wants to use. The function bar controller in the accompanying device or watch can create such function bar data objects that can be passed (e.g., via public API calls) to the display manager on the watch, which is part of the watch's system software.

[0191] Figure 7 A process for initializing and using a template to display data in the function bar of a watch 720 according to an embodiment of the present invention is illustrated. The watch 720 includes components that can correspond to... Figure 3The watch 720 includes various components. The watch application 722 may include a function bar controller 725 and a style window support list 723. In other embodiments, the function bar controller 725 may reside in an accompanying device communicating with the watch. The watch 720 also includes a display manager 740 and a watch face 730, within which a function bar 734 may be displayed.

[0192] At 701, initialization can be performed. As part of the initialization, the display manager 740 can notify the watch application 722 which function bar (e.g., which style window) the application will provide data for. The function bar controller 725 can use information about the corresponding style window when creating a function bar data object for updating function bar data in the function bar 734. In this way, the function bar controller 725 can know that the watch application 722 will use a template of the large modular style (or other style window) when creating the function bar data object.

[0193] At point 702, the function bar data can be received by the watch application 722. This function bar data may have already been sent by a companion device and is received via the watch transmission daemon and companion communication daemon before being received by the watch application 722. In various examples, the companion device may be a telephone communicating with the watch 720, or a server (e.g., when the watch 720 has an internet connection).

[0194] At 703, the ribbon controller 725 determines which template will be used. In some implementations, the ribbon controller 725 can be configured to always select a specific template. For example, the developer can determine that if the style window is large.modular, then the template "large.modular.3" will always be used. If another style window is in use, another template can be selected.

[0195] In other implementations, the function bar controller 725 can determine which template to use based on the type of function bar data being received. For example, if a sports application is providing updates on a specific match, a template displaying two data points (e.g., one of which is large text) can be used. If the sports application is providing a list of matches scheduled for a particular day, another template displaying six data points can be used. Similarly, if a user's favorite teams don't have a match on a particular day, the function bar can display the time of the next match, which could use a different template. The configuration of which data to send can be based on user preferences. Such preferences can be provided to accompanying devices, such as automatically providing scores for favorite teams. If the team is not a favorite, the team can be selected based on the device's current location.

[0196] At 704, the ribbon controller 725 can create a ribbon data object using the determined template. The ribbon data object may include the name of the determined template and ribbon data. In some embodiments, the ribbon data object may include information about how the ribbon data will be displayed, such as whether to use month, day, and / or year in the date. The ribbon data object may also include a style specifying how the data will be displayed, such as whether the date format is numeric, such as "5 / 31 / 15" or "May 31, 2015". The style may also correspond to specific rules for how the data length will be shortened to fit the limited space of the ribbon. Additionally, the ribbon data object may include function calls specifying system routines that determine the display, such as whether the data should be displayed as a regular date, simple text, time interval, or other suitable format.

[0197] At 705, the ribbon controller 725 can provide ribbon data objects via a public API. API calls can be identified as corresponding to the display manager 740 and thus routed accordingly. The display manager 740 can be configured to receive such API calls and respond by updating the corresponding ribbon. The corresponding ribbon can be identified via a table that associates the application with the corresponding ribbon; such a table can be created when the user configures the dial.

[0198] In some implementations, the function bar data object may only include any changed data and indicate which function bar data the new data corresponds to. This reduces the amount of data that needs to be sent to the display manager 740. In other implementations, all data to be displayed in the function bar may be sent each time. In such implementations, the display manager 740 may identify which data has changed and limit processing to only the changed data. For example, only new data may need to be formatted for display.

[0199] At 706, the display manager 740 can retrieve templates identified in the function bar data objects. Templates can be retrieved partially or completely. For example, information about how data is displayed in a template can be retrieved, while other information about the template may not be needed.

[0200] At 707, the display manager 740 determines display information for the function bar object. This display information precisely specifies how the function bar data should be displayed. Therefore, the display information can be provided to the rendering engine that determines which pixels are displayed with which colors and intensities. In some implementations, the display manager 740 determines whether the function bar data is suitable for the space allocated to the function bar. The display manager 740 may need to modify the data, for example, by truncating, reasonably abbreviating, or selectively removing certain text while retaining more critical information so that said information is still conveyed in the function bar.

[0201] At point 708, the updated function bar data is displayed in function bar 734. The display can change some or all of the data in function bar 734. The display information of the updated function bar data can be stored in a buffer and is ready to be used the next time the monitor is turned on.

[0202] VI. Updates are provided to the watch along with the device.

[0203] As described above, the companion device can provide updated toolbar data to the watch. The companion device can obtain new toolbar data based on various triggers. For example, the companion device can receive push notifications from a server. Alternatively, the companion device can determine that the toolbar should be updated periodically based on one or more of the following: previous user interactions with the companion device and / or the watch, planned events (such as expected sports updates), and any other user preferences. The companion device can determine whether to send new toolbar data to the watch based on various criteria.

[0204] A. System diagram of accompanying equipment

[0205] Figure 8 The process of providing new function bar data to a watch using a companion device 810 according to an embodiment of the present invention is illustrated. The companion device 810 includes components that can correspond to… Figure 3 The accompanying device 810 includes various components. The accompanying device 810 includes an accompanying application 812 that corresponds to a function bar for which it is acquiring new function bar data. The server 860 can provide new function bar data to the accompanying device 810. The accompanying device 810 may also include a Watch Communication Daemon (WCD) 816, an Accompanying Transmission Daemon (CTD) 818, and an Accompanying Sampling Daemon (CSD) 819. The WCD 816 tracks which function bars are active (e.g., which applications are currently assigned to function bars on the current watch face). The CTD 818 stores messages in queue 817 that have been requested to be sent to the watch by the accompanying application but are not currently allowed to be sent.

[0206] At 801a and 801b, triggers indicating that new function bar data should be retrieved are received. At 801a, an internal trigger is generated by CSD 819. This internal trigger may be generated in response to a prediction that the user will soon view an update on the watch. For example, a user might check calendar or weather information every morning at 9:00 AM. CSD 819 can identify such patterns and anticipate such requests by providing new function bar data to the watch. Sampling daemons on the watch (such as WSD 329) can also participate in identifying such patterns; for example, WSD can identify patterns and send them to CSD 819.

[0207] At 801b, a push trigger is sent from server 860 to accompanying device 810. In various implementations, the push trigger may correspond to a new message sent to the user or a new event subscribed to by the user (e.g., a new report or post that matches user-specified criteria).

[0208] At 802, new data is received from server 860. In some implementations, the push trigger may include new data. In some specific implementations, an internal trigger (e.g., as in 801a) may initiate companion application 812, and companion application 812 may send a retrieval request to server 860 to obtain new data. The new data may be transmitted to companion application 812 via CTD 818.

[0209] At point 803, the accompanying application 812 may process new data to obtain new function bar data if needed. For example, the accompanying application 812 may analyze the new data and determine which data is suitable to be sent to the corresponding watch application for display in the function bar. The accompanying application 812 may obtain the scores of multiple matches and send only the scores of specific matches to the watch. This determination may be based on which style window is assigned to the function bar, where the watch application may send such style window information to the accompanying application 812.

[0210] At 804, the accompanying application 812 can request that new function bar data be sent to the watch. The request can be routed to the WCD 816, as the WCD 816 manages the communication modes with the watch. Various communication modes are possible, such as those for file transfer, pushing data to the watch, and sending new function bar data.

[0211] At 805, WCD 816 can determine a communication pattern for managing requests to send new function bar data to the watch. For example, WCD 816 can identify that the data to be sent is function bar data and use the corresponding function bar pattern. WCD 816 can track which applications are assigned to the function bars on the current watch face. This information can be received from the watch, for example, when the companion device and the watch first establish a new connection. If the user subsequently changes the watch face or any function bars on the watch face, the change can be communicated to WCD 816. Active function bars can be stored in list 880. Further details regarding the communication patterns can be found in the U.S. patent application filed simultaneously by Ledwith et al., entitled "Network Messaging For Paired Devices".

[0212] In some implementations, if the companion application 812 corresponds to a watch application that is providing data for the active function bar, the WCD 816 can use list 880 to determine which new function bar data should be sent to the watch. Since the companion application 812 is providing data for the active function bar, messages containing that data can be marked as special and thus allowed to be sent to the watch, even if the watch is not currently displaying information.

[0213] If the WCD 816 determines that new function bar data should not be sent to the watch at this time, the WCD 816 may send a response message instructing this to the companion application 812. The companion application may store the new function bar data and subsequently send another request to request that function bar data be sent to the watch. In the meantime, the companion application 812 may obtain updated function bar data.

[0214] At point 806, if WCD 816 determines that new function bar data should be sent to the watch, WCD 816 may send a request to CTD 818 to send a message with the new function bar data to the watch. CTD 818 may further determine whether to send the message with the new function bar data. WCD 816 may make this determination based on information from CSD 819, which may track device information (such as battery level) and the application's budget to determine whether to send the message.

[0215] At point 807, CTD 818 can send new function bar data to the watch. In some implementations, CTD 818 can determine the appropriate time to send the new function bar data. For example, CTD 818 can wait until other data has been sent from the same interface to, for example, another device besides the watch.

[0216] B. Method

[0217] Figure 9 This is a flowchart illustrating a method 900 of an accompanying device providing new function bar data to a watch according to an embodiment of the present invention. Method 900 can be performed by various components of the accompanying device.

[0218] At box 910, a trigger for acquiring new data is received. For example, the trigger could be an internal trigger, such as one generated by a sampling daemon on the watch or accompanying device. Refresh preferences can be received from the watch, and the trigger can be generated based on these preferences.

[0219] At box 920, retrieve new data from the server. New data can be retrieved from the server in response to a trigger. If the trigger receives data from the server, the new data can be sent along with the trigger.

[0220] At box 930, the accompanying application can process new data to obtain new function bar data. For example, the accompanying application can identify specific data that should be displayed in the function bar.

[0221] At box 940, the companion application can request the watch communication daemon to send new function bar data to the watch. The companion application may know its budget for multiple updates and whether the function bar assigned to the application is active. Therefore, the companion application can determine whether to send a request.

[0222] At box 950, the watch communication daemon determines which communication mode should be used. Various modes can include interactive mode, push update background mode (e.g., for pushing news reports and publishing to the watch), file transfer mode, and function bar mode. Function bar mode is used when a companion application sends new function bar data. Requests from companion applications can specify the type of data to be sent, and the data can act as a mode identifier. Explicit flags regarding which mode to use can also be sent in the request.

[0223] At box 960, the watch communication daemon can determine whether to request that new function bar data be sent to the watch. The request may be based on a list of applications (received from the watch) assigned to the function bar on the watch face currently being used by the watch. The list of applications may include a first application. This list may be received when the companion device is first connected to the watch. Access to the application list determines which first application is assigned to the function bar on the watch face currently being used by the watch. New function bar data may be sent to the transmission daemon for transmission to the watch.

[0224] At box 970, the accompanying transfer daemon determines when to send new function bar data to the watch. The transfer daemon determines whether to transfer new function bar data to the watch or to queue the new function bar data for later transfer. This decision can be made as follows: Figure 3 and Figure 8 And as described elsewhere. For example, the determination could be based on a budget allocated for the transmission from the first application to the electronic watch.

[0225] At box 980, the accompanying device can transmit new function bar data to the watch. This new function bar data can be sent along with other data, such as in a batch of messages. The message can specify the type of data included in the message and the receiving application.

[0226] VII. Exemplary Device

[0227] The implementation scheme described herein can take the form of a suitable electronic device, which can be integrated into or operate with a suitable electronic device, such as an accessory device or a watch device. An example of such a device is... Figure 10 As shown, it takes the form of a wearable watch device. Alternative embodiments of suitable electronic devices include mobile phones, tablet computers, portable media players, etc. Other suitable electronic devices may include laptops / notebook computers, personal digital assistants, touchscreens, input-sensitive pads or surfaces, etc.

[0228] Figure 10 A wearable watch device 1000 according to an embodiment of the present invention is illustrated. In this example, the wearable device 1000 is illustrated as a wristwatch-style device having a face portion 1002 connected to straps 1004A, 1004B. In various embodiments, the electronic device can hold and display the time, essentially functioning as a wristwatch among other functions. The time can be displayed in analog or digital format, depending on the device, its settings, and (in some cases) user preferences. Typically, the time is displayed on a digital display stack that forms part of the exterior of the device.

[0229] The surface portion 1002 may include, for example, a touchscreen display 1006, the size of which may be appropriately determined depending on where the wearable device 1000 is intended to be worn on the user's body. The user can view information presented by the wearable device 1000 on the touchscreen display 1006 and provide input to the wearable device 1000 by touching the touchscreen display 1006. In some embodiments, the touchscreen display 1006 may occupy most or all of the front surface of the surface portion 1002.

[0230] Strips 1004A and 1004B may be provided to allow the wearable device 1000 to be removably worn by a user, for example, around and secured to the user's wrist. In some embodiments, strips 1004A and 1004B may be made of any flexible material (e.g., chains or flexible interwoven plates or connectors made of fabric, flexible plastic, leather, metal, or other rigid materials) and may be connected to the face portion 1002, for example, by hinges. Alternatively, strips 1004A and 1004B may be made of a rigid material, wherein one or more hinges are located at the junction of the face 1002 and the proximal ends 1008A and 1008B of strips 1004A and 1004B and / or elsewhere along the length of strips 1004A and 1004B to allow the user to put on and take off the wearable device 1000. Different portions of strips 1004A and 1004B may be made of different materials; for example, flexible or stretchable portions may alternate with rigid portions. In some embodiments, one or both of strips 1004A and 1004B may include removable sections, thereby allowing the size of the wearable device 1000 to be adjusted to fit the wrist size of a particular user. In some embodiments, strips 1004A and 1004B may be portions extending behind or through a continuous strip member of the face portion 1002. The face portion 1002 may be detachable from, permanently attached to, or integrally formed with, strips 1004A and 1004B.

[0231] The distal ends of the strips 1004A, 1004B opposite to the surface portion 1002 may provide complementary fastening members 1010A, 1010B, which can engage with each other to secure the distal ends of the strips 1004A, 1004B to each other, thereby forming a closed loop. In this way, the device 1000 can be secured to the user's body, for example, around the user's wrist; the fastening members 1010A, 1010B can subsequently disengage to facilitate removal of the device 1000 from the user's body. The design of the fastening members 1010A, 1010B can vary; in various embodiments, the fastening members 1010A, 1010B may include a loop, magnetic fastener, mechanical fastener, snap closure structure, etc. In some embodiments, one or both of the latching members 1010A, 1010B may be movable along at least a portion of the length of the respective strips 1004A, 1004B, thereby allowing the size of the wearable device 1000 to be adjusted to fit the wrist size of a particular user.

[0232] Strips 1004A and 1004B may be two distinct segments, or they may be formed as a continuous strip of elastic material (including, for example, elastic fabric, stretchable metal connectors, or a combination of elastic and inelastic sections), thereby allowing the wearable device 1000 to be put on and taken off by stretching the strips 1004A and 1004B. In such embodiments, fastening members 1010A and 1010B may be omitted.

[0233] The strips 1004A, 1004B and / or the fastening members 1010A, 1010B may include sensors that allow the wearable device 1000 to determine whether it is being worn at any given time. The wearable device 1000 may operate in different ways depending on whether it is currently being worn. For example, the wearable device 1000 may disable various user interfaces and / or RF interface components when it is not being worn. Furthermore, in some embodiments, the wearable device 1000 may notify accompanying devices (e.g., smartphones, mobile devices, tablets, media players, speakers, or other electronic devices) when a user puts on or takes off the wearable device 1000.

[0234] In various embodiments, the wearable device 1000 includes a rotary input component such as a crown 1012 (also referred to as a digital crown in the specification). The crown 1012 can be used to perform a variety of functions. In some embodiments, the crown 1012 provides rotary input for navigating content (e.g., zooming in and out, panning over content). In this example, the crown 1012 comprises a plastic or metal crown body, preferably having conventional external teeth. Typically, a base 1015, integrally formed with the body of the crown, is positioned and protrudes into the face portion 1002. The crown 1012 can be permanently or removably attached to hardware associated with the wearable device 1000. Rotation of the crown (and / or lever) can be sensed optically, electrically, magnetically, or mechanically. Furthermore, in some embodiments, the crown (and / or lever) can also move laterally, thereby providing a second type of input to the device.

[0235] The wearable device 1000 may also include one or more buttons (not shown here). The buttons can be pressed to provide additional input to the device. In various embodiments, the buttons may be spring switches, rocker switches, electrical contacts, magnetic switches, etc. In some embodiments, the buttons may be waterproof or otherwise sealed relative to the environment.

[0236] It should be understood that wearable device 1000 is exemplary, and variations and modifications are possible. For example, wearable device 1000 can be implemented in any wearable article, including watches, bracelets, necklaces, rings, straps, coats, etc. In some cases, wearable device 1000 can be a clip-on or pin-on device with clips or pins attached to the user's clothing. The interface portion (including, for example, a touchscreen display 1006) can be attached to the clip or pin portion via a retractable cord, allowing the user to easily pull the touchscreen display 1006 into the field of view for use without removing the clip or pin portion, and then return the wearable device 1000 to its resting position. Therefore, the user can wear wearable device 1000 in any convenient position.

[0237] The wearable device 1000 can be realized using electronic components disposed within the surface portion 1002, the strips 1004A, 1004B and / or the fastening members 1010A, 1010B.

[0238] Figure 11 This is a simplified block diagram of a device 1100 (e.g., a wearable device 1000 or an accompanying device) according to an embodiment of the present invention. The wearable device 1100 may include a processing subsystem 1102, a storage subsystem 1104, a user interface 1106, an RF interface 1108, a connector interface 1110, a power supply subsystem 1112, an environmental sensor 1114, and a strip sensor 1116. The wearable device 1100 may also include other components (not explicitly shown).

[0239] In several implementations, the electronic device can hold and display the time, essentially functioning as a wristwatch among other features. The time can be displayed in analog or digital format, depending on the device, its settings, and (in some cases) user preferences. Typically, the time is displayed on a digital display overlay that forms part of the device's exterior.

[0240] Storage subsystem 1104 may be implemented, for example, using magnetic storage media, flash memory, other semiconductor memories (e.g., DRAM, SRAM), or any other non-transitory storage media or combinations thereof, and may include volatile and / or non-volatile media. In some embodiments, storage subsystem 1104 may store media items such as audio files, video files, image files, or original image files; information about a user's contacts (name, address, telephone number, etc.); information about a user's scheduled appointments and events; a notepad; and / or other types of information, examples of which are described below. In some embodiments, storage subsystem 1104 may also store one or more applications to be executed by processing subsystem 1102 (e.g., video game programs, personal information management programs, media playback programs, interface programs associated with specific host devices and / or host device functions, etc.).

[0241] The user interface 1106 may include any combination of input and output devices. Users can operate the input devices of the user interface 1106 to invoke the functions of the wearable device 1100, and can view, listen to and / or otherwise experience the output from the wearable device 1100 via the output devices of the user interface 1106.

[0242] Examples of output devices include a display 1120, a speaker 1122, and a haptic output generator 1124. The display 1120 may be implemented using compact display technologies such as LCD (Liquid Crystal Display), LED (Light Emitting Diode), OLED (Organic Light Emitting Diode), etc. In some embodiments, the display 1120 may incorporate flexible display elements or curved glass display elements, thereby allowing the wearable device 1100 to conform to a desired shape. One or more speakers 1122 may be provided using miniature speaker technologies, including any technology capable of converting electronic signals into audible sound waves. In some embodiments, the speaker 1122 may be used to generate tones (e.g., buzzing or ringing) and may, but need not, be able to reproduce sounds such as speech or music with any particular fidelity. The haptic output generator 1124 may, for example, be a device that converts electronic signals into vibrations; in some embodiments, the vibrations may be strong enough to be felt by a user wearing the wearable device 1100 but not strong enough to produce different sounds.

[0243] Wearable device 1100 can also provide alerts to users. Alerts can be generated in response to: changes in device status (an example being low power); the device receiving information (such as receiving a message); communication between the device and another entity / device (such as a second type of device notifying the device that a message is pending or communication is in progress); the operational status of an application (such as as part of a game, or when a calendar appointment is approaching) or operating system (such as when the device is powered on or off); and so on. The number and types of triggers used for alerts are diverse and extensive.

[0244] Warnings can be auditory, visual, tactile, or a combination thereof. A tactile actuator may be housed within the device and linearly movable to generate a tactile output (but in alternative embodiments, the tactile actuator may be rotary or any other type). A speaker provides the auditory component of the warning, and the aforementioned display provides the visual warning component. In some embodiments, a dedicated light, display, or other visual output component may be used as part of the warning.

[0245] The auditory, tactile, and / or visual components of an alert can be synchronized to provide the user with an overall experience. One or more components can be delayed relative to other components to create the desired synchronization between them. Components can be synchronized so that they are perceived substantially simultaneously; for example, a tactile output may be triggered slightly before an auditory output, as tactile output may take longer to perceive compared to audio. Alternatively, a tactile output (or a portion thereof) may be triggered significantly before an auditory output, but to a weak or even imperceptible degree, thereby causing the wearer to primarily receive the auditory output.

[0246] Examples of input devices include microphone 1126, touch sensor 1128, and camera 1129. Microphone 1126 may include any device that converts sound waves into electronic signals. In some embodiments, microphone 1126 may be sensitive enough to provide a representation of a specific word spoken by a user; in other embodiments, microphone 1126 may be used to provide an indication of the overall ambient sound level, rather than necessarily providing a high-quality electronic representation of a specific sound.

[0247] Touch sensor 1128 may include, for example, a capacitive sensor array having the ability to localize a contact to a specific point or area on the surface of the sensor, and in some cases, the ability to distinguish multiple concurrent contacts. In some embodiments, touch sensor 1128 may be overlaid on display 1120 to provide a touchscreen interface, and processing subsystem 1102 may translate touch events (including taps and / or other gestures made using one or more contacts) into specific user input based on the content currently displayed on display 1120. In some embodiments, touch sensor 1128 may also determine the location of a touch on a covering glass. Touch sensors may be incorporated into or on display stacks to determine the location of a touch. Touch sensors may be self-capacitive in some embodiments, mutually capacitive in others, or a combination thereof.

[0248] Display stacks may include overlay elements (such as overlay glass) covering the display. The overlay glass does not necessarily have to be made of glass, although this is an option; it can be made of sapphire, zirconium oxide, alumina, chemically strengthened glass, hardened plastic, etc. Similarly, the display can be a liquid crystal display, an organic light-emitting diode display, or any other suitable display technology. Among other things, display stacks may include a light source in some embodiments.

[0249] Camera 1129 may include, for example, a compact digital camera, comprising an image sensor such as a CMOS sensor and optical components (e.g., a lens) arranged to focus an image onto the image sensor, as well as control logic components for capturing and storing still images and / or video images using the imaging components. Images may be stored, for example, in a storage subsystem 1104, and / or transferred by wearable device 1100 to other devices for storage. Depending on the specific implementation, the optical components may provide a fixed focal length or a variable focal length; in the latter case, autofocus may be provided. In some embodiments, camera 1129 may be along... Figure 10 The edge (e.g., top edge) of the face portion 1002 is positioned and oriented to allow a user to capture images of nearby objects in the environment (such as barcodes or QR codes). In other embodiments, the camera 1129 may be positioned... Figure 10 On the front surface of the face member 1002, for example, to capture images of the user. Depending on the specific implementation, zero or one or more cameras may be provided.

[0250] In some embodiments, the user interface 1106 may provide output to and / or receive input from an assistive device, such as a headset. For example, an audio jack 1130 may be connected to the assistive device via an audio cable (e.g., a standard 2.5mm or 3.5mm audio cable). The audio jack 1130 may include an input path and / or an output path. Therefore, the audio jack 1130 may provide audio to and / or receive audio from the assistive device. In some embodiments, a wireless connectivity interface may be used for communication with the assistive device.

[0251] Processing subsystem 1102 can be implemented as any electronic device capable of processing, receiving, or transmitting data or instructions. Processing subsystem 1102 may include one or more integrated circuits. For example, processing subsystem 1102 may include one or more single-core or multi-core microprocessors or microcontrollers, central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs), or additional combinations of such devices. In operation, processing subsystem 1102 can control the operation of wearable device 1100. In various embodiments, processing subsystem 1102 can execute various 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 may reside in processing subsystem 1102 and / or storage media such as storage subsystem 1104.

[0252] With appropriate programming, the processing subsystem 1102 can provide various functionalities for the wearable device 1100. For example, in some embodiments, the processing subsystem 1102 may execute an operating system (OS) 1132 and various applications for interfacing with a host device, such as a telephone interface application 1134, a text interface application 1136, and / or a media interface application 1138. In some embodiments, some or all of these applications may interact with the host device, for example, by generating messages to be sent to the host device and / or by receiving and interpreting messages from the host device. In some embodiments, some or all of the applications may operate locally on the wearable device 1100. For example, if the wearable device 1100 has a local media library stored in the storage subsystem 1104, the media interface application 1138 may provide a user interface for selecting and playing locally stored media items. Examples of interface applications are described below.

[0253] In some implementations, the processing subsystem 1102 may also execute a host security process 1160, which supports the establishment and maintenance of a verified communication session with the host device. A verified communication session provides an enhanced level of security, and various operations of the wearable device 1100 and / or the host device may be performed depending on whether a verified communication session between the devices is in progress. For example, the host security process 1160 may facilitate unlocking the host device when the wearable device 1100 is present, depending on whether a verified session is in progress. User data 1162 may include any user-specific information, such as identification information, user-specified settings and preferences, custom information (e.g., contacts, scheduled text messages), and any other user-related data or content. In some implementations, running applications and processes may access user data 1162 to facilitate operation.

[0254] The RF (radio frequency) interface 1108 allows the wearable device 1100 to communicate wirelessly with various host devices. The RF interface 1108 may include RF transceiver components (such as an antenna and supporting circuitry) to enable data communication via a wireless medium, such as using WiFi (IEEE 802.11 series standards). (A series of standards published by Bluetooth SIG) or other protocols for wireless data communication. The RF interface 1108 can be implemented using a combination of hardware components (e.g., driver circuitry, antenna, modulator / demodulator, encoder / decoder, and other analog and / or digital signal processing circuitry) and software components. In some implementations, the RF interface 1108 can provide near-field communication (“NFC”) capabilities, such as implementing the ISO / IEC 18092 standard; NFC enables wireless data exchange between devices over very short ranges (e.g., 20 cm or less). Several different wireless communication protocols and associated hardware can be combined into the RF interface 1108. The wearable device 1100 can communicate wirelessly with nearby point-of-sale terminals, thus allowing users to quickly and efficiently conduct transactions such as selling, buying, or returning goods. The wearable device 1100 can use NFC technology to perform these and other functions.

[0255] Connector interface 1110 allows wearable device 1100 to communicate with various host devices via a wired communication path, such as using Universal Serial Bus (USB), Universal Asynchronous Receiver / Transmitter (UART), or other protocols for wired data communication. In some embodiments, connector interface 1110 may provide a power port, allowing wearable device 1100 to receive power, for example, to charge an internal battery. For example, connector interface 1110 may include connectors such as micro USB connectors or custom connectors, as well as supporting circuitry. In some embodiments, the connector may be a custom connector that provides dedicated power and ground contacts and digital data contacts that can be used to implement different communication technologies in parallel; for example, two pins may be assigned as USB data pins (D+ and D-), and other two pins may be assigned as serial transmit / receive pins (e.g., implementing a UART interface). Pin assignments for specific communication technologies may be hardwired or negotiated as the connection is being established. In some embodiments, the connector may also provide connectivity for audio and / or video signals that may be transmitted to or from a host device in analog and / or digital formats.

[0256] In some implementations, connector interface 1110 and / or RF interface 1108 may be used to support synchronization operations in which data is transferred from a host device to wearable device 1100 (or vice versa). For example, as described below, a user may customize certain information for wearable device 1100 (e.g., a "favorites" list of contacts and / or specific predefined text messages that can be sent). Although user interface 1106 may support data input operations, users may find it more convenient to define custom information on a separate device (e.g., a tablet or smartphone) with a larger interface (e.g., including a physical or virtual alphanumeric keypad) and then transfer the custom information to wearable device 1100 via synchronization operations. Synchronization operations may also be used to load and / or update other types of data in storage subsystem 1104, such as media items, applications, and / or operating system programs. Synchronization operations may be performed in response to explicit user requests and / or automatically, such as when wireless device 1100 resumes communication with a particular host device or in response to either device receiving an update to its copy of synchronization information.

[0257] Environmental sensor 1114 may include various electronic, mechanical, electromechanical, optical, or other devices that provide information relating to external conditions surrounding wearable device 1100. In some embodiments, sensor 1114 may provide digital signals to processing subsystem 1102, for example, as needed, either in a streaming manner or in response to polling by processing subsystem 1102. Any type and combination of environmental sensors may be used; accelerometer 1142, magnetometer 1144, gyroscope 1146, and GPS receiver 1148 are shown by way of example.

[0258] Some environmental sensors can provide information about the position and / or motion of the wearable device 1100. For example, an accelerometer 1142 can sense acceleration (relative to free fall) along one or more axes, for example, by using piezoelectric components or other components in combination with associated electronics to generate a signal. A magnetometer 1144 can sense the surrounding magnetic field (e.g., the Earth's magnetic field) and generate a corresponding electrical signal that can be interpreted as compass orientation. A gyroscope sensor 1146 can, for example, use one or more MEMS (microelectromechanical systems) gyroscopes along with associated control and sensing circuitry to sense rotational motion in one or more directions. A Global Positioning System (GPS) receiver 1148 can determine the position based on signals received from GPS satellites.

[0259] In addition to or instead of these examples, other sensors may be included. For example, a sound sensor may be combined with microphone 1126 along with associated circuitry and / or program code to determine, for example, the decibel level of ambient sound. Temperature sensors, proximity sensors, ambient light sensors, etc., may also be included. An ambient light sensor allows the device to sense the brightness of its environment and adjust specific operating parameters accordingly. For example, wearable device 1100 may change the brightness of its display in response to sensed ambient light. Alternatively, wearable device 1100 may turn off its display when there is no or almost no light sensed for a prolonged period of time.

[0260] Sensor 1116 may include various electronic, mechanical, electromechanical, optical, or other devices that provide information to wearable device 1100. For example, buckle sensor 1150 may be at least partially located in... Figure 10 The latching sensor 1150 is configured to detect when it engages or disengages from the latching members 1010A and 1010B. For example, engaging the latching members 1010A and 1010B completes a circuit, allowing current to flow through the latching sensor 1150; disengaging the latching members 1010A and 1010B disconnects the circuit. Alternatively, one or more crown sensors 1152 may be configured to detect current from the latching members 1010A and 1010B. Figure 10The input of the crown 1012. The crown sensor 1152 may also include a motion sensor, an accelerometer, a pressure sensor (e.g., a piezoelectric device), etc.

[0261] In addition to or in place of the strip sensor 1116 and the crown sensor 1152, any other type of sensor may be used. For example, physiological or biological sensors, such as pulse sensors, ECG sensors, etc., may be provided. In some embodiments, the physiological sensor may monitor the user's physiological signals and provide health-related information based on those signals. In some embodiments, the physiological or biological sensor may be used to verify the identity of the wearer of the wearable device 1100.

[0262] Some implementations may incorporate one or more biosensors to measure specific physiological characteristics of a user. The device may, for example, include a photoplethysmometer to determine a user's heart rate or blood oxygen levels. The device may additionally or alternatively include electrodes for measuring the user's body impedance, which allows the device to estimate body fat percentage, body electrical activity, body impedance, and so on. In some implementations, the device may also measure blood pressure, ultraviolet radiation, etc. Depending on the sensors incorporated into or associated with the electronic device, a variety of user characteristics can be measured and / or estimated, thereby allowing different health information to be provided to the user. In some examples, the sensed biometric information may be used by an alert manager, in part, for managing electronic content and / or access alerts.

[0263] Similarly, wearable device 1100 may include a force sensor (not shown here) to determine the amount of force applied to the covering glass. In some embodiments, the force sensor may be a capacitive sensor, and in others, a strain sensor. In either embodiment, the force sensor is generally transparent and made of a transparent material, or located below or away from the display so as not to obstruct viewing. The force sensor may, for example, take the form of two capacitive plates separated by silicone or another deformable material. As the capacitive plates move closer together under the action of an external force, a change in capacitance can be measured, and the value of the external force is correlated with the change in capacitance. Additionally, the location where the force is applied can be determined by comparing relative capacitance changes from multiple points on the force sensor or from multiple force sensors. In one embodiment, the force sensor may take the form of a gasket extending below the periphery of the display. The gasket may be segmented or integral, depending on the embodiment.

[0264] The power subsystem 1112 provides power and power management capabilities to the wearable device 1100. For example, the power subsystem 1112 may include a battery 1140 (e.g., a rechargeable battery) and associated circuitry for distributing power from the battery 1140 to other components of the wearable device 1100 that require power. In some embodiments, the power subsystem 1112 may also include circuitry for charging the battery 1140, for example, when the connector interface 1110 is connected to a power source. In some embodiments, the power subsystem 1112 may include a “wireless” charger, such as an inductive charger, for charging the battery 1140 without relying on the connector interface 1110. An inductive charging base can transfer power to an inductive receiver within the device to charge the device's battery. Additionally, data can be communicated between the device and the base by altering the inductive field between them. As a simple, non-limiting example, this could be used to wake the base from a low-power sleep state to an active charging state when the device is placed on it. Other wireless charging systems (e.g., near-field magnetic resonance and radio frequency) may also be used. Alternatively, the device may also employ wired charging via electrodes. In some embodiments, in addition to or in place of battery 1140, the power subsystem 1112 may also include other power sources, such as solar cells.

[0265] In some embodiments, the power subsystem 1112 can control the power distribution to components within the wearable device 1100 to effectively manage power consumption. For example, the power subsystem 1112 can automatically put the device 1100 into a "sleep" state when the strip sensor 1116 indicates that the device 1100 is not being worn. The sleep state can be designed to reduce power consumption; therefore, the user interface 1106 (or components thereof), RF interface 1108, connector interface 1110, and / or environmental sensor 1114 can be powered down (e.g., enter a low-power state or be completely turned off), while the strip sensor 1116 is powered on (continuously or intermittently) to detect when the user puts on the wearable device 1100. As another example, in some embodiments, while the wearable device 1100 is being worn, the power subsystem 1112 can turn the display 1120 and / or other components on or off based on the movement and / or orientation of the wearable device 1100 detected by the environmental sensor 1114. For example, if the wearable device 1100 is designed to be worn on a user's wrist, the power subsystem 1112 can detect the lifting and rotation of the user's wrist based on information provided by the accelerometer 1142, as typically associated with viewing a wristwatch. In response to this detected movement, the power subsystem 1112 can automatically turn on the display 1120 and / or the touch sensor 1128; similarly, the power subsystem 1112 can automatically turn off the display 1120 and / or the touch sensor 1128 in response to detecting that the user's wrist has returned to a neutral position (e.g., lowered).

[0266] The power subsystem 1112 may also provide other power management capabilities, such as adjusting the power consumption of other components of the wearable device 1100 based on the source and amount of available power, monitoring the power stored in the battery 1140, generating user alerts when the stored power drops below a minimum level, and so on.

[0267] In some implementations, the control functions of the power subsystem 1112 may be implemented using programmable or controllable circuitry that operates in response to control signals, or as a stand-alone microprocessor or microcontroller generated by the processing subsystem 1102 in response to program code executed thereon.

[0268] It should be understood that wearable device 1100 is exemplary, and variations and modifications are possible.

[0269] Various implementations can also be implemented in a wide range of operating environments, and in some cases may include one or more user computers, computing devices, or processing devices that can be used to operate any of the multiple applications in the application. Users of client devices may include any of a variety of general-purpose personal computers, such as desktop or laptop computers running standard operating systems, and cellular, wireless, and handheld devices running mobile software and supporting multiple networking and messaging protocols. Such systems may also include multiple workstations running a variety of commercially available operating systems and other applications known for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0270] Most implementations utilize at least one network familiar to those skilled in the art to support communication using a variety of commercially available protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, the public switched telephone network (PSTN), an infrared network, a wireless network, or any combination thereof.

[0271] In implementations utilizing a web server, the web server may run any of multiple server or middleware applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server may also be able to execute programs or scripts in response to requests from user devices, such as by executing one or more applications that can be implemented as one or more scripts or programs written in any programming language or any scripting language and combinations thereof. The server can be configured with C, C#, or C++, and scripting languages ​​such as Perl, Python, or TCL. The server may also include a database server, and is not limited to those that can access databases from... and Those obtained through commercial purchases.

[0272] Such programs can also be encoded and transmitted using carrier signals adapted for transmission over wired networks conforming to various protocols. Similarly, computer-readable media according to embodiments of the invention can be created using data signals encoded by such programs. Computer-readable media encoded with program code can be encapsulated in a compatible device or independent of other devices (e.g., downloaded via the Internet). Any such computer-readable medium can be present or located within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can be present or located within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0273] The environment may include various data repositories and other storage media, as described above. These may reside in multiple locations, such as locally (and / or permanently) on one or more of the computers or on storage media remotely on a network from any or all of the computers. In a particular set of embodiments, information may reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally and / or remotely, as appropriate. If the system includes computerized devices, each such device may include hardware elements electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., display device, printer, or speaker). Such systems may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as RAM or ROM, as well as removable media devices, memory cards, flash memory cards, and the like.

[0274] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices, etc.), and working memory, as described above. Computer-readable storage medium readers may be connected to or configured to receive non-transitory computer-readable storage media, representing remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more persistently containing, storing, transmitting, and retrieving computer-readable information. Systems and various devices will also typically include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or browsers. It should be understood that alternative embodiments may have several variations as described above. For example, custom hardware may also be used and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. Additionally, connections to other computing devices, such as network input / output devices, may be employed.

[0275] Non-transitory storage media and computer-readable storage media containing code or code portions may include any suitable media known or used in the art, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any way or technology for storing information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, DVD or other optical storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by system devices. Based on the disclosure and teachings provided herein, those skilled in the art will realize other ways and / or methods to implement the various embodiments. However, computer-readable storage media do not include transient media such as carrier waves.

[0276] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will be apparent that various modifications and alterations can be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

[0277] Other variations are within the scope of this disclosure. Therefore, while the disclosed technology allows for various modifications and alterations in construction, certain exemplary embodiments are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative structures, and equivalents falling within the scope and spirit of this disclosure as defined by the appended claims.

[0278] In the context of describing the disclosed embodiments (especially in the context of the following claims), the terms “a,” “an,” and “the,” and similar designations, shall be understood to cover both the singular and the plural, unless otherwise specified herein or the context clearly contradicts this. The terms “comprising,” “having,” and “including” shall be understood as open-ended terms (i.e., meaning “including but not limited to”), unless otherwise specified. The term “connected” shall be understood as partially or wholly contained, attached to, or joined together, even if something is in between. The phrase “based on” shall be understood as open-ended and not limiting in any way, and is intended to be interpreted or otherwise understood as “at least partially based on” where appropriate. The expressions of numerical ranges herein are intended only as a method of abbreviating each individual value falling within the range, unless otherwise specified herein, and each individual value is incorporated into the specification as if it were recited individually herein. All methods described herein may be performed in any suitable order, unless otherwise specified herein or the context clearly contradicts this. The use of any and all examples or exemplary language (such as "such as") provided herein is merely intended to better illustrate embodiments of this disclosure and does not constitute a limitation on the scope of this disclosure unless otherwise stated. No language in the specification should be construed as indicating that any unclaimed element is necessary for the implementation of this disclosure.

[0279] Disjunctive languages ​​such as the phrase "at least one of X, Y, or Z" are generally understood in the context to mean that a term, word, etc., can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive languages ​​are generally not intended and should not imply that a particular embodiment requires at least one X, at least one Y, or at least one Z, up to and including the presence of each. Additionally, connective languages ​​such as the phrase "at least one of X, Y, and Z" are also understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z," unless otherwise specified.

[0280] Preferred embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out this disclosure. Variations of those preferred embodiments will become apparent to those skilled in the art upon reading the above description. The inventors intend that those skilled in the art will employ such variations as appropriate, and the inventors intend that this disclosure can be implemented in ways other than those specifically described herein. Therefore, this disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by patent law. Furthermore, any combination of the foregoing elements in all possible variations is covered by this disclosure unless otherwise specified herein or the context clearly contradicts it.

[0281] All references mentioned in this article, including publications, patent applications and patents, are hereby incorporated by reference as if each reference were individually and specifically indicated to be incorporated by reference and as recorded in its full text herein.

Claims

1. A method for displaying data on a wearable device, the method comprising, at the wearable device: providing a user interface for a user to configure data to be displayed in one or more style windows in conjunction with time on a display of the wearable device, wherein the one or more style windows correspond to a portion of the display; receiving a first window selection of a first style window of the display of the wearable device, the first style window being associated with a first plurality of templates for displaying the data, wherein each template specifies for displaying data in a different manner; identifying a first list of applications designated to support the first style window, the first list of applications being determined from data provided by device applications; providing the first list of applications to the user; receiving a selection of a first application from the first list of applications to display in the first style window; in response to the first application being assigned to the first style window, receiving a first data object from the first application, the first data object specifying a first template of the first plurality of templates and one or more first data items for displaying according to the first template; retrieving the first template; and displaying the one or more first data items in the first style window on the display of the wearable device according to the first template.

2. The method of claim 1, further comprising, in response to receiving the selection of the first application, notifying the first application that the first application is assigned to the first style window.

3. The method of claim 1, further comprising, at the wearable device: receiving one or more removal commands from the user to remove one or more applications from the first list of applications; removing the one or more applications from the first list of applications to obtain a modified first list of applications; and providing the modified first list of applications to the user upon a subsequent selection of the first style window.

4. The method of claim 1, further comprising, at the wearable device: sending a refresh preference to a companion device for obtaining new data for the first style window; receiving new data from the companion device; and generating the first data object using the new data.

5. The method of claim 1, further comprising, at the wearable device: receiving a refresh preference from a companion device for the companion device to provide new data for the first style window, the new data to be used to generate the first data object; monitoring a status of the wearable device and a number of updates of the first application; and determining when to request the new data from the companion device based on the status of the wearable device and the number of updates.

6. The method of claim 1, wherein the first data object comprises one or more pieces of data, wherein the one or more pieces of data comprise one or more data types selected from a group comprising text, image, and number. ​ ​ ​ 7. The method of claim 1, wherein the first template comprises an image whose display is dependent on a number provided in the first data object.

8. The method of claim 1, wherein the first data object is received by a display manager, the method further comprising, at the wearable device: notifying, by the display manager, a function bar controller of the first application program that the first application program is assigned to the first style window.

9. The method of claim 1, further comprising, at the wearable device: receiving a second window selection of a second style window for a display of the wearable device, the second style window associated with a second plurality of templates; identifying a second list of application programs designated as supporting the second style window; providing the second list of application programs to the user; receiving a second application program selection of a second application program from the second list of application programs; receiving a second data object from the second application program, the second data object designating a second template of the second plurality of templates and comprising one or more second data items for display according to the second template; retrieving the second template; and displaying the one or more second data items in the second style window on the display of the wearable device according to the second template.

10. A method of providing information to a wearable device by a companion device, the method comprising, at the companion device: receiving, from the wearable device, a list of application programs assigned to a display window on a display currently being used by the wearable device, the list of application programs comprising a first application program; receiving, from the first application program on the companion device, a request to send new function bar data to the wearable device; accessing the list of application programs to determine that the first application program is assigned to a function bar on a display currently being used by the wearable device; and in response to the first application program being assigned to the function bar, sending the new function bar data to a transport daemon for transport to the wearable device.

11. The method of claim 10, further comprising, at the companion device: receiving a trigger to fetch new data; and fetching the new function bar data from a server.

12. The method of claim 11, wherein the trigger is generated by the companion device, and wherein the new function bar data is retrieved from the server in response to the trigger.

13. The method of claim 12, further comprising, at the companion device: receiving a refresh preference from the wearable device, wherein the trigger is generated based on the refresh preference.

14. The method of claim 10, further comprising, at the companion device: determining, by the transport daemon, whether to transport the new function bar data to the wearable device or to queue the new function bar data for a subsequent transport.

15. The method of claim 14, wherein the determination is based on an assigned budget for transmissions of the first application program to the wearable device. ​ ​ 16. A wearable device comprising: one or more processors configured to perform the method of any of claims 1-15.

17. A non-transitory computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a mobile device, cause the one or more processors to perform the method of any of claims 1-15.

18. A method for configuring a user interface to display data on a wearable device, the method comprising, at a companion device: providing a user interface for a user to configure data displayed in one or more style windows on a display of the wearable device in conjunction with time, wherein the one or more style windows correspond to a portion of the display; receiving a first window selection of a first style window of the display of the wearable device, the first style window being associated with a first plurality of templates for displaying the data; identifying a first list of applications designated as supporting the first style window, the first list of applications being determined from data provided by companion applications; providing the first list of applications to the user; receiving a selection of a first application from the first list of applications to display in the first style window; in response to the first application being assigned to the first style window, receiving a first data object from the first application, the first data object specifying a first template of the first plurality of templates and one or more first data items for display according to the first template; retrieving the first template; and transmitting the first template to the wearable device for displaying the one or more first data items.

19. The method of claim 18, further comprising: receiving one or more removal commands from the user to remove one or more applications from the first list of applications; removing the one or more applications from the first list of applications to obtain a modified first list of applications; and providing the modified first list of applications to the user upon a subsequent selection of the first style window.

20. The method of claim 18, further comprising: sending a refresh preference to the wearable device for obtaining new data for the first style window; receiving new data for the wearable device; and generating the first data object using the new data.

21. The method of claim 18, further comprising, at the companion device: transmitting a refresh preference from the companion device for the companion device to provide new data for the first style window, the new data to be used to generate the first data object; and receiving a request from the companion device for the new data based on a status of the wearable device and an update quantity.

22. The method of claim 18, wherein the first data object comprises one or more pieces of data, wherein the one or more pieces of data comprise one or more data types selected from a group comprising text, images, and numbers. ​ ​ ​ 23. The method of claim 18, wherein the first template comprises an image whose display is dependent on a number provided in the first data object.

24. The method of claim 18, further comprising, at the companion device: receiving a second window selection of a second style window for a display of the wearable device, the second style window being associated with a second plurality of templates; identifying a second list of application programs designated as supporting the second style window; providing the second list of application programs to the user; receiving a second application program selection of a second application program from the second list of application programs; receiving a second data object from the second application program, the second data object designating a second template of the second plurality of templates and comprising one or more second data items for display according to the second template; retrieving the second template; and displaying the one or more second data items in the second style window on the display of the wearable device according to the second template.

25. A wearable device comprising: one or more processors configured to perform the method of any of claims 18-24.

26. A non-transitory computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a mobile device, cause the one or more processors to perform the method of any of claims 18-24. ​

Images