An authenticated device used to unlock another device

Abstract

To provide more efficient, user-friendly procedures for unlocking devices, input mechanisms, and / or applications.SOLUTION: An electronic device unlocking procedure is provided, comprising: detecting an external device via wireless communication; receiving unlocking information for unlocking an electronic device from the external device; determining whether the external device is authorized to facilitate unlocking of the electronic device; detecting a user input; unlocking the electronic device in response to the user input, received unlocking information, and / or determination that the external device is authorized; and entering a normal operating state to launch and use application programs.SELECTED DRAWING: Figure 12

Description

[Background technology]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 038,077, entitled "Authenticated Device Used to Unlock Another Device," filed August 15, 2014, and U.S. Provisional Patent Application No. 62 / 129,747, entitled "Authenticated Device Used to Unlock Another Device," filed March 6, 2015, the contents of which are incorporated herein by reference in their entireties.

[0002] This application is related to U.S. Patent Application No. 62 / 035,348, entitled "CONTINUITY," filed August 8, 2014, and U.S. Patent Application No. 62 / 006,043, entitled "CONTINUITY," filed May 30, 2014, the contents of which are incorporated herein by reference in their entireties.

[0003] 1.Technical Field The present disclosure relates generally to computer user interfaces, and more particularly to techniques that allow a user to seamlessly transition from using one device to using another. 2. Description of Related Technology

[0004] Modern electronic devices may have multiple input mechanisms, such as a touchscreen, touchpad, and / or buttons. One problem associated with using these input mechanisms is the unintentional activation or deactivation of functions due to unintentional contact. To address this problem, some devices lock when a predefined lock condition is met, such as after a predetermined idle time has elapsed or manual locking by a user. When locked, the device remains operational but ignores most, if not all, user input to reduce the likelihood of unintentional operation. That is, the device, its input mechanisms, and / or applications running on it may ignore certain classes of input when locked.

[0005] One class of inputs to which a locked device will still respond is attempts to unlock the device. These inputs may include known unlocking procedures, such as pressing a predetermined set of buttons (simultaneously or in sequence) or entering a code or password. However, these unlocking procedures have drawbacks. Button combinations can be difficult to perform. Creating, memorizing, and recalling passwords, codes, etc. can be tedious. These drawbacks are exacerbated when a user switches between using multiple devices that require unlocking, especially if the devices are configured to auto-lock after some idle period.

[0006] There is a need for a more efficient and user-friendly procedure for unlocking such devices, input mechanisms, and / or applications. Summary of the Invention

[0007] In some embodiments, a method for unlocking an electronic device using an authenticated external device includes, in an electronic device having a user interface locked state and a user interface unlocked state, detecting, via wireless communication, the external device; receiving unlock information from the external device for unlocking the electronic device; detecting user input while in the locked state; and unlocking the electronic device in response to detecting the user input and the received unlock information.

[0008] In some embodiments, a method for unlocking an external device using an (authenticated) electronic device includes, in the electronic device having a user interface locked state and a user interface unlocked state and being in the user interface unlocked state, detecting via wireless communication an external device having a user interface locked state and a user interface unlocked state and being in the user interface locked state, and transmitting unlock data to the external device, wherein the external device unlocks after receiving the unlock information and detecting the user input.

[0009] In some embodiments, a method for configuring an electronic device to recognize that an external device is an authorized external device that can be used to facilitate (automatic) unlocking of the electronic device includes, at an electronic device having a user interface locked state and a user interface unlocked state and within wireless communication range of the external device, receiving user input at the electronic device while in the user interface locked state representing a credential for unlocking the electronic device, unlocking the electronic device in response to determining that the credential is valid, displaying an identification of the external device on a screen of the electronic device after unlocking, and prompting a user to specify whether the external device is permitted to unlock the electronic device when the external device comes within wireless communication range of the electronic device while the electronic device is in the user interface locked state. [Brief explanation of the drawings]

[0010] For a better understanding of the various described embodiments, please refer to the following detailed description in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout the drawings, in which:

[0011] [Figure 1A] FIG. 1 is a block diagram illustrating a portable multifunction device with a touch-sensitive display in accordance with some embodiments.

[0012] [Figure 1B] FIG. 2 is a block diagram illustrating exemplary components for event processing according to some embodiments.

[0013] [Figure 2] FIG. 1 illustrates a portable multifunction device having a touch-sensitive display in accordance with some embodiments.

[0014] [Figure 3]FIG. 1 is a block diagram of an exemplary multifunction device having a display and a touch-sensitive surface in accordance with some embodiments.

[0015] [Figure 4A] 1A-1C illustrate exemplary user interfaces for application menus on a portable multifunction device in accordance with some embodiments.

[0016] [Figure 4B] 1A-1C illustrate exemplary user interfaces for multifunction devices having a touch-sensitive surface separate from a display in accordance with some embodiments.

[0017] [Figure 5A] FIG. 1 illustrates a personal electronic device according to some embodiments.

[0018] [Figure 5B] FIG. 1 is a block diagram illustrating a personal electronic device according to some embodiments.

[0019] [Figure 6A] FIG. 1 illustrates an exemplary device for implementing an automatic unlocking technique.

[0020] [Figure 6B] FIG. 1 illustrates an exemplary device for implementing an automatic unlocking technique.

[0021] [Figure 6C] FIG. 1 illustrates an exemplary device for implementing an automatic unlocking technique.

[0022] [Figure 6D] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0023] [Figure 6E]FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0024] [Figure 6F] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0025] [Figure 7A] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0026] [Figure 7B] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0027] [Figure 7C] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0028] [Figure 7D] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0029] [Figure 7E] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0030] [Figure 7F] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0031] [Figure 8A] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0032] [Figure 8B] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0033] [Figure 8C] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0034] [Figure 9A] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0035] [Figure 9B] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0036] [Figure 10A] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0037] [Figure 10B] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0038] [Figure 10C] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0039] [Figure 10D] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0040] [Figure 11A] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0041] [Figure 11B] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0042] [Figure 11C] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0043] [Figure 11D] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0044] [Figure 11E] FIG. 1 illustrates exemplary user interface(s) for unlocking an electronic device.

[0045] [Figure 12] FIG. 1 is a flow diagram illustrating a process for unlocking an electronic device.

[0046] [Figure 13] FIG. 1 is a flow diagram illustrating a process for unlocking an electronic device.

[0047] [Figure 14] FIG. 1 is a flow diagram illustrating a process for unlocking an electronic device.

[0048] [Figure 15] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments.

[0049] [Figure 16] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments.

[0050] [Figure 17] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments.

[0051] [Figure 18] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0052] The following description sets forth example methods, parameters, etc. However, it should be recognized that such description is not intended as a limitation on the scope of the present disclosure, but is provided as a description of example embodiments.

[0053] It is desirable for a device that is trusted by other electronic devices (e.g., an "authenticated" device) to be able to easily unlock certain other electronic devices. Consider a situation in which a user owns multiple electronic devices and frequently switches between their use. It would be useful for unlocking one electronic device (e.g., by providing a password) to also automatically unlock nearby devices (within wireless communication range), or at least require only a reduced set of user inputs for unlocking. In this way, a user can quickly transition between different devices without having to enter the corresponding password for each device. Techniques that perform these functions of using an authenticated device to unlock other electronic devices are sometimes referred to as automatic unlocking techniques.

[0054] 1A-1B, 2, 3, 4A-4B, and 5A-5B provide descriptions of exemplary devices that can implement the automatic unlocking techniques. Additionally, FIGS. 6-11 illustrate exemplary user interfaces involved in automatically unlocking a device. The user interfaces in the figures are also used to explain the automatic unlocking process described below, including the process in FIGS. 12-14.

[0055] In the following description, terms such as "first" and "second" are used to describe various elements, but these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first touch can be referred to as a second touch, and similarly, a second touch can be referred to as a first touch, without departing from the scope of the various embodiments described. A first touch and a second touch are both touches, but are not the same touch.

[0056] The terminology used in the description of the various embodiments set forth herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the various described embodiments and in the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, it should also be understood that the term "and / or" refers to and includes any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0057] The term "if" can be interpreted to mean "when," "upon," "in response to determining," or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if [a stated condition or event] is detected" can be interpreted to mean "upon determining," or "in response to determining," or "upon detecting [the stated condition or event]," or "in response to detecting [the stated condition or event]," depending on the context.

[0058] Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described. In some embodiments, the device is a portable communication device, such as a mobile telephone, that also includes other functions, such as PDA functionality and / or music playback functionality. Exemplary embodiments of portable multifunction devices include, but are not limited to, the iPhone®, iPod Touch®, and iPad® devices by Apple Inc. (Cupertino, California). Other portable electronic devices, such as laptops or tablet computers with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads), are also optionally used. It should also be understood that in some embodiments, the device is not a portable communication device, but rather a desktop computer with a touch-sensitive surface (e.g., touchscreen displays and / or touchpads).

[0059] In the following discussion, we describe an electronic device with a display and a touch-sensitive surface, but it should be understood that the electronic device optionally includes one or more other physical user interface devices, such as a physical keyboard, a mouse, and / or a joystick.

[0060] The device may support a variety of applications, such as one or more of a drawing application, a presentation application, a word processing application, a website creation application, a disc authoring application, a spreadsheet application, a gaming application, a telephone application, a video conferencing application, an email application, an instant messaging application, a training support application, a photo management application, a digital camera application, a digital video camera application, a web browsing application, a digital music playback application, and / or a digital video playback application.

[0061] Various applications running on the device optionally use at least one common physical user interface device, such as a touch-sensitive surface. One or more features of the touch-sensitive surface and corresponding information displayed on the device are optionally adjusted and / or changed for each application and / or within the corresponding application. In this way, the common physical architecture (such as the touch-sensitive surface) of the device optionally supports various applications with user interfaces that are intuitive and transparent to the user.

[0062] Attention is now directed to embodiments of portable devices with touch-sensitive displays. FIG. 1A is a block diagram illustrating portable multifunction device 100 with touch-sensitive display system 112, according to some embodiments. Touch-sensitive display 112 may conveniently be referred to as a "touch screen" and may also be known or referred to as a touch-sensitive display system. Device 100 includes memory 102 (optionally including one or more computer-readable storage media), memory controller 122, one or more processing units (CPUs) 120, peripherals interface 118, RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, input / output (I / O) subsystem 106, other input control devices 116, and external port 124. Device 100 optionally includes one or more optical sensors 164. Device 100 optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on device 100 (e.g., a touch-sensitive surface, such as touch-sensitive display system 112 of device 100). Device 100 optionally includes one or more tactile output generators 167 for generating tactile output on device 100 (e.g., generating tactile output on a touch-sensitive surface, such as touch-sensitive display system 112 of device 100 or touchpad 355 of device 300). These components optionally communicate via one or more communication buses or signal lines 103.

[0063] As used in this specification and claims, the term “intensity” of a contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of a contact (e.g., a finger contact) on the touch-sensitive surface, or a surrogate (proxy) for the force or pressure of a contact on the touch-sensitive surface. The intensity of a contact has a range of values that includes at least four distinct values and more typically includes hundreds of different values (e.g., at least 256). The intensity of a contact is optionally determined (or measured) using various methods and various sensors or combinations of sensors. For example, one or more force sensors positioned beneath or adjacent to the touch-sensitive surface are optionally used to measure force at various points on the touch-sensitive surface. In some implementations, the force measurements of multiple force sensors are combined (e.g., weighted average) to determine an estimate of the contact force. Similarly, a pressure-sensitive tip of a stylus is optionally used to determine the pressure of the stylus on the touch-sensitive surface. Alternatively, the size and / or change in the contact area detected on the touch-sensitive surface, the capacitance and / or change in the capacitance of the touch-sensitive surface proximate the contact, and / or the resistance and / or change in the capacitance of the touch-sensitive surface proximate the contact are optionally used as surrogates for the force or pressure of the contact on the touch-sensitive surface. In some implementations, the surrogate measure of the force or pressure of the contact is used directly to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is stated in units corresponding to the surrogate measure). In some implementations, the surrogate measure of the force or pressure of the contact is converted to an estimated force or pressure, and this estimated force or pressure is used to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is a pressure threshold measured in units of pressure). Using the intensity of contact as an attribute of user input allows a user access to additional device functionality that may otherwise be inaccessible to the user on reduced-size devices with limited area for displaying affordances (e.g., on a touch-sensitive display) and / or receiving user input (e.g., via a touch-sensitive display, touch-sensitive surface, or physical / mechanical controls such as knobs or buttons).

[0064] As used herein and in the claims, the term “tactile output” refers to a physical displacement of a device relative to its previous position, a physical displacement of a component of the device (e.g., a touch-sensitive surface) relative to another component (e.g., a housing), or a displacement of a component relative to the center of mass of the device, that will be detected by a user with the user's sense of touch. For example, in a situation where a device or a component of the device is in contact with a touch-sensitive surface of a user (e.g., the fingers, palm, or other part of the user's hand), the tactile output produced by the physical displacement will be interpreted by the user as a tactile sensation corresponding to a perceived change in a physical property of the device or a component of the device. For example, movement of the touch-sensitive surface (e.g., a touch-sensitive display or trackpad) is optionally interpreted by the user as a “downclick” or “upclick” of a physical actuator button. In some cases, a user will feel a tactile sensation such as a “downclick” or “upclick” even when there is no movement of a physical actuator button associated with the touch-sensitive surface that has been physically pressed (e.g., displaced) by the user's action. As another example, movement of the touch-sensitive surface is optionally interpreted or perceived by a user as "roughness" of the touch-sensitive surface, even when there is no change in the smoothness of the touch-sensitive surface. Such interpretation of touch by a user depends on the user's individual sensory perception, but there are many sensory perceptions of touch that are common to a majority of users. Thus, when a tactile output is described as corresponding to a particular sensory perception of a user (e.g., an "upclick," "downclick," "roughness"), unless otherwise specified, the generated tactile output corresponds to a physical displacement of the device, or a component thereof, that produces the described sensory perception for a typical (or average) user.

[0065] It should be understood that device 100 is only one example of a portable multifunction device, and that device 100 optionally has more or fewer components than those shown, optionally combines two or more components, or optionally has a different configuration or arrangement of components. The various components shown in Figure 1A are implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application specific integrated circuits.

[0066] Memory 102 may include one or more computer-readable storage media. The computer-readable storage media may be tangible and non-transitory. Memory 102 may include high-speed random-access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. Memory controller 122 may control access to memory 102 by other components of device 100.

[0067] A peripheral interface 118 can be used to couple input and output peripherals of the device to the CPU 120 and memory 102. The one or more processors 120 operate or execute various software programs and / or instruction sets stored in memory 102 to perform various functions for device 100 and to process data. In some embodiments, the peripheral interface 118, CPU 120, and memory controller 122 may be implemented on a single chip, such as chip 104. In some other embodiments, they may be implemented on separate chips.

[0068] The RF (radio frequency) circuitry 108 transmits and receives RF signals, also called electromagnetic signals. The RF circuitry 108 converts electrical signals to electromagnetic signals or electromagnetic signals to electrical signals and communicates with communication networks and other communication devices via electromagnetic signals. The RF circuitry 108 optionally includes well-known circuitry for performing these functions, including, but not limited to, an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, etc. The RF circuitry 108 optionally communicates via wireless communication with the Internet, also called the World Wide Web (WWW), an intranet, and / or wireless networks, such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs), and other devices. The RF circuitry 108 optionally includes well-known circuitry for detecting near field communication (NFC) fields, such as near field communication radios. The wireless communication optionally uses any of a number of communication standards, protocols, and technologies. These include Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), high-speed downlink packet access (HSDPA), high-speed uplink packet access (HSUPA), Evolution, Data-Only (EV-DO), HSPA, HSPA+, Dual-Cell HSPA (DC-HSPDA), long term evolution (LTE), near field communication (NFC), wideband code division multiple access (W-CDMA), and code division multiple access (CDMA).access (CDMA), time division multiple access (TDMA), Bluetooth®, Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi)® (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and / or IEEE 802.11ac), voice over Internet Protocol (VoIP), Wi-MAX, protocols for email (e.g., Internet message access protocol (IMAP) and / or post office protocol (POP)), instant messaging (e.g., extensible messaging and presence protocol (XMPP)), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE)), instant messaging and presence services (e.g., IEEE 802.11b), and / or IEEE 802.11ac). The present invention may be applied to any suitable communication protocol, including, but not limited to, Intermediate Message Service (IMPS), and / or Short Message Service (SMS), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document.

[0069] Audio circuit 110, speaker 111, and microphone 113 provide an audio interface between a user and device 100. Audio circuit 110 receives audio data from peripherals interface 118, converts the audio data into electrical signals, and transmits the electrical signals to speaker 111. Speaker 111 converts the electrical signals into sound waves audible to humans. Audio circuit 110 also receives electrical signals converted from sound waves by microphone 113. Audio circuit 110 converts the electrical signals into audio data and transmits the audio data to peripherals interface 118 for processing. Audio data may be retrieved from and / or transmitted to memory 102 and / or RF circuit 108 by peripherals interface 118. In some embodiments, audio circuit 110 further comprises a headset jack (e.g., 212 in FIG. 2 ). The headset jack provides an interface between audio circuitry 110 and a removable audio input / output peripheral, such as an output-only headphone or a headset with both an output (e.g., single or double ear headphones) and an input (e.g., a microphone).

[0070] I / O subsystem 106 couples input / output peripherals of device 100, such as touchscreen 112 and other input control devices 116, to peripheral interface 118. I / O subsystem 106 optionally includes one or more input controllers 160 for display controller 156, light sensor controller 158, intensity sensor controller 159, haptic feedback controller 161, and other input or control devices. One or more input controllers 160 receive electrical signals from and send electrical signals to other input or control devices 116. Other input control devices 116 optionally include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, etc. In some other embodiments, input controller(s) 160 are optionally coupled to any (or none) of a keyboard, infrared port, USB port, and pointer device such as a mouse. The one or more buttons (e.g., 208 in FIG. 2) optionally include up / down buttons for adjusting the volume of the speaker 111 and / or microphone 113. The one or more buttons optionally include a push button (e.g., 206 in FIG. 2).

[0071] A quick press of a push button may unlock the touchscreen 112 or initiate a process for using gestures on the touchscreen to unlock the device, as described in U.S. Patent Application No. 11 / 322,549, filed December 23, 2005, U.S. Patent No. 7,657,849, entitled "Unlocking a Device by Performing Gestures on an Unlock Image." This patent is incorporated herein by reference in its entirety. A longer press of a push button (e.g., 206) may power the device 100 on or off. The user may customize the functionality of one or more buttons. The touchscreen 112 may be used to implement virtual or soft buttons and one or more soft keyboards.

[0072] The touch-sensitive display 112 provides an input and output interface between the device and a user. The display controller 156 receives and sends electrical signals to and from the touchscreen 112. The touchscreen 112 displays visual output to the user. This visual output may include graphics, text, icons, video, and any combination thereof (collectively referred to as "graphics"). In some embodiments, some or all of the visual output may correspond to user interface objects.

[0073] Touchscreen 112 has a touch-sensitive surface, sensor, or set of sensors that receives input from a user based on haptic and / or tactile contact. Touchscreen 112 and display controller 156 (along with any associated modules and / or instruction sets in memory 102) detects contacts (and any movement or cessation of contact) on touchscreen 112 and translates the detected contacts into interactions with user interface objects (e.g., one or more softkeys, icons, web pages, or images) displayed on touchscreen 112. In one exemplary embodiment, the point of contact between touchscreen 112 and the user corresponds to the user's finger.

[0074] Touchscreen 112 may use liquid crystal display (LCD), light emitting polymer display (LPD), or light emitting diode (LED) technology, although other display technologies may be used in other embodiments. Touchscreen 112 and display controller 156 may detect contact and any movement or disruption of that contact using any of several now known or later developed touch sensing technologies, including, but not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touchscreen 112. In an exemplary embodiment, projected mutual capacitance sensing technology, such as that found in the iPhone® and iPod Touch® by Apple Inc. of Cupertino, California, is used.

[0075] The touch-sensitive display in some embodiments of touchscreen 112 may be similar to the multi-touch-sensing touchpads described in the following U.S. Patents: 6,323,846 (Westerman et al.), 6,570,557 (Westerman et al.), and / or 6,677,932 (Westerman), and / or U.S. Patent Application Publication No. 2002 / 0015024 A1, each of which is incorporated by reference in its entirety. However, touchscreen 112 displays visual output from device 100, whereas touch-sensitive touchpads do not provide visual output.

[0076] The touch-sensitive display in some embodiments of touchscreen 112 may be as described in the following applications: (1) U.S. Patent Application No. 11 / 381,313, filed May 2, 2006, entitled "Multipoint Touch Surface Controller"; (2) U.S. Patent Application No. 10 / 840,862, filed May 6, 2004, entitled "Multipoint Touchscreen"; (3) U.S. Patent Application No. 10 / 903,964, filed July 30, 2004, entitled "Gestures For Touch Sensitive Input Devices"; (4) U.S. Patent Application No. 11 / 048,264, filed January 31, 2005, entitled "Gestures For Touch Sensitive Input Devices"; (5) U.S. Patent Application No. 11 / 038,590, filed January 18, 2005, entitled "Mode-Based Graphical User Interfaces For Touch Sensitive Input Devices"; (6) U.S. Patent Application No. 11 / 228,758, filed September 16, 2005, entitled "Virtual Input Device"; (7) US Patent No. 11 / 228,700, filed September 16, 2005, entitled "Operation Of A Computer With A Touch Screen Interface," (8) US Patent No. 11 / 228,737, filed September 16, 2005, entitled "Activating Virtual Keys Of A Touch-Screen Virtual Keyboard," and (9) US Patent No. 11 / 367,749, filed March 3, 2006, entitled "Multi-Functional Hand-Held Device," all of which are incorporated herein by reference in their entirety.

[0077] The touchscreen 112 may have a video resolution greater than 100 dpi. In some embodiments, the touchscreen has a video resolution of approximately 160 dpi. A user can contact the touchscreen 112 using any suitable object or accessory, such as a stylus, a finger, or the like. In some embodiments, the user interface is designed to function primarily through finger-based contact and gestures, which may be less precise than stylus-based input due to the large contact area of a finger on the touchscreen. In some embodiments, the device translates coarse finger-based input into precise pointer / cursor position or commands to perform the user's desired action.

[0078] In some embodiments, in addition to a touchscreen, device 100 may include a touchpad (not shown) for activating or deactivating certain functions. In some embodiments, a touchpad is a touch-sensitive area of a device that, unlike a touchscreen, does not display visual output. A touchpad can be a touch-sensitive surface separate from touchscreen 112 or an extension of the touch-sensitive surface formed by the touchscreen.

[0079] Device 100 also includes a power system 162 for providing power to the various components. Power system 162 may include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, power failure detection circuitry, power converters or inverters, power status indicators (e.g., light emitting diodes (LEDs)), and any other components associated with generating, managing, and distributing power in a portable device.

[0080] Device 100 may also include one or more light sensors 164. FIG. 1A shows a light sensor coupled to light sensor controller 158 in I / O subsystem 106. Light sensor 164 may include a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) phototransistor. Light sensor 164 receives light from the environment, projected through one or more lenses, and converts the light into data representing an image. In conjunction with imaging module 143 (also referred to as a camera module), light sensor 164 can capture still images or video. In some embodiments, a light sensor is located on the back of device 100, opposite touchscreen display 112 on the front of the device, so that the touchscreen display can be used as a viewfinder for still and / or video image acquisition. In some embodiments, a light sensor is located on the front of the device so that an image of a user can be obtained for a videoconference while the user simultaneously views other videoconference participants on the touchscreen display. In some embodiments, the position of the light sensor 164 can be changed by the user (e.g., by rotating the lens and sensor within the device housing), thereby allowing a single light sensor 164 to be used in conjunction with a touchscreen display for both video conferencing and capturing still and / or video images.

[0081] Device 100 also optionally includes one or more contact intensity sensors 165. FIG. 1A shows contact intensity sensors coupled to intensity sensor controller 159 in I / O subsystem 106. Contact intensity sensors 165 optionally include one or more piezoresistive strain gauges, capacitive force sensors, electric force sensors, piezoelectric force sensors, optical force sensors, capacitive touch-sensitive surfaces, or other intensity sensors (e.g., sensors used to measure the force (or pressure) of a contact on a touch-sensitive surface). Contact intensity sensors 165 receive contact intensity information (e.g., pressure information or a proxy for pressure information) from the environment. In some embodiments, at least one contact intensity sensor is located on or proximate to the touch-sensitive surface (e.g., touch-sensitive display system 112). In some embodiments, at least one contact intensity sensor is located on the back of device 100, opposite touchscreen display 112, which is located on the front of device 100.

[0082] Device 100 may also include one or more proximity sensors 166. Figure 1A shows proximity sensor 166 coupled to peripherals interface 118. Alternatively, proximity sensor 166 may be coupled to input controller 160 within I / O subsystem 106. Proximity sensor 166 may function as described in U.S. patent application Ser. Nos. 11 / 241,839, "Proximity Detector In Handheld Device," 11 / 240,788, "Proximity Detector In Handheld Device," 11 / 620,702, "Using Ambient Light Sensor To Augment Proximity Sensor Output," 11 / 586,862, "Automated Response To And Sensing Of User Activity In Portable Devices," and 11 / 638,251, "Methods And Systems For Automatic Configuration Of Peripherals," which are incorporated herein by reference in their entireties. In some embodiments, the proximity sensor turns off and disables touchscreen 112 when the multifunction device is placed near the user's ear (e.g., when the user is talking on the phone).

[0083] Device 100 also optionally includes one or more tactile output generators 167. FIG. 1A shows tactile output generators 167 coupled to haptic feedback controller 161 in I / O subsystem 106. Tactile output generator 167 optionally includes one or more electroacoustic devices, such as speakers or other audio components, and / or electromechanical devices that convert energy into linear motion, such as motors, solenoids, electroactive polymers, piezoelectric actuators, electrostatic actuators, or other tactile output generating components (e.g., components that convert electrical signals into tactile output on the device). Contact intensity sensor 165 receives tactile feedback generation instructions from haptic feedback module 133 and generates a tactile output on device 100 that can be sensed by a user of device 100. In some embodiments, at least one tactile output generator is located on or proximate to a touch-sensitive surface (e.g., touch-sensitive display system 112) and, optionally, generates a tactile output by moving the touch-sensitive surface vertically (e.g., in / out of the surface of device 100) or laterally (e.g., back and forth in the same plane as the surface of device 100). In some embodiments, at least one tactile output generator sensor is located on the back of device 100, opposite touchscreen display 112, which is located on the front of device 100.

[0084] Device 100 may further include one or more accelerometers 168. FIG. 1A shows accelerometer 168 coupled to peripherals interface 118. Alternatively, accelerometer 168 may be coupled to input controller 160 in I / O subsystem 106. Accelerometer 168 may function as described in U.S. Patent Application Publication Nos. 20050190059, "Acceleration-Based Theft Detection System for Portable Electronic Devices," and 20060017692, "Methods And Apparatuses For Operating A Portable Device Based On An Accelerometer," both of which are incorporated herein by reference in their entireties. In some embodiments, information is displayed on a touchscreen display in portrait or landscape orientation based on an analysis of data received from one or more accelerometers. In addition to accelerometer(s) 168, device 100 optionally includes a magnetometer (not shown) and a GPS (or GLONASS or other global navigation system) receiver (not shown) for obtaining information regarding the location and orientation (e.g., portrait or landscape) of device 100.

[0085] In some embodiments, the software components stored in memory 102 include an operating system 126, a communications module (or instruction set) 128, a touch / motion module (or instruction set) 130, a graphics module (or instruction set) 132, a text input module (or instruction set) 134, a global positioning system (GPS) module (or instruction set) 135, and applications (or instruction sets) 136. Additionally, in some embodiments, as shown in FIGS. 1A and 3, memory 102 (FIG. 1A) or memory 370 (FIG. 3) stores device / global internal state 157. Device / global internal state 157 includes one or more of: an active application state indicating which, if any, applications are currently active; a display state indicating what applications, views, or other information occupy various regions of touchscreen display 112; a sensor state including information obtained from the device's various sensors and input control devices 116; and location information regarding the device's position and / or orientation.

[0086] Operating system 126 (e.g., an embedded operating system such as Darwin®, RTXC®, LINUX®, UNIX®, OS X®, iOS®, WINDOWS®, or VxWorks®) includes various software components and / or drivers for controlling and managing common system tasks (e.g., memory management, storage device control, power management, etc.) and facilitating communication between various hardware and software components.

[0087] Communications module 128 facilitates communication with other devices through one or more external ports 124 and also includes various software components for processing data received by RF circuitry 108 and / or external ports 124. External ports 124 (e.g., Universal Serial Bus (USB), FIREWIRE®, etc.) are adapted to couple to other devices directly or indirectly through a network (e.g., the Internet, wireless LAN, etc.). In some embodiments, the external ports are multi-pin (e.g., 30-pin) connectors identical to, similar to, and / or compatible with the 30-pin connector used on iPod® (trademark of Apple Inc.) devices.

[0088] Contact / motion module 130, optionally in cooperation with display controller 156, detects contact with touch screen 112 and other touch-sensing devices (e.g., a touchpad or physical click wheel). Contact / motion module 130 includes various software components for performing various operations related to detecting contact, such as determining whether contact has occurred (e.g., detecting a finger-down event), determining the intensity of the contact (e.g., the force or pressure of the contact, or a surrogate for the force or pressure of the contact), determining whether there is contact movement and tracking of the movement across the touch-sensitive surface (e.g., detecting one or more finger-drag events), and determining whether the contact has ceased (e.g., detecting a finger-up event or an interruption of contact). Contact / motion module 130 receives contact data from the touch-sensitive surface. Determining the movement of the contact point represented by the series of contact data optionally includes determining the speed (magnitude), velocity (magnitude and direction), and / or acceleration (change in magnitude and / or direction) of the contact point. These actions are optionally applied to a single contact (e.g., a single finger contact) or multiple simultaneous contacts (e.g., "multi-touch" / multiple finger contacts). In some embodiments, contact / motion module 130 and display controller 156 detect contacts on the touchpad.

[0089] In some embodiments, contact / motion module 130 uses a set of one or more intensity thresholds for determining whether an action has been performed by a user (e.g., for determining whether a user has “clicked” on an icon). In some embodiments, at least a subset of the intensity thresholds are determined according to software parameters (e.g., the intensity thresholds are not determined by the activation threshold of a particular physical actuator and may be adjusted without modifying the physical hardware of device 100). For example, the mouse “click” threshold of a trackpad or touchscreen display can be set to any of a wide range of pre-defined thresholds without modifying the trackpad or touchscreen display hardware. Furthermore, in some implementations, a user of the device is provided with a software setting for adjusting one or more of the set of intensity thresholds (e.g., by adjusting individual intensity thresholds and / or by adjusting multiple intensity thresholds at once via a system-level click “intensity” parameter).

[0090] Contact / motion module 130 optionally detects gesture input by a user. Different gestures on the touch-sensitive surface have different contact patterns (e.g., different movements, timing, and / or intensity of detected contact). Thus, gestures are optionally detected by detecting particular contact patterns. For example, detecting a finger tap gesture includes detecting a finger down event (e.g., at an icon location), followed by detecting a finger lift (lift-off) event at the same location (or substantially the same location) as the finger down event. As another example, detecting a finger swipe gesture on the touch-sensitive surface includes detecting a finger down event, followed by detecting one or more finger drag events, followed by detecting a finger lift (lift-off) event.

[0091] Graphics module 132 includes various known software components for rendering and displaying graphics on touchscreen 112 or other display, including components for modifying the visual effects (e.g., brightness, transparency, saturation, contrast, or other visual characteristics) of the displayed graphics. As used herein, the term "graphics" includes any object that can be displayed to a user, including, but not limited to, text, web pages, icons (such as user interface objects including soft keys), digital images, video, animation, etc.

[0092] In some embodiments, graphics module 132 stores data representing the graphics to be used. Each graphic is optionally assigned a corresponding code. Graphics module 132 receives one or more codes specifying the graphics to be displayed, including coordinate data and other graphic characteristic data, as needed, from an application or the like, and then generates screen image data to output to display controller 156.

[0093] The tactile feedback module 133 includes various software components for generating instructions used by the tactile output generator(s) 167 to generate tactile outputs at one or more locations on the device 100 in response to user interaction with the device 100.

[0094] The text input module 134 may be a component of the graphics module 132 and provides a soft keyboard for entering text in various applications (e.g., contacts 137, email 140, IM 141, browser 147, and any other application requiring text input).

[0095] The GPS module 135 determines the location of the device and provides this information for use in various applications (e.g., a phone 138 application for use in location-based dialing, a camera 143 application for image / video metadata, and applications that provide location-based services such as a weather widget, a local yellow pages widget, and a maps / navigation widget).

[0096] The application 136 may include the following modules (or sets of instructions), or a subset or superset thereof: Contacts module 137 (sometimes called an address book or contact list) ●Telephone module 138 ●Videoconferencing module 139 ●Email client module 140 ● Instant Messaging (IM) Module 141 ●Training Support Module 142 Camera module 143 for still and / or video images ●Image Management Module 144 ●Video playback module ●Music playback module Browser module 147 ●Calendar module 148 A widget module 149, which may include one or more of a weather widget 149-1, a stock price widget 149-2, a calculator widget 149-3, an alarm clock widget 149-4, a dictionary widget 149-5, and other widgets acquired by the user, as well as user-created widgets 149-6. A widget creation module 150 for creating user-created widgets 149-6 ●Search module 151 ●Video and music playback module 152, which integrates a video playback module and a music playback module. ●Memo Module 153 Map module 154, and / or ●Online video module 155.

[0097] Examples of other applications 136 that may be stored in memory 102 include other word processing applications, other image editing applications, drawing applications, presentation applications, JAVA®-enabled applications, encryption, digital rights management, voice recognition, and voice duplication.

[0098] In conjunction with touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, contacts module 137 is used to manage an address book or contact list (e.g., stored in memory 102 or in the application internal state 192 of contacts module 137 in memory 370), including adding name(s) to the address book, removing name(s) from the address book, associating phone number(s), email address(es), postal address(es), or other information with names, associating images with names, categorizing and sorting names, providing phone numbers or email addresses to initiate and / or facilitate communication by phone 138, videoconferencing module 139, email 140, or IM 141, etc.

[0099] In conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, telephone module 138 can be used to enter a series of characters corresponding to a telephone number, access one or more telephone numbers in contacts module 137, modify an entered telephone number, dial the corresponding telephone number, conduct a conversation, and disconnect or hang up when the conversation is completed. As noted above, wireless communication can use any of a number of communication standards, protocols, and technologies.

[0100] In conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, light sensor 164, light sensor controller 158, contact module 130, graphics module 132, text input module 134, contact module 137, and telephone module 138, videoconferencing module 139 includes executable instructions for initiating, conducting, and terminating a videoconference between a user and one or more other participants in accordance with the user's instructions.

[0101] In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, email client module 140 contains executable instructions for composing, sending, receiving, and managing emails in response to user instructions. Email client module 140 in conjunction with image management module 144 greatly facilitates composing and sending emails with attached still or video images captured by camera module 143.

[0102] In cooperation with RF circuitry 108, touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, instant messaging module 141 includes executable instructions for entering text corresponding to an instant message, modifying entered text, sending the corresponding instant message (e.g., using Short Message Service (SMS) or Multimedia Message Service (MMS) protocols for telephone-based instant messaging, or using XMPP, SIMPLE, or IMPS for Internet-based instant messaging), and receiving and displaying the received instant message. In some embodiments, sent and / or received instant messages may include graphics, photos, audio files, video files, and / or other attachments, such as those supported by MMS and / or Enhanced Messaging Service (EMS). As used herein, "instant messaging" refers to both telephone-based messages (e.g., messages sent using SMS or MMS) and Internet-based messages (e.g., messages sent using XMPP, SIMPLE, or IMPS).

[0103] In conjunction with the RF circuitry 108, touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, text input module 134, GPS module 135, map module 154, and music playback module, the training support module 142 includes executable instructions for generating workouts (e.g., having time, distance, and / or calorie burn goals), communicating with training sensors (sports devices), receiving training sensor data, calibrating sensors used to monitor workouts, selecting and playing music for workouts, and displaying, storing, and transmitting workout data.

[0104] In conjunction with touch screen 112, display controller 156, light sensor(s) 164, light sensor controller 158, contact / motion module 130, graphics module 132, and image management module 144, camera module 143 contains executable instructions to capture still images or video (including video streams) and store them in memory 102, change the characteristics of the still images or video, or delete the still images or video from memory 102.

[0105] In conjunction with touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, text input module 134, and camera module 143, image management module 144 includes executable instructions for arranging, modifying (e.g., editing) and otherwise manipulating, labeling, deleting, presenting (e.g., in a digital slideshow or album), and storing still and / or video images.

[0106] In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, browser module 147 contains executable instructions for browsing the Internet according to user instructions, including retrieving, linking to, receiving, and displaying web pages or portions thereof, as well as attachments and other files linked to web pages.

[0107] In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact / motion module 130, graphics module 132, text input module 134, email client module 140, and browser module 147, calendar module 148 contains executable instructions for creating, displaying, modifying, and storing calendars and data associated with calendars (e.g., calendar entries, to-do lists, etc.) in accordance with user instructions.

[0108] In conjunction with RF circuitry 108, touchscreen 112, display controller 156, touch / motion module 130, graphics module 132, text input module 134, and browser module 147, widget module 149 is a mini-application that can be downloaded and used by a user (e.g., weather widget 149-1, stock quotes widget 149-2, calculator widget 149-3, alarm clock widget 149-4, and dictionary widget 149-5), or created by a user (e.g., user-created widget 149-6). In some embodiments, a widget includes an HTML (HyperText Markup Language) file, a CSS (Cascading Style Sheets) file, and a JavaScript file. In some embodiments, a widget includes an XML (Extensible Markup Language) file and a JavaScript file (e.g., Yahoo! Widget).

[0109] In conjunction with the RF circuitry 108, touch screen 112, display controller 156, touch / motion module 130, graphics module 132, text input module 134, and browser module 147, widget creation module 150 can be used by a user to create widgets (e.g., turn user-specified portions of a web page into widgets).

[0110] In cooperation with touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, search module 151 contains executable instructions for searching memory 102 for text, music, sound, images, video, and / or other files that match one or more search criteria (e.g., one or more user-specified search terms) in accordance with a user's instructions.

[0111] In cooperation with touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, audio circuitry 110, speaker 111, RF circuitry 108, and browser module 147, video and music playback module 152 contains executable instructions that enable a user to download and play pre-recorded music and other sound files stored in one or more file formats, such as MP3 or AAC files, as well as executable instructions for displaying, presenting, or otherwise playing videos (on touchscreen 112 or on an external display connected via external port 124). In some embodiments, device 100 optionally includes the functionality of an MP3 player, such as an iPod (a trademark of Apple Inc.).

[0112] In conjunction with touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, notes module 153 contains executable instructions for creating and managing notes, to-do lists, and the like, in accordance with user instructions.

[0113] In conjunction with RF circuitry 108, touch screen 112, display controller 156, touch / motion module 130, graphics module 132, text input module 134, GPS module 135, and browser module 147, map module 154 can be used to receive, display, modify, and store maps and data associated with maps (e.g., driving directions, data about businesses and other points of interest at or near a particular location, and other location-based data) in accordance with user instructions.

[0114] In cooperation with touchscreen 112, display controller 156, contact / motion module 130, graphics module 132, audio circuitry 110, speaker 111, RF circuitry 108, text input module 134, email client module 140, and browser module 147, online video module 155 contains instructions that enable a user to access, view, receive (e.g., by streaming and / or downloading), play (e.g., on the touchscreen or on an external display connected via external port 124), and send and otherwise manage emails containing links to particular online videos in one or more file formats, such as H.264. In some embodiments, instant messaging module 141 is used to send links to particular online videos, rather than email client module 140. Additional description of online video applications can be found in U.S. Provisional Patent Application No. 60 / 936,562, filed June 20, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," and U.S. Patent Application No. 11 / 968,067, filed December 31, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," the contents of which are incorporated by reference herein in their entireties.

[0115] Each of the above-identified modules and applications corresponds to an executable instruction set and method described herein (e.g., a computer-implemented method and other information processing method described herein) for performing one or more of the above functions. These modules (e.g., instruction sets) need not be implemented as separate software programs, procedures, or modules; thus, in various embodiments, various subsets of these modules may be combined or otherwise rearranged. For example, a video playback module may be combined with a music playback module into a single module (e.g., video and music playback module 152 of FIG. 1A). In some embodiments, memory 102 may store a subset of the above-identified modules and data structures. Additionally, memory 102 may store additional modules and data structures not described above.

[0116] In some embodiments, device 100 is a device in which operation of a predefined set of functions on the device is performed exclusively via a touchscreen and / or touchpad. By using the touchscreen and / or touchpad as the primary input control device for operation of device 100, the number of physical input control devices (e.g., pushbuttons, dials, etc.) on device 100 can be reduced.

[0117] The set of predefined functions, performed exclusively via the touchscreen and / or touchpad, optionally includes navigation between user interfaces. In some embodiments, the touchpad, when touched by a user, navigates device 100 to a main menu, home menu, or root menu from any user interface displayed on device 100. In such embodiments, a "menu button" is implemented using the touchpad. In some other embodiments, the menu button is a physical push button or other physical input control device instead of a touchpad.

[0118] 1B is a block diagram illustrating exemplary components for event processing, according to some embodiments. In some embodiments, memory 102 (FIG. 1A) or memory 370 (FIG. 3) includes event sorter 170 (e.g., in operating system 126) and corresponding application 136-1 (e.g., any of applications 137-151, 155, 380-390 described above).

[0119] Event sorter 170 receives the event information and determines which application 136-1 and application view 191 for application 136-1 to deliver the event information to. Event sorter 170 includes event monitor 171 and event dispatcher module 174. In some embodiments, application 136-1 includes application internal state 192 that indicates the current application view(s) to be displayed on touch-sensitive display 112 when the application is active or running. In some embodiments, device / global internal state 157 is used by event sorter 170 to determine which application(s) is currently active, and application internal state 192 is used by event sorter 170 to determine which application(s) is / are currently active, and application internal state 192 is used by event sorter 170 to determine which application view(s) to deliver the event information to.

[0120] In some embodiments, application internal state 192 includes additional information such as one or more of resume information used when application 136-1 resumes execution, user interface state information indicating information being displayed or ready to be displayed by application 136-1, a state queue to allow the user to return to a previous state or view of application 136-1, and a redo / undo queue of actions previously performed by the user.

[0121] Event monitor 171 receives event information from peripherals interface 118. The event information includes information about sub-events (e.g., a user's touch on touch-sensitive display 112 as part of a multi-touch gesture). Peripherals interface 118 transmits information it receives from I / O subsystem 106 or sensors such as proximity sensor 166, accelerometer(s) 168, and / or microphone 113 (via audio circuitry 110). Information that peripherals interface 118 receives from I / O subsystem 106 includes information from touch-sensitive display 112 or a touch-sensitive surface.

[0122] In some embodiments, event monitor 171 sends requests to peripherals interface 118 at predetermined intervals. In response, peripherals interface 118 transmits event information. In other embodiments, peripherals interface 118 transmits event information only when there is a significant event (e.g., receiving an input that exceeds a predetermined noise threshold and / or exceeds a predetermined duration).

[0123] In some embodiments, event sorter 170 also includes a hit view determination module 172 and / or an active event recognizer determination module 173 .

[0124] Hit view determination module 172 provides software procedures for determining where a sub-event occurred within one or more views when touch-sensitive display 112 displays one or more views. A view consists of controls and other elements that a user can see on the display.

[0125] Another aspect of a user interface associated with an application is the set of views, sometimes referred to herein as application views or user interface windows, in which information is displayed and touch-based gestures occur. The application view (of the corresponding application) in which a touch is detected may correspond to a programmatic level within the programmatic or view hierarchy of that application. For example, the lowest-level view in which a touch is detected may be referred to as the hit view, and the set of events that are recognized as appropriate inputs may be determined, at least in part, based on the hit view of the initial touch that initiates a touch-based gesture.

[0126] Hit view determination module 172 receives information associated with sub-events of a touch-based gesture. If an application has multiple views organized as a hierarchy, hit view determination module 172 identifies the hit view as the lowest view in the hierarchy that should process the sub-event. In most situations, the hit view is the lowest-level view in which the first sub-event occurs (e.g., the first sub-event in a sequence of sub-events that form an event or potential event). Once a hit view is identified by hit view determination module 172, the hit view typically receives all sub-events associated with the same touch or input source for which it was identified as the hit view.

[0127] Active event recognizer determination module 173 determines which view(s) in the view hierarchy should receive the particular sequence of sub-events. In some embodiments, active event recognizer determination module 173 determines that only the hit view should receive the particular sequence of sub-events. In other embodiments, active event recognizer determination module 173 determines that all views that contain the physical location of the sub-events are actively participating views, and therefore, all actively participating views should receive the particular sequence of sub-events. In other embodiments, even if the touch sub-event is completely confined to the region associated with a particular view, views higher in the hierarchy remain actively participating views.

[0128] Event dispatcher module 174 dispatches event information to event recognizers (e.g., event recognizer 180). In embodiments that include active event recognizer determination module 173, event dispatcher module 174 delivers the event information to the event recognizers determined by active event recognizer determination module 173. In some embodiments, event dispatcher module 174 stores event information retrieved by corresponding event receivers 182 in an event queue.

[0129] In some embodiments, operating system 126 includes event sorter 170. Alternatively, application 136-1 includes event sorter 170. In still other embodiments, event sorter 170 is a stand-alone module or part of another module stored in memory 102, such as contact / motion module 130.

[0130] In some embodiments, application 136-1 includes multiple event handlers 190 and one or more application views 191, each containing instructions for handling touch events that occur within a respective view of the application's user interface. Each application view 191 of application 136-1 includes one or more event recognizers 180. Typically, each application view 191 includes multiple event recognizers 180. In other embodiments, one or more of event recognizers 180 are part of a separate module, such as a User Interface Kit (not shown) or a higher-level object from which application 136-1 inherits methods and other properties. In some embodiments, each event handler 190 includes one or more of data updater 176, object updater 177, GUI updater 178, and / or event data 179 received from event sorter 170. Event handler 190 may utilize or call data updater 176, object updater 177, or GUI updater 178 to update application internal state 192. Alternatively, one or more of the application views 191 includes one or more respective event handlers 190. In some embodiments, one or more of a data updater 176, an object updater 177, and a GUI updater 178 are also included in the corresponding application view 191.

[0131] Each event recognizer 180 receives event information (e.g., event data 179) from event sorter 170 and identifies an event from the event information. Event recognizer 180 includes event receiver 182 and event comparator 184. In some embodiments, event recognizer 180 further includes metadata 183 and at least a subset of event delivery instructions 188 (which may include sub-event delivery instructions).

[0132] Event receiver 182 receives event information from event sorter 170. The event information includes information about sub-events, such as a touch or a movement of the touch. Depending on the sub-event, the event information also includes additional information, such as the position of the sub-event. If the sub-event involves a movement of the touch, the event information may further include the speed and direction of the sub-event. In some embodiments, the event includes a rotation of the device from one orientation to another (e.g., from portrait to landscape orientation, or vice versa), and the event information includes corresponding information about the current orientation of the device (also called the device's attitude).

[0133] The event comparator 184 compares the event information to predefined event or sub-event definitions and determines the event or sub-event, or determines or updates the state of the event or sub-event, based on the comparison. In some embodiments, the event comparator 184 includes an event definition 186. The event definition 186 includes a definition of an event (e.g., a predefined sequence of sub-events), such as Event 1 (187-1), Event 2 (187-2), etc. In some embodiments, sub-events within an event (187) include, for example, touch start, touch end, touch movement, touch cancellation, and multiple touches. In one example, the definition of Event 1 (187-1) is a double tap on a displayed object. This double tap includes, for example, a first touch on a displayed object for a predetermined phase (touch start), a first lift-off (touch end) for the predetermined phase, a second touch on a displayed object for the predetermined phase (touch start), and a second lift-off (touch end) for the predetermined phase. In another example, the definition of event 2 (187-2) is a drag operation on a displayed object, including, for example, a touch (or contact) on the displayed object for a predetermined step, a movement of the touch across the touch-sensitive display 112, and a lift-off of the touch (end of the touch). In some embodiments, the event also includes information about one or more associated event handlers 190.

[0134] In some embodiments, event definitions 187 include definitions of events for each user interface object. In some embodiments, event comparator 184 performs a hit test to determine the user interface object associated with the sub-event. For example, in an application view in which three user interface objects are displayed on touch-sensitive display 112, if a touch is detected on touch-sensitive display 112, event comparator 184 performs a hit test to determine which of the three user interface objects is associated with the touch (sub-event). If each displayed object is associated with a corresponding event handler 190, event comparator 184 uses the results of the hit test to determine which event handler 190 to activate. For example, event comparator 184 selects the event handler associated with the sub-event and the object that triggers the hit test.

[0135] In some embodiments, the definition for each event (187) also includes a delay action that delays delivery of the event information until it is determined whether the sequence of sub-events corresponds to the event type of the event recognizer.

[0136] If each event recognizer 180 determines that the sequence of sub-events does not match any of the events in event definition 186, then each event recognizer 180 enters an event-disabled, event-failed, or event-ended state and thereafter ignores the next sub-event of the touch-based gesture. In this situation, any other event recognizers that remain active for the hit view continue to track and process sub-events of the ongoing touch-based gesture.

[0137] In some embodiments, each event recognizer 180 includes metadata 183 with configurable properties, flags, and / or lists that indicate how the event delivery system performs sub-event delivery to actively participating event recognizers. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate how event recognizers may or may not interact with each other. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate whether sub-events are delivered to various levels in the view or programmatic hierarchy.

[0138] In some embodiments, each event recognizer 180 activates an event handler 190 associated with an event when one or more specific sub-events in the event are recognized. In some embodiments, each event recognizer 180 delivers event information associated with the event to the event handler 190. Activating an event handler 190 is distinct from sending (and postponing sending) the sub-events to the corresponding hit view. In some embodiments, the event recognizer 180 throws a flag associated with the recognized event, and the event handler 190 associated with the flag catches the flag and performs predefined processing.

[0139] In some embodiments, event delivery instructions 188 include sub-event delivery instructions that deliver event information about a sub-event without activating an event handler. Instead, the sub-event delivery instructions deliver the event information to an event handler associated with a set of sub-events or an actively participating view. The event handler associated with the set of sub-events or an actively participating view receives the event information and performs predetermined processing.

[0140] In some embodiments, data updater 176 creates and updates data used by application 136-1. For example, data updater 176 updates phone numbers used by contacts module 137 or stores video files used by video playback module. In some embodiments, object updater 177 creates and updates objects used by application 136-1. For example, object updater 177 creates new user interface objects or updates the positions of user interface objects. GUI updater 178 updates the GUI. For example, GUI updater 178 prepares display information and sends it to graphics module 132 for display on the touch-sensitive display.

[0141] In some embodiments, event handler(s) 190 include or have access to data updater 176, object updater 177, and GUI updater 178. In some embodiments, data updater 176, object updater 177, and GUI updater 178 are included in a single module for each application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.

[0142] It will be understood that the above description of event processing of a user's touch on a touch-sensitive display also applies to other forms of user input for operating multifunction device 100 using input devices, not all of which are initiated on the touchscreen. For example, mouse movements and mouse button presses, optionally coupled with single or multiple keyboard presses or holds, touch movements such as tapping, dragging, scrolling, etc. on a touchpad, pen stylus input, device movement, verbal commands, detected eye movement, biometric input, and / or any combination thereof, are optionally utilized as inputs corresponding to sub-events that define the event to be recognized.

[0143] FIG. 2 illustrates portable multifunction device 100 having touchscreen 112, according to some embodiments. The touchscreen optionally displays one or more graphics within user interface (UI) 200. In this embodiment, as well as embodiments described below, a user can select one or more of the graphics by making a gesture on the graphics, for example, with one or more fingers 202 (not drawn to scale) or one or more styluses 203 (not drawn to scale). In some embodiments, selection of one or more graphics occurs when the user loses contact with the one or more graphics. In some embodiments, the gesture optionally includes one or more taps, one or more swipes (left to right, right to left, upward and / or downward), and / or rolling of a finger in contact with device 100 (right to left, left to right, upward and / or downward). In some implementations or situations, accidental contact with a graphic does not select the graphic. For example, if the gesture corresponding to selection is a tap, a swipe gesture sweeping over an application icon optionally does not select the corresponding application.

[0144] Device 100 may also include one or more physical buttons, such as a "home" or menu button 204. As described above, menu button 204 can be used to navigate to any application 136 in a set of applications that may be running on device 100. Alternatively, in some embodiments, the menu button is implemented as a soft key in a GUI displayed on touch screen 112.

[0145] In one embodiment, device 100 includes touchscreen 112, menu button 204, pushbutton 206 for powering the device on / off and locking the device, volume control button(s) 208, subscriber identity module (SIM) card slot 210, headset jack 212, and external docking / charging port 124. Pushbutton 206 is optionally used to turn power on / off on the device by pressing and holding the button down for a predetermined time, lock the device by pressing and releasing the button before the predetermined time has elapsed, and / or unlock the device or begin an unlocking process. In another embodiment, device 100 also receives verbal input for activating or deactivating certain functions through microphone 113. Device 100 also optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on touchscreen 112 and / or one or more tactile output generators 167 for generating a tactile output for a user of device 100.

[0146] FIG. 3 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface, according to some embodiments. Device 300 need not be portable. In some embodiments, device 300 is a laptop computer, a desktop computer, a tablet computer, a multimedia player device, a navigation device, an educational device (such as a child's learning toy), a gaming system, or a control device (e.g., a home or commercial controller). Device 300 typically includes one or more processing units (CPUs) 310, one or more network or other communication interfaces 360, memory 370, and one or more communication buses 320 for interconnecting these components. Communication bus 320 optionally includes circuitry (sometimes called a chipset) that interconnects and controls communication between system components. Device 300 includes an input / output (I / O) interface 330 with a display 340, which is typically a touchscreen display. I / O interface 330 also optionally includes a keyboard and / or mouse (or other pointing device) 350, as well as a touchpad 355, a tactile output generator 357 (e.g., similar to tactile output generator(s) 167 described above with reference to FIG. 1A ) for generating tactile output on device 300, and sensors 359 (e.g., optical sensors, acceleration sensors, proximity sensors, touch-sensitive sensors, and / or contact intensity sensors similar to contact intensity sensor(s) 165 described above with reference to FIG. 1A ). Memory 370 includes high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices, and optionally includes non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile semiconductor storage devices. Memory 370 optionally includes one or more storage devices located remotely from CPU(s) 310.In some embodiments, memory 370 stores programs, modules, and data structures similar to, or a subset of, the programs, modules, and data structures stored in memory 102 of portable multifunction device 100 (FIG. 1A). Additionally, memory 370 optionally stores additional programs, modules, and data structures not present in memory 102 of portable multifunction device 100. For example, memory 370 of device 300 optionally stores drawing module 380, presentation module 382, word processing module 384, website creation module 386, disk authoring module 388, and / or spreadsheet module 390, while memory 102 of portable multifunction device 100 (FIG. 1A) optionally does not store these modules.

[0147] Each of the above-identified elements of FIG. 3 may be stored in one or more of the memory devices mentioned above. Each of the above-identified modules corresponds to an instruction set that performs the functions described above. The above-identified modules or programs (e.g., instruction sets) need not be implemented as separate software programs, procedures, or modules; thus, various embodiments may combine or otherwise rearrange various subsets of these modules. In some embodiments, memory 370 may store a subset of the above-identified modules and data structures. Additionally, memory 370 may store additional modules and data structures not described above.

[0148] Attention is now directed to user interface embodiments that may be implemented on portable multifunction device 100, for example.

[0149] 4A shows an exemplary user interface for a menu of applications on portable multifunction device 100, according to some embodiments. A similar user interface may be implemented on device 300. In some embodiments, user interface 400 includes the following elements, or a subset or superset thereof: signal strength indicator(s) 402 for wireless communication(s), such as cellular and Wi-Fi signals; ●Time 404, ●Bluetooth indicator 405, ● Battery status indicator 406, A tray 408 containing icons for frequently used applications, such as: an icon 416 for the phone module 138, labeled "Phone," optionally including an indicator 414 of the number of missed calls or voicemail messages; an icon 418 for the email client module 140, labeled "Mail," optionally including an indicator 410 of the number of unread emails; ○ An icon 420 for the browser module 147, labeled "Browser"; and ○ An icon 422 labeled "iPod" for the video and music playback module 152, also referred to as the iPod (trademark of Apple Inc.) module 152; ●Icons for other applications, such as: ○ Icon 424 for IM module 141, labeled "Messages" ○ An icon 426 for the calendar module 148, labeled "Calendar"; ○ Icon 428 for the image management module 144, labeled "Photos" ○ An icon 430 for the camera module 143, labeled "camera"; ○ Icon 432 for the online video module 155, labeled "Online Video" Icon 434 for stock price widget 149-2, labeled "Stock Prices" ○ Icon 436 for map module 154, labeled "Map" ○ Icon 438 for weather widget 149-1, labeled "Weather" ○ Icon 440 for alarm clock widget 149-4, labeled "Clock" ○ Icon 442 for Training Support Module 142, labeled "Training Support"; ○ An icon 444 for the notes module 153, labeled "Notes," and o An icon 446 labeled "Settings" for a settings application or module that provides access to settings for the device 100 and its various applications 136.

[0150] 4A are merely exemplary. For example, icon 422 for video and music playback module 152 is labeled "Music" or "Music Player." Other labels are optionally used for various application icons. In some embodiments, the label for each application icon includes the name of the application corresponding to each application icon. In some embodiments, the label for a particular application icon is different from the name of the application corresponding to the particular application icon.

[0151] 4B shows an exemplary user interface on a device (e.g., device 300 of FIG. 3) that includes a touch-sensitive surface 451 (e.g., tablet or touchpad 355 of FIG. 3) that is separate from display 450 (e.g., touchscreen display 112). Device 300 also optionally includes one or more contact intensity sensors (e.g., one or more of sensors 357) for detecting the intensity of a contact on touch-sensitive surface 451 and / or one or more tactile output generators 359 for generating a tactile output for a user of device 300.

[0152] Although some of the following examples are described with reference to input on touchscreen display 112 (when the touch-sensitive surface and display are combined), in some embodiments, the device detects input on a touch-sensitive surface that is separate from the display, as shown in FIG. 4B . In some embodiments, this touch-sensitive surface (e.g., 451 in FIG. 4B ) has a major axis (e.g., 452 in FIG. 4B ) that corresponds to a major axis (e.g., 453 in FIG. 4B ) on the display (e.g., 450). According to these embodiments, the device detects contact with touch-sensitive surface 451 (e.g., 460 and 462 in FIG. 4B ) at locations that correspond to their respective locations on the display (e.g., in FIG. 4B , 460 corresponds to 468 and 462 corresponds to 470). In this manner, when the touch-sensitive surface is separate from the display, user input (e.g., contacts 460 and 462 and their movement) detected by the device on the touch-sensitive surface (e.g., 451 in FIG. 4B ) is used by the device to operate a user interface on the display (e.g., 450 in FIG. 4B ) of the multifunction device. It should be understood that similar methods are optionally used for the other user interfaces described herein.

[0153] Additionally, while the following examples are described primarily with reference to finger input (e.g., finger touches, finger tap gestures, finger swipe gestures), it should be understood that in some embodiments, one or more of the finger inputs are replaced with input from another input device (e.g., mouse-based input or stylus input). For example, a swipe gesture is optionally replaced by a mouse click (e.g., instead of a touch) followed by an action of moving a cursor along the path of the swipe (e.g., instead of moving the contact). As another example, a tap gesture is optionally replaced by a mouse click while the cursor is positioned over the tap gesture location (e.g., instead of detecting a contact followed by ceasing to detect the contact). Similarly, it should be understood that when multiple user inputs are detected simultaneously, multiple computer mice are optionally used simultaneously, or mice and / or finger contacts are optionally used simultaneously.

[0154] FIG. 5A shows an exemplary personal electronic device 500. Device 500 includes a main body 502. In some embodiments, device 500 may include some or all of the features described with respect to devices 100 and 300 (e.g., FIGS. 1A-4B ). In some embodiments, device 500 includes a touch-sensitive display screen 504, hereafter touchscreen 504. Instead of, or in addition to, touchscreen 504, device 500 includes a display and a touch-sensitive surface. Similar to devices 100 and 300, in some embodiments, touchscreen 504 (or the touch-sensitive surface) may include one or more intensity sensors for detecting the intensity of an applied contact (e.g., a touch). The one or more intensity sensors in touchscreen 504 (or the touch-sensitive surface) can provide output data representing the intensity of the touch. The user interface of device 500 may respond to a touch based on the intensity of the touch, meaning that touches of different intensities may invoke different user interface actions on device 500.

[0155] Techniques for detecting and processing touch intensity can be found, for example, in related applications International Patent Application No. PCT / US2013 / 040061, filed May 8, 2013, entitled "Device, Method, and Graphical User Interface for Displaying User Interface Objects Corresponding to an Application," and International Patent Application No. PCT / US2013 / 069483, filed November 11, 2013, entitled "Device, Method, and Graphical User Interface for Transitioning Between Touch Input to Display Output Relationships," each of which is incorporated herein by reference in its entirety.

[0156] In some embodiments, device 500 has one or more input mechanisms 506 and 508. Input mechanisms 506 and 508, if included, can be physical. Examples of physical input mechanisms include push buttons and rotatable mechanisms. In some embodiments, device 500 has one or more attachment mechanisms. Such attachment mechanisms, if included, can allow device 500 to be attached to, for example, hats, eyewear, earrings, necklaces, shirts, jackets, bracelets, watch bands, chains, pants, belts, shoes, wallets, backpacks, etc. These attachment mechanisms allow a user to wear device 500.

[0157] FIG. 5B illustrates an exemplary personal electronic device 500. In some embodiments, device 500 may include some or all of the components described with respect to FIGS. 1A, 1B, and 3. Device 500 has a bus 512 operably coupling I / O unit 514 to one or more computer processors 516 and memory 518. I / O unit 514 may be connected to a display 504, which may have touch-sensing components 522 and, optionally, touch-intensity-sensing components 524. Additionally, I / O unit 514 may connect to a communication unit 530 for receiving application and operating system data using Wi-Fi, Bluetooth, near-field communication (NFC), cellular, and / or other wireless communication technologies. Device 500 may include input mechanisms 506 and / or 508. Input mechanism 506 may be, for example, a rotatable input device or a depressible and rotatable input device. Input mechanism 508 may, in some examples, be a button.

[0158] The input mechanism 508 may be a microphone in some embodiments. The personal electronic device 500 may include various sensors, such as a GPS sensor 532, an accelerometer 534, an orientation sensor 540 (e.g., a compass), a gyroscope 536, a motion sensor 538, and / or combinations thereof, all of which may be operably connected to the I / O section 514.

[0159] The memory 518 of the personal electronic device 500 may be a non-transitory computer-readable storage medium for storing computer-executable instructions that, when executed by one or more computer processors 516, may cause the computer processors to perform the techniques described above, including processes 1200-1500 (FIGS. 12-15). The computer-executable instructions may also be stored and / or transmitted to any non-transitory computer-readable storage medium used by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, a system including a processor, or other system that may fetch instructions from and execute the instructions from an instruction execution system, apparatus, or device. For purposes of this document, a "non-transitory computer-readable storage medium" may be any medium capable of tangibly containing or storing computer-executable instructions used by or in connection with an instruction execution system, apparatus, or device. Non-transitory computer-readable storage media may include, but are not limited to, magnetic, optical, and / or semiconductor storage devices. Examples of such storage devices include magnetic disks, optical disks based on CD, DVD, or Blu-ray technology, and persistent solid-state memory such as flash, solid-state drives, etc. Personal electronic device 500 is not limited to the components and configuration of Figure 5B and may include other or additional components in multiple configurations.

[0160] As used herein, the term "affordance" refers to a user-interactive graphical user interface object that may be displayed on the display screen of device 100, 300, and / or 500 (FIGS. 1, 3, and 5). For example, an image (e.g., an icon), a button, and text (e.g., a hyperlink) can each constitute an affordance.

[0161] As used herein, the term “focus selector” refers to an input element that indicates the current portion of a user interface with which a user is interacting. In some implementations involving a cursor or other position marker, when input (e.g., a press input) is detected on a touch-sensitive surface (e.g., touchpad 355 of FIG. 3 or touch-sensitive surface 451 of FIG. 4B ) and the cursor is over a particular user interface element (e.g., a button, window, slider, or other user interface element), the cursor acts as a “focus selector,” and the particular user interface element is adjusted according to the detected input. In some implementations involving a touchscreen display (e.g., touch-sensitive display system 112 of FIG. 1A or touchscreen 112 of FIG. 4A ) that allows direct interaction with user interface elements on the touchscreen display, contact detected on the touchscreen acts as a “focus selector,” such that when input (e.g., a press input by contact) is detected at the location of a particular user interface element (e.g., a button, window, slider, or other user interface element) on the touchscreen display, the particular user interface element is adjusted according to the detected input. In some implementations, focus is moved from one region of the user interface to another region of the user interface (e.g., by using the tab or arrow keys to move focus from one button to another) without a corresponding cursor movement or contact movement on the touchscreen display. In these implementations, the focus selector moves to follow the movement of focus between different regions of the user interface. Regardless of the specific form the focus selector takes, the focus selector is generally a user interface element (or a contact on a touchscreen display) that is controlled by the user to communicate the user's intended interaction with the user interface (e.g., by indicating to the device the element of the user interface that the user intends to interact with).For example, when a pressure input is detected on a touch-sensitive surface (e.g., a touchpad or touchscreen), the position of the focus selector (e.g., a cursor, touch, or selection box) over the corresponding button signals that the user is about to activate the corresponding button (as opposed to other user interface elements shown on the device's display).

[0162] As used herein and in the claims, the term "characteristic intensity" of a contact refers to a characteristic of that contact based on one or more intensities of the contact. In some embodiments, the characteristic intensity is based on a plurality of intensity samples. The characteristic intensity is optionally based on a predetermined number of intensity samples or a set of intensity samples collected within a predetermined time period (e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds) relative to a predetermined event (e.g., after detecting the contact, before detecting lift-off of the contact, before or after detecting the start of contact movement, before detecting the end of the contact, before or after detecting an increase in the intensity of the contact, and / or before or after detecting a decrease in the intensity of the contact). The characteristic intensity of the contact is optionally based on one or more of the maximum intensity of the contact, the mean value of the intensity of the contact, the average value of the intensity of the contact, the top 10% of the intensity of the contact, half the maximum intensity of the contact, 90% of the maximum intensity of the contact, etc. In some embodiments, the duration of the contact is used to determine the characteristic intensity (e.g., when the characteristic intensity is an average of the intensity of the contact over time). In some embodiments, the characteristic intensity is compared to a set of one or more intensity thresholds to determine whether an action is performed by the user. For example, the set of one or more intensity thresholds may include a first intensity threshold and a second intensity threshold. In this example, a contact having a characteristic intensity that does not exceed the first threshold results in a first action being performed, a contact having a characteristic intensity that exceeds the first intensity threshold but does not exceed the second intensity threshold results in a second action being performed, and a contact having a characteristic intensity that exceeds the second threshold results in a third action being performed. In some embodiments, the comparison between the characteristic intensity and one or more thresholds is not used to determine whether to perform the first or second action, but rather to determine whether to perform one or more actions (e.g., whether to perform each action or to forgo performing each action).

[0163] In some embodiments, a portion of a gesture is identified for purposes of determining the characteristic intensity. For example, a touch-sensitive surface may receive successive swipe contacts that transition from a start position to an end position, where the intensity of the contact increases. In this example, the characteristic intensity of the contact at the end position may be based on only a portion of the swipe contact (e.g., only the portion of the swipe contact at the end position) rather than the entire successive swipe contact. In some embodiments, a smoothing algorithm may be applied to the intensity of the swipe contact before determining the characteristic intensity of the contact. For example, the smoothing algorithm optionally includes one or more of an unweighted moving average smoothing algorithm, a triangular smoothing algorithm, a median filter smoothing algorithm, and / or an exponential smoothing algorithm. In some situations, these smoothing algorithms exclude small increases or decreases in the intensity of the swipe contact for purposes of determining the characteristic intensity.

[0164] The intensity of a contact on the touch-sensitive surface may be characterized relative to one or more intensity thresholds, such as a contact-detection intensity threshold, a light pressure intensity threshold, a deep pressure intensity threshold, and / or one or more other intensity thresholds. In some embodiments, the light pressure intensity threshold corresponds to an intensity that causes the device to perform an action typically associated with a physical mouse button or a trackpad click. In some embodiments, the deep pressure intensity threshold corresponds to an intensity that causes the device to perform an action different from an action typically associated with a physical mouse button or a trackpad click. In some embodiments, if a contact is detected with a characteristic intensity below the light pressure intensity threshold (e.g., and above a slight contact-detection intensity threshold below which the contact is no longer detected), the device moves a focus selector in accordance with the movement of the contact on the touch-sensitive surface without performing an action associated with the light pressure intensity threshold or the deep pressure intensity threshold. Generally, unless otherwise specified, these intensity thresholds are consistent across different sets of user interface diagrams.

[0165] An increase in the characteristic intensity of the contact from an intensity below the light pressure intensity threshold to an intensity between the light pressure intensity threshold and the deep pressure intensity threshold may be referred to as a "light press" input. An increase in the characteristic intensity of the contact from an intensity below the deep pressure intensity threshold to an intensity above the deep pressure intensity threshold may be referred to as a "deep press" input. An increase in the characteristic intensity of the contact from an intensity below the contact-detection intensity threshold to an intensity between the contact-detection intensity threshold and the light pressure intensity threshold may be referred to as detecting a contact on the touch surface. A decrease in the characteristic intensity of the contact from an intensity above the contact-detection intensity threshold to an intensity below the contact-detection intensity threshold may be referred to as detecting lift-off of the contact from the touch surface. In some embodiments, the contact-detection intensity threshold is zero. In some embodiments, the contact-detection intensity threshold is greater than zero.

[0166] In some embodiments described herein, one or more actions are performed in response to detecting a gesture including the respective pressure input or in response to detecting a respective pressure input performed on the respective contact (or contacts), where the respective pressure input is detected at least in part based on detecting an increase in intensity of the contact (or contacts) above a pressure input intensity threshold. In some embodiments, the respective actions are performed in response to detecting an increase in intensity of the corresponding contact (e.g., a “downstroke” of the corresponding pressure input) above a pressure input intensity threshold. In some embodiments, the pressure input includes an increase in intensity of the corresponding contact above a pressure input intensity threshold and a subsequent decrease in intensity of the contact below the pressure input intensity threshold, and the corresponding action is performed in response to detecting a subsequent decrease in intensity of the corresponding contact below the pressure input threshold (e.g., an “upstroke” of the corresponding pressure input).

[0167] In some embodiments, the device employs intensity hysteresis to avoid accidental inputs, sometimes referred to as “jitter,” and the device defines or selects a hysteresis intensity threshold that has a predetermined relationship to the pressure input intensity threshold (e.g., the hysteresis intensity threshold is X intensity units below the pressure input intensity threshold, or the hysteresis intensity threshold is 75%, 90%, or some reasonable percentage of the pressure input intensity threshold). Thus, in some embodiments, the pressure input includes a corresponding increase in the intensity of the contact above the pressure input intensity threshold and a subsequent decrease in the intensity of the contact below a hysteresis intensity threshold that corresponds to the pressure input intensity threshold, and a corresponding action is performed in response to detecting a subsequent decrease in the intensity of the corresponding contact below the hysteresis intensity threshold (e.g., an “upstroke” of the corresponding pressure input). Similarly, in some embodiments, a pressure input is detected only when the device detects an increase in the intensity of the contact from an intensity below the hysteresis intensity threshold to an intensity above the pressure input intensity threshold, and optionally a subsequent decrease in the intensity of the contact to an intensity below the hysteresis intensity, and a corresponding action is performed in response to detecting the pressure input (e.g., an increase in the intensity of the contact or a decrease in the intensity of the contact, as the case may be).

[0168] For ease of explanation, descriptions of actions performed in response to a pressure input associated with a pressure input intensity threshold or in response to a gesture including that pressure input are optionally triggered in response to detecting any of: an increase in the intensity of the contact above the pressure input intensity threshold, an increase in the intensity of the contact from an intensity below a hysteresis intensity threshold to an intensity above the pressure input intensity threshold, a decrease in the intensity of the contact below the pressure input intensity threshold, and / or a decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to the pressure input intensity threshold. Additionally, in examples described as performing an action in response to detecting a decrease in the intensity of the contact below a pressure input intensity threshold, the action is optionally performed in response to detecting a decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to and lower than the pressure input intensity threshold.

[0169] As used herein, an "installed application" refers to a software application that has been downloaded to an electronic device (e.g., device 100, 300, and / or 500) and is ready to be launched (e.g., opened) on that device. In some embodiments, a downloaded application becomes an installed application by an installation program that extracts program portions from a downloaded package and integrates the extracted portions with the computer system's operating system.

[0170] As used herein, the terms "open application" or "running application" refer to a software application for which state information is maintained (e.g., as part of device / global internal state 157 and / or application internal state 192). An open or running application can be any one of the following types of applications: ● The active application currently displayed on the display screen of the device on which the application is being used; Background applications (or background processes) that are not currently displayed, but whose associated processes are being processed by one or more processors. A suspended or hibernated application that is not running but has state information stored in memory (volatile and / or non-volatile, respectively) that can be used to resume execution of that application.

[0171] As used herein, the term "closed application" refers to a software application for which no state information is maintained (e.g., no state information about the closed application is stored in the device's memory). Thus, closing an application includes stopping and / or removing the application process for that application and removing state information about that application from the device's memory. Generally, opening a second application while a first application is running does not close the first application. Once the second application is displayed and the first application is no longer displayed, the first application becomes a background application.

[0172] Attention is now directed to user interfaces (“UIs”) and related processes that may be implemented on multifunction devices with displays and touch-sensitive surfaces, such as devices 100, 300, and / or 500, to provide automatic unlock functionality. 1. User interface lock and unlock state

[0173] 6A shows exemplary electronic devices 600, 602, and 604. In some embodiments, device 600 may be device 100 (FIG. 1A). In the illustrated example, device 600 is a phone. In some embodiments, device 602 may be device 300 (FIG. 3A). In the illustrated example, device 602 is a laptop computer. In some embodiments, device 604 may be device 500 (FIG. 5A). In the illustrated example, device 604 is a wearable electronic device.

[0174] Devices 600, 602, and 604 can have a user interface locked state and a user interface unlocked state, respectively. In the user interface locked state (hereinafter referred to as the "locked state"), a device such as device 600, 602, or 604 is powered on and operational, but ignores most, if not all, user input. That is, the device does not take any action in response to user input and / or is prevented from performing a predefined set of operations in response to user input. This predefined set of operations may include navigation through the user interface and activation or deactivation of a predefined set of functions. This locked state can be used to prevent unintended or unauthorized use of the device or activation or deactivation of functions on the device. The device can enter the locked state in response to a user instruction. The device can also enter the locked state after an idle period, which the user can specify as a configuration setting. When a device is in the locked state, the device can be said to be locked. As shown in the figure, devices 600, 602, and 604 are locked.

[0175] In some embodiments, a device in a locked state may still respond to a limited set of user inputs, including inputs corresponding to attempts to transition the device to a user interface unlocked state or inputs corresponding to powering off the device. In other words, a locked device responds to user inputs corresponding to attempts to transition the device to a user interface unlocked state or power off the device, but does not respond to user inputs corresponding to attempts to navigate through the user interface. Also, even if a device ignores user input, the device may still provide sensory feedback (such as visual, auditory, or vibration feedback) to the user upon detecting the input to indicate that the input is being ignored.

[0176] In a user interface unlocked state (hereinafter referred to as the "unlocked state"), the device is in a normal operating state and detects and responds to user input corresponding to interactions with the user interface. A device in the unlocked state can be said to be unlocked. A device in the unlocked state detects and responds to user input such as navigating between user interfaces, entering data, and activating or deactivating features. In embodiments where the device includes a touch-sensitive input mechanism, a device in the unlocked state detects and responds to contacts corresponding to navigation between user interfaces, entering data, and activating or deactivating features via the touch-sensitive input mechanism. In embodiments where the device includes a rotatable input mechanism, a device in the unlocked state detects and responds to rotations and / or presses corresponding to navigation between user interfaces, entering data, and activating or deactivating features via the rotatable input mechanism.

[0177] 6B shows a user 606 using multiple electronic devices, including devices 600, 602, and 604. Each of these devices may be locked. To use a particular device, user 606 may first need to unlock it. As mentioned above, this process can be cumbersome, especially if the device is configured to automatically lock after a period of inactivity.

[0178] 6C illustrates an exemplary situation in which it is desirable to use an authenticated device to unlock another electronic device. As shown, user 606 is preparing to use device 602, which is a laptop. Device 602 may be configured to be powered on and locked. However, user 606 may be interacting with device 600 or 604, meaning that device 600 and / or 604 are still unlocked. Devices 600 and 604 are also within physical proximity (e.g., wireless communication range) of device 602. In this situation, it is useful for either device 600 or 604 to provide credentials to device 602 so that device 602 requires minimal or no user input to unlock, thereby permitting user 606 to begin productive work on the device.

[0179] 6D-6F, attention is now directed to techniques for unlocking a device 602 using device(s) 600 and 604 in an unlocked state. FIG. 6D shows the device 602 displaying a user interface lock screen 608 indicating that the device is locked. In this state, the device 602 receives a password entry in a password entry field 610 to unlock the device. However, it would be useful if the user 606 could access the device 602 without having to manually enter a password. As shown in FIG. 6E, an external device 604 may be within communication range of the device 602. The device 602 can detect the presence of the device 604 via a wireless communication protocol. Low-power wireless communication may be particularly suitable for this purpose. Examples of suitable wireless communication include Bluetooth® and Bluetooth Low Energy (BTLE). Similarly, the device 604 can detect nearby devices 602.

[0180] As shown, external device 604 is in an unlocked state (e.g., normal operating mode), likely due to recent use by user 606 (FIG. 6C). After detection, device 604 can transmit information to device 602 to facilitate unlocking device 602, such as, for example, the user's credentials. Assuming device 602 trusts device 604, device 602 can use the received credential information to facilitate its unlocking process.

[0181] In some embodiments, device 602 may unlock upon receiving the credential information and further upon detecting user input. The user input may be mouse input, such as a mouse movement or a mouse click. The user input may be touch input, such as a tap or swipe. The user input may be a depression of a mechanical or capacitive input mechanism. In the illustrated example, upon receiving the unlock information from device 604, device 602 replaces password entry field 610 (FIG. 6D) with affordance 612, which, when selected (e.g., clicked), unlocks device 602. Note that in embodiments requiring detection of user input before unlocking, simply placing devices (e.g., 604 and 602) in physical proximity should not be considered detected user input.

[0182] In some embodiments, upon receiving the credential from device 604, device 602 may automatically unlock without requiring further user input. In some embodiments, upon receiving the credential information from device 604, device 602 may unlock after detecting a valid biometric read from a biometric input device. In these embodiments, the further biometric read may be used to form a two-factor authentication process.

[0183] 6F shows device 602 in an unlocked state. In this state, device 602 may display a desktop screen 614 with affordances for launching various application programs (e.g., an icon 616 for launching a messaging application). Optionally, device 604 may display a visual indicator 616 and / or haptic feedback that indicates that device 604 has effected unlocking device 602.

[0184] It should be noted that while FIGS. 6D-6F illustrate the unlocking of device 602 by external device 604, the described techniques can be extended to encompass other devices, such as devices 100, 300, and 500 (FIGS. 1A, 3A, and 5A). That is, various electronic devices serving as locks and keys can be interchanged. For example, in some embodiments, device 100 (FIG. 1A) can serve as an authentication device for unlocking device 500 (FIG. 5A), as described below with reference to FIGS. 7A-7E. For example, in some embodiments, device 500 (FIG. 5A) can serve as an authentication device for unlocking device 100 (FIG. 1A), as described below with reference to FIGS. 8A-8C. For the sake of brevity, other permutations, while possible, will not be explicitly discussed herein.

[0185] 7A-7E, attention is now directed to additional techniques for unlocking another electronic device using an authenticated device. FIG. 7A illustrates an exemplary device 700, which in some embodiments may be device 500 (FIG. 5A). Device 700 may include a display screen that turns off under certain circumstances. For example, the display screen may turn off after a predetermined idle period. The display screen of device 700 may be turned back on in response to movement and / or user input. When the display screen of device 700 turns on, it may display a lock screen 702 indicating that device 700 is locked. Lock screen 702 may prompt the user for a password to unlock the device.

[0186] 7B illustrates the presence of an external device 704 within wireless communication range of device 700. In some embodiments, device 704 may be device 100 (FIG. 1A). External device 704 may also be in a locked state, as indicated by lock screen 706. Lock screen 706 may have instructions 708 indicating how device 704 can be unlocked. Because device 704 itself is locked, device 700 does not respond by automatically unlocking.

[0187] Figure 7C shows a user input 710 representing a user attempt to unlock the device 704. As shown, the device 700 remains locked while the attempt is made to unlock the device 704. Figure 7D shows a further user input 712 representing the user's continued attempts to unlock the device 704. The device 700 continues to maintain its locked state.

[0188] Referring to FIG. 7E, upon receiving a valid passcode via user input 712 (FIG. 7D), device 704 unlocks and enters a normal operating state. As shown, device 704 is running an active application 714. Application 714 may be a messaging application, such as Messages from Apple Inc., Cupertino, California. After unlocking, device 704 may also transmit information to device 700, including information that facilitates automatic unlocking of device 700.

[0189] 7F, upon receiving this information, device 700 automatically unlocks without further user input and displays clock screen 716. In some embodiments, device 700 can unlock upon receiving the credential information and detecting user input. The user input can be movement of device 700. The user input can be touch input, such as a tap or swipe. The user input can be a depression of a mechanical or capacitive input mechanism.

[0190] 8A-8C, attention is now directed to additional techniques for unlocking another electronic device using an authenticated device. FIG. 8A illustrates an exemplary device 800, which in some embodiments may be device 100 (FIG. 1A). Device 800 may include a display screen that turns off under certain circumstances. For example, the display screen may turn off after an idle period. The display screen of device 800 may be turned back on in response to movement and / or user input. When the display screen of device 800 turns on, it may display a lock screen 802 indicating that device 800 is locked. Lock screen 802 may include instructions 804 indicating how to unlock device 800.

[0191] FIG. 8B illustrates the presence of an external device 806 within wireless communication range of device 800. In some embodiments, device 806 may be device 500 (FIG. 5A). Device 806 may have been used recently by a user (e.g., within the last 5-20 seconds) and may therefore be unlocked. Device 806 may transmit information to device 800 that facilitates automatic unlocking of device 800. As shown in FIG. 8C, upon receiving this information, device 800 may automatically unlock without further user input, thereby replacing lock screen 802 (FIG. 8B) with a menu 808 having various application icons. In some embodiments, device 800 may require some user input (e.g., a substantially horizontal swipe) before unlocking. 2. Application state continuity across devices

[0192] When a user switches between different devices, it would be useful for the user to be able to automatically unlock the device and switch content displayed on one device onto another device. Co-pending U.S. Provisional Application No. 62 / 035,348, filed August 8, 2014, entitled "CONTINUITY," which is incorporated herein in its entirety, describes application continuity across multiple electronic devices. It describes how a user working on an application on one device can transfer their work to a nearby device within wireless communication range.

[0193] Continuity aspects can be incorporated into the above user interfaces to unlock other devices using an authenticated device. For example, when the target device automatically unlocks, it may be desirable to launch the same application on the target device that is running on the authenticated external device. It may also be desirable for the application to have the same application state upon launch (e.g., display the same information that was displayed on the authenticated external device).

[0194] These features are described with reference to Figures 9A and 9B. As shown in Figure 9A, device 900 (which in some embodiments may be device 100 of Figure 1A) and device 902 (which in some embodiments may be device 500 of Figure 5A) are within wireless communication range. As shown, device 900 is locked and device 902 is unlocked. Device 902 may be displaying a message record 906 with an active messaging application. Device 902 may send information to device 900 to facilitate unlocking device 900. In addition to user credentials, this information may include an identification of an application (e.g., a messaging application) that is active on device 902 and / or application state information (e.g., message record 906).

[0195] Device 900 may be configured to require a password before unlocking. However, upon receiving unlock information from device 902, device 900 may unlock without requiring the entry of additional password information. Additionally, received application and / or application state information may enable device 900 to further provide continued functionality after unlocking.

[0196] In the illustrated embodiment, in response to the transmitted information, device 900 may display affordance 904 indicating that a corresponding (messaging) application will be launched after unlocking device 900. Additionally, affordance 904 may have a visual indication identifying the application (e.g., messaging) that will be launched when device 900 is unlocked. As shown in FIG. 9B , upon unlocking, device 900 may launch the corresponding messaging application and display the same message records 906 that are displayed on device 902. The amount of message records 906 displayed on devices 900 and 902 may vary depending on the form factor of the devices (e.g., the size and resolution of the display screen).

[0197] In some embodiments (not shown), instead of affordance 904, device 900 can display an instruction on lock screen 908 indicating that a messaging application will be launched if the user proceeds to unlock device 900. For example, device 900 can display the instruction "Slide to open Messages." In some embodiments (not shown), in response to the transmitted information, device 900 allows for unlocking with a single depression of its mechanical input mechanism 910 and launches a corresponding application (e.g., Messages) upon unlocking. In some embodiments (not shown), in response to information transmitted from device 902, device 900 can simply unlock and launch a corresponding application without requiring further user input.

[0198] In some embodiments, device 900 may allow a user to unlock the device without necessarily invoking a continuity function. Whether device 900 invokes the continuity function may depend on the user input used to unlock device 900. For example, device 900 may launch a corresponding application if the user taps affordance 904 but not launch an application if the user taps mechanical input mechanism 910 to unlock. Instead, when the user taps button 910, device 900 may unlock and display the most recently used application on device 900. 3. Certified Devices

[0199] For privacy reasons, it is useful for electronic devices to unlock each other in various situations, but care may be needed in controlling which electronic devices can facilitate automatic unlocking of other devices. In other words, it may be necessary to determine which electronic devices should be authenticated for purposes of the automatic unlock feature. Attention is now directed to user interfaces for authenticating devices for purposes of automatic unlocking, such as devices 100, 300, and 500 (FIGS. 1A, 3A, and 5A).

[0200] In some embodiments, the device may prompt the user as to whether a nearby external device should be authenticated (meaning whether the external device should be able to unlock the device). This aspect is described with reference to FIGS. 10A-10D. FIG. 10A shows a device 1000, which may be device 300 (FIG. 3A) in some embodiments. Device 1000 may display a lock screen 1002 indicating that it is locked. Lock screen 1002 may include a password entry field 1004 for unlocking device 1000.

[0201] FIG. 10B illustrates the presence of an external device 1010 within wireless communication range of device 1000. External device 1010 can be any one of devices 100, 300, or 500 (FIGS. 1A, 3A, 5A). In the illustrated embodiment, external device 1010 is device 500 (FIG. 5A). External device 1010 is shown in an unlocked state and actively running a messaging application to display message records 1012. Device 1000 and external device 1010 can detect each other over wireless communication. External device 1010 can send information to device 1000 to facilitate unlocking device 1000.

[0202] In some embodiments, the device 1000 may refuse to automatically unlock based on the received information because it is not configured to trust the device 1010. In other words, from the perspective of the device 1000, the device 1010 is not an authenticated device. Thus, the device 1000 may continue to display the lock screen 1002. However, the user can manually unlock the device 1000 while the external device 1010 is still within range. For example, the user can unlock the device 1002 by entering a valid password in the password entry field 1004, as shown in FIG. 10B .

[0203] 10C , when a user manually unlocks device 1000 in the presence of an unlocked external device 1010, device 1000 may prompt the user to indicate whether device 1000 should become an authenticated device. That is, device 1000 may ask whether the external device 1010 should be allowed to automatically unlock device 1000 in the future when it again comes within communication range. This prompt may include identifying the external device 1010 by its make / model and / or its device name.

[0204] If the user responds affirmatively (e.g., by selecting affordance 1012), device 1000 can register external device 1010 as an authenticated device, meaning that external device 1010 becomes an authenticated device for purposes of automatic unlocking of device 1000. In other words, if external device 1010 comes within wireless communication range of device 1000 in the future and the external device 1010 is unlocked while device 1000 is locked, device 1010 will be allowed to unlock device 1000.

[0205] Additionally, in some embodiments, device 1000 may prompt the user to confirm the authentication of device 1002 by re-entering the user's password (for unlocking device 1000) on device 1000, as shown in Figure 10D. In this way, device 1002 will be able to automatically unlock device 1000 in the future.

[0206] If the user responds negatively (e.g., by selecting affordance 1014), device 1000 can store external device 1010 as an unauthenticated device. Thus, device 1000 can avoid automatically prompting the user to authenticate external device 1010 if the two devices begin wireless communication again in the future. Device 1000 can also avoid automatically unlocking device 1010 when it comes within wireless communication range in the future.

[0207] In some embodiments, a device may provide access to configuration settings that control whether certain external devices should be authorized for purposes of the auto-unlock feature. This aspect is described with reference to FIGS. 11A-11C. FIG. 11A shows a device 1100, which may be device 300 (FIG. 3A) in some embodiments. The device 1100 may be unlocked and displaying a desktop screen 1102. The desktop screen 1102 may have graphical user interface affordances for launching applications and other functions, such as icons 1104 for configuring device settings. Configurable settings may include settings that identify external electronic devices to facilitate auto-unlocking of the device 1100.

[0208] As shown in FIG. 11B , the device 1100 can display a list 1106 of external devices that can be authorized devices for purposes of automatically unlocking the device 1100. The devices that appear on the list 1106 can be determined by various techniques. In some embodiments, the device 1100 can be associated with a user identifier (e.g., an account or email address), and the device 1100 can generate the list 1106 to include other devices associated with the same user account. In some embodiments, the device 1100 can be a trusted member of a security domain, and the device 1100 can generate a list 1106 of external devices that are trusted members of the same security domain. In some embodiments, the device 1100 can connect to a security server or authentication server to determine whether two electronic devices are associated with each other. For example, the device 1100 can contact the server to obtain a list of devices that are trusted for a particular domain and / or registered for a given user identifier. In some embodiments, the device 1100 can generate the list 1106 based on the physical proximity of the external device. For example, list 1106 may list only devices that are currently within wireless communication distance via a low-power wireless communication protocol.

[0209] List 1106 may have check boxes next to the listed external devices that allow users to specify whether the corresponding external devices should be authenticated for purposes of facilitating automatic unlocking of device 1100. In the illustrated embodiment, device 1100 displays list 1106 with check boxes 1108 and 1110 corresponding to "phone" and "tablet" devices. The "phone" and "tablet" devices, and device 1100, may each be associated with the same user identifier on a cloud-based service, such as iCloud® by Apple Inc. of Cupertino, California.

[0210] 11C illustrates possible responses of device 1100 to a user's selection of checkbox 1110. In the illustrated example, device 1100 requires that a particular external device be within communication range of device 1110 at the time of authentication for purposes of the auto-unlock feature. In the illustrated example, the user's tablet computer is out of communication range with device 1100. Therefore, device 1100 displays message 1112 indicating that the tablet cannot be authenticated for purposes of the auto-unlock feature.

[0211] 11D and 11E illustrate possible responses by the device 1100 to a user's selection of a checkbox 1108. In the illustrated embodiment, the checkbox 1108 represents the user's phone 1114 that is within communication range of the device 1100. In this case, the device 1100 can register the phone 1114 as an authenticated device, meaning that in the future, if the phone 1114 comes within wireless communication range of the device 1100 and the phone 1114 is unlocked, the phone 1114 will be allowed to unlock the device 1100. Referring to FIG. 11E, the device 1100 can further require the user to confirm the authenticity of the phone 1114 by having the user enter a password on the device 1100 to unlock the device 1100.

[0212] FIG. 12 is a flow diagram illustrating a process 1200 for unlocking an electronic device using an authenticated external device. Process 1200 may be performed by an electronic device, such as devices 100, 300, and / or 500 ( FIGS. 1A , 3A , 5A ), in various embodiments. At block 1202, the locked electronic device detects an external device via wireless communication. The electronic device may verify that the detected external device is authorized for purposes of the automatic unlock feature. At block 1204, the electronic device receives unlock information from the external device for unlocking the electronic device. The electronic device may verify that the received information is valid and authentic. At block 1206, the electronic device detects user input while in the locked state. At block 1208, in response to the received information and the detected user input, the device unlocks and enters a normal operating state. For example, in the unlocked state, the electronic device allows a user to launch an application. Optionally, at block 1210, the electronic device may launch the application immediately upon unlocking. The launched application may be the same as the application active on the external device. Optionally, upon launch, the application may enter the same application state as the application active on the external device. That is, for example, the newly launched application may retrieve and display on the electronic device the same web page or email that is displayed on the external device.

[0213] FIG. 13 is a flow diagram illustrating a process 1300 for unlocking an external electronic device using an electronic device. Process 1300 may be performed by an electronic device, such as devices 100, 300, and / or 500 ( FIGS. 1A , 3A , 5A ), in various embodiments. An electronic device having a user interface locked state and a user interface unlocked state may be in a user interface unlocked state. In block 1302, the electronic device can detect an external device via wireless communication. The external device also has a user interface locked state and a user interface unlocked state and is in a user interface locked state. In block 1304, the electronic device transmits unlock data to the external device, thereby causing the external device to unlock after receiving the unlock information and detecting a user input. Optionally, in block 1306, the electronic device can provide visual and / or tactile confirmation that the external device has been unlocked. This confirmation may be provided after the electronic device obtains confirmation that the external device has been unlocked.

[0214] 14 is a flow diagram illustrating a process 1400 for configuring an electronic device to recognize an external device as an authorized external device for purposes of an auto-unlock feature. Process 1400 may be performed by an electronic device, such as devices 100, 300, and / or 500 (FIGS. 1A, 3A, 5A), in various embodiments. At block 1402, an electronic device having a user interface locked state and a user interface unlocked state may detect an external device within its wireless communication range. At block 1404, the electronic device may determine whether the external device has previously been authorized for purposes of auto-unlocking the electronic device.

[0215] If the external device is an authorized device for purposes of automatic unlocking of the electronic device, the electronic device may proceed to auto-unlock, for example, via the user interfaces shown in Figures 5-7 and described above, and process 1200 (Figure 12). If the external device has previously been registered as an unauthorized device for the automatic unlock feature, the electronic device may remain locked and await other possible attempts to unlock (such as manually entering a password).

[0216] If the external device is not yet registered as either authenticated or unauthenticated, processing proceeds to block 1406, where the (locked) electronic device may receive user input representing credentials to unlock the electronic device. The electronic device may then verify the received credentials and unlock appropriately. At block 1408, after unlocking, the electronic device may display an identification of the external device indicating that the two devices are in physical proximity (e.g., within wireless communication range of a low-power communication protocol) and that the external device may be authenticated for purposes of the automatic unlock feature. At block 1410, the electronic device may prompt the user to specify whether the external device should be allowed to unlock the electronic device when it comes within wireless communication range of the electronic device while the electronic device is in the user interface locked state.

[0217] 15 illustrates exemplary functional blocks of an electronic device 1500 that, in some embodiments, implements the features described above. As shown in FIG. 15 , the electronic device 1500 may include a display unit 1502 configured to display graphical objects, a human input interface unit 1504 configured to receive user input, one or more RF units 1506 configured to detect and communicate with external electronic devices, one or more feedback units configured to provide tactile, audio, and / or visual feedback to a user, and a processing unit 1510 coupled to the display unit 1502, the human input interface unit 1504, the RF unit(s) 1506, and the feedback unit 1508. In some embodiments, the processing unit 1510 is configured to support an operating system running on an operating system unit 1512. The operating system unit 1512, in turn, may support an application unit 1514 for launching and running one or more applications.

[0218] In some embodiments, the processing unit 1510 includes a display enablement unit 1516 and a security unit 1518. In some embodiments, the display enablement unit 1516 is configured to display a user interface (or a portion of a user interface) in cooperation with the display unit 1502. For example, the display enablement unit 1516 may be used to display a lock screen, an unlock screen, a menu of application icons, a desktop screen, and a prompt that prompts the user to specify whether or not to authorize an external device for purposes of the auto-unlock feature.

[0219] In some embodiments, the RF unit 1506 is configured to detect and receive information from the external device, such as credential information, application information, application state information, etc., that facilitates unlocking of the receiving device. In some embodiments, the RF unit is configured to detect and transmit information to the external device, such as credential information, application information, application state information, etc., that facilitates unlocking of the receiving device.

[0220] In some embodiments, the security unit 1518 is configured to receive input, for example, through use of the human input interface unit 1504 and / or the RF unit 1506. For example, the security unit 1518 can determine whether information received from the RF unit 1506 represents an authenticated device that can be used to facilitate unlocking. The security unit 1518 may also determine whether information received from the human input interface unit 1504 is a valid set of credentials for unlocking the electronic device 1500. The security unit 1518 can decide whether to unlock the device 1500 based on the information received from the human input interface unit 1504 and / or the RF unit 1506. The security unit 1518 can also cause other units of the device 1500 to prompt the user as to whether an external device should be authenticated for purposes of the automatic unlock feature. The security unit 1518 can register the authenticated device, allowing the device 1500 to recognize the authenticated device.

[0221] The units in FIG. 15 may be used to implement the various techniques and methods described above with respect to FIGS. 6-14. The units of device 1500 are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various embodiments described. Those skilled in the art will understand that the functional blocks described in FIG. 15 may be optionally combined into sub-blocks or separated to realize the principles of the various embodiments described. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0222] According to some embodiments, FIG. 16 illustrates a functional block diagram of an electronic device 1600 configured according to the principles of various described embodiments. The functional blocks of the device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various described embodiments. Those skilled in the art will understand that the functional blocks described in FIG. 16 may be optionally combined into sub-blocks or separated to realize the principles of the various described embodiments. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0223] 16 , electronic device 1600 includes a display unit 1602 configured to display a graphical user interface, optionally a touch-sensitive surface unit 1604 configured to receive contacts, and a processing unit 1606 coupled to display unit 1602 and optionally touch-sensitive surface unit 1604. In some embodiments, processing unit 1606 includes a detecting unit 1608, a receiving unit 1610, an unlocking unit 1612, an obtaining unit 1614, a display enabling unit 1616, a prompt enabling unit 1618, an activating unit 1620, a calling unit 1622, and a sending unit 1624. Electronic device 1600 optionally has a user interface locked state and a user interface unlocked state.

[0224] The processing unit 1606 is configured to detect an external device via wireless communication (e.g., using the detection unit 1608), receive unlock information from the external device (e.g., using the receiving unit 1610) for unlocking the electronic device, detect a user input (e.g., using the detection unit 1608) while in the locked state, and unlock the electronic device (e.g., using the unlocking unit 1612) in response to detecting the user input and the received unlock information.

[0225] In some embodiments, the external device has a user interface locked state and a user interface unlocked state, and the processing unit 1606 is further configured to obtain (e.g., with the obtaining unit 1614) a notification that the external device is in the user interface unlocked state. Then, when the external device is in the user interface unlocked state, the processing unit 1606 unlocks the electronic device (e.g., with the unlocking unit 1612) in response to the received unlock information and the received user input.

[0226] In some embodiments, the processing unit 1606 is further configured to enable (e.g., using the display enabling unit 1616) the display of a visual notification indicating that the electronic device is in a user interface unlocked state after unlocking the electronic device.

[0227] In some embodiments, the external device displays a visual notification indicating that the electronic device is in a user interface unlocked state after the electronic device unlocks.

[0228] In some embodiments, after the electronic device unlocks, the external device generates a haptic event that indicates that the electronic device is in a user interface unlocked state.

[0229] In some embodiments, the processing unit 1606 is further configured to receive (e.g., with the receiving unit 1610) input data representing a user input of a password while in the user interface locked state, and, in response to receiving the input data, enable (e.g., with the prompt enabling unit 1618) on a display of the electronic device to prompt the user to specify whether or not to allow an external device to unlock the electronic device.

[0230] In some embodiments, the input data includes readings from a biosensor of the electronic device and / or a biosensor of an external device.

[0231] In some embodiments, the input data includes a touch on a touch-sensitive input of the electronic device.

[0232] In some embodiments, the input data includes movements of a mouse coupled to the electronic device and / or a mouse coupled to an external device.

[0233] In some embodiments, the user input comprises keystrokes on a keyboard of the electronic device.

[0234] In some embodiments, the processing unit 1606 is further configured to receive, from the external device, usage information indicating use of a first application on the external device, and, after unlocking, launch, on the electronic device, a second application corresponding to the first application.

[0235] In some embodiments, launching the second application includes invoking a state within the second application on the electronic device.

[0236] In some embodiments, the detected user input is a user input on an electronic device.

[0237] In some embodiments, the unlocking information includes identification data based on an email address associated with the electronic device, and the processing unit 1606 is further configured to unlock the electronic device (e.g., with the unlocking unit 1612) in response to the received unlocking information and the received user input if the external device is associated with the email address associated with the electronic device.

[0238] In some embodiments, the unlocking information includes identification data that identifies the external device, and the processing unit 1606 is further configured to transmit at least a portion of the identification data to an authentication server (e.g., using the transmitting unit 1624), receive a notification from the authentication server (e.g., using the receiving unit 1610) of whether the external device is authorized to unlock the electronic device, and, if the external device is authorized, unlock the electronic device (e.g., using the unlocking unit 1612) in response to the received unlocking information and the received user input.

[0239] In some embodiments, the unlocking information includes an identification of a security domain associated with the external device, and the processing unit 1606 is further configured to unlock the electronic device (e.g., with the unlocking unit 1612) in response to the received unlocking information and the received user input if the electronic device is associated with the same security domain.

[0240] In some embodiments, the processing unit 1606 is further configured to detect external devices (eg, using the detection unit 1608) via peer-to-peer wireless communication.

[0241] In some embodiments, the wireless communication includes Bluetooth communication.

[0242] In some embodiments, the external device is a wearable electronic device.

[0243] 1A-1B or 16. For example, detect operations 1202 and 1206, receive operation 1204, and unlock operations 1208 and 1210 are optionally implemented by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 delivers the event information to application 136-1. Corresponding event recognizer 180 of application 136-1 consults the event information against corresponding event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface (or rotation of the device) corresponds to a predefined event or sub-event, such as selecting an object on a user interface or rotating the device from one orientation to another. When a corresponding predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally uses or invokes data updater 176 or object updater 177 to update application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in FIGS. 1A-1B.

[0244] According to some embodiments, FIG. 17 illustrates a functional block diagram of an electronic device 1700 configured according to the principles of various described embodiments. The functional blocks of the device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various described embodiments. Those skilled in the art will understand that the functional blocks described in FIG. 17 may be optionally combined or separated into sub-blocks to realize the principles of the various described embodiments. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0245] 17, electronic device 1700 includes a display unit 1702 configured to display a graphical user interface, optionally a touch-sensitive surface unit 1704 configured to receive contacts, and a processing unit 1706 coupled to display unit 1702 and optionally touch-sensitive surface unit 1704. In some embodiments, processing unit 1706 includes a detecting unit 1708, a transmitting unit 1710, a display enabling unit 1712, a causing unit 1714, and a sending unit 1716. Electronic device 1700 optionally has a user interface locked state and a user interface unlocked state, and may be in the user interface unlocked state.

[0246] The processing unit 1706 has a user interface locked state and a user interface unlocked state, and is configured to detect (for example, by using the detecting unit 1708) an external device in the user interface locked state via wireless communication, and send unlocking data to the external device (for example, by using the sending unit 1710). The external device unlocks after the external device receives the unlocking information and detects the user input.

[0247] In some embodiments, the processing unit 1706 is further configured to enable (e.g., using the display enabling unit 1712) the display of a visual notification on the electronic device after the external device has unlocked, indicating that the external device is in a user interface unlocked state.

[0248] In some embodiments, the processing unit 1706 is further configured to, after the external device unlocks, cause (e.g., using the triggering unit 1714) a haptic event on the electronic device indicating that the external device is in a user interface unlocked state.

[0249] In some embodiments, after the external device unlocks, the external device displays a visual notification that the external device is in an unlocked state of the user interface.

[0250] In some embodiments, the detected user input is a reading from a biosensor of the external device and / or a biosensor of the electronic device.

[0251] In some embodiments, the detected user input is a touch on a touch-sensitive input of an external device.

[0252] In some embodiments, the detected user input is a mouse coupled to an external device and / or movement of a mouse coupled to the electronic device.

[0253] In some embodiments, the detected user input is a keystroke on a keyboard of the external device.

[0254] In some embodiments, the detected user input is an input on an external device.

[0255] In some embodiments, the processing unit 1706 is executing a first application, and the processing unit 1706 is further configured to send (e.g., with the sending unit 1716) usage information indicating use of the first application on the electronic device to the external device, the usage information at least in part causing the external device to display an affordance for unlocking and launching a second application on the external device, the second application corresponding to the first application.

[0256] In some embodiments, the usage information indicates a state of the first application that is invoked in the second application when the second application is launched on the external device.

[0257] In some embodiments, the electronic device is associated with an email address, and the external device unlocks after verifying that it is associated with the same email address as the email address associated with the electronic device.

[0258] In some embodiments, an association between the electronic device and the external device is stored in an authentication server, and the external device unlocks after verifying the association with the authentication server.

[0259] In some embodiments, the electronic device is associated with a security domain and the external device unlocks after verifying that it is associated with the same security domain as the security domain associated with the electronic device.

[0260] In some embodiments, the processing unit 1706 is further configured to detect external devices (eg, using the detection unit 1708) via peer-to-peer wireless communication.

[0261] In some embodiments, the wireless communication includes Bluetooth communication.

[0262] In some embodiments, the electronic device is a wearable electronic device.

[0263] 1A-1B or 17. For example, detect operation 1302, send operation 1304, and receive operation 1306 are optionally implemented by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 delivers the event information to application 136-1. Corresponding event recognizer 180 of application 136-1 consults the event information with corresponding event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface (or rotation of the device) corresponds to a predefined event or sub-event, such as selecting an object on a user interface or rotating the device from one orientation to another. When a corresponding predefined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally uses or invokes data updater 176 or object updater 177 to update application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0264] According to some embodiments, Figure 18 illustrates a functional block diagram of an electronic device 1800 configured in accordance with the principles of the various described embodiments. The functional blocks of this device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various described embodiments. Those skilled in the art will understand that the functional blocks described in Figure 18 may optionally be combined or separated into sub-blocks to carry out the principles of the various described embodiments. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0265] 18 , electronic device 1800 includes a display unit 1802 configured to display a graphical user interface, optionally a touch-sensitive surface unit 1804 configured to receive contacts, and a processing unit 1806 coupled to display unit 1802 and optionally touch-sensitive surface unit 1804. In some embodiments, processing unit 1806 includes a receiving unit 1808, an unlocking unit 1810, a display enabling unit 1812, a prompt enabling unit 1814, a locking unit 1816, a detecting unit 1818, and a triggering unit 1820. Electronic device 1800 optionally has a user interface locked state and a user interface unlocked state, and may be within wireless communication range of an external device.

[0266] The processing unit 1806 is configured to receive (e.g., using the receiving unit 1808) user input representing credentials for unlocking the electronic device while in the user interface locked state, and in response to determining that the credentials are valid, unlock the electronic device (e.g., using the unlocking unit 1810), and after unlocking, enable a display unit of the electronic device to display (e.g., using the display enabling unit 1812) an identification of the external device, and enable a user to specify whether or not the external device is allowed to unlock the electronic device when the external device comes within wireless communication range of the electronic device while the electronic device is in the user interface locked state (e.g., using the prompt enabling unit 1814).

[0267] In some embodiments, if the external device is in a user interface unlocked state when the external device comes into wireless communication range with the electronic device, the external device causes the electronic device to unlock.

[0268] In some embodiments, the user input is a first user input, and the processing unit 1806 is further configured to lock the electronic device (e.g., with the lock unit 1816), detect a second user input at the electronic device (e.g., with the detection unit 1818) while the electronic device is in the user interface lock state and the external device is within communication range, and unlock the electronic device (e.g., with the unlock unit 1810) in response to detecting the second user input.

[0269] In some embodiments, the processing unit 1806 is further configured to enable (e.g., using the display enabling unit 1812) the display of a visual notification on the electronic device indicating that the electronic device is in a user interface unlocked state after the external device has unlocked.

[0270] In some embodiments, the processing unit 1806 is further configured to, after the electronic device unlocks, enable (e.g., using the display enabling unit 1812) the display of a visual notification on the external device indicating that the electronic device is in a user interface unlocked state.

[0271] In some embodiments, the processing unit 1806 is further configured to, after the electronic device unlocks, cause (e.g., using the triggering unit 1820) a haptic event on the external device indicating that the electronic device is in a user interface unlocked state.

[0272] In some embodiments, receiving user input representing credentials to unlock the electronic device includes obtaining a reading from a biometric sensor of the electronic device.

[0273] In some embodiments, receiving user input representing credentials for unlocking the electronic device includes detecting a touch to a touch-sensitive input of the electronic device.

[0274] In some embodiments, receiving user input representing credentials to unlock the electronic device includes detecting mouse motion of a mouse coupled to the electronic device.

[0275] In some embodiments, receiving user input representing credentials to unlock the electronic device includes detecting keystrokes on a keyboard of the electronic device.

[0276] In some embodiments, the processing unit 1806 is further configured to detect external devices via peer-to-peer wireless communication (eg, using the detection unit 1818).

[0277] In some embodiments, the wireless communication includes Bluetooth communication.

[0278] In some embodiments, the external device is a wearable electronic device.

[0279] 1A-1B or 18. For example, one or more of the operations described with reference to FIG. 14, including detect operation 1402, determine operation 1404, receive operation 1406, and display operations 1408 and 1410, are optionally implemented by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 delivers the event information to application 136-1. Corresponding event recognizer 180 of application 136-1 consults corresponding event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface (or rotation of the device) corresponds to a predefined event or sub-event, such as selecting an object on a user interface or rotating the device from one orientation to another. When a corresponding predefined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally uses or invokes data updater 176 or object updater 177 to update application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in FIGS. 1A-1B.

[0280] The foregoing description has been described with reference to specific embodiments for purposes of explanation. However, the illustrative description above is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. These embodiments were chosen and described in order to best explain the principles of the technology and its practical application. Those skilled in the art will be able to best utilize the technology and various embodiments with various modifications tailored to the particular use intended.

[0281] Although the present disclosure and examples have been fully described with reference to the accompanying drawings, it should be noted that various changes and modifications will become apparent to those skilled in the art, and such changes and modifications are to be understood as being included within the scope of the present disclosure and examples, as defined by the appended claims.

Claims

1. 1. A method comprising: a first electronic device having a display, Detecting a selection of a user interface object corresponding to a first external electronic device from the one or more external devices; In response to detecting the selection of the user interface object corresponding to the first external electronic device, displaying a screen via the display for providing authentication information; and while displaying the screen for providing the authentication information, requesting authentication information from a user to enable the first electronic device to transition from a locked state to an unlocked state based on the presence of the first external electronic device.

2. 10. The method of claim 1, further comprising: detecting a selection of a user interface object corresponding to a second external electronic device from the one or more external devices; in response to detecting the selection of the user interface object corresponding to the second external electronic device; displaying a screen for providing the authentication information to enable the first electronic device to transition from the locked state to an unlocked state based on the presence of the second external electronic device according to determining that the second external electronic device is within a predetermined distance of the first electronic device; and providing, in accordance with a determination that the second external electronic device is not within the predetermined distance of the first electronic device, an indication that the second external electronic device cannot be authenticated to allow the first electronic device to transition from the locked state to the unlocked state based on the presence of the second external electronic device.

3. The method of claim 1 , wherein the screen for providing authentication information includes a text entry field.

4. The method of claim 3 , wherein capturing authentication information includes receiving a passcode entered into the text entry field.

5. 3. The method of claim 2, wherein the indication that the second external electronic device cannot be authenticated to allow the first electronic device to transition from the locked state to the unlocked state based on the presence of the second external electronic device occupies more than 50% of the display of the first electronic device.

6. The method of claim 4 , wherein the screen for providing authentication information includes a selectable affordance for confirming entry of the passcode.

7. The method according to any one of claims 1 to 6, further comprising: subsequent to displaying the screen for providing authentication information, detecting that the first external electronic device is within a predetermined distance of the first electronic device while the first electronic device is in the locked state; and transitioning the first electronic device from the locked state to the unlocked state in response to detecting that the first external electronic device is within the predetermined distance of the first electronic device.

8. 8. The method of claim 7, further comprising: following the first electronic device transitioning from the locked state to the unlocked state, displaying a visual indication via the display that the first electronic device is in the unlocked state.

9. 8. The method of claim 7, further comprising: after the first electronic device transitions from the locked state to the unlocked state, displaying a visual indication on the first external electronic device that the first electronic device is in the unlocked state.

10. A computer program that causes a computer to execute the method according to any one of claims 1 to 9.

11. 11. An electronic device comprising: a memory storing a computer program according to claim 10; and one or more processors capable of executing the computer program stored in said memory.

12. An electronic device comprising means for carrying out the method according to any one of claims 1 to 9.

Images