User interface for managing secure operations

Abstract

To provide a method, a computer system, and a storage medium for managing secure operation via input received at an external device.SOLUTION: A method in a computer system in communication with an external automotive head unit includes: receiving, from the external automotive head unit, first data corresponding to input received at one or more input components of the external automotive head unit that responds to a request to perform a first transfer operation from a first account to a second account using an application on a computer system associated with the first account; and initiating, in response to receiving the first data, a process of performing the first transfer operation by transmitting, using the application on the computer system, second data containing information for identifying the first account.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] This application claims priority to U.S. Patent Application No. 17 / 076,694, entitled "USER INTERFACES FOR MANAGING SECURE OPERATIONS," filed October 21, 2020, and U.S. Provisional Patent Application No. 63 / 041,969, entitled "USER INTERFACES FOR MANAGING SECURE OPERATIONS," filed June 21, 2020, the contents of each of which are incorporated herein by reference in their entirety.

[0002] The present disclosure relates generally to computer user interfaces, and more specifically to techniques for managing secure operations via input received at an external device. [Background technology]

[0003] Users often perform actions using personal electronic devices, and such technologies typically require users to provide various inputs and permissions to perform those actions. Summary of the Invention

[0004] However, some techniques for managing secure operations using electronic devices are generally cumbersome and inefficient. For example, some existing techniques require a user to provide various inputs and permissions to perform these operations on a personal device (e.g., a mobile phone), and these inputs may not be convenient or safe for a user to provide while the user is operating a vehicle.

[0005] Thus, the present technology provides faster, safer, and more efficient methods and interfaces for managing secure operations using electronic devices. Such methods and interfaces optionally complement or replace other methods for managing secure operations. Such methods and interfaces are safer, such as not distracting a user while the user is operating a vehicle. Such methods and interfaces reduce the cognitive burden on the user and create a more efficient human-machine interface.

[0006] According to some embodiments, a method is described. The method is executed in a computer system in communication with an external automobile head unit, the external automobile head unit including one or more input components and in communication with an external receiving device. The method includes receiving first data from the external automobile head unit corresponding to an input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with the first account, and in response to receiving the first data, initiating a process to perform the first transfer operation using the application on the computer system, where performing the first transfer operation includes transmitting second data to the external receiving device, the second data including information identifying the first account.

[0007] According to some embodiments, a non-transitory computer-readable storage medium is described. The non-transitory computer-readable storage medium stores one or more programs configured to be executed by one or more processors of a computer system in communication with an external automobile head unit, the computer system including one or more input components and in communication with an external receiving device. The one or more programs include instructions for receiving, from the external automobile head unit, first data corresponding to an input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with the first account, and in response to receiving the first data, initiating a process to perform the first transfer operation using the application on the computer system, and performing the first transfer operation includes transmitting, to the external receiving device, second data including information identifying the first account.

[0008] According to some embodiments, a temporary computer-readable storage medium is described. The temporary computer-readable storage medium stores one or more programs configured to be executed by one or more processors of a computer system in communication with an external automobile head unit, the computer system including one or more input components and in communication with an external receiving device. The one or more programs include instructions for receiving, from the external automobile head unit, first data corresponding to an input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with the first account, and in response to receiving the first data, initiating a process to perform the first transfer operation using the application on the computer system, where performing the first transfer operation includes transmitting, to the external receiving device, second data including information identifying the first account.

[0009] According to some embodiments, a computer system is described. The computer system includes one or more processors, the computer system in communication with an external automobile head unit including one or more input components, the computer system in communication with an external receiving device, and a memory storing one or more programs configured to be executed by the one or more processors. The one or more programs include instructions for receiving, from the external automobile head unit, first data corresponding to an input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with the first account, and in response to receiving the first data, initiating a process to perform the first transfer operation using the application on the computer system, where performing the first transfer operation includes transmitting, to the external receiving device, second data including information identifying the first account.

[0010] According to some embodiments, a computer system is described that is in communication with an external automobile head unit including one or more input components, the computer system in communication with an external receiving device, the computer system comprising: means for receiving, from the external automobile head unit, first data corresponding to an input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with the first account, and means for initiating, in response to receiving the first data, a process for performing the first transfer operation using the application on the computer system, where performing the first transfer operation includes transmitting, to the external receiving device, second data including information identifying the first account.

[0011] According to some embodiments, a method is described. The method is executed in a computer system. The computer system includes receiving a first request from the external input device to interact with a first portion of a user interface associated with a secure transaction, the first request requesting separate permission from a user if authorized by the computer system while the computer system is connected to the external input device. In response to receiving the first request, the computer system further includes providing, via the external input device, an option to initiate a secure transaction without requesting separate permission from a user, in accordance with a determination that the external input device meets a set of permission criteria, and ceasing to provide the option to initiate a secure transaction without requesting separate permission from a user in accordance with a determination that the external input device does not meet the set of permission criteria.

[0012] According to some embodiments, a non-transitory computer-readable storage medium is described. The non-transitory computer-readable storage medium stores one or more programs configured to be executed by one or more processors of a computer system. The one or more programs include instructions for receiving a first request from the external input device to interact with a first portion of a user interface associated with a secure transaction, the first request requesting separate permission from a user if authorized by the computer system while the computer system is connected to the external input device. The one or more programs further include instructions for, in response to receiving the first request, providing an option to initiate a secure transaction via the external input device without requesting separate permission from a user, in accordance with a determination that the external input device meets a set of permission criteria, and forfeiting providing the option to initiate a secure transaction without requesting separate permission from a user, in accordance with a determination that the external input device does not meet the set of permission criteria.

[0013] According to some embodiments, a temporary computer-readable storage medium is described. The temporary computer-readable storage medium stores one or more programs configured to be executed by one or more processors of a computer system. The one or more programs include instructions for receiving a first request from the external input device to interact with a first portion of a user interface associated with a secure transaction, the first request requesting separate permission from a user if authorized by the computer system while the computer system is connected to the external input device. The one or more programs further include instructions for, in response to receiving the first request, providing an option to initiate a secure transaction via the external input device without requesting separate permission from the user, in accordance with a determination that the external input device meets a set of permission criteria, and forfeiting providing the option to initiate a secure transaction without requesting separate permission from the user, in accordance with a determination that the external input device does not meet the set of permission criteria.

[0014] According to some embodiments, a computer system is described. The computer system includes one or more processors and a memory storing one or more programs configured to be executed by the one or more processors. The one or more programs include instructions for receiving a first request from the external input device to interact with a first portion of a user interface associated with a secure transaction, the first request requesting separate permission from a user if authorized by the computer system while the computer system is connected to the external input device. The one or more programs further include instructions for, in response to receiving the first request, providing an option to initiate a secure transaction via the external input device without requesting separate permission from the user in accordance with a determination that the external input device meets a set of permission criteria, and forfeiting the option to initiate a secure transaction without requesting separate permission from the user in accordance with a determination that the external input device does not meet the set of permission criteria.

[0015] According to some embodiments, a computer system is described comprising: means for receiving a first request from the external input device to interact with a first portion of a user interface associated with a secure transaction, the first request requesting separate permission from a user if authorized by the computer system while the computer system is connected to the external input device; and means for, in response to receiving the first request, providing, via the external input device, an option to initiate a secure transaction without requesting separate permission from a user, in accordance with a determination that the external input device meets a set of permission criteria, and for withdrawing from providing the option to initiate a secure transaction without requesting separate permission from a user in accordance with a determination that the external input device does not meet the set of permission criteria.

[0016] Executable instructions to perform these functions are optionally contained in a non-transitory computer-readable storage medium or other computer program product configured for execution by one or more processors. Executable instructions to perform these functions are optionally contained in a transitory computer-readable storage medium or other computer program product configured for execution by one or more processors.

[0017] Thus, devices are provided with faster, more efficient methods and interfaces for managing secure operations, thereby increasing the effectiveness, efficiency, and user satisfaction of such devices. Such methods and interfaces may complement or replace other methods for managing secure operations. [Brief description of the drawings]

[0018] For a better understanding of the various described embodiments, reference should be made to the following Detailed Description in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout:

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

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

[0021] [Diagram 2] FIG. 1 illustrates a portable multifunction device having a touch screen in accordance with some embodiments.

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

[0023] [Figure 4A] 1 illustrates an exemplary user interface for a menu of applications on a portable multifunction device in accordance with some embodiments.

[0024] [Figure 4B] 1 illustrates an exemplary user interface of a multifunction device having a touch-sensitive surface that is separate from a display in accordance with some embodiments.

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

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

[0027] [Figure 6A] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 6B] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 6C] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 6D] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 6E] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 6F] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments.

[0028] [Figure 7A] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7B] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7C] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7D] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7E] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7F] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7G] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7H] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7I]1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7J] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7K] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7L] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments. [Figure 7M] 1 illustrates an exemplary user interface for performing secure operations according to some embodiments.

[0029] [Figure 8] FIG. 1 is a flow diagram illustrating a method for performing secure operations according to some embodiments.

[0030] [Figure 9] FIG. 1 is a flow diagram illustrating a method for providing an option to initiate a secure operation according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] 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 rather is provided as a description of example embodiments.

[0032] There is a need for electronic devices that provide efficient methods and interfaces for managing secure operations. For example, there is a need to provide techniques that increase safety when managing operations that can be performed while a vehicle is being operated. Such methods and interfaces are safer, such as not distracting a user while the user is operating the vehicle. Such techniques can reduce the cognitive burden on a user who needs to perform an operation, thereby increasing productivity. Furthermore, such techniques can reduce processor and battery power that would otherwise be wasted on redundant user input.

[0033] 1A-1B, 2, 3, 4A-4B, and 5A-5B below provide a description of an example device for performing techniques for managing secure operations.

[0034] 6A-6F show example user interfaces for performing a secure operation, according to some embodiments. FIGS. 7A-7M show example user interfaces for performing a secure operation, according to some embodiments. FIG. 8 is a flow diagram illustrating a method for performing a secure operation, according to some embodiments. FIG. 9 is a flow diagram illustrating a method for providing an option to initiate a secure operation, according to some embodiments. The user interfaces of FIGS. 6A-6F and 7A-7M are used to illustrate processes described below, including the processes of FIGS. 8 and 9.

[0035] The processes described below improve the usability of the device and make the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors) through various techniques, including by providing improved visual feedback to the user, reducing the number of inputs required to execute an action, providing additional control options without cluttering the user interface with additional displayed controls, executing an action when a set of conditions is met without requiring further user input, and / or additional techniques. These techniques also reduce power usage and improve the battery life of the device by allowing the user to use the device more quickly and efficiently.

[0036] In addition, in methods described herein in which one or more steps depend on one or more conditions being satisfied, it should be understood that the described methods can be repeated multiple times, whereby over the course of the iterations, all of the conditions on which the steps of the method depend are satisfied in different iterations of the method. For example, if a method requires a first step to be performed if a condition is satisfied, and a second step to be performed if the condition is not satisfied, one skilled in the art will understand that the claimed steps are repeated in no particular order, both until the condition is satisfied and until it is no longer satisfied. Thus, a method described with one or more steps that depend on one or more conditions being satisfied can be rewritten as a method that is repeated until each of the conditions described in the method are satisfied. However, this is not required for system or computer readable medium claims in which the system or computer readable medium includes instructions to perform a dependent action based on the satisfaction of the corresponding one or more conditions, and thus can determine whether a context dependency has been satisfied without explicitly repeating the steps of the method until all of the conditions on which the steps of the method depend are satisfied. Those skilled in the art will also understand that, as with methods having conditional steps, the system or computer-readable storage medium may repeat the steps of the method as many times as necessary to ensure that all of the conditional steps have been performed.

[0037] 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 only used to distinguish one element from another element. For example, a first touch can be called a second touch, and a second touch can be called a first touch, without departing from the scope of various embodiments described. Although a first touch and a second touch are both touches, they are not the same touch.

[0038] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. In the description of the various embodiments described 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 dictates otherwise. It should also be understood that as used herein, 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," as 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.

[0039] The term "if" is interpreted, optionally, depending on the context, to mean "when" or "upon," or "in response to determining" or "in response to detecting." Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" is interpreted, optionally, depending on the context, 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]."

[0040] 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 phone, that also includes other functions, such as a PDA function and / or a music player function. Exemplary embodiments of portable multifunction devices include, but are not limited to, iPhone®, iPod Touch®, and iPad® devices from Apple Inc. of Cupertino, Calif. Optionally, other portable electronic devices, such as laptop computers or tablet computers having a touch-sensitive surface (e.g., a touchscreen display and / or a touchpad), are also used. It should also be understood that in some embodiments, the device is not a portable communication device, but a desktop computer having a touch-sensitive surface (e.g., a touchscreen display and / or a touchpad). In some embodiments, the electronic device is a computer system in communication (e.g., via wired communication, via wireless communication) with a display generating component. The display generating component is configured to provide a visual output, such as a display via a CRT display, a display via an LED display, or a display via image projection. In some embodiments, the display generating component is integrated with the computer system. In some embodiments, the display generation components are separate from the computer system. As used herein, "displaying" content includes causing content (e.g., video data rendered or decoded by display controller 156) to be displayed by transmitting data (e.g., image data or video data) over a wired or wireless connection to an integrated or external display generation component to visually generate the content.

[0041] In the following discussion, electronic devices are described that include a display and a touch-sensitive surface, however, 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.

[0042] The device typically supports a variety of applications, such as one or more of drawing applications, presentation applications, word processing applications, website creation applications, disc authoring applications, spreadsheet applications, gaming applications, telephony applications, video conferencing applications, email applications, instant messaging applications, training support applications, photo management applications, digital camera applications, digital video camera applications, web browsing applications, digital music player applications, and / or digital video player applications.

[0043] The 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 individual applications. In this way, the common physical architecture of the device (such as the touch-sensitive surface) optionally supports a variety of applications with user interfaces that are intuitive and transparent to the user.

[0044] Attention is now directed to embodiments of portable devices with touch-sensitive displays. FIG. 1A is a block diagram illustrating a portable multifunction device 100 having a touch-sensitive display system 112, according to some embodiments. Touch-sensitive display 112 may be conveniently 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 that detect 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 that generate tactile output on device 100 (e.g., generate 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 over one or more communication buses or signal lines 103.

[0045] As used herein and in the 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 proxy for the force or pressure of a contact on the touch-sensitive surface. The intensity of a contact has a range of values ​​including at least four distinct values, and more typically including hundreds (e.g., at least 256) distinct values. The intensity of a contact is optionally determined (or measured) using various techniques and various sensors or combinations of sensors. For example, one or more force sensors under or adjacent to the touch-sensitive surface are optionally used to measure the force at various points on the touch-sensitive surface. In some implementations, force measurements from multiple force sensors are combined (e.g., weighted averaged) to determine an estimated force of the contact. 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 a surrogate 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 is exceeded (e.g., the intensity threshold is described in units that correspond to the surrogate measure). In some implementations, the surrogate measure of the contact force or pressure is converted to an estimate of the force or pressure, and the estimate of the force or pressure is used to determine whether an intensity threshold is 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 may enable a user to access additional device functionality (e.g., on a touch-sensitive display) and / or receive user input (e.g., via a touch-sensitive display, touch-sensitive surface, or physical / mechanical controls such as knobs or buttons) that may not otherwise be accessible on devices of reduced size that have limited real estate for displaying affordances.

[0046] As used herein and in the claims, the term "tactile output" refers to a physical displacement of a device relative to a previous position of the device, a physical displacement of a component of the device (e.g., a touch-sensitive surface) relative to another component of the device (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 a device is in contact with a touch-sensitive surface of a user (e.g., the fingers, palm, or other part of a user's hand), the tactile output generated 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 a touch-sensitive surface (e.g., a touch-sensitive display or trackpad) is optionally interpreted by the user as a "down-click" or "up-click" of a physical actuator button. In some cases, a user feels a tactile sensation such as a "down-click" or "up-click" even when there is no movement of a physical actuator button associated with the touch-sensitive surface that is physically pressed (e.g., displaced) by the user's action. As another example, movement of a touch-sensitive surface is optionally interpreted or sensed 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 user interpretation of touch depends on the user's personal 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 "up click," a "down click," "roughness"), unless otherwise noted, the generated tactile output corresponds to a physical displacement of the device, or a component of the device, that produces the described sensory perception for a typical (or average) user.

[0047] It is 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 its components. The various components shown in FIG. 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.

[0048] Memory 102 optionally includes high-speed random access memory, and optionally includes non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. A memory controller 122 optionally controls access to memory 102 by other components of device 100.

[0049] The peripherals interface 118 may 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 the memory 102 to perform various functions and process data for the device 100. In some embodiments, the peripherals interface 118, the CPU 120, and the memory controller 122 are optionally implemented on a single chip, such as the chip 104. In some other embodiments, they are optionally implemented on separate chips.

[0050] The radio frequency (RF) circuitry 108 transmits and receives RF signals, also referred to as 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 circuits 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 with networks, such as the Internet, also referred to as 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 with other devices, by wireless communication. RF circuitry 108 optionally includes well known circuitry for detecting near field communication (NFC) fields, such as by short-range radios. Wireless communication optionally includes, but is not limited to, 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-HSPA), long term evolution (EV-DO), and other related technologies.Wireless technology includes, but is not limited to, wireless technology such as wireless LAN, wireless technology such as wireless technology with a cellular network (WAN), wireless technology such as wireless technology with a cellular network (WAN-CDMA), wireless technology such as wireless technology with a cellular network (WAN-SWAN ... The present invention may use any of a number of communications standards, protocols, and technologies, including Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (XMPP), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), Instant Messaging and Presence Service (IMPS), and / or Short Message Service (SMS), or any other suitable communications protocol, including communications protocols not yet developed as of the filing date of this application.

[0051] The audio circuit 110, the speaker 111, and the microphone 113 provide an audio interface between a user and the device 100. The audio circuit 110 receives audio data from the peripherals interface 118, converts the audio data into an electrical signal, and transmits the electrical signal to the speaker 111. The speaker 111 converts the electrical signal into human audible sound waves. The audio circuit 110 also receives an electrical signal converted from the sound waves by the microphone 113. The audio circuit 110 converts the electrical signal into audio data, and transmits the audio data to the peripherals interface 118 for processing. The audio data is optionally retrieved from and / or transmitted to the memory 102 and / or the RF circuit 108 by the peripherals interface 118. In some embodiments, the audio circuit 110 also includes a headset jack (e.g., 212 in FIG. 2). The headset jack provides an interface between audio circuitry 110 and a detachable audio input / output peripheral such as an output-only headphone or a headset with both an output (e.g., one-ear or binaural headphones) and an input (e.g., a microphone).

[0052] The I / O subsystem 106 couples input / output peripherals on the device 100, such as the touch screen 112 and other input control devices 116, to a peripheral interface 118. The I / O subsystem 106 optionally includes a display controller 156, an optical sensor controller 158, a depth camera controller 169, an intensity sensor controller 159, a haptic feedback controller 161, and one or more input controllers 160 for other input or control devices. The one or more input controllers 160 receive / send electrical signals from / to the other input control devices 116. The 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 embodiments, the input controller(s) 160 are optionally coupled to any (or none) of a keyboard, an infrared port, a USB port, and a pointer device such as a mouse. The one or more buttons (e.g., 208 in FIG. 2) optionally include up / down buttons for volume control of speaker 111 and / or microphone 113. The one or more buttons optionally include push buttons (e.g., 206 in FIG. 2). In some embodiments, the electronic device is a computer system in communication (e.g., via wireless communication over wired communication) with one or more input devices. In some embodiments, the one or more input devices include a touch-sensitive surface (e.g., a trackpad as part of a touch-sensitive display). In some embodiments, the one or more input devices include one or more camera sensors (e.g., one or more optical sensors 164 and / or one or more depth camera sensors 175), such as for tracking a user's gestures (e.g., hand gestures) as input. In some embodiments, the one or more input devices are integrated with the computer system. In some embodiments, the one or more input devices are separate from the computer system.

[0053] A quick press of the push button optionally unlocks the touch screen 112 or optionally initiates a process of unlocking the device using gestures on the touch screen, as described in U.S. Patent Application Serial No. 11 / 322,549, filed December 23, 2005, "Unlocking a Device by Performing Gestures on an Unlock Image," U.S. Patent No. 7,657,849, which is incorporated herein by reference in its entirety. A longer press of the push button (e.g., 206) optionally turns power on or off to the device 100. The functionality of one or more of the buttons is optionally customizable by the user. The touch screen 112 is used to implement virtual or soft buttons and one or more soft keyboards.

[0054] Touch-sensitive display 112 provides an input and output interface between the device and a user. Display controller 156 receives and / or transmits electrical signals from touchscreen 112. Touchscreen 112 displays visual output to the user. This visual output optionally includes graphics, text, icons, animation, and any combination thereof (collectively "graphics"). In some embodiments, some or all of the visual output optionally corresponds to user interface objects.

[0055] Touchscreen 112 has a touch-sensitive surface, sensor, or set of sensors that accepts 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 breaking of contact) on touchscreen 112 and translates the detected contacts into interactions with user interface objects (e.g., one or more soft keys, icons, web pages, or images) displayed on touchscreen 112. In an exemplary embodiment, the point of contact between touchscreen 112 and the user corresponds to the user's finger.

[0056] Touchscreen 112 optionally uses LCD (Liquid Crystal Display), LPD (Light Emitting Polymer Display), or LED (Light Emitting Diode) technology, although other display technologies are used in other embodiments. Touchscreen 112 and display controller 156 optionally detect contact and any movement or interruption thereof using any of a number of 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 that determine one or more points of contact with touchscreen 112. In an exemplary embodiment, projected mutual capacitance sensing technology is used, such as that found in the iPhone® and iPod Touch® from Apple Inc. of Cupertino, Calif.

[0057] The touch-sensitive display in some embodiments of touchscreen 112 is optionally similar to a multi-touch-sensing touchpad as described in U.S. Patent Nos. 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, whereas touchscreen 112 displays visual output from device 100, a touch-sensitive touchpad does not provide visual output.

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

[0059] Touchscreen 112 optionally has a video resolution of greater than 100 dpi. In some embodiments, the touchscreen has a video resolution of approximately 160 dpi. A user optionally contacts touchscreen 112 using any suitable object or appendage, such as a stylus, finger, etc. In some embodiments, the user interface is designed to operate primarily using finger-based contacts and gestures, which may not be as precise as stylus-based input due to the larger contact area of ​​a finger on the touchscreen. In some embodiments, the device translates the rough finger input into precise pointer / cursor positions or commands to perform the actions desired by the user.

[0060] In some embodiments, in addition to a touchscreen, device 100 optionally includes a touchpad for activating or deactivating certain functions. In some embodiments, the touchpad is a touch-sensitive area of ​​the device that, unlike the touchscreen, does not display visual output. The touchpad is optionally a touch-sensitive surface separate from touchscreen 112 or an extension of the touch-sensitive surface formed by the touchscreen.

[0061] Device 100 also includes a power system 162 that provides power to the various components. Power system 162 optionally includes a power management system, one or more power sources (e.g., batteries, 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 the generation, management, and distribution of power within a portable device.

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

[0063] Device 100 also optionally includes one or more depth camera sensors 175. FIG. 1A shows a depth camera sensor coupled to depth camera controller 169 in I / O subsystem 106. Depth camera sensor 175 receives data from the environment to create a three-dimensional model of an object (e.g., a face) in a scene from a viewpoint (e.g., the depth camera sensor). In some embodiments, in cooperation with imaging module 143 (also called camera module), depth camera sensor 175 is optionally used to determine a depth map of different parts of an image captured by imaging module 143. In some embodiments, a depth camera sensor is disposed on the front of device 100 to obtain an image of a user with depth information for a video conference and to capture a selfie image with depth map data while the user views other video conference participants on a touch screen display. In some embodiments, depth camera sensor 175 is disposed on the back of the device, or on the back and front of device 100. In some embodiments, the position of the depth camera sensor 175 can be changed by the user (e.g., by rotating the lens and sensor within the device housing) such that the depth camera sensor 175 is used for both video conferencing and still image and / or video capture in conjunction with a touchscreen display.

[0064] Device 100 also optionally includes one or more contact intensity sensors 165. FIG. 1A shows a contact intensity sensor coupled to intensity sensor controller 159 in I / O subsystem 106. Contact intensity sensor 165 optionally includes one or more piezoresistive strain gauges, capacitive force sensors, electrical 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 sensor 165 receives 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 juxtaposed with or proximate to a 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 located on the front of device 100.

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

[0066] Device 100 also optionally includes one or more tactile output generators 167. FIG. 1A shows a tactile output generator 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 commands 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 juxtaposed with or proximate to a touch-sensitive surface (e.g., touch-sensitive display system 112) and generates a tactile output, optionally by moving the touch-sensitive surface vertically (e.g., in / out of the surface of device 100) or horizontally (e.g., back and forth in the same plane as the surface of device 100). In some embodiments, the 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.

[0067] Device 100 also optionally includes one or more accelerometers 168. FIG. 1A shows accelerometer 168 coupled to peripherals interface 118. Alternatively, accelerometer 168 is optionally coupled to input controller 160 in I / O subsystem 106. Accelerometer 168 optionally functions as described in U.S. Patent Application Publication No. 20050190059, “Acceleration-based Theft Detection System for Portable Electronic Devices,” and U.S. Patent Application Publication No. 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 the touchscreen display in portrait or landscape view based on an analysis of data received from the one or more accelerometers. In addition to accelerometer(s) 168, device 100 optionally includes a magnetometer and a GPS (or GLONASS or other global navigation system) receiver for obtaining information regarding the position and orientation (e.g., vertical or horizontal) of device 100.

[0068] In some embodiments, the software components stored in memory 102 include an operating system 126, a communication 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, memory 102 (FIG. 1A) or 370 (FIG. 3) stores device / global internal state 157, as shown in FIGS. 1A and 3. Device / global internal state 157 includes one or more of an active application state indicating which applications, if any, are currently active, a display state indicating which applications, views, or other information are occupying 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 location and / or orientation of the device.

[0069] Operating system 126 (e.g., Darwin, RTXC, LINUX, UNIX, OS X, iOS, WINDOWS, or an embedded operating system such as VxWorks) includes various software components and / or drivers that control and manage general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitate communication between various hardware and software components.

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

[0071] Contact / motion module 130, optionally in conjunction 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 strength 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 movement of the contact and tracking the movement across the touch-sensitive surface (e.g., detecting one or more finger-dragging events), and determining whether the contact has ceased (e.g., detecting a finger-up event or an interruption of the contact). Contact / motion module 130 receives contact data from the touch-sensitive surface. Determining the movement of the contact, as 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. These actions are, optionally, applied to a single contact (e.g., one 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 a touchpad.

[0072] In some embodiments, the contact / motion module 130 uses a set of one or more intensity thresholds to determine whether an action has been performed by a user (e.g., to determine 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 thresholds of a particular physical actuator, but can be adjusted without modifying the physical hardware of the device 100). For example, the mouse “click” threshold of a trackpad or touchscreen display can be set to any of a wide range of predefined thresholds without modifying the trackpad or touchscreen display hardware. Additionally, in some implementations, a user of the device is provided with a software setting to adjust one or more of the sets 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).

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

[0074] Graphics module 132 includes various known software components that render and display graphics on touchscreen 112 or other display, including components that vary the visual impact (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, characters, web pages, icons (such as user interface objects including soft keys), digital images, video, animations, and the like.

[0075] 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, such as from an application, along with coordinate data and other graphic characteristic data, as appropriate, and then generates screen image data for output to display controller 156.

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

[0077] Text input module 134 is optionally a component of 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).

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

[0079] Application 136 optionally includes the following modules (or sets of instructions), or a subset or superset thereof: ● a contacts module 137 (sometimes called an address book or contact list); ●Telephone module 138, ● Videoconferencing module 139, ● an email client module 140; ● Instant messaging (IM) module 141, ● Training support module 142, A camera module 143 for still images and / or video; ● Image management module 144, ●Video player module, ●Music player module, ● Browser module 147, ● Calendar module 148, ● A widget module 149, optionally including 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 obtained by the user, as well as user-created widgets 149-6; A widget creator module 150 for creating user-created widgets 149-6; ● Search module 151, A video and music player module 152 that integrates a video player module and a music player module; ● Memo module 153, Map module 154, and / or ●Online video module 155.

[0080] Examples of other applications 136 optionally 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.

[0081] In conjunction with the touch screen 112, the display controller 156, the contact / motion module 130, the graphics module 132, and the text input module 134, the contacts module 137 is used to manage an address book or contact list (e.g., stored in the application internal state 192 of the contacts module 137 in the memory 102 or memory 370), including, optionally, adding a name(s) to the address book, deleting a name(s) from the address book, associating phone number(s), email address(es), address(es), or other information with a name, associating a picture with a name, 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, and the like.

[0082] Telephone module 138, in conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134, is optionally used to enter character sequences corresponding to telephone numbers, access one or more telephone numbers in contacts module 137, modify entered telephone numbers, dial individual telephone numbers, place calls, and disconnect and hang up when a call is completed. As previously mentioned, wireless communication optionally uses any of a number of communication standards, protocols, and technologies.

[0083] Videoconferencing module 139 includes executable instructions to cooperate with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, optical sensor 164, optical sensor controller 158, contact / motion module 130, graphics module 132, text input module 134, contact module 137, and telephone module 138 to initiate, conduct, and end a videoconference between a user and one or more other participants in accordance with instructions from the user.

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

[0085] Instant messaging module 141 includes executable instructions in cooperation with RF circuitry 108, touch screen 112, display controller 156, contact / motion module 130, graphics module 132, and text input module 134 for entering character sequences corresponding to instant messages, modifying previously entered characters, sending individual instant messages (e.g., using Short Message Service (SMS) or Multimedia Message Service (MMS) protocols for telephony-based instant messaging, or XMPP, SIMPLE, or IMPS for Internet-based instant messaging), receiving instant messages, and viewing received instant messages. In some embodiments, sent and / or received instant messages optionally include graphics, photos, audio files, video files, and / or other attachments as supported by MMS and / or Enhanced Messaging Service (EMS). As used herein, "instant messaging" refers to both telephony-based messages (e.g., messages sent using SMS or MMS) and Internet-based messages (e.g., messages sent using XMPP, SIMPLE, or IMPS).

[0086] The training support module 142 includes executable instructions to cooperate with the RF circuitry 108, the touch screen 112, the display controller 156, the contact / motion module 130, the graphics module 132, the text input module 134, the GPS module 135, the map module 154, and the music player module to create workouts (e.g., having time, distance, and / or calorie burn goals), communicate with training sensors (sports devices), receive training sensor data, calibrate sensors used to monitor the workouts, select and play music for the workouts, and display, store, and transmit the workout data.

[0087] Camera module 143, in conjunction with touch screen 112, display controller 156, optical sensor 164, optical sensor controller 158, contact / motion module 130, graphics module 132, and image management module 144, contains executable instructions for capturing and storing still images or video (including video streams) in memory 102, modifying characteristics of the still images or video, or deleting still images or video from memory 102.

[0088] Image management module 144, in conjunction with touch screen 112, display controller 156, contact / motion module 130, graphics module 132, text input module 134, and camera module 143, contains executable instructions for arranging, modifying (e.g., editing), or otherwise manipulating, labeling, deleting, presenting (e.g., in a digital slide show or album), and storing still and / or video images.

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

[0090] The calendar module 148 includes executable instructions to cooperate with the RF circuitry 108, the touch screen 112, the display controller 156, the contact / motion module 130, the graphics module 132, the text input module 134, the email client module 140, and the browser module 147 to create, display, modify, and store calendars and data associated with the calendars (e.g., calendar items, to-do lists, etc.) according to user instructions.

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

[0092] The widget creator module 150, in conjunction with the RF circuitry 108, the touch screen 112, the display controller 156, the contact / motion module 130, the graphics module 132, the text input module 134, and the browser module 147, is optionally used by a user to create a widget (e.g., turn a user-specified portion of a web page into a widget).

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

[0094] Video and music player module 152 includes executable instructions that cooperate 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 to 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 (e.g., 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.).

[0095] The notes module 153 includes executable instructions for cooperating with the touch screen 112, the display controller 156, the contact / motion module 130, the graphics module 132, and the text input module 134 to create and manage notes, to-do lists, and the like as directed by a user.

[0096] Map module 154, 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, is used to receive, display, modify, and store maps and data associated with the maps (e.g., driving directions, data regarding businesses and other points of interest at or near a particular location, and other location-based data), optionally in accordance with a user's instructions.

[0097] Online video module 155, in conjunction 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, includes instructions that enable a user to access, browse for, receive (e.g., by streaming and / or downloading), and play (e.g., on the touchscreen or on an external display connected via external port 124) particular online videos, send emails with links to particular online videos, and otherwise manage 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. For additional description of online video applications, see U.S. Provisional Patent Application No. 60 / 936,562, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," filed June 20, 2007, and U.S. Patent Application No. 11 / 968,067, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," filed December 31, 2007, the contents of which are incorporated herein by reference in their entireties.

[0098] Each of the above-identified modules and applications corresponds to a set of executable instructions that perform one or more of the functions previously described and methods described herein (e.g., the computer-implemented methods and other information processing methods described herein). These modules (e.g., sets of instructions) need not be implemented as separate software program computer programs (e.g., including instructions), procedures, or modules, and thus, in various embodiments, various subsets of these modules are optionally combined or otherwise reconfigured. For example, a video player module is optionally combined with a music player module into a single module (e.g., video and music player module 152 of FIG. 1A). In some embodiments, memory 102 optionally stores a subset of the above-identified modules and data structures. Additionally, memory 102 optionally stores additional modules and data structures not described above.

[0099] 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. Using the touchscreen and / or touchpad as the primary input control device for operation of device 100 optionally reduces the number of physical input control devices (push buttons, dials, etc.) on device 100.

[0100] The set of predefined functions performed only through 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, a home menu, or a 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 rather than a touchpad.

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

[0102] Event sorter 170 receives the event information and determines which application 136-1 to deliver the event information to and application view 191 of application 136-1. Event sorter 170 includes an event monitor 171 and an event dispatcher module 174. In some embodiments, application 136-1 includes application internal state 192 that indicates the current application view that is 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 view 191 to deliver the event information to.

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

[0104] Event monitor 171 receives event information from peripherals interface 118. The event information includes information about a sub-event (e.g., a user touch as part of a multi-touch gesture on touch-sensitive display 112). 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.

[0105] 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., receipt of an input above a predetermined noise threshold and / or for a predetermined duration).

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

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

[0108] 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 views (of a particular application) in which a touch is detected optionally correspond to programmatic levels within the programmatic or view hierarchy of the application. For example, the lowest level view in which a touch is detected is optionally referred to as a hit view, and the set of events that are recognized as suitable inputs is optionally determined based at least in part on the hit view of the initial touch that initiates the touch gesture.

[0109] Hit view determination module 172 receives information related to sub-events of a touch-based gesture. When an application has multiple views organized in a hierarchical manner, hit view determination module 172 identifies the hit view as the lowest view in the hierarchy that should process the sub-events. In most situations, the hit view is the lowest level view in which an initiating sub-event occurs (e.g., the first sub-event in a sub-event sequence that forms 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 related to the same touch or input source as the touch or input source identified as the hit view.

[0110] 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-event 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 area associated with one particular view, views higher in the hierarchy still remain actively participating views.

[0111] 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 obtained by individual event receivers 182 in an event queue.

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

[0113] In some embodiments, application 136-1 includes multiple event handlers 190 and one or more application views 191, each including instructions for handling touch events that occur within a separate view of the application's user interface. Each application view 191 of application 136-1 includes one or more event recognizers 180. Typically, a separate application view 191 includes multiple event recognizers 180. In other embodiments, one or more of the event recognizers 180 are part of a separate module, such as a user interface kit or a higher-level object from which application 136-1 inherits methods and other properties. In some embodiments, a separate event handler 190 includes one or more of a data updater 176, an object updater 177, a GUI updater 178, and / or event data 179 received from event sorter 170. Event handler 190 optionally utilizes or invokes 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 include one or more separate event handlers 190. Also, in some embodiments, one or more of the data updater 176, the object updater 177, and the GUI updater 178 are included in a separate application view 191.

[0114] A separate 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 an event receiver 182 and an event comparator 184. In some embodiments, event recognizer 180 also includes at least a subset of metadata 183 and event delivery instructions 188 (optionally including sub-event delivery instructions).

[0115] The event receiver 182 receives event information from the event sorter 170. The event information includes information about a sub-event, e.g., a touch or a movement of a touch. Depending on the sub-event, the event information also includes additional information, such as a position of the sub-event. When the sub-event involves a movement of a touch, the event information also optionally includes a speed and a 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 or vice versa), and the event information includes corresponding information about the current orientation of the device (also referred to as the device's attitude).

[0116] 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 definitions of events (e.g., a sequence of predefined sub-events), such as event 1 (187-1) and event 2 (187-2). In some embodiments, sub-events in an event (187) include, for example, touch start, touch end, touch move, touch cancel, and multiple touches. In one example, the definition for event 1 (187-1) is a double tap on a displayed object. The double tap includes, for example, a first touch on a displayed object for a given phase (touch start), a first lift off (touch end) for a given phase, a second touch on a displayed object for a given phase (touch start), and a second lift off (touch end) for a given phase. In another example, a definition of event 2 (187-2) is a drag on a displayed object. A drag includes, for example, a touch (or contact) on a displayed object to a predetermined stage, 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 regarding one or more associated event handlers 190.

[0117] In some embodiments, event definition 187 includes definitions of events for individual user interface objects. In some embodiments, event comparator 184 performs a hit test to determine which user interface object is associated with a sub-event. For example, when a touch is detected on touch-sensitive display 112 in an application view in which three user interface objects are displayed 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 separate 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 object that triggers the hit test.

[0118] In some embodiments, the definition of an individual event 187 also includes a delay action that delays transmission of the event information until it is determined whether the sequence of sub-events corresponds to the event type of the event recognizer.

[0119] If the individual event recognizer 180 determines that the sequence of sub-events does not match any of the events in the event definition 186, the individual event recognizer 180 enters an event disabled, event failed, or event finished 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 gesture.

[0120] In some embodiments, individual event recognizers 180 include metadata 183 with configurable properties, flags, and / or lists that indicate to actively participating event recognizers how the event delivery system should perform sub-event delivery. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate how event recognizers interact with each other or are enabled to interact with each other. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate how sub-events are delivered to various levels in a view or programmatic hierarchy.

[0121] In some embodiments, the individual event recognizer 180 activates an event handler 190 associated with an event when one or more particular sub-events of the event are recognized. In some embodiments, the individual event recognizer 180 delivers event information associated with the event to the event handler 190. Activating the event handler 190 is separate from sending (and postponing sending) the sub-events to the individual hit view. In some embodiments, the event recognizer 180 pops a flag associated with the recognized event, and the event handler 190 associated with the flag catches the flag and performs a predefined process.

[0122] In some embodiments, the 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 to an actively participating view. The event handler associated with the set of sub-events or the actively participating view receives the event information and performs a predetermined process.

[0123] 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 a video player 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 the display information to graphics module 132 for display on the touch-sensitive display.

[0124] In some embodiments, event handler(s) 190 includes or has 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 of an individual application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.

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

[0126] FIG. 2 illustrates portable multifunction device 100 having touch screen 112, according to some embodiments. The touch screen optionally displays one or more graphics in user interface (UI) 200. In this embodiment, as well as other embodiments described below, a user may select one or more of the graphics by performing a gesture on the graphics, for example, using 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 is performed when the user breaks 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, upwards and / or downwards), and / or rolling (right to left, left to right, upwards and / or downwards) of a finger in contact with device 100. In some implementations or situations, accidental contact with a graphic does not select that graphic: for example, a swipe gesture sweeping over an application icon optionally does not select the corresponding application when the gesture corresponding to selection is a tap.

[0127] Device 100 also optionally includes one or more physical buttons, such as a “home” button or menu button 204. As previously mentioned, menu button 204 is optionally used to navigate to any application 136 within a set of applications executing on device 100. Alternatively, in some embodiments, the menu button is implemented as a soft key within a GUI displayed on touch screen 112.

[0128] In some embodiments, device 100 includes touch screen 112, menu button 204, push button 206 for powering the device on / off and locking the device, volume control button 208, subscriber identity module (SIM) card slot 210, headset jack 212, and external port 124 for docking / charging. Push button 206 is optionally used to power the device on / off by pressing and holding the button down for a predefined time interval, to lock the device by pressing and releasing the button before the predefined time interval has elapsed, and / or to unlock the device or initiate an unlocking process. In an alternative embodiment, device 100 also accepts verbal input via microphone 113 to activate or deactivate some functions. Device 100 also optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on touch screen 112 and / or one or more tactile output generators 167 for generating a tactile output to a user of device 100.

[0129] FIG. 3 is a block diagram of an exemplary multifunction device having 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 that interconnect these components. Communication bus 320 optionally includes circuitry (sometimes referred to as a chipset) that interconnects and controls communication between system components. Device 300 includes input / output (I / O) interface 330, including 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 and a touchpad 355, a tactile output generator 357 (e.g., similar to tactile output generator 167 described above with reference to FIG. 1A) for generating tactile output on device 300, and sensors 359 (e.g., light, acceleration, proximity, touch sensing, and / or contact intensity sensors similar to contact intensity sensor 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 solid-state 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, 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, whereas memory 102 of portable multifunction device 100 (FIG. 1A) optionally does not store these modules.

[0130] Each of the above-identified elements of FIG. 3 is optionally 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 computer programs (e.g., including instruction sets or instructions) need not be implemented as separate software programs (e.g., computer programs (e.g., including instructions)), procedures, or modules, and thus in various embodiments, various subsets of these modules are optionally combined or otherwise reconfigured. In some embodiments, memory 370 optionally stores a subset of the above-identified modules and data structures. Additionally, memory 370 optionally stores additional modules and data structures not described above.

[0131] Attention is now optionally directed to embodiments of user interfaces implemented, for example, on portable multifunction device 100.

[0132] 4A shows an exemplary user interface for a menu of applications on portable multifunction device 100, according to some embodiments. A similar user interface is optionally 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, Tray 408 with icons of 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 of 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 for the video and music player module 152, also called the iPod (trademark of Apple Inc.) module 152, labeled "iPod"; and ● Icons of other applications, such as: ○ Icon 424 of IM module 141, labeled "Messages"; ○ Icon 426 of the calendar module 148, labeled "Calendar", ○ Icon 428 of the image management module 144, labeled "Photos"; ○ An icon 430 of the camera module 143, labeled “camera”; ○ Icon 432 of the online video module 155, labeled "Online Video"; Icon 434 of Stock Price Widget 149-2, labeled "Stock Price" ○ Icon 436 of the map module 154, labeled "Map"; Icon 438 of weather widget 149-1, labeled "Weather"; Icon 440 of the alarm clock widget 149-4, labeled "Clock" ○ Icon 442 of Training Support Module 142, labeled "Training Support"; ○ An icon 444 of the Notes module 153, labeled "Notes"; and ○ A settings application or module icon 446 labeled “Settings,” which provides access to settings for the device 100 and its various applications 136 .

[0133] Note that the icon labels shown in FIG. 4A are merely exemplary. For example, icon 422 of video and music player module 152 is labeled "Music" or "Music Player." Other labels are optionally used for the various application icons. In some embodiments, the label for an individual application icon includes the name of the application that corresponds to the individual application icon. In some embodiments, the label of a particular application icon is different from the name of the application that corresponds to that particular application icon.

[0134] 4B shows an example user interface on a device (e.g., device 300 of FIG. 3) that has 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 359) that detect the intensity of a contact on touch-sensitive surface 451 and / or one or more tactile output generators 357 that generate a tactile output to a user of device 300.

[0135] Although some of the following examples are given with reference to input on touch screen display 112 (wherein 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, the touch-sensitive surface (e.g., 451 in FIG. 4B) has a primary axis (e.g., 452 in FIG. 4B) that corresponds to a primary 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 respective locations on the display (e.g., in FIG. 4B, 460 corresponds to 468 and 462 corresponds to 470). In this manner, 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 when the touch-sensitive surface is separate from the display. It is to be understood that similar methods are optionally used for the other user interfaces described herein.

[0136] In addition, while the following examples are given primarily with reference to finger input (e.g., finger contact, finger tap gesture, finger swipe gesture), 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 contact) followed by movement of 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 (e.g., instead of detecting a contact and then ceasing to detect the contact) while the cursor is located over the location of the tap gesture. Similarly, it should be understood that when multiple user inputs are detected simultaneously, multiple computer mice are optionally used simultaneously, or mice and finger contacts are optionally used simultaneously.

[0137] FIG. 5A illustrates an exemplary personal electronic device 500. Device 500 includes a body 502. In some embodiments, device 500 can 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 has a touch-sensitive display screen 504, hereafter touch screen 504. Alternatively, or in addition to touch screen 504, device 500 has a display and a touch-sensitive surface. Similar to devices 100 and 300, in some embodiments, touch screen 504 (or touch-sensitive surface) optionally includes one or more intensity sensors that detect the intensity of a contact (e.g., a touch) being applied. The one or more intensity sensors of touch screen 504 (or touch-sensitive surface) can provide output data that represents the intensity of the touch. A user interface of device 500 can respond to touch(s) based on their intensity, meaning that touches of different intensities can invoke different user interface actions on device 500.

[0138] For exemplary techniques for detecting and processing touch intensity, see, for example, 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," published as International Publication No. WO / 2013 / 169849, and International Patent Application No. PCT / US2013 / 069483, filed November 11, 2013, published as International Publication No. WO / 2014 / 105276, 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.

[0139] 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 straps, chains, pants, belts, shoes, wallets, backpacks, etc. These attachment mechanisms allow a user to wear device 500.

[0140] FIG. 5B illustrates an exemplary personal electronic device 500. In some embodiments, the device 500 can include some or all of the components described with respect to FIGS. 1A, 1B, and 3. The device 500 has a bus 512 that operably couples an I / O section 514 to one or more computer processors 516 and a memory 518. The I / O section 514 can be connected to a touch-sensitive display 504, which can have touch-sensing components 522 and optionally an intensity sensor 524 (e.g., a contact intensity sensor). In addition, the I / O section 514 can be connected to a communication unit 530 that receives application and operating system data using Wi-Fi, Bluetooth, near field communication (NFC), cellular, and / or other wireless communication technologies. The device 500 can include input mechanisms 506 and / or 508. The input mechanism 506 is optionally, for example, a rotatable input device or a depressible and rotatable input device. In some embodiments, input mechanism 508 is optionally a button.

[0141] In some embodiments, the input mechanism 508 is optionally a microphone. The personal electronic device 500 optionally includes 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 operatively connected to the I / O section 514.

[0142] The memory 518 of the personal electronic device 500 may include one or more non-transitory computer-readable storage media 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 below, including process 800 and process 900 (FIGS. 8 and 9). A computer-readable storage medium may be any medium that can tangibly contain or store computer-executable instructions for use by or in connection with an instruction execution system, apparatus, or device. In some embodiments, the storage medium is a transient computer-readable storage medium. In some embodiments, the storage medium is a non-transitory computer-readable storage medium. Non-transitory computer-readable storage media may include, but are not limited to, magnetic storage devices, optical storage devices, and / or semiconductor storage devices. Examples of such storage devices include magnetic disks, optical disks based on CDs, DVDs, or Blu-ray technology, as well as persistent solid-state memory such as flash, solid-state drives, and the like. The personal electronic device 500 is not limited to the components and configuration of FIG. 5B and may include other or additional components in multiple configurations.

[0143] As used herein, the term "affordance" refers to a user-interactive graphical user interface object, optionally displayed on a display screen of device 100, 300, and / or 500 (FIGS. 1A, 3, and 5A-5B). For example, images (e.g., icons), buttons, and text (e.g., hyperlinks) each, optionally, constitute an affordance.

[0144] The term "focus selector" as used herein refers to an input element that indicates the current portion of the user interface with which the user is interacting. In some implementations involving a cursor or other position marker, the cursor acts as the "focus selector," such that when an 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) while the cursor is positioned over a particular user interface element (e.g., a button, window, slider, or other user interface element), 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, a detected contact on the touchscreen acts as the "focus selector," such that when an 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 without a corresponding cursor movement or contact movement on the touch-screen display (e.g., by using a tab key or arrow keys to move focus from one button to another), and in these implementations the focus selector moves to follow the movement of focus between various regions of the user interface. Regardless of the specific form the focus selector takes, the focus selector is generally a user interface element (or contact on a touch-screen 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 which element of the user interface the user intends to interact through).For example, positioning of a focus selector (e.g., a cursor, contact, or selection box) over an individual button while a press input is detected on a touch-sensitive surface (e.g., a touchpad or touchscreen) indicates that the user intends to activate that individual button (and not other user interface elements shown on the device's display).

[0145] 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 predefined number of intensity samples, i.e., a set of intensity samples collected during a predefined time period (e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds) associated with a predefined event (e.g., after detecting a contact, before detecting a lift-off of the contact, before or after detecting the start of movement of the contact, before detecting an 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 a contact is optionally based on one or more of a maximum intensity of the contact, a mean value of the intensity of the contact, an average value of the intensity of the contact, a top 10 percentile value of the intensity of the contact, a half maximum intensity value of the contact, a 90th percentile value of the maximum intensity of the contact, etc. In some embodiments, the duration of the contact is used in determining 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 optionally includes a first intensity threshold and a second intensity threshold. In this example, a contact having a characteristic intensity not exceeding the first threshold results in a first action, a contact having a characteristic intensity above the first intensity threshold but not exceeding the second intensity threshold results in a second action, and a contact having a characteristic intensity above the second threshold results in a third action. In some embodiments, the comparison between the characteristic intensity and the one or more thresholds is not used to determine whether the first action or the second action should be performed, but rather is used to determine whether one or more actions should be performed (e.g., whether to perform an individual action or to forgo performing an individual action).

[0146] In some embodiments, a portion of the gesture is identified for purposes of determining the characteristic intensity. For example, the touch-sensitive surface optionally receives 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 is optionally based on only a portion of the successive swipe contacts (e.g., only the portion of the swipe contact at the end position) rather than the entire swipe contact. In some embodiments, a smoothing algorithm is optionally applied to the intensity of the swipe contact prior to 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 circumstances, these smoothing algorithms eliminate narrow spikes or dips in the swipe contact intensity for purposes of determining the characteristic intensity.

[0147] The intensity of the contact on the touch-sensitive surface is optionally characterized against 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 at which the device performs an action normally associated with clicking a physical mouse button or trackpad. In some embodiments, the deep pressure intensity threshold corresponds to an intensity at which the device performs an action different from an action normally associated with clicking a physical mouse button or trackpad. In some embodiments, when a contact is detected having a characteristic intensity below the light pressure intensity threshold (e.g., and above a nominal contact-detection intensity threshold below which the contact is not detected), the device follows the movement of the contact on the touch-sensitive surface and moves the focus selector without performing an action associated with the light pressure intensity threshold or the deep pressure intensity threshold. In general, unless otherwise specified, these intensity thresholds are consistent among various sets of values ​​for a user interface.

[0148] An increase in the characteristic intensity of a 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 inputting a "light press." An increase in the characteristic intensity of a contact from an intensity below the deep pressure intensity threshold to an intensity above the deep pressure intensity threshold may be referred to as inputting a "deep press." An increase in the characteristic intensity of a 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 a 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 a 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.

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

[0150] 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 predefined 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 an increase in the intensity of a discrete contact above the pressure input intensity threshold, followed by a decrease in the intensity of the contact below a hysteresis intensity threshold that corresponds to the pressure input intensity threshold, and a discrete action is performed in response to detecting a subsequent decrease in the intensity of the discrete contact below the hysteresis intensity threshold (e.g., an "upstroke" of the discrete 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 distinct 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).

[0151] For ease of explanation, descriptions of operations performed in response to a press input associated with a press input intensity threshold, or a gesture including a press input, are optionally triggered in response to detecting any of an increase in the intensity of a contact above the press input intensity threshold, an increase in the intensity of a contact from an intensity below a hysteresis intensity threshold to an intensity above the press input intensity threshold, a decrease in the intensity of a contact below the press input intensity threshold, and / or a decrease in the intensity of a contact below a hysteresis intensity threshold corresponding to the press input intensity threshold. Further, in examples where an operation is described as being performed in response to detecting a decrease in the intensity of a contact below a press input intensity threshold, the operation is optionally performed in response to detecting a decrease in the intensity of a contact below a hysteresis intensity threshold corresponding to and lower than the press input intensity threshold.

[0152] Attention is now directed to embodiments of user interfaces (“UI”) and associated processes implemented on an electronic device, such as portable multifunction device 100, device 300, or device 500.

[0153] 6A-6F illustrate example user interfaces for performing secure operations, according to some embodiments. Specifically, FIGS. 6A-6F illustrate example user interfaces that may be displayed during a scenario in which a secure transaction (e.g., transferring a parking spot between accounts) is completed in response to receiving one or more gestures and biometric data from a user of device 600. The user interfaces in these figures are used to illustrate the processes described below, including the processes in FIGS. 8 and 9. In some embodiments, the example user interfaces of FIGS. 6A-6F may be combined with or displayed simultaneously with the example user interfaces of FIGS. 7A-7M, described below.

[0154] 6A shows a device 600 displaying a user interface 602 on a touch-sensitive display. In some embodiments, device 600 includes one or more features of devices 100, 300, and 500 described above.

[0155] As shown in Figure 6A, user interface 602 includes application icons 604. Application icons 604 include a number of application icons for launching different applications that cause different user interfaces to be displayed on device 600. Application icons 604 include a parking application icon 604a for launching a parking application and a coffee shop application icon 604b for launching a coffee shop application. In Figure 6A, device 600 detects a tap gesture 650a on (e.g., toward and at a location corresponding to) parking application icon 604a.

[0156] 6B, in response to detecting the tap gesture 650a, the device 600 launches a parking application corresponding to the parking application icon 604a and displays a parking application user interface 610. The user interface 610 includes an account identifier 612, current parking information 614, and recommended parking information 616. The account identifier 612 indicates that the device 600 is currently logged into a particular account ("Jane's account") that is recognized by and / or belongs to (e.g., stored in a database in communication with) the parking application. The recommended parking information 616 includes information regarding one or more available parking spots that are recommended to a user of the device 600.

[0157] As shown in FIG. 6B, the current parking information 614 indicates that parking spot #31, located at Garage A at 123 Gala Street, is currently assigned to Jane's account. The current parking spot information 614 also includes a time frame (e.g., 9:00 AM-11:00 AM) during which parking spot #31 is assigned to Jane's account before parking spot #31 is automatically transferred back to the account associated with Garage A. Additionally, the current parking information includes a check-in control 618 for transferring parking spot #31 from Jane's account to an account belonging to Garage A. In FIG. 6B, the device 600 detects a tap gesture 650b on the check-in control 618.

[0158] As shown in FIG. 6C, in response to detecting tap gesture 650b, device 600 initiates a process to execute a transaction (e.g., execute a secure operation) including transferring parking spot #31 from Jane's account to an account associated with Garage A. As shown in FIG. 6C, in response to detecting tap gesture 650b, device 600 displays user interface 620 over a portion of user interface 610 and blurs the portion of user 610 that remains displayed in FIG. 6C. User interface 620 includes transaction information 622, confirmation instructions 624, and input instructions 626. Transaction information 622 includes information such as an email address (e.g., "jane-apples@mail.com") assigned (e.g., on file) to the particular account (e.g., "Jane's account") to which parking spot #31 is currently assigned, and an identifier associated with the account ("Garage A") to which parking spot #31 is to be transferred. In Figure 6C, the parking application is configured to perform a transfer operation using Jane's account (e.g., and / or an email address assigned to Jane's account). Confirmation instructions 624 indicate that an input must be received on hardware button 648 (e.g., a "side button") for the transaction to be initiated, and input instructions 626 indicate that hardware button 648 must be pressed twice quickly (e.g., a "double click") to initiate the transaction. In Figure 6C, device 600 detects a double click input 650c on hardware button 648.

[0159] 6D, in response to detecting double click input 650c, device 600 initiates an authentication process that causes camera 646a and / or camera 646b to capture an image to obtain biometric data (e.g., data corresponding to one or more features of the user's face). As part of the authentication process, device 600 also replaces confirmation instruction 624 with a biometric identification status indicator 628 to indicate that device 600 is about to capture an image to obtain biometric information.

[0160] In FIG. 6D, after capturing the set of images, device 600 acquires biometric data (e.g., one or more features of the user's face) to authenticate the user so that the transaction can be authorized. Device 600 uses the newly acquired biometric data to authenticate the current user of device 600 by matching (e.g., matching within a certain confidence level) this newly acquired biometric data to previously stored biometric data associated with known users who have authorization to complete secure transactions via device 600. In some embodiments, the biometric data (e.g., the previously stored biometric data and the newly captured biometric data) is accessible to an application for managing secure transactions (or operations) on device 600. In some embodiments, the parking application does not have access to the biometric data. In some embodiments, if device 600 is unable to match the newly acquired biometric data to the previously stored biometric data, device 600 continues to capture images to acquire additional biometric data to match to the previously stored biometric data. In some embodiments, device 600 only captures images for a predefined period of time. In some embodiments, if device 600 is unable to match the biometric data, device 600 displays an indication that the user of device 600 cannot be authenticated and therefore cannot transfer parking spot #31 to Garage A, and / or displays a control to complete authentication of the transaction in other ways (e.g., via entry of a password). In some embodiments, device 600 can authenticate the user by capturing and comparing other types of biometric data, such as finger data (e.g., captured via a touch-sensitive display including a fingerprint sensor), voice data (e.g., via one or more microphones), etc.In FIG. 6D, device 600 (or another device in communication with device 600) matches the newly acquired set of biometric data with the previously stored biometric data, thereby authenticating the current user of device 600 as a user with permission to complete a secure transaction via device 600.

[0161] In FIG. 6E, in response to authenticating the current user of device 600 as a user with permission to complete a secure transaction (e.g., via Jane's account), device 600 causes parking spot #31 to be transferred from Jane's account to Garage A's account. In some embodiments, device 600 causes parking spot #31 to be transferred from Jane's account to Garage A's account using a secure hardware component (e.g., a hardware chip) that stores information representative of Jane's account (e.g., Jane's email address, a device-specific account identifier). In some embodiments, the secure hardware component does not store or have access to primary information associated with Jane's account (e.g., a primary account number). In some embodiments, authenticating that the current user of device 600 has permission to complete a secure transaction allows device 600 to use the secure hardware component to complete the secure transaction.

[0162] As shown in FIG. 6E, in response to authenticating the current user of device 600 as a user with authorization to complete the secure transaction, device 600 also replaces biometric identification status indicator 628 with authenticated status indicator 630 to indicate that the user has been authenticated and the transfer has been completed.

[0163] 6F, after completing the transfer, device 600 ceases displaying user interface 620 and updates user interface 610 to indicate (e.g., via confirmation instruction 624) that parking spot #31 is no longer assigned to Jane's account. In addition, after completing the transfer, device 600 also receives and displays notification 632 (e.g., from one or more external devices) indicating that the transfer is complete.

[0164] Figures 7A-7M show example user interfaces for performing secure operations, according to some embodiments. Specifically, Figures 7A-7M show example user interfaces that may be displayed during a scenario attempting to complete one or more secure transactions in response to receiving one or more gestures on a touch-sensitive display of an automobile head unit 700 in communication with device 600. The user interfaces in these figures are used to illustrate the processes described below, including the processes in Figures 8 and 9.

[0165] 7A, device 600 is in operative communication with car head unit 700, as indicated by communication link 708. In some embodiments, device 600 is in operative communication with car head unit 700 via a wireless or wired connection. In some embodiments, car head unit 700 includes a touch-sensitive display and is mounted on the dashboard of the car. In some embodiments, car head unit 700 includes one or more features of devices 100, 300, and 500 described above.

[0166] As shown in FIG. 7A, the device 600 displays a user interface 670 including a lock indication 672 indicating that the device 600 is in a locked state (e.g., one of the displays or functions (e.g., display function, input function) available in the unlocked state is disabled / unavailable). While the device 600 is in the locked state, one or more operations that can be performed when the device 600 is in the unlocked state cannot be performed when the device 600 is in the locked state. The one or more operations include the device 600 performing one or more operations to interact with the automobile head unit 700 while the device 600 is in the locked state without receiving prior permission to interact. The one or more operations to interact with the automobile head unit 700 include causing (e.g., by sending commands and data) the automobile head unit 700 to display one or more user interface components (e.g., user interfaces, icons) corresponding to applications installed on the device 600.

[0167] In FIG. 7A , device 600 has not received previous permission to interact with car head unit 700 while device 600 is operating in a locked state. Thus, in FIG. 7A , device 600 causes car head unit 700 to display user interface 714. User interface 714 is displayed in response to device 600 detecting a connection (e.g., operational communication has been established) between car head unit 700 and device 600. User interface 714 includes instructions for a user to unlock device 600 to cause device 600 to perform one or more operations that cause device 600 to start “car player” on car head unit 700 and / or cause car head unit 700 to display one or more user interface components corresponding to applications installed on device 600.

[0168] As shown in FIG. 7A, while device 600 is operating in a locked state, device 600 displays notification 676 including instructions similar to those displayed on auto head unit 700 because device 600 has not received previous permission to interact with (e.g., provide data and / or receive data from) auto head unit 700. In some embodiments, when device 600 is in operative communication with another display device (e.g., auto head unit 700) and previous permission to interact with the other display device has been received, device 600 causes the other display device to display one or more user interface components corresponding to applications installed on device 600. In FIG. 7A, device 600 receives an upward swipe gesture 750a on user interface 670 and obtains biometric data (e.g., via one or more of cameras 646a and 646b) to authenticate the user to perform a secure operation to unlock device 600. In some embodiments, device 600 obtains biometric data (e.g., via cameras 646a and / or 646b) and / or authenticates a user of device 600 in order to unlock device 600 using one or more techniques similar to those described above (e.g., in response to detecting gesture 650c of FIG. 6C).

[0169] As shown in Figure 7B, in response to receiving the upward swipe gesture 750a and in response to authenticating the user of the device 600, the device 600 switches to operating in an unlocked state and ceases displaying the user interface 670. Further, in response to receiving the upward swipe gesture 750a and in response to authenticating the user of the device 600, the device 600 displays the user interface 602, including the application icons 604. In Figure 7B, the user interface 602 is displayed because it was the last user interface displayed by the device 600 before the device 600 entered the locked state.

[0170] As shown in FIG. 7B, because the device 600 is operating in an unlocked state, the device 600 causes the car head unit 700 to display a user interface 702 that includes an enlarged set of application icons 704. The application icons 704 include a parking application icon 704a that corresponds to the same application as the parking application icon 604a (e.g., launches an application on the car head unit 700 that matches (e.g., can access data from) the parking application of the application icon 604; causes the device 600 to display on the car head unit 700 an interface generated directly by the parking application on the device 600), and a coffee shop application icon 704b that corresponds to the same application as the coffee shop application icon 604b. The application icon 704 is larger than the application icon 604, such that the application icon 704 can be more readably seen and interacted with by a user operating the vehicle. In addition, the application icon 704 is a subset of the application icon 604. That is, the number of application icons 704 is less than the number of application icons 604, and some of the application icons included in application icons 604 are not included in application icons 704 (eg, the camera application icon).

[0171] As shown in FIG. 7B, in response to receiving an upward swipe gesture 750a and in response to authenticating the user of the device 600, the device 600 also displays a user interface 660 superimposed on the user interface 602. The device 600 displays the user interface 660 because the device 600 has not received previous permission to interact with the automobile head unit 700 while the device 600 is operating in a locked state. The user interface 660 includes a control 661 that allows interaction while locked. In FIG. 7B, the device 600 detects a tap gesture 750b on the control 661 that allows control while locked.

[0172] In FIG. 7C, in response to detecting a tap gesture 750b, the device 600 receives permission to interact with the car head unit 700 while the device 600 is operating in a locked state and ceases displaying the user interface 660. As shown in FIG. 7C, in response to detecting a tap gesture 750b, the device 600 displays a user interface 662 superimposed on the user interface 602. The user interface 662 is a user interface for setting a trust level assigned to the car head unit 700, which the device 600 uses to determine whether the car head unit 700 is trusted to initiate one or more secure operations, as described further below. As shown in FIG. 7C, the user interface 662 includes three options 664; an "always" option 664a, a "one time" option 664b, and a "never" option 664c.

[0173] When the "Always" option 664a is selected (e.g., via a gesture such as a tap gesture), the device 600 is configured to permanently trust the car head unit 700, such that the car head unit 700 is trusted by the device 600 until the device 600 is manually reconfigured (e.g., via one or more inputs on a different interface) to not trust the car head unit 700. Thus, in a scenario in which the device 600 is disconnected (e.g., operative communication ceases) after the option "Always" 664a is selected and is subsequently reconnected to the car head unit 700 (e.g., operative communication begins), the device 600 will not display the user interfaces shown in FIGS. 7A-7C because the car head unit 700 is a permanently trusted device.

[0174] When the "One Time" option 664b is selected, the device 600 is configured to temporarily trust the car head unit 700, such that the car head unit 700 is trusted by the device 600 until the device 600 is disconnected from the car head unit 700. Thus, in a scenario in which the device 600 is disconnected (e.g., operational communication ceases) after the "One Time" option 664b is selected and is subsequently reconnected to the car head unit 700 (e.g., operational communication begins), the device 600 will redisplay the user interfaces shown in Figures 7A-7C because the car head unit 700 is no longer a trusted device.

[0175] When the "No" option 664c is selected, the device 600 is configured to not trust the car head unit 700, such that the car head unit 700 is no longer a trusted device. Thus, in a scenario in which the device 600 is disconnected (e.g., ceases operative communication) after the "No" option 664c is selected and is subsequently reconnected (e.g., begins operative communication) to the car head unit 700, the device 600 will display the user interfaces shown in Figures 7A-7C because the car head unit 700 is not a trusted device.

[0176] FIG. 7C illustrates a user interface 662 including three options 664 for setting the trust level of the device 600 for the car head unit 700, which the car head unit 700 may or may not trust based on other factors. In some embodiments, the device 600 is configured to trust the car head unit 700 if the car head unit 700 is a particular type of display device, such as a display device from a particular manufacturer, or has a particular type of software installed. In some embodiments, the device 600 is configured to trust the car head unit 700 if the device 600 is physically connected to a vehicle that includes hardware (e.g., a secure identification chip) that is trusted by the device 600. In some embodiments, if the device 600 trusts the car head unit 700 based on other factors, the user interface 662 is not displayed in response to detecting the tap gesture 750b.

[0177] 7D-7E show example user interfaces that are displayed after the "Never" option 664c is selected in Fig. 7C. In Fig. 7C, the device 600 detects a tap gesture 750c3 on the "Never" option 664c.

[0178] In FIG. 7D, in response to detecting the tap gesture 750c3, the device 600 is configured such that the car head unit 700 is not a trusted device, as described above in connection with FIG. 7C. As shown in FIG. 7D, the device 600 is also in a locked state (e.g., as indicated by the lock indicator 672) because a predetermined time has elapsed since the tap gesture 750c3 was detected and the device 600 is configured to enter the locked state after a predetermined period of time has elapsed. In particular, the device 600 continues to interact with the car head unit 700 (e.g., display the user interface 702) while the device 600 is in the locked state because the device 600 has received permission to interact (e.g., via the tap gesture 750b on the control 661 that allows interaction while locked in FIG. 7B). In FIG. 7D, the device 600 receives an indication from the car head unit 700 that a tap gesture 752d1 was detected at a location on the car head unit 700 that corresponds to the parking application icon 704a.

[0179] As shown in FIG. 7E, in response to the device 600 receiving an indication that the tap gesture 752d1 has been detected, the device 600 causes the automobile head unit 700 to display a user interface 710. The user interface 710 corresponds to the user interface 610 described above in connection with FIGS. 6B-6D. Thus, the user interface 710 is a user interface of a parking application. In comparison to the user interface 610 of FIG. 6B, the user interface 710 includes less information than that displayed on the user interface 610 (e.g., does not include recommendation information on the user interface 710). Also, one or more similar components (e.g., account identifier 712) displayed on the user interface 710 are enlarged in comparison to the corresponding components (e.g., account identifier 612) on the user interface 610. However, the user interface 610 of FIG. 6B and the user interface 710 convey similar information.

[0180] As shown in Figure 7E, user interface 710 includes an account identifier 712 and current parking information 714 (e.g., displayed using similar techniques and for similar reasons as described above in connection with account identifier 612 and current parking information 614). As shown in Figure 7E, account identifier 712 indicates that device 600 is currently logged into "Jane's Account," and currently, parking information 714 indicates that parking spot #31 in Garage A is currently assigned to Jane's account.

[0181] In particular, as shown in FIG. 7E, device 600 does not display a control corresponding to check-in control 618 in response to device 600 receiving an indication that tap gesture 752d1 was detected. Here, device 600 does not display a control corresponding to check-in control 618 because automobile head unit 700 is not a trusted device (e.g., via tap gesture 750c3 on "never" option 664c). Instead of causing the check control to be displayed, device 600 causes automobile head unit 700 to display instructions 716 indicating that the user must complete a check-in process on device 600 (e.g., via one or more inputs on device 600, as described above in connection with FIGS. 6A-6E). In some embodiments, device 600 causes automobile head unit 700 to display instructions 716 even if the device is a trusted device if the parking application on device 600 does not have an account already on file (e.g., linked) with the application. Thus, in FIG. 7E, because the car head unit 700 is not trusted by the device 600, one or more inputs cannot be detected on the car head unit 700 that would cause the device 600 to complete a secure operation.

[0182] 7F-7I show exemplary user interfaces displayed after the "always" option 664a or the "once" option 644b is selected in FIG. 7C. In FIG. 7C, the device 600 detects a tap gesture 750c1 on the "always" option 664a or a tap gesture 750c2 on the "once" option 644b. In FIG. 7F, in response to detecting the tap gesture 750c1 or the tap gesture 750c2, the device 600 configures the car head unit 700 to be a trusted device (e.g., as described above in connection with FIG. 7C). In FIG. 7F, the car head unit 700 and the device 600 display respective user interfaces that are the same as the user interface displayed in FIG. 7D. In FIG. 7F, the device 600 receives an indication from the car head unit 700 that a tap gesture 752d1 was detected at a location on the car head unit 700 that corresponds to the parking application icon 704a.

[0183] As shown in FIG. 7G, in response to the device 600 receiving an indication that the tap gesture 752d1 was detected, the device 600 causes the automobile head unit 700 to display a user interface 710. The user interface 710 of FIG. 7G includes the same components as those described above in connection with the user interface of FIG. 7E, except for one separate component. As shown in FIG. 7G, the user interface 710 includes a check-in control 718 that was not displayed in FIG. 7E, and excludes the instructions 716 that were displayed in FIG. 7E. In FIG. 7G, the device 600 causes the automobile head unit 700 to display a check-in control because the automobile head unit 700 is trusted by the device 600 (e.g., via selection of the "always" option 664a or the "one time" option 644b). In FIG. 7C, a tap gesture 750c2 on the "Once" option 644b is detected, in some embodiments, when the user interface 710 is redisplayed after the device 600 is disconnected and then reconnected to the car head unit 700, the check-in control 718 is not displayed. In FIG. 7C, a tap gesture 750c1 on the "Always" option 644a is detected, in some embodiments, when the user interface 710 is redisplayed after the device 600 is disconnected and then reconnected to the car head unit 700, the check-in control 718 is displayed. In FIG. 7G, the device 600 receives an indication from the car head unit 700 that a tap gesture 752g was detected at a location on the car head unit 700 that corresponds to the check-in control 718. In some embodiments, if account information for Jane's account (e.g., Jane's email address) is not stored in the secure hardware component and is configured to be used to complete a transaction using the parking application, the check-in control 718 is not displayed.

[0184] As shown in Figure 7H, in response to receiving an indication that tap gesture 752g was detected, device 600 causes car head unit 700 to replace check-in control 718 with confirmation control 728. In Figure 7H, device 600 receives an indication from car head unit 700 that tap gesture 752h was detected at a location on car head unit 700 that corresponds to confirmation control 728.

[0185] In FIG. 7I , in response to receiving an indication that tap gesture 752h was detected, device 600 transfers parking spot #31 from Jane's account to Garage A's account. In some embodiments, the transfer occurs in response to tap gesture 752g on check-in control 718 without requiring further confirmation input. In FIG. 7I , once device 600 transfers parking spot #31 from Jane's account to Garage A's account, device 600 (not automobile head unit 700) communicates with one or more external devices (e.g., databases, account management servers) that update Jane's account information and Garage A's account information to perform the transfer. In some embodiments, information corresponding to Jane's account (e.g., Jane's email address) is stored in a secure hardware component of device 600, and device 600 accesses the information corresponding to Jane's account in the secure hardware component. In some embodiments, device 600 transmits the accessed information corresponding to Jane's account (e.g., or a token corresponding to the accessed information) to one or more external devices as part of performing the transfer.

[0186] Returning to FIGS. 6C-6D, device 600 transferred parking spot #31 after authenticating the user by capturing biometric data (e.g., via cameras 646a and 646b) in response to detecting a confirmation gesture (e.g., double-click input 650c). However, in FIG. 7H, device 600 transfers parking spot #31 from Jane's account to Garage A's account without authenticating the user of device 600 and / or car head unit 700 after receiving an indication that tap gesture 752h was detected. In FIG. 7H, device 600 does not need to authenticate the user by capturing biometric data because car head unit 700 is trusted by device 600. When the user is operating a vehicle, it may be useful for simplicity and safety reasons to allow a user of a trusted display device to complete a transaction without providing biometric data (or other authentication data) via device 600. In some embodiments, the device 600 does not also need to authenticate the user via biometric data because the device 600 previously authenticated the user when the device 600 was unlocked in FIGS. 6A-6B.

[0187] As shown in FIG. 7I, in response to receiving an indication that tap gesture 752h was detected, device 600 causes automobile head unit 700 to display transaction interface 720 including transaction information 722. Transaction interface 720 includes information regarding the completed transaction for transferring parking spot #31 from Jane's account to Garage A's account. Transaction information 722 is displayed using techniques similar to those described above in connection with transaction information 622 of FIG. 6E, where transaction information 722 and transaction information 622 are displayed using different layouts. In some embodiments, transaction information 722 and transaction information 622 are displayed using the same layout.

[0188] 7J-7L show example user interfaces that are displayed in a scenario where the user is attempting to complete another type of transaction (e.g., a payment transaction) with a different application (e.g., a coffee shop application) after "always" option 664a or "one time" option 644b is selected in FIG. 7C. Returning to FIG. 7F (or FIG. 7D), device 600 receives an indication from automobile head unit 700 that a tap gesture 752d2 was detected at a location on automobile head unit 700 that corresponds to coffee shop application icon 704b.

[0189] As shown in FIG. 7J, in response to receiving an indication that tap gesture 752d2 was detected, device 600 causes car head unit 700 to display user interface 730, which is a user interface of a coffee shop application. User interface 730 includes order recommendation 734 along with purchase control 738. In FIG. 7J, device 600 causes car head unit 700 to display purchase control 738 because car head unit 700 is a trusted device (e.g., “always” option 664a or “one time” option 644b was previously selected in FIG. 7C). In some embodiments, device 600 does not cause car head unit 700 to display purchase control 738 if car head unit 700 is not trusted by device 600. In some embodiments, car head unit 700 can display instructions (e.g., similar to instructions 716, as described above with reference to FIG. 7E) indicating that device 600 should be used to purchase an item from the coffee shop. In FIG. 7J, the device 600 receives an indication from the car head unit 700 that a tap gesture 752j was detected at a location on the car head unit 700 corresponding to the confirmation control 728.

[0190] As shown in FIG. 7K, in response to receiving an indication that tap gesture 752j was detected, device 600 causes automobile head unit 700 to display user interface 740. User interface 740 is a user interface for purchasing an order associated with Jane's account. In FIG. 7J, Jane's account is associated with a favorite order that includes a cup of cold brew coffee priced at $2.59. As shown in FIG. 7J, Jane's account is also associated with a card representation 734 ("Jane's card"), which is a representation of a payment card linked to a bank account associated with Jane. As shown in FIG. 7J, user interface 740 also includes an order confirmation control 742 that is similar to confirmation control 728 of FIG. 7H. In FIG. 7K, device 600 receives an indication from automobile head unit 700 that tap gesture 752k was detected at a location on automobile head unit 700 that corresponds to confirmation control 728.

[0191] As shown in FIG. 7L, in response to receiving an indication that tap gesture 752k was detected, device 600 causes $2.59 to be transferred from the bank account associated with Jane's card to the bank account associated with Garage A (and / or the parking application) without capturing biometric data (e.g., for reasons similar to those described above in connection with FIG. 7I) and / or authenticating the user of car head unit 700 and / or device 600. In FIG. 7L, as device 600 causes the transfer of money from the bank account associated with Jane's card to the bank account associated with Garage A, device 600 (not car head unit 700) communicates with one or more external devices (e.g., databases, account management servers) that update the balances of Jane's account and Garage A's account to reflect the completed transaction. In some embodiments, device 600 causes the transfer of money from Jane's account to Garage A's account using a secure hardware component (e.g., a hardware chip) that has stored information representing the account number associated with Jane's card. In some embodiments, the secure hardware component does not store or have access to the primary information associated with Jane's card (e.g., the primary account number). In some embodiments, if device 600 is not configured to process transactions using Jane's card, device 600 cannot process transactions and device 600 does not display purchase controls 638 in user interface 730, regardless of whether automobile head unit 700 is trusted by device 600.

[0192] As shown in Figure 7L, in response to receiving an indication that tap gesture 752k was detected, device 600 causes automobile head unit 700 to display user interface 760 including transaction information 762. Transaction information 762 displays similar information as transaction information 722, as described above with respect to Figure 7L. Additionally, transaction information 762 in Figure 7L is displayed using the same layout as transaction information 722 in Figure 7L. As shown in Figure 7L, transaction information 762 indicates that $2.59 was transferred from an account associated with Jane's card indicated by card representation 762.

[0193] FIG. 7M illustrates device 600 displaying a settings user interface with setting 772. Setting 772 is enabled (e.g., "on") and is a setting for allowing transactions to be processed via gestures received at automobile head unit 700. Returning to the example described above in connection with FIGS. 7A-7M, device 600 could have various transactions processed in response to detecting gestures received on automobile head unit 700 if automobile head unit 700 was trusted by device 600. Thus, in the example described above in connection with FIGS. 7A-7M, setting 772 was on. In some embodiments, if setting 772 is off, device 600 cannot have various transactions processed in response to detecting gestures received on automobile head unit 700, regardless of whether automobile head unit 700 is trusted by device 600. In some embodiments, one or more other settings similar to setting 772 exist. These settings can allow a user of device 600 to control whether device 600 can have various transactions processed for a particular application. In some embodiments, device 600 is configured (e.g., via one or more settings) to be able to process transactions for a parking spot application, but not for a coffee shop application, via gestures received at automobile head unit 700.Thus, in some of these embodiments, regardless of whether the automobile head unit 700 is trusted by the device 600, the device 600 causes the automobile head unit 700 to display a transaction control (e.g., a check control 718) when it causes one or more user interfaces of a parking application (e.g., user interface 710 of FIG. 7G) to be displayed on the automobile head unit 700, and the device 600 does not cause the automobile head unit 700 to display a transaction control (e.g., a purchase control 738) when it causes one or more user interfaces of a coffee shop application (e.g., user interface 710 of FIG. 7G) to be displayed on the automobile head unit 700.

[0194] 8 is a flow diagram illustrating a method of performing secure operations using a computer system, according to some embodiments. Method 800 is performed in a computer system (e.g., 100, 300, 500, 600). The computer system (e.g., 600) communicates (e.g., wirelessly, wired) with an external automobile head unit (e.g., 700) (e.g., integrated hardware interfaces (e.g., stereo head unit, infotainment system) of the automobile's multiple entertainment and information systems (e.g., sound, navigation)) that includes one or more input components (e.g., touch-sensitive surface (e.g., touch screen), hardware buttons), and the computer system communicates with an external receiving device (e.g., transaction management server, payment terminal). Some operations of method 800 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0195] As described below, the method 800 provides an intuitive way to perform secure operations using a computer system. The method reduces the cognitive burden on a user performing secure operations using a computer system, thereby creating a more efficient human-machine interface. The method also enables a user to perform secure operations using a computer system more safely and securely. In the case of battery-operated computing devices, power is conserved and the time between battery charges is increased by enabling a user to perform operations using a computer system faster and more efficiently.

[0196] The computer system receives (802) from the external automobile head unit (e.g., 700) first data corresponding to input (e.g., 752g, 752h, 752j, 752k) received at one or more input components of the external automobile head unit (e.g., 700) (e.g., selection of a payment selectable user interface object) corresponding to a request to perform a first transfer operation from a first account (e.g., Jane's account as indicated by 712, Jane's card as indicated by 734) (e.g., an account associated with a user of the computer system, a credit account, a debit account, a cash balance account) to a second account (e.g., garage account, coffee shop account) (e.g., an account associated with a merchant) using an application (e.g., digital storefront application, digital wallet application, e-commerce application) on the computer system (e.g., 600) associated with the first account.

[0197] In response to receiving the first data (e.g., data associated with input 752g, 752h, 752j, or 752k), the computer system initiates (804) a process (e.g., a process that may require one or more additional inputs (e.g., inputs at the computer system to be fully completed)) to perform a first transfer operation (e.g., a transaction (e.g., a payment transaction, a purchase)) using an application on the computer system. In some embodiments, in response to receiving the first data, the first operation is performed. In some embodiments, the first data includes one or more parameters or variables that affect the operation (e.g., amount of purchase, items for purchase). As part of performing the first transfer operation, the computer system transmits to the external receiving device second data that includes information identifying the first account (e.g., an encrypted representation of the account (e.g., device-specific account number) stored on the computer system, a representation of a payment account (e.g., credit, debit, and / or cash balance account)). In some embodiments, the second data includes information other than the account identifier (e.g., transaction parameters (e.g., price, amount)). Performing a transfer operation using an application on the computer system based on inputs on the automobile head unit provides a user with the ability to perform the transfer operation without having to directly interact with the computer system. Performing the operation without having to directly interact with the computer system can increase the safety of a user while using the computer system and operating an automobile. Performing a transfer operation using an application on the computer system based on inputs on the automobile head unit also provides a user with the option to perform the operation using inputs on the head unit.Providing additional control options improves operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0198] In some embodiments, an application (e.g., an application shown at 604a, 704a, 604b, 704b) was (e.g., and remains) configured to perform a transfer operation from a first account prior to receiving the first data (e.g., the first account was previously associated with the application (e.g., the first account is on file with the application)). In some embodiments, a second application not previously configured to perform a transfer operation from an existing account (e.g., the first account) cannot be used with the external automobile head unit to perform a transfer operation (e.g., until the second application is associated with the existing account). Performing the transfer operation using an application on a computer system that was already configured to perform the operation using the first account reduces the risk of an erroneous operation (e.g., by reducing the risk of using an incorrect account or an error in providing account information). Improves operability of the computer system by reducing the risk of errors when operating the computer system; makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors); and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0199] In some embodiments, a second application (e.g., application shown at 604a, 704a, 604b, 704b) different from the first application (e.g., application shown at 604a, 704a, 604b, 704b) is installed on the computer system (e.g., 600). In some embodiments, pursuant to (e.g., pursuant to a determination that) the second application (e.g., application shown at 604a, 704a, 604b, 704b) is configured to perform a transfer operation from a third account (e.g., Jane's account as shown by 712, Jane's card as shown by 734) (e.g., an account different from the first account, the same account as the first account), the second application is configured to perform a transfer operation in response to a request received from the external automobile head unit (e.g., 700) to perform a transfer operation from the third account (e.g., Jane's account, Jane's card). In some embodiments, pursuant to (e.g., pursuant to a determination that) the second application (e.g., the application shown at 604a, 704a, 604b, 704b) is not configured to perform a transfer operation from a third account (e.g., not configured (e.g., pre-configured) to perform a transfer operation from any existing account). In some embodiments, the second application is not configured to perform a transfer operation in response to a request (e.g., 752g, 752h, 752j, 752k) received from the external car head unit (e.g., 700) to perform a transfer operation from a third account (e.g., Jane's account as shown by 712, Jane's card as shown by 734). In some embodiments, only installed applications that are already configured to perform a transfer operation from one or more existing accounts may perform a transfer operation based on input received at the external car head unit.Performing a transfer operation using an application on a computer system based on whether a given application is already configured to perform the operation using an account reduces the risk of erroneous operation (e.g., by reducing the risk of using an incorrect account or an error in providing account information), improves operability of the computer system by reducing the risk of error in operating the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0200] In some embodiments, the second application is configured to perform a transfer operation from a third account. In some embodiments, the computer system receives third data (e.g., prior to receiving the first data, after receiving the first data) corresponding to an input (e.g., 752g, 752h, 752j, 752k) (e.g., selection of a payment selectable user interface object) received at one or more input components of the external automobile head unit (e.g., 700) that corresponds to a request to perform a second transfer operation from a third account (e.g., Jane's account as indicated by 712, Jane's card as indicated by 734) (e.g., an account associated with a user of the computer system, a credit account, a debit account, a cash balance account) to a fourth account (e.g., Garage A's account, Coffee Shop's account) (e.g., an account associated with a merchant, an account the same as the second account, a different account from the second account) using a second application (e.g., an application indicated by 604a, 704a, 604b, 704b). In some embodiments, in response to receiving the third data, the computer system initiates a process (e.g., a process that may require one or more additional inputs (e.g., inputs at the computer system to fully complete)) using a second application (e.g., an application shown at 604a, 704a, 604b, 704b) to perform a second transfer operation (e.g., a transaction (e.g., a payment transaction, a purchase)) (and in some embodiments, to perform the first operation in response to receiving the first data). In some embodiments, the first data includes one or more parameters or variables that affect the operation (e.g., the amount of the purchase, the items for the purchase).In some embodiments, as part of performing the second transfer operation, the computer system transmits to the external receiving device fourth data (e.g., an encrypted representation of an account (e.g., a device-specific account number) stored on the computer system, a representation of a payment account (e.g., a credit, debit, and / or cash balance account)) that includes information identifying a third account (e.g., Jane's account as shown by 712, Jane's card as shown by 734). In some embodiments, the second data includes information other than the account identifier (e.g., transaction parameters (e.g., price, amount)). Performing the second transfer operation using a second application on the computer system based on inputs on the automobile head unit provides the user with the ability to perform the second transfer operation without having to directly interact with the computer system. Performing the operation without having to directly interact with the computer system can increase user safety while using the computer system and operating the automobile. Performing the transfer operation using an application on the computer system based on inputs on the automobile head unit also provides the user with the option to perform the operation using inputs on the head unit. Providing additional control options improves operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0201] In some embodiments, the computer system (e.g., 600) communicates with (e.g., includes) a display generating component (e.g., a display (e.g., an integrated touch screen display)) that is in a locked state (e.g., 760) (e.g., a state in which one of the displays (e.g., a display that is available in an unlocked state) or functions (e.g., display function, input function) are disabled / unavailable) while the computer system (e.g., 600) is receiving the first data. Also, performing a transfer operation using an application on the computer system based on an input on the automobile head unit while the computer system is in the locked state provides the user with the option to perform an operation using an input on the head unit without having to separately unlock the computer system, which can reduce the risk of unintended input on the computer system, and by doing so increases the security of the system by allowing the computer system to remain in the locked state more frequently (e.g., while still usable). Improves usability of the computer system by providing additional control options and improving security; makes the user-device interface more efficient and secure (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors); and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly, efficiently, and securely.

[0202] In some embodiments, the external car head unit (e.g., 700) is authorized (e.g., prior to receiving the first data) to request execution of a transfer operation from a first account (e.g., Jane's account as shown by 712, Jane's card as shown by 734) (e.g., as well as from other accounts accessible to and / or stored on the computer system) (e.g., the external car head unit is a trusted unit, authorized via input from a user). In some embodiments, an unauthorized (e.g., untrusted) external car head unit cannot request execution of a transfer operation from an account accessible to and / or stored on the computer system. Performing the transfer operation using an application on the computer system based on input on the car head unit only if the car head unit is authorized reduces the risk of unauthorized operation (e.g., especially when the user of the computer system does not control the input provided at the head unit). Improves the operability of the computer system by reducing the risk of unauthorized operation and improving the security of the computer system; makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors); and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0203] In some embodiments, prior to detecting the first data (e.g., data associated with input 752g, 752h, 752j, or 752k), the computer system receives a first set of one or more inputs (e.g., 750c1, 750c2) (e.g., inputs at the external automobile head unit and / or the computer system). In some embodiments, in response to the first set of one or more inputs (e.g., 750a, 750b 750c1, 7502), the computer system allows (e.g., before communicating with) the external automobile head unit (e.g., 700) to connect to the computer system (e.g., 600) while the computer system is in a locked state (e.g., 760) (e.g., a state in which one or more features of the computer system available while in an unlocked state are unavailable) and allows the external automobile head unit (e.g., 700) to request to perform a transfer operation from the first account (e.g., as well as from other accounts accessible to and / or stored on the computer system). By permitting the external automobile head unit to request execution of a transfer operation based on previous user input, it provides additional control options to the user and reduces the need for authorization input for each operation. By providing additional control options and performing operations without requiring input at specific times, it improves operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves device battery life by allowing the user to use the computer system more quickly and efficiently. Also, by performing the transfer operation with an authorized (e.g., trusted) external automobile head unit, it increases security by reducing the risk of unauthorized requests for transfer operations.Improves the operability of the computer system by reducing the risk of unauthorized operation and improving the security of the computer system; makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors); and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0204] In some embodiments, while the computer system is in communication with (e.g., connected to) an external car unit (e.g., 700) and while the computer system (e.g., 600) is in a locked state (e.g., 760) (e.g., a state in which one or more features of the computer system available while in the unlocked state are unavailable), the computer system receives a second set of one or more inputs (e.g., 750a). In some embodiments, in response to the second set of one or more inputs (e.g., 750a), the computer system transitions the computer system (e.g., 600) to an unlocked state (e.g., 602) (e.g., a state in which one or more features of the computer system that were unavailable while in the locked state are available) and authorizes the external car head unit (e.g., 700) to request the execution of a transfer operation from the first account (e.g., as well as from other accounts accessible to and / or stored on the computer system). In some embodiments, the authorizing occurs simultaneously as part of (e.g., is a result of) transitioning the computer system to the unlocked state. By permitting the external automobile head unit to request execution of a transfer operation based on a user input that also unlocks the computer system, the number of inputs required to perform the set of operations is reduced, and the risk of unintended operation of the computer system is also reduced because unlocking the computer system correlates with intended use of the system. Reducing the number of inputs required to perform the set of operations and reducing the risk of unintended operation inputs improves usability of the device, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and additionally reduces power usage and improves battery life of the device by allowing the user to use the device more quickly and efficiently.Improves security by providing a user with the option to link the unit's authorization with another authorization function by authorizing an external automobile head unit to request execution of a transfer operation based on user input that also unlocks the computer system, improves usability of the computer system by improving the security of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0205] In some embodiments, prior to receiving the first data (e.g., data associated with input 752g, 752h, 752j, or 752k), the computer system transmits to the automobile head unit fifth data including one or more user interface elements (e.g., 718, 738) to be displayed by the automobile head unit. In some embodiments, the one or more user interface elements include one or more elements associated with an application (e.g., an identifier for the application) and / or associated with the first account (e.g., an identifier for the first account). Transmitting the data including the one or more user interface elements to be displayed by the automobile head unit provides visual feedback to the user regarding the computer system and its connection to the head unit. Providing improved visual feedback to the user improves operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), as well as reducing power usage and improving battery life of the computer system by allowing the user to use the computer system more quickly and efficiently.

[0206] In some embodiments, the computer system (e.g., 600) is a smartphone (e.g., a mobile computing device configured to make and receive telephone calls over a cellular network) that includes a hardware secure element (e.g., a chip that stores information representing an account (e.g., account related information such as a device-specific account number (e.g., different from the account number) provided by an issuer of the account) that is not directly accessible to the computer system's operating system or installed applications. In some embodiments, the secure element does not store or have access to the primary account number. In some embodiments, the secure element provides, as part of the transfer operation, an encrypted version of the device-specific account number (e.g., a version unique to a given transaction) that is decrypted by the account issuer to identify the account). In some embodiments, the information identifying the first account is stored in the hardware secure element.

[0207] In some embodiments, while the computer system (e.g., 600) is communicating with a second external automobile head unit (e.g., 700) including one or more input components different from the external automobile head unit (e.g., 700) and a second external receiving device (806), the computer system receives sixth data from the second external automobile head unit (e.g., 700) corresponding to input (e.g., 752g, 752h, 752j, 752k) received at one or more input components of the second external automobile head unit corresponding to a request to perform a third transfer operation from the first account to a fifth account (e.g., an account associated with a supplier) using an application (e.g., a digital storefront application, a digital wallet application, an e-commerce application, an application different from the first or second application, the same application as the first and / or second application) (808). In some embodiments, while the computer system (e.g., 600) is in communication with a second external automobile head unit (e.g., 700) including one or more input components and a second external receiving device (806), the computer system, in response to receiving the sixth data, initiates (810) a process to perform a third transfer operation using an application on the computer system (e.g., 600) (e.g., a process that may require one or more additional inputs (e.g., inputs at the computer system to complete). In some embodiments, as part of performing the third transfer operation, the computer system transmits to the second external receiving device seventh data including information identifying the first account (e.g., an encrypted representation of the account (e.g., device-specific account number) stored on the computer system, a representation of a payment account (e.g., credit, debit, and / or cash balance account)). In some embodiments, the first operation is performed in response to receiving the first data. In some embodiments, the second data includes information other than the account identifier (e.g., transaction parameters (e.g., price, amount)).Providing a user with additional options for operating the computer system by providing the ability to request a different head unit to transfer operations on the computer system, improving operability of the computer system by providing additional control options and performing operations without requiring input at specific times, making the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reducing power usage and improving battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0208] It should be noted that the details of the process described above in connection with method 800 (e.g., FIG. 8) are also applicable in a similar manner to the methods described below. For example, method 800 optionally includes one or more of the characteristics of the various methods described below with reference to method 900. For example, method 800 may be used to initiate a process of performing a first transfer operation (e.g., 804) if (e.g., at 906) the external input device meets a set of authorization criteria and provides an option to initiate a secure transaction. For the sake of brevity, these details will not be repeated below.

[0209] 9 is a flow diagram illustrating a method of providing an option to initiate a secure operation using a computer system, according to some embodiments. Method 900 is performed on a computer system (e.g., 100, 300, 500, 600). Some operations of method 900 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0210] As described below, method 900 provides an intuitive way to provide an option to initiate a secure operation using a computer system. The method reduces the cognitive burden on a user of providing an option to initiate a secure operation using a computer system, thereby creating a more efficient human-machine interface. The method also enables a user to perform a secure operation using a computer system more safely and securely. In the case of battery-operated computing devices, power is conserved and the time between battery charges is increased by enabling a user to more quickly and efficiently provide an option to initiate a secure operation using a computer system.

[0211] While the computer system (e.g., 600) is connected to an external input device (e.g., 700) (e.g., an automobile head unit (e.g., an integrated hardware interface (e.g., stereo head unit, infotainment system) of the automobile's multiple entertainment and information systems (e.g., sound, navigation))), the computer system may perform secure transactions (e.g., transfer of resources (e.g., credit, funds) from a first account (e.g., an account associated with a user of the computer system) to a second account (e.g., an account associated with a merchant) (e.g., entry of a passcode) that, if authorized by the computer system (e.g., 600), requires separate authorization (e.g., 646a, 646b, 638) from the user. a first request (e.g., 752d1, 752d2) (e.g., selection of an option or variable) from an external input device to interact with a first portion of a user interface (e.g., 710, 730) (e.g., an interface of a digital storefront application, a digital wallet application, an e-commerce application, an interface displayed on the external input device (e.g., generated at least in part based on data from the computer system)) associated with a transaction that, when performed on the computer system, requires additional authentication via one or more inputs received via one or more input devices of the computer system, such as a fingerprint, facial recognition, iris recognition, or other biometric authentication (902).

[0212] In response to receiving a first request (e.g., 752d1, 752d2) (904), and following a determination that the external input device (e.g., 700) meets a set of authorization criteria (e.g., a set of criteria that are met if the external input device is authorized by previous user input, if the external input device is a first type of device, and / or if the external input device is not a second type of device), the computer system provides (906) an option (e.g., 718) to initiate a secure transaction (e.g., a selectable user interface object, a prompt (e.g., a visual or audio prompt) to use one or more input devices (e.g., a touch-sensitive surface, a microphone) of the external input device) via the external input device (e.g., 700) without requesting separate authorization from the user.

[0213] In response to receiving (904) the first request (e.g., 752d1, 752d2) and in accordance with a determination that the external input device (e.g., 700) does not meet the set of authorization criteria, the computer system ceases to provide (912) the option to initiate a secure transaction (e.g., 716 in FIG. 7E) without requesting separate authorization from the user. In some embodiments, as part of ceasing to provide the option to initiate a secure transaction without requesting separate authorization from the user, the computer system provides a second option to initiate a secure transaction that requires separate authorization from the user at the external input device and / or the computer system. Providing an option to initiate a secure transaction without requesting separate authorization from the user in response to a request at the external input device provides the user with an option to perform a secure transaction without requesting separate authorization and without having to directly interact with the computer system. Providing an option to perform an operation without having to directly interact with the computer system and reducing the number of inputs required can increase ease of use of the computer, which also provides the user with an option to perform an operation using inputs on the external input device. Improve operability of the computer system by providing additional control options, make the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduce power usage and improve battery life of the device by allowing the user to use the computer system more quickly and efficiently. Increase security by providing an option to initiate a secure transaction if the external input device meets a set of authorization criteria, and by not providing the option if the external input device does not meet the criteria.Improving the security of the computer system improves the operability of the computer system, making the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reducing power usage and improving battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0214] In some embodiments, the external input device (e.g., 700) is an external automobile head unit (e.g., an integrated hardware interface for multiple entertainment and information systems (e.g., sound, navigation) in an automobile (e.g., stereo head unit, infotainment system)). In some embodiments, the computer system (e.g., 600) is a smartphone (e.g., a mobile computing device configured to make and receive telephone calls over a cellular network) that includes a hardware secure element (e.g., a chip that stores information representing an account that is not directly accessible to the computer system's operating system or installed applications (e.g., account related information such as a device-specific account number provided by the account issuer (e.g., different from the account number)). In some embodiments, the secure element does not store or have access to the primary account number. In some embodiments, the secure element provides an encrypted version of the device-specific account number (e.g., a version unique to a given transaction) that is decrypted by the account issuer to identify the account as part of the transfer operation.

[0215] In some embodiments, the computer system (e.g., 600) includes one or more external device communication interfaces (e.g., a communication system, a wired communication bus, a wireless communication bus, a data bus) for transferring data between the computer system and one or more external devices. In some embodiments, the computer system detects a connection (e.g., 708) of the computer system to an external input device via the one or more external device communication interfaces. In some embodiments, the first request (e.g., 752d1, 752d2) is received after detecting the connection of the computer system to the external input device.

[0216] In some embodiments, the computer system (e.g., 600) communicates with one or more hardware input devices (e.g., a touch-sensitive display of 600) (e.g., a touch-sensitive surface (e.g., a touch screen), a microphone, a biometric reader (e.g., a fingerprint reader, an optical sensor for detecting facial features, and / or a depth sensor)). In some embodiments, the secure transaction requires permission from the user (e.g., permission to perform the secure transaction using information from a hardware secure element (e.g., a chip that stores account information that is not directly accessible to the operating system or installed applications of the computer system) that stores information for use in the secure transaction (e.g., account information, information identifying an account)) provided via one or more hardware input devices if authorized by the computer system (e.g., not an external input device). In some embodiments, a computer receives a request at the computer system to perform a secure transaction. In some embodiments, the computer system performs the secure transaction after receiving a first request and pursuant to a determination that permission was provided via the one or more hardware input devices (e.g., provided prior to receiving the first request, provided after receiving the first request). Improve security by reducing the risk of unauthorized requests by requesting permission to perform a secure transaction, improve the usability of the computer system by improving the security of the computer system, make the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduce power usage and improve battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0217] In some embodiments, the one or more hardware input devices include a biometric reader (e.g., 646a, 646b) (e.g., a fingerprint reader, an optical sensor for detecting facial features, and / or a depth sensor), and authorization from the user provided via the one or more hardware input devices is a biometric authorization (e.g., as shown at 628, 630) (e.g., an authorized fingerprint scan or an authorized face scan) received via the biometric reader (e.g., 646a, 646b) (e.g., authorization to perform a secure transaction using information from a hardware secure element (e.g., a chip that stores account information that is not directly accessible to the operating system or installed applications of the computer system) that stores information for use in a secure transaction (account information, information that identifies an account). Requiring authorization via a biometric reader improves security by reducing the risk of unauthorized requests. Improving the security of the computer system improves the operability of the computer system, making the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reducing power usage and improving battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0218] In some embodiments, after providing an option (e.g., 718) to initiate a secure transaction without requesting separate permission from the user, the computer system receives (908) from the external input device (e.g., 700) a request (e.g., 752g, 752h) to proceed with the secure transaction (e.g., an input, a selection of a payment selectable user interface object displayed on a display of the external input device, a voice command received at the external input device). In some embodiments, as part of providing the option, the computer system transmits data to the external input device including one or more user interface elements to be displayed by the external input device. In some embodiments, in response to receiving a request from an external input device (e.g., 700) to proceed with the secure transaction, the computer system executes (910) the secure transaction including securely transmitting first data (e.g., an encrypted representation of an account (e.g., device-specific account number) stored on the computer system, a representation of a payment account (e.g., credit, debit, and / or cash balance account)) including information identifying a first account (e.g., “Jane’s Account” as shown by 612, 712, “Jane’s Card” as shown by 734) for use in the secure transaction to an external receiving device (e.g., transaction management server, payment terminal). In some embodiments, the second data includes information other than the account identifier (e.g., transaction parameters (e.g., price, amount)). Executing the secure transaction based on a request from the external input device provides a user with an option to perform an action using input at the external input device.Providing additional control options improves operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0219] In some embodiments, the computer system (e.g., 600) communicates with (e.g., includes) a display generating component (e.g., a display (e.g., an integrated touch screen display)). In some embodiments, performing the secure transaction (e.g., including securely transmitting first data including information identifying the first account to an external receiving device) occurs while the display generating component is in a locked state (e.g., 670) (e.g., a state in which one of the displays or functions (e.g., display function, input function) available in the unlocked state is disabled / unavailable). Performing the secure transaction while the display generating component communicating with the computer system is in a locked state provides the user with the option to perform the transaction without having to interact with the display generating component (e.g., see or provide input directed to the component). Providing additional control options improves the usability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves the battery life of the device by allowing the user to use the computer system more quickly and efficiently. Also, performing secure transactions while display generating components communicating with the computer system are in a locked state increases security by allowing the computer system to remain in a locked state while still allowing interaction via external input devices. Improving the security of the computer system improves the usability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and also reduces power usage and improves battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0220] In some embodiments, the secure transaction is performed using a first application (e.g., an application corresponding to 604a, 604b) on a computer system (e.g., 600). In some embodiments, the user interface (e.g., 720, 760) is an interface displayed on an external input device (e.g., 700). In some embodiments, the user interface (e.g., 720, 760) is arranged according to a first interface layout template (e.g., a scheme for arranging graphical elements and / or content of an interface) and includes information (e.g., 722, 762) provided by the first application (e.g., an application corresponding to 604a, 604b) (e.g., an identifier (e.g., text and / or graphics) of the first application, parameters affecting the execution of the secure transaction (e.g., amount of credits or currency to be transferred, services or goods to be purchased), identifiers of accounts used in the secure transaction). In some embodiments, the computer system receives a second request (e.g., 752d1, 752d2) from the external input device (e.g., 700) to interact with a first portion of a second user interface (e.g., 720, 760) (e.g., an interface that is the same as the user interface, an interface that is different from the user interface) that is displayed on the external input device (e.g., 700) and that is associated with a second secure transaction performed using a second application (e.g., an application corresponding to 604a, 604b) on the computer system (e.g., 600), which, if authorized by the computer system (e.g., 600), requests separate authorization from the user. In some embodiments, the second application (e.g., an application corresponding to 604a, 604b) is different from the first application.In some embodiments, the second user interface (e.g., 720, 760) is arranged according to the first interface layout template and includes information (e.g., 722, 762) provided by the second application (e.g., application corresponding to 604a, 604b) (e.g., an identifier (e.g., text and / or graphics) of the second application, parameters affecting the execution of the secure transaction (e.g., amount of credit or currency to be transferred, service or product to be purchased), identifier of the account used in the second secure transaction). Arranging interfaces corresponding to different applications for performing different secure transactions according to the same interface layout provides the user with improved visual feedback that consistently informs the user about aspects of the secure transaction. Providing the user with improved visual feedback improves the operability of the computer system, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and additionally reduces power usage and improves battery life of the computer system by allowing the user to use the computer system more quickly and efficiently.

[0221] In some embodiments, the set of authorization criteria is met if the computer system receives a first set of one or more inputs (e.g., 750a) (e.g., selection of an option in a peripheral management interface, a set of inputs received at the external input device, a set of inputs received at the computer system) before receiving the first request (e.g., 752d1, 752d2) (e.g., and while not detecting movement of the automobile connected to the external input device). In some embodiments, in response to the first set of one or more inputs (e.g., 750a), the computer system has authorized (e.g., before communicating with) the external input device (e.g., 700) to be connected to the computer system (e.g., 600) while the computer system is in a locked state (e.g., 670) (e.g., a state in which one or more features of the computer system available while in an unlocked state are unavailable). Allowing the connection of the external input device to the computer system while the computer system is in a locked state provides additional control options to the user and reduces the need for authorization inputs at the time a secure transaction is requested. Improve operability of the computer system by providing additional control options, make the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduce power usage and improve device battery life by allowing the user to use the computer system more quickly and efficiently. Increase security by linking authorization functions to reduce the risk of unintended authorization by meeting authorization criteria based on previous inputs that also allowed connection of external input devices to the computer system while in a locked state.Improving the security of the computer system improves the operability of the computer system, making the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reducing power usage and improving battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0222] In some embodiments, the external input device (e.g., 700) satisfies the set of permission criteria based on a state established (e.g., set) based on a second set of one or more inputs (e.g., 750b, 750c1, 750c2) received after receiving a first set of one or more inputs (e.g., 750a) (e.g., selection of a second option in a peripheral management interface, a set of inputs received at the external input device, a set of inputs received at the computer system) (e.g., a state that establishes a duration (e.g., permanent (e.g., until cancelled), temporary (e.g., for a transient duration (e.g., one day, one week), or for a pre-set number of connection events (e.g., one connection event, five connection events)) that the external input device satisfies the set of permission criteria. Establishing a state of the external input device that affects satisfaction of the permission criteria provides the user with additional control options to precisely control the relationship between the computer system and the external input device. By providing additional control options, the operability of the computer system is improved, the user-device interface is made more efficient (e.g., by assisting the user to provide appropriate inputs when operating / interacting with the device and reducing user errors), and the user can use the computer system more quickly and efficiently, thereby reducing power usage and improving battery life of the device. By satisfying authorization criteria based on previous inputs, security is increased by providing the user with the opportunity to provide authorization outside of the context of performing a particular secure transaction, thereby reducing the risk of unintended authorization. By improving the security of the computer system, the operability of the computer system is improved, the user-device interface is made more efficient (e.g., by assisting the user to provide appropriate inputs when operating / interacting with the device and reducing user errors), and the user can use the computer system more securely, quickly, and efficiently, thereby reducing power usage and improving battery life of the device.

[0223] In some embodiments, the external input device (e.g., 700) meets the set of authorization criteria based on the state being a long-term (e.g., indefinite until revoked) authorized state. In some embodiments, the first set of one or more inputs (e.g., 750a, 750b, 752c1) was received while the computer system (e.g., 600) is in a connection session with the external input device (e.g., 700) that is also the connection session in which the first request (e.g., 752d1, 752d2) was received (e.g., a session that begins with the connection of the computer system to the external input device and transmits when that connection is discontinued), or while the computer system (e.g., 600) is in a prior connection session with the external input device (e.g., 700) that is different from the connection session in which the first request (e.g., 752d1, 752d2) was received.

[0224] In some embodiments, the external input device (e.g., 700) meets the set of authorization criteria based on the state being a short-term (e.g., temporary or transient duration (e.g., one day, one week), or for a pre-set number of connection events (e.g., one connection event, five connection events), expiring without requiring further user input) authorized state. In some embodiments, the first set of one or more inputs (e.g., 750a, 750b, 750c2) was received while the computer system was in a connection session (e.g., a session that begins with the connection of the computer system to the external input device and transmits when that connection is discontinued) with the external input device (e.g., 700) that is also the connection session in which the first request (e.g., 752d1, 752d2) was received. In some embodiments, if the state is a temporary authorized state, the one or more sets of inputs were not received (e.g., cannot be received) while the computer system was in a prior connection session with the external input device that is different from the connection session in which the first request was received.

[0225] In some embodiments, the external input device (e.g., 700) meets a set of authorization criteria based on inputs (e.g., 750a, 750b, 750c1, 750c2) (e.g., selection of an option in a peripheral management interface) received prior to receiving a first request (e.g., prior to connecting to the external input device), and the computer system authorizes (e.g., pre-authorizes) the external input device (e.g., 700) to provide requests to initiate one or more secure transactions that, if authorized by the computer system (e.g., 600), require separate authorization from the user. In some embodiments, the inputs that authorize (e.g., pre-authorize) the external input device to provide requests to initiate one or more secure transactions that, if authorized by the computer system, require separate authorization from the user are different from the inputs that authorize the external input device to connect to the computer system while the computer system is in a locked state (e.g., a state in which one or more features of the computer system that are available while in an unlocked state are unavailable). Authorizing the external input device based on previous inputs allows the user to have better control over the relationship between the computer system and the external input device. Improves operability of the computer system by providing additional control options, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reduces power usage and improves device battery life by allowing the user to use the computer system more quickly and efficiently. Reduces the risk of unintended authorization and increases security by satisfying authorization criteria based on prior and explicit input that authorizes a secure transaction.Improving the security of the computer system improves the operability of the computer system, making the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), and reducing power usage and improving battery life of the device by allowing the user to use the computer system more securely, quickly, and efficiently.

[0226] In some embodiments, the external input device (e.g., 700) satisfies a set of authorization criteria based on input (e.g., 750a) (e.g., accepting a prompt providing authorization) received while connected to the external input device (e.g., 700) (e.g., while connected in the same connection session in which the first request was received), and the computer system authorizes the external input device (e.g., 700) to provide a request to initiate one or more secure transactions, which, if authorized by the computer system (e.g., 600), requires separate authorization from the user. Authorizing the external input device based on input received while connected to the external input device allows the user to have better control over the relationship between the computer system and the external input device, and also reduces the risk of unintentionally authorizing the wrong device. It improves the operability of the computer system by providing additional control options and reducing the risk of error, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), plus reduces power usage and improves the device's battery life by allowing the user to use the computer system more quickly and efficiently.

[0227] In some embodiments, an external input device (e.g., 700) meets a set of authorization criteria based on the external input device (e.g., 700) being identified as being a first type of device (e.g., a pre-authorized type of device (e.g., a device from a particular manufacturer), a type of device with particular hardware (e.g., secure hardware), a type of device with particular software (e.g., secure software)). In some embodiments, a second type of external input device (e.g., not of the first type) does not meet the set of authorization criteria. Authorizing an external input device based on the device being a first type of device reduces the risk of a device not having the required characteristics being authorized, thereby increasing security and also reducing the need for explicit input to authorize a first type of device. Increases security, improves operability of the computer system by reducing the number of inputs required to perform an operation, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), plus reduces power usage and improves device battery life by allowing the user to use the computer system more quickly and efficiently.

[0228] In some embodiments, an external input device (e.g., 700) (e.g., an integrated hardware interface (e.g., stereo head unit, infotainment system) of an automobile head unit (e.g., multiple entertainment and information systems (e.g., sound, navigation) of an automobile) meets a set of authorization criteria based on the external input device being connected to a vehicle (e.g., automobile, motorcycle) that has been identified as having authorized authentication hardware (e.g., authenticated identification chip). Authorizing an external input device based on the device being connected to a vehicle that has been identified as having authorized authentication hardware increases security and also reduces the need for explicit input to authorize devices connected to such vehicles. Increases security and improves usability of the computer system by reducing the number of inputs required to perform an operation, makes the user-device interface more efficient (e.g., by assisting the user in providing appropriate inputs when operating / interacting with the device and reducing user errors), plus reduces power usage and improves battery life of the device by allowing the user to use the computer system more quickly and efficiently.

[0229] It should be noted that the details of the process described above in connection with method 900 (e.g., FIG. 9) are also applicable in a similar manner to the methods described below. For example, method 900 optionally includes one or more of the characteristics of the various methods described above with reference to method 800. For example, method 800 may be used to initiate a process of performing a first transfer operation (e.g., 804) if (e.g., at 906) the external input device meets a set of authorization criteria and provides an option to initiate a secure transaction. For the sake of brevity, these details will not be repeated below.

[0230] The above has been described with reference to specific embodiments for purposes of illustration. However, the above exemplary discussion 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. The embodiments have been chosen and described in order to best explain the principles of the technology and their practical applications. In order to enable others skilled in the art to best utilize the technology and various embodiments with various modifications as suited to the particular applications intended.

[0231] 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 claims.

[0232] As mentioned above, one aspect of the present technology is to collect and use data available from various sources to improve management and security of operations (e.g., transactions) performed on various devices. The present disclosure contemplates that in some cases, this collected data may include personal information data that uniquely identifies a particular person or that can be used to contact or locate a particular person. Such personal information data may include demographic data, location-based data, phone numbers, email addresses, Twitter IDs, home addresses, data or records regarding a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), birth date, or any other identifying or personal information.

[0233] This disclosure recognizes that the use of such personal information data in the present technology may be used to the benefit of the user. For example, the personal information data may be used to provide authorization for an electronic device to perform a secure operation (e.g., a transaction) based on the personal information provided. Thus, the use of such personal information data allows the user to have calculated control and / or increased security over the secure operations performed via the electronic device. Additionally, other uses of personal information data that benefit the user are also contemplated by this disclosure. For example, health and fitness data may be used to provide insight into the overall wellness of the user, or may be used as proactive feedback to individuals using the technology in pursuit of wellness goals.

[0234] This disclosure contemplates that entities involved in the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will adhere to robust privacy policies and / or practices. Specifically, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for keeping personal information data confidential and secure. Such policies should be easily accessible by users and should be updated as data collection and / or use changes. Personal information from users should be collected for the entity's lawful and legitimate use and should not be shared or sold except for those lawful uses. Furthermore, such collection / sharing should be carried out after informing and obtaining consent from the user. Moreover, such entities should consider taking all necessary measures to protect and secure access to such personal information data and ensure that others who have access to the personal information data adhere to their privacy policies and procedures. Furthermore, such entities may subject themselves to third-party assessments to attest to their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted to the specific types of personal data collected and / or accessed, and should conform to applicable laws and standards, including jurisdiction-specific considerations. For example, in the United States, collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA), while health data in other countries may be subject to other regulations and policies and should be addressed accordingly. Therefore, different privacy practices should be maintained with respect to different types of personal data in each country.

[0235] Notwithstanding the foregoing, the present disclosure also contemplates embodiments in which a user selectively blocks use of or access to personal information data. That is, the present disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, when performing a secure operation (e.g., a payment transaction), the present technology may be configured to allow a user to select to "opt-in" or "opt-out" of participating in the collection of personal information data during registration for the service or at any time thereafter. In another example, the user may select to provide other information (e.g., a password, etc.) to perform one or more secure operations using the electronic device. In yet another example, the user may select to limit the amount of time that collected data (e.g., biometric data) is maintained or to completely prohibit the permission of operations based on collected data. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notifications regarding access or use of personal information. For example, the user may be notified upon download of an app that will access the user's personal information data, and then again immediately before the personal information data is accessed by the app.

[0236] Moreover, it is the intent of this disclosure that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting the collection of data and deleting it when it is no longer needed. Additionally, and where applicable in certain health-related applications, anonymization of data can be used to protect user privacy. De-identification can be facilitated by removing certain identifiers (e.g., date of birth, etc.) where appropriate, controlling the amount or specificity of data stored (e.g., collecting location data at a city level rather than an address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods.

[0237] Thus, while this disclosure broadly encompasses the use of personal information data to implement one or more of the various disclosed embodiments, this disclosure also contemplates that the various embodiments may be implemented without requiring access to such personal information data. That is, the various embodiments of the technology are not rendered inoperable by the absence of all or a portion of such personal information data. For example, secure operations may be performed based on non-personal information data, such as content requested by a device associated with a user, or a minimal amount of personal information necessary, other non-personal information available to the authorization system, or publicly available information.

Claims

1. 1. A method comprising:

1. A computer system in communication with an external automobile head unit including one or more input components, the computer system in communication with an external receiving device, the computer system comprising: receiving, from the external automobile head unit, first data corresponding to input received at the one or more input components of the external automobile head unit corresponding to a request to perform a first transfer operation from the first account to a second account using an application on the computer system associated with a first account, the application being configured to perform the transfer operation from the first account prior to receiving the first data; In response to receiving the first data, initiating a process to perform the first transfer operation using the application on the computer system, where performing the first transfer operation includes sending second data to the external receiving device, the second data including information identifying the first account; A method comprising:

2. a second application different from the application is installed on the computer system; and the second application being configured to perform a transfer operation from a third account; and the second application being configured to perform a transfer operation in response to a request received from the external automobile head unit to perform the transfer operation from the third account; According to the second application being not configured to perform a transfer operation from a third account, the second application is not configured to perform a transfer operation in response to a request received from the external automobile head unit to perform a transfer operation from the third account. The method of claim 1.

3. The second application is configured to perform a transfer operation from the third account, and the method further comprises: receiving third data from the external car head unit corresponding to an input received at the one or more input components of the external car head unit corresponding to a request to perform a second transfer operation from the third account to a fourth account using the second application; initiating a process for performing the second transfer operation using the second application in response to receiving the third data, the performing the second transfer operation including transmitting fourth data to the external receiving device, the fourth data including information identifying the third account; The method of claim 2 further comprising:

4. The method of claim 1 , wherein the computer system is in communication with a display generating component, the display generating component being in a locked state while the computer system is receiving the first data.

5. The method of claim 1 , wherein the external automobile head unit is authorized to request the performance of a transfer operation from the first account.

6. receiving a first set of one or more inputs prior to detecting the first data; in response to the first set of one or more inputs; allowing connection of the external automobile head unit to the computer system while the computer system is in a locked state; authorizing the external automobile head unit to request execution of a transfer operation from the first account; The method of claim 5 further comprising:

7. receiving a second set of one or more inputs while the computer system is in communication with the external vehicle head unit and while the computer system is in a locked state; in response to the second set of one or more inputs; transitioning the computer system to an unlocked state; authorizing the external automobile head unit to request execution of a transfer operation from the first account; The method of claim 5 further comprising:

8. transmitting, prior to receiving the first data, to the external automobile head unit, fifth data including one or more user interface elements to be displayed by the external automobile head unit; The method of claim 1 further comprising:

9. The method of claim 1 , wherein the computer system is a smartphone including a hardware secure element, and the information identifying the first account is stored in the hardware secure element.

10. while the computer system is in communication with a second external automobile head unit and a second external receiving device that includes one or more input components different from the external automobile head unit; receiving sixth data from the second external automobile head unit corresponding to an input received at the one or more input components of the second external automobile head unit corresponding to a request to perform a third transfer operation from the first account to a fifth account using the application; initiating a process for performing the third transfer operation using the application on the computer system in response to receiving the sixth data, wherein performing the third transfer operation includes transmitting seventh data to the second external receiving device, the seventh data including information identifying the first account; The method of claim 1 further comprising:

11. A computer program product causing a computer to carry out the method according to any one of claims 1 to 10.

12. 1. A computer system comprising: A memory for storing the computer program according to claim 11; and one or more processors capable of executing the computer program stored in the memory, the computer system configured to communicate with an external automobile head unit including one or more input components, the computer system communicating with an external receiving device.

13. A computer system comprising means for carrying out the method according to any one of claims 1 to 10.

Images