Structured Proposal

Abstract

To identify suggested contact address information and event information, and provide those pieces of information to a user.SOLUTION: A method includes: causing an electronic device including a display to receive a message; identifying, in the received message, multiple case examples on a contact address or event information; and displaying a first user interface corresponding to the received message. The first user interface includes: a first portion containing content of the message as originally received by the electronic device; and a second portion for causing the electronic device to display a second user interface containing the multiple case examples of the identified contact address or event information when selected.SELECTED DRAWING: Figure 9A

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 62 / 005,839, entitled "STRUCTURED SUGGETIONS," filed May 30, 2014, and U.S. Patent Application No. 14 / 718,049, entitled "STRUCTURED SUGGETIONS," filed May 20, 2015, the contents of each of which are incorporated herein by reference for all purposes. [Background technology]

[0002] 1.Technical Field FIELD OF THE DISCLOSURE This disclosure relates generally to context-aware computing, and more particularly to identifying and providing suggested contact and event information to a user. 2. Background technology

[0003] Modern electronic devices allow users to stay more connected to friends, colleagues, and activities than ever before. However, managing contacts and calendar events on an electronic device can be cumbersome. For example, adding or updating a contact or calendar event typically requires several manual steps. As a result, many users neglect to keep their address books and calendars updated, choosing instead to rely on inefficient searching of stored messages and other content on the device when the user needs to find information about a person or event. This can result in a frustrating user experience and loss of productivity. Summary of the Invention

[0004] In some embodiments, a method of suggesting a contact includes receiving a message at an electronic device, identifying an entity and contact information associated with the entity in the received message, determining that a contact associated with the identified entity does not exist among a plurality of contacts in a database, and in response to the determination, generating a contact associated with the entity, the generated contact including the contact information and an indication that the generated contact is a suggested contact.

[0005] In some embodiments, a method of suggesting a contact includes receiving, at an electronic device, a message; identifying, in the received message, an entity and an item of contact information associated with the entity; determining that a contact associated with the identified entity is present among a plurality of contacts in a database and that the contact does not include the identified item of contact information; and, in response to the determination, updating the contact to include the item of contact information and an indication that the item of contact information is a suggested item of contact information.

[0006] In some embodiments, a method of suggesting contacts includes receiving a message on an electronic device having a display; identifying an entity and contact information associated with the entity in the received message; generating an indication that the identified contact information is suggested contact information; and displaying a first user interface corresponding to the contact associated with the entity, the first user interface including a first user interface object indicating that the identified contact information is suggested contact information based on the generated indication.

[0007] In some embodiments, a method of suggesting contacts includes receiving a message at an electronic device having a display, identifying entities and contact information associated with the entities in the received message, and displaying a first user interface corresponding to the received message, the first user interface including a first portion including content of the message as received by the electronic device and a second portion including a first user interface object corresponding to the identified entity, a second user interface object corresponding to the identified contact information, and a third user interface object associated with the identified contact information that, when selected, causes the electronic device to add the identified contact information to a database.

[0008] In some embodiments, a method of suggesting a calendar event includes receiving, at an electronic device, a message, identifying event information in the received message, and generating a calendar event associated with the identified event information, the generated calendar event including the event information and an indication that the generated calendar event is a suggested calendar event.

[0009] In some embodiments, a method of suggesting a calendar event includes, at an electronic device having a display, receiving a message, identifying event information in the received message, and displaying a first user interface corresponding to the received message, the first user interface including a first portion including content of the message as received by the electronic device and a second portion including a first user interface object corresponding to the identified event information and a second user interface object associated with the identified event information that, when selected, causes the electronic device to add the identified event information to a database including a plurality of calendar events.

[0010] In some embodiments, a method of suggesting multiple contacts and / or calendar events includes receiving a message on an electronic device having a display, identifying multiple instances of contact or event information in the received message, and displaying a first user interface corresponding to the received message, the first user interface including a first portion including content of the message as received by the electronic device and a second portion that, if selected, causes the electronic device to display a second user interface including a list of multiple instances of the identified contact or event information. [Brief description of the drawings]

[0011] [Figure 1A] FIG. 1 is a block diagram illustrating a portable multifunction device with a touch-sensitive display in accordance with some embodiments. [Figure 1B] FIG. 2 is a block diagram illustrating example components for event processing according to some embodiments. [Diagram 2] FIG. 1 illustrates a portable multifunction device having a touch screen in accordance with some embodiments. [Diagram 3] 1 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface in accordance with some embodiments. [Figure 4A] 1 illustrates an exemplary user interface for a menu of applications on a portable multifunction device in accordance with some embodiments. [Figure 4B] 1 illustrates an exemplary user interface for a menu of applications on a portable multifunction device in accordance with some embodiments. [Figure 5A] FIG. 2 is a block diagram of an example data structure for suggested contacts according to some embodiments. [Figure 5B]FIG. 2 illustrates a block diagram of an example data structure for suggested calendar events according to some embodiments. [Figure 6A] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6B] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6C] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6D] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6E] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6F] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 6G] FIG. 2 illustrates an exemplary user interface for providing suggested contacts and calendar events according to some embodiments. [Figure 7A] FIG. 1 is a flow diagram of an example process for generating suggested contacts according to some embodiments. [Figure 7B] FIG. 1 is a flow diagram of an example process for generating suggested contacts according to some embodiments. [Figure 8A] FIG. 1 is a flow diagram of an example process for updating an existing contact with suggested items of contact information according to some embodiments. [Figure 8B] FIG. 1 is a flow diagram of an example process for updating an existing contact with suggested items of contact information according to some embodiments. [Figure 9A] FIG. 1 is a flow diagram of an example process for displaying contacts with suggested contact information according to some embodiments. [Figure 9B] FIG. 1 is a flow diagram of an example process for displaying contacts with suggested contact information according to some embodiments. [Figure 10] FIG. 1 is a flow diagram of an example process for displaying suggested contact information with a message according to some embodiments. [Figure 11A] FIG. 1 is a flow diagram of an example process for generating suggested calendar events according to some embodiments. [Figure 11B] FIG. 1 is a flow diagram of an example process for generating suggested calendar events according to some embodiments. [Figure 12] FIG. 1 is a flow diagram of an example process for displaying suggested event information along with a message according to some embodiments. [Figure 13] FIG. 11 is a flow diagram of an example process for displaying multiple suggested contact or event information along with a message according to some embodiments. [Figure 14] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 15] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 16] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 17] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 18] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 19] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 20] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 21]FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. [Figure 22] FIG. 1 is a functional block diagram of an electronic device in accordance with some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] In the following description of the disclosure and embodiments, reference is made to the accompanying drawings, in which is shown, by way of illustration, specific embodiments which may be practiced. It is to be understood that other embodiments and examples may be practiced and changes may be made without departing from the scope of the present disclosure.

[0013] As mentioned above, managing contacts and calendar events on an electronic device can be cumbersome for users because adding or updating a contact or calendar event requires several manual steps that are time-consuming. Because of this, many users easily neglect to keep their address books and calendars up to date, which later results in more time when the user needs to manually search their device for specific contact or event information. This can result in a frustrating user experience and loss of productivity.

[0014] The present disclosure addresses this challenge by providing an electronic device that automatically suggests contacts and calendar events for a user based on the user's messages. The device can analyze the user's messages for contact and event information and automatically generate or update suggested contacts and calendar events for the user based on this information. The suggested contacts and calendar events are searchable as if they were manually entered by the user, and the user can choose to add or ignore the suggested contacts and calendar events. In this way, the user's contacts and calendar events can be maintained with no or minimal effort on the user's part. This can save the user time, increase productivity, and create a more efficient human-machine interface. 1. Exemplary Devices

[0015] In the following, Figures 1A, 1B, 2, and 3 provide a description of an example device for performing techniques for suggesting contact and event information. Figures 4A, 4B, and 6A-6G show example user interfaces for suggesting contact and event information. The user interfaces in these figures are used to illustrate the processes described below, including the processes in Figures 7A-13.

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

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

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

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

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

[0021] The device may support a variety of applications, such as one or more of drawing applications, presentation applications, word processing applications, website creation applications, disk authoring applications, spreadsheet applications, gaming applications, telephony applications, video conferencing applications, e-mail applications, instant messaging applications, training support applications, photo management applications, digital camera applications, digital video camera applications, web browsing applications, digital music playback applications, and / or digital video playback applications.

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

[0023] Attention is now directed to embodiments of portable devices with touch-sensitive displays. FIG. 1A is a block diagram illustrating a portable multifunction device 100 with a touch-sensitive display system 112, according to some embodiments. Touch-sensitive display 112 may be conveniently referred to as a "touch screen" and may also be known or referred to as a "touch-sensitive display system." Device 100 includes memory 102 (optionally including one or more computer-readable storage media), 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 control devices 116, and an external port 124. Device 100 optionally includes one or more light sensors 164. Device 100 optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on device 100 (e.g., a touch-sensitive surface such as touch-sensitive display system 112 of device 100). Device 100 optionally includes one or more tactile output generators 167 for generating a tactile output on device 100 (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 optionally communicate via one or more communication buses or signal lines 103.

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

[0025] As used herein and in the claims, the term "tactile output" refers to a physical displacement of a device relative to a previous position of the device, a physical displacement of a component of the device (e.g., a touch-sensitive surface) relative to another component of the device (e.g., a housing), or a displacement of a component relative to the center of mass of the device, that is to be detected by a user with the user's sense of touch. For example, in a situation where a device or a component of the device is in contact with a touch-sensitive user's surface (e.g., the fingers, palm, or other part of the user's hand), the tactile output generated by the physical displacement is interpreted by the user as a tactile sensation that corresponds to a perceived change in a physical property of the device or a component of the device. For example, movement of a touch-sensitive surface (e.g., a touch-sensitive display or trackpad) is optionally interpreted by the user as a "down-click" or "up-click" of a physical actuator button. In some cases, the user feels a tactile sensation such as a "down-click" or "up-click" even when no movement of a physical actuator button associated with the touch-sensitive surface is physically pressed (e.g., displaced) by the user's movement. As another example, movement of the touch-sensitive surface is, optionally, 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 user interpretation of touch depends on the user's individual sensory perception, but there are many sensory perceptions of touch that are common to a majority of users. Thus, when a tactile output is described as corresponding to a particular sensory perception of a user (e.g., an "up click," a "down click," "roughness"), unless otherwise stated, the generated tactile output corresponds to a physical displacement of the device, or a component of the device, that produces the described sensory perception for a typical (or average) user.

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

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

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

[0029] The RF (Radio Frequency) circuitry 108 transmits and receives RF signals, also called electromagnetic signals. The RF circuitry 108 converts electrical signals to electromagnetic signals or electromagnetic signals to electrical signals and communicates with communication networks and other communication devices via electromagnetic signals. The RF circuitry 108 optionally includes well-known circuitry for performing the above 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 optionally communicates by wireless communication with networks such as the Internet, also called the Internet Information Retrieval System (WWW), intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs), and other devices. The RF circuitry 108 optionally includes well-known circuitry for detecting near field communication (NFC), for example, by short range radio. The wireless communication optionally uses any of a number of communication standards, protocols, and technologies, including Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), high-speed downlink packet access (HSDPA), high-speed uplink packet access (HSUPA), Evolution, Data-Only (EV-DO), HSPA, HSPA+, Dual-Cell HSPA (DC-HSPA), long term evolution (LTE), near field communication (NFC), wideband code division multiple access (WDMA), and the like.access (W-CDMA), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and / or IEEE 802.11ac), voice over Internet Protocol (VoIP), Wi-MAX, protocols for e-mail (e.g., Internet message access protocol (IMAP) and / or post office protocol (POP)), instant messaging (e.g., extensible messaging and presence protocol (XMPP), Session Initiation Protocol for Instant Messaging and Presence Leveraging), and the like. Examples of suitable communication protocols include, but are not limited to, Simple Intermediate System (SIMPLE), Instant Messaging and Presence Service (IMPS), and / or Short Message Service (SMS), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document.

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

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

[0032] A quick press of the push button may unlock the touch screen 112 or 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, "Unlocking a Device by Performing Gestures on an Unlock Image," U.S. Patent No. 7,657,849, filed December 23, 2005, which is incorporated by reference in its entirety. A longer press of a push button (e.g., 206) may turn power on or off to the device 100. The user may be able to customize the functionality of one or more buttons. The touch screen 112 is used to implement virtual or soft buttons as well as one or more soft keyboards.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] The application 136 may include the following modules (or sets of instructions), or a subset or superset thereof: ● a contacts module 137 (sometimes called an address book or contact list); ● Telephone module 138, ●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 stock widget 149-2, a calculator widget 149-3, an alarm clock widget 149-4, a dictionary widget 149-5, and other widgets acquired by the user, as well as user-created widgets 149-6; ● a widget creation module 150 for creating user-created widgets 149-6; ● Search module 151, A video and music player module 152 that integrates a video player module and a music player module; ● Memo module 153, Map module 154, and / or ●Online Video Module 155

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

[0059] The contacts module 137, along 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 memory 102 or in the application internal state 192 of the contacts module 137 in the memory 370), including adding a name(s) to the address book, deleting a name(s) from the address book, associating a phone number(s), email address(es), address(es), or other information with a name, associating a picture with a name, categorizing and sorting names, providing a phone number or email address to initiate and / or facilitate communication by phone 138, videoconferencing module 139, mail 140, or IM 141, and the like.

[0060] Telephone module 138, along 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 each telephone number, conduct a conversation, and disconnect or hang up when the conversation is completed. As mentioned above, wireless communication may use any of a number of communication standards, protocols, and technologies.

[0061] Video conferencing module 139, along with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, light sensor 164, light sensor controller 158, contact / motion module 130, graphics module 132, text input module 134, contact module 137, and telephone module 138, contains executable instructions for initiating, conducting, and terminating a video conference between a user and one or more other participants in accordance with the user's instructions.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0079] 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 corresponding application 136-1 (e.g., any of applications 137-151, 155, 380-390 discussed above).

[0080] Event sorter 170 accepts the event information and determines application 136-1 and application view 191 of application 136-1 to which to deliver the event information. Event sorter 170 includes an event monitor 171 and an event dispatcher module 174. In some embodiments, application 136-1 includes application internal state 192 that indicates the current application view(s) that are 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 which application is currently active, and application internal state 192 is used by event sorter 170 to determine which application view 191 to deliver the event information to.

[0081] 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 is being displayed or ready to be displayed by application 136-1, a state queue to allow the user to return to a previous state or view of application 136-1, and a redo / undo queue of actions previously performed by the user.

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

[0083] In some embodiments, event monitor 171 sends a request to peripherals interface 118 at predetermined intervals. In response, peripherals interface 118 sends out the event information. In other embodiments, peripherals interface 118 sends out the event information only if there is a significant event (e.g., exceeding a predetermined noise threshold and / or receiving an input for more than a predetermined time). In some embodiments, event sorter 170 also includes a hit view determination module 172 and / or an active event recognizer determination module 173.

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

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

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

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

[0088] Event dispatcher module 174 sends the event information to an event recognizer (e.g., event recognizer 180). In embodiments that include active event recognizer determination module 173, event dispatcher module 174 distributes the event information to the event recognizers determined by active event recognizer determination module 173. In some embodiments, event dispatcher module 174 stores event information obtained by each event receiver 182 in an event queue.

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

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

[0091] Each event recognizer 180 receives event information (e.g., event data 179) from event sorter 170 and identifies an event from the event information. Event recognizer 180 includes an event receiver 182 and an 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).

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

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

[0094] In some embodiments, event definition 186 includes a definition of the event 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 (the sub-event). If each displayed object is associated with a respective event handler 190, event comparator 184 uses the results of the hit test to determine which event handler 190 needs to be activated. For example, event comparator 184 selects the event handler associated with the sub-event and the object that triggers the hit test.

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

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

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

[0098] In some embodiments, each event recognizer 180 activates an event handler 190 associated with an event when one or more particular sub-events of the event are recognized. In some embodiments, each event recognizer 180 distributes event information associated with the event to the event handler 190. A distinction is made between activating an event handler 190 and sending (and deferring sending) sub-events to the respective hit view. In some embodiments, the event recognizer 180 throws a flag associated with the recognized event, and the event handler 190 associated with the flag catches the flag and performs predefined processing.

[0099] 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 distribute the event information to event handlers associated with a set of sub-events or actively participating views. The event handlers associated with the set of sub-events or actively participating views accept the event information and perform the specified processing.

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

[0101] In some embodiments, event handler(s) 190 includes or has access to data updater 176, object updater 177, and GUI updater 178. In some embodiments, data updater 176, object updater 177, and GUI updater 178 are included in one module of the respective application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.

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

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

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

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

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

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

[0108] For example, attention is directed to embodiments of a user interface that may be implemented on portable multifunction device 100 .

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

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

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

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

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

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

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

[0116] As used in the specification and claims, the term "characteristic intensity" of a contact 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 characteristic intensity is optionally based on a predefined number of intensity samples or a set of intensity samples collected within a predefined time period (e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds) relative to a predefined 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 is optionally based on one or more of the maximum intensity of the contact, the mean of the intensity of the contact, the average of the intensity of the contact, the top 10 percentiles of the intensity of the contact, half the maximum intensity of the contact, 90 percent of the maximum intensity of the contact, etc. In some embodiments, the duration of the contact is used to determine the characteristic intensity (e.g., when the characteristic intensity is an average of the intensity of the contact over time). In some embodiments, the characteristic intensity is compared to a set of one or more intensity thresholds to determine whether an action is performed by the user. For example, the set of one or more intensity thresholds may include a first intensity threshold and a second intensity threshold. In this example, a contact having a characteristic intensity that does not exceed the first threshold results in a first action being performed, a contact having a characteristic intensity that exceeds the first intensity threshold and does not exceed the second intensity threshold results in a second action being performed, and a contact having a characteristic intensity above the second threshold results in a third action being performed. In some embodiments, the comparison between the characteristic intensity and the one or more thresholds is not used to determine whether to perform the first action or the second action, but rather to determine whether to perform one or more actions (e.g., to perform the respective action or to omit performing the respective action).

[0117] In some embodiments, a portion of the gesture is identified for purposes of determining the characteristic intensity. For example, a touch-sensitive surface may receive 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 (e.g., only the portion of the swipe contact at the end position) rather than the entire continuous swipe contact. In some embodiments, 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 optionally includes one or more of an unweighted moving average smoothing algorithm, a triangular smoothing algorithm, a median filter smoothing algorithm, and / or an exponential smoothing algorithm. In some circumstances, these smoothing algorithms filter out small increases or decreases in the intensity of the swipe contact for purposes of determining the characteristic intensity.

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

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

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

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

[0122] For ease of explanation, descriptions of actions performed in response to a pressure input associated with a pressure input intensity threshold or in response to a gesture including that pressure input are optionally triggered in response to detecting either an increase in the intensity of the contact above the pressure input intensity threshold, an increase in the intensity of the contact from an intensity below a hysteresis intensity threshold to an intensity above the pressure input intensity threshold, a decrease in the intensity of the contact below the pressure input intensity threshold, and / or a decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to the pressure input intensity threshold. Additionally, in embodiments where an action is described as being performed in response to detecting a decrease in the intensity of the contact below a pressure input intensity threshold, the action is optionally performed in response to detecting a decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to the pressure input intensity threshold and below the pressure input intensity threshold. 2. Structured Proposal

[0123] In an embodiment of the present disclosure, an electronic device can structure suggested contacts and calendar events for a user from the user's messages. The suggested contacts and calendar events are searchable as if they were manually entered by the user, and the user can choose to add or ignore (e.g., reject) the suggested contacts and calendar events. In this manner, the user's contacts and calendar events can be maintained with no or minimal effort on the user's part. This can save the user time, increase productivity, and create a more efficient human-machine interface. 2.1 Suggested Contact Information

[0124] 5A illustrates an example data structure 502A for suggested contacts, according to some embodiments. As shown in FIG. 5A, the electronic device 500 can associate (e.g., store) contact information 520A from a message 510 with a corresponding contact 530A. The message 510 can include any type of message that can be sent or received by a user of the device 500, such as, for example, an email, an instant message, a message via an application on the device 500, etc., and can include any attachments to the message 510.

[0125] Contact information 520A may include information typically associated with a contact entry in an address book database, such as the entity's name, phone number, address, business or social network handle, etc. Contact entries are typically organized or indexed by entity, which may include individuals, groups, organizations, businesses, etc. Contact information 520A may be stored in any suitable format that an application, such as contacts module 137, can recognize to process contact information 520A. Contact information 520 may also be formatted according to a standard protocol, such as the CardDAV protocol, to allow for updates and synchronization with other clients over a network.

[0126] In some embodiments, the identified contact information 520A can be associated with the contact 530A in any one of three mutually exclusive states - a proposed state 540, an added state 550, and a rejected state 560. The proposed state 540 may indicate a state in which the user has not yet confirmed or approved the addition of the contact information 520A to the contact. The added state 550 may indicate a state in which the user has confirmed or approved the addition of the contact information 520A to the contact. The rejected state 560 may indicate a state in which the user has rejected the addition of the contact information 520A to the contact. The contact 530A can also be associated with any one of these three states if all associated contact information belongs to the same state.

[0127] In some embodiments, the added state 550 can be treated as a default state by the device 500. The default state means that no additional data needs to be associated with such contacts to indicate that they are in the added state 550. For example, contacts added by a user on the device 500 can default to the added state 550.

[0128] In embodiments in which the added state 550 is treated as the default state, the device 500 may associate data with the contact information 520A to indicate that the contact information 520A belongs to either the proposed state 540 or the rejected state 560. This data may take any suitable form, such as metadata, which may be used by an application processing the contact information 520A to recognize that the contact information 520A is in either the proposed state 540 or the rejected state 560. The device 500 may also associate data with the contact 530A to indicate that the contact 530A and all associated contact information belongs to either the proposed state 540 or the rejected state 560.

[0129] By storing contact information 520A in the suggested state 540, device 500 (e.g., via an application running on device 500) can include the contact information in a search for contacts. To avoid user confusion, device 500 can also indicate to the user that contact information 520A is in the suggested state 540 by providing a visual indication (e.g., by labeling or highlighting) and / or by preventing the user from acting directly on contact information 520A (e.g., by requiring additional input from the user before allowing the user to act on contact information 520A). Input can refer to any suitable method of input, such as touch, mouse, speech, etc.

[0130] By storing contact information 520A in the rejected state 560, device 500 can remember previously suggested contact information that a user rejected so as not to suggest the contact information to the user again. Contact information 520A in the rejected state 560 can be ignored by applications that process contact information in the added state 550 and suggested state 540.

[0131] The device 500 may store the contact information 520A locally on the device 500 and may refrain from synchronizing the contact information 520A to a remote database until the contact information 520A changes from the suggested state 540 to the added state 550. In other embodiments, the contact information 520A may be updated to the remote database while in the suggested state 540.

[0132] Device 500 can identify contact information 520A from structured or unstructured content in message 510. Structured content refers to content that has a formal organization or structure arranged according to a predefined format, such as an automated email provided by an online travel agency that lays out flight, hotel, and / or car reservation information in the same predefined way (e.g., using the same HTML structure). In some embodiments, to identify contact information 520A from structured content, device 500 can use templates that are configured to recognize contact information in a particular format provided by such a message. In some embodiments, device 500 can add and / or update these templates over the network.

[0133] Unstructured content refers to content that does not have a formal organization or structure, such as natural language content (e.g., someone mentions in a message that they have a new number) and email signatures. To identify contact information 520A from unstructured content, device 500 can use data detectors configured to identify predefined references to contact information, such as specific phrases, e.g., "I got a new number, it's <number>". Device 500 can also add and / or update these data detectors on the network. Device 500 can refine the predefined references relied upon by the data detectors by cross-correlating contact information on device 500 (e.g., in an address book database) with language associated with that contact information on device 500 (e.g., in a message). The correlated language can then be used to refine the predefined references for subsequent use. Message content analyzed by device 500 can include any information recognizable by device 500, including message metadata.

[0134] In some embodiments, the device receives an instruction (e.g., a user request) to initiate communication (e.g., a phone call, an instant message, an email) with a contact (e.g., an individual or a business). The device determines that the contact is not in the device's address book. In response, the device locates the contact information (e.g., phone number, username, email address) based on one or more communications (e.g., instant message, email, calendar entry). That is, the device searches a database of possible contacts to identify the requested contact referenced in the instruction. Optionally, the device presents a ranked list of possible matching contacts and receives user input to select the intended contact. In response to the user input to select the intended contact, the device may initiate communication (e.g., a phone call, an instant message, an email) with the intended contact. 2.2 Suggested Event Information

[0135] 5B illustrates an example data structure 502B for suggested calendar events, according to some embodiments. As shown in FIG. 5B, the electronic device 500 can associate (e.g., store) event information 520B from a message 510 with a corresponding calendar event 530B. The message 510 can include any type of message that can be sent or received by a user of the device 500, such as, for example, an email, an instant message, a message via an application on the device, etc., and can include any attachments to the message.

[0136] The event information 520B may include information typically associated with a calendar entry in a calendar database, such as time, date, location, etc. The event information 520B may be stored in any suitable format that an application, such as the calendar module 148, can recognize to process the event information 520B. The event information 520B may also be formatted according to a standard protocol, such as the CalDAV protocol, to allow it to be updated or synchronized with other clients over a network.

[0137] In some embodiments, the identified event information 520B may be associated with the calendar event 530B in any one of three mutually exclusive states - proposed state 540, added state 550, and rejected state 560. The proposed state 540 may indicate a state in which a user has not yet confirmed or approved the addition of the event information 520B to the calendar event. The added state 550 may indicate a state in which a user has confirmed or approved the addition of the event information 520B to the calendar event. The rejected state 560 may indicate a state in which a user has rejected the addition of the event information 520B to the calendar event. The calendar event 530B may also be associated with any one of these three states if all associated calendar event information belongs to the same state.

[0138] In some embodiments, the added state 550 may be treated as a default state by the device 500, meaning that no additional data needs to be associated with such calendar event to indicate that it is in the added state 550. For example, calendar events added by a user on the device 500 may default to the added state 550.

[0139] In embodiments in which the added state 550 is treated as the default state, the device 500 may associate data with the event information 520B to indicate that the event information 520B belongs to either the proposed state 540 or the rejected state 560. This data may take any suitable form, such as metadata, which may be used by an application that processes the event information 520B to recognize that the event information 520B is in either the proposed state 540 or the rejected state 560. The device 500 may also associate data with the calendar event 530B to indicate that the calendar event 530B and all associated event information belongs to either the proposed state 540 or the rejected state 560.

[0140] By storing the event information 520B in the suggested state 540, the device 500 (e.g., via an application running on the device 500) can include the event information as suggested in a search for calendar events. To avoid user confusion, the device 500 can also indicate to the user that the event information 520B is in the suggested state 540 by providing a visual indication (e.g., by labeling or highlighting) and / or by preventing the user from directly acting on the event information 520B (e.g., by requiring additional input from the user before the user can act on the event information 520B). Input can refer to any suitable method of input, such as touch, mouse, speech, etc.

[0141] By storing event information 520B in the rejected state 560, device 500 can remember previously proposed event information that a user rejected so as not to suggest the event information to the user again. Event information 520B in the rejected state 560 can be ignored by applications that process event information in the added state 550 and proposed state 540.

[0142] The device 500 may store the event information 520B locally on the device 500 and may refrain from synchronizing the event information 520B to the remote database until the event information 520B changes from the proposed state 540 to the added state 550. In other embodiments, the event information 520B may be updated to the remote database while in the proposed state 540.

[0143] Device 500 can identify event information 520B from structured or unstructured content in message 510. Structured content refers to content that has a formal organization or structure arranged according to a predefined format, such as an automated email provided by an online travel agency that lays out flight, hotel, and / or car reservation information in the same predefined way (e.g., using the same HTML structure). In some embodiments, to identify event information 520B from structured content, device 500 can use templates that are configured to recognize event information in a particular format provided by such a message. In some embodiments, device 500 can add and / or update these templates on the network.

[0144] Unstructured content refers to content that does not have a formal organization or structure, such as natural language content (e.g., someone says in a message that they are going to meet you at a certain time somewhere) and email signatures. To identify event information 520B from unstructured content, device 500 can use data detectors configured to identify predefined references to event information, such as specific phrases, e.g., "meet me at <location> at <time>". Device 500 can also add and / or update these data detectors on the network. Device 500 can refine the predefined references relied upon by the data detectors by cross-correlating event information on device 500 (e.g., in a calendar database) with language associated with that event information on device 500 (e.g., in a message). The correlated language can then be used to refine the predefined references for subsequent use. The content of messages analyzed by device 500 can include any information recognizable by device 500, including message metadata.

[0145] In some examples, the device identifies one or more communications (e.g., emails or other content) associated with a calendar event (e.g., a calendar event added by the user or a received meeting invitation accepted by the user). For example, the device may determine that a communication is associated with a calendar event if the communication describes an event with the same or similar name, an event with the same or similar date / time and / or duration, and / or an event in the same location. For another example, the device may determine that a communication is associated with a calendar event based on the calendar event including the same or similar language used in the communication. The one or more communications and the associated calendar events may be analyzed and / or compared to better identify candidate communications for which future calendar entries should be created or suggested. For example, machine learning techniques may be used to learn patterns of event creation by training / analyzing emails that are the basis of the events (using support vector machines and corpora of emails used to create the calendar events).

[0146] For example, the device may receive an email communication from an auto parts store that includes the language, "Hello, could you stop by the parts store tomorrow to pick up a replacement part?" The email may also include an email signature that includes a street address of the parts store. The user may then manually create a calendar event that includes the language, "Stop by the parts store to pick up a replacement part." The calendar event may also include the street address of the parts store as the location of the calendar event. Based on the email communication and the calendar event, the device may use machine learning to determine that this type of email communication requires a suggestion for a calendar entry. The determination may be based on a similarity between "Stop by the parts store to pick up a replacement part" in the email communication and the calendar event, a similarity between the street address in the email communication and the calendar event, a similarity of dates / times identified in the email communication and the calendar event, or a combination of two or more of these.

[0147] In some examples, the device identifies event information from (e.g., during) an instant messaging conversation (e.g., an SMS or text messaging conversation). During the conversation, the device collects information related to the event. After a relevant portion of the conversation (e.g., after a predetermined set of information has been collected), the device generates a suggested calendar event. In some examples, the suggested calendar event is updated based on conversation messages sent or received after the initial suggested calendar event was generated. This conversation event creation technique allows a user to quickly and efficiently add events to a calendar based on messages in an instant messaging conversation.

[0148] For example, the device may display an instant message conversation between a user of the device and a representative of an auto parts store. The conversation may include a message from the representative that includes the language, "Hello, would you mind stopping by the parts store tomorrow to pick up a replacement part?". The conversation may also include a message from the representative that includes a street address for the parts store. The user may respond, "Yes, I'll be there!". In response to the relevant portions of the conversation (e.g., receiving a confirmation of the visit, "Yes, I'll be there!", or a time and location (street address) of "tomorrow"), the device may generate suggested calendar information. If the device subsequently receives a message from the representative indicating an updated time (e.g., "Actually, we're closed tomorrow, but we're open this Friday"), location, or other event components, the device may update the suggested calendar event.

[0149] It should be appreciated that the exemplary data structures 520A and 520B may be the same or different. For example, a single data structure may be used for suggested contacts as well as for suggested calendar events. Or, one data structure may be used for suggested contacts while another, different data structure is used for suggested calendar events.

[0150] It should also be appreciated that message 510 may be processed only for the suggested contacts, only for the suggested calendar event, or for both the suggested contacts and the suggested calendar event. If processed for both the suggested contacts and the suggested calendar event, message 510 may be processed sequentially or in parallel for the suggested contacts and the suggested calendar event. For example, message 510 may be processed first for the suggested contacts and then for the suggested calendar event. Alternatively, message 510 and a copy of message 510 may be processed in parallel for the suggested contacts and the suggested calendar event.

[0151] In some examples, an announcement or reminder may be presented to the user (through a visual, tactile, audio, or a combination of one or more announcements on device 500) based on event information identified from structured or unstructured content in a message or other media. In some examples, an announcement or reminder may be presented to the user even if the event information is not associated with an added state. For example, the device may remind the user to pack based on an email received about an upcoming camping trip, even if the camping trip has not been added to the user's calendar. Thus, reminders may be presented for calendar entries, events, etc. that are in a proposed state (e.g., not explicitly accepted or rejected). 3. User Interface and Related Processes

[0152] 6A-13 illustrate embodiments of a user interface ("UI") and associated processes that may be implemented in device 500. In some embodiments, device 500 corresponds to device 100 or 300.

[0153] 6A and 6G show example user interfaces for providing suggested contacts and calendar events according to some embodiments.

[0154] 6A illustrates a display, e.g., by the contacts module 137 of a user interface, corresponding to a contact including suggested contact information (i.e., contact information in the proposed state 540), e.g., after processing a message as described above. In this example, the contact is associated with a personal name, John Appleseed, and includes a business name ("Any Company Inc."), a work number ("405-555-1234"), and a mobile phone number ("405-123-6633"). The business name and work number are confirmed items of contact information and reside in the added state 550. The mobile phone number is a proposed item of contact information and resides in the proposed state 540.

[0155] Device 500 may provide a user interface object 600 (e.g., the word "suggested") in the user interface to indicate to the user that the mobile phone number is a suggested item of contact information and not one that has been accepted by the user. Any suitable user interface object may be used for this purpose, including a label, icon, or other visual indication that the mobile phone number is a suggested item of contact information. If the same contact includes an item of contact information in the suggested state 540 and an item of contact information in the added state 550, as in the example of FIG. 6A, device 500 may display the item in the suggested state 540 below or at a lower priority relative to all items in the added state 550.

[0156] The device 500 may also prevent the user from directly invoking an application (e.g., the phone module 138) that would call John Appleseed at the suggested number from this initial user interface. For example, the device 500 may provide text and / or a region associated with the suggested number that has a different visual appearance than the accepted item of contact information (e.g., a grayed-out appearance (not shown)) to indicate that the user's selection of the suggested number will not result in a direct call to that number. Rather, once the user selects the suggested number, the device 500 may replace the current user interface with a second user interface that allows the user to review the suggested number and place the call.

[0157] As shown in FIG. 6B, the second user interface (labeled “Review Suggestion”) includes a suggestion portion 606 in the form of a banner that includes a user interface object 602 (labeled “Add to Contacts”) associated with the suggested number. Selection by the user of the user interface object 602 can cause the device 500 to add the suggested number to the contact in the added state 550 (e.g., change the state of the suggested number from the suggested state 540 to the added state 550). Based on the user's selection of the mobile number or a similar indicia, such as a phone icon displayed next to the mobile number in this subsequent user interface, the device 500 can invoke an application (e.g., the phone module 138) that calls John Appleseed at the suggested number. In some embodiments, the device 500 can maintain the mobile number in the suggested state 540 if the user does not select the user interface object 602 but selects the mobile number and a similar indicia (e.g., the user's calling the suggested number is not treated as an implicit acceptance of the suggested number to the contact). In other embodiments, device 500 may change the state of the mobile phone number to added state 550 when the user selects the mobile phone number, even if the user did not select user interface object 602 (e.g., the user's calling the suggested number is treated as an implicit acceptance of the suggested number to the contact).

[0158] 6B also includes a user interface object 604 (labeled "ignore") associated with the suggested number. A user selection of the user interface object 604 may cause the device 500 to cease displaying the user interface object 602. This withdrawal may eliminate the option to add the number to a contact. Selection of the user interface object 604 may cause the device 500 to change the state of the suggested number from the suggested state 540 to a rejected state 560. In the rejected state 560, the device 500 may be configured to no longer display or suggest the suggested number in association with this contact.

[0159] Additionally, the second user interface in FIG. 6B includes a message portion 608 (labeled “Related Email”) that includes the portion of the message for which the suggested number was identified by device 500. Thus, in providing an interface for reviewing the suggested contact information, the user interface of FIG. 6B can provide the user with a message context associated with the suggested contact information. As shown in FIG. 6B, device 500 can display a limited portion of the email that is related to the portion that includes the mobile phone number. When the user selects the displayed portion of the message, device 500 can cause a message application (e.g., email client module 140) to open the entire email to the user. In some embodiments, the entire email may be displayed along with the suggested contact information in a user interface equivalent to that shown in FIG. 6D.

[0160] Figure 6C illustrates a user interface that is displayed in response to a user selecting the "edit" user interface object in Figure 6A. The edit user interface object also allows the user to directly call the suggested number represented by user interface object 610. User interface object 610 is highlighted (i.e., bolded) to indicate that the number is in the suggested state 540. Any suitable visual indication may be used to indicate that user interface object 610 is in the suggested state 540.

[0161] FIG. 6D illustrates a screen that a user may view upon opening a message on device 500 (e.g., an email displayed by email client module 140) with device 500 having suggested contact information identified in the message. The user interface of FIG. 6D includes a suggestions portion 612 and a message portion 614. Message portion 614 includes the content of the message received by device 500. Suggestions portion 612 includes a user interface object corresponding to the identified entity ("John Appleseed"), a user interface object corresponding to the identified contact information ("405-123-6633"), and a user interface object 618 (labeled "Add to Contacts") associated with the identified contact information. User interface object 618, when selected, causes the device to add the suggested number to a contact in the add state 550. Suggestions portion 612 includes a user interface object 620 (labeled "Ignore") associated with the identified contact information. When selected, user interface object 620 causes device 500 to change the state of the identified contact information from suggested state 540 to rejected state 560. In rejected state 560, device 500 may be configured to no longer display or suggest suggested contact information in association with this contact. Selecting identified contact information 616 in the suggestions portion 612 above the "Ignore" and "Add to Contacts" tiles can result in a user interface corresponding to the contact associated with the identified entity. For example, device 500 can present contact information for "John Appleseed" in a user interface corresponding to that shown in FIG. 6A in this embodiment.

[0162] FIG. 6E illustrates a screen that a user may view upon opening a message on device 500 (e.g., an email displayed by email client module 140) with device 500 having suggested event information identified within the message. The user interface of FIG. 6E includes a suggestions portion 620 and a message portion 622. Message portion 622 includes the content of the message received by device 500. Suggestions portion 620 includes a user interface object corresponding to the identified event information ("Dinner", "Sushi Restaurant", "Friday, March 7", or "9:50 PM") and a user interface object 626 (labeled "Add to Calendar") associated with the identified event information. User interface object 626, when selected, causes device 500 to add the suggested event information to a calendar event in added state 550. Suggestions portion 620 includes a user interface object 628 (labeled "Ignore"), when selected, causes device 500 to change the state of the identified event information from suggested state 540 to rejected state 560. In the reject state 560, the device 500 may be configured to no longer display or suggest the suggested event information in association with this calendar event. Selecting the identified event information 624 in the suggestions portion 620 above the “Ignore” and “Add to Calendar” tiles may result in a user interface (not shown) corresponding to the calendar event associated with the identified event information (e.g., displayed by the contacts module 137) from which the user can select a user interface object to add the suggested event information to the calendar event in the add state 550.

[0163] In some examples, the device may display a calendar event on the device's calendar. In this case, the calendar event corresponds to event information in the proposed state 540. Calendar events in the proposed state 540 displayed on the device's calendar may optionally be grayed out to indicate that they are in the proposed state 540. The device may display details of the calendar event (e.g., when the user activates an affordance associated with the calendar event). The details of the calendar event include at least a portion of the source of the event information (e.g., a portion of the communication, such as an email, that is the basis for the proposed event information). Alternatively or additionally, the device may display an affordance that, when activated, causes the device to display at least a portion of the communication (e.g., an email) that is the basis for the proposed event information. The displayed details of the proposed calendar event may also optionally include an affordance to ignore (or reject) the proposed calendar event or to accept the proposed calendar event. Thus, the user can see the proposed calendar event on the device's calendar and the user can quickly and efficiently reject or accept the proposed calendar event.

[0164] FIG. 6F illustrates a screen that a user may see upon opening a message on device 500 (e.g., an email displayed by email client module 140) with device 500 having multiple suggested contacts and / or calendar events identified in the message. The user interface of FIG. 6F includes a suggestions portion 630 and a message portion 632. Message portion 632 includes the contents of the message as received by device 500. Suggestions portion 630 further includes a user-selectable area that, if selected, causes device 500 to display a subsequent user interface having a list of multiple instances of the identified contact or event information, as shown in FIG. 6G. By limiting suggestions portion 630 of FIG. 6F to a single banner rather than incorporating all of the suggestions of FIG. 6G within the user interface of FIG. 6F, the suggestions portion of FIG. 6F can be prevented from interfering with the user's ability to see and read the message in the message portion.

[0165] FIG. 6G illustrates a subsequent user interface having a list of suggested contact or event information identified in the message associated with the user interface of FIG. 6F. As shown in FIG. 6G, the suggestions are organized by type (e.g., suggested calendar events are grouped and suggested contacts are grouped). Each suggestion includes the "ignore" as well as "add to contacts" and "add to calendar" functionality described above. The user interface of FIG. 6G also includes a user interface object 634 ("add all") that, when selected, causes the device 500 to add each of the multiple instance groupings of identified contact or event information (e.g., the two suggested calendar events shown in FIG. 6G) to the corresponding contact or calendar event in the add state 550.

[0166] 7A and 7B are flow diagrams of an example process for generating suggested contacts, according to some embodiments, that may be performed on an electronic device (e.g., device 500).

[0167] The electronic device may receive (702) a message (e.g., FIG. 6D , email in message portion 614) and identify (704) an entity (e.g., FIG. 6D , “John Appleseed”) and contact information associated with the entity (e.g., FIG. 6D , “405-123-6633”) in the received message. The device may determine (722) that a contact (e.g., FIG. 5A , contact 530A) associated with the identified entity does not exist among multiple contacts in a database (e.g., storage on device 500, such as an address book database). In response to this determination (724), the device may create a contact associated with the entity. The created contact includes the contact information and an indication (e.g., metadata) that the created contact is a suggested contact (e.g., in suggested state 540). It should be noted that if the device generates the contact "John Appleseed" as a suggested contact, then each item of contact information in the contact may be shown as a suggested item of contact information and stored in suggested state 540, or the entire contact as a whole may be shown as a suggested contact and stored in suggested state 540. It should also be noted that any message on the device, such as an outgoing or incoming message, may be analyzed using the disclosed process.

[0168] In some embodiments, the identified entity is a name and the identified contact information is a phone number, an address, a business network, or a social network handle (706).

[0169] In some embodiments, the device can identify unstructured content in a message by recognizing a signature block in the message. For example, to identify entities and associated contact information in the message, the device can identify a signature block in the message and analyze the identified signature block for entities and contact information (708). The message may include an email, and the signature block may be a signature of the email (710). The email may include one or more previous emails in an email thread, and identifying the email signature may include analyzing the one or more previous emails in the email thread (712). By deploying a quoting layer for the email, the device can avoid incorrectly associating the location of contact information in various emails in the email thread.

[0170] In some embodiments, the device can identify unstructured content in a message by searching for deterministic phrases with a data detector. For example, to identify entities and associated contact information in a message, the device can identify one or more phrases in the message based on a collection of predefined phrases and analyze the one or more identified phrases for entities and contact information (714). The device can update the collection of predefined phrases across the network (716), which allows the device to continue to use accurate phrases. The device can also downgrade one or more of the predefined phrases as a result of a request to reject suggested contacts (718). That is, if a user continues to reject identified suggestions due to the use of certain phrases, it may be an indication that those phrases are inaccurate. The device can also generate one or more of the predefined phrases by cross-correlating the contact information in the database with language associated with contact information on the electronic device (e.g., messages, calendar events, etc.) (720). In this manner, the device can determine which accurate language in a message containing contact information will, for example, cause a user to create or update a contact with the contact information.

[0171] In some embodiments, the suggested contacts are searchable in terms of the data structure of Figure 5 A. For example, the device may receive a request for contacts (e.g., by a user searching for contacts via an application on the device) and search for suggested contacts in response to the request for contacts (726).

[0172] In some embodiments, in response to creating the contact, the device can refrain from storing the suggested contact in a remote database on the network (728). For example, if the suggested contact is in the proposed state 540, the device can refrain from promoting the contact to an update or sync service (e.g., an application on the device) that allows the contact to be updated to multiple clients on the network.

[0173] In some embodiments, the device may receive a request to add a suggested contact to a database (e.g., FIG. 6D, “Add to Contacts” 618) and, in response to the request, store the generated contact in the database (e.g., change the state of the contact from suggested 540 to added 550) without indicating that the generated contact is a suggested contact (730). In response to the request to add a suggested contact to a database, the device may store the generated contact in a remote database on the network (732) without indicating that the generated contact is a suggested contact, for example, by promoting the contact to an update or sync service.

[0174] In some embodiments, the device may receive a request to reject a suggested contact (e.g., FIG. 6D, "Ignore" 620) and, in response to the request to reject a suggested contact, prevent future suggested contacts from being generated as a result of the entity and contact information being identified in future messages (734). This is accomplished by storing rejected contacts in the rejected state 560 so the device knows which ones have already been rejected.

[0175] 8A and 8B are flow diagrams of an example process for updating an existing contact with suggested items of contact information, according to some embodiments, the process may be performed on an electronic device (e.g., device 500).

[0176] The electronic device receives (802) a message (e.g., FIG. 6D , email in message portion 614) and identifies (804) an entity (e.g., FIG. 6D , “John Appleseed”) and an item of contact information associated with the entity (e.g., FIG. 6D , “405-123-6633”) in the received message. The device may determine (822) that a contact (e.g., FIG. 5A , contact 530A) associated with the identified entity is present among multiple contacts in a database and that the contact does not include the identified item of contact information. In response to this determination (824), the device may update the contact to include the item of contact information and an indication (e.g., metadata) that the item of contact information is a suggested item of contact information (e.g., in suggested state 540). It should also be noted that any message on the device, such as an incoming or outgoing message, may be analyzed using the disclosed processes.

[0177] In some embodiments, the identified entity is a name and the identified item of contact information is a phone number, an address, a business network, or a social network handle (806).

[0178] In some embodiments, the device can identify unstructured content in a message by recognizing a signature in the message. For example, to identify entities and associated items of contact information in the message, the device can identify a signature block in the message and analyze the identified signature block for entities and items of contact information (808). The message can include an email, and the signature block can be a signature of the email (810). The email can include one or more previous emails in an email thread, and identifying the email signature can include analyzing the one or more previous emails in the email thread (812). By deploying a quoting layer for the email, the device can avoid incorrectly associating locations of contact information in various emails in the email thread.

[0179] In some embodiments, the device can identify unstructured content in a message by searching for deterministic phrases with a data detector. For example, to identify entities and associated items of contact information in a message, the device can identify one or more phrases in the message based on a collection of predefined phrases and analyze the one or more identified phrases for entities and items of contact information (814). The device can update the collection of predefined phrases across the network (816), which allows the device to continue to use accurate phrases. The device can also downgrade one or more of the predefined phrases as a result of a request to reject suggested items of contact information (818). That is, if a user continues to reject identified suggestions due to the use of certain phrases, it may be an indication that those phrases are inaccurate. The device can also generate one or more of the predefined phrases by cross-correlating the contact information in the database with language associated with the contact information on the electronic device (e.g., messages, calendar events, etc.) (820). In this manner, the device can determine which accurate language in a message containing contact information will, for example, cause a user to create or update a contact with the contact information.

[0180] In some embodiments, the suggested contacts are searchable in terms of the data structure of Figure 5 A. For example, the device may receive a request for a contact (e.g., by a user searching for a contact via an application on the device) and retrieve suggested items of contact information in response to the request for the contact (826).

[0181] In some embodiments, the device can refrain from storing the suggested item of contact information in a remote database on the network in response to updating the contact (828). When the suggested item of contact information is in the proposed state 540, the device can refrain from promoting the item of contact information to an update or sync service (e.g., an application on the device) that allows the contact to be updated for multiple clients on the network.

[0182] In some embodiments, the device may receive a request to add a suggested item of contact information to a database (e.g., FIG. 6B, “Add to Contacts” 602) and, in response to the request, store the updated contact in the database (e.g., change the state of the contact information from suggested state 540 to added state 550) without indicating that the item of contact information is a suggested item of contact information (830). In response to the request to add the suggested item of contact information to a database, the device may store the updated contact in a remote database on the network (832), for example, by promoting the contact information to an update / sync service.

[0183] In some embodiments, the device receives a request to reject a suggested item of contact information (e.g., FIG. 6B, "Ignore" 604) and, in response to the request to reject the suggested item of contact information, can prevent the contact from being updated with the suggested item of contact information in future messages as a result of the entity and the item of contact information being identified in future messages (834). This is accomplished by storing the rejected contact information in the rejected state 560 so the device knows what has already been rejected.

[0184] 9A and 9B are flow diagrams of an example process for displaying contacts with suggested contact information according to some embodiments, the process may be performed on an electronic device with a display (e.g., device 500).

[0185] The electronic device may receive (902) a message (e.g., FIG. 6D , email in message portion 614) and identify (904) an entity (e.g., FIG. 6D , “John Appleseed”) and contact information associated with the entity (e.g., FIG. 6D , “405-123-6633”) in the received message. The device may generate (906) an indication (e.g., metadata) that the identified contact information is suggested contact information and display (908) a first user interface (e.g., FIG. 6A ) corresponding to the contact associated with the entity. The first user interface may include a first user interface object (e.g., “Suggestion”) that indicates that the identified contact information is suggested contact information based on the generated indication.

[0186] In some embodiments, the device may prevent an input corresponding to a selection of suggested contact information from invoking an application to contact the entity (e.g., FIG. 6A, selecting a suggested number does not call that number) (910).

[0187] In some embodiments, the device may detect an input corresponding to a selection of the suggested contact information in the first user interface and, in response to the detection, display a second user interface (e.g., FIG. 6B) including a second user interface object associated with the identified contact information (e.g., FIG. 6B, “Add to Contacts” 602) that, when selected, causes the electronic device to add the identified contact information to the database (912). The second user interface may include a third user interface object associated with the identified contact information (e.g., FIG. 6B, “Ignore” 604) that, when selected, causes the electronic device to cease displaying the second user interface object (914). Displaying the second user interface may cease displaying the first user interface (916). The device may cease displaying the first user interface object in response to adding the identified contact information to the database (918).

[0188] In some embodiments, the second user interface may display at least a portion of the message (e.g., FIG. 6B, “Related Emails”) (920). The device may detect an input corresponding to a selection of the displayed message and, in response to the detection, may invoke an application (e.g., email client module 140) that opens the message (e.g., FIG. 6D) (922). The message may be an email and the application may be an email application (924).

[0189] In some embodiments, the device may detect input corresponding to a selection of the suggested contact information in the second user interface and, in response to the detection, may invoke an application (e.g., the phone module 138) that uses the identified contact information to contact the entity (926). In response to detecting input corresponding to a selection of the suggested contact information in the second user interface, the device may add the identified contact information to a database (e.g., change the state of the contact information from the suggested state 540 to the added state 550) (928). In response to adding the identified contact information to the database, the device may cease displaying the first user interface object (918).

[0190] 10 shows a flow diagram of an example process for displaying suggested contact information with a message according to some embodiments. The process may be performed in an electronic device with a display (e.g., device 500).

[0191] The electronic device may receive (1002) a message (e.g., FIG. 6D, email in message portion 614) and identify (1004) an entity (e.g., FIG. 6D, "John Appleseed") and contact information associated with the entity (e.g., FIG. 6D, "405-123-6633") in the received message. The message may be an email (1006). The identified entity may be a name and the identified contact information may be a phone number, an address, a business network, or a social network handle (1008).

[0192] The device may display 1010 a first user interface (e.g., FIG. 6D ) corresponding to the received message. The first user interface may include a first portion (e.g., FIG. 6D , message portion 614) that includes the content of the message received by the electronic device, and a second portion ( FIG. 6D , suggestions portion 612) that includes a first user interface object corresponding to the identified entity (e.g., FIG. 6D , “John Appleseed”), a second user interface object corresponding to the identified contact information (e.g., FIG. 6D , “405-123-6633”), and a third user interface object associated with the identified contact information (e.g., FIG. 6D , “Add to Contacts” 618) that, if selected, causes the electronic device to add the identified contact information to a database (e.g., store the contact information as a contact). The second portion may include a fourth user interface object (e.g., FIG. 6D, “Ignore” 620) associated with the identified contact information that, when selected, causes the electronic device to cease displaying the third user interface object (1012).

[0193] 11A and 11B are flow diagrams of an example process for generating suggested calendar events, according to some embodiments, that may be performed on an electronic device (e.g., device 500).

[0194] The electronic device may receive (1102) a message (e.g., FIG. 6E , email in message portion 622) and identify (1104) event information in the received message (e.g., FIG. 6E , “Dinner,” “Sushi Restaurant,” “Friday, March 7,” or “9:50 PM”). The device may generate (1122) a calendar event (e.g., FIG. 5B , calendar event 530B) associated with the identified event information, where the generated calendar event includes the event information and an indication (e.g., metadata) that the generated calendar event is a suggested calendar event (e.g., is in the suggested state 540).

[0195] In some embodiments, the identified event information is a date and time (1106).

[0196] In some embodiments, the device can identify structured content in a message by using templates configured to recognize contact information in a particular format provided by such a message. For example, to identify event information in a message, the device can identify a format of the content in the message, identify a template from a collection of predefined templates configured to recognize event information in the format of the content in the message, and analyze the content for the event information with the identified template (1108). The message can include an email and the content can include an appointment (e.g., FIG. 6E) (1110). The device can update the collection of predefined templates over the network (1112), which allows the device to continue using accurate templates.

[0197] In some embodiments, the device can identify unstructured content in a message by searching for references to event information with a data detector. For example, to identify event information in a message, the device can identify one or more references to dates and times in the message based on a collection of predefined references to dates and times, and analyze the one or more identified references to dates and times for event information (1114). The device can update the collection of predefined references to dates and times over the network (1116), which allows the device to continue to use accurate references. The device can downgrade one or more of the predefined references to dates and times as a result of a request to reject a suggested calendar event (1118). That is, if a user continues to reject suggestions identified by the use of specific references to dates and times, these references may be an indication of inaccuracy. The device can generate one or more of the predefined references to dates and times by cross-correlating event information in a database including multiple calendar events with language associated with the event information on the electronic device (1120). In this way, the device can better determine which language in a message containing event information will, for example, cause a user to create or update a calendar event with the event information.

[0198] In some embodiments, the suggested calendar events are searchable in terms of the data structure of Figure 5. For example, the device may receive a request for a calendar event (e.g., by a user searching for a calendar event via an application on the device) and retrieve (1124) the suggested calendar events in response to the request for the calendar event.

[0199] In some embodiments, in response to generating the calendar event, the device can refrain from storing the proposed calendar event in a remote database on the network (1126). For example, if the proposed calendar event is in the proposed state 540, the device can refrain from promoting the calendar event to an update or sync service (e.g., an application on the device) that allows the calendar event to be updated to multiple clients on the network.

[0200] In some embodiments, the device may receive a request to add a suggested calendar event to a database including a plurality of calendar events (e.g., FIG. 6E, “Add to Calendar” 626) and, in response to the request, store the generated calendar event in the database without indicating that the generated calendar event is a suggested calendar event (e.g., change the state of the calendar event from suggested 540 to added 550) (1128). In response to the request to add the suggested calendar event to the database, the device may store the generated calendar event in a remote database on the network without indicating that the generated calendar event is a suggested calendar event (1130), for example, by promoting the calendar event to an update or synchronization service.

[0201] In some embodiments, the device may receive a request to reject a proposed calendar event (e.g., FIG. 6E, "Ignore" 628) and, in response to the rejection request, may prevent the proposed calendar event from being generated in the future as a result of the event information being specified in future messages (1132). This is accomplished by storing rejected events in the rejected state 560 so the device knows what has already been rejected.

[0202] 12 illustrates a flow diagram of an example process for displaying suggested event information along with a message, according to some embodiments. The process may be performed in an electronic device with a display (e.g., device 500).

[0203] The electronic device can receive 1202 a message (e.g., FIG. 6E, email in message portion 622) and identify 1204 event information (e.g., FIG. 6E, "Dinner," "Sushi Restaurant," "Friday, March 7," or "9:50 PM") in the received message. The message can be an email 1206. The identified event information can be a date and time 1208.

[0204] The device may display a first user interface (e.g., FIG. 6E) corresponding to the received message (1210). The first user interface may include a first portion (e.g., FIG. 6E, message portion 622) that includes the content of the message received by the electronic device, and a second portion (e.g., FIG. 6E, suggestions portion 620) that includes a first user interface object corresponding to the identified event information (e.g., FIG. 6E, "Dinner," "Sushi Restaurant," "Friday, March 7," or "9:50 PM") and a second user interface object (e.g., FIG. 6E, "Add to Calendar" 626) associated with the identified event information that, when selected, causes the electronic device to add the identified event information to a database that includes multiple calendar events (e.g., stores the event information as a calendar event). The second portion may include a third user interface object (e.g., FIG. 6E, "Ignore" 628) associated with the identified event information that, when selected, causes the electronic device to cease displaying the second user interface object (1212).

[0205] 13 is a flow diagram of an example process for displaying multiple suggested contact or event information along with a message, according to some embodiments. The process may be performed in an electronic device with a display (e.g., device 500).

[0206] The electronic device may receive (1302) a message (e.g., the email in FIG. 6F, message portion 632) and identify (1304) multiple instances of contact or event information in the received message (e.g., FIG. 6F, “2 Events, 1 Contact” in the attached travel itinerary).

[0207] The device may display 1306 a first user interface (e.g., FIG. 6F) corresponding to the received message. The first user interface may include a first portion (e.g., FIG. 6F, message portion 632) that includes content of the message received by the electronic device and a second portion (e.g., FIG. 6F, suggestions portion 630) that, if selected, causes the electronic device to display a second user interface (FIG. 6G) that includes a list of multiple instances of the identified contact or event information.

[0208] In some embodiments, the device may detect an input corresponding to a selection of a second portion of the first user interface and, in response to the detection, display (1308) a second user interface that includes a list of multiple instances of the identified contact or event information and, for each of the multiple instances of the identified contact or event information, a first user interface object (e.g., FIG. 6G, “Add to Calendar” or “Add to Contacts”) that, if selected, causes the electronic device to add the identified information to a database (e.g., store the event information as a calendar event or the contact information as a contact). The second user interface may include a second user interface object (e.g., FIG. 6G, “Ignore”) that, when selected, causes the electronic device to cease displaying the first user interface object for each of the multiple instances of the identified contact or event information (1310). The second user interface may include a third user interface object (e.g., FIG. 6G, “Add All” 634) that, when selected, causes the electronic device to add each of the multiple instances of the identified contact or event information groupings (e.g., calendar events or contacts) to a database (1312). Displaying the second user interface may cause the first user interface to cease displaying (1314).

[0209] It should be understood that the particular order described for the operations in Figures 7A-13 is exemplary, and that the described order is not intended to indicate the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. For the sake of brevity, these details will not be repeated here. Furthermore, it should be noted that aspects of processes 700-1300 (Figures 7-13) may be incorporated into one another.

[0210] The operations of the above-mentioned information processing processes can be implemented by executing one or more functional modules of an information processing device, such as a general-purpose processor or an application-specific chip. These modules, combinations of these modules, and / or their combination with common hardware (e.g., as described above with respect to Figures 1A, 1B, and 3) are all within the scope of protection of the present invention.

[0211] 14 illustrates example functional blocks of an electronic device 1400 that, in some embodiments, performs the features described above. As shown in FIG. 14, electronic device 1400 includes a display unit 1402 configured to display graphical objects, a touch-sensitive surface unit 1404 configured to receive user gestures, one or more RF units 1406 configured to detect and communicate with external electronic devices, and a processing unit 1408 coupled to display unit 1402, touch-sensitive surface unit 1404, and RF unit 1406.

[0212] In some embodiments, processing unit 1408 is configured to support operating system 1410 that executes one or more applications 1412. In some embodiments, processing unit 1408 is configured to receive data from RF unit 1406 representing an external device within wireless communication range, display a graphical user interface affordance on touch-sensitive surface unit 1404, and, in response to detecting a contact on the displayed affordance, launch an application on device 1400 that corresponds to the application running on the external device.

[0213] 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 embodiments described. It will be understood by those skilled in the art that the functional blocks described in FIG. 14 are optionally combined or separated into sub-blocks to implement the principles of the various embodiments described. Thus, the description in this specification optionally supports any possible combination or division or further definition of the functional blocks described in this specification.

[0214] 15 illustrates example functional blocks of another electronic device 1500 that, in some embodiments, performs the features described above. As shown in FIG. 14, electronic device 1500 includes a display unit 1402 configured to display graphical objects, a touch-sensitive surface unit 1504 configured to receive user gestures, one or more RF units 1506 configured to detect and communicate with external electronic devices, and a processing unit 1508 coupled to display unit 1502, touch-sensitive surface unit 1504, and RF unit 1506.

[0215] In some embodiments, the processing unit 1508 is configured to support one or more units 1510-1520 performing various functions described above. For example, the receiving unit 1510 is configured to perform one or more of the receiving functions described above (e.g., receiving a message). The identifying unit 1512 is configured to perform one or more of the identifying functions described above (e.g., identifying an entity and contact information associated with the entity in the received message, identifying event information in the received message, or identifying multiple instances of contact or event information in the received message). The determining unit 1514 is configured to perform one or more of the determining functions described above (e.g., determining that a contact associated with the identified entity does not exist among the multiple contacts in the database, determining that a contact associated with the identified entity exists among the multiple contacts in the database, and determining that the contact does not include a specified item of contact information). The generating unit 1516 is configured to perform one or more of the generating described above (e.g., in response to the determination, generating a contact associated with the entity, generating an indication that the identified contact information is suggested contact information, and generating a calendar event associated with the identified event information). The updating unit 1518 is configured to perform one or more of the updating described above (e.g., in response to the determination, updating the contact to include an item of contact information and an indication that the item of contact information is a suggested item of contact information). The displaying unit 1520 is configured to perform one or more of the displaying described above (e.g., displaying, e.g., on the display unit 1502, a first user interface corresponding to the entity or a contact associated with the received message).

[0216] 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 embodiments described. It will be understood by those skilled in the art that the functional blocks described in FIG. 15 are optionally combined or separated into sub-blocks to implement the principles of the various embodiments described. Thus, the description in this specification optionally supports any possible combination or division or further definition of the functional blocks described in this specification.

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

[0218] 16 , the electronic device 1600 includes one or more RF units 1606 configured to communicate with an external electronic device, and a processing unit 1608 coupled to the RF unit 1606. In some embodiments, the processing unit 1608 includes a receiving unit 1610, an identifying unit 1612, a determining unit 1614, a generating unit 1616, an analyzing unit 1618, an updating unit 1620, a downgrading unit 1622, a searching unit 1624, a storage canceling unit 1626, a storage unit 1628, and a prevention unit 1630.

[0219] The processing unit 1608 is configured to receive a message (e.g., by the receiving unit 1610), identify an entity and contact information associated with the entity in the received message (e.g., by the identifying unit 1612), determine (e.g., by the determining unit 1614) that a contact associated with the identified entity does not exist among the multiple contacts in the database, and in response to the determination, generate (e.g., by the generating unit 1616) a contact associated with the entity, where the generated contact includes the contact information and an indication that the generated contact is a suggested contact.

[0220] In some embodiments, the identified entity includes a name and the identified contact information includes a phone number, an address, a business, or a social networking handle.

[0221] In some embodiments, to identify, the processing unit 1608 identifies the signature block of the message (e.g., via an identifying unit 1612); It is further configured to analyze (eg, by the analysis unit 1618) the identified signature blocks for entity and contact information.

[0222] In some embodiments, the message comprises an email and the signature block comprises a signature of the email.

[0223] In some embodiments, the email includes one or more previous emails in the email thread, and the processing unit 1608 is further configured to analyze (e.g., via the analysis unit 1618) the one or more previous emails in the email thread to identify the signature of the email.

[0224] In some embodiments, to identify, the processing unit 1608 is further configured to identify (e.g., by the identification unit 1612) one or more phrases in the message based on a collection of predetermined phrases and analyze (e.g., by the analysis unit 1618) the one or more identified phrases for entity and contact information.

[0225] In some embodiments, the processing unit 1608 is further configured to update the collection of predefined phrases over the network (eg, via an update unit 1620).

[0226] In some embodiments, the processing unit 1608 is further configured to downgrade (e.g., via the downgrading unit 1622) one or more of the predefined phrases as a result of the request to reject the suggested contact.

[0227] In some embodiments, the processing unit 1608 is further configured to generate (e.g., via the generation unit 1616) one or more of the predefined phrases by cross-correlating the contact information in the database with language associated with the contact information on the electronic device.

[0228] In some embodiments, the processing unit 1608 is further configured to receive a request for contacts (e.g., via the receiving unit 1610) and search for suggested contacts in response to the request for contacts (e.g., via the searching unit 1624).

[0229] In some embodiments, the processing unit 1608 is further configured to refrain from storing the suggested contact in a remote database on the network (e.g., via the storage discontinuation unit 1626) in response to generating the contact.

[0230] In some embodiments, the processing unit 1608 is further configured to receive (e.g., via the receiving unit 1610) a request to add the suggested contact to the database, and in response to the request to add the suggested contact to the database, store (e.g., via the storage unit 1628) the generated contact in the database without indicating that the generated contact is a suggested contact.

[0231] In some embodiments, the processing unit 1608 is further configured to store (e.g., via the storage unit 1628) the generated contact in a remote database on the network in response to a request to add the suggested contact to the database, without indicating that the generated contact is a suggested contact.

[0232] In some embodiments, the processing unit 1608 is further configured to receive (e.g., via the receiving unit 1610) a request to reject the suggested contact, and, in response to the request to reject the suggested contact, to prevent (e.g., via the prevention unit 1630) future suggested contacts from being generated as a result of the entity and contact information being identified in future messages.

[0233] The operations described above with reference to Figures 7A and 7B are optionally performed by components shown in Figures 1A and 1B, or 16. For example, the receive operation at block 702, the identify operation at block 704, the determine operation at block 722, the generate operation at block 724, the receive operation at block 726, and the store operation at block 728 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 in event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to applications 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on a user interface. When a respective predefined event or sub-event is detected, the event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call a data updater 176 or an object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

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

[0235] 17, the electronic device 1700 includes one or more RF units 1706 configured to communicate with an external electronic device, and a processing unit 1708 coupled to the one or more RF units 1706. In some embodiments, the processing unit 1708 includes a receiving unit 1710, an identifying unit 1712, a determining unit 1714, a generating unit 1716, an analyzing unit 1718, an updating unit 1720, a downgrading unit 1722, a searching unit 1724, a storing cancellation unit 1726, a storing unit 1728, and a prevention unit 1730.

[0236] The processing unit 1780 is configured to receive a message (e.g., by the receiving unit 1710), identify an entity and an item of contact information associated with the entity in the received message (e.g., by the identifying unit 1712), determine (e.g., by the identifying unit 1714) that a contact associated with the identified entity is present among a plurality of contacts in the database and that the contact does not include the identified item of contact information, and, in response to the determination, update the contact (e.g., by the updating unit 1720) to include the item of contact information and an indication that the item of contact information is a suggested item of contact information.

[0237] In some embodiments, the identified entity includes a name and the identified items of contact information include a phone number, an address, a business network or a social network handle.

[0238] In some embodiments, to identify, the processing unit 1708 is further configured to identify a signature block of the message (e.g., via the identification unit 1712) and analyze the identified signature block for items of entity and contact information (e.g., via the analysis unit 1718).

[0239] In some embodiments, the message comprises an email and the signature block comprises a signature of the email.

[0240] In some embodiments, the email includes one or more previous emails in the email thread, and the processing unit 1708 is further configured to analyze (e.g., via the analysis unit 1718) the one or more previous emails in the email thread to identify the signature of the email.

[0241] In some embodiments, to identify, the processing unit 1708 is further configured to identify (e.g., by the identification unit 1712) one or more phrases in the message based on a collection of predetermined phrases, and analyze (e.g., by the analysis unit 1718) the one or more identified phrases for items of entity and contact information.

[0242] In some embodiments, the processing unit 1708 is further configured to update the collection of predefined phrases over the network (eg, via an update unit 1720).

[0243] In some embodiments, the processing unit 1708 is further configured to downgrade (e.g., via the downgrading unit 1722) one or more of the predefined phrases as a result of a request to reject a suggested item of contact information.

[0244] In some embodiments, the processing unit 1708 is further configured to generate (e.g., by the generation unit 1716) one or more of the predefined phrases by cross-correlating the contact information in the database with language associated with the contact information on the electronic device.

[0245] In some embodiments, the processing unit 1708 is further configured to receive a request for a contact (e.g., via the receiving unit 1710) and to search for suggested items of contact information in response to the request for the contact (e.g., via the searching unit 1724).

[0246] In some embodiments, the processing unit 1708 is further configured to refrain from storing the suggested item of contact information in a remote database on the network (e.g., via the storage discontinuation unit 1726) in response to updating the contact.

[0247] In some embodiments, the processing unit 1708 is further configured to receive (e.g., via the receiving unit 1710) a request to add the suggested item of contact information to the database, and, in response to the request to add the suggested item of contact information to the database, store (e.g., via the storage unit 1728) the updated contact in the database, without indicating that the item of contact information is a suggested item of contact information.

[0248] In some embodiments, the processing unit 1708 is further configured to store (e.g., via the storage unit 1728) the updated contact in a remote database on the network in response to a request to add the suggested item of contact information to the database, without indicating that the item of contact information is a suggested item of contact information.

[0249] In some embodiments, the processing unit 1708 is further configured to receive (e.g., via the receiving unit 1710) a request to reject the suggested item of contact information, and, in response to the request to reject the suggested item of contact information, to prevent (e.g., via the prevention unit 1730) the contact from being updated with the suggested item of contact information in the future as a result of the entity and the item of contact information being identified in a future message.

[0250] The operations described above with reference to Figures 8A and 8B are optionally performed by components shown in Figures 1A and 1B or 17. For example, the receiving operation at block 802, the identifying operation at block 804, the determining operation at block 822, and the updating operation at block 824 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 in event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on the user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

[0251] According to some embodiments, FIG. 18 illustrates a functional block diagram of an electronic device 1800 configured according to the principles of the various embodiments described. The functional blocks of this device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various embodiments described. It will be understood by those skilled in the art that the functional blocks described in FIG. 18 are optionally combined or separated into sub-blocks to carry out the principles of the various embodiments described. Thus, the description herein optionally supports any possible combination or division or further definition of the functional blocks described herein.

[0252] 18 , the electronic device 1800 includes a display unit 1802 configured to display graphical objects, one or more RF units 1806 configured to communicate with external electronic devices, and a processing unit 1808 coupled to the display unit 1802 and the one or more RF units 1806. In some embodiments, the processing unit 1808 includes a receiving unit 1810, an identifying unit 1812, a generating unit 1814, a display enabling unit 1816, a preventing unit 1818, a detecting unit 1820, a calling unit 1822, and an adding unit 1824.

[0253] The processing unit 1808 is configured to receive a message (e.g., by the receiving unit 1810), identify an entity and contact information associated with the entity in the received message (e.g., by the identifying unit 1812), generate (e.g., by the generating unit 1814) an indication that the identified contact information is suggested contact information, and enable (e.g., by the display enabling unit 1816) display of a first user interface corresponding to the contact associated with the entity, the first user interface including a first user interface object indicating that the identified contact information is suggested contact information based on the generated indication.

[0254] In some embodiments, the processing unit 1808 is further configured to prevent (e.g., via the prevention unit 1818) an input corresponding to a selection of the suggested contact information from invoking an application that contacts the entity.

[0255] In some embodiments, the processing unit 1808 is further configured to detect (e.g., by the detection unit 1820) an input corresponding to a selection of the suggested contact information in the first user interface, and, in response to detecting the input corresponding to a selection of the suggested contact information in the first user interface, enable (e.g., by the display enabling unit 1816) the display of a second user interface including a second user interface object associated with the identified contact information that, when selected, causes the electronic device to add the identified contact information to the database.

[0256] In some embodiments, the second user interface includes a third user interface object associated with the identified contact information that, when selected, causes the electronic device to cease displaying the second user interface object.

[0257] In some embodiments, the display of the second user interface ceases the display of the first user interface.

[0258] In some embodiments, the second user interface displays at least a portion of the message.

[0259] In some embodiments, the processing unit 1808 is further configured to detect (e.g., via the detection unit 1820) an input corresponding to selection of the displayed message, and, in response to detecting the input corresponding to selection of the displayed message, invoke (e.g., via the invocation unit 1822) an application that opens the message.

[0260] In some embodiments, the message comprises an email and the application comprises an email application.

[0261] In some embodiments, the processing unit 1808 is further configured to detect (e.g., via the detection unit 1820) an input corresponding to a selection of the suggested contact information in the second user interface, and, in response to detecting the input corresponding to a selection of the suggested contact information in the second user interface, invoke (e.g., via the invocation unit 1822) an application that contacts the entity using the identified contact information.

[0262] In some embodiments, the processing unit 1808 is further configured to add the identified contact information to the database (e.g., by the adding unit 1824) in response to detecting an input corresponding to a selection of the suggested contact information in the second user interface.

[0263] In some embodiments, the processing unit 1808 is further configured to cease displaying the first user interface object in response to adding the identified contact information to the database.

[0264] 9A and 9B are optionally performed by components shown in FIGS. 1A and 1B or 18. For example, the receive operation at block 902, the identify operation at block 904, the generate operation at block 906, and the display operation at block 908 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on a user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

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

[0266] 19 , the electronic device 1900 includes a display unit 1902 configured to display graphical objects, one or more RF units 1906 configured to communicate with external electronic devices, and a processing unit 1908 coupled to the display unit 1902 and the one or more RF units 1906. In some embodiments, the processing unit 1908 includes a receiving unit 1910, an identifying unit 1912, and a display enabling unit 1914.

[0267] The processing unit 1908 is configured to receive a message (e.g., by the receiving unit 1910), identify entities and contact information associated with the entities in the received message (e.g., by the identifying unit 1912), and enable (e.g., by the display enabling unit 1914) the display of a first user interface corresponding to the received message, the first user interface including a first portion including content of the message received by the electronic device and a second portion including a first user interface object corresponding to the identified entity, a second user interface object corresponding to the identified contact information, and a third user interface object associated with the identified contact information that, if selected, causes the electronic device to add the identified contact information to a database.

[0268] In some embodiments, the second portion includes a fourth user interface object associated with the identified contact information that, when selected, causes the electronic device to cease displaying the third user interface object.

[0269] In some embodiments, the message comprises an email.

[0270] In some embodiments, the identified entity includes a name and the identified contact information includes a phone number, an address, a business network or a social network handle.

[0271] The operations described above with reference to FIG. 10 are optionally performed by components shown in FIGS. 1A and 1B or FIG. 19. For example, the receiving operation at block 1002, the identifying operation at block 1004, and the display operation at block 1010 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects a contact on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on a user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

[0272] According to some embodiments, FIG. 20 shows a functional block diagram of an electronic device 2000 configured according to the principles of the various embodiments described. The functional blocks of this device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various embodiments described. It will be understood by those skilled in the art that the functional blocks described in FIG. 20 are optionally combined or separated into sub-blocks to carry out the principles of the various embodiments described. Thus, the description in this specification optionally supports any possible combination or division or further definition of the functional blocks described in this specification.

[0273] 20, the electronic device 2000 includes one or more RF units 2006 configured to communicate with an external electronic device, and a processing unit 2008 coupled to the one or more RF units 2006. In some embodiments, the processing unit 2008 includes a receiving unit 2010, a identifying unit 2012, a generating unit 2014, an analyzing unit 2016, an updating unit 2018, a downgrading unit 2020, a searching unit 2022, a storage self-restraint unit 2024, a storage unit 2026, and a prevention unit 2028.

[0274] The processing unit 2008 is configured to receive a message (e.g., by the receiving unit 2010), identify event information in the received message (e.g., by the identifying unit 2012), and generate (e.g., by the generating unit 2014) a calendar event associated with the identified event information, where the generated calendar event includes the event information and an indication that the generated calendar event is a suggested calendar event.

[0275] In some embodiments, the identified event information includes a date and a time.

[0276] In some embodiments, for the identification, the processing unit 2008 is further configured to identify (e.g., by the identification unit 2012) a format of the content in the message, identify a template (e.g., by the identification unit 2012) from a collection of predefined templates configured to recognize the event information in the format of the content in the message, and analyze (e.g., by the analysis unit 2016) the content for the event information according to the identified template.

[0277] In some embodiments, the message comprises an email and the content comprises a reservation.

[0278] In some embodiments, the processing unit 2008 is further configured to update the collection of pre-defined templates over the network (eg, via an update unit 2018).

[0279] In some embodiments, to identify, the processing unit 2008 is further configured to identify (e.g., by the identification unit 2012) one or more references to dates and times in the message based on a collection of predetermined references to dates and times, and analyze (e.g., by the analysis unit 2016) the one or more identified references to dates and times against the event information.

[0280] In some embodiments, the processing unit 2008 is further configured to update (eg, via the updating unit 2018) the collection of predefined mentions to the date and time on the network.

[0281] In some embodiments, the processing unit 2008 is further configured to downgrade (e.g., by the downgrading unit 2020) one or more of the predetermined references to dates and times as a result of a request to reject a proposed calendar event.

[0282] In some embodiments, the processing unit 2008 is further configured to generate (e.g., by the generation unit 2014) one or more of the predefined references to dates and times by cross-correlating event information in a database including a plurality of calendar events with language associated with the event information on the electronic device.

[0283] In some embodiments, the processing unit 2008 is further configured to receive a request for a calendar event (e.g., via the receiving unit 2010) and to search for suggested calendar events (e.g., via the search unit 2022) in response to the request for the calendar event.

[0284] In some embodiments, the processing unit 2008 is further configured to refrain from storing the suggested calendar event in a remote database on the network (e.g., via the storage discontinuation unit 2024) in response to generating the calendar event.

[0285] In some embodiments, the processing unit 2008 is further configured to receive (e.g., via the receiving unit 2010) a request to add the suggested calendar event to a database including a plurality of calendar events, and in response to the request to add the suggested calendar event to the database, store (e.g., via the storage unit 2026) the generated calendar event in the database without indicating that the generated calendar event is a suggested calendar event.

[0286] In some embodiments, the processing unit 2008 is further configured to store (e.g., via the storage unit 2026) the generated calendar event in a remote database on the network in response to a request to add the suggested calendar event to the database, without indicating that the generated calendar event is a suggested calendar event.

[0287] In some embodiments, the processing unit 2008 is further configured to receive (e.g., by the receiving unit 2010) a request to reject the proposed calendar event, and, in response to the request to reject the proposed calendar event, to prevent (e.g., by the prevention unit 2028) future generation of the proposed calendar event as a result of the event information being identified in a future message.

[0288] 1A and 11B are optionally performed by components shown in FIG. 1A and 1B or FIG. 20. For example, the receiving operation at block 1102, the identifying operation at block 1104, and the generating operation at block 1122 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on a user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

[0289] According to some embodiments, FIG. 21 shows a functional block diagram of an electronic device 2100 configured according to the principles of the various embodiments described. The functional blocks of this device are optionally implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various embodiments described. It will be understood by those skilled in the art that the functional blocks described in FIG. 21 are optionally combined or separated into sub-blocks to carry out the principles of the various embodiments described. Thus, the description in this specification optionally supports any possible combination or division or further definition of the functional blocks described in this specification.

[0290] 21 , the electronic device 2100 includes a display unit 2102 configured to display graphical objects, one or more RF units 2106 configured to communicate with external electronic devices, and a processing unit 2108 coupled to the display unit 2102 and the one or more RF units 2106. In some embodiments, the processing unit 2108 includes a receiving unit 2110, an identifying unit 2112, and a display enabling unit 2114.

[0291] The processing unit 2108 is configured to receive a message (e.g., by the receiving unit 2110), identify event information in the received message (e.g., by the identifying unit 2112), and enable (e.g., by the display enabling unit 2114) the display of a first user interface corresponding to the received message, the first user interface including a first portion including content of the message received by the electronic device and a second portion including a first user interface object corresponding to the identified event information and a second user interface object associated with the identified event information that, when selected, causes the electronic device to add the identified event information to a database including multiple calendar events.

[0292] In some embodiments, the second portion includes a third user interface object associated with the identified event information that, when selected, causes the electronic device to cease displaying the second user interface object.

[0293] In some embodiments, the message comprises an email.

[0294] In some embodiments, the identified event information includes a date and a time.

[0295] The operations described above with reference to FIG. 12 are optionally performed by components shown in FIGS. 1A and 1B or FIG. 21. For example, the receiving operation at block 1202, the identifying operation at block 1204, and the display operation at block 1210 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 in event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on the user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

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

[0297] 22 , the electronic device 2200 includes a display unit 2202 configured to display graphical objects, one or more RF units 2206 configured to communicate with external electronic devices, and a processing unit 2208 coupled to the display unit 2202 and the one or more RF units 2206. In some embodiments, the processing unit 2208 includes a receiving unit 2210, an identifying unit 2212, a display enabling unit 2214, and a detecting unit 2216.

[0298] The processing unit 2208 is configured to receive a message (e.g., by the receiving unit 2210), identify multiple instances of contact or event information in the received message (e.g., by the identifying unit 2212), and enable (e.g., by the display enabling unit 2214) the display of a first user interface corresponding to the received message, the first user interface including a first portion including the content of the message received by the electronic device and a second portion that, when selected, causes the electronic device to display a second user interface including a list of multiple instances of the identified contact or event information.

[0299] In some embodiments, the processing unit 2208 is further configured to detect (e.g., by the detection unit 2216) an input corresponding to a selection of the second portion of the first user interface, and in response to detecting the input corresponding to the selection of the second portion of the first user interface, enable (e.g., by the display enabling unit 2214) the display of a second user interface including a list of multiple instances of the identified contact or event information and, for each of the multiple instances of the identified contact or event information, a first user interface object that, when selected, causes the electronic device to add the identified information to the database.

[0300] In some embodiments, the second user interface includes, for each of a plurality of instances of the identified contact or event information, a second user interface object that, when selected, causes the electronic device to cease displaying the first user interface object.

[0301] In some embodiments, the second user interface includes a third user interface object that, when selected, causes the electronic device to add each of the groupings of multiple instances of the identified contact or event information to the database.

[0302] In some embodiments, the display of the second user interface causes the display of the first user interface to cease.

[0303] The operations described above with reference to FIG. 13 are optionally performed by components shown in FIGS. 1A and 1B or 22. For example, the receive operation at block 1302, the identify operation at block 1304, and the display operation at block 1306 may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 in event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information to a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as activation of an affordance on the user interface. When a respective predefined event or sub-event is detected, event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. The event handler 190 may utilize or call the data updater 176 or the object updater 177 to update the application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be performed based on the components shown in Figures 1A and 1B.

[0304] The above description has been described with reference to specific embodiments for purposes of explanation. However, the above illustrative description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments were selected and described in order to best explain the principles of the technology and its practical application so that those skilled in the art can best utilize the various embodiments with various modifications as are suitable for the technology and the particular use contemplated.

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

[0306] As mentioned above, one aspect of the present technology is the collection and use of data available from various sources to improve the delivery to users of engaging content or any other content that may be of interest to the user. The present disclosure contemplates that in some instances, this collected data may include personal information data that uniquely identifies a particular person or that can be used to contact or locate that person. Such personal information data may include location-based data, demographic data, phone numbers, email addresses, home addresses, or any other identifying information.

[0307] This disclosure recognizes that such personal information data may be used in the present technology to benefit the user. For example, the personal information data may be used to deliver targeted content that is more likely to be of interest to the user. Thus, the use of such personal information data allows for quantitative management of the content delivered. Still further, other uses of personal information data to benefit the user are also contemplated by this disclosure.

[0308] This disclosure further contemplates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will adhere to established privacy policies and / or privacy practices. In particular, such entities must implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements to keep personal information data private and secure. For example, personal information from users should be collected for the entity's lawful and legitimate uses and should not be shared or sold except for those lawful uses. Furthermore, such collection should be carried out only after the user's informed consent is obtained. Furthermore, such entities shall take all necessary measures to protect and secure access to such personal information data and ensure that others having access to that personal information data comply with their privacy policies and procedures. Furthermore, such entities may subject themselves to third-party assessments to attest to their compliance with widely accepted privacy policies and privacy practices.

[0309] Notwithstanding the foregoing, the present disclosure also contemplates embodiments in which a user selectively blocks use of or access to personal information data. That is, the present disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, in the case of an ad delivery service, the technique may be configured to allow a user to select "opt-in" or "opt-out" of participating in the collection of personal information data during registration for the service. In another example, a user may choose not to provide location information for a desired content delivery service. In yet another example, a user may choose not to provide precise location information but to allow transmission of location zone information.

[0310] Thus, while this disclosure broadly encompasses the use of personal information data to implement one or more of the various disclosed embodiments, this disclosure also contemplates that the various embodiments may also be implemented without requiring access to such personal information data. That is, various embodiments of the technology are not rendered inoperable by the absence of all or a portion of such personal information data. For example, content may be selected and delivered to a user by inferring a selection based on non-personal information data or minimal personal information (e.g., content requested by a device associated with the user, other non-personal information available to the content delivery service, or publicly available information).

Claims

1. In an electronic device having a display, Receiving a message; and identifying a plurality of instances of contact or event information in the received message; and displaying a first user interface corresponding to the received message, the first user interface comprising: a first portion including the content of the message as received by the electronic device; and a second portion that, if selected, causes the electronic device to display a second user interface including a list of multiple instances of the identified contact or event information, the list organized by type.

2. Detecting an input corresponding to a selection of the second portion of the first user interface; in response to detecting the input corresponding to a selection of the second portion of the first user interface; a list of a plurality of instances of the identified contact or event information; and for each of a plurality of instances of the identified contact or event information, displaying the second user interface including a first user interface object that, when selected, causes the electronic device to add the identified information to a database.

3. 3. The method of claim 2, wherein the second user interface includes, for each of a plurality of instances of the identified contact or event information, a second user interface object that, when selected, causes the electronic device to cease displaying the first user interface object.

4. 4. The method of claim 2 or 3, wherein the second user interface includes a third user interface object that, when selected, causes the electronic device to add each of the groupings of multiple instances of identified contact or event information to a database.

5. The method of claim 2 , wherein displaying the second user interface causes displaying the first user interface to cease.

6. 1. An electronic device comprising: Display and one or more processors; Memory, and one or more programs stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the method of any one of claims 1 to 5.

7. A computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by an electronic device having a display, cause the electronic device to perform the method of any one of claims 1 to 5.

Images