USER INTERFACE FOR DEVICE REQUESTING REMOTE AUTHORIZATION - Patent application

Abstract

To provide an electronic device with a quicker, more efficient method and interface for managing remote authorization to proceed with an action.SOLUTION: In a quicker, more efficient method for managing remote authorization to proceed with an action, a requesting device receives selection of one or more options and transmits a request including information about one or more options to proceed with an action to an authenticating device. The authenticating device, which has received the request, simultaneously displays an indication of the request to proceed with the action, information about the selected one or more options, and an indication of the requesting device. The authenticating device further receives authorization to proceed with the action and transmits, to the requesting device, a response to the request to proceed with the action.SELECTED DRAWING: Figure 9A

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 62 / 338,994, filed May 19, 2016, entitled "REMOTE AUTHORIZATION TO PROCEED WITH AN ACTION", the entire contents of which are incorporated herein by reference. This application claims priority to U.S. Provisional Patent Application No. 62 / 347,852, filed June 9, 2016, entitled "REMOTE AUTHORIZATION TO PROCEED WITH AN ACTION", the entire contents of which are incorporated herein by reference. This application claims priority to Danish Patent Application No. PA 2016 70628, filed August 16, 2016, entitled "REMOTE AUTHORIZATION TO PROCEED WITH AN ACTION", the entire contents of which are incorporated herein by reference. This application claims priority to U.S. Nonprovisional Patent Application No. 15 / 269,801, filed Sep. 19, 2016, entitled “USER INTERFACE FOR A DEVICE REQUESTING REMOTE AUTHORIZATION,” the entire contents of which are incorporated herein by reference. [Technical field]

[0002] TECHNICAL FIELD This disclosure relates generally to computer user interfaces, and more particularly to techniques for managing remote authorization of the progression of actions. [Background technology]

[0003] The use of electronic devices to store and display secure information has increased significantly in recent years, such as the use of devices for two-factor authentication. For example, a device may store a secure value. By securely storing the value on the device, the device provides a level of security for the user. The value may then be displayed on a display of the device, and the user may use the displayed value to perform various tasks with the device. Summary of the Invention

[0004] Methods for managing remote permission to proceed with an action using an electronic device are generally cumbersome and inefficient. For example, some existing methods utilize complex and time-consuming user interfaces that may involve multiple key presses or keystrokes. Existing methods are unnecessarily time-consuming and waste the user's time and the device's energy. The latter problem is particularly acute in the case of battery-operated devices.

[0005] Thus, the present technology provides electronic devices with faster and more efficient methods and interfaces for managing remote authorization of action progression. Such methods and interfaces may supplement or replace other methods for managing remote authorization of action progression. Such methods and interfaces reduce the cognitive burden on the user and create a more efficient human-machine interface. In the case of battery-operated computing devices, such methods and interfaces conserve power and extend the time between battery charges. In some embodiments of the present technology, such techniques allow a user to utilize the hardware capabilities of a first device while using (or performing a task on) a second device (e.g., when the second device does not have the same hardware capabilities as the first device). In some embodiments of the present technology, the present technology allows a parent to remotely authorize an action using a first device, which is requested (or initiated) by a child of the parent using a second device (e.g., regardless of the hardware capabilities of the second device). In some embodiments of the present technology, the present technology helps maintain a certain level of security by avoiding the need to distribute secure data to systems that do not meet certain security standards (e.g., avoiding the need to generate or store secure data on systems that do not have secure elements).

[0006] According to some embodiments, a method is described that includes receiving a selection of one or more options at a requester device having a display, receiving a selection of an option at the requester device to proceed with an action associated with the selected one or more options, transmitting a request to proceed with the action by the requester device, the request including information regarding the selected one or more options, receiving the request to proceed with the action by an authentication device having a display, simultaneously displaying on a display of the authentication device an indication of the request to proceed with the action, information regarding the selected one or more options, and an indication of the requester device, displaying on a display of the authentication device a request for permission to proceed with the action, and transmitting, at the authentication device, a request for permission to proceed with the action. receiving input responsive to the request for permission to proceed with the action; transmitting, by the authentication device, a response to the request to proceed with the action, the response to the request to proceed with the action being based on the input responsive to the request for permission to proceed with the action; receiving, by the requesting device, a response to the request to proceed with the action; displaying an indication on a display of the requesting device that authorization was successful in accordance with a determination at the requesting device that the response to the request to proceed with the action indicates that authorization at the authentication device was successful; and displaying an indication on a display of the requesting device that authorization was not successful in accordance with a determination at the requesting device that the response to the request to proceed with the action indicates that authorization at the authentication device was not successful.

[0007] According to some embodiments, a method is described that is performed on a requester device having a display, the method including receiving a selection of one or more options associated with an action, receiving a selection of an option to proceed with an action associated with the selected one or more options, sending a request to proceed with the action from the requester device to an authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, receiving a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and displaying an indication of successful authorization on a display of the requester device in accordance with a determination that the response to the request to proceed with the action indicates successful authorization at the authentication device.

[0008] According to some embodiments, a requesting device is described having a display, one or more processors, and a memory storing one or more programs, the one or more programs configured to be executed by the one or more processors, the one or more programs having instructions for receiving a selection of one or more options associated with an action, receiving a selection of an option to proceed with an action associated with the selected one or more options, transmitting a request to proceed with the action from the requesting device to an authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, receiving a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and displaying an indication of successful authorization on a display of the requesting device pursuant to a determination that the response to the request to proceed with the action indicates successful authorization at the authentication device.

[0009] According to some embodiments, a non-transitory computer-readable storage medium is described, the non-transitory computer-readable storage medium storing one or more programs executable by one or more processors of a requester device having a display, the one or more programs having instructions for receiving a selection of one or more options associated with an action, receiving a selection of an option to proceed with an action associated with the selected one or more options, transmitting a request to proceed with the action from the requester device to an authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, receiving a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and displaying an indication of successful authorization on a display of the requester device pursuant to a determination that the response to the request to proceed with the action indicates successful authorization at the authentication device.

[0010] According to some embodiments, a non-transitory computer-readable storage medium is described, the non-transitory computer-readable storage medium storing one or more programs executable by one or more processors of a requester device having a display, the one or more programs having instructions for receiving a selection of one or more options associated with an action, receiving a selection of an option to proceed with an action associated with the selected one or more options, transmitting a request to proceed with the action from the requester device to an authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, receiving a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and displaying an indication of successful authorization on the display of the requester device pursuant to a determination that the response to the request to proceed with the action indicates successful authorization at the authentication device.

[0011] According to some embodiments, a requesting device is described that includes a display, means for receiving a selection of one or more options associated with an action, means for receiving a selection of an option to proceed with an action associated with the selected one or more options, means for sending a request to proceed with the action from the requesting device to the authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, means for receiving a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and means for displaying an indication of successful authorization on a display of the requesting device in accordance with a determination at the authentication device that authorization was successful.

[0012] According to some embodiments, a method is described that is performed on an authenticator device having a display, the method including receiving a request to proceed with an action from a requester device, the request including information about the action, and both the requester device and the authenticator device being signed in to a service using the same account, simultaneously displaying on the display an indication of the request to proceed with the action, the information about the action, and an indication of the requester device, displaying a request for permission to proceed with the action, and receiving input responsive to the request for permission to proceed with the action.

[0013] According to some embodiments, an authentication device is described, the authentication device having a display, one or more processors, and memory storing one or more programs, the one or more programs configured to be executed by the one or more processors, the one or more programs receiving a request to proceed with an action from a requesting device, the request including information about the action, both the requesting device and the authenticating device being signed into a service using the same account, and the memory having instructions for simultaneously displaying on the display an indication of the request to proceed with the action, the information about the action, and an indication of the requesting device, displaying a request for permission to proceed with the action, and receiving input responsive to the request for permission to proceed with the action.

[0014] According to some embodiments, a non-transitory computer-readable storage medium is described, the non-transitory computer-readable storage medium storing one or more programs executable by one or more processors of an authentication device having a display, the one or more programs having instructions for receiving a request to proceed with an action from a requesting device, the request including information about the action, both the requesting device and the authentication device being signed into a service using the same account, simultaneously displaying on the display an indication of the request to proceed with the action, the information about the action, and an indication of the requesting device, displaying a request for permission to proceed with the action, and receiving input responsive to the request for permission to proceed with the action.

[0015] According to some embodiments, a non-transitory computer-readable storage medium is described, the non-transitory computer-readable storage medium storing one or more programs executable by one or more processors of an authentication device having a display, the one or more programs having instructions for receiving a request to proceed with an action from a requester device, the request including information about the action, both the requester device and the authentication device being signed into a service using the same account, simultaneously displaying on the display an indication of the request to proceed with the action, the information about the action, and an indication of the requester device, displaying a request for permission to proceed with the action, and receiving input responsive to the request for permission to proceed with the action.

[0016] According to some embodiments, an authentication device is described that includes a display, means for receiving a request to proceed with an action from a requester device, the request including information about the action, and both the requester device and the authentication device being signed in to the service using the same account, means for simultaneously displaying on the display an indication of the request to proceed with the action, information about the action, and an indication of the requester device, means for displaying a request for permission to proceed with the action, and means for receiving input responsive to the request for permission to proceed with the action.

[0017] According to some embodiments, a requesting device is described, the requesting device comprising: a display unit; and a processing unit coupled to the display unit, the processing unit configured to receive a selection of one or more options associated with an action, receive a selection of an option to proceed with an action associated with the selected one or more options, transmit a request to proceed with the action from the requesting device to the authentication device, the request including information regarding the selected one or more options, the information regarding the selected one or more options for display by the authentication device, receive a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device, and display an indication of successful authorization on a display of the requesting device pursuant to a determination that the response to the request to proceed with the action indicates successful authorization at the authentication device.

[0018] According to some embodiments, an authentication device is described, the authentication device comprising: a display unit; and a processing unit coupled to the display unit, the processing unit configured to receive a request to proceed with an action from a requesting device, the request including information about the action, both the requesting device and the authenticating device being signed into a service using the same account, to simultaneously display on the display unit an indication of the request to proceed with the action, the information about the action, and an indication of the requesting device, to display a request for permission to proceed with the action, and to receive an input responsive to the request for permission to proceed with the action.

[0019] Executable instructions to perform these functions may be included in a non-transitory computer-readable storage medium or other computer program product configured to be executed by one or more processors. Executable instructions to perform these functions may be included in a transitory computer-readable storage medium or other computer program product configured to be executed by one or more processors.

[0020] Thus, the effectiveness, efficiency, and user satisfaction of devices are improved by providing faster and more efficient methods and interfaces for managing remote authorization of action progression, which methods and interfaces may supplement or replace other methods for managing remote authorization of action progression. [Brief description of the drawings]

[0021] The various described embodiments will be better understood by reference to the following description of examples in conjunction with the accompanying drawings, in which like reference numerals refer to corresponding parts throughout the several views.

[0022] [Figure 1A] 1 is a block diagram illustrating a portable multifunction device having a touch-sensitive display according to some embodiments.

[0023] [Figure 1B] FIG. 2 is a block diagram illustrating example components for event processing in accordance with some embodiments.

[0024] [Diagram 2] 1 illustrates a portable multifunction device with a touch screen according to some embodiments.

[0025] [Diagram 3] 1 is a block diagram of an example multifunction device having a display and a touch-sensitive surface according to some embodiments.

[0026] [Figure 4A] 1 illustrates an example user interface for a menu of applications on a portable multifunction device according to some embodiments.

[0027] [Figure 4B]1 illustrates an example user interface for a multifunction device having a display and a separate touch-sensitive surface according to some embodiments.

[0028] [Figure 5A] 1 illustrates an illustration of a personal electronic device according to some embodiments.

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

[0030] [Figure 5C] 1 illustrates several example components of a personal electronic device having a touch-sensitive display and intensity sensor according to some embodiments. [Figure 5D] 1 illustrates several example components of a personal electronic device having a touch-sensitive display and intensity sensor according to some embodiments.

[0031] [Figure 5E] 1 illustrates several example components and user interfaces of a personal electronic device according to some embodiments. [Figure 5F] 1 illustrates several example components and user interfaces of a personal electronic device according to some embodiments. [Figure 5G] 1 illustrates several example components and user interfaces of a personal electronic device according to some embodiments. [Figure 5H] 1 illustrates several example components and user interfaces of a personal electronic device according to some embodiments.

[0032] [Figure 6] 1 illustrates a number of example devices connected via one or more communication channels to complete a payment transaction according to some embodiments.

[0033] [Figure 7A] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7B] 1 illustrates several example user interfaces for managing remote permissions for progression of an action according to some embodiments. [Figure 7C] 1 illustrates several example user interfaces for managing remote permissions for progression of an action according to some embodiments. [Figure 7D] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7E] 1 illustrates several example user interfaces for managing remote permissions for progression of an action according to some embodiments. [Figure 7F] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7G] 1 illustrates several example user interfaces for managing remote permissions for progression of an action according to some embodiments. [Figure 7H] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7I] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7J] 1 illustrates several example user interfaces for managing remote permissions for progression of an action according to some embodiments. [Figure 7K] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 7L] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments.

[0034] [Figure 8A] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8B] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8C-1] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8C-2] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8D] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8E] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8F] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8G] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8H] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8I] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8J] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8K] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8L] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments. [Figure 8M] 1 illustrates several example user interfaces for managing remote permissions for the progression of an action according to some embodiments.

[0035] [Figure 9A] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments. [Figure 9B] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments. [Figure 9C] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments. [Figure 9D] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments.

[0036] [Figure 10A] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments. [Figure 10B] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments.

[0037] [Figure 11] FIG. 1 is a flow diagram illustrating a method for managing remote authorization of the progression of an action according to some embodiments.

[0038] [Figure 12] FIG. 2 is a functional block diagram of an electronic requesting device according to some embodiments.

[0039] [Figure 13] FIG. 1 is a functional block diagram of an electronic authentication device according to some embodiments.

[0040] [Figure 14] FIG. 2 is a functional block diagram of an electronic requesting device according to some embodiments.

[0041] [Figure 15] FIG. 1 is a functional block diagram of an electronic authentication device according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] The following description sets forth a number of example methods, parameters, etc. It should be understood that such description is not intended to limit the scope of the present disclosure, but is provided as a description of a number of example embodiments.

[0043] There is a need for an electronic device that provides an efficient method and interface for managing remote authorization of action progression. As an example, a user may be using a personal laptop computer that is not capable of generating a secure value, such as a token, used to perform an action, such as creating a secure network connection between the laptop computer and a remote server, while the user's personal smartphone is capable of generating a token used to create the secure network connection. The user may be able to remotely authorize the action progression using a personal smartphone device, which may include a personal smartphone device that transmits the token used to create the secure network connection to a remote server or personal laptop computer. In another example, a user may be using a personal laptop computer that is not capable of generating payment information used to perform an action, such as a payment transaction, while the user's personal smartphone is capable of generating payment information used for the payment transaction. The user may be able to remotely authorize the payment transaction progression using a personal smartphone device, which may include a personal smartphone device that transmits payment information used for the payment transaction to a remote server or personal laptop computer. Such a technique may increase productivity by reducing the cognitive burden on a user utilizing remote authorization of action progression. Also, such a technique may conserve processor and battery power that would otherwise be wasted if user input were redundant.

[0044] 1A-1B, 2, 3, 4A-4B, 5A-5H, and 6 illustrate exemplary devices for performing techniques for managing remote authorization of action progression. FIG. 6 illustrates exemplary devices connected via one or more communication channels to complete a payment transaction according to some embodiments. FIGS. 7A-7L illustrate exemplary user interfaces for managing remote authorization to create a secure network connection. FIGS. 8A-8M illustrate exemplary user interfaces for managing remote authorization of a payment transaction progression. FIGS. 9-11 are flow diagrams illustrating methods for managing remote authorization of action progression. The user interfaces of FIGS. 7A-7L are used to explain processes described below, including the processes of FIGS. 9-11. The user interfaces of FIGS. 8A-8M are used to explain processes described below, including the processes of FIGS. 9-11.

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

[0046] The terms used to describe the various embodiments described herein are for the purpose of describing particular embodiments only and are not intended to be limiting. The singular forms "a," "an," and "the," as used in describing the various embodiments described and the appended claims, are intended to encompass the plural forms as well, unless expressly stated otherwise. The term "and / or," as used herein, will also be understood to encompass any and all combinations of one or more of the elements connected thereby. It will be further understood that the terms "having," "including," "comprising," and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0047] The term "if" may be interpreted as meaning "when," "when," "in response to a determination that," or "in response to detection of," depending on the context. Similarly, the phrases "when it is determined that" or "when (a predetermined condition or event) is detected" may be interpreted as meaning "when it is determined that," "in response to a determination that," "once (a predetermined condition or event) is detected," or "in response to detection of (a predetermined condition or event)," depending on the context.

[0048] Several embodiments of electronic devices, user interfaces for such electronic 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 has other functions, such as PDA and / or music player functions. Examples of portable multifunction devices include, but are not limited to, the iPhone, iPod Touch, and iPad devices manufactured by Apple Inc. of Cupertino, Calif. Laptop or tablet computers and other portable electronic devices having a touch-sensitive surface (such as a touchscreen display and / or touchpad) may also be used. It should be understood that in some embodiments, the device is not a portable communication device, but rather a desktop computer having a touch-sensitive surface (such as a touchscreen display and / or touchpad).

[0049] An electronic device having a display and a touch-sensitive surface is described below. It should be understood that the electronic device may also have one or more other physical user interface devices, such as a physical keyboard, a mouse, and / or a joystick.

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

[0051] Various applications executing on the device may use at least one common physical user interface device, such as a touch-sensitive surface. One or more features of the touch-sensitive screen and corresponding information displayed on the device may be coordinated and / or changed between one application and the next and / or within an application. In this manner, a common physical architecture (such as a touch-sensitive surface) of the device may accommodate various applications with user interfaces that are intuitive and transparent to the user.

[0052] Several embodiments of portable devices having touch-sensitive displays are described below. FIG. 1A is a block diagram illustrating a portable multifunction device 100 having a touch-sensitive display system 112 according to some embodiments. The 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 (which may include one or more computer-readable storage media), a memory controller 122, one or more processing units (CPUs) 120, a peripherals interface 118, RF circuitry 108, audio circuitry 110, a speaker 111, a microphone 113, an input / output (I / O) subsystem 106, other input controls 116, and an external port 124. Device 100 may include one or more optical sensors 164. Device 100 may include one or more contact intensity sensors 165 (e.g., a touch-sensitive surface, such as touch-sensitive display system 112 of device 100) for detecting the intensity of a contact on device 100. Device 100 may also have one or more tactile output generators 167 for generating tactile output (e.g., generating a 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 may communicate over one or more communication buses or signal lines 103.

[0053] 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 (such as a finger contact) on the touch-sensitive surface or a surrogate (alternative value) 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 different values ​​and more typically including hundreds of values ​​(such as at least 256). The intensity of a contact may be determined (or measured) using a variety of techniques and a variety of sensors or combinations of sensors. For example, one or more force sensors under or adjacent to the touch-sensitive surface may be used to measure the force at various points on the touch-sensitive surface. In some implementations, force measurements from multiple force sensors may be combined (such as by weighted averaging) to determine an estimated intensity of the contact. Similarly, a pressure-sensitive tip of a stylus may be used to determine the pressure of the stylus on the touch-sensitive surface. Alternatively, the size and / or change in the area of ​​contact 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 may be used as a surrogate for the force or pressure of the contact on the touch-sensitive surface. In some examples, the surrogate measure of the force or pressure of the contact may be used directly to determine whether the intensity threshold is exceeded (e.g., the intensity threshold is expressed in units corresponding to the surrogate measure). In some examples, the surrogate measure of the force or pressure of the contact may be converted to an estimated force or pressure (e.g., the intensity threshold is a pressure threshold measured in pressure units), and the estimated force or pressure may be used to determine whether the intensity threshold is exceeded. Using the intensity of the contact as an attribute of the user input allows users to access additional functionality that may not otherwise be available on small devices that have limited space for displaying affordances (e.g., on a touch-sensitive display) and / or receiving user input (via a touch-sensitive display, a touch-sensitive surface, or a physical / mechanical control such as a knob or button).

[0054] The term "tactile output" as used herein and in the claims refers to a physical displacement of a device compared to a previous position of the device, a physical displacement of one component of the device (such as a touch-sensitive surface) compared to another component of the device (such as a housing), or a displacement of a component compared to the center of mass of the device, as sensed by a user through his or her touch. For example, in a situation where a device or a component of the device is in contact with a touch-sensitive user surface (such as a finger, palm, or other part of the user's hand), the tactile output generated by the physical displacement may be interpreted by the user as a tactile sensation corresponding to a perceived change in a physical characteristic of the device or a component of the device. For example, movement of a touch-sensitive surface (such as a touch-sensitive display or trackpad) may be interpreted by the user as a "click down" or "click up" of a physical actuator button. In some cases, the user feels a tactile sensation such as a "click down" or "click up" even in the absence of movement of a physical actuator button associated with the touch-sensitive surface that is physically depressed (e.g., displaced) by the user's movement. As another example, movement of the touch-sensitive surface may be interpreted or felt by a user as "roughness" of the touch-sensitive surface even when there is no change in the smoothness of the touch-sensitive surface. Such interpretation of touch by a user may depend 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 (such as "click up," "click down," "roughness," etc.), unless otherwise specified, the generated tactile output corresponds to a physical displacement of the device or a component of the device that produces the aforementioned sensory perception of a typical (or average) user.

[0055] It should be understood that device 100 is merely one example of a portable multifunction device, and that device 100 may have more or fewer components than shown, a combination of two or more components, or multiple components in different configurations or arrangements. The various components shown in Figure 1A may be embodied as hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0056] Memory 102 may include high-speed random access memory, or may include 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 may control access to memory 102 by other components of device 100.

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

[0058] The RF (radio frequency) circuitry 108 receives and transmits RF signals, also referred to as electromagnetic signals. The RF circuitry 108 converts electrical signals to and from electromagnetic signals, and communicates with communication networks and other communication devices via electromagnetic signals. The RF circuitry 108 may include known circuitry for performing these functions, including, but not limited to, an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and the like. The RF circuitry 108 may communicate wirelessly with networks and other devices, such as the Internet, also referred to as the World Wide Web, an intranet, and / or wireless networks, such as cellular networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). The RF circuitry 108 may include known circuitry for detecting near field communication (NFC) fields, such as by near field communication radio waves.Wireless communications include Global System for Mobile Communications (GSM), Enhanced Data Environment for GSM (EDGE), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), Evolution Data Only (EV-DO), HSPA, HSPA+, Dual Cell HSPA (DC-HSPADA), Long Term Evolution (LTE), Near Field Communication (NFC), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth®, Bluetooth® Low Energy (BLE), Bluetooth® LTE, Bluetooth® LTE+ ... Any of the communications standards, protocols, and technologies may be used, including, but not limited to, Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and / or IEEE 802.11ac), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email (such as Internet Message Protocol (IMAP) and / or Post Office Protocol (POP)), instant messaging (such as Extensible Messaging and Presence Protocol (XMPP)), Session Initiation Protocol for Instant Messaging and Presence Event Package (SIMPLE), Instant Messaging and Presence Service (IMPS) and / or Short Message Service (SMS), or any other suitable communications protocols, including communications protocols not yet developed as of the time of filing this application.

[0059] The audio circuit 110, the speaker 111, and the microphone 113 constitute an audio interface between a user and the device 100. The audio circuit 110 receives audio data from the peripheral device 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 sound waves that can be heard by a human. The audio circuit 110 also receives electrical signals converted from sound waves by the microphone 113. The audio circuit 110 converts the electrical signal into audio data and transmits the audio data to the peripheral device 118 for processing. Audio data may be transmitted to and from the memory 102 and / or the RF circuit 108 by the peripheral device interface 118. In some embodiments, the audio circuit 110 further includes a headset jack (such as 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 (such as a single or double ear headphone) and an input (such as a microphone).

[0060] The I / O subsystem 106 couples input / output peripherals on the device 100, such as the touch screen 112 and other input controls 116, with the peripherals 118. The I / O subsystem 106 may include a display controller 156, an optical sensor controller 158, an intensity sensor controller 159, a tactile feedback controller 161, and one or more input controllers 160 for other input or control devices. The one or more input controllers 160 send and receive electrical signals to and from the other input controls 116. The other input controls 116 may include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, etc. In some alternative embodiments, the input controllers 160 may or may not be coupled to any of a keyboard, an infrared port, a USB port, and a pointer device such as a mouse. One or more buttons (e.g., 208 in FIG. 2) may include up / down buttons for adjusting the volume of the speaker 111 and / or the microphone 113. The one or more buttons may include a push button (such as 206 in FIG. 2).

[0061] A quick press of the push button may unlock the touch screen 112 or may initiate the 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, entitled "Unlocking a Device by Performing Gestures on an Unlock Image" (U.S. Patent No. 7,657,849), the entire contents of which are incorporated herein by reference. A long press of a push button (such as 206) may power the device 100 on or off. The functionality of one or more buttons may be customizable by the user. The touch screen 112 is used to implement virtual or soft buttons as well as one or more soft keyboards.

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

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

[0064] The touch screen 112 may use LCD (liquid crystal display), LPD (light emitting polymer display) or LED (light emitting diode) technology, although other display technologies are used in other embodiments. The touch screen 112 and display controller 156 may 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, for measuring one or more points of contact with the touch screen 112. In one embodiment, projected mutual capacitance sensing technology is used, such as that used in the iPhone® and iPod Touch® manufactured by Apple Inc. of Cupertino, Calif.

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

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

[0067] The touch screen 112 may have a video resolution of more than 100 dpi. In some embodiments, the touch screen has a video resolution of approximately 160 dpi. A user may contact the touch screen 112 with any suitable object or appendage, such as a stylus, a finger, etc. In some embodiments, the user interface is designed to operate primarily through finger contacts and gestures, which may be less precise than input using a stylus due to the larger contact area of ​​a finger on the touch screen. In some embodiments, the device translates the less precise finger input into precise pointer / cursor position or commands to perform the user's desired action.

[0068] In some embodiments, in addition to a touchscreen, device 100 may include a touchpad (not shown) for enabling or disabling 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 may be a separate touch-sensitive surface from touchscreen 112 or may be an extension of the touch-sensitive surface formed by the touchscreen.

[0069] The device 100 further includes a power system 162 for powering the various components. The power system 162 may include a power management system, one or more power sources (such as batteries, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (such as a light emitting diode (LED)), and any other components involved in the generation, management, and distribution of power in a portable device.

[0070] The device 100 may further include one or more optical sensors 164. FIG. 1A illustrates an optical sensor coupled to an optical sensor controller 158 in the I / O subsystem 106. The optical sensor 164 may include a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) phototransistor. The optical sensor 164 receives light projected from the environment through one or more lenses and converts the light into data representing an image. The optical sensor 164 may work in conjunction with an imaging module 143 (also called a camera module) to capture still images or video. In some embodiments, the optical sensor is located on the back side of the device 100 opposite the touchscreen display 112 on the front side of the device so that the touchscreen display can be used as a viewfinder to capture still and / or video images. In some embodiments, the optical sensor is located on the front side of the device so that an image of the user is captured 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 a user (such as by rotating the lens and sensor within the device housing) so that a single optical sensor 164 can be used in conjunction with a touch screen display for both video conferencing and capturing still and / or video images.

[0071] Device 100 may include one or more contact intensity sensors 165. FIG. 1A illustrates a contact intensity sensor coupled to one or more intensity sensor controllers 159 in I / O subsystem 106. Contact intensity sensor 165 may include 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 (such as sensors used to measure the force (or pressure) of a contact on a touch-sensitive surface). Contact intensity sensor 165 receives contact intensity information (such as pressure information or a proxy for pressure information) from the environment. In some embodiments, at least one contact intensity sensor is juxtaposed or adjacent to a touch-sensitive surface (such as touch-sensitive display system 112). In some embodiments, at least one contact intensity sensor is located on a back side of device 100 opposite touch screen 112 located on the front side of device 100.

[0072] The device 100 may further include one or more proximity sensors 166. FIG. 1A illustrates the proximity sensor 166 coupled to the peripherals interface 118. Alternatively, the proximity sensor 166 may be coupled to an input controller 160 in the I / O subsystem 106. The proximity sensor 166 may function as described in U.S. patent application Ser. Nos. 11 / 241,839, entitled "Proximity Detector In Handheld Device," 11 / 240,788, entitled "Proximity Detector In Handheld Device," 11 / 620,702, entitled "Using Ambient Light Sensor To Augment Proximity Sensor Output," 11 / 586,862, entitled "Automated Response To And Sensing Of User Activity In Portable Devices," and 11 / 638,251, entitled "Methods And Systems For Automatic Configuration Of Peripherals," the entire contents of which are incorporated herein by reference. In some embodiments, a proximity sensor turns off and disables the touch screen 112 when the multifunction device is placed close to the user's ear (such as when the user is making a phone call).

[0073] Device 100 may further include one or more tactile output generators 167. FIG. 1A illustrates a tactile output generator coupled to tactile feedback controller 161 in I / O subsystem 106. Tactile output generator 167 may include one or more electroacoustic devices, such as speakers and 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 tactile 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 or adjacent to a touch-sensitive surface (such as touch-sensitive display system 112) and may generate a tactile output by moving the touch-sensitive surface vertically (e.g., toward or away from the surface of device 100) or laterally (e.g., back and forth in the same plane as the surface of device 100). In some embodiments, at least one tactile output generator sensor is located on the back side of device 100, opposite touchscreen display 112 that is located on the front side of device 100.

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

[0075] In some embodiments, 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 described in FIGS. 1A and 3. Device / global internal state 157 includes one or more of an active application state indicating which applications 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 various sensors and input controls 116 of the device, and position information regarding the position and / or orientation of the device.

[0076] Operating system 126 (e.g., Darwin, RTXC, LINUX, UNIX, OS X, iOS, WINDOWS, or an embedded operating system such as VxWorks) has various software components and / or drivers for control and management of general system tasks (such as memory management, storage control, power management, etc.) and for facilitating communication between the various hardware and software components.

[0077] Communications module 128 includes various software components for facilitating communication with other devices via one or more external ports 124, and for processing data received by RF circuitry 108 and / or external port 124. External port 124 (e.g., Universal Serial Bus (USB), FIREWIRE, etc.) can be coupled directly to other devices or indirectly via a network (e.g., the Internet, wireless LAN, etc.). In some embodiments, the external port is a multi-pin connector (e.g., 30-pin) identical to and / or compatible with the 30-pin connector used on iPod (a trademark of Apple Inc.) devices.

[0078] Contact / motion module 130 may detect contact with touch screen 112 (in conjunction with display controller 156) and other touch-sensitive devices (such as a touchpad or physical click wheel). Contact / motion module 130 has various software components for performing various operations related to contact detection, such as determining whether a contact has occurred (such as detecting a finger touch event), determining the strength of the contact (such as a contact force or pressure or a substitute for contact force or pressure), determining whether there is contact movement and tracking this movement across the touch-sensitive surface (such as detecting a drag event by one or more fingers), and determining whether the contact has ceased (such as a finger lift event or contact interruption). Contact / motion module 130 receives contact data from the touch-sensitive surface. Detecting the movement of a contact point represented by a series of contact data may include determining the velocity (magnitude), speed (magnitude and direction), and / or acceleration (change in magnitude and / or direction). These operations may be performed for a single contact (such as a single finger contact) or for multiple simultaneous contacts (such as "multi-touch" or multiple finger contacts). In some embodiments, contact / motion module 130 and display controller 156 detect contacts on the touchpad.

[0079] 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 the user (e.g., determining whether the user has performed a "click" action on an icon). In some embodiments, at least one subset of intensity thresholds is determined according to multiple software parameters (e.g., the intensity thresholds are not determined by the activation thresholds of a particular physical actuator, but are adjustable 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 predetermined thresholds without modifying the trackpad or touchscreen display. Additionally, in some embodiments, a software setting is provided to a user of the device to adjust one or more 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).

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

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

[0082] In some embodiments, the graphics module 132 stores data representing the graphics to be used. Each graphic may be assigned a corresponding code. The graphics module 132 receives, from an application or the like, one or more codes specifying the graphics to be displayed, and, if necessary, coordinate data and other coordinate characteristic data, and then generates screen image data to be output to the display controller 156.

[0083] 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.

[0084] Text input module 134, which may be a component of graphics module 132, provides a soft keyboard for text entry in various applications (such as contacts 137, email 140, IM 141, browser 147, and any other application requiring text input).

[0085] The GPS module 135 determines the location of the device and provides this information for use by various applications (such as the phone 138 for location-based dialing, the camera 143 for picture / video metadata, and applications that provide location-based services such as weather widgets, local yellow pages widgets, and map / navigation widgets).

[0086] The application 136 includes the following modules (or instruction sets): ● a contacts module 137 (sometimes called an address book or contact list); ● Telephone module 138, ●Video conferencing module 139; ● an email client module 140; ● Instant messaging (IM) module 141; ● Training support module 142, A camera module 143 for still and / or video images, ● Image management module 144, ●Video player module, ●Music player module, ● Browser module 147, ● Calendar module 148, A widget module 149 that may include one or more of a weather widget 149-1, a stocks widget 149-2, a calculator widget 149-3, an alarm clock widget 149-4, a dictionary widget 149-5, and other user-acquired and 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 combines a video player module and a music player module; ● Memo module 153, Map module 154, and / or ●Online Video Module 155 Or it may include a subset or superset of these.

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

[0088] A contacts module 137, 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, may be 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 adding names to the address book, removing names from the address book, associating names with phone numbers, email addresses, physical addresses or other information, associating names with pictures, categorizing and sorting names, providing phone numbers or email addresses to initiate and / or facilitate communications via telephone 138, video conferencing module 139, email 140, or IM 141, etc.

[0089] A 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, may be used to enter a series of characters corresponding to a telephone number, access one or more telephone numbers in contacts module 137, modify an entered telephone number, dial a telephone number, conduct a conversation, and hang up when a conversation is completed. As mentioned above, wireless communication may use any of a number of communication standards, protocols, and technologies.

[0090] A video conferencing module 139 has executable instructions in conjunction with the RF circuitry 108, the audio circuitry 110, the speaker 111, the microphone 113, the touch screen 112, the display controller 156, the optical sensor 164, the optical sensor controller 158, the contact / motion module 130, the graphics module 132, the text input module 134, the contacts module 137, and the telephone module 138 to initiate, conduct, and end a video conference between a user and one or more other participants based on the user's commands.

[0091] An email client module 140 has executable instructions in conjunction with the RF circuitry 108, touch screen 112, display controller 156, contact / motion module 130, graphics module 132 and text input module 134 to create, send, receive and manage emails in response to user commands. The email client module 140 in conjunction with image management module 144 greatly facilitates the creation and sending of emails along with still or video images captured using camera module 143.

[0092] An instant messaging module 141 includes a plurality of executable instructions 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 to input a series of characters corresponding to an instant message, modify previously input characters, send instant messages (e.g., using Short Message Service (SMS) or Multimedia Message Service (MMS) protocols for telephone-based instant messages, or XMPP, SIMPLE, or IMPS for Internet-based instant messages), receive instant messages, and view received instant messages. In some embodiments, sent and / or received instant messages may include MMS- and / or Enhanced Message Service (EMS)-enabled graphics, photos, audio files, video files, and / or other attachments. As used herein, "instant messaging" refers to both telephone-based messages (e.g., messages sent using SMS or MMS) and Internet-based messages (e.g., messages sent using XMPP, SIMPLE, or IMPS).

[0093] The training support module 142 has a plurality of executable instructions 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, the GPS module 135, the map module 154, and the music player module to create workouts (such as time, distance and / or calorie burn goals), communicate with training sensors (sports equipment), receive training sensor data, calibrate sensors used to monitor workouts, select and play music for workouts, and display, store and transmit workout data.

[0094] 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, has a plurality of executable instructions for capturing still images or video (including video streams) and storing them in memory 102, changing characteristics of the still images or video, or deleting the still images or video from memory 102.

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

[0096] A 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 has a plurality of executable instructions for browsing the Internet based on user commands, including retrieving, linking to, receiving, and displaying web pages or portions thereof, as well as attachments and other files linked to the web pages.

[0097] A calendar module 148 has a plurality of executable instructions for operating 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, 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 entries, to-do lists, etc.) in accordance with user commands.

[0098] Widget modules 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, are mini-applications that may be downloaded and used by a user (such as weather widget 149-1, stocks widget 149-2, calculator widget 149-3, alarm clock widget 149-4, and dictionary widget 149-5) or created by a user (such as user-created widget 149-6). In some embodiments, a widget includes an HTML (HyperText Markup Language) file, a CSS (Cascading Style Sheets) file, and a JavaScript file. In some embodiments, a widget includes an XML (Extensible Markup Language) file and a JavaScript file (such as Yahoo! Widget).

[0099] A 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, may be used by a user to create a widget (e.g., turn a user-specified portion of a web page into a widget).

[0100] A search module 151 has a plurality of 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, audio, images, video and / or other files in the memory 102 that match one or more search criteria (e.g., one or more search terms specified by a user).

[0101] A video and music player module 152 comprises executable instructions in conjunction with touch screen 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 recorded music and other audio files stored in one or more file formats, such as MP3 or AAC files, and executable instructions for displaying, presenting, or playing video (such as on touch screen 112 or on an external display connected via external port 124). In some embodiments, device 100 may have the functionality of an MP3 player, such as an iPod (a trademark of Apple Inc.).

[0102] A memo module 153 has a plurality of executable instructions 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 for creating and managing memos, to-do lists, and the like in accordance with user instructions.

[0103] A map module 154, in conjunction with the 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, may be used to receive, display, modify and store maps and data associated with the maps (such as driving directions, data regarding stores and other points of interest at or near a particular location, and other location-based data) in accordance with a user's instructions.

[0104] An 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, has instructions that enable a user to access, browse, receive (by streaming and / or downloading), play (such as on the touchscreen or on an external display connected via external port 124), email with a link, and manage in one or more file formats, such as H.264, particular online videos. In some embodiments, instant messaging module 141, rather than email client module 140, is used to send links to particular online videos. Further description of online video applications is provided in U.S. Provisional Patent Application No. 60 / 936,562, filed June 20, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," and U.S. Patent Application No. 11 / 968,067, filed December 31, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," the entire contents of which are incorporated herein by reference.

[0105] Each of the above-mentioned modules and applications corresponds to a set of executable instructions (such as computer-implemented methods and other information programming methods described herein) that perform one or more of the above-mentioned functions and methods described herein. These modules (such as sets of instructions) need not be embodied as separate software programs, procedures, or modules, and thus, in various embodiments, various subsets of these modules may be combined or reconfigured. For example, a video player module may be combined with a music player module into a single module (such as the video and music player module 152 of FIG. 1A). In some embodiments, memory 102 may store a subset of the above-mentioned modules and data structures. Additionally, memory 102 may store additional modules and data structures not described above.

[0106] In some embodiments, device 100 may be a device in which operations on a given set of functions are performed solely through a touchscreen and / or touchpad. By using the touchscreen and / or touchpad as the primary input control device for operating device 100, the number of physical input controls (e.g., push buttons, dials, etc.) on device 100 may be reduced.

[0107] A predetermined set of functions performed solely by the touchscreen and / or touchpad may include navigation between user interfaces. In some embodiments, the touchpad, when touched by a user, navigates device 100 to a main menu, home menu, or root menu from any user interface displayed on device 100. In such embodiments, a "menu button" is embodied using the touchpad. In other embodiments, the menu button is not a touchpad, but rather a physical push button or other physical input control device.

[0108] 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 event sorter 170 (e.g., within operating system 126) and application 136-1 (such as any of applications 137-151, 155, 380-390 discussed above).

[0109] Event sorter 170 receives the event information and determines application 136-1 and application view 191 of application 136-1 as the destination for the event information. Event sorter 170 includes event monitor 171 and event dispatcher module 174. In some embodiments, application 136-1 has 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 is currently active, and application internal state 192 is used by event sorter 170 to determine application view 191 as the destination for the event information.

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

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

[0112] In some embodiments, event monitor 171 sends requests at predetermined intervals to peripherals interface 118. In response, peripherals interface 118 sends event information. In other embodiments, peripherals interface 118 sends event information only when a significant event occurs (such as receiving an input that exceeds a predetermined noise threshold and / or for a period of time that exceeds a predetermined length of time).

[0113] In some embodiments, event sorter 170 further comprises a hit view determination module 172 and / or an active event recognizer determination module 173 .

[0114] In some embodiments, hit view determination module 172 provides software procedures for determining in which of one or more views a sub-event occurred, when touch-sensitive display 112 displays multiple views. A view consists of controls and other elements that a user can see on the display.

[0115] 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 in which touch-based gestures occur. The application view (of an application) in which a touch is detected may correspond to a program level within the application's hierarchy of programs or views. For example, the lowest level view in which a touch is detected may be referred to as the hit view, and the set of events that are recognized as suitable inputs may be determined based at least in part on the hit view of the initial touch that initiates a touch-based gesture.

[0116] Hit view determination module 172 receives information about sub-events of a touch-based gesture. If an application has multiple hierarchical views, hit view determination module 172 identifies a hit view as the lowest view in the hierarchy that should process the sub-events. In most cases, this hit view is the lowest view in which a starting sub-event occurs (such as the first sub-event in a series of sub-events that form an event or a future event). Once a hit view is identified by hit view determination module 172, it typically receives all sub-events associated with the same touch or input source that identified the hit view as the hit view.

[0117] An active event recognizer determination module 173 determines which view or views in the view hierarchy should receive a particular sequence of sub-events. In some embodiments, the active event recognizer determination module 173 determines that only the hit view should receive a particular sequence of sub-events. In other embodiments, the active event recognizer determination module 173 determines that all views that contain the physical location of a sub-event are effectively participating views, and therefore all effectively participating views should receive a particular sequence of sub-events. In other embodiments, views higher in the hierarchy may continue to be effectively participating views even if touch sub-events are entirely contained within an area associated with a particular view.

[0118] Event dispatcher module 174 distributes the event information to event recognizers (such as event recognizer 180). In embodiments with active event recognizer determination module 173, event dispatcher module 174 delivers the event information to the event recognizers defined by active event recognizer determination module 173. In some embodiments, event dispatcher module 174 stores the event information in an event queue, from which the event information is retrieved by event receiver 182.

[0119] 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 separate module or is part of another module stored in memory 102, such as contact / motion module 130.

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

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

[0122] Event receiver 182 receives event information from event sorter 170. The event information includes information about a sub-event, such as a touch or a movement of a touch. For some sub-events, the event information also includes further information, such as a position of the sub-event. If the sub-event is related to a movement of a touch, the event information may further include a speed and direction of the sub-event. In some implementations, the event includes rotating the device from one orientation to another (such as from portrait to landscape or vice versa), and the event information includes corresponding information about the current orientation of the device (also called the device's attitude).

[0123] The event comparator 184 compares the event information to predefined event or sub-event definitions and determines an event or sub-event or determines or updates the state of the event or sub-event based on the comparison. In some embodiments, the event comparator 184 includes an event definition 186. The event definition 186 includes a definition of an event (e.g., a predefined sequence of sub-events), such as event 1 (187-1), event 2 (187-2), etc. In some embodiments, multiple sub-events within an event (187) include, for example, touch start, touch end, touch movement, touch break, and multiple touches. In one example, the definition of event 1 (187-1) is a double tap on a displayed object. A double tap may, for example, include a first touch on a displayed object at a predefined stage (touch start), a first lift at a predefined stage, and a second lift at a predefined stage. In one example, the definition of event 187-1 is a drag on a displayed object. The drag may comprise, for example, a touch (or contact) on a displayed object at a predetermined stage, a movement of the touch on the touch-sensitive display 112, and a lift-off of the touch (end of the touch). In some examples, the event further comprises information regarding one or more associated event handlers 190.

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

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

[0126] If event recognizer 180 determines that the sequence of sub-events does not match any event in event definition 186, event recognizer 180 enters an event disabled, event failed, or event finished state and thereafter ignores subsequent touch-based gesture sub-events. In this situation, if there are other event recognizers that remain enabled for the hit view, those event recognizers continue to track and process sub-events for the ongoing touch-based gesture.

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

[0128] In some embodiments, when one or more particular sub-events of an event are recognized, the event recognizer 180 activates an event handler 190 associated with the event. In some embodiments, each event recognizer 180 delivers event information associated with the event to the event handler 190. Activating the event handler 190 is distinct from sending (and delaying sending) sub-events to each hit view. In some embodiments, the event recognizer 180 sends a flag associated with the recognized event, and the event handler 190 associated with the flag receives the flag and performs a process.

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

[0130] 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 creates display information and sends it to graphics module 132 for display on a touch-sensitive display.

[0131] In some embodiments, event handler 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 contained within a single module of application 136-1 or application view 191. In other embodiments, they are contained within two or more software modules.

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

[0133] FIG. 2 illustrates a portable multifunction device 100 having a touch screen 112 according to some embodiments. The touch screen may display one or more graphics within a user interface (UI) 200. In this embodiment, as well as other embodiments described below, a user may select one or more graphics by making a gesture on the graphics, such as with one or more fingers 202 (not shown to scale) or one or more styluses 203 (not shown to scale). In some embodiments, selection of the one or more graphics occurs when the user breaks contact with the one or more graphics. In some embodiments, a gesture may include one or more taps, one or more swipes (left to right, right to left, bottom to top, and / or top to bottom), and / or a rotation (right to left, left to right, bottom to top, and / or top to bottom) of a finger in contact with the device 100. In some embodiments or cases, unintentional contact with a graphic does not select the graphic. For example, a swipe gesture sliding over an application icon may not select the corresponding application if the gesture corresponding to selection is a tap.

[0134] The device 100 may have one or more physical buttons, such as a “home” or menu button 204. As mentioned above, the menu button 204 may be used to navigate to any application 136 of a set of applications that may be running on the device 100. Alternatively, in some embodiments, the menu button is embodied as a soft key within a GUI displayed on the touch screen 112.

[0135] In some embodiments, the device 100 includes a touch screen 112, a menu button 204, a push button 206 for powering the device on / off and locking the device, a volume control button 208, a subscriber identity module (SIM) card slot 210, a headset jack 212, and a docking / charging external port 124. The push button 206 may be used to power the device on / off by pressing and holding the button down for a predetermined time, to lock the device by pressing and releasing the button before the predetermined time has elapsed, and / or to unlock the device or initiate an unlocking process. In another embodiment, the device 100 receives verbal input via the microphone 113 for enabling or disabling certain features. The device 100 may further include one or more intensity sensors 165 for detecting the intensity of a touch on the touch screen 112 and / or a tactile output generator 167 for generating a tactile output for a user of the device 100.

[0136] FIG. 3 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface, according to some embodiments. The device 300 need not be portable. In some embodiments, the 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 learning toy for children), a gaming system, or a control device (such as a home or industrial controller). The device 300 typically has one or more processing units (CPUs) 310, one or more network or other communication interfaces 360, a memory 370, and one or more communication buses 320 for interconnecting these components. The communication bus 320 may include circuitry (also called a chipset) that interconnects and controls communication between multiple system components. The device 300 has an input / output (I / O) interface 330 with a display 340, which is typically a touch screen display. I / O interface 330 may further include a keyboard and / or mouse (or other pointing device) 350 and a touchpad 355, a tactile output generator 357 for generating tactile output on device 300 (e.g., similar to tactile output generator 167 described above with reference to FIG. 1A), and sensors 359 (e.g., optical, acceleration, proximity, touch sensing, and / or contact intensity sensor 165 described above with reference to FIG. 1A). Memory 370 may include high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices, and may also include 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 may include one or more storage devices located remotely from CPU 310. In some embodiments, memory 370 stores programs, modules, and data structures similar to, or a subset of, the programs, modules, and data structures stored in memory 102 of the portable multifunction device (FIG. 1A).Additionally, memory 370 may store additional programs, modules and data structures not present in memory 102 of portable multifunction device 100. For example, memory 370 of device 300 may store drawing module 380, presentation module 382, ​​word processing module 384, website creation module 386, disk authoring module 388 and / or spreadsheet module 390, while memory 102 of portable multifunction device 100 (FIG. 1A) may not store these modules.

[0137] Each of the above-mentioned elements shown in FIG. 3 may be stored in one or more of the above-mentioned memory devices. Each of the above-mentioned modules corresponds to a set of instructions that perform the above-mentioned functions. Each of the above-mentioned modules and programs (e.g., sets of instructions) need not be embodied as separate software programs, procedures, or modules, and thus, in various embodiments, various subsets of these modules may be combined or reconfigured. In some embodiments, memory 370 may store a subset of the above-mentioned modules and data structures. Additionally, memory 370 may store additional modules and data structures not described above.

[0138] Below are described several examples of user interfaces that may be implemented on portable multifunction device 100, for example.

[0139] 4A illustrates an example user interface for an applications menu of portable multifunction device 100 in accordance with some embodiments. A similar user interface may be implemented on device 300. In some embodiments, user interface 400 includes the following elements, or a subset or superset thereof: ● Signal strength indicators 402 for wireless communications such as cellular and Wi-Fi signals; ●Time 404, ●Bluetooth indicator 405, ● Battery status indicator 406, ● Tray 408 containing icons for frequently used applications such as: ○ An icon 416 labeled “phone” for the phone module 138, which may include an indicator 414 of the number of missed calls or voicemail messages; ○ An icon 418 labeled “Mail” for the email client module 140, which may include an indicator 410 of the number of unread emails; ○ an icon 420 for the browser module 147 labeled "Browser"; and ○ An icon 422 labeled “iPod” for the video and music player module 152, also called the iPod (registered trademark of Apple Inc.) module 152 ● Icons for other applications such as: ○ Icon 424 labeled "Message" for IM module 141, ○ An icon 426 labeled “Calendar” for the calendar module 148; ○ An icon 428 labeled "Photo" for the image management module 144; ○ An icon 430 labeled “camera” for the camera module 143; ○ an icon 432 labeled “Online Video” for the online video module 155; ○ Icon 434, which displays "Stocks" for stock widget 149-2, ○ Icon 436 labeled "Map" for map module 154, ○ Icon 438, which displays "Weather" for weather widget 149-1; ○ Icon 440 labeled "Clock" for alarm clock widget 149-4, icon 442 labeled "Training Support" for the training support module 142; icon 444 labeled "Notes" for the Notes module 153; and ○ An icon 446 labeled “Settings” for a settings application or module for accessing settings for the device 100 and its various applications 136 .

[0140] It should be noted that the icon representations shown in FIG. 4A are merely exemplary. For example, icon 422 for video and music player module 152 may be represented as "Music" or "Music Player." Other representations may be used for the various application icons. In some embodiments, the representation for an application icon includes the name of the application that corresponds to the application icon. In some embodiments, the representation for an application icon is different from the name of the application that corresponds to the application icon.

[0141] Figure 4B illustrates an example of a user interface on a device (such as device 300 of Figure 3) having a touch-sensitive surface 451 (such as tablet or touchpad 355 of Figure 3) spaced from a display 450 (such as touchscreen display 112). Device 300 may have one or more contact intensity sensors (such as one or more sensors 359) for detecting the intensity of a contact on touch-sensitive surface 451 and / or one or more tactile output generators 357 for generating a tactile output for a user of device 300.

[0142] Some of the following examples are described with reference to input on touch screen display 112 (a combination touch-sensitive surface and display), although in some embodiments the device detects input on a touch-sensitive surface spaced apart from the display, as shown in FIG. 4B. In some embodiments, the touch-sensitive surface (such as 451 in FIG. 4B) has a primary axis (such as 452 in FIG. 4B) that corresponds to a primary axis (such as 453 in FIG. 4B) on the display (such as 450). In accordance with these embodiments, the device detects contacts (such as 460 and 462 in FIG. 4B) to locations on touch-sensitive surface 451 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 (such as contacts 460 and 462 and their movement) detected by the device on the touch-sensitive surface (such as 451 in FIG. 4B ) is used by the device to operate a user interface on the display (such as 450 in FIG. 4B ) of the multifunction device when the touch-sensitive surface is spaced apart from the display. It should be understood that similar methods may be used for the other user interfaces described herein.

[0143] In addition, although the following examples are described primarily in relation 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 may be replaced with input from another input device (e.g., mouse-based input or stylus input). For example, a swipe gesture may be replaced with a mouse click (e.g., instead of a contact) followed by moving a cursor along the swipe path (e.g., instead of moving the contact). As another example, a tap gesture may be replaced with a mouse click while the cursor is positioned over the tap gesture location (e.g., instead of terminating contact detection after contact detection). Similarly, it should be understood that multiple computer mice may be used simultaneously, or a mouse and finger contact may be used simultaneously, when multiple user inputs are detected simultaneously.

[0144] FIG. 5A illustrates an exemplary personal electronic device 500. Device 500 has a body 502. In some embodiments, device 500 may have 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, hereinafter referred to as 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) may have one or more intensity sensors for detecting the intensity of a contact (e.g., a touch) being applied. One or more intensity sensors of touch screen 504 (or touch-sensitive surface) may provide output data representative of the intensity of the touch. A user interface of device 500 may respond to touches based on their intensity, i.e., touches of different intensities may cause different user interface actions on device 500.

[0145] Examples of techniques for detecting and processing touch intensity are described in the following related applications, the entire contents of which are incorporated herein by reference, including, but not limited to, 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 WIPO Publication No. WO / 2013 / 169849, and International Patent Application No. PCT / US2013 / 069483, filed November 11, 2013, entitled "Device, Method, and Graphical User Interface for Transitioning Between Touch Input to Display Output Relationships," published as WIPO Publication No. WO / 2014 / 105276.

[0146] In some embodiments, device 500 has one or more input mechanisms 506 and 508. Input mechanisms 506 and 508, if included, may 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, may allow device 500 to be attached to, for example, a hat, glasses, earrings, a necklace, a shirt, a jacket, a bracelet, a watch band, a chain, pants, a belt, a shoe, a wallet, a backpack, etc. These attachment mechanisms allow a user to wear device 500.

[0147] FIG. 5B illustrates an example of a personal electronic device 500. In some embodiments, the device 500 may include some or all of the components described in connection with FIGS. 1A, 1B, and 3. The device 500 includes a bus 512 operatively coupling an I / O portion 514 with one or more computer processors 516 and a memory 518. The I / O portion 514 may be connected to a display 504, which may include a touch-sensing component 522 and an intensity sensor 524 (such as a contact intensity sensor). Additionally, the I / O portion 514 may be connected to a communication unit 530 for receiving application and operating system data using Wi-Fi, Bluetooth, Near Field Communication (NFC), cellular, and / or other wireless communication technologies. The device 500 may include input mechanisms 506 and / or 508. The input mechanism 506 may be, for example, a rotatable input device or a depressible and rotatable input device. In some examples, the input mechanism 508 may be a button.

[0148] In some examples, the input mechanism 508 may be a microphone. The personal electronic device 500 may also include a GPS sensor 532, an accelerometer 534, an orientation sensor (such as a compass) 540, a gyroscope 536, a motion sensor 538, and / or combinations thereof, all of which may be operatively coupled to the I / O portion 514.

[0149] 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, for example, one or more computer processors 516, can cause those computer processors to perform the techniques described below, including processes 900-1100 (FIGS. 9-11). A computer readable storage medium may be any medium capable of tangibly containing or storing computer executable instructions for use by or in combination 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. A non-transitory computer readable storage medium may include, but is not limited to, magnetic, optical, and / or semiconductor storage devices. Examples of such storage devices include magnetic disks, optical disks based on CD, DVD, or Blu-ray technology, 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 various configurations.

[0150] The term "affordance" as used herein refers to a user-interactive graphical user interface object that may be displayed on a display screen of devices 100, 300 and / or 500 (FIGS. 1A, 3 and 5A-5B). For example, images (such as icons), buttons and text (such as hyperlinks) may each constitute an affordance.

[0151] 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 embodiments, this includes a cursor or other position marker, and the cursor acts as the "focus selector" such that when an input (such as a press input) is detected on a touch-sensitive surface (such as touchpad 355 of FIG. 3 or touch-sensitive surface 451 of FIG. 4B) while the cursor is positioned over a particular user interface element (such as a button, window, slider, or other user interface element), the particular user interface element is adjusted in accordance with the detected input. In some embodiments including a touchscreen display (such as 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 to the touchscreen acts as the "focus selector" such that when an input (such as a press input by contact) is detected at the location of a particular user interface element (such as a button, window, slider, or other user interface element) on the touchscreen display, the particular user interface element is adjusted in accordance with the detected input. In some embodiments, focus moves from one area of ​​the user interface to another area of ​​the user interface (e.g., by using a tab key or arrow keys to move focus from one button to another) without a corresponding cursor movement or contact movement on the touch screen display. In these embodiments, the focus selector moves to follow the movement of focus between different areas of the user interface. Regardless of what form the focus selector takes, it 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 (by indicating to the device the element of the user interface with which the user intends to interact).For example, positioning a focus selector (such as a cursor, touch, or selection box) over a button while a press input is detected on a touch-sensitive surface (such as a touchpad or touchscreen) indicates that the user intends to activate that button (and not other user interface elements displayed on the device's display).

[0152] The term "characteristic intensity" of a contact as used herein and in the claims refers to a characteristic of the 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 intensity of the contact may be based on a predetermined number of intensity samples or a set of samples collected over a predetermined time period (e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds, etc.) for a given event (e.g., after detecting the contact, before detecting lift-off of the contact, before or after detecting the start of movement of the contact, before detecting the end of the contact, before or after detecting an increase in the intensity of the contact, and / or before or after detecting a decrease in the intensity of the contact). The characteristic intensity of the contact may be based on one or more of a maximum intensity of the contact, an average intensity of the contact, the top 10% of the intensity of the contact, half the maximum intensity of the contact, 90% of the maximum intensity of the contact, etc. In some embodiments, the duration of the contact is used to determine the characteristic intensity (e.g., where 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 being performed by the user. For example, the set of one or more intensity thresholds may include a first intensity threshold and a second intensity threshold. In this example, a contact having a characteristic intensity that does not exceed the first intensity threshold is a first action, a contact having a characteristic intensity that exceeds the first intensity threshold and does not exceed a second intensity threshold is a second action, and a contact having a characteristic intensity that exceeds the second intensity threshold is a third action. In some embodiments, the comparison of the characteristic intensity to one or more thresholds is used to determine whether to perform one or more actions (such as whether to perform each action or not perform each action), rather than whether to perform the first action or the second action.

[0153] FIG. 5C illustrates detection of multiple contacts 552A-552E on a touch-sensitive display screen 504 having multiple intensity sensors 524A-524D. FIG. 5C illustrates an intensity diagram showing the current intensity measurements of intensity sensors 524A-524D in relation to intensity units. In this example, the intensity measurements of intensity sensors 524A and 524D are each 9 intensity units, and the intensity measurements of intensity sensors 524B and 524C are each 7 intensity units. In some embodiments, the total intensity is the sum of the intensity measurements of the multiple intensity sensors 524A-524D, which in this example is 32 intensity units. In some embodiments, each contact is assigned an intensity that is a portion of the total intensity. FIG. 5D illustrates assigning the total intensity to contacts 552A-552E based on their distance from the center of force 554. In this example, contacts 552A, 552B and 552E are each assigned a contact intensity of 8 intensity units of the total intensity, and contacts 552C and 552D are each assigned a contact intensity of 4 intensity units of the total intensity. More generally, in some embodiments, each contact j is assigned an intensity Ij that is a portion of the total intensity A according to a predetermined formula Ij=A·(Dj / ΣDi), where Dj is the distance of each contact j to the center of force, and ΣDi (from i=1 to the end) is the sum of the distances of all contacts to the center of force. The operations described with reference to Figures 5C-5D may be performed using electronic devices similar to or identical to device 100, 300 or 500. In some embodiments, the characteristic intensity of a contact is based on one or more intensities of the contact. In some embodiments, multiple intensity sensors are used to determine a characteristic intensity (such as a characteristic intensity of a single contact). It should be noted that the intensity plots are not part of the displayed user interface, but are included in FIGS. 5C-5D as an aid to the reader.

[0154] In some examples, a portion of the gesture is identified for purposes of determining the characteristic intensity. For example, a touch-sensitive surface may be subjected to a continuous swipe contact that transitions from a start position to an end position where the intensity of the contact increases. In this example, the characteristic intensity of the contact at the end position may be based on only a portion of the continuous swipe contact (such as only the portion of the swipe contact at the end position) rather than the entire swipe contact. In some examples, a smoothing algorithm may be applied to the intensity of the swipe contact prior to determining the characteristic intensity of the contact. For example, the smoothing algorithm may include 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 cases, these smoothing algorithms may remove minute irregularities in the intensity of the swipe contact for purposes of determining the characteristic intensity.

[0155] The intensity of a contact on the touch-sensitive surface may be characterized against one or more intensity thresholds, such as a contact detection intensity threshold, a weak press intensity threshold, a strong press intensity threshold, and / or one or more other intensity thresholds. In some embodiments, the weak press intensity threshold corresponds to an intensity at which the device performs an action typically associated with clicking a button on a physical mouse or trackpad. In some embodiments, the strong press intensity threshold corresponds to an intensity at which the device performs an action different from an action typically associated with clicking a button on a physical mouse or trackpad. In some embodiments, when a contact is detected whose characteristic intensity is less than the weak press intensity threshold (and is higher than a micro-touch detection intensity threshold, e.g., below which the contact is not detected), the device moves the focus selector according to the movement of the contact on the touch-sensitive surface without performing an action associated with the weak press intensity threshold or the strong press intensity threshold. In general, unless otherwise noted, these intensity thresholds are consistent across different user interface shapes.

[0156] An increase in the characteristic intensity of a contact from an intensity below the weak intensity threshold to an intensity between the weak and strong intensity thresholds may be referred to as a "weak press" input. An increase in the characteristic intensity of a contact from an intensity below the strong intensity threshold to an intensity above the strong intensity threshold may be referred to as a "strong press" input. 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 weak 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.

[0157] In some embodiments described herein, one or more actions are performed in response to detecting a gesture including a press input or in response to detecting a press input performed with each contact (or multiple contacts), and the press input is detected based at least in part on detecting that an intensity of the contact (or multiple contacts) has increased above a press input intensity threshold. In some embodiments, the action is performed in response to detecting that an intensity of the contact (e.g., a "top to bottom" movement of the press input) has increased above a press input intensity threshold. In some embodiments, the press input includes an intensity of the contact increasing above a press input intensity threshold followed by a decrease in the intensity of the contact below the press input intensity threshold, and the action is performed in response to detecting that an intensity of the subsequent contact (e.g., a "bottom to top" movement of the press input) has decreased below the press input intensity threshold.

[0158] 5E to 5H show that the strength of the contact 562 is the same as that of FIG. 5E ("IT L " (e.g., "IT ") from a weak press intensity below the threshold to the weak press intensity of D5 illustrates detection of a gesture including a press input corresponding to an intensity increasing above a hard press intensity threshold (such as "IT 562"). A gesture performed with contact 562 is detected on touch-sensitive surface 560 while cursor 576 is displayed over application icon 572B corresponding to App2 on displayed user interface 570 including application icons 572A-572D displayed within predetermined region 574. In some embodiments, the gesture is detected on touch-sensitive display 504. An intensity sensor detects the intensity of the contact on touch-sensitive surface 560. The intensity of contact 562 is detected on touch-sensitive surface 560 while cursor 576 is displayed over application icon 572B corresponding to App2 on displayed user interface 570 including application icons 572A-572D displayed within predetermined region 574. In some embodiments, the gesture is detected on touch-sensitive display 504. An intensity sensor detects the intensity of the contact on touch-sensitive surface 560. D The device determines that a hard press intensity threshold (such as "IT") has been exceeded and peaked. Contact 562 is held on touch-sensitive surface 560. In response to detecting the gesture, and contact 562 is D Based on having an intensity that exceeds a hard press intensity threshold (e.g., "hard press intensity threshold") during the gesture, reduced representations (e.g., thumbnails) 578A-578C of recently opened documents of App2 are displayed, as shown in Figures 5F-5H. In some embodiments, the intensity that is compared to one or more intensity thresholds is a characteristic intensity of the contact. It should be noted that the intensity diagram of contact 562 is included in Figures 5E-5H as an aid to the reader, and is not part of the displayed user interface.

[0159] In some embodiments, the display of representations 578A-578C includes an animation. For example, as shown in FIG. 5F, first representation 578A is displayed near application icon 572B. As the animation progresses, representation 578A moves up and representation 578B is displayed near application icon 572B, as shown in FIG. 5G. Then, as shown in FIG. 5H, representation 578A moves up and representation 578B moves up toward representation 578A and representation 578C is displayed near application icon 572B. Representations 578A-578C form a row above icon 572B. In some embodiments, as shown in FIGS. 5F-5G, the animation progresses according to the intensity of contact 562, in which case representations 578A-578C move in a direction that changes as the intensity of contact 562 ("IT D " and move upwards as the hard press intensity threshold increases. In some embodiments, the intensity on which the animation progresses is a characteristic intensity of the contact. The operations described with reference to Figures 5E-5H may be performed using electronic devices similar to or identical to devices 100, 300, or 500.

[0160] In some embodiments, to avoid unexpected inputs, also known as "jitter," a device utilizes intensity hysteresis, where the device defines or selects a hysteresis intensity threshold to have a predetermined relationship to the press input intensity threshold (such as the hysteresis intensity threshold being X intensity units below the press input intensity threshold, or the hysteresis intensity threshold being 75%, 90%, or some reasonable percentage of the press input intensity threshold). Thus, in some embodiments, a press input includes an intensity of each contact increasing above the press input intensity threshold, followed by a decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to the press input intensity threshold, with each action being performed in response to detecting that the intensity of the subsequent contact (such as a "down to up" movement of each press input) has decreased below the hysteresis intensity threshold corresponding to the press input intensity threshold. Similarly, in some embodiments, a press input is detected, and an action is performed in response to detecting the press input (such as an increase in the intensity of the contact or a decrease in the intensity of the contact, as the case may be), only if the device detects that the intensity of the contact increases from an intensity below the hysteresis intensity threshold to an intensity above the press input intensity threshold, and, optionally, thereafter decreases to an intensity below the hysteresis intensity.

[0161] For ease of explanation, a description of an action performed in response to a press input associated with a press input intensity threshold or in response to a gesture that includes a press input may be initiated in response to detecting that the intensity of the contact has increased above the press input intensity threshold, that the intensity of the contact has increased from an intensity below a hysteresis intensity threshold to an intensity above the press input intensity threshold, that the intensity of the contact has decreased below the press input intensity threshold, and / or that the intensity of the contact has decreased below a hysteresis intensity threshold corresponding to the press input intensity threshold. Additionally, in examples where an action is described as being performed in response to detecting that the intensity of the contact has decreased below a press input intensity threshold, the action may also be performed in response to detecting that the intensity of the contact has decreased below a hysteresis intensity threshold corresponding to and lower than the press input intensity threshold.

[0162] 6 illustrates multiple exemplary devices connected via one or more communication channels to complete a payment transaction according to some embodiments. One or more of the exemplary electronic devices (such as devices 100, 300, and 500) are configured to optionally detect input (such as a particular user input, an NFC field, etc.) and optionally transmit payment information (e.g., using NFC). One or more of the exemplary electronic devices may have NFC hardware and be configured to be NFC-enabled.

[0163] An electronic device (such as devices 100, 300, and 500) may be configured to store payment account information for each of one or more payment accounts. The payment account information may include, for example, one or more of a personal or company name, a billing address, a login, a password, an account number, an expiration date, a security code, a phone number, a bank (such as an issuing bank) and a card network identification information associated with the payment account. In some examples, the payment account information includes an image, such as a photo of a payment card (e.g., taken by the device and / or received by the device). In some examples, the electronic device receives a user input that includes at least some of the payment account information (e.g., receiving a user-entered credit, debit, account, or gift card number and expiration date). In some examples, the electronic device detects at least some of the payment account information from an image (e.g., of a payment card captured by a camera sensor of the device). In some examples, the electronic device receives at least some of the payment information from another device (e.g., another user device or a server). In some examples, the electronic device receives payment account information from a server where the user or user device account is associated with another service (e.g., an app for renting or selling audio and / or video files) for which the user or user device account has previously made a purchase or specified payment account data.

[0164] In some embodiments, a payment account is added to an electronic device (such as devices 100, 300, and 500) in such a way that the payment account information is securely stored on the electronic device. In some examples, after a user initiates such a process, the electronic device transmits the payment account information to a transaction coordination server, which then communicates with a server operated by the account's payment network (such as a payment server) to verify the validity of the information. The electronic device may be configured to receive a script from the server that allows the account's payment information to be programmed onto a secure component.

[0165] In some embodiments, communication between electronic devices 100, 300, and 500 facilitates a transaction (such as a general or specific transaction). For example, a first electronic device (such as 100) may act as a provisioning or management device and may send notifications of new or updated payment account data (such as information about a new account, updated information about an existing account, and / or alerts about an existing account) to a second device (such as 500). In another example, a first electronic device (such as 100) may send data to a second electronic device, where the data reflects information about a payment transaction facilitated by the first electronic device. The information may include one or more of the amount of the payment, the account used, the date and time of the purchase, and whether the default account has changed. The second device (such as 500) may use such information to update the default payment account (e.g., based on a learning algorithm or explicit user input).

[0166] Multiple electronic devices (e.g., 100, 300, 500, 700) are configured to communicate with each other over any of a variety of networks. For example, the multiple devices communicate using a Bluetooth connection 608 (e.g., a traditional Bluetooth connection or a Bluetooth Low Energy connection) or a WiFi network 606. Communications between multiple user devices may be coordinated to reduce the possibility of inappropriate sharing of information between multiple devices. For example, communications related to payment information may require the multiple devices to be paired (e.g., associated with each other via explicit user interaction) or associated with the same user account.

[0167] In some embodiments, an electronic device (e.g., 100, 300, 500) is used to communicate with a point-of-sale (POS) payment terminal 600, which may be NFC-enabled. The communication may occur using a variety of communication channels and / or technologies. In one example, the electronic device (e.g., 100, 300, 500) communicates with the payment terminal 600 using an NFC channel 610. In some examples, the payment terminal 600 communicates with the electronic device (e.g., 100, 300, 500) using a peer-to-peer NFC mode. The electronic device (e.g., 100, 300, 500) may be configured to send a signal to the payment terminal 600 that includes payment information for a payment account (e.g., a default account or an account selected for a particular transaction).

[0168] In some embodiments, the generation and / or transmission of the signal may be controlled by a secure component within the electronic device (e.g., 100, 300, 500). The secure component may require a specific user input before releasing the payment information. For example, the secure component may require detection of the electronic device being worn, detection of a button press, detection of the entry of a passcode, detection of a touch, detection of one or more option selections (e.g., received during interaction with an application), detection of a fingerprint signature, detection of a voice or voice command, and / or detection of a gesture or movement (e.g., rotation or acceleration). In some examples, if a communication channel (e.g., an NFC communication channel) with another device (e.g., payment terminal 600) is established within a certain time from detection of the input, the secure component releases the payment information for transmission to another device (e.g., payment terminal 600). In some examples, the secure component is a hardware component that controls the release of the secure information. In some embodiments, the secure component is a software component that controls the release of the secure information.

[0169] In some embodiments, the protocols associated with participating in a transaction depend, for example, on the type of device. For example, the conditions for generating and / or transmitting payment information may be different for a wearable device (such as device 500) than for a phone (such as device 100). For example, a payment and / or transmission condition for a wearable device may include detection of a button being pressed (e.g., after security verification), while a corresponding condition for a phone may not require a button press, but instead detection of a specific interaction with an application. In some examples, the conditions for transmitting and / or releasing payment information may include a specific input being made on each of multiple devices. For example, releasing payment information may require detection of a fingerprint and / or passcode on a device (such as device 100) and detection of a mechanical input (such as a button press) on the other device (such as device 500).

[0170] The payment terminal 600 may use the payment information to generate and send a signal to the payment server 604 to determine whether the payment is authorized. The payment server 604 may receive the payment information associated with the payment account and determine whether the proposed purchase is authorized. In some examples, the payment server 604 includes an issuing bank server. The payment terminal 600 communicates with the payment server 604 directly or indirectly through one or more other devices or systems (such as an acquiring bank server and / or a card network server).

[0171] The payment server 604 optionally uses at least a portion of the payment information to identify a given user account within a database of user accounts (e.g., 602). For example, each user account includes payment information. The account is optionally identified by identifying the account with specific payment information that matches that from the POS communication. In some examples, if the provided payment information does not match (e.g., an expiration date does not correspond to a credit, debit, or gift card number) or if there is no account with payment information that matches that from the POS communication, the payment is rejected.

[0172] In some embodiments, data from the user account further identifies one or more restrictions (e.g., credit limit), current or previous balance, previous transaction dates, locations and / or amounts, account status (e.g., active or frozen), and / or authorization instructions. In some examples, the payment server (e.g., 604) uses such data to determine whether to allow a payment. For example, the payment server denies a payment if the purchase amount added to the current balance would cause the account limit to be exceeded, if the account is frozen, if the previous transaction amount exceeds a threshold, or if the number or frequency of previous transactions exceeds a threshold.

[0173] In some embodiments, the payment server 604 responds to the POS payment terminal 600 with an indication as to whether the proposed purchase is permitted or denied. In some examples, the POS payment terminal 600 sends a signal to the electronic device (e.g., 100, 300, 500) to identify the outcome. For example, if the purchase is permitted (e.g., via a transaction coordinating server managing a transaction app on the user device), the POS payment terminal 600 sends a receipt to the electronic device (e.g., 100, 300, 500). In some examples, the POS payment terminal 600 presents an output (e.g., visual or audio output) indicating the outcome. The payment can be transmitted to the retailer as part of the authorization process or subsequently.

[0174] In some embodiments, the electronic device (e.g., 100, 300, 500) participates in a transaction that is completed without the involvement of the POS payment terminal 600. For example, upon detecting that a mechanical input has been received, a secure element within the electronic device (e.g., 100, 300, 500) releases the payment information so that an application on the electronic device can access the information (e.g., send the information to a server associated with the application).

[0175] In some embodiments, the electronic device (e.g., 100, 300, 500) is in a locked or unlocked state. In the locked state, the electronic device is powered on and operable but is prevented from performing a predetermined set of operations in response to user input. The predetermined set of operations may include navigation between user interfaces, activating or deactivating a predetermined set of functions, and activating or deactivating predetermined applications. The locked state can be used to prevent accidental or unauthorized use of some functions of the electronic device or activating or deactivating some functions on the electronic device. In the unlocked state, the electronic device 100 is powered on and operable but is not prevented from performing at least a portion of the predetermined set of operations that cannot be performed while in the locked state.

[0176] When a device is in a locked state, the device is said to be locked. In some embodiments, a device in a locked state can respond to a limited set of user inputs, including inputs corresponding to an attempt to transition the device to an unlocked state or inputs corresponding to powering off the device.

[0177] In some examples, the secure element is a hardware component (e.g., a secure microcontroller chip) configured to securely store data or algorithms. In some examples, the secure element provides (or releases) the payment information (e.g., an account number and / or a transaction-specific dynamic security code). In some examples, the secure element provides (or releases) the payment information in response to the device receiving authentication, such as a user authentication (e.g., fingerprint authentication, passcode authentication, detecting a double press of a hardware button when the device is in an unlocked state, and optionally, while the device is on the user's wrist, such as by detecting that the device is in contact with the user's skin). For example, the device detects a fingerprint at its fingerprint sensor (e.g., a fingerprint sensor integrated in a button). The device determines whether the fingerprint matches a registered fingerprint. In response to a determination that the fingerprint matches a registered fingerprint, the secure element provides (or releases) the payment information. In response to a determination that the fingerprint does not match a registered fingerprint, the secure element refrains from providing (or releasing) the payment information.

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

[0179] 7A-7L illustrate exemplary user interface devices for managing remote permission to proceed with an action, according to some embodiments. The user interfaces in these figures are used to illustrate the following processes, including those in FIGS. 9-11.

[0180] FIG. 7A illustrates a requesting device 700 (e.g., an electronic device such as a laptop computer with a display that does not have a hardware token generator) and an authenticating device 500 (e.g., an electronic device such as a smartphone with a display that does not have a hardware token generator). In some examples, the authenticating device 500 includes hardware (e.g., a hardware token generator) that can perform a certain function, but the requesting device 700 does not include that hardware and cannot perform that function. Using remote authorization in such a situation allows a user to utilize the hardware capabilities of one device (e.g., the authenticating device 500) while using (or performing a task on) a different device (e.g., the requesting device 700). In some examples, this technique allows a parent to remotely authorize an action using a first device (e.g., the authenticating device 500) that is requested (or initiated) by the parent's child using a second device (e.g., the requesting device) (regardless of the hardware capabilities of the second device). In some examples, the techniques help maintain a given level of security by avoiding the need to distribute secure data to systems that do not comply with a given security standard (e.g., avoiding the need to generate or store secure information on a system that does not have a secure element).

[0181] In some examples, the requestor device 700 and the authenticator device 500 are configured to communicate, such as via wireless communication. For example, the requestor device 700 and the authenticator device 500 can communicate via a personal area network, a local area network, a wide area network, Bluetooth, a WLAN, a cellular network, or any combination thereof.

[0182] The requesting device 700 displays a user interface 702 that includes one or more options 708. In this example, the one or more options 708 are names of corresponding remote servers. In some examples, the requesting device 700 displays multiple options 708. The authenticating device 500 is in an on state. In this example, the display of the authenticating device 500 is blank (e.g., the display is off).

[0183] The requesting device 700 receives a selection of one or more options (e.g., receives a user selection of a name or address of a remote server, receives a user selection of a predetermined security token generation algorithm from among multiple token generation algorithms, receives a user selection of the length of the security token to be generated, or a combination thereof). In this example, the requesting device 700 receives activation of option 706 of one or more options with cursor 704. In FIG. 7B, the requesting device detects activation of continuation affordance 714 with cursor 704.

[0184] In some examples, in FIG. 7C , the requesting device 700 provides options corresponding to multiple authentication devices (e.g., by displaying the options), and the options corresponding to multiple authentication devices include an option 716 labeled Bob's Phone corresponding to authentication device 500.

[0185] In Figure 7C, the requester device 700 receives input selecting option 716 corresponding to the authenticator. In Figure 7D, the requester device receives a selection of option 722 (e.g., detects user activation of the "Confirm" affordance or the "Connect" affordance) and proceeds with an action associated with the selected option or options 706 (e.g., creates a secure network connection, proceeds with a payment transaction). In some examples, the action is based on the selected option or options 706. In some examples, a plurality of one or more options are selected.

[0186] The requesting device 700 sends a request to proceed with the action. The request includes information about (or based on) one or more options selected. In some examples, the requesting device 700 sends the request to proceed with the action to the authenticator 500 based on input received selecting an option 716 corresponding to the authenticator.

[0187] As shown in Figure 7E, the authenticator 500 receives a request to proceed with the action. In some examples, the transmission from the requester 700 to the authenticator 500 is direct. In some examples, the transmission from the requester 700 to the authenticator 500 is indirect, such as via an intermediate device.

[0188] In some examples, the authentication device 500 is in a locked state when the request to proceed with the action is received. In response to receiving the request to proceed with the action, the authentication device 500 (while remaining in the locked state) displays a request notification 730 on the display (e.g., on the lock screen of the authentication device 500). In some examples, the request notification 730 includes one or more pieces of information 732 about (or based on) the one or more selected options and an indication 734 of the requesting device 700.

[0189] In some examples, as shown in FIG. 7F, the authentication device 500 receives an input that activates the request notification 730 (e.g., a user swipe gesture 736 that slides the request notification 730 beyond a threshold distance, or a user input gesture that presses on the notification with a unique intensity above a respective threshold intensity).

[0190] In some examples, as shown in FIG. 7G, the authentication device 500 notifies the user of the authentication device 500 (e.g., by displaying a request 740 and / or generating a haptic vibration) that permission to unlock the authentication device 500 has been requested.

[0191] In some examples, the authentication device 500 receives permission (e.g., via a fingerprint or passcode) to unlock the authentication device (e.g., transition the authentication device 500 to an unlocked state). This permission to unlock the device is separate and additional to permission to proceed with the action. In some examples, permission to unlock and permission to proceed with the action can be satisfied using the same technique (e.g., using the same fingerprint or the same password). In some examples, permission to unlock and permission to proceed with the action can be satisfied using different techniques (e.g., using a fingerprint to grant permission to unlock and a password to grant permission to proceed with the action). In some examples, permission to unlock and permission to proceed with the action are satisfied using the same technique but different inputs (e.g., using a first fingerprint to grant permission to unlock and a second fingerprint to grant permission to proceed with the action, or a first password to grant permission to unlock and a second password to grant permission to proceed with the action). Upon receiving (or following) permission to unlock the authentication device 500, the authentication device 500 performs the unlocking (eg, transitions the authentication device 500 to an unlocked state).

[0192] In FIG. 7H , the authentication device 500 (e.g., in response to receiving a request to proceed with the action, in response to unlocking) simultaneously displays on the display of the authentication device 500 an indication 750 of the request to proceed with the action, information 752 about the one or more selected options (e.g., the name of the remote server to connect to, the security token generation algorithm, the length of the security token to be generated, one or more products / services to purchase, one or more shipping methods, or a combination thereof), and an indication 754 of the requesting device 700 (e.g., the name of the requesting device, an identifier of the requesting device, or an icon or image representing the requesting device, such as a line drawing of the requesting device's casing).

[0193] In some examples, the indication 754 of the requesting device 700 includes a graphical representation of the requesting device 700. In some examples, the graphical representation of the requesting device 700 is an iconic representation of the requesting device 700, such as a line drawing of the device's housing. In some examples, the iconic representation includes one or more of the finish, form factor, and one or more dimensional information of the requesting device 700, allowing a user to quickly and accurately identify the device for which authentication is being requested. For example, the graphical representation may indicate that the requesting device 700 is a Gold MacBook® or a 27” iMac®.

[0194] The authentication device 500 displays a request 756 for permission to proceed with the action on the display of the authentication device 500 .

[0195] 7I, the authentication device 500 receives input (e.g., user authentication information, a fingerprint of a finger 758, a passcode) corresponding to a request for permission to proceed with an action. For example, the authentication device 500 receives a fingerprint of a finger 758 as input and determines that the fingerprint matches a fingerprint that can authorize the authentication device 500 to proceed with the action.

[0196] The authenticator 500 transmits a response to the request to proceed with the action. For example, the authenticator 500 transmits the response to the requester 700. The response to the request to proceed with the action is based on the input corresponding to the request for permission to proceed with the action. In some examples, the authenticator 500 provides an indication 760 that a response to the request to proceed with the action has been transmitted.

[0197] The requesting device 700 receives a response to the request to continue the action (e.g., in response to sending the request, following sending the request). For example, the requesting device 700 receives the response to the request to continue the action from the authentication device 500.

[0198] As shown in FIG. 7J, following a determination in the requesting device 700 that the response to the request to proceed with the action indicates that authorization in the authentication device 500 (e.g., user authentication by the authentication device 500 based on biometrics, fingerprint, or password) was successful, the requesting device 700 displays an indication 762 on the display of the requesting device 700 that authorization was successful.

[0199] In some examples, as shown in FIG. 7K, the requestor device 700 displays an indication 764 that the requestor device 700 (and alternatively or additionally, the authenticator device 500) has proceeded with the action.

[0200] 7L, following a determination at the requester device 700 that the response to the request to proceed with the action indicates that authorization (e.g., biometric, fingerprint, or password-based user authentication by the authentication device 500) was not successful, the requester device 700 displays an indication 766 that authorization was not successful on the display of the requester device 700. The indication 762 that authorization was successful is distinct from the indication 766 that authorization was not successful. In some examples, the authentication device 500 displays an indication 768 that authorization was not successful.

[0201] In some examples, receiving permission to proceed includes receiving a passcode via a touch-sensitive surface of authentication device 500 and determining that the passcode matches a registered passcode that allows the action to be permitted. In some examples, receiving permission to proceed includes detecting a fingerprint using a fingerprint sensor and determining that the fingerprint matches a registered fingerprint that allows the action to be permitted. For example, authentication device 500 stores information about one or more fingerprints of the user and uses each fingerprint to determine whether the action is permitted. In some examples, receiving permission to proceed includes receiving a double press of a mechanical button while the device is in an unlocked state (and optionally while the device is continuously on the user's wrist since the device was unlocked by providing an authentication credential to the device, where the continuous presence of the device on the user's wrist is determined by periodically verifying that the device is in contact with the user's skin).

[0202] In some examples, the authenticator 500 includes hardware (e.g., a hardware token generator, a secure element) configured to respond to input corresponding to a request for permission to proceed with an action (e.g., by generating or providing a token, by generating or providing payment information), and the requester 700 does not include that hardware (e.g., a hardware token generator, a secure element). Thus, a user can leverage the hardware capabilities of one device (e.g., the authenticator 500) while using (or performing a task on) a different device (e.g., the requester 700).

[0203] 8A-8M illustrate exemplary user interfaces for managing remote authorization to proceed with a payment transaction according to some embodiments. The user interfaces in these figures are used to illustrate the following processes, including those in FIGS. 9-11.

[0204] FIG. 8A illustrates a requester device 700 (e.g., an electronic device such as a laptop computer with a display that does not have a secure element) and an authenticator device 500 (e.g., an electronic device such as a smartphone with a display that has a secure element). In some examples, the authenticator device 500 includes hardware (e.g., a secure element) that can perform a certain function (e.g., generating payment account information for use in a payment transaction) and the requester device 700 does not include that hardware and cannot perform that function. Using remote authorization in such situations allows a user to take advantage of the hardware capabilities of one device (e.g., the authenticator device 500) while using (or performing a task on) a different device (e.g., the requester device 700). For example, a user can browse a website, select items for purchase using the requester device 700, and use the authenticator device 500 to proceed with payment for the selected items.

[0205] The requesting device 700 displays a user interface 802 of a computer application. In this example, the application is a web browser application configured to search and display a website, such as through searching and displaying a markup language. In some examples, the requesting device 700 receives user input to navigate to a web address. The user interface 802 includes a URI / URL field 802A that displays the web address. In some examples, the searched web page is displayed in a first portion 802C of the user interface 802 (e.g., a web page displaying portion), which is different from a second portion 802B of the user interface 802 (e.g., a non-web page displaying portion). In some examples, the second portion is a status bar, a non-web page displaying portion, etc. In some examples, the web browser application is configured to display the searched web page in the first portion 802C, and is not configured to display the searched web page in the second portion 802B. This allows a user to distinguish between content that is displayed as a result of a rendered web page (e.g., in the first portion 802C) and content that is displayed as a result of content provided by a web browser application (e.g., in the second portion 802B).

[0206] In Figure 8A, a requester device 700 navigates a website and receives a user command to add one or more items to a virtual shopping cart. The requester device 700 displays an affordance 804 that, when activated, transitions to (e.g., causes to be displayed) a payment webpage 805 in Figure 8B. In some examples, the affordance 804 is displayed in a first portion 802C of a user interface 802 of a web browser application.

[0207] In FIG. 8B, the requesting device 700 displays a payment webpage (e.g., in first portion 802C) (e.g., in response to detecting activation of affordance 804). In response to determining that a set of one or more transaction conditions is met, the requesting device 700 displays affordance 802D (e.g., in second portion 802B, first portion 802C). For example, the set of one or more transaction conditions includes one or more of: (1) a condition that is met when a remote server (e.g., that provided a payment webpage for display) requests that a payment affordance be displayed; (2) a condition that is met when the requesting device 700 determines that a remote server (e.g., that provided a payment webpage for display) is configured to accept payments using a particular payment method; and (3) a condition that is met when the requesting device 700 determines that the displayed webpage includes a request for payment, e.g., displayed in first portion 802C. Affordance 802D, when activated, causes a payment sheet 802E to be displayed. In some examples, the payment sheet 802E is a user interface of the requester's operating system. In some embodiments, the payment sheet 802E is part of a first party application provided by the requester's operating system provider.

[0208] In some examples, as shown in FIGS. 8C-1 and 8C-2, the payment sheet 802E slides into the display (e.g., into view on the display) in response to activation of the affordance 802D. In some examples, the payment sheet 802E at least partially obscures the payment webpage displayed in the first portion 802C. In some examples, the payment sheet 802E at least partially obscures the second portion 802B. In some examples, the payment sheet 802E is not part of the first portion 802C or the second portion 802C, but rather overlaps with the two portions.

[0209] The payment sheet 802E includes one or more options for selection, including, for example, one or more products / services to purchase, one or more shipping methods (e.g., a shipping address), one or more payment accounts, one or more authentication devices, and a contact name.

[0210] In some examples, the payment sheet 802E includes an indication of a default payment account 802G associated with the authenticator (e.g., the default authenticator). In some examples, the payment sheet 802E includes a user-configurable "ship-to" mailing address. For example, the requester 700 fills in a mailing address field based on information stored on the requester 700 (e.g., based on profile information stored in a contacts application or a default contact name). In some examples, the requester 700 receives a user selection of an address to use as a mailing address. In some examples, the payment sheet 802E includes a user-configurable contact name. The requester 700 fills in a contact name field based on information stored on the requester 700 (e.g., based on profile information stored in a contacts application or a default contact name). In some examples, the payment sheet 802E includes a total amount, tax, and / or shipping fee for the payment transaction. By receiving a selection of various options, the requester device reveals the user's purchasing preferences.

[0211] In some examples, the payment sheet 802E includes a payment option 802F that, when activated, causes the display of options for multiple payment accounts associated with the corresponding authentication device, as shown in FIG. 8D. In some embodiments, a first payment account (e.g., indicated by option 802H) is associated with a first authentication device (e.g., indicated by a graphical indication 802I of the first authentication device), and a second payment account (e.g., indicated by option 802J) corresponds to a second authentication device (e.g., indicated by a graphical indication 802K of the second authentication device) that is different from the first authentication device. For example, the payment accounts are grouped according to their corresponding authentication device or displayed with a graphical or textual indication of the authentication device that corresponds to each payment account. In some examples, the first area includes one or more indications (or multiple indications) of the payment accounts associated with the first authentication device, and the second area, different from the first area, includes one or more indications (or multiple indications) of the payment accounts associated with the second authentication device. In some examples, at least some of the payment accounts associated with the first authentication device are different from the payment accounts associated with the second authentication device. The requesting device reveals the user's payment preferences by receiving predetermined payment selections from among various payment accounts provisioned on the user's various personal devices.

[0212] In some examples, the requester device 700 receives a selection of an option 802H corresponding to each payment account from among the options for multiple payment accounts. In response to receiving the selection of the option 802H corresponding to each payment account, the requester device 700 selects each authentication device based on the selected option 802H corresponding to each payment account (e.g., as indicated by the graphical indication 802I of the first authentication device). In this example, the display of the authentication device 500 is blank (e.g., the display is turned off). In response to receiving the selection of the option 802H corresponding to each payment account from among the options for multiple payment accounts, the requester device displays the exemplary user interface shown in FIG. 8E.

[0213] In some examples, the requesting device is a smartphone. In some examples, the smartphone displays a user interface for a web browser application. In some examples, the smartphone displays a user interface for an application downloaded from a remote server and installed on the smartphone. In some examples, the smartphone detects activation of an affordance (e.g., 802D) and in response displays a payment sheet (e.g., 802E). In some examples, the requesting device is a smartwatch. In some examples, the smartwatch displays a user interface for an application downloaded from a remote server and installed on the smartwatch. In some examples, the smartwatch detects activation of an affordance (e.g., 802D) and in response displays a payment sheet (e.g., 802E).

[0214] In FIG. 8E, after the requesting device 700 receives a selection of one or more options (e.g., receives a user selection of a contact name, receives a user selection of a payment account, receives a selection of an authentication device, receives a selection of one or more products / services to purchase, or a combination thereof), the requesting device 700 receives a selection of option 822 (e.g., detects user activation of a “Confirm” affordance or a “Payment” affordance) and proceeds with an action associated with the selected option or options (e.g., 802H) (e.g., proceeds with the payment transaction). In some examples, the action is based on the selected option or options (e.g., 802H). In some examples, a plurality of the one or more options is selected.

[0215] The requesting device 700 sends a request to proceed with the action, the request including information about (or based on) one or more selected options. In some examples, the requesting device 700 sends the request to proceed with the action to the authenticator 500 based on the input received selecting option 802H corresponding to the authenticator.

[0216] As shown in Figure 8F, the authenticator 500 receives a request to proceed with the action. The transmission from the requester 700 to the authenticator 500 may be direct or indirect, such as via an intermediate device.

[0217] In response to receiving the request to proceed with the action, the authentication device 500 (while remaining in the locked state) displays a request notification 830 on the display (e.g., on the lock screen of the authentication device 500). In some examples, the authentication device 500 is in the locked state when the request to proceed with the action is received. In some examples, the request notification 830 includes one or more pieces of information 832 about (or based on) the one or more options selected and an indication 834 of the requesting device 700.

[0218] In some examples, as shown in FIG. 8G, the authentication device 500 receives an input that activates the request notification 830 (e.g., a user swipe gesture 836 that slides the request notification 830 beyond a threshold distance, or a user input gesture that presses on the notification with a unique intensity above a respective threshold intensity).

[0219] In some examples, as shown in FIG. 8H, the authentication device 500 requests permission to unlock the authentication device 500 (eg, by displaying a request 840 and / or generating a haptic vibration).

[0220] In some examples, the authentication device 500 receives (e.g., via a fingerprint or passcode) permission to unlock the authentication device (e.g., transition the authentication device 500 to an unlocked state). This permission to unlock the device is separate and additional to the permission to proceed with the action. In some examples, the permission to unlock and the permission to proceed with the action can be satisfied using the same technique (e.g., using the same fingerprint or the same password). In some examples, the permission to unlock and the permission to proceed with the action can be satisfied using different techniques (e.g., using a fingerprint to grant permission to unlock and a password to grant permission to proceed with the action). In some examples, the permission to unlock and the permission to proceed with the action are satisfied using the same technique but different inputs (e.g., using a first fingerprint to grant permission to unlock and a second fingerprint to grant permission to proceed with the action, a first password to grant permission to unlock and a second password to grant permission to proceed with the action). In response to (or subsequent to) receiving permission to unlock the authentication device 500, the authentication device 500 performs the unlock (e.g., transitions the authentication device 500 to an unlocked state).

[0221] In FIG. 8I, the authentication device 500 (e.g., in response to receiving a request to proceed with the action, in response to unlocking) simultaneously displays on the display of the authentication device 500 an indication 850 of the request to proceed with the action, information 852 about one or more selected options (e.g., selecting a contact name, selecting a payment account, selecting an authentication device, selecting one or more products / services to purchase, selecting one or more shipping methods, or a combination thereof), and an indication 854 of the requesting device 700 (e.g., the name of the requesting device, an identifier of the requesting device, or an icon or image representing the requesting device, such as a line drawing of the requesting device's casing).

[0222] In some examples, the indication 854 of the requesting device 700 includes a graphical representation of the requesting device 700. In some examples, the graphical representation of the requesting device 700 is an iconic representation of the requesting device 700, such as a line drawing of the device's housing. In some examples, the iconic representation includes one or more of the finish, form factor, and one or more dimensional information of the requesting device 700. For example, the graphical representation may indicate that the requesting device 700 is a Gold MacBook® or a 27” iMac®.

[0223] The authentication device 500 displays a request 856 for permission to proceed with the action on the display of the authentication device 500 .

[0224] 8K, the authentication device 500 receives input (e.g., user authentication information, a fingerprint of a finger 858, a passcode) corresponding to a request for permission to proceed with an action. For example, the authentication device 500 receives a fingerprint of a finger 858 as input and determines that the fingerprint matches a fingerprint that can be allowed to proceed with the action.

[0225] The authenticator 500 transmits a response to the request to proceed with the action. For example, the authenticator 500 transmits the response to the requester 700. The response to the request to proceed with the action is based on the input corresponding to the request for permission to proceed with the action. In some examples, the authenticator 500 provides an indication 860 that a response to the request to proceed with the action has been transmitted.

[0226] The requesting device 700 receives a response to the request to continue the action (e.g., in response to sending the request, following sending the request). For example, the requesting device 700 receives the response to the request to continue the action from the authentication device 500.

[0227] As shown in FIG. 8K, following a determination at the requesting device 700 that the response to the request to proceed with the action indicates that authorization at the authentication device 500 (e.g., user authentication by the authentication device 500 based on biometrics, fingerprint, or password) was successful, the requesting device 700 displays an indication 862 on the display of the requesting device 700 that authorization was successful.

[0228] 8L, the requesting device 700 displays (e.g., in the first portion 802C) an indication 864 that the requesting device 700 (and alternatively or additionally, the authenticator 500) has proceeded with the action. In some examples, the requesting device 700 displays (e.g., in the second portion 802B) an indication that the requesting device 700 (and alternatively or additionally, the authenticator 500) has proceeded with the action.

[0229] 8M, in response to a request to proceed with the action indicating that authorization (e.g., user authentication by biometric, fingerprint, or password-based authentication device 500) was not successful, an indication that authorization was not successful 866 is displayed on the display of requesting device 700. Indication that authorization was successful 862 is different from indication that authorization was not successful 866.

[0230] In some examples, receiving permission to proceed with the action includes receiving a passcode via a touch-sensitive surface of authentication device 500 and determining that the passcode matches a registered passcode for which the action is permitted. In some examples, allowing to proceed includes detecting a fingerprint using a fingerprint sensor and determining that the fingerprint matches a registered fingerprint for which the action is permitted. For example, authentication device 500 stores information about one or more fingerprints of a user and uses each fingerprint to determine whether the action is permitted. In some examples, allowing to proceed includes receiving a double press of a mechanical button while the device is in an unlocked state (and optionally while the device is on the user's wrist, such as by detecting that the device is in contact with the user's skin).

[0231] In some examples, the authenticator 500 includes hardware (e.g., a secure element) configured to respond to input corresponding to a request for permission to proceed with an action (e.g., by generating or providing payment information), and the requester 700 does not include that hardware (e.g., a secure element). Thus, a user can take advantage of the hardware capabilities of one device (e.g., the authenticator 500) while using (or performing a task on) a different device (e.g., the requester 700).

[0232] 9A-9D are flow diagrams illustrating a method 900 for managing remote permission to proceed with an action using an electronic device according to some embodiments. Method 900 is performed in a requester device (e.g., 100, 300, 500) with a display and an authentication device (e.g., 700) with a display. In some examples, authentication device 500 includes hardware (e.g., secure element, token generator) configured to respond to input corresponding to a request for permission to proceed with an action (e.g., by generating or providing payment information) and requester device 700 does not include the hardware (e.g., secure element). Some operations in method 900 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0233] As described below, method 900 provides an intuitive way to manage remote permissions to proceed with an action, which reduces the cognitive burden on the user and creates a more efficient human-machine interface. For battery-operated computing devices, allowing users to manage remote permissions faster and more efficiently conserves power and increases the time between battery charges.

[0234] In block 902, a requesting device (e.g., 700, a laptop device without a hardware token generator) receives a selection of one or more options (e.g., 708, 718, 802G, 802H, 802J). For example, the requesting device may receive a user selection of a remote server name or address, a user selection of a given security token generation algorithm from among multiple token generation algorithms, a user selection of the length of the security token to be generated, a user selection of one or more products / services to purchase, a user selection of one or more shipping methods, a user selection of a payment account, or any combination thereof.

[0235] In block 904, the requesting device (e.g., 700) receives a selection of an option (e.g., 722, 822) to proceed with an action associated with the selected option or options. In some examples, the action creates a secure network connection. In some examples, the action proceeds with a payment transaction. In some examples, receiving the selection of an option includes detecting a user activation of a "confirm" affordance or a "connect" affordance. In some examples, the action is based on the selected option or options (e.g., 708, 718, 802G, 802H, 802J).

[0236] At block 906, the requesting device (e.g., 700) sends a request to proceed with the action. The request includes information about (or based on) one or more selected options (e.g., 708, 718, 802G, 802H, 802J). For example, the request may include selected shipping information or selected payment account information.

[0237] At block 908, the authenticator (e.g., 500, a phone device that does not have a hardware token generator, a phone device that does not have a secure element) receives a request to proceed with the action. In some examples, the transmission of the request to proceed with the action from the requester (e.g., 700) to the authenticator (e.g., 500) is direct. In some examples, the transmission is indirect, such as through an intermediate device.

[0238] In block 910, the authenticator (e.g., in response to receiving the request) simultaneously displays on the authenticator's display an indication of a request to proceed with the action (e.g., 750, 850), information about the selected option or options (e.g., 752, 852), and an indication of the requesting device (e.g., 754, 854) (e.g., the name of the requesting laptop or phone, an identifier for the requesting device, or an icon or image representing the requesting device, such as a line drawing of the device's housing).

[0239] At block 912, the authentication device (eg, 500) displays on the authentication device's display a request (eg, 756, 856) for permission to proceed with the action.

[0240] At block 914, the authentication device receives input (eg, user authentication information, finger 758 / 858 fingerprint, passcode) corresponding to a request for permission to proceed with the action.

[0241] In block 916, the authentication device transmits a response to the request to proceed with the action. The response to the request to proceed with the action is based on the input corresponding to the request for permission to proceed with the action.

[0242] At block 918, the requesting device receives a response to the request to continue the action (eg, in response to, subsequent to, sending the request).

[0243] In block 920, pursuant to a determination at the requester device (e.g., 700) that the response to the request to proceed with the action indicates that authorization (e.g., user authentication) at the authentication device (e.g., 500) was successful (e.g., a user successfully authenticated based on biometric, fingerprint, or password), the requester device (e.g., 700) displays an indication (e.g., 762, 862) on the display of the requester device that authorization was successful.

[0244] In block 932, pursuant to a determination at the requester device (e.g., 700) that the response to the request to proceed with the action indicates that authorization at the authentication device (e.g., 500) was not successful (e.g., biometric, fingerprint, password-based user authentication), the requester device (e.g., 700) displays an indication that authorization was not successful (e.g., 766, 866) on the display of the requester device. An indication that authorization was successful (e.g., 762, 862) is distinct from an indication that authorization was not successful (e.g., 766, 866).

[0245] In some examples, receiving permission to proceed with the action includes receiving a passcode via a touch-sensitive surface of the electronic device. Authorization is successful if it is determined that the passcode matches a registered passcode that allows the action. In some examples, authorization to proceed includes detecting a fingerprint. Authorization is successful if it is determined that the fingerprint matches a registered fingerprint that allows the action. For example, the device stores information about one or more fingerprints of the user and uses each fingerprint to determine whether the action is allowed. In some examples, authorization to proceed includes receiving a double press of a mechanical button while the device (e.g., a smartwatch device) is in an unlocked state (and optionally while the device is on the user's wrist, such as by detecting that the device is in contact with the user's skin).

[0246] In some examples, the authenticator device (e.g., 500) includes hardware (e.g., a hardware token generator, a secure element) configured to respond to input corresponding to a request for permission to proceed with an action (e.g., by generating or providing a token, by generating or providing payment information), and the requester device (e.g., 700) does not include that hardware (e.g., a hardware token generator, a secure element).

[0247] In some examples, the action creates a secure network connection between the authentication device (e.g., 500) and the remote server at block 824. In response to a determination in the authentication device (e.g., 500) that the input corresponding to the request for permission to proceed with the action matches the input that was allowed to proceed with the action (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authentication device continues the action (e.g., creates a secure network connection) using hardware (e.g., a hardware token generator) configured to respond to the input corresponding to the request for permission to proceed with the action. Thus, the authentication device continues creating the secure network connection by using a token generated by the hardware token generator. For example, the authentication device (e.g., 500) transmits the token to the remote server. In some examples, the action continues with the payment transaction without creating a secure network connection.

[0248] In some examples, in block 826, the action creates a secure network connection between the requesting device (e.g., 700) and the remote server. In response to a determination at the authenticating device (e.g., 500) that the input corresponding to the request for permission to proceed with the action matches the input that was allowed to proceed with the action (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authenticating device sends a token to the requesting device. The token is generated using hardware (e.g., a hardware token generator) of the authenticating device (e.g., 500) configured to respond to the input corresponding to the request for permission to proceed with the action. The requesting device (e.g., 700) receives the token from the authenticating device. The requesting device (e.g., 700) continues the action (e.g., creates a secure network connection) using the token received from the authenticating device (e.g., 500).

[0249] In some examples, the indication of the requesting device (e.g., 700) includes a graphical representation (e.g., 754, 854) of the requesting device (e.g., 700). In some examples, the graphical representation (e.g., 754, 854) of the requesting device (e.g., 700) is an iconic representation of the requesting device, such as a line drawing of the device's housing, where the iconic representation includes one or more of the requesting device's finish, form factor, and one or more dimensional information. For example, the graphical representation can indicate that the requesting device (e.g., 700) is a Gold MacBook® or a 27” iMac®.

[0250] In some examples, the authentication device is in a locked state when an input (e.g., user credentials, fingerprint, passcode) corresponding to the request for permission to proceed with the action is received in block 828. Pursuant to a determination in the authentication device that the input corresponding to the request for permission to proceed with the action matches an input that is authorized to proceed with the action, the authentication device transmits a response to the request for proceeding with the action while maintaining (e.g., remaining) in a locked state, and the response to the request for proceeding with the action is based on the input. Thus, there is no need to request that the authentication device (e.g., 500) be unlocked (as in FIGS. 7G, 8H and their accompanying descriptions).

[0251] In some examples, detecting an interaction with the fingerprint sensor (in the absence of an authentication request) while the authentication device is locked unlocks the authentication device (e.g., 500) (e.g., touching on a fingerprint sensor integrated into the home button unlocks the device if detected while the lock screen is displayed, but allowing the request without unlocking the authentication device if a touch on the fingerprint sensor is detected while a request is displayed on the authentication device display). Thus, in some examples, swipe gestures 736 and 836 cause the user interfaces of Figures 7H and 8I, respectively, to be displayed.

[0252] In some examples, the requesting device (e.g., 700) is signed in to the service using an account when it sends the request to proceed with the action, and the authenticating device (e.g., 500) is signed in to the service using an account when it receives the request to proceed with the action (e.g., the requesting device and authenticating device are both signed in to the service using the same user account / same user credentials). Alternatively, the requesting device (e.g., 700) and authenticating device (e.g., 500) are each signed in to separate accounts on the same service, and the separate accounts are linked to each other (e.g., explicitly linked to each other to authorize the action).

[0253] In some examples, the action proceeds with the payment transaction at block 830, and in response to a determination at the authenticator (e.g., 500) that the input corresponding to the request for permission to proceed with the action matches an input authorized for the action to proceed (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) proceeds with the action (e.g., proceeds with the payment transaction) using hardware (e.g., secure element) configured to respond to the input corresponding to the request for permission to proceed with the action. In some examples, the hardware used to perform the action is not available to the requester (e.g., 700). For example, the authenticator (e.g., 500) provides (to the payment transaction / retailer) payment information (e.g., payment account number) for use in the payment transaction so that the retailer can receive payment from the payment institution or requester.

[0254] In some examples, at block 832, the action proceeds with the payment transaction, and in response to a determination at the authenticator (e.g., 500) that the input corresponding to the request for permission to proceed with the action matches the input authorized to proceed with the action (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) transmits payment information to the requester. The payment information is generated using hardware (e.g., a secure element) configured to respond to the input corresponding to the request for permission to proceed with the action. In some examples, the hardware used to generate the payment information is not available to the requester (e.g., 700). The requester (e.g., 700) receives the payment information from the authenticator (e.g., 500). The requester (e.g., 700) proceeds with the action (e.g., proceed with the payment transaction, provide the payment information to a payment transaction server / retailer so that the retailer can receive payment from the payment institution) using the payment information (e.g., payment account number) received from the authenticator (e.g., 500).

[0255] In some examples, an authenticator (e.g., 500) sends a token to a server (e.g., a remote server) and the server uses the token to obtain resources associated with the token (e.g., CPU time, network sockets, memory access). In some examples, a requester (e.g., 700) sends a token to a server (e.g., a remote server) and the server uses the token to obtain resources associated with the token (e.g., CPU time, network sockets, memory access).

[0256] In some examples, the authenticator (e.g., 500) sends payment information to a payment transaction server (e.g., a retailer's server), which uses the payment information to obtain resources (e.g., funds) associated with the payment information (e.g., payment from a user payment account specified by the token). In some examples, the requester (e.g., 700) sends payment information to a payment transaction server (e.g., a retailer's server), which uses the payment information to obtain resources (e.g., funds) associated with the payment information (e.g., payment from a user payment account specified by the token).

[0257] In some examples, the action proceeds with a payment transaction. The authenticator (e.g., 500) includes hardware (e.g., a hardware secure element) that authorizes the payment transaction. In some examples, the hardware is configured to respond to an input corresponding to a request for authorization to proceed with the action. For example, once authorization is received by authenticating a user (e.g., using fingerprint authentication, using passcode authentication), the authenticator (e.g., 500) hardware generates and / or provides payment information. In some examples, the requester (e.g., 700) does not include hardware that authorizes a payment transaction. In some examples, the authenticator (e.g., 500) includes hardware that authenticates a user and the requester (e.g., 700) does not include hardware that authenticates a user.

[0258] In some examples, the action continues with the payment transaction. Following a determination at the authentication device (e.g., 500) that an input corresponding to a request for permission to continue the action matches an input that is permitted to continue the action (e.g., successful user authentication based on user input, user authentication information, fingerprint, passcode), the authentication device (e.g., 500) continues with the action (e.g., continues with the payment transaction with the payment information) without further input from the request device (e.g., 700). For example, the authentication device transmits information required to process the payment transaction (e.g., payment information) to a payment transaction server. In some examples, following a determination that permission to continue has been provided, the authentication device (e.g., 500) continues with the action (e.g., continues with the payment transaction with the payment information) without further input from the user at the authentication device (e.g., 500).

[0259] In some examples, the authentication device (e.g., 500) is a telephone (e.g., a smartphone) and the requestor is a television device (e.g., a flat panel television or a set-top box that controls the display of a user interface on a flat panel television). In some examples, the authentication device is a telephone (e.g., a smartphone) and the requestor is a computer (e.g., a laptop computer, a desktop computer). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requestor is a television device (e.g., a flat panel television or a set-top box that controls the display of a user interface on a flat panel television). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requestor is a computer (e.g., a laptop computer, a desktop computer).

[0260] In some examples, the electronic wallet of the authentication device (e.g., 500) includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on a given one of the one or more payment accounts. In some examples, the payment information is an account number or PAN of the payment account.

[0261] In some examples, continuing the payment transaction includes sending payment information (e.g., payment information for a payment account linked to the electronic device and stored in the device's electronic wallet) to a payment transaction server involved in the payment transaction. In some examples, participating in the payment transaction includes routing information to one or more financial institutions to verify payment credentials and / or receive authorization to complete the transaction. For example, the payment information is sent from an authenticator (e.g., 500) to a payment server involved in the payment transaction. In another example, the payment information is sent from a requester (e.g., 700) to a payment server involved in the payment transaction.

[0262] In some examples, continuing the payment transaction includes completing the payment transaction using payment information (e.g., payment information for a payment account linked to the electronic device and stored in an electronic wallet on the device). In some examples, continuing the payment transaction includes completing the payment transaction (e.g., using a credit account to make the purchase) using payment information (e.g., an account number or PAN for the payment account) for use in the payment transaction, where the payment information is stored on the electronic device (e.g., 500, 700).

[0263] It should be noted that the process details described above for method 900 (e.g., FIGS. 9A-9D) may also be applied to the methods described below as well. For example, methods 1000 and 1100 may optionally include one or more of the features of the methods described above with reference to method 900. For example, claimer features and techniques of the various methods may be combined. In another example, authenticator features and techniques of the various methods may be combined. For the sake of brevity, some of these details will not be repeated below.

[0264] 10A-10B are flow diagrams illustrating a method 1000 for managing remote permission to proceed with an action using an electronic device according to some embodiments. Method 1000 is performed on a requesting device (e.g., 100, 300, 700) with a display. In some examples, the requesting device (e.g., 700) does not have a hardware token generator or secure element. Some operations in method 1000 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0265] As described below, the method 1000 provides an intuitive way to manage remote permissions to proceed with an action. The method reduces the cognitive burden on the user and creates a more efficient human-machine interface. For battery-operated computing devices, the method conserves power and increases the time between battery charges by allowing the user to manage remote permissions faster and more efficiently. The method also improves transaction security by allowing the user to use an authentication device with dedicated authentication and / or secure storage hardware. The method also reduces device costs by enabling dedicated authentication and / or secure storage hardware in one device from another device used by the user.

[0266] At block 1002, the requester device receives a selection of one or more options (e.g., 708, 718, 802G, 802H, 802J) associated with the action. For example, the requester device receives a user selection of a given security token generation algorithm from among multiple token generation algorithms, receives a user selection of the length of the security token to be generated, receives a selection of one or more products / services to purchase, receives a selection of one or more shipping methods, receives a selection of a payment account, or combinations thereof. In some examples, the selected one or more options associated with the action are displayed on a display of the requester device. In some examples, the one or more options associated with the action are multiple options associated with the action.

[0267] In some examples, an action at block 1004 creates a secure network connection. A secure network is created between a requesting device (e.g., 700) and a remote server by sending (e.g., at the requesting device or authenticator) a token to the remote server. In some examples, an action creates a secure connection between an authenticator and a remote server by sending (e.g., at the requesting device or authenticator) a token to the remote server. In some examples, an authenticator (e.g., 500) generates a token and sends it to a requesting device (e.g., 700) before the requesting device (e.g., 700) sends the token to the remote server.

[0268] In some examples, at block 1006, the action continues with the payment transaction (e.g., by sending the payment information to a payment transaction server for use by the payment transaction server to process the payment transaction).

[0269] In block 1008, the requesting device receives (e.g., detects user activation of the “Confirm” affordance) a selection of an option (e.g., 722, 822) to proceed with an action (e.g., create a secure network connection, proceed with a payment transaction) associated with the selected option or options (e.g., 708, 718, 802G, 802H, 802J). In some examples, the action is based on the selected option or options.

[0270] In block 1010, the requesting device (e.g., 700) (in response to receiving a selection of an option to proceed with the action) sends a request to proceed with the action to the authenticating device (e.g., 500, a phone device having a hardware token generator, a phone device having a secure element) either directly or indirectly, such as via an intermediate device. The request includes information about (or based on) the selected option or options. The information about the selected option or options (e.g., 752, 852) is for display by the authenticating device (e.g., 500). For example, the information about the selected option or options is for display on a display of the authenticating device (e.g., 500).

[0271] In block 1012, the requesting device (e.g., 700) receives (e.g., in response to sending the request, following sending the request) a response to the request to proceed with the action from the authenticating device (e.g., 500). The response to the request to proceed with the action indicates input at the authenticating device (e.g., 500).

[0272] In block 1014, pursuant to a determination that the response to the request to proceed with the action indicates that authorization at the authentication device (e.g., 500) was successful (e.g., user authentication via the authentication device based on biometrics, fingerprint, or password), the requesting device (e.g., 700) displays an indication (e.g., 762, 862) on the display of the requesting device that authorization was successful.

[0273] In some examples, in block 1016, pursuant to a determination that the response to the request to proceed with the action indicates that authorization at the authentication device (e.g., biometric, fingerprint, password-based user authentication via the authentication device) was not successful, the requesting device (e.g., 70) displays an indication that authorization was not successful (e.g., 766, 866) on a display of the requesting device. The indication that authorization was successful (e.g., 762, 862) is distinct from the indication that authorization was not successful (e.g., 766, 866).

[0274] In some examples, the action is to create a secure network connection. A requesting device (e.g., 700) receives a token from an authenticator (e.g., 500). The requesting device (e.g., 700) continues with the action (e.g., create a secure network connection) using the token (e.g., security token) received from the authenticator (e.g., 500).

[0275] In some examples, the action is to continue a payment transaction. The requesting device (e.g., 700) receives payment information (e.g., payment account number, payment account identifier, payment card information such as account number and expiration date) from the authenticating device (e.g., 500). The requesting device (e.g., 700) continues the action (e.g., continue the payment transaction) using the payment information (e.g., payment account number, payment account identifier, payment card information such as account number and expiration date) received from the authenticating device (e.g., 500).

[0276] In some examples, continuing the payment transaction includes sending at least a portion of the payment information to a payment transaction server / retailer, which can receive the payment from a payment institution or requesting device. For example, a payment transaction server is a server configured to process payments.

[0277] In some examples, the requesting device signs in to the service using an account and the authenticator signs in to the service using an account (e.g., the requesting device and authenticator both sign in to the service using the same user account / same user credentials). Alternatively, the requesting device and authenticator each sign in to separate accounts on the same service, and the separate accounts are linked to each other (e.g., explicitly linked to each other to authorize actions).

[0278] In some examples, at block 1014, the requester (e.g., 700) receives an indication (via communications with the authenticator, via communications with a bank, a card issuer's server, a payment transaction server, or the retailer) that the action was successful (e.g., the payment was approved by the authenticator, the token was sent by the authenticator). The requester (e.g., 700) presents an indication (e.g., 762, 862) at the requester that the action was successful (e.g., by displaying an indication on a display, by playing an audio indication on a speaker, by executing a tactile output at the requester).

[0279] In some examples, at block 1016, the requester device (e.g., 700) receives an indication (via communications with the authenticator, via communications with a bank, a card issuer's server, a payment transaction server, or the retailer) that the action was not successful (e.g., the payment was rejected by the authenticator, the token was not sent by the authenticator). The requester device (e.g., 700) presents an indication (e.g., 766, 866) at the requester device (e.g., 700) that the action was not successful (e.g., by displaying an indication on a display, by playing an audio indication on a speaker, by executing a tactile output at the requester device).

[0280] In some examples, before sending a request to proceed with the action, the requesting device (e.g., 700) determines whether a set of one or more conditions is met that indicate whether the requesting device (e.g., 700) can authorize the request (e.g., a local token generator that generates token information available, a local secure element with payment account information available). Sending the request to the authenticator occurs pursuant to a determination that the set of one or more conditions is not met. Pursuant to a determination that the set of one or more conditions is not met, the requesting device does not send a request for information to the authenticator, but instead authorizes the request using the capabilities of the requesting device (e.g., using a locally available fingerprint sensor and secure element to generate a token that can be used to complete the transaction and / or obtain payment information). In some examples, if a fingerprint sensor and secure element are available on the requesting device (e.g., 700), the requesting device displays a user interface that instructs the user to provide authorization to proceed with the transaction using a locally available fingerprint sensor and secure element on the device. Alternatively, in some examples, the requesting device (e.g., 700) displays instructions to enter a passcode that, when entered, can obtain a token from a token generator or payment information from a secure element.

[0281] In some examples, a set of one or more conditions is met when hardware (e.g., a local secure element) configured to generate (or securely store or provide) payment information is available at the requesting device (e.g., 700). In some examples, pursuant to a determination that the set of one or more conditions is met, the requesting device requests payment information from the secure element of the requesting device (e.g., 700) for use in proceeding with the action.

[0282] In some examples, the request to proceed with the action includes one or more details of the payment transaction (eg, price, retailer name, shipping address, payment account identifier, URL of the payment transaction server).

[0283] In some examples, prior to sending a request to proceed with the action by the requesting device (e.g., 700) to the authenticating device (e.g., 500), the requesting device (e.g., 700) provides options (e.g., displays options) corresponding to a plurality of authentication devices, the plurality of authentication devices including a given authentication device, and the requesting device (e.g., 700) receives an input (e.g., user input on a touch-sensitive surface) selecting an option corresponding to the authentication device (e.g., 500). Sending a request to proceed with the action by the requesting device (e.g., a laptop device without a hardware token generator, a laptop device without a secure element) to the authenticating device occurs in accordance with receiving an input selecting a given authentication device from among the plurality of authentication devices. In some examples, the options corresponding to the plurality of authentication devices are displayed in a browser user interface of a web browser (e.g., a sheet, tongue, or overlay extending from a portion of the web browser such as a smart search field or a web address field). In some examples, a plurality of other options related to the transaction are also displayed simultaneously with the options corresponding to the authentication device (e.g., shipping address, shipping options).

[0284] In some examples, prior to transmitting a request to proceed with the action by the requesting device (e.g., 700) to the authenticator (e.g., 500), the requesting device (e.g., 700) selects a predefined authenticator (e.g., 500) from among the multiple authenticators based on one or more of the following: proximity of the authenticator to the requesting device, recency of use of the authenticator, user-defined preferences for the authenticator, and a prioritization scheme for the multiple authenticators. The transmitting of the request to proceed with the action by the requesting device to the authenticator is performed in accordance with the selection of the predefined authenticator from among the multiple authenticators. Thus, in some examples, the requesting device (e.g., 700) automatically selects the authenticator (e.g., 500) based on predefined criteria.

[0285] In some examples, prior to sending a request to proceed with the action by the requesting device (e.g., 700) to the authenticator, the requesting device (e.g., 700) selects a given authenticator from among the plurality of authenticators based on availability of the selected payment account (or type of payment account) on the authenticator. Sending a request to proceed with the action by the requesting device (e.g., 700) to the authenticator (e.g., 500) is performed according to a selection of a given authenticator from among the plurality of authenticators. In some examples, the requesting device receives an input selecting a payment account, and an authenticator is selected from among the plurality of authenticators based on an authenticator that is prepared to provide payment information using the selected payment account. In some examples, the requesting device receives an input selecting a card type (e.g., American Express or Visa), and an authenticator is selected from among the plurality of authenticators based on an authenticator that is prepared to provide payment information using a payment account of the selected card type. In some examples, if a selection of a first payment method is received, the requesting device sends a request to the first authenticator, and if a selection of a second payment method is received, the requesting device sends a request to the second authenticator.

[0286] In some examples, following transmission of a request to proceed with the action by the requesting device (e.g., 700) to an authenticator, the requesting device (e.g., 700) refrains from sending the request to proceed with the action to another authenticator of the multiple authenticators, e.g., the requesting device only sends the request to proceed with the action to one authenticator even when multiple authenticators are nearby and available.

[0287] In some examples, the requester device transmits a request to proceed with the action to a second authenticator device (e.g., multiple authenticators). For example, the requester device 700 transmits requests to proceed with the action to multiple authenticators simultaneously (or sequentially).

[0288] In some examples, prior to sending a request to proceed with the action, the requesting device (e.g., 700) determines whether a set of one or more conditions is met (e.g., a local secure element that generates token information is available, a local secure element with payment information is available). The set of one or more conditions is met when hardware (e.g., a local secure element) configured to generate (or provide or securely store) payment information is available at the requesting device (e.g., 700). In response to a determination that the set of one or more conditions is not met, the requesting device provides (e.g., displays) an option corresponding to a plurality of authentication devices. The plurality of authentication devices includes a given authentication device (e.g., 500). In some examples, the requesting device receives an input (e.g., a user input on a touch-sensitive surface) selecting an option corresponding to the authentication device. Sending the request to proceed with the action by the requesting device to the authentication device is in response to receiving an input selecting a given authentication device from among the plurality of authentication devices.

[0289] In some examples, following transmission of the request to proceed with the action, the requesting device (e.g., 700) receives user input that changes at least one of the selected one or more options (e.g., 708, 718, 802G, 802H, 802J) associated with the action, transmits a modified request to proceed with the action to the authenticator, and receives an acknowledgment of receipt of the modified request to proceed with the action from the authenticator (e.g., in response to transmitting the request, following transmission of the request). Displaying an indication on a display of the requesting device that authorization was successful is performed pursuant to a determination that the acknowledgment of receipt of the modified request to proceed with the action has been received.

[0290] In some examples, prior to transmitting the request to proceed with the action, the requesting device (e.g., 700) displays on a display of the requesting device the one or more selected options (e.g., 708, 718, 802G, 802H, 802J) associated with the action. Following transmission of the request to proceed with the action, the requesting device (e.g., 700) receives from the authenticating device a change to at least one of the one or more selected options associated with the action, and in response to receiving from the authenticating device a change to at least one of the one or more selected options associated with the action, updates the display in accordance with the received change to at least one of the one or more selected options associated with the action. For example, the authenticating device receives user input that changes some of the one or more options, and the authenticating device transmits information indicating the change to the requesting device.

[0291] In some examples, following sending a request to continue the action, the requesting device (e.g., 700) receives a selection of an option to cancel the action (e.g., detects user activation of a “Cancel” affordance) and, in response to receiving the selection of the option to cancel the action, sends a request to cancel the action to the authenticating device.

[0292] In some examples, the requesting device (e.g., 700) displays on the requesting device's display one or more options (e.g., 708, 718, 802G, 802H, 802J) associated with an action in the third party user interface. The requesting device (e.g., 700) displays on the requesting device's display an option (e.g., 722, 822) to proceed with the action in the first party user interface (e.g., simultaneously with the one or more options). In some examples, the third party user interface is a web page displayed on a web browser application. In some examples, the third party user interface is a user interface of a first application. In some examples, the first party user interface is a user interface of a second application that is different from the first application. In some examples, the first party user interface is a user interface of the requesting device's operating system. In some examples, the first party user interface is a user interface of a web browser that is not coded in HyperText Markup Language.

[0293] In some examples, the requesting device (eg, 700) displays on the requesting device's display an option (eg, 722, 822) to proceed with the action within the first party user interface.

[0294] In some examples, the requesting device (e.g., 700) determines whether one or more authentication devices are available for authentication (e.g., within a predetermined distance). Following a determination that one or more authentication devices are available for authentication (e.g., at least one device is available within a predetermined distance of the requesting device, at least one device is available on the same LAN as the requesting device, at least one device is available via the requesting device's personal area network), the requesting device (e.g., 700) displays an option (e.g., 722, 822) to proceed with the action on the display of the requesting device. Following a determination that one or more authentication devices are not available for authentication (e.g., no devices are available), the requesting device (e.g., 700) refrains from displaying the option to proceed with the action on the display of the requesting device.

[0295] In some examples, prior to sending a request to proceed with the action by the requesting device (e.g., 700) to the authenticating device (e.g., 500), the requesting device (e.g., 700) receives a selection of one or more options associated with a second action (e.g., a second payment transaction). The request to proceed with the action is a request to proceed with both the given action and the second action, the request further including information about (or based on) the one or more options selected in association with the second action and information about the one or more options selected in association with the second action for display by the authenticating device. For example, a user may add multiple items from a single website or multiple websites to a single shared shopping cart and then send a single request to the authenticating device for authorization to purchase the multiple items. Once the request is authorized, the different websites are notified of the different purchases and the orders are fulfilled separately.

[0296] In some examples, the requesting device (e.g., 700) receives a payment option (e.g., 802F) before receiving (e.g., by the requesting device) a selection of an option (e.g., 822) that proceeds with an action associated with the selected option or options (e.g., proceed with the payment transaction) (e.g., upon detecting user activation of a “Confirm” affordance). In response to receiving the selection of the payment option (e.g., 802F), the requesting device (e.g., 700) displays options for multiple payment accounts (e.g., 802H, 802J) associated with a corresponding authentication device. In some embodiments, a first payment account is associated with a first authentication device and a second payment account corresponds to a second authentication device that is different from the first authentication device. For example, the payment accounts are grouped according to their corresponding authentication devices or are displayed with a graphical or textual indication of the authentication device corresponding to each payment account.

[0297] In some examples, prior to receiving (e.g., by the requesting device) a selection of an option (e.g., 822) to proceed with an action associated with the selected one or more options (e.g., proceed with the payment transaction) (e.g., upon detecting user activation of the “Confirm” affordance), the requesting device (e.g., 700) receives a selection of an option (e.g., 802H) corresponding to each payment account from among the options (e.g., 802H, 802J) for the multiple payment accounts. In response to receiving the selection of the option (e.g., 802H) corresponding to each payment account, the requesting device (e.g., 700) selects each authentication account based on the selected option (e.g., 802H) corresponding to each payment account.

[0298] In some examples, prior to receiving (e.g., by the requesting device) a selection of an option (e.g., 822) to proceed with an action associated with the selected one or more options (e.g., proceed with the payment transaction) (e.g., upon detecting user activation of a “confirm” affordance), the requesting device (e.g., 700) displays options (e.g., 802H, 802J) for multiple payment accounts associated with a corresponding authentication device. In some examples, a first payment account is associated with a first authentication device and a second payment account corresponds to a second authentication device that is different from the first authentication device. For example, the payment accounts are grouped according to their corresponding authentication devices or displayed with a graphical or textual indication of the authentication device corresponding to each payment account. The requesting device (e.g., 700) receives a selection of an option (e.g., 802H) corresponding to each payment account. In response to receiving a selection of an option corresponding to each payment account, the requesting device (e.g., 700) selects each authentication device based on the option (e.g., 802H) selected corresponding to each payment account. In some embodiments, a payment account associated with the first authentication device is initially selected as the default payment account, and in response to receiving a selection of an option corresponding to a second payment account, a second device is selected in place of the first device as each authentication device. In some embodiments, there are more than two devices selectable as each authentication device.

[0299] In some examples, following receipt of a selection of an option (e.g., 802H) corresponding to each payment account, an option (e.g., 822) to proceed with an action associated with the selected option or options (e.g., with a “Confirm” affordance) (e.g., proceed with the payment transaction) and an indication of an authentication device (e.g., 802I) are simultaneously displayed.

[0300] In some examples, the indication of the authentication device (e.g., 802I) includes a graphical representation of the authentication device. In some examples, the graphical representation of the authentication device is an iconic representation of the authentication device, such as a line drawing of a housing for the device, where the iconic representation includes one or more of the finish, form factor, and one or more dimensional information of the authentication device. For example, the graphical representation may indicate that the requesting device (e.g., 700) is a Gold MacBook® or a 27” iMac®.

[0301] In some examples, the multiple payment account options include payment accounts linked to a first type of device regardless of whether the first type of device is currently locked or unlocked (e.g., if a wearable device, such as a smartwatch, associated with the payment account is near the requesting device but the smartwatch is not worn and / or locked, the payment account associated with the smartwatch is excluded from the list of payment accounts available for use by the requesting device, and if the smartwatch is worn and unlocked, the payment account associated with the smartwatch is included in the list of payment accounts). The multiple payment account options include payment accounts linked to a second type of device (e.g., a smartwatch device) based on being unlocked (and alternatively or additionally based on the second type of device currently being on the user's wrist). In some examples, the multiple payment account options do not include payment accounts linked to a second type of device that is locked. In some examples, the multiple payment account options do not include payment accounts linked to a second type of device that is locked or is not currently on the user's wrist). For example, if a portable device, such as a tablet, laptop or smartphone, associated with a payment account is near the requesting device, the payment account associated with the portable device will be included in the list of payment accounts whether the portable device is locked or unlocked.

[0302] In some examples, the authentication device (e.g., 500) is a telephone and the requesting device (e.g., 700) is a television device (e.g., a flat panel television or a set-top box that controls the display of a user interface on a flat panel television). In some examples, the authentication device is a telephone and the requesting device is a computer (e.g., a laptop computer, a desktop computer). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requesting device is a television device (e.g., a flat panel television or a set-top box that controls the display of a user interface on a flat panel television). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requesting device is a computer (e.g., a laptop computer, a desktop computer).

[0303] In some examples, the electronic wallet of the authentication device (e.g., 500) includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on a given one of the one or more payment accounts. In some examples, the payment information is an account number or PAN of the payment account.

[0304] In some examples, continuing the payment transaction includes transmitting the payment information to a payment transaction server involved in the payment transaction. In some examples, participating in the payment transaction includes routing information to one or more financial institutions to verify payment credentials and / or receive authorization to complete the transaction. For example, the payment information is transmitted from an authenticator to a payment server involved in the payment transaction. In another example, the payment information is transmitted from a requester to a payment server involved in the payment transaction.

[0305] In some examples, continuing the payment transaction includes completing the payment transaction using payment information (e.g., payment information for a payment account linked to the electronic device and stored in an electronic wallet on the device). In some examples, continuing the payment transaction includes completing the payment transaction using payment information (e.g., a primary account number) used in the payment transaction (e.g., using a credit account to make the purchase), the payment information stored on the electronic device.

[0306] It should be noted that the process details described above for method 1000 (e.g., FIGS. 10A-10B) may be equally applicable to the methods described above and below. For example, methods 900 and 1100 may optionally include one or more features of the various methods described above with reference to method 1000. For example, claimer features and techniques of the various methods may be combined. In another example, authenticator features and techniques of the various methods may be combined. For the sake of brevity, some of these details will not be repeated hereinafter.

[0307] 11 is a flow diagram illustrating a method 1100 using an electronic device according to some embodiments. Method 1100 is performed in an authentication device (e.g., 100, 300, 500) with a display. In some examples, the authentication device (e.g., 500) includes hardware (e.g., a secure element, a token generator) configured to respond to input (e.g., by generating or providing payment information) corresponding to a request for permission to proceed with an action. Some operations in method 1100 are optionally combined, the order of some operations is optionally changed, and some operations are optionally omitted.

[0308] As described below, the method 1100 provides an intuitive way to manage remote permissions to proceed with an action, which reduces the cognitive burden on a user to manage remote permissions and creates a more efficient human-machine interface. For battery-operated computing devices, it conserves power and increases the time between battery charges by allowing a user to manage remote permissions faster and more efficiently.

[0309] In block 1102, the authenticator (e.g., 500) receives a request to proceed with the action from the requester (e.g., 700). The request includes information about the action (e.g., information about or based on one or more options selected by a user on the requester, the name of a remote server to contact, transaction details such as a total amount, or an indication of a payment account). The requester (e.g., 700) and authenticator (e.g., 500) are both signed into the service using the same account (or are each signed into separate accounts that are explicitly linked to each other to authorize the action). In some examples, in block 1104, the action creates a secure network connection. In some examples, in block 1106, the action proceeds with the payment transaction.

[0310] In block 1108, the authenticator device (e.g., 500) simultaneously displays on the authenticator device's display an indication (e.g., 750, 850) of a request to proceed with the action, information (e.g., 752, 852) about the action (e.g., name of the remote server to contact, transaction details such as total amount or indication of payment account), and an indication of the requesting device (e.g., 754, 854) (e.g., name of the requesting laptop or phone, identifier of the requesting device).

[0311] At block 1110, the authentication device (eg, 500) displays a request (eg, 856) for permission to proceed with the action.

[0312] In block 1112, the authentication device (e.g., 500) receives input (e.g., user credentials, fingerprint, passcode) corresponding to a request for permission to proceed with the action. In some examples, receiving permission to proceed with the action includes receiving a passcode via a touch-sensitive surface of the electronic device and determining that the passcode matches a registered passcode that allows the action to be permitted. In some examples, allowing to proceed includes detecting a fingerprint and determining that the fingerprint matches a registered fingerprint that allows the action to be permitted. For example, the device stores information about one or more fingerprints of the user and uses each fingerprint to determine whether the action is permitted. In some examples, allowing to proceed includes receiving a double press of a mechanical button while the device (e.g., an electronic smartwatch) is in an unlocked state (and optionally while the device is on the user's wrist, such as by detecting that the device is in contact with the user's skin).

[0313] In some examples, the action creates a secure network connection between the requesting device and the remote server. In response to a determination in the authenticator (e.g., 500) that an input corresponding to the request for permission to proceed with the action matches an input authorized for the action to proceed (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) transmits token information to the requesting device. In some examples, the requesting device (e.g., 700) receives token information from the authenticator, and the requesting device (e.g., 700) continues the action (e.g., creates a secure network connection) using the token information received from the authenticator. In some examples, in response to a determination in the authenticator (e.g., 500) that an input corresponding to the request for permission to proceed with the action does not match an input authorized for the action to proceed (e.g., unsuccessful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) refrains from transmitting token information to the requesting device.

[0314] In some examples, the simultaneous display on the display of an indication of a request to proceed with the action (e.g., 750, 850), information about the action (e.g., 752, 852), and an indication of the requesting device (e.g., 754, 854) is responsive to (or subsequent to) the request to proceed with the action.

[0315] In some examples, the authentication device includes hardware (e.g., a hardware token generator, a secure element) configured to respond to input responsive to an authentication request that proceeds with an action (e.g., by generating or providing a token, by generating or providing payment information), for example, if the requesting device (e.g., 700) does not include the hardware (e.g., a hardware token generator, a secure element).

[0316] In some examples, the action is proceeded with a payment transaction. The authenticator (e.g., 500) generates (or provides, or releases) payment information (e.g., a payment account number, an identifier for the payment account, or payment card information such as an account number and expiration date for a payment account linked to the device and stored in the device's electronic wallet). For example, the authenticator (e.g., 500) uses hardware (e.g., a secure element) configured to respond (by generating or providing payment information) to an input responsive to an authentication request to proceed with the action. In response to determining in the authenticator (e.g., 500) that an input responsive to an authentication request to proceed with the action matches an input that was authenticated to proceed with the action (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) transmits the payment information (e.g., to a requester or a payment transaction server). In some examples, the requester receives the payment information from the authenticator, and the requester proceeds with the action (e.g., proceeds with a payment transaction) using the payment information received from the authenticator. In some examples, the payment transaction server receives payment information from the authenticator and processes the payment transaction using the payment information received from the authenticator. In response to determining at the authenticator (e.g., 500) that an input in response to an authentication request to proceed with an action does not match an input that was authorized to proceed with the action (e.g., unsuccessful user authentication based on user input, user credentials, fingerprint, passcode), the authenticator (e.g., 500) cancels transmission of the payment information (e.g., to the requesting device or the payment transaction server).

[0317] In some examples, the indication of the requesting device (e.g., 754, 854) includes a graphical representation of the requesting device. In some examples, the graphical representation of the requesting device is an iconic representation of the requesting device, such as a line drawing of a housing for the device, where the iconic representation includes one or more of a finish, a form factor, and one or more dimensional information of the requesting device. For example, the graphical representation may indicate that the requesting device (e.g., 700) is a Gold MacBook® or a 27” iMac®.

[0318] In some examples, the authentication device (e.g., 500) is in a locked state upon receiving an input (e.g., user credentials, fingerprint, passcode) in response to an authentication request to proceed with an action. In response to determining in the authentication device that the input in response to the authentication request to proceed with an action matches an input that is authenticated to proceed with the action (e.g., successful user authentication based on the user input, user credentials, fingerprint, passcode), the authentication device (e.g., 500) transmits a response to the request to proceed with the action, a response to the request to proceed with the action based on the input, by the authentication device while maintaining the authentication device in a locked state. Thus, in some examples, the authentication device (e.g., 500) remains in a locked state throughout the authentication process.

[0319] In some examples, the requesting device (e.g., 700) is signed into the service using an account and the authenticating device (e.g., 500) is signed into the service using an account (e.g., both the requesting device and authenticating device are signed into the service using the same user account / same user credentials). In some examples, the requesting device and authenticating device are each signed into separate accounts on the same service, and the separate accounts are linked to each other (e.g., explicitly linked to each other for purposes of authorizing actions).

[0320] In some examples, the authentication device (e.g., 500) is in a locked state upon receiving a request to proceed with the action. In response to receiving the request to proceed with the action, the authentication device displays a request notification on a display (e.g., 730, 830, on the lock screen of the authentication device). Before simultaneously displaying an indication of the request to proceed with the action (e.g., 750, 850), information about the action (e.g., 752, 852), and an indication of the request device (e.g., 754, 854) on the display, the authentication device (e.g., 500) receives an input that activates the request notification (e.g., 730, 830) (e.g., a user swipe gesture that slides the notification beyond a threshold distance or a user input gesture that presses the notification with a characteristic intensity above a respective threshold intensity), requests authentication to unlock the authentication device (e.g., 740, 840, by displaying a request and / or by causing a haptic vibration), and receives authentication to unlock the authentication device (e.g., a fingerprint or passcode). This authentication to unlock the authentication device is separate from and in addition to the authentication to proceed with the action. In some examples, the authentication to unlock and the authentication to proceed with the action can be satisfied using the same technique (e.g., using the same fingerprint or the same password). In some examples, the authentication to unlock and the authentication to proceed with the action are satisfied using different techniques (e.g., using a fingerprint for the authentication to unlock and a password for the authentication to proceed with the action). In some examples, the authentication to unlock and the authentication to proceed with the action are satisfied using the same technique but with different inputs (e.g., using a first fingerprint for the authentication to unlock and a second fingerprint for the authentication to proceed with the action, or using a first password for the authentication to unlock and a second password for the authentication to proceed with the action). In response to (or subsequent to) receiving an authentication to unlock the authentication device, the authentication device (e.g., 500) unlocks (e.g., transitions the device to an unlocked state).Concurrently displaying on the display an indication of the request to proceed with the action, information about the action, and an indication of the requesting device occurs in response to receiving authentication to unlock the authentication device. In some examples, the indication of the request to proceed with the action, information about the action, and an indication of the requesting device are displayed within a user interface of the electronic wallet application. In some examples, the electronic wallet application stores multiple payment accounts associated with a user of the authentication device as the user's personal device.

[0321] In some examples, in response to receiving a request to proceed with the action, the authentication device (e.g., 500) displays a request notification on a display (e.g., 730, 830, on a lock screen of the authentication device). Prior to simultaneously displaying an indication of the request for the action, information about the action, and an indication of the requesting device on the display, the authentication device (e.g., 500) receives an input that activates the request notification (e.g., a user swipe gesture that slides the notification beyond a threshold distance or a user input gesture that presses the notification with a characteristic intensity equal to or greater than a respective threshold intensity). The simultaneously displaying an indication of the request to proceed with the action, information about the action, and an indication of the requesting device on the display is in response to (or subsequent to) receiving the input that activates the request notification. In some examples, the indication of the request to proceed with the action, information about the action, and an indication of the requesting device are displayed within a user interface of an electronic wallet application. In some examples, the electronic wallet application stores multiple payment accounts associated with a user of the authentication device as the user's personal device.

[0322] In some examples, the authentication device (e.g., 500) is in a locked state upon receiving a request to proceed with the action. In response to receiving the request to proceed with the action, the authentication device (e.g., 500) displays a request notification on the display (e.g., 730, 830, on the authentication device's lock screen). Prior to simultaneously displaying the indication of the request for the action, information about the action, and an indication of the requesting device on the display, the authentication device (e.g., 500) receives an input that activates the request notification (e.g., a user swipe gesture that slides the notification beyond a threshold distance or a user input gesture that presses the notification with a characteristic intensity equal to or greater than the respective threshold intensity). The simultaneously displaying the indication of the request to proceed with the action, information about the action, and an indication of the requesting device on the display is in response to (or subsequent to) receiving the input that activates the request notification. In some examples, the indication of the request to proceed with the action, information about the action, and an indication of the requesting device are displayed within a user interface of an electronic wallet application. In some examples, the electronic wallet application stores multiple payment accounts associated with a user of the authentication device as the user's personal device. If it is determined that the input in response to an authentication request to proceed with an action matches input that has been authenticated to proceed with the action (e.g., user authentication information, a fingerprint, a passcode), the requesting device is not transitioned to an unlocked state (or, in other words, is not transitioned from a locked state).

[0323] In some examples, upon receiving the request to proceed with the action, the authentication device (e.g., 500) is in an unlocked state (e.g., a state in which the user has already provided authentication, allowing access to restricted features of the authentication device). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) that, once unlocked, remains in an unlocked state and automatically locks when the device detects that it is being worn and is no longer being worn (e.g., by detecting an end of user contact by one or more sensors of the device or by detecting an end of proximity to the user by one or more sensors of the device). The requesting device includes a hardware button, and receiving an input that is a response to the authentication request to proceed with the action includes detecting a double press of the hardware button while the device is in the unlocked state.

[0324] In some examples, the information about the action includes one or more options associated with the action. The authenticator (e.g., 500) simultaneously displays on a display an indication of a request for the action, information about the action, and an indication of a requesting device, then receives user input requesting a change to at least one of the one or more options associated with the action, sends an updated request to the requesting device including the change to at least one of the one or more options associated with the action, displays an indication on the display that confirmation of receipt of the updated request has not been received from the requesting device, receives confirmation of receipt of the updated request from the requesting device, and in response to receiving confirmation of receipt of the updated request from the requesting device, ceases displaying the indication that confirmation of receipt of the updated request has not been received from the requesting device.

[0325] In some examples, after receiving a request to proceed with the action and before receiving input (e.g., user credentials, fingerprint, passcode) that is a response to the authentication request to proceed with the action, the authentication device (e.g., 500) receives a request to cancel the action from the requesting device, and in response to receiving the request to cancel the action and receiving input (e.g., user credentials, fingerprint, passcode) that is a response to the authentication request to proceed with the action, the authentication device (e.g., 500) cancels the action from proceeding with the action (e.g., cancels sending payment information).

[0326] In some examples, after receiving a request to proceed with the action and before receiving input (e.g., user credentials, fingerprint, passcode) that is a response to the authentication request that proceeds with the action, the authentication device (e.g., 500) receives a request to cancel the action from the requesting device (e.g., 700), and in response to receiving the request to cancel the action, the authentication device ceases to receive input (e.g., user credentials, fingerprint, passcode) that is a response to the authentication request that proceeds with the action. For example, the authentication device (e.g., 500) disables a fingerprint sensor used to receive input that is a response to the authentication request.

[0327] In some examples, after determining at an authentication device (e.g., 500) that an input responsive to an authentication request to proceed with an action matches an input that is authenticated to proceed with the action (e.g., successful user authentication based on user input, user credentials, fingerprint, passcode), the authentication device proceeds with the action (e.g., using payment information) without further input (e.g., from either the requesting device or the user). For example, the authentication device transmits information necessary (or useful) to process a payment transaction to a payment server.

[0328] In some examples, the authentication device (e.g., 500) displays the transactions in a transaction history user interface. The authentication device (e.g., 500) receives a second request to proceed with a second action (e.g., requesting to proceed with a second payment transaction). The authentication device (e.g., 500) simultaneously displays on the display a second indication of the request to proceed with the action (e.g., proceed with the payment transaction) and an indication of whether the action was successful (e.g., the payment transaction was approved), and simultaneously displays on the display a third indication of the second request to proceed with the second action (e.g., proceed with the second payment transaction) and an indication of whether the second action was successful (e.g., the second payment transaction was approved). Thus, the authentication device (e.g., 500) displays a transaction history including the received request along with an indication of whether the corresponding transaction payment was approved or rejected. In some examples, the authentication device (e.g., 500) simultaneously displays a second indication of a request to proceed with the action, an indication of whether the action was successful, a third indication of a second request to proceed with the second action, and an indication of whether the second action was successful.

[0329] In some examples, the authentication device (e.g., 500) is a telephone (e.g., a smartphone) and the requesting device is a television device (e.g., a flat panel television or a set-top box controlling the display of a user interface on the flat panel television). In some examples, the authentication device is a telephone (e.g., a smartphone) and the requesting device is a computer (e.g., a laptop computer, a desktop computer). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requesting device is a television device (e.g., a flat panel television or a set-top box controlling the display of a user interface on the flat panel television). In some examples, the authentication device is a wearable device (e.g., an electronic smart watch) and the requesting device is a computer (e.g., a laptop computer, a desktop computer).

[0330] In some examples, the electronic wallet of the authentication device (e.g., 500) includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on a payment account of the one or more payment accounts. In some examples, the payment information is an account number or a PAN of the payment account.

[0331] In some examples, proceeding with the payment transaction includes sending payment information (e.g., payment information for a payment account linked to the electronic device and stored in the device's electronic wallet) to a payment transaction server participating in the payment transaction. In some examples, participating in the payment transaction includes routing information to one or more financial institutions to verify payment credentials and / or receive authorization to complete the transaction. For example, the payment information is sent from an authenticating device (e.g., 500) to a payment server for participating in the payment transaction. In another example, the payment information is sent from a requesting device (e.g., 700) to a payment server for participating in the payment transaction.

[0332] In some examples, proceeding with the payment transaction includes completing the payment transaction using payment information (e.g., payment information for a payment account linked to the electronic device and stored in an electronic wallet on the device). In some examples, proceeding with the payment transaction includes completing the payment transaction using payment information (e.g., an account number or PAN for a payment account) for use in the payment transaction (e.g., making a purchase using a credit account), where the payment information is stored on the electronic device (e.g., 500, 700).

[0333] It should be noted that the process details described above with respect to method 1100 (e.g., FIG. 11) are also applicable to the methods described above as well. For example, methods 900 and 1000 optionally include one or more of the features of the various methods described above with respect to method 1100. For example, the requester features and techniques of the various methods may be combined. As another example, the authenticator features and techniques of the various methods may be combined. For the sake of brevity, these details are not repeated below.

[0334] According to some embodiments, FIG. 12 illustrates an example functional block diagram of a requesting device 1200 configured according to the principles of various described embodiments. According to some embodiments, the functional blocks of the requesting device 1200 are configured to execute the techniques described above. The functional blocks of the device 1200 are optionally implemented by hardware, software, or a combination of hardware and software to execute the principles of the various described examples. Those skilled in the art will understand that the functional blocks described in FIG. 12 are optionally combined or separated into sub-blocks to implement the principles of the various described examples. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0335] 12 , the requesting device 1200 includes a display unit 1202 configured to display a graphical user interface, and a processing unit 1204 connected to the display unit 1202. In some embodiments, the processing unit 1204 includes a receiving unit 1206, a sending unit 1208, a display enabling unit 1210, a network forming unit 1212, a proceeding unit 1216, and a determining unit 1218.

[0336] The processing unit 1204 is configured to receive (e.g., via the receiving unit 1206) a selection of one or more options. The processing unit 1204 is further configured to receive (e.g., via the receiving unit 1206) a selection of an option to proceed with an action associated with the selected one or more options. The processing unit 1204 is further configured to send (e.g., via the sending unit 1208) a request to proceed with the action, the request including information regarding the selected one or more options. The processing unit 1204 is further configured to receive (e.g., via the receiving unit 1206) a response to the request to proceed with the action. The processing unit 1204 is further configured to display enable (by the display enable unit 1210) an indication of successful authentication on the display unit 1202 in response to determining (e.g., using the determining unit 1218) that the response to the request to proceed with the action is successful authentication at the authentication device. The processing unit 1204 is further configured to display enable (by the display enablement unit 1210) on the display unit 1202 an indication that the authentication was not successful in response to a determination (e.g., using the determination unit 1218) that the response to the request to proceed with the action is that the authentication at the authentication device was not successful.

[0337] In some embodiments, the action is forming a secure network connection between the requesting device 1200 and a remote server (e.g., using the network forming unit 1212). The processing unit 1204 is further configured to receive (e.g., by the receiving unit 1206) a token from the authenticator. The processing unit 1204 is further configured to proceed with the action using the token received from the authenticator (e.g., by the proceeding unit 1216).

[0338] In some embodiments, the requesting device 1200 is signed into the service using an account when sending a request to proceed with an action (eg, using the sending unit 1208).

[0339] In some embodiments, the action is progressed by a payment transaction (e.g., using the progressing unit 1216). The processing unit 1204 is further configured to receive (e.g., via the receiving unit 1206) payment information from the authentication device. The processing unit 1204 is further configured to progress the action using the payment information received from the authentication device (e.g., using the progressing unit 1216).

[0340] In some embodiments, the processing unit 1204 is configured to transmit the token (eg, via the transmitting unit 1208) to a server, where the server uses the token to obtain a resource associated with the token.

[0341] In some embodiments, the processing unit 1204 is further configured to transmit (e.g., by the sending unit 1208) the payment information to a payment transaction server, which uses the payment information to obtain resources associated with the payment information.

[0342] In some embodiments, the requesting device 1200 is a television device. In some embodiments, the requesting device 1200 is a computer.

[0343] In some embodiments, proceeding with the payment transaction includes transmitting (eg, by the transmitting unit 1208) payment information to a payment transaction server for participation in the payment transaction.

[0344] The operations described above with reference to Figures 9A-9D are optionally implemented by the components shown in Figures 1A-1B or 12. For example, receive operation 902 and display operation 910 are optionally implemented by event recognizer 180 and event handler 190. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0345] According to some embodiments, FIG. 13 illustrates an exemplary functional block diagram of an authentication device 1300 configured according to the principles of various described embodiments. According to some embodiments, the functional blocks of the authentication device 1300 are configured to execute the techniques described above. The functional blocks of the device 1300 are optionally implemented by hardware, software, or a combination of hardware and software to execute the principles of the various described examples. Those skilled in the art will understand that the functional blocks described in FIG. 13 are optionally combined or separated into sub-blocks to implement the principles of the various described examples. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0346] 13 , the authentication device 1300 includes a display unit 1302 configured to display a graphic user interface, a hardware unit 1318, and a processing unit 1304 connected to the display unit 1302, and optionally the hardware unit 1318. In some embodiments, the processing unit 1304 includes a receiving unit 1306, a sending unit 1308, a display enabling unit 1310, a network forming unit 1312, a proceeding unit 1316, a determining unit 1320, and a locking unit 1322.

[0347] The processing unit 1304 is configured to receive (e.g., via the receiving unit 1306) a request to proceed with the action. The processing unit 1304 is further configured to simultaneously display-enable (e.g., using the display-enable unit 1310) an indication of the request to proceed with the action, information regarding the one or more selected options, and an indication of the requesting device on the display unit 1302. The processing unit 1304 is further configured to display-enable (e.g., using the display-enable unit 1310) an authentication request to proceed with the action on the display unit 1302. The processing unit 1304 is further configured to receive (e.g., using the receiving unit 1306) an input that is a response to the authentication request to proceed with the action. The processing unit 1304 is further configured to transmit (e.g., using the transmitting unit 1308) a response to the request to proceed with the action, the response to the request to proceed with the action being based on the input that is a response to the request for the authentication request to proceed with the action.

[0348] In some embodiments, the authenticator 1300 includes a hardware unit 1318 configured to respond to the input in response to the authentication request to proceed with the action, and the requester does not include the hardware. The action is forming a secure network connection between the authenticator 1300 and the remote server (e.g., using the network forming unit 1312). The processing unit 1304 is configured to proceed with the action (e.g., using the proceeding unit 1316) using the hardware unit 1318 configured to respond to the input in response to the authentication request to proceed with the action in response to determining (e.g., using the determining unit 1320) that the input in response to the authentication request to proceed with the action matches the input authenticated to proceed with the action.

[0349] In some embodiments, the action is forming a secure network connection between the requesting device and the remote server (e.g., using the network forming unit 1312). In response to determining (e.g., using the determining unit 1320) that the input in response to the authentication request to proceed with the action matches the input authenticated to proceed with the action, the processing unit 1304 transmits (e.g., using the transmitting unit 1308) to the requesting device the token that was generated using the hardware unit configured to respond to the input in response to the authentication request to proceed with the action 1318.

[0350] In some embodiments, the indication of the requesting device includes a graphical representation of the requesting device.

[0351] In some embodiments, the authenticator 1300 is in the locked state upon receiving (e.g., using the receiving unit 1306) an input that is a response to an authentication request to proceed with an action. The processing unit 1304 is configured to maintain the authenticator 1300 in the locked state (e.g., using the locking unit 1322) and to transmit (e.g., using the transmitting unit 1308) a response to the request to proceed with the action that is based on the input, in response to determining (e.g., using the determining unit 1320) that the input that is a response to the authentication request to proceed with the action matches an input that is authenticated to proceed with the action.

[0352] In some embodiments, the authenticator 1300 is signed into the service using an account when it receives a request to proceed with an action.

[0353] In some embodiments, the action is being progressed by a payment transaction (e.g., using the progressing unit 1316). The processing unit 1304 is configured to progress the action (e.g., using the progressing unit 1316) using a hardware unit 1318 configured to respond to the input in response to the authentication request to proceed with the action, in response to determining (e.g., using the determining unit 1320) that the input in response to the authentication request to proceed with the action matches an input authenticated for proceeding with the action.

[0354] In some embodiments, the action is progressed by a payment transaction (e.g., using the proceeding unit 1316). In response to determining (e.g., using the determining unit 1320) that the input in response to the authentication request to proceed with the action matches the input authenticated to proceed with the action, the processing unit 1304 transmits (e.g., using the transmitting unit 1308) to the requesting device the payment information generated using the hardware unit configured to respond to the input in response to the authentication request to proceed with the action 1318.

[0355] In some embodiments, the processing unit 1304 is configured to transmit the token (e.g., using the transmitting unit 1308) to a server, where the server uses the token to obtain a resource associated with the token.

[0356] In some embodiments, the processing unit 1304 is configured to send the payment information to a payment transaction server (e.g., using the sending unit 1308), where the payment transaction server uses the payment information to obtain a resource associated with the payment information.

[0357] In some embodiments, the action is proceeding with a payment transaction and the authentication device 1300 includes a hardware unit 1318 for authenticating the payment transaction.

[0358] In some embodiments, the action is progressed by a payment transaction (e.g., using the progressing unit 1316). After the processing unit 1304 determines (e.g., using the determining unit 1320) that the input in response to the authentication request to proceed with the action matches the authenticated input for proceeding with the action, the processing unit 1304 proceeds with the action without further input from the requesting device (e.g., using the progressing unit 1316).

[0359] In some embodiments, the authentication device 1300 is a phone. In some embodiments, the authentication device 1300 is a wearable device.

[0360] In some embodiments, the electronic wallet of the authentication device 1300 includes one or more payment accounts associated with a user of the authentication device 1300, and the payment information is based on a payment account of the one or more payment accounts.

[0361] In some embodiments, progressing the payment transaction (e.g., using the progressing unit 1316) includes transmitting payment information to a payment transaction server for participation in the payment transaction (e.g., using the sending unit 1308).

[0362] The operations described above with reference to Figures 9A-9D are optionally implemented by the components shown in Figures 1A-1B or 13. For example, receive operation 908 and display operation 912 are optionally implemented by event recognizer 180 and event handler 190. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0363] According to some embodiments, FIG. 14 illustrates an example functional block diagram of a requesting device 1400 configured according to the principles of various described embodiments. According to some embodiments, the functional blocks of the requesting device 1400 are configured to execute the techniques described above. The functional blocks of the device 1400 are optionally implemented by hardware, software, or a combination of hardware and software to implement the principles of the various described examples. Those skilled in the art will understand that the functional blocks described in FIG. 14 are optionally combined or separated into sub-blocks to implement the principles of the various described examples. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0364] 14 , the requesting device 1400 includes a display unit 1402 configured to display a graphical user interface, and a processing unit 1404 connected to the display unit 1402. In some embodiments, the processing unit 1404 includes a receiving unit 1406, a sending unit 1408, a display enabling unit 1410, a network forming unit 1412, a proceeding unit 1416, a determining unit 1420, a providing unit 1422, and a selecting unit 1424.

[0365] The processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) a selection of one or more options associated with the action. The processing unit 1404 is further configured to receive (e.g., using the receiving unit 1406) a selection of an option to proceed with an action associated with the selected one or more options. The processing unit 1404 is further configured to send (e.g., using the sending unit 1408) a request to proceed with the action to the authentication device, the request including information about the selected one or more options, the information about the selected one or more options for display by the authentication device. The processing unit 1404 is further configured to receive (e.g., using the receiving unit 1406) a response to the request to proceed with the action from the authentication device, the response to the request to proceed with the action indicating an input at the authentication device. The processing unit 1404 is further configured to display enable (using the display enable unit 1410) an indication of successful authentication on the display unit 1402 in response to a determination (e.g., using the determining unit 1420) that the response to the request to proceed with the action indicates successful authentication at the authentication device.

[0366] In some embodiments, the processing unit 1404 is further configured to display enable (by the display enable unit 1410) on the display unit 1402 an indication that the authentication was not successful in response to a determination (e.g., using the determination unit 1420) that the response to the request to proceed with the action is that the authentication at the authentication device was not successful.

[0367] In some embodiments, the action is forming a secure network connection between the requesting device and the remote server (e.g., using the network forming unit 1412) by sending the token to the remote server (e.g., using the sending unit 1408).

[0368] In some embodiments, the processing unit 1404 is configured to receive a token from the authentication device (e.g., using the receiving unit 1406). The processing unit 1404 is further configured to proceed with an action using the token received from the authentication device (e.g., using the proceeding unit 1416).

[0369] In some embodiments, the action is progressed by a payment transaction (eg, using the progress unit 1416).

[0370] In some embodiments, the processing unit 1404 is configured to receive payment information from the authentication device (e.g., using the receiving unit 1406). The processing unit 1404 is further configured to proceed with an action using the payment information received from the authentication device (e.g., using the proceeding unit 1416).

[0371] In some embodiments, proceeding with the payment transaction includes transmitting at least a portion of the payment information to the merchant (eg, using the transmitting unit 1408).

[0372] In some embodiments, the requesting device 1400 is signed in to the service using an account and the authenticating device is signed in to the service using an account.

[0373] In some embodiments, the processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) an indication that the action was successful. The processing unit 1404 is further configured to present (e.g., using the presenting unit 1418) an indication that the action was successful to the requesting device.

[0374] In some embodiments, the processing unit 1404 is configured to determine (e.g., using the determining unit 1420) whether a set of one or more conditions indicating whether the device is able to authenticate the request is met before sending the request to proceed with the action, and sending the request to the authentication device occurs following a determination that the set of one or more conditions is not met.

[0375] In some embodiments, a set of one or more conditions is met if hardware configured to generate payment information is available at the requester device.

[0376] In some embodiments, the request to proceed with the action includes details of one or more payment transactions.

[0377] In some embodiments, the processing unit 1404 is configured to provide (e.g., using the providing unit 1422) options corresponding to a plurality of authentication devices including the authentication device before sending a request to proceed with the action to the authentication device, and to receive (e.g., using the receiving unit 1406) an input selecting an option corresponding to the authentication device, and sending the request to proceed with the action to the authentication device is in response to receiving the input selecting the authentication device from among the plurality of authentication devices.

[0378] In some embodiments, before sending the request to proceed with the action to the authentication device, the processing unit 1404 is configured to select an authentication device from among the multiple authentication devices based on any one or more of the proximity of the authentication device to the requesting device 1400, the recency of usage of the authentication device, user-defined preferences for the authentication device, and a prioritization scheme for the multiple authentication devices (e.g., using the selection unit 1424), and sending the request to proceed with the action to the authentication device (e.g., using the sending unit 1408) is responsive to selecting the authentication device from among the multiple authentication devices.

[0379] In some embodiments, the processing unit 1404 is configured to select an authentication device from among the multiple authentication devices based on availability of the selected payment account at the authentication device (e.g., using the selection unit 1424) before sending a request to proceed with an action by the requesting device 1400 to the authentication device, and the sending of the request to proceed with an action by the requesting device 1400 to the authentication device is responsive to selecting the authentication device from among the multiple authentication devices.

[0380] In some embodiments, the processing unit 1404 is configured to, in response to the requesting device 1400 sending (e.g., using the transmitting unit 1408) a request to proceed with the action to an authenticating device, refrain from sending (e.g., using the transmitting device 1408) a request to proceed with the action to another authenticating device of the plurality of authenticating devices.

[0381] In some embodiments, the processing unit 1404 is configured to send, by the requesting device 1400, a request to proceed with the action to the second authenticator device (eg, using the sending unit 1408).

[0382] In some embodiments, the processing unit 1404 is configured to determine (e.g., using the determining unit 1420) whether a set of one or more conditions is met before sending the request to proceed with the action, the set of one or more conditions being met if hardware configured to generate payment information is available in the requesting device 1400, and to provide (e.g., using the providing unit 1422) an option corresponding to multiple authentication devices according to a determination that the set of one or more conditions is not met, the multiple authentication devices including the authentication device.

[0383] In some embodiments, the processing unit 1404 is configured to receive user input (e.g., using the receiving unit 1406) that changes at least one of the selected one or more options associated with the action after sending a request to proceed with the action (e.g., using the transmitting unit 1408), send by the requesting device 1400 a modified request to proceed with the action to the authenticating device (e.g., using the transmitting unit 1408), receive a confirmation of receipt of the modified request to proceed with the action from the authenticating device (e.g., using the receiving unit 1406), and display enabling (e.g., using the display enabling unit 1410) an indication of successful authentication on the display unit 1402 of the requesting device 1400 following a determination (e.g., using the determining unit 1420) that the confirmation of receipt of the modified request to proceed with the action has been received.

[0384] In some embodiments, the processing unit 1404 is configured to, prior to sending the request to proceed with the action, display-enable (e.g., using the display enablement unit) the one or more selected options associated with the action on the display unit 1402. After sending the request to proceed with the action, the processing unit 1404 is further configured to receive (e.g., using the receiving unit 1406) a change to at least one of the selected options associated with the action from the authentication device, and in response to receiving from the authentication device the change to at least one of the selected options associated with the action, update the display according to the received (e.g., using the display enablement unit) change to at least one of the selected options associated with the action.

[0385] In some embodiments, the processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) a selection of an option to cancel the action after sending a request to proceed with the action, and to send, by the requesting device 1400, a request to cancel the action to the authenticating device (e.g., using the sending unit 1408) in response to receiving the selection of the option to cancel the action.

[0386] In some embodiments, the processing unit 1404 is configured to display enable (e.g., using the display enablement unit 1410) one or more options associated with the action in the third party's user interface on the display unit 1402, and to display enable (e.g., using the display enablement unit 1410) an option to proceed with the action in the first party's user interface on the display unit 1402 of the requesting device.

[0387] In some embodiments, the processing unit 1404 is configured to display and enable (e.g., using the display enablement unit 1410) an option to proceed with the action in the first party's user interface on the display unit 1402 of the requesting device 1400.

[0388] In some embodiments, the processing unit 1404 is configured to determine (e.g., using the determining unit 1420) whether one or more authentication devices are available for authentication. The processing unit 1404 is further configured to, in accordance with a determination that the one or more authentication devices are available for authentication, display-enable (e.g., using the display-enable unit 1410) an option to proceed with the action on the display unit 1402 of the requesting device 1400. In accordance with a determination that the one or more authentication devices are not available for authentication, the processing unit 1404 is further configured to, in accordance with a determination that the one or more authentication devices are available for authentication, deactivate (e.g., using the display-enable unit 1410) a request to proceed with the action on the display unit 1402 of the requesting device 1400.

[0389] In some embodiments, the processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) a selection of one or more options associated with the second action before sending a request to proceed with the action by the requesting device 1400 to the authentication device, where the request to proceed with the action is a request to proceed with both the action and the second action, and the request further includes information regarding the selected one or more options associated with the second action, and information regarding the selected one or more options associated with the second action for display by the authentication device.

[0390] In some embodiments, the processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) a selection of a payment option prior to receiving a selection of an option to proceed with an action associated with the selected one or more options, and in response to receiving the selection of the payment option, to display enable (e.g., using the display enablement unit 1410) options for a plurality of payment accounts associated with the corresponding authentication device.

[0391] In some embodiments, the processing unit 1404 is configured to receive (e.g., using the receiving unit 1406) a selection of an option corresponding to each payment account from among the multiple payment account options prior to receiving a selection of an option to proceed with an action associated with the selected one or more options, and in response to receiving the selection of the option corresponding to each payment account, select each authentication device based on the selected option corresponding to each payment account (e.g., using the selection unit 1424).

[0392] In some embodiments, the processing unit 1404 is configured to display-enable (e.g., using the display-enable unit 1410) options for a plurality of payment accounts associated with the corresponding authentication device prior to receiving a selection of an option to proceed with an action associated with the selected one or more options, receive (e.g., using the receiving unit 1406) a selection of an option corresponding to each payment account, and, in response to receiving the selection of the option corresponding to each payment account, select each authentication device based on the selected option corresponding to each payment account (e.g., using the selection unit 1424).

[0393] In some embodiments, the processing unit 1404, after receiving a selection of an option corresponding to each payment account, is configured to simultaneously display and enable (e.g., using a display enablement unit) an indication of an option and an authentication device to proceed with an action associated with the selected one or more options.

[0394] In some embodiments, the indication of the authentication device includes a graphical representation of the authentication device.

[0395] In some embodiments, the multiple payment account options include a payment account linked to a first type of device regardless of whether the first type of device is currently in a locked or unlocked state, and the multiple payment account options include a payment account linked to a second type of device based on it being in an unlocked state.

[0396] In some embodiments, the authentication device is a telephone and the requesting device is a television device. In some embodiments, the authentication device is a telephone and the requesting device is a computer. In some embodiments, the authentication device is a wearable device and the requesting device is a television device. In some embodiments, the authentication device is a wearable device and the requesting device is a computer.

[0397] In some embodiments, the electronic wallet of the authentication device includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on a payment account of the one or more payment accounts.

[0398] In some embodiments, proceeding with the payment transaction includes transmitting payment information to a payment transaction server for participation in the payment transaction.

[0399] The operations described above with reference to Figures 10A-10B are optionally implemented by the components shown in Figures 1A-1B or 14. For example, receive operation 1002 and display operation 1010 are optionally implemented by event recognizer 180 and event handler 190. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0400] According to some embodiments, FIG. 15 illustrates an exemplary functional block diagram of an authentication device 1500 configured according to the principles of various described embodiments. According to some embodiments, the functional blocks of the authentication device 1500 are configured to execute the techniques described above. The functional blocks of the device 1500 are optionally implemented by hardware, software, or a combination of hardware and software to implement the principles of the various described examples. Those skilled in the art will understand that the functional blocks described in FIG. 15 are optionally combined or separated into sub-blocks to implement the principles of the various described examples. Thus, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein.

[0401] 15 , the authentication device 1500 includes a display unit 1502 configured to display a graphical user interface, optionally a hardware unit 1518, and a processing unit 1504 connected to the display unit 1502 and optionally the hardware unit 1518. In some embodiments, the processing unit 1504 includes a receiving unit 1506, a sending unit 1508, a display enabling unit 1510, a network forming unit 1512, a proceeding unit 1516, a generating unit 1518, a determining unit 1520, a locking unit 1524, and a requesting unit 1526.

[0402] The processing unit 1504 is configured to receive (e.g., using the receiving unit 1506) a request to proceed with the action from the requesting device, the request including information about the action, and the requesting device and the authenticating device are both signed in to the service using the same account. The processing unit 1504 is further configured to simultaneously display and enable (e.g., using the display enabling unit 1510) an indication of the request to proceed with the action, the information about the action, and an indication of the requesting device on the display unit 1502. The processing unit 1504 is further configured to display and enable (e.g., using the display enabling unit 1510) an authentication request to proceed with the action on the display unit 1502. The processing unit 1504 is further configured to receive (e.g., using the receiving unit 1506) an input that is a response to the authentication request to proceed with the action.

[0403] In some embodiments, the action is forming a secure network connection between the requesting device and the remote server (e.g., using the network forming unit 1512). The processing unit 1504 is configured to transmit the token information to the requesting device (e.g., using the transmitting unit 1508) in response to determining (e.g., using the determining unit 1520) that an input that is responsive to an authentication request to proceed with the action matches an input that is authenticated to proceed with the action.

[0404] In some embodiments, the processing unit 1504 is configured to simultaneously display and enable on the display unit 1502 (e.g., using the display enablement unit 1510) an indication of the request to proceed with the action, information about the action, and an indication of whether the requesting device has responded to receiving the request to proceed with the action.

[0405] In some embodiments, the authentication device 1500 includes a hardware unit 1518 configured to respond to input that is a response to an authentication request that proceeds with an action, and the requesting device does not include the hardware.

[0406] In some embodiments, the action is progressed by a payment transaction (e.g., using the progressing unit 1516). The processing unit 1504 is configured to generate payment information (e.g., using the generating unit 1518). The processing unit 1504 is further configured to transmit the payment information (e.g., using the transmitting unit 1508) in response to determining that an input in response to an authentication request to progress the action matches an input that is authenticated for progressing the action.

[0407] In some embodiments, the indication of the requesting device includes a graphical representation of the requesting device.

[0408] In some embodiments, the authentication device 1500 is in a locked state upon receiving an input that is a response to an authentication request to proceed with an action. The processing unit 1504 is configured to maintain the authentication device in a locked state (e.g., using the lock unit 1524) and to send a response to the request to proceed with the action, where the request to proceed with the action is based on the input, in response to determining that the input that is a response to the authentication request to proceed with the action matches an input that is authenticated to proceed with the action.

[0409] In some embodiments, the requesting device is signed in to the service using an account and the authenticating device is signed in to the service using an account.

[0410] In some embodiments, the authentication device 1500 is in a locked state upon receiving a request to proceed with the action. The processing unit 1504 is configured to, in response to receiving the request to proceed with the action, enable a request notification on the display unit 1502 (e.g., using the display enable unit 1510). The processing unit 1504 is configured to receive an input to activate the request notification (e.g., using the receiving unit 1506), request an authorization to unlock the authentication device (e.g., using the requesting unit 1526), ​​and receive an authorization to unlock the authentication device (e.g., using the receiving unit 1506) before simultaneously enabling an indication of the request to proceed with the action, information about the action, and an indication of the requesting device on the display. The processing unit 1504 is configured to unlock the authentication device (e.g., using the locking unit 1525) in response to receiving the authorization to unlock the authentication device. Concurrently displaying and enabling on the display unit 1502 an indication of a request to proceed with the action, information about the action, and an indication of the requesting device is responsive to receiving authorization to unlock the authentication device.

[0411] In some embodiments, the processing unit 1504 is configured to, in response to receiving a request to proceed with the action, to display enable a request notification on the display unit 1502 (e.g., using the display enable unit 1510). The processing unit 1504 is further configured to receive an input activating the request notification (e.g., using the request unit 1526) before simultaneously display enabling an indication of the request to proceed with the action, information regarding the action, and an indication of the requesting device on the display unit 1502, where the display enabling of the indication of the request to proceed with the action, information regarding the action, and an indication of the requesting device on the display unit 1502 is responsive to receiving the input activating the request notification.

[0412] In some embodiments, the authentication device 1500 is in the locked state upon receiving a request to proceed with the action. The processing unit 1504 is further configured to, in response to receiving the request to proceed with the action, enable (e.g., using the display enable unit 1510) a request notification on the display unit 1502. The processing unit 1504 is further configured to receive an input to activate the request notification (e.g., using the request unit 1526) before simultaneously enabling (e.g., using the display enable unit 1510) an indication of the request to proceed with the action, information about the action, and an indication of the requesting device on the display unit 1502, where the simultaneously enabling of the indication of the request to proceed with the action, information about the action, and an indication of the requesting device on the display unit 1502 is responsive to receiving the input to activate the request notification, and determining that the input in response to the authentication request to proceed with the action matches an input authenticated to proceed with the action does not transition the requesting device to the unlocked state.

[0413] In some embodiments, the authentication device 1500 is in an unlocked state when it receives a request to proceed with the action, the requesting device includes a hardware button, and receiving an input that is a response to the authentication request to proceed with the action includes detecting a double press of the hardware button while in the unlocked state.

[0414] In some embodiments, the information about the action includes one or more options associated with the action. The processing unit 1504 is further configured, after simultaneously display-enabling an indication of a request for the action, the information about the action, and an indication of the requesting device on the display unit 1502, to receive (e.g., using the receiving unit 1506) a user input requesting a change to at least one of the one or more options associated with the action, to send (e.g., using the sending unit 1508) an updated request including the change to the at least one of the one or more options associated with the action to the requesting device, to display-enable (e.g., using the display enabling unit 1510) an indication that a confirmation of receipt of the updated request has not been received from the requesting device, to receive (e.g., using the receiving unit 1506) an confirmation of receipt of the updated request from the requesting device, and to stop display-enabling (e.g., using the display enabling unit 1510) the indication that a confirmation of receipt of the updated request has not been received from the requesting device in response to receiving the confirmation of receipt of the updated request from the requesting device.

[0415] In some embodiments, the processing unit 1504 is configured to receive a request to cancel the action from the requesting device (e.g., using the receiving unit 1506) after receiving a request to proceed with the action and before receiving the input that is a response to the authentication request to proceed with the action. The processing unit 1504 is further configured to cease proceeding with the action (e.g., using the proceeding unit 1516) in response to receiving the request to cancel the action and in response to receiving the input that is a response to the authentication request to proceed with the action.

[0416] In some embodiments, the processing unit 1504 is configured to receive a request to cancel the action from the requesting device (e.g., using the receiving unit 1506) after receiving a request to proceed with the action and before receiving input that is a response to the authentication request to proceed with the action, and to cease receiving (e.g., using the receiving unit 1506) the input that is a response to the authentication request to proceed with the action in response to receiving the request to cancel the action.

[0417] In some embodiments, the processing unit 1504 is configured to proceed with the action by the authentication device 1500 without further input (e.g., using the proceeding unit 1516) after determining that an input in the authentication device that is a response to an authentication request to proceed with the action matches an input that is authenticated for proceeding with the action.

[0418] In some embodiments, the processing unit 1504 is configured to receive (e.g., using the receiving unit 1506) a second request to proceed with the second action. The processing unit 1504 is further configured to simultaneously display enable (e.g., using the display enable unit 1510) a second indication of the request to proceed with the action and an indication of whether the action was successful on the display unit 1502. The processing unit 1504 is further configured to simultaneously display enable (e.g., using the display enable unit 1510) a third indication of the second request to proceed with the second action and an indication of whether the second action was successful on the display unit 1502.

[0419] In some embodiments, the authentication device 1500 is a telephone and the requesting device is a television device. In some embodiments, the authentication device 1500 is a telephone and the requesting device is a computer. In some embodiments, the authentication device 1500 is a wearable device and the requesting device is a television device. In some embodiments, the authentication device 1500 is a wearable device and the requesting device is a computer.

[0420] In some embodiments, the electronic wallet of the authentication device 1500 includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on a payment account of the one or more payment accounts.

[0421] In some embodiments, proceeding with the payment transaction includes transmitting payment information to a payment transaction server for participation in the payment transaction.

[0422] The operations described above with reference to Figure 11 are optionally implemented by the components shown in Figures 1A-1B or 15. For example, receive operation 1102 and display operation 1108 are optionally implemented by event recognizer 180 and event handler 190. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0423] Exemplary methods, systems, electronic, request and authentication devices, and non-transitory computer-readable storage media are described in the following sections. 1. A method comprising: receiving a selection of one or more options at a requester device having a display; receiving, at the requesting device, a selection of an option that proceeds with an action associated with the selected one or more options; transmitting, by the requesting device, a request to proceed with the action, the request including information regarding the one or more options selected; receiving a request to proceed with an action by an authentication device having a display; An indication of a request to proceed with an action; Information regarding one or more selected options; and An indication of the requesting device, simultaneously displaying the same on a display of the authentication device; displaying an authentication request on a display of the authentication device to proceed with the action; receiving an input at an authentication device that is a response to an authentication request that proceeds with an action; transmitting, by the authentication device, a response to the request to proceed with the action, the response to the request to proceed with the action being based on the input that is a response to the authentication request to proceed with the action; receiving, by the requesting device, a response to the request to proceed with the action; displaying, at the requesting device, an indication on a display of the requesting device that the authentication was successful in response to the request to proceed with the action in accordance with a determination at the authenticating device that the authentication was successful; The method, at the requester device, responding to the request to proceed with the action includes, pursuant to a determination at the authentication device that the authentication was not successful, displaying an indication on a display of the requester device that the authentication was not successful. 2. 2. The method of claim 1, wherein the authentication device includes hardware configured to respond to input that is a response to an authentication request that proceeds with an action, and the requesting device does not include the hardware. 3. The action includes forming a secure network connection between the authentication device and a remote server; Item 3. The method of item 2, further comprising, in the authentication device, proceeding with the action using hardware configured to respond to the input in response to the authentication request to proceed with the action in accordance with a determination that the input in response to the authentication request to proceed with the action matches an input authenticated for proceeding with the action. 4. The action comprises forming a secure network connection between the requesting device and a remote server; The method further comprises: in response to determining, at the authenticator device, that the input in response to the authentication request to proceed with the action matches the input that is authenticated for proceeding with the action, transmitting, by the authenticator device, to the requester device, a token that is generated using hardware configured to respond to the input in response to the authentication request to proceed with the action; receiving, at the requesting device, a token from the authenticator; and proceeding with the action by the requesting device using the token received from the authenticating device. 5. 5. The method of any one of claims 1 to 4, wherein the indication of the requesting device includes a graphical representation of the requesting device. 6. The authentication device is in the locked state upon receiving an input in response to an authentication request that proceeds with an action at the authentication device, the method further comprising: at the authentication device, in response to determining that an input in response to an authentication request for proceeding with the action matches an input that is authenticated for proceeding with the action; 6. The method of any one of items 1 to 5, comprising maintaining the authentication device in a locked state and sending, by the authentication device, a response to the request to proceed with the action, wherein the response to the request to proceed with the action is based on the input. 7. The method according to any one of items 1 to 6, wherein the requesting device is signed in to the service using the account when sending a request to proceed with the action, and the authenticating device is signed in to the service using the account when receiving the request to proceed with the action. 8. The action proceeds with a payment transaction, the method further comprising: 7. The method of any one of items 1-2 and 5-6, comprising, in the authentication device, in response to determining that an input in response to the authentication request to proceed with the action matches an input authenticated for proceeding with the action, proceeding with the action by the authentication device using hardware configured to respond to the input in response to the authentication request to proceed with the action. 9. The action proceeds with a payment transaction, the method further comprising: in response to determining, at the authentication device, that the input in response to the authentication request to proceed with the action matches the input authenticated for proceeding with the action, transmitting, by the authentication device, payment information to the requesting device that was generated using hardware configured to respond to the input in response to the authentication request to proceed with the action; receiving, at the requester device, payment information from the authenticator device; and proceeding with the action by the requesting device using the payment information received from the authenticating device. 10. 9. The method according to any one of items 1 to 8, further comprising transmitting the token by the authentication device to a server, the server using the token to obtain a resource associated with the token. 11. 11. The method according to any one of items 1 to 8 and 10, further comprising transmitting the token by the requesting device to a server, the server using the token to obtain a resource associated with the token. 12. 10. The method of any one of claims 1 to 9, further comprising transmitting, by the authentication device, payment information to a payment transaction server, wherein...

Claims

1. 1. A method comprising: receiving, at a requester device having a display generation component, a selection of one or more options; receiving, at the requesting device, a selection of an option that proceeds with an action associated with the selected one or more options; sending, by the requesting device, a request to proceed with the action, the request including information regarding the selected one or more options; receiving, by an authentication device having a display generation component, the request to proceed with the action; on the display generation component of the authentication device, an indication of the request to proceed with the action; and said information regarding said selected one or more options; and an indication of the requesting device; and and displaying, on the display generating component of the authentication device, a request for permission to proceed with the action; receiving, at the authentication device, an input responsive to the request for permission to proceed with the action; transmitting, by the authentication device, a response to the request to proceed with the action, the response to the request to proceed with the action being based on the input in response to the request for permission to proceed with the action; receiving, by the requesting device, the response to the request that proceeds with the action; pursuant to a determination at the requesting device that the response to the request to proceed with the action indicates that the authorization at the authenticating device was successful, displaying an indication on the display generation component of the requesting device that the authorization was successful; pursuant to a determination at the requesting device that the response to the request to proceed with the action indicates that the authorization at the authenticating device was not successful, displaying an indication on the display generation component of the requesting device that the authorization was not successful; The method includes:

2. The method of claim 1 , wherein the authenticator device has hardware configured to respond to the input responsive to the request for permission to proceed with the action, and the requester device does not have the hardware.

3. The action creates a secure network connection between the authentication device and a remote server, the method comprising:

3. The method of claim 2, further comprising, in response to a determination at the authentication device that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action, proceeding with the action by the authentication device using the hardware configured to respond to the input responsive to the request for permission to proceed with the action.

4. The action creates a secure network connection between the requesting device and a remote server, the method comprising: in response to a determination at the authentication device that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action, transmitting, by the authentication device to the requesting device, a token generated using hardware configured to respond to the input responsive to the request for permission to proceed with the action; receiving, at the requesting device, the token from the authenticating device; proceeding, by the requesting device, with the action using the token received from the authenticating device; The method of claim 2 further comprising:

5. The method of claim 1 , wherein the indication of the requesting device comprises a graphical representation of the requesting device.

6. the authentication device is in a locked state when the input is received at the authentication device in response to the request for permission to proceed with the action, and the method further comprises: in response to a determination at the authentication device that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action; maintaining the authentication device in the locked state while the authentication device transmits the response to the request to proceed with the action, the response to the request to proceed with the action being based on the input; The method of claim 1 , further comprising:

7. 7. The method of claim 1, wherein the requesting device is signed in to a service using an account when it sends the request to proceed with the action, and the authenticating device is signed in to the service using the account when it receives the request to proceed with the action.

8. The action proceeds with a payment transaction, and the method further comprises: in response to a determination at the authentication device that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action, the authentication device proceeds with the action using hardware configured to respond to the input responsive to the request for permission to proceed with the action. The method of claim 1 , further comprising:

9. The action proceeds with a payment transaction, and the method further comprises: in response to determining at the authentication device that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action, the authentication device transmitting to the requesting device payment information generated using hardware configured to respond to the input responsive to the request for permission to proceed with the action; receiving, at the requester device, the payment information from the authentication device; proceeding with the action using the payment information received from the authentication device, by the requesting device; The method of claim 1 or 2, further comprising:

10. transmitting, by the authentication device, a token to a server, the server using the token to obtain a resource associated with the token, the resource including one or more of CPU time, network sockets, and memory access; The method of claim 1 , further comprising:

11. transmitting, by the requesting device, a token to a server, the server using the token to obtain a resource associated with the token, the resource including one or more of CPU time, a network socket, and memory access; The method of claim 1 , further comprising:

12. transmitting, by the authentication device, the payment information to a payment transaction server, the payment transaction server using the payment information to obtain resources associated with the payment information, the resources including funds; The method of claim 9 further comprising:

13. transmitting, by the requesting device, the payment information to a payment transaction server, the payment transaction server using the payment information to obtain resources associated with the payment information, the resources including funds; The method of claim 9 further comprising:

14. 14. The method of claim 1, wherein the action proceeds with a payment transaction and the authentication device has hardware for authorizing the payment transaction.

15. The action proceeds with a payment transaction, and the method further comprises: proceeding with the action by the authentication device without receiving further input from the requesting device after the authentication device determines that the input responsive to the request for permission to proceed with the action matches an input authorized to proceed with the action. The method of claim 1 , further comprising:

16. 16. The method of claim 1, wherein the authenticating device is a telephone and the requesting device is a television device.

17. 17. The method of claim 1, wherein the authenticating device is a phone and the requesting device is a computer.

18. 18. The method of claim 1, wherein the authentication device is a wearable device and the requesting device is a television device.

19. 19. The method of claim 1, wherein the authentication device is a wearable device and the requesting device is a computer.

20. 10. The method of claim 9, wherein the authentication device electronic wallet includes one or more payment accounts associated with a user of the authentication device, and the payment information is based on one of the one or more payment accounts.

21. 10. The method of claim 9, wherein proceeding with the payment transaction comprises transmitting the payment information to a payment transaction server that performs the payment transaction.

22. A computer program product configured to cause a computer system including a requestor and an authenticator to carry out the method of any one of claims 1 to 21.

23. A computer system including a requesting device having a representation generating component and an authenticating device having a representation generating component, comprising: means for receiving, at the requesting device, a selection of one or more options; means for receiving, at the requesting device, a selection of an option that proceeds with an action associated with the selected one or more options; means for transmitting, by the requesting device, a request to proceed with the action, the request including information regarding the selected one or more options; means for receiving, by the authentication device, the request to proceed with the action; on the display generation component of the authentication device, an indication of the request to proceed with the action; and said information regarding said selected one or more options; and an indication of the requesting device; and and a means for simultaneously displaying means for displaying, on the display generating component of the authentication device, a request for permission to proceed with the action; means for receiving, at the authentication device, an input responsive to the request for permission to proceed with the action; means for transmitting, by the authentication device, a response to the request to proceed with the action, the response to the request to proceed with the action being based on the input in response to the request for permission to proceed with the action; means for receiving, by the requesting device, the response to the request that proceeds with the action; means for displaying, in accordance with a determination at the requesting device that the response to the request to proceed with the action indicates that the authorization at the authenticating device was successful, an indication on the display generation component of the requesting device that the authorization was successful; means for displaying, in accordance with a determination at the requesting device that the response to the request to proceed with the action indicates that the authorization at the authenticating device was unsuccessful, an indication on the display generation component of the requesting device that the authorization was unsuccessful; A computer system comprising:

Images