System and method for generating and providing intelligent departure time reminders

Abstract

To provide systems and methods for generating and providing intelligent time to leave reminders on an electronic device.SOLUTION: The method includes the steps of: automatically, without human intervention, identifying a calendar entry including a first identifier (for example, text in the title of a calendar entry that relates to a location, such as "go to dental checkup") that corresponds to an unknown geographic location; retrieving a previously-visited address (for example, a street address or GPS coordinates corresponding to the street address) associated with the first identifier; determining a departure time for the calendar entry on the basis of previously-visited address (for example, on the basis of a route from the current location of the device to the previously-visited address); automatically, without human intervention, associating the determined departure time with the calendar entry.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] Embodiments of the present specification generally relate to an electronic device including a touch sensing display, and more particularly, to a system and method for generating and providing an intelligent departure time reminder.

Background Art

[0002] Users of handheld electronic devices including touch sensing displays often create and receive numerous calendar entries to help them remember upcoming events. These calendar entries often include reminders or alerts that are presented to the user when each event is scheduled to occur some amount of time in the future (e.g., 15 minutes, 30 minutes, 1 hour, etc.). The user typically selects the amount of time based on the lead time required before the event, or simply selects a default value without considering how long it will take to reach the event on time. Thus, reminders or alerts are provided simply based on default values or inaccurate and / or old information from the user. Further, in the case of calendar entries that do not include location information, reminders or alerts do not take into account information regarding previously visited (and available for use in generating accurate reminders) addresses that may be accessible on the handheld electronic device.

Summary of the Invention

[0003] Therefore, there is a need for electronic devices with faster, more efficient methods and interfaces for generating and providing intelligent reminders that allow users sufficient time to depart and reach their destination by the start time of an event. Such methods and interfaces optionally complement or replace conventional methods for providing generic or default departure time reminders. Such methods and interfaces reduce the cognitive burden on the user and create a more efficient human-machine interface. Furthermore, such methods and interfaces help extend the lifespan of touch-sensitive displays by requiring fewer touch inputs (for example, by eliminating the need for users to repeatedly interact with the device to search for and review address / navigation details).

[0004] The defects and other problems described above, associated with user interfaces for electronic devices having touch-sensitive surfaces, are mitigated or eliminated by the devices disclosed herein. In some embodiments, the device is a desktop computer. In some embodiments, the device is portable (e.g., a notebook computer, tablet computer, or handheld device). In some embodiments, the device has a touchpad. In some embodiments, the device has a touch-sensitive display (also known as a “touchscreen” or “touchscreen display”). In some embodiments, the device has a graphical user interface (GUI), one or more processors, memory, and one or more modules, programs, or instruction sets stored in memory to perform multiple functions. In some embodiments, the user interacts with the GUI primarily through stylus and / or finger touch and gestures on the touch-sensitive surface. In some embodiments, the functions optionally include image editing, drawing, presenting, word processing, website creation, disk authoring, spreadsheet creation, gameplay, making phone calls, video conferencing, sending emails, instant messaging, training support, digital photography, digital video recording, web browsing, and digital music. The executable instructions that perform these functions are optionally included in non-temporary computer-readable storage media or other computer program products configured to be executed by one or more processors.

[0005] (A1) According to some embodiments, the method is performed in an electronic device (e.g., a portable multifunction device 100, Figure 1A) equipped with a touch-sensitive display (touchscreen 112, Figure 1C). The method includes automatically and without human intervention identifying a calendar item containing a first identifier corresponding to an unknown geographical location. The method further includes automatically and without human intervention retrieving a previously visited address associated with the first identifier. The method also includes automatically and without human intervention determining the departure time of the calendar item based on the previously visited address. The method further includes automatically and without human intervention associating the determined departure time with the calendar item. In other words, the method uses the first identifier to locate a previously visited address, and then determines (or determines) that the unknown geographical location is a previously visited address based on (i) an item associated with the previously visited address (e.g., a different calendar item, a text message, an email message, etc.) and (ii) the existence of the calendar item.

[0006] (A2) In some embodiments of the method described in A1, the method further includes providing a user with a reminder of the determined departure time for a calendar item on an electronic device.

[0007] (A3) In some embodiments of the method described in A2, a calendar item is associated with a default reminder separate from the reminder of the departure time determined for the calendar item provided to the user.

[0008] (A4) In some embodiments of the method described in any one of A2 to A3, providing a reminder includes providing a reminder in accordance with the determination that the departure time is within a predetermined amount of time from the current time.

[0009] (A5) In some embodiments of the method described in any one of A1 to A4, determining the departure time includes (i) determining the current address corresponding to the electronic device, (ii) determining the route from the current address to a previously visited address, and (iii) determining the departure time based on the amount of time it takes for the user to complete the route so that they reach the previously visited address within a predetermined amount of time from a start time associated with a calendar item.

[0010] (A6) In some embodiments of the method described in A5, the route is selected from a plurality of available routes from the current address to a previously visited address, according to the route selection preferences associated with the user of the electronic device.

[0011] (A7) In some embodiments of the method according to any one of A2 to A6, associating a determined departure time with a calendar item includes generating a reminder and updating the calendar item to include the generated reminder.

[0012] (A8) In some embodiments of the method described in any one of A1 to A7, the method further includes receiving confirmation from the user of an electronic device on a touch-sensitive display that a previously visited address corresponds to a calendar item, before determining the departure time. The method includes determining the departure time after receiving the confirmation.

[0013] (A9) In some embodiments of the method described in any one of A1 to A8, retrieving previously visited addresses includes retrieving previously visited addresses from a database of previously visited addresses associated with the user of an electronic device.

[0014] In some embodiments of the method described in (A10)A9, each previously visited address in the previously visited address database corresponds to an address previously visited by the user of the electronic device.

[0015] (A11) In some embodiments of the method described in any one of A9 to A10, retrieving a previously visited address includes performing a lookup in a database of previously visited addresses using a first identifier.

[0016] (A12) In some embodiments of the method described in any one of A1 to A11, the method further includes scanning a plurality of new calendar items during the calendar item creation process. The method includes presenting to the user of an electronic device previously visited addresses to be included in each of the new calendar items, according to the determination that a first identifier is included in each of the new calendar items of the plurality of new calendar items scanned.

[0017] (A13) In some embodiments of the method described in any one of A1 to A12, the method further includes determining whether the user has arrived at a previously visited address (for example, after determining that the user is traveling to a previously visited address in accordance with receiving the provided reminder described in A2 above). The method includes updating location information associated with the previously visited address in accordance with the determination that the user has arrived at a previously visited address. In some embodiments, determining whether the user has arrived at a previously visited address is performed after (or in accordance with) providing the reminder.

[0018] (A14) In another embodiment, an electronic device is provided. In some embodiments, the electronic device includes a touch-sensitive display, one or more processors, and a memory for storing one or more programs that, when executed by the one or more processors, cause the electronic device to perform the method described in any one of A1 to A13.

[0019] (A15) In yet another embodiment, an electronic device is provided which includes a touch-sensitive display and means for performing the method described in any one of A1 to A13.

[0020] (A16) In yet another embodiment, a non-temporary computer-readable storage medium is provided. The non-temporary computer-readable storage medium stores executable instructions that, when executed by an electronic device having a touch-sensitive display, cause the electronic device to perform the method described in any one of A1 to A13.

[0021] (A17) In yet another embodiment, a graphical user interface is provided on an electronic device having a touch-sensitive display. In some embodiments, the graphical user interface includes a user interface that is displayed in accordance with the method described in any one of A1 to A13.

[0022] (A18) In one additional embodiment, an electronic device is provided that includes a display unit (e.g., display unit 801, Figure 8), a touch-sensitive surface unit (e.g., touch-sensitive surface unit 803, Figure 8), and a processing unit (e.g., processing unit 805, Figure 8) connected to the display unit 801 and the touch-sensitive surface unit 803. In some embodiments, the display unit and the touch-sensitive surface unit are incorporated into a single touch-sensitive display unit (also referred to herein as a touch-sensitive display). In some embodiments, the processing unit includes an identification unit (e.g., identification unit 807), a retrieval unit (e.g., retrieval unit 809), a determination unit (e.g., determination unit 811), an association unit (e.g., association unit 813), a provision unit (e.g., provision unit 815), a selection unit (e.g., selection unit 817), a generation unit (e.g., generation unit 819), a reception unit (e.g., reception unit 821), an execution unit (e.g., execution unit 823), a scan unit (e.g., scan unit 825), a presentation unit (e.g., presentation unit 827), and an update unit (e.g., update unit 829). The processing unit is configured to automatically and without human intervention identify a calendar item containing a first identifier corresponding to an unknown geographical location (for example, using the identification unit 807), automatically and without human intervention retrieve a previously visited address associated with the first identifier (for example, using the retrieval unit 809), automatically and without human intervention determine the departure time of the calendar item based on the previously visited address (for example, using the determination unit 811), and automatically and without human intervention associate the determined departure time with the calendar item (for example, using the association unit 813).

[0023] (A19) In some embodiments of the electronic device described in A18, the processing unit is further configured to provide the user with a reminder of the determined departure time for a calendar item on the electronic device (for example, using the providing unit 815 and the display unit 801 (or using the providing unit 815 in conjunction with the display unit 801).

[0024] In some embodiments of the electronic devices described in (A20)A19, a calendar item is associated with a default reminder separate from the reminder of the departure time determined by the calendar item provided to the user.

[0025] (A21) In some embodiments of the electronic device described in any one of A19 to A20, providing a reminder includes providing a reminder (for example, using the providing unit 815 and the display unit 801 (or using the providing unit 815 in conjunction with the display unit 801)) in accordance with a determination (for example, by the determination unit 811) that the departure time is within a predetermined amount of time from the current time.

[0026] (A22) In some embodiments of the electronic device described in any one of A18 to A21, determining the departure time includes (i) determining the current address corresponding to the electronic device (e.g., using determination unit 811), (ii) determining the route from the current address to a previously visited address (e.g., using determination unit 811), and (iii) determining the departure time (e.g., using determination unit 811) based on the amount of time it takes for the user to complete the route so that they reach a previously visited address within a predetermined amount of time from a start time associated with a calendar item.

[0027] (A23) In some embodiments of the electronic device described in A22, the route is selected from a plurality of available routes from the current address to a previously visited address, according to the route selection preferences associated with the user of the electronic device (for example, using a selection unit 817).

[0028] (A24) In some embodiments of the electronic device described in any one of A19 to A23, associating a determined departure time with a calendar item includes generating a reminder (for example, using the generation unit 819) and updating the calendar item to include the generated reminder.

[0029] (A25)In some embodiments of the electronic device according to any one of A18 to A24, before determining the departure time, the processing unit is further configured to receive, from the user of the electronic device (e.g., using the receiving unit 821), on the touch-sensing display unit, a confirmation that a previously visited address corresponds to a calendar item. After receiving the confirmation, the processing unit is configured to determine the departure time (e.g., using the determination unit 811).

[0030] (A26)In some embodiments of the electronic device according to any one of A18 to A25, retrieving a previously visited address includes retrieving the previously visited address from a database of previously visited addresses associated with the user of the electronic device (e.g., using the retrieval unit 809).

[0031] (A27)In some embodiments of the electronic device according to A26, each previously visited address in the database of previously visited addresses corresponds to an address previously visited by the user of the electronic device.

[0032] (A28)In some embodiments of the electronic device according to any one of A26 to A27, retrieving a previously visited address includes performing a lookup in the database of previously visited addresses using a first identifier (e.g., using the execution unit 823).

[0033] (A29) In some embodiments of the electronic device described in any one of A18 to A28, the processing unit is further configured to scan multiple new calendar items during the calendar item creation process (for example, using the scan unit 825). In accordance with the determination (for example, by the determination unit 811) that each of the scanned new calendar items contains a first identifier, the processing unit is configured to present previously visited addresses to the user of the electronic device for inclusion in each new calendar item (for example, using the presentation unit 827 and the display unit 801 (or using the presentation unit 827 in conjunction with the display unit 801)).

[0034] (A30) Electronic device as described in any one of A18 to A29. In some embodiments, the processing unit is further configured to determine (e.g., using a determination unit 811) whether the user has arrived at a previously visited address in response to the provision of a reminder. In accordance with the determination (e.g., by the determination unit 811) that the user has arrived at a previously visited address, the processing unit is configured to update the location information associated with the previously visited address (e.g., using an update unit 829). In some embodiments, the determination of whether the user has arrived at a previously visited address is performed after (or in response to) the provision of a reminder.

[0035] Therefore, a faster, more efficient method and interface is provided for generating and providing intelligent departure time reminders to an electronic device comprising a display, a touch-sensitive surface, and one or more optional sensors for detecting the intensity of contact with the touch-sensitive surface, thereby increasing the effectiveness, efficiency, and user satisfaction of such a device. Such a method and interface may complement or replace conventional methods for providing generic or default reminders.

[0036] It should be noted that the various embodiments described above can be combined with any other embodiments described herein. The features and advantages described herein are not exhaustive, and many additional features and advantages will become apparent to those skilled in the art, particularly in light of the drawings, specification and claims. Furthermore, it should be noted that the language used herein has been selected solely for readability and explanatory purposes and not to define or limit the subject matter of the invention. [Brief explanation of the drawing]

[0037] To better understand the various embodiments described, please refer to the following “Modes for Carrying Out the Invention” section in conjunction with the drawings. Here, similar reference numerals refer to the corresponding parts throughout the drawings.

[0038] [Figure 1A] This block diagram shows a computing device with a touch-sensitive display according to several embodiments.

[0039] [Figure 1B] This is a block diagram of exemplary components for event handling according to several embodiments.

[0040] [Figure 1C] This is a schematic diagram of a portable multifunctional device having a touch-sensitive display, according to several embodiments.

[0041] [Figure 1D] This is a schematic diagram used to illustrate a computing device having a touch-sensitive surface separate from the display, according to several embodiments.

[0042] [Figure 2] This is a schematic diagram of a touchscreen used to illustrate a user interface for an application menu according to several embodiments.

[0043] [Figure 3A] This is a block diagram showing a data structure for storing calendar items according to several embodiments. [Figure 3B] This is a block diagram showing a data structure for storing calendar items according to several embodiments.

[0044] [Figure 4A] This is a block diagram showing a data structure for remembering previously visited addresses, according to several embodiments. [Figure 4B] This is a block diagram showing a data structure for remembering previously visited addresses, according to several embodiments.

[0045] [Figure 5] This block diagram shows an exemplary departure time reminder generation system according to several embodiments.

[0046] [Figure 6] This flowchart shows a method for generating and providing an intelligent departure time reminder according to some embodiments.

[0047] [Figure 7A] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments. [Figure 7B] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments. [Figure 7C] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments. [Figure 7D] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments. [Figure 7E] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments. [Figure 7F] This is a schematic diagram of a touch-sensitive display used to demonstrate the generation and provision of an intelligent departure time reminder according to several embodiments.

[0048] [Figure 8] This is a functional block diagram of an electronic device according to several embodiments.

[0049] As discussed above and in more detail below, there is a need for electronic devices with faster, more efficient methods and interfaces for generating and providing intelligent departure time reminders. In particular, there is a need to generate and provide departure time reminders based on previously visited addresses (for example, if a calendar item contains a title with the text "Visit Dentist," a departure time reminder can be generated based on the previously visited address corresponding to the dentist). This specification discloses novel methods and interfaces that address these needs. Such methods and interfaces optionally complement or replace conventional methods for generating departure time reminders. Such methods and interfaces streamline the process for generating departure time reminders by enabling users to quickly generate calendar items with minimal text input, and then automatically and without human intervention, determine the geographical destination corresponding to the calendar item based only on that minimal text input. Thus, users can continue to quickly generate calendar items on electronic devices, and by utilizing the methods and interfaces disclosed herein, electronic devices can seamlessly generate intelligent departure time reminders for calendar items. In this way, such methods and interfaces help ensure that users arrive at events in a timely manner. Thus, the methods and interfaces disclosed herein reduce cognitive burden and the time that users must spend generating calendar items, thereby resulting in a more efficient human-machine interface. In the case of battery-operated electronic devices, this not only saves power but also increases the interval between battery charges by generating and providing intelligent departure time reminders faster and more efficiently (for example, by automatically performing tasks that traditionally require extensive user interaction, such as automatically identifying previously visited addresses as destinations for calendar items generated without specific location details).

[0050] Figures 1A-1B and 2 below provide a description of an exemplary device. Figure 8 provides a functional block diagram of an exemplary electronic device. Figures 3A-3B and 4A-4B are block diagrams of exemplary data structures used to generate and provide an intelligent departure time reminder (these data structures are used in the method described below with respect to Figure 6). Figure 5 is a block diagram of an exemplary system for generating and providing an intelligent departure time reminder (this exemplary system is used in the method described below with respect to Figure 6). Figure 5 is a flowchart of a method for generating and providing an intelligent departure time reminder. Figures 7A-7F are schematic diagrams of touch-sensitive displays used to show an exemplary user interface for generating and providing an intelligent departure time reminder. Figures 3A-3B, 4A-4B, 5 and 7A-7E illustrate the method and / or process of Figure 5.

[0051] Herein, we will refer in detail to embodiments shown in the accompanying drawings. The following detailed description includes numerous specific details to provide a complete understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various embodiments described can be carried out without these specific details. In other examples, well-known methods, procedures, components, circuits, and networks are not described in detail so as not to unnecessarily obscure the aspects of the embodiments.

[0052] In this specification, terms such as "first," "second," etc., are used to describe various elements in some embodiments, but it will be understood that these elements should not be limited by those terms. These terms are used solely to distinguish one element from another. For example, without departing from the scope of the various embodiments described, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact. Both the first and second contacts are contacts, but they are not the same contact.

[0053] The terminology used in the description of the various embodiments described herein is intended solely to describe a particular embodiment and not to limit it. When used in the various described embodiments and in the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context otherwise clearly indicates. When used herein, the term “and / or” should also be understood to mean and include any and all possible combinations of one or more of the enumerated items relating to the description. When used herein, the terms “includes,” “including,” “comprises,” and / or “comprising” specify the presence of the described features, integers, steps, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof.

[0054] As used herein, the term "if" is interpreted, at its discretion, as contextual, to mean "when," "upon," "in response to determining," or "in response to detecting." Similarly, the phrases "if it is determined" or "if (a stated condition or event) is detected" are interpreted, at its discretion, as contextual, to mean "upon determining," "in response to determining," "upon detecting (the stated condition or event)," or "in response to detecting (the stated condition or event)."

[0055] The disclosure herein relates interchangeably to detecting touch input on, at, over, on top of, or substantially within a particular user interface element or portion of a touch-sensitive display. When used herein, touch input detected at a particular user interface element may, depending on the context, also be detected on, over, on top of, or substantially within the same user interface element. In some embodiments, as will be discussed in more detail below, the desired sensitivity level for detecting touch input is configured by the user of the electronic device (for example, the user may decide that touch input should only be detected when the touch input is entirely within the user interface element, and may configure the electronic device to operate in this manner).

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

[0057] The following description refers to an electronic device having a display and a touch-sensitive surface. However, please understand that this electronic device may optionally include one or more other physical user interface devices such as a physical keyboard, mouse, and / or joystick.

[0058] This device generally supports a variety of applications, including drawing applications, presentation applications, word processing applications, website creation applications, disk authoring applications, spreadsheet applications, game applications, telephone applications, video conferencing applications, email applications, instant messaging applications, fitness applications, photo management applications, digital camera applications, digital video camera applications, web browsing applications, digital music playback applications, and / or digital video playback applications.

[0059] Various applications running on this device optionally utilize at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface, as well as the corresponding information displayed on the device, are optionally adjusted and / or modified on an application-by-application basis and / or within the corresponding application. In this way, the device's common physical architecture (such as the touch-sensitive surface) optionally supports a variety of applications that have an intuitive and transparent user interface for the user.

[0060] Next, we turn our attention to embodiments of portable electronic devices equipped with a touch-sensitive display. Figure 1A is a block diagram of a portable multifunction device 100 (also referred to herein interchangeably as electronic device 100 or device 100) equipped with a touch-sensitive display 112 according to several embodiments. The touch-sensitive display 112 may be referred to for convenience as a “touchscreen,” and may be known or referred to as a touch-sensitive display system. Device 100 includes memory 102 (optionally including one or more computer-readable storage media), a controller 120, one or more processing units (CPUs) 122, a peripheral interface 118, an RF circuit 108, an audio circuit 110, a speaker 111, a microphone 113, an input / output (I / O) subsystem 106, other input or control devices 116, and an external port 124. Device 100 optionally includes one or more optical sensors 164. Device 100 optionally includes one or more intensity sensors 165 for detecting the intensity of contact on Device 100 (e.g., a touch-sensitive surface such as the touch-sensitive display system 112 of Device 100). Device 100 optionally includes one or more tactile output generators 167 for generating tactile output on Device 100 (e.g., generating tactile output on a touch-sensitive surface such as the touch-sensitive display system 112 of Device 100 or the touchpad of Device 100). These components optionally communicate via one or more communication buses or signal lines 103.

[0061] As used herein and in the claims, the term “strength” of contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of contact (e.g., finger contact) on the touch-sensitive surface, or a substitute for the force or pressure of contact on the touch-sensitive surface. The strength of contact has a range of values, including at least four distinct values, and more typically hundreds of different values ​​(e.g., at least 256). The strength of contact is determined (or measured) optionally using various methods and various sensors, or combinations of sensors. For example, one or more force sensors placed below or adjacent to the touch-sensitive surface are optionally used to measure forces at various points on the touch-sensitive surface. In some implementations, force measurements from multiple force sensors are combined (e.g., weighted average) to determine an estimate of the contact force. Similarly, a pressure-sensing tip on a stylus is optionally used to determine the pressure of a stylus on the touch-sensitive surface. Alternatively, the size and / or change in the contact area detected on the touch-sensitive surface, the capacitance and / or change in the touch-sensitive surface adjacent to the contact, and / or the resistance and / or change in the touch-sensitive surface adjacent to the contact may optionally be used as a substitute for the force or pressure of the contact on the touch-sensitive surface. In some implementations, the substitute measurement of the force or pressure of the contact is used directly to determine whether an intensity threshold is exceeded (e.g., the intensity threshold is described in units corresponding to the substitute measurement). In some implementations, the substitute measurement of the force or pressure of the contact is converted to an estimated force or pressure, and this estimated force or pressure is used to determine whether an intensity threshold is exceeded (e.g., the intensity threshold is a pressure threshold measured in units of pressure).

[0062] As used herein and in the claims, the term “tactile output” means a physical displacement of the device relative to its previous position, a physical displacement of a component of the device (e.g., a touch-sensitive surface) relative to another component of the device (e.g., a housing), or a displacement of a component relative to the center of mass of the device, which will be detected by the user through the user’s sense of touch. For example, in a situation where the device or a component of the device is in contact with the touch-sensitive surface of the user (e.g., the user’s fingers, palm, or other part of the hand), the tactile output generated by the physical displacement will be interpreted by the user as a tactile sensation corresponding to a perceived change in the physical properties of the device or a component of the device. For example, the movement of a touch-sensitive surface (e.g., a touch-sensitive display or trackpad) may be optionally interpreted by the user as a “down-click” or “up-click” of a physical actuator button. In some cases, the user may feel a tactile sensation such as a “down-click” or “up-click” even when there is no movement of a physical actuator button associated with a touch-sensitive surface that has been physically pressed (e.g., displaced) by the user’s action. In another embodiment, movement of a touch-sensitive surface may be optionally interpreted or perceived by the user as "roughness" of the touch-sensitive surface, even if there is no change in the smoothness of the touch-sensitive surface. While such interpretation of touch by the user depends on the user's personal sensory perception, there are many sensory perceptions of touch that are common to the majority of users. Therefore, when a tactile output is described as corresponding to a specific sensory perception of the user (e.g., "up-click," "down-click," "roughness"), unless otherwise stated, the generated tactile output corresponds to the physical displacement of the device or its components that produce the described sensory perception of a typical (or average) user.

[0063] Device 100 is merely one embodiment of a portable multifunction device, and it should be understood that Device 100 may optionally have more or fewer components than those shown, or may optionally have two or more components in any combination, or may optionally have different configurations or arrangements of components. The various components shown in Figure 1A may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application-specific integrated circuits.

[0064] Memory 102 optionally includes high-speed random-access memory (e.g., DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices), and optionally includes non-volatile memory such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory 102 optionally includes one or more storage devices located remotely from the processor(s) 122. Access to memory 102 by the CPU 122 and other components of device 100, such as the peripheral interface 118, is optionally controlled by the controller 120.

[0065] Using the peripheral device interface 118, the input and output peripheral devices of the device can be connected to the CPU 122 and memory 102. One or more processors 122 operate or execute various software programs and / or instruction sets stored in memory 102 to perform various functions for device 100 and process data.

[0066] In some embodiments, the peripheral interface 118, CPU 122, and controller 120 are optionally implemented on a single chip, such as chip 104. In some embodiments, they are optionally implemented on separate chips.

[0067] The RF (radio frequency) circuit 108 transmits and receives RF signals, also known as electromagnetic signals. The RF circuit 108 converts electrical signals to electromagnetic signals, or electromagnetic signals to electrical signals, and communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 108 optionally includes, but is not limited to, well-known circuits for performing these functions, including, but not limited to, antenna systems, RF transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, CODEC chipsets, subscriber identification module (SIM) cards, and memory. The RF circuit 108 optionally communicates wirelessly with the Internet, also known as the World Wide Web (WWW), intranets, and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs), and / or metropolitan area networks (MANs), and other devices. Wireless communication may optionally utilize any of several communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM)®, Enhanced Data GSM Environment (EDGE)®, High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Evolution, Data-Only (EV-DO), HSPA, HSPA+, Dual-Cell HSPA (DC-HSPDA), Long-Term Evolution (LTE), Near Field Communication (NFC), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth®, and Wireless Fidelity (Wi-Fi)® (e.g., IEEE 802.11a, IEEE 802.1lb, IEEE 802.1lg, and / or IEEE 802.1ln).

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

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

[0070] The touch-sensitive display 112 provides input and output interfaces between the device and the user. The display controller 156 receives electrical signals from and / or transmits electrical signals to the touchscreen 112. The touchscreen 112 displays visual output to the user. The visual output optionally includes graphics, text, icons, videos, and any combination thereof (collectively referred to as “graphics”). In some embodiments, some or all of the visual output corresponds to user interface objects.

[0071] The touchscreen 112 has a touch-sensing surface, sensor, or set of sensors that accept user input based on tactile and / or haptic contact. The touchscreen 112 and the display controller 156 (together with any associated modules and / or instruction sets in memory 102) detect contact (and any movement or interruption of contact) on the touchscreen 112 and translate the detected contact into interaction with user interface objects displayed on the touchscreen 112 (e.g., one or more soft keys, icons, web pages, or images). In an exemplary embodiment, the point of contact between the touchscreen 112 and the user corresponds to the area under the user's finger.

[0072] The touchscreen 112 optionally uses LCD (liquid crystal display) technology, LPD (polymer light-emitting display) technology, LED (light-emitting diode) technology, or OLED (organic light-emitting diode) technology, but other display technologies are used in other embodiments. The touchscreen 112 and display controller 156 optionally detect contact and any movement or interruption of contact using any of several currently known or future-developed touch sensing technologies, including but not limited to capacitive technology, resistive technology, infrared technology, and surface acoustic wave technology, as well as other proximity sensor arrays or other elements for determining one or more contact points with the touchscreen 112. In exemplary embodiments, projected mutual capacitance sensing technology is used, such as that found in iPhone®, iPod Touch®, and iPad® from Apple Inc., Cupertino, California.

[0073] The touchscreen 112 optionally has a video resolution greater than 400 dpi. In some embodiments, the touchscreen 112 has a video resolution of at least 600 dpi. In other embodiments, the touchscreen 112 has a video resolution of at least 1000 dpi. The user optionally touches the touchscreen 112 using any suitable object or digit, such as a stylus or finger. In some embodiments, the user interface is designed to operate primarily with finger touch and gestures. In some embodiments, the device translates finger-based input into commands to perform a precise pointer / cursor position or an action desired by the user.

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

[0075] Device 100 also includes a power system 162 for supplying power to various components. The power system 162 optionally includes a power management system, one or more power sources (e.g., a battery, alternating current (AC)), a recharge system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)), and any other components associated with the generation, management, and distribution of power within the portable device.

[0076] Device 100 also optionally includes one or more optical sensors 164. Figure 1A shows an optical sensor coupled to an optical sensor controller 158 in the I / O subsystem 106. The optical sensor 164 optionally includes a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The optical sensor 164 receives light from the environment projected through one or more lenses and converts that light into data that represents an image. In use with an imaging module 143 (also referred to as a camera module), the optical sensor 164 optionally captures still images or video. In some embodiments, the optical sensor is located on the back of Device 100, opposite the touchscreen 112 on the front of the device, to enable the touch-sensitive display as a viewfinder for acquiring still and / or video images. In some embodiments, another optical sensor is located on the front of the device to optionally obtain an image of the user for video conferencing while the user is viewing other video conference participants on the touch-sensitive display.

[0077] Device 100 also optionally includes one or more contact strength sensors 165. Figure 1A shows a contact strength sensor coupled to a strength sensor controller 159 in the I / O subsystem 106. The contact strength sensor 165 optionally includes one or more piezoresistive strain gauges, capacitive force sensors, electric force sensors, pressure-power sensors, optical force sensors, capacitive touch-sensing surfaces, or other strength sensors (e.g., sensors used to measure the force (or pressure) of contact on a touch-sensing surface). The contact strength sensor 165 receives contact strength information (e.g., pressure information or a substitute for pressure information) from the environment. In some embodiments, at least one contact strength sensor is collated with or adjacent to a touch-sensing surface (e.g., a touch-sensing display system 112). In some embodiments, at least one contact strength sensor is located on the back of Device 100, opposite the touchscreen 112 located on the front of Device 100.

[0078] Device 100 also optionally includes one or more proximity sensors 166. Figure 1A shows a proximity sensor 166 coupled to a peripheral interface 118. Alternatively, the proximity sensor 166 is coupled to an input controller 160 in the I / O subsystem 106. In some embodiments, if the multifunction device is positioned near the user's ear (for example, when the user is making a phone call), the proximity sensor is turned off and the touchscreen 112 is disabled.

[0079] Device 100 also optionally includes one or more tactile output generators 167. Figure 1A shows a tactile output generator connected to a tactile feedback controller 161 in the I / O subsystem 106. The tactile output generator 167 optionally includes one or more electroacoustic devices, such as a speaker or other audio component, and / or electromechanical devices that convert energy into linear motion, such as a motor, solenoid, electroactive polymer, piezoelectric actuator, electrostatic actuator, or other tactile output generating component (e.g., a component that converts an electrical signal into a tactile output on the device). The contact intensity sensor 165 receives a tactile feedback generation command from the tactile feedback module 133 and generates a tactile output on device 100 that can be sensed by the user of device 100. In some embodiments, at least one tactile output generator is located on or near a touch-sensitive surface (e.g., a touch-sensitive display system 112) and optionally generates a tactile output by moving the touch-sensitive surface vertically (e.g., inward / outward from the surface of device 100) or laterally (e.g., forward / backward in the same plane as the surface of device 100). In some embodiments, at least one tactile output generator sensor is located on the back of device 100, opposite the touch-sensitive display 112 located on the front of device 100.

[0080] Device 100 also optionally includes one or more accelerometers 168. Figure 1A shows an accelerometer 168 connected to a peripheral interface 118. Alternatively, the accelerometer 168 is optionally connected to an input controller 160 in the I / O subsystem 106. In some embodiments, information is displayed on a touch-sensitive display in portrait or landscape orientation based on an analysis of data received from one or more accelerometers. In addition to the accelerometers (one or more) 168, device 100 optionally includes a magnetometer (not shown) and a GPS (or GLONASS or other global navigation system) receiver (not shown) for obtaining information about the position and orientation (e.g., portrait or landscape) of device 100.

[0081] In some embodiments, the software components stored in memory 102 include an operating system 126, a communication module (or instruction set) 128, a contact / motion module (or instruction set) 130, a graphics module (or instruction set) 132, a text input module (or instruction set) 134, a Global Positioning System (GPS) module (or instruction set) 135, and an application (or instruction set) 136. Furthermore, in some embodiments, as shown in Figure 1A, memory 102 stores the device / global internal state 157, a destination determination module 163 (optionally including one or more of the following: previously visited addresses 402, a calendar item data structure 302, a destination prediction module 163-1, a route determination module 163-2, and / or a departure reminder module 163-3). The device / global internal state 157 includes one or more of the following: If there is an application currently active, the active application status indicates which application is active; the display status indicates which applications, views, or other information occupy different areas of the touch-sensitive display 112; the sensor status includes information obtained from various sensors and input control devices 116 of the device; and location information relating to the position and / or orientation of the device (e.g., the orientation of the device).

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

[0083] The communication module 128 facilitates communication with other devices via one or more external ports 124 and includes various software components for processing data received by the RF circuit 108 and / or external ports 124. The external ports 124 (e.g., Universal Serial Bus (USB), FireWire®, etc.) are adapted to connect to other devices directly or indirectly through a network (e.g., the Internet, Wi-Fi, etc.). In some embodiments, the external ports are multi-pin (e.g., 30-pin) connectors identical to, or similar to and / or compatible with, the 30-pin connector used in some embodiments of Apple Inc.'s iPod® devices. In other embodiments, the external ports are multi-pin (e.g., 8-pin) connectors identical to, or similar to and / or compatible with, the 8-pin connector used in Apple Inc.'s Lightning® connectors.

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

[0085] In some embodiments, the contact / motion module 130 uses a set of one or more intensity thresholds to determine whether an action has been performed by the user (e.g., whether the user has selected or "clicked" on an affordance). In some embodiments, at least a subset of the intensity thresholds is determined according to software parameters (e.g., the intensity thresholds are not determined by activation thresholds of a particular physical actuator and can be adjusted without modifying the physical hardware of device 100). For example, the mouse "click" threshold for a trackpad or touch-sensitive display can be set to one of a range of predetermined thresholds without modifying the hardware of the trackpad or touch-sensitive display. Furthermore, in some implementations, the user of the device is provided with software settings to adjust one or more of the set of intensity thresholds (e.g., by adjusting individual intensity thresholds and / or by adjusting multiple intensity thresholds at once using a system-level click "intensity" parameter).

[0086] The contact / motion module 130 optionally detects gesture input from the user. Different gestures on the touch-sensitive surface have different contact patterns (e.g., different movements, timings, and / or intensity of contact detected). Thus, gestures are optionally detected by detecting specific contact patterns. For example, detecting a finger tap gesture involves detecting a finger-down event (e.g., at the icon's position) followed by a finger-lift-off event at the same (or substantially the same) location as the finger-down event. In another embodiment, detecting a finger swipe gesture on the touch-sensitive surface involves detecting a finger-down event followed by one or more finger-drag events, and in some embodiments, subsequently a finger-lift-off event.

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

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

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

[0090] The text input module 134 is optionally a component of the graphics module 132 and provides a soft keyboard for entering text in various applications (e.g., the contact module 137, the email client module 140, the IM module 141, the browser module 147, and any other applications that require text input).

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

[0092] Application ("app") 136 optionally includes the following modules (or instruction sets), or subsets or supersets thereof: ●Contact module 137 (sometimes also called the address book or contact list), ●Telephone module 138, ●Video conferencing module 139, ● Email client module 140, ● Instant messaging (IM) module 141, ●Fitness Module 142, ● Camera module 143 for still images and / or video images, ●Image management module 144, ● Browser module 147, ●Calendar module 148, ● A widget module 149 that optionally includes one or more of the following: weather widget 149-1, stock price widget 149-2, calculator widget 149-3, alarm clock widget 149-4, dictionary widget 149-5, other widgets obtained by the user, and user-created widgets 149-6. ●Search module 151, ● A video and music player module 152, which optionally consists of a video playback module and a music playback module. ●Memo Module 153, ●Map module 154 and / or ● Online video module 155.

[0093] Examples of other applications 136 that may be optionally stored in memory 102 include other word processing applications, other image editing applications, drawing applications, presentation applications, website creation applications, disk authoring applications, spreadsheet applications, JAVA®-compatible applications, encryption, digital rights management, speech recognition, a widget creator module for creating user-created widgets 149-6, and speech duplication.

[0094] Together with the touchscreen 112, display controller 156, contact module 130, graphics module 132, and text input module 134, the contact module 137 is optionally used to manage an address book or contact list (for example, stored in the contact module 137 in memory 102), which includes adding names(s) to and removing names(s) from the address book, associating telephone numbers(s) to and including module 138, video conferencing module 139, email client module 140, or IM module 141.

[0095] In conjunction with the RF circuit 108, audio circuit 110, speaker 111, microphone 113, touchscreen 112, display controller 156, contact module 130, graphics module 132, and text input module 134, the telephone module 138 is optionally used to input a series of characters corresponding to a telephone number, access one or more telephone numbers in the address book 137, modify an entered telephone number, dial each telephone number, conduct a conversation, or disconnect or hang up when the conversation is complete. As described above, wireless communication optionally uses one of several communication standards, protocols, and technologies.

[0096] In conjunction with the RF circuit 108, audio circuit 110, speaker 111, microphone 113, touchscreen 112, display controller 156, light sensor 164, light sensor controller 158, contact module 130, graphics module 132, text input module 134, contact list 137, and telephone module 138, the video conferencing module 139 includes executable commands for starting, conducting, and ending a video conference between the user and one or more other participants, according to the user's instructions.

[0097] In conjunction with the RF circuit 108, touchscreen 112, display controller 156, contact module 130, graphics module 132, and text input module 134, the email client module 140 includes executable commands for creating, sending, receiving, and managing emails in response to user instructions. Working in conjunction with the image management module 144, the email client module 140 makes it extremely easy to create and send emails containing still or video images captured by the camera module 143.

[0098] In association with the RF circuit 108, touchscreen 112, display controller 156, contact module 130, graphics module 132, and text input module 134, the instant messaging module 141 includes executable instructions for inputting a string corresponding to an instant message, modifying entered characters, sending the corresponding instant message (e.g., using the Short Message Service (SMS) or Multimedia Messaging Service (MMS) protocol for telephone-based instant messaging, or using XMPP, SIMPLE, or IMPS for internet-based instant messaging), receiving an instant message, and displaying the received instant message. In some embodiments, the transmitted and / or received instant messages optionally include graphics, photographs, audio files, video files, and / or other attachments, such as those supported by MMS and / or Enhanced Messaging Service (EMS). As used herein, “instant message” refers to both telephone-based messages (e.g., messages sent using SMS or MMS) and internet-based messages (e.g., messages sent using XMPP, SIMPLE, or IMPS).

[0099] In conjunction with the RF circuit 108, touchscreen 112, display controller 156, contact module 130, graphics module 132, text input module 134, GPS module 135, map module 154, and video and music player module 152, the fitness module 142 includes executable commands for creating training (e.g., with respect to time, distance, and / or calorie consumption goals), communicating with training sensors (sports devices such as a portable watch or pedometer), receiving training sensor data, calibrating sensors used to monitor training, selecting and playing music for training, and displaying, storing, and transmitting training data.

[0100] In association with the touchscreen 112, display controller 156, light sensor(s) 164, light sensor controller 158, contact module 130, graphics module 132, and image management module 144, the camera module 143 includes executable instructions for capturing still images or videos (including video streams) and storing them in memory 102, modifying the characteristics of still images or videos, or deleting still images or videos from memory 102.

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

[0102] In association with the RF circuit 108, touchscreen 112, display system controller 156, contact module 130, graphics module 132, and text input module 134, the browser module 147 includes executable instructions for browsing the Internet, following user instructions, including navigating, linking, receiving, and displaying web pages or portions thereof, as well as attachments and other files linked to web pages.

[0103] Together with the RF circuit 108, touchscreen 112, display system controller 156, contact module 130, graphics module 132, text input module 134, email client module 140, and browser module 147, the calendar module 148 includes executable instructions for creating, displaying, modifying, and storing a calendar and data associated with the calendar (e.g., calendar items, to-do lists, etc.) in accordance with user instructions.

[0104] Along with the RF circuit 108, touchscreen 112, display system controller 156, contact module 130, graphics module 132, text input module 134, and browser module 147, the widget module 149 is a mini-application that can be optionally downloaded and used by the user (e.g., weather widget 149-1, stock price widget 149-2, calculator widget 149-3, alarm clock widget 149-4, and dictionary widget 149-5), or a mini-application created by the user (e.g., user-created widget 149-6). In some embodiments, the widget includes an HTML (Hypertext Markup Language) file, a CSS (Cascading Style Sheets) file, and a JavaScript® file. In some embodiments, the widget includes an XML (Extensible Markup Language) file and a JavaScript file (e.g., a Yahoo!® widget).

[0105] Together with the RF circuit 108, touchscreen 112, display system controller 156, contact module 130, graphics module 132, text input module 134, and browser module 147, a widget creator module (not shown) is optionally used by the user to create widgets (for example, to convert a user-specified area of ​​a web page into a widget).

[0106] In association with the touchscreen 112, display system controller 156, contact module 130, graphics module 132, and text input module 134, the search module 151 includes executable instructions for searching for text, music, sounds, images, videos, and / or other files in memory 102 that match one or more search criteria (e.g., one or more user-specified search terms) according to user instructions.

[0107] In association with the touchscreen 112, display system controller 156, contact module 130, graphics module 132, audio circuit 110, speaker 111, RF circuit 108, and browser module 147, the video and music player module 152 includes executable instructions that allow the user to download and play recorded music or other sound files stored in one or more file formats such as MP3 or AAC files, as well as executable instructions for displaying, presenting, or otherwise playing video (for example, on the touchscreen 112 or on an external display connected via the external port 124). In some embodiments, the device 100 optionally includes the functionality of an MP3 player, such as Apple Inc.'s iPod®.

[0108] In conjunction with the touchscreen 112, display controller 156, contact module 130, graphics module 132, and text input module 134, the memo module 153 includes executable instructions for creating and managing memos, to-do lists, etc., according to user instructions.

[0109] Together with the RF circuit 108, touchscreen 112, display system controller 156, contact module 130, graphics module 132, text input module 134, GPS module 135, and browser module 147, the map module 154 can optionally be used to receive, display, modify, and store maps and map-related data (e.g., driving directions, data about shops in or near a specific location and other points of interest, and other location-based data) in accordance with user instructions.

[0110] In relation to the touchscreen 112, display system controller 156, contact module 130, graphics module 132, audio circuit 110, speaker 111, RF circuit 108, text input module 134, email client module 140, and browser module 147, the online video module 155 includes instructions that allow the user to access, browse, receive (e.g., by streaming and / or downloading), play (e.g., on the touchscreen or on an external display connected via external port 124), send emails containing links to specific online videos, and manage them in other ways. In some embodiments, an instant messaging module 141 is used instead of the email client module 140 to send links to specific online videos.

[0111] As shown in Figure 1A, the portable multifunction device 100 also includes a destination determination module 163 for coordinating destination determination operations on the device 100 (for example, retrieving data from a data structure 302 of a previously visited address 402 or calendar item, and using the retrieved data to generate a departure time reminder). The destination determination module 163 optionally includes the following modules (or instruction sets), or subsets or supersets: ● Previously visited addresses 402 for storing information about addresses (or GPS coordinates corresponding to addresses) that the user of device 100 has previously visited; ●Calendar item data structure 302 for storing information about calendar items associated with the user of device 100; ●Destination prediction module 163-1; ● Route determination module 163-2; ●Departure reminder module 163-3.

[0112] Together with the GPS module 135, operating system 126, I / O subsystem 106, previously visited addresses 402, calendar item data structure 302, map module 154, and calendar module 148, the destination prediction module 163-1 includes executable instructions that scan calendar items (e.g., one or more records stored in the calendar item data structure 302) and predict the destination for the corresponding calendar item based on previously visited addresses (e.g., previously visited addresses stored in previously visited addresses 402).

[0113] Together with the GPS module 135, operating system 126, I / O subsystem 106, previously visited addresses 402, calendar item data structure 302, map module 154, and calendar module 148, the route determination module 163-2 includes executable instructions for determining one or more possible routes to a specific destination (e.g., walking, cycling, driving, public transport, etc.).

[0114] Together with the GPS module 135, the operating system 126, the I / O subsystem 106, the previously visited addresses 402, the calendar item data structure 302, the map module 154, and the calendar module 148, the departure reminder module 163-3 includes executable instructions that provide the user of device 100 with a reminder that the next event is the departure time (for example, an exemplary user interface object 702 with an exemplary reminder is shown in Figure 7B).

[0115] Each of the modules and applications identified above corresponds to an executable instruction set and a method of this application (e.g., a method performed by a computer and other information processing methods described herein) that perform one or more of the above functions. These modules (i.e., instruction sets) do not need to be implemented as separate software programs, procedures, or modules, and therefore various subsets of these modules can be optionally combined or rearranged in various embodiments. In some embodiments, memory 102 optionally stores a subset of the identified modules and data structures described above. Furthermore, memory 102 optionally stores additional modules and data structures not described above.

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

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

[0118] Figure 1B is a block diagram showing exemplary components for event processing according to several embodiments. In some embodiments, memory 102 (in Figure 1A) includes an event sorting unit 170 (for example, of the operating system 126) and a corresponding application 136-1 selected from applications 136 of the portable multifunction device 100 (Figure 1A) (for example, any of the above applications stored in memory 102 that have application 136).

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

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

[0121] The event monitor 171 receives event information from the peripheral interface 118. The event information includes information about sub-events (for example, user touch on the touch-sensitive display 112 as part of a multi-touch gesture). The peripheral interface 118 transmits information received from the I / O subsystem 106, or from sensors such as the proximity sensor 166, one or more accelerometers 168, and / or the microphone 113 (via the audio circuit 110). The information received by the peripheral interface 118 from the I / O subsystem 106 includes information from the touch-sensitive display 112 or the touch-sensitive surface.

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

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

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

[0125] Another aspect of the user interface associated with an application is a set of views, which may be referred to herein as application views or user interface windows, in which information is displayed and touch-based gestures are performed. The application view (of each application) in which a touch is detected optionally corresponds to a program level within the application's program hierarchy or view hierarchy. For example, the lowest level view in which a touch is detected is optionally referred to as a hit view, and the set of events recognized as appropriate input is optionally determined, at least partially, based on the hit view of the initial touch that initiates a touch-based gesture.

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

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

[0128] The event dispatcher module 174 transmits event information to an event recognition unit (e.g., an event recognition unit 180). In embodiments including an active event recognition unit determination module 173, the event dispatcher module 174 distributes the event information to the event recognition unit determined by the active event recognition unit determination module 173. In some embodiments, the event dispatcher module 174 stores the event information acquired by the corresponding event receiving unit 182 in an event queue.

[0129] In some embodiments, the operating system 126 includes an event sorting unit 170. Alternatively, application 136-1 includes an event sorting unit 170. In yet another embodiment, the event sorting unit 170 is either a standalone module or part of another module stored in memory 102, such as a contact / motion module 130.

[0130] In some embodiments, application 136-1 includes a plurality of event processing units 190 and one or more application views 191, each containing instructions for processing touch events occurring within each view of the application's user interface. Each application view 191 of application 136-1 includes one or more event recognition units 180. Typically, each application view 191 contains multiple event recognition units 180. In other embodiments, one or more of the event recognition units 180 are part of a separate module, such as a user interface kit (not shown) or a higher-level object from which application 136-1 inherits methods and other characteristics. In some embodiments, each event processing unit 190 includes one or more event data 179 received from a data update unit 176, an object update unit 177, a GUI update unit 178, and / or an event sorting unit 170. The event processing unit 190 optionally uses or calls the data update unit 176, the object update unit 177, or the GUI update unit 178 to update the application's internal state 192. Alternatively, one or more of the application views 191 include one or more corresponding event processing units 190. In some embodiments, one or more of the data update unit 176, object update unit 177, and GUI update unit 178 are included in the corresponding application view 191.

[0131] The corresponding event recognition unit 180 receives event information (e.g., event data 179) from the event sorting unit 170 and identifies an event from that event information. The event recognition unit 180 includes an event receiving unit 182 and an event comparison unit 184. In some embodiments, the event recognition unit 180 further includes metadata 183 and at least a subset of event distribution commands 188 (optionally including sub-event distribution commands).

[0132] The event receiving unit 182 receives event information from the event sorting unit 170. This event information includes information about sub-events, such as touches or touch movements. Depending on the sub-event, the event information may also include additional information, such as the location of the sub-event. When a sub-event involves a touch movement, the event information may optionally further include the speed and direction of the sub-event. In some embodiments, an event includes a rotation of the device from one orientation to another (e.g., from portrait to landscape, or vice versa), and the event information includes corresponding information about the device's current orientation (also called the device's orientation).

[0133] The event comparison unit 184 compares event information with a default event or sub-event definition and, based on the comparison, determines the event or sub-event, or determines or updates the state of the event or sub-event. In some embodiments, the event comparison unit 184 includes an event definition 186. The event definition 186 includes an event definition (e.g., a default sequence of sub-events), such as event 1 (187-1) and event 2 (187-2). In some embodiments, sub-events within event 187 include, for example, touch start, touch end, touch movement, touch cancellation, and multiple touches. In one embodiment, the definition of event 1 (187-1) is a double tap on a displayed object. A double tap includes, for example, a first touch (touch start) for a predetermined stage on the displayed object, a first lift-off (touch end) for the predetermined stage, a second touch (touch start) for the predetermined stage on the displayed object, and a second lift-off (touch end) for the predetermined stage. In another embodiment, the definition of event 2 (187-2) is a drag operation on a displayed object. A drag includes, for example, touching (or contacting) a predetermined stage on a displayed object, moving the touch across the touch-sensitive display 112, and lifting off the touch (ending the touch). In some embodiments, the event also includes information about one or more associated event processing units 190.

[0134] In some embodiments, the event definition 186 includes an event definition for each user interface object. In some embodiments, the event comparison unit 184 performs a hit test to determine which user interface object is associated with a sub-event. For example, in an application view where 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 comparison unit 184 performs a hit test to determine which of the three user interface objects is associated with the touch (sub-event). If each displayed object is associated with a corresponding event processing unit 190, the event comparison unit uses the results of the hit test to determine which event processing unit 190 should be activated. For example, the event comparison unit 184 selects an event processing unit associated with the object that triggers the sub-event and the hit test.

[0135] In some embodiments, the definition of each event 187 also includes a delay effect that delays the delivery of event information until it is determined whether or not the sequence of sub-events corresponds to the event type of the event recognition unit.

[0136] If each event recognition unit 180 determines that a series of sub-events does not match any of the events in the event definition 186, each event recognition unit 180 enters an event impossible, event failed, or event terminated state and thereafter ignores subsequent sub-events of the touch-based gesture. In this situation, if there are other event recognition units that remain active with respect to the hit view, they continue to track and process the sub-events of the ongoing touch-based gesture.

[0137] In some embodiments, each event recognition unit 180 includes metadata 183 having configurable properties, flags, and / or a list indicating how the event distribution system performs sub-event distribution to event recognition units in which it is actively involved. In some embodiments, the metadata 183 includes configurable properties, flags, and / or a list indicating how event recognition units can or can interact with each other. In some embodiments, the metadata 183 includes configurable properties, flags, and / or a list indicating whether sub-events are distributed to different levels within the view hierarchy or program hierarchy.

[0138] In some embodiments, each event recognition unit 180 activates an event processing unit 190 associated with an event when one or more specific sub-events of an event are recognized. In some embodiments, each event recognition unit 180 delivers event information associated with the event to the event processing unit 190. Activating the event processing unit 190 is different from sending (and delaying the sending of) sub-events to the corresponding hit view. In some embodiments, the event recognition unit 180 throws a flag associated with the recognized event, and the event processing unit 190 associated with the flag catches the flag and performs predetermined processing.

[0139] In some embodiments, the event distribution command 188 includes a sub-event distribution command that distributes event information about a sub-event without activating an event processing unit. Instead, the sub-event distribution command distributes the event information to an event processing unit or an actively involved view associated with a set of sub-events. The event processing unit associated with the set of sub-events or the actively involved view receives the event information and performs predetermined processing.

[0140] In some embodiments, the data update unit 176 creates and updates data used in application 136-1. For example, the data update unit 176 updates telephone numbers used in contact module 137 or stores video files used in video and music player module 152. In some embodiments, the object update unit 177 creates and updates objects used in application 136-1. For example, the object update unit 176 creates new user interface objects or updates the position of user interface objects. The GUI update unit 178 updates the GUI. For example, the GUI update unit 178 prepares display information and sends it to graphics module 132 for display on touch-sensitive display.

[0141] In some embodiments, the event processing unit(s) 190 includes, or can access, a data update unit 176, an object update unit 177, and a GUI update unit 178. In some embodiments, the data update unit 176, the object update unit 177, and the GUI update unit 178 are included in a single module of their respective applications 136-1 or application view 191. In other embodiments, they are included in two or more software modules.

[0142] The above description of event processing for user touch on a touch-sensitive display also applies to other forms of user input for operating the multifunction device 100 using input devices, but it should be understood that not all of this begins on the touchscreen. For example, mouse movements and mouse button presses optionally matched to single or multiple keyboard presses or holds, touch movements such as taps, drags, and scrolls on a touchpad, pen stylus input, device movement, verbal instructions, detected eye movements, biometric input, and / or any combination thereof may be optionally used as inputs corresponding to sub-events that define the event to be recognized.

[0143] Figure 1C is a schematic diagram of a portable multifunction device (e.g., portable multifunction device 100) having a touch-sensitive display (e.g., touchscreen 112) according to some embodiments. In some embodiments and other embodiments described below, a user can select one or more graphics displayed on the touch-sensitive display by making gestures on the screen using, for example, one or more fingers or one or more styluses. In some embodiments, the selection of one or more graphics occurs when the user disconnects contact with one or more graphics (e.g., by lifting off a finger from the screen). In some embodiments, the gestures optionally include one or more tap gestures (e.g., lifting off after a series of touches on the screen), one or more swipe gestures (e.g., continuous contact between gestures along the screen surface from left to right, right to left, upward and / or downward), and / or rolling of a finger in contact with the device 100 (e.g., from right to left, left to right, upward and / or downward). In some implementations or situations, an unintended contact with a graphic does not necessarily mean selecting that graphic. For example, if the gesture for launching an application is a tap gesture, a swipe gesture sweeping over an application affordance (e.g., an icon) will not selectively launch (e.g., not open) the corresponding application.

[0144] Device 100 also optionally includes one or more physical buttons, such as a "Home" or menu button 204. As previously stated, the menu button 204 is optionally used on device 100 to navigate to any application 136 within the set of applications to be executed. Alternatively, in some embodiments, the menu button is implemented as a soft key in the GUI displayed on the touchscreen 112.

[0145] In one embodiment, device 100 includes a touchscreen 112, a menu button 204, a push button 206 for turning the device on / off and locking the device, one or more volume control buttons 208, a subscriber identification module (SIM) card slot 210, a headset jack 212, and an external docking / charging port 124. The push button 206 turns the device on / off by pressing and holding the button down for a predetermined time, locks the device by pressing and releasing the button before the predetermined time has elapsed, and / or unlocks the device or initiates an unlocking process. In an alternative embodiment, device 100 also receives verbal input through a microphone 113 to activate or deactivate certain functions. Device 100 also optionally includes one or more contact intensity sensors 165 for detecting the intensity of contact on the touchscreen 112, and / or one or more tactile output generators 167 for generating tactile output to the user of device 100.

[0146] Figure 1D shows a user interface on a device (e.g., device 100 in Figure 1A) that has a touch-sensing surface 195 (e.g., a tablet or touchpad) separate from a display 194 (e.g., a touchscreen 112). In some embodiments, the touch-sensing surface 195 optionally includes one or more contact intensity sensors (e.g., one or more of one or more contact intensity sensors 359) for detecting the intensity of contact on the touch-sensing surface 195 and / or one or more tactile output generators 357 for generating user tactile output on the touch-sensing surface 195.

[0147] Some of the following embodiments will be described with reference to input on a touchscreen 112 (when the touch-sensing surface and the display are combined), but in some embodiments, the device detects input on a touch-sensing surface separate from the display, as shown in Figure 1D. In some embodiments, this touch-sensing surface (e.g., 195 in Figure 1D) has a principal axis (e.g., 199 in Figure 1D) corresponding to a principal axis (e.g., 198 in Figure 1D) on the display (e.g., 194). According to these embodiments, the device detects contact with the touch-sensing surface 195 (e.g., 197-1 and 197-2 in Figure 1D) at locations corresponding to each location on the display (e.g., in Figure 1D, 197-1 corresponds to 196-1, 197-2 corresponds to 196-2). Thus, when the touch-sensitive surface is separate from the display, user input detected by the device on the touch-sensitive surface (e.g., 195 in Figure 1D) (e.g., touches 197-1 and 197-2, and their movements) is used by the device to operate the user interface on the display of the multifunction device (e.g., 194 in Figure 1D). It should be understood that a similar method may be optionally used for other user interfaces described herein.

[0148] Furthermore, while the following embodiments primarily refer to and describe finger input (e.g., finger touch, finger tap gesture, finger swipe gesture), it should be understood that in some embodiments, one or more of these finger inputs may be replaced by input from another input device (e.g., mouse-based input, or stylus input). For example, a swipe gesture may optionally be replaced with a mouse click (e.g., instead of touch), followed by cursor movement along the swipe path (e.g., instead of touch movement). As another example, a tap gesture may optionally be replaced with a mouse click (e.g., instead of stopping touch detection after touch detection). Similarly, when multiple user inputs are detected simultaneously, it should be understood that multiple computer mice may be used simultaneously and optionally, or that a mouse and finger touch may be used simultaneously and optionally.

[0149] As used herein, the term “focus selector” refers to an input element that indicates the current portion of the user interface with which the user is interacting. In some implementations, including a cursor or other position marker, when input (e.g., a press input) is detected on a touch-sensitive surface (e.g., touch-sensitive surface 195 in Figure 1D (in some embodiments, touch-sensitive surface 195 is a touchpad)) and the cursor is over a particular user interface element (e.g., a button, window, slider, or other user interface element), the cursor functions as a “focus selector” and the particular user interface element is adjusted according to the detected input. In some implementations, including a touchscreen display (e.g., touch-sensitive display system 112, or touchscreen 112, in Figure 1A) that enables direct interaction with user interface elements on a touchscreen display, the contact detected on the touchscreen acts as a “focus selector” so that when input (e.g., a press input by touch) is detected at the location of a particular user interface element (e.g., a button, window, slider, or other user interface element) on the touchscreen display, that particular user interface element is adjusted according to the detected input. In some implementations, focus is moved from one area of ​​the user interface to another without corresponding cursor movement or touch movement on the touchscreen display (for example, by moving focus from one button to another using the tab key or arrow keys). In these implementations, the focus selector moves in accordance with the movement of focus between different areas of the user interface. Regardless of the specific form the focus selector employs, the focus selector is generally a user interface element (or touch on the touchscreen display) controlled by the user to communicate the user's intended interaction with the user interface (for example, by pointing the device to the user interface element that the user intends to interact with).For example, when a press input is detected on a touch-sensitive surface (e.g., a touchpad or touch-sensitive display), the position of the focus selector (e.g., cursor, touch, or selection box) above the corresponding button indicates that the user is attempting to activate the corresponding button (rather than other user interface elements displayed on the device's display).

[0150] Next, we will focus on embodiments of a user interface ("UI") and related processes that can be implemented on an electronic device having a display and a touch-sensitive surface, such as device 100.

[0151] Figure 2 is a schematic diagram of a touchscreen used to illustrate a user interface for an application menu according to several embodiments. Optionally, a similar user interface is implemented on device 100 (Figure 1A). In some embodiments, the user interface for the application menu includes the following elements, or subsets or supersets thereof: ●Signal strength indicators (single or multiple) for wireless communication (single or multiple) such as cellular signals and Wi-Fi signals 202, ●Time 203, ●Bluetooth® indicator 205, ●Battery status indicator 206, ●Tray 209 containing icons for frequently used applications such as the following: ○Optionally including an indicator 214 for the number of missed calls or voicemail messages, an icon 216 for the telephone module 138 labeled "Telephone", An icon 218 for the email client module 140, labeled "Mail," optionally including an indicator 210 for the number of unread emails. ○ Icon 220 for browser module 147, labeled as "Browser", and ○ Icon 222 for the video and music player module 152, also known as the IPOD (registered trademark) (trademark of Apple Inc.) module 152, labeled as "iPod (registered trademark)", and ● Icons for other applications, such as the ones listed below. ○ Icon 224 for IM module 141, labeled as "Message", ○ Icon 226 for calendar module 148, labeled as "Calendar" ○ Icon 228 for image management module 144, labeled as "Photo" ○ Icon 230 for camera module 143, labeled "Camera" ○ Icon 232 for online video module 155, labeled "online video" ○ Icon 234 for stock price widget 149-2, labeled "Stock Price" ○ Icon 236 for map module 154, labeled "Map" ○ Icon 238 for weather widget 149-1, labeled "Weather" ○ Icon 240 for alarm clock widget 149-4, labeled as "Clock" ○ Icon 242 for fitness module 142, labeled "Fitness" ○ Icon 244 for memo module 153, labeled as "Memo" ○ Icons 246 for a configuration application or module that provide access to settings related to device 100 and its various applications, and ○Other icons for additional applications such as the App Store, iTunes®, Voice Memos, and Utilities.

[0152] It should be noted that the icon labels shown in Figure 2 are illustrative only. Other labels may be used optionally for various application icons. For example, icon 242 for fitness module 142 may alternatively be labeled “Fitness Support,” “Training,” “Training Support,” “Exercise,” “Exercise Support,” or “Health.” In some embodiments, the label for each application icon includes the name of the application corresponding to that application icon. In some embodiments, the label for a particular application icon is different from the name of the application corresponding to that particular application icon.

[0153] Figures 3A and 3B are block diagrams illustrating data structures for storing calendar items (for example, for a specific user of device 100) according to several embodiments. As shown in Figure 3A, the calendar item data structure 302 includes a set of data structures 302 that each store calendar items associated with a specific user of device 100, which are optionally implemented as a set of tables for each specific user of device 100 (for example, calendar item data structure 302-1 stores calendar items for user 1 of device 100, and calendar item data structure 302-2 stores calendar items for user 2 of device 100). In some embodiments, each table in the set of calendar item data structures (for example, tables 302-1, 302-2, 302-3...302-N) stores calendar items for two or more users of the device.

[0154] In some embodiments, one or more calendar item data structures 302 (e.g., calendar item data structure 302-1, Figure 3B) are used to store calendar items associated with a user of device 100. As shown in Figure 3B, calendar item data structure 302-1 contains data associated with user 1's calendar items (e.g., calendar item ID, title, location, date and time, departure time reminder, and alert). In some embodiments, the data is stored in individual records 312-1, 312-2, 312-3 to 312-N. In some embodiments, a header field 312-0 is used to describe each field of information associated with each corresponding record. In some embodiments, the header 312-0 contains an overview of each field of information stored in the table (e.g., each field associated with each record). As shown in Figure 3B, the header 312-0 indicates that each record 312-1, 312-2, 312-3 to 312-N stores the following information and data structures, or subsets or supersets thereof. ● The value of the "Calendar Item ID" field that uniquely identifies each specific record (for example, records 312-1 to 312-N); ● The value of the “Title” field corresponding to the descriptive text about the calendar item (e.g., the descriptive text provided by the user at the time the calendar item is generated, such as the text provided in field 770 in Figure 7E). In some situations, the title includes an identifier corresponding to the geographical location (e.g., “Go to the Dentist” in record 312-3 includes the identifier “Dentist” corresponding to the geographical location of the dental clinic (e.g., “Dentist” in the previously visited address associated with record 412-1 in the previously visited addresses data structure 402-1); the value of the “Location” field corresponding to the location information associated with the calendar item (e.g., information provided by the user at the time the calendar item is generated (e.g., provided in field 771 in Figure 7E)). ●In some situations, users generate calendar entries without providing location information (or only providing incomplete location information) (for example, record 312-1 has a NULL value in the location field, indicating that the user did not provide any location information for the calendar entry associated with record 312-1). ● The value of the "Date and Time" field corresponding to information regarding the start and end times of the calendar item (for example, information provided by the user at the time the calendar item was generated (for example, in the "All Day," "Start," "End," and "Repeat" sections shown in Figures 7E to 7F)); ● Based on previously visited addresses associated with the user, the device 100 (or its components, such as the destination determination module 163) automatically and without human intervention generates a value for the "Departure Time Reminder" field (for example, since records 312-1 and 312-2 each contain the same identifier ("Dentist") as part of the title field, the departure time reminder can be automatically generated using the previously visited address associated with record 312-3 (for example, record 412-1 in Figure 4B (as will be discussed in more detail below with reference to Figure 6)). In some embodiments or situations, the value of the departure time reminder further includes information about the optimal route to arrive at the previously visited address (determined, for example, by the route determination module 163-2); and ● The value of the "Alert" field corresponding to information about the alert or reminder for the calendar item (for example, information provided by the user at the time the calendar item was generated, such as "30 minutes ago," as illustrated for record 312-1).

[0155] In some embodiments, the calendar item data structure 302-1 includes, in addition to the fields described above, a timestamp field that identifies when each calendar item was generated and / or stored in table 302-1, and / or related address fields that include one or more address ID values ​​(Figure 4B) corresponding to previously visited addresses associated with each calendar item.

[0156] As shown in Figure 3B, the calendar item data structure 302-1 includes records 312-1, 312-2, 312-3 to 312-N. As an example of the information stored in an exemplary record in the calendar item data structure 302-1, record 312-1 stores the value "1" in the calendar item ID field, the value "Going to the dentist" in the title field, a NULL value in the location field, the value "6 / 12 / 15 12PM~2PM)" in the date and time field, the value "30 minutes ago" in the alert field, and a NULL value in the departure time reminder field. In some embodiments, a NULL value in the departure time reminder field provides the device (or its components, such as the destination determination module 163) with an indicator that a departure time reminder has not yet been generated (as described below with reference to operation 602 in Figure 6).

[0157] Although shown as a specific implementation of a data structure (e.g., a table), in some embodiments the data structures in Figures 3A-3B may be implemented in XML files, tables in relational databases, text files, and / or any other suitable format for storing data.

[0158] Figures 4A and 4B are block diagrams illustrating data structures for storing previously visited addresses (for example, for a specific user of device 100) according to several embodiments. As shown in Figure 4A, the previously visited addresses data structure 402 includes a set of data structures 402 that each store previously visited addresses associated with a specific user of device 100, which are optionally implemented as a set of tables for each specific user of device 100 (for example, previously visited addresses data structure 402-1 stores previously visited addresses for user 1 of device 100, and previously visited addresses data structure 402-2 stores previously visited addresses for user 2 of device 100). In some embodiments, each table in the set of calendar item data structures (for example, tables 402-1, 402-2, 402-3...402-N) stores previously visited addresses for two or more users of the device.

[0159] In some embodiments, one or more previously visited address data structures 402 (e.g., previously visited address data structure 402-1, Figure 4B) are used to store previously visited addresses associated with the user of device 100. As shown in Figure 4B, previously visited address data structure 402-1 contains data associated with addresses previously visited by user 1 (e.g., address ID, name, arrival address, departure address, related items, and arrival time). In some embodiments, this data is used to generate accurate departure time reminders for upcoming events that do not include location details (e.g., calendar items, events referenced in text messages, etc.) by identifying previously visited addresses corresponding to the next event. In some embodiments, the data is stored in individual records 412-1, 412-2, 412-3 to 412-N. In some embodiments, a header field 412-0 is used to describe each field of information associated with each corresponding record. In some embodiments, the header 412-0 contains an overview of each field of information stored in the table (e.g., each field associated with each record). As shown in Figure 4B, header 412-0 indicates that each record 412-1, 412-2, 412-3 to 412-N stores the following information and data structures, or subsets or supersets thereof. ● The value of the "Address ID" field that uniquely identifies each record associated with a specific previously visited address (for example, "1" is the value stored in the Address ID field of record 412-1); ● The value of the "Name" field corresponds to the text description of a specific previously visited address (for example, "Dental Clinic" is the value stored in the Name field of record 412-1). In some embodiments or situations, the value of the Name field is determined automatically and without human intervention based on an identifier associated with the record (for example, since record 412-1 is associated with calendar item 3, and calendar item 3 (record 312-3 in the calendar item's data structure 302-1) contains the identifier "Dentist", the device uses the same identifier when generating the value of the Name field of record 412-1). In some embodiments, the value of the Name field is a term related to the identifier (if the identifier is "Dentist", the related terms include, for example, teeth (singular), teeth (plural), teeth cleaning, dental hygienist, orthodontist, periodontist, etc.); ● The value of the “Destination Address” field contains information that identifies the address corresponding to the geographic destination the user is going to (e.g., street address, GPS coordinates, etc.) (for example, if a user has a calendar entry for a dental clinic but no location data that identifies the dentist’s address, when the user reaches the specific address at the time identified in the calendar entry, the record in the previously visited addresses data structure 402-1 will be updated to remember the specific address as the destination address); ● An optional “Departure Address” field value containing information that identifies the address (e.g., street address, GPS coordinates, etc.) corresponding to the user’s geographical location at the time of departure to reach a specific destination address (for example, if a user has a calendar item for a dentist appointment and departs from a specific address at a time indicating they are heading to the dentist appointment, when they arrive at the appointment at the time identified in the calendar item, the record in the previously visited addresses data structure 402-1 will be updated to remember the specific address as the departure address); ●The value of the "Related Items" field, which contains information that identifies one or more related items, such as a related message (e.g., email) containing an identifier ("I'm on my way to the dentist now"), a related calendar item (e.g., a "Calendar Item" with the title field value "Dentist's Appointment" as shown for record 312-3 in Figure 3B), etc. (e.g., a content item containing an identifier (e.g., "Dentist") associated with each record); and ● The user's optional "Time of Arrival" field value, which includes information identifying the time of arrival at the geographical location corresponding to the destination address.

[0160] In some embodiments, the previously used address data structure 402-1 includes, in addition to the fields described above, fields such as a “Departure Time” field containing information identifying when the user departed for the destination address, and / or a “Route Used” field containing information identifying the route the user traveled between the departure address and the destination address. In some embodiments, these additional fields are used to help the device predict patterns associated with the user (for example, to identify and predict the most frequently used route or most common departure time for the user).

[0161] As shown in Figure 4B, the previously visited address data structure 402-1 includes records 412-1 to 412-N. As an example of the information stored in an exemplary record in the previously visited address data structure 402-1, record 412-1 stores the address ID field value "1", the title field value "Dentist", the arrival address field value "123N.12345, State, City, Dentist Street", the departure address field value "88W.12345, State, City, Street 2", the related items field "Calendar Item 3, Message 23", and the arrival time field value "5 / 12 / 14, 11:15 AM". In some embodiments, records in the previously visited address data structure 402-1 are generated at predetermined time intervals (e.g., every hour, every four hours, daily, when the device is idle).

[0162] In some embodiments, the data structure 402 of previously visited addresses is prepopulated during a background process running on device 100 (as described below with respect to operations 620 and 622 in Figure 6).

[0163] In some embodiments, previously visited addresses 402 also store information about privacy settings associated with the user of device 100. For example, the user of device 100 can configure privacy settings associated with the storage of previously visited addresses. In some embodiments, the user can configure data collection settings for all information contained within each record in the previously visited addresses data structure 402 (e.g., name, destination address, departure address, related items, arrival time, etc.). For example, the user can configure privacy settings for a first application so that device 100 (or its components, such as map module 154) does not collect the departure address, but collects information about related items, destination address, and arrival time. As another example, for a second application (separate from the first application described above), the user can configure privacy settings so that device 100 (or its components, such as map module 154) does not collect any information about previously visited addresses. In this way, users can control the collection of previously visited addresses on device 100 and select appropriate privacy settings for each application available on device 100 (for example, each of application 136, Figure 1A) based on their personal preferences regarding the collection of previously visited addresses.

[0164] Although shown as a specific implementation of a data structure (e.g., a table), in some embodiments the data structures in Figures 4A-4B may be implemented in XML files, tables in relational databases, text files, and / or any other suitable format for storing data.

[0165] Figure 5 is a block diagram illustrating an exemplary departure time reminder generation system according to several embodiments. As shown in Figure 5, the departure time reminder generation system 500 includes a portable multifunction device 100 and further includes one or more servers 502. The portable multifunction device 100 communicates with one or more servers 502 over one or more networks. One or more networks (e.g., one or more networks 520) connect each component of the departure time reminder generation system 500 so that it can communicate with other components of the departure time reminder generation system 500. In some embodiments, one or more networks 520 include public networks, private networks, or a combination of both public and private networks. For example, one or more networks 520 may be any network (or a combination of networks), such as the Internet, other wide area networks (WANs), local area networks (LANs), virtual private networks (VPNs), metropolitan area networks (MANs), peer-to-peer networks, and / or ad-hoc connections.

[0166] In some embodiments, one or more previously visited address data structures 402 are stored on the portable multifunction device 100, and one or more other previously visited address data structures 402 are stored on one or more servers 502. In some embodiments, the portable multifunction device 100 stores the previously visited address data structures 402, while in other embodiments, one or more servers 502 store the previously visited address data structures 402. Similarly, in some embodiments, one or more calendar item data structures 302 are stored on the portable multifunction device 100, and one or more other calendar item data structures 302 are stored on one or more servers 502. In some embodiments, the portable multifunction device 100 stores the calendar item data structures 302, while in other embodiments, one or more servers 502 store the calendar item data structures 302.

[0167] In embodiments where a table of one or more previously visited addresses 402 or a data structure 302 of one or more calendar items is stored on one or more servers 502, some of the functions performed by the destination determination module 163 (and its components, such as the destination prediction module 163-1, the route determination module 163-2, and the departure reminder module 163-3) are performed on one or more servers 502. In these embodiments, information is exchanged between one or more servers 502 and device 100 via the network 520. For example, if one or more servers 502 store a data structure 402 of previously visited addresses of a first user, in some embodiments, device 100 sends data associated with the first user (e.g., location data collected by the GPS module 135, Figure 1A) to one or more servers 502. In some embodiments, one or more servers 502 then mine the received data to predict destinations for calendar items (as discussed above with respect to Figures 4A-4B) and generate departure time reminders for calendar items. One or more servers 502 also send the generated departure time reminders to the device 100 (or alternatively, send information associated with the generated reminders for presentation on the device). In this way, one or more servers 502 can handle the calculation of when to depart, and only occasional GPS pings from the device 100 are required to maintain the accuracy of the calculation (in this way, the departure time reminder generation system 500 can extend the battery life of the device 100). In some embodiments, the data sent to one or more servers 502 is limited in scope and therefore includes only information relating to the addresses visited by the first user (as described above, the user also configures privacy settings that cover the collection of this data, and these privacy settings, in some embodiments, allow the user to control, limit, or eliminate the exchange of data with one or more servers 502).

[0168] Figure 6 is a flowchart illustrating a method 600 for generating and providing an intelligent departure time reminder according to several embodiments. The method and / or process of Figure 6 is illustrated using Figures 3A-3B, 4A-4B, 5, and 7A-7F. Some of the following embodiments are described with reference to input on a touchscreen (combining a touch-sensitive surface and a display), but in some embodiments, the device detects input on a touch-sensitive surface 195 separate from the display 194, as shown in Figure 1D.

[0169] In some embodiments, Method 600 is executed by one or more components of an electronic device (e.g., a portable multifunction device 100, Figure 1A) and / or an electronic device (e.g., an I / O subsystem 106, an operating system 126, etc.). In some embodiments, Method 600 is stored in a non-temporary computer-readable storage medium and controlled by instructions executed by one or more processors of the device, such as one or more processors 122 of the device 100 (Figure 1A). For simplicity of explanation, Method 600 is described below as being executed by the device 100. In some embodiments, referring to Figure 1A, the operation of Method 600 is performed, at least in part, by or using a destination determination module (e.g., destination determination module 163), previously visited addresses (e.g., previously visited addresses 402), a calendar item data structure (e.g., calendar item data structure 302), a destination prediction module (e.g., destination prediction module 163-1), a route determination module (e.g., route determination module 163-2), a departure reminder module (e.g., departure reminder module 163-3), a graphics module (e.g., graphics module 132), and a touch-sensitive display (e.g., touch-sensitive display system 112). Some operations of Method 600 are optionally combined, and / or the order of some operations is optionally changed.

[0170] As described below, Method 600 (and associated interface) provides an intuitive method for generating intelligent departure time reminders and providing them on an electronic device equipped with a touch-sensitive display. Method 600 streamlines the process for generating departure time reminders by enabling users to quickly generate calendar items with minimal text input, and then automatically and without human intervention, determine the geographical destination corresponding to the calendar item based solely on that minimal text input. Thus, users can continue to quickly generate calendar items on the electronic device, and by utilizing Method 600, the electronic device can seamlessly generate intelligent departure time reminders for those calendar items. In this way, Method 600 helps ensure that users arrive at events in a timely manner. Therefore, Method 600 reduces cognitive burden and the time that users must spend generating calendar items, thereby resulting in a more efficient human-machine interface. For battery-operated electronic devices, generating and providing intelligent departure time reminders faster and more efficiently (for example, by automatically performing tasks that traditionally require extensive user interaction, such as automatically identifying previously visited addresses as destinations for calendar items generated without specific location details) not only saves power but also increases the interval between battery charges.

[0171] In some embodiments, the device identifies the next event having a start time and an unknown location (620). For example, the device receives a text message saying, “Remember your dentist appointment at 2:30 PM today.” The content of the text message includes the next event that the device can identify, having a start time of 2:30 PM today and an unknown location (i.e., in the context of this one text message, the content of this message is unknown because it does not include the location where the dental clinic is located). After identifying the next event, in some embodiments, the device monitors the device’s current location (e.g., using a process running in the background on device 100) (e.g., using a GPS module 135), and when the device is moving (e.g., as indicated by an accelerometer 168 and / or GPS module 135), the device checks whether the current location is close to any dental clinic. In other embodiments, upon determination that the device is no longer moving and has arrived at or near the dental clinic (e.g., has stopped moving) (e.g., by comparing the device's current location with information about the dental clinic's location determined by the map module 154), the device associates the following event with the geographic location (622). In other embodiments, at the time of the appointment or event, the GPS module 135 determines the device's location, and the device associates the following event with its location (622). In some embodiments, associating the following event with the geographic location involves adding a record to the previously visited address data structure 402 (e.g., record 412-1 indicates that it is associated with message 23).

[0172] In some embodiments, the device continuously monitors for the next event (determined, for example, by the destination determination module 163) based on the content associated with one or more items on the device (e.g., text messages, email messages, voice messages, calendar items, notes, and any other items containing information about the next event). By continuously monitoring for the next event and associating it with a corresponding geographical location, the device can pre-build a comprehensive database of previously visited addresses associated with a specific identifier (e.g., dentist) (e.g., data structure 402-1 for previously visited addresses, Figure 4B), and use that comprehensive database to generate an intelligent departure time reminder for the event (e.g., a calendar item), which may not yet contain any information about the location of the event.

[0173] In some embodiments, the device automatically and without human intervention identifies calendar items containing a first identifier (602). For example, calendar items are identified based on text in the title of a calendar item that describes a location in general (e.g., the title contains the first identifier), such as a calendar item with the title "Go to the Dentist" (e.g., the calendar item associated with record 312-1 contains the first identifier "Dentist," Figure 3B). In some embodiments, the first identifier corresponds to an unknown geographical location (unknown to the calendar item, for example, as indicated by a NULL value stored in the location field of the calendar item's data structure 302-1). In some embodiments, the geographical location may be known to the device as a previously visited address (e.g., a geographical location discussed above with respect to operations 620-622), even if the calendar item is not (initially) aware of a previously visited address. In some embodiments, the device searches for previously visited addresses using the first identifier (as described below) and determines the unknown location by identifying the previously visited address corresponding to the first identifier.

[0174] In some embodiments, the device automatically and without human intervention retrieves previously visited addresses associated with a first identifier (e.g., street addresses and / or GPS coordinates corresponding to street addresses) (604) by performing a lookup in a data structure of previously visited addresses 402 using identifiers (e.g., dentist, or related terms such as tooth(singular), tooth(plural), periodontist, orthodontist, etc.). For example, the association between a previously visited address and the first identifier may result from the first identifier having previously appeared in a related item (e.g., another calendar item, a specific text message, a conversation containing a specific text message, or an email message). One exemplary related item is a text message that says, “Remember my 3 PM dental checkup.” Continuing with this embodiment, the user then leaves the first address and subsequently arrives at the second address (for example, the user then arrives at the dentist's address at 2:55 PM, and a new record is generated in the previously visited addresses data structure 402 for the identifier "dentist," as illustrated for record 412-1 in the previously visited addresses data structure 402, based on the identifier from the text message, as shown in Figure 4B). Furthermore, the new record in this embodiment includes an association with related items (for example, the value of the related items field in record 412-1 includes information that identifies related items such as "message 23").

[0175] In some embodiments, previously visited addresses are retrieved from a database of previously visited addresses associated with the device user (e.g., from each previously visited address data structure 402 associated with the user, such as previously visited address data structure 402-1 corresponding to user 1, Figure 4B), (e.g., by destination determination module 163). In some embodiments, each previously visited address in the previously visited addresses database corresponds to an address previously visited by the user of the electronic device (e.g., each record contained within data structure 402-1 corresponds to an address visited by user 1). In some embodiments, retrieving previously visited addresses involves performing a lookup in the previously visited addresses database using a first identifier (e.g., submitting a query to previously visited address data structure 402-1 for all records with the value "dentist" in the name field). Alternatively, in some embodiments, the lookup is performed using a second identifier related to the first identifier (e.g., a category containing the first identifier, such as "medical professional"). In some of these embodiments, a second identifier is used to perform a lookup when a database query using the first identifier returns an empty or null recordset.

[0176] In some embodiments, the device receives confirmation from the user that a previously visited address corresponds to a calendar item (606). As shown in Figure 7A, the device presents the user with a user interface object that allows the user to confirm that a previously visited address corresponds to a calendar item. For example, the presented user interface object is displayed in the upper notification unit 710 (or alternatively, the lower notification unit 712) and includes an optional icon 750, a confirmation dialog 758 with selectable affordances for confirming or rejecting the correspondence between a previously visited address and a calendar item, and a suggestion reason 714 that provides the user with an indication of why the user interface object was presented (for example, based on the identifier "dentist" appearing in the title of the calendar item and the user having previously visited the dentist's address). In some embodiments, the icon 750 corresponds to an icon associated with a calendar application (e.g., calendar module 148, Figure 1A), and in response to detecting a selection of the icon 750, the device displays the calendar item within the calendar application. In some embodiments, the confirmation dialog 758 includes a text description requesting confirmation, such as "Do you want to confirm 123N. Dentist as the address for your next 'Dental Checkup' event at 12 PM?". Upon detecting a selection of the "Yes" button displayed within the confirmation dialog 758, the device stops displaying the confirmation dialog 758 and updates the calendar item to include an association with a previously visited address (for example, updating record 312-1, Figure 3B, to have the value "Address 1" in the location field instead of NULL).

[0177] In response to detecting the selection of the “No” button displayed in the confirmation dialog 758, the device stops displaying the confirmation dialog 758 and cancels updating the calendar item (e.g., does not update the value of the location field in record 312-1, Figure 3B). Alternatively, in some embodiments, in response to detecting the selection of the “No” button, the device returns to the retrieve operation 604 to determine whether it can identify a different previously visited address for the calendar item. In some embodiments, in response to detecting the selection of the suggestion reason affordance 714, the device displays a user interface that allows the user to configure privacy settings associated with a set of previously visited addresses (discussed above with respect to Figures 4A-4B). In some embodiments, the user interface object also includes an affordance (e.g., “x” or “close” affordance) that allows the user to reject the user interface object (similar to the reject affordance 713, as discussed with reference to Figure 7C).

[0178] In some embodiments, as shown in Figure 7A, the device receives confirmation from the user that a departure time should be determined for a calendar item (for example, before retrieving previously visited addresses and / or before determining the departure time). As shown in Figure 7A, the device presents a user interface object that allows the user to confirm that the departure time should be determined automatically. For example, the presented user interface object is displayed in the lower notification unit 712 (or alternatively, the upper notification unit 710) and includes an optional icon 750, a confirmation dialog 772 with selectable affordances for confirming or rejecting the generation of a departure time for a calendar item, and a suggestion reason 714 that provides the user with an indication of why the user interface object was presented (for example, by indicating that a NULL value exists in the record's location field in the calendar item's data structure 302, as illustrated for record 312-1 in Figure 3B, based on the fact that the calendar item is generated without any location information). In some embodiments, the icon 750 corresponds to an icon associated with a calendar application (e.g., calendar module 148, Figure 1A), and in response to detecting the selection of the icon 750, the device displays the calendar item within the calendar application. In some embodiments, the confirmation dialog 772 includes a text description requesting confirmation, such as, "Do you need an automatic departure reminder for the next 'Dental Checkup' event?". Upon detecting a selection of the "Yes" button displayed in the confirmation dialog 772, the device stops displaying the confirmation dialog 772 and proceeds with the retrieval operation 604 discussed above. Upon detecting a selection of the "No" button displayed in the confirmation dialog 772, the device stops displaying the confirmation dialog 772 and optionally flags the record corresponding to the calendar item (e.g., record 312-1, Figure 3B) as not requiring a departure time (e.g., updating the value of the position field to be withdrawn instead of NULL).In some embodiments, upon detecting the selection of the suggestion affordance 714, the device displays a user interface that allows the user to configure privacy settings associated with a set of previously visited addresses (discussed above with respect to Figures 4A-4B). In some embodiments, the user interface object also includes an affordance (e.g., an "x" or "close" affordance) that allows the user to reject the user interface object (similar to the reject affordance 713, as discussed with respect to Figure 7C).

[0179] In some embodiments, the device automatically and without human intervention determines the departure time of a calendar item based on a previously visited address (e.g., based on the route from the device's current location to the previously visited address) (608). In some embodiments, determining the departure time includes (i) determining the current address corresponding to the electronic device (e.g., the device's current GPS coordinates or the corresponding address), (ii) determining the route from the current address to the previously visited address, and (iii) determining the departure time based on the amount of time it takes for the user to complete the route so that they reach the previously visited address within a predetermined amount of time (e.g., 5 minutes, 10 minutes, 15 minutes, etc.) from the start time associated with the calendar item (e.g., the start time is retrieved from the calendar item's data structure 302 based on a value stored in the datetime field).

[0180] In some embodiments, the departure time is initially determined at a first time point based on a default departure address associated with the user (e.g., the user's home address, work address, or some other most frequently used address). In some embodiments, the first time point is the time when previously visited addresses are retrieved, while in other embodiments, the first time point is determined based on the start time of a calendar item (e.g., the initial departure time is determined when the calendar item's start time is scheduled to begin in 2 hours). In some embodiments, the device then checks (at a second time point) whether the initial departure time needs to be recalculated / re-determined (e.g., because the user has traveled a threshold distance away from the default departure address, or because the calendar item's start time is scheduled to begin in 30 minutes). Based on the determination that the user has traveled a threshold distance away from the default departure address, or that the calendar item's start time is within a predetermined amount of time, the device determines the new departure time for the calendar item based on the device's current location (i.e., the device's current location is the departure address at that time, not the default departure address).

[0181] In some embodiments, the route is selected from multiple available routes from the current address to a previously visited address, according to the route selection preferences associated with the device user. Exemplary route selection preferences include road type preferences (e.g., avoiding highways), timing preferences (e.g., arriving at the address within 15 minutes of the calendar item's start time), and mode of transport preferences (e.g., preferring to walk if the previously visited address is within 3 miles of the current address and / or if the weather is good). In some embodiments, the current address is stored in the departure address field of the previously visited addresses data structure 402. In some embodiments, decision operations (i) to (iii) are performed at predetermined time intervals relative to the calendar item's start time (e.g., one day before the start time). In some embodiments, decision operations (i) to (iii) are performed at a first time and then repeated thereafter (e.g., at a second time closer to the calendar item's start time) to confirm that the route is still the optimal route based on current traffic conditions.

[0182] In some embodiments, the device associates the determined departure time with a calendar item (610) (for example, updating the record in the calendar item data structure 302 to include the association with the determined departure time, as illustrated for record 312-3 of the calendar item data structure 302-1, and the departure time reminder field includes the value "5 / 12 / 14, 11:25 AM", which is the determined departure time for the calendar item corresponding to record 312-3). In some embodiments, associating the determined departure time with a calendar item includes generating a reminder (e.g., a visual reminder, a tactile reminder (vibration), and / or an auditory reminder) and updating the calendar item to include the generated reminder (612). In some embodiments, the generated reminder is separate from the default reminder associated with the calendar item (e.g., the value in the alert field in the calendar item data structure 302-1, Figure 3B).

[0183] In some embodiments, the device provides a generated reminder to the user of a determined departure time for a calendar item on the electronic device (614) (e.g., displaying a visual reminder on a touch-sensitive display such as the user interface object 702 in Figure 7B, causing the device to output a haptic reminder, and / or causing the device to generate an audio output corresponding to the reminder). In some embodiments, providing a reminder includes providing a reminder according to a determination that the departure time is within a predetermined amount of time from the current time (e.g., displaying the user interface object 702, Figure 7B, on the lock screen 701). For example, the predetermined amount of time may be a default amount such as 5 minutes, 10 minutes, or 15 minutes, or an amount of time calculated based on current predictions regarding changes in traffic and other factors that affect the amount of time required to reach a previously visited address corresponding to the calendar item (e.g., the time it takes to walk from the office building to where the user's car is parked). In some embodiments, the device monitors its motion data (e.g., data from accelerometer 168 and / or GPS module 135) and uses that motion data to determine the estimated amount of time it will take for the user to reach their vehicle (for example, if the device is not moving (at a first time), is moving at pedestrian speed (at a second time), and is moving at vehicle speed (at a third time), the device can use the difference between the third time and the first time as an estimate of the amount of time it will take for the user to reach their vehicle). In some embodiments, the device uses the estimated amount of time (or the average of several estimates) to determine when to provide the generated reminder to the user. In other embodiments, the device adds the estimated amount of time (or the average of several estimates) to the departure time to add a buffer, and then the generated reminder is simply provided at the departure time.

[0184] As shown in Figure 7B, in some embodiments, the provided reminder is displayed on a user interface object 702, or in alternative embodiments, on a user interface object 722 (as discussed below) on the device's lock screen 701. In some embodiments, the user interface object 702 is displayed in the central area of ​​the lock screen 701 and includes an optional first icon 750, an optional second icon 767, and a reminder 742. In some embodiments, the first icon 750 corresponds to an icon associated with a calendar application (e.g., calendar module 148, Figure 1A), and upon detection of a selection of the first icon 750, the device displays a calendar item within the calendar application (e.g., after unlocking the device). In some embodiments, the second icon 767 corresponds to an icon associated with a map application (e.g., map module 154, Figure 1A), and upon detection of a selection of the second icon 767, the device displays a map interface including route change instructions to reach a previously visited address (e.g., after unlocking the device).

[0185] In some embodiments, the reminder (or alert) 742 includes a text description that includes, for example, a departure time (e.g., 11:15 AM) and a calendar item (e.g., a title such as "Dental Checkup"). In some embodiments, the reminder 742 allows the user to use gestures to display affordances for performing actions associated with the reminder (e.g., initiating a change of route instruction, dismissing the reminder, snoozing the reminder, etc.). As shown in Figures 7B to 7C, upon detection of a swipe gesture (e.g., gesture 782, Figure 7B) moving in a first direction (e.g., left) over the reminder 742, the text description of the reminder moves in the first direction, so that at that point only a portion of the text description is visible on the touchscreen 112, and the reminder 742 is updated (e.g., by the graphics module 132) to display one or more affordances for taking action (e.g., one or more of the instruction start affordance 746, snooze affordance 744, and reject affordance 713, Figure 7C). In some embodiments, the one or more affordances include the snooze affordance 744 and the instruction start affordance 746, while in other embodiments, the one or more affordances include the instruction start affordance 746 and the reject affordance 713. In other embodiments, one or more affordances include an instruction start affordance 746, a snooze affordance 744, or a rejection affordance 713.

[0186] Referring next to Figure 7C, in some embodiments, the reject affordance 713, when selected, causes the device to stop displaying the reminder 742. In some embodiments, the instruction start affordance 746 (also referred herein as the route change instruction affordance 746), when selected, causes the device to display a map interface (e.g., map module 154) with a previously visited address prepopulated as the destination and route change instructions to reach the destination already initiated. In some embodiments, before the map interface is displayed, the user performs an action to unlock the device 100 (e.g., enter a series of characters to unlock the device, provide a verbal password, perform fingerprint authentication, etc.). In other embodiments, the instruction start affordance 746 includes text indicating to the user that by selecting the instruction start affordance 746, the device will begin providing route selection and route change instructions (e.g., providing audio output corresponding to the instructions) without leaving the lock screen 701.

[0187] In some embodiments, the snooze affordance 744, when selected, causes the device to stop displaying the UI object 702 and redisplay the UI object 702 after a user-selected or pre-configured time period or after a default time period. In some embodiments, the snooze affordance 744 allows the user to select the time period for which to snooze the reminder (for example, the snooze affordance 744 includes selectable options such as 15 minutes, 30 minutes, 1 hour, until time is free, etc.). For example, the user selects the option to snooze the UI object 702 for 5 minutes, and after 5 minutes, the device redisplays the UI object 702. In another example, the user chooses to snooze the UI object 702 until it becomes available (for example, "snooze until time is free"), and in some embodiments, the device 100 searches the calendar module 148 to identify the next open slot in the user's schedule and redisplays the UI object 702 during the identified next open slot.

[0188] In some embodiments, the user may also use an additional gesture (e.g., gesture 783 in Figure 7B) to quickly access route change instructions. In some embodiments, the additional gesture is a swipe gesture on the reminder 742 that moves in a second direction opposite to the first direction (e.g., to the right). Upon detecting that the second gesture is moving in the second direction, the device displays a map interface (e.g., map module 154) with previously visited addresses prepopulated as destinations and route change instructions to reach the destination already initiated. In some embodiments, before displaying the map interface, the user performs an action to unlock the device 100 (e.g., enter a series of characters to unlock the device, provide a verbal password, perform fingerprint authentication, etc.).

[0189] Referring again to Figure 7B, alternative embodiments of providing the generated reminder are shown with respect to a user interface object 722. In some of the alternative embodiments, the provided reminder is displayed on a user interface object 722 on the device's lock screen 701. In some of the alternative embodiments, the user interface object 722 is substantially displayed in the central area of ​​the lock screen 701 and includes a first icon 750(a), a second icon 767(a), a reminder 742(a), a snooze option 744(a), and a change of direction instruction affordance 746(a). In some of the alternative embodiments, the first icon 750(a) corresponds to an icon associated with a calendar application (e.g., calendar module 148, Figure 1A), and in response to detecting the selection of the first icon 750(a), the device displays a calendar item within the calendar application (e.g., after unlocking the device). In some of the alternative embodiments, the second icon 767(a) corresponds to an icon associated with a map application (e.g., map module 154, Figure 1A), and upon detection of the selection of the second icon 767(a), the device displays a map interface including route change instructions to reach a previously visited address (e.g., after unlocking the device). In some embodiments, the reminder 742(a) includes a text description such as "Time to leave for your dental appointment!". Upon detection of the selection of the reminder 742(a), the device stops displaying the reminder 742(a) and displays a calendar item in a calendar application (e.g., after unlocking the device).

[0190] In some of the alternative embodiments, the snooze option 744(a) includes one or more selectable options for stopping the display of the UI object 722 and redisplaying the UI object 722 after a user-selected or pre-configured time period. For example, the user selects the option to snooze the UI object 722 for two hours, and after two hours, the device redisplays the UI object 722. In another example, the user chooses to snooze the UI object 722 until it becomes available (e.g., "snooze until time is free"), and in some of the alternative embodiments, the device 100 searches the calendar module 148 to identify the next open slot in the user's schedule and redisplays the UI object 722 during the identified next open slot.

[0191] In some of the alternative embodiments, the route change instruction affordance 746(a) includes text indicating to the user that selecting the route change instruction affordance 746(a) will cause the device to initiate route selection and provide route change instructions (for example, providing an audio output corresponding to the instruction (e.g., an instruction based on the selected route) without leaving the lock screen 701).

[0192] In some embodiments, a combination of both user interface object 702 and user interface object 722 is used. For example, a route change instruction affordance 746 or 746(a) is displayed below a reminder (e.g., reminder 742 or reminder 742(a)), and a snooze option 744 and a reject option 713 are available through a first gesture (e.g., in response to the detection of a first gesture).

[0193] In some embodiments, the device determines, in response to (or after) a reminder, whether the user has arrived at a previously visited address (616) (for example, after determining that the user has stopped moving (based on data provided by, for example, accelerometer 168, Figure 1A), the device compares the device's current GPS coordinates with the GPS coordinates associated with the previously visited address). In accordance with the determination that the user has arrived at a previously visited address, the device updates the location information associated with the previously visited address. In some embodiments, updating the location information includes refining the GPS coordinates associated with the previously visited address (for example, when the user has arrived at (or within a first predetermined distance from) the destination address of a previously visited address associated with record 412-1, if the device determines that the signal strength corresponding to GPS 135 is greater than the signal strength when the destination address was previously established, the device replaces the destination address with the device's current GPS coordinates). In some embodiments, upon determining that the current GPS coordinates exceed a second predetermined distance from a previously visited address, the device adds a new record to the previously visited addresses data structure 402-1, which contains the value of the destination address (or the corresponding physical street address) corresponding to the current GPS coordinates. For example, the new record corresponds to a new parking location near a previously visited address.

[0194] In some embodiments, the device requests feedback from the user before refining or updating the arrival address (as discussed above). In some embodiments, as shown in Figure 7D, the device presents the user with a user interface object that allows the user to decide whether or not to update the arrival address. For example, the presented user interface object is displayed in the upper notification unit 710 (or alternatively, the lower notification unit 712) and includes an optional icon 767, a confirmation dialog 752 with selectable affordances for confirming or rejecting the arrival address update, and a suggestion reason 714 that provides the user with an indication of why the user interface object was presented. In some embodiments, the optional icon 767 corresponds to an icon associated with a map application (e.g., map module 154, Figure 1A), and upon detecting a selection of the icon 767, the device displays a map interface containing identifiers for both the currently stored arrival address and the arrival address that may be updated (i.e., the device's current location). In some embodiments, the confirmation dialog 752 includes a confirmation requesting a text description such as, "Do you want to update the stored dentist's address based on your current location?" Upon detecting the selection of the "No" button displayed in the confirmation dialog 752, the device discontinues displaying the confirmation dialog 752 and updates the record associated with previously visited addresses to include the updated value of the arrival address field. Upon detecting the selection of the "No" button displayed in the confirmation dialog 752, the device discontinues displaying the confirmation dialog 752 and cancels updating the record associated with previously visited addresses. In some embodiments, upon detecting the selection of the suggestion reason affordance 714, the device displays a user interface that allows the user to configure privacy settings associated with the location data and the set of previously visited addresses (discussed above with respect to Figures 4A-4B).In some embodiments, the user interface object also includes affordances (e.g., "x" or "close" affordances) that allow the user interface object to be rejected by the user.

[0195] In some embodiments, the device scans multiple new calendar items (618) during the calendar item creation process (e.g., the calendar item creation process shown in Figures 7E-7F). Based on the determination that a first identifier is included in each of the multiple scanned new calendar items (e.g., field 770 contains the identifier "Dentist"), the device presents the user of the device with previously visited addresses to include in each new calendar item (e.g., the device presents a user interface object 772 with the text "123N.12345, State, City, Dentist Street (Tap to confirm)"). In response to detecting a selection in the user interface object 772, the device associates the new calendar item with the previously visited address.

[0196] It should be understood that the specific sequence of operations described in Figure 6 is merely illustrative and is not intended to indicate that the described sequence is the only sequence in which the operations can be performed. Those skilled in the art will recognize various ways of rearranging the sequence of operations described herein.

[0197] In some embodiments, Figure 8 shows a functional block diagram of an electronic device 800 configured according to the principles of the various embodiments described. The functional blocks of this device are optionally implemented by hardware, software, firmware, or a combination thereof to perform the principles of the various embodiments described. Those skilled in the art will understand that the functional blocks described in Figure 8 are optionally combined or separated into subblocks to perform the principles of the various embodiments described. Accordingly, the description herein optionally supports any possible combination or division of the functional blocks described herein, or further definitions. For simplicity of discussion, the electronic device 800 is implemented as a portable multifunction device 100 (Figure 1A).

[0198] As shown in Figure 8, the electronic device 800 includes a display unit 801 (e.g., a touch-sensitive display system 112, Figure 1A, also referred to as a touchscreen, touch-sensitive display, and touchscreen display) configured to display information, a touch-sensitive surface unit 803 (e.g., a display controller 156 and a touch-sensitive display system 112, Figure 1A) configured to receive touch, gestures, and other user input on the touch-sensitive display, and a processing unit 805 connected to the display unit 801 and the touch-sensitive surface unit 803. In some embodiments, the processing unit includes an identification unit (e.g., identification unit 807), a retrieval unit (e.g., retrieval unit 809), a determination unit (e.g., determination unit 811), an association unit (e.g., association unit 813), a provision unit (e.g., provision unit 815), a selection unit (e.g., selection unit 817), a generation unit (e.g., generation unit 819), a reception unit (e.g., reception unit 821), an execution unit (e.g., execution unit 823), a scan unit (e.g., scan unit 825), a presentation unit (e.g., presentation unit 827), and an update unit (e.g., update unit 829). The processing unit is configured to automatically and without human intervention identify a calendar item containing a first identifier corresponding to an unknown geographical location (for example, using the identification unit 807), automatically and without human intervention retrieve a previously visited address associated with the first identifier (for example, using the retrieval unit 809), automatically and without human intervention determine the departure time of the calendar item based on the previously visited address (for example, using the determination unit 811), and automatically and without human intervention associate the determined departure time with the calendar item (for example, using the association unit 813).

[0199] In some embodiments of the electronic device 800, the processing unit is further configured to provide the user with a reminder of the determined departure time for a calendar item on the electronic device (for example, using the providing unit 815 and the display unit 801 (or using the providing unit 815 in conjunction with the display unit 801)). In some embodiments of the electronic device 800, the calendar item is associated with a default reminder separate from the reminder of the determined departure time for the calendar item provided to the user. In some embodiments of the electronic device 800, providing a reminder includes providing a reminder (for example, using the providing unit 815 and the display unit 801 (or using the providing unit 815 in conjunction with the display unit 801)) according to a determination (for example, by the determination unit 811) that the departure time is within a predetermined amount of time from the current time. In some embodiments of the electronic device 800, associating the determined departure time with a calendar item includes generating a reminder (for example, using the generation unit 819) and updating the calendar item to include the generated reminder.

[0200] In some embodiments of the electronic device 800, determining the departure time includes (i) determining the current address corresponding to the electronic device (e.g., using a determination unit 811), (ii) determining the route from the current address to a previously visited address (e.g., using a determination unit 811), and (iii) determining the departure time (e.g., using a determination unit 811) based on the amount of time required to complete the route so that the user reaches the previously visited address within a predetermined amount of time from a start time associated with a calendar item. In some embodiments of the electronic device 800, the route is selected from a plurality of available routes from the current address to a previously visited address (e.g., using a selection unit 817) according to the route selection preferences associated with the user of the electronic device.

[0201] In some embodiments of the electronic device 800, the processing unit is further configured to receive confirmation from the user of the electronic device (for example, using a receiving unit 821) on a touch-sensitive display that a previously visited address corresponds to a calendar item, before determining the departure time. After receiving the confirmation, the processing unit is configured to determine the departure time (for example, using a determination unit 811).

[0202] In some embodiments of the electronic device 800, retrieving a previously visited address includes retrieving the address from a database of previously visited addresses associated with the user of the electronic device (for example, using a retrieval unit 809). In some embodiments of the electronic device 800, each previously visited address in the database of previously visited addresses corresponds to an address previously visited by the user of the electronic device. In some embodiments of the electronic device 800, retrieving a previously visited address includes performing a lookup in the database of previously visited addresses using a first identifier (for example, using an execution unit 823).

[0203] In some embodiments of the electronic device 800, the processing unit is further configured to scan multiple new calendar items during the calendar item creation process (for example, using the scan unit 825). Based on the determination (for example, by the determination unit 811) that each of the scanned new calendar items contains a first identifier, the processing unit is configured to present previously visited addresses to the user of the electronic device for inclusion in each new calendar item (for example, using the presentation unit 827 and the display unit 801 (or using the presentation unit 827 in conjunction with the display unit 801)).

[0204] In some embodiments of the electronic device 800, the processing unit is further configured to determine (for example, using a determination unit 811) whether the user has arrived at a previously visited address in response to the provision of a reminder. In accordance with the determination (for example, by the determination unit 811) that the user has arrived at a previously visited address, the processing unit is configured to update the location information associated with the previously visited address (for example, using an update unit 829).

[0205] The operation of the information processing method described above is optionally performed by activating one or more functional modules within the information processing device, such as a general-purpose processor (for example, one as described above in relation to Figure 1A) or an application-specific chip.

[0206] Referring to Figure 5, the operations described above are optionally performed by the components shown in Figures 1A to 1B or Figure 8. For example, the receiving operation 606 and the providing operation 614 are optionally performed by the event sorting unit 170, the event recognition unit 180, and the event processing unit 190. The event monitor 171 of the event sorting unit 170 detects contact on the touch-sensitive display 112, and the event dispatcher module 174 distributes the event information to application 136-1. The corresponding event recognition unit 180 of application 136-1 compares the event information with the corresponding event definition 186 and determines whether the first contact (or device rotation) at the first location on the touch-sensitive surface corresponds to a default event or sub-event, such as the selection of an object on the user interface or the rotation of the device from one orientation to another. If a corresponding default event or sub-event is detected, the event recognition unit 180 activates the event processing unit 190 associated with the detection of the event or sub-event. The event processing unit 190 optionally uses or calls the data update unit 176 or the object update unit 177 to update the application's internal state 192. In some embodiments, the event processing unit 190 accesses the corresponding GUI update unit 178 to update what is displayed by the application. Similarly, it will be clear to those skilled in the art how other processes are performed based on the components shown in Figures 1A and 1B.

[0207] The above description is based on reference to specific embodiments for illustrative purposes. However, the above exemplary discussion is not intended to be exhaustive or to limit the invention to the exact form disclosed. In light of the above teachings, many modifications and variations are possible. These embodiments have been selected and described in order to best illustrate the principles and practical applications of the invention, thereby enabling other persons skilled in the art to best use the invention and its various embodiments with various improvements suitable for specific applications that may be conceived.

Claims

1. It is a method, In an electronic device having a touch-sensitive display and a position sensor, The electronic device identifies an identifier and an associated second time, date, or the second time and date, wherein the identifier is the name of an entity that the user plans to visit at the second time, date, or the second time and date, and the second time is later than the first time. In response to the determination that the user is scheduled to visit the entity at the second time, the date, or the second time and date, the position sensor is used to determine the location of the electronic device as the entity address. Associating the aforementioned identifier with the aforementioned entity address, The aforementioned identifier and the associated entity address are stored, When the aforementioned identifier is received as input, Using the aforementioned identifier, obtain the entity address, The touch-sensitive display displays selectable user interface elements corresponding to the entity address, Receiving the selection of the selectable user interface element corresponding to the entity address, In response to receiving the aforementioned selection, the entity address is provided for use by the application on the electronic device, A method that includes this.

2. The method according to claim 1, wherein the identifier and the associated entity address are stored as local data on the electronic device.

3. The method according to claim 1, further comprising providing the entity address for use by an application on the electronic device, thereby providing the user of the electronic device with a service by running the application.

4. The method according to claim 1, wherein the input is received by a map application, the entity address is provided to the map application, and the map application uses the entity address to provide a route change instruction to the associated entity address.

5. The method according to claim 1, wherein the input is received by a calendar application and the entity address is provided to the calendar application as a position field in a calendar entry.

6. The method according to claim 1, wherein the input is received by a reminder application, and the entity address is used, along with the current time, current location, and target arrival time, to calculate a departure time reminder to be displayed to the user on the touch-sensitive display.

7. The method according to claim 6, wherein the departure time reminder is displayed on the home screen of the electronic device.

8. The departure time reminder receives additional input, In response to receiving additional input in the aforementioned departure time reminder, the system will begin providing a route change instruction to the aforementioned entity address. The method according to claim 6, including the method described in claim 6.

9. The method according to claim 8, wherein the lane change instruction is provided within a map application.

10. The method according to claim 1, wherein the identifier and the associated second time, date, or second time and date are obtained by electronic communication.

11. The method according to claim 10, wherein the electronic communication is one of a text message, an email message, or a voice message.

12. The method according to claim 10, wherein one or more user-defined privacy settings allow the user to set one or more data collection settings relating to the conditions for collecting entity addresses by storing collected entity addresses, and in one or more data collection settings, a portion of the addresses that can be obtained as entity addresses are collected.

13. The method according to claim 1, wherein receiving the identifier as input occurs after storing the identifier and the associated entity address.

14. The method according to claim 1, wherein the identification does not include identifying the location of the entity.

15. A computer program that, when executed by an electronic device having a touch-sensitive display and a position sensor, includes a set of executable instructions that cause the electronic device to perform the method according to any one of claims 1 to 14.

16. An electronic device comprising a touch-sensitive display, a position sensor, one or more processors, and a memory, wherein the memory includes a set of executable instructions that, when executed by the one or more processors, cause the electronic device to perform the method according to any one of claims 1 to 14.

Images