KR20220038816A - Structured suggestions - Google Patents

Abstract

The electronic device suggests contacts and calendar events for users based on their message. The device may analyze the user's messages for contact and event information and automatically create or update suggested contacts and calendar events for the user based on this information. Suggested contacts and calendar events may be searchable as if they were manually entered by the user, and the user may choose to add or ignore suggested contacts and calendar events.

Description

STRUCTURED SUGGESTIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is filed on May 30, 2014 in U.S. Provisional Patent Application No. 62/005,839, entitled “STRUCTURED SUGGESTIONS,” and in U.S. regular patent applications, filed May 20, 2015, entitled “STRUCTURED SUGGESTIONS.” 14/718,049, which is incorporated herein by reference in its entirety for all purposes.

technical field

TECHNICAL FIELD This disclosure relates generally to context-aware computing, and more particularly to identifying and providing suggested contact information and event information to users.

Modern electronic devices enable users to connect with friends, colleagues, and activities more than ever before. However, managing contacts and calendar events on electronic devices can be burdensome. For example, adding or updating a contact or calendar event typically requires several manual steps. As a result, many users neglect managing their address books and calendars, leading to inefficient retrieval of stored messages and other content on their devices when they need to locate information about a person or event. Choose instead of depend. This creates an unsatisfactory user experience and can lead to loss of productivity.

The prior art of the present application includes the following documents.

- US Patent Application Publication No. 2013/0297317 (published on Nov. 7, 2013)

- US Patent Application Publication No. 2012/0173222 (published on Jul. 5, 2012)

- US Patent Application Publication No. 2012/0096389 (published on April 19, 2012)

- US Patent No. 6349299 (published on February 19, 2002)

- Japanese Patent Application Laid-Open No. 10-171827 (published on June 26, 1998)

- Japanese Patent Application Publication No. 2012-059083 (published on March 22, 2012)

In some embodiments, a method of suggesting a contact comprises, at an electronic device: receiving a message; identifying, within the received message, an entity and contact information associated with the entity; determining that a contact associated with the identified entity does not exist among the plurality of contacts in the database; and in response to the determining, creating a contact associated with the entity, wherein the created contact includes contact information and an indication that the created contact is a suggested contact.

In some embodiments, a method of suggesting a contact comprises, at an electronic device: receiving a message; identifying, within the received message, an entity and an item of contact information associated with the entity; determining that a contact associated with the identified entity exists among a plurality of contacts in the database and the contact does not contain an item of identified contact information; and in response to the determining step, updating the contact to include the item of contact information and an indication that the item of contact information is an item of suggested contact information.

In some embodiments, a method of suggesting a contact comprises, at an electronic device having a display: receiving a message; identifying, within the received message, an entity and contact information associated with the entity; generating an indication that the identified contact information is suggested contact information; and displaying a first user interface corresponding to a contact associated with the entity, wherein the first user interface is configured to indicate, based on the generated indication, that the identified contact information is suggested contact information. includes

In some embodiments, a method of suggesting a contact comprises, at an electronic device having a display: receiving a message; identifying, within the received message, an entity and contact information associated with the entity; and displaying a first user interface corresponding to the received message, the first user interface comprising: a first portion comprising content of the message received by the electronic device; and a second portion, the second portion comprising: 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 the database.

In some embodiments, a method of suggesting a contact comprises, at an electronic device: receiving a message; identifying event information within the received message; and generating a calendar event associated with the identified event information, wherein the generated calendar event includes the event information and an indication that the generated calendar event is a suggested calendar event.

In some embodiments, a method of suggesting a calendar event comprises, at an electronic device having a display: receiving a message; identifying event information within the received message; and displaying a first user interface corresponding to the received message, the first user interface comprising: a first portion comprising content of the message received by the electronic device; and a second portion, the second portion comprising: 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 comprising a plurality of calendar events.

In some embodiments, a method of suggesting multiple contact and/or calendar events comprises: at an electronic device having a display: receiving a message; identifying, within the received message, multiple instances of contact or event information; and displaying a first user interface corresponding to the received message, the first user interface comprising: a first portion comprising 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 comprising a list of the plurality of instances of the identified contact or event information.

1A is a block diagram illustrating a portable multifunction device with a touch-sensitive display, in accordance with some examples.
1B is a block diagram illustrating example components for event handling, in accordance with some embodiments.
2 illustrates a portable multifunction device with a touch screen, in accordance with some embodiments.
3 is a block diagram of an exemplary multifunction device having a display and a touch-sensitive surface, in accordance with some embodiments.
4A and 4B illustrate an example user interface for a menu of applications on a portable multifunction device, in accordance with some.
5A illustrates a block diagram of an example data architecture for a proposed contact, in accordance with some embodiments.
5B illustrates a block diagram of an example data architecture for a proposed calendar event, in accordance with some embodiments.
6A-6G illustrate example user interfaces for providing suggested contact and calendar events, in accordance with some embodiments.
7A-7B illustrate a flow diagram of an example process for creating a suggested contact in accordance with some embodiments.
8A-8B illustrate a flow diagram of an example process for updating an existing contact with an item of suggested contact information, in accordance with some embodiments.
9A and 9B illustrate a flow diagram of an example process for displaying a contact with suggested contact information, in accordance with some embodiments.
10 illustrates a flow diagram of an example process for presenting suggested contact information with a message, in accordance with some embodiments.
11A and 11B illustrate a flow diagram of an example process for creating a suggested calendar event in accordance with some embodiments.
12 illustrates a flow diagram of an example process for presenting suggested event information with a message, in accordance with some embodiments.
13 illustrates a flow diagram of an example process for displaying multiple suggested contact or event information with a message, in accordance with some embodiments.
14 is a functional block diagram of an electronic device in accordance with some embodiments.
15 is a functional block diagram of an electronic device in accordance with some embodiments.
16 is a functional block diagram of an electronic device in accordance with some embodiments.
17 is a functional block diagram of an electronic device in accordance with some embodiments.
18 is a functional block diagram of an electronic device in accordance with some embodiments.
19 is a functional block diagram of an electronic device in accordance with some embodiments.
20 is a functional block diagram of an electronic device in accordance with some embodiments.
21 is a functional block diagram of an electronic device in accordance with some embodiments.
22 is a functional block diagram of an electronic device in accordance with some embodiments.

In the following description of the disclosure and embodiments, reference is made to the accompanying drawings, wherein specific embodiments in which they may be practiced are shown by way of example in the drawings. It will be understood that other embodiments may be practiced and changes may be made without departing from the scope of the disclosure.

As mentioned above, managing contacts and calendar events on electronic devices can be burdensome for users, because adding or updating contacts and calendar events requires multiple manual steps to add over time. Because. For this reason, many users simply neglect keeping their address books and calendars up to date, which they have to spend time later when they need to manually search on their device for specific contact or event information. This can lead to an unsatisfactory user experience and loss of productivity.

The present disclosure seeks to address this problem by providing users with an electronic device that automatically suggests contact and calendar events based on their messages. The device may analyze the user's messages for contact and event information and automatically create or update suggested contacts and calendar events for the user based on this information. Suggested contacts and calendar events may be searchable as if they were manually entered by the user, and the user may choose to add or ignore 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 part of the user, which can save user time, improve productivity, and create a more efficient human-machine interface.

1. Exemplary device

In the following, FIGS. 1A, 1B, 2, and 3 provide descriptions of example devices for performing techniques for suggesting contact and event information. 4A, 4B, and 6A-6G illustrate example user interfaces for suggesting contact and event information. The user interfaces in these figures are also used to describe the processes described below, including those in FIGS. 7A-13 .

Although the following description uses terms such as “first,” “second,” and the like to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, a first touch could be referred to as a second touch, and similarly, a second touch could be referred to as a first touch, without departing from the scope of the various described embodiments. Although the first touch and the second touch are both touches, they are not the same touch.

The terminology used in the description of the various described embodiments herein is for the purpose of describing the specific embodiments only, and is not intended to be limiting. As used in the description of the various described embodiments and in the appended claims, the singular forms “a, an” and “the” also refer to the plural forms, unless the context clearly dictates otherwise. It is intended to include It is also to be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the listed related items. The terms “include,” “including,” “comprise,” and/or “comprising,” as used herein, refer to the recited features, integers Specifies the presence of steps, steps, actions, elements, and/or components, but the presence or absence of one or more other features, integers, steps, actions, elements, components, and/or groups thereof; It will further be appreciated that addition is not excluded.

The term “if” refers to “when” or “upon” or “in response to determining” or “detecting, depending on the context. It can be interpreted as meaning "in response to detecting". Similarly, the phrase "if it is determined that" or "if [the stated condition or event] is detected" means "on determining that" or "in response to determining that" or "[ be construed to mean "on detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]."

Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described. In some embodiments, the device is a portable communication device, such as a mobile phone, that also includes other functions, such as PDA and/or music player functions. Exemplary embodiments of portable multifunction devices include the iPhone®, iPod Touch®, and iPad® devices of Apple Inc. of Cupertino, CA (these are including but not limited to). Other portable electronic devices such as laptop or tablet computers with touch-sensitive surfaces (eg, touch screen displays and/or touchpads) are optionally used. It should also be understood that in some embodiments, the device is not a portable communication device, but a desktop computer with a touch-sensitive surface (eg, a touch screen display and/or a touchpad).

In the discussion below, an electronic device including a display and a touch-sensitive surface is described. However, it should be understood that the electronic device optionally includes one or more other physical user interface devices such as a physical keyboard, mouse, and/or joystick.

The device may support a variety of applications, such as one or more of the following: drawing applications, presentation applications, word processing applications, website creation applications, disk authoring applications, spreadsheet applications, gaming applications, phone applications, video conferencing applications, e- A mail application, an instant messaging application, an exercise support application, a photo management application, a digital camera application, a digital video camera application, a web browsing application, a digital music player application, and/or a digital video player application.

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

We now turn to embodiments of portable devices with touch-sensitive displays. 1A is a block diagram illustrating a portable multifunction device 100 having a touch-sensitive display system 112 in accordance with some embodiments. Touch-sensitive display 112 is sometimes referred to as a “touch screen” for convenience, and is sometimes known or referred to as a “touch-sensitive display system.” Device 100 includes memory 102 (optionally including one or more computer-readable storage media), memory controller 122 , one or more processing units (CPUs) 120 , peripheral interface 118 , RF Circuitry 108 , audio circuitry 110 , speaker 111 , microphone 113 , input/output (I/O) subsystem 106 , other input or control devices 116 and external port 124 . includes Device 100 optionally includes one or more optical sensors 164 . Device 100 may optionally include one or more contact intensity sensors to detect intensity of contacts on device 100 (eg, a touch-sensitive surface such as touch-sensitive display system 112 of device 100 ). (165). Device 100 may optionally generate tactile outputs on device 100 (eg, a touch-sensitive surface such as touch-sensitive display system 112 of device 100 or touch of device 300 ). one or more tactile output generators 167 for generating tactile outputs on the pad 355 . These components optionally communicate via one or more communication buses or signal lines 103 .

As used in the specification and claims, the term “strength” of a contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of a contact (eg, finger contact) on the touch-sensitive surface; or a substitute (proxy) for the force or pressure of contact on a touch-sensitive surface. The intensity of the contact has a range of values including at least four distinct values and more typically including hundreds (eg, at least 256) distinct values. The intensity of the contact is optionally determined (or measured) using various approaches and various sensors or combinations of sensors. For example, one or more force sensors below or adjacent to the touch-sensitive surface are optionally used to measure force at various points on the touch-sensitive surface. In some implementations, force measurements from multiple force sensors are combined (eg, weighted average) to determine an estimated force of a contact. Similarly, a pressure-sensitive tip of the stylus is, optionally, used to determine the pressure of the stylus on the touch-sensitive surface. Alternatively, the size and/or changes thereto of the contact area detected on the touch-sensitive surface, the capacitance and/or changes thereto of the touch-sensitive surface in the vicinity of the contact, and/or the changes thereto, of the touch-sensitive surface in the vicinity of the contact Resistance and/or changes thereto are optionally used as a substitute for the force or pressure of contact on the touch-sensitive surface. In some implementations, the surrogate measurements for contact force or pressure are used directly to determine whether an intensity threshold has been exceeded (eg, the intensity threshold is described in units corresponding to the surrogate measurements). In some implementations, alternative measurements for contact force or pressure are converted to an estimated force or pressure, and the estimated force or pressure is used to determine whether an intensity threshold has been exceeded (eg, the intensity threshold is pressure threshold measured in units). Using the intensity of the contact as an attribute of the user input would otherwise indicate affordances (eg, on a touch-sensitive display) and/or (eg, a touch-sensitive display, touch-sensitive surface, or knob (eg, a touch-sensitive display). knob) or through a physical/mechanical control such as a button) enables user access to additional device functions that may not be accessible by the user on a reduced size device with a limited footprint for receiving user input .

As used in the specification and claims, the term “tactile output” refers to the physical displacement of a device relative to its previous position, a component of the device (eg, a touch-sensitive surface) relative to another component of the device (eg, a housing). ), or the displacement of a component with respect to the center of mass of the device to be detected by the user using the user's tactile sense. For example, in a situation where the device or component of the device is in contact with a touch-sensitive surface of the user (eg, a finger, palm, or other portion of the user's hand), the tactile output generated by the physical displacement may be to be interpreted as a tactile sensation corresponding to a perceived change in the physical properties of a device or component of a device. For example, movement of a touch-sensitive surface (eg, a touch-sensitive display or trackpad) may optionally be performed by the user as a “down click” or “up click” of a physical actuator button. is interpreted by In some cases, the user will feel a tactile sensation such as a "down click" or "up click" even when there is no movement of the physical actuator button associated with the touch-sensitive surface that is physically depressed (eg, displaced) by the user's movement. . As another example, movement of the touch-sensitive surface is optionally interpreted or sensed by the user as a “roughness” of the touch-sensitive surface even when there is no change in flatness of the touch-sensitive surface. Although these interpretations of touch by the user will be susceptible to the user's personalized sensory perceptions, there are many touch sensory perceptions that are common to the majority of users. Thus, when tactile output is described as corresponding to a user's specific sensory perception (eg, "up click", "down click", "roughness"), unless otherwise stated, the generated tactile output is typically Corresponds to a physical displacement of the device or component thereof that will produce the described sensory perception for a human (or average) user.

Device 100 is but one example of a portable multifunction device and device 100 may optionally have more or fewer components than shown, optionally combine two or more components, or optionally In general, it will be appreciated that they have different configurations or arrangements of components. The various components shown in FIG. 1A are implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application-specific integrated circuits (ASICs).

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

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

Radio frequency (RF) circuitry 108 receives and transmits RF signals, also called electromagnetic signals. The RF circuitry 108 converts electrical signals to/from electromagnetic signals and communicates with communication networks and other communication devices via the electromagnetic signals. RF circuitry 108 optionally includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, etc. It includes, but is not limited to, well-known circuitry for performing these functions. The RF circuitry 108 may optionally include networks such as the Internet, intranet, and/or wireless networks also referred to as the World Wide Web (WWW), such as a cellular telephone network, a wireless local area network (LAN). and/or a metropolitan area network (MAN), and other devices, by wireless communication. The RF circuitry 108 optionally includes well known circuitry for detecting a near field communication (NFC) field, such as a short range communication radio. Wireless communication is optionally, Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), high-speed downlink packet access (HSDPA), high-speed uplink packet access (HSUPA), Evolution (EV-DO) , Data-Only), HSPA, HSPA+, DC-HSPDA (Dual-Cell HSPA), LTE (long term evolution), NFC (near field communication), W-CDMA (wideband code division multiple access), CDMA (code division multiple) access), time division multiple access (TDMA), Bluetooth (Bluetooth), Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi) (eg, 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 (eg, Internet message access protocol (IMAP) and/or post office protocol (POP)), instant messaging (eg, XMPP) (extensible messaging and presence protocol), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), Instant Messaging and Presence Service (IMPS), and/or Short Message Service (SMS), or not yet developed at the filing date of this document. any other suitable communication protocols, including It uses any of a plurality of communication standards, protocols and technologies including, but not limited to, a communication protocol.

The audio circuit unit 110 , the speaker 111 , and the microphone 113 provide an audio interface between the user and the device 100 . The audio circuit unit 110 receives audio data from the peripheral device interface 118 , converts the audio data into an electrical signal, and transmits the electrical signal to the speaker 111 . The speaker 111 converts the electrical signal into sound waves that humans can hear. The audio circuitry 110 also receives an electrical signal converted from sound waves by the microphone 113 . The audio circuitry 110 converts the electrical signal into audio data and transmits the audio data to the peripheral interface 118 for processing. Audio data may be retrieved from and/or transmitted to memory 102 and/or RF circuitry 108 by peripherals interface 118 . In some embodiments, audio circuitry 110 also includes a headset jack (eg, 212 in FIG. 2 ). The headset jack provides an interface between the audio circuitry 110 and detachable audio input/output peripherals, such as output-only headphones, or a headset that has both an output (eg, headphones for one or both ears) and an input (eg, a microphone). to provide.

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

A quick press of the push button may initiate the process of using gestures on the touch screen to unlock the touch screen 112, or to unlock the device, filed on December 23, 2005 and entitled " As described in U.S. Patent Application Serial No. 11/322,549 and U.S. Patent No. 7,657,849, "Unlocking a Device by Performing Gestures on an Unlock Image," which is incorporated herein by reference in its entirety. A longer press of the push button (eg, 206 ) may power on or off the device 100 . A user may customize the function of one or more of the buttons. The touch screen 112 is used to implement virtual or soft buttons and one or more soft keyboards.

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

Touch screen 112 has a touch-sensitive surface, sensor, or set of sensors that receives input from a user based on haptic and/or tactile contact. Touch screen 112 and display controller 156 (along with any associated modules and/or sets of instructions within memory 102 ) contact (and any movement or interruption of) contact on touch screen 112 . , and converts the detected contact into interaction with user interface objects (eg, one or more soft keys, icons, web pages or images) displayed on the touch screen 112 . In an exemplary embodiment, the point of contact between the touch screen 112 and the user corresponds to the user's finger.

The touch screen 112 may use a liquid crystal display (LCD) technology, a light emitting polymer display (LPD) technology, or a light emitting diode (LED) technology, but in other embodiments Other display technologies may be used. Touch screen 112 and display controller 156 may use capacitive, resistive, infrared and surface acoustic wave techniques, as well as other proximity sensor arrays or other elements to determine one or more points of contact with touch screen 112 ( Any of a plurality of touch sensing technologies currently known or to be developed in the future, including but not limited to), may be used to detect a contact and any movement or disruption thereof. In an exemplary embodiment, a projected mutual capacitance sensing technology such as that provided in the iPhone® and iPod Touch® of Apple Inc. of Cupertino, CA is used.

The touch-sensitive display in some embodiments of the touch screen 112 is described in US Pat. It may be similar to the multi-touch sensitive touchpads described in US Patent Publication No. 2002/0015024A1, each of which is incorporated herein by reference in its entirety. However, touch screen 112 displays visual output from device 100 , while touch-sensitive touchpads do not provide visual output.

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

The touch screen 112 may have a video resolution greater than 100 dpi. In some embodiments, the touch screen has a video resolution of approximately 160 dpi. A user may contact the touch screen 112 using any suitable object or appendage, such as a stylus, finger, or the like. In some embodiments, the user interface is primarily designed to operate using finger-based contacts and gestures, which may be less precise than stylus-based input due to the larger contact area of the finger on the touch screen. In some embodiments, the device converts coarse finger-based input into precise pointer/cursor positions or commands for performing actions desired by the user.

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

Device 100 also includes a power grid 162 for providing power to the various components. Power grid 162 may include a power management system, one or more power sources (eg, batteries, alternating current (AC)), recharge systems, power fault detection circuitry, power converters or inverters, power status indicators (eg, light emitting diodes (LEDs)) ), and any other components associated with the generation, management, and distribution of power within portable devices.

Device 100 may also include one or more optical sensors 164 . 1A shows a light sensor coupled to a light sensor controller 158 in the I/O subsystem 106 . The optical sensor 164 may include charge-coupled device (CCD) or complementary metal-oxide semiconductor (CMOS) phototransistors. 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 the imaging module 143 (also referred to as a camera module), the optical sensor 164 may capture still images or video. In some embodiments, the optical sensor is located on the back of the device 100 opposite the touch screen display 112 on the front of the device so that the touch screen display acts as a viewfinder for still and/or video image acquisition. make it usable In some embodiments, an optical sensor is positioned on the front of the device to allow an image of the user to be acquired for the videoconference while the user views other videoconference participants on the touch screen display. In some embodiments, the position of the optical sensor 164 can be changed by the user (eg, by rotating the sensor and a lens within the device housing) so that a single optical sensor 164 can video conferencing and stationary and /or it can be used for both video image acquisition.

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

Device 100 may also include one or more proximity sensors 166 . 1A shows a proximity sensor 166 coupled to a peripherals interface 118 . Alternatively, the proximity sensor 166 may be coupled to the input controller 160 within the I/O subsystem 106 . Proximity sensor 166 is described in US Patent Application Serial Nos. 11/241,839, "Proximity Detector In Handheld Device;" 11/240,788, "Proximity Detector In Handheld Device"; 11/620,702, "Using Ambient Light Sensor To Augment Proximity Sensor Output"; 11/586,862, "Automated Response To And Sensing Of User Activity In Portable Devices"; and 11/638,251, "Methods And Systems For Automatic Configuration Of Peripherals," which are hereby incorporated by reference in their entirety. In some embodiments, the proximity sensor turns off and disables the touch screen 112 when the multifunction device is placed near the user's ear (eg, when the user is on a phone call).

Device 100 also optionally includes one or more tactile output generators 167 . 1A shows a tactile output generator coupled to a haptic feedback controller 161 within the I/O subsystem 106 . Tactile output generator 167 optionally generates one or more electroacoustic devices, such as speakers or other audio components, and/or a motor, solenoid, electroactive polymer, piezoelectric actuator, electrostatic actuator, or other tactile output Electromechanical devices that convert energy into linear motion, such as a component (eg, a component that converts electrical signals into tactile outputs on the device). The contact intensity sensor 165 receives tactile feedback generation instructions from the haptic feedback module 133 to generate tactile outputs on the device 100 that can be sensed by a user of the device 100 . In some embodiments, at least one tactile output generator is positioned alongside or proximate to a touch-sensitive surface (eg, touch-sensitive display system 112 ) and, optionally, vertically ( For example, generating a tactile output by moving in/out of the surface of the device 100 ) or laterally (eg, back and forth within the same plane as the surface of the device 100 ). In some embodiments, the at least one tactile output generator sensor is located on the back of the device 100 opposite the touch screen display 112 positioned on the front of the device 100 .

Device 100 may also include one or more accelerometers 168 . 1A shows an accelerometer 168 coupled to a peripherals interface 118 . Alternatively, the accelerometer 168 may be coupled to the input controller 160 within the I/O subsystem 106 . Accelerometer 168 is described in US Patent Publication No. 20050190059, "Acceleration-based Theft Detection System for Portable Electronic Devices," and US Patent Publication 2006017692, "Methods And Apparatuses For Operating A Portable Device Based On An Accelerometer." may operate as described above, 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 analysis of data received from one or more accelerometers. Device 100 is a magnetometer (not shown) in addition to accelerometer(s) 168 , and a GPS (or GLONASS or other global navigation system) optionally includes a receiver (not shown).

In some embodiments, software components stored in memory 102 include operating system 126 , communication module (or set of instructions) 128 , contact/motion module (or set of instructions) 130 , graphics module ( or set of instructions) 132 , a text input module (or set of instructions) 134 , a Global Positioning System (GPS) module (or set of instructions) 135 , and applications (or sets of instructions) ( 136). Moreover, in some embodiments, the memory ( 102 in FIG. 1A or 370 in FIG. 3 ) stores device/global internal state 157 as shown in FIGS. 1A and 3 . Device/global internal state 157 includes an active application state indicating that applications (if any) are currently active; a display state indicating which applications, views, or other information occupy the various areas of the touch screen display 112 ; sensor status, including information obtained from various sensors and input control devices 116 of the device; and location information regarding the location and/or posture of the device.

Operating system 126 (eg, an embedded operating system such as Darwin, RTXC, LINUX, UNIX, OS X, iOS, WINDOWS, or VxWorks) can perform general system tasks (eg, memory management, storage device control, power management, etc.) It includes various software components and/or drivers for controlling and managing the software, and facilitates communication between various hardware and software components.

Communication module 128 facilitates communication with other devices via one or more external ports 124 , and also provides various functions for processing data received by RF circuitry 108 and/or external ports 124 . Includes software components. External port 124 (eg, Universal Serial Bus (USB), FIREWIRE, etc.) may be configured to couple to other devices directly or indirectly through a network (eg, Internet, wireless LAN, etc.) is composed In some embodiments, the external port is a multi-pin (eg, 30-pin) that is the same as or similar to and/or compatible with the 30-pin connector used in iPod® (trademark of Apple Inc.) devices. It's a connector.

Contact/motion module 130 optionally detects contact with touch screen 112 (in conjunction with display controller 156 ), and other touch-sensitive devices (eg, a touchpad or physical click wheel). do. The contact/motion module 130 is configured to determine whether a contact has occurred (eg, detect a finger-down event), a strength of a contact (eg, a force or pressure of a contact, or a force of a contact) or a substitute for pressure), determining if there is movement of the contact and tracking movement across the touch-sensitive surface (eg, detecting one or more finger-dragging events). , and various software components for performing various operations related to detection of a contact, such as determining whether the contact has ceased (eg, detecting a finger-up event or contact cessation). . The contact/motion module 130 receives contact data from the touch-sensitive surface. Determining the movement of the point of contact represented by the set of contact data may optionally include a speed (magnitude), velocity (magnitude and direction), and/or acceleration (change in magnitude and/or direction) of the point of contact. includes deciding. These operations are, optionally, applied to single contacts (eg, one finger contacts) or to multiple simultaneous contacts (eg, "multi-touch"/multiple finger contacts). In some embodiments, contact/motion module 130 and display controller 156 detect a contact on the touchpad.

In some embodiments, contact/motion module 130 determines whether an action was performed by a user (eg, to determine whether a user "clicked" on an icon) a set of one or more intensity thresholds. use it In some embodiments, at least a subset of the intensity thresholds are determined according to software parameters (eg, the intensity thresholds are not determined by activation thresholds of particular physical actuators, the physical hardware of the device 100 ) can be adjusted without changing For example, the mouse "click" threshold of a trackpad or touch screen display may be set to any of a wide range of predefined thresholds without changing the trackpad or touch screen display hardware. Additionally, in some implementations, a user of the device (eg, by adjusting individual intensity thresholds and/or adjusting a plurality of intensity thresholds at once with a system level click “intensity” parameter) may select one or more of the set of intensity thresholds. are provided with software settings for adjusting the

The contact/motion module 130 optionally detects a gesture input by the user. Different gestures on the touch-sensitive surface have different contact patterns (eg, different motions, timings, and/or intensities of detected contacts). Thus, the gesture is, optionally, detected by detecting a specific contact pattern. For example, detecting a finger tap gesture may include detecting a finger-down event followed by a finger-up at the same (or substantially the same location) as the finger-down event (eg, the location of the icon). (lift off) includes detecting an event. As another example, detecting a finger swipe gesture on the touch-sensitive surface detects a finger-down event followed by one or more finger-drag events followed by a finger-up (lift-off) detecting events.

Graphics module 132 renders and displays graphics on touch screen 112 or other display, including components for changing the visual effect (eg, brightness, transparency, saturation, contrast, or other visual property) of the displayed graphic. It includes various well-known software components for As used herein, the term “graphic” includes, but is not limited to, text, web pages, icons (such as user interface objects including soft keys), digital images, videos, animations, and the like. ), including any object that can be displayed to the user.

In some embodiments, graphics module 132 stores data representing graphics to be used. Each graphic is optionally assigned a corresponding code. The graphics module 132 receives one or more codes specifying graphics to be displayed along with coordinate data and other graphics attribute data, if necessary, from applications, etc., and then generates and outputs screen image data to the display controller 156 .

The haptic feedback module 133 is an instruction 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 interactions with the device 100 . It includes various software components for creating

The text input module 134 , which may be a component of the graphics module 132 , requires various applications (eg, contacts 137 , e-mail 140 , IM 141 , browser 147 , and text input). It provides soft keyboards for entering text into any other application.

The GPS module 135 determines the location of the device and uses this information for use in various applications (eg, to the phone 138 for use in location-based dialing), and to the camera 143 as photo/video metadata. to applications that provide location-based services such as weather widgets, local yellow page widgets, and map/navigation widgets).

Applications 136 may include the following modules (or sets of instructions), or a subset or superset thereof:

연락처 모듈(137)(때때로 주소록 또는 연락처 목록이라고 지칭됨);

Contacts module 137 (sometimes referred to as an address book or contact list);

전화 모듈(138);

phone module 138;

화상 회의 모듈(139);

video conferencing module 139;

이메일 클라이언트 모듈(140);

email client module 140;

인스턴트 메시징(IM) 모듈(141);

an instant messaging (IM) module 141;

운동 지원 모듈(142);

exercise support module 142;

정지 및/또는 비디오 영상들을 위한 카메라 모듈(143);

a camera module 143 for still and/or video images;

영상 관리 모듈(144);

video management module 144;

비디오 재생기 모듈;

video player module;

음악 재생기 모듈;

music player module;

브라우저 모듈(147);

browser module 147;

캘린더 모듈(148);

calendar module 148;

날씨 위젯(149-1), 주식 위젯(149-2), 계산기 위젯(149-3), 알람 시계 위젯(149-4), 사전 위젯(149-5), 및 사용자에 의해 획득되는 다른 위젯들뿐만 아니라 사용자-생성 위젯들(149-6) 중 하나 이상을 포함할 수 있는, 위젯 모듈들(149);

Weather widget 149-1, stock widget 149-2, calculator widget 149-3, alarm clock widget 149-4, dictionary widget 149-5, and other widgets obtained by the user as well as widget modules 149 , which may include one or more of user-created widgets 149 - 6 ;

사용자 생성 위젯들(149-6)을 만들기 위한 위젯 생성기 모듈(150);

a widget generator module 150 for creating user generated widgets 149-6;

검색 모듈(151);

search module 151;

비디오 재생기 모듈 및 음악 재생기 모듈을 통합하는 비디오 및 음악 재생기 모듈(152);

a video and music player module 152 incorporating a video player module and a music player module;

메모 모듈(153);

memo module 153;

지도 모듈(154); 및/또는

map module 154; and/or

온라인 비디오 모듈(155).

Online video module (155).

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 replication.

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, adds the name(s) to the address book. to do; deleting name(s) from the address book; associating a name with a phone number(s), email address(es), physical address(es), or other information; associating an image with a name; sorting and sorting names; address book or, including providing phone numbers or email addresses to initiate and/or facilitate communication by phone 138 , video conferencing module 139 , email 140 , or IM 141 , or the like. It may be used to manage a list of contacts (eg, stored in the application internal state 192 of the contacts module 137 in memory 102 or memory 370 ).

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 In conjunction with the input module 134 , the phone module 138 enters a sequence of characters corresponding to a phone number, accesses one or more phone numbers in the contacts module 137 , modifies the entered phone number, and It can be used to dial a phone number, have a conversation, and disconnect or hang up when the conversation is complete. As noted above, wireless communication may utilize any of a plurality of communication standards, protocols, and technologies.

RF circuitry 108 , audio circuitry 110 , speaker 111 , microphone 113 , touch screen 112 , display controller 156 , optical sensor 164 , optical sensor controller 158 , contact/motion Together with the module 130 , the graphics module 132 , the text input module 134 , the contacts module 137 , and the phone module 138 , the video conferencing module 139 communicates with the user according to user instructions. and executable instructions for initiating, conducting, and terminating a video conference between participants.

Along 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 provides user instruction executable instructions for composing, sending, receiving, and managing email in response to Together with the image management module 144 , the email client module 140 greatly facilitates composing and sending emails with still or video images captured with the camera module 143 .

Along 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: Enter a sequence of characters corresponding to a message, modify previously entered characters (eg, Short Message Service (SMS) or Multimedia Message Service (MMS) protocol for phone-based instant messages); or using XMPP, SIMPLE or IMPS for Internet-based instant messages), respectively, including executable instructions to send instant messages, receive instant messages, and view received instant messages. In some embodiments, the instant messages sent and/or received are graphics, pictures, audio files, video files, and/or as supported by MMS and/or Enhanced Messaging Service (EMS). Other attachments may be included. As used herein, “instant messaging” refers to phone-based messages (eg, messages sent using SMS or MMS) and Internet-based messages (eg, messages sent using XMPP, SIMPLE, or IMPS). ) refers to both.

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 in conjunction with the music player module, the exercise support module 142 devises exercises (eg, along with time, distance, and/or calorie expenditure goals); communicate with motion sensors (sports devices); receive motion sensor data; calibrate sensors used to monitor movement; select and play music during exercise; executable instructions to display, store, and transmit athletic data.

with touch screen 112 , display controller 156 , optical sensor(s) 164 , optical sensor controller 158 , contact/motion module 130 , graphics module 132 and image management module 144 . , the camera module 143 captures still images or video (including a video stream) and stores them in the memory 102 , modifies the characteristics of the still image or video, or stores the still image or video from the memory 102 . It contains executable instructions for deleting a video.

Along with the touch screen 112 , the display controller 156 , the contact/motion module 130 , the graphics module 132 , the text input module 134 , and the camera module 143 , the image management module 144 is configured to perform static and and/or executable instructions to arrange, modify (eg, edit), otherwise manipulate, label, delete, present (eg, in a digital slide show or album), and store video images.

Along 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 is configured to: executable instructions to browse the Internet according to user instructions, including retrieving, linking to, receiving, and displaying files or portions thereof, as well as attachments and other files linked to web pages include those

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 ( In conjunction with 147 , calendar module 148 is an executable executable to create, display, modify, and store calendars and data associated with calendars (eg, calendar entries, to-do lists, etc.) according to user instructions. contains commands.

Widget modules, along with RF circuitry 108 , touch screen 112 , display controller 156 , contact/motion module 130 , graphics module 132 , text input module 134 and browser module 147 . 149 may be downloaded and used by a user (eg, a weather widget 149-1, a stock widget 149-2, a calculator widget 149-3, an alarm clock widget 149-4, and a dictionary widget). (149-5)), or mini-applications that may be created by the user (eg, user-created widgets 149-6). In some embodiments, the widget includes a Hypertext Markup Language (HTML) file, a Cascading Style Sheets (CSS) file, and a JavaScript file. In some embodiments, a widget includes an Extensible Markup Language (XML) file and a JavaScript file (eg, Yahoo! widgets).

A widget generator module, along with RF circuitry 108 , touch screen 112 , display controller 156 , contact/motion module 130 , graphics module 132 , text input module 134 and browser module 147 . 150 may be used by a user to create widgets (eg, change a user-specific portion of a web page into a widget).

With touch screen 112 , display controller 156 , contact/motion module 130 , graphics module 132 , and text input module 134 , search module 151 is configured to perform one or more search criteria according to user instructions. executable instructions to search for text, music, sound, image, video, and/or other files in memory 102 matching (eg, one or more user-specified search terms).

With touch screen 112 , display controller 156 , contact/motion module 130 , graphics module 132 , audio circuitry 110 , speaker 111 , RF circuitry 108 and browser module 147 . , video and music player module 152 provides executable instructions that enable a user to download and play recorded music and other sound files stored in one or more file formats, such as MP3 or AAC files, and videos (eg, , on a touch screen 112 or on an externally connected display through an external port 124), to show, or otherwise play back. In some embodiments, device 100 optionally includes the functionality of an MP3 player, such as an iPod (trademark of Apple Inc.).

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 , the memo module 153 is configured to take notes, to do, according to user instructions. executable instructions to create and manage to-do lists and the like.

RF circuitry 108 , touch screen 112 , display controller 156 , contact/motion module 130 , graphics module 132 , text input module 134 , GPS module 135 , and browser module 147 . ) along with the maps module 154 according to user instructions, maps and data associated with the maps (eg, driving directions; data regarding shops and other points of interest at or near a particular location; and other location-based data) can be used to receive, display, modify, and store.

Touch screen 112, display controller 156, contact/motion module 130, graphics module 132, audio circuitry 110, speaker 111, RF circuitry 108, text input module 134, Along with email client module 140 and browser module 147 , online video module 155 allows a user to access, browse, (eg, stream and/or stream, online videos in one or more file formats, such as H.264), commands to receive (by download), play (eg, on a touch screen or on an externally connected display via external port 124 ), send an email with a link to a particular online video, and otherwise manage include In some embodiments, instant messaging module 141 rather than email client module 140 is used to send a link to a particular online video. For additional description of online video applications, see U.S. Provisional Patent Application Serial No. 60/936,562, "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," filed on June 20, 2007, and December 31, 2007. Can be found in U.S. Patent Application Serial No. 11/968,067, filed on the date of "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," the contents of which are hereby incorporated herein by reference in their entirety. do.

Each of the modules and applications identified above are executable instructions for performing one or more of the functions described above and the methods described herein (eg, the computer-implemented methods and other information processing methods described herein). corresponding to a set of These modules (eg, sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various embodiments. . For example, a video player module may be combined with a music player module into a single module (eg, video and music player module 152 in FIG. 1A ). In some embodiments, memory 102 may store a subset of the modules and data structures identified above. In addition, the memory 102 may store additional modules and data structures not described above.

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 touch screen and/or touchpad. By using a touch screen 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, etc.) on device 100 may be reduced.

A predefined set of functions, performed entirely via the touch screen and/or touchpad, optionally include navigation between user interfaces. In some embodiments, the touchpad, when touched by a user, navigates device 100 to a main, home, or root menu from any user interface displayed on device 100 . In these embodiments, a “menu button” is implemented using a touchpad. In some other embodiments, the menu button is a physical push button or other physical input control device instead of a touchpad.

1B is a block diagram illustrating example components for event processing, in accordance with some embodiments. In some embodiments, memory (102 in FIG. 1A or 370 in FIG. 3 ) includes event classifier 170 (eg, in operating system 126 ) and respective application 136 - 1 (eg, the application described above). (any of 137-151, 155, 380-390).

The event classifier 170 receives the event information and determines the application 136 - 1 to which to forward the event information, and the application view 191 of the application 136 - 1 . The event classifier 170 includes an event monitor 171 and an event dispatcher module 174 . In some embodiments, application 136 - 1 includes an application internal state 192 representing the current application view(s) displayed on touch-sensitive display 112 when the application is active or running. In some embodiments, the device/global internal state 157 is used by the event classifier 170 to determine which application(s) is currently active, and the application internal state 192 is the event classifier 170 . ) to determine the application views 191 to which the event information will be delivered.

In some embodiments, application internal state 192 is user indicating resume information to be used when application 136-1 resumes execution, information being displayed by application 136-1 or ready to be displayed. interface state information, a state queue for allowing the user to return to a previous state or view of the application 136-1, and a redo/undo queue of previous actions taken by the user. include information.

The event monitor 171 receives event information from the peripheral interface 118 . The event information includes information regarding a sub-event (eg, a user touch on the touch-sensitive display 112 as part of a multi-touch gesture). Peripheral interface 118 is from I/O subsystem 106 or sensors (such as proximity sensor 166 , accelerometer(s) 168 , and/or microphone 113 (via audio circuitry 110 )). Transmits the information it receives. Information that peripherals interface 118 receives from I/O subsystem 106 includes information from touch-sensitive display 112 or a touch-sensitive surface.

In some embodiments, event monitor 171 sends requests to peripherals interface 118 at predetermined intervals. In response, peripherals interface 118 sends event information. In other embodiments, peripherals interface 118 transmits event information only when there is a significant event (eg, accepting input exceeding a predetermined noise threshold and/or input for exceeding a predetermined duration). . In some embodiments, the event classifier 170 also includes a hit view determination module 172 and/or an active event recognizer determination module 173 .

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

Another aspect of a user interface associated with an application is a set of views, sometimes referred to herein as application views or user interface windows, in which information is displayed and touch-based gestures occur. The application views (of the respective application) for which a touch is detected may correspond to the application's programmatic or programmatic levels within the view hierarchy. 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 recognized as appropriate inputs may be determined based, at least in part, on the hit view of the initial touch that initiates the touch-based gesture.

The hit view determination module 172 receives information related to sub-events of the touch-based gesture. When the application has multiple views organized in a hierarchy, the hit view determination module 172 identifies the hit view as the lowest view in the hierarchy that should handle the sub-event. In most situations, the hit view is the lowest level view in which the initiated sub-event occurs (eg, it is the first sub-event in the sequence of sub-events that form the event or potential event). Once a hit view is identified by hit view determination module 172 , the hit view typically receives all sub-events related to the same touch or input source that caused it to be identified as a hit view.

The active event recognizer determination module 173 determines which view or views within the view hierarchy should receive a particular sequence of sub-events. In some embodiments, the active event recognizer determination module 173 determines that only the hit view should receive a particular sequence of sub-events. In other embodiments, the active event recognizer determination module 173 determines that all views including the physical location of the sub-event are actively involved views, so that all actively involved views are sub-events. determines that it should receive a specific sequence of In other embodiments, even if touch sub-events are exclusively confined to an area associated with one particular view, views higher in the hierarchy will still remain as actively participating views.

The event dispatcher module 174 forwards the event information to an event recognizer (eg, event recognizer 180 ). In embodiments that include an active event recognizer determination module 173 , the event dispatcher module 174 communicates event information to the event recognizer determined by the active event recognizer determination module 173 . In some embodiments, event dispatcher module 174 stores event information in an event queue, which event information is fetched by each event receiver 182 .

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

In some embodiments, application 136 - 1 includes a plurality of event handlers 190 and one or more application views 191 , each of which is a touch event occurring within a respective view of the application's user interface. Includes instructions for processing them. Each application view 191 of application 136 - 1 includes one or more event recognizers 180 . Typically, each application view 191 includes a plurality of event recognizers 180 . In other embodiments, one or more of the event recognizers 180 may be part of a separate module, such as a user interface kit (not shown) or a higher-level object from which the application 136-1 inherits methods and other properties. am. In some embodiments, each event handler 190 is one of data updater 176 , object updater 177 , GUI updater 178 , and/or event data 179 received from event classifier 170 . includes more than Event handler 190 may update application internal state 192 using or calling data updater 176 , object updater 177 , or GUI updater 178 . 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 data updater 176 , object updater 177 , and GUI updater 178 are included in respective application view 191 .

Each event recognizer 180 receives event information (eg, event data 179 ) from the event classifier 170 and identifies an event from the event information. The event recognizer 180 includes an event receiver 182 and an event comparator 184 . In some embodiments, event recognizer 180 also includes at least a subset of metadata 183 and event delivery instructions 188 (which may include sub-event delivery instructions).

The event receiver 182 receives event information from the event classifier 170 . The event information includes information about a sub-event, for example a touch or a touch movement. Depending on the sub-event, the event information also includes additional information such as the location of the sub-event. When the sub-event relates to the motion of the touch, the event information may also include the speed and direction of the sub-event. In some embodiments, the events include rotation of the device from one orientation to another (eg, from portrait to landscape orientation, or vice versa), and the event information includes the current orientation of the device (also referred to as device pose). ) and corresponding information about

The event comparator 184 compares the event information to predefined event or sub-event definitions, and based on the comparison, determines an event or sub-event, or determines or updates the status of the event or sub-event. . In some embodiments, event comparator 184 includes event definitions 186 . Event definitions 186 include definitions of events (eg, predefined sequences of sub-events), eg, Event 1 187-1, Event 2 187-2, and the like. In some embodiments, sub-events within event 187 include, for example, touch start, touch end, touch move, touch cancel, and multi-touch. In one example, the definition for event 1 (187-1) is a double tap on the displayed object. A double tap is, for example, a first touch (touch start) on a displayed object during a predetermined phase, a first liftoff (touch end) during a predetermined phase, a displayed object during a predetermined phase a second touch on the upper body (touch start), and a second liftoff (touch end) for a predetermined phase. In another example, the definition for event 2 187 - 2 is a drag on the displayed object. Dragging includes, for example, a touch (or contact) on the displayed object during a predetermined phase, movement of the touch across the touch-sensitive display 112 , and liftoff of the touch (touch termination). In some embodiments, the event also includes information about one or more associated event handlers 190 .

In some embodiments, event definition 186 includes a definition of an event for a respective user interface object. In some embodiments, event comparator 184 performs a hit test to determine which user interface object is associated with a sub-event. For example, in an application view in which three user interface objects are displayed on the touch-sensitive display 112 , when a touch is detected on the touch-sensitive display 112 , the event comparator 184 displays the three user interface objects A hit test is performed to determine which of them is associated with a touch (sub-event). When each displayed object is associated with a respective event handler 190 , the event comparator uses the result of the hit test to determine which event handler 190 should be activated. For example, event comparator 184 selects an event handler associated with the sub-event and object that triggers the hit test.

In some embodiments, the definition of a respective event 187 also includes deferred actions of delaying the delivery of event information until after it is determined whether the sequence of sub-events corresponds to or does not correspond to an event type of the event recognizer. .

When the respective event recognizer 180 determines that the set of sub-events does not match any of the events in the event definitions 186 , the respective event recognizer 180 determines that the event is impossible, event failed, or event An end state is entered, after which the respective event recognizer ignores subsequent sub-events 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 touch-based gestures in progress.

In some embodiments, each event recognizer 180 has configurable properties, flags, and/or indicating how the event delivery system should perform sub-event delivery to actively engaged event recognizers. or metadata 183 with lists. In some embodiments, metadata 183 includes configurable properties, flags, and/or lists that indicate how event recognizers may interact with, or become able to interact with, each other. In some embodiments, metadata 183 includes configurable properties, flags, and/or lists that indicate whether sub-events are delivered to various levels in the view or program hierarchy.

In some embodiments, a respective event recognizer 180 activates an event handler 190 associated with an event when one or more particular sub-events of the event are recognized. In some embodiments, the respective event recognizer 180 passes event information associated with the event to the event handler 190 . Activating the event handler 190 is distinct from sending (and delayed sending) sub-events to the respective hit view. In some embodiments, event recognizer 180 throws a flag associated with the recognized event, and event handler 190 associated with that flag catches the flag to perform a predefined process.

In some embodiments, event delivery instructions 188 include sub-event delivery instructions that deliver event information related to a sub-event without activating an event handler. Instead, sub-event delivery instructions deliver event information to event handlers associated with a series of sub-events or to actively engaged views. Event handlers associated with a series of sub-events or actively engaged views receive event information and perform a predetermined process.

In some embodiments, data updater 176 creates and updates data used in application 136 - 1 . For example, the data updater 176 updates a phone number used in the contact module 137 or stores a video file used in the video player module. In some embodiments, object updater 177 creates and updates objects used in application 136 - 1 . For example, the object updater 177 creates a new user interface object or updates the location of the user interface object. GUI updater 178 updates the GUI. For example, GUI updater 178 prepares display information and sends it to graphics module 132 for display on a touch-sensitive display.

In some embodiments, event handler(s) 190 includes or accesses 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 within a single module of each application 136 - 1 or application view 191 . In other embodiments, they are included in two or more software modules.

The discussion above regarding event handling of user touches on touch-sensitive displays also applies to other forms of user inputs for operating multifunction devices 100 having input devices, but all of which are disclosed on touch screens. You have to understand that it's not going to happen. mouse movement and mouse button presses optionally coordinated with, for example, single or multiple keyboard presses or holds; contact movements, such as tap, drag, scroll, etc., on the touchpad; pen stylus inputs; movement of the device; verbal commands; detected eye movements; biometric inputs; and/or any combination thereof is optionally used as inputs corresponding to sub-events defining the event to be recognized.

2 illustrates a portable multifunction device 100 having a touch screen 112 , in accordance with some embodiments. The touch screen, optionally, displays one or more graphics within user interface (UI) 200 . In this embodiment, as well as other embodiments described below, the user may, for example, use one or more fingers 202 (not drawn to scale in the figures) or one or more styluses 203 (shown to scale in the figures). not) to select one or more of the graphics by making a gesture on the graphic. In some embodiments, selection of the one or more graphics occurs when the user ceases contacting the one or more graphics. In some embodiments, the gesture may optionally include one or more taps of a finger in contact with device 100 , one or more swipes (left to right, right to left, up and/or down) and/or (right). to left, left to right, up and/or down) rolling. In some implementations or circumstances, if inadvertently contacted with a graphic, the graphic is not selected. For example, when the gesture corresponding to selection is a tap, a swipe gesture passing over the application icon optionally does not select the corresponding application.

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

In some embodiments, device 100 includes touch screen 112 , menu button 204 , push button 206 to power on/off the device and lock the device, volume control button(s) 208 , a Subscriber Identity Module (SIM) card slot 210 , a headset jack 212 , and a docking/charging external port 124 . Push button 206 may optionally power on/off the device by pressing the button and holding the button depressed for a predefined time interval; lock the device by depressing the button and releasing the button depress before a predefined time interval elapses; and/or to unlock the device or initiate an unlocking process. In an alternative embodiment, device 100 also receives verbal input for activation or deactivation of some functions via microphone 113 . Device 100 may also optionally include one or more contact intensity sensors 165 for detecting intensity of contacts on touch screen 112 and/or for generating tactile outputs for a user of device 100 . one or more tactile output generators 167 .

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

Each of the previously identified elements in FIG. 3 may be stored in one or more of the previously mentioned memory devices. Each of the modules identified above corresponds to a set of instructions for performing the functions described above. The modules or programs (eg, sets of instructions) identified above need not be implemented as separate software programs, procedures, or modules; thus, various subsets of these modules may be combined in various embodiments or otherwise can be rearranged in this way. In some embodiments, memory 370 may store a subset of the modules and data structures identified above. Also, the memory 370 may store additional modules and data structures not described above.

We now look at embodiments of user interfaces that may be implemented, for example, on portable multifunction device 100 .

4A illustrates an example user interface for a menu of applications on portable multifunction device 100 in accordance with some embodiments. Similar user interfaces may be implemented on device 300 . In some embodiments, user interface 400 includes the following elements, or a subset or superset thereof:

셀룰러 및 Wi-Fi 신호들과 같은 무선 통신(들)에 대한 신호 세기 표시자(들)(402);

signal strength indicator(s) 402 for wireless communication(s), such as cellular and Wi-Fi signals;

시간(404);

time 404;

블루투스 표시자(405);

Bluetooth indicator 405;

배터리 상태 표시자(406);

battery status indicator 406 ;

다음과 같은, 빈번하게 사용되는 애플리케이션들에 대한 아이콘들을 갖는 트레이(408):

Tray 408 with icons for frequently used applications, such as:

o an icon 416 for the phone module 138 labeled “Call”, optionally including an indicator 414 of the number of missed calls or voicemail messages;

o an icon 418 for the email client module 140 labeled "Mail" optionally including an indicator 410 of the number of unread emails;

o icon 420 for browser module 147 labeled "Browser"; and

o icon 422 for video and music player module 152 labeled "iPod", also referred to as iPod (trademark of Apple Inc.) module 152; and

다음과 같은, 다른 애플리케이션들용 아이콘들:

Icons for different applications, such as:

o icon 424 for IM module 141 labeled "message";

o icon 426 for calendar module 148 labeled “Calendar”;

o icon 428 for image management module 144 labeled "Photos";

o icon 430 for camera module 143 labeled “Camera”;

o icon 432 for online video module 155 labeled “Online Video”;

o icon 434 for stock widget 149-2 labeled "Stocks";

o icon 436 for map module 154 labeled “map”;

o icon 438 for weather widget 149-1 labeled “weather”;

o icon 440 for alarm clock widget 149-4 labeled “Clock”;

o icon 442 for workout support module 142 labeled “Workout Support”;

o icon 444 for notes module 153 labeled “Notes”; and

o An icon 446 for a settings application or module, labeled “Settings,” that provides access to settings for device 100 and its various applications 136 .

It should be noted that the icon labels illustrated in FIG. 4A are merely exemplary. For example, icon 422 for video and music player module 152 may optionally be labeled "Music" or "Music Player". Other labels are optionally used for various application icons. In some embodiments, the label for each application icon includes the name of the application corresponding to each application icon. In some embodiments, the label for a particular application icon is separate from the name of the application corresponding to the particular application icon.

4B illustrates a device (eg, device 300 ) having a touch-sensitive surface 451 (eg, tablet or touchpad 355 , FIG. 3 ) separate from display 450 (eg, touch screen display 112 ). ), illustrating an exemplary user interface on FIG. 3). Device 300 may also optionally include one or more contact intensity sensors (eg, one or more of sensors 357 ) and/or device 300 for detecting intensity of contacts on touch-sensitive surface 451 . one or more tactile output generators 359 for generating tactile outputs for the user of

Although some examples that follow will be provided with reference to inputs on a touch screen display 112 (a touch-sensitive surface and a display combined), in some embodiments, the device is separate from the display as shown in FIG. 4B . Detect inputs on a touch-sensitive surface. In some embodiments, the touch-sensitive surface (eg, 451 in FIG. 4B ) has a major axis (eg, 452 in FIG. 4B ) that corresponds to a major axis (eg, 453 in FIG. 4B ) on the display (eg, 450 ). According to these embodiments, the device communicates with the touch-sensitive surface 451 at positions corresponding to respective positions on the display (eg, in FIG. 4B , 460 corresponds to 468 and 462 corresponds to 470 ). Detect contacts (eg, 460 and 462 in FIG. 4B ). In this way, user inputs (eg, contacts 460 , 462 and their movements) detected by the device on the touch-sensitive surface (eg, 451 in FIG. 4B ) will not affect if the touch-sensitive surface is separate from the display. used by the device to manipulate the user interface on the display (eg, 450 in FIG. 4B ) of the multifunction device. It will be appreciated that similar methods are, optionally, used with other user interfaces described herein.

In addition, while the following examples are given primarily with reference to finger inputs (eg, finger contacts, finger tapping gestures, finger swipe gestures), in some embodiments, one or more of the finger inputs are other It will be appreciated that input from an input device (eg, mouse-based input or stylus input) is replaced. For example, a swipe gesture is optionally replaced with a mouse click (eg, instead of a contact) followed by movement of the cursor along the path of the swipe (eg, instead of movement of the contact). As another example, the tapping gesture is, optionally, replaced with a mouse click while the cursor is positioned over the location of the tapping gesture (eg, instead of detecting the contact and ceasing to detect the subsequent contact). Similarly, where multiple user inputs are detected simultaneously, it will be appreciated that multiple computer mice are, optionally, used simultaneously, or mouse and finger contacts are, optionally, used concurrently.

As used herein, the term “affordance” refers to a user-interactive graphical user interface that may be displayed on the display screen of devices 100 , 300 , and/or 500 ( FIGS. 1 , 3 , and 5 ). Refers to a user-interactive graphical user interface object. For example, an image (eg, an icon), a button, and a text (eg, a hyperlink) may each constitute an affordance.

As used herein, the term “focus selector” refers to an input element that represents the current portion of a user interface with which the user is interacting. In some implementations that include a cursor or other location marker, a touch-sensitive surface (eg, FIG. 3 ) while the cursor is over a particular user interface element (eg, a button, window, slider, or other user interface element). When an input (eg, a press input) is detected on the touch pad 355 of the touchpad 355 or the touch-sensitive surface 451 of FIG. 4B ), the cursor moves to a "focus selector" such that certain user interface elements are adjusted in accordance with the detected input. functions as " Some implementations include a touch screen display (eg, touch-sensitive display system 112 of FIG. 1A or touch screen 112 of FIG. 4A ) that enables direct interaction with user interface elements on the touch screen display. In , when an input (eg, a touch input) is detected on the touch screen display at the location of a particular user interface element (eg, a button, window, slider, or other user interface element), the particular user interface element is A contact detected on the touch screen serves as a “focus selector” to be adjusted according to the detected input. In some implementations, focus without movement of a corresponding cursor or movement of a contact on the touch screen display (eg, by moving focus from one button to another using the tab key or arrow keys). is moved from one area of the user interface to another area of the user interface; In these implementations, the focus selector moves in response to movement of focus between different areas of the user interface. Regardless of the particular form the focus selector has, the focus selector generally communicates the user's intended interaction with the user interface (eg, by informing the device which element of the user interface the user wants to interact with). A user interface element (or contact on a touch screen display) that is controlled by the user for For example, while a press input is detected on a touch-sensitive surface (eg, a touchpad or touch screen), the location of a focus selector (eg, cursor, contact, or selection box) over each button (eg, on the device's display) It will indicate that the user is about to activate the respective button (unlike the other user interface elements shown).

As used in the specification and claims, the term “characteristic intensity” of a contact refers to a characteristic of a contact based on one or more intensities of the contact. In some embodiments, the feature intensity is based on multiple intensity samples. The characteristic intensity is, optionally, for a predefined number of intensity samples, or for a predefined event (eg, after detecting the contact, before detecting liftoff of the contact, detecting the start of movement of the contact) a predetermined period of time (eg, 0.05, 0.1, 0.2) before or after, 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 , 0.5, 1, 2, 5, 10 s) based on the set of intensity samples collected. The characteristic intensity of the contact is, optionally, a maximum value of the intensities of the contact, a mean value of the intensities of the contact, an average value of the intensities of the contact, a top 10 percentile value of the intensities of the contact. ), a value of half the maximum value of the intensity of the contact, a value of 90 percent of the maximum value of the intensity of the contact, and the like. In some embodiments, the duration of the contact is used to determine the feature intensity (eg, when the feature 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 was 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 result of a contact having a characteristic intensity that does not exceed a first threshold, a first action is performed, and a result of a contact having a characteristic intensity that exceeds a first intensity threshold but does not exceed a second intensity threshold, a second An action is performed, and as a result of the contact having a characteristic intensity above the second threshold, a third action is performed. In some embodiments, the comparison between the characteristic strength and one or more thresholds is rather than used to determine whether to perform the first action or the second action, whether to perform the one or more actions (eg, whether to perform the respective action). It is used to decide whether to stop performing an individual's movement.

In some embodiments, a portion of a gesture is identified to determine a characteristic strength. For example, a touch-sensitive surface may receive successive swipe contacts moving from a starting position to an ending position, at which point the intensity of the contact increases. In this example, the characteristic intensity of the contact at the end location may be based on only a portion of the successive swipe contacts (eg, only the portion of the swipe contact at the end location) rather than the entire swipe contact. In some embodiments, a smoothing algorithm may be applied to the intensities of the swipe contact prior to determining the characteristic intensity of the contact. For example, the smoothing algorithm may optionally include an unweighted sliding-average smoothing algorithm, a triangular smoothing algorithm, a median filter smoothing algorithm, and/or an exponential smoothing algorithm. includes one or more of In some situations, these smoothing algorithms remove narrow spikes or dips in the intensities of the swipe contact to determine the characteristic intensity.

An intensity of a contact on the touch-sensitive surface may be characterized for one or more intensity thresholds, such as a touch detection intensity threshold, a light press intensity threshold, a deep press intensity threshold, and/or one or more other intensity thresholds. In some embodiments, the light press intensity threshold corresponds to the intensity at which the device will perform operations typically associated with clicking a button or trackpad of a physical mouse. In some embodiments, the deep press intensity threshold corresponds to an intensity at which the device will perform operations that are different from those typically associated with clicking a button or trackpad of a physical mouse. In some embodiments, when a contact is detected with a characteristic intensity below a light press intensity threshold (eg, and above a nominal contact detection intensity threshold, below which the contact is no longer detected), the device activates the light press intensity It will move the focus selector according to movement of the contact on the touch-sensitive surface without performing an action associated with the threshold or the deep press intensity threshold. In general, unless stated otherwise, these intensity thresholds are consistent between different sets of user interface drawings.

An increase in the characteristic intensity of a contact from an intensity below the light press intensity threshold to an intensity between the light press intensity threshold and the deep press intensity threshold is sometimes referred to as a "light press" input. An increase in the characteristic intensity of a contact from an intensity below the deep press intensity threshold to an intensity above the deep press intensity threshold is sometimes referred to as a “deep press” input. An increase in the characteristic intensity of a contact from an intensity below the touch detection intensity threshold to an intensity between the touch detection intensity threshold and the light press intensity threshold is sometimes referred to as detection of a contact on a 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 is sometimes referred to as detection of liftoff of the contact from the touch surface. In some embodiments, the touch detection intensity threshold is zero. In some embodiments, the contact detection intensity threshold is greater than zero.

In some embodiments described herein, the one or more actions include detecting a respective press input performed with a respective contact (or multiple contacts) or in response to detecting a gesture comprising the respective press input. and wherein each press input is detected based, at least in part, on detecting an increase in intensity of the contact (or plurality of contacts) above a press-input intensity threshold. In some embodiments, the respective action is performed in response to detecting an increase in the intensity of the respective contact above a press-input intensity threshold (eg, a “down stroke” of the respective press input). . In some embodiments, the press input comprises an increase in the intensity of the respective contact above the press-input intensity threshold and a subsequent decrease in the intensity of the contact below the press-input intensity threshold, wherein the respective action is below the press input intensity threshold is performed in response to detecting a subsequent decrease in the intensity of the respective contact (eg, an “up stroke” of the respective press input).

In some embodiments, the device employs intensity hysteresis to avoid sudden inputs, sometimes referred to as “jitter,” wherein the device has a hysteresis intensity threshold (e.g., , the hysteresis intensity threshold is X intensity units lower than the press-input intensity threshold, or the hysteresis intensity threshold is 75%, 90%, or any suitable percentage of the press-input intensity threshold). As such, in some embodiments, the press input comprises an increase in the intensity of the respective contact above the press-input intensity threshold and a subsequent decrease in the intensity of the contact below the hysteresis intensity threshold corresponding to the press-input intensity threshold, , the respective action is performed in response to detecting a subsequent decrease in the intensity of the respective contact below the hysteresis intensity threshold (eg, an “up stroke” of the respective press input). Similarly, in some embodiments, the press input is an increase in the intensity of the contact from an intensity below the hysteresis intensity threshold to an intensity above the press-input intensity threshold and, optionally, an intensity of the contact to an intensity below the hysteresis intensity threshold. is detected only when the device detects a subsequent decrease in , the respective action is performed in response to detecting a press input (eg, increasing the intensity of the contact or decreasing the intensity of the contact, depending on the situation).

For convenience of description, descriptions of actions performed in response to a press input associated with a press-input intensity threshold or in response to a gesture comprising a press input include, optionally, an increase in the intensity of the contact above the press-input intensity threshold; an increase in the intensity of the contact from an intensity below the hysteresis intensity threshold to an intensity above the press-input intensity threshold, a decrease in the intensity of the contact below the press-input intensity threshold, and/or a hysteresis intensity threshold corresponding to the press-input intensity threshold Triggered in response to detecting any one of a decrease in the intensity of the contact below. Further, in examples wherein the action is described as being performed in response to detecting a decrease in intensity of the contact below the press-input intensity threshold, the action is, optionally, a hysteresis corresponding to and lower than the press-input intensity threshold. performed in response to detecting a decrease in intensity of the contact below an intensity threshold.

2. Structured Proposal

In embodiments of the present disclosure, the electronic device may structure a suggested contact and calendar event for the user from their message. Suggested contacts and calendar events may be searchable as if they were manually entered by the user, and the user may choose to add or ignore (eg, reject) 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 part of the user, which can save user time, improve productivity, and create a more efficient human-machine interface.

2.1 Suggested contact information

5A illustrates an example data architecture 502A for a proposed contact, in accordance with some embodiments. As shown in FIG. 5A , electronic device 500 may associate (ie, store) contact information 520A from message 510 with corresponding contact 530A. Message 510 may include any type of message that may be sent or received by a user of device 500 , such as email, instant message, messaging through an application on device 500 , and the like, 510) may include any attachments.

Contact information 520A may include information typically associated with a contact entry in an address book database, such as an entity's name, phone number, address, business or social networking handle, and the like. Contact entries are typically organized or indexed by an entity that may include an individual, group, institution, company, or the like. Contact information 520A may be stored in any suitable format that applications such as contacts module 137 can recognize for processing contact information 520A. Contact information 520 may also be formatted according to a standard protocol, such as the CardDAV protocol, to allow updates or synchronization over a network with other clients.

In some embodiments, the identified contact information 520A may be stored in the contact 530A in any one of three mutually exclusive states: a proposed state 540 , an added state 550 , and a rejected state 560 . ) can be associated with The suggested state 540 may reflect 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 reflect a state in which the user confirms or approves addition of the contact information 520A to the contact information. The rejected state 560 may reflect a state in which the user has rejected addition of the contact information 520A to the contact list. Contact 530A may also be associated with any one of these three states if all associated contact information belongs to the same state.

In some embodiments, added state 550 may be treated by device 500 as a default state, which may include additional data to be associated with these contacts to indicate that they are in added state 550 . means that it is not required. For example, user added contacts on device 500 may default to added state 550 .

In embodiments where the added state 550 is treated as the default state, the device 500 sends the contact data to indicate that the contact information 520A belongs to the proposed state 540 or the rejected state 560 . information 520A. This data may be any such data, such as metadata, that may be used by applications processing contact information 520A to recognize that contact information 520A is in a suggested state 540 or rejected state 560 . may take any suitable form. Device 500 may also associate data with contact 530A to indicate that contact 530A and all associated contact information belong to proposed state 540 or rejected state 560 .

By storing contact information 520A in suggested state 540 , device 500 (eg, via an application running on device 500 ) can include the suggested contact information in retrieval of contacts. To avoid user confusion, device 500 may also provide a visual indication (eg, via labeling or highlighting) and/or prevent the user from taking direct action on contact information 520A (eg, may indicate to the user that contact information 520A is in suggested state 540 (by requiring the user to provide additional input prior to taking action on contact information 520A). Input may refer to any suitable manner as input such as touch, mouse, voice, and the like.

By storing the contact information 520A in the rejected state 560 , the device 500 can remember the previously suggested contact information that the user rejected so as not to suggest it to the user again. Contact information 520A in rejected state 560 may be overridden by applications processing contact information in added state 550 and proposed state 540 .

Device 500 stores contact information 520A locally on device 500 , and contact information 520A until it changes from suggested state 540 to added state 550 . ) can be suppressed from synchronizing to a remote database. In other embodiments, contact information 520A may be updated in a remote database while in suggested state 540 .

Device 500 may identify contact information 520A from structured or unstructured content in message 510 . The structured content is arranged according to a predefined format, such as an automated email provided by an online travel agency that plans flight, hotel, and/or vehicle reservation information in the same predefined manner (eg, using the same HTML structure). It refers to content that has a formal composition or structure. In some embodiments, to identify contact information 520A from structured content, device 500 may use a template configured to recognize contact information in a particular format provided by these messages. In some embodiments, device 500 may add and/or update such a template over a network.

Unstructured content refers to content that lacks formal organization or structure, such as natural language content (eg, someone says they have a new number in a message) and email signatures. To identify the contact information 520A from the unstructured content, the device 500 is configured to identify predefined references to the contact information, such as specific phrases such as "I got a new number, it's <number>." A configured data detector may be used. Device 500 may also add/update these data detectors via a network. Device 500 is configured to cross-correlate contact information (eg, in an address book database) on device 500 with a language associated with contact information (eg, in messages) on device 500 , thereby providing predefined predefined dependencies that are relied on by the data detector. References can be improved. The correlated language can then be used to refine predefined references for subsequent use. The content of the message analyzed by device 500 may include any information recognizable by device 500 including message metadata.

In some embodiments, the device receives an instruction (eg, user request) to initiate a communication (eg, phone call, instant message, email) with a contact (eg, individual or business). The device determines that the contact is not in the device's address book. In response, the device locates contact information (eg, phone number, user name, email address) based on one or more communications (eg, instant message, email, calendar entry). In other words, the device searches the entire database of potential contacts to disambiguate the requested contact referenced in the command. Optionally, the device displays a ranked list of potentially matching contacts and receives user input to select an intended contact. In response to user input selecting the intended contact, the device may initiate a communication (eg, phone call, instant message, email) with the intended contact.

2.2 Suggested event information

5B illustrates an example data architecture 502B for proposed calendar events, in accordance with some embodiments. As shown in FIG. 5B , electronic device 500 may associate (ie, store) event information 520B from message 510 with a corresponding calendar event 530B. Message 510 may include any type of message that may be sent or received by a user of device 500 , such as email, instant message, messaging through an application on the device, and the like, and may include any attachment to the message. may include

Event information 520B may include information typically associated with a calendar entry in a calendar database, such as time, date, location, and the like. Event information 520B may be stored in any suitable format that applications such as calendar module 148 can recognize to process event information 520B. Event information 520B may also be formatted according to a standard protocol, such as the CalDAV protocol, to allow updating with or synchronizing with other clients over the network.

In some embodiments, the identified event information 520B includes a calendar event ( 530B). The suggested state 540 may reflect a state in which the user has not yet confirmed or approved the addition of the event information 520B to the calendar event. The added state 550 may reflect a state in which the user confirms or approves addition of the event information 520B to the calendar event. The rejected state 560 may reflect a state in which the user rejects addition of the event information 520B to the calendar event. 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.

In some embodiments, the added state 550 may be treated by the device 500 as a default state, which is added to be associated with these calendar events to indicate that they are in the added state 550 . This means that no data is required. For example, user added calendar events on device 500 may default to added state 550 .

In embodiments where the added state 550 is treated as the default state, the device 500 event data to indicate that the event information 520B belongs to the proposed state 540 or the rejected state 560 . information 520B. This data can be any, such as metadata, that can be used by applications processing the event information 520B to recognize that the event information 520B is in a suggested state 540 or rejected state 560 . may take any suitable form. Device 500 may also associate data with calendar event 530B to indicate that calendar event 530B and all associated event information belong to suggested state 540 or rejected state 560 .

By storing event information 520B in suggested state 540 , device 500 (eg, via an application running on device 500 ) can include the suggested event information in retrieval of calendar events. . To avoid user confusion, device 500 may also provide a visual indication (eg, via labeling or highlighting) and/or prevent the user from taking direct action on event information 520B (eg, may indicate to the user that event information 520B is in suggested state 540 (by requiring the user to provide additional input prior to taking action on event information 520B). Input may refer to any suitable manner as input such as touch, mouse, voice, and the like.

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

Device 500 stores event information 520B locally on device 500 , and event information 520B until event information 520B changes from suggested state 540 to added state 550 . ) can be suppressed from synchronizing to a remote database. In other embodiments, event information 520B may be updated in a remote database while in suggested state 540 .

Device 500 may identify event information 520B from structured or unstructured content in message 510 . The structured content is arranged according to a predefined format, such as an automated email provided by an online travel agency that plans flight, hotel, and/or vehicle reservation information in the same predefined manner (eg, using the same HTML structure). It refers to content that has a formal composition or structure. In some embodiments, to identify event information 520B from structured content, device 500 may use a template configured to recognize the event information in a particular format provided by these messages. In some embodiments, device 500 may add and/or update such a template over a network.

Unstructured content refers to content that lacks formal organization or structure, such as natural language content (eg, someone says in a message where they will meet you at a specific time) and email signatures. To identify event information 520B from unstructured content, device 500 identifies predefined references to event information, such as specific phrases such as “meet me at <address> at <time>.” A configured data detector may be used. Device 500 may also add/update these data detectors over the network. Device 500 is configured to cross-correlate event information (eg, in a calendar database) on device 500 with a language associated with event information (eg, in messages) on device 500 , thereby providing predefined predefined dependencies that are relied on by the data detector. References can be improved. The correlated language can then be used to refine predefined references for subsequent use. The message analyzed by device 500 may include any information recognizable by device 500 including message metadata.

In some examples, the device identifies one or more communications (eg, email or other content) associated with a calendar event (eg, a user added calendar event or a received meeting invitation accepted by the user). For example, a device may determine that a communication is associated with a calendar event when the communication describes an event of the same or similar name, an event of 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 the communication is associated with a calendar event based on a calendar event that includes the same or similar language used in the communication. One or more communications and associated calendar events are analyzed and/or compared to better identify candidate communications for which future calendar entries should be created or proposed. For example, machine learning techniques can learn patterns of event generation by training from and/or analyzing emails on which the events are based (using a support vector machine used to generate calendar events and a corpus of emails). You can be hired to learn.

For example, the device may receive an email communication from an auto parts store that includes the language "Hi, Can you swing by the parts shop tomorrow to get the replacement part?" The email may also include an email signature including the street address of the parts store. The user can then manually create a calendar event that includes the language “swing by the parts shop to get the 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 warrants an offer for a calendar entry. The determination may be determined by a similarity between an email communication and “swing by the parts shop to get the replacement part” within a calendar event, a similarity between an email communication and a street address within a calendar event, similarity of a date/time identified within an email communication and a calendar event, or It may be based on a combination of two or more thereof.

In some examples, the device identifies event information from (eg, during) an instant message conversation (eg, an SMS or text message conversation). During a conversation, the device collects information related to the event. After the relevant portion of the conversation (eg, after a predetermined set of information has been gathered), the device generates a suggested calendar event. In some examples, the suggested calendar event is updated based on messages in the conversation sent or received after the initial suggested calendar event was created. This interactive event creation technique allows users to quickly and efficiently add events to their calendars based on messages within an instant message conversation.

For example, the device may be displaying 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 including the language "Hi, Can you swing by the parts shop tomorrow to get the replacement part?" The conversation may also include a message from the representative including the street address of the parts store. The user can answer "yes, I'll be there!" In response to the relevant portion of the conversation (eg, receiving confirmation of attendance "yes, I'll be there!"; or time "tomorrow" and location (street address)), the device generates a suggested calendar event. do. The device may set up a suggested calendar when the device subsequently receives a message from a representative indicating an updated time (eg, "Actually, tomorrow won't work, but this Friday will work."), location, or other event component. Events can be updated.

It should be appreciated that the example data architectures 520A, 520B may be the same or different. For example, a single data architecture could be used for a proposed contact as well as for a proposed calendar event. Alternatively, one data architecture may be used for the proposed contact, but another different data architecture may be used for the proposed calendar event.

It should also be appreciated that message 510 may be processed for suggested contacts only, for suggested calendar events only, or for both suggested contacts and suggested calendar events. When processed for both suggested contacts and suggested calendar events, message 510 may be processed serially or in parallel for suggested contacts and suggested calendar events. For example, message 510 may be processed first for a suggested contact and then for a suggested calendar event. Alternatively, message 510 and a copy of message 510 may be processed in parallel for suggested contacts and suggested calendar events.

In some examples, the notification or reminder is based on event information identified from structured or unstructured content in a message or other media (eg, of a visual notification, haptic notification, audio notification, or one or more notifications on device 500 ). combination) can be shown to the user. In some examples, a notification or reminder may be shown to the user even if the event information is not associated with the added state. For example, the device may remind the user to pack a bag based on an email received about an upcoming camping trip, even if the camping trip is not added to the user's calendar. Thus, reminders may be shown for calendar entries, events, and things such as being in a suggested state (eg, explicitly not accepting or rejecting).

3. User Interface and Associated Processes

6A-13 illustrate embodiments of a user interface (“UI”) and associated processes that may be implemented on device 500 . In some embodiments, device 500 corresponds to devices 100 or 300 .

6A-6G illustrate example user interfaces for providing suggested contact and calendar events, in accordance with some embodiments.

In particular, FIG. 6A illustrates having suggested contact information (ie, contact information in suggested state 540 ), eg, by contacts module 137 , eg, after processing the message as described above. Shows the display of the user interface corresponding to the contact. In this example, the contact is associated with a person named John Appleseed and has a company name ("Any Company Inc."), a work number ("405-555-1234"), and a mobile phone number ("405-123-6633"). includes The company name and work number are confirmed items of contact information and belong to the added state 550 . The mobile phone number is an item of suggested contact information and belongs to the suggested state 540 .

Device 500 may provide a user interface object 600 (eg, the word “suggestion”) in a user interface to indicate to the user that a mobile phone number is an item of suggested contact information and not confirmed by the user. there is. Any suitable user interface object may be used for this purpose, including a label, icon, or other visual indication that a mobile phone number is an item of suggested contact information. When the same contact includes items of contact information in suggested state 540 and items of contact information in added state 550 , device 500 returns to suggested state 540 , as in the case of FIG. 6A . ) may be displayed below all items in the added state 550 or in a lower priority position.

Device 500 may also prevent the user from directly calling an application (eg, phone module 138 ) to call John Appleseed at the number suggested from this initial user interface. For example, device 500 may display an established contact, such as a grayed out appearance (not shown), to indicate that selection of a number suggested by the user is not a direct call to the number. It is possible to provide text and/or regions associated with the suggested number that have a different visual appearance than the visual appearance of the item of information. Instead, upon selection of a number suggested by the user, device 500 may replace the current interface with a second user interface through which the user may review and call the suggested number.

As shown in FIG. 6B , a second user interface (labeled “review proposal”) is a proposal portion in the form of a banner that includes a user interface object 602 (labeled “Add to Contacts”) associated with the proposed number. (606). Selecting the user interface object 602 by the user may cause the device 500 to add the suggested number to a contact in the added state 550 (eg, add the suggested number's status to the suggested number). change from state 540 to added state 550). Upon selection of a mobile phone number or similar indication, such as a phone icon displayed next to the mobile phone number, by the user in this subsequent user interface, device 500 may initiate an application (eg, call John Appleseed at the suggested number). phone module 138). In some embodiments, device 500 may keep the mobile phone number in suggested state 540 if the user does not select user interface object 602 but selects a mobile phone number or similar indication (eg, For example, a user calling a suggested number will not be treated as an implied acknowledgment of the suggested number to the contact). In other embodiments, the device 500 may change the state of the mobile phone number to the added state 550 when the user selects the mobile phone number, even if the user does not select the user interface object 602 ( For example, a user calling a suggested number is treated as an implied acknowledgment of the suggested number to the contact).

The second user interface of FIG. 6B also includes a user interface object 604 (labeled “Ignore”) associated with the suggested number. Selection of user interface object 604 by a user may cause device 500 to stop displaying user interface object 602 , which removes the option of adding the number to a contact. When the user interface object 604 is selected, the device 500 may change the state of the proposed number from the proposed state 540 to the rejected state 560 . In rejected state 560 , device 500 may be configured to no longer display or suggest a suggested number associated with this contact.

The second user interface of FIG. 6B also includes a message portion 608 (labeled as “relevant email”) including a portion of the message from which the suggested number was identified by device 500 . Accordingly, upon providing an interface for reviewing the suggested contact information, the user interface of FIG. 6B may provide the user with message context associated with the suggested contact information. As shown in FIG. 6B , the device 500 may display a limited portion of the email related to the portion having a mobile phone number. Upon the user selecting the displayed portion of the message, device 500 may cause a messaging application (eg, email client module 140 ) to open the entire email for the user. In some embodiments, the entire email may be displayed with suggested contact information in a user interface corresponding to that shown in FIG. 6D .

6C illustrates a user interface displayed in response to the user of FIG. 6A selecting an “edit” user interface object. In this editorial user interface, the user can also directly dial the suggested number, represented by the user interface object 610 , which is highlighted (ie, 540 ) to indicate that the number is in the suggested state 540 . in bold). Any suitable visual indication may be used to indicate that the user interface object 610 is in the suggested state 540 .

6D is a diagram that a user may see when opening a message on device 500 (eg, an email displayed by email client module 140 ) using device 500 with suggested contact information identified in the message. shows the screen. The user interface of FIG. 6D includes a suggestion portion 612 and a message portion 614 . Message portion 614 includes the contents of a message received by device 500 . Suggestion 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, when selected, causing the device to suggest and a user interface object 618 (labeled “Add to Contacts”) associated with the identified contact information that allows the added number to be added to the contact in the added state 550 . Suggestion portion 612, when selected, causes device 500 to change the status of identified contact information from suggested state 540 to rejected state 560. User interface object 620 associated with the identified contact information. ) (labeled "ignore"). In rejected state 560 , device 500 may be configured to no longer display or suggest suggested contact information associated with this contact. Selecting the identified contact information 616 of the suggestion portion 612 above the “Ignore” and “Add to Contacts” tiles may bring up a user interface corresponding to a contact associated with the identified entity. For example, device 500 may present contact information for “John Appleseed” in a user interface corresponding to that shown in FIG. 6A in this embodiment.

6E is a diagram that a user may see when opening a message on device 500 (eg, an email displayed by email client module 140 ) using device 500 with suggested event information identified in the message. shows the screen. The user interface of FIG. 6E includes a suggestion portion 620 and a message portion 622 . Message portion 622 includes the contents of a message received by device 500 . Suggestion portion 620 includes a user interface object corresponding to the identified event information ("Dinner", "Any Sushi Bar", "Friday 7 March", or "9:50 PM"), and a device ( and a user interface object 626 (labeled “Add to Calendar”) associated with the identified event information that causes 500 to add the suggested event information to a calendar event in added state 550 . The suggestion portion 620 includes a user interface object 628 that, upon selection, causes the device 500 to change the state of the identified event information from the suggested state 540 to the rejected state 560 . In the rejected state 560 , the device 500 may be configured to no longer display or suggest suggested event information associated with this calendar event. Selecting the identified event information 624 of the suggestion portion 620 above the “Ignore” and “Add to Calendar” tiles allows the user to add event information suggested therethrough to the calendar event in the added state 550 . A user interface (not shown) corresponding to a calendar event associated with the identified event information (eg, as displayed by, for example, the contact module 137 ) may be retrieved from which a user interface object may be selected for access.

In some examples, the device may display a calendar event on a calendar of the device, the calendar event corresponding to event information in suggested state 540 . Calendar events in suggested state 540 displayed on the device's calendar may optionally be grayed out to indicate that they are in suggested state 540 . A device may be configured to enable a calendar event (eg, a user to activate an affordance associated with a calendar event) that includes at least a portion of a source of event information (eg, a portion of a communication, such as an email, upon which the suggested event information is based). When) details can be displayed. Alternatively, or in addition, the device may display an affordance that, when activated, causes the device to indicate at least a portion of a communication (eg, email) upon which the suggested event information is based. The displayed details of the suggested calendar event may also optionally include an affordance to ignore (or reject) the suggested calendar event or to accept the suggested calendar event. Thus, the user can view the suggested calendar events on the device's calendar and the user can reject or accept the suggested calendar events quickly and efficiently.

6F illustrates opening a message on device 500 (eg, an email displayed by email client module 140 ) using device 500 with a number of suggested contacts and/or calendar events identified in the message. Shows a screen that the user can see when The user interface of FIG. 6F includes a suggestion portion 630 and a message portion 632 . Message portion 632 includes the contents of a message received by device 500 . Suggestion portion 630 further includes a user selectable area that, when 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 . do. Rather than incorporating all of the suggestions of FIG. 6G into the user interface of FIG. 6F, limiting the proposal portion 630 of FIG. 6F to a single banner indicates that the proposal portion of FIG. 6F may increase the user's ability to easily view and read messages within the message portion. avoid interfering

6G illustrates a subsequent user interface with a list of identified suggested contact and event information in a message associated with the user interface of FIG. 6F. As shown in FIG. 6G , the suggestions are organized by type (eg, suggested calendar events are grouped together and suggested contacts are grouped together) and each suggestion is identified as "Ignore" and "Add to Contacts" and "Add to Contacts" as described above. Add to Calendar" feature. The user interface of FIG. 6G also allows device 500, when selected, to add each of the groupings of multiple instances of the identified contact or event information (eg, the two suggested calendar events shown in FIG. 6G ) to an added state 550 . ) includes a user interface object 634 (“Add All”) that allows adding to the corresponding contact or calendar event in the .

7A-7B illustrate a flow diagram of an example process for creating a suggested contact in accordance with some embodiments. The process may be performed in an electronic device (eg, device 500 ).

The electronic device may receive 702 a message in a received message (eg, email in message portion 614, FIG. 6D), and an entity (eg, "John Appleseed", FIG. 6D, FIG. 6D) and entity within the received message. Contact information (eg, FIG. 6D , “405-123-6633”) associated with may be identified (704). The device may determine ( 722 ) that a contact (eg, FIG. 5A , contact 530A) associated with the identified entity does not exist among the plurality of contacts in a database (eg, storage on device 500 such as an address book database), such In response to the determination, the device may create a contact associated with the entity, the created contact including contact information and an indication that the created contact is a proposed contact (eg, in suggested state 540 ) ( 724 ). When the device creates a "John Appleseed" contact as a suggested contact, each item of contact information in the contact appears as an item of suggested contact information and can be stored in the suggested state 540 or the entire contact as a whole is a suggested contact. Note also that any messages residing on the device, such as incoming and outgoing messages, may be analyzed using the disclosed process.

In some embodiments, the identified entity is a name and the identified contact information is a phone number, address, business or social networking alias (706).

In some embodiments, the device can identify the unstructured content in the message by recognizing the signature line in the message. For example, to identify an entity and associated contact information in the message, the device may identify a signature line of the message and parse the identified signature line for the entity and contact information ( 708 ). The message may include an email and the signature line may be an email signature (710). The email includes one or more previous emails within the email thread, and identifying the email signature may include analyzing 712 one or more previous emails within the email thread. By unfolding the citation layers of an email, the device can avoid misassociating contact information locations in different emails within an email thread.

In some embodiments, the device may identify unstructured content in the message by using a data detector to search for positive phrases. For example, to identify an entity and associated contact information in the message, one or more phrases may be identified in the message based on a predefined set of phrases, and the one or more identified phrases may be analyzed for the entity and contact information. There is (714). The device may update the predefined set of phrases over the network, which may cause the device to continue using the correct phrases (716). The device may also downgrade ( 718 ) one or more of the predefined phrases as a result of the request to reject the proposed contact. In other words, if users continue to decline offers identified through the use of certain phrases, that may be an indication that those phrases are incorrect. The device may also generate 720 one or more of the predefined phrases by cross-correlating the contact information in the database with a language associated with the contact information on the electronic device (eg, a message, a calendar event, etc.). In this way, the device can determine which exact language in the message with the contact information will, for example, cause the user to create or update a contact with the contact information.

In some embodiments, the suggested contact may be searchable in the view of the data architecture of FIG. 5A . For example, the device may receive a request for a contact (eg, by a user search for the contact through an application on the device) and, in response to the request for the contact, retrieve a suggested contact 726 ).

In some embodiments, in response to creation of the contact, the device may refrain from storing the suggested contact in a remote database over the network ( 728 ). For example, if the suggested contact is in the suggested state 540 , the device may prevent pushing the contact to an update or synchronization service (eg, an application on the device) that causes the contacts to be updated on multiple clients over the network. can be suppressed

In some embodiments, the device receives a request to add the suggested contact to the database (eg, FIG. 6D, “Add to Contacts” 618), and in response to the request, the created contact is a suggested contact ( For example, the created contact may be stored in the database ( 730 ) without displaying the status of the contact from the suggested status 540 to the added status 550 ). In response to a request to add a suggested contact to the database, the device stores the created contact to a remote database over the network, for example, by pushing the contact to an update or synchronization service, without any indication that the created contact is a proposed contact. It can be saved (732).

In some embodiments, the device receives a request to reject the proposed contact (eg, “Ignore” 620 , FIG. 6D ), and in response to the request to reject the proposed contact, the entity within the future message and as a result of identifying the contact information, the suggested contact may be prevented from being created in the future (734). This can be implemented by storing rejected contacts in rejected state 560 so that the device knows which ones have already been rejected.

8A-8B illustrate a flow diagram of an example process for updating an existing contact with an item of suggested contact information, in accordance with some embodiments. The process may be performed in an electronic device (eg, device 500 ).

The electronic device receives 802 a message (eg, FIG. 6D , an email in message portion 614 ), and an entity within the received message (eg, “John Appleseed”, FIG. 6D ) and contact information associated with the entity (eg, , in FIG. 6D , “405-123-6633”) may be identified ( 804 ). The device may determine ( 822 ) that a contact (eg, FIG. 5A , contact 530A) associated with the identified entity exists among the plurality of contacts in the database and that the contact does not contain an item of identified contact information. In response to this determination, the device updates the contact to include an item of contact information and an indication (eg, metadata) that the item of contact information is an item of suggested contact information (eg, within suggested state 540 ). can (824). It is also noted that any message on the device, such as incoming and outgoing messages, can be analyzed using the disclosed process.

In some embodiments, the identified entity includes a name and the identified item of contact information is a phone number, address, business or social networking alias ( 806 ).

In some embodiments, the device can identify unstructured content in a message by recognizing a signature in the message. For example, to identify an entity in the message and an item of associated contact information, the device may examine the signature line of the message and parse the identified signature line for the entity and item of contact information ( 808 ). The message may include an email and the signature line may be an email signature (810). The email includes one or more previous emails within the email thread, and identifying the email signature may include analyzing 812 one or more previous emails within the email thread. By unfolding the citation layers of an email, the device can avoid misassociating contact information locations in different emails within an email thread.

In some embodiments, the device may identify unstructured content in the message by using a data detector to search for positive phrases. For example, to identify an entity in the message and an item of associated contact information, the device identifies one or more phrases in the message based on a predefined set of phrases, and identifies the one or more identifications for entities and items of contact information. The old sphere can be analyzed (814). The device may update the predefined set of phrases over the network, which may cause the device to continue using the correct phrases (816). The device may also downgrade ( 818 ) one or more of the predefined phrases as a result of the request to reject the proposed item of contact information. In other words, if users continue to decline offers identified through the use of certain phrases, that may be an indication that those phrases are incorrect. The device may also generate 820 one or more of the predefined phrases by cross-correlating the contact information in the database with a language associated with the contact information on the electronic device (eg, a message, a calendar event, etc.). In this way, the device can determine which exact language in the message with the contact information will, for example, cause the user to create or update a contact with the contact information.

In some embodiments, the suggested contact may be searchable in the view of the data architecture of FIG. 5A . For example, a device may receive a request for a contact (eg, by a user search for a contact through an application on the device), and in response to the request for a contact, retrieve an item of suggested contact information. There is (826).

In some embodiments, in response to the update of the contact, the device may refrain from storing the item of suggested contact information to a remote database over the network ( 828 ). If the item of suggested contact information is within suggested state 540 , the device pushes the item of contact information to an update or synchronization service (eg, an application on the device) that causes the contacts to be updated on multiple clients over the network. can be deterred from doing

In some embodiments, the device receives a request to add an item of suggested contact information to a database (eg, FIG. 6B , “Add to Contact” 602 ), and in response to the request, the item of contact information is proposed The updated contact information may be stored in the database ( 830 ) without indicating that the contact information is an item of the contact information (eg, the state of the contact information is changed from the proposed state 540 to the added state 550 ). In response to a request to add an item of suggested contact information to the database, the device may cause the updated contact information to be updated, eg, by pushing the contact information to an update/sync service, without indication that the item of contact information is an item of suggested contact information. Contacts may be stored in a remote database over a network (832).

In some embodiments, the device may receive a request to reject the proposed item of contact information (eg, “Ignore” 604, FIG. 6B ) and, in response to the request, decline the proposed item of contact information. , which prevents the contact from being updated in the future with the proposed item of contact information as a result of the entity and item of contact information being identified within the future message ( 834 ). This can be implemented by storing the rejected contact information in the rejected state 560 , so that the device knows which ones have already been rejected.

9A and 9B illustrate a flow diagram of an example process for displaying a contact with suggested contact information, in accordance with some embodiments. The process may be performed in an electronic device having a display (eg, device 500 ).

The electronic device receives 902 a message (eg, FIG. 6D, email in message portion 614), and within the received message, an entity (eg, “John Appleseed”, FIG. 6D ) and contact information associated with the entity ( 6D, “405-123-6633”) can be identified 904 . The device can generate ( 906 ) an indication (eg, metadata) that the identified contact information is suggested contact information, and display ( 908 ) a first user interface (eg, FIG. 6A ) corresponding to a contact associated with the entity. ). The first user interface may include a first user interface object (eg, “suggestion”) indicating, based on the generated indication, that the identified contact information is suggested contact information.

In some embodiments, the device may prevent an input corresponding to selection of suggested contact information from invoking an application to contact the entity ( 910 ) (eg, FIG. 6A , selecting a suggested number is a number not calling ).

In some embodiments, the device detects an input corresponding to selection of suggested contact information in the first user interface, and in response to detection, an identification that, when selected, causes the electronic device to add the identified contact information to a database A second user interface (FIG. 6B) including a second UI object (eg, "Add to Contacts" 602, FIG. 6B) associated with the contact information may be displayed (912). The second user interface may cause a third user interface object associated with the identified contact information that, when selected, causes the electronic device to stop displaying the second user interface object (eg, “Ignore” 604 , FIG. 6B ). may include (914). Displaying the second user interface may stop displaying the first user interface ( 916 ). In response to adding the identified contact information to the database, the device stops displaying the first user interface object ( 918 ).

In some embodiments, the second user interface may display ( 920 ) at least a portion of a message (eg, FIG. 6B , “Related Email”). The device detects input corresponding to selection of the displayed message, and in response to the detection, invokes an application (eg, email client module 140 ) to open the message (eg, FIG. 6D ) 922 . The message may be an email and the application may be an email application ( 924 ).

In some embodiments, the device detects an input corresponding to a selection of suggested contact information in the second user interface, and, in response to the detection, an application (eg, a phone module) to contact the entity using the identified contact information. (138)) may be called (926). In response to detecting an input corresponding to a selection of suggested contact information in the second user interface, the device may add 928 the identified contact information to a database (eg, add a status of the contact information to a suggested status 540 ). ) to added state (550)). In response to adding the identified contact information to the database, the device stops displaying the first user interface object ( 918 ).

10 illustrates a flow diagram of an example process for presenting suggested contact information with a message, in accordance with some embodiments. The process may be performed in an electronic device having a display (eg, device 500 ).

The electronic device receives 1002 a message (eg, FIG. 6D , an email in message portion 614 ), and within the received message, an entity (eg, “John Appleseed”, FIG. 6D ) and contact information associated with the entity ( 6D, “405-123-6633”) can be identified ( 1004 ). The message may be an email ( 1006 ). The identified entity may be a name, and the identified contact information may be a phone number, address, business or social networking alias ( 1008 ).

The device may display a first user interface (eg, FIG. 6D ) corresponding to the received message ( 1010 ). The first user interface includes a first portion (eg, FIG. 6D , message portion 614 ) that includes content of a message received at the electronic device, and a first user interface object corresponding to the identified entity (eg, FIG. 6D , FIG. 6D , "John Appleseed"), a second user interface object corresponding to the identified contact information (eg, FIG. 6D , "405-123-6633"), and when selected cause the electronic device to add the identified contact information to the database ( A second portion (eg, FIG. 6D , suggested portion) that includes a third user interface (eg, FIG. 6D , “Add to Contacts” 618 ) associated with the identified contact information that causes the contact information to be stored as a contact. (612)). The second portion may include a fourth user interface object (eg, “Ignore” 620 , FIG. 6D ) associated with the identified contact information that, when selected, causes the electronic device to stop displaying the third user interface object. can (1012).

11A and 11B illustrate a flow diagram of an example process for creating a suggested calendar event in accordance with some embodiments. The process may be performed in an electronic device (eg, device 500 ).

The electronic device receives 1102 a message (eg, FIG. 6E, email in message portion 622), and within the received message, event information (eg, FIG. 6E, "Dinner", "Any Sushi Bar", " Friday, March 7", or "9:50 PM") can be identified ( 1104 ). The device may generate a calendar event (eg, FIG. 5B , calendar event 530B) associated with the identified event information, wherein the generated calendar event includes event information, and a calendar event (eg, a proposal) for which the generated calendar event is proposed. and an indication (eg, meta data) (eg, metadata) ( 1122 ).

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

In some embodiments, the device may identify structured content within a message by using a template configured to recognize event information in a specific format provided by such messages. For example, to identify event information in the message, the device identifies, from a set of predefined templates, a template configured to identify a format of content in the message, recognize event information in a format of content in the message, and The identified template for information may be used to analyze the content ( 1108 ). The message may include an email and the content may include a reservation (eg, FIG. 6E ) ( 1110 ). The device may update the predefined set of templates over the network, which may cause the device to continue using the correct template ( 1112 ).

In some embodiments, the device may identify unstructured content in the message by using a data detector to retrieve references to event information. For example, to identify event information in a message, the device identifies one or more references to a date and time in the message based on a predefined set of references to the date and time, and identifies the date and time for the event information. One or more identified references to time may be resolved ( 1114 ). The device may update the predefined set of references to the date and time over the network, which may cause the device to continue using the correct references ( 1116 ). The device may downgrade ( 1118 ) one or more of the predefined references to a date and time as a result of the request to reject the proposed calendar event. In other words, if users continue to decline offers identified through the use of specific references to date and time, that may be an indication that those references are inaccurate. The device may create ( 1120 ) one or more of the predefined references to a date and time by cross-correlating event information in a database comprising a plurality of calendar events with a language associated with the event information on the electronic device. In this way, the device can better determine what language in the message with the event information, for example, causes the user to create or update a calendar event with the event information.

In some embodiments, the suggested calendar event may be searchable in the view of the data architecture of FIG. 5 . For example, the device may receive a request for a calendar event (eg, by a user search for a calendar event through an application on the device) and, in response to the request for a calendar event, retrieve a suggested calendar event. may (1124).

In some embodiments, in response to generating the calendar event, the device may refrain from storing the suggested calendar event to a remote database over the network ( 1126 ). For example, if the suggested calendar event is in the suggested state 540 , the device sends the calendar event to an update or synchronization service (eg, an application on the device) that causes the calendar events to be updated on multiple clients over a network. Pushing can be suppressed.

In some embodiments, the device receives a request to add a suggested calendar event (eg, FIG. 6E , “Add to Calendar” 626 ) to a database comprising a plurality of calendar events, and in response to the generated The generated calendar event may be stored in a database 1128 without an indication that the calendar event is a suggested calendar event (eg, changing the status of the calendar event from the suggested status 540 to the added status 550 ). ). In response to a request to add the suggested calendar event to the database, the device may network the generated calendar event without an indication that the generated calendar event is a suggested calendar event, eg, by pushing the calendar event to an update or synchronization service. It can be stored in a remote database through (1130).

In some embodiments, the device receives a request to reject the proposed calendar event (eg, “Ignore” 628 , FIG. 6E ), and in response to the request to reject the proposed calendar event, in a future message As a result of identifying event information in , it is possible to prevent a proposed calendar event from being generated in the future ( 1132 ). This can be implemented by storing the rejected event in the rejected state 560 , so that the device knows which ones have already been rejected.

12 illustrates a flow diagram of an example process for presenting suggested event information with a message, in accordance with some embodiments. The process may be performed in an electronic device having a display (eg, device 500 ).

The electronic device receives 1202 a message (eg, FIG. 6E, email in message portion 622), and within the received message, event information (eg, FIG. 6E, "Dinner", "Any Sushi Bar", " Friday, March 7", or "9:50 PM") may be identified ( 1204 ). The message may be an email ( 1206 ). The identified event information may be a date and time ( 1208 ).

The device may display a first user interface (eg, FIG. 6E ) corresponding to the received message ( 1210 ). The first user interface includes a first portion (eg, FIG. 6E , message portion 622 ) including content of a message received by the electronic device, and a first user interface object (eg, FIG. 6E ) corresponding to the identified event information. 6e, “Dinner,” “Any Sushi Bar,” “Friday, March 7,” or “9:50 PM”), and when selected, causes the electronic device to store the identified event information into a database including a plurality of calendar events. A second portion (eg, “Add to Calendar” 626 ) that includes a second user interface object (eg, FIG. 6E , “Add to Calendar” 626) associated with the identified event information that allows adding to (eg, storing the event information as a calendar event). 6e, a suggestion portion 620). The second portion includes a third user interface object (eg, FIG. 6E , “ignore” 628 ) associated with the identified event information that, when selected, causes the electronic device to stop displaying the second user interface object. (1212).

13 illustrates a flow diagram of an example process for displaying multiple suggested contact or event information with a message, in accordance with some embodiments. The process may be performed in an electronic device having a display (eg, device 500 ).

The electronic device receives 1302 a message (eg, FIG. 6F , an email in message portion 632 ), and, within the received message, multiple instances of contact or event information (eg, FIG. 6F , an attached itinerary). "2 events, 1 contact") in 1304 .

The device may display ( 1306 ) a first user interface (eg, FIG. 6F ) corresponding to the received message. The first user interface includes a first portion (eg, FIG. 6F , message portion 632 ) that includes content of a message received by the electronic device and, when selected, causes the electronic device to identify a plurality of instances of the contact or event information. and a second portion (eg, FIG. 6f , suggestion portion 630 ) for displaying a second user interface ( FIG. 6G ) that includes a list of those.

In some embodiments, the device detects an input corresponding to selection of the second portion of the first user interface, and in response to the detection, a list of multiple instances of the identified contact or event information, and the identified contact or event a first user interface object (eg, storing event information as a calendar event, or contact information as a contact) that, when selected, causes the electronic device to add the identified information to a database (eg, store event information as a calendar event, or contact information as a contact) for each of the plurality of instances of information , FIG. 6G , “add to calendar”, or “add to contact” ( 1308 ). The second user interface includes a second user interface object (eg, FIG. 6G ) that, when selected, causes the electronic device to stop displaying the first user interface object for each of the plurality of instances of the identified contact or event information. , "ignore") (1310). The second user interface is a third user interface object (eg, FIG. 6G ) that, when selected, causes the electronic device to add each of the identified contact or grouping of multiple instances of event information (eg, a calendar event or contact) to the database. , "add all" (634)) (1312). Displaying the second user interface may stop displaying the first user interface ( 1314 ).

It should be understood that the specific order in which the operations in FIGS. 7A-13 are described is exemplary and is not intended to indicate that the described order is the only order in which the operations may be performed. Those of ordinary skill in the art will recognize various ways of reordering the operations described herein. For the sake of brevity, these details are not repeated here. Additionally, it should be noted that aspects of processes 700 - 1300 ( FIGS. 7-13 ) may be combined with each other.

Operations in the information processing processes described above may be implemented by operating one or more functional modules in an information processing apparatus such as general-purpose processors or application-specific chips. All of these modules, combinations of these modules, and/or combinations thereof with general hardware (eg, as described above with respect to FIGS. 1A , 1B and 3 ) are included within the protection scope of the present invention.

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

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

The functional blocks of device 1400 are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described examples. Those skilled in the art will appreciate that the functional blocks described in FIG. 14 may optionally be combined or separated into sub-blocks to implement the principles of the various described examples. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

15 depicts example functional blocks of an electronic device 1500 that, in some examples, performs the features described above. As shown in FIG. 14 , the electronic device 1500 includes a display unit 1402 configured to display graphic objects; a touch-sensitive surface unit 1504 configured to accept user gestures; one or more RF units 1506 configured to detect and communicate with external electronic devices; and a processing unit 1508 coupled to the display unit 1502 , the touch-sensitive surface unit 1504 , and the RF units 1506 .

In some embodiments, processing unit 1508 is configured to support one or more of units 1510 - 1520 to perform the various functions described above. For example, the receiving unit 1510 is configured to perform any of the receiving functions described above (eg, receiving a message). The identification unit 1512 is configured to perform one or more of the identification functions described above (eg, to identify, within a received message, an entity and contact information associated with the entity; for event information within a received message) identifying; or identifying multiple instances of contact or event information within a received message). The determining unit 1514 is configured to perform one or more of the above-described determining functions (eg, determining that a contact associated with the identified entity does not exist among the plurality of contacts in the database; determining that the contact exists among a plurality of contacts in the database and that the contact does not contain an entry in the identified contact information). The generating unit 1516 is configured to perform one or more of the generating steps described above (eg, in response to a determination, generating a contact associated with the entity; providing an indication that the identified contact information is suggested contact information; generating; generating a calendar event associated with the identified event information). The updating unit 1518 is configured to perform one or more of the updating steps described above (eg, in response to determining, an item of contact information, and an indication that the item of contact information is an item of suggested contact information). updating your contacts to include ). The display unit 1520 is configured to perform one or more of the display steps described above (eg, display, for example, on the display unit 1502 , a first user interface corresponding to an entity or a contact associated with the received message) to do).

The functional blocks of device 1500 are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described examples. Those skilled in the art will appreciate that the functional blocks described in FIG. 15 may optionally be combined or separated into sub-blocks to implement the principles of the various described examples. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

16 shows a functional block diagram of an electronic device 1600 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 16 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 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 units 1606 . In some embodiments, processing unit 1608 includes receiving unit 1610 , identifying unit 1612 , determining unit 1614 , generating unit 1616 , analyzing unit 1618 , updating unit 1620 , downgrade a unit 1622 , a retrieval unit 1624 , a storage suppression unit 1626 , a storage unit 1628 , and a prevent unit 1630 .

The processing unit 1608 is configured to receive a message (eg, using the receiving unit 1610 ); identify, within the received message, the entity and contact information associated with the entity (eg, using the identification unit 1612 ); determine (eg, using determining unit 1614 ) that a contact associated with the identified entity does not exist among the plurality of contacts in the database; In response to the determination, generate (eg, using generating unit 1616 ) a contact associated with the entity, the generated contact including contact information and an indication that the created contact is a suggested contact.

In some embodiments, the identified entity includes a name and the identified contact information includes a phone number, address, business or social networking alias.

In some embodiments, to identify, processing unit 1608 identifies (eg, using identification unit 1612 ) a signature line of the message; and to parse (eg, with analysis unit 1618 ) the identified signature line for entity and contact information.

In some embodiments, the message includes an email and the signature line includes an email signature.

In some embodiments, the email includes one or more previous emails within the email thread, and to identify an email signature, processing unit 1608 is configured to analyze one or more previous emails within the email thread (eg, analysis unit 1618)) is further constructed.

In some embodiments, to identify, processing unit 1608 is configured to identify (eg, using identification unit 1612 ) one or more phrases within a message based on a predefined set of phrases; and analyze (eg, with analysis unit 1618 ) the one or more identified phrases for entity and contact information.

In some embodiments, the processing unit 1608 is further configured to update (eg, using the update unit 1620 ) the predefined set of phrases over the network.

In some embodiments, the processing unit 1608 is further configured to downgrade (eg, using the downgrade unit 1622 ) one or more of the predefined phrases as a result of the request to reject the proposed contact. do.

In some embodiments, processing unit 1608 generates (eg, generating unit 1616 ) one or more of the predefined phrases by cross-correlating the contact information in the database with a language associated with the contact information on the electronic device. using) is further constructed.

In some embodiments, processing unit 1608 receives a request for a contact (eg, with receiving unit 1610 ); and in response to the request for the contact, retrieve the suggested contact (eg, using the retrieval unit 1624 ).

In some embodiments, processing unit 1608 is further configured, in response to creation of the contact, to refrain from storing the proposed contact in a remote database over the network (eg, storage suppression unit 1626 ).

In some embodiments, processing unit 1608 receives (eg, using receiving unit 1610 ) a request to add a suggested contact to a database; and in response to the request to add the suggested contact to the database, store (eg, using the storage unit 1628 ) the created contact in the database without an indication that the created contact is a proposed contact.

In some embodiments, processing unit 1608, in response to a request to add a suggested contact to the database, is configured to store the created contact in a remote database over a network without an indication that the created contact is a proposed contact ( eg, using storage unit 1628).

In some embodiments, processing unit 1608 is configured to receive a request to reject the proposed contact (eg, using receiving unit 1610 ); and in response to the request to reject the proposed contact, further configure (eg, with the prevention unit 1630 ) to prevent future creation of the proposed contact as a result of the entity and contact information being identified within the future message. do.

The operations described above with reference to FIGS. 7A and 7B are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 16 . For example, the receive operation of block 702 , the identify operation of block 704 , the determine operation of block 722 , the create operation of block 724 , the receive operation of block 726 , and the receive operation of block 728 . The storage suppression operation may be implemented by the event classifier 170 , the event recognizer 180 , and the event handler 190 . The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

17 shows a functional block diagram of an electronic device 1700 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 17 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 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, processing unit 1708 includes receiving unit 1710 , identifying unit 1712 , determining unit 1714 , generating unit 1716 , analyzing unit 1718 , updating unit 1720 , downgrade a unit 1722 , a retrieval unit 1724 , a storage suppression unit 1726 , a storage unit 1728 , and a prevent unit 1730 .

The processing unit 1708 is configured to receive the message (eg, using the receiving unit 1710 ); identify within the received message an entity and an item of contact information associated with the entity (eg, using identification unit 1712 ); determine (eg, using determining unit 1714 ) that a contact associated with the identified entity exists among the plurality of contacts in the database and the contact does not contain an item of identified contact information; In response to the determining step, update the contact (eg, using the update unit 1720 ) to include the item of contact information and an indication that the item of contact information is an item of suggested contact information.

In some embodiments, the identified entity includes a name and the identified item of contact information includes a phone number, address, business or social networking alias.

In some embodiments, to identify, processing unit 1708 identifies (eg, using identification unit 1712 ) a signature line of the message; and to parse (eg, with analysis unit 1718 ) the identified signature line for entities and items of contact information.

In some embodiments, the message includes an email and the signature line includes an email signature.

In some embodiments, the email includes one or more previous emails within the email thread, and to identify an email signature, processing unit 1708 is configured to analyze one or more previous emails within the email thread (eg, analysis unit 1718)) is further constructed.

In some embodiments, to identify, processing unit 1708 is configured to identify (eg, using identification unit 1712 ) one or more phrases within a message based on a predefined set of phrases; and to analyze (eg, with analysis unit 1718 ) the one or more identified phrases for entities and items of contact information.

In some embodiments, the processing unit 1708 is further configured to update (eg, using the update unit 1720 ) the predefined set of phrases over the network.

In some embodiments, the processing unit 1708 downgrades (eg, uses the downgrade unit 1722 ) one or more of the predefined phrases as a result of a request to reject the proposed item of contact information. ) is more structured.

In some embodiments, the processing unit 1708 generates (eg, generating unit 1716 ) one or more of the predefined phrases by cross-correlating the contact information in the database with a language associated with the contact information on the electronic device. using) is further constructed.

In some embodiments, processing unit 1708 receives a request for a contact (eg, with receiving unit 1710 ); and in response to the request for the contact, retrieve (eg, using the retrieval unit 1724 ) the item of suggested contact information.

In some embodiments, processing unit 1708 may, in response to the update of the contact, refrain from storing the item of suggested contact information in a remote database over the network (eg, storage suppression unit 1726 ). there is.

In some embodiments, processing unit 1708 receives (eg, using receiving unit 1710 ) a request to add an item of suggested contact information to a database; In response to a request to add an item of suggested contact information to the database, store (e.g., storage unit 1728) the updated contact to the database, without indication that the item of contact information is an item of suggested contact information. using) is further constructed.

In some embodiments, processing unit 1708, in response to a request to add an item of suggested contact information to the database, connects the updated contact to the network without an indication that the item of contact information is an item of suggested contact information. and store (eg, using storage unit 1728) to a remote database via

In some embodiments, processing unit 1708 receives a request to reject the proposed item of contact information (eg, using receiving unit 1710 ); In response to a request to decline an item of proposed contact information, prevent the contact from being updated in the future with the item of suggested contact information as a result of the entity and item of contact information being identified within future messages (e.g., , using the prevention unit 1730) is further configured.

The operations described above with reference to FIGS. 8A and 8B are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 17 . For example, the receiving operation of block 802 , the identifying operation of block 804 , the determining operation of block 822 , and the updating operation of block 824 are the event classifier 170 , the event recognizer 180 and the It may be implemented by the event handler 190 . The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

18 shows a functional block diagram of an electronic device 1800 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 18 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 18 , the electronic device 1800 includes a display unit 1802 configured to display graphic objects; one or more RF units 1806 configured to communicate with external electronic devices; and a processing unit 1808 coupled to the splay 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 .

The processing unit 1808 is configured to receive the message (eg, using the receiving unit 1810 ); identify, within the received message, the entity and contact information associated with the entity (eg, using identification unit 1812 ); generate (eg, using generating unit 1814 ) an indication that the identified contact information is suggested contact information; Enable display of a first user interface corresponding to a contact associated with the entity (eg, with display enabling unit 1816 ), wherein the first user interface is configured to: based on the generated indication, the identified contact and a first user interface object indicating that the information is suggested contact information.

In some embodiments, processing unit 1808 is further configured to prevent (eg, with prevent unit 1818 ) input corresponding to selection of suggested contact information from invoking an application to contact the entity. is composed

In some embodiments, processing unit 1808 detects (eg, using detection unit 1820 ) an input corresponding to selection of suggested contact information of the first user interface; In response to detecting an input corresponding to a selection of suggested contact information in the first user interface, 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. and enable display of a second user interface comprising (eg, with display enabling unit 1816 ).

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 stop displaying the second user interface object.

In some embodiments, displaying the second user interface stops displaying the first user interface.

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

In some embodiments, processing unit 1808 detects (eg, with detection unit 1820 ) an input corresponding to selection of the displayed message; and in response to detecting an input corresponding to selection of the displayed message, invoke (eg, using the calling unit 1822 ) the application to open the message.

In some embodiments, the message includes an email and the application includes an email application.

In some embodiments, processing unit 1808 detects (eg, using detection unit 1820 ) an input corresponding to selection of suggested contact information of the second user interface; In response to detecting an input corresponding to selection of suggested contact information of the second user interface, invoke (eg, using calling unit 1822 ) the application to contact the entity using the identified contact information. ) is further constructed.

In some embodiments, processing unit 1808 is responsive to detecting input corresponding to selection of suggested contact information in the second user interface to add the identified contact information to a database (eg, add unit 1824) is further constructed.

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

The operations described above with reference to FIGS. 9A and 9B are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 18 . For example, the receiving operation of block 902 , the identifying operation of block 904 , the generating operation of block 906 , and the displaying operation of block 908 are the event classifier 170 , the event recognizer 180 , and the event handler 190 . The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

19 shows a functional block diagram of an electronic device 1900 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 19 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 19 , the electronic device 1900 includes a display unit 1902 configured to display graphic 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 .

The processing unit 1908 is configured to receive the message (eg, using the receiving unit 1910 ); identify, within the received message, the entity and contact information associated with the entity (eg, using the identification unit 1912 ); configured to enable (eg, with display enabling unit 1914 ) display of a first user interface corresponding to the received message, wherein the first user interface includes: content of the message received by the electronic device a first part comprising; and a first user interface object corresponding to the identified entity; a second user interface object corresponding to the identified contact information; and a second portion comprising 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 the database.

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 stop displaying the third user interface object.

In some embodiments, the message comprises an email.

In some embodiments, the identified entity includes a name and the identified contact information includes a phone number, address, business or social networking alias.

The operations described above with reference to FIG. 10 are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 19 . For example, the receive operation of block 1002 , the identify operation of block 1004 , and the display operation of block 1010 are performed by the event classifier 170 , the event recognizer 180 , and the event handler 190 . can be implemented. The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

20 shows a functional block diagram of an electronic device 2000 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 20 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 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, processing unit 2008 includes receiving unit 2010 , identifying unit 2012 , generating unit 2014 , analyzing unit 2016 , updating unit 2018 , downgrading unit 2020 , searching a unit 2022 , a storage suppression unit 2024 , a storage unit 2026 , and a prevention unit 2028 .

The processing unit 2008 is configured to receive the message (eg, using the receiving unit 2010 ); identify event information within the received message (eg, using the identification unit 2012 ); and generate (eg, using generating unit 2014 ) a calendar event associated with the identified event information, the generated calendar event comprising the event information and an indication that the generated calendar event is a suggested calendar event. .

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

In some embodiments, to identify, processing unit 2008 identifies (eg, using identification unit 2012 ) the format of the content within the message; identify (eg, using the identification unit 2012 ) a template configured to recognize event information in a format of content in the message from the set of predefined templates; and to analyze the content using the identified template for the event information (eg, using the analysis unit 2016 ).

In some embodiments, the message includes an email and the content includes a reservation.

In some embodiments, the processing unit 2008 is further configured to update (eg, using the update unit 2018 ) the set of predefined templates over the network.

In some embodiments, to identify, processing unit 2008 identifies in the message one or more references to a date and time based on a predefined set of references to the date and time (eg, using identification unit 2012); and to analyze (eg, using the analysis unit 2016 ) the one or more identified references to dates and times for event information.

In some embodiments, processing unit 2008 is further configured to update (eg, using update unit 2018 ) the set of predefined references to date and time over the network.

In some embodiments, processing unit 2008 is configured to downgrade (eg, downgrade unit ( 2020) is further constructed.

In some embodiments, processing unit 2008 references one or more of the predefined references to a date and time by correlating event information in a database comprising a plurality of calendar events with a language associated with the event information on the electronic device. and to generate (eg, using the generating unit 2014 ).

In some embodiments, processing unit 2008 receives a request for a calendar event (eg, using receiving unit 2010 ); and in response to the request for the calendar event, retrieve (eg, using the search unit 2022 ) the suggested calendar event.

In some embodiments, processing unit 2008, in response to generation of the calendar event, is configured to refrain from storing the suggested calendar event in a remote database over a network (eg, using storage suppression unit 2024 ). ) is further constructed.

In some embodiments, processing unit 2008 receives (eg, using receiving unit 2010 ) a request to add a suggested calendar event to a database including a plurality of calendar events; In response to a request to add the suggested calendar event to the database, store the generated calendar event in the database (eg, using the storage unit 2026 ) without an indication that the generated calendar event is a proposed calendar event. more composed.

In some embodiments, processing unit 2008, in response to a request to add the suggested calendar event to the database, without an indication that the generated calendar event is a proposed calendar event, is configured to: and to store (eg, using storage unit 2026 ) in .

In some embodiments, the processing unit 2008 is configured to receive a request to reject the proposed calendar event (eg, using the receiving unit 2010 ); and in response to the request to reject the proposed calendar event, prevent (eg, with the preventing unit 2028 ) from being generated in the future as a result of the event information being identified in the future message.

The operations described above with reference to FIGS. 11A and 11B are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 20 . For example, the receiving operation of block 1102 , the identifying operation of block 1104 , and the generating operation of block 1122 are performed by the event classifier 170 , the event recognizer 180 , and the event handler 190 . can be implemented. The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

21 shows a functional block diagram of an electronic device 2100 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 21 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 21 , the electronic device 2100 includes a display unit 2102 configured to display graphic 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 .

The processing unit 2108 is configured to receive a message (eg, using the receiving unit 2110 ); identify event information within the received message (eg, using the identification unit 2112 ); configured to enable display of a first user interface corresponding to the received message (eg, using the display enabling unit 2114 ), the first user interface comprising: content of the message received by the electronic device a first part comprising; and a second portion, the second portion comprising: 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 comprising a plurality of calendar events.

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 stop displaying the second user interface object.

In some embodiments, the message comprises an email.

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

The operations described above with reference to FIG. 12 are optionally implemented by the components shown in FIGS. 1A and 1B or FIG. 21 . For example, the receive operation of block 1202 , the identify operation of block 1204 , and the display operation of block 1210 are performed by the event classifier 170 , the event recognizer 180 , and the event handler 190 . can be implemented. The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components shown in FIGS. 1A and 1B .

22 shows a functional block diagram of an electronic device 2200 configured in accordance with the principles of various described embodiments, in accordance with some embodiments. The functional blocks of the device are, optionally, implemented by hardware, software, or a combination of hardware and software for carrying out the principles of the various described embodiments. It is understood by those skilled in the art that the functional blocks described in FIG. 22 may be optionally combined or separated into sub-blocks to implement the principles of the various described embodiments. Accordingly, the description herein supports, optionally, any possible combination or separation or further definition of the functional blocks described herein.

As shown in FIG. 22 , the electronic device 2200 includes a display unit 2202 configured to display graphic 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 .

The processing unit 2208 is configured to receive a message (eg, using the receiving unit 2210 ); identify (eg, using identification unit 2212 ) multiple instances of contact or event information within the received message; configured to enable (eg, with display enabling unit 2214 ) display of a first user interface corresponding to the received message, the first user interface comprising: content of the message received by the electronic device a first part comprising; and a second portion that, when selected, causes the electronic device to display a second user interface comprising a list of the plurality of instances of the identified contact or event information.

In some embodiments, the processing unit 2208 detects (eg, with the detection unit 2216 ) an input corresponding to selection of the second portion of the first user interface; in response to detecting an input corresponding to selection of the second portion of the first user interface, a list of the plurality of instances of the identified contact or event information; and to enable display of a second user interface for each of the plurality of instances of the identified contact or event information, the second user interface comprising a first user interface object that, when selected, causes the electronic device to add the identified information to the database. (eg, using the display enabling unit 2214 ).

In some embodiments, the second user interface causes the electronic device to stop displaying the first user interface object when selected, for each of the plurality of instances of the identified contact or event information. contains objects.

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

In some embodiments, enabling display of the second user interface stops display of the first user interface.

The operations described above with reference to FIG. 13 are optionally implemented by the components shown in FIGS. 1A and 1B or 22 . For example, the receive operation of block 1302 , the identify operation of block 1304 , and the display operation of block 1306 are performed by the event classifier 170 , the event recognizer 180 , and the event handler 190 . can be implemented. The event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive display 112 , and the event dispatcher module 174 communicates the event information to the application 136 - 1 . A respective event recognizer 180 of the application 136-1 compares the event information to a respective event definition 186, wherein a first contact at a first location on the touch-sensitive surface corresponds to activation of an affordance on the user interface. Determines whether it corresponds to the same predefined event or sub-event. 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 the data updater 176 or the object updater 177 to update the application internal state 192 . In some embodiments, event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, how other processes may be implemented based on the components shown in FIGS. 1A and 1B will be apparent to those of ordinary skill in the art.

The foregoing description, for purposes of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments are chosen and described in order to best explain the concept of the techniques and their practical application. Accordingly, those skilled in the art will be able to best utilize the techniques and various embodiments with various modifications as are suited to the particular use contemplated.

While 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. It is to be understood that such changes and modifications are included within the scope of the disclosure and examples as defined by the claims.

As noted above, one aspect of the present technology is the collection and use of data available from a variety of sources to improve delivery of invitation content, or any other content that may be of interest to them, to users. The present invention contemplates that, in some cases, such collected data may include personal information data that may be used to uniquely identify or contact or identify a particular individual's location. Such personal information data may include demographic data, location-based data, phone numbers, email addresses, home addresses, or any other identifying information.

The present invention recognizes that such use of personal information data in the present technology can be used to benefit users. For example, personal information data may be used to deliver targeted content of greater interest to a user. Accordingly, the use of such personal information data enables calculated control of the delivered content. In addition, other uses for personal information data that benefit users are also contemplated by this disclosure.

This disclosure further contemplates that entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities must implement and continue to use privacy policies and practices that are generally recognized as meeting or exceeding industrial or administrative requirements for keeping personal information data private and secure. For example, personal information from users should be collected for lawful and appropriate uses of the entity and not shared or sold outside of these lawful uses. Moreover, such collection should only occur after receiving informed consent from users. Additionally, such entities will take any necessary steps to protect and secure access to such personal information data and to ensure that others having access to personal information data adhere to their privacy policies and procedures. . In addition, such entities may themselves be assessed by third parties to prove their adherence to widely accepted privacy policies and practices.

Notwithstanding the foregoing, this disclosure also contemplates embodiments in which a user selectively blocks the use of, or access to, personal information data. That is, this 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 advertising delivery services, the technology may be configured to allow users to select "I agree" or "I do not agree" to participate in the collection of personal information data during registration for the service. there is. In another example, users may choose not to provide location information for targeted content delivery services. In another example, users may choose not to provide accurate location information, but allow delivery of location zone information.

Accordingly, while the present invention broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the invention also recognizes that various embodiments may also be implemented without the need to access such personal information data. consider That is, various embodiments of the present technology are not rendered inoperable due to lack of all or a portion of such personal information data. For example, content may include non-personal data such as content requested by a device associated with a user, other non-personal information available for content delivery services, or publicly available information or a basic minimal amount of personal information. It may be selected and delivered to users by inferring a preference based on the .

Claims (17)

As a method,
In an electronic device with a display:
receiving a message comprising unstructured content;
in response to receiving the message, identifying event information in the unstructured content;
in response to identifying the event information, generating a calendar event associated with the identified event information;
In response to the request to view the received message, on the display:
at least a portion of the received message;
an indication that the generated calendar event is a suggested calendar event; and
Rejection affordance for the generated calendar event
simultaneously displaying;
while displaying the rejection affordance for the generated calendar event on the display, detecting selection of the rejection affordance; and
In response to detecting selection of the rejection affordance:
ceasing to display an indication that the generated calendar event is a suggested calendar event; and
maintaining display of at least a portion of the received message;
How to include. The method of claim 1 , wherein the identified event information includes a date and time. The method of claim 1 , wherein identifying the event information comprises:
identifying a format of content in the message;
identifying a template from a set of predefined templates configured to recognize event information in the format of the content in the message; and
parsing the content with the identified template for the event information;
How to include. 4. The method of claim 3, wherein the message comprises an email and the content comprises a reservation. 4. The method of claim 3,
The method further comprising updating the set of predefined templates via a network. The method of claim 1 , wherein identifying the event information comprises:
identifying one or more references to a date and time in the message based on a predefined set of references to the date and time; and
and resolving the one or more identified references to a date and time against the event information. 7. The method of claim 6,
The method further comprising updating the predefined set of references to date and time via a network. 7. The method of claim 6,
downgrading one or more of the predefined references to a date and time as a result of the request to reject the proposed calendar event. 7. The method of claim 6,
generating one or more of the predefined references to a date and time by cross-correlating event information in a database comprising a plurality of calendar events with a language associated with the event information on the electronic device. According to claim 1,
receiving a request for a calendar event; and
responsive to the request for the calendar event, further comprising retrieving the suggested calendar event. According to claim 1,
and in response to generating the calendar event, refraining from storing the suggested calendar event to a remote database over a network. According to claim 1,
receiving a request to add the suggested calendar event to a database comprising a plurality of calendar events; and
in response to a request to add the suggested calendar event to the database, storing the generated calendar event in the database without an indication that the generated calendar event is a suggested calendar event. 13. The method of claim 12,
in response to a request to add the suggested calendar event to the database, further comprising: storing the generated calendar event in a remote database over a network without an indication that the generated calendar event is a suggested calendar event; method. According to claim 1,
receiving a request to reject the proposed calendar event; and
in response to a request to reject the proposed calendar event, preventing the suggested calendar event from being created in the future as a result of the event information being identified in a future message. The method of claim 1 , wherein the unstructured content is natural language content. An electronic device comprising:
display;
one or more processors;
Memory; and
16 , comprising one or more programs, the one or more programs stored in the memory and configured to be executed by the one or more processors, wherein the one or more programs are instructions for performing the method of claim 1 . Electronic devices comprising 16. A non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processors of an electronic device having a display, wherein the one or more programs perform the method of any one of claims 1-15. A non-transitory computer-readable storage medium comprising instructions for

Images